[go-nuts] Re: Syscall trouble with parameter handling

[snmed]

Has anyone a hint, what i'm doing wrong with the Call arguments? I think 
the last parameter is the problematic one, but i can't figure out how to 
pass that argument.

Any help would be most appreciated!

Cheers snmed

Am Dienstag, 21. Februar 2017 10:36:29 UTC+1 schrieb snmed:
>
> Hi all
>
> I try to use the syscall package to call a native Windows API and 
> struggling with the call parameters. I calling the api
>
> HRESULT WINAPI AmsiInitialize(
>   _In_  LPCWSTR  appName,
>   _In_  DWORDcoInit,
>   _Out_ HAMSICONTEXT *amsiContext
> );
>
>
> my test app looks like this
> package main
>
> import (
> "fmt"
>
> "syscall"
> "unsafe"
>
> "golang.org/x/sys/windows"
> )
>
> func main() {
> h := windows.MustLoadDLL("Amsi.dll")
> defer h.Release()
>
> ainit := h.MustFindProc("AmsiInitialize")
> auinit := h.MustFindProc("AmsiUninitialize")
> ascanstring := h.MustFindProc("AmsiScanString")
>
> var context uintptr
> r1, r2, err := ainit.Call(uintptr(unsafe.Pointer(syscall.
> StringToUTF16Ptr("Scanner Tool"))), 0, uintptr(unsafe.Pointer()))
> fmt.Println(context)
> fmt.Println(r1, r2, err)
> // output:
> // 0
> // 2147942487 0 The operation completed successfully.
>
> unfortunately the call succeeds but the context is still zero. Probably i 
> call the function with the wrong parameters but i can't work it out.
> Has anybody a idea what could be wrong?
>
> Thank you in advance
> snmed
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Trying to understand := and named return values

[John Souvestre]

Ø  Again, named return values are fine and cause no problems, but naked returns 
should never have been part of the language (at first they seem useful and 
cool, but in the end, they cause more problems than they solve).

 

I agree.  Perhaps in Go 2?  J

 

John

John Souvestre - New Orleans LA

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Trying to understand := and named return values

['Paul Borman' via golang-nuts]

Named return values are perfectly fine, and I agree, probably should not be
discouraged.  For example, which is easier to write documentation for?

func Run(cmd string) ([]byte, []byte, error)

func Run(cmd string) (stdout, stderr []byte, _ error)

What is not good is the following function:

func Foo() (err error) {
if err := someFunc(); err != nil {
return  // Why do I always get a nil error?!?!
}
return
}

This is a* naked return* and that is what is bad, not that you named your
return values.   This version is fine:

func Foo() (err error) {
if err := someFunc(); err != nil {
return  err
}
return nil
}

As there is no doubt on what is being returned.  And as mentioned earlier,
named returns are very useful in defers:

func Foo(path string) (err error) {
w, err := os.Create(path, 0644)
if err != nil {
return err
}
defer func() {
if cerr := w.Close(); cerr != nil && err == nil {
err = cerr
}
}()
...
}


Again, named return values are fine and cause no problems, but naked
returns should never have been part of the language (at first they seem
useful and cool, but in the end, they cause more problems than they solve).

On Tue, Feb 21, 2017 at 8:25 PM,  wrote:

> Named returns are actually quite useful with panics :
>
> https://play.golang.org/p/ZdoZJBN0T1
>
>
> Le mardi 21 février 2017 23:13:11 UTC+1, Ian Lance Taylor a écrit :
>>
>> On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
>> > Seems like named returns + if/for/switch initializers = a shadowing
>> > nightmare. I wish the Go compiler emitted a loud warning on shadowing,
>> as
>> > this is a dangerously subtle problem out there.
>>
>> Yes, named returns may have been a mistake.  Only use them in very
>> very short functions.
>>
>> 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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [go-nuts] Re: Trying to understand := and named return values

[prades . marq]

Named returns are actually quite useful with panics :

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


Le mardi 21 février 2017 23:13:11 UTC+1, Ian Lance Taylor a écrit :
>
> On Tue, Feb 21, 2017 at 1:46 PM,   
> wrote: 
> > Seems like named returns + if/for/switch initializers = a shadowing 
> > nightmare. I wish the Go compiler emitted a loud warning on shadowing, 
> as 
> > this is a dangerously subtle problem out there. 
>
> Yes, named returns may have been a mistake.  Only use them in very 
> very short functions. 
>
> 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: Trying to understand := and named return values

[John Souvestre]

I feel the opposite.  I view named returns as documentation of a function's 
parameters.  I'm constantly amazed by the (correct) emphasis placed on using 
appropriate names for calling parameters, but not for the return parameters.  
The goal is that I shouldn't have to read a function's code to use the 
function, right?

So how can the disparity be justified?  Oh, and the longer the function is the 
more benefit there is to using them.

John

John Souvestre - New Orleans LA


-Original Message-
From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Ian Lance Taylor
Sent: 2017 February 21, Tue 16:13
To: andrew.penneba...@gmail.com
Cc: golang-nuts
Subject: Re: [go-nuts] Re: Trying to understand := and named return values

On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.

Yes, named returns may have been a mistake.  Only use them in very
very short functions.

Ian

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

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

[go-nuts] Re: Unsafe string/slice conversions

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 2:53 PM, Caleb Spare  wrote:
> I have a program that uses unsafe in order to coerce some slices to
> strings for use as map keys. (Avoiding these allocations ends up being
> an important performance optimization to this program.)
>
> Here's some example code that shows what I'm doing:
>
> https://play.golang.org/p/Yye1Riv0Jj
>
> Does this seem OK? I've tried to make sure I understand how all the
> unsafe codes fits into the blessed idioms at
> https://golang.org/pkg/unsafe/#Pointer. The part I'm most curious
> about is the indicated line:
>
> sh.Data = (*reflect.StringHeader)(unsafe.Pointer()).Data // <---
>
> This is a double-application of rule 6: it's a conversion *from* a
> reflect.StringHeader's Data field *to* a reflect.SliceHeader's Data
> field, through an unsafe.Pointer and uintptr.
>
> This code has been working for a long time and appears to continue to
> work, but I've been re-reviewing all my unsafe usage after reading the
> conversation at https://github.com/golang/go/issues/19168.

I can't see anything wrong with this code.  Maybe someone else can.

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] Unsafe string/slice conversions

[Caleb Spare]

I have a program that uses unsafe in order to coerce some slices to
strings for use as map keys. (Avoiding these allocations ends up being
an important performance optimization to this program.)

Here's some example code that shows what I'm doing:

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

Does this seem OK? I've tried to make sure I understand how all the
unsafe codes fits into the blessed idioms at
https://golang.org/pkg/unsafe/#Pointer. The part I'm most curious
about is the indicated line:

sh.Data = (*reflect.StringHeader)(unsafe.Pointer()).Data // <---

This is a double-application of rule 6: it's a conversion *from* a
reflect.StringHeader's Data field *to* a reflect.SliceHeader's Data
field, through an unsafe.Pointer and uintptr.

This code has been working for a long time and appears to continue to
work, but I've been re-reviewing all my unsafe usage after reading the
conversation at https://github.com/golang/go/issues/19168.

Thanks for any insights.
Caleb

P.S. In this particular case, I'm planning on replacing the map with a
custom hashtable (since it's very specialized I can do better than a
built-in map type) and that will eliminate the unsafe code.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Manlio Perillo]

On Tue, Feb 21, 2017 at 11:29 PM, andrey mirtchovski
 wrote:
> You can try binary.Size but you'll also run into the same problem:
> int's size is platform specific (binary.Size returns -1 for ints). As
> the go faq states "For portability, code that relies on a particular
> size of value should use an explicitly sized type, like int64."

Actually, for this specific case, there is a very simple method to
compute the size of int at compile time:
https://www.reddit.com/r/golang/comments/4vaaip/number_of_bits_in_an_integer_type/

This is used in strconv/atoi.go.


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] flag: possible issue with intValue.Set

[andrey mirtchovski]

You can try binary.Size but you'll also run into the same problem:
int's size is platform specific (binary.Size returns -1 for ints). As
the go faq states "For portability, code that relies on a particular
size of value should use an explicitly sized type, like int64."

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Manlio Perillo]

Il giorno martedì 21 febbraio 2017 23:00:44 UTC+1, Matt Harden ha scritto:
>
> Sizeof does exist in the unsafe package and returns a compile time 
> constant.
>
>
One usually don't want to import the unsafe package just to use the Sizeof 
function in a safe package.
This is the reason why I'm curious to why sizeof is not a builtin function.
It is true that Sizeof is usually used in unsafe packages, but this is not 
always true.
 
> [...]

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] Re: Trying to understand := and named return values

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 1:46 PM,   wrote:
> Seems like named returns + if/for/switch initializers = a shadowing
> nightmare. I wish the Go compiler emitted a loud warning on shadowing, as
> this is a dangerously subtle problem out there.

Yes, named returns may have been a mistake.  Only use them in very
very short functions.

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] flag: possible issue with intValue.Set

[Matt Harden]

Sizeof does exist in the unsafe package and returns a compile time constant.

On Tue, Feb 21, 2017, 13:56 Manlio Perillo  wrote:

> Il giorno martedì 21 febbraio 2017 22:14:38 UTC+1, Ian Lance Taylor ha
> scritto:
>
> On Tue, Feb 21, 2017 at 9:51 AM, Manlio Perillo
>  wrote:
> > I have noted that the intValue (and uintValue) Set method do the
> following:
> > v, err := strconv.ParseInt(s, 0, 64)
> >
> > However this is incorrect on 32 bit systems:
> > https://play.golang.org/p/tvAUCI63x3
> >
> > Can this be considered a bug?
>
> Yes, I think so.
>
>
> Done, thanks
>
> https://github.com/golang/go/issues/19230
>
> By the way, a sizeof builtin function would be useful to have.
>
>
> 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Caleb Spare]

Like unsafe.Sizeof?

On Tue, Feb 21, 2017 at 1:56 PM, Manlio Perillo
 wrote:
> Il giorno martedì 21 febbraio 2017 22:14:38 UTC+1, Ian Lance Taylor ha
> scritto:
>>
>> On Tue, Feb 21, 2017 at 9:51 AM, Manlio Perillo
>>  wrote:
>> > I have noted that the intValue (and uintValue) Set method do the
>> > following:
>> > v, err := strconv.ParseInt(s, 0, 64)
>> >
>> > However this is incorrect on 32 bit systems:
>> > https://play.golang.org/p/tvAUCI63x3
>> >
>> > Can this be considered a bug?
>>
>> Yes, I think so.
>>
>
> Done, thanks
>
> https://github.com/golang/go/issues/19230
>
> By the way, a sizeof builtin function would be useful to have.
>
>
> 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.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Manlio Perillo]

Il giorno martedì 21 febbraio 2017 22:14:38 UTC+1, Ian Lance Taylor ha 
scritto:
>
> On Tue, Feb 21, 2017 at 9:51 AM, Manlio Perillo 
>  wrote: 
> > I have noted that the intValue (and uintValue) Set method do the 
> following: 
> > v, err := strconv.ParseInt(s, 0, 64) 
> > 
> > However this is incorrect on 32 bit systems: 
> > https://play.golang.org/p/tvAUCI63x3 
> > 
> > Can this be considered a bug? 
>
> Yes, I think so. 
>
>
Done, thanks

https://github.com/golang/go/issues/19230

By the way, a sizeof builtin function would be useful to have.


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 do you implement and use Context.Done?

['Thomas Bushnell, BSG' via golang-nuts]

Oops! ::blush::

On Tue, Feb 21, 2017 at 11:39 AM Axel Wagner 
wrote:

> Wrong list :) You meant to link here:
> https://godoc.org/context#Context.Err
>
> On Tue, Feb 21, 2017 at 8:15 PM, 'Thomas Bushnell, BSG' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
> On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:
>
> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
> > Thanks, I see you build it up with decorators on a standard prototype.
> > For example: https://play.golang.org/p/PJy5lE9QqF
> >
> > So context.Done is a convenience function for those that require it?
> > Otherwise a context will expire after it leaves scope, so Done does not
> need
> > to be called?
>
> Cancelling the context just marks the context as cancelled.  It does
> not actually stop any goroutines using the context.  Those goroutines
> must themselves periodically check the context to see whether it has
> been cancelled, and, if so, stop working.  They do that by calling
> either the Done or Err method; it's much more common to call the Done
> method (and check whether the channel is closed).
>
>
> Calling the Err() method to see if the context has been cancelled is
> incorrect.  See
> https://godoc.corp.google.com/pkg/google3/go/context/context#Context.Err:
> "Err's return value is unspecified before Done is closed."
>
> Thomas
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 9:51 AM, Manlio Perillo
 wrote:
> I have noted that the intValue (and uintValue) Set method do the following:
> v, err := strconv.ParseInt(s, 0, 64)
>
> However this is incorrect on 32 bit systems:
> https://play.golang.org/p/tvAUCI63x3
>
> Can this be considered a bug?

Yes, I think so.

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 do you implement and use Context.Done?

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 12:45 PM, Ian Lance Taylor  wrote:
> On Tue, Feb 21, 2017 at 11:15 AM, Thomas Bushnell, BSG
>  wrote:
>> On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:
>>>
>>> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
>>> > Thanks, I see you build it up with decorators on a standard prototype.
>>> > For example: https://play.golang.org/p/PJy5lE9QqF
>>> >
>>> > So context.Done is a convenience function for those that require it?
>>> > Otherwise a context will expire after it leaves scope, so Done does not
>>> > need
>>> > to be called?
>>>
>>> Cancelling the context just marks the context as cancelled.  It does
>>> not actually stop any goroutines using the context.  Those goroutines
>>> must themselves periodically check the context to see whether it has
>>> been cancelled, and, if so, stop working.  They do that by calling
>>> either the Done or Err method; it's much more common to call the Done
>>> method (and check whether the channel is closed).
>>
>>
>> Calling the Err() method to see if the context has been cancelled is
>> incorrect.
>
> ...
>
>> "Err's return value is unspecified before Done is closed."
>
> Hmmm, that text is not in the version of the context package included
> in the Go standard library.  Perhaps it should be.

Sent https://golang.org/cl/37375 .

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 do you implement and use Context.Done?

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 11:15 AM, Thomas Bushnell, BSG
 wrote:
> On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:
>>
>> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
>> > Thanks, I see you build it up with decorators on a standard prototype.
>> > For example: https://play.golang.org/p/PJy5lE9QqF
>> >
>> > So context.Done is a convenience function for those that require it?
>> > Otherwise a context will expire after it leaves scope, so Done does not
>> > need
>> > to be called?
>>
>> Cancelling the context just marks the context as cancelled.  It does
>> not actually stop any goroutines using the context.  Those goroutines
>> must themselves periodically check the context to see whether it has
>> been cancelled, and, if so, stop working.  They do that by calling
>> either the Done or Err method; it's much more common to call the Done
>> method (and check whether the channel is closed).
>
>
> Calling the Err() method to see if the context has been cancelled is
> incorrect.

...

> "Err's return value is unspecified before Done is closed."

Hmmm, that text is not in the version of the context package included
in the Go standard library.  Perhaps it should be.

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: Import path search order?

[so . query]

Thanks for the clarification!


On Tuesday, February 21, 2017 at 10:00:41 AM UTC-8, Nathan Kerr wrote:
>
> GOPATH is a list 
> , though it 
> usually only contains one element. The first element in the list is the 
> leftmost one (e.g., GOPATH=first:second:last).
>
> GOROOT holds the standard library, so those packages must be findable. The 
> standard library is distributed as source.
>
> On Tuesday, February 21, 2017 at 5:51:10 PM UTC+1, so.q...@gmail.com 
> wrote:
>>
>> Thanks! 
>>
>> what do you mean by "from left to right"?
>> And by GOROOT, you mean it looks at the go source?
>>
>>
>>
>> On Tuesday, February 21, 2017 at 1:27:59 AM UTC-8, Nathan Kerr wrote:
>>>
>>> Relative package don't need to be searched for, they are explicit 
>>> (indicated with ./ or ../)
>>>
>>> Then it seems to be:
>>>
>>> 1. vendor tree, if it exists
>>> 2. GOROOT
>>> 3. GOPATH, from left to right
>>>
>>> Trying to build a package with an import that cannot be found will 
>>> display an error listing all the locations it looked for the package. To 
>>> get the vendor tree listed, a vendor directory must exist in the package 
>>> you are trying to build.
>>>
>>>
>>> On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com 
>>> wrote:

 What is the search order for the import path?
 for example, relative then vendor then workspace?




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] History: Does the _ (Blank identifier) trace its history back to VI's or something earlier?

[Rob Pike]

Perhaps, but in Go it's just the shortest name that looks meaningless.
Nothing inspired it but brevity.

-rob


On Tue, Feb 21, 2017 at 11:25 AM, Wim Lewis  wrote:

> If I had to speculate, I'd guess that the use of "_" for an anonymous or
> blank identifier in pattern matching and destructuring traces back to
> Prolog.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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 do you implement and use Context.Done?

['Axel Wagner' via golang-nuts]

Wrong list :) You meant to link here:
https://godoc.org/context#Context.Err

On Tue, Feb 21, 2017 at 8:15 PM, 'Thomas Bushnell, BSG' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:
>
>> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
>> > Thanks, I see you build it up with decorators on a standard prototype.
>> > For example: https://play.golang.org/p/PJy5lE9QqF
>> >
>> > So context.Done is a convenience function for those that require it?
>> > Otherwise a context will expire after it leaves scope, so Done does not
>> need
>> > to be called?
>>
>> Cancelling the context just marks the context as cancelled.  It does
>> not actually stop any goroutines using the context.  Those goroutines
>> must themselves periodically check the context to see whether it has
>> been cancelled, and, if so, stop working.  They do that by calling
>> either the Done or Err method; it's much more common to call the Done
>> method (and check whether the channel is closed).
>>
>
> Calling the Err() method to see if the context has been cancelled is
> incorrect.  See https://godoc.corp.google.com/pkg/google3/go/context/
> context#Context.Err: "Err's return value is unspecified before Done is
> closed."
>
> Thomas
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Alexander Kapshuk]

On Tue, Feb 21, 2017 at 9:13 PM, Alexander Kapshuk
 wrote:
> On Tue, Feb 21, 2017 at 7:51 PM, Manlio Perillo
>  wrote:
>> I have noted that the intValue (and uintValue) Set method do the following:
>> v, err := strconv.ParseInt(s, 0, 64)
>>
>> However this is incorrect on 32 bit systems:
>> https://play.golang.org/p/tvAUCI63x3
>>
>> Can this be considered a bug?
>>
>> Another, minor, issue is that:
>> *i = intValue(v)
>> return err
>>
>> i is set to 0 in case of error, discarding the default value.
>> It is probably not an issue with the flag package, but probably should be
>> corrected.
>>
>>
>> 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.
>
> Looks like 'v' gets truncated towards zero when cast to int, which is
> at least 32 bits in size, https://golang.org/pkg/builtin/#int.
>
> Declaring '*i' as type int64 retains the value of 'v' in '*i'.
> https://play.golang.org/p/Cgg9itErt9

int(int64) conversion overflows int.

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

Output:

tmp/sandbox655723034/main.go:9: constant 8589934592 overflows int

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] History: Does the _ (Blank identifier) trace its history back to VI's or something earlier?

[Wim Lewis]

If I had to speculate, I'd guess that the use of "_" for an anonymous or blank 
identifier in pattern matching and destructuring traces back to Prolog.


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 do you implement and use Context.Done?

['Thomas Bushnell, BSG' via golang-nuts]

On Mon, Feb 20, 2017 at 11:42 AM Ian Lance Taylor  wrote:

> On Sun, Feb 19, 2017 at 2:57 PM,   wrote:
> > Thanks, I see you build it up with decorators on a standard prototype.
> > For example: https://play.golang.org/p/PJy5lE9QqF
> >
> > So context.Done is a convenience function for those that require it?
> > Otherwise a context will expire after it leaves scope, so Done does not
> need
> > to be called?
>
> Cancelling the context just marks the context as cancelled.  It does
> not actually stop any goroutines using the context.  Those goroutines
> must themselves periodically check the context to see whether it has
> been cancelled, and, if so, stop working.  They do that by calling
> either the Done or Err method; it's much more common to call the Done
> method (and check whether the channel is closed).
>

Calling the Err() method to see if the context has been cancelled is
incorrect.  See
https://godoc.corp.google.com/pkg/google3/go/context/context#Context.Err:
"Err's return value is unspecified before Done is closed."

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Alexander Kapshuk]

On Tue, Feb 21, 2017 at 7:51 PM, Manlio Perillo
 wrote:
> I have noted that the intValue (and uintValue) Set method do the following:
> v, err := strconv.ParseInt(s, 0, 64)
>
> However this is incorrect on 32 bit systems:
> https://play.golang.org/p/tvAUCI63x3
>
> Can this be considered a bug?
>
> Another, minor, issue is that:
> *i = intValue(v)
> return err
>
> i is set to 0 in case of error, discarding the default value.
> It is probably not an issue with the flag package, but probably should be
> corrected.
>
>
> 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.

Looks like 'v' gets truncated towards zero when cast to int, which is
at least 32 bits in size, https://golang.org/pkg/builtin/#int.

Declaring '*i' as type int64 retains the value of 'v' in '*i'.
https://play.golang.org/p/Cgg9itErt9

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Import path search order?

[Nathan Kerr]

GOPATH is a list 
, though it 
usually only contains one element. The first element in the list is the 
leftmost one (e.g., GOPATH=first:second:last).

GOROOT holds the standard library, so those packages must be findable. The 
standard library is distributed as source.

On Tuesday, February 21, 2017 at 5:51:10 PM UTC+1, so.q...@gmail.com wrote:
>
> Thanks! 
>
> what do you mean by "from left to right"?
> And by GOROOT, you mean it looks at the go source?
>
>
>
> On Tuesday, February 21, 2017 at 1:27:59 AM UTC-8, Nathan Kerr wrote:
>>
>> Relative package don't need to be searched for, they are explicit 
>> (indicated with ./ or ../)
>>
>> Then it seems to be:
>>
>> 1. vendor tree, if it exists
>> 2. GOROOT
>> 3. GOPATH, from left to right
>>
>> Trying to build a package with an import that cannot be found will 
>> display an error listing all the locations it looked for the package. To 
>> get the vendor tree listed, a vendor directory must exist in the package 
>> you are trying to build.
>>
>>
>> On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com 
>> wrote:
>>>
>>> What is the search order for the import path?
>>> for example, relative then vendor then workspace?
>>>
>>>
>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] flag: possible issue with intValue.Set

[Manlio Perillo]

I have noted that the intValue (and uintValue) Set method do the following:
v, err := strconv.ParseInt(s, 0, 64)

However this is incorrect on 32 bit systems:
https://play.golang.org/p/tvAUCI63x3

Can this be considered a bug?

Another, minor, issue is that:
*i = intValue(v)
return err

i is set to 0 in case of error, discarding the default value.
It is probably not an issue with the flag package, but probably should be 
corrected.


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] Go Compiler Intermediate Representation

[Ian Lance Taylor]

On Tue, Feb 21, 2017 at 9:15 AM, Arpit Aggarwal  wrote:
>
> I am doing a project in which I need Go compiler's intermediate
> representation(IR) (which is semantics preserving and I can get all all info
> like line number and data type and other features) (human readable) to
> convert to another IR of a tool.
> I am new to Golang.
> Can anybody tell me how can I generate it from the Go compiler.
> I also tried this blog but the new versions of go compiler doesn't support
> this.
> I also tried llgo but was able to generate llvm-ir from llgo's docker image
> available and not able to build llgo myself.
> Any help would be highly appreciated.

Unfortunately there is no simple way to do this using the Go compiler.

If you don't actually need the Go compiler itself, then you should use
the go/types package.  That is a complete semantics preserving
representation of a Go program with position and type information.

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] Go Compiler Intermediate Representation

[Arpit Aggarwal]

Thanks a lot *Ian*.
Will try it and ask if I have any further doubts.

Thanks,
Arpit

On Tuesday, February 21, 2017 at 10:59:41 PM UTC+5:30, Ian Lance Taylor 
wrote:
>
> On Tue, Feb 21, 2017 at 9:15 AM, Arpit Aggarwal  > wrote: 
> > 
> > I am doing a project in which I need Go compiler's intermediate 
> > representation(IR) (which is semantics preserving and I can get all all 
> info 
> > like line number and data type and other features) (human readable) to 
> > convert to another IR of a tool. 
> > I am new to Golang. 
> > Can anybody tell me how can I generate it from the Go compiler. 
> > I also tried this blog but the new versions of go compiler doesn't 
> support 
> > this. 
> > I also tried llgo but was able to generate llvm-ir from llgo's docker 
> image 
> > available and not able to build llgo myself. 
> > Any help would be highly appreciated. 
>
> Unfortunately there is no simple way to do this using the Go compiler. 
>
> If you don't actually need the Go compiler itself, then you should use 
> the go/types package.  That is a complete semantics preserving 
> representation of a Go program with position and type information. 
>
> 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 Compiler Intermediate Representation

[Arpit Aggarwal]

Hi all,
I am doing a project in which I need Go compiler's intermediate 
representation(IR) (which is semantics preserving and I can get all all 
info like line number and data type and other features) (human readable) to 
convert to another IR of a tool.
I am new to Golang.
Can anybody tell me how can I generate it from the Go compiler.
I also tried this blog 

 
but the new versions of go compiler doesn't support this.
I also tried llgo but was able to generate llvm-ir from llgo's docker image 
available and not able to build llgo myself.
Any help would be highly appreciated.
Thanks in advance.

Thanks,
Arpit
 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Cannot decrypt rsa.EncryptOAEP messages with openssl

[John-Paul Bader]

Hello,


I have the following code where I'm loading an RSA pub key to encrypt a 
message and write it to a file. 

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

Then I'm trying to decrypt it with the following openssl command:

openssl rsautl -decrypt -inkey private.pem -oaep -in cryptedmessage -out 
decrypted
RSA operation error
11511:error:0407A079:rsa routines:RSA_padding_check_PKCS1_OAEP:oaep 
decoding 
error:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/crypto/rsa/rsa_oaep.c:199:
11511:error:04065072:rsa routines:RSA_EAY_PRIVATE_DECRYPT:padding check 
failed:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/crypto/rsa/rsa_eay.c:614:

But it doesn't work and I don't know why. 

If I encrypt and decrypt a message just with openssl using the same 
pub/priv keys it works of course

So its either something with the OAEP padding or I'm doing something else 
wrong. Either way, any clues would be appreciated.

Kind regards,

~ John

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Import path search order?

[so . query]

Thanks! 

what do you mean by "from left to right"?
And by GOROOT, you mean it looks at the go source?



On Tuesday, February 21, 2017 at 1:27:59 AM UTC-8, Nathan Kerr wrote:
>
> Relative package don't need to be searched for, they are explicit 
> (indicated with ./ or ../)
>
> Then it seems to be:
>
> 1. vendor tree, if it exists
> 2. GOROOT
> 3. GOPATH, from left to right
>
> Trying to build a package with an import that cannot be found will display 
> an error listing all the locations it looked for the package. To get the 
> vendor tree listed, a vendor directory must exist in the package you are 
> trying to build.
>
>
> On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com 
> wrote:
>>
>> What is the search order for the import path?
>> for example, relative then vendor then workspace?
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 test -race much slower in 1.8 (was Re: [go-nuts] Go 1.8 is released)

[Will Newton]

On Tue, Feb 21, 2017 at 11:56 AM, peterGo  wrote:
> Will,
>
> "it looks like the plan is to fix this in Go 1.9 rather than 1.8.x, is that
> the case? " What makes you think that?
>
> https://github.com/golang/go/issues/19151: Milestone Go1.8.1
>
> https://github.com/golang/go/issues/19133: Milestone Go1.8.1

Thanks, yes I had misread the github ticket.

> Peter
>
> On Tuesday, February 21, 2017 at 5:41:25 AM UTC-5, Will Newton wrote:
>>
>> On Mon, Feb 20, 2017 at 8:23 PM, Ian Lance Taylor 
>> wrote:
>> > On Mon, Feb 20, 2017 at 12:06 PM, Will Newton 
>> > wrote:
>> >> On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot 
>> >> wrote:
>> >>> Hello gophers,
>> >>>
>> >>> We just released Go 1.8.
>> >>>
>> >>> You can read the announcement blog post here:
>> >>>   https://blog.golang.org/go1.8
>> >>>
>> >>> You can download binary and source distributions from our download
>> >>> page:
>> >>>   https://golang.org/dl/
>> >>>
>> >>> To compile from source using a Git checkout, update to the release
>> >>> with "git
>> >>> checkout go1.8" and build as usual.
>> >>>
>> >>> To find out what has changed, read the release notes:
>> >>>   https://golang.org/doc/go1.8
>> >>>
>> >>> Thanks to everyone who contributed to the release.
>> >>
>> >> After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone
>> >> up from ~4 minutes to ~20 minutes. We run it with "go test -race
>> >> -covermode=atomic -coverprofile=coverage.tmp" and it seems like one or
>> >> other of coverage or race detector is implicated. Is anything like
>> >> this expected?
>> >
>> > This could possibly be related to https://golang.org/issue/19133
>> > and/or https://golang.org/issue/19151.
>>
>> Thanks, this looks like it could be it. Is there a suggested
>> workaround beyond running my testsuite without coverage/race detector?
>>
>> Also it looks like the plan is to fix this in Go 1.9 rather than
>> 1.8.x, is that the case?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: Can anyone provide an example or stopping and/or starting an established Windows service?

[Tamás Gulácsi]

A working windows service example is at 
https://github.com/tgulacsi/agostle/blob/master/main_windows.go

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

[go-nuts] Interfaces in Go (part II) - type assertion & type switch

[Michał Łowicki]

https://medium.com/golangspec/interfaces-in-go-part-ii-d5057ffdb0a6

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 test -race much slower in 1.8 (was Re: [go-nuts] Go 1.8 is released)

[peterGo]

Will,

"it looks like the plan is to fix this in Go 1.9 rather than 1.8.x, is that 
the case? " What makes you think that? 

https://github.com/golang/go/issues/19151: Milestone Go1.8.1

https://github.com/golang/go/issues/19133: Milestone Go1.8.1

Peter

On Tuesday, February 21, 2017 at 5:41:25 AM UTC-5, Will Newton wrote:
>
> On Mon, Feb 20, 2017 at 8:23 PM, Ian Lance Taylor  > wrote: 
> > On Mon, Feb 20, 2017 at 12:06 PM, Will Newton  > wrote: 
> >> On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot  > wrote: 
> >>> Hello gophers, 
> >>> 
> >>> We just released Go 1.8. 
> >>> 
> >>> You can read the announcement blog post here: 
> >>>   https://blog.golang.org/go1.8 
> >>> 
> >>> You can download binary and source distributions from our download 
> page: 
> >>>   https://golang.org/dl/ 
> >>> 
> >>> To compile from source using a Git checkout, update to the release 
> with "git 
> >>> checkout go1.8" and build as usual. 
> >>> 
> >>> To find out what has changed, read the release notes: 
> >>>   https://golang.org/doc/go1.8 
> >>> 
> >>> Thanks to everyone who contributed to the release. 
> >> 
> >> After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone 
> >> up from ~4 minutes to ~20 minutes. We run it with "go test -race 
> >> -covermode=atomic -coverprofile=coverage.tmp" and it seems like one or 
> >> other of coverage or race detector is implicated. Is anything like 
> >> this expected? 
> > 
> > This could possibly be related to https://golang.org/issue/19133 
> > and/or https://golang.org/issue/19151. 
>
> Thanks, this looks like it could be it. Is there a suggested 
> workaround beyond running my testsuite without coverage/race detector? 
>
> Also it looks like the plan is to fix this in Go 1.9 rather than 
> 1.8.x, is that the case? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 UDP performance

[Konstantin Khomoutov]

On Mon, 20 Feb 2017 13:02:15 -0800
Tharaneedharan Vilwanathan  wrote:

> Hi All,
> 
> I am trying to send a lot of UDP packets from Go code but I realized
> UDP performance is too low. The max I was able to do is about
> 160Mbps. This is in Ubuntu 16.10 on x86_64 (i7-6700HQ).
> 
> I tried to google on this and it looks like this is about the
> performance we can get. I am a bit surprised.
> 
> Am I missing something? Any suggestions on how to improve the
> performance?

You could estimate what a "dumb sender written in C" could produce:

On the receiver box, do:

  # apt install netcat-openbsd
  $ nc -k -u -l  >/dev/null

On the sender box, do:

  # apt install netcat-openbsd pv
  $ pv https://groups.google.com/d/optout.

[go-nuts] Re: Go UDP performance

[anupam . kapoor]

> "Franke" == Marcus Franke writes:

,[ Franke ]
| an additional note, don't forget to monitor the netstat udp counter on both
| servers.
| 
| % netstat -auns | grep -A 7 "Udp:"
| Udp:
| 9381 packets received
| 0 packets to unknown port received
| 0 packet receive errors
| 1009 packets sent
| 0 receive buffer errors
| 0 send buffer errors
| IgnoredMulti: 1264
| 
| Maybe your client is dropping the packets and it is not your sender.
`
moreover, depending on how your datagrams looks like (src+dst ip, and
src+dst port), kernel might be distributing each rx-queue of your nic to
the same cpu core. perhaps, SO_REUSEPORT can be used to alleviate this ?

--
kind regards
anupam

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 Concurrency Patterns: Pipelines

[Tamás Gulácsi]

You should benchmark, but md5 is not cpu hungry at all, so the disk read speed 
will dominate. That means 2*runtime.NumCPU disk-reading goroutines is a good 
rule of thumb.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Syscall trouble with parameter handling

[snmed]

okay it says "E_INVALIDARGOne or more arguments are not valid
0x80070057", but what i am doing wrong with the parameters?




Am Dienstag, 21. Februar 2017 12:01:47 UTC+1 schrieb snmed:
>
> Ohh strange i missed that, i thought it's S_OK  because the error stated 
> "The operation completed successfully". So i need to find out why it is 
> failling, do you have any idea about the reason?
>
> Cheers
> snmed 
>
> Am Dienstag, 21. Februar 2017 11:16:08 UTC+1 schrieb brainman:
>>
>> According to the doco 
>> https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862(v=vs.85).aspx
>> ```
>> Return value
>> If this function succeeds, it returns S_OK. Otherwise, it returns an 
>> HRESULT error code.
>> ```
>>
>> Your call returns 2147942487, and it is not S_OK. It must be the error 
>> code. You need to find out what that error means. 
>>
>> Alex
>>
>> PS: You should ignore r2 and err returned from ainit.Call. r2 is never 
>> set on windows, and err will contain value of 
>> GetLastError at the time when ainit.Call completes. But (accordng to the 
>> doco) AmsiInitialize does not set GetLastError value.
>>
>

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

[go-nuts] Re: Syscall trouble with parameter handling

[snmed]

Ohh strange i missed that, i thought it's S_OK  because the error stated 
"The operation completed successfully". So i need to find out why it is 
failling, do you have any idea about the reason?

Cheers
snmed 

Am Dienstag, 21. Februar 2017 11:16:08 UTC+1 schrieb brainman:
>
> According to the doco 
> https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862(v=vs.85).aspx
> ```
> Return value
> If this function succeeds, it returns S_OK. Otherwise, it returns an 
> HRESULT error code.
> ```
>
> Your call returns 2147942487, and it is not S_OK. It must be the error 
> code. You need to find out what that error means. 
>
> Alex
>
> PS: You should ignore r2 and err returned from ainit.Call. r2 is never set 
> on windows, and err will contain value of 
> GetLastError at the time when ainit.Call completes. But (accordng to the 
> doco) AmsiInitialize does not set GetLastError value.
>

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

Re: go test -race much slower in 1.8 (was Re: [go-nuts] Go 1.8 is released)

[Will Newton]

On Mon, Feb 20, 2017 at 8:23 PM, Ian Lance Taylor  wrote:
> On Mon, Feb 20, 2017 at 12:06 PM, Will Newton  wrote:
>> On Thu, Feb 16, 2017 at 9:01 PM, Chris Broadfoot  wrote:
>>> Hello gophers,
>>>
>>> We just released Go 1.8.
>>>
>>> You can read the announcement blog post here:
>>>   https://blog.golang.org/go1.8
>>>
>>> You can download binary and source distributions from our download page:
>>>   https://golang.org/dl/
>>>
>>> To compile from source using a Git checkout, update to the release with "git
>>> checkout go1.8" and build as usual.
>>>
>>> To find out what has changed, read the release notes:
>>>   https://golang.org/doc/go1.8
>>>
>>> Thanks to everyone who contributed to the release.
>>
>> After upgrading to Go 1.8 from Go 1.7 our testsuite runtime has gone
>> up from ~4 minutes to ~20 minutes. We run it with "go test -race
>> -covermode=atomic -coverprofile=coverage.tmp" and it seems like one or
>> other of coverage or race detector is implicated. Is anything like
>> this expected?
>
> This could possibly be related to https://golang.org/issue/19133
> and/or https://golang.org/issue/19151.

Thanks, this looks like it could be it. Is there a suggested
workaround beyond running my testsuite without coverage/race detector?

Also it looks like the plan is to fix this in Go 1.9 rather than
1.8.x, is that the case?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 UDP performance

[Marcus Franke]

Hi,
an additional note, don't forget to monitor the netstat udp counter on both
servers.

% netstat -auns | grep -A 7 "Udp:"
Udp:
9381 packets received
0 packets to unknown port received
0 packet receive errors
1009 packets sent
0 receive buffer errors
0 send buffer errors
IgnoredMulti: 1264

Maybe your client is dropping the packets and it is not your sender.



Rich  schrieb am Di., 21. Feb. 2017 um 03:16 Uhr:

> I would wireshark the data coming in to both sides so that you can see
> when the packet was transmitted, and when it was received by the other
> side. That way you can isolate if it's network or Go.
>
>
> On Monday, February 20, 2017 at 4:02:28 PM UTC-5, Tharaneedharan
> Vilwanathan wrote:
>
> Hi All,
>
> I am trying to send a lot of UDP packets from Go code but I realized UDP
> performance is too low. The max I was able to do is about 160Mbps. This is
> in Ubuntu 16.10 on x86_64 (i7-6700HQ).
>
> I tried to google on this and it looks like this is about the performance
> we can get. I am a bit surprised.
>
> Am I missing something? Any suggestions on how to improve the performance?
>
> Thanks
> dharani
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: Syscall trouble with parameter handling

[brainman]

According to the doco 
https://msdn.microsoft.com/en-us/library/windows/desktop/dn889862(v=vs.85).aspx
```
Return value
If this function succeeds, it returns S_OK. Otherwise, it returns an 
HRESULT error code.
```

Your call returns 2147942487, and it is not S_OK. It must be the error 
code. You need to find out what that error means. 

Alex

PS: You should ignore r2 and err returned from ainit.Call. r2 is never set 
on windows, and err will contain value of 
GetLastError at the time when ainit.Call completes. But (accordng to the 
doco) AmsiInitialize does not set GetLastError value.

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

Re: [go-nuts] Initializing nested struct, by dynamically forming struct member path

[Nathan Kerr]

Could you give an example of the json you are starting from?

Also, what database are you using?

On Sunday, February 19, 2017 at 8:27:32 AM UTC+1, Bharath B wrote:
>
> Hi,
>
> I am trying to read those values and store in DB.
>
> Regards,
> Bharath B
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] History: Does the _ (Blank identifier) trace its history back to VI's or something earlier?

[Konstantin Khomoutov]

On Tue, 21 Feb 2017 01:16:08 -0800 (PST)
"'pfitzsimons' via golang-nuts"  wrote:

> The _ is used as the https://golang.org/ref/spec#Blank_identifier to
> ignore right-hand side values in an assignment 
> (https://golang.org/ref/spec#Assignments)
> 
> In VI(M) _ is used as a black hole register 
> http://vimdoc.sourceforge.net/htmldoc/change.html#registers when you
> want to delete clipboard text
> 
> Does the _ (blank identifier) in golang trace back to VI(M) _ (black
> hole register) or was _ used before this to discard text?

I think for the case of Vim's blackhole register, this is a coinsidence.
Instead, _ is probably taken from many functional languages where it's
used in so-called pattern matching [1] and stands to mean "discard
the matching value on the right hand-side" of the expression.

By the way, in many (most?) POSIX shells, the $_ variable means the
last positional argument of the last command executed.

And Perl (sort of obviously ;-)) has it, too.

1. https://en.wikipedia.org/wiki/Pattern_matching

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Syscall trouble with parameter handling

[snmed]

Hi all

I try to use the syscall package to call a native Windows API and 
struggling with the call parameters. I calling the api

HRESULT WINAPI AmsiInitialize(
  _In_  LPCWSTR  appName,
  _In_  DWORDcoInit,
  _Out_ HAMSICONTEXT *amsiContext
);


my test app looks like this
package main

import (
"fmt"

"syscall"
"unsafe"

"golang.org/x/sys/windows"
)

func main() {
h := windows.MustLoadDLL("Amsi.dll")
defer h.Release()

ainit := h.MustFindProc("AmsiInitialize")
auinit := h.MustFindProc("AmsiUninitialize")
ascanstring := h.MustFindProc("AmsiScanString")

var context uintptr
r1, r2, err := ainit.Call(uintptr(unsafe.Pointer(syscall.
StringToUTF16Ptr("Scanner Tool"))), 0, uintptr(unsafe.Pointer()))
fmt.Println(context)
fmt.Println(r1, r2, err)
// output:
// 0
// 2147942487 0 The operation completed successfully.

unfortunately the call succeeds but the context is still zero. Probably i 
call the function with the wrong parameters but i can't work it out.
Has anybody a idea what could be wrong?

Thank you in advance
snmed

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Import path search order?

[Nathan Kerr]

Relative package don't need to be searched for, they are explicit 
(indicated with ./ or ../)

Then it seems to be:

1. vendor tree, if it exists
2. GOROOT
3. GOPATH, from left to right

Trying to build a package with an import that cannot be found will display 
an error listing all the locations it looked for the package. To get the 
vendor tree listed, a vendor directory must exist in the package you are 
trying to build.


On Tuesday, February 21, 2017 at 3:01:59 AM UTC+1, so.q...@gmail.com wrote:
>
> What is the search order for the import path?
> for example, relative then vendor then workspace?
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] History: Does the _ (Blank identifier) trace its history back to VI's or something earlier?

['pfitzsimons' via golang-nuts]

The _ is used as the https://golang.org/ref/spec#Blank_identifier to ignore 
right-hand side values in an assignment 
(https://golang.org/ref/spec#Assignments)

In VI(M) _ is used as a black hole register 
http://vimdoc.sourceforge.net/htmldoc/change.html#registers when you want 
to delete clipboard text

Does the _ (blank identifier) in golang trace back to VI(M) _ (black hole 
register) or was _ used before this to discard text?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

I am sorry I forgot to mention that I have built go1.8 instead of go-1.7, 
this thread subject says go-1.7


On Tuesday, February 21, 2017 at 2:20:16 PM UTC+5:30, Srikanth Chandika 
wrote:
>
> Thanks for the valuable information.
>
> Go fully built.
> I ran ./all.bash repeatedly for 5 to 6 times somehow all tests are 
> successfully completed.
>
> And my requirement fulfilled.
>
> On Tuesday, February 21, 2017 at 12:39:35 PM UTC+5:30, Dave Cheney wrote:
>>
>> It looks like one test in the os/exec package failed during the tests 
>> which are run during ./all.bash
>>
>> --- FAIL: TestStdinCloseRace (0.04s)
>> exec_test.go:267: Kill: os: process already finished
>> FAIL
>> FAILos/exec 0.371s
>>
>> At this point Go is fully built, so you may wish to ignore this error, 
>> however it would be good if you would raise a bug report, 
>> https://golang.org/issue/new.
>>
>> Thanks
>>
>> Dave
>>
>> On Tuesday, 21 February 2017 17:33:56 UTC+11, Srikanth Chandika wrote:
>>>
>>> I tried installing go1.8 from source(
>>> https://golang.org/doc/install/source) but I am getting error saying 
>>> that "2017/02/21 17:05:18 Failed: exit status 1"
>>>
>>> Attached a file(output of ./all.bash)
>>>
>>>
>>> On Tuesday, February 21, 2017 at 1:13:53 AM UTC+5:30, Ian Lance Taylor 
>>> wrote:

 On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika 
  wrote: 
 > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9. 

 It's no different from building Go from source on any other system. 

 https://golang.org/doc/install/source 

 Note that the current release is now 1.8, but the procedure hasn't 
 changed since 1.7. 

 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 Build and Install Go 1.7.4 in OpenBSD 5.9

[Srikanth Chandika]

Thanks for the valuable information.

Go fully built.
I ran ./all.bash repeatedly for 5 to 6 times somehow all tests are 
successfully completed.

And my requirement fulfilled.

On Tuesday, February 21, 2017 at 12:39:35 PM UTC+5:30, Dave Cheney wrote:
>
> It looks like one test in the os/exec package failed during the tests 
> which are run during ./all.bash
>
> --- FAIL: TestStdinCloseRace (0.04s)
> exec_test.go:267: Kill: os: process already finished
> FAIL
> FAILos/exec 0.371s
>
> At this point Go is fully built, so you may wish to ignore this error, 
> however it would be good if you would raise a bug report, 
> https://golang.org/issue/new.
>
> Thanks
>
> Dave
>
> On Tuesday, 21 February 2017 17:33:56 UTC+11, Srikanth Chandika wrote:
>>
>> I tried installing go1.8 from source(
>> https://golang.org/doc/install/source) but I am getting error saying 
>> that "2017/02/21 17:05:18 Failed: exit status 1"
>>
>> Attached a file(output of ./all.bash)
>>
>>
>> On Tuesday, February 21, 2017 at 1:13:53 AM UTC+5:30, Ian Lance Taylor 
>> wrote:
>>>
>>> On Mon, Feb 20, 2017 at 2:55 AM, Srikanth Chandika 
>>>  wrote: 
>>> > How to Build and Install Go 1.7 from go src code in OpenBSD 5.9. 
>>>
>>> It's no different from building Go from source on any other system. 
>>>
>>> https://golang.org/doc/install/source 
>>>
>>> Note that the current release is now 1.8, but the procedure hasn't 
>>> changed since 1.7. 
>>>
>>> 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] Does Go spec assure that a substring shares the underlying bytes with the original string?

['Axel Wagner' via golang-nuts]

On Tue, Feb 21, 2017 at 9:30 AM, T L  wrote:

>
>
> On Tuesday, February 21, 2017 at 1:30:24 AM UTC+8, Ian Lance Taylor wrote:
>>
>> On Mon, Feb 20, 2017 at 9:12 AM, T L  wrote:
>> >
>> > I know gc assures this, but I don't know if it is compiler specified or
>> a
>> > spec rule.
>>
>> I can't think of any way that a Go program that does not unsafe could
>> detect whether a string slice uses the same memory as the string being
>> sliced.  Also, I can easily imagine that in some cases it would be
>> desirable to make a copy, as when writing s[i:i+1] when len(s) > 4096
>> and there are no other references to s.  So I don't think this should
>> be written down in the spec.  I think Go programs should trust that
>> the implementation will make the right choice, which will of course be
>> to normally not copy the string.
>>
>> Ian
>>
>
> My intention is to make sure s[a:b] will always share the underlying bytes
> with s,
>

Quoting the spec:

If the sliced operand of a valid slice expression is a nil slice, the
result is a nil slice. Otherwise, the result shares its underlying array
with the operand.


> otherwise strings.Index(s[fromIndex:], sep) would be inefficient if
> s[fromIndex:] doesn't share the underlying bytes with s.
>

Ian's point was: You should assume that it's efficient whether or not it
actually shares memory. If that assumption turns out to be false, you can
always file a bug against that particular implementation.


> I know gc can assure this. My concern is whether or not other compilers
> can assure this too if the spec doesn't cover this.
> And I think if the spec doesn't cover this, a new strings.IndexFrom
> function should be added to the standard lib.
>

If you are really, really convinced, that you need this (but you don't. You
are worrying about theoretical concerns that are incredibly unlikely to be
relevant in practice), just write it yourself. Copy the code from the
stdlib and adjust it to your needs.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Does Go spec assure that a substring shares the underlying bytes with the original string?

[T L]

On Tuesday, February 21, 2017 at 1:30:24 AM UTC+8, Ian Lance Taylor wrote:
>
> On Mon, Feb 20, 2017 at 9:12 AM, T L  
> wrote: 
> > 
> > I know gc assures this, but I don't know if it is compiler specified or 
> a 
> > spec rule. 
>
> I can't think of any way that a Go program that does not unsafe could 
> detect whether a string slice uses the same memory as the string being 
> sliced.  Also, I can easily imagine that in some cases it would be 
> desirable to make a copy, as when writing s[i:i+1] when len(s) > 4096 
> and there are no other references to s.  So I don't think this should 
> be written down in the spec.  I think Go programs should trust that 
> the implementation will make the right choice, which will of course be 
> to normally not copy the string. 
>
> Ian 
>

My intention is to make sure s[a:b] will always share the underlying bytes 
with s,
otherwise strings.Index(s[fromIndex:], sep) would be inefficient if 
s[fromIndex:] doesn't share the underlying bytes with s.
I know gc can assure this. My concern is whether or not other compilers can 
assure this too if the spec doesn't cover this.
And I think if the spec doesn't cover this, a new strings.IndexFrom 
function should be added to the standard lib.



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: unexpected end of JSON input while unmarshal to struct

[Nathan Kerr]

I figured it out.

First off, the posted playground had a different json string and did not 
use your UnmarshalJSON function. These made translating between the 
non-working setup described in your post and the working playground 
annoying. In the future, share the non-working setup.

At the point when I figured things out, my code was: 
https://play.golang.org/p/aMvz_JTrjD. This won't run on playground because 
it uses github.com/pkg/errors to add context to the errors so I could see 
which error was returned along with a much needed stack trace.

I found two problems with the implementation of UnmarshalJSON:

1. tmp["response_data"] and tmp2["order"] return zero values when the key 
is not found. This happened, first, because of the difference between the 
posted json and the json in the posted playground. Second, because of the 
second problem.

2. json.Unmarshal uses a type's UnmarshalJSON function if it exists to do 
the unmarshalling. This created a loop where *LimitOrder.UnmarshalJSON 
calls json.Unmarshal, which calls *LimitOrder.UnmarshalJSON, and so on. 
Line 71 prints out the call stack for the returned error that confirms this.

My recommended way of doing things is https://play.golang.org/p/kRKevuX8LW, 
that is write out the structs you need. This will also allow you to check 
the status_code from the response. If your LimitOrder will outlive the 
response then change ResponseData.LimitOrder to be a pointer.

Hope this helps.

On Tuesday, February 21, 2017 at 6:25:10 AM UTC+1, Diogo Ribeiro wrote:
>
> Could you help me to understand why I'm always getting the error unexpected 
> end of JSON input while trying to unmarshal the following json to the 
> LimitOrder struct? It works if I use golang playground 
> https://play.golang.org/p/udPQ_TayXG but not locally running tests.
>
>
> P.S.: if I use map[string]json.RawMessage instead of LimitOrder struct 
> I'm able to execute the unmarshal.
>
>
> {
>   "response_data": {
> "order": {
>   "order_id": 3,
>   "coin_pair": "BRLBTC",
>   "order_type": 1,
>   "status": 4,
>   "has_fills": true,
>   "quantity": "1.",
>   "limit_price": "900.0",
>   "executed_quantity": "1.",
>   "executed_price_avg": "900.0",
>   "fee": "0.0030",
>   "created_timestamp": "1453835329",
>   "updated_timestamp": "1453835329",
>   "operations": [
> {
>   "operation_id": 1,
>   "quantity": "1.",
>   "price": "900.0",
>   "fee_rate": "0.30",
>   "executed_timestamp": "1453835329"
> }
>   ]
> }
>   },
>   "status_code": 100,
>   "server_unix_timestamp": "1453835329"}
>
> *LimitOrder struct*
>
>
> type LimitOrder struct {
>   OrderId int `json:"order_id"`
>   CoinPair string `json:"coin_pair"`
>   OrderType int `json:"order_type"`
>   Status int `json:"status"`
>   HasFills bool `json:"has_fills"`
>   Quantity float64 `json:"quantity,string"`
>   LimitPrice float64 `json:"limit_price,string"`
>   ExecutedQuantity float64 `json:"executed_quantity,string"`
>   ExecutedPriceAvg float64 `json:"executed_price_avg,string"`
>   Fee float64 `json:"fee,string"`
>   Operations []*Operation `json:"operations"`
>   CreatedTimestamp string `json:"created_timestamp"`
>   UpdatedTimestamp string `json:"updated_timestamp"`}
>
>
> and this is how I'm trying to unmarshal it
>
>
> func (limitOrder *LimitOrder) UnmarshalJSON(buf []byte) error {
>
>   tmp := make(map[string]json.RawMessage)
>   if err := json.Unmarshal(buf, ); err != nil {
> return err
>   }
>
>   tmp2 := make(map[string]json.RawMessage)
>
>   if err := json.Unmarshal(tmp["response_data"], ); err != nil {
> return err
>   }
>
>   if err := json.Unmarshal(tmp2["order"], limitOrder); err != nil {
> return err
>   }
>
>   return nil}
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: ActiveState seeking Go community feedback

[Konstantin Khomoutov]

On Mon, 20 Feb 2017 12:50:32 -0800 (PST)
Kevin Powick  wrote:

[...]
> I'm not really up on Activestate's involvement with Go, but have they 
> contributed to the development or promotion of Go in any significant
> way?

I'm not up with their involvement in Go as well, but I know about their
involvement with Tcl¹.  Two of that team, Jeff Hobbs and Andreas Kupries
are full-time developers there who are highly-skilled experts
contributing to Tcl's core and stdlib.  I'm not sure AS currently
employs anyone for Go as they do for Tcl, but they've just started
anyway.  I mean, it's too early to make judgements.

FWIW, I'm not affiliated with AS in any way; just was participating in
the development of a cross-platform software based on Tcl/Tk.

¹ They do have a "batteries-included" distro of Tcl/Tk for various
  OSes named «Active Tcl»; with this distro for Windows being arguably
  the best there is for Tcl/Tk development on that platform.

  Their «Active Perl» solution for Windows IMO was also the best among
  the available options back then when I needed one.

  And they also have something alike for Python but I had no chance of
  evaluating it personally.

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