Re: [go-nuts] Interesting "select" examples

[Skip Tavakkolian]

On Mon, Apr 3, 2023 at 5:22 PM Nigel Tao  wrote:
>
> On Tue, Apr 4, 2023 at 7:56 AM Skip Tavakkolian
>  wrote:
> > mux9p, Fazlul Shahriar's port of Russ' 9pserve (plan9port)
> > https://github.com/fhs/mux9p/search?q=clientIO
> >
> > ...
> >
> > select {
> > case v, ok := <- counts:
> > // collect samples
> > case reporting <- Stats{ stats }:
> > case <-timer:
> >// calculate stats from samples
> >  case cmd, ok := <-commands:
> >// reset counters, restart worker, exit, etc.
> > }
>
> I'd have to study mux9p for longer, but its select chooses between two
> receives, so it could possibly collapse to a single heterogenous
> channel. Indeed, both its channels are already heterogenous in some
> sense. Both its processTx and processRx methods say "switch
> m.tx.Type".

One side serializes the Fcall to 9P packet and the other decodes the
packet into Fcall (there is a check m.tx.Type+1 == m.rx.Type;  by 9P
convention).

>
> Your second suggestion, mixing both sends (on the reporting channel)
> and receives, is interesting. Would it be possible to move the
> `reporting <- Stats{ stats }` case inside the `case <-timer: //
> calculate stats from samples` body, though?

Yes, but you'd have to have another select if you don't want to block
on reporting. I have an old piece of code that does that:
https://github.com/9nut/tcpmeter/search?q=Dispatch

I don't know if you're looking for ideas on potential API's for C
implementation, but Plan 9's (and P9P) C API for chan/select is easy
to understand and use (https://9p.io/magic/man2html/2/thread).

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfm%2BheUJBAWd3fub-9JD2%3DovPR_oqfxWT0Dpnpg8aq5jvFw%40mail.gmail.com.

Re: [go-nuts] Interesting "select" examples

[Skip Tavakkolian]

Nice pause/resume. I'll need to remember this.

On Mon, Apr 3, 2023 at 3:14 AM Rob Pike  wrote:
>
> Here's an excerpt from a piece of concurrent code I like, an unpublished 
> interactive game of life. The select near the bottom has only two cases but 
> it is perhaps instructive. I leave its analysis to the reader.
>
> -rob
>
>
>var kbdC chan of rune = ... // events from keyboard
>var ticker = time.NewTicker(*deltaTFlag)
> ...
> pauseC := make(chan int)
> go func() {
> for {
> switch <-kbdC {
> case 'q':
> os.Exit(0)
> case ' ':
> pauseC <- 1
> }
> }
> }()
>
> gen := 0
> for gen = 1; ; gen++ {
> b.draw(display, *cellSizeFlag)
> changed := b.step()
> if !changed {
> break
> }
> select {
> case <-ticker.C:
> case <-pauseC:
> <-pauseC
> }
> }
> fmt.Fprintln(os.Stderr, "stable after", gen, "generations")
> select {}
> }
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOXNBZS11bKz%2B95gUXstgHHrgDRFoTWdm5kmNBriDpoxNz%3DWXQ%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmKsgSgfxzUYa77V1Ry%2Bo1Z9v6_hXY1Ank22y-SY%3Dc82gg%40mail.gmail.com.

Re: [go-nuts] Interesting "select" examples

[Skip Tavakkolian]

I think this qualifies:
mux9p, Fazlul Shahriar's port of Russ' 9pserve (plan9port)
https://github.com/fhs/mux9p/search?q=clientIO

I've used this dispatcher pattern:
func dispatcher(commands chan Cmd, reporting chan Stats, worker Worker) {
  control = make(chan ...)
  counts = make(chan ...)
  timer = time.Tick( ... )
  go worker.Work(control, counts)
  for {
select {
case v, ok := <- counts:
// collect samples
case reporting <- Stats{ stats }:
case <-timer:
   // calculate stats from samples
 case cmd, ok := <-commands:
   // reset counters, restart worker, exit, etc.
}
  }
}


On Sun, Apr 2, 2023 at 8:44 PM Nigel Tao  wrote:
>
> I'm working on a multi-threaded C++ project. We have the equivalent of
> Go's channels, and are considering whether we also need to implement
> the equivalent of Go's select.
>
> Does anyone have interesting, non-trivial examples of a Go select
> statement in real code?
>
> By non-trivial, I mean that a lot of the selects that I've seen have
> exactly two cases, one of them doing "real work" and the other being
> either (1) "default" or (2) a timeout/cancel channel (e.g.
> ctx.Done()).
>
> In our C++ API, our channel send/recv methods already have
> try_send/try_recv equivalents for (1) and a timeout/cancel mechanism
> for (2).
>
> bcmills' "Rethinking Classical
> Concurrency Patterns"
> (https://drive.google.com/file/d/1nPdvhB0PutEJzdCq5ms6UI58dp50fcAN/view)
> uses select to implement higher level ResourcePool / WorkerPool APIs
> but select is arguably a private implementation detail. While it might
> not be as beautiful under the hood, I think we can already present
> similar APIs using C++'s std::counting_semaphore.
>
> r's "A Concurrent Window System"
> (https://swtch.com/~rsc/thread/cws.pdf) discusses select'ing from
> separate window, keyboard and mouse channels but this could arguably
> instead be a single channel of heterogenous elements (e.g. in C++, a
> std::variant).
>
> It's more interesting to select over both input and output channels,
> and output channels may become "ready to communicate" without new
> input. But again, it may be possible to work around that by downstream
> actors sending "I'm ready to receive" events onto the upstream actor's
> heterogenous input channel.
>
> The most interesting selects I have so far is the
> golang.org/x/net/http2 source code, whose internals have a bit of a
> learning curve. If anyone has other examples, please share.
>
> --
> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/CAOeFMNWBtuEci9oPUFNa0v0gDC%3DV6Xb0N05Jyxo%3DxN2ywJALGA%40mail.gmail.com.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmLUntfusLYko%2By2jhkMKOjmmd1wvaKozOcvJS8M%3D30hZw%40mail.gmail.com.

Re: [go-nuts] How to open browser with NTLM auth

[Skip Tavakkolian]

the code is working, but the user/pass are incorrect. user param may need
the domain name (i.e. "DOMAIN\\username")
curl uses the stored credentials, which are usually created when user signs
in or unlocks a session.


On Mon, Oct 28, 2019 at 7:20 PM  wrote:

> When I use go-ntlmssp I get error 401. Try use curl curl --ntlm -u: url,
> get 200
>
> среда, 23 октября 2019 г., 9:11:23 UTC+3 пользователь Skip написал:
>>
>> Googling for "NTLM http go client", the first result looks legit:
>>
>> https://github.com/Azure/go-ntlmssp
>>
>>
>> On Tue, Oct 22, 2019 at 10:20 PM  wrote:
>>
>>> I'm trying emulate browser, open intranet url and get status code 401.
>>> How to open url with NTLM auth or login, pass? Thanks
>>>
>>> package main
>>> import (
>>> "gopkg.in/headzoo/surf.v1"
>>> "fmt")
>>>
>>> func main() {
>>> bow := surf.NewBrowser()
>>> bow.AddRequestHeader("Accept", "text/html")
>>> bow.AddRequestHeader("Accept-Charset", "utf8")
>>> err := bow.Open(url)
>>> if err != nil {
>>> panic(err)
>>> }
>>>
>>> fmt.Println(bow.StatusCode())}
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/golang-nuts/faaa1b45-7516-447c-8397-fa9c16cc549c%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/778568c7-a746-41c3-be8b-386d5a91239c%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfm%2BAJZA_ROoF5gdgsx4zcriGwF256UdpNgE7HGHUawifTw%40mail.gmail.com.

Re: [go-nuts] How to open browser with NTLM auth

[Skip Tavakkolian]

Googling for "NTLM http go client", the first result looks legit:

https://github.com/Azure/go-ntlmssp


On Tue, Oct 22, 2019 at 10:20 PM  wrote:

> I'm trying emulate browser, open intranet url and get status code 401. How
> to open url with NTLM auth or login, pass? Thanks
>
> package main
> import (
> "gopkg.in/headzoo/surf.v1"
> "fmt")
>
> func main() {
> bow := surf.NewBrowser()
> bow.AddRequestHeader("Accept", "text/html")
> bow.AddRequestHeader("Accept-Charset", "utf8")
> err := bow.Open(url)
> if err != nil {
> panic(err)
> }
>
> fmt.Println(bow.StatusCode())}
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/faaa1b45-7516-447c-8397-fa9c16cc549c%40googlegroups.com
> 
> .
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmLgCAGAUbGbbMfJOOWCk7_fovvFHNZnwR3rDASAfFoXug%40mail.gmail.com.

Re: [go-nuts] Let's play

[Skip Tavakkolian]

If your security depends on you not clicking on hyperlinks, you don't have
security.

On Fri, Jul 12, 2019, 10:39 AM Marvin Renich  wrote:

> * Ali Hassan  [190712 12:56]:
> >
> > If you curious about check out the link below
> >
> https://koohinoorgo.blogspot.com/2019/07/methods-bind-to-special-type-of-receiver.html
>
> The only thing about this message that does not look like a phishing or
> Trojan attack is the end of the URL.  The subject and the "If curious,
> click link" as the only text of the message looks exactly like a
> nefarious message.
>
> Please don't send "teaser" messages to a technical mailing list; this is
> generally considered very rude.  This is a moderately high volume
> mailing list, with a large reader base.  Please be polite and include
> enough information in your mailing list post to allow the many readers
> to quickly and easily decide if they are interested in following the
> link to read more.
>
> Thank you...Marvin
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/20190712173928.l7nnjupii5rf2nad%40basil.wdw
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmLOL6Nhzi15X9OsmLTs8zjL54_Y2ePqXpsX6anjPWouMQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Remind me, please, about "taking over" a socket

[Skip Tavakkolian]

Do you mean like tcp half-close?

On Thu, May 30, 2019, 5:40 PM David Collier-Brown 
wrote:

> My leaky brain has lost an old technique...
>
> Once upon a time, I would send an old copy of a program a SIGHUP, and it
> would shut down a socket listening on, for example, port 25 (SMTP). A newer
> release of the program would succeeding in binding to port 25, taking over
> any new connection requests. When the old program closed it's last email
> transfer, it would then exit.
>
> The idea was to update a (mail-)server implementation without losing
> transactions.
>
> I can no longer find the code I once used, nor other people's examples,
> much less modern Golang examples!
>
> Please tell me we haven't lost this technique (:-()
>
> --dave
>
> --
> 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.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/36fabc29-6ccc-45f6-99bb-f728710c6e18%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJSxfmKG%3Dw3sWRMHXg5EPG%2BRBAxvbd1iSOnyPN1a%3De6zKL%3D%3D6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] is -2147483648 the same as MinInt32

[Skip Tavakkolian]

Use Ivy?




On Sun, Apr 21, 2019, 8:36 PM Pat Farrell  wrote:

> I have a logic error in my calculation. I am getting -2147483648 in an
> int32
> This sure looks a lot like MinInt32, but I can't seem to be able to tell,
> all my calculators want to blow up on -1 << 31
>
>
> I'm willing to bet that my value is +/- one from whatever MinInt32 is in
> decimal form.
>
> Is this correct?
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Concurrency safe struct access

[Skip Tavakkolian]

I believe you only need one or the other; I assumed a use case like this:

https://play.golang.org/p/nSgyiXU87XN


On Sun, Apr 14, 2019 at 1:33 PM  wrote:

> I found a good discussion in the FAQ that explains the problem clearly.
> https://golang.org/doc/faq#methods_on_values_or_pointers
>
> I think the mutex is needed on the update function with or without the use
> of sync/atomic.  The atomic guards the Load and the Store but the func is
> operating on the copy returned by Load.  Seems to me it's vulnerable to
> being pre-empted unless the entire read/modify/write sequence is guarded by
> a mutex.
>
> On Sunday, April 14, 2019 at 2:20:02 PM UTC-4, Skip wrote:
>>
>> I don't know if it's documented or not.  In the language reference you
>> can see the rules for method calls:
>>
>> https://golang.org/ref/spec#Calls
>> https://golang.org/ref/spec#Method_sets
>>
>> A hint might have been that object should have mutated, but it didn't.
>> It's in a class of errors that becomes recognizable once you've been bitten
>> by it.
>>
>> In the example you gave, use of mutex seems redundant to me; execution of
>> func passed into update is already guarded by atomic.
>>
>> On Sun, Apr 14, 2019 at 9:51 AM  wrote:
>>
>>> Thanks, Skip. That fixes it. Is the need for a pointer receiver
>>> documented somewhere? It's not something that even crossed my mind given
>>> that the neither the compiler nor golint complained.  I suppose it makes
>>> sense if I think of func (x) foo(y) {} as being an alternate way of writing
>>> func foo(x, y) {}. In that case, it's clear that a copy of x is being
>>> passed since that's Go's default.
>>>
>>> While this topic is still alive, I'd like to ask a follow-on question:
>>> Is the use of sync/atomic actually needed in this example or is it
>>> sufficient to wrap all accesses in mutex Lock/Unlock (using the same mutex,
>>> of course).
>>>
>>>
>>>
>>> On Sunday, April 14, 2019 at 12:08:55 PM UTC-4, Skip wrote:

 The receiver for load and update should be the original object not a
 copy.

 https://play.golang.org/p/XCZC0OVhGMa

 On Sun, Apr 14, 2019, 7:56 AM  wrote:

>
> https://play.golang.org/p/6aQYNjojyBD
>
> I'm clearly missing something about the way sync.Mutex and
> atomic.Value work in Go.
>
> I'm attempting to write a pair of concurrency safe methods, load() and
> update(), for accessing a struct.  The struct is stored as an atomic.Value
> and accessed with atomic.Load and atomic.Value.  I'm also wrapping the
> accesses within a mutex Lock/Unlock.  That's probably unneeded for my
> load() method but I added it trying to figure out why it's not returning
> updated info. In my minimal example below (also in the Go Playground link
> above) the output of main() should be:
>
> s={65535}
> v={65535}
>
> but I get
>
> s={65535}
> v={0}
>
> indicating that the updated value is not available after the call to
> update().
>
> The only thing I'm doing that's a little different from the examples
> in the doc for sync/atomic is passing a function that takes a pointer to a
> struct instance to my update function. I do that to make it easy to write
> code that updates just a few items in the state struct (which in my real
> application has many members instead of just one as shown here.)
>
> Apologies for wasting the group's time if I've overlooked a brain-dead
> error, but I've been fooling with this for several hours now and can't see
> why it shouldn't be working,
>
>
> package main
>
> import (
> "fmt"
> "sync"
> "sync/atomic"
> )
>
> type state struct {
> R4000 uint16
> }
> type guardedState struct {
> v atomic.Value
> }
>
> var stateMutex = sync.Mutex{}
> var gState guardedState
>
> func init() {
> gState.v.Store(state{})
> }
>
> func (g guardedState) load() state {
> stateMutex.Lock()
> defer stateMutex.Unlock()
> s := gState.v.Load()
> return s.(state)
> }
>
> func (g guardedState) update(f func(*state)) {
> stateMutex.Lock()
> defer stateMutex.Unlock()
> s := g.v.Load().(state)
> f()
> g.v.Store(s)
> }
>
> func main() {
> f := func(s *state) {
> s.R4000 = 65535
> fmt.Printf("s=%v\n", *s)
> }
> gState.update(f)
> v := gState.load()
> fmt.Printf("v=%v\n", v)
> }
>
> --
> 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 golan...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
 --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails 

Re: [go-nuts] Concurrency safe struct access

[Skip Tavakkolian]

I don't know if it's documented or not.  In the language reference you can
see the rules for method calls:

https://golang.org/ref/spec#Calls
https://golang.org/ref/spec#Method_sets

A hint might have been that object should have mutated, but it didn't.
It's in a class of errors that becomes recognizable once you've been bitten
by it.

In the example you gave, use of mutex seems redundant to me; execution of
func passed into update is already guarded by atomic.

On Sun, Apr 14, 2019 at 9:51 AM  wrote:

> Thanks, Skip. That fixes it. Is the need for a pointer receiver documented
> somewhere? It's not something that even crossed my mind given that the
> neither the compiler nor golint complained.  I suppose it makes sense if I
> think of func (x) foo(y) {} as being an alternate way of writing func
> foo(x, y) {}. In that case, it's clear that a copy of x is being passed
> since that's Go's default.
>
> While this topic is still alive, I'd like to ask a follow-on question: Is
> the use of sync/atomic actually needed in this example or is it sufficient
> to wrap all accesses in mutex Lock/Unlock (using the same mutex, of course).
>
>
>
> On Sunday, April 14, 2019 at 12:08:55 PM UTC-4, Skip wrote:
>>
>> The receiver for load and update should be the original object not a copy.
>>
>> https://play.golang.org/p/XCZC0OVhGMa
>>
>> On Sun, Apr 14, 2019, 7:56 AM  wrote:
>>
>>>
>>> https://play.golang.org/p/6aQYNjojyBD
>>>
>>> I'm clearly missing something about the way sync.Mutex and atomic.Value
>>> work in Go.
>>>
>>> I'm attempting to write a pair of concurrency safe methods, load() and
>>> update(), for accessing a struct.  The struct is stored as an atomic.Value
>>> and accessed with atomic.Load and atomic.Value.  I'm also wrapping the
>>> accesses within a mutex Lock/Unlock.  That's probably unneeded for my
>>> load() method but I added it trying to figure out why it's not returning
>>> updated info. In my minimal example below (also in the Go Playground link
>>> above) the output of main() should be:
>>>
>>> s={65535}
>>> v={65535}
>>>
>>> but I get
>>>
>>> s={65535}
>>> v={0}
>>>
>>> indicating that the updated value is not available after the call to
>>> update().
>>>
>>> The only thing I'm doing that's a little different from the examples in
>>> the doc for sync/atomic is passing a function that takes a pointer to a
>>> struct instance to my update function. I do that to make it easy to write
>>> code that updates just a few items in the state struct (which in my real
>>> application has many members instead of just one as shown here.)
>>>
>>> Apologies for wasting the group's time if I've overlooked a brain-dead
>>> error, but I've been fooling with this for several hours now and can't see
>>> why it shouldn't be working,
>>>
>>>
>>> package main
>>>
>>> import (
>>> "fmt"
>>> "sync"
>>> "sync/atomic"
>>> )
>>>
>>> type state struct {
>>> R4000 uint16
>>> }
>>> type guardedState struct {
>>> v atomic.Value
>>> }
>>>
>>> var stateMutex = sync.Mutex{}
>>> var gState guardedState
>>>
>>> func init() {
>>> gState.v.Store(state{})
>>> }
>>>
>>> func (g guardedState) load() state {
>>> stateMutex.Lock()
>>> defer stateMutex.Unlock()
>>> s := gState.v.Load()
>>> return s.(state)
>>> }
>>>
>>> func (g guardedState) update(f func(*state)) {
>>> stateMutex.Lock()
>>> defer stateMutex.Unlock()
>>> s := g.v.Load().(state)
>>> f()
>>> g.v.Store(s)
>>> }
>>>
>>> func main() {
>>> f := func(s *state) {
>>> s.R4000 = 65535
>>> fmt.Printf("s=%v\n", *s)
>>> }
>>> gState.update(f)
>>> v := gState.load()
>>> fmt.Printf("v=%v\n", v)
>>> }
>>>
>>> --
>>> 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 golan...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Producer-Consumer with Goroutines

[Skip Tavakkolian]

if the intent is to "print" the producer's output before the consumer's,
then this example still can't guarantee it; for example:
https://play.golang.org/p/2sb67Qf5IPd

the only synchronization guarantee is the moment of exchange on the channel.

On Fri, Jan 25, 2019 at 3:27 AM Wagner Riffel  wrote:

> maybe it's the way you approached the problem, here is a perhaps cleaner
> way to achieve desired output, https://play.golang.org/p/3a4lxbjdQAr
>
> BR.
>
> On Thu, Jan 24, 2019 at 7:12 PM diego patricio  wrote:
>
>> Hi all, i'am just learning Go and goroutines, I have three goroutines
>> (main, producer, consumer) and I dont know how synchronize producer and
>> consumer for print one value at time, the output that I want is
>>
>> Producer 0
>> Consumer 0
>> Producer 1
>> Consumer 1
>> ..
>> but the output of my program it's diferent.
>>
>> the program:
>>
>> [image: image.png]
>>
>> The output:
>>
>> [image: image.png]
>>
>> Sorry about my english
>>
>> Regards
>>
>> --
>> 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.com/d/optout.
>>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Channels: selecting the last element

[Skip Tavakkolian]

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)
done := 0
dc := make(chan bool, worker)
for i := 0; i < worker; i++ {
go do(i, rc, dc)
}
for done < worker {
r := <-rc
fmt.Println(r)
<-dc
done++
}
}


On Tue, Dec 18, 2018 at 5: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
> sometimes misses to select the last result. What would be the idiomatic way
> to prevent this and completely drain the result channel?
>
> Here is a minmal example which sometimes prints one 0 but should always
> print two of them:
>
> package main
>
> import (
> "fmt"
> )
>
> func do(rc chan<- int, dc chan<- bool) {
> rc <- 0
> dc <- true
> }
>
> func main() {
> worker := 2
> rc := make(chan int, worker)
> done := 0
> dc := make(chan bool, worker)
> for i := 0; i < worker; i++ {
> go do(rc, dc)
> }
> for done < worker {
> select {
> case <-dc:
> done++
> case r := <-rc:
> fmt.Println(r)
> }
> }
> }
>
> many thanks
> Chris
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] invalid recursive type alias

[Skip Tavakkolian]

I think in the second case it is a reasonable error because the type alias
has not been defined yet while the anonymous struct is being declared.

On Sat, Dec 8, 2018, 9:33 AM Jan Mercl <0xj...@gmail.com wrote:

> This code compiles fine
>
> package main
>
> type node struct {
> next *node
> }
>
> func main() {}
>
> (https://play.golang.org/p/ZYg0EciQnOQ)
>
> This code does not
>
> package main
>
> type node = struct {
> next *node
> }
>
> func main() {}
>
> (https://play.golang.org/p/gWWX8ngPsS6)
>
> The error is
>
> prog.go:3:6: invalid recursive type alias node
> prog.go:3:6: node uses 
> prog.go:3:13:  uses node
>
> The specification remains silent about what is considered "invalid
> recursive type alias" so I'm not sure, but it seems to me the first and
> second programs should both compile fine. In both cases, so to say "the
> pointer breaks the cycle" while type checking. But maybe/probably I'm
> mistaken.
>
> Can anybody enlighten me please and explain if the compiler is right or if
> it's a bug?
>
> Thanks in advance.
>
> --
>
> -j
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] websocket implentation in golang

[Skip Tavakkolian]

Here's a sketch:

https://gist.github.com/9nut/11052587


On Wed, Oct 24, 2018 at 4:20 AM sakthi apr  wrote:

> Hi,
>
> I'm developing web socket in golang that checks the database changes like
> new data insert.
>
> if the new record added in table user will get notified at client side.
>
> Anyone have idea plz share with me.
>
>
> Thanks
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Cross-compiled program for Raspberry Pi crashes

[Skip Tavakkolian]

Rpi1 model B requires setting GOARM=5 I believe.

On Sun, Aug 12, 2018, 8:29 AM Stephan Mühlstrasser <
stephan.muehlstras...@gmail.com> wrote:

> Hi,
>
> I'm developing my first Go program that is supposed to upload files into a
> Google Cloud Storage bucket from a Raspberry Pi 1. It uses the
> https://github.com/blackjack/webcam library to grab a picture from an USB
> camera.
>
> I can compile the program on the Raspberry Pi itself with Go 1.7.4 that
> comes with Raspbian, and then it works as expected. However compilation on
> the Raspberry Pi is slow and it even sometimes fails because of memory
> shortage. Therefore I want to cross-compile on Windows.
>
> When I cross-compile the exact same source on Windows for ARM with Go
> 1.10.3, then this binary crashes at some point on the Raspberry Pi with a
> segmentation fault:
>
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x4 pc=0x11520]
>
>
> goroutine 8 [running]:
> sync/atomic.addUint64(0x1236210c, 0x8a75f371, 0xa3f9cbd6, 0xdcd30e9,
> 0xda39e1c1)
> C:/Go/src/sync/atomic/64bit_arm.go:31 +0x4c
> go.opencensus.io/trace.(*defaultIDGenerator).NewSpanID(0x123620f0, 0x0,
> 0x0)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:483 +0x50
> go.opencensus.io/trace.startSpanInternal(0x123202d0, 0x22, 0x0, 0x0, 0x0,
> 0x0, 0x0, 0x0, 0x0, 0x0, ...)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:196 +0x7c
> go.opencensus.io/trace.StartSpan(0x4c4128, 0x12795c60, 0x123202d0, 0x22,
> 0x123798ec, 0x2, 0x2, 0x10, 0x40, 0x58f74)
> E:/Users/stm/go/src/go.opencensus.io/trace/trace.go:162 +0x128
> ...
>
> I'm a Go newbie, and therefore I'm not sure how to interpret this. May
> this be a bug in the Go cross-compiler, or may this be a bug in the program
> that only manifests itself when the program is cross-compiled with the
> newer compiler on Windows?  How can I analyze this?
>
> Thanks
> Stephan
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Re: Nil Channels and Case Evaluation

[Skip Tavakkolian]

i think the compiler has identified both problems correctly; c is nil (no
cases) and nothing is receiving from c (deadlock).

package main

func main() {
// var c chan struct{}
c := make(chan struct{})
go func(x chan struct{}) { <-x }(c)
select {
case c <- f():
}
}

func f() struct{} {
println("f called")
return struct{}{}
}


On Wed, Aug 8, 2018 at 12:40 AM Kaveh Shahbazian 
wrote:

> According to this thread, for this program:
>
> package main
>
> func main() {
> var c chan struct{}
>
> select {
> case c <- f():
> }
> }
>
>
> func f() struct{} {
> println("f called")
> return struct{}{}
> }
>
> The error message in the output:
>
> f called
> fatal error: all goroutines are asleep - deadlock!
>
> goroutine 1 [select (no cases)]:
> main.main()
> /path/to/main.go:6 +0x45
>
> Is a bit unclear since it says *select (no cases)* but the function *f*
> is still being called - Go 1.10.3.
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Re: pet peeve: it's Go not golang

[Skip Tavakkolian]

Erlang is assumed to be a node to the Danish mathematician Erlang, an
important figure in telephony queuing theory.

On Sun, Jul 30, 2017, 9:10 PM simran  wrote:

> Er?
>
> sorry, couldn't help myself :)
>
> Go Go!
>
>
>
> On Mon, Jul 31, 2017 12:24 PM, Dave Cheney d...@cheney.net wrote:
>
>> Golang helps much, when searching for Go related programming issues all
>> over the internet
>>
>>
>> Skip's point, which I heartily support, is here, on this forum, there is
>> little ambiguity what people refer to when they talk about the programming
>> language called Go.
>>
>> --
>> 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.com/d/optout.
>>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

Re: [go-nuts] Re: pet peeve: it's Go not golang

[Skip Tavakkolian]

I was specifically referring to things posted to this list to avoid the old
chestnut about search.

For what it's worth, I don't buy that argument either. Searching for "game
of life in go language" works just as well. Correctness matters even when
nobody is looking.

On Tue, Jul 25, 2017, 2:47 PM  wrote:

> Yes, the language name is Go, but sometimes real life matters.
>
> Imagine I want to search for a Go implementation of Conway's Game of Life,
> but I don't quite remember the game name, so I search for:
>
> go game life
>
> Nothing. Otherwise, if I search for
>
> golang game life
>
> I get plenty of entries directly related to what I was looking for. Ditto
> for Google, Bing and Yahoo.
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

[go-nuts] pet peeve: it's Go not golang

[Skip Tavakkolian]

Although "go" is a verb, an adjective and a noun (including the game),
there shouldn't be any confusion in what Go is, when posting to a list
dedicated to the language.

Thanks,
-Skip

-- 
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.com/d/optout.

Re: [go-nuts] 9fans.net/go

[Skip Tavakkolian]

It's not abandoned; it's resting :)


On Sun, Feb 19, 2017 at 10:08 AM Dave MacFarlane <driu...@gmail.com> wrote:

> Sure, but I'm not the one using plan9/client: plumb.Open is. So in
> order to do it and keep supporting p9p, I still need to fork
> 9fans.net/go and vendor my changes to the plumb package, which brings
> me back to where I started: needing to maintain my own fork of a
> seemingly abandoned package.
>
> (I just tried directly opening /mnt/plumb/edit behind a build tag in
> the plumb package and returning the *os.File, and it does mostly work
> except for the same problem of *os.File not implementing
> io.ByteReader, and the fact that now the same function on different
> platforms has different signatures, because the default plumb.Open is
> defined as returning a concrete type from plan9/client, not an
> interface..)
>
> On Sun, Feb 19, 2017 at 9:43 AM, Skip Tavakkolian
> <skip.tavakkol...@gmail.com> wrote:
> > if want to run those utilities in Plan 9 you don't need to worry about
> > speaking 9P with the underlying services  -- i.e.  no need for
> plan9/client
> > package. the file hierarchies for plumber, acme, draw, etc. are mounted
> into
> > the process' namespace. for example, acme's namespace is mounted on
> > "/mnt/acme"; so a program that is started by acme will use normal
> > open/read/write/close to interact with acme.  that's the beauty of Plan
> 9.
> >
> > the middle-layer packages (i.e. acme, plumb, draw) should use
> os.OpenFile,
> > File.Read/Write, etc.
> > for example: acme.New() can be modified like this
> >
> > // New creates a new window.
> > func New() (*Win, error) {
> > fid, err := os.OpenFile("/mnt/acme/new/ctl", os.O_RDWR)
> > if err != nil {
> > return nil, err
> > }
> > buf := make([]byte, 100)
> > n, err := fid.Read(buf)
> > if err != nil {
> > fid.Close()
> > return nil, err
> > }
> > a := strings.Fields(string(buf[0:n]))
> > if len(a) == 0 {
> > fid.Close()
> > return nil, errors.New("short read from acme/new/ctl")
> > }
> > id, err := strconv.Atoi(a[0])
> > if err != nil {
> > fid.Close()
> > return nil, errors.New("invalid window id in acme/new/ctl: " + a[0])
> > }
> > return Open(id, fid)
> > }
> >
> > etc.
> >
> >
> >
> >
> > On Sat, Feb 18, 2017 at 3:51 PM Dave MacFarlane <driu...@gmail.com>
> wrote:
> >>
> >> client doesn't implement ReadByte, and opening a plumbing port with
> >> 9fans.net/go/plumb9fans/net/go/plumb needs a ByteReader is the change
> >> that I've been vendoring for other OSes to be able to open the "edit"
> >> port of the plumber.
> >>
> >> The problem that I'm having now isn't that it doesn't build, it's that
> >> "plumb.Open("edit", plan9.OREAD)" returns an error right away on Plan
> >> 9 because DialService is assuming it's for p9p trying to emulate
> >> namespaces with Unix Domain Sockets. I'm sure it's fixable, but the
> >> repo seems to be abandoned (pull requests have been open since 2015),
> >> so I'm wondering if there's any other packages that deal with the
> >> plumbing ports (because otherwise I think my only option is to fork it
> >> and maintain it myself..)
> >>
> >>
> >> On Sat, Feb 18, 2017 at 10:57 PM, Bakul Shah <ba...@bitblocks.com>
> wrote:
> >> > On Sat, 18 Feb 2017 21:42:05 GMT Dave MacFarlane <driu...@gmail.com>
> >> > wrote:
> >> >> Are there any cross-platform alternatives to 9fans.net/go for
> >> >> interacting with the Plan9/p9p plumber?
> >> >
> >> > I think you will have to create os specific versions of
> >> > 9fans.net/go/plan9/client/dial.go:Namespace()
> >> >
> >> >> It doesn't seem to be maintained (I've had to vendor a bug fix for a
> >> >> while to use it to receive plumbing messages) and I just discovered
> >> >> while trying to use my de text editor on Plan 9 that, ironically,
> >> >> 9fans.net/go doesn't work under Plan 9, either..
> >> >
> >> > I know go/acme/Watch doesn't build. Are there others (modulo
> >> > the above issue)?  There may be other ways to handle Watch
> >>
> >>
> >>
> >> --
> >> - Dave
> >>
> >> --
> >> 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.com/d/optout.
>
>
>
> --
> - Dave
>

-- 
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.com/d/optout.

Re: [go-nuts] 9fans.net/go

[Skip Tavakkolian]

if want to run those utilities in Plan 9 you don't need to worry about
speaking 9P with the underlying services  -- i.e.  no need for plan9/client
package. the file hierarchies for plumber, acme, draw, etc. are mounted
into the process' namespace. for example, acme's namespace is mounted on
"/mnt/acme"; so a program that is started by acme will use normal
open/read/write/close to interact with acme.  that's the beauty of Plan 9.

the middle-layer packages (i.e. acme, plumb, draw) should use os.OpenFile,
File.Read/Write, etc.
for example: acme.New() can be modified like this

// New creates a new window.
func New() (*Win, error) {
fid, err := os.OpenFile("/mnt/acme/new/ctl", os.O_RDWR)
if err != nil {
return nil, err
}
buf := make([]byte, 100)
n, err := fid.Read(buf)
if err != nil {
fid.Close()
return nil, err
}
a := strings.Fields(string(buf[0:n]))
if len(a) == 0 {
fid.Close()
return nil, errors.New("short read from acme/new/ctl")
}
id, err := strconv.Atoi(a[0])
if err != nil {
fid.Close()
return nil, errors.New("invalid window id in acme/new/ctl: " + a[0])
}
return Open(id, fid)
}

etc.




On Sat, Feb 18, 2017 at 3:51 PM Dave MacFarlane  wrote:

> client doesn't implement ReadByte, and opening a plumbing port with
> 9fans.net/go/plumb9fans/net/go/plumb needs a ByteReader is the change
> that I've been vendoring for other OSes to be able to open the "edit"
> port of the plumber.
>
> The problem that I'm having now isn't that it doesn't build, it's that
> "plumb.Open("edit", plan9.OREAD)" returns an error right away on Plan
> 9 because DialService is assuming it's for p9p trying to emulate
> namespaces with Unix Domain Sockets. I'm sure it's fixable, but the
> repo seems to be abandoned (pull requests have been open since 2015),
> so I'm wondering if there's any other packages that deal with the
> plumbing ports (because otherwise I think my only option is to fork it
> and maintain it myself..)
>
>
> On Sat, Feb 18, 2017 at 10:57 PM, Bakul Shah  wrote:
> > On Sat, 18 Feb 2017 21:42:05 GMT Dave MacFarlane 
> wrote:
> >> Are there any cross-platform alternatives to 9fans.net/go for
> >> interacting with the Plan9/p9p plumber?
> >
> > I think you will have to create os specific versions of
> > 9fans.net/go/plan9/client/dial.go:Namespace()
> >
> >> It doesn't seem to be maintained (I've had to vendor a bug fix for a
> >> while to use it to receive plumbing messages) and I just discovered
> >> while trying to use my de text editor on Plan 9 that, ironically,
> >> 9fans.net/go doesn't work under Plan 9, either..
> >
> > I know go/acme/Watch doesn't build. Are there others (modulo
> > the above issue)?  There may be other ways to handle Watch
>
>
>
> --
> - Dave
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.

[go-nuts] looking for example of CloseRead in production code

[Skip Tavakkolian]

Does anyone have a pointer to production code that uses CloseRead or
CloseWrite (TCPConn or UnixConn)?  I am aware of the net/http test cases.

Thanks,
-Skip

-- 
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.com/d/optout.

Re: [go-nuts] First tutorials for iranian users

[Skip Tavakkolian]

Hi Erfan,

This is cool!  I skimmed through the videos.  I think the videos are great
for students learning Go as their first language.

I read the intro page, and I think your reasons for "a bright future for
Go" are reasonable but somewhat subjective. I think it would be useful to
include why Go was created in the first place:
https://golang.org/doc/faq#creating_a_new_language ; for experienced
programmers those are good reasons for learning and using Go.

-Skip (Fariborz)




On Sun, Aug 28, 2016 at 12:05 PM  wrote:

> Hello gophers
> After 5 years experience working with Go, i decided to record educational
> videos for iranian users which can't learn go simply
> I'm an iranian and i know iranian users need to be trained
> In the past years, i didn't see any significant training for Go in iran,
> Actually nothing
> Now i start record videos about go programming (Basic, Advanced, Useful)
> At the moment i put all of my videos in the Daneshjooyar.com [Largest
> Educational Videos Company in IRAN]
> today i put 5 videos in this website , you can access that by open this
> url : goo.gl/wQKrmU
> In coming days other videos will be released
>
> and source code of each session is on github.com/icoolboy/startgolang
>
> Good Luck- Erfan Akbarimanesh [CoolBoy]
>
> --
> 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.com/d/optout.
>

-- 
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.com/d/optout.