| 00:43:43 | * | DAddYE quit (Remote host closed the connection) |
| 01:28:36 | * | kpublik joined #nimrod |
| 01:32:29 | * | kpublik quit (Client Quit) |
| 01:33:56 | * | kpublik joined #nimrod |
| 01:37:45 | * | kpublik quit (Client Quit) |
| 01:43:34 | * | q66 quit (Remote host closed the connection) |
| 01:43:52 | * | DAddYE joined #nimrod |
| 01:48:42 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 01:54:07 | * | DAddYE joined #nimrod |
| 01:54:46 | * | tymat quit (Read error: Operation timed out) |
| 01:58:54 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 02:47:07 | * | ARCADIVS joined #nimrod |
| 03:02:24 | * | fowl quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!) |
| 03:06:49 | * | fowl joined #nimrod |
| 04:19:50 | * | OrionPK quit (Quit: Leaving) |
| 04:22:12 | * | fowl quit (Quit: EliteBNC free bnc service - http://elitebnc.org - be a part of the Elite!) |
| 04:23:47 | * | fowl joined #nimrod |
| 04:24:27 | * | fowl quit (Changing host) |
| 04:24:27 | * | fowl joined #nimrod |
| 06:09:43 | * | zahary joined #nimrod |
| 07:12:32 | * | Endy joined #nimrod |
| 07:53:00 | * | zahary quit (Quit: Leaving.) |
| 07:54:00 | * | tumak joined #nimrod |
| 07:58:35 | * | zahary joined #nimrod |
| 08:19:50 | NimBot | Araq/Nimrod master cbc52f8 zah [+0 ±1 -0]: documented trackDirty |
| 09:12:48 | fowl | is concating strings like "A" "BC" valid C? i thought that was just in c++ |
| 09:24:01 | Araq | fowl: it's valid C too |
| 09:24:35 | Araq | hi tumak, welcome |
| 09:45:58 | * | [1]Endy joined #nimrod |
| 09:48:57 | * | Endy quit (Ping timeout: 252 seconds) |
| 09:48:57 | * | [1]Endy is now known as Endy |
| 10:10:53 | * | zahary quit (Quit: Leaving.) |
| 10:16:01 | * | q66 joined #nimrod |
| 10:36:44 | * | zahary joined #nimrod |
| 12:09:29 | tumak | oi araq |
| 13:43:13 | dom96 | hello tumak |
| 13:50:44 | Araq | TTimeInfo contains monthday*: range[1..31] |
| 13:51:10 | Araq | with my new static checking this means it's a type that *requires* explicit initialization |
| 13:51:28 | Araq | so that the monthday can't be 0 |
| 13:52:23 | Araq | however this breaks code ... |
| 13:52:56 | Araq | proc getLocalTime(t: TTime): TTimeInfo = |
| 13:52:57 | Araq | result.second = t.getSeconds() |
| 13:52:59 | Araq | ... |
| 13:53:20 | Araq | doesn't compile anymore then; you need to write: result = TTimeInfo(second: ...) |
| 13:54:41 | Araq | so I suppose I should make it warning for 0.9.4 ? |
| 13:55:33 | dom96 | well it's currently a bug that it's initialised to '0'. Perhaps the initial value should be the lowest in the range? |
| 13:56:59 | Araq | it's not a bug, it's in the spec :P |
| 13:57:22 | dom96 | then it's a bug in the spec :P |
| 13:59:10 | Araq | no, it's just fine to init to binary 0 ... everything else slows things down |
| 13:59:34 | Araq | and now the compiler prevents it at compile time which is better anyway |
| 14:00:27 | dom96 | I suppose it's a nice idea to do a warning for now, and then make it an error for 0.9.6 |
| 14:03:06 | dom96 | please make the error and warning clear though |
| 14:57:24 | * | OrionPK joined #nimrod |
| 16:30:52 | Araq | how do I name the warning? |
| 16:31:05 | Araq | "warning: deprecated usage of 'X' since it cannot be proven to be initialized" ? |
| 16:31:12 | * | Trix[a]r_za is now known as Trixar_za |
| 16:32:25 | dom96 | what will 'X' be in this context? |
| 16:32:34 | Araq | some variable |
| 16:37:24 | Araq | well? |
| 16:37:53 | dom96 | by "this context" I mean, the example you gave a while ago. |
| 16:38:22 | Araq | well yes ...? |
| 16:40:26 | Araq | well in that context it is "result" |
| 16:42:51 | dom96 | hrm |
| 16:43:57 | dom96 | how about: "Warning: Cannot prove that 'X' is initialised, use object constructor. This will become a compile time error in the future." |
| 17:08:13 | Araq | ok, that's better |
| 17:22:34 | Araq | how should the type pragma be named to get this feature for other types? "needsInit" ? |
| 17:24:27 | dom96 | "forceInit"? |
| 17:25:24 | Araq | hmm well it's "explicitInit" really ... |
| 17:25:40 | dom96 | 'force' is shorter :P |
| 17:27:00 | Araq | it's just as imprecise as "needs" |
| 17:27:25 | dom96 | fine, go for the 'explicit' then |
| 17:27:37 | Araq | meh that's too long :P |
| 17:27:50 | Araq | plus I can't spell it |
| 17:29:01 | dom96 | learn to spell then :P |
| 17:29:31 | reactormonk | you could make nimrod spelling-invariant too, like you did with case |
| 17:30:58 | * | Trixar_za is now known as Trix[a]r_za |
| 17:33:07 | Araq | what about "requiresInit"? |
| 17:39:45 | * | Trix[a]r_za is now known as Trixar_za |
| 17:59:07 | * | Trixar_za is now known as Trix[a]r_za |
| 18:15:01 | * | gradha joined #nimrod |
| 18:50:50 | gradha | version of the docs at http://build.nimrod-code.org/docs/overview.html says they are behind the stable version |
| 18:51:03 | tumak | Araq: http://build.nimrod-code.org/irclogs/02-07-2012.html ... is that still the case (no bignums at all?) |
| 18:55:53 | Araq | tumak: yeah we still lack bignums |
| 18:57:51 | tumak | ok, i'm fairly new to this so i have something to stab at :) |
| 19:00:32 | tumak | cursory grep -R shows few lines with TyBigNum, i presume it just serves as sentinel marker for biggest native int type? |
| 19:04:35 | * | Endy quit (Ping timeout: 260 seconds) |
| 19:09:39 | Araq | no it's unused |
| 19:10:10 | Araq | and there is no need to hack the compiler for now, first step is a bignum library that the compiler could use |
| 19:10:30 | Araq | but then I'm not sure I like the compiler using bignums ... |
| 19:10:53 | Araq | it looks bad for compile time evaluation |
| 19:12:22 | tumak | indeed the language is powerful enough it can be just module :) |
| 19:13:03 | tumak | yeah, if compiler (internally) has to ever resort to bignums, the implementation should be pretty efficient already |
| 19:15:07 | Araq | things would be more pressing if I liked unsigned ints ... but I don't ;-) |
| 19:20:08 | Araq | btw are you kt on the forum, tumak? |
| 19:21:27 | tumak | yep |
| 19:21:33 | tumak | you were right about the gc btw :( |
| 19:23:50 | tumak | (not that it would be pressing issue, c-like coroutines, or better said green threads, are imo overrated unless they resemble something like lua has, ie efficient value passing between yield/resume) |
| 19:26:12 | Araq | you know, you can use nimrod's closure iterators instead ... |
| 19:26:53 | tumak | yeah yeah, same excuse as python's |
| 19:26:57 | tumak | thats why we have stackless python *g* |
| 19:27:16 | gradha | crap, don't we have stackless nimrod? |
| 19:27:51 | tumak | i presume Araq is already rich and famous like guido in that case |
| 19:28:17 | Araq | actually no ... we have real technical reasons for not having them |
| 19:28:32 | Araq | whereas Python is simply poorly implemented |
| 19:30:15 | tumak | never understimated guido, maybe in python 4000 one will be able to yield from arbitrary function depth! |
| 19:30:47 | tumak | </python bashing> |
| 19:30:48 | fowl | lua wrapper is going to be annoying |
| 19:31:15 | Araq | "explicit is better than implicit" for a dynamically typed language? ... it's hard to underestimate Guido :P |
| 19:31:27 | fowl | for some reason the functions are in the form void *(lua_func) (void); and c2nim trips over the parens |
| 19:32:10 | tumak | Araq: to be fair, cpython fixes that pretty nicely |
| 19:32:16 | tumak | that and it generates several megabytes .c blobs |
| 19:32:25 | tumak | s/cpython/cython/ |
| 19:32:42 | Araq | cython still has no real type system the last time I looked at it |
| 19:32:49 | gradha | Araq: you are taking that out of context: it means, use a single CPU core and explicitly prevent threading |
| 19:33:40 | gradha | after all, multicore is a fad, and GHz will keep rasing every year |
| 19:34:15 | Araq | dunno I don't mind the GIL |
| 19:34:53 | gradha | I would tell you a performance terror history of python on macosx, but then you would rightly dismiss it as it being a macosx problem |
| 19:35:01 | tumak | inb4 disorderdly nimrod mob with torches and pitchforks raiding comp.lang.python |
| 19:35:25 | Araq | you can easily lose a factor of 20x against C with Python |
| 19:35:48 | Araq | using multi-threading to make use of all your cores is ridiculous in this context |
| 19:36:06 | Araq | my machine has 4 cores btw, not 20 ... |
| 19:37:08 | gradha | well, the horror history goes like this: due to some wtf combination of GIL and macosx (some version can't remember which) a single threaded python program ran 10 times slower, with no possibilities of improving |
| 19:38:02 | gradha | that's when I switched to cython and solved it, at the same time improving the performance of the script by an order of magnitude |
| 19:38:31 | gradha | eventually that wtf problem was solved |
| 19:39:21 | * | tumak never had an issue with gil |
| 19:40:19 | tumak | i think its awesome for its intended purpose, ie super fast prototyping concurrent networking code in python where asyncio would be overkill |
| 19:40:28 | tumak | maybe they should extend it into some sort of barriers |
| 19:40:48 | tumak | so dict[hash()] = dict2[gethash2()] is all atomic |
| 19:41:05 | tumak | having to use locks around that is silly, why not just lock gil per function or something |
| 19:42:49 | gradha | maybe it has to do with C bindings, the GIL is even funnier when you are implementing a C module |
| 19:44:32 | Araq | tumak: if you gist your setcontext stuff, I may add GC support for it next week |
| 19:45:06 | tumak | gradha: nah, the gil should be held by C only if the C function is non-reentrant |
| 19:45:49 | tumak | Araq: I'll open issue with it then |
| 19:45:59 | Araq | ok good |
| 19:53:59 | gradha | I like how the license change happend in the commit "made some tests green; implemented 'from module import nil'" |
| 19:54:20 | Araq | ssshhh |
| 19:54:22 | gradha | sneaky bsd ninjas at work |
| 20:04:16 | * | silven_ joined #nimrod |
| 20:07:58 | * | _ponce quit (Ping timeout: 246 seconds) |
| 20:07:59 | * | silven quit (Ping timeout: 246 seconds) |
| 20:08:57 | * | _ponce joined #nimrod |
| 20:28:18 | * | JStoker_ joined #nimrod |
| 20:29:11 | * | JStoker quit (*.net *.split) |
| 20:32:35 | * | JStoker_ is now known as Guest25439 |
| 20:36:51 | * | Guest25439 quit (Changing host) |
| 20:36:51 | * | Guest25439 joined #nimrod |
| 20:36:58 | * | Guest25439 is now known as JStoker |
| 20:50:14 | fowl | dunno how to wrap this: http://pastebin.com/t7met9VC |
| 20:50:27 | fowl | how do i tell what LUAI_BITSINT was when lua was compiled |
| 20:52:08 | Araq | when sizeof(int) >= 4 |
| 20:58:56 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 21:04:47 | fowl | thx |
| 21:07:33 | dom96 | Araq: gradha is onto you. |
| 21:19:23 | tumak | Araq: https://gist.github.com/katuma/5736628 |
| 21:19:31 | tumak | i wrote generalized coro base in the end |
| 21:19:40 | tumak | GC_fullCollect() just hangs on me :( |
| 21:21:25 | Araq | btw does it work with --gc:boehm? |
| 21:34:20 | tumak | Araq: all of em hang |
| 21:34:22 | tumak | except none :( |
| 21:34:26 | tumak | will file the issue |
| 21:34:40 | tumak | hopefully the code s not that utterly broken, there is some hard cast wrt cconv |
| 21:41:09 | tumak | ha, got segfault |
| 21:41:21 | tumak | this is going to be tricky one, as sometimes it segfaults, and sometimes ends in infinite loop |
| 21:46:51 | tumak | Araq: https://github.com/Araq/Nimrod/issues/472 |
| 21:46:59 | tumak | have fun, would be nice to have stack-aware gc! :) |
| 21:47:59 | Araq | doesn't seem to be tricky :P |
| 22:09:16 | * | silven_ is now known as silven |
| 22:14:40 | dom96 | We really need this for the Nimrod forum: https://github.com/goshakkk/nsa_panel :P |
| 23:09:12 | * | ARCADIVS quit (Quit: WeeChat 0.3.8) |