Thanks Robert,
Daves article is mind opening. I created 4 variants of my program to
compare the effects and to give others the chance to study it:
1. https://play.golang.org/p/WE_CbRlfTFf
2. https://play.golang.org/p/FnuzyEVHS-I
3. https://play.golang.org/p/S9ssTxlZK6X
4. https://play.
Now I got it - thanks for the explanation.
Am Mi., 19. Dez. 2018 um 02:25 Uhr schrieb :
> > feel unbuffered channels are safer to use especially in an acyclic
> directed graph of flowing values. Buffered channels seem to reduce blocking
> but I feel they come with the cost of such side effects li
Go 1.12 is the last release that will support binary-only packages.
What are the alternatives?
I need binary-only packages for packages that use cgo with non-standard
environment variable values.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
I tend to give my tests numbers and names. The number lets me run just one
(go test -v -run 001); the name can
be used in the -r regular expression to pick out a class such as priority.
For example,
func Test001DesctiptionHerePriorityA(t *testing.T) { ... }
func Test002DescriptionHerePriorityA(
Can you please describe what is goasm? I tried searching for it but I get mixed
results. Is there a link to the documentation of the project that I can use?
After that, I'll be happy to help you out. Alternatively, feel free to open an
issue on the tracker https://youtrack.jetbrains.com/issues/G
On Tue, Dec 18, 2018 at 7:44 PM komuW wrote:
>
> is go.sum documented? I have seen a couple of questions on the same in the
> #modules channel on gophers slack
go.sum is documented, briefly, at
https://tip.golang.org/cmd/go/#hdr-Module_downloading_and_verification.
I don't know whether it deserv
On Tue, Dec 18, 2018 at 6:25 PM Yanhao Mo wrote:
>
> 伊藤和也 writes:
>
> > Are there typed variables?
> I'm affraid not.
I'm not sure what any of this really means, but, to be clear, in Go
all variables have types.
Ian
--
You received this message because you are subscribed to the Google Groups
Try to access https://news.kompas.com with http.Client
code here: https://play.golang.org/p/lr71n5No_8Z
It seems that tls handshake succeeds, but server does not write response?,
it keeps retrying until timeouts:
DNS Info: {Addrs:[{IP:202.146.4.17 Zone:}] Err: Coalesced:false}
> Conn Done:
> T
is go.sum documented? I have seen a couple of questions on the same in the
#modules channel on gophers slack
On Tuesday, 18 December 2018 19:14:12 UTC+3, Ian Lance Taylor wrote:
>
> On Tue, Dec 18, 2018 at 8:07 AM Sam Whited > wrote:
> >
> > I've been asked multiple times recently to point peo
伊藤和也 writes:
> Are there typed variables?
I'm affraid not.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more
I'm not an expert but I do my best.
Original json format required:
{ "pos": [{ "lp" : "WISE-12", "lat": "-33,43565400", "lon" :
"-70,60552700", "speed" : "102" }]
}
Json autogenerated from: https://mholt.github.io/json-to-go/ (lazy style
but it works. Even more when my boss is surrounding li
Unbuffered channels are not dangerous. They just mean that “done sending”
is not the same as “done receiving.” I have done many variations of these
approaches and all work...but I’ve never used select.
On Tue, Dec 18, 2018 at 5:25 PM wrote:
> > feel unbuffered channels are safer to use especiall
> feel unbuffered channels are safer to use especially in an acyclic
directed graph of flowing values. Buffered channels seem to reduce blocking
but I feel they come with the cost of such side effects like my initial
problem of forgotten results in their channels.
that happens with unbuffered
Hello gophers,
We have just released go1.12beta1, a beta version of Go 1.12.
It is cut from the master branch at the revision tagged go1.12beta1.
Please try your production load tests and unit tests with the new version.
Your help testing these pre-release versions is invaluable.
Report any prob
I hope so.
--
Aram Hăvărneanu
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.g
Are there typed variables?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google
On Tue, Dec 18, 2018 at 11:23 PM 伊藤和也 wrote:
> There are untyped and typed constants. Are there untyped variables?
No, there are not. But please note, that untyped constants remain untyped
only when _not_ used. Any actual use of an untyped constant in any possible
context "collapses the wave fun
There are untyped and typed constants. Are there untyped variables?
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For
All right. With GCC 6.X it worked! Thanks so much for your support.
As promised, here is my installation script (feel free to use this):
sudo add-apt-repository ppa:ubuntu-toolchain-r/test -y
sudo apt update && sudo apt upgrade -y
sudo apt install python3 git build-essential cmake m4 libxml2-dev
This may be a helpful read:
https://dave.cheney.net/2013/04/30/curious-channels
> On Dec 18, 2018, at 2:02 PM, robert engels wrote:
>
> To clarify the semantics aspects:
>
> If A cannot proceed until B performs it’s work, because there is a
> dependency, then using a unbuffered channel simpli
To clarify the semantics aspects:
If A cannot proceed until B performs it’s work, because there is a dependency,
then using a unbuffered channel simplifies a lot - you will always be at most
“one event ahead” without any extra synchronization (wait groups, etc.)
> On Dec 18, 2018, at 2:01 PM, r
Whether to use buffered or unbuffered comes down to two things:
1) the semantics of the communication. because using unbuffered channels
simplifies a lot - knowing the send will not complete until the read completes
- it provides a synchronization mechanism between events/messages and routines.
What he is saying is that a closed channel is always ready to be received, so
in your code, you could achieve closed++ twice on the same channel...
> On Dec 18, 2018, at 1:38 PM, Chris Burkert wrote:
>
> Justin,
> I don‘t understand that. Maybe I am wrong but I think this is not an issue
> any
Robert,
it seems to me that you have a clear understanding about unbuffered vs.
buffered channels. I feel unbuffered channels are safer to use especially
in an acyclic directed graph of flowing values. Buffered channels seem to
reduce blocking but I feel they come with the cost of such side effects
Justin,
I don‘t understand that. Maybe I am wrong but I think this is not an issue
anymore with the wait group as Ian proposed. It fully replaces the done
channel by closing all result channels while the select keeps on reading
from the result channels until they are all closed and empty. Please
co
hey im wondering if anyone knows how to set up a goasm projecct?
Thanks in advance
H
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@goo
Just realized what you meant about buffered channels. I'm wrong, and sorry
for the confusion.
+1 to your original solution (combined with setting channels to nil).
Diane Looney
On Tue, Dec 18, 2018 at 11:31 AM Chris Burkert
wrote:
> Hello Ian, all,
> yes, the workers generate multiple results
I'm not sure this code behaves as you expect it to. I don't think there's
any magic in place to prevent select from picking the same closed channel
more than once. For example:
https://play.golang.org/p/nVvsBxww_Rb
package main
import (
"fmt"
"sync"
)
func test() {
c1 := make(chan bool, 1000)
c
On Wed, Dec 19, 2018, 5:31 AM Chris Burkert wrote:
> Hello Ian, all,
> yes, the workers generate multiple results. I was able to use your
> proposal with the waiting goroutine which closes the channel. Unfortunately
> my initial minimal example was not so minimal. It is a little more
> complicate
Hello Ian, all,
yes, the workers generate multiple results. I was able to use your proposal
with the waiting goroutine which closes the channel. Unfortunately my
initial minimal example was not so minimal. It is a little more
complicated, as I have multiple "result" channels with different types an
On Tue, Dec 18, 2018, at 10:13, Ian Lance Taylor wrote:
> https://tip.golang.org/cmd/go/#hdr-The_go_mod_file
Ah thanks! I wouldn't have ever thought to look there for info on the mod file.
I'll pass that along.
—Sam
--
You received this message because you are subscribed to the Google Groups
Note from my side: It didn't work for me when using gcc 5.4 which meets the
requirements of "V4.9 or later of GCC" stated in your commit. Maybe I made
a mistake during compilation, but my binaries seem to have been compiled by
gcc 5.4 and the symbol is still missing.
Thank you guys for making t
Sent https://go-review.googlesource.com/c/gollvm/+/154737 to make that
correction.
Thanks for the feedback and helping improve gollvm...
Cheers, Than
On Tue, Dec 18, 2018 at 11:03 AM Benedikt T wrote:
> Thanks! Running compilation now, will keep you posted. I thought 5.4 would
> be ok, as the F
On Tue, Dec 18, 2018 at 8:07 AM Sam Whited wrote:
>
> I've been asked multiple times recently to point people to documentation for
> the language line in a go.mod file (eg. the `go 1.12' line that's added by
> recent builds), but I haven't been able to find any on the wiki or in `go
> help modu
Hi all,
I've been asked multiple times recently to point people to documentation for
the language line in a go.mod file (eg. the `go 1.12' line that's added by
recent builds), but I haven't been able to find any on the wiki or in `go help
modules` or similar, just the occasional list discussion
On Tue, Dec 18, 2018 at 9:01 AM Skip Tavakkolian
wrote:
>
> why not just drop the select? i think the following is guaranteed because
> putting things on rc has to succeed before putting true into dc:
That will serialize all goroutines. They'll run one after the other.
>
> package main
>
> imp
Since there are multiple results needed to be processed ...
> On Dec 18, 2018, at 10:02 AM, Robert Engels wrote:
>
> That code is incorrect as well when using buffered channels.
>
>> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian
>> wrote:
>>
>> why not just drop the select? i think the fo
That code is incorrect as well when using buffered channels.
> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian
> wrote:
>
> why not just drop the select? i think the following is guaranteed because
> putting things on rc has to succeed before putting true into dc:
>
> package main
>
> impor
Thanks! Running compilation now, will keep you posted. I thought 5.4 would
be ok, as the FAQ for building gollvm states: "You'll need to have an
up-to-date copy of cmake on your system (3.6 or later vintage) to build
Gollvm, as well as a C/C++ compiler (V5.0 or later for Clang, or V4.9 or
later
why not just drop the select? i think the following is guaranteed because
putting things on rc has to succeed before putting true into dc:
package main
import (
"fmt"
)
func do(i int, rc chan<- int, dc chan<- bool) {
rc <- i
dc <- true
}
func main() {
worker := 10
rc := make(chan int, worker)
You are both correct, I somehow missed that they were buffered. Thanks for
correcting me. On a side note, is there a reason not to use a wait all?
Thanks.
On Tue, Dec 18, 2018 at 10:05 AM Robert Engels
wrote:
> I don’t think that code is correct. You are using buffered channels do it
> could rea
On Tue, Dec 18, 2018 at 6:27 AM wrote:
>
> I have to projects. One is cgo and one is C application.
> The cgo has a function which needs to return pointer to struct.
> The C app receives this pointer and then calls other function in cgo with
> this pointer.
> I build the cgo as shared lib:
>
> go
I don’t think that code is correct. You are using buffered channels do it could
read the done values and exit before reading any results technically since when
data is available on both it is random which is read.
> On Dec 18, 2018, at 8:32 AM, john_halder...@moma.org wrote:
>
> This code work
On Tue, Dec 18, 2018 at 1:50 AM Benedikt T wrote:
>
> Ok, compilation went through after I ran the make command again. Seems like
> this run the debug data is omitted. However, setting the compiler to GCC
> yields the same error:
>
> ~/llvm-install/bin#
> LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/
This code works though, it's not possible to send the dc before the rc is
read and so the done counter cannot reach 2 before both 0s have been
written. I made a playground that runs it 100k times to
demonstrate. https://play.golang.org/p/DKltfzDI95L
On Tuesday, December 18, 2018 at 8:35:26 AM U
On Tue, Dec 18, 2018 at 5:35 AM Chris Burkert wrote:
>
> I have a couple of goroutines sending multiple results over a channel - a
> simple fan-in. They signal the completion on a done channel. Main selects on
> the results and done channel in parallel. As the select is random main
> sometimes
I have a VPN connection configured on Ubuntu using a certificate, I run the
bot telegrams locally, is there a way to connect to the vpn server directly
from the application itself
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe
Hi,
I have to projects. One is cgo and one is C application.
The cgo has a function which needs to return pointer to struct.
The C app receives this pointer and then calls other function in cgo with
this pointer.
I build the cgo as shared lib:
*go build -o ebsdk.so -buildmode=c-shared*
The cg
On Tue, Dec 18, 2018 at 6:35 AM Chris Burkert wrote:
>
> Dear all,
>
> I have a couple of goroutines sending multiple results over a channel - a
> simple fan-in. They signal the completion on a done channel. Main selects on
> the results and done channel in parallel. As the select is random main
Thinking about it, use the expected count, in the done process decrement the
count and only print when 0. Thus works if the channels are unbuffered.
> On Dec 18, 2018, at 7:49 AM, Robert Engels wrote:
>
> This is not trivial, as you are imposing an order on unrelated async events.
>
> Would
This is not trivial, as you are imposing an order on unrelated async events.
Would you phrase the condition as, do not process a done until I’ve processed
requests for N routines - then you are back to using an expected count.
With an expected count, the problem is trivial.
I think you need t
Dear all,
I have a couple of goroutines sending multiple results over a channel - a
simple fan-in. They signal the completion on a done channel. Main selects
on the results and done channel in parallel. As the select is random main
sometimes misses to select the last result. What would be the idio
Ok, compilation went through after I ran the make command again. Seems like
this run the debug data is omitted. However, setting the compiler to GCC
yields the same error:
~/llvm-install/bin#
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/root/llvm-install/lib:/root/llvm-install/lib64/
./go
./go: symbol l
Is there a problem with the docker hub build at the moment? Currently only Go
1.11.3 is available there:
https://hub.docker.com/_/golang/
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails f
54 matches
Mail list logo
