Re: [go-nuts] Generic "nillable" constraint

['Axel Wagner' via golang-nuts]

On Wed, Oct 18, 2023 at 6:09 AM Jon Watte  wrote:

> Circling back to this, because it came up today again.
>
> Here's the generic function I want to write. It comes up in a lot of
> function composition, which in turn comes up in a lot of interface adapters
> and such:
>
> func maybeAssign[T any](dst *T, src T, name string) {
> if *dst != nil { // any can't be compared with nil
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
>
> Using this function in each assignment, instead of inlining the four-line
> construct with panic, can save a lot of space and make code a lot more
> readable.
> The above doesn't work, because not every type can be assigned nil.
> The following also doesn't work:
>
> func maybeAssign[T comparable](dst *T, src T, name string) {
> var zero T
> if *dst != zero { // interface and other nillable types can't be
> compared to zero
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
>
> Because interface values aren't comparable. (As aren't chans, maps, etc,
> but THOSE can be jammed into various interface constructs, whereas "any
> interface" cannot, because "interface{}" doesn't actually mean "any
> interface")
>
> Let me try to answer:
>
> > Why is the *specific* split into (interfaces, pointers, slices,
> functions, maps, channels) and (numbers, booleans, strings, structs,
> arrays) a particularly important one?
>
> Because, while go tries very hard to make sure every storable type has a
> "zero value," it somehow decides that you can't necessarily COMPARE to that
> zero value.
> But the whole point of zero values is that you can tell them from non-zero
> values!
> So, the language has introduced a work-around with the concept of "I can
> compare to nil" for these reference types that aren't comparable to their
> zero value.
> But generics don't allow us to sense or make use of this, so generics
> can't express what the regular language can express. Even a very simple
> case like the above, can't currently be expressed, and this leads to more
> verbose code that's harder to read and harder to work with. (Granted, this
> is my opinion, but I'm not alone.)
>

That does not actually answer the question, though. Again, note that your
problem would be solved both by #61372
 (you could write `if *dst !=
zero`) and by #62487  (you could
just write `if *dst != nil`), neither of which require you to make a
distinction between "nilable" types and "non-nilable" types. In fact, it
would make your `maybeAssign` function worse - it would be less general,
because it could only be used with a subset of types and it's not clear why
that subset is a good one.

(also, nit: channels are comparable)

If the language instead changes so that nil means "the zero value" in
> general, and it so happens that these nil-comparable types can be compared
> to nil without any particular qualification, that also solves the problem.
>

Right. That is what my question was getting at.


> That might indeed be a good solution -- but if so, it'd be nice to know
> what we can do to make that happen, and what the other opposition to that
> change might be, because that change also feels much less narrow than a
> "nil" type constraint.
>

Being "less narrow" can mean two things: It can mean "it is a more general
solution" and it can mean "it is a bigger change". The two proposals above
are a similarly big change, that are more general in the kinds of problems
they solve. So they seem better.


>
>
> Sincerely,
>
> Jon Watte
>
>
> --
> "I find that the harder I work, the more luck I seem to have." -- Thomas
> Jefferson
>
>
> On Tue, Oct 3, 2023 at 10:41 PM Axel Wagner 
> wrote:
>
>> Oh (sorry, being forgetful) and re "it's less of a new mechanism than
>> introducing a zero identifier": #62487
>>  introduces *even less* new
>> mechanism, by expanding comparison to (and assignment of) `nil` to all
>> types inside a generic function. It's not a new class of constraint, it
>> just special-cases `nil` a bit more. So it is still a far more general
>> mechanism, that solves more problems than `nilable` constraint, while
>> requiring fewer (or at worst the same number of) new concepts.
>>
>> On Wed, Oct 4, 2023 at 7:36 AM Axel Wagner 
>> wrote:
>>
>>> (correction: It should be Convert[J isinterface, T J]. I changed the
>>> name from I to J to be more readable and then missed one occurrence)
>>>
>>> On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner <
>>> axel.wagner...@googlemail.com> wrote:
>>>
 On Wed, Oct 4, 2023 at 6:54 AM Jon Watte  wrote:

> > where it is important to permit only type arguments that can be
> compared to nil
>
> I see! As in, if we somehow got a "equalszero" constraint, then that
> constraint would solve the problem I illustrate.
> I believe that assertion is correct, but I 

Re: [go-nuts] Generic "nillable" constraint

[Bakul Shah]

I'd happy with

if val { ... }

and

if !val { ... }

Instead of comparing val with an explicit zero but don't feel strongly about 
this.

> On Oct 17, 2023, at 9:09 PM, Jon Watte  wrote:
> 
> Circling back to this, because it came up today again.
> 
> Here's the generic function I want to write. It comes up in a lot of function 
> composition, which in turn comes up in a lot of interface adapters and such:
> 
> func maybeAssign[T any](dst *T, src T, name string) {
> if *dst != nil { // any can't be compared with nil
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
> 
> Using this function in each assignment, instead of inlining the four-line 
> construct with panic, can save a lot of space and make code a lot more 
> readable.
> The above doesn't work, because not every type can be assigned nil.
> The following also doesn't work:
> 
> func maybeAssign[T comparable](dst *T, src T, name string) {
> var zero T
> if *dst != zero { // interface and other nillable types can't be compared 
> to zero
> panic(fmt.Errorf("too many %s arguments", name))
> }
> *dst = src
> }
> 
> Because interface values aren't comparable. (As aren't chans, maps, etc, but 
> THOSE can be jammed into various interface constructs, whereas "any 
> interface" cannot, because "interface{}" doesn't actually mean "any 
> interface")
> 
> Let me try to answer:
> 
> > Why is the specific split into (interfaces, pointers, slices, functions, 
> > maps, channels) and (numbers, booleans, strings, structs, arrays) a 
> > particularly important one?
> 
> Because, while go tries very hard to make sure every storable type has a 
> "zero value," it somehow decides that you can't necessarily COMPARE to that 
> zero value.
> But the whole point of zero values is that you can tell them from non-zero 
> values!
> So, the language has introduced a work-around with the concept of "I can 
> compare to nil" for these reference types that aren't comparable to their 
> zero value.
> But generics don't allow us to sense or make use of this, so generics can't 
> express what the regular language can express. Even a very simple case like 
> the above, can't currently be expressed, and this leads to more verbose code 
> that's harder to read and harder to work with. (Granted, this is my opinion, 
> but I'm not alone.)
> 
> If the language instead changes such that chans and interfaces and maps 
> become comparable, then that's fine -- that solves the problem! But that 
> seems like a much bigger change than a constraint that senses exactly the 
> "can compare to nil" semantic.
> 
> If the language instead changes so that nil means "the zero value" in 
> general, and it so happens that these nil-comparable types can be compared to 
> nil without any particular qualification, that also solves the problem. That 
> might indeed be a good solution -- but if so, it'd be nice to know what we 
> can do to make that happen, and what the other opposition to that change 
> might be, because that change also feels much less narrow than a "nil" type 
> constraint.
> 
> 
> Sincerely,
> 
> Jon Watte
> 
> 
> --
> "I find that the harder I work, the more luck I seem to have." -- Thomas 
> Jefferson
> 
> 
> On Tue, Oct 3, 2023 at 10:41 PM Axel Wagner  > wrote:
>> Oh (sorry, being forgetful) and re "it's less of a new mechanism than 
>> introducing a zero identifier": #62487 
>>  introduces even less new 
>> mechanism, by expanding comparison to (and assignment of) `nil` to all types 
>> inside a generic function. It's not a new class of constraint, it just 
>> special-cases `nil` a bit more. So it is still a far more general mechanism, 
>> that solves more problems than `nilable` constraint, while requiring fewer 
>> (or at worst the same number of) new concepts.
>> 
>> On Wed, Oct 4, 2023 at 7:36 AM Axel Wagner > > wrote:
>>> (correction: It should be Convert[J isinterface, T J]. I changed the name 
>>> from I to J to be more readable and then missed one occurrence)
>>> 
>>> On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner >> > wrote:
 On Wed, Oct 4, 2023 at 6:54 AM Jon Watte >>> > wrote:
> > where it is important to permit only type arguments that can be 
> > compared to nil
> 
> I see! As in, if we somehow got a "equalszero" constraint, then that 
> constraint would solve the problem I illustrate.
> I believe that assertion is correct, but I also believe that is a 
> stronger assertion, and also that it introduces more of a new concept 
> than a simple "nil" constraint. (Unless you're looking for some way to 
> make "any" work, and introduce a zero keyword or something...)
 
 Yes, that is what #61372  proposes: Introduce 
 a `zero` predeclared 

Re: [go-nuts] Generic "nillable" constraint

[Jon Watte]

Circling back to this, because it came up today again.

Here's the generic function I want to write. It comes up in a lot of
function composition, which in turn comes up in a lot of interface adapters
and such:

func maybeAssign[T any](dst *T, src T, name string) {
if *dst != nil { // any can't be compared with nil
panic(fmt.Errorf("too many %s arguments", name))
}
*dst = src
}

Using this function in each assignment, instead of inlining the four-line
construct with panic, can save a lot of space and make code a lot more
readable.
The above doesn't work, because not every type can be assigned nil.
The following also doesn't work:

func maybeAssign[T comparable](dst *T, src T, name string) {
var zero T
if *dst != zero { // interface and other nillable types can't be
compared to zero
panic(fmt.Errorf("too many %s arguments", name))
}
*dst = src
}

Because interface values aren't comparable. (As aren't chans, maps, etc,
but THOSE can be jammed into various interface constructs, whereas "any
interface" cannot, because "interface{}" doesn't actually mean "any
interface")

Let me try to answer:

> Why is the *specific* split into (interfaces, pointers, slices,
functions, maps, channels) and (numbers, booleans, strings, structs,
arrays) a particularly important one?

Because, while go tries very hard to make sure every storable type has a
"zero value," it somehow decides that you can't necessarily COMPARE to that
zero value.
But the whole point of zero values is that you can tell them from non-zero
values!
So, the language has introduced a work-around with the concept of "I can
compare to nil" for these reference types that aren't comparable to their
zero value.
But generics don't allow us to sense or make use of this, so generics can't
express what the regular language can express. Even a very simple case like
the above, can't currently be expressed, and this leads to more verbose
code that's harder to read and harder to work with. (Granted, this is my
opinion, but I'm not alone.)

If the language instead changes such that chans and interfaces and maps
become comparable, then that's fine -- that solves the problem! But that
seems like a much bigger change than a constraint that senses exactly the
"can compare to nil" semantic.

If the language instead changes so that nil means "the zero value" in
general, and it so happens that these nil-comparable types can be compared
to nil without any particular qualification, that also solves the problem.
That might indeed be a good solution -- but if so, it'd be nice to know
what we can do to make that happen, and what the other opposition to that
change might be, because that change also feels much less narrow than a
"nil" type constraint.


Sincerely,

Jon Watte


--
"I find that the harder I work, the more luck I seem to have." -- Thomas
Jefferson


On Tue, Oct 3, 2023 at 10:41 PM Axel Wagner 
wrote:

> Oh (sorry, being forgetful) and re "it's less of a new mechanism than
> introducing a zero identifier": #62487
>  introduces *even less* new
> mechanism, by expanding comparison to (and assignment of) `nil` to all
> types inside a generic function. It's not a new class of constraint, it
> just special-cases `nil` a bit more. So it is still a far more general
> mechanism, that solves more problems than `nilable` constraint, while
> requiring fewer (or at worst the same number of) new concepts.
>
> On Wed, Oct 4, 2023 at 7:36 AM Axel Wagner 
> wrote:
>
>> (correction: It should be Convert[J isinterface, T J]. I changed the name
>> from I to J to be more readable and then missed one occurrence)
>>
>> On Wed, Oct 4, 2023 at 7:33 AM Axel Wagner 
>> wrote:
>>
>>> On Wed, Oct 4, 2023 at 6:54 AM Jon Watte  wrote:
>>>
 > where it is important to permit only type arguments that can be
 compared to nil

 I see! As in, if we somehow got a "equalszero" constraint, then that
 constraint would solve the problem I illustrate.
 I believe that assertion is correct, but I also believe that is a
 stronger assertion, and also that it introduces more of a new concept than
 a simple "nil" constraint. (Unless you're looking for some way to make
 "any" work, and introduce a zero keyword or something...)

>>>
>>> Yes, that is what #61372  proposes:
>>> Introduce a `zero` predeclared identifier (!) that is assignable to any
>>> type and comparable to any type. With some discussion about whether it
>>> should only apply inside generic code or not. There is no proposal (as far
>>> as I know) for anything like an "equalszero" constraint, as every type can
>>> be assigned a meaningful comparison to its zero value, so it seems we
>>> should just allow it for all types.
>>>
>>> To be clear, the criticism of a `nilable` constraint is
>>> 1. It only solves a subset of the problem we are seeing. You gave
>>> examples from that subset. I gave some 

[go-nuts] Re: go list fails, how do I clear "-mod=readonly"

[Pat Farrell]

yes, thanks
I updated to the latest go and no longer get the error

I'm not sure I understand the output that I'm getting now, but that
is a subject for more research on my par
On Monday, October 16, 2023 at 5:12:41 PM UTC-4 Jason Phillips wrote:

> I believe the fixes have already been released. Go 1.21 was released in 
> August and there have been 5 point releases to 1.20 since your version 
> (1.20.5) was released. Have you tried updating your Go toolchain?
>
> On Monday, October 16, 2023 at 4:21:11 PM UTC-4 Pat Farrell wrote:
>
>> yes that is it.
>>  I see that there is a patch that will be in the next release.
>>
>> Anyone know of a workaround until then?
>>
>> thanks
>>
>>

-- 
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/6fec2e17-d3d6-4908-b5eb-6df6ae48a7dan%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Justin Israel]

On Wednesday, October 18, 2023 at 3:12:29 AM UTC+13 Marc-Antoine Ruel wrote:

Sorry I wasn't clear. The static libraries are in a subdirectory because 
the user should not care and these libraries are effectively third party 
code.


Actually, you were totally clear. Sorry if my comment didn't make sense. I 
get that the user doesn't need to worry about the third_party directory 
with the header and pre-built static libraries. And I saw how you arrange 
to pick up the right ones in the code. My point was that from previous 
experience, "go get" would prune away directories that do not contain go 
source code, after it performs the clone from the remote, into the module 
cache. So I would have expected that when someone uses your library as a 
dependency, it would have omitted the needed third_party directory, for not 
having any Go source files in it. But when I tested it just now, it does 
seem to retain the subdirectory and link correctly. Maybe this was improved 
as of recent Go releases. 
In earlier versions of the Go tool, I would have either included a dummy Go 
source file in the subdirectory, or just kept the non-go files in the root 
with the rest of the Go source.
Maybe someone else can clarify if this workflow has been improved?


This declares the generic code available everywhere:
https://github.com/periph/d2xx/blob/main/d2xx.go

One set of files declare the import that is OS and CPU arch appropriate, 
e.g. 
https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go

Then another set of two files defines the OS specific code. In practice, 
POSIX and windows;
https://github.com/periph/d2xx/blob/main/d2xx_posix.go
https://github.com/periph/d2xx/blob/main/d2xx_windows.go

A CGO_ENABLED=0 build gets instead redirected to
https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
but not on windows because this package uses dynamic linking on windows. 
Adapt as appropriate in your use case.

I hope this helps.

M-A


Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a écrit :



On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:

I second Richard's suggestion. I used the same trick for 
https://github.com/periph/d2xx. This git repository contains a minimalist 
shim for the .a libraries and nothing else. It's designed to compile on any 
platform. It falls back to a scaffolding if the corresponding .a library is 
not present for the OS-arch combination or if CGO is disabled. It makes 
testing easier.

Then a proper package under https://github.com/periph/host/tree/main/ftdi 
exposes a higher level abstraction for the user.


With only headers and static libs in the thirdparty directory, is this 
package "go-gettable"? 
Will go make the subdirectory available in that case? It usually ignores if 
there is no Go source files. 
 

M-A

Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a 
écrit :

Hi Jan,

I'm going to go out on a limb here and suggest looking at using Go's 
`embed` feature?

https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/

I have not tried it with C libraries so there may be numerous reasons why 
it may not work for your needs. For example, I do not know what is required 
to *"install"* the libraries so that might be your sticking point that 
embed would not address. But if building on the user's machine is the real 
problem and you can distribute pre-build binaries then this might work for 
you.  

Basically Go reads a `//go:embed` comment, converts your files into Go 
source code, compiles that code, and then provides a package that allows 
you to write those files to disk from an your Go app before you need to 
load the libraries.

Maybe this will work for you?  If yes, would love to hear back how it 
worked out.

-Mike
On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:

I guess you switched things here. Shared libraries (.so) need to be 
available at engine. Static libraries (.a) are bagged into the binary.

-Bruno


On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:

Thanks Tamas, this is useful information. 

One of my libraries is using a `.a` library -- as opposed to `.so`, which 
is another level of complexity, since the library has to be available in 
runtime, not only in compile time -- and I'm going to follow your 
"incantation" suggestion.


On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:

Neither I see a convenient way.
BUT if you add a .go file into the directories where your precompiled 
libraries live,
then "go get" will download them too (and only those dirs that have .go 
files in it).

So your next mission is to prepare the right #cgo CFLAGS LDFLAGS 
incantations to use those libraries.

Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):

Thanks Tamás, I may not be understanding correctly, but after taking a look 
at github.com/godror/godror, and the odpi subdirectory,
I see it is including all the `.c` files on the fly 

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

[Volker Dobler]

On Tuesday, 17 October 2023 at 14:40:47 UTC+2 Christopher C wrote:

I was thinking partial reads could be an issue 

In what regards are "partial reads" less well covered by io.ReadAll
than via json.Decoder?
 

and the Decoder seemed to do the initial checking for me. Would the 
ReadAll() be able to recover from EOF state?


io.ReadAll cannot "recover" from EOF just like an Decoder cannot.
This EOF is smth that happens during _reading_ and both, io.ReadAll
and json.Decoder do the actual read via identical methods.

If your io.Reader allows reading up to EOF and than reading
more (no idea how this is going to happen, but let's assume
your underlying Reader somehow allows this) then it doesn't
matter.

io.ReadAll reads until EOF, forget about "partial reads".
Decoding can be done on the read stuff. I think this is
clearer.
Once your io.Reader signals EOF you have to find some
way to read more (???) or reset the Reader and this has
nothing to do with _how_ you read from that Reader.

V.


On Tuesday, October 17, 2023 at 4:37:58 AM UTC-4 Volker Dobler wrote:

Why do you use a json.Decoder? It seems as reading
everything (io.ReadAll) until EOF and json.Unmarshal'ling
would be a cleaner/simpler solution?

V.

On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote:

Hello all!
I'm trying to read json objects from a named pipe.  The pipe will be  
filled intermittently by bash scripts.  After the Decode() of the first 
object, any more calls to Decode() will return EOF.  This seems proper 
since the script has completed, but once it errors with EOF, there doesn't 
seem to be a way to read any more.

Is there a way to 'reset' the decoder so when another script writes to the 
pipe it can process the next object, or should I be doing some pipe length 
validation before trying to decode?

Current read code snippet  is...

decoder := json.NewDecoder(fpipe)
for {
err := decoder.Decode()
if err != nil {
if err == io.EOF {
// how to reset this?
} else {
logger.Fatal(err)
}
} else {
// send out the msg

-- 
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/a418fd99-e618-4b78-a2a8-aff2158f0c70n%40googlegroups.com.

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

['Brian Candler' via golang-nuts]

Are you sure that the writer isn't closing the named pipe between writing 
JSON objects? If necessary you can check this with strace.

I'm pretty sure you'll get an EOF in the *reader* when the *writer* closes 
from their side. You can demonstrate this with the shell:

(In terminal 1)
mkfifo /tmp/fifo
cat /tmp/fifo

(In terminal 2)
cat >/tmp/fifo
abcd
efgh
<< wait a while >>
^D

When you hit ^D in terminal 2, the cat in terminal 1 ends.

The solution (or as you asked, "how to reset this?") is simply to re-open 
the fifo for reading.

On Tuesday, 17 October 2023 at 13:40:47 UTC+1 Christopher C wrote:

> I was thinking partial reads could be an issue and the Decoder seemed to 
> do the initial checking for me. Would the ReadAll() be able to recover from 
> EOF state?
>
> On Tuesday, October 17, 2023 at 4:37:58 AM UTC-4 Volker Dobler wrote:
>
>> Why do you use a json.Decoder? It seems as reading
>> everything (io.ReadAll) until EOF and json.Unmarshal'ling
>> would be a cleaner/simpler solution?
>>
>> V.
>>
>> On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote:
>>
>>> Hello all!
>>> I'm trying to read json objects from a named pipe.  The pipe will be  
>>> filled intermittently by bash scripts.  After the Decode() of the first 
>>> object, any more calls to Decode() will return EOF.  This seems proper 
>>> since the script has completed, but once it errors with EOF, there doesn't 
>>> seem to be a way to read any more.
>>>
>>> Is there a way to 'reset' the decoder so when another script writes to 
>>> the pipe it can process the next object, or should I be doing some pipe 
>>> length validation before trying to decode?
>>>
>>> Current read code snippet  is...
>>>
>>> decoder := json.NewDecoder(fpipe)
>>> for {
>>> err := decoder.Decode()
>>> if err != nil {
>>> if err == io.EOF {
>>> // how to reset this?
>>> } else {
>>> logger.Fatal(err)
>>> }
>>> } else {
>>> // send out the msg
>>>
>>>

-- 
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/75667b50-9eaf-4721-b3a4-75f023be753fn%40googlegroups.com.

Re: [go-nuts] Re: Recommended way to distribute pre-compiled C-dependencies for modules using CGO ?

[Marc-Antoine Ruel]

Sorry I wasn't clear. The static libraries are in a subdirectory because
the user should not care and these libraries are effectively third party
code.

This declares the generic code available everywhere:
https://github.com/periph/d2xx/blob/main/d2xx.go

One set of files declare the import that is OS and CPU arch appropriate,
e.g.
https://github.com/periph/d2xx/blob/main/d2xx_linux_amd64.go

Then another set of two files defines the OS specific code. In practice,
POSIX and windows;
https://github.com/periph/d2xx/blob/main/d2xx_posix.go
https://github.com/periph/d2xx/blob/main/d2xx_windows.go

A CGO_ENABLED=0 build gets instead redirected to
https://github.com/periph/d2xx/blob/main/d2xx_posix_no_cgo.go
but not on windows because this package uses dynamic linking on windows.
Adapt as appropriate in your use case.

I hope this helps.

M-A


Le lun. 16 oct. 2023, 21 h 13, Justin Israel  a
écrit :

>
>
> On Tuesday, October 17, 2023 at 10:40:33 AM UTC+13 Marc-Antoine Ruel wrote:
>
> I second Richard's suggestion. I used the same trick for
> https://github.com/periph/d2xx. This git repository contains a minimalist
> shim for the .a libraries and nothing else. It's designed to compile on any
> platform. It falls back to a scaffolding if the corresponding .a library is
> not present for the OS-arch combination or if CGO is disabled. It makes
> testing easier.
>
> Then a proper package under https://github.com/periph/host/tree/main/ftdi
> exposes a higher level abstraction for the user.
>
>
> With only headers and static libs in the thirdparty directory, is this
> package "go-gettable"?
> Will go make the subdirectory available in that case? It usually ignores
> if there is no Go source files.
>
>
> M-A
>
> Le lun. 16 oct. 2023, à 14 h 48, Mike Schinkel  a
> écrit :
>
> Hi Jan,
>
> I'm going to go out on a limb here and suggest looking at using Go's
> `embed` feature?
>
> https://blog.jetbrains.com/go/2021/06/09/how-to-use-go-embed-in-go-1-16/
>
> I have not tried it with C libraries so there may be numerous reasons why
> it may not work for your needs. For example, I do not know what is required
> to *"install"* the libraries so that might be your sticking point that
> embed would not address. But if building on the user's machine is the real
> problem and you can distribute pre-build binaries then this might work for
> you.
>
> Basically Go reads a `//go:embed` comment, converts your files into Go
> source code, compiles that code, and then provides a package that allows
> you to write those files to disk from an your Go app before you need to
> load the libraries.
>
> Maybe this will work for you?  If yes, would love to hear back how it
> worked out.
>
> -Mike
> On Monday, October 16, 2023 at 8:40:54 AM UTC-4 Bruno Albuquerque wrote:
>
> I guess you switched things here. Shared libraries (.so) need to be
> available at engine. Static libraries (.a) are bagged into the binary.
>
> -Bruno
>
>
> On Sun, Oct 15, 2023, 3:55 PM Jan  wrote:
>
> Thanks Tamas, this is useful information.
>
> One of my libraries is using a `.a` library -- as opposed to `.so`, which
> is another level of complexity, since the library has to be available in
> runtime, not only in compile time -- and I'm going to follow your
> "incantation" suggestion.
>
>
> On Sunday, October 15, 2023 at 7:55:55 AM UTC+2 Tamás Gulácsi wrote:
>
> Neither I see a convenient way.
> BUT if you add a .go file into the directories where your precompiled
> libraries live,
> then "go get" will download them too (and only those dirs that have .go
> files in it).
>
> So your next mission is to prepare the right #cgo CFLAGS LDFLAGS
> incantations to use those libraries.
>
> Jan a következőt írta (2023. október 14., szombat, 8:37:48 UTC+2):
>
> Thanks Tamás, I may not be understanding correctly, but after taking a
> look at github.com/godror/godror, and the odpi subdirectory,
> I see it is including all the `.c` files on the fly
> .
>
> A couple of reasons immediately come to mind, that make this not a
> generically valid option:
>
> * ODPI library is all C code (see src
> ) so it works
> including in Go: my dependencies are C++/Rust code, for which I write a
> small C wrapper (or for Rust just `extern "C"`). Also architecture
> dependent compilation is different in C++/C/Rust code ...
> * The C++ libraries I'm including have sub-dependencies of themselves (one
> of which is llvm). It uses Bazel to organize it, and to manually move all
> the required C++ files to a directory would be years of work :) Plus would
> require me to slave to maintain things in sync.
> * The C++ libraries take hours to compile ... I don't want to impose this
> to users of my libraries.
>
> I think the only way to work this out is distributing the pre-compiled
> C++/Rust libraries, so the Go simply refer to them (and we get the fast
> compilation times from Go). But then, how to 

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

[Christopher C]

I was thinking partial reads could be an issue and the Decoder seemed to do 
the initial checking for me. Would the ReadAll() be able to recover from 
EOF state?

On Tuesday, October 17, 2023 at 4:37:58 AM UTC-4 Volker Dobler wrote:

> Why do you use a json.Decoder? It seems as reading
> everything (io.ReadAll) until EOF and json.Unmarshal'ling
> would be a cleaner/simpler solution?
>
> V.
>
> On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote:
>
>> Hello all!
>> I'm trying to read json objects from a named pipe.  The pipe will be  
>> filled intermittently by bash scripts.  After the Decode() of the first 
>> object, any more calls to Decode() will return EOF.  This seems proper 
>> since the script has completed, but once it errors with EOF, there doesn't 
>> seem to be a way to read any more.
>>
>> Is there a way to 'reset' the decoder so when another script writes to 
>> the pipe it can process the next object, or should I be doing some pipe 
>> length validation before trying to decode?
>>
>> Current read code snippet  is...
>>
>> decoder := json.NewDecoder(fpipe)
>> for {
>> err := decoder.Decode()
>> if err != nil {
>> if err == io.EOF {
>> // how to reset this?
>> } else {
>> logger.Fatal(err)
>> }
>> } else {
>> // send out the msg
>>
>>

-- 
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/8446c446-2113-4c65-bf3c-5a7f84c601dcn%40googlegroups.com.

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

['Axel Wagner' via golang-nuts]

It is not "meant for tests internal to the http package". It's meant for
tests of users of the `net/http` package. That is, implementations of the
`http.Handler` interface.
In the context of the standard library, that is what "general purpose HTTP
testing" means.

On Tue, Oct 17, 2023 at 10:44 AM Simon Walter  wrote:

> It is good practice to use test lang/tools/libs/etc different from what
> you are using in your actual code.
>
> If the author has meant for the httptest package as general purpose HTTP
> testing library, then, I will argue that such defaults are incorrect. It is
> incorrect even if the intended purpose is to tests code that is derived
> from http package.
>
> If the author has meant for the httptest package to be used for tests
> internal to the http package, then it should be labeled such.
>
> I'll mention this to bradf...@golang.org.
> On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:
>
>> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a
>> 200 status code if no explicit WriteHeader call is made is documented:
>> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
>> I really think it is a bad (or at least strange) idea to claim to
>> implement `http.ResponseWriter` while *not* replicating this behavior.
>>
>> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner 
>> wrote:
>>
>>> It seems to me that the fact that the functions accept and return types
>>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given
>>> that it's nested below `net/http` should make it fairly obvious that it's
>>> meant to be used with `net/http`. I also genuinely don't understand what
>>> the intersection is of "being tempted to use `httptest`" and "does not
>>> intend to be used with `net/http`". I also genuinely don't understand how
>>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>>
>>> But, YMMV, of course and you are free to roll your own testing helpers.
>>>
>>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>>
 Axel, thanks for providing some context.

 I suppose it is better for me to think of the httptest package as
 specific to the http package - although this is not explicitly stated:
 "Package httptest provides utilities for HTTP testing"

 This seems misleading as is the case with this '200' default.

 I stopped using httptest.NewRecorder() because of the possibility to
 introduce changes to tests that would make tests pass. Not everyone knows
 the internals of all the code. Because of this, I think it is risky to have
 values set by default to the value that causes the test to pass.

 Some questions that should not keep us awake at night: The test passed,
 but will it fail? Will it fail where/how I think it will?

 Simon

 On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:

> If you want to argue that `net/http` should not set the response code
> to 200 by default, I would be inclined to agree. I don't particularly like
> that the API even *allows* you not to explicitly set a response code. But
> it does. And while it does, the best test is one that matches the behavior
> of the production environment as closely as possible, full stop.
>
> Another way to look at it: Why do you believe you have to test that
> your handler sets the response code to 200? Why should the test fail, if 
> it
> doesn't do it - given that *the production code* will still end up with 
> the
> right response code? If the response sent to the user is the right one -
> why would it matter whether it was your Handler that set it, or the
> framework?
>
> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter 
> wrote:
>
>> How does that explain why it is a good idea?
>>
>> Perhaps my concern is not clear enough.
>>
>> For example:
>>
>> n := 5
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> This is not a good test.
>>
>> I can check if the value has changed by:
>>
>> n := 0
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> That's a bit more sensible.
>>
>> Wouldn't it be less risky for a test to fail by default? Removal of
>> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>
>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>
>>> A default `net/http` server also uses 200 as the default response
>>> code. The behavior of an `http.Handler` not setting a response code 
>>> should
>>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>>
>>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter 
>>> wrote:
>>>
 Hi all,

 What is the reason that ResponseRecorder HTTP status code defaults
 to 200?

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

And so: https://github.com/golang/go/issues/63589

On Tuesday, October 17, 2023 at 10:44:04 AM UTC+2 Simon Walter wrote:

> It is good practice to use test lang/tools/libs/etc different from what 
> you are using in your actual code.
>
> If the author has meant for the httptest package as general purpose HTTP 
> testing library, then, I will argue that such defaults are incorrect. It is 
> incorrect even if the intended purpose is to tests code that is derived 
> from http package.
>
> If the author has meant for the httptest package to be used for tests 
> internal to the http package, then it should be labeled such.
>
> I'll mention this to brad...@golang.org.
> On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:
>
>> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 
>> 200 status code if no explicit WriteHeader call is made is documented:
>> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
>> I really think it is a bad (or at least strange) idea to claim to 
>> implement `http.ResponseWriter` while *not* replicating this behavior.
>>
>> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner  
>> wrote:
>>
>>> It seems to me that the fact that the functions accept and return types 
>>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given 
>>> that it's nested below `net/http` should make it fairly obvious that it's 
>>> meant to be used with `net/http`. I also genuinely don't understand what 
>>> the intersection is of "being tempted to use `httptest`" and "does not 
>>> intend to be used with `net/http`". I also genuinely don't understand how 
>>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>>
>>> But, YMMV, of course and you are free to roll your own testing helpers.
>>>
>>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>>
 Axel, thanks for providing some context.

 I suppose it is better for me to think of the httptest package as 
 specific to the http package - although this is not explicitly stated: 
 "Package httptest provides utilities for HTTP testing"

 This seems misleading as is the case with this '200' default.

 I stopped using httptest.NewRecorder() because of the possibility to 
 introduce changes to tests that would make tests pass. Not everyone knows 
 the internals of all the code. Because of this, I think it is risky to 
 have 
 values set by default to the value that causes the test to pass.

 Some questions that should not keep us awake at night: The test passed, 
 but will it fail? Will it fail where/how I think it will?

 Simon

 On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:

> If you want to argue that `net/http` should not set the response code 
> to 200 by default, I would be inclined to agree. I don't particularly 
> like 
> that the API even *allows* you not to explicitly set a response code. But 
> it does. And while it does, the best test is one that matches the 
> behavior 
> of the production environment as closely as possible, full stop.
>
> Another way to look at it: Why do you believe you have to test that 
> your handler sets the response code to 200? Why should the test fail, if 
> it 
> doesn't do it - given that *the production code* will still end up with 
> the 
> right response code? If the response sent to the user is the right one - 
> why would it matter whether it was your Handler that set it, or the 
> framework?
>
> On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  
> wrote:
>
>> How does that explain why it is a good idea?
>>
>> Perhaps my concern is not clear enough.
>>
>> For example:
>>
>> n := 5
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> This is not a good test.
>>
>> I can check if the value has changed by:
>>
>> n := 0
>> funcThatShouldSetNtoFive()
>> if n != 5 {
>>   panic("n is not 5)
>> }
>>
>> That's a bit more sensible.
>>
>> Wouldn't it be less risky for a test to fail by default? Removal of 
>> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>>
>> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>>
>>> A default `net/http` server also uses 200 as the default response 
>>> code. The behavior of an `http.Handler` not setting a response code 
>>> should 
>>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>>
>>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  
>>> wrote:
>>>
 Hi all,

 What is the reason that ResponseRecorder HTTP status code defaults 
 to 200?


 

Re: [go-nuts] ResponseRecorder HTTP status code defaults to 200

[Simon Walter]

It is good practice to use test lang/tools/libs/etc different from what you 
are using in your actual code.

If the author has meant for the httptest package as general purpose HTTP 
testing library, then, I will argue that such defaults are incorrect. It is 
incorrect even if the intended purpose is to tests code that is derived 
from http package.

If the author has meant for the httptest package to be used for tests 
internal to the http package, then it should be labeled such.

I'll mention this to bradf...@golang.org.
On Monday, October 16, 2023 at 4:58:16 PM UTC+2 Axel Wagner wrote:

> To be clear: The behavior of an `http.ResponseWriter` to implicitly use a 
> 200 status code if no explicit WriteHeader call is made is documented:
> https://pkg.go.dev/net/http#ResponseWriter.WriteHeader
> I really think it is a bad (or at least strange) idea to claim to 
> implement `http.ResponseWriter` while *not* replicating this behavior.
>
> On Mon, Oct 16, 2023 at 4:53 PM Axel Wagner  
> wrote:
>
>> It seems to me that the fact that the functions accept and return types 
>> from `net/http` (like `http.ResponseWriter` and `http.Handler`) and given 
>> that it's nested below `net/http` should make it fairly obvious that it's 
>> meant to be used with `net/http`. I also genuinely don't understand what 
>> the intersection is of "being tempted to use `httptest`" and "does not 
>> intend to be used with `net/http`". I also genuinely don't understand how 
>> the behavior of `httptest` could ever cause any harm (quite the opposite).
>>
>> But, YMMV, of course and you are free to roll your own testing helpers.
>>
>> On Mon, Oct 16, 2023 at 9:30 AM Simon Walter  wrote:
>>
>>> Axel, thanks for providing some context.
>>>
>>> I suppose it is better for me to think of the httptest package as 
>>> specific to the http package - although this is not explicitly stated: 
>>> "Package httptest provides utilities for HTTP testing"
>>>
>>> This seems misleading as is the case with this '200' default.
>>>
>>> I stopped using httptest.NewRecorder() because of the possibility to 
>>> introduce changes to tests that would make tests pass. Not everyone knows 
>>> the internals of all the code. Because of this, I think it is risky to have 
>>> values set by default to the value that causes the test to pass.
>>>
>>> Some questions that should not keep us awake at night: The test passed, 
>>> but will it fail? Will it fail where/how I think it will?
>>>
>>> Simon
>>>
>>> On Monday, October 16, 2023 at 6:16:41 AM UTC+2 Axel Wagner wrote:
>>>
 If you want to argue that `net/http` should not set the response code 
 to 200 by default, I would be inclined to agree. I don't particularly like 
 that the API even *allows* you not to explicitly set a response code. But 
 it does. And while it does, the best test is one that matches the behavior 
 of the production environment as closely as possible, full stop.

 Another way to look at it: Why do you believe you have to test that 
 your handler sets the response code to 200? Why should the test fail, if 
 it 
 doesn't do it - given that *the production code* will still end up with 
 the 
 right response code? If the response sent to the user is the right one - 
 why would it matter whether it was your Handler that set it, or the 
 framework?

 On Sun, Oct 15, 2023 at 10:22 PM Simon Walter  
 wrote:

> How does that explain why it is a good idea?
>
> Perhaps my concern is not clear enough.
>
> For example:
>
> n := 5
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> This is not a good test.
>
> I can check if the value has changed by:
>
> n := 0
> funcThatShouldSetNtoFive()
> if n != 5 {
>   panic("n is not 5)
> }
>
> That's a bit more sensible.
>
> Wouldn't it be less risky for a test to fail by default? Removal of 
> the call to funcThatShouldSetNtoFive, IMO, should result in failure.
>
> On Sunday, October 15, 2023 at 6:10:36 PM UTC+2 Axel Wagner wrote:
>
>> A default `net/http` server also uses 200 as the default response 
>> code. The behavior of an `http.Handler` not setting a response code 
>> should 
>> be the same, if it uses `httptest`, as if it uses `net/http`.
>>
>> On Sun, Oct 15, 2023 at 5:17 PM Simon Walter  
>> wrote:
>>
>>> Hi all,
>>>
>>> What is the reason that ResponseRecorder HTTP status code defaults 
>>> to 200?
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=55
>>>
>>>
>>> https://cs.opensource.google/go/go/+/refs/tags/go1.21.3:src/net/http/httptest/recorder.go;drc=ff14e844d26090e09aa335d836f737c09a7a0402;l=196
>>>
>>> Can someone explain to me why this is a good idea? Would it not make 

[go-nuts] Re: Handling EOF when using json.NewDecoder() from named pipe

[Volker Dobler]

Why do you use a json.Decoder? It seems as reading
everything (io.ReadAll) until EOF and json.Unmarshal'ling
would be a cleaner/simpler solution?

V.

On Tuesday, 17 October 2023 at 09:10:09 UTC+2 Christopher C wrote:

> Hello all!
> I'm trying to read json objects from a named pipe.  The pipe will be  
> filled intermittently by bash scripts.  After the Decode() of the first 
> object, any more calls to Decode() will return EOF.  This seems proper 
> since the script has completed, but once it errors with EOF, there doesn't 
> seem to be a way to read any more.
>
> Is there a way to 'reset' the decoder so when another script writes to the 
> pipe it can process the next object, or should I be doing some pipe length 
> validation before trying to decode?
>
> Current read code snippet  is...
>
> decoder := json.NewDecoder(fpipe)
> for {
> err := decoder.Decode()
> if err != nil {
> if err == io.EOF {
> // how to reset this?
> } else {
> logger.Fatal(err)
> }
> } else {
> // send out the msg
>
>

-- 
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/0cb1918d-2eb9-41e1-86f0-8cd02e6a0113n%40googlegroups.com.

[go-nuts] Handling EOF when using json.NewDecoder() from named pipe

[Christopher C]

Hello all!
I'm trying to read json objects from a named pipe.  The pipe will be  
filled intermittently by bash scripts.  After the Decode() of the first 
object, any more calls to Decode() will return EOF.  This seems proper 
since the script has completed, but once it errors with EOF, there doesn't 
seem to be a way to read any more.

Is there a way to 'reset' the decoder so when another script writes to the 
pipe it can process the next object, or should I be doing some pipe length 
validation before trying to decode?

Current read code snippet  is...

decoder := json.NewDecoder(fpipe)
for {
err := decoder.Decode()
if err != nil {
if err == io.EOF {
// how to reset this?
} else {
logger.Fatal(err)
}
} else {
// send out the msg

-- 
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/0846d26b-8cd3-4d1f-bebb-9972ea248c30n%40googlegroups.com.