Re: [go-nuts] Question regarding gob
There is certainly no reason why pointer semantic meaning cannot be
supported in encode/decode tools for Go. It does not seem hard to do, but
there was a choice not to do it. I shared my understanding of the reason,
but that's not a suggestion of difficulty or impossibility.
The most natural implementation uses a map in both the encoder and decoder.
The least memory way uses the existing pointer values as the instance ID. A
refinement uses 2x map memory but is more compressible in the wire format.
encoder:
if next item is a pointer{
is pointer NOT in the map of previously sent pointers?
recursively encode/transmit *pointer and use uintptr(pointer) as its
ID.
send "next thing is a pointer to a T; value is whatever you
(reconstructor) generated for ID uintptr(pointer)"
}
decoder:
opposite of this, where the map has IDs sent and pointers to locally
allocated objects.
That is all it takes. More suave is to have the map not just be a
map[uintptr]struct{} but of map[uintptr]uint64, where the ID is a serial
number counting up. This would be invisible to the decoder, but real
addresses sent as IDs will be big numbers in a 64-bit address space and
take more bits to encode than one byte 0..255, two byte 256..65535, ...
On Tue, Mar 26, 2019 at 3:44 PM Robert Engels wrote:
> Yes, when using pointers and cycles you need to either use ids in the
> encoding or break the cycle by dropping the cyclic fields (for example, a
> simple ‘parent’ field causes an infinite cycle so drop it and make it
> implicit)
>
> On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG
> wrote:
>
> I mean, everything except the things that are not pointers.
>
> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels
> wrote:
>
>> This is not really true. In Java everything is a pointer (reference) and
>> has no problem with the semantics of passing a reference, it is built into
>> the serialization. They may be in fact passed as a pointer (local rpc) or
>> passed as a copy of the object graph, or something in between (custom).
>>
>> There is no reason Go can not achieve use the same paradigm.
>>
>> On Mar 26, 2019, at 11:48 AM, Michael Jones
>> wrote:
>>
>> To be clear here as educators, it is important to point out that
>> exporting / persisting / sending a pointer is an awkward concept.
>>
>> The normal meanings of sending data beyond an executing program have no
>> direct use for the pointer’s literal value; “the thing at location 12345 in
>> the memory of a program that ran last year” is not much help.
>>
>> On the other hand, one might imagine pointers being like file names and
>> then recreate both content and references during reading. The export format
>> could persist all the typed, pointed to values in tables, and then for each
>> pointer variable exported send instead advice like “put the address of the
>> 456th element of the table for type C things in this pointer slot.”
>>
>> A persistent format supporting this way of recreating the semantics of
>> pointers is very much like an archive format (Zip) with support for
>> symbolic links. It is not particularly hard to implement, but it is a
>> “heavyweight” approach. My sense is that the common desire in export tools
>> is high speed and byte efficiency so it is natural that Gob and other
>> mechanisms adopt the “pointers don’t make sense for export” argument.
>>
>> Michael
>>
>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote:
>>
>>>
>>>
>>> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote:
>>>
Thanks for the reply, Sameer.
Being able to directly send go types is a really big plus for me, I
wonder if I really want to use gob, are there any recommended rpc choices?
>>>
>>> Note that gob has at least one significant limitation when encoding Go
>>> types - it doesn't know about pointers - in general it encodes a pointer by
>>> omitting a field. So if you want to send a slice of a pointer type where
>>> some elements can be nil, you're out of luck:
>>> https://play.golang.org/p/ThVUT_M0hjR
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "golang-nuts" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to golang-nuts+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>>
>> *Michael T. jonesmichael.jo...@gmail.com *
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to golang-nuts+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> 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
[go-nuts] Re: wasm output and modules
You can use "-ldflags='-s -w'" to reduce the size, but it is expected that wasm files will be in the order of MBs (see https://golang.org/doc/go1.11#wasm). > So I was wondering if there are tools that parse the .wasm and prune unused pkgs? The size is not due to unused packages being imported, but rather the runtime and scheduling code. See the relnotes above. On Tuesday, 26 March 2019 17:45:08 UTC+5:30, whiteh...@googlemail.com wrote: > > I know that the Go wasm support is still experimental, although it seems > to be working great here! :) but are there any tools for pruning the .wasm > output? I'm only using about 3 pkg imports but end up with a 2.6MB .wasm > file. I've seen the suggestion for using tinygo, but I didnt get that > working here... > > So I was wondering if there are tools that parse the .wasm and prune > unused pkgs? > > Or are there plans to add any pruning to Go core? So far I saw the file > size increase between 1.11 and 1.12... > > Also, from what I've read about wasm so far, there is some support for > modules. Which to me sounds like one wasm module should be able to talk to > another wasm module directly, avoiding the js bridge. Does Go in anyway > support this concept, or have I misunderstood it? > > Thanks, Peter > > macos10.12.4, Go 1.12 > -- 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] net.Conn types: File vs SyscallConn method
On Mon, Mar 25, 2019 at 11:04 AM Matt Layher wrote: > > I've been doing low-level networking work in Go for a few years now, but I > had a realization the other day: > > With the addition of the SyscallConn method in Go 1.9 to several > net.Conn/PacketConn types, what is the advantage of using the File method at > this point in time? > > The documentation (https://golang.org/pkg/net/#IPConn.File) mentions: > > > File returns a copy of the underlying os.File It is the caller's > > responsibility to close f when finished. Closing c does not affect f, and > > closing f does not affect c. > > > > The returned os.File's file descriptor is different from the connection's. > > Attempting to change properties of the original using this duplicate may or > > may not have the desired effect. > > But the syscall.RawConn provides a handle to a non-dup'd file descriptor, > which can be used for dealing with socket options and runtime network > poller-integrated reads/writes. To my knowledge, changing the properties of > the file descriptor passed in syscall.RawConn methods will always have the > desired effect, because it offers direct access to the file descriptor. > > Which leads to my next question: if SyscallConn provides better flexibility, > is it time to add a deprecation notice to the File method on various package > net types, in favor of SyscallConn? > > Perhaps there's some benefit to File that I'm not seeing. If so, I'd be > curious to find out! If you are only calling File so that you can change properties of the descriptor, then I agree that you always use SyscallConn instead. But if you are calling File just to pass a socket to something that expects a *os.File, then it remains useful. I don't think I would call it deprecated, though we could consider removing it if we ever make a net/v2 package. 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] Question regarding gob
Yes, when using pointers and cycles you need to either use ids in the encoding or break the cycle by dropping the cyclic fields (for example, a simple ‘parent’ field causes an infinite cycle so drop it and make it implicit) > On Mar 26, 2019, at 2:27 PM, Thomas Bushnell, BSG > wrote: > > I mean, everything except the things that are not pointers. > >> On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote: >> This is not really true. In Java everything is a pointer (reference) and has >> no problem with the semantics of passing a reference, it is built into the >> serialization. They may be in fact passed as a pointer (local rpc) or passed >> as a copy of the object graph, or something in between (custom). >> >> There is no reason Go can not achieve use the same paradigm. >> >>> On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: >>> >>> To be clear here as educators, it is important to point out that exporting >>> / persisting / sending a pointer is an awkward concept. >>> >>> The normal meanings of sending data beyond an executing program have no >>> direct use for the pointer’s literal value; “the thing at location 12345 in >>> the memory of a program that ran last year” is not much help. >>> >>> On the other hand, one might imagine pointers being like file names and >>> then recreate both content and references during reading. The export format >>> could persist all the typed, pointed to values in tables, and then for each >>> pointer variable exported send instead advice like “put the address of the >>> 456th element of the table for type C things in this pointer slot.” >>> >>> A persistent format supporting this way of recreating the semantics of >>> pointers is very much like an archive format (Zip) with support for >>> symbolic links. It is not particularly hard to implement, but it is a >>> “heavyweight” approach. My sense is that the common desire in export tools >>> is high speed and byte efficiency so it is natural that Gob and other >>> mechanisms adopt the “pointers don’t make sense for export” argument. >>> >>> Michael >>> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > Thanks for the reply, Sameer. > > Being able to directly send go types is a really big plus for me, I > wonder if I really want to use gob, are there any recommended rpc choices? Note that gob has at least one significant limitation when encoding Go types - it doesn't know about pointers - in general it encodes a pointer by omitting a field. So if you want to send a slice of a pointer type where some elements can be nil, you're out of luck: https://play.golang.org/p/ThVUT_M0hjR -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> -- >>> Michael T. Jones >>> michael.jo...@gmail.com >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "golang-nuts" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to golang-nuts+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] rand.Rand.Seed() vs rand.NewSource()
On Tue, Mar 26, 2019 at 11:48 AM Liam Breck wrote: > > Could anyone clarify the difference between these two? > > r := rand.New(rand.NewSource(...)) > > var r rand.Rand; r.Seed(...) Well, it's not a complete program, and maybe I'm missing something, but it seems to me that the difference is that the first one will give you a random number generator and the second one will panic at run time. 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: Generis, yet another Generic go code generator... ;)
Indeed this one is nice too. And quite simple to use compared to several
other solutions :)
I'm always astonished by the incredible number of code generation solutions
that Go developers have implemented to emulate strongly-typed generics in
Go.
In my own case, I've opted for an all-in-one tool which solved all my needs
(genericity, free-form macros, conditional compilation, inline HTML
templating, indentation style, etc) at once, but obviously there are
already many ways to achieve almost the same result by combining several
existing tools :)
On Tuesday, March 26, 2019 at 10:44:19 AM UTC+1, Michał Matczuk wrote:
>
> You may be also interested in https://github.com/mmatczuk/go_generics (the
> credit goes to Google).
>
> With it you can write a generic code that actually compiles and change the
> types later ex.
> https://github.com/scylladb/go-set/tree/master/internal/set
>
> W dniu poniedziałek, 25 marca 2019 15:58:03 UTC+1 użytkownik David Skinner
> napisał:
>>
>> I am very, very, old school, grew up with ASM and Macro Assembly. I
>> really appreciate this.
>>
>> I prefer to write Go code in a purely idiomatic way but there are times i
>> just want to finish the job and ship it.
>>
>> Thank you for sharing.
>>
>> On Sunday, March 24, 2019 at 4:23:52 PM UTC-5, Ecstatic Coder wrote:
>>>
>>> Just to inform you that I've just released an first version of *Generis*,
>>> a lightweight code preprocessor adding the following features to the Go
>>> language :
>>>
>>>- Generic code definition and instantiation.
>>>- Conditional compilation.
>>>- ERB-like HTML templating.
>>>- Allman to K style conversion.
>>>
>>> https://github.com/senselogic/GENERIS
>>>
>>> It's very similar in function to both Ego and Genny, but implemented as
>>> a free-form C++-like preprocessor.
>>>
>>> Probably of no use at all for anyone who likes to develop Go code in a
>>> purely idiomatic way, which obviously I'm not...
>>>
>>>
>>> *Sample*
>>>
>>> package main;
>>> // -- IMPORTS
>>> import (
>>> "html"
>>> "io"
>>> "log"
>>> "net/http"
>>> "strconv"
>>> );
>>> // -- DEFINITIONS
>>>
>>> #define DebugMode
>>> #as true
>>> // ~~
>>>
>>> #define HttpPort
>>> #as 8080
>>> // ~~
>>>
>>> #define WriteLine( {{text}} )
>>> #as log.Println( {{text}} )
>>> // ~~
>>>
>>> #define local {{variable}} : {{type}};
>>> #as var {{variable}} {{type}};
>>> // ~~
>>>
>>> #define DeclareStack( {{type}}, {{name}} )
>>> #as
>>> // -- TYPES
>>>
>>> type {{name}}Stack struct
>>> {
>>> ElementArray []{{type}};
>>> }
>>>
>>> // -- INQUIRIES
>>>
>>> func ( stack * {{name}}Stack ) IsEmpty(
>>> ) bool
>>> {
>>> return len( stack.ElementArray ) == 0;
>>> }
>>>
>>> // -- OPERATIONS
>>>
>>> func ( stack * {{name}}Stack ) Push(
>>> element {{type}}
>>> )
>>> {
>>> stack.ElementArray = append( stack.ElementArray, element );
>>> }
>>>
>>> // ~~
>>>
>>> func ( stack * {{name}}Stack ) Pop(
>>> ) {{type}}
>>> {
>>> local
>>> element : {{type}};
>>>
>>> element = stack.ElementArray[ len( stack.ElementArray ) - 1 ];
>>>
>>> stack.ElementArray = stack.ElementArray[ : len( stack.ElementArray
>>> ) - 1 ];
>>>
>>> return element;
>>> }
>>> #end
>>> // ~~
>>>
>>> #define DeclareStack( {{type}} )
>>> #as DeclareStack( {{type}}, {{type:PascalCase}} )
>>> // -- TYPES
>>> DeclareStack( string )DeclareStack( int32 )
>>> // -- FUNCTIONS
>>> func HandleRootPage(
>>> response_writer http.ResponseWriter,
>>> request * http.Request
>>> )
>>> {
>>> local
>>> boolean : bool;
>>> local
>>> natural : uint;
>>> local
>>> integer : int;
>>> local
>>> real : float64;
>>> local
>>> escaped_text,
>>> text : string;
>>> local
>>> integer_stack : Int32Stack;
>>>
>>> boolean = true;
>>> natural = 10;
>>> integer = 20;
>>> real = 30.0;
>>> text = "text";
>>> escaped_text = "";
>>>
>>> integer_stack.Push( 10 );
>>> integer_stack.Push( 20 );
>>> integer_stack.Push( 30 );
>>>
>>> #write response_writer
>>>
>>>
>>>
>>>
>>> <%= request.URL.Path %>
>>>
>>>
>>> <% if ( boolean ) { %>
>>> <%= "URL : " + request.URL.Path %>
>>>
>>> <%@ natural %>
>>> <%# integer %>
>>> <%& real %>
>>>
>>> <%~ text %>
>>> <%= escaped_text %>
>>> <%= "<%% ignored %%>" %>
>>> <%% ignored %%>
>>> <% } %>
>>>
>>> Stack :
>>>
>>> <% for !integer_stack.IsEmpty() { %>
>>> <%#
Re: [go-nuts] Question regarding gob
I mean, everything except the things that are not pointers. On Tue, Mar 26, 2019 at 2:45 PM Robert Engels wrote: > This is not really true. In Java everything is a pointer (reference) and > has no problem with the semantics of passing a reference, it is built into > the serialization. They may be in fact passed as a pointer (local rpc) or > passed as a copy of the object graph, or something in between (custom). > > There is no reason Go can not achieve use the same paradigm. > > On Mar 26, 2019, at 11:48 AM, Michael Jones > wrote: > > To be clear here as educators, it is important to point out that exporting > / persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and > then recreate both content and references during reading. The export format > could persist all the typed, pointed to values in tables, and then for each > pointer variable exported send instead advice like “put the address of the > 456th element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for > symbolic links. It is not particularly hard to implement, but it is a > “heavyweight” approach. My sense is that the common desire in export tools > is high speed and byte efficiency so it is natural that Gob and other > mechanisms adopt the “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I >>> wonder if I really want to use gob, are there any recommended rpc choices? >>> >> >> Note that gob has at least one significant limitation when encoding Go >> types - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *Michael T. jonesmichael.jo...@gmail.com * > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
On Tue, Mar 26, 2019 at 12:45 PM Robert Engels wrote: > > This is not really true. In Java everything is a pointer (reference) and has > no problem with the semantics of passing a reference, it is built into the > serialization. They may be in fact passed as a pointer (local rpc) or passed > as a copy of the object graph, or something in between (custom). When you deal with pointers during serialization, you have to deal with the potential of cyclic references. I remember getting frustrated during my Java days with things failing when encoded in JSON where they worked just fine with Java serialization because of cyclic references. This is not a language problem, it is more of an encoding problem. > > There is no reason Go can not achieve use the same paradigm. > > On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: > > To be clear here as educators, it is important to point out that exporting / > persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and then > recreate both content and references during reading. The export format could > persist all the typed, pointed to values in tables, and then for each pointer > variable exported send instead advice like “put the address of the 456th > element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for symbolic > links. It is not particularly hard to implement, but it is a “heavyweight” > approach. My sense is that the common desire in export tools is high speed > and byte efficiency so it is natural that Gob and other mechanisms adopt the > “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: >> >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >>> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I wonder >>> if I really want to use gob, are there any recommended rpc choices? >> >> >> Note that gob has at least one significant limitation when encoding Go types >> - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > > -- > Michael T. Jones > michael.jo...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > 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] rand.Rand.Seed() vs rand.NewSource()
Could anyone clarify the difference between these two? r := rand.New(rand.NewSource(...)) var r rand.Rand; r.Seed(...) -- 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] Question regarding gob
This is not really true. In Java everything is a pointer (reference) and has no problem with the semantics of passing a reference, it is built into the serialization. They may be in fact passed as a pointer (local rpc) or passed as a copy of the object graph, or something in between (custom). There is no reason Go can not achieve use the same paradigm. > On Mar 26, 2019, at 11:48 AM, Michael Jones wrote: > > To be clear here as educators, it is important to point out that exporting / > persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and then > recreate both content and references during reading. The export format could > persist all the typed, pointed to values in tables, and then for each pointer > variable exported send instead advice like “put the address of the 456th > element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for symbolic > links. It is not particularly hard to implement, but it is a “heavyweight” > approach. My sense is that the common desire in export tools is high speed > and byte efficiency so it is natural that Gob and other mechanisms adopt the > “pointers don’t make sense for export” argument. > > Michael > >> On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: >> >> >>> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I wonder >>> if I really want to use gob, are there any recommended rpc choices? >> >> Note that gob has at least one significant limitation when encoding Go types >> - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. > -- > Michael T. Jones > michael.jo...@gmail.com > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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: How to use godoc with Go's module?
godoc doesn't work in module mode yet. The workaround is to create a directory resembling a GOPATH and put your project there and set the GOPATH variable to that. Tracking issue here - https://github.com/golang/go/issues/26827 On Tuesday, 26 March 2019 18:07:23 UTC+5:30, Weerasak Chongnguluam wrote: > > I try to use `godoc` to render package's documentation of module. But > `godoc` parsing only packages in `GOPATH`. How to use `godoc` with Go's > module or have alternative tool to render document of Go's module? > -- 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] Question regarding gob
When we think of pointers as what they literally are, an address to a space in memory, it sounds reasonable for Gob to not support them. Things get more unclear when we consider that, in practice, Go programmers often use pointers as a replacement for option types. Without pointers, I don't know how an optional value could be transported using Gob, unless you're willing to add an additional flag to your data structure to indicate if some data is considered present. On Tue, Mar 26, 2019 at 9:48 AM Michael Jones wrote: > To be clear here as educators, it is important to point out that exporting > / persisting / sending a pointer is an awkward concept. > > The normal meanings of sending data beyond an executing program have no > direct use for the pointer’s literal value; “the thing at location 12345 in > the memory of a program that ran last year” is not much help. > > On the other hand, one might imagine pointers being like file names and > then recreate both content and references during reading. The export format > could persist all the typed, pointed to values in tables, and then for each > pointer variable exported send instead advice like “put the address of the > 456th element of the table for type C things in this pointer slot.” > > A persistent format supporting this way of recreating the semantics of > pointers is very much like an archive format (Zip) with support for > symbolic links. It is not particularly hard to implement, but it is a > “heavyweight” approach. My sense is that the common desire in export tools > is high speed and byte efficiency so it is natural that Gob and other > mechanisms adopt the “pointers don’t make sense for export” argument. > > Michael > > On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > >> >> >> On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: >> >>> Thanks for the reply, Sameer. >>> >>> Being able to directly send go types is a really big plus for me, I >>> wonder if I really want to use gob, are there any recommended rpc choices? >>> >> >> Note that gob has at least one significant limitation when encoding Go >> types - it doesn't know about pointers - in general it encodes a pointer by >> omitting a field. So if you want to send a slice of a pointer type where >> some elements can be nil, you're out of luck: >> https://play.golang.org/p/ThVUT_M0hjR >> >> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > -- > > *Michael T. jonesmichael.jo...@gmail.com * > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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] Question regarding gob
To be clear here as educators, it is important to point out that exporting / persisting / sending a pointer is an awkward concept. The normal meanings of sending data beyond an executing program have no direct use for the pointer’s literal value; “the thing at location 12345 in the memory of a program that ran last year” is not much help. On the other hand, one might imagine pointers being like file names and then recreate both content and references during reading. The export format could persist all the typed, pointed to values in tables, and then for each pointer variable exported send instead advice like “put the address of the 456th element of the table for type C things in this pointer slot.” A persistent format supporting this way of recreating the semantics of pointers is very much like an archive format (Zip) with support for symbolic links. It is not particularly hard to implement, but it is a “heavyweight” approach. My sense is that the common desire in export tools is high speed and byte efficiency so it is natural that Gob and other mechanisms adopt the “pointers don’t make sense for export” argument. Michael On Tue, Mar 26, 2019 at 6:01 AM roger peppe wrote: > > > On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > >> Thanks for the reply, Sameer. >> >> Being able to directly send go types is a really big plus for me, I >> wonder if I really want to use gob, are there any recommended rpc choices? >> > > Note that gob has at least one significant limitation when encoding Go > types - it doesn't know about pointers - in general it encodes a pointer by > omitting a field. So if you want to send a slice of a pointer type where > some elements can be nil, you're out of luck: > https://play.golang.org/p/ThVUT_M0hjR > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Michael T. jonesmichael.jo...@gmail.com * -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] Question regarding gob
On Mon, 25 Mar 2019 at 14:45, Glen Huang wrote: > Thanks for the reply, Sameer. > > Being able to directly send go types is a really big plus for me, I wonder > if I really want to use gob, are there any recommended rpc choices? > Note that gob has at least one significant limitation when encoding Go types - it doesn't know about pointers - in general it encodes a pointer by omitting a field. So if you want to send a slice of a pointer type where some elements can be nil, you're out of luck: https://play.golang.org/p/ThVUT_M0hjR -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] How to write bson.M format Golang
On Tue, Mar 26, 2019 at 4:05 AM wrote:
>
> Hi,
>
> Am using mongodb as database. Am able to query the database from the command
> line using the command
>
> db.nfinstances.distinct("ipv4Addresses",{"nfType":"AMF", "amfInfo.amfSetId":
> "3fa85f64-5717-4562-b3fc-2c963f66af33"})
>
> and this give me ipaddress [x.x.x.x] output that i want.
>
> mongo command line Output:
>
>
> > db.nfinstances.distinct("ipv4Addresses",{"nfType":"AMF",
> > "amfInfo.amfSetId": "3fa85f64-5717-4562-b3fc-2c963f66af33"})
>
> [ "198.51.100.300" ]
>
> >
>
>
> However if i query using the golang query
>
> var SliceIP []NfInstance
>
> db.C(COLLECTION).Find("nfType": "AMF", "amfInfo.amfSetId":
> "3fa85f64-5717-4562-b3fc-2c963f66af33").Distinct("ipv4Addresses", )
You need to pass a bson.M query:
db.C(COLLECTION).Find(bson.M{"nfType":AMF","amfinfo.amfSetId":"fa85f64-5717-4562-b3fc-2c963f66af33"})
>
> am getting empy array instead of the the IP address in an array. In the
> database i have the json document as
>
> {
> "nfinstanceID": "3fa85f64-5717-4562-b3fc-2c963f66af33",
> "nfType": [
> "AMF"
> ],
> "nfStatus": [
> "REGISTERED"
> ],
> "sNssais": [
> {
> "sst": 1,
> "sd": "sd1"
> }
> ],
> "nsiList": [
> "string"
> ],
> "ipv4Addresses": [
> "198.51.100.300"
> ],
> "allowedNssais": [
> {
> "sst": 1,
> "sd": "sd1"
> }
> ],
> "amfInfo": {
> "amfSetId": "3fa85f64-5717-4562-b3fc-2c963f66af33",
> "taiList": [
> {
> "plmnId": {
> "mcc": "244",
> "mnc": "38"
> },
> "tac": "string"
> }
> ],
> "n2InterfaceAmfInfo": {
> "ipv4EndpointAddress": [
> "198.51.100.105"
> ]
> }
> }
> }
>
> Can anyone help me find the problem. I may be doing missing something.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [go-nuts] why add the useless function in interface?
On Tue, 26 Mar 2019, at 12:37 PM, XiaoBing Jiang wrote:
> Hi, all:
>
> in src/cmd/compile/internal/syntax/nodes.go, why need the aNode() function in
> the interface?
>
> type Node interface {
> // Pos() returns the position associated with the node as follows:
> // 1) The position of a node representing a terminal syntax production
> // (Name, BasicLit, etc.) is the position of the respective production
> // in the source.
> // 2) The position of a node representing a non-terminal production
> // (IndexExpr, IfStmt, etc.) is the position of a token uniquely
> // associated with that production; usually the left-most one
> // ('[' for IndexExpr, 'if' for IfStmt, etc.)
> Pos() Pos
> aNode()
> }
>
> type node struct {
> // commented out for now since not yet used
> // doc *Comment // nil means no comment(s) attached
> pos Pos
> }
>
> func (n *node) Pos() Pos { return n.pos }
> func (*node) aNode() {}
>
It prevents implementations of the interface outside of that package. The code
can then assume it knows all the possible implementations of Node.
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] How to use godoc with Go's module?
I try to use `godoc` to render package's documentation of module. But `godoc` parsing only packages in `GOPATH`. How to use `godoc` with Go's module or have alternative tool to render document of Go's module? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[go-nuts] why add the useless function in interface?
Hi, all:
in src/cmd/compile/internal/syntax/nodes.go, why need the aNode() function
in the interface?
type Node interface {
// Pos() returns the position associated with the node as follows:
// 1) The position of a node representing a terminal syntax production
//(Name, BasicLit, etc.) is the position of the respective production
//in the source.
// 2) The position of a node representing a non-terminal production
//(IndexExpr, IfStmt, etc.) is the position of a token uniquely
//associated with that production; usually the left-most one
//('[' for IndexExpr, 'if' for IfStmt, etc.)
Pos() Pos
aNode()
}
type node struct {
// commented out for now since not yet used
// doc *Comment // nil means no comment(s) attached
pos Pos
}
func (n *node) Pos() Pos { return n.pos }
func (*node) aNode() {}
Thanks!
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[go-nuts] wasm output and modules
I know that the Go wasm support is still experimental, although it seems to be working great here! :) but are there any tools for pruning the .wasm output? I'm only using about 3 pkg imports but end up with a 2.6MB .wasm file. I've seen the suggestion for using tinygo, but I didnt get that working here... So I was wondering if there are tools that parse the .wasm and prune unused pkgs? Or are there plans to add any pruning to Go core? So far I saw the file size increase between 1.11 and 1.12... Also, from what I've read about wasm so far, there is some support for modules. Which to me sounds like one wasm module should be able to talk to another wasm module directly, avoiding the js bridge. Does Go in anyway support this concept, or have I misunderstood it? Thanks, Peter macos10.12.4, Go 1.12 -- 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 write bson.M format Golang
Hi,
Am using mongodb as database. Am able to query the database from the
command line using the command
db.nfinstances.distinct("ipv4Addresses",{"nfType":"AMF",
"amfInfo.amfSetId": "3fa85f64-5717-4562-b3fc-2c963f66af33"})
and this give me ipaddress [x.x.x.x] output that i want.
mongo command line Output:
*> db.nfinstances.distinct("ipv4Addresses",{"nfType":"AMF",
"amfInfo.amfSetId": "3fa85f64-5717-4562-b3fc-2c963f66af33"})*
*[ "198.51.100.300" ]*
*> *
However if i query using the golang query
var SliceIP []NfInstance
db.C(COLLECTION).Find("nfType": "AMF",
"amfInfo.amfSetId":
"3fa85f64-5717-4562-b3fc-2c963f66af33").Distinct("ipv4Addresses",
)
am getting empy array instead of the the IP address in an array. In the
database i have the json document as
{
"nfinstanceID": "3fa85f64-5717-4562-b3fc-2c963f66af33",
"nfType": [
"AMF"
],
"nfStatus": [
"REGISTERED"
],
"sNssais": [
{
"sst": 1,
"sd": "sd1"
}
],
"nsiList": [
"string"
],
"ipv4Addresses": [
"198.51.100.300"
],
"allowedNssais": [
{
"sst": 1,
"sd": "sd1"
}
],
"amfInfo": {
"amfSetId": "3fa85f64-5717-4562-b3fc-2c963f66af33",
"taiList": [
{
"plmnId": {
"mcc": "244",
"mnc": "38"
},
"tac": "string"
}
],
"n2InterfaceAmfInfo": {
"ipv4EndpointAddress": [
"198.51.100.105"
]
}
}
}
Can anyone help me find the problem. I may be doing missing something.
--
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: Generis, yet another Generic go code generator... ;)
You may be also interested in https://github.com/mmatczuk/go_generics (the
credit goes to Google).
With it you can write a generic code that actually compiles and change the
types later ex. https://github.com/scylladb/go-set/tree/master/internal/set
W dniu poniedziałek, 25 marca 2019 15:58:03 UTC+1 użytkownik David Skinner
napisał:
>
> I am very, very, old school, grew up with ASM and Macro Assembly. I really
> appreciate this.
>
> I prefer to write Go code in a purely idiomatic way but there are times i
> just want to finish the job and ship it.
>
> Thank you for sharing.
>
> On Sunday, March 24, 2019 at 4:23:52 PM UTC-5, Ecstatic Coder wrote:
>>
>> Just to inform you that I've just released an first version of *Generis*,
>> a lightweight code preprocessor adding the following features to the Go
>> language :
>>
>>- Generic code definition and instantiation.
>>- Conditional compilation.
>>- ERB-like HTML templating.
>>- Allman to K style conversion.
>>
>> https://github.com/senselogic/GENERIS
>>
>> It's very similar in function to both Ego and Genny, but implemented as a
>> free-form C++-like preprocessor.
>>
>> Probably of no use at all for anyone who likes to develop Go code in a
>> purely idiomatic way, which obviously I'm not...
>>
>>
>> *Sample*
>>
>> package main;
>> // -- IMPORTS
>> import (
>> "html"
>> "io"
>> "log"
>> "net/http"
>> "strconv"
>> );
>> // -- DEFINITIONS
>>
>> #define DebugMode
>> #as true
>> // ~~
>>
>> #define HttpPort
>> #as 8080
>> // ~~
>>
>> #define WriteLine( {{text}} )
>> #as log.Println( {{text}} )
>> // ~~
>>
>> #define local {{variable}} : {{type}};
>> #as var {{variable}} {{type}};
>> // ~~
>>
>> #define DeclareStack( {{type}}, {{name}} )
>> #as
>> // -- TYPES
>>
>> type {{name}}Stack struct
>> {
>> ElementArray []{{type}};
>> }
>>
>> // -- INQUIRIES
>>
>> func ( stack * {{name}}Stack ) IsEmpty(
>> ) bool
>> {
>> return len( stack.ElementArray ) == 0;
>> }
>>
>> // -- OPERATIONS
>>
>> func ( stack * {{name}}Stack ) Push(
>> element {{type}}
>> )
>> {
>> stack.ElementArray = append( stack.ElementArray, element );
>> }
>>
>> // ~~
>>
>> func ( stack * {{name}}Stack ) Pop(
>> ) {{type}}
>> {
>> local
>> element : {{type}};
>>
>> element = stack.ElementArray[ len( stack.ElementArray ) - 1 ];
>>
>> stack.ElementArray = stack.ElementArray[ : len( stack.ElementArray )
>> - 1 ];
>>
>> return element;
>> }
>> #end
>> // ~~
>>
>> #define DeclareStack( {{type}} )
>> #as DeclareStack( {{type}}, {{type:PascalCase}} )
>> // -- TYPES
>> DeclareStack( string )DeclareStack( int32 )
>> // -- FUNCTIONS
>> func HandleRootPage(
>> response_writer http.ResponseWriter,
>> request * http.Request
>> )
>> {
>> local
>> boolean : bool;
>> local
>> natural : uint;
>> local
>> integer : int;
>> local
>> real : float64;
>> local
>> escaped_text,
>> text : string;
>> local
>> integer_stack : Int32Stack;
>>
>> boolean = true;
>> natural = 10;
>> integer = 20;
>> real = 30.0;
>> text = "text";
>> escaped_text = "";
>>
>> integer_stack.Push( 10 );
>> integer_stack.Push( 20 );
>> integer_stack.Push( 30 );
>>
>> #write response_writer
>>
>>
>>
>>
>> <%= request.URL.Path %>
>>
>>
>> <% if ( boolean ) { %>
>> <%= "URL : " + request.URL.Path %>
>>
>> <%@ natural %>
>> <%# integer %>
>> <%& real %>
>>
>> <%~ text %>
>> <%= escaped_text %>
>> <%= "<%% ignored %%>" %>
>> <%% ignored %%>
>> <% } %>
>>
>> Stack :
>>
>> <% for !integer_stack.IsEmpty() { %>
>> <%# integer_stack.Pop() %>
>> <% } %>
>>
>>
>> #end
>> }
>> // ~~
>> func main()
>> {
>> http.HandleFunc( "/", HandleRootPage );
>>
>> #if DebugMode
>> WriteLine( "Listening on http://localhost:HttpPort; );
>> #end
>>
>> log.Fatal(
>> http.ListenAndServe( ":8080", nil )
>> );
>> }
>>
>>
--
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] Bootstrap CRUD on several tables
Hi there, I'm looking for a tool to help create a RestFUL interface on a MariaDB database with many several tables. There are plenty of tutorials on this topic like that of https://github.com/kelvins/GoApiTutorial [1] however it's _very_ labourious to do this for anything more than a couple of tables. Unless am I missing a trick? https://github.com/topics/rest?l=go came up empty. Thank you in advance! [1] think it could be bettered with https://github.com/jmoiron/sqlx -- 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.
