| 02:09:11 | * | zahary quit (Quit: Leaving.) |
| 02:13:45 | * | Trixar_za is now known as Trix[a]r_za |
| 04:23:11 | * | ccssnet quit (*.net *.split) |
| 04:23:12 | * | CodeBlock quit (*.net *.split) |
| 04:23:12 | * | Trix[a]r_za quit (*.net *.split) |
| 04:28:30 | * | ccssnet joined #nimrod |
| 04:28:30 | * | Trix[a]r_za joined #nimrod |
| 04:36:23 | * | CodeBlock joined #nimrod |
| 04:39:37 | * | CodeBlock quit (Changing host) |
| 04:39:37 | * | CodeBlock joined #nimrod |
| 08:06:47 | * | Araq_ joined #nimrod |
| 08:56:09 | * | Araq_ quit (Read error: Connection timed out) |
| 08:57:05 | * | Araq_ joined #nimrod |
| 08:59:43 | * | Trix[a]r_za is now known as Trixar_za |
| 09:17:20 | * | Boscop joined #nimrod |
| 10:02:04 | * | zahary joined #nimrod |
| 10:02:13 | * | Trixar_za is now known as Trix[a]r_za |
| 10:18:54 | * | Boscop quit (Ping timeout: 240 seconds) |
| 12:45:06 | Araq_ | ping zahary |
| 12:45:45 | zahary | hi |
| 12:46:12 | * | Boscop joined #nimrod |
| 12:47:00 | Araq_ | turns out I was right and your new typeinfo handling in the C backend is wrong ;-) |
| 12:47:16 | Araq_ | because there can be cyclic dependencies |
| 12:47:36 | Araq_ | between modules thanks to generics |
| 12:48:05 | zahary | so what happens when there is a cyclic depency? |
| 12:48:08 | Araq_ | however there seems to be an easy fix which even improves code size :-) |
| 12:48:23 | Araq_ | well the generic is outputted in the defining module |
| 12:48:37 | Araq_ | but it's T is outputted in the other module |
| 12:48:57 | zahary | and it's just not visible? fails to compile at all? |
| 12:49:20 | Araq_ | no, problem is that it sets: field.typ = externType; |
| 12:49:28 | Araq_ | however externType is still NULL |
| 12:49:38 | zahary | I see |
| 12:49:53 | Araq_ | but as I said, I've implemented a nice fix |
| 12:50:16 | Araq_ | instead of NimType* NTI0 |
| 12:50:35 | Araq_ | we use NimType NTI0 and then &NTI0 |
| 12:51:00 | Araq_ | the linker resolves address-of-forwarded-data for us :-) |
| 12:51:18 | zahary | I think I know what are you talking about - I wondered why this indirection is needed myself |
| 12:52:48 | Araq_ | the code used to use indices instead of pointers |
| 12:53:05 | Araq_ | and this recursive logic was quite hard to get right ;-) |
| 12:53:20 | Araq_ | so when I transformed it to pointers for efficiency I was lucky when it worked |
| 12:53:31 | Araq_ | and never bothered to optimize the indirection away |
| 12:53:39 | Araq_ | (it's in my todo.txt btw) |
| 12:53:40 | zahary | there was a lot of action with arrays going on in the main function that seemed like it can be moved to regular global vars |
| 12:54:29 | Araq_ | indexes are nicer as you can use 16bits for them |
| 12:54:40 | zahary | btw I still think it's better to compile the generics in their owner module (potentially in a part.N.cpp file) - this way when you modify a generic, there will be a single module to recompile |
| 12:54:54 | Araq_ | but were a PITA to work with |
| 12:57:14 | Araq_ | the typeinfo stuff should work with DLLs, right? |
| 12:57:27 | Araq_ | we don't every compare types by their address I think |
| 12:57:42 | Araq_ | we get duplicated data, but structurally equivalent |
| 12:59:35 | * | q66 joined #nimrod |
| 13:00:30 | Araq_ | I don't mind part.N.cpp too much if there is a way to deactivate it for debugging |
| 13:00:49 | Araq_ | but then there is always the risk the bug only shows up in part.N.cpp ;-) |
| 13:03:39 | zahary | the ID problem that causes recompilation of untouched modules is a bigger issue right now and would look at it first |
| 13:06:19 | Araq_ | true |
| 13:06:40 | Araq_ | I also found a symbolfiles bug that I'm clueless about |
| 13:06:57 | Araq_ | edited some modules, recompiled --> wrong ID used |
| 13:08:02 | zahary | wrong wrong or just unnecessary recompilation again? |
| 13:09:46 | Araq_ | it's tempting to read the ID from the generated C code somehow ... |
| 13:10:32 | Araq_ | wrong wrong and linking failed |
| 13:11:07 | Araq_ | but it was 2 projects using the same dependent module |
| 13:12:03 | Araq_ | but this is all a PITA to debug |
| 13:12:33 | Araq_ | state between compiler runs in some rodfile you can't really browse ... |
| 13:13:30 | Araq_ | I guess we need a "disassembler" for rodfiles |
| 13:17:34 | zahary | why is it hard to read the ID from the generated source? I had a number of ideas about alternative ways to store the mergeable data (it can be in a separate file that is included from the static source). Also, since we delay the writing to disk till the end now, it's also possible to use a single unified structure for metadata that is serialized in the begging of the file instead of the current ad-hoc mechanism with many various comments |
| 13:18:52 | Araq_ | if you write all data at the end that sucks for incremental compilation anyway |
| 13:19:33 | Araq_ | often some module does NOT compile properly and then you need to ensure to store all the other modules properly nevertheless |
| 13:19:38 | zahary | you mean you can not start the C compiler, before the nimrod compiler is done? |
| 13:20:04 | Araq_ | I mean that often you recompile only to get a semcheck error |
| 13:20:15 | Araq_ | then you fix it, recompile again ... |
| 13:21:13 | Araq_ | and you need to ensure anyway to have this serialization step at module level |
| 13:21:14 | zahary | hmm, are we talking about the same thing - what I meant is that we now keep files "open", because more type info can be added to them |
| 13:21:18 | Araq_ | not at project level |
| 13:23:07 | zahary | so it's possible to delay writing of any metadata (like IDs) in the same fashion (you just update it as fields in BModule) |
| 13:24:43 | Araq_ | sure but I'm more concerned with on the fly "nimrod check/suggest" |
| 13:25:05 | Araq_ | so I'd rather make the compiler a service now |
| 13:25:28 | zahary | I cannot argue with that idea :) |
| 13:25:29 | Araq_ | and then you don't have to recompile that often too |
| 13:25:44 | Araq_ | and there is no serialization to worry about |
| 13:28:26 | Araq_ | and it's not hard to read the ID from the generated source but *wrong* as the backend shouldn't set IDs ... |
| 13:29:10 | Araq_ | in fact, the merge info in the .c file is already a hack |
| 13:29:38 | zahary | well, sure - I didn't go ahead with any of those ideas mainly because mandatory rod files sounded more sensible long-term |
| 13:30:36 | Araq_ | but yeah maybe we need to make a virtue out of necessity |
| 13:30:59 | Araq_ | and have all the stuff in the .c file/ the backend |
| 13:31:27 | Araq_ | and query the backend "gimme the ID for this" |
| 13:35:36 | zahary | how much compiler as a service do you imagine? will you accept patches to the sem data structures that will potentially enable delta updates on a symbol level? |
| 13:36:27 | zahary | I have though for a while about what changes will be required |
| 13:38:11 | Araq_ | seriously? delta updates on a symbol level? why? |
| 13:38:40 | Araq_ | or do you mean symtab patching like for templates? |
| 13:39:45 | zahary | oh, maybe it's not needed - it just seems unnecessary to compile the whole module on every few keystrokes in the text editor (it could prove to be fast enough tho) |
| 13:40:35 | Araq_ | what I imagine is that we have an http API to the compiler |
| 13:40:37 | zahary | I want to remove patching, but allow for multiple definitions to be "remembered" and properly selected/updated |
| 13:41:33 | Araq_ | and the editor can send a whole buffer to the compiler to recompile without /tmp stuff |
| 13:42:53 | Araq_ | or maybe only the delta |
| 13:43:38 | Araq_ | but then the compiler would need to do oldstringPrefix & newPart & oldstirngSuffix and recompile this as a whole anyway |
| 13:48:09 | zahary | the problem is I want the editor to be able to display much more information than syntax highlighting and code errors - I have a number of per features where the compiler annotates the source code with various labels, links to other places, reports, etc - If the interface is "take this whole module, tell me everything about it" I fear there will be limits to what is possible (not enough bandwidth so to speak) |
| 13:48:24 | zahary | * pet features * |
| 13:51:08 | Araq_ | like what? |
| 13:51:50 | Araq_ | it's better to do "take this whole module" if the editor understands the entity you're currently editing |
| 13:53:30 | Araq_ | *to do than |
| 13:54:02 | Araq_ | but for a start I'm gonna copy haxe's approach |
| 13:54:39 | Araq_ | (don't know yet what their protocol looks like) |
| 13:55:05 | Araq_ | haxe's macro system is quite like nimrod's btw except they have no overloading |
| 13:55:30 | Araq_ | and thus don't semcheck the arguments passed to a macro at all |
| 13:55:47 | Araq_ | and instead have an API so that the macro can requrest semchecking of an argument |
| 14:00:54 | zahary | it's hard to explain what I imagine without a context. from my experience with generative programming in C++, what's complicates such systems is the fact that the generated code and data is much less visible so it becomes harder to debug - In many situations I have imagined that if the generative approach was complemented with some custom created reports of what was generated the problems will be largely eliminated so I want such support in the language and th |
| 14:01:04 | zahary | haxe has a compiler server now? |
| 14:01:45 | Araq_ | yes |
| 14:01:51 | Araq_ | since a long time I think |
| 14:01:57 | Araq_ | I have to go, see you later |
| 14:02:01 | * | Araq_ quit (Quit: ChatZilla 0.9.88.2 [Firefox 14.0.1/20120713134347]) |
| 14:07:19 | zahary | since april actually, from 2.09 |
| 15:17:52 | dom96 | hello |
| 15:40:12 | shevy | dom96! |
| 15:40:17 | shevy | my favourite girl here |
| 15:40:23 | dom96 | lolwut? |
| 15:40:26 | shevy | hehe |
| 15:40:29 | * | zahary quit (Quit: Leaving.) |
| 15:40:30 | shevy | dom96, I realized something new lately |
| 15:40:37 | dom96 | I ain't no girl! |
| 15:40:45 | shevy | I have one project, in ruby, which has about 250 different files right now |
| 15:40:53 | shevy | and it is getting too big and unwieldy |
| 15:41:17 | shevy | I think I need an editor where I edit one project, as if it would be one file alone |
| 15:41:32 | shevy | (and that "file" would be "assembled" from the different files) |
| 15:41:44 | shevy | my brain is not good enough to deal with big projects :( |
| 15:41:56 | shevy | can you add something like this to Aporia? :> |
| 15:42:19 | dom96 | 250 files wtf |
| 15:43:04 | dom96 | I don't really see that feature being useful for me. |
| 15:43:45 | dom96 | I should have actually asked what kind of project it is. |
| 15:44:08 | dom96 | It's not like you're editing 250 files at the same time though... |
| 15:46:58 | dom96 | But yeah, sorry. I doubt I will implement this. |
| 15:47:30 | shevy | yeah, not at the same time |
| 15:47:56 | shevy | it's more like this routine: I notice a bug, or I want to add a feature. Before I can even start, I need to locate where the bug exists, or where the feature should reside / put into |
| 15:48:09 | shevy | :( |
| 15:48:18 | dom96 | And you think having a single file with 50 million lines of code will help with that? :P |
| 15:48:20 | shevy | what strategy do you use when a project becomes really huge dom96? |
| 15:48:23 | shevy | hmm |
| 15:48:24 | shevy | a bit |
| 15:48:25 | shevy | :) |
| 15:48:34 | shevy | 50 million lines is quite a lot though |
| 15:48:46 | dom96 | I was exaggerating a bit :P |
| 15:48:48 | shevy | I think I am only at about ... 50.000 lines of code in ruby at maximum |
| 15:48:53 | shevy | after 7 years or such |
| 15:49:03 | shevy | and the less I have to add the better! |
| 15:49:14 | dom96 | I mostly remember where things are. If I can't I grep for them. |
| 15:49:40 | dom96 | Aporia will eventually let you search for things in multiple files. |
| 15:49:42 | shevy | hehe |
| 15:49:48 | shevy | I grep all the time :( |
| 15:50:13 | shevy | it's a part of the workflow I don't really like. I use GUI based editors and it feels a bit at odds |
| 15:50:19 | shevy | with vim, I guess it is more natural to use grep |
| 15:50:37 | shevy | dom96, what editor do you use most the time btw? did I ask this already... I think I asked this months ago hmmmm |
| 15:50:38 | dom96 | Yes, well it does require you to switch to the command line. |
| 15:50:45 | dom96 | That's why I want to let Aporia do it. |
| 15:50:55 | dom96 | Obviously Aporia :P |
| 15:51:26 | shevy | hmm and before aporia? |
| 15:51:40 | dom96 | gedit |
| 15:51:44 | shevy | ahhhh |
| 15:51:49 | shevy | you are really my brother then :) |
| 15:52:04 | dom96 | hehe |
| 15:52:11 | dom96 | I've tried Vim and Emacs but never got into them |
| 15:52:20 | dom96 | They're too far from the norm. |
| 15:52:25 | dom96 | IMO |
| 15:52:39 | shevy | yeah |
| 16:10:26 | * | Boscop quit (Ping timeout: 252 seconds) |
| 16:11:49 | reactormonk | Linux is too far away from the norm. |
| 16:15:31 | * | Reisen quit (Remote host closed the connection) |
| 16:40:05 | * | shevy quit (Ping timeout: 268 seconds) |
| 16:44:55 | Araq | ping fowl |
| 16:52:38 | * | shevy joined #nimrod |
| 16:57:55 | Araq | reactormonk: what about implementing a random number generator in pure nimrod? |
| 17:24:43 | * | Boscop joined #nimrod |
| 17:33:12 | Araq | dom96: my todo contains: implement ``--script:sh|bat`` command line option; think about script generation |
| 17:33:45 | Araq | what should we do with that? make the compiler output some JSON so that external tools can process it? |
| 17:34:22 | dom96 | Sure. |
| 17:34:49 | dom96 | But if you're going to be playing around with that, what about the other packaging issue? |
| 17:35:01 | fowl | yo |
| 17:35:02 | * | dom96 can't remember exactly what it was |
| 17:35:10 | fowl | oh yeah the tests |
| 17:35:34 | dom96 | * Add support for prefixes in install.sh, so that you can install to prefix/usr/bin and it will just work (TM). |
| 17:35:34 | dom96 | * Nimrod should look for config files in /etc/nimrod not in /etc/ (This creates a mess of config files in /etc) |
| 17:35:37 | dom96 | Araq: ^^ |
| 17:35:38 | dom96 | :P |
| 17:36:27 | Araq | dom96: I thought you patched the prefix stuff |
| 17:36:29 | fowl | i like the way it works now, i just symlinked nimrod into /usr/bin and it works fine |
| 17:36:40 | dom96 | Araq: I don't think so. |
| 17:36:55 | Araq | fowl: symlinking does not work reliably for some reason |
| 17:37:12 | Araq | especially not on macosx |
| 17:37:36 | Araq | but I like it too |
| 17:37:49 | Araq | though I prefer to just update my $PATH |
| 17:38:04 | * | fowl quit (Quit: brb) |
| 17:38:19 | Araq | and dom96 I told you the config file system won't change *again* |
| 17:38:44 | Araq | (This creates a mess of config files in /etc) <-- yeah, that's how UNIX works :P |
| 17:38:48 | dom96 | This is a small change though. |
| 17:39:27 | * | Araq is looking at his /etc |
| 17:39:33 | dom96 | Packaging guidelines say that if an application uses multiple config files they should be put into /etc/AppName |
| 17:39:40 | dom96 | (For Debian at least IIRC) |
| 17:39:46 | dom96 | If only 1 then it can go to /etc |
| 17:39:58 | Araq | we used to have only one ... |
| 17:40:10 | Araq | I guess we have more now ... |
| 17:41:06 | Araq | well alright, but you implement it please :P |
| 17:41:57 | dom96 | ok, but then I doubt it will make it into 0.9.0... |
| 17:44:56 | Araq | fine, I'm doing it |
| 17:45:18 | Araq | er no |
| 17:45:29 | Araq | testing the installer has proven to be very time consuming |
| 17:45:35 | Araq | so after 0.9.0 |
| 17:56:12 | * | fowl joined #nimrod |
| 17:58:33 | Araq | so fowl, what do the tests say? |
| 18:00:00 | fowl | they're running now |
| 18:00:49 | Araq | alright, thanks |
| 18:09:12 | Araq | and I broke stuff ... :-/ |
| 18:11:46 | Araq | but it looks easy to fix |
| 18:12:21 | Araq | so dom96 |
| 18:12:43 | dom96 | yes? |
| 18:12:50 | Araq | what about fixing ftpclient etc.? |
| 18:13:47 | dom96 | I'm working on it :) |
| 18:14:25 | fowl | i wanted to talk about the SDL wrapper |
| 18:15:04 | fowl | i believe that all the functions that return int should actually return cint or int32 |
| 18:16:26 | Araq | probably |
| 18:16:50 | fowl | and i can fix the events to a union-type thing, i thought of two ways to do this, the first is i could inline the fields from each event into TEvent, this has the advantage of being compatible with the way it is right now, you could still do EvKeyboard() to change the event and you wouldnt have to change any of your existing code |
| 18:16:51 | Araq | the SDL C code doesn't use C's long, does it? |
| 18:16:56 | dom96 | Araq: What else is there to fix except ftpclient? |
| 18:17:37 | Araq | tircbot |
| 18:17:58 | Araq | I guess that's it |
| 18:18:11 | Araq | the other tests import ftpclient |
| 18:18:18 | fowl | or i could take the kind field out of each event and use them in the case statement, that would be more like what SDL has but it would make the EvConvs not work |
| 18:18:39 | Araq | fowl: be careful |
| 18:18:43 | dom96 | You just put NimBot in as a test? |
| 18:18:55 | Araq | we tried that already and failed to get it binary compatible due to alignment issues |
| 18:19:33 | fowl | well i did that for SFML and it works |
| 18:19:55 | Araq | SFML uses unions too? |
| 18:20:13 | fowl | https://gist.github.com/3737049 |
| 18:20:27 | fowl | yea |
| 18:21:09 | Araq | fowl: that's nice but it should have generated testresults.html |
| 18:21:23 | fowl | ah |
| 18:21:25 | fowl | i see it |
| 18:21:34 | fowl | u want the html or json |
| 18:22:38 | Araq | html please |
| 18:23:14 | fowl | https://gist.github.com/3737049 |
| 18:26:07 | * | apriori_ joined #nimrod |
| 18:27:15 | Araq | hi apriori_ |
| 18:27:30 | Araq | I finally fixed you "actors" test program |
| 18:27:32 | Araq | *your |
| 18:27:46 | Araq | triggered 2 serious bugs :-) |
| 18:31:47 | apriori_ | Araq: hey, great.. thanks! |
| 18:31:58 | apriori_ | time to port over the parallelism shootouts, then :P |
| 18:32:04 | apriori_ | and maybe improve the message passing |
| 18:32:25 | Araq | yeah I have good ideas how to improve it |
| 18:32:30 | Araq | but brb |
| 19:03:58 | Araq | so, apriori_ |
| 19:04:21 | Araq | actors.nim deals with tasks and a task is supposed to not take much time |
| 19:04:50 | Araq | the reasons why deep copying is needed are: |
| 19:05:02 | Araq | a) prevents race conditions |
| 19:05:17 | Araq | as every thread deals with its own memory only |
| 19:05:22 | dom96 | How do you get the behaviour of old templates again? |
| 19:05:33 | Araq | dom96: .immediate, dirty |
| 19:05:39 | dom96 | thanks |
| 19:06:52 | Araq | b) the GC can work per thread only |
| 19:07:22 | Araq | but for b) we can do better than copying |
| 19:08:00 | Araq | we simply incRef the data before 'send' and decRef it again when the task is completed |
| 19:08:29 | Araq | within the worker thread the type should be converted/casted from 'ref T' to 'ptr T' |
| 19:08:59 | Araq | to prevent the compiler from emitting write barriers which are unnecessary anyway |
| 19:09:17 | Araq | of course this assumes that the thread only uses read access to the data |
| 19:10:23 | Araq | but the effect system that is growing in my mind will ensure that :-) |
| 19:12:05 | Araq | well? any opinion? |
| 19:14:09 | dom96 | ugh |
| 19:14:14 | shevy | Araq! let's cuddle! |
| 19:15:34 | shevy | reactormonk, I bought some kind of notebook today, it did cost 280 euro. it runs SuSE Linux hehe... the odd thing is... about 5 years ago, I bought a cheap laptop from fujitsu... also with linux. it did cost about 500 euro... weighs more, and is also much slower |
| 19:16:02 | shevy | going to find out whether nimrod runs on it or not tomorrow |
| 19:16:17 | fowl | shevy, http://www.youtube.com/watch?v=Emd5grRLhv0 |
| 19:16:38 | shevy | lol |
| 19:17:01 | shevy | you know weird stuff fowl |
| 19:17:44 | dom96 | Araq: https://gist.github.com/72536612071c62b8427a |
| 19:22:39 | reactormonk | shevy: ^^ |
| 19:22:58 | reactormonk | shevy: there at UT, they have a sponsorship from m$, therefore no linux. |
| 19:26:01 | Araq | dom96: alright, fixing it |
| 19:29:39 | dom96 | thanks |
| 19:35:20 | Araq | dom96: temp7.nim(507, 6) Error: undeclared field: 'setHandleWrite' :-/ |
| 19:35:37 | dom96 | Maybe I should just push my changes? |
| 19:35:57 | Araq | yeah |
| 19:36:12 | Araq | but note in the commit that it still doesn't work |
| 19:42:17 | dom96 | Araq: Done. |
| 19:55:34 | Araq | argh, dom96 your code is evil ;-) |
| 19:55:41 | Araq | inheritance + case object |
| 19:56:04 | dom96 | :P |
| 19:57:26 | dom96 | If it's easier to simply change ftpclient then do that :P |
| 19:57:40 | Araq | no, no, it's fine |
| 19:58:00 | Araq | I'm fixing it and it's good we have a test case for it :-) |
| 19:59:31 | dom96 | :) |
| 20:11:29 | * | silven quit (Quit: No Ping reply in 180 seconds.) |
| 20:11:50 | * | silven joined #nimrod |
| 20:15:19 | Araq | fowl: did you use a debug build of the nimrod compiler for running the tests? |
| 20:15:41 | fowl | YEA |
| 20:15:45 | fowl | yea* sry |
| 20:15:59 | Araq | that explains some weird results ;-) |
| 20:17:14 | apriori_ | Araq: sorry, was quite busy the last hour |
| 20:17:36 | apriori_ | and no, got no opinion yet. I need to investigate it further. and maybe orientate, what others did on that subject |
| 20:18:18 | Araq | hey, I'm already an expert :P |
| 20:18:35 | Araq | I asked around what others did ;-) |
| 20:18:44 | apriori_ | hm, okay |
| 20:19:03 | Araq | but nah, it's good, do some studies |
| 20:19:18 | apriori_ | when did you do your research on that? |
| 20:20:24 | Araq | about a year ago |
| 20:20:40 | apriori_ | okay |
| 20:20:53 | apriori_ | well, I doubt too much changed in that time.. but who knows. |
| 20:21:47 | Araq | most runtimes have a global GC so it doesn't really apply |
| 20:21:58 | Araq | yes, including haskell's |
| 20:22:56 | Araq | only erlang and perl6's vm do the GC per thread |
| 20:24:03 | Araq | eiffel studio used to do it but they didn't prevent sharing at all |
| 20:24:25 | Araq | relying on the poor programmer to not mix different memory regions |
| 20:24:44 | Araq | nowadays they use a global GC ;-) |
| 20:25:09 | apriori_ | ohm, a "stop the world" kind? |
| 20:25:25 | Araq | yes |
| 20:25:38 | apriori_ | hrm |
| 20:25:45 | apriori_ | actually that sounds like a very bad idea for performance |
| 20:25:49 | Araq | there are hardly any GCs out there that don't stop the world |
| 20:26:57 | Araq | it's possible to implement with a read barrier but then a read barrier is crap ;-) |
| 20:28:20 | apriori_ | Araq: and about refs.. yeah, either that.. or some copy-on-write |
| 20:29:01 | Araq | forget it |
| 20:29:51 | Araq | I don't want the compiler to generate 2 versions of a proc: 1 version if called in a worker thread and 1 ordinary version |
| 20:30:42 | apriori_ | yeah, that would be a problem |
| 20:30:46 | Araq | if we do that we may as well implement Cilk's concurrency model |
| 20:31:04 | Araq | which I like much better than Nimrod's ;-) |
| 20:31:12 | apriori_ | I don't qute know it |
| 20:31:19 | apriori_ | I just know openmp/openmpi |
| 20:31:22 | fowl | Araq, u want me to run the tests again in release ode |
| 20:31:23 | fowl | mode* |
| 20:31:23 | apriori_ | and.. tbb |
| 20:31:25 | fowl | ? |
| 20:31:53 | Araq | fowl: nah, it's fine |
| 20:31:56 | apriori_ | and, btw (I'm sure you're aware of that).. your tr macros allow some kind of annotation mechanics |
| 20:32:24 | Araq | run tests/run/ttables2.nim please, fowl |
| 20:33:00 | fowl | with just nimrod c -r ? |
| 20:33:06 | Araq | and 'gctest' and 'weakrefs' |
| 20:33:15 | Araq | with both 'c -r' and 'c -r -d:release' |
| 20:33:53 | fowl | ttables2 ran out of memory |
| 20:33:55 | Araq | apriori_: how would you annotate? |
| 20:34:41 | apriori_ | Araq: e.g. via some special comment |
| 20:35:20 | apriori_ | your tr. macros would also allow to generete doctests, or something similar |
| 20:35:25 | Araq | how can ttables2 run out of memory? o.O |
| 20:35:26 | apriori_ | *generate |
| 20:36:38 | Araq | perhaps but that can also be done with an ordinary macro in a cleaner way |
| 20:37:41 | fowl | weakrefs is outputting "true" |
| 20:38:51 | Araq | so it works ... hm |
| 20:39:30 | Araq | what does 'gctest' say? |
| 20:39:33 | fowl | https://gist.github.com/3763762 |
| 20:40:58 | Araq | so that works too |
| 20:42:38 | Araq | how can ttables2 run out of memory? what was its output exactly? |
| 20:45:44 | Araq | dom96: tasynciossl doesn't work on windows :P |
| 20:46:05 | dom96 | does tasyncioudp work? |
| 20:46:51 | Araq | that doesn't even exist ... |
| 20:47:12 | fowl | fowl@PARADOX ~/Desktop/Nimrod (master) |
| 20:47:12 | fowl | $ ./tests/run/ttables2 |
| 20:47:12 | fowl | out of memory |
| 20:47:20 | dom96 | Araq: Sorry, tasyncudp |
| 20:48:17 | Araq | er ... is that cygwin? |
| 20:48:39 | Araq | dom96: yes that test is green |
| 20:49:01 | fowl | no, git bash |
| 20:49:07 | fowl | msys or whatever |
| 20:49:33 | dom96 | Araq: In that case I'm guessing tasynciossl doesn't work because the ssl library is missing. |
| 20:51:12 | fowl | i dunno how its running out of memory, i have 8 gigs |
| 20:51:27 | dom96 | fowl: Try it in cmd.exe |
| 20:51:59 | fowl | same error |
| 20:52:17 | dom96 | interesting |
| 20:53:00 | Araq | it's some other issue |
| 20:53:14 | Araq | I'll look into it |
| 20:53:33 | fowl | Araq, if i got the sdl events working like a union type are you ok with breaking compatibility with older sdl programs |
| 20:54:16 | fowl | older nim-sdl programs, since the evconvs wont be needed |
| 21:04:30 | Araq | fowl: ensure they work on both 32bit and 64bit systems ;-) |
| 21:04:53 | Araq | and even then we can keep the old evconvs, right? |
| 21:06:40 | fowl | i only have a 64 bit system |
| 21:08:03 | dom96 | Get a VM :P |
| 21:08:09 | fowl | no the events wont be compatible anymore, like this line for example https://github.com/Vladar4/nimgame/blob/master/lib/engine.nim#L165 would just be addKeyEvent(eventp.keysym.sym, down) |
| 21:12:01 | Araq | well explain to me once again what you want to do |
| 21:13:21 | fowl | i want to make the events work like they do in my SFML wrapper: https://github.com/fowlmouth/nimrod-sfml/blob/master/sfml.nim#L86 |
| 21:16:24 | Araq | well alright but you won't get the 'object case' binary compatible to SDL's event union |
| 21:16:43 | Araq | it's not that I didn't try ... :P |
| 21:17:20 | fowl | are you sure because i compared sdl's to csfml's and they are pretty much the same |
| 21:17:21 | apriori_ | Araq: interesting.. I thought you implemented that with unions |
| 21:17:38 | fowl | i had to take the kind field out of each specific event for it to be possible |
| 21:17:47 | Araq | "pretty much" doesn't cut it |
| 21:18:29 | Araq | apriori_: indeed it's implemented with unions but the alignment differs subtly |
| 21:19:22 | Araq | it can work in principle and thus for SFML, but not for SDL |
| 21:19:26 | fowl | they are the same, compare http://hg.libsdl.org/SDL/file/ec7ccf5ee3dd/include/SDL_events.h to https://github.com/LaurentGomila/CSFML/blob/master/include/SFML/Window/Event.h |
| 21:21:35 | Araq | how are they the same? |
| 21:22:49 | Araq | the SFML version uses a union of structs just like Nimrod |
| 21:23:18 | Araq | SDL uses byte and int16 sized stuff |
| 21:23:29 | Araq | which makes all the difference |
| 21:24:17 | fowl | sdl's is a union of structs also |
| 21:24:31 | Araq | I compared the field's offsets and couldn't get it compatible even with dummy fields |
| 21:26:29 | apriori_ | alignment quite often sucks in struct |
| 21:26:31 | apriori_ | *structs |
| 21:26:38 | Araq | but hey, feel free to prove me wrong |
| 21:26:42 | apriori_ | I had much fun with code that used pragma pack etc. |
| 21:27:31 | Araq | but chances are slim that I will break SDL again, sorry |
| 21:28:21 | fowl | ok |
| 21:28:23 | fowl | brb |
| 21:28:25 | * | fowl quit (Quit: Leaving) |
| 21:29:15 | apriori_ | time to go for me, too.. |
| 21:29:16 | apriori_ | bye all |
| 21:29:20 | * | apriori_ quit (Quit: Konversation terminated!) |
| 21:42:06 | * | fowl joined #nimrod |
| 22:03:40 | fowl | yea its not working :( |
| 22:10:19 | fowl | its treating TEventKind as it should be 4 bytes instead of 1 |
| 22:22:37 | dom96 | "Error: cannot bind parameter 'pass' twice" |
| 22:22:49 | dom96 | Cool, first time I got this error. |
| 22:25:45 | Araq | my compiler is not bad :P |
| 22:26:29 | dom96 | Well I don't get the error. |
| 22:26:47 | dom96 | I have an idea of why the error happens. |
| 22:26:56 | dom96 | But if I didn't this error message would not help me much. |
| 22:29:19 | Araq | p(pass = 23, pass = 33) |
| 22:29:41 | dom96 | oh hah |
| 22:30:04 | dom96 | I'm just tired. |
| 22:30:13 | dom96 | And can't read English. |
| 22:30:29 | dom96 | That's a nice error message. |
| 22:33:37 | Araq | good |
| 22:34:28 | Araq | fowl: no offence but how come you're as good as wrapping when you never really used C++? |
| 22:34:37 | Araq | *that good at |
| 22:37:14 | fowl | heh i dunno |
| 22:37:42 | dom96 | This is odd. |
| 22:37:53 | dom96 | Araq: How come a converter like this: converter getFTPClient*(aftp: PAsyncFTPClient): var TAsyncFTPClient = return aftp[] |
| 22:37:59 | dom96 | Doesn't get applied automatically? |
| 22:38:35 | dom96 | I suppose it doesn't matter anyway, since you said at one point that that would be done automatically anyway, right? |
| 22:38:52 | Araq | dunno I never tested converters properly :P |
| 22:39:00 | fowl | at the moment im just casting to an array of bytes and saw that the first field was 4 bytes off |
| 22:39:14 | fowl | doesnt make sense to me since sizeof(teventkind) is 1 |
| 22:39:45 | dom96 | Araq: The compiler will consider ref TAsyncFTPClient to be the same as var TAsyncFTPClient when resolving function signatures, right? |
| 22:39:53 | dom96 | in the future. |
| 22:40:20 | Araq | yeah |
| 22:40:28 | * | Trix[a]r_za is now known as Trixar_za |
| 23:32:02 | Araq | good night guys |
| 23:49:36 | * | Trixar_za is now known as Trix[a]r_za |