| 00:00:12 | Araq | use message passing and watch the horrible performance |
| 00:00:27 | Araq | nimrod's message passing implementation is VERY slow |
| 00:00:53 | gradha | I presume I would use the locks module along with allocShared's result? |
| 00:01:04 | Araq | perhaps |
| 00:01:41 | Araq | you can also just split the imagines into non-overlapping parts and process these without locks |
| 00:02:11 | Araq | *images |
| 00:02:43 | gradha | you would still need locking at some point between the worker threads when they finish and try to get more tiles to process |
| 00:02:57 | gradha | maybe a locked queue is somewhere? |
| 00:03:46 | Araq | sure that's what threads are supposed to communicate with |
| 00:04:22 | Araq | but I'd try fork&join and not do any work stealing |
| 00:05:01 | Araq | in fact, just use the || iterator and don't perform any allocations in the loop body |
| 00:05:45 | gradha | is there an API which exposes the number of cores to create the optimal number of threads for a pool? |
| 00:06:17 | Araq | osproc.getNumberOfCPUs or something like that |
| 00:06:22 | Araq | it's in osproc |
| 00:06:23 | gradha | osproc.countProcessors? |
| 00:06:26 | Araq | yeah |
| 00:06:53 | gradha | does that work at the physical level or at the logical one? you know, intel throwing multi-whatever-simulation-virtualization-stuff and so |
| 00:07:04 | gradha | hyperthreading |
| 00:07:07 | gradha | that's the word |
| 00:07:22 | Araq | it does the right thing (TM), ok? |
| 00:07:31 | Araq | that means I don't know ... ;-) |
| 00:07:41 | gradha | that's fine |
| 00:07:45 | Araq | it asks the OS what it thinks |
| 00:09:13 | gradha | I'll ask my pillow what it thinks, good night |
| 00:09:22 | Araq | bye |
| 00:09:27 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 02:59:54 | * | ccssnet quit (Quit: http://atccss.net) |
| 03:03:04 | * | ccssnet joined #nimrod |
| 03:28:13 | * | fowl joined #nimrod |
| 05:24:35 | * | zahary1 joined #nimrod |
| 05:25:27 | * | zahary quit (Ping timeout: 245 seconds) |
| 12:32:16 | * | q66[bru] joined #nimrod |
| 12:32:22 | q66[bru] | #join #d |
| 12:32:25 | q66[bru] | errr |
| 12:32:48 | q66[bru] | fucking irc commands |
| 12:35:52 | Araq | joining #d is a mistake anyway :P |
| 12:37:38 | q66[bru] | Araq, yes |
| 12:37:41 | q66[bru] | i like to troll it there |
| 12:37:50 | Araq | oh alright |
| 13:03:49 | * | q66[bru] quit (Quit: Computer has gone to sleep.) |
| 13:20:28 | dom96 | hello |
| 14:39:21 | * | FreeArtMan quit (Quit: Leaving) |
| 14:46:26 | * | Trix[a]r_za is now known as Trixar_za |
| 15:06:01 | * | Trixar_za is now known as Trix[a]r_za |
| 15:14:15 | * | Trix[a]r_za is now known as Trixar_za |
| 16:02:54 | * | Trixar_za is now known as Trix[a]r_za |
| 16:36:01 | * | FreeArtMan joined #nimrod |
| 16:41:36 | * | q66[bru] joined #nimrod |
| 16:59:42 | * | q66[bru] quit (Quit: Computer has gone to sleep.) |
| 17:04:00 | * | XAMPP_8 joined #nimrod |
| 17:11:45 | * | Zerathul joined #nimrod |
| 17:37:20 | fowl | 16808f2 revert to old GC; use --gc:v2 to activate the new GC |
| 17:37:23 | fowl | whats that about |
| 17:38:01 | Araq | fowl: zahary is working on a new GC which supports garbage collecting a shared heap |
| 17:38:15 | Araq | and incremental operation for the cycle collector |
| 17:38:34 | Araq | but currently it uses more memory and is slower |
| 17:39:52 | * | q66[bru] joined #nimrod |
| 17:40:27 | fowl | o cool |
| 17:40:42 | q66[bru] | cool what |
| 17:41:02 | fowl | 113800: <Araq> fowl: zahary is working on a new GC which supports garbage collecting a shared heap |
| 17:41:02 | fowl | 113814: <Araq> and incremental operation for the cycle collector |
| 17:41:02 | fowl | 113833: <Araq> but currently it uses more memory and is slower |
| 17:41:08 | Araq | q66[bru]: http://build.nimrod-code.org/irclogs/ |
| 17:41:23 | * | gradha joined #nimrod |
| 17:41:35 | q66[bru] | neat |
| 17:42:46 | gradha | not sure, using more memory and being slower is so mainstream |
| 17:46:37 | Araq | gradha: do you feel like investigating some bugs on windows? |
| 17:47:07 | gradha | fortunately I don't have windows |
| 17:47:32 | Araq | fowl: same question |
| 17:48:10 | gradha | I might get a surface pro this year if the windows platform starts picking up speed on mobile though |
| 17:49:52 | Araq | oh wait, there is a pull request for #322 now |
| 17:51:04 | gradha | today I was told by unreliable sources Microsoft is already working on Windows 9 due to 8 having lackluster sales |
| 17:51:21 | gradha | I can't believe I'm getting news about tech through meatspace earlier than through internet |
| 17:56:22 | * | FreeArtMan quit (Ping timeout: 276 seconds) |
| 17:57:47 | * | q66[bru] quit (Quit: Computer has gone to sleep.) |
| 18:19:38 | gradha | can't call an immediate template from within another immediate template? |
| 18:21:39 | Araq | sure you can |
| 18:22:39 | gradha | I guess I'm failing again at syntax, will try dividing the code |
| 18:23:16 | Araq | what's the error message? |
| 18:23:27 | gradha | ok, found the problem, typo |
| 18:23:55 | gradha | had vim autocomplete me a variable name similar to the template name |
| 18:24:19 | gradha | I think I'll rename the variable to avoid future problems |
| 18:54:28 | gradha | in what situations would you pass in a typedesc[something] to a proc as a parameter? |
| 18:55:01 | Araq | I don't know |
| 18:56:23 | Araq | I don't really remember what it means ;-) |
| 18:57:02 | Araq | I know what expr[string] means and I'll remove it again once I feel like it |
| 18:57:17 | gradha | it means I fucked up writing proc(a = string) instead of proc(a: string) |
| 18:57:32 | gradha | expr[string] ? |
| 18:59:18 | Araq | it means string{lit} |
| 19:01:33 | gradha | interesting |
| 19:14:48 | gradha | assignment to discriminant changes object branch |
| 19:14:51 | * | shevy quit (Ping timeout: 244 seconds) |
| 19:14:58 | gradha | so I guess I can't do that |
| 19:19:14 | gradha | looks like $ won't stringify a ref E_base, is there any proc which will? |
| 19:19:37 | Araq | nope |
| 19:19:45 | Araq | repr should work |
| 19:22:27 | gradha | I get ref 0x102817788 --> [] |
| 19:22:35 | gradha | if I try to deref with []?I get just the blank brackets |
| 19:22:58 | Araq | well it doesn't use the dynamic type |
| 19:23:01 | Araq | but the static type |
| 19:23:30 | Araq | E_Base does contain the fields though, hm |
| 19:25:46 | Araq | bbl |
| 19:28:22 | * | shevy joined #nimrod |
| 19:41:26 | * | gradha quit (Ping timeout: 246 seconds) |
| 19:49:17 | * | gradha joined #nimrod |
| 20:03:19 | gradha | I'm failing to instantiate an object variant through a template https://gist.github.com/4699026 |
| 20:03:32 | gradha | maybe this is where templates don't cut it and I have to resort to macros? |
| 20:05:35 | dom96 | gradha: think about it this way, new_node(...) gets replaced with your templates body. |
| 20:05:56 | dom96 | so you should put the `let t3 = new_node(...)` inside your templates body. |
| 20:07:05 | gradha | the error is the same if I call new_node without assigning it anywhere |
| 20:07:30 | gradha | I guess the problem is this generates wrong type branches for the switch |
| 20:07:49 | gradha | but a template is run at compile time, so it would leave just the code of the selected branch |
| 20:08:02 | dom96 | the return type of the template should also be: stmt |
| 20:09:01 | gradha | s/template is.../macro is.../ |
| 20:09:45 | dom96 | a template is also run at compile time |
| 20:11:29 | gradha | it's a pity the compiler dislikes my template |
| 20:13:54 | dom96 | hrm, lets see what I can do. |
| 20:14:29 | dom96 | first thing I notice is your 'expr' arg, that seems like a bad idea (not giving it a type) |
| 20:14:44 | gradha | well, that's the point of the template/macro |
| 20:15:07 | dom96 | you should make it "e: expr" |
| 20:15:11 | dom96 | expr is a type |
| 20:16:23 | dom96 | oh, I see the problem. |
| 20:17:02 | dom96 | I suppose what you do is fine, but it feels risky to me. |
| 20:17:30 | dom96 | the 'kind' arg actually causes a problem, in that 'result.kind' is transformed into 'result.PK_INT' |
| 20:18:40 | gradha | ugh, what? |
| 20:19:05 | gradha | ok, I renamed the parameter to tkind and now the error is indeed different |
| 20:19:13 | dom96 | yeah. |
| 20:19:20 | gradha | now it fails where I expected it to fail: the case with all branches |
| 20:20:32 | gradha | I guess Araq will come and beat me with some obscure oneliner from the manual explaining the why of the kind variable substitution |
| 20:21:05 | gradha | aha, indeed, "Lookup rules for template parameters" |
| 20:22:15 | dom96 | hrm, perhaps this is a bug. |
| 20:22:54 | gradha | it's even more than one line of doc, so I bet it's definitely a feature |
| 20:24:56 | dom96 | here is a workaround: https://gist.github.com/20159763f3812bc0f131 |
| 20:25:02 | dom96 | But you don't get compile time safety then |
| 20:26:02 | gradha | isn't that evil? |
| 20:26:07 | * | dom96 didn't know that you could have templates which return a proper type :O |
| 20:26:27 | dom96 | seems to be quite evil, yeah. |
| 20:27:03 | gradha | but clever evilness |
| 20:27:58 | gradha | so the compiler will leave the case there, and at runtime will pick one of the branches, so if I pass the wrong type will raise an exception, correct? |
| 20:28:48 | dom96 | yeah |
| 20:29:04 | dom96 | It should be possible to get compile time safety though |
| 20:29:45 | gradha | any time is good to stat learning macros, so there I go |
| 20:30:19 | gradha | and thanks for the evil suggestion |
| 20:30:22 | dom96 | ooh |
| 20:30:48 | dom96 | https://gist.github.com/20159763f3812bc0f131 |
| 20:30:48 | dom96 | :D |
| 20:30:55 | dom96 | You can use a when |
| 20:31:11 | gradha | nice! |
| 20:31:21 | dom96 | A compile-time case would be even awesomer. |
| 20:31:40 | dom96 | oh and don't mind the {lit} |
| 20:31:50 | dom96 | It works without that too it seems. |
| 20:32:06 | gradha | I still don't know what {lit} means |
| 20:33:04 | dom96 | I think it might only apply to term rewriting macros |
| 20:33:28 | dom96 | Sadly, the following will not work: var blah = PK_INT; let t3 = new_node(blah, 2) |
| 20:33:41 | dom96 | but that's correct I think |
| 20:33:55 | gradha | I was going to ask that |
| 20:34:11 | gradha | since I thought when was only available for compilation defines |
| 20:34:15 | gradha | like release or debug |
| 20:34:20 | gradha | compilation constants |
| 20:34:37 | dom96 | yeah, I would just use a proc for the runtime version. |
| 20:46:58 | * | FreeArtMan joined #nimrod |
| 20:51:15 | gradha | you mentioned a compile time case, sounds like that could be provided by an expression macro named static_case |
| 20:52:57 | gradha | I wonder if the macro could be made to generate a runtime case if the input parameter was not appropriate |
| 20:57:54 | Araq | I can only shake my head about this conversation |
| 20:58:44 | Araq | 'case' should work fine too in the template |
| 20:59:38 | Araq | and dom96, T{lit} is now available for ordinary templates too |
| 21:00:02 | Araq | but I wonder why you use it, if you don't know what it means ... ;-) |
| 21:00:14 | gradha | it is a bug then that case didn't work? |
| 21:00:27 | Araq | dunno yet |
| 21:00:44 | Araq | often I say it's a bug and then figure out the compiler is correct ;-) |
| 21:07:07 | Araq | Error: type mismatch: got (int literal(3)) but expected 'string' |
| 21:07:32 | Araq | well you can't do it that way |
| 21:08:03 | Araq | indeed the 'case' is not evaluated at the instantation time |
| 21:08:56 | Araq | a 'static case' construct is planned but for now you have to use 'when' |
| 21:10:31 | Araq | when tkind == PK_EMPTY: nil |
| 21:10:33 | Araq | elif tkind == PK_INT: result.int_val = expr |
| 21:10:34 | Araq | elif tkind == PK_STRING: result.str_val = expr |
| 21:10:36 | Araq | else: {.error: "unknown kind".} |
| 21:10:42 | Araq | works fine too |
| 21:11:05 | Araq | so no bug here |
| 21:11:21 | Araq | and dom96 was correct |
| 21:13:59 | * | Zerathul quit (Ping timeout: 256 seconds) |
| 21:14:21 | * | Zerathul joined #nimrod |
| 21:14:54 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 21:21:56 | * | FreeArtMan quit (Ping timeout: 255 seconds) |
| 21:43:54 | * | gradha joined #nimrod |
| 21:46:46 | gradha | nimrod templates, cool |
| 21:46:55 | gradha | forgetting to eat dinner because of nimrod, not so cool |
| 21:47:37 | Araq | can't be that bad, you didn't forget to watch youtube |
| 21:51:51 | gradha | actually, I didn't undestand yesterday's video: why does this kratos throw chains from his hands? is he like ancient-greece-spiderman? |
| 21:52:55 | Araq | the chains are between the sword's blade and handle |
| 21:53:04 | Araq | I think |
| 21:53:38 | gradha | haha, reminds me of mazinger z when he launched the forearms |
| 21:53:58 | Araq | inspector gadget? |
| 21:54:19 | gradha | that would be closer, yes, since the forearms weren't attached |
| 21:55:34 | gradha | mazinger z: http://www.toei-anim.co.jp/lineup/tv/mazingerz/ pretty popular when I was a child, did watch films of it in the basement of our local church |
| 21:55:58 | gradha | can't find the name in english, huh, maybe the translation was different? |
| 21:56:14 | Araq | no idea |
| 21:56:42 | gradha | is the static case more work than just joining the when/elif? |
| 21:56:52 | gradha | I mean, does it do something else the when/elif construct can't do? |
| 21:56:59 | Araq | nah |
| 21:57:52 | Araq | did you also watch "Gamera" as a child? |
| 21:58:00 | gradha | no idea what that is |
| 21:58:10 | Araq | http://www.youtube.com/watch?v=Gqejmh-nJFo |
| 21:58:44 | gradha | ah, no, I came late to this genre with the power rangers |
| 22:00:51 | gradha | holy cow! it's september 11 in tortoise mode! |
| 22:01:35 | Araq | I especially like the voice acting in the movie |
| 22:02:02 | gradha | oh man, watching this as an adult is not so fun, realizing puny human structures wouldn't support the weight of those monsters |
| 22:03:18 | gradha | and now it's pacman! |
| 22:03:28 | gradha | and a hovercraf! |
| 22:05:57 | gradha | this is confusing, why are we programming in nimrod and not in gamera? |
| 22:06:36 | Araq | because I didn't know about gamera back then |
| 22:09:21 | Araq | but we should give versions names like Ubuntu |
| 22:09:35 | gradha | you mean, pokemon names? |
| 22:09:37 | Araq | so it'll be "Nimrod -- the Gamera edition" XD |
| 22:44:34 | dom96 | Araq: Is there a way to give wrapped functions docs? |
| 22:45:02 | gradha | maybe forward declaring? |
| 22:46:45 | dom96 | hrm, not sure what you mean |
| 22:47:34 | gradha | by wrapped function you mean a proc which uses the importc pragma, right? |
| 22:48:05 | dom96 | yeah |
| 22:48:42 | fowl | did you try it |
| 22:49:05 | fowl | iirc some of the sdl functions are documented |
| 22:49:39 | gradha | yeah, tried adding a comment to a gtk2 proc, worked without problem |
| 22:49:59 | gradha | http://pastebin.com/ben9qdjT |
| 22:50:17 | gradha | no need to forward declare then |
| 22:50:39 | dom96 | cool, thanks. |
| 22:51:20 | gradha | the forward declaration doc is used in the system module, system.nim forward declares and documents, included files implement, so that would be possible too |
| 22:55:47 | dom96 | oh yeah, I forgot about that. |
| 22:57:06 | gradha | Araq: we talked the other day about procs being "overwritten", and you having this style of documenting only where the export mark is |
| 22:57:34 | gradha | does idetools support telling you that for the proc x there are several points declaring that? maybe this could help finding such cases |
| 22:57:45 | gradha | by default idetools could give the "most recent", whatever that meant in compiler terms |
| 22:58:24 | gradha | I guess idetools already gives the "most recent" one |
| 22:58:57 | gradha | oh, and I think idetools has stopped working completely since last update |
| 22:59:05 | gradha | I will try to bisect the change |
| 23:00:46 | gradha | also: gamera edition is nice, but what would follow? |
| 23:58:31 | * | FreeArtMan joined #nimrod |
| 23:58:44 | * | gradha quit (Quit: bbl, have youtube videos to watch) |