| 00:12:40 | Araq | lol "doesn't read well on phone" | 
| 00:12:57 | Araq | yeah ... well ... nothing does ... guess why | 
| 00:13:50 | Araq | dom96: btw a good hacker news answer would be to explain to them how open source works | 
| 00:14:27 | Araq | "hmm Nix is cool, I'll patch the C++/Perl implementation to work on Windows so that we can use Nix for Nimrod ..." | 
| 00:15:53 | Araq | <-- spot the error :-) | 
| 00:17:14 | Araq | Nix also solves a different problem | 
| 00:17:23 | dom96 | I did answer one of the comments | 
| 00:17:34 | Araq | it seems to be overly concerned with reproducible builds | 
| 00:17:44 | Araq | so every version is nailed down | 
| 00:18:21 | Araq | well you can do that with Babel, it's called "include your deps by copying the directories" | 
| 00:20:20 | * | superfunc joined #nimrod | 
| 00:20:23 | Joe_knock | Araq: You must not like many online communities :P | 
| 00:22:44 | Araq | Joe_knock: I built a programming language for geniuses because programmers are retarded | 
| 00:25:45 | * | sdw joined #nimrod | 
| 00:25:53 | Joe_knock | :D | 
| 00:27:10 | Joe_knock | Araq: Your opinion on this: http://www.youtube.com/watch?v=b2F-DItXtZs? :D | 
| 00:29:32 | * | darkf joined #nimrod | 
| 00:33:05 | Araq | Joe_knock: it's funny but I like MongoDB | 
| 00:33:21 | Araq | it's good when you know what you're doing | 
| 00:34:40 | EXetoC | that's not the impression I got | 
| 00:34:46 | EXetoC | I need to complete the wrapper already | 
| 00:35:49 | * | Jehan_ quit (Quit: Leaving) | 
| 00:37:09 | superfunc | Araq: Is there any plan to lift the capture maximum on pegs? | 
| 00:38:31 | Araq | superfunc: no, you need to copy&paste the pegs module into something that builds a real parser | 
| 00:38:56 | Araq | but then why would you? there are much better parsing algorithms around | 
| 00:40:08 | superfunc | ok | 
| 00:51:19 | * | q66 quit (Quit: Leaving) | 
| 00:51:30 | superfunc | I had only thought about it because it provides a really clean way to define a grammar | 
| 01:04:47 | * | Jesin joined #nimrod | 
| 01:17:39 | * | superfunc quit (Quit: leaving) | 
| 01:18:23 | * | superfunc joined #nimrod | 
| 01:49:00 | * | hoverbear joined #nimrod | 
| 01:56:03 | * | brson quit (Quit: leaving) | 
| 01:57:54 | * | vendethiel- quit (Ping timeout: 255 seconds) | 
| 02:02:35 | * | vendethiel joined #nimrod | 
| 02:03:52 | * | saml_ joined #nimrod | 
| 02:03:53 | * | superfunc quit (Read error: Connection reset by peer) | 
| 02:08:25 | * | Demos joined #nimrod | 
| 02:09:16 | * | superfunc joined #nimrod | 
| 02:11:59 | * | superfunc quit (Client Quit) | 
| 02:12:15 | * | superfunc joined #nimrod | 
| 02:23:40 | * | superfunc quit (Quit: leaving) | 
| 02:39:41 | * | Demos quit (Ping timeout: 244 seconds) | 
| 02:58:38 | * | goobles joined #nimrod | 
| 03:11:46 | * | brson joined #nimrod | 
| 03:11:47 | * | brson quit (Client Quit) | 
| 03:12:05 | * | brson joined #nimrod | 
| 03:12:14 | * | brson quit (Client Quit) | 
| 03:32:15 | goobles | nimrod 4 hot swap | 
| 04:01:11 | * | xenagi quit (Quit: Leaving) | 
| 04:13:32 | * | Joe_knock quit (Ping timeout: 245 seconds) | 
| 04:24:28 | * | joelmo quit (Quit: Connection closed for inactivity) | 
| 04:45:17 | * | saml_ quit (Quit: Leaving) | 
| 04:48:02 | * | ARCADIVS joined #nimrod | 
| 04:52:46 | * | kemet joined #nimrod | 
| 04:55:44 | * | kemet quit (Remote host closed the connection) | 
| 04:58:02 | * | kemet joined #nimrod | 
| 04:59:40 | * | flaviu quit (Ping timeout: 240 seconds) | 
| 05:22:56 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) | 
| 05:52:42 | * | hoverbear quit () | 
| 06:00:59 | fowl | how can i do this in nimrod, it requires offsetof(ty,field) https://docs.python.org/2/extending/newtypes.html | 
| 06:10:06 | * | brson joined #nimrod | 
| 06:46:29 | * | brson quit (Read error: Connection reset by peer) | 
| 07:25:14 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) | 
| 07:35:07 | flyx | fowl: interesting question. I cannot think of anything better than using pragma packed to be able to calculate the offset of the object fields | 
| 07:37:12 | Araq | you can importc offset: | 
| 07:38:36 | Araq | nah screw this | 
| 07:39:31 | Araq | but you can do:   cast[PNimType](typeInfo(FooType)).sons[3].offset # offset of 3rd field | 
| 07:40:03 | Araq | or something like that, my type info voodoo is rusty | 
| 07:40:13 | flyx | wouldn't that be the 4th field? | 
| 07:40:37 | Araq | the 3rd field where also the 0th field exists :P | 
| 07:40:43 | flyx | ^^ | 
| 07:40:45 | Araq | so yes, the 4th field | 
| 07:40:46 | flyx | nice one | 
| 07:42:00 | flyx | I need a cheat sheet for stuff one can do at compiletime | 
| 07:42:40 | Araq | everything except: | 
| 07:42:48 | Araq | - go *up* in the AST | 
| 07:43:00 | Araq | - looking up an arbitrary symbol | 
| 07:43:13 | * | Trustable joined #nimrod | 
| 07:43:17 | Araq | - using the FFI | 
| 07:43:50 | * | ARCADIVS joined #nimrod | 
| 07:43:52 | Araq | - processing types (as opposed to processing the type's AST) | 
| 07:44:15 | Araq | 1-3 are intentional restrictions | 
| 07:44:30 | Araq | 4 is planned | 
| 07:45:07 | flyx | where is typeInfo declared? I cannot find it in macros | 
| 07:45:14 | Araq | system | 
| 07:45:43 | flyx | hum. according to the doc, there's only getTypeInfo | 
| 07:45:57 | Araq | it returns a pointer, and the real type is not exported :P | 
| 07:46:11 | Araq | yeah, told you I'm rusty | 
| 07:46:20 | Araq | it's getTypeInfo then | 
| 07:47:08 | flyx | that works on a value, not a type. can I get this from a typedesc? | 
| 07:47:26 | Araq | hmm damn | 
| 07:47:53 | Araq | you can try ... | 
| 07:48:36 | Araq | proc getTypeInfo*(x: typeDesc): pointer {.magic: "GetTypeInfo", gcsafe.} | 
| 07:48:48 | Araq | in fact, try this: | 
| 07:49:06 | Araq | include "system/hti.nim" | 
| 07:49:23 | Araq | proc getTypeInfo*(x: typeDesc): PNimType {.magic: "GetTypeInfo", gcsafe.} | 
| 07:49:53 | Araq | echo getTypeInfo(FooType).node.sons[3].offset | 
| 07:52:02 | * | kunev joined #nimrod | 
| 07:53:22 | flyx | Error: internal error: evalOp(mGetTypeInfo) | 
| 07:53:25 | flyx | on last line | 
| 07:53:53 | Araq | fix it | 
| 07:54:11 | Araq | add 'mGetTypeInfo' to the list of unsupported ops in evalOp | 
| 07:54:48 | Araq | then all you need to do is ensure mGetTypeInfo works for typedesc in ccgexprs.nim | 
| 07:55:37 | flyx | might have a look at it later today | 
| 07:55:41 | Araq | but this should already work | 
| 07:55:48 | Araq | so it's only the 1 fix | 
| 07:55:51 | Araq | try it now | 
| 07:55:51 | flyx | unfortunately, I get payed for doing other, less interesting stuff :/ | 
| 07:55:56 | Araq | make a PR | 
| 07:56:12 | Araq | flyx: that's why you get *paid* | 
| 07:56:25 | flyx | ah, my bad | 
| 07:56:42 | Araq | no, I mean it's the nature of the universe | 
| 07:56:50 | Araq | they pay you because it's no fun | 
| 07:59:07 | flyx | it could be better. I mean, I could search a better job or go back to university and make a Dr. | 
| 08:00:40 | flyx | most things are better than maintaining 10 year old Java code | 
| 08:01:02 | Araq | ugh. I feel for you. | 
| 08:02:36 | * | BitPuffin quit (Ping timeout: 244 seconds) | 
| 08:02:50 | Araq | how many design pattern per line? ;-) | 
| 08:04:46 | flyx | dunno. is „we split the code into multiple enterprise modules so we cannot debug-step from one into another“ a design pattern? | 
| 08:05:40 | flyx | ah well, it's Java, so, yes it is | 
| 08:07:30 | flyx | I still cannot wrap my head around why *anyone* could think this Java Enterprise stuff is useful for anything other than ensuring that the customer pays large sums for continuous support | 
| 08:07:46 | flyx | but perhaps that's the point | 
| 08:10:40 | * | ehaliewi` quit (Ping timeout: 240 seconds) | 
| 08:17:30 | fowl | interesting Araq | 
| 08:17:41 | fowl | i always wondered what that gettypeinfo thing is | 
| 08:36:05 | * | joelmo joined #nimrod | 
| 08:44:22 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) | 
| 08:48:38 | Skrylar | flyx: but bigger balls of mud = more billable hours! | 
| 08:52:40 | * | BitPuffin joined #nimrod | 
| 09:43:03 | * | Trustable quit (Ping timeout: 240 seconds) | 
| 09:43:39 | * | vendethiel quit (Ping timeout: 255 seconds) | 
| 09:45:25 | * | vendethiel joined #nimrod | 
| 09:47:39 | * | Trustable joined #nimrod | 
| 10:02:10 | * | vendethiel quit (Ping timeout: 240 seconds) | 
| 10:02:15 | * | vendethiel- joined #nimrod | 
| 10:12:10 | * | Trustable quit (Ping timeout: 240 seconds) | 
| 10:24:32 | * | Trustable joined #nimrod | 
| 10:34:09 | * | soc joined #nimrod | 
| 10:41:05 | * | q66 joined #nimrod | 
| 10:41:10 | dom96 | hi | 
| 10:45:18 | EXetoC | ho | 
| 10:50:31 | * | vendethiel- quit (Ping timeout: 244 seconds) | 
| 10:51:01 | * | vendethiel joined #nimrod | 
| 11:03:00 | * | vendethiel- joined #nimrod | 
| 11:03:32 | * | vendethiel quit (Ping timeout: 245 seconds) | 
| 11:36:37 | * | saml_ joined #nimrod | 
| 11:37:01 | * | meguli joined #nimrod | 
| 11:37:29 | * | meguli quit (Client Quit) | 
| 11:49:00 | * | Johz joined #nimrod | 
| 11:52:44 | * | q66 quit (Ping timeout: 252 seconds) | 
| 12:05:01 | * | q66 joined #nimrod | 
| 12:20:07 | * | saml_ quit (Quit: Leaving) | 
| 12:22:42 | * | untitaker quit (Ping timeout: 245 seconds) | 
| 12:25:42 | flyx | so, um, when I stuff too much things into a TSet, I get "Error: interpretation requires too many iterations" | 
| 12:26:14 | flyx | this seems to come from a call in sets.nim: high(s.data) | 
| 12:28:15 | flyx | this happens when 64 elements are in the set | 
| 12:29:36 | * | untitaker joined #nimrod | 
| 12:35:46 | flyx | same thing happens with TTable | 
| 12:43:30 | flyx | only at compile time | 
| 12:45:25 | Araq | hmmm well we have a bug report about TTable not always working properly at compile time | 
| 12:48:17 | flyx | hm yes, read it, but this is different | 
| 12:48:37 | flyx | it originates in the hash calculation of TSet and TTable | 
| 12:51:18 | flyx | I'll file an issue | 
| 12:54:11 | Araq | ok | 
| 13:04:36 | flyx | https://github.com/Araq/Nimrod/issues/1305 | 
| 13:05:38 | Araq | flyx: wanna fix these VM bugs? | 
| 13:06:17 | flyx | Araq: well I can try. | 
| 13:06:50 | Araq | well you'll need my help | 
| 13:09:45 | flyx | okay. I'll go shopping and do some other boring but necessary RL stuff, then I'll return and ask you about the VM | 
| 13:18:11 | Araq | good | 
| 13:28:12 | * | darkf quit (Quit: Leaving) | 
| 13:41:55 | Skrylar | it always sucks when you get a programming problem so fundamentally boring that it grinds all of your coding to a halt because you hate it that much | 
| 13:42:18 | * | pafmaf joined #nimrod | 
| 13:55:36 | flyx | Araq: okay, I'm ready | 
| 13:57:28 | Araq | well what does   echo high(s.data)   produce in sets.nim? | 
| 14:01:25 | * | flaviu joined #nimrod | 
| 14:04:10 | flyx | always 63. interestingly, if I add it before the line that fails, it does produce its usual output right before the fail | 
| 14:04:58 | flyx | so high(s.data) seems to be working on its own. | 
| 14:05:56 | Araq | er ... you do run the compiler in debug mode, right? | 
| 14:06:15 | flyx | ah, I should, I guess | 
| 14:07:18 | * | Jehan_ joined #nimrod | 
| 14:08:49 | flyx | does it matter? the error is in the VM, does debugging alter the macros that run in the VM? | 
| 14:09:06 | flaviu | flyx: You get a stack trace | 
| 14:09:36 | flyx | flaviu: I also get a stack trace without --debugger:on | 
| 14:13:49 | flyx | the stack trace doesn't seem right | 
| 14:15:38 | flyx | what happens seems to be that the following loop doesn't return, because it loops over all entries - which happen to be 64 and are all filled | 
| 14:16:56 | * | hoverbear joined #nimrod | 
| 14:17:16 | flyx | and the set doesn't recognize this and doesn't expand | 
| 14:18:06 | flyx | afaik, the theory tells it's a good idea to expand a hash table when 50% is filled | 
| 14:18:07 | Araq | well that pretty much means sets.enlarge doesn't work properly | 
| 14:18:38 | Araq | it uses 66% look at mustRehash | 
| 14:18:43 | * | hoverbear quit (Client Quit) | 
| 14:19:27 | Araq | my suspicion is:   swap(s.data, n) | 
| 14:19:43 | Araq | if that fails to update 's.data' properly you'll likely see this misbehaviour | 
| 14:19:47 | flyx | well, the loop in rawGetImpl doesn't return until a match is found | 
| 14:19:55 | Araq | yes | 
| 14:19:55 | flyx | but after the loop, there is a result = -1 | 
| 14:20:04 | Araq | but the bug happens before | 
| 14:20:06 | flyx | which would lead to a call to enlarge | 
| 14:20:22 | flyx | but the code never gets there | 
| 14:20:30 | Araq | listen to me | 
| 14:20:37 | flyx | okay | 
| 14:20:44 | Araq | if the data array is 100% full, that is the bug | 
| 14:20:55 | Araq | it should never be this full in the first place | 
| 14:21:12 | Araq | so it failed to enlarge *before* the mget call | 
| 14:21:31 | Araq | so that's your problem | 
| 14:23:08 | flyx | okay. so I never call anything but incl on the set, so the only point where enlarge could get called, is in inclImpl() | 
| 14:23:16 | * | goobles quit (Ping timeout: 246 seconds) | 
| 14:23:36 | flyx | that only happens if rawGet returns a negative number | 
| 14:24:49 | flyx | okay, this happens when an empty slot is found | 
| 14:27:45 | Jehan_ | flyx: Do you have the code to look at or is it too complex for a gist? | 
| 14:28:09 | flyx | Jehan_: it's right here: https://github.com/Araq/Nimrod/blob/devel/lib/pure/collections/sets.nim | 
| 14:28:22 | Jehan_ | No, I mean how you use it. | 
| 14:28:31 | Jehan_ | I know where sets.nim is. :) | 
| 14:28:46 | flyx | ah, that's included in my issue: https://github.com/Araq/Nimrod/issues/1305 | 
| 14:29:33 | Jehan_ | Ah, I see. Looks like I got in on the tail end of the discussion. | 
| 14:30:06 | Araq | flyx is debugging sets.nim instead of the vm :P | 
| 14:30:48 | Jehan_ | It works when running it outside the VM. | 
| 14:31:27 | flyx | jup, swap is the problem | 
| 14:31:37 | flyx | after swap, both n and s.data have a length of 64 | 
| 14:32:45 | flyx | the order of the parameters doesn't matter | 
| 14:32:52 | Araq | see? it helps to listen | 
| 14:33:17 | flyx | jep. I just wanted to get my grips on the code | 
| 14:34:58 | Araq | the opcode for swap is opcSwap | 
| 14:35:06 | flyx | k | 
| 14:35:23 | Araq | 90% of the vm bugs are not in the vm, but in vmgen which is its code generator | 
| 14:36:02 | Araq | so have a look at line 792 in vmgen.nim | 
| 14:36:12 | Araq | and lots of things are suspicious | 
| 14:37:44 | Araq | 'setLen' takes a 'var' parameter and these needs lots of complex logic to support in the VM | 
| 14:38:01 | Araq | so it calls:       c.genAsgnPatch(n.sons[1], d) | 
| 14:38:08 | Araq | for its var parameter | 
| 14:38:15 | Araq | swap does nothing like that | 
| 14:38:44 | Araq | also the 2nd argument is stored in a "tmp" and then freed with freeTemp | 
| 14:39:00 | Araq | this should be a nop, but it makes no sense | 
| 14:39:24 | Araq | the 2nd arg is a var parameter too and these are not kept in temporary registers | 
| 14:40:34 | Araq | I gotta go, see you later | 
| 14:40:54 | Araq | try to call | 
| 14:40:56 | Araq |     c.genAsgnPatch(n.sons[1], d) | 
| 14:41:08 | Araq |     c.genAsgnPatch(n.sons[2], tmp) | 
| 14:41:13 | Araq | for mSwap | 
| 14:41:17 | Araq | bye | 
| 14:41:23 | flyx | kay, bye | 
| 14:47:53 | flyx | I should upgrade to an SSD sometime to get better compile times | 
| 15:03:27 | * | Puffin joined #nimrod | 
| 15:03:57 | * | BitPuffin quit (Ping timeout: 245 seconds) | 
| 15:04:47 | flyx | jup, this works | 
| 15:04:58 | * | flyx prepares a PR | 
| 15:05:12 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 15:05:55 | * | Puffin is now known as BitPuffin | 
| 15:12:03 | * | pafmaf joined #nimrod | 
| 15:16:17 | * | vendethiel- quit (Ping timeout: 272 seconds) | 
| 15:17:28 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 15:18:13 | KevinKelley | queues bug?  compiler says "error: undeclared identifier: count" on call to q.dequeue() | 
| 15:19:01 | KevinKelley | looks like the count member is non-public, maybe a visibility problem in the gen'd code? | 
| 15:19:57 | * | vendethiel joined #nimrod | 
| 15:26:47 | * | pafmaf joined #nimrod | 
| 15:29:27 | * | pafmaf quit (Client Quit) | 
| 15:31:36 | Jehan_ | KevinKelley: I think that's fixed in the devel branch. | 
| 15:32:41 | Jehan_ | Hmm, no, apparently the fix didn't go through. | 
| 15:35:57 | * | pafmaf joined #nimrod | 
| 15:36:51 | Jehan_ | Ugh, it was fixed and apparently got reverted accidentally in another patch. | 
| 15:38:01 | Jehan_ | Or not? That patch says it fixes the issue for real, and now that I'm trying it, it seems to compile cleanly. | 
| 15:38:59 | * | io2 joined #nimrod | 
| 15:44:20 | * | Johz quit (Quit: Leaving) | 
| 15:56:57 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 16:00:29 | * | Demos joined #nimrod | 
| 16:00:37 | * | pafmaf joined #nimrod | 
| 16:02:31 | * | hoverbear joined #nimrod | 
| 16:02:41 | * | pafmaf quit (Client Quit) | 
| 16:03:10 | Demos | dom96, ping | 
| 16:13:39 | * | kunev quit (Quit: leaving) | 
| 16:13:46 | dom96 | Demos: sup | 
| 16:14:24 | Demos | is anyone working on fixing and improving the times module? | 
| 16:14:26 | NimBot | nimrod-code/babel master f194dbf Grzegorz Adam Hankiewicz [+0 ±1 -0]: Updates required nimrod compiler version in readme. | 
| 16:14:26 | NimBot | nimrod-code/babel master edd92a2 Dominik Picheta [+0 ±1 -0]: Merge pull request #45 from gradha/pr_updates_nimrod_version... 2 more lines | 
| 16:14:44 | dom96 | Demos: Not that I know of. What do you want to fix in it? | 
| 16:15:42 | Demos | according to the GSoC document there is a bug in the `-` operator, I also really want high precision timer support, although I dont know if times is the right place to do that | 
| 16:16:19 | * | pafmaf joined #nimrod | 
| 16:17:05 | dom96 | ahh, go ahead. I think the compiler makes use of a high precision timer maybe you could just grab the code from there. | 
| 16:17:16 | dom96 | It's used for the real-time GC IIRC | 
| 16:17:22 | dom96 | not sure where to look though | 
| 16:22:27 | Demos | yeah I looked over there (lib/compiler/timers.nim). I am not sure if that should be integrated into times or not. Times seems to be more about wall clocks and dates | 
| 16:26:43 | Demos | hmmmm to fix the error in times `-` we would have to know when to switch to the julan calender.... | 
| 16:37:44 | * | johnsoft joined #nimrod | 
| 16:47:13 | * | nande joined #nimrod | 
| 16:53:14 | * | Matthias247 joined #nimrod | 
| 16:53:56 | * | brson joined #nimrod | 
| 17:00:38 | * | askatasuna joined #nimrod | 
| 17:00:52 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 17:03:46 | * | soc quit (Quit: Leaving.) | 
| 17:05:33 | * | hoverbear quit (Ping timeout: 240 seconds) | 
| 17:06:20 | * | pafmaf joined #nimrod | 
| 17:06:24 | * | hoverbear joined #nimrod | 
| 17:11:25 | * | superfunc joined #nimrod | 
| 17:11:33 | superfunc | morning everyone! | 
| 17:12:44 | * | Jehan_ looks at the clock. "Yeah, right …" :) | 
| 17:13:15 | EXetoC | he's in one of those silly timezones | 
| 17:13:15 | superfunc | You'll have to forgive my typical california antics | 
| 17:13:53 | Jehan_ | Oh, I was just kidding. I mean, I lived in Oregon only a few years ago. | 
| 17:14:39 | Jehan_ | Calling my family while they were having breakfast and just before I was about to go to bed was an interesting experience. :) | 
| 17:14:39 | superfunc | Oregon isn't too bad, I'm in Eugene for a few more days. But I'll be happy to get back to San Jose where the internet wont suck | 
| 17:15:30 | Jehan_ | Heh. I think I had Comcast back then. It wasn't bad, just horribly expensive. | 
| 17:17:39 | superfunc | Its that or AT&T in the bay area | 
| 17:18:05 | superfunc | Some new ISPs are popping up in SF, and google fiber is supposed to hit the valley soon, so I suppose there is hope | 
| 17:21:59 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 17:22:40 | * | Demos quit (Ping timeout: 244 seconds) | 
| 17:24:36 | flyx | in a macro, how can I tell the compiler to fail with an error message that displays file, line and column of a PNimrodNode? | 
| 17:29:53 | * | aarondabomb joined #nimrod | 
| 17:30:10 | * | aarondabomb left #nimrod (#nimrod) | 
| 17:30:12 | superfunc | fowl: Why is static linking disabled in sdl2? | 
| 17:30:43 | * | pafmaf joined #nimrod | 
| 17:33:44 | * | io2 quit (Ping timeout: 260 seconds) | 
| 17:34:30 | Araq | flyx: now fix the other reported VM bug please, about 'add' iirc | 
| 17:34:58 | flyx | Araq: string.add? aye, sir! | 
| 17:35:19 | superfunc | Jehan_: Do you know much about the implications of using something that is LGPL? the license I'm looking at says I have to provide a way for the user to link with something else. Is providing the source sufficient? | 
| 17:35:59 | Araq | flyx: this is done by mAppendStrCh, mAppendStrStr and mAppendSeqElem | 
| 17:36:00 | Jehan_ | Source should generally be sufficient, as long as it actually compiles. | 
| 17:36:27 | Araq | these all call genBinaryStmtVar | 
| 17:36:38 | superfunc | Ok. I should just convert my code from sdl1.2 to sdl2 to avoid it altogether. | 
| 17:36:40 | Jehan_ | Not a big fan of either the LGPL or the GPL, so I'm avoiding them as much as I can. | 
| 17:36:50 | Araq | which contains this line: | 
| 17:36:52 | Araq |   #c.genAsgnPatch(n.sons[1], dest) | 
| 17:37:01 | Araq | why is it disabled? I don't know | 
| 17:37:10 | Araq | enable it and watch everything work ... | 
| 17:37:21 | Araq | btw you should really run the test suite | 
| 17:37:34 | Araq | nimrod c tests/testament/tester | 
| 17:37:40 | flyx | kk | 
| 17:37:42 | Araq | tests/testament/tester cat vm | 
| 17:37:48 | superfunc | Jehan_: I think sdl2 is zlib | 
| 17:38:22 | Araq | and the category 'macros' too | 
| 17:38:28 | Jehan_ | superfunc: I don't even know what sdl2 is. :) | 
| 17:39:00 | fowl | flyx, i disabled it because it wasnt supported in the other modules | 
| 17:39:14 | superfunc | Oh, my bad lol. Its a game library. Fowl made wrappers for the old version(1.2) which is LGPL and the new(2.0) which is zlib | 
| 17:39:43 | Jehan_ | Gotcha. | 
| 17:40:12 | fowl | flyx, you can enable it if you like but dont do it like the guy in issue #2 | 
| 17:41:19 | superfunc | fowl: was your previous message to me? | 
| 17:41:29 | superfunc | fowl: about statically linking sdl2 | 
| 17:42:30 | * | hoverbea_ joined #nimrod | 
| 17:42:35 | fowl | yeah sry | 
| 17:42:43 | superfunc | ok, I figured. Thanks for answering | 
| 17:43:09 | superfunc | I guess I'll stick with 1.2 for now. | 
| 17:43:17 | fowl | why? | 
| 17:43:35 | superfunc | I wanted to statically link sdl in. | 
| 17:44:15 | * | hoverbear quit (Ping timeout: 255 seconds) | 
| 17:44:53 | fowl | i dont think the 1.2 has that option? i just did it for an experiment | 
| 17:45:20 | fowl | it is easy to re-enable though, just uncomment some stuff and make a PR | 
| 17:47:49 | * | BitPuffin quit (Ping timeout: 264 seconds) | 
| 17:48:01 | superfunc | I think I did in in 1.2 by passing all the flags through to gcc | 
| 17:49:04 | * | BlameStross joined #nimrod | 
| 17:50:37 | * | Skrylar quit (Ping timeout: 245 seconds) | 
| 17:50:45 | flyx | enabling the line neither fixes the bug I reported nor the bug it possibly duplicates | 
| 17:51:30 | * | io2 joined #nimrod | 
| 17:52:20 | Araq | hi BlameStross welcome | 
| 17:52:28 | Araq | flyx: ok ... too bad | 
| 17:53:00 | flyx | the tester currently raises an error in tcompiletimetable.nim | 
| 17:53:10 | flyx | I'll see if it vanishes if I remove the change | 
| 17:53:28 | Araq | no that's a currently failing test iirc | 
| 17:53:42 | Araq | but sure check it | 
| 17:54:29 | superfunc | Araq: Does --passC and --passL supersede nimrod code that tries to disable static linking? | 
| 17:55:11 | Araq | superfunc: --passC and --passL all append to some internal buffer, dunno the order but the compiler tells you how it invokes GCC | 
| 17:55:19 | flyx | same test error without the change. and both times, there's also a test in macros failing, tstringinterp.nim | 
| 17:56:10 | superfunc | Ok, I was able to statically link sdl1.2 without problem. Checking with ldd filename, I only saw libc and a few other things, so I think my understanding of it is correct. | 
| 17:56:52 | fowl | superfunc, the easier way is {.passl: gorge("pkg-config --libs sdl2").} | 
| 17:56:58 | Araq | flyx: tstringinterp should not fail ... argh | 
| 17:57:11 | superfunc | fowl: Much easier | 
| 17:57:16 | superfunc | I wish I had known that lol | 
| 17:57:25 | superfunc | because the string of things to include was huge | 
| 17:57:43 | flyx | Araq: okay, I'll test again without my previous change | 
| 17:58:32 | fowl | superfunc, if you uncomment this you're good to go https://github.com/nimrod-code/sdl2/blob/master/src/sdl2.nim#L8 | 
| 17:58:54 | Araq | I still don't get why you all want static linking | 
| 17:59:12 | Araq | doesn't  gorge("pkg-config --libs sdl2") tell you that it simply DOESN'T work? | 
| 17:59:43 | * | pafmaf quit (Quit: This computer has gone to sleep) | 
| 18:00:11 | flyx | well, the test fails on current devel without any of my changes | 
| 18:00:11 | fowl | shrug | 
| 18:03:20 | Araq | flyx: yeah it's some other regression. yay | 
| 18:03:46 | * | Matthias247 quit (Read error: Connection reset by peer) | 
| 18:06:07 | superfunc | fowl: thanks | 
| 18:06:34 | superfunc | I just realized something, to Araq's point. You can't really get a completely self-contained binary anyways because of libc | 
| 18:07:32 | superfunc | fowl: I have one last question, if you don't mind | 
| 18:07:44 | fowl | ok | 
| 18:08:42 | superfunc | Do you see much benefit to a 2D game for sdl2 over sdl1.2. I've read that sdl2 offloads a lot of cpu work onto the gpu if available, but I don't see it being much of an issue in this case | 
| 18:10:00 | Trixar_za | It does that by plugin directly into mesa if memory serves | 
| 18:10:04 | Trixar_za | plugging * | 
| 18:11:36 | Trixar_za | You'll probably get better support with sdl1.2 than for sdl2 on systems with older versions of OpenGL or SDL | 
| 18:11:58 | Trixar_za | Not that sdl1.2 doesn't have it's own host of problems | 
| 18:12:33 | fowl | superfunc, sdl2 is being worked on, its changed a lot since 1.2 | 
| 18:13:37 | fowl | i like the new api, and it can target android/ios | 
| 18:13:46 | superfunc | Ok, now you have me | 
| 18:14:37 | fowl | i wouldnt worry about supporting old computers either, one day we'll round up all computers over a year old and burn them (i had a dream about it) | 
| 18:14:45 | superfunc | It really wasn't that much code to convert, I was just being lazy. | 
| 18:17:36 | * | io2 quit (Ping timeout: 260 seconds) | 
| 18:28:24 | * | hoverbea_ is now known as hoverbear | 
| 18:40:41 | * | vendethiel quit (Ping timeout: 244 seconds) | 
| 18:40:44 | * | vendethiel- joined #nimrod | 
| 18:41:41 | reactormonk | Araq, what do you think of {.borrows *.} ? | 
| 18:42:13 | * | Demos joined #nimrod | 
| 18:42:36 | flyx | TSets seem to miss union and intersection | 
| 18:42:52 | reactormonk | Maybe & and | | 
| 18:43:04 | Araq | that would be + and * in nimrod | 
| 18:43:23 | Araq | but yeah quite likely that they missing | 
| 18:43:27 | Araq | add them | 
| 18:43:40 | flyx | will do | 
| 18:43:45 | Araq | reactormonk: dunno, sounds like a bad idea | 
| 18:45:00 | reactormonk | Araq, let's say you want to implement meters as a type. type meters = distinct float {.borrows: *.} sounds good to me | 
| 18:45:37 | Araq | and what does the * mean? | 
| 18:45:57 | Araq | meter+meter == meter | 
| 18:46:05 | Araq | meter*meter == meter? | 
| 18:46:27 | reactormonk | hm, duh | 
| 18:46:46 | reactormonk | But I suppose "import all additive constructs" is too complicated | 
| 18:47:39 | Araq | meter * <no unit of measure> == meter btw | 
| 18:48:08 | reactormonk | anything required to make that work? | 
| 18:48:21 | NimBot | Araq/Nimrod devel 15456b5 def [+0 ±1 -0]: Use monospace as fallback font on website | 
| 18:48:21 | NimBot | Araq/Nimrod devel 7a5be93 Simon Hafner [+0 ±1 -0]: Merge pull request #1293 from def-/website-monospace... 2 more lines | 
| 18:48:41 | reactormonk | is it {.effect.} or {.effects.}? | 
| 18:48:50 | superfunc | ls | 
| 18:48:58 | reactormonk | ^^ | 
| 18:49:07 | flyx | what does the dirty pragma do? | 
| 18:49:14 | Araq | I don't know, reactormonk :-) | 
| 18:49:35 | Araq | flyx: you have to be over 18 to use the dirty pragma | 
| 18:50:22 | NimBot | Araq/Nimrod devel 3c89ad7 def [+0 ±1 -0]: Rename {.effect.} to {.effects.} in Tut 2 | 
| 18:50:22 | NimBot | Araq/Nimrod devel f793523 Simon Hafner [+0 ±1 -0]: Merge pull request #1294 from def-/tut-fix... 2 more lines | 
| 18:50:35 | flyx | Araq: I am 27 and know how to code C++ without shooting myself in the knee, does this suffice? | 
| 18:51:23 | reactormonk | superfunc, nice issue report | 
| 18:51:33 | Araq | flyx: 'dirty': every identifier is looked up in the instantiation context | 
| 18:52:02 | Araq | (you can still override this with a 'bind' statement I think) | 
| 18:52:48 | flyx | ah. well, I'll be probably just calling the low-level stuff, so I don't need it myself | 
| 18:53:21 | Araq | the macro system is actually quite easy to understand once you spent a few years thinking about it | 
| 18:53:22 | reactormonk | Araq, you want more documentation? Go read that PR from gradha (#1299) | 
| 18:53:28 | flyx | ^^ | 
| 18:53:46 | Araq | there is immediate vs. non-immediate | 
| 18:53:51 | Araq | and dirty vs clean | 
| 18:54:06 | flyx | oh no, my music stopped! skill-- | 
| 18:54:35 | flyx | yeah, I already used immediate a lot | 
| 18:54:37 | reactormonk | dirty ones can interact with the calling code other than arguments passed | 
| 18:54:48 | reactormonk | ... data flow wise. | 
| 18:54:55 | Araq | immediate means "doesn't participate in overloading resolution" (and so supports more dangerous stuff) | 
| 18:55:29 | Araq | dirty means "look up the symbols as a C macro does" | 
| 18:56:18 | superfunc | reactormonk: what? | 
| 18:56:42 | reactormonk | superfunc, it looks well constructed. | 
| 18:57:00 | superfunc | The bug I reported? | 
| 18:57:07 | reactormonk | yup | 
| 18:57:32 | superfunc | Oh, thanks lol. It was so minor, but I figured better to report than not | 
| 19:06:40 | Araq | what the heck ... dom96 ! | 
| 19:06:59 | Araq | got closure iterators to work again | 
| 19:18:36 | superfunc | dependency hell makes for a sucky wednesday | 
| 19:20:15 | flyx | why doesn't TOrderedSet have excl()? is this by design? | 
| 19:25:12 | flyx | well, I guess union on ordered sets doesn't make much sense anyway | 
| 19:41:53 | dom96 | Araq: ? | 
| 19:42:40 | dom96 | Araq: oh, you got them to work. Why the what the heck? | 
| 19:50:04 | Araq | because it finally worked | 
| 19:50:37 | Araq | flyx: iirc excl is hard to implement for TOrderedSet and might even require a less efficient data structure | 
| 19:51:24 | dom96 | Araq: well I guess they're still not perfect or else I would see some commits already | 
| 19:52:42 | flyx | Araq: can I just add tests to tests/sets? | 
| 19:53:39 | * | Matthias247 joined #nimrod | 
| 19:56:34 | Araq | flyx: the test has to start with t and then it will be run by the tester, yes | 
| 19:56:49 | flyx | good | 
| 19:56:52 | flyx | PR incoming | 
| 19:57:42 | Araq | dom96: well yes but at least simple closure iterators work again | 
| 19:58:10 | dom96 | Araq: good | 
| 19:58:27 | dom96 | I guess it's time for me to stop playing Far Cry 3 and get back to work. | 
| 20:02:05 | Araq | bbl | 
| 20:02:23 | flyx | ah damn, I cannot create a new PR on the same branch while the old one is still pending | 
| 20:02:36 | flyx | can't github do cherry picking for PRs? | 
| 20:03:27 | Araq | flyx: so push somebody to accept your PR | 
| 20:03:35 | Araq | but not me, I'm not here | 
| 20:05:17 | * | flyx carefully pushes dom96 | 
| 20:05:26 | dom96 | flyx: why can't you create a new branch? | 
| 20:05:36 | flyx | dom96: sure, I can | 
| 20:05:43 | flyx | was about to do that | 
| 20:07:28 | dom96 | I'm not confident enough to be accepting vmgen changes :P | 
| 20:07:45 | flyx | kk | 
| 20:33:17 | superfunc | Hmm, any idea why I'm not able to declare something as const when its initializers only depend on const values? | 
| 20:34:12 | superfunc | Eg. const some_x*: int = 5 ... position_rect* = TRect(x:some_x,..) | 
| 20:34:22 | superfunc | but if its in under var it works | 
| 20:36:35 | flyx | because TRect is an object? | 
| 20:36:50 | superfunc | Can we not have const objects? | 
| 20:37:17 | flyx | no, according to the manual: „Constants cannot be of type ptr, ref, var or object, nor can they contain such a type.“ | 
| 20:37:33 | superfunc | Thanks flyx, I didn't know that :) | 
| 20:37:53 | flyx | you can of course use let instead | 
| 20:37:53 | superfunc | I should get around to finishing reading that tonight | 
| 20:38:23 | superfunc | yep, thats what I ended up doing | 
| 20:40:56 | flyx | well. enough coding for today | 
| 20:41:28 | * | flyx goes getting some sleep | 
| 20:41:36 | flyx | bye folks | 
| 20:45:07 | * | vendethiel joined #nimrod | 
| 20:47:16 | * | vendethiel- quit (Ping timeout: 244 seconds) | 
| 20:48:05 | * | vendethiel quit (Read error: Connection reset by peer) | 
| 20:48:28 | * | vendethiel joined #nimrod | 
| 20:52:23 | * | BitPuffin joined #nimrod | 
| 20:53:38 | Jehan_ | superfunc: `let` values are still immutable, so you won't see a difference. | 
| 20:54:11 | Jehan_ | As I understand it (caveat, I may be wrong) `const` values are those that can actually be put in static memory. | 
| 20:54:20 | Jehan_ | `let` values still are constructed at runtime. | 
| 20:54:22 | * | askatasuna quit (Ping timeout: 245 seconds) | 
| 20:54:23 | superfunc | Yeah, there is a problem with using let though | 
| 20:54:32 | superfunc | if you need to take its addr | 
| 20:55:05 | superfunc | so I had to use a var anyways | 
| 20:57:55 | * | fowl quit (Quit: Leaving) | 
| 21:01:08 | Matthias247 | just after we talked about it - android seems to get rid of JIT | 
| 21:05:58 | * | superfunc quit (Quit: leaving) | 
| 21:18:33 | * | johnsoft quit (Ping timeout: 240 seconds) | 
| 21:19:08 | * | johnsoft joined #nimrod | 
| 21:31:55 | Jehan_ | Matthias247: Oh? Haven't seen that. | 
| 21:34:04 | Jehan_ | Ah, interesting. So, they compile during installation. Hmm. | 
| 21:34:09 | Matthias247 | Jehan_: read only a short german press report about Google IO and Android L. There they say that Android L dismisses Dalvik for Android Runtime (ART), whicch is an ahead of time compiler during installation | 
| 21:34:30 | Jehan_ | Yeah, reading up on it on Ars Technica right now. | 
| 21:34:33 | Matthias247 | sounds logical | 
| 21:34:36 | Jehan_ | It does make sense. | 
| 21:34:39 | Matthias247 | even windows does this :) | 
| 21:34:47 | Matthias247 | for the .net runtime | 
| 21:34:59 | Jehan_ | They retain code portability and get better speed. | 
| 21:35:23 | Matthias247 | yes, and they can still distribute architecture-independent APKs | 
| 21:35:39 | Jehan_ | Yup, that's what I meant by portability. | 
| 21:36:13 | Matthias247 | ok, you could also distribute LLVM IL in those packages and compile them at installation ;) | 
| 21:36:25 | Jehan_ | Heh. Same difference. | 
| 21:36:32 | Matthias247 | I think that's what pncal does | 
| 21:36:38 | Matthias247 | pnacl | 
| 21:36:45 | Jehan_ | I wouldn't be surprised if they are actually using LLVM for this. | 
| 21:36:56 | Jehan_ | Since they're heavily invested in the development. | 
| 21:37:36 | Matthias247 | don't think so | 
| 21:38:02 | Jehan_ | Google employs a few Clang/LLVM core developers? | 
| 21:38:37 | Matthias247 | yes, but I don't think llvm helps in reading java bytecode | 
| 21:39:00 | Jehan_ | No, they're probably translating JVM bytecode to LLVM IR and then compile that. | 
| 21:39:13 | Matthias247 | ok, they could add a frontend which transforms the bytecode/dex to IR | 
| 21:39:32 | Jehan_ | Actually, Dalvik bytecode, as I recall. :) | 
| 21:40:01 | Matthias247 | but I think google has also enough expierence in direct code generation to do it without LLVM. E.g. they also do it in the Dart VM | 
| 21:40:36 | Jehan_ | On a related note, I have now discovered Avian and think I can pretty much dump C++ entirely, even for the odd personal project. | 
| 21:41:02 | Jehan_ | Matthias247: Yeah, but they have only finite developer time. Still better to reuse what they have. | 
| 21:41:12 | Matthias247 | this? https://github.com/ReadyTalk/avian | 
| 21:41:48 | Jehan_ | Yeah. | 
| 21:42:45 | Matthias247 | but I thought a JIT can optimize some things that ahead-of-time can't, e.g. devirtualization? | 
| 21:43:24 | Matthias247 | or will an ahead-of-time compiler still have more time and possibilies for optimization? | 
| 21:43:25 | Jehan_ | What's the context for that question? | 
| 21:43:35 | Jehan_ | What Google is doing with Android? | 
| 21:43:39 | Matthias247 | yes | 
| 21:43:58 | Jehan_ | It's a double-edged sword, especially on mobile architectures. | 
| 21:44:08 | Jehan_ | JIT optimization doesn't come for free. | 
| 21:44:35 | Jehan_ | Oracle's JVM takes quite a bit of time to warm up and have reasonable performance, for example. | 
| 21:45:00 | Jehan_ | Which is one reason why Java tends to do poorly on microbenchmarks, but pretty well on large systems. | 
| 21:45:22 | Jehan_ | You can do a lot of devirtualization at compile time even without JIT. | 
| 21:46:09 | Jehan_ | The biggest direct benefit of a JIT is that you don't incur overheads for position-independent code, linker indirections to stubs, and a few other things. | 
| 21:46:14 | * | pafmaf joined #nimrod | 
| 21:49:34 | Matthias247 | Jehan_: can the avian thing do java8 lambdas? ;) | 
| 21:49:40 | flaviu | Are people really including warmup in JVM microbenchmarks? I thought its common knowledge that a library to do your microbenchmarks is absolutely essential. | 
| 21:49:49 | Jehan_ | Matthias247: No idea. It's a recent discovery. | 
| 21:49:59 | Jehan_ | I know that it's slower than Oracle's JDK. | 
| 21:50:17 | Matthias247 | android is also slower ;) | 
| 21:50:54 | Jehan_ | But it's an alternative if a system doesn't have JDK installed without dragging in a huge JDK installation. | 
| 21:51:07 | Jehan_ | At least in theory, I'm still investigating some of the details. | 
| 21:51:30 | Jehan_ | The standard build process still requires a Java compiler to build the standard classes. | 
| 21:51:42 | Jehan_ | But it should be possible to ship the bytecode and forgo that step. | 
| 21:53:03 | Jehan_ | The ultimate reason why I've still been occasionally falling back to C/C++ is simply that you can get it to run anywhere. | 
| 21:53:16 | Matthias247 | hmm, I've also fascinated a guy from an embedded company this week:  "I could compile your c# library and applications with a single mono command and it immediatly run on linux" | 
| 21:53:38 | Jehan_ | Heh. :) | 
| 21:53:54 | Jehan_ | I'm actually pretty impressed by what the Xamarin guys are doing. At the same time ... | 
| 21:54:07 | Jehan_ | This attitude strikes me as just a tad optimistic. | 
| 21:54:17 | Matthias247 | yes | 
| 21:54:28 | flaviu | Matthias247: Last time I checked, the performance isn't as good as .Net, so it isn't really suitable for things that need speed | 
| 21:55:02 | Jehan_ | flaviu: It isn't, but few things really do need speed. Those that do don't use .NET, either. | 
| 21:55:16 | Matthias247 | flaviu: we didn't perform measurements. But for most things it would still be fast enough | 
| 21:55:36 | Jehan_ | What I found funny was the belief in portability between Windows and Linux. | 
| 21:55:45 | Matthias247 | And it would be still way faster than python and co | 
| 21:55:50 | Jehan_ | No other platform has made that magically possible, so why the CLR? | 
| 21:56:24 | flaviu | Jehan_: Huh? Java does that very well. | 
| 21:56:43 | Jehan_ | Matthias247: Yes. I have actually used Mono quite a bit in the past. | 
| 21:57:17 | Matthias247 | I will at least look forward to use it for a lot of prototyping and testing related stuff | 
| 21:57:32 | flaviu | Although the look-and-feel emulation isn't particularly good, it mostly works | 
| 21:57:43 | Jehan_ | flaviu: There are still platform differences that make write-once-run-anywhere hard. You can't just conjure away central differences in how the OS works. | 
| 21:58:43 | Matthias247 | yes. But writing cross-plattform C++ code is therefore in most cases even harder :) | 
| 22:01:34 | Jehan_ | Matthias247: No doubt. I only ever used it when I needed fairly low-level stuff. | 
| 22:02:05 | Jehan_ | The problem is that sometimes I have to deploy code on machines without a JDK. | 
| 22:02:38 | reactormonk | Jehan_, entertaining | 
| 22:02:43 | Jehan_ | Pretty barebones Linux installations. | 
| 22:02:52 | reactormonk | How many? | 
| 22:03:04 | Jehan_ | Or with a really outdated Java version. | 
| 22:03:43 | Matthias247 | be happy when you don't have to deploy on windows ce ;) | 
| 22:04:25 | Jehan_ | Matthias247: I am grateful. | 
| 22:04:41 | Jehan_ | But you'd be surprised how much behind times some HPC installations are. | 
| 22:08:20 | Varriount | Example of how hard it is to write cross platform abstractions: File Event Monitoring | 
| 22:08:22 | Jehan_ | Nimrod has actually been pretty useful in this regard, too. | 
| 22:08:49 | Jehan_ | Because the basic stuff makes very few platform-specific assumptions. | 
| 22:09:14 | flaviu | Varriount: Aren't most your issues there with GC interactions? | 
| 22:09:25 | Jehan_ | Other than my day job (and as a target for code generation), I hope to be C++-free within the year. | 
| 22:09:38 | * | pafmaf quit (Quit: Verlassend) | 
| 22:11:32 | Varriount | flaviu: And OS abstractions. The file event monitoring interface across OS's is... different. | 
| 22:12:22 | flaviu | Varriount: Do you have a couple links? | 
| 22:12:40 | Varriount | http://msdn.microsoft.com/en-us/library/windows/desktop/aa365465(v=vs.85).aspx | 
| 22:12:48 | flaviu | Thanks | 
| 22:12:50 | Varriount | http://man7.org/linux/man-pages/man7/inotify.7.html | 
| 22:13:04 | Varriount | http://www.freebsd.org/cgi/man.cgi?query=kqueue&sektion=2 | 
| 22:13:59 | Varriount | flaviu: Yes, I'm dealing with only Windows, but I have to modify the behavior such that it is consistant with other platforms. | 
| 22:15:18 | flaviu | The windows method definition makes my eyes bleed | 
| 22:15:31 | Varriount | flaviu: Oh good, I'm not the only one. | 
| 22:16:36 | Varriount | Speaking of GC issues, a really useful tool for nimrod would be some sort of runtime analyzer which draws a network chart of all the references an object holds | 
| 22:17:26 | Matthias247 | the winapi is complex as hell. But still more efficient than linux things ;) | 
| 22:18:04 | flaviu | Matthias247: Maybe so, but I'd prefer a simple, less efficient API than a complex, super efficient API | 
| 22:18:07 | Varriount | Matthias247: I couldn't judge without some sort of comparison. | 
| 22:18:16 | flaviu | Especially when dealing with slow things like IO | 
| 22:18:45 | Varriount | My IT supervisor always complains about how slow things hosted on Windows are, but that may be the fault of server implementations. | 
| 22:19:00 | Matthias247 | IO can be the bottleneck for some kinds of applications | 
| 22:19:02 | flaviu | Varriount: Did you make sure power saving mode is off? | 
| 22:19:11 | Varriount | flaviu: What? | 
| 22:19:23 | flaviu | http://serverfault.com/questions/94212/does-cpu-power-management-affect-server-performance | 
| 22:19:41 | Varriount | I have no idea. I've only been an intern for about 4 weeks. | 
| 22:19:51 | Varriount | I'll ask him about it though. | 
| 22:23:41 | * | johnsoft quit (Ping timeout: 240 seconds) | 
| 22:24:35 | * | johnsoft joined #nimrod | 
| 22:28:53 | OrionPK | hola | 
| 22:33:17 | flaviu | Varriount: That actually might not be that hard | 
| 22:34:02 | flaviu | http://huffman.ooz.ie/tree.dot?text=TO%20BE%20OR%20NOT%20TO%20BE -> http://upload.wikimedia.org/wikipedia/commons/thumb/c/c6/Huffman_%28To_be_or_not_to_be%29.svg/406px-Huffman_%28To_be_or_not_to_be%29.svg.png | 
| 22:34:21 | flaviu | I don't have time to implement it though | 
| 22:36:35 | Varriount | flaviu: I'm thinking that it would be nice to be able to do that for arbitrary structures, so that one could easily find cyclic dependancies | 
| 22:37:30 | * | Jehan_ quit (Quit: Leaving) | 
| 22:48:03 | * | TylerE quit (Ping timeout: 240 seconds) | 
| 22:51:10 | * | TylerE joined #nimrod | 
| 23:04:28 | Araq | dom96: the bat file generation should be easily fixable via the encodings module, right? | 
| 23:06:23 | dom96 | no idea | 
| 23:06:37 | Araq | well now you know | 
| 23:06:49 | Araq | it should be | 
| 23:07:52 | dom96 | why not just tell me instead of asking me? | 
| 23:08:22 | Araq | well I have no idea how you do the bat file generation | 
| 23:09:21 | dom96 | Isn't it obvious? | 
| 23:09:46 | Araq | didn't look at the code | 
| 23:10:09 | * | Matthias247 quit (Read error: Connection reset by peer) | 
| 23:10:33 | * | joelmo quit (Ping timeout: 240 seconds) | 
| 23:11:37 | dom96 | Araq: You don't need to look at the code to guess. | 
| 23:12:16 | Araq | well I guessed and asked you but all I got was "no idea" :P | 
| 23:13:49 | * | joelmo joined #nimrod | 
| 23:14:18 | * | superfunc joined #nimrod | 
| 23:15:46 | dom96 | In any case, it seems to me that the solution is to change the code page. | 
| 23:16:41 | * | hoverbear quit (Ping timeout: 240 seconds) | 
| 23:16:48 | * | hoverbea_ joined #nimrod | 
| 23:19:02 | Araq | but to what? | 
| 23:19:46 | Araq | I think the better solution is to convert the utf-8 to OEM or whatever it's called before writing the bat file | 
| 23:19:56 | * | sdw left #nimrod (#nimrod) | 
| 23:22:51 | flaviu | Varriount: ReadDirectoryChangesW is horrible. It looks like the easiest way to use it correctly is to spin off a new thread for each directory | 
| 23:23:28 | dom96 | Araq: It may be better, but it's more complex. | 
| 23:23:33 | flaviu | http://qualapps.blogspot.com/2010/05/understanding-readdirectorychangesw_19.html | 
| 23:24:38 | Araq | dom96: no, it's 1-3 lines of code thanks to encodings.nim | 
| 23:25:56 | dom96 | there is like 100 different OEM encodings I think | 
| 23:26:23 | * | darkf joined #nimrod | 
| 23:27:36 | Araq | "You have to save the batch file with OEM encoding. How to do this varies depending on your text editor. The encoding used in that case varies as well" | 
| 23:27:46 | Araq | ah you're right, I misread the SO answer | 
| 23:27:53 | Araq | too bad | 
| 23:28:11 | dom96 | code page 65001 is UTF-8 btw | 
| 23:28:47 | * | hoverbea_ quit () | 
| 23:28:49 | dom96 | But who knows if that works on every version of Windows... | 
| 23:31:45 | dom96 | better yet, babel should just change the code page for the user instead. | 
| 23:33:39 | Araq | http://msdn.microsoft.com/en-us/library/windows/desktop/dd319072%28v=vs.85%29.aspx | 
| 23:33:57 | Araq | CP_OEMCP      The current system OEM code page. | 
| 23:36:05 | dom96 | http://superuser.com/questions/269818/change-default-code-page-of-windows-console-to-utf-8 | 
| 23:37:33 | Varriount | I had to do that in order to get Unicode output from skyrlar's unicode module to display correctly. | 
| 23:38:02 | Araq | dom96: I think this switches codepages permanently | 
| 23:38:20 | dom96 | Araq: Yes. | 
| 23:38:44 | dom96 | There is no reason for the user not do that | 
| 23:39:13 | Araq | hmm makes sense | 
| 23:39:21 | Varriount | Unless they use programs which use other code pages... | 
| 23:39:40 | Varriount | Or rather, programs which have worked around the default code page using other means. | 
| 23:39:42 | Araq | well my idea requires 1 line of code to add to encodings.nim and then it'll work | 
| 23:39:57 | dom96 | Araq: implement it then | 
| 23:40:48 | Araq | already did | 
| 23:42:25 | Araq | use it like so: | 
| 23:43:23 | Araq | convert(batContents, destEncoding = "OEMCP", srcEncoding = "UTF-8") | 
| 23:44:36 | dom96 | implement it in babel :P | 
| 23:45:19 | Varriount | What exactly does that do? | 
| 23:48:18 | Araq | it ends up calling MultiByteToWideChar with CP_OEMCP | 
| 23:48:48 | Varriount | Ah. |