| 00:30:02 | * | Boscop quit (Disconnected by services) |
| 00:30:03 | * | Boscop joined #nimrod |
| 01:13:52 | * | reactormonk quit (Ping timeout: 246 seconds) |
| 01:27:17 | * | reactormonk joined #nimrod |
| 01:40:48 | * | q66 quit (Quit: Quit) |
| 02:24:13 | * | zahary quit (Quit: Leaving.) |
| 03:14:37 | * | reactormonk quit (Ping timeout: 246 seconds) |
| 03:27:46 | * | reactormonk joined #nimrod |
| 05:12:34 | * | XAMPP quit (Ping timeout: 260 seconds) |
| 07:07:31 | * | Trix[a]r_za is now known as Trixar_za |
| 07:27:51 | * | XAMPP joined #nimrod |
| 07:27:52 | * | XAMPP quit (Changing host) |
| 07:27:52 | * | XAMPP joined #nimrod |
| 07:32:14 | Trixar_za | Hmmm |
| 07:32:20 | Trixar_za | I might as well |
| 09:28:41 | * | q66 joined #nimrod |
| 10:57:53 | * | Trixar_za is now known as Trix[a]r_za |
| 11:01:56 | * | Araq_ joined #nimrod |
| 11:19:43 | * | Araq_ quit (Read error: Connection timed out) |
| 12:05:24 | fowl | wow i just discovered that repr(result) shows the nimrod code result instead of treerepr() showing the tree |
| 12:05:26 | fowl | beautiful |
| 13:20:40 | * | zahary joined #nimrod |
| 13:47:26 | fowl | someone should copy the styles dir for http://build.nimrod-code.org/docs/ |
| 14:31:32 | dom96 | hello |
| 14:32:27 | fowl | yp |
| 14:32:30 | fowl | yo* |
| 14:38:59 | * | dom96 just got back from a school interview heh |
| 14:49:58 | dom96 | fowl: Why should someone copy the styles dir for http://build.nimrod-code.org/docs/? |
| 15:00:42 | fowl | because its missing and would make it a lot more readable |
| 15:05:32 | dom96 | oh I see what you mean. |
| 15:05:38 | dom96 | Well, you should access that to be honest. |
| 15:05:44 | dom96 | Just go straight to http://build.nimrod-code.org/docs/lib.html |
| 15:05:53 | dom96 | And that is what http://build.nimrod-code.org/ links to as well |
| 15:06:07 | dom96 | I might make a page with all the links at some point though. |
| 15:07:19 | * | Trix[a]r_za is now known as Trixar_za |
| 15:11:04 | Trixar_za | You so should list the events in the irc module documentation |
| 15:11:33 | Trixar_za | Oh wait, there it is |
| 15:11:35 | Trixar_za | nevermind |
| 15:11:54 | dom96 | heh |
| 15:12:34 | Trixar_za | TIRCMType* = enum |
| 15:12:35 | Trixar_za | MUnknown, MNumeric, MPrivMsg, MJoin, MPart, MMode, MTopic, MInvite, MKick, |
| 15:12:35 | Trixar_za | MQuit, MNick, MNotice, MPing, MPong, MErro |
| 15:12:44 | Trixar_za | TIRCEventType* = enum |
| 15:12:45 | Trixar_za | EvMsg, EvDisconnected |
| 15:12:48 | Trixar_za | I assume it's those |
| 15:12:48 | Trixar_za | :P |
| 15:13:03 | Trixar_za | But yeah - rewriting the damn java logbot in Nimrod |
| 15:13:04 | fowl | dom96: i like to get to the index that way |
| 15:18:49 | Trixar_za | The module can retrieve lag? Oo |
| 15:19:55 | dom96 | fowl: I just type "theindex" into firefox and it suggests the page for me ;) |
| 15:20:39 | dom96 | Trixar_za: Yay, awesome. And yes, it can ;) |
| 15:20:45 | fowl | lol |
| 15:20:53 | dom96 | It pings the server periodically, and stores the lag. |
| 15:21:13 | fowl | now that i have networking working i have to start on the rest of my game :/ all this work i've been putting off lol |
| 15:21:51 | dom96 | hehe |
| 15:25:02 | Trixar_za | Yeah, I'm reading through c4hbot's code to learn a proper way to write IRC bots |
| 15:25:03 | Trixar_za | :P |
| 15:25:50 | Trixar_za | Well, 'better way' would probably be more accurate |
| 15:29:22 | dom96 | Note: That code is competition quality on a strict timeline ;) |
| 15:30:11 | Trixar_za | Yeah, but you created procs to handle the events. That's really a better way to do it |
| 15:30:43 | Trixar_za | You also turned the Bot into an object (if I'm reading this right) |
| 15:47:52 | dom96 | Trixar_za: Yes, it's an object with the Bot as a field. |
| 15:48:17 | * | Trixar_za should learn to program properly |
| 16:11:45 | * | shevy quit (Ping timeout: 252 seconds) |
| 16:24:00 | * | shevy joined #nimrod |
| 17:44:48 | Araq | ping zahary |
| 17:45:03 | Araq | I'm implementing 'bind' for macros; I'm almost done |
| 17:46:43 | Araq | but I wonder if newIdentNode() should return a bound symbol or if we should introduce a new magic |
| 17:50:54 | zahary | well, if there is a new magic, then there is no need for bind |
| 17:51:03 | Araq | yes there is |
| 17:51:34 | zahary | why? |
| 17:51:44 | Trixar_za | The sex won't be the same without it |
| 17:51:53 | Trixar_za | And hi Araq |
| 17:52:14 | Araq | let abc = "x", n = getBoundSym(abc) |
| 17:52:30 | Araq | --> by the time we know what to bind, it's too late |
| 17:52:40 | Araq | because it can be runtime value |
| 17:53:20 | Araq | 'bind' is declarative and can be processed earlier accurately |
| 17:53:25 | zahary | I don't follow. it will still be evaluated during the execution of the macro? |
| 17:53:42 | zahary | ah, you mean you need to do the analysis in sem |
| 17:53:44 | zahary | not in evals |
| 17:53:50 | Araq | yes |
| 17:58:20 | zahary | well, depending on how inner scopes are handled (whether it's possible to return a call to symbol local to the proc), it may be much more appropriate to do in sem indeed |
| 17:59:06 | Araq | I'm doing it in sem, yes |
| 17:59:09 | zahary | that said, why do you think a new magic is required |
| 17:59:27 | Araq | because newNimNode() is too low level |
| 17:59:37 | Araq | and newIdentNode() is not a builtin anway |
| 17:59:56 | zahary | I suggested StrToIdent as the hooked magic |
| 18:00:16 | Araq | yeah I don't understand why :-) |
| 18:00:25 | Araq | a symbol is not an ident |
| 18:00:27 | zahary | notice how newIdentNode expects PNimrodIndent - you cannot create these without StrToIdent |
| 18:00:48 | Araq | ah I see, true |
| 18:03:16 | Araq | hi Trixar_za |
| 18:03:37 | zahary | I still imagine something more along the lines of a special indent node until it's time to return the macro AST and then some additional logic in lookups.nim to turn these into the appropriate symbols |
| 18:04:17 | Araq | well my latest gensym changes ensure that a nkSym won't be looked up again |
| 18:04:18 | zahary | when I say bind x, there may be multiple symbols with that identifier so it depends on the particulars of the nkCall node |
| 18:04:42 | Trixar_za | I'm so many levels behind it's not even funny |
| 18:04:58 | dom96 | Trixar_za: Join the club. |
| 18:04:59 | Araq | well, nkSymChoice deals with that, zahary |
| 18:05:21 | Araq | 'bind x' is more advanced than you may think it is |
| 18:06:23 | zahary | sure, I imagined that may be the case - still you can defer the resolution to the end of evalMacro |
| 18:06:56 | Araq | no because that would require capturing the macro definition's scope |
| 18:07:01 | Araq | and I don't want that :-) |
| 18:07:41 | Araq | it's annoying enough I can't throw away a proc's AST because it could be necessary for CTFE |
| 18:08:07 | Araq | and thus memory usage can only ever increase for large programs |
| 18:10:02 | zahary | a noble goal is to make the memory linear with regard to the source code size (regardless of the constant factor) - then you can postulate that computer's ram amounts will increase faster then the ability of humans to produce code :) |
| 18:10:05 | zahary | but back to topic |
| 18:10:55 | zahary | so, you want this new magic to be at least partially handled in sem as well |
| 18:12:54 | Araq | no |
| 18:13:03 | Araq | it works like this: |
| 18:13:24 | Araq | nkBindStmt in macro body: processed in sem.nim, nkBindStmt becomes a list of symbols |
| 18:13:28 | zahary | and it's not about identifiers, but about symbols… if there is a new magic and it's handled in sem then bind is not needed again, no? |
| 18:13:59 | Araq | nkBindStmt in evals.nim is processed again and fills a symbol table in PEvalContext |
| 18:14:16 | Araq | the new magic looks at this symbol table |
| 18:14:30 | Araq | --> new magic only in evals.nim |
| 18:14:53 | Araq | an AST can already be "mixed" |
| 18:15:14 | Araq | with some stuff looked up and other nkIdent's that are still to be processed |
| 18:15:17 | zahary | bindMagic could be handled in sem directly and it can produces a meta node to be used directly in evals.nim without any further analysis |
| 18:15:46 | Araq | bindMagic(myVariableString) # ugh |
| 18:16:05 | Araq | of course you can prevent that by special semantic checking code |
| 18:16:12 | Araq | but 'bind' seems more attractive |
| 18:16:22 | zahary | ah, yes - 2 minutes ago I though of that, but forgot it |
| 18:16:59 | Araq | why do you dislike my solution? ;-) |
| 18:17:14 | zahary | bind requires static symbol names - such new magic could require it too... |
| 18:17:35 | Araq | yeah, I said that :P |
| 18:17:36 | zahary | I want to avoid the "repeating my intentions" element in the solution |
| 18:18:12 | zahary | bind X |
| 18:18:12 | zahary | getBoundSym("X") |
| 18:21:43 | Araq | well yes, as I said, I like the improved readability |
| 18:22:02 | Araq | I guess it often suffices to look at the 'bind' statement and get what the macro is about to do |
| 18:22:43 | Araq | 'bind write, writeln, `$`, `&`' # ok, I have an idea ;-) |
| 18:26:44 | zahary | it's certainly not extremely painful, but it's one thing to say "write a bind statement, then do everything as usual in the rest of the macro" and it's another to say "write a bind statement, then use the % operator to get a bound symbol everywhere where you need one" (my first reaction will be "why do I need to steps here?") |
| 18:27:14 | zahary | * two steps * |
| 18:28:33 | zahary | but if you like the extra readability then I can't argue further |
| 18:28:53 | Araq | well I'm almost done with the feature and then we can play around ;-) |
| 18:29:25 | Araq | another solution is to re-activate the bind *expression* inside of a macro |
| 18:29:41 | Araq | which is exactly your solution, but with a keyword instead of a magic |
| 18:30:10 | Araq | might be a good compromise readability-wise though |
| 18:32:51 | Araq | your unittest module is interesting btw |
| 18:33:10 | Araq | it shows 'dirty' is really necessary and the same can't be done with 'inject' |
| 18:33:46 | zahary | dirty is the old injectAll, right? |
| 18:34:01 | Araq | as then the client code needs to be aware of the implementation and 'inject' its own locals |
| 18:34:11 | Araq | (yes, dirty = old injectAll) |
| 18:34:48 | Araq | in fact, there is a paper that argues for special hygiene rules to support your testsuite macro |
| 18:36:52 | Araq | so maybe I should have implemented those ;-) |
| 18:38:29 | zahary | the explicit control one has now with nimrod is the way to go for me - any more complicated rules require you to understand very well the intended usage model set by the language designer and contributes to a much steeper learning curve - learning ATS is example for me in that direction |
| 18:39:24 | zahary | of course there may be robustness benefits with some more advanced set of rules, but it's hard to tell without any real-world experience using them |
| 18:39:38 | Araq | yeah true |
| 18:41:14 | * | Trixar_za is now known as Trix[a]r_za |
| 18:41:43 | Araq | but the real "proper" solution are fexprs anyway |
| 18:42:13 | Araq | which are first class; hygiene is a workaround to get some kind of lexical scoping back |
| 18:43:15 | zahary | ahm |
| 18:43:42 | zahary | gotta go btw, see you later |
| 18:43:57 | Araq | alright |
| 18:44:09 | Araq | and no, I don't get fexprs either :-) |
| 18:46:59 | * | reactormonk quit (Ping timeout: 240 seconds) |
| 18:48:12 | * | reactormonk joined #nimrod |
| 18:48:39 | dom96 | I am so going to compete in Ludum Dare 24 with Nimrod |
| 18:50:20 | Araq | cool :-) |
| 18:51:35 | dom96 | http://www.youtube.com/watch?feature=player_embedded&v=v1ByVqh0jrU |
| 18:51:42 | dom96 | That's a pretty cool keynote :P |
| 18:55:28 | Araq | brb |
| 19:18:59 | Araq | back |
| 20:19:04 | fowl | macro `?`*(a: expr): expr = result = if a[1].kind == nnkIdent: hash($a[1].ident).lit else: a[1] |
| 20:19:31 | fowl | ?ez ?fake ?symbols :> |
| 20:22:36 | dom96 | That's like obfuscation to the max, if I understand what it does :P |
| 20:27:35 | Araq | fowl: what do you need symbols for? |
| 20:27:44 | Araq | I prefer enums :P |
| 20:34:56 | fowl | I was thinking about using them for IDs |
| 20:35:38 | Araq | use a compiletime variable |
| 20:35:48 | Araq | var counter {.compileTime.}: int |
| 20:42:50 | Araq | fowl: what about some bug reports? or does your macro fu simply work? |
| 20:43:04 | fowl | it works |
| 20:45:26 | * | zahary quit (Ping timeout: 245 seconds) |
| 20:58:34 | reactormonk | fowl: hmm, liberal symbols vs. conservative enums? ;-) |
| 21:04:16 | Araq | type TSymbol = distinct int |
| 21:04:22 | Araq | const |
| 21:04:30 | Araq | symA = TSymbol(0) |
| 21:05:19 | fowl | hmm i should start it again with a compiletime table then i could just use increasing values 0, 1, 2, etc |
| 21:06:01 | Araq | var counter {.compileTime.}: int |
| 21:06:16 | Araq | proc gensym(): int {.compileTime.} = |
| 21:06:22 | Araq | result = counter |
| 21:06:27 | Araq | inc counter |
| 21:06:45 | Araq | const symB = TSymbol(gensym()) |
| 21:06:54 | Araq | const symC = TSymbol(gensym()) |
| 21:07:16 | Araq | proc `==`(a, b: TSymbol): bool {.borrow.} |
| 21:07:45 | fowl | i mean ?foo map foo => compiletimetable["foo"] or compiletimetable["foo"] = counter; inc counter |
| 21:09:11 | Araq | why? |
| 21:09:27 | Araq | why do you want a compiletimetable? |
| 21:09:38 | Araq | use the compiler's symbol table instead ;-) |
| 21:10:13 | fowl | so when it hits ?foo again its looked up instead of a new id generated |
| 21:10:32 | Araq | meh |
| 21:10:42 | Araq | so you don't want to declare symbols at all |
| 21:10:48 | Araq | I see |
| 21:10:58 | fowl | no i want to replace them with int literals :p |
| 21:11:33 | Araq | how do you notice typos then? oh alright, you don't :P |
| 21:11:43 | Araq | seems the way to go :P |
| 21:11:59 | fowl | brb pizza |
| 21:20:28 | Araq | dom96: please make the "output" subwindow optional |
| 21:21:52 | * | dom96 looks at his todo list and cries |
| 21:21:53 | dom96 | :P |
| 21:57:39 | * | reactormonk quit (Ping timeout: 260 seconds) |
| 22:00:21 | * | reactormonk joined #nimrod |