<< 21-11-2013 >>

---

00:07:17	*	brson joined #nimrod
00:10:13	C0C0	anyone interessted in a mersen twister implementation (I heard there was some critic on the defulat rng a while ago)?
00:12:35	*	webskipper joined #nimrod
00:13:30	*	webskipper quit (Client Quit)
00:30:48	*	xenagi joined #nimrod
00:39:34	Varriount	C0C0, interested as in, to code, or interested as in, to use/include?
00:58:05	Varriount	Araq, will the new VM fix any bugs with generic creation/instantiation?
01:03:01	*	BitPuffin quit (Ping timeout: 248 seconds)
01:42:42	*	NimBot joined #nimrod
01:45:31	mkb	d/w 3
01:50:41	*	familiar125 joined #nimrod
01:51:46	*	DAddYE quit (Remote host closed the connection)
02:04:32	*	brson quit (Quit: leaving)
02:04:46	*	brson joined #nimrod
02:15:02	*	brson quit (Ping timeout: 248 seconds)
02:28:28	*	brson joined #nimrod
02:31:48	*	comex quit (Ping timeout: 245 seconds)
02:50:13	*	brson quit (Ping timeout: 248 seconds)
03:02:42	*	DAddYE joined #nimrod
03:07:05	*	DAddYE quit (Ping timeout: 252 seconds)
03:26:26	*	DAddYE joined #nimrod
03:30:51	*	DAddYE quit (Ping timeout: 246 seconds)
03:45:02	*	brson joined #nimrod
03:49:25	*	brson quit (Ping timeout: 248 seconds)
03:52:20	*	DAddYE joined #nimrod
03:52:38	*	DAddYE quit (Remote host closed the connection)
03:52:44	*	DAddYE joined #nimrod
04:07:06	*	brson joined #nimrod
04:30:06	*	brson quit (Ping timeout: 265 seconds)
04:35:42	*	xenagi quit (Quit: Leaving)
04:35:58	*	xenagi joined #nimrod
05:00:54	*	OrionPK quit (Quit: Leaving)
05:04:29	*	XAMPP quit (Quit: Drink all the Booze; Hack all the Things; Kill all the Humans;)
05:23:41	*	xenagi quit (Quit: Leaving)
05:28:46	*	familiar125 quit (Read error: Connection reset by peer)
05:35:04	*	XAMPP joined #nimrod
06:13:58	*	Jackneill joined #nimrod
07:19:05	*	shodan45 quit (Quit: Konversation terminated!)
07:34:05	*	silven quit (Read error: Operation timed out)
07:52:34	*	silven joined #nimrod
07:57:46	*	silven quit (Ping timeout: 246 seconds)
08:00:42	*	silven joined #nimrod
08:18:51	*	anton2 joined #nimrod
08:43:33	*	anton2 quit (Quit: anton2)
09:22:02	C0C0	Varriount: as in "to use/include"
09:22:42	C0C0	just wrote it for myself, and read something bout missing rngs some time ago
09:35:27	*	CarpNet joined #nimrod
09:37:34	*	silven quit (Ping timeout: 272 seconds)
09:41:01	*	zahary_ joined #nimrod
10:44:29	Araq	Varriount: no
10:51:02	zahary_	Araq, it's embarrassing to admit, but today I read the first-class iterator docs for the first time and the design seems wrong to me
10:52:36	zahary_	I think we've discussed this before, but there are really two "types of iterators" - the first one is an iterator function that can have arbitrary parameters and it will produce "an iteration / coroutine".
10:52:57	Araq	we talked a lot about this design
10:53:05	zahary_	i.e. this is the current type iterator (x: foo, y: bar): baz
10:53:34	zahary_	the second type is the "iteration" itself - this is the thing that has finished(); resume(), etc procs
10:54:33	zahary_	in the simple case it have a type like Coroutine[T] (Iterator[T]); (you just call it without argument to get the next value)
10:54:37	Araq	to produce an iterator you simply close over the variables you want to iterate over and let the closure escape
10:55:08	Araq	I still think my design is very natural and consistent with other first class functions
10:55:14	Araq	but bbl
10:55:21	zahary_	in some languages like lua, it can accept values at each step; then it's something like Coroutine[X, Y, Ret]
10:55:46	zahary_	well, I'm pretty sure we've discussed this indeed and I think I must have made the same points then
10:59:32	zahary_	can you clarify the runTasks example in the manual; why do I pass the ticker argument on each step? and what actually results from this? the captured value in the iterator closure is changed that way?
10:59:51	zahary_	http://build.nimrod-code.org/docs/manual.html#first-class-iterators
11:24:06	Araq	no the "ticker" is just a dummy argument in that example :-)
11:25:26	zahary_	but it must be supplied I guess (that's what the closure expect)?
11:25:47	Araq	no, iterator a1(): void would be perfectly fine
11:26:02	Araq	but then TTask must be iterator() of course
11:26:18	Araq	the real problem with my design is the "finished" built-in. It's very hard to make that perform like people expect.
11:26:43	Araq	often it only returns true the 2nd time it's finished
11:26:54	Araq	the following illustrates the problem:
11:26:59	Araq	iterator (): int =
11:27:03	Araq	yield 1
11:27:08	Araq	discard
11:27:27	Araq	it yields 1 but then it's not finished
11:27:34	Araq	because it has yet to run the 'discard'
11:29:00	zahary_	the problem is that a real similar task system will have functions with different parameters producing tasks, but once the task is produced, it can be handled with the same interface no matter the factory/producing function
11:29:24	Araq	but that's not a problem because you can do:
11:29:46	Araq	proc produce(): iterator (): int = captureThings() ...
11:29:54	Araq	proc produce2(): iterator (): int = captureDifferentThings() ...
11:32:30	zahary_	well, then the current iterators are equivalent to the Iterator[T]/Couroutine[T] that I described, bust I think most people confuse them with the "factory" type
11:33:23	zahary_	I guess the full code is like this
11:33:23	zahary_	proc foo: iterator(): int =
11:33:23	zahary_	iterator x: int {.closure.} =
11:33:23	zahary_	capture stuff
11:33:23	zahary_	return x
11:34:01	Araq	yes
11:34:31	Araq	and yeah it means people will expect anonymous iterators to work ...
11:35:11	zahary_	I guess this confusion comes form the fact that the non-closure iterators behave like the "factory" type
11:35:49	Araq	I don't think they do.
11:36:00	Araq	in fact now I need to think why you think they do
11:36:02	zahary_	because, there you can have the arbitrary input parameters and the body will return the equivalent of iterator(): X (for the purposes of the loop)
11:36:03	Araq	;-)
11:36:26	zahary_	it erases the input parameters so to speak
11:38:24	Araq	for i in iter(a, b) # input arguments are passed every time to 'iter'
11:38:38	*	BitPuffin joined #nimrod
11:39:05	Araq	or perhaps: let x = a; for i in iter(x) but still they are not erased
11:39:48	zahary_	they shouldn't be; if you ask me what is the abstract type of iterating over a collection (doesn't matter if this is array, list, etc); the answer is iterator(): ElementType
11:39:56	BitPuffin	good * guys!
11:40:23	zahary_	I can have many factory functions such as items(array), items(seq), every_odd_element(list)
11:40:52	Araq	so for you iterator(): ElementType is IEnumerable<ElemenType> ?
11:40:53	zahary_	the all produce itearator(): ElementType
11:41:01	zahary_	yes
11:41:04	Araq	aha
11:41:55	*	BitPuffi1 joined #nimrod
11:42:13	zahary_	now you should see why this is what the for loop consumes (sans the inlining)
11:42:24	*	BitPuffin quit (Read error: Connection reset by peer)
11:42:40	zahary_	and how nonclosure iterators act as a factory for such Enumerable objects
11:42:43	*	BitPuffi1 is now known as BitPuffin
11:42:45	Araq	indeed this is where Nimrod and C# differ: C# has a special "lazy return type" (IEnumerable) whereas Nimrod conflates the laziness with the function kind
11:43:20	zahary_	but nimrod has it too in the form of closure iterators
11:46:13	Araq	for me iterator (): T {.closure.} is quite different from IEnumerable<T> conceptually. But I can see your point. They are the same for you.
11:47:15	zahary_	and my point is that nonclosure iterators are different than closure iterators in the way they encode the "creation of the iteration"
11:47:35	zahary_	if I wish to refactor a non-closure iterator into a closure one, I have to wrap it up in a proc
11:48:02	Araq	depends on your exact refactoring. otherwise you simply have to add {.closure.}
11:48:38	zahary_	I challenge you to give me example where this would work
11:49:02	Araq	iterator split ... {.inline.} = ...
11:49:13	zahary_	so this produces words
11:49:24	Araq	proc takeIt(it: iterator (): string)
11:49:27	zahary_	the correct signature is itearator(): string
11:49:30	Araq	takeIt(split) # gah
11:49:43	Araq	--> make split a .closure and it compiles
11:49:48	zahary_	but the split iterator was defined iterator(x: string): string
11:50:04	Araq	good point
11:50:20	Araq	proc takeIt(it: iterator (input: string): string) is unnatural I guess
11:50:26	zahary_	it will be like this in every example
11:51:53	zahary_	I'm ok with the current design, but I guess it's not explained very well
11:52:08	Araq	ok but if iterator (): T is IEnumerable<T> what is iterator (a: S): T?
11:52:23	Araq	(both iterator headers are .closure here)
11:52:31	zahary_	this is the coroutine that takes arguments on every step
11:52:57	Araq	yeah but now you see why it's different
11:52:58	zahary_	imagine a mud game; the iterator walks though rooms and ask you for a next step
11:53:35	Araq	Func<Input, IEnumerable<Output>> is iterator (Input): Output. perhaps.
11:53:53	zahary_	nope, the factories can have arbitrary arguments
11:54:27	zahary_	that's why you should not try to consider them in the "type of the iteration"
11:54:47	Araq	well it's your turn then. What is iterator (x: Input): Output {.closure.} in C#?
11:55:14	zahary_	C# doesn't have these I guess (co-routines?)
11:55:22	zahary_	I mentioned lua as an example for this
11:55:44	zahary_	http://www.lua.org/pil/9.1.html
11:55:53	zahary_	notice how the resume function can have arguments
11:56:01	zahary_	then, within the iterator the syntax is like this
11:56:08	zahary_	var next_step = yield(room)
11:56:37	zahary_	you have two-way communication - the iterator yields rooms, the user supplies the next step
11:59:26	Araq	ok well more interesting for me is this:
11:59:29	Araq	coroutine.resume(co) --> co 10
11:59:31	Araq	coroutine.resume(co) -- prints nothing
11:59:32	Araq	During the last call to resume, the coroutine body finished the loop and then returned, so the coroutine is dead now.
12:00:04	Araq	so it's dead AFTER an additional "print nothing"
12:00:39	Araq	so it has the same issue as my system.finished
12:00:55	zahary_	so you wander how the last value is consumed/signaled?
12:01:34	Araq	no I wonder whether somebody came up with a better solution or if it's inherent
12:03:08	zahary_	well, I remember we discussed this as well
12:03:35	Araq	and you're right Func<Input, IEnumerable<Output>> is different from the iterator
12:04:11	zahary_	what was going to happen when I try to call the iterator after it has produced the last value (it still runs its epilogue code, then what?)
12:04:34	Araq	it produces default(T) aka binary zero
12:04:46	Araq	iirc
12:05:11	Araq	in fact, I let the implementation decide
12:05:36	zahary_	there is some magic that let you set the default value?
12:06:02	Araq	you can invoke iter() as often as you like even when finished() returns true
12:06:43	zahary_	yeah, but how the user know that this last zero it got is not an actual value
12:10:22	Araq	well finished returns true after the last value has been read
12:11:32	Araq	well let me fix some iterator related bugs and I can give you better answers
12:12:10	zahary_	so you know to ignore the last value you got just before finished? having a magic to set the "EOF value" could be useful - it will allow loops without `finished` in them
12:12:33	Araq	finished is very cheap though
12:12:47	Araq	no indirect function call and it only reads the internal 'state' field
12:12:57	Araq	which is always at offset 0
12:13:07	zahary_	sure, but it more cumbersome to write my code
12:13:12	Araq	ah ok
12:13:18	Araq	that's a different issue then
12:13:56	zahary_	I'm splitting words and putting each word in a seq; I hit finished and now I must know to remove the last word (that was empty or something)
12:14:22	Araq	no you don't
12:14:37	Araq	while not finished(it): echo it()
12:14:48	Araq	is the 'for' loop replacement iirc
12:15:18	zahary_	but the last call ot it() will return the default zero value
12:15:25	Araq	for i in it(): echo i # translates into the above 'while'
12:15:53	Araq	well ... I don't remember
12:15:58	Araq	let me look at the implementation again
12:16:01	zahary_	we are talking about closure operators here (splitting words is not a good example)
12:16:05	zahary_	it's easier to have while (word = next(); word.not_empty): words.add(word)
12:16:49	zahary_	otherwise, I should have while not finished(it): words.add(it()); now after the loop; words.erase_last()
12:17:45	Araq	ah well apparently it's:
12:17:50	Araq	while true:
12:17:55	Araq	let x = it()
12:18:01	Araq	if finished(it): break
12:18:14	Araq	so you're right but the loop is still simple *cough*
12:18:38	Araq	in a way you get (next, finished) = it()
12:18:49	zahary_	but it's not finished if it still needs to do something in the iterator
12:18:52	Araq	and should not look at 'next' if finished == true
12:19:29	zahary_	iterator foo =
12:19:29	zahary_	yield 1
12:19:29	zahary_	yield 2
12:19:29	zahary_	print "exiting"
12:19:29	zahary_	doSomethingImportant()
12:21:17	Araq	actually the major gripe I have with my design is that the state machine algorithm is too useful to attach it to heap allocated closures only. And even escape analysis doesn't help. When you don't have closures but explicit memory management you can easily put them into arrays etc. All these things are lost with closures.
12:22:06	Araq	also serialization of a closure requires some magic
12:23:03	Araq	your iterator foo is arguably bad style. it's easy enough to "yield -1" at the end and tell people it's another way to determine if it finished
12:23:19	zahary_	hmm
12:23:36	Araq	the sentinel version is easy enough to provide if you want to and have a value that can act as such
12:23:45	*	BitPuffin quit (Ping timeout: 272 seconds)
12:23:47	zahary_	maybe you have a point, since I'm suggesting a magic that will require a similar line
12:24:54	zahary_	but is the compiler otherwise smart enough to notice that yield is the last statement and to populate finished for me properly?
12:25:28	zahary_	that's quite nice if it's true
12:26:21	zahary_	e.g. the last yield automatically sets "finished" as well if the compiler sees that nothing further interesting is going to happen
12:27:19	Araq	that's what I planned to implement, in fact
12:27:28	Araq	but it changes semantics subtly
12:27:42	Araq	arguably it changes it for the better though
12:28:02	zahary_	it seems hard to do considering that the exit is usually going to happen due to some loop exit branch
12:28:35	Araq	yeah it's only easy to come up with heuristics
12:29:26	Araq	I need to go, see you later
12:29:31	zahary_	bye
12:42:20	*	BitPuffin joined #nimrod
12:47:59	*	zahary_ left #nimrod (#nimrod)
13:12:25	*	BitPuffin quit (Read error: Operation timed out)
13:12:28	*	BitPuffi1 joined #nimrod
13:16:41	BitPuffi1	Araq: me and my friend might be doing this 64k thing, is there a way to get the space usage down to as low as C? :P
13:16:49	BitPuffi1	otherwise we're gonna have to use C :P
13:19:19	*	zahary_ joined #nimrod
13:28:22	*	EXetoC joined #nimrod
14:07:33	*	BitPuffi1 is now known as BitPuffin
14:21:37	Varriount	Hm. Anyone know how to reset your forum account's password?
14:22:32	Varriount	BitPuffin, -> http://forum.nimrod-code.org/t/301
14:26:09	BitPuffin	Varriount: hmm?
14:29:40	BitPuffin	Varriount: I am not sure if I like the blending of parameters and parameter types
14:32:29	Varriount	BitPuffin, parameters and parameter types can already be blended. :/
14:32:30	*	OrionPK joined #nimrod
14:34:02	BitPuffin	say you'd want something like this: proc foo[T, S, P](a: T[S], b: T[P]), that'd become proc foo(T: typedesc, S: typedesc, P: typedesc, a: T[S], b: T[P])
14:34:03	Varriount	BitPuffin, "proc foo(T: typedesc, obj:T): T" is a perfectly valid function.
14:34:14	BitPuffin	Varriount: oh
14:34:18	BitPuffin	well that's a shame xD
14:34:22	BitPuffin	but yeah
14:34:25	BitPuffin	I missed his point
14:34:31	BitPuffin	he wants partial function application
14:34:32	Varriount	BitPuffin, I'm not suggesting that generic *declaration* syntax change
14:34:38	Varriount	Also, that user is me.
14:34:48	Varriount	I forgot my forum password.
14:35:03	BitPuffin	ah
14:35:05	BitPuffin	haha
14:35:07	BitPuffin	:P
14:35:29	BitPuffin	I'm not sure the genericProc[int, 20] syntax makes much sense
14:35:50	BitPuffin	that bleeds together the parameters and generic parameters
14:35:50	Varriount	That's merely an example case
14:35:53	BitPuffin	yeah
14:36:27	OrionPK	what kind of db does the forum use?
14:37:18	BitPuffin	OrionPK: sqlite
14:37:27	BitPuffin	the sauce is on github
14:37:37	OrionPK	yeah I know
14:37:42	OrionPK	just curious if anyone knew off hand
14:37:58	BitPuffin	Varriount: you forgot to elaborate on type parameters
14:38:03	BitPuffin	"while procedures with type parameters (which is why iterators with typedesc parameters hardly work, if at all)."
14:38:17	BitPuffin	while procedures with type parameters what :P
14:38:28	Varriount	Ah, sorry
14:38:32	BitPuffin	OrionPK: alright :)
14:38:41	BitPuffin	OrionPK: why are you wondering? :P
14:38:42	Varriount	I wrote all this on my phone at 12:00 pm
14:38:55	BitPuffin	It's cool, just thought it'd be helpful to point it out
14:38:58	OrionPK	bitpuffin curiosity :P
14:39:24	BitPuffin	OrionPK: something that is urgent imo to fix about nimforum is the pw hashing
14:39:42	OrionPK	whats wrong w/ it?
14:39:47	BitPuffin	OrionPK: it uses md5
14:39:58	OrionPK	you would have to reset everyone's password to fix that
14:40:04	BitPuffin	not really
14:40:07	BitPuffin	just rehash the hash
14:40:24	OrionPK	i guess that would work heh
14:40:40	BitPuffin	if they have stored the information lke you should where you prefix with what algo it is it's fine
14:40:46	OrionPK	sha1 isnt really that secure either though
14:41:01	BitPuffin	if not well then they should first update the db to have that info
14:41:10	BitPuffin	OrionPK: hell no I'm not suggesting sha1
14:41:16	OrionPK	okay lol :p
14:41:24	BitPuffin	OrionPK: https://bitbucket.org/BitPuffin/scrypt.nim
14:41:28	BitPuffin	although that's not done yet
14:42:48	BitPuffin	it doesn't know how to check yet
14:42:53	BitPuffin	but damn it I think I implemented that
14:42:56	BitPuffin	just that I lost the data xD
14:42:59	BitPuffin	because i didn't push
14:44:14	*	comex joined #nimrod
14:50:04	BitPuffin	OrionPK: I'm actually debating whether sha1 is secure enough for h-macs even
14:50:21	BitPuffin	maybe I should scrypt that too
14:50:28	BitPuffin	just that verifying cookies happen a lot
14:51:23	EXetoC	newException(EIo, "oh no") I think it's pretty clear. it's more limited though, but it's concise
14:52:22	BitPuffin	EXetoC: lol wut
14:52:49	EXetoC	typedesc
14:53:25	BitPuffin	EXetoC: ah
14:53:34	BitPuffin	sure it is clear
14:53:42	BitPuffin	But I dunno
14:53:53	BitPuffin	newException[EIo]("oh no") is even more clear
14:53:55	BitPuffin	:P
14:54:11	BitPuffin	because let's not forget that we also parameterize types with []
14:54:31	BitPuffin	so we become familiar with the fact that generic params are within []
14:57:38	*	Kristina_ joined #nimrod
14:57:50	*	Kristina_ is now known as Kristina
15:02:24	EXetoC	I'm used to both
15:04:23	BitPuffin	EXetoC: sure but consistency has value
15:04:47	BitPuffin	Which is why I try to follow nimrod naming conventions
15:04:51	BitPuffin	not because I agree with it
15:05:01	BitPuffin	and not only because Araq will send an assassin otherwise
15:05:08	BitPuffin	but just because it benefits everyone :P
15:12:04	*	olahol quit (Quit: Lost terminal)
15:14:49	EXetoC	I guess
15:20:21	*	q66 quit (Ping timeout: 246 seconds)
15:22:37	*	q66 joined #nimrod
15:23:32	EXetoC	Araq: will users always be required to handle input contracts manually? because it might be a good idea to implicitly raise EAssertionFailed by default
15:26:20	EXetoC	but it might not be so bad to just do it manually by wrapping said function
15:27:50	BitPuffin	can't you make a proc raise an exception by default?
15:28:21	BitPuffin	yeah
15:28:25	BitPuffin	you should be able to
15:28:32	BitPuffin	so pull request EXetoC
15:28:34	BitPuffin	:P
15:29:48	*	DAddYE quit (Remote host closed the connection)
15:29:54	EXetoC	such contracts haven't even been implemented yet
15:30:16	*	DAddYE joined #nimrod
15:30:19	EXetoC	if ever, but it seems useful
15:31:25	EXetoC	proc f(x: int) {.in: x < 10.} something like this
15:32:39	EXetoC	where the contract is supposed to be validated at compile-time according to Araq (with conditional statements), in case you missed that discussion
15:35:02	*	DAddYE quit (Ping timeout: 272 seconds)
15:38:10	EXetoC	procs cannot actually be members of a type, so I wonder if it'll be feasible to have type-wide contracts
15:39:02	BitPuffin	EXetoC: gotcha
15:39:11	BitPuffin	it would be useful both at compile time and runtime
15:39:12	EXetoC	or maybe explicit is better than implicit in this case: proc f(x: TFoo) {.in: fooInvariant(x).}
15:39:43	BitPuffin	EXetoC: it doesn't even seem hard to do
15:39:47	BitPuffin	EXetoC: just write a module
15:39:49	BitPuffin	call it contracts
15:39:57	BitPuffin	make macro that does the checking
15:40:02	BitPuffin	and then use the macro as a pragma
15:40:04	BitPuffin	???
15:40:06	BitPuffin	profit
15:40:07	EXetoC	that's what I planned to do IIRC
15:40:21	EXetoC	but then it can't be enforced at compile time
15:40:26	BitPuffin	EXetoC: it can
15:40:29	EXetoC	not the way Araq intended anyway
15:40:31	EXetoC	how?
15:40:51	BitPuffin	EXetoC: overloading, for literals etc have one that uses when
15:40:56	BitPuffin	EXetoC: for values use if
15:41:00	BitPuffin	umm
15:41:02	BitPuffin	runtime values
15:41:39	BitPuffin	that should work no?
15:41:45	EXetoC	proc f(x: int) {.in: bla.} ... if (bla): f(42) # Check enforced by compiler
15:42:39	BitPuffin	huh?
15:43:11	EXetoC	oops missed a couple of things
15:44:01	EXetoC	let x = 42; if bla(x): f(x)
15:45:39	BitPuffin	what do you mean if bla?
15:45:47	BitPuffin	is that what it's transformed to
15:48:23	EXetoC	no, user code would be required to perform that check prior to calling the function
15:49:27	EXetoC	and I suggested that maybe EAssertionFailed should be raised implicitly if the user doesn't check the pre-condition and it then happens to fail
15:50:14	BitPuffin	doesn't the user check eliminate the convenience of a contract?
15:53:24	EXetoC	I suppose, but sometimes you want to perform different actions depending on whether not the pre-condition
15:53:25	BitPuffin	maybe I'm confused with what it's supposed to do because I'm tired
15:53:29	EXetoC	and only abort in some cases
15:54:12	EXetoC	I might gist an example later
15:54:58	BitPuffin	sure
15:57:49	*	Varriount wonders when Araq will be up.
16:03:21	EXetoC	if x >= 0: let y = sqrt(x) # Allowed by the compiler .......... let y = sqrt(x) # Should the compilation abort here or should EAssertionFailed be raised implicitly if the pre-condition fails?
16:03:35	EXetoC	BitPuffin: is that clear?
16:04:22	EXetoC	proc sqrt(x: T) {.in: x >= 0.}...
16:06:57	BitPuffin	sec
16:09:14	Varriount	BitPuffin, I've updated the post to better elaborate.
16:09:41	BitPuffin	Varriount: cool!
16:12:10	BitPuffin	EXetoC: abort if value is known at compile time, exception if not
16:12:22	*	OrionPK quit (Quit: Page closed)
16:12:54	*	familiar125 joined #nimrod
16:18:11	*	BitPuffin quit (Ping timeout: 272 seconds)
16:33:01	familiar125	is there a pragma to arbitrarily run cmds at compile time?
16:37:10	dom96	Why a pragma?
16:37:12	dom96	There is staticExec
16:37:22	dom96	also hi
16:40:07	familiar125	hi dom96
16:40:34	familiar125	staticExec, thanks
16:51:53	*	familiar125 quit (Read error: Connection reset by peer)
17:20:53	*	MFlamer joined #nimrod
17:53:30	Varriount	dom96, if you need a documentation builder, I don't mind hosting another build-bot
17:55:57	*	familiar125 joined #nimrod
17:58:25	dom96	Varriount: Thanks but currently there is no code for the upload of the docs so the builder which builds the docs must be local.
18:04:54	*	brson joined #nimrod
18:05:46	*	DAddYE joined #nimrod
18:05:50	*	DAddYE quit (Remote host closed the connection)
18:06:02	*	DAddYE joined #nimrod
18:08:40	*	silven joined #nimrod
18:21:44	*	CarpNet quit (Quit: Leaving)
18:22:05	*	familiar125 quit (Read error: Connection reset by peer)
18:24:56	*	shodan45 joined #nimrod
18:35:32	*	familiar125 joined #nimrod
18:44:47	*	Mat2 joined #nimrod
18:44:50	Mat2	hi all
18:47:28	Araq	EXetoC: compile time evaluation is the whole point, otherwise 'in' can already implemented with a macro that transforms the proc body and inserts an 'assert'
18:47:57	Araq	"emit assert if you can't prove it" is a misfeature
18:48:56	Varriount	Good evening Araq.
18:50:48	*	filwit joined #nimrod
18:51:07	filwit	51 users?
18:51:18	filwit	that a new record, or where we going for 60?
18:51:22	filwit	dom96 ^
18:51:38	dom96	60 is the current record
18:51:42	Varriount	filwit, it fluctuates.
18:51:52	filwit	dom96: when did that happen?
18:52:08	dom96	sometime after my article went live
18:52:13	filwit	nice
18:52:27	Varriount	~45 - ~60
18:52:52	filwit	Varriount: yes, i just meant "most people every here at once"
18:53:08	filwit	dom96: well, 70's the new 40!
18:53:40	filwit	dom96: sounds like articles do a lot for Nimrod's publicity
18:53:54	Mat2	you can bet on it
18:54:43	Varriount	Araq, have you read this proposed idea/concept on the forum? -> http://forum.nimrod-code.org/t/301
18:56:47	filwit	i really don't understand that guys proposal. I'm probably missing some key part of the syntax, but how can (T:typedesc, obj:T) translate into (a, b:T)?
18:57:10	filwit	where did 'aobj' come from in his example?
18:57:20	filwit	objA**
18:57:47	filwit	also, his syntax suggestion for auto-templates would probably only make the code harder to read
18:57:55	filwit	but those are just my thoughts
19:01:39	*	Mat2 I'm not sure if need of the these features are not really fixes for bad code design
19:02:30	*	brson quit (Ping timeout: 272 seconds)
19:03:41	*	brson joined #nimrod
19:03:57	Varriount	filwit, "that guy" is me. Also, I wrote that on my phone, at 12 pm
19:04:00	Varriount	am
19:04:03	Varriount	*am
19:05:15	Varriount	filwit, ok, I fixed that mistake, any others?
19:06:15	MFlamer	I'm confused by the [T] vs. (T: typedesc) in general now. I know zahary was mentioning that [T] is limited in power now and that the other syntax is prefered now?
19:06:51	EXetoC	Araq: right, but I was just thinking of an optional way to have it assert instead, but without having to create an if/else pair every time
19:07:03	Varriount	MFlamer, A generic procedure that uses the [] syntax instead of a typedesc parameter cannot be partially instanciated with just the types.
19:07:17	Varriount	*can be partially instanciated.
19:08:01	MFlamer	ahh, ok
19:08:25	Araq	huh? it can't be partially instantiated either way
19:08:38	EXetoC	Araq: I realize that I'm a little pedantic once again, but perhaps it's doable
19:08:45	Araq	Varriount: I read it but my head is already hurting
19:08:46	EXetoC	we'd need more reflection capabilities though
19:08:52	*	brson quit (Ping timeout: 264 seconds)
19:09:09	Varriount	^ What I get when writing at midnight on a phone
19:09:16	Araq	EXetoC: it's not about whether it's doable, it's about whether it's a good idea
19:09:22	Araq	if you have:
19:09:36	Mat2	Araq: It's not (my opinion)
19:10:03	Araq	proc foo(x: int) {.in: x < 0.} with my proposal guarantees x < 0
19:10:10	Araq	at compile time
19:10:27	Araq	whereas with your way we're back to 'in' being sugar for 'assert'
19:10:28	*	brson joined #nimrod
19:11:01	Araq	and I can't easily see whether the 'in' is proven or not with your proposal
19:15:37	zahary1	well, the hard part is to prove such things, not to choose syntax for the feature
19:16:33	zahary1	Varriount: can you illustrate the problems you are having with typedesc params and iterators with an example?
19:16:50	zahary1	I suspect you're doing something wrong
19:19:44	bastian_	really happy with nimrod so far, great productivity and the generated code looks also great
19:20:24	EXetoC	Araq: no, It'd just be a simple way of saying "just raise EAssertionFailed if the contract fails", and it'd still be self-documenting, though maybe not self-documenting enough according to you
19:20:31	bastian_	Araq: good job!
19:20:54	Araq	EXetoC: well what syntax exactly do you propose?
19:21:00	Araq	bastian_: thank you. :-)
19:22:05	bastian_	any reason why 'var x : seq[uint8] = @[0, 0, 0, ...' won't work, but using '@[0'u8, 0, 0, ...' does?
19:22:13	zahary1	there is little point in putting invariants on procs as these can be replaced with simple assert statements; what's useful is to put invariants on types, then the compiler can insert them automatically on each proc modifying an object of the given type
19:23:01	bastian_	also, found compiler/bitsets.nim
19:23:22	Araq	bastian_: there is a reason. ;-)
19:23:51	Araq	it's not a bug, but perhaps a questionable design
19:24:26	bastian_	not a problem, just thought type inference would pick it up
19:24:45	Araq	that would be non-local type inference
19:24:51	EXetoC	Araq: something like "assert_contract sqrt(x)" maybe, which is a little more compact
19:25:33	*	brson quit (Ping timeout: 272 seconds)
19:25:42	Varriount	zahary1, https://gist.github.com/Varriount/7587953
19:26:13	Araq	zahary1: yeah well but the docgen should look into the proc body and extract the assertions
19:26:20	EXetoC	Araq: but what's wrong with having it raise EAssertionFailed by default? I'm guessing that the whole point of this is to be explicit. can't think of anything else really
19:26:35	Araq	no the whole point is to *prove* things
19:26:48	Araq	EAssertionFailed doesn't prove anything since it's all at runtime
19:27:52	*	brson joined #nimrod
19:27:59	Varriount	zahary1, also, having to either give iterators the same arguments each time they are iterated on is annoying.
19:28:07	zahary1	well, Varriount, did you catch my discussion with Araq earlier today?
19:28:23	Varriount	No...?
19:29:10	Araq	zahary1: I think I already told you, but proving array bounds is within reach with the inference engine
19:29:41	zahary1	http://build.nimrod-code.org/irclogs/21-11-2013.html
19:29:41	zahary1	your iterators are perfect example of the confusion users have regarding the closure iterators
19:30:52	*	brson quit (Client Quit)
19:31:01	Araq	well I'm more concerned about their bugs for now
19:31:07	*	brson joined #nimrod
19:31:38	Araq	I'm not sure they are more confusing than any other design I can come up with ...
19:32:42	Varriount	zahary1, which is?
19:33:57	Varriount	Besides, I still can't use iterators with typedesc parameters, nor can I have iterators that just have to accepts arguments once
19:34:30	zahary1	I left you a comment in the gist
19:34:30	zahary1	https://gist.github.com/Varriount/7587953
19:35:07	zahary1	to understand why this is necessary, you'll have to read through the logs starting from 10:51 today
19:36:13	zahary1	Araq, the design is fine with me - the explanation in the manual is currently lacking
19:38:28	Varriount	Zahary, your example gives me a codegen error.
19:39:37	Araq	zahary1: also the problem we talked about can easily be solved with a builtin setFinished()
19:39:43	Araq	setFinished()
19:39:47	Araq	yield 1
19:39:57	fowl	i dont understand why each time you call the instantiated closure iterator with arguments each time
19:40:04	Araq	# --> no need for generating a sentinel value
19:40:04	zahary1	well, that would be bug, please file it, but still that's the correct way to write the code
19:40:40	Varriount	Also, the example does nothing to bridge the gap between typedesc parameters and generic parameters.
19:41:31	zahary1	well, what is the problem with typedesc parameters? that you cannot "instantiate" the iterator?
19:41:46	Varriount	My main complaint is about the subtle differences between generic parameters (those within []) and typedesc parameters (those within ()).
19:41:48	zahary1	the enclosing proc will have the typedesc parameters and you'll just call it
19:42:21	Varriount	As well as the different situations in which you can/should use them
19:44:21	zahary1	the simple guideline that we should adopt is this: explicitly supplied generic parameters should be used only for types. procs should have inferable generic parameters and explicitly provided typedesc parameters
19:44:51	zahary1	the partial application that you propose in the forum is called "currying"
19:44:52	zahary1	http://en.wikipedia.org/wiki/Currying
19:45:11	EXetoC	Araq: yes, but then the 'if' block isn't entered, but rather the 'else' block which raises EAssertionFailed
19:45:29	EXetoC	so the only difference is that the proof would be hidden behind some generic construct
19:45:35	zahary1	it works the same way for both regular values such as ints and strings and with compile-time values such as types, expressions, etc
19:45:42	EXetoC	similar to just creating wrapper functions, except it would be less tedious
19:46:06	Varriount	zahary1, yes, it is, and I don't see why it's worse than the current generic/typedesc concept.
19:47:16	Varriount	It's an extension of your typedesc idea, allowing such procedures to be partially generated/instantiated.
19:47:49	EXetoC	while still making the intent clear: macro assertContract(x: lazy_call, msg: string) = if magicWayToAccessContract: x() else: assert false, msg
19:48:00	EXetoC	(tons of magic omitted)
19:48:22	Araq	ah alright I see
19:48:43	Araq	well I consider this bad style :P
19:48:56	Varriount	zahary1, and besides, your anonymous iterator idea still requires boilerplate wrapper code.
19:50:11	bastian_	is newSeq zero-initializing the seq?
19:50:20	Araq	bastian_: yes
19:50:24	EXetoC	Araq: yes the point is that it must be proven, but aren't you implying that you think it should be explicit? which seems like a reasonable requirement
19:50:28	Mat2	ciao
19:50:32	*	Mat2 quit (Quit: Verlassend)
19:50:52	zahary1	that's not my idea, but our current design - if you read the logs I mentioned you'll see that I was initially complaining about how confusing it is
19:51:14	Araq	yeah yeah, blame it all on me, I can handle it ;-)
19:51:34	bastian_	Araq: it looked like it, but the docs say " will be filled with uninitialized entries"
19:51:42	Araq	what?
19:51:49	Araq	let me check
19:52:13	bastian_	http://nimrod-code.org/system.html#206
19:52:22	Araq	yeah it's a documentation bug
19:52:46	Araq	what gradha here means it's initialized with 'nil' for strings
19:53:12	zahary1	I like aspects of the design as well - indeed, the symmetry with regular closures is quite nice
19:53:15	bastian_	ah I see, just wasn't sure
19:53:31	EXetoC	but I don't know... in some cases a function might be littered with fairly similar if/else pairs
19:53:46	bastian_	pretty nice it's doing the 'right' thing by default, reduces bugs
19:53:59	bastian_	thanks
19:54:34	EXetoC	so that's roughly 3-4 additional lines for each contract assertion, depending on whether or not a value is returned
19:57:33	Araq	EXetoC: perhaps but come on. that's nothing to worry about *now*
19:57:42	EXetoC	sure
19:57:44	Varriount	zahary1, is 'auto' actually documented anywhere? And by documented, I mean has it's usage explained.
19:59:14	zahary1	auto is a type class matching any type - its usage in this context is explained in the section of the manual called return type inference
20:00:47	Araq	btw zahary1 my final solution is to make 'len' and 'add' check for 'nil' and leave strings and seqs as they are with 'nil' being distinct from "" and @[]. Seems to be the best solution given that "" and @[] allocate which can be costly. Any better ideas?
20:01:27	fowl	Araq, fye on that
20:01:35	fowl	or fie, im not sure which
20:02:01	fowl	the last thing we need is more checks, you already get a backtrace on SEGFAULT, anything more is superfluous
20:04:00	Varriount	zahary1, and what if I wanted to get just the type of a procedure with typedesc params, given concrete type arguments? Is there some equivalent to "var x: genericProc[int, string]"?
20:04:04	EXetoC	Araq: actually, improved statements-as-expressions semantics would improve the situation a little (allowing the ability to throw in some branches while evaluating a value in others).
20:04:23	zahary1	in C++ libraries, I've used a clever trick for empty containers such as seq[T] and string;
20:04:23	zahary1	each string or sequence is just a pointer to a heap allocated buffer of variable length;
20:04:23	zahary1	to represent the empty default value, you prepare a single empty buffer that will be used by all default constructed strings
20:04:23	zahary1	that way, most of the operations won't have any code dealing with the empty case (if empty: allocate ..)
20:04:45	EXetoC	Just saying. I know you said it might be tricky to implement. Doesn't hurt to submit a feature request though (will do that some day)
20:06:10	zahary1	that's because the empty buffer has a capacity and lenght of 0
20:06:10	zahary1	the code for `add` for example does this:
20:06:10	zahary1	newLenght = current (which is 0) + newSuffix.len
20:06:10	zahary1	if newLenght > capacity (which is 0): allocate
20:06:26	zahary1	the same code works when the current length and capacity are not 0
20:06:55	fowl	meh
20:06:59	zahary1	all you have to special case is the destruction in C++ (you have to be careful not to free the empty buffer)
20:07:28	fowl	i'd rather var x: string not nil allocate an empty string and leave normal stuff as it is
20:09:17	Araq	zahary1: I know about this trick but it's not that simple to implement plus it doesn't allow memset()ing the memory for newSeq(s, N)
20:09:23	Varriount	zahary - https://github.com/Araq/Nimrod/issues/683
20:10:07	zahary1	well, your claim is that memsetting to 0 is faster than memsetting to some fixed value
20:10:14	Araq	not quite
20:10:35	Araq	for i in 0..N: s[i] = emptyValue means we incRef emptyValue N times
20:10:57	Araq	unless you introduce a special sticky RC value too
20:11:14	zahary1	ideally, the empty value won't have to be counted
20:12:09	Araq	but even then memsetting to 0 should produce less code
20:12:23	Araq	also tuple[x: int, s: string] get ugly
20:12:30	Araq	x needs to be 0, but s does not
20:13:05	Araq	with 'nil' you can rely on cmov for the overhead to become unnoticable
20:13:06	zahary1	yes, but it's still hard to tell if these drawbacks will offset the benefits
20:13:44	Araq	alright then my argument about the implementation complexity remains :P
20:14:09	zahary1	because you lose just a little bit of the assembly efficiency of memset (although you still touch the same memory) on initialization, but you gain the streamlined code in every other operation
20:14:49	Araq	well thanks to 'cmov' and modern branch prediction I predict my way would win :-)
20:15:25	zahary1	I've tested my way in C++
20:15:37	Araq	yeah but that was years ago :P
20:15:43	zahary1	:)
20:16:42	Araq	and in fact, you chose the same implementation with 'safeAdd'
20:18:02	zahary1	well, can't argue on the easy-to-implement-from-our-current-position factor
20:19:38	Araq	ok so the decision has been made
20:20:08	zahary1	safeAdd still has one semantic difference with the other proposal tho - when you pass a nil string to a proc expecting strings (in order to print them for example), such procs have to deal with the nil case explicitly
20:20:43	zahary1	this is especially true for foreign C procs that are outside our control
20:21:28	Araq	well as I said "" remains different from 'nil' but 'nil' won't bite nearly as often as 'len' returns 0 for it and 'add' can handle it
20:32:14	Varriount	Araq, ever thought of putting "effective obfuscation" as a selling point for nimrod?
20:33:12	*	filwit quit (Ping timeout: 246 seconds)
20:35:22	Araq	Varriount: are you still annoyed by 'proc foo(a, b)' or what are you referring to?
20:35:43	Varriount	Araq, I'm referring to the generated C code.
20:36:32	Araq	well I don't read it often. I don't read the generated asm often either...
20:36:46	Varriount	I'm exploring how the code works, in a vain attempt to fix anonymous iterators, or at least, get a better understanding of nimrod internals.
20:37:01	familiar125	who are you going to be giving the C code to, varriount?
20:37:13	familiar125	you either give them the nim, or you give them the binary
20:37:25	Araq	Varriount: -d:release helps to cut it down
20:38:32	*	BitPuffin joined #nimrod
20:40:31	C0C0	how do I initialize a reference properly?
20:40:45	C0C0	e.G. return new(TSomeThing(x: ..., y: ...))
20:40:50	familiar125	new(varName)
20:40:57	familiar125	you need to declare it ahead of that
20:41:03	Araq	MFlamer: I just got "types and programming languages"
20:41:10	C0C0	and then I have to set the members individually?
20:41:16	Varriount	C0C0, yes.
20:41:21	Araq	nah
20:41:23	fowl	C0C0, if you have a PType for it you can say PType(x: 1, y: 2)
20:41:30	C0C0	ah
20:41:32	C0C0	cool
20:41:41	Varriount	Or create a newType function
20:41:44	Araq	fowl is up to date :-)
20:41:52	C0C0	should have tried that first^^
20:42:04	Varriount	Which is standard operating procedure, at least, as far as the standard library goes.
20:42:12	familiar125	Araq the question is, is it PType(x=1, y=2) or (x:1, y:2) :P
20:42:17	familiar125	Araq god knows I'll never remember
20:42:33	fowl	familiar125, its just like tuple syntax
20:42:57	familiar125	fowl I know, the proc syntax is different
20:43:42	Araq	MFlamer: but I can't do exercise 3.2.5 because it's clearly wrong?
20:43:55	Araq	S1 is not a subset of S2 ...
20:53:02	MFlamer	let me take a look....
20:55:22	C0C0	is there a way to make runtime errors a little more verbose
20:55:38	C0C0	currently I only get the stacktrace but not the error message itself
20:55:59	fowl	--verbosity
20:56:18	MFlamer	Araq: I read that chapter a few nights ago but havent done the exercises yet.
20:56:21	fowl	C0C0, error message will be above the stacktrace
20:58:37	C0C0	aahhh
20:58:48	C0C0	--advanced gives the real --help^^
21:00:36	C0C0	hmm
21:00:39	*	Jackneill quit (Remote host closed the connection)
21:00:59	C0C0	nope that seems to increase the verbosity of the compiler
21:01:04	C0C0	but not of the program itself
21:01:50	*	brson quit (Quit: leaving)
21:02:06	*	brson joined #nimrod
21:02:33	fowl	C0C0, the error is above the stacktrace
21:02:42	C0C0	nope
21:02:43	C0C0	just
21:02:44	fowl	C0C0, that's all i can tell you without seeing the output myself
21:02:53	C0C0	TRaceback (most recent call last)
21:03:14	C0C0	and then the callstack file(line) functionname
21:07:02	C0C0	ah if i run it in bash it prints SIGSEGV Illegal storage access. (Attempt to read from nil?)
21:07:16	C0C0	seems my prompt swallowed that part (below the stacktrace)
21:07:59	Varriount	Araq, do you prefer that enum fields be camelCase, or PascalCase?
21:08:54	Varriount	C0C0, that attempt to read from nil *is* the error message
21:09:31	C0C0	yeah its always there with bash, but my zsh prompt somehow fucked it up
21:09:38	Varriount	Usually it means that the program tried accessing an object or tuple field that either didn't exist, or was set to nil
21:09:57	Varriount	Sometimes its a variable, though not often.
21:10:12	C0C0	allready fixed that bug
21:10:20	C0C0	thx ^^
21:10:39	C0C0	attempt to read from nil + line is a pretty decent error message^^
21:10:54	fowl	beats C
21:11:08	C0C0	sure enough
21:11:10	fowl	oh you got a null pointer? better open gdb
21:11:21	fowl	<- no idea how to gdb
21:11:26	C0C0	^^
21:11:31	C0C0	don't use gdb
21:11:36	Varriount	<- theoretical idea how to gdb
21:11:39	C0C0	always use valgrind etc
21:14:45	*	familiar125 quit (Read error: Connection reset by peer)
21:15:41	*	OrionPK joined #nimrod
21:18:32	MFlamer	Araq: "{pred t1....}" implies the set terms apply to the predecessor also, if we look at 3.2.1 (2) dosent this imply the cumulativity of the sets? Also, look at the second half of the 3.2.3 definition, has the sum right there
21:22:18	MFlamer	actually, the second half is refering to S being the sum of subsets, so, I'm wrong above
21:23:02	MFlamer	I was thinking it was Si
21:25:08	MFlamer	I agree it's not really clear why it's cumulative. The next few paragraphs are comparing the 2 methods of definition, maybe the reason is burried there
21:27:10	MFlamer	Araq: you still around?
21:29:40	C0C0	is there a nice way to echo a pointer that might be nil?
21:30:12	fowl	C0C0, repr()
21:30:55	C0C0	ah
21:30:58	C0C0	thx :)
21:31:29	fowl	C0C0, any more tips will cost $1 a piece
21:31:46	C0C0	payable in?
21:31:56	fowl	BTC is acceptable
21:32:56	C0C0	if I was sitting on a stash of bitcoins I wouldn't be sitting on a stash of bitcoins after they went up to 800$^^
21:33:34	fowl	just this week i've watched it go up and down from 500-800-500-650-500 and now its at 700 again
21:33:47	fowl	kicking myself for not buying them years ago for pennies
21:33:54	C0C0	same here
21:34:42	fowl	C0C0, lets start a website on tor where we offer illegal services then ignore the people who pay us
21:35:23	C0C0	fowl: well we should deliver for the first few weeks
21:35:24	Araq	MFlamer: I'm back and I now think it's correct :-) but surely subtle
21:35:49	fowl	C0C0, deliver them to the FBI maybe
21:36:00	fowl	(not the bitcoins, the patrons)
21:36:07	C0C0	hehe
21:36:27	C0C0	are you hoping the FBI is paying you with the confiscated bitcoins from silkroad
21:36:40	C0C0	(also: german here, FBI would be the wrong juristdiction)
21:37:36	fowl	well ok then the kriminalprosekutung or whatever sie kerle have
21:37:42	Araq	oh btw guys, nimrod-lang.org is now available
21:37:44	C0C0	^^
21:38:01	C0C0	fowl: Bundeskriminalamt
21:38:54	fowl	bitcoinen
21:39:05	fowl	or is it bitkeunen?
21:39:13	C0C0	but they would probably imprisson you for possesion of "Hackerwerkzeuge"
21:41:19	fowl	for using Tor?
21:41:49	C0C0	fowl: there is the "hackerparagraph" which makes posession of "Hackerwerkzeuge" illegal
21:41:56	C0C0	but its unclear what hackertools are
21:42:28	C0C0	recently some idiot politician came up with the idea to make Tor "meldepflichtig"
21:42:50	fowl	i'm sure if you said you're protecting yourself from the NSA they would verstehen
21:42:53	C0C0	meldepflichtig = you have to tell the government you are using it and for waht
21:45:54	mkb	can you say you're protecting yourself from the BND?
21:46:08	C0C0	mkb nope
21:46:09	dom96	Araq: Does nimrod-lang.org work for you on its own now?
21:46:16	C0C0	the BND is not even allowed to spy on germans
21:46:24	C0C0	thats the job of the verfassungsschutz
21:46:39	mkb	and the NSA is not even allowed to spy on americans
21:46:39	mkb	oh
21:47:04	C0C0	^^
21:47:05	C0C0	yeah
21:48:18	mkb	from wikipedia: main concerns of the BfV are ... scientology
21:48:24	C0C0	^^
21:48:24	mkb	the NSA would do well to copy them
21:48:27	Araq	dom96: yeah
21:49:21	dom96	Araq: ok, in that case I will make nimrod-code.org redirect to nimrod-lang.org
21:49:59	C0C0	mkb and making leftwing women pregnant for additional cover^^
21:50:19	Araq	dom96: alright thanks
21:50:30	mkb	dom96, www.nimrod-lang.org redirects to your blog..
21:50:48	Araq	damn mkb is right. wtf.
21:51:36	dom96	Araq: you set up the redirect incorrectly.
21:52:29	dom96	s/178.79.158.152/http://nimrod-lang.org/
22:01:51	OrionPK	www isnt set up properly
22:01:57	OrionPK	but nimrod-lang.org is fine
22:02:50	Araq	dunno what you mean. www.nimrod-lang.org is just fine :P
22:03:06	OrionPK	lol
22:03:13	OrionPK	302 = the devil
22:03:28	OrionPK	or 301, whichever you're using
22:04:36	Araq	I thought it's easier this way for google
22:04:57	dom96	I think it is.
22:06:16	OrionPK	dark theme, woo! https://dl.dropboxusercontent.com/u/417554/familiar-dark.png
22:06:58	dom96	OrionPK: omg open source this sexiness already
22:07:37	OrionPK	dom96 as soon as httpserver doesnt need my ugly hacky patch to work with asyncio :P
22:07:59	fowl	OrionPK, do you use the 'Rod for JS also
22:08:10	OrionPK	btw, if you have a phone.. it works really well
22:08:12	OrionPK	no, typescript
22:08:21	fowl	ewwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww
22:08:25	Araq	gah, use my JS backend ...
22:08:32	OrionPK	:P
22:08:59	OrionPK	fowl once I open source it, you guys will be free to submit a pull request that changes it to the nimrod js backend :P
22:09:19	OrionPK	Im not a believer in compile to JS though
22:09:29	fowl	typescript compiles to js
22:09:32	OrionPK	especially since the JS code is ~15 kb before gzip right now
22:09:50	OrionPK	fowl only sort of
22:13:23	Araq	OrionPK: what? "only sort of"?
22:13:46	Araq	because IE will get a specialized VM for it and every other browser will not?
22:13:49	OrionPK	I mean you can plop javascript into a ts file and run it through tsc and it produces the same output
22:13:58	OrionPK	thats not going to happen
22:14:07	OrionPK	you're thinking of dart :p
22:14:18	Araq	I said IE
22:14:22	OrionPK	I know you did
22:14:46	OrionPK	why would microsoft do that after investing so much into chakra & running JS as "native" apps for windows 8?
22:15:41	Araq	because ms is a big company and managers don't communicate
22:15:57	OrionPK	typescript is much more 1:1 with javascript, the output is very similar to the input so debugging w/ f12 tools is much easier
22:16:31	OrionPK	Araq they're pretty heavily invested in JS, and NOT very invested in typescript
22:16:40	*	brson quit (Ping timeout: 245 seconds)
22:20:03	MFlamer	Araq: I need to generate the C source for a type. I see alot of useful procs in ccgtypes.nim but not sure if there is a main entry point for this topic, do you have any suggestions? If not, I'll figure it out
22:21:02	*	brson joined #nimrod
22:21:33	Araq	MFlamer: getTypeDesc()
22:22:40	MFlamer	great, thanks.
22:23:43	Araq	and seriously
22:24:18	Araq	S1 contains (succ 0)
22:24:33	Araq	S2 can only contain (succ succ 0)
22:25:33	Araq	gah but 0 is always in Si
22:25:55	Araq	never mind then
22:26:43	MFlamer	Where do I get this BModule?
22:27:07	MFlamer	I got a BProc
22:27:20	OrionPK	Araq u get a chance to look at 681?
22:27:40	Araq	p.module
22:29:18	MFlamer	got it
22:30:02	dom96	Let me know if some of the redirects fail.
22:32:28	*	Associat0r joined #nimrod
22:33:31	Araq	OrionPK: well it's a bug
22:34:34	Araq	the issue is that nimrod knows range[0..23] - 12 produces range[-12..11] and for some reason demands val12.hour falls into this range
22:34:54	dom96	Now keep attention to reddit because this is an excuse for someone to resubmit a link to Nimrod's homepage
22:35:22	dom96	Araq: Update the url on github
22:38:48	Araq	done
22:39:06	dom96	and in the readme too :P
22:39:32	Araq	that's your job
22:44:12	dom96	Should the nimrod-code organisation on github stay as it is?
22:44:35	Araq	I don't know what a name change implies
22:45:37	dom96	"We will create redirects for your repositories (web and git access)."
22:45:43	dom96	"You will need to update your local repositories to point to the new location."
22:45:49	dom96	Sounds like more bother than it's worth
22:45:55	Araq	yeah
22:46:56	NimBot	Araq/Nimrod master 43e2c29 Dominik Picheta [+0 ±2 -0]: Modified website links in readme.
22:54:09	*	OrionPK quit (Read error: Connection reset by peer)
22:59:56	MFlamer	Error: type mismatch: got (string, PRope) for `&`
23:00:26	Araq	the compiler's ropes are archaic
23:00:31	MFlamer	Do I have to qualify operators or something? ropes is imported
23:00:51	Araq	it's been translated from pascal which doesn't know about cross module overloading
23:01:09	Araq	so ... instead of 'add' and '&' there is 'app' and 'con'
23:01:24	MFlamer	ok, I was using those before, no biggie
23:01:43	Araq	well we should change it eventually
23:02:15	Araq	but then I dislike patches affecting 4000 lines of code that do nothing
23:02:27	fowl	http://9gag.com/gag/aG9pXZG
23:03:14	fowl	Araq, it doesnt have to all change at once
23:03:41	Araq	fowl: but then new people need to look at both anyway
23:04:15	Araq	and need to know about the old stuff
23:04:33	Araq	my time is better spent fixing bugs instead
23:06:54	C0C0	is `if x != nil:` or the alternativ `if not x.isNil:` considered better style?
23:07:07	fowl	not x.isNil
23:07:34	C0C0	thx :)
23:08:17	*	DAddYE quit (Remote host closed the connection)
23:10:29	*	DAddYE joined #nimrod
23:13:07	Araq	Varriount: enum field should be camelCase. everything should be camelCase except types which should be PascalCase. that's what we decided iirc
23:18:09	Varriount	Araq, the forum post says camelCase or PascalCase
23:20:26	*	OrionPK joined #nimrod
23:23:24	Araq	well the forum post is old
23:29:30	fowl	in a world, where style doesn't matter...
23:30:13	MFlamer	sweet, as a learning exercice, I have added a pragma that allows you to specify a type for enum variants. The enum can then act as a sum ptr. https://gist.github.com/mflamer/7591727
23:33:04	fowl	i dont get it
23:33:47	Araq	MFlamer: impressive
23:34:10	MFlamer	thanks master
23:35:18	MFlamer	It allows you to use our enums like a haskell ADT. When I add field access etc. it will be much clearer.
23:37:42	Varriount	MFlamer, can you explain what you did exactly?
23:39:10	MFlamer	the machinery was already present in the parser for an additional token representing either the ord value for the enum variant and/or the string representation
23:39:35	MFlamer	I extended it a little to also accept a type
23:39:51	Varriount	And do... what with the type?
23:40:39	MFlamer	Just keep it in the AST for type checking later or casting
23:41:56	MFlamer	there is room in an enum of 4 or less variants(32bit 8 for 64bit) for a ptr
23:43:06	*	filwit joined #nimrod
23:43:29	MFlamer	so you can keep a pointer and its type in an enum which is 1 word
23:43:30	Varriount	MFlamer, just make sure to also produce some tests, so that I can test the machinery on Windows and it's wierd memory sizes.
23:44:09	MFlamer	sure, for larger enums, I'm going to just use another word
23:45:06	MFlamer	but I am also on windows, btw
23:45:37	Varriount	Oh, I didn't know. Are you also using both 32 and 64 bit compilers?
23:45:40	fowl	MFlamer, dont forget there is also {.size.} for enums
23:46:37	MFlamer	fowl: I'll have to take a look, I forget what that does now
23:48:40	Varriount	Araq, the compiler also uses lambda lifting for actual inner functions, right? Not just ones directly attached to a variable?
23:51:23	MFlamer	fowl: {.size.} is a pragma?
23:51:35	fowl	{.size: someSizeInBytes.}
23:53:00	fowl	lol
23:53:05	fowl	i cant find any documentation of it
23:53:20	MFlamer	I see it in the compiler,
23:53:37	Araq	Varriount: yes
23:53:46	MFlamer	pragmas.nim
23:54:12	Varriount	Araq, does the compiler have any logic in place to lift iterators?
23:54:43	MFlamer	ok, well if that sets the size of the enum representation, I'll have to limit that when used with my pragma
23:55:38	Araq	Varriount: yeah but there 2 very different implementations
23:55:45	Araq	one that inlines iterators
23:55:57	Araq	and one that produces a state machine from an iterator
23:56:00	*	familiar125 joined #nimrod
23:56:04	Araq	for obvious reasons
23:56:29	fowl	MFlamer, its mainly used in c wrappers where the size of enum should be sizeof(cint)
23:57:32	MFlamer	ok, I am actually forcing the size to a word already, so shouldnt be a problem. Thanks for the heads up
23:57:57	*	brson quit (Ping timeout: 248 seconds)
23:59:53	*	brson joined #nimrod