[go-nuts] Set LD_LIBRARY_PATH while executing go test

[lakshmibc8]

Hello,

Is there a way to set the LD_LIBRARY_PATH while executing go test command? 

My version is "go version go1.5.1 linux/amd64"

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] genmap: Generate thread-safe, type-safe maps easily

[ammar]

https://github.com/ammario/mapgen


Features:

   - Supports any key/value pair supported by Go's native maps
   - Allows complex operations via Lock() and Unlock()
   - Generated code conforms to golint and gofmt
   - Allows custom types
   - Sensible default file name and map name
   

-- 
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: chidley: XML to Go structs

[Glen Newton]

Without your XML file I cannot figure out the issue.
If you are OK with sharing your XML file, please post it with the issue at: 
https://github.com/gnewton/chidley/issues

Thanks,
Glen


On Wednesday, June 14, 2017 at 2:54:28 PM UTC-4, shrinkhala singhania wrote:
>
> Hi,
>
> I tried running my XML file and throws this error:
>
>
> chidley$chidley -W xml/openconfig.xml > examples/oc/openconfig1.go
>
> chidley$cd examples/oc/
>
> oc$go build
>
># github.com/gnewton/chidley/examples/oc
>
>   ./openconfig1.go:3361: Chiroot redeclared in this block
>
>previous declaration at ./openconfig1.go:213
>
> Regards,
> Shrinkhala
>
> On Wed, Jun 14, 2017 at 2:25 PM, Shrinkhala Singhania <
> singhani...@gmail.com > wrote:
>
>> That worked. Thanks.
>>
>> Regards,
>> Shrinkhala
>>
>> On Wed, Jun 14, 2017 at 2:22 PM, Ian Lance Taylor > > wrote:
>>
>>> On Wed, Jun 14, 2017 at 11:08 AM,   
>>> wrote:
>>> > I have this in my bash_profile:
>>> >
>>> > export PATH=/usr/local/bin:/usr/local/sbin:$PATH
>>> >
>>> > export GOPATH = /Users/ssinghania/go/
>>> >
>>> > export CLASSPATH=".:/usr/local/lib/antlr-4.6-complete.jar:$CLASSPATH"
>>>
>>> OK, so do what I suggested.  You need something like
>>>
>>> export PATH=/usr/local/bin:/usr/local/sbin:/Users/ssinghania/go/bin:$PATH
>>>
>>> Ian
>>>
>>>
>>> > On Wednesday, June 14, 2017 at 1:53:53 PM UTC-4, Ian Lance Taylor 
>>> wrote:
>>> >>
>>> >> On Wed, Jun 14, 2017 at 10:19 AM,   wrote:
>>> >> >
>>> >> > To install chidley, I did the following:
>>> >> >
>>> >> > go get github.com/gnewton/chidley
>>> >> >
>>> >> > This worked. However, issue on
>>> >> >
>>> >> >
>>> >> > chidley -W xml/test1.xml > examples/test/ChildTest1.go
>>> >> >
>>> >> > -bash: chidley: command not found
>>> >> >
>>> >> > How do I fix this?
>>> >>
>>> >> Put $GOPATH/bin on your PATH.  If you haven't set $GOPATH, the default
>>> >> is $HOME/go.
>>> >>
>>> >> 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.

Re: [go-nuts] Re: KVs store for large strings

[James Pettyjohn]

Thanks for the follow-up!

That ended up being the approach I took - map two levels deep (because 
that's how the keys come through) and load everything at start up and use 
as an immutable structure. While in dev it is using the old code 
essentially and that's fine.

I also noted that internal structure in the old code using a struct {x 
string, y string} for its first level key which I thought odd. Not sure 
what effects that would have on things.

Best,
James

On Thursday, June 15, 2017 at 8:17:47 AM UTC-7, ksug wrote:
>
> There were mistakes with the code I posted. Oh well, in a hurry and not 
> the point. 
>
>
>
> On 15/06/17 22:41, Kiki Sugiaman wrote: 
> > I think I misunderstood what you were trying to accomplish. Let me try 
> > to rephrase and see if I'm getting closer: 
> > 
> > - to accommodate template changes during development, you introduced 
> > read-locking to your app. 
> > - as a result, your reads in production are slow. Never mind the fact 
> > that locking is pointless in production because the templates don't 
> change. 
> > - ideally, you want your reads to yield to template changes during 
> > development, but go lockless in production. 
> > 
> > If the above are correct, then the solution is not data structure 
> > change, but code swapping during init() depending on the environment 
> > variable $DEVMODE (or whatever you want to call it). 
> > 
> > Example: 
> > https://play.golang.org/p/wqb9lVIPLa 
> > (repeat several times and change the random seed to randomize the 
> > behavior a bit) 
> > 
> > Of course, optimizing the data structure doesn't hurt. And to answer 
> > your question, yes map can handle 10's of thousands entries with 100MB 
> > raw data with *relative* ease. 
> > 
> > 
> > 
> > On 15/06/17 15:45, James Pettyjohn wrote: 
> >> I looked at doing boltdb but ended up with a slightly simpler 
> >> approach. I don't need the disk persistence in this case. 
> >> 
> >> I tried radix tree implementation but found it slower than my current 
> >> nested map with locks. In that interest I rewrote the nested map 
> >> approach considering the key partitioning noted by Robert. 
> >> 
> >> The primary differences in my approach this time were: 
> >> 1) Read the whole dataset once treat it as immutable, no locking 
> >> 2) Align the API to no require any manipulation of the keys after the 
> >> first load, so every lookup is now 0 allocation. 
> >> 
> >> The structure is a simplistic map[string]map[string]string - language 
> >> -> key. There was a breakdown of the second map further in the 
> >> previous implementation, probably bringing it from a few thousand to a 
> >> few hundred each. Don't know what the threshold on the benefits there, 
> >> based on my experience the map implementation can handle 10s of 
> >> thousands with ease. 
> >> 
> >> This brought the lookups down by about 50%: 
> >> 
> >> BenchmarkLookupLooseLazy-8 300 458 ns/op 32 B/op 1 allocs/op 
> >> BenchmarkLookupLooseMap-8 500 265 ns/op 0 B/op 0 allocs/op 
> >> 
> >> Let me know if see anything else worth adjusting. 
> >> 
> >> Best, 
> >> James 
> >> 
> >> 
> >> On Wednesday, June 14, 2017 at 2:01:44 PM UTC-7, Robert Johnstone 
> wrote: 
> >> 
> >> I'm surprised that the memory overhead is significant - 100 MB is 
> >> not that much. 
> >> 
> >> Assuming that you don't need atomic updates to the entire KV store, 
> >> partition the keys. 
> >> 
> >> Does the periodic reload involve changing the keys?  If not, you 
> >> could map the dataset into nested structs.  However, you will still 
> >> need to synchronise access if you want to to reload without 
> stopping 
> >> the server, but that would just be the leaves.  Switching just the 
> >> top-tier to a struct could help with the contention. 
> >> 
> >> 
> >> On Wednesday, 14 June 2017 14:45:25 UTC-4, James Pettyjohn wrote: 
> >> 
> >> I have an application which has all of it's text, multiple 
> >> languages, stored in XML on disk that is merged into templates 
> >> on the fly. About 100MB. Templates use dozens of strings for 
> >> each render. 
> >> 
> >> Currently this is loaded in full into memory in a bunch of tier 
> >> hash maps. They are lazy loaded and using multiple locks to 
> >> perform reads but, unless in dev mode, actually don't change 
> >> throughout the lifetime of the application and should be 
> >> considered immutable. 
> >> 
> >> While workable at a smaller scale, it's slow at scale. The most 
> >> important factor is concurrent lookup speed, secondary concern 
> >> is memory overhead. And it cannot preclude periodic reload 
> while 
> >> doing dev. 
> >> 
> >> Is there a data structure or lib that suits this scenarios more 
> >> than others? 
> >> 
> >> -- 
> >> You received this message because you are subscribed to the Google 
> >> Groups "golang-nuts" group. 
> 

[go-nuts] Re: Go 1.9 Beta 1 is released

[G. R. Rocha]

thank you

Em quarta-feira, 14 de junho de 2017 19:15:49 UTC-3, Chris Broadfoot 
escreveu:
>
> Hello gophers,
>
> We have just released go1.9beta1, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta1.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new 
> version.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 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.

Re: [go-nuts] Curious about this snippet in /src/runtime/proc.go

[Rob Pike]

Code comments can be helpful with unusual situations like this.

-rob


On Fri, Jun 16, 2017 at 4:25 AM, Goodwin Lawlor 
wrote:

> Thanks for the explanation.
>
> My random guess was that it's the compiler version of deleting your
> browser cache... If exit fails, blank as much memory as we can get our
> hands on. 
>
> On 15 Jun 2017 6:34 pm, "Ian Lance Taylor"  wrote:
>
>> On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton 
>> wrote:
>> > Why not just panic, though? And why the infinite loop, I wonder?
>>
>> The runtime is a special case in many ways, and this is among the more
>> special parts.  This loop exists to catch problems while testing new
>> ports.  If that loop is ever reached, something has gone badly wrong:
>> the exit call should have caused the program to exit.  We can't assume
>> that panic is working.  We can't really assume that anything is
>> working.  What we want to do is stop the program.  Since exit failed,
>> it's possible that a nil dereference will succeed.  If that fails too,
>> we still have to do something, so we just loop.  We can't return
>> because this is the main function that started the program; there is
>> nothing to return to.
>>
>> Ian
>>
>> > On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:
>> >>
>> >> Force a panic in case exit fails?
>> >>
>> >> --
>> >> -- Aldrin Leal,  / http://about.me/aldrinleal
>> >>
>> >> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
>> >>>
>> >>> Hey,
>> >>>
>> >>> Learning golang at the moment and came across this at the end of func
>> >>> main() in proc.go in the golang source tree.
>> >>>
>> >>> exit(0)
>> >>> for {
>> >>> var x *int32
>> >>> *x = 0
>> >>> }
>> >>>
>> >>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>> >>>
>> >>> How is the for loop ever reached and what's the purpose of the
>> infinite
>> >>> loop, zeroing memory?
>> >>>
>> >>> Thanks,
>> >>>
>> >>> Goodwin
>> >>>
>> >>> --
>> >>> 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.
>> >
>> > --
>> > Tyler Compton
>> > Software Engineering
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to golang-nuts+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go 1.9 Beta 1 is released

[Henrik Johansson]

Ah well. Still cool though!

On Thu, 15 Jun 2017, 22:12 Ian Lance Taylor,  wrote:

> On Thu, Jun 15, 2017 at 12:16 PM, Henrik Johansson 
> wrote:
> >
> > I must have missed this but just clarify my thoughts are all file reads
> > async now? That would a pretty big deal for apps that read a lot of
> files.
>
> That would be nice but in practice most systems do not support
> pollable I/O on disk files.  So, no.
>
> Reads and writes to pipes (from os.Pipe) are now asynchronous.
>
> 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: Go 1.9 Beta 1 is released

[Ian Lance Taylor]

On Thu, Jun 15, 2017 at 12:16 PM, Henrik Johansson  wrote:
>
> I must have missed this but just clarify my thoughts are all file reads
> async now? That would a pretty big deal for apps that read a lot of files.

That would be nice but in practice most systems do not support
pollable I/O on disk files.  So, no.

Reads and writes to pipes (from os.Pipe) are now asynchronous.

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: Go 1.9 Beta 1 is released

[Henrik Johansson]

I must have missed this but just clarify my thoughts are all file reads
async now? That would a pretty big deal for apps that read a lot of files.

tors 15 juni 2017 kl 19:30 skrev Ian Lance Taylor :

> On Thu, Jun 15, 2017 at 7:37 AM,   wrote:
> >
> > With go1.9beta1 (Linux / amd64) I noticed an extra file descriptor that I
> > cannot explain.
> > A simple example is after calling ioutil.ReadDir().
> >
> > package main
> > import (
> >
> >"fmt"
> >
> >"io/ioutil"
> >
> > )
> >
> > func main() {
> >
> >_, err := ioutil.ReadDir(".")
> >
> >if err != nil {
> >
> >panic(err)
> >
> >}
> >
> >fmt.Scanln()
> >
> > }
> >
> >
> > sudo lsof -p `pidof fd-go1.9beta1`
> > COMMANDPID  USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
> > fd-go1.9b 3698 peter  cwd   DIR8,2 4096 23596911
> > /home/peter/go/src/fd
> > fd-go1.9b 3698 peter  rtd   DIR8,2 40962 /
> > fd-go1.9b 3698 peter  txt   REG8,2  1964089 23596832
> > /home/peter/go/src/fd/fd-go1.9beta1
> > fd-go1.9b 3698 peter0u  CHR  136,1  0t04 /dev/pts/1
> > fd-go1.9b 3698 peter1u  CHR  136,1  0t04 /dev/pts/1
> > fd-go1.9b 3698 peter2u  CHR  136,1  0t04 /dev/pts/1
> > fd-go1.9b 3698 peter4u  a_inode   0,120 9667 [eventpoll]
> >
> > FD #4 doesn't show up with go1.8.3. Is this expected, a bug or something
> > else?
>
> In 1.9 the os package now uses the event poller that the net package
> has always used.
>
> I sent https://golang.org/cl/45910 to add that to the release notes.
>
> 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.

Re: [go-nuts] Curious about this snippet in /src/runtime/proc.go

[Goodwin Lawlor]

Thanks for the explanation.

My random guess was that it's the compiler version of deleting your browser
cache... If exit fails, blank as much memory as we can get our hands on. 

On 15 Jun 2017 6:34 pm, "Ian Lance Taylor"  wrote:

> On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton  wrote:
> > Why not just panic, though? And why the infinite loop, I wonder?
>
> The runtime is a special case in many ways, and this is among the more
> special parts.  This loop exists to catch problems while testing new
> ports.  If that loop is ever reached, something has gone badly wrong:
> the exit call should have caused the program to exit.  We can't assume
> that panic is working.  We can't really assume that anything is
> working.  What we want to do is stop the program.  Since exit failed,
> it's possible that a nil dereference will succeed.  If that fails too,
> we still have to do something, so we just loop.  We can't return
> because this is the main function that started the program; there is
> nothing to return to.
>
> Ian
>
> > On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:
> >>
> >> Force a panic in case exit fails?
> >>
> >> --
> >> -- Aldrin Leal,  / http://about.me/aldrinleal
> >>
> >> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
> >>>
> >>> Hey,
> >>>
> >>> Learning golang at the moment and came across this at the end of func
> >>> main() in proc.go in the golang source tree.
> >>>
> >>> exit(0)
> >>> for {
> >>> var x *int32
> >>> *x = 0
> >>> }
> >>>
> >>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
> >>>
> >>> How is the for loop ever reached and what's the purpose of the infinite
> >>> loop, zeroing memory?
> >>>
> >>> Thanks,
> >>>
> >>> Goodwin
> >>>
> >>> --
> >>> 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.
> >
> > --
> > Tyler Compton
> > Software Engineering
> >
> > --
> > 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] Curious about this snippet in /src/runtime/proc.go

[Tyler Compton]

Very interesting. I'm not used to looking at Go code from the perspective
of an implementer of Go.

Somebody should contribute a comment about this upstream :)

On Thu, Jun 15, 2017 at 10:34 AM Ian Lance Taylor  wrote:

> On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton  wrote:
> > Why not just panic, though? And why the infinite loop, I wonder?
>
> The runtime is a special case in many ways, and this is among the more
> special parts.  This loop exists to catch problems while testing new
> ports.  If that loop is ever reached, something has gone badly wrong:
> the exit call should have caused the program to exit.  We can't assume
> that panic is working.  We can't really assume that anything is
> working.  What we want to do is stop the program.  Since exit failed,
> it's possible that a nil dereference will succeed.  If that fails too,
> we still have to do something, so we just loop.  We can't return
> because this is the main function that started the program; there is
> nothing to return to.
>
> Ian
>
> > On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:
> >>
> >> Force a panic in case exit fails?
> >>
> >> --
> >> -- Aldrin Leal,  / http://about.me/aldrinleal
> >>
> >> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
> >>>
> >>> Hey,
> >>>
> >>> Learning golang at the moment and came across this at the end of func
> >>> main() in proc.go in the golang source tree.
> >>>
> >>> exit(0)
> >>> for {
> >>> var x *int32
> >>> *x = 0
> >>> }
> >>>
> >>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
> >>>
> >>> How is the for loop ever reached and what's the purpose of the infinite
> >>> loop, zeroing memory?
> >>>
> >>> Thanks,
> >>>
> >>> Goodwin
> >>>
> >>> --
> >>> 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.
> >
> > --
> > Tyler Compton
> > Software Engineering
> >
> > --
> > 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.
>
-- 
Tyler Compton
Software Engineering

-- 
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] Curious about this snippet in /src/runtime/proc.go

[Ian Lance Taylor]

On Thu, Jun 15, 2017 at 10:28 AM, Tyler Compton  wrote:
> Why not just panic, though? And why the infinite loop, I wonder?

The runtime is a special case in many ways, and this is among the more
special parts.  This loop exists to catch problems while testing new
ports.  If that loop is ever reached, something has gone badly wrong:
the exit call should have caused the program to exit.  We can't assume
that panic is working.  We can't really assume that anything is
working.  What we want to do is stop the program.  Since exit failed,
it's possible that a nil dereference will succeed.  If that fails too,
we still have to do something, so we just loop.  We can't return
because this is the main function that started the program; there is
nothing to return to.

Ian

> On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:
>>
>> Force a panic in case exit fails?
>>
>> --
>> -- Aldrin Leal,  / http://about.me/aldrinleal
>>
>> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
>>>
>>> Hey,
>>>
>>> Learning golang at the moment and came across this at the end of func
>>> main() in proc.go in the golang source tree.
>>>
>>> exit(0)
>>> for {
>>> var x *int32
>>> *x = 0
>>> }
>>>
>>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>>>
>>> How is the for loop ever reached and what's the purpose of the infinite
>>> loop, zeroing memory?
>>>
>>> Thanks,
>>>
>>> Goodwin
>>>
>>> --
>>> 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.
>
> --
> Tyler Compton
> Software Engineering
>
> --
> 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] Curious about this snippet in /src/runtime/proc.go

[Aldrin Leal]

I don't know.

On Jun 15, 2017 12:29, "Tyler Compton"  wrote:

> Why not just panic, though? And why the infinite loop, I wonder?
>
> On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:
>
>> Force a panic in case exit fails?
>>
>> --
>> -- Aldrin Leal,  / http://about.me/aldrinleal
>>
>> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
>>
>>> Hey,
>>>
>>> Learning golang at the moment and came across this at the end of func
>>> main() in proc.go in the golang source tree.
>>>
>>> exit(0)
>>> for {
>>> var x *int32
>>> *x = 0
>>> }
>>>
>>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>>>
>>> How is the for loop ever reached and what's the purpose of the infinite
>>> loop, zeroing memory?
>>>
>>> Thanks,
>>>
>>> Goodwin
>>>
>>> --
>>> 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.
>>
> --
> Tyler Compton
> Software Engineering
>

-- 
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: Go 1.9 Beta 1 is released

[Ian Lance Taylor]

On Thu, Jun 15, 2017 at 7:37 AM,   wrote:
>
> With go1.9beta1 (Linux / amd64) I noticed an extra file descriptor that I
> cannot explain.
> A simple example is after calling ioutil.ReadDir().
>
> package main
> import (
>
>"fmt"
>
>"io/ioutil"
>
> )
>
> func main() {
>
>_, err := ioutil.ReadDir(".")
>
>if err != nil {
>
>panic(err)
>
>}
>
>fmt.Scanln()
>
> }
>
>
> sudo lsof -p `pidof fd-go1.9beta1`
> COMMANDPID  USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
> fd-go1.9b 3698 peter  cwd   DIR8,2 4096 23596911
> /home/peter/go/src/fd
> fd-go1.9b 3698 peter  rtd   DIR8,2 40962 /
> fd-go1.9b 3698 peter  txt   REG8,2  1964089 23596832
> /home/peter/go/src/fd/fd-go1.9beta1
> fd-go1.9b 3698 peter0u  CHR  136,1  0t04 /dev/pts/1
> fd-go1.9b 3698 peter1u  CHR  136,1  0t04 /dev/pts/1
> fd-go1.9b 3698 peter2u  CHR  136,1  0t04 /dev/pts/1
> fd-go1.9b 3698 peter4u  a_inode   0,120 9667 [eventpoll]
>
> FD #4 doesn't show up with go1.8.3. Is this expected, a bug or something
> else?

In 1.9 the os package now uses the event poller that the net package
has always used.

I sent https://golang.org/cl/45910 to add that to the release notes.

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] Curious about this snippet in /src/runtime/proc.go

[Tyler Compton]

Why not just panic, though? And why the infinite loop, I wonder?

On Thu, Jun 15, 2017 at 9:56 AM Aldrin Leal  wrote:

> Force a panic in case exit fails?
>
> --
> -- Aldrin Leal,  / http://about.me/aldrinleal
>
> On Thu, Jun 15, 2017 at 4:54 AM,  wrote:
>
>> Hey,
>>
>> Learning golang at the moment and came across this at the end of func
>> main() in proc.go in the golang source tree.
>>
>> exit(0)
>> for {
>> var x *int32
>> *x = 0
>> }
>>
>> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>>
>> How is the for loop ever reached and what's the purpose of the infinite
>> loop, zeroing memory?
>>
>> Thanks,
>>
>> Goodwin
>>
>> --
>> 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.
>
-- 
Tyler Compton
Software Engineering

-- 
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] Curious about this snippet in /src/runtime/proc.go

[Aldrin Leal]

Force a panic in case exit fails?

--
-- Aldrin Leal,  / http://about.me/aldrinleal

On Thu, Jun 15, 2017 at 4:54 AM,  wrote:

> Hey,
>
> Learning golang at the moment and came across this at the end of func
> main() in proc.go in the golang source tree.
>
> exit(0)
> for {
> var x *int32
> *x = 0
> }
>
> Ln 198 - 202 https://golang.org/src/runtime/proc.go
>
> How is the for loop ever reached and what's the purpose of the infinite
> loop, zeroing memory?
>
> Thanks,
>
> Goodwin
>
> --
> 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.9 Beta 1 is released

[pmorjan]

With go1.9beta1 (Linux / amd64) I noticed an extra file descriptor that I 
cannot explain. 
A simple example is after calling ioutil.ReadDir(). 

package main
import (

   "fmt"

   "io/ioutil"

)

func main() {

   _, err := ioutil.ReadDir(".")

   if err != nil {

   panic(err)

   }

   fmt.Scanln()

}

sudo lsof -p `pidof fd-go1.9beta1`
COMMANDPID  USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
fd-go1.9b 3698 peter  cwd   DIR8,2 4096 23596911 /home/peter/go/
src/fd
fd-go1.9b 3698 peter  rtd   DIR8,2 40962 /
fd-go1.9b 3698 peter  txt   REG8,2  1964089 23596832 /home/peter/go/
src/fd/fd-go1.9beta1
fd-go1.9b 3698 peter0u  CHR  136,1  0t04 /dev/pts/1
fd-go1.9b 3698 peter1u  CHR  136,1  0t04 /dev/pts/1
fd-go1.9b 3698 peter2u  CHR  136,1  0t04 /dev/pts/1
fd-go1.9b 3698 peter4u  a_inode   0,120 9667 [eventpoll]

FD #4 doesn't show up with go1.8.3. Is this expected, a bug or something 
else?
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] Go 1.9 Beta 1 is released

[Юрий Соколов]

In fact that was Dmitry's answer where he pointed to his previous answer
where he answered that there is no problem.

So ball is not on Aliaksandr side, but on the side of core team.


15 июня 2017 г. 6:45 PM пользователь "Brad Fitzpatrick" 
написал:



On Wed, Jun 14, 2017 at 11:35 PM, Sokolov Yura 
wrote:

> So, no scalable timers in 1.9 ?
> https://go-review.googlesource.com/c/34784/15
> It's a pity.


Yes. But Aliaksandr hasn't replied to Dmitry for the past 10 days, either.

We don't ship code that hasn't made it through code review.

-- 
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] Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

On Thu, Jun 15, 2017 at 8:54 AM, Michael Banzon  wrote:

> 
> does this mean that 2.0 is next?
> 
>


I gave a talk about that:

Slides:
https://docs.google.com/presentation/d/1JsCKdK_AvDdn8EkummMNvpo7ntqteWQfynq9hFTCkhQ/view?slide=id.p#slide=id.p

Video:
https://www.youtube.com/watch?v=4Dr8FXs9aJM


-- 
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] Go 1.9 Beta 1 is released

[Michael Banzon]

does this mean that 2.0 is next?


On Thu, Jun 15, 2017 at 5:45 PM Brad Fitzpatrick 
wrote:

> On Wed, Jun 14, 2017 at 11:35 PM, Sokolov Yura 
> wrote:
>
>> So, no scalable timers in 1.9 ?
>> https://go-review.googlesource.com/c/34784/15
>> It's a pity.
>
>
> Yes. But Aliaksandr hasn't replied to Dmitry for the past 10 days, either.
>
> We don't ship code that hasn't made it through code review.
>
>
> --
> 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.
>
-- 
Michael Banzon
https://michaelbanzon.com/

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

On Wed, Jun 14, 2017 at 11:35 PM, Sokolov Yura 
wrote:

> So, no scalable timers in 1.9 ?
> https://go-review.googlesource.com/c/34784/15
> It's a pity.


Yes. But Aliaksandr hasn't replied to Dmitry for the past 10 days, either.

We don't ship code that hasn't made it through code review.

-- 
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: Go 1.9 Beta 1 is released

[Brad Fitzpatrick]

If you view the HTML source, the relevant CL numbers are in comments.


On Wed, Jun 14, 2017 at 11:02 PM,  wrote:

> Can someone elaborate more on "Large object allocation performance is
> significantly improved in applications using large (>50GB) heaps containing
> many large objects."? What PR / issue is related to this change? What are
> the numbers?
>
> On Wednesday, June 14, 2017 at 3:15:49 PM UTC-7, Chris Broadfoot wrote:
>>
>> Hello gophers,
>>
>> We have just released go1.9beta1, a beta version of Go 1.9.
>> It is cut from the master branch at the revision tagged go1.9beta1.
>>
>> There are no known problems or regressions.
>> Please try running production load tests and your unit tests with the new
>> version.
>>
>> Report any problems using the issue tracker:
>> https://golang.org/issue/new
>>
>> If you have Go installed already, the easiest way to try go1.9beta1
>> is by using this tool:
>> https://godoc.org/golang.org/x/build/version/go1.9beta1
>>
>> You can download binary and source distributions from the usual place:
>> https://golang.org/dl/#go1.9beta1
>>
>> To find out what has changed in Go 1.9, read the draft release notes:
>> https://tip.golang.org/doc/go1.9
>>
>> Documentation for Go 1.9 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.
>

-- 
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.9 Beta 1 is released

[litwinos]

Can someone elaborate more on "Large object allocation performance is 
significantly improved in applications using large (>50GB) heaps containing 
many large objects."? What PR / issue is related to this change? What are 
the numbers?

On Wednesday, June 14, 2017 at 3:15:49 PM UTC-7, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9beta1, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta1.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new 
> version.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 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] Curious about this snippet in /src/runtime/proc.go

[goodwin . lawlor]

Hey,

Learning golang at the moment and came across this at the end of func 
main() in proc.go in the golang source tree.

exit(0)
for {
var x *int32
*x = 0
}

Ln 198 - 202 https://golang.org/src/runtime/proc.go

How is the for loop ever reached and what's the purpose of the infinite 
loop, zeroing memory?

Thanks,

Goodwin

-- 
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] MSSQL DBMS

[Shawn Milochik]

I recommend this excellent documentation to get started:

http://jmoiron.github.io/sqlx/

The docs are from the sqlx package, but they do a great job of explaining
the standard library functionality first. You can just stop reading after
the beginning.

Also, unless I'm missing something, you're *much* better off starting off
with PostgreSQL or (if you must), MySQL. They have great drivers:

https://github.com/lib/pq
https://github.com/go-sql-driver/mysql

Using sqlite3 is more complicated in Go, because you'd have to also import
a sqlite3 library which probably requires cgo.

-- 
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] Passing []byte from golang to char * C.

[Tamás Gulácsi]

C strings are 0-terminated. Either encode 0 (byte) values, or call with pointer 
to first byte, and the length.

-- 
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] MSSQL DBMS

[Kiki Sugiaman]

Try to get the simplest sqlite example working using database/sql. This 
is to get config issues common with database servers out of the way. 
Such example has been discussed several times in the past in this very 
mailing list.


Once you get the example with sqlite working, substitute driverName and 
dataSourceName passed to the following function:

https://golang.org/pkg/database/sql/#Open
...with respective SQL Server/MS Access values.

If your example doesn't work after the substitution, then you configured 
your database or connection string (dataSourceName) incorrectly.




On 15/06/17 21:57, Vikram Rawat wrote:
I have read like every blog about database but I am not able to 
understand how to connect GOLANG to


1. SQL Server
2. MS Access

can anybody please tell me how to query these databases please

--
You received this message because you are subscribed to the Google 
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to golang-nuts+unsubscr...@googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: KVs store for large strings

[Kiki Sugiaman]

I think I misunderstood what you were trying to accomplish. Let me try 
to rephrase and see if I'm getting closer:


- to accommodate template changes during development, you introduced 
read-locking to your app.
- as a result, your reads in production are slow. Never mind the fact 
that locking is pointless in production because the templates don't change.
- ideally, you want your reads to yield to template changes during 
development, but go lockless in production.


If the above are correct, then the solution is not data structure 
change, but code swapping during init() depending on the environment 
variable $DEVMODE (or whatever you want to call it).


Example:
https://play.golang.org/p/wqb9lVIPLa
(repeat several times and change the random seed to randomize the 
behavior a bit)


Of course, optimizing the data structure doesn't hurt. And to answer 
your question, yes map can handle 10's of thousands entries with 100MB 
raw data with *relative* ease.




On 15/06/17 15:45, James Pettyjohn wrote:
I looked at doing boltdb but ended up with a slightly simpler approach. 
I don't need the disk persistence in this case.


I tried radix tree implementation but found it slower than my current 
nested map with locks. In that interest I rewrote the nested map 
approach considering the key partitioning noted by Robert.


The primary differences in my approach this time were:
1) Read the whole dataset once treat it as immutable, no locking
2) Align the API to no require any manipulation of the keys after the 
first load, so every lookup is now 0 allocation.


The structure is a simplistic map[string]map[string]string - language -> 
key. There was a breakdown of the second map further in the previous 
implementation, probably bringing it from a few thousand to a few 
hundred each. Don't know what the threshold on the benefits there, based 
on my experience the map implementation can handle 10s of thousands with 
ease.


This brought the lookups down by about 50%:

BenchmarkLookupLooseLazy-8 300 458 ns/op 32 B/op 1 allocs/op 
BenchmarkLookupLooseMap-8 500 265 ns/op 0 B/op 0 allocs/op


Let me know if see anything else worth adjusting.

Best,
James


On Wednesday, June 14, 2017 at 2:01:44 PM UTC-7, Robert Johnstone wrote:

I'm surprised that the memory overhead is significant - 100 MB is
not that much.

Assuming that you don't need atomic updates to the entire KV store,
partition the keys.

Does the periodic reload involve changing the keys?  If not, you
could map the dataset into nested structs.  However, you will still
need to synchronise access if you want to to reload without stopping
the server, but that would just be the leaves.  Switching just the
top-tier to a struct could help with the contention.


On Wednesday, 14 June 2017 14:45:25 UTC-4, James Pettyjohn wrote:

I have an application which has all of it's text, multiple
languages, stored in XML on disk that is merged into templates
on the fly. About 100MB. Templates use dozens of strings for
each render.

Currently this is loaded in full into memory in a bunch of tier
hash maps. They are lazy loaded and using multiple locks to
perform reads but, unless in dev mode, actually don't change
throughout the lifetime of the application and should be
considered immutable.

While workable at a smaller scale, it's slow at scale. The most
important factor is concurrent lookup speed, secondary concern
is memory overhead. And it cannot preclude periodic reload while
doing dev.

Is there a data structure or lib that suits this scenarios more
than others?

--
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] MSSQL DBMS

[Vikram Rawat]

I have read like every blog about database but I am not able to understand 
how to connect GOLANG to

1. SQL Server
2. MS Access

can anybody please tell me how to query these databases please

-- 
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.9 Beta 1 is released

[Julius Kovac]

Great work! I can't express how grateful I'm that you keep the language 
stable and backwards compatible in times when everything is changing so 
fast. Thank you!

On Thursday, June 15, 2017 at 12:15:49 AM UTC+2, Chris Broadfoot wrote:
>
> Hello gophers,
>
> We have just released go1.9beta1, a beta version of Go 1.9.
> It is cut from the master branch at the revision tagged go1.9beta1.
>
> There are no known problems or regressions.
> Please try running production load tests and your unit tests with the new 
> version.
>
> Report any problems using the issue tracker:
> https://golang.org/issue/new
>
> If you have Go installed already, the easiest way to try go1.9beta1
> is by using this tool:
> https://godoc.org/golang.org/x/build/version/go1.9beta1
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.9beta1
>
> To find out what has changed in Go 1.9, read the draft release notes:
> https://tip.golang.org/doc/go1.9
>
> Documentation for Go 1.9 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.