Re: [go-nuts] Unexpected circular type definition limitation
The following playground example shows the problem:
https://go.dev/play/p/1kC2j57M_fW
Le 15/06/2023 à 10:28, Jan Mercl a écrit :
On Thu, Jun 15, 2023 at 10:16 AM christoph...@gmail.com
wrote:
It is possible to define two structures globally with mutual type dependency as
this:
type A struct {
B []B
}
type B struct {
A A[]
}
but I just noticed that we can't do that inside a function:
func Foo() {
type A struct {
B []B
}
type B struct {
A A[]
}
}
Is there a reason for this limitation ?
Syntax error: https://go.dev/play/p/ZOGyZyQDW0I
--
Bien cordialement,
Ch.Meessen
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/801e7e6b-d3f8-c1df-8eae-46aa619d49a5%40gmail.com.
[go-nuts] [generics] is generics with constrain needed ?
Reading the document "Type parameters - Draft desing" of June 16, 2020 (https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md), I wonder if these two following function definitions are not equivalent and thus interchangeable func Stringify(type T Stringer)(s []T) (ret []string) func Stringify(s []Stringer) (ret []string) If the constrain is an interface, wouldn’t it be the same as to use the interface as type ? How would it be different ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/3b758827-2d14-4769-bf94-95cf60a06b1bo%40googlegroups.com.
[go-nuts] It is said that future Macs will use ARM, is golang ready for this move ?
There is a rumor that Apple will announce at the WWDC2020, the 22 june, that the Macs of generation 2021 and beyond will use ARM processors in place of the Intel processors. Is Golang ready to follow this move ? Will I be able to compile and run my go programs on ARM Macs ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f8bd2b7a-99e1-47f1-8cc5-3d37a1aeade5o%40googlegroups.com.
[go-nuts] Re: Memory leak or GC feature ?
While letting the program run for a few hours I see that after some time
the memory usage vary in saw teeth. Some of the garbage is reclaimed after
800 calls to GC().
However, it never gets back to the low level it had initially. Initial
lowest Alloc is 146520. It then grows steadily up to 163040. Then suddenly
drops to 156896, and grows slowly again to 163520. Then drops suddenly to
157376. Etc.
So memory is indeed a little bit partially reclaimed from time to time. So
the GC kind of works, but the GC() function doesn’t behave as I was
expectiong.
Le vendredi 6 mars 2020 16:55:24 UTC+1, Christophe Meessen a écrit :
>
> The documentation of the GC() function states:
>
> "GC runs a garbage collection and blocks the caller until the garbage
> collection is complete. It may also block the entire program."
>
> Based on the documentation, I assumed that a garbage collection would be
> really complete by calling GC. By complete I mean that no garbage is left
> over.
>
> Apparently It’s not the case. Is it possible learn a bit more on this ?
> Why would the GC not garbage collect everything when GC() is called ?
>
> It would have been convenient for detecting memory leaks to be able to
> compare memory Alloc before and after the checked task and a really
> complete GC.
>
>
>
>
> Le vendredi 6 mars 2020 15:26:33 UTC+1, Volker Dobler a écrit :
>>
>> This is normal behaviour and not a leak.
>> Nothing is leaking in your code (and it is generally
>> hard to leak RAM). The allocations will be reclaimed.
>>
>> V.
>>
>> On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen wrote:
>>>
>>> I wanted to check my program for go routine and memory leaks. In doing
>>> so I detected what resemble a memory leak while my program was doing
>>> nothing.
>>>
>>> Here is a minimal program that reproduces the problem. The program
>>> collects and prints the total number of bytes allocated and the number of
>>> blocks.
>>>
>>> package main
>>>
>>> import (
>>> "runtime"
>>>
>>> func main() {
>>> var m runtime.MemStats
>>> ticker := time.NewTicker(20 * time.Second)
>>> for {
>>> runtime.ReadMemStats()
>>> println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees,
>>> "numGC", m.NumGC)
>>> <-ticker.C
>>> runtime.GC()
>>> }
>>> }
>>>
>>> What I see is a slow but steady increase of memUse and allocs. The
>>> memUse grows by 4 to 96 bytes every 40 to 60 seconds.
>>> Is this a feature of the GC or is this a memory leak in one of the
>>> called functions ?
>>>
>>> Note that I use println because the "leak" is much more important when I
>>> use fmt.Println of log.Println. I also use ticker because I was told it
>>> would be better than time.Sleep, but I don’t see any significant difference
>>> in the "leak" when I use one or the other.
>>>
>>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/e53fb283-4b76-48f5-b5ed-319f6cf4fbb8%40googlegroups.com.
[go-nuts] Re: Memory leak or GC feature ?
The documentation of the GC() function states:
"GC runs a garbage collection and blocks the caller until the garbage
collection is complete. It may also block the entire program."
Based on the documentation, I assumed that a garbage collection would be
really complete by calling GC. By complete I mean that no garbage is left
over.
Apparently It’s not the case. Is it possible learn a bit more on this ? Why
would the GC not garbage collect everything when GC() is called ?
It would have been convenient for detecting memory leaks to be able to
compare memory Alloc before and after the checked task and a really
complete GC.
Le vendredi 6 mars 2020 15:26:33 UTC+1, Volker Dobler a écrit :
>
> This is normal behaviour and not a leak.
> Nothing is leaking in your code (and it is generally
> hard to leak RAM). The allocations will be reclaimed.
>
> V.
>
> On Friday, 6 March 2020 14:11:37 UTC+1, Christophe Meessen wrote:
>>
>> I wanted to check my program for go routine and memory leaks. In doing so
>> I detected what resemble a memory leak while my program was doing nothing.
>>
>> Here is a minimal program that reproduces the problem. The program
>> collects and prints the total number of bytes allocated and the number of
>> blocks.
>>
>> package main
>>
>> import (
>> "runtime"
>>
>> func main() {
>> var m runtime.MemStats
>> ticker := time.NewTicker(20 * time.Second)
>> for {
>> runtime.ReadMemStats()
>> println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees,
>> "numGC", m.NumGC)
>> <-ticker.C
>> runtime.GC()
>> }
>> }
>>
>> What I see is a slow but steady increase of memUse and allocs. The memUse
>> grows by 4 to 96 bytes every 40 to 60 seconds.
>> Is this a feature of the GC or is this a memory leak in one of the called
>> functions ?
>>
>> Note that I use println because the "leak" is much more important when I
>> use fmt.Println of log.Println. I also use ticker because I was told it
>> would be better than time.Sleep, but I don’t see any significant difference
>> in the "leak" when I use one or the other.
>>
>>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/b8103128-8ae8-42fb-8b3f-4d5265632246%40googlegroups.com.
[go-nuts] Memory leak or GC feature ?
I wanted to check my program for go routine and memory leaks. In doing so I
detected what resemble a memory leak while my program was doing nothing.
Here is a minimal program that reproduces the problem. The program collects
and prints the total number of bytes allocated and the number of blocks.
package main
import (
"runtime"
func main() {
var m runtime.MemStats
ticker := time.NewTicker(20 * time.Second)
for {
runtime.ReadMemStats()
println("status: memUsed:", m.Alloc, "allocs:", m.Mallocs-m.Frees, "numGC",
m.NumGC)
<-ticker.C
runtime.GC()
}
}
What I see is a slow but steady increase of memUse and allocs. The memUse
grows by 4 to 96 bytes every 40 to 60 seconds.
Is this a feature of the GC or is this a memory leak in one of the called
functions ?
Note that I use println because the "leak" is much more important when I
use fmt.Println of log.Println. I also use ticker because I was told it
would be better than time.Sleep, but I don’t see any significant difference
in the "leak" when I use one or the other.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/58e246f2-692f-4246-8728-e28517ed6db0%40googlegroups.com.
[go-nuts] Is the GC recovering storage when full slice expression reduce capacity ?
It is possible to reduce the capacity of a slice by using the full slice expression (https://golang.org/ref/spec#Slice_expressions). Now consider the following code where a is a 1MB slice. I then create b, a slice of a, but with a much smaller capacity. Finally, I change the value of a so that only b refers to the slice element storage. a := make([]byte, 100) b := b[:3:3] a = nil Will the garbage collector be able to recover the inaccessible space in the slice element storage ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/1c984e3f-eb86-49b8-be00-34a99f9f2551%40googlegroups.com.
[go-nuts] Re: Inconsistent rounding with float printf ?
I can't change expectations. It is to convert a byte count into a human readable byte count ( with kB, MB, ... units). I found out that I can produce the expected result by using math.Round. See here https://play.golang.org/p/UorDwbKlLj5 For my use case, I ended up converting "manually" the integer into a .1f float by using an array. The resulting code is 12 time faster than the one using the printf and float64 operations. It also need only one allocation to convert the byte array into a string. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/425dd75e-7d58-44cd-9e99-b197b81c078e%40googlegroups.com.
[go-nuts] Inconsistent rounding with float printf ?
I have noticed that printf performs an apparently inconsistent rounding of floating point values. I divide a big number by 1000 and printf the resulting value with "%.1f". Here is the code: https://play.golang.org/p/e7dD3c6IHq2 I would expect the rounding rule to be "round away from zero" as defined here: https://math.stackexchange.com/a/2252888/33796 In this case 0.5 is rounded to 1 (or 0.05 to 0.1) and -0.5 to -1 (or -0.05 to -0.1). Here is what I see with golang 1.13.4: 999000/1000 = 999.0 999050/1000 = 999.0 // expected 999.1 999100/1000 = 999.1 999150/1000 = 999.1 // expected 999.2 999200/1000 = 999.2 999250/1000 = 999.2 // expected 999.3 999300/1000 = 999.3 999350/1000 = 999.4 999400/1000 = 999.4 999450/1000 = 999.5 999500/1000 = 999.5 999550/1000 = 999.5 // expected 999.6 999600/1000 = 999.6 999650/1000 = 999.6 // expected 999.7 999700/1000 = 999.7 999750/1000 = 999.8 999800/1000 = 999.8 999850/1000 = 999.9 00/1000 = 999.9 50/1000 = 1000.0 -50/1000 = -1000.0 -00/1000 = -999.9 -999850/1000 = -999.9 -999800/1000 = -999.8 -999750/1000 = -999.8 -999700/1000 = -999.7 -999650/1000 = -999.6 // expected -999.7 -999600/1000 = -999.6 -999550/1000 = -999.5 // expected -999.6 -999500/1000 = -999.5 -999450/1000 = -999.5 -999400/1000 = -999.4 -999350/1000 = -999.4 -999300/1000 = -999.3 -999250/1000 = -999.2 // expected -999.3 -999200/1000 = -999.2 -999150/1000 = -999.1 // expected -999.2 -999100/1000 = -999.1 -999050/1000 = -999.0 // expected -999.1 Is this actual rounding the result of a rule or is it pseudo random ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7ace93da-e330-4069-9b0c-6d1aa15fc179%40googlegroups.com.
[go-nuts] Re: Can’t get latest package version with modules
I finally understood. The GOPATH definition is not relevant here. It is the presence of the go.mod file that determines if the module mode is in application. With go1.13, without go.mod file, the old GOPATH mode is in application. The go.mod file is create by "go mod init [package name]". When present, a "go get" will download and install all dependencies. Sorry for the noise. Le mardi 1 octobre 2019 08:59:55 UTC+2, Christophe Meessen a écrit : > > When GOPATH is defined (~/go), > > go get -u github.com/XXX/go-YYY@latest > > doesn’t work. I get the error message: > > go: cannot use path@version syntax in GOPATH mode > > This is with go1.13.1. > > Does this mean that GOPATH must be undefined to use modules with 1.13.1 ? > I thought that with go1.13 modules was used everywhere. > The rules are non-intuitive and not explicit. > > Le lundi 30 septembre 2019 11:17:11 UTC+2, Christophe Meessen a écrit : >> >> Solved the issue with the command: >> >> go get -u github.com/XXX/go-YYY@latest >> >> Is there another way ? >> >> Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit : >>> >>> I have a small go program to test a third party package stored on >>> github. >>> I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. >>> >>> When I first tried to compile the program, there was an error in the >>> third party package. I submitted a pull request to fix it and the manager >>> merged it. >>> >>> The problem I’m facing now is that I can’t get go to use the newest >>> version of the package. >>> >>> If I remove the require line in the go.mod file and do a go get, or go >>> get -u, or go get -u , I always get the older package although go >>> prints the message "go: finding github.com/XXX/go-YYY latest". It’s >>> definitely not the latest. >>> I’m stuck now and don’t know how to download the really latest version >>> of the package. >>> >>> I guess I’m not supposed to manually clean the go cache (~/go/src/mod/ >>> github.com/XXX/go-YYY@...), or am I ? >>> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/e7fb2f66-c0d7-407a-a6d6-0527d14036ad%40googlegroups.com.
[go-nuts] Re: Can’t get latest package version with modules
When GOPATH is defined (~/go), go get -u github.com/XXX/go-YYY@latest doesn’t work. I get the error message: go: cannot use path@version syntax in GOPATH mode This is with go1.13.1. Does this mean that GOPATH must be undefined to use modules with 1.13.1 ? I thought that with go1.13 modules was used everywhere. The rules are non-intuitive and not explicit. Le lundi 30 septembre 2019 11:17:11 UTC+2, Christophe Meessen a écrit : > > Solved the issue with the command: > > go get -u github.com/XXX/go-YYY@latest > > Is there another way ? > > Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit : >> >> I have a small go program to test a third party package stored on github. >> I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. >> >> When I first tried to compile the program, there was an error in the >> third party package. I submitted a pull request to fix it and the manager >> merged it. >> >> The problem I’m facing now is that I can’t get go to use the newest >> version of the package. >> >> If I remove the require line in the go.mod file and do a go get, or go >> get -u, or go get -u , I always get the older package although go >> prints the message "go: finding github.com/XXX/go-YYY latest". It’s >> definitely not the latest. >> I’m stuck now and don’t know how to download the really latest version of >> the package. >> >> I guess I’m not supposed to manually clean the go cache (~/go/src/mod/ >> github.com/XXX/go-YYY@...), or am I ? >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c71e539f-3926-4fb0-b3bb-92e3d2c19dff%40googlegroups.com.
[go-nuts] Re: Can’t get latest package version with modules
Solved the issue with the command: go get -u github.com/XXX/go-YYY@latest Is there another way ? Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit : > > I have a small go program to test a third party package stored on github. > I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. > > When I first tried to compile the program, there was an error in the third > party package. I submitted a pull request to fix it and the manager merged > it. > > The problem I’m facing now is that I can’t get go to use the newest > version of the package. > > If I remove the require line in the go.mod file and do a go get, or go get > -u, or go get -u , I always get the older package although go > prints the message "go: finding github.com/XXX/go-YYY latest". It’s > definitely not the latest. > I’m stuck now and don’t know how to download the really latest version of > the package. > > I guess I’m not supposed to manually clean the go cache (~/go/src/mod/ > github.com/XXX/go-YYY@...), or am I ? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0691adf5-5b04-4e39-b2e9-295c260c9527%40googlegroups.com.
[go-nuts] Re: Can’t get latest package version with modules
Note that the third party package has no tags. Le lundi 30 septembre 2019 11:01:17 UTC+2, Christophe Meessen a écrit : > > I have a small go program to test a third party package stored on github. > I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. > > When I first tried to compile the program, there was an error in the third > party package. I submitted a pull request to fix it and the manager merged > it. > > The problem I’m facing now is that I can’t get go to use the newest > version of the package. > > If I remove the require line in the go.mod file and do a go get, or go get > -u, or go get -u , I always get the older package although go > prints the message "go: finding github.com/XXX/go-YYY latest". It’s > definitely not the latest. > I’m stuck now and don’t know how to download the really latest version of > the package. > > I guess I’m not supposed to manually clean the go cache (~/go/src/mod/ > github.com/XXX/go-YYY@...), or am I ? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/6975d023-f1db-442b-81d3-60d7c2f41597%40googlegroups.com.
[go-nuts] Can’t get latest package version with modules
I have a small go program to test a third party package stored on github. I’m using go1.13.1 with no GOPATH defined. Code is in ~/go/src. When I first tried to compile the program, there was an error in the third party package. I submitted a pull request to fix it and the manager merged it. The problem I’m facing now is that I can’t get go to use the newest version of the package. If I remove the require line in the go.mod file and do a go get, or go get -u, or go get -u , I always get the older package although go prints the message "go: finding github.com/XXX/go-YYY latest". It’s definitely not the latest. I’m stuck now and don’t know how to download the really latest version of the package. I guess I’m not supposed to manually clean the go cache (~/go/src/mod/github.com/XXX/go-YYY@...), or am I ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/f74ffd31-2e78-4c0a-bea9-1c2d6f84ea22%40googlegroups.com.
[go-nuts] Re: Any support for proxy certificates (RFC3820) ?
Answering to my self. In case someone else is sharing the need, I found this Go package that provides support for x509 proxy certificates. https://gitlab.cern.ch/flutter/go-proxy Le lundi 23 septembre 2019 14:31:51 UTC+2, Christophe Meessen a écrit : > > Hello, > I need to write go code dealing with proxy certificates (RFC3820). > They are sometimes referred to as Grid Security Infrastructure (GSI) > certificates > > I couldn’t find anything related in crypto or x/crypto. Any suggestion ? > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/790596b3-bf59-44f4-874b-549d5daa11db%40googlegroups.com.
[go-nuts] Any support for proxy certificates (RFC3820) ?
Hello, I need to write go code dealing with proxy certificates (RFC3820). They are sometimes referred to as Grid Security Infrastructure (GSI) certificates I couldn’t find anything related in crypto or x/crypto. Any suggestion ? -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/b513edb2-e49a-424e-a9b8-326295c5ce42%40googlegroups.com.
[go-nuts] Re: Elastic synchronised logging : What do you think ?
Please replace 'case ticker.C' with 'case <-ticker.C' in my previous code. -- 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] Elastic synchronised logging : What do you think ?
What you did is decouple production from consumption. You can speed up the
production go routine if the rate is irregular. But if, on average, consumption
is too slow, the list will grow until out of memory.
If you want to speed up consumption, you may group the strings in one big
string and print once. This will reduce the rate of system calls to print each
string individually.
Something like this (warning: raw untested code)
buf := make([]byte, 0, 1024)
ticker := time.NewTicker(1*time.Second)
for {
select {
case ticker.C:
if len(buf) > 0 {
fmt.Print(string(buf))
buf := buf[:0]
}
case m := <-buffChan:
buf = append(buf, m...)
buf = append(buf, '\n')
}
}
Adjust the ticker period time and initial buffer size to what matches your
need.
--
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] Why can't we use < > for the Go generic parameters ?
I understand your example, but it wouldn't be a problem anymore with a special
character like a $ sign. D use the !.
--
Bien cordialement,
Ch.Meessen
> Le 6 sept. 2018 à 09:56, Jan Mercl <0xj...@gmail.com> a écrit :
>
> On Thu, Sep 6, 2018 at 9:49 AM Christophe Meessen
> wrote:
>
> func f(bool) { ... }
>
> func g() { f(ad) }
>
> an similar constructs require unlimited look ahead to distinguish the above
> example from something generics. The current Go parser can always decide
> where to go based on just the next symbol.
>
> --
> -j
--
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] Why can't we use < > for the Go generic parameters ?
I know about the problems it raised with C++, but Go is different. Go2 draft restricts generic parameters to types. The only case where there might eventually be an ambiguity is with specialized functions in expressions. I would like to determine if it's still possible to use < > and avoid the pitfalls. One of the option to consider is to use a special character to signal the specializing of a generic. Such a special character could be $ for instance. A generic type or function would be instantiated by the following expression : foo$(...) bar$(...) foo2$>(...) When there is only one generic parameter, we could use a concise form foo$int(...) == foo$(...) foo2$List$float(...) == foo2$>(...) My current understanding is that the $ would remove ambiguity in parsing. The reason I would prefer to use < > is to - satisfy to rule of least surprise. - readability -- 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: Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu
Thank you for the suggestions peterGo, but that is my current browser. I finally used Chrome to print. Le mercredi 5 septembre 2018 10:10:22 UTC+2, Christophe Meessen a écrit : > > Hello, > > when I try to print the draft documents, only the first page is printed. > It's not related with the printer because I get the same result when I try > to print in a document (pdf). > > Is it possible to provide the documents also in pdf format ? > -- 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] Can't print GO2 draft documents with firefox 61.0.1 (64 bits) Ubuntu
Hello, when I try to print the draft documents, only the first page is printed. It's not related with the printer because I get the same result when I try to print in a document (pdf). Is it possible to provide the documents also in pdf format ? -- 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] Safeness of using reflect.Type as a map key instead of reflect.Type.Name() ?
I need to index data by type and I have two options: - use a string as key and index the string returned by reflect.Type.Name() - use reflect.Type as key I have the impression that indexing by reflect.Type would be slightly more speed and space efficient, but I'm unsure if the relation between reflect.Type and reflect.Type.Name() is bijective. -- 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: Custom types for use with range (Go 2)
If considering user defined Ranger interface, I would strongly suggest to look at D's equivalent. The interface is simple and there are many use of it. It is trivial to develop a reverse range or ranges that traverse data structures (e.g. binary trees) in different ways (once you have generics). My experience with it (as a beginner) was that it makes the code less readable. There is a tendency to overuse it because a "for range" is concise and looks simple. But it is not because one has to lookup the "Ranger" implementation to understand what it is doing. When you know by hart what each "Ranger" does, you can still read and understand the code, but this is for the elites. It may give an impression of power to those mastering it, but it gives an impression of frustration to people learning the language. This also adds the burden to decide which "Ranger" to use, or to determine if there is a Ranger for what I want to do. The power of Go is its simplicity and readability. Let it stay that way. As it has already been said, it's only syntactic sugar. -- 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: [urgent] need aguments to justify use of Go for a scientific application
Thank you all for your help.
I assembled a sort document with the collected arguments (thanks
Sebastien).
It also contains short code samples.
Le 06/12/2017 à 16:17, Jesper Louis Andersen a écrit :
The best point in time to switch languages are when one of the
following things is happening:
* There is a small experiment on the side of the larger system which
can be handled in another language.
* There is a large project which has failed internally in the
business, it is severely behind and nobody thinks it can be solved anyway.
The by far best situation is when the sky is falling. This is when you
can propose a solution to the problem rather than a language. The
solution then proves itself first and then the language decision
follows as part of the solution.
However, for your situation, analyze the requirements of the project
first, then make a real effort to analyze a Python solution against a
Go solution. If astrophysicists are likely to grab e.g., numpy to do
their image processing loop, it is a hard sell. OTOH, if you have to
serve a serious amount of image data then the concurrency of Go is a
better choice and so on. Quantify "how many images per minute", "how
many concurrent requests", "resource usage" and so on.
You could also look for a split solution: process the images in
Python, but serve them from Go?
To me, the two biggest weaknesses of Python in (industrial) production
settings are:
* Dynamic typing and no other program modularization leads to programs
that are really hard to maintain, especially as they grow. A small
machine-learning training script is easy enough to maintain as a
work-sheet, but I don't particularly like it for serving said
machine-learning model.
* Deployment often requires some hoop-jumping. Getting the right
software versions built on one machine and deployed on another is IMO
living hell for Python programs. My experience is that build pipelines
for Python systems often break in subtle ways. Go produces static
binaries which are much easier to handle (Other systems doing it
right: Haskell, Erlang, OCaml, Elixir, ...)
On Wed, Dec 6, 2017 at 2:34 PM Christophe Meessen
<christophe.mees...@gmail.com <mailto:christophe.mees...@gmail.com>>
wrote:
Thanks far all the answers. Sebastien Binet is a colleague and he
is indeed brilliant.
pachyderm looks powerful, but also an overkill for my need. It
might scare my colleagues away.
Le 06/12/2017 à 12:34, Henrik Johansson a écrit :
I have a vague memory of +Rob Pike <mailto:r...@golang.org> tweeting
something about astronomy or perhaps an observatory a few months ago.
Perhaps there was no programming involved but if so I imagine Go
is safe bet.
But building pipelines using something like Pachyderm would allow
for a very polyglot "use the tool that fits in each part" approach.
ons 6 dec. 2017 kl 11:43 skrev Volker Dobler
<dr.volker.dob...@gmail.com <mailto:dr.volker.dob...@gmail.com>>:
I know about https://go-hep.org probably Sebastien can
elaborate more
if and how it is used at CERN.
V.
On Wednesday, 6 December 2017 10:56:01 UTC+1, Christophe
Meessen wrote:
Hello,
I'm a computer scientist in charge of developing an image
processing pipeline for telescope images.
It will also have a web server and DB connection.
The project is going through reviews by external experts,
and the problem I'm facing is that my proposal to use Go
is about to be rejected.
The main opposing arguments are
- everybody uses python in astrophysics
- it is very easy to find someone who knows python
- risk that I, sole Go programmer, might become unavailable
I would have the same arguments if I was project leader
and unfamiliar with Go.
The counter arguments I found so far are that
- Go is simpler and safer than Python
- I learned Go in a week-end
The problem is that they don't convince people who don't
know Go, are not experienced software developers, and
don't want to do the due diligence.
It's the usual inertia to change.
What other arguments could I use ?
Do you know other significant scientific experiments that
have adopted Go ?
I have found this github project.
https://github.com/indigo-astronomy/indigo
INDI is a well known Python Observatory Control System.
INDIGO is its translation into Go.
I have also found SciPipe https://github.com/scipipe.
It is a Go pipeline framework used in scientific
applications.
--
You received this message becaus
Re: [go-nuts] Re: [urgent] need aguments to justify use of Go for a scientific application
Thanks far all the answers. Sebastien Binet is a colleague and he is indeed brilliant. pachyderm looks powerful, but also an overkill for my need. It might scare my colleagues away. Le 06/12/2017 à 12:34, Henrik Johansson a écrit : I have a vague memory of +Rob Pike <mailto:r...@golang.org> tweeting something about astronomy or perhaps an observatory a few months ago. Perhaps there was no programming involved but if so I imagine Go is safe bet. But building pipelines using something like Pachyderm would allow for a very polyglot "use the tool that fits in each part" approach. ons 6 dec. 2017 kl 11:43 skrev Volker Dobler <dr.volker.dob...@gmail.com <mailto:dr.volker.dob...@gmail.com>>: I know about https://go-hep.org probably Sebastien can elaborate more if and how it is used at CERN. V. On Wednesday, 6 December 2017 10:56:01 UTC+1, Christophe Meessen wrote: Hello, I'm a computer scientist in charge of developing an image processing pipeline for telescope images. It will also have a web server and DB connection. The project is going through reviews by external experts, and the problem I'm facing is that my proposal to use Go is about to be rejected. The main opposing arguments are - everybody uses python in astrophysics - it is very easy to find someone who knows python - risk that I, sole Go programmer, might become unavailable I would have the same arguments if I was project leader and unfamiliar with Go. The counter arguments I found so far are that - Go is simpler and safer than Python - I learned Go in a week-end The problem is that they don't convince people who don't know Go, are not experienced software developers, and don't want to do the due diligence. It's the usual inertia to change. What other arguments could I use ? Do you know other significant scientific experiments that have adopted Go ? I have found this github project. https://github.com/indigo-astronomy/indigo INDI is a well known Python Observatory Control System. INDIGO is its translation into Go. I have also found SciPipe https://github.com/scipipe. It is a Go pipeline framework used in scientific applications. -- 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 <mailto:golang-nuts+unsubscr...@googlegroups.com>. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to a topic in the Google Groups "golang-nuts" group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/golang-nuts/BH4tOlu6df8/unsubscribe. To unsubscribe from this group and all its topics, send an email to golang-nuts+unsubscr...@googlegroups.com <mailto: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] [urgent] need aguments to justify use of Go for a scientific application
Hello, I'm a computer scientist in charge of developing an image processing pipeline for telescope images. It will also have a web server and DB connection. The project is going through reviews by external experts, and the problem I'm facing is that my proposal to use Go is about to be rejected. The main opposing arguments are - everybody uses python in astrophysics - it is very easy to find someone who knows python - risk that I, sole Go programmer, might become unavailable I would have the same arguments if I was project leader and unfamiliar with Go. The counter arguments I found so far are that - Go is simpler and safer than Python - I learned Go in a week-end The problem is that they don't convince people who don't know Go, are not experienced software developers, and don't want to do the due diligence. It's the usual inertia to change. What other arguments could I use ? Do you know other significant scientific experiments that have adopted Go ? I have found this github project. https://github.com/indigo-astronomy/indigo INDI is a well known Python Observatory Control System. INDIGO is its translation into Go. I have also found SciPipe https://github.com/scipipe. It is a Go pipeline framework used in scientific applications. -- 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: Error Handling
Just for clarification, the function fn() must return an interface for this to work. -- 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.
