| 00:03:53 | * | fowl quit (Ping timeout: 245 seconds) |
| 00:21:22 | * | q66 quit (Remote host closed the connection) |
| 04:37:21 | * | fowl joined #nimrod |
| 08:10:42 | * | XAMPP quit (Read error: Connection reset by peer) |
| 08:27:42 | * | Trix[a]r_za is now known as Trixar_za |
| 09:01:54 | * | reactormonk quit (Ping timeout: 272 seconds) |
| 09:14:16 | * | reactormonk joined #nimrod |
| 09:47:48 | * | zahary joined #nimrod |
| 10:01:07 | * | Trixar_za is now known as Trix[a]r_za |
| 10:15:45 | * | Trix[a]r_za is now known as Trixar_za |
| 10:27:55 | * | Trixar_za is now known as Trix[a]r_za |
| 12:47:07 | Araq | ping Z |
| 12:47:10 | Araq | ping zahary |
| 12:48:50 | zahary | hi Araq |
| 12:50:02 | Araq | I'm working on the lazy semchecking of operands but your changes with nkDo make me puzzled |
| 12:50:58 | zahary | let me take a look to remind myself of the code |
| 12:51:03 | zahary | where was it? |
| 12:51:09 | Araq | well I've implemented lazy semchecking and it works |
| 12:51:23 | Araq | but I wonder if sigmatch:710 is still necessary |
| 12:55:27 | zahary | I'm looking at the nkDo commit. My first note about fixImmediateParams was about a problem with templates when you pass an invalid code block that was sem checked like a closure and produced errors |
| 12:56:49 | Araq | yeah but that's due to your nkDo/nkStmtList merge |
| 12:57:03 | zahary | the change in sigmatch seems to be related to this. it just detects the effect of fixImmediateParams |
| 12:58:03 | zahary | so basically, if the closure body is sem-checked lazily now only when used as a real closure and not as a template argument, then it's OK to remove the code |
| 12:58:40 | zahary | "closure body" = "the passed block" |
| 13:00:41 | Araq | well but you also do: |
| 13:00:50 | Araq | elif f.kind == tyTypeDesc: |
| 13:00:52 | Araq | result = arg |
| 13:00:53 | Araq | else: |
| 13:00:55 | Araq | result = argOrig |
| 13:03:05 | zahary | are you opposed to this? I find it more convenient to work this way. basically, the user has specified that he wants a typedesc paramenter, so I give him a typedesc instead of AST tree |
| 13:05:38 | zahary | I was going to argue about this in some other cases too. Static params(expr[strinng]) should not be passed as AST as well. |
| 13:06:11 | zahary | the compile-time rope formatting code needed this badly |
| 13:06:29 | Araq | well if we remove all these special cases it'll get 'copyTree(arg)' |
| 13:06:56 | Araq | (I think the copyTree is unnecessary now) |
| 13:07:09 | Araq | so I can't really follow |
| 13:07:26 | Araq | yeah you requested a typeDesc but you'll get a typeDesc |
| 13:07:37 | zahary | let me describe the problem |
| 13:07:57 | Araq | result = argOrig # this is what's questionable |
| 13:08:01 | zahary | say you call a macro with an expression that returns a type, but is more complex than just a name |
| 13:08:19 | zahary | do_something_with_type(choose_type(foo, bar)) |
| 13:09:09 | zahary | it's very inconvenient to get the AST tree of "choose_type(foo, bar)", instead of the actual type |
| 13:09:17 | Araq | yep |
| 13:10:15 | zahary | well, result = argOrig is there to avoid "dirtifying" of the AST in the regular case |
| 13:11:13 | Araq | but why do we need this? |
| 13:11:18 | * | Trix[a]r_za is now known as Trixar_za |
| 13:11:33 | Araq | you can always use callsite() to get the original ast |
| 13:11:37 | zahary | when you say that you accept "expr" or "stmt", you don't want identifiers to be converted to nkSym for example (it used to be like this for a while and I had problems related to it while developing the unittest lib) |
| 13:12:00 | zahary | callsite may be a good work-around, but I'm not sure what is the better default |
| 13:13:08 | Araq | well have a look at prepareOperand please |
| 13:13:20 | zahary | in sem.nim ? |
| 13:13:25 | Araq | sigmatch.nim |
| 13:14:53 | Araq | it doesn't deal with tyStmt yet |
| 13:15:19 | Araq | but the semantics are quite clear: if the formal is a tyExpr we don't want any semchecking |
| 13:15:50 | Araq | otherwise if it hasn't been sem'checked (a.typ.isNil), it is |
| 13:17:15 | Araq | however, expr[string] is very different |
| 13:17:26 | Araq | it means the opposite of 'expr' |
| 13:17:45 | Araq | not only semcheck it, but in fact evaluate it at compile-time |
| 13:18:17 | zahary | that's why I call them static params to eliminate any confusion. expr[string] is just a matter of encoding it somehow in the code and the compiler |
| 13:18:51 | Araq | alright well I'm against these hacks now :-) |
| 13:19:17 | Araq | so I may add tyStatic instead |
| 13:20:03 | zahary | one way to define it in an alternative way is to say "expr" is compile time value. if it's not given a type, it will be matched and represented by any AST tree that you pass |
| 13:21:36 | Araq | speaking of which, I also plan to introduce quite some type flags like 'hasDestructor' that are lifted up the type graph |
| 13:21:41 | zahary | there was some other argument for tyExpr related to generic params, but I can't quite recall it |
| 13:22:35 | Araq | so there is no need for the deep checking everywhere in the compiler |
| 13:22:56 | zahary | there is hasDestructor already |
| 13:23:12 | Araq | yeah but it's hackish |
| 13:23:23 | Araq | with a global dummy symbol |
| 13:23:35 | zahary | destructor can be either a pointer to symbol, nil for "no destructor" and a special value for ... |
| 13:23:41 | zahary | ... not checked yet |
| 13:23:55 | Araq | also ccgtypes.containsCompileTimeOnly() seems to be wrong ;-) |
| 13:24:08 | Araq | as it has no recursion check |
| 13:24:14 | zahary | well, it's hackish, but also efficient. why waste memory |
| 13:25:13 | zahary | alright (about compileTimeOnly) |
| 13:25:23 | Araq | warning: nil here may not necessary |
| 13:25:24 | Araq | mean that there is no destructor. |
| 13:25:34 | Araq | --> that's the problem |
| 13:25:51 | zahary | where was this |
| 13:25:53 | zahary | ? |
| 13:26:04 | Araq | it's your comment in ast.nim |
| 13:26:46 | zahary | alright, so nil means "not checked yet" |
| 13:26:56 | zahary | and the special value is for "no destructor" |
| 13:27:52 | Araq | well I want to check for p(q()) where q yields a type with a destructor |
| 13:28:07 | Araq | and forbid it for now |
| 13:29:00 | Araq | and it's confusing if 'nil' doesn't mean what is natural ;-) |
| 13:29:04 | zahary | the way it's supposed to work is that you call instantiateDestructor and it returns "hard" true or false whether the type has a destructor |
| 13:29:26 | zahary | if necessary, it performs the analysis, otherwise it returns the cached result |
| 13:30:48 | zahary | again, it was a bit more efficient to work this way, it's easy to initialize the type with the special value to mean "not checked yet" |
| 13:32:12 | Araq | well I need these flags for other things like "hasGCedMemory", "hasGenericType" |
| 13:32:46 | Araq | and I don't think they use any additional space in PType |
| 13:33:01 | Araq | we already use a full word for the flags iirc |
| 13:33:30 | zahary | there are free bits in the type flags, but still for destructors in particular you don't need them |
| 13:33:43 | Araq | also instantiateDestructor doesn't work as nicely as it takes a PContext |
| 13:34:07 | zahary | but any solution that performs the analysis lazily is likely to need it |
| 13:34:32 | zahary | what would be different if you used flags? |
| 13:34:57 | Araq | I'd simply query the type if it contains any destructor |
| 13:35:36 | Araq | and as you said, the flag doesn't mean the destructor symbol is set |
| 13:36:29 | Araq | because for arrays for instance we don't need an explicit destructor |
| 13:37:02 | Araq | but alright, it's not that important |
| 13:37:35 | Araq | how do you think the p(q()) problem should be tackled? |
| 13:39:06 | zahary | one easy way is turn the call into a stament block, where the params the turned into variables |
| 13:39:06 | Araq | if we transform it to: let tmp = q(); p(tmp) this has consequences for macros |
| 13:39:41 | Araq | in particular it has consequences for TR macros |
| 13:40:39 | zahary | hmm, you can do it late in the codegen and evals, but it will be more work |
| 13:41:45 | zahary | I had an idea once about "post-call statements" in the expr templates |
| 13:42:24 | zahary | if this existed, its mechanisms would have been sufficient for destructors as well |
| 13:43:01 | * | fowl quit (Ping timeout: 248 seconds) |
| 13:47:13 | Araq | well we have the fields iterator now for objects; if only '=' would be overloadable, we'd have a perfect user definable '=' |
| 13:47:46 | Araq | however destructors are harder as they're invoked implicitly at scope exit |
| 14:03:58 | Araq | zahary: if we ensure that calling a destructor twice has no effect, we can also simply invoke it for every *parameter* at the end of a function, right? |
| 14:04:52 | Araq | so p(q()) # p calls the destructor |
| 14:08:09 | Araq | ah never mind, cant work |
| 14:08:21 | zahary | come on, it's not that hard to implement it properly :) |
| 14:09:55 | zahary | btw, I wanted to add a node flag to the try blocks inserted for destructors that will allow me to use C++ destructors in the codegen after all (as an option/policy) |
| 14:11:01 | Araq | no node flag, it should be nkHiddenTryStmt instead I think |
| 14:12:12 | zahary | sounded easier to do with a flag, but I don't mind |
| 14:13:16 | Araq | nkHiddenTryStmt could be hidden in renderer.nim though I don't know whether it's a good idea |
| 14:57:58 | * | fowl joined #nimrod |
| 15:05:49 | * | q66 joined #nimrod |
| 17:20:55 | * | avarus joined #nimrod |
| 17:20:57 | avarus | hi |
| 17:22:56 | * | xcombelle joined #nimrod |
| 17:23:21 | Araq | hi avarus |
| 17:24:21 | avarus | hey Araq |
| 17:24:30 | avarus | everything allright? |
| 17:24:50 | Araq | sure :-) |
| 17:25:24 | avarus | nimrod evolving :)? |
| 17:25:59 | avarus | I've given up ada btw. :P |
| 17:26:24 | avarus | it's a good language but too few people are using it so I have to reinvent every wheel I need |
| 17:26:33 | Araq | nimrod's always evolving |
| 17:26:43 | avarus | guessed that |
| 17:26:54 | avarus | the language is still changing, I guess? |
| 17:27:19 | Araq | not that much |
| 17:27:47 | Araq | we're mostly fixing bugs and adding features |
| 17:27:57 | avarus | ah cool |
| 17:28:20 | Araq | what wheels do you need? |
| 17:29:14 | avarus | e.g. amazon s3 "bindings" :) |
| 17:29:49 | Araq | never heard of that |
| 17:29:57 | Araq | what's "amazon s3"? |
| 17:30:49 | avarus | it's the "cloud" of amazon; you can store your files there and request them via simple http |
| 17:31:56 | avarus | you probably encountered a file that was served by amazon servers :) |
| 17:32:07 | avarus | they often have the url "amazonaws" |
| 17:32:16 | avarus | but you can cname that as well |
| 17:32:26 | Araq | sounds like some protocol on top of http |
| 17:32:33 | avarus | no it's not |
| 17:32:37 | avarus | it's just http |
| 17:32:42 | Araq | we have an httpclient in the stdlib ;-) |
| 17:33:02 | avarus | ya, I know but it's also oauth stuff which makes it ugly :P |
| 17:33:29 | avarus | s3 was just an example :) |
| 17:33:36 | avarus | there's more in ada I am missing |
| 17:33:47 | avarus | the language is fine but the eco system is too small |
| 17:33:58 | avarus | and it's not going to grow :) |
| 17:34:08 | avarus | that's important to notice |
| 17:34:48 | avarus | nimrod is young and if people like it they will write libs for it |
| 17:34:50 | avarus | components |
| 17:34:55 | avarus | however it's called for nimrod |
| 17:42:00 | Araq | it's called "module" or "package" I guess |
| 17:43:59 | avarus | k |
| 17:45:14 | Araq | actually we're still trying to figure out how to do package management ;-) |
| 17:45:39 | avarus | make it simple :) |
| 17:46:38 | Araq | I'd like to copy Go's approach but that doesn't deal with versioning afaik |
| 17:46:48 | * | fowl quit (Ping timeout: 245 seconds) |
| 18:07:33 | * | Trixar_za is now known as Trix[a]r_za |
| 18:23:36 | Araq | ping zahary |
| 18:23:42 | reactormonk | whee zahary \o/ |
| 18:48:13 | * | avarus quit (Remote host closed the connection) |
| 19:05:07 | * | q66 quit (Remote host closed the connection) |
| 19:07:19 | * | q66 joined #nimrod |
| 19:57:11 | * | xcombelle quit (Remote host closed the connection) |
| 20:15:16 | dom96 | hello |
| 21:09:04 | Araq | hi dom96 |
| 21:09:11 | dom96 | hey Araq |
| 21:09:19 | dom96 | what's up? |
| 21:10:17 | Araq | not much |
| 21:24:37 | * | gradha joined #nimrod |
| 21:25:33 | * | Trix[a]r_za is now known as Trixar_za |
| 22:09:09 | dom96 | gradha: Any reason you decided to make the rss link /threadActivity.xml and not for example /rss? |
| 22:09:39 | gradha | I'm going to add also /postActivity.xml |
| 22:09:54 | dom96 | alright |
| 22:10:30 | gradha | I don't know anything about fancy webs, maybe the cannonical way would be /rss/threadActivity and /rss/postActivity without extensions? |
| 22:11:15 | dom96 | Also I think the links in the atom feed should actually be linking directly to the post. Since they mention what was actually said for a specific post. |
| 22:11:18 | * | dom96 can add that |
| 22:11:32 | dom96 | threadActivity.xml is fine I guess |
| 22:11:54 | gradha | I'm adding the link to direct post now, creating local tests for paged threads |
| 22:12:27 | dom96 | alright, I won't add it then. |
| 22:12:38 | dom96 | An anchor is already in place for each post btw. |
| 22:12:52 | dom96 | Just need to append #postID |
| 22:12:54 | gradha | yes, I'm looking at that, will create a common function to use by both rss |
| 22:13:19 | dom96 | github uses username.atom for atom feeds of a user's activity feed. |
| 22:13:58 | dom96 | same for their blogs |
| 22:14:44 | gradha | that's wrong from a file type perspective, .atom doesn't mean anything, xml does |
| 22:15:03 | gradha | I thought mime types were precisely for that distinction: file extension vs content type |
| 22:15:03 | dom96 | sure, i'm fine with how it is now. |
| 22:17:12 | gradha | interesting stack trace http://pastebin.com/sxZZc7gs |
| 22:17:32 | gradha | this is creating a reply with the text "8" |
| 22:17:52 | gradha | " 8" fails too, " 8 " works |
| 22:17:59 | dom96 | lol |
| 22:18:08 | dom96 | That's not good. |
| 22:18:52 | gradha | interesting, " -8" renders with a square |
| 22:18:54 | dom96 | I suppose I can try to fix it, I bet Araq is busy with hardcore compiler work. |
| 22:19:44 | gradha | maybe the forum could have a "disable syntax" option, or something, at least I'm willing to implement mardown |
| 22:20:47 | dom96 | Would require a new db field, but can be done. |
| 22:21:25 | dom96 | perhaps we should make a 'syntaxType' field and have 'rst' and 'none', so that we can extend it in the future easily. |
| 22:21:50 | dom96 | Implementing markdown may not be trivial, and the rst parser supports some markdown I think. |
| 22:21:59 | gradha | an int to a hardcoded table would be enough |
| 22:22:24 | gradha | I'm thinking of stealing stackoverflow's real time javascript markdown preview. if it's js |
| 22:22:27 | dom96 | yeah, wasn't really thinking about what data types will be used in SQL. |
| 22:22:35 | Araq | omg not again |
| 22:22:58 | Araq | the rst parser does support markdown |
| 22:23:12 | Araq | heck, markdown is not even defined properly |
| 22:23:24 | dom96 | IMO proper quoting would be better. |
| 22:23:32 | gradha | I know, I'm going to write my own version, with black jack and hookers |
| 22:23:56 | dom96 | Araq: I don't get why you dislike markdown. |
| 22:23:58 | gradha | actually I'm going to write gradhadown, for the ladies |
| 22:24:23 | Araq | it's not that I dislike markdown ... |
| 22:24:36 | Araq | it's just that markdown is a subset of RST, mostly |
| 22:24:50 | Araq | and our RST parser supports markdown afaict |
| 22:25:17 | gradha | I happen to suffer from NIH and dislike both mardown and rst, so... it's inevitable I'll make my own failure, eventually |
| 22:25:46 | Araq | gradha: that's actually a serious bug |
| 22:25:54 | Araq | the rst parser should never fail |
| 22:26:18 | Araq | that might be used as a DOS attack |
| 22:26:27 | gradha | it was likely implemented for small values of the word never |
| 22:27:00 | Araq | however, the rst.nim(607) doesn't contain any array index expression ... :-/ |
| 22:28:01 | gradha | maybe its one of those strange mac only bugs, can you try with a local version of nimforum? just answer with an 8 to a thread |
| 22:29:59 | Araq | no I think it's quite clear what's wrong here |
| 22:30:32 | dom96 | fails here. |
| 22:30:40 | dom96 | Forum doesn't crash thanks to jester though :P |
| 22:31:04 | * | dom96 hugs jester |
| 22:31:33 | gradha | it's awkward touching night again? |
| 22:32:05 | dom96 | sure, why not. |
| 22:32:36 | gradha | btw, electronic sleep inducing butterfly lovers may like http://www.youtube.com/watch?v=epvFaBeqii8 too |
| 22:33:00 | gradha | I think there's a better song in that album, but it's so rare it's not on youtube |
| 22:35:12 | Araq | dom96: add ' and result < p.tok.len' in line rst:605 and see if that fixes it please |
| 22:35:24 | dom96 | will do |
| 22:35:32 | dom96 | gimme a couple of minutes |
| 23:08:31 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 23:29:34 | * | Trixar_za is now known as Trix[a]r_za |
| 23:29:44 | dom96 | !repos |
| 23:29:44 | NimBot | Announced repos: Araq/Nimrod, nimrod-code/nimbuild, nimrod-code/aporia |
| 23:29:54 | dom96 | !addrepo nimrod-code nimforum |
| 23:29:54 | NimBot | Done. |
| 23:30:20 | NimBot | nimrod-code/nimforum 4c2b5d1 Grzegorz Adam Hankiewicz [+1 ±0 -0]: Creates a .gitignore to avoid generated files. |
| 23:30:20 | NimBot | nimrod-code/nimforum 01f480a Grzegorz Adam Hankiewicz [+0 ±2 -0]: Adds hyperlinks to profile pages. |
| 23:30:20 | NimBot | nimrod-code/nimforum 9d9772e Grzegorz Adam Hankiewicz [+0 ±1 -0]: Changes forum's header links.... 4 more lines |
| 23:30:20 | NimBot | nimrod-code/nimforum eab0673 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Implements rss for thread activity. |
| 23:30:20 | NimBot | nimrod-code/nimforum b5d190e Dominik Picheta [+1 ±2 -0]: Merge branch 'pr_hyperlinks_user_profiles' of git://github.com/gradha/nimforum into gradha-pr_hyperlinks_user_profiles |
| 23:37:40 | dom96 | Araq: Doesn't help. |
| 23:39:58 | Araq | but you added it before the 'continuesWith' condition, right? |
| 23:41:24 | dom96 | nope :P |
| 23:41:57 | Araq | well you have to use your brain |
| 23:42:24 | dom96 | well I found it puzzling that the line with the exception points to 'inc result'... |
| 23:43:07 | dom96 | ok, that fixed it |
| 23:43:25 | Araq | good |
| 23:45:17 | NimBot | nimrod-code/nimforum f9fa9b4 Dominik Picheta [+0 ±2 -0]: Reverted back some risky changes. |
| 23:58:14 | NimBot | Araq/Nimrod 6f3452d Dominik Picheta [+0 ±1 -0]: Fixed issue with rst parser failing to parse a specific character. |
| 23:58:14 | NimBot | Araq/Nimrod c7a6a87 Dominik Picheta [+0 ±1 -0]: Fixed some recvLine deprecation warnings in httpserver module. |