Re: [go-nuts] Re: Replacement for net.Error.Temporary in server Accept loops

[Ian Lance Taylor]

On Wed, Apr 20, 2022 at 6:46 PM 'Damien Neil' via golang-nuts
 wrote:
>
> The reason for deprecating Temporary is that the set of "temporary" errors 
> was extremely ill-defined. The initial issue for https://go.dev/issue/45729 
> discusses the de facto definition of Temporary and the confusion resulting 
> from it.
>
> Perhaps there's a useful definition of temporary or retriable errors, perhaps 
> limited in scope to syscall errors such as EINTR and EMFILE. I don't know 
> what that definition is, but perhaps we should come up with one and add an 
> os.ErrTemporary or some such. I don't think leaving net.Error.Temporary 
> undeprecated was the right choice, however; the need for a good way to 
> identify transient system errors such as EMFILE doesn't mean that it was a 
> good way to do so or could ever be made into one.

To frame issue 45729 in a different way, whether an error is temporary
is not a general characteristic.  It depends on the context in which
it appears.  For the Accept loop in http.Server.Serve really the only
plausible temporary errors are ENFILE and EMFILE. Perhaps the net
package needs a RetriableAcceptError function.

Ian



> On Wednesday, April 20, 2022 at 6:02:34 PM UTC-7 ces...@gmail.com wrote:
>>
>> In Go 1.18 net.Error.Temporary was deprecated (see
>> https://go.dev/issue/45729). However, in trying to remove it from my
>> code, I found one way in which Temporary is used for which there is no
>> obvious replacement: in a TCP server's Accept loop, when deciding
>> whether to wait and retry an Accept error.
>>
>> You can see an example of this in net/http.Server today:
>> https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059
>>
>> In this case, Temporary seems useful, and enumerating the OS-specific
>> errors myself doesn't seem like a good idea.
>>
>> Does anyone have a good solution here? It doesn't seem like this was
>> adequately considered when making this deprecation decision.
>>
>> Caleb
>
> --
> 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/1024e668-795f-454f-a659-ab5a4bf9517cn%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/CAOyqgcVKMUhNhpHud6HowL%2BXULuZ1-%2BOu5MgMe0pj8HB0gG_Cg%40mail.gmail.com.

Re: [go-nuts] [GoLLVM/gofrontend] Different itab implementation?

[Lanzhiguan Huang]

Thanks
On Thursday, April 21, 2022 at 6:37:10 AM UTC+8 Ian Lance Taylor wrote:

> On Wed, Apr 20, 2022 at 6:31 AM Lanzhiguan Huang
>  wrote:
> >
> > In gc's implementation, the itab struct has an interface type and an 
> object type field and a method table, while in the GoLLVM's implementation, 
> the type descriptor was moved to the first field of the method table. I 
> think they just maintain the same information but do not understand the 
> purposes of the design. Currently the difference may cause incompatibility 
> between the two compilers.
>
> There is no safe way for Go code to ever see these structures, so the
> difference should not matter to any ordinary Go programs.
>
> At this point I don't think there is any deep reason for the slightly
> different design. Historically it was because the gc implementation
> used a runtime cache, but these days the gofrontend implementation
> used by GoLLVM also uses a runtime cache.
>
> 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/1c141a39-1cfb-484a-a61f-03becd8ed590n%40googlegroups.com.

Re: [go-nuts] Executing a tar command from within a Go program

[Dean Schulze]

The variadic args worked perfectly.  Thanks.

I did not use the archive/tar and compress/gzip approach because that wold 
be a lot more complicated than just executing a tar command.  Those 
packages are oriented towards reading/writing the contents of 
archive/compressed files into the program rather than just extracting a 
file from a compressed archive.

On Wednesday, April 20, 2022 at 10:28:06 AM UTC-6 wagner riffel wrote:

> On Wed Apr 20, 2022 at 6:16 PM CEST, Dean Schulze wrote:
> > I need to execute this tar command
> >
> > *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/*
> >
>
> Did you considered using the packages "archive/tar" and
> "compress/gzip" to achive this?
>
> > *argStr := "xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/"output, err
> > := exec.Command("tar", argStr).Output()*
> >
>
> exec.Command arguments are variadic, each argument is one argv, thus I
> think you meant exec.Command("tar", "xzf", "dir1/dir2/somefile.tgz",
> "--directory=dir1/dir2/")
>
> -w
>

-- 
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/2556c040-94e3-487e-b5b1-ecbe75bb7d47n%40googlegroups.com.

[go-nuts] Re: Replacement for net.Error.Temporary in server Accept loops

['Damien Neil' via golang-nuts]

The reason for deprecating Temporary is that the set of "temporary" errors 
was extremely ill-defined. The initial issue for https://go.dev/issue/45729 
discusses the de facto definition of Temporary and the confusion resulting 
from it.

Perhaps there's a useful definition of temporary or retriable errors, 
perhaps limited in scope to syscall errors such as EINTR and EMFILE. I 
don't know what that definition is, but perhaps we should come up with one 
and add an os.ErrTemporary or some such. I don't think leaving 
net.Error.Temporary undeprecated was the right choice, however; the need 
for a good way to identify transient system errors such as EMFILE doesn't 
mean that it was a good way to do so or could ever be made into one.

On Wednesday, April 20, 2022 at 6:02:34 PM UTC-7 ces...@gmail.com wrote:

> In Go 1.18 net.Error.Temporary was deprecated (see
> https://go.dev/issue/45729). However, in trying to remove it from my
> code, I found one way in which Temporary is used for which there is no
> obvious replacement: in a TCP server's Accept loop, when deciding
> whether to wait and retry an Accept error.
>
> You can see an example of this in net/http.Server today:
>
> https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059
>
> In this case, Temporary seems useful, and enumerating the OS-specific
> errors myself doesn't seem like a good idea.
>
> Does anyone have a good solution here? It doesn't seem like this was
> adequately considered when making this deprecation decision.
>
> Caleb
>

-- 
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/1024e668-795f-454f-a659-ab5a4bf9517cn%40googlegroups.com.

[go-nuts] Replacement for net.Error.Temporary in server Accept loops

[Caleb Spare]

In Go 1.18 net.Error.Temporary was deprecated (see
https://go.dev/issue/45729). However, in trying to remove it from my
code, I found one way in which Temporary is used for which there is no
obvious replacement: in a TCP server's Accept loop, when deciding
whether to wait and retry an Accept error.

You can see an example of this in net/http.Server today:
https://github.com/golang/go/blob/ab9d31da9e088a271e656120a3d99cd3b1103ab6/src/net/http/server.go#L3047-L3059

In this case, Temporary seems useful, and enumerating the OS-specific
errors myself doesn't seem like a good idea.

Does anyone have a good solution here? It doesn't seem like this was
adequately considered when making this deprecation decision.

Caleb

-- 
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/CAGeFq%2BkrZLpE0zaL80B-SJsUMx4FeSEOCRrY4fVX1cBsgzRkNg%40mail.gmail.com.

Re: [go-nuts] Re: Protective buffered channel that never triggers deadlock

[Zhaoxun Yan]

" Strangely I found the start testing and disconnect log clustered and the
disconnect  did actually happen. Then I switch back to the sequential case
that the receiving channel gots filled without receiving until
disconnection. It works now."

-- I found the error occurred again. It turned out that it referenced a
global integer variable which might be 0 yet so it called the disconnection
function even before it got connected.  It has nothing to do with first to
receive or to send.

On Fri, Apr 15, 2022 at 3:44 PM Brian Candler  wrote:

> On Friday, 15 April 2022 at 08:31:17 UTC+1 yan.z...@gmail.com wrote:
>
>> Thanks for your demonstration, Brian.
>> Actually my code involving cgo is quite like your first case, like this
>> code:
>>
>> *log("start testing")*
>> *go func{*
>> *  for*
>> *  select*
>> *  case a: <=receiving*
>> *  case <- killsig*
>> *...*
>> *}()*
>>
>> *subscribequotations*
>> *( meanwhile the cgo of the dll will call back go functions to fill
>> receiving channel)*
>> *time.Sleep(3 * time.Seconds)*
>>
>> *disconnect and log*
>> *killsig <- true*
>>
>
> That code is obviously incomplete, but I'm guessing when you receive a
> value on killsig you return from the function.
>
> A better Go idiom for that is to close a channel.  All the receivers on
> that channel will see that the channel is closed:
>
> case msg, ok <- killsig:
> // msg is the zero value and ok is false if the channel is closed
>
> The same channel can be shared between many receivers, so it becomes a way
> of broadcasting a kill message.  See https://go.dev/tour/concurrency/4
>
> You should never *send* on a closed channel though - that will cause a
> panic.
>
>
>
>>
>> I am really curious about your example on select -  is it a try... except
>> alternative?
>>
>
> It's not really anything like "try... except".
>
> The "select" statement is specifically for channel communication.  See the
> description in the Go Tour starting here:
> https://go.dev/tour/concurrency/5  # pages 5 and 6
> It picks one branch where a channel is ready to send or receive, or the
> "default" branch if none are.
>
> If you have a series of general conditions that you want to try one by
> one, then there is the "switch" statement:
> https://go.dev/tour/flowcontrol/9   # pages 9 to 11
>
> In most languages "try... except" is an error recovery mechanism which can
> handle unwinding the stack (returning from multiple levels of nested
> function calls).  The nearest equivalent to that in go is panic/recover,
> but that should only be used in very special circumstances.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "golang-nuts" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/golang-nuts/6ExktXrF5Xc/unsubscribe.
> To unsubscribe from this group and all its topics, 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/452795b8-4817-4161-84e7-02665e24ae06n%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/CADEX6_UE4VkNc3gEPRfB046vWYU_%2BcYwUHfSPOCYfrJWJCdypA%40mail.gmail.com.

Re: [go-nuts] zero value for generic types?

[Ian Lance Taylor]

On Wed, Apr 20, 2022 at 3:30 PM Arthur Comte  wrote:
>
> Actually, even with proper error handling, I still need to return a value. In 
> some functions I can just return a variable that was defined in the function, 
> but that is not always available. In those cases, the only solution I've 
> found is to use `*new(E)`, which seems plain terrible. Is there an 
> alternative? I'm guessing something is wrong with my angle

See 
https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#the-zero-value

The easy is verbose way is

var zero E

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/CAOyqgcVv9SuasqrCaJW97bmw%2BCv6Z4afHS6Sv-EUnfJ6HKj6wg%40mail.gmail.com.

Re: [go-nuts] [GoLLVM/gofrontend] Different itab implementation?

[Ian Lance Taylor]

On Wed, Apr 20, 2022 at 6:31 AM Lanzhiguan Huang
 wrote:
>
>   In gc's implementation, the itab struct has an interface type and an object 
> type field and a method table, while in the GoLLVM's implementation, the type 
> descriptor was moved to the first field of the method table. I think they 
> just maintain the same information but do not understand the purposes of the 
> design. Currently the difference may cause incompatibility between the two 
> compilers.

There is no safe way for Go code to ever see these structures, so the
difference should not matter to any ordinary Go programs.

At this point I don't think there is any deep reason for the slightly
different design.  Historically it was because the gc implementation
used a runtime cache, but these days the gofrontend implementation
used by GoLLVM also uses a runtime cache.

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

Re: [go-nuts] zero value for generic types?

[Arthur Comte]

Actually, even with proper error handling, I still need to return a value.
In some functions I can just return a variable that was defined in the
function, but that is not always available. In those cases, the only
solution I've found is to use `*new(E)`, which seems plain terrible. Is
there an alternative? I'm guessing something is wrong with my angle

-- 
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/CAP1AJ8fqT0yxd2g8gctPA%2B6Ei-fKfFQCdDM4iBMtfX%2BS-r9qgg%40mail.gmail.com.

[go-nuts] zero value for generic types?

[Arthur Comte]

Hi! I was trying the following code, but it does not compile. How can I 
check if a generic value is its zero value. More broadly, can you explain 
where this issue comes from?
```go
type MemoryRepository[E identifiable.Identifiable] struct {
  elements []E
}

func (repo MemoryRepository[E]) Find(ID string) (E, error) {
  elem, _ := repo.findWithIndex(ID)
if elem == nil {
  return elem, fmt.Errorf("element with id '%v' does not exist", ID)
}
  return elem, nil
}
```
I should (and will) just use an error to check for proper execution, that 
code was written pretty late in the night!
But now I'm curious about the semantics this code butts against

-- 
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/ab78002f-eba3-46e6-825e-20f56217586en%40googlegroups.com.

Re: [go-nuts] Executing a tar command from within a Go program

['Axel Wagner' via golang-nuts]

On Wed, Apr 20, 2022 at 6:16 PM Dean Schulze 
wrote:

> I need to execute this tar command
>
> *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/*
>
> from within a Go program.  I've verified that it works from the command
> line.  I've tried using
>
>
> *argStr := "xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/"output, err
> := exec.Command("tar", argStr).Output()*
>

You need to pass the args separately, not as one string:
output, err := exec.Command("tar", "xzf", "dir1/dir2/somefile.tgz",
"--directory=dir1/dir2/").Output()
I also tend to set `cmd.Stderr = os.Stderr` to make sure I see error
messages, when executing commands.


>
>
> but it returns an error code of 2 with no other output indicating what is
> wrong.
>
> Using exec.Command(name, arg) is always a guessing game as to what the
> command name should be and what the argument should be.  How do I execute
> this tar command from within Go?
>
> --
> 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/4c4345b7-2155-4bd9-ba61-7a76b5256d2fn%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/CAEkBMfFC_oZz%2BWxu7b4wuaY0GqchK5wUaLVu6AhQ708OmCjOtw%40mail.gmail.com.

Re: [go-nuts] Executing a tar command from within a Go program

['wagner riffel' via golang-nuts]

Also, the Output method only returns what was wrote to stdout, tar
argument parsing errors are probably in stderr, using CombinedOutput()
has better effect to debug.

-- 
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/CJF7P5OFW5I8.2YK5VGDWTSBVV%40pampas.

Re: [go-nuts] Executing a tar command from within a Go program

['wagner riffel' via golang-nuts]

On Wed Apr 20, 2022 at 6:16 PM CEST, Dean Schulze wrote:
> I need to execute this tar command
>
> *tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/*
>

Did you considered using the packages "archive/tar" and
"compress/gzip" to achive this?

> *argStr := "xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/"output, err
> := exec.Command("tar", argStr).Output()*
>

exec.Command arguments are variadic, each argument is one argv, thus I
think you meant exec.Command("tar", "xzf", "dir1/dir2/somefile.tgz",
"--directory=dir1/dir2/")

-w

-- 
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/CJF7II5MD0Y9.2Y2HYXCZ4QDSC%40pampas.

[go-nuts] Executing a tar command from within a Go program

[Dean Schulze]

I need to execute this tar command 

*tar xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/*

from within a Go program.  I've verified that it works from the command 
line.  I've tried using 


*argStr := "xzf dir1/dir2/somefile.tgz --directory=dir1/dir2/"output, err 
:= exec.Command("tar", argStr).Output()*

but it returns an error code of 2 with no other output indicating what is 
wrong.

Using exec.Command(name, arg) is always a guessing game as to what the 
command name should be and what the argument should be.  How do I execute 
this tar command from within Go?

-- 
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/4c4345b7-2155-4bd9-ba61-7a76b5256d2fn%40googlegroups.com.

[go-nuts] [Remote Job] Software Engineer at Expertlead 

['Lilly Ohl' via golang-nuts]

We are looking for a Fullstack Software Engineer with hands-on experience 
with Golang. *Our tech stack: ReactJS, NodeJS, and GoLang*

*Curious? Apply here! 
*

We are looking for a dedicated Software Engineer with both frontend and 
backend knowledge to contribute to our core platform. If you are passionate 
about building strong services that utilize computer science and 
engineering skills like high-performance services, high availability, 
distributed systems, and machine learning to build a state-of-the-art 
system, we would love to talk to you!

Here are the details of the job: 

YOUR MISSION
   
   - Able to code product features with cross-collaboration teams
   - Support designing major components in software, systems, and features 
   by analyzing, designing, developing, and testing deliverables
   - Enhance & support software code
   - Maintain project priorities & deadlines
   - Mentor & guide other team members
   - Participate in growing a healthy collaborative culture in line with 
   the company's vision and values

YOUR SKILLSET
   
   - Bachelors/Masters degree in Computer Science or Engineering or any 
   related field
   - Software development experience in ReactJS, NodeJS, and GoLang
   - Experience with PostgreSQL
   - Comfortable using CI/CD and git
   - Good knowledge in Elasticsearch and ELK stack
   - Experience working in Agile (Scrum) environments
   - Self-motivated, proactive, desire to work in a diverse, collaborative 
   and multi-national team
   - Fluent in English

*WHY EXPERTLEAD*

*Work from anywhere:* We believe in a “hybrid office”, granting you full 
flexibility to work from any country in the world or from our brand new 
office in Berlin Tiergarten/Schöneberg. Our top floor office is right in 
the city centre and comes with a beautiful balcony for some after-work 
beers.

*Learn and develop:* full onboarding plan and a dedicated mentor on your 
side. Full ownership & responsibility from day one and regular feedback 
sessions and career development support to further build on your strengths, 
complemented by a wide range of internal learning and development programs 
and a personal development budget.

*Have fun:* We are a group of very ambitious, but equally down-to-earth 
girls & guys. Teamwork matters most to us and we organize regular team 
events - on- and offline- to stay connected.

*Be who you are:* It’s not about gender, race, religion, age, sexual 
orientation, color, disability, or place of origin. We live diversity and 
cherish our multinational team. At expertlead we consider ourselves as 
equals and create a space everybody feels comfortable and happy to work in.

And yes, we have the obligatory foosball table, a Playstation and a fridge 
that is always full — at least until Friday afternoon ;).

P.S.: Our communication style is pretty much based on memes - so feel free 
to bring in your repertoire ;).

*ABOUT US*

Thank you for your interest in joining us!
At expertlead, we aim to revolutionize tech recruitment by helping 
businesses to find, assess, and hire the right tech experts. We rely on a 
combination of technology and a global community of vetted freelance tech 
talents to support our stakeholders.

The technology we build allows us to find millions of tech 
talents and assess their skills. It is fueled by our freelance community 
that conducts remote technical interviews for us. That way we can provide 
our clients with access to vetted tech freelancers within two days or take 
over the technical assessment of their perm candidates. Our freelancers 
benefit from exciting projects, learning opportunities and a large variety 
of services.

We are proud that leading multinationals like Volkswagen and Accenture as 
well as tech companies like Klarna, Delivery Hero and Babbel trust our 
services.

You have a passion for tech and are ready to rethink the future of work? We 
can’t wait to hear from 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/5302ef69-a851-495d-b127-86c49df584f4n%40googlegroups.com.

[go-nuts] google/gopacket abandoned?

[Matthias Frei]

Hi there,

the github.com/google/gopacket appears to no longer have a maintainer. The 
last commit was about one year ago (29. April 2021), and it appears that 
around the same time the previous maintainer, gconnell, has left Google.
gopacket is used as a dependency in a large-ish number of projects, 3.6k 
according to github's stats. We too use it in our projects, both for 
parsing and generating network packets.

Is there any googler here who would be able to pick this up in some form?

Cheers,
Matthias

-- 
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/66ee4ef0-429b-4422-9e52-35553f5eed89n%40googlegroups.com.

[go-nuts] Re: Interfaces holding integers and memory allocations

[Kyle Nusbaum]

Sorry to revive a dead thread.

I have also been playing with an interpreter and found that increasing the 
size of runtime.staticuint64s helps with the convT64 issue a lot.
https://github.com/golang/go/blob/aa8262d800f0cba2e4d4472a7e344eb60481b0ff/src/runtime/iface.go#L493-L526

I'm guessing that such a small static array is sufficient in most Go 
programs, but in interpreters that are constantly putting integers into 
interfaces, it might be worth wasting a MiB or 2 to cover a larger range.
For me it made a huge difference.

This is only helpful if you're willing to modify Go's runtime package, of 
course.

-- Kyle
On Tuesday, December 22, 2020 at 2:30:55 PM UTC-6 ben...@gmail.com wrote:

> Wow -- yes, that's pretty significant! (Though point taken about "real 
> workloads".) Thanks for sharing this.
>
> On Tuesday, December 22, 2020 at 11:44:25 PM UTC+13 arn...@gmail.com 
> wrote:
>
>> Luckily, I have the "no scalar" version with a build tag.  Here is a 
>> simple benchmark:
>>
>> func BenchmarkValue(b *testing.B) {
>> for n := 0; n < b.N; n++ {
>> sv := IntValue(0)
>> for i := 0; i < 1000; i++ {
>> iv := IntValue(int64(i))
>> sv, _ = add(nil, sv, iv) // add is the "real" lua runtime 
>> function that adds two numeric values.
>> }
>> }
>> }
>>
>> Results with the "scalar" version
>>
>> $ go test -benchmem -run=^$ -bench '^(BenchmarkValue)$' ./runtime
>> goos: darwin
>> goarch: amd64
>> pkg: github.com/arnodel/golua/runtime
>> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
>> BenchmarkValue-8  122995  9494 ns/op   0 
>> B/op  0 allocs/op
>> PASS
>> ok  github.com/arnodel/golua/runtime1.415s
>>
>> Results without the "scalar" version (noscalar build tag)
>>
>> $ go test -benchmem -run=^$ -tags noscalar  -bench '^(BenchmarkValue)$' 
>> ./runtime
>> goos: darwin
>> goarch: amd64
>> pkg: github.com/arnodel/golua/runtime
>> cpu: Intel(R) Core(TM) i7-7820HQ CPU @ 2.90GHz
>> BenchmarkValue-8   37407 32357 ns/op   13768 
>> B/op   1721 allocs/op
>> PASS
>> ok  github.com/arnodel/golua/runtime1.629s
>>
>> That looks like a pretty big improvement :)
>>
>> The improvement is also significant in real workloads but not.so dramatic 
>> (given they don't spend all their time manipulating scalar values!)
>>
>>

-- 
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/7b0f9aef-51d6-40eb-99c6-ec4d9a455a5bn%40googlegroups.com.

[go-nuts] [GoLLVM/gofrontend] Different itab implementation?

[Lanzhiguan Huang]

Hi,
  In gc's implementation, the itab struct has an interface type and an 
object type field and a method table, while in the GoLLVM's implementation, 
the type descriptor was moved to the first field of the method table. I 
think they just maintain the same information but do not understand the 
purposes of the design. Currently the difference may cause incompatibility 
between the two compilers.

-- 
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/99639ad4-ab60-493a-86ae-6f44e75befben%40googlegroups.com.