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.
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
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"
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
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
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
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:
>
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
伊藤和也 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
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
> 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
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
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
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
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
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
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
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,
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
>
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
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
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
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
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)
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
>
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
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
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
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
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
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
>
>
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
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
>
>
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
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
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:
>
>
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
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#
>
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
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
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
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.
>
>
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
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
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
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
53 matches
Mail list logo
