Just wrapping a write with a mutex is not enough; you have to wrap all the
reads as well. In this case that's not possible because there are reads of
time.Local all over the place. Anyway, as has been said, time.Local should
never be written to in user code.
On Fri, Nov 30, 2018 at 7:46 AM Agniva
The main reason for the prohibition against circular imports is that you
have to add overhead in the processing to determine when to stop. From an
architectural perspective it also makes sense - most often if you stop for
a moment and think about what you are building, usually if you are
m!
Yes, using pure integer values for currency is generally the best way to
deal with it. The Bitcoin standard is that 1 BTC = 10,000,000 'satoshis'.
Many rightly point out that this is a stupidly small precision, but for the
time being is ok. I personally would expand this, and just use
I agree about the stutter naming. The name should at least specify the
bitwidth of the integral and fractional parts, to follow the pattern of the
fixed width types already existing. Fixed is easy enough to infer that it
is a fixed point type, by the package. You could name the types based on
C/C++ way of working with these things requires specifying the start and
end point using pointer arithmetic, which is pretty cumbersome considering
how often it is needed. I think what Ian said is probably the most complete
way to deal with it.
But probably you can also do it using the unsafe
The implicit type inferred from an integer is always 'int'. This is a 64
bit signed integer and thus has a maximum width of 63 bits. In Go, you
should not assume sign or width of an untyped implicit conversion, as the
'int' and 'uint' types default to the size of processor registers, which
are
Another way of saying it: "Go has Schrödinger's Constants." This captures
the notion that a constant is of every type until you use it, whereupon it
settles to the appropriate type based on the expectations of the use site.
On Wed, Dec 5, 2018 at 2:55 PM Rob Pike wrote:
> Most of this is
Most of this is explained in blog.golang.org/constants.
-rob
On Thu, Dec 6, 2018 at 4:04 AM Andy Balholm wrote:
> When an untyped integer constant is converted to a typed value, it always
> becomes int. I suppose the rules could be made more complicated to handle
> values that won’t fit in an
I always go with the approach that uses the equivalent of the "Transact()"
method.
On top of that, rather than use a generic *sql.Tx parameter to the "txFunc"
function, I pass an interface that is specific to the operations of the
database layer for my application.
This pattern has three
On Wed, Dec 5, 2018 at 12:16 PM Burak Serdar wrote:
> On Wed, Dec 5, 2018 at 10:12 AM Mark Volkmann
> wrote:
> >
> > I can get a reflect.Type for a variable with the following: myType :=
> reflect.TypeOf(myVariable)
> >
> > How can I get a reflect.Type for a type I have defined?
> > For
On Wed, Dec 5, 2018 at 10:12 AM Mark Volkmann wrote:
>
> I can get a reflect.Type for a variable with the following: myType :=
> reflect.TypeOf(myVariable)
>
> How can I get a reflect.Type for a type I have defined?
> For example: type MyThing struct { …bunch of fields… }
> I need to get a
I can get a reflect.Type for a variable with the following: myType :=
reflect.TypeOf(myVariable)
How can I get a reflect.Type for a type I have defined?
For example: type MyThing struct { …bunch of fields… }
I need to get a reflect.Type that describes the MyThing type.
The best I can find is
When an untyped integer constant is converted to a typed value, it always
becomes int. I suppose the rules could be made more complicated to handle
values that won’t fit in an int. But what if the value is too big to fit in a
uint64? Should it be a float64 then?
Andy
> On Dec 5, 2018, at 8:54
On Wednesday, December 5, 2018 at 11:55:25 AM UTC-5, Michel Levieux wrote:
>
> Well the only thing I do in the main is :
>
> fmt.Println(v)
>>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
>
>
Nope. You're passing an untyped constant
On Wed, Dec 5, 2018 at 9:55 AM Michel Levieux wrote:
>
> Well the only thing I do in the main is :
>
>> fmt.Println(v)
>
>
> Shouldn't the compiler statically type v to uint64?
> I don't get the need to force type of v to uint64?
v is an untyped constant. When passed to Println, it is an int.
Well the only thing I do in the main is :
fmt.Println(v)
>
Shouldn't the compiler statically type v to uint64?
I don't get the need to force type of v to uint64?
Le mer. 5 déc. 2018 à 17:45, Andy Balholm a écrit :
> Apparently in your code the value is being assigned to an int. But it’s
> too
Apparently in your code the value is being assigned to an int. But it’s too
large for an int; it needs a uint64 to hold it.
Andy
> On Dec 5, 2018, at 8:35 AM, Michel Levieux wrote:
>
> Hi guys,
>
> With a colleague of mine, we've run into a strange issue today. When we look
> at package
On Wednesday, December 5, 2018 at 11:36:32 AM UTC-5, Michel Levieux wrote:
>
> which I assume works pretty well. But if I do the same in a test main and
> try to 'go run' it, with this line :
>
> const v = 1 << 64 - 1
>>
>>
> I get the following error :
>
> ./testmain.go:8:13: constant
Hi guys,
With a colleague of mine, we've run into a strange issue today. When we
look at package math, in const.go, we can see this line :
MaxUint64 = 1<<64 - 1
>
>
which I assume works pretty well. But if I do the same in a test main and
try to 'go run' it, with this line :
const v = 1 << 64 -
hi,
I've been seeing the following odd behavior in the middle of a larger
project where glog.V(2).Infof outputs something, while glog.V(2) evaluates
to false in the line that just follows.
I'm wondering if it has something to do with some optimization (inlining of
the compiler messing up with
20 matches
Mail list logo
