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. |