| 00:19:06 | * | q66 quit (Quit: Quit) |
| 06:55:47 | * | zahary1 quit (Ping timeout: 252 seconds) |
| 06:56:43 | * | zahary joined #nimrod |
| 07:57:34 | * | Araq_ joined #nimrod |
| 09:34:42 | Araq_ | ping zahary |
| 09:36:18 | Araq_ | well you'll read this anyway: bootstrapping on my laptop: old version ~170 MB of ram, 3.1s |
| 09:36:34 | Araq_ | new GC version: 235 MB, 3.3s |
| 09:37:59 | Araq_ | and without having checked it, I blame the new cycleRoots handling for that :P |
| 09:41:13 | * | Araq_ quit (Read error: Connection timed out) |
| 09:42:49 | * | Araq_ joined #nimrod |
| 10:29:21 | * | Araq_ quit (Read error: Connection timed out) |
| 10:30:51 | * | Araq_ joined #nimrod |
| 10:45:22 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.1/20130116073211]) |
| 11:04:02 | * | XAMPP-8 joined #nimrod |
| 12:52:40 | * | Trix[a]r_za is now known as Trixar_za |
| 13:05:23 | * | q66 joined #nimrod |
| 13:16:52 | * | Trixar_za is now known as Trix[a]r_za |
| 13:31:37 | * | Trix[a]r_za is now known as Trixar_za |
| 14:12:13 | * | Trixar_za is now known as Trix[a]r_za |
| 14:46:54 | * | zahary quit (Ping timeout: 264 seconds) |
| 15:09:32 | * | zahary joined #nimrod |
| 15:28:57 | * | XAMPP-8 quit (Ping timeout: 276 seconds) |
| 15:33:07 | * | XAMPP-8 joined #nimrod |
| 16:18:43 | * | XAMPP-8 quit (Ping timeout: 248 seconds) |
| 16:22:52 | zahary | hi Araq. I can explain why you see this increase even tho the old collector didn't collect any cyclic objets, but I have only a few minutes right now |
| 17:12:52 | shevy | am I the only one to find games really difficult to make? |
| 17:17:52 | Araq | ping zahary |
| 17:25:12 | NimBot | Araq/Nimrod fcef03e Araq [+0 ±7 -0]: cleaner GC switching |
| 17:25:12 | NimBot | Araq/Nimrod 16808f2 Araq [+1 ±5 -1]: revert to old GC; use --gc:v2 to activate the new GC |
| 17:29:38 | * | gradha joined #nimrod |
| 17:30:19 | Araq | gradha: I know, I know, I broke bootstrapping ... ;-) |
| 17:30:49 | gradha | huh? |
| 17:31:21 | gradha | if you mean changes from git, I only update when I want to fetch some commit |
| 17:31:31 | Araq | alright |
| 17:31:45 | gradha | and there's no problem going back in time either |
| 17:32:01 | gradha | shevy: define "difficult", I'm sure you can make a tic-tac-toe |
| 17:32:36 | shevy | gradha oh yeah, those games are easy |
| 17:32:43 | gradha | ok, define game then |
| 17:32:47 | shevy | 9 fields, 4 or 5 actions per player |
| 17:32:52 | shevy | gradha, a browser game for instance |
| 17:33:05 | gradha | hmm... what? |
| 17:33:16 | gradha | like a "select your option" dialog/story? |
| 17:33:40 | gradha | or you mean games you can make with unity and play with the browser plugin? |
| 17:34:18 | gradha | maybe you mean flash games? |
| 17:35:07 | dom96 | To me the difficult thing about games is the art and sound. |
| 17:35:48 | gradha | you can always settle for the "8-bit" look and make crap mspaint graphics and beeps for sound |
| 17:37:07 | * | XAMPP-8 joined #nimrod |
| 17:37:41 | Araq | but who will play it if it looks like minecraft? |
| 17:38:24 | * | dom96 is highly jealous of Minecraft |
| 17:38:28 | gradha | you can ask people who play text based muds |
| 17:38:41 | gradha | dom96: why are you jealous of Minecraft? |
| 17:39:21 | dom96 | gradha: Because it's extremely successful |
| 17:39:23 | Araq | ha, I used to develop a text based adventure game |
| 17:39:38 | Araq | you could chose between human, orc and elve |
| 17:39:55 | Araq | if you pick elve you lose immediately XD |
| 17:40:33 | Araq | *elf |
| 17:40:46 | gradha | that's really xenophobic against elves |
| 17:40:59 | gradha | they will come and kill you shooting hundreds of arrows |
| 17:41:14 | reactormonk | or boil your brain with magic |
| 17:41:47 | Araq | the game said something like "fag elves cannot win!" :P |
| 17:41:55 | gradha | dom96: I'm more jealous of the guy who made the 1 million pixels page |
| 17:42:13 | dom96 | gradha: the what? |
| 17:42:36 | gradha | http://www.milliondollarhomepage.com |
| 17:43:07 | gradha | whenever I want to cry and kill myself I go read http://en.wikipedia.org/wiki/The_Million_Dollar_Homepage |
| 17:44:21 | gradha | I'm also jealous of the guy who made the first "fart-app" on the app store |
| 17:44:37 | gradha | to me, these are examples of extreme genius for raking the best profit with minimal work |
| 17:44:52 | gradha | minecraft is successful, but still has work behind |
| 17:45:50 | gradha | Araq: was the game any different if you played orc or human? |
| 17:46:43 | Araq | nah, I don't think so |
| 17:46:55 | dom96 | damn, that is quite brilliant. |
| 17:47:14 | Araq | you could choose 2-3 different things after the "race" and then it would be over anyway |
| 17:47:32 | dom96 | I keep thinking that there is still so many of these million dollar ideas out there, but I can't come up with a single damn thing. |
| 17:47:39 | gradha | that's genius too, you increase replayability by 100% or more simply by adding a few selection screens |
| 17:48:02 | gradha | the problem is nowadays people with interent figure stuff earlier |
| 17:48:21 | gradha | like in star wars kotor, they figured all stats are irrelevant compared to strength |
| 17:48:52 | Araq | you're already quite successful if you have players who notice that ;-) |
| 17:49:36 | gradha | yeah, I would love to have such problems, sleeping on my pile of money |
| 17:53:08 | reactormonk | or you didn't beta-test enough |
| 17:53:46 | gradha | maybe the betatesters were sleeping on their piles of money? |
| 17:53:52 | Araq | you don't make money by beta-testing |
| 17:54:01 | gradha | true |
| 17:54:24 | gradha | so maybe you get the pile of money by not employing betatesters? woah, amazing revelation |
| 17:55:28 | gradha | always wondered why multi-billion comanies can't afford to hire a few guys who just test security of their software, I guess it's not worth it |
| 17:57:05 | reactormonk | Araq, depends, QA makes money |
| 17:58:18 | gradha | indeed, http://build.nimrod-code.org is all... orange and red? I'll never understand those colors |
| 17:58:50 | * | dom96 notes to self to never become a UI designer |
| 17:59:16 | gradha | I don't mind the colors if you write somewhere what they mean |
| 17:59:57 | dom96 | yeah, I will get around to that. |
| 18:00:20 | gradha | daltonic people would welcome too some graphical indicator too, apart from the colors |
| 18:03:30 | dom96 | As soon as some daltonic person actually shows up, then I will think about doing that :P |
| 18:03:56 | gradha | that's a nice superpower you have there: telepathic user detection |
| 18:03:56 | NimBot | Araq/Nimrod ff2a049 Araq [+0 ±7 -0]: rebuilt C sources for bootstrapping |
| 18:04:22 | gradha | Araq: you mentioned writing drivers without gc, what happens with memory when you disable the gc? is there a delete for new? |
| 18:05:38 | Araq | gradha: nah, it either leaks or doesn't compile :P |
| 18:05:45 | dom96 | gradha: hah. by what I said I mean as soon as they complain :P |
| 18:06:29 | gradha | Araq: so you could use nimrod with manual memory thorugh calls to C's malloc/realloc/free? |
| 18:06:41 | gradha | as long as you don't use nimrod's new, that is |
| 18:08:55 | gradha | I'm thinking of the example in the manual using alloc0+dealloc, that would work? |
| 18:09:37 | gradha | that example (in the Referenced and pointer types) calls the GC to unref the var, so I guess not |
| 18:10:32 | Araq | gradha: alloc0 + dealloc would work yeah |
| 18:10:47 | Araq | it's a bit more complex though |
| 18:11:21 | gradha | ah, the unref'ed variable is the string, which was automatically allocated by nimrod I guess |
| 18:11:31 | Araq | exactly |
| 18:11:35 | gradha | so there would you get the memory leak if gc is disabled |
| 18:11:53 | Araq | currently yeah but nimrod's seq and strings semantics don't require a GC ;-) |
| 18:12:12 | Araq | it's planned to use C++'s styled destructors for them one day |
| 18:12:32 | Araq | however 'GC_unref' would then invoke the destructor |
| 18:13:15 | Araq | but it's all academic anyway because for drivers you're in kernel mode and need to call something like kernel_alloc() |
| 18:13:44 | Araq | nimrod's memory allocator doesn't work in kernel land out of the box |
| 18:14:07 | Araq | if you happen to write a driver that lives in userspace, Nimrod's allocator may be fine |
| 18:14:14 | Araq | but then so would Nimrod's GC as well |
| 18:14:28 | gradha | excellent, nimrod is HURD ready then |
| 18:15:15 | Araq | the only things in the language that require GC is 'ref' and closures |
| 18:15:55 | Araq | I guess the compiler should warn/error about closures when you do --gc:none |
| 18:17:59 | gradha | if a closure references a variable from the enclosing scope, does the closure make a copy? |
| 18:18:10 | Araq | depends |
| 18:18:25 | Araq | often the compiler manages to allocate the variable in the environment upfront |
| 18:18:52 | gradha | oh, so the compiler analizes the life of the closure? |
| 18:19:08 | Araq | not really for now |
| 18:19:29 | Araq | but it's planned and easy to do |
| 18:20:49 | gradha | so the hidden environment is itself a ref, and that's why closures would not work anyway without gc (or leak) |
| 18:20:59 | Araq | yep |
| 18:21:28 | Araq | in practice often the closure can be optimized to live on the stack though |
| 18:22:00 | Araq | the compiler will error then when it can't do that with --gc:none |
| 18:22:23 | Araq | so yeah the semantics then depend on the compiler's optimizer :P |
| 18:22:46 | gradha | is there a proc like instantiationInfo() to get info about the hidden environment of closures? |
| 18:23:29 | Araq | there is system.rawEnv |
| 18:23:37 | Araq | and system.rawProc |
| 18:24:05 | Araq | but both return untyped pointers :P |
| 18:24:58 | Araq | you're too concerned about closures though |
| 18:25:08 | gradha | I'm just curious |
| 18:25:22 | gradha | closures are this magical thing I'm not used to too much |
| 18:25:25 | Araq | nimrod's templates are faster, fit the language better, don't require GC |
| 18:25:41 | Araq | and work better with nimrod's effect system |
| 18:25:58 | gradha | the closures I'm used to are for async programming, I don't know how templates would help with that |
| 18:26:07 | Araq | using closures for sequtils is misguided ;-) |
| 18:26:18 | Araq | for async programming we have first class iterators |
| 18:26:31 | Araq | but they indeed use closures too :-) |
| 18:27:16 | gradha | one trend in the ios/objc community is to abuse closures to specify callback procs |
| 18:27:49 | gradha | even when you don't need to capture variables, people think it's neater to have all code close together |
| 18:28:40 | Araq | if you don't capture variables, the nimrod compiler doesn't create an environment on the heap |
| 18:32:24 | gradha | I also think that creating a shared environment avoids the problem ios/objc has with closures referencing their parent object and creating loops |
| 18:32:57 | gradha | you sometimes have to use the "weak__" modifier for variables, or create temporary values on the stack to avoid referencing the parent object |
| 18:34:46 | gradha | other than dealing yourself with what the compiler might do regarding memory management, it just works! |
| 18:35:15 | Araq | cycles are no problem for a real GC |
| 18:35:26 | Araq | except for Nimrod's ... *cough* |
| 18:35:36 | Araq | but we're working on it |
| 18:37:01 | Araq | in fact the new --gc:v2 fixes that |
| 18:47:02 | * | FreeArtMan joined #nimrod |
| 18:57:57 | * | shevy quit (Ping timeout: 245 seconds) |
| 19:01:02 | * | gradha quit (Quit: Leaving) |
| 19:10:52 | * | shevy joined #nimrod |
| 19:20:53 | * | XAMPP-8 quit (Ping timeout: 255 seconds) |
| 20:25:41 | * | XAMPP-8 joined #nimrod |
| 20:32:48 | * | gradha joined #nimrod |
| 20:44:35 | gradha | ah, can't write "assert not a in b", nor "assert a not in b", have to use assert (not (a in b)) |
| 20:44:59 | gradha | so lispy |
| 20:45:32 | reactormonk | gradha, bug Araq so he changes precedence ^^ |
| 20:45:56 | Araq | gradha: assert a notin b |
| 20:46:23 | Araq | and reactormonk, it's not a problem of precedence, it's a parser/grammar thing |
| 20:46:43 | reactormonk | Araq, oh |
| 20:48:56 | gradha | notin down notin |
| 20:50:33 | gradha | isnot, what's the contrary? ==? |
| 20:50:58 | reactormonk | gradha, is |
| 20:51:04 | Araq | is/isnot, == / != |
| 20:51:39 | Araq | but there is no 'notof' :P |
| 20:52:36 | reactormonk | Araq, aww |
| 20:52:37 | gradha | is there an 'is'? Just tried "assert proc_returning_bool is false" and the compiler didn't like it |
| 20:53:04 | Araq | that's because you just can't take your python knowledge and apply it to nimrod :P |
| 20:53:17 | gradha | I'm just replacing == with is as you said above? |
| 20:53:50 | Araq | 'is' is a type check for generic types: if T is int: ... |
| 20:54:21 | reactormonk | Araq, does the type system use that? so T is considered to be int in that body? |
| 20:54:22 | gradha | ok, misunderstood is/isnot as equivalent of comparisons |
| 20:55:19 | Araq | reactormonk: no, but it's not necessary either as nimrod's generics are quite macro-like |
| 20:55:29 | reactormonk | Araq, ok |
| 20:55:49 | Araq | aka "C++-styled duck typing" within generic code |
| 20:55:56 | reactormonk | ^^ |
| 21:10:58 | * | FreeArtMan quit (Remote host closed the connection) |
| 21:16:17 | Araq | ping zahary |
| 21:21:21 | * | XAMPP-8 quit (Ping timeout: 252 seconds) |
| 21:33:59 | gradha | is this bad? "Error: internal error: (filename: compiler/sem.nim, line: 76)" |
| 21:38:37 | Araq | yeah, an internal error is a bug |
| 21:46:27 | gradha | if you want me to test https://github.com/Araq/Nimrod/issues/324 with the latest git commit tell me what to do to avoid the bootstrapping problem |
| 21:47:14 | Araq | gradha: just unzip the C sources from the git repo, run build.sh and there you go |
| 21:47:37 | gradha | isn't that the normal way? what broke? |
| 21:49:52 | Araq | normally no unzipping of the C code is necessary |
| 21:50:01 | Araq | as the old version can build the new one |
| 21:50:13 | Araq | but ... not today ;-) |
| 21:50:23 | reactormonk | what did you change? |
| 21:50:44 | gradha | I use a shell script which purges the build files and unzips every time, so wouldn't have noticed |
| 21:53:35 | Araq | I added support for compileOption("gc", "v2") which system.nim now uses |
| 21:53:48 | Araq | so it's a chicken and egg problem |
| 21:55:04 | reactormonk | zahary, documentation for nimrod serve? *puppyeyes* |
| 21:55:49 | Araq | it's like you can't program without an IDE :P |
| 21:55:53 | gradha | arj, was going to shout bad things but forgot to merge my clang fixup branch |
| 22:03:29 | gradha | https://github.com/Araq/Nimrod/issues/324 still fails with the recent git version |
| 22:04:57 | Araq | how can a 'dirty' template contain a 'gensym' ? :P |
| 22:05:19 | Araq | I guess the compiler should produce a decent error message instead of crashing |
| 22:05:22 | gradha | I wonder where did that come from |
| 22:06:53 | gradha | compiling and running the sequtils module itself works, so why does it not crash there? |
| 22:08:10 | Araq | bad luck |
| 22:08:50 | Araq | within an 'assert' it's expanded differently |
| 22:09:00 | Araq | as 'assert' itself is a template |
| 22:09:46 | gradha | indeed, bad luck http://memegenerator.net/instance/34154059 |
| 22:10:42 | Araq | I planned to rework the templating system for 0.9.4 |
| 22:10:58 | Araq | but apperently it needs to fixed for 0.9.2 ... |
| 22:11:32 | gradha | "inject and gensym have no effect in dirty templates", oh yeah, they crash and burn, hehe |
| 22:12:01 | * | q66 quit (Quit: Quit) |
| 22:12:50 | gradha | yay, so removing dirty makes it work |
| 22:28:57 | reactormonk | Araq, well, the idetools work somewhat halfway |
| 22:29:08 | Araq | reactormonk: I know, I know ... |
| 22:29:24 | Araq | I'm sorry I'm not paid to work on Nimrod fulltime, you know |
| 22:29:39 | reactormonk | Araq, I know ;-) |
| 22:29:46 | gradha | I'm also sorry |
| 22:30:45 | gradha | something I'm hitting now with idetools is starting to type the name of a proc, open parenthesis, and think, "what where the parameters again?" |
| 22:30:51 | reactormonk | Araq, oh, I found it... my bug. Forgot to read project configs for includes |
| 22:31:02 | gradha | so I back on the name of the proc, search for it, and it is not found, but deleting the open parenthesis tends to work |
| 22:31:32 | Araq | idetools support the '(' event |
| 22:31:50 | Araq | so it could be your editor doesn't know about that |
| 22:32:00 | gradha | maybe I'm remembering incorrectly and the problem is when I've written one or two parameters but that doesn't match the proc's signature |
| 22:32:06 | Araq | more likely however is that it's broken in the compiler |
| 22:32:22 | Araq | you know ... it's pretty hard to test without editor support :P |
| 22:32:35 | gradha | right |
| 22:33:19 | Araq | but since the editor support improves, we have the chance to improve idetools |
| 22:33:33 | gradha | hmm... zahary: how about a vim macro which spits out a testcase? like, you have open a small file, put the cursor where idetools is supposed to work in a way, but it doesn't, and you capture all that? oh, and post to github since you are at it |
| 22:33:51 | reactormonk | gradha, snippets? |
| 22:34:04 | gradha | not sure what those are |
| 22:34:11 | Araq | I thought about adding support for testing idetools to our tester |
| 22:34:22 | Araq | but it's quite a lot of work :-/ |
| 22:34:57 | gradha | reactormonk: to make an idetools test case you need to put the source and invoke the compiler on it with line/column info, maybe that could be generated from the editor itself |
| 22:35:10 | reactormonk | gradha, more elisp \o/ |
| 22:35:37 | reactormonk | but this evening is dedicated to scala. |
| 22:36:17 | gradha | Araq: how about a proxy tester which reads target source and line/col info from some xml/json? |
| 22:36:37 | gradha | the json could contain the expected output and fail if it doesn't match what the compiler returns? |
| 22:36:50 | Araq | you don't need json for that |
| 22:36:59 | Araq | but it's still some work |
| 22:37:15 | gradha | the source of the test case would contain the line/col info? |
| 22:37:43 | Araq | ever looked at the current test suite? |
| 22:37:57 | gradha | just recently got it to completely run, so no |
| 22:38:02 | Araq | look at tests/reject/t*.nim |
| 22:38:11 | Araq | to see how it's done already |
| 22:38:23 | Araq | oh btw dom96 |
| 22:39:40 | reactormonk | cat 99bottles.nim |
| 22:39:41 | reactormonk | # Test if the compiler detects invalid module names |
| 22:39:44 | reactormonk | :-) |
| 22:41:25 | Araq | ugh, dom96, sometimes numbers like 0xff'i32 are not highlighted properly in aporia |
| 22:41:36 | Araq | but I can't reproduce it now :-/ |
| 22:44:14 | reactormonk | Araq, could syntax hl be done by idetools? |
| 22:45:02 | Araq | why should it? |
| 22:45:06 | gradha | sounds extremely slow for every typed character |
| 22:45:13 | Araq | yeah |
| 22:45:13 | reactormonk | gradha, yep :-/ |
| 22:45:26 | Araq | nimrod is not that hard to lex |
| 22:53:30 | dom96 | Araq: "Sometimes", that doesn't give me much to go on :( |
| 22:54:03 | Araq | dom96: perhaps it was an older version of aporia |
| 22:54:28 | Araq | it's was one file in compiler/*.nim, I'll write down which one when I notice it again |
| 22:54:32 | dom96 | I don't think I changed how that stuff is highlighted though. |
| 22:55:03 | Araq | I'll look at that file again soon I think |
| 23:01:12 | * | gradha quit (Quit: Leaving) |
| 23:16:29 | * | XAMPP-8 joined #nimrod |