Re: [go-nuts] Create methods for structs at runtime

[Ian Lance Taylor]

On Tue, Jun 13, 2017 at 9:27 PM, Dat Huynh  wrote:
>
> I have a question about Go.
>
> Given an interface, how can I create a struct instance with the methods of
> the interface at runtime?
>
> After reading the document of Go on the web page
> https://golang.org/pkg/reflect/#StructOf
> I see the below statement.
>
> "StructOf currently does not generate wrapper methods for embedded fields.
> This limitation may be lifted in a future version."
>
> It means that I cannot do it with the current version of Go.
> Am I correct?

I believe you are correct.

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] Create methods for structs at runtime

[Dat Huynh]

Hi all,

I have a question about Go.

Given an interface, how can I create a struct instance with the methods of 
the interface at runtime?

After reading the document of Go on the web page
https://golang.org/pkg/reflect/#StructOf
I see the below statement.

"StructOf currently does not generate wrapper methods for embedded fields. 
This limitation may be lifted in a future version."

It means that I cannot do it with the current version of Go.
Am I correct?

Thank you very much.

Sincerely,
Dat.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] Problem with building Go1.4.3 in OpenBSD/386

[Henry]

Thanks for the reply, Ian.

I'll take a look at it. There is a Go1.8 binary package in OpenBSD's port 
collection. So, obviously someone has made it work somehow. 

On Wednesday, June 14, 2017 at 2:35:54 AM UTC+8, Ian Lance Taylor wrote:
>
> On Tue, Jun 13, 2017 at 8:42 AM, Henry  > wrote: 
> > 
> > I have problems with building Go toolchain (Go1.4.3) on my older 
> OpenBSD/386 
> > machine. Any idea how to make this works? 
> > 
> >> 
> >> # Building packages and commands for openbsd/386. 
> >> runtime 
> >> ./make.bash: line 174: 99548 Illegal instruction (core dumped) 
> >> CC=$CC_FOR_TARGET "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags 
> >> "$GO_CCFLAGS" -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std 
>
> This error implies that the newly build Go compiler builds programs 
> that do not run on your system.  There isn't enough information here 
> to know why they don't run.  Since you say you are using an older 386 
> machine, try setting GO386=387 in the environment.  It probably won't 
> help, but it's worth a try.  Beyond that,  you'll need to debug the 
> program to find out what the illegal instruction is. 
>
> 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] reflect.Type.Field() order

[akalin]

On Tuesday, June 13, 2017 at 2:33:00 PM UTC-5, Ian Lance Taylor wrote:
>
>
> It's the order in which the fields appear in the struct declaration. 
> It's not going to change.  If you find a case where it is *not* the 
> order in the declaration, please file a bug.  Thanks. 
>
> Ian 
>

Thanks for the clarification. After some further digging, this turned out 
to be a bug in how the serialization library handles embedded structs.

-- Fred

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] reflect.Type.Field() order

[Ian Lance Taylor]

On Tue, Jun 13, 2017 at 8:24 AM,   wrote:
>
> https://golang.org/pkg/reflect/#Value.Field says "Field returns the i'th
> field of the struct v.". Are there any guarantees as to what the ordering of
> the i'th field is? If not, does anyone know what the current behavior is,
> and whether it may change in the future? Is there a way to get the fields in
> declaration order?
>
> Looking around online turned up
> https://stackoverflow.com/questions/32392311/reflect-type-field-order ,
> which didn't come to any conclusion.
>
> I'm asking because a serialization library I'm using uses the above field
> order when serializing structs as arrays, and I encountered a case where it
> seems to diverge from declaration order. If this is something that may
> change in the future, the users of that library (and anything like it) would
> probably break...

It's the order in which the fields appear in the struct declaration.
It's not going to change.  If you find a case where it is *not* the
order in the declaration, please file a bug.  Thanks.

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] Fast string sorting

[Stefan Nilsson]

That's an interesting challenge! What the algorithm really does is to first 
find a permutation that will sort the string slice, and then apply this 
permutation to the slice. Perhaps it would be possible to return this 
permutation in some cheap usable format.

On Tuesday, June 13, 2017 at 7:56:54 PM UTC+2, Thomas Bushnell, BSG wrote:
>
> That's really nice!
>
> Consider a case where I am sorting a slice of structs, but the underlying 
> sort is based on a string within the structs. Or, with some other radixable 
> datatype besides strings.
>
> Can we figure out an interface (similar to sort.Interface) which would 
> permit a solution for either or both of these cases? The former should be 
> fairly simple to do without sacrificing the speedup; the latter might be 
> trickier.
>
> Thomas
>
>
> On Tue, Jun 13, 2017 at 6:20 AM Stefan Nilsson  > wrote:
>
>> It's well known that radix sort can be faster than comparison-based 
>> methods for string sorting. With that in mind, I wrote this optimized 
>> version of MSD radix sort:
>>
>> https://github.com/yourbasic/radix
>>
>> It's equivalent to sort.Strings in the standard library and on my machine 
>> it's twice as fast as when sorting King James Bible and four times as fast 
>> for the 1k benchmark in the sort package. Of course I can't promise similar 
>> performance in other settings, but Go get it if you like.
>>
>> Stefan
>>
>> -- 
>> You received this message because you are subscribed 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] Problem with building Go1.4.3 in OpenBSD/386

[Ian Lance Taylor]

On Tue, Jun 13, 2017 at 8:42 AM, Henry  wrote:
>
> I have problems with building Go toolchain (Go1.4.3) on my older OpenBSD/386
> machine. Any idea how to make this works?
>
>>
>> # Building packages and commands for openbsd/386.
>> runtime
>> ./make.bash: line 174: 99548 Illegal instruction (core dumped)
>> CC=$CC_FOR_TARGET "$GOTOOLDIR"/go_bootstrap install $GO_FLAGS -ccflags
>> "$GO_CCFLAGS" -gcflags "$GO_GCFLAGS" -ldflags "$GO_LDFLAGS" -v std

This error implies that the newly build Go compiler builds programs
that do not run on your system.  There isn't enough information here
to know why they don't run.  Since you say you are using an older 386
machine, try setting GO386=387 in the environment.  It probably won't
help, but it's worth a try.  Beyond that,  you'll need to debug the
program to find out what the illegal instruction is.

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] Fast string sorting

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

That's really nice!

Consider a case where I am sorting a slice of structs, but the underlying
sort is based on a string within the structs. Or, with some other radixable
datatype besides strings.

Can we figure out an interface (similar to sort.Interface) which would
permit a solution for either or both of these cases? The former should be
fairly simple to do without sacrificing the speedup; the latter might be
trickier.

Thomas


On Tue, Jun 13, 2017 at 6:20 AM Stefan Nilsson 
wrote:

> It's well known that radix sort can be faster than comparison-based
> methods for string sorting. With that in mind, I wrote this optimized
> version of MSD radix sort:
>
> https://github.com/yourbasic/radix
>
> It's equivalent to sort.Strings in the standard library and on my machine
> it's twice as fast as when sorting King James Bible and four times as fast
> for the 1k benchmark in the sort package. Of course I can't promise similar
> performance in other settings, but Go get it if you like.
>
> Stefan
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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: mixed C / Go debugging

[Alain Mellan]

Haha, I agree, Printf is my debugging tool of choice, but some in my team 
like debuggers ...

On Monday, June 12, 2017 at 5:40:30 PM UTC-7, brainman wrote:
>
> > ... I also tried to load the go extension for gdb with "source 
> C:/utils/go/src/runtime/runtime-gdb.py", but it doesn't do much good, 
>
> Yes, I tried that recently. It didn't work for me either. From what I 
> remember, you had to have "python support" with gdb, and that, apparently, 
> is hard. I didn't have real need for runtime-gdb.py, so I gave up.
>
> > It would be nice to have a dbg_break() call in Go that would wait for 
> dlv to connect, irrespective of whether Go is embedded in C/C++ or not.
>
> I do not know what you are proposing. But, sure, there are other ways to 
> debug code. For example, I use fmt.Printf or println.
>
> Alex
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and 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] reflect.Type.Field() order

[akalin]

https://golang.org/pkg/reflect/#Value.Field says "Field returns the i'th 
field of the struct v.". Are there any guarantees as to what the ordering 
of the i'th field is? If not, does anyone know what the current behavior 
is, and whether it may change in the future? Is there a way to get the 
fields in declaration order?

Looking around online turned 
up https://stackoverflow.com/questions/32392311/reflect-type-field-order , 
which didn't come to any conclusion.

I'm asking because a serialization library I'm using uses the above field 
order when serializing structs as arrays, and I encountered a case where it 
seems to diverge from declaration order. If this is something that may 
change in the future, the users of that library (and anything like it) 
would probably break...

-- Fred

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

[Michael Banzon]

Sorry, it is 
tir. 13. jun. 2017 kl. 17.17 skrev Clayton Ray :

> Yes it is or yes it's not?
>
>
> On Tuesday, June 13, 2017 at 11:10:43 AM UTC-4, mbanzon wrote:
>
>> Yes.
>>
>> On Tue, Jun 13, 2017 at 4:51 PM Clayton Ray  wrote:
>>
> Is https://github.com/golang/mobile;>Golang/mobile not
>>> actively being developed anymore? I see the last commit was 20 days ago,
>>> but before that, months.
>>>
>>> --
>>> You received this message because you are subscribed 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.
>>>
>> --
>> Michael Banzon
>> https://michaelbanzon.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.
>
-- 
Michael Banzon
https://michaelbanzon.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] goimports flag parity with gofmt

['Sergiy Byelozyorov' via golang-nuts]

Ah. Good point. Added

autocmd BufWritePre *.go :GoFmt
autocmd BufWritePre *.go :GoImports

to my .vimrc. Thanks.

On Tue, Jun 13, 2017 at 3:38 PM Fatih Arslan  wrote:

> No you can do it. We have two commands, called :GoImports and :GoFmt. You
> can set the new setting and then call first :GoImports and then :GoFmt.
> With a little vim script you could create a single command that executes
> them in order.
>
> On Tue, Jun 13, 2017 at 4:07 PM Sergiy Byelozyorov 
> wrote:
>
>> Yes, but what I need is to run "goimports" and then "gofmt -s". If
>> goimports supported -s, then I would be able to do what I need, but not
>> with current vim-go implementation.
>>
>> On Tue, Jun 13, 2017 at 3:00 PM Fatih Arslan  wrote:
>>
>>> I think there is a misunderstanding here. People somehow don't read the
>>> manuals or the changelog when I release a new version. We have the
>>> following setting for  (which was released recently with v1.13):
>>>
>>>   let g:go_fmt_options = {
>>> \ 'gofmt': '-s',
>>> \ 'goimports': '-local mycompany.com',
>>> \ }
>>>
>>> Everyone who can see this immediately can see how this already solves
>>> this problem. As you see, vim-go can use different kind of options for each
>>> different binary name.
>>>
>>>
>>> On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
>>> wrote:
>>>
 Use the tool that does what you want.

 We don't have to put all functionality into all binaries.

 If vim-go makes assumptions that one helper binary does all
 functionality, yes, please fix vim-go.

 On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
 golang-nuts@googlegroups.com> wrote:

> This is still bothering us in 2017. I'd love to be able to run
> goimports on save in Vim, but also would like to simplify code (-s 
> option).
> I use vim-go plugin, so I guess I can submit a pull request asking the
> plugin to run both commands on save, but I do not understand why the
> workaround instead of command parity? Is it something no one has had time
> to look into yet or is it too hard to implement with current goimports
> implementation?
>
> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>
>> Oh, you did update goimports.
>>
>> gofmt and goimports both had their tab options removed.
>>
>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
>> much it matters.  No editors really use those, do they?  If you want to 
>> do
>> it by hand, gofmt is still there.
>>
>>
>>
>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick > > wrote:
>>
>>> I don't think you're running the correct binary then, because:
>>>
>>> $ rm $(which goimports)
>>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>>> $ goimports -h
>>> usage: goimports [flags] [path ...]
>>>   -d=false: display diffs instead of rewriting files
>>>   -e=false: report all errors (not just the first 10 on different
>>> lines)
>>>   -l=false: list files whose formatting differs from goimport's
>>>   -w=false: write result to (source) file instead of stdout
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
>>> wrote:
>>>
 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
 > You're running old binaries of each.


 Hmm. I'm try new goimports but nothing different:

 go get -v -x -u code.google.com/p/go.tools/cmd/goimports
 code.google.com/p/go.tools (download)
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg pull
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg tags
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg branches
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
 hg update default
 WORK=/tmp/go-build706264051
 code.google.com/p/go.tools/imports
 mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
 mkdir -p $WORK/code.google.com/p/go.tools/
 cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
 /usr/lib64/go/pkg/tool/linux_amd64/6g
 
 -o
 $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
 code.google.com/p/go.tools/imports -complete -D
 _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
 $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
 ./imports.go
 ./sortimports.go ./zstdlib.go
 /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
 $WORK/code.google.com/p/go.tools/imports.a
 

Re: [go-nuts] Gomobile

[Michael Banzon]

Yes.

On Tue, Jun 13, 2017 at 4:51 PM Clayton Ray  wrote:

> Is https://github.com/golang/mobile;>Golang/mobile not
> actively being developed anymore? I see the last commit was 20 days ago,
> but before that, months.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and 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 Banzon
https://michaelbanzon.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.

[go-nuts] Gomobile

[Clayton Ray]

Is https://github.com/golang/mobile;>Golang/mobile not 
actively being developed anymore? I see the last commit was 20 days ago, 
but before that, months.

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

[visualfc]

Hi, all. LiteIDE x32 released!

This version reimplemented multifolder model, support folder custom GOPATH, 
session switch, new themes and color scheme, fix source navigation and code 
reflect etc. more info view changes.

### Links
* LiteIDE New Home    

* LiteIDE Source code

* Gotools Source code

* Release downloads


### Changes 2017.6.12 Ver X32
* LiteIDE
* support folder build config custom GOPATH
* support folder build config BUILDFLAGS -tags setup
* support folder build config TARGETBASENAME setup
* support session switching for folder/editor
* support load custom icon library from liteapp/qrc folder (default and 
folder)
* reimplemented multifolder model, it took me a long time :)
* add macOS session menu for native dock menu
* recent menu sync for multi windows
* gotools support +build source navigate (single file or -tags setup)
* LiteApp
* add the session switching function
* add autosavedocument emit message option
* add max editor tab count option
* add option action to standard toolbar
* add tool window use shortcuts option for unstandard keyboard option
* add exit liteide ctrl+q on windows
* add themes (carbon.qss gray.qss sublime.qss) for liteide & beautify old 
themes, thanks for hope hook
* editor tab context add open terminal here action
* folders context menu add open in new windows action (new folder session)
* folder view add show showdetails action
* fix folder sync editor incorrect on macOS
* fix webview and debug console qss
* fix folders tool window enter key to jump
* fix exit error save session by ctrl+q on macos
* fix newfile dialog space name
* update folder tool window showInExporer showInShell action text
* LiteFind
* find files add auto swith current folder checkbox
* find in editor add show replace mode checkbox
* filesearch enable replace whitespace or empty
* editor replace all in one edit block for ctrl+z once undo
* LiteBuild
* add custom GOPATH in build config for build/debug/GolangEdit
* add custom share-value BUILDFLAGS in build config for 
build/debug/GolangEdit
* add custom TARGETBASENAME in build config for build/debug
* support BUILDFLAGS -tags for build/debug/GolangEdit
* update gosrc.xml to export custom value and share-value
* folders tool window context menu add Go build configuration action
* folders tool window context go tool use Go build configuration setup
* fix stop action for kill process
* LiteDebug
* console use editor color scheme
* support LiteBuild folder build config BUILDFLAGS/BUILDARGS -tags flag 
setup
* DlvDebugger
* fix process identify for auto exit
* LiteEnv
* default env /usr/local/go on macosx
* update macosx cross env GOROOT for system
* LiteEditor
* context menu add convert case menu
* go.snippet add iferr
* update sublime.xml / sublime-bold.xml, thanks for hopehook 

* alt+backspace delete serial whitespaces
* option font QComboBox to QFontComboBox, add restore DefaultFont action
* option add show monospace font check
* option file types sort mimetype, show custom extsition first
* GolangPackage
* gopath setup add use sysgopath/litegopath check
* GolangPlay
* fix goplay use goenvironment
* GolangDoc
* change golang api index search for go/api folder
* GolangEdit
* add go root source readonly setup option
* support folder go build config BUILDFLAGS/BUILDARGS -tags flag setup
* fix interface type by gotools
* fix find process stop and run
* fix lookup guru for source query
* GolangAst
* fix astview enter key to jump
* FileBorwser
* fix file system enter key to jump
* gotools
* fix types interface method
* types support +build for single source
* types support -tags flag
* tools
* add new exportqrc tool for export liteide all build-in images


Sent from Gmail

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

[Fatih Arslan]

No you can do it. We have two commands, called :GoImports and :GoFmt. You
can set the new setting and then call first :GoImports and then :GoFmt.
With a little vim script you could create a single command that executes
them in order.

On Tue, Jun 13, 2017 at 4:07 PM Sergiy Byelozyorov 
wrote:

> Yes, but what I need is to run "goimports" and then "gofmt -s". If
> goimports supported -s, then I would be able to do what I need, but not
> with current vim-go implementation.
>
> On Tue, Jun 13, 2017 at 3:00 PM Fatih Arslan  wrote:
>
>> I think there is a misunderstanding here. People somehow don't read the
>> manuals or the changelog when I release a new version. We have the
>> following setting for  (which was released recently with v1.13):
>>
>>   let g:go_fmt_options = {
>> \ 'gofmt': '-s',
>> \ 'goimports': '-local mycompany.com',
>> \ }
>>
>> Everyone who can see this immediately can see how this already solves
>> this problem. As you see, vim-go can use different kind of options for each
>> different binary name.
>>
>>
>> On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
>> wrote:
>>
>>> Use the tool that does what you want.
>>>
>>> We don't have to put all functionality into all binaries.
>>>
>>> If vim-go makes assumptions that one helper binary does all
>>> functionality, yes, please fix vim-go.
>>>
>>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>>> golang-nuts@googlegroups.com> wrote:
>>>
 This is still bothering us in 2017. I'd love to be able to run
 goimports on save in Vim, but also would like to simplify code (-s option).
 I use vim-go plugin, so I guess I can submit a pull request asking the
 plugin to run both commands on save, but I do not understand why the
 workaround instead of command parity? Is it something no one has had time
 to look into yet or is it too hard to implement with current goimports
 implementation?

 On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>
> Oh, you did update goimports.
>
> gofmt and goimports both had their tab options removed.
>
> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
> much it matters.  No editors really use those, do they?  If you want to do
> it by hand, gofmt is still there.
>
>
>
> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick 
> wrote:
>
>> I don't think you're running the correct binary then, because:
>>
>> $ rm $(which goimports)
>> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
>> $ goimports -h
>> usage: goimports [flags] [path ...]
>>   -d=false: display diffs instead of rewriting files
>>   -e=false: report all errors (not just the first 10 on different
>> lines)
>>   -l=false: list files whose formatting differs from goimport's
>>   -w=false: write result to (source) file instead of stdout
>>
>>
>>
>> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
>> wrote:
>>
>>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
>>> > You're running old binaries of each.
>>>
>>>
>>> Hmm. I'm try new goimports but nothing different:
>>>
>>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>>> code.google.com/p/go.tools (download)
>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>> hg pull
>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>> hg tags
>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>> hg branches
>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>>> hg update default
>>> WORK=/tmp/go-build706264051
>>> code.google.com/p/go.tools/imports
>>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>>> mkdir -p $WORK/code.google.com/p/go.tools/
>>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>>> 
>>> -o
>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>>> code.google.com/p/go.tools/imports -complete -D
>>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go
>>> ./imports.go
>>> ./sortimports.go ./zstdlib.go
>>> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
>>> $WORK/code.google.com/p/go.tools/imports.a
>>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
>>> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
>>> code.google.com/p/go.tools/
>>> cp $WORK/code.google.com/p/go.tools/imports.a
>>> /home/vtolstov/devel/go/pkg/linux_amd64/
>>> code.google.com/p/go.tools/imports.a
>>> code.google.com/p/go.tools/cmd/goimports
>>> mkdir -p 

[go-nuts] Golang process manager tools

[David Zhang]

Hi guys.

i want to introduce a process manager tool for Golang. that's pmgo 
.

If you want to know details, you can click the link.


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

[Damian Gryski]

Just went to add this to https://github.com/golang/go/wiki/ResearchPapers , 
but it's already there :)

Damian

On Sunday, June 11, 2017 at 5:44:33 PM UTC+2, Michael Jones wrote:
>
> Atom: Horizontally Scaling Strong Anonymity
>
> "To evaluate Atom, *we implemented an Atom prototype*
> *in Go*, and tested it on a network of 1,024 Amazon EC2
> machines. Our result shows that Atom can support more
> than one million users sending microblogging messages with
> 28 minutes of latency. using 1,024 commodity machines.
> (Processing this number of messages using Riposte [21], a
> centralized anonymous microblogging system, would take
> more than 11 hours.) Atom can also support a million users
> dialing with 28 minutes of latency, with stronger guarantees
> than prior systems [47, 68]."
>
> https://arxiv.org/pdf/1612.07841.pdf
>
> -- 
> Michael T. Jones
> michae...@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.

[go-nuts] Fast string sorting

[Stefan Nilsson]

It's well known that radix sort can be faster than comparison-based methods 
for string sorting. With that in mind, I wrote this optimized version of 
MSD radix sort:

https://github.com/yourbasic/radix

It's equivalent to sort.Strings in the standard library and on my machine 
it's twice as fast as when sorting King James Bible and four times as fast 
for the 1k benchmark in the sort package. Of course I can't promise similar 
performance in other settings, but Go get it if you like.

Stefan

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

['Sergiy Byelozyorov' via golang-nuts]

Yes, but what I need is to run "goimports" and then "gofmt -s". If
goimports supported -s, then I would be able to do what I need, but not
with current vim-go implementation.

On Tue, Jun 13, 2017 at 3:00 PM Fatih Arslan  wrote:

> I think there is a misunderstanding here. People somehow don't read the
> manuals or the changelog when I release a new version. We have the
> following setting for  (which was released recently with v1.13):
>
>   let g:go_fmt_options = {
> \ 'gofmt': '-s',
> \ 'goimports': '-local mycompany.com',
> \ }
>
> Everyone who can see this immediately can see how this already solves this
> problem. As you see, vim-go can use different kind of options for each
> different binary name.
>
>
> On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
> wrote:
>
>> Use the tool that does what you want.
>>
>> We don't have to put all functionality into all binaries.
>>
>> If vim-go makes assumptions that one helper binary does all
>> functionality, yes, please fix vim-go.
>>
>> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
>> golang-nuts@googlegroups.com> wrote:
>>
>>> This is still bothering us in 2017. I'd love to be able to run goimports
>>> on save in Vim, but also would like to simplify code (-s option). I use
>>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>>> run both commands on save, but I do not understand why the workaround
>>> instead of command parity? Is it something no one has had time to look into
>>> yet or is it too hard to implement with current goimports implementation?
>>>
>>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:

 Oh, you did update goimports.

 gofmt and goimports both had their tab options removed.

 But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
 much it matters.  No editors really use those, do they?  If you want to do
 it by hand, gofmt is still there.



 On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick 
 wrote:

> I don't think you're running the correct binary then, because:
>
> $ rm $(which goimports)
> $ go get -v -u code.google.com/p/go.tools/cmd/goimports
> $ goimports -h
> usage: goimports [flags] [path ...]
>   -d=false: display diffs instead of rewriting files
>   -e=false: report all errors (not just the first 10 on different
> lines)
>   -l=false: list files whose formatting differs from goimport's
>   -w=false: write result to (source) file instead of stdout
>
>
>
> On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
> wrote:
>
>> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
>> > You're running old binaries of each.
>>
>>
>> Hmm. I'm try new goimports but nothing different:
>>
>> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
>> code.google.com/p/go.tools (download)
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg pull
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg tags
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg branches
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
>> hg update default
>> WORK=/tmp/go-build706264051
>> code.google.com/p/go.tools/imports
>> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/
>> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
>> code.google.com/p/go.tools/imports -complete -D
>> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
>> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go ./imports.go
>> ./sortimports.go ./zstdlib.go
>> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
>> $WORK/code.google.com/p/go.tools/imports.a
>> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
>> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
>> code.google.com/p/go.tools/
>> cp $WORK/code.google.com/p/go.tools/imports.a
>> /home/vtolstov/devel/go/pkg/linux_amd64/
>> code.google.com/p/go.tools/imports.a
>> code.google.com/p/go.tools/cmd/goimports
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
>> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
>> cd /home/vtolstov/devel/go/src/
>> code.google.com/p/go.tools/cmd/goimports
>> /usr/lib64/go/pkg/tool/linux_amd64/6g
>> 
>> -o
>> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
>> 

Re: [go-nuts] goimports flag parity with gofmt

[Fatih Arslan]

I think there is a misunderstanding here. People somehow don't read the
manuals or the changelog when I release a new version. We have the
following setting for  (which was released recently with v1.13):

  let g:go_fmt_options = {
\ 'gofmt': '-s',
\ 'goimports': '-local mycompany.com',
\ }

Everyone who can see this immediately can see how this already solves this
problem. As you see, vim-go can use different kind of options for each
different binary name.


On Mon, Jun 12, 2017 at 7:55 PM Brad Fitzpatrick 
wrote:

> Use the tool that does what you want.
>
> We don't have to put all functionality into all binaries.
>
> If vim-go makes assumptions that one helper binary does all functionality,
> yes, please fix vim-go.
>
> On Mon, Jun 12, 2017 at 9:12 AM, sergiyb via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> This is still bothering us in 2017. I'd love to be able to run goimports
>> on save in Vim, but also would like to simplify code (-s option). I use
>> vim-go plugin, so I guess I can submit a pull request asking the plugin to
>> run both commands on save, but I do not understand why the workaround
>> instead of command parity? Is it something no one has had time to look into
>> yet or is it too hard to implement with current goimports implementation?
>>
>> On Friday, February 21, 2014 at 6:36:59 AM UTC+1, bradfitz wrote:
>>>
>>> Oh, you did update goimports.
>>>
>>> gofmt and goimports both had their tab options removed.
>>>
>>> But yes, goimports doesn't have cpuprofile, -r, or -s.  Not sure how
>>> much it matters.  No editors really use those, do they?  If you want to do
>>> it by hand, gofmt is still there.
>>>
>>>
>>>
>>> On Thu, Feb 20, 2014 at 9:35 PM, Brad Fitzpatrick 
>>> wrote:
>>>
 I don't think you're running the correct binary then, because:

 $ rm $(which goimports)
 $ go get -v -u code.google.com/p/go.tools/cmd/goimports
 $ goimports -h
 usage: goimports [flags] [path ...]
   -d=false: display diffs instead of rewriting files
   -e=false: report all errors (not just the first 10 on different lines)
   -l=false: list files whose formatting differs from goimport's
   -w=false: write result to (source) file instead of stdout



 On Thu, Feb 20, 2014 at 9:32 PM, Vasiliy Tolstov 
 wrote:

> 2014-02-21 9:29 GMT+04:00 Brad Fitzpatrick :
> > You're running old binaries of each.
>
>
> Hmm. I'm try new goimports but nothing different:
>
> go get -v -x -u code.google.com/p/go.tools/cmd/goimports
> code.google.com/p/go.tools (download)
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg pull
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg tags
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg branches
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools
> hg update default
> WORK=/tmp/go-build706264051
> code.google.com/p/go.tools/imports
> mkdir -p $WORK/code.google.com/p/go.tools/imports/_obj/
> mkdir -p $WORK/code.google.com/p/go.tools/
> cd /home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports
> /usr/lib64/go/pkg/tool/linux_amd64/6g
> 
> -o
> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6 -p
> code.google.com/p/go.tools/imports -complete -D
> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/imports -I
> $WORK -I /home/vtolstov/devel/go/pkg/linux_amd64 ./fix.go ./imports.go
> ./sortimports.go ./zstdlib.go
> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
> $WORK/code.google.com/p/go.tools/imports.a
> $WORK/code.google.com/p/go.tools/imports/_obj/_go_.6
> mkdir -p /home/vtolstov/devel/go/pkg/linux_amd64/
> code.google.com/p/go.tools/
> cp $WORK/code.google.com/p/go.tools/imports.a
> /home/vtolstov/devel/go/pkg/linux_amd64/
> code.google.com/p/go.tools/imports.a
> code.google.com/p/go.tools/cmd/goimports
> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/
> mkdir -p $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/exe/
> cd /home/vtolstov/devel/go/src/
> code.google.com/p/go.tools/cmd/goimports
> /usr/lib64/go/pkg/tool/linux_amd64/6g
> 
> -o
> $WORK/code.google.com/p/go.tools/cmd/goimports/_obj/_go_.6 -p
> code.google.com/p/go.tools/cmd/goimports -complete -D
> _/home/vtolstov/devel/go/src/code.google.com/p/go.tools/cmd/goimports
> -I  $WORK -I
> /home/vtolstov/devel/go/pkg/linux_amd64 ./doc.go ./goimports.go
> /usr/lib64/go/pkg/tool/linux_amd64/pack grcP $WORK
> $WORK/code.google.com/p/go.tools/cmd/goimports.a
>