[go-nuts] Re: concurrent write-only to map ok?

[Alex Buchanan]

So many good answers! Lots of different ways to accomplish this. I'll say 
that in this specific case, which is does not require every ounce of 
performance, syncmap is by far the simplest and least amount of code, so 
readability wins on this one.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Newbie Implementation of Set Partitions Generator

[john lynch]

"I'm sure it'll reveal an error in my thinking"

To avoid importing math I had changed my upper limit early on but I 'd 
misread it.

The critical line in error should be changed to:

for j := 0; j < int(math.Pow(2.0, float64(len(set)))/2.0); 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] cgo multiple definition errors

[Ian Lance Taylor]

On Fri, Oct 13, 2017 at 4:24 PM, 'Pushkar' via golang-nuts
 wrote:
>
> I was getting the multiple definition error when I put my C files in the
> same directory as my go files.
> Only after reading some online posts I figured I should put my code into a
> separate directory.
>
> The introductory page to cgo doesn't mention this. It would save newbies
> some time if did:
> https://blog.golang.org/c-go-cgo
>
> Using go1.8.3 on Linux.

It usually works fine to put your C files in the same directory as
your Go files.  For example, that's how misc/cgo/test works.  I don't
know what happened that caused you to put your code in a separate
directory, so I don't know what to fix in the docs.

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] cgo multiple definition errors

['Pushkar' via golang-nuts]

I was getting the multiple definition error when I put my C files in the 
same directory as my go files.
Only after reading some online posts I figured I should put my code into a 
separate directory.

The introductory page to cgo doesn't mention this. It would save newbies 
some time if did:
https://blog.golang.org/c-go-cgo

Using go1.8.3 on Linux.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: concurrent write-only to map ok?

[Slawomir Pryczek]

I think using standard sync'ed map may be bad idea for this use case 
(write-only access), especially taking into account that it's optimized for 
read access and stable keys, so each write will acquire mutex anyway.

if nothing is read from that map during the threads run, it should be 
probably much better to assign single map for every thread and at the end, 
copy/merge the results to single "output" using mutex or rwmutex. This way 
you can acquire mutex once per thread, acquiring it for every write from 
multiple threads (which is what sync/map will do) is a performance killer.




W dniu piątek, 13 października 2017 20:05:56 UTC+2 użytkownik Alex Buchanan 
napisał:
>
> Basically, I want to spawn a goroutine per object, objects have unique 
> IDs, and I want each routine to write its results to a shared map. Nothing 
> will be reading from the map while the goroutines are running.
>
> Is this safe?
>
> 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] Newbie Implementation of Set Partitions Generator

[john lynch]

Thanks Michael,

I appreciate the information.   Because I'm trying to learn Go, I'm more 
interested in what should cause it to stop running part way through the 
process without generating an error.   It just seems bizarre to me but I'm 
sure it'll reveal an error in my thinking.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Newbie Implementation of Set Partitions Generator

[john lynch]

Thanks Ian,

You are correct (although the post I submitted yesterday had the clobbering 
lines incorrect - that was one of my experiments to see if rebuilding the 
3D slice differently would overcome the problem).   The code below is my 
original.

Yes, the function works by building fresh versions of out at each later and 
then reconstructing each set from the returned outs.

I am currently assuming that because it works for 2, 3, and 4 then somehow 
I'm doing something that causes my Go runtime (latest version running on 
Linux Mint 18 on an Intel i5) to return an answer before it has finished 
producing sets.

My next experiments will be to try to use the Gogland debug to establish 
why it stops.


package main
import (
"fmt"
"time")

func get_partitions(set []string, out [][][]string) [][][]string {
out = make([][][]string, 1)
out[0] = make([][]string, 1)
out[0][0] = make([]string, 0)

if len(set) <= 1 {
out[0][0] = set
return out
}
for j := 0; j < len(set)*len(set)/2; j++ {
i := j
parts := make([][]string, 2)
for _, item := range set {
parts[i&1] = append(parts[i&1], item)
i >>= 1
}
pts := get_partitions(parts[1], out)
for _, pt := range pts {
i3 := len(out) - 1
if len(out[i3][len(out[i3])-1]) == 0 {
out[i3][len(out[i3])-1] = parts[0]
} else {
out = append(out, [][]string{})
i3 += 1
out[i3] = append(out[i3], parts[0])
}
if len(pt[0]) > 0 {
for ptidx, _ := range pt {
out[i3] = append(out[i3], pt[ptidx])
}
}
}
}
return out}

func main() {
set := []string{"1", "2", "3", "4", "5"}
var out, ppp [][][]string
out = make([][][]string, 1) // create & initialize 3D slice
out[0] = make([][]string, 1)
out[0][0] = make([]string, 1)
t0 := time.Now()
ppp = get_partitions(set, out)
elapsed := time.Since(t0)
fmt.Printf("Took %s\n", elapsed)
fmt.Printf("\nGot the partition: %v\n", ppp)
fmt.Println(len(ppp))}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Newbie Implementation of Set Partitions Generator

[john lynch]

The top 3 lines of the function I posted yesterday were not correct but I 
couldn't edit them.   Unfortunately, in my experiments with the slice I had 
changed them and didn't realize before posting.   The correct version is:

package main
import (
"fmt"
"time")

func get_partitions(set []string, out [][][]string) [][][]string {
out = make([][][]string, 1)
out[0] = make([][]string, 1)
out[0][0] = make([]string, 0)

if len(set) <= 1 {
out[0][0] = set
return out
}
for j := 0; j < len(set)*len(set)/2; j++ {
i := j
parts := make([][]string, 2)
for _, item := range set {
parts[i&1] = append(parts[i&1], item)
i >>= 1
}
pts := get_partitions(parts[1], out)
for _, pt := range pts {
i3 := len(out) - 1
if len(out[i3][len(out[i3])-1]) == 0 {
out[i3][len(out[i3])-1] = parts[0]
} else {
out = append(out, [][]string{})
i3 += 1
out[i3] = append(out[i3], parts[0])
}
if len(pt[0]) > 0 {
for ptidx, _ := range pt {
out[i3] = append(out[i3], pt[ptidx])
}
}
}
}
return out}

func main() {
set := []string{"1", "2", "3", "4", "5"}
var out, ppp [][][]string
out = make([][][]string, 1) // create & initialize 3D slice
out[0] = make([][]string, 1)
out[0][0] = make([]string, 1)
t0 := time.Now()
ppp = get_partitions(set, out)
elapsed := time.Since(t0)
fmt.Printf("Took %s\n", elapsed)
fmt.Printf("\nGot the partition: %v\n", ppp)
fmt.Println(len(ppp))}

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

Re: [go-nuts] Re: go on Windows 10 from the bash shell (and the cmd shell)

[Gerald Henriksen]

On Thu, 12 Oct 2017 22:08:44 -0700 (PDT), you wrote:

>
>On Thursday, October 12, 2017 at 8:31:52 PM UTC-4, Gerald wrote:
>>
>> The MSI is a Windows application, whereas apt-get would install the 
>> Linux binary of go. 
>>
>> WSL has you actually running Linux binaries on Windows unless you 
>> specifically go and choose a Windows executable. 
>>
>
>The MSI file triggers a Windows application, sure. But is the actual go 
>binary different?
>Its possible to make a Posix compliant system call on nearly any operating 
>system. Posix was
>designed to let the US Government require Unix, back when Unix was special. 
>But the basic functions
>that most of us call Unix or Linux system calls are trivial in any 
>operating system. Probably even Plan-9
>
>There is a lot less to making bash, and apt-get run on any operating system 
>than many folks think
>
>I may have to do both installs and do a shasum on the files.

WSL actually runs the Linux distrobution you choose - currently SUSE
and Ubuntu are available with Fedora coming.

The only limitation is no GUI stuff.

Microsoft enables this by amongst other things emulating the Linux
kernel so that WSL natively runs Linux ELF64 binaries.

So Go installed via the Windows MSI and via apt-get (or yum or dnf)
will be entirely separate binaries.

More information:

https://msdn.microsoft.com/en-us/commandline/wsl/faq

https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] concurrent write-only to map ok?

[Marvin Renich]

* Alex Buchanan  [171013 14:06]:
> Basically, I want to spawn a goroutine per object, objects have unique IDs, 
> and I want each routine to write its results to a shared map. Nothing will 
> be reading from the map while the goroutines are running.

You didn't give much detail, but if the map is map[ID]sometype and each
goroutine is only writing to its own element of the map, you could make
it a map[ID]*sometype.  Assuming the goroutines are all spawned by a
single "main" goroutine, that main goroutine can create the sometype,
assign its address to the map, and pass the *sometype to the goroutine.
Now, only the main goroutine accesses the map.  Accessing the individual
sometype instances does not interfere with any other goroutine, and no
explicit synchronization is needed.

...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] Blocking in C functions called from go

[Ian Lance Taylor]

On Fri, Oct 13, 2017 at 12:23 PM, 'Pushkar' via golang-nuts
 wrote:
> I need to call some C functions from Go. I think I know how to proceed using
> cgo.
> However, I was wondering how goroutines and blocking calls in the C
> functions work together.
> So in the below example (pseudocode) will the goroutine be suspended when
> the pthread_lock call is waiting to acquire the lock?

Yes.

> I am guessing that the Go engine will detect that the OS thread on which the
> goroutine(s) are running is blocked so it will suspend them too.
> Once the thread is runnable, the blocked goroutines will be scheduled to
> run.

Yes.

Ian

> For example:
>
> int cfunc (int a) {
>   pthread_lock(..);
>   ++a;
>   pthread_unlock();
> }
>
> func main() {
>   for (i  := 0; i < 100; i++) {
> go cfunc(i)
>   }
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] Blocking in C functions called from go

['Pushkar' via golang-nuts]

I need to call some C functions from Go. I think I know how to proceed 
using cgo.
However, I was wondering how goroutines and blocking calls in the C 
functions work together.
So in the below example (pseudocode) will the goroutine be suspended when 
the pthread_lock call is waiting to acquire the lock?

I am guessing that the Go engine will detect that the OS thread on which 
the goroutine(s) are running is blocked so it will suspend them too.
Once the thread is runnable, the blocked goroutines will be scheduled to 
run.

For example:

int cfunc (int a) {
  pthread_lock(..);
  ++a;
  pthread_unlock();
}

func main() {
  for (i  := 0; i < 100; i++) {
go cfunc(i)
  }
}

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] concurrent write-only to map ok?

[Shawn Milochik]

On Fri, Oct 13, 2017 at 2:33 PM, Alex Buchanan 
wrote:

> Thanks for the quick help guys!
>
> I ended up using https://godoc.org/golang.org/x/sync/syncmap
>
>
Cool, that's what it's there for. Personally I'd avoid using empty
interfaces, though.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] concurrent write-only to map ok?

[Alex Buchanan]

Thanks for the quick help guys!

I ended up using https://godoc.org/golang.org/x/sync/syncmap

On Friday, October 13, 2017 at 11:22:44 AM UTC-7, Shawn Milochik wrote:
>
> On Fri, Oct 13, 2017 at 2:05 PM, Alex Buchanan  > wrote:
>
>> Basically, I want to spawn a goroutine per object, objects have unique 
>> IDs, and I want each routine to write its results to a shared map. Nothing 
>> will be reading from the map while the goroutines are running.
>>
>> Is this safe?
>>
>>
> Whether this is technically safe *today* in the reference implementation, 
> it's better to *be* safe.
>
> I suggest using a waitgroup and a channel to collect the results in an 
> explicitly safe way. Perhaps something like this: 
> https://play.golang.org/p/1NdQbAW65k
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 on Windows 10 from the bash shell (and the cmd shell)

[Sotirios Mantziaris]

follow the procedure of installing go in linux.
set the following in .bashrc of your home directory at the end:

export PATH=$PATH:/usr/local/go/bin
export PATH=$PATH:$GOPATH/bin

worked for me just fine!

On Wednesday, October 11, 2017 at 8:04:28 AM UTC+3, Pat Farrell wrote:
>
> I've installed the go 1.9 binary distribution on my windows 10 laptop. 
> I just let the install do the defaults. (in addition to learning go, I'm 
> trying to see if I can live with 
> bash under Windows, or if I have to reboot to a linux distro to avoid 
> going crazy, that is a separate topic)
>
> in the cmd shell
> 'go build' works, but creates a file go.exe that when run, displays hello 
> world
> it does not create the expected hello.exe
>
> in the bash shell, 'go build' does not work, it whines that 'go' is not a 
> program
>
> The program 'go' is currently not installed. You can install it by typing:
> sudo apt-get install gccgo-go
>
>
>
> but 'go.exe build' does create a local go.exe which executes and displays 
> the expected hello world.
>
> Which raises a couple of questions:
>
> 1) is the standard documentation wrong/out of date?
> 2) how do I get the go build process to create a hello.exe rather than 
> go.exe?
> 3) how do I get the bash shell to let me just type 'go build' like we all 
> want?
>
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] concurrent write-only to map ok?

[Shawn Milochik]

On Fri, Oct 13, 2017 at 2:05 PM, Alex Buchanan 
wrote:

> Basically, I want to spawn a goroutine per object, objects have unique
> IDs, and I want each routine to write its results to a shared map. Nothing
> will be reading from the map while the goroutines are running.
>
> Is this safe?
>
>
Whether this is technically safe *today* in the reference implementation,
it's better to *be* safe.

I suggest using a waitgroup and a channel to collect the results in an
explicitly safe way. Perhaps something like this:
https://play.golang.org/p/1NdQbAW65k

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] concurrent write-only to map ok?

[Ian Lance Taylor]

On Fri, Oct 13, 2017 at 11:05 AM, Alex Buchanan  wrote:
>
> Basically, I want to spawn a goroutine per object, objects have unique IDs,
> and I want each routine to write its results to a shared map. Nothing will
> be reading from the map while the goroutines are running.
>
> Is this safe?

No.  In general, multiple goroutines writing to a single variable is
not safe.  You need some sort of synchronization.

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] concurrent write-only to map ok?

[Alex Buchanan]

Basically, I want to spawn a goroutine per object, objects have unique IDs, 
and I want each routine to write its results to a shared map. Nothing will 
be reading from the map while the goroutines are running.

Is this safe?

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] Crypto - modes of operation

[Jakob Borg]

On 13 Oct 2017, at 14:40, Sonia Bogos 
> wrote:

Hello,

I have a small crypto question. I noticed that in the "crypto/cipher" package 
CBC and ECB are BlockMode type while CFB,CTR,OFB are Stream type.  At the 
basics, they are all modes of operation that allow us to encrypt messages with 
a variable length. What is the technical reason for this split?

ECB and CBC require that the input is a whole number of blocks. Padding must be 
added at an earlier stage if the plaintext itself isn't a whole number of 
blocks. CFB, CTR, OFB don't have this restriction and can be used as stream 
ciphers.

//jb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Newbie Implementation of Set Partitions Generator

[Michael Jones]

Generating set partitions is efficiently performed by [the second]
Algorithm H in Knuth's Art of Computer Programming, Volume 4A,
Combinatorial Algorithms, Part 1. It appears on page 416.

Counting the number of set partitions means evaluating the Bell numbers,
which is easily done by table summation.

Efficiently programming the generation of set partitions depends on what
you need contextually, either all of the partitions at once as a list of
solutions, or one at a time in the spirit of a solution generator.

In the second case, a generator for set partitions, it is possible to
generate them in "shape order"; a 4-tuple broken into blocks of length 4,
3+1, 2+2, 2+1+1, 1+1+1+1. (The five "shapes" being the integer partition of
the number 4). If you were to create slices of these cardinalities in Go
and just fill in the values, then the generator would have a minimal
allocation overhead, given that there may be many instances of some shapes.

It is also possible to skip the generation of the physical subsets
altogether, by generating the manifests for the various blocks. For
example, dividing "ABCD" into AD+B+C can be represented by the value "1231"
meaning that A and D are in group 1, B is in 2, and C is in group 3. I have
done this scheme in a combination generator before in Go with respectable
efficiency:

BenchmarkOrderedRate1-8  3  4.65 ns/op
BenchmarkOrderedRate2-8  1 10.5 ns/op
BenchmarkOrderedRate3-8  1 17.1 ns/op
BenchmarkOrderedRate4-8  1 24.1 ns/op
BenchmarkOrderedRate5-8  5000 32.5 ns/op
BenchmarkOrderedRate6-8  5000 39.5 ns/op
BenchmarkOrderedRate7-8  3000 46.5 ns/op
BenchmarkOrderedRate8-8  3000 53.0 ns/op
BenchmarkOrderedRate9-8  2000 59.6 ns/op
BenchmarkOrderedRate10-82000 66.9 ns/op
BenchmarkOrderedRate11-82000 75.9 ns/op
BenchmarkOrderedRate12-82000 82.6 ns/op
BenchmarkOrderedRate13-82000 88.9 ns/op
BenchmarkOrderedRate14-82000 95.6 ns/op
BenchmarkOrderedRate15-82000102 ns/op


...and because i was able to use the "manifest" representation in my code,
there is no allocation in the loops and even 15-element generation proceeds
at 10 million iterations per second. I did not need a set partition
generator, so I don't have code to offer, but the work is similar and the
speeds should not be too different, at least for the manifest (aka "index")
representation.

On Fri, Oct 13, 2017 at 6:51 AM, Ian Lance Taylor  wrote:

> On Thu, Oct 12, 2017 at 11:57 PM, john lynch  wrote:
> >
> > I've been implementing some Python code in Go to learn the language.  In
> > Python this will generate a Set Partition.  The Go equivalent follows.
> >
> > The Go runs fine for list element sizes 2 and 3 (which means the
> recursion
> > is running properly). Also 4 but at 5 and above it generates the intial
> sets
> > and then just stops. So on my machine I get 25 partitions for 5 elements
> and
> > it should continue to 52. Similar results for larger number, with 9
> > generating 213 sets against Python's 21147. So, I got over the lack of
> lists
> > by using slices, I got used to the global nature of variables.  I love
> the
> > language but this has me confused. Any thoughts please?
>
> I don't know what you are trying to do but if I were you I would look
> closely at the way you are passing slices around.  When you pass the
> slice `out` in the recursive call, it will be modified by the function
> you are calling.  So you seem to be trying to build partitions in out
> while also passing it down in a recursive call that clobbers some
> elements.
>
> 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.
>



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

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

Re: [go-nuts] Re: Why are two slices in this example less costly than one?

[Marvin Stenger]

I told you the reason already. slice of struct is in the stack frame.

Am Freitag, 13. Oktober 2017 16:59:14 UTC+2 schrieb Gabriel Aszalos:
>
>
> For some reason, it seems that allocating a slice of slices takes up quite 
> a bit of memory, while allocating the slice of structs takes up no memory? 
> Quite interesting. But still can't really make sense of it.
>

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

Re: [go-nuts] Re: Why are two slices in this example less costly than one?

[Gabriel Aszalos]

Thanks Diego. I didn't know about the `--alloc_space` flag. Quite 
insightful!!! For anyone else potentially interested in the results, here 
they are:

Here are the results for the original FieldsFunc from the standard library:


And here are the results for my "simplified" version:



For some reason, it seems that allocating a slice of slices takes up quite 
a bit of memory, while allocating the slice of structs takes up no memory? 
Quite interesting. But still can't really make sense of it.

On Friday, 13 October 2017 13:11:25 UTC+2, Diego Medina wrote:
>
>
>> This is exactly what I was trying to figure out how I would be able to 
>> do, and more specifically, if there's an easy way to find out.
>>
>>
>
> the pprof tool can read a memory or cpu  profile created during your 
> benchmark, and then you can see details of your function, line by line, and 
> see the amount of allocations you are making, this should help you see the 
> differences between one implementation vs the other 
>
> once you are inside the pprof tool, you can run
>
> list 
>
> and it will give you the details
>
> here is a post I recently wrote, in case you haven't used pprof with go 
> code before 
>
> https://blog.fmpwizard.com/2017/09/29/memory-profiling-in-go/
>
> Regards,
>
> Diego
>
>  
>
>> On Tuesday, 10 October 2017 15:38:58 UTC+2, Ian Lance Taylor wrote:
>>>
>>> On Tue, Oct 10, 2017 at 12:50 AM, Gabriel Aszalos 
>>>  wrote: 
>>> > 
>>> > I would love to find out the answer to this. Even if you don't know 
>>> the 
>>> > answer but know how to investigate into it (using pprof or some 
>>> tracing 
>>> > flags), I would also appreciate being guided in the right direction 
>>> and I 
>>> > would love to embark on the journey of finding out myself. 
>>> > 
>>> > What I'm basically saying is that I'd be more interested to find out 
>>> the way 
>>> > in which I can tell why one is faster than the other, as opposed to 
>>> hearing 
>>> > just the final answer. Hope that makes sense. 
>>>
>>> Start by writing a standalone x_test.go program that provides both 
>>> versions of the code and uses the benchmark framework to measure both. 
>>> When you can repeat the issue with -bench=., run it with -benchmem to 
>>> print the memory allocations.  If they are different, that is probably 
>>> the cause.  Then you have to figure out why they are different.  If 
>>> they are not different, you'll need to look at the generated code.  On 
>>> GNU/Linux, the system's perf tool can help you identify which parts of 
>>> the code take more time.  For a larger program I would suggest pprof, 
>>> but pprof is better at pointing you at a specific function then it is 
>>> at identifying which part of the function is slow. 
>>>
>>> Ian 
>>>
>>>
>>> > On Thursday, 5 October 2017 15:22:47 UTC+2, Marvin Stenger wrote: 
>>> >> 
>>> >> I can reproduce the numbers. The only think I'm seeing is that the 
>>> spans 
>>> >> array is allocated on the stack. Not sure though if this is the only 
>>> reason. 
>>> >> 
>>> >> Am Donnerstag, 5. Oktober 2017 13:13:56 UTC+2 schrieb Gabriel 
>>> Aszalos: 
>>> >>> 
>>> >>> I was playing around with the implementation of FieldsFunc from the 
>>> bytes 
>>> >>> package and I was wondering how it would affect the benchmarks to 
>>> disregard 
>>> >>> the extra slice that was used there to calculate offsets. It only 
>>> made sense 
>>> >>> that it would make things faster. 
>>> >>> 
>>> >>> To my amusement (although expected), it didn't. But I'm quite 
>>> curious why 
>>> >>> one is faster than the other and if this reveals any good practices 
>>> when 
>>> >>> working with similar algorithms. The benchmark and diff I am talking 
>>> about 
>>> >>> can be viewed here: 
>>> >>> 
>>> >>> 
>>> >>> 
>>> https://github.com/gbbr/go/commit/2f6e92bc746fa232f2f2aea66dae3fa0c04700a5?diff=split
>>>  
>>> >>> 
>>> >>> Many thanks for looking! 
>>> >> 
>>> >> 
>>> > -- 
>>> > You received this message because you are subscribed to the Google 
>>> Groups 
>>> > "golang-nuts" group. 
>>> > To unsubscribe from this group and stop receiving emails from it, send 
>>> an 
>>> > email to golang-nuts...@googlegroups.com. 
>>> > For more options, visit https://groups.google.com/d/optout. 
>>>
>>

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

Re: [go-nuts] How to generate long int with k random bits.

[Jan Mercl]

> On Fri, Oct 13, 2017 at 4:37 PM Christian LeMoussel 
wrote:

See https://golang.org/pkg/math/big/#Int.Rand

-- 

-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] How to generate long int with k random bits.

[Christian LeMoussel]

Hi,

In python there is random. 

getrandbits(*k* 
) 
 that returns 
a python long int with *k* random bits. 
Eg : getrandbits(128) => long int with 128 random bits

I do this

func init() {
rand.Seed(time.Now().UnixNano())}
var bitsRunes = []rune("01")

func RandBitsRunes(n int) string {
b := make([]rune, n)
for i := range b {
b[i] = bitsRunes [rand.Intn(len(bitsRunes ))]
}
return string(b)}


i,_ := strconv.Btoi64(RandBitsRunes(128), 2)


I'm new in Go.  There may be a more efficient solution


Thank for your 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.

Re: [go-nuts] Why can't I call a pointer-receiver method on a temperary but addressable struct literal?

[Ian Lance Taylor]

On Fri, Oct 13, 2017 at 5:41 AM, Cholerae Hu  wrote:
> package main
>
> import (
> "fmt"
> "reflect"
> )
>
> type Circle struct {
> radius float64
> }
>
> func (c *Circle) DummyMethod() {
> fmt.Println("Type of receiver:", reflect.TypeOf(c))
> }
>
> func main() {
> // error: cannot take the address of Circle literal
> // Circle{radius: 1.0}.DummyMethod()
> ({radius: 1.0}).DummyMethod()
> }
>
> https://golang.org/ref/spec#Calls
>>
>>  If x is addressable and 's method set contains m, x.m() is shorthand
>> for ().m()
>
>
> https://golang.org/ref/spec#Address_operators
> Composite literals is addressable.
>
> So why can't I call DummyMethod like Circle{radius: 1.0}.DummyMethod() ?

Composite literals are not addressable.  The section of the spec you
are citing lists the addressable objects and then says that, as an
exception, the address operator '&' may be applied to a composite
literal even though they are not addressable.

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] Shutdown server over shared variable

[Ian Lance Taylor]

On Fri, Oct 13, 2017 at 3:52 AM,   wrote:
>
> As I can understand from manuals prefered way to communicate between
> gorutine is channel but in core component net/http we have shared method
> Shutdown
>
>Why and how it work? Why autor violate language ideology by himself?

There are various ways to communicate between goroutines.  Channels is
one way but there are others.

I don't understand the contradiction you see between the
(*Server).Shutdown method and communication using channels.  The
Shutdown method does in fact use a channel to communicate the
request--see closeDoneChanLocked.

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] Newbie Implementation of Set Partitions Generator

[Ian Lance Taylor]

On Thu, Oct 12, 2017 at 11:57 PM, john lynch  wrote:
>
> I've been implementing some Python code in Go to learn the language.  In
> Python this will generate a Set Partition.  The Go equivalent follows.
>
> The Go runs fine for list element sizes 2 and 3 (which means the recursion
> is running properly). Also 4 but at 5 and above it generates the intial sets
> and then just stops. So on my machine I get 25 partitions for 5 elements and
> it should continue to 52. Similar results for larger number, with 9
> generating 213 sets against Python's 21147. So, I got over the lack of lists
> by using slices, I got used to the global nature of variables.  I love the
> language but this has me confused. Any thoughts please?

I don't know what you are trying to do but if I were you I would look
closely at the way you are passing slices around.  When you pass the
slice `out` in the recursive call, it will be modified by the function
you are calling.  So you seem to be trying to build partitions in out
while also passing it down in a recursive call that clobbers some
elements.

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] Why can't I call a pointer-receiver method on a temperary but addressable struct literal?

[Ian Davis]

On Fri, 13 Oct 2017, at 02:02 PM, Ian Davis wrote:
> On Fri, 13 Oct 2017, at 01:41 PM, Cholerae Hu wrote:
>> https://golang.org/ref/spec#Calls
>>>  If x is addressable[1] and 's method set contains m, x.m() is
>>>  shorthand for ().m()>> 
>> https://golang.org/ref/spec#Address_operators
>> Composite literals is addressable.
>> 
>> So why can't I call DummyMethod like Circle{radius:
>> 1.0}.DummyMethod() ?> 
> It works on the playground: https://play.golang.org/p/kP9emNKWeg
> 
> Ian

Sorry, I misread your question.

Links:

  1. https://golang.org/ref/spec#Address_operators

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

[go-nuts] Why can't I call a pointer-receiver method on a temperary but addressable struct literal?

[Cholerae Hu]

package main

import (
"fmt"
"reflect"
)

type Circle struct {
radius float64
}

func (c *Circle) DummyMethod() { 
fmt.Println("Type of receiver:", reflect.TypeOf(c))
}

func main() {
// error: cannot take the address of Circle literal
// Circle{radius: 1.0}.DummyMethod()
({radius: 1.0}).DummyMethod()
}

https://golang.org/ref/spec#Calls 

>  If x is addressable  and 
> 's method set contains m, x.m() is shorthand for ().m()


https://golang.org/ref/spec#Address_operators
Composite literals is addressable.

So why can't I call DummyMethod like Circle{radius: 1.0}.DummyMethod() ?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Newbie Implementation of Set Partitions Generator

[john lynch]

I've been implementing some Python code in Go to learn the language.  In 
Python this will generate a Set Partition.  The Go equivalent follows.

The Go runs fine for list element sizes 2 and 3 (which means the recursion 
is running properly). Also 4 but at 5 and above it generates the intial 
sets and then just stops. So on my machine I get 25 partitions for 5 
elements and it should continue to 52. Similar results for larger number, 
with 9 generating 213 sets against Python's 21147. So, I got over the lack 
of lists by using slices, I got used to the global nature of variables.  I 
love the language but this has me confused. Any thoughts please?

---

def get_partitions(ss, out = []):
if len(ss) <= 1: 
return [ss]
for i in range(2**len(ss)//2):
parts = [[], []]
for item in ss:
parts[i&1].append(item)
i >>= 1
for b in get_partitions(parts[1], []):
if b and not isinstance(b[0], list): 
b = [b]
out.append([parts[0]]+ b)
return out


sp = get_partitions(["1", "2", "3", "4", "5"])




---

package main

import (
   "fmt"
)

func get_partitions(set []string, out [][][]string) [][][]string {
   out = out[:1]
   out[0] = out[0][:1]
   out[0][0] = out[0][0][:1]

   if len(set) <= 1 {
  out[0][0] = set
  return out
   }
   for j := 0; j < len(set)*len(set)/2; j++ {
  i := j
  parts := make([][]string, 2)
  for _, item := range set {
 parts[i&1] = append(parts[i&1], item)
 i >>= 1
  }
  pts := get_partitions(parts[1], out)
  for _, pt := range pts {
 i3 := len(out) - 1
 if len(out[i3][len(out[i3])-1]) == 0 {
out[i3][len(out[i3])-1] = parts[0]
 } else {
out = append(out, [][]string{})
i3 += 1
out[i3] = append(out[i3], parts[0])
 }
 if len(pt[0]) > 0 {
for ptidx, _ := range pt {
   out[i3] = append(out[i3], pt[ptidx])
}
 }
  }
   }
   return out
}

func main() {
   set := []string{"1", "2", "3", "4", "5"}
   var out [][][]string
   out = make([][][]string, 1) // create & initialize 3D slice
   out[0] = make([][]string, 1)
   out[0][0] = make([]string, 1)
   t0 := time.Now()
   ppp := get_partitions(set, out)
   fmt.Println(len(ppp))
}

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

[Sonia Bogos]

Hello, 

I have a small crypto question. I noticed that in the "crypto/cipher" 
package CBC and ECB are BlockMode type while CFB,CTR,OFB are Stream type.  
At the basics, they are all modes of operation that allow us to encrypt 
messages with a variable length. What is the technical reason for this 
split?
 
I am asking since myself I implement a small module that encrypts some data 
and I want to be able to be generic and choose if I want to encrypt with 
gcm, cbc or ctr (but for different modes of operation I need to provide 
different types). So I cannot provide a generic interface for my module. 
Thank you. 

Sonia 

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

[vit1251]

Hello,

As I can understand from manuals prefered way to communicate between 
gorutine is channel but in core component net/http we have shared method 
Shutdown

   Why and how it work? Why autor violate language ideology by himself?

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: Go jobs in Canada

[jobs jobs]

Did you had the job in Canada?

在 2017年9月21日星期四 UTC+8上午11:00:50，Totoro W写道：
>
> Hi there,
>
> I'm now software developer in China and looking for a job in Canada. And I 
> have worked with go for at least 5 years.
> Is there any opportunity there (i could relocate there if possible). I'd 
> like to hear about them. 
>
> My github: https://github.com/tw4452852
> My blog: https://totorow.xyz
>
> Thanks a lot.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Why are two slices in this example less costly than one?

[Diego Medina]

>
>
> This is exactly what I was trying to figure out how I would be able to do, 
> and more specifically, if there's an easy way to find out.
>
>

the pprof tool can read a memory or cpu  profile created during your 
benchmark, and then you can see details of your function, line by line, and 
see the amount of allocations you are making, this should help you see the 
differences between one implementation vs the other 

once you are inside the pprof tool, you can run

list 

and it will give you the details

here is a post I recently wrote, in case you haven't used pprof with go 
code before 

https://blog.fmpwizard.com/2017/09/29/memory-profiling-in-go/

Regards,

Diego

 

> On Tuesday, 10 October 2017 15:38:58 UTC+2, Ian Lance Taylor wrote:
>>
>> On Tue, Oct 10, 2017 at 12:50 AM, Gabriel Aszalos 
>>  wrote: 
>> > 
>> > I would love to find out the answer to this. Even if you don't know the 
>> > answer but know how to investigate into it (using pprof or some tracing 
>> > flags), I would also appreciate being guided in the right direction and 
>> I 
>> > would love to embark on the journey of finding out myself. 
>> > 
>> > What I'm basically saying is that I'd be more interested to find out 
>> the way 
>> > in which I can tell why one is faster than the other, as opposed to 
>> hearing 
>> > just the final answer. Hope that makes sense. 
>>
>> Start by writing a standalone x_test.go program that provides both 
>> versions of the code and uses the benchmark framework to measure both. 
>> When you can repeat the issue with -bench=., run it with -benchmem to 
>> print the memory allocations.  If they are different, that is probably 
>> the cause.  Then you have to figure out why they are different.  If 
>> they are not different, you'll need to look at the generated code.  On 
>> GNU/Linux, the system's perf tool can help you identify which parts of 
>> the code take more time.  For a larger program I would suggest pprof, 
>> but pprof is better at pointing you at a specific function then it is 
>> at identifying which part of the function is slow. 
>>
>> Ian 
>>
>>
>> > On Thursday, 5 October 2017 15:22:47 UTC+2, Marvin Stenger wrote: 
>> >> 
>> >> I can reproduce the numbers. The only think I'm seeing is that the 
>> spans 
>> >> array is allocated on the stack. Not sure though if this is the only 
>> reason. 
>> >> 
>> >> Am Donnerstag, 5. Oktober 2017 13:13:56 UTC+2 schrieb Gabriel Aszalos: 
>> >>> 
>> >>> I was playing around with the implementation of FieldsFunc from the 
>> bytes 
>> >>> package and I was wondering how it would affect the benchmarks to 
>> disregard 
>> >>> the extra slice that was used there to calculate offsets. It only 
>> made sense 
>> >>> that it would make things faster. 
>> >>> 
>> >>> To my amusement (although expected), it didn't. But I'm quite curious 
>> why 
>> >>> one is faster than the other and if this reveals any good practices 
>> when 
>> >>> working with similar algorithms. The benchmark and diff I am talking 
>> about 
>> >>> can be viewed here: 
>> >>> 
>> >>> 
>> >>> 
>> https://github.com/gbbr/go/commit/2f6e92bc746fa232f2f2aea66dae3fa0c04700a5?diff=split
>>  
>> >>> 
>> >>> Many thanks for looking! 
>> >> 
>> >> 
>> > -- 
>> > You received this message because you are subscribed to the Google 
>> Groups 
>> > "golang-nuts" group. 
>> > To unsubscribe from this group and stop receiving emails from it, send 
>> an 
>> > email to golang-nuts...@googlegroups.com. 
>> > For more options, visit https://groups.google.com/d/optout. 
>>
>

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

Re: [go-nuts] Re: Why are two slices in this example less costly than one?

[Gabriel Aszalos]

Superb! Thank you Ian. That is indeed insightful. In my case (as can be 
seen in the commit message showing the benchstat output), allocations for 
small ASCII test cases have a delta of +860%, which is 8 times more bytes 
allocated. You've said:

> Then you have to figure out why they are different.

This is exactly what I was trying to figure out how I would be able to do, 
and more specifically, if there's an easy way to find out.

On Tuesday, 10 October 2017 15:38:58 UTC+2, Ian Lance Taylor wrote:
>
> On Tue, Oct 10, 2017 at 12:50 AM, Gabriel Aszalos 
>  wrote: 
> > 
> > I would love to find out the answer to this. Even if you don't know the 
> > answer but know how to investigate into it (using pprof or some tracing 
> > flags), I would also appreciate being guided in the right direction and 
> I 
> > would love to embark on the journey of finding out myself. 
> > 
> > What I'm basically saying is that I'd be more interested to find out the 
> way 
> > in which I can tell why one is faster than the other, as opposed to 
> hearing 
> > just the final answer. Hope that makes sense. 
>
> Start by writing a standalone x_test.go program that provides both 
> versions of the code and uses the benchmark framework to measure both. 
> When you can repeat the issue with -bench=., run it with -benchmem to 
> print the memory allocations.  If they are different, that is probably 
> the cause.  Then you have to figure out why they are different.  If 
> they are not different, you'll need to look at the generated code.  On 
> GNU/Linux, the system's perf tool can help you identify which parts of 
> the code take more time.  For a larger program I would suggest pprof, 
> but pprof is better at pointing you at a specific function then it is 
> at identifying which part of the function is slow. 
>
> Ian 
>
>
> > On Thursday, 5 October 2017 15:22:47 UTC+2, Marvin Stenger wrote: 
> >> 
> >> I can reproduce the numbers. The only think I'm seeing is that the 
> spans 
> >> array is allocated on the stack. Not sure though if this is the only 
> reason. 
> >> 
> >> Am Donnerstag, 5. Oktober 2017 13:13:56 UTC+2 schrieb Gabriel Aszalos: 
> >>> 
> >>> I was playing around with the implementation of FieldsFunc from the 
> bytes 
> >>> package and I was wondering how it would affect the benchmarks to 
> disregard 
> >>> the extra slice that was used there to calculate offsets. It only made 
> sense 
> >>> that it would make things faster. 
> >>> 
> >>> To my amusement (although expected), it didn't. But I'm quite curious 
> why 
> >>> one is faster than the other and if this reveals any good practices 
> when 
> >>> working with similar algorithms. The benchmark and diff I am talking 
> about 
> >>> can be viewed here: 
> >>> 
> >>> 
> >>> 
> https://github.com/gbbr/go/commit/2f6e92bc746fa232f2f2aea66dae3fa0c04700a5?diff=split
>  
> >>> 
> >>> Many thanks for looking! 
> >> 
> >> 
> > -- 
> > You received this message because you are subscribed to the Google 
> Groups 
> > "golang-nuts" group. 
> > To unsubscribe from this group and stop receiving emails from it, send 
> an 
> > email to golang-nuts...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

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

Re: [go-nuts] Gomobile and SAF

[Audrius Butkevicius]

This is more work than say writing a bit of C to instantiate a JVM in the
go process for example, and to get what we are after.

On 13 Oct 2017 06:41, "Jakob Borg"  wrote:

> On 12 Oct 2017, at 23:43, audrius.butkevic...@gmail.com wrote:
> >
> > Your example has a MainActivity.java.
> > As I said, this is a Go application, and as it stands it has no Java, so
> it doesn't have (and doesn't intend to have) a main activity.
> > Also, your initialization (Hello.initContentProvider) happens from Java
> (not from Go), so my question is still unanswered of how do do all of this
> purely from the Go side without reverse bindings.
>
> Maybe a solution in this case is to refactor the Go program to be a
> library (just moving package main to package app, and main.main() ->
> app.Run() or something) and then using dependency injection from the Java
> side.
>
> //jb

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