| 00:00:35 | Araq | reactormonk: the information is in the generated type info |
| 00:01:03 | Araq | I need to fix it in the codegen; should be quick |
| 00:02:40 | Araq | oh but it'll lose your space I think :P |
| 00:02:50 | Araq | however you should do: |
| 00:03:16 | Araq | enumField = "its string repr", enumFieldB = "B's string repr" |
| 00:03:35 | Araq | then it should work |
| 00:05:05 | reactormonk | tiling.nim(5, 3) Error: 'Top' cannot be assigned to |
| 00:05:35 | Araq | type TMyEnum = enum |
| 00:05:43 | Araq | enumField = "its string repr" enumFieldB = "B's string repr" |
| 00:05:56 | Araq | obviously :P |
| 00:07:53 | reactormonk | ... |
| 00:08:31 | reactormonk | How can I access the string for here then? |
| 00:08:44 | Araq | with the builtin $ operator ;-) |
| 00:08:47 | reactormonk | $ triggers the same error |
| 00:08:52 | Araq | I know, working on it |
| 00:10:11 | Araq | reactormonk: how to convert a number into a string in JS btw? |
| 00:12:25 | reactormonk | eehm |
| 00:12:40 | reactormonk | "" + 2 |
| 00:12:42 | reactormonk | '2' |
| 00:13:19 | Araq | that's how I would have implemented it :-) |
| 00:13:19 | reactormonk | or (2).toString() |
| 00:13:27 | Araq | ugh |
| 00:13:36 | reactormonk | 2.toString seems to parse it as a float and fail |
| 00:13:53 | reactormonk | at least node |
| 00:13:54 | Araq | "" + 2 may be better for the JIT |
| 00:14:19 | reactormonk | "" + a maybe not |
| 00:16:07 | Araq | but it should |
| 00:39:10 | NimBot | Araq/Nimrod 42d671f Araq [+0 ±1 -0]: implemented $/repr for enums for the JS target |
| 00:39:11 | * | q66 quit (Quit: Quit) |
| 00:39:30 | Araq | reactormonk: implemented now |
| 00:39:44 | reactormonk | booting... |
| 00:40:49 | reactormonk | item_26134 = (var defaultbindings_26096 = NimCopy([{Field0: 0, Field1: cstrToNimstr("M-9")}, {Field0: 1, Field1: cstrToNimstr("M-8")}, {Field0: 2, Field1: cstrToNimstr("M-0")}, {Field0: 3, Field1: cstrToNimstr("M-i")}, {Field0: 4, Field1: cstrToNimstr("M-p")}, {Field0: 7, Field1: cstrToNimstr("M-,")}, {Field0: 5, Field1: cstrToNimstr("M-m")}, {Field0: 6, Field1: cstrToNimstr("M-.")}], NTI26097); |
| 00:40:51 | reactormonk | , defaultbindings_26096)[i_26144]; |
| 00:40:53 | reactormonk | hmmm |
| 00:42:45 | Araq | that looks like wrong code :P |
| 00:45:16 | Araq | but now that you've seen my fixes you should know how the JS backend works |
| 00:45:25 | Araq | ;-) |
| 00:45:27 | Araq | and can fix it yourself |
| 00:50:40 | * | Anaphaxeton quit (Remote host closed the connection) |
| 00:56:41 | reactormonk | why wrong code? |
| 00:56:56 | Araq | is it correct? |
| 00:57:02 | Araq | looks wrong to me |
| 00:57:22 | reactormonk | well, item_X is used afterwards |
| 00:57:26 | reactormonk | so it's not that bad |
| 00:57:37 | reactormonk | err, wait. |
| 00:59:50 | reactormonk | while (false); |
| 00:59:53 | reactormonk | whut? |
| 01:02:11 | Araq | well I have to sleep now |
| 01:02:14 | Araq | good night |
| 01:02:27 | reactormonk | good night and thanks for the help |
| 01:02:58 | reactormonk | http://sprunge.us/NVJI |
| 01:03:05 | reactormonk | jslint does not like generated JS ^^ |
| 01:05:31 | NimBot | nimrod-code/Aporia 09274b7 Dominik Picheta [+0 ±2 -0]: Added "Go to definition" to the Edit menu. |
| 01:05:58 | reactormonk | dom96, not really edit imo |
| 01:06:16 | reactormonk | dom96, edit is something that changes a file. Put it somewhere else. |
| 01:06:28 | dom96 | where should I put it? |
| 01:07:37 | dom96 | I guess I'll make a separate section called "Find" or something |
| 01:07:52 | dom96 | But it's late, so I don't feel like it :P |
| 01:08:06 | reactormonk | dom96, make a github issue then |
| 01:09:16 | dom96 | I'll add it to my todo file :) |
| 01:10:16 | dom96 | reactormonk: Are you using Aporia yet? |
| 01:14:29 | * | Anaphaxeton joined #nimrod |
| 01:16:06 | reactormonk | dom96, I'm stuck with vim keybindings. |
| 01:17:00 | dom96 | Make an issue, I might be able to help out with that. |
| 01:20:03 | dom96 | But let me know what keys you use and such. |
| 01:21:07 | dom96 | Full vim support would be a bit too much, from what I recall with my adventures with vim. |
| 01:34:38 | dom96 | good night |
| 01:37:49 | reactormonk | dom96, that's likely. |
| 01:38:01 | reactormonk | dom96, well, hell a lot. |
| 02:02:41 | Anaphaxeton | nighters |
| 02:39:15 | * | XAMPP-8 joined #nimrod |
| 02:55:48 | reactormonk | ... works halfway. |
| 04:12:42 | * | SchalaZeal joined #nimrod |
| 04:13:23 | SchalaZeal | I'm rather curious as to how importobjc pragma works. |
| 04:13:54 | SchalaZeal | I'm looking at the "horrible example" and I don't know where "Greater new" came from |
| 04:22:35 | SchalaZeal | oh wait |
| 04:22:41 | SchalaZeal | Wikipedia...heh |
| 04:52:11 | * | SchalaZeal quit (Quit: Konversation terminated!) |
| 05:44:00 | * | XAMPP joined #nimrod |
| 07:34:53 | Anaphaxeton | good morning |
| 07:42:40 | * | shevy joined #nimrod |
| 09:57:39 | * | XAMPP-8 quit (Read error: Connection reset by peer) |
| 10:10:44 | * | XAMPP-8 joined #nimrod |
| 11:17:40 | * | q66 joined #nimrod |
| 11:35:31 | dom96 | 'morning |
| 11:41:13 | shevy | sex |
| 11:41:16 | shevy | oops wrong channel!!! |
| 11:43:31 | dom96 | lol |
| 11:54:11 | Anaphaxeton | haha |
| 11:58:35 | shevy | you know what would be nice? |
| 11:58:49 | shevy | if you could mix in different scripting languages, and they'd all have very good, strong points each |
| 11:58:58 | shevy | so that you could actually use them for their strengths |
| 11:59:11 | shevy | when I look at php, the strengths it has are rather few |
| 11:59:31 | shevy | the only ones I could think of, is actually software like phpBB or mediawiki |
| 12:22:06 | q66 | but both phpBB and mediawiki are pretty bad |
| 12:56:38 | dom96 | Yet PHP somehow manages to be used by all these big websites like Facebook. |
| 13:10:43 | Anaphaxeton | marketing works |
| 13:11:07 | Anaphaxeton | they promoted php a lot back then |
| 13:50:20 | shevy | q66 I think both phpBB and mediawiki are quite good, compared to many other things out there. you also always need to look at what a competition can offer |
| 13:50:33 | shevy | in ruby, without ruby-on-rails there would be barely any real competition at all to these :( |
| 13:50:54 | q66 | shevy, both phpBB and mediawiki are prone to spam attacks |
| 13:51:11 | q66 | more so than the other apps |
| 13:52:52 | shevy | well that is understandable, if software is used a lot, more people will try to break it |
| 13:53:44 | q66 | shevy, but PHP just encourages bad security and attacks |
| 13:54:11 | shevy | php is a fairly awful language, yeah |
| 16:23:01 | * | FreeArtMan joined #nimrod |
| 16:55:03 | * | gradha joined #nimrod |
| 17:27:58 | * | gradha quit (Quit: Leaving) |
| 18:04:23 | * | XAMPP-8 quit (Ping timeout: 246 seconds) |
| 18:15:35 | NimBot | Araq/Nimrod 3b1ca1e Araq [+0 ±5 -0]: bugfix: typeinfo.extendSeq |
| 18:31:54 | * | codeallergy joined #nimrod |
| 18:32:13 | Araq | ping reactormonk |
| 18:39:44 | * | gradha joined #nimrod |
| 18:47:24 | Araq | hi gradha |
| 18:48:16 | gradha | hi Araq |
| 18:48:54 | Araq | my brain is dizzy so: given too ranges A..B and C..D how do I check for any overlaps? |
| 18:49:52 | gradha | You could try testing for exclusion |
| 18:50:02 | gradha | if D < A and C > B then they don't overlap |
| 18:50:18 | gradha | actually, that would be an or |
| 18:51:20 | Araq | but that's not sufficient, is it? |
| 18:51:47 | gradha | no, you would need to test the same for the reverse range, meaning A..B doesn't overlap C..D |
| 18:52:16 | Araq | not overlapping iff A notin C..D and B notin C..D ? |
| 18:52:24 | Araq | doesn't work, right? |
| 18:54:11 | gradha | if it makes more sense you can always check for the inclusion of C or D inside A..B plus the check of C < A and D > B |
| 18:54:44 | gradha | sounds like something which should have been debated to death on the internets, let's check |
| 18:55:20 | gradha | http://stackoverflow.com/questions/3269434/whats-the-most-efficient-way-to-test-two-integer-ranges-for-overlap |
| 18:55:40 | gradha | again, this considers ranges are integers |
| 18:55:47 | gradha | ranges are more fun with floats and epsilons |
| 18:56:54 | NimBot | nimrod-code/Aporia 9be6af5 Amrykid [+0 ±5 -0]: Windows improvements. |
| 18:56:54 | NimBot | nimrod-code/Aporia 2dedd77 Dominik Picheta [+0 ±3 -0]: 'piekno' is now the default color scheme. |
| 18:56:54 | NimBot | nimrod-code/Aporia 3c25dc5 Dominik Picheta [+0 ±5 -0]: Merge branch 'master' of git://github.com/Amrykid/Aporia into Amrykid-master |
| 18:56:54 | NimBot | nimrod-code/Aporia 0031640 Dominik Picheta [+0 ±5 -0]: Refactored GetCmd. Renamed getNimrodPath to promptNimrodPath. |
| 18:57:14 | * | shevy quit (Ping timeout: 246 seconds) |
| 19:00:11 | Araq | well the top answer should work with floats too |
| 19:02:42 | gradha | I believe the formula I have been using so far is C > B AND D < A AND A > D AND B < C -> no overlap |
| 19:02:42 | gradha | never bothered to check if it worked, seemed legit |
| 19:03:22 | gradha | hmm... but it might not have been ranges what I were testing... huh, what a help |
| 19:08:35 | gradha | oh, just realized why the stackoverflow answer wasn't making sense to me: I'm used to expressing ranges in form x1,y1 vs x2,y2, not x1,x2 vs y1,y2 |
| 19:08:55 | Araq | bbl |
| 19:10:03 | * | shevy joined #nimrod |
| 20:26:37 | reactormonk | Araq, pong |
| 20:27:27 | Araq | reactormonk: do you feel like testing exception handling for the JS backend? |
| 20:27:38 | reactormonk | Araq, didn't need any so far |
| 20:28:22 | reactormonk | Araq, sure, but not today |
| 20:28:31 | Araq | ok |
| 20:28:48 | Araq | what about the wrong produced JS code? or did that work? |
| 20:29:21 | Araq | what about closures for the JS backend? what's the problem with them? |
| 20:31:17 | reactormonk | Araq, nope, but that may not be my fault, gotta debug it |
| 20:31:36 | Araq | alright |
| 20:42:10 | * | FreeArtMan quit (Read error: Operation timed out) |
| 21:58:31 | NimBot | Araq/Nimrod fce5975 Araq [+1 ±3 -0]: bugfix: overlap checking for 'case' |
| 22:11:50 | gradha | Araq: you mentioned that "for" inlines iterators |
| 22:12:04 | gradha | is this inlining different from a proc marked as inline? |
| 22:12:49 | Araq | yes |
| 22:13:07 | Araq | for a start the nimrod compiler does it, 'inline' for procs is left to C's optimizer |
| 22:13:38 | Araq | but the real difference is that inlining an iterator means that 'yield' is replaced by the for loop body |
| 22:13:56 | Araq | this has consequences for code size |
| 22:13:58 | gradha | oh, nasty |
| 22:14:16 | Araq | the stdlib's iterators only use 1 'yield' for a reason ;-) |
| 22:15:06 | Araq | but closure iterators don't have this problem |
| 22:15:53 | gradha | coming back to the discussion on "type future compatibility", why do procs by default use the closure calling convention if you need to mark them as {.procvar.} to actually use them as closures? wouldn't nimcall be better as the default calling convetion? |
| 22:16:44 | Araq | your question doesn't make sense because the claims in it are wrong :P |
| 22:16:56 | gradha | that's what I was supposing |
| 22:17:26 | gradha | I think you said nasty people do "var x = procBlah" and that can break in the future |
| 22:17:45 | Araq | proc *types* default to 'closure' so that it's not overly verbose in sort's signature etc. |
| 22:18:15 | Araq | *procs* default to nimcall but that is compatible to 'closure' |
| 22:18:49 | Araq | an explicit calling convention implies 'procvar' (though that's wrong for .inline.) |
| 22:19:31 | gradha | how can nimcall procs be compatible with closure if they lack the additional hidden environment parameter? does the compiler not need this hidden parameter? |
| 22:20:13 | gradha | I think my problem is I don't understand the manual with nimcall and closure both being defaults |
| 22:20:39 | gradha | if I write a proc without pragmas, is it nimcall or closure? not that I care, just trying to understand the manual |
| 22:20:57 | Araq | a proc without pragmas is nimcall |
| 22:21:08 | Araq | a proc *type* without pragmas is closure |
| 22:21:22 | Araq | type ProcTypeHere = proc (a, b: int) # closure |
| 22:21:57 | Araq | proc realProcHere(a, b: int) # nimcall |
| 22:22:29 | gradha | oh, so whenever you write a proc accepting a proc it is always of closure type |
| 22:22:40 | gradha | the parameter |
| 22:22:51 | Araq | yes |
| 22:22:52 | gradha | and the proc itself is a nimcall |
| 22:22:59 | Araq | yes |
| 22:23:14 | gradha | everything clear now, thanks |
| 22:29:06 | Araq | dom96: what about the osproc/tester bugfix? |
| 22:31:58 | dom96 | oh yeah. I'll get right on that. Need to take a shower first though. |
| 22:37:54 | Araq | gradha: what about the 'procvar'? do you still think it's a bad idea? |
| 22:38:35 | Araq | I'd argue it's even more tolerable once we got the shorter lambda syntax with better type inference |
| 22:38:36 | gradha | I'll tell you if I ever hit the issue, most of the time I talk about corner cases simply because it is fun |
| 22:39:09 | Araq | wrapping the library proc in a lambda is future proof |
| 22:39:33 | Araq | and it's exactly what the compiler would have to do for system.`+` |
| 22:39:54 | Araq | so I think it's a pretty good idea and fits the language perfectly fine |
| 22:40:32 | gradha | IIRC I didn't pursue the conversation further because I still don't understand why adding a default parameter to a proc used as the type for a var would break compilation |
| 22:40:57 | gradha | well, I sort of undestand it, or maybe not |
| 22:41:10 | gradha | today it's unsure day for me |
| 22:41:14 | Araq | but extra parameters are not binary compatible |
| 22:41:39 | Araq | for closures it works because the compiler inserts some magic for you |
| 22:41:53 | Araq | but it only works because it's a single additional parameter |
| 22:42:07 | gradha | can't you add magic to the compiler to add the default parameter then? |
| 22:42:37 | Araq | well the compiler could rewrite a default param to an overloaded proc |
| 22:42:52 | Araq | but that's a code explosion waiting to happen |
| 22:43:37 | gradha | would this problem go away if you couldn't have binary nimrod code and always had to parse again everything? |
| 22:43:37 | Araq | proc p(a = 0, b = "", c = false) |
| 22:43:57 | gradha | I mean the object files in nimcache and incremental compilation |
| 22:44:12 | Araq | that has nothing to do with it |
| 22:44:58 | Araq | it can go away with a custom calling convention like Haskell uses afaik |
| 22:45:22 | Araq | but a new custom calling convention is hard to do when targetting C |
| 22:45:35 | Araq | nor is the problem worth the effort |
| 22:45:39 | gradha | ok, don't mind me then, I still don't understand enough to discuss this seriously |
| 22:49:26 | Araq | er .. forget this |
| 22:49:37 | Araq | haskell doesn't support that either anyway |
| 22:49:58 | Araq | in fact, it's not currying |
| 22:50:10 | NimBot | Araq/Nimrod c87973d Zahary Karadjov [+0 ±18 -0]: caas is now drivable through stdin... 4 more lines |
| 22:50:10 | NimBot | Araq/Nimrod c8312eb Zahary Karadjov [+0 ±23 -0]: CaaS in-memory caching... 4 more lines |
| 22:50:10 | NimBot | Araq/Nimrod 4721506 Zahary Karadjov [+0 ±9 -0]: [caas] first version that actually works (still has a lot of logical memory leaks on recompilation) |
| 22:50:11 | NimBot | Araq/Nimrod c77df1f Zahary Karadjov [+0 ±7 -0]: store the instantiation cache in the generic symbol |
| 22:50:11 | NimBot | Araq/Nimrod b2481c4 Zahary Karadjov [+0 ±3 -0]: experimental compile-time rope formatting code |
| 22:50:12 | gradha | you'll find a better ROI poking dom96 to do stuff rather than discussing with me |
| 22:50:39 | gradha | huh? the mythical caas branch ready? is it christmas? |
| 22:51:01 | Araq | hi zahary |
| 22:51:13 | zahary | hi everybody, sorry for not being around in the last week |
| 22:51:50 | zahary | I'm changing jobs and this is keeping me too busy |
| 22:52:19 | Araq | er ... congratulations then? |
| 22:52:43 | zahary | :) sure |
| 22:52:51 | gradha | excellent |
| 22:55:22 | Araq | what about the GC? |
| 22:55:53 | Araq | you have both fixes for the old one and working on a new one, right? |
| 22:56:21 | zahary | the old one is not really fixable |
| 22:56:31 | zahary | it performs pruning in a wrong way |
| 22:56:31 | Araq | of course it is |
| 22:56:44 | Araq | well alright |
| 22:56:48 | Araq | let me fix it then |
| 22:57:08 | Araq | and you should give your GC a name and add it to the --gc option |
| 22:57:21 | zahary | let me just explain what I mean |
| 22:57:31 | Araq | ok |
| 22:59:28 | zahary | the real reason why the old GC is so fast is this line: |
| 22:59:28 | zahary | https://github.com/Araq/Nimrod/blob/master/lib/system/oldgc.nim#L607 |
| 22:59:29 | zahary | in the mark phase it only considers objects that are current cycle candidates |
| 23:00:06 | zahary | this is a very small number of objects most of the time (given the fact that cycleRoots is cleared between collections) |
| 23:01:15 | zahary | to implement a proper fix, you can either remove this pruning method or if you keep the original python approach, cycleRoots should not be emptied, but rather it should contain all alive cyclic objects |
| 23:01:41 | zahary | now, this is a much much larger set of objects that will bring the old GC to a crawl |
| 23:01:48 | gradha | does a substr proc exist for sequences where it returns a range of a sequence? |
| 23:02:11 | Araq | gradha: there is s[1..3] for sequences, but no substr |
| 23:02:26 | gradha | oh, slices work on sequences? cool |
| 23:04:19 | Araq | zahary, you said the difference was 0.3s for bootstrapping iirc |
| 23:04:37 | Araq | that's not "bring it to a crawl", is it? |
| 23:05:34 | dom96 | yay, it is christmas! |
| 23:06:09 | zahary | what I mean is that the old GC cannot be fixed in a useful way - sure, you can spent some time plugging the leaks, but you won't get better performance |
| 23:06:43 | zahary | the constant factor of the old GC is higher, because it uses hash tables where the new GC uses arrays |
| 23:08:04 | zahary | I've currently left a way to switch the GC in mmdisp, and there are some useful print outs of various stats you can look at |
| 23:08:34 | Araq | I don't mind a crappy cycle collector |
| 23:08:43 | zahary | you can find a special revision in the logs where the print outs are enabled |
| 23:08:56 | Araq | I do mind a GC that wasn't written by me :P |
| 23:09:17 | zahary | well, the new one is not much different, try to read the code |
| 23:09:27 | Araq | well, a new GC isn't something that's introduced without a fallback to the old one |
| 23:10:22 | Araq | btw you broke 6 tests |
| 23:14:45 | zahary | I know, I'll try to fix them in the next few days |
| 23:15:12 | zahary | I started with 20 broken tests after the merge |
| 23:16:20 | Araq | alright |
| 23:16:33 | Araq | what's broken? |
| 23:19:06 | dom96 | zahary: docs for caas would also be nice. |
| 23:19:07 | zahary | I've changed the way IDs are assigned to files and modules and I need to make a small change in how symbol files use them |
| 23:19:07 | zahary | one of the tests that fails locally looks bad tho - it appears and disappears with unrelated code changes - could be something about the new GC |
| 23:21:59 | zahary | dom96, I'll try to integrate it in my vim plugin and it could serve you as a reference implementation |
| 23:23:58 | gradha | Araq: found this as semi-broken https://github.com/Araq/Nimrod/issues/321 |
| 23:23:58 | dom96 | Alright. |
| 23:24:19 | zahary | Araq, another thing - currently, it's easy to switch GCs, but I plan to generate a bit more optimised marker procs that will be compatible only with the new one |
| 23:25:14 | Araq | gradha: negative indexes are supposed to work for seqs |
| 23:25:47 | gradha | cool |
| 23:26:26 | gradha | wait, but do they reverse the sequence if necessary, or would they only work as long as the second index is bigger than the first? |
| 23:27:11 | gradha | ah, ok, so they don't reverse, [-3..3] works, since -3 is lesser than 3 in this case |
| 23:27:45 | gradha | the negative seems to be a problem for the second index |
| 23:27:59 | Araq | you need to split up '..-' into '.. -' |
| 23:28:11 | Araq | due to the operator lexing rules |
| 23:28:41 | gradha | ok, so negative indexes work, no plan for reversing the sequence on the fly? |
| 23:29:35 | gradha | hmm... not sure if I want this feature myself |
| 23:30:06 | gradha | just asking, since asking is free |
| 23:32:48 | Araq | no reverse on the fly |
| 23:35:41 | gradha | btw, the repr(t) which crashes was found when I was trying to use the t as an index into a TTable, in this situation it doesn't crash but the types don't match |
| 23:36:09 | gradha | I usually log with repr to see if the type I'm getting is the one I am expecting |
| 23:43:53 | gradha | does something use the ropes module? I see no examples, and have trouble finding a use case for them |
| 23:44:34 | Araq | there are no good use cases for them because they're slow |
| 23:44:52 | Araq | in theory they are great though, O(1) string concat |
| 23:45:18 | Araq | so if you build a huge output file from lots of small pieces it can be the tool of your choice |
| 23:46:00 | gradha | does the reverse exist? something which given a huge string creates substrings by using pointers into the bigger one? I would find that useful for parsing |
| 23:46:55 | Araq | there are helpers in parseutils which take (s: string, startIndex: int) |
| 23:47:18 | Araq | and there are ways to implement efficient slices in Nimrod, but the stdlib doesn't |
| 23:47:48 | Araq | I use integer indexes for parsing instead |
| 23:48:47 | gradha | you convert the indices into string objects with the substr proc or something internal more efficient? |
| 23:49:01 | gradha | or maybe you don't convert ever to string? |
| 23:50:34 | Araq | often I have a buffer that is 4-8K and so can't keep the entire input anyway and I produce a single string containing the parsed token |
| 23:51:06 | Araq | try that with slices :P |
| 23:51:28 | Araq | it requires you to keep your whole input in memory then |
| 23:52:24 | gradha | yes, I was thinking of input which always fits in memory |
| 23:52:39 | Araq | but with mmap() and virtual memory it could be the better option, yeah |
| 23:59:42 | NimBot | Araq/Nimrod 22a93a0 Dominik Picheta [+0 ±1 -0]: Fixes #317 |