<<13-08-2012>>
00:10:14reactormonkapriori__: eeeeh, what do you want to do?
00:15:42apriori__say I just want to offset a pointer
00:20:07*silven quit (Ping timeout: 240 seconds)
00:39:10*apriori__ quit (Quit: Konversation terminated!)
01:18:39*apriori_ quit (Quit: Konversation terminated!)
02:19:11*q66 quit (Quit: Quit)
08:47:30*silven joined #nimrod
09:07:23*dom96_ joined #nimrod
09:28:14*q66 joined #nimrod
10:17:56*Boscop quit (Ping timeout: 252 seconds)
10:29:26*Trix[a]r_za is now known as Trixar_za
10:47:26*Araq_ joined #nimrod
10:47:57*zahary joined #nimrod
10:49:12Araq_oh hi zahary
10:50:26zaharyhi
10:51:09zaharywhat's up? I'm catching up with the logs
10:51:44Araq_dunno, I'm almost done with the closures ...
10:51:56Araq_transf is not a pass anymore
10:52:06dom96_hello
10:52:19Araq_took much longer than I expected as always
10:52:40zaharytransf is merged into sem?
10:52:55Araq_and we really need to do something about "Koenig's lookup"
10:53:22Araq_zahary: more or less, yes
10:54:23zaharynice to see that def support is improving. I'll try to add the latest idetools goodies to the vim plugin
10:54:43Araq_great but it's still too slow
10:55:31Araq_about the koenig's lookup: I really want to disallow locals overriding in generics
10:55:44Araq_I had a typo in sets.nim
10:55:53Araq_where the proc used a non-existing 't'
10:56:08Araq_and in the test case it used 't' and so the test worked
10:56:18Araq_that's really bad ...
10:56:46Araq_hi dom96_
10:56:58zaharydistinct types should be the recommended way to do this imo
10:57:12zaharybut errors when conflict is detected is surely nice
11:00:47Araq_at least unknown identifiers should be detected in generics
11:01:15Araq_though it can be useful if you merely postulate that a %& operator exists ... hm
11:03:14zaharywhat was the typo again? I didn't quite follow
11:03:51Araq_I've implemented your idea to make semBorrow use overloading resolution and it works nicely :-)
11:05:23zaharyI saw the log already :)
11:05:50zaharynow we need my other borrowAll idea
11:09:06Araq_first class iterators are almost implemented too
11:09:13Araq_but I have problems with their design
11:09:30Araq_iterator it(): int =
11:09:32Araq_ yield 1
11:09:34Araq_ yield 2
11:09:36Araq_ yield 3
11:09:46Araq_echo it() # 1
11:09:50Araq_echo it() # 1 or 2 ?
11:10:06Araq_in other words when is the closure created?
11:10:29Araq_(the closure contains the state field too)
11:10:59fowlAraq: it() twice should create two iterators
11:11:06Araq_when you do:
11:11:10Araq_let x = it
11:11:14Araq_echo x() # 1
11:11:17Araq_echo x() # 2
11:11:45Araq_because every lexical occurance of 'it' creates a new closure
11:11:57Araq_but that's not intuitive
11:12:28*Araq_ quit (Read error: Connection timed out)
11:13:33*Araq_ joined #nimrod
11:13:40Araq_I played with IEnumerable[T] and C#'s design but it's hard to do it and not introduce indirect/virtual calls at the same time
11:13:58zaharywell, I think the return value should be a object with getValue hasMore and moveNext methods
11:15:25zaharywith type inference it's not necessary to have virtual calls, because the user usually won't specify the type?
11:15:42zaharyso you can infer the concrete type and eliminate virtual calls
11:16:16Araq_perhaps, but that the hasNext/next way is completely alien to the way iterators work today
11:17:26zaharyI guess the current inlining method of implementing iterators is nicer most of the time
11:17:56zaharyonly when the user explicitly assigns the iterator value to local variable, the more expensive Iterator[T] approach should be used
11:22:46Araq_well in my current design there are two types of iterators: 1. closure based and 2. inlining based (current implementation)
11:23:11Araq_for (1) there are restrictions with 'try' but it allows for parallel iteration
11:23:19Araq_( for x in a(), y in b() )
11:24:43Araq_and (2) allows for 'try' but cannot be used in a parallel for loop
11:25:03Araq_both don't support recursion
11:25:13Araq_it's quite messy
11:25:57Araq_and of course (2) leads to code bloat but that can be prevented by clever implementations
11:30:37fowlfor x in a(), y in b(x) ? :)
11:30:59zaharyI understand the differences in what's possible and allowed, but I think over time we will eliminate most of the restrictions.
11:30:59zaharyif you say var it = someIterator() you get the Iterator[T] object. in parallel iterations, the compiler writes the parallel loops using Iterator[T] objects, recursive iterators in for loops may be handled with the loop-body-as-a-implicit-closure-param method
11:31:02fowlnvm i guess that doesnt make sense lol
11:33:53Araq_we could also reconsider an implicit conversion from IEnumerable[T] to seq[T] and be done with it ;-)
11:34:25zaharyI don't quite like such methods requiring implicit allocations and copies
11:35:36Araq_nor do I
11:35:59Araq_but I'll explore this idea further anyway as it supports recursion ;-)
11:36:52Araq_and the people who use take(30).filter().map() tend to not care about efficiency anyway
11:37:12zaharywhy doesn't the current Iterator[T] approach handle recursion btw?
11:37:18Araq_they simply want expressiveness and nimrod is not on par with other languages in this respect
11:37:30zaharyit should albeit inefficiently
11:38:55zaharythe "infinite iterator" is also a potentially good feature that doesn't fly with seq[T]
11:39:42zaharytake(30) is an example of a lazy iterator, which will be hurt too
11:41:29Araq_sure
11:42:15Araq_you're right it may handle recursion inefficiently
11:42:54Araq_I never think about it, it's a joke IMHO; exponential complexity for traversing a tree
11:43:17Araq_iirc?
11:45:07zaharyyeah
12:06:36Araq_i have to go, see you later
12:06:40*Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347])
12:44:11*Trixar_za is now known as Trix[a]r_za
14:39:22*comex quit (*.net *.split)
14:44:57*comex joined #nimrod
14:51:13*JStoker quit (Excess Flood)
15:05:05*JStoker joined #nimrod
15:06:29*Boscop joined #nimrod
15:25:36Boscopping Araq
15:39:16*Boscop quit (Disconnected by services)
15:39:17*Boscop joined #nimrod
15:45:59*shevy quit (Ping timeout: 268 seconds)
15:51:38*Boscop quit (Disconnected by services)
15:51:40*Boscop joined #nimrod
15:58:28*shevy joined #nimrod
16:11:03*Boscop quit (Ping timeout: 276 seconds)
16:14:22*Boscop joined #nimrod
16:28:49*Boscop quit (Ping timeout: 265 seconds)
16:38:38*zahary quit (Read error: No route to host)
16:38:45*zahary joined #nimrod
16:59:44Araqback
17:01:37shevytop
17:11:22Araqso ...
17:11:33AraqI also plan to make 'final' the default for objects
17:11:55Araqif you want inheritable objects inherit from TObject or use a pragma
17:12:03Araqopinions?
17:24:54fowlwhy
17:24:55dom96hrm.
17:25:08dom96Yeah, what fowl asked.
17:25:28Araqbecause it's the proper default
17:25:42Araqyou can't just inherit from an object that has not been designed for it anyway
17:26:04Araqand the shorter syntax should be the more efficient syntax
17:26:24dom96That makes sense yes.
17:27:21Araqcurrently 'type MyObject = object' means "inheritable, but not compatible to TObject"
17:27:32Araqthis doesn't make much sense ...
17:31:22dom96It's a bit strange though that inheriting from TObject makes the object inheritable.
17:31:27dom96Might confuse people
17:31:34Araqlol why?
17:31:57AmrykidTInheritableObject ftw
17:32:01*Amrykid hides
17:32:12AraqAmrykid: that's what TObject is all about
17:32:25AraqTInheritableObject == TObject
17:32:29dom96type MyObject = inheritable object
17:32:31dom96:P
17:32:52Amrykidtype MyObject = inherits object?
17:33:02Araqtype MyObject = inheritable object of TObject ?
17:33:18Amrykidtype inheritable MyObject?
17:33:31Araqno new keyword for it
17:33:42Araqand it's not a question of syntax anyway
17:34:07Araqthe question is "should an object inheriting from something be inheritable by default?"
17:36:50Araqand I think the question should be answered with "yes"
17:37:01Amrykidyes.
17:37:04Araqwhich is also much nicer for backwards compatibility
17:37:22Amrykidbut how would you specify if it shouldn't be inheritable?
17:37:36Araq{.final.} like today
17:37:47Amrykidah
17:38:05Araqhrm my closure changes broke quite some tests ...
17:38:21dom96huh? Won't {.final.} become obsolete?
17:38:27fowli dont get it araq
17:38:33fowldid you just change your mind?
17:38:40Araqno
17:38:46Araqnot at all
17:39:03fowlah ok i re-read
17:39:09Araqtype o = object # implicitely 'final' (new behaviour)
17:39:26Araqtype o = object of whatever # implicitely not final (like today)
18:18:21fowlpadded str and length-encoded str for streams.nim: https://gist.github.com/3342882
18:19:37Araqnice
18:19:46Araq s.write(str & repeatChar(length - str.len, padChar)) # make it more efficient :P
18:20:16fowlthe assertion on line 39 fails.. ends up with 14 \0s at the end..?
18:21:50fowlim not sure how to efficiently repeat a char >_>
18:22:17AraqrepeatChar is not bad, but you can get rid of the &
18:22:36Araq s.write(str); s.write(repeatChar(length - str.len, padChar))
18:23:10AraqI don't know why the assertion on line 39 fails
18:24:01Araqand use 'doAssert' instead of 'assert' in tests within 'when isMainModule' so that they are not deactivated in release mode
18:25:24fowli see
18:27:26Araqresult = result.substr(0, lastChr) # --> setLen(result, lastChr+1)
18:28:06Araqwhy is length an int16?
18:30:12fowlsounded good at the time
19:01:28fowlAraq: what would you use, int8?
19:12:23Araqfowl: int32
19:13:00fowlno string needs to be that long
19:13:21Araqwhy not?
19:15:14Araq32K isn't that much ...
19:39:13fowlwell i was thinking more for sockets
19:40:35AraqI see
19:40:48Araqbut you should make it int32 ;-)
19:44:38fowlstrings longer than high(int16) should be shot!
19:45:39fowlill just make it generic
19:46:10shevyhmm
19:46:14shevyI think I asked this before
19:46:28shevywhen I have nimrod available locally, is there a way to have it fetch latest aporia somehow and install it?
19:46:40shevyI am so lazy :(
19:48:16fowlmake a recipe for it
19:48:39Araqdom96 is working on babel, Nimrod's package manager
19:48:48Araqwell not really
19:48:52Araqbut it exists ;-)
19:54:24shevydom96!!!
19:56:57Araqshevy: don't update the nimrod compiler please, I broke methods and closures :P
19:59:40shevyhehe
20:06:57dom96shevy!!!
21:27:09*Trix[a]r_za is now known as Trixar_za
22:31:12Araq100% again :P
22:31:16Araqand I'm off
22:31:18Araqgood night
22:31:54dom96yeah, me too
22:33:17Trixar_zaNight Araq and dom96
22:33:18Trixar_za:P
22:37:03*Nafai quit (Quit: WeeChat 0.3.7)