Re: [go-nuts] Re: A question !

2020-01-07 Thread Motaz Hejaze 
Thank you all guys for your help..

May i ask what is the best deployment for more performance ??

On Mon, 6 Jan 2020, 10:56 am ,  wrote:

> 2 - What is the fastest resource to learn Golang ( efficiently )
>>
>
> For me the best thing was Effective Go
> https://golang.org/doc/effective_go.html
> Helps to understand "the go way"of coding and the main characteristics of
> the language
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/3cba8190-1ead-42dc-a920-1c871059ad97%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHV4E-f6Yn6%2BFx9NPPQMc%2Bzi23fKiZzRuUx8Axi7Zm%3DAfc0ebw%40mail.gmail.com.

Re: [go-nuts] Panicking in public API ?

2020-01-07 Thread Christian Mauduit 
I'd suggest you expose both kind of APIs as in:

* https://golang.org/pkg/regexp/#Compile
* https://golang.org/pkg/regexp/#MustCompile

Implementing the `Must` flavor is trivial, just call the standard func
and panic() if you get an error. As a side effect you'll get a unique
point where to panic(), and callers will recognize it's likely yo
panic() because the function has "Must" in its name.

If in doubt, implement only the func that returns the error, the other
is just syntaxic sugar IMHO. Example:

https://golang.org/src/regexp/regexp.go?s=10768:10804#L298

panics() have been, in my Golang experience, a pain to deal with. Most
of the time they are just below a "TODO refactor that sh*t" comment, or
they would deserve that comment anyway. Proper error handling takes
time, but it's an investment that pays of.

My 2c.

Christian.

Le 07/01/2020 à 8:10 AM, Tay a écrit :
> Hi,
> 
> Just a quick question. I know it's well accepted that panics leaking to
> the public API of a library is generally a no-go.
> 
> Yet, are there any exception to the rule?
> 
> For instance, I have a library that instantiates some database prepared
> statements (so, the majority of the elements are instantiated and used
> in the main function). I would like to panic instead of returning an
> error because, if db.Prepare(q) returns an error, there is no point in
> continuing, the error is barely recoverable. Besides, it will allow for
> a better looking API so to speak.
> 
> Any comments?
-- 
Christian Mauduit__/\__  ___
uf...@ufoot.org  \~ ~ / (`_ \   ___
https://ufoot.org/_o _\\ \_/ _ \_
int q = (2 * b) || !(2 * b);   \/   \___/ \__)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e7cd8115-bdb3-9edb-006b-1b5100e4cd7e%40ufoot.org.

[go-nuts] Re: Unlinked temporary files

2020-01-07 Thread Egon 
You are not checking return value of os.Remove in 
https://github.com/eikenb/pipeat/blob/master/pipeat.go#L51.
That will fail on windows.

You can take look at https://github.com/calebcase/tmpfile, which works on 
Windows.

+ Egon

On Friday, 3 January 2020 19:50:20 UTC+2, drakk...@gmail.com wrote:
>
> Hi,
>
> I'm going to use this library https://github.com/eikenb/pipeat/ 
>
> it reads/writes from/to an unlinked temporary file, as you can see here:
>
> https://github.com/eikenb/pipeat/blob/master/pipeat.go#L51
>
> the temporary file is removed and then used for I/O operations. 
>
> I ran the test cases on Windows and they work there too.
>
> Is it really safe to assume that an unliked file will work on all 
> supported OS? I was really surprised that this work on Windows,
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b85b3d8b-7b22-4b60-b22e-41bb36ded85c%40googlegroups.com.

Re: [go-nuts] doubt about reflect.Type.String and empty interface

2020-01-07 Thread Marvin Renich 
* Manlio Perillo  [200106 18:57]:
> I wrote another test https://play.golang.org/p/hoTAnijCfg1.
> Now it is clear why the first entry can only print nil for the type
> and  for the value.
> 
> However printf %v verb prints nil for both an empty interface and an
> interface with a dynamic value of nil:
> https://play.golang.org/p/m_WfR2SPWQ3
> Can this cause confusion?

Yes, it definitely can (and probably does).  However, if you change "%v"
to "%#v", it helps to clarify things:

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

...Marvin

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20200107120900.krld2ci3dvdadcqn%40basil.wdw.

Re: [go-nuts] Panicking in public API ?

2020-01-07 Thread Brian Candler 
On Tuesday, 7 January 2020 07:47:28 UTC, Axel Wagner wrote:
>
> Personally, I consider panics "run-time type-errors". That is, they 
> indicate a bug that couldn't be caught statically by the type-system - so 
> the program shouldn't have compiled in the first place and crashing it is 
> the right choice. Dereferencing a nil-pointer or indexing out-of-bounds 
> fall into that category. So does using reflect to do otherwise invalid 
> operations (which is why reflect panics). IMO, a straight-out rejection of 
> panics doesn't make sense, unless you assume your type-system is perfect 
> and so there are no bug-free programs.
>
> Another way to look at it, is that a panic in general dumps a stack-trace, 
> while an error is being presented to the human using the resulting 
> software. And that stack-traces in general are not actionable to the user 
> of a software, but only its developer - while error message don't contain 
> the necessary details to debug a program, but can (should!) provide 
> actionable advise to its user. Thus, panics are the right tool to use when 
> reporting an issue that requires programmer attention and errors are the 
> right tool when reporting an issue that requires user-attention (or, of 
> course, can be handled programmatically).¹
>

Or to put it another way: if the caller of your function violates your *API 
contract* then panic.  The bug is with the caller for not invoking your 
function properly, and therefore the calling code needs to be fixed.

By that definition: if the API contract says "you must pass in a valid SQL 
statement", and you can say with 100% certainty that the SQL they passed in 
is invalid, then by all means panic.  But if you can't  be sure of that - 
e.g. the problem could be a failure to connect to the database - then 
return an error.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/693c9e10-06f2-49b3-a9cc-2b9025b88041%40googlegroups.com.

[go-nuts] Sybase SQLAnywhere driver for Unix systems

2020-01-07 Thread reda laanait 
Hello,

Is there a Golang driver for Sybase SQLAnywhere DB that works in a Unix
system? I only find this , which
works only on windows.

Otherwise, Is there any workaround to fix that e.g implementing a wrapper
of another language driver?

Thanks
-- 
LAANAIT Ahmed Reda
--
Computer Engineer at
TamTam international

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJg1kZP_68-XsdSXHzkSm2mOPuP%2BptLpihCsmcOtLJ734XyZcw%40mail.gmail.com.

AW: [go-nuts] Sybase SQLAnywhere driver for Unix systems

2020-01-07 Thread Lutz Horn 
If there is none listed on 
https://github.com/avelino/awesome-go#database-drivers or 
https://github.com/golang/go/wiki/SQLDrivers you are out of luck.

Lutz


Von: golang-nuts@googlegroups.com  im Auftrag von 
reda laanait 
Gesendet: Dienstag, 7. Januar 2020 09:09
An: golang-nuts@googlegroups.com
Betreff: [go-nuts] Sybase SQLAnywhere driver for Unix systems


Hello,

Is there a Golang driver for Sybase SQLAnywhere DB that works in a Unix system? 
I only find this, which works only on 
windows.

Otherwise, Is there any workaround to fix that e.g implementing a wrapper of 
another language driver?

Thanks
--
LAANAIT Ahmed Reda
--
Computer Engineer at
TamTam international

--
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAJg1kZP_68-XsdSXHzkSm2mOPuP%2BptLpihCsmcOtLJ734XyZcw%40mail.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/VI1PR06MB39338E22C3B4E190F8A8236F9E3F0%40VI1PR06MB3933.eurprd06.prod.outlook.com.

Re: [go-nuts] Loading Go plugin from Go shared library ends up with `fatal error: runtime: no plugin module data`

2020-01-07 Thread Ian Lance Taylor 
On Mon, Jan 6, 2020 at 11:54 PM Karthik Krishnamurthy
 wrote:
>
> This is probably an unusual situation, but I am working on a product that has 
> the following chain of invocation.
>
> C (native shared library libfoo.so) -> Go (c-shared libbar.so)
>
> So basically, a native C shared library invokes a -buildmode=c-shared type Go 
> shared library. This interaction works just fine.
>
> However, we are augmenting libbar.so (Go shared library) to invoke a Go-style 
> plugin (libplugin.so) using Go's plugin package. The very first attempt of 
> this, failed like this:
>
> fatal error: runtime: no plugin module data
>
>
> goroutine 17 [running, locked to thread]:
> runtime.throw(0xf72b5cc4, 0x1e)
> /usr/local/go/src/runtime/panic.go:774 +0x70 fp=0xc64d1b48 sp=0xc64d1b34 
> pc=0xf71bfdd0
> plugin.lastmoduleinit(0xc648e5e0, 0x1001, 0x1001, 0xc64823e8, 0x95b9588)
> /usr/local/go/src/runtime/plugin.go:20 +0xa50 fp=0xc64d1bd4 sp=0xc64d1b48 
> pc=0xf71c1420
> plugin.open(0xc64a60c0, 0x26, 0x29, 0xc64a6060, 0x2a)
> /usr/local/go/src/plugin/plugin_dlopen.go:77 +0x388 fp=0xc64d1d2c 
> sp=0xc64d1bd4 pc=0xf7275ad8
> plugin.Open(...)
> /usr/local/go/src/plugin/plugin.go:32
> zero/base/interfaces.glob..func1(0xc64a60c0, 0x29, 0xf72b2610, 0x11, 0x29, 
> 0x0, 0xf719e2e5, 0xf71d958c)
> /app/base/interfaces/plugin.go:12 +0x2e fp=0xc64d1d68 sp=0xc64d1d2c 
> pc=0xf7276cbe
> zero/base.glob..func4(0xf7759c60, 0x21, 0xf7357f80, 0xc64823e0, 0xc64a8445, 
> 0x5, 0xf, 0xe, 0xd, 0xd)
> /app/base/zl_helper.go:28 +0xb4 fp=0xc64d1d9c sp=0xc64d1d68 pc=0xf72ac554
> main.glob..func10(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
> 0x15, 0xc648e5c0, 0x5, ...)
> /app/dec/dec.go:328 +0x7a fp=0xc64d1dd8 sp=0xc64d1d9c pc=0xf72aeb0a
> main.glob..func11(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
> 0x15, 0xc6496040, 0x5, ...)
> /app/dec/dec.go:368 +0xa3 fp=0xc64d1e34 sp=0xc64d1dd8 pc=0xf72aee13
> main.Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 0x15, 
> 0xc6436000)
> /app/dec/dec.go:98 +0x1f3 fp=0xc64d1eac sp=0xc64d1e34 pc=0xf72ad0b3
> main._cgoexpwrap_079f3b2ec7da_Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 
> 0x21, 0xf775ac60, 0x1b, 0x15, 0x0)
> _cgo_gotypes.go:79 +0x95 fp=0xc64d1ef4 sp=0xc64d1eac pc=0xf72ace15
> runtime.call64(0x0, 0xffa1e72c, 0xffa1e79c, 0x24, 0x0)
> /usr/local/go/src/runtime/asm_386.s:571 +0x31 fp=0xc64d1f38 sp=0xc64d1ef4 
> pc=0xf71e9ad1
> runtime.cgocallbackg1(0x0)
> /usr/local/go/src/runtime/cgocall.go:314 +0x162 fp=0xc64d1fb0 
> sp=0xc64d1f38 pc=0xf71966f2
> runtime.cgocallbackg(0x0)
> /usr/local/go/src/runtime/cgocall.go:191 +0x9d fp=0xc64d1fe0 
> sp=0xc64d1fb0 pc=0xf719650d
> runtime.cgocallback_gofunc(0x0, 0x0, 0x0, 0x0)
> /usr/local/go/src/runtime/asm_386.s:810 +0x79 fp=0xc64d1ff0 sp=0xc64d1fe0 
> pc=0xf71eab79
> runtime.goexit()
> /usr/local/go/src/runtime/asm_386.s:1325 +0x1 fp=0xc64d1ff4 sp=0xc64d1ff0 
> pc=0xf71eb081
> Aborted
>
>
> What is the error indicative of?
>
> Is invoking go plugin from go shared library supported?
>
> I know Go plugins have a few restrictions. I have verified that all the above 
> libraries are built on the same machine with the same gcc/go toolkit.

I wouldn't be surprised if you are the first person to try this.  I'm
not surprised that it doesn't work.  I can't think of any fundamental
reason why it wouldn't work, so it may be relatively easy to fix if
you want to dig into the linker.  I'm not sure.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWcF%2Bt8Kef5nHeMoMQ0%3DvO0j87fs3FOj6hdXtsnJU0VAQ%40mail.gmail.com.

Re: [go-nuts] Re: A question !

2020-01-07 Thread David Riley 
On Jan 7, 2020, at 04:44, Motaz Hejaze  wrote:
> 
> 
> Thank you all guys for your help..
> 
> May i ask what is the best deployment for more performance ??

I’m not quite sure what you mean. Do you mean what environment results in the 
highest-performing Go programs? I’d imagine the s390x architecture represents 
the biggest hammer, but it’s not one I’d suggest unless you know you need it.

Running on OS X and Linux (on any supported architecture) will likely yield the 
best mix of performance and pleasant development experience. But Go runs fine 
(modulo certain low-level compatibility issues) on Windows, FreeBSD, NetBSD, 
OpenBSD and a variety of other systems as well.

Deploying for production will likely be easiest with Docker containers or the 
like, albeit at the normal (relatively small, mostly) performance costs 
associated. You can deploy directly as a regular application, with all the 
associated maintenance issues that may involve.

What is the angle of your question?

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/B2C596C5-67D1-4722-B418-B3BFF321C1FE%40gmail.com.

Re: [go-nuts] Loading Go plugin from Go shared library ends up with `fatal error: runtime: no plugin module data`

2020-01-07 Thread Karthik Krishnamurthy 
Ian,

I did some more digging on the web and landed on this Go issue where you 
had a 
comment: https://github.com/golang/go/issues/18123#issuecomment-264590075. 

The original issue is related c-archive buildmode, but reading further on 
that thread, I am guessing that even for Go shared libraries built with 
c-shared buildmode, invoking a plugin doesn't work due to multiple Go 
runtimes being loaded.

This 
comment: https://github.com/golang/go/issues/18123#issuecomment-469111906 
has a demo that resembles my situation.

Given all this, I am thinking that native C shared library -> Go shared 
library -> Go plugin is an unsupported situation. Am I missing something? 

Thanks,
Karthik.

On Tuesday, January 7, 2020 at 6:20:50 AM UTC-8, Ian Lance Taylor wrote:
>
> On Mon, Jan 6, 2020 at 11:54 PM Karthik Krishnamurthy 
> > wrote: 
> > 
> > This is probably an unusual situation, but I am working on a product 
> that has the following chain of invocation. 
> > 
> > C (native shared library libfoo.so) -> Go (c-shared libbar.so) 
> > 
> > So basically, a native C shared library invokes a -buildmode=c-shared 
> type Go shared library. This interaction works just fine. 
> > 
> > However, we are augmenting libbar.so (Go shared library) to invoke a 
> Go-style plugin (libplugin.so) using Go's plugin package. The very first 
> attempt of this, failed like this: 
> > 
> > fatal error: runtime: no plugin module data 
> > 
> > 
> > goroutine 17 [running, locked to thread]: 
> > runtime.throw(0xf72b5cc4, 0x1e) 
> > /usr/local/go/src/runtime/panic.go:774 +0x70 fp=0xc64d1b48 
> sp=0xc64d1b34 pc=0xf71bfdd0 
> > plugin.lastmoduleinit(0xc648e5e0, 0x1001, 0x1001, 0xc64823e8, 0x95b9588) 
> > /usr/local/go/src/runtime/plugin.go:20 +0xa50 fp=0xc64d1bd4 
> sp=0xc64d1b48 pc=0xf71c1420 
> > plugin.open(0xc64a60c0, 0x26, 0x29, 0xc64a6060, 0x2a) 
> > /usr/local/go/src/plugin/plugin_dlopen.go:77 +0x388 fp=0xc64d1d2c 
> sp=0xc64d1bd4 pc=0xf7275ad8 
> > plugin.Open(...) 
> > /usr/local/go/src/plugin/plugin.go:32 
> > zero/base/interfaces.glob..func1(0xc64a60c0, 0x29, 0xf72b2610, 0x11, 
> 0x29, 0x0, 0xf719e2e5, 0xf71d958c) 
> > /app/base/interfaces/plugin.go:12 +0x2e fp=0xc64d1d68 sp=0xc64d1d2c 
> pc=0xf7276cbe 
> > zero/base.glob..func4(0xf7759c60, 0x21, 0xf7357f80, 0xc64823e0, 
> 0xc64a8445, 0x5, 0xf, 0xe, 0xd, 0xd) 
> > /app/base/zl_helper.go:28 +0xb4 fp=0xc64d1d9c sp=0xc64d1d68 
> pc=0xf72ac554 
> > main.glob..func10(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 
> 0x1b, 0x15, 0xc648e5c0, 0x5, ...) 
> > /app/dec/dec.go:328 +0x7a fp=0xc64d1dd8 sp=0xc64d1d9c pc=0xf72aeb0a 
> > main.glob..func11(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 
> 0x1b, 0x15, 0xc6496040, 0x5, ...) 
> > /app/dec/dec.go:368 +0xa3 fp=0xc64d1e34 sp=0xc64d1dd8 pc=0xf72aee13 
> > main.Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
> 0x15, 0xc6436000) 
> > /app/dec/dec.go:98 +0x1f3 fp=0xc64d1eac sp=0xc64d1e34 pc=0xf72ad0b3 
> > main._cgoexpwrap_079f3b2ec7da_Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 
> 0x21, 0xf775ac60, 0x1b, 0x15, 0x0) 
> > _cgo_gotypes.go:79 +0x95 fp=0xc64d1ef4 sp=0xc64d1eac pc=0xf72ace15 
> > runtime.call64(0x0, 0xffa1e72c, 0xffa1e79c, 0x24, 0x0) 
> > /usr/local/go/src/runtime/asm_386.s:571 +0x31 fp=0xc64d1f38 
> sp=0xc64d1ef4 pc=0xf71e9ad1 
> > runtime.cgocallbackg1(0x0) 
> > /usr/local/go/src/runtime/cgocall.go:314 +0x162 fp=0xc64d1fb0 
> sp=0xc64d1f38 pc=0xf71966f2 
> > runtime.cgocallbackg(0x0) 
> > /usr/local/go/src/runtime/cgocall.go:191 +0x9d fp=0xc64d1fe0 
> sp=0xc64d1fb0 pc=0xf719650d 
> > runtime.cgocallback_gofunc(0x0, 0x0, 0x0, 0x0) 
> > /usr/local/go/src/runtime/asm_386.s:810 +0x79 fp=0xc64d1ff0 
> sp=0xc64d1fe0 pc=0xf71eab79 
> > runtime.goexit() 
> > /usr/local/go/src/runtime/asm_386.s:1325 +0x1 fp=0xc64d1ff4 
> sp=0xc64d1ff0 pc=0xf71eb081 
> > Aborted 
> > 
> > 
> > What is the error indicative of? 
> > 
> > Is invoking go plugin from go shared library supported? 
> > 
> > I know Go plugins have a few restrictions. I have verified that all the 
> above libraries are built on the same machine with the same gcc/go toolkit. 
>
> I wouldn't be surprised if you are the first person to try this.  I'm 
> not surprised that it doesn't work.  I can't think of any fundamental 
> reason why it wouldn't work, so it may be relatively easy to fix if 
> you want to dig into the linker.  I'm not sure. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/82032f0b-5458-42a3-be21-81c00fd253a8%40googlegroups.com.

Re: [go-nuts] Re: A question !

2020-01-07 Thread Amnon Baron Cohen 


On Tuesday, 7 January 2020 09:44:28 UTC, Motaz Hejaze wrote:
>
>
> May i ask what is the best deployment for more performance ?? 
>
>>
>>
Do whatever is easiest. If you have come from the Python/Django world 
then you will be blown away by Go's speed, whatever deployment you use.
I would also use the standard library's built in web-server rather than 
proxying 
behind nginx. 

A big benefit of Go's improved speed is that you can stop worrying about 
performance.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a4063992-911d-4f3c-a518-5088762ba0fb%40googlegroups.com.

Re: [go-nuts] Loading Go plugin from Go shared library ends up with `fatal error: runtime: no plugin module data`

2020-01-07 Thread Ian Lance Taylor 
On Tue, Jan 7, 2020 at 7:10 AM Karthik Krishnamurthy
 wrote:
>
> I did some more digging on the web and landed on this Go issue where you had 
> a comment: https://github.com/golang/go/issues/18123#issuecomment-264590075.
>
> The original issue is related c-archive buildmode, but reading further on 
> that thread, I am guessing that even for Go shared libraries built with 
> c-shared buildmode, invoking a plugin doesn't work due to multiple Go 
> runtimes being loaded.
>
> This comment: 
> https://github.com/golang/go/issues/18123#issuecomment-469111906 has a demo 
> that resembles my situation.
>
> Given all this, I am thinking that native C shared library -> Go shared 
> library -> Go plugin is an unsupported situation. Am I missing something?

I doubt it.  Sorry for not being clear in my earlier reply: it's
definitely unsupported.  I was speculating as to whether it might be
possible to make it work if you wanted to dig into the linker.

Ian


> On Tuesday, January 7, 2020 at 6:20:50 AM UTC-8, Ian Lance Taylor wrote:
>>
>> On Mon, Jan 6, 2020 at 11:54 PM Karthik Krishnamurthy
>>  wrote:
>> >
>> > This is probably an unusual situation, but I am working on a product that 
>> > has the following chain of invocation.
>> >
>> > C (native shared library libfoo.so) -> Go (c-shared libbar.so)
>> >
>> > So basically, a native C shared library invokes a -buildmode=c-shared type 
>> > Go shared library. This interaction works just fine.
>> >
>> > However, we are augmenting libbar.so (Go shared library) to invoke a 
>> > Go-style plugin (libplugin.so) using Go's plugin package. The very first 
>> > attempt of this, failed like this:
>> >
>> > fatal error: runtime: no plugin module data
>> >
>> >
>> > goroutine 17 [running, locked to thread]:
>> > runtime.throw(0xf72b5cc4, 0x1e)
>> > /usr/local/go/src/runtime/panic.go:774 +0x70 fp=0xc64d1b48 
>> > sp=0xc64d1b34 pc=0xf71bfdd0
>> > plugin.lastmoduleinit(0xc648e5e0, 0x1001, 0x1001, 0xc64823e8, 0x95b9588)
>> > /usr/local/go/src/runtime/plugin.go:20 +0xa50 fp=0xc64d1bd4 
>> > sp=0xc64d1b48 pc=0xf71c1420
>> > plugin.open(0xc64a60c0, 0x26, 0x29, 0xc64a6060, 0x2a)
>> > /usr/local/go/src/plugin/plugin_dlopen.go:77 +0x388 fp=0xc64d1d2c 
>> > sp=0xc64d1bd4 pc=0xf7275ad8
>> > plugin.Open(...)
>> > /usr/local/go/src/plugin/plugin.go:32
>> > zero/base/interfaces.glob..func1(0xc64a60c0, 0x29, 0xf72b2610, 0x11, 0x29, 
>> > 0x0, 0xf719e2e5, 0xf71d958c)
>> > /app/base/interfaces/plugin.go:12 +0x2e fp=0xc64d1d68 sp=0xc64d1d2c 
>> > pc=0xf7276cbe
>> > zero/base.glob..func4(0xf7759c60, 0x21, 0xf7357f80, 0xc64823e0, 
>> > 0xc64a8445, 0x5, 0xf, 0xe, 0xd, 0xd)
>> > /app/base/zl_helper.go:28 +0xb4 fp=0xc64d1d9c sp=0xc64d1d68 
>> > pc=0xf72ac554
>> > main.glob..func10(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 
>> > 0x1b, 0x15, 0xc648e5c0, 0x5, ...)
>> > /app/dec/dec.go:328 +0x7a fp=0xc64d1dd8 sp=0xc64d1d9c pc=0xf72aeb0a
>> > main.glob..func11(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 
>> > 0x1b, 0x15, 0xc6496040, 0x5, ...)
>> > /app/dec/dec.go:368 +0xa3 fp=0xc64d1e34 sp=0xc64d1dd8 pc=0xf72aee13
>> > main.Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 0x21, 0xf775ac60, 0x1b, 
>> > 0x15, 0xc6436000)
>> > /app/dec/dec.go:98 +0x1f3 fp=0xc64d1eac sp=0xc64d1e34 pc=0xf72ad0b3
>> > main._cgoexpwrap_079f3b2ec7da_Decorate(0xffa1e800, 0x2, 0x2, 0xf7759c60, 
>> > 0x21, 0xf775ac60, 0x1b, 0x15, 0x0)
>> > _cgo_gotypes.go:79 +0x95 fp=0xc64d1ef4 sp=0xc64d1eac pc=0xf72ace15
>> > runtime.call64(0x0, 0xffa1e72c, 0xffa1e79c, 0x24, 0x0)
>> > /usr/local/go/src/runtime/asm_386.s:571 +0x31 fp=0xc64d1f38 
>> > sp=0xc64d1ef4 pc=0xf71e9ad1
>> > runtime.cgocallbackg1(0x0)
>> > /usr/local/go/src/runtime/cgocall.go:314 +0x162 fp=0xc64d1fb0 
>> > sp=0xc64d1f38 pc=0xf71966f2
>> > runtime.cgocallbackg(0x0)
>> > /usr/local/go/src/runtime/cgocall.go:191 +0x9d fp=0xc64d1fe0 
>> > sp=0xc64d1fb0 pc=0xf719650d
>> > runtime.cgocallback_gofunc(0x0, 0x0, 0x0, 0x0)
>> > /usr/local/go/src/runtime/asm_386.s:810 +0x79 fp=0xc64d1ff0 
>> > sp=0xc64d1fe0 pc=0xf71eab79
>> > runtime.goexit()
>> > /usr/local/go/src/runtime/asm_386.s:1325 +0x1 fp=0xc64d1ff4 
>> > sp=0xc64d1ff0 pc=0xf71eb081
>> > Aborted
>> >
>> >
>> > What is the error indicative of?
>> >
>> > Is invoking go plugin from go shared library supported?
>> >
>> > I know Go plugins have a few restrictions. I have verified that all the 
>> > above libraries are built on the same machine with the same gcc/go toolkit.
>>
>> I wouldn't be surprised if you are the first person to try this.  I'm
>> not surprised that it doesn't work.  I can't think of any fundamental
>> reason why it wouldn't work, so it may be relatively easy to fix if
>> you want to dig into the linker.  I'm not sure.
>>
>> 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...@goo

Re: [go-nuts] Panicking in public API ?

2020-01-07 Thread Tay 
Many thanks everyone for the insight.
Instead of accepting a raw query string and try to compile it, I will defer 
that part to the library user. So, I will simply accept a *sql.Stmt.
That way, I won't have to handle the various failure modes within the 
library and leave the issue to the end user.
Thanks again,

On Tuesday, January 7, 2020 at 2:10:32 PM UTC+1, Brian Candler wrote:
>
> On Tuesday, 7 January 2020 07:47:28 UTC, Axel Wagner wrote:
>>
>> Personally, I consider panics "run-time type-errors". That is, they 
>> indicate a bug that couldn't be caught statically by the type-system - so 
>> the program shouldn't have compiled in the first place and crashing it is 
>> the right choice. Dereferencing a nil-pointer or indexing out-of-bounds 
>> fall into that category. So does using reflect to do otherwise invalid 
>> operations (which is why reflect panics). IMO, a straight-out rejection of 
>> panics doesn't make sense, unless you assume your type-system is perfect 
>> and so there are no bug-free programs.
>>
>> Another way to look at it, is that a panic in general dumps a 
>> stack-trace, while an error is being presented to the human using the 
>> resulting software. And that stack-traces in general are not actionable to 
>> the user of a software, but only its developer - while error message don't 
>> contain the necessary details to debug a program, but can (should!) provide 
>> actionable advise to its user. Thus, panics are the right tool to use when 
>> reporting an issue that requires programmer attention and errors are the 
>> right tool when reporting an issue that requires user-attention (or, of 
>> course, can be handled programmatically).¹
>>
>
> Or to put it another way: if the caller of your function violates your 
> *API contract* then panic.  The bug is with the caller for not invoking 
> your function properly, and therefore the calling code needs to be fixed.
>
> By that definition: if the API contract says "you must pass in a valid SQL 
> statement", and you can say with 100% certainty that the SQL they passed in 
> is invalid, then by all means panic.  But if you can't  be sure of that - 
> e.g. the problem could be a failure to connect to the database - then 
> return an error.
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/77510edd-7662-4f93-80a4-f5742e904e5c%40googlegroups.com.

Re: [go-nuts] RecvMsgUDP / SendMsgUDP

2020-01-07 Thread John Dreystadt 


On Monday, January 6, 2020 at 5:42:04 PM UTC-5, Ian Lance Taylor wrote:
>
> On Mon, Jan 6, 2020 at 12:46 PM John Dreystadt  > wrote: 
> > 
> > I noticed that the documentation for net.RecvMesgUDP and net.SendMesgUDP 
> seemed a bit odd because it referred to “out of band” for some of the 
> parameters being passed and some of the return values. This caused me to 
> look closely at these two functions and here are the results of my 
> research. First, the documentation uses “out of band” when most other 
> documentation, such as the Linux docs for recvmsg(2), use either “control 
> messages” or “ancillary information” for the same fields. This may confuse 
> newcomers to these functions as “out of band” looks like a reference to the 
> TCP concept of “out of band” which is specific to TCP and not present in 
> UDP. Second, the “out of band” fields in question are not useful unless 
> certain socket options are set which cannot be done using the functions 
> available in the “net” package. Third, the “golang.org/x/net” package 
> provides access to most of the socket options in question but not all (the 
> socket option IPPROTO_IP, IP_PKTINFO is not available). There are functions 
> in “golang.org/x/net/internal/socket” for both setting arbitrary socket 
> options and calling recvmsg/sendmsg (still assuming Linux here but Windows 
> just has different names). These cannot be called by user programs because 
> they are in an “internal” package. Fourth and last, I don’t see any way to 
> determine if a read of a TCP socket (not UDP this time) has returned out of 
> band information. In C, I would use recvmsg and check the returned flags 
> for the bit MSG_OOB but there is no RecvMesgTCP. 
> > 
> > I have a proposal for changes but I wanted to see if anyone disagreed 
> with the above. I would be especially interested in anyone using these two 
> functions today. 
>
> I guess you're talking about net.UDPConn.WriteMsgUDP and 
> net.UDPConn.ReadMsgUDP.  I agree that on Unix systems that "out of 
> band" data is normally called "ancillary data," and we should change 
> the net package docs. 
>
> User programs can set arbitrary socket options by using 
> net.UDPConn.SyscallConn to get a syscall.RawConn and calling the 
> Control method.  But I agree that that procedure needs to be better 
> documented somewhere. 
>
> I'm kind of surprised that there is no way to handle TCP out-of-band 
> data but I admit that I don't see one. 
>
> Ian 
>

Sigh, sorry for getting the names wrong. Anyway, I see what Ian means about 
using the Control method to set an arbitrary socket option but I would not 
have found it without his prompting. So either we need a different 
procedure or better documentation. Which leads me into my proposal for 
changes.

Change 1, add WriteMsg and ReadMsg functions to the different socket types 
in x/net. This seems more in keeping with the division between the main net 
package and x/net. Not hard to do as the existing code for WriteMsgUDP and 
ReadMsgUDP can be used as a start. This would also fix the issue of 
handling TCP out-of-band data since TCP sockets would get the new functions.

Change 2, add GetSocketOption and SetSocketOption functions to the  same 
socket types in x/net. Again, not hard to do as these would be wrapper 
functions calling the Get and Set functions on 
x/net/internal/socket.Option. Documentation would be much easier than 
explaining how to use the syscall mechanism.

Change 3, deprecate the existing WriteMsgUDP and ReadMsgUDP functions 
pointing users to the new WriteMsg and ReadMsg functions. 

Any comments?

John Dreystadt

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/20540f17-67b7-4e53-8dea-b059996f99d2%40googlegroups.com.

[go-nuts] regexp syntax and named Unicode character classes

2020-01-07 Thread Tom Payne 
Hi,

tl;dr How should I use named Unicode character classes in regexps?

I'm trying to write a regular expression that matches Go identifiers 
, which start with a Unicode 
letter or underscore followed by zero or more Unicode letters, decimal 
digits, and/or underscores.

Based on the regexp syntax , and the variables 
in the unicode package  which 
mention the classes "Letter" and "Number, decimal digit", I was expecting 
to write something like:

  identiferRegexp := 
regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
digit}]_]*\z`)

However, this pattern does not compile, giving the error:

  regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
digit}]_]*\z`): error parsing regexp: invalid character class range: 
`\p{Letter}`

Using the short name for character classes (L for Letter, Nd for Number, 
decimal digit) does work however:

  identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`)

You can play with these regexps on play.golang.org 
.

Is this simply an oversight that Unicode character classes like "Letter" 
and "Number, decimal digit" are not available for use in regexps, or should 
I be using them differently?

Many thanks,
Tom

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/844b99d5-0ae1-4e29-b576-cd4f1b1c24b3%40googlegroups.com.

Re: [go-nuts] regexp syntax and named Unicode character classes

2020-01-07 Thread Ian Lance Taylor 
On Tue, Jan 7, 2020 at 10:22 AM Tom Payne  wrote:
>
> tl;dr How should I use named Unicode character classes in regexps?
>
> I'm trying to write a regular expression that matches Go identifiers, which 
> start with a Unicode letter or underscore followed by zero or more Unicode 
> letters, decimal digits, and/or underscores.
>
> Based on the regexp syntax, and the variables in the unicode package which 
> mention the classes "Letter" and "Number, decimal digit", I was expecting to 
> write something like:
>
>   identiferRegexp := 
> regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`)
>
> However, this pattern does not compile, giving the error:
>
>   regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`): error parsing regexp: invalid character class range: 
> `\p{Letter}`
>
> Using the short name for character classes (L for Letter, Nd for Number, 
> decimal digit) does work however:
>
>   identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`)
>
> You can play with these regexps on play.golang.org.
>
> Is this simply an oversight that Unicode character classes like "Letter" and 
> "Number, decimal digit" are not available for use in regexps, or should I be 
> using them differently?

The strings you can use with \p are the ones listed in
unicode.Categories and unicode.Scripts.  So use \pL as you do in the
second example.

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWJQFfQ9C5%2BGdz1uSsGCRWb_pmuphnj%2Bg5jza8%2BytEVrA%40mail.gmail.com.

Re: [go-nuts] regexp syntax and named Unicode character classes

2020-01-07 Thread Tom Payne 
Thank you :) Is this worth adding to the regexp/syntax documentation? I'd 
happily contribute a patch.

On Tuesday, January 7, 2020 at 7:36:02 PM UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Jan 7, 2020 at 10:22 AM Tom Payne > 
> wrote: 
> > 
> > tl;dr How should I use named Unicode character classes in regexps? 
> > 
> > I'm trying to write a regular expression that matches Go identifiers, 
> which start with a Unicode letter or underscore followed by zero or more 
> Unicode letters, decimal digits, and/or underscores. 
> > 
> > Based on the regexp syntax, and the variables in the unicode package 
> which mention the classes "Letter" and "Number, decimal digit", I was 
> expecting to write something like: 
> > 
> >   identiferRegexp := 
> regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`) 
> > 
> > However, this pattern does not compile, giving the error: 
> > 
> >   regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`): error parsing regexp: invalid character class range: 
> `\p{Letter}` 
> > 
> > Using the short name for character classes (L for Letter, Nd for Number, 
> decimal digit) does work however: 
> > 
> >   identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`) 
> > 
> > You can play with these regexps on play.golang.org. 
> > 
> > Is this simply an oversight that Unicode character classes like "Letter" 
> and "Number, decimal digit" are not available for use in regexps, or should 
> I be using them differently? 
>
> The strings you can use with \p are the ones listed in 
> unicode.Categories and unicode.Scripts.  So use \pL as you do in the 
> second example. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a22421cc-becb-496e-8d32-b41506536a54%40googlegroups.com.

Re: [go-nuts] regexp syntax and named Unicode character classes

2020-01-07 Thread Ian Lance Taylor 
On Tue, Jan 7, 2020 at 10:39 AM Tom Payne  wrote:
>
> Thank you :) Is this worth adding to the regexp/syntax documentation? I'd 
> happily contribute a patch.

I think so, if it can be described precisely and tersely.  Thanks.

Ian


> On Tuesday, January 7, 2020 at 7:36:02 PM UTC+1, Ian Lance Taylor wrote:
>>
>> On Tue, Jan 7, 2020 at 10:22 AM Tom Payne  wrote:
>> >
>> > tl;dr How should I use named Unicode character classes in regexps?
>> >
>> > I'm trying to write a regular expression that matches Go identifiers, 
>> > which start with a Unicode letter or underscore followed by zero or more 
>> > Unicode letters, decimal digits, and/or underscores.
>> >
>> > Based on the regexp syntax, and the variables in the unicode package which 
>> > mention the classes "Letter" and "Number, decimal digit", I was expecting 
>> > to write something like:
>> >
>> >   identiferRegexp := 
>> > regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
>> > digit}]_]*\z`)
>> >
>> > However, this pattern does not compile, giving the error:
>> >
>> >   regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
>> > digit}]_]*\z`): error parsing regexp: invalid character class range: 
>> > `\p{Letter}`
>> >
>> > Using the short name for character classes (L for Letter, Nd for Number, 
>> > decimal digit) does work however:
>> >
>> >   identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`)
>> >
>> > You can play with these regexps on play.golang.org.
>> >
>> > Is this simply an oversight that Unicode character classes like "Letter" 
>> > and "Number, decimal digit" are not available for use in regexps, or 
>> > should I be using them differently?
>>
>> The strings you can use with \p are the ones listed in
>> unicode.Categories and unicode.Scripts.  So use \pL as you do in the
>> second example.
>>
>> 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.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/a22421cc-becb-496e-8d32-b41506536a54%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWZan2r3FX_UcE6XNT7vanDLUBi3QjFhyuO0%3DEZ-yG0pA%40mail.gmail.com.

[go-nuts] Re: regexp syntax and named Unicode character classes

2020-01-07 Thread alan . fox6 
As Go's regular expressions are based on RE2, I always use the latter's 
documentation 
page  to check what is and isn't 
allowed.

Note though that: \C, which RE2 normally allows, isn't allowed in Go.

Alan

On Tuesday, January 7, 2020 at 6:21:58 PM UTC, Tom Payne wrote:
>
> Hi,
>
> tl;dr How should I use named Unicode character classes in regexps?
>
> I'm trying to write a regular expression that matches Go identifiers 
> , which start with a Unicode 
> letter or underscore followed by zero or more Unicode letters, decimal 
> digits, and/or underscores.
>
> Based on the regexp syntax , and the 
> variables 
> in the unicode package  which 
> mention the classes "Letter" and "Number, decimal digit", I was expecting 
> to write something like:
>
>   identiferRegexp := 
> regexp.MustCompile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`)
>
> However, this pattern does not compile, giving the error:
>
>   regexp: Compile(`\A[[\p{Letter}]_][[\p{Letter}][\p{Number, decimal 
> digit}]_]*\z`): error parsing regexp: invalid character class range: 
> `\p{Letter}`
>
> Using the short name for character classes (L for Letter, Nd for Number, 
> decimal digit) does work however:
>
>   identiferRegexp := regexp.MustCompile(`\A[\pL_][\pL\p{Nd}_]*\z`)
>
> You can play with these regexps on play.golang.org 
> .
>
> Is this simply an oversight that Unicode character classes like "Letter" 
> and "Number, decimal digit" are not available for use in regexps, or should 
> I be using them differently?
>
> Many thanks,
> Tom
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e6307afc-889c-46de-87b0-6f9a06620421%40googlegroups.com.

Re: [go-nuts] Re: modules exclude version and above

2020-01-07 Thread 'Bryan C. Mills' via golang-nuts 
Ok, I think I've figured out what's going on.
The commits tagged `v2.0.2` and `v2.0.3` in this repo have a module in
subdirectory `v2` that declares its path to be `
github.com/nicksnyder/go-i18n/v2` .
However, that module cannot match the requested path `
github.com/nicksnyder/go-i18n` , so
`go get` does not look there — instead, it looks for a module at the repo
root that lacks a `go.mod` file.
And, indeed, the repo root does lack a `go.mod` file, so the `go` command
interprets it as a module.

Since `v1.10.1` does have a `go.mod` file, `go get -u` should ignore the
`+incompatible` versions as of Go 1.14.
(That's the fix described in
https://tip.golang.org/doc/go1.14#incompatible-versions.)
https://golang.org/issue/31866 would also catch this particular case.

However, there is still a remaining bug, which I've filed as
https://golang.org/issue/36438.
I'm not sure whether we'll fix that one, though: we would give better
diagnostics for some confusing situations, but at the cost of invalidating
some versions that were previously usable.


On Mon, Jan 6, 2020 at 1:53 PM Jérôme LAFORGE 
wrote:

> I use this version:
> go version go1.13.5 linux/amd64
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/eRt5gD5pIhQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/d8e502c5-80cf-4aab-943c-0216b15afa33%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAKWVi_TEHF0GKTzQZSzhXea09ApQUyanEdNM9Yhd8WuwYnpc0g%40mail.gmail.com.

Re: [go-nuts] Re: A question !

2020-01-07 Thread Motaz Hejaze 
Thank you guys for your help,
But do to lake of learning resources for golang , i decided flto go for
node.js in my startup project , thank you all

On Tue, 7 Jan 2020, 5:25 pm Amnon Baron Cohen,  wrote:

>
>
> On Tuesday, 7 January 2020 09:44:28 UTC, Motaz Hejaze wrote:
>>
>>
>> May i ask what is the best deployment for more performance ??
>>
>>>
>>>
> Do whatever is easiest. If you have come from the Python/Django world
> then you will be blown away by Go's speed, whatever deployment you use.
> I would also use the standard library's built in web-server rather than
> proxying
> behind nginx.
>
> A big benefit of Go's improved speed is that you can stop worrying about
> performance.
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/a4063992-911d-4f3c-a518-5088762ba0fb%40googlegroups.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAHV4E-evRFWs7DVg66xCyAXnrjwzU7aWw2owKaMHB8TgFCq4-w%40mail.gmail.com.

[go-nuts] How to reduce the fluctuation of micro benchmark results

2020-01-07 Thread Xiangdong JI 
Hi,

Significant fluctuation is observed when running micro benchmarks, even 
with the same version of go, e.g the following numbers from math/big 
package, could anyone please share practices that may help generate stable 
result?


FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05%  
(p=0.008 n=5+5)
FloatAdd/10-64   5.29µs ± 1%5.56µs ± 0%+5.08%  
(p=0.008 n=5+5)
FloatSub/10-64125ns ± 0% 125ns ± 0%  ~
 (p=0.444 n=5+5)
FloatSub/100-64   126ns ± 0% 126ns ± 0%  ~
 (all equal)
FloatSub/1000-64  150ns ± 0% 150ns ± 0%  ~
 (all equal)
FloatSub/1-64 393ns ± 0% 447ns ± 0%   +13.79%  
(p=0.008 n=5+5)
FloatSub/10-64   3.20µs ± 0%3.20µs ± 0%  ~
 (p=0.056 n=5+5)
ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26%  
(p=0.016 n=5+5)
ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1%  ~
 (p=0.690 n=5+5)
GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60%  
(p=0.029 n=4+4)
GCD10x10/WithXY-64746ns ± 1% 747ns ± 1%  ~
 (p=0.810 n=4+5)
GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0%  ~
 (p=0.730 n=5+5)
GCD10x100/WithXY-64  2.35µs ±14%2.23µs ± 2%  ~
 (p=0.175 n=5+5)
GCD10x1000/WithoutXY-64  1.16µs ±13%1.37µs ±43%  ~
 (p=0.310 n=5+5)
GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29%  ~
 (p=0.841 n=5+5)
GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46%  ~
 (p=0.151 n=5+5)
GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53%  ~
 (p=0.310 n=5+5)
GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16%  ~
 (p=0.421 n=5+5)
GCD10x10/WithXY-64   * 169µs ±19% 271µs ±28%   +60.47% * 
(p=0.016 n=5+5)
GCD100x100/WithoutXY-64  2.37µs ±18%2.31µs ± 8%  ~
 (p=0.841 n=5+5)
GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1%  ~
 (p=0.556 n=5+4)
GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27%  ~
 (p=0.841 n=5+5)
GCD100x1000/WithXY-64   * 7.44µs ± 3%   10.67µs ±22%   +43.33%*  
(p=0.008 n=5+5)
GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3%   -35.83%  
(p=0.016 n=5+4)
GCD100x1/WithXY-64   71.3µs ±93%   118.5µs ±44%  ~
 (p=0.151 n=5+5)
GCD100x10/WithoutXY-64199µs ±56% 195µs ±29%  ~
 (p=1.000 n=5+5)
GCD100x10/WithXY-64  * 459µs ±33% 892µs ±60%   +94.33% * 
(p=0.016 n=5+5)
GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10%  ~
 (p=1.000 n=5+5)
GCD1000x1000/WithXY-64   39.8µs ± 0%43.9µs ±10%   +10.26%  
(p=0.008 n=5+5)
GCD1000x1/WithoutXY-64   41.6µs ± 0%56.0µs ±16%   +34.70%  
(p=0.008 n=5+5)
GCD1000x1/WithXY-64   *154µs ± 0% 302µs ±29%   +96.15%*  
(p=0.008 n=5+5)
GCD1000x10/WithoutXY-64   240µs ± 0% 268µs ±11%   +11.64%  
(p=0.016 n=4+5)
GCD1000x10/WithXY-64 *2.51ms ±60%   9.28ms ±197%  +270.21%*  
(p=0.032 n=5+5)
GCD1x1/WithoutXY-64   545µs ± 0% 549µs ± 0%+0.69%  
(p=0.008 n=5+5)
GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1%  ~
 (p=0.222 n=5+5)
GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27%   +19.66%  
(p=0.008 n=5+5)
GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14%  ~
 (p=0.841 n=5+5)
GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0%  ~
 (p=0.690 n=5+5)
GCD10x10/WithXY-64   84.9ms ± 0%85.0ms ± 0%  ~
 (p=0.905 n=5+4)
Hilbert-64   1.93ms ± 0%1.93ms ± 1%  ~
 (p=1.000 n=4+5)
Binomial-64  3.42µs ± 2%3.59µs ± 8%  ~
 (p=0.095 n=5+5)
QuoRem-644.55µs ± 0%4.55µs ± 0%  ~
 (p=0.659 n=5+5)
Exp-64   17.1ms ± 0%17.1ms ± 0%  ~
 (p=0.841 n=5+5)
Exp2-64  17.1ms ± 0%17.1ms ± 0%  ~
 (p=0.421 n=5+5)
Bitset-6420.8ns ± 0%20.8ns ± 0%  ~
 (p=1.000 n=5+5)
BitsetNeg-64  105ns ± 0% 106ns ± 1%  ~
 (p=0.238 n=4+5)
BitsetOrig-64 231ns ±20% 183ns ± 2%   -20.92%  
(p=0.016 n=5+5)
BitsetNegOrig-64  786ns ±49% 543ns ±32%  ~
 (p=0.143 n=5+5)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5d57b1f4-7e9e-4aa5-bc74-85fac11c

[go-nuts] Re: How to reduce the fluctuation of micro benchmark results

2020-01-07 Thread Xiangdong JI 
BTW. 'drop cache' is made, while setting cpu governor is not supported by 
the platform. 
Thanks.

On Wednesday, January 8, 2020 at 10:19:25 AM UTC+8, Xiangdong JI wrote:
>
> Hi,
>
> Significant fluctuation is observed when running micro benchmarks, even 
> with the same version of go, e.g the following numbers from math/big 
> package, could anyone please share practices that may help generate stable 
> result?
>
>
> FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05%  
> (p=0.008 n=5+5)
> FloatAdd/10-64   5.29µs ± 1%5.56µs ± 0%+5.08%  
> (p=0.008 n=5+5)
> FloatSub/10-64125ns ± 0% 125ns ± 0%  ~
>  (p=0.444 n=5+5)
> FloatSub/100-64   126ns ± 0% 126ns ± 0%  ~
>  (all equal)
> FloatSub/1000-64  150ns ± 0% 150ns ± 0%  ~
>  (all equal)
> FloatSub/1-64 393ns ± 0% 447ns ± 0%   +13.79%  
> (p=0.008 n=5+5)
> FloatSub/10-64   3.20µs ± 0%3.20µs ± 0%  ~
>  (p=0.056 n=5+5)
> ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26%  
> (p=0.016 n=5+5)
> ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1%  ~
>  (p=0.690 n=5+5)
> GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60%  
> (p=0.029 n=4+4)
> GCD10x10/WithXY-64746ns ± 1% 747ns ± 1%  ~
>  (p=0.810 n=4+5)
> GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0%  ~
>  (p=0.730 n=5+5)
> GCD10x100/WithXY-64  2.35µs ±14%2.23µs ± 2%  ~
>  (p=0.175 n=5+5)
> GCD10x1000/WithoutXY-64  1.16µs ±13%1.37µs ±43%  ~
>  (p=0.310 n=5+5)
> GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29%  ~
>  (p=0.841 n=5+5)
> GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46%  ~
>  (p=0.151 n=5+5)
> GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53%  ~
>  (p=0.310 n=5+5)
> GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16%  ~
>  (p=0.421 n=5+5)
> GCD10x10/WithXY-64   * 169µs ±19% 271µs ±28%  
>  +60.47% * (p=0.016 n=5+5)
> GCD100x100/WithoutXY-64  2.37µs ±18%2.31µs ± 8%  ~
>  (p=0.841 n=5+5)
> GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1%  ~
>  (p=0.556 n=5+4)
> GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27%  ~
>  (p=0.841 n=5+5)
> GCD100x1000/WithXY-64   * 7.44µs ± 3%   10.67µs ±22%  
>  +43.33%*  (p=0.008 n=5+5)
> GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3%   -35.83%  
> (p=0.016 n=5+4)
> GCD100x1/WithXY-64   71.3µs ±93%   118.5µs ±44%  ~
>  (p=0.151 n=5+5)
> GCD100x10/WithoutXY-64199µs ±56% 195µs ±29%  ~
>  (p=1.000 n=5+5)
> GCD100x10/WithXY-64  * 459µs ±33% 892µs ±60%  
>  +94.33% * (p=0.016 n=5+5)
> GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10%  ~
>  (p=1.000 n=5+5)
> GCD1000x1000/WithXY-64   39.8µs ± 0%43.9µs ±10%   +10.26%  
> (p=0.008 n=5+5)
> GCD1000x1/WithoutXY-64   41.6µs ± 0%56.0µs ±16%   +34.70%  
> (p=0.008 n=5+5)
> GCD1000x1/WithXY-64   *154µs ± 0% 302µs ±29%  
>  +96.15%*  (p=0.008 n=5+5)
> GCD1000x10/WithoutXY-64   240µs ± 0% 268µs ±11%   +11.64%  
> (p=0.016 n=4+5)
> GCD1000x10/WithXY-64 *2.51ms ±60%   9.28ms ±197%  
> +270.21%*  (p=0.032 n=5+5)
> GCD1x1/WithoutXY-64   545µs ± 0% 549µs ± 0%+0.69%  
> (p=0.008 n=5+5)
> GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1%  ~
>  (p=0.222 n=5+5)
> GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27%   +19.66%  
> (p=0.008 n=5+5)
> GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14%  ~
>  (p=0.841 n=5+5)
> GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0%  ~
>  (p=0.690 n=5+5)
> GCD10x10/WithXY-64   84.9ms ± 0%85.0ms ± 0%  ~
>  (p=0.905 n=5+4)
> Hilbert-64   1.93ms ± 0%1.93ms ± 1%  ~
>  (p=1.000 n=4+5)
> Binomial-64  3.42µs ± 2%3.59µs ± 8%  ~
>  (p=0.095 n=5+5)
> QuoRem-644.55µs ± 0%4.55µs ± 0%  ~
>  (p=0.659 n=5+5)
> Exp-64   17.1ms ± 0%17.1ms ± 0%  ~
>  (p=0.841 n=5+5)
> Exp2-64  17.1ms ± 0%17.1ms ± 0%  ~
>  (p=0.421 n=5+5)
> Bitset-6420.8ns ± 0%20.8ns ± 0%  ~
>  (p=1.000 n=5+5)
> BitsetNeg-64  105ns ± 0% 106ns ± 1%  ~
>  (p=0.238 n=4+5)
> BitsetOrig-64 231ns ±20% 183ns ± 2%   -20.92%  
> (p=0.016 n=5+5)
> BitsetNegOrig-64  786ns ±49% 543ns ±32%

Re: [go-nuts] How to reduce the fluctuation of micro benchmark results

2020-01-07 Thread robert engels 
Take a look at https://github.com/golang/go/issues/24735 


You probably want to increase benchtime to a larger value, even 10x.

> On Jan 7, 2020, at 8:44 PM, Xiangdong JI  wrote:
> 
> BTW. 'drop cache' is made, while setting cpu governor is not supported by the 
> platform. 
> Thanks.
> 
> On Wednesday, January 8, 2020 at 10:19:25 AM UTC+8, Xiangdong JI wrote:
> Hi,
> 
> Significant fluctuation is observed when running micro benchmarks, even with 
> the same version of go, e.g the following numbers from math/big package, 
> could anyone please share practices that may help generate stable result?
> 
> 
> FloatAdd/1-64 669ns ± 0% 676ns ± 1%+1.05%  
> (p=0.008 n=5+5)
> FloatAdd/10-64   5.29µs ± 1%5.56µs ± 0%+5.08%  
> (p=0.008 n=5+5)
> FloatSub/10-64125ns ± 0% 125ns ± 0%  ~ 
> (p=0.444 n=5+5)
> FloatSub/100-64   126ns ± 0% 126ns ± 0%  ~ 
> (all equal)
> FloatSub/1000-64  150ns ± 0% 150ns ± 0%  ~ 
> (all equal)
> FloatSub/1-64 393ns ± 0% 447ns ± 0%   +13.79%  
> (p=0.008 n=5+5)
> FloatSub/10-64   3.20µs ± 0%3.20µs ± 0%  ~ 
> (p=0.056 n=5+5)
> ParseFloatSmallExp-6425.3µs ±15%23.8µs ± 0%-6.26%  
> (p=0.016 n=5+5)
> ParseFloatLargeExp-6484.7µs ± 0%84.8µs ± 1%  ~ 
> (p=0.690 n=5+5)
> GCD10x10/WithoutXY-64 166ns ± 0% 165ns ± 0%-0.60%  
> (p=0.029 n=4+4)
> GCD10x10/WithXY-64746ns ± 1% 747ns ± 1%  ~ 
> (p=0.810 n=4+5)
> GCD10x100/WithoutXY-64438ns ± 0% 439ns ± 0%  ~ 
> (p=0.730 n=5+5)
> GCD10x100/WithXY-64  2.35µs ±14%2.23µs ± 2%  ~ 
> (p=0.175 n=5+5)
> GCD10x1000/WithoutXY-64  1.16µs ±13%1.37µs ±43%  ~ 
> (p=0.310 n=5+5)
> GCD10x1000/WithXY-64 6.20µs ±59%4.71µs ±29%  ~ 
> (p=0.841 n=5+5)
> GCD10x1/WithoutXY-64 16.8µs ±52%11.7µs ±46%  ~ 
> (p=0.151 n=5+5)
> GCD10x1/WithXY-6458.6µs ±53%80.2µs ±53%  ~ 
> (p=0.310 n=5+5)
> GCD10x10/WithoutXY-6472.0µs ±20%77.1µs ±16%  ~ 
> (p=0.421 n=5+5)
> GCD10x10/WithXY-64169µs ±19% 271µs ±28%   +60.47%  
> (p=0.016 n=5+5)
> GCD100x100/WithoutXY-64  2.37µs ±18%2.31µs ± 8%  ~ 
> (p=0.841 n=5+5)
> GCD100x100/WithXY-64 4.22µs ± 7%4.05µs ± 1%  ~ 
> (p=0.556 n=5+4)
> GCD100x1000/WithoutXY-64 3.73µs ± 7%4.02µs ±27%  ~ 
> (p=0.841 n=5+5)
> GCD100x1000/WithXY-647.44µs ± 3%   10.67µs ±22%   +43.33%  
> (p=0.008 n=5+5)
> GCD100x1/WithoutXY-6432.4µs ±63%20.8µs ± 3%   -35.83%  
> (p=0.016 n=5+4)
> GCD100x1/WithXY-64   71.3µs ±93%   118.5µs ±44%  ~ 
> (p=0.151 n=5+5)
> GCD100x10/WithoutXY-64199µs ±56% 195µs ±29%  ~ 
> (p=1.000 n=5+5)
> GCD100x10/WithXY-64   459µs ±33% 892µs ±60%   +94.33%  
> (p=0.016 n=5+5)
> GCD1000x1000/WithoutXY-6422.8µs ±14%22.5µs ±10%  ~ 
> (p=1.000 n=5+5)
> GCD1000x1000/WithXY-64   39.8µs ± 0%43.9µs ±10%   +10.26%  
> (p=0.008 n=5+5)
> GCD1000x1/WithoutXY-64   41.6µs ± 0%56.0µs ±16%   +34.70%  
> (p=0.008 n=5+5)
> GCD1000x1/WithXY-64   154µs ± 0% 302µs ±29%   +96.15%  
> (p=0.008 n=5+5)
> GCD1000x10/WithoutXY-64   240µs ± 0% 268µs ±11%   +11.64%  
> (p=0.016 n=4+5)
> GCD1000x10/WithXY-64 2.51ms ±60%   9.28ms ±197%  +270.21%  
> (p=0.032 n=5+5)
> GCD1x1/WithoutXY-64   545µs ± 0% 549µs ± 0%+0.69%  
> (p=0.008 n=5+5)
> GCD1x1/WithXY-64 1.20ms ± 0%1.20ms ± 1%  ~ 
> (p=0.222 n=5+5)
> GCD1x10/WithoutXY-64 1.40ms ± 0%1.67ms ±27%   +19.66%  
> (p=0.008 n=5+5)
> GCD1x10/WithXY-6411.7ms ± 9%11.4ms ±14%  ~ 
> (p=0.841 n=5+5)
> GCD10x10/WithoutXY-6438.8ms ± 0%38.8ms ± 0%  ~ 
> (p=0.690 n=5+5)
> GCD10x10/WithXY-64   84.9ms ± 0%85.0ms ± 0%  ~ 
> (p=0.905 n=5+4)
> Hilbert-64   1.93ms ± 0%1.93ms ± 1%  ~ 
> (p=1.000 n=4+5)
> Binomial-64  3.42µs ± 2%3.59µs ± 8%  ~ 
> (p=0.095 n=5+5)
> QuoRem-644.55µs ± 0%4.55µs ± 0%  ~ 
> (p=0.659 n=5+5)
> Exp-64   17.1ms ± 0%17.1ms ± 0%  ~ 
> (p=0.841 n=5+5)
> Exp2-64  17.1ms ± 0%17.1ms ± 0%  ~ 
> (p=0.421 n=5+5)
> Bitset-6420.8ns ± 0%20.8ns ± 0%  ~ 
> (p=1.000 n=5+5)
> BitsetNeg-64

[go-nuts] performance improvements

2020-01-07 Thread robert engels 
Shout out to the Go team on a job well done. I took the time to re-run some 
benchmarks, here are the results (both 1.9.7 and 1.13.5 re-run on same hardware 
& OS).

>From fixed 

iMac:tmp robertengels$ benchcmp bench_1_9_7.txt bench_1_13_15.txt 
benchmark old ns/op new ns/op delta
BenchmarkAddFixed-8   1.29  1.01  -21.71%
BenchmarkAddDecimal-8 352   249   -29.26%
BenchmarkAddBigInt-8  15.3  14.8  -3.27%
BenchmarkAddBigFloat-880.6  80.1  -0.62%
BenchmarkMulFixed-8   4.40  4.60  +4.55%
BenchmarkMulDecimal-8 71.8  73.8  +2.79%
BenchmarkMulBigInt-8  17.8  17.4  -2.25%
BenchmarkMulBigFloat-837.1  35.4  -4.58%
BenchmarkDivFixed-8   4.75  4.63  -2.53%
BenchmarkDivDecimal-8 882   769   -12.81%
BenchmarkDivBigInt-8  56.8  45.4  -20.07%
BenchmarkDivBigFloat-8121   109   -9.92%
BenchmarkCmpFixed-8   1.02  0.50  -50.69%
BenchmarkCmpDecimal-8 8.42  8.03  -4.63%
BenchmarkCmpBigInt-8  5.93  5.44  -8.26%
BenchmarkCmpBigFloat-85.11  5.63  +10.18%
BenchmarkStringFixed-860.1  58.6  -2.50%
BenchmarkStringNFixed-8   59.0  57.2  -3.05%
BenchmarkStringDecimal-8  259   214   -17.37%
BenchmarkStringBigInt-8   164   126   -23.17%
BenchmarkStringBigFloat-8 465   433   -6.88%
BenchmarkWriteTo-845.1  38.4  -14.86%





-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5267D756-D269-4ABC-B8EB-D7C98D29F82E%40ix.netcom.com.

[go-nuts] Re: how to get the full path of current process' executable file

2020-01-07 Thread Eric Chai 
Moved to https://github.com/kardianos/osext

On Thursday, March 13, 2014 at 3:54:29 PM UTC+8, Dobrosław Żybort wrote:
>
> Too bad you did not search on stackoverflow:
> http://stackoverflow.com/a/15038241/1722542
>
> My answer there:
>
> Use package bitbucket.org/kardianos/osext.
>
> It's providing function Executable() that returns an absolute path to the 
> current program executable. *It's portable between systems.*
>
> Online documentation 
>
> package main
> import (
> "bitbucket.org/kardianos/osext"
> "fmt")
>
> func main() {
> filename, _ := osext.Executable()
> fmt.Println(filename)}
>
>
> Best regards,
> Dobrosław Żybort
>
> W dniu czwartek, 13 marca 2014 06:45:20 UTC+1 użytkownik Shark Flh napisał:
>>
>> how to get the full path of current process' executable file
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3290c2f3-77f8-4de1-a934-38bfb30325f8%40googlegroups.com.