Re: [go-nuts] How to have panic messages show in a PowerShell console

['Jim Idle' via golang-nuts]

You should upgrade your Go installation to the latest version and retry. Go 
1.6.3, if that is not a typo is very old.

Jim
On Feb 28 2024, at 11:35 am, Thom BENTLEY  wrote:
> Hi All,
>
> OS: Windows 10
> GoLang: go1.6.3 windows/386
>
> I am trying to have a go executable run and show the panics it causes in the 
> PowerShell console.
> I think I can use GODEBUG, but all the examples I've seen so far are for 
> Linux.
> I've set that variable to paniclog=1, but nothing changed.
>
> If I run go env, I don't see GODEBUG listed.
> Thanks in advance.
>
>
> The information in this email and any attachments are intended solely for the 
> recipient(s) to whom it is addressed, and may be confidential and/or 
> privileged. Any unauthorized distribution or copying of this transmittal or 
> its attachments is prohibited. If you are not a named recipient or have 
> received this email in error: (i) you should not read, disclose, or copy it, 
> (ii) please notify the sender of your receipt by reply email and delete this 
> email and all attachments.
> --
> 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 
> (mailto:golang-nuts+unsubscr...@googlegroups.com).
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/c27faf57-74a0-4299-ac61-140e634f5297n%40googlegroups.com
>  
> (https://groups.google.com/d/msgid/golang-nuts/c27faf57-74a0-4299-ac61-140e634f5297n%40googlegroups.com?utm_medium=email_source=footer).

-- 
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/2FC3FDE4-BCC9-4D29-8C74-361801650A1C%40getmailspring.com.

Re: [go-nuts] Re: Weird error when trying to fetch a module.

['Jim Idle' via golang-nuts]

The go.mod at the root was one thing that might work, but it will cause the
entire repo to be pulled in so the tag will still have to be sec/go/ etc.

On Fri, Sep 15, 2023 at 15:15 Brian Candler  wrote:

> > Keep your go source at the root of the repo and tag that
>
> Or would it be OK just to put go.mod at the root of the repo, containing
> module github.com/flatgeobuf/flatgeobuf
> - and leave the rest of the source where it is?
>
> I believe that will still allow someone to import or get
> github.com/flatgeobuf/flatgeobuf/src/go
> (not that that's a pretty import path). But I don't know if it will behave
> any differently to what the OP sees today.
>
> --
> 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/9638fac0-caa9-491e-bfb2-1d5e51df678en%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/CAGPPfg8VP6bBd3z%3D5Yr8U%2B%3Dr1ajZuzwukAsxy0dDWSuX4HLTCQ%40mail.gmail.com.

Re: [go-nuts] Re: Parsing difficult JSON

['Jim Idle' via golang-nuts]

You can also unmarshal in stages to Raw and then unmarshal the next piece
based on what you have so far. I presume that you cannot change the format?

On Fri, Sep 15, 2023 at 01:05 Tobias Klausmann 
wrote:

> Hi!
>
> On Thu, 14 Sep 2023, Brian Candler wrote:
> > Could you just unmarshal it to a map[string]IntTSList, and then walk it
> and
> > build whatever structure you want?
>
> I will try and make that work tomorrow, thanks for the hint!
>
> > If you want to pick certain fixed fields into a struct and separate out
> the
> > leftovers to be parsed as "subnet[X].Y", then see
> >
> https://stackoverflow.com/questions/33436730/unmarshal-json-with-some-known-and-some-unknown-field-names
> > The last answer points to some other JSON libraries which can handle this
> > part for you - but you'd still have to process the "subnet[X].Y" keys.
>
> That looks like it might work as an alternative. I suspected that _some_
> JSON lib out there would allow for "unknown at compile time" fields
> (without resorting to [][]interface{} --- which leads to doing all the
> parsing myself). So thanks for helping me find a blade of hay in a
> needlestack :)
>
> Best,
> Tobias
>
> --
> 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/cf1b2521-79dc-4651-90de-afacff084f9a%40skade.local
> .
>

-- 
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/CAGPPfg_0Rnu_RGASdKOgUQ9ccZdVz_4Rbo0Q%3D98vtziPWkiXFQ%40mail.gmail.com.

Re: [go-nuts] Re: Weird error when trying to fetch a module.

['Jim Idle' via golang-nuts]

It’s an absolute nightmare to publish modules from subdirectories. I gave
up for ANTLR and created a new repo with the source code in the root
directory.

But the art is that you need to create a tag named with the subdirectory. I
was able to make that work until we needed a v{n} tag. Which as far as I
can tell, just doesn’t work.

I found that go get will duplicate the entire repo anyway, will create a
pseudo tag from the commit, will download after every commit anyway, even
if the go source wasn’t updated, and neither was the tag… the list goes
on.  I looked at the source code for this part of go - it seems the authors
wrestle with this on every release. There are open issues around it too. I
can see how hairy the issues are and I am surprised this does not come up
more often - when I first asked here about it, it was crickets all the way
to the bottom. Also, the import will need to have your subdirectories in
the path, which looks a bit wonky even if it works.

So basically. Don’t do this as you are doing it, even though, on paper, go
does not impose any particular structure on your repo beyond a few basic
things such as excluding testdata, internal, and so on.

Keep your go source at the root of the repo and tag that. If you have a
choice, keep non-go artifacts in another repo, otherwise place that code in
sub-directories, not the go code.

If you have not created a tag, the go will create a pseudo version for you,
which is its default. That’s ok, but it’s difficult to know what source
level you are at from the git commit hash.

I recommend using git flow methodology to make this stuff easier, though
there is nothing forcing you to do so of course.




On Fri, Sep 15, 2023 at 08:34 Lenny Kneller  wrote:

> Hi Bruno,
>
> This command works `github.com/flatgeobuf/flatgeobuf/src/go@master`
> .
> I wonder if `@master` is needed because the repo has no packages published?
> There's more info about pseudo-versions here
> 
>
> -Lenny-
>
> On Thursday, September 14, 2023 at 5:59:39 PM UTC-4 Bruno Albuquerque
> wrote:
>
>> It is likely that I am doing something stupid but as I am out of ideas,
>> here goes nothing.
>>
>> I pushed an initial Go flatgeobuf implementation here:
>>
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> This directory in the repository has a go.mod file with the following
>> contents:
>>
>> module github.com/flatgeobuf/flatgeobuf/src/go
>> go 1.20
>> require github.com/google/flatbuffers v22.11.23+incompatible
>>
>> Just in case it might be relevant, the actual repository is
>> github.com/flatgeobuf/flatgeobuf, src/go is a subdirectory there.
>>
>> If I try to use this module, it fails. For example:
>>
>> # go get -u github.com/flatgeobuf/flatgeobuf/src/go
>> go: downloading github.com/flatgeobuf/flatgeobuf
>> v0.0.0-20230914202020-25c11d75fe28
>> go: module github.com/flatgeobuf/flatgeobuf@upgrade found
>> (v0.0.0-20230914202020-25c11d75fe28), but does not contain package
>> github.com/flatgeobuf/flatgeobuf/src/go
>>
>> What am I missing?
>>
>> -Bruno
>>
>> --
> 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/98b7c5b7-5d5b-4a84-8237-b099dd623a53n%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/CAGPPfg-YT%2BQ4B1R3Wyj%2BQqcfHyeiTJErnZwVKWhMy1%3DzhCQJgg%40mail.gmail.com.

Re: [go-nuts] Slog and error tracing

['Jim Idle' via golang-nuts]

You are logging the same error many times and then trying to solve that in
the logs.

Try this:

Only log the error where it is handled, otherwise wrap it and return it
without logging. At some point, you will log it as either an error if there
is nothing you can do about it, or a warning if somehow you can recover
from it (not panic recover). However your log record will contain the trace
from the point where the error occurred, so you have all the information
you need.

In short: log the error once, at the point you handle it.

On Thu, Aug 10, 2023 at 8:38 PM jal...@gmail.com  wrote:

> Hi all,
>
> I've adopted slog and I am really loving the library.  As I have used this
> on my team, I've noticed a repetitive problem with error wrapping and I am
> curious how other folks have handled this problem.
>
> Lets say you are calling a sequence of functions where one function
> depends on the result of the next function in the sequence. Each function
> returns an error. For traceability, you want to log the error where it was
> encountered, then wrap the error in the current function and return it. You
> then repeat this all the way up the stack. See here for a simplified
> example:
>
> https://go.dev/play/p/uDWU1JucG5W
>
> This has the benefit of clearly communicating what caused the failure in
> each function. It has the drawback that you are repeatedly logging the same
> error information multiple times. Depending on the error text, this could
> turn into a wall of text that makes interpreting logs quite hard for an
> engineer. I learned this the hard way when i use github.com/pkg/errors
> and would print out the stacktrace.
>
> So then I wondered about using context to inject a traceId that would link
> log messages together. I banged out quickly a small library as a PoC.
> Here's what that looks like:
>
> https://go.dev/play/p/BhARBtthdzJ
>
> This allows me to trace back the cause across the logs by sorting by time
> and filtering for the trace id. Means I only need to log the error once.
> The negative here is you have to pass context around for any function that
> logswhich is probably most of them when most of those functions don't
> need to do cancellation. I suppose you could just do context.Background.
>
> So that's what I've come up with. I am curious what others have done.
>
> Thanks,
> Joe
>
> P.S Note yes i know the problem is distributed tracing, that logging is a
> poor way to do this, and one should use an observability platform like
> honeycomb.io  to send errors too. But I don't
> have a platform. I have slog and i am curious how to make error tracing
> work nicely with that.
>
> --
> 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/3a786e33-cb56-4bf5-8e84-d8bfbda7737en%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/CAGPPfg_NwFtTm_%2BZRVbgKCFR7iG85neh%3DUDeCXq1aWVQJgQGZA%40mail.gmail.com.

Re: [go-nuts] go package dating back to 2009

['Jim Idle' via golang-nuts]

Decred is a project that was originally put together by someone who never
claimed the moniker used by the originator.  I suggest that 'Bravo Moua' is
trying to claim authorship.  HOwever, it is clear that I am Spartacus.

https://thedecreddigest.wordpress.com/2017/06/10/decred-where-did-it-all-begin/

On Wed, Jul 26, 2023 at 2:49 PM Rob Pike  wrote:

> I am delighted to learn that I, the original author of Go's fmt and bytes
> packages, am actually Satoshi Nakamoto. I always wondered who he was.
> Thanks for clearing that up.
>
> All kidding aside, I do not understand what you are trying to achieve by
> claiming authorship of this code. Or even if that's what you are doing. As
> Ian said, there was no public Go code in early 2009, and the private,
> internal code that became the public release was all written by a handful
> of Google engineers, your name (or Satoshi's) not among them.
>
> -rob
>
>
> On Wed, Jul 26, 2023 at 3:07 PM Jan Mercl <0xj...@gmail.com> wrote:
>
>> On Wed, Jul 26, 2023 at 12:32 AM Bravo Moua  wrote:
>>
>> > For a fact, bytes, fmt, and packages in those category are from Satoshi
>> Nakamoto and myself.
>>
>> Extraordinary claims require extraordinary evidence.
>>
>> --
>> 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/CAA40n-Xna5Zg-RRygLRquchVC4Z3945kjpE-Z69YBbskB-z0wg%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/CAOXNBZSKRRNZ2LJLmOP617%3Dtfi9tm4SD%2BOopp5s0V3cKKk-Xsw%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/CAGPPfg-sDQSNa6MRQctnJq0ObdqWdC3SXwMkaOJtkqUawM-NsQ%40mail.gmail.com.

Re: [go-nuts] [net.mail] ReadMessage returns nil, io.EOF when email w/o body.

['Jim Idle' via golang-nuts]

If you are doing any serious email work, you might find that the enmime
module is useful.

https://github.com/jhillyerd/enmime

And perhaps this:

https://github.com/gatherstars-com/jwz

Jim

On Wed, Jul 19, 2023 at 9:07 AM Karan Gupta  wrote:

> That is correct. It is the same issue.
> Thanks for the help.
>
> -Karan
>
>
> On Wed, 19 Jul, 2023, 05:15 Ian Lance Taylor,  wrote:
>
>> On Tue, Jul 18, 2023 at 4:36 PM Karan Gupta 
>> wrote:
>> >
>> > RFC 5322 (https://www.rfc-editor.org/rfc/rfc5322#section-3.5) allows
>> for messages without bodies.
>> > ` A message consists of header fields, optionally followed by a message
>> body `
>> >
>> > However, the net/mail . ReadMessage returns an error when an email does
>> not contain a body.
>> > To demonstrate this I have written a small program (attached) that
>> shows the difference in values returned by mail.ReadMessage when the input
>> email message ends in
>> > 1. a 'field' where field is defined as in RFC5322. with focus on the
>> fact that 'field' ends in  a single CRLF
>> > 2. a body. In this specific case, I have chosen to use an empty body.
>> Email is constructed by appending 2 consecutive CRLFs to the message from
>> (1). The first CRLF is to separate the header from the body and the second
>> to terminate an empty body
>> >
>> > Is this a bug in the go standard library?
>>
>> I think you are describing https://go.dev/issue/33823, which, as it
>> happens, is fixed in the upcoming Go 1.21 release.
>>
>> 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/CAAtLhrc4tohZW9taHcyUHr09UN7X5u84XaJS6B_CSr2g-SurVw%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/CAGPPfg-QEXMcOVoYvJeZMZ_jN_1CdpVjKv1BeUcSFfxQEjS5tQ%40mail.gmail.com.

Re: [go-nuts] Go routines consuming memory

['Jim Idle' via golang-nuts]

Ha ha. Yes, I am similarly bearded grey.

I didn't think it was worth filling in after Etc. I almost stopped reading
after ChatGPT on the basis that if you cannot write the simple driver code,
you can neither verify that the driver is correct, nor have the
understanding of the system needed to interpret the results. Measuring
things is a whole different ball game.

On Wed, Jun 7, 2023 at 11:37 AM Kurtis Rader  wrote:

> Thank you. I had the same reaction. I'm a grey beard who in the past
> specialized in benchmarking and performance tuning. Synthetic, micro,
> benchmarks of the type used in that blog post are borderline useless.
> Especially when comparing different languages. Even when used to measure a
> single metric such as memory consumed. I found it interesting that the
> author didn't document (AFAICT) how the memory consumption was measured.
> And the use of ChatGPT to create some of the examples caused an eye-roll
> so strong I was surprised it didn't physically hurt.
>
> On Tue, Jun 6, 2023 at 8:29 PM 'Jim Idle' via golang-nuts <
> golang-nuts@googlegroups.com> wrote:
>
>> This benchmark is worthless for all languages used.
>>
>>- Each Go routine will be given a 2K stack.
>>- Go routines are managed by Go, threads by the operating system.
>>- C# uses a thread pool.
>>- There's a lot wrong with this article, not just with things being
>>claimed about Go.
>>- Benchmarking is not the trivial exercise that the author thinks it
>>is.
>>- Would you really write any system like this in any of the languages?
>>- One would use idiomatic techniques in each of the systems for huge
>>numbers of tasks.
>>- Etc.
>>
>>
>> Personally, I don't think that it is worth addressing; others may feel it
>> is worth it to counter the spread of accidental disinformation.
>>
>> On Wed, Jun 7, 2023 at 10:59 AM Nikhilesh Susarla <
>> nikhilesh1...@gmail.com> wrote:
>>
>>> I was going through a blog where they compare different language threads
>>> to see how much memory they consume for a million tasks.
>>>
>>> Blog : https://pkolaczk.github.io/memory-consumption-of-async/
>>>
>>> Do we have any benchmarking/report before that Go routines take more
>>> memory with more threads?
>>>
>>> I know we can't consider it to be ideal but any reasons that the memory
>>> spiked up?
>>> Is there any blog to read more about go routines and their memory
>>> consumptions?
>>>
>>> Thank you
>>>
>>> --
>>> 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/0af076cc-8b5d-491b-88f5-599dbd37c056n%40googlegroups.com
>>> <https://groups.google.com/d/msgid/golang-nuts/0af076cc-8b5d-491b-88f5-599dbd37c056n%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> 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/CAGPPfg9%2B9xeHVgfTuWVMaSotUt3tJD-3PVE5%3D4o5ozW3WOWDzA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAGPPfg9%2B9xeHVgfTuWVMaSotUt3tJD-3PVE5%3D4o5ozW3WOWDzA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Kurtis Rader
> Caretaker of the exceptional canines Junior and Hank
>

-- 
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/CAGPPfg-26L08BHhDk-Kgv3Yyb-8R7c0gmpkH705EbjN6rRQqqA%40mail.gmail.com.

Re: [go-nuts] Go routines consuming memory

['Jim Idle' via golang-nuts]

This benchmark is worthless for all languages used.

   - Each Go routine will be given a 2K stack.
   - Go routines are managed by Go, threads by the operating system.
   - C# uses a thread pool.
   - There's a lot wrong with this article, not just with things being
   claimed about Go.
   - Benchmarking is not the trivial exercise that the author thinks it is.
   - Would you really write any system like this in any of the languages?
   - One would use idiomatic techniques in each of the systems for huge
   numbers of tasks.
   - Etc.


Personally, I don't think that it is worth addressing; others may feel it
is worth it to counter the spread of accidental disinformation.

On Wed, Jun 7, 2023 at 10:59 AM Nikhilesh Susarla 
wrote:

> I was going through a blog where they compare different language threads
> to see how much memory they consume for a million tasks.
>
> Blog : https://pkolaczk.github.io/memory-consumption-of-async/
>
> Do we have any benchmarking/report before that Go routines take more
> memory with more threads?
>
> I know we can't consider it to be ideal but any reasons that the memory
> spiked up?
> Is there any blog to read more about go routines and their memory
> consumptions?
>
> Thank you
>
> --
> 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/0af076cc-8b5d-491b-88f5-599dbd37c056n%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/CAGPPfg9%2B9xeHVgfTuWVMaSotUt3tJD-3PVE5%3D4o5ozW3WOWDzA%40mail.gmail.com.

Re: [go-nuts] go mod download fails on docker for 1.20 (but not for 1.18)

['Jim Idle' via golang-nuts]

My guess is that IPV6 is disabled in your containers. If you use

docker run -it xxx yyy -c "ip -6 addr show dev eth0; ip -6 route show"

Then you can find out if that is the case.

On Mon, May 22, 2023 at 8:29 AM Joao Miguel Ferreira <
joao.miguel.c.ferre...@gmail.com> wrote:

> Hello all,
>
> My docker build is ok with FROM golang:1.18-alpine, FROM
> golang:1.18-buster and FROM golang:1.18-bullseye images. The application
> works. All is fine on the 3 cases.
>
> But the docker build fails with FROM golang:1.20-alpine, FROM
> golang:1.20-buster and FROM golang:1.20-bullseye images.
>
> This is the error message I get:
>
> go: github.com/davecgh/go-spew@v1.1.1: Get "
> https://proxy.golang.org/github.com/davecgh/go-spew/@v/v1.1.1.mod": dial
> tcp [2a00:1450:4003:801::2011]:443: connect: cannot assign requested address
>
> It happens during go mod download. It happens when building on Debian11,
> Debian12 and Ubuntu22 hosts.
>
> I have tried many things including going inside the container and
> downloading the module with wget. It works fine. Maybe something changed
> from 1.18 to 1.20 related to ipv6.
>
> I would like to be able to do the build with one golang 1.20 image. But I
> can not understand what is wrong. Can you help clarify that error and how
> to overcome it?
>
>
> --
> 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/6629812f-534e-4d01-a46c-ef5bdeac4c12n%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/CAGPPfg90rVL-ctRwFm9%2Bro7GN%3Drt4rHvy1ox0JSMSE7FAoVKMw%40mail.gmail.com.

Re: [go-nuts] Avoid forcing my module users' to carry dependencies from code that live under the same repo just as examples/ debugging purposes.

[Jim Idle]

Indeed. Some parts of it are fine though, given that the ask was for a
starting point. I agree completely with the pkg stuff being wrong. I use
just some of the ideas here, but I don’t see what the point of pkg is.

On Fri, Apr 14, 2023 at 16:04 'Dan Kortschak' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> On Fri, 2023-04-14 at 14:01 +0800, Jim Idle wrote:
> > You might start with this repo:
> >
> > https://github.com/golang-standards/project-layout
> >
> > This is not an 'official' standard, though it does encapsulate the
> > things that are standard go such as the internal directory.
> >
> > Personally I avoid its recommendation to use a directory 'pkg' to
> > store your module code as it makes the import path quite strange. But
> > for a main you can look at the cmd directory or the internal
> > directory. You will not go too far wrong by following this guide.
> >
> > Jim
>
> It's worth noting this issue in that repo:
> https://github.com/golang-standards/project-layout/issues/117
>
> --
> 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/c66f416360824816fa1c9415126c78969beaad9b.camel%40kortschak.io
> .
>

-- 
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/CAGPPfg9s6UNPvQAJ4mz_kH4i6t%3Dp3W8Eb4G-573a-_CnE4F7uA%40mail.gmail.com.

Re: [go-nuts] Avoid forcing my module users' to carry dependencies from code that live under the same repo just as examples/ debugging purposes.

[Jim Idle]

You might start with this repo:

https://github.com/golang-standards/project-layout

This is not an 'official' standard, though it does encapsulate the
things that are standard go such as the internal directory.

Personally I avoid its recommendation to use a directory 'pkg' to store
your module code as it makes the import path quite strange. But for a main
you can look at the cmd directory or the internal directory. You will not
go too far wrong by following this guide.

Jim

On Fri, Apr 14, 2023 at 10:27 AM Pablo Caballero  wrote:

> I made a very simple module (the very first one that I uploaded to my
> GitHub account). I had a main.go file in the root directory used just for
> testing/debugging (and to keep as an example of how to use the module).
> Then I "go got" my module from another project just to see that this
> project transitively got dependencies used only by my module's main.go file
> (pretty obvious that this was going to happen and also that it's not
> desirable) and not used by my module logic.
>
> To avoid this, I moved the main.go and related files to a sub-directory
> called "examples" and created a new go.mod file there. The final structure
> was something like this:
>
> go.mod (github.com/myuser/mymodule)
> my-module-logic.go
> internal/*
> examples/main.go
> examples/go.mod (github.com/myuser/mymodule/examples)
>
> Now when I "go get" my module from another module I don't see the unwanted
> dependencies anymore but I feel like I'm not following best practices
> here... especially because I was hit by some negative consequences:
> * now I must "go get github.com/myuser/mymodule" from "examples"
> * while making changes to my module (I use Goland because it's provided by
> the company I work for) and debugging it using the examples/main.go as an
> entry point (yes, I know that strictly speaking, doing that, I'm debugging
> my module as a "side effect" from debugging the example ) I find myself
> walking through the source code from the version of my module that I "go
> got" last (and not through the source that I'm actively working on)
>
> Sorry if I'm asking something obvious here (I tried to do the homework)
>
> I really appreciate any help.
>
> Best!
>
> Pablo
>
>
> --
> 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/CAPxFe-ur4cURAmCRFJa0QpTHaL3CHCt_Lz%2BZkWK4N1hiL5Bd0A%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/CAGPPfg-6jgV-Ah8yecb_0hfTdMB%2BBS6%3DsgPBks2NHTvKOKnYEw%40mail.gmail.com.

[go-nuts] Re: Correctly tagging a module in a subdirectory of a Github repo

[Jim Idle]

Just to follow up on my question, I have read all the docs again, and I am 
thinking that I used the wrong tag syntax. I think it should either be:

git tag -a  runtime/Go/antlr/v4/v4.12.0 -m "ssads" runtime/Go/antlr/v4

or just

git tag -a  runtime/Go/antlr/v4/v4.12.0 -m "ssads"

Am I on the right path?

Sorry to speculate here on the group, but I cannot just go start messing 
around on the master branch and testing it out, or I would have done so.

Jim

On Saturday, March 4, 2023 at 12:09:48 PM UTC+8 Jim Idle wrote:

> For historic reasons, which are too difficult to change (and pre-modules), 
> the runtime module for the ANTLR v4 Go runtime is held in a subdirectory of 
> the antlr/antlr4 Github repo. This is complicated by the fact that 
> organizations have written scripts into their build to copy the source code 
> into their monorepos and so on (I'm looking at you Google ;). I cannot just 
> put the source code into its own repo and be done with it. Also, there are 
> a ton of automated scripts for testing and release etc. There are something 
> like 45 projects within Google alone that rely on the source location and 
> tag presence etc.
>
> In the past, tags with the v prefix had been created that point to the 
> root of the repo (to clarify, I mean the tags don't contain the prefix - I 
> know tags point at commit hashes). They were not created for go and people 
> have used them in builds - I cannot just delete them. For instance, there 
> is a tag v.4.11.1 which seemed to totally throw off the go get etc and 
> while using the path to the runtime in the import works, it meant that the 
> entire repo source is installed as if it were the go module, and the go.mod 
> for a project and the ~/go/pkg/mod shows 
> github.com/antlr/ant...@v4.11.1+incompatible 
> <http://github.com/antlr/antlr4@v4.11.1+incompatible>. I can understand 
> why this is.
>
> With the latest release v4.12.0, I created tags with the directory prefix: 
> runtime/Go/antlr/v4/v4.12.0 a la:
>
> git tag -a v4.12.0 -m "ssads" runtime/Go/antlr/v4
>
> And there is no v4.12.0 tag. There is a 4.12.0 tag for use by non-go users 
> in the future.
>
> This seems to work in that the cache now only contains the v4 source for 
> go. So far so good. But when a go get is issued, the go.mod (and reflected 
> in cache) for a project seems to indicate the commit hash and not the 
> version, so the module for a project that uses it will look like this:
>
> module x/y/z
>
> go 1.19
>
> require (
> github.com/antlr/antlr4/runtime/Go/antlr/v4 
> v4.0.0-20230219212500-1f9a474cc2dc
> )
>
> require golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect
>
> Where I was expecting to see v4.12.0. The go.mod for the runtime is stored 
> inthe /v4 directory of course, but there is no other go.mod, such as at the 
> root of the repo.
>
> The docs are a little light on this area, so I cannot tell if this is what 
> should be expected, or whether my tags are not quite correct in some way.
>
> The current latest tag is:
>
>
> https://github.com/antlr/antlr4/releases/tag/runtime%2FGo%2Fantlr%2Fv4%2Fv4.12.0
>
> The previous incorrect tag is:
>
> https://github.com/antlr/antlr4/releases/tag/v4.11.1
>
> I suspect that the directory associated tag is not correct, and that:
>
> go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4
>
> Is just getting the latest commit to master, or the commit at the point 
> where the tag was created. I am aware that tags point at the commit and 
> refer to the repo as a whole. I'm even looking suspiciously at that 
> uppercase G.
>
> I suspect this because:
>
> go get -u github.com/antlr/antlr4/runtime/Go/antlr/v...@v4.12.0 
> <http://github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0>
> go: github.com/antlr/antlr4/runtime/Go/antlr/v...@v4.12.0 
> <http://github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0>: invalid 
> version: unknown revision runtime/Go/antlr/v4.12.0
>
> So, I am wondering if there are any devops guys on here (I am a wizened 
> old coder, used to having devops guys to ask ;), that no how to do this 
> correctly?
>
> Any pointers appreciated. Hopefully I am just misunderstanding something 
> here.
>
> Jim
>

-- 
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/2f38c23d-48b0-4b25-847f-7b6131b7c372n%40googlegroups.com.

[go-nuts] Correctly tagging a module in a subdirectory of a Github repo

[Jim Idle]

For historic reasons, which are too difficult to change (and pre-modules),
the runtime module for the ANTLR v4 Go runtime is held in a subdirectory of
the antlr/antlr4 Github repo. This is complicated by the fact that
organizations have written scripts into their build to copy the source code
into their monorepos and so on (I'm looking at you Google ;). I cannot just
put the source code into its own repo and be done with it. Also, there are
a ton of automated scripts for testing and release etc. There are something
like 45 projects within Google alone that rely on the source location and
tag presence etc.

In the past, tags with the v prefix had been created that point to the root
of the repo (to clarify, I mean the tags don't contain the prefix - I know
tags point at commit hashes). They were not created for go and people have
used them in builds - I cannot just delete them. For instance, there is a
tag v.4.11.1 which seemed to totally throw off the go get etc and while
using the path to the runtime in the import works, it meant that the entire
repo source is installed as if it were the go module, and the go.mod for a
project and the ~/go/pkg/mod shows
github.com/antlr/antlr4@v4.11.1+incompatible. I can understand why this is.

With the latest release v4.12.0, I created tags with the directory prefix:
runtime/Go/antlr/v4/v4.12.0 a la:

git tag -a v4.12.0 -m "ssads" runtime/Go/antlr/v4

And there is no v4.12.0 tag. There is a 4.12.0 tag for use by non-go users
in the future.

This seems to work in that the cache now only contains the v4 source for
go. So far so good. But when a go get is issued, the go.mod (and reflected
in cache) for a project seems to indicate the commit hash and not the
version, so the module for a project that uses it will look like this:

module x/y/z

go 1.19

require (
github.com/antlr/antlr4/runtime/Go/antlr/v4
v4.0.0-20230219212500-1f9a474cc2dc
)

require golang.org/x/exp v0.0.0-20230224173230-c95f2b4c22f2 // indirect

Where I was expecting to see v4.12.0. The go.mod for the runtime is stored
inthe /v4 directory of course, but there is no other go.mod, such as at the
root of the repo.

The docs are a little light on this area, so I cannot tell if this is what
should be expected, or whether my tags are not quite correct in some way.

The current latest tag is:

https://github.com/antlr/antlr4/releases/tag/runtime%2FGo%2Fantlr%2Fv4%2Fv4.12.0

The previous incorrect tag is:

https://github.com/antlr/antlr4/releases/tag/v4.11.1

I suspect that the directory associated tag is not correct, and that:

go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4

Is just getting the latest commit to master, or the commit at the point
where the tag was created. I am aware that tags point at the commit and
refer to the repo as a whole. I'm even looking suspiciously at that
uppercase G.

I suspect this because:

go get -u github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0
go: github.com/antlr/antlr4/runtime/Go/antlr/v4@v4.12.0: invalid version:
unknown revision runtime/Go/antlr/v4.12.0

So, I am wondering if there are any devops guys on here (I am a wizened old
coder, used to having devops guys to ask ;), that no how to do this
correctly?

Any pointers appreciated. Hopefully I am just misunderstanding something
here.

Jim

-- 
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/CAGPPfg_JqcfWU7cFPWu2sNs11dzk2iELJry9nSVFmAeZUgqVYQ%40mail.gmail.com.

Re: [go-nuts] Creating and Linking to Shared Library Version of Go Runtime? (with possible solution)

[Jim Idle]

Looking back at your posts, I think you got there because your initial
build of the shared library was via sudo? I don’t think that was correct
and you didn’t need sudo.

If the shared library only contained code needed for your executable, then
it could only be shared by other instances of your executable.

Jim

On Tue, Jan 31, 2023 at 04:56 jlfo...@berkeley.edu 
wrote:

> I'm the original poster. I've looked into this more and I might have an
> explanation for
> what's going on.
>
> Just for yuks, I started with perhaps the simplest Go program, which I
> called t.go:
>
> package main
> func main() {
> }
>
> As root, I was able to build both a dynamically (21512 bytes) and a
> statically (1203019 bytes) linked  executable.
> This is with go version go1.19.4 linux/amd64.
>
> I then ran
>
> go build -linkshared -x t.go
>
> This showed all the commands the go tool executed. I saved these commands
> in a file
> so I could look more closely at what was going on.
>
> Here's what I think is going on. When running go build -linkshared go
> attempts to create a new
> version of the shared runtime library. At first glance, it appears that
> only the code that's necessary
> to run the executable is put there (I'm not 100% sure about this). But
> it's clear that a new file
> called
>
> /usr/local/go/pkg/linux_amd64_dynlink/libstd.so
>
> is created. As a normal user I create or write to this file, which is why
> I get all
> the permission denied error messages. So, the main question is why does go
> build create
> this library when I already ran
>
> go install -buildmode=shared std
>
> to create the shared library?
>
> To continue, as root I changed the ownership of
>
> /usr/local/go/pkg/linux_amd64_dynlink
>
> to me, and then, as me, was finally able to create the dynamically linked
> executable!
>
> So, to answer my original question, the reason I can't create a
> dynamically linked
> executable is because the go build tool attempts to create a new shared
> library in
> a location that a normal user can't write to. Whether it's actually
> necessary to
> create this shared library I can't say, but if so, it should be done an a
> directory
> that a normal user can write to.
>
> This also answers the second question, which is why it takes longer to
> create a dynamically
> linked executable than a statically linked executable. This is due to the
> time it takes to
> build the possibly-extraneous shared library.
>
> I welcome any comments and/or corrections to any of this.
>
> Cordially,
> Jon Forrest
>
>
> --
> 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/6a17b197-3e57-4a3d-9a84-4a01ba04bf31n%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/CAGPPfg-GAp7wG1c%3DeXpuu4SmiD9EDp-fcoVCsokDMRDy94bJ_w%40mail.gmail.com.

Re: [go-nuts] Re: Changes to x509 in Go 1.18

[Jim Idle]

 The issue is here already: https://github.com/golang/go/issues/51991 - the
causes seems to be already known.


On Mar 29, 2022 at 12:34:44 AM, 'Jordan Liggitt' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> Do you have a standalone reproducer of a certificate go1.17 considered
> valid that go1.18 does not? If so, can you file an issue at
> https://github.com/golang/go/issues for investigation?
>
> On Thursday, March 24, 2022 at 2:10:10 AM UTC-4 Jim Idle wrote:
>
>> Having just upgraded to 1.18, I find that quite a few encrypted
>> connections, for instance https to a Neptune instance on AWS, now fail with:
>>
>> x509: “*.x.neptune.amazonaws.com” certificate is not standards
>> compliant
>>
>> It seems to be related to this comment:
>>
>>
>> https://cs.opensource.google/go/go/+/master:src/crypto/x509/root_darwin.go;l=52
>>
>> I don’t immediately see anything on how to get around this via google
>> searches, though I see some changelists concerning x509 for 1.18. I am not
>> able to change the Neptune certificate, which may indeed not be quite
>> standards compliant, as the error message suggests. However, it is not just
>> Neptune - I see some people having issues with redid for instance.
>>
>> Apologies if this has been addressed somewhere that I have not found.
>> Perhaps with more time, I will find some workaround or solution, but I
>> thought asking here may help.
>>
>> Any input/workarounds appreciated, as well as any insight into the reason
>> for change.
>>
>> Jim
>>
> --
> 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/2dcb264a-25a0-4122-ab1b-7db88aac3bcdn%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/2dcb264a-25a0-4122-ab1b-7db88aac3bcdn%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 
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/CAGPPfg8C6o3sde7u_2Lhw028dsuEokV%2Bv-HuQKt9dGfM9N4QsQ%40mail.gmail.com.

Re: [go-nuts] Changes to x509 in Go 1.18

[Jim Idle]

 Yes - look like it is for slightly different reasons. Apple have decided
on a new policy for verifying certificates and the certificate must have
either two (younger certs) or three (older certs) valid SCTs. I suspect
that you could re-issue your cert to comply with this, but I am not sure
about your mechanism for this. It seems though that even if Go 1.18 was
patched to let such a failure through - and it isn’t clear that it should
be, as per the TODO - that it would not help with AWS as it seems that they
don’t have ANY SCTs in their certificates. AWS will have have to re-issue
probably all their certificates, which leaves some of us a bit screwed for
a while.

This isn’t my area of expertise, but it seems that perhaps Apple have been
a bit too aggressive on this. I hazard a guess that what they have
implemented is likely correct, but if a company such as Apple makes such a
change, I think they should have made more noise about it, so that other
companies knew about the change.

So, a combination of OSX 12.3 with Go 1.18 will trigger this, unless you
have the ability to re-issue certificates with the requisite number of
SCTs. I have no control over most AWS certificates - they are issued by
AWS, for AWS. So now, I will have to ask AWS if they can do anything about
it. But I can’t see them re-issuing certificates for all their myriad
services, overnight.

Jim

PS: I quote the ticket you raised, in case it is useful to others:

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


On Mar 29, 2022 at 2:48:34 AM, Davanum Srinivas  wrote:

> Jim,
>
> Looks like we ended up seeing the same problem in a kubernetes test case
> as well:
> https://github.com/kubernetes/kubernetes/issues/108956
>
> -- Dims
>
> On Thu, Mar 24, 2022 at 2:09 AM Jim Idle  wrote:
>
>> Having just upgraded to 1.18, I find that quite a few encrypted
>> connections, for instance https to a Neptune instance on AWS, now fail with:
>>
>> x509: “*.x.neptune.amazonaws.com” certificate is not standards
>> compliant
>>
>> It seems to be related to this comment:
>>
>>
>> https://cs.opensource.google/go/go/+/master:src/crypto/x509/root_darwin.go;l=52
>>
>> I don’t immediately see anything on how to get around this via google
>> searches, though I see some changelists concerning x509 for 1.18. I am not
>> able to change the Neptune certificate, which may indeed not be quite
>> standards compliant, as the error message suggests. However, it is not just
>> Neptune - I see some people having issues with redid for instance.
>>
>> Apologies if this has been addressed somewhere that I have not found.
>> Perhaps with more time, I will find some workaround or solution, but I
>> thought asking here may help.
>>
>> Any input/workarounds appreciated, as well as any insight into the reason
>> for change.
>>
>> Jim
>>
>> --
>> 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/CAGPPfg-PtW7dqeNKo72fvLsLZ1Qg2i_AwmUBJcTGMNgeHUhfCA%40mail.gmail.com
>> <https://groups.google.com/d/msgid/golang-nuts/CAGPPfg-PtW7dqeNKo72fvLsLZ1Qg2i_AwmUBJcTGMNgeHUhfCA%40mail.gmail.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
> Davanum Srinivas :: https://twitter.com/dims
>

-- 
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/CAGPPfg_FTFPLk6Rq577YFLNK_3D8qYWdkDhDQgzRjfOTqhMbBw%40mail.gmail.com.

[go-nuts] Changes to x509 in Go 1.18

[Jim Idle]

Having just upgraded to 1.18, I find that quite a few encrypted
connections, for instance https to a Neptune instance on AWS, now fail with:

x509: “*.x.neptune.amazonaws.com” certificate is not standards
compliant

It seems to be related to this comment:

https://cs.opensource.google/go/go/+/master:src/crypto/x509/root_darwin.go;l=52

I don’t immediately see anything on how to get around this via google
searches, though I see some changelists concerning x509 for 1.18. I am not
able to change the Neptune certificate, which may indeed not be quite
standards compliant, as the error message suggests. However, it is not just
Neptune - I see some people having issues with redid for instance.

Apologies if this has been addressed somewhere that I have not found.
Perhaps with more time, I will find some workaround or solution, but I
thought asking here may help.

Any input/workarounds appreciated, as well as any insight into the reason
for change.

Jim

-- 
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/CAGPPfg-PtW7dqeNKo72fvLsLZ1Qg2i_AwmUBJcTGMNgeHUhfCA%40mail.gmail.com.

[go-nuts] JWZ Email Threading algorithm now available

[Jim Idle]

A few people were talking about email parsing etc on this forum, so perhaps 
this will be useful to some people:

https://github.com/gatherstars-com/jwz

Fully implements the JWZ Threading algorithm in go. It provides:

   - Threading via interface
   - Sort with custom comparator func
   - Walk with custom visitor function
   - Example program to parse emails using Enmime, thread them, sort them, 
   then use tview to display a rudimentary tree view in the console

Cheers,

Jim

PS: Ignore the "go report: F" badge. It is actually A+, but the go report 
site is down at the moment it seems.


-- 
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/4df4216d-c345-4d2f-8c21-c21559e0d4e0n%40googlegroups.com.

Re: [go-nuts] Re: Email threading package?

[Jim Idle]

Hi,

I was going to need to write this anyway, so I took today to write it and
the company decided we can open source it. I have literally just pushed it
to github, so please report any problems if you try it out. I have not
proofread and checked the documentation yet, so I have made it 0.9.0 for
the next day or so, after which it will be released. I hope this helps:

https://github.com/gatherstars-com/jwz

I have tested it on hundreds of thousands of emails using the enmime email
parsing package to generate the envelopes - this is a very good package by
the way if you need a parser.

Cheers,

Jim


On Sat, Aug 7, 2021 at 1:40 PM 'Sebastien Binet' via golang-nuts <
golang-nuts@googlegroups.com> wrote:

> There's that:
>
> https://git.sr.ht/~emersion/go-emailthreads
>
> (Quickly scanning the sources, it seems it "just" performs a topological
> sort, though)
>
> hth,
> -s
>
> Aug 7, 2021 00:41:41 Tuhin Nair :
>
> Hey, this is a long shot but any chance you found a Go implementation for
> the JWZ algorithm?
>
> On Monday, July 20, 2015 at 6:14:32 AM UTC+5:30 a...@develooper.com
> wrote:
>
>> Hi,
>>
>> Has anyone made an (open source) package to thread emails -- ideally a
>> variation of http://www.jwz.org/doc/threading.html ? (I wanted to
>> upgrade an old NNTP -> web gateway to Go to make it easier to maintain and
>> it seems like nobody has done this part yet as open source -- or really
>> much email parsing stuff).
>>
>> Searching the internet for "golang email thread" (and variations) brings
>> a lot of results referencing other email threads. :-)
>>
>>
>> Ask
>>
> --
> 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/89dddc34-3bdf-4cc7-8503-3d43a36ab771n%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/ddc0e3bd-696f-48a6-9911-b7873a6b3b48%40sbinet.org
> 
> .
>

-- 
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/CAGPPfg_fOLm8AFfgeuTwGRw%2Bv5BFY6Vwyk2d2R4E5gmcJi2z0A%40mail.gmail.com.

Re: [go-nuts] doubts

[Jim Idle]

If you are just starting out, I would use Iris rather than gin-gonic. You
can then borrow from the many examples for that framework:
https://github.com/iris-contrib/examples



On Sun, Jul 11, 2021 at 1:38 AM Sree lekshmi MG  wrote:

> hey all i am the beginner in golang ,and now  i want to slove *CRUD
> Operations using gin-gonic framework:*
> 1.Create a go service using Gin.
> 2.Connect to mysql database.
> 3.Create End points for all crud operations.
> 4.Write functions for each operation.
> 5.Finally, test it from postman. these type of progrmms can u give me idea
> where i start and what are things i want to slove
>
> --
> 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/e45b549e-df63-4f8b-b08c-854b8988bf24n%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/CAGPPfg8%3DeA0Muu5rYPUp3mTXKSS%3Dewii1nJgK_bAhA%3DYRZ2GxA%40mail.gmail.com.

Re: [go-nuts] Fwd: protoc-gen-go and go modules

[Jim Idle]

Create a separate module that contains only the .proto files and use the
generate directive. You can then version that module and share it. If your
client is some other language, you can generate Its code from the same repo
at the same version using your CI. For instance generate a pip wheel as
well as the go source.

By checking in the generated code for all languages, you guarantee that it
is in a particular state and that your build is reproducible. It sounds
counter intuitive, but Makes sense once you've cogitated on it.

On Wed, May 12, 2021 at 18:47 Amit Saha  wrote:

> Hi all, this is only relevant to people using grpc.  I posted the query
> below to the grpc mailing list, thought of posting it here as welll.
>
> How are you importing the generated definitions and other resources
> them into your server and client? As far as I see it now, the protoc
> command will not generate a go.mod file in the generated code which
> means - you have to do it manually and then import them into your
> server and client. That is, you will have three modules:
>
> - One for server
> - One for client
> - One for the generated code
>
> This seems to be the cleanest approach. During local development, we
> will then use the "replace" directive for iteration.
>
> I am keen to hear how it's being done by others in the community.
>
> Thanks,
> Amit.
>
> --
> 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/CANODV3kqN0wtK5bO3AfVbUhMt1iE9eYvboqbzmSLnY72N6-a6A%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/CAGPPfg9MtU0yvgr9FOC-h9XCzpG7O2Sfm%3Dha53swxZiyd1uFrQ%40mail.gmail.com.

[go-nuts] Code generation with LLVM bindings

[Jim Idle]

It isn't immediately obvious to me which package should be used to generate 
code using LLVM and go bindings.

On the one hand there is this package:

https://godoc.org/llvm.org/llvm/bindings/go/llvm

But I also see this one:

https://github.com/llir/llvm

Which seems to be specifically about IR. 

Instinct tells me that the llvm.org package is probably the one to use when 
implementing a code generator for a DSL, but a little searching does not 
make it obvious. 

Before I go diving in on my own, anyone on here used either of them? If 
this is not the right group I am about to rejoin the LLVM group and can ask 
there if further searching does not give me the answer.

Cheers,

Jim

-- 
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/7c9e6f17-5dec-44f8-b644-59d0d3726d28%40googlegroups.com.

Re: [go-nuts] Proposal: provide runtime sigprocmask api to block some signal for go runtime

['Jim Idle' via golang-nuts]

*Note that you must not use sigprocmask in multi-threaded processes,
because each thread has its own signal mask and there is no single process
signal mask. According to POSIX, the behavior of sigprocmask in a
multi-threaded process is “unspecified”. *

There is a lot more to signal handling than sigprocmask. If you read
through all the docs, you should be able to work out what you want to do.

On Tue, Aug 13, 2019 at 5:27 PM hui zhang  wrote:

> check this
> https://groups.google.com/forum/#!topic/golang-nuts/1YvP-5V6xSI
> when we code golang with c,   some c code used *  sigwait  sigwaitinfo*
> function to wait signal.
> sometime this signal is caught by golang runtime,  and this cause cash.
> we want the signal continue to be handled by *sigwait  sigwaitinfo*
>
>
> --
> 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/086f1e16-c8ea-4970-b4e8-98b34c4dec75%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/CAFZPyg1zoTFAAhM%3Dn2gjujOKH1eK%2BHUHS6jdrjgTQ4kt6Ydtcg%40mail.gmail.com.

Re: [go-nuts] I know you cannot kill a goroutine, but ...

['Jim Idle' via golang-nuts]

Good luck on your implementation. I suggest though that you will find too
many issues like this to use go routines as the base model for a user. I
looked in to threads as a model for jBASE and even with that model, it was
going to be too fraught with difficulty. Unless you are considering a
production grade implementation with 1000's of users, then I would just
implement it as separate go processes. You don't have to use shared memory
unless you are trying to copy Universe, but even if you did, you can still
use such things in go (though mmap might a better way).

Your bigger problem, if you are trying to provide a complete copy, is
reproducing the query language and conversion processor. with all their
quirks and strangeness. The compiler is easy compared to that :)

Jim

On Sat, Aug 10, 2019 at 2:34 AM  wrote:

> Background:
> UniVerse is a Pick model, multivalue database,
> https://groups.google.com/forum/#!forum/mvdbms for some general
> information.
> Multivalue databases permit more than one value in a column for a row.
> Since you do not know the size of the column with hundreds or thousands of
> values in the column-row, you do not know the size of the record. Access
> dictates linked lists to handle variability in record size. So, every row
> gets a unique primary key and stored in hash tables with an appropriately
> large number of hash buckets for the data - key / value pairs. With good
> hashing, I can often access a record in a single disk access. Group (hash
> table bucket) locking happens within the environment, while users request
> row locking. Each user in UniVerse is a separate O/S process. Locking
> activity occurs in shared memory, using assembly test-and-set kinds of
> instructions or host-specific semaphores.
>
> After retiring, I decided it would be a fun experiment to build a
> clean-room implementation of UniVerse. Go does not do interprocess
> communication at the rate that would match the shared memory semaphore
> activity in UniVerse. A natural match implements each user as a goroutine.
> UniVerse provides an extended BASIC language for accessing and manipulating
> table data that runs close to the engine. In a language you can do silly
> things like create an infinite loop. In a production environment of 1000s
> of users, you cannot simply bounce the environment because one user is
> eating a CPU. An admin function to dismiss or kill a goroutine would be
> ideal. Not possible in the current Go world.
>
> For an infinite loop to exist, you need to branch "backwards" or call a
> routine that calls you back with some possible indirection. (An equivalent
> in Go is "for {}" with no break. Here, you would not get back to the
> traditional mechanism of telling a goroutine to shut down where one of the
> channels for select is the shutdown indicator.)  There may be other
> examples I have yet to think of. When I "compile" BASIC, I can put checks
> into those two functions, call, and branch (to a lower address), without
> inducing too much overhead. an unimportant detail is that the BASIC
> compiles to a p-code run on a run machine, comparable to a JVM. I might
> even be able to find the PC, Program Counter or IA, Instruction Address,
> and insert some kind of trap instruction opcode, that would cause it to try
> the select statement and see the shutdown channel. But in the general case,
> this may be insufficient. I think a "context" timeout would interrupt a
> properly long-running program in a way that might be hard to restart if
> shutdown was not requested.
>
> As a database, there is also the possibility of deadly embrace. Killing
> one of the two (or more) goroutines in a deadly embrace would be useful.
> This normally occurs on poorly managed acquisition of exclusive locks on
> database table rows. I could forcibly release a lock, but then would need
> extra work so that a user goroutine that thinks it exclusively owns a lock,
> finds that it does not, and would need to gracefully exit or handle the
> situation.
>
> As a goroutine, each user does not have a STDIN, and STDOUT to communicate
> with its user. Currently, the user communicates with the goroutine with a
> socket connection. I can probably redesign, adding a new goroutine
> accepting user requests/commands on a channel, and monitoring the shutdown
> channel with a select in a loop. Otherwise, I could not get a goroutine to
> shut down if it is waiting on user input from a socket, or a dropped
> connection, although that begs the question of how to get the
> socket-reading goroutine to now shut down.
>
> The current Go implementation smells of cooperative multitasking. Not a
> bad thing, per se, but makes it hard to stop in certain degenerate cases.
> Have I missed a way to deal with some of the discussed issues?
>
> The project has certainly been a good way to become familiar with a number
> of the Go idioms. (BTW, I happen to *like* the current way of handling
> errors!)
>
> --
> You received this message because