[go-nuts] Re: Oden Language 0.3.0 released

[Tyler Compton]

I believe it does, thank you. If I understand you correctly, Oden is to the 
Go community a bit like what Scala is to the Java/JVM community.

On Sunday, June 12, 2016 at 3:17:15 PM UTC-7, Oskar Wickström wrote:
>
> Glad you like it! :)
>
> The latter suggestion fits the goals of Oden better. It is focused on 
> being the language you write your application in, while making it easy to 
> use stuff from Go. Using Oden code from Go is not directly supported, but 
> might be practically possible anyway. I hope that answers your question 
> well, otherwise I'll try another way. :)
>
> Den torsdag 26 maj 2016 kl. 00:47:03 UTC+2 skrev Tyler Compton:
>>
>> The language looks interested and I love the Oden mascot!
>>
>> I'm not sure if I understand the goal, though. Is this supposed to be a 
>> language used alongside Go code for parts of the application that are 
>> better or easier expressed using Oden (kind of like when using Lua in a C 
>> code base) , or is it supposed to be a language to write your entire 
>> project in instead of Go (that happens to leverage Go under the covers)?
>>
>> On Saturday, May 14, 2016 at 8:59:15 PM UTC-7, Oskar Wickström wrote:
>>>
>>> Hi! I just released Oden 0.3.0, an experimental functional programming 
>>> language for the Go ecosystem, which now features both parametric 
>>> polymorphism and experimental support for ad hoc polymorphism (basically 
>>> like Haskell type classes). For more info see 
>>> https://oden-lang.org/blog/news/2016/05/14/0.3.0-is-out.html. I'll try 
>>> to get more documentation up this week. 
>>>
>>> Have a nice weekend!
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] A question about passing arguments to closure

[Henry]

In "go func(int) { fmt.Println(i)}(i)", 'i' is passed as an argument, but 
it is not used. 'fmt.Println(i)' uses the variable 'i' that is 
inherited from the parent function, because 'i' is not defined by the 
function func(int) as an argument and the next available 'i' is the one 
inherited from the parent function. 

I think it is safer that all arguments must be explicitly passed to an 
anonymous function. No automatic variable copying from the parent function. 
This is to prevent accidental error. Perhaps Go's language designers may 
consider this suggestion?

On Monday, June 13, 2016 at 12:29:56 PM UTC+7, Nan Xiao wrote:

> Hi Shawn,
>
> Thanks for yor answer!
>
> Another question, considering "go func(int) { fmt.Println(i)}(i)", the 
> closure should accept an int argument but actually nothing is passed. Why 
> does Go compiler allow this? 
>
> Best Regards
> Nan Xiao
>
> On Mon, Jun 13, 2016 at 12:54 PM, Shawn Milochik  > wrote:
>
>> On Sun, Jun 12, 2016 at 11:39 PM, Nan Xiao > > wrote:
>>
>>> Hi Shawn,
>>>
>>> Thanks for your reply!
>>>
>>> I can figure out the cause of what I have seen, but I want to know 
>>> whether there are detailed rules about processing parameters of closure.
>>>
>>> Best Regards
>>> Nan Xiao
>>>
>>> Nan,
>>
>> If you pass in a value to the anonymous function, it will have its own 
>> variable -- even if you give it the same name as the one in the function 
>> that called it. This is why the value you pass is correct, and the one you 
>> "inherit" is not.
>>
>> If you do not pass it in, and refer to a variable from the enclosing 
>> function inside the anonymous function, all goroutines (including the 
>> enclosing function) share a single variable. So, it can be modified by any 
>> of the goroutines.
>>
>> See the fourth paragraph here (beginning with "For instance"): 
>> https://golang.org/ref/spec#Defer_statements
>>
>> Also, see here (search for "the bug is"): 
>> https://golang.org/doc/effective_go.html
>>
>>
>>
>>
>>
>> -- 
>> 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/JXTEYyoPLio/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to 
>> golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

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

Re: [go-nuts] goxpath: An XPath 1.0 parser

[Henrik Johansson]

How does it compare to https://godoc.org/launchpad.net/xmlpath?
I have been using it with great satisfaction but it is not complete to my
knowledge xpath feature wise.


mån 13 juni 2016 kl 01:48 skrev Chris Trenkamp :

> https://github.com/ChrisTrenkamp/goxpath
>
> I've created an XPath 1.0 parser.  The only thing missing is the id()
> function for complicated reasons.  It also comes with a command-line
> utility that works like xmlstarlet, except it only has XPath queries.
>
> Looking for feedback.  Let me know if you find this useful.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: [ANN] primegen.go: Sieve of Atkin prime number generator

[alb . donizetti]

> Current versions of golang are not as fast as GCC C/C++ optimized code by 
at least a factor of two

This is, in general, not true at all: I've written numeric code as fast as 
C code compiled by GCC -O3

Il giorno martedì 14 giugno 2016 14:31:18 UTC+2, gordo...@gmail.com ha 
scritto:
>
> That's interesting but your time or 0.7 seconds on your specified machine 
> isn't very informative: you should at least specify how long the original 
> version of primegen (which is not multithreaded) takes, which we assume as 
> about 0.7 seconds, and also how long your golang version takes without 
> multithreading (or set "maxprocs := 1")  Also, one should really convert 
> Bernstein's "eratspeed" to golang for comparison. 
>
> Current versions of golang are not as fast as GCC C/C++ optimized code by 
> at least a factor of two, and you will find that if one applies maximum 
> wheel factorization (ie a 2/3/5/7 wheel plus pre-culling for primes of 
> 11/13/17/19), rather than the limited 2/3/5 wheel factorization Bernstein 
> used in eratspeed, that the Sieve of Eratosthenes will beat "primegen" for 
> every range when comparing like for like (multithreading or not for both, 
> written in the same language), and that golang will currently always be a 
> factor slower than the C/C++ code due to less efficient compilation.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Is it possible to upload golang application to Mac App store?

[liudan king]

I developed an application that displays a icon in status bar to show 
network speed.
I have packaged it to a standard mac app package (ns.app and ns.dmg) using 
command *codesign* and *appdmg.*
The problem is that, when I try to upload it to app store using Application 
Loader, the loader can't recognise file ns.app or ns.dmg.
What have I missed? Or am I on the wrong way?

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

[Vasily Korytov]

jsonmon is a simple but powerful monitoring and alerting system. It has 
only two types of checks: shell and Web. More details at 
https://github.com/chillum/jsonmon/wiki

Today the version 2.0.11 is released, it is a bug fix for the previous 
optimization release.

Versions prior to 2.0.9 were prone to data races, I highly recommend 
switching to 2.0.11 or 2.0.9 from all previous versions.

Thanks.

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

[go-nuts] Re: Save to store encryption key in Go executable?

[Evan Digby]

Unfortunately there's a reason why password managers still require a 
passphrase. It's simply not secure to store the key anywhere near the 
secure files. 

I'm not saying password managers are perfect--they have their own security 
issues--but it seems that you're attempting to closely mimic that 
functionality (except for data instead of passwords) while removing the 
requirement for a passphrase. I would investigate the security model of 
some well respected password managers as a foundation to give you some 
insight/inspiration. 

I like the idea of storing your key on a flash drive--it seems to be the 
best suggestion here so far, but honestly that probably won't be much more 
secure than simply writing your passphrase down and keeping it in your 
wallet. 

Trusting a device or piece of paper also has a steep downside: it can be 
lost just as easily as your memory--maybe more easily. Depending on a 
device and then losing it is just as devastating as forgetting the 
passphrase so this doesn't really meet your requirements given the 
inspiration behind this project. 

Storing your password somewhere in the cloud as a backup can be a form of 
poor mans two-factor authentication/password recovery. You can try to 
remember the passphrase (or not lose the device/paper), or you can remember 
your account details for the backup. Gives you two shots at recovery (three 
if the cloud service has a password recovery option). 

Please note, however, that the more places you put the passphrase the less 
secure it is, but it sounds like you need "good" encryption with a near 
zero percent chance of losing the encrypted data, as opposed to "great" 
encryption with a high chance of losing the encrypted data. The more secure 
you need it, the closer you approach needing a brain-memory only long 
passphrase that is (for some) easily forgotten but impossible to extract 
digitally.

Back to your implementation, I agree with the advice that it's best to keep 
the passphrase/key separate from the binary. I would start by investigating 
"non-lose-able" (technical term :P) and reasonably secure methods of 
storing that passphrase separate from the binary (and even the system that 
stores the data) as a priority over the encryption software itself. See how 
that works with existing encryption solutions, and then make the encryption 
"phase 2" of your project. 









On Monday, 13 June 2016 23:57:35 UTC-7, as@gmail.com wrote:
>
> You're right, even if you aren't planning to share the program, it's still 
> a good idea to separate the key from the executable. For one, the 
> executable is bigger and harder to keep secret than a few bytes of data. 
> It's generally frowned upon to bundle the two since the secrecy should rely 
> solely on the key.
>
> If you don't like passwords, you can store the key on a flash drive as a 
> file or even write it directly to the underlying block device.
>
> On Monday, June 13, 2016 at 10:12:25 PM UTC-7, Haddock wrote:
>>
>> Thanks for all the useful answers. All I want to do is to create an 
>> encryption program for simple home computing purposes. I once lost some 
>> encrypted files, because I lost the password. I think I did a typo when 
>> typing it in and didn't realize. So I thought I write my own encryption 
>> programm with a catch-all password in it. That might be a very bad idea now 
>> ... 
>>
>> I first wanted to use Java as I'm used to it. But Java code cannot be 
>> encrypted to hide the encryption key, because the Java byte codes would 
>> then become unreadable for the JVM. So I thought of something else. I 
>> thought of moving the key to some server. But then I would be dependent on 
>> some server and the Internet being reachable in order to decrypt my things 
>> (password files, etc.). 
>>
>> Seems like the best solution would be to store the key in a separate 
>> file, though I don't understand exactly how this makes things better. 
>> Having the key in a separate file means that the decrypted blank key is 
>> only visible from within the running encryption programm for a very short 
>> moment. Is that the idea? Maybe have a solution that first looks for a 
>> local key file and only checks some server for it when locally not present.
>>
>> Regards, Haddock
>>
>> Am Montag, 13. Juni 2016 18:01:48 UTC+2 schrieb Haddock:
>>>
>>> Hello,
>>>
>>> I'm developing my own little encryption application in Go. The Go 
>>> application needs to know the key used for encryption and decryption. My 
>>> question is whether that key can be extracted from the Go executable 
>>> somehow through disassembly or looking at the applications memory or 
>>> something. I'm a complete Go beginner and know nothing about its memory 
>>> layout. So that's why I thought it's better to ask. 
>>>
>>> Thanks, Haddock
>>>
>>

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

[go-nuts] How to properly get basename under DOS?

[Tong Sun]

I thought to get basename, we should use the official *path.Base* 
-- https://golang.org/pkg/path/#Base

However, I just found out that it is *not working under DOS* 
-- https://play.golang.org/p/kfr0N50JWc

package main


import (
 "fmt"
 "path"
)


func main() {
 fmt.Println(path.Base("/a/b.c"))
 fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio 
9\Common7\IDE\devenv.exe`))
}


The output is:

b.c
C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe


What's your solution for this, that is working for both Linux and Windows? 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 properly get basename under DOS?

[Jan Mercl]

Package path is for *nix paths only. import "path/filepath" instead.

On Tue, Jun 14, 2016, 18:55 Tong Sun  wrote:

> I thought to get basename, we should use the official *path.Base* --
> https://golang.org/pkg/path/#Base
>
> However, I just found out that it is *not working under DOS* --
> https://play.golang.org/p/kfr0N50JWc
>
> package main
>
>
> import (
>  "fmt"
>  "path"
> )
>
>
> func main() {
>  fmt.Println(path.Base("/a/b.c"))
>  fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio
> 9\Common7\IDE\devenv.exe`))
> }
>
>
> The output is:
>
> b.c
> C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe
>
>
> What's your solution for this, that is working for both Linux and Windows?
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
-- 

-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] Bitmasks on signed types

[Rob Pike]

Please read blog.golang.org/constants.

-rob


On Tue, Jun 14, 2016 at 10:47 AM, Jan Mercl <0xj...@gmail.com> wrote:

> The untyped integer constant 0x represents a positive number not
> representable by any int32 value.
>
>
> On Tue, Jun 14, 2016, 19:45 Dave MacFarlane  wrote:
>
>> What I'm not understanding is why that's not the case in this example.
>> It's a 32 bit bitwise operation on a 32 bit signed type.  Shouldn't
>> 0x be coerced to a value of -1?
>>
>> On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com> wrote:
>>
>>> All binary operators, except shifts, require identical left and right
>>> types. Untyped values will be coerced to the type of the other side, if
>>> representable as such after the conversion. That's not the case in this
>>> example.
>>>
>>> On Tue, Jun 14, 2016, 19:16 Dave MacFarlane  wrote:
>>>
 Is this supposed to be legal in Go:

 var x int32 = 3

 fmt.Printf("%d", x & 0x)?

 The language spec just says the bitwise operator "applies to integers
 only" and
 "yields a result of the same type as the first operand" that I can see,
 but it's giving
 me a compiler error:

 ./main.go:10: constant 4294967295 overflows int32

 with go 1.6.2.

 Is this a compiler bug, or am I missing something else in the spec that
 makes it impossible
 to mask out the high bit in a signed integer type without converting to
 an unsigned equivalent first?

 - Dave

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

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

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

[go-nuts] Re: Loading X509 Key Pair with invalid Certificate

[Chris Johnson]

Figured this out and wanted to reply in case anyone else hits it. 
Apparently the latest Ubuntu images on DockerHub (14.04.04) do not have the 
latest cert files baked into them.

https://github.com/docker/docker/issues/5157


I just added the following to the Dockerfile that builds this container:

apt-get install --reinstall ca-certificates ca-certificates-java


On Monday, June 13, 2016 at 12:01:39 PM UTC-4, jo...@koho.ca wrote:
>
> Hello,
>
> We have been issued a client certificate that will not load 
> (tls.LoadX509KeyPair) as it contains an identifier with an "_" in it - the 
> underscore is not valid in the ASN.1 spec 
> , although openssl and many 
> other language implementations appear to accept it anyway.
>

> The Go language authors discussed 
>  loosening the implementation, 
> but it didn't go anywhere.
>
> I'm hoping that the certificate can be reissued without the underscore, 
> but in the case that it can't be, I'm investigating other options and 
> really hoping for something besides having to fork and modify crypto/tls, 
> crypto/x509 and encoding/asn1.
>
> Thanks in advance.
>
> Joel
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 properly get basename under DOS?

[Tong Sun]

Like this? -- https://play.golang.org/p/jhK-vmmmdH

package main


import (
 "fmt"
 "path/filepath"
)


func main() {
 fmt.Println(filepath.Base("/a/b.c"))
 fmt.Println(filepath.Base(`C:\Program Files\Microsoft Visual Studio 
9\Common7\IDE\devenv.exe`))
}


The output is still exactly the same as before. 


On Tuesday, June 14, 2016 at 1:01:18 PM UTC-4, Jan Mercl wrote:
>
> Package path is for *nix paths only. import "path/filepath" instead.
>
> On Tue, Jun 14, 2016, 18:55 Tong Sun  
> wrote:
>
>> I thought to get basename, we should use the official *path.Base* -- 
>> https://golang.org/pkg/path/#Base
>>
>> However, I just found out that it is *not working under DOS* -- 
>> https://play.golang.org/p/kfr0N50JWc
>>
>> package main
>>
>>
>> import (
>>  "fmt"
>>  "path"
>> )
>>
>>
>> func main() {
>>  fmt.Println(path.Base("/a/b.c"))
>>  fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio 
>> 9\Common7\IDE\devenv.exe`))
>> }
>>
>>
>> The output is:
>>
>> b.c
>> C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe
>>
>>
>> What's your solution for this, that is working for both Linux and 
>> Windows? 
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
> -- 
>
> -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] How to properly get basename under DOS?

[John Souvestre]

> Package path is for *nix paths only. import "path/filepath" instead.

When should path be used?  Or should it be deprecated in favor of path/filepath?

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Jan Mercl
Sent: 2016 June 14, Tue 12:01
To: Tong Sun; golang-nuts
Subject: Re: [go-nuts] How to properly get basename under DOS?

 

Package path is for *nix paths only. import "path/filepath" instead.

 

On Tue, Jun 14, 2016, 18:55 Tong Sun  wrote:

I thought to get basename, we should use the official path.Base -- 
https://golang.org/pkg/path/#Base

 

However, I just found out that it is not working under DOS -- 
https://play.golang.org/p/kfr0N50JWc

 

package main


import (
 "fmt"
 "path"
)


func main() {
 fmt.Println(path.Base("/a/b.c"))
 fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio 
9\Common7\IDE\devenv.exe`))
}

 

The output is:

 

b.c
C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe

 

What's your solution for this, that is working for both Linux and Windows? 

 

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

-- 

-j

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

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

Re: [go-nuts] How to properly get basename under DOS?

[Ian Lance Taylor]

On Tue, Jun 14, 2016 at 10:00 AM, Jan Mercl <0xj...@gmail.com> wrote:
> Package path is for *nix paths only. import "path/filepath" instead.

I agree that path/filepath is what you want, but I would say it
slightly differently.  path is for what you find inside URLs,
path/filepath is for paths in the file system on both Unix and
Windows.

Ian

> On Tue, Jun 14, 2016, 18:55 Tong Sun  wrote:
>>
>> I thought to get basename, we should use the official path.Base --
>> https://golang.org/pkg/path/#Base
>>
>> However, I just found out that it is not working under DOS --
>> https://play.golang.org/p/kfr0N50JWc
>>
>> package main
>>
>>
>> import (
>>  "fmt"
>>  "path"
>> )
>>
>>
>> func main() {
>>  fmt.Println(path.Base("/a/b.c"))
>>  fmt.Println(path.Base(`C:\Program Files\Microsoft Visual Studio
>> 9\Common7\IDE\devenv.exe`))
>> }
>>
>>
>> The output is:
>>
>> b.c
>> C:\Program Files\Microsoft Visual Studio 9\Common7\IDE\devenv.exe
>>
>>
>> What's your solution for this, that is working for both Linux and Windows?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
>
> -j
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

[go-nuts] Bitmasks on signed types

[Dave MacFarlane]

Is this supposed to be legal in Go:

var x int32 = 3

fmt.Printf("%d", x & 0x)?

The language spec just says the bitwise operator "applies to integers only"
and
"yields a result of the same type as the first operand" that I can see, but
it's giving
me a compiler error:

./main.go:10: constant 4294967295 overflows int32

with go 1.6.2.

Is this a compiler bug, or am I missing something else in the spec that
makes it impossible
to mask out the high bit in a signed integer type without converting to an
unsigned equivalent first?

- Dave

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

[go-nuts] Re: Save to store encryption key in Go executable?

[Haddock]

Thanks for all the useful answers. All I want to do is to create an 
encryption program for simple home computing purposes. I once lost some 
encrypted files, because I lost the password. I think I did a typo when 
typing it in and didn't realize. So I thought I write my own encryption 
programm with a catch-all password in it. That might be a very bad idea now 
... 

I first wanted to use Java as I'm used to it. But Java code cannot be 
encrypted to hide the encryption key, because the Java byte codes would 
then become unreadable for the JVM. So I thought of something else. I 
thought of moving the key to some server. But then I would be dependent on 
some server and the Internet being reachable in order to decrypt my things 
(password files, etc.). 

Seems like the best solution would be to store the key in a separate file, 
though I don't understand exactly how this makes things better. Having the 
key in a separate file means that the decrypted blank key is only visible 
from within the running encryption programm for a very short moment. Is 
that the idea? Maybe have a solution that first looks for a local key file 
and only checks some server for it when locally not present.

Regards, Haddock

Am Montag, 13. Juni 2016 18:01:48 UTC+2 schrieb Haddock:
>
> Hello,
>
> I'm developing my own little encryption application in Go. The Go 
> application needs to know the key used for encryption and decryption. My 
> question is whether that key can be extracted from the Go executable 
> somehow through disassembly or looking at the applications memory or 
> something. I'm a complete Go beginner and know nothing about its memory 
> layout. So that's why I thought it's better to ask. 
>
> Thanks, Haddock
>

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

[Matt Harden]

Consider coercing them to int64, multiply, then shift and coerce back to
Int26_6. I suspect that would be faster than splitting with shifts and
ANDs, two int32 multiplies, shift and add.

On Tue, Jun 14, 2016, 11:42 Dave MacFarlane  wrote:

> I'm not actually trying to do x & -1, that would be pointless, as you say.
> It was just
> the easiest way to demonstrate the behaviour that I didn't understand in a
> minimal
> way. I understand the problem now--I was thinking of 0x as a prefix
> representing a bitmask
> when used as a constant with a bitwise operation, while Go thinks of it as
> a prefix
> representing a hexadecimal number even in that context.
>
> What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
> variables. I don't
> want to lose the precision that x*y >> 6 would unnecessarily as x or y get
> large, so I wanted
> to extract the first 26 bits, multiply them, and then separately multiply
> the decimal portion and add
> it back shifted into the correct location.
>
> (Int26_6 is defined as `type Int26_6 int32`)
>
> On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor  wrote:
>
>> On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane 
>> wrote:
>> > What I'm not understanding is why that's not the case in this example.
>> It's
>> > a 32 bit bitwise operation on a 32 bit signed type.  Shouldn't
>> 0x be
>> > coerced to a value of -1?
>>
>> Why don't you just write -1?
>>
>> I don't actually understand what you are doing.  Given an int32 value
>> x, x & 0xFFF (assuming that were valid) is always simply x.  What
>> else could it be?  If you want to mask out the sign bit you should
>> write x & 0x7FFF.
>>
>> Ian
>>
>>
>> > On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com> wrote:
>> >>
>> >> All binary operators, except shifts, require identical left and right
>> >> types. Untyped values will be coerced to the type of the other side, if
>> >> representable as such after the conversion. That's not the case in this
>> >> example.
>> >>
>> >> On Tue, Jun 14, 2016, 19:16 Dave MacFarlane  wrote:
>> >>>
>> >>> Is this supposed to be legal in Go:
>> >>>
>> >>> var x int32 = 3
>> >>>
>> >>> fmt.Printf("%d", x & 0x)?
>> >>>
>> >>> The language spec just says the bitwise operator "applies to integers
>> >>> only" and
>> >>> "yields a result of the same type as the first operand" that I can
>> see,
>> >>> but it's giving
>> >>> me a compiler error:
>> >>>
>> >>> ./main.go:10: constant 4294967295 overflows int32
>> >>>
>> >>> with go 1.6.2.
>> >>>
>> >>> Is this a compiler bug, or am I missing something else in the spec
>> that
>> >>> makes it impossible
>> >>> to mask out the high bit in a signed integer type without converting
>> to
>> >>> an unsigned equivalent first?
>> >>>
>> >>> - Dave
>> >>>
>> >>> --
>> >>> You received this message because you are subscribed to the Google
>> Groups
>> >>> "golang-nuts" group.
>> >>> To unsubscribe from this group and stop receiving emails from it,
>> send an
>> >>> email to golang-nuts+unsubscr...@googlegroups.com.
>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>
>> >> --
>> >>
>> >> -j
>> >
>> >
>> >
>> >
>> > --
>> > - Dave
>> >
>> > --
>> > You received this message because you are subscribed to the Google
>> Groups
>> > "golang-nuts" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> an
>> > email to golang-nuts+unsubscr...@googlegroups.com.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> - Dave
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

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

[Dave MacFarlane]

I'm not actually trying to do x & -1, that would be pointless, as you say.
It was just
the easiest way to demonstrate the behaviour that I didn't understand in a
minimal
way. I understand the problem now--I was thinking of 0x as a prefix
representing a bitmask
when used as a constant with a bitwise operation, while Go thinks of it as
a prefix
representing a hexadecimal number even in that context.

What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
variables. I don't
want to lose the precision that x*y >> 6 would unnecessarily as x or y get
large, so I wanted
to extract the first 26 bits, multiply them, and then separately multiply
the decimal portion and add
it back shifted into the correct location.

(Int26_6 is defined as `type Int26_6 int32`)

On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor  wrote:

> On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane 
> wrote:
> > What I'm not understanding is why that's not the case in this example.
> It's
> > a 32 bit bitwise operation on a 32 bit signed type.  Shouldn't
> 0x be
> > coerced to a value of -1?
>
> Why don't you just write -1?
>
> I don't actually understand what you are doing.  Given an int32 value
> x, x & 0xFFF (assuming that were valid) is always simply x.  What
> else could it be?  If you want to mask out the sign bit you should
> write x & 0x7FFF.
>
> Ian
>
>
> > On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com> wrote:
> >>
> >> All binary operators, except shifts, require identical left and right
> >> types. Untyped values will be coerced to the type of the other side, if
> >> representable as such after the conversion. That's not the case in this
> >> example.
> >>
> >> On Tue, Jun 14, 2016, 19:16 Dave MacFarlane  wrote:
> >>>
> >>> Is this supposed to be legal in Go:
> >>>
> >>> var x int32 = 3
> >>>
> >>> fmt.Printf("%d", x & 0x)?
> >>>
> >>> The language spec just says the bitwise operator "applies to integers
> >>> only" and
> >>> "yields a result of the same type as the first operand" that I can see,
> >>> but it's giving
> >>> me a compiler error:
> >>>
> >>> ./main.go:10: constant 4294967295 overflows int32
> >>>
> >>> with go 1.6.2.
> >>>
> >>> Is this a compiler bug, or am I missing something else in the spec that
> >>> makes it impossible
> >>> to mask out the high bit in a signed integer type without converting to
> >>> an unsigned equivalent first?
> >>>
> >>> - Dave
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "golang-nuts" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to golang-nuts+unsubscr...@googlegroups.com.
> >>> For more options, visit https://groups.google.com/d/optout.
> >>
> >> --
> >>
> >> -j
> >
> >
> >
> >
> > --
> > - Dave
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-nuts" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-nuts+unsubscr...@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>



-- 
- Dave

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

Re: [go-nuts] Bitmasks on signed types

[Michael Jones]

I have fought this many times.

What I almost always do is cast all variables involved as unsigned so that
I can express the logical operations as desired. The exception is right
shift which must be signed if the expected outcome for signed values is to
happen.

On Tue, Jun 14, 2016 at 1:08 PM, Dave MacFarlane  wrote:

> You're right. I've already written it the ugly way, but at least it
> has the benefit of being generalizable to fixed.Int52_12,
> while there is no int128.
>
> Would a patch that adds a Mult receiver function to Int52_12 and
> Int26_6 be welcome in x/image/math/fixed? I've already
> worked out the stupid shifting/bitwise arithmetic so you don't end up
> with things like multiplying by fixed.I(1) overflowing. It seems
> like the type of thing that users of the package shouldn't have to
> derive from scratch if they just want to multiply 2 fixed point
> numbers.
>
> - Dave
>
> On Tue, Jun 14, 2016 at 3:41 PM, Matt Harden 
> wrote:
> > Consider coercing them to int64, multiply, then shift and coerce back to
> > Int26_6. I suspect that would be faster than splitting with shifts and
> ANDs,
> > two int32 multiplies, shift and add.
> >
> > On Tue, Jun 14, 2016, 11:42 Dave MacFarlane  wrote:
> >>
> >> I'm not actually trying to do x & -1, that would be pointless, as you
> say.
> >> It was just
> >> the easiest way to demonstrate the behaviour that I didn't understand
> in a
> >> minimal
> >> way. I understand the problem now--I was thinking of 0x as a prefix
> >> representing a bitmask
> >> when used as a constant with a bitwise operation, while Go thinks of it
> as
> >> a prefix
> >> representing a hexadecimal number even in that context.
> >>
> >> What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
> >> variables. I don't
> >> want to lose the precision that x*y >> 6 would unnecessarily as x or y
> get
> >> large, so I wanted
> >> to extract the first 26 bits, multiply them, and then separately
> multiply
> >> the decimal portion and add
> >> it back shifted into the correct location.
> >>
> >> (Int26_6 is defined as `type Int26_6 int32`)
> >>
> >> On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor 
> wrote:
> >>>
> >>> On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane 
> >>> wrote:
> >>> > What I'm not understanding is why that's not the case in this
> example.
> >>> > It's
> >>> > a 32 bit bitwise operation on a 32 bit signed type.  Shouldn't
> >>> > 0x be
> >>> > coerced to a value of -1?
> >>>
> >>> Why don't you just write -1?
> >>>
> >>> I don't actually understand what you are doing.  Given an int32 value
> >>> x, x & 0xFFF (assuming that were valid) is always simply x.  What
> >>> else could it be?  If you want to mask out the sign bit you should
> >>> write x & 0x7FFF.
> >>>
> >>> Ian
> >>>
> >>>
> >>> > On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com> wrote:
> >>> >>
> >>> >> All binary operators, except shifts, require identical left and
> right
> >>> >> types. Untyped values will be coerced to the type of the other side,
> >>> >> if
> >>> >> representable as such after the conversion. That's not the case in
> >>> >> this
> >>> >> example.
> >>> >>
> >>> >> On Tue, Jun 14, 2016, 19:16 Dave MacFarlane 
> wrote:
> >>> >>>
> >>> >>> Is this supposed to be legal in Go:
> >>> >>>
> >>> >>> var x int32 = 3
> >>> >>>
> >>> >>> fmt.Printf("%d", x & 0x)?
> >>> >>>
> >>> >>> The language spec just says the bitwise operator "applies to
> integers
> >>> >>> only" and
> >>> >>> "yields a result of the same type as the first operand" that I can
> >>> >>> see,
> >>> >>> but it's giving
> >>> >>> me a compiler error:
> >>> >>>
> >>> >>> ./main.go:10: constant 4294967295 overflows int32
> >>> >>>
> >>> >>> with go 1.6.2.
> >>> >>>
> >>> >>> Is this a compiler bug, or am I missing something else in the spec
> >>> >>> that
> >>> >>> makes it impossible
> >>> >>> to mask out the high bit in a signed integer type without
> converting
> >>> >>> to
> >>> >>> an unsigned equivalent first?
> >>> >>>
> >>> >>> - Dave
> >>> >>>
> >>> >>> --
> >>> >>> You received this message because you are subscribed to the Google
> >>> >>> Groups
> >>> >>> "golang-nuts" group.
> >>> >>> To unsubscribe from this group and stop receiving emails from it,
> >>> >>> send an
> >>> >>> email to golang-nuts+unsubscr...@googlegroups.com.
> >>> >>> For more options, visit https://groups.google.com/d/optout.
> >>> >>
> >>> >> --
> >>> >>
> >>> >> -j
> >>> >
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > - Dave
> >>> >
> >>> > --
> >>> > You received this message because you are subscribed to the Google
> >>> > Groups
> >>> > "golang-nuts" group.
> >>> > To unsubscribe from this group and stop receiving emails from it,
> send
> >>> > an
> >>> > email to golang-nuts+unsubscr...@googlegroups.com.
> >>> > For more options, visit https://groups.google.com/d/optout.
> >>
> >>
> 

Re: [go-nuts] Hi! I'm happy to announce the very first release of *nexer* 1.0.0b simple and easy to use and extend content based network multiplexer

[Konstantin Khomoutov]

On Tue, 14 Jun 2016 17:29:33 -0700 (PDT)
Diego Cena  wrote:

> *nexer* is a simple and easy to use and extend content based network 
> multiplexer (or redirector)

Could you please explain to the uninitiated in a couple of words what
the heck "content-based network multiplexer" is? ;-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: broadcasting on a set of channels

[Ian Lance Taylor]

On Tue, Jun 14, 2016 at 10:15 PM,   wrote:
>
> What happens if the channel closes?
>
> I'm thinking about maintaining a list of channels (one for each websocket
> client), then sending a message to all of them.  The only problem is that
> when the websocket client disconnects, their channel closes.  Being there no
> easy way to skip closed channels, the program crashes.

To be clear, I assume that we are talking about the Go chan type.

Closing a channel is a send operation, and only the sender should
close a channel.  So I'm not sure what you mean when you that when the
websocket client disconnects, their channel closes.  If you are
sending a message to the client, then the client should not close the
channel.

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] [ANN] GopherPit.com - service to manage remote import paths

[Janoš Guljaš]

Hello all,

I would like to announce GopherPit [0], a web service to serve and manage
go-import and go-source HTML meta tags. [1] That is the base functionality,
but it supports custom domains, subdomains under gopherpit.com, automatic
TLS certificate generation from Let’s Encrypt, team management for each
domain…

It allows usage of custom domains for projects, that for any reason, can
not be hosted on github or similar providers, or branding is required. This
project started as service for managing package paths for private usage,
that can be useful for single developer as well as for teams.

A kind of versioning can also be achieved by specifying different
repositories for subpaths, like example.com/package and
example.com/package/v2, if you do not want to keep both code-bases in the
same repository.

It serves a simple purpose, but it implements many boring parts related to
a public web service.

Best regards,
Janoš

[0] https://gopherpit.com
[1] https://golang.org/cmd/go/#hdr-Remote_import_paths

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Hi! I'm happy to announce the very first release of *nexer* 1.0.0b simple and easy to use and extend content based network multiplexer

[Diego Cena]

Sure Konstantin!

It means you can route network traffic based on transmitted content. A 
minimalistic example is the ur ltunnel type.

:-)



On Wednesday, June 15, 2016 at 7:58:36 AM UTC-3, Konstantin Khomoutov wrote:
>
> On Tue, 14 Jun 2016 17:29:33 -0700 (PDT) 
> Diego Cena  wrote: 
>
> > *nexer* is a simple and easy to use and extend content based network 
> > multiplexer (or redirector) 
>
> Could you please explain to the uninitiated in a couple of words what 
> the heck "content-based network multiplexer" is? ;-) 
>

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

[ToSuNuS]

Hi Steven,

I want to use a word that the data from this function.

for example;

f := func() { grep(flag.Arg(0), flag.Arg(1)) }

if f  == "domain.com" {
}

or

handle := exec.Command("echo", string(f[1])).Output()

Examples of these subject. My purpose is to convert the string.

Regards.

On Wednesday, June 15, 2016 at 7:28:53 PM UTC+3, Steven Blenkinsop wrote:
>
> Oh, sorry, didn't see that. `grep` doesn't return a value, so there's 
> nothing to assign to a variable. What are you trying to do exactly? If you 
> want a function value you can call repeatedly which will pass the same 
> arguments to `grep`, you want:
>
>f := func() { grep(flag.Arg(1), flag.Arg(2)) }
>
> This is called a closure. It basically creates a function value you can 
> call, and it will execute the body each time, in this case the call to 
> grep. It will also capture any variables referenced inside it, but that 
> doesn't happen here.
>
> On Wed, Jun 15, 2016 at 12:17 PM ToSuNuS  
> wrote:
>
>> Hi Steven,
>>
>> I mistyped the opening question.
>>
>> However, the script has been added correctly.
>>
>> Of course, the result is still the same.
>>
>> I run the command.
>>
>> go run test.go testword /root/testfile.txt
>>
>> Result:
>>
>> grep(flag.Arg(0), flag.Arg(1)) used as value
>>
>> I just add the following code. (to test)
>>
>> f := grep(flag.Arg(0), flag.Arg(1))
>> fmt.Println(f)
>>
>>
>> Regards.
>>
>>
>> On Wednesday, June 15, 2016 at 6:54:18 PM UTC+3, ToSuNuS wrote:
>>>
>>> Hi guys,
>>>
>>> How do I assign a variable function of sample scripts are used on the 
>>> following address?
>>>
>>>
>>> https://github.com/StefanSchroeder/Golang-Regex-Tutorial/blob/master/01-chapter3.markdown
>>>
>>> How can I define this as a variables of function .
>>>
>>> grep (flag.arg (0) flag.arg (1))
>>>
>>> I tried as follows. However, the results did not.
>>>
>>> f := grep (flag.arg (0) flag.arg (1))
>>>
>>> Regards.
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@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: polymorphism (for Go 2.0), new fast playground is live

[adamw]

I'd like to see changes to the standard library. Things that many people 
agree should be fixed but thwarted by go1 compat. The list is long and this 
mailing list is riddled with them. Possibly weeding out the standard 
library, kicking stuff to /x/.

I'd provide generics through preprocessors wrapping the go toolkit. Most of 
everything needed is already provided in /src/go. The hard works already 
been done by the go team. A few interesting ideas come across this mailing 
list, but that is it, just ideas.

On Saturday, June 11, 2016 at 4:31:06 PM UTC-4, charr...@gmail.com wrote:
>
> Document: 
> https://docs.google.com/document/d/1kAc6Hn89j1aspqBdeywP0X3IvVr0P4xrOZqYr0yYgNg/edit?usp=sharing
>
> The project is currently stuck the following things.
> swapping of generic variables. - a must have, for sort  obviously. 
> To operate on arbitrary slices not just slices of arbitrary pointers.
>
> The generic return is another nice to have thing, but can be emulated by C 
> inspired double pointer argument.
>
> It's time to look for new goals, maybe do some map[anything]struct{} set 
> thing. Various channels and merging
> multiple channels with same values into one channel and other stuff is 
> another area ripe for exploration.
>
> What do you need to be added to the Go language?
>

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

[go-nuts] Proposal: extend the "don't care" value to more uses

[oli . gagnon4418]

consider 

func Foo(a int, b string, x SomeStruct)


It would be nice if it was possible to pass in the "don't care" value, 
a.k.a. "_" as one of the argument, as an alias for the default value of the 
type.

pkg.Foo(a, b, _) 


This way if the user knows he doesn't care about the last value and that 
the default is fine. He can use that syntax to just give the zero value.

This could be extended to returns

func Bar() (SomeStruct, error) { 

...

if err != nil { 

return _, err

} 

...

} 


or things like channels

var c chan struct{}

c <- _ 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: curious problem implementing RGB565 image

[Dan Kortschak]

Yes, that explains it.

The simple summary is that I forgot the r,g,b,a are 16bit and was
working with them as 8bit. This is why the image.RGBA worked, but the
png decoded image did not - image.RGBA returned c|c<<8 for each channel,
so the error was masked by having the low byte mimic the high byte.

thanks

On Tue, 2016-06-14 at 11:15 +1000, Nigel Tao wrote:
> On Mon, Jun 13, 2016 at 9:10 PM, Dan Kortschak
>  wrote:
> > Though doing the direct round trip of an image through an RGB565 gets
> > back the pixels in a state that you would expect, shown here in the
> > playground snippet:
> >
> > https://play.golang.org/p/UCwE4YJk21
> 
> Here's your color model function:
> 
> func rgb565Model(c color.Color) color.Color {
> if _, ok := c.(Pixel565); ok {
> return c
> }
> r, g, b, _ := c.RGBA()
> r >>= (bytewid - rwid)
> g >>= (bytewid - gwid)
> b >>= (bytewid - bwid)
> return Pixel565((r)< }
> 
> The
> r, g, b, _ := c.RGBA()
> line gives a 16-bit red value, in the range [0x, 0x]. The
> value's type is uint32, but the effective range is 16 bits. (See the
> "three important subtleties" paragraph at
> https://blog.golang.org/go-image-package). The next line is:
> r >>= (bytewid - rwid)
> or equivalently,
> r >>= (8 - 5)
> so that r is effectively an 13 bit value. The final line says:
> r
> but rmask is 0x1f, so you're masking off all but the low 5 bytes,
> instead of the high 5 bytes. I suspect that it suffices to replace
> r >>= (bytewid - rwid)
> with
> r >>= (8 + bytewid - rwid)
> and the same for g and b, obviously.
> 
> Here's a quick test:
> fmt.Printf("0x%04x\n", RGB565Model.Convert(color.RGBA64{
> R: 0x,
> G: 0x,
> B: 0x8000,
> A: 0x,
> }))
> should print a Pixel565 value that's 50-ish% blue: 0x0010 instead of 0x.

-- 
Omnes mundum facimus.

Dan Kortschak 
F9B3 3810 C4DD E214 347C B8DA D879 B7A7 EECC 5A40
10C7 EEF4 A467 89C9 CA00 70DF C18F 3421 A744 607C

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Better sum types for go

[as . utf8]

Thanks!

On Monday, June 13, 2016 at 3:27:51 AM UTC-7, Jesper Louis Andersen wrote:
>
>
> On Mon, Jun 13, 2016 at 1:58 AM,  wrote:
>
>> What research or other literature can you recommend on the topic of type 
>> theory?
>
>
> Benjamin C. Pierce's "Types and Programming Languages", often abbreviated 
> TAPL, is a classic text on type theory. Working from the semanticists 
> favorite toy language, the Lambda-calculus, Pierce proceeds to add 
> different type-theoretic constructs on top of it one at a time to explain 
> their concepts. Don't let the choice of the lambda-calculus fool you. Once 
> you add references into that language it essentially becomes a basis for 
> imperative programming.
>
>
> -- 
> 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] Re: How to get executed query string after execution.

[Harry]

Hi Dave,

Now, I'm developping cache system of query result to redis or another 
key-value store.
Stored data are supposed that seriarized result of query using key 
serialized query string exected actually.


Harry

2016年6月14日火曜日 10時23分25秒 UTC+9 Dave Cheney:
>
> If there was a way to get the contents of the query string, what would you 
> do with that information?
>
> On Tuesday, 14 June 2016 11:18:47 UTC+10, Harry wrote:
>>
>> Hi guys,
>>
>> I wonder that question.
>> Before execution, it's possible to get query by myself.
>> But I want to get executed query string actually.
>> Is there any way to manage that?
>>
>> Thanks!
>>
>

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

Re: [go-nuts] Bitmasks on signed types

['Keith Randall' via golang-nuts]

I do x & (0x - 1<<32).

On Tuesday, June 14, 2016 at 1:44:14 PM UTC-7, Michael Jones wrote:
>
> I have fought this many times. 
>
> What I almost always do is cast all variables involved as unsigned so that 
> I can express the logical operations as desired. The exception is right 
> shift which must be signed if the expected outcome for signed values is to 
> happen.
>
> On Tue, Jun 14, 2016 at 1:08 PM, Dave MacFarlane  > wrote:
>
>> You're right. I've already written it the ugly way, but at least it
>> has the benefit of being generalizable to fixed.Int52_12,
>> while there is no int128.
>>
>> Would a patch that adds a Mult receiver function to Int52_12 and
>> Int26_6 be welcome in x/image/math/fixed? I've already
>> worked out the stupid shifting/bitwise arithmetic so you don't end up
>> with things like multiplying by fixed.I(1) overflowing. It seems
>> like the type of thing that users of the package shouldn't have to
>> derive from scratch if they just want to multiply 2 fixed point
>> numbers.
>>
>> - Dave
>>
>> On Tue, Jun 14, 2016 at 3:41 PM, Matt Harden > > wrote:
>> > Consider coercing them to int64, multiply, then shift and coerce back to
>> > Int26_6. I suspect that would be faster than splitting with shifts and 
>> ANDs,
>> > two int32 multiplies, shift and add.
>> >
>> > On Tue, Jun 14, 2016, 11:42 Dave MacFarlane > > wrote:
>> >>
>> >> I'm not actually trying to do x & -1, that would be pointless, as you 
>> say.
>> >> It was just
>> >> the easiest way to demonstrate the behaviour that I didn't understand 
>> in a
>> >> minimal
>> >> way. I understand the problem now--I was thinking of 0x as a prefix
>> >> representing a bitmask
>> >> when used as a constant with a bitwise operation, while Go thinks of 
>> it as
>> >> a prefix
>> >> representing a hexadecimal number even in that context.
>> >>
>> >> What I *really* want to do is multiply 2 x/image/math/fixed.Int26_6
>> >> variables. I don't
>> >> want to lose the precision that x*y >> 6 would unnecessarily as x or y 
>> get
>> >> large, so I wanted
>> >> to extract the first 26 bits, multiply them, and then separately 
>> multiply
>> >> the decimal portion and add
>> >> it back shifted into the correct location.
>> >>
>> >> (Int26_6 is defined as `type Int26_6 int32`)
>> >>
>> >> On Tue, Jun 14, 2016 at 2:16 PM, Ian Lance Taylor > > wrote:
>> >>>
>> >>> On Tue, Jun 14, 2016 at 10:44 AM, Dave MacFarlane > >
>> >>> wrote:
>> >>> > What I'm not understanding is why that's not the case in this 
>> example.
>> >>> > It's
>> >>> > a 32 bit bitwise operation on a 32 bit signed type.  Shouldn't
>> >>> > 0x be
>> >>> > coerced to a value of -1?
>> >>>
>> >>> Why don't you just write -1?
>> >>>
>> >>> I don't actually understand what you are doing.  Given an int32 value
>> >>> x, x & 0xFFF (assuming that were valid) is always simply x.  What
>> >>> else could it be?  If you want to mask out the sign bit you should
>> >>> write x & 0x7FFF.
>> >>>
>> >>> Ian
>> >>>
>> >>>
>> >>> > On Tue, Jun 14, 2016 at 1:23 PM, Jan Mercl <0xj...@gmail.com 
>> > wrote:
>> >>> >>
>> >>> >> All binary operators, except shifts, require identical left and 
>> right
>> >>> >> types. Untyped values will be coerced to the type of the other 
>> side,
>> >>> >> if
>> >>> >> representable as such after the conversion. That's not the case in
>> >>> >> this
>> >>> >> example.
>> >>> >>
>> >>> >> On Tue, Jun 14, 2016, 19:16 Dave MacFarlane > > wrote:
>> >>> >>>
>> >>> >>> Is this supposed to be legal in Go:
>> >>> >>>
>> >>> >>> var x int32 = 3
>> >>> >>>
>> >>> >>> fmt.Printf("%d", x & 0x)?
>> >>> >>>
>> >>> >>> The language spec just says the bitwise operator "applies to 
>> integers
>> >>> >>> only" and
>> >>> >>> "yields a result of the same type as the first operand" that I can
>> >>> >>> see,
>> >>> >>> but it's giving
>> >>> >>> me a compiler error:
>> >>> >>>
>> >>> >>> ./main.go:10: constant 4294967295 overflows int32
>> >>> >>>
>> >>> >>> with go 1.6.2.
>> >>> >>>
>> >>> >>> Is this a compiler bug, or am I missing something else in the spec
>> >>> >>> that
>> >>> >>> makes it impossible
>> >>> >>> to mask out the high bit in a signed integer type without 
>> converting
>> >>> >>> to
>> >>> >>> an unsigned equivalent first?
>> >>> >>>
>> >>> >>> - Dave
>> >>> >>>
>> >>> >>> --
>> >>> >>> You received this message because you are subscribed to the Google
>> >>> >>> Groups
>> >>> >>> "golang-nuts" group.
>> >>> >>> To unsubscribe from this group and stop receiving emails from it,
>> >>> >>> send an
>> >>> >>> email to golang-nuts...@googlegroups.com .
>> >>> >>> For more options, visit https://groups.google.com/d/optout.
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> -j
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> > --
>> >>> > - Dave
>> >>> >
>> >>> > --
>> >>> > You received this message because you are subscribed to the 

Re: [go-nuts] Re: Go 1.6.1 Link problem on Windows:

[Roger Pack]

FWIW this is not a failure, just a double define... and if the problem
is in mingw-w64 then it won't be fixed in golang any version of
course, though I'm not sure if that's the case or not.
Cheers!

On Wed, Jun 22, 2016 at 6:24 AM,   wrote:
> I am having the same issues with go1.6.2... I also tried go1.7beta2 with no
> luck.
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dmads01971.o):(.idata$5+0x0):
> multiple definition of `__imp_sqrt'
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dygcs01179.o):(.idata$5+0x0):
> first defined here
>
>
>
> On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>>
>> Hi,
>>
>> I'm just wondering what is the cause of the following error (multiple
>> definition of __something)?
>> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>>
>> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>> multiple definition of `__imp_pow'
>>
>> This only happens on Windows10 but on Ubuntu/Linux.
>>
>> The Go code makes a call to LAPACK via a C interface as follows:
>> package main
>>
>> /*
>> #cgo CFLAGS: -O3
>> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
>> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>>
>> #include 
>>
>> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const int*
>> N, double* A, const int* lda, double* S, double* U, const int* ldu, double*
>> VT, const int* ldvt, double* work,const int* lwork, const int* info);
>>
>> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
>> int m = (int)(m_long);
>> int info  = 0;
>> charjob   = 'A';
>> int lwork = 10*m;
>> double* work  = (double*)malloc(lwork*sizeof(double));
>> dgesvd_(,   // JOBU
>> ,   // JOBVT
>> , // M
>> , // N
>> A,  // A
>> , // LDA
>> S,  // S
>> U,  // U
>> , // LDU
>> Vt, // VT
>> , // LDVT
>> work,   // WORK
>> , // LWORK
>> ); // INFO
>> free(work);
>> return info;
>> }
>> */
>> import "C"
>>
>> import (
>> "fmt"
>> "math"
>> "unsafe"
>> )
>>
>> func main() {
>> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
>> m := int(math.Sqrt(float64(len(A
>> I := func(i, j int) int { return j*m + i }
>> printmat(m, A, "A")
>> U := make([]float64, len(A))
>> S := make([]float64, len(A))
>> Vt := make([]float64, len(A))
>> info := C.lapack_svd(
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (C.long)(m),
>> (*C.double)(unsafe.Pointer([0])),
>> )
>> fmt.Printf("SVD: info = %d\n", info)
>> USVt := make([]float64, len(A))
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> for k := 0; k < m; k++ {
>> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
>> }
>> }
>> }
>> printmat(m, USVt, "U*S*Vt")
>> }
>>
>> func printmat(m int, M []float64, msg string) {
>> fmt.Printf("%s =\n", msg)
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> fmt.Printf("%13.8f", M[j*m+i])
>> }
>> fmt.Println()
>> }
>> }
>>
>> Any help is much appreciated.
>>
>> Cheers.
>> Dorival
>
> --
> 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/fW4KZQ05G_8/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.

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Michael Jones]

> https://github.com/golang/go/issues/42

Michael Jones
michael.jo...@gmail.com

> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
> 
> Could you drop me a link to the discussion by chance? Seems this
> feature is actually a reasonably common request :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Andy Balholm]

Actually, the mention of gofmt brings up the issue of consistent formatting. If 
underscores in numbers were allowed, gofmt should automatically insert them for 
all numbers over a given length, and remove them for shorter numbers. Otherwise 
it would just be another opportunity for inconsistency, like indentation.

Andy

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

[Tu Pham Anh]

Thank you very much for your response, I think that at abstract level it is 
true.

When we go into more detail, we will that GO optimize to have Routine context ( 
that some kind of Thread context), I think that at the conception level it some 
kind of yeild (conception ) to start to GORoutine.

But I read somewhere that GoRoutine optimize to create the thread when it 
dispatched ( at REGIGER level, they said that 3 Registers  need to be handled 
to create new GoRoutine ).


You see that although you could create the large number of GORoutine but almost 
of them have status BLOCK, and small number of them are running ( basing OS 
Thread ). For the sharing data between routines, I think that in mode RUNNING, 
there are Routine context that keep this sharing work smoothly.

In my own opinion, it is one of the best choice to schedule job, Imagine that 
each time you start the GoRoutine, the new OS thread is created and start - I 
do not think that way cheap or lightweight routine as everyone said.



> On Jun 22, 2016, at 20:53, Konstantin Khomoutov 
>  wrote:
> 
> On Wed, 22 Jun 2016 00:34:56 -0700 (PDT)
> tu.p...@zalora.com wrote:
> 
>> I think that the idea of Goroutine come from
>> [https://en.wikipedia.org/wiki/Coroutine],
> 
> This is hardly true: coroutines imply cooperative scheduling, where
> each coroutine explictly relinquishes control to some other coroutine
> (typically it's said it "yields" some intermediate result) without
> actually returning.  In contrast, goroutines behave much more like
> OS-level threads in that the Go runtime scheduler is free to preempt any
> goroutine at will at certain key points of their execution (presently
> these include the event when a goroutine is about to block on a syscall
> or call another Go function).  Hence while it's not a "full" preemptive
> scheduling which commodity operating systems apply to their OS-level
> threads, it's still way more closer to it than the cooperative ("at
> will") scheduling used by coroutines.
> 
> One more point to this is that coroutines are usually considered as
> being executed by a single thread of execution which is not true for
> goroutines -- which, due to this reason, cannot safely access shared
> data without locking, and must synchronize all such access or use
> specific communication primitives -- channels.
> 
> Go draws its approach to goroutines from a number of languages which
> predates it, but ultimately this idea comes from [1].
> 
>> the number of Goroutines are mapped to OS Threads.
> 
> It's more accurate to say that an arbitrary number of goroutines can be
> mapped to an arbitrary number of OS threads, which is usually referred
> to as "N x M scheduling", with N -- the number of goroutines --
> typically being way larger than M -- the number of OS threads undelying
> them.
> 
>> In my own opinion, Go maintain the Thread pool and task queue to
>> dispatch the job.
> 
> At a very abstract level, this is mostly true.
> 
> [...]
> 
> 1. https://en.wikipedia.org/wiki/Communicating_sequential_processes

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Roger Pack]

Could you drop me a link to the discussion by chance? Seems this
feature is actually a reasonably common request :)

On Tue, Jun 21, 2016 at 12:47 PM, Michael Jones  wrote:
> I asked for this a while back ("drop underscore between digits as in Ada")
> and the answer was no. I try to ask just once.
>
> This was shut down without much discussion at
> https://github.com/golang/go/issues/42.
>
> I agree that it's a nice feature.
>
> By the way, though, one nice aspect of Go is that because of how
> untyped constants work you can write integers using scientific
> notation:
>
> for i := 0; i < 10e6; i++ {
> // ...
> }
>
> This is exactly the same as if you had written 1000.
>
> (I don't think you'd want to do this in C or Java because, although it
> would "work", 10e6 is a floating point number and so i would be
> converted to a double for comparison. I am not an expert in those
> languages, though, so someone can correct if I'm wrong here.)
>
> On Tue, Jun 21, 2016 at 8:44 AM, Roger Pack  wrote:
>> I found recently when doing some language comparisons
>>
>> In a few other languages (ruby, java, etc.) underscores within numeric
>> literals to make them more readable, ex:
>>
>> 10_000_000.times do
>>   ...
>> end
>>
>> go ex:
>>
>> for i := 0; i < 1000; i++ {
>> ...
>> }
>>
>> I find it helps readability, and think it would be a nice addition to the
>> language (or some way to group digits, perhaps there already is one?).
>> Consider this a feature request (go 2.0 or what not).
>> Cheers.
>> -roger-
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Michael Jones]

Sorry, I sent that too soon. 

One argument against underscores in numbers and other discardable syntax is the 
tooling in Go to parse and regenerate go code, as in gofmt. It may be more 
complicated to keep the “original input format” around and that is a pretty 
good argument—unless that is already there for input values in hex.

Michael Jones
michael.jo...@gmail.com

> On Jun 22, 2016, at 8:14 AM, Michael Jones  wrote:
> 
>> https://github.com/golang/go/issues/42
> 
> Michael Jones
> michael.jo...@gmail.com
> 
>> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
>> 
>> Could you drop me a link to the discussion by chance? Seems this
>> feature is actually a reasonably common request :)
> 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Any keyboard players here?

[Seb Binet]

On Wed, Jun 22, 2016 at 6:37 PM,  wrote:

> Hello,
>
> I created a (kind of) organ or piano, to be played with a MIDI keyboard.
> It has a GUI running in the terminal, thanks to the excellent termbox-go
> library. It's only for Linux, but porting should not be too difficult.
> PulseAudio is used for sound.
>
> In my humble opinion this software instrument sounds very good. You can
> add new patches of your own, adding to the about 20 built-in patches. What
> you play can be dumped into a WAVE file.
>
> You can get it here: https://github.com/wboeke/tgui
>

FYI, there was this Go challenge some time ago:
 http://golang-challenge.org/go-challenge7/
with these winners:
 https://jamescscott.io/2015/11/03/my-golang-challenge-experience/
 https://github.com/dskinner/snd/tree/master/example/piano

I also know Andrew Gerrand is dabbling into sound related activities
(during his "copious" free time :P)
https://github.com/nf/sigourney

hth,
-s

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Treeless: distributed NoSQL key-value DB written in Go

[David M.]

Hi,

I've just released Treeless (https://github.com/dv343/treeless), a new 
distributed NoSQL key-value DB written in Go.

I have been focused on performance and simplicity and I think I have 
achieved good results. For example, Get performance is 20% slower compared 
to Redis, but Set performance can be up to 2x faster than Redis.

I think I have reached a  stable state. Real usage may show critical bugs, 
but all tests are passed now.

I would love to get some feedback about it, I know it's not perfect, and it 
needs some polish, but I hope you like it.

PS: I didn't thought I would achieve those performance results with Go, 
using Go has been a really good design choice. Congratulations to all Go 
developers! 

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] A proposal for generic in go

[Micky]

I guess that's for diplomatic reasons. If you watch talks of core
contributors then I believe you'll know what I mean :)

On Tue, Jun 21, 2016 at 5:15 AM, Rodrigo Kochenburger  wrote:
> Micky, I'm not sure where you're quoting from but they never said it's never
> gonna happen.
>
> From the FAQ: "Generics may well be added at some point." and "This remains
> an open issue".
>
> https://golang.org/doc/faq#generics
>
>
> On Mon, Jun 20, 2016 at 4:54 PM Micky  wrote:
>>
>> It's never going to happen! To quote the powers-to-be, "The language is
>> done".
>> Good luck!
>>
>> On Wed, Jun 15, 2016 at 6:04 AM, xingtao zhao 
>> wrote:
>> > Here is my proposal for generic in go:
>> >
>> > https://docs.google.com/document/d/1nO7D15c2B3eq2kF62C0yUs_UgpkyPL2zHhMAmlq1l98/edit?usp=sharing
>> >
>> > Many parts has not been finished, and just initial thoughts. In the
>> > proposal, I want to keep back compatibility. And I try to add the
>> > orthogonal
>> > feature only and keep the language still simple enough.
>> >
>> > Please add your comments on it. Hope it is useful and could inspire some
>> > new
>> > features in go 2.0
>> >
>> > 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] Send us your gophers!

[Jan Mercl]

On Sat, May 21, 2016 at 8:28 AM 'Andrew Gerrand' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Renee French and I are doing a little secret project and would love it if
you would draw a gopher and sent it to us.

Hi Andrew,

is / will be there be some public output of your little secret project?

-- 

-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] Re: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>
>
> 
>
> I am attempting to generate a random starfield, in go. This is something 
> that will need to printed on actual paper, but that is another issue and I 
> only mention it to give some context for what I am doing here: Using go to 
> create graphics to pair with something I'm already doing in go (I've been 
> through several iterations of trying to use the go parts I have with 
> numerous variations of tex/latex templates using asymptote, and I reached a 
> point of frustration where I figured why not just do it all in go, as it 
> seems less a problem than I originally thought -- but opens a new set of 
> problems to solve, one of the biggest is that I know nothing at all about 
> graphics, let alone how to apply graphics in go).
>
> Cosmic1 from:  
> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
> generates the above it is the first thing that even roughly approximates 
> what I want to do.
>
> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
> directly translate an opengl shader to something cpu bound(which I suspect 
> is a thing, I may need to do more that I can't see right now).
>

As for the current code:

Here you are picking a random rotation for each pixel:
a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2

This can change for every pixel (in shader the time is a constant for one 
frame):
time := float64(time.Now().UTC().Unix())*speed + 0.25

In func toUint8(in float64) uint8 { you need to clamp the value between 0 
and 255, otherwise the conversion overflows.

Color adjusting code doesn't match the shader code.

I suspect there are further issues in the iteration code.

PS: often with such fragments you can simplify code and achieve a similar 
result with less details, e.g. 
https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] [ANN] primegen.go: Sieve of Atkin prime number generator

[alb . donizetti]

>  Do you plan to include SSA for the x86 version as well?

For an answer to this: yes, it seems like the plan is to port every 
supported architecture
to SSA. It was discussed here:
https://groups.google.com/d/msg/golang-dev/fSIl5Sbr4ek/10sgOsnDEAAJ

Il giorno martedì 21 giugno 2016 03:39:41 UTC+2, gordo...@gmail.com ha 
scritto:
>
> On Monday, June 20, 2016 at 6:33:29 AM UTC-7, gordo...@gmail.com wrote: 
> Further to the subject of compiler efficiency, the following is the 
> assembler code output with array bounds checking turned off (-B) the the 
> inner tight composite culling loop of FasterEratspeed above (generated with 
> go tool compile -B -S FasterEratspeed.go > FasterEratspeed.asm): 
>
> 0x0051 00081 (main.go:426)MOVLR11, CX 
> 0x0054 00084 (main.go:426)SHRL$5, R11 
> 0x0058 00088 (main.go:428)MOVL(R9)(R11*4), R13 
> 0x005c 00092 (main.go:430)MOVL$1, R14 
> 0x0062 00098 (main.go:430)SHLLCX, R14 
> 0x0065 00101 (main.go:430)ORLR13, R14 
> 0x0068 00104 (main.go:431)MOVLR14, (R9)(R11*4) 
> 0x006c 00108 (main.go:429)LEAL(R12)(CX*1), R11 
> 0x0070 00112 (main.go:425)CMPLR11, R8 
> 0x0073 00115 (main.go:425)JCS$0, 81 
>
> At 10 instructions, this is about as tight as it gets other than for using 
> the more complex read/modify/write version of the ORL instruction, but that 
> doesn't seem to save much if any time given instruction latencies.  Note 
> that this code has eliminated the "k & 31" for the shift, seeming to 
> recognize that it isn't necessary as a long shift can't be greater than 31 
>
> Getting rid of the &31 is easy and I'll do that in 1.8. 
>   
> anyway, that unlike the simple PrimeSpeed program, this properly uses the 
> immediate load of '1', 
>
> I don't know what the issue is yet, but it shouldn't be hard to fix in 
> 1.8. 
>   
> that it cleverly uses the LEAL instruction to add the prime value 'q' in 
> R12 to the unmodified 'k' value in CX to produce the sum to the original 
> location of 'j' in R11 to save another instruction to move the results from 
> CX to R11. 
>
> The current SSA backend should do this also. 
>   
> No, Keith, you seem to have misunderstood, I wasn't complaining above the 
> above assembler codeas produced by the 1.7beta1 compiler, and I was 
> wondering why it always isn't this good, which is about as good as it gets 
> for this loop and already properly gets rid of &31, does a proper immediate 
> load of 1, and the clever use of the LEA instruction without the misuse of 
> the LEA instruction to continuously recalculate 'p'.  The assembler code 
> above is produced by either of the below loop variations: 
>
> 1) as it is in FasterEratspeed: 
>
> for k < lngthb { 
> pos := k >> 5 
> data := k & 31 
> bits := buf[pos] 
> k += q 
> bits |= 1 << data // two[data] 
> buf[pos] = bits 
> } 
>
> 2) I get the same assembler code if I change this to the simpler: 
>
> for ; k < lngthb; k += q { 
> buf[k>>5] |= 1 << (k & 31) 
> } 
>
> where all variables and buffers are uint32. 
>
> My question was, why did the compiler produce this very good code for both 
> variations, yet produced something much worse for the same variation two 
> loop in the simple PrimeSpeed code, with the main difference that 
> PrimeSpeed uses 64-bit uint for the loop variables and loop limit.  Does 
> that give you a clue where the problem might be?  Converting PrimeSpeed to 
> use uint32's as here fixed the continuous recalculation of 'p' but not the 
> other problems. 
>
> It seems that sometimes the compiler erroneously tries to reduce register 
> use without applying the cost in execution speed to the decision.  It is 
> inconsistent, sometimes producing great code as here, and sometimes not so 
> great as in PrimeSpeed. 
>
> I was looking for some general advice on how to format loops so they 
> produce code as good as this? 
>
> Do you plan to include SSA for the x86 version as well?

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

[DM]

Hi

On Mac OS X 10.11.4 *go get* is failing with the below error. 

jabongs-MacBook-Pro-4:florest debraj$ go get ./...
go install github.com/jabong/florest/src/common/config: open /var/folders/lp
/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.com/jabong/
florest/src/common/config.a: no such file or directory
go install github.com/jabong/florest/src/common/utils/responseheaders: open 
/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.
com/jabong/florest/src/common/utils/responseheaders.a: no such file or 
directory
go install github.com/jabong/florest/src/service: open /var/folders/lp/
3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build823644730/github.com/jabong/florest
/src/service.a: no such file or directory


Can some one let me know why this is failing? This is working perfectly 
fine on Ubuntu.

   - Go Lang Version - 1.6.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: A proposal for generic in go

[Henry]

I am not saying that generics is bad, but I am questioning whether generics 
is necessary.


On Tuesday, June 21, 2016 at 3:45:08 PM UTC+7, andrew...@gmail.com wrote:

> >> I was one of the generics supporters for Go in this forum, but now I am 
> not so sure.
>
> But why?
> Generic types is the same types as and the regular types.
> Difference only in that the regular types does not have a parameters but 
> generic types are always have at least one parameter.
> This is why they are called generic (universal) types.
> The same as you don't worry about that the function can have a parameters 
> why you should worry about that the type can have a parameters?
> When for types allowed to have parameters then this get a some benefits:
> 1. Generice types can be "configured" by some requirements (by their 
> parameters)
> 2. Generice types can have a restrictions (eg. each parameter can have its 
> own upper type bounds)
> 3. Generic types are universal types
>
> Eg. Trivial example
>
> type KeyValuePair struct {
>   key K
>   val V
> }
>
> You can use this type everywhere since it is universal type.
>
> Below is not the same type (because in generic type system K != V, but 
> here interface{} == interface{}):
>
> type KeyValuePair struct {
>   key interface{}
>   val interface{}
> }
>
> Because power of the generic types in that the they are variative:
> - Covariant
> - Contrvariant
> - Invariant
>
> And they, of course, can have a parameters.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: [?] emulating an opengl shader in cpu bound functions

[Egon]

On Tuesday, 21 June 2016 12:50:16 UTC+3, Egon wrote:
>
>
>
> On Monday, 20 June 2016 18:02:53 UTC+3, blue...@gmail.com wrote:
>>
>>
>> 
>>
>> I am attempting to generate a random starfield, in go. This is something 
>> that will need to printed on actual paper, but that is another issue and I 
>> only mention it to give some context for what I am doing here: Using go to 
>> create graphics to pair with something I'm already doing in go (I've been 
>> through several iterations of trying to use the go parts I have with 
>> numerous variations of tex/latex templates using asymptote, and I reached a 
>> point of frustration where I figured why not just do it all in go, as it 
>> seems less a problem than I originally thought -- but opens a new set of 
>> problems to solve, one of the biggest is that I know nothing at all about 
>> graphics, let alone how to apply graphics in go).
>>
>> Cosmic1 from:  
>> https://gist.github.com/thrisp/1ed1785ac6a902585595fb8cb52f0a16, 
>> generates the above it is the first thing that even roughly approximates 
>> what I want to do.
>>
>> Any thoughts, or help cleaning that up. Maybe tell me why exactly I can't 
>> directly translate an opengl shader to something cpu bound(which I suspect 
>> is a thing, I may need to do more that I can't see right now).
>>
>
> As for the current code:
>
> Here you are picking a random rotation for each pixel:
> a1 := .5 + float64(float64(mr.Intn(size.X))/3)/float64(mr.Intn(size.X))*2
> a2 := .8 + float64(float64(mr.Intn(size.X))/2)/float64(mr.Intn(size.Y))*2
>
> This can change for every pixel (in shader the time is a constant for one 
> frame):
> time := float64(time.Now().UTC().Unix())*speed + 0.25
>
> In func toUint8(in float64) uint8 { you need to clamp the value between 0 
> and 255, otherwise the conversion overflows.
>
> Color adjusting code doesn't match the shader code.
>
> I suspect there are further issues in the iteration code.
>
> PS: often with such fragments you can simplify code and achieve a similar 
> result with less details, e.g. 
> https://gist.github.com/egonelbre/b5f41ac8946e609ce1a944631dd462ef
>

Here's the minimal code for doing that: 
https://gist.github.com/egonelbre/811d37e94dda69b6d92365a7e63a2eec 

+ Egon

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[andrew . mezoni]

>> I was one of the generics supporters for Go in this forum, but now I am 
not so sure.

But why?
Generic types is the same types as and the regular types.
Difference only in that the regular types does not have a parameters but 
generic types are always have at least one parameter.
This is why they are called generic (universal) types.
The same as you don't worry about that the function can have a parameters 
why you should worry about that the type can have a parameters?
When for types allowed to have parameters then this get a some benefits:
1. Generice types can be "configured" by some requirements (by their 
parameters)
2. Generice types can have a restrictions (eg. each parameter can have its 
own upper type bounds)
3. Generic types are universal types

Eg. Trivial example

type KeyValuePair struct {
  key K
  val V
}

You can use this type everywhere since it is universal type.

Below is not the same type (because in generic type system K != V, but here 
interface{} == interface{}):

type KeyValuePair struct {
  key interface{}
  val interface{}
}

Because power of the generic types in that the they are variative:
- Covariant
- Contrvariant
- Invariant

And they, of course, can have a parameters.

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

[Krzysztof Kowalczyk]

My guess is that's because Mac filesystem is case preserving but not 
case-sensitive, meaning that in mac os "floRest" and "florest" is the same 
file/directory while on linux those are 2 distinct files. (you can 
configure mac filesystem to be case-sensitive as well, but that's not the 
default).

As you can see in the logs:

mv $WORK/github.com/jabong/floRest/src/examples.a
 /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/floRest/src/examples.a

mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/

cp $WORK/github.com/jabong/florest/src/examples.a
 /Users/debraj/golang/pkg/darwin_amd64/
github.com/jabong/florest/src/examples.a

go install github.com/jabong/florest/src/examples: open 
/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426/
github.com/jabong/florest/src/examples.a: no such file or directory


a file "floRest/src/examples.a" is moved and then there's an attempt to 
copy "florest/src/examples.a", which is the same file on mac os, and it's 
no longer there.


The question is why do you have "florest" and "floRest" packages in your 
code. Are those 2 different packages? Did you make a typo in an import 
statement?


-- kjk


On Tuesday, June 21, 2016 at 8:16:26 AM UTC-7, DM wrote:
>
> Below is the ouput using the -x flag:-
>
> jabongs-MacBook-Pro-4:florest debraj$ go get -x ./...
>
> WORK=/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426
>
> mkdir -p $WORK/github.com/jabong/floRest/src/examples/_obj/
>
> mkdir -p $WORK/github.com/jabong/floRest/src/
>
> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/examples
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/floRest/src/examples.a -trimpath $WORK -p 
> github.com/jabong/floRest/src/examples -complete -buildid 
> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
> github.com/jabong/floRest/src/examples -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go 
> ./hello_world_multipe_errors.go ./swagger.go
>
> mkdir -p $WORK/github.com/jabong/floRest/src/service/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/
>
> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/service
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/floRest/src/service.a -trimpath $WORK -p 
> github.com/jabong/floRest/src/service -complete -buildid 
> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
> github.com/jabong/floRest/src/service -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go 
> ./business_logic_executor.go ./config_manager.go ./constants.go 
> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go 
> ./init_manager.go ./monitor_helper.go ./service_register.go 
> ./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go 
> ./web_server.go
>
> cd /Users/debraj/golang/src/github.com/jabong/florest/src/examples
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/examples.a -trimpath $WORK -p 
> github.com/jabong/florest/src/examples -complete -buildid 
> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/examples -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go 
> ./hello_world_multipe_errors.go ./swagger.go
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/cachestrategy/_obj/
>
> mkdir -p $WORK/github.com/jabong/florest/src/examples/
>
> cd /Users/debraj/golang/src/
> github.com/jabong/florest/src/examples/cachestrategy
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/examples/cachestrategy.a -trimpath $WORK -p 
> github.com/jabong/florest/src/examples/cachestrategy -complete -buildid 
> c16efba4536c81f8b5b9f0090f909c0b3c71383c -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/examples/cachestrategy -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go 
> ./cache_strategy_user.go ./sample_db_adapter.go
>
> mkdir -p $WORK/github.com/jabong/florest/src/service/_obj/
>
> cd /Users/debraj/golang/src/github.com/jabong/florest/src/service
>
> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
> github.com/jabong/florest/src/service.a -trimpath $WORK -p 
> github.com/jabong/florest/src/service -complete -buildid 
> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
> github.com/jabong/florest/src/service -I $WORK -I 
> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go 
> ./business_logic_executor.go ./config_manager.go ./constants.go 
> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go 
> ./init_manager.go ./monitor_helper.go 

[go-nuts] Re: A proposal for generic in go

[Matt Ho]

I think I have to agree with most of the posters here about generics.  In 
theory, I miss them.  However, in practice, I find that there are usually 
only a few times during the course of a project where I wish I had 
generics.  And then after writing a few lines of code to do what the 
generic would have done, I find I stop missing them.  

M



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

[Hoping White]

Thanks for all the replies. I agree that there is a better way to do the 
security jobs. I ask this question just for curiosity, to find out if there is 
a equivalence way to do this in golang. From all the replies I assume there is 
a no.

> 在 2016年6月21日，下午10:39，Matt Harden  写道：
> 
> It's generally a bad idea to try to improve security by hiding args. Much 
> better to pass the argument another way, for instance via an open file 
> descriptor that the program reads the value from.
> 
> 
> On Tue, Jun 21, 2016, 07:16 Hoping White  > wrote:
> Hi, all
> 
>I wonder is there a way to hide command line arguments from programs like 
> “ps”？ I can rewrite argv parameter for main in c language, or use LD_PRELOAD 
> to intercept libc_start_main, but all these methods do not be functional in 
> go. 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] Re: A proposal for generic in go

[andrew . mezoni]

>> perfectly type safe.

Perfectly type safe but not perfectly reusable.

What If we slightly complicate the task?

Now is my code and I want to see on your code exampe (perfectly type safe 
but and perfectly reusable)

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

['Axel Wagner' via golang-nuts]

You are not bringing anything new to the table here, except the attempt to
insult my intelligence, apparently.

There are huge software projects out there written in languages that are
less type safe than go and the vast majority of code written is not
reusable. Both also aren't absolutes. There is no binary "type safe or not
type safe" and no "reusable or not reusable". There are only more or less
expressive type systems and there are only pieces of code that are easier
or harder to reuse. Every language finds their own tradeoff for them and
every programmer must find their own preferences for the tradeoffs they
require. go is explicitly designed as an engineering language and the
defining characteristic of engineering is the acknowledgment of tradeoffs.
So, without acknowledging that this needs to be a tradeoff, there really is
not much point in talking about how to improve go. If someone prefers the
extreme, might I suggest agda instead of go? I don't know of a more type
safe language out there.

On Wed, Jun 22, 2016 at 10:11 AM,  wrote:

> We continue the discussion about the dangers of `to be both type safe
> *and* reusable`?
>

That is not what I was saying. I was talking about the dangers of generics
for producing clear and readable code. That is not an issue with being
both, it's an issue with generics. "It needs to be both" just isn't a very
good argument in favor of them.


> Me and most of us MUST focusing our energy on writing high quailty and
> reusable software.
>

Instead, we seem to focus your energy on debating whether we need to add
generics to go or not. There are people out there writing high quality and
reusable software *right now*, both in go and not in go. Coincidentally,
that's what I'm going to do now too.


> Want write software only for himself? Not a problem, your energy are your
> energy.
>

I get paid to write and maintain large software in large teams, in many
languages falling into very different spots on the scale of type safety and
re-usability and my opinions are informed by that. You shouldn't presume
that people disagree with you because they know less.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[andrew . mezoni]

Sorry for typo and possible spam but correct example here:

type Foo interface {
  Get(key K) V
  Set(key K, val V)
}
func foo() (int, Foo) {

  // Typo: foo := {}
  foo := {}
  // ...
  foos := []Foo{}
  // ...
  k := "London"
  // ...
  return 55, foo2(foos, 55, k)
}
// This code is type safe and reusable
foo2 (foos []Foo, i int, key K) (V, Foo) {
  foo := foos[i]
  return foo.Get(key), foo
}



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[andrew . mezoni]

>> You are not bringing anything new to the table here, except the attempt 
to insult my intelligence, apparently.
>
>
I do not have any claims to anyone personally.
I only defend my own point of view.

P.S.

Also I don't love to see or use some (not my own) code which written like a 
mess.
If I cannot understand some code then this does not means that this code is 
bad.

But if I know that a some code has been written carelessly and can be 
written more diligently then it gives me a negative reaction on that work 
(if there was no reason to write it carelessly).

That is, write code once and and use it everywhere.
Or more precisely, write (high quality and reusable) code once and and use 
it everywhere (and give the possibility to use it to everyone).

The generics programming are very good suit for that.

In the simplest definition, *generic programming* is a style of computer 
programming  in which 
algorithms are written in terms of types *to-be-specified-later* that are 
then *instantiated* when needed for specific types provided as parameters 
. 

The term *generic programming *describes a programming paradigm whereby 
fundamental requirements on types are abstracted from across concrete 
examples of algorithms and data structures and formalised as concepts, with 
generic functions implemented in terms of these concepts, typically using 
language genericity mechanisms as described above.

P.S.

I am sorry but here we discuss mostly about the advantages and 
disadvantages of the generic programming (of course, in Go language).
Here we do not discuss: How to coding in Go language without generic 
programming.
I think that it should be different topic with appropriate title.

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

[Debraj Manna]

Thanks Krzysztof that was the issue. For cloning the repo I used:-

git clone https://github.com/jabong/florest/

So in mac my code checked out in a directory florest. But the actual repo
name was https://github.com/jabong/floRest/ and in code it was referenced as
floRest which was causing the issue.

On Wed, Jun 22, 2016 at 8:18 AM, Krzysztof Kowalczyk 
wrote:

> My guess is that's because Mac filesystem is case preserving but not
> case-sensitive, meaning that in mac os "floRest" and "florest" is the same
> file/directory while on linux those are 2 distinct files. (you can
> configure mac filesystem to be case-sensitive as well, but that's not the
> default).
>
> As you can see in the logs:
>
> mv $WORK/github.com/jabong/floRest/src/examples.a
>  /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/floRest/src/examples.a
>
> mkdir -p /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/florest/src/
>
> cp $WORK/github.com/jabong/florest/src/examples.a
>  /Users/debraj/golang/pkg/darwin_amd64/
> github.com/jabong/florest/src/examples.a
>
> go install github.com/jabong/florest/src/examples: open
> /var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426/
> github.com/jabong/florest/src/examples.a: no such file or directory
>
>
> a file "floRest/src/examples.a" is moved and then there's an attempt to
> copy "florest/src/examples.a", which is the same file on mac os, and it's
> no longer there.
>
>
> The question is why do you have "florest" and "floRest" packages in your
> code. Are those 2 different packages? Did you make a typo in an import
> statement?
>
>
> -- kjk
>
>
> On Tuesday, June 21, 2016 at 8:16:26 AM UTC-7, DM wrote:
>
>> Below is the ouput using the -x flag:-
>>
>> jabongs-MacBook-Pro-4:florest debraj$ go get -x ./...
>>
>> WORK=/var/folders/lp/3q9_2mn51hd9s4yj_jcf3jxmgp/T/go-build665863426
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/examples/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/examples
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/floRest/src/examples.a -trimpath $WORK -p
>> github.com/jabong/floRest/src/examples -complete -buildid
>> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
>> github.com/jabong/floRest/src/examples -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go
>> ./hello_world_multipe_errors.go ./swagger.go
>>
>> mkdir -p $WORK/github.com/jabong/floRest/src/service/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/floRest/src/service
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/floRest/src/service.a -trimpath $WORK -p
>> github.com/jabong/floRest/src/service -complete -buildid
>> f55b565340e2d0d690f5de8bd424fffb8895a331 -D _/Users/debraj/golang/src/
>> github.com/jabong/floRest/src/service -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_interface.go
>> ./business_logic_executor.go ./config_manager.go ./constants.go
>> ./dynamic_config_manager.go ./health_checker.go ./http_response_creator.go
>> ./init_manager.go ./monitor_helper.go ./service_register.go
>> ./service_version_helper.go ./service_workflow_data.go ./uri_interpreter.go
>> ./web_server.go
>>
>> cd /Users/debraj/golang/src/github.com/jabong/florest/src/examples
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/florest/src/examples.a -trimpath $WORK -p
>> github.com/jabong/florest/src/examples -complete -buildid
>> febe48d3c570d8539844891977fbdc206dc458b4 -D _/Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./data_structures.go ./hello_world.go ./hello_world_health_checker.go
>> ./hello_world_multipe_errors.go ./swagger.go
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/cachestrategy/_obj/
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/examples/
>>
>> cd /Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples/cachestrategy
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> github.com/jabong/florest/src/examples/cachestrategy.a -trimpath $WORK
>> -p github.com/jabong/florest/src/examples/cachestrategy -complete
>> -buildid c16efba4536c81f8b5b9f0090f909c0b3c71383c -D
>> _/Users/debraj/golang/src/
>> github.com/jabong/florest/src/examples/cachestrategy -I $WORK -I
>> /Users/debraj/golang/pkg/darwin_amd64 -pack ./api_definition.go
>> ./cache_strategy_user.go ./sample_db_adapter.go
>>
>> mkdir -p $WORK/github.com/jabong/florest/src/service/_obj/
>>
>> cd /Users/debraj/golang/src/github.com/jabong/florest/src/service
>>
>> /usr/local/go/pkg/tool/darwin_amd64/compile -o $WORK/
>> 

Re: [go-nuts] Re: A proposal for generic in go

['Axel Wagner' via golang-nuts]

And my point is and was: It doesn't *need* to be both type safe *and*
reusable, unless you are focusing your energy on writing frameworks or
treating type safety as a goal solely for it's own sake. It's perfectly
fine to write small stuff yourself (for example like this) with explicit
types and it's perfectly fine to locally not have strict compiler checks if
you are doing something complicated that needs to be reusable. If you focus
on application writers, instead of the authors of the frameworks they might
use, you'll recognize that either choice just isn't that bad.

On Wed, Jun 22, 2016 at 9:36 AM,  wrote:

> >> perfectly type safe.
>
> Perfectly type safe but not perfectly reusable.
>
> What If we slightly complicate the task?
>
> Now is my code and I want to see on your code exampe (perfectly type safe
> but and perfectly reusable)
>
> type Foo interface {
>   Get(key K) V
>   Set(key K, val V)
> }
> func foo() (int, Foo) {
>   foo := {}
>   // ...
>   foos := []Foo{}
>   // ...
>   k := "London"
>   // ...
>   return 55, foo2(foos, 55, k)
> }
> // This code is type safe and reusable
> foo2 (foos []Foo, i int, key K) (V, Foo) {
>   foo := foos[i]
>   return foo.Get(key), foo
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Bakul Shah]

That can be dealt with an output format. Just as the hex or octal or the "e" 
input format is lost.

With respect to the "e" notation Go seems to be an exception. Perhaps the sole 
one? Other prog languages I have used treat eas a floating pt. even 
in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a float. I 
find 1_000_000 clearer than 1e6. Not a big deal either way.

> On Jun 22, 2016, at 8:17 AM, Michael Jones  wrote:
> 
> Sorry, I sent that too soon. 
> 
> One argument against underscores in numbers and other discardable syntax is 
> the tooling in Go to parse and regenerate go code, as in gofmt. It may be 
> more complicated to keep the “original input format” around and that is a 
> pretty good argument—unless that is already there for input values in hex.
> 
> Michael Jones
> michael.jo...@gmail.com
> 
>>> On Jun 22, 2016, at 8:14 AM, Michael Jones  wrote:
>>> 
>>> https://github.com/golang/go/issues/42
>> 
>> Michael Jones
>> michael.jo...@gmail.com
>> 
>>> On Jun 22, 2016, at 7:29 AM, Roger Pack  wrote:
>>> 
>>> Could you drop me a link to the discussion by chance? Seems this
>>> feature is actually a reasonably common request :)
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Andy Balholm]

The same is true of brace styles :-P.

But my point is that by not allowing digit grouping, Go avoids style debates on 
that issue. The grouping could have been standardized with gofmt, but as it is, 
it is standardized by the compiler to a format that is universally understood 
(no grouping).

Andy

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Jan Mercl]

On Wed, Jun 22, 2016 at 5:54 PM Bakul Shah  wrote:

That can be dealt with an output format. Just as the hex or octal or the
"e" input format is lost.

> ... in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a
float.

The literals 1e6 and 1e-6 are both untyped floating point constants.


-- 

-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] feature request: allow literal digit underscore grouping

[Jan Mercl]

On Wed, Jun 22, 2016 at 5:56 PM Andy Balholm  wrote:

> The same is true of brace styles :-P.

Brace style is a matter of preference. Wrong digit grouping in a given
place on Earth is wrong, not less preferred.

-- 

-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] Getting a pointer in a type switch gives a *interface {} if case lists several options

[Marvin Renich]

* raidopah...@gmail.com  [160621 18:02]:
> I have encountered some unexpected and inconsistent behavior with type 
> switches. Can someone shed some light as to why Go behaves this way?
> 
> Take a look at https://play.golang.org/p/YPV5YPtWF8
> 
> I would expect both of the switches to behave the same way, but for some 
> reason the one with multiple options in the case ends up with a pointer to 
> an interface and the one with just one option ends up with a pointer to the 
> correct type.

(Aside: reusing the variable t makes it harder to discuss specific
instances of that variable.  I am pasting your code here with variable
name changes.)

package main

import "fmt"
import "reflect"

func main() {
var v uint8 = 0
var t interface{} = v
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(v), reflect.TypeOf()))
switch w := t.(type) {
case uint8:
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(w), 
reflect.TypeOf()))
}
switch x := t.(type) {
case uint8, int8:
fmt.Println(fmt.Sprintf("%s %s", reflect.TypeOf(x), 
reflect.TypeOf()))
}
}

The compiler must know, at compile time, what type w and x are
everywhere except in the switch expression itself.  For w in the "case
uint8" clause, the type of w is known to be uint8.  For x in the "case
uint8, int8" clause, it cannot be determined whether x will be uint8 or
int8, so the compiler must use interface{} so that it can generate a
single block of code that works for both possible case types.

If you use different case clauses for the different types, you will get
what you expected.  (I.e. add a separate "case int8:" to the first
switch statement.)

...Marvin

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

Re: [go-nuts] specific file cannot build

[indev]

Thank you very much.
I understand that _arm.go file means DO BUILD ONLY ARM PROCESSOR.

2016년 6월 22일 수요일 오후 9시 39분 25초 UTC+9, Jan Mercl 님의 말:
>
> On Wed, Jun 22, 2016 at 2:32 PM  wrote:
>
> > How this "magic" can be occurred?
>
> The magic is described here: 
> https://golang.org/pkg/go/build/#hdr-Build_Constraints
>
> -- 
>
> -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] feature request: allow literal digit underscore grouping

[Manlio Perillo]

Il giorno martedì 21 giugno 2016 18:35:13 UTC+2, Caleb Spare ha scritto:
>
> This was shut down without much discussion at 
> https://github.com/golang/go/issues/42. 
>
> I agree that it's a nice feature. 
>
> By the way, though, one nice aspect of Go is that because of how 
> untyped constants work you can write integers using scientific 
> notation: 
>
> for i := 0; i < 10e6; i++ { 
> // ... 
> } 
>
> This is exactly the same as if you had written 1000. 
>
> (I don't think you'd want to do this in C or Java


I would not do this even in Go, since it makes the code less readable IMHO.

> [...]


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: A proposal for generic in go

[Viktor Kojouharov]

On Tuesday, June 21, 2016 at 9:56:01 PM UTC+3, Axel Wagner wrote:
>
> The issue is, that a "KeyValuePair" (no matter if you implemented it 
> via generics or like you mention via interfaces) is a fundamentally useless 
> type and generics encourage people to add useless types. A "KeyValuePair V>" is a "struct { Key K, Value V }", plain and simple. It's not an 
> interface and it's not a generic type, it's simply a struct.
>

And yet the 'K' and 'V' within the struct are generic types. A struct is 
never simple. That's its whole point.
 

>
> I agree, that generics are useful, but they seem to be mainly useful for 
> people who write "frameworks", not so much for people who write 
> "applications" and so far, go is pretty much a language for the latter. 
> Whenever people try to justify generics, they do it from a "I want to write 
> a framework" POV - and whenever I miss generics, I do because I'm currently 
> writing a framework of some kind.
>

A lot of these 'applications' that you think are the language's main target 
are built on top of libraries, including stdlib, written by that same 
language. And these same libraries can benefit from having generics, once 
again, including stdlib.
 

>
> Generics empower abstractions, but most programmers are very bad at 
> building abstractions, so if you make it easy to build abstractions, you 
> will end up with a lot of bad abstractions (have a look at java). So, to a 
> certain degree, the value of go is, to *not* make building abstractions 
> overly simple. That leads to abstractions being used only where they are 
> essential and being left out where they are superfluous. This is where 
> reduced cognitive overhead comes into play - limiting the levels of 
> abstractions that people need to deal with to the bare essentials. Java is 
> bloated and hard to use, not because the language is bad, but because it 
> has a history of programmers building bad abstractions into it which gets 
> stacked on top of each other. So, yes, if you compare a bad abstraction 
> using interfaces with a bad abstraction using generics, generics will, in 
> general, compare very well. But you just shouldn't build the bad 
> abstraction in the first place.
>

I've found this type of thinking quite poisonous. The "lets bereave 
ourselves of something universally lauded as useful, because it _might_ be 
used in the wrong manner by some people" mentality is just wrong and 
prevents any kind of useful evolution under any context. 
 

>
> The second concern with complexity is the spec. The exact behavior and 
> semantics of generics need to be spec'ed and useful generics need a lot 
> specification. For example, the current rules for type inference can be 
> understood completely just by looking at a single expression and it's type 
> and it's correspondingly simple to implement and spec. Generics usually 
> need more powerful type inference methods to not be cumbersome, which will 
> take up a lot of space in the spec. As humans, just like computers, have 
> very little memory, the time it takes to understand the spec will grow 
> superlinear with the length of it, due to frequent cache misses, so a long 
> spec will significantly increase the time needed to learn the language. In 
> the same vein, to understand a language, you need to know about 
> interactions between it's different concepts, not just the concepts itself, 
> so the needed space and time complexity to learn a language also grows 
> quadratic in the number of concepts in the language (in general). All of 
> that contributes to why people are wary of adding new concepts to go - the 
> costs in terms of understanding and learning the language are huge and they 
> grow very much superlinear in the number of concepts added, so each added 
> concept must be carefully examined (I know go for years and I still learn 
> new things about interactions between different concepts all the time).
>

And yet this hasn't stopped people from successfully learning and utilizing 
languages that have generics are part of their specifications. The fact 
still remains that unlike a lot of other proposed languages additions that 
are immediately dropped, generics are still open for discussion by the 
language developers themselves. 

>
>
> I sometimes miss generics, yes, but I also believe adding them will make 
> the language significantly harder to learn and will significantly worsen 
> the quality of go code in the wild, so it would likely eliminate the 
> reasons I like go currently (which is that go code is usually of 
> exceptionally high quality, uniform and easy to understand).
>

I'm sorry, but that's just fearmongering. Unless you have some kind of 
magic crystal ball, there's now way you'd know how the quality of go code 
will change. You don't even know what the implementation will look like ...
 

>
> On Tue, Jun 21, 2016 at 5:06 PM,  
> wrote:
>
>> >> What I mean is that most people who have 

Re: [go-nuts] Re: Go 1.6.1 Link problem on Windows:

[Dorival Pedroso]

oh, bad news... I was expecting this to be fixed in 1.7...

On Wed, Jun 22, 2016 at 10:33 PM  wrote:

> I am having the same issues with go1.6.2... I also tried go1.7beta2 with
> no luck.
> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>
> c:/program files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin
> /../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib
> /../lib/libntdll.a(dmads01971.o):(.idata$5+0x0): multiple definition of
> `__imp_sqrt'
> c:/program
> files/mingw-w64/x86_64-4.8.1-posix-seh-rt_v3-rev2/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/lib/../lib/libmsvcrt.a(dygcs01179.o):(.idata$5+0x0):
> first defined here
>
>
>
> On Wednesday, April 20, 2016 at 7:06:28 PM UTC-7, Dorival Pedroso wrote:
>>
>> Hi,
>>
>> I'm just wondering what is the cause of the following error (multiple
>> definition of __something)?
>> C:\Go\pkg\tool\windows_amd64\link.exe: running gcc failed: exit status 1
>> C:/TDM-GCC-64/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libntdll.a(dyyls01966.o):(.idata$5+0x0):
>> multiple definition of `__imp_pow'
>>
>> This only happens on Windows10 but on Ubuntu/Linux.
>>
>> The Go code makes a call to LAPACK via a C interface as follows:
>> package main
>>
>> /*
>> #cgo CFLAGS: -O3
>> #cgo linux   LDFLAGS: -lm -llapack -lgfortran -lblas
>> #cgo windows LDFLAGS: -lm -llapack -lgfortran -lblas -LC:/GoslDeps/lib
>>
>> #include 
>>
>> void dgesvd_(const char* jobu, const char* jobvt, const int* M, const
>> int* N, double* A, const int* lda, double* S, double* U, const int* ldu,
>> double* VT, const int* ldvt, double* work,const int* lwork, const int*
>> info);
>>
>> int lapack_svd(double *U, double *S, double *Vt, long m_long, double *A) {
>> int m = (int)(m_long);
>> int info  = 0;
>> charjob   = 'A';
>> int lwork = 10*m;
>> double* work  = (double*)malloc(lwork*sizeof(double));
>> dgesvd_(,   // JOBU
>> ,   // JOBVT
>> , // M
>> , // N
>> A,  // A
>> , // LDA
>> S,  // S
>> U,  // U
>> , // LDU
>> Vt, // VT
>> , // LDVT
>> work,   // WORK
>> , // LWORK
>> ); // INFO
>> free(work);
>> return info;
>> }
>> */
>> import "C"
>>
>> import (
>> "fmt"
>> "math"
>> "unsafe"
>> )
>>
>> func main() {
>> A := []float64{1, 2, 3, 2, -4, -9, 3, 6, -3} // col-major format
>> m := int(math.Sqrt(float64(len(A
>> I := func(i, j int) int { return j*m + i }
>> printmat(m, A, "A")
>> U := make([]float64, len(A))
>> S := make([]float64, len(A))
>> Vt := make([]float64, len(A))
>> info := C.lapack_svd(
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (*C.double)(unsafe.Pointer([0])),
>> (C.long)(m),
>> (*C.double)(unsafe.Pointer([0])),
>> )
>> fmt.Printf("SVD: info = %d\n", info)
>> USVt := make([]float64, len(A))
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> for k := 0; k < m; k++ {
>> USVt[I(i, j)] += U[I(i, k)] * S[k] * Vt[I(k, j)]
>> }
>> }
>> }
>> printmat(m, USVt, "U*S*Vt")
>> }
>>
>> func printmat(m int, M []float64, msg string) {
>> fmt.Printf("%s =\n", msg)
>> for i := 0; i < m; i++ {
>> for j := 0; j < m; j++ {
>> fmt.Printf("%13.8f", M[j*m+i])
>> }
>> fmt.Println()
>> }
>> }
>>
>> Any help is much appreciated.
>>
>> Cheers.
>> Dorival
>>
> --
> 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/fW4KZQ05G_8/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.
>
-- 

Dorival Pedroso PhD +61 0420411142 www.cpmech.com Brisbane Australia

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

[indev]

Hi. I have a question about relation between building source code and its 
filename.

When I try to build with *store_arm.go* file, I cannot build(compiler 
ignore this file).

But after *just change filename of same source code*, it is built.

How this "magic" can be occurred?









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

[tu . pham]

I think that the idea of Goroutine come from 
[https://en.wikipedia.org/wiki/Coroutine], the number of Goroutines are 
mapped to OS Threads. In my own opinion, Go maintain the Thread pool and 
task queue to dispatch the job.

This pattern has been implemented in some modern JEE container.
Hope that the answer 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] Re: ANN: GoFlow - Flow-based programming package for Go

[liewjoee]

Hello Vladimir,
Is there any further developement on goflow? I see that it has last updated 
since Nov 7, 2015.

Are there any further intergration in goflow with noflo-ui?  

On Tuesday, February 14, 2012 at 4:18:23 AM UTC+10:30, Vladimir Sibirov 
wrote:
>
> I'm glad to announce GoFlow package:
> https://github.com/trustmaster/goflow
>
> It provides a framework that lets you build Go applications in 
> flow-based/dataflow/reactive programming style. A flow-based program is a 
> graph of components which run in parallel and communicate by sending 
> information packets through channels. You could surely achieve the same 
> effect by writing plain Go code, but Flow-based programming (FBP) 
> distinguishes 2 viewpoints in programming:
>  - Graph view - what components the program consists of and how they are 
> connected to each other. This is similar to DFD/SADT and is preferably 
> represented by visual diagrams.
>  - Component view - what inputs and outputs a component has and how it 
> processes data. This viewpoint is focused on smaller entities which 
> implement one specific function and the actual data processing code.
>
> I'd describe major goals of Flow-based programming paradigm in general 
> this way:
>  * Concurrency by design, not by purpose. Operate with entities which work 
> in parallel and share by communication by default.
>  * Unified approach in software development from domain analysis and 
> architecture to coding. Start with diagrams and data flows and continue the 
> structural breakdown until you reach data processing algorithms.
>  * Practices of hardware engineering mapped to software development world. 
> Some say software could be as reliable as hardware if it was built in a 
> similar way :)
>  * Active use of visual diagrams. Human beings are likely to understand 
> high-level things from diagrams easier.
>
> Unfortunately GoFlow isn't capable of running visual diagrams yet. 
> Currently this package does the following:
>  * Turns your Go structs into FBP components and graphs.
>  * Enables you to program components in event-driven way.
>  * Lets you make networks consisting of process and other networks.
>  * Provides a runtime that makes it work alltogether.
>
> More information can be found on project page and wiki.
>
> Looking forward to hearing from dataflow enthusiasts from the Go community.
>
> Vladimir.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[Andrew Mezoni]

>> The version without generics is necessary to compare how well a 
particular generics approach improves the current language and code.

I am sorry but this is obviously that any useful feature (in the context of 
solving problems) improves the current language and code.
Another question: how new (version of the) language will look cosmetically 
with this newly added feature.

I found that the second question here more important then the first.

It is obviously correct that the code with a generics (in appropriate 
place) would be more useful then other code.
But here I undestand one interesting thing which states: Some obviously 
useful feature can significantly spoil the overall picture of language.

For me this is very strange only because even a C language also has been 
improved after when it initially was introduced.

In the years following the publication of K C, several features were 
added to the language, supported by compilers from AT and some other 
vendors. These included:

   - void  functions (i.e., 
   functions with no return value)
   - functions returning struct 
    or union 
    types (rather 
   than pointers)
   - assignment 
    for struct 
data 
   types
   - enumerated types 


C99 introduced several new features, including inline functions 
, several new data types 
 (including long long int and a 
complex type to represent complex numbers 
), variable-length arrays 
 and flexible array 
members , improved 
support for IEEE 754  floating 
point, support for variadic macros 
 (macros of variable arity 
), and support for one-line comments 
beginning with //

The C11 standard adds numerous new features to C and the library, including 
type generic macros, anonymous structures, improved Unicode support, atomic 
operations, multi-threading, and bounds-checked functions. 

P.S.

I guess I should think that this is very bad, because my first acquaintance 
with the language began with the ZX-Spetrum and continued with the Borland 
Turbo C.

Indeed, the C language is now looks much worse cosmetically than before. 
But should I regret it?
Maybe...

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[Andrew Mezoni]

>> The fact still remains that unlike a lot of other proposed languages 
additions that are immediately dropped, generics are still open for 
discussion by the language developers themselves. 

I think that the problerm only in the Go developers brcause them even does 
try to implement them experimentally.
That is so called "hidden" implementation when the runtime engine supports 
the feature but compiler does not.
That is, available for testing only through the reflection but without 
grammar specification on that how to declare and use time at compile time.
As for me, they should have them (support of the generic types) in the 
runtime engine and in the reflection for the testing purpose but does not 
introduce them until they not decide that them are ready for real use.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] feature request: allow literal digit underscore grouping

[Ian Lance Taylor]

On Wed, Jun 22, 2016 at 6:50 AM, Manlio Perillo
 wrote:
> On Wed, Jun 22, 2016 at 3:35 PM, Henrik Johansson  
> wrote:
>> Really?
>
> Yes.
> The problem is that many people coming from C like languages may
> incorrectly assume that i is a floating point number.

This doesn't strike me as a good reason to avoid writing numbers as
1e6 or whatever.  Go is a relatively simple language.  It's reasonable
to expect people using Go to learn the language.

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: A proposal for generic in go

[Egon]

On Wednesday, 22 June 2016 15:32:53 UTC+3, Andrew Mezoni wrote:
>
> >> The version without generics is necessary to compare how well a 
> particular generics approach improves the current language and code.
>
> I am sorry but this is obviously that any useful feature (in the context 
> of solving problems) improves the current language and code.
>

Yes.. Of course, this presupposes that the particular generics approach is 
useful.
How would you demonstrate that one generics approach is more useful than 
another?

Another question: how new (version of the) language will look cosmetically 
> with this newly added feature.
>
> I found that the second question here more important then the first.
>
> It is obviously correct that the code with a generics (in appropriate 
> place) would be more useful then other code.
>

Which generics approach?
Which places need that kind of generics?
Should the language solve all generics related problems or only some?
Are there better solutions to those problems than generics?
Would some meta-programming approach negate the need for generics?

Also, is "useful in some particular case" the best metric to decide whether 
something should be included in the language?

e*.g. #define max(a,b) ((a) < (b) ? (b) : (a))*

But here I undestand one interesting thing which states: Some obviously 
> useful feature can significantly spoil the overall picture of language.
>
> For me this is very strange only because even a C language also has been 
> improved after when it initially was introduced. 
>

Have you also looked at the proposals that were rejected? If someone made 
the proposal, it must have been useful to someone.

In the years following the publication of K C, several features were 
> added to the language, supported by compilers from AT and some other 
> vendors. These included:
>
>- void  functions (i.e., 
>functions with no return value)
>- functions returning struct 
>
> 
> or union  types 
>(rather than pointers)
>- assignment 
> for 
>struct data types
>- enumerated types 
>
> 
>
> Were there any competing proposal for those same feature sets? Why were 
the others rejected whereas these particular ones accepted?

Also, what if, instead functions just allowing returning struct/unions, it 
would have also allowed to return multiple parameters? Would that have 
resulted better or worse C code?
 

> C99 introduced several new features, including inline functions 
> ,
>  
> several new data types 
>  (including long long int and a complex type to represent complex numbers 
> ), variable-length arrays 
> 
>  and flexible array members 
> ,
>  
> improved support for IEEE 754  
> floating 
> point, support for variadic macros 
>  (macros of variable arity 
> ), and support for one-line comments 
> beginning with //
>
> The C11 standard adds numerous new features to C and the library, 
> including type generic macros, anonymous structures, improved Unicode 
> support, atomic operations, multi-threading, and bounds-checked functions. 
>
> P.S.
>
> I guess I should think that this is very bad, because my first 
> acquaintance with the language began with the ZX-Spetrum and continued with 
> the Borland Turbo C.
>
> Indeed, the C language is now looks much worse cosmetically than before. 
> But should I regret it?
> Maybe...
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[Sean Russell]

On Tuesday, June 21, 2016 at 10:29:37 AM UTC-4, Henry wrote:
> You still haven't provided any argument why generics is indispensable. 

That can't be the litmus for language feature inclusion; if it was, Go would 
resemble ASM. 

In my personal experience, something North of 50% of my non-trivial 
applications could have been more simple with some form of generics allowing me 
to reduce code duplication. In particular, any application dealing with 
demarshaling of data from a large set of similar functions (e.g. web calls) are 
good examples. Have 30 functions to make the same web calls and perform the 
same demarshaling calls -- especially where the web call may be more complex, 
as in a SOAP call -- does not make the code cleaner, easier to cognitively 
parse, or more safe. Indeed, in almost every such case, generics reduce code 
duplication and make the code safer from bugs, and easier to maintain.

Indispensable? That's subjective, and very few language features satisfy that 
requirement. For me, the strongest argument against it is that if the core Go 
team can't think of a way to implement it cleanly and efficiently, then I trust 
it's a hard problem. I'm sure they've looked at it; it must be the single most 
commonly requested, hashed-over, and proposal-backed feature.

--- SER

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

Re: [go-nuts] How to hide command line argument from ps

[Sean Russell]

On Tuesday, June 21, 2016 at 9:56:21 PM UTC-4, Lazytiger wrote:
> Thanks for all the replies. I agree that there is a better way to do the 
> security jobs. I ask this question just for curiosity, to find out if there 
> is a equivalence way to do this in golang. From all the replies I assume 
> there is a no.

Environment variables. github.com/namsral/flag implements a flags library that 
will populate flags from either command line args or environment variables at 
run time, and is a drop-in replacement for the standard flag library.

--- SER

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

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Henrik Johansson]

Really? I find that counting digits in large numbers is harder, for me at
least, than expected. The scientific notation is sweet.

On Wed, Jun 22, 2016, 14:57 Manlio Perillo  wrote:

> Il giorno martedì 21 giugno 2016 18:35:13 UTC+2, Caleb Spare ha scritto:
>>
>> This was shut down without much discussion at
>> https://github.com/golang/go/issues/42.
>>
>> I agree that it's a nice feature.
>>
>> By the way, though, one nice aspect of Go is that because of how
>> untyped constants work you can write integers using scientific
>> notation:
>>
>> for i := 0; i < 10e6; i++ {
>> // ...
>> }
>>
>> This is exactly the same as if you had written 1000.
>>
>> (I don't think you'd want to do this in C or Java
>
>
> I would not do this even in Go, since it makes the code less readable IMHO.
>
> > [...]
>
>
> 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] Go test to run over sub packages?

[John Souvestre]

Ø  Symlinks and the go tools should be avoided.

 

Was this done intentionally?  If so, why?  If not, is it a bug which should be 
fixed?

 

John

John Souvestre - New Orleans LA

 

From: golang-nuts@googlegroups.com [mailto:golang-nuts@googlegroups.com] On 
Behalf Of Dave Cheney
Sent: 2016 June 21, Tue 19:19
To: golang-nuts
Cc: gabriel.kop...@gmail.com
Subject: Re: [go-nuts] Go test to run over sub packages?

 

I'm sorry to say that that is bad advice. Symlinks and the go tools should be 
avoided.

On Wednesday, 22 June 2016 08:29:33 UTC+10, gabriel...@gmail.com wrote:

Hi Ian, thanks for the confirmation!

It turns out that the cause of this behavior is that I had followed the 
instructions at 
https://github.com/karlseguin/the-little-go-book/blob/9f95b4405760fe9d24d4f9b7da93889cc9306f58/en/go.md#getting-started
 and
symlinked thus: `$ ln -s ~/code/golang-workspace/src/github.com/foo/proj 
~/code/proj`

 

In a directory structure without the symlink, things work correctly :)

 

I'll file an issue on the Little Book of Go about this gotcha.

 

Gabe

 

 

On Tuesday, June 21, 2016 at 3:09:35 PM UTC-7, Ian Lance Taylor wrote:

On Tue, Jun 21, 2016 at 12:42 PM,   wrote: 
> Is `$ go test github.com/foo/proj/...`   
> really supposed to work? 

Yes. 

> When I run it I get 
> 
> warning: "github.com/foo/proj/..  ." matched no 
> packages 
> no packages to test 
> 
> But `cd src/github.com/foo/proj && go test ./...` does work as suggested. 

What is the value of your GOPATH environment variable? 

Ian 

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

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

Re: [go-nuts] feature request: allow literal digit underscore grouping

[Bakul Shah]

I should've realized go automatically coerced float constants to ints. Which is 
worse but never mind :-)

> On Jun 22, 2016, at 8:57 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> On Wed, Jun 22, 2016 at 5:54 PM Bakul Shah  wrote:
> 
> That can be dealt with an output format. Just as the hex or octal or the "e" 
> input format is lost.
> 
> > ... in Go there is a slight inconsistency: 1e6 is an int but 1e-6 is a 
> > float.
> 
> The literals 1e6 and 1e-6 are both untyped floating point constants.
> 
> 
> -- 
> -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] Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

I am trying to run a large number of tcp 
connects https://play.golang.org/p/lNGWD-q028. However I am getting a lot 
of i/o timeouts. Is this a know issue, or I am missing something.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

No real surprises with the no bounds checks option (-B), it just eliminated the 
array bounds checks with the rest of the code the same (version 1.7beta1):

0x00dd 00221 (main.go:37)   MOVQDI, CX
0x00e0 00224 (main.go:37)   SHRQ$5, DI
0x00e4 00228 (main.go:37)   MOVL(AX)(DI*4), R9
0x00e8 00232 (main.go:37)   MOVQCX, R10
0x00eb 00235 (main.go:37)   ANDQ$31, CX
0x00ef 00239 (main.go:37)   MOVLR8, R11
0x00f2 00242 (main.go:37)   SHLLCX, R8
0x00f5 00245 (main.go:37)   ORL R8, R9
0x00f8 00248 (main.go:37)   MOVLR9, (AX)(DI*4)
0x00fc 00252 (main.go:36)   LEAQ3(R10)(SI*2), DI
0x0101 00257 (main.go:37)   MOVLR11, R8
0x0104 00260 (main.go:36)   CMPQDI, DX
0x0107 00263 (main.go:36)   JLS $0, 221

It is now almost as fast as C/C++ code, and isn't for the same reasons as 
explained before:  excessively using registers to store things and not using 
the read/modify/write instruction (which also saves the use of a register).

The current beta will work not too badly with amd64 code but still doesn't use 
registers efficiently enough to support x86 code as it uses too many register.  
optimized C/C++ code only uses six or at most 7 registers, which the x86 
architecture has, but not the nine registers that the above requires.

So for this tight loop, golang is still slower than optimized C/C++ code, but 
not by very much if array bounds checks are disabled.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] [ANN] Mirror of Go SSA

[JW Bell]

>>I have to say that I don't see a big benefit to mirroring a github 
repo on github itself. 
There isn't another way to use the ssa package.

On Tuesday, June 14, 2016 at 10:15:19 PM UTC-7, Ian Lance Taylor wrote:
>
> On Tue, Jun 14, 2016 at 7:07 PM,   wrote: 
> > Mirror of the Go compiler SSA library -  https://github.com/bjwbell/ssa 
> > The mirror is automatically updated daily. 
> > 
> > Any feedback is welcome. I'm unsure on the licensing requirements for 
> > mirroring. 
>
> The license requirements in general are in the LICENSE file.  It's no 
> different from mirroring than for any other use. 
>
> I have to say that I don't see a big benefit to mirroring a github 
> repo on github itself. 
>
> 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: Is syscall.Mmap broken? Or am I?

[Dave Mazzoni]

Wow. You all are incredible -- your suggestion nailed it. Now I'm getting:

 ./peekgo 0x43c0
mem[0]:0x3020100mem[1]:0x7060504mem[2]:0xb0a0908
mem[3]:0xf0e0d0c  ...

which is PERFECT. Thanks!


On Tue, Jun 14, 2016 at 6:05 PM, Ian Lance Taylor  wrote:

> On Tue, Jun 14, 2016 at 2:47 PM, Dave Mazzoni  wrote:
> >
> > Thanks for the suggestions. I'm a bit confused though since Mmap returns
> a
> > slice of bytes. I print all the bytes as you can see, but only the first
> > byte at each 32 bit boundary is correct. I don't know casting several of
> > them together would somehow derive the correct value.
>
> Because Mmap returns a []byte, every access using that []byte will
> load a single byte.  But device memory is often magic.  Doing a byte
> load and doing a word load are two very different things from the
> device's perspective.  So what we're suggesting is that you do
> something like
> b := syscall.Mmap(...)
> w := (*[1024]uint32)(unsafe.Pointer([0]))
> and then print w[0].  That will access the memory as a 32-bit word, not a
> byte.
>
> Or conversely change your C program to print out one byte at a time
> and see what you get.
>
> 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] Hi! I'm happy to announce the very first release of *nexer* 1.0.0b simple and easy to use and extend content based network multiplexer

[Diego Cena]

*nexer* is a simple and easy to use and extend content based network 
multiplexer (or redirector) 
made with love and golang.

Binaries: https://github.com/diegohce/nexer/releases/latest 

Source : https://github.com/diegohce/nexer 

Read the docs at https://github.com/diegohce/nexer/blob/master/README.md

Any question or comment is welcome here or in the project's issue tracker 
https://github.com/diegohce/nexer/issues 


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Is syscall.Mmap broken? Or am I?

[Dave Mazzoni]

You're too kind. Now I don't feel like an idiot.  Thanks again.

On Tue, Jun 14, 2016 at 6:17 PM, Dave Cheney  wrote:

> It helps if you've hit the same issue before :)
>
> On Wed, Jun 15, 2016 at 8:14 AM, Dave Mazzoni  wrote:
> > Wow. You all are incredible -- your suggestion nailed it. Now I'm
> getting:
> >
> >  ./peekgo 0x43c0
> > mem[0]:0x3020100mem[1]:0x7060504mem[2]:0xb0a0908
> > mem[3]:0xf0e0d0c  ...
> >
> > which is PERFECT. Thanks!
> >
> >
> > On Tue, Jun 14, 2016 at 6:05 PM, Ian Lance Taylor 
> wrote:
> >>
> >> On Tue, Jun 14, 2016 at 2:47 PM, Dave Mazzoni  wrote:
> >> >
> >> > Thanks for the suggestions. I'm a bit confused though since Mmap
> returns
> >> > a
> >> > slice of bytes. I print all the bytes as you can see, but only the
> first
> >> > byte at each 32 bit boundary is correct. I don't know casting several
> of
> >> > them together would somehow derive the correct value.
> >>
> >> Because Mmap returns a []byte, every access using that []byte will
> >> load a single byte.  But device memory is often magic.  Doing a byte
> >> load and doing a word load are two very different things from the
> >> device's perspective.  So what we're suggesting is that you do
> >> something like
> >> b := syscall.Mmap(...)
> >> w := (*[1024]uint32)(unsafe.Pointer([0]))
> >> and then print w[0].  That will access the memory as a 32-bit word, not
> a
> >> byte.
> >>
> >> Or conversely change your C program to print out one byte at a time
> >> and see what you get.
> >>
> >> 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: Getting a lot of i/o timeouts in Go 1.4

[Mayank Jha]

Tried with Go 1.5, the problem persists. And the IP I gave was for showing 
purposes. I actually used an IP of a node which is a part of a closed 
network, and ran it from another node in the same network.

On Thursday, June 16, 2016 at 1:44:56 PM UTC+5:30, Dave Cheney wrote:
>
> Go 1.4 isn't supported anymore, so you should upgrade.
>
> Maybe 8.8.8.8 is rate limiting you.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Golang Error - When marshelling data

[Konstantin Khomoutov]

On Thu, 16 Jun 2016 04:55:41 -0700 (PDT)
User123  wrote:

> Is it giving error since it has null values? 
> 
> I'm just not able to get it. Since this code works perfectly fine in
> 1.4.2

A wild guess:

1) Your error message is:

 json: unsupported type: <-chan struct {}

   and indeed the docs of encoding/json clearly state that certain
   types cannot be sensibly marshalled and unmarshalled.
   Channel types are among them.

2) Some value contained as a field of your value -- which is supposedly
   of some custom struct type -- started to contain a variable of type

 <-chan struct{}

   somewhere between 1.4.2 and 1.6.

   This might be not an immediate field of your struct-typed value
   but a field of a value which is an immediate field, and so on --
   deeper down the hierarchy -- because the json encoder is recursive.

Hence inspect what your value might clinge on which is not *pure data.*
Say, an http.Client instance is not pure data.

Once identified, make sure you convert your existing value you're
encoding to a value of some other type which contains nothing but pure
data values.

[...]
> > I did fmt.println on the data that I am trying to marshall and it
> > looks like this
> >
> > *%!(EXTRA main.JobResponseRoot={{92b4f95b309e8db0f8d56afadefc}
> > http.res {[{{  map[] }
> > "Date","Time","Time_Zone","Source","Name","Raw_Data"*
> > *  0x10a3c2d0}]}})*
[...]
> >>> The data  I am trying to marshal contains serialized data. This
> >>> data is received in http response.
> >>>
> >>> It works perfectly when I try in version 1.4.1/ 1.4.2.
> >>>
> >>> But when I try this to the latest version 1.6 it gives an error:
> >>> *json: unsupported type: <-chan struct {}*
[...]

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

[Rob Pike]

If you're testing a binary, go install will overwrite the installed
version, which is usually not what you want. In that case, go build makes
sense.

-rob


On Thu, Jun 16, 2016 at 1:17 AM, Dave Cheney  wrote:

> I don't understand why that flag even exists, if feels like a symptomatic
> misfeature. Just use go install -v, always*
>
> * except when cross compiling.
>
> On 16 Jun 2016, at 18:11, Harmen B  wrote:
>
> Or build with `go build -i`
>
> On Thu, Jun 16, 2016 at 1:52 AM, Hugh Emberson 
> wrote:
>
>> He might be running go test which also seems to rebuild everything every
>> time unless it has been installed.
>>
>> go test -i installs all the dependencies for a test and fixes this
>> problem.
>>
>>
>> On Wed, Jun 15, 2016 at 6:14 PM, Dave Cheney  wrote:
>>
>>> My guess is you are using go build, which compiles then discards
>>> everything it just compiled (unless what was compiled was a main package,
>>> in which case the binary will be left in your current working directory)
>>>
>>> I recommend using go install -v rather than go build for general use.
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and 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.
>

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

[go-nuts] Re: Golang Error - When marshelling data

[User123]

Is it giving error since it has null values? 

I'm just not able to get it. Since this code works perfectly fine in 1.4.2

On Thursday, June 16, 2016 at 4:08:38 PM UTC+5:30, User123 wrote:
>
> I cannot provide the full code sincethere are some dependencies.
>
> I did fmt.println on the data that I am trying to marshall and it looks 
> like this
>
> *%!(EXTRA main.JobResponseRoot={{92b4f95b309e8db0f8d56afadefc} http.res 
> {[{{  map[] } "Date","Time","Time_Zone","Source","Name","Raw_Data"*
> *  0x10a3c2d0}]}})*
>
> On Thursday, June 16, 2016 at 3:21:48 PM UTC+5:30, Dave Cheney wrote:
>>
>> Hello,
>>
>> Can you please provide a runnable code sample that shows the problem.
>>
>> Thanks
>>
>> Dave
>>
>> On Thursday, 16 June 2016 19:44:00 UTC+10, User123 wrote:
>>>
>>> The data  I am trying to marshal contains serialized data. This data is 
>>> received in http response.
>>>
>>> It works perfectly when I try in version 1.4.1/ 1.4.2.
>>>
>>> But when I try this to the latest version 1.6 it gives an error: *json: 
>>> unsupported type: <-chan struct {}*
>>>
>>> Why is it so? 
>>>
>>> I am not able to upgrade to the latest version because of this.
>>>
>>> Please 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] Re: Getting a lot of i/o timeouts in Go 1.4

[Dave Cheney]

Have you adjusted th number of file descriptors available to your program, and 
the server you are connecting to?

Have you used another program to verify that your target can handle the number 
of connections you are making?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Simon Ritchie]

This is not a question about Go, but basic web infrastructure.  However, 
it's one of those "best practice" questions which "everybody knows the 
answer to" and so you may be hard put to find out more without knowing 
where to start.

First of all, I should point out that when you tweak your PHP page, that 
does cause a service outage, but it's very short, and you usually don't 
notice. 

The usual solution to this problem is to use a team of web servers behind a 
load balancer or a reverse proxy.  A load balancer is a commercial product 
and most router manufacturers supply them, Cisco to name but one.  You can 
build your own reverse proxy using the Apache web server.  The Apache 
documentation explains how.

A reverse proxy is a web server that stands between the client web browsers 
and a team of web servers that do the work.  The proxy takes each incoming 
request and sends it to one of the web servers, then relays the response 
back to the client.  it looks to the client that the proxy is its web 
server, but actually it's just relaying requests and responses.  Add the 
ability to put extra worker servers into the team and take them out and you 
have your solution.  When you want to restart a server, you remove it from 
the team, restart it and then put it back, so at no time are all the 
servers out of action.  You need to arrange that there are always enough 
servers to cope with the traffic.

If you visit a large website such Google or Amazon, you are almost 
certainly talking to some sort of reverse proxy with lots of workers behind 
it.

The worker servers are usually called "application servers" , so you have 
the classic chain of: load balancer, web server, application server.  In 
your case, your Go software will run on the app servers.

Access to the app servers should be disallowed by the network except by the 
web server.

One of the advantages of the REST approach to web design is that your 
servers can be stateless, so each request can be sent to any old server.  
(With a statefull protocol, the proxy may need to keep track of sessions of 
associated requests and send all of the request in the session to the same 
worker.)

It's also common to terminate any SSL connections at the web server, ie the 
clients communicate with the web server via HTTPS, but it communicates with 
the app servers via HTTP.  Being encrypted, HTTPS requires significant 
extra work and Apache, in particular, is very good at this. 

A load balancer is a reverse proxy with lots of extra features.  In 
particular it may have more than one connection to the internet, so if 
there is a problem with one of the connections, it will still work.  Load 
balancers themselves can be more than one machine working as a team, 
possibly on different sites.  By spending (a lot) more money you can 
increase the reliability of your web service by having equipment in 
separate buildings on separate sites with a distributed load balancer 
network, Internet connections from different providers coming into 
different parts of the buildings and arriving at your equipment via 
different physical routes, multiple redundant uninterruptable power 
supplies, backup diesel generators, and so on. 

One organisation I worked for ran two buildings, one on each side of 
London, both staffed and each with enough equipment to provide the web 
service single-handed.  The thinking was that there was small chance of one 
building being destroyed by war, flood, fire or a plane crash.  They 
switched the production service between the buildings regularly to make 
sure that everything still worked.  This is not a cheap solution, but they 
were in the banking sector and they could afford it.

On the more affordable side, cloud services often provide a load balancer 
as part of the mix.

This is general web infrastructure wisdom and nothing to do with Go, so 
let's not let this discussion run on.  There should be enough above to help 
you choose the right Google searches.  Unless anybody thinks that what I've 
written contains any major blunders, let's all get back to talking about Go.

(If anybody wants to contact me directly for help with this sort of stuff, 
I'm a contractor and my daily rate is only slightly heinous.)

Hoping that this helps.

Simon


On Thursday, June 16, 2016 at 4:02:50 PM UTC+1, romano.p...@gmail.com wrote:
>
> Hi All,
>
> Forgive me if I posted in the wrong group, as it could be more of a 
> question related to design patterns rather than to golang itself.
>
> *The context*
> Imagine to create a full portal with users, profiles, ... and multiple 
> services that can be activated for different customers.
> I can organise the code of my portal in modules so to have a "quite" clear 
> use of golang packages, but at the end of the day I get to a unique EXE 
> file that represents my server/portal.
>
> When I start it, the portal runs. Perfect.
>
> To make an example, think of google, where you have Drive (Service 1) and 
> Gmail 

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

[⚛]

On Friday, June 17, 2016 at 2:30:12 AM UTC+2, gordo...@gmail.com wrote:
>
> > Modern x86 CPUs don't work like that. 
>
> > In general, optimally scheduled assembly code which uses more registers 
> has higher performance than optimally scheduled assembly code which uses 
> smaller number of registers. Assuming both assembly codes correspond to the 
> same source code. 
>
> > Register renaming: since Intel Pentium Pro and AMD K5. 
>
> > Suggestion for reading: 
> http://www.agner.org/optimize/microarchitecture.pdf 
>
> > An excerpt from the above PDF document (Section 10 about Haswell and 
> Broadwell pipeline): "... the register file has 168 integer registers and 
> 168 vector registers ..." 
>
> I am aware of all of the above and have already read Agner Fogg's 
> publications.  In addition modern CPU's do Out of Order Execution (OOE) so 
> rearrange the instructions to best reduce instruction latencies and 
> increase throughput given that there are parallel execution pipelines and 
> ahead-of-time execution, so the actual execution order is almost certainly 
> not as per the assembly listing. 
>
> Yes, both assembly listings are from the same tight loop code, but the 
> "C/C++" one has been converted from another assembly format to the golang 
> assembly format. 
>
> Daniel Bernstein, the author of "primegen" wrote for the Pentium 3 in x86 
> (32-bit) code, as the Pentium Pro processor wasn't commonly available at 
> that time and 64-bit code didn't exist.  His hand optimized C code for the 
> Sieve of Eratosthenes ("eratspeed.c" in the "doit()" function for the 
> "while k < B loop") uses six registers for this inner culling loop being 
> discussed, and takes about 3.5 CPU clock cycles per loop on a modern CPU 
> (Haswell).
>

The following isn't an argument against your post or in favor of your post. 
It is just some assembly code that I find interesting.

$ clang-3.9 -S -O3 eratspeed.c -mtune=bdver3
.LBB1_4:
movl%edx, %edi
shrl$5, %edi
movl%edx, %ecx
andl$31, %ecx
movltwo(,%rcx,4), *%ecx*
addl%esi, %edx
orl *%ecx*, a(%rbx,%rdi,4)
cmpl$32032, %edx
jb  .LBB1_4

5 registers: DX DI CX SI BX

$ perf stat --repeat=100 -- ./eratspeed.orig >/dev/null

 Performance counter stats for './eratspeed.orig' (100 runs):

466.592220  task-clock (msec) #0.999 CPUs utilized 
   ( +-  0.11% )
 1  context-switches  #0.002 K/sec 
   ( +- 12.37% )
 0  cpu-migrations#0.000 K/sec 
   ( +-100.00% )
86  page-faults   #0.185 K/sec 
   ( +-  0.09% )
 1,862,076,369  cycles#3.991 GHz   
   ( +-  0.11% )
74,805,707  stalled-cycles-frontend   #4.02% frontend 
cycles idle ( +-  1.20% )
   272,721,373  stalled-cycles-backend#  *14.65%* backend 
cycles idle   ( +-  0.16% )
 4,116,301,949  instructions  #*2.21*  insn per 
cycle 
  #0.07  stalled cycles 
per insn  ( +-  0.00% )
   473,019,237  branches  # 1013.774 M/sec 
   ( +-  0.00% )
 8,443,283  branch-misses #1.78% of all 
branches  ( +-  1.05% )

   0.467167554 seconds time elapsed 
 ( +-  0.11% )

-

Hand optimization of the above:

.LBB1_4:
movl%edx, %edi
shrl$5, %edi
movl%edx, %ecx
andl$31, %ecx
movltwo(,%rcx,4), *%r11d*
addl%esi, %edx
orl *%r11d*, a(%rbx,%rdi,4)
cmpl$32032, %edx
jb  .LBB1_4

6 registers: DX DI CX SI BX R11

$ perf stat --repeat=100 -- ./eratspeed.opt >/dev/null
 Performance counter stats for './eratspeed.opt' (100 runs):

444.740487  task-clock (msec) #0.999 CPUs utilized 
   ( +-  0.01% )
 1  context-switches  #0.002 K/sec 
   ( +- 11.68% )
 0  cpu-migrations#0.000 K/sec 
   ( +-100.00% )
85  page-faults   #0.191 K/sec 
   ( +-  0.10% )
 1,775,283,795  cycles#3.992 GHz   
   ( +-  0.00% )
68,397,472  stalled-cycles-frontend   #3.85% frontend 
cycles idle ( +-  0.04% )
   201,687,390  stalled-cycles-backend#  *11.36%* backend 
cycles idle   ( +-  0.02% )
 4,116,277,783  instructions  #*2.32*  insn per 
cycle 
  #0.05  stalled cycles 
per insn  ( +-  0.00% )
   473,014,763  branches  # 1063.575 M/sec 
  

Re: [go-nuts] Re: [ANN] primegen.go: Sieve of Atkin prime number generator

[gordonbgood]

I don't see the point of the exercise other than it proves that not putting the 
result of an operation back into the same register reduces the latency slightly 
for your processor (whatever it is?); I suspect that if you used any other 
register such as the unused AX register rather then the R11 register, the 
results would be the same.

What would be interesting is to compare the run time on your processor with the 
same eratspeed program written in golang using version 1.7beta1 with and 
without array bounds checks.

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

[paraiso . marc]

What is the point of doing that in a language that doesn't support auto 
currying ? There is none. You are not currying anything by the way, you 
just wrote 3 closures. 

Le vendredi 17 juin 2016 00:00:43 UTC+2, Zauberkraut a écrit :
>
> Hello,
>
> Go enables the evaluation of functions using currying over function 
> literals. Every example I've found of this is rather shallow; a "deeper" 
> example I wrote implementing (x => (y => (z => x^2 + y^2 + z^2))) follows:
>
> func f(x int) func(int) func(int) int {
> return func(y int) func(int) int {
> return func(z int) int {
> return x*x + y*y + z*z
> }
> }
> }
>
> Go's limited type inference makes the explicit, cascading function types 
> necessary; this seems like an eyesore and maintenance concern. While I 
> don't really mind it, it does cause me to hear code review sirens going off 
> in the distance. Generally speaking, would an extended usage of this 
> paradigm be considered unidiomatic in Go? Obviously, the above example is 
> contrived and not the sort of use case in question. Thanks!
>

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

[go-nuts] Re: How to manage a web portal with multiple services without stopping and restarting everything at each release/fix?

[Romano]

Hi Tamás,
thanks, I will have a look. I guess and hope that this is what I need.

@Simon: thanks for the response with so many details.
I have been working for years for projects with load balancers, HA, 
disaster recovery sites, and so on so your detailed answer can be really 
helpful to understand the topic for other readers.

In my specific case it's not what I was looking for because I am more 
interested in a modular software architecture that allows me to make 
modifications in that way, rather than the service one.

Thanks.
I guess that I will build up my special golang architecture and I hope that 
the graceful restart pattern is what I need.
Cheers!



Romano

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

[go-nuts] Re: Go 1.7 Beta 2 is released

[paraiso . marc]

Thanks, is there a way to know what to expect in later versions ( 
1.8,1.9,1.10 and so forth ... ) ? 

Le vendredi 17 juin 2016 01:15:18 UTC+2, Chris Broadfoot a écrit :
>
> Hello gophers,
>
> We have just released go1.7beta2, a beta version of Go 1.7.
> It is cut from the master branch at the revision tagged go1.7beta2.
>
> Please help us by testing your Go programs with the release, and report 
> any problems using the issue tracker:
> https://golang.org/issue/new
>
> You can download binary and source distributions from the usual place:
> https://golang.org/dl/#go1.7beta2
>
> To find out what has changed in Go 1.7, read the draft release notes:
> https://tip.golang.org/doc/go1.7
>
> Documentation for Go 1.7 is available at:
> https://tip.golang.org/
>
> Our goal is to release the final version of Go 1.7 on the 1st of August.
>
> Cheers,
> Chris
>

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

[go-nuts] Re: A proposal for generic in go

[andrew . mezoni]

>> I am not saying that generics is bad, but I am questioning whether 
generics is necessary.

Please, do not panic.
If you worry about the following things:
- Generated code will grow when used generics
- Generated code will be more complex when used generics
- Execution performance will slow down when used generics
- Memory consumption will grow when used generics

I can say you.
- Generated code will NOT grow when used generics
- Generated code will NOT more complex when used generics
- Execution performance will NOT slow down when used generics
- Memory consumption will NOT grow when used generics

They are so arranged that they are universal for all uses cases and does 
not require a significant changes in the following things:
- Compilers
- Runtimes
- Reflections

Most of the type checks will be performed at the compile time only because 
the Go language is statically typed language.
Most of the type instances (instances of the generic types which will be 
created at runtime) will be stored for the further reuse (they will be not 
created again and again but they will retrieved from the hidden static 
variables, so called lazy getters).

Only when used reflection then they (newly created type instances) can get 
some overhead but just a little bit more then with non-generic types.

Generic types is not evil, nor complex.
They are still the same types but only with the parameters (this is single 
kind of complexity which for me is not complexity at all) and they are 
variative (but this is not a complexity this is just a rules).

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

[Hoping White]

Hi, all

   I wonder is there a way to hide command line arguments from programs like 
“ps”？ I can rewrite argv parameter for main in c language, or use LD_PRELOAD to 
intercept libc_start_main, but all these methods do not be functional in go. 
Thanks. 

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

Re: [go-nuts] Unmarshalling and tags

[Nate Finch]

I'd like to see something like this:

type Payment struct { 
ActionType paypal.ActionType `xml,yaml,json:"actionType,omitempty"` 
ReceiverList paypal.ReceiverList `xml,yaml,json:"actionType,omitempty"` 
} 


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[Ian Davis]

 
On Tue, Jun 21, 2016, at 03:17 PM, andrew.mez...@gmail.com wrote:
> >>increase in cognitive load to decipher chains of type definitions.
>
> Sorry, but who are members of this mail lists?
> This is a first time when I hear about such loads such as the
> `cognitive load`.
> Also I am possible here a single person who does not know anything
> about the `cognitive load to decipher chains of type definitions`.
> I am mostly business man and a programmer just for my own
> requirements.
> I love to implements parsers, code generators, some effective
> algorithms for solving some problem at the most effective time.
> Also my work includes a diagnose the failures and locate them.
> And I want to apologize for my illiteracy (thick-headed), but I do not
> really was expecting that all members of this mail list worry mostly
> about the ` increase in cognitive load to decipher chains of type
> definitions` and don't worry about other things.
 
What I mean is that most people who have followed the past generics
discussions already know it's possible to implement them with efficient
memory use and performance. So they don't need to worry much about that.
 
What stops them being added to the language is: can they be implemented
without making Go a much more complex language than it is now.  In my
opinion complex or large languages result in code that is much harder
and expensive to maintain over the long term.
 
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: A proposal for generic in go

[Ian Davis]

 
On Tue, Jun 21, 2016, at 01:45 PM, andrew.mez...@gmail.com wrote:
> >>I am not saying that generics is bad, but I am questioning whether
> >>generics is necessary.
>
> Please, do not panic.
> If you worry about the following things:
> - Generated code will grow when used generics
> - Generated code will be more complex when used generics
> - Execution performance will slow down when used generics
> - Memory consumption will grow when used generics
 
I don't believe most people in this mailing list are worried about those
things. They are worried about things like code complexity, readability
and increase in cognitive load to decipher chains of type definitions.
 
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 hide command line argument from ps

[Konstantin Khomoutov]

On Tue, 21 Jun 2016 22:16:38 +0800
Hoping White  wrote:

> I wonder is there a way to hide command line arguments from
> programs like “ps”？ I can rewrite argv parameter for main in c
> language, or use LD_PRELOAD to intercept libc_start_main, but all
> these methods do not be functional in go. Thanks. 

What problem are you trying to solve?

It smells like you're passing some security-sensitive data to your
program.  If yes, do not do that: pass it via stdin via any protocol
agreed-upon by both parties (a single LF-terminated UTF-8-encoded string
could be OK).  If you need to use stdin to pass some other data, create
a socket pair (man 2 socketpair) in your host program, mark its read
end as exported on fork (or, alternatively, mark its write end as not
exported on fork -- this really depends on what language/runtime the
host is written in) -- to make the read end's file descriptor inherited
by your Go process, and pass the number of that file descriptor on the
command-line to the Go process.  It will then convert it to a proper
socket value and read your security-sensitive data from there.  (That's
what GPG does, for instance).  If you need more details, ask away.

Otherwise, try looking at prctl(2) and its PR_SET_NAME.
Not sure if it works on all POSIX kernels as this call is not defined
by POSIX.

In any case, I should stress that any attempt of re-writing
command-line options as seen by `ps` for security is solving the problem
asswards.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: A proposal for generic in go

[andrew . mezoni]

>> increase in cognitive load to decipher chains of type definitions.

Sorry, but who are members of this mail lists?
This is a first time when I hear about such loads such as the `cognitive 
load`.
Also I am possible here a single person who does not know anything about 
the `cognitive load to decipher chains of type definitions`.
I am mostly business man and a programmer just for my own requirements.
I love to implements parsers, code generators, some effective algorithms 
for solving some problem at the most effective time.
Also my work includes a diagnose the failures and locate them.
And I want to apologize for my illiteracy (thick-headed), but I do not 
really was expecting that all members of this mail list worry mostly about 
the ` increase in cognitive load to decipher chains of type definitions` 
and don't worry about other things.
I am sorry.

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