Re: [go-nuts] if/switch statements as expressions

ead zone from which 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:

Re: [go-nuts] if/switch statements as expressions

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

Re: [go-nuts] Rethink possibility to make circular imports

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 simpl

Re: [go-nuts] [ANN] fixed point math library

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

Re: [go-nuts] [ANN] fixed point math library

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

[go-nuts] Re: Rethink possibility to make circular imports

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 Lev

Re: [go-nuts] [ANN] fixed point math library

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

Re: [go-nuts] [ANN] fixed point math library

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

Re: [go-nuts] [ANN] fixed point math library

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

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

rog wrote: > > 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 g

Re: [go-nuts] Code generated by generics draft

ifiers to identify type parameter 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. :) >> >> >>

Re: [go-nuts] Code generated by generics draft

tricted overloads. > 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 inte

Re: [go-nuts] Code generated by generics draft

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

Re: [go-nuts] Code generated by generics draft

use contracts (but 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 >> t

Re: [go-nuts] Code generated by generics draft

M UTC, 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 []UserN

Re: [go-nuts] Code generated by generics draft

er 30, 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 work

Re: [go-nuts] Code generated by generics draft

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

[go-nuts] Code generated by generics draft

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

[go-nuts] Re: Go could really use a while statement

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 excelle

[go-nuts] [ANN] New (alpha) version of Vermeer Light Tools released

Hi Gophers, I've just released a new (alpha) version of Vermeer Light Tools, a physically plausible renderer written in Go. Check it out: https://github.com/jamiec7919/vermeer . A few new features in this release including more advanced anisotropic texture filtering, multiple importance sam

[go-nuts] Re: [ANN] Vermeer - physically based rendering (raytracing) with Go

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

[go-nuts] Re: [ANN] Vermeer - physically based rendering (raytracing) with Go

I can't say I've really thought about using the standard library for handling HDR images, although I can definitely see how that could be useful. As you say it looks tricky to fit the expected colour.Colour behaviour, although there is 16bits to play with there? Mostly I'd be looking to either

[go-nuts] [ANN] Vermeer - physically based rendering (raytracing) with Go

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 p