| 00:07:53 | * | vendethiel- quit (Ping timeout: 252 seconds) |
| 00:10:52 | * | superfun1 quit (Ping timeout: 240 seconds) |
| 00:12:38 | * | vendethiel joined #nimrod |
| 00:15:50 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 00:26:18 | * | dain joined #nimrod |
| 00:27:28 | flaviu | "lib/core/macros.nim(274, 16) Error: unhandled exception: lib/core/macros.nim(288, 176) Hint: line too long [LineTooLong]" |
| 00:27:30 | flaviu | huh? |
| 00:30:32 | reactormonk | flaviu, pretty much. ^^ |
| 00:30:52 | flaviu | ok, I fixed it by splitting it over a few lines |
| 00:31:06 | flaviu | weird, because it was 100-200 chars long, not that much |
| 00:31:09 | reactormonk | I think it's a compiler limitation on buffer allocated |
| 00:31:29 | reactormonk | Or maybe Araq just doesn't like overlong lines, you never know ;-) |
| 00:31:45 | flaviu | reactormonk: It really wasn't very long: https://gist.github.com/40fb42726f1cc30f6f37 |
| 00:32:13 | flaviu | And when I put it in the source file, it works fine. |
| 00:32:21 | flaviu | macro weirdness, I guess |
| 00:35:27 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 00:36:10 | * | fowlmouth joined #nimrod |
| 00:37:40 | Araq | hi dain welcome |
| 00:37:47 | Araq | flaviu: report it, it's a bug |
| 00:37:58 | Araq | hints should not end up as errors |
| 00:38:18 | flaviu | Ok. |
| 00:40:13 | Araq | flaviu: also "bloat" in the test suite doesn't refer to its runtime, but to maintainability |
| 00:40:25 | * | vendethiel joined #nimrod |
| 00:42:18 | * | dain quit (Quit: dain) |
| 00:44:45 | flaviu | lol, I hit another bug while trying to make a minimal test case for the current one |
| 00:45:23 | flaviu | Wait, no, that's just me |
| 00:50:02 | wan | gokr: first three links to earlier posts are broken |
| 01:00:23 | Araq | bye |
| 01:01:05 | wan | gokr: wow, you really have to remember to put the procCall, else you get a stackoverflow (infinite call) |
| 01:01:45 | wan | (I just removed one to see what it would do) |
| 01:03:29 | wan | good article, btw |
| 01:14:16 | * | Boscop_ joined #nimrod |
| 01:17:17 | * | Boscop quit (Ping timeout: 240 seconds) |
| 01:20:47 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 01:22:23 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 01:35:22 | * | boydgreenfield joined #nimrod |
| 01:35:22 | * | boydgreenfield quit (Client Quit) |
| 01:40:38 | * | Trixar_za quit (Ping timeout: 244 seconds) |
| 01:41:54 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 01:43:21 | * | Trixar_za joined #nimrod |
| 01:46:17 | * | boydgreenfield joined #nimrod |
| 01:47:37 | * | fowlmouth quit (Ping timeout: 252 seconds) |
| 01:52:05 | * | wan quit (Quit: WeeChat 1.0.1) |
| 01:59:22 | * | vendethiel joined #nimrod |
| 02:03:09 | * | will quit (Read error: Connection reset by peer) |
| 02:06:35 | * | darkf joined #nimrod |
| 02:12:12 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:17:32 | * | superfunc joined #nimrod |
| 02:20:44 | * | q66 quit (Quit: Leaving) |
| 02:24:06 | * | vendethiel quit (Ping timeout: 256 seconds) |
| 02:33:41 | * | boydgreenfield joined #nimrod |
| 02:51:29 | * | pink-rg left #nimrod (#nimrod) |
| 03:05:04 | * | saml_ joined #nimrod |
| 03:10:55 | * | srlang joined #nimrod |
| 03:18:12 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 03:29:33 | * | EXetoC quit (Ping timeout: 252 seconds) |
| 03:48:19 | * | kapil__ joined #nimrod |
| 03:58:16 | * | vendethiel joined #nimrod |
| 04:01:52 | * | j3rky quit (Ping timeout: 258 seconds) |
| 04:12:58 | * | flaviu quit (Ping timeout: 250 seconds) |
| 04:31:07 | * | srlang quit (Ping timeout: 245 seconds) |
| 04:34:30 | * | AFKMorpork is now known as AMorpork |
| 04:38:29 | * | BitPuffin joined #nimrod |
| 04:41:57 | * | vendethiel quit (Ping timeout: 240 seconds) |
| 04:42:52 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 04:44:22 | ldlework | I am struggling with the difference between generics in method parameters and generics in field storage |
| 04:44:36 | ldlework | It seems like it is really easy to pass around different types but not keep references to them etc |
| 04:44:53 | ldlework | Why can I have generic references? |
| 04:44:56 | ldlework | can't* |
| 04:52:42 | * | superfunc quit (Quit: Connection closed for inactivity) |
| 05:05:15 | * | Demos quit (Read error: Connection reset by peer) |
| 05:06:02 | * | vendethiel joined #nimrod |
| 05:06:17 | * | bjz_ quit (Ping timeout: 240 seconds) |
| 05:08:57 | * | bjz joined #nimrod |
| 05:10:35 | ldlework | We should totally support this syntax: https://gist.github.com/dustinlacewell/598fcbcf367b188c15ee |
| 05:10:43 | * | AMorpork is now known as AFKMorpork |
| 05:16:00 | * | kmcguire joined #nimrod |
| 05:18:33 | * | bjz quit (Ping timeout: 272 seconds) |
| 05:21:39 | * | milosn joined #nimrod |
| 05:23:34 | * | Boscop_ quit (Ping timeout: 264 seconds) |
| 05:28:53 | * | vendethiel quit (Ping timeout: 258 seconds) |
| 05:30:00 | * | saml_ quit (Quit: Leaving) |
| 05:32:17 | * | kmcguire quit (Ping timeout: 264 seconds) |
| 05:36:03 | * | vendethiel joined #nimrod |
| 05:52:41 | * | untitaker quit (Ping timeout: 264 seconds) |
| 05:57:50 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 05:58:07 | * | untitaker joined #nimrod |
| 06:06:01 | * | perturbation quit (Quit: Leaving) |
| 06:30:26 | * | vendethiel joined #nimrod |
| 06:40:52 | * | BlaXpirit joined #nimrod |
| 06:52:19 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 06:55:25 | * | flyx left #nimrod ("I'm a happy Miranda NG user! Get it here: http://miranda-ng.org/") |
| 07:00:07 | * | c74d quit (Remote host closed the connection) |
| 07:04:37 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 07:05:13 | * | gokr_ joined #nimrod |
| 07:08:43 | * | c74d joined #nimrod |
| 07:14:06 | * | q66[lap] quit (Ping timeout: 250 seconds) |
| 07:30:24 | * | gokr_ quit (Read error: Connection reset by peer) |
| 07:30:35 | * | gokr_ joined #nimrod |
| 07:46:46 | ldlework | good god the requirement that you import methods just hung me up for like an hour |
| 07:48:04 | * | gour joined #nimrod |
| 07:51:32 | * | BlaXpirit quit (Ping timeout: 245 seconds) |
| 07:52:16 | * | bjz joined #nimrod |
| 07:55:32 | gokr | ldlework: Regarding generic references... I am no guru on generics, but it seems to me that you can think of generic methods as "templates" - in other words, there are multiple procs created "under the hood" - matching each unique call site. |
| 07:55:50 | gokr | Now... that works just fine for procs. But for an object? There is only "one" :) |
| 07:56:41 | gokr | In other words, generics in proc signatures can be thought of as "sugar" instead of typing in one proc for all the combinations of actual types used in your program. |
| 07:57:07 | gokr | Btw, thanks to both flaviu and wan for the "bug reports" on my articles, all fixed :) |
| 08:47:18 | * | vendethiel joined #nimrod |
| 08:47:19 | * | Trustable joined #nimrod |
| 08:52:28 | * | ekarlso- quit (Ping timeout: 255 seconds) |
| 08:54:59 | * | wan joined #nimrod |
| 09:09:34 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 09:10:36 | * | ekarlso- joined #nimrod |
| 09:11:18 | * | khmm joined #nimrod |
| 09:17:07 | * | vendethiel joined #nimrod |
| 09:21:15 | * | dts joined #nimrod |
| 09:32:08 | * | Araq0 joined #nimrod |
| 09:32:41 | Araq0 | ldlework: why do you think RootRef exists and the language makes you inherit from RootObj when you want inheritance? |
| 09:33:01 | Araq0 | RootRef is your "generic" reference |
| 09:33:09 | dts | because you felt like it? |
| 09:34:12 | Araq0 | btw it's funny how many people go for "from m import foo" and then curse it imports what they told it to do |
| 09:34:36 | Araq0 | and then come up with rules what it obviously "should" import |
| 09:35:07 | Araq0 | here's a hint, "import m" works, if you get a conflict, use "import m except foo" |
| 09:35:55 | dts | just import everything and be done with it |
| 09:38:51 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 09:40:16 | * | vendethiel joined #nimrod |
| 09:45:28 | * | BitPuffin joined #nimrod |
| 10:06:19 | * | Araq0 quit (Quit: Page closed) |
| 10:25:10 | * | Etheco joined #nimrod |
| 10:26:30 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 10:26:41 | * | gour_ joined #nimrod |
| 10:27:10 | * | BlaXpirit joined #nimrod |
| 10:30:29 | * | gour quit (Ping timeout: 264 seconds) |
| 10:32:18 | * | gour_ is now known as gour |
| 10:33:52 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 10:37:59 | * | BitPuffin joined #nimrod |
| 10:38:53 | * | bjz quit (Ping timeout: 240 seconds) |
| 10:42:19 | * | BitPuffin quit (Ping timeout: 244 seconds) |
| 10:43:42 | * | vendethiel joined #nimrod |
| 10:59:07 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 11:06:07 | * | vendethiel quit (Ping timeout: 255 seconds) |
| 11:41:46 | * | flaviu joined #nimrod |
| 11:42:50 | gokr | flaviu: Thanks for the corrections to the articles |
| 11:53:42 | * | flaviu quit (Ping timeout: 265 seconds) |
| 12:05:11 | * | bjz joined #nimrod |
| 12:10:55 | * | vendethiel joined #nimrod |
| 12:33:39 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 12:35:05 | * | BitPuffin joined #nimrod |
| 12:35:37 | * | vendethiel joined #nimrod |
| 12:44:02 | * | EXetoC joined #nimrod |
| 12:59:34 | * | vendethiel quit (Ping timeout: 264 seconds) |
| 13:08:59 | * | vendethiel joined #nimrod |
| 13:30:22 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 13:30:24 | * | Puffin joined #nimrod |
| 13:32:15 | * | BlaXpirit joined #nimrod |
| 13:35:05 | * | Puffin quit (Ping timeout: 272 seconds) |
| 13:43:46 | * | vendethiel joined #nimrod |
| 14:05:43 | * | vendethiel quit (Ping timeout: 252 seconds) |
| 14:16:08 | * | vendethiel joined #nimrod |
| 14:24:21 | * | j3rky joined #nimrod |
| 14:31:47 | * | boydgreenfield joined #nimrod |
| 14:51:41 | * | AFKMorpork is now known as AMorpork |
| 15:02:29 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 15:03:30 | * | kostya joined #nimrod |
| 15:10:54 | * | vendethiel joined #nimrod |
| 15:11:38 | * | dom96_ quit (Ping timeout: 250 seconds) |
| 15:15:29 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 15:15:37 | * | darkf quit (Quit: Leaving) |
| 15:16:39 | * | johnsoft joined #nimrod |
| 15:17:25 | * | saml joined #nimrod |
| 15:28:59 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 15:41:23 | * | kapil__ quit (Quit: Connection closed for inactivity) |
| 15:50:42 | kostya | optimized https://github.com/kostya/benchmarks/commit/2a52213abe2883810e6c28df7b6949550ceedaa3 |
| 15:51:37 | * | gokr_ quit (Ping timeout: 240 seconds) |
| 15:52:33 | * | gokr_ joined #nimrod |
| 15:55:32 | * | boydgreenfield joined #nimrod |
| 15:59:32 | * | gokr_ quit (Ping timeout: 256 seconds) |
| 16:03:19 | ldlework | "Just import everything" sounds like one of those "Its just the Go way dude" things that we all know is bad |
| 16:03:44 | ldlework | We've learned over the last 40 years that namespaces are A Good Thing and that anyone telling you otherwise is a kook |
| 16:04:23 | ldlework | Araq: I'm not surprised that "from m import foo" imports foo, but that it doesn't import everything related to foo is all |
| 16:04:39 | ldlework | And that there is no way to say "Give me all the methods related to foo" |
| 16:05:12 | ldlework | I've heard things on the forums about how Python gets by with looser checking than this or that |
| 16:05:43 | ldlework | err I don't know where I was going with the Python remark |
| 16:05:48 | ldlework | literally just woke up |
| 16:06:47 | * | srlang joined #nimrod |
| 16:09:02 | ldlework | Anyway its not a serious critique this is like the only thing I've found so far that I don't like |
| 16:12:38 | * | bjz quit (Read error: Connection reset by peer) |
| 16:13:03 | * | bjz joined #nimrod |
| 16:13:37 | * | Araq0 joined #nimrod |
| 16:14:10 | Araq0 | "We've learned over the last 40 years that namespaces are A Good Thing and that anyone telling you otherwise is a kook" well I didn't learn this lesson |
| 16:14:25 | Araq0 | I learned it's a non-issue when you have strict static typing |
| 16:14:50 | Araq0 | the type system exists to prevent stupid mistakes |
| 16:15:14 | EXetoC | so it's just "import all procs and methods associated with this type" that is missing? namespaces are a different subject, and the modules are basically namespaces |
| 16:16:27 | Araq0 | namespacing is aesthetic |
| 16:17:39 | EXetoC | except when used as a way to resolve conflicts |
| 16:19:30 | Araq0 | also ... not that I like these kind of arguments, but: "having procs nothing to do with Foo in module foos is a code smell anyway so 'import' is fine with importing everything" |
| 16:20:57 | Araq0 | (that would be the counter argument on reddit level) |
| 16:21:02 | EXetoC | except maybe when you want to exclude something for the sake of not having to qualify symbols when said proc is imported from another module, which I imagine won't be the case very often |
| 16:22:13 | EXetoC | but I wouldn't mind such an import feature, but I don't know how many people use it only for the sake of documentation |
| 16:24:08 | * | flyx joined #nimrod |
| 16:27:37 | EXetoC | there's some danger of hijacking though, if we don't have actual member functions tied to a single module, but unit tests should catch many of these occurrences, if indeed the semantics differ |
| 16:28:15 | EXetoC | but the intended proc must either have been removed, or excluded when importing |
| 16:30:41 | Araq0 | kostya: can you edit tables.nim and sets.nim, to use a different 'nextTry' algorithm and see what/if it changes? |
| 16:30:56 | Araq0 | proc nextTry(h, maxHash: THash): THash {.inline.} = result = (h + 1) and maxHash |
| 16:31:07 | Araq0 | # linear probing |
| 16:31:44 | Araq0 | is a planned optimization |
| 16:32:52 | EXetoC | but "from x import T*" doesn't seem like a very intrusive addition |
| 16:34:19 | EXetoC | ldlework: consider discussing it on the forums and/or on github if you haven't already, assuming that you don't get a straight 'no' here |
| 16:34:41 | Araq0 | what's the point though? what evil symbols do you get when you "import pegs"? |
| 16:35:42 | EXetoC | I would consider using it, since it would be so effortless, but I'm not that bothered about it |
| 16:36:12 | Araq0 | IMO the module and packaging system is already quite complex |
| 16:36:31 | Araq0 | and people already struggle with it all the time |
| 16:36:32 | EXetoC | but that would be for the sake of documentation, really |
| 16:37:11 | EXetoC | but the documentation system could track symbol references and so on anyway |
| 16:38:42 | EXetoC | an IDE could do it too |
| 16:38:55 | EXetoC | will that be a priority before 2.0? |
| 16:39:55 | Araq0 | will what be a priority? better idetools support? |
| 16:40:05 | Araq0 | sure |
| 16:40:42 | EXetoC | ok |
| 16:41:14 | saml | so, x can come from any of the imported modules and those modules' dependencies? |
| 16:42:18 | EXetoC | not the dependencies, unless they are exported |
| 16:42:51 | * | Boscop joined #nimrod |
| 16:43:22 | saml | i guess compiler/linker could incrementally build search index |
| 16:44:41 | saml | each nim installation collects and builds local index. and when the machine goes online, it replicates to central index. web scale. |
| 16:45:25 | saml | wait.. won't work due to private code. people would like some privacy and don't want to publish their index of private code |
| 16:47:27 | Araq0 | saml: no idea what you mean but we have theindex.html |
| 16:48:36 | saml | that's for modules that bundled with nim only |
| 16:48:58 | saml | wait.. maybe nim already has something like maven |
| 16:50:25 | Araq0 | we have Nimble (formerly known as Babel) |
| 16:50:32 | EXetoC | shouldn't that be the responsible of either the owner of the package, or the maintainer of the package manager, who could generate documentation for all packages |
| 16:51:02 | EXetoC | people can then consult locally generated documentation too, if necessary |
| 16:51:27 | Araq0 | we could try and build the index for every registered nimble package |
| 16:51:40 | Araq0 | shouldn't be too hard |
| 16:57:03 | * | Varriount|Mobile joined #nimrod |
| 16:57:08 | Varriount|Mobile | Meep |
| 16:57:55 | Varriount|Mobile | I'm back, at least for a little bit. I'm swamped with final exams preparations |
| 17:00:54 | Araq0 | Varriount|Mobile: ok, well, we plan to release this weekend (as always) |
| 17:01:31 | * | gokr_ joined #nimrod |
| 17:01:38 | Araq0 | do you have time then? |
| 17:01:54 | Varriount|Mobile | Araq: I'll see if I can scrounge together some time... I can't make any promises though |
| 17:02:35 | Varriount|Mobile | I'll be free after the 10th, though, that's when classes end. |
| 17:05:21 | Araq0 | well dom96 really wants us to release 0.10.2, I don't mind skipping that release too much |
| 17:06:23 | gour | what's the point of 0.10.2 less than one monthy before 1.0? |
| 17:07:10 | Araq0 | so we get more feedback for 1.0 |
| 17:07:54 | gour | but isn't the road for 1.0 already traced out? |
| 17:08:27 | Araq0 | yeah but I'm open to feature removals :P |
| 17:08:44 | gour | i mean. nothing against it if it does not take too much (precious) resources |
| 17:10:13 | Araq0 | it doesn't matter too much, 1.0 will be beta quality, this is just reality. KDE 4.0 had the same problem afaict. people use supposedly "stable" software and find all the bugs the devs missed and than it's really stable at 4.2 or something |
| 17:12:06 | Araq0 | the joy of open source development |
| 17:12:38 | ldlework | Sorry for being grumpy earlier |
| 17:13:33 | Araq0 | ldlework: same here. sorry for being grumpy. |
| 17:19:55 | * | khmm quit (Ping timeout: 272 seconds) |
| 17:20:37 | kostya | nextTry not helping |
| 17:21:53 | * | vendethiel quit (Ping timeout: 265 seconds) |
| 17:22:00 | ldlework | So I wrote an application that scrolls random pixels upwards |
| 17:22:09 | ldlework | I notice there it a slight pause every once and a while |
| 17:22:11 | ldlework | This is the GC? |
| 17:22:32 | Araq0 | kostya: does it make it worse? |
| 17:22:50 | kostya | a bit |
| 17:23:15 | Araq0 | ldlework: possibly, you can always use the realtime gc |
| 17:23:45 | Araq0 | kostya: bah... and this is why I don't like benchmarks on modern hardware ;-) |
| 17:23:58 | Araq0 | it should be slightly faster |
| 17:26:13 | * | kostya quit (Quit: Leaving) |
| 17:26:54 | * | vendethiel joined #nimrod |
| 17:27:04 | ldlework | Araq0: just "var useRealtimeGC = true" or something like that? |
| 17:27:41 | EXetoC | how long are these pauses? is the memory usage high? |
| 17:28:19 | ldlework | EXetoC: its just a tick, like a barely noticable studder every say, 3-5 seconds or so |
| 17:28:31 | ldlework | Its just a test, nothing important just trying to understand |
| 17:28:55 | Araq0 | ldlework: you have to read the docs |
| 17:29:11 | ldlework | Araq0: I do! I swear! |
| 17:29:18 | Araq0 | http://nim-lang.org/gc.html |
| 17:29:19 | ldlework | Sometimes I don't know what I'm looking for though :) |
| 17:29:38 | ldlework | Araq0: I'm there. It says "define the symbol" so I wondered if that just meant, define it as anything like = true |
| 17:29:51 | Araq0 | ah ok fair enough |
| 17:30:15 | Araq0 | it means to use -d:useRealtimeGC on the command line |
| 17:30:21 | Araq0 | (or your config file) |
| 17:30:22 | ldlework | Oh okay |
| 17:30:36 | EXetoC | it should maybe say 'conditional symbol' |
| 17:30:48 | Araq0 | it should just give an example |
| 17:31:00 | Araq0 | examples, examples, examples! |
| 17:31:05 | boydgreenfield | dom96 / others: In Jester, do query strings only get parsed for formData, or am I missing something? |
| 17:31:06 | Araq0 | there is no other way to learn |
| 17:31:32 | ldlework | Hmm that didn't fix the pause but anyway its not important I guess :) |
| 17:31:44 | ldlework | EXetoC: do you know what cellular automata is? |
| 17:32:24 | ldlework | Hmm it might even be an optical illusion or something |
| 17:32:43 | ldlework | Like my eye is tracking the movement for a second so it only seems to pause or something. haha |
| 17:33:57 | Araq0 | boydgreenfield: sorry, I don't know. |
| 17:34:09 | * | Araq0 sucks at web development |
| 17:34:12 | * | onionhammer quit (Ping timeout: 250 seconds) |
| 17:34:18 | boydgreenfield | Araq0: No worries, I think it just isn’t parsing them… I’ll submit a PR to dom |
| 17:34:20 | EXetoC | ldlework: calculate the frame rate and then display that |
| 17:34:40 | Araq0 | see you later guys |
| 17:34:47 | * | Araq0 quit (Quit: Page closed) |
| 17:40:01 | ldlework | EXetoC: if you want to see for yourself, https://github.com/dustinlacewell/nimbots |
| 17:40:10 | ldlework | There are two scenes you can toggle between with spacebar |
| 17:40:23 | ldlework | one does vertical scrolling of random noise, and another just like tv static |
| 17:40:46 | ldlework | the vertical scrolling has all this wierd studdering and choppyness, the tv static is smooth as silk |
| 17:40:55 | ldlework | no need to waste any time on it, but if you were curious what I was seeing |
| 17:41:56 | * | onionhammer joined #nimrod |
| 17:43:31 | * | q66[lap] joined #nimrod |
| 17:44:07 | * | q66 joined #nimrod |
| 17:44:13 | EXetoC | I don't get any pauses |
| 17:45:10 | ldlework | wow |
| 17:45:15 | ldlework | Maybe I'll reboot |
| 17:45:24 | ldlework | brb |
| 17:46:20 | Varriount|Mobile | EXetoC: What's the memory usage like? Is it fluctuating? |
| 17:50:17 | EXetoC | Varriount|Mobile: it stays at about 70mb |
| 17:51:35 | Varriount|Mobile | Hm, if memory usage is constant, that would suggest the stutter *isn't* caused by the GC |
| 17:52:04 | EXetoC | and an ICE when compiling with -d:release |
| 17:52:59 | * | dom96_ joined #nimrod |
| 17:56:29 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 17:57:03 | EXetoC | ldlework: I need to call my lib nim-libtcod2 or something, at least temporary |
| 17:57:38 | * | boydgreenfield joined #nimrod |
| 17:57:38 | EXetoC | *temporarily |
| 17:58:18 | * | boydgreenfield quit (Client Quit) |
| 18:00:22 | * | irrequietus joined #nimrod |
| 18:05:54 | * | milosn quit (Ping timeout: 264 seconds) |
| 18:06:31 | ldlework | I guess I will chalk it up to my window manager... |
| 18:09:21 | Araq | EXetoC: er ... what do you mean? "ICE" with -d:release? |
| 18:09:55 | Araq | so the compiler crashes when you enable release mode? |
| 18:14:23 | Araq | flaviu: http://www.cs.indiana.edu/~dyb/pubs/nano-jfp.pdf |
| 18:14:47 | ldlework | Is there a way to build so that dependencies get built into the binary? Is that a stupid question? |
| 18:16:21 | Araq | yes. ;-) |
| 18:17:24 | ldlework | Araq: heh to the former or latter? :) |
| 18:17:48 | * | Matthias247 joined #nimrod |
| 18:18:32 | Araq | it's both possible with lots of archane linker flags and a stupid question :P |
| 18:20:34 | ldlework | hehe ok |
| 18:21:00 | ldlework | I just want to send someone this binary who's on the same arch as me without having to have them install/build libtcod |
| 18:21:10 | ldlework | Just wondering if I could statically link libtcod |
| 18:22:21 | Araq | so you use Linux and want to share binaries easily ... spot your error. :P |
| 18:22:45 | * | milosn joined #nimrod |
| 18:26:36 | ldlework | Araq: heh this is totally doable and you're just giving me shit arnt you :D |
| 18:27:28 | Araq | last time I did it, it worked until some libc version differed |
| 18:27:49 | * | gour quit (Quit: Konversation terminated!) |
| 18:28:39 | EXetoC | Araq: with relative paths? |
| 18:29:36 | EXetoC | or maybe you meant statically |
| 18:30:54 | Araq | EXetoC: I meant copying nimrod binaries around |
| 18:31:22 | * | gour joined #nimrod |
| 18:31:31 | * | gour quit (Changing host) |
| 18:31:31 | * | gour joined #nimrod |
| 18:33:17 | dts | why dont iterators contain an implicit result variable? |
| 18:35:40 | Araq | because it's not necessary |
| 18:35:51 | dts | hmmm |
| 18:35:53 | Araq | you need to 'yield' anyway |
| 18:36:10 | Araq | 'result's point is to avoid brutal control flow |
| 18:36:25 | Araq | but you cannot avoid it an iterator |
| 18:36:37 | dts | yeah good point |
| 18:36:58 | milosn | evening |
| 18:43:30 | * | milosn at starbucks |
| 18:46:46 | * | milosn having coffee |
| 18:46:47 | milosn | :) |
| 18:47:02 | milosn | you "made" me arsholes, now you take care of me |
| 18:47:04 | milosn | har har |
| 18:47:35 | milosn | they love to stir shit up and play all innocent |
| 18:47:37 | milosn | har har |
| 18:48:10 | * | Boscop quit (Read error: Connection reset by peer) |
| 18:48:25 | milosn | hmmmm |
| 18:48:27 | * | Boscop joined #nimrod |
| 18:49:11 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 18:49:17 | * | Var|Mobile joined #nimrod |
| 18:49:57 | milosn | man i need a holiday, again |
| 18:54:12 | milosn | ive started reading new york times last week |
| 18:54:15 | milosn | you are doomed |
| 18:54:22 | milosn | i am gonna see through all your games |
| 18:54:27 | milosn | :) |
| 19:00:06 | * | Boscop_ joined #nimrod |
| 19:03:36 | milosn | mpg123 http://213.8.143.168/100Hits |
| 19:04:05 | * | Boscop quit (Ping timeout: 264 seconds) |
| 19:05:56 | * | skyfex joined #nimrod |
| 19:07:56 | EXetoC | milosn: it's choppy since the track change |
| 19:07:56 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 19:08:22 | milosn | dont think so |
| 19:08:27 | milosn | :) |
| 19:09:10 | milosn | i know chop from "chop" |
| 19:09:20 | milosn | anyway thats less important |
| 19:09:49 | milosn | ive lost at least 5kg last 3 weeks |
| 19:10:42 | milosn | sorry wrong # |
| 19:10:44 | milosn | :) |
| 19:10:48 | milosn | i was in other place |
| 19:10:53 | milosn | sorry for the bother :D |
| 19:11:04 | * | milosn swicthes back to the place |
| 19:13:22 | Araq | hey, skyfex is back! |
| 19:14:29 | ldlework | Well |
| 19:14:35 | ldlework | I'm convinved it is an optical illusion I guess |
| 19:14:45 | ldlework | If I drag the window down to the edge of the screen |
| 19:14:51 | ldlework | so I can only see like three or four rows |
| 19:14:57 | ldlework | I never see those studder or stop or anything like that |
| 19:15:09 | skyfex | Araq: hey :) |
| 19:15:24 | ldlework | so it literally must be an illusion where my eye is tracking the movement for a split second making me thing I see studder |
| 19:15:37 | EXetoC | ok, but add a frame rate display for tracking changes easily |
| 19:15:45 | EXetoC | I don't know if there's a utility for that in libtcod |
| 19:16:31 | EXetoC | sys_get_fps, or did I omit sys? |
| 19:16:42 | ldlework | EXetoC: its interesting to me that you don't experience the same illusion |
| 19:19:45 | EXetoC | ldlework: it's not tearing then? which causes some jitter |
| 19:20:10 | ldlework | EXetoC: it was definitely tearing before... but when I run it now, it seems to not |
| 19:20:22 | ldlework | EXetoC: I still experience the illusion where it stops for a microsecond, but I'm convinced that's my eyes |
| 19:22:28 | EXetoC | ok |
| 19:29:56 | * | Var|Mobile joined #nimrod |
| 19:30:57 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 19:30:57 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 19:31:26 | ldlework | EXetoC: I added an FPS counter and pushed up |
| 19:33:41 | EXetoC | vsync only for the second scene? |
| 19:34:06 | EXetoC | and that means no tearing, but that's not the cause? |
| 19:36:08 | EXetoC | nevermind. it's no worth spending time on it, but the second example is indeed vsync'ed |
| 19:36:57 | ldlework | EXetoC: they are setup exactly the same |
| 19:37:29 | ldlework | The only thing that changes is the rendering routine |
| 19:37:38 | ldlework | EXetoC: are you getting tearing on the first one now? |
| 19:38:29 | EXetoC | I always did, because the frame rate is not that of the monitor frequency |
| 19:41:28 | ldlework | EXetoC: makes sense |
| 19:42:32 | ldlework | Hmm even if I set the tcod fps to 30 I still get tearing on the first one lol |
| 19:45:23 | * | Var|Mobile joined #nimrod |
| 19:46:32 | EXetoC | it was just a coincidence that it remained at 60 |
| 19:46:32 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 19:48:46 | ldlework | EXetoC: I think that libtcod is rendering faster than vsync but limiting the user render pipeline to whatever you set the fps to |
| 19:49:19 | ldlework | Oh well |
| 19:58:11 | ldlework | I feel wierd defining a P version of all my types |
| 19:58:27 | ldlework | I know it is just an alias |
| 19:58:40 | ldlework | Does anyone here just use ref Type everywhere vs defining ref aliases? |
| 19:58:41 | EXetoC | that convention is deprecated |
| 19:58:53 | ldlework | EXetoC: oh so I should just be using ref Type? |
| 19:59:22 | EXetoC | some do, but the primary type should be Type, which could be a ref or a ptr |
| 20:00:07 | ldlework | EXetoC: hmm if I do type MyType = object; then MyType isn't a ref or a ptr right? |
| 20:00:27 | ldlework | EXetoC: are you saying to do something like "type BaseType = object ... Type = ref BaseType" |
| 20:00:33 | EXetoC | and secondary types should be called TypeObj, TypeRef and TypePtr IIRC, depending on which type is the primary one and which ones you want to define and export |
| 20:00:51 | EXetoC | almost |
| 20:01:42 | * | Var|Mobile joined #nimrod |
| 20:02:12 | * | gour is wondering why is suse's partitioner putting 0700 type for btrfs partitions |
| 20:02:29 | ldlework | EXetoC: "type Type = object ... TypeRef = ref Type" ? |
| 20:04:28 | Araq | Var|Mobile: what about that 'diff' feature? |
| 20:05:06 | EXetoC | ldlework: if Type is the primary type, and if TypeRef is needed |
| 20:05:17 | * | j3rky quit (Ping timeout: 264 seconds) |
| 20:05:29 | ldlework | EXetoC: what if I'm primarily working with ref's to the type |
| 20:06:24 | ldlework | EXetoC: sorry, just trying to get an idea of the Nim conventions |
| 20:06:40 | ldlework | EXetoC: btw, if you wanted to look over that code and correct any bad forming habits or anything I wouldn't be offended :) |
| 20:07:05 | EXetoC | ldlework: "Type = ref TypeObj" I think |
| 20:07:17 | ldlework | Oh |
| 20:07:19 | ldlework | I see |
| 20:07:35 | Araq | or simply Type = ref object ... |
| 20:07:43 | EXetoC | was just going to say |
| 20:07:44 | ldlework | that works? |
| 20:07:46 | ldlework | nice |
| 20:07:54 | EXetoC | Araq: so all this is set in stone? |
| 20:07:58 | ldlework | I don't really understand any of the semantics on the right side of the = |
| 20:08:09 | ldlework | object, RootObj, object of |
| 20:08:20 | Araq | EXetoC: yes |
| 20:08:21 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 20:08:34 | * | Var|Mobile joined #nimrod |
| 20:08:46 | ldlework | I showed someone the code with RootObj and they said 'ew' and I said 'nooo ignore that, look at the rest of it!' |
| 20:08:46 | * | Var|Mobile quit (Read error: Connection reset by peer) |
| 20:09:00 | * | Var|Mobile joined #nimrod |
| 20:11:13 | ldlework | Someone saying that Rust will be the next game-dev language leader |
| 20:11:21 | ldlework | I said "Except that you can opt out of the GC with Nim" |
| 20:11:23 | ldlework | he asks |
| 20:11:25 | ldlework | <rsaarelm> Does that work nicely with the standard library and do you get RAII? |
| 20:11:35 | ldlework | I'm guessing not |
| 20:11:49 | ldlework | Since the standard library is probably all GC-based |
| 20:11:59 | EXetoC | it's very hard to predict these things, and Nim is better in many ways |
| 20:12:29 | EXetoC | oh, and syntax does matter |
| 20:12:47 | ldlework | EXetoC: I'm taking that as a "no it wont play nice with the standard library" |
| 20:14:21 | EXetoC | it mostly like will eventually |
| 20:14:39 | Araq | ldlework: the point of Nim's GC is to be good enough that you can use in a game |
| 20:14:56 | EXetoC | and I can't remember if destructors work well outside the global scope |
| 20:14:56 | Araq | and as predictable as you want it |
| 20:15:14 | Araq | destructors are not stable and will end up in --experimental |
| 20:15:28 | EXetoC | ok |
| 20:17:13 | gokr | ldlework: Not sure what's so odd there. |
| 20:17:24 | ldlework | gokr: odd where? |
| 20:17:30 | gokr | (oops, I am 20 lines behind) |
| 20:17:43 | gokr | The "the code with RootObj" etc |
| 20:17:57 | Araq | this idea that you have to avoid the stdlib for your game code is really backwards anyway |
| 20:18:10 | Araq | so lets go through some examples: |
| 20:18:15 | EXetoC | and the pause time can be reduced, right? because someone complained that 2ms was way too much |
| 20:18:16 | ldlework | gokr: probably because it is an arbitrarily defined symbol name for something that is usually hidden in syntax or a keyword, etc |
| 20:18:36 | * | Var|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 20:18:40 | gokr | ldlework: AFAIK RootObj is the same as "Object" in Java, the base type. |
| 20:18:41 | ldlework | gokr: and it doesn't resemble the "object" or "object of" patterns |
| 20:18:46 | EXetoC | I think you said that the guaranteed maximum pause time is actually lower |
| 20:19:02 | EXetoC | but there are other ways to go about this |
| 20:19:21 | * | boydgreenfield joined #nimrod |
| 20:19:49 | Araq | max pause time has been reported to be 0.5ms for some games |
| 20:20:18 | ldlework | Araq: you should finish your previous thought :P |
| 20:20:19 | EXetoC | ldlework: no? it's just an alias then |
| 20:20:33 | ldlework | EXetoC: sorry what? |
| 20:20:35 | EXetoC | rather than inheritance |
| 20:21:00 | Araq | let's look at XML processing. allocates? yes. BUT: do you use it in in your main loop? |
| 20:21:16 | gokr | Also, the GC pauses is "per thread", not global. |
| 20:21:21 | EXetoC | if it's just "Type = RootObj" rather than "Type = object of RootObj" (include ref where necessary) |
| 20:21:30 | * | srlang quit (Quit: WeeChat 1.0.1) |
| 20:21:48 | Araq | osproc. allocates? yes. but running some external process is expensive anyway |
| 20:22:15 | ldlework | Araq: I think it is for like data structures and stuff |
| 20:22:37 | ldlework | the point that the other guy made about the stdlib |
| 20:22:50 | EXetoC | then you have things like DSP threads, but you wouldn't deal with these things in those |
| 20:22:58 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 20:23:57 | * | johnsoft joined #nimrod |
| 20:24:18 | Araq | ldlework: well the GC is just optimized reference counting anyway, the same algorithm that many game engines use |
| 20:25:01 | ldlework | Araq: I did attempt the point that Jehan had made that some GC's are faster than manual deconstruction anyway (OCaml) |
| 20:25:20 | Araq | other important example is logging |
| 20:25:44 | Araq | with some TR macro you can get that down to how C does it |
| 20:26:23 | Araq | ldlework: they are but it depends on what you do. |
| 20:29:09 | gokr | AFAIK, if you can control for how long the GC pauses (and IIRC, you can in Nim) then its a no-brainer, it will most probably not be the "performance bottle neck". |
| 20:31:34 | Araq | the thing is: when use a data structure coming from a library, it really depends on how the library is designed. For instance, I wouldn't use "glib" in a game either even though it's in C and doesn't use a GC. |
| 20:31:58 | gokr | Take bitsquid for example - a swedish professional game engine (just bought by Autodesk btw) - they went *all in* on Lua, for basically everything on the "game" side. And still, this is a super high performance game engine. |
| 20:33:01 | Araq | I mean seriously. The typical destructor for a binary tree in C++ is O(n) where n is the tree size and not interruptable. |
| 20:33:20 | Araq | that's worse than what you get with Nim. |
| 20:34:01 | Araq | well it's still O(n) of course, but it is interruptable |
| 20:34:26 | Araq | for other GCs it's O(1) if they can compact |
| 20:35:05 | gokr | (the trick behind bitsquid is being fully job based, everything optimized for multicore. That's where the challenges are, not with "gc or no gc" IMHO) |
| 20:35:32 | Araq | the libraries you use need to play well in C++ too, so the entire argument makes no sense |
| 20:36:45 | * | gokr playing with having my big screen on the side... hmmm |
| 20:38:32 | ldlework | gokr: so that it is more tall than wide? |
| 20:38:42 | * | flaviu joined #nimrod |
| 20:41:37 | gokr | Right, I realized I could actually tilt it |
| 20:41:57 | gokr | A friend of mine had it like that, and of course... more text vertically |
| 20:45:00 | Araq | flaviu: check the logs please, I sent you a link |
| 20:45:51 | * | Mat4 joined #nimrod |
| 20:45:55 | Mat4 | hello |
| 20:47:28 | flaviu | Araq: Yep, I've seen that paper, but I' |
| 20:47:38 | flaviu | ve never completely read it |
| 20:49:03 | Araq | well the essence is that automatic combining of passes for efficiency is an open research problem :P |
| 20:49:23 | Mat4 | compiler passes ? |
| 20:49:25 | Araq | and these many passes really slow down a compiler |
| 20:49:32 | Araq | Mat4: yes |
| 20:51:04 | * | Mat4 wonders, why academic researches doesn't seem to relate on researches in computer history end up reinventing the wheel over and over again |
| 20:52:51 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:08:18 | flaviu | Araq: I skimmed over it, but from what I can tell, performance is still reasonable, even with all the passes. |
| 21:08:18 | flaviu | also, this compiler compiled to machine code, which is much harder. |
| 21:09:05 | Araq | not really, it's different, but not harder |
| 21:09:13 | Araq | unless you want to optimize ;-) |
| 21:09:32 | Araq | (then indeed it's much harder) |
| 21:09:42 | flaviu | They do do a small amount of optimization |
| 21:10:36 | flaviu | The whole idea with the nanopass compiler is that the framework figures out how and where to run the code. |
| 21:11:10 | flaviu | They had previously used a "micropass" structure, which is what I imagine you thinking about, where the programmer had to transverse the AST. |
| 21:11:54 | flaviu | They found that was slow - because it required full transversal each pass, and error prone - it was easy to overlook some cases |
| 21:14:11 | flaviu | They developed a new framework, the "nanopass framework", where the author defines the pattern to match (this is lisp, so this is trivial), a standard conditional (ideally, this would not frequently fail, increasing performance), and what he wants to replace the given pattern with/ |
| 21:17:43 | Araq | yeah sure but that means I'm right :P |
| 21:18:06 | Araq | the naive way of doing "nano passes" sucks |
| 21:23:23 | * | milosn quit (Ping timeout: 258 seconds) |
| 21:27:14 | * | skroll2 joined #nimrod |
| 21:27:33 | * | heinrich5991_ joined #nimrod |
| 21:28:41 | Araq | hi heinrich5991 welcome |
| 21:28:53 | Araq | hi skroll2. same to you |
| 21:28:58 | * | EXetoC1 joined #nimrod |
| 21:29:02 | * | flaviu1 joined #nimrod |
| 21:29:43 | * | [CBR]Unspoken1 joined #nimrod |
| 21:30:43 | * | JStoker quit (Killed (wolfe.freenode.net (Nickname regained by services))) |
| 21:30:50 | * | JStoker joined #nimrod |
| 21:33:06 | ldlework | What a shitstorm |
| 21:33:38 | Mat4 | ??? |
| 21:33:52 | Araq | wrong channel I guess |
| 21:34:15 | ldlework | Sorry, we need a #nimrod-offtopic |
| 21:34:22 | ldlework | Because you guys are cool and I want to chat :P |
| 21:34:30 | dom96 | that exists |
| 21:34:32 | gokr | ldlework: There is already |
| 21:34:44 | flaviu1 | ldlework: Check the status message :P |
| 21:34:45 | EXetoC1 | see the topic |
| 21:34:53 | ldlework | heh woops |
| 21:35:05 | * | flaviu quit (*.net *.split) |
| 21:35:05 | * | skyfex quit (*.net *.split) |
| 21:35:05 | * | EXetoC quit (*.net *.split) |
| 21:35:06 | * | jhc76 quit (*.net *.split) |
| 21:35:06 | * | skroll1 quit (*.net *.split) |
| 21:35:07 | * | [CBR]Unspoken quit (*.net *.split) |
| 21:35:07 | * | heinrich5991 quit (*.net *.split) |
| 21:35:09 | * | EXetoC1 is now known as EXetoC |
| 21:35:15 | * | flaviu1 is now known as flaviu |
| 21:35:17 | * | heinrich5991_ is now known as heinrich5991 |
| 21:35:43 | EXetoC | let's just migrate to #nim and so on |
| 21:36:05 | Mat4 | there exist a new channel ? |
| 21:37:35 | EXetoC | there are only a few people in #nim and #nim-offtopic |
| 21:38:22 | * | irrequietus quit () |
| 21:39:37 | * | dom96_ quit (Ping timeout: 240 seconds) |
| 21:40:00 | EXetoC | just kick everyone with a message, and update the topic |
| 21:44:05 | Mat4 | Both the need for multi-pass compilation and sophisticated optimization strategies are avoidable simply by choosing an effective IL code representation in combination with an interpreter which generate such intermediate code beside parsing (this is also resource effective and ease porting as well as limit complexity) |
| 21:45:11 | Araq | Mat4: you're describing LuaJIT, right? ;-) |
| 21:46:22 | Mat4 | no but yes ;) |
| 21:48:46 | * | boydgreenfield joined #nimrod |
| 21:52:23 | Mat4 | LuaJIT compiles beside interpretation and so add some memory overhead (inclusive the increased code depth caused by it RISC oriented, register-based IL representation which resulting even in an additional overhead for needed SSH transformations for optimization as side effect) |
| 21:52:53 | Mat4 | otherwise it's amazing efficient |
| 22:10:01 | * | Joe_knock joined #nimrod |
| 22:11:07 | Araq | ping boydgreenfield |
| 22:11:21 | Araq | does anybody know what to do about these? |
| 22:11:23 | Araq | https://github.com/Araq/Nimrod/issues/782 |
| 22:11:32 | Araq | https://github.com/Araq/Nimrod/issues/784 |
| 22:12:20 | flaviu | Well, it's a security issue, so the only reasonable response is to fix it. |
| 22:13:54 | ldlework | flaviu: I think Araq meant 'does anyone know how to fix these' |
| 22:14:12 | flaviu | ah, I'll look into OpenSSL I guess |
| 22:15:03 | Araq | thanks |
| 22:16:03 | boydgreenfield | Araq: Hey. |
| 22:16:23 | Joe_knock | welcome to Nim boydgreenfield |
| 22:18:15 | * | milosn joined #nimrod |
| 22:29:33 | * | jhc76 joined #nimrod |
| 22:33:55 | Mat4 | ciao |
| 22:34:25 | Araq | bye |
| 22:34:46 | * | Mat4 left #nimrod (#nimrod) |
| 22:54:23 | * | will joined #nimrod |
| 22:55:30 | will | Joe_knock: how did the presentation go? |
| 22:56:14 | * | tinAndi joined #nimrod |
| 23:03:37 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:07:58 | Joe_knock | will: terrible. very few people showed up |
| 23:13:32 | ldlework | :( |
| 23:13:50 | ldlework | a talk about Nim? |
| 23:20:03 | flaviu | Well, comparing python's usage of openssl to nim's, I'm a bit scared |
| 23:21:15 | flaviu | There is no way that nim is implementing 5500 lines of python and c code in just a couple hundred. |
| 23:21:59 | ldlework | :3 |
| 23:24:06 | Araq | there are openSSL alternatives around now |
| 23:24:11 | Araq | maybe we should use these |
| 23:25:35 | Joe_knock | LibreSSL |
| 23:25:53 | Joe_knock | openSSL is quite bloated, so an alternate will work |
| 23:27:11 | ldlework | Though everyone has openssl already installed |
| 23:28:16 | EXetoC | c(:)< |
| 23:29:10 | flaviu | yeah, exactly. Requiring extra dependencies isn't good ui, although development time does push in that direction.. |
| 23:29:56 | flaviu | Wow, libressl libtls is really simple to use |
| 23:30:38 | Joe_knock | Well having 1 is better than none. If libressl takes less time, at least we'll have something |
| 23:31:56 | * | gour quit (Quit: Konversation terminated!) |
| 23:33:43 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 23:47:07 | Araq | yeah go for libressl |
| 23:53:53 | * | j3rky joined #nimrod |