Andrew,
Thanks for doing this. The Cloud Platform is great and I'm glad you're
looking into this. Here are my 2c that didn't quite fit in the survey: when
not running in a 'full' environment (lambdas/cloud functions, app engine,
containers etc.), it would be good to keep the package/vendoring co
it in the x/ packages, or something that should be left for 3rd party
package writers.
Thanks,
Ondrej
--
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
Klaus, that's a great thread, completely missed it.
It seems that a universal binary, as Go requires it, would be slow on
dispatch, because there would be too much checking for individual
intrinsics support. Do I understand it correctly, that to overcome this,
people either compile natively (wh
On Thursday, 3 November 2016 01:40:29 UTC, Nigel Tao wrote:
>
>
> Another ignorant question from me, but what do you mean exactly by
> universal binary?
>
Apologies for the confusing and nonsensical term. What I meant was a binary
that works for a number of CPUs within an architecture, with or
I have a tool that generates some HTML and launches a web browser to
display it. For this to work, I need to save the HTML some place and I also
need to handle the file afterwards. The app itself doesn't persist - it
generates the content and exits. There are thus two issues I'm struggling
with
:= ioutil.TempFile("", "")
>
> Obtain a new temp dir :
> dir, err := ioutil.TempDir("", "")
>
> I suggest you don't bother with cleanup. It should work on any OS.
>
> On Friday, November 18, 2016 at 11:21:23 AM UTC+1, Ondrej wrote:
>
I already noted that in my very first post, "How do I clean up? As I said,
the app does not persist (so I can't defer os.Remove)"
I guess I wasn't quite clear about my intentions, so never mind, I'll just
handle it somehow.
Thanks all for your suggestions.
On Monday, 21 November 2016 16:57:56
And in case you want to actually marshal it into a struct, I recommend
giving JSON to Go a... go.
On Tuesday, 22 November 2016 20:48:49 UTC, vanmuld...@gmail.com wrote:
>
> I just started leaning Go and I've been stuck on this for a couple of days
>
> Running on an App Engine dev server
>
>
> The
Hey,
I had int as a key in my map and later realised I only used 100 or so
values, so swapped it for a uint8, expecting a minor speed increase, but
saw a major slowdown instead. To recreate this, I tried this simple
microbenchmark and was surprised by the difference between (u)int8/16 and
int/i
Oh yeah, preallocating 256 elements is fine. It's a bit expensive to
allocate 2**16 for the int16 case, so I'll have to do with the slow hashing
there - or are there any plans for speeding up that one?
Cheers, this is helpful.
O.
On Saturday, 17 December 2016 06:15:43 UTC+1, Damian Gryski wrot
Excellent work!
- Binary 27% smaller
- Performance up by 5-10%
- JSON marshalling of numerical keys much welcome
- Fortran support is great (I haven't tested it, but just the prospects are
cool)
Thank you, as always.
On Friday, 8 July 2016 05:50:34 UTC+1, Chris Broadfoot wrote:
>
> Hello gopher
Hi all,
I have a model with variables, let's call them a, b, c, ..., z. These are
numerical values (time series loaded from a database) and I let the user
specify their relationships in a JSON, say 'z = 12; x = a + 2/3 + 3*c; y =
log(12*f) + exp(g)' etc. The syntax is trivial - it's basically ju
I wanted to see if there was a difference when loading values from a
large-ish slice (1 elements) - to see if caches, locality and other
things had any meaningful impacts. Whilst individual value loading (just a
single element) seemed to be equally fast regardless of element position
(see b
Excellent stuff. I remember finding out about trace over here
https://groups.google.com/forum/#!topic/golang-nuts/Ktvua7AGdkI
and I marvelled that there wasn't any documentation, so it was all trial
and error for me. But what a gem. What a gem. Both the tool and your blog
post.
On Thursday, 6
be mostly
fine for functions.
While it probably does not solve any problems for any people apart from me,
I'll try and fix the method issues, because I do really need it for my own
test writing.
Do let me know if there's a better solution to this or if you've
encountered thi
n Wednesday, 18 March 2020 13:29:05 UTC+1, Robert Engels wrote:
>
> It’s because you are not writing the top level test correctly - there is
> no testing at all !
>
> On Mar 18, 2020, at 7:02 AM, Ondrej >
> wrote:
>
>
> Hey!
>
> There's an issue I've b
> reason to test them in isolation.
>
> On Mar 18, 2020, at 9:04 AM, Ondrej >
> wrote:
>
>
> That omission is not really relevant. Even if I included an assertion in
> the test, it wouldn't affect the point I am making. I just wanted to have
> at least some so
I must agree that Russ made some really valid points. I would like to see some
concrete examples that contradict his reasoning.
--
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, sen
I am not sure what is your problem exactly. Did you follow the readme and
actually installed dep tool?
--
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-nut
Not sure what you mean but if you are asking if go compiler generates C
code which is then compiled by gcc then not really. Since version go 1.5
even the compiler itself is written in pure Go and since then no C code is
needed anymore.
On Tuesday, December 12, 2017 at 10:03:08 PM UTC+1, erfang.
go tool trace was nicely explained here
https://groups.google.com/forum/#!topic/Golang-Nuts/Ktvua7AGdkI
and had no proper documentation at the time. Would be good if it had a high
level overview like that
On Tuesday, 18 October 2016 19:54:49 UTC+1, Jaana Burcu Dogan wrote:
>
> Hello gophers,
>
parsing the equation; but that's just now off the top
of my head.
I attached a pprof result in the header.
Thanks again.
On Friday, 8 July 2016 15:46:32 UTC+1, Egon wrote:
>
> On Friday, 8 July 2016 16:25:40 UTC+3, Ondrej wrote:
>>
>> Hi all,
>> I have a model with
gt;>
>> *From: * on behalf of Egon
>> *Date: *Monday, July 18, 2016 at 1:32 AM
>> *To: *golang-nuts
>> *Cc: *
>> *Subject: *[go-nuts] Re: An efficient runtime expression evaluation
>>
>>
>>
>>
>>
>> On Monday, 18 July 2016
chmarkFirst-4 20 0.59 ns/op
>>
>> BenchmarkSecond-4 20 0.59 ns/op
>>
>> BenchmarkLast-4 20 0.59 ns/op
>>
>> BenchmarkPenultimate-4 20 0.58 ns/op
>>
>> On Wednesday, August
(I have now recreated it on my Mac, under 1.7rc5, the runtime differences
are still there.) I thought the compiler was removing these as you suggest,
but then StartEnd and EndStart had wildly different running times, despite
using the very same values. So I added dummy assignments to double chec
Excellent, now it's all consistent. Thank you, sir.
https://play.golang.org/p/cKANdyqXen
Still a bit confused as to why the code elimination in the previous
examples yielded code with such differing performance, but at I'm glad that
locality was not the culprit.
Thanks everyone for your input.
This is excellent, really helpful. The -help flag only mentions testing and
casual searching only again pops up with info on more testing, I couldn't
see anything on actually using it for running a generic binary. Perhaps it
would be worth adding this to the documentation?
+ things like not nee
Maybe this is more OS related than Go, since Go just produces a static
executable, so please feel free to lock this.
I've built a simple tool, it works just fine in the terminal, both as a
local executable and when put in the PATH. But when I want to register it
as the default app for a given f
ms of appreciation.
I'd like to help to give back to the community so if this is a go then I'm
in!
Ondrej
Dne úterý 18. července 2017 3:52:04 UTC+2 Nate Finch napsal(a):
>
> (sorry for the duplicate post, the other one disappeared)
>
> I wrote a tweet after Gophercon about making
29 matches
Mail list logo
