Re: [go-nuts] Koazee vs Go-Linq vs Go-Funk

[Marko Ristin-Kaufmann]

Thanks, Ivan! These numbers are very helpful! Could you at least give us a
hint why your library is faster than the other two? As far as I can see,
all three libraries in the benchmark use reflection.

On Tue, 4 Dec 2018 at 08:49, Iván Corrales Solera <
ivan.corrales.sol...@gmail.com> wrote:

> Hey all,
>
> I am working on Koazee, a library to deal with slices in a functional way.
> Since I published the very first release I was asked me for publishing a
> benchmark comparison with other existing and matured frameworks. that
> provide similar functionality.
>
> I hope you find useful this article:  Koazee vs Go-Linq vs Go-Funk
> 
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] Koazee vs Go-Linq vs Go-Funk

[Iván Corrales Solera]

Thanks for reply Marko,

Sure!  I think the approach of making validation smarter and generating 
code for primitive types was the key. 

Actually when you ask me for benchmark the first time, the performance was 
terrible! 

If we have a look at how operation Filter is implemented:

*Filter operation*
https://github.com/wesovilabs/koazee/tree/master/internal/filter
We find 3 files (this is basically the same for all the operations)

In the filter.go, my input is a reflection type and obviously I am required 
to do a validation in order to avoid an uncontrolled *panic*

I guess my validation function is smarter than other libraries, Why? 
Because of I cache some info


func (op *Filter) validate() (*filterInfo, *errors.Error) {
   item := &filterInfo{}
   fnType := reflect.TypeOf(op.Func)
   if val := cache.get(op.ItemsType, fnType); val != nil {
  return val, nil
   //.. Validations for input
   item.fnInputType = fnIn.Type()
   cache.add(op.ItemsType, fnType, item)
   return item, nil
}


By this "smart cache" I avoid to evaluate eternally the same things. I mean,

If my stream contains string's and the filter func looks like func(string)bool 
I only evaluate once 

because the output will be always the same


The dispatcher.go has been generated. This has been generated from 
repository koazee-gen 

What do I achieve with this generated code? That my operation are applied 
over a function that will work with primitive values instead of doing it 
with reflection
For example,

func filterString(itemsValue reflect.Value, function interface{}) interface{} {
   input := itemsValue.Interface().([]string)
   output := make([]string, 0)
   fn := function.(func(string) bool)
   for i := 0; i < len(input); i++ {
  if fn(input[i]) {
 output = append(output, input[i])
  }
   }
   return output
}


Since I have a function for any primitive type (or pointers too) the 
performance doesn't suffer the reflection cost


I've also put a lot of effort to find the best way to do any operation with 
the best performance. 

For example, for reverse operation  I could do

func reverseInt16Ptr(itemsValue reflect.Value) interface{}{
   input := itemsValue.Interface().([]*int16)
   len := len(input)
   output := make([]*int16, len)
   for index := 0; index < len(input); index++ {
  output[index]= input[len-1-index]
   }
   return output
}



but my generated function looks like below

func reverseInt16Ptr(itemsValue reflect.Value) interface{}{
   input := itemsValue.Interface().([]*int16)
   len := len(input)
   output := make([]*int16, len)
   for index := 0; index < (len/2)+1; index++ {
  output[index], output[len-1-index] = input[len-1-index], input[index]
   }
   return output
}



I think is the best approach. I reduce a half the time of elements to be 
evaluated

I am learning a lot of Go (and enjoying too)  with all your requests and 
suggestions and to be honest is so valuable when you achieve good results.


On roadmap , I would like to publish a richer set of operations for v0.0.3 
(I know my provided set of operations is poor)  and for v0.0.4  find a way 
to improve the performance for complex structs (I got a idea..)





On Tuesday, December 4, 2018 at 9:05:52 AM UTC+1, Marko Ristin wrote:
>
> Thanks, Ivan! These numbers are very helpful! Could you at least give us a 
> hint why your library is faster than the other two? As far as I can see, 
> all three libraries in the benchmark use reflection.
>
> On Tue, 4 Dec 2018 at 08:49, Iván Corrales Solera  > wrote:
>
>> Hey all,
>>
>> I am working on Koazee, a library to deal with slices in a functional 
>> way. Since I published the very first release I was asked me for publishing 
>> a benchmark comparison with other existing and matured frameworks. that 
>> provide similar functionality. 
>>
>> I hope you find useful this article:  Koazee vs Go-Linq vs Go-Funk  
>> 
>>
>> -- 
>> You received this message because you are subscribed 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] Koazee vs Go-Linq vs Go-Funk

[Iván Corrales Solera]

I would also state that Koazee is the only one that doesn't force you to 
cast data in your filter functions nor sort... because I understand the 
argument as an interface

instead of expect a function with arguments as the other 2 libraries do.

On Tuesday, December 4, 2018 at 12:27:14 PM UTC+1, Iván Corrales Solera 
wrote:
>
> Thanks for reply Marko,
>
> Sure!  I think the approach of making validation smarter and generating 
> code for primitive types was the key. 
>
> Actually when you ask me for benchmark the first time, the performance was 
> terrible! 
>
> If we have a look at how operation Filter is implemented:
>
> *Filter operation*
> https://github.com/wesovilabs/koazee/tree/master/internal/filter
> We find 3 files (this is basically the same for all the operations)
>
> In the filter.go, my input is a reflection type and obviously I am 
> required to do a validation in order to avoid an uncontrolled *panic*
>
> I guess my validation function is smarter than other libraries, Why? 
> Because of I cache some info
>
>
> func (op *Filter) validate() (*filterInfo, *errors.Error) {
>item := &filterInfo{}
>fnType := reflect.TypeOf(op.Func)
>if val := cache.get(op.ItemsType, fnType); val != nil {
>   return val, nil
>//.. Validations for input
>item.fnInputType = fnIn.Type()
>cache.add(op.ItemsType, fnType, item)
>return item, nil
> }
>
>
> By this "smart cache" I avoid to evaluate eternally the same things. I mean,
>
> If my stream contains string's and the filter func looks like 
> func(string)bool I only evaluate once 
>
> because the output will be always the same
>
>
> The dispatcher.go has been generated. This has been generated from 
> repository koazee-gen 
>
> What do I achieve with this generated code? That my operation are applied 
> over a function that will work with primitive values instead of doing it 
> with reflection
> For example,
>
> func filterString(itemsValue reflect.Value, function interface{}) interface{} 
> {
>input := itemsValue.Interface().([]string)
>output := make([]string, 0)
>fn := function.(func(string) bool)
>for i := 0; i < len(input); i++ {
>   if fn(input[i]) {
>  output = append(output, input[i])
>   }
>}
>return output
> }
>
>
> Since I have a function for any primitive type (or pointers too) the 
> performance doesn't suffer the reflection cost
>
>
> I've also put a lot of effort to find the best way to do any operation 
> with the best performance. 
>
> For example, for reverse operation  I could do
>
> func reverseInt16Ptr(itemsValue reflect.Value) interface{}{
>input := itemsValue.Interface().([]*int16)
>len := len(input)
>output := make([]*int16, len)
>for index := 0; index < len(input); index++ {
>   output[index]= input[len-1-index]
>}
>return output
> }
>
>
>
> but my generated function looks like below
>
> func reverseInt16Ptr(itemsValue reflect.Value) interface{}{
>input := itemsValue.Interface().([]*int16)
>len := len(input)
>output := make([]*int16, len)
>for index := 0; index < (len/2)+1; index++ {
>   output[index], output[len-1-index] = input[len-1-index], input[index]
>}
>return output
> }
>
>
>
> I think is the best approach. I reduce a half the time of elements to be 
> evaluated
>
> I am learning a lot of Go (and enjoying too)  with all your requests and 
> suggestions and to be honest is so valuable when you achieve good results.
>
>
> On roadmap , I would like to publish a richer set of operations for v0.0.3 
> (I know my provided set of operations is poor)  and for v0.0.4  find a way 
> to improve the performance for complex structs (I got a idea..)
>
>
>
>
>
> On Tuesday, December 4, 2018 at 9:05:52 AM UTC+1, Marko Ristin wrote:
>>
>> Thanks, Ivan! These numbers are very helpful! Could you at least give us 
>> a hint why your library is faster than the other two? As far as I can see, 
>> all three libraries in the benchmark use reflection.
>>
>> On Tue, 4 Dec 2018 at 08:49, Iván Corrales Solera <
>> ivan.corra...@gmail.com> wrote:
>>
>>> Hey all,
>>>
>>> I am working on Koazee, a library to deal with slices in a functional 
>>> way. Since I published the very first release I was asked me for publishing 
>>> a benchmark comparison with other existing and matured frameworks. that 
>>> provide similar functionality. 
>>>
>>> I hope you find useful this article:  Koazee vs Go-Linq vs Go-Funk  
>>> 
>>>
>>> -- 
>>> You received this message because you are subscribed 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-nut

[go-nuts] Best way to handle database transactions? (commit, or rollback on error)

[Tamás Gulácsi]

defer tx.Rollback()
...
tx.Commit() // at the end

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Best way to handle database transactions? (commit, or rollback on error)

[Manlio Perillo]

On Monday, December 3, 2018 at 10:53:30 PM UTC+1, Ben Hoyt wrote:
>
> Hi folks,
>
> We found some subtle bugs in our db transaction code for handling 
> commits/rollbacks. Here's the pattern we were using (not real, but shows 
> the issue):
>
> func DoTwoThings() error {
> tx, err := db.Begin()
> if err != nil {
> return err
> }
> // commit or rollback the transaction before we return
> defer tx.Close(&err)
>
> err := InsertFoo(tx)
> if err != nil {
> return err
> }
> if _, err := UpdateBar(tx); err != nil {
> return err
> }
> return nil
> }
>
> The problem is there's a subtle but potentially quite bad bug with this 
> usage pattern -- if the InsertFoo succeeds but UpdateBar fails, the first 
> "err" variable will be nil, so the deferred tx.Close() will COMMIT the 
> transaction rather than ROLLBACK, and the database will be in an 
> inconsistent state.
>
> The code above is a bit contrived, and you can easily fix it by moving the 
> "_, err := UpdateBar()" outside of the if so it's referring to the same 
> "err" variable, but it's very easy to miss and get it wrong. So we decided 
> it was a bad pattern and started thinking about the best way to fix.
>
>  
> [...]
 

> Another idea is to create a "Transact" function which takes an anonymous 
> function and does all the transaction handling:
>
> func (db *DatabaseImpl) Transact(txFunc func() error) (err error) {
> tx, err := db.Begin()
> if err != nil {
> return
> }
> defer func() {
> if p := recover(); p != nil {
> tx.Rollback()
> panic(p) // re-throw panic after Rollback
> } else if err != nil {
> tx.Rollback() // err is non-nil; don't change it
> } else {
> err = tx.Commit() // err is nil; if Commit returns error 
> update err
> }
> }()
> err = txFunc(tx)
> return err
> }
>
>
I'm using a similar function but with a different implementation:
https://play.golang.org/p/4t4ls8JH8Ss

Currently does not handle panics.
I'm still experimenting with the database/sql package.
One problem is what happens if the function needs to commit some code.

Should you use nested transaction?  Or should you use reference counting to 
only commit the last transaction?

> [...]

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] Generic function aliases

['Axel Wagner' via golang-nuts]

You can use
var Gi = g.G(int)
or you can use
func Gi(i int) error { return g.G(i) }
for the same effect. Which is pretty much the reason why alias-declarations
ended up only be added for types - all other declarations can already be
emulated sufficiently well. :)


On Mon, Dec 3, 2018 at 11:39 PM Liam Breck  wrote:

> Type aliases appear in the contracts draft design. Has anyone suggested
> alias declarations for generic functions? This would simplify syntax for
> callers...
>
> package g
>
> func G(type T)(i T) error { ... }
>
> ---
>
> package main
> import "g"
>
> func Gi g.G(int) // declare alias
>
> func f() {
>Gi(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.
>

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

[ssskip]

As Robert mention, that’s a design problem

U should 1. do pub/sub 2. do sharding

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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: Best way to handle database transactions? (commit, or rollback on error)

[Leonel Quinteros]

Hi Ben,

Sorry, I've misread that part.
Now that I got some sleep and reviewed your code a little bit more, it
looks like you got trapped by your own design decisions.

First of all, variable shadowing is something every Go developer should be
able to handle gracefully, but I understand your concern about how easy
it's to miss that bug. Doesn't the linter alert you about that shadowing
process? Just curious about that.

Then, the mistake, IMHO, is the use of the defer function and the custom
tx.Close method (is it custom made, right? I haven't found a reference for
that method in the sql.Tx type docs) that "saves" you from manually
handling tx.Commit() vs tx.Rollback() calls, which if you think, it gets
pretty well aligned to the error handling philosophy of Go. If you get an
error, please go ahead and explicitly handle that error.

So, your DoTwoThings() function is actually doing 3 things, the 2 things
against the DB, but it's also handling the transaction. If you see these 2
DB queries as a unit, you may want to put these in a method that takes a
sql.Tx object, executes queries in that context and return an error result
that will indicate if all of them were successful or not. Then you Commit
or Rollback the transaction in the caller, not in a deeper level.
So pretty much as your Transact() method, but I'm not a fan of the defer
use there, while I get how you managed to also catch panics there.
Out of your 2 proposals, I like this one better.

But if you ask me, I'd recommend to avoid the defer use, which is the thing
that's actually causing the shadowing problem, and to enforce the manually
handling of the transactions directly related to error handling. That's how
I've been doing it and it's pretty clear and straightforward when you read
that code, the Rollbacks after the errors and the Commits at the end of
each function are just there, explicitly telling you what's happening when
some DB query fails.

But again, it's a matter of opinion, design and personal preferences.
I just hope this helps for you to form an opinion.

Best!


*Leonel Quinteros*
Director of Technology
Global Brigades 



El lun., 3 de dic. de 2018 a la(s) 20:54, Ben Hoyt (benh...@gmail.com)
escribió:

> Robert, here is code (actual working code this time) similar to what we
> have: https://play.golang.org/p/jUPqgnk6Ttk
>
> Leonel, yep, I understand that, which is why we have this problem. The
> thing is, this pattern makes it very easy to forget to always re-use the
> same error variable, especially in code that's a bit more complex with a
> bunch of nested ifs, etc. So we're trying to come up with a pattern that's
> hard or impossible to misuse, instead of easy to misuse.
>
> -Ben
>
> On Mon, Dec 3, 2018 at 6:46 PM Leonel Quinteros <
> leonel.quinte...@gmail.com> wrote:
>
>> Hi Ben,
>>
>> I'm pretty sure that the *err* variable is getting shadowed on your
>> Update construct.
>> Instead of doing:
>>
>> if _, err := UpdateBar(tx); err != nil {
>> return err
>> }
>>
>> You should do something like:
>>
>> _, err = UpdateBar(tx)
>> if err != nil {
>> return err
>> }
>>
>> Just like you do with the insert and avoiding the *:=* operand
>>
>> Let me know if that works.
>>
>>
>> Best!
>> Leonel
>>
>>
>> El lunes, 3 de diciembre de 2018, 18:53:30 (UTC-3), Ben Hoyt escribió:
>>>
>>> Hi folks,
>>>
>>> We found some subtle bugs in our db transaction code for handling
>>> commits/rollbacks. Here's the pattern we were using (not real, but shows
>>> the issue):
>>>
>>> func DoTwoThings() error {
>>> tx, err := db.Begin()
>>> if err != nil {
>>> return err
>>> }
>>> // commit or rollback the transaction before we return
>>> defer tx.Close(&err)
>>>
>>> err := InsertFoo(tx)
>>> if err != nil {
>>> return err
>>> }
>>> if _, err := UpdateBar(tx); err != nil {
>>> return err
>>> }
>>> return nil
>>> }
>>>
>>> The problem is there's a subtle but potentially quite bad bug with this
>>> usage pattern -- if the InsertFoo succeeds but UpdateBar fails, the first
>>> "err" variable will be nil, so the deferred tx.Close() will COMMIT the
>>> transaction rather than ROLLBACK, and the database will be in an
>>> inconsistent state.
>>>
>>> The code above is a bit contrived, and you can easily fix it by moving
>>> the "_, err := UpdateBar()" outside of the if so it's referring to the same
>>> "err" variable, but it's very easy to miss and get it wrong. So we decided
>>> it was a bad pattern and started thinking about the best way to fix.
>>>
>>> One idea is a RollbackUnlessCommitted() function which you can defer,
>>> and then you call Commit() once manually (stolen from gocraft/dbr):
>>>
>>> func DoTwoThings() error {
>>> tx, err := db.Begin()
>>> if err != nil {
>>> return err
>>> }
>>> defer tx.RollbackUnlessCommitted()
>>>
>>> err := InsertFoo(tx)
>>> if err != nil {
>>> return err
>>> }
>>> if _, err 

Re: [go-nuts] Re: Best way to handle database transactions? (commit, or rollback on error)

[Ben Hoyt]

Helpful comments and good suggestion, thanks Leonel. -Ben

On Tue, Dec 4, 2018 at 9:15 AM Leonel Quinteros 
wrote:

> Hi Ben,
>
> Sorry, I've misread that part.
> Now that I got some sleep and reviewed your code a little bit more, it
> looks like you got trapped by your own design decisions.
>
> First of all, variable shadowing is something every Go developer should be
> able to handle gracefully, but I understand your concern about how easy
> it's to miss that bug. Doesn't the linter alert you about that shadowing
> process? Just curious about that.
>
> Then, the mistake, IMHO, is the use of the defer function and the custom
> tx.Close method (is it custom made, right? I haven't found a reference for
> that method in the sql.Tx type docs) that "saves" you from manually
> handling tx.Commit() vs tx.Rollback() calls, which if you think, it gets
> pretty well aligned to the error handling philosophy of Go. If you get an
> error, please go ahead and explicitly handle that error.
>
> So, your DoTwoThings() function is actually doing 3 things, the 2 things
> against the DB, but it's also handling the transaction. If you see these 2
> DB queries as a unit, you may want to put these in a method that takes a
> sql.Tx object, executes queries in that context and return an error result
> that will indicate if all of them were successful or not. Then you Commit
> or Rollback the transaction in the caller, not in a deeper level.
> So pretty much as your Transact() method, but I'm not a fan of the defer
> use there, while I get how you managed to also catch panics there.
> Out of your 2 proposals, I like this one better.
>
> But if you ask me, I'd recommend to avoid the defer use, which is the
> thing that's actually causing the shadowing problem, and to enforce the
> manually handling of the transactions directly related to error handling.
> That's how I've been doing it and it's pretty clear and straightforward
> when you read that code, the Rollbacks after the errors and the Commits at
> the end of each function are just there, explicitly telling you what's
> happening when some DB query fails.
>
> But again, it's a matter of opinion, design and personal preferences.
> I just hope this helps for you to form an opinion.
>
> Best!
>
>
> *Leonel Quinteros*
> Director of Technology
> Global Brigades 
>
>
>
> El lun., 3 de dic. de 2018 a la(s) 20:54, Ben Hoyt (benh...@gmail.com)
> escribió:
>
>> Robert, here is code (actual working code this time) similar to what we
>> have: https://play.golang.org/p/jUPqgnk6Ttk
>>
>> Leonel, yep, I understand that, which is why we have this problem. The
>> thing is, this pattern makes it very easy to forget to always re-use the
>> same error variable, especially in code that's a bit more complex with a
>> bunch of nested ifs, etc. So we're trying to come up with a pattern that's
>> hard or impossible to misuse, instead of easy to misuse.
>>
>> -Ben
>>
>> On Mon, Dec 3, 2018 at 6:46 PM Leonel Quinteros <
>> leonel.quinte...@gmail.com> wrote:
>>
>>> Hi Ben,
>>>
>>> I'm pretty sure that the *err* variable is getting shadowed on your
>>> Update construct.
>>> Instead of doing:
>>>
>>> if _, err := UpdateBar(tx); err != nil {
>>> return err
>>> }
>>>
>>> You should do something like:
>>>
>>> _, err = UpdateBar(tx)
>>> if err != nil {
>>> return err
>>> }
>>>
>>> Just like you do with the insert and avoiding the *:=* operand
>>>
>>> Let me know if that works.
>>>
>>>
>>> Best!
>>> Leonel
>>>
>>>
>>> El lunes, 3 de diciembre de 2018, 18:53:30 (UTC-3), Ben Hoyt escribió:

 Hi folks,

 We found some subtle bugs in our db transaction code for handling
 commits/rollbacks. Here's the pattern we were using (not real, but shows
 the issue):

 func DoTwoThings() error {
 tx, err := db.Begin()
 if err != nil {
 return err
 }
 // commit or rollback the transaction before we return
 defer tx.Close(&err)

 err := InsertFoo(tx)
 if err != nil {
 return err
 }
 if _, err := UpdateBar(tx); err != nil {
 return err
 }
 return nil
 }

 The problem is there's a subtle but potentially quite bad bug with this
 usage pattern -- if the InsertFoo succeeds but UpdateBar fails, the first
 "err" variable will be nil, so the deferred tx.Close() will COMMIT the
 transaction rather than ROLLBACK, and the database will be in an
 inconsistent state.

 The code above is a bit contrived, and you can easily fix it by moving
 the "_, err := UpdateBar()" outside of the if so it's referring to the same
 "err" variable, but it's very easy to miss and get it wrong. So we decided
 it was a bad pattern and started thinking about the best way to fix.

 One idea is a RollbackUnlessCommitted() function which you can defer,
 and then you call Commit() once manually (stolen from goc

Re: [go-nuts] Documentation/tutorials on building and including precompiled .syso files in packages

[jclc via golang-nuts]

I'm very sorry for replying to this old thread, I forgot to post a reply 
earlier.

Unfortunately your reply doesn't really explain much that I didn't already 
know. Simply put, I have two questions.

Firstly, can precompiled .syso files be used to obviate the need for a 
C-compiler entirely for the package user, or will you still need a 
C-compiler and/or linker if a Go package has .syso files?

Secondly, is there a concrete example of a project where some source files 
are compiled into a .syso file? If someone could just point me to a 
makefile, that would probably show me all I need to know. I recall seeing 
some .syso files in the compiler source tree but could not find a makefile 
or sources for them.

On Tuesday, October 30, 2018 at 6:33:21 AM UTC+2, Ian Lance Taylor wrote:
>
> On Sun, Oct 28, 2018 at 1:20 PM, jclc via golang-nuts 
> > wrote: 
> > 
> > There is an initiative to remove the requirement of having a C compiler 
> for 
> > certain CGO packages and this seems like a somewhat common thing to do, 
> even 
> > the Go race condition detector ships as a pre-built C blob in the Go 
> source 
> > tree. Yet I can't find any documentation on how to actually do this. 
> > 
> > How should .syso files be built? Where should the C code live (Go 
> complains 
> > if C source files exist in the package directory)? How does the Go 
> linker 
> > find the correct symbols? Is there any concrete documentation or a 
> tutorial 
> > on how to do this? 
>
> There are no guidelines for how to build .syso files, and the C code 
> can live anywhere.  The .syso file will be built by some mechanism 
> other than the go tool, such as make.  The .syso file can be copied 
> into the Go package.  It will be linked into the Go program.  A 
> typical use would involve using cgo (https://golang.org/cmd/cgo) to 
> call into the .syso. 
>
> 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] Koazee vs Go-Linq vs Go-Funk

[Robert Engels]

Shouldn’t this code be index = index+ 2

for index := 0; index < (len/2)+1; index++ {
output[index], output[len-1-index] = input[len-1-index], input[index]
}
And the loop needs to go to Len - you are only copying half the elements

> On Dec 4, 2018, at 5:27 AM, Iván Corrales Solera 
>  wrote:
> 
> for index := 0; index < (len/2)+1; index++ {
> output[index], output[len-1-index] = input[len-1-index], input[index]
> }

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

[Robert Engels]

Sorry, I see it is going from both ends... too early :)

> On Dec 4, 2018, at 8:33 AM, Robert Engels  wrote:
> 
> Shouldn’t this code be index = index+ 2
> 
> for index := 0; index < (len/2)+1; index++ {
> output[index], output[len-1-index] = input[len-1-index], input[index]
> }
> And the loop needs to go to Len - you are only copying half the elements
> 
>> On Dec 4, 2018, at 5:27 AM, Iván Corrales Solera 
>>  wrote:
>> 
>> for index := 0; index < (len/2)+1; index++ {
>> output[index], output[len-1-index] = input[len-1-index], input[index]
>> }
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and 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] Koazee vs Go-Linq vs Go-Funk

[Iván Corrales Solera]

No worries! ahaha It's ok

On Tue, Dec 4, 2018 at 3:39 PM Robert Engels  wrote:

> Sorry, I see it is going from both ends... too early :)
>
> On Dec 4, 2018, at 8:33 AM, Robert Engels  wrote:
>
> Shouldn’t this code be index = index+ 2
>
> for index := 0; index < (len/2)+1; index++ {
>   output[index], output[len-1-index] = input[len-1-index], input[index]
>}
>
> And the loop needs to go to Len - you are only copying half the elements
>
>
> On Dec 4, 2018, at 5:27 AM, Iván Corrales Solera <
> ivan.corrales.sol...@gmail.com> wrote:
>
> for index := 0; index < (len/2)+1; index++ {
> output[index], output[len-1-index] = input[len-1-index], input[index]
> }
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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] Documentation/tutorials on building and including precompiled .syso files in packages

[Ian Lance Taylor]

On Tue, Dec 4, 2018 at 6:22 AM jclc via golang-nuts
 wrote:
>
> I'm very sorry for replying to this old thread, I forgot to post a reply 
> earlier.
>
> Unfortunately your reply doesn't really explain much that I didn't already 
> know. Simply put, I have two questions.
>
> Firstly, can precompiled .syso files be used to obviate the need for a 
> C-compiler entirely for the package user, or will you still need a C-compiler 
> and/or linker if a Go package has .syso files?

Yes, in general you will need a C compiler if the Go package has .syso
files.  The compiler will be run to invoke the C linker.


> Secondly, is there a concrete example of a project where some source files 
> are compiled into a .syso file? If someone could just point me to a makefile, 
> that would probably show me all I need to know. I recall seeing some .syso 
> files in the compiler source tree but could not find a makefile or sources 
> for them.

If it helps, the .syso files in the standard library are built by
https://github.com/llvm-mirror/compiler-rt/blob/master/lib/tsan/go/buildgo.sh
.

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] Is it possible with go modules to `go get` the ref (not the SHA) of an GitHub PR?

[mark]

I have a private github repository that depends on an open source github 
repository. There's an open PR in the open source repo, and I'd like to `go 
get` that change to test it locally in my private repo.

Normally, when I update the open source repository, I can just run `go get 
github.com/MY_ORG/MY_OSS_REPO@`. If I use the full SHA of 
the most recent commit in the PR, this works fine. 

But I can't get it to work for variations of `go get 
github.com/ORG/REPO@{refs/,}pull/123{,/head}`, following the instructions 
at https://help.github.com/articles/checking-out-pull-requests-locally/ 
and https://stackoverflow.com/q/6743514. I get the impression that there's 
something special about the pull refs that you have to request them 
directly, since they don't get pulled during a plain `git fetch` during 
normal repository work.

I would prefer to use the direct PR ref, rather than the SHA. I can figure 
out how to script retrieving the SHA from the PR number, so I have a valid 
workaround, but I thought I'd ask here to see if maybe I missed some 
obvious way to go get by PR number.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Documentation/tutorials on building and including precompiled .syso files in packages

[jclc via golang-nuts]

Thank you very much!

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

[Liam Breck]

Ah yes, var works. But it should be const, since func names aren't
variables.

On Tue, Dec 4, 2018, 5:40 AM Axel Wagner  You can use
> var Gi = g.G(int)
> or you can use
> func Gi(i int) error { return g.G(i) }
> for the same effect. Which is pretty much the reason why
> alias-declarations ended up only be added for types - all other
> declarations can already be emulated sufficiently well. :)
>
>
> On Mon, Dec 3, 2018 at 11:39 PM Liam Breck  wrote:
>
>> Type aliases appear in the contracts draft design. Has anyone suggested
>> alias declarations for generic functions? This would simplify syntax for
>> callers...
>>
>> package g
>>
>> func G(type T)(i T) error { ... }
>>
>> ---
>>
>> package main
>> import "g"
>>
>> func Gi g.G(int) // declare alias
>>
>> func f() {
>>Gi(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.
>>
>

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

[Alex Dvoretskiy]

Hi Golangnuts,

I'm trying to implement kind of pipe function, using channels

Do you think this would be a correct conception:

func Pipe(fs ...task) {

ch1 := make(chan interface{})
ch2 := make(chan interface{})

for _, f := range fs {
ch1, ch2 = ch2, ch1
go f(ch1, ch2)
}
}



Can you also explain why the function 2 and 3 don't go through the end? "f2 
end", "f3 end" not printed :(

https://play.golang.org/p/g5lL9xiM_-q

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

[messju mohr]

Erm, function names may be const, but functions are first class citizen types 
and can of course be assigned to variables and be passed around.

just my 2c

On Tue, Dec 04, 2018 at 10:27:19AM -0800, Liam Breck wrote:
>Ah yes, var works. But it should be const, since func names aren't
>variables.
>On Tue, Dec 4, 2018, 5:40 AM Axel Wagner <[1]axel.wagner...@googlemail.com
>wrote:
> 
>  You can use
>  var Gi = g.G(int)
>  or you can use
>  func Gi(i int) error { return g.G(i) }
>  for the same effect. Which is pretty much the reason why
>  alias-declarations ended up only be added for types - all other
>  declarations can already be emulated sufficiently well. :)
>  On Mon, Dec 3, 2018 at 11:39 PM Liam Breck <[2]l...@networkimprov.net>
>  wrote:
> 
>Type aliases appear in the contracts draft design. Has anyone
>suggested alias declarations for generic functions? This would
>simplify syntax for callers...
>package g
>func G(type T)(i T) error { ... }
>---
>package main
>import "g"
>func Gi g.G(int) // declare alias
>func f() {
>   Gi(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 [3]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [4]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 [5]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [6]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. mailto:axel.wagner...@googlemail.com
>2. mailto:l...@networkimprov.net
>3. mailto:golang-nuts+unsubscr...@googlegroups.com
>4. https://groups.google.com/d/optout
>5. mailto:golang-nuts+unsubscr...@googlegroups.com
>6. 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] Generic function aliases

[Liam Breck]

I meant this should work

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

On Tue, Dec 4, 2018, 11:21 AM messju mohr  Erm, function names may be const, but functions are first class citizen
> types and can of course be assigned to variables and be passed around.
>
> just my 2c
>
> On Tue, Dec 04, 2018 at 10:27:19AM -0800, Liam Breck wrote:
> >Ah yes, var works. But it should be const, since func names aren't
> >variables.
> >On Tue, Dec 4, 2018, 5:40 AM Axel Wagner <[1]
> axel.wagner...@googlemail.com
> >wrote:
> >
> >  You can use
> >  var Gi = g.G(int)
> >  or you can use
> >  func Gi(i int) error { return g.G(i) }
> >  for the same effect. Which is pretty much the reason why
> >  alias-declarations ended up only be added for types - all other
> >  declarations can already be emulated sufficiently well. :)
> >  On Mon, Dec 3, 2018 at 11:39 PM Liam Breck <[2]
> l...@networkimprov.net>
> >  wrote:
> >
> >Type aliases appear in the contracts draft design. Has anyone
> >suggested alias declarations for generic functions? This would
> >simplify syntax for callers...
> >package g
> >func G(type T)(i T) error { ... }
> >---
> >package main
> >import "g"
> >func Gi g.G(int) // declare alias
> >func f() {
> >   Gi(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 [3]golang-nuts+unsubscr...@googlegroups.com.
> >For more options, visit [4]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 [5]golang-nuts+unsubscr...@googlegroups.com.
> >For more options, visit [6]https://groups.google.com/d/optout.
> >
> > References
> >
> >Visible links
> >1. mailto:axel.wagner...@googlemail.com
> >2. mailto:l...@networkimprov.net
> >3. mailto:golang-nuts+unsubscr...@googlegroups.com
> >4. https://groups.google.com/d/optout
> >5. mailto:golang-nuts+unsubscr...@googlegroups.com
> >6. 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] concurent pipe

[Burak Serdar]

On Tue, Dec 4, 2018 at 11:57 AM Alex Dvoretskiy  wrote:
>
> Hi Golangnuts,
>
> I'm trying to implement kind of pipe function, using channels
>
> Do you think this would be a correct conception:
>
> func Pipe(fs ...task) {
>
> ch1 := make(chan interface{})
> ch2 := make(chan interface{})
>
> for _, f := range fs {
> ch1, ch2 = ch2, ch1
> go f(ch1, ch2)
> }
> }
>

It is not. You need a separate channel for each connection:

var in,out chan interface{}
for _,f:=range fs {
   out=make(chan interface{})
   go f(in,out)
   in=out
}

You don't ever use the first input channel, if you do, you need to
initialize that as well.

>
>
> Can you also explain why the function 2 and 3 don't go through the end? "f2 
> end", "f3 end" not printed :(
>
> https://play.golang.org/p/g5lL9xiM_-q


Because f2 and f3 range over a channel, and the for loops never
terminate. The for loop ends when the channel is closed. You need to
close the out channel for each f() once they're done, so the reader
would know it ended.


>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and 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] Documentation/tutorials on building and including precompiled .syso files in packages

[lakk . jl]

Thank you very much!

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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 convert or typecast windows handle/fd to net.conn

[apmattil]

Hi

My problem is following: I need to use windows WSAAccept() instead of 
normal accept (net package seems to use AcceptEx).

I'm I missing somethig 

I do not know a way to extend net-package so only way I know is to use 
reflect to get the listener Sysfd (I know .. really bad, other options ?) 
and pass it to WSAAccept().

Now I get the new handle/fd back and to be able to use rest of the code I 
would need to convert it to net.conn, how can I do this ?

In general, how can we extend net package when all important structures are 
private ? fd_windows.go:netFD struct includes poll.FD what is even deeper 
at package chain.

Br,
Ari

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

['Axel Wagner' via golang-nuts]

This was considered (or rather, the `func g = f` syntax), but ultimately it
was decided that the current ways to forward functions are good enough :)
Either use var, or if you are uncomfortable with having that
*theoretically* mutable, wrap it directly (it should get inlined, so
there's no cost apart from writing the wrapper).

On Tue, Dec 4, 2018 at 8:34 PM Liam Breck  wrote:

> I meant this should work
>
> https://play.golang.org/p/w6MBzP9RNdH
>
> On Tue, Dec 4, 2018, 11:21 AM messju mohr 
>> Erm, function names may be const, but functions are first class citizen
>> types and can of course be assigned to variables and be passed around.
>>
>> just my 2c
>>
>> On Tue, Dec 04, 2018 at 10:27:19AM -0800, Liam Breck wrote:
>> >Ah yes, var works. But it should be const, since func names aren't
>> >variables.
>> >On Tue, Dec 4, 2018, 5:40 AM Axel Wagner <[1]
>> axel.wagner...@googlemail.com
>> >wrote:
>> >
>> >  You can use
>> >  var Gi = g.G(int)
>> >  or you can use
>> >  func Gi(i int) error { return g.G(i) }
>> >  for the same effect. Which is pretty much the reason why
>> >  alias-declarations ended up only be added for types - all other
>> >  declarations can already be emulated sufficiently well. :)
>> >  On Mon, Dec 3, 2018 at 11:39 PM Liam Breck <[2]
>> l...@networkimprov.net>
>> >  wrote:
>> >
>> >Type aliases appear in the contracts draft design. Has anyone
>> >suggested alias declarations for generic functions? This would
>> >simplify syntax for callers...
>> >package g
>> >func G(type T)(i T) error { ... }
>> >---
>> >package main
>> >import "g"
>> >func Gi g.G(int) // declare alias
>> >func f() {
>> >   Gi(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 [3]golang-nuts+unsubscr...@googlegroups.com.
>> >For more options, visit [4]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 [5]golang-nuts+unsubscr...@googlegroups.com.
>> >For more options, visit [6]https://groups.google.com/d/optout.
>> >
>> > References
>> >
>> >Visible links
>> >1. mailto:axel.wagner...@googlemail.com
>> >2. mailto:l...@networkimprov.net
>> >3. mailto:golang-nuts+unsubscr...@googlegroups.com
>> >4. https://groups.google.com/d/optout
>> >5. mailto:golang-nuts+unsubscr...@googlegroups.com
>> >6. 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: concurent pipe

[Alex Dvoretskiy]

Thanks, Burak. Great explanation!

On Tuesday, December 4, 2018 at 10:57:03 AM UTC-8, Alex Dvoretskiy wrote:
>
> Hi Golangnuts,
>
> I'm trying to implement kind of pipe function, using channels
>
> Do you think this would be a correct conception:
>
> func Pipe(fs ...task) {
>
> ch1 := make(chan interface{})
> ch2 := make(chan interface{})
>
> for _, f := range fs {
> ch1, ch2 = ch2, ch1
> go f(ch1, ch2)
> }
> }
>
>
>
> Can you also explain why the function 2 and 3 don't go through the end? "f2 
> end", "f3 end" not printed :(
>
> https://play.golang.org/p/g5lL9xiM_-q
>
>

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

[Alex Dvoretskiy]

I'm getting "fatal error: all goroutines are asleep - deadlock! on this 
code. 

Why?

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

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

[Burak Serdar]

On Tue, Dec 4, 2018 at 4:52 PM Alex Dvoretskiy  wrote:
>
> I'm getting "fatal error: all goroutines are asleep - deadlock! on this code.
>
> Why?
>
> https://play.golang.org/p/KgJKu96PF7Q


close(out) when a task ends.

Also, you don't need to pass wg to the goroutine:

https://play.golang.org/p/0K3T7n13emQ

> To unsubscribe from this group and 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] build go in Intellij

[robert engels]

Hi, anyone on the list know how, or can point me to documentation, on building 
Go itself in Intellij?

By that I mean, I want to make changes to the standard lib, or tools 
(specifically trace), and just compile that tool, tests, etc, work in Intellij.

Right now, when I fork golang/go and open in Intellij I get errors like:




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] build go in Intellij

[robert engels]

I also get errors like:



even though the strings package shows a being imported correctly.

> On Dec 4, 2018, at 6:37 PM, robert engels  wrote:
> 
> Hi, anyone on the list know how, or can point me to documentation, on 
> building Go itself in Intellij?
> 
> By that I mean, I want to make changes to the standard lib, or tools 
> (specifically trace), and just compile that tool, tests, etc, work in 
> Intellij.
> 
> Right now, when I fork golang/go and open in Intellij I get errors like:
> 
> 
> 
> 
> 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.

[go-nuts] GitHub Golang color

[littleheart]

Hello,

I opened an pull request on https://github.com/github/linguist to improve 
Golang color on GitHub: Improve Golang color #4331 

The actual color (#375EAB) doesn't fit to the official Golang's color (
#00ADD8) according to Golang's style guide 

.

I open this topic to have your opinions on this change.

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

[Alex Dvoretskiy]

Thanks.
One question, we do "defer close(out)", but we don't close "in" channel. 
Why garbage collector don't remove "out" channel? We don't write nothing to 
it in function 3. So it should be empty.

On Tuesday, December 4, 2018 at 3:52:45 PM UTC-8, Alex Dvoretskiy wrote:
>
> I'm getting "fatal error: all goroutines are asleep - deadlock! on this 
> code. 
>
> Why?
>
> https://play.golang.org/p/KgJKu96PF7Q
>

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

[Burak Serdar]

On Tue, Dec 4, 2018 at 5:54 PM Alex Dvoretskiy  wrote:
>
> Thanks.
> One question, we do "defer close(out)", but we don't close "in" channel. Why 
> garbage collector don't remove "out" channel? We don't write nothing to it in 
> function 3. So it should be empty.

closing a channel sends a signal through the channel that no more data
will be coming, so any goroutines waiting on that channel can resume.
Without close, a for loop waiting on a channel will wait indefinitely.

A channel will be garbage collected once all references to it are
gone, whether it is closed or not.



>
> On Tuesday, December 4, 2018 at 3:52:45 PM UTC-8, Alex Dvoretskiy wrote:
>>
>> I'm getting "fatal error: all goroutines are asleep - deadlock! on this code.
>>
>> Why?
>>
>> https://play.golang.org/p/KgJKu96PF7Q
>
> --
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and 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] I want to set the position of the window in GUI display of golang

[mdi . kato]

Hi
I'm Japanese, so sorry if my English is wrong.

I'm try to display GUI window with WALK(github.com/lxn/walk).
But there is a problem dose not go well.

If you run this code, maybe the window displayed upper left of screen.
I want to set the position of the window in center of screen.
What should i do?


import ( "github.com/lxn/walk" . "github.com/lxn/walk/declarative" ) type 
MyLoadWindow struct { *walk.MainWindow progressBar *walk.ProgressBar } func 
Main() { mw := &MyLoadWindow{} // 画面情報設定 MW := MainWindow{ AssignTo: 
&mw.MainWindow, // Widgetを実体に割り当て Title: "コンピュータの情報を取得中", Size: Size{ 300, 
100}, Font: Font{PointSize: 12}, Layout: VBox{}, Children: []Widget{ // 
ウィジェットを入れるスライス ProgressBar{ AssignTo: &mw.progressBar, MarqueeMode: true, 
}, }, } if _, err := MW.Run(); err != nil { println("Error") return } }


If someone know solution, please show me.
thank 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] I want to set the position of the window in GUI display of golang

[Robert Engels]

You should probably file an issue at 

http://github.com/lxn/walk

They don’t seem to have a community forum, but I think the author could help 
you easily. Also you could try stack overflow as there are a few questions 
about this library there. 

> On Dec 4, 2018, at 7:44 PM, mdi.k...@gmail.com wrote:
> 
> Hi
> I'm Japanese, so sorry if my English is wrong.
> 
> I'm try to display GUI window with WALK(github.com/lxn/walk).
> But there is a problem dose not go well.
> 
> If you run this code, maybe the window displayed upper left of screen.
> I want to set the position of the window in center of screen.
> What should i do?
> 
> 
> 
> import (
> "github.com/lxn/walk"
> . "github.com/lxn/walk/declarative"
> )
> 
> type MyLoadWindow struct {
> *walk.MainWindow
> progressBar *walk.ProgressBar
> }
> 
> func Main() {
> mw := &MyLoadWindow{}
> 
> 
> // 画面情報設定
> MW := MainWindow{
> AssignTo: &mw.MainWindow, // Widgetを実体に割り当て
> Title:"コンピュータの情報を取得中",
> Size: Size{
> 300,
> 100},
> Font:   Font{PointSize: 12},
> Layout: VBox{},
> 
> Children: []Widget{ // ウィジェットを入れるスライス
> 
> ProgressBar{
> AssignTo:&mw.progressBar,
> MarqueeMode: true,
> },
> },
> }
> 
> if _, err := MW.Run(); err != nil {
> println("Error")
> return
> }
> }
> 
> 
> If someone know solution, please show me.
> thank 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.

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