hich C saved
> us all.
>
> Unfortunately the good of these dead ends was lost, and the good of
> Algol68 was never even understood. I don’t long for them, but I miss their
> DNA being in the mix.
>
> On Fri, Dec 21, 2018 at 4:53 AM Jamie Clarkson > wrote:
>
>&
Happened to be randomly rereading through the EWD archives and came upon
this simultaneously with reading this thread:
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD230.html
(no comment!)
Jamie
On Friday, December 21, 2018 at 7:57:07 AM UTC, Tom Mitchell wrote:
>
>
> On Thu,
I've been trying to find examples of cases where it is complicated to
> structure the project because circular imports are forbidden, but I can't
> find something simple that I can show you. The thing is when I've been
> confronted to such cases, it was with large projects, and I have no
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
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 Na
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
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
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 loo
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
Yes that does help, looks like a really good solution. In your opinion
would the resulting code be worthwhile (including all the dictionaries,
stubs etc.) when compared to the C++ code expansion method? I can see that
it would save for the basic types and types derived from them but once you
:
>
> On Mon, 5 Nov 2018 at 11:38, Jamie Clarkson > wrote:
>
>> Thanks Rog, yes that seems to be very similar to what I was converging on
>> - I see you're combining the dictionaries per-implied-type (as I suggested
>> above) into a single dictionary per generic
ter tuples (e.g.
>> ShortestPath__10). The typeids.go file holds the crib for the identifiers (
>> https://github.com/rogpeppe/genericdemo/blob/master/graph/typeids.go).
>>
>> It actually seems to work. :)
>>
>>
>>
>> On Thu, 1 Nov 2018 a
ds.
> Cheers.
>
> On Thursday, November 1, 2018 at 10:04:08 AM UTC-4, Jamie Clarkson wrote:
>>
>> Thanks, that looks like a cool project - however I'd disagree that not
>> using contracts is relevant to the question.
>>
>> My interest was ma
e they would be nice to have. A good godoc goes a long way!
>
> Cheers.
>
> On Thursday, November 1, 2018 at 10:04:08 AM UTC-4, Jamie Clarkson wrote:
>>
>> Thanks, that looks like a cool project - however I'd disagree that not
>> using contracts is relevant to th
not relevant for your question since
> contracts are for compile time)
>
> On Tuesday, October 30, 2018 at 12:14:42 PM UTC-4, Jamie Clarkson wrote:
>>
>> Replying to myself but I've got a different method with a dictionary per
>> type instead of the interf
, Jamie Clarkson wrote:
>
> Ah ok, sorry I don't want to waste your time getting into the nitty-gritty
> of a hypothetical situation but are you meaning the
> code for (say):
>
> func (u *_UserEdge) Nodes() _SliceN {
> nodes := u.UserEdge.Nodes() // type []UserNode
>
, 2018 at 3:19:42 PM UTC, Ian Lance Taylor wrote:
>
> On Tue, Oct 30, 2018 at 8:15 AM, Jamie Clarkson > wrote:
> >
> > I'm not sure what you meant by conversion of non-interface to interface
> > types to handle results? I can see the usual conversions working fi
itly mutual rec types into the
single contract (and apparently implicitly mutual types).
Jamie
On Tuesday, October 30, 2018 at 1:50:02 PM UTC, Ian Lance Taylor wrote:
>
> On Tue, Oct 30, 2018 at 6:13 AM, Jamie Clarkson > wrote:
> >
> > Apologies if this is covered
Hi gophers,
Apologies if this is covered somewhere, have searched and not found.
I'm curious about the Go2 generics draft, how does the team envisage the
code generated for the ShortestPath (without code expansion like C++
templates where it's obvious)? I can come up with two so far.
i)
I agree with the first part, but not the second - 'for' is far more 'Go
like' in terms of clarity and meaning
Compare the first few meanings of 'loop':
http://www.dictionary.com/browse/loop?s=t
with 'for': http://www.dictionary.com/browse/for?s=t
Although I think 'desirous' would be an
Ah yes, thanks for that - it should be relatively easy to add back in the
Go code to support all architectures (it was all originally Go before
rewriting in ASM for the SIMD) so I'll add a note to do that soonish. The
SSE4 requirement may be able to be relaxed too as the traversal code
Hi,
I'd just like to announce a little project I've just released into alpha.
It's a physically based renderer written in Go.
You can install Vermeer via go get github.com/jamiec7919/vermeer
There are some example data files available at:
https://github.com/jamiec7919/vermeer-example/
And
22 matches
Mail list logo
