Re: [go-nuts] Go += Package Versioning

[David Anderson]

I should add: even though I spent several hours working through these
issues, I feel very happy about the process and outcome. I have high
confidence that I understand what vgo is doing with my module spec, and
that I know how to tweak its thinking in future. I would contrast this with
my experience with Glide. Last weekend, I tried to `glide up` this same
project, and spent 4 hours trying to resolve the resulting mayhem of
diamond dependencies and build errors. I failed, rolled back the change,
and decided MetalLB could stay on old code for a while longer. I still have
very low confidence that I understand what glide will do when I `glide up`,
or that it will produce a working result.

Additionally, some of the time spent is likely the learning curve. As
https://github.com/golang/go/issues/24032 illustrates, I was initially
confused and had to re-read some of rsc's writing to formulate my plan of
action. Despite that, I still spent less time end to end than with glide,
and I had a working build at the end of it.

- Dave

On Thu, Feb 22, 2018 at 11:20 PM, David Anderson  wrote:

> This is an experience report onboarding vgo for a relatively complex
> project (multiple binaries, vast import tree, tricky unidiomatic imports).
> I leave it here in the hopes that it guides other people, and potentially
> illustrates places where vgo falls short of great. TL;DR it went pretty
> well, modulo a couple of UX speed bumps.
>
> The result is the `vgo-test` branch of https://github.com/google/metallb/
> . Cloning that repository should allow you to `vgo test ./...`, `vgo build
> ./controller`, `vgo build ./speaker`, and a few others. I don't make any
> representation that the code does what it should, merely that it builds and
> passes tests.
>
> The resultant go.mod, https://github.com/google/
> metallb/blob/vgo-test/go.mod , is quite messy. This is mostly due to the
> number of dependencies that have no semver at all, forcing vgo to use
> commit hash "versions". The result is a lot of visual noise in the file,
> but hopefully that will improve over time as both vgo and dep nudge people
> towards semver releases.
>
> I encountered two major roadblocks on the road to `vgo test ./...`: the
> Kubernetes client library, and mixed case packages. These are
> https://github.com/golang/go/issues/24032 and https://github.com/spf13/
> jWalterWeatherman/issues/22 respectively.
>
>
> The Kubernetes client library is a worst case scenario for vgo. It
> releases a new major version every 3 months under the same module name,
> with real incompatibilities between versions; and it relies extensively on
> a transitive version lock to force a specific package selection on its
> dependents. Making this library usable from vgo required the following:
>
>- Fix up client-go in a fork
>   - Fork github.com/kubernetes/client-go to
>   github.com/danderson/client-go
>   - Add a go.mod to the fork, containing only: module "
>   k8s.io/client-go/v6"
>   - Update all internal self-references within client-go: perl -pi -e
>   's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>   - Commit the result, https://github.com/danderson/client-go/commit/
>   7d8481153a9edbf8eacc176ce29f8d58949c3a77
>   
> 
>   . Tag as v0.0.0-vgo-prototype-compat and push.
>- Make my repository use my fork of client-go:
>   - Update all uses of client-go to the new versioned package name: perl
>   -pi -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
>   - Require the right version in mod.go: require "k8s.io/client-go/v6"
>   v6.0.0
>   - Replace upstream with my fork in mod.go: replace "
>   k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go"
>   v0.0.0-vgo-prototype-compat
>
> I'm curious how we could upstream the changes I had to make to client-go.
> I had to rename module-internal imports, which will break existing non-vgo
> uses of the library, but vgo offers no alternative to this renaming that
> I'm aware of. It looks to me like there's no graceful upgrade path for this
> module. The repo structure works either for pre-vgo clients, or for vgo,
> but not both at once.
>
> The UX was lacking to explain the reason for failures, before I made any
> of the changes. Given just my repository, vgo inferred that I wanted v1.5.2
> of client-go (3+ years old), continued resolving dependencies, and
> eventually barfed when it found an import for a client-go subpackage that
> didn't exist in 1.5.2. The error was simply a bunch of "no such file or
> directory", and required some head-scratching to understand what had
> happened. Once I understood why vgo was making that decision, and how to
> correct it, vgo provided the right tools (mostly replace-with-fork) to
> correct the issue without waiting on the library to fix itself.
>
>
> The second issue I hit is 

Re: [go-nuts] Go += Package Versioning

[David Anderson]

This is an experience report onboarding vgo for a relatively complex
project (multiple binaries, vast import tree, tricky unidiomatic imports).
I leave it here in the hopes that it guides other people, and potentially
illustrates places where vgo falls short of great. TL;DR it went pretty
well, modulo a couple of UX speed bumps.

The result is the `vgo-test` branch of https://github.com/google/metallb/ .
Cloning that repository should allow you to `vgo test ./...`, `vgo build
./controller`, `vgo build ./speaker`, and a few others. I don't make any
representation that the code does what it should, merely that it builds and
passes tests.

The resultant go.mod, https://github.com/google/metallb/blob/vgo-test/go.mod
, is quite messy. This is mostly due to the number of dependencies that
have no semver at all, forcing vgo to use commit hash "versions". The
result is a lot of visual noise in the file, but hopefully that will
improve over time as both vgo and dep nudge people towards semver releases.

I encountered two major roadblocks on the road to `vgo test ./...`: the
Kubernetes client library, and mixed case packages. These are
https://github.com/golang/go/issues/24032 and
https://github.com/spf13/jWalterWeatherman/issues/22 respectively.


The Kubernetes client library is a worst case scenario for vgo. It releases
a new major version every 3 months under the same module name, with real
incompatibilities between versions; and it relies extensively on a
transitive version lock to force a specific package selection on its
dependents. Making this library usable from vgo required the following:

   - Fix up client-go in a fork
  - Fork github.com/kubernetes/client-go to
  github.com/danderson/client-go
  - Add a go.mod to the fork, containing only: module "
  k8s.io/client-go/v6"
  - Update all internal self-references within client-go: perl -pi -e
  's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
  - Commit the result,
  
https://github.com/danderson/client-go/commit/7d8481153a9edbf8eacc176ce29f8d58949c3a77
  . Tag as v0.0.0-vgo-prototype-compat and push.
   - Make my repository use my fork of client-go:
  - Update all uses of client-go to the new versioned package name: perl
  -pi -e 's#"k8s.io/client-go#"k8s.io/client-go/v6#g' **/*.go
  - Require the right version in mod.go: require "k8s.io/client-go/v6"
  v6.0.0
  - Replace upstream with my fork in mod.go: replace "
  k8s.io/client-go/v6" v6.0.0 => "github.com/danderson/client-go"
  v0.0.0-vgo-prototype-compat

I'm curious how we could upstream the changes I had to make to client-go. I
had to rename module-internal imports, which will break existing non-vgo
uses of the library, but vgo offers no alternative to this renaming that
I'm aware of. It looks to me like there's no graceful upgrade path for this
module. The repo structure works either for pre-vgo clients, or for vgo,
but not both at once.

The UX was lacking to explain the reason for failures, before I made any of
the changes. Given just my repository, vgo inferred that I wanted v1.5.2 of
client-go (3+ years old), continued resolving dependencies, and eventually
barfed when it found an import for a client-go subpackage that didn't exist
in 1.5.2. The error was simply a bunch of "no such file or directory", and
required some head-scratching to understand what had happened. Once I
understood why vgo was making that decision, and how to correct it, vgo
provided the right tools (mostly replace-with-fork) to correct the issue
without waiting on the library to fix itself.


The second issue I hit is github.com/spf13/jwalterweatherman. The actual
repository name in github is "jWalterWeatherman", but everyone (including
the package's author :) ) imports it lowercase. vgo disallows this casing
mismatch.

To solve that, I just added a require + replacement to "fix" the
case: replace "github.com/spf13/jwalterweatherman"
v0.0.0-20180109140146-7c0cea34c8ec => "github.com/spf13/jWalterWeatherman"
v0.0.0-20180109140146-7c0cea34c8ec

The version to use in that replacement was hard to come by. Since vgo was
unable to compute the right dependency list without this replacement, it
bailed without giving me any version I might use. The date+hash format is
irritating to construct by hand, but could be trivially lifted into a tool
(perhaps even vgo itself). Instead, I opted to create a separate dummy
module, with a dummy main.go that imported and used the camelCased package,
and run vgo on that. This produced a tiny go.mod with a constructed commit
hash version, which I then used in MetalLB's go.mod. It would have been
nice for vgo to help me a bit more there.

- Dave



On Tue, Feb 20, 2018 at 9:20 AM, Russ Cox  wrote:

> Hi everyone,
>
> I have a new blog post you might be interested in.
> https://research.swtch.com/vgo.
>
> I'll try to watch this thread to answer any questions.
>
> Best,
> Russ
>
>
>
> --
> You received this message 

Re: [go-nuts] All goroutines hung in futex / sleep

[Michael Andersen]

I have found that GODEBUG=schedtrace still prints when the program is
frozen but I cannot find much documentation on deciphering its output. The
full output is here:
https://gist.github.com/immesys/7f213c63c54ce60ba72d1cbc9ffcc4cb but here
are the first few lines. It looks like this is garbage collector related?

SCHED 111364ms: gomaxprocs=40 idleprocs=0 threads=78 spinningthreads=0
idlethreads=65 runqueue=31 gcwaiting=1 nmidlelocked=1 stopwait=1
sysmonwait=0
P0: status=3 schedtick=36699 syscalltick=29158 m=-1 runqsize=0 gfreecnt=45
P1: status=3 schedtick=37370 syscalltick=30563 m=-1 runqsize=0 gfreecnt=31
P2: status=3 schedtick=36650 syscalltick=29478 m=-1 runqsize=0 gfreecnt=17
P3: status=3 schedtick=42395 syscalltick=34028 m=-1 runqsize=0 gfreecnt=38
P4: status=3 schedtick=40531 syscalltick=33546 m=-1 runqsize=0 gfreecnt=27
P5: status=3 schedtick=41369 syscalltick=31884 m=-1 runqsize=0 gfreecnt=19
P6: status=3 schedtick=39302 syscalltick=32162 m=-1 runqsize=0 gfreecnt=39
P7: status=3 schedtick=39739 syscalltick=32624 m=-1 runqsize=0 gfreecnt=34
P8: status=3 schedtick=32585 syscalltick=24358 m=-1 runqsize=0 gfreecnt=45
P9: status=3 schedtick=40376 syscalltick=30399 m=-1 runqsize=0 gfreecnt=27
P10: status=3 schedtick=31018 syscalltick=22164 m=-1 runqsize=0 gfreecnt=40
P11: status=3 schedtick=32043 syscalltick=24479 m=-1 runqsize=0 gfreecnt=53
P12: status=3 schedtick=36459 syscalltick=25222 m=-1 runqsize=0 gfreecnt=21
P13: status=3 schedtick=38445 syscalltick=28317 m=-1 runqsize=0 gfreecnt=38
P14: status=3 schedtick=39533 syscalltick=28189 m=-1 runqsize=0 gfreecnt=29
P15: status=3 schedtick=37009 syscalltick=27231 m=-1 runqsize=0 gfreecnt=29
P16: status=3 schedtick=36957 syscalltick=26211 m=44 runqsize=0 gfreecnt=45
P17: status=3 schedtick=35632 syscalltick=26481 m=-1 runqsize=0 gfreecnt=48
P18: status=3 schedtick=36228 syscalltick=24751 m=-1 runqsize=0 gfreecnt=59
P19: status=3 schedtick=32479 syscalltick=22970 m=-1 runqsize=0 gfreecnt=48
P20: status=3 schedtick=34090 syscalltick=25864 m=-1 runqsize=0 gfreecnt=12
P21: status=3 schedtick=35409 syscalltick=24369 m=-1 runqsize=0 gfreecnt=6
P22: status=3 schedtick=42235 syscalltick=28607 m=-1 runqsize=0 gfreecnt=16
P23: status=3 schedtick=29733 syscalltick=19429 m=-1 runqsize=0 gfreecnt=43
P24: status=3 schedtick=34757 syscalltick=22141 m=-1 runqsize=0 gfreecnt=26
P25: status=3 schedtick=31434 syscalltick=21767 m=-1 runqsize=0 gfreecnt=23
P26: status=3 schedtick=31597 syscalltick=21657 m=-1 runqsize=0 gfreecnt=53
P27: status=3 schedtick=32539 syscalltick=22653 m=-1 runqsize=0 gfreecnt=34
P28: status=3 schedtick=29503 syscalltick=20588 m=-1 runqsize=0 gfreecnt=28
P29: status=3 schedtick=30842 syscalltick=20199 m=-1 runqsize=0 gfreecnt=41
P30: status=3 schedtick=29787 syscalltick=19492 m=-1 runqsize=0 gfreecnt=15
P31: status=3 schedtick=28226 syscalltick=19101 m=-1 runqsize=0 gfreecnt=32
P32: status=3 schedtick=34254 syscalltick=24135 m=-1 runqsize=0 gfreecnt=27
P33: status=3 schedtick=34567 syscalltick=22554 m=-1 runqsize=0 gfreecnt=36
P34: status=3 schedtick=30416 syscalltick=19722 m=-1 runqsize=0 gfreecnt=33
P35: status=1 schedtick=19536 syscalltick=13084 m=0 runqsize=0 gfreecnt=50
P36: status=3 schedtick=29336 syscalltick=19015 m=-1 runqsize=0 gfreecnt=28
P37: status=3 schedtick=29794 syscalltick=19499 m=-1 runqsize=0 gfreecnt=40
P38: status=3 schedtick=31748 syscalltick=20359 m=-1 runqsize=0 gfreecnt=35
P39: status=3 schedtick=31851 syscalltick=20260 m=-1 runqsize=0 gfreecnt=46



On Thu, Feb 22, 2018 at 8:47 PM, Michael Andersen 
wrote:

> Hi
>
> Thanks for your suggestions. This freeze happens to coincide with a larger
> number of cgo calls which in turn most likely do blocking read/write from
> sockets. How are those treated by the scheduler?
>
> I am not doing anything FUSE related, nor do I have assembly code. The
> only "interesting" stuff is the use of a c library - librados.
>
> In the goroutine dump from SIGQUIT, some stacks are followed by register
> dumps. Are those the only ones currently running? All of those are in
> runtime: 16 are in runtime.futex, 2 are in runtime.notetsleepg and one in
> runtime.gopark, which would make it seem like it was not an un-preemptable
> tight loop, but I am not sure how to parse the SIGQUIT output.
>
> Thanks
> Michael
>
>
>> I don't know what is happening with your program.
>>
>> This kind of thing can happen if you have a goroutine that is running
>> in a tight loop with no function calls or memory allocations.  The
>> current Go scheduler is non-preemptive, meaning that nothing will stop
>> that loop.  If that loop occurs while holding a lock, it could block
>> the entire rest of the program from running.  However, you would see
>> this in the stack trace.  This problem with the current scheduler is
>> https://golang.org/issue/10958.
>>
>> This kind of thing can happen if you are using an in-process FUSE file
>> system implemented by goroutines in your program.  The Go runtime
>> 

Re: [go-nuts] Float multiplication bug?

[Michael Jones]

finished. Steve, this may help explain.
https://play.golang.org/p/tcy1QFZb-Fp


On Thu, Feb 22, 2018 at 5:35 PM, Michael Jones 
wrote:

> https://play.golang.org/p/0XRLg6-6uPk
>
> On Thu, Feb 22, 2018 at 1:09 PM, andrey mirtchovski  > wrote:
>
>> in the first Printf "area" is truncated. try %.40f to see the real
>> value, which is more like:
>>
>> 262256.4523014638689346611499786376953125
>>
>> plugging that in as h2 will result in
>> 39709429597.0098280725069344043731689453125 (according to wolfram
>> alpha)
>>
>> On Thu, Feb 22, 2018 at 1:32 PM,   wrote:
>> >
>> >  Hello Everyone,
>> >
>> >  This looks like a Golang bug to me. What do you all think?
>> >
>> >  I have this function ...
>> >
>> >> func getArea(base, side int64) float64 {
>> >> var height, fSide, area float64
>> >> fSide = float64(side)
>> >> halfBase := float64(base) / 2.0
>> >> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>> >> area = halfBase * height
>> >> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
>> area)
>> >
>> >
>> >>
>> >> hb2 := 151414.5
>> >> h2 := 262256.452301
>> >> fmt.Printf("Area 2: %f\n", hb2 * h2)
>> >
>> >
>> >>
>> >> return area
>> >> }
>> >
>> >
>> > When I call it with `result := getArea(302829, 302828)`,   I get this
>> output
>> > ...
>> >
>> >> halfBase: 151414.50, height: 262256.452301, Area:
>> 39709429597.00
>> >> Area 2: 39709429596.929764
>> >
>> >
>> > I could see how some kind of rounding could produce the first Area
>> value.
>> > But in that case, why wouldn't Area2 be rounded as well?
>> >
>> > --
>> > 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.
>>
>> --
>> 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.
>>
>
>
>
> --
> Michael T. Jones
> michael.jo...@gmail.com
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] All goroutines hung in futex / sleep

[Michael Andersen]

Hi

Thanks for your suggestions. This freeze happens to coincide with a larger
number of cgo calls which in turn most likely do blocking read/write from
sockets. How are those treated by the scheduler?

I am not doing anything FUSE related, nor do I have assembly code. The only
"interesting" stuff is the use of a c library - librados.

In the goroutine dump from SIGQUIT, some stacks are followed by register
dumps. Are those the only ones currently running? All of those are in
runtime: 16 are in runtime.futex, 2 are in runtime.notetsleepg and one in
runtime.gopark, which would make it seem like it was not an un-preemptable
tight loop, but I am not sure how to parse the SIGQUIT output.

Thanks
Michael


> I don't know what is happening with your program.
>
> This kind of thing can happen if you have a goroutine that is running
> in a tight loop with no function calls or memory allocations.  The
> current Go scheduler is non-preemptive, meaning that nothing will stop
> that loop.  If that loop occurs while holding a lock, it could block
> the entire rest of the program from running.  However, you would see
> this in the stack trace.  This problem with the current scheduler is
> https://golang.org/issue/10958.
>
> This kind of thing can happen if you are using an in-process FUSE file
> system implemented by goroutines in your program.  The Go runtime
> believes that some system calls, such as pipe or socket, never block.
> If you have somehow set things up so that those system calls enter
> your FUSE file system and depend on some other goroutine running, it
> is possible that that goroutine will never be scheduled.  I don't know
> of any bugs like this at present but they have existed in the past.
> Of course if you aren't using a FUSE file system then this is not the
> problem.
>
> This kind of thing can happen if you use assembler code to do a
> blocking operation, or if you use syscall.Rawsyscall to call a system
> call that blocks.  That can confuse the scheduler and lead to a
> deadlock.  Don't do that.
>
> None of these are likely, but you asked for suggestions, and that's
> what I've come up with.
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] All goroutines hung in futex / sleep

[Michael Andersen]

Hi all

I have a complex program that when under load will very reproducibly freeze 
every goroutine simultaneously. It then makes no progress at all, even if 
left for hours. I'm posting here because I don't know of anything that can 
cause this behavior so I don't even know where to begin debugging. When it 
"freezes", every goroutine appears to be no longer scheduled, no matter how 
simple. Even this at the start of main() ceases to print to stdout:

go func() {
for {
time.Sleep(3 * time.Second)
fmt.Printf("Still alive\n")
}
}()

The system is nowhere near OOM, the goroutine count is large but reasonable 
just before the freeze (<2k). After it freezes the process is still 
running, and attaching sysdig shows it is stuck spinning in futex, with 
only this showing up over and over:

637779 17:21:56.254826712 20 prog (43085) < futex res=-110(ETIMEDOUT) 
637782 17:21:56.254827305 20 prog (43085) > futex addr=10D5FA0 
op=0(FUTEX_WAIT) val=0 
637783 17:21:56.254828132 20 prog (43085) > switch next=0 pgft_maj=0 
pgft_min=60361 vm_size=20710168 vm_rss=10792276 vm_swap=0 

The "frozen" program still responds to SIGQUIT and dumps out the 
goroutines, but given that this is not a minimal reproducer (which I have 
not managed to make) I don't know which parts of that are useful. I put all 
of it 
here: https://gist.github.com/immesys/0b741e4ea18979614d8419fa9c007098 . 

My main question is what sort of bugs can cause the whole program to lock 
up? Even if some goroutines were deadlocked, why would that stop everything 
from net/http/pprof to a printf loop from working?

Some tidbits:

I have a core dump so I can inspect things with delve if I know what I am 
looking for
Building/running with -race doesn't print anything
I came across this 
(https://groups.google.com/forum/#!msg/golang-nuts/PMm8nH0yaoA/mb-cnKmZlb4J) 
which describes a similar occurency but I don't interact with syslog, at 
least not directly.
I am getting this on go 1.10 but I rebuilt on 1.9.4 and I get the same 
behavior.
I am on linux amd64 kernel 4.10
It only takes about two minutes to reproduce.
When frozen, only a single CPU core is pegged, the rest of the system is 
fine.

Any help at all would be appreciated, thanks
Michael



-- 
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.

Re: [go-nuts] Float multiplication bug?

[Michael Jones]

https://play.golang.org/p/0XRLg6-6uPk

On Thu, Feb 22, 2018 at 1:09 PM, andrey mirtchovski 
wrote:

> in the first Printf "area" is truncated. try %.40f to see the real
> value, which is more like:
>
> 262256.4523014638689346611499786376953125
>
> plugging that in as h2 will result in
> 39709429597.0098280725069344043731689453125 (according to wolfram
> alpha)
>
> On Thu, Feb 22, 2018 at 1:32 PM,   wrote:
> >
> >  Hello Everyone,
> >
> >  This looks like a Golang bug to me. What do you all think?
> >
> >  I have this function ...
> >
> >> func getArea(base, side int64) float64 {
> >> var height, fSide, area float64
> >> fSide = float64(side)
> >> halfBase := float64(base) / 2.0
> >> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
> >> area = halfBase * height
> >> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height,
> area)
> >
> >
> >>
> >> hb2 := 151414.5
> >> h2 := 262256.452301
> >> fmt.Printf("Area 2: %f\n", hb2 * h2)
> >
> >
> >>
> >> return area
> >> }
> >
> >
> > When I call it with `result := getArea(302829, 302828)`,   I get this
> output
> > ...
> >
> >> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
> >> Area 2: 39709429596.929764
> >
> >
> > I could see how some kind of rounding could produce the first Area value.
> > But in that case, why wouldn't Area2 be rounded as well?
> >
> > --
> > 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.
>
> --
> 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.
>



-- 
Michael T. Jones
michael.jo...@gmail.com

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

Re: [go-nuts] vgo and enterprise GitHub servers

[andrey mirtchovski]

can you create an issue for this? we're also suffering from the same
internally. please make it about GitHub Enterprise, as that is what
they call it :)

On Thu, Feb 22, 2018 at 5:16 PM, Richard Wilkes  wrote:
> Is it expected that vgo should work with enterprise GitHub servers at this
> point in time? When trying it out, I find I'm getting messages like this
> during import resolution:
>
>> vgo: resolving import "jaxf-github.fanatics.corp/forge/furnace"
>> findRepo: XML syntax error on line 25: unescaped < inside quoted string
>> vgo: import "jaxf-github.fanatics.corp/forge/ratelimiter" ->
>> import "jaxf-github.fanatics.corp/forge/furnace": unknown VCS, Repo: git,
>> https://jaxf-github.fanatics.corp/forge/furnace.git
>
>
> Imports from GitHub itself are resolving fine. Anyway, any insight as to
> what might be going wrong would be appreciated. The error message isn't
> terribly enlightening to me, I'm afraid.
>
> - Rich
>
> --
> 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.

-- 
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] math integer sizes

[Jason Gade]

I see that the math/bits package has a UintSize constant, and math has 
Max types. Why doesn't math have MaxInt and MaxUint?

Yes, I know that these are derivative by themselves, but can they be 
included in the standard library without breaking the Go Compatibility 
promise?

-- 
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.

Re: [go-nuts] http.shutdownPollInterval documentation

[Ian Lance Taylor]

On Thu, Feb 22, 2018 at 1:50 PM, Sridhar  wrote:
>
> In https://golang.org/src/net/http/server.go the documentation for
> shutdownPollInterval (admittedly unexported) reads:
>
> // Ideally we could find a solution that doesn't involve polling,
>
> // but which also doesn't have a high runtime cost (and doesn't
>
> // involve any contentious mutexes), but that is left as an
>
> // exercise for the reader.
>
> Is this a remnant from a book on Go ? If so which one ?

It's not from a book.  "Left as an exercise for the reader" is just a
saying.  It means, approximately, "we're not sure how to do it, but if
you can figure it out, please send a fix."

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

Re: [go-nuts] Go += Package Versioning

[Russ Cox]

On Tue, Feb 20, 2018 at 5:14 PM, Dave MacFarlane  wrote:

> I really like this, except for the claim that it the blog post that it
> will eliminate vendoring and deprecate GOPATH and the problems that
> will cause for backwards compatibility for things that are currently
> using them. If this is going to result in removing language features
> (ie. vendoring), shouldn't it be in Go2, not Go 1.11?
>

The proposal is only to remove vendoring when working with modules.
Non-module repos with vendor directories will keep building at least past
Go 1.11,
perhaps even forever.


> The other question I have is: where does the module name come from if
> you don't have a "// import" comment on the package, since it can't be
> filesystem based (because you're explicitly outside of GOPATH..)
>

It comes from go.mod. It only has to come from somewhere else if go.mod is
missing. That was a cute trick to ease transition more than anything else.
The places that vgo looks to try to guess a module path when filling in the
initial go.mod are:

- // import comments in the top-level directory or immediate
subdirectories
- Godeps/Godeps.json
- vendor/vendor.json
- .git/config

Perhaps this is not worth keeping in the real integration, but it was a
nice way to get off the ground.

Best,
Russ

-- 
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.

Re: [go-nuts] Go += Package Versioning

[Russ Cox]

On Tue, Feb 20, 2018 at 4:07 PM, David Anderson  wrote:

> On Tue, Feb 20, 2018 at 11:37 AM, Russ Cox  wrote:
>
>> On Tue, Feb 20, 2018 at 1:55 PM, David Anderson  wrote:
>>
>>> I love this. I want it now.
>>>
>>
>> go get -u golang.org/x/vgo :-)
>>
>> I've struggled with `glide` and `dep` dependency hell a lot in my Go
>>> projects (especially those that use the Kubernetes client library, which
>>> abuses "I, the library author, can define byzantine constraints on my
>>> users" to the extreme). The way I've described it informally is that
>>> traditional "arbitrary version selection" algorithms create the wrong
>>> incentive structure for library authors, in the sense that they have all
>>> the power to lock versions arbitrarily, but bear none of the pain
>>> associated with their decisions - instead, the binary author at the apex of
>>> the dependency tree gets that pain. "Authority without responsibility" is
>>> the death of many incentive structures.
>>>
>>
>> Yes, I'll make that point again in tomorrow's posts elaborating minimal
>> version selection, but I think this is probably the most important
>> algorithmic policy detail. You get total control over your own build. You
>> only get limited control over other people's builds that happen to import
>> your code.
>>
>
> Big +1. I'm curious about your ideas on how to manage the transition from
> a glide/dep world to a vgo world. I look forward to reading more about
> that, assuming you have an article queued to discuss that facet :).
>

I don't have an article about this. There are two parts to the answer. The
first is that vgo reads all these tools' lock files and records the things
listed there are minimum requirements, as a starting point. I expect this
will be good enough for many projects. For example, on Tuesday when vgo was
first released, before anything had time to convert, you could git clone
upspin or dep, cd into the checkout (anywhere, not just in GOPATH), and
start working. Vgo seeded go.mod with the Gopkg.lock file. The second part
is that, as Sam posted , we are
trying to work out a way to contract him to build tools to help with more
complex conversions.

One thought that I hope you'll cover there: immutability. Reading through
> the vgo tour, it seems to assume that once v5.6.7 has been released, that
> .zip and its declared dependencies will never change.
>

You've probably seen this by now, but: research.swtch.com/vgo-repro.

Best,
Russ

-- 
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.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

[David Collier-Brown]

On Thursday, February 22, 2018 at 6:43:07 AM UTC-5, alex@gmail.com 
wrote:
>
> Yup, the package I'm working on really cannot have 2 instances even in 
> different import paths as it deals with a shared resource and code that 
> must be run on the main thread.
> So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a 
> central v0 where all the v1, v2, etc.. packages import.
>
> Daisy chaining would mean I would only have to code API translations for 
> the latest API but then it's debug hell and if one version in the chain 
> breaks, 
> it means fixing all the newer versions. Also there's a performance hit 
> going through many translations.
>

If I understand you correctly, v2's foo() has to call v1's foo() in the 
daisy-chain case.   This was one of the two common cases in Multics (and 
Solaris, and Linux glibc).  The other case was v1's foo() calling a wrapper 
around v2's foo().

We called these "updaters" and "downdaters", and implemented them in the 
same library, under the covers.

Feel free to drop me a line if you are interested, and see 
also 
https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-avoiding-an-np-complete-problem/
 
fore some of the background.

--dave
dav...@spamcop.net

-- 
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] vgo and enterprise GitHub servers

[Richard Wilkes]

Is it expected that vgo should work with enterprise GitHub servers at this 
point in time? When trying it out, I find I'm getting messages like this 
during import resolution:

vgo: resolving import "jaxf-github.fanatics.corp/forge/furnace"
> findRepo: XML syntax error on line 25: unescaped < inside quoted string
> vgo: import "jaxf-github.fanatics.corp/forge/ratelimiter" ->
> import "jaxf-github.fanatics.corp/forge/furnace": unknown VCS, Repo: git, 
> https://jaxf-github.fanatics.corp/forge/furnace.git


Imports from GitHub itself are resolving fine. Anyway, any insight as to 
what might be going wrong would be appreciated. The error message isn't 
terribly enlightening to me, I'm afraid.

- Rich

-- 
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.

Re: [go-nuts] Experience report on coming to Go from a C perspective

[Devon H. O'Dell]

I like this, thanks for pointing me to it. I think that's a good way
to go for about half of it; if make / new can be considered as well,
that'd be great. I suppose adg's point still stands in terms of gofmt
output and a detailed proposal? I agree such a change should only be
considered for Go 2.

--dho

2018-02-22 15:37 GMT-08:00 'Bryan Mills' via golang-nuts
:
> You might be interested in https://golang.org/issue/12854 for maps, slices,
> and structs.
>
> (It wouldn't help with channels, because there is currently no such thing as
> a channel literal.)
>
> On Thursday, February 22, 2018 at 5:32:40 PM UTC-5, Devon H. O'Dell wrote:
>>
>> 2018-02-22 14:19 GMT-08:00 Caleb Spare :
>> > I occasionally run into this, but in my experience it's exclusively with
>> > maps:
>>
>> I think all of the cases I ran into this were for maps and channels.
>>
>> > - Initializing empty slices is ~never necessary; (in my opinion the
>> > "members: []int{}" from the blog post is a code smell).
>>
>> Probably, but as mentioned in the post, this example was to illustrate
>> the point. It was also to keep consistency with the C example. This
>> would have been convoluted to do for maps or channels.
>>
>> > - Channels need initialization but that's where the important buffered
>> > vs.
>> > unbuffered choice is made, so I'm happy that's explicit. (I suppose you
>> > can
>> > say the same about initializing maps with a size, but that's fairly rare
>> > in
>> > my experience.)
>>
>> That's fair, but why require expressing the type in the call to make?
>> You already know the type of the channel; you should only need to
>> specify the buffer length (if any). Type inference is so pervasive
>> through the rest of the language; the compiler should absolutely be
>> able to help here.
>>
>> For example:
>>
>> return {c: make(chan T)}
>> return {c: make(chan T, 100)}
>> return {m: make()}
>> return {m: make(100)}
>>
>> and
>>
>> return {c: make()}
>> return {c: make(100)}
>> return {m: make()}
>> return {m: make(100)}
>>
>> I think the latter set of examples is much nicer. Yes, you don't see
>> _what_ make is allocating, but you knew that if you looked at the
>> specification for the type (which you probably already did). Other
>> idiomatic expressions already hide this information. For example, c :=
>> foo.c also doesn't tell you what the type of the assignment is. And
>> bar := foo is even more indirect.
>>
>> --dho
>>
>> > - If the struct has a nested pointer to another struct type, then having
>> > it
>> > be nil is definitely what you want since the nested type may or may not
>> > have
>> > a valid zero value.
>> >
>> > On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell 
>> > wrote:
>> >>
>> >> Hi all,
>> >>
>> >> It's been some time since I really contributed much of anything to the
>> >> project (sorry!), but after 8 years, I'm finally writing Go outside of
>> >> the project itself (and outside of porting efforts). I was lamenting
>> >> to some coworkers about the lack of a comparable feature to C's
>> >> "malloc idiom" and they suggested I write an experience report on it.
>> >> I wrote the bulk of the article a month ago, but finally put in some
>> >> finishing touches and published.
>> >>
>> >> For whatever it's worth (probably not much):
>> >> https://9vx.org/post/a-malloc-idiom-in-go/
>> >>
>> >> --dho
>> >>
>> >> --
>> >> 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.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >
>> >
>
> --
> 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.

-- 
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] Re: extract rsa-encrypted public-key from tls-certificate (pem-format)

[Maciej Gałkowski]

Hi, 
I believe you want something like 
this: https://play.golang.org/p/IL8f5AqpeQ3

This example is quick and dirty, but it should be a good starting point for 
you. I am assuming that both public & private keys are RSA keys, for EC 
keys the process is similar. 
Also, if you decide to copy past the code, please handle the errors 
properly!

Golang have quite good crypto library fortunately.

Regards,
Maciej

W dniu czwartek, 22 lutego 2018 16:30:30 UTC użytkownik Andro Yamamoto 
napisał:
>
> Hi,
>
>
> What I have:
> - tls-certificate (x.509 format, pem encoded)
> - within the tls-certificate -> public-key (rsa encrypted)
> - corresponding private-key (pem encoded, rsa encrypted)
>
>
> What I want:
> - validate pem encoded private-keys // (something like 'openssl rsa -in 
> client.key -check' )
> - validate key-pair (if private-key is matching certificate) // (something 
> like is key matching certificate running -> 'openssl x509 -noout -modulus 
> -in client.cert | openssl md5' == 'openssl rsa -noout -modulus -in 
> PRIVATEKEY.key | openssl md5')
>
>
> What I tried:
>
> *func *CheckKeyPair(clientcert, key string) error {
>
>
>block, _ := pem.Decode([]byte(clientcert))  // decode pem 
> encoded tls certificate
>
>cert,_ := x509.ParseCertificate(block.Bytes)  // parse certificate 
> (get type x509.*Certificate)
>
>fmt.Println(reflect.TypeOf(cert.PublicKey))  // print parsed 
> public-key from certificate (get type *rsa.PublicKey)
>
>   
>
> *return *nil
>
> }
>
> I fill this function with an the tls-certificate (type string) and 
> private-key (type string).
>
> I've already started several experiments. That's why I haven't posted my 
> mischief yet. 
> I thought I would use this function, to validate the key-pair. -> 
> tls.X509KeyPair (https://golang.org/pkg/crypto/tls/#X509KeyPair)
> Does anyone know how to move on?
>
> Best,
> A
>
>
>

-- 
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] Re: Build started to fail with 1.10

[Nic Pottier]

This is almost certainly because your .travis file is specifying your 
version as `1.10` vs `"1.10"`

So your build is building with go 1.1 instead of 1.10.

Ran into this myself this morning.

-Nic

On Thursday, February 22, 2018 at 11:38:43 AM UTC-5, Владислав Митов wrote:
>
> Hey guys, 
>
> One of my build started failing with 1.10. Basically I'm building a 
> wrapper around a C library and it fails with: 
>
> # runtime/cgo
> gcc_libinit.c: In function '_cgo_try_pthread_create':
> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>   struct timespec ts;
>   ^~
> gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
> [-Werror=implicit-function-declaration]
>nanosleep(, nil);
>^
> gcc_libinit.c:97:18: error: unused variable 'ts' [-Werror=unused-variable]
>   struct timespec ts;
>   ^~
> cc1: all warnings being treated as errors
> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>
> Any hint's what's causing this? 
>
> Cheers, 
> Vladi
>

-- 
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.

Re: [go-nuts] Experience report on coming to Go from a C perspective

['Bryan Mills' via golang-nuts]

You might be interested in https://golang.org/issue/12854 for maps, slices, 
and structs.

(It wouldn't help with channels, because there is currently no such thing 
as a channel literal.)

On Thursday, February 22, 2018 at 5:32:40 PM UTC-5, Devon H. O'Dell wrote:
>
> 2018-02-22 14:19 GMT-08:00 Caleb Spare : 
> > I occasionally run into this, but in my experience it's exclusively with 
> > maps: 
>
> I think all of the cases I ran into this were for maps and channels. 
>
> > - Initializing empty slices is ~never necessary; (in my opinion the 
> > "members: []int{}" from the blog post is a code smell). 
>
> Probably, but as mentioned in the post, this example was to illustrate 
> the point. It was also to keep consistency with the C example. This 
> would have been convoluted to do for maps or channels. 
>
> > - Channels need initialization but that's where the important buffered 
> vs. 
> > unbuffered choice is made, so I'm happy that's explicit. (I suppose you 
> can 
> > say the same about initializing maps with a size, but that's fairly rare 
> in 
> > my experience.) 
>
> That's fair, but why require expressing the type in the call to make? 
> You already know the type of the channel; you should only need to 
> specify the buffer length (if any). Type inference is so pervasive 
> through the rest of the language; the compiler should absolutely be 
> able to help here. 
>
> For example: 
>
> return {c: make(chan T)} 
> return {c: make(chan T, 100)} 
> return {m: make()} 
> return {m: make(100)} 
>
> and 
>
> return {c: make()} 
> return {c: make(100)} 
> return {m: make()} 
> return {m: make(100)} 
>
> I think the latter set of examples is much nicer. Yes, you don't see 
> _what_ make is allocating, but you knew that if you looked at the 
> specification for the type (which you probably already did). Other 
> idiomatic expressions already hide this information. For example, c := 
> foo.c also doesn't tell you what the type of the assignment is. And 
> bar := foo is even more indirect. 
>
> --dho 
>
> > - If the struct has a nested pointer to another struct type, then having 
> it 
> > be nil is definitely what you want since the nested type may or may not 
> have 
> > a valid zero value. 
> > 
> > On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell  > 
> > wrote: 
> >> 
> >> Hi all, 
> >> 
> >> It's been some time since I really contributed much of anything to the 
> >> project (sorry!), but after 8 years, I'm finally writing Go outside of 
> >> the project itself (and outside of porting efforts). I was lamenting 
> >> to some coworkers about the lack of a comparable feature to C's 
> >> "malloc idiom" and they suggested I write an experience report on it. 
> >> I wrote the bulk of the article a month ago, but finally put in some 
> >> finishing touches and published. 
> >> 
> >> For whatever it's worth (probably not much): 
> >> https://9vx.org/post/a-malloc-idiom-in-go/ 
> >> 
> >> --dho 
> >> 
> >> -- 
> >> 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 . 
> >> For more options, visit https://groups.google.com/d/optout. 
> > 
> > 
>

-- 
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.

Re: [go-nuts] Go += Package Versioning

[jimmy frasche]

Is there a story for a module that changes domains, like when google
code shutdown or moving to a custom domain for vanity import paths?

Having directives to say "find earlier versions here" or "find later
versions" here seems like it would help downgrades/upgrades. If one of
those old domains stops existing entirely the chain would be broken,
certainly, but it still seems like it would be useful.

-- 
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.

BSD Re: [go-nuts] Experience report on coming to Go from a C perspective

[Bakul Shah]

On Feb 22, 2018, at 2:16 PM, Devon H. O'Dell  wrote:
> 
> (Re-adding list in here with Bakul's okay.)
> 
> 2018-02-22 12:27 GMT-08:00 Bakul Shah :
>> On Thu, 22 Feb 2018 12:02:35 -0800 "Devon H. O'Dell"  
>> wrote:
>>> Hi all,
>>> 
>>> It's been some time since I really contributed much of anything to the
>>> project (sorry!), but after 8 years, I'm finally writing Go outside of
>>> the project itself (and outside of porting efforts). I was lamenting
>>> to some coworkers about the lack of a comparable feature to C's
>>> "malloc idiom" and they suggested I write an experience report on it.
>>> I wrote the bulk of the article a month ago, but finally put in some
>>> finishing touches and published.
>> 
>> I still run FreeBSD at home and test any go programs I write
>> on it as well as MacOS (and sometime on plan9)! But FreeBSD
>> support seems to be falling further and further behind.
> 
> I'm aware of some strange crash, but I don't have any FreeBSD systems
> anymore to investigate. Are there other areas that FreeBSD is lagging
> in? (Maybe tangent should go to separate thread :))

Go compiles and runs fine but packages don't always. For 
instance I was trying to use shiny but indirectly it depends
on shmat(2) & friends. This means adding syscall support in
golang.org/x/sys/unix for FreeBSD.  Overall (not just for X
windows or shiny) there is support for various flavors of BSDs
but it is quite haphazard. This is probably due to the small 
number of people developing Go code for the BSDs. It is quite
easy to write portable code in Go (compared to most languages)
but a systematic effort is needed to find and fix all the
porting problems - most of them are typically quite minor.

-- 
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.

Re: [go-nuts] Float multiplication bug?

[andrey mirtchovski]

sorry, i just realized that i said 'area' but meant 'height' in my
previous email.

On Thu, Feb 22, 2018 at 2:09 PM, andrey mirtchovski
 wrote:
> in the first Printf "area" is truncated. try %.40f to see the real
> value, which is more like:
>
> 262256.4523014638689346611499786376953125
>
> plugging that in as h2 will result in
> 39709429597.0098280725069344043731689453125 (according to wolfram
> alpha)
>
> On Thu, Feb 22, 2018 at 1:32 PM,   wrote:
>>
>>  Hello Everyone,
>>
>>  This looks like a Golang bug to me. What do you all think?
>>
>>  I have this function ...
>>
>>> func getArea(base, side int64) float64 {
>>> var height, fSide, area float64
>>> fSide = float64(side)
>>> halfBase := float64(base) / 2.0
>>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>>> area = halfBase * height
>>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height, area)
>>
>>
>>>
>>> hb2 := 151414.5
>>> h2 := 262256.452301
>>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>>
>>
>>>
>>> return area
>>> }
>>
>>
>> When I call it with `result := getArea(302829, 302828)`,   I get this output
>> ...
>>
>>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>>> Area 2: 39709429596.929764
>>
>>
>> I could see how some kind of rounding could produce the first Area value.
>> But in that case, why wouldn't Area2 be rounded as well?
>>
>> --
>> 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.

-- 
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.

Re: [go-nuts] Experience report on coming to Go from a C perspective

[Devon H. O'Dell]

2018-02-22 14:19 GMT-08:00 Caleb Spare :
> I occasionally run into this, but in my experience it's exclusively with
> maps:

I think all of the cases I ran into this were for maps and channels.

> - Initializing empty slices is ~never necessary; (in my opinion the
> "members: []int{}" from the blog post is a code smell).

Probably, but as mentioned in the post, this example was to illustrate
the point. It was also to keep consistency with the C example. This
would have been convoluted to do for maps or channels.

> - Channels need initialization but that's where the important buffered vs.
> unbuffered choice is made, so I'm happy that's explicit. (I suppose you can
> say the same about initializing maps with a size, but that's fairly rare in
> my experience.)

That's fair, but why require expressing the type in the call to make?
You already know the type of the channel; you should only need to
specify the buffer length (if any). Type inference is so pervasive
through the rest of the language; the compiler should absolutely be
able to help here.

For example:

return {c: make(chan T)}
return {c: make(chan T, 100)}
return {m: make()}
return {m: make(100)}

and

return {c: make()}
return {c: make(100)}
return {m: make()}
return {m: make(100)}

I think the latter set of examples is much nicer. Yes, you don't see
_what_ make is allocating, but you knew that if you looked at the
specification for the type (which you probably already did). Other
idiomatic expressions already hide this information. For example, c :=
foo.c also doesn't tell you what the type of the assignment is. And
bar := foo is even more indirect.

--dho

> - If the struct has a nested pointer to another struct type, then having it
> be nil is definitely what you want since the nested type may or may not have
> a valid zero value.
>
> On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell 
> wrote:
>>
>> Hi all,
>>
>> It's been some time since I really contributed much of anything to the
>> project (sorry!), but after 8 years, I'm finally writing Go outside of
>> the project itself (and outside of porting efforts). I was lamenting
>> to some coworkers about the lack of a comparable feature to C's
>> "malloc idiom" and they suggested I write an experience report on it.
>> I wrote the bulk of the article a month ago, but finally put in some
>> finishing touches and published.
>>
>> For whatever it's worth (probably not much):
>> https://9vx.org/post/a-malloc-idiom-in-go/
>>
>> --dho
>>
>> --
>> 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.
>
>

-- 
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.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018 at 10:27 PM  wrote:

> On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote:
>>
>> Daisy chaining would mean I would only have to code API translations for
>>> the latest API but then it's debug hell and if one version in the chain
>>> breaks,
>>> it means fixing all the newer versions. Also there's a performance hit
>>> going through many translations.
>>>
>>
>> I don't believe so. There's may be an increase in compile time though.
>>
>
> I was thinking of cases where the behavior is so different it needed to
> emulate old behavior so over time all the emulation adds up and would be
> more complex than just emulating based on v0/latest.
>
>
>> The real question though, is how other package management semantics would
>> solve this better. Is this actually accidental complexity or just
>> systematic complexity caused by "I need to both break compatibility *and*
>> have different versions coexist *and* still share Singleton state between
>> them?
>>
>
> The vgo blogs talk about coexistence of multiple versions so was just
> figuring out if it makes sense and how would that look like.
> I just like to be prepared for worst case scenarios, so stuff I was
> worried about may or may not actually happen. But better be safe than sorry.
>

Sure, I'm just saying that if you start with how you'd do this in a more
familiar packaging scheme, you might be able to transfer it to vgo - I'm
not convinced vgo makes this at all harder, it's simply a hard problem to
begin with.


> --
> 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.
>

-- 
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.

Re: [go-nuts] Experience report on coming to Go from a C perspective

[Caleb Spare]

I occasionally run into this, but in my experience it's exclusively with
maps:

- Initializing empty slices is ~never necessary; (in my opinion the
"members: []int{}" from the blog post is a code smell).
- Channels need initialization but that's where the important buffered vs.
unbuffered choice is made, so I'm happy that's explicit. (I suppose you can
say the same about initializing maps with a size, but that's fairly rare in
my experience.)
- ​If the struct has a nested pointer to another struct type, then having
it be nil is definitely what you want since the nested type may or may not
have a valid zero value.

On Thu, Feb 22, 2018 at 12:02 PM, Devon H. O'Dell 
wrote:

> Hi all,
>
> It's been some time since I really contributed much of anything to the
> project (sorry!), but after 8 years, I'm finally writing Go outside of
> the project itself (and outside of porting efforts). I was lamenting
> to some coworkers about the lack of a comparable feature to C's
> "malloc idiom" and they suggested I write an experience report on it.
> I wrote the bulk of the article a month ago, but finally put in some
> finishing touches and published.
>
> For whatever it's worth (probably not much):
> https://9vx.org/post/a-malloc-idiom-in-go/
>
> --dho
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Experience report on coming to Go from a C perspective

[Devon H. O'Dell]

(Re-adding list in here with Bakul's okay.)

2018-02-22 12:27 GMT-08:00 Bakul Shah :
> On Thu, 22 Feb 2018 12:02:35 -0800 "Devon H. O'Dell"  
> wrote:
>> Hi all,
>>
>> It's been some time since I really contributed much of anything to the
>> project (sorry!), but after 8 years, I'm finally writing Go outside of
>> the project itself (and outside of porting efforts). I was lamenting
>> to some coworkers about the lack of a comparable feature to C's
>> "malloc idiom" and they suggested I write an experience report on it.
>> I wrote the bulk of the article a month ago, but finally put in some
>> finishing touches and published.
>
> I still run FreeBSD at home and test any go programs I write
> on it as well as MacOS (and sometime on plan9)! But FreeBSD
> support seems to be falling further and further behind.

I'm aware of some strange crash, but I don't have any FreeBSD systems
anymore to investigate. Are there other areas that FreeBSD is lagging
in? (Maybe tangent should go to separate thread :))

>> For whatever it's worth (probably not much):
>> https://9vx.org/post/a-malloc-idiom-in-go/
>
> I think you are suggesting inferring types of subobjects given
> that the parent type specified in a literal. So that you can
> type
>
> func NewSet(sz int)*Set {
> return {cap: sz, members:{}}
> }
>
> Or even
>
> func NewSet(sz int)*Set {
> return &{cap: sz, members:{}}
> }
>
> Or even
>
> func NewSet(sz int)*Set {
> return &{sz, {}}
> }
>
> I agree. Though some people won't like the extreme brevity of
> the last form!

Yes, this is exactly the idea. I like this empty-compound-literal
form, but I agree that the last form is probably asking for trouble.
For example, if the last two members of type Set are e.g. *Foo and
map[T]T', you probably meant to allocate the map. I think compound
literals for structs should retain field names. I definitely like the
second idea where you infer the type based on the return value (after
all, it _is_ known!).

--dho

-- 
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.

Re: [go-nuts] Re: Experience report on coming to Go from a C perspective

[Devon H. O'Dell]

Thanks for pointing this out; I wasn't aware of this new syntax. I
think this gets to about halfway of what I'd hope for. That said, I'd
really like to avoid needing to jump through the hoop of indirection
for this. I occasionally find it hard to recognize what the type of a
thing is due to heavy use of type inference, so I'd hope for something
that doesn't require me to do additional backtracking to figure out
what the real underlying type is.

2018-02-22 12:31 GMT-08:00  :
> Have you considered using the new type alias feature introduced in 1.9? Line
> so:
>
> https://play.golang.org/p/6HK8qcuh9UU
>
> This would allow you to change the type of the map in a singe place (the
> type alias) and all the {} or make would adapt appropriately.
> Disclaimer: I am not espousing this style, just pointing out that it is
> possible.
>
>
>
> On Thursday, February 22, 2018 at 3:03:13 PM UTC-5, Devon H. O'Dell wrote:
>>
>> Hi all,
>>
>> It's been some time since I really contributed much of anything to the
>> project (sorry!), but after 8 years, I'm finally writing Go outside of
>> the project itself (and outside of porting efforts). I was lamenting
>> to some coworkers about the lack of a comparable feature to C's
>> "malloc idiom" and they suggested I write an experience report on it.
>> I wrote the bulk of the article a month ago, but finally put in some
>> finishing touches and published.
>>
>> For whatever it's worth (probably not much):
>> https://9vx.org/post/a-malloc-idiom-in-go/
>>
>> --dho
>
> --
> 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.

-- 
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.

Re: [go-nuts] Build started to fail with 1.10

[Владислав Митов]

I'm not sure where the issue is but I tried with 1.9 - both locally and in 
Travis it passes with the same code. 
https://github.com/miracl/gomiracl/compare/fix-build?expand=1 - code 
https://travis-ci.org/miracl/gomiracl/jobs/345000314 - build

On Thursday, February 22, 2018 at 6:48:34 PM UTC+2, Ian Lance Taylor wrote:
>
> On Thu, Feb 22, 2018 at 8:38 AM, Владислав Митов 
>  wrote: 
> > 
> > One of my build started failing with 1.10. Basically I'm building a 
> wrapper 
> > around a C library and it fails with: 
> > 
> > # runtime/cgo 
> > gcc_libinit.c: In function '_cgo_try_pthread_create': 
> > gcc_libinit.c:97:18: error: storage size of 'ts' isn't known 
> >   struct timespec ts; 
> >   ^~ 
> > gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
> > [-Werror=implicit-function-declaration] 
> >nanosleep(, nil); 
> >^ 
> > gcc_libinit.c:97:18: error: unused variable 'ts' 
> [-Werror=unused-variable] 
> >   struct timespec ts; 
> >   ^~ 
> > cc1: all warnings being treated as errors 
> > https://travis-ci.org/miracl/gomiracl/jobs/344782123 
> > 
> > Any hint's what's causing this? 
>
> You say this started failing with 1.10.  That file 
> (runtime/cgo/gcc_libinit.c) hasn't changed since 1.9, so I think 
> something else must have changed. 
>
> timespec and nanosleep are normally defined in .  What system 
> are you using? 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] http.shutdownPollInterval documentation

[Sridhar]

In https://golang.org/src/net/http/server.go the documentation for 
shutdownPollInterval (admittedly unexported) reads:

// Ideally we could find a solution that doesn't involve polling,

// but which also doesn't have a high runtime cost (and doesn't

// involve any contentious mutexes), but that is left as an

// exercise for the reader.

Is this a remnant from a book on Go ? If so which one ?

 

-- 
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.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

[alex . rou . sg]

On Thursday, February 22, 2018 at 9:53:20 PM UTC+8, Axel Wagner wrote:
>
> Daisy chaining would mean I would only have to code API translations for 
>> the latest API but then it's debug hell and if one version in the chain 
>> breaks, 
>> it means fixing all the newer versions. Also there's a performance hit 
>> going through many translations.
>>
>
> I don't believe so. There's may be an increase in compile time though.
>

I was thinking of cases where the behavior is so different it needed to 
emulate old behavior so over time all the emulation adds up and would be 
more complex than just emulating based on v0/latest.
 

> The real question though, is how other package management semantics would 
> solve this better. Is this actually accidental complexity or just 
> systematic complexity caused by "I need to both break compatibility *and* 
> have different versions coexist *and* still share Singleton state between 
> them?
>

The vgo blogs talk about coexistence of multiple versions so was just 
figuring out if it makes sense and how would that look like.
I just like to be prepared for worst case scenarios, so stuff I was worried 
about may or may not actually happen. But better be safe than sorry.

-- 
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.

Re: [go-nuts] Float multiplication bug?

[andrey mirtchovski]

in the first Printf "area" is truncated. try %.40f to see the real
value, which is more like:

262256.4523014638689346611499786376953125

plugging that in as h2 will result in
39709429597.0098280725069344043731689453125 (according to wolfram
alpha)

On Thu, Feb 22, 2018 at 1:32 PM,   wrote:
>
>  Hello Everyone,
>
>  This looks like a Golang bug to me. What do you all think?
>
>  I have this function ...
>
>> func getArea(base, side int64) float64 {
>> var height, fSide, area float64
>> fSide = float64(side)
>> halfBase := float64(base) / 2.0
>> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
>> area = halfBase * height
>> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height, area)
>
>
>>
>> hb2 := 151414.5
>> h2 := 262256.452301
>> fmt.Printf("Area 2: %f\n", hb2 * h2)
>
>
>>
>> return area
>> }
>
>
> When I call it with `result := getArea(302829, 302828)`,   I get this output
> ...
>
>> halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
>> Area 2: 39709429596.929764
>
>
> I could see how some kind of rounding could produce the first Area value.
> But in that case, why wouldn't Area2 be rounded as well?
>
> --
> 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.

-- 
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] Float multiplication bug?

[steve_bagwell]

 Hello Everyone,

 This looks like a Golang bug to me. What do you all think?

>  I have this function ...

func getArea(base, side int64) float64 {
> var height, fSide, area float64
> fSide = float64(side)
> halfBase := float64(base) / 2.0
> height = math.Sqrt(fSide*fSide - halfBase*halfBase)
> area = halfBase * height
> fmt.Printf("halfBase: %f, height: %f, Area: %f\n", halfBase, height, area)
>
 

> hb2 := 151414.5
> h2 := 262256.452301
> fmt.Printf("Area 2: %f\n", hb2 * h2)
>
 

> return area
> }

 
When I call it with `result := getArea(302829, 302828)`,   I get this 
output ...

halfBase: 151414.50, height: 262256.452301, Area: 39709429597.00
> Area 2: 39709429596.929764


I could see how some kind of rounding could produce the first Area value.  
But in that case, why wouldn't Area2 be rounded as well?

-- 
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] Re: Experience report on coming to Go from a C perspective

[jake6502]

Have you considered using the new type alias feature introduced in 1.9? 
Line so:

https://play.golang.org/p/6HK8qcuh9UU

This would allow you to change the type of the map in a singe place (the 
type alias) and all the *{}* or *make *would adapt appropriately. 
Disclaimer: I am not espousing this style, just pointing out that it is 
possible.


On Thursday, February 22, 2018 at 3:03:13 PM UTC-5, Devon H. O'Dell wrote:
>
> Hi all, 
>
> It's been some time since I really contributed much of anything to the 
> project (sorry!), but after 8 years, I'm finally writing Go outside of 
> the project itself (and outside of porting efforts). I was lamenting 
> to some coworkers about the lack of a comparable feature to C's 
> "malloc idiom" and they suggested I write an experience report on it. 
> I wrote the bulk of the article a month ago, but finally put in some 
> finishing touches and published. 
>
> For whatever it's worth (probably not much): 
> https://9vx.org/post/a-malloc-idiom-in-go/ 
>
> --dho 
>

-- 
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] Experience report on coming to Go from a C perspective

[Devon H. O'Dell]

Hi all,

It's been some time since I really contributed much of anything to the
project (sorry!), but after 8 years, I'm finally writing Go outside of
the project itself (and outside of porting efforts). I was lamenting
to some coworkers about the lack of a comparable feature to C's
"malloc idiom" and they suggested I write an experience report on it.
I wrote the bulk of the article a month ago, but finally put in some
finishing touches and published.

For whatever it's worth (probably not much):
https://9vx.org/post/a-malloc-idiom-in-go/

--dho

-- 
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.

Re: [go-nuts] Build started to fail with 1.10

[Ian Lance Taylor]

On Thu, Feb 22, 2018 at 8:38 AM, Владислав Митов
 wrote:
>
> One of my build started failing with 1.10. Basically I'm building a wrapper
> around a C library and it fails with:
>
> # runtime/cgo
> gcc_libinit.c: In function '_cgo_try_pthread_create':
> gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
>   struct timespec ts;
>   ^~
> gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep'
> [-Werror=implicit-function-declaration]
>nanosleep(, nil);
>^
> gcc_libinit.c:97:18: error: unused variable 'ts' [-Werror=unused-variable]
>   struct timespec ts;
>   ^~
> cc1: all warnings being treated as errors
> https://travis-ci.org/miracl/gomiracl/jobs/344782123
>
> Any hint's what's causing this?

You say this started failing with 1.10.  That file
(runtime/cgo/gcc_libinit.c) hasn't changed since 1.9, so I think
something else must have changed.

timespec and nanosleep are normally defined in .  What system
are you using?

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

[go-nuts] Build started to fail with 1.10

[Владислав Митов]

Hey guys, 

One of my build started failing with 1.10. Basically I'm building a wrapper 
around a C library and it fails with: 

# runtime/cgo
gcc_libinit.c: In function '_cgo_try_pthread_create':
gcc_libinit.c:97:18: error: storage size of 'ts' isn't known
  struct timespec ts;
  ^~
gcc_libinit.c:110:3: error: implicit declaration of function 'nanosleep' 
[-Werror=implicit-function-declaration]
   nanosleep(, nil);
   ^
gcc_libinit.c:97:18: error: unused variable 'ts' [-Werror=unused-variable]
  struct timespec ts;
  ^~
cc1: all warnings being treated as errors
https://travis-ci.org/miracl/gomiracl/jobs/344782123

Any hint's what's causing this? 

Cheers, 
Vladi

-- 
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] extract rsa-encrypted public-key from tls-certificate (pem-format)

[andro . yamamoto]

Hi,


What I have:
- tls-certificate (x.509 format, pem encoded)
- within the tls-certificate -> public-key (rsa encrypted)
- corresponding private-key (pem encoded, rsa encrypted)


What I want:
- validate pem encoded private-keys // (something like 'openssl rsa -in 
client.key -check' )
- validate key-pair (if private-key is matching certificate) // (something 
like is key matching certificate running -> 'openssl x509 -noout -modulus 
-in client.cert | openssl md5' == 'openssl rsa -noout -modulus -in 
PRIVATEKEY.key | openssl md5')


What I tried:

*func *CheckKeyPair(clientcert, key string) error {


   block, _ := pem.Decode([]byte(clientcert))  // decode pem 
encoded tls certificate

   cert,_ := x509.ParseCertificate(block.Bytes)  // parse certificate 
(get type x509.*Certificate)

   fmt.Println(reflect.TypeOf(cert.PublicKey))  // print parsed 
public-key from certificate (get type *rsa.PublicKey)

  

*return *nil

}

I fill this function with an the tls-certificate (type string) and 
private-key (type string).

I've already started several experiments. That's why I haven't posted my 
mischief yet. 
I thought I would use this function, to validate the key-pair. -> 
tls.X509KeyPair (https://golang.org/pkg/crypto/tls/#X509KeyPair)
Does anyone know how to move on?

Best,
A


-- 
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] Re: All Forms of Wishful Generics

['David Chase' via golang-nuts]

I agree that this is one of the two large risks.
The other is whether the language remains comparatively easy to learn.

The next largest problem after those two is "what exactly do you mean by 
generics"?
Some people want code stenciling, like C++ (it's fast, it's easy to 
understand, code size might explode, generic methods are harder).
Some people want dictionaries (you get type checking and generic methods, 
but not too likely you get speed from specialization).
Some people think erased Java-style generics are fine (these do have issues 
with reflection, and it might look different w/o type tags).

Note that Java-style generics were supposed to be the best choice for 
old/new compatibility.

As a technical problem it is *relatively* easy.

On Monday, February 19, 2018 at 5:55:54 AM UTC-5, Doğan Kurt wrote:
>
> Generics would divide the Go community.
>
> I would probably never use it, like many people who comes to Go from C. 
> People who are already experienced Go programmers also likely to avoid it. 
> Java programmers on the other hand will surely overuse it.
>
> There it is, you have two different Go code bases that looks nothing like 
> each others. One uses Generics and the other does not. Nobody wants Go to 
> have the same fate as C++. We love how there is only one way to accomplish 
> something in Go.
>
> There are billions of lines of code written in Go. Nobody would happily 
> transform all those working codes just to use new idiomatic Go with 
> generics. I suspect even Go team would hesitate to transform all the 
> standard library.
>
> If Go team add generics to Go 2, i am afraid that Go 2 will have the same 
> fate as python 3.
>
> Let's hope it never happens.
>
> On Friday, February 16, 2018 at 7:25:35 AM UTC+1, dc0d wrote:
>>
>> All forms of generics that I would love to have in Go:
>>
>>
>> 
>>
>>

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

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018, 12:43  wrote:

> On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote:
>>
>> Have you read https://research.swtch.com/vgo-import? It talks about
>> singletons and also how to solve that with different import paths.
>> Note, that this is also independent of *how* the different import paths
>> are represented and distributed; for singletons it only matters what import
>> paths the compiler sees, whether they are committed physical directories or
>> whether the vgo tool automatically resolves them.
>>
>
> Yup, the package I'm working on really cannot have 2 instances even in
> different import paths as it deals with a shared resource and code that
> must be run on the main thread.
> So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a
> central v0 where all the v1, v2, etc.. packages import.
>

Both seem fine.

Daisy chaining would mean I would only have to code API translations for
> the latest API but then it's debug hell and if one version in the chain
> breaks,
> it means fixing all the newer versions. Also there's a performance hit
> going through many translations.
>

I don't believe so. There's may be an increase in compile time though.

Note also, that you don't have to Daisy-Chain down - AIUI you can daisy
chain up too. i.e. v1/singleton aliases into v2/singleton, aliases into
v3/singleton... That way any cost would only be paid by people on stale
versions. Yes, if vN breaks, that would also break vM for M work when there's a breaking change as then I'll have to update all
> versions.
>
Also it means that all version packages have to be from the same release or
> it breaks.
>
> If I just have one module at the root, is it right to assume all sub
> packages would be of the same commit and that there will be only one
> version of the module?
>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Appreciating Go

[Jesper Louis Andersen]

Usually, the type theoretic basis is what is called a sum-type. They are
corresponding to a logical OR or a '+' addition operation in algebra. A
"struct" is rightfully a variant of a product-type, or a logical AND or a
'*' multiplication operation in algebra[0]. Most (commonly used)
programming languages can "multiply" in the type system, but they can't
"add", and this creates a lot of serious problems since you have to
simulate sums through products.

If we write

type point struct {
   x int
   y int
}

you could argue that a value of type point contains "a value X" AND "a
value Y", which is why they are often called product types. Forming a point
point{x,y} mandates you supply both at the same time.

For sums, in Go, I have to return a pair,

x, err := someOperation(..)

but this is slightly inconsistent, insofar I can return "nil, nil", which
might not be a valid value, or I can return "3, Error(..)" but in that case
the 3 is not to be used. Only one "side" is valid at a given point in time.
If you have sum-types in the usual sense, you can define something along
the lines of (OCaml follows):

type ('a, 'b) result = Ok of 'a | Error of 'b

And then you can discriminate on this value via pattern matching

match res with
| Ok value -> ...
| Error err -> ...

This means that the inconsistent state cannot be represented. An ('a, 'b)
result is either "Ok ..." OR "Error ..." but it can't be both.

Go does have matching constructions which are special cases of the general
variant above. In particular, in OCaml we can have

match x with
| true -> ExprT
| false -> ExprF

(where ExprT/ExprF are arbitrary expressions) but this is same as (in fact,
syntactic sugar for):

if x then ExprT else ExprF

which is roughly equivalent to the following in Go[1]

if x {
ExprT
} else {
ExprF
}

The other matching construction is a switch-statement, but such a statement
doesn't allow for matching deeply into an AST structure, which a
traditional pattern matcher does.

In practice, a programming language will contain a "pattern match compiler"
which compiles a pattern match into an if-maze, a jump table, binary search
and so on. This means they are efficient to execute in practice because you
can use positive and negative match information to skip match clauses when
needed. Two good references are Simon Peyton Jones compiler book[3] and
Peter Sestofts pattern match compiler[4]

Coincidentally, given sum-types, you can write a regexp matching engine in
very few lines of code. See Bob Harper's "Programming in Standard ML" [2]
for example; it is the introductory example to get a feel for the language.
The solution uses sum types to define the AST for regular expressions, and
then uses pattern matching to build a matcher on regular expressions. I
can't remember how far Bob takes the exposition however.

Rust calls them "enums" but they are more than just an enumeration in e.g.,
Java, because each variant also binds values. Scala calls them sealed
classes, and I guess it has to do with the language being heavely based on
Java and thus needs the concept to coexist with subtyping, but I may be
wrong in my guess.


[0] They are really the same in the right setting. In a boolean algebra,
for instance, + is OR and * is AND. If you look at them from the Category
Theory branch of mathematics they are related: they are duals of each other
which means that if you "invert" one you get the other and vice versa.

[1] Obviously, Go, being a descendant of Algol has two syntactic classes:
statements and expressions, whereas OCaml is descendant from either Lisp or
the Lambda Calculus depending on view. Those languages only have
expressions as a syntactic class.

[2] http://www.cs.cmu.edu/~rwh/isml/book.pdf

[3]
https://www.microsoft.com/en-us/research/wp-content/uploads/1987/01/slpj-book-1987-small.pdf

[4] http://dotat.at/tmp/match.pdf

On Thu, Feb 22, 2018 at 1:14 PM Josh Humphries 
wrote:

> On Thu, Feb 22, 2018 at 4:56 AM, Steven Hartland 
> wrote:
>
>> On 22/02/2018 09:46, andrewchambe...@gmail.com wrote:
>>
>> Just a list of things I like about Go, thanks everyone for the hard work:
>>
>> snip...
>>
>> Minor things that could be improved in order of importance:
>>
>> - Ways to express immutability ... as a concurrent language it can still
>> be easy to make mistakes and share a buffer or slice by accident.
>> - More advanced static analysis tools that can prove properties of your
>> code (perhaps linked with the above).
>>
>> Have you seen: https://github.com/alecthomas/gometalinter
>>
>> - Generics.
>> - Some sort of slightly more sophisticated pattern matching .
>>
>> Not sure what you mean here but have you seen:
>> https://golang.org/pkg/regexp/
>>
>
> I'm pretty sure Andrew was referring to pattern matching like in Scala and
> Rust. It's a very slick feature. Related: Rust's enum types are slick --
> they are like a combination of enums (such as in Java, and Scala) and
> Scala's 

Re: [go-nuts] Appreciating Go

[Josh Humphries]

On Thu, Feb 22, 2018 at 4:56 AM, Steven Hartland 
wrote:

> On 22/02/2018 09:46, andrewchambe...@gmail.com wrote:
>
> Just a list of things I like about Go, thanks everyone for the hard work:
>
> snip...
>
> Minor things that could be improved in order of importance:
>
> - Ways to express immutability ... as a concurrent language it can still
> be easy to make mistakes and share a buffer or slice by accident.
> - More advanced static analysis tools that can prove properties of your
> code (perhaps linked with the above).
>
> Have you seen: https://github.com/alecthomas/gometalinter
>
> - Generics.
> - Some sort of slightly more sophisticated pattern matching .
>
> Not sure what you mean here but have you seen:
> https://golang.org/pkg/regexp/
>

I'm pretty sure Andrew was referring to pattern matching like in Scala and
Rust. It's a very slick feature. Related: Rust's enum types are slick --
they are like a combination of enums (such as in Java, and Scala) and
Scala's sealed classes.
https://docs.scala-lang.org/tour/pattern-matching.html
https://doc.rust-lang.org/1.6.0/book/match.html


>
> --
> 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.
>

-- 
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.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

[alex . rou . sg]

On Thursday, February 22, 2018 at 5:29:23 PM UTC+8, Axel Wagner wrote:
>
> Have you read https://research.swtch.com/vgo-import? It talks about 
> singletons and also how to solve that with different import paths.
> Note, that this is also independent of *how* the different import paths 
> are represented and distributed; for singletons it only matters what import 
> paths the compiler sees, whether they are committed physical directories or 
> whether the vgo tool automatically resolves them.
>

Yup, the package I'm working on really cannot have 2 instances even in 
different import paths as it deals with a shared resource and code that 
must be run on the main thread.
So I have to choose between daisy chaining v1 to v2 to v3 etc.. or have a 
central v0 where all the v1, v2, etc.. packages import.

Daisy chaining would mean I would only have to code API translations for 
the latest API but then it's debug hell and if one version in the chain 
breaks, 
it means fixing all the newer versions. Also there's a performance hit 
going through many translations.

Having a v0 means non of all the daisy chaining problems but it means more 
work when there's a breaking change as then I'll have to update all 
versions.
Also it means that all version packages have to be from the same release or 
it breaks. 

If I just have one module at the root, is it right to assume all sub 
packages would be of the same commit and that there will be only one 
version of the module?

-- 
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] Go Web app skeleton

[Thomas Bellembois]

Hello,

For one of my projects I wanted to create first a sample Web app in Go
with the full layers (authentication, authorization, views, databases)
and with no framework (but with toolkits).

It is not perfect but I want to share if it may help others:
https://github.com/tbellembois/gowebskel

Feel free to improve my work.

Regards,

Thomas

-- 
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.

Re: [go-nuts] Appreciating Go

[Steven Hartland]

On 22/02/2018 09:46, andrewchambe...@gmail.com wrote:

Just a list of things I like about Go, thanks everyone for the hard work:

snip...

Minor things that could be improved in order of importance:

- Ways to express immutability ... as a concurrent language it can 
still be easy to make mistakes and share a buffer or slice by accident.
- More advanced static analysis tools that can prove properties of 
your code (perhaps linked with the above).

Have you seen: https://github.com/alecthomas/gometalinter

- Generics.
- Some sort of slightly more sophisticated pattern matching .
Not sure what you mean here but have you seen: 
https://golang.org/pkg/regexp/


--
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] Appreciating Go

[andrewchamberss]

Just a list of things I like about Go, thanks everyone for the hard work:

Good things go has:

- Go has an extremely useful std library.
- Go has the best backwards compatibility I have seen (I'm pretty sure code 
from go version 1.0 still works today.).
- Go has the nicest code manipulation tools I have seen.
- The best race condition detector tool around.
- An incredibly useful in practice interface system. (I once tunneled http 
and ssh connections over a serial port because net.Listener and net.Conn 
are easy interfaces)
- The fastest compiler to use, and to build from source.
- Probably the best cross compilation story of any language, with 
uniformity across platforms, including ones you haven't heard of.
- One of the easiest to distribute binaries across platforms (this is why 
hashicorp, cockroachdb, ngrok etc choose go, it makes on boarding customers 
so much easier.).
- A very sophisticated garbage collector with low pause times.
- One of the best runtime performance to ease of use ratios around.
- One of the easier to learn languages around.
- A compiler that produces byte for byte identical binaries.
- incredibly useful libraries maintained by google: (e.g. Heres a complete 
ssh client and server anyone can  use: 
https://godoc.org/golang.org/x/crypto/ssh)
- Lots of money invested in keeping it working well from many companies: 
cloud flare, google, uber, hashicorp  and more.
- *FINALLY* A fresh and bold take on package management that isn't a cargo 
cult :) - https://research.swtch.com/vgo  (I especially like how well this 
tackles verifiable builds).

Minor things that could be improved in order of importance:

- Ways to express immutability ... as a concurrent language it can still be 
easy to make mistakes and share a buffer or slice by accident.
- More advanced static analysis tools that can prove properties of your 
code (perhaps linked with the above).
- Generics.
- Some sort of slightly more sophisticated pattern matching .



Let me know if I missed anything, thanks again.

-- 
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.

Re: [go-nuts] What's the best way to maintain a package repository that have the major version in the import path?

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018 at 7:18 AM  wrote:

> I don't think changing the module name would be a good idea for singletons
> tho.
>

Have you read https://research.swtch.com/vgo-import? It talks about
singletons and also how to solve that with different import paths.
Note, that this is also independent of *how* the different import paths are
represented and distributed; for singletons it only matters what import
paths the compiler sees, whether they are committed physical directories or
whether the vgo tool automatically resolves them.


> And having a v0 has the added benefit of using newer codes while
> maintaining backwards compatible API.
> So no more backporting and all the mess of having multiple branches.
>

If you don't want multiple branches, you can commit your
version-directories and keep the same module name for all of them. If you
prefer having a single directory and different branches for different
version, you can have the version in the module line instead.

To the compiler, both are equivalent, the tool will resolve them to the
same thing.


>
> On Thursday, February 22, 2018 at 1:49:53 PM UTC+8, Sam Whited wrote:
>>
>> On Wed, Feb 21, 2018, at 22:35, alex@gmail.com wrote:
>> > vgo suggested that package developers put the major version into the
>> import
>> > path e.g. foo/v1.
>> > However dealing with a VCS like git, this thought occur to me, what
>> would
>> > it look like when the project needs to move from v1 to v2?
>>
>> This wasn't clear to me either, but it was pointed out that you can just
>> change the "module" line in your go.mod file, eg.
>>
>> module "example.net/mypackage/v2"
>>
>> and you don't have to actually create a /v2 tree or move your code around
>> at all.
>>
>> —Sam
>>
> --
> 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.
>

-- 
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.

Re: [go-nuts] Re: Go += Package Versioning

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018 at 9:50 AM dc0d  wrote:

> And the first idea is about having packages that does not harm the
> environment (like by importing reflect or executing external commands), and
> seems to be a feasible goal.
>

Apologies, I was ambiguous in my quote, I wasn't trying to say anything
about the first point at all.

-- 
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.

Re: [go-nuts] Re: Go += Package Versioning

[dc0d]

Thanks Axel,

You are right about env-vars and as I've noted, there might be security 
concerns. The main goal here was to represent an idea for the source of the 
import. It can be the module descriptor of vgo.

And the first idea is about having packages that does not harm the 
environment (like by importing reflect or executing external commands), and 
seems to be a feasible goal.

On Thursday, February 22, 2018 at 11:31:35 AM UTC+3:30, Axel Wagner wrote:
>
> On Thu, Feb 22, 2018 at 7:10 AM dc0d  
> wrote:
>
>> I'm looking forward to see this in official releases too!
>>
>> Also I would like to:
>>
>> - Have a mechanism for safe dependency packages (as in Safe-Tcl 
>>  - this implies it would be 
>> possible to have meta-data other than versions for packages, too).
>> - This one looks like a minor change in import syntax and might bring in 
>> some security concerns: being able to use env-vars in imports: import 
>> "$MY_OTHER_PKG".
>>
>
> Please don't. This is the antithesis to what vgo is trying to do. vgo 
> tries very hard to marry reproducible builds with simplicity. Having 
> environment variables determine what gets built destroys that completely.
>
> The occasional edge-case that might benefit from this should write their 
> own tool which generates an appropriate 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Re: Go += Package Versioning

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018 at 7:10 AM dc0d  wrote:

> I'm looking forward to see this in official releases too!
>
> Also I would like to:
>
> - Have a mechanism for safe dependency packages (as in Safe-Tcl
>  - this implies it would be
> possible to have meta-data other than versions for packages, too).
> - This one looks like a minor change in import syntax and might bring in
> some security concerns: being able to use env-vars in imports: import
> "$MY_OTHER_PKG".
>

Please don't. This is the antithesis to what vgo is trying to do. vgo tries
very hard to marry reproducible builds with simplicity. Having environment
variables determine what gets built destroys that completely.

The occasional edge-case that might benefit from this should write their
own tool which generates an appropriate 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.
For more options, visit https://groups.google.com/d/optout.

Re: [go-nuts] Go += Package Versioning

['Axel Wagner' via golang-nuts]

On Thu, Feb 22, 2018 at 4:21 AM David Anderson  wrote:

> Currently, per the vgo tour, the entire transitive closure gets updated,
> which, per the article's definition, results in a low-fidelity build... If
> you assume that the intent of `vgo get -u` was "the libraries I'm calling
> have new features/fixes, please use them," and not "I want to use the
> latest possible code the universe can offer me, throughout the stack."
>

I don't think this is the correct interpretation of what Russ calls
"low-fidelity". "low-fidelity build" means, that you install something I
built and gets a poor reproduction of what I intended you to get. This is
different from me upgrading the transitive closure of dependencies of my
stuff and you then installing that; this would still be a good reproduction
of my intent and thus high-fidelity.


> I believe both operations have their place, and I could be convinced
> either way on which should be the default for "update my stuff." I'm
> wondering if I'm alone in thinking that "upgrade only direct dependencies,
> minimal versions elsewhere" is desirable as a "suggested" commandline
> action.
>

I think it *may* have its place but it should be strongly discouraged (to
the degree that I'm not sure whether I want it to exist at all). I think
upgrading the transitive closure can be a valuable driver to prevent bitrot
in the Go community at large - but that requires that a critical mass of
projects actually use it.

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