| 00:13:19 | * | Bo5c0p is now known as Boscop |
| 00:13:19 | * | Boscop quit (Changing host) |
| 00:13:19 | * | Boscop joined #nimrod |
| 01:31:33 | * | Boscop quit (Read error: Connection reset by peer) |
| 01:37:23 | * | Boscop joined #nimrod |
| 01:40:24 | * | Boscop quit (Read error: Connection reset by peer) |
| 01:40:45 | * | Boscop joined #nimrod |
| 03:32:19 | * | Boscop quit (Quit: OutOfTimeException: Allocation of TimeFrame failed due to lack of time. Free up time by cancelling unimportant events.) |
| 08:44:44 | * | Trix[a]r_za is now known as Trixar_za |
| 10:57:57 | * | JStoker quit (Excess Flood) |
| 10:59:43 | * | JStoker joined #nimrod |
| 11:06:27 | * | Trixar_za is now known as Trix[a]r_za |
| 12:03:43 | Araq | ping zahary |
| 13:28:04 | * | shevy quit (Ping timeout: 245 seconds) |
| 13:41:41 | * | shevy joined #nimrod |
| 15:11:08 | Araq | ping zahary |
| 15:12:34 | zahary | hi Araq, I'm just passing through home and I don't have much time |
| 15:12:48 | zahary | but I answered the post you linked yesterday - no bug there |
| 15:12:56 | Araq | yeah saw it |
| 15:13:06 | Araq | I wondered what's wrong with it |
| 15:13:16 | Araq | but I have bad news |
| 15:13:27 | Araq | some simple program triggers a segfault |
| 15:13:32 | Araq | in debug mode only |
| 15:14:16 | zahary | is it reproducible on each run? |
| 15:14:23 | Araq | on my machine yes |
| 15:14:32 | Araq | haven't pushed it yet to the test runner |
| 15:15:02 | Araq | and as usual my debugger is useless |
| 15:15:16 | Araq | well at least it doesn't stop the bug from occurring |
| 15:16:38 | zahary | when I produce some strange crashes I usually just compile a very clean version of the program (no checks, no stack traces, etc) and try to debug it as a regular C executable |
| 15:21:17 | Araq | er |
| 15:21:42 | Araq | do we allocate top level temps statically in the generated C code? |
| 15:22:03 | Araq | the bug disappears when I put it in a main proc... |
| 15:23:51 | Araq | no we don't do that |
| 15:23:55 | Araq | hm |
| 16:12:52 | Araq | ha, I found it :P |
| 16:13:07 | Araq | the stack bottom setup has been broken again... |
| 16:13:14 | Araq | really fragile |
| 16:36:38 | Tasser | Araq, what kind of code isn't fragile? |
| 16:38:28 | Araq | the kind of code they don't teach at university :P |
| 17:10:19 | * | Trix[a]r_za is now known as Trixar_za |
| 17:42:28 | * | apriori_ joined #nimrod |
| 17:43:22 | Araq | hi apriori_ |
| 17:51:57 | apriori_ | hi Araq |
| 17:52:09 | apriori_ | how are nimrod things going? |
| 17:52:31 | Araq | there is new documentation generator |
| 17:52:37 | Araq | closures are becoming stable |
| 17:52:44 | apriori_ | ah, nice |
| 17:52:50 | Araq | and I just found and fixed a very rare GC bug |
| 17:52:57 | apriori_ | even better |
| 17:53:08 | apriori_ | D still doesn't progress too much with its new GC :P |
| 17:53:36 | Araq | D's GC will never be fast ;-) *cough* |
| 17:53:42 | apriori_ | hehe, who knows |
| 17:55:10 | Araq | oh and I found an easy way to do auto forward referencing |
| 17:55:23 | Araq | but it will only be for procs and methods |
| 17:55:46 | Araq | and the first implementation will require an explict {.forward: on.} pragma or something |
| 17:56:54 | apriori_ | nimrod is definetly not short on pragmas ;) |
| 17:57:10 | apriori_ | question is... well.. will one ever be able to define custom pragmas? |
| 17:57:25 | Araq | one already can with the 'pragma' pragma :D |
| 17:57:32 | apriori_ | ah, ok |
| 17:57:38 | Araq | but pragmas will also grow macro support |
| 17:57:42 | Araq | so you can do: |
| 17:57:46 | Araq | macro m() = ... |
| 17:57:53 | Araq | proc p {.m.} = |
| 17:57:54 | apriori_ | because one striking thing came to my mind when describing the use case of more or less anotating code with macro calls.. in order to e.g. transform a normal for loop into a dispatched opencl one |
| 17:58:06 | Araq | as a shortcut for: |
| 17:58:07 | apriori_ | for that the macro needs a hell lot context information |
| 17:58:08 | Araq | m: |
| 17:58:11 | Araq | proc p = ... |
| 17:58:29 | apriori_ | ah |
| 17:58:33 | apriori_ | so thats annotating |
| 17:58:57 | Araq | yeah but not implemented yet :-/ |
| 17:59:16 | Araq | should be 2 hours of work though |
| 18:00:12 | apriori_ | ok |
| 18:00:52 | apriori_ | can one actually already annotate a block? |
| 18:01:04 | Araq | you mean like: |
| 18:01:11 | Araq | block {.x.}: |
| 18:01:13 | Araq | ? |
| 18:01:21 | Araq | no ... |
| 18:01:27 | apriori_ | the block into the macro |
| 18:01:43 | Araq | hm? |
| 18:01:59 | apriori_ | well, forget it... |
| 18:02:10 | apriori_ | guess that would only make sense for the actual explicit "block" |
| 18:02:33 | Araq | well what feature do you really want for opencl? |
| 18:02:42 | apriori_ | no, not really... |
| 18:02:47 | apriori_ | just thinking a bit about it |
| 18:03:08 | Araq | you know I'm open to feature requests ;-) |
| 18:03:47 | apriori_ | and really.. dont take that stuff too serious .. what am doing just for the "lols" was done by several institutes with haskells combinator library, which has backends for several GPU frameworks |
| 18:04:12 | apriori_ | so I really doubt I will have anything really useful in limited time |
| 18:07:10 | apriori_ | which is kinda sad.. because I really think... that this is a very, very, very import niche now one could fill. |
| 18:08:02 | apriori_ | making all that tedious and (if you ask me) broken by design frameworks for GPGPU computing more accessible and convenient within a single language is definetly a way in into a bigger market for a language |
| 18:08:49 | apriori_ | so far only haskell is succeeded a bit in that regard.. nvidia tries to push trough a new standard called "OpenACC" (open accelerator framework) and at the same time tries to merge it with the OpenMP consortioum to come up with something merged there |
| 18:10:18 | apriori_ | that will take at least 2-3 years to get somewhere. in the meantime.. a language which would solve the language disparity problem "usual language" vs "opencl version" (which I think, could be generated in many cases automatically) could easily get huge momentum |
| 18:11:45 | apriori_ | actually.. it all comes down to unification of multiprocessing framework into a single language, if actually doable |
| 18:12:46 | Tasser | apriori_, ask Araq about abstraction |
| 18:13:15 | Araq | hey that's unfair, Tasser :P |
| 18:13:44 | Araq | you want me to say that abstraction quickly breaks |
| 18:13:49 | Araq | and indeed it does |
| 18:13:54 | apriori_ | yeah, sure. |
| 18:14:15 | Araq | but in this case I see the opportunity to succeed |
| 18:14:15 | apriori_ | but really... I somehow really hate the khronos group... they always come up with completely broken DSL designs |
| 18:17:13 | apriori_ | e.g...no support for actual "shared routines inclusion".. something like the simple #include in C is not supported in opencl, one has to manually concatenate the sources |
| 18:17:33 | apriori_ | and then of course the compiler messes up the line numbers |
| 18:18:02 | Tasser | apriori_, uh-oh. wasn't one of the points of llvm that it produces better error messages than gcc? |
| 18:18:16 | Araq | how much work do you think it is to adapt a C code generator to an opencl one? |
| 18:18:17 | Tasser | same in the ruby world, rubinius produces better error messages than cruby... |
| 18:18:22 | apriori_ | Tasser: well, that doesn't help here.. if there not even the dumbest module system included |
| 18:18:29 | Tasser | apriori_, wtf. |
| 18:18:47 | apriori_ | Tasser: same with with the GL shader language |
| 18:18:53 | apriori_ | no include statement... |
| 18:18:57 | Tasser | Araq, are you sure you need frame pointers in javascript as well? |
| 18:19:05 | apriori_ | while cuda is even able to include normal c++ in its code |
| 18:19:19 | apriori_ | Araq: well, I can |
| 18:19:22 | Araq | Tasser: the stack traces they enabled are incredibly useful, so yes |
| 18:19:23 | apriori_ | I can't really tell |
| 18:19:32 | apriori_ | opencl is pretty much C99 |
| 18:19:41 | Tasser | Araq, how about speed? |
| 18:19:50 | Araq | Tasser: debug vs. release mode? |
| 18:19:58 | Tasser | Araq, point |
| 18:20:37 | apriori_ | Tasser: not to mention that debugging opencl stuff is a mere nightmare... its like good old pre-printf debugging days |
| 18:20:55 | apriori_ | some vendors have a "printf extension" - one really should laugh about calling that an extension |
| 18:21:11 | Araq | apriori_: that's exactly when a code generator helps |
| 18:21:19 | apriori_ | Araq: yeah, indeed. |
| 18:21:30 | apriori_ | but if you transform source, you will need the same stuff for a custom debugger |
| 18:22:00 | apriori_ | you wrote compilers yourself.. I guess you know this quickly becomes non-trivial :P |
| 18:22:53 | Araq | well nimrod supports #line generation |
| 18:23:09 | Araq | and zahary frequently uses it with UI debuggers |
| 18:23:15 | apriori_ | one thing the khronos group messed up again (just like they did with the GL shader language), is, that they simple don't get, that its bad designt to separate stuff from the source which is absolutely crucial that its part of the source |
| 18:23:20 | apriori_ | ah, interesting |
| 18:23:54 | Araq | I don't, I use command line gdb or the nimrod debugger or simply 'echo' |
| 18:24:14 | apriori_ | yeah, I really liked the embedded debugger.. it was really impressive |
| 18:24:28 | apriori_ | nice idea... never saw that anywhere |
| 18:24:50 | Araq | oh cool people use it :-) |
| 18:25:03 | apriori_ | about that thing which is severely messed up: arrays must have compile-time constant sizes |
| 18:25:36 | Araq | not entirely true |
| 18:25:43 | apriori_ | which is kinda stupid, because often one wants to allocate local memory on the device suitable for the specs of the device - no support from opencl of any kind for that |
| 18:26:06 | Araq | you know about openarray and seq, right? |
| 18:26:13 | apriori_ | Araq: in opencl ;) |
| 18:26:15 | apriori_ | not nimrod |
| 18:26:23 | Araq | oh i see :-) |
| 18:27:03 | apriori_ | so one ends up writing code which is hardwired for a specific "minimum device".. and the code will scale "bad at best" for different device.. so much to device agnostic design |
| 18:27:34 | Araq | actually i stole the embedded debugger idea from smart eiffel :-) |
| 18:27:36 | apriori_ | I guess I should really write a hate mail to khronos ^^ |
| 18:28:01 | apriori_ | ah, interesting.. |
| 18:28:09 | apriori_ | I heard about eiffel.. but never used it |
| 18:28:33 | Araq | i dont like eiffel ;-) |
| 18:28:42 | Tasser | Araq, how do I invoke the embedded debugger btw? |
| 18:29:04 | apriori_ | wasnt one of its key features easy message passing for multiprocessing? |
| 18:29:13 | apriori_ | Tasser: you alter the compile args |
| 18:29:23 | apriori_ | Tasser: and then the debugging stuff gets compiled into the executable |
| 18:30:33 | apriori_ | Tasser: http://nimrod-code.org/endb.html |
| 18:32:50 | apriori_ | actually i think its a very good idea to make a debugger part of the language itself |
| 18:33:08 | apriori_ | it saves from a hell lot of "debugger X sucks vs Y and platform Z" issues |
| 18:33:38 | apriori_ | or well, the compiler, of course, not the language |
| 18:35:20 | apriori_ | Tasser: haven't you actually been in the D community? |
| 18:35:26 | apriori_ | I recall your name from there... |
| 18:35:29 | Tasser | apriori_, nope |
| 18:35:37 | apriori_ | hm, ok |
| 18:35:44 | Tasser | I really gotta change name |
| 18:35:48 | apriori_ | ^^ |
| 18:35:55 | apriori_ | have you been confused a lot? |
| 18:36:01 | Tasser | just in here |
| 18:36:03 | Tasser | but two times already |
| 18:36:06 | apriori_ | hehe |
| 18:39:42 | shevy | lol |
| 18:39:48 | shevy | seems like apeiros_ on #ruby ;) |
| 18:40:16 | Araq | Tasser: just write something on D's forum |
| 18:40:25 | Araq | then you can say "yes I'm the one from D" |
| 18:41:50 | apriori_ | ^^ |
| 18:43:42 | Araq | you may start with the question: "what's the point of improving onto C++ if C++ is such a clusterfuck to begin with?" :D |
| 18:44:26 | apriori_ | I actually see good points in D.. but also some bad points that can easily evolve like the problems with C++ |
| 18:44:53 | apriori_ | e.g. the template mixins.. very handy stuff, but a nightmare to debug and a nightmare to maintain. |
| 18:44:53 | Araq | sure it wasn't exactly my opinion |
| 18:44:59 | apriori_ | ;) |
| 18:45:12 | Araq | but it's a question that needs to be answered IMHO |
| 18:45:19 | apriori_ | yeah, definetly |
| 18:45:32 | apriori_ | and another problem D really has, as a whole, is lack of focus.. |
| 18:45:48 | apriori_ | like.. ffs.. get the GC useful instead of improving on CTFE first. |
| 18:46:14 | Araq | well it's optimized for popularity and hype |
| 18:46:30 | Tasser | as is php? ^^ |
| 18:46:36 | apriori_ | yes.. but if something tries to be a successor of C++, performance is key. |
| 18:46:45 | Araq | a bit like C# ... |
| 18:47:00 | Araq | but C# has manpower attached to it and it shows |
| 18:47:10 | apriori_ | yeah, the problem is.. with all these C-ish languages... |
| 18:47:29 | Trixar_za | Not just manpower, but Microsoft pretty much pushing it everywhere |
| 18:47:38 | apriori_ | they aren't C-ish, because C/C++ is so awesome.. they're at, because we damn programmers are so damn lazy to unlearn and relearn |
| 18:48:07 | Araq | true |
| 18:48:33 | Araq | apparently D's const system is broken wrt delegates ;-) |
| 18:48:44 | Araq | they just found out :D |
| 18:48:59 | apriori_ | wrt? |
| 18:49:06 | apriori_ | typo or some abbriviation I don't know? |
| 18:49:07 | Araq | "with respect to" |
| 18:49:11 | apriori_ | ok |
| 18:49:35 | apriori_ | yeah.. the const system is not really "thought out till the end" |
| 18:49:53 | Araq | things like that need to be mathematically sound |
| 18:49:54 | apriori_ | there is a reason java doesn't have one with the exception of the final marker |
| 18:49:57 | apriori_ | yep |
| 18:50:18 | Araq | you need to modell it in agda and prove it correct |
| 18:50:53 | Araq | unfortunately nimrod has a hole too and I need to prove my solution :-) |
| 18:51:02 | apriori_ | which one? |
| 18:51:22 | Araq | https://github.com/Araq/Nimrod/issues/124 |
| 18:51:53 | Araq | but I'm too stupid to do so and I also lack the time |
| 18:52:11 | apriori_ | too stupid for the proof? :P |
| 18:52:18 | Araq | yes :-) |
| 18:52:33 | apriori_ | well, I suck in that regard.. there is a reason why we got 2 different study direction at my university |
| 18:52:34 | Araq | need to learn more about formal semantics to do it |
| 18:52:54 | apriori_ | I understand. |
| 18:53:01 | apriori_ | yeah.. that whole stuff is not really easy. |
| 18:53:20 | Araq | I'm quite sure the rest of the language is sound though |
| 18:53:28 | apriori_ | the D inventor also lack theory background a bit... |
| 18:53:38 | Araq | I noticed ;-) |
| 18:54:55 | apriori_ | about languages that definetly suck... take a look at latex :P |
| 18:55:02 | Trixar_za | Hey, maybe I should invent a Language then. I lack all sorts of background |
| 18:55:05 | apriori_ | its nice what one can do with it.. but its a mess throughout |
| 18:55:15 | Araq | but hey unless you're rob harper there is always lots of stuff you don't know about programming semantics and type systems |
| 18:55:26 | apriori_ | yeah... |
| 18:55:37 | apriori_ | and as already stated.. I'm definetly also not strong on theory |
| 18:55:42 | Araq | it's a deep ocean |
| 18:55:56 | apriori_ | I study "applied computer science with physics"... |
| 18:55:57 | Tasser | apriori_, org-mode provides the good old 80-20 abstraction over latex ;-) |
| 18:56:02 | Trixar_za | MTSUAIG |
| 18:56:12 | Trixar_za | ^--- future language's name |
| 18:56:16 | Tasser | apriori_, nice, I studied a bit of physics ;-) |
| 18:56:24 | Trixar_za | Making This Shit Up As I Go |
| 18:56:45 | apriori_ | Trixar_za: one can definetly easily find that "unique" name with google... |
| 18:56:59 | apriori_ | Trixar_za: but none would be able to pronounce it.. or type it correctly at the 1st time ;) |
| 18:57:26 | apriori_ | Tasser: yeah, but physics is only a 2nd subjects.. so its by no means comparable to have it as a main subject |
| 18:57:27 | Trixar_za | How about MUS? |
| 18:57:38 | apriori_ | Trixar_za: autocorrect to must |
| 18:57:45 | apriori_ | *autocorrected |
| 18:58:09 | Trixar_za | SIMU? |
| 18:58:23 | apriori_ | Trixar_za: "did you mean simulation?" :P |
| 18:58:36 | Trixar_za | No, Shit I Made Up |
| 18:58:37 | Trixar_za | :P |
| 18:58:40 | apriori_ | or Trixar_za: "did you mean sumo"? :) |
| 18:59:23 | Tasser | BTDTNTLTM? |
| 18:59:59 | Trixar_za | STAA? |
| 19:00:11 | Trixar_za | Shit To Annoy Araq? |
| 19:00:12 | Trixar_za | :P |
| 19:00:24 | Trixar_za | Sorry, I totally derailed this topic |
| 19:00:38 | apriori_ | np, Trixar_za, busy with university stuff anyway ;) |
| 19:01:29 | Araq | apriori_: instead of doing it the macro way, maybe you should hack the compiler for opencl support :-) |
| 19:01:40 | Araq | introduce a pragma {.opencl.} for procs |
| 19:01:44 | Tasser | Trixar_za, successful troll is successful? |
| 19:01:47 | apriori_ | Araq: yeah, that was another idea |
| 19:01:58 | Araq | and they are then compiled into an opencl file |
| 19:02:00 | apriori_ | Araq: because.. actually the macro needs the very same information |
| 19:02:25 | Araq | the macro would end up re-implementing parts of the C code gen I'm sure |
| 19:02:39 | Araq | and the compile times would suck |
| 19:02:40 | apriori_ | if possible I would really prefer an in-language solution though.. or the features needed to do that within the language |
| 19:02:53 | Araq | well yes |
| 19:02:54 | apriori_ | that would actually make the language extremely powerful for this (not that uncommong) case |
| 19:02:58 | Araq | that's what I'm talking about |
| 19:05:40 | Araq | you should write some design document about it :-) |
| 19:05:47 | apriori_ | uff |
| 19:05:53 | apriori_ | question is.. am I qualified :P |
| 19:05:54 | Araq | so that we have a starting base to discuss :P |
| 19:06:07 | Araq | well you're around here |
| 19:06:15 | Araq | and all the other people don't care |
| 19:06:22 | Araq | so that makes you qualified :-) |
| 19:06:22 | apriori_ | yeah, maybe.. |
| 19:06:41 | apriori_ | it will take a while though.. but I will think about, how one could implement that. |
| 19:06:53 | apriori_ | actually.. I think.. there actually was a language wihich pretty much did that... |
| 19:06:58 | apriori_ | don't recall the name |
| 19:07:14 | apriori_ | it allowed attaching "subcompilers", one could say... |
| 19:07:21 | apriori_ | and allowed extending the syntax etc. |
| 19:08:59 | Araq | "subcompiler" I like it |
| 19:10:00 | Trixar_za | And easter eggs. If I cared enough to write it, I would include lots and lots of easter eggs. Mostly to annoy people. |
| 19:10:25 | Araq | lol? everybody loves easter eggs |
| 19:10:32 | apriori_ | Araq: not in a language ;) |
| 19:10:40 | apriori_ | "easter egg memory leak" ;) |
| 19:10:58 | Araq | I consider 'slurp' and 'gorge' easter eggs :-) |
| 19:11:39 | apriori_ | Araq: it was "seed7" http://seed7.sourceforge.net/ |
| 19:12:06 | Trixar_za | What is slurp and gorge? |
| 19:12:14 | Araq | seed7 doesn't support subcompilers afaik |
| 19:12:29 | apriori_ | yeah.. not really, it seems... |
| 19:12:59 | apriori_ | http://en.wikipedia.org/wiki/Extensible_programming#Programming_languages |
| 19:13:25 | apriori_ | plugin-infrastructure for th passes of the compiler... this easily gets very bloated. |
| 19:13:42 | Araq | hey I like the idea :-) |
| 19:13:50 | apriori_ | hehe, good ;) |
| 19:14:15 | Araq | nimrod's macros are defacto pass dependent too now |
| 19:14:40 | Araq | we have now both 'ordinary' and 'immediate' templates ... |
| 19:15:02 | apriori_ | ah, good |
| 19:16:30 | Araq | cool seed7 has a fixed number of exceptions |
| 19:16:39 | Araq | no inheritance for exceptions |
| 19:17:23 | Araq | it's either "memory", "numeric", "range", "file" or "illegal_action" |
| 19:17:30 | apriori_ | yeah, reading that |
| 19:17:35 | Araq | i like it |
| 19:17:47 | apriori_ | guess they simple don't want error handling being done with exceptions |
| 19:18:20 | Araq | no I think they don't like exception type proliferation |
| 19:18:37 | apriori_ | which I prefer, too... e.g. java makes the name of "exception" absurd... its not "exception" anymore if its a usual error case |
| 19:19:43 | Araq | well yes but it's great if you don't want exceptions :-) |
| 19:19:53 | Araq | Java's way is superior to Go's then |
| 19:20:04 | apriori_ | hm, what do you mean? |
| 19:20:12 | Tasser | apriori_, see python |
| 19:20:24 | Tasser | apriori_, ... coding with exceptions |
| 19:22:50 | Araq | in Go you have to propagate the error manually through the call stack |
| 19:23:00 | Araq | in Java you can do that automatically |
| 19:23:14 | apriori_ | yeah.. pass the error on e.g. with rethrows |
| 19:23:21 | Araq | and still "force" the programmer to handle exceptions with the "checked" exception feature |
| 19:23:44 | Araq | in practice it sucks |
| 19:23:59 | apriori_ | the problem I have with that.. is pure code aesthetics.... |
| 19:24:02 | Araq | but Go's approach sucks moreso IMHO |
| 19:24:15 | apriori_ | branching because of the try/catch thing |
| 19:24:29 | apriori_ | thats one thing I _really_ liked in D, with its "scope" statement |
| 19:24:41 | apriori_ | which created a more C-goto-like view on this issue |
| 19:24:42 | Araq | Nimrod has that already too |
| 19:24:56 | Araq | var x: TFile = open() |
| 19:25:02 | Araq | finally: x.close |
| 19:25:15 | Araq | it's not documented yet though |
| 19:25:22 | Tasser | Araq, aka it does not exist ;-) |
| 19:25:25 | Araq | zahary implemented it |
| 19:25:58 | apriori_ | interesting |
| 19:27:42 | Araq | Go's approach also completely breaks composability |
| 19:27:54 | Araq | f(g(x)) # do that with Go's error handling |
| 19:27:57 | Araq | you can't |
| 19:28:09 | Araq | in haskell you can introduce a monad to do it for you |
| 19:28:22 | Araq | in go this monad should be built-in I suppose |
| 19:28:42 | apriori_ | yeah.. I should definetly clone myself.. so that I one day can find the time to continue learning haskell ;) |
| 19:28:42 | Araq | too bad the Go people don't know what a monad is ;-) |
| 19:29:05 | Tasser | Araq, got a nice reading about it? |
| 19:32:55 | Araq | Tasser: damn lost the link .. |
| 19:33:06 | apriori_ | grr.. even 2 screens are not enough :/ |
| 20:12:43 | * | fowl joined #nimrod |
| 20:18:23 | Araq | hi fowl |
| 20:19:51 | fowl | sup |
| 20:20:54 | Araq | was it you who was interested in opengl? |
| 20:46:36 | fowl | no im interested in sdl :> |
| 20:48:14 | Araq | oh alright |
| 20:48:23 | Araq | well there is nimgame now, check it out :-) |
| 20:48:33 | Araq | still have to try the game that has been written in it |
| 20:48:50 | fowl | do you have a link |
| 20:48:57 | fowl | google is not helpful |
| 20:49:18 | apriori_ | Araq: isnt it somehow interesting, that, whenever a "new" language comes out... game devs are among the first who try to create something with it? |
| 20:50:30 | Araq | fowl: https://github.com/Vladar4/nimgame |
| 20:50:56 | Araq | I heard it doesn't build with 0.8.15, but only with 0.8.14 |
| 20:51:33 | Araq | I'll fix that next week or so |
| 20:52:44 | Araq | apriori_: I don't know |
| 20:53:08 | Araq | haven't experienced that |
| 20:53:08 | apriori_ | Araq: pure evidence that current most used game dev languages suck :P |
| 20:53:40 | Araq | I'd say the first ones are the people who can't program and blame the language |
| 20:53:54 | apriori_ | first ones? |
| 20:53:54 | Araq | and think they will be able to in the new language |
| 20:54:06 | Araq | the first who try the language |
| 20:54:12 | apriori_ | well, partly... maybe. |
| 20:54:34 | Tasser | as soon as a language becomes popular, it's dragged down by politics and legacy... |
| 20:54:42 | apriori_ | I mean.. if language wouldn't matter.. we would simply describe every program as a turing machine table chart |
| 20:54:42 | Tasser | guess why there is no string in C :-) |
| 20:55:03 | Tasser | apriori_, and carve for abstraction? |
| 20:55:11 | apriori_ | Tasser: :P |
| 21:01:35 | Trixar_za | I actually have a copy of nimgame. You say it doesn't work with the git version? |
| 21:05:16 | Araq | Trixar_za: dom96 said that |
| 21:06:13 | Trixar_za | I wonder why Vladar never included the demo with the github version |
| 21:06:45 | fowl | doesnt build with 0.8.15 here |
| 21:08:33 | Trixar_za | common.nim(28, 7) Error: identifier expected, but found 'keyword do' |
| 21:09:09 | Araq | well yes 'do' is keyword now ... |
| 21:09:40 | Trixar_za | Well that explains a lot |
| 21:10:28 | Trixar_za | Also note my copy is behind on a few revisions :P |
| 21:11:04 | Araq | that may not be bad as I push changes to see nimbuild's results :P |
| 21:11:13 | Araq | and I always break some test |
| 21:11:53 | Araq | and then people fill in bug reports "omg this doesn't work with latest github version anymore" -.- |
| 21:12:22 | Araq | the installation docs should mention that somewhere I guess |
| 21:14:15 | apriori_ | Araq: or you should run your tests on a separate branch.. and only merge working versions |
| 21:14:40 | Araq | I'm too lazy to work with branches |
| 21:15:06 | apriori_ | you could also setup hooks for that |
| 21:15:11 | Araq | heck I'm too lazy to clean up the git repo and prune it |
| 21:15:22 | apriori_ | like.. automerge stuff into stable line which passes tests |
| 21:15:25 | Araq | so that it doesn't include the old generated C code |
| 21:15:42 | Araq | I could do a lot ... :P |
| 21:17:25 | Trixar_za | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
| 21:17:28 | Trixar_za | Oh I hate you |
| 21:17:29 | Trixar_za | :P |
| 21:18:47 | Araq | what did you do? |
| 21:19:18 | Trixar_za | replaced all the do( with do2( |
| 21:19:39 | Araq | oh yeah I think dom96 said that too :-) |
| 21:19:56 | Araq | do a 'koch boot' and pastebin the stack trace of the compiler please |
| 21:20:16 | Trixar_za | lol |
| 21:20:27 | Trixar_za | This is the 0.1 code though |
| 21:20:31 | Trixar_za | with the demo |
| 21:23:31 | Araq | well? |
| 21:27:39 | Trixar_za | Nope, even with the 0.2 code (fixed) it still breaks |
| 21:27:51 | Trixar_za | I replaced do with rend (since that what it does, it renders) |
| 21:28:16 | Trixar_za | Anyway, let's put this where I can test it with koch |
| 21:28:16 | Trixar_za | :P |
| 21:29:44 | Tasser | apriori_, just give him some scripts ;-) |
| 21:30:12 | apriori_ | Tasser: I would need to see the current integration |
| 21:30:25 | Tasser | apriori_, there is none? ^^ |
| 21:30:39 | fowl | how do I build ths |
| 21:32:01 | apriori_ | Tasser: no, of the build/test system |
| 21:33:50 | Araq | apriori_: there is nimbuild and we use github hooks so that a rebuilt is triggered per push |
| 21:33:59 | apriori_ | Araq: ok |
| 21:34:02 | Araq | sorry if that was already obvious to you |
| 21:34:12 | Araq | but I don't know much about nimbuild |
| 21:34:16 | apriori_ | Araq: nope, not really... but I thought in that way. |
| 21:34:18 | Araq | only skimmed its code once |
| 21:34:40 | Araq | it's all dom96's work :-) |
| 21:35:12 | Araq | I'm frightened by nimrod code not written by me :D |
| 21:35:44 | Araq | as I keep thinking how it pushes my poor compiler ... |
| 21:36:45 | Trixar_za | I don't think it's including the nimgame libraries :/ |
| 21:37:13 | Tasser | apriori_, I'm kind of the official feature pusher ;-) |
| 21:37:20 | apriori_ | Tasser: ah, ok |
| 21:37:26 | apriori_ | yeah, my idea would be: |
| 21:37:33 | apriori_ | develop in a testbranch |
| 21:37:41 | apriori_ | and only work fast-forward to master |
| 21:37:51 | apriori_ | so that a script can merge fast-forwad on success |
| 21:37:54 | Tasser | apriori_, as in test wherever stuff works... |
| 21:38:04 | Trixar_za | Nope |
| 21:38:13 | Trixar_za | Just run koch boot |
| 21:38:17 | Trixar_za | :P |
| 21:38:24 | Tasser | by writing code that would never come to Araq's mind :-) |
| 21:38:54 | Tasser | apriori_, have you ever looked at the stats? the test success is approx. 99% |
| 21:39:41 | Araq | apriori_: I like your idea |
| 21:39:56 | fowl | Trixar_za, where is the example game you speak of |
| 21:40:13 | Tasser | ecmas.nim - no |
| 21:40:15 | Tasser | uh |
| 21:40:18 | Araq | as it means I can continue to do rare official releases |
| 21:40:25 | Araq | which are incredibly time consuming |
| 21:40:45 | Tasser | dom96, how about a jquery plugin that can do table sorting n stuff on the nimbuild page? :-) |
| 21:41:10 | Araq | dom96 is on holidays ... ;-) |
| 21:41:54 | Trixar_za | http://forum.nimrod-code.org/t/19 @ fowl |
| 21:42:13 | Trixar_za | Btw, I tried --debugger:on and --debuginfo |
| 21:42:15 | Tasser | Araq, blubb |
| 21:43:08 | Araq | Trixar_za: does the compiler crash or the resulting program? |
| 21:43:20 | Trixar_za | compiler |
| 21:43:40 | Araq | thank god |
| 21:44:00 | Araq | well what about a stack trace of the compiler? |
| 21:44:07 | Trixar_za | What the, the error is different |
| 21:44:08 | Trixar_za | lol |
| 21:46:07 | fowl | Trixar_za, ty |
| 21:47:34 | Trixar_za | Right, I think I may have broken my nimrod |
| 21:47:37 | Trixar_za | lol |
| 21:52:01 | Tasser | Araq, wouldn't there be a better idea than saving the generated source in git? |
| 21:52:29 | Araq | omg here we go again |
| 21:53:18 | Araq | yes there would |
| 21:53:27 | Araq | zufrieden? |
| 21:53:54 | Araq | and now don't be bother me about it again |
| 21:55:54 | apriori_ | Tasser: what generated source? |
| 21:59:02 | Tasser | apriori_, build.zip |
| 21:59:39 | apriori_ | Tasser: k |
| 21:59:45 | apriori_ | investigating git hooks, btw. |
| 22:26:37 | Trixar_za | Hint: imageex [Processing] |
| 22:26:37 | Trixar_za | SIGSEGV: Illegal storage access. (Attempt to read from nil?) |
| 22:26:46 | Trixar_za | So it's probably something in imageex causing it |
| 22:27:04 | Trixar_za | Anyway, going to bed. Night :P |
| 22:27:07 | Araq | Trixar_za: which part of 'stack trace' is so hard to understand? |
| 22:27:38 | Trixar_za | The part including 'stack' and 'trace' |
| 22:28:06 | Araq | alright ;-) |
| 22:28:12 | Araq | I should sleep too |
| 22:28:14 | Araq | good night |
| 22:29:20 | * | Trixar_za is now known as Trix[a]r_za |
| 22:33:30 | * | ANASLEX left #nimrod ("LOLeaving") |
| 23:09:55 | * | apriori_ quit (Quit: Konversation terminated!) |