| 14:47:25 | * | NimBot joined #nimrod |
| 15:17:32 | * | gradha joined #nimrod |
| 16:44:15 | * | q66 joined #nimrod |
| 16:54:40 | * | codeallergy joined #nimrod |
| 17:05:35 | NimBot | nimrod-code/packages 41a5f78 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds nimepak to list of available packages. |
| 17:05:35 | NimBot | nimrod-code/packages 05c1c66 Dominik Picheta [+0 ±1 -0]: Merge pull request #5 from gradha/pr_adds_nimepak... 3 more lines |
| 17:27:28 | Araq | ping zahary |
| 17:34:12 | Araq | gradha: want to add your name to tut1 ? ;-) |
| 17:34:24 | gradha | why? |
| 17:35:14 | Araq | because you keep adding things to the tutorial :-) |
| 17:36:11 | gradha | contributors.txt is more than enough, unless you want to particularly blame me for the tutorial in the future |
| 17:38:42 | Araq | no I don't mind either way |
| 17:39:32 | gradha | then I'll stay in contributors.txt, thanks |
| 17:40:11 | Araq | no problem |
| 17:52:20 | * | codeallergy quit (Ping timeout: 248 seconds) |
| 17:52:31 | gradha | when an exception is raised usually the "raiser" assigns a text message to a msg variable, which is then showed by the compiler |
| 17:52:55 | gradha | is it possible to "capture" this message and append it to another one, when re-raising as a different exception? |
| 17:53:20 | Araq | getStackTrace(e) ? |
| 17:53:34 | Araq | only works in debug mode of course :P |
| 17:53:38 | reactormonk | well, we could use a 'the hard way' template |
| 17:55:45 | gradha | so there is no way of accesing the exception object inside an except branch? you can't create a custom exception object and attach stuff to it as a means of extra communication? |
| 18:01:07 | Araq | you can do getCurrentException() or getCurrentExceptionMsg() or getStackTrace(getCurrentException()) in an 'except' section |
| 18:01:23 | Araq | and then set the msg of your new exception to whatever you like |
| 18:02:35 | Araq | you can also make the stacktrace field public in system.nim and do a pull request if you feel adventurous |
| 18:03:17 | Araq | reactormonk: what's a "hard way template" and how could it possibly find out the stack trace? |
| 18:05:29 | reactormonk | Araq, for tutorials... |
| 18:06:30 | Araq | I still can't follow |
| 18:06:37 | reactormonk | don't bother too much. |
| 18:08:03 | * | XAMPP_8 quit (Ping timeout: 245 seconds) |
| 18:09:45 | Araq | gradha: usually I'm not of a fan of exception wrapping; it's slow and rarely helps :P |
| 18:11:07 | Araq | transforming ESQL into an abstract EIO for encapsulation purposes is mostly misguided IMO |
| 18:16:38 | dom96 | gradha: In regards to your pull request: it might be a nice idea to mention that just because you are using two variables in the for loop does not mean that the first variable will be the index, in some cases like tables.pairs this is not the case. |
| 18:17:41 | gradha | yes, it's more complex, that's why I ended up adding the text to the sequence section rather than the for statement, because it's not generic |
| 18:17:54 | gradha | I guess you could write an iterator returning three variables |
| 18:18:27 | dom96 | ahh, I didn't realise it was in the sequence section. |
| 18:18:28 | gradha | or maybe a "pair" iterator which "unpacks" the paris from a sequence of pair tuples? |
| 18:19:04 | gradha | the only reason I added this note is because I "expected" the two-variable version to unpack tuples from a sequence, and got weird results |
| 18:20:30 | dom96 | Yeah. I think it was suggested at some point that you should be able to specify types for the variables in your for loops, and the compiler could then infer the right iterator to use. Not sure if that's still the plan. |
| 18:21:29 | gradha | there's a leap of faith there, why does the for pick the items/pairs iterator and not something else? |
| 18:21:59 | Araq | gradha: the 'for' loop used to unpack tuples in the way you imagined |
| 18:22:11 | Araq | but it turned out to be idiotic for generic code |
| 18:22:42 | Araq | so now the rules are very simple: 1 for loop var an no explicit iterator -- items is called |
| 18:22:52 | Araq | 2 for loop vars an no explicit iterator -- pairs is called |
| 18:23:13 | Araq | pairs for a sequence yields (idx, value) because what else can it do? |
| 18:23:47 | Araq | it shouldn't look at the type to see it's a tuple of 2 fields and do some special magic for that |
| 18:29:07 | Araq | but maybe we need an 'unpack' iterator ;-) |
| 18:30:35 | gradha | hmm... would it be a macro which looks at the type of the objects and generates code which returns n-result variables? |
| 18:34:38 | Araq | that's a possible solution, yeah |
| 18:35:59 | Araq | or you 2-5 overloads for tuples of lengths 2-5 ;-) |
| 18:36:37 | Araq | unpacking of 6 vars is then not supported but you should reconsider your design then anyway :P |
| 18:37:21 | gradha | can macros keep some sort of global state? say, this hypothetical unpack macro could generate the iterator for 2-length tuples of a certain type, if that is encountered again, could it call the previously generated iterator instead of bloating repeated code? |
| 18:38:07 | Araq | yeah use a .compiletime. variable for that |
| 18:38:32 | gradha | I really need to learn macros |
| 18:38:42 | Araq | but it doesn't gain you much, the iterator is inlined anyway so that won't fight code bloat |
| 18:39:02 | Araq | unless you generate the new first class iterators ... |
| 18:47:57 | reactormonk | Araq, that expensive? |
| 18:49:07 | Araq | reactormonk: 'expensive' is relative ... first class iterators require a (currently always) heap allocated closure |
| 18:49:18 | reactormonk | Araq, oh |
| 18:53:24 | reactormonk | Araq, https://gitorious.org/learn-x-the-hard-way/learn-x-the-hard-way/blobs/master/README |
| 18:54:50 | Araq | reactormonk: I know about the hard way template ... oh ... that's what you mean |
| 18:55:04 | * | Araq was thinking about nimrod's templates :P |
| 18:55:33 | Araq | apparently there is no easy way to learn nimrod, so what's the point? :P |
| 18:56:14 | dom96 | reactormonk: A learn Nimrod the hard way would be cool |
| 18:58:58 | Araq | reactormonk: better write a tutorial about how to (mis)use Nimrod's JS code generator |
| 19:01:38 | dom96 | Just about any document about Nimrod is worth encouraging :) |
| 19:01:59 | Araq | except perhaps a rant about nimrod ... |
| 19:02:03 | reactormonk | Araq, ^^ |
| 19:02:14 | reactormonk | which platform to use? |
| 19:02:18 | dom96 | Araq: true |
| 19:02:26 | dom96 | Any positive document :P |
| 19:02:31 | Araq | hrm |
| 19:03:09 | Araq | actually a script kiddie rant full of irrelevant things could work too :D |
| 19:03:31 | * | gradha quit (Ping timeout: 248 seconds) |
| 19:12:12 | Araq | ping zahary |
| 19:14:19 | dom96 | reactormonk: You should write learn nimrod the hard way :) |
| 20:00:45 | dom96 | This is interesting: http://blog.ninlabs.com/2013/01/programmer-interrupted/ |
| 22:11:35 | NimBot | nimrod-code/Aporia 3c7bbf0 Dominik Picheta [+0 ±2 -0]: Configuration is now validated before being saved when editing it raw. |
| 22:12:36 | Araq | dom96: I think you should save the configuration when the config dialog vanishes |
| 22:13:21 | dom96 | Araq: The session will then be outdated though. |
| 22:13:23 | Araq | and not when the application ends |
| 22:13:33 | Araq | yeah the session doesn't belong in there anyway :P |
| 22:13:41 | Araq | use a different file for that |
| 22:14:12 | dom96 | Meh, it's fine for now. :P |
| 22:15:49 | Araq | hope it wasn't too much work |
| 22:16:25 | dom96 | I would need to break settings to do this... |
| 22:17:14 | Araq | alright then, thought it would be less work than config validation |
| 22:17:51 | dom96 | It would be a lot more :P |
| 22:18:17 | Araq | your architecture is meh then :P |
| 22:18:25 | Araq | oh btw |
| 22:18:31 | Araq | reproduced the crash? |
| 22:18:36 | dom96 | no |
| 22:18:41 | Araq | should I try? |
| 22:18:45 | dom96 | Yes |
| 22:19:31 | * | gradha joined #nimrod |
| 22:32:50 | * | zahary1 joined #nimrod |
| 22:33:11 | Araq | ping zahary1 |
| 22:35:13 | * | zahary quit (Read error: Connection reset by peer) |
| 23:01:36 | gradha | hmmm... weird, if I use the except/finally combo as statements the finally block runs before the except block |
| 23:01:49 | gradha | isn't finally supposed to run after everything else? |
| 23:02:31 | Araq | hmm weird that we have lots of complex tests for try now and nobody noticed it |
| 23:02:50 | gradha | I believe none use the statement form |
| 23:03:10 | Araq | what do you mean? |
| 23:03:20 | Araq | there is no expression form of 'try' yet |
| 23:03:47 | gradha | try this https://gist.github.com/4590343 and tell me what output you get |
| 23:04:10 | gradha | I get 1, 3, 2, but I was expecting 1, 2, 3 |
| 23:04:12 | Araq | that's a "standalone" finally |
| 23:04:39 | gradha | so the finally has to be before the except? |
| 23:04:50 | Araq | I don't know ;-) |
| 23:05:02 | gradha | well, that works then |
| 23:05:09 | gradha | huh, so everything is in reverse |
| 23:05:15 | gradha | makes sense |
| 23:05:22 | Araq | well then so be it ;-) |
| 23:05:26 | gradha | yeah |
| 23:06:23 | Araq | standalone finally/except is weird and only exists for templates |
| 23:06:38 | Araq | he discussed it already |
| 23:06:41 | Araq | *we |
| 23:06:57 | gradha | we includes me? |
| 23:07:03 | Araq | I think so |
| 23:07:33 | gradha | you can't write normal try/except/finally inside a template? |
| 23:08:18 | Araq | er ... yes you can |
| 23:08:44 | Araq | look up what the manual says about standalone finally please |
| 23:09:01 | gradha | well, I'm trying to document it, because it doesn't say much |
| 23:09:24 | Araq | I think I should mark it as experimental |
| 23:10:45 | * | XAMPP_8 joined #nimrod |
| 23:10:49 | gradha | the only thing I find is "except and finally can also be used as a stand-alone statements. Any statements following them in the current block will be considered to be in an implicit try block" |
| 23:11:01 | gradha | so that's what I'm trying to expand on and submit a pull request |
| 23:11:09 | Araq | cool :-) |
| 23:11:46 | gradha | I see no reference to finally in templates, so I don't get why there has to be a standalone statement version |
| 23:12:36 | Araq | onErrorDo: rollback() was the idea iirc |
| 23:13:04 | Araq | except that we don't a keyword like that so used 'except' |
| 23:13:20 | Araq | and you can wrap it in a template with a name that makes sense |
| 23:13:58 | Araq | template onErrorDo(body: stmt) {.immediate, dirty.} = except: body |
| 23:14:31 | dom96 | damn, I'm getting a deja vu. |
| 23:15:55 | gradha | I can't see any advantage of doing that, so I'll leave it sink |
| 23:15:55 | dom96 | If onErrorDo would have been used from the get go, it would have made this a bit less confusing/easier to explain. |
| 23:30:42 | NimBot | Araq/Nimrod 7c0f4e2 Araq [+1 ±8 -0]: fixed some closure related bugs |
| 23:30:42 | NimBot | Araq/Nimrod 077070a Araq [+0 ±2 -0]: Merge branch 'master' of github.com:Araq/Nimrod |
| 23:33:12 | * | gradha quit (Quit: Leaving) |
| 23:37:47 | NimBot | Araq/Nimrod be45fd8 Araq [+1 ±2 -0]: bootstrapping works again |
| 23:59:48 | NimBot | Araq/Nimrod eeb4183 Araq [+0 ±2 -0]: bugfix: ftpclient compiles again |