Re: [go-nuts] Request for advice: Developing for Android

[Nigel Tao]

On Thu, Sep 22, 2016 at 12:33 AM, Peter Kleiweg  wrote:
> How about Go Mobile? Is that useful as a starting point, or should I try to
> get to know the system first using Android Studio? What are the capabilities
> of Go Mobile? Can it do all the stuff a native app can do, system calls,
> events, graphics, sound, sensors, communications, all that stuff? Can I use
> all the Java libraries for Android that I assume must be available out
> there?

I don't know about other approaches, but Go Mobile is still a work in
progress. If it works for you, that's great, but depending on how
complicated your app is, there may be missing features, libraries or
documentation that we haven't written yet.

-- 
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] Crypto/rsa : OAEP documentation can lead to misunderstanding regarding max message length, is it a bug?

[Nigel Tao]

On Wed, Sep 21, 2016 at 1:41 AM, AnomalRoil  wrote:
> So here am I: should I open an issue for a trivial sign mistake in a
> sentence in the documentation?

Opening an issue would have been fine. In this case, though, I just
sent the trivial change out for review:
https://go-review.googlesource.com/29496

Thanks for the note.

-- 
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] truncate float32 to lesser precision (22 bit mantissa)

[Michael Jones]

Good point. I missed that. Also, I did not mean “unsolvabe” just not solvable 
using slightly a different precision.

Common solutions:

Remove the divides by multiplying them out. Then it just works (at least in FP 
where integer precision is not such an issue as in graphics hardware)

Avoid the clipping/division tests by doing comparisons alone.

Deal with relative primality by direct means. I think I have a patent (SGI 
patent / OpenGL) about dealing with this as part of the reference polygon 
extension. There was an elaboration that resolved the “cracks at T-vertices” 
problem too, but that died with SGI.

-Original Message-
From:  on behalf of Nigel Tao 
Date: Wednesday, September 21, 2016 at 4:26 PM
To: Xio Fen 
Cc: golang-nuts 
Subject: Re: [go-nuts] truncate float32 to lesser precision (22 bit mantissa)

On Sun, Sep 18, 2016 at 1:57 PM,   wrote:
> It looked like I would have to use pkg unsafe

BTW, you don't have to use package unsafe. Use package math's
Float32bits and Float32frombits functions.

-- 
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: localfile

[maturana via golang-nuts]

I wonder if go's google.Init() ends up missing initializers that are in the 
C side of cgo.


On Wednesday, September 21, 2016 at 3:44:20 PM UTC-7, matu...@google.com 
wrote:
>
> I have a go binary that calls C code (with cgo). It is a little test, and 
> main calls google.Init() and calls some C function that ends up opening a 
> local file.
>
> I get an error like:
> WARNING: Logging before InitGoogle() is written to STDERR
> E0921 15:16:46.570978  184662 extractor.cc:102] 
> generic::failed_precondition: FileFactory 'local_file' not found. The 
> application has not been linked against the '//file/localfile' library or 
> InitGoogle() has not been called yet.
>
> The C library I am linking against is compiled with deps = [ ... , 
> "//file/localfile",...].
>
> Is there something obvious I am missing? Is there a go equivalent of 
> localfile to directly link to my binary?
>
>

-- 
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] truncate float32 to lesser precision (22 bit mantissa)

[Nigel Tao]

On Sun, Sep 18, 2016 at 1:57 PM,   wrote:
> It looked like I would have to use pkg unsafe

BTW, you don't have to use package unsafe. Use package math's
Float32bits and Float32frombits functions.

-- 
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] ARM Cortex-R52 real time chip announced today

[Michael Hudson-Doyle]

On 22 September 2016 at 05:54, Ian Lance Taylor  wrote:

> On Wed, Sep 21, 2016 at 7:16 AM, Ged Wed  wrote:
> >
> > Today ARM announced a new real time chip for cars.
> >
> > http://www.anandtech.com/show/10690/arm-announces-the-
> cortexr52-cpu-deterministic-safe-for-adas-more
> >
> > https://github.com/golang/go/wiki/GoArm
> >
> > I am curious how hard it would be for golang to target this ??
> > Not that i would be anytime soon, but its seems like it would be great
> for
> > drones, robotics, and hardware that needs to be deterministic in the
> time it
> > takes to complete tasks.
>
> As far as I can see, the Go toolchain should be able to generate code
> today that will run on this processor.


I think the code might be OK (not sure how much the ISA for userland
differs between -A and -R) but I think getting the runtime to work on a
system without an MMU might be an adventure. I'm hardly an expert in such
things though!

Cheers,
mwh

-- 
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] localfile

[maturana via golang-nuts]

I have a go binary that calls C code (with cgo). It is a little test, and 
main calls google.Init() and calls some C function that ends up opening a 
local file.

I get an error like:
WARNING: Logging before InitGoogle() is written to STDERR
E0921 15:16:46.570978  184662 extractor.cc:102] 
generic::failed_precondition: FileFactory 'local_file' not found. The 
application has not been linked against the '//file/localfile' library or 
InitGoogle() has not been called yet.

The C library I am linking against is compiled with deps = [ ... , 
"//file/localfile",...].

Is there something obvious I am missing? Is there a go equivalent of 
localfile to directly link to my binary?

-- 
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: Image Processing - Removing Color

[dbeasy]

This was a great find, I am doing the same now in Windows. I've had to 
modify it a bit, I imagine weather.gov has changed the image somewhat since 
the original post in 2013. I've had to remove some more of the light blue 
colors and then one more pass to get rid of the light grey radar "noise".

I'm also grabbing the pre-made gif loop, e.g. 
http://radar.weather.gov/Conus/Loop/uppermissvly_loop.gif

I put all the commands for the main colors into one convert command. Since 
I was grabbing the regional loop with the state lines I couldn't use the 
"blur".
Also, since I'm on Windows I had to make sure to not call the other 
"convert" (which is for NTFS filesystem conversion).

echo Processing weather gif radar_uppermissvly_loop.gif removing the blue 
colors from the radar...
set "imconvert=C:\Program Files (x86)\ImageMagick-6.9.2-Q8\convert.exe" 

REM the carets are for multi-lines in "DOS"
"%imconvert%" -channel rgba -alpha set -fuzz 25% -fill "#FF" -opaque 
"#3030CE" ^
-opaque "#04e9e7" -opaque "#019ff4" -opaque "#0300f4" -opaque "#0248F4" ^
-opaque "#69F2F0" radar_uppermissvly_loop.gif radar_grey.gif

echo Processing weather gif radar removing the greyish radar...
"%imconvert%"  -channel rgba -alpha set -fuzz 12% -fill "#FF" -opaque 
"#E2E2E2"  radar_grey.gif radar_clean.gif

echo Trimming down the radar to a more localized region...
%imconvert%"  -crop 260x280+277+56 -trim +repage  radar_clean.gif 
radar_cropped.gif


Thanks, posting in case it helps someone else who's stuck on the blue and 
grey colors (and is using the command line version in Windows or Linux).



-- 
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: truncate float32 to lesser precision (22 bit mantissa)

[xiiophen]

Thanks for those links - I started using a something similar to what is 
described as Smit's algorithm (Slab method) in the Amy Williams paper. My 
code us subtly different to that usually given because I check the "back 
face" intersection first -for an early terminate ; this basically involves 
swapping x_plane_min and x_plane_max early if v.X<0 .. then looking 
explicitly for the back plane intersection points first..  as well as being 
slightly more verbose it seems to have the side effect of avoiding the 
divide by -0 problem described in the paper. (misses ray parallel to plane, 
catches adjoining edges) I think my version is sub-optimal but not a 
priority right now.

I've noticed that the divides in all the "slab" methods could be multiplied 
out - this which inverts the boundary condition if the divisor was 
negative, but can be caught using 

if (multiplied_x < undivided_boundary_value) ==(divisor>0)


instead of the vanilla.

if (x < boundary_value) 


not only does this avoid any division (hurray!), but also reduces the 
cumulative float errors - the number of operations on both sides of the 
condition of is roughly equal, rather than being unbalanced with most on 
one side in the un-premultuplied version.. It's a little more complicated, 
but divides are, afaik, still slow even on modern hardware, which is 
something I suspect may be a bottleneck within the function.. I need to 
bench this.. It may mitigate but doesn't solve the float precision problem.

The second link is a nice optimisation for simd too. Optimisation for this 
function isn't a big priority for me because I'm primarily using it it get 
the intersection point for a bounding volume for a "3d texture" (or 
'non-sparse voxel array' in other words) - my main routine steps through 
the voxel grid front to back using a different algorithm.

PBRT looks good - wasn't aware of it - found the pre-publication chapter 
section 3.9.2 "CONSERVATIVE RAY–BOUNDS INTERSECTIONS" - though I didn't 
proof read it it looks like it covers using calculated expected errors 
(deltas) well.

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

Re: [go-nuts] time.Time vs time.Instant

[Jakob Borg]

UTC, Coordinated Universal Time, is not really an arbitrary time zone. It's
the time scale underlying almost all time measurements on Earth (excepting
some specific use cases, typically in astronomy) and from which all time
zones are derived. As such, I don't think it implies a location (other than
"on Earth", possibly).

Having a defined time scale is necessary when talking about a point in time
as a duration relative to another well defined reference point. I'm not
aware of any other common way of denoting points in time other than as a
duration from a reference point, so I'm not sure what's the significance of
the difference between a point in time and a duration? Perhaps it's
philosophical. :)

//jb

ons 21 sep. 2016 kl 21:49 skrev Axel Wagner :

> I am aware. I don't understand how that contradicts my point that they
> have an implied location (or rather *Location, namely time.UTC).
>
> I am aware, that you could choose an arbitrary *Location (because that's
> what time.UTC is. Just one, arbitrary, timezone) and create a special
> in-memory Representation for times relative to that *Location. It still
> doesn't seem worthwile to me and likely to cause more trouble than it has
> advantages.
>
> On Wed, Sep 21, 2016 at 8:55 PM, Jakob Borg  wrote:
>
>> The sec and nsec fields in a time.Time are relative to the Unix epoch and
>> so denote a point in time by themselves. The location is merely for
>> presentation.
>>
>> ons 21 sep. 2016 kl 20:35 skrev 'Axel Wagner' via golang-nuts <
>> golang-nuts@googlegroups.com>:
>>
>>> Your Instant is not an Instant, it's a duration. For a duration to
>>> demarkate an Instant, you'd actually need a reference point (a zero). And
>>> that'll pretty much certainly be given relative to a location. So even your
>>> Instant still has a location, it's just implied (probably to be UTC).
>>>
>>> Personally, I *really* like how the time.Time design doesn't let you
>>> forget that what you have is inherently a clock and the instant in time
>>> that is marked by that clock depends on it's location. Too much software
>>> out there is coming from exactly your PoV: Dealing with unix-timestamps in
>>> the belief that they are sufficient to mark a point in time. But then,
>>> during transmission, storage, bugs or accidental reinterpretation, you
>>> loose that information or add it where it doesn't belong and that's how
>>> timezone-bugs are born.
>>>
>>> By making it impossible to separate the two, go forces you to consider
>>> that all the time. Which is, in my opinion, a good thing. That you get for
>>> very little overhead.
>>>
>>> On Wed, Sep 21, 2016 at 8:22 PM, Paul Jolly  wrote:
>>>
 Please can someone can enlighten me or point me towards relevant
 docs/other regarding the design decisions behind time.Time?

 Specifically why the concept of an instant in time, referenced many
 times throughout the time docs, was not encoded as a type itself:

 type Instant struct {
 sec int64
 nsec int32
 }

 and time.Time then reference time.Instant in some way:

 type Time struct {
 instant Instant
 loc *Location
 }

 The obvious difference being that an instant in time has no location.
 If I'm only interested in instants in time (i.e. my code doesn't do
 anything presentational) then the location is redundant.

 Many thanks


 --
 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] time.Time vs time.Instant

[Paul Jolly]

>
> > The sec and nsec fields in a time.Time are relative to the Unix epoch 
> and so 
> > denote a point in time by themselves. The location is merely for 
> > presentation. 
>
> Pedantically, they are not relative to the Unix epoch.  They are 
> relative to January 1, year 1, 00:00:00.0 UTC. 
>

Thanks everyone for the various responses. 

I suspect my inclusion of a potential definition of the struct behind the 
type time.Instant has confused what I was trying to get at.

All I had intended with time.Instant is that a value of type time.Instant 
should represent an instant in time with a specific precision (time.Time 
defines this precision as nanoseconds), which I believe only requires us to 
define time (and the precision), a definition we get from UTC (and second). *A 
corollary of this point, I don't understand why UTC is considered a 
location... but maybe that's a separate point.*

time.Instant would likely only define Unix() and UnixNano() methods. And 
this deals with your point about "correctness" Axel, because you wouldn't 
be able to do anything presentational with a value of type time.Instant, 
instead you'd rely on:

func FromInstant(inst Instant) Time

at which point you're "safe" again. But your point about trying to avoid 
mistakes when handling time, zones etc is well received; that is dealt with 
elsewhere in my case.

The implementation of time.Instant is of course arbitrary... although I 
would imagine it's likely to follow the approach currently used by 
time.Time, hence why I included the struct definition.


Paul

-- 
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] time.Time vs time.Instant

['Axel Wagner' via golang-nuts]

I am aware. I don't understand how that contradicts my point that they have
an implied location (or rather *Location, namely time.UTC).

I am aware, that you could choose an arbitrary *Location (because that's
what time.UTC is. Just one, arbitrary, timezone) and create a special
in-memory Representation for times relative to that *Location. It still
doesn't seem worthwile to me and likely to cause more trouble than it has
advantages.

On Wed, Sep 21, 2016 at 8:55 PM, Jakob Borg  wrote:

> The sec and nsec fields in a time.Time are relative to the Unix epoch and
> so denote a point in time by themselves. The location is merely for
> presentation.
>
> ons 21 sep. 2016 kl 20:35 skrev 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> Your Instant is not an Instant, it's a duration. For a duration to
>> demarkate an Instant, you'd actually need a reference point (a zero). And
>> that'll pretty much certainly be given relative to a location. So even your
>> Instant still has a location, it's just implied (probably to be UTC).
>>
>> Personally, I *really* like how the time.Time design doesn't let you
>> forget that what you have is inherently a clock and the instant in time
>> that is marked by that clock depends on it's location. Too much software
>> out there is coming from exactly your PoV: Dealing with unix-timestamps in
>> the belief that they are sufficient to mark a point in time. But then,
>> during transmission, storage, bugs or accidental reinterpretation, you
>> loose that information or add it where it doesn't belong and that's how
>> timezone-bugs are born.
>>
>> By making it impossible to separate the two, go forces you to consider
>> that all the time. Which is, in my opinion, a good thing. That you get for
>> very little overhead.
>>
>> On Wed, Sep 21, 2016 at 8:22 PM, Paul Jolly  wrote:
>>
>>> Please can someone can enlighten me or point me towards relevant
>>> docs/other regarding the design decisions behind time.Time?
>>>
>>> Specifically why the concept of an instant in time, referenced many
>>> times throughout the time docs, was not encoded as a type itself:
>>>
>>> type Instant struct {
>>> sec int64
>>> nsec int32
>>> }
>>>
>>> and time.Time then reference time.Instant in some way:
>>>
>>> type Time struct {
>>> instant Instant
>>> loc *Location
>>> }
>>>
>>> The obvious difference being that an instant in time has no location. If
>>> I'm only interested in instants in time (i.e. my code doesn't do anything
>>> presentational) then the location is redundant.
>>>
>>> Many thanks
>>>
>>>
>>> --
>>> 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] time.Time vs time.Instant

[Sam Whited]

On Wed, Sep 21, 2016 at 1:55 PM, Jakob Borg  wrote:
> The sec and nsec fields in a time.Time are relative to the Unix epoch and so
> denote a point in time by themselves.

Right, making your "instant" a duration with an implicit starting
time, and a time that has a timezone at that (aka, just a duration
that we've made some arbitrary assumptions about, which you could do
with the existing duration implementation).

—Sam


-- 
Sam Whited
pub 4096R/54083AE104EA7AD3

-- 
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] time.Time vs time.Instant

[Jakob Borg]

Ah, indeed. No pedantry required to appreciate the difference, it's almost
two thousand years after all. :) Sorry for the confusion.

//jb

ons 21 sep. 2016 kl 21:40 skrev Ian Lance Taylor :

> On Wed, Sep 21, 2016 at 11:55 AM, Jakob Borg  wrote:
> > The sec and nsec fields in a time.Time are relative to the Unix epoch
> and so
> > denote a point in time by themselves. The location is merely for
> > presentation.
>
> Pedantically, they are not relative to the Unix epoch.  They are
> relative to January 1, year 1, 00:00:00.0 UTC.
>
> 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] time.Time vs time.Instant

[Ian Lance Taylor]

On Wed, Sep 21, 2016 at 11:55 AM, Jakob Borg  wrote:
> The sec and nsec fields in a time.Time are relative to the Unix epoch and so
> denote a point in time by themselves. The location is merely for
> presentation.

Pedantically, they are not relative to the Unix epoch.  They are
relative to January 1, year 1, 00:00:00.0 UTC.

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] Re: truncate float32 to lesser precision (22 bit mantissa)

[jnc7919]

Michael is of course correct about floating point but it is possible to 
robustly handle cases like this. I'm not sure on your exact goals but 
you've not already seen there are several papers about robust ray-box 
intersection e.g. An Efficient and Robust Ray-Box Intersection Algorithm by 
Amy Williams et al., and 
https://tavianator.com/fast-branchless-raybounding-box-intersections/ has 
some good information about handling precision, infs and NaNs (Vermeer LT 
implements some of this in Go but mainly in asm unfortunately so it's not 
much use for borrowing :). Also the chapter in PBRT about floating point 
error handling is very handy for understanding the issues (there is a 
preprint PDF floating).

Cheers,

Jamie


On Wednesday, September 21, 2016 at 2:11:42 PM UTC+1, xiio...@gmail.com 
wrote:
>
> Yes thanks. 
>
> I decided on catching the missed ON (edge/corner) case at the end of the 
> function with an extra if statement when the numerical work returns 
> EXITS_BOX=true, ENTERS_BOX=false - then I do a relatively simple check for 
> the 'ray' outside the box - if Ray.Origin was outside and EXITS_BOX=true 
> then ENTERS_BOX should have been true too - so a contradiction here lets be 
> catch the miss. (There's another reverse case I don't need to catch).
>
> if s.X < xmin || s.Y < ymin || s.Z < zmin || s.X > xmax || s.Y > ymax || s.Z 
> > zmax {
>   //origin is outside box *but* ray intersected with back plane
>   //  so ray should have intersected with front plane
>   //  probable rounding error at edge/corner intersection
>   return true, true, back_n, back_n, back_p, back_p
>   }
>
>
> The float conversion is a little fiddly because of that implicit bit in 
> the mantissa .. if the compiler is working well the catch is only 6 
> compares, and the rounding conversion adds a bit-ops AND, OR and SHIFT.. so 
> I doubt the unsafe will make a huge difference in time.. though I think it 
> could be preferable.
>
>
>
> .. Mainly relieved to here someone say this problem is unavoidable with 
> floats .. I can stop looking for maths work arounds.. Thanks again.
>

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

Re: [go-nuts] time.Time vs time.Instant

[Jakob Borg]

The sec and nsec fields in a time.Time are relative to the Unix epoch and
so denote a point in time by themselves. The location is merely for
presentation.

ons 21 sep. 2016 kl 20:35 skrev 'Axel Wagner' via golang-nuts <
golang-nuts@googlegroups.com>:

> Your Instant is not an Instant, it's a duration. For a duration to
> demarkate an Instant, you'd actually need a reference point (a zero). And
> that'll pretty much certainly be given relative to a location. So even your
> Instant still has a location, it's just implied (probably to be UTC).
>
> Personally, I *really* like how the time.Time design doesn't let you
> forget that what you have is inherently a clock and the instant in time
> that is marked by that clock depends on it's location. Too much software
> out there is coming from exactly your PoV: Dealing with unix-timestamps in
> the belief that they are sufficient to mark a point in time. But then,
> during transmission, storage, bugs or accidental reinterpretation, you
> loose that information or add it where it doesn't belong and that's how
> timezone-bugs are born.
>
> By making it impossible to separate the two, go forces you to consider
> that all the time. Which is, in my opinion, a good thing. That you get for
> very little overhead.
>
> On Wed, Sep 21, 2016 at 8:22 PM, Paul Jolly  wrote:
>
>> Please can someone can enlighten me or point me towards relevant
>> docs/other regarding the design decisions behind time.Time?
>>
>> Specifically why the concept of an instant in time, referenced many times
>> throughout the time docs, was not encoded as a type itself:
>>
>> type Instant struct {
>> sec int64
>> nsec int32
>> }
>>
>> and time.Time then reference time.Instant in some way:
>>
>> type Time struct {
>> instant Instant
>> loc *Location
>> }
>>
>> The obvious difference being that an instant in time has no location. If
>> I'm only interested in instants in time (i.e. my code doesn't do anything
>> presentational) then the location is redundant.
>>
>> Many thanks
>>
>>
>> --
>> 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] time.Time vs time.Instant

['Axel Wagner' via golang-nuts]

Your Instant is not an Instant, it's a duration. For a duration to
demarkate an Instant, you'd actually need a reference point (a zero). And
that'll pretty much certainly be given relative to a location. So even your
Instant still has a location, it's just implied (probably to be UTC).

Personally, I *really* like how the time.Time design doesn't let you forget
that what you have is inherently a clock and the instant in time that is
marked by that clock depends on it's location. Too much software out there
is coming from exactly your PoV: Dealing with unix-timestamps in the belief
that they are sufficient to mark a point in time. But then, during
transmission, storage, bugs or accidental reinterpretation, you loose that
information or add it where it doesn't belong and that's how timezone-bugs
are born.

By making it impossible to separate the two, go forces you to consider that
all the time. Which is, in my opinion, a good thing. That you get for very
little overhead.

On Wed, Sep 21, 2016 at 8:22 PM, Paul Jolly  wrote:

> Please can someone can enlighten me or point me towards relevant
> docs/other regarding the design decisions behind time.Time?
>
> Specifically why the concept of an instant in time, referenced many times
> throughout the time docs, was not encoded as a type itself:
>
> type Instant struct {
> sec int64
> nsec int32
> }
>
> and time.Time then reference time.Instant in some way:
>
> type Time struct {
> instant Instant
> loc *Location
> }
>
> The obvious difference being that an instant in time has no location. If
> I'm only interested in instants in time (i.e. my code doesn't do anything
> presentational) then the location is redundant.
>
> Many thanks
>
>
> --
> 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.Time vs time.Instant

[Paul Jolly]

Please can someone can enlighten me or point me towards relevant docs/other 
regarding the design decisions behind time.Time?

Specifically why the concept of an instant in time, referenced many times 
throughout the time docs, was not encoded as a type itself:

type Instant struct {
sec int64
nsec int32
}

and time.Time then reference time.Instant in some way:

type Time struct {
instant Instant
loc *Location
}

The obvious difference being that an instant in time has no location. If 
I'm only interested in instants in time (i.e. my code doesn't do anything 
presentational) then the location is redundant. 

Many thanks


-- 
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] ARM Cortex-R52 real time chip announced today

[Ged Wed]

Thanks for the response. That's an amazing testament to Yolanda design.

I guess it's just a matter of a board coming out with it on now and then
having a crack at it

On Wed, 21 Sep 2016, 19:54 Ian Lance Taylor,  wrote:

> On Wed, Sep 21, 2016 at 7:16 AM, Ged Wed  wrote:
> >
> > Today ARM announced a new real time chip for cars.
> >
> >
> http://www.anandtech.com/show/10690/arm-announces-the-cortexr52-cpu-deterministic-safe-for-adas-more
> >
> > https://github.com/golang/go/wiki/GoArm
> >
> > I am curious how hard it would be for golang to target this ??
> > Not that i would be anytime soon, but its seems like it would be great
> for
> > drones, robotics, and hardware that needs to be deterministic in the
> time it
> > takes to complete tasks.
>
> As far as I can see, the Go toolchain should be able to generate code
> today that will run on this processor.
>
> 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] pprof: what are runtime.scanobject/gentraceback/pcvalue/etc

[mhhcbon]

... Sorry for the publishing issues..


// BytesByLine emits chunks of []byte splitted by line (\n).
func BytesByLine() *Transform {
  var buf []byte
  var EOL = []byte("\n")

  byLine := func () [][]byte {
ret := make([][]byte, 0)
lines := bytes.Split(buf, EOL)
isEOL := len(buf)>0 && buf[len(buf)-1:][0]==EOL[0]
for i, line := range lines {
  if i==len(lines)-1 {
if isEOL && len(line)>0 {
  buf=buf[:0]
  ret = append(ret, line)
} else {
  buf = line
}
  } else {
ret = append(ret, line)
  }
}
return ret
  }

  var TT TransformFunc
  TT = func (s Stream, data interface{}) {
if val, ok := data.([]byte); ok {
  buf = append(buf, val...)
  for _, line := range byLine() {
s.Push(line)
  }
} else {
  s.Emit(errors.New("Value must be of type []byte"))
}
  }

  var FF FlushFunc
  FF = func (s Stream) {
for _, line := range byLine() {
  s.Push(line)
}
if len(buf)>0 {
  s.Push(buf)
}
  }

  return NewTransformFlush(TT, FF)
}

-- 
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] pprof: what are runtime.scanobject/gentraceback/pcvalue/etc

[mhhcbon]

Hi,

thanks again for all the explanations.

I kept digging, and now i m having the same behavior as this thread

https://groups.google.com/forum/#!topic/golang-nuts/P1EFc4kMBfo

I run test with memprofile enabled, then use pprof to see the results, but 
the numbers are all 0.

$ go test -v -bench=. -cpuprofile=cpu.out -memprofile mem.out -benchmem -
short stream/*
=== RUN   TestReader
--- PASS: TestReader (0.00s)
=== RUN   TestReader2
--- PASS: TestReader2 (0.00s)
BenchmarkByLine-4 10 14654 ns/op2248 B/op   
   39 allocs/op
PASS
ok  command-line-arguments1.635s


$ go tool pprof stream.test mem.out 
Entering interactive mode (type "help" for commands)
(pprof) top10
0 of 0 total (0%)
  flat  flat%   sum%cum   cum%
 0 0% 0%  0 0%  bytes.(*Buffer).WriteString
 0 0% 0%  0 0%  bytes.(*Buffer).grow
 0 0% 0%  0 0%  bytes.Split
 0 0% 0%  0 0%  bytes.genSplit
 0 0% 0%  0 0%  bytes.makeSlice
 0 0% 0%  0 0%  command-line-arguments.(*
Readable).Close
 0 0% 0%  0 0%  command-line-arguments.(*
Readable).Pipe
 0 0% 0%  0 0%  command-line-arguments.(*
Readable).Push
 0 0% 0%  0 0%  command-line-arguments.(*
Readable).Read
 0 0% 0%  0 0%  command-line-arguments.(*
Readable).ReadClose


I tried to put b.ReportAllocs() in front of the benchmark loop. It did not 
help.

At some points I added variations in the benchmark

$ go test -v -bench=. -cpuprofile=cpu.out -memprofile mem.out -benchmem -
short stream/*
=== RUN   TestReader
--- PASS: TestReader (0.00s)
=== RUN   TestReader2
--- PASS: TestReader2 (0.00s)
BenchmarkReader1-4 50  2337 ns/op 976 B/op 
 12 allocs/op
BenchmarkByLine-4  10 16560 ns/op2248 B/op 
 39 allocs/op
BenchmarkByLine2-4100  2113 ns/op 848 B/op 
 13 allocs/op
PASS
ok  command-line-arguments5.153s


which gives

$ go tool pprof stream.test mem.out
Entering interactive mode (type "help" for commands)
(pprof) top50
512.20kB of 512.20kB total (  100%)
Dropped 29 nodes (cum <= 2.56kB)
  flat  flat%   sum%cum   cum%
  512.20kB   100%   100%   512.20kB   100%  runtime.malg
 0 0%   100%   512.20kB   100%  runtime.allocm
 0 0%   100%   512.20kB   100%  runtime.newm
 0 0%   100%   512.20kB   100%  runtime.startTheWorldWithSema
 0 0%   100%   512.20kB   100%  runtime.systemstack


$ go tool pprof -inuse_objects stream.test mem.out
Entering interactive mode (type "help" for commands)
(pprof) top100
1260 of 1260 total (  100%)
Dropped 29 nodes (cum <= 6)
  flat  flat%   sum%cum   cum%
  1260   100%   100%   1260   100%  runtime.malg
 0 0%   100%   1260   100%  runtime.allocm
 0 0%   100%   1260   100%  runtime.newm
 0 0%   100%   1260   100%  runtime.startTheWorldWithSema
 0 0%   100%   1260   100%  runtime.systemstack


I m unclear because the tested func is definitely allocating,

// BytesByLine emits chunks of []byte split by line (\n).
func BytesByLine() *Transform {
  var buf []byte
  var EOL = []byte("\n")

  byLine := func () [][]byte {
ret := make([][]byte, 0)
lines := bytes.Split(buf, EOL)
isEOL := len(buf)>0 && buf[len(buf)-1:][0]==EOL[0]
for i, line := range lines {
  if i==len(lines)-1 {
if isEOL && len(line)>0 {
  buf=buf[:0]
  ret = append(ret, line)
} else {
  buf = line
}
  } else {
ret = append(ret, line)
  }
}
return ret
  }

  var TT TransformFunc
  TT = func (s Stream, data interface{}) {
if val, ok := data.([]byte); ok {
  buf = append(buf, val...)
  for _, line := range byLine() {
s.Push(line)
  }
} else {
  s.Emit(errors.New("Value must be of type []byte"))
}
  }

  var FF FlushFunc
  FF = func (s Stream) {
for _, line := range byLine() {
  s.Push(line)
}
if len(buf)>0 {
  s.Push(buf)
}
  }

  return NewTransformFlush(TT, FF)
}



Le mardi 20 septembre 2016 18:37:55 UTC+2, Ian Lance Taylor a écrit :
>
> On Tue, Sep 20, 2016 at 8:17 AM, mhhcbon  > wrote: 
> > 
> > on my way to learn to use pprof, i now face some intriguing results with 
> > lots of runtime.* calls, 
> > 
> > can you help me to understand what those call are and how i should care 
> > about ? 
> > 
> > (pprof) top30 
> > 8720ms of 14380ms total (60.64%) 
> > Dropped 118 nodes (cum <= 71.90ms) 
> > Showing top 30 nodes out of 143 (cum >= 3800ms) 
> >   flat  flat%   sum%cum   cum% 
> >  720ms  5.01%  5.01% 1050ms  7.30%  runtime.scanobject 
> >  

[go-nuts] Re: pprof: what are runtime.scanobject/gentraceback/pcvalue/etc

[mhhcbon]

Le mardi 20 septembre 2016 17:17:37 UTC+2, mhhcbon a écrit :
>
> Hi,
>
> on my way to learn to use pprof, i now face some intriguing results with 
> lots of runtime.* calls, 
>
> can you help me to understand what those call are and how i should care 
> about ?
>
> (pprof) top30
> 8720ms of 14380ms total (60.64%)
> Dropped 118 nodes (cum <= 71.90ms)
> Showing top 30 nodes out of 143 (cum >= 3800ms)
>   flat  flat%   sum%cum   cum%
>  720ms  5.01%  5.01% 1050ms  7.30%  runtime.scanobject
>  700ms  4.87%  9.87% 3640ms 25.31%  runtime.gentraceback
>  670ms  4.66% 14.53% 1780ms 12.38%  runtime.pcvalue
>  490ms  3.41% 17.94%  490ms  3.41%  runtime.readvarint
>  420ms  2.92% 20.86%  910ms  6.33%  runtime.step
>  420ms  2.92% 23.78%  420ms  2.92%  runtime/internal/atomic.Xchg
>  380ms  2.64% 26.43%  380ms  2.64%  runtime.heapBitsForObject
>  340ms  2.36% 28.79% 1580ms 10.99%  runtime.mallocgc
>  310ms  2.16% 30.95%  360ms  2.50%  runtime.gopark
>  270ms  1.88% 32.82%  270ms  1.88%  runtime.heapBitsSetType
>  260ms  1.81% 34.63%  510ms  3.55%  runtime.scanblock
>  250ms  1.74% 36.37%  250ms  1.74%  runtime/internal/atomic.Cas
>  240ms  1.67% 38.04% 4040ms 28.09%  github.com/mh-cbon/chan/stream
> .(*Transform).Push
>  240ms  1.67% 39.71% 1210ms  8.41%  runtime.schedule
>  230ms  1.60% 41.31%  230ms  1.60%  runtime.newdefer
>  220ms  1.53% 42.84%  320ms  2.23%  runtime.deferreturn
>  210ms  1.46% 44.30%  260ms  1.81%  bytes.genSplit
>  210ms  1.46% 45.76%  260ms  1.81%  runtime.greyobject
>  210ms  1.46% 47.22% 6080ms 42.28%  runtime.systemstack
>  200ms  1.39% 48.61%  210ms  1.46%  runtime.acquireSudog
>  200ms  1.39% 50.00% 1760ms 12.24%  runtime.scanframeworker
>  190ms  1.32% 51.32%  790ms  5.49%  sync.(*Mutex).Lock
>  180ms  1.25% 52.57%  180ms  1.25%  runtime.gogo
>  180ms  1.25% 53.82%  180ms  1.25%  runtime.memmove
>  170ms  1.18% 55.01%  790ms  5.49%  runtime.chanrecv
>  170ms  1.18% 56.19%  530ms  3.69%  runtime.lock
>  170ms  1.18% 57.37%  170ms  1.18%  runtime.usleep
>  160ms  1.11% 58.48%  220ms  1.53%  runtime.siftdownTimer
>  160ms  1.11% 59.60%  160ms  1.11%  runtime/internal/atomic.Load
>  150ms  1.04% 60.64% 3800ms 26.43%  main.main.func2
>
> Also, I m not totally comfortable with flat Vs cum meanings, 
> and those basics are not covered in 
> https://blog.golang.org/profiling-go-programs
>
> Can you take a moment to explain those two notions ?
>
> One more Q. In this pprof output
>
> (pprof) list Push
> Total: 14.38s
> ROUTINE  github.com/mh-cbon/chan/stream.(*Readable
> ).Push in /home/mh-cbon/gow/src/github.com/mh-cbon/chan/stream/reader.go
>  0  1.65s (flat, cum) 11.47% of Total
>  .  . 79:func (s *Readable) Push(b interface{}) {
>  .  . 80:  for s.Paused() {
>  .  . 81:<- time.After(time.Millisecond * 1)
>  .  . 82:  }
>  .  . 83:  s.writeMutex.Lock()
>  .   10ms 84:  defer s.writeMutex.Unlock()
>  .  . 85:  for _, o := range s.Pipes {
>  .  1.64s 86:o.Write(b)
>  .  . 87:  }
>  .  . 88:}
>  .  . 89:func (s *Readable) Catch(fn ErrorFunc) Stream 
> {
>  .  . 90:  s.E = append(s.E, fn)
>  .  . 91:  return s
> ROUTINE  github.com/mh-cbon/chan/stream.(*
> Transform).Push in /home/mh-cbon/gow/src/github.com/mh-cbon/chan/stream/
> transform.go
>  240ms  4.13s (flat, cum) 28.72% of Total
>  .  . 72:  } else {
>  .  . 73:s.Push(b)
>  .  . 74:  }
>  .  . 75:}
>  .  . 76:// Push writes data down in the stream.
>   40ms   40ms 77:func (s *Transform) Push(b interface{}) {
>  .  . 78:  // s.pipeMutex.Lock()
>  .  . 79:  // defer s.pipeMutex.Unlock()
>  190ms  190ms 80:  for _, o := range s.Pipes {
>   10ms  3.90s 81:o.Write(b)
>  .  . 82:  }
>  .  . 83:}
>  .  . 84:func (s *Transform) Catch(fn ErrorFunc) 
> Stream {
>  .  . 85:  s.E = append(s.E, fn)
>  .  . 86:  return s
>
>
>
> The tow methods are very similar, but Transform.Push shows 190ms for the 
> for loop, where Readable.Push does not show anything.
> How to understand this ?
>
>
> thanks!
>

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

[go-nuts] Re: create a .rpm file for go app.

[Diego Medina]

You could also use 
https://equinox.io/


once you have your token. keys, etc all setup, you can build new releases 
rpm, deb, etc using 

equinox release \
--version="1.0.0" \
--platforms="darwin_amd64 linux_amd64" \
--signing-key=/Users/inconshreveable/equinox.key \
--app="app_ja6WuaZgwsF" \
--token="4kj5ypgZj3QeGvGz7LckDGvcAcdmUozUNU8YhVhEg97r7dcmFgy" \
github.com/example/tool


https://equinox.io/docs#building-your-first-release

Regards,

Diego




On Tuesday, September 20, 2016 at 2:53:39 PM UTC-4, sujith...@gmail.com 
wrote:
>
>
> Right now, to build my .rpm package, I'm using this website: 
> https://packager.io/
>
> However, I would like to automate this in our prod enviroment. Whats the 
> best way? Any plugins or tools available to build the .rpm file from the GO 
> App code? I have Dependencies saved using GODEP.
>
>
>

-- 
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] Request for advice: Developing for Android

[Peter Kleiweg]

I want to start developing for Android, and would like your advice on that: 
Where to start.

My background is Linux. I have a lot of programming experience. Mainly C 
and Perl, followed by C and Python, and for the last five years it's mainly 
Go. I did some Java programming for a few weeks, decades ago, and I didn't 
like it.

I played around briefly with DroidScript http://droidscript.org/ a while 
ago, but never used it for anything useful.

My first goal is to get to know Android as a developer, learn its concepts, 
architecture, possibilities. What I am going to do with it is something I 
don't know yet, but I don't want to limit myself by using the wrong 
development platform. So, Android Studio would be the obvious choice. But: 
Java.

How about Go Mobile? Is that useful as a starting point, or should I try to 
get to know the system first using Android Studio? What are the 
capabilities of Go Mobile? Can it do all the stuff a native app can do, 
system calls, events, graphics, sound, sensors, communications, all that 
stuff? Can I use all the Java libraries for Android that I assume must be 
available out there?

Or should I use another platform all together? There seem to be so many. A 
quick search got me Adobe PhoneGap, Apache Cordova, DroidScript, 
NativeScript, AppDeck...

(If things can run on iPhone too... I don't care.)

I would like to hear your advice on what you think is the best platform. 
But what's important too is: does it have good tutorials, that explain 
concepts and architecture, as well as how to do practical stuff.

-- 
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] ARM Cortex-R52 real time chip announced today

[Ged Wed]

hey all,

Today ARM announced a new real time chip for cars. 

http://www.anandtech.com/show/10690/arm-announces-the-cortexr52-cpu-deterministic-safe-for-adas-more

https://github.com/golang/go/wiki/GoArm

I am curious how hard it would be for golang to target this ??
Not that i would be anytime soon, but its seems like it would be great for 
drones, robotics, and hardware that needs to be deterministic in the time 
it takes to complete tasks.




-- 
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: truncate float32 to lesser precision (22 bit mantissa)

[xiiophen]

Yes thanks. 

I decided on catching the missed ON (edge/corner) case at the end of the 
function with an extra if statement when the numerical work returns 
EXITS_BOX=true, ENTERS_BOX=false - then I do a relatively simple check for 
the 'ray' outside the box - if Ray.Origin was outside and EXITS_BOX=true 
then ENTERS_BOX should have been true too - so a contradiction here lets be 
catch the miss. (There's another reverse case I don't need to catch).

if s.X < xmin || s.Y < ymin || s.Z < zmin || s.X > xmax || s.Y > ymax || s.Z > 
zmax {
//origin is outside box *but* ray intersected with back plane
//  so ray should have intersected with front plane
//  probable rounding error at edge/corner intersection
return true, true, back_n, back_n, back_p, back_p
}


The float conversion is a little fiddly because of that implicit bit in the 
mantissa .. if the compiler is working well the catch is only 6 compares, 
and the rounding conversion adds a bit-ops AND, OR and SHIFT.. so I doubt 
the unsafe will make a huge difference in time.. though I think it could be 
preferable.



.. Mainly relieved to here someone say this problem is unavoidable with 
floats .. I can stop looking for maths work arounds.. Thanks again.

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

[go-nuts] DeviceAtlas Go wrapper

[David Carlier]

Hi all, I am working for DeviceAtlas, the mobile detection solution and 
know some users of the C enterprise API available here 
https://deviceatlas.com/deviceatlas-haproxy-module were wondering how to 
integrate it inside golang. Can be taken as it is or at least as an 
inspiration as I m not necessarily a very skilled go developer but if it 
can help a little, why not !

https://github.com/devnexen/deviceatlas-go-mod

-- 
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] Garbage collection internals information

[Gleb Stepanov]

Hi, folks.

 Recently i've watched Rick Hudsons presentation about beating latency 
problem in Go GC and it was great,
but when i've tried to understand how does it works i've concluded that 
there are not so much info compare to Java for example.
Design docs and source code looks complicated to get superficial grasp and 
not everybody has time to read Garbage Collection Handbook.
Is it possible for GC contributors to write series of blog posts, 
presentation etc. about GC internals? I guess it will be great for gophers 
who
would liketo know more about golang runtime internals, because stuff like 
writebarriers and their implementations, memory bitmaps and etc
are not so easy to understand by source code, even though comments are 
great.

Kind Regards, Gleb Stepanov.

-- 
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: Rational number to floating point

[Brendan Tracey]

Or if you have them as actual constants, 355.0 / 113

On Monday, September 19, 2016 at 12:07:13 PM UTC-6, Hotei wrote:
>
> I think you'll need something like x := float(355) / float(113)   - where 
> float is either float32 or float64 depending on your preferred trade-off 
> for accuracy vs bytes required per number.
>
> On Monday, September 19, 2016 at 12:38:12 PM UTC-4, Mark Longtin wrote:
>>
>> Hey guys, 
>>
>> I'm new to Go - through the Ivy app on IOS- so I have a newbie question. 
>> What's the easiest way to cast or convert a rational number to its floating 
>> point representation?
>>
>> EG, looking for something like this:
>>
>>
>> *float 355/113*3.14159292035
>>
>> I could do something inelegant like
>>
>>
>> *floor .5+1e11* 355/113*314159292035
>>
>> but was hoping there would be a native function for this.
>>
>> Thanks
>>
>>

-- 
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] go1.4.2/go/pkg/tool/linux_386/8g: signal: segmentation fault

[Dave Cheney]

Centos 5 is not supported, the kernel is too old. Sorry. 

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

[go-nuts] go1.4.2/go/pkg/tool/linux_386/8g: signal: segmentation fault

[Srinivasa Rao Ragolu]

Hi All,

 I am new to golang. I have been trying to build golang 1.5.0 with golang 
1.4.2 bootstrap binaries. My build host is centos5 and build is yocto 
build. But I always get below compilation issue.

# Building Go bootstrap tool.
| cmd/dist
| go build 
_/local/jenkins/ws/CB/160921103249-broadcom-ns2-emgw-3.10-1.4/i686/build-project/tmp/work/aarch64-montavista-linux/golang/1.5-r0/go/src/cmd/dist:
 
/local/jenkins/ws/CB/160921103249-broadcom-ns2-emgw-3.10-1.4/i686/build-project/tmp/work/aarch64-montavista-linux/golang/1.5-r0/go1.4.2/go/pkg/tool/linux_386/8g:
 signal: segmentation fault
| ERROR: build failed


Please Help me in resolving this issue.


Thanks,

Srinivas.

-- 
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] Record audio on Windows

[Dominik Link]

Hi

I'm currently writing a program which listens to a HID (sliders and 
buttons) and controls a karaoke program with these inputs. Grabbing input 
and sending commands with websockets work, but now I need to record the 
audio output as well.

I tried to compile and run portaudio, but I cannot install the golang 
wrapper (https://github.com/gordonklaus/portaudio) as it always returns 
with the following error: 
"C:/Program 
Files/mingw-w64/x86_64-5.3.0-posix-seh-rt_v4-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/5.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
 
cannot find -lportaudio
collect2.exe: error: ld returned 1 exit status "

Does anyone know a simple way to record audio output using go on Windows 
10? I don't want to tinker lots of hours to finally surrender anymore.

Regards,
Dominik

-- 
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] truncate float32 to lesser precision (22 bit mantissa)

[Michael Jones]

Any kind of computational geometry code will have subtle issues in just this 
area. Broadly, the issue is classification of a point or line as IN, OUT, or 
ON. Of these, ‘ON’ is the difficult one because floating point prevents perfect 
calculation where real numbers would allow it. This is because floating point 
is actually integer math with a companion power function, and the integer math 
part has the problem in cases of division where the numerators and denominators 
are relatively prime. This leads to differences in edge and point positions and 
frustrates the ON calculation, and this the in and out calculation near the 
edge.

 

I suggest that you think of this carefully because there is generally no good 
solution to be found by considering only floating point precision—the same 
problem will exist at any non-infinite precision.

 

However, to answer your specific question, yes you can easily truncate float32 
to a lower precision. Just force the bits you want to truncate to zero.

 

 Hp is high precision

 Lp is low precision

 

 Lp := (unsafe interpret as float)(Mask & (unsafe interpret as integer(Hp))

 

 Mask would be used to discard the lower bits of the word and thus precision. 

 Mask := ^uint32(0) << k //discard lowest k bits

 

Nice examples of what this accomplishes are here:

http://www.h-schmidt.net/FloatConverter/IEEE754.html

 

 

From:  on behalf of 
Date: Saturday, September 17, 2016 at 8:57 PM
To: golang-nuts 
Subject: [go-nuts] truncate float32 to lesser precision (22 bit mantissa)

 

ok I have a problem with rounding errors on floats which I think is 
unavoidable. Just as specific background this is happening for me on tests of 
vectors (lines) intersecting with bounding boxes (ie oblongs, axis aligned). 
Two code snippets shows the core of the maths..

 

front_n = (x_front - s.X) / v.X

ripY = s.Y + front_n*v.Y

ripZ = s.Z + front_n*v.Z

 

if (front_n > 0) && (ymin <= ripY && ripY <= ymax) && (zmin <= ripZ && ripZ <= 
zmax) {

 ...

   etc

 

and so on eg :

 

back_n = (x_back - s.X) / v.X

ripY = s.Y + back_n*v.Y

ripZ = s.Z + back_n*v.Z

 

if (back_n > 0) && (ymin <= ripY && ripY <= ymax) && (zmin <= ripZ && ripZ <= 
zmax) {

 ...

  etc 

 

where xmin, ymin etc represent the boundaries of the box, anything .X , .Y etc 
is one component of a 3d vector, and anything suffix _n is a scalar. All are 
floats

 

One of the two boundaries (front or back face) is occasionally skipped .. The 
issue occurs obviously (?) when the vector intersects and crosses the box close 
to or on and edge/corner are reached. It's rare, and clearly (?) switching to 
float64 makes it less rare, but doesn't solve the problem. I considered 
multiplying out the divides but that greatly complicates the boundary 
conditions, and I don't think it actually solves the problem.. I think using a 
'delta' in the boundaries just kicks the same problem down the road.

(I've got a simple workaround that doesn't solve the core problem..)

 

I think I need to truncate the accuracy of the float to 22 bits  - so the 
question is really about guard and round bits etc - we got anything supporting 
that in go ? It looked like I would have to use pkg unsafe

 

-- 
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] [ANN] gitstreak: a terminal-based Git contribution calendar (written in Go)

[Xudong Zheng]

https://github.com/xudongzheng/gitstreak

I decided to write this a few weeks ago to keep track of my own progress, 
after having read 
http://lifehacker.com/281626/jerry-seinfelds-productivity-secret months 
ago. Go related feedback in particular would be appreciated. Hope some of 
you find this useful!

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

[go-nuts] Problem with PDF generation with github.com/jung-kurt/gofpdf

[Ed Pelc]

Well adding some code would help. But generally there is a ln variable you need 
to set to 1 to break the line. 

Your really need to read the docs carefully to get what you want with gofpdf. 
Most of the info is there. 

-- 
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] Problem with PDF generation with github.com/jung-kurt/gofpdf

[Arie van Wingerden]

Hi,

I have started using https://godoc.org/github.com/jung-kurt/gofpdf

So far I can get some output, but everything is overlapping each other at
the start of the page.

I am using Cell or Text for writing a line of output.

How can I advance to the next physical "row" (line) in the output page?

TIA!

-- 
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: net/http: In the infinite loop, refused all requests.

[Tyler Compton]

This issue may be of interest to you:

https://github.com/golang/go/issues/10958

On Tuesday, September 20, 2016 at 7:42:24 PM UTC-7, Tony Chen wrote:
>
> ### What version of Go are you using (`go version`)?
> go 1.6.2 mac/amd64
>
> ### What operating system and processor architecture are you using (`go 
> env`)?
> GOARCH="amd64"
> GOBIN=""
> GOEXE=""
> GOHOSTARCH="amd64"
> GOHOSTOS="darwin"
> GOOS="darwin"
> GOPATH="/data/apps/go"
> GORACE=""
> GOROOT="/usr/local/go"
> GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
> GO15VENDOREXPERIMENT="1"
> CC="clang"
> GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments 
> -fmessage-length=0 -fno-common"
> CXX="clang++"
> CGO_ENABLED="1"
>
> ### What did you do?
>
> package main
>
> import (
> "net/http"
> "strconv"
> "fmt"
> )
>
> func main() {
> http.HandleFunc("/", httpHandler)
> http.ListenAndServe(":8001", nil)
> }
>
> func httpHandler(w http.ResponseWriter, r *http.Request) {
> b, _ := strconv.ParseBool(r.URL.Query().Get("loop"))
> if b {
> loop()
> }
> fmt.Fprintf(w, "ok")
> }
>
> func loop() {
> i := 0
> for {
> if i == 1 {
> i = 0
> }
> i++
> }
> }
> 1. curl http://127.0.0.1:8001/?loop=true
> 2. curl http://127.0.0.1:8001/?loop=false
> When the loop to the CPU processing and about 8 times the request, refused 
> to all the HTTP request.
> ### What did you expect to see?
>
> export GODEBUG=schedtrace=1000
> SCHED 1010ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 2016ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 3019ms: gomaxprocs=8 idleprocs=8 threads=6 spinningthreads=0 
> idlethreads=3 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 4028ms: gomaxprocs=8 idleprocs=7 threads=6 spinningthreads=0 
> idlethreads=2 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 5033ms: gomaxprocs=8 idleprocs=5 threads=6 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 6033ms: gomaxprocs=8 idleprocs=3 threads=8 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 7035ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=0 [0 0 0 0 0 0 0 0]
> SCHED 8037ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 9044ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 10050ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 11059ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
> SCHED 12060ms: gomaxprocs=8 idleprocs=0 threads=10 spinningthreads=0 
> idlethreads=0 runqueue=1 [0 0 0 0 0 0 0 0]
>
>
>

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