<<06-09-2012>>

---

02:02:29	*	zahary quit (Ping timeout: 248 seconds)
09:38:59	*	Araq_ joined #nimrod
09:41:57	*	Araq_ quit (Client Quit)
10:31:45	*	St_Darius joined #nimrod
10:33:20	*	St_Darius left #nimrod (#nimrod)
11:57:28	*	q66 joined #nimrod
12:21:22	*	zahary joined #nimrod
12:40:04	*	zahary quit (Quit: Leaving.)
13:06:42	*	zahary joined #nimrod
14:31:42	*	zahary quit (Quit: Leaving.)
14:39:49	*	Trix[a]r_za is now known as Trixar_za
14:41:27	Trixar_za	Erm
14:41:46	Trixar_za	Why am I getting messages from Github meant for Araq?
14:56:47	*	zahary joined #nimrod
15:07:30	*	zahary quit (Quit: Leaving.)
15:37:46	dom96	Trixar_za: Are you watching the Nimrod repo?
15:39:18	Trixar_za	Yeah
15:40:14	dom96	that's probably why
16:50:25	*	shevy quit (Read error: Operation timed out)
16:57:03	Araq	btw dom96, I tried to fix the closure bug you encountered
16:57:10	Araq	but I can't even compile asyncio ...
16:57:15	Araq	and the tests fail too
16:58:14	dom96	huh?
16:58:21	dom96	tasynciossl passes?
16:58:58	Araq	seems you fucked up the test :P
16:59:27	dom96	How so?
17:00:41	Trixar_za	:|
17:00:52	*	zahary joined #nimrod
17:00:53	Trixar_za	There is a Pussy Energy drink?
17:00:59	dom96	Trixar_za: yeah!
17:01:05	dom96	I bought it once :D
17:01:25	Trixar_za	lol
17:01:33	Trixar_za	Well, atleast I knew about Pussy Linux
17:02:04	Araq	zahary: I got some new ideas about 'const' and the effect system
17:02:33	dom96	Araq: Come on. Don't just lose interest :P
17:02:43	dom96	How did I fuck up the test?
17:02:52	Araq	ok, let me see
17:03:05	Trixar_za	http://puppylinux.info/topic/pussy-linux-discution-continues-here
17:03:37	zahary	hi araq
17:05:11	*	shevy joined #nimrod
17:07:47	Araq	er, dom96, asyncio compiles
17:08:03	dom96	... yeah
17:08:09	dom96	So what's the problem?
17:08:50	Araq	for a start, you don' export 'TInfo'
17:09:10	Araq	just look at the test results please
17:09:42	dom96	'TInfo' shouldn't be exported.
17:10:06	Araq	nimrod check lib/pure/scgi.nim
17:10:10	dom96	ugh.
17:10:16	Araq	lib/pure/scgi.nim(188, 7) Error: undeclared field: 'handleAccept'
17:10:21	dom96	Be more explicit please.
17:10:34	dom96	"asyncio doesn't compile" is not the same as "scgi doesn't compile"
17:10:39	dom96	Because asyncio does in fact compile.
17:10:43	dom96	And its tests do pass.
17:10:50	Araq	proc getSocket(h: PObject): tuple[info: TInfo, sock: TSocket] # TInfo here?
17:10:53	dom96	I have not fixed scgi/ftpclient/et al yet
17:11:08	Araq	well you broke the interface
17:11:10	dom96	Yes.
17:11:18	Araq	that's hardly "fixing"
17:11:23	dom96	It was necessary.
17:11:30	dom96	The interface was socket specific.
17:11:40	Araq	lol?
17:11:49	Araq	scgi only makes sense with sockets ...
17:12:09	dom96	Yes. Listen.
17:12:15	dom96	TDelegate was socket specific.
17:12:21	dom96	It is no file descriptor specific.
17:12:27	Araq	well I got a blob of code from you that doesn't compile
17:12:35	dom96	So it works with sockets, files and whetever else uses file descriptors.
17:12:41	Araq	how am I supposed to fix code gen bugs with that?
17:12:54	dom96	You're not.
17:13:27	dom96	But don't say asyncio doesn't compile when it does :P
17:14:41	Araq	ok
17:14:43	Araq	brb
17:15:09	zahary	so Araq, tell me about your new ideas
17:18:39	Araq	well I thought about CSE (common subexpression elimination)
17:18:50	Araq	and how to implement it
17:19:05	Araq	of course, TR macros are not up for to this task
17:19:18	Araq	but you could "easily" do something like:
17:19:39	Araq	proc p() {.cse.} = ... # cse macro does the optimization
17:20:13	Araq	however to be effective you want CSE to work across basic block boundaries
17:20:22	Araq	(making it 'global' iirc)
17:20:45	Araq	so you have code like:
17:20:52	Araq	use n.len
17:21:03	Araq	echo n.treeDepth()
17:21:09	Araq	useAgain n.len
17:21:31	Araq	and CSE for 'n.len' can be performed if you know that 'treeDepth' does not modify a PNode
17:21:49	dom96	Araq: https://gist.github.com/c041537978a23bb97e02 Sorry for the amount of code.
17:21:57	dom96	That's actually a code gen bug I believe.
17:22:15	Araq	so the effect system need to track *stores*
17:22:44	Araq	as a simple first step any store is considered equal
17:23:08	Araq	and treeDepth() does no store whatsoever, so it's safe to optimize
17:23:27	Araq	the next step would be to parametrize the store effect with the type that is affected
17:23:45	dom96	And I just found a bug in asyncio
17:24:09	Araq	stores/writes are generally very useful to track as they affect both aliasing and parallelism
17:24:56	Araq	the next step would be to track the *path* that is effected, but that's too much work I think ;-)
17:24:57	zahary	when you say "the type that is affected", you mean the location that is being written, right?
17:25:05	Araq	no, the type
17:25:12	Araq	PNode in the example
17:25:25	zahary	why is this interesting by itself?
17:25:40	Araq	because n.len can only be accessed via PNode
17:25:54	Araq	ok, not really thanks to 'addr'
17:25:56	zahary	but you care about particular PNode
17:26:10	Araq	no, any PNode is treated equal
17:26:25	Araq	otherwise it would indeed be a location
17:26:33	Araq	but location tracking is really hard
17:27:17	zahary	so per-type tracking is something of a heuristic that works most of the time and is good enough?
17:27:30	Araq	well I dunno, I hope so
17:27:58	Araq	for a start even 'nowrite' would be useful
17:28:11	Araq	I dunno if you looked at the tnoalias test
17:28:42	Araq	template optslice{a = b + c}(a: expr{noalias}, b, c: expr): stmt =
17:28:44	Araq	a = b
17:28:45	Araq	inc a, c
17:29:30	Araq	for other patterns 'nowrite' is nice to have
17:29:32	zahary	I think the C compilers are trying to do at least a part of this btw - probably a language could take advantage of some higher-level information, but I don't know where the line SSA optmizer and the high-level optmizer should be
17:29:51	zahary	* the line between *
17:30:06	Araq	yeah I don't know how good they are either
17:30:15	Araq	did no tests
17:30:55	Araq	I'm quite sure LLVM doesn't do it as well as we could do it in the frontend
17:31:11	*	Trixar_za is now known as Trix[a]r_za
17:31:54	Araq	the effect system essentially performs this optimization on a whole program level
17:32:19	Araq	whereas I think the "whole program opts" are more of an afterthought for LLVM
17:32:58	zahary	from what I've read whole program optimization was a design goal from the start for them
17:33:36	zahary	they even wanted on the fly profile guided recompilation (that was their first paper)
17:34:11	zahary	that was before apple decided to replace gcc with llvm (making much more of a classic static compiler)
17:34:31	Araq	well alright, I could be wrong
17:35:21	Araq	and my educated guess would be that visual C++ performs the optimization the way I image or much better ;-)
17:35:39	reactormonk	Araq: I suppose you want tests, right?
17:35:42	Araq	in general visual C++'s analysis is really deep
17:36:05	Araq	reactormonk: not really, if it compiles and you tested it, it's good enough
17:36:22	Araq	the test suite already runs very long
17:36:39	zahary	yes, my intuition is that for this particular problem the low level form of the code (concerned only with reads and writes to structures) is good enough
17:37:17	Araq	yeah well
17:37:28	Araq	it's nice to say this though and have the compiler check it:
17:37:36	zahary	user defined effects is where a new language could shine
17:37:40	Araq	proc depthTree(n: PNode): int {.nowrite.} = ...
17:38:01	Araq	which is actually stricter than 'noSideEffect'
17:38:17	Araq	because noSideEffect currently only says "uses no global"
17:43:34	Araq	and 'nowrite' seems pretty easy to track
17:43:57	zahary	btw, you wanted to be able to overload on whether the param is on the stack or on the heap - string{stack}. you haven't forgotten this idea, right?
17:44:32	Araq	indeed I forgot :-)
17:44:50	zahary	in the C++ papers about effects there were some examples where the user want to override the automatic effect propagation
17:44:57	Araq	well I added an {lvalue} predicate already
17:45:17	Araq	{stack} is impossible because of ptr/var
17:45:36	Araq	but we can easily do {local} # in current stack frame
17:45:37	zahary	for example, he may be calling some function that have side effect only in some of its execution paths and you know they want be entered when you supply certain arguments
17:46:30	zahary	* wont be entered *
17:47:01	Araq	what's the canonical example for that?
17:47:02	zahary	hmm, isn't {local} and {stack} the same?
17:47:20	Araq	no
17:47:36	zahary	let's imagine you're tracking an effect like "allocates memory"
17:47:41	Araq	local is 1 line of code
17:47:54	Araq	stack is impossible and needs sometimes 'unsureAsgnRef'
17:48:07	Araq	which is really annoying btw ;-)
17:48:44	zahary	ah, I didn't mean perfect knowledge - I meant what you mean by local I guess - sometimes you know the value is on the stack
17:50:04	Araq	alright
17:50:29	Araq	I'm adding it now ;-)
17:50:54	zahary	back to "allocates memory" - many functions working with containers will have this effect, but imagine your function requires containers with enough preserved memory - the automatic system will flag the function with "allocates memory", because it used the insert function, but in reality it never allocates
17:51:13	zahary	so the user knows that and manually removes the effect somehow
17:51:19	Araq	I see
17:51:47	Araq	allocators, yeah makes sense, we need to think about these
17:51:59	Araq	constructors are part of the puzzle too:
17:52:05	Araq	var n = newNode()
17:52:11	Araq	n.len = x
17:52:29	Araq	# but: we know 'newNode' cannot alias anything
17:52:44	Araq	so the proc may end up being 'nowrite'
17:52:49	reactormonk	Araq: I tested it a bit.
17:52:58	reactormonk	I'll add a test nontheless
17:53:10	Araq	reactormonk: if you feel like it
17:53:10	reactormonk	what to use for numeric sets?
17:53:25	Araq	TIntSet ?
17:53:34	Araq	dunno if TSet[float] works
17:53:47	Araq	I guess I didn't provide a hash for floats ...
17:53:56	Araq	because it's tricky
17:54:09	Araq	0.0 == -0.0 and stuff like that
17:55:14	Araq	iirc Lua just adds +1.0 to the float to get normalization for 0.0
17:56:04	reactormonk	:D
17:56:08	reactormonk	works.
17:59:03	reactormonk	I suppose I can use a n^2 solution with ~ 10 randoms
17:59:42	Araq	reactormonk: name the test tmath please
17:59:52	reactormonk	aye
18:00:00	Araq	so that we can bloat it up instead of every more tiny files
18:00:13	Araq	*ever
18:02:12	Araq	zahary: I'm a fan of analysis that don't track conditions :-)
18:02:46	Araq	so 'if false: sideEffect()' has a side effect
18:03:02	Araq	otherwise you need dependent typing
18:03:27	Araq	there also was an experiment with "guarded SSA"
18:03:34	Araq	in an oberon compiler
18:03:49	Araq	and the author later admitted that it didn't buy much
18:04:10	zahary	well ok, my point was that the user has the ability to explicitly override the effects that the automatic analysis will assign
18:04:13	Araq	and it was quite a burden to always have the guards around
18:04:44	reactormonk	Araq: btw, is there no better way to initialize to RNG than the current time?
18:05:18	zahary	I imagined that in the IDE the effects could appear as labels next to the proc so the user can instantly say "hey, this effect shouldn't be here"
18:06:00	Araq	well some {.force: noSideEffect.} would be nice, yeah
18:06:24	zahary	two ways to control it was suggested in the C++ paper
18:06:48	zahary	one is just like you said - you set the final effect directly to the whole proc
18:07:17	zahary	the other method is to set the effect of specific expression inside the proc and the rest of the proc is analysed normally
18:08:00	Araq	reactormonk: current time is the best way I think
18:08:30	Araq	mongo uses current time + unique counter + random value to generate a GUID
18:08:49	Araq	and random value is initialized with the current time
18:09:05	Araq	zahary: ok, we already have expr{.pragma.} syntactically
18:09:14	Araq	but it's not used yet
18:09:52	zahary	can I use when inside pragmas btw?
18:10:13	Araq	well you made 'when' an expression
18:10:14	zahary	{.when foo: pragmaFoo else: pragmaBar .}
18:10:25	zahary	so it will work probably?
18:10:31	Araq	hrm
18:10:34	Araq	I guess not
18:10:48	Araq	but you can do:
18:10:51	Araq	when foo:
18:11:02	Araq	{.pragma p: foo.}
18:11:04	Araq	else:
18:11:11	Araq	{.pragma p: bar.}
18:11:27	Araq	er, it's {.pragma: p, bar.} I think
18:11:36	zahary	yeah, I got it
18:12:23	Araq	the key:value syntax for pragmas looks nice
18:12:38	Araq	but a better way would have been to just use 'expr' instead inside them
18:12:57	Araq	and {.importc("name").} would have been bearable too
18:13:57	Araq	but it's not too late to support that
18:14:47	reactormonk	Araq: add a unique counter?
18:15:13	Araq	yeah and 'unique == thread local counter' in this case
18:15:51	Araq	which doesn't make much sense but I guess they feared data races
18:16:40	Araq	er, no, I'm wrong
18:16:52	Araq	they use a global and 'atomicInc'
18:18:11	reactormonk	yeah, that sounds better
18:19:04	Araq	see lib/pure/oids.nim
18:21:46	Araq	oh and zahary, I think I was wrong about the matrix macros
18:21:53	Araq	you can do:
18:22:14	Araq	macro `+`(x, y: TMatrix): TMatrix
18:22:19	Araq	macro `*`(x, y: TMatrix): TMatrix
18:22:43	Araq	but then you don't know if it's an intermediate result or not
18:23:04	Araq	so you'd need to annotate the result somehow
18:23:13	Araq	and check for that
18:23:23	Araq	but like expression templates
18:23:25	Araq	*much
18:24:46	zahary	what was the thing you were wrong about?
18:25:16	Araq	a few days ago I said you don't need TR macros for that
18:25:32	Araq	which is true
18:25:47	Araq	but I had in mind "and no expression template like stuff either"
18:25:53	zahary	aha, I see
18:26:37	Araq	so
18:26:43	dom96	hrm, I think there needs to be a way to get a plain TSocket using `PAsyncSocket.accept`.
18:27:58	reactormonk	# work around a compiler bug:
18:28:05	reactormonk	still nessecary?
18:28:59	Araq	macro m{x = (`+` | `-` | `*` ){ops} * args}(x: TMatrix, ops: varargs[expr], args: varargs[TMatrix])
18:29:08	dom96	Actually, I can get that behaviour by using the converter.
18:29:31	Araq	zahary: the idea is that 'ops' collects the operators and 'args' the arguments
18:30:08	Araq	so that within the macro you don't have to re-extract these things
18:30:16	zahary	sounds great - are we there yet?
18:30:41	Araq	the {ops} * args needs to be implemented
18:30:53	Araq	it's a special case
18:31:19	*	Araq left #nimrod (#nimrod)
18:31:33	*	Araq joined #nimrod
18:31:49	Araq	but the rest works good enough I think
18:34:05	zahary	btw I was going to suggest to refactor the term rewriting bits in a way that I will be able to call them as magics - (i.e. apply this set of rules to this PNimrodNode and return me the transformed result)
18:35:06	Araq	yeah I thought the same :D
18:35:17	Araq	it's really useful within a macro too
18:37:24	Araq	there is a serious problem with AST overloading btw:
18:37:41	Araq	proc p(x: expr{noSideEffect})
18:37:48	Araq	if we allow for that
18:37:59	Araq	we need to check if 'x' has no side effects
18:38:26	Araq	which currently works decently because we have likely seen x's body already
18:38:44	Araq	but with unrestricted forwarding this turns into a nightmare
18:39:34	Araq	an effect system is only bearable if the inference engine works good enough
18:39:49	Araq	I don't want to annotate every proc with these things
18:41:05	Araq	the constraint {noSideEffect} for a TR macro does not have that problem as they come later in the compilation pipeline
18:43:11	zahary	what do you mean by forwarding here?
18:43:37	Araq	no need for forward declarations like in Java/C# etc.
18:44:01	zahary	ok, I thought so
18:44:39	zahary	can't the compilation be depth-first?
18:45:51	Araq	well yeah but I don't really like it and sometimes you simply have to give up:
18:45:53	zahary	I start from the main proc and analyse and compile each proc that I see (this is the second pass after the declarations of all functions have been seen)
18:46:13	Araq	proc p(x: type(q))
18:46:17	Araq	proc q(x: type(p))
18:47:24	zahary	:)
18:47:36	zahary	well, that's an error I guess
18:47:48	Araq	well it frightens me
18:48:29	Araq	error message may become very hard to follow
18:48:39	Araq	because soon enough it's too complex
18:48:51	Araq	and the compiler takes a "random" path through your module
18:49:02	Araq	oh wait, through your "package"
18:49:10	Araq	because we want recursive module deps too
18:51:12	zahary	what could go wrong :)
18:51:29	zahary	brb
18:51:41	Araq	nah, see you later ;-)
19:36:00	reactormonk	var unique_counter: cint = 0
19:36:02	reactormonk	proc randomize() =
19:36:04	reactormonk	atomicInc(unique_counter)
19:36:06	reactormonk	gives me
19:36:08	reactormonk	lib/pure/math.nim(195, 28) Error: for a 'var' type a variable needs to be passed
19:40:28	reactormonk	.... that's the atomicInt line
20:19:56	Araq	reactormonk: a 'cint' type converts to 'int'
20:20:11	Araq	which is what atomicInc expects
20:20:20	Araq	but that doesn't work for 'var int'
20:25:16	Araq	zahary: thinking about it some more
20:25:41	Araq	the bottom up pass for tr macros is crap:
20:25:55	Araq	template t{x = a + b * c} ...
20:26:06	Araq	template t2{a + b * c} ...
20:26:23	Araq	you want the longest rule to match
20:26:46	Araq	but due to the bottom up pass it will trigger a + b * c
20:27:00	Araq	and then the macro transforms that into something like:
20:27:18	Araq	for i: tmp[i] = a[i] + b[i] * c[i]
20:27:33	Araq	and then you'd need to match against *that* in 't'
20:29:08	Araq	this stuff really needs to be done in a new top down pass ...
20:29:47	Araq	'semExpr' is the wrong place, especially since it doesn't enable proxies anyway
20:41:34	reactormonk	Araq: hmm, cast the counter to a cint then?
20:42:54	reactormonk	gettime(null) + cast[cint]uniqueCounter ?
20:50:06	Araq	make uniqueCounter an int
20:50:16	Araq	and convert it to cint later
20:50:31	Araq	but don't 'cast'
20:50:37	Araq	cint(uniqueCounter)
20:51:24	reactormonk	... I really need to tinker with nimrod-mode
20:51:58	reactormonk	why does
20:52:01	reactormonk	randomize
20:52:03	reactormonk	set.incl random(max(int))
20:52:05	reactormonk	give me
20:52:12	reactormonk	tests/run/tmath.nim(9, 15) Error: 'randomize' cannot be passed to a procvar
20:52:15	reactormonk	tests/run/tmath.nim(9, 15) Error: 'randomize' cannot be passed to a procvar
20:52:43	Araq	randomize() # can't leave out the () for nullary procs
20:53:17	fowl	nullary proc?
20:53:27	Araq	a proc with 0 parameters?
20:53:32	fowl	ah
20:54:10	reactormonk	http://pastie.org/private/pnb0er6w6bbj4zrebvhvw gives me http://sprunge.us/MUdI
20:55:20	Araq	wow
20:55:27	Araq	that's pretty weird, hm?
20:57:23	fowl	are you writing unittest?
20:57:39	reactormonk	fowl: yep
20:58:01	fowl	cool
20:58:22	reactormonk	Araq: nope, it's not
20:58:24	reactormonk	max(int)
20:58:37	Araq	yeah, I figured
20:58:42	Araq	try high(int)
20:58:51	reactormonk	can't we merge those two?
20:59:15	Araq	can't you just learn the fucking language instead? :P
20:59:50	Araq	it's already full of overloads and complexity :P
21:00:11	reactormonk	imo max(int) is simpler than high(int)
21:00:21	Araq	max(2, 3) == 3
21:00:54	Araq	but indeed it can be overloaded to do what you want
21:00:59	reactormonk	max(<type>) should basically be high(<type>)
21:01:50	reactormonk	brb, gotta move out of this building - why the hell is it always freakking cold within buildings
21:02:02	Araq	are you in a church?
21:11:04	reactormonk	nope, just a regular restaurant in austin
21:11:16	reactormonk	it's ~ 30 outside and felt 15 inside
21:11:50	Araq	texas?
21:12:33	reactormonk	yes, indeed
21:15:58	reactormonk	is there a literal for TSlice btw?
21:16:44	reactormonk	lib/system.nim(1261, 36) Error: ambiguous call; both system.max(x: varargs[T]): T and tmath.max(x: varargs[TSet[int]]): TSet[int] match for: (TSet[int], TSet[int])
21:16:47	reactormonk	what to do about that?
21:17:01	reactormonk	imo the right one should match, as it's more specific
21:18:02	reactormonk	err, wait, where is the second one coming from
21:18:37	Araq	a..b : TSlice[T]
21:18:56	Araq	1..2 --> TSlice[int]
21:19:22	fowl	reactormonk: you use celsius but your in texas?
21:20:13	Araq	and yeah I never find the time to implement that 'most specific generic' overload resolution rule
21:20:26	reactormonk	fowl: I use celsius because farenheit is a scale invented by a self-centric scientist who took what he assumed was the lowest temperature as 0 and 100 as his body temperature
21:21:03	reactormonk	sss
21:21:58	Araq	did you implement '<' for TSet?
21:22:26	reactormonk	nope
21:22:41	Araq	why do you have a 'max' for TSet then?
21:22:51	reactormonk	no idea
21:22:53	reactormonk	http://sprunge.us/UEVK
21:25:01	Araq	sigh
21:25:14	Araq	well there is no 'max' for TSet
21:25:26	Araq	dunno why the compiler thinks there is such a thing
21:26:06	Araq	just use an accumulator in the loop
21:36:35	reactormonk	... yep. http://sprunge.us/bRCg
21:37:01	reactormonk	no floaty keys
21:39:55	Araq	proc hash(x: float): THash {.inline.} = result = cast[ptr THash](addr(x+1.0))[]
21:40:06	Araq	oh lol
21:40:15	Araq	var y = x + 1.0
21:40:20	Araq	addr(y)
21:40:42	Araq	can't take address of a + expression ;-)
21:41:19	reactormonk	what about > a bit more coercing? 1 > 1.0 fails the typecheck atm
21:44:08	Araq	really? I thought it would work with int literals now
21:44:11	Araq	...
21:44:38	fowl	>>> 1 > 1.0
21:44:39	fowl	false
21:45:09	reactormonk	check rand < 1000
21:45:15	reactormonk	lib/pure/unittest.nim(118, 24) Error: type mismatch: got (float, int)
21:45:27	reactormonk	Araq: feel free to pull
21:46:43	Araq	reactormonk: 1 > 1.0 works for me
21:46:57	Araq	and 1 == 1.0 is even true
21:51:23	reactormonk	hum
21:52:11	Araq	do you use 0.8.14 or 0.8.15?
21:53:34	reactormonk	master
21:54:20	Araq	hm
22:01:55	Araq	reactormonk: but it's supposed to only work for int *literals*
22:02:09	Araq	maybe you tested it with something else?
22:03:56	reactormonk	see above, <float var> > 1
22:12:05	Araq	got (float, int)
22:12:07	Araq	not
22:12:15	Araq	(float, int literal(1000))
22:12:29	Araq	so the 'check' macro messes things up, I guess :P
22:18:11	reactormonk	oh
22:18:32	reactormonk	let's blame zahary?
22:19:52	Araq	;-)
22:21:38	reactormonk	anyway, https://github.com/Araq/Nimrod/pull/196
22:23:17	Araq	er, why do we need uniqueCounter?
22:23:27	reactormonk	try without
22:23:37	Araq	nah just tell me
22:23:52	reactormonk	let's see if we really need it
22:24:14	Araq	nah, just remove it
22:24:16	Araq	in fact
22:24:20	Araq	you should do:
22:24:22	reactormonk	well, the basic problem is that if you call randomize() more than once in a second...
22:24:35	Araq	let x = gettime(nil)
22:24:44	Araq	srand(x)
22:24:52	Araq	srand48(x)
22:25:49	Araq	and what's wrong with the old 'proc random(max: int): int = return int(rand()) mod max'
22:25:51	Araq	?
22:26:04	Araq	what if the cpu only has FP emulation?
22:26:37	Araq	random(max: float) is fine, but keep the random(max: int) the way it is please
22:26:53	reactormonk	I only changed return <foo> to result = <foo>
22:27:19	Araq	no
22:28:19	Araq	oh
22:28:23	Araq	you're right
22:28:25	Araq	strange
22:28:29	Araq	alright then
22:28:48	reactormonk	and I moved the doc out of the when
22:29:13	Araq	but JS doesn't have these
22:29:26	Araq	and the docgen does the right thing anyway
22:29:48	reactormonk	if it gets more intelligent, when might be relevant
22:30:09	Araq	doc2 is more intelligent
22:30:13	Araq	btw
22:30:17	reactormonk	nice
22:30:30	Araq	but fine, I'll pull
22:31:28	Araq	why an issue?
22:31:43	Araq	oh well fine
22:31:54	reactormonk	so stuff doesn't get lost
22:33:26	reactormonk	I hope the tmath.nim works
22:34:38	Araq	don't worry
22:34:51	Araq	currently we have quite some tests failing
22:34:55	Araq	and severe other bugs
22:36:47	reactormonk	^^
22:36:57	reactormonk	well, I imported unittest and that's it...
22:50:06	Araq	well thanks for your work and good night
22:56:14	*	q66 quit (Quit: Quit)