Re: [go-nuts] Use of NoMethod type for custom marshaling

[Sathish VJ]

Yes, that makes sense.  Thank you.

The example I wrote was concocted.  But I've seen others do it on their own 
types too, which didn't make sense at all.  Maybe they were just 
copy-pasting similar code from elsewhere.

On Saturday, 14 September 2019 20:20:49 UTC+5:30, Ben Burwell wrote:
>
> On Sat Sep 14, 2019 at 1:43 AM Sathish VJ wrote: 
> > I saw some code where there is a temporary type called *noMethod* 
> created 
> > before performing custom marshaling. 
> > 
> > What is the purpose of doing this? 
> > 
> > type T struct { 
> >  A int 
> >  C string 
> > } 
> > 
> > func (t T) MarshalJSON() (text []byte, err error) { 
> >  type noMethod T 
> >  return json.Marshal(noMethod(t)) 
> > } 
> > 
> > https://play.golang.org/p/e8cZfkU1uvE 
>
> When json.Marshal is called, if the value passed implements 
> json.Marshaler, then that method is called to marshal the value. 
>
> If you wrote 
>
> func (t T) MarshalJSON() (text []byte, err error) { 
> return json.Marshal(t) 
> } 
>
> func main() { 
> var t T 
> json.Marshal(t) 
> } 
>
> then you'd end up with infinite recursion, as the T.MarshalJSON() method 
> would just keep getting called. By defining `type noMethod T` and 
> casting t to a noMethod before calling json.Marshal, you can avoid this 
> because the noMethod type has, well, no methods, and thus does not 
> implement json.Marshaler and will be encoded using the struct encoder. 
>
> In this case, you may as well just not implement json.Marshaler at all 
> and fall through immediately to the struct encoder, but perhaps there's 
> some reason to do this that your example doesn't show. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/aeea2f49-58e1-42d8-806a-56cdf899c70c%40googlegroups.com.

[go-nuts] regarding regex package

[Doug Clark]

There’s a pure Go (no cgo needed) regexp engine that supports lookahead and 
lookbehind here: https://github.com/dlclark/regexp2

However, and I say this as someone who maintains that regex library, use this 
type of regex with caution.  I would highly recommend changing your code to use 
the native, RE2-based engine if you can. Runaway regex’s on certain inputs is a 
risk with backtracking and is frequently a bad trade off in production.  

If you need compatibility because you don’t control the patterns being used or 
are porting code with lots of existing patterns (which is why the library 
exists) then regexp2 is nice to have in your back pocket. 

-Doug

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

Re: [go-nuts] regarding regex package

[Ian Lance Taylor]

On Sat, Sep 14, 2019 at 12:40 AM Durga Someswararao G
 wrote:
>
> I tried to execute one regular expression with regex package. When I try to 
> compile I am getting unsupported Perl syntax. After reading regex syntax 
> conclusion is golang not supporting some combination regex patterns like 
> positive lookahed,negative lookahed etc. Is there any alternative or anyway 
> to handle this in golang.
>
> Regex Syntax: https://github.com/google/re2/wiki/Syntax
> Sample Code: https://play.golang.org/p/SwODqNNJtBN

Not supporting all of Perl's regexp features is an intentional
decision.  See the discussion at
https://swtch.com/~rsc/regexp/regexp1.html.

When I search for "golang pcre" I see several Go packages that support
Perl regular expressions, mostly by calling out to a PCRE library
written in 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcWb%3Dm%2BfkKxmg4zhfJmETmsNwc1GTc5PQ8EkOpq%2BoN_k0Q%40mail.gmail.com.

[go-nuts] Re: go mod dependency hell is real

[ariebrainware]

Update ugorji to v1.7 works for me

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

Re: [go-nuts] Who can explain more on the "upgrade" module version selector?

['Axel Wagner' via golang-nuts]

Can you explain more specifically what you don't understand?
The example seems pretty clear: Say you currently require the latest master
commit (e.g. by using a pseudo-version), which is a couple commits ahead of
the latest released version, then "latest" will select the release, while
"upgrade" will select the current commit.

On Sat, Sep 14, 2019 at 10:35 AM T L  wrote:

> The doc https://golang.org/cmd/go/#hdr-Module_queries says:
>
> The string "upgrade" is like "latest", but if the module is currently
>> required at a later version than the version "latest" would select (for
>> example, a newer pre-release version), "upgrade" will select the later
>> version instead.
>>
>
> But I don't very get it. Who can explain it more to let me understand it
> better?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/6a4ace13-3ad8-4154-846c-e8d5f343b022%40googlegroups.com
> 
> .
>

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

Re: [go-nuts] Use of NoMethod type for custom marshaling

[Ben Burwell]

On Sat Sep 14, 2019 at 1:43 AM Sathish VJ wrote:
> I saw some code where there is a temporary type called *noMethod* created 
> before performing custom marshaling.
> 
> What is the purpose of doing this?
> 
> type T struct {
>  A int
>  C string
> }
> 
> func (t T) MarshalJSON() (text []byte, err error) {
>  type noMethod T
>  return json.Marshal(noMethod(t))
> }
> 
> https://play.golang.org/p/e8cZfkU1uvE 

When json.Marshal is called, if the value passed implements
json.Marshaler, then that method is called to marshal the value.

If you wrote

func (t T) MarshalJSON() (text []byte, err error) {
return json.Marshal(t)
}

func main() {
var t T
json.Marshal(t)
}

then you'd end up with infinite recursion, as the T.MarshalJSON() method
would just keep getting called. By defining `type noMethod T` and
casting t to a noMethod before calling json.Marshal, you can avoid this
because the noMethod type has, well, no methods, and thus does not
implement json.Marshaler and will be encoded using the struct encoder.

In this case, you may as well just not implement json.Marshaler at all
and fall through immediately to the struct encoder, but perhaps there's
some reason to do this that your example doesn't show.

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

[go-nuts] Re: select on slice of channels

[Nate Finch]

You're better off funnelling everything into a single channel.

There's little real difference between reading from one channel that N 
things write to, and reading from N channels that have one writer each.


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

[go-nuts] Re: go mod dependency hell is real

[Manlio Perillo]

On Tuesday, September 10, 2019 at 2:48:25 PM UTC+2, Darko Luketic wrote:
>
> What used to work pre go 1.13 now doesn't work anymore
>
> go mod is one big mess no one needs and complicates everything
> I'm now getting ambiguity. How do I resolve it?
> Nothing compiles anymore
>
>  ✘ darko@wrk  ~/go/src/git.icod.de/dalu/socialthing   master ●✚  go 
> mod tidy
> go: extracting github.com/ugorji/go/codec 
> v0.0.0-20181204163529-d75b2dcb6bc8
> git.icod.de/dalu/socialthing/cmd imports
> github.com/gin-gonic/gin/binding imports
> github.com/ugorji/go/codec: ambiguous import: found 
> github.com/ugorji/go/codec in multiple modules:
> github.com/ugorji/go v1.1.4 (/home/darko/go/pkg/mod/
> github.com/ugorji/go@v1.1.4/codec)
> github.com/ugorji/go/codec v0.0.0-20181204163529-d75b2dcb6bc8 
> (/home/darko/go/pkg/mod/
> github.com/ugorji/go/codec@v0.0.0-20181204163529-d75b2dcb6bc8)
>
>
> What does that even mean?
>

I agree that the error message is too short.
I hope that in a future version, the go compiler will add a long 
description to each error message.

> [...]

Manlio Perillo

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

[go-nuts] Use of NoMethod type for custom marshaling

[Sathish VJ]

I saw some code where there is a temporary type called *noMethod* created 
before performing custom marshaling.

What is the purpose of doing this?  

type T struct {
 A int
 C string
}


func (t T) MarshalText() (text []byte, err error) {
 type noMethod T
 return json.Marshal(noMethod(t))
}


func (t *T) UnmarshalText(text []byte) error {
 type noMethod T
 return json.Unmarshal(text, (*noMethod)(t))
}


func (t T) MarshalJSON() (text []byte, err error) {
 type noMethod T
 return json.Marshal(noMethod(t))
}


func (t *T) UnmarshalJSON(text []byte) error {
 type noMethod T
 return json.Unmarshal(text, (*noMethod)(t))
}





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

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

[go-nuts] Who can explain more on the "upgrade" module version selector?

[T L]

The doc https://golang.org/cmd/go/#hdr-Module_queries says:

The string "upgrade" is like "latest", but if the module is currently 
> required at a later version than the version "latest" would select (for 
> example, a newer pre-release version), "upgrade" will select the later 
> version instead. 
>

But I don't very get it. Who can explain it more to let me understand it 
better?


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

Re: [go-nuts] Re: go mod dependency hell is real

[roger peppe]

On Sat, 14 Sep 2019, 07:32 Antoine Mercadal,  wrote:

> Hey,
>
> Then why is it called mvs? I don't understand what package system would
> give me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.
>

Any time you don't understand why the versions have resolved in a
particular way, I'd recommend looking at the output of `go mod graph`,
which shows all the information used by the MVS algorithm (piping it
through grep to see only the module you're interested in works well).

I've found it invaluable on many occasions.


> I'll read a bit more about it, but you may have decreased my level of go
> module hate by a bit, sir :)
>
> Thanks,
> --
> Antoine Mercadal
>
> On Sep 13, 2019, at 11:05 PM, Jakob Borg  wrote:
>
> On 14 Sep 2019, at 01:52, anto...@aporeto.com wrote:
>
>
> but require 1.2.0 will not work if another dependency requires the same
> package at version 1.1.0 thanks to mvs.
>
> So either I'm wrong and I did not understand mvs, in that case I would
> like to get enlighten, or I got that right and that comforts me in my deep
> hate of mvs.
>
>
> Luckily, you're wrong on this point. MVS means that if you require 1.2.0
> and some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say,
> 1.3.49).
>
> //jb
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/BF3BD86E-47E7-4D85-A25E-EFA2E42C020E%40aporeto.com
> 
> .
>

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

[go-nuts] regarding regex package

[Durga Someswararao G]

Hi,

I tried to execute one regular expression with regex package. When I try to 
compile I am getting unsupported Perl syntax. After reading regex syntax 
conclusion is golang not supporting some combination regex patterns like 
positive lookahed,negative lookahed etc. Is there any alternative or anyway 
to handle this in golang.

Regex Syntax: https://github.com/google/re2/wiki/Syntax
Sample Code: https://play.golang.org/p/SwODqNNJtBN

Thanks,
Durga SomeswaraRao G.

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

Re: [go-nuts] Re: go mod dependency hell is real

[Jakob Borg]

On 14 Sep 2019, at 08:32, Antoine Mercadal  wrote:
> 
> Hey,
> 
> Then why is it called mvs? I don't understand what package system would give 
> me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.
> 
> I'll read a bit more about it, but you may have decreased my level of go 
> module hate by a bit, sir :)

Lacking other constraints, or with the general "major version 1" constraint 
that covers your example, many other package managers would default to the 
latest compatible version at installation time (i.e., 1.3.49). MVS picks the 
oldest compatible version, 1.2.0.

//jb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4E707F06-682F-4014-A3BB-11F62D359AD0%40kastelo.net.

Re: [go-nuts] Re: go mod dependency hell is real

[Chris Broadfoot]

Is this the issue you came across the other day, Jean?

On Fri, Sep 13, 2019, 11:32 PM Antoine Mercadal  wrote:

> Hey,
>
> Then why is it called mvs? I don't understand what package system would
> give me 1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.
>
> I'll read a bit more about it, but you may have decreased my level of go
> module hate by a bit, sir :)
>
> Thanks,
> --
> Antoine Mercadal
>
> On Sep 13, 2019, at 11:05 PM, Jakob Borg  wrote:
>
> On 14 Sep 2019, at 01:52, anto...@aporeto.com wrote:
>
>
> but require 1.2.0 will not work if another dependency requires the same
> package at version 1.1.0 thanks to mvs.
>
> So either I'm wrong and I did not understand mvs, in that case I would
> like to get enlighten, or I got that right and that comforts me in my deep
> hate of mvs.
>
>
> Luckily, you're wrong on this point. MVS means that if you require 1.2.0
> and some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say,
> 1.3.49).
>
> //jb
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/golang-nuts/BF3BD86E-47E7-4D85-A25E-EFA2E42C020E%40aporeto.com
> 
> .
>

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

Re: [go-nuts] Re: go mod dependency hell is real

[Antoine Mercadal]

Hey,

Then why is it called mvs? I don't understand what package system would give me 
1.3.49, if I require 1.2.0 and my dependency requires 1.1.0.

I'll read a bit more about it, but you may have decreased my level of go module 
hate by a bit, sir :)

Thanks,
-- 
Antoine Mercadal

> On Sep 13, 2019, at 11:05 PM, Jakob Borg  wrote:
> 
>> On 14 Sep 2019, at 01:52, anto...@aporeto.com wrote:
>> 
>> but require 1.2.0 will not work if another dependency requires the same 
>> package at version 1.1.0 thanks to mvs.
>> 
>> So either I'm wrong and I did not understand mvs, in that case I would like 
>> to get enlighten, or I got that right and that comforts me in my deep hate 
>> of mvs.
> 
> Luckily, you're wrong on this point. MVS means that if you require 1.2.0 and 
> some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say, 1.3.49).
> 
> //jb

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

Re: [go-nuts] Re: If v2.x.y+incompatible exists, then getting the modules based v3 version will always fail?

[T L]

On Friday, September 13, 2019 at 3:19:55 PM UTC-4, andrey mirtchovski wrote:
>
> are you following the steps outlined below? 
>
> https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher 
>
> in particular, for a v2 (or v3) it states that the go.mod file must be 
> updated: 
>
> > Update the go.mod file to include a /v3 at the end of the module path in 
> the module directive (e.g., module github.com/my/module/v3). 
>
>
Aha, maybe I have read it, but I forgot it. Thanks for pointing the mistake 
I made.

On the other hand, I think output message is not very clear, it is even 
some misleading.
 

>
> On Fri, Sep 13, 2019 at 12:53 PM T L > 
> wrote: 
> > 
> > I really don't get how modules are got. 
> > I create another repo with all versions are module based, but it still 
> fails on getting v2. 
> > 
> > $ go get github.com/go101/mod_versions_b/v2@latest 
> > go: finding github.com/go101/mod_versions_b/v2 v2.1.1 
> > go get github.com/go101/mod_versions_b/v2@latest: module 
> github.com/go101/mod_versions_b@latest (v1.0.0) found, but does not 
> contain package github.com/go101/mod_versions_b/v2 
> > 
> > It looks, the go command found the target version v2.1.1, but it 
> downloads v1.0.0 in the end. 
> > What is the mistake I made in the process? 
> > 
> > 
> > On Friday, September 13, 2019 at 2:22:16 PM UTC-4, T L wrote: 
> >> 
> >> For example, 
> >> 
> >> $ $ go get github.com/go101/mod_versions/v3@latest 
> >> go: finding github.com/go101/mod_versions/v3 v3.1.0 
> >> go get github.com/go101/mod_versions/v3@latest: module 
> github.com/go101/mod_versions@latest (v2.0.0+incompatible) found, but 
> does not contain package github.com/go101/mod_versions/v3 
> >> 
> >> Is it required to remove all v2.x.y+incompatible versions? 
> > 
> > -- 
> > 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 golan...@googlegroups.com . 
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/71315e79-cbb0-4838-9c85-1ec183f7bb3f%40googlegroups.com.
>  
>
>

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

Re: [go-nuts] Re: go mod dependency hell is real

[Jakob Borg]

On 14 Sep 2019, at 01:52, anto...@aporeto.com wrote:

but require 1.2.0 will not work if another dependency requires the same package 
at version 1.1.0 thanks to mvs.

So either I'm wrong and I did not understand mvs, in that case I would like to 
get enlighten, or I got that right and that comforts me in my deep hate of mvs.

Luckily, you're wrong on this point. MVS means that if you require 1.2.0 and 
some dependency requires 1.1.0, you'll both get 1.2.0. (And not, say, 1.3.49).

//jb

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/13683340-0C3E-46EC-B5A7-935D911AF8A4%40kastelo.net.