[go-nuts] go executable cross-compiled for arm5 works on amd64 (and arm5)

[Dan Kortschak]

Can someone explain to me why this works? I am cross-compiling for
arm5, but the executable works on amd64.

$ cat hello.go 
package main

import "fmt"

func main() {
fmt.Println("hello")
}
$ GOARCH=arm GOARM=5 go build hello.go 
$ ./hello 
hello
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/daniel"
GORACE=""
GOROOT="/home/daniel/go"
GOTOOLDIR="/home/daniel/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-
map=/tmp/go-build014006335=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
$ go version
go version go1.7.4 linux/amd64


The executable also works on the arm5 device. I'm not worried, but I
don't understand how this works.

-- 
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] will GC close unused connection ?

[Jan Mercl]

On Thu, Feb 16, 2017 at 8:20 AM  wrote:

> Will GC close unused connection ?

No. At least not directly. A finalizer can possibly do that and finalizers
are possibly invoked by the GC.

-- 

-j

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

[go-nuts] will GC close unused connection ?

[caspian46]

Will GC close unused connection ?
In a particular case, I found that if there's a connection won't be used 
for a while, it will be closed. If I disable GC, then the connection will 
not be closed.
In the test, I never call the close function manually. But this is a bit 
hard to reproduce. 
GC will close unused tcp connection, is my assumption 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] Re: weak hash for (MongoDb like) data server

[Basile Starynkevitch]

On Thursday, February 16, 2017 at 6:42:05 AM UTC+1, Basile Starynkevitch 
wrote:
>
>
>
> On Wednesday, February 15, 2017 at 9:01:58 PM UTC+1, Tamás Gulácsi wrote:
>
>
>> Why do you need this? 
>> You want the GC do the housekeeping for you, but I'm sure you won't be 
>> happy with the result, as the GC's policy differs from what you await...
>>
>
> What make you believe I won't be happy with the GC's policy. I'm quite 
> open on that. My understanding is that the GC's policy is what I want.
>
>>
>> What kind of eviction policy would you want?
>> Storing the data in an append-only file (or LevelDB), the deleted items 
>> in SQLite, evicting regularly and on close?
>>
>
> Persistence to disk will only happen explicitly at shutdown (process exit) 
> time. So the file aspect don't matter much for my Q1.
>
> So my Q1 is basically: how can I make a weak hash table (in the sense I 
> have described, of having an association from strong keys -pairs of uint64- 
> to weak pointers to items).
>
> BTW, I have found https://github.com/fx5/weakref/blob/master/weakref.go 
but I am not sure to understand how it works (and even if it works). 

-- 
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: weak hash for (MongoDb like) data server

[Basile Starynkevitch]

On Wednesday, February 15, 2017 at 9:01:58 PM UTC+1, Tamás Gulácsi wrote:


> Why do you need this? 
> You want the GC do the housekeeping for you, but I'm sure you won't be 
> happy with the result, as the GC's policy differs from what you await...
>

What make you believe I won't be happy with the GC's policy. I'm quite open 
on that. My understanding is that the GC's policy is what I want.

>
> What kind of eviction policy would you want?
> Storing the data in an append-only file (or LevelDB), the deleted items in 
> SQLite, evicting regularly and on close?
>

Persistence to disk will only happen explicitly at shutdown (process exit) 
time. So the file aspect don't matter much for my Q1.

So my Q1 is basically: how can I make a weak hash table (in the sense I 
have described, of having an association from strong keys -pairs of uint64- 
to weak pointers to items).
 

-- 
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] Orm Golang

[I Ketut Gunawan]

Hi is there any suggestion of using orm in golang with lock feature update
record ?


Thanks for help

-- 
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] Changes to the Code of Conduct

[Andrew Gerrand]

Hi golang-nuts,

This morning we made a change 
to the Code of Conduct . This change removes
the punitive language and anonymous reporting mechanism from the Code of
Conduct document. The changes will go live with the imminent release of Go
1.8.

The commit message explains the change:

More than a year has passed since the Go Code of Conduct was introduced.
In that time, there have been a small number (<30) of reports to the Working
Group. Some reports we handled well, with positive outcomes for all
involved.
A few reports we handled badly, resulting in hurt feelings and a bad
experience
for all involved.

On reflection, the reports that had positive outcomes were ones where the
Working Group took the role of advisor/facilitator, listening to complaints
and
providing suggestions and advice to the parties involved.
The reports that had negative outcomes were ones where the subject of the
report felt threatened by the Working Group and Code of Conduct.

After some discussion among the Working Group, we saw that we are most
effective as facilitators, rather than disciplinarians. The various Go
spaces
already have moderators; this change to the CoC acknowledges their authority
and places the group in a purely advisory role. If an incident is reported
to
the group we may provide information to or make a suggestion the moderators,
but the Working Group need not (and should not) have any authority to take
disciplinary action.

In short, we want it to be clear that the Working Group are here to help
resolve conflict, period.

The second change made here is the removal of the anonymous reporting
mechanism. To date, the quality of anonymous reports has been low, and with
no
way to reach out to the reporter for more information there is often very
little we can do in response. Removing this one-way reporting mechanism
strengthens the message that the Working Group are here to facilitate a
constructive dialogue.

End commit message.

Earlier this month we made a separate change
 to remove Jason Buberel and
Dave Cheney from the working group (at their request). We intend to replace
them, but we haven't decided how best to do that. (If you have suggestions,
get in touch.)

Cheers,
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] Re: Windows Message Loop is getting blocked and resumed intermittently

[martseniuk]

check ole.GeMessage error.

btw. https://github.com/go-ole/go-ole/blob/master/com_func.go#L163

-- 
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: Windows Message Loop is getting blocked and resumed intermittently

[martseniuk]

check ole.GeMessage error.

btw. https://github.com/go-ole/go-ole/blob/master/com_func.go#L163

On Thursday, February 16, 2017 at 7:12:19 AM UTC+3, fe f wrote:
>
> I'm writing a go program that constantly receives and processes windows 
> messages in golang. (Go1.7, GOMAXPROCS=8, Windows 10)
>
> Here's my code.. (minimal code)
>
> import (
> "fmt"
> "github.com/go-ole/go-ole"
> "runtime"
> )
> func main () {
> SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS)
> runtime.LockOSThread()
>
>
> InitCOM() // Initializes COM Object 
> // (The com object constantly send message to this process)
>
>
> RunTickerGoroutine() 
> // This functions internally launches one goroutine, 
> // which also sends message to the main thread every 30 seconds
>
>
>
>
> /* Typical Windows Message Loop */
> var m ole.Msg
> for {
> ole.GetMessage(, 0, 0, 0)
> fmt.Println(m, ": Got Message!")
> ole.DispatchMessage()
> }
> }
>
>
> func SetPriorityClass() {
>// Just some some syscalls calling SetPriorityClass of Kernel32.dll
>... 
> }
>
>
>
> So bascially there are two objects(com object and goroutine I launched) 
> which constantly send messages to the main goroutine and this main 
> goroutine processes them with typical message loop.. and it works well most 
> of the time.
>
> However, the problem is, sometimes the message loop is getting blocked, 
> and after some amount of time, the message loop resumes and large amount of 
> blocked old messages are getting pumped.
>
> I initially thought this is because of main goroutine's OS Thread 
> switching. 
> I thought windows message loop is not getting any message for a while 
> because it's goroutine got switched to other OS Thread for a while. 
>
> So I added a code runtime.LockOSThread() like above code. But the problem 
> still occurred! 
>
> So I thought this is probably because of OS Context Switch.. 
> So I added code SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS) 
> to ensure this process to be high priority in windows, and killed all of 
> other cpu intensive processes.
> But the problem still occurred.
>
> I really have no idea how to solve this problem.. 
>
> Now I'm suspecting that runtime go scheduler is not scheduling my main 
> goroutine(message loop thread) sometimes, and that's why my message loop 
> get blocked for a while.
>
> However, I have no idea how to verify it and also solve it.
>
> So my question is.. 
>
> Why the message loop is getting blocked intermittently?
>
> How can I solve this problem? (I want my main goroutine(message loop) 
> always working without OS Thread switch (never blocked))
>
> Any helps/ideas will be greatly appreciated. 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] Windows Message Loop is getting blocked and resumed intermittently

[fe f]

I'm writing a go program that constantly receives and processes windows 
messages in golang. (Go1.7, GOMAXPROCS=8, Windows 10)

Here's my code.. (minimal code)

import (
"fmt"
"github.com/go-ole/go-ole"
"runtime"
)
func main () {
SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS)
runtime.LockOSThread()


InitCOM() // Initializes COM Object 
// (The com object constantly send message to this process)


RunTickerGoroutine() 
// This functions internally launches one goroutine, 
// which also sends message to the main thread every 30 seconds




/* Typical Windows Message Loop */
var m ole.Msg
for {
ole.GetMessage(, 0, 0, 0)
fmt.Println(m, ": Got Message!")
ole.DispatchMessage()
}
}


func SetPriorityClass() {
   // Just some some syscalls calling SetPriorityClass of Kernel32.dll
   ... 
}



So bascially there are two objects(com object and goroutine I launched) 
which constantly send messages to the main goroutine and this main 
goroutine processes them with typical message loop.. and it works well most 
of the time.

However, the problem is, sometimes the message loop is getting blocked, and 
after some amount of time, the message loop resumes and large amount of 
blocked old messages are getting pumped.

I initially thought this is because of main goroutine's OS Thread 
switching. 
I thought windows message loop is not getting any message for a while 
because it's goroutine got switched to other OS Thread for a while. 

So I added a code runtime.LockOSThread() like above code. But the problem 
still occurred! 

So I thought this is probably because of OS Context Switch.. 
So I added code SetPriorityClass(GetCurrentProcess(), HIGH_PRIORITY_CLASS) 
to ensure this process to be high priority in windows, and killed all of 
other cpu intensive processes.
But the problem still occurred.

I really have no idea how to solve this problem.. 

Now I'm suspecting that runtime go scheduler is not scheduling my main 
goroutine(message loop thread) sometimes, and that's why my message loop 
get blocked for a while.

However, I have no idea how to verify it and also solve it.

So my question is.. 

Why the message loop is getting blocked intermittently?

How can I solve this problem? (I want my main goroutine(message loop) 
always working without OS Thread switch (never blocked))

Any helps/ideas will be greatly appreciated. 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] [ANN] go-getch - a Library to read the console-event (keyboard-hit or screen-resize) on Windows

[Kaoru HAYAMA]

I wrote a library to read console-events (key-hit and/or window-resize) on 
Microsoft-Windows Console.

   - https://github.com/zetamatta/go-getch
   
Example:
e := getch.All()
if k := e.Key; k != nil {
fmt.Printf("\n%c %08X %08X %08X\n",
k.Rune, k.Rune, k.Scan, k.Shift)
} else if r := e.Resize; r != nil {
fmt.Printf("\nWidth=%d Height=%d\n", r.Width, r.Height)
} else {
fmt.Println("\n(unknown event)")
}


   - go-getch supports the surrogate pair of Unicode.
   - I made go-getch to use on NYAGOS .
   - You can use,copy and modify all under the BSD 3-Clause License.
   
---
zetamatta (HAYAMA,Kaoru)



-- 
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] TLS server to save client certificates after a request is received

[Janne Snabb]

The certificate byte stream is available in the Raw field of the
Certificate struct.

You can for example output received certificates PEM encoded like this:

for _, c := range r.TLS.PeerCertificates {
pem.Encode(os.Stdout, {Type: "CERTIFICATE", Bytes: c.Raw})
}

Or you can just save c.Raw in a file if you prefer binary format.

See https://gist.github.com/snabb/01c71af8cc9815e2fed68767bbb445af for
complete example.

Janne Snabb
sn...@epipe.com

On 2017-02-15 03:54, Naveen Shivegowda wrote:
> Hi,
> 
> I need to store the client certificates in a file for further
> authentication purpose but I am not able to re-form the client certificates.
> TLS.PeerCertificates has information related to client certificates but
> it is separated by struct fields and is not present as byte stream which
> could be written into a file, Is there any package which could take
> 'TLS.PeerCertificates' and convert it into a certificate again?
> 
> -- 
> 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] encoding/binary partial read errors

[Eric Buth]

 

The ReadUvarint implementation (and ReadVarint which depends on it) reads 
from a io.ByteReader until it encounters a leading 0 bit indicating the end 
of the last byte of a varint. If it encounters an io.EOF error at any 
point, that error is passed back to the caller. 


The issue is that the caller has no way to know if a partial read took 
place. I’d argue that in that case – an io.EOF error on any read after the 
first – ReadUvarint should return an io.ErrUnexpectedEOF error.


Is this something worth filing a GitHub issue about? Thanks!


e

-- 
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/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

[Will Faught]

Ah, I forgot about that syntax. Thanks!

On Wed, Feb 15, 2017 at 11:31 AM  wrote:

> Invalid, Bool, Int, Int8 there are const integers, and they are specifying
> the entry's position in the slice, allowing gaps in the list to be
> implicitly defined.
>
> See this example: https://play.golang.org/p/KVqO40R6mP
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/k7ZFpDN5eXM/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Compressing 2.5 GB data trims files

[Dave Cheney]

Or use https://godoc.org/io/ioutil#ReadFile

By really you don't need to buffer all the data in memory, io.Copy will do 
that for you

in, err := os.Open(input)
check(err)
defer in.Close()
out, err := os.Create(output)
gz := gzip.New.Writer(out)
_, err = io.Copy(gz, in)
check(err)
err = gz.Close()
check(err)
err = out.Close()
check(err)

On Thursday, 16 February 2017 06:05:51 UTC+11, howar...@gmail.com wrote:
>
> While it is not clear from the Buffer documentation, the Reader 
> *interface* documentation (which Buffer.Read implements implicitly) does 
> state "up to len(p) bytes." You are ignoring how many bytes it read and 
> assuming that the one read is reading the whole file. I am not sure that 
> this is guaranteed with Buffer.Read. 
>
> I would suggest you try to adhere to the Reader interface's documented 
> behavior, and continue to call Read until you get EOF, and process the n 
> returned bytes each time. Doing this would also make it easier to then move 
> a step further and drop your buffer size to something sensible, instead of 
> attempting to read the entire 2.5G file into memory before compressing.
>
> Howard
>

-- 
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] Organizing a lot of implementations for single interface

[Luca Looz]

I'm developing a library where i have 1 common interface and a lot of 
implementations (likely hundreds).
A single implementation is not too complex and can reside in a single 
source file but then i have visibility issues with constants etc. Should i 
just create a package for each implementation?

The execution flow of this program will be something like:
*input data -> find implementation -> execute implementation -> return 
common struct*
The program shouldn't use these implementations directly. 
I'm thinking to use an entry point package that holds a map of the 
implementations exporting *Find/Register* methods. This entry point package 
will also import with an underscore all impl packages so that they can self 
register with an *init* method without exporting anything.

-- 
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: weak hash for (MongoDb like) data server

[Tamás Gulácsi]

> The id of data items is the only way to refer to data items on the 
> protocol side. So I need a *weak association* between an id and the data 
> item (if any) of that id. I do not want to keep (in some ordinary Go map, 
> for example) the association between ids and their data items (otherwise, 
> no data item would be garbage collected). I accept the fact that eventually 
> (and perhaps quite later), a data item which is not reachable from the root 
> data item would be garbage collected.
>
> I was thinking of using unsafe.Pointer-s with runtime.SetFinalizer. A 
> simplistic approach could be to use a Go map (module variable) from pairs 
> of uint64_t to such unsafe pointers. At data item creation, I would 
> register in that map, using the pair of uint64_t-s as key, the pointer of 
> that data item suitably converted to an unsafe.Pointer. I would also pass 
> to SetFinalizer some finalization routine which would unregister (delete) 
> from that map. That scheme would work only if Go garbage collector does not 
> move objects (i.e. struct-s). If Go's GC is a conservative GC à la Boehm 
> GC , I'll probably even better "hide" the 
> pointer (e.g. by keeping not a Pointer, but some uintptr suitably 
> "hidden" e.g. by complementing all its bits à la GC_HIDE_POINTERS 
>  in Boehm 
> GC). But that scheme would work only if Go's garbage collector is not 
> moving values (e.g. struct-s).* Is Go's garbage collector guaranteed to 
> be some marking *(not moving or generational copying, à la Ocaml) *one?* 
> FWIW, I am familiar with the terminology of the GC handbook 
> .
>

Why do you need this? 
You want the GC do the housekeeping for you, but I'm sure you won't be 
happy with the result, as the GC's policy differs from what you await...

What kind of eviction policy would you want?
Storing the data in an append-only file (or LevelDB), the deleted items in 
SQLite, evicting regularly and on close?

-- 
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 run deferred function in main() on panic() in a goroutine?

['Axel Wagner' via golang-nuts]

You might also want to consider running the stuff in a separate process.
But honestly, you can't really be sure anyway, for asynchronous signals,
because they are - as the name suggest - asynchronous. Between you calling
kill and the signal actually being delivered and interrupting the process,
it can just continue as it where.

On Wed, Feb 15, 2017 at 7:11 PM, Yucong Sun  wrote:

> In single threaded C code, The interrupter loop is guaranteed stop
> when crash() is executing,  Now in Go code, however,  the interrupter
> loop could still be executing when crash() is running. because there
> is no way to interrupt a go routine beside a panic(), but like you
> said, i can't induce panic on another go routine, so I can't do what i
> want.
>
> Now, I get what you are saying, I need to invest some time on C code's
> main loop to make it interruptible by other thread . which maybe what
> I need to do.
>
> On Wed, Feb 15, 2017 at 10:56 AM, Ian Lance Taylor 
> wrote:
> > On Wed, Feb 15, 2017 at 10:43 AM, Yucong Sun 
> wrote:
> >> So, to give more background,  i am trying to porting a C based
> >> interpreter to Go.  In the single threaded C code, the signal is
> >> always handled by interrupting whatever code was executing and
> >> directly exit after executing some "crash()" cleanup function.
> >
> > Why can't you do exactly that in Go?
> >
> >
> >> Now, I ported the main function to Go, as I demonstrated above, there
> >> is no way to "interrupt" C code anymore, so I can't run crash()
> >> cleanly as before. This seems to be a limitation of Go, and I couldn't
> >> think of any way to work around it.
> >
> > If you want to implement the precise behavior of a single-threaded C
> > program, then you need to write a single-threaded Go program.  But
> > that goal is clearly folly.  Don't try to write C code in Go.  When
> > you are using Go, write Go code.  That means: arrange your program as
> > a Go program.
> >
> > 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: go/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

[howardcshaw]

Invalid, Bool, Int, Int8 there are const integers, and they are specifying 
the entry's position in the slice, allowing gaps in the list to be 
implicitly defined.

See this example: https://play.golang.org/p/KVqO40R6mP

-- 
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/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 11:08 AM, Will Faught  wrote:
> The go/types.Typ decl:
>
> var Typ = []*Basic{
> Invalid:   {Invalid, 0, "invalid type"},
>
> Bool:  {Bool, IsBoolean, "bool"},
> Int:   {Int, IsInteger, "int"},
> Int8:  {Int8, IsInteger, "int8"},
> ...
> }
>
> Typ is a slice of pointer to Basic—got it; Basic is a struct—got it; the
> {Bool, IsBoolean, "bool"} stuff is clearly a Basic or *Basic—got it; but
> where is the map syntax coming from? How does that work?

That's not "map syntax", it's general composite literal syntax and is
permitted for all kinds of composite literals.  For a slice, it means
that the element with index `Invalid` gets the value `{Invalid, 0,
"invalid type"}`, and so forth.  For a slice composite literal the
keys (in this case, `Invalid`, `Bool`, etc.) must all be non-negative
integer constant expressions.

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: Compressing 2.5 GB data trims files

[howardcshaw]

While it is not clear from the Buffer documentation, the Reader *interface* 
documentation (which Buffer.Read implements implicitly) does state "up to 
len(p) bytes." You are ignoring how many bytes it read and assuming that 
the one read is reading the whole file. I am not sure that this is 
guaranteed with Buffer.Read. 

I would suggest you try to adhere to the Reader interface's documented 
behavior, and continue to call Read until you get EOF, and process the n 
returned bytes each time. Doing this would also make it easier to then move 
a step further and drop your buffer size to something sensible, instead of 
attempting to read the entire 2.5G file into memory before compressing.

Howard

-- 
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 run deferred function in main() on panic() in a goroutine?

[Yucong Sun]

In single threaded C code, The interrupter loop is guaranteed stop
when crash() is executing,  Now in Go code, however,  the interrupter
loop could still be executing when crash() is running. because there
is no way to interrupt a go routine beside a panic(), but like you
said, i can't induce panic on another go routine, so I can't do what i
want.

Now, I get what you are saying, I need to invest some time on C code's
main loop to make it interruptible by other thread . which maybe what
I need to do.

On Wed, Feb 15, 2017 at 10:56 AM, Ian Lance Taylor  wrote:
> On Wed, Feb 15, 2017 at 10:43 AM, Yucong Sun  wrote:
>> So, to give more background,  i am trying to porting a C based
>> interpreter to Go.  In the single threaded C code, the signal is
>> always handled by interrupting whatever code was executing and
>> directly exit after executing some "crash()" cleanup function.
>
> Why can't you do exactly that in Go?
>
>
>> Now, I ported the main function to Go, as I demonstrated above, there
>> is no way to "interrupt" C code anymore, so I can't run crash()
>> cleanly as before. This seems to be a limitation of Go, and I couldn't
>> think of any way to work around it.
>
> If you want to implement the precise behavior of a single-threaded C
> program, then you need to write a single-threaded Go program.  But
> that goal is clearly folly.  Don't try to write C code in Go.  When
> you are using Go, write Go code.  That means: arrange your program as
> a Go program.
>
> 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] go/types.Typ is a slice-of-pointer-to-struct yet uses map syntax

[Will Faught]

The go/types.Typ decl:

var Typ = []*Basic{
Invalid:   {Invalid, 0, "invalid type"},

Bool:  {Bool, IsBoolean, "bool"},
Int:   {Int, IsInteger, "int"},
Int8:  {Int8, IsInteger, "int8"},
...
}

Typ is a slice of pointer to Basic—got it; Basic is a struct—got it; the {Bool, 
IsBoolean, "bool"} stuff is clearly a Basic or *Basic—got it; but where is 
the map syntax coming from? How does that work?

-- 
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 run deferred function in main() on panic() in a goroutine?

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 10:43 AM, Yucong Sun  wrote:
> So, to give more background,  i am trying to porting a C based
> interpreter to Go.  In the single threaded C code, the signal is
> always handled by interrupting whatever code was executing and
> directly exit after executing some "crash()" cleanup function.

Why can't you do exactly that in Go?


> Now, I ported the main function to Go, as I demonstrated above, there
> is no way to "interrupt" C code anymore, so I can't run crash()
> cleanly as before. This seems to be a limitation of Go, and I couldn't
> think of any way to work around it.

If you want to implement the precise behavior of a single-threaded C
program, then you need to write a single-threaded Go program.  But
that goal is clearly folly.  Don't try to write C code in Go.  When
you are using Go, write Go code.  That means: arrange your program as
a Go program.

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] Are the tests in the Go source code considered "Unit" tests?

[so . query]

I see, Thank you both for your comments.



On Wednesday, February 15, 2017 at 7:23:25 AM UTC-8, Ian Lance Taylor wrote:
>
> On Tue, Feb 14, 2017 at 10:35 PM,   
> wrote: 
> > 
> > From my understanding Unit Tests should focus on testing a single 
> feature 
> > and not use the filesystem. 
> > 
> > But in the Go source (https://github.com/golang/go) I saw several tests 
> that 
> > would violate those conditions. 
> > 
> > Should we strive to follow more standard conventions in our own unit 
> tests? 
> > or are those tests idiomatic and acceptable for Go? 
>
> The tests in the Go source tree do not attempt to distinguish unit 
> tests from other sorts of tests.  They are all just tests. 
>
> You should follow whatever conventions you think will work best for 
> you.  Personally I would say that unit tests are a good idea but they 
> are not sufficient; you need some tests of the entire program. 
>
> 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 run deferred function in main() on panic() in a goroutine?

[Yucong Sun]

So, to give more background,  i am trying to porting a C based
interpreter to Go.  In the single threaded C code, the signal is
always handled by interrupting whatever code was executing and
directly exit after executing some "crash()" cleanup function.

Now, I ported the main function to Go, as I demonstrated above, there
is no way to "interrupt" C code anymore, so I can't run crash()
cleanly as before. This seems to be a limitation of Go, and I couldn't
think of any way to work around it.

On Wed, Feb 15, 2017 at 10:35 AM, Axel Wagner
 wrote:
> You misunderstood what I was trying to do (the recover was supposed to
> recover from any panic raised by the C-code, not from the panic of the main
> loop). And just added a new requirement.
>
> I don't think what you want is possible, from what I know about the go
> runtime. You could approximate it, by running C.do_anything and reading from
> the signal-channel alternately, but that would still delay any signal
> handling to after your C-code is done.
>
> But your requirements also seems more and more obscure to me; I could kind
> of understand why the C code and the cleanup code must run in the same
> goroutine/thread, but it seems obscure, that the asynchronous signal
> handling *also* needs to run in that thread.
>
> Anyway. Maybe someone else knows more about all of this than me and can help
> you :)
>
> On Wed, Feb 15, 2017 at 7:26 PM, Yucong Sun  wrote:
>>
>> Also, my cleanup function must be tied directly with C loop, because
>> they are sharing the same underlaying memory/state  . If I directly
>> run cleanup() while C loop was running, there could be race.
>>
>> So that leaves me with no choice, i must be able to panic on the C
>> loop's go-routine on async signals, which I can't do with current
>> tools.
>>
>> On Wed, Feb 15, 2017 at 10:21 AM, Yucong Sun  wrote:
>> > https://play.golang.org/p/7Vz0o4ZoQF
>> >
>> > shows that your code doesn't really work.  My understanding is once
>> > panic reaches the current goroutine's top of callstack, program will
>> > crash, there are no attempt to call other goroutine's deferred
>> > function.
>> >
>> > So,  in order to do what I want, i must be able to trigger some sort
>> > of inline panic remotely.   Note in the C code this is easy, the
>> > signal handler will interrupt current thread, jump directly to the
>> > handler code and resume.  If I can do that in golang, i will be able
>> > to trigger a panic in main() and do what I want (or do what the old C
>> > code does, which i was porting into go)
>> >
>> > On Wed, Feb 15, 2017 at 10:14 AM, Yucong Sun 
>> > wrote:
>> >> Thanks axle,  but are you sure the code would work?  it is essentially
>> >> triggering panic on the main go routine while recovering from another
>> >> goroutine, isn't that impossible?
>> >>
>> >> If this is possible, why couldn't I trigger a panic on a goroutine
>> >> then recover it from main goroutine?
>> >>
>> >> On Wed, Feb 15, 2017 at 10:03 AM, Axel Wagner
>> >>  wrote:
>> >>> First, the code you wrote here doesn't use os/signal, so you can't
>> >>> really
>> >>> fault Ian for giving that advice. Here's my understanding:
>> >>>
>> >>> In general, there are two kinds of signals: synchronous ones, raised
>> >>> e.g. by
>> >>> dereferencing invalid memory. They produce a runtime panic at the site
>> >>> that
>> >>> produced them in the corresponding goroutine. And asynchronous ones,
>> >>> raised
>> >>> e.g. by using the kill command or os.Kill. They do not produce a
>> >>> runtime
>> >>> panic but instead need to be handled via os/signal.
>> >>>
>> >>> Now, to "catch" asynchronous panic's, you need to use os/signal and if
>> >>> you
>> >>> need them to produce a runtime-panic on the goroutine running main,
>> >>> you need
>> >>> to read from that channel in main and produce a panic whenever you
>> >>> read a
>> >>> value. You could, for example, do this:
>> >>>
>> >>> func main() {
>> >>> ch := make(chan os.Signal)
>> >>> signal.Notify(ch, mySignals)
>> >>>
>> >>> errs := make(chan interface{})
>> >>>
>> >>> go func() {
>> >>> defer func() {
>> >>> errs <- recover()
>> >>> }()
>> >>> for {
>> >>> C.do_something()
>> >>> }
>> >>> }()
>> >>>
>> >>> for {
>> >>> select {
>> >>> case s := <-ch:
>> >>> panic(fmt.Sprintf("received signal: %v", s))
>> >>> case v := <-errs:
>> >>> panic(fmt.Sprintf("recovered runtime panic in C-code: %v",
>> >>> v))
>> >>> }
>> >>> }
>> >>> }
>> >>>
>> >>> this will get asynchronous signals via os/signal and synchronous
>> >>> signals in
>> >>> the C-code raising runtime-panics via recover.
>> >>>
>> >>> Now, what is *not* possible, is to somehow recover from runtime panics
>> >>> caused by synchronous signals in *other* goroutines. The spec is
>> 

[go-nuts] [ANN] NYAGOS 4.1.8_0 - Extended CUI Shell for Windows written in Go

[Kaoru HAYAMA]

I released NYAGOS (Nihongo Yet Anothoer GOing Shell) 4.1.8_0,

which is the extended CUI Shell for Windows written in Golang.

   - https://github.com/zetamatta/nyagos (Introduction)
   - https://github.com/zetamatta/nyagos/releases/tag/4.1.8_0 (download)
   
NYAGOS.EXE is like CMD.EXE but is extended as below.

   - Keybinding like Emacs.
   - You can bind a Lua-function to key.
   - History by Ctrl-P and !-mark
   - Recoding cmdline,directory,datetime and process-id (NEW feature in 
  4.1.8_0)
   - Alias
   - Written with a text to be replaced , or  Lua-script
   - Filename/Command-name completion
  - Optimized for Windows
   - Colored ls

If you are interested, please use it. Feedback is welcome 
. 
---
zetamatta

-- 
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 run deferred function in main() on panic() in a goroutine?

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 10:26 AM, Yucong Sun  wrote:
> Also, my cleanup function must be tied directly with C loop, because
> they are sharing the same underlaying memory/state  . If I directly
> run cleanup() while C loop was running, there could be race.
>
> So that leaves me with no choice, i must be able to panic on the C
> loop's go-routine on async signals, which I can't do with current
> tools.

I sort of feel like you've set yourself an impossible task by saying
"I must induce a panic on the main goroutine."  You can't do that,
except by having the main goroutine sit around waiting on a channel
telling it when to panic.

But that is not your real problem.  I think you should step back and
figure out what your real problem is.  If your real problem is "I want
to do something when the program exits," then that is easy enough to
do by putting that thing into function F, and having a separate
goroutine that listens on an os/signal channel and invokes F and then
os.Exit when a signal arrives.

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: empty nested template definitions not working as expected

[mhhcbon]

Hi,

see this play,
https://play.golang.org/p/s-GdewdWz_

In my understanding, 
as the template is empty, 
it is not added to the templates tree, 
i suspect it has something to do with that,
https://golang.org/src/text/template/parse/parse.go?#L243

Maybe a non breakable space like  will do the trick ?

On Wednesday, February 15, 2017 at 5:10:16 PM UTC+1, Manlio Perillo wrote:
>
> Hi.
>
> I have found an unexpected behavior with the html/template package.
> This is a sample program:
> https://play.golang.org/p/Yh7UZJxQOd
>
> It will print:
>
> 
> 
>   
> 
> Test 2
>
>   
>   
> Test
>   
> 
>
>
>
> However, suppose I want to "disable" the "head" template;
> the reasonable solution is to define an empty "head" template in the 
> associated template:
> https://play.golang.org/p/yexg_Hxujq
>
> However this prints:
>
> 
> 
>   
> 
> Test 1
>
>   
>   
> Test
>   
> 
>
>
> instead of the expected:
>
> 
> 
>   
> 
>   
>   
> Test
>   
> 
>
>
> Is this a bug?
>
>
> Thanks
> Manlio
>

-- 
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 run deferred function in main() on panic() in a goroutine?

['Axel Wagner' via golang-nuts]

You misunderstood what I was trying to do (the recover was supposed to
recover from any panic raised by the C-code, not from the panic of the main
loop). And just added a new requirement.

I don't think what you want is possible, from what I know about the go
runtime. You could approximate it, by running C.do_anything and reading
from the signal-channel alternately, but that would still delay any signal
handling to after your C-code is done.

But your requirements also seems more and more obscure to me; I could kind
of understand why the C code and the cleanup code must run in the same
goroutine/thread, but it seems obscure, that the asynchronous signal
handling *also* needs to run in that thread.

Anyway. Maybe someone else knows more about all of this than me and can
help you :)

On Wed, Feb 15, 2017 at 7:26 PM, Yucong Sun  wrote:

> Also, my cleanup function must be tied directly with C loop, because
> they are sharing the same underlaying memory/state  . If I directly
> run cleanup() while C loop was running, there could be race.
>
> So that leaves me with no choice, i must be able to panic on the C
> loop's go-routine on async signals, which I can't do with current
> tools.
>
> On Wed, Feb 15, 2017 at 10:21 AM, Yucong Sun  wrote:
> > https://play.golang.org/p/7Vz0o4ZoQF
> >
> > shows that your code doesn't really work.  My understanding is once
> > panic reaches the current goroutine's top of callstack, program will
> > crash, there are no attempt to call other goroutine's deferred
> > function.
> >
> > So,  in order to do what I want, i must be able to trigger some sort
> > of inline panic remotely.   Note in the C code this is easy, the
> > signal handler will interrupt current thread, jump directly to the
> > handler code and resume.  If I can do that in golang, i will be able
> > to trigger a panic in main() and do what I want (or do what the old C
> > code does, which i was porting into go)
> >
> > On Wed, Feb 15, 2017 at 10:14 AM, Yucong Sun 
> wrote:
> >> Thanks axle,  but are you sure the code would work?  it is essentially
> >> triggering panic on the main go routine while recovering from another
> >> goroutine, isn't that impossible?
> >>
> >> If this is possible, why couldn't I trigger a panic on a goroutine
> >> then recover it from main goroutine?
> >>
> >> On Wed, Feb 15, 2017 at 10:03 AM, Axel Wagner
> >>  wrote:
> >>> First, the code you wrote here doesn't use os/signal, so you can't
> really
> >>> fault Ian for giving that advice. Here's my understanding:
> >>>
> >>> In general, there are two kinds of signals: synchronous ones, raised
> e.g. by
> >>> dereferencing invalid memory. They produce a runtime panic at the site
> that
> >>> produced them in the corresponding goroutine. And asynchronous ones,
> raised
> >>> e.g. by using the kill command or os.Kill. They do not produce a
> runtime
> >>> panic but instead need to be handled via os/signal.
> >>>
> >>> Now, to "catch" asynchronous panic's, you need to use os/signal and if
> you
> >>> need them to produce a runtime-panic on the goroutine running main,
> you need
> >>> to read from that channel in main and produce a panic whenever you
> read a
> >>> value. You could, for example, do this:
> >>>
> >>> func main() {
> >>> ch := make(chan os.Signal)
> >>> signal.Notify(ch, mySignals)
> >>>
> >>> errs := make(chan interface{})
> >>>
> >>> go func() {
> >>> defer func() {
> >>> errs <- recover()
> >>> }()
> >>> for {
> >>> C.do_something()
> >>> }
> >>> }()
> >>>
> >>> for {
> >>> select {
> >>> case s := <-ch:
> >>> panic(fmt.Sprintf("received signal: %v", s))
> >>> case v := <-errs:
> >>> panic(fmt.Sprintf("recovered runtime panic in C-code: %v",
> v))
> >>> }
> >>> }
> >>> }
> >>>
> >>> this will get asynchronous signals via os/signal and synchronous
> signals in
> >>> the C-code raising runtime-panics via recover.
> >>>
> >>> Now, what is *not* possible, is to somehow recover from runtime panics
> >>> caused by synchronous signals in *other* goroutines. The spec is pretty
> >>> clear about that; a panic that isn't recovered will cause the program
> to
> >>> crash.
> >>>
> >>> Hope this helps.
> >>>
> >>> On Wed, Feb 15, 2017 at 6:44 PM, Yucong Sun 
> wrote:
> 
>  hi,
> 
>  Maybe I wasn't clear, I am indeed using os.signal package. But it
> doesn't
>  do what I want!  I want to trigger a panic in main function , seems
> there is
>  no way to do it by using a signal channel .
> 
>  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.

Re: [go-nuts] How to run deferred function in main() on panic() in a goroutine?

[roger peppe]

Could you run the C code in its own OS thread by
using LockOSThread and then send a signal to that thread directly?


On 15 February 2017 at 18:26, Yucong Sun  wrote:
> Also, my cleanup function must be tied directly with C loop, because
> they are sharing the same underlaying memory/state  . If I directly
> run cleanup() while C loop was running, there could be race.
>
> So that leaves me with no choice, i must be able to panic on the C
> loop's go-routine on async signals, which I can't do with current
> tools.
>
> On Wed, Feb 15, 2017 at 10:21 AM, Yucong Sun  wrote:
>> https://play.golang.org/p/7Vz0o4ZoQF
>>
>> shows that your code doesn't really work.  My understanding is once
>> panic reaches the current goroutine's top of callstack, program will
>> crash, there are no attempt to call other goroutine's deferred
>> function.
>>
>> So,  in order to do what I want, i must be able to trigger some sort
>> of inline panic remotely.   Note in the C code this is easy, the
>> signal handler will interrupt current thread, jump directly to the
>> handler code and resume.  If I can do that in golang, i will be able
>> to trigger a panic in main() and do what I want (or do what the old C
>> code does, which i was porting into go)
>>
>> On Wed, Feb 15, 2017 at 10:14 AM, Yucong Sun  wrote:
>>> Thanks axle,  but are you sure the code would work?  it is essentially
>>> triggering panic on the main go routine while recovering from another
>>> goroutine, isn't that impossible?
>>>
>>> If this is possible, why couldn't I trigger a panic on a goroutine
>>> then recover it from main goroutine?
>>>
>>> On Wed, Feb 15, 2017 at 10:03 AM, Axel Wagner
>>>  wrote:
 First, the code you wrote here doesn't use os/signal, so you can't really
 fault Ian for giving that advice. Here's my understanding:

 In general, there are two kinds of signals: synchronous ones, raised e.g. 
 by
 dereferencing invalid memory. They produce a runtime panic at the site that
 produced them in the corresponding goroutine. And asynchronous ones, raised
 e.g. by using the kill command or os.Kill. They do not produce a runtime
 panic but instead need to be handled via os/signal.

 Now, to "catch" asynchronous panic's, you need to use os/signal and if you
 need them to produce a runtime-panic on the goroutine running main, you 
 need
 to read from that channel in main and produce a panic whenever you read a
 value. You could, for example, do this:

 func main() {
 ch := make(chan os.Signal)
 signal.Notify(ch, mySignals)

 errs := make(chan interface{})

 go func() {
 defer func() {
 errs <- recover()
 }()
 for {
 C.do_something()
 }
 }()

 for {
 select {
 case s := <-ch:
 panic(fmt.Sprintf("received signal: %v", s))
 case v := <-errs:
 panic(fmt.Sprintf("recovered runtime panic in C-code: %v", v))
 }
 }
 }

 this will get asynchronous signals via os/signal and synchronous signals in
 the C-code raising runtime-panics via recover.

 Now, what is *not* possible, is to somehow recover from runtime panics
 caused by synchronous signals in *other* goroutines. The spec is pretty
 clear about that; a panic that isn't recovered will cause the program to
 crash.

 Hope this helps.

 On Wed, Feb 15, 2017 at 6:44 PM, Yucong Sun  wrote:
>
> hi,
>
> Maybe I wasn't clear, I am indeed using os.signal package. But it doesn't
> do what I want!  I want to trigger a panic in main function , seems there 
> is
> no way to do it by using a signal channel .
>
> 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.

-- 
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 run deferred function in main() on panic() in a goroutine?

[Yucong Sun]

Also, my cleanup function must be tied directly with C loop, because
they are sharing the same underlaying memory/state  . If I directly
run cleanup() while C loop was running, there could be race.

So that leaves me with no choice, i must be able to panic on the C
loop's go-routine on async signals, which I can't do with current
tools.

On Wed, Feb 15, 2017 at 10:21 AM, Yucong Sun  wrote:
> https://play.golang.org/p/7Vz0o4ZoQF
>
> shows that your code doesn't really work.  My understanding is once
> panic reaches the current goroutine's top of callstack, program will
> crash, there are no attempt to call other goroutine's deferred
> function.
>
> So,  in order to do what I want, i must be able to trigger some sort
> of inline panic remotely.   Note in the C code this is easy, the
> signal handler will interrupt current thread, jump directly to the
> handler code and resume.  If I can do that in golang, i will be able
> to trigger a panic in main() and do what I want (or do what the old C
> code does, which i was porting into go)
>
> On Wed, Feb 15, 2017 at 10:14 AM, Yucong Sun  wrote:
>> Thanks axle,  but are you sure the code would work?  it is essentially
>> triggering panic on the main go routine while recovering from another
>> goroutine, isn't that impossible?
>>
>> If this is possible, why couldn't I trigger a panic on a goroutine
>> then recover it from main goroutine?
>>
>> On Wed, Feb 15, 2017 at 10:03 AM, Axel Wagner
>>  wrote:
>>> First, the code you wrote here doesn't use os/signal, so you can't really
>>> fault Ian for giving that advice. Here's my understanding:
>>>
>>> In general, there are two kinds of signals: synchronous ones, raised e.g. by
>>> dereferencing invalid memory. They produce a runtime panic at the site that
>>> produced them in the corresponding goroutine. And asynchronous ones, raised
>>> e.g. by using the kill command or os.Kill. They do not produce a runtime
>>> panic but instead need to be handled via os/signal.
>>>
>>> Now, to "catch" asynchronous panic's, you need to use os/signal and if you
>>> need them to produce a runtime-panic on the goroutine running main, you need
>>> to read from that channel in main and produce a panic whenever you read a
>>> value. You could, for example, do this:
>>>
>>> func main() {
>>> ch := make(chan os.Signal)
>>> signal.Notify(ch, mySignals)
>>>
>>> errs := make(chan interface{})
>>>
>>> go func() {
>>> defer func() {
>>> errs <- recover()
>>> }()
>>> for {
>>> C.do_something()
>>> }
>>> }()
>>>
>>> for {
>>> select {
>>> case s := <-ch:
>>> panic(fmt.Sprintf("received signal: %v", s))
>>> case v := <-errs:
>>> panic(fmt.Sprintf("recovered runtime panic in C-code: %v", v))
>>> }
>>> }
>>> }
>>>
>>> this will get asynchronous signals via os/signal and synchronous signals in
>>> the C-code raising runtime-panics via recover.
>>>
>>> Now, what is *not* possible, is to somehow recover from runtime panics
>>> caused by synchronous signals in *other* goroutines. The spec is pretty
>>> clear about that; a panic that isn't recovered will cause the program to
>>> crash.
>>>
>>> Hope this helps.
>>>
>>> On Wed, Feb 15, 2017 at 6:44 PM, Yucong Sun  wrote:

 hi,

 Maybe I wasn't clear, I am indeed using os.signal package. But it doesn't
 do what I want!  I want to trigger a panic in main function , seems there 
 is
 no way to do it by using a signal channel .

 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] Compressing 2.5 GB data trims files

[Shawn Milochik]

You're ignoring the error on os.Stat.

-- 
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 2.5 GB data trims files

[Kale Blankenship]

Did you try with the example I provided on your GH issue?
https://play.golang.org/p/u6eAphPRrk

On Wed, Feb 15, 2017 at 10:14 AM Mukund 8kmiles  wrote:

> Hi ,
>
> Has anyone tried compressing > ~2.5 GB of data using golang.
>
> The following function compresses files. Files less than ~2.5 GB are
> successful with any data loss. Files greater than ~2.5 are getting
> compressed but the API trims  section of the data at the last
>
> Any inputs are welcome!!!
>
> func compressFile(filename string, outputFile string) {
>
> fmt.Println("Compresssng file " + filename)
>
> if filename == "" {
> os.Exit(1)
> }
>
> rawfile, err := os.Open(filename)
>
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
> defer rawfile.Close()
>
> // calculate the buffer size for rawfile
> info, _ := rawfile.Stat()
>
> var size int64 = info.Size()
> rawbytes := make([]byte, size)
>
> // read rawfile content into buffer
> buffer := bufio.NewReader(rawfile)
> _, err = buffer.Read(rawbytes)
>
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
>
> var buf bytes.Buffer
> writer := gzip.NewWriter()
> writer.Write(rawbytes)
> writer.Close()
>
> err = ioutil.WriteFile(outputFile, buf.Bytes(), info.Mode())
>
> if err != nil {
> fmt.Println(err)
> os.Exit(1)
> }
> fmt.Println("compresssng file " + filename + " complete")
> }
>
> --
> 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] How to run deferred function in main() on panic() in a goroutine?

[Yucong Sun]

https://play.golang.org/p/7Vz0o4ZoQF

shows that your code doesn't really work.  My understanding is once
panic reaches the current goroutine's top of callstack, program will
crash, there are no attempt to call other goroutine's deferred
function.

So,  in order to do what I want, i must be able to trigger some sort
of inline panic remotely.   Note in the C code this is easy, the
signal handler will interrupt current thread, jump directly to the
handler code and resume.  If I can do that in golang, i will be able
to trigger a panic in main() and do what I want (or do what the old C
code does, which i was porting into go)

On Wed, Feb 15, 2017 at 10:14 AM, Yucong Sun  wrote:
> Thanks axle,  but are you sure the code would work?  it is essentially
> triggering panic on the main go routine while recovering from another
> goroutine, isn't that impossible?
>
> If this is possible, why couldn't I trigger a panic on a goroutine
> then recover it from main goroutine?
>
> On Wed, Feb 15, 2017 at 10:03 AM, Axel Wagner
>  wrote:
>> First, the code you wrote here doesn't use os/signal, so you can't really
>> fault Ian for giving that advice. Here's my understanding:
>>
>> In general, there are two kinds of signals: synchronous ones, raised e.g. by
>> dereferencing invalid memory. They produce a runtime panic at the site that
>> produced them in the corresponding goroutine. And asynchronous ones, raised
>> e.g. by using the kill command or os.Kill. They do not produce a runtime
>> panic but instead need to be handled via os/signal.
>>
>> Now, to "catch" asynchronous panic's, you need to use os/signal and if you
>> need them to produce a runtime-panic on the goroutine running main, you need
>> to read from that channel in main and produce a panic whenever you read a
>> value. You could, for example, do this:
>>
>> func main() {
>> ch := make(chan os.Signal)
>> signal.Notify(ch, mySignals)
>>
>> errs := make(chan interface{})
>>
>> go func() {
>> defer func() {
>> errs <- recover()
>> }()
>> for {
>> C.do_something()
>> }
>> }()
>>
>> for {
>> select {
>> case s := <-ch:
>> panic(fmt.Sprintf("received signal: %v", s))
>> case v := <-errs:
>> panic(fmt.Sprintf("recovered runtime panic in C-code: %v", v))
>> }
>> }
>> }
>>
>> this will get asynchronous signals via os/signal and synchronous signals in
>> the C-code raising runtime-panics via recover.
>>
>> Now, what is *not* possible, is to somehow recover from runtime panics
>> caused by synchronous signals in *other* goroutines. The spec is pretty
>> clear about that; a panic that isn't recovered will cause the program to
>> crash.
>>
>> Hope this helps.
>>
>> On Wed, Feb 15, 2017 at 6:44 PM, Yucong Sun  wrote:
>>>
>>> hi,
>>>
>>> Maybe I wasn't clear, I am indeed using os.signal package. But it doesn't
>>> do what I want!  I want to trigger a panic in main function , seems there is
>>> no way to do it by using a signal channel .
>>>
>>> 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] CodeReviewComments: Recommendation of gofmt

[roger peppe]

On 15 February 2017 at 13:48,   wrote:
>>
>> > Side-note: I don't think goimports can actually do what you are saying,
>> > can it? Because, if you run goimports on a valid program, it won't actually
>> > *change* any imports, it might just reformat it. For goimports to change
>> > anything semantically, the program would need to have missing imports to
>> > begin with.
>>
>> Of course, you're right. I should have said: It can silently turn an
>> invalid program into a valid one with different than intended/assumed
>> semantics. Security implications, however, remain.
>>
>
> I've experienced this (not in the sense of a security hole, but
> unintended/expected semantic change) in developing my little toy GUI
> wrapper. As I was writing in support for gotk3 after previously writing
> support code for go-gtk (GTK2), the similarity in the two code-bases several
> times lead goimports to bring in a mix of modules from the two different gtk
> libraries, causing odd build errors and forcing manual fixes.

This happens quite often to me. I sometimes wonder if goimports could
be cleverer about choosing packages when there are other imports
close by (for some value of "close by") that satisfy the constraints.

That applies to aliased packages too (in some code bases, some packages are
almost always aliased for ambiguity or convenience reasons).

-- 
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] Why get an element from []interface{} `arr[0] == nil` is not true?

[roger peppe]

In addition to what others have said, note that the
comparison works as you expected if you use a typed nil:

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


On 15 February 2017 at 08:40, Felix Sun  wrote:
> https://play.golang.org/p/qYA8Ddnnye
>
> ```
>
> package main
>
> import (
> "fmt"
> )
>
> type Obj struct {
> One *Obj
> }
>
> func main() {
> var o = {}
>
> var arr = []interface{}{o.One}
>
> fmt.Println(arr[0])
> fmt.Println("why this is not true?", arr[0] == nil)
> }
>
>
> ```
>
>
> Why `arr[0] == nil` is not true?
>
> --
> 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] How to run deferred function in main() on panic() in a goroutine?

['Axel Wagner' via golang-nuts]

First, the code you wrote here doesn't use os/signal, so you can't really
fault Ian for giving that advice. Here's my understanding:

In general, there are two kinds of signals: synchronous ones, raised e.g.
by dereferencing invalid memory. They produce a runtime panic at the site
that produced them in the corresponding goroutine. And asynchronous ones,
raised e.g. by using the kill command or os.Kill. They do not produce a
runtime panic but instead need to be handled via os/signal.

Now, to "catch" asynchronous panic's, you need to use os/signal and if you
need them to produce a runtime-panic on the goroutine running main, you
need to read from that channel in main and produce a panic whenever you
read a value. You could, for example, do this:

func main() {
ch := make(chan os.Signal)
signal.Notify(ch, mySignals)

errs := make(chan interface{})

go func() {
defer func() {
errs <- recover()
}()
for {
C.do_something()
}
}()

for {
select {
case s := <-ch:
panic(fmt.Sprintf("received signal: %v", s))
case v := <-errs:
panic(fmt.Sprintf("recovered runtime panic in C-code: %v", v))
}
}
}

this will get asynchronous signals via os/signal and synchronous signals in
the C-code raising runtime-panics via recover.

Now, what is *not* possible, is to somehow recover from runtime panics
caused by synchronous signals in *other* goroutines. The spec is pretty clear
about that ; a panic that
isn't recovered will cause the program to crash.

Hope this helps.

On Wed, Feb 15, 2017 at 6:44 PM, Yucong Sun  wrote:

> hi,
>
> Maybe I wasn't clear, I am indeed using os.signal package. But it doesn't
> do what I want!  I want to trigger a panic in main function , seems there
> is no way to do it by using a signal channel .
>
> 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] How to run deferred function in main() on panic() in a goroutine?

[Yucong Sun]

hi,

Maybe I wasn't clear, I am indeed using os.signal package. But it doesn't do 
what I want!  I want to trigger a panic in main function , seems there is no 
way to do it by using a signal channel .

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] empty nested template definitions not working as expected

[Manlio Perillo]

Hi.

I have found an unexpected behavior with the html/template package.
This is a sample program:
https://play.golang.org/p/Yh7UZJxQOd

It will print:



  

Test 2

  
  
Test
  




However, suppose I want to "disable" the "head" template;
the reasonable solution is to define an empty "head" template in the 
associated template:
https://play.golang.org/p/yexg_Hxujq

However this prints:



  

Test 1

  
  
Test
  



instead of the expected:



  

  
  
Test
  



Is this a bug?


Thanks
Manlio

-- 
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] Are the tests in the Go source code considered "Unit" tests?

[Ian Lance Taylor]

On Tue, Feb 14, 2017 at 10:35 PM,   wrote:
>
> From my understanding Unit Tests should focus on testing a single feature
> and not use the filesystem.
>
> But in the Go source (https://github.com/golang/go) I saw several tests that
> would violate those conditions.
>
> Should we strive to follow more standard conventions in our own unit tests?
> or are those tests idiomatic and acceptable for Go?

The tests in the Go source tree do not attempt to distinguish unit
tests from other sorts of tests.  They are all just tests.

You should follow whatever conventions you think will work best for
you.  Personally I would say that unit tests are a good idea but they
are not sufficient; you need some tests of the entire program.

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 run deferred function in main() on panic() in a goroutine?

[Ian Lance Taylor]

On Wed, Feb 15, 2017 at 12:35 AM,   wrote:
>
> I have a situation that need some advice. I have a main loop that is calling
> some C code (potentially looping forever).  and I need to handle signals
> like SIGABRT correctly by ensuring a cleanup function was run.
>
> func main() {
>
>   cleanup := func() {}
>   defer cleanup()
>
>   for {
>  C.do_something()
>   }
>
> }
>
> now , this works for synchronous signal / or anything caused by C code,
> because they will generate runtime panic on main thread, and deferred
> cleanup function will run.
>
> However, if I send signal through kill, the signal arrived in another
> thread, and apparently , main()'s defered functions  was never called , how
> do I catch that situation ?   I tried with a custom signal handler, but
> since I am busy looping in C code, I can't invoke panic() on the main
> thread.

Use the os/signal package.

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] CodeReviewComments: Recommendation of gofmt

[howardcshaw]

>
>
> > Side-note: I don't think goimports can actually do what you are saying, 
> can it? Because, if you run goimports on a valid program, it won't actually 
> *change* any imports, it might just reformat it. For goimports to change 
> anything semantically, the program would need to have missing imports to 
> begin with.
>
> Of course, you're right. I should have said: It can silently turn an 
> invalid program into a valid one with different than intended/assumed 
> semantics. Security implications, however, remain.
>
>
I've experienced this (not in the sense of a security hole, but 
unintended/expected semantic change) in developing my little toy GUI 
 wrapper. As I was writing in support for gotk3 after previously writing 
support code for go-gtk (GTK2), the similarity in the two code-bases 
several times lead goimports to bring in a mix of modules from the two 
different gtk libraries, causing odd build errors and forcing manual fixes.

-- 
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 parse script expression with go and run the script

[howardcshaw]

The go/parse package is not really going to help much, as Go is a compiled 
language. What you are wanting is something akin to a scripting language, 
something with an 'eval' type function. While it is just barely feasible 
that you could accomplish something directly with Go using on-the-fly 
compilation, dynamic object loading, and plugins, it is going to be a lot 
of work and not likely to be a comfortable fit.

My recommendation would be to look at simply embedding a script engine in 
your Go program. There are several Lua implementations for Go, for example.

Have a look at http://awesome-go.com/#embeddable-scripting-languages and 
see if one of them might work for your situation. 

-- 
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] How to run deferred function in main() on panic() in a goroutine?

[sunyc]

Hi,

I have a situation that need some advice. I have a main loop that is 
calling some C code (potentially looping forever).  and I need to handle 
signals like SIGABRT correctly by ensuring a cleanup function was run. 

func main() {

  cleanup := func() {}
  defer cleanup()

  for {
 C.do_something()
  }

}

now , this works for synchronous signal / or anything caused by C code, 
because they will generate runtime panic on main thread, and deferred 
cleanup function will run. 

However, if I send signal through kill, the signal arrived in another 
thread, and apparently , main()'s defered functions  was never called , how 
do I catch that situation ?   I tried with a custom signal handler, but 
since I am busy looping in C code, I can't invoke panic() on the main 
thread.

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

[go-nuts] building a linux binary with -race on a mac

[Joseph Lorenzini]

All:

I am writing and building my code on a mac. The code is a linux binary
though so its obviously a cross compilation. This works fine:

GOOS=linux GOARCH=amd64  go build .

This does not:

GOOS=linux GOARCH=amd64  go build -race .
go build: -race requires cgo; enable cgo by setting CGO_ENABLED=1

Nor does this:

 GOOS=linux GOARCH=amd64  CGO_ENABLED=1 go build -race .
# runtime/cgo
ld: unknown option: --build-id=none
clang: error: linker command failed with exit code 1 (use -v to see
invocation)



Go env below:

GOARCH="amd64"

GOBIN="/Users/jlorenzini/go/bin"

GOEXE=""

GOHOSTARCH="amd64"

GOHOSTOS="darwin"

GOOS="darwin"

GOPATH="/Users/jlorenzini/go"

GORACE=""

GOROOT="/usr/local/go"

GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"

CC="clang"

GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments
-fmessage-length=0
-fdebug-prefix-map=/var/folders/8w/7ndx_j6s36x9hm9dns67j21s3hynqn/T/go-build987997970=/tmp/go-build
-gno-record-gcc-switches -fno-common"

CXX="clang++"

CGO_ENABLED="1"

-- 
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: Why get an element from []interface{} `arr[0] == nil` is not true?

[djadala]

On Wednesday, February 15, 2017 at 11:25:16 AM UTC+2, dja...@gmail.com 
wrote:
>
>
>
> On Wednesday, February 15, 2017 at 10:40:35 AM UTC+2, Felix Sun wrote:
>>
>> https://play.golang.org/p/qYA8Ddnnye
>>
>> ```
>>
>> package main
>>
>> import (
>> "fmt"
>> )
>>
>> type Obj struct {
>> One *Obj
>> }
>>
>> func main() {
>> var o = {}
>>
>> var arr = []interface{}{o.One}
>>
>> fmt.Println(arr[0])
>> fmt.Println("why this is not true?", arr[0] == nil)
>> }
>>
>>
>> ```
>>
>>
>> Why `arr[0] == nil` is not true?
>>
>> Hi, there are misleading answers, so:
>
> First Println prints value of arr[0].One, winch is nil.
> Second Println check if f arr[0] is nil (arr[0] is address of 'o')
>
> Ops, my bad, this is not true,
> I must read source more carefully.
>
>

-- 
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: Why get an element from []interface{} `arr[0] == nil` is not true?

[djadala]

On Wednesday, February 15, 2017 at 10:40:35 AM UTC+2, Felix Sun wrote:
>
> https://play.golang.org/p/qYA8Ddnnye
>
> ```
>
> package main
>
> import (
> "fmt"
> )
>
> type Obj struct {
> One *Obj
> }
>
> func main() {
> var o = {}
>
> var arr = []interface{}{o.One}
>
> fmt.Println(arr[0])
> fmt.Println("why this is not true?", arr[0] == nil)
> }
>
>
> ```
>
>
> Why `arr[0] == nil` is not true?
>
> Hi, there are misleading answers, so:

First Println prints value of arr[0].One, winch is nil.
Second Println check if f arr[0] is nil (arr[0] is address of 'o')

Regards,
Djadala

-- 
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: Why get an element from []interface{} `arr[0] == nil` is not true?

[Volker Dobler]

Am Mittwoch, 15. Februar 2017 09:40:35 UTC+1 schrieb Felix Sun:
>
> https://play.golang.org/p/qYA8Ddnnye
>
> ```
>
> package main
>
> import (
> "fmt"
> )
>
> type Obj struct {
> One *Obj
> }
>
> func main() {
> var o = {}
>
> var arr = []interface{}{o.One}
>
> fmt.Println(arr[0])
> fmt.Println("why this is not true?", arr[0] == nil)
> }
>
>
> ```
>
>
> Why `arr[0] == nil` is not true?
>
>
Its an instance of https://golang.org/doc/faq#nil_error.

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] Why get an element from []interface{} `arr[0] == nil` is not true?

[Jan Mercl]

On Wed, Feb 15, 2017 at 9:40 AM Felix Sun  wrote:

Why `arr[0] == nil` is not true?

Because it's not a nil interface{}: https://play.golang.org/p/w-od_KHWlc

See also https://golang.org/doc/faq#nil_error

-- 

-j

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

Re: [go-nuts] Why get an element from []interface{} `arr[0] == nil` is not true?

['Axel Wagner' via golang-nuts]

This is a frequently asked question  (it
has nothing to do with the slice).

On Wed, Feb 15, 2017 at 9:40 AM, Felix Sun  wrote:

> https://play.golang.org/p/qYA8Ddnnye
>
> ```
>
> package main
>
> import (
> "fmt"
> )
>
> type Obj struct {
> One *Obj
> }
>
> func main() {
> var o = {}
>
> var arr = []interface{}{o.One}
>
> fmt.Println(arr[0])
> fmt.Println("why this is not true?", arr[0] == nil)
> }
>
>
> ```
>
>
> Why `arr[0] == nil` is not true?
>
> --
> 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] Why get an element from []interface{} `arr[0] == nil` is not true?

[Felix Sun]

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

```

package main

import (
"fmt"
)

type Obj struct {
One *Obj
}

func main() {
var o = {}

var arr = []interface{}{o.One}

fmt.Println(arr[0])
fmt.Println("why this is not true?", arr[0] == nil)
}


```


Why `arr[0] == nil` is not true?

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