Re: [go-nuts] Fast ConcurrentCounter without memory sharing

[Gaurav Agarwal]

Ian, thanks for the explanation and the link !

But I am still unclear how to implement such a concurrent counter in Go -
given that we can't find out what thread/cpu is the goroutine executing.
Note that in this case there was never the need of pinning a goroutine to a
thread or cpu; just that we wanted to know which is it, at any given moment
so as to access the required memory location.

Do you have any alternate ideas for this?

On Sun, Aug 14, 2016 at 10:18 PM, Ian Lance Taylor  wrote:

> On Sun, Aug 14, 2016 at 2:25 AM, gaurav  wrote:
> >
> > How do I get to know the Thread (or CpuCore) id on which the goroutine is
> > running?
>
> Go does not expose this information.  In Go it's also unreliable
> because the language makes no guarantees about when a goroutine may
> move from one thread, or CPU, to another.
>
> > In the get() call of this counter, I need to sum up array values; how
> does
> > one ensure that the  latest values written to the array are visible to
> the
> > goroutine calling the get() method? Are the values written using atomic
> > package made visible to all cores immediately? Or else, does
> > atomic.LoadInt32()guarantee to return the latest values? I think the
> problem
> > is that atomic package does not say anything about visibility of memory
> > updates across cores.
>
> The lack of documentation is https://golang.org/issue/5045.  It's not
> the case that values written are visible to all cores for ordinary
> memory access, but they are visible if you use atomic.LoadNN.  What is
> unclear is what that says about other memory writes, but I think the
> current implementation, and all plausible future implementations,
> treat Store as a store-release and treat Load as a load-acquire.
>
> Ian
>

-- 
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] runtime.Caller ->

['Tim Hockin' via golang-nuts]

I was playing with a method that wants to print the file:line of the
caller.  `runtime.Caller(1)` seems like it should do the trick, but I
get ':2'.  If I call `runtime.Caller(2)` instead it
seems to work, but I don't know why, so I am reluctant to depend on
that.

Can anyone enlighten me?  How can I know how many frames to crawl back
to my real caller?

go1.6.1 on linux/amd64

-- 
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] Re: Wxwidgets ， Best GUI package for Golang！

[unxeds]

https://github.com/dontpanic92/wxGo


-- 
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] runtime.Caller ->

[Ian Lance Taylor]

On Sun, Aug 14, 2016 at 11:10 AM, 'Tim Hockin' via golang-nuts
 wrote:
> I was playing with a method that wants to print the file:line of the
> caller.  `runtime.Caller(1)` seems like it should do the trick, but I
> get ':2'.  If I call `runtime.Caller(2)` instead it
> seems to work, but I don't know why, so I am reluctant to depend on
> that.
>
> Can anyone enlighten me?  How can I know how many frames to crawl back
> to my real caller?
>
> go1.6.1 on linux/amd64

An `autogenerated` frame means that you are calling a method that is
defined on some type T1 that is embedded in some other type T2.  The
`autogenerated` code is the little wrapper that takes a value of type
T2 and invokes the method on the embedded field of type T1.  As far as
I know you will never see autogenerated code called by autogenerated
code.  So you only need to worry about this in a method of a type that
your program will embed into some other type.  If you don't know at
run time whether the type is embedded or not, call runtime.Caller(1),
and if you see autogenerated call runtime.Caller(2).

Ian

-- 
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] Fast ConcurrentCounter without memory sharing

[John Souvestre]

Hello Gaurav.

You might want to look at Jon Gjengset's project: 
https://github.com/jonhoo/drwmutex

Also, I seem to recall Dmitry saying that sync.Pool distributes locking.  So it 
might be worth looking into.

Another type of lock which might be of interest is MCS (or K42, CLH, HCLH).

John

John Souvestre - New Orleans LA

-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Ian Lance Taylor
Sent: 2016 August 14, Sun 14:21
To: Gaurav Agarwal
Cc: golang-nuts
Subject: Re: [go-nuts] Fast ConcurrentCounter without memory sharing

On Sun, Aug 14, 2016 at 9:58 AM, Gaurav Agarwal
 wrote:
> Ian, thanks for the explanation and the link !
>
> But I am still unclear how to implement such a concurrent counter in Go -
> given that we can't find out what thread/cpu is the goroutine executing.
> Note that in this case there was never the need of pinning a goroutine to a
> thread or cpu; just that we wanted to know which is it, at any given moment
> so as to access the required memory location.
>
> Do you have any alternate ideas for this?

I think the last time a similar though not identical concept was
discussed was this thread:

https://groups.google.com/d/msg/golang-nuts/zt_CQssHw4M/TteNG44geaEJ

It would be interesting to know what the potential speedup is.  It
should be easy enough to write a C program to measure that.  But when
writing such a program, remember that no real program will simply
increment a concurrent counter.  The question is not just how much
speedup you can get from a concurrent counter, but how much it will
matter to a real program.

Anyhow, that aside, if you know how many goroutines you are going to
run, just allocate a slice with that many elements.  If you don't, use
a set of fixed size arrays and have each goroutine grab a pointer to a
possibly-new array when it starts.  Pass down the pointer.

If these approaches seem awkward, I suppose you could get
syscall(syscall.GETCPU, ...) when you want to increment a counter.
But that would admittedly introduce overhead that would distort the
results.

We do not plan to modify the Go runtime to expose a thread or CPU ID,
because although it's true that your application doesn't care much if
the value becomes immediately stale, other applications would care.
It seems unwise to expose a value that is extremely easy to misuse in
a way that will often succeed and occasionally and inexplicably fail.

Ian

-- 
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] Re: Cast interface{} to []string

['simon place' via golang-nuts]

could something like this help; https://play.golang.org/p/9tbiUY1w0d


On Friday, 12 August 2016 19:41:26 UTC+1, Vasily Korytov wrote:
>
> Hi,
>
> I have an interface{} variable that can be either string or a list of 
> string (yes, that's bad design, I know).
>
> I need a []string to feed it to strings.Join (I need one string for 
> output).
>
> This way works, that is explicitly creating []string and copying each 
> element to it:
>
> var list []string
> for _, v := range mail.([]interface{}) {
> list = append(list, v.(string))
> }
> rcpt = strings.Join(list, ", ")
>
> Have I overlooked something and there is a way to do it in a more graceful 
> and effective way?
>
> Thanks.
>
> -- 
>   Vasily Korytov
>   https://chillum.github.io
>

-- 
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] [ANN] gopkg.in/gcfg.v1 : gcfg v1.2.0 released

[speter . go1]

Gcfg reads "INI-style" text-based configuration files with "name=value" 
pairs grouped into sections (gcfg files).

A lot has been happening to gcfg since my previous announcement. Most 
notably, the project has moved from Google Code:

gopkg.in/gcfg.v1
https://godoc.org/gopkg.in/gcfg.v1
https://github.com/go-gcfg/gcfg/issues
https://github.com/go-gcfg/gcfg/pulls

New features:

experimental (feature/user_vars branch):
- Sections with user-supplied variables (like in git's [alias] section)

v1.2.0:
- Ability to ignore errors due to extra configuration data. This feature is 
enabled by the new gopkg.in/warnings.v0 package which I intend to announce 
shortly (need some more docs).

v1.1.0:
- Ability to specify default values for subsections

v1.0.0 and earlier:
- Create entries for empty subsections
- "Blank" value for multi-valued vars (slices) resets preset values
- Support pointer to slice (allow distinguishing between no values and 
blank value for slice)
- Support for big.Int
- Configurable parsing of int values (Dec and Hex only by default)
- Support for names starting with unicode letters that are neither upper or 
lower case
- Support for encoding/TextUnmarshaler

Thanks to everyone who has provided feedback!

-- 
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] runtime.Caller ->

['Tim Hockin' via golang-nuts]

It is, in fact, a method on an embedded type.  That means I can document it
and it ceases to be a magic number!  Thanks.

On Aug 14, 2016 12:27 PM, "Ian Lance Taylor"  wrote:

> On Sun, Aug 14, 2016 at 11:10 AM, 'Tim Hockin' via golang-nuts
>  wrote:
> > I was playing with a method that wants to print the file:line of the
> > caller.  `runtime.Caller(1)` seems like it should do the trick, but I
> > get ':2'.  If I call `runtime.Caller(2)` instead it
> > seems to work, but I don't know why, so I am reluctant to depend on
> > that.
> >
> > Can anyone enlighten me?  How can I know how many frames to crawl back
> > to my real caller?
> >
> > go1.6.1 on linux/amd64
>
> An `autogenerated` frame means that you are calling a method that is
> defined on some type T1 that is embedded in some other type T2.  The
> `autogenerated` code is the little wrapper that takes a value of type
> T2 and invokes the method on the embedded field of type T1.  As far as
> I know you will never see autogenerated code called by autogenerated
> code.  So you only need to worry about this in a method of a type that
> your program will embed into some other type.  If you don't know at
> run time whether the type is embedded or not, call runtime.Caller(1),
> and if you see autogenerated call runtime.Caller(2).
>
> Ian
>

-- 
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] runtime.Caller ->

['Tim Hockin' via golang-nuts]

Edit:  It looks like this has more to do with being an interface
method than an embedded type.

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

Is there a generic way to get the caller safely, or should I just
check for  and increment?

On Sun, Aug 14, 2016 at 3:02 PM, Tim Hockin  wrote:
> It is, in fact, a method on an embedded type.  That means I can document it
> and it ceases to be a magic number!  Thanks.
>
>
> On Aug 14, 2016 12:27 PM, "Ian Lance Taylor"  wrote:
>>
>> On Sun, Aug 14, 2016 at 11:10 AM, 'Tim Hockin' via golang-nuts
>>  wrote:
>> > I was playing with a method that wants to print the file:line of the
>> > caller.  `runtime.Caller(1)` seems like it should do the trick, but I
>> > get ':2'.  If I call `runtime.Caller(2)` instead it
>> > seems to work, but I don't know why, so I am reluctant to depend on
>> > that.
>> >
>> > Can anyone enlighten me?  How can I know how many frames to crawl back
>> > to my real caller?
>> >
>> > go1.6.1 on linux/amd64
>>
>> An `autogenerated` frame means that you are calling a method that is
>> defined on some type T1 that is embedded in some other type T2.  The
>> `autogenerated` code is the little wrapper that takes a value of type
>> T2 and invokes the method on the embedded field of type T1.  As far as
>> I know you will never see autogenerated code called by autogenerated
>> code.  So you only need to worry about this in a method of a type that
>> your program will embed into some other type.  If you don't know at
>> run time whether the type is embedded or not, call runtime.Caller(1),
>> and if you see autogenerated call runtime.Caller(2).
>>
>> Ian

-- 
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] Who Loves Go?

[Matt Harden]

I love it!

On Sun, Aug 14, 2016 at 7:01 PM Kevin Malachowski 
wrote:

> I do!
>
> --
> 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] Fast ConcurrentCounter without memory sharing

[Ian Lance Taylor]

On Sun, Aug 14, 2016 at 2:49 PM, Nigel Tao  wrote:
> On Aug 15, 2016 05:21, "Ian Lance Taylor"  wrote:
>> If these approaches seem awkward, I suppose you could get
>> syscall(syscall.GETCPU, ...) when you want to increment a counter.
>
> That still seems racy:
>
> n := syscall(syscall.GETCPU, ...)
> // The goroutine could be re-scheduled here to another CPU, between these
> two lines, so n is out of date.
> array[n]++ // read/writes wrong n, non-atomically.

Yes, you do need to use an atomic add.  But the point is that in the
normal case that particular memory location will only be accessed from
a single CPU, and as such it should be faster than having all the CPUs
access a single shared counter.

Ian

-- 
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] Who Loves Go?

[Dorival Pedroso]

Hello Everyone,

I'm preparing a list of people / companies that use Go and *really like Go*.

The plan is to present this to a large crowd of undergraduate students (and 
others).

So, suggestions are very welcome!

Many thanks.
Dorival

-- 
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] Bug: gomobile on iOS 10 crashes after app is suspended+resumed

[Steve]

Hi all,

I've found a reproducible crash of gomobile on iOS 10 using 1.7 rc6 (this 
isn't the time system call issue).

I'm happy to submit a detailed bug report, but I wasn't sure if this issue 
already being tracked, and didn't want to duplicate another bug.

Short description: a framework generated by gomobile loads and runs fine, 
until the app suspends and resumed (to do this you need to hit the home 
button and wait 7+ minutes, then tap the app icon again). When resuming, I 
get a crash (stack trace is the start of a new thread, "notok: 
exc_bad_access"). This does not repro on the simulator, or iOS 9.

Is this already being tracked, or should I file a bug?

Thanks,
Steve

-- 
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] Bug: gomobile on iOS 10 crashes after app is suspended+resumed

[Dave Cheney]

Please file a bug. 

-- 
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] runtime.Caller ->

['Tim Hockin' via golang-nuts]

On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  wrote:
> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  wrote:
>> Edit:  It looks like this has more to do with being an interface
>> method than an embedded type.
>>
>> https://play.golang.org/p/I5XPdWR_O0
>
> Hmmm, you're right.  It only happens for a value method.

Is this likely to change? I.e. can I hardcode "2" or should I actually
write the loop to climb frames?  Is there a limit to the number of
frames I should inspect before I give up?  Is the string
"" stable?

>> Is there a generic way to get the caller safely, or should I just
>> check for  and increment?
>
> I think that is what you should do here.
>
> Ian

-- 
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] runtime.Caller ->

[Dave Cheney]

The autogenerated miranda method only happens if you are calling through an 
interface method that is provided by an embedded type. If you're doing 
something like

func log(...) {
pc := runtime.Callers(1) // get the caller of log
}

It shouldn't be a problem.

On Monday, 15 August 2016 14:42:14 UTC+10, Tim Hockin wrote:
>
> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor  > wrote: 
> > On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin  > wrote: 
> >> Edit:  It looks like this has more to do with being an interface 
> >> method than an embedded type. 
> >> 
> >> https://play.golang.org/p/I5XPdWR_O0 
> > 
> > Hmmm, you're right.  It only happens for a value method. 
>
> Is this likely to change? I.e. can I hardcode "2" or should I actually 
> write the loop to climb frames?  Is there a limit to the number of 
> frames I should inspect before I give up?  Is the string 
> "" stable? 
>
> >> Is there a generic way to get the caller safely, or should I just 
> >> check for  and increment? 
> > 
> > I think that is what you should do here. 
> > 
> > Ian 
>

-- 
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] Re: Wxwidgets ， Best GUI package for Golang！

[Peter Howard]

This shows how to make a standalone gui program with Go that uses html5 and 
Bootstrap css, but with all the resources compiled into the Go executable.

https://github.com/peterhoward42/godesktopgui

-- 
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] Re: Closures vs structs with embedded functions (I call 'em pseudo-closures)

[xiiophen]

On Saturday, 13 August 2016 00:57:10 UTC+1, simon place wrote:
>
> aren't your "pseudo-closure"'s commonly know as "objects"?
>
>
In languages that have "objects" (and not the structs I'm using here that 
serve the same function) the answer is yes.

Of course this is already known eg 
https://www.google.co.uk/search?q=objects%20vs%20closures 

I was interested in specifics technical to 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 from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Closures vs structs with embedded functions (I call 'em pseudo-closures)

['simon place' via golang-nuts]

aren't your "pseudo-closure"'s commonly know as "objects"?

-- 
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] keyed vs unkeyed fields

[Ian Lance Taylor]

On Fri, Aug 12, 2016 at 2:29 PM, Anmol Sethi  wrote:
> Keyed fields seem to be always better than unkeyed fields in a composite 
> literal.
> Under what circumstances would I want to use unkeyed fields?

Keys aren't always useful, e.g.,

var colors = [...]string{"red", "blue", "green", "yellow"}

Ian

-- 
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] keyed vs unkeyed fields

[Anmol Sethi]

My bad. I should have specified that I meant struct literals.

> On Aug 12, 2016, at 6:02 PM, Ian Lance Taylor  wrote:
> 
> On Fri, Aug 12, 2016 at 2:29 PM, Anmol Sethi  wrote:
>> Keyed fields seem to be always better than unkeyed fields in a composite 
>> literal.
>> Under what circumstances would I want to use unkeyed fields?
> 
> Keys aren't always useful, e.g.,
> 
> var colors = [...]string{"red", "blue", "green", "yellow"}
> 
> Ian
> 
> -- 
> 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] Re: Increase speed of repeated builds

[Dave Cheney]

Thank you for this information. There is no timing information.

On Saturday, 13 August 2016 08:01:19 UTC+10, James Pettyjohn wrote:
>
> Here we go:
>
> WORK=/var/folders/j7/4pq3fms94f16lq7sljs3gd1cgp/T/go-build579975441
> site_www2
> mkdir -p $WORK/site_www2/_obj/
> mkdir -p $WORK/site_www2/_obj/exe/
> cd /Users/jp/git/project/src/site_www2
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/site_www2.a -trimpath 
> $WORK -p main -complete -buildid 66dc2ac41b6b8158286be8a6b59f302b6ff26b19 
> -D _/Users/jp/git/project/src/site_www2 -I $WORK -I 
> /Users/jp/git/project/pkg/darwin_amd64 -pack ./activities.go 
> ./admin_handler.go ./attrs.go ./awards.go ./blockdata.go ./blocks.go 
> ./calendar.go ./combined.go ./context-editable.go ./context-funcmap.go 
> ./context-orgs.go ./context-store.go ./context.go ./data.go ./datafile.go 
> ./draft_pages_attr_manager.go ./duration.go ./email_subscribe.go 
> ./error_handler.go ./events_handler.go ./fake_attrs.go ./features.go 
> ./f-vchannel.go ./form-submitter-core.go ./form-submitter-item-data.go 
> ./form-submitter.go ./io_handler.go ./igcache.go ./event.go ./legacy.go 
> ./main.go ./a-handler.go ./menus.go ./notfound.go ./org_handler.go 
> ./profile.go ./published_pages_handler.go ./reaches_handler.go 
> ./redirects.go ./region-slideshow.go ./regions.go ./robots-txt.go ./rss.go 
> ./search.go ./security-handler.go ./server.go ./sessions.go ./sitemap.go 
> ./store-handler-r.go ./store-handler.go ./store-sessions.go ./submitter.go 
> ./tagmapper.go ./tags.go ./temp_draft_api.go ./translation-import.go 
> ./util-admin-access.go ./util.go ./video-c.go ./videos.go
> cd .
> /usr/local/go/pkg/tool/darwin_amd64/link -o $WORK/site_www2/_obj/exe/a.out 
> -L $WORK -L /Users/jp/git/project/pkg/darwin_amd64 -extld=clang 
> -buildmode=exe -buildid=66dc2ac41b6b8158286be8a6b59f302b6ff26b19 -X 
> main.CacheId=8d815e7 $WORK/site_www2.a
> mkdir -p /Users/jp/git/project/bin/
> mv $WORK/site_www2/_obj/exe/a.out /Users/jp/git/project/bin/site_www2
>
> On Thursday, August 11, 2016 at 10:47:10 PM UTC-7, Dave Cheney wrote:
>>
>> You mentioned timing your build with -x, can you please provide those 
>> details. 
>
>

-- 
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] Cast interface{} to []string

[Jesse McNelis]

On Sat, Aug 13, 2016 at 4:41 AM, Vasily Korytov  wrote:
> Hi,
>
> I have an interface{} variable that can be either string or a list of string
> (yes, that's bad design, I know).

Your code below indicates that you're storing a []interface{} not an []string.

> Have I overlooked something and there is a way to do it in a more graceful
> and effective way?

Could you instead store a []string in your interface{} instead of an
[]interface{}?

-- 
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] Need trailing comma before newline in composite literal

[pgore]

Because of this reason I started feeling it natural :D thanks Andrew 
Gerrand for pointing out.

On Friday, November 18, 2011 at 9:47:18 AM UTC+5:30, Andrew Gerrand wrote:
>
> It's not just that. It also means that you can more easily re-order the 
> lines of a literal without needing to worry about adding or removing 
> commas. (As is the case with JavaScript, for example.)
>
> Andrew
>

-- 
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] Out of "bandwidth": Selling gortos.com and related domains

[Rasmus Ulslev Pedersen]

Hello,

I think the best place to find someone who can understand the potential in 
the idea in using go as the basis for an RTOS is this list. I do not have 
the time to pursue the idea of "*gortos.com"* that + the hardware that 
needs to go along with it (which I think is necessary to make enough money 
to run it on a professional/dayjob basis). 

See ebay for the domain listing: 
http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem=162166893650#ht_500wt_1156

Ras

-- 
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] Invoking Golang executable on Mac OS X

[Justin Israel]

Maybe wrap it with Automator into an app?

On Sat, 13 Aug 2016, 5:52 AM  wrote:

> Maybe this is more OS related than Go, since Go just produces a static
> executable, so please feel free to lock this.
>
> I've built a simple tool, it works just fine in the terminal, both as a
> local executable and when put in the PATH. But when I want to register it
> as the default app for a given file type (to be run from Finder by double
> clicking a file of said file type), I'm not allowed to select it. Is this
> got to do with the Gatekeeper functionality? Or do I need to build a
> wrapper that has all the plists and other Mac specific things? If so, is
> there a Go way to wrap it (and still pass os.Args)?
>
> 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] keyed vs unkeyed fields

[Anmol Sethi]

Thing is, since keyed fields are almost always better, why were unkeyed fields 
even allowed for struct literals? I see what you mean in your example, but I 
think it would be simpler to only have unkeyed fields.

Was it a mistake or is there a even better reason?

> On Aug 12, 2016, at 10:12 PM, Nate Finch  wrote:
> 
> Unkeyed can be good to remind future you that you've changed the signature of 
> a struct and are now not populating all the fields.  That cuts both ways, 
> since it means you *have* to go to every place you've created a value of that 
> struct and update it with a new value... but it also means that if you don't 
> have a good default for that new field, that you won't miss places it's used.

-- 
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] what is the meaning of ENV GOEXE

[Anmol Sethi]

I looked in the Go source code. You can’t actually set it as a environment 
variable. It’s the value of the executable suffix. It’s set automatically in 
build.go. Like if running on windows, it is '.exe’ or for c-archives it is ‘.a’.

I don’t think it matters for an end user.

> On Aug 13, 2016, at 7:51 AM, andyxning  wrote:
> 
> when run `go env`, i get the following output:
> 
> ```
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/Users/andy/Github/go"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GO15VENDOREXPERIMENT="1"
> CC="clang"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 -fno-common"
> CXX="clang++"
> CGO_ENABLED="1"
> ```
> 
> what makes me confused is the GOEXE env, i googled it but found nothing.
> 
> -- 
> 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] xDT encoder / decoder

[Joe Blue]

There is a full implementation in js, so there is a starting point.

I can also provide test data of course.

https://www.npmjs.com/package/xdt

-- 
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] context race

[Dave Cheney]

Receiving from a closed channel immediately returns the channel types zero 
value. 

-- 
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] what is the meaning of ENV GOEXE

[Andy Xie]

​thanks. Just run `go env` and see it and is curious about it.


===
Ning Xie


2016-08-13 20:01 GMT+08:00 Anmol Sethi :

> I looked in the Go source code. You can’t actually set it as a environment
> variable. It’s the value of the executable suffix. It’s set automatically
> in build.go. Like if running on windows, it is '.exe’ or for c-archives it
> is ‘.a’.
>
> I don’t think it matters for an end user.
>
> > On Aug 13, 2016, at 7:51 AM, andyxning  wrote:
> >
> > when run `go env`, i get the following output:
> >
> > ```
> > GOARCH="amd64"
> > GOBIN=""
> > GOEXE=""
> > GOHOSTARCH="amd64"
> > GOHOSTOS="darwin"
> > GOOS="darwin"
> > GOPATH="/Users/andy/Github/go"
> > GORACE=""
> > GOROOT="/usr/local/go"
> > GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> > GO15VENDOREXPERIMENT="1"
> > CC="clang"
> > GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics
> -Qunused-arguments -fmessage-length=0 -fno-common"
> > CXX="clang++"
> > CGO_ENABLED="1"
> > ```
> >
> > what makes me confused is the GOEXE env, i googled it but found nothing.
> >
> > --
> > 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] context race

[upadhyay]

Say I have:

func DoSomething(ctx context.Context) {
for {
 select {
 case <- ctx.Done():
 return
 case <- time.After(time.Second)
 // do something
 }
}
}

Based on the documentation of context: 

Successive calls to Done return the same value.


So for each context there is only one channel, which is returned to every 
caller. 

Now given receiving on a closed channel never returns, above is not safe. I 
can check inside my second case if ctx.Err() is non nil, but its not a very 
clean solution. 

What would be safe way to use context.Done()? Or am I not understanding 
something right?

-- 
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] what is the meaning of ENV GOEXE

[andyxning]

when run `go env`, i get the following output:

```
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/andy/Github/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
-fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
```

what makes me confused is the GOEXE env, i googled it but found nothing.

-- 
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] Re: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:
>
> From what I gather even Adobe uses [dcraw]. 
>

I am pretty sure it is the other way around. Observing for years, it seems 
like dc is reverse engineering the Adobe DNG Converter. His color 
conversion matrices are definitely from that, and his support mostly 
follows a DNG converter release.

It should be possible to reference his code base in C and rewrite it in 
> Go,  I think.
>

Have you read dcraw.c? I have spent hours "reverse-engineering" what his 
code does. It is a spagetti of jumps, hoops, global variables, secret 
values, weird dependencies, etc.

/Klaus

-- 
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] Re: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Wednesday, 27 July 2016 04:36:31 UTC+2, Jonathan Pittman wrote:
>
> Well me too!  I am looking to see what level of interest there is in the 
> Go community to see this happen.  I am also looking for people who are 
> interested in working on this.
>

(a bit late to the party)

I am the author of RawSpeed - https://github.com/klauspost/rawspeed - which 
is a RAW decoding library which currently supports >700 cameras. It decodes 
to CFA-level images, so processing is still required to make the image 
"viewable". It is used by "Darktable" as well as other open source 
projects. It has even been stolen (oh sorry - converted) by raw.pics.io for 
their browser based decoding.

In my own humble opinion the code quality is way above dcraw, and I and 
other people have spent a lot of time trying to work out what goes on under 
the hood. Metadata is in a readable separate XML file (yes, this was 
designed in 2008), and not scattered around a single CPP file. Furthermore 
it is LGPL v2, but with a rewrite to Go, it should probably be MIT or 
similar. 

The code should translate rather well to Go - there is no big problems with 
it. Finding a decoder, parsing file structure and decoding images are 
nicely separated. Only the "RawImageData" seems to have accumulated a lot 
of fields and methods over time. It is rather sparsely commented, but I 
think the code should be pretty clear for a Gopher.

There are some design decision made that makes it faster by design. It 
decodes from raw memory and not a stream which makes it much faster to 
"jump around" without having to seek in the input stream. It decodes to 
unpadded memory which makes it use less memory and generally faster. 
Decoders have been heavily optimized for speed, while always maintaining 
full quality.

I have considered converting it to Go almost since I started programming, 
but since the demand for it is probably pretty small and I don't have a few 
months to spend on it, I have not done so. I am willing to help out the 
extent my knowledge

/Klaus

>

-- 
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: Who wants to use Go to process your camera's raw files?

[Klaus Post]

On Saturday, 13 August 2016 17:22:29 UTC+2, Peter Herth wrote:
>
> Having a parallel version of the raw converter could yield conversion 
> times far faster then the original C. And it would be a neat Go library to 
> have. 
>

For the biggest part, I would not expect you to be able to beat C code, for 
that there is too much pointer arithmetic going on. The forced bounds 
checks will probably eat around 20% of your speed. The Go 1.7 SSA compiler 
will however help bringing us to the 20% overhead.

In terms of multithreading - only a few formats can be decoded 
multithreaded. Most formats are some sort of LJPEG, where every pixel 
depends on previous data - forcing you to do single threaded decoding. DNG 
being the only "big" exception. 

For uncompressed formats, you are just moving bits, so multithreading gives 
you little advantage. RawSpeed has multithreaded decoding of images where 
it is possible.

/Klaus

-- 
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] Re: Who wants to use Go to process your camera's raw files?

['Paul' via golang-nuts]

I don't know what the true story actually is, however some camera hardware 
makers such as Nikon are giving software developers a tough time by 
intentionally obfuscating their metadata. A lot of folks had big problems 
with that including adobe. I just mentioned "reverse engineering" to 
indicate a potential for far bigger mess. Enough said. 

I was not aware of Rawspeed. I do not have any personal preferences, all I 
was saying is that a lot of hard work has already been done and it would be 
reasonable to try and leverage it.  Go language would be good,  I think, 
because a lot of programmers that would like to help out in opensource 
image processing drop out when they discover C++ is just to hard. They try 
for a while and then they just give up. Maybe Go language has the potential 
to bring some change to that problem.   
 

On Wednesday, July 27, 2016 at 4:36:31 AM UTC+2, Jonathan Pittman wrote:
>
> Well me too!  I am looking to see what level of interest there is in the 
> Go community to see this happen.  I am also looking for people who are 
> interested in working on this.
>
> Figuring out how to handle this problem for one specific camera's raw 
> files is not too difficult.  Figuring out how to do this to handle the 
> majority of cases requires a bit more work.
>
> To be clear, I am wanting a pure Go solution that is better thought out, 
> better laid out, and better to use than the existing C/C++ options.
>

-- 
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: Who wants to use Go to process your camera's raw files?

[Peter Herth]

Dcraw seems to be only partially gpl - otherwise Adobe couldn't use it in
its products. Having a parallel version of the raw converter could yield
conversion times far faster then the original C. And it would be a neat Go
library to have.

Peter

On Sat, Aug 13, 2016 at 5:18 PM, 'Paul' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> DCRAW pretty much does it all. Its straight C under GPLv2.  Dave Coffin
> reverse engineered a lot of stuff to get it to work. It would be a sizable
> duplication of effort to try to do all that again.  From what I gather even
> Adobe uses his stuff. It should be possible to reference his code base in C
> and rewrite it in Go,  I think. The question would be, what is the point?
> Its probably already fast as hell and it likely will not need a garbage
> collector. Whatever...
>
> On Wednesday, July 27, 2016 at 4:36:31 AM UTC+2, Jonathan Pittman wrote:
>>
>> Well me too!  I am looking to see what level of interest there is in the
>> Go community to see this happen.  I am also looking for people who are
>> interested in working on this.
>>
>> Figuring out how to handle this problem for one specific camera's raw
>> files is not too difficult.  Figuring out how to do this to handle the
>> majority of cases requires a bit more work.
>>
>> To be clear, I am wanting a pure Go solution that is better thought out,
>> better laid out, and better to use than the existing C/C++ options.
>>
> --
> 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] Small complete examples which show the power of Go?

[as . utf8]

It's shorter, but it's harder for me to grasp what it does as easily as the 
first example.

On Wednesday, August 10, 2016 at 2:09:58 AM UTC-7, Anmol Sethi wrote:
>
> You can shorten that by 6 lines 
>
> package main 
>
> import "net/http" 
>
> func main() { 
> http.ListenAndServe(":8080", http.HandlerFunc(func(w 
> http.ResponseWriter, r *http.Request) { 
> w.Write([]byte("Hello World!")) 
> })) 
> } 
>
> A bare bones web server in just 9 lines! 
>
> > On Aug 10, 2016, at 3:53 AM, gary.wi...@victoriaplumb.com  
> wrote: 
> > 
> > Hi, 
> > 
> > I'm giving a talk at work introducing Go and I'm looking for small 
> examples to show Go's potential. For example, the following program 
> demonstrates a bare-bones webserver in 13 lines: 
> > 
> > import ( 
> > 
> > "fmt" 
> > "net/http" 
> > ) 
> >   
> > func home(w http.ResponseWriter, r *http.Request) { 
> > fmt.Fprintf(w, "Hello, world!") 
> > } 
> >   
> > func main() { 
> > http.HandleFunc("/", home) 
> > http.ListenAndServe(":8080", nil) 
> > } 
> > 
> > Has anyone here got any more little snippets like this to show the power 
> and potential of Go? It doesn't have to be in networking, just little a 
> little snippet to make people think "wow, that's cool!". 
> > 
> > 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...@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] keyed vs unkeyed fields

[Ian Lance Taylor]

On Sat, Aug 13, 2016 at 12:06 AM, Anmol Sethi  wrote:
> Thing is, since keyed fields are almost always better, why were unkeyed 
> fields even allowed for struct literals? I see what you mean in your example, 
> but I think it would be simpler to only have unkeyed fields.
>
> Was it a mistake or is there a even better reason?

I think this is a case where consistency is valuable.

And for something like
struct Point { x, y int }
there is no real confusion to writing
Point{1, 2}
Why make people always write
Point(x: 1, y: 2}
?

Also consider that there are useful structs with a single field, in
order to implement some interface without allowing people to casually
change the value.  It would be a pain to force people to always state
the field when writing a composite literal.  And it would be a pain to
have a special exception for a single field.

Ian

-- 
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] Re: golang.org/x/tools/go/loader: file names of parsed *ast.File

[Paul Jolly]

On Saturday, 13 August 2016 21:58:37 UTC+1, Paul Jolly wrote:
>
> Am I missing something obvious here?
>

Please excuse the reply to self, but I have discovered what I was missing.

For the sake of completeness, here is how the equivalent mapping is 
achieved in golang.org/x/tools/go/loader world:

import (
"go/ast"
"go/parser"
"golang.org/x/tools/go/loader"
)


conf := loader.Config{
ParserMode: parser.AllErrors | parser.ParseComments,
Cwd:path,
}

...

conf.CreateFromFilenames(path, toParse...)

prog, err := conf.Load()
if err != nil {
panic(err)
}

At this point conf.CreatePkgs (type []loader.PkgSpec) and prog.Created 
(type []*loader.PackageInfo) correspond to each other.

For each (loader.PkgSpec, *loader.PackageInfo) pairing, say pkgSpec and 
pkgInfo, then pkgSpec.Filenames (type []string) and pkgInfo (type 
[]*ast.File) again correspond, which gives us the required mapping.

-- 
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] Re: go mobile : keyboard input, camera

[danilolr]

About the camera I think you best hope is use NDK (c++ bindings to android 
functions).
But you are out of luck as most of the links I search do not provide a 
solution.
The best answer I find is this :

http://stackoverflow.com/questions/30328276/access-android-camera-with-ndk

Not tested, but I did a quick search because I will need this on the future.

Maybe to make it work without hacks you can make you app a android/iOS 
native application and call the go code as a SDK app. This way you can have 
all the calls on java/swift/objective-c.

sexta-feira, 12 de Agosto de 2016 às 02:00:23 UTC-3, zzz...@gmail.com 
escreveu:
>
> Hi,
>
>   I have looked the go mobile docs / examples (the most advanced being 
> 'flappy gopher'), but I can not find code/API for either of the following:
>
>   1) accessing the camera (i.e. taking a picture)
>   2) keyboard input (is the current best to draw a bunch of squares with 
> letters in them in OpenGL and manually track the touch events?)
>
> 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.

[go-nuts] Re: Who wants to use Go to process your camera's raw files?

['Paul' via golang-nuts]

On Saturday, August 13, 2016 at 8:06:44 PM UTC+2, Klaus Post wrote:
>
> On Saturday, 13 August 2016 17:18:16 UTC+2, Paul wrote:
>>
>> From what I gather even Adobe uses [dcraw]. 
>>
>
> I am pretty sure it is the other way around. Observing for years, it seems 
> like dc is reverse engineering the Adobe DNG Converter. His color 
> conversion matrices are definitely from that, and his support mostly 
> follows a DNG converter release.
>

I could'nt remember where I read it, but it actually says so in the adobe 
forum Quote: 
"ACR contains some stuff from dcraw, and dcraw contains some stuff from 
ACR." 

>
> It should be possible to reference his code base in C and rewrite it in 
>> Go,  I think.
>>
>
> Have you read dcraw.c? I have spent hours "reverse-engineering" what his 
> code does. It is a spagetti of jumps, hoops, global variables, secret 
> values, weird dependencies, etc.
>
> /Klaus
>

Well apart from the 'code quality', his code does seem to be of interest to 
quite a few software developers in the graphics business,  including 
yourself as you write.  Adobe would have their own special reasons for 
using some of his stuff.  

I was not even aware of Rawspeed. I do use Darktable, however there is 
quite some discussion going on as to the quality of the images that 
opensource raw converters produce. Adobe seems to still be king of that 
hill. Or poprietary Converters such as Capture Nx2 which very unfortunately 
has been discontinued. 

   

-- 
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] Re: Who wants to use Go to process your camera's raw files?

[Jonathan Pittman]

For some reason I did not get the last 3 updates until this one.  Weird.

So, I have looked over a number of packages that parse tiff files.  While, 
at the most basic level, they all have to do the same sort of things, each 
one also approaches the situation a little differently.  And more so, the 
end result tends to be for custom use cases.

I already have code up on github 
.  You will have to excuse my 
lack of good documentation and tests.  I was originally planning to just do 
a proof of concept for how this might work.  So, it needs some cleaning up. 
 I am also in the process of making some changes to it including the 
LICENSE.  No pull requests at this time please, but do have a look if you 
like.

I would like to see some real discussion about the approach before writing 
any more code.  I am not sure the best way to go about this discussion. 
 Does email work for everyone?  Should we use the go proposal method?  A 
shared google doc?  I would like this to eventually make its way to the 
golang.org/x/image repo.  I would like to see a collection of use cases 
that we can include when trying to solve this in an appropriate and general 
way.

On Wednesday, August 10, 2016 at 6:08:00 PM UTC-4, jonathan...@gmail.com 
wrote:
>
> I would be interested in seeing this happen.
>
> On Tuesday, July 26, 2016 at 7:36:31 PM UTC-7, Jonathan Pittman wrote:
>>
>> Well me too!  I am looking to see what level of interest there is in the 
>> Go community to see this happen.  I am also looking for people who are 
>> interested in working on this.
>>
>> Figuring out how to handle this problem for one specific camera's raw 
>> files is not too difficult.  Figuring out how to do this to handle the 
>> majority of cases requires a bit more work.
>>
>> To be clear, I am wanting a pure Go solution that is better thought out, 
>> better laid out, and better to use than the existing C/C++ options.
>>
>

-- 
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 info on how Go package developers handle breaking changes with other packages

[Chris Bogart]

Hi, I'm looking for some help from developers who write Go packages. My 
research group is interested in the different choices new package managers 
and repositories are making when designing their ecosystems. Platforms like 
Node.js/NPM, Google's go, and Rust/Cargo are making somewhat different 
design choices from each other, and they are very different from older 
packaging systems like CPAN. We'd like to know what the impact of those 
design choices are on how developers deal with breaking changes among 
packages when they depend on each other. The go ecosystem is particularly 
interesting in the way it handles versioning, and we're curious to know how 
people use it in practice.


Could I ask people to take ~20 minutes of your time and fill out our survey 
at http://breakingapis.org/survey? I'll report back to the go community 
when we've analyzed the results (or there's a sign up link to be notified 
when results are out at http://breakingapis.org).


(If you don't develop Go packages, but have experience with Node.js/NPM, 
PyPI, Hackage, or something else, we're still interested -- just make a 
different "software ecosystem" choice on the first page. The study is a 
comparison among ecosystems; Go is one point of comparison).

-- 
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 info on how Go package developers handle breaking changes with other packages

['Ingo Oeser' via golang-nuts]

Please note that there is no concept central repository of Go code. Those 
questions in the survey are very confusing for a Go developer. Maybe you could 
exclude those questions for Go developers. Otherwise you would need to ignore 
the results for Go developers here in your later analysis.

-- 
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] Re: Looking for info on how Go package developers handle breaking changes with other packages

[Volker Dobler]

I tried to fill out the survey but I got lost as I'm unsure what
"go (community packages)" really means. Some question
indicate that this could be the standard library, some questions
make sense if you interpret "go (community packages)" as
the golang.org/x/... packages while other questions seem
to ask about any open source package.

Short: The survey asks questions unanswerable for go packages.

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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] convert a given time in one Timezone to other TimeZone

[laxman . ece]

Apologize if my question was confusing. My question was to get the 
equivalent time to a given time in other time zones.

Thanks Axel. Your code snippet helped in what i was solving to an extent.


On Wednesday, August 10, 2016 at 10:54:50 PM UTC+5:30, Axel Wagner wrote:
>
> https://play.golang.org/p/l_bu62zuLm
>
> On Wed, Aug 10, 2016 at 6:55 PM, Matthew Zimmerman  > wrote:
>
>> I don't understand your question, but maybe this helps?
>>
>> https://github.com/mzimmerman/tt
>>
>> On Wed, Aug 10, 2016 at 9:50 AM  wrote:
>>
>>> I was trying to find the solution to get a given time in timezone1 using 
>>> the time in timezone2.
>>>
>>> Have solution to get the time in other timezone for current time but did 
>>> not found a way to get time for a given time. 
>>>
>>> Thanks
>>> L 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 golang-nuts...@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...@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] Re: Who wants to use Go to process your camera's raw files?

[Evan Digby]

Sorry, I didn't see your longer high-level overview post--I see the vision 
a bit more clearly now.

Have you used slack? It might be a good place to start discussion to hammer 
out some details before moving onto a google doc. I find shared google docs 
can be challenging without at least a foundation discussed up-front. 

Slack is free for this type of thing (https://gophers.slack.com/pricing). I 
know lots of people dislike it, but I find it quite useful for the sort of 
semi-formal discussion that seeds this type of project.

On Wednesday, 10 August 2016 20:09:12 UTC-7, Jonathan Pittman wrote:
>
> For some reason I did not get the last 3 updates until this one.  Weird.
>
> So, I have looked over a number of packages that parse tiff files.  While, 
> at the most basic level, they all have to do the same sort of things, each 
> one also approaches the situation a little differently.  And more so, the 
> end result tends to be for custom use cases.
>
> I already have code up on github 
> .  You will have to excuse my 
> lack of good documentation and tests.  I was originally planning to just do 
> a proof of concept for how this might work.  So, it needs some cleaning up. 
>  I am also in the process of making some changes to it including the 
> LICENSE.  No pull requests at this time please, but do have a look if you 
> like.
>
> I would like to see some real discussion about the approach before writing 
> any more code.  I am not sure the best way to go about this discussion. 
>  Does email work for everyone?  Should we use the go proposal method?  A 
> shared google doc?  I would like this to eventually make its way to the 
> golang.org/x/image repo.  I would like to see a collection of use cases 
> that we can include when trying to solve this in an appropriate and general 
> way.
>
> On Wednesday, August 10, 2016 at 6:08:00 PM UTC-4, jonathan...@gmail.com 
> wrote:
>>
>> I would be interested in seeing this happen.
>>
>> On Tuesday, July 26, 2016 at 7:36:31 PM UTC-7, Jonathan Pittman wrote:
>>>
>>> Well me too!  I am looking to see what level of interest there is in the 
>>> Go community to see this happen.  I am also looking for people who are 
>>> interested in working on this.
>>>
>>> Figuring out how to handle this problem for one specific camera's raw 
>>> files is not too difficult.  Figuring out how to do this to handle the 
>>> majority of cases requires a bit more work.
>>>
>>> To be clear, I am wanting a pure Go solution that is better thought out, 
>>> better laid out, and better to use than the existing C/C++ options.
>>>
>>

-- 
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] Cast interface{} to []string

[Vasily Korytov]

Hi,

I have an interface{} variable that can be either string or a list of 
string (yes, that's bad design, I know).

I need a []string to feed it to strings.Join (I need one string for output).

This way works, that is explicitly creating []string and copying each 
element to it:

var list []string
for _, v := range mail.([]interface{}) {
list = append(list, v.(string))
}
rcpt = strings.Join(list, ", ")

Have I overlooked something and there is a way to do it in a more graceful 
and effective way?

Thanks.

-- 
  Vasily Korytov
  https://chillum.github.io

-- 
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] go mobile : keyboard input, camera

[zzzgeom]

Hi,

  I have looked the go mobile docs / examples (the most advanced being 
'flappy gopher'), but I can not find code/API for either of the following:

  1) accessing the camera (i.e. taking a picture)
  2) keyboard input (is the current best to draw a bunch of squares with 
letters in them in OpenGL and manually track the touch events?)

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.

[go-nuts] Cast interface{} to []string

[Val]

Looks fine to me. You'll have to iterate anyway.
You can save a little perf by allocating directly the right size for your temp 
slice, with make. Then use indexing instead of append.

-- 
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] Re: Looking for info on how Go package developers handle breaking changes with other packages

[Chris Bogart]

Thank you both -- yes, I see the problem.  It was tricky to get the 
questions right to apply across ecosystems with different infrastructure 
and terminology; but we're particularly interested in comparing ecosystems 
like Go and (much of) Swift that don't have central repositories with ones 
like R/CRAN that do.  So we're definitely interested in your insights even 
if the wording feels strange in places.

Anyway, I've tweaked things where I can without throwing off the survey's 
comparability with already-collected answers, and I think most of the 
questions appear more sensible for Go, if not perfect.

For those of you in the future who take the survey -- if there's anything 
left that doesn't make sense, just answer literally if you can, and/or skip 
questions that don't apply.  But we definitely will take into account Go's 
lack of a repository when interpreting the answers.

Ingo Oeser wrote:
| There is no central repository of Go code.

Volker Dobler wrote:
>
> I tried to fill out the survey but I got lost as I'm unsure what
> "go (community packages)" really means. 
>

 

-- 
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] Have some troubles with connection of delve + Visual Studio Code under my Mac

[Dmitriy Suhinin]

I can't run debug mode under  Visual Studio Code. Everything seems 
configure well, but no answer from the delve. I can run Debug and I can see 
that delve process ruined, but no activity under Visual Studio Code. Can 
someone help with that?

-- 
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] Re: Go 1.7 Release Candidate 6 is released

[foo bar]

Hi David,

The issue you are having seems related to 
https://github.com/golang/go/issues/16636

I'm also running Arch Linux, and it seems like -fsanitize=memory is broken 
on general for Clang on Arch. Would you be able to verify if this is also 
the case for you? Add a comment to the issue, rather than this thread to 
keep the discussion on track.

Cheers /u

On Thursday, August 11, 2016 at 6:07:01 PM UTC+2, David Marceau wrote:
>
> Ok so yes I recently installed clang on this archlinux box.  The previous 
> go binaries were built with gcc/g++.
>
> So to clarify and save others time:
>
> 1)to build using gcc/g++:
> CC=/usr/bin/gcc CXX=/usr/bin/g++ GOROOT_BOOTSTRAP=/root/go1.7rc5 
> ./make.bash
>
> 2)to build using clang/clang++:
> CC=/usr/bin/clang CXX=/usr/bin/clang++ GOROOT_BOOTSTRAP=/root/go1.7rc5 
> ./make.bash
>
> By explicitly setting those CC and CXX variables, I was able to revert to 
> my original gcc/g++ built golang binaries in order to be consistent since 
> my earlier binaries were built with gcc/g++ I prefer to stay on that path 
> for the moment.
>
>
> On Wednesday, August 10, 2016 at 10:00:37 AM UTC-4, David Marceau wrote:
>>
>> when I install from sources straight from git checkout go1.7rc6
>> go1.7rc6 FAILS on Asus Z97-A-USB31 motherboard with intel i5-4590,
>> "../misc/cgo/testsanitizers" 
>> it core dumps and doesn't give me the success message to start using it 
>> as the previous go1.7rc[1-4] did.
>> signal: segmentation fault (core dumped)
>> FAIL: msan
>> FAIL: msan2
>> FAIL: msan3
>> FAIL: msan4
>> ... FAILED
>>
>>
>> To contrast this, Go1.7rc6 does succeed on another much older motherboard 
>> Dell Inc. Vostro 430/054KM3, BIOS 2.2.0.
>>
>>
>> On Monday, August 8, 2016 at 4:44:40 PM UTC-4, Chris Broadfoot wrote:
>>>
>>> Hello gophers,
>>>
>>> We have just released go1.7rc6, a release candidate for Go 1.7.
>>> Some say that it's the best one yet.
>>> It is cut from release-branch.go1.7 at the revision tagged go1.7rc6.
>>>
>>> Please help us by testing your Go programs with the release, and
>>> report any problems using the issue tracker:
>>>   https://golang.org/issue/new
>>>
>>> You can download binary and source distributions from the usual place:   
>>>   
>>>   https://golang.org/dl/#go1.7rc6
>>>
>>> To find out what has changed in Go 1.7, read the draft release notes:
>>>   https://tip.golang.org/doc/go1.7
>>>
>>> Documentation for Go 1.7 is available at:
>>>   https://tip.golang.org/
>>>   
>>> A comprehensive list of changes since rc5 is here:
>>>   https://github.com/golang/go/compare/go1.7rc5...go1.7rc6
>>>   
>>> We plan to issue Go 1.7 in a week's time (August 15).
>>>
>>> Cheers,
>>> 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.

[go-nuts] keyed vs unkeyed fields

[Anmol Sethi]

Keyed fields seem to be always better than unkeyed fields in a composite 
literal.
Under what circumstances would I want to use unkeyed fields?

-- 
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] Small complete examples which show the power of Go?

[gary . willoughby]

Hi,

I'm giving a talk at work introducing Go and I'm looking for small examples 
to show Go's potential. For example, the following program demonstrates a 
bare-bones webserver in 13 lines:

import (

"fmt"
"net/http"
)
 
func home(w http.ResponseWriter, r *http.Request) {
fmt.Fprintf(w, "Hello, world!")
}
 
func main() {
http.HandleFunc("/", home)
http.ListenAndServe(":8080", nil)
}

Has anyone here got any more little snippets like this to show the power 
and potential of Go? It doesn't have to be in networking, just little a 
little snippet to make people think "wow, that's cool!".

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.

Re: [go-nuts] Small complete examples which show the power of Go?

[Anmol Sethi]

You can shorten that by 6 lines

package main

import "net/http"

func main() {
http.ListenAndServe(":8080", http.HandlerFunc(func(w 
http.ResponseWriter, r *http.Request) {
w.Write([]byte("Hello World!"))
}))
}

A bare bones web server in just 9 lines!

> On Aug 10, 2016, at 3:53 AM, gary.willoug...@victoriaplumb.com wrote:
> 
> Hi,
> 
> I'm giving a talk at work introducing Go and I'm looking for small examples 
> to show Go's potential. For example, the following program demonstrates a 
> bare-bones webserver in 13 lines:
> 
> import (
> 
> "fmt"
> "net/http"
> )
>  
> func home(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello, world!")
> }
>  
> func main() {
> http.HandleFunc("/", home)
> http.ListenAndServe(":8080", nil)
> }
> 
> Has anyone here got any more little snippets like this to show the power and 
> potential of Go? It doesn't have to be in networking, just little a little 
> snippet to make people think "wow, that's cool!".
> 
> 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.

[go-nuts] http2 questions

[Jeffrey Smith]

I have been playing around with http2 in the latetst 1.7RC today and had a 
few questions 

I still had to import "golang.org/x/net/http2" and then set 
http2.ConfigureTransport to actually use http2 when creating a client. I 
was under the impression this was fixed or was I wrong? 
https://github.com/golang/go/issues/14391 

tr := {
TLSClientConfig: {InsecureSkipVerify: true},
}
http2.ConfigureTransport(tr)
client := {Transport: tr}


I have the below code but it appears to leak connections whenever the 20 
second timeout is hit after connecting to a client, is there anyway to 
clean up the connection for reuse rather than creating a new one until I 
hit my open file limit?

func worker(id int, jobs <-chan int, results chan<- Results) {

tr := {
TLSClientConfig: {InsecureSkipVerify: true},
MaxIdleConnsPerHost: 2,
}
http2.ConfigureTransport(tr)
PostClient := {Transport: tr, Timeout: time.Duration(20 
* time.Second)}
closeBody := false

for {
closeBody = false
t0 := time.Now()

req, err := http.NewRequest("GET", 
Url+strconv.Itoa(<-jobs), nil)
if err != nil {
results <- Results{0, err, "0"}
continue
}
resp, err := PostClient.Do(req)
if resp != nil {
closeBody = true
//defer resp.Body.Close()
}
t1 := time.Now()
if err != nil {
results <- Results{0, err, fmt.Sprintf("%v", 
t1.Sub(t0))}
if closeBody == true {
io.Copy(ioutil.Discard, resp.Body)
resp.Body.Close()
}
continue
}
//discard the body so we can reuse the connections
io.Copy(ioutil.Discard, resp.Body)
//Close the body so we can resuse
resp.Body.Close()

results <- Results{resp.StatusCode, err, fmt.Sprintf("%v", 
t1.Sub(t0))}
}
}

Also does anyone have any recommendations with http2 should I be creating 
one connection per server and fire all requests down that (not even sure 
how I would do this in golang) or just create a global pool and allow the 
http client deal with it?

-- 
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] compressing long list of short strings

[Alex Flint]

I have long list of short strings that I want to compress, but I want to be
able to decompress an arbitrary string in the list at any time without
decompressing the entire list.

I know the list ahead of time and it doesn't matter how much preprocessing
time is involved. It is also fine if there is some significant O(1) memory
overhead at runtime.

Any suggestions?

-- 
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] compressing long list of short strings

[Ian Lance Taylor]

On Wed, Aug 10, 2016 at 3:27 PM, Alex Flint  wrote:
>
> I have long list of short strings that I want to compress, but I want to be
> able to decompress an arbitrary string in the list at any time without
> decompressing the entire list.
>
> I know the list ahead of time and it doesn't matter how much preprocessing
> time is involved. It is also fine if there is some significant O(1) memory
> overhead at runtime.
>
> Any suggestions?

You say the strings are "short": how short?  How many strings are
there?  How much total data in the uncompressed strings?

What is your target for the total amount of memory used by the
compressed strings plus any data required to decompress them?

One approach that comes to mind is building an optimized Huffman table
for the full set of strings, and compressing each one separately using
that table.  Then each string is represented by a bit offset into the
resulting bitstream, and each can be decompressed separately.  But you
would need storage at run time not only for the bitstream, but also
for the Huffman table.

Ian

-- 
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] Re: [ANN] Gomail v2: sending emails faster

[matic]

GitHub page says "Automatic encoding of special characters". Does that mean 
if I use output from (user provided input to a 
golang.org/pkg/text/template) as body input to gomail, gomail will properly 
escape any characters that could be used to insert SMTP headers or do 
anything else that could be malicious?

-- 
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] Re: Small complete examples which show the power of Go?

[Val]

Iterations over slices, maps, channels are very cool, usually straight to 
the point :

func main() {
for _, a := range []int{6, 4} {
for _, b := range []int{2, 3} {
for fname, f := range map[string]func(int, int) int{
"plus":  func(x, y int) int { return x + y },
"minus": func(x, y int) int { return x - y },
"times": func(x, y int) int { return x * y },
"div":   func(x, y int) int { return x / y },
} {
fmt.Println(a, fname, b, "is", f(a, b))
}
}
}
}
Playground 

Then you may tell some specific details : why the underscores for ignored 
iteration variables, and why the map iteration order is not the same as the 
order in the code. Also, I find these iterations quite versatile in 
practice, but they work only on built-in types (you won't have java-like 
custom iterables).

Cheers
Val

On Wednesday, August 10, 2016 at 9:53:38 AM UTC+2, 
gary.wi...@victoriaplumb.com wrote:
>
> Hi,
>
> I'm giving a talk at work introducing Go and I'm looking for small 
> examples to show Go's potential. For example, the following program 
> demonstrates a bare-bones webserver in 13 lines:
>
> import (
>
> "fmt"
> "net/http"
> )
>  
> func home(w http.ResponseWriter, r *http.Request) {
> fmt.Fprintf(w, "Hello, world!")
> }
>  
> func main() {
> http.HandleFunc("/", home)
> http.ListenAndServe(":8080", nil)
> }
>
> Has anyone here got any more little snippets like this to show the power 
> and potential of Go? It doesn't have to be in networking, just little a 
> little snippet to make people think "wow, that's cool!".
>
> 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.

[go-nuts] Re: Small complete examples which show the power of Go?

[sphilippov]

Easy parallelization and concurrency:

package main 

import (
 "runtime"
)
 
func FoldParallel(data []float64, initialValue float64, op func(float64, 
float64) float64) float64 {
sliceSize := len(data) / runtime.NumCPU()
results := make(chan float64, runtime.NumCPU())
numResults := 0
for i := 0; i < len(data); i += sliceSize {
numResults++
go func(dataSlice []float64) {
result := float64(initialValue)
for _, v := range dataSlice {
op(result, v)
}
results <- result
}(data[i : i+sliceSize])
}
result := initialValue
for i := 0; i < numResults; i++ {
result = op(result, <-results)
}
return result
}

func main() {
var data [1000]float64

// parallel sum
FoldParallel(data[:], 0, func(v1, v2 float64) float64 { return v1 + v2 
})
// parallel mul
FoldParallel(data[:], 1, func(v1, v2 float64) float64 { return v1 * v2 
})
}



-- 
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] compressing long list of short strings

[Alex Flint]

There are around 2M strings, and their total size is ~6 GB, so an average
of 3k each.

I actually looked briefly at Go's compress/flate to see whether something
like what you're describing is possible without writing my own compressor
but I couldn't see any obvious way to get at the underlying compressor
state. Or perhaps I'm looking in the wrong package - any pointers would be
appreciated.

On Wed, Aug 10, 2016 at 3:42 PM Ian Lance Taylor  wrote:

> On Wed, Aug 10, 2016 at 3:27 PM, Alex Flint  wrote:
> >
> > I have long list of short strings that I want to compress, but I want to
> be
> > able to decompress an arbitrary string in the list at any time without
> > decompressing the entire list.
> >
> > I know the list ahead of time and it doesn't matter how much
> preprocessing
> > time is involved. It is also fine if there is some significant O(1)
> memory
> > overhead at runtime.
> >
> > Any suggestions?
>
> You say the strings are "short": how short?  How many strings are
> there?  How much total data in the uncompressed strings?
>
> What is your target for the total amount of memory used by the
> compressed strings plus any data required to decompress them?
>
> One approach that comes to mind is building an optimized Huffman table
> for the full set of strings, and compressing each one separately using
> that table.  Then each string is represented by a bit offset into the
> resulting bitstream, and each can be decompressed separately.  But you
> would need storage at run time not only for the bitstream, but also
> for the Huffman table.
>
> Ian
>

-- 
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] bodyless functions in standard libary

[Aram Hăvărneanu]

https://golang.org/doc/asm

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

Re: [go-nuts] filepath.Join

[Steven Hartland]

Are the unexported methods OS specific?

On 13/07/2016 20:56, Anmol Sethi wrote:

Why does filepath.Join only call to the unexported join? Why not just export 
the unexported join?



--
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] Re: Reverse proxy with HTTP2 support

[Kevin Klues]

Im curious about this as well. Are there any plans to build native support 
for a reverse proxy that can directly forward HTTP/2 traffic to a backend 
server? If not, does anyone know of a usable external project that provides 
this functionality?

On Wednesday, March 30, 2016 at 2:48:11 AM UTC-7, Piyush Dewnani wrote:
>
> The default reverse proxy at 
> https://golang.org/pkg/net/http/httputil/#ReverseProxy has some 
> hard-coded vars which uses http 1.1 
>
> For example: https://golang.org/src/net/http/httputil/reverseproxy.go#L178
>
> Not sure about the changes targeted to support 'HTTP 2' out of the box for 
> 'HTTP 2' enabled backend.
>
>

-- 
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] filepath.Clean

[Ian Lance Taylor]

On Wed, Jul 13, 2016 at 10:40 AM, Anmol Sethi  wrote:
> Why does filepath.Clean replace each slash with a separator at the end of the 
> function? What’s the point of attempting to clean it if the separator used is 
> incorrect? Wouldn’t doing this at the start of the function make more sense?

It dates back to https://golang.org/cl/4758051 in 2011.  I would guess
that Alex thought it would be simpler to just do it at the end rather
than reworking the rest of the function.

Ian

-- 
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] Rel in path package

[Anmol Sethi]

Thanks Ian!

> On Jul 13, 2016, at 10:23 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 2:43 AM, Anmol Sethi  wrote:
>> Right here: 
>> https://github.com/nsf/gocode/blob/f535dc686130fcc7b942c504ce5903222a205ca3/autocompletecontext.go#L254
>> 
>> I have to annoyingly use filepath.ToSlash after just in case the user was on 
>> windows.
> 
> I don't know what that code is doing, but the fact that you are
> passing fpath to readdir makes me think that fpath is a path in the
> file system, and that you should be using the path/filepath package
> anyhow.  Why are you using the path package here?  (To be clear, the
> path package is for things like URLs, and the path/filepath package is
> for file system paths.)
> 
> Ian
> 
> 
> 
>>> On Jul 12, 2016, at 10:58 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
 Why is there no function in the path package to get relative paths, like 
 filepath.Rel?
>>> 
>>> When would you want to use it?
>>> 
>>> Ian
>> 

-- 
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] filepath.Clean

[Anmol Sethi]

Why does filepath.Clean replace each slash with a separator at the end of the 
function? What’s the point of attempting to clean it if the separator used is 
incorrect? Wouldn’t doing this at the start of the function make more sense?

-- 
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] Rel in path package

[Anmol Sethi]

fixed here: https://github.com/nsf/gocode/pull/361/files

Not sure what I was thinking when I wrote that code. My bad.
> On Jul 13, 2016, at 10:23 AM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 2:43 AM, Anmol Sethi  wrote:
>> Right here: 
>> https://github.com/nsf/gocode/blob/f535dc686130fcc7b942c504ce5903222a205ca3/autocompletecontext.go#L254
>> 
>> I have to annoyingly use filepath.ToSlash after just in case the user was on 
>> windows.
> 
> I don't know what that code is doing, but the fact that you are
> passing fpath to readdir makes me think that fpath is a path in the
> file system, and that you should be using the path/filepath package
> anyhow.  Why are you using the path package here?  (To be clear, the
> path package is for things like URLs, and the path/filepath package is
> for file system paths.)
> 
> Ian
> 
> 
> 
>>> On Jul 12, 2016, at 10:58 PM, Ian Lance Taylor  wrote:
>>> 
>>> On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
 Why is there no function in the path package to get relative paths, like 
 filepath.Rel?
>>> 
>>> When would you want to use it?
>>> 
>>> Ian
>> 

-- 
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: Reverse proxy with HTTP2 support

[Tim Hawkins]

https://github.com/containous/traefik
On 14 Jul 2016 2:13 a.m., "Kevin Klues"  wrote:

> Im curious about this as well. Are there any plans to build native support
> for a reverse proxy that can directly forward HTTP/2 traffic to a backend
> server? If not, does anyone know of a usable external project that provides
> this functionality?
>
> On Wednesday, March 30, 2016 at 2:48:11 AM UTC-7, Piyush Dewnani wrote:
>>
>> The default reverse proxy at
>> https://golang.org/pkg/net/http/httputil/#ReverseProxy has some
>> hard-coded vars which uses http 1.1
>>
>> For example:
>> https://golang.org/src/net/http/httputil/reverseproxy.go#L178
>>
>> Not sure about the changes targeted to support 'HTTP 2' out of the box
>> for 'HTTP 2' enabled backend.
>>
>> --
> 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] Re: Go 1.7 Release Candidate 1 is released

[Sathish VJ]

On Mac, bash prompt, attempting to install go to custom location using 
package installation file go1.7rc1.darwin-amd64.pkg.  But it is always 
installed in /usr/local/bin.  

export GOROOT="/Users/username/coding/golang/go1.7.rc1"
export GOPATH="/Users/username/coding/golang/gopath"
export GOBIN="/Users/username/coding/golang/gopath/bin"  # with or without 
this, result is the same.
export PATH=$PATH:$GOBIN
export PATH=$PATH:$GOROOT/bin:/Users/vj/coding/golang/go_appengine

Folder for GOROOT, GOPATH, and GOBIN already exists.  

Is there any way I can get it to install in a custom path?  Or is there an 
issue in the pkg installation?

On Friday, 8 July 2016 10:20:34 UTC+5:30, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.7rc1, a release candidate for Go 1.7.
> It is cut from release-branch.go1.7 at the revision tagged go1.7rc1.
>
> Please help us by testing your Go programs with the release, and report 
> any problems using the issue tracker:
>   https://golang.org/issue/new
>
> You can download binary and source distributions from the usual place: 
>   https://golang.org/dl/#go1.7rc1
>
> To find out what has changed in Go 1.7, read the draft release notes:
>   https://tip.golang.org/doc/go1.7
>
> Documentation for Go 1.7 is available at:
>   https://tip.golang.org/
>
> Cheers,
> 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.

[go-nuts] any way to save an image to 8-bit indexed png format?

[sleepy]

I need to shrink images to as small as possible with an acceptable quality.
found https://tinypng.com/ could convert the image to 8-bit indexed png, 
which is best fit my requirement.

however, I need to do this by my go program, any hints for this?

thanks in advance.

-- 
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] if something not perfect here

[wweir9]

These are two screeshot from os/exec , it looks like that code below will 
always be true.
len(c.Args) > 0






-- 
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] Proposal: Add coloured output to go commands

[Zac Pullar-Strecker]

Commands like go run, go build and go test amoung others should have 
coloured output when an error occurs. it would make reading stack traces a 
lot easier. I personally use the go run tool a lot during development 
because I have no reason to keep a binary in the $GOPATH/bin directory when 
it's likely to change in the next 5 minutes.

github.com/fatih/color & github.com/kortschak/ct are os agnostic (Unix & 
Windows,) packages for ANSI escape codes.
It would make sense to do this with a flag -c or -color and anyone who 
wanted it perminantly could alias it.
I'm relatively new to the community so I wanted to post it here before 
creating an issue on github. Are there any issues with doing this?

Thanks, Zac

-- 
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] http.Handler method name

[Nigel Tao]

On Wed, Jul 13, 2016 at 6:14 AM, Anmol Sethi  wrote:
> If you were to redesign it now, would you name the method Handle?

Also speaking personally, yes.

-- 
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] Rel in path package

[Ian Lance Taylor]

On Tue, Jul 12, 2016 at 5:17 PM, Anmol Sethi  wrote:
> Why is there no function in the path package to get relative paths, like 
> filepath.Rel?

When would you want to use it?

Ian

-- 
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] What dependency management tool do you use?

[Matt Silverlock]

gvt - simple but robust: https://github.com/FiloSottile/gvt

-- 
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] Trying to verify io.Copy and underlying way of handling files.

[Eliezer Croitoru]

I have looked at : https://github.com/rainycape/vfs

and I am trying to understand and predict what to be expected from the VFS
when I will be using io.Copy on a file.

The VFS has a lock on a file but from what I have seen until now in the
source code it locks the file on a "read' operation but it releases the lock
with a defer on a read.

I am trying to predict if I would need to "lock" the whole file manually as
long as I want it to be or not.

I have seen the sources of io.Copy which led me to:
https://golang.org/src/io/io.go?s=12235:12295#L366

And it seems that the read is being used in a loop with couple basic exit
states.

Between these read operations, there is a state which the file would not
stay in under a "read" operation which allows the vfs file to be unlocked.

 

Would any lower level of the language will "assume" that the file will be
"unlocked"(since the read operation ended) at runtime or
it will be considered or optimized to be a single long "read" operation and
by that will allow me to count on the VFS lock?

As I am writing myself I feel like I have the answer already but I need more
eyes to ease my mind.

 

Thanks,

Eliezer

 



Eliezer Croitoru  
Linux System Administrator
Mobile: +972-5-28704261
Email: elie...@ngtech.co.il



 

-- 
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] What dependency management tool do you use?

[Sean Russell]

Hi Nathan,

On Wednesday, July 13, 2016 at 11:43:09 AM UTC-4, Nathan Fisher wrote:
> Out of curiosity if the upstream deletes their repo does a force push
> invalidating a sha or in some other way causes a dangling reference how do you
> protect against that without checking the dependency in? I'm thinking about

You can commit external repositories or not, whichever is your preference.  gvt 
doesn't force you to do one or the other.  The difference is whether the build 
process includes a step to pull the dependencies.

--- SER

-- 
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] How to make bootstrap style reflect on golang template

[Josh Kamau]

If you inspect the browser console, are you serving the bootstrap css ??

I normally do something like this:
mux.Handle("/assets/", http.StripPrefix("/assets/",
http.FileServer(http.Dir("./assets"

And then my css link will be  /assets/bootstrap/css/bootstrap.min.css
where 'assets' is my public folder.


On Tue, Jul 12, 2016 at 6:57 AM,  wrote:

> i have been having major issues making bootstrap style reflect on my
> html/template output and i'm wondering if there's any other way to go about
> this. my code below
> INDEX.HTML
>
> {{define "head"}}Dead Or Injured
> 
> 
> 
>
> 
> 
> {{end}}
>
> {{define "body"}}
> 
> 
> Input your guess: 
> Submit
> 
> 
>
>
> 
> {{range .}}
> 
> {{.}}
> 
> {{end}}
> 
>
> {{end}}
>
> And this is BASE.HTML
>
> {{define "base"}}
> 
> {{template "head" .}}
> {{template "body" .}}
> 
> {{end}}
>
> index.html and base.html are in the same folder so i don't think the
> folder structure is a problem except you think otherwise.
> Here's main.go
> func main() {
>mongo.GetSession()
>
>r := mux.NewRouter().StrictSlash(false)
>fs := http.FileServer(http.Dir("public"))
>r.Handle("/public/", fs)
>r.HandleFunc("/", gamePage)
>r.HandleFunc("/game/submit", functions.Submit)
>r.HandleFunc("/game/highscoreinput", scoreInputPage)
>r.HandleFunc("/game/postUser", mongo.PostUser)
>r.HandleFunc("/game/highscores", mongo.RetrieveUsers)
>
>server := {
>Addr:":8080",
>Handler: r,
>}
>log.Println("Listening...")
>server.ListenAndServe()
> }
>
> After all these, the template works fine and all the pnly bit remaining is
> for it to shake off the boring interface and make use of the bootstrap
> provided. 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] liteide x30.2 released

[paraiso . marc]

Nice Ctrl+P to navigate between files work well , it's like to be able to 
navigate between Symbols too. With a drop down menu .

Le mardi 12 juillet 2016 09:09:15 UTC+2, visualfc a écrit :
>
> Hi, all
>
> LiteIDE x30.2 released, This version bug fix and build test for Go1.7 rc1
>
>
> ### 2016.7.12 Ver X30.2
> * LiteApp
> * add new vs-dard css, thanks [tupunco](https://github.com/tupunco)
> * fix and re-implement editor list menu
> * QuickOpen
> * QuickOpenFile skip same folder and same files
> * QuickOpneFile add current editor local files
>

-- 
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] ARM big-endian support roadmap

[Igor Gatis]

AFAIK, big endian support for ARM is not available. Will it ever be
supported?

Out of curiosity, how hard is this task?

-- 
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] net/http: request canceled while waiting for connection

[DM]

Hi

We making some http PUT calls to a web server using net/http. Some time in 
the log we are seeing the below errors:-

{"level":"error","message":"Put 
http://blitz:2196/cache/api/v1/buckets/styloko/entities/product-xlarge-multi-sku-de898wa73oooindfas
: *read tcp **172.16.84.112:2196* *:* *use of 
closed network connection"*,"stackTraces":["/var/lib/jenkins/jobs/CI_
styloko_pkg_creation/workspace/styloko/src/amenities/products/common/
cache_manager.go(295)","/var/lib/jenkins/jobs/CI_styloko_
pkg_creation/workspace/styloko/src/amenities/products/get/search/
exactquery/node_response.go(127)","/usr/local/go/src/
runtime/asm_amd64.s(2232)"],"timestamp":"2016-07-11T19:30:29+05:30"}

{"level":"error","message":"Put 
http://blitz:2196/cache/api/v1/buckets/styloko/entities/product-xlarge-multi-sku-mi162bg58vblindfas
: *net/http: request canceled while waiting for connection"*
,"stackTraces":["/var/lib/jenkins/jobs/CI_styloko_pkg_creation/
workspace/styloko/src/amenities/products/common/
cache_manager.go(295)","/var/lib/jenkins/jobs/CI_styloko_
pkg_creation/workspace/styloko/src/amenities/products/get/search/
exactquery/node_response.go(127)","/usr/local/go/src/
runtime/asm_amd64.s(2232)"],"timestamp":"2016-07-11T19:30:32+05:30"}

Can some one please let me know when does the error "Use of closed network 
connection", "request canceled while waiting for connection" can come?

I am using go 1.5 on Debian 8 64 Bit.

Thanks,
D

-- 
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] ARM big-endian support roadmap

[Ian Lance Taylor]

On Tue, Jul 12, 2016 at 5:20 AM, Igor Gatis  wrote:
>
> AFAIK, big endian support for ARM is not available. Will it ever be
> supported?

If somebody works on it, and can provide a build machine for testing.
See https://github.com/golang/go/wiki/PortingPolicy .

> Out of curiosity, how hard is this task?

Probably pretty easy for someone with the hardware needed for testing.

Ian

-- 
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] How to allocate memory from OS in compatible way.

[Ian Lance Taylor]

On Tue, Jul 12, 2016 at 1:05 AM,   wrote:
> GCC slow, not GC.

Sorry, my apologies for misreading.

Ian

> вторник, 12 июля 2016 г., 1:52:01 UTC+3 пользователь Ian Lance Taylor
> написал:
>>
>> On Mon, Jul 11, 2016 at 1:25 PM,   wrote:
>> > Ohh that slow gcc. Sad.
>>
>> The GC in general is quite fast.  If you have specific examples where
>> the GC does poorly, please open issues for them with test cases.
>> Thanks.
>>
>> Ian
>>
>> > понедельник, 11 июля 2016 г., 23:03:07 UTC+3 пользователь Ian Lance
>> > Taylor
>> > написал:
>> >>
>> >> On Mon, Jul 11, 2016 at 9:11 AM,   wrote:
>> >> > Thank for answer but I'm already implemented portable unmanaged
>> >> > memory
>> >> > pool
>> >> > (https://github.com/ardente/goal/blob/master/gut/mempool.go). I'm
>> >> > just
>> >> > looking for standard direct analogue (incliding mapping of fd -1) of
>> >> > unix's
>> >> > syscall.Mmap for windows. Looks like there is none. There is some
>> >> > rationale
>> >> > behind this or just lack of time/interest?
>> >>
>> >> This is not something most Go programs are expected to do.
>> >>
>> >> Most Go programs that need to allocate memory that is not controlled
>> >> by the Go garbage collector are programs that already use cgo.  Those
>> >> programs can use C.malloc, which works on all systems.
>> >>
>> >> Ian
>> >
>> > --
>> > 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...@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.

[go-nuts] Re: New Context method in http.Request, what can we do with it?

[Matt Silverlock]

Sure, and that's why gorilla/mux uses context.Context internally.

gorilla/sessions (and mux) both existed well before context.Context did, 
and sessions can't be changed without breaking the public API. 


On Tuesday, July 12, 2016 at 4:20:59 AM UTC-7, parais...@gmail.com wrote:
>
> Don't you think it would be better to use context to hold session values 
> rather than using global variables like github.com/gorilla/sessions does 
> ? 
>
> Le lundi 11 juillet 2016 00:43:05 UTC+2, Matt Silverlock a écrit :
>>
>> Use it to pass connection/request-scoped values: that is, values that 
>> could only exist once you have a request. authentication tokens, user 
>> details, connection IDs: things that can't be known/generated before the 
>> connection has been received.
>>
>> e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass 
>> route-matching information back to the user (i.e. for /user/:name, the 
>> :name value). Don't use context to pass app-level dependencies, as it makes 
>> testing, reasoning and debugging hard.
>>
>>
>>
>> On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote:
>>>
>>> I'm really excited to see context.Context become a first class citizen 
>>> in Go 1.7. After using context, it feels like a natural way to write Go 
>>> network code and it fits naturally in the standard library. I'm trying to 
>>> figure out how I can improve existing code with the new features that come 
>>> with it.
>>>
>>> In Go 1.7, requests now can contain a context, and the context can be 
>>> changed. This seems really cool, but I don't know what exactly I can do 
>>> that I can't do before, other than what the documentation specifically 
>>> outlines: "For outgoing client requests, the context controls cancelation."
>>>
>>> Is there anything else we will be able to do that I should be looking 
>>> into? What are your plans?
>>>
>>

-- 
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] Re: New Context method in http.Request, what can we do with it?

[paraiso . marc]

Don't you think it would be better to use context to hold session values 
rather than using global variables like github.com/gorilla/sessions does ? 

Le lundi 11 juillet 2016 00:43:05 UTC+2, Matt Silverlock a écrit :
>
> Use it to pass connection/request-scoped values: that is, values that 
> could only exist once you have a request. authentication tokens, user 
> details, connection IDs: things that can't be known/generated before the 
> connection has been received.
>
> e.g. gorilla/mux (https://github.com/gorilla/mux) uses it to pass 
> route-matching information back to the user (i.e. for /user/:name, the 
> :name value). Don't use context to pass app-level dependencies, as it makes 
> testing, reasoning and debugging hard.
>
>
>
> On Thursday, July 7, 2016 at 4:03:18 PM UTC-7, Tyler Compton wrote:
>>
>> I'm really excited to see context.Context become a first class citizen in 
>> Go 1.7. After using context, it feels like a natural way to write Go 
>> network code and it fits naturally in the standard library. I'm trying to 
>> figure out how I can improve existing code with the new features that come 
>> with it.
>>
>> In Go 1.7, requests now can contain a context, and the context can be 
>> changed. This seems really cool, but I don't know what exactly I can do 
>> that I can't do before, other than what the documentation specifically 
>> outlines: "For outgoing client requests, the context controls cancelation."
>>
>> Is there anything else we will be able to do that I should be looking 
>> into? What are your plans?
>>
>

-- 
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] Proposal: Add coloured output to go commands

[Dan Kortschak]

github.com/maruel/panicparse is a good package to do this if you need
it.

On Tue, 2016-07-12 at 22:26 -0700, Ian Lance Taylor wrote:
> On Tue, Jul 12, 2016 at 9:36 PM, Zac Pullar-Strecker  wrote:
> > Commands like go run, go build and go test amoung others should have
> > coloured output when an error occurs. it would make reading stack traces a
> > lot easier. I personally use the go run tool a lot during development
> > because I have no reason to keep a binary in the $GOPATH/bin directory when
> > it's likely to change in the next 5 minutes.
> >
> > github.com/fatih/color & github.com/kortschak/ct are os agnostic (Unix &
> > Windows,) packages for ANSI escape codes.
> > It would make sense to do this with a flag -c or -color and anyone who
> > wanted it perminantly could alias it.
> > I'm relatively new to the community so I wanted to post it here before
> > creating an issue on github. Are there any issues with doing this?
> 
> I think this is unlikely to be accepted.
> 
> Much more plausible would be a go-gettable colorizing filter that you
> can apply to the go tool output.  Then you could run a shell script
> that pipes go through that filter.
> 
> Ian


-- 
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] Proposal: Add coloured output to go commands

[Ian Lance Taylor]

On Tue, Jul 12, 2016 at 9:36 PM, Zac Pullar-Strecker  wrote:
> Commands like go run, go build and go test amoung others should have
> coloured output when an error occurs. it would make reading stack traces a
> lot easier. I personally use the go run tool a lot during development
> because I have no reason to keep a binary in the $GOPATH/bin directory when
> it's likely to change in the next 5 minutes.
>
> github.com/fatih/color & github.com/kortschak/ct are os agnostic (Unix &
> Windows,) packages for ANSI escape codes.
> It would make sense to do this with a flag -c or -color and anyone who
> wanted it perminantly could alias it.
> I'm relatively new to the community so I wanted to post it here before
> creating an issue on github. Are there any issues with doing this?

I think this is unlikely to be accepted.

Much more plausible would be a go-gettable colorizing filter that you
can apply to the go tool output.  Then you could run a shell script
that pipes go through that filter.

Ian

-- 
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] if something not perfect here

[Ian Lance Taylor]

On Tue, Jul 12, 2016 at 8:07 PM, wweir9  wrote:

> These are two screeshot from os/exec , it looks like that code below will
> always be true.
> len(c.Args) > 0
>
>
>
> 
>
>
> 
>
>
It's not absolutely required to use the Command function.

Ian

-- 
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] Plurality of package naming

[Nathan Fisher]

struct and class semantics aren't equivalent but they are similar. Which is
why I think the rule "avoid -er" is relevant. If you're struggling to name
something then you probably don't know what it is and what it needs to do.

I'm not advocating going to the Java extreme of fifty syllable names.
Rather I'm siding with the principle that poor names are a smell of they
don't fit or are buckets for random bits of code (eg util).
On Wed, 13 Jul 2016 at 00:26, Thomas Bushnell, BSG 
wrote:

> That's advice for a very different style of language than Go.
>
> Go does not have "objects" in the sense of that post. A Go interface, for
> example, does not "have lots of instance variables, lots of arguments, and
> pass lots of data around probably."
>
> A class is not a struct is not a Go interface.
>
> Thomas
>
> On Tue, Jul 12, 2016 at 4:23 PM Nathan Fisher 
> wrote:
>
>> There's a good oop blog article on the caveats of naming classes (struct)
>> ending in -er.
>>
>> http://objology.blogspot.co.uk/2011/09/one-of-best-bits-of-programming-advice.html?m=1
>>
>> I know the reader/writer interface kind of flies in the face of this but
>> I think that's partly associated with it being an interface and its focus
>> on one method.
>>
>> Personally if it's RESTy I'd opt for BlahResource where Blah is the
>> resource that it manages which will probably map to an underlying
>> serialisable struct with additional REST elements (eg next, self, etc).
>>
>> On Tue, 12 Jul 2016 at 17:41, Sam Whited  wrote:
>>
>>> On Tue, Jul 12, 2016 at 9:19 AM, Rayland  wrote:
>>> > When does it make sense for a package to be named in plural? For
>>> example,
>>> > I'm currently working on a MVC framework and for me it makes sense to
>>> have a
>>> > "controller" package as opposed to "controllers", but I saw that Beego
>>> > prefers plural for the same case.
>>>
>>> Generally speaking, try to consider how your users will write things
>>> that use your package and not what's actually in it. For instance,
>>> which makes the better API:
>>>
>>> controller.New()
>>>
>>> or:
>>>
>>> controllers.NewController()
>>>
>>> The second is redundant, so I'd argue that the first one will look
>>> better in your users code. However, given the example:
>>>
>>> byte.Split(b []byte)
>>>
>>> vs.
>>>
>>> bytes.Split(b []byte)
>>>
>>> the second may be more expected because you're operating on a collection.
>>>
>>> Of course, both of these are just my opinion, but it's just to
>>> illustrate how I generally think about picking a name. Instead of
>>> "what will my code in the package look like" think "what will my users
>>> write using this package?"
>>>
>>> —Sam
>>>
>>> --
>>> 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] Initializing a channel as "Closed" so that it doesn't block if a "Thing" hasn't been done yet

[Harmen B]

I don't understand the problems 100%, but maybe these things can point you
in the right direction:

- try to see if using a sync.WaitGroup{} can help you. WaitGroups are great
to use when you need to keep track of a varying bunch of Go routines.
- you can send channels over channels, to wait for things to happen.
In pseudo-pseudo-code:

type myThing struct {
quit chan chan struct{}
}

func (m *myThing) Quit() {
q := make(chan struct{})
m.quit <- q
<- q
}

elsewhere:

for {
select {
case <-somewhere:
// do something.
case q := <- m.quit:
// tell all Go routines to quit and wait for that. Maybe
using a WaitGroup
close(q)
}
}

On Wed, Jul 13, 2016 at 6:28 PM, Evan Digby  wrote:

> Hi All,
>
> I'm looking for some advice on a pattern I've found myself trapped in. I
> don't think I like it.
>
> For all examples, assume I have to meet the following interface (enforced
> externally):
>
> type DoerCloser interface {
> Do()
> Close()
> }
>
>
> The code below is mostly snippets from:
>
> https://play.golang.org/p/RQp97u4ZeK
>
> First, the part that seems standard (or is this my first incorrect
> assumption?):
>
> I'm using a "closed" (or "closing") channel to tell all methods on a
> struct that the user has asked us to close, and then a "done" channel to
> allow the methods to alert that they're done.
>
> func (t *doerCloser) do() {
> t.doneDoing = make(chan struct{})
> defer close(t.doneDoing)
> for {
> select {
> case <-t.closed:
> return
> case <-time.After(time.Second):
> fmt.Println("Doing a thing!")
> }
> }
> }
>
> func (t *doerCloser) Close() {
> close(t.closed)
> <-t.doneDoing
> }
>
> This works fine if the "New" function that creates the struct kicks off
> the action, and therefore the "doneDoing" channel is always created and in
> a good state.
>
> func NewDoerCloser1() DoerCloser {
> dc := {
> closed: make(chan struct{}),
> }
> go dc.do()
> return dc
> }
>
> User can do the following safely:
>
> dc := NewDoerCloser1()
> defer dc.Close()
>
>
> Where it gets tricky is if "Do" can't be kicked off right away. In my
> current real-world example I need to meet an external interface, and the
> interface dictates that "Do" kicks of the thing--in other examples perhaps
> you simply want the user to be able to explicitly start the doing.
>
> // If "do" is never called, Close will "Block" because it's a nil channel
> func NewDoerCloser2() DoerCloser {
> return {
> closed: make(chan struct{}),
> }
> }
>
> If "do" is never called, then "Close" will block forever on:
>
> <-t.doneDoing.
>
> One solution would be to create "doneDoing" and then close it immediately.
> Seems crazy to me; however, It's fairly simple so perhaps it isn't crazy?
>
> func NewDoerCloser3() DoerCloser {
> doneDoing := make(chan struct{})
> defer close(doneDoing)
>
> return {
> closed:make(chan struct{}),
> doneDoing: doneDoing,
> }
> }
>
> Another solution would be to "kick off" the "Do" functionality, but have
> it wait to start processing until "Do" is explicitly called. This seems
> much more complex than the "create and close immediately" idea.
>
> func NewDoerCloser() DoerCloser {
> dc := {
> closed:   make(chan struct{}),
> doCalled: make(chan struct{}),
> }
>
> go dc.do()
>
> return dc
> }
>
> func (t *doerCloser) do() {
> t.doneDoing = make(chan struct{})
> defer close(t.doneDoing)
>
> select {
> case <-t.closed:
> return
> case <-t.doCalled:
> }
>
> // Let's start doing!
>
> for {
> select {
> case <-t.closed:
> return
> case <-time.After(time.Millisecond):
> fmt.Println("Doing a thing!")
> }
> }
> }
>
>
> https://play.golang.org/p/qA3_oFF_EP
>
> Any other options? Am I totally crazy? Is this overcomplicated and there
> is a much simpler solution I'm spacing on?
>
> Thank's everyone!
>
> Evan
>
> --
> 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] exec.Cmd: if the child forks Wait may hang forever

[Steven Hartland]

If your forked process still has stdin / stdout open then I would say 
this is expected.


You could confirm this by adding the following to the python script.
import sys
...
if pid == 0:
   sys.stdin.close()
   sys.stdout.close()

On 13/07/2016 21:50, noxiouz wrote:

Good day!

I faced a corner case of cmd.Exec usage and want to find out if it's 
designed behavior.



go version go1.6.2 darwin/amd64 and linux


Let's assume we use cmd.Exec to start some process, that can fork and 
dies, but the fork will live forever. For example:


|
#!/usr/bin/env python

importos
importtime

pid =os.fork()
ifpid ==0:
whileTrue:
time.sleep(10)

print"main process has quited"

|

The real script is much more complicated but it's not important.

Also there is a go code:

|
packagemain

import(
"io"
"log"
"os/exec"
)

func main(){
cmd :=exec.Command("./forker.py")
rd,wr :=io.Pipe()
cmd.Stdout=wr
go func(){
b :=make([]byte,100)
for{
nn,err :=rd.Read(b)
ifnn >0{
log.Printf("%s",b[:nn])
}
iferr !=nil{
log.Fatal(err)
return
}
}
}()
iferr :=cmd.Start();err !=nil{
log.Fatal(err)
}

log.Printf("PID %d",cmd.Process.Pid)

iferr :=cmd.Wait();err !=nil{
log.Fatal(err)
}
}
|

The output would be like this:

2016/07/13 23:40:20 PID 90614
2016/07/13 23:40:20 main process has quited


but the Go process will hang forever, because of waiting on: 
https://github.com/golang/go/blob/release-branch.go1.6/src/os/exec/exec.go#L401

I think, because stdout fd of child process would not be closed .

On the other hand the next code works perfectly and does not hang:

|
packagemain

import(
"log"
"os/exec"
)

func main(){
cmd :=exec.Command("./forker.py")
rd,err :=cmd.StdoutPipe()
iferr !=nil{
log.Fatal(err)
}
go func(){
b :=make([]byte,100)
for{
nn,err :=rd.Read(b)
ifnn >0{
log.Printf("%s",b[:nn])
}
iferr !=nil{
log.Fatal(err)
return
}
}
}()
iferr :=cmd.Start();err !=nil{
log.Fatal(err)
}

log.Printf("PID %d",cmd.Process.Pid)

iferr :=cmd.Wait();err !=nil{
log.Fatal(err)
}
}

|

So I would like to find out if setting cmd.Stdout explicitly is not 
expected.



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] filepath.Clean

[Anmol Sethi]

I’ve cced him, hopefully he can state exactly why.

> On Jul 13, 2016, at 4:02 PM, Ian Lance Taylor  wrote:
> 
> On Wed, Jul 13, 2016 at 10:40 AM, Anmol Sethi  wrote:
>> Why does filepath.Clean replace each slash with a separator at the end of 
>> the function? What’s the point of attempting to clean it if the separator 
>> used is incorrect? Wouldn’t doing this at the start of the function make 
>> more sense?
> 
> It dates back to https://golang.org/cl/4758051 in 2011.  I would guess
> that Alex thought it would be simpler to just do it at the end rather
> than reworking the rest of the function.
> 
> Ian
> 
> -- 
> 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] Re: exec.Cmd: if the child forks Wait may hang forever

[noxiouz]

https://github.com/golang/go/blob/master/src/os/exec/exec.go#L484 set 
io.Writer explicitly so it looks like a bug

среда, 13 июля 2016 г., 23:50:56 UTC+3 пользователь noxiouz написал:
>
> Good day!
>
> I faced a corner case of cmd.Exec usage and want to find out if it's 
> designed behavior.
>
>
> go version go1.6.2 darwin/amd64 and linux
>>
>
> Let's assume we use cmd.Exec to start some process, that can fork and 
> dies, but the fork will live forever. For example:
>
> #!/usr/bin/env python
>
> import os
> import time
>
> pid = os.fork()
> if pid == 0:
> while True:
> time.sleep(10)
>
> print "main process has quited"
>
>
> The real script is much more complicated but it's not important.
>
> Also there is a go code:
>
> package main
>
> import (
> "io"
> "log"
> "os/exec"
> )
>
> func main() {
> cmd := exec.Command("./forker.py")
> rd, wr := io.Pipe()
> cmd.Stdout = wr
> go func() {
> b := make([]byte, 100)
> for {
> nn, err := rd.Read(b)
> if nn > 0 {
> log.Printf("%s", b[:nn])
> }
> if err != nil {
> log.Fatal(err)
> return
> }
> }
> }()
> if err := cmd.Start(); err != nil {
> log.Fatal(err)
> }
>
> log.Printf("PID %d", cmd.Process.Pid)
>
> if err := cmd.Wait(); err != nil {
> log.Fatal(err)
> }
> }
>
> The output would be like this:
>
> 2016/07/13 23:40:20 PID 90614
>> 2016/07/13 23:40:20 main process has quited
>>
>  
> but the Go process will hang forever, because of waiting on: 
> https://github.com/golang/go/blob/release-branch.go1.6/src/os/exec/exec.go#L401
> I think, because stdout fd of child process would not be closed .
>
> On the other hand the next code works perfectly and does not hang:
>
> package main
>
> import (
> "log"
> "os/exec"
> )
>
> func main() {
> cmd := exec.Command("./forker.py")
> rd, err := cmd.StdoutPipe()
> if err != nil {
> log.Fatal(err)
> }
> go func() {
> b := make([]byte, 100)
> for {
> nn, err := rd.Read(b)
> if nn > 0 {
> log.Printf("%s", b[:nn])
> }
> if err != nil {
> log.Fatal(err)
> return
> }
> }
> }()
> if err := cmd.Start(); err != nil {
> log.Fatal(err)
> }
>
> log.Printf("PID %d", cmd.Process.Pid)
>
> if err := cmd.Wait(); err != nil {
> log.Fatal(err)
> }
> }
>
>
> So I would like to find out if setting cmd.Stdout explicitly is not 
> expected.
>
>
> 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.

Re: [go-nuts] exec.Cmd: if the child forks Wait may hang forever

[Ian Lance Taylor]

On Wed, Jul 13, 2016 at 1:50 PM, noxiouz  wrote:
>
> I faced a corner case of cmd.Exec usage and want to find out if it's
> designed behavior.

...

> So I would like to find out if setting cmd.Stdout explicitly is not
> expected.

Sounds like https://golang.org/issue/13155 .

Ian

-- 
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] Re: How to make the first character in a string lowercase?

[Tamás Gulácsi]

But this works only for ASCII input!

-- 
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.