| 00:07:52 | * | XAMPP-8 joined #nimrod |
| 00:14:30 | * | Araq quit (*.net *.split) |
| 00:38:33 | * | ARCADIVS quit (Quit: WeeChat 0.3.8) |
| 00:57:25 | * | OnionPK joined #nimrod |
| 01:02:13 | * | Araq joined #nimrod |
| 01:03:54 | * | OrionPK quit (Read error: Connection reset by peer) |
| 01:04:15 | * | comex` quit (Ping timeout: 245 seconds) |
| 01:05:55 | * | comex joined #nimrod |
| 01:06:02 | * | Boscop joined #nimrod |
| 01:11:22 | * | XAMPP-8 quit (Quit: Leaving) |
| 01:56:50 | * | fowl quit (Ping timeout: 240 seconds) |
| 02:09:32 | * | fowl joined #nimrod |
| 02:09:55 | * | q66 quit (Remote host closed the connection) |
| 04:29:29 | * | OnionPK quit (Quit: Leaving) |
| 05:04:29 | * | fowl quit (Ping timeout: 256 seconds) |
| 06:36:52 | * | fowl joined #nimrod |
| 07:44:20 | * | fowl quit (Quit: Leaving) |
| 08:21:35 | * | zahary joined #nimrod |
| 09:17:40 | Araq | muhaha your hacks now hunt you, zahary |
| 09:18:07 | Araq | see #429 #430 |
| 09:27:39 | * | zahary quit (Quit: Leaving.) |
| 10:13:00 | * | zahary joined #nimrod |
| 10:13:37 | zahary | I've already assigned them to me :) |
| 10:37:30 | * | q66 joined #nimrod |
| 10:44:26 | * | silven joined #nimrod |
| 10:44:45 | * | silven quit (Remote host closed the connection) |
| 11:55:57 | * | zahary quit (Quit: Leaving.) |
| 12:12:33 | * | zahary joined #nimrod |
| 12:55:20 | * | Endy joined #nimrod |
| 13:15:59 | NimBot | Araq/Nimrod 93ecfbb Zahary Karadjov [+0 ±9 -0]: added a ``noforward`` pragma that enables a new compilation strategy... 2 more lines |
| 13:15:59 | NimBot | Araq/Nimrod 5c9b667 Zahary Karadjov [+0 ±11 -0]: switch to a linked list of scopes |
| 13:15:59 | NimBot | Araq/Nimrod d9be769 Zahary Karadjov [+0 ±11 -0]: get rid of the SymTab* procs in astalgo |
| 13:15:59 | NimBot | Araq/Nimrod 5482c43 Zahary Karadjov [+0 ±9 -0]: get rid of ImportTablePos and ModuleTablePos |
| 13:15:59 | NimBot | Araq/Nimrod 1032d15 Zahary Karadjov [+0 ±3 -0]: get rid of TOverloadIter.stackPtr |
| 13:33:26 | * | zahary quit (Quit: Leaving.) |
| 13:38:23 | * | zahary joined #nimrod |
| 14:08:17 | Araq | ugh, I'd have preferred a branch for the changed symbol table handling, zahary |
| 14:10:03 | zahary | I did a lot of tests and it has pretty much zero overhead |
| 14:10:33 | Araq | yeah but then I don't know which tests it breaks |
| 14:13:33 | zahary | is there still a way to see the test history of a single branch? e.g. like the old style nimbuild |
| 14:14:04 | Araq | I don't think so ... |
| 14:15:45 | zahary | it was useful, but anyway - I don't seem to have broken any tests as one of the testers still shows the previous report on the last dom96 commit |
| 14:16:08 | zahary | the changes appear complicated, but actually they were quite safe refactorings |
| 14:16:26 | Araq | it's 578 vs 580 |
| 14:17:13 | zahary | I'm looking at the linux-x86_64 log which stills displays the "before" results on master |
| 14:17:38 | Araq | tstmtexp and titer7 look suspicious |
| 14:25:11 | * | Trix[a]r_za is now known as Trixar_za |
| 14:26:15 | NimBot | Araq/Nimrod ddbe129 Zahary Karadjov [+0 ±1 -0]: fixing the dos line endings in a broken test |
| 14:26:34 | zahary | tstmtexp works on my machine, but it reports the error on a different line. maybe that was the problem. |
| 14:26:47 | zahary | it was using mixed line endings |
| 14:26:54 | Araq | ok |
| 14:30:42 | zahary | hmm, actually, it still reports the wrong line - I'll take a further look |
| 14:38:46 | Araq | btw my idea was to treat a section of procs/iterator/methods as 1 block like it's done for 'type' sections |
| 14:39:42 | Araq | so a top level 'when' would break the section and there would be no problem with references to undefined types etc. |
| 14:44:04 | zahary | how does this idea deal with top-level macros generating proc definitions? |
| 14:45:20 | Araq | that would likely be a separate section then too |
| 14:45:46 | zahary | so you get no forward declarations in a single "section" |
| 14:45:47 | zahary | ? |
| 14:45:59 | Araq | yeah |
| 14:47:19 | zahary | why do you prefer such a scheme given the limitations? |
| 14:54:04 | zahary | I agree it's not awfully limiting if you organise your code well, but I still prefer if we stay on a path that will make possible to use cyclic dependencies between modules in certain situations |
| 14:56:30 | zahary | and I still hope to realise very fast suggest times with the new scheme that doesn't need to compile the whole program |
| 15:01:21 | Araq | sempass2 heavily assumes the "backwards" declaration order as the effects for forwarded procs need to be annotated explicitly |
| 15:01:30 | Araq | no idea how it works with your scheme |
| 15:02:03 | Araq | also I fear that the scopes are now permanent and can't be GC'ed easily with your scheme |
| 15:05:07 | zahary | well, I was wondering how it will affect memory consumption too, but it didn't move the high watermark reported in the end of compilation at all |
| 15:06:17 | zahary | can you elaborate about the sempass2 problem |
| 15:06:23 | Araq | yeah but then I do hope it will make a difference one day ... once the ropes are gone for instance ;-) |
| 15:07:00 | Araq | sempass2 (better called semeffects now) problem: |
| 15:07:20 | Araq | p(...) # p forward declared? --> then we haven't computed its effects yet |
| 15:07:35 | zahary | ok, I see, I think I got it |
| 15:07:44 | Araq | and assume it has raises: EBase, tags: TEffect |
| 15:09:50 | zahary | generally in my scheme, the compilation of a proc body will only commence after all other definitions used in the body are visible (that's the idea - you can get the compiler to start compiling a piece of code earlier) |
| 15:09:51 | Araq | I'd have computed the effects of every proc section as a whole in my scheme |
| 15:10:57 | Araq | how do you know the "definitions used in the body"? |
| 15:11:37 | Araq | you treat a template call like a proc I guess? and then it's expanded and then what? |
| 15:11:48 | zahary | the scheme is recursive in nature - you start from the main proc and walk through the program line-by-line determining the types of invoked procs and compiling them as necessary |
| 15:12:24 | zahary | the templates will be expanded and the ast will be processed just as if it was a regular part of the proc body |
| 15:15:40 | * | Boscop quit (Disconnected by services) |
| 15:15:42 | * | Boscop joined #nimrod |
| 15:20:29 | * | zahary1 joined #nimrod |
| 15:21:05 | * | dom96_ joined #nimrod |
| 15:24:46 | * | zahary quit (*.net *.split) |
| 15:24:50 | * | dom96 quit (*.net *.split) |
| 15:28:30 | zahary1 | Araq, some clarifications here: https://gist.github.com/zah/5563908 |
| 15:29:07 | zahary1 | also, see my notes in the manual |
| 15:29:13 | * | JStoker quit (Excess Flood) |
| 15:29:25 | * | JStoker joined #nimrod |
| 15:30:10 | * | Amrykid_ joined #nimrod |
| 15:30:29 | * | Amrykid quit (Excess Flood) |
| 15:30:59 | Araq | zahary1: it's not that I'm against your scheme, I'll do some experiments myself later; I really would have preferred a separate branch for it though |
| 15:31:18 | Araq | for instance there are still 2 tests that fail with --symbolFiles |
| 15:31:51 | Araq | and I dislike releasing a new version that works worse than an older one |
| 15:32:04 | Araq | even if it's a feature apparently nobody uses |
| 15:33:22 | * | Amrykid_ is now known as Amrykid |
| 15:33:29 | * | Amrykid quit (Changing host) |
| 15:33:29 | * | Amrykid joined #nimrod |
| 15:34:02 | zahary1 | that's good points, but long-lived branches bring their own set of problems. I just try to apply common sense and hiding the feature behind a pragma sounds like a good compromise |
| 15:34:58 | zahary1 | and then we have more incentives to fix the bugs if they are in master :P |
| 15:35:53 | Araq | we refreshing to not get bug reports for the new parser/JS codegen/expr/stmt unification until it was ready :P |
| 15:36:07 | Araq | *was refreshing |
| 15:42:23 | * | OrionPK joined #nimrod |
| 15:48:06 | * | Trixar_za is now known as Trix[a]r_za |
| 15:55:20 | * | Trix[a]r_za is now known as Trixar_za |
| 15:59:31 | * | zahary1 quit (Quit: Leaving.) |
| 16:06:11 | * | zahary joined #nimrod |
| 16:08:20 | * | Trixar_za is now known as Trix[a]r_za |
| 16:21:06 | * | dom96_ is now known as dom96 |
| 16:21:06 | * | dom96 quit (Changing host) |
| 16:21:06 | * | dom96 joined #nimrod |
| 17:15:00 | Araq | ping zahary |
| 17:15:34 | zahary | pong Araq |
| 17:15:49 | Araq | in semTemplateDef you do: SymTabReplace(c.tab.stack[curScope], proto, s) |
| 17:16:17 | Araq | but what does that do? why not simply overwrite proto's AST? |
| 17:16:38 | Araq | parts of the AST already may refer to the old prototype |
| 17:16:47 | Araq | fixing that in the symbol table is not enough |
| 17:17:28 | zahary | I think the problem was that somebody was holding on to an indirect pointer to the AST through the previous symbol |
| 17:18:21 | zahary | and then at some later point (after the override), the incorrect new AST was used instead of the original one |
| 17:18:56 | zahary | the end result was some weird codegen errors |
| 17:19:03 | Araq | yeah well, what's the override we're discussing again? |
| 17:19:20 | zahary | the feature is that you are able to define a template multiple times in the same scope |
| 17:19:39 | zahary | this was motivated by some examples from the XL manual |
| 17:20:01 | zahary | the assert_failed: template is one of them |
| 17:22:28 | zahary | I meant system.onFailedAssert |
| 17:22:34 | Araq | ok so old references are supposed to point to the old definition |
| 17:22:44 | zahary | yep |
| 17:22:51 | Araq | alright then |
| 18:03:46 | NimBot | Araq/Nimrod 0e5ae2d Zahary Karadjov [+0 ±6 -0]: fixes #429 and tstmtexpr |
| 18:08:34 | * | fowl joined #nimrod |
| 18:16:02 | Araq | what about titer7 zahary ? |
| 18:17:45 | zahary | looks a bit tougher. the problem is that a closure variable is defined in the wrong scope in the C code |
| 18:18:50 | zahary | haven't spent much time on it yet tho |
| 18:19:25 | * | Endy quit (Ping timeout: 246 seconds) |
| 18:19:38 | Araq | we need a proper name mangling mechanism btw |
| 18:20:01 | Araq | the ID based stuff is too fragile, especially for link generation in the docgen |
| 18:20:14 | Araq | I thought about simply copying C++'s scheme |
| 18:20:41 | Araq | should be a good idea for better GDB support too |
| 18:22:34 | zahary | the name mangling changes usually affect performance quite a lot if you remember |
| 18:23:46 | Araq | true but I think we can optimize it by using proper strings and moving them into the rope |
| 18:24:37 | zahary | what is the idea about links in the docgen btw? |
| 18:25:12 | Araq | so that the link can be guessed and stays persistent |
| 18:25:20 | zahary | I want to support semantic highlighting in the IDE - e.g. the ability to paint in different colors global variables, constants, etc |
| 18:25:43 | zahary | and this requires some kind of "text to semantic data" inverse map in the compiler process |
| 18:25:55 | zahary | not "requires", but "suggests" |
| 18:26:08 | Araq | I can't follow |
| 18:26:16 | Araq | what would the "text" look like? |
| 18:27:45 | zahary | I meant that the IDE would need to ask "give me highlighting information for lines 25-50" and the compiler will answer very quickly with the token positions and the associated data |
| 18:56:27 | NimBot | Araq/Nimrod 89033f4 Zahary Karadjov [+1 ±1 -0]: fixes #430 |
| 19:11:04 | Araq | Build failed for: linux-x86_64 ("koch boot" failed. |
| 19:11:28 | dom96 | <dom96> ^^ Could be because x86_64 missed some commits |
| 19:13:24 | Araq | yay ... |
| 19:14:43 | reactormonk | anyone in for some code golf in nimrod? http://codegolf.stackexchange.com/ |
| 19:15:34 | dom96 | it's ok, i'll fix it |
| 19:25:06 | dom96 | well it seems the only way to fix it is to push new c sources |
| 19:31:33 | Araq | ok, please do so, zahary |
| 20:41:09 | * | zahary quit (Quit: Leaving.) |
| 20:42:47 | * | zahary joined #nimrod |
| 20:56:10 | * | gradha joined #nimrod |
| 21:01:06 | gradha | Araq: can't follow your discussion about name mangling, idetools returns the name of the symbol and the signature of the proc, can't that be used instead of a number? |
| 21:01:39 | gradha | example def skProc system.readFile proc (string): TaintedString |
| 21:02:01 | gradha | it's weird that you provide that information for an idetools query but somehow don't have it available during doc gen |
| 21:04:10 | gradha | the href for that could be readFile_string, unless you have to discard by return value too, or a proc and template can share name |
| 21:05:20 | gradha | to differentiate between a readFile accepting string and one proc named readFile_string without parameters an underscore could be added to indicate void parameters |
| 21:07:13 | gradha | maybe you could still conflict it with proc foo_string(string) and foo(string, string) |
| 21:09:52 | gradha | from http://www.htmlhelp.com/reference/html40/values.html it seems colons could be used for separating name from params, like foo_string:string, foo:string_string, or foo:_ |
| 21:12:05 | gradha | also lowercase everything since hrefs seem case sensitive |
| 21:22:42 | dom96 | i like that |
| 21:23:53 | gradha | wrt to browser testing I made the following which seems to work ok http://dl.dropbox.com/u/145894/t/index.html |
| 21:25:09 | gradha | in theory "Anchors may only contain characters in the range [A-Za-z0-9:_.]", so this is the browser just being nicer, but encoding in the form &#xxxx should be possible for pedantic browsers |
| 21:25:26 | dom96 | I think Nimrod could use a concise way to specify proc types, instead of having to write proc (name: type, anotherName: type2) etc. |
| 21:25:47 | dom96 | Then we could reuse it for the docgen |
| 21:25:57 | reactormonk | dom96, any idea how the syntax should look like? |
| 21:27:20 | dom96 | Maybe just allowing for the param name to be omitted would be enough. |
| 21:27:32 | dom96 | proc (type, type2) |
| 21:27:41 | Araq | and then? |
| 21:27:49 | Araq | how is that called with named parameters? |
| 21:28:13 | dom96 | it's not |
| 21:29:08 | Araq | bah |
| 21:29:31 | Araq | gradha: the name mangling seeks to make the proc header shorter and yet keep it unique |
| 21:29:46 | Araq | your way certainly works but generates longish anchor names |
| 21:29:48 | dom96 | if you want to call it with named params then specify them. |
| 21:30:05 | Araq | I don't get what this solves: |
| 21:30:16 | Araq | proc ugh(int, int) = ??? |
| 21:30:34 | dom96 | Araq: I said proc types. |
| 21:30:35 | Araq | and then what? how do I use these unnamed parameters in the body? |
| 21:30:39 | Araq | ah |
| 21:30:46 | Araq | yeah alright |
| 21:30:59 | reactormonk | maybe be able to use type proc(foo: int, bar: int) ? |
| 21:31:08 | reactormonk | ehh type baz = proc(foo: int, bar: int) |
| 21:31:28 | dom96 | I think that's already possible? |
| 21:31:50 | gradha | well, using integers as anchor names is the ultimate compression, but it's not human friendly nor stable when adding/removing procs, short of specifying symbol+param_types can't see anything better which is predictable by a human |
| 21:32:11 | dom96 | Araq: You could also take inspiration from haskell and allow: type -> type2 -> type3 :P |
| 21:32:56 | Araq | gradha: true but we could also sha32 the proc header :P |
| 21:33:11 | Araq | dom96: boring we discussed it multiple times |
| 21:33:22 | dom96 | Araq: Yeah, but not here I don't think :P |
| 21:33:34 | Araq | and type -> type -> type only makes sense when you support builtin currying anyway which we don't and can't |
| 21:35:07 | gradha | what I don't understand is why you can't have both: can't you use integers internally for speed and only for idetools/docgen produce the human friendly version? |
| 21:35:23 | Araq | sure, gradha |
| 21:36:33 | gradha | I misunderstood the earlier conversation then, thought both features were exclusive |
| 21:37:08 | Araq | well technically only doc2 has the proper headers available for link generation |
| 21:37:24 | Araq | but I think nobody uses 'doc' anymore anyway |
| 21:38:50 | gradha | if you are worried about URL length dom96 will implement an URL shortener |
| 21:39:29 | dom96 | totally, going to implement all the web apps I can think of in Nimrod. |
| 21:39:47 | gradha | so how are your exams going? |
| 21:40:08 | dom96 | Tomorrow is my first one :P |
| 21:40:36 | gradha | sounds like a good night to stay late coding |
| 21:40:53 | dom96 | heheh, don't tempt me :P |
| 21:44:03 | gradha | for HTML links you can generate more than one anchor, if you wish you could decorate with three versions: the number one, the symbol name alone, and symbol name + param types |
| 21:44:30 | gradha | for most cases the "just the symbol" will work fine |
| 21:44:43 | gradha | for overloading the full version would be used by people |
| 21:52:00 | dom96 | But then I will need to pay for more bandwidth :\ |
| 22:06:37 | * | zahary quit (Quit: Leaving.) |
| 22:10:58 | gradha | doesn't the server support gzip? |
| 22:11:24 | dom96 | true |
| 22:12:59 | gradha | every time a developer makes a json?protocol with "short" attributes baby gzip jesus weeps in a corner |
| 22:13:26 | * | fowl_ joined #nimrod |
| 22:25:24 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 22:30:03 | fowl_ | got an issue, here after all the components and messages are declared, numComponents and numMessages are still coming up as 0: https://gist.github.com/fowlmouth/5516425 |
| 22:36:42 | * | fowl_ quit (Quit: Leaving) |