Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?

[Wojciech S. Czarnecki]

On Wed, 14 Aug 2019 19:12:40 -0700 (PDT)
sp55aa@gmail.com wrote:
> What is the reason behind time.Parse using a reference time?

The rationale is that every position of the reference time can be
treated as an enum (of int) stating the exact meaning of the field:

01/02 03:04:05PM '06 -0700
1 2 3 4 5 6 7 :  M D h m s year zone/offset

You then use these enums to tell the parser where in *your* date/time
format to parse these fields are. These are accompanied by words of
"Mon"/"Monday" "Jan"/"January" to show parser that format use names.

Eg.  you may need the "06/01" ("year's last two digit / month") format to
extract dates off some monthly financial reports.
In other place you will use "__2/06" ("day-of-year/year") to parse
daily sales reports.

Read https://golang.org/pkg/time/#pkg-constants till it clicks in :)

This is as simple and brilliant as many other things in Go.
Just the docs are somewhat terse.

> I think "2006-01-02 15:04" is a good idea, but have bad practice.
> you cannot understand this code directly. then it is easy to write wrong 
> code like: time.Parse("1970-01-01 00:00", "2011-01-19 22:15")

With format placeholders other languages use code is less readable
until you memorize all of mnemonics. [ man date, look what %_I does mean].
In Go you need only to remember that month is a first member of
"month, day, hour, minutes, seconds, year, zone" sequence and you
can read/understand any of hundreds being in use date formats.

Hope this helps,

-- 
Wojciech S. Czarnecki
 << ^oo^ >> OHIR-RIPE

-- 
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/20190815144747.65f16214%40zuzia.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

['Axel Wagner' via golang-nuts]

On Thu, Aug 15, 2019 at 11:14 AM Jochen Voss  wrote:

> You are right.  But the type is somehow represented by some index or so,
> instead of the name? Since the type needs to be registered using
> gob.Register() beforehand, this seems not totally impossible to me.
>

`Register` only gets the type-name though. It somehow would have to
reproducibly map from type-names to indices and back for this to work - the
process doing the *decoding* isn't necessarily the same process doing the
encoding (that's kind of the point :) ). So AIUI, the name still needs to
be present. The documentation
 says so too:

Interface values are transmitted as a string identifying the concrete type
> being sent (a name that must be pre-defined by calling Register), followed
> by a byte count of the length of the following data (so the value can be
> skipped if it cannot be stored), followed by the usual encoding of concrete
> (dynamic) value stored in the interface value. (A nil interface value is
> identified by the empty string and transmits no value.) Upon receipt, the
> decoder verifies that the unpacked concrete item satisfies the interface of
> the receiving variable.


I wish I could help more :) I'd be interested to see how you get this
resolved though (and maybe someone who used gob more can chime in). AIUI it
*should* be possible to do what you want, so once we figured out how, it
would probably be super helpful to contribute it as a runnable example.

  But then, when I change your code to let gob do the encoding itself, the
> name is suddenly there: https://play.golang.org/p/Qz7zDKL047z, so
> probably the absence of the type name is part of the problem.
>

>
>> And I agree that this probably shouldn't panic, but instead return an
>> error. But given that the encoded bytes don't contain the name of the
>> concrete struct, there is no way the decoder can know where you want to put
>> it, without giving it the correct type.
>>
>
> Yes, an informative error instead of the hard to interpret panic would be
> nice.  I wonder whether this is indeed intended behaviour, or whether this
> is some kind of bug in the encoding/gob package.
>
> --
> 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/32c27653-c50b-42cd-a525-8c9e9298bf60%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/CAEkBMfF9nv70UpS4VF8imVDpSANBpeP4Z_tkkiTECje7d8f16Q%40mail.gmail.com.

[go-nuts] Re: Open Source audit of go package dependencies for security vulnerabilities?

[Chris Hines]

Have you seen: https://github.com/sonatype-nexus-community/nancy

"A tool to check for vulnerabilities in your Golang dependencies, powered 
by Sonatype OSS Index"


On Wednesday, August 14, 2019 at 1:02:03 AM UTC-4, Eric Johnson wrote:
>
> And then, it also occurs to me that perhaps I can answer my own question. 
> Taking advantage of three aspects of the ecosystem.
>
> #1) Most open source Go libraries are on GitHub
> #2) Many (most?) CVEs for open source projects will include a reference 
> back to the project, and these references can be extracted from the 
> cvelist  project.
> #3) GitHub has an API to fetch the language of a GitHub repository.
>
> Putting those three together, it might be possible to filter every CVE 
> entry that has a reference to GitHub, then every GitHub project in that 
> list that is implemented in Go, and turn that into a list of 
> vulnerabilities for packages. Then match on those packages. That might 
> generate a short list of projects that have had vulnerabilities. That far 
> more reasonable list could then be augmented by a small amount of open 
> source labor to annotate with the versions known to be vulnerable, when new 
> items appear.
>
> From a completely different direction, the CVE quality team is looking to 
> add more data to CVE entries. Seems like implementation language + package 
> management name as additional data in the CVE record itself might also help 
> address the issue. That would be generalizable to Java, Javascript. Rust, 
> Python, and Go, for starters.
>
> Before I send that idea in to the quality WG, does anyone here have a 
> better suggestion?
>
> Eric
>
> On Tuesday, August 13, 2019 at 9:50:19 PM UTC-7, Eric Johnson wrote:
>>
>> It would be great to hear of an answer to this question. I suspect there 
>> isn't one, though.
>>
>> The trouble is, one of the first hurdles is to identify Go libraries that 
>> have CVEs against them. It is very easy to find CVEs for the Go standard 
>> library, but I cannot see any easy way to scan the vulnerability databases 
>> for vulnerable projects that happen to be implemented in Go.
>>
>> On top of that, for the purposes of dependency scanning, we really only 
>> need to care about those projects implemented in Go that have non-main 
>> packages. The main packages may have vulnerabilities, but those will never 
>> show up in a dependency scan...
>>
>> If one can identify that list, then the open source tool to find any 
>> dependent libraries that might have vulnerabilities would be pretty 
>> straightforward.
>>
>> Unfortunately, identifying that list is might be really hard. Currently 
>> probably only possible for companies that have a business model that 
>> supports paying people to investigate each and every one of the 
>> vulnerabilities that shows up with a CVE
>>
>> Maybe someone on this list can think of a great way to filter the CVE 
>> list
>>
>> Eric.
>>
>> On Tuesday, August 13, 2019 at 2:32:55 AM UTC-7, Steve Mynott wrote:
>>>
>>> I've been introduced to https://rubysec.com/ which has a database 
>>> which easily integrates with builds to check for known security 
>>> vulnerabilities in third party libraries and was wondering whether 
>>> anything similar exists for go packages? 
>>>
>>> A quick search finds https://snyk.io/vuln?type=golang which appears 
>>> similar but is basically a pay service based on node.js. 
>>>
>>> Also https://www.owasp.org/index.php/OWASP_Dependency_Track_Project 
>>> looks interesting but doesn't include go. 
>>>
>>> Does such an open source version exist for go which is written in go 
>>> and integrates easily with builds? 
>>>
>>> -- 
>>> Steve Mynott  
>>> cv25519/ECF8B611205B447E091246AF959E3D6197190DD5 
>>>
>>

-- 
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/ecc1f0e7-b371-46b7-bb88-9ab518120332%40googlegroups.com.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

['Axel Wagner' via golang-nuts]

I haven't really used gob much, so unfortunately I can't *really* help you.
But one thing to note is that you can dump the content of the buffer and
see that it doesn't actually contain the name of the type you are encoding:
https://play.golang.org/p/R8HB6RP8kS0
I agree that from the documentation, it seems to me that it *should* and I
can't really see what this is doing wrong. And I agree that this probably
shouldn't panic, but instead return an error. But given that the encoded
bytes don't contain the name of the concrete struct, there is no way the
decoder can know where you want to put it, without giving it the correct
type.

On Thu, Aug 15, 2019 at 9:22 AM Jochen Voss  wrote:

> Dear Marcin,
>
> My aim is to unmarshal into an interface variable, without having to know
> in advance which concrete type I'm receiving (the actual interface has
> several possible implementations, and gob data comes in over a network
> connection). So, while your code avoids the panic, it does not solve my
> problem.
>
> Many thanks,
> Jochen
>
> On Wednesday, 14 August 2019 22:12:54 UTC+1, Marcin Romaszewicz wrote:
>>
>> Here you go:
>> https://play.golang.org/p/_cPmaSxRatC
>>
>> You want to unmarshal into , not into 
>>
>> This means:
>> var duck2 A
>>
>> not:
>> var duck2 Duck
>>
>> On Wed, Aug 14, 2019 at 8:46 AM Jochen Voss  wrote:
>>
>>> Hello,
>>>
>>> I'm trying to read gob-encoded data into a variable of interface type.
>>> In simple cases, this works for me, but when I use a custom encoding
>>> via MarshalBinary() and UnmarshalBinary() methods, my code keeps crashing,
>>> with the error message
>>>
>>> panic: interface conversion: interface is nil, not
>>> encoding.BinaryUnmarshaler
>>>
>>> Example:
>>>
>>> - The code at https://play.golang.org/p/y8nWNhObUwb, letting gob do the
>>> en-/decoding works.
>>>
>>> - The very similar code at https://play.golang.org/p/-zS7QjEJg9x, which
>>> uses MarshalBinary() and UnmarshalBinary() crashes with the panic shown
>>> above.
>>>
>>> What am I doing wrong?
>>>
>>> [I asked the same question at
>>> https://stackoverflow.com/questions/57485698/, with no answers so far]
>>>
>>> Many thanks,
>>> Jochen
>>>
>>> --
>>> 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/b19c51bc-524c-4292-915b-fc00e9289052%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/042b28c0-d768-4cba-94cf-159cf4231818%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/CAEkBMfFp567QVvMy4iOmYfuWzQFdbNovNAJXGu%2Bk_%3DcDKm7yBg%40mail.gmail.com.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

['Axel Wagner' via golang-nuts]

Hm, I looked a bit at the code. ISTM that if you implement
BinaryMarshaler/Unmarshaler (or GobEncoder/Decoder), the values are sent as
a []byte, not an interface, so the concrete type information is lost. You
can kind of circumvent this, by instead passing the values as interface{}:
https://play.golang.org/p/n5oxq9g2Q-9 -- As you can see, gob still uses the
methods, but because you more specifically say that it should en/decode
interfaces, it's passing the type-info along too. This will require that
you do your own type-assertions after decoding, but maybe that's acceptable?

The panic, I think, comes from the fact that you pass a *Duck, which then
gets dereferenced, pointing at a nil Duck. Even a nil-Duck *does* have a
DecodeBinary method though, so gob thinks it should use that. It then
type-asserts to BinaryDecoder, which panics, because it's a nil-interface,
just like this example: https://play.golang.org/p/EEwOt0FQunh. Arguably,
the language should allow this (returning nil from the type-assertion), but
either way, it won't help you, because it would panic when calling the
method anyway. So, in a way, gob behaves correctly. It says that if the
value you decode into implements BinaryUnmarshaler, it will call it's
UnmarshalBinary method. And the BinaryUnmarshaler you pass will panic if
you actually call that method. It's still not a great failure mode.

I hope this kinda helps. Or that someone can give a more authoritative
answer :)

On Thu, Aug 15, 2019 at 11:54 AM Axel Wagner 
wrote:

> On Thu, Aug 15, 2019 at 11:14 AM Jochen Voss 
> wrote:
>
>> You are right.  But the type is somehow represented by some index or so,
>> instead of the name? Since the type needs to be registered using
>> gob.Register() beforehand, this seems not totally impossible to me.
>>
>
> `Register` only gets the type-name though. It somehow would have to
> reproducibly map from type-names to indices and back for this to work - the
> process doing the *decoding* isn't necessarily the same process doing the
> encoding (that's kind of the point :) ). So AIUI, the name still needs to
> be present. The documentation
>  says so too:
>
> Interface values are transmitted as a string identifying the concrete type
>> being sent (a name that must be pre-defined by calling Register), followed
>> by a byte count of the length of the following data (so the value can be
>> skipped if it cannot be stored), followed by the usual encoding of concrete
>> (dynamic) value stored in the interface value. (A nil interface value is
>> identified by the empty string and transmits no value.) Upon receipt, the
>> decoder verifies that the unpacked concrete item satisfies the interface of
>> the receiving variable.
>
>
> I wish I could help more :) I'd be interested to see how you get this
> resolved though (and maybe someone who used gob more can chime in). AIUI it
> *should* be possible to do what you want, so once we figured out how, it
> would probably be super helpful to contribute it as a runnable example.
>
>   But then, when I change your code to let gob do the encoding itself, the
>> name is suddenly there: https://play.golang.org/p/Qz7zDKL047z, so
>> probably the absence of the type name is part of the problem.
>>
>
>>
>>> And I agree that this probably shouldn't panic, but instead return an
>>> error. But given that the encoded bytes don't contain the name of the
>>> concrete struct, there is no way the decoder can know where you want to put
>>> it, without giving it the correct type.
>>>
>>
>> Yes, an informative error instead of the hard to interpret panic would be
>> nice.  I wonder whether this is indeed intended behaviour, or whether this
>> is some kind of bug in the encoding/gob package.
>>
>> --
>> 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/32c27653-c50b-42cd-a525-8c9e9298bf60%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/CAEkBMfHDb0dXOJas6otGdv1t8J17fhdHstTdVQZX1iUVc-Hk5g%40mail.gmail.com.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

[Jochen Voss]

Dear Marcin,

My aim is to unmarshal into an interface variable, without having to know 
in advance which concrete type I'm receiving (the actual interface has 
several possible implementations, and gob data comes in over a network 
connection). So, while your code avoids the panic, it does not solve my 
problem.

Many thanks,
Jochen

On Wednesday, 14 August 2019 22:12:54 UTC+1, Marcin Romaszewicz wrote:
>
> Here you go:
> https://play.golang.org/p/_cPmaSxRatC
>
> You want to unmarshal into , not into 
>
> This means:
> var duck2 A
>
> not:
> var duck2 Duck
>
> On Wed, Aug 14, 2019 at 8:46 AM Jochen Voss  > wrote:
>
>> Hello,
>>
>> I'm trying to read gob-encoded data into a variable of interface type.  
>> In simple cases, this works for me, but when I use a custom encoding 
>> via MarshalBinary() and UnmarshalBinary() methods, my code keeps crashing, 
>> with the error message
>>
>> panic: interface conversion: interface is nil, not 
>> encoding.BinaryUnmarshaler
>>
>> Example:
>>
>> - The code at https://play.golang.org/p/y8nWNhObUwb, letting gob do the 
>> en-/decoding works.
>>
>> - The very similar code at https://play.golang.org/p/-zS7QjEJg9x, which 
>> uses MarshalBinary() and UnmarshalBinary() crashes with the panic shown 
>> above.
>>
>> What am I doing wrong?
>>
>> [I asked the same question at 
>> https://stackoverflow.com/questions/57485698/, with no answers so far]
>>
>> Many thanks,
>> Jochen
>>
>> -- 
>> 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/b19c51bc-524c-4292-915b-fc00e9289052%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/042b28c0-d768-4cba-94cf-159cf4231818%40googlegroups.com.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

[Jochen Voss]

Hi Axel,

On Thursday, 15 August 2019 09:13:17 UTC+1, Axel Wagner wrote:
>
> I haven't really used gob much, so unfortunately I can't *really* help 
> you. But one thing to note is that you can dump the content of the buffer 
> and see that it doesn't actually contain the name of the type you are 
> encoding: https://play.golang.org/p/R8HB6RP8kS0
>

You are right.  But the type is somehow represented by some index or so, 
instead of the name?  Since the type needs to be registered using 
gob.Register() beforehand, this seems not totally impossible to me.  But 
then, when I change your code to let gob do the encoding itself, the name 
is suddenly there: https://play.golang.org/p/Qz7zDKL047z, so probably the 
absence of the type name is part of the problem.
 

> And I agree that this probably shouldn't panic, but instead return an 
> error. But given that the encoded bytes don't contain the name of the 
> concrete struct, there is no way the decoder can know where you want to put 
> it, without giving it the correct type.
>

Yes, an informative error instead of the hard to interpret panic would be 
nice.  I wonder whether this is indeed intended behaviour, or whether this 
is some kind of bug in the encoding/gob package.

-- 
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/32c27653-c50b-42cd-a525-8c9e9298bf60%40googlegroups.com.

Re: [go-nuts] panic: interface conversion: interface is nil, not encoding.BinaryUnmarshaler

['Axel Wagner' via golang-nuts]

Please see upthread - gob does that for you.

On Thu, Aug 15, 2019 at 5:59 PM Robert Engels  wrote:

> I think you will need to encode a struct that contains the type name and
> the struct. Then you decode using reflection.
>
> -Original Message-
> From: 'Axel Wagner' via golang-nuts
> Sent: Aug 15, 2019 3:12 AM
> To: Jochen Voss
> Cc: golang-nuts
> Subject: Re: [go-nuts] panic: interface conversion: interface is nil, not
> encoding.BinaryUnmarshaler
>
> I haven't really used gob much, so unfortunately I can't *really* help
> you. But one thing to note is that you can dump the content of the buffer
> and see that it doesn't actually contain the name of the type you are
> encoding: https://play.golang.org/p/R8HB6RP8kS0
> I agree that from the documentation, it seems to me that it *should* and I
> can't really see what this is doing wrong. And I agree that this probably
> shouldn't panic, but instead return an error. But given that the encoded
> bytes don't contain the name of the concrete struct, there is no way the
> decoder can know where you want to put it, without giving it the correct
> type.
>
> On Thu, Aug 15, 2019 at 9:22 AM Jochen Voss  wrote:
>
>> Dear Marcin,
>>
>> My aim is to unmarshal into an interface variable, without having to
>> know in advance which concrete type I'm receiving (the actual interface has
>> several possible implementations, and gob data comes in over a network
>> connection). So, while your code avoids the panic, it does not solve my
>> problem.
>>
>> Many thanks,
>> Jochen
>>
>> On Wednesday, 14 August 2019 22:12:54 UTC+1, Marcin Romaszewicz wrote:
>>>
>>> Here you go:
>>> https://play.golang.org/p/_cPmaSxRatC
>>>
>>> You want to unmarshal into , not into 
>>>
>>> This means:
>>> var duck2 A
>>>
>>> not:
>>> var duck2 Duck
>>>
>>> On Wed, Aug 14, 2019 at 8:46 AM Jochen Voss  wrote:
>>>
 Hello,

 I'm trying to read gob-encoded data into a variable of interface type.
 In simple cases, this works for me, but when I use a custom encoding
 via MarshalBinary() and UnmarshalBinary() methods, my code keeps crashing,
 with the error message

 panic: interface conversion: interface is nil, not
 encoding.BinaryUnmarshaler

 Example:

 - The code at https://play.golang.org/p/y8nWNhObUwb, letting gob do
 the en-/decoding works.

 - The very similar code at https://play.golang.org/p/-zS7QjEJg9x,
 which uses MarshalBinary() and UnmarshalBinary() crashes with the panic
 shown above.

 What am I doing wrong?

 [I asked the same question at
 https://stackoverflow.com/questions/57485698/, with no answers so far]

 Many thanks,
 Jochen

 --
 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/b19c51bc-524c-4292-915b-fc00e9289052%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/042b28c0-d768-4cba-94cf-159cf4231818%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/CAEkBMfFp567QVvMy4iOmYfuWzQFdbNovNAJXGu%2Bk_%3DcDKm7yBg%40mail.gmail.com
> 
> .
>
>
>
>
>

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

[go-nuts] Tips for reproducing flaky Go tests

[mark]

I put together a blog post on reproducing flaky Go tests: 
https://www.influxdata.com/blog/reproducing-a-flaky-test-in-go/

This was the result of what I've learned spending many, many hours hunting 
down many unreliable tests.

I hope these tips can help you out next time you have a test that fails in 
CI but passes locally.

-- 
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/5ec4932c-ec83-4875-857d-8522fe7fdc68%40googlegroups.com.

[go-nuts] Golang project ideas

[kifenraph]

I'm new to go, been working with go for about ten weeks. So far, I've 
worked on a couple of blockchain related projects (decred), and made some 
PRs. But I still feel like I need more to be well grounded in golang. So 
does anyone have any golang real world project ideas? I cannot seem to come 
up with one. I'll appreciate the help...

-- 
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/1fbb7ac9-137e-486f-a1f5-4b6add91828a%40googlegroups.com.

[go-nuts] Re: Distributing task execution

[mfateev]

Look at the Cadence Workflow. It is a very powerful orchestration solution 
including periodic jobs. And it has Go SDK: https://cadenceworkflow.io/

On Friday, August 9, 2019 at 5:39:44 AM UTC-7, Thiru k wrote:
>
> Hi,
> We have used goLang for developing the web based application using micro 
> service pattern. Each and every service will be scale as per demand. here, 
> few of the functionality have to be worked periodically as *cron* , it is 
> easy on the server is just one but if it is scaled then the problem arrives 
> to distribute the task across the replication. Please tell me is there any 
> framework is available to handle this. How to sync and how to split the 
> task among  replications?
>
> Thanks for helping :)
>

-- 
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/573bab69-aaf0-4847-83fb-ba2def534be6%40googlegroups.com.

[go-nuts] Go 1.12.9 is released

[Dmitri Shuralyov]

Hello gophers,

We have just released Go version 1.12.9, a minor point release.

This release includes fixes to the linker, and the os and math/big packages.

View the release notes for more information:
https://golang.org/doc/devel/release.html#go1.12.minor

You can download binary and source distributions from the Go web site:
https://golang.org/dl/

To compile from source using a Git clone, update to the release with
"git checkout go1.12.9" and build as usual.

Thanks to everyone who contributed to the release.

Cheers,
Dmitri for the Go team

-- 
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/CA%2BON-PELTdkKY7FZ7TqrJr21m2o1mBkua_NLwki_xrHm2Kzq7A%40mail.gmail.com.

[go-nuts] golang with XSLT

[p Chak]

Hi,
 I am newbie to golang programming and planning to use xslt. Please let me 
know the best XSLT API for golang.

Thanks
Praveen

-- 
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/04921ea5-037e-48d5-a08e-463aa5d883a8%40googlegroups.com.

Re: [go-nuts] Re: What is the reason behind time.Parse using a reference time?

[Michael Baldry]

I agree with that. It is an odd choice, as I've never seen any other
library use a reference date like that - there may be many but in 20 years,
I've not seen one.

I think your argument about Parse is valid, but in most cases, you'll be
passing in a variable for the date you are parsing and the format will be
in a constant, so you'd be more likely to have something like
time.Parse(myTimeFormat,
request.birthday) or something.

It's useful to remember the reference time has a pattern, but the MST, 12
hour clock and it not being in a common order (day month, then year later)
makes it less obvious, it is essentially: 01/02 03:04:05PM '06 -0700, that
fact is obscured when parsing in common formats.

On Thu, Aug 15, 2019 at 5:28 AM  wrote:

> I think "2006-01-02 15:04" is a good idea, but have bad practice.
> you cannot understand this code directly. then it is easy to write wrong
> code like: time.Parse("1970-01-01 00:00", "2011-01-19 22:15")
>
> On Monday, April 14, 2014 at 9:19:29 PM UTC+8, Jean de Klerk wrote:
>>
>> In java, we do things like new SimpleDateFormat("HH:mm:ss");. In php,
>> something like date_parse_from_format("j.n.Y H:iP", $date) or just
>> strtotime($date). In perl, we create a datetime parser with a pattern that
>> might look like pattern => '%B %d, %Y %I:%M %p %Z'. And so on and so on.
>>
>> However, in go we give it this ambiguous reference time, as in t, err :=
>> time.Parse("2006-01-02 15:04", "2011-01-19 22:15").
>>
>> This seems odd to me. On first glance, I can't tell which is layout and
>> which is string, but we can move around that. Then, when using it, I'm
>> uncertain as to how to change formats without looking it up, I'm uncertain
>> as to whether or not my reference time is supposed to be just random
>> numbers or if I should specify things like 12-hour time vs 24-hour time, or
>> if post-1970 is different than pre-1970, and overall I don't understand the
>> reason why we choose arbitrary numbers instead of the aforementioned
>> conventions of things like Y-M-d.
>>
>> Thanks for any clarification on this. It's very clunky and tricky to use
>> at the moment, but I'm sure I'd understand it more if I more fully
>> understood the rational or what this approach solves that the other does
>> not.
>>
> --
> 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/5d3a4adf-2b4c-4a4f-896e-85206da552a5%40googlegroups.com
> 
> .
>


-- 
Michael



www.brightbits.co.uk

Company number: 08133555
Registered in England
Registered office: 22 Finwell Road, Rainham, Kent, ME8 7PY

-- 
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/CAMQ_qVpHRvq2ukN0964hR64tJoLUNiN4vZLjrg%3DJswb%3D%3D7QK1Q%40mail.gmail.com.

[go-nuts] add guru support refer folder outside gopath

[hui zhang]

"Find All References" does not find code in other packages outside 
GOPATHin vscode

https://github.com/microsoft/vscode-go/issues/2236
https://github.com/Microsoft/vscode-go/issues/1602
https://github.com/Microsoft/vscode-go/issues/1473

the root cause is that guru did not support that.
as guru is part of the official tool. 
pls add feature,  
guru support refer folder outside gopath.
the folder could be project root path


-- 
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/dbb85d34-2b09-4727-b007-ac469bb5819b%40googlegroups.com.