Re: [go-nuts] When set time.Location, will be detected Data Race

On Thu, Nov 29, 2018 at 9:47 PM wrote: > > My go version is 1.11. > > When I set time.Location, then … > > == > WARNING: DATA RACE > Write at 0x02e275d0 by main goroutine: > vcs.taiyouxi.net/platform/planx/timeutil.SetTimeLocal() > > /Users/zhangzhen/serverthreekingdom

[go-nuts] When set time.Location, will be detected Data Race

My go version is 1.11. When I set time.Location, then … == WARNING: DATA RACE Write at 0x02e275d0 by main goroutine: vcs.taiyouxi.net/platform/planx/timeutil.SetTimeLocal() /Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/platform/planx/timeutil/time_util.go

[go-nuts] how to build golang program with a lower kernel requirement?

I build golang programe on ubuntu 18.04, try to run it on ubuntu 16.04 , it hint "kernal too old" ldd --version ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27 #ubuntu 18.04 ldd (Ubuntu GLIBC 2.23-3ubuntu1) 2.23 #ubuntu 16.04 glibc 2.24 above requires kernel 3.2 minimum glibc 2.23 requires kernel 2.6.32.

Re: [go-nuts] [ANN] fixed point math library

Quoting Bakul Shah (2018-11-29 22:13:45) > I doubt go2 will get generics flexible enough for this! It can actually already pull much of this off, and you don't even need the contracts part of the draft. E.g: // Type 'Money' represents a monetary value. The Currency type parameter // is unused at

Re: [go-nuts] [ANN] fixed point math library

Yes, a real currency type would contain a Fixed. Most likely adding a symbol, code, etc. > On Nov 29, 2018, at 9:13 PM, Bakul Shah wrote: > > FWIW, in some code I am writing, I considered using > fixed point decimal numbers but ended up defining a > *currency* type which is an int64 for value

Re: [go-nuts] [ANN] fixed point math library

FWIW, in some code I am writing, I considered using fixed point decimal numbers but ended up defining a *currency* type which is an int64 for value + a separate unit + currency kind. Even if I use a unit of millicent, this will allow handling amounts close to $100 Trillion. I don't expect this lim

Re: [go-nuts] GORM, saving values

In addition to exported fields, you don't need to import _ "github.com/lib/pq" just these "github.com/jinzhu/gorm" _ "github.com/jinzhu/gorm/dialects/postgres" четверг, 29 ноября 2018 г., 21:04:06 UTC+3 пользователь Mohamed Yousif написал: > > Beside exporting issue, you need to

Re: [go-nuts] [ANN] fixed point math library

On Fri, Nov 30, 2018 at 12:26 AM Nigel Tao wrote: On Thu, Nov 29, 2018 at 9:20 PM Jan Mercl <0xj...@gmail.com> wrote: > Well, there's already context.Context, hash.Hash, image.Image and > time.Time in the standard library. Perhaps, in a parallel universe, we > could have settled on the testing.T

Re: [go-nuts] [ANN] fixed point math library

On Thu, 2018-11-29 at 17:07 -0600, robert engels wrote: > The dot imports are useful, and others feel the same https://github.c > om/golang/lint/issues/179 > . When you make statements > like,  > > > > > Now given that dot imports are generally considere

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 9:20 PM Jan Mercl <0xj...@gmail.com> wrote: > - To me type name 'fixed.Fixed' sounds like Javaism. Well, there's already context.Context, hash.Hash, image.Image and time.Time in the standard library. Perhaps, in a parallel universe, we could have settled on the testing.T na

Re: [go-nuts] [ANN] fixed point math library

On Fri, Nov 30, 2018 at 12:07 AM robert engels wrote: > The dot imports are useful, and others feel the same https://github.com/golang/lint/issues/179. Not all others do feel the same. Actually, most others do not. From Go Code Review Comments

Re: [go-nuts] [ANN] fixed point math library

The dot imports are useful, and others feel the same https://github.com/golang/lint/issues/179 . When you make statements like, > Now given that dot imports are generally considered a bad idea in Go It feels a lot like the “cut off the sides of the ro

Re: [go-nuts] [ANN] fixed point math library

fixed.Number reduces stutter and is more informative. This was Jan's point. In general dot imports are a bad idea when maintaining large code bases since it requires more work to figure out what is actually providing the X that has been added to the . imports pool. It also a prevents the protectio

Re: [go-nuts] [ANN] fixed point math library

Right and since fixed.Fixed can be reduced to Fixed with no loss of information, it is a great lossless compression - more than 50 %. Thanks for playing ! > On Nov 29, 2018, at 4:11 PM, Daniel Kortschak wrote: > > That is correct. The number of physical bits used to represent the > informatio

Re: [go-nuts] [ANN] fixed point math library

I believe Jan is talking about bits in the information-theoretic sense. I.e, asking "how much do I know?", not "how much space does this take up?" Quoting robert engels (2018-11-29 17:10:51) >Would you elaborate? I've read the discussion multiple times, and can't >see what other bits you t

Re: [go-nuts] Rethink possibility to make circular imports

And to reduce build time, especially for incremental builds. -rob On Fri, Nov 30, 2018 at 8:17 AM Ian Lance Taylor wrote: > On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux > wrote: > > > > The last few days I've been thinking a lot about the fact that Go does > not allow circular imports. > >

Re: [go-nuts] [ANN] fixed point math library

That is correct. The number of physical bits used to represent the information is reduced. The number of bits of information remains the same except in the case of lossy compression. If this were not true, I could propose the following compression protocol: count the number of 1 bits in the uncomp

Re: [go-nuts] [ANN] fixed point math library

Would you elaborate? I’ve read the discussion multiple times, and can’t see what other bits you think he is referring to. > On Nov 29, 2018, at 3:07 PM, Jan Mercl <0xj...@gmail.com> wrote: > > > On Thu, Nov 29, 2018 at 10:02 PM robert engels > wrote: > > > I’m pr

[go-nuts] Re: [ANN] fixed point math library

This made the front page of Hacker News https://news.ycombinator.com/item?id=18559625 On Wednesday, November 28, 2018 at 10:47:37 PM UTC-8, robert engels wrote: > > For those interesting in financial apps, I have released ‘fixed' at > https://github.com/robaho/fixed a high performance fixed-poi

Re: [go-nuts] Rethink possibility to make circular imports

On Thu, Nov 29, 2018 at 5:22 AM Michel Levieux wrote: > > The last few days I've been thinking a lot about the fact that Go does not > allow circular imports. > I'm not really sure of why it currently works that way, but from what I've > understood the way the compiler works - which is also the

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 10:02 PM robert engels wrote: > I’m pretty sure that is not correct, see https://www.maximumcompression.com > > Most lossless text compression is > 85 %, and if you use lossy compression (images, audio) it can be 100:1 Dan was talking about quite different bits. -- -j

Re: [go-nuts] [ANN] fixed point math library

I’m pretty sure that is not correct, see https://www.maximumcompression.com Most lossless text compression is > 85 %, and if you use lossy compression (images, audio) it can be 100:1 > On Nov 29, 2018, at 2:39 PM, Daniel Kortschak wrote: > > In the majori

Re: [go-nuts] [ANN] fixed point math library

In the majority of cases compression does not reduce the number of bits of information (appreciably). On Thu, 2018-11-29 at 08:35 -0600, Robert Engels wrote: > And since you like lingo, more bits of information is not always a > good thing. That’s why we have compression, and lossless compression

[go-nuts] small utility for i3 wm users

Hello Gophers, I have written a small script to display the open application names in the i3 wm workspace bar. You can also map each application to a custom name. I use the great i3/go-i3 package (https://github.com/i3/go-i3). https://github.com/tbellembois/goi3autowname Regards, Thomas -- Yo

Re: [go-nuts] GORM, saving values

Beside exporting issue, you need to commit these models into your database. I use .Create(). On Thu, 29 Nov 2018 at 5:47 PM, Robert Engels wrote: > If gorm is like json marshalling the fields need to be exported, that is > capitalized. > > Just a thought. > > On Nov 29, 2018, at 12:02 AM, mmbari

Re: [go-nuts] GORM, saving values

If gorm is like json marshalling the fields need to be exported, that is capitalized. Just a thought. > On Nov 29, 2018, at 12:02 AM, mmbarighz...@gmail.com wrote: > > New to Go - please bear with me. > > I am trying to create a new row in my table, but the values are being saved > as `Null

[go-nuts] time_now may cause linux kernel run out of CPU

package main import ( "fmt" "log" "net/http" _ "net/http/pprof" "sync" "time" ) func main() { go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }() wg := sync.WaitGroup{} fmt.Println("see cpu profile") ch := make(chan struct{}) time.AfterFunc(time.Second*60, func() { close(ch)

[go-nuts] Questions on finalizers in Go 1.6 runtime

Hi, guys I saw the issue posted by Ian Lance Tayler on finalizers. I am wandering whether the statement "input args are kept live until the end of the function, including the receiver for methods" commented by Keith Randy is true in Go 1.6 Here is m

Re: [go-nuts] [ANN] fixed point math library

That being said, I am not sure why I can use the qualified package name when I have a dot import. This would be helpful for method collision like New() > On Nov 29, 2018, at 8:35 AM, Robert Engels wrote: > > I am not referring to variable declarations I am referring to > > X := SomeFunc() > >

Re: [go-nuts] [ANN] fixed point math library

I am not referring to variable declarations I am referring to X := SomeFunc() Far worse for understanding than having common or ubiquitous structs as dot imports. That way they become “part of the language” Static imports were added to Java long ago and if Java guys can figure it out I think y

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 3:07 PM Robert Engels wrote: > Wait, you support type inference and not dot imports... I think you should revisit this opinion... I believe it's the other way around. Seeing T alone has n bits of information. Seeing foo.T carries more bits of information. So Seeing x :=

Re: [go-nuts] [ANN] fixed point math library

Wait, you support type inference and not dot imports... I think you should revisit this opinion... also, dot imports are very versatile when changing the implementation without changing a lot of LOC. I think the string method is certainly more useful when dealing with external systems or files

Re: [go-nuts] [ANN] fixed point math library

Yes it does (for some reason I was thinking that Cmp returning 0 was false but it's not it's equals :) ), I'm not sure Cmp can be implemented in that case, at least without panicing NaN == NaN should be false, the other packages like decimal & big don't seem to have an issue as NaN can't exist?

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:41 PM Robert Engels wrote: > Ah, you want a ctor that is the int value. Ok. The Raw doesn’t do this anyway... I could add a NewI() ctor but I’m not sure it is much that NewF(float64(x)) given the magnitude restrictions. The OP says: "For those interesting in financial

Re: [go-nuts] [ANN] fixed point math library

Yeah I posted that before rereading your initial reply to Jan, I can accept the argument of not exposing the underlying type directly (to avoid using standard int operators on Fixed values), however the raw accessors circumvent that since you could always use them to modify a value through a po

Re: [go-nuts] [ANN] fixed point math library

Btw, thus includes == when using NaN and float64. It’s strange but that’s the way it’s defined. > On Nov 29, 2018, at 7:46 AM, Robert Engels wrote: > > Technically, a NaN in comparison with any other including NaN is false. For > Cmp this creates a problem > >> On Nov 29, 2018, at 7:41

Re: [go-nuts] [ANN] fixed point math library

Technically, a NaN in comparison with any other including NaN is false. For Cmp this creates a problem > On Nov 29, 2018, at 7:41 AM, Robert Engels wrote: > > Ah, you want a ctor that is the int value. Ok. The Raw doesn’t do this > anyway... I could add a NewI() ctor but I’m not sure it i

Re: [go-nuts] [ANN] fixed point math library

You don’t want fp public for value safety. The Raw methods are going away in favor of direct read and write. > On Nov 29, 2018, at 7:32 AM, Jamie Clarkson wrote: > > Also I fail to see the point of the ToRaw/fromRaw when you could just make FP > public. > >> On Thursday, November 29, 2018 at

Re: [go-nuts] [ANN] fixed point math library

Ah, you want a ctor that is the int value. Ok. The Raw doesn’t do this anyway... I could add a NewI() ctor but I’m not sure it is much that NewF(float64(x)) given the magnitude restrictions. If you review the gotrader you’ll see that it uses a dot import on this. If it was just Number you lose

[go-nuts] Re: Rethink possibility to make circular imports

Hi Michel, Maybe it would help if you gave an example of some code that you think requires circular imports and we can see if it can be restructured without? (IMO forbidding circular imports is a great strength!) Kind regards, Jamie On Thursday, November 29, 2018 at 1:23:04 PM UTC, Michel Lev

Re: [go-nuts] Rethink possibility to make circular imports

On Thu, Nov 29, 2018 at 2:22 PM Michel Levieux wrote: > The main reason why I'm strongly convinced forbidding circular imports is not a good thing is that it separates too much the problem space from the solution space. TBH, I cannot even figure out how could _possibly_ circular imports work. Ha

Re: [go-nuts] [ANN] fixed point math library

Scratch that, just seen your original reply to Jan about them being temporary. On Thursday, November 29, 2018 at 1:32:10 PM UTC, Jamie Clarkson wrote: > > Also I fail to see the point of the ToRaw/fromRaw when you could just make > FP public. > > On Thursday, November 29, 2018 at 1:28:40 PM UTC,

Re: [go-nuts] Rethink possibility to make circular imports

Can I suggest you provide a real example to help motivate why you think circular package imports should work, and therefore what they would solve? I will note that circular module dependencies are possible and have good reasons to exist (https://github.com/go-modules-by-example/index/blob/master/0

Re: [go-nuts] [ANN] fixed point math library

Also I fail to see the point of the ToRaw/fromRaw when you could just make FP public. On Thursday, November 29, 2018 at 1:28:40 PM UTC, Jamie Clarkson wrote: > > I think the logic should be that if either operand is NaN the comparison > should be false to match floats (currently it looks like f

Re: [go-nuts] [ANN] fixed point math library

I think the logic should be that if either operand is NaN the comparison should be false to match floats (currently it looks like f < NaN and NaN < f give incorrect results), you might have some reason for that though. A few other random thoughts: - Not all methods/funcs are documented (whic

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:15 PM Robert Engels wrote: > Also, the most important reason against the setters - a Fixed is immutable. Great, then just let the setter return a value. x := fixed.New(0).SetString(foo) Similarly like big.Float.SetString

[go-nuts] Rethink possibility to make circular imports

The last few days I've been thinking a lot about the fact that Go does not allow circular imports. I'm not really sure of why it currently works that way, but from what I've understood the way the compiler works - which is also the reason why compilation of Go programs is much faster than other lan

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 2:00 PM Robert Engels wrote: >> - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually tries to avoid such stutter: 'sort.Interface', 'big.Int' etc. > To me that’s a limitation of Go with small packages like this that only have a single public struct. It is

Re: [go-nuts] [ANN] fixed point math library

Also, the most important reason against the setters - a Fixed is immutable. > On Nov 29, 2018, at 7:00 AM, Robert Engels wrote: > > Thanks for the feedback. My comments below. > >> - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually tries >> to avoid such stutter: 'sort.Inte

Re: [go-nuts] [ANN] fixed point math library

NaN cannot be returned in an int so not possible. > On Nov 29, 2018, at 4:41 AM, messju mohr wrote: > > Hello, > > this looks like a really nice and useful library! :) > > Just one thing: At first glance i saw that fixed.Cmp() returns 0 when both > operands are NaN. > I think it would be mor

Re: [go-nuts] [ANN] fixed point math library

Thanks for the feedback. My comments below. > - To me type name 'fixed.Fixed' sounds like Javaism. Go code usually tries to > avoid such stutter: 'sort.Interface', 'big.Int' etc. > To me that’s a limitation of Go with small packages like this that only have a single public struct. It is based

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

Hi Göcs, Could you expand on your question, including a bit more about the scenario you are in, what you are seeing currently, and what you would like to see instead? It would probably help to include a simplified example that is representative of your question or issue. For example (and makin

Re: [go-nuts] [ANN] fixed point math library

Hello, this looks like a really nice and useful library! :) Just one thing: At first glance i saw that fixed.Cmp() returns 0 when both operands are NaN. I think it would be more consistent if fixed.Cmp() would return NaN if any of it's operands are NaN. just my 2ct messju On Thu, Nov 29, 201

Re: [go-nuts] [ANN] fixed point math library

On Thu, Nov 29, 2018 at 7:47 AM robert engels wrote: > For those interesting in financial apps, I have released ‘fixed' at https://github.com/robaho/fixed a high performance fixed-point math library primarily designed for to work with currencies. - To me type name 'fixed.Fixed' sounds like Javai