Re: [go-nuts] generics question

2024-04-23 Thread Jochen Voss
Thank you both!

This works, see my code below.  Followup question: is there a way to refer 
to the new type without having to list both the element type and the 
pointer type separately?  Below I have to write C[A, *A], which looks 
slightly ugly.  And in my real application something like Creator 
OrderedArray[ProperName] would look much more readable than Creator 
OrderedArray[ProperName, *ProperName] .

Many thanks,
Jochen

type Type interface{}

type Settable[E Type] interface {
*E
Set(int)
}

type C[E any, P Settable[E]] struct {
Val []E
}

func (c *C[E, P]) Set(v int) {
for i := range c.Val {
var ptr P = &(c.Val[i])
ptr.Set(v)
}
}

var c = C[A, *A]{Val: []A{1, 2, 3}}

On Tuesday 23 April 2024 at 03:36:25 UTC+1 Nagaev Boris wrote:

> On Mon, Apr 22, 2024 at 9:54 PM Ian Lance Taylor  wrote:
> >
> > On Mon, Apr 22, 2024 at 2:25 PM Jochen Voss  wrote:
> > >
> > > Using generics, can I somehow write a constraint which says that *T 
> (instead of T) implements a certain interface? The following code 
> illustrated what I'm trying to do:
> > >
> > > type A int
> > >
> > > func (a *A) Set(x int) {
> > > *a = A(x)
> > > }
> > >
> > > type B string
> > >
> > > func (b *B) Set(x int) {
> > > *b = B(strconv.Itoa(x))
> > > }
> > >
> > > type C1 struct {
> > > Val []A
> > > }
> > >
> > > func (c *C1) Set(v int) {
> > > for i := range c.Val {
> > > c.Val[i].Set(v)
> > > }
> > > }
> > >
> > > type C2 struct {
> > > Val []B
> > > }
> > >
> > > func (c *C2) Set(v int) {
> > > for i := range c.Val {
> > > c.Val[i].Set(v)
> > > }
> > > }
> > >
> > > I would like to use generics to use a single definition for the 
> methods which here are func (c *C1) Set(v int) and func (c *C2) Set(v int). 
> (My real code has many base types, instead of just A and B.) How can I do 
> this?
> > >
> > > I tried the naive approach:
> > >
> > > type C[T interface{ Set(int) }] struct {
> > > Val []T
> > > }
> > >
> > > but when I try to use the type C[A] now, I get the error message "A 
> does not satisfy interface{Set(int)} (method Set has pointer receiver)".
> >
> >
> > type C[P interface {
> > *E
> > Set(int)
> > }, E any] struct {
> > Val []P
> > }
> >
> > Ian
> >
>
> I think it should be this (s/Val []P/Val []E/):
>
> type C[P interface {
> *E
> Set(int)
> }, E any] struct {
> Val []E
> }
>
>
>
> -- 
> Best regards,
> Boris Nagaev
>

-- 
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/c5571d6c-d4d1-4cb9-9617-d5405f68d66an%40googlegroups.com.


[go-nuts] generics question

2024-04-22 Thread Jochen Voss
Using generics, can I somehow write a constraint which says that *T 
(instead of T) implements a certain interface?  The following code 
illustrated what I'm trying to do:

type A int

func (a *A) Set(x int) {
*a = A(x)
}

type B string

func (b *B) Set(x int) {
*b = B(strconv.Itoa(x))
}

type C1 struct {
Val []A
}

func (c *C1) Set(v int) {
for i := range c.Val {
c.Val[i].Set(v)
}
}

type C2 struct {
Val []B
}

func (c *C2) Set(v int) {
for i := range c.Val {
c.Val[i].Set(v)
}
}

I would like to use generics to use a single definition for the methods 
which here are func (c *C1) Set(v int) and func (c *C2) Set(v int).  (My 
real code has many base types, instead of just A and B.)  How can I do this?

I tried the naive approach:

type C[T interface{ Set(int) }] struct {
Val []T
}

but when I try to use the type C[A] now, I get the error message "A does 
not satisfy interface{Set(int)} (method Set has pointer receiver)".

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e6c1647a-9ade-496e-85b5-0e96563b5e22n%40googlegroups.com.


[go-nuts] Re: heap profiling does not work on M2 MacBook air?

2024-01-27 Thread Jochen Voss
I've now filed https://github.com/golang/go/issues/65328 to report this.

On Friday 3 March 2023 at 09:47:26 UTC Jochen Voss wrote:

> Hi Peter,
>
> Thanks again for looking into this, and for your help!
>
> You mention that the blog post was long ago.  I wonder whether the code to 
> write profile information is covered by the compatibility promise.  If so, 
> probably the legacy WriteHeapProfile function could be made to implement 
> the required code to keep this working.  Should a bug report be filed to 
> this effect? 
>
> Similarly, should a bug report be filed about the mistake you found in the 
> pprof package documentation?
>
> All the best,
> Jochen
> On Thursday, 2 March 2023 at 15:36:24 UTC peterGo wrote:
>
>> On Thursday, March 2, 2023 at 2:03:22 AM UTC-5 Jochen Voss wrote:
>>
>> Hi Peter,
>>
>> Thanks a lot, giving the "-alloc_space" option makes all the difference!  
>> With this option, it also works for me.
>>
>> I wonder whether it meant to be the way that you have to give this 
>> option.  Maybe something broke?  In the blog entry 
>> https://go.dev/blog/pprof they didn't need this option to get the 
>> profile output.
>>
>>
>> The Go blog post at https://go.dev/blog/pprof was written in 2011; it is 
>> now 2023. For up-to-date information, see the latest pprof package 
>> documentation at https://pkg.go.dev/runtime/pprof@latest.
>>
>> The pprof package documentation is incorrect: 
>>
>> To add equivalent [go test] profiling support to a standalone program, 
>> add code like the following to your main function:
>>
>> // ...
>> runtime.GC() // get up-to-date statistics
>> if err := pprof.WriteHeapProfile(f); err != nil {
>> log.Fatal("could not write memory profile: ", err)
>> }
>> // ...
>>
>> To obtain equivalent results, replace the above code with:
>>
>> // ...
>> runtime.GC() // get up-to-date statistics
>> if allocs := pprof.Lookup("allocs"); allocs == nil {
>> log.Fatal("could not lookup memory profile: ")
>> } else if err := allocs.WriteTo(f, 0); err != nil {
>>
>> log.Fatal("could not write memory profile: ", err)
>> }
>> // ...
>>
>> For your example,
>>
>> yyy.go: https://go.dev/play/p/epy4c3et1Io
>>
>> $ go build yyy.go && ./yyy
>> $ go tool pprof mem.prof
>> File: yyy
>> Type: alloc_space
>> Time: Mar 2, 2023 at 10:02am (EST)
>>
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top
>> Showing nodes accounting for 6975.42MB, 98.93% of 7050.77MB total
>> Dropped 62 nodes (cum <= 35.25MB)
>>
>> Showing top 10 nodes out of 18
>>   flat  flat%   sum%cum   cum%
>>  3564.88MB 50.56% 50.56%  3564.88MB 50.56%  
>> golang.org/x/exp/slices.Insert[.. 
>> <http://golang.org/x/exp/slices.Insert%5B..>.] (inline)
>>  3122.14MB 44.28% 94.84%  3122.14MB 44.28%  
>> seehuhn.de/go/layout.(*Skip).Minus
>>   117.01MB  1.66% 96.50%   117.01MB  1.66%  
>> seehuhn.de/go/layout.(*Skip).Clone (inline)
>>   115.51MB  1.64% 98.14%  6919.54MB 98.14%  
>> seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
>>52.89MB  0.75% 98.89%65.63MB  0.93%  compress/flate.NewWriter
>> 2.50MB 0.035% 98.92%  6926.54MB 98.24%  
>> seehuhn.de/go/layout.(*Engine).EndParagraph
>> 0.50MB 0.0071% 98.93%  7050.27MB   100%  main.main
>>  0 0% 98.93%65.63MB  0.93%  compress/flate.NewWriterDict
>>  0 0% 98.93%65.63MB  0.93%  compress/zlib.(*Writer).Write
>>  0 0% 98.93%65.63MB  0.93% 
>>  compress/zlib.(*Writer).writeHeader
>> (pprof) quit
>> $ 
>>
>> Peter
>>
>>

-- 
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/52a65cdb-afee-4101-9602-42c0d17a3088n%40googlegroups.com.


Re: [go-nuts] weblist in go tool pprof does not work for me

2023-09-27 Thread Jochen Voss
On 26 Sep 2023, at 6:20, Sergey Gorlov wrote:
> Did you find a solution to this problem? I have the same problem with
> weblist.

No, I didn't.  I think it's just broken.  If I find time, I'll submit a bug 
report (unless somebody beats me to it).

All the best,
Jochen
--
http://seehuhn.de/

-- 
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/C56812A9-7A5C-44DB-9061-985F18B3029C%40gmail.com.


[go-nuts] (minor) broken link in the Go 1.21 release notes.

2023-08-16 Thread Jochen Voss
Hello,

Not really important, but there is a somewhat broken link in the Go 1.21 
release notes.  The introduction says "See “Go versions” in the “Go 
Toolchains” documentation for details", and this links to

https://go.dev/doc/toolchain#versions

The link goes to the beginning of the page, not to the intended section, 
because "versions" is a typo.  The correct link is

https://go.dev/doc/toolchain#version

(without the trailing "s").  Not sure if this is worth fixing, but if 
anybody feels so inclined, the extra "s" could be removed to make the link 
work.

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5ccd2caa-1e26-4573-8c83-55c541266ea4n%40googlegroups.com.


[go-nuts] failed fuzz tests not reproducible when re-run

2023-08-02 Thread Jochen Voss
Dear all,

Recently I find quite often that after "go test -fuzz" reported an error, 
the command shown to re-run the test does not reproduce the failure.  For 
example, just now I got the following:

voss@dumpling [..nt/tounicode2] go test -fuzz FuzzToUnicode
fuzz: elapsed: 0s, gathering baseline coverage: 0/2 completed
fuzz: elapsed: 0s, gathering baseline coverage: 2/2 completed, now fuzzing 
with 10 workers
fuzz: elapsed: 3s, execs: 280461 (93481/sec), new interesting: 24 (total: 
26)
fuzz: elapsed: 5s, execs: 410320 (72348/sec), new interesting: 60 (total: 
62)
--- FAIL: FuzzToUnicode (4.80s)
--- FAIL: FuzzToUnicode (0.00s)
tounicode_test.go:129: template: tounicode:26:2: executing 
"tounicode" at : error calling Single: runtime error: integer 
divide by zero

Failing input written to testdata/fuzz/FuzzToUnicode/2566873a28045c1b
To re-run:
go test -run=FuzzToUnicode/2566873a28045c1b
FAIL
exit status 1
FAIL seehuhn.de/go/pdf/font/tounicode2 4.957s
voss@dumpling [..nt/tounicode2] go test -run=FuzzToUnicode/2566873a28045c1b
PASS
ok   seehuhn.de/go/pdf/font/tounicode2 0.122s

The fuzzer reported a failure, and when I re-run the test I get a "PASS".

How to debug such a problem?

I understand that my fuzz function may somehow be non-deterministic, but so 
far I have not found any cause of non-determinism and re-running the test 
10 times gives me 10 passes.  Also, for a bug the fuzzer reported earlier, 
I found it very hard to believe that the given input could make the fuzz 
function reach the site of the error message.  Could it be that the fuzzer 
sometimes looses track of which input belongs to which fuzzing run, and 
then reports the wrong input?

If somebody wants to play with this, here is how to reproduce (up to 
randomness) the fuzzing run shown above:

 git clone https://github.com/seehuhn/go-pdf.git
 cd go-pdf/
 git reset --hard 26c235ad
 cd font/tounicode2/
 go test -fuzz FuzzToUnicode

Any suggestions on how to debug such errors would be most welcome.

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3fe3725b-e59e-4b1f-a2e9-0f28c15ea3d4n%40googlegroups.com.


[go-nuts] Re: testing whether two maps are the same object

2023-07-18 Thread Jochen Voss
Thanks Jason, I get your point about DeepEqual now :)

On Tuesday, 18 July 2023 at 16:52:51 UTC+1 Jason Phillips wrote:

> Also note: reflect.DeepEqual doesn't *just* compare the contents of the 
> map. It only compares contents if the maps aren't "the same map object". 
> From the documentation:
>
> > Map values are deeply equal when all of the following are true: they are 
> both nil or both non-nil, they have the same length, and either they are 
> the same map object or their corresponding keys (matched using Go equality) 
> map to deeply equal values.
>
> Comparing if they're "the same map object" is done in the way described 
> earlier, which seems exactly what you're looking for.
>
> On Tuesday, July 18, 2023 at 11:44:53 AM UTC-4 Jason Phillips wrote:
>
>> reflect.Value.UnsafePointer() is probably not safer than using unsafe 
>> directly, assuming you're using unsafe in a way that doesn't break the 
>> rules. Reflect is doing effectively the same unsafe.Pointer conversion 
>> under the hood [1]. It's certainly easier on the eyes, in my opinion, 
>> though.
>>
>> [1] - 
>> https://cs.opensource.google/go/go/+/refs/tags/go1.20.6:src/reflect/value.go;l=103
>>
>> On Tuesday, July 18, 2023 at 11:25:42 AM UTC-4 Stephen Illingworth wrote:
>>
>>>
>>> I like that. I think it's is quite a smart way of doing it,
>>>
>>> I don't think you need to check both maps when choosing a key. Once 
>>> you've found a candidate key in one map, you can test the other map and if 
>>> it *does* exist then the two maps aren't equal. You've then saved the 
>>> insertion and deletion step. I would also prefer to use rand.Int() rather 
>>> than a linear search. 
>>>
>>> https://go.dev/play/p/ftBGgQMuvvC
>>>
>>>
>>> On Tuesday, 18 July 2023 at 15:35:38 UTC+1 Jochen Voss wrote:
>>>
>>>> Dear all,
>>>>
>>>> To implement the "eq" operator in a simple PostScript interpreter, I 
>>>> need to determine whether two maps are the same object.
>>>>
>>>> This can be done by adding a new element to one map, and checking 
>>>> whether the new entry also appears in the second map, but as you can 
>>>> imagine, the resulting code is quite ugly.  See 
>>>> https://go.dev/play/p/AfembYDt3en for an implementation of this idea.
>>>>
>>>> Is there a better way?
>>>>
>>>> Many thanks,
>>>> Jochen
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c8b9aac5-6a53-472f-9c5d-497a23575a79n%40googlegroups.com.


Re: [go-nuts] testing whether two maps are the same object

2023-07-18 Thread Jochen Voss
Dear Jason,

Thanks for the idea of using reflect.  Do you know whether 
`reflect.ValueOf(a).UnsafePointer()` is somehow "safer" than 
`*(*uintptr)(unsafe.Pointer())`?

reflect.DeepEqual will not work, since it just compares contents of the 
maps: https://go.dev/play/p/tE_qZI2cKEd

All the best,
Jochen
On Tuesday, 18 July 2023 at 15:52:24 UTC+1 Jason Phillips wrote:

> You can also use the reflect package rather than (directly) reaching for 
> unsafe. The reflect.DeepEqual function does something along the lines of: 
> https://go.dev/play/p/IVt0Z-mxugh
>
> On Tuesday, July 18, 2023 at 10:45:18 AM UTC-4 Jan Mercl wrote:
>
>> On Tue, Jul 18, 2023 at 4:35 PM Jochen Voss  wrote: 
>>
>> > Is there a better way? 
>>
>> I have never been here and please don't do this: 
>> https://go.dev/play/p/x4QYJubXMnQ 
>>
>

-- 
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/30202b52-554e-462e-aaa4-dfe7f4d23554n%40googlegroups.com.


[go-nuts] testing whether two maps are the same object

2023-07-18 Thread Jochen Voss
Dear all,

To implement the "eq" operator in a simple PostScript interpreter, I need 
to determine whether two maps are the same object.

This can be done by adding a new element to one map, and checking whether 
the new entry also appears in the second map, but as you can imagine, the 
resulting code is quite ugly.  See https://go.dev/play/p/AfembYDt3en for an 
implementation of this idea.

Is there a better way?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9f5e5eb6-faee-4918-9a7f-e441ac15ecadn%40googlegroups.com.


[go-nuts] Re: finding the call graph of a method

2023-04-19 Thread Jochen Voss
Ah, found it!  If I write types.NewPointer(reader.Type()) instead of just 
reader.Type(), things work better.

On Tuesday, 18 April 2023 at 20:34:30 UTC+1 Jochen Voss wrote:

> Dear all,
>
> I'm trying to find the callgraph of a method, using the following code:
>
> package main
>
> import (
> "log"
>
> "golang.org/x/tools/go/callgraph"
> "golang.org/x/tools/go/packages"
> "golang.org/x/tools/go/ssa/ssautil"
> )
>
> func main() {
> cfg := {Mode: packages.LoadSyntax}
> initial, err := packages.Load(cfg, "seehuhn.de/go/pdf")
> if err != nil {
> log.Fatal(err)
> } else if packages.PrintErrors(initial) > 0 {
> log.Fatalf("packages contain errors")
> }
>
> prog, pkgs := ssautil.Packages(initial, 0)
> if len(pkgs) != 1 {
> log.Fatalf("expected 1 package, got %d", len(pkgs))
> }
> pkg := pkgs[0]
> pkg.Build()
>
> reader := pkg.Members["Reader"]
>
> f := prog.LookupMethod(reader.Type(), pkg.Pkg, "readXRef")
> g := callgraph.New(f)
> _ = g
> }
>
> (Also on the playgound at https://go.dev/play/p/_S-oKAJ6YNO, but 
> resulting in some fancy error messages there.)
>
> This fails with the following error message: panic: 
> seehuhn.de/go/pdf.Reader has no method seehuhn.de/go/pdf.readXRef
>
> What am I doing wrong?
>
> All the best,
> Jochen
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/c128c8fb-bb40-4cbe-86a1-f6da0c88a78bn%40googlegroups.com.


[go-nuts] finding the call graph of a method

2023-04-18 Thread Jochen Voss
Dear all,

I'm trying to find the callgraph of a method, using the following code:

package main

import (
"log"

"golang.org/x/tools/go/callgraph"
"golang.org/x/tools/go/packages"
"golang.org/x/tools/go/ssa/ssautil"
)

func main() {
cfg := {Mode: packages.LoadSyntax}
initial, err := packages.Load(cfg, "seehuhn.de/go/pdf")
if err != nil {
log.Fatal(err)
} else if packages.PrintErrors(initial) > 0 {
log.Fatalf("packages contain errors")
}

prog, pkgs := ssautil.Packages(initial, 0)
if len(pkgs) != 1 {
log.Fatalf("expected 1 package, got %d", len(pkgs))
}
pkg := pkgs[0]
pkg.Build()

reader := pkg.Members["Reader"]

f := prog.LookupMethod(reader.Type(), pkg.Pkg, "readXRef")
g := callgraph.New(f)
_ = g
}

(Also on the playgound at https://go.dev/play/p/_S-oKAJ6YNO, but resulting 
in some fancy error messages there.)

This fails with the following error message: panic: 
seehuhn.de/go/pdf.Reader has no method seehuhn.de/go/pdf.readXRef

What am I doing wrong?

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/68b8c937-7bce-44d4-81fb-2507b55fb0bcn%40googlegroups.com.


Re: [go-nuts] getting the size of an io.ReaderAt?

2023-04-01 Thread Jochen Voss
Dear Bruno,

Thanks for your answer.  Originally I had a separate size argument for the 
function which opens a new reader, something like this:

func NewReader(data io.ReaderAt, size int64, opt *ReaderOptions) 
(*Reader, error)

But this makes it a bit annoying to create a reader for a file, because you 
always need the additional Stat() call before, and also it looks a bit 
weird, I though.  So my idea was to move the code for checking the size 
into the function, and to simplify the API:

func NewReader(data io.ReaderAt, opt *ReaderOptions) (*Reader, error)

This way the library does the work once, rather than every caller having to 
do this separately.

All the best,
Jochen

On Friday, 31 March 2023 at 21:38:04 UTC+1 Bruno Albuquerque wrote:

> Not a direct answer to your question (your code looks like a reasonable 
> implementation modulo any bugs I did not notice) but: Aren't you over 
> engineering things? If the source is a PDF file, why not also pass the size 
> to the function instead of doing all this work to get it? At some point you 
> have to open the file, right? And checking the size of a file is trivial 
> (it is just a stat call) and then you do not need to do that.
>
>
> On Fri, Mar 31, 2023 at 4:30 PM Jochen Voss  wrote:
>
>> Dear all,
>>
>> I am trying to get the size of an io.ReaderAt, i.e. the offset after 
>> which no more data can be read.  I have some working (?) code (
>> https://go.dev/play/p/wTouYbaJ7RG , also reproduced below), but I am not 
>> sure whether what I do is correct and the best way to do this.  Some 
>> questions:
>>
>>- Does the standard library provide a way to get the size of an 
>>io,ReaderAt?
>>- Is my code correct?
>>- Is there a better way to do this?
>>- If a type provides not only a ReadAt() method, but also a Size() 
>>method, would it be save to assume that Size() returns how many bytes are 
>>accessible via ReadAt()?  This seems to work for bytes.Reader and 
>>strings.Reader,  but there may be types out there where Size() does 
>>something different?
>>- If ReadAt(p, x) returns io.EOF for an offset x, is it then 
>>guaranteed that then ReadAt(p, y) also returns io.EOF for all y > x?  
>>Or could there be different error messages, or "files with holes", or 
>>whatnot?
>>- Which types in the standard library provide ReadAt methods?  I know 
>>of os.File, strings.Reader, and bytes.Reader.  Any others?
>>
>> For context: this is for reading the cross reference table of PDF files, 
>> which have to be located by following some convoluted route starting *from 
>> the end* of the PDF file.
>>
>> Many thanks,
>> Jochen
>>
>> func getSize(r io.ReaderAt) (int64, error) {
>> if f, ok := r.(*os.File); ok {
>> fi, err := f.Stat()
>> if err != nil {
>> return 0, err
>> }
>> return fi.Size(), nil
>> }
>> if b, ok := r.(*bytes.Reader); ok {
>> return int64(b.Size()), nil
>> }
>> if s, ok := r.(*strings.Reader); ok {
>> return int64(s.Size()), nil
>> }
>>
>> buf := make([]byte, 1024)
>> n, err := r.ReadAt(buf, 0)
>> if err == io.EOF {
>> return int64(n), nil
>> } else if err != nil {
>> return 0, err
>> }
>>
>> lowerBound := int64(n) // all bytes before lowerBound are known to be 
>> present
>> var upperBound int64   // at least one byte before upperBound is known to 
>> be missing
>> for {
>> test := 2 * lowerBound
>> _, err := r.ReadAt(buf[:1], test-1)
>> if err == io.EOF {
>> upperBound = test
>> break
>> } else if err != nil {
>> return 0, err
>> }
>> lowerBound = test
>> }
>>
>> for lowerBound+1 < upperBound {
>> test := (lowerBound + upperBound + 1) / 2
>> _, err := r.ReadAt(buf[:1], test-1)
>> if err == io.EOF {
>> upperBound = test
>> } else if err != nil {
>> return 0, err
>> } else {
>> lowerBound = test
>> }
>> }
>> return lowerBound, nil
>> }
>>
>> -- 
>> 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...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/aa604ac0-3542-4a9e-adef-a9eaecfd8170n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/aa604ac0-3542-4a9e-adef-a9eaecfd8170n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1be784af-63e5-4238-bd96-ef3123318d68n%40googlegroups.com.


[go-nuts] getting the size of an io.ReaderAt?

2023-03-31 Thread Jochen Voss
Dear all,

I am trying to get the size of an io.ReaderAt, i.e. the offset after which 
no more data can be read.  I have some working (?) code 
(https://go.dev/play/p/wTouYbaJ7RG , also reproduced below), but I am not 
sure whether what I do is correct and the best way to do this.  Some 
questions:

   - Does the standard library provide a way to get the size of an 
   io,ReaderAt?
   - Is my code correct?
   - Is there a better way to do this?
   - If a type provides not only a ReadAt() method, but also a Size() 
   method, would it be save to assume that Size() returns how many bytes are 
   accessible via ReadAt()?  This seems to work for bytes.Reader and 
   strings.Reader,  but there may be types out there where Size() does 
   something different?
   - If ReadAt(p, x) returns io.EOF for an offset x, is it then guaranteed 
   that then ReadAt(p, y) also returns io.EOF for all y > x?  Or could 
   there be different error messages, or "files with holes", or whatnot?
   - Which types in the standard library provide ReadAt methods?  I know of 
   os.File, strings.Reader, and bytes.Reader.  Any others?

For context: this is for reading the cross reference table of PDF files, 
which have to be located by following some convoluted route starting *from 
the end* of the PDF file.

Many thanks,
Jochen

func getSize(r io.ReaderAt) (int64, error) {
if f, ok := r.(*os.File); ok {
fi, err := f.Stat()
if err != nil {
return 0, err
}
return fi.Size(), nil
}
if b, ok := r.(*bytes.Reader); ok {
return int64(b.Size()), nil
}
if s, ok := r.(*strings.Reader); ok {
return int64(s.Size()), nil
}

buf := make([]byte, 1024)
n, err := r.ReadAt(buf, 0)
if err == io.EOF {
return int64(n), nil
} else if err != nil {
return 0, err
}

lowerBound := int64(n) // all bytes before lowerBound are known to be 
present
var upperBound int64   // at least one byte before upperBound is known to 
be missing
for {
test := 2 * lowerBound
_, err := r.ReadAt(buf[:1], test-1)
if err == io.EOF {
upperBound = test
break
} else if err != nil {
return 0, err
}
lowerBound = test
}

for lowerBound+1 < upperBound {
test := (lowerBound + upperBound + 1) / 2
_, err := r.ReadAt(buf[:1], test-1)
if err == io.EOF {
upperBound = test
} else if err != nil {
return 0, err
} else {
lowerBound = test
}
}
return lowerBound, nil
}

-- 
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/aa604ac0-3542-4a9e-adef-a9eaecfd8170n%40googlegroups.com.


[go-nuts] Re: heap profiling does not work on M2 MacBook air?

2023-03-03 Thread Jochen Voss
Hi Peter,

Thanks again for looking into this, and for your help!

You mention that the blog post was long ago.  I wonder whether the code to 
write profile information is covered by the compatibility promise.  If so, 
probably the legacy WriteHeapProfile function could be made to implement 
the required code to keep this working.  Should a bug report be filed to 
this effect? 

Similarly, should a bug report be filed about the mistake you found in the 
pprof package documentation?

All the best,
Jochen
On Thursday, 2 March 2023 at 15:36:24 UTC peterGo wrote:

> On Thursday, March 2, 2023 at 2:03:22 AM UTC-5 Jochen Voss wrote:
>
> Hi Peter,
>
> Thanks a lot, giving the "-alloc_space" option makes all the difference!  
> With this option, it also works for me.
>
> I wonder whether it meant to be the way that you have to give this 
> option.  Maybe something broke?  In the blog entry 
> https://go.dev/blog/pprof they didn't need this option to get the profile 
> output.
>
>
> The Go blog post at https://go.dev/blog/pprof was written in 2011; it is 
> now 2023. For up-to-date information, see the latest pprof package 
> documentation at https://pkg.go.dev/runtime/pprof@latest.
>
> The pprof package documentation is incorrect: 
>
> To add equivalent [go test] profiling support to a standalone program, add 
> code like the following to your main function:
>
> // ...
> runtime.GC() // get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> log.Fatal("could not write memory profile: ", err)
> }
> // ...
>
> To obtain equivalent results, replace the above code with:
>
> // ...
> runtime.GC() // get up-to-date statistics
> if allocs := pprof.Lookup("allocs"); allocs == nil {
> log.Fatal("could not lookup memory profile: ")
> } else if err := allocs.WriteTo(f, 0); err != nil {
>
> log.Fatal("could not write memory profile: ", err)
> }
> // ...
>
> For your example,
>
> yyy.go: https://go.dev/play/p/epy4c3et1Io
>
> $ go build yyy.go && ./yyy
> $ go tool pprof mem.prof
> File: yyy
> Type: alloc_space
> Time: Mar 2, 2023 at 10:02am (EST)
>
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top
> Showing nodes accounting for 6975.42MB, 98.93% of 7050.77MB total
> Dropped 62 nodes (cum <= 35.25MB)
>
> Showing top 10 nodes out of 18
>   flat  flat%   sum%cum   cum%
>  3564.88MB 50.56% 50.56%  3564.88MB 50.56%  
> golang.org/x/exp/slices.Insert[.. 
> <http://golang.org/x/exp/slices.Insert%5B..>.] (inline)
>  3122.14MB 44.28% 94.84%  3122.14MB 44.28%  
> seehuhn.de/go/layout.(*Skip).Minus
>   117.01MB  1.66% 96.50%   117.01MB  1.66%  
> seehuhn.de/go/layout.(*Skip).Clone (inline)
>   115.51MB  1.64% 98.14%  6919.54MB 98.14%  
> seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
>52.89MB  0.75% 98.89%65.63MB  0.93%  compress/flate.NewWriter
> 2.50MB 0.035% 98.92%  6926.54MB 98.24%  
> seehuhn.de/go/layout.(*Engine).EndParagraph
> 0.50MB 0.0071% 98.93%  7050.27MB   100%  main.main
>  0 0% 98.93%65.63MB  0.93%  compress/flate.NewWriterDict
>  0 0% 98.93%65.63MB  0.93%  compress/zlib.(*Writer).Write
>  0 0% 98.93%65.63MB  0.93% 
>  compress/zlib.(*Writer).writeHeader
> (pprof) quit
> $ 
>
> Peter
>
>

-- 
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/a06065fb-ae57-4c52-b182-b444e9e32bcdn%40googlegroups.com.


[go-nuts] Re: heap profiling does not work on M2 MacBook air?

2023-03-01 Thread Jochen Voss
Hi Peter,

Thanks a lot, giving the "-alloc_space" option makes all the difference!  
With this option, it also works for me.

I wonder whether it meant to be the way that you have to give this option.  
Maybe something broke?  In the blog entry https://go.dev/blog/pprof they 
didn't need this option to get the profile output.

All the best,
Jochen


On Thursday, 2 March 2023 at 04:12:24 UTC peterGo wrote:

> Jochen Voss,
>
> On linux/amd64
>
> xxx.go: https://go.dev/play/p/Wq_OU49LVQZ
>
> $ go build xxx.go && ./xxx
>
> $ go tool pprof xxx mem.prof
> File: xxx
> Type: inuse_space
> Time: Mar 1, 2023 at 11:03pm (EST)
>
> No samples were found with the default sample value type.
> Try "sample_index" command to analyze different sample values.
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) quit
>
> $ go tool pprof -alloc_space xxx mem.prof
> File: xxx
> Type: alloc_space
> Time: Mar 1, 2023 at 11:03pm (EST)
>
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top
> Showing nodes accounting for 6919.54MB, 98.93% of 6994.32MB total
> Dropped 77 nodes (cum <= 34.97MB)
> Showing top 10 nodes out of 18
>
>   flat  flat%   sum%cum   cum%
>  3564.91MB 50.97% 50.97%  3564.91MB 50.97%  
> golang.org/x/exp/slices.Insert[.. 
> <http://golang.org/x/exp/slices.Insert%5B..>.] (inline)
>  3073.64MB 43.94% 94.91%  3073.64MB 43.94%  
> seehuhn.de/go/layout.(*Skip).Minus
>   123.51MB  1.77% 96.68%   123.51MB  1.77%  
> seehuhn.de/go/layout.(*Skip).Clone (inline)
>   104.50MB  1.49% 98.17%  6866.56MB 98.17%  
> seehuhn.de/go/layout.(*knuthPlassLineBreaker).Run
>48.48MB  0.69% 98.87%60.68MB  0.87%  compress/flate.NewWriter
> 4.50MB 0.064% 98.93%  6878.06MB 98.34%  
> seehuhn.de/go/layout.(*Engine).EndParagraph
>  0 0% 98.93%60.68MB  0.87%  compress/flate.NewWriterDict
>  0 0% 98.93%60.68MB  0.87%  compress/zlib.(*Writer).Write
>  0     0% 98.93%60.68MB  0.87% 
>  compress/zlib.(*Writer).writeHeader
>  0 0% 98.93%56.12MB   0.8%  fmt.Fprintln
> (pprof) quit
> $ 
>
> Peter
>
> On Wednesday, March 1, 2023 at 8:55:30 AM UTC-5 Jochen Voss wrote:
>
>> Dear all,
>>
>> I'm trying to profile memory use of a program, following the instructions 
>> at https://go.dev/blog/pprof , but I can't get memory profiling to 
>> work.  Am I doing things wrong, or is this broken?
>>
>> Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code 
>> doesn't run on the playground, but you can download it and run it locally.)
>>
>> Following the advice from https://pkg.go.dev/runtime/pprof I added the 
>> following code to the end of my main() function:
>>
>> f, err := os.Create("mem.prof")
>> if err != nil {
>> log.Fatal("could not create memory profile: ", err)
>> }
>> runtime.GC() // get up-to-date statistics
>> if err := pprof.WriteHeapProfile(f); err != nil {
>> log.Fatal("could not write memory profile: ", err)
>> }
>> err = f.Close()
>> if err != nil {
>> log.Fatal(err)
>> }
>>
>> When I run the code, this gives me a "mem.prof" file (5084 bytes).  But 
>> when I start "go tool pprof" on this file, I get
>>
>> >>> go tool pprof xxx mem.prof
>> File: xxx
>> Type: inuse_space
>> Time: Mar 1, 2023 at 1:15pm (GMT)
>> No samples were found with the default sample value type.
>> Try "sample_index" command to analyze different sample values.
>> Entering interactive mode (type "help" for commands, "o" for options)
>> (pprof) top10
>> Showing nodes accounting for 0, 0% of 0 total
>>   flat  flat%   sum%cum   cum%
>>
>> There seem to be no samples in this file.
>>
>> What am I doing wrong?
>>
>> All the best,
>> Jochen
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/99230d35-8f0a-41b4-9fb5-b0adb365b8c4n%40googlegroups.com.


Re: [go-nuts] Re: heap profiling does not work on M2 MacBook air?

2023-03-01 Thread Jochen Voss
Dear Sean,

Thanks for trying this out.  Your result is different from mine, but I 
don't think this can be right.  According to the output, the only 
allocation would be inside the regexp module.  But there should be many 
more allocations (for example in line 56 of the code)!

All the best,
Jochen
On Wednesday, 1 March 2023 at 17:44:30 UTC Sean Liao wrote:

> fwiw, that code works on my machine :tm:
>
> 1:40:47 ~/tmp/testrepo0120 0:00:27
> main » go run .  
> 1:40:58 ~/tmp/testrepo0120 0:00:08
> main » go tool pprof mem.prof
> File: testrepo0120
> Type: inuse_space
> Time: Mar 2, 2023 at 1:40am (CST)
>
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top10
> Showing nodes accounting for 513.31kB, 100% of 513.31kB total
>
>   flat  flat%   sum%cum   cum%
>   513.31kB   100%   100%   513.31kB   100%  regexp/syntax.(*compiler).inst 
> (inline)
>  0 0%   100%   513.31kB   100%  regexp.Compile (inline)
>  0 0%   100%   513.31kB   100%  regexp.MustCompile
>  0 0%   100%   513.31kB   100%  regexp.compile
>  0 0%   100%   513.31kB   100% 
>  regexp/syntax.(*compiler).compile
>  0 0%   100%   513.31kB   100%  regexp/syntax.(*compiler).rune
>  0 0%   100%   513.31kB   100%  regexp/syntax.Compile
>  0 0%   100%   513.31kB   100%  runtime.doInit
>  0 0%   100%   513.31kB   100%  runtime.main
>  0 0%   100%   513.31kB   100%  
> seehuhn.de/go/pdf/font/tounicode.init
>
> - sean
>
>
> On Wed, Mar 1, 2023 at 11:25 PM Jochen Voss  wrote:
>
>> The problem also occurs on AMD64 Linux, so it's not architecture 
>> specific.  Hints would be most welcome!
>>
>> On Wednesday, 1 March 2023 at 13:55:30 UTC Jochen Voss wrote:
>>
>>> Dear all,
>>>
>>> I'm trying to profile memory use of a program, following the 
>>> instructions at https://go.dev/blog/pprof , but I can't get memory 
>>> profiling to work.  Am I doing things wrong, or is this broken?
>>>
>>> Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code 
>>> doesn't run on the playground, but you can download it and run it locally.)
>>>
>>> Following the advice from https://pkg.go.dev/runtime/pprof I added the 
>>> following code to the end of my main() function:
>>>
>>> f, err := os.Create("mem.prof")
>>> if err != nil {
>>> log.Fatal("could not create memory profile: ", err)
>>> }
>>> runtime.GC() // get up-to-date statistics
>>> if err := pprof.WriteHeapProfile(f); err != nil {
>>> log.Fatal("could not write memory profile: ", err)
>>> }
>>> err = f.Close()
>>> if err != nil {
>>> log.Fatal(err)
>>> }
>>>
>>> When I run the code, this gives me a "mem.prof" file (5084 bytes).  But 
>>> when I start "go tool pprof" on this file, I get
>>>
>>> >>> go tool pprof xxx mem.prof
>>> File: xxx
>>> Type: inuse_space
>>> Time: Mar 1, 2023 at 1:15pm (GMT)
>>> No samples were found with the default sample value type.
>>> Try "sample_index" command to analyze different sample values.
>>> Entering interactive mode (type "help" for commands, "o" for options)
>>> (pprof) top10
>>> Showing nodes accounting for 0, 0% of 0 total
>>>   flat  flat%   sum%cum   cum%
>>>
>>> There seem to be no samples in this file.
>>>
>>> What am I doing wrong?
>>>
>>> All the best,
>>> Jochen
>>>
>>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/4e85c396-ef29-41d5-9bb6-5b950648287fn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/4e85c396-ef29-41d5-9bb6-5b950648287fn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32579fb7-773f-49e3-bfe1-a9af4a292dd9n%40googlegroups.com.


[go-nuts] Re: heap profiling does not work on M2 MacBook air?

2023-03-01 Thread Jochen Voss
The problem also occurs on AMD64 Linux, so it's not architecture specific.  
Hints would be most welcome!

On Wednesday, 1 March 2023 at 13:55:30 UTC Jochen Voss wrote:

> Dear all,
>
> I'm trying to profile memory use of a program, following the instructions 
> at https://go.dev/blog/pprof , but I can't get memory profiling to work.  
> Am I doing things wrong, or is this broken?
>
> Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code 
> doesn't run on the playground, but you can download it and run it locally.)
>
> Following the advice from https://pkg.go.dev/runtime/pprof I added the 
> following code to the end of my main() function:
>
> f, err := os.Create("mem.prof")
> if err != nil {
> log.Fatal("could not create memory profile: ", err)
> }
> runtime.GC() // get up-to-date statistics
> if err := pprof.WriteHeapProfile(f); err != nil {
> log.Fatal("could not write memory profile: ", err)
> }
> err = f.Close()
> if err != nil {
> log.Fatal(err)
> }
>
> When I run the code, this gives me a "mem.prof" file (5084 bytes).  But 
> when I start "go tool pprof" on this file, I get
>
> >>> go tool pprof xxx mem.prof
> File: xxx
> Type: inuse_space
> Time: Mar 1, 2023 at 1:15pm (GMT)
> No samples were found with the default sample value type.
> Try "sample_index" command to analyze different sample values.
> Entering interactive mode (type "help" for commands, "o" for options)
> (pprof) top10
> Showing nodes accounting for 0, 0% of 0 total
>   flat  flat%   sum%cum   cum%
>
> There seem to be no samples in this file.
>
> What am I doing wrong?
>
> All the best,
> Jochen
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4e85c396-ef29-41d5-9bb6-5b950648287fn%40googlegroups.com.


[go-nuts] heap profiling does not work on M2 MacBook air?

2023-03-01 Thread Jochen Voss
Dear all,

I'm trying to profile memory use of a program, following the instructions 
at https://go.dev/blog/pprof , but I can't get memory profiling to work.  
Am I doing things wrong, or is this broken?

Simplified code is at https://go.dev/play/p/Wq_OU49LVQZ .  (The code 
doesn't run on the playground, but you can download it and run it locally.)

Following the advice from https://pkg.go.dev/runtime/pprof I added the 
following code to the end of my main() function:

f, err := os.Create("mem.prof")
if err != nil {
log.Fatal("could not create memory profile: ", err)
}
runtime.GC() // get up-to-date statistics
if err := pprof.WriteHeapProfile(f); err != nil {
log.Fatal("could not write memory profile: ", err)
}
err = f.Close()
if err != nil {
log.Fatal(err)
}

When I run the code, this gives me a "mem.prof" file (5084 bytes).  But 
when I start "go tool pprof" on this file, I get

>>> go tool pprof xxx mem.prof
File: xxx
Type: inuse_space
Time: Mar 1, 2023 at 1:15pm (GMT)
No samples were found with the default sample value type.
Try "sample_index" command to analyze different sample values.
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top10
Showing nodes accounting for 0, 0% of 0 total
  flat  flat%   sum%cum   cum%

There seem to be no samples in this file.

What am I doing wrong?

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b6b7456b-16ad-4651-81f9-754184ad52c2n%40googlegroups.com.


Re: [go-nuts] Another generics question

2023-02-18 Thread Jochen Voss
Thanks a lot!

As an aside, the playgound is great.  It made this conversation so much 
easier!

All the best,
Jochen
On Saturday, 18 February 2023 at 01:31:16 UTC Ian Lance Taylor wrote:

> On Fri, Feb 17, 2023 at 4:47 PM Jochen Voss  wrote:,
> >
> > I would like to write a type constraint which matches types like the 
> following:
> >
> > type v1 int
> >
> > func (obj v1) Add(other v1) v1 {
> > return obj + other
> > }
> >
> > type v2 string
> >
> > func (obj v2) Add(other v2) v2 {
> > return obj + other
> > }
> >
> > This should match anything with an Add() method which can add another 
> item of the same type. I want to be able to write a function like the 
> following:
> >
> > func Double[Adder ...???...](x Adder) Adder {
> > return x.Add(x)
> > }
> >
> > My best attempts is https://go.dev/play/p/R0WLqSq9dys , but this 
> doesn't quite work. What is the correct type constraint to use?
>
> This is one way to do it: https://go.dev/play/p/uUxkvds5HLB .
>
> 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/7c9f4ac8-6951-44cb-b94f-2cee8751a049n%40googlegroups.com.


[go-nuts] Another generics question

2023-02-17 Thread Jochen Voss
Hello,

I would like to write a  type constraint which matches types like the 
following:

type v1 int

func (obj v1) Add(other v1) v1 {
return obj + other
}

type v2 string

func (obj v2) Add(other v2) v2 {
return obj + other
}

This should match anything with an Add() method which can add another item 
of the same type.  I want to be able to write a function like the following:

func Double[Adder ...???...](x Adder) Adder {
return x.Add(x)
}

My best attempts is https://go.dev/play/p/R0WLqSq9dys , but this doesn't 
quite work.  What is the correct type constraint to use?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5d8fcc25-2174-4c1d-a325-29111932fe6dn%40googlegroups.com.


Re: [go-nuts] generics: can I require "comparable" together with some methods?

2023-02-17 Thread Jochen Voss
Thanks again, reading the blog post indeed solved the problem!

On Friday, 17 February 2023 at 23:47:09 UTC Ian Lance Taylor wrote:

> On Fri, Feb 17, 2023 at 3:34 PM Jochen Voss  wrote:
> >
> > I'm trying to write a generic function like the following (simplified) 
> one:
> >
> > type V interface {
> > comparable // (1)
> > SomeMethod(V)
> > }
> >
> > func Test[val V](x val) {
> > m := make(map[val]int) // (2)
> > // uses a x as key in a map and calls x.SomeMethod()
> > }
> >
> > When I try this, see https://go.dev/play/p/cJoH5YwEHaK , I get an error 
> message for (1): "cannot use type V outside a type constraint: interface is 
> (or embeds) comparable". If I remove the line (1) I get an error for (2) 
> instead: "invalid map key type val (missing comparable constraint)".
> >
> > Is there a way to make something like this work?
>
> Are you using Go 1.20? See https://go.dev/blog/comparable .
>
> 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/9833388c-f9af-45bd-8f34-22d3edabdae5n%40googlegroups.com.


Re: [go-nuts] generics: can I require "comparable" together with some methods?

2023-02-17 Thread Jochen Voss
Dear Ian,

Yes, I'm using 1.20.1.

I hadn't seen the blog post yet, will read this next.  Thanks for pointing 
me at this.  Judging from the first paragraph of the blog post alone, the 
change described there may not solve my problem, though.

All the best,
Jochen

On Friday, 17 February 2023 at 23:47:09 UTC Ian Lance Taylor wrote:

> On Fri, Feb 17, 2023 at 3:34 PM Jochen Voss  wrote:
> >
> > I'm trying to write a generic function like the following (simplified) 
> one:
> >
> > type V interface {
> > comparable // (1)
> > SomeMethod(V)
> > }
> >
> > func Test[val V](x val) {
> > m := make(map[val]int) // (2)
> > // uses a x as key in a map and calls x.SomeMethod()
> > }
> >
> > When I try this, see https://go.dev/play/p/cJoH5YwEHaK , I get an error 
> message for (1): "cannot use type V outside a type constraint: interface is 
> (or embeds) comparable". If I remove the line (1) I get an error for (2) 
> instead: "invalid map key type val (missing comparable constraint)".
> >
> > Is there a way to make something like this work?
>
> Are you using Go 1.20? See https://go.dev/blog/comparable .
>
> 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/5d6fbfe1-be87-4c8f-ae65-3216af73202an%40googlegroups.com.


[go-nuts] generics: can I require "comparable" together with some methods?

2023-02-17 Thread Jochen Voss
Hello,

I'm trying to write a generic function like the following (simplified) one:

type V interface {
comparable // (1)
SomeMethod(V)
}

func Test[val V](x val) {
m := make(map[val]int) // (2)
// uses a x as key in a map and calls x.SomeMethod()
}

When I try this, see https://go.dev/play/p/cJoH5YwEHaK , I get an error 
message for (1): "cannot use type V outside a type constraint: interface is 
(or embeds) comparable".  If I remove the line (1) I get an error for (2) 
instead: "invalid map key type val (missing comparable constraint)".

Is there a way to make something like this work?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/71d60f95-73e4-40cc-833d-dda84ef36708n%40googlegroups.com.


[go-nuts] Re: regexp question

2023-02-10 Thread Jochen Voss
Hi Peter,

I don't think this is the solution: https://go.dev/play/p/Ti7UEGd1BVE .
I think "All" means that it can deal with several copies of the regexp, 
rather than returning all matches of the group.

All the best,
Jochen

On Friday, 10 February 2023 at 16:09:04 UTC Peter Galbavy wrote:

> FindAllStringSubmatch() ? 
> https://pkg.go.dev/regexp#Regexp.FindAllStringSubmatch
>
> On Friday, 10 February 2023 at 12:52:34 UTC Jochen Voss wrote:
>
>> Dear all,
>>
>> What happens if a group in a regular expression matches repeatedly, via 
>> the * operator?  Experimentally I found that FindStringSubmatch then 
>> returns the text of the last match.  Is this guaranteed somewhere (I didn't 
>> find anything about this on https://pkg.go.dev/regexp )?  Also, is there 
>> an easy way to get the other matched strings?
>>
>> Example: https://go.dev/play/p/h5UDongaz7u
>>
>> regexp: `A\s*(?:([a-z]+)\s*)*B`
>> applied to: "one A two three four B five"
>> the inner group gives me "four"
>>
>> Is FindStringSubmatch guaranteed to return the "four"? 
>> Is there a way to also get the matched "two" and "three"?
>>
>> Many thanks,
>> Jochen
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de25ad20-02bc-4fb6-ab3c-4adc30702c74n%40googlegroups.com.


[go-nuts] regexp question

2023-02-10 Thread Jochen Voss
Dear all,

What happens if a group in a regular expression matches repeatedly, via the 
* operator?  Experimentally I found that FindStringSubmatch then returns 
the text of the last match.  Is this guaranteed somewhere (I didn't find 
anything about this on https://pkg.go.dev/regexp )?  Also, is there an easy 
way to get the other matched strings?

Example: https://go.dev/play/p/h5UDongaz7u

regexp: `A\s*(?:([a-z]+)\s*)*B`
applied to: "one A two three four B five"
the inner group gives me "four"

Is FindStringSubmatch guaranteed to return the "four"? 
Is there a way to also get the matched "two" and "three"?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2b8c9ec4-7967-46d3-b6d7-29730eb0f6c3n%40googlegroups.com.


[go-nuts] maps.Keys() does not work when keys are of type language.Tag

2022-10-06 Thread Jochen Voss
Hello,

Using "golang.org/x/text/language" I have a map of 
type map[language.Tag]int.  I would like to get the keys present in my 
map.  Why does the following command not work?

import "golang.org/x/exp/maps"
...
var x map[language.Tag]int
...
fmt.Println(maps.Keys(x))

The error message is "Tag does not implement comparable".  Code on the 
playground: https://go.dev/play/p/dsyEt0ClDBH .

The following function does work as expected, so this is easy to work 
around:

func myKeys(m map[language.Tag]int) []language.Tag {
var res []language.Tag
for key := range m {
res = append(res, key)
}
return res
}

But I wonder now whether it is unwise to use language.Tag for the keys in a 
map, and why maps.Keys() requires the keys to implement "comparable" in 
addition to the constraint "M ~map[K]V".

Many thanks,
Jochen




-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fc3f94ac-e4ae-4964-8c38-ece6492ccd00n%40googlegroups.com.


[go-nuts] how to organise code with channels and error handling?

2022-09-23 Thread Jochen Voss
Dear all,

I am writing a program which processes data in stages.  To structure the 
code cleanly, I would like implement each stage as an individual function 
and use channels to pass data between stages.

My questions:
- How to structure the code?  Is my approach described below reasonable?
- How to deal with errors?

Here is a sketch of I currently have (runnable version 
at https://go.dev/play/p/7Rrq-OLARl_R ):

func getInputs() <-chan t1 {
c := make(chan t1)
go func() {
for ... {
...
c <- x
}
close(c)
}()
return c
}

func process(in <-chan t1) <-chan t2 {
c := make(chan t2)
go func() {
for i := range in {
x, err := ...
_ = err // what to do with the error?
c <- x
}
close(c)
}()
return c
}

func main() {
c1 := getInputs()
c2 := process(c1)
summarise(c2)
}

There are some things I like about this approach:

   - the main function looks nice and tidy
   - the stages of work are cleanly separated

But there are also things I don't like:

   - I can't see an obvious way to handle errors in the stages.  In my case 
   the first stage is locating input files on the file system, and there may 
   be read errors etc.  The second stage processes the files, and files may 
   have invalid contents.
   - The code for the individual stages looks a bit strange with the double 
   indentation from the outer func(){} and the go func() {}().

So my questions are:

   - What would be a good way to incorporate error handling into my code?  
   I assume this will require one or more additional channels, just for 
   errors.  Or is there a better way?
   - Is there a better way to structure my code?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/cd4e086c-4f1c-4a48-9162-c46ab45df66fn%40googlegroups.com.


[go-nuts] returning struct vs. returning interface

2022-08-03 Thread Jochen Voss
Dear all,

Why does the function NewReader [1] in compress/lzw return an io.ReadCloser 
instead of an *lzw.Reader?  The docs say "It is guaranteed that the 
underlying type of the returned io.ReadCloser is a *Reader", so why not 
return a *Reader without wrapping?

[1] https://pkg.go.dev/compress/lzw#NewReader

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7ee4994a-a9e2-44d7-a939-9ca9fa7529d4n%40googlegroups.com.


[go-nuts] weblist in go tool pprof does not work for me

2022-06-24 Thread Jochen Voss
Hello,

For a while, the "weblist" command in go tool pprof has been broken for me 
("list" still works).  Is this a known issue?  What can I do to fix this?

What I am doing:

- I am using "go version go1.18.3 darwin/arm64" on a MacBook Pro (M1 Pro 
processor).
- I am profiling one of my unit tests using the following command:
go test -run '^TestAll$' -cpuprofile cpu.out -memprofile mem.out
- I am calling pprof using the command
go tool pprof sfnt.test cpu.out
- most commands seem to work, for example:
(pprof) top10
Showing nodes accounting for 20130ms, 86.54% of 23260ms total
Dropped 162 nodes (cum <= 116.30ms)
Showing top 10 nodes out of 124
  flat  flat%   sum%cum   cum%
6790ms 29.19% 29.19% 6790ms 29.19%  runtime.madvise
4840ms 20.81% 50.00% 4840ms 20.81%  syscall.syscall6
1910ms  8.21% 58.21% 1910ms  8.21%  runtime.usleep
1740ms  7.48% 65.69% 1740ms  7.48%  runtime.pthread_kill
1710ms  7.35% 73.04% 1710ms  7.35%  runtime.pthread_cond_wait
 990ms  4.26% 77.30%  990ms  4.26%  runtime.kevent
 770ms  3.31% 80.61% 2020ms  8.68% 
 seehuhn.de/go/pdf/font/cff.decodeCharString
 540ms  2.32% 82.93% 1440ms  6.19%  runtime.scanobject
 530ms  2.28% 85.21%  530ms  2.28%  runtime.pthread_cond_signal
 310ms  1.33% 86.54% 1040ms  4.47%  runtime.mallocgc
- "list" works, for example I get the expected output for list 
cff.decodeCharString
- "weblist" does not work.  If I call weblist cff.decodeCharString the web 
browser opens but shows a page containing only the following five lines of 
text, and no listing:

 File: sfnt.test
 Type: cpu
 Time: Jun 24, 2022 at 1:09pm (BST)
 Duration: 19.03s, Total samples = 23.26s (122.20%)
 Total: 23.26s

Am I doing anything wrong?  I didn't find any reports of similar problems 
on Google, so maybe this is just some oddity of my setup or me doing 
something silly?

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/02c205c7-e491-4940-9d9d-2421555ff5ecn%40googlegroups.com.


Re: [go-nuts] evaluation of range expression in for-range loop

2022-03-18 Thread Jochen Voss
Thanks Axel,

Now this makes sense to me.

All the best,
Jochen

On Friday, 18 March 2022 at 12:04:04 UTC axel.wa...@googlemail.com wrote:

> https://go.dev/ref/spec#Length_and_capacity says:
>
>> The expression len(s) is constant if s is a string constant. The 
>> expressions len(s) and cap(s) are constants if the type of s is an array or 
>> pointer to an array and the expression s does not contain channel receives 
>> or (non-constant) function calls; in this case s is not evaluated. 
>> Otherwise, invocations of len and cap are not constant and s is evaluated.
>
> So, in your case, the array contains a function call, so `len(…)` is not 
> constant.
>
> Here is a case where the clause from the spec makes an observable 
> difference:  https://go.dev/play/p/jeCk6vHzf9u
> Without that clause, the range loop would have to iterate over the element 
> of the pointee, causing a nil-dereference panic. The clause allows this 
> code to work.
>
> On Fri, Mar 18, 2022 at 12:43 PM Jochen Voss  wrote:
>
>> Dear all,
>>
>> The spec at https://go.dev/ref/spec#For_range says
>>
>> "The range expression x is evaluated once before beginning the loop, with 
>> one exception: if at most one iteration variable is present and len(x) is 
>> constant, the range expression is not evaluated." 
>>
>> What does the second half of this sentence mean?
>>
>> My guess was that this says that in "for i := range [3]int{1, 2, f()} 
>> ..." the function f is not called, but I quick experiment shows that this 
>> guess is wrong, see https://go.dev/play/p/MXqH_C7mllx .
>>
>> All the best,
>> Jochen
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/db6d865e-233e-4120-8ce5-5feb832732b6n%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/db6d865e-233e-4120-8ce5-5feb832732b6n%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/589d8a21-931c-4c74-95e8-62ef83a501a9n%40googlegroups.com.


[go-nuts] evaluation of range expression in for-range loop

2022-03-18 Thread Jochen Voss
Dear all,

The spec at https://go.dev/ref/spec#For_range says

"The range expression x is evaluated once before beginning the loop, with 
one exception: if at most one iteration variable is present and len(x) is 
constant, the range expression is not evaluated." 

What does the second half of this sentence mean?

My guess was that this says that in "for i := range [3]int{1, 2, f()} ..." 
the function f is not called, but I quick experiment shows that this guess 
is wrong, see https://go.dev/play/p/MXqH_C7mllx .

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/db6d865e-233e-4120-8ce5-5feb832732b6n%40googlegroups.com.


Re: [go-nuts] Pointer to a pointer

2022-03-15 Thread Jochen Voss
Thanks for the pointer to peano.go, this is fun!

It took me a while to locate the file.  In case others are interested: 
peano.go is 
at https://github.com/golang/website/blob/master/_content/doc/play/peano.go 
and can also be found by choosing "Peano Integers" from the top-right menu 
in the Go playground.

All the best,
Jochen
On Thursday, 10 March 2022 at 09:31:58 UTC Rob 'Commander' Pike wrote:

> On Thu, Mar 10, 2022 at 5:08 PM shan...@gmail.com  
> wrote:
> >
> > Is this really how you want to be known?
>
> Sure, why not? It's a more interesting program than one might think.
>
> For a richer example of the foundational idea here, see the peano.go
> program in the test directory in the repo.
>
> -rob
>

-- 
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/efbb4589-ff23-4e57-ae6f-0ab4e82ca1cfn%40googlegroups.com.


Re: [go-nuts] is url->String->Parse != url a bug?

2022-03-04 Thread Jochen Voss
Hi Axel,

You write "in general, there are multiple valid escaped forms of any URL".  
This would still allow for all escaped forms to result in the same URL 
object when parsed.

What I hoped for is a way to go URL->string->URL and get back the same 
result.  I understand that this is how is works for every URL.  Now I 
wonder, if I do

url1 := ...
s2 := url1.String()
url2, _ := url1.Parse(s2)
s3 := url2.String()
url3,_ := url2.Parse(s3)

will I then have reflect.DeepEqual(url2, url3)?  If this works, then I 
could use the url1->url2 step to "normalize" my URL, and url2 would have 
the property I want.  Or is there an easier way to obtain this "normalized" 
version?

All the best,
Jochen
On Friday, 4 March 2022 at 13:31:50 UTC axel.wa...@googlemail.com wrote:

> On Fri, Mar 4, 2022 at 2:12 PM Jochen Voss  wrote:
>
>> If I convert an url.URL to a string and then parse the result, am I meant 
>> to get back the original url?
>>
>
> I don't think so. String() returns an escaped URL and in general, there 
> are multiple valid escaped forms of any URL. So, by necessity, there are 
> different URLs which return the same String() result.
> The documentation points that out: 
> https://pkg.go.dev/net/url#URL.EscapedPath
>  
>
>>   While playing with the new fuzzer I found that in practise this is not 
>> the case,
>> but I'm not sure whether this is due to bugs, or whether this is expected.
>>
>> The affected URLs are of course all silly urls, chosen by the fuzzer.
>> Example: https://go.dev/play/p/VFe0MbBty3r
>>
>
> For this specific example, there is also this sentence in the docs:
>
> Trying to parse a hostname and path without a scheme is invalid but may 
>> not necessarily return an error, due to parsing ambiguities.
>
> https://pkg.go.dev/net/url#Parse
>
> I don't know terribly much about the actual URL format, but this sounds to 
> me, that the parsing result for that string is not actually well-defined 
> anyway.
>
>
>> All the best,
>> Jochen
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/288ac10a-2dab-42ad-a134-0e160006d187n%40googlegroups.com.


[go-nuts] is url->String->Parse != url a bug?

2022-03-04 Thread Jochen Voss
Hello,

If I convert an url.URL to a string and then parse the result, am I meant 
to get back the original url?  While playing with the new fuzzer I found 
that in practise this is not the case,
but I'm not sure whether this is due to bugs, or whether this is expected.

The affected URLs are of course all silly urls, chosen by the fuzzer.
Example: https://go.dev/play/p/VFe0MbBty3r

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/7a45513b-c0b3-457e-9f3b-3360204a713en%40googlegroups.com.


[go-nuts] feedback from my first experiment with generic go code

2022-02-16 Thread Jochen Voss
Dear all,

Today I tried out the new generics support in Go for the first time by 
implementing Dijkstra's algorithm for the shortest path in a directed 
graph.  In case it's interesting to somebody, here are my impressions, code 
is at https://github.com/seehuhn/go-dijkstra .

The key parts of my code are:


type Vertex[edge any] interface {
comparable
Edges() []edge
}

type Edge[vertex any, length constraints.Ordered] interface {
From() vertex
To() vertex
Length() length
}

func ShortestPath[edge Edge[vertex, length], vertex Vertex[edge], length 
constraints.Ordered](start, end vertex) ([]edge, error) { ...}

My comments/questions:

   - I found generics reasonably easy to use.  This was my first experience 
   with generics, and I went wrong only once.  Overall, writing the code was 
   straightforward.
   - Since I am using the beta release, I have to type "go1.18beta2" to 
   call go.  Sometimes I typed "go" accidentally, and I found the resulting 
   error messages often confusing and unhelpful.  For example, "go test" says 
   "package constraints is not in GOROOT".  I wonder whether in case of errors 
   the go command should show a message if the go version in go.mod is newer 
   than the current version.
   - "go doc" is still sometimes confused about generics.  When I type 
   "go1.18beta2 doc seehuhn.de/go/dijkstra Vertex" the output claims that 
   Vertex "has unexported methods".  The message is misleading, it is cause by 
   Vertex embedding "comparable".  Is this worth reporting as a bug?
   - To me it is not intuitive why "comparable" is built intro the language 
   but "Ordered" is in an external package.
   - I have not managed to make it possible for ShortestPath() to 
   automatically infer the type parameters.  Is there a trick I have missed?
   - Currently I am using constraints.Ordered for the edge length.  This 
   currently works, but I'm slightly cheating here since I am also using "+" 
   on the edge lengths.  If in the future new ordered types were added to  
   constraints.Ordered, my code might break.  Is there a way to say "I need <= 
   and +" (short of enumerating all types)?
   - When checking for negative edge lengths, I need the zero value for my 
   instance of constraints.Ordered.  Currently I am using a separate, 
   uninitialised variable for this.  Is there a better way to say "x <= 0" 
   when x is of a type which matches constraints.Ordered?
   - I needed to reverse a slice in-place.  Would a function to do this 
   make a good addition to golang.org/x/exp?
   - The "func ShortestPath..." line is hard to read and quite long.  I 
   didn't find a good place for a line break either.  Any ideas for making 
   this more readable?

I'd be happy to receive feedback about my code.

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/ec227a9a-4c8b-4db0-b515-63997af429b1n%40googlegroups.com.


[go-nuts] type parameter names

2022-02-16 Thread Jochen Voss
Dear all,

I stumbled across a difference between type names and type parameter names 
(in the go1.18 beta): I can re-use a type name as a variable name, but the 
same is not possible with type parameter names.  Is this difference 
intentional?

For illustration, the following code is 
valid https://go.dev/play/p/r2NAddZmoE3 :

type other int

func test(x other) other {
other := x + 1
return other
}

But this doesn't work https://go.dev/play/p/Dsh9IgvKDDY?v=gotip :

type Numeric interface {
~int | ~float64
}

func test[other Numeric](x other) other {
other := x + 1
return other
}

All the best,
Jochen



-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/4d0066c3-315d-4746-a0cf-3749bfbcb45dn%40googlegroups.com.


Re: [go-nuts] Re: golang-announce is blocked in Google Groups?

2022-01-21 Thread Jochen Voss
Same here, the problem seems to have gone away.

On Thursday, 20 January 2022 at 19:37:54 UTC seank...@gmail.com wrote:

> For me it did show as blocked a few hours earlier but works now
>


>> > -- 
>> > 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...@googlegroups.com. 
>> > To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/113efe51-64c0-4a53-9631-8177ca8ed8fcn%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/b08cd338-d908-4d92-9823-cf8920b74541n%40googlegroups.com.


[go-nuts] golang-announce is blocked in Google Groups?

2022-01-20 Thread Jochen Voss
Hello,

It seems that golang-announce is blocked in Google Groups.  When I try to 
access the group, I only get the following message:

Banned content warning
golang-announce has been identified as containing spam, malware or 
other malicious content.
For more information about content policies on Google Groups, see ...

Anybody knows what this is about?

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/110a3919-e8f6-4d43-8e10-007e6dcbbab7n%40googlegroups.com.


[go-nuts] Re: 410 Gone response from sum.golang.org for new module version?

2021-10-02 Thread Jochen Voss
Never mind, waiting fixed it.  The package showed up around 40 minutes 
after I published it on github.

All the best,
Jochen

On Saturday, 2 October 2021 at 11:11:23 UTC+1 Jochen Voss wrote:

> Hello,
>
> I have just published a new version of my websocket library, but I cannot 
> get it to load into the client.  The error message is as follows:
>
> > go get seehuhn.de/go/webs...@v1.1.0 
> <http://seehuhn.de/go/websocket@v1.1.0>
> go: downloading seehuhn.de/go/websocket v1.1.0
> go get: seehuhn.de/go/webs...@v1.1.0 
> <http://seehuhn.de/go/websocket@v1.1.0>: verifying module: 
> seehuhn.de/go/webs...@v1.1.0 <http://seehuhn.de/go/websocket@v1.1.0>: 
> reading https://sum.golang.org/lookup/seehuhn.de/go/webs...@v1.1.0 
> <https://sum.golang.org/lookup/seehuhn.de/go/websocket@v1.1.0>: 410 Gone
> server response: not found: seehuhn.de/go/webs...@v1.1.0 
> <http://seehuhn.de/go/websocket@v1.1.0>: invalid version: unknown 
> revision v1.1.0
>
> The previous version works: go get seehuhn.de/go/webs...@v1.0.1 
> <http://seehuhn.de/go/websocket@v1.0.1> and I believe I have correctly 
> tagged the new version, since the tag shows up here: 
> https://github.com/seehuhn/go-websocket/tags .
>
> What am I doing wrong?
>
> Many thanks,
> Jochen
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e7698410-047e-49e5-81e0-6ffa5fc4af8en%40googlegroups.com.


[go-nuts] 410 Gone response from sum.golang.org for new module version?

2021-10-02 Thread Jochen Voss
Hello,

I have just published a new version of my websocket library, but I cannot 
get it to load into the client.  The error message is as follows:

> go get seehuhn.de/go/websocket@v1.1.0
go: downloading seehuhn.de/go/websocket v1.1.0
go get: seehuhn.de/go/websocket@v1.1.0: verifying module: 
seehuhn.de/go/websocket@v1.1.0: reading 
https://sum.golang.org/lookup/seehuhn.de/go/websocket@v1.1.0: 410 Gone
server response: not found: seehuhn.de/go/websocket@v1.1.0: invalid 
version: unknown revision v1.1.0

The previous version works: go get seehuhn.de/go/websocket@v1.0.1 and I 
believe I have correctly tagged the new version, since the tag shows up 
here: https://github.com/seehuhn/go-websocket/tags .

What am I doing wrong?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fc6d5a31-3197-440e-b9ae-9cc6422ee63en%40googlegroups.com.


Re: [go-nuts] ParseInt confusion

2021-02-09 Thread Jochen Voss
Oh, yes, thank you and sorry about the noise!

On Tuesday, 9 February 2021 at 17:02:41 UTC ja...@kastelo.net wrote:

> An int8 has a range of -128 to +127. You may be looking for 
> strconv.ParseUint if you want an 8 bit unsigned int? 
>
> //jb
>
> On 9 Feb 2021, at 17:51, Jochen Voss  wrote:
>
> Dear all, 
>
> The command strconv.ParseInt("256", 8, 8) should not return an error, 
> because octal 256 is decimal 174 which fits into 8 bits.  Right?
>
> I'm asking, because actually running this command gives 'strconv.ParseInt: 
> parsing "256": value out of range'!  https://play.golang.org/p/gNKN0kKLfDd
>
> What am I overlooking here?
>
> All the best,
> Jochen
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to golang-nuts...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/golang-nuts/73e9d2a5-d8fb-468d-aebe-95f171bbff1dn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/golang-nuts/73e9d2a5-d8fb-468d-aebe-95f171bbff1dn%40googlegroups.com?utm_medium=email_source=footer>
> .
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/d1dcd8dd-a31f-48e8-993d-005f05e24d91n%40googlegroups.com.


[go-nuts] ParseInt confusion

2021-02-09 Thread Jochen Voss
Dear all,

The command strconv.ParseInt("256", 8, 8) should not return an error, 
because octal 256 is decimal 174 which fits into 8 bits.  Right?

I'm asking, because actually running this command gives 'strconv.ParseInt: 
parsing "256": value out of range'!  https://play.golang.org/p/gNKN0kKLfDd

What am I overlooking here?

All the best,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/73e9d2a5-d8fb-468d-aebe-95f171bbff1dn%40googlegroups.com.


Re: [go-nuts] printing an empty slice with fmt.Printf()

2020-12-19 Thread Jochen Voss
Dear all,

Thanks for your help.  The solution is indeed to use "%x" instead of "%02x".

My confusion was caused by the following sentence in the docs: "For 
compound operands such as slices and structs, the format applies to the 
elements of each operand".  I never spotted the relevant exception 
mentioned a few lines later: "However, when printing a byte slice with a 
string-like verb (%s %q %x %X), it is treated ... as a single item."  So 
the "%02" applies to the whole byte slice, and not to each byte as I had 
wrongly thought.

All the best,
Jochen


On Saturday, 19 December 2020 at 00:24:07 UTC kortschak wrote:

> I think that's the question. Here's a simpler example, 
> https://play.golang.org/p/9Kv3PhlM-OF
>
> That is, is 00 an expected %02x representation of a zero-length byte
> slice?
>
> The answer to that is yes; the 02 forces leading zeros. The %x verb
> essentially renders bit strings as hex, so a zero-length bit string
> with mandated two leading zeros is 00.
>
> If you leave out the 02, you get the expected empty string.
>
> https://play.golang.org/p/uVFt3lecKxf
>
> On Fri, 2020-12-18 at 15:38 -0800, Marcin Romaszewicz wrote:
> > It's expected behavior.
> > 
> > Your for loop runs once for l=0, since your condition is <=0 because
> > len([]byte{}) is 0.
> > 
> > -- Marcin
>
>
>

-- 
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/bd781856-6e04-4978-b23f-8b7d98611e56n%40googlegroups.com.


[go-nuts] printing an empty slice with fmt.Printf()

2020-12-18 Thread Jochen Voss
Hello,

I can print slices of bytes as hex strings, using code like the following:

x := []byte{0, 1, 2, 3}
fmt.Printf("%02x", x[:l])

This gives the output "00010203" as expected.  But this fails for the empty 
slice: running

x := []byte{}
fmt.Printf("%02x", x[:l])

gives "00" instead of the empty string.  See 
https://play.golang.org/p/rvLLqydDDE6 for a demonstration.

Is this a bug, or is this expected behaviour?

All the best,
Jochen


-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/bb8774f3-aa17-4044-8435-ed1cd162976cn%40googlegroups.com.


[go-nuts] Re: request for feedback: another websocket server implementation

2019-09-18 Thread Jochen Voss
Dear Ilia,

Thank you for your comment.  In my mind, Read and Write are made for 
streaming data, whereas a websocket connection transports messages.  How 
would I handle message types and message boundaries when using the 
io.Reader and io.Writer interfaces?  (I do try to implement these 
interfaces for the *contents* of the messages themselves, see my 
SendMessage and ReceiveMessage functions.)

Many thanks,
Jochen

On Wednesday, 18 September 2019 14:37:49 UTC+1, Ilia Choly wrote:
>
> You should try to make Conn implement io.Reader and io.Writer
>
> On Tuesday, September 17, 2019 at 6:29:08 PM UTC-4, Jochen Voss wrote:
>>
>> Dear all,
>>
>> Because I wanted to learn about the websocket protocol, I have 
>> implemented a websocket server in Go:
>>
>> code: https://github.com/seehuhn/go-websocket
>> documentation: https://godoc.org/seehuhn.de/go/websocket
>>
>> I would be happy to receive feedback about my code.
>>
>> Specific questions:
>>
>> - Does the API look reasonable?  Anything to improve?
>>
>> - I use the function readMultiplexer (at the end of reader.go) to read 
>> all frame headers from the network connection, and to make sure that the 
>> readers of the frame bodies don't step on each other's feet.  Similarly, 
>> the function writeMultiplexer (at the end of writer.go) coordinates all 
>> writers and performs all writes to the network connection.  This system is 
>> held together by a tangle of go channels.  The code is much messier than I 
>> would like it to be.  Is there a way to structure such code so that it 
>> is easier to reason about, so that I can be more confident that it is 
>> correct?  The bits a struggled most with are the various ways the 
>> connection can be closed (closed by server explicitly or because of a 
>> protocol error, closed by client with/without close frame).
>>
>> - I attempted to profile the code, to find whether there are any 
>> performance bottlenecks.  My code for this is in websocket_test.go 
>> (function BenchmarkEcho), but the profiles then only ever show the code 
>> waiting for data on go channels or for data from the network.  My feeling 
>> is that I was really benchmarking the network connection and not my code.  
>> Is there a way to improve BenchmarkEcho to get more meaningful results?
>>
>> Many thanks,
>> Jochen
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/de7cd4f5-e2dd-4a17-876d-c4ac61da2c3f%40googlegroups.com.


[go-nuts] Re: request for feedback: another websocket server implementation

2019-09-18 Thread Jochen Voss
Dear T L,

Thanks for this.  I was aware of implementations number 1 and 4 (and I 
think I like my own better than these), but I didn't spot numbers 2 and 3.  
I'll have a look at these, too.

Many thanks,
Jochen

On Wednesday, 18 September 2019 14:27:17 UTC+1, T L wrote:
>
> Just for reference. Here are other Go websocket implementations:
> * Gorilla WebSocket https://github.com/gorilla/websocket
> * https://github.com/nhooyr/websocket
> * https://github.com/gobwas/ws
> * x/net/websocket https://godoc.org/golang.org/x/net/websocket
>
> On Tuesday, September 17, 2019 at 6:29:08 PM UTC-4, Jochen Voss wrote:
>>
>> Dear all,
>>
>> Because I wanted to learn about the websocket protocol, I have 
>> implemented a websocket server in Go:
>>
>> code: https://github.com/seehuhn/go-websocket
>> documentation: https://godoc.org/seehuhn.de/go/websocket
>>
>> I would be happy to receive feedback about my code.
>>
>> Specific questions:
>>
>> - Does the API look reasonable?  Anything to improve?
>>
>> - I use the function readMultiplexer (at the end of reader.go) to read 
>> all frame headers from the network connection, and to make sure that the 
>> readers of the frame bodies don't step on each other's feet.  Similarly, 
>> the function writeMultiplexer (at the end of writer.go) coordinates all 
>> writers and performs all writes to the network connection.  This system is 
>> held together by a tangle of go channels.  The code is much messier than I 
>> would like it to be.  Is there a way to structure such code so that it 
>> is easier to reason about, so that I can be more confident that it is 
>> correct?  The bits a struggled most with are the various ways the 
>> connection can be closed (closed by server explicitly or because of a 
>> protocol error, closed by client with/without close frame).
>>
>> - I attempted to profile the code, to find whether there are any 
>> performance bottlenecks.  My code for this is in websocket_test.go 
>> (function BenchmarkEcho), but the profiles then only ever show the code 
>> waiting for data on go channels or for data from the network.  My feeling 
>> is that I was really benchmarking the network connection and not my code.  
>> Is there a way to improve BenchmarkEcho to get more meaningful results?
>>
>> Many thanks,
>> Jochen
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/9637cdf0-c438-4659-9ce8-35ddff219bfb%40googlegroups.com.


[go-nuts] request for feedback: another websocket server implementation

2019-09-17 Thread Jochen Voss
Dear all,

Because I wanted to learn about the websocket protocol, I have implemented 
a websocket server in Go:

code: https://github.com/seehuhn/go-websocket
documentation: https://godoc.org/seehuhn.de/go/websocket

I would be happy to receive feedback about my code.

Specific questions:

- Does the API look reasonable?  Anything to improve?

- I use the function readMultiplexer (at the end of reader.go) to read all 
frame headers from the network connection, and to make sure that the 
readers of the frame bodies don't step on each other's feet.  Similarly, 
the function writeMultiplexer (at the end of writer.go) coordinates all 
writers and performs all writes to the network connection.  This system is 
held together by a tangle of go channels.  The code is much messier than I 
would like it to be.  Is there a way to structure such code so that it is 
easier to reason about, so that I can be more confident that it is correct?  
The bits a struggled most with are the various ways the connection can be 
closed (closed by server explicitly or because of a protocol error, closed 
by client with/without close frame).

- I attempted to profile the code, to find whether there are any 
performance bottlenecks.  My code for this is in websocket_test.go 
(function BenchmarkEcho), but the profiles then only ever show the code 
waiting for data on go channels or for data from the network.  My feeling 
is that I was really benchmarking the network connection and not my code.  
Is there a way to improve BenchmarkEcho to get more meaningful results?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1826e9b6-03db-4d93-92e2-ba0c0fd0b379%40googlegroups.com.


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

2019-08-16 Thread Jochen Voss
Hi Axel,

Thanks a lot for looking into this.  Your post makes things much clearer 
for me.  In particular, I now think that I probably should not have 
(Un)MarshalBinary() methods on the interface type, but have them only on 
the concrete type instead.  For example, this 
works: https://play.golang.org/p/oBgHqN74ZeM .

On Thursday, 15 August 2019 11:16:45 UTC+1, Axel Wagner wrote:
>
> The panic, I think, comes from the fact that you pass a *Duck, which then 
> gets dereferenced, pointing at a nil Duck. Even a nil-Duck *does* have a 
> DecodeBinary method though, so gob thinks it should use that. It then 
> type-asserts to BinaryDecoder, which panics, because it's a nil-interface, 
> just like this example: https://play.golang.org/p/EEwOt0FQunh.
>

I had forgotten that type assertions don't allow nil values, but indeed 
they don't.  Thank you for reminding me.

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/a707a33a-ea3a-4103-84f8-24d56a91fdae%40googlegroups.com.


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

2019-08-15 Thread Jochen Voss
Hi Axel,

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

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

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

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

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/32c27653-c50b-42cd-a525-8c9e9298bf60%40googlegroups.com.


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

2019-08-15 Thread Jochen Voss
Dear Marcin,

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

Many thanks,
Jochen

On Wednesday, 14 August 2019 22:12:54 UTC+1, Marcin Romaszewicz wrote:
>
> Here you go:
> https://play.golang.org/p/_cPmaSxRatC
>
> You want to unmarshal into , not into 
>
> This means:
> var duck2 A
>
> not:
> var duck2 Duck
>
> On Wed, Aug 14, 2019 at 8:46 AM Jochen Voss  > wrote:
>
>> Hello,
>>
>> I'm trying to read gob-encoded data into a variable of interface type.  
>> In simple cases, this works for me, but when I use a custom encoding 
>> via MarshalBinary() and UnmarshalBinary() methods, my code keeps crashing, 
>> with the error message
>>
>> panic: interface conversion: interface is nil, not 
>> encoding.BinaryUnmarshaler
>>
>> Example:
>>
>> - The code at https://play.golang.org/p/y8nWNhObUwb, letting gob do the 
>> en-/decoding works.
>>
>> - The very similar code at https://play.golang.org/p/-zS7QjEJg9x, which 
>> uses MarshalBinary() and UnmarshalBinary() crashes with the panic shown 
>> above.
>>
>> What am I doing wrong?
>>
>> [I asked the same question at 
>> https://stackoverflow.com/questions/57485698/, with no answers so far]
>>
>> Many thanks,
>> Jochen
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golan...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/b19c51bc-524c-4292-915b-fc00e9289052%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/b19c51bc-524c-4292-915b-fc00e9289052%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/042b28c0-d768-4cba-94cf-159cf4231818%40googlegroups.com.


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

2019-08-14 Thread Jochen Voss
Hello,

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

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

Example:

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

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

What am I doing wrong?

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

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/b19c51bc-524c-4292-915b-fc00e9289052%40googlegroups.com.


[go-nuts] Re: HTML template behaviour changed in Go 1.8?

2017-02-26 Thread Jochen Voss
Since this is a change in behaviour since Go 1.7.5, I have now reported 
this as a bug:
https://github.com/golang/go/issues/19294

-- 
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.
For more options, visit https://groups.google.com/d/optout.


[go-nuts] HTML template behaviour changed in Go 1.8?

2017-02-26 Thread Jochen Voss
Hello,

I am using Go templates to generated the files inside an EPUB container.   
Since I switched to Go version 1.8 the output of my rendered templates 
seems to be no longer deterministic and often bit which used to be always 
there are now missing.

Minimal working (well, broken) example: https://play.golang.org/p/BnwKHNrnom
Full, messy code: https://github.com/seehuhn/epublatex

When I run the code from the "minimal working example", on my machine the 
output differs between runs:

voss@flammeri [..uhn/epublatex] go run bug.go

http://www.w3.org/1999/xhtml;>






voss@flammeri [..uhn/epublatex] go run bug.go

http://www.w3.org/1999/xhtml;>









The second run has the stylesheet line included, while it is missing in the 
first run.  On play.golang.org the code seems deterministic, but I suspect 
that may be due to caching?

Am I misusing Go templates here?  If so, what should I be doing 
differently?  Or is there a problem with templates in Go version 1.8?

Many thanks,
Jochen

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.