| 01:12:37 | * | ack006 joined #nimrod |
| 01:22:55 | OrionPK | has something changed since 0.9.0 with importc? |
| 01:23:37 | OrionPK | int test(int x, int y) { return x * y; } in C, I import it into nim |
| 01:23:50 | OrionPK | proc test*(x, y: int) : int {.importc: "test".} |
| 01:23:55 | OrionPK | then call test(5,8) |
| 01:24:02 | OrionPK | I get a memory address or something back |
| 01:24:20 | OrionPK | 21937048 |
| 01:24:25 | OrionPK | instead of 40 |
| 01:24:42 | OrionPK | (and this used to work in 0.9.0) |
| 01:24:59 | Araq | 64 vs 32 bit issue? |
| 01:25:07 | Araq | c's int is not Nimrod's int |
| 01:25:16 | Araq | use 'cint' and it should work |
| 01:25:30 | OrionPK | ah, good thinking |
| 01:28:11 | OrionPK | pretty sure everything is 32bit |
| 01:28:38 | Araq | what does 'nimrod -v' say? |
| 01:28:47 | Araq | and what does 'gcc -v' say? |
| 01:28:49 | OrionPK | Nimrod Compiler Version 0.9.1 (2013-04-23) [Windows: i386] |
| 01:29:09 | fowl | Araq: dont you need {.stdcall.} on windows |
| 01:29:18 | OrionPK | mingw32 |
| 01:29:46 | Araq | hmm good point fowl; the calling convention has to match |
| 01:29:59 | Araq | if your C code has none, it's 'cdecl' in Nimrod |
| 01:30:20 | OrionPK | this is the code: |
| 01:30:20 | OrionPK | {.link: "test.dll".} |
| 01:30:20 | OrionPK | proc test*(x, y: cint) : cint {.importc: "test".} |
| 01:30:44 | Araq | {.link: "test.dll".} ? |
| 01:30:54 | Araq | do it properly please |
| 01:30:57 | OrionPK | the C is in test.dll |
| 01:31:04 | Araq | yeah I figured |
| 01:31:05 | OrionPK | pretty sure I got that from your manual :P |
| 01:31:14 | Araq | pretty sure you don't |
| 01:31:15 | fowl | you probably want {.dynlib.} |
| 01:32:02 | Araq | proc test*(x, y: cint): cint {.importc: "test", dynlib: "test.dll", cdecl.} |
| 01:32:06 | Araq | try that one |
| 01:33:42 | OrionPK | bad image error |
| 01:34:04 | Araq | ? |
| 01:34:22 | Araq | sounds like the test.dll is broken then |
| 01:34:26 | OrionPK | test.dll is either not designed to run on windows or it contains an error |
| 01:35:04 | OrionPK | not saying I was doing it correctly before |
| 01:35:08 | OrionPK | but it used to work |
| 01:35:18 | OrionPK | in 0.9.0 |
| 01:36:38 | Araq | well the {.link.} could happen to work and int = cint for 32bit, so yeah |
| 01:37:08 | Araq | not sure wether I fixed the calling convention after 0.9.0 to really be fastcall |
| 01:40:31 | Araq | did you rebuild the test.dll? |
| 01:40:40 | OrionPK | yes |
| 01:41:31 | Araq | well you did it wrong this time :P |
| 01:41:35 | OrionPK | lol |
| 01:41:46 | OrionPK | I only recompiled it because it wasnt working ;) |
| 01:41:50 | Araq | build a 64 bit DLL? |
| 01:42:23 | OrionPK | nope |
| 01:43:32 | Araq | built a 16 bit DLL? |
| 01:44:28 | OrionPK | just gcc -c test.c -o test.dll options |
| 01:45:09 | fowl | doesnt that build an executable? |
| 01:45:19 | Araq | add -shared at least |
| 01:47:35 | OrionPK | no difference |
| 01:48:09 | Araq | dunno -c looks wrong |
| 01:48:31 | Araq | that would compile an .o into test.dll I think |
| 01:48:38 | OrionPK | ah |
| 01:48:51 | OrionPK | you were right |
| 01:49:06 | Araq | but I'm sleeping since 3 hours anyway |
| 01:49:07 | OrionPK | I was compiling it as an executable |
| 01:49:14 | OrionPK | "40" |
| 01:49:15 | Araq | so good night |
| 01:49:19 | OrionPK | thanks for your help |
| 01:49:31 | OrionPK | god natt |
| 01:49:36 | Araq | you're welcome, bye |
| 01:50:27 | OrionPK | now why the hell what I was doing ever work :S |
| 01:50:58 | OrionPK | (this is what I get for going straight from school into high level languages) |
| 01:53:48 | fowl | lol |
| 01:56:51 | OrionPK | last time I used C was for embedded stuff in college |
| 02:56:22 | * | r0bglees0n joined #nimrod |
| 02:56:28 | r0bglees0n | hey |
| 02:56:32 | r0bglees0n | fowl: hello |
| 03:35:37 | fowl | hey |
| 04:11:07 | * | OrionPK quit (Quit: Leaving) |
| 05:07:51 | * | Trixar_za is now known as Trix[a]r_za |
| 05:07:59 | * | ack006 quit (Quit: Leaving) |
| 09:02:39 | Araq | hi r0bglees0n, welcome |
| 09:16:35 | NimBot | Araq/Nimrod 1e10a2b Billingsly Wetherfordshire [+0 ±1 -0]: Update evals.nim |
| 09:16:35 | NimBot | Araq/Nimrod 47fd198 Billingsly Wetherfordshire [+0 ±1 -0]: Update macros.nim |
| 09:16:35 | NimBot | Araq/Nimrod 1bea922 Araq [+0 ±2 -0]: Merge pull request #403 from fowlmouth/patch-4... 3 more lines |
| 09:18:04 | zahary_ | ha, Araq is secretly working on a new parser! is this about the expressions/statement sunification? |
| 09:20:16 | Araq | zahary_: yeah that's one reason |
| 09:20:38 | Araq | it's pretty hard to achieve and I'm still wondering how to do it |
| 09:20:59 | zahary_ | are there any user-visible changes in the syntax? |
| 09:21:22 | Araq | proc p() |
| 09:21:27 | Araq | {.pragmas.} |
| 09:21:31 | Araq | is finally supported |
| 09:21:39 | zahary_ | aha, cool |
| 09:21:46 | Araq | I don't think there are any other changes for now |
| 09:22:17 | Araq | it currently breaks docgen I haven't looked at it yet |
| 09:22:30 | Araq | it compiles all the code we could throw at it |
| 09:23:06 | zahary_ | hmm, but how could it break it, there are changes in the AST as well? |
| 09:23:24 | Araq | the indentation handling changed |
| 09:23:49 | Araq | so what was acceptable could be an error now |
| 09:23:59 | zahary_ | but these are lexer tokens only? |
| 09:24:09 | Araq | the AST didn't change |
| 09:24:27 | Araq | breaking code as in "the parser doesn't parse this anymore" |
| 09:24:35 | zahary_ | I see |
| 09:24:53 | zahary_ | have you made up your mind about the horizontal layout btw? (white-space sensitivity for operators) |
| 09:25:07 | zahary_ | I guess, it's too much of a breaking change |
| 09:25:40 | Araq | I still like the idea, I dunno if it puts the language too far |
| 09:26:16 | Araq | however depending on how the expr/stmt unification goes, we need '#! newsyn' anyway |
| 09:27:08 | zahary_ | I didn't quite get that |
| 09:27:19 | Araq | interestingly the major problem with the unification is the attempted typedesc/expr unification that's already in the grammar |
| 09:27:47 | zahary_ | where does it strike? |
| 09:28:09 | Araq | var T # type or beginning of a 'var' statement? |
| 09:28:40 | Araq | I have solutions for most now, but it will break code |
| 09:28:51 | Araq | the compiler supports alternative parsers |
| 09:29:02 | Araq | via lines starting with #! |
| 09:29:18 | Araq | so we can keep what we have and introduce '#! newsyn' |
| 09:29:26 | Araq | and then at one point make that the default |
| 09:29:37 | Araq | and the old one '#! oldsym' |
| 09:30:01 | Araq | I have to go, see you later |
| 09:30:05 | zahary_ | ah, you meant #! newsyn activates the horizontal layout and other stuff, I see |
| 09:30:13 | Araq | yeah, bye |
| 09:30:21 | zahary_ | see you |
| 09:37:56 | fowl | im writing a megamacro :> |
| 09:57:27 | * | xcombelle joined #nimrod |
| 10:05:46 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 10:56:52 | * | xcombelle joined #nimrod |
| 12:35:28 | * | q66 joined #nimrod |
| 13:47:41 | Araq | zahary_: one idea that I like very much is to separate typeDesc from expr properly and introduce [. .] brackets to disambiguate |
| 13:48:13 | zahary_ | I didn't quite get what the problem is |
| 13:48:19 | zahary_ | var T |
| 13:48:26 | zahary_ | why T can be interpreted as type here? |
| 13:48:57 | Araq | declareMyVar(x, var int) # works currently afaik |
| 13:49:58 | zahary_ | hmm, it doesn't look well-formed |
| 13:50:01 | Araq | with the new syntax this would become: |
| 13:50:08 | Araq | declareMyVar(x, [.var int.]) |
| 13:50:33 | Araq | also this means we can do: [.ref T.](x) # type conversion without named type |
| 13:51:18 | zahary_ | but what is to gain here? the goal of this construct is to allow both "var int" and "let int" as arguments |
| 13:51:29 | zahary_ | oh, I get it |
| 13:51:45 | zahary_ | var int, "int reference" |
| 13:51:55 | Araq | yes |
| 13:52:26 | zahary_ | ok, so the problem is how to preserve LL(1)? |
| 13:52:44 | Araq | yeah, well |
| 13:52:52 | Araq | it's not LL(1) anymore by any means |
| 13:53:09 | Araq | but I really like the 1 token of lookahead required |
| 13:53:44 | Araq | and I think it's a really good rule to keep things readable |
| 13:54:32 | zahary_ | isn't this still possible. I have to look at the code, but it looks like you just don't have to "commit" to what AST "var x" will be turned into before looking at the next token (either a colon or expression-end) |
| 13:55:56 | Araq | yeah maybe but then AST patching is cheating too :-) |
| 13:56:26 | zahary_ | yes, but you are trading our convenience in writing the parser to the convenience of millions of users |
| 13:56:48 | Araq | that's not the reason |
| 13:56:59 | Araq | infinite lookahead is trivial to implement |
| 13:57:04 | Araq | I did it for c2nim |
| 13:58:12 | Araq | I'm trying to keep things simple for the convenience of our users |
| 14:01:22 | zahary_ | explaining parsing ambiguities is a bit high-toll demand for the average joe I think |
| 14:01:56 | zahary_ | make that "resolving parsing amb..." |
| 14:02:57 | zahary_ | also, var int doesn't look well-formed as a variable declaration. why should I help the parser in figuring this out |
| 14:06:20 | Araq | because it's rarely necessary to pass a typedesc to a template anyway and edge cases don't deserve the complexity |
| 14:07:00 | zahary_ | passing a typedesc to a function/macro/template is not common? |
| 14:07:16 | zahary_ | please, reconsider. I plan to do this a lot |
| 14:07:28 | Araq | lol, what's the use case? |
| 14:09:10 | zahary_ | all the type traits functions, generating types like "variant" from list of types. registering types in DIY reflection or RPC systems |
| 14:09:46 | zahary_ | and this is a short list. doing meta-programming with types is really common |
| 14:09:52 | Araq | yeah but I'm not talking about typeDescs that do parse as an expression like 'int' or 'seq[int]' |
| 14:10:15 | Araq | it's only a few things like 'var T' that cause problems in the 'expr' context |
| 14:10:38 | Araq | we could also allow var[int] instead ... |
| 14:10:44 | zahary_ | well, you can always work around with helper templates like int.var_t |
| 14:10:54 | zahary_ | but that's a bit of kludge too |
| 14:11:08 | Araq | var[int] is pretty cool though and consistent |
| 14:11:10 | zahary_ | ah, you were first |
| 14:12:48 | Araq | and yeah ref[T](x) as a type conversion is nice too |
| 14:17:19 | * | xcombelle quit (Remote host closed the connection) |
| 14:18:56 | Araq | another problem is {expr: expr} where the ':' doesn't mean the same as in expr: expr # pass expr to the macro |
| 14:19:48 | Araq | seems easy to invoke the macro as expr(expr) instead in this case then |
| 14:20:03 | Araq | so the ':' can be special in the curlies |
| 14:20:15 | zahary_ | yes, I think this would be more consistent, but you must break backward compatibility here |
| 14:20:37 | Araq | huh? how so? |
| 14:21:04 | zahary_ | I mean if you allow only the {. foo(bar) .} version to keep things consistent |
| 14:21:32 | Araq | but |
| 14:21:33 | Araq | m( |
| 14:21:36 | Araq | if .... |
| 14:21:38 | Araq | ) |
| 14:21:46 | Araq | is ugly compared to: |
| 14:21:47 | Araq | m: |
| 14:21:49 | Araq | if .... |
| 14:22:03 | Araq | not sure I get what you mean |
| 14:22:50 | zahary_ | ah, so you meant that foo: bar is parsed as the former nkMacroStmt and not as some kind of nkPair |
| 14:23:31 | Araq | yeah unless it is in {} and then it's a pair |
| 14:23:41 | Araq | I have to go again, see you later |
| 15:02:50 | * | XAMPP_ quit (Quit: My code has no bug's, just random features) |
| 15:03:08 | * | XAMPP joined #nimrod |
| 15:03:08 | * | XAMPP quit (Changing host) |
| 15:03:08 | * | XAMPP joined #nimrod |
| 15:04:08 | * | XAMPP quit (Read error: Connection reset by peer) |
| 15:04:29 | * | XAMPP joined #nimrod |
| 15:04:31 | * | XAMPP quit (Changing host) |
| 15:04:31 | * | XAMPP joined #nimrod |
| 16:58:47 | * | zahary_ quit (Quit: ~ Trillian Astra - www.trillian.im ~) |
| 19:06:30 | fowl | Araq: got a segfault somewhere in buildEntities() https://gist.github.com/fowlmouth/5466040 |
| 19:08:49 | * | Trix[a]r_za is now known as Trixar_za |
| 19:36:38 | fowl | ahzzzzzzz Error: macro returned a cyclic abstract syntax tree |
| 20:26:04 | fowl | ty = newNimNode(nnkRefTy).und(ty) |
| 20:26:12 | fowl | ^ problematic |
| 20:26:51 | dom96 | lol, looks like it. |
| 20:30:48 | * | fowl quit (Ping timeout: 264 seconds) |
| 20:53:55 | * | fowl joined #nimrod |
| 21:08:32 | fowl | dom96: that should work, right? |
| 21:08:43 | dom96 | i have no idea, sorry. |
| 21:09:11 | dom96 | But since it's an error it seems like it shouldn't. |
| 21:09:34 | fowl | i think its an error with the evaluator |
| 22:32:31 | * | OrionPK joined #nimrod |
| 22:34:10 | Araq | fowl: it's a known evaluator bug; too hard to fix |
| 22:34:32 | Araq | my hope is the luajit backend will fix it finally |
| 22:37:20 | Araq | or maybe it's possible to fix in some other way |
| 22:46:37 | fowl | what exactly is happening? is it creating the refty, setting to ty then adding ty to it? |
| 22:48:44 | Araq | x = ..... x .... |
| 22:49:02 | Araq | the "self" assignment |
| 22:58:03 | fowl | thats normally ok with ref types |
| 22:58:26 | Araq | but not with PNimrodNode at compile time |
| 23:03:09 | * | q66 quit (Remote host closed the connection) |
| 23:04:02 | fowl | Araq: there is really strange behavior of tables in a macro |
| 23:07:37 | Araq | yeah haven't looked at it yet |
| 23:08:06 | fowl | https://gist.github.com/fowlmouth/5466040#file-components-nim-L65 table[field].needsRef = true is silently failing |
| 23:12:33 | Araq | what's"silently"? |
| 23:12:48 | Araq | doesn't update? |
| 23:12:54 | fowl | yea |