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

[Ian Lance Taylor]

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/src/vcs.taiyouxi.net/platform/planx/timeutil/time_util.go:51
>  +0xb4
>   vcs.taiyouxi.net/platform/planx/timeutil.init.0()
>   
> /Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/platform/planx/timeutil/time_util.go:42
>  +0x43
>   vcs.taiyouxi.net/platform/planx/timeutil.init()
>   :1 +0xd0
>   vcs.taiyouxi.net/jws2/common/time.init()
>   :1 +0xa6
>   vcs.taiyouxi.net/jws2/gamex/account/account.init()
>   :1 +0xa6
>   vcs.taiyouxi.net/jws2/gamex/logics.init()
>   :1 +0xa6
>   vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init()
>   :1 +0xa6
>   main.init()
>   :1 +0xa6
>
> Previous read at 0x02e275d0 by goroutine 8:
>   time.Now()
>   /Users/zhangzhen/.gvm/gos/go1.11/src/time/time.go:1060 +0xcf
>   time.sendTime()
>   /Users/zhangzhen/.gvm/gos/go1.11/src/time/sleep.go:141 +0x44
>
> Goroutine 8 (running) created at:
>   runtime.(*timersBucket).addtimerLocked()
>   /Users/zhangzhen/.gvm/gos/go1.11/src/runtime/time.go:170 +0x113
>   
> vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel.NewTimingWheel()
>   
> /Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel/timingwheel.go:39
>  +0x2a0
>   vcs.taiyouxi.net/platform/planx/util.init()
>   
> /Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/platform/planx/util/timer_helper.go:10
>  +0xf3
>   vcs.taiyouxi.net/platform/planx/metrics.init()
>   :1 +0xbf
>   vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init()
>   :1 +0x9c
>   main.init()
>   :1 +0xa6
> ==
>
> The feature of golang is goroutine, and it is a normal situation that get 
> time in different goroutine.
> But only can set time.Location in one goroutine. So the Data Race is 
> inevitable.
>
>
> And there is the replay from agnivade 3
>
> “It is not a bug. Please synchronize access to time.Location using 
> synchronization primitives in the sync andsync/atomic packages.”
>
>
> But there are lots of place that time.Location used by time package of 
> golang. For example: time.Now(), time.locabs()
> I can’t change them.
>
>
> So, What should I do ? Please help me.

You said time.Location.  Do you mean time.Local?  It's true that you
should never change time.Local.  Why  do you want to?  If you want to
change the location of a specific time.Time value, call the In method.

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] When set time.Location, will be detected Data Race

[zhangzhentaihe]

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:51
 +0xb4
  vcs.taiyouxi.net/platform/planx/timeutil.init.0()
  
/Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/platform/planx/timeutil/time_util.go:42
 +0x43
  vcs.taiyouxi.net/platform/planx/timeutil.init()
  :1 +0xd0
  vcs.taiyouxi.net/jws2/common/time.init()
  :1 +0xa6
  vcs.taiyouxi.net/jws2/gamex/account/account.init()
  :1 +0xa6
  vcs.taiyouxi.net/jws2/gamex/logics.init()
  :1 +0xa6
  vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init()
  :1 +0xa6
  main.init()
  :1 +0xa6

Previous read at 0x02e275d0 by goroutine 8:
  time.Now()
  /Users/zhangzhen/.gvm/gos/go1.11/src/time/time.go:1060 +0xcf
  time.sendTime()
  /Users/zhangzhen/.gvm/gos/go1.11/src/time/sleep.go:141 +0x44

Goroutine 8 (running) created at:
  runtime.(*timersBucket).addtimerLocked()
  /Users/zhangzhen/.gvm/gos/go1.11/src/runtime/time.go:170 +0x113
  vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel.NewTimingWheel()
  
/Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/vendor/github.com/siddontang/go/timingwheel/timingwheel.go:39
 +0x2a0
  vcs.taiyouxi.net/platform/planx/util.init()
  
/Users/zhangzhen/serverthreekingdom/src/vcs.taiyouxi.net/platform/planx/util/timer_helper.go:10
 +0xf3
  vcs.taiyouxi.net/platform/planx/metrics.init()
  :1 +0xbf
  vcs.taiyouxi.net/jws2/gamex/cmds/gamemode.init()
  :1 +0x9c
  main.init()
  :1 +0xa6
==

The feature of golang is goroutine, and it is a normal situation that get 
time in different goroutine.
But only can set time.Location in one goroutine. So the Data Race is 
inevitable.


And there is the replay from *agnivade 3 *

“It is not a bug. Please synchronize access to time.Location using 
synchronization primitives in the sync andsync/atomic packages.”


But there are lots of place that time.Location used by time package of 
golang. For example: time.Now(), time.locabs()
I can’t change them.


So, What should I do ? Please help me.

-- 
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] how to build golang program with a lower kernel requirement?

[hui zhang]

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. minimum #ubuntu 16.04

Q1:
how to build golang program with a lower kernel requirement?

Q2:
on the other hand 
if I build golang program on ubuntu 16.04 ,  can it run on ubuntu 18.04

-- 
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] [ANN] fixed point math library

[Ian Denhardt]

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 runtime, but serves to prevent mixing up different
// currencies:
type Money(type Currency) int64

// These types used as the parameter for 'Money'. They are never used as
// values, just as part of this trick with the type system -- because of
// this you'll sometimes hear them referred to as "phantom types".
type USD struct{}
type EUR struct{}
type GBP struct{}
// ...

var m1 Money(USD) = 5
var m2 Money(USD) = 10
var m3 Money(EUR) = 2

m1 + m2 // ok
m2 + m3 // type error: Money(USD) vs. Money(EUR)

-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] [ANN] fixed point math library

[Robert Engels]

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 + 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 limit to be a problem for my personal
> finances! Performance is not an issue for my use. I
> even store all the financial data in text files!
> 
> Dealing with stuff such  as currency conversion, interest
> rates, stocks etc. gets a bit complicated due to their own
> precision needs but for that one can look at existing
> practices to do the right thing (which is, be able to accurately
> implement the rules your bank etc use).
> 
> [Aside:
> Ideally this would be done using a *generic* currency
> type. Something like
> 
> import "currency"
> type $ = currency.Type("$")
> type £ = currency.Type("£")
> 
> var m1 = $(5)
> var m2 = $(10)
> var m3 = £(2)
> 
> m1 + m2 // ok
> m2 + m3 // compile time error
> m1*m2 // compile time error
> m1*5  // ok
> m1+5  // compile time error
> 
> I doubt go2 will get generics flexible enough for this!
> ]
> 
>> On Nov 28, 2018, at 10:47 PM, 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.
>> 
>> The benchmarks: (Decimal is the shopspring library, big Int/Float are the 
>> stdlib)
>> 
>> BenchmarkAddFixed-8  20   0.83 ns/op
>> 0 B/op  0 allocs/op
>> BenchmarkAddDecimal-8 300   457 ns/op 
>> 400 B/op 10 allocs/op
>> BenchmarkAddBigInt-8 1   19.2 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkAddBigFloat-8   2000   110 ns/op  
>> 48 B/op  1 allocs/op
>> BenchmarkMulFixed-8  1   12.4 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkMulDecimal-8200094.2 ns/op
>> 80 B/op  2 allocs/op
>> BenchmarkMulBigInt-8 1   22.0 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkMulBigFloat-8   300050.0 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkDivFixed-8  1   19.3 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkDivDecimal-8 100  1152 ns/op 
>> 928 B/op 22 allocs/op
>> BenchmarkDivBigInt-8 200068.4 ns/op
>> 48 B/op  1 allocs/op
>> BenchmarkDivBigFloat-8   1000   151 ns/op  
>> 64 B/op  2 allocs/op
>> BenchmarkCmpFixed-8  20   0.28 ns/op
>> 0 B/op  0 allocs/op
>> BenchmarkCmpDecimal-81   10.8 ns/op 
>> 0 B/op  0 allocs/op
>> BenchmarkCmpBigInt-8 28.37 ns/op
>> 0 B/op  0 allocs/op
>> BenchmarkCmpBigFloat-8   27.74 ns/op
>> 0 B/op  0 allocs/op
>> BenchmarkStringFixed-8   200099.0 ns/op
>> 16 B/op  1 allocs/op
>> BenchmarkStringDecimal-8  500   326 ns/op 
>> 144 B/op  5 allocs/op
>> BenchmarkStringBigInt-8  1000   209 ns/op  
>> 80 B/op  3 allocs/op
>> BenchmarkStringBigFloat-8 300   571 ns/op 
>> 272 B/op  8 allocs/op
>> 
>> 
>> -- 
>> 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.

-- 
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] [ANN] fixed point math library

[Bakul Shah]

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 limit to be a problem for my personal
finances! Performance is not an issue for my use. I
even store all the financial data in text files!

Dealing with stuff such  as currency conversion, interest
rates, stocks etc. gets a bit complicated due to their own
precision needs but for that one can look at existing
practices to do the right thing (which is, be able to accurately
implement the rules your bank etc use).

[Aside:
Ideally this would be done using a *generic* currency
type. Something like

import "currency"
type $ = currency.Type("$")
type £ = currency.Type("£")

var m1 = $(5)
var m2 = $(10)
var m3 = £(2)

m1 + m2 // ok
m2 + m3 // compile time error
m1*m2   // compile time error
m1*5// ok
m1+5// compile time error

I doubt go2 will get generics flexible enough for this!
]

> On Nov 28, 2018, at 10:47 PM, 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.
> 
> The benchmarks: (Decimal is the shopspring library, big Int/Float are the 
> stdlib)
> 
> BenchmarkAddFixed-8   20   0.83 ns/op
> 0 B/op  0 allocs/op
> BenchmarkAddDecimal-8  300   457 ns/op 
> 400 B/op 10 allocs/op
> BenchmarkAddBigInt-8  1   19.2 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkAddBigFloat-82000   110 ns/op  
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8   1   12.4 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkMulDecimal-8 200094.2 ns/op
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-8  1   22.0 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8300050.0 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkDivFixed-8   1   19.3 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkDivDecimal-8  100  1152 ns/op 
> 928 B/op 22 allocs/op
> BenchmarkDivBigInt-8  200068.4 ns/op
> 48 B/op  1 allocs/op
> BenchmarkDivBigFloat-81000   151 ns/op  
> 64 B/op  2 allocs/op
> BenchmarkCmpFixed-8   20   0.28 ns/op
> 0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8 1   10.8 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkCmpBigInt-8  28.37 ns/op
> 0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-827.74 ns/op
> 0 B/op  0 allocs/op
> BenchmarkStringFixed-8200099.0 ns/op
> 16 B/op  1 allocs/op
> BenchmarkStringDecimal-8   500   326 ns/op 
> 144 B/op  5 allocs/op
> BenchmarkStringBigInt-8   1000   209 ns/op  
> 80 B/op  3 allocs/op
> BenchmarkStringBigFloat-8  300   571 ns/op 
> 272 B/op  8 allocs/op
> 
> 
> -- 
> 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] GORM, saving values

[Space A.]

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 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...@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`. Can anyone see the problem here?
>>
>> package main
>>
>> import (
>>"fmt"
>>"log"
>>
>> "github.com/jinzhu/gorm"
>>_ "github.com/jinzhu/gorm/dialects/postgres"
>>_ "github.com/lib/pq"
>> )
>>
>> type contact struct {
>>gorm.Model
>>idint`gorm:"primary_key;not null;unique;AUTO_INCREMENT"`
>>fname string `gorm:"type:TEXT"`
>>lname string `gorm:"type:TEXT"`
>>email string `gorm:"type:TEXT"`
>> }
>>
>> func main() {
>>connStr := "user=postgres dbname=postgres sslmode=disable"
>>db, err := gorm.Open("postgres", connStr)
>>
>> if err != nil {
>>log.Fatal(err)
>>}
>>
>> defer db.Close()
>>
>> db.AutoMigrate({})
>>
>> c := contact{
>>fname: "bob",
>>lname: "job",
>>email: "b...@jb.com ",
>>}
>>
>> fmt.Println()
>>db.Create()
>>
>> }
>>
>> 
>>
>>
>>
>> -- 
>> 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...@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] [ANN] fixed point math library

[Jan Mercl]

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 naming style, but that's all
> academic, at this point.

Those names are set in stone by the Go 1 compatibility guarantee. The
interesting, but hypothetical, question is, if possible and revisited now,
whether a better name would be chosen. It's not always possible, I guess.
Still, when it _is_, the more informative type name should be IMO
preferred. big.{Int,Float,Rat} was already mentioned, but it should be
added, that the math/big package started with only the big.Int type, not
big.Big or big.BigtInt type.


-- 

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

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

[Dan Kortschak]

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 considered a bad idea in
> > Go
> It feels a lot like the “cut off the sides of the roast to fit it in
> the oven”.
> 
> As I cited, there were static imports added to Java a long time ago,
> and it is not a problem. Clearly it can’t be that challenging to Go
> developers.

Just because something existed somewhere else with different context
(where is may or may not have been a good idea) means that it will be a
good idea here.

> In Java you don’t write java.lang.Object… you write Object. Similarly
> in Go, I don’t write github.com/golang/go/runtime/X
>  I write runtime.X and I don’t
> write go.int64 I write int64 - why? because int64 is a language
> specified type.

There's a significant difference here. In go we don't continually
reiterate the import path is is unfortunately the case in java. That
additional verbosity is possibly a reason why it might have been a good
idea in java, though eliding the redundant path information at the call
site probably would have been better.

> By using dot imports you can promote user types to standard types.

And in my experience this leads to additional cognitive load on the
maintainer. A similar argument exists for why operator overloading
doesn't exist in Go.

> When writing application code - not systems code - you are often
> working in a constrained environment that the architect has chosen.
> The dot imports allow the coding to be close to a DSL. Maybe I create
> a package ‘common’ that has “wrappers/facades’ for a lot of
> APIs/packages I want my developers to use, but I don’t want to expose
> all of the functionality. By using a dot import on the common
> package, the developer works with a concept “Fixed” - she doesn’t
> need to know it is maybe a decimal.Decimal behind the scenes, and it
> has a API limited to the solving the problem domain.

The labels make close to zero difference here. If the user wants to
make a dsl, they can do that, but don't expect me to consume their
code.

> It allows the designer and extra layer of abstraction and
> simplification. The developers don’t need to import/learn a gazillion
> packages with hundreds of methods, they import ‘common’ as a facade
> providing a simplified interface to the system. Having to prefix
> every type with ‘common' is senseless. In reality there would
> probably be multiple packages, like ‘common’, ‘printing’, ‘security’,
> ‘database' etc. but even then the name collision would be limited by
> the designer. This is enterprise/framework design 101.
> 
> 
> 
> 
> 
> > 
> > On Nov 29, 2018, at 4:34 PM, Daniel Kortschak 
> > wrote:
> > 
> > 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
> > protection you get from importing colliding labels under different
> > name
> > spaces. foo.X and bar.X; import ( . "foo"; . "bar" ) and you have
> > problems.
> > 
> > When you change the rules of the game, of course you can win. My
> > point
> > below says that information is not reduced by lossless compression
> > (your claim being the opposite). Given that as you show fixed.Fixed
> > is
> > almost completely compressible without any tricks to 50% its
> > original
> > size (almost because of the capitalisation, but given the
> > requirement
> > for exported labels to be capitalised we can invoke context,
> > though...
> > if you rename your package to Fixed, then you get perfect 50%
> > compression without context). Now given that dot imports are
> > generally
> > considered a bad idea in Go and that as you show your label can be
> > compressed, the conclusion is not that you should compress, but
> > rather
> > there is room to add additional information; fixed.Number.
> > 
> > Thanks for playing!
> > 
> > On Thu, 2018-11-29 at 16:24 -0600, robert engels wrote:
> > > 
> > > 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  > > > .io>
> > > > wrote:
> > > > 
> > > > 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 

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

[Nigel Tao]

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 naming style, but that's all
academic, at this point.

FWIW, in the golang.org/x/image/math/fixed package, the qualified type
name is fixed.Int26_6 and a constructor function is fixed.I.

https://godoc.org/golang.org/x/image/math/fixed

-- 
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] [ANN] fixed point math library

[Jan Mercl]

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

:

This page collects common comments made during reviews of Go code,
so that a single detailed
explanation can be referred to by shorthands. This is a laundry
list of common mistakes, not a
comprehensive style guide.

And in particular: Import Dot



The import . form can be useful in tests that, due to circular
dependencies, cannot be made part of
the package being tested:

package foo_test
import (
"bar/testutil" // also imports "foo"
 . "foo"
)

In this case, the test file cannot be in package foo because it uses
bar/testutil, which imports foo.
So we use the 'import .' form to let the file pretend to be part of package
foo even though it is not. Except
for this one case, do not use import . in your programs. It makes the
programs much harder to read
because it is unclear whether a name like Quux is a top-level identifier in
the current package or in
an imported package.


-- 

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

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

[robert engels]

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 roast to fit it in the oven”.

As I cited, there were static imports added to Java a long time ago, and it is 
not a problem. Clearly it can’t be that challenging to Go developers.

In Java you don’t write java.lang.Object… you write Object. Similarly in Go, I 
don’t write github.com/golang/go/runtime/X 
 I write runtime.X and I don’t write 
go.int64 I write int64 - why? because int64 is a language specified type.

By using dot imports you can promote user types to standard types.

When writing application code - not systems code - you are often working in a 
constrained environment that the architect has chosen. The dot imports allow 
the coding to be close to a DSL. Maybe I create a package ‘common’ that has 
“wrappers/facades’ for a lot of APIs/packages I want my developers to use, but 
I don’t want to expose all of the functionality. By using a dot import on the 
common package, the developer works with a concept “Fixed” - she doesn’t need 
to know it is maybe a decimal.Decimal behind the scenes, and it has a API 
limited to the solving the problem domain.

It allows the designer and extra layer of abstraction and simplification. The 
developers don’t need to import/learn a gazillion packages with hundreds of 
methods, they import ‘common’ as a facade providing a simplified interface to 
the system. Having to prefix every type with ‘common' is senseless. In reality 
there would probably be multiple packages, like ‘common’, ‘printing’, 
‘security’, ‘database' etc. but even then the name collision would be limited 
by the designer. This is enterprise/framework design 101.





> On Nov 29, 2018, at 4:34 PM, Daniel Kortschak  wrote:
> 
> 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
> protection you get from importing colliding labels under different name
> spaces. foo.X and bar.X; import ( . "foo"; . "bar" ) and you have
> problems.
> 
> When you change the rules of the game, of course you can win. My point
> below says that information is not reduced by lossless compression
> (your claim being the opposite). Given that as you show fixed.Fixed is
> almost completely compressible without any tricks to 50% its original
> size (almost because of the capitalisation, but given the requirement
> for exported labels to be capitalised we can invoke context, though...
> if you rename your package to Fixed, then you get perfect 50%
> compression without context). Now given that dot imports are generally
> considered a bad idea in Go and that as you show your label can be
> compressed, the conclusion is not that you should compress, but rather
> there is room to add additional information; fixed.Number.
> 
> Thanks for playing!
> 
> On Thu, 2018-11-29 at 16:24 -0600, robert engels wrote:
>> 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
>>> 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 uncompressed stream and
>>> represent this as a binary number, recursively apply this to the
>>> ones-
>>> count until you have one one bit. This is your compressed data. I
>>> have
>>> a truly marvellous decompression scheme to complement this, which
>>> this
>>> email is too narrow to contain (damn 80 column limit), but here is
>>> the
>>> compressed version, 0x1.
>>> 
>>> On Thu, 2018-11-29 at 22:07 +0100, Jan Mercl wrote:
 
 On Thu, Nov 29, 2018 at 10:02 PM robert engels >>> .com
> 
> 
 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.
> 
> -- 
> 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 

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

[Daniel Kortschak]

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
protection you get from importing colliding labels under different name
spaces. foo.X and bar.X; import ( . "foo"; . "bar" ) and you have
problems.

When you change the rules of the game, of course you can win. My point
below says that information is not reduced by lossless compression
(your claim being the opposite). Given that as you show fixed.Fixed is
almost completely compressible without any tricks to 50% its original
size (almost because of the capitalisation, but given the requirement
for exported labels to be capitalised we can invoke context, though...
if you rename your package to Fixed, then you get perfect 50%
compression without context). Now given that dot imports are generally
considered a bad idea in Go and that as you show your label can be
compressed, the conclusion is not that you should compress, but rather
there is room to add additional information; fixed.Number.

Thanks for playing!

On Thu, 2018-11-29 at 16:24 -0600, robert engels wrote:
> 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
> > 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 uncompressed stream and
> > represent this as a binary number, recursively apply this to the
> > ones-
> > count until you have one one bit. This is your compressed data. I
> > have
> > a truly marvellous decompression scheme to complement this, which
> > this
> > email is too narrow to contain (damn 80 column limit), but here is
> > the
> > compressed version, 0x1.
> > 
> > On Thu, 2018-11-29 at 22:07 +0100, Jan Mercl wrote:
> > > 
> > > On Thu, Nov 29, 2018 at 10:02 PM robert engels  > > .com
> > > > 
> > > > 
> > > 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.

-- 
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] [ANN] fixed point math library

[robert engels]

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
> 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 uncompressed stream and
> represent this as a binary number, recursively apply this to the ones-
> count until you have one one bit. This is your compressed data. I have
> a truly marvellous decompression scheme to complement this, which this
> email is too narrow to contain (damn 80 column limit), but here is the
> compressed version, 0x1.
> 
> On Thu, 2018-11-29 at 22:07 +0100, Jan Mercl wrote:
>> 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.

-- 
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] [ANN] fixed point math library

[Ian Denhardt]

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 think he is referring to.
>
>On Nov 29, 2018, at 3:07 PM, Jan Mercl <[1]0xj...@gmail.com> wrote:
>
>On Thu, Nov 29, 2018 at 10:02 PM robert engels
><[2]reng...@ix.netcom.com> wrote:
>> I'm pretty sure that is not correct, see
>[3]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
>--
>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 [4]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [5]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 [6]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [7]https://groups.google.com/d/optout.
>
> Verweise
>
>1. mailto:0xj...@gmail.com
>2. mailto:reng...@ix.netcom.com
>3. https://www.maximumcompression.com/
>4. mailto:golang-nuts+unsubscr...@googlegroups.com
>5. https://groups.google.com/d/optout
>6. mailto:golang-nuts+unsubscr...@googlegroups.com
>7. 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] Rethink possibility to make circular imports

[Rob Pike]

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.
> > 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 languages - makes it
> quite difficult to authorize circular imports.
>
> That's not the real reason.  The real reason is to make program
> initialization as clear and unambiguous as possible.
>
> 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.
>

-- 
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] [ANN] fixed point math library

[Daniel Kortschak]

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 uncompressed stream and
represent this as a binary number, recursively apply this to the ones-
count until you have one one bit. This is your compressed data. I have
a truly marvellous decompression scheme to complement this, which this
email is too narrow to contain (damn 80 column limit), but here is the
compressed version, 0x1.

On Thu, 2018-11-29 at 22:07 +0100, Jan Mercl wrote:
> 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.

-- 
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] [ANN] fixed point math library

[robert engels]

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 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
> 
> 
> -- 
> 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: [ANN] fixed point math library

[Liam]

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-point math 
> library primarily designed for to work with currencies.
>
> The benchmarks: (Decimal is the shopspring library, big Int/Float are the 
> stdlib)
>
> BenchmarkAddFixed-8   20   0.83 ns/op
> 0 B/op  0 allocs/op
> BenchmarkAddDecimal-8  300   457 ns/op 
> 400 B/op 10 allocs/op
> BenchmarkAddBigInt-8  1   19.2 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkAddBigFloat-82000   110 ns/op  
> 48 B/op  1 allocs/op
> BenchmarkMulFixed-8   1   12.4 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkMulDecimal-8 200094.2 ns/op
> 80 B/op  2 allocs/op
> BenchmarkMulBigInt-8  1   22.0 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkMulBigFloat-8300050.0 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkDivFixed-8   1   19.3 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkDivDecimal-8  100  1152 ns/op 
> 928 B/op 22 allocs/op
> BenchmarkDivBigInt-8  200068.4 ns/op
> 48 B/op  1 allocs/op
> BenchmarkDivBigFloat-81000   151 ns/op  
> 64 B/op  2 allocs/op
> BenchmarkCmpFixed-8   20   0.28 ns/op
> 0 B/op  0 allocs/op
> BenchmarkCmpDecimal-8 1   10.8 ns/op 
> 0 B/op  0 allocs/op
> BenchmarkCmpBigInt-8  28.37 ns/op
> 0 B/op  0 allocs/op
> BenchmarkCmpBigFloat-827.74 ns/op
> 0 B/op  0 allocs/op
> BenchmarkStringFixed-8200099.0 ns/op
> 16 B/op  1 allocs/op
> BenchmarkStringDecimal-8   500   326 ns/op 
> 144 B/op  5 allocs/op
> BenchmarkStringBigInt-8   1000   209 ns/op  
> 80 B/op  3 allocs/op
> BenchmarkStringBigFloat-8  300   571 ns/op 
> 272 B/op  8 allocs/op
>
>
>

-- 
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] Rethink possibility to make circular imports

[Ian Lance Taylor]

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 reason why 
> compilation of Go programs is much faster than other languages - makes it 
> quite difficult to authorize circular imports.

That's not the real reason.  The real reason is to make program
initialization as clear and unambiguous as possible.

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] [ANN] fixed point math library

[Jan Mercl]

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

-- 
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] [ANN] fixed point math library

[robert engels]

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 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
>> of fixed.Fixed to Fixed is pretty good in my book. 

-- 
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] [ANN] fixed point math library

[Daniel Kortschak]

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
> of fixed.Fixed to Fixed is pretty good in my book. 

-- 
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] small utility for i3 wm users

[Thomas Bellembois]

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

-- 
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] GORM, saving values

[Mohamed Yousif]

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, 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`. Can anyone see the problem here?
>
> package main
>
> import (
>"fmt"
>"log"
>
> "github.com/jinzhu/gorm"
>_ "github.com/jinzhu/gorm/dialects/postgres"
>_ "github.com/lib/pq"
> )
>
> type contact struct {
>gorm.Model
>idint`gorm:"primary_key;not null;unique;AUTO_INCREMENT"`
>fname string `gorm:"type:TEXT"`
>lname string `gorm:"type:TEXT"`
>email string `gorm:"type:TEXT"`
> }
>
> func main() {
>connStr := "user=postgres dbname=postgres sslmode=disable"
>db, err := gorm.Open("postgres", connStr)
>
> if err != nil {
>log.Fatal(err)
>}
>
> defer db.Close()
>
> db.AutoMigrate({})
>
> c := contact{
>fname: "bob",
>lname: "job",
>email: "b...@jb.com",
>}
>
> fmt.Println()
>db.Create()
>
> }
>
> 
>
>
>
> --
> 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.
>

-- 
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] GORM, saving values

[Robert Engels]

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`. Can anyone see the problem here?
> 
> package main
> 
> import (
> "fmt"
> "log"
> 
> "github.com/jinzhu/gorm"
> _ "github.com/jinzhu/gorm/dialects/postgres"
> _ "github.com/lib/pq"
> )
> 
> type contact struct {
> gorm.Model
> idint`gorm:"primary_key;not null;unique;AUTO_INCREMENT"`
> fname string `gorm:"type:TEXT"`
> lname string `gorm:"type:TEXT"`
> email string `gorm:"type:TEXT"`
> }
> 
> func main() {
> connStr := "user=postgres dbname=postgres sslmode=disable"
> db, err := gorm.Open("postgres", connStr)
> 
> if err != nil {
> log.Fatal(err)
> }
> 
> defer db.Close()
> 
> db.AutoMigrate({})
> 
> c := contact{
> fname: "bob",
> lname: "job",
> email: "b...@jb.com",
> }
> 
> fmt.Println()
> db.Create()
> 
> }
> 
> 
> 
> 
> 
> 
> -- 
> 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] time_now may cause linux kernel run out of CPU

[my7andriy]

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)
})

for i := 0; i <= 100; i++ {
wg.Add(1)
go func() {
defer wg.Done()

ticker := time.NewTicker(time.Millisecond * 1000)
defer ticker.Stop()

for {
select {
case <-ticker.C:
// do something
case <-ch:
return
}
}
}()
}

fmt.Println("waiting...")
wg.Wait()
fmt.Println("all done")
}


The snippet demonstrate millions of workers do something in parallel. 
Everyone hold a time ticker to check job per second. Though it is kind of 
ridiculous in real life. 

The code works well a few days ago in Linux Mint 19(Ubuntu 18.04). It take 
60-70% CPU usage of six-core Intel I5-8500T.

Once I run the code, I see the kernel take about 85% CPU(RED bar in htop) 
and left 15% for user(GREEN bar in htop).

I try to debug using pprof.

Type: cpu
Time: Nov 29, 2018 at 8:56pm (CST)
Duration: 45.20s, Total samples = 1.55mins (206.39%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 90.80s, 97.34% of 93.28s total
Dropped 38 nodes (cum <= 0.47s)
Showing top 10 nodes out of 16
  flat  flat%   sum%cum   cum%
83.20s 89.19% 89.19% 83.25s 89.25%  time.now
 3.58s  3.84% 93.03%  3.58s  3.84%  runtime.procyield
 1.44s  1.54% 94.58%  1.44s  1.54%  runtime._VDSO
 1.04s  1.11% 95.69%  1.04s  1.11%  runtime.siftdownTimer
 0.69s  0.74% 96.43%  4.46s  4.78%  runtime.lock
 0.41s  0.44% 96.87%  5.49s  5.89%  runtime.selectgo
 0.16s  0.17% 97.04%  0.51s  0.55%  runtime.schedule
 0.11s  0.12% 97.16%  0.85s  0.91%  runtime.chansend
 0.10s  0.11% 97.27%  4.34s  4.65%  runtime.sellock
 0.07s 0.075% 97.34%  5.58s  5.98%  main.main.func3
(pprof) list time.now
Total: 1.55mins
ROUTINE  time.now in 
/usr/local/go/src/runtime/timestub.go
  1.39mins   1.39mins (flat, cum) 89.25% of Total
 .  . 11:
 .  . 12:import _ "unsafe" // for go:linkname
 .  . 13:
 .  . 14://go:linkname time_now time.now
 .  . 15:func time_now() (sec int64, nsec int32, mono 
int64) {
47.56s 47.58s 16: sec, nsec = walltime()
35.64s 35.67s 17: return sec, nsec, nanotime() - startNano
 .  . 18:}

Here you can see *time.now* take almost CPU time.

After reboot it is work well as usually. see profile below.

Type: cpu
Time: Nov 28, 2018 at 11:07pm (CST)
Duration: 30.13s, Total samples = 58.85s (195.33%)
Entering interactive mode (type "help" for commands, "o" for options)
(pprof) top
Showing nodes accounting for 47840ms, 81.29% of 58850ms total
Dropped 110 nodes (cum <= 294.25ms)
Showing top 10 nodes out of 67
  flat  flat%   sum%cum   cum%
   26080ms 44.32% 44.32%26080ms 44.32%  runtime.procyield
6050ms 10.28% 54.60% 6050ms 10.28%  runtime.futex
3990ms  6.78% 61.38%31100ms 52.85%  runtime.lock
2640ms  4.49% 65.86%36480ms 61.99%  runtime.selectgo
2290ms  3.89% 69.75% 3080ms  5.23%  runtime.unlock
2070ms  3.52% 73.27% 2080ms  3.53%  runtime.siftdownTimer
1450ms  2.46% 75.73% 1450ms  2.46%  runtime.casgstatus
1230ms  2.09% 77.82% 1280ms  2.18%  runtime.gopark
1120ms  1.90% 79.73% 1120ms  1.90%  runtime.(*waitq).dequeue
 920ms  1.56% 81.29%  940ms  1.60%  time.now

I also run the code in MacOS 10.13 and Windows 10 as I expected. It works 
well.

So is it a bug belongs to kernel or golang? even hardware?

Hardware: Dell OptiPlex 7060 micro, Intel Core I5 8500T, 8G RAM

Linux Mint 19(Ubuntu 18.04) with shipped kernel: Linux HOSTNAME 
4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:16:15 UTC 2018 x86_64 x86_64 
x86_64 GNU/Linux

Go version: go version go1.11.2 linux/amd64

GOARCH="amd64"
GOBIN=""
GOCACHE="/home/USER/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/USER/go"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 
-fdebug-prefix-map=/tmp/go-build427891521=/tmp/go-build 
-gno-record-gcc-switches"


-- 
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] Questions on finalizers in Go 1.6 runtime

[escape . the . well]

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 my code using runtime.SetFinalizer() in a concurrent environment:

__

type redisCheckerT struct {
connPool *lru.LRUCache
}

func (r *redisCheckerT) ping(host_port string) error {
connif, ok := r.connPool.Get(host_port)
if !ok {
c, err := redis.DialTimeout(
"tcp", host_port, time.Second, 3 * time.Second, 3 * time.Second)
if err != nil {
return err
}
r.connPool.Put(host_port, c)
runtime.SetFinalizer(c, redis.Conn.Close)
connif = c
}
conn := connif.(redis.Conn)
_, err := conn.Do("ping")
// Ensure conn is not finalized before conn.Do() returns
//runtime.KeepAlive(conn)
if err != nil {
r.connPool.Remove(host_port)
}
return err
}

func (r *redisCheckerT) CheckAlive(host_port string) error {
var err error
for i := 0; i < 5; i++ { // try a few times
err = r.ping(host_port)
if err != nil {
continue
}
return nil
}
log.InfoErrorf(err, "Ping server '%s' failed", host_port)
return err
}

___

Will conn be finalized before conn.Do() returns? Thanks very much

Notice that runtime.KeepAlive is not available in Go 1.6, so I commented it 
out.

-- 
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] [ANN] fixed point math library

[Robert Engels]

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()
> 
> 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 you can too. It makes constants and ubiquitous types far easier to 
> work with. 
> 
> And since you like lingo, more bits of information is not always a good 
> thing. That’s why we have compression, and lossless compression of 
> fixed.Fixed to Fixed is pretty good in my book. 
> 
>> On Nov 29, 2018, at 8:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
>> 
>> 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 := foo.T{}
>> 
>> for example, tells me about everything what I need to know when I already 
>> know what is and why I or anyone else imported package foo.
>> 
>> OTOH, "naked" T from an imported package loses that information and requires 
>> to additionally build a mind map from T to foo. That's arguably not simpler.
>> 
>> > also, dot imports are very versatile when changing the implementation 
>> > without changing a lot of LOC. 
>> 
>> Well, then I hope your code reviewer does not share my opinions about dot 
>> imports ;-)
>> 
>> BTW: Neither are dot imports allowed inside the Go project itself. IINM, the 
>> only exception are tests that were written before the build system (the go 
>> command) existed.
>> 
>> 
>> -- 
>> -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.

-- 
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] [ANN] fixed point math library

[Robert Engels]

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 you can too. It makes constants and ubiquitous types far easier to work 
with. 

And since you like lingo, more bits of information is not always a good thing. 
That’s why we have compression, and lossless compression of fixed.Fixed to 
Fixed is pretty good in my book. 

> On Nov 29, 2018, at 8:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> 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 := foo.T{}
> 
> for example, tells me about everything what I need to know when I already 
> know what is and why I or anyone else imported package foo.
> 
> OTOH, "naked" T from an imported package loses that information and requires 
> to additionally build a mind map from T to foo. That's arguably not simpler.
> 
> > also, dot imports are very versatile when changing the implementation 
> > without changing a lot of LOC. 
> 
> Well, then I hope your code reviewer does not share my opinions about dot 
> imports ;-)
> 
> BTW: Neither are dot imports allowed inside the Go project itself. IINM, the 
> only exception are tests that were written before the build system (the go 
> command) existed.
> 
> 
> -- 
> -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.

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

[Jan Mercl]

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 := foo.T{}

for example, tells me about everything what I need to know when I already
know what is and why I or anyone else imported package foo.

OTOH, "naked" T from an imported package loses that information and
requires to additionally build a mind map from T to foo. That's arguably
not simpler.

> also, dot imports are very versatile when changing the implementation
without changing a lot of LOC.

Well, then I hope your code reviewer does not share my opinions about dot
imports ;-)

BTW: Neither are dot imports allowed inside the Go project itself. IINM,
the only exception are tests that were written before the build system (the
go command) existed.


-- 

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

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

[Robert Engels]

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 and constants. I think the scaled ctor is a fine addition 
though. 

> On Nov 29, 2018, at 7:56 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> 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 apps, ...". I don't think 
> financial apps prefer using inexact floating point numbers like float64. They 
> tend to rather use _exact_ values like 1234.56. Note that many such values 
> cannot be constructed _exactly_ from a float64 at all. Probably forces the 
> user to workaround using strings. Much more effective would be x := 
> fixed.New(123456).Div(scale), where var scale = fixed.New(100) performed 
> probably in init(). Or even NewScaled(int64, int64). Or even New just should 
> have two int64 parameters. Provided we really talk about financial computing.
> 
> > If you review the gotrader you’ll see that it uses a dot import on this. 
> 
> Dot imports shall not pass my review.
> 
> > If it was just Number you lose a lot of information. 
> 
> And that's exactly why dot imports should not ne used.
> 
> -- 
> -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.

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

[Jamie Clarkson]

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?  Could be wrong.

On Thursday, November 29, 2018 at 1:46:48 PM UTC, 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 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 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 a lot of information. I find it makes the 
> structures far more readable for a common type. 
>
> Java’s BigInteger has this exact optimization when the value fits in a 
> single word. Go could do this too so it is a fair performance comparison 
> IMO. 
>
> On Nov 29, 2018, at 7:20 AM, Jan Mercl <0xj...@gmail.com > 
> wrote:
>
> 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 based on decimal.Decimal so I’m not the 
> only one who thinks this
>
> I don't think we are talking about the same thing here. Go idiom is to 
> name types such that they are not the same as the package qualifier (modulo 
> case) at the caller site. So the exported type should be 'Int', or 'Float' 
> or 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller 
> site. `var n fixed.Number` looks better to me, for example, than `var n 
> fixed.Fixed`. The later actually does not even communicate any hint what 
> the type could possibly be.
>
> >> - A struct with a single field could be replaced by the field itself. 
> OTOH, it would enable coding errors by applying arithmetic operators to it 
> directly, so it's maybe justified in this case if that was the intention.
> > It was the intention. The Raw methods are there temporarily and will be 
> removed for direct serialization via a Writer. 
>
> Then it looks strange that to construct a Fixed from int64 one has to 
> write 'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) 
> constructors and setters, they are much more natural to use.
>
> >> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
> 'SetFloat' etc.
> > Not possible. The caller doesn’t know the int64 value. Also, think of 
> how that would look in a chained math statement. Horrible. 
>
> It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that 
> has the _value_ of n, which of course has a different underlying int64 bit 
> pattern in the private Fixed field. The caller want New(42) meaning 42 and 
> does not casre about the internal, scaled value, that's just an 
> implementation detail and no business of the caller. BTW: Chained math 
> statements where the operators are written as function calls, above chains 
> of length 2 are not seen very often. Longer ones, in many cases, well, 
> that's what I'd call horrible.
>
> >> I don't consider comparing performances of 64 bit integer arithmetic 
> and arbitrary sized arithmetic very useful.
> > Those are the alternatives to use when performing fixed place 
> arithmetic. In fact decimal.Decimal uses big Int... so it is included for 
> reference. 
>
> The point being made here is fixed size fitting to a machine word on a 64 
> bit CPU vs arbitrary sizes math libs implemented inevitably by multiple 
> word structs with pointers to backing storage and the necessary allocation 
> overhead. Apples to oranges. Not even in the same league.
>
> -- 
>
> -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...@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] [ANN] fixed point math library

[Jan Mercl]

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 apps, ...". I don't think
financial apps prefer using inexact floating point numbers like float64.
They tend to rather use _exact_ values like 1234.56. Note that many such
values cannot be constructed _exactly_ from a float64 at all. Probably
forces the user to workaround using strings. Much more effective would be x
:= fixed.New(123456).Div(scale), where var scale = fixed.New(100) performed
probably in init(). Or even NewScaled(int64, int64). Or even New just
should have two int64 parameters. Provided we really talk about financial
computing.

> If you review the gotrader you’ll see that it uses a dot import on this.

Dot imports shall not pass my review.

> If it was just Number you lose a lot of information.

And that's exactly why dot imports should not ne used.

-- 

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

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

[Jamie Clarkson]

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 
pointer.  The point is moot though if the raw accessors are going away.

On Thursday, November 29, 2018 at 1:44:31 PM UTC, Robert Engels wrote:
>
> 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 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 < 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 (which might clear up the above).  
>> - It might be nice to have a clamped set for a floating value out of 
>> range (rather than just return a NaN).
>> - Can't see a way to create from an integer (other than convert to float)
>> - Personally I'd rather not see a NewS() which can silently fail with no 
>> info, I'd prefer to rename NewSErr to Parse and remove NewS.
>>
>> Other than that, pretty cool.
>>
>> Cheers,
>>
>> Jamie
>>
>> On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote:
>>>
>>> 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 more consistent if fixed.Cmp() would return NaN if 
>>> any of it's operands are NaN. 
>>> > 
>>> > just my 2ct 
>>> > messju 
>>> > 
>>> > 
>>>
>>> -- 
> 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] [ANN] fixed point math library

[Robert Engels]

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 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 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 a lot of information. I find it makes the 
>> structures far more readable for a common type. 
>> 
>> Java’s BigInteger has this exact optimization when the value fits in a 
>> single word. Go could do this too so it is a fair performance comparison 
>> IMO. 
>> 
>>> On Nov 29, 2018, at 7:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
>>> 
>>> 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 based on decimal.Decimal so I’m not 
>>> > the only one who thinks this
>>> 
>>> I don't think we are talking about the same thing here. Go idiom is to name 
>>> types such that they are not the same as the package qualifier (modulo 
>>> case) at the caller site. So the exported type should be 'Int', or 'Float' 
>>> or 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller 
>>> site. `var n fixed.Number` looks better to me, for example, than `var n 
>>> fixed.Fixed`. The later actually does not even communicate any hint what 
>>> the type could possibly be.
>>> 
>>> >> - A struct with a single field could be replaced by the field itself. 
>>> >> OTOH, it would enable coding errors by applying arithmetic operators to 
>>> >> it directly, so it's maybe justified in this case if that was the 
>>> >> intention.
>>> > It was the intention. The Raw methods are there temporarily and will be 
>>> > removed for direct serialization via a Writer. 
>>> 
>>> Then it looks strange that to construct a Fixed from int64 one has to write 
>>> 'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) constructors and 
>>> setters, they are much more natural to use.
>>> 
>>> >> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
>>> >> 'SetFloat' etc.
>>> > Not possible. The caller doesn’t know the int64 value. Also, think of how 
>>> > that would look in a chained math statement. Horrible. 
>>> 
>>> It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that 
>>> has the _value_ of n, which of course has a different underlying int64 bit 
>>> pattern in the private Fixed field. The caller want New(42) meaning 42 and 
>>> does not casre about the internal, scaled value, that's just an 
>>> implementation detail and no business of the caller. BTW: Chained math 
>>> statements where the operators are written as function calls, above chains 
>>> of length 2 are not seen very often. Longer ones, in many cases, well, 
>>> that's what I'd call horrible.
>>> 
>>> >> I don't consider comparing performances of 64 bit integer arithmetic and 
>>> >> arbitrary sized arithmetic very useful.
>>> > Those are the alternatives to use when performing fixed place arithmetic. 
>>> > In fact decimal.Decimal uses big Int... so it is included for reference. 
>>> 
>>> The point being made here is fixed size fitting to a machine word on a 64 
>>> bit CPU vs arbitrary sizes math libs implemented inevitably by multiple 
>>> word structs with pointers to backing storage and the necessary allocation 
>>> overhead. Apples to oranges. Not even in the same league.
>>> 
>>> -- 
>>> -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.
> -- 
> 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] [ANN] fixed point math library

[Robert Engels]

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 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 a lot of information. I find it makes the 
> structures far more readable for a common type. 
> 
> Java’s BigInteger has this exact optimization when the value fits in a single 
> word. Go could do this too so it is a fair performance comparison IMO. 
> 
>> On Nov 29, 2018, at 7:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
>> 
>> 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 based on decimal.Decimal so I’m not the 
>> > only one who thinks this
>> 
>> I don't think we are talking about the same thing here. Go idiom is to name 
>> types such that they are not the same as the package qualifier (modulo case) 
>> at the caller site. So the exported type should be 'Int', or 'Float' or 
>> 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller site. 
>> `var n fixed.Number` looks better to me, for example, than `var n 
>> fixed.Fixed`. The later actually does not even communicate any hint what the 
>> type could possibly be.
>> 
>> >> - A struct with a single field could be replaced by the field itself. 
>> >> OTOH, it would enable coding errors by applying arithmetic operators to 
>> >> it directly, so it's maybe justified in this case if that was the 
>> >> intention.
>> > It was the intention. The Raw methods are there temporarily and will be 
>> > removed for direct serialization via a Writer. 
>> 
>> Then it looks strange that to construct a Fixed from int64 one has to write 
>> 'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) constructors and 
>> setters, they are much more natural to use.
>> 
>> >> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
>> >> 'SetFloat' etc.
>> > Not possible. The caller doesn’t know the int64 value. Also, think of how 
>> > that would look in a chained math statement. Horrible. 
>> 
>> It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that 
>> has the _value_ of n, which of course has a different underlying int64 bit 
>> pattern in the private Fixed field. The caller want New(42) meaning 42 and 
>> does not casre about the internal, scaled value, that's just an 
>> implementation detail and no business of the caller. BTW: Chained math 
>> statements where the operators are written as function calls, above chains 
>> of length 2 are not seen very often. Longer ones, in many cases, well, 
>> that's what I'd call horrible.
>> 
>> >> I don't consider comparing performances of 64 bit integer arithmetic and 
>> >> arbitrary sized arithmetic very useful.
>> > Those are the alternatives to use when performing fixed place arithmetic. 
>> > In fact decimal.Decimal uses big Int... so it is included for reference. 
>> 
>> The point being made here is fixed size fitting to a machine word on a 64 
>> bit CPU vs arbitrary sizes math libs implemented inevitably by multiple word 
>> structs with pointers to backing storage and the necessary allocation 
>> overhead. Apples to oranges. Not even in the same league.
>> 
>> -- 
>> -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.

-- 
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] [ANN] fixed point math library

[Robert Engels]

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 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 < 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 (which might clear up the above).  
>> - It might be nice to have a clamped set for a floating value out of range 
>> (rather than just return a NaN).
>> - Can't see a way to create from an integer (other than convert to float)
>> - Personally I'd rather not see a NewS() which can silently fail with no 
>> info, I'd prefer to rename NewSErr to Parse and remove NewS.
>> 
>> Other than that, pretty cool.
>> 
>> Cheers,
>> 
>> Jamie
>> 
>>> On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote:
>>> 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 more consistent if fixed.Cmp() would return NaN if 
>>> > any of it's operands are NaN. 
>>> > 
>>> > just my 2ct 
>>> > messju 
>>> > 
>>> > 
>>> 
> 
> -- 
> 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] [ANN] fixed point math library

[Robert Engels]

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 a lot of information. I find it makes the structures 
far more readable for a common type. 

Java’s BigInteger has this exact optimization when the value fits in a single 
word. Go could do this too so it is a fair performance comparison IMO. 

> On Nov 29, 2018, at 7:20 AM, Jan Mercl <0xj...@gmail.com> wrote:
> 
> 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 based on decimal.Decimal so I’m not the 
> > only one who thinks this
> 
> I don't think we are talking about the same thing here. Go idiom is to name 
> types such that they are not the same as the package qualifier (modulo case) 
> at the caller site. So the exported type should be 'Int', or 'Float' or 
> 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller site. 
> `var n fixed.Number` looks better to me, for example, than `var n 
> fixed.Fixed`. The later actually does not even communicate any hint what the 
> type could possibly be.
> 
> >> - A struct with a single field could be replaced by the field itself. 
> >> OTOH, it would enable coding errors by applying arithmetic operators to it 
> >> directly, so it's maybe justified in this case if that was the intention.
> > It was the intention. The Raw methods are there temporarily and will be 
> > removed for direct serialization via a Writer. 
> 
> Then it looks strange that to construct a Fixed from int64 one has to write 
> 'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) constructors and 
> setters, they are much more natural to use.
> 
> >> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
> >> 'SetFloat' etc.
> > Not possible. The caller doesn’t know the int64 value. Also, think of how 
> > that would look in a chained math statement. Horrible. 
> 
> It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that has 
> the _value_ of n, which of course has a different underlying int64 bit 
> pattern in the private Fixed field. The caller want New(42) meaning 42 and 
> does not casre about the internal, scaled value, that's just an 
> implementation detail and no business of the caller. BTW: Chained math 
> statements where the operators are written as function calls, above chains of 
> length 2 are not seen very often. Longer ones, in many cases, well, that's 
> what I'd call horrible.
> 
> >> I don't consider comparing performances of 64 bit integer arithmetic and 
> >> arbitrary sized arithmetic very useful.
> > Those are the alternatives to use when performing fixed place arithmetic. 
> > In fact decimal.Decimal uses big Int... so it is included for reference. 
> 
> The point being made here is fixed size fitting to a machine word on a 64 bit 
> CPU vs arbitrary sizes math libs implemented inevitably by multiple word 
> structs with pointers to backing storage and the necessary allocation 
> overhead. Apples to oranges. Not even in the same league.
> 
> -- 
> -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] Re: Rethink possibility to make circular imports

[Jamie Clarkson]

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 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 reason why 
> compilation of Go programs is much faster than other languages - makes it 
> quite difficult to authorize circular imports.
>
> I'm a young developer (not particularly in Go, I have only 2-3 years of 
> experience at total) so I'm looking forward to hearing your opinion guys, 
> but I think Go2 should allow importing packages circularly. I have no 
> practical reason to think that, except I've been tricking many times to 
> have a structure in my project with which I can at least build.
>
> 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. In Golang, the majority of the solutions we find are just 
> the translation of the logic behind our head into a language a computer can 
> understand - I emphasize this because it might not be true for all 
> languages (take Prolog for instance). Most of the time when you read a well 
> written program, you clearly get the underlying logic that led to this 
> particular solution, AND implementation of the solution.
>
> BUT - I think that there are some cases (and not just a few) when from a 
> logical point of view, the solution is clear, and we have to take the 
> structure of a project away from that logic, because circular imports are 
> not permitted. The human brain works in such a manner that circular imports 
> make sense, and I'll get even further, they are what makes the strongest 
> sense of all the solutions it can get to.
>
> That is my one and only point, but I personally think it is enough to at 
> least discuss the issue.
>
> I have many questions from this point :
> - Has there been any discussions about that for Go2 yet? If yes, could any 
> of you point me to them?
> - What do you think about what I just wrote? Is it coherent and relevant 
> or am I missing something?
> - Do you see any alternative to the problem I brought here other than 
> authorizing circular imports? 
> - Can anyone explain me exactly why circular imports are forbidden or is 
> this too complicated to hold in a mail?
>
> Thank you all for reading!
>

-- 
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] Rethink possibility to make circular imports

[Jan Mercl]

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.
Have you considered also
https://golang.org/ref/spec#Program_initialization_and_execution in your
thoughts?

Anyway, can you provide a small example of two packages, importing each
other, illustrating the advantage of circular imports? I'm not sure, but I
feel it can be proven that it's always possible to reorganize those two
packages to do not depend on circular imports. And transitively for N
packages. But I'm really just guessing.

-- 

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

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

[Jamie Clarkson]

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, 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 < 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 (which might clear up the above).  
>> - It might be nice to have a clamped set for a floating value out of 
>> range (rather than just return a NaN).
>> - Can't see a way to create from an integer (other than convert to float)
>> - Personally I'd rather not see a NewS() which can silently fail with no 
>> info, I'd prefer to rename NewSErr to Parse and remove NewS.
>>
>> Other than that, pretty cool.
>>
>> Cheers,
>>
>> Jamie
>>
>> On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote:
>>>
>>> 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 more consistent if fixed.Cmp() would return NaN if 
>>> any of it's operands are NaN. 
>>> > 
>>> > just my 2ct 
>>> > messju 
>>> > 
>>> > 
>>>
>>>

-- 
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] Rethink possibility to make circular imports

[Paul Jolly]

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/013_cyclic/README.md)
On Thu, 29 Nov 2018 at 13:22, 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 reason why 
> compilation of Go programs is much faster than other languages - makes it 
> quite difficult to authorize circular imports.
>
> I'm a young developer (not particularly in Go, I have only 2-3 years of 
> experience at total) so I'm looking forward to hearing your opinion guys, but 
> I think Go2 should allow importing packages circularly. I have no practical 
> reason to think that, except I've been tricking many times to have a 
> structure in my project with which I can at least build.
>
> 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. In Golang, the majority of the solutions we find are just the 
> translation of the logic behind our head into a language a computer can 
> understand - I emphasize this because it might not be true for all languages 
> (take Prolog for instance). Most of the time when you read a well written 
> program, you clearly get the underlying logic that led to this particular 
> solution, AND implementation of the solution.
>
> BUT - I think that there are some cases (and not just a few) when from a 
> logical point of view, the solution is clear, and we have to take the 
> structure of a project away from that logic, because circular imports are not 
> permitted. The human brain works in such a manner that circular imports make 
> sense, and I'll get even further, they are what makes the strongest sense of 
> all the solutions it can get to.
>
> That is my one and only point, but I personally think it is enough to at 
> least discuss the issue.
>
> I have many questions from this point :
> - Has there been any discussions about that for Go2 yet? If yes, could any of 
> you point me to them?
> - What do you think about what I just wrote? Is it coherent and relevant or 
> am I missing something?
> - Do you see any alternative to the problem I brought here other than 
> authorizing circular imports?
> - Can anyone explain me exactly why circular imports are forbidden or is this 
> too complicated to hold in a mail?
>
> Thank you all for reading!
>
> --
> 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] [ANN] fixed point math library

[Jamie Clarkson]

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 < 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 (which might clear up the above).  
> - It might be nice to have a clamped set for a floating value out of range 
> (rather than just return a NaN).
> - Can't see a way to create from an integer (other than convert to float)
> - Personally I'd rather not see a NewS() which can silently fail with no 
> info, I'd prefer to rename NewSErr to Parse and remove NewS.
>
> Other than that, pretty cool.
>
> Cheers,
>
> Jamie
>
> On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote:
>>
>> 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 more consistent if fixed.Cmp() would return NaN if 
>> any of it's operands are NaN. 
>> > 
>> > just my 2ct 
>> > messju 
>> > 
>> > 
>>
>>

-- 
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] [ANN] fixed point math library

[Jamie Clarkson]

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 (which might clear up the above).  
- It might be nice to have a clamped set for a floating value out of range 
(rather than just return a NaN).
- Can't see a way to create from an integer (other than convert to float)
- Personally I'd rather not see a NewS() which can silently fail with no 
info, I'd prefer to rename NewSErr to Parse and remove NewS.

Other than that, pretty cool.

Cheers,

Jamie

On Thursday, November 29, 2018 at 1:01:39 PM UTC, Robert Engels wrote:
>
> 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 more consistent if fixed.Cmp() would return NaN if 
> any of it's operands are NaN. 
> > 
> > just my 2ct 
> > messju 
> > 
> > 
>
>

-- 
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] [ANN] fixed point math library

[Jan Mercl]

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
 does and how it's
typically used.

The point is that the New should take the type that is expected to be used
most often. In your case it would be probably int64, less probably float64
or string.

-- 

-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] Rethink possibility to make circular imports

[Michel Levieux]

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 languages - makes it
quite difficult to authorize circular imports.

I'm a young developer (not particularly in Go, I have only 2-3 years of
experience at total) so I'm looking forward to hearing your opinion guys,
but I think Go2 should allow importing packages circularly. I have no
practical reason to think that, except I've been tricking many times to
have a structure in my project with which I can at least build.

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. In Golang, the majority of the solutions we find are just
the translation of the logic behind our head into a language a computer can
understand - I emphasize this because it might not be true for all
languages (take Prolog for instance). Most of the time when you read a well
written program, you clearly get the underlying logic that led to this
particular solution, AND implementation of the solution.

BUT - I think that there are some cases (and not just a few) when from a
logical point of view, the solution is clear, and we have to take the
structure of a project away from that logic, because circular imports are
not permitted. The human brain works in such a manner that circular imports
make sense, and I'll get even further, they are what makes the strongest
sense of all the solutions it can get to.

That is my one and only point, but I personally think it is enough to at
least discuss the issue.

I have many questions from this point :
- Has there been any discussions about that for Go2 yet? If yes, could any
of you point me to them?
- What do you think about what I just wrote? Is it coherent and relevant or
am I missing something?
- Do you see any alternative to the problem I brought here other than
authorizing circular imports?
- Can anyone explain me exactly why circular imports are forbidden or is
this too complicated to hold in a mail?

Thank you all for reading!

-- 
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] [ANN] fixed point math library

[Jan Mercl]

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 based on decimal.Decimal so I’m not the
only one who thinks this

I don't think we are talking about the same thing here. Go idiom is to name
types such that they are not the same as the package qualifier (modulo
case) at the caller site. So the exported type should be 'Int', or 'Float'
or 'Real' or 'Number', etc., not 'FIxed' to avoid 'fixed.Fixed' at caller
site. `var n fixed.Number` looks better to me, for example, than `var n
fixed.Fixed`. The later actually does not even communicate any hint what
the type could possibly be.

>> - A struct with a single field could be replaced by the field itself.
OTOH, it would enable coding errors by applying arithmetic operators to it
directly, so it's maybe justified in this case if that was the intention.
> It was the intention. The Raw methods are there temporarily and will be
removed for direct serialization via a Writer.

Then it looks strange that to construct a Fixed from int64 one has to write
'fixed.NewF(0).FromRaw(42)'. Check the big.{Int,Float,Rat) constructors and
setters, they are much more natural to use.

>> - I'd prefer a single constructor 'New(int64)' and methods 'SetString',
'SetFloat' etc.
> Not possible. The caller doesn’t know the int64 value. Also, think of how
that would look in a chained math statement. Horrible.

It _is_ possible. You've misunderstood. New(n int64) returns a Fixed that
has the _value_ of n, which of course has a different underlying int64 bit
pattern in the private Fixed field. The caller want New(42) meaning 42 and
does not casre about the internal, scaled value, that's just an
implementation detail and no business of the caller. BTW: Chained math
statements where the operators are written as function calls, above chains
of length 2 are not seen very often. Longer ones, in many cases, well,
that's what I'd call horrible.

>> I don't consider comparing performances of 64 bit integer arithmetic and
arbitrary sized arithmetic very useful.
> Those are the alternatives to use when performing fixed place arithmetic.
In fact decimal.Decimal uses big Int... so it is included for reference.

The point being made here is fixed size fitting to a machine word on a 64
bit CPU vs arbitrary sizes math libs implemented inevitably by multiple
word structs with pointers to backing storage and the necessary allocation
overhead. Apples to oranges. Not even in the same league.

-- 

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

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

[Robert Engels]

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.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 on decimal.Decimal so I’m not the only 
> one who thinks this
>> - A struct with a single field could be replaced by the field itself. OTOH, 
>> it would enable coding errors by applying arithmetic operators to it 
>> directly, so it's maybe justified in this case if that was the intention.
>> 
> It was the intention. The Raw methods are there temporarily and will be 
> removed for direct serialization  via a Writer. 
>> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
>> 'SetFloat' etc.
>> 
> Not possible. The caller doesn’t know the int64 value. Also, think of how 
> that would look in a chained math statement. Horrible. 
>> > The benchmarks: (Decimal is the shopspring library, big Int/Float are the 
>> > stdlib)
>> 
>> I don't consider comparing performances of 64 bit integer arithmetic and 
>> arbitrary sized arithmetic very useful.
>> 
> Those are the alternatives to use when performing fixed place arithmetic. In 
> fact decimal.Decimal uses big Int... so it is included for reference. 
>> -- 
>> -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.

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

[Robert Engels]

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 more consistent if fixed.Cmp() would return NaN if any of 
> it's operands are NaN.
> 
> just my 2ct
> messju
> 
> 
>> On Thu, Nov 29, 2018 at 12:47:05AM -0600, robert engels wrote:
>>   For those interesting in financial apps, I have released ‘fixed'
>>   at [1]https://github.com/robaho/fixed a high performance fixed-point math
>>   library primarily designed for to work with currencies.
>>   The benchmarks: (Decimal is the shopspring library, big Int/Float are the
>>   stdlib)
>> 
>> BenchmarkAddFixed-8 20   0.83 ns/op  
>>   0 B/op  0 allocs/op
>> BenchmarkAddDecimal-8300   457 ns/op 
>> 400 B/op 10 allocs/op
>> BenchmarkAddBigInt-81   19.2 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkAddBigFloat-8  2000   110 ns/op 
>>  48 B/op  1 allocs/op
>> BenchmarkMulFixed-8 1   12.4 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkMulDecimal-8   200094.2 ns/op   
>>  80 B/op  2 allocs/op
>> BenchmarkMulBigInt-81   22.0 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkMulBigFloat-8  300050.0 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkDivFixed-8 1   19.3 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkDivDecimal-8100  1152 ns/op 
>> 928 B/op 22 allocs/op
>> BenchmarkDivBigInt-8200068.4 ns/op   
>>  48 B/op  1 allocs/op
>> BenchmarkDivBigFloat-8  1000   151 ns/op 
>>  64 B/op  2 allocs/op
>> BenchmarkCmpFixed-8 20   0.28 ns/op  
>>   0 B/op  0 allocs/op
>> BenchmarkCmpDecimal-8   1   10.8 ns/op   
>>   0 B/op  0 allocs/op
>> BenchmarkCmpBigInt-828.37 ns/op  
>>   0 B/op  0 allocs/op
>> BenchmarkCmpBigFloat-8  27.74 ns/op  
>>   0 B/op  0 allocs/op
>> BenchmarkStringFixed-8  200099.0 ns/op   
>>  16 B/op  1 allocs/op
>> BenchmarkStringDecimal-8 500   326 ns/op 
>> 144 B/op  5 allocs/op
>> BenchmarkStringBigInt-8 1000   209 ns/op 
>>  80 B/op  3 allocs/op
>> BenchmarkStringBigFloat-8300   571 ns/op 
>> 272 B/op  8 allocs/op
>> 
>>   --
>>   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 [2]golang-nuts+unsubscr...@googlegroups.com.
>>   For more options, visit [3]https://groups.google.com/d/optout.
>> 
>> References
>> 
>>   Visible links
>>   1. https://github.com/robaho/fixed
>>   2. mailto:golang-nuts+unsubscr...@googlegroups.com
>>   3. 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.

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

[Robert Engels]

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 on decimal.Decimal so I’m not the only one 
who thinks this
> - A struct with a single field could be replaced by the field itself. OTOH, 
> it would enable coding errors by applying arithmetic operators to it 
> directly, so it's maybe justified in this case if that was the intention.
> 
It was the intention. The Raw methods are there temporarily and will be removed 
for direct serialization  via a Writer. 
> - I'd prefer a single constructor 'New(int64)' and methods 'SetString', 
> 'SetFloat' etc.
> 
Not possible. The caller doesn’t know the int64 value. Also, think of how that 
would look in a chained math statement. Horrible. 
> > The benchmarks: (Decimal is the shopspring library, big Int/Float are the 
> > stdlib)
> 
> I don't consider comparing performances of 64 bit integer arithmetic and 
> arbitrary sized arithmetic very useful.
> 
Those are the alternatives to use when performing fixed place arithmetic. In 
fact decimal.Decimal uses big Int... so it is included for reference. 
> -- 
> -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] Re: Go += Package Versioning

[thepudds1460]

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 making something 
up):

  "I have module 'foo' located in a remote git server, and the latest 
commit is tagged v1.2.3. I just did a fresh git clone to 
/tmp/scratchpad/foo, and now I want to do ... but instead I am seeing ..."

Also, it might be good to start a new thread with a new subject, which will 
make it easier for people to find your question. (This thread has many 
people on it, and was primarily about reaction to the initial versioned 
modules blog series from back in February).

Best,
--thepudds

On Tuesday, November 27, 2018 at 9:22:17 AM UTC-5, Göcs Jëss wrote:
>
> Is it possible to restrain of having 2 files in my workspace/project while 
> keeping 2 versions of the same repo?
>
> On Wednesday, February 21, 2018 at 1:20:54 AM UTC+8, 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 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] [ANN] fixed point math library

[messju mohr]

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, 2018 at 12:47:05AM -0600, robert engels wrote:
>For those interesting in financial apps, I have released ‘fixed'
>at [1]https://github.com/robaho/fixed a high performance fixed-point math
>library primarily designed for to work with currencies.
>The benchmarks: (Decimal is the shopspring library, big Int/Float are the
>stdlib)
> 
>  BenchmarkAddFixed-8 20   0.83 ns/op  
>   0 B/op  0 allocs/op
>  BenchmarkAddDecimal-8300   457 ns/op 
> 400 B/op 10 allocs/op
>  BenchmarkAddBigInt-81   19.2 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkAddBigFloat-8  2000   110 ns/op 
>  48 B/op  1 allocs/op
>  BenchmarkMulFixed-8 1   12.4 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkMulDecimal-8   200094.2 ns/op   
>  80 B/op  2 allocs/op
>  BenchmarkMulBigInt-81   22.0 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkMulBigFloat-8  300050.0 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkDivFixed-8 1   19.3 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkDivDecimal-8100  1152 ns/op 
> 928 B/op 22 allocs/op
>  BenchmarkDivBigInt-8200068.4 ns/op   
>  48 B/op  1 allocs/op
>  BenchmarkDivBigFloat-8  1000   151 ns/op 
>  64 B/op  2 allocs/op
>  BenchmarkCmpFixed-8 20   0.28 ns/op  
>   0 B/op  0 allocs/op
>  BenchmarkCmpDecimal-8   1   10.8 ns/op   
>   0 B/op  0 allocs/op
>  BenchmarkCmpBigInt-828.37 ns/op  
>   0 B/op  0 allocs/op
>  BenchmarkCmpBigFloat-8  27.74 ns/op  
>   0 B/op  0 allocs/op
>  BenchmarkStringFixed-8  200099.0 ns/op   
>  16 B/op  1 allocs/op
>  BenchmarkStringDecimal-8 500   326 ns/op 
> 144 B/op  5 allocs/op
>  BenchmarkStringBigInt-8 1000   209 ns/op 
>  80 B/op  3 allocs/op
>  BenchmarkStringBigFloat-8300   571 ns/op 
> 272 B/op  8 allocs/op
> 
>--
>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 [2]golang-nuts+unsubscr...@googlegroups.com.
>For more options, visit [3]https://groups.google.com/d/optout.
> 
> References
> 
>Visible links
>1. https://github.com/robaho/fixed
>2. mailto:golang-nuts+unsubscr...@googlegroups.com
>3. 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] [ANN] fixed point math library

[Jan Mercl]

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 Javaism. Go code usually tries
to avoid such stutter: 'sort.Interface', 'big.Int' etc.

- A struct with a single field could be replaced by the field itself. OTOH,
it would enable coding errors by applying arithmetic operators to it
directly, so it's maybe justified in this case if that was the intention.

- I'd prefer a single constructor 'New(int64)' and methods 'SetString',
'SetFloat' etc.

> The benchmarks: (Decimal is the shopspring library, big Int/Float are the
stdlib)

I don't consider comparing performances of 64 bit integer arithmetic and
arbitrary sized arithmetic very useful.

-- 

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