00:45:43 | * | XAMPP-8 quit (Ping timeout: 264 seconds) |
00:46:42 | * | XAMPP-8 joined #nimrod |
00:57:35 | NimBot | Araq/Nimrod 52d4395 Araq [+1 ±11 -0]: first version of a simple mark&sweep GC; activate with --gc:markAndSweep |
01:00:38 | Araq | 59429 lines compiled; 2.704 sec total; 254.260MB # mark&sweep |
01:01:42 | Araq | 59971 lines compiled; 2.806 sec total; 173.178MB # reference counting |
01:02:35 | Araq | --> M&S trades memory for speed |
01:02:44 | Araq | suprisingly ... |
01:03:15 | Araq | 58008 lines compiled; 3.425 sec total; 130.133MB # Boehm |
01:03:39 | Araq | good night |
03:31:52 | * | Anaphaxeton quit (Remote host closed the connection) |
03:39:18 | reactormonk | Can I just overwrite 'echo' in my lib? |
04:54:06 | * | XAMPP-8 quit (Ping timeout: 264 seconds) |
08:44:29 | * | gour joined #nimrod |
09:33:27 | Araq | ping zahary, zahary_ |
09:35:29 | zahary_ | pong Araq |
09:36:33 | Araq | saw my new m&s gc? |
09:41:33 | Araq | suprisingly it's faster than the RC-based GC but uses much more RAM |
09:44:13 | Araq | however this is due to the doubling of the threshold, if I make the formula * 1.5, it uses 185MB |
09:45:53 | Araq | but then it loses against the old one ... |
10:52:41 | * | gour quit (Disconnected by services) |
10:52:43 | * | gour_ joined #nimrod |
10:58:59 | * | gour_ is now known as gour |
11:57:43 | * | q66 joined #nimrod |
13:41:53 | * | silven quit (Remote host closed the connection) |
13:45:57 | * | silven joined #nimrod |
13:51:53 | * | silven quit (Remote host closed the connection) |
13:53:44 | * | silven joined #nimrod |
13:56:33 | * | silven quit (Remote host closed the connection) |
13:59:53 | * | silven joined #nimrod |
14:05:58 | * | silven quit (Remote host closed the connection) |
14:07:02 | * | silven joined #nimrod |
14:14:06 | * | silven quit (Remote host closed the connection) |
14:16:00 | * | silven joined #nimrod |
14:23:16 | * | silven quit (Remote host closed the connection) |
14:26:54 | * | silven joined #nimrod |
14:33:23 | * | silven quit (Remote host closed the connection) |
14:34:34 | * | silven joined #nimrod |
14:42:27 | * | Anaphaxeton joined #nimrod |
15:51:08 | Araq | ping zahary, zahary_ |
15:59:00 | zahary_ | sorry Araq, too many fires at work to put out today |
16:00:05 | Araq | alright np |
16:00:08 | zahary_ | as for the new GC, well, that was fast :) (implementing it) |
16:00:12 | zahary_ | I'll try it out tonigh |
16:00:30 | Araq | I'm already working on an improved version |
16:00:46 | Araq | not sure if the algorithm that I've in mind is correct though ;-) |
16:01:05 | Araq | that's what I wanted to talk you about |
16:01:12 | zahary_ | I'd love to add more discovered leaks to my belt (7 so far) |
16:03:16 | Araq | what do you mean? you found even more leaks? |
16:05:49 | zahary_ | no, this is the my all-time count. if you remember, I also discovered some zeromem leaks in an old code by ddl_smurf |
16:05:59 | zahary_ | :) |
16:07:14 | Araq | arguably all the leaks in my GC count as 1 leak :P |
16:07:49 | Araq | often I deliberately removed the full write barrier for optimization |
16:08:02 | Araq | (I thought it's correct) |
16:21:36 | Araq | dom96: please have a look at the bug about os.createDir and aporia |
16:22:47 | dom96 | link? |
16:22:56 | Araq | ugh |
16:23:28 | Araq | https://github.com/Araq/Nimrod/pull/322 |
16:26:54 | gour | Araq: when i asked about comparison between ada & nimrod yesterday in terms of reliability/security, i hope you understood i'm thinking about type-safety and such things, but I bet you thought about it when designing nimrod considering you used ada in real world |
16:28:55 | Araq | gour: yes but to be honest we found a few issues wrt memory safety ;-) |
16:29:52 | gour | Araq: well those things can be fixed, i hope...not much of design blunder |
16:30:16 | * | gour would use GC preferrably |
16:30:41 | gour | iow. "safeNimrod" :-) |
16:31:28 | Araq | sure but it's a bit of work and will break some code; I'm talking about branch transitions in 'case objects' |
16:32:15 | gour | you're still below 1.0, so code break is probably not big issue |
16:32:28 | Araq | well ok, it's trivial to fix by not overlaying these fields in memory but where is the fun in that? ;-) |
16:33:39 | Araq | also memory safety in particular is a complex topic, I guess I should finally create a blog and write about it |
16:33:57 | gour | pls. do it |
16:34:14 | gour | it'll be good for nimrod |
16:45:21 | Araq | I know |
17:54:53 | * | Zerathul joined #nimrod |
18:19:00 | reactormonk | gour, the more issues you create the better nimrod-mode can get :> |
18:19:12 | reactormonk | hacked a bit on the js part because I need it |
18:30:31 | * | fowl joined #nimrod |
18:52:23 | * | FreeArtMan joined #nimrod |
18:58:53 | * | zahary quit (Read error: Connection reset by peer) |
18:59:04 | * | zahary joined #nimrod |
18:59:42 | * | zahary quit (Client Quit) |
19:00:20 | * | zahary joined #nimrod |
19:03:16 | apotheon | http://sourceware.org/ml/glibc-cvs/2013-q1/msg00115.html |
19:15:44 | * | shevy quit (Ping timeout: 246 seconds) |
19:18:39 | Araq | apotheon: I already know that one ;-) but if you use TWO instead of 2.0 your code is bs anyway |
19:19:55 | dom96 | I for one think the compiler should understand syntax like "two point five" :P |
19:28:25 | * | shevy joined #nimrod |
19:40:47 | * | q66 quit (Read error: Connection reset by peer) |
19:41:22 | * | q66_ joined #nimrod |
19:43:56 | * | q66_ is now known as q66 |
20:05:38 | reactormonk | Araq, btw, openarray[expr] doesn't match string e.g. |
20:30:26 | * | XAMPP-8 joined #nimrod |
20:33:48 | * | FreeArtMan quit (Quit: Leaving) |
20:43:50 | gour | reactormonk: i'll do as as i find time to play a bit with it |
20:50:12 | Araq | reactormonk: try varargs[expr] instead |
20:56:48 | reactormonk | Araq, ok |
20:57:00 | gour | reactormonk: from which languages you're arriving to nimrod? |
20:57:02 | reactormonk | gour, completion doesn't work with + or similar - blame idetools |
20:57:05 | * | gradha joined #nimrod |
20:57:12 | reactormonk | gour, ruby, mainly. and elisp. Currently learning scala. |
20:57:18 | reactormonk | Araq, I assume proc types are contravariant? |
20:57:32 | gour | reactormonk: idetools? what's that? |
20:57:52 | reactormonk | gour, the nimrod compiler provides me with completion and symbol information. |
20:58:18 | reactormonk | gour, go try M-. |
20:58:24 | gour | reactormonk: ahh, that's something for core devs then |
20:58:36 | gradha | gour: not at all |
20:58:44 | gradha | I use it all the time |
20:58:53 | gour | reactormonk: haven't install your mode yet and now have some afk work |
20:59:02 | gour | gradha: emacs? |
20:59:13 | gradha | I meant idetools, it's something for users |
20:59:20 | gradha | sorry if I barged in the conversation without context |
20:59:50 | Araq | reactormonk: they are not contravariant nor covariant |
21:00:43 | reactormonk | Araq, aww |
21:01:18 | reactormonk | gour, nope, they're the interface that provides the editor with contextual information |
21:02:01 | gour | reactormonk: so, editor just uses what it gets, right? |
21:08:15 | reactormonk | gour, exactly. |
21:08:44 | gour | then, it's compiler bug... |
21:09:14 | reactormonk | gour, if it doesn't get anything or the wrong one, reproduce it. Maybe it's my fault, or idetools doesn't work right. There's a *nimrod-suggestion or so buffer that does a bit more |
21:09:22 | reactormonk | s/does a bit more/displays the outputs/ |
21:09:39 | gour | reactormonk: ok. will try tomorrow afternoon |
21:34:48 | gour | what is the plan in regard to interfacing with C++? i'm thinking about e.g. wx bindings |
21:34:57 | gour | or Qt...whatever |
21:35:39 | gradha | hmm... that reminds me, maybe it would be worth investigating swing generating bindings for nimrod? |
21:37:41 | gour | maybe..although very often i hear people from different camps complaining about the quality (aka bloat) of swig-generated bindings for the language xyz |
21:38:02 | gradha | granted, but sometimes having something is better than nothing, especially for adoption |
21:38:21 | gradha | you see, you can advertise "we have bindings!" and with fine print "but they are swingified" |
21:38:24 | * | gour nods |
21:39:01 | Araq | gradha: I'd improve c2nim instead so that it can handle C++ |
21:39:39 | gour | that'd be great |
21:39:51 | gradha | NIH syndrome or some other good reason? I mean, c2nim doesn't work with non-massaged C headers, so... |
21:40:16 | Araq | neither does anything work with non-massaged C headers |
21:40:38 | gradha | swig doesn't either? |
21:41:12 | Araq | not really |
21:41:35 | Araq | in fact, special "header.i" files for swig are common |
21:42:24 | gour | iirc, it's possible to run swig directly on *.h as well |
21:42:27 | gradha | disappointing, maybe using llvm would be easier? at least that should support C parsing |
21:43:45 | Araq | good luck with that |
21:43:57 | gradha | was waiting for you to say that |
21:44:02 | gour | maybe this https://github.com/Araq/Nimrod/wiki/Editor-Support needs some update to point at reactormonk's fork? |
21:44:17 | gradha | doit! |
21:44:21 | Araq | you start with a minute long build for LLVM and then you haven't tweaked anything |
21:45:11 | gradha | I had the impression that llvm does the heavy parsing stuff and you can hook into it at the point it uses AST trees or something like that you compiler guys undestand |
21:46:07 | Araq | well it's been a while but I didn't like their APIs and I tried once to implement a 'void run_C_code(char* code);' |
21:46:35 | gradha | wow, I had expected they would be providing that |
21:46:38 | Araq | was in their channel and they told me it would be quite some work |
21:47:04 | Araq | plus most of their APIs have no C bindings or they are not kept up to date |
21:47:27 | Araq | but if you want to hack it in C++ anyway that's no problem |
21:48:15 | Araq | btw c2nim can also translate function *bodies* |
21:48:31 | Araq | I don't think SWIG can do that |
21:50:14 | gour | http://rosettacode.org/wiki/Nimrod says: "...although it could use more developers, there is currently only one core developer." |
21:50:30 | gradha | scratch my words about llvm, I should have said http://clang.llvm.org/docs/Tooling.html |
21:50:48 | gradha | "Use LibClang when you want powerful high-level abstractions, like iterating through an AST with a cursor" |
21:51:57 | Araq | "and forget about #defines as they are no first class citizens of C/C++" :P |
21:52:23 | gradha | yes, I was just thinking that maybe by the time you reach ASTs you have lost something on the way |
21:55:05 | gradha | looks like I'm not the only crazy person with crazy thoughts https://github.com/jacob-carlborg/dstep |
21:56:31 | gour | ahh, D stuff :-) |
21:56:34 | Araq | https://github.com/jacob-carlborg/dstep/blob/master/features/array.feature |
21:57:49 | gour | what is ETA for 0.9.2? |
21:58:01 | gradha | that subdir even has ruby |
21:58:09 | Araq | gour: christmas 2012 |
21:58:11 | * | zahary quit (Ping timeout: 252 seconds) |
21:58:22 | gour | good. that's not far away ;) |
22:03:00 | gradha | just in time for the year of nimrod |
22:05:12 | Araq | *shrug* we can always skip 0.9.2 and release 0.9.4 instead |
22:30:58 | * | gradha is away: auto-away |
22:41:03 | * | gradha is back (gone 00:10:06) |
22:46:28 | gradha | oh, auto-away spamming, I knew it wasn't that a good idea |
22:47:04 | Araq | why not? it's interesting you spend only 10 minutes on youtube ... |
22:47:10 | gour | lol |
22:47:26 | gradha | this time it was a parent-control phone call |
22:47:47 | gradha | AFAICS watching youtube doesn't make the laptop sleep, so it thinks it's active |
22:53:43 | gradha | I think I've been hearing too much of death metal lately, I'm starting to understand the lyrics of the distorted voices, creepy |
22:54:47 | * | Zerathul_ joined #nimrod |
22:55:56 | * | Zerathul quit (Ping timeout: 256 seconds) |
22:55:59 | * | Zerathul_ is now known as Zerathul |
23:08:15 | NimBot | Araq/Nimrod 02a0d49 Araq [+0 ±7 -0]: code cleanup for mark&sweep GC |
23:08:15 | NimBot | Araq/Nimrod 3ad9b2e Araq [+0 ±3 -0]: made some tests green |
23:08:25 | Araq | good night |
23:08:27 | reactormonk | gradha, done |
23:08:32 | reactormonk | @ gour |
23:08:37 | gradha | Araq: bye |
23:08:44 | reactormonk | Araq, duh |
23:09:16 | Araq | reactormonk: what? |
23:09:28 | reactormonk | Araq, how can I tell it to convert strings to cstrings? |
23:09:39 | gradha | cast to cstring? |
23:09:45 | gradha | cstring(string_var) |
23:10:07 | reactormonk | and btw, is there a way to avoid toEcmaStr(cstrToNimstr( ... ? |
23:10:19 | Araq | try varargs[expr, cstring] |
23:10:20 | reactormonk | ehh, context: varargs[expr] |
23:10:43 | Araq | if that doesn't work, try varargs[expr, toCString] with a helper toCString that you need to provide |
23:11:01 | Araq | and the compiler should optimize away toEcmaStr(cstrToNimstr(...)) |
23:11:16 | Araq | bug report if it doesn't |
23:11:21 | reactormonk | Araq, nope, got string, required varargs[cstring] |
23:11:56 | Araq | er |
23:12:06 | Araq | try varargs[cstring, toCString] then |
23:12:25 | reactormonk | or varargs[expr] if I put varargs[expr, cstring] |
23:12:46 | reactormonk | or varargs[cstring, repr] and implement the fucking repr |
23:13:56 | gour | reactormonk: ? |
23:14:08 | Araq | you're aware of ecmasys.nim:305, right? |
23:15:10 | Araq | there is an echo implementation for nodejs and one for manipulating the DOM |
23:15:18 | * | gour --> sleep |
23:15:23 | Araq | can't imagine what else you need |
23:15:39 | * | gour quit (Quit: WeeChat 0.4.0) |
23:16:37 | reactormonk | Araq, let me see |
23:17:42 | * | Zerathul quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]) |
23:18:38 | reactormonk | Araq, ok. The one in kwin is 'print', so I go console.log = print basically? |
23:19:03 | Araq | yep |
23:19:35 | reactormonk | or could I overwrite rawEcho in my lib? |
23:19:44 | Araq | add a define "qtjs" or something for your target |
23:20:00 | reactormonk | it's kwin. |
23:20:05 | Araq | ok |
23:20:13 | reactormonk | no override proc rawEcho ? |
23:20:25 | Araq | there may be a way to overwrite it but you don't want to go that way ;-) |
23:21:16 | reactormonk | why not? |
23:21:29 | reactormonk | so I wouldn't have to hack the compiler for a lib |
23:22:39 | Araq | you could use a TR macro or overwrite it in JS land via 'emit' |
23:22:55 | Araq | but the TR macro will only work by chance |
23:23:12 | reactormonk | you need an overwrite keyword ;> |
23:23:56 | Araq | the lack of it is what gives Nimrod its strategic advantage for concurrency :P |
23:24:15 | reactormonk | yeye |
23:24:23 | Araq | once I implemented what I've in mind ... |
23:25:01 | Araq | you can replace the stdlib including system.nim btw |
23:25:15 | Araq | via some compiler switch that I don't remember |
23:25:27 | Araq | so that would be the 3rd possibility |
23:25:54 | Araq | but for now, just touch ecmasys.nim and make a pull request |
23:26:09 | gradha | man, you can't leave us with that "what I've in mind", is it in the todo? |
23:27:06 | Araq | gradha: kind of, "use the effect system for static deadlock prevention and race detection" |
23:28:11 | Araq | oh btw, try the stock GCC on macosx with the new --gc:markAndSweep please |
23:28:21 | gradha | will do |
23:28:23 | Araq | it may be a work-around |
23:28:45 | Araq | and it's faster anyway than the default GC |
23:28:56 | gradha | it beats reading crap on the interent anyway |
23:29:11 | gradha | where do I add the switch, nimrod.cfg? |
23:29:30 | Araq | 'koch boot -d:release --gc:markAndSweep' |
23:29:35 | Araq | I'd start with that |
23:29:38 | gradha | ok |
23:30:39 | Araq | (it's only faster because it uses more memory though) |
23:30:56 | gradha | running |
23:32:16 | gradha | command line(1, 1) Error: 'none', 'boehm' or 'refc' expected, but 'markAndSweep' found |
23:32:24 | gradha | I must have got a wrong git |
23:32:56 | Araq | well you need to bootstrap once to get that option .... -.- |
23:33:11 | Araq | I didn't rebuild the C sources ... sorry |
23:33:26 | gradha | but I do the unzip? |
23:33:38 | Araq | shouldn't be necessary |
23:35:02 | gradha | so run build.sh twice? |
23:35:33 | Araq | nah |
23:35:54 | Araq | run build.sh, bootstrap with llvm, bootstrap with gcc and --gc:markAndSweep |
23:36:03 | Araq | simple, heh? |
23:36:12 | gradha | err... that's new |
23:37:05 | Araq | please resist the temptation to document it ;-) |
23:37:13 | Araq | it's only for you |
23:37:18 | gradha | so basically whatever I do always, then remove clang patches and run koch --gc:markAndSweep? |
23:37:27 | Araq | yes |
23:37:29 | gradha | ok |
23:37:40 | gradha | I see you are starting to be afraid of my anal retentive capabilities |
23:38:07 | Araq | "afraid" is such a strong word |
23:38:15 | Araq | let's say "respect" |
23:38:35 | gradha | that's new, again |
23:40:10 | Araq | I'm tired :P |
23:40:12 | Araq | good night |
23:40:24 | gradha | sleep well |
23:41:59 | gradha | hoho, doesn't crash |
23:42:09 | gradha | ah, crap, forgot to remove patches |
23:44:37 | gradha | ./koch boot -d:release --gc:markAndSweep --> executables are equal: SUCCESS! |
23:45:08 | gradha | during the log I got gcc instead of clang, so it seems to be working |
23:53:21 | gradha | koch web wasn't that lucky http://pastebin.com/5SVDiUPh |
23:54:20 | gradha | neither koch tests http://pastebin.com/x8fxNpc5 |
23:55:25 | gradha | oh, I guess both invoke the nimrod compiler itself without the markAndSweep switch |
23:59:09 | gradha | interesting, different crash for koch tests if I add --gc:markAndSweep to config/nimrod.cfg http://pastebin.com/9TVhDsNZ |
23:59:33 | * | gradha quit (Quit: bbl, have youtube videos to watch) |