[go-nuts] no plan9obj.ErrNoSymbols

['Dan Kortschak' via golang-nuts]

The elf package provide a sentinel error, ErrNoSymbols for the case
that Symbols or DynamicSymbols cannot return a symbol list because the
section is empty[1]. The same situation is handled in plan9obj by
returning a new error for this case[2-3]. For PE/Mach-O there is no
issue since access to the symbols is via direct access to a slice
field.

Because of this, it's either necessary to do an error string comparison
or re-call f.Section("syms") to check whether is was nil.

Would a PR to add a package var error reflecting the elf package
approach be acceptable?

thanks
Dan

[1]https://pkg.go.dev/debug/elf@go1.17#pkg-variables
[2]https://pkg.go.dev/debug/plan9obj@go1.17#pkg-variables
[3]
https://cs.opensource.google/go/go/+/refs/tags/go1.17:src/debug/plan9obj/file.go;l=308


-- 
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/9e60500df5d35ce2c732466b331b1d2c521a018d.camel%40kortschak.io.

[go-nuts] Questions about documentation of Go standard library

[Kamil Ziemian]

Hello,

I now need to learn regular expressions for my work and since I can choose 
tool, I decided combine it with learning Go. When documentation of "regexp" 
package (I hope that I use this name correctly) is in most part clear to 
me, one thing is unclear to me. Since, I probably raise many more questions 
about Go standard library, I decided to name it as such.

In the description of function "func CompilePOSIX" 
(https://pkg.go.dev/regexp) we can read.
BEGINNING
That is, when matching against text, the regexp returns a match that begins 
as early as possible in the input (leftmost), and among those it chooses a 
match that is as long as possible. This so-called leftmost-longest matching 
is the same semantics that early regular expression implementations used 
and that POSIX specifies. 
END

Line "early regular expression implementations used and that POSIX 
specifies" is a bit confusing to me. I guess it can mean "old 
implementations Go regexp package", but also very old implementations of 
regular expressions in different languages and systems (?). Can someone 
help me understand this text?

Best
Kamil Ziemian

-- 
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/8e002363-da47-4c43-953f-a66fefc1bcdcn%40googlegroups.com.

[go-nuts] cgo and fatal: morestack on g0

[Miha Vrhovnik]

Hey,

we are using a library via CGO that is the emulator for a real device. 
That library also contains a javascript engine which calls to Go for 
communication to the outside world. The problem we are facing is that we 
are getting more and more crashes with "morestack on g0". 
I have found tickets on the go github (for windows) that show that this 
occurs where go is out of stack. When looking at the gdb bt, the callstack 
doesn't seem so deep. 
And before anyone asks, yes the call stack looks like this  
go->c->c->.->c->go (crash).

The main is locked to the Os thread with runtime.LockOSThread() however 
removing this doesn't help.

Is there any chance of upping up the available stack in CGO cases.

The behavior is the same on 1.16.7 and newly released 1.17.

BR,
Miha

-- 
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/01278325-357b-4ec5-95a2-d126bd38009dn%40googlegroups.com.

Re: [go-nuts] Questions about documentation of Go standard library

[Joshua O'Connor]

Hi,

I read that line as "very old implementations of regular expressions in 
different languages and systems".

And indeed this documentation hasn't changed since Go v1 
(), so I'm pretty sure it means 
that.

In any case I don't think it should affect your usage of the package :)

Joshua

-- 
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/87eeago0fk.fsf%40mail.google.com.

[go-nuts] Re: Questions about documentation of Go standard library

[Volker Dobler]

On Thursday, 26 August 2021 at 13:27:01 UTC+2 kziem...@gmail.com wrote:
 

> Line "early regular expression implementations used and that POSIX 
> specifies" is a bit confusing to me. I guess it can mean "old 
> implementations Go regexp package", 

This guess is wrong. Go's regexp package did and does not change (in that 
respect).
 

> but also very old implementations of regular expressions in different 
> languages and systems (?). 

This is the correct meaning of the sentence.
 
V.

-- 
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/d7fad8f2-3510-4f77-98f0-b28ba6470752n%40googlegroups.com.

[go-nuts] Re: Questions about documentation of Go standard library

[Kamil Ziemian]

Thank you for responses. Indeed, such things don't hamper using of package, 
but are confusing to me and I have already too much confusing thing in my 
work. So, I need no more of them. ;)

Another topic. I needed to check package "math/bits" (learning about Go can 
lead us in such places quite fast) and I'm confused about function "Len(x 
uint) int". In its description we have (https://pkg.go.dev/math/bits@go1.17)
BEGINNING
Len returns the minimum number of bits required to represent x; the result 
is 0 for x == 0.
END
I have no problem with using function that says 0 can be encoded in 0 bits, 
but it is still odd. Maybe it is connected to something done under the 
hood, about which I don't know a thing? Does anyone know why this choose 
was made?

Again, I have no problem with this function (and other realeated functions) 
working in this way. It is just strange thing to me.

PS. This is not about documentation, but about implementation, but I think 
it fit to this topic.

Best
Kamil


czwartek, 26 sierpnia 2021 o 17:04:50 UTC+2 Volker Dobler napisał(a):

> On Thursday, 26 August 2021 at 13:27:01 UTC+2 kziem...@gmail.com wrote:
>  
>
>> Line "early regular expression implementations used and that POSIX 
>> specifies" is a bit confusing to me. I guess it can mean "old 
>> implementations Go regexp package", 
>
> This guess is wrong. Go's regexp package did and does not change (in that 
> respect).
>  
>
>> but also very old implementations of regular expressions in different 
>> languages and systems (?). 
>
> This is the correct meaning of the sentence.
>  
> V.
>

-- 
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/5557ee9d-7487-47df-9045-e42ba6b0f77en%40googlegroups.com.

[go-nuts] Using a local copy of an external package?

[Paul S. R. Chisholm]

Hypothetical example: Say I'm writing an application that uses "rsc.io/quote"
and I discover a bug in that package that breaks my software. I would of
course clone the quote repository, add a test that demonstrates the bug,
fix the bug, and submit a patch to the maintainer.

After making the fix but before submitting the patch, I'd like to first
import my local copy of the quote package to ensure my change prevents the
problem in my application. How could I do that?

Back in the GOPATH days, I could presumably have temporarily used a
relative import path:

https://pkg.go.dev/cmd/go#hdr-Import_path_syntax

I'm not sure how that would work in a post-GOPATH environment. (That page
also talks about programs in a "work space" and not in a "work space."
Apparently "work space" is a technical term in this context, but I don't
know what it means. "go help gopath" doesn't help. What is and isn't a
"work space"?)

Could I clone the quote repository in a vendor/ directory inside my
application directory structure? Are vendor/ directories still used in
post-GOPATH environments, or are they considered deprecated or obsolete?

Thanks. --PSRC

-- 
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/CAG%3D3cj%3Duj8csjJsY45Uk81RLZpwhr1xmtgCWU9L4HLuFvpxOoQ%40mail.gmail.com.

Re: [go-nuts] Using a local copy of an external package?

['Dan Kortschak' via golang-nuts]

On Thu, 2021-08-26 at 18:21 -0400, Paul S. R. Chisholm wrote:
> Hypothetical example: Say I'm writing an application that
> uses "rsc.io/quote" and I discover a bug in that package that breaks
> my software. I would of course clone the quote repository, add a test
> that demonstrates the bug, fix the bug, and submit a patch to the
> maintainer.
>
> After making the fix but before submitting the patch, I'd like to
> first import my local copy of the quote package to ensure my change
> prevents the problem in my application. How could I do that?
>
> Back in the GOPATH days, I could presumably have temporarily used a
> relative import path:
> > https://pkg.go.dev/cmd/go#hdr-Import_path_syntax
>
> I'm not sure how that would work in a post-GOPATH environment. (That
> page also talks about programs in a "work space" and not in a "work
> space." Apparently "work space" is a technical term in this context,
> but I don't know what it means. "go help gopath" doesn't help. What
> is and isn't a "work space"?)
>
> Could I clone the quote repository in a vendor/ directory inside my
> application directory structure? Are vendor/ directories still used
> in post-GOPATH environments, or are they considered deprecated or
> obsolete?
>
> Thanks. --PSRC

Module replace statements will help you here.


https://github.com/golang/go/wiki/Modules#when-should-i-use-the-replace-directive


-- 
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/5d8336f24dc0547c4dd1e5518f598e5f7c44de30.camel%40kortschak.io.

[go-nuts] Re: Questions about documentation of Go standard library

[Volker Dobler]

On Thursday, 26 August 2021 at 22:17:55 UTC+2 kziem...@gmail.com wrote:

> Another topic. I needed to check package "math/bits" (learning about Go 
> can lead us in such places quite fast) and I'm confused about function 
> "Len(x uint) int". In its description we have (
> https://pkg.go.dev/math/bi...@go1.17 
> )
> BEGINNING
> Len returns the minimum number of bits required to represent x; the result 
> is 0 for x == 0.
> END
> I have no problem with using function that says 0 can be encoded in 0 
> bits, but it is still odd. Maybe it is connected to something done under 
> the hood, about which I don't know a thing? Does anyone know why this 
> choose was made?

 
No, the description doesn't say that 0 can be encoded in 0 bits:
It says that Len(0) returns 0.
If you want Len to be a total function you must return a value for every 
input.
For most inputs the value is strictly determined by what the functions does
(number of bits needed to represent), so Len(9) == 3. But how many bits
do you need to represent 0? The question is malformed as there are no 
set bits in the used representation of 0. One could have declared
"Len(0) returns -42"
but this makes no sense at all. Having Len(0)==0 results in
Len(a) <= Len(b) if a < b without having to invent totally arbitrary
values for Len(0).

You probably should not overinterpret Go's documentation.
This is not lyric. "the result is 0 for x == 0" has no hidden meaning.

V.

-- 
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/e6f03535-5fd6-44b4-a866-0382aa13483bn%40googlegroups.com.