Re: [go-nuts] plugin questions....

[Basile Starynkevitch]

On Wednesday, March 1, 2017 at 7:17:42 AM UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Feb 28, 2017 at 12:44 PM, Basile Starynkevitch 
>  wrote: 
> > Can the packages defined in one plugin be visible from plugins loaded 
> > afterwards? I'm thinking of a dlopen with  RTLD_GLOBAL flag in C 
> parlance. 
>
> I'm not sure this really makes sense in a Go context.  I'm not sure 
> how you would refer to those symbols. 
>

The scenario would be the following:

a plugin *P1* defines the P1_foo () function. *P1* is loaded (and I would 
like the name to be visible afterwards, see below). We can assume that the 
loading program & process does not have any P1_foo in it.

later, *another* plugin *P2* defines the P2_bar() function which calls 
P1_foo(), and I would like that to mean the P1_foo() function inside *P1*. 
It seems that this is not possible currently. (of course loading *P2* 
before loading *P1* should fail). I don't understand why would that not 
make any sense.

Of course, once could play dirty tricks (somehow equivalent to what the 
plugin ELF machinery does internally) like using function variables (that 
is closures) systematically, for example having the main program define a 
map from string to functions and register inside that map at init time of 
the plugin.

Cheers.

-- 
Basile Starynkevitch

-- 
You received this message because you 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] plugin questions....

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 12:44 PM, Basile Starynkevitch
 wrote:
>
> Can a plugin be made of several source files in Go?

Yes.

> How should then I
> compile a single plugin myfoo.so from several Go source files ? Can a
> plugin define several packages?

A plugin is a main package.  It can be built from as many source files
as you like.  I think a plugin can only define a single main package.


> Can a plugin contain several packages? How can I refer to symbols inside
> packages of plugins? As the usual "packagename.PublicSymbol" passed as
> argument to plugin.Lookup ? If yes, that should IMHO be documented.

As far as I know you can only refer to symbols defined in the main
package.  I could be wrong about that.


> Can one get a plugin handle for the entire program & process (like dlopen(3)
> does with a NULL filename argument on Linux)  From my understanding of
> plugin/plugin_dlopen.go this is not the case. I wish it would be the case.

You can not.


> Can the packages defined in one plugin be visible from plugins loaded
> afterwards? I'm thinking of a dlopen with  RTLD_GLOBAL flag in C parlance.

I'm not sure this really makes sense in a Go context.  I'm not sure
how you would refer to those symbols.


> I'm interested in having my Go program (monimelt on github, currently
> Feb2017 in pre-alpha stage, so nothing is working) generate at runtime some
> Go source files, compiling them as a plugin (by forking some compilation
> command at runtime), and loading them. BTW, I'm really interested in Go only
> since its plugin abilities so they matter a lot to me.

As far as I know that would work.  Note that the plugin support is
very new, is experimental, and several bugs have been reported against
it already (search for plugin at https://golang.org/issue).


> Is dladdr(3) available in Go? I would like, given a pointer, to get the name
> of the function at the same address (but I guess there could be issues with
> closures).

See runtime.FuncForPC.


> Is there any name mangling issues the user of Go plugins should be aware of?

I don't think so.  I mean, names are mangled slightly, but you
shouldn't need to know about it.

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] Pipm your brain. Golang exercise

[tanya - cube]

Anagram exercise 

-- 
You received this message because you 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] plugin questions....

[Basile Starynkevitch]

On Tuesday, February 28, 2017 at 10:16:27 PM UTC+1, Ian Lance Taylor wrote:
>
> On Tue, Feb 28, 2017 at 12:44 PM, Basile Starynkevitch 
>  wrote: 
> > 
> > A few questions and wishes about plugins (Go1.8 Linux/amd64) 
>
> Sorry, but you need to indicate whether you are talking about 
> -buildmode=plugin (an experimental option to build plugins that may be 
> opened by Go programs) or -buildmode=c-shared (a supported option to 
> build plugins that may be opened by non-Go programs). 
>

I'm talking about plugins written in Go for a Go program, so 
-buildmode=plugin
(I'm coding in Go because I don't want to code my multi-thread friendly GC 
in C++ or C)
 

>
> Ian 
>

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

[go-nuts] Re: Golang and WebAssembly

[Dmitry Pavluk]

FYI there's now a GItHub issue  
tracking the developent of wasm support.

On Tuesday, July 7, 2015 at 9:08:22 PM UTC-4, Ilya Kowalewski wrote:
>
> Salute nuts,
>
> I read about WebAssembly (WA) recently and this topic haven't left my head 
> ever since. Am I right that if we had a Go-to-WA translator when actually 
> becomes standard, we'd been able to run Go applications on the front-end? 
> That makes hell lot of sense to me. We could kill JavaScript, once and for 
> all. Among all the modern languages, Go seems to be a pretty great 
> candidate for such a JS-killer.
>
> Go team, are you generally going to look into this topic in the near 
> future? IIRC, Google loved Go, e.g. for networking stuff, who knows, maybe 
> you guys would love it for front-end?
>
> Best regards,
> Ilya Kowalewski
>

-- 
You received this message because you 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: Some best practices for debuging and optimizing with -gcflags?

[Derek Parker]

FWIW Delve (https://github.com/derekparker/delve) sets the proper `gcflags` 
to produce a binary optimal for debugging if you need a debugger.

On Monday, February 27, 2017 at 4:17:39 PM UTC-8, jamalsm...@gmail.com 
wrote:
>
> What are some best practices for general purpose -gcflags to use for 
> debugging and conversely for optimizing code?
>

-- 
You received this message because you 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] Support for the race detector on ARM

[Owen Waller]

Hi Dimitry,
> 
> 
> The make goal of the current mapping is to make MemToShadow function
> fast (no memory accesses, no branching).
> For starters you can take any simple mapping at the cost making
> MemToShadow slower.
> 

OK that's good. As I wasn't intending to do anything apart from put in the new 
memory map, rebuild things and then try it against some sort of hello world 
example.

I do not want to be changing any code beyond this if a can avoid it.

> > 
> > 
and do you want
to take a stab at what the mappings might be for a 32 bit system?


I don't have time to work on this.


I understand that. But at the minute, I don't understand how the
numbers in the memory map are arrived at. Is the process documented
somewhere so I can work this out for myself?

> 
You need clang as it contains the master copy of tsan runtime. Here
are some building instructions:
https://github.com/google/sanitizers/wiki/AddressSanitizerHowToBuild


Thank you for this. It looks like I'll need to set up clang etc first.

Owen
> 

-- 
You received this message because you 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] x509.Certificate Template: Is there any support for URI in SubjectAltName?

[lita via golang-nuts]

Link: https://godoc.corp.google.com/pkg/crypto/x509/#Certificate

Seems currently it only supports as listed below, is there plan to support 
URI?

// Subject Alternate Name valuesDNSNames   []string
EmailAddresses []string
IPAddresses[]net .IP 


-- 
You received this message because you 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] Subject_Alt_name in x509.Certificate

['Tao Li' via golang-nuts]

Currently it only supports DNSNames, EmailAddresses, and IPAddresses, is 
there any plan to support URI as well?

Thanks
Tao

-- 
You received this message because you 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] Extra bytes in Gob format

[Rob Pike]

When writing singletons (Encode() as opposed to Encode()), the
code essentially wraps it in a struct and makes it a single field, because
the rest of the code works that way. I don't remember the exact reason it
was built like that, other than the fact that singletons came later, but it
doesn't matter now because we can't change it.

-rob


On Tue, Feb 28, 2017 at 1:47 PM, Axel Wagner 
wrote:

> I'm not convinced of that, as I'm having trouble seeing the logic behind
> those extra bytes (they don't seem necessary or to convey any information
> to me), but I decided to wait for whatever update is deemed appropriate and
> then reevaluate :)
>
> On Tue, Feb 28, 2017 at 4:44 PM, Sam Whited  wrote:
>
>> On Tue, Feb 28, 2017 at 11:49 AM, Axel Wagner
>>  wrote:
>> > FYI, this looks very similar to this issue I filed a while back:
>> > https://github.com/golang/go/issues/16978
>>
>> Looks like there's nothing to do here (except the actual work to
>> update the docs); thanks Axel!
>>
>> —Sam
>>
>
>

-- 
You received this message because you 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] Extra bytes in Gob format

['Axel Wagner' via golang-nuts]

I'm not convinced of that, as I'm having trouble seeing the logic behind
those extra bytes (they don't seem necessary or to convey any information
to me), but I decided to wait for whatever update is deemed appropriate and
then reevaluate :)

On Tue, Feb 28, 2017 at 4:44 PM, Sam Whited  wrote:

> On Tue, Feb 28, 2017 at 11:49 AM, Axel Wagner
>  wrote:
> > FYI, this looks very similar to this issue I filed a while back:
> > https://github.com/golang/go/issues/16978
>
> Looks like there's nothing to do here (except the actual work to
> update the docs); thanks Axel!
>
> —Sam
>

-- 
You received this message because you 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] Extra bytes in Gob format

[Sam Whited]

On Tue, Feb 28, 2017 at 11:49 AM, Axel Wagner
 wrote:
> FYI, this looks very similar to this issue I filed a while back:
> https://github.com/golang/go/issues/16978

Looks like there's nothing to do here (except the actual work to
update the docs); thanks Axel!

—Sam

-- 
You received this message because you 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] plugin questions....

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 12:44 PM, Basile Starynkevitch
 wrote:
>
> A few questions and wishes about plugins (Go1.8 Linux/amd64)

Sorry, but you need to indicate whether you are talking about
-buildmode=plugin (an experimental option to build plugins that may be
opened by Go programs) or -buildmode=c-shared (a supported option to
build plugins that may be opened by non-Go programs).

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] plugin questions....

[Basile Starynkevitch]

Hello All,

A few questions and wishes about plugins (Go1.8 Linux/amd64)

Can a plugin be made of several source files in Go? How should then I 
compile a single plugin myfoo.so from several Go source files ? Can a  
plugin define several packages? 

Can a plugin contain several packages? How can I refer to symbols inside 
packages of plugins? As the usual "packagename.PublicSymbol" passed as 
argument to plugin.Lookup  ? If yes, that 
should IMHO be documented.

Can one get a plugin handle for the entire program & process (like dlopen(3) 
 does with a NULL 
*filename* argument on Linux)  From my understanding of 
plugin/plugin_dlopen.go  
this is not the case. I wish it would be the case.

Can the packages defined in one plugin be visible from plugins loaded 
afterwards? I'm thinking of a dlopen with  *RTLD_GLOBAL *flag in C parlance.

I'm interested in having my Go program (monimelt 
 on github, currently Feb2017 in 
pre-alpha stage, so nothing is working) generate at runtime some Go source 
files, compiling them as a plugin (by forking some compilation command at 
runtime), and loading them. BTW, I'm really interested in Go only since its 
plugin abilities so they matter a lot to me.

Is dladdr(3)  available 
in Go? I would like, given a pointer, to get the name of the function at 
the same address (but I guess there could be issues with closures).

Is there any name mangling  
issues the user of Go plugins should be aware of?

Regards.


-- 
Basile Starynkevitch (France)   -   http://starynkevitch.net/Basile/ 



-- 
You received this message because you 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] Linking static c++ library with Go using SWIG

[Chun Zhang]

Thank you for your reply! I read a few posts between you and Stephen before 
posting this. 

Sorry, it was a bad copy and paste. 

I did have the import "C" line in the file. But I have the same error. 

I can "go build libcolor.go" itself with no error. But that does not seem 
to build the whole library.

Best Regards,
Chun

On Tuesday, February 28, 2017 at 2:44:21 PM UTC-5, Ian Lance Taylor wrote:
>
> On Tue, Feb 28, 2017 at 11:04 AM, Chun Zhang  > wrote: 
> > 
> > An empty libcolor.go file with the following lines was manually created 
> > 
> > --- 
> > package libcolor 
> > 
> > // #cgo CFLAGS: -I . 
> > // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work 
> > // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at 
> the 
> > correct place 
>
> Note that this is only effective if those comments appear directly 
> before an `import "C"` line. 
>
> 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] Go 1.8 compiler SEGV - issue #19323

[Basile Starynkevitch]

Hello All,

I'm still a newbie, and I managed to crash the Go 1.8 compiler 
(Linux/amd64/Debian/Sid). Probably I have some mistake in my own code (but 
I am not expecting it to SEGV the compiler)

I've written my first Go report. https://github.com/golang/go/issues/19323 
Is it complete enough?

For some reason, I might have not been able to upload the faulty program (a 
quite small one). To help Go maintainers, I have attached it here.

Regards

-- 
Basile Starynkevitch (France) http://starynkevitch.net/Basile/


-- 
You received this message because you 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.


monimelt-go-segv.tar.gz
Description: Binary data

Re: [go-nuts] Linking static c++ library with Go using SWIG

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 11:04 AM, Chun Zhang  wrote:
>
> An empty libcolor.go file with the following lines was manually created
>
> ---
> package libcolor
>
> // #cgo CFLAGS: -I .
> // #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
> // #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at the
> correct place

Note that this is only effective if those comments appear directly
before an `import "C"` line.

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] Linking static c++ library with Go using SWIG

[Chun Zhang]

Hi, All, 

I have googled quite a bit about this issue, there are some tutorials 
online. But most of them targeted either at older go releases or C instead 
of C++. 

Can somebody please help me to figure out how to solve the following issues?

I have to use a static library, wrote in C++ in a go project. I have the 
libcolor.a and the COLOR.h header file, the libcolor.a relies on some other 
libraries, such as libboost_system.a, libxml2.a etc to build. 

I wrote a libcolor.swigcxx file as follows:
---
%module libcoror

%{
#include "include/COLOR.h"
#include 
#include 

/* This is where we initialize any global parameters that are not 
search-thread specific */
extern void COLOR_init_global_config(int argc, char *argv[]);  // from the 
COLOR.h file, which is one of the APIs I would like to use

%}

#include "include/COLOR.h"
extern void COLOR_init_global_config(int argc, char *argv[]);
---

An empty libcolor.go file with the following lines was manually created

---
package libcolor

// #cgo CFLAGS: -I .
// #cgo CXXFLAGS: -std=c++11 <--- this does not seem to work
// #cgo LDFLAGS: -L${SRCDIR}/lib/ -lCOLOR.a -lz <--- this is placed at the 
correct place
---

When I tried to build this using "go build -x" CLI, I hit the following 
error:

WORK=/tmp/go-build797493895
mkdir -p $WORK/klow/libcolor/_obj/
mkdir -p $WORK/klow/
swig -version
cd $WORK
/usr/local/go/pkg/tool/linux_amd64/compile -o ./klow/libcolor/_obj/_go_.o 
-trimpath . -p main -complete -buildid 
73a7f9534f74346db4b3e0f48875da9dbf8bc2fd -D _$WORK ./swig_intsize.go
cd /home/chzhang/go/src/klow/libcolor
swig -go -cgo -intgosize 64 -module libcolor -o 
$WORK/klow/libcolor/_obj/libcolor_wrap.cxx -outdir 
$WORK/klow/libcolor/_obj/ -c++ libcolor.swigcxx
CGO_LDFLAGS="-g" "-O2" /usr/local/go/pkg/tool/linux_amd64/cgo -objdir 
$WORK/klow/libcolor/_obj/ -importpath klow/libcolor -- -I 
$WORK/klow/libcolor/_obj/ $WORK/klow/libcolor/_obj/libcolor.go
cd $WORK
gcc -fdebug-prefix-map=a=b -c trivial.c
gcc -gno-record-gcc-switches -c trivial.c
cd /home/chzhang/go/src/klow/libcolor
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
$WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_main.o -c 
$WORK/klow/libcolor/_obj/_cgo_main.c
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
$WORK/klow/libcolor/_obj/ -g -O2 -o $WORK/klow/libcolor/_obj/_cgo_export.o 
-c $WORK/klow/libcolor/_obj/_cgo_export.c
gcc -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
$WORK/klow/libcolor/_obj/ -g -O2 -o 
$WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
 
-c 
$WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.c
g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -I 
$WORK/klow/libcolor/_obj/ -g -O2 -o 
$WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
 
-c $WORK/klow/libcolor/_obj/libcolor_wrap.cxx
# klow/libcolor
In file included from $WORK/klow/libcolor/_obj/libcolor_wrap.cxx:243:0:
./include/COLOR.h:13:43: warning: defaulted and deleted functions only 
available with -std=c++11 or -std=gnu++11
   PerSessionData(const PerSessionData )=default;
   ^
./include/COLOR.h:14:53: warning: defaulted and deleted functions only 
available with -std=c++11 or -std=gnu++11
   PerSessionData& operator=(const PerSessionData)=default;
 ^
g++ -I . -fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=$WORK=/tmp/go-build -gno-record-gcc-switches -o 
$WORK/klow/libcolor/_obj/_cgo_.o $WORK/klow/libcolor/_obj/_cgo_main.o 
$WORK/klow/libcolor/_obj/_cgo_export.o 
$WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor.cgo2.o
 
$WORK/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o
 
-g -O2
# klow/libcolor
/tmp/go-build797493895/klow/libcolor/_obj/_tmp_go-build797493895_klow_libcolor__obj_libcolor_wrap.cxx.o:
 
In function `_wrap_COLOR_init_global_config_libcolor_3cea422eb6211fe0':
/tmp/go-build/klow/libcolor/_obj/libcolor_wrap.cxx:285: undefined reference 
to `COLOR_init_global_config(int, char**)'
collect2: error: ld returned 1 exit status


Looks like there are two errors:
1, the C++11 warning
2, the linker can't find the function COLOR_init_global_config in the 
static library. That means the compiler directives I defined in libcolor.go 
was not successfully passed to the compiler. From the log, looks like 
another libcolor.go was generated in the $WORK directory by swig. The one I 
manually created was not used at all. 

Can somebody please help me to figure out what I need to do to get this 

[go-nuts] Re: casting slice of rune to string picks up extra characters for some inputs

[Robert Johnstone]

Hello,

Strings are encoded using UTF-8, which is a multi-byte encoding.  Different 
runes require different lengths to be encoded, and the prefix you noted is 
how that length is transmitted (although the ranges in your message don't 
seem to be correct).

Robert


On Tuesday, 28 February 2017 12:29:07 UTC-5, Fraser Hanson wrote:
>
> https://play.golang.org/p/05wZM9BhfB
>
> I'm working on some code that reads UTF32 and converts it to go strings. 
> I'm finding some surprising behavior when casting slices of runes to 
> strings.
>
>  runes := []rune{'©'}
>  fmt.Printf(" cast to string: (%s)\n", string(runes))
>  fmt.Printf("bytes in string: (%x)\n", string(runes))
> Output:
>
>  cast to string: (©)
> bytes in string: (c2a9) // <-- where's the C2 byte coming from??
>
>
> The weird part is that casting the rune slice to a string causes it to 
> pick up an additional leading character. 
>
> runesi 0x00-0x7f get nothing prepended.
> runes 0x80-0xbf gets a leading c2 byte as seen above.
> runes 0xc0-0xff gets a leading c3 byte.
> rune 0x100 gets a leading c4 byte.  Seems like a pattern here.
>
> The same thing happens if I add the runes into a bytes.Buffer with 
> WriteRune(), then print it out with bytes.Buffer.String().
>
> Can anyone explain this?  
> What's the correct way to convert a slice of runes into a string?
>

-- 
You received this message because you 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: Building golang on MIPS using gccgo

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 9:41 AM, James Cowgill  wrote:
>
> On 28/02/17 17:30, Ian Lance Taylor wrote:
>> On Tue, Feb 28, 2017 at 7:33 AM, James Cowgill  
>> wrote:
>>>
>>> Stumbling over this thread:
>>> https://groups.google.com/forum/#!topic/golang-nuts/waTy56I_KWQ
>>>
>>> On 25/03/16 17:08, Ian Lance Taylor wrote:
 mipsn64 is a GOARCH value used by gccgo, but not by gc.  The gc
 compiler uses mips64 and mips64le.  It's not clear to me how we are
 going to resolve this.
>>>
>>> This is still a problem. It is currently not possible to build golang
>>> using gccgo on mips* due to it. What is the solution? Why can't (for
>>> instance) gccgo move to using the GOARCH values from golang?
>>
>> The complexity is that since gccgo is based on GCC, it supports
>> multiple different calling conventions.  Which calling convention
>> should "mips64" represent?  I don't have an answer.  I also haven't
>> really thought about it.
>
> I think there already is a mapping:
>
> mips, mipsle = o32
> mips64p32, mips64p32le = n32
> mips64, mips64le = n64
>
> I see there is "support" for o64 in gccgo. That ABI (and the other MIPS
> ABIs gcc supports) have close to 0 users so I expect there isn't anyone
> using it for go.
>
> I can have a go at writing a patch for this. I was just wondering if
> this was a good idea.

I guess if that makes sense to you it's OK with me.

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] casting slice of rune to string picks up extra characters for some inputs

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 9:05 AM, Fraser Hanson  wrote:
> https://play.golang.org/p/05wZM9BhfB
>
> I'm working on some code that reads UTF32 and converts it to go strings.
> I'm finding some surprising behavior when casting slices of runes to
> strings.
>
>  runes := []rune{'©'}
>  fmt.Printf(" cast to string: (%s)\n", string(runes))
>  fmt.Printf("bytes in string: (%x)\n", string(runes))
> Output:
>
>  cast to string: (©)
> bytes in string: (c2a9) // <-- where's the C2 byte coming from??
>
>
> The weird part is that casting the rune slice to a string causes it to pick
> up an additional leading character.
>
> runesi 0x00-0x7f get nothing prepended.
> runes 0x80-0xbf gets a leading c2 byte as seen above.
> runes 0xc0-0xff gets a leading c3 byte.
> rune 0x100 gets a leading c4 byte.  Seems like a pattern here.
>
> The same thing happens if I add the runes into a bytes.Buffer with
> WriteRune(), then print it out with bytes.Buffer.String().
>
> Can anyone explain this?
> What's the correct way to convert a slice of runes into a string?

When you convert []rune to string, the runes are encoded into UTF-8
and the resulting bytes are the contents of the string.  That is what
you are seeing.  I don't know what you expect to see.

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] Extra bytes in Gob format

['Axel Wagner' via golang-nuts]

FYI, this looks very similar to this issue I filed a while back:
https://github.com/golang/go/issues/16978

On Tue, Feb 28, 2017 at 12:07 PM, Rob Pike  wrote:

> Please do.
>
> I was sure it was there somewhere but I couldn't find it. Check again
> (look internally as well) before proceeding.
>
> -rob
>
>
> On Tue, Feb 28, 2017 at 8:53 AM, Sam Whited  wrote:
>
>> On Tue, Feb 28, 2017 at 1:04 AM, Rob Pike  wrote:
>> > For a single object, not a struct, it still gets sent as a struct with
>> one
>> > field. The 0 is the marker after the last (only) field is sent.
>>
>> Thanks; that makes sense. So it fits in the grammar description by
>> virtue of being part of "encoding of a value", but I don't see
>> anywhere that actually says that values are always encoded as structs.
>> This might be a good place to improve the documentation a bit. Unless
>> someone points me at something obvious I'm missing, I'll file an issue
>> to improve the docs, and possibly a CL.
>>
>> Thanks again.
>>
>> —Sam
>>
>
> --
> You received this message because you 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: casting slice of rune to string picks up extra characters for some inputs

[Fraser Hanson]

I understand now, it's just the UTF-8 representation of these runes.

Even though ascii 128-255 are representable as single bytes (e.g. 0x80), 
UTF-8 doesn't do it that way and prepends a byte.
The results seen in my output are shown as the UTF-8 representation in the 
unicode tables:

https://unicode-table.com/en/0080/
https://unicode-table.com/en/00FF/

As described in the go docs, casting anything to a string results in UTF-8. 
 


-- 
You received this message because you 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] casting slice of rune to string picks up extra characters for some inputs

[Rob Pike]

https://en.wikipedia.org/wiki/UTF-8
https://blog.golang.org/strings

-rob

-- 
You received this message because you 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: casting slice of rune to string picks up extra characters for some inputs

[Volker Dobler]

Strings in Go are UTF-8, so it's expected.
See e.g. http://www.fileformat.info/info/unicode/char/00a9/index.htm
What bytes for © _would_ you expect? And why?

V.

Am Dienstag, 28. Februar 2017 18:29:07 UTC+1 schrieb Fraser Hanson:
>
> https://play.golang.org/p/05wZM9BhfB
>
> I'm working on some code that reads UTF32 and converts it to go strings. 
> I'm finding some surprising behavior when casting slices of runes to 
> strings.
>
>  runes := []rune{'©'}
>  fmt.Printf(" cast to string: (%s)\n", string(runes))
>  fmt.Printf("bytes in string: (%x)\n", string(runes))
> Output:
>
>  cast to string: (©)
> bytes in string: (c2a9) // <-- where's the C2 byte coming from??
>
>
> The weird part is that casting the rune slice to a string causes it to 
> pick up an additional leading character. 
>
> runesi 0x00-0x7f get nothing prepended.
> runes 0x80-0xbf gets a leading c2 byte as seen above.
> runes 0xc0-0xff gets a leading c3 byte.
> rune 0x100 gets a leading c4 byte.  Seems like a pattern here.
>
> The same thing happens if I add the runes into a bytes.Buffer with 
> WriteRune(), then print it out with bytes.Buffer.String().
>
> Can anyone explain this?  
> What's the correct way to convert a slice of runes into a string?
>

-- 
You received this message because you 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] Can ServerMux serve two different handler functions on / and a path beyond / ?

[Howard Guo]

Hey fellow gophers.

As it is currently implemented, if http.ServerMux serves a FileServer on a 
path beyond "/", for example "/mydir", and then serves a very different 
document on "/", the FileServer handler will not be triggered at all and 
the "/" handler gets all the requests.

Is there a workaround so that FileServer(s) will continue to function, even 
though a very different handler is installed on path "/" ?

Kind regards,
Howard

-- 
You received this message because you 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: Building golang on MIPS using gccgo

[James Cowgill]

Hi,

On 28/02/17 17:30, Ian Lance Taylor wrote:
> On Tue, Feb 28, 2017 at 7:33 AM, James Cowgill  
> wrote:
>>
>> Stumbling over this thread:
>> https://groups.google.com/forum/#!topic/golang-nuts/waTy56I_KWQ
>>
>> On 25/03/16 17:08, Ian Lance Taylor wrote:
>>> mipsn64 is a GOARCH value used by gccgo, but not by gc.  The gc
>>> compiler uses mips64 and mips64le.  It's not clear to me how we are
>>> going to resolve this.
>>
>> This is still a problem. It is currently not possible to build golang
>> using gccgo on mips* due to it. What is the solution? Why can't (for
>> instance) gccgo move to using the GOARCH values from golang?
> 
> The complexity is that since gccgo is based on GCC, it supports
> multiple different calling conventions.  Which calling convention
> should "mips64" represent?  I don't have an answer.  I also haven't
> really thought about it.

I think there already is a mapping:

mips, mipsle = o32
mips64p32, mips64p32le = n32
mips64, mips64le = n64

I see there is "support" for o64 in gccgo. That ABI (and the other MIPS
ABIs gcc supports) have close to 0 users so I expect there isn't anyone
using it for go.

I can have a go at writing a patch for this. I was just wondering if
this was a good idea.

James

-- 
You received this message because you 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: Building golang on MIPS using gccgo

[Ian Lance Taylor]

On Tue, Feb 28, 2017 at 7:33 AM, James Cowgill  wrote:
>
> Stumbling over this thread:
> https://groups.google.com/forum/#!topic/golang-nuts/waTy56I_KWQ
>
> On 25/03/16 17:08, Ian Lance Taylor wrote:
>> mipsn64 is a GOARCH value used by gccgo, but not by gc.  The gc
>> compiler uses mips64 and mips64le.  It's not clear to me how we are
>> going to resolve this.
>
> This is still a problem. It is currently not possible to build golang
> using gccgo on mips* due to it. What is the solution? Why can't (for
> instance) gccgo move to using the GOARCH values from golang?

The complexity is that since gccgo is based on GCC, it supports
multiple different calling conventions.  Which calling convention
should "mips64" represent?  I don't have an answer.  I also haven't
really thought about it.

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] casting slice of rune to string picks up extra characters for some inputs

[Fraser Hanson]

https://play.golang.org/p/05wZM9BhfB

I'm working on some code that reads UTF32 and converts it to go strings. 
I'm finding some surprising behavior when casting slices of runes to 
strings.

 runes := []rune{'©'}
 fmt.Printf(" cast to string: (%s)\n", string(runes))
 fmt.Printf("bytes in string: (%x)\n", string(runes))
Output:

 cast to string: (©)
bytes in string: (c2a9) // <-- where's the C2 byte coming from??


The weird part is that casting the rune slice to a string causes it to pick 
up an additional leading character. 

runesi 0x00-0x7f get nothing prepended.
runes 0x80-0xbf gets a leading c2 byte as seen above.
runes 0xc0-0xff gets a leading c3 byte.
rune 0x100 gets a leading c4 byte.  Seems like a pattern here.

The same thing happens if I add the runes into a bytes.Buffer with 
WriteRune(), then print it out with bytes.Buffer.String().

Can anyone explain this?  
What's the correct way to convert a slice of runes into a string?

-- 
You received this message because you 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] Building golang on MIPS using gccgo

[James Cowgill]

Hi,

Stumbling over this thread:
https://groups.google.com/forum/#!topic/golang-nuts/waTy56I_KWQ

On 25/03/16 17:08, Ian Lance Taylor wrote:
> mipsn64 is a GOARCH value used by gccgo, but not by gc.  The gc
> compiler uses mips64 and mips64le.  It's not clear to me how we are
> going to resolve this.

This is still a problem. It is currently not possible to build golang
using gccgo on mips* due to it. What is the solution? Why can't (for
instance) gccgo move to using the GOARCH values from golang?

Thanks,
James

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


signature.asc
Description: OpenPGP digital signature

Re: [go-nuts] Extra bytes in Gob format

[Rob Pike]

Please do.

I was sure it was there somewhere but I couldn't find it. Check again (look
internally as well) before proceeding.

-rob


On Tue, Feb 28, 2017 at 8:53 AM, Sam Whited  wrote:

> On Tue, Feb 28, 2017 at 1:04 AM, Rob Pike  wrote:
> > For a single object, not a struct, it still gets sent as a struct with
> one
> > field. The 0 is the marker after the last (only) field is sent.
>
> Thanks; that makes sense. So it fits in the grammar description by
> virtue of being part of "encoding of a value", but I don't see
> anywhere that actually says that values are always encoded as structs.
> This might be a good place to improve the documentation a bit. Unless
> someone points me at something obvious I'm missing, I'll file an issue
> to improve the docs, and possibly a CL.
>
> Thanks again.
>
> —Sam
>

-- 
You received this message because you 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] Extra bytes in Gob format

[Sam Whited]

On Tue, Feb 28, 2017 at 1:04 AM, Rob Pike  wrote:
> For a single object, not a struct, it still gets sent as a struct with one
> field. The 0 is the marker after the last (only) field is sent.

Thanks; that makes sense. So it fits in the grammar description by
virtue of being part of "encoding of a value", but I don't see
anywhere that actually says that values are always encoded as structs.
This might be a good place to improve the documentation a bit. Unless
someone points me at something obvious I'm missing, I'll file an issue
to improve the docs, and possibly a CL.

Thanks again.

—Sam

-- 
You received this message because you 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: Some best practices for debuging and optimizing with -gcflags?

['David Chase' via golang-nuts]

Goal "best" practice is that there is no need to tinker with -gcflags, and
this is already true for optimization.

In practice -gcflags -N tends to make the generated code easier to debug,
but that is a sort of a bug that we're trying to fix by improving the 
compiler's
Dwarf generation skills.

On Monday, February 27, 2017 at 7:17:39 PM UTC-5, jamalsm...@gmail.com 
wrote:
>
> What are some best practices for general purpose -gcflags to use for 
> debugging and conversely for optimizing code?
>

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

Re: [go-nuts] Why is Go Unicode concat so slow compared to Python3 ?

[Shubha Ramani]

Ian you nailed it too - thanks for your advice about micro-benchmarks. I
will fix them per your suggestion.

On Tue, Feb 28, 2017 at 7:41 AM, Shubha Ramani 
wrote:

> Dan thank you so much. Indeed you solved it and thanks for your advice
> about the micro-benchmarks
> too.
>
> Sincerely,
>
> Shubha
>
> On Mon, Feb 27, 2017 at 7:25 PM, Dan Kortschak <
> dan.kortsc...@adelaide.edu.au> wrote:
>
>> When the python functions are actually called the comparison is more
>> reasonable:
>>
>> ```
>> ~/concat $ go test -bench . concat_test.go
>> BenchmarkUnicodeConcat-8  20 10379 ns/op
>> PASS
>> ok  command-line-arguments  2.193s
>> ~/concat $ python concat_test.py
>> time_taken = 8901.3030529 nsec
>>
>> ~/concat $ python3 concat_test.py
>> time_taken = 7210.201049922034 nsec
>> ```
>>
>> This involved appending "; concat()" and "; mysetup()" to the stmt and
>> setup parameters.
>>
>> On Mon, 2017-02-27 at 19:03 -0800, Ian Lance Taylor wrote:
>> > On Mon, Feb 27, 2017 at 6:40 PM, Shubha Ramani > > m> wrote:
>> > >
>> > > mysetup is being called here:
>> > >
>> > > times = timeit.Timer(stmt="from __main__ import
>> > > concat",setup="gc.enable();from __main__ import
>> > > mysetup").repeat(7,loops)
>> > >
>> > > Look at "from __main__ import mysetup" after gc.enable();
>> > > gc,enable()
>> > > according to timeit rules needs to be called
>> > > before the setup function. Are you saying Ian that I only import
>> > > but never
>> > > call mysetup() ? Perhaps you are right but I followed examples and
>> > > this is
>> > > what I thought was correct (maybe not).
>> > I added print statements to the Python functions and they never
>> > printed.  I don't know whether that proves anything or not.
>> >
>> > Your micro-benchmarks are suspicious because they don't exist.  It
>> > would take very little for the compiler to simply discard all the
>> > computation.  I'm actually surprised that does not happen with the Go
>> > compiler--seems like a minor bug.  I wonder whether the Python
>> > interpreter is doing that one way or another.
>> >
>> > You should always write a micro-benchmark to compute a real result
>> > and
>> > verify that the result is what you expect.  Otherwise a clever
>> > compiler will completely defeat the purpose of the benchmark.
>> >
>> > Ian
>> >
>>
>
>

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

Re: [go-nuts] Why is Go Unicode concat so slow compared to Python3 ?

[Shubha Ramani]

Dan thank you so much. Indeed you solved it and thanks for your advice
about the micro-benchmarks
too.

Sincerely,

Shubha

On Mon, Feb 27, 2017 at 7:25 PM, Dan Kortschak <
dan.kortsc...@adelaide.edu.au> wrote:

> When the python functions are actually called the comparison is more
> reasonable:
>
> ```
> ~/concat $ go test -bench . concat_test.go
> BenchmarkUnicodeConcat-8  20 10379 ns/op
> PASS
> ok  command-line-arguments  2.193s
> ~/concat $ python concat_test.py
> time_taken = 8901.3030529 nsec
>
> ~/concat $ python3 concat_test.py
> time_taken = 7210.201049922034 nsec
> ```
>
> This involved appending "; concat()" and "; mysetup()" to the stmt and
> setup parameters.
>
> On Mon, 2017-02-27 at 19:03 -0800, Ian Lance Taylor wrote:
> > On Mon, Feb 27, 2017 at 6:40 PM, Shubha Ramani  > m> wrote:
> > >
> > > mysetup is being called here:
> > >
> > > times = timeit.Timer(stmt="from __main__ import
> > > concat",setup="gc.enable();from __main__ import
> > > mysetup").repeat(7,loops)
> > >
> > > Look at "from __main__ import mysetup" after gc.enable();
> > > gc,enable()
> > > according to timeit rules needs to be called
> > > before the setup function. Are you saying Ian that I only import
> > > but never
> > > call mysetup() ? Perhaps you are right but I followed examples and
> > > this is
> > > what I thought was correct (maybe not).
> > I added print statements to the Python functions and they never
> > printed.  I don't know whether that proves anything or not.
> >
> > Your micro-benchmarks are suspicious because they don't exist.  It
> > would take very little for the compiler to simply discard all the
> > computation.  I'm actually surprised that does not happen with the Go
> > compiler--seems like a minor bug.  I wonder whether the Python
> > interpreter is doing that one way or another.
> >
> > You should always write a micro-benchmark to compute a real result
> > and
> > verify that the result is what you expect.  Otherwise a clever
> > compiler will completely defeat the purpose of the benchmark.
> >
> > Ian
> >
>

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

[go-nuts] Re: units disappear from duration at 0.

[peterGo]

You are replying to a message from over a year ago. You should review all 
that has happened since then. For example,

https://go-review.googlesource.com/#/c/22357/

https://github.com/golang/go/issues/14058

Things have changed.

Peter

On Tuesday, February 28, 2017 at 9:29:15 AM UTC-5, andyxning wrote:
>
> This should be good enough to justify what is a zero duration.
>
> 在 2016年1月21日星期四 UTC+8下午12:57:26，peterGo写道：
>>
>> Simon,
>>
>> By design, the Go answer to problems like this is often a simple 
>> function. For example,
>>
>> package main
>>
>> import (
>> "fmt"
>> "time"
>> )
>>
>> type DurationZero struct{ time.Duration }
>>
>> func (d DurationZero) String() string {
>> if d.Duration == 0 {
>> return "0s"
>> }
>> return fmt.Sprint(d.Duration)
>> }
>>
>> func main() {
>> var d time.Duration
>> fmt.Println(DurationZero{d})
>> d = 7 * time.Second
>> fmt.Println(DurationZero{d})
>> d = 42 * time.Nanosecond
>> fmt.Println(DurationZero{d})
>> }
>>
>> Output:
>>
>> 0s
>> 7s
>> 42ns
>>
>>
>> https://play.golang.org/p/p9Av-oYMaE
>>
>> Peter
>>
>> On Wednesday, January 20, 2016 at 7:09:35 PM UTC-5, simon place wrote:
>>>
>>> see;  http://play.golang.org/p/NQy0qmjEX3
>>>
>>>
>>>

-- 
You received this message because you 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: units disappear from duration at 0.

[andyxning]

This should be good enough to justify what is a zero duration.

在 2016年1月21日星期四 UTC+8下午12:57:26，peterGo写道：
>
> Simon,
>
> By design, the Go answer to problems like this is often a simple function. 
> For example,
>
> package main
>
> import (
> "fmt"
> "time"
> )
>
> type DurationZero struct{ time.Duration }
>
> func (d DurationZero) String() string {
> if d.Duration == 0 {
> return "0s"
> }
> return fmt.Sprint(d.Duration)
> }
>
> func main() {
> var d time.Duration
> fmt.Println(DurationZero{d})
> d = 7 * time.Second
> fmt.Println(DurationZero{d})
> d = 42 * time.Nanosecond
> fmt.Println(DurationZero{d})
> }
>
> Output:
>
> 0s
> 7s
> 42ns
>
>
> https://play.golang.org/p/p9Av-oYMaE
>
> Peter
>
> On Wednesday, January 20, 2016 at 7:09:35 PM UTC-5, simon place wrote:
>>
>> see;  http://play.golang.org/p/NQy0qmjEX3
>>
>>
>>

-- 
You received this message because you 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: File organization in a github-ed Go project

[Diego Medina]

Note that if you write a project that other users would use, you will force 
them to update their $GOPATH to make your app work.
Which I think it a lot worse than making people who fork your project 
update the import path And like someone else said, if I need to fork a 
project, I most likely already vendor the dependency, so I simply make 
small changes to the file(s) in the vendor folder

Thanks

Diego



On Tuesday, February 28, 2017 at 5:24:28 AM UTC-5, Basile Starynkevitch 
wrote:
>
>
>
> On Monday, February 27, 2017 at 3:18:18 PM UTC+1, Basile Starynkevitch 
> wrote:
>>
>>
>>
>> On Monday, February 27, 2017 at 3:02:24 PM UTC+1, C Banning wrote:
>>>
>>> Try organizing your project as:
>>>
>>> monimelt
>>>
>>> src
>>>
>>> cmd (or "monimelt", if there's just one app)
>>>
>>> objvalmo
>>>
>>> serial 
>>>
>>>  
>>>
>>>  Then include $HOME/monimelt in your GOPATH.
>>>

  
>> Thanks for the suggestion.
>>
>> BTW, I did commit in bbc5c3789788 
>> 
>>  
>> the change of using directory names same as package names. So I have 
>> monimelt/objvalmo/objvalmo.go 
>>  
>> & monimelt/serialmo/serialmo.go 
>>  
>> files (implementing packages objvalmo & serialmo respectively)
>>
>> But does that avoid me to have to use long paths in import directives? 
>> Would that allow me to code import "serialmo" instead of import "
>> github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease 
>> the forking of my github project)?
>>
>> Regards
>>
>> -- 
>> Basile Starynkevitch 
>>
>>
> Actually I did that (adding $HOME/monimelt to my GOPATH)  and now I am 
> simply importing "serialmo"
>
> BTW, I am beginning to believe that I could drop the go tool and use gb 
> build tool  instead.
>

-- 
You received this message because you 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: Serve large files

[Tamás Gulácsi]

A  "defer streamPDFbytes.Close()" is missing - you'll run out of file 
descriptors...

-- 
You received this message because you 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: Serve large files

[Christian Joergensen]

Hello,

I'd recommend you take a look at:
https://godoc.org/net/http#ServeFile

This also gives you support for range requests and other goodies.

Cheers,

Christian

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

Re: [go-nuts] Re: Serve large files

[Jesse McNelis]

Try using os.Open to get a *File (which implements io.Reader), and then
> io.Copy to the response from the file.
>

You should use https://golang.org/pkg/net/http/#ServeFile that's what it
does. It will also handle requests with range headers for allowing the
client to fetch just a part of the 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Serve large files

[Jordan Krage]

Try using os.Open to get a *File (which implements io.Reader), and then 
io.Copy to the response from the file.

On Tuesday, February 28, 2017 at 5:13:20 AM UTC-6, Jeffrey Smith wrote:
>
> I'm trying to server up a file that can be very large so would like to try 
> and stream the content back.
>
> package main
>
> import (
> "bytes"
> "fmt"
> //"io"
> "io/ioutil"
> "log"
> "net/http"
> )
>
> func main() {
>
> http.HandleFunc("/", serverFile)
> if err := http.ListenAndServe(":8085", nil); err != nil {
> log.Fatal(err)
> }
>
> }
>
> func serverFile(w http.ResponseWriter, r *http.Request) {
>
> streamPDFbytes, err := ioutil.ReadFile("./large.txt")
> if err != nil {
> fmt.Println(err)
> return
> }
>
> b := bytes.NewBuffer(streamPDFbytes)
>
> w.Header().Set("Content-Disposition", 
> "attachment;filename=large.txt")
> //io.Copy(w, b)
> if _, err := b.WriteTo(w); err != nil {
> fmt.Fprintf(w, "%s", err)
> }
> }
>
> I tried using this but I believe ioutil.readFile actually calls 
> ioutil.readAll so sticks the whole content of the file into a byte array. 
> What am i doing wrong?
>

-- 
You received this message because you 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] Serve large files

[Jeffrey Smith]

I'm trying to server up a file that can be very large so would like to try 
and stream the content back.

package main

import (
"bytes"
"fmt"
//"io"
"io/ioutil"
"log"
"net/http"
)

func main() {

http.HandleFunc("/", serverFile)
if err := http.ListenAndServe(":8085", nil); err != nil {
log.Fatal(err)
}

}

func serverFile(w http.ResponseWriter, r *http.Request) {

streamPDFbytes, err := ioutil.ReadFile("./large.txt")
if err != nil {
fmt.Println(err)
return
}

b := bytes.NewBuffer(streamPDFbytes)

w.Header().Set("Content-Disposition", 
"attachment;filename=large.txt")
//io.Copy(w, b)
if _, err := b.WriteTo(w); err != nil {
fmt.Fprintf(w, "%s", err)
}
}

I tried using this but I believe ioutil.readFile actually calls 
ioutil.readAll so sticks the whole content of the file into a byte array. 
What am i doing wrong?

-- 
You received this message because you 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: File organization in a github-ed Go project

[Basile Starynkevitch]

On Monday, February 27, 2017 at 3:18:18 PM UTC+1, Basile Starynkevitch 
wrote:
>
>
>
> On Monday, February 27, 2017 at 3:02:24 PM UTC+1, C Banning wrote:
>>
>> Try organizing your project as:
>>
>> monimelt
>>
>> src
>>
>> cmd (or "monimelt", if there's just one app)
>>
>> objvalmo
>>
>> serial 
>>
>>  
>>
>>  Then include $HOME/monimelt in your GOPATH.
>>
>>>
>>>  
> Thanks for the suggestion.
>
> BTW, I did commit in bbc5c3789788 
> 
>  
> the change of using directory names same as package names. So I have 
> monimelt/objvalmo/objvalmo.go 
>  & 
> monimelt/serialmo/serialmo.go 
>  
> files (implementing packages objvalmo & serialmo respectively)
>
> But does that avoid me to have to use long paths in import directives? 
> Would that allow me to code import "serialmo" instead of import "
> github.com/bstarynk/monimelt/serialmo" in my file objvalmo.go (to ease 
> the forking of my github project)?
>
> Regards
>
> -- 
> Basile Starynkevitch 
>
>
Actually I did that (adding $HOME/monimelt to my GOPATH)  and now I am 
simply importing "serialmo"

BTW, I am beginning to believe that I could drop the go tool and use gb 
build tool  instead.

-- 
You received this message because you 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: correct way to convert wchar_t* to string ?

[Mark]

That works perfectly - thanks!

On Tuesday, February 28, 2017 at 1:51:49 AM UTC, brainman wrote:
>
> I would just use syscall.UTF16ToString: 
> https://play.golang.org/p/jGmQXHtoRT
>
> 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] How to prevent net/http from canonicalizing request paths?

[tsuna]

Hi there,
the code in
https://github.com/golang/go/blob/go1.8/src/net/http/server.go#L2197 is
canonicalizing the request paths such that if you get /foo//bar you get a
301 redirect to /foo/bar.

While this is generally what you want, I am dealing with an unfortunate
case where /foo//bar and /foo/bar are not the same resource (and lot’s not
argue about why) and I couldn’t find an easy way to circumvent this
behavior without completely replacing the ServeMux.  Am I missing something
and there is a better way?

I should specify also that my handler is just for the prefix /foo and that
I cannot explicitly register a handler for each possible path where this
problem exists under /foo.

-- 
Benoit "tsuna" Sigoure

-- 
You received this message because you 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.