On Wednesday, 12 June 2019 23:48:36 UTC+2, Michael Jones wrote:
>
> Volker, did you see a few posts back that I did the run Roger asked about,
> on RSC’s huge corpus? It is about 10x the size and its parens, braces, and
> brackets match just fine, all *7476284* of them
>
If I remember the c
All of a sudden, when trying to build programs that used to work, as
recently as a couple of days ago, I'm getting
main.go:6:2: cannot find package "text/template" in any of:
C:\Go\src\text\template (from $GOROOT)
D:\\Go\src\text\template (from $GOPATH)
I was trying this in a module, but when
Yeah, no doubt, I totally agree with that as well.
But now, I can proudly say ...
My Go beats C :-)
On Thu, Jun 13, 2019 at 12:09 AM Justin Israel wrote:
>
>
>
> On Thu, Jun 13, 2019 at 4:05 PM Tong Sun wrote:
>>
>> Yep, thanks Justin, both your points really made the difference,
>> because I
On Thu, Jun 13, 2019 at 4:05 PM Tong Sun wrote:
> Yep, thanks Justin, both your points really made the difference,
> because I do believe that the buffered socket write is the key
> component for the 3-time improvement that I'm getting (from using
> FastHTTP), IMHO. And FastHTTP recommends GOMAXP
Yep, thanks Justin, both your points really made the difference,
because I do believe that the buffered socket write is the key
component for the 3-time improvement that I'm getting (from using
FastHTTP), IMHO. And FastHTTP recommends GOMAXPROCS=1 too, which I
used this time as well.
So thanks aga
On Mon, Jun 10, 2019 at 5:27 PM Tong Sun wrote:
> > IMO this is just not a meaningful test. Or its results are totally
> > unsurprising.
>
> Again, I was trying to improve Perl performs with Go. That
> "ridiculously simple" Perl code is the foundation of the Debian dbab
> package, and I was tryin
This is interesting. I have exactly the opposite situation; up-down is
much easier than significant left-right because of faulty saccades.
On Wed, 2019-06-12 at 11:41 -0700, Michael Jones wrote:
> Bakul, more good arguments. I have another motivation in the "?"
> world that
> I've not argued becau
I feel your pain. For me it's at the other end of the keyboard.
Dan
On Wed, 2019-06-12 at 17:01 -0700, Ian Lance Taylor wrote:
> On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak
> wrote:
> >
> > For others, the cl is https://golang.org/cl/181840 (note the extra
> > 0).
>
> Thanks.
>
> (My laptop
On Wed, Jun 12, 2019 at 12:14 PM Neil Schellenberger
wrote:
>
> Sorry for the delay in responding. Filed as
> https://github.com/golang/go/issues/32579.
Thanks.
Ian
> On Tue, Jun 11, 2019 at 1:21 AM Ian Lance Taylor wrote:
>>
>> On Mon, Jun 10, 2019 at 9:14 PM Neil Schellenberger
>> wrote:
On Wed, Jun 12, 2019 at 2:55 PM Dan Kortschak wrote:
>
> For others, the cl is https://golang.org/cl/181840 (note the extra 0).
Thanks.
(My laptop keyboard is barely a year old and already becoming unreliable.)
Ian
> On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> > On Tue, Jun 1
On Wed, Jun 12, 2019 at 7:39 AM t hepudds wrote:
>
> Thank you for sending that CL 181840.
>
> One minor request for clarification on the discussion here.
>
> When you said earlier in this thread:
>
> > “For almost all users the default
> value will be correct. At least, I hope that is the case.”
thx, filed at https://github.com/golang/go/issues/32588
On Wednesday, June 12, 2019 at 11:48:20 PM UTC+2, andrey mirtchovski wrote:
>
> collection is not an exported type:
> https://github.com/couchbase/moss/blob/master/collection.go#L24
>
> the ?m=all parameter should enable you to see those, b
For others, the cl is https://golang.org/cl/181840 (note the extra 0).
On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak
> wrote:
> >
> > Having that and exactly what it means in the go help modules output
> > would probably be the best ou
Volker, did you see a few posts back that I did the run Roger asked about,
on RSC’s huge corpus? It is about 10x the size and its parens, braces, and
brackets match just fine, all *7476284* of them
On Wed, Jun 12, 2019 at 2:13 PM Michael Jones
wrote:
> They matched up until yesterday. When I
collection is not an exported type:
https://github.com/couchbase/moss/blob/master/collection.go#L24
the ?m=all parameter should enable you to see those, but it's not
working for me on your link. perhaps because "collection" and
"Collection" are not considered by godoc to be two different things?
y
aaa ok thx
On Wednesday, June 12, 2019 at 11:40:29 PM UTC+2, David Anderson wrote:
>
> collection is an unexported type. Godoc doesn't show unexported types by
> default, so none of the methods of collection will appear.
>
> On Wed, Jun 12, 2019 at 2:25 PM Gert >
> wrote:
>
>> Is it just me or i
Thanks, Ian.
I'll look later today.
Dan
On Wed, 2019-06-12 at 07:01 -0700, Ian Lance Taylor wrote:
> On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak
> wrote:
> >
> > Having that and exactly what it means in the go help modules output
> > would probably be the best outcome.
> >
> > Currently it'
collection is an unexported type. Godoc doesn't show unexported types by
default, so none of the methods of collection will appear.
On Wed, Jun 12, 2019 at 2:25 PM Gert wrote:
> Is it just me or is stuff missing in godoc like for example
>
> // NewBatch returns a new Batch instance with hinted a
Is it just me or is stuff missing in godoc like for example
// NewBatch returns a new Batch instance with hinted amount of
// resources expected to be required.
func (m *collection) NewBatch(totalOps, totalKeyValBytes int) (
...
}
from collection.go
https://godoc.org/github.com/couchbase/moss
-
Try a VMWARE virtual machine.
Install a FreeBSD distro and as long as the hardware (CPU) is the same you
should be good.
Even targeting a different hardware platform might be easier inside a VM.
Inside the VM you can save temp files and capture compiler, assembler and
linker settings to
Chip away
They matched up until yesterday. When I updated at 2am California time it
changed. It also had no "0o" octal literals up until the latest.
I'd planned to joke how the race was on to be the first to check in a new
octal literal in my mail, but a few of those snuck in too.
Yesterday:
Count | Frequ
Cool work!
What I found most astonishing on a first look: Not all
parentheses ( are closed: 4 ) seem to be missing??
For { 5 are unclosed while there is one more ] than [ ?
Are you parsing testfiles with deliberate errors?
V.
On Wednesday, 12 June 2019 15:08:44 UTC+2, Michael Jones wrote:
>
>
I agree that ? for simple choices is nice. But my C experience with nested
?s and with long expressions for one or both branches has not been nice.
The mandatory {}s make Go's nested ifs more readable (but vertical).
On Wed, Jun 12, 2019 at 2:42 PM Michael Jones
wrote:
> Roger, here's the same t
Sorry for the delay in responding. Filed as
https://github.com/golang/go/issues/32579.
On Tue, Jun 11, 2019 at 1:21 AM Ian Lance Taylor wrote:
> On Mon, Jun 10, 2019 at 9:14 PM Neil Schellenberger
> wrote:
> >
> > When upgrading our build container from 1.11.10 to 1.12.5, some of our
> tests f
Roger, here's the same thing, but for Russ's corpus v0.01:
https://gist.github.com/MichaelTJones/609589e05017da4be52bc2810e9df4e8
I've been comparing the two side by side and it's fascinating.
Bakul, more good arguments. I have another motivation in the "?" world that
I've not argued because it
I haven't looked further than the godoc, but a couple of initial
suggestions:
- the word JSON should always be spelled in all-caps if the first letter is
J, so you would be better with NewJSONParser.
- you should almost certainly return a chan, not a pointer to chan.
On Tue, 11 Jun 2019, 13:47
On Wed, Jun 12, 2019 at 1:18 AM Jan Mercl <0xj...@gmail.com> wrote:
> > Disallowing unintended fall throughs into labeled sections of a block
> will prevent a class of stupid errors.
>
> I'm stupid and I know it. Yet, it seems I haven't made this kind of error
> in the last ten years of Go. Maybe
On Jun 12, 2019, at 8:24 AM, Michael Jones wrote:
>
> Bakul, these are good points.
>
> On the second, I used to always write (C/C++):
>
> If (things are good) {
> happy case
> } else {
> sad case
> }
>
> so the nesting was that the all-good was the first code block even when
> multip
Thank you. Probably too hard for me.
On Tuesday, June 11, 2019 at 10:09:49 PM UTC-6, Tamás Gulácsi wrote:
>
> Not hopeless, just hard. You need a cross-C-compiler, and use that.
>
> It's easier to compile on native en.
> But you can try github.com/karalabe/xgo if you have Docker.
>
--
You recei
On Wednesday, 12 June 2019 17:25:19 UTC+2, Michael Jones wrote:
>
> Bakul, these are good points.
>
>
> Nice work, Michael; nice comments, Bakul.
It's nice when the philosophy behind intuition is given some solidity. I
keep hoping to see more of Dijkstra's "A Discipline of Programming" leaking
I wonder whether the Go 1.13 code base is representative of Go in the wild.
It might be interesting to see the results when run on the code in the Go
corpus. https://github.com/rsc/corpus
On Wed, 12 Jun 2019 at 14:08, Michael Jones wrote:
> I've been working on a cascade of projects, each needin
Bakul, these are good points.
On the second, I used to always write (C/C++):
If (things are good) {
happy case
} else {
sad case
}
so the nesting was that the all-good was the first code block even when
multiply nested and the exceptions came later. A blunt kind of literate
programming
On Jun 12, 2019, at 7:36 AM, Michael Jones wrote:
>
> 128640 If statements, and just 8034 else, a 16:1 ratio. I'd like to
> understand this better,
There are two patterns that encourage this:
x := v1
if someCond { x = v2 }
And
if someCond { return ... }
The second pattern acts s
Hi Ian,
Thank you for sending that CL 181840.
One minor request for clarification on the discussion here.
When you said earlier in this thread:
> “For almost all users the default
value will be correct. At least, I hope that is the case.”
I *think* what you are saying is for almost everyone
Yes, quite a bit there of note:
More hex numbers than decimal. That was a surprise.
The "0o" prefixed octal number literals just went in in the last two days.
I think a gofix rewrite might be in order--it is more explicit and less
vulnerable to mistake than the legacy 0377 style--despite a whole
On Tue, Jun 11, 2019 at 6:30 PM Dan Kortschak wrote:
>
> Having that and exactly what it means in the go help modules output
> would probably be the best outcome.
>
> Currently it's not mentioned in that output for the current release
> (1.12.6) and the meaning/implication of "expected [Go] langua
On Wed, Jun 12, 2019 at 6:08 AM Michael Jones wrote:
>
> I've been working on a cascade of projects, each needing the next as a part,
> the most recent being rewriting text.Scanner. It was not a goal, but the
> existing scanner does not do what I need (recognize Go operators, number
> types, an
I've been working on a cascade of projects, each needing the next as a
part, the most recent being rewriting text.Scanner. It was not a goal, but
the existing scanner does not do what I need (recognize Go operators,
number types, and more) and my shim code was nearly as big as the standard
library
And if you prefer a talk, there is one by Bryan C. Mills,
https://www.youtube.com/watch?v=5zXAHh5tJqQ
which describes common concurrency patterns and how to apply them. In your
case, a buffered channel can work as a (counting) semaphore. The invariant
is: the number of tokens in the channel is th
> Disallowing unintended fall throughs into labeled sections of a block
will prevent a class of stupid errors.
I'm stupid and I know it. Yet, it seems I haven't made this kind of error
in the last ten years of Go. Maybe I'm just lucky. Or maybe this kind of
error is rare. But if it's rare then a l
40 matches
Mail list logo
