<<10-09-2012>>
01:05:52*XAMPP quit (Read error: Connection reset by peer)
08:27:07*zahary joined #nimrod
13:47:36*q66 joined #nimrod
14:51:35*XAMPP joined #nimrod
14:57:42*XAMPP quit (Read error: Connection reset by peer)
15:00:10reactormonkAraq: playing alpha centauri :-)
15:16:42*zahary quit (Quit: Leaving.)
15:26:55*Guest69842 joined #nimrod
15:32:21*Guest69842 quit (Quit: Leaving)
15:32:43*XAMPP_ joined #nimrod
15:45:25*XAMPP_ quit (Quit: Leaving)
15:54:19Araqping reactormonk
15:55:54reactormonkyep?
15:56:05Araqgood taste btw
15:56:13Araqalpha centauri is great
15:56:21reactormonknow to get it running on my netbook
15:56:26AraqI thought you could work on floating point checks
15:56:34reactormonkstandard difficultiy is booring
15:56:40reactormonkthat is?
15:57:12Araqwell we already have NaN and INF checks
15:57:25Araqbut only for basic builtins like + and *
15:57:33Araqwe need these for math.sin etc.
15:57:37reactormonkwould you know where to read up on image matching? We have to read a paper on SIFT, but I have no clue of image matching at all...
15:57:56Araqme neither, sorry
15:58:35reactormonkproc `*` *(x, y: float): float {.magic: "MulF64", noSideEffect.}
15:58:38reactormonkhuh?
15:59:33reactormonkwhere is that stuff? So I can see how NaN/INF is done
16:00:01reactormonkand I suppose they need to be able to be disabled
16:02:10Araqreactormonk: it's in the codegen
16:03:18Araqccgexprs.binaryFloatArith
16:05:02reactormonkwhich file?
16:05:13Araqccgexprs.nim
16:05:33reactormonkin compiler/ - $PWD was in lib/ :-/
16:05:44Araqyeah
16:06:04Araqwe need some other way to deal with this
16:06:27Araqwe need a 'guard' proc that performs the requested checks
16:06:47reactormonkhuh?
16:06:51reactormonk http://sprunge.us/fDRI <- found this
16:07:20Araqyeah that's what I'm talking about
16:09:50Araqwell for a start somebody needs to check which compilers support C99's fpclassify()
16:11:39Araqin fact, tr macros can be used to inject the code with the guard
16:14:44Araqbut hm, apparently visual c++ now has fpclassify :-)
16:15:28reactormonkwhat's that "guard" you wish implemented?
16:16:27Araqsomething that merges nanCheck() and infCheck()
16:16:39Araqboth to be found in lib/system/arithm.nim btw
16:17:37reactormonkproc infCheck(x: float64) {.compilerProc, inline.} =
16:17:40reactormonk if x != 0.0 and x*0.5 == x: raiseFloatOverflow(x)
16:17:49reactormonk... compile-time check for something better?
16:18:12Araqcan't be checked at compile-time
16:18:50reactormonkisNaN n stuff?
16:19:14AraqINF / INF == NaN iirc
16:19:35Araqwe need something like:
16:20:16Araqtype FPGuardFlag = enum checkInf, checkNan, checkSubnormal
16:20:36Araqproc floatGuard(x: float64, checks: set[FPGuardFlag]) {.compilerproc, inline.} =
16:21:02Araq if checkInf in checks: noInf(x)
16:21:11Araq if checkNan in checks: noNan(x)
16:21:25Araq if checkSubnormal in checks: noSubnormal(x)
16:22:02Araqand noInf, noNaN, noSubnormal raise the proper exceptions should 'x' fail the test
16:23:09*shevy quit (Ping timeout: 252 seconds)
16:23:15Araqwell the real implementation should be more efficient and only call fpclassify() once
16:24:07reactormonkFPGuardFlag looks global to me
16:24:26reactormonkwell, semi-global as in lisp? :-)
16:25:26Araqwhat's semi-global in lisp?
16:29:37Araqbut then again the whole feature can now be implemented as a library ;-)
16:30:12Araqtemplate floatCheck*{x}(x: float{call}): expr =
16:30:18Araq let y = x
16:30:40Araq floatGuard(y)
16:30:42Araq y
16:31:56reactormonkAraq: (let (*semi-global* "foo") ... further code with *semi-global* set to something else ... )
16:32:20reactormonkwhy call it floatGuard and not floatCheck?
16:32:42Araq*shrug*, call it floatCheck then
16:33:06Araqwell the template should be called floatGuard
16:33:40Araqsemi-global sounds like overriding something in system.nim
16:33:57Araqbtw nimrod now has a hygienic macro system :P
16:35:32reactormonk\o/
16:35:41*shevy joined #nimrod
16:36:31reactormonkwhere should the code go?
16:36:44reactormonkarithm.nim ?
16:36:50Araqyeah
16:38:22Araqfowl: overloading of templates works for me
16:38:38Araqwithout any bugfixes
16:40:37reactormonkAraq: need a fallback for fbclassify?
16:41:19Araqdon't think so
16:41:24Araqeven visual c++ has it now
16:46:44fowlAraq: ah, works for me too ._.
16:51:20*XAMPP joined #nimrod
16:51:20*XAMPP quit (Changing host)
16:51:20*XAMPP joined #nimrod
17:10:29*XAMPP quit (Quit: Leaving)
17:10:50*XAMPP joined #nimrod
17:10:50*XAMPP quit (Changing host)
17:10:50*XAMPP joined #nimrod
17:11:17*apriori_ joined #nimrod
17:11:22apriori_hi guys
17:11:34apriori_is there a reason why low, high and len dont work on tuples?
17:11:54apriori_I mean, sure its always low = 0 and high = len-1.. but I cant call those functions with a tuple
17:13:44reactormonkgo ask Araq
17:14:09apriori_Araq: ? :)
17:14:33Araqnever occured to me they would be useful for tuples
17:14:41apriori_why not?
17:14:46Araqas tup[idx] only works if idx is a constant value
17:14:56apriori_oh
17:15:12Araqyou can use system.fields to iterate over the fields, but it creates a 'fake' loop
17:15:25apriori_ok
17:16:31apriori_thank you
17:26:15Araqapriori_: use array[0..2, float] instead of tuple[x,y,z: float] to get a[i]
17:26:27Araqwith a variable 'i'
17:27:44apriori_Araq: yeah, I figured..
17:27:59apriori_but I would really prefer both: index based access and .fieldname based
17:29:13Araqyou can define accessors for the the array, but hm yeah
17:29:29Araqyou use freebsd, right?
17:29:35apriori_currently on arch linux
17:29:38apriori_freebsd is on my laptop
17:29:39Araqcan you help this guy: http://forum.nimrod-code.org/t/69
17:29:40Araq?
17:29:51apriori_yeah
17:31:00apriori_huh
17:31:11apriori_well.. I could run nimrod on both, freebsd and pcbsd
17:31:24apriori_juding by his uname -a that's pcbsd (which is like > 95% freebsd)
17:35:29Araqapriori_: check out the new TR macros
17:35:44Araqthey allow operator overloading on steriods
17:35:45apriori_got no idea what that is ;)
17:35:59apriori_where can I find the docs?
17:36:08Araqit's especially designed for matrix operations
17:36:09apriori_are these only in github right now?
17:36:22Araqyeah, well
17:36:30Araqin ten minutes nimbuild will have built the docs
17:36:38Araqand I'll post a link :D
17:36:42apriori_good ;)
17:36:43apriori_thank you
17:37:08apriori_are tr macros unique to nimrod or is that some established name for something?
17:37:44Araqterm rewriting is established
17:37:50Araqbut nimrod's implementation is unique
17:38:25Araqafaik no other language has ever supported term rewriting with side effect and alias analysis
17:38:40apriori_okay
17:39:05apriori_now I'm quite curious ;)
17:45:22Araqugh, nimbuild failed :-/
17:46:17apriori_oops ;)
17:48:19dom96Araq: Docs get generated after testing :P
17:48:42Araqwell gc.html does not exist either
17:52:02dom96trmacros does now
17:52:44Araqhttp://build.nimrod-code.org/docs/trmacros.html, there you go, apriori_
17:52:57apriori_Araq: on it ;)
17:55:57reactormonkAraq: got alpha centauri working on my laptop... but the fonts suck balls.
17:56:46Araqdoes that mean you have plenty of time for nimrod now?
17:57:08reactormonknah, shower & lecture now
17:58:01apriori_Araq: pretty much what I once wanted..
17:58:13apriori_this should make writing code converters much easier
18:02:29Araqnot only code converters
18:03:06Araqbignums and matrixes can be implemented as efficient as if they would have been built-in
18:06:55apriori_user defined constrains would be insane
18:07:11apriori_those would allow such operations to be implemented in a more "high level" way
18:07:16Araqwhat do you have in mind?
18:07:31apriori_currently you check e.g. whether something is an alias, macro etc..
18:07:59apriori_what about a user defined check, whether e.g. the type of A is something specific or satisfies a boolean proc?
18:09:06apriori_currently one would have to use the "low level" constraints and check the others in the template
18:10:17Araqtrue
18:13:37Araqwell you want param{predicate} and that's it?
18:14:00Araqbut then we still have no type API ...
18:14:15Araqso I guess that would be the first step
18:15:04apriori_well, one first would definetly need general constraints for all templates (I see no reason to limit them to tr macros only)
18:15:04reactormonkwhat is the compilerproc pragma btw?
18:15:13apriori_pretty much.. like D did.. maybe better
18:16:14Araqapriori_: the constraints are indeed planned for everything
18:16:25Araqand will become part of the overloading resolution
18:16:33apriori_yeah, good
18:16:39apriori_tough task already, I think ;)
18:16:51Araqnot really :P
18:16:56apriori_for you :P
18:17:30Araqbut what do you mean "pretty much like D did"?
18:17:49Araqafaik D has nothing like that
18:18:03apriori_well, it does have it in a quite simple way
18:18:26AraqC++like expression templates I'd guess
18:18:32apriori_following the declaration one can write an if block prior to the function body opening { which is the constraint to be checked
18:18:47Araqbut the constraints operate on types
18:18:55Araqin Nimrod they operate on ASTs
18:18:59apriori_yeah
18:19:14apriori_ASTs is of course much more powerful ;)
18:19:44apriori_actually.. it already takes quite some time to get used to all this stuff ...
18:19:59apriori_I'm not really thinking in "AST validation patterns" all the time ;)
18:38:04apriori_Araq: another question about tuples
18:38:12apriori_currently I more often run into the following issue:
18:38:45apriori_say we got 2 tuple types A and B, both with the same count of elements but different field names.. those can't be used interchangable.. although that's sometimes desired
18:38:56apriori_I that intentional?
18:39:06apriori_*is
18:39:13Araqyeah
18:39:25apriori_okay
18:39:50Araqthough it would be easier if the compiler could always ignore the field names for tuples
18:39:57Araqso what use case do you have in mind?
18:40:09apriori_say I got one vector tuple and one size tuple
18:40:16apriori_(x, y, z) vs (width, height, depth)
18:40:43apriori_and I'd prefer (out of lazyness) to define vector operations only once..
18:40:56apriori_sure.. I could do that for both types.... using copy pasta :P
18:41:08Araqmacros avoid copy pasta
18:41:12Araqbut I see your point
18:41:17Araqwill think about it
18:41:24apriori_thank you
18:41:30AraqRTTI does not include proper field names anymore already
18:43:36Araqmaybe we need yet another pragma ;-)
18:43:48Araq{.dirty.} for tuples
18:43:52apriori_hehe
18:44:19apriori_yeah. I see it might not be a good idea to promote "ignoring fieldnames" to default behaviour
18:49:40apriori_am I right that for loops don't allow element unpacking?
18:49:53apriori_like: for (i, j) in somePairIterator:
18:50:10Araqthey do, but you need to use 'items' explicitely
18:50:58apriori_hm, is that really the same?
18:51:47Araqwell you mustn't use () in this context
18:51:54Araqand yeah I know it's not consistent
18:52:12apriori_you mean: for i, j in somePairIterator: ?
18:52:33Araqyeah
18:52:35apriori_ok
19:02:38reactormonkwhat is the compilerproc pragma?
19:07:47Araqapriori_: nimrod needs matrix and vector etc. in its stdlib; would you like to implement these?
19:08:16AraqI'm not good enough at these, so I won't do it
19:08:34Araqreactormonk: 'compilerproc' is a "codegen proc"
19:08:47Araqit's a proc that is called by the code generator
19:09:08Araqthe compiler keeps these in an extra symbol table
19:09:23reactormonkaaand so what?
19:09:53apriori_Araq: well, I could.. but give me some time. got university stuff etc. to do, too
19:09:54Araqin the C generator you can invoke it in a pattern like "#compProc"
19:10:04reactormonkah
19:11:11Araqapriori_: no problem, but if somebody comes around and is faster than you ... ;-)
19:11:26Araqhe'll get the fame ;-)
19:12:04apriori_hehe, yeah
19:12:39apriori_one question about type declarations, btw.. because if I'd do that, I'd prefer that to be as general as possible:
19:12:47apriori_something like that doesn't seem to be possible:
19:13:19apriori_TVectorN*[T, s:int] = array[0..s-1, T]
19:13:21apriori_as type
19:15:50Araqtrue type parameters cannot be values
19:16:06Araqsomething like that should work though (modulo compiler bugs)
19:16:28Araqtype TVectorN*[T, IDX] = array[IDX, T]
19:17:23Araqthen you can also pass 1..3 as IDX
19:28:30apriori_ohm, what am I doing wrong here?: http://pastebin.com/9tCBe6mE
19:30:07reactormonkapriori_: apparently you only have TSlice[int] and no int matching
19:30:12reactormonkaka second-last
19:32:30apriori_I'd more say, that i in my for loop is replaced by the entire tuple
19:33:08apriori_or, well..
19:33:13apriori_hm..
19:33:27apriori_actually 3 args is just right
19:33:37apriori_but it expects the enum as index
19:33:41apriori_otherwise no operator can match
19:34:36apriori_yup, that was the issue
19:44:03apriori_got go now bye
19:44:12*apriori_ quit (Quit: Konversation terminated!)
21:43:21*Trix[a]r_za is now known as Trixar_za
23:37:05fowli just found tools/nimrepl.nim o_O
23:38:58Trixar_zaYou know why I like you guys? Because you actually know the Language from the roots up. Unlike certain *coff* Python! *coff* people in a certain IRC channel.
23:41:49Trixar_zaUse Twistd my ass
23:47:18reactormonkTrixar_za: I don't think Araq still knows all the small stuff ;-(
23:47:33reactormonkI hope you know the part where the compiler is translated from pascal via pas2nim
23:47:38Trixar_zaYou'd be surprised
23:49:21Trixar_zaWell, from what I read, Nimrod started it's life in Pascal, so that conversion is probably the most complete of the bunch.
23:50:02Trixar_zaAlthough, a few years have gone by since Nimrod became totally bootstrapped, so that may have changed
23:54:28reactormonkyep, that's the pas2nim part
23:57:56*q66 quit (Quit: Quit)