| 01:21:20 | * | Trixar_za is now known as Trix[a]r_za |
| 01:43:41 | * | q66 quit (Quit: Leaving..) |
| 07:31:35 | * | shevy quit (Quit: "") |
| 07:39:44 | * | Araq_ joined #nimrod |
| 07:43:46 | * | Araq_ quit (Client Quit) |
| 07:45:15 | * | shevy joined #nimrod |
| 10:17:40 | * | q66 joined #nimrod |
| 10:36:24 | * | fowl is now known as fowlzzzzzzzzzzzz |
| 11:45:22 | * | Araq_ joined #nimrod |
| 11:45:42 | * | Araq_ quit (Client Quit) |
| 12:55:12 | * | Araq_ joined #nimrod |
| 12:55:33 | * | Araq_ quit (Client Quit) |
| 13:40:14 | * | fowlzzzzzzzzzzzz is now known as fowl |
| 14:53:08 | * | jyyou quit (*.net *.split) |
| 14:53:09 | * | comex quit (*.net *.split) |
| 14:55:46 | * | jyyou joined #nimrod |
| 14:55:46 | * | comex joined #nimrod |
| 15:26:04 | * | shevy quit (Ping timeout: 246 seconds) |
| 15:38:59 | * | shevy joined #nimrod |
| 15:57:40 | * | q66 quit (Quit: Leaving..) |
| 15:58:17 | * | q66 joined #nimrod |
| 17:11:29 | * | apriori__ joined #nimrod |
| 17:12:20 | apriori__ | hey, Araq, want something to laugh about? |
| 17:12:29 | apriori__ | http://www.heise.de/newsticker/meldung/SIGGRAPH-OpenGL-4-3-bringt-Compute-Shader-1660650.html |
| 17:12:58 | apriori__ | khronos now adding "compute shaders" to opengl... how stupid one can be... |
| 17:43:33 | shevy | so! |
| 17:43:36 | shevy | today is a new day |
| 17:43:40 | shevy | waaaake up dom96 |
| 17:50:21 | Araq | tach, apriori__ |
| 17:50:34 | Araq | what's so funny about that? |
| 17:50:48 | apriori__ | well, as already mentioned.. I think its utterly stupid |
| 17:51:00 | apriori__ | because it will, yet again, result in source level toolkit separation |
| 17:52:39 | apriori__ | one just doesn't know then.. shall I use OpenCL or OpenGL compute shaders? will both work on the same hardware etc. |
| 17:55:06 | Araq | I know too few about opencl to have an opinion |
| 17:55:28 | Araq | apparently openCL is much broader and thus harder to implement correctly though |
| 17:55:44 | apriori__ | well, it for sure is |
| 17:56:46 | apriori__ | but this development could very lead to the "death" of opencl.. simply because vendors might be too lazy to implement the opencl stack instead of the opengl compute shader subset |
| 17:57:32 | Araq | I don't think so opencl is already commonly used for scientific computing, afaik? |
| 17:58:35 | apriori__ | not as broad as cuda, for example |
| 17:58:46 | Araq | btw strtod is locale dependent |
| 17:58:49 | apriori__ | even though cuda is vendor locked.. opencl is still quite behind, feature wise |
| 17:58:55 | apriori__ | it is? |
| 17:58:57 | apriori__ | damn |
| 17:59:32 | Araq | http://stackoverflow.com/questions/1994658/locale-independent-strtod-implementation |
| 18:00:20 | Araq | I think I will adapt my code so that it works like: http://svn.ruby-lang.org/repos/ruby/branches/ruby_1_8/missing/strtod.c |
| 18:00:27 | Araq | what do you think? |
| 18:01:09 | apriori__ | I don't quite know the scope of parseFloat... shouldn't it be locale aware? |
| 18:01:34 | Araq | hell no |
| 18:02:21 | apriori__ | or one could use a variant which allows passing in a locale.. or just port that ruby strtod |
| 18:02:39 | Araq | "port that ruby strtod" is what I mean |
| 18:02:50 | Araq | it's however already similar to the current implementation |
| 18:03:07 | Araq | and nimrod's stdlib has no notion of locales |
| 18:03:26 | Araq | by design |
| 18:04:00 | apriori__ | okay |
| 18:04:35 | apriori__ | well, if your implementation is similiar.. you might also just try to find the bug in yours |
| 18:05:12 | Araq | true but the implementation is also braindead for large exponents |
| 18:08:03 | Araq | "Warning: The proposed implementation from ruby contains bugs." ... -.- |
| 18:08:10 | Araq | hurray |
| 18:08:14 | apriori__ | ouch |
| 18:08:38 | apriori__ | one might take a look at D's stdlib, maybe |
| 18:11:22 | Araq | usually I copy these things from FPC but it could have the same bugs |
| 18:11:33 | apriori__ | FPC? |
| 18:14:20 | Araq | free pascal |
| 18:15:24 | shevy | hmm |
| 18:15:38 | shevy | on my biggest wish list would be yaml in nimrod :D |
| 18:15:48 | shevy | though I can convert it into json |
| 18:15:53 | Araq | I started a yaml parser once |
| 18:15:58 | Araq | but found it tedious |
| 18:15:59 | shevy | and nimrod has json support I think so it is not a real problem |
| 18:16:02 | shevy | hehe |
| 18:16:10 | shevy | I think I use only like 5% of what yaml offers |
| 18:16:18 | shevy | mostly, its "foo: bar" entries I use |
| 18:16:21 | Araq | yeah just like everybody else |
| 18:16:25 | shevy | :) |
| 18:16:33 | Araq | it's over engineered |
| 18:18:58 | Araq | shevy: you could wrap a yaml parser written in C easily |
| 18:23:54 | Araq | hm on the other hand if we don't set the locale, it defaults to the "C" locale, right? |
| 18:24:35 | Araq | and since we don't provide setlocale() it should be safe ... |
| 18:24:40 | Araq | well not really |
| 18:24:59 | shevy | no real idea |
| 18:25:10 | shevy | I'll just convert the yaml data I have via ruby into a format nimrod likes :) |
| 18:25:26 | shevy | hmm that brings me to a question though |
| 18:25:42 | shevy | let's say I have a large nimrod project, which allows a user to have different configuration entries, for specific in-program behaviour |
| 18:25:58 | shevy | how should I store this? a simple text file that the nimrod program would read? or something else? |
| 18:26:08 | shevy | debug: true |
| 18:26:09 | shevy | debug: false |
| 18:26:30 | shevy | things like that, flags and such. or store_log_files_where: /tmp/bionimrod |
| 18:37:01 | Araq | but we can blame other libraries for the resulting bugs |
| 18:37:01 | Araq | that's a good idea :-) |
| 18:37:01 | Araq | use nimrod's configuration file parser |
| 18:37:53 | shevy | hmm |
| 18:38:03 | shevy | does this follow some kind of format? |
| 18:38:14 | shevy | http://nimrod-code.org/parsecfg.html |
| 18:38:25 | shevy | "The configuration file's syntax is similar to the Windows .ini format" |
| 18:38:44 | shevy | the docu even includes an example :) |
| 18:39:07 | Araq | http://nimrod-code.org/parsecfg.html |
| 18:39:13 | Araq | apriori__: I think we should use strtod() and convert any ',' back to '.' |
| 18:39:13 | Araq | er |
| 18:39:13 | Araq | convert it to the locale's decimal separator |
| 18:39:16 | shevy | hmm |
| 18:40:14 | shevy | of cfgEof: |
| 18:40:20 | shevy | where from does cfgEof come? |
| 18:40:29 | shevy | ah |
| 18:40:31 | shevy | from Types I suppose |
| 18:40:47 | Araq | TCfgEventKind |
| 18:40:58 | Araq | lol "enumation " |
| 18:41:11 | Araq | typos, typos, typos ... |
| 18:44:30 | Araq | brb |
| 18:47:41 | Araq | back |
| 18:47:58 | Araq | so, apriori__ |
| 18:48:04 | Araq | what about using nimrod for opencl code generation? ;-) |
| 18:50:21 | apriori__ | Araq: I don't quite know yet... |
| 18:50:34 | apriori__ | got severe lack of time.. was ill for 2 weeks etc... |
| 18:51:46 | Araq | just make a decent feature request ;-) |
| 18:52:13 | apriori__ | I will.. just be a bit more patient |
| 18:52:24 | Araq | alright |
| 18:53:35 | dom96 | hello |
| 18:53:52 | dom96 | Well I think my Graphics Card will die quite soon |
| 18:54:05 | dom96 | :( |
| 18:54:39 | apriori__ | Araq: actually... before I can do that, I need to more or less develop/propose a wrapper implementation for opencl |
| 18:55:14 | dom96 | But I got an old Nvidia so it's all good |
| 18:55:18 | dom96 | I hope |
| 18:55:25 | dom96 | So what did I miss? |
| 18:55:40 | apriori__ | like handlers for specific variable types, more or less an "optimizer" (though one will need it even for basic code), which will analyze use patterns and generate the respective opencl code and nimrod interop code |
| 19:03:08 | Araq | what do you mean? "Handlers for specific variable types"? |
| 19:04:31 | apriori__ | well, suppose you got an array.. and want to work on that array, what would be the proper update strategy if the array is in fact a transparent wrapper for an opencl array |
| 19:04:45 | apriori__ | this is where things get complicated... |
| 19:05:28 | apriori__ | one could either just extend the type system.. and let the user convert/copy data by hand or via overloaded operators, or one could "transparently" wrap the opencl buffer objects |
| 19:07:21 | apriori__ | I mean.. it should be quite doable to use a naive openmp-like approach in which you got clearly distinct sections of a program, which are annotate to execute in parallel |
| 19:07:39 | apriori__ | you know all the variable in that block, their types.. and can apply handlers on these types. |
| 19:08:25 | apriori__ | but things get complicated when assumptions about the usage outside of these blocks shall be made (the problem is, thats the only way to allow efficient usage of the resources) |
| 19:08:52 | apriori__ | in other words: at first I need to make up my mind, what the limits of the goal should be ;) |
| 19:10:20 | apriori__ | anyway... this is definetly a case of way too early thoughts about optimization |
| 19:10:47 | Araq | I don't get it |
| 19:11:26 | Araq | proc p(a: array [0..M, float]) {.runOnGPU.} = ... |
| 19:11:42 | Araq | # let the compiler deal with it |
| 19:11:44 | apriori__ | which is an easy case, yes. |
| 19:12:06 | apriori__ | anyway.. about the code generator |
| 19:12:07 | Araq | nimrod's semantics already allow for the array to be copied |
| 19:12:18 | apriori__ | can you point me to some locations on where to look how its used? |
| 19:12:38 | Araq | the compiler is free to copy or use pass by reference |
| 19:14:00 | Araq | apriori__: not really; it's part of a (annoying) translation pipeline |
| 19:14:15 | apriori__ | hm, okay |
| 19:15:05 | Araq | perhaps look at cgen.cgenPass() |
| 19:19:06 | apriori__ | on it |
| 19:21:39 | Araq | basically it registers callbacks, 'myProcess' is called for every top level statement/declaration |
| 19:27:45 | apriori__ | uff.. cloning the repo takes time |
| 19:31:08 | Araq | sorry, I never got rid of the generated C cruft |
| 19:31:46 | apriori__ | well, no problem |
| 19:31:54 | apriori__ | but it will take some time, to make sense out of that ;) |
| 19:58:18 | Araq | yay my "borrow" changes did not break anything :-) |
| 19:58:24 | Araq | amazing |
| 19:58:47 | apriori__ | maybe you just dont have a test case for it :P |
| 19:59:02 | Araq | I added a test case :P |
| 19:59:55 | Araq | what's the new "unstar" button on github? |
| 20:07:52 | dom96 | https://github.com/blog/1204-notifications-stars |
| 20:07:53 | dom96 | :) |
| 20:09:37 | Araq | already reading it :P |
| 20:09:46 | Araq | but I don't get it :P |
| 20:19:38 | dom96 | My "friends" are already complaining :P |
| 20:21:18 | Araq | about what? |
| 20:23:40 | dom96 | About the new Github |
| 20:46:09 | * | Boscop quit (Disconnected by services) |
| 20:46:12 | * | Boscop joined #nimrod |
| 20:50:54 | * | Boscop quit (Disconnected by services) |
| 20:50:57 | * | Boscop joined #nimrod |
| 20:52:57 | * | Bosc0p joined #nimrod |
| 20:54:16 | * | Bo5cop quit (Ping timeout: 272 seconds) |
| 21:09:06 | * | Bo5cop joined #nimrod |
| 21:12:58 | * | Bosc0p quit (Ping timeout: 255 seconds) |
| 21:18:23 | Araq | good night guys |
| 21:19:03 | * | Bosc0p joined #nimrod |
| 21:20:14 | * | Boscop quit (Disconnected by services) |
| 21:20:18 | * | Boscop joined #nimrod |
| 21:23:16 | * | Bo5cop quit (Ping timeout: 268 seconds) |
| 21:30:14 | * | apriori__ quit (Ping timeout: 246 seconds) |
| 22:32:51 | * | Trix[a]r_za is now known as Trixar_za |