| 00:01:58 | * | mflamer_ joined #nimrod |
| 00:13:47 | * | mflamer_ quit (Ping timeout: 268 seconds) |
| 00:20:14 | * | XAMPP-8 quit (Ping timeout: 240 seconds) |
| 00:21:21 | * | XAMPP-8 joined #nimrod |
| 00:25:02 | Varriount | You know, it's so refreshing to have a compiler which takes only a minute or two to build itself, compared to the hour or so gcc takes. |
| 00:25:29 | fowl | hi |
| 00:25:42 | Varriount | hi |
| 00:32:56 | * | xenagi joined #nimrod |
| 00:36:10 | filwit | any chance the developer from the Leaf language stopped by at any point? |
| 00:36:14 | * | webskipper quit (Ping timeout: 240 seconds) |
| 00:36:31 | filwit | also.. if only Phoronix would do an article on Nimrod.. |
| 00:36:38 | * | webskipper joined #nimrod |
| 00:36:48 | Varriount | filwit, Leaf language? |
| 00:37:10 | Varriount | filwit, did you email him/her? |
| 00:37:14 | filwit | Phoronix did an article on it, it's new: http://leaflang.org/ |
| 00:37:37 | filwit | and yes, i talked to the developer, and invited (him?) to come over here sometime |
| 00:38:08 | Varriount | filwit, did you email Phoronix? |
| 00:38:26 | filwit | no, i used the contact message thing on the Leaf site |
| 00:38:51 | filwit | i've never contacted Phoronix, though it might be cool to write him and see if he would be willing to do an article on Nimrod |
| 00:39:03 | filwit | though we'd probably need to supply said article |
| 00:39:44 | Varriount | filwit, I like the site. The only think that turns me off is the "Join Us" button. |
| 00:40:03 | filwit | the reason i contacted the Leaf guy was cause his language looks very similar to a language i was starting to write before, and his goals seem similar to Nimrod in general |
| 00:40:21 | filwit | Varriount: yeah, the site is well done |
| 00:40:35 | filwit | language looks good (to me) as well.. mostly |
| 00:40:46 | filwit | though it's still really new (not even modules yet) |
| 00:42:16 | * | brson joined #nimrod |
| 00:42:21 | * | brson quit (Client Quit) |
| 00:42:30 | * | brson joined #nimrod |
| 00:42:38 | * | mkb quit (Ping timeout: 240 seconds) |
| 00:42:38 | xenagi | eh |
| 00:42:46 | * | mkb joined #nimrod |
| 00:42:53 | xenagi | aside from a nice syntax, i haven't found anything revolutionary or impressive about it |
| 00:43:28 | filwit | well, there really arent many options out there if you want a language that does memory safety and runtime performance |
| 00:43:38 | filwit | and his syntax is pretty nice (mostly) |
| 00:43:38 | Varriount | It's the downside of programmers, that they tend to all want to reinvent the wheel. |
| 00:44:06 | xenagi | ^ |
| 00:44:07 | filwit | and he compiles to LLVM, unlike D which tries it's own thing, so maybe it will move alone quicker |
| 00:44:41 | xenagi | Varriount, that could be the majority of people, not just programmers. |
| 00:44:58 | filwit | really, for games, if you want to avoid C/C++ your only options are: D, Nimrod... maybe C#/Java if you can manage that |
| 00:45:12 | filwit | oh, and Rust |
| 00:45:38 | Varriount | While I like that new languages are being developed, when two languages (such as leaf and nimrod) with similar syntax crop up, I can't help but think how much more successful they would be to just combine and work together. |
| 00:45:43 | * | xenagi noticed how filwit neglected Go |
| 00:45:46 | filwit | but D's implementation is poor and barely runs on ARM, and Rust is over complicated |
| 00:45:58 | xenagi | Varriount, agreed. |
| 00:45:59 | filwit | xenagi: Go isn't an option for games man |
| 00:46:12 | filwit | xenagi: Go's type system is gimped, and it's slow |
| 00:46:25 | filwit | xenagi: it's GC is horrible and causes memory leaks too |
| 00:46:44 | xenagi | lol ok ok im starting to regret having mentioned it |
| 00:46:54 | filwit | xenagi: though i haven't tried it in awhile, so maybe thats out of date info |
| 00:47:06 | filwit | xenagi: lol |
| 00:47:08 | * | Varriount noticed how filwit neglected perl |
| 00:47:12 | Varriount | ;3 |
| 00:47:14 | filwit | ^ LOL |
| 00:47:16 | xenagi | i like it, but for different reasons than Nimrod |
| 00:47:48 | xenagi | The way I see it, Go and Nimrod have their respective niches, much like you're typical Venn diagram with the typical intersection |
| 00:49:04 | OrionPK | marshal.nim(242, 9) Error: internal error: |
| 00:49:05 | OrionPK | instantiateGenericParamList |
| 00:49:06 | OrionPK | :S |
| 00:49:08 | xenagi | Varriount, I know what you mean. Sometimes I think programmers invent languages for the sake of inventing languages, without offering anything new, and before you know it, PHP is born |
| 00:49:09 | filwit | nah, Nimrod's a league of it's own.. it's Macro's allow third parties to invent their own inheritance system, and once that's discovered by everyone (and the standard lib is cleaned up) then Nimrod will explode i think :) |
| 00:49:58 | Varriount | filwit, you are forgetting the fact that it is not well known. Also, even though the main site looks pretty, the documentation pages could use some work. |
| 00:50:19 | filwit | Varriount: yes i agree |
| 00:50:29 | filwit | Varriount: both can be fixed though :) |
| 00:50:30 | Varriount | Programmers also tend to forget that people, even other programmers, tend to judge a book by it's cover. |
| 00:50:45 | xenagi | yeah, i think the module docs in the stl could use more examples |
| 00:51:02 | filwit | Varriount: yes exactly, which is why having a good website is a first step, but only just a single step |
| 00:51:03 | * | Varriount points at GNU's html1.0 web pages. |
| 00:51:27 | * | xenagi is blind |
| 00:51:53 | filwit | Nimrod needs a few things, but it's really the only good replacement for C++ for games, IMO, because it can be used for the engine code AND the scripts |
| 00:52:02 | filwit | maybe Rust... |
| 00:52:07 | filwit | eventually D.. |
| 00:52:44 | Varriount | I've not heard much about rust. D's stop-the-world gc, as well as lack of 64-bit window compilation, is a drawback. |
| 00:52:59 | filwit | yeah exactly. |
| 00:53:15 | filwit | and Rust is kinda too complicated to be used for script kiddies too |
| 00:53:31 | filwit | so, yeah, Nimrod is it (and has the best tech anyways) |
| 00:53:38 | filwit | at least for now |
| 00:53:40 | Varriount | With nimrod, I was surprised to actually get the compiler to bootstrap with relatively little fuss. |
| 00:54:37 | Varriount | I've never been able to get *any* other compiler to natively compile to a 64 bit binary on windows. |
| 00:55:07 | filwit | yeah, i had the same experience when compiling Nimrod. it just worked without odd problems |
| 00:55:25 | filwit | but Nimrod's fighting an uphill battle, because it's so alien to everything else |
| 00:56:10 | filwit | if the main website hadn't put "a soft real-time GC (with games in mind)" on the main page, i probably would have passed it up |
| 00:57:35 | Varriount | Huh, did you know that, if you don |
| 00:58:00 | Varriount | Did you know that if you don't give a procedure parameter a type, it defaults to 'expr'? |
| 00:58:53 | filwit | yes |
| 00:59:15 | filwit | which is great, IMO |
| 00:59:36 | Varriount | filwit, to my mind, it's too ambiguous |
| 00:59:40 | filwit | makes writing code almost feel like a dynamic language, which you can then go tighten up |
| 01:00:27 | Varriount | because that trait also effects everything from lambdas to type declarations |
| 01:00:52 | filwit | Varriount: it's debatable, but I like the feature |
| 01:01:18 | filwit | dont really use it myself, but it's nice for advertisement at the very least |
| 01:01:37 | Varriount | filwit, Well, it's what is causing bugs several bugs with accidental generics |
| 01:02:17 | filwit | Varriount: well i haven't looked at the issues list concerning it. maybe it's not worth it, idk |
| 01:02:51 | filwit | although i'd imagine it'd be the same as using 'expr' everywhere, so idk how it would really cause problems |
| 01:02:52 | webskipper | I am right: nimrod has not call-by-reference as default ? |
| 01:03:16 | filwit | webskipper: no, nimrod has call-by-reference (if i understand you correctly) |
| 01:03:25 | webskipper | oh ok |
| 01:03:27 | filwit | webskipper: type Foo = ref object ... |
| 01:03:31 | Varriount | call by reference? |
| 01:03:33 | webskipper | and when I use var in the parameters list? |
| 01:03:41 | webskipper | its call by value ? |
| 01:03:51 | filwit | webskipper: it's a ref |
| 01:04:07 | filwit | webskipper: cause it modifies the original var, it has to be a ref |
| 01:04:26 | filwit | webskiper: you can also do: type Foo {.byRef.} = object ... |
| 01:04:35 | Varriount | webskipper, I believe that, by default, the compiler tries to infer automaticaly whether to pass function arguments as references or copies. |
| 01:04:41 | filwit | webskipper: which will create a value type object, but always pass it by ref |
| 01:04:43 | webskipper | I mean proc(a : int, var b : int, c : int) |
| 01:05:35 | filwit | proc foo(a:int, b:var int, c:int) # a is value, b is ref, c is value |
| 01:05:48 | webskipper | ah ok |
| 01:05:59 | filwit | proc bar(a:ref int) # a is ref |
| 01:06:22 | * | Varriount misses Araq |
| 01:07:00 | filwit | webskipper: also: type myint = ref int; proc foo(a:myint) # a is ref |
| 01:07:01 | webskipper | why is a ref ? its similar to a:var int than ? |
| 01:07:30 | webskipper | uuuh |
| 01:07:49 | webskipper | so its a global ref, than its ref as parameter too.. ? |
| 01:07:49 | filwit | webskipper: pass by ref means you have a reference to the instance. it's the same as: void foo(int& a) // C code |
| 01:08:27 | filwit | webskipper: but (i believe) you can't modify the ref, it just passes by ref (for performance? idk..) |
| 01:08:30 | webskipper | The & I know from PHP too. |
| 01:08:56 | filwit | webskipper: where as pass by 'var' means the type can be modified |
| 01:09:07 | filwit | webskipper: sorry, i made a mistake in my C code above |
| 01:09:37 | filwit | webskipper: "a:ref int" == "const int& a" |
| 01:09:59 | filwit | webskipper: or "int& a const" (i forget the correct C notation) |
| 01:10:55 | Varriount | filwit, have you seen the code for the sockets and asyncio modules? |
| 01:11:04 | filwit | Varriount: no |
| 01:11:09 | filwit | Varriount: why? |
| 01:11:18 | webskipper | switching to higher abstraction and than to lower back is a bit confusing me :D |
| 01:11:46 | filwit | webskipper: i'm not sure what you mean |
| 01:12:27 | Varriount | There's quite a bit of explicitly creating a reference type for each concrete type in those modules, and I want to know why, since I don't see why they're strictly necessary. |
| 01:14:12 | * | XAMPP-8 quit (Ping timeout: 246 seconds) |
| 01:14:12 | filwit | Varriount: they may have been written before 'ref object' was introduced as a language feature |
| 01:14:43 | filwit | Varriount: which I am proud to announce was a suggestion of mine :) |
| 01:15:27 | Varriount | by 'ref object', do you mean as part of parameter types? |
| 01:15:53 | filwit | Varriount: no, i mean "type Foo = ref object" |
| 01:15:53 | webskipper | filwit: in dynamically typed languages like python its a bit less complex - that I mean. |
| 01:16:18 | filwit | Varriount: before, Nimrod didn't allow objects to be implicitly ref types |
| 01:16:30 | Varriount | filwit -> http://nimrod-code.org/asyncio.html#102 |
| 01:17:49 | webskipper | filwit: from doc "Parameters are constant in the procedure body. Their value cannot be changed because this allows the compiler to implement parameter passing in the most efficient way. If the procedure needs to modify the argument for the caller, a var parameter can be used:" |
| 01:19:00 | filwit | webskipper: correct. Like i said above, passing by 'ref' in nimrod is like passing by 'const &' in C |
| 01:19:06 | webskipper | k, ty |
| 01:19:31 | filwit | np |
| 01:19:43 | filwit | Varriount: i'm not sure what you're trying to show me |
| 01:20:30 | Varriount | webskipper, keep in mind though, you can still modify the attributes of the parameter's you're given, even without var or ref |
| 01:20:37 | OrionPK | has anyone encountered errors with passing one generic parameter to another proc? |
| 01:20:53 | Varriount | filwit, why all the explicit use of ref types? |
| 01:21:05 | Varriount | OrionPK, example? |
| 01:21:59 | filwit | Varriount: like i said, maybe the code was written before implicit ref objects where introduced, or maybe there's places where those types are used as stack objects a lot or something |
| 01:22:40 | OrionPK | Varriount i'm going to boil down a gist in a minute |
| 01:28:07 | OrionPK | Varriount check this out https://gist.github.com/onionhammer/7423812 |
| 01:29:39 | Varriount | OrionPK, what am I supposed to see? |
| 01:29:45 | OrionPK | bah |
| 01:29:49 | OrionPK | hold on, i'll update it |
| 01:30:06 | * | Varriount knows the feeling |
| 01:32:19 | webskipper | c2nim: "for example duff's device cannot be translated to Nimrod" because we have no switch case statements ? |
| 01:33:16 | filwit | webskipper: switch statements in nimrod look like: 'case.. of.. of.. else.." |
| 01:33:26 | filwit | webskipper: http://nimrod-code.org/tut1.html#case-statement |
| 01:33:31 | * | Demos joined #nimrod |
| 01:35:23 | Demos | anyone here looked at pyret? I like nimrod more :D |
| 01:36:17 | Varriount | Demos, there's been some talk of it on the python mailing lists |
| 01:36:24 | filwit | LOL @ their extension types.. that's awesome |
| 01:36:35 | Varriount | ? |
| 01:36:55 | filwit | language is named "Pyret" (pirate) and extensions are '.arr' |
| 01:37:37 | Demos | so true |
| 01:37:44 | filwit | do not like the syntax though.. |
| 01:38:03 | filwit | always hated VB-style languages |
| 01:38:05 | Demos | the predicates are neat, but a bit of a hack, would prefer the math PhDs figure out dependent types |
| 01:38:11 | Demos | erm the refinements |
| 01:38:27 | Demos | hey you can end blocks with ; instead of end :D |
| 01:38:35 | filwit | meh |
| 01:38:43 | filwit | but that's a plus |
| 01:38:54 | Demos | I kid though |
| 01:39:01 | Demos | also the .{} syntax is really wierd |
| 01:39:30 | Varriount | OrionPK, updated that gist yet? |
| 01:39:34 | filwit | its the language efficient? |
| 01:39:37 | filwit | is** |
| 01:39:48 | Demos | it is probably slower than ruby |
| 01:39:57 | Demos | I think the interpreter is implemented in racket |
| 01:39:58 | filwit | LOL |
| 01:40:10 | OrionPK | Varriount no... i'll get back to you lol. it's working in the gist but not my library |
| 01:40:25 | Demos | although cpython is written in c and it is still slow, when you are parsing strings all the time I doubt langage matter so much |
| 01:41:09 | Varriount | Demos, 'slow' is quite relative. |
| 01:41:18 | filwit | yeah, it's just doesn't fit my goals |
| 01:41:20 | Varriount | Also, pypy |
| 01:42:15 | Demos | true |
| 01:42:33 | Demos | still it is designed as a teaching language (I have no idea what that means) |
| 01:43:12 | Demos | heck my school gets away with teaching c++ to first year undergrads.... I am pretty sure c++ is not a teaching language but hey |
| 01:43:52 | Varriount | Demos, at least it's not php |
| 01:43:54 | OrionPK | Varriount, okay it's updated... |
| 01:44:19 | Demos | so true, for all c++'s strangeness it does not do anything where I am just like "WHYYYYYYYY" |
| 01:44:55 | Varriount | Demos, I will forever and for always hate include files, and autoconf. |
| 01:45:10 | Varriount | OrionPK, this better not explode all over my hard-drive |
| 01:45:29 | OrionPK | :P |
| 01:46:16 | Varriount | OrionPK, Ok, I got the error. Lessee... |
| 01:46:27 | Demos | Varriount: I will as well |
| 01:46:49 | Demos | I did a cloc on my c++ project last week and saw 1500 lines of cmake files.... |
| 01:47:31 | Demos | and c++ will get real modules in 2017(or so) |
| 01:47:35 | Varriount | For those interested in OrionPK's error -> https://gist.github.com/Varriount/7424009 |
| 01:47:53 | webskipper | Cpython IS slow :D |
| 01:48:10 | Demos | that has some line numbers |
| 01:49:56 | Demos | CompareByID<decltype(_cont)>(cont) screw you too c++ |
| 01:50:03 | OrionPK | varriount is that from a debug build of nimrod? |
| 01:50:18 | Varriount | OrionPK, yep |
| 01:51:04 | Varriount | I always build nimrod in debug mode. Makes it so much easier to help with bugs. The slowdown isn't much, and the tracebacks are enormously helpful. |
| 01:51:39 | filwit | i have three Nimrod compilers |
| 01:51:43 | Varriount | OrionPK, it seems that you can't instanciate a generic with another generic. |
| 01:51:57 | filwit | the one that's on the Arch repos, the git-HEAD, and my fork |
| 01:52:02 | OrionPK | Varriount sec.. |
| 01:52:16 | Varriount | OrionPK, It's actually enforced by the compiler. |
| 01:52:34 | OrionPK | Varriount this is a compiler error.. |
| 01:52:37 | OrionPK | try this |
| 01:52:39 | Demos | I wish it was that easy on windows |
| 01:52:45 | OrionPK | line 37 replace with echo read[string](log) |
| 01:52:50 | Varriount | Demos, ? |
| 01:52:55 | OrionPK | isntaed of log.read[string]() |
| 01:53:07 | Demos | windows installation and path handling is a pain |
| 01:53:18 | Demos | and you need to switch a crapton of stuff for each compiler |
| 01:53:23 | Demos | it is just annoying |
| 01:53:31 | Varriount | Demos, I have 2 main batch files I use, so that I can use either 32 or 64 bit compilers. |
| 01:53:46 | Demos | same, but I keep forgetting which is which |
| 01:53:59 | Varriount | I just named them 32 and 64 |
| 01:54:13 | OrionPK | Varriount updated gist |
| 01:54:16 | Demos | honestly I should probably invest more time into setting that stuff up |
| 01:54:19 | Varriount | OrionPK, it's an intentional compiler error |
| 01:54:28 | Demos | too used to just cmake .. boot visual studio and go |
| 01:55:38 | Demos | but yeah, I would think nimrod's debug mode in a VM running on javascript would be faster than a c++ compiler |
| 01:56:06 | OrionPK | looks that wa |
| 01:56:11 | OrionPK | i submitted a bug, hopefully not a dupe |
| 01:56:26 | Varriount | OrionPK, https://gist.github.com/Varriount/7424009 |
| 01:57:11 | Varriount | OrionPK, line 35 of seminst.nim is |
| 01:57:13 | Varriount | elif t.kind == tyGenericParam: |
| 01:57:13 | Varriount | InternalError(a.info, "instantiateGenericParamList: " & q.name.s) |
| 01:58:20 | Varriount | Where 't' is a node retrieved from some sort of type table |
| 01:58:52 | OrionPK | i dont understand why soemthing(obj) works and obj.something() fails |
| 01:58:59 | OrionPK | it shouldnt be that way |
| 01:59:28 | Varriount | OrionPK, it's the order in which types are inferred. |
| 01:59:42 | Varriount | I think |
| 01:59:46 | OrionPK | there is no inference necessary, I'm explcitly stating the generic type |
| 02:00:34 | Varriount | Let me look at the code a bit. |
| 02:02:15 | Varriount | OrionPK, it might be related to why obj.toSeq and toSeq(obj) sometimes work/don't work |
| 02:04:59 | Varriount | AST-Wise, the two expressions are different. |
| 02:11:34 | OrionPK | hm |
| 02:12:41 | Varriount | I'm thinking that the call is being evaluated before the generic type can be spread throughout, though that's a guess, since I have no clue as to how nimrod calculates generic call types and such |
| 02:16:55 | OrionPK | im sure araq could tell us why it's impossible to fix and correct the way it is in a few seconds anyway :) |
| 02:17:19 | Varriount | OrionPK, Araq isn't here. His internet is down. |
| 02:17:31 | OrionPK | i know he isnt, it's also in the wee hours in germany |
| 02:24:07 | * | Varriount misses Germany |
| 02:25:09 | Varriount | OrionPK, why don't you have nimrod built in debug mode? |
| 02:28:03 | OrionPK | because i got sick of waiting for it to build |
| 02:28:14 | OrionPK | takes a lot longer to koch without release mode |
| 02:29:45 | Varriount | It takes, like, less than 2 minutes for me :/ |
| 02:30:13 | Varriount | Hint: operation successful (65828 lines compiled; 44.252 sec total; 274.280MB) [SuccessX] |
| 02:40:48 | * | mflamer_ joined #nimrod |
| 02:45:12 | Varriount | Hi MFlamer |
| 02:49:00 | * | MFlamer quit (Ping timeout: 244 seconds) |
| 03:22:37 | Varriount | OrionPK, Thank you |
| 03:29:47 | * | brson quit (Ping timeout: 260 seconds) |
| 03:33:01 | fowl | OrionPK, are you talking about templates |
| 03:33:07 | fowl | obj.foo() vs foo(obj) |
| 03:34:05 | Varriount | fowl, it's a generic |
| 03:34:35 | Varriount | Though a generic is, conceptually, a kind of template |
| 03:35:49 | fowl | ? |
| 03:35:54 | fowl | is there problem with it or not |
| 03:36:52 | Varriount | fowl, there is, but it has something to do with the compiler internals |
| 03:37:34 | Varriount | The problem is that I am unable to determine where two similar statements deviate when they are being semantically processed. |
| 03:39:32 | * | Demos quit (Quit: Konversation terminated!) |
| 04:10:20 | Varriount | OrionPK, if you're still up, I've kinda identified the problem, or at least, the general reason what you want won't work. |
| 04:11:31 | OrionPK | yah im still around |
| 04:11:35 | OrionPK | in and out though |
| 04:11:39 | Varriount | OrionPK, Here's my theory. Your first call, which the compiler sees as this: |
| 04:11:56 | Varriount | Call |
| 04:11:56 | Varriount | BracketExpr |
| 04:11:56 | Varriount | Ident !"readLog" |
| 04:11:56 | Varriount | Ident !"string" |
| 04:11:56 | Varriount | Ident !"log" |
| 04:12:57 | Varriount | The compiler looks at readLog, a generic proc, and it's paired type, string. It creates a concrete proc with all the types filled with string |
| 04:13:32 | Varriount | It then fills out the remaining argument, the log type. |
| 04:13:54 | Varriount | OrionPK, Here is what the second call looks like to the compiler: |
| 04:14:14 | Varriount | BracketExpr |
| 04:14:15 | Varriount | DotExpr |
| 04:14:15 | Varriount | Ident !"log" |
| 04:14:15 | Varriount | Ident !"readLog" |
| 04:14:15 | Varriount | Ident !"string" |
| 04:14:28 | OrionPK | interesting.. |
| 04:15:13 | OrionPK | but how that information is treated is at issue, isn't it? |
| 04:15:32 | Varriount | In this case, the compiler sees that readLog, a generic procedure, is being called with log, a concrete type, as it's argument. |
| 04:16:16 | Varriount | But it hasn't *filled out* readLog to become a concrete procedure, it still has that generic return type |
| 04:16:59 | Varriount | After that, I'm a bit unsure, but guessing from the traceback, it thinks that you're trying to access the result via [] |
| 04:18:27 | Varriount | OrionPK, see, your second call could also be interpreted as, say, a function accepting a log, and returning an array. |
| 04:18:53 | Varriount | OrionPK, In any case, the type isn't being filled out for you read proc |
| 04:18:54 | OrionPK | shouldnt be |
| 04:19:18 | OrionPK | well, maybe araq will have some thoughts next time he's about |
| 04:19:55 | Varriount | OrionPK, I have to go to bed now (exam tomorrow) but I'll continue to dig into this problem. |
| 04:20:18 | fowl | instantiating a generic like this: obj.f[ty] does not work right now |
| 04:20:21 | Varriount | I may not be able to fix it, but I might be able to dig up enough information to help Araq |
| 04:20:42 | fowl | if you have to explicitly say the type then you have to call it like f[ty](obj) |
| 04:23:50 | OrionPK | okay, thanks for taking a look Varriount |
| 04:24:16 | OrionPK | fowl yeah thats what I've noticed |
| 04:24:18 | OrionPK | this is a known issue? |
| 04:24:33 | fowl | known behavior, im not sure i'd call it an issue |
| 04:24:39 | OrionPK | figures |
| 04:24:42 | OrionPK | why isnt it an issue? |
| 04:24:52 | fowl | i'd definitely like it to work with dot syntax |
| 04:24:57 | Varriount | OrionPK, my please. It's helped me get better acquainted with the compiler internals. |
| 04:25:02 | Varriount | *pleasure |
| 04:25:18 | OrionPK | glad it was productive for you :) |
| 04:27:39 | Varriount | If anyone is interested, look in semexpr, line 1923 |
| 04:27:50 | xenagi | what is it? |
| 04:28:10 | Varriount | That is where the decision is made to either treat something as a generic instanciation, or an array access |
| 04:28:54 | Varriount | Nimrod is surprisingly readable, unlike *some* languages I know *cough*c++*cough* |
| 04:28:57 | OrionPK | suppose it's too early to check |
| 04:29:01 | OrionPK | if it's a type |
| 04:29:12 | OrionPK | not an variable identifier or const |
| 04:29:26 | Varriount | OrionPK, look at those AST parts I printed above |
| 04:29:49 | OrionPK | I'm running out of time tonight |
| 04:30:32 | Varriount | Goodnight guys |
| 04:31:40 | OrionPK | night |
| 04:34:44 | * | brson joined #nimrod |
| 04:43:16 | * | brson quit (Ping timeout: 268 seconds) |
| 04:47:15 | * | brson joined #nimrod |
| 04:49:12 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 05:02:15 | * | ics joined #nimrod |
| 05:19:56 | * | OrionPK quit (Read error: Connection reset by peer) |
| 05:32:51 | * | webskipper quit (Ping timeout: 246 seconds) |
| 05:40:35 | * | xenagi quit (Quit: Leaving) |
| 05:59:03 | * | filwit quit (Quit: Leaving) |
| 07:11:55 | * | dymk quit (Ping timeout: 260 seconds) |
| 07:31:24 | * | brson quit (Read error: Connection reset by peer) |
| 07:31:35 | * | brson joined #nimrod |
| 07:43:21 | * | dyu joined #nimrod |
| 07:52:26 | * | dymk joined #nimrod |
| 07:59:32 | * | delian2 quit (Remote host closed the connection) |
| 08:01:03 | * | delian2 joined #nimrod |
| 09:03:47 | * | NimBot joined #nimrod |
| 09:15:51 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:16:24 | * | capisce_ quit (Ping timeout: 272 seconds) |
| 09:17:10 | * | capisce joined #nimrod |
| 09:23:14 | * | mflamer_ quit (Ping timeout: 268 seconds) |
| 09:27:57 | * | BitPuffin joined #nimrod |
| 09:30:07 | BitPuffin | good morning guys! |
| 09:33:21 | * | CarpNet joined #nimrod |
| 09:46:46 | * | Jackneill joined #nimrod |
| 09:54:51 | BitPuffin | ping zahary |
| 10:02:38 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 10:08:40 | * | Araq_ joined #nimrod |
| 10:13:26 | * | mkb quit (Ping timeout: 240 seconds) |
| 10:14:00 | * | mkb joined #nimrod |
| 10:22:44 | * | EXetoC joined #nimrod |
| 10:38:35 | * | Araq_ quit (Read error: Connection timed out) |
| 10:39:56 | * | Araq_ joined #nimrod |
| 10:49:52 | * | musicalchair joined #nimrod |
| 11:52:04 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 11:59:01 | * | BitPuffin joined #nimrod |
| 12:28:35 | * | eigenlicht joined #nimrod |
| 12:28:41 | * | brson joined #nimrod |
| 12:29:57 | BitPuffin | my god imagine the ddos github would experience if nimrod suddenly exploaded in popularity and everybody clones the compiler repo |
| 12:34:23 | * | dyu quit (Disconnected by services) |
| 12:35:00 | * | dyu_ joined #nimrod |
| 12:39:01 | eigenlicht | would be shame if someone...did a git push --force before that ;) |
| 12:44:03 | * | Phil joined #nimrod |
| 12:46:26 | Phil | Hi, just wondering if anyone can give me some pointers. I'm trying out nimrod, currently trying to get the httpserver2.nim example to work, however when I run it, I get "accept: ./index.html" or what ever I request, and the connection hangs indefinately and no page is served. |
| 12:46:26 | * | EXetoC quit (Read error: Connection reset by peer) |
| 12:48:16 | BitPuffin | Phil: code? errors? |
| 12:50:58 | Phil | It's the httpserver2.nim file in the "examples" directory of the nimrod source distribution, and unfourtunately there is no error emited, if you open a web browser and point it at the http server you see output in the console "accept: ./index.html" so you know it's found the server, but the connection hangs from that point, nothing is reveived back |
| 12:50:58 | Phil | by the browser, and it never times out. |
| 12:51:53 | BitPuffin | hmm interesting |
| 12:52:13 | BitPuffin | Phil: you should use the latest git version of nimrod though |
| 12:52:56 | Phil | Ok, I can try that, are there many changed since the 0.9.2 release? |
| 12:54:00 | BitPuffin | Phil: yep |
| 12:54:11 | BitPuffin | not many libs are compatible with 0.9.2 even anymore :P |
| 12:54:18 | BitPuffin | because most nimrod users use the git version |
| 12:54:26 | BitPuffin | well okay many libs are compatible |
| 12:54:32 | BitPuffin | but a lot of them aren't |
| 12:55:09 | Phil | oh right, didn't know that, I presume the main branch is kept in a good working state then |
| 12:55:21 | BitPuffin | Phil: for the most part yes |
| 12:56:10 | Phil | I'll check that out then and see how that goes first. |
| 12:58:06 | * | CarpNet quit (Remote host closed the connection) |
| 12:58:11 | Phil | Thanks for the tips. |
| 12:58:56 | BitPuffin | no problem |
| 13:04:47 | * | EXetoC joined #nimrod |
| 13:04:56 | BitPuffin | hey EXetoC! |
| 13:07:32 | EXetoC | hi |
| 13:09:34 | * | Ricky_Ricardo joined #nimrod |
| 13:09:37 | BitPuffin | EXetoC: do you know what it means when there is a ! in front of a string |
| 13:11:22 | EXetoC | BitPuffin: grep "\`!\`" **/*.nim |
| 13:11:28 | EXetoC | user-defined operators. nothing else I think |
| 13:11:37 | EXetoC | in macros.nim and pegs.nim |
| 13:12:53 | BitPuffin | EXetoC: really? operators? |
| 13:12:56 | BitPuffin | http://nimrod-code.org/macros.html |
| 13:13:06 | BitPuffin | nnkAddr(nnkIdent(!"x")) |
| 13:13:11 | BitPuffin | x is not an operator there |
| 13:14:24 | EXetoC | no but '!' is |
| 13:15:00 | BitPuffin | EXetoC: sure but that doesn't say what it does when it is in front of a string |
| 13:15:09 | BitPuffin | constructs an identifier from the string s |
| 13:15:11 | BitPuffin | ah |
| 13:15:13 | BitPuffin | okay |
| 13:22:19 | * | webskipper joined #nimrod |
| 13:22:37 | * | CarpNet joined #nimrod |
| 14:01:17 | Phil | Still having the same problem with the examples/httpserver2.nim file, it never serves a page, it just hangs when you make a GET request. |
| 14:02:20 | BitPuffin | Phil: why don't you have a look at jester instead? |
| 14:02:51 | BitPuffin | EXetoC: why don't you teach yourself ack? :P |
| 14:03:26 | Phil | Worth a try, I was just looking for a good bit of example code to test out the possibilities |
| 14:03:43 | BitPuffin | Phil: there are plenty :) |
| 14:04:08 | Phil | is it a seperate package I can find somewhere? |
| 14:06:41 | * | Ricky_Ricardo quit (Quit: Ricky_Ricardo) |
| 14:09:50 | * | EXetoC quit (Ping timeout: 240 seconds) |
| 14:11:10 | BitPuffin | Phil: you mean jester? |
| 14:11:29 | * | EXetoC joined #nimrod |
| 14:11:41 | Phil | yes, I've been looking around, I presume I install babel and then use that to get it? |
| 14:12:09 | BitPuffin | Phil: yeah it's a babel package |
| 14:12:15 | Phil | cool |
| 14:12:42 | EXetoC | BitPuffin: I don't think I've needed it |
| 14:18:32 | BitPuffin | EXetoC: well of course you don't *need* it but it's a lot nicer |
| 14:18:57 | BitPuffin | ack --nimrod foo |
| 14:18:59 | BitPuffin | :P |
| 14:19:14 | BitPuffin | no more **/*.nim biz |
| 14:19:30 | BitPuffin | that --nimrod flag is user defined so you can make it --nim etc |
| 14:19:41 | BitPuffin | so now when I do ack --nimrod it searcher .nim and .tmpl |
| 14:22:04 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 14:22:36 | * | BitPuffin joined #nimrod |
| 14:25:38 | EXetoC | I've aliased my most common glob expression |
| 14:26:22 | EXetoC | *expressions |
| 14:28:34 | * | OrionPK joined #nimrod |
| 14:30:12 | EXetoC | grpi foo ggni |
| 14:34:51 | webskipper | I asked about call-by-* yesterday in #python. Its more about call-by-object than call-by-value or call-by-reference as default behaviour. And it depend on what yo do with your objects within the function. |
| 14:40:58 | EXetoC | are you referring to the fact that assigning to the object won't affect the caller, but modifying one of the fields of said parameter will? |
| 14:43:38 | webskipper | EXEtoC: y I mean the semantics. For example you have a list as parameter. pop() from it and its state is viewable after the function ist terminated. |
| 14:48:47 | EXetoC | right |
| 15:07:45 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 15:09:49 | Varriount | In python, everything is passed as a reference. |
| 15:10:50 | Varriount | webskipper, whether a list is modified after pop() is a case of function design, not semantics |
| 15:16:04 | webskipper | Varriount: funny, say that in #python. Lot of guys there said its call-by-value. Other said call-by-object. |
| 15:17:05 | webskipper | Varriount: call-by-* its more a concept for the programmer than the concrete implementation. |
| 15:17:21 | Varriount | I don't know what the official term is, but I do know this: Arguments passed to a function act as if whatever is passed to the function is assigned to a local variable |
| 15:17:41 | EXetoC | is call by reference accurate? because the caller isn't affected by a del or an assignment |
| 15:19:00 | Varriount | Thus, in python, if you assign a new value to an argument via =, and the left side is not an attribute of the argument, but the argument itself, then only the local variable is overwritten. |
| 15:20:33 | Varriount | "def foo(a, b): a = b" will not, in fact, do anything, as the assignment only affects the local variable "a". "def foo(a, b): a.c = b" on the other hand, does do something, as it affects the attributes of the object referred to by the variable |
| 15:22:10 | EXetoC | that's what we said, yes |
| 15:22:41 | Varriount | EXetoC, again, I don't know the terms, just the behavior. |
| 15:23:02 | Varriount | Also, I tend towards the verbose. It's a bad habit, I know. |
| 15:28:14 | * | Endy joined #nimrod |
| 15:29:27 | EXetoC | so it's neither one of those, and I don't know if pass-by-object has an official meaning |
| 15:45:49 | Phil | I noticed you discussion above. With python everything is passed by reference, but certain types of object are imuatable, e.g. int, bool, tuple where as others are mutable, e.g. lists, dicts, so if you assign to an imutable you'll actually get a new object and any thing which referenced the old one will still point at the old thing. |
| 15:47:58 | * | [1]Endy joined #nimrod |
| 15:48:04 | * | mflamer joined #nimrod |
| 15:49:49 | EXetoC | I've read twice that it's not pass-by-reference, but if you're correct, then it's a fairly fuzzy term |
| 15:50:10 | Varriount | Pass-By-Python |
| 15:51:23 | * | Endy quit (Ping timeout: 245 seconds) |
| 15:51:23 | * | [1]Endy is now known as Endy |
| 15:51:47 | Phil | You can see what's going on if you use the id() function. I'll do an quick example... |
| 15:52:59 | Phil | Try this out: def fn(b): return id(b); a = 1; assert id(a) == fn(a) |
| 15:58:17 | * | mflamer quit (Ping timeout: 272 seconds) |
| 16:05:38 | Phil | Can anyone point me towards any large self-contained example programs witten in nimrod? |
| 16:05:41 | * | brson quit (Ping timeout: 252 seconds) |
| 16:08:27 | * | [1]Endy joined #nimrod |
| 16:11:17 | * | Endy quit (Ping timeout: 248 seconds) |
| 16:11:18 | * | [1]Endy is now known as Endy |
| 16:12:06 | EXetoC | I don't know what that proves. I still see it as some kind of value/reference hybrid |
| 16:19:48 | Phil | It's probably not a good fit for either term, since everything is an object in python it is just passing those objects around and each object has a unique id, so by code above proves you are dealing with the very same object inside the function that you were dealing with outside the function. |
| 16:20:09 | webskipper | Phil: pass-by-python I like :D |
| 16:21:17 | * | MFlamer joined #nimrod |
| 16:23:45 | Phil | Most accurately term I can think of is "pass-by-assignment" since that is what happens internally, it's just like you did "b = a" in my example above, in which case both a and b point to the same object in memory, but if you were to do b = 2 since the object b was point to is imutable you'll get a new object (and id()) and b will reference it, whic |
| 16:23:45 | Phil | h a still references the original object which hasn't changed in value. |
| 16:24:43 | webskipper | fine - we should close this topic now :D |
| 16:27:41 | * | XAMPP-8 joined #nimrod |
| 16:28:27 | * | XAMPP_8 joined #nimrod |
| 16:28:58 | * | [1]Endy joined #nimrod |
| 16:30:38 | EXetoC | :-) |
| 16:31:50 | * | XAMPP-8 quit (Ping timeout: 240 seconds) |
| 16:32:07 | * | Endy quit (Ping timeout: 272 seconds) |
| 16:32:08 | * | [1]Endy is now known as Endy |
| 16:36:05 | dom96 | hey Phil. The httpserver2 example is most likely pretty broken. Look at the httpserver module instead. |
| 16:36:42 | Phil | dom96: ok thanks |
| 16:38:06 | Phil | dom96: I got jester working in the end, but I'm still looking for a good self contained example of a large program that I can use to test out on a small embedded linux system. |
| 16:38:31 | dom96 | babel sounds like a good candidate for that |
| 16:39:51 | Phil | not sure about the dependancies though does it need anything, like git, I'd need to cross-compile a load of other stuff, was hoping to find something mainly self-contained |
| 16:40:27 | dom96 | hrm, it needs openssl too. |
| 16:40:59 | * | XAMPP_8 quit (Ping timeout: 240 seconds) |
| 16:42:24 | * | MFlamer quit (Remote host closed the connection) |
| 16:44:33 | * | [1]Endy joined #nimrod |
| 16:46:59 | * | Endy quit (Ping timeout: 240 seconds) |
| 16:47:00 | * | [1]Endy is now known as Endy |
| 16:58:24 | * | Phil left #nimrod (#nimrod) |
| 17:04:56 | * | [1]Endy joined #nimrod |
| 17:08:35 | * | Endy quit (Ping timeout: 272 seconds) |
| 17:08:36 | * | [1]Endy is now known as Endy |
| 17:25:25 | * | [1]Endy joined #nimrod |
| 17:27:44 | * | Varriount wonders why nimrod can echo() faster than python |
| 17:28:11 | * | Endy quit (Ping timeout: 252 seconds) |
| 17:28:12 | * | [1]Endy is now known as Endy |
| 17:30:55 | * | shodan45 joined #nimrod |
| 17:45:38 | * | [1]Endy joined #nimrod |
| 17:48:45 | * | Endy quit (Ping timeout: 245 seconds) |
| 17:48:45 | * | [1]Endy is now known as Endy |
| 17:50:58 | * | [1]Endy joined #nimrod |
| 17:53:51 | * | Endy quit (Ping timeout: 252 seconds) |
| 17:53:52 | * | [1]Endy is now known as Endy |
| 18:02:47 | * | EXetoC quit (Ping timeout: 246 seconds) |
| 18:05:20 | * | MFlamer joined #nimrod |
| 18:08:33 | * | Araq0 joined #nimrod |
| 18:09:45 | * | dyu_ quit (Quit: Leaving) |
| 18:10:39 | Araq0 | dom96: pm me please |
| 18:11:36 | * | [1]Endy joined #nimrod |
| 18:14:20 | * | Endy quit (Ping timeout: 246 seconds) |
| 18:14:21 | * | [1]Endy is now known as Endy |
| 18:18:50 | Varriount | Araq0, you're alive! |
| 18:20:07 | Araq0 | Yeah but typing on this device sucks |
| 18:20:43 | Varriount | You could always USB Tether to your laptop or desktop |
| 18:21:05 | Araq0 | I guess i could |
| 18:21:11 | * | Mat2 joined #nimrod |
| 18:21:13 | Varriount | :3 |
| 18:21:16 | Mat2 | hi all |
| 18:21:26 | Varriount | Hello! |
| 18:21:28 | Araq0 | Hi mat2 |
| 18:21:47 | Mat2 | hi Araq and Varriount |
| 18:22:01 | Varriount | So, Araq0, how is the no-internet thing going? |
| 18:22:45 | Araq0 | Very well i also have no tv so all i can do is drinking |
| 18:22:56 | Mat2 | ?? |
| 18:24:12 | Varriount | Araq0, while you've been away, I fixed generic lambdas crashing the compiler, and am investigating how to fix object.genericProc[T] |
| 18:24:54 | Araq0 | That only needs a proper error msg |
| 18:25:46 | Varriount | Bhy not fix it so that the generic actually works? Right now, nimrod just thinks that the [] is an array access |
| 18:26:19 | Araq0 | A.b[i] is clearly oh wait nevermind |
| 18:26:59 | * | OrionPK quit (Ping timeout: 250 seconds) |
| 18:27:04 | Varriount | OrionPK and I dug into it a bit. |
| 18:28:45 | Araq0 | Great |
| 18:29:17 | Varriount | It's because when semExpr is called, when trying to determine if a BracketExpr refers to a generic, it uses qualifiedLookup on the first child node |
| 18:29:32 | Varriount | And in that case, the child node is a dotExpr |
| 18:30:13 | Araq0 | Told ya. Every usage of *lookup is suspicious |
| 18:30:31 | Varriount | I've been trying to get qualifiedLookup to accept the last child of the dotExpr - an Ident node that holds the name of the generic Param |
| 18:30:54 | Araq0 | Argh |
| 18:30:58 | Varriount | However I get a wierd error in system.nim, in some branching procedure |
| 18:31:13 | Araq0 | Dont patch lookup |
| 18:31:26 | Varriount | I'm not. I'm trying to modify semExpr |
| 18:31:36 | Araq0 | Good |
| 18:31:59 | * | [1]Endy joined #nimrod |
| 18:32:15 | Varriount | Araq0, any idea why a call to qualifiedLookup would yield an attribute error for the name "son" in system.nim? |
| 18:32:51 | Varriount | Specifically, c:\64\nimrod\lib\system.nim(2203, 19) Error: undeclared identifier: 'sons' |
| 18:33:36 | Araq0 | You cant lookup a field via lookups |
| 18:34:20 | * | ics joined #nimrod |
| 18:34:31 | MFlamer | I've been digging deep in the compiler lately. I'm getting pretty familiar with how it all works and should be able to start helping with some of these problems soon. |
| 18:34:45 | * | Varriount hi-fives MFlamer |
| 18:35:01 | * | Endy quit (Ping timeout: 244 seconds) |
| 18:35:01 | * | [1]Endy is now known as Endy |
| 18:35:38 | Araq0 | I will have more time and perhaps even internet by the end of the week |
| 18:35:56 | Mat2 | just beside: How complex you guys want to get with the compiler ? (I mean, at some stage the intrinsic complexity can lead to chaotic behaviour and as result maybe only psychological analysis will help undestand it's nature) |
| 18:36:15 | Varriount | Mat2, I want to compiler to work. |
| 18:36:34 | * | webskipper quit (Ping timeout: 244 seconds) |
| 18:36:44 | Varriount | In this case, I will likely be adding less than 20 lines of code, most of it conditions |
| 18:36:49 | Varriount | With comments |
| 18:37:26 | * | filwit joined #nimrod |
| 18:37:27 | Araq0 | Expect me to rewrite it |
| 18:37:59 | * | CarpNet quit (Quit: Leaving) |
| 18:38:20 | Varriount | I always do. I've learned that no matter what I write, someone will always write it in a better way. The point is to make a start. |
| 18:39:07 | Araq0 | Sure. Your doing great work anyway |
| 18:39:24 | Varriount | Araq, does the prefix "sk" mean anything in particular? |
| 18:39:35 | filwit | symbole-kind |
| 18:39:40 | filwit | symbol* |
| 18:39:44 | Varriount | Ah, thanks |
| 18:41:29 | filwit | np :) |
| 18:42:13 | Araq0 | Btw do you guys prefer suffixes instead? Procsym? |
| 18:42:56 | filwit | i want 5 layers of nested hierarchy + 3 prefixs and 2 post-fixes |
| 18:43:14 | reactormonk | Araq0, where are the tests for the idetools? |
| 18:43:19 | Varriount | Araq, as long as the prefixes are explained somewhere, I'm fine with them. |
| 18:43:22 | filwit | (in reality, not sure what exactly you're asking) |
| 18:43:39 | Varriount | Anyway, got to go, I have class in 15 minutes, and need to print out a paper. |
| 18:43:52 | filwit | bye, Varriount |
| 18:44:18 | Varriount | Before I go , anyone care to explain why this doesn't work? |
| 18:44:20 | Varriount | if not isNil(n.sons[0]) and n.sons[0].kind in {nkDotExpr}: |
| 18:44:20 | Varriount | var g = qualifiedLookup(c, n.sons[0].sons[1]) |
| 18:44:39 | filwit | what is there to explain? |
| 18:44:40 | Araq0 | Reactormonk: tests/caas |
| 18:44:50 | Varriount | It gives me an error in system.nim |
| 18:44:59 | filwit | which line? |
| 18:45:21 | Varriount | 2203 |
| 18:45:32 | filwit | no i mean above, first or second? |
| 18:45:33 | reactormonk | Araq0, sweet |
| 18:45:57 | filwit | Varriount: i'm not sure what error it's giving you is all i'm saying |
| 18:46:02 | Araq0 | I told you qualifiedlookup doesnt supprt arbitrary nkdotexpr |
| 18:46:14 | filwit | ahh.. |
| 18:48:28 | filwit | Araq0: i'm not sure if I was included in your question back there, but honestly I probably do prefer 'ProcSym' to 'SymProc'. Just my opinion. |
| 18:49:39 | Araq0 | I meant skproc vs procsym |
| 18:50:29 | dom96 | The latter is more descriptive than the former. |
| 18:51:20 | filwit | Araq0: nevermind then. personally i would prefer: SymKind.Proc here, but otherwise i prefer the 'sk' prefix cause it's common among all of those enums |
| 18:51:39 | Araq0 | Alright. Might keep it in mind the next time i start from scratch |
| 18:52:16 | Araq0 | (Which is never) |
| 18:52:30 | * | [1]Endy joined #nimrod |
| 18:52:50 | filwit | Araq0: not sure what you're talking about (but i assume it's my 'something.somethingelse' preference :) |
| 18:53:54 | Araq0 | Yeah of course. Who doesnt |
| 18:55:15 | filwit | Araq0: .. i'm confused by that last comments. but regardless, i state my preference to start a debate or try and convince you you should add it or anything. |
| 18:55:28 | filwit | Araq0: sorry, i DIDN"T** |
| 18:55:33 | * | Endy quit (Ping timeout: 248 seconds) |
| 18:55:34 | * | [1]Endy is now known as Endy |
| 18:55:36 | filwit | Araq: typo |
| 18:55:59 | * | OrionPK joined #nimrod |
| 18:56:22 | Araq0 | I know. I asked for your opinion |
| 18:57:17 | filwit | Araq0: ah, okay. Sorry for the confusion. Like I said, in terms of realistic Nimrod options, i prefer the way Nimrod currently does it (with the 'sk' prefix) |
| 18:57:36 | Araq0 | And that last comment was subtle sacarsm, sorry |
| 18:57:45 | MFlamer | The C generator creates some functions in the C scoure like "reprEnum" & "reprInt". For some reason I can't find where these are defined. |
| 18:58:05 | MFlamer | I like the sk, ty, nk prefix |
| 18:58:17 | filwit | Araq0: yeah i got it now. sometimes the subtle comments don't translate over the web correctly, my mistake. |
| 18:59:00 | Varriount | Araq, but I'm giving qualifiedLookup an nkIdent node |
| 18:59:56 | Araq0 | Mflamer compilerprocs are not mangled |
| 18:59:59 | filwit | Varriount: "... and n.sons[0].kind in {nkDotExpr}:" only allows nkDotExpr through |
| 19:00:22 | Araq0 | Varriount the worse |
| 19:01:26 | * | Endy quit (Ping timeout: 240 seconds) |
| 19:01:34 | * | Varriount is rewriting |
| 19:01:43 | MFlamer | Araq0: I'm not sure what that means here |
| 19:02:26 | MFlamer | what is this line doing? N_NIMCALL(NimStringDesc*, reprEnum)(NI e_69477, TNimType* typ); |
| 19:02:26 | Mat2 | filwit: What's your native language ? |
| 19:02:44 | filwit | Mat2: programming or IRL ? |
| 19:03:20 | filwit | Mat2: i dont' really have a "native" programming language, but I'm from the US and only speak English |
| 19:04:04 | filwit | hey folks, if anyone named something like "edA-qa mort-ora-y" shows up, it's probably the Leaf Language developer |
| 19:05:00 | Araq0 | Ok. I am sure i can convince him to work on nimrod instead |
| 19:05:13 | filwit | I've been talking to him a little, (he's interested in Nimrod's GC design), and invited him to stop by and chat sometime. |
| 19:05:30 | Mat2 | filwit: programming |
| 19:05:46 | filwit | Araq0: that would be cool :) lol, but i'm really just giving you a heads-up in case he comes around |
| 19:06:16 | * | BitPuffin joined #nimrod |
| 19:06:27 | filwit | Mat2: I've used mostly Javascript (HTML, etc..), D, & C# |
| 19:06:30 | Varriount | Hi BitPuffin! |
| 19:07:12 | Mat2 | hi BitPuffin |
| 19:07:23 | Araq0 | Mat2: about the complexity... there is no way going back. As soon as you have static typing you want generics etc |
| 19:08:09 | filwit | Araq0: I have been arguing some of the benefits of Nimrod's features to him (the leaf guy), and I think he was interested in knowing more about Nimrod, so he might show. |
| 19:08:23 | Mat2 | Araq0: I know, the price to pay if you start this route |
| 19:08:32 | Araq0 | And now people kind of expect dependent typing |
| 19:08:44 | Varriount | What is dependant typing> |
| 19:08:47 | Varriount | *? |
| 19:08:49 | filwit | ^ ? |
| 19:09:28 | filwit | give Varriount, filwit: http://en.wikipedia.org/wiki/Dependent_type |
| 19:09:52 | Araq0 | what used to novel and complex is now common |
| 19:09:54 | dom96 | !seen mortoray |
| 19:09:54 | NimBot | I have not seen mortoray |
| 19:10:06 | dom96 | Looks like he has not been here yet. |
| 19:10:09 | Mat2 | hi dom96 |
| 19:10:17 | Araq0 | And thus not regarded as complex anymore |
| 19:10:21 | dom96 | hi Mat2 |
| 19:11:09 | filwit | dom96: okay thanks. Just wanted to know. |
| 19:11:29 | dom96 | of course my guess of his nick could be wrong heh |
| 19:11:31 | Varriount | Araq0, -> https://gist.github.com/Varriount/7436886 |
| 19:12:24 | Varriount | Even though I check that the kind of node passed to lookupQualified is a nkIdent node, it still errors. :/ |
| 19:12:35 | filwit | dom96: i'm worried he's going to show up, then Araq is going to tell him how crap he thinks Leaf is or something, and then the guy will hate us all. lol |
| 19:12:51 | Varriount | ^ Programmers are not known for their tact. |
| 19:13:04 | filwit | lol, true enough |
| 19:13:11 | dom96 | filwit: Come onnn, Araq would never do such a thing... surely... :P |
| 19:13:12 | Mat2 | what mean tact ? |
| 19:13:22 | OrionPK | Araq especially |
| 19:13:31 | filwit | dom96: lol |
| 19:14:21 | filwit | Mat2: tact means sensitivity to others feelings |
| 19:14:37 | filwit | Mat2: basically |
| 19:15:07 | Araq0 | I dont know leaf |
| 19:15:25 | filwit | Araq0: you don't read Phoronix? |
| 19:15:28 | Araq0 | That helps to stay polite i guess |
| 19:15:35 | filwit | LOL |
| 19:16:17 | Mat2 | filwit: ah, this kind of tactic ! |
| 19:16:33 | filwit | Araq0: Phoronix did a story on Leaf "Soon to be great programming language".. i was thinking "damn, too bad we can't get him to write about Nimrod" |
| 19:17:04 | filwit | Araq0: http://leaflang.org/ |
| 19:17:54 | filwit | for some reason, i anticipate you will really hate the language.. |
| 19:17:55 | dom96 | We just need to bribe phoronix. |
| 19:18:34 | Trixar_za | Finally a use for the surplus goat whores |
| 19:18:41 | Trixar_za | Only works on the Welsh, but still |
| 19:18:50 | filwit | dom96: we could just write a good article on how Nimrod's macros allow you to build your own type-hierarchy or something, then submit it to Phoronix |
| 19:18:51 | dom96 | Araq0: Remember when reactormonk wanted to give you a bitcoin for something? You should see how much one is worth now :P |
| 19:19:29 | dom96 | Well I think that what I discussed with BitPuffin is a good idea. We need an article per week. |
| 19:19:44 | dom96 | Doesn't matter where, as long as someone writes something about Nimrod and gets it to reddit/HN. |
| 19:21:10 | * | webskipper joined #nimrod |
| 19:21:10 | Mat2 | I can write about my progress if this would help (somehow I fear most readers wouldn't understand what I write however) |
| 19:21:22 | filwit | dom96: actually, i was thinking about what factors limit Nimrod's popularity recently, and I'm thinking docs is big area that could be cleaned up. Also, Nimrod simply needs better IDE tools, that takes a lot of work, but perhaps building Aporia and distributing the bins would help. |
| 19:21:46 | dom96 | filwit: You're our designer, design nicer docs :P |
| 19:22:02 | Varriount | Use the same theme as the main website. |
| 19:22:24 | Mat2 | as complexity seem to be favoured, how about a Eclipse plugin ? |
| 19:22:27 | dom96 | hrm, I dunno. I think the design should be different. |
| 19:22:34 | dom96 | Mat2: Bleh. |
| 19:23:23 | filwit | dom96, Varriount: well It's not just about visuals.. the docgen needs to be updated to have better category searching. |
| 19:23:56 | filwit | dom96, Varriount: for instance, often i want to find "all procs that modify a <someType>" |
| 19:24:09 | Araq0 | Mat2: complexity doesnt mean "broken", though the correlation is high |
| 19:24:22 | filwit | dom96, Varriount: but I have to hunt through a giant list of procs which are often duplicated names and stuff |
| 19:25:06 | dom96 | filwit: You can certainly figure out how to get the docgen to do that. |
| 19:25:07 | filwit | dom96, Varriount: i can design the visuals for the docs quickly, but I've never looked at the docgen at all |
| 19:25:28 | filwit | dom96: yeah, i figure it's probably not hard. I'll take a look later. |
| 19:26:39 | reactormonk | dom96, now we're talking about bitcents ^^ |
| 19:26:49 | dom96 | filwit: I think you should do a mock up of how you want it to look and then we can decide whether it will be easy to do. |
| 19:27:40 | Mat2 | Araq0: A SM way of programming is always, ehm "broken" (there like it) |
| 19:27:48 | filwit | dom96: yeah that's my plan. I'll try and make something later this week. |
| 19:33:18 | filwit | dom96: btw, I like the code-highlighting on your blog. You can bring that to the docs? |
| 19:34:07 | dom96 | filwit: Sure. It's one of Pygment's themes transformed to work with Nimrod's highlighting engine. |
| 19:34:12 | Araq0 | Varriount i read your gist but your solution is wrong |
| 19:34:33 | Araq0 | Fundamentally wrong |
| 19:34:38 | filwit | dom96: k great. |
| 19:35:00 | BitPuffin | I WAS PINGED BY SO MANY |
| 19:35:05 | Araq0 | You cant lookup the identifier like this |
| 19:35:19 | dom96 | BitPuffin: THE PINGS ARE TOO DAMN HIGH |
| 19:35:31 | BitPuffin | IT IS fowl'S FAULT |
| 19:35:37 | BitPuffin | hey Mat2 and Varriount |
| 19:35:39 | BitPuffin | ! |
| 19:35:43 | BitPuffin | and not dom96 |
| 19:36:04 | dom96 | no hi for me!? </3 |
| 19:36:09 | BitPuffin | nope |
| 19:36:12 | BitPuffin | you get: |
| 19:36:20 | BitPuffin | hi hi dom96!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! |
| 19:36:27 | dom96 | yayayayya |
| 19:36:37 | dom96 | hello BitPuffin!!!!!!! :) |
| 19:39:22 | BitPuffin | I hope that I get my website up this week |
| 19:39:42 | BitPuffin | the annoying thing is that I wanted to write about linagl but compiler bugs are in the way |
| 19:42:38 | Varriount | Araq, is there a non-fundamentally wrong way? |
| 19:42:50 | Varriount | *Araq0 |
| 19:47:16 | OrionPK | filwit dom96 we need code highlighting for source code filters :) |
| 19:47:48 | filwit | OrionPK: source code filters? |
| 19:48:02 | OrionPK | filwit http://nimrod-code.org/filters.html |
| 19:48:16 | filwit | OrionPK: my Kate language scheme is awesome, btw. It color codes things based on how they're used.. and Nimrod looks pretty |
| 19:48:35 | Varriount | filwit, Kate? |
| 19:48:57 | filwit | Varriount: it's KDE's text editor. Kinda like GEdit, only much better :) |
| 19:49:56 | Varriount | filwit, what do the file(s) that define the highlight scheme look like? Depending on what format they're in, I might be able to update the sublime text plugin |
| 19:50:58 | filwit | Varriount: it's something unique to KDE tools (i think), but it's pretty much the same a .lang file |
| 19:51:17 | Varriount | filwit, can you post it somewhere? |
| 19:51:21 | filwit | Varriount: i was planning on porting it to .lang eventually, for use with Aporia |
| 19:51:46 | filwit | Varriount: sure. it's not done yet though (still some bugs in the regex on some places) |
| 19:52:24 | Varriount | filwit, if it uses regex, then I can probably get it. |
| 19:52:56 | filwit | Varriount: https://gist.github.com/PhilipWitte/7437510 |
| 19:52:57 | Varriount | (Btw, why is it that editor use regex for such things, and not something designed for language parsing, like EBNF, or PEG?) |
| 19:53:51 | Varriount | Araq0, you there? |
| 19:53:53 | filwit | Varriount: actually, I think Kate allows for more than just Regex (unlike .lang files?) |
| 19:54:04 | * | enurlyx joined #nimrod |
| 19:54:33 | filwit | Varriount: if you notice, there are a couple of places i "beginRegion" (also, there's some 'hymn' specific stuff in there that's not Nimrod) |
| 19:57:21 | BitPuffin | ping zahary |
| 19:57:32 | BitPuffin | zahary seesm to be MIA |
| 19:58:09 | Varriount | So, where to implement this fix... |
| 19:58:27 | filwit | Varriount: the resulting syntax looks something like this: http://reign-studios.net/philipwitte/screenshots/arch-win-mac2.png |
| 19:58:49 | BitPuffin | Varriount: by the way I think I'm gonna have time to finish the bug |
| 19:58:57 | filwit | Varriount: though i've changed the scheme slightly since that screen was taken |
| 20:00:08 | * | zahary quit (Ping timeout: 260 seconds) |
| 20:03:10 | Mat2 | hi BitPuffin |
| 20:03:40 | Mat2 | get some sleep, ciao |
| 20:03:44 | * | Mat2 quit (Quit: Verlassend) |
| 20:03:49 | Varriount | BitPuffin, I have found that bug from last night |
| 20:03:59 | Varriount | And know of *a* way to fix it. |
| 20:04:52 | Varriount | Though, Araq0 has hinted that my way is fundamentally wrong, he hasn't told me what the right way is, so I'm gonna go ahead. |
| 20:09:28 | BitPuffin | Varriount: Well I think I know where Araq0 wanted me to fix it |
| 20:09:31 | BitPuffin | and almost how |
| 20:09:43 | BitPuffin | Varriount: the *a* way you found was probably the same thing I initially did |
| 20:10:13 | Varriount | Where/how? I'm looking at semexpr.semexpr, in the nkBrace case |
| 20:10:40 | BitPuffin | Varriount: I don't think we are talking about the same bug |
| 20:11:16 | BitPuffin | Varriount: how are you getting to know the compiler? just by hacking on it or by reading its code first |
| 20:11:34 | Varriount | I'm talking about the bug from last night - "obj.genericProc[type]()" |
| 20:11:42 | Varriount | BitPuffin, both. |
| 20:11:56 | BitPuffin | Because I tried by just starting hacking but felt that I was fundamentally missing an understanding of how it works so I didn't know what to do |
| 20:11:58 | Varriount | It helps that I know a litle bit about things like abstract syntax trees. |
| 20:12:12 | BitPuffin | Varriount: ah well then it isn't the same bug : |
| 20:12:14 | BitPuffin | p |
| 20:14:36 | BitPuffin | Araq0: did the golang people assassinate zahary? |
| 20:18:22 | webskipper | Is there a doc how to wrap ? For example wrappers / mysql.nim not really clear for me |
| 20:19:11 | Araq0 | The golang people are too busy writing "if error { return err }" :p |
| 20:20:37 | Varriount | Araq0, what is fundamentally wrong with my approach of checking that a nkBracket node contains a nkDotExpr node with it's last child being a generic procedure? |
| 20:22:02 | Araq0 | The last part |
| 20:22:50 | Araq0 | You cant check for the generic proc in a.b without lookimg at a |
| 20:24:21 | Varriount | Because...? |
| 20:24:43 | Araq0 | Also your rule is arbitrary |
| 20:25:07 | Araq0 | What about (a.b)[c] ? |
| 20:25:45 | Araq0 | You need to fix semarrayaccess or whatever its called |
| 20:27:06 | Araq0 | General Semexpr for the x in x [y] is not wrong afaict |
| 20:27:27 | filwit | webskipper: Nimrod supports a lot of 'c-types' in it's system module ('cint', 'clong', 'cstring', etc). These are useful for wrapping C. |
| 20:27:38 | webskipper | "cint{.stdcall, dynlib: lib, importc: "mysql_stmt_execute".}" |
| 20:30:55 | BitPuffin | Araq0: hehehe :P |
| 20:31:15 | Varriount | Araq0, so modify semArrayAccess to do... what? That calls semSubscript (and uses it if there's no overloaded subscript operator) |
| 20:31:29 | BitPuffin | Araq0: what have you written in nimrod except nimrod? |
| 20:31:46 | Varriount | Araq0, does semSubscript "unwrap" the expression part of the array? |
| 20:35:01 | Araq0 | I think so yes |
| 20:35:21 | Araq0 | Not sure what unwraps means here |
| 20:35:40 | Varriount | Ah, yeah, skipTypes |
| 20:36:19 | webskipper | this "*" is ugly |
| 20:36:32 | webskipper | have to think about pointers every time lol |
| 20:37:05 | Araq0 | Bitpuffin: nothing. Its obviously only good for compilers or gcs or vms or web stuff or scientific computing |
| 20:37:35 | BitPuffin | webskipper: well it's better than public I think |
| 20:37:58 | BitPuffin | Araq0: people use it for scientific computing? |
| 20:38:47 | Varriount | BitPuffin, I believe Araq0 wrote nimgrep, among other things |
| 20:39:23 | BitPuffin | Varriount: and endb etc |
| 20:39:29 | webskipper | btw: is the nimrod fixed or is it planed to change some syntax things (like this '*') |
| 20:39:43 | BitPuffin | but I meant if he uses it to solve problems for personal projects |
| 20:40:50 | Varriount | Hm. What would people expect (obj.genericProc)[type] to do..? |
| 20:41:37 | BitPuffin | Varriount: not compile? |
| 20:41:55 | fowl | Varriount, call `[]`(genericProc(obj), type) |
| 20:42:34 | BitPuffin | yeah true |
| 20:42:37 | Araq0 | Webskipper some things will change; * will stay as nobody ever came up with something better |
| 20:43:11 | BitPuffin | Araq0: things will change? But what happened to the whole let's make it stable and 1.0 thing that we seem to be approaching |
| 20:43:17 | webskipper | export proc() for example ? |
| 20:43:51 | Araq0 | Bitpuffin *sigh* |
| 20:44:14 | Araq0 | There is no contradiction here |
| 20:44:43 | BitPuffin | change and stability is a bit contradictory |
| 20:44:46 | BitPuffin | but whatever! :D |
| 20:45:14 | BitPuffin | all I want is competitive concurrency and working fleshed out generics and I'll be a happy man |
| 20:45:21 | webskipper | on other side I like the ref and ptr statements. Makes sense ! |
| 20:45:26 | BitPuffin | and ofc the macro stuff but imagine that already works quite well >.< |
| 20:45:26 | * | fredmorcos joined #nimrod |
| 20:45:35 | Varriount | BitPuffin, a light can be stable, in the sense that it's brightness never changes, and yet can still change colors. |
| 20:45:50 | Araq0 | Webskipper sucks too verbose and the name of the proc is too much in the middle if you know what i mean |
| 20:46:05 | Varriount | A molecule can be stable, and yet still undergo physical change. |
| 20:46:09 | BitPuffin | ambiguous start of a sentence there |
| 20:46:29 | BitPuffin | Varriount: look at mr physicist here :P |
| 20:47:18 | BitPuffin | Araq0: ref and ptr is too verbose? |
| 20:47:27 | BitPuffin | have you ever used java? |
| 20:47:38 | webskipper | export he means |
| 20:47:44 | BitPuffin | exprt |
| 20:47:45 | Araq0 | Webskipper: when i started with c i saw multiplications everywhere |
| 20:47:46 | BitPuffin | :P |
| 20:47:50 | BitPuffin | xprt |
| 20:48:04 | Araq0 | Turned out .. |
| 20:48:15 | Varriount | Araq0, I share your viewpoint on * in C |
| 20:48:23 | BitPuffin | Araq0: but what about import and include, they are verbose too |
| 20:48:32 | BitPuffin | if export is verbose that is |
| 20:48:41 | Varriount | BitPuffin, but they are not used nearly as often as procs are. |
| 20:48:57 | BitPuffin | imp, inc, xprt |
| 20:49:05 | BitPuffin | Varriount: prc? |
| 20:49:32 | BitPuffin | I think inc and dec should have been incr and decr |
| 20:49:35 | webskipper | Araq0: sure but C is like a zombie - will never die. So a lot of people associate '*' with pointers |
| 20:49:57 | BitPuffin | because inc is slightly ambiguous, could mean include or whatever. dec can be declare or something |
| 20:49:59 | Varriount | webskipper, for those zombies that still work with pointers >_> |
| 20:50:21 | Varriount | BitPuffin, I didn't choose the names. Though, I do agree with you. |
| 20:50:37 | BitPuffin | what about ª |
| 20:50:43 | BitPuffin | nobody associates that to anything |
| 20:50:44 | Varriount | If you want, make a source code filter that transforms them, or aliased functions |
| 20:50:46 | BitPuffin | could be public :P |
| 20:51:21 | BitPuffin | Varriount: but then nimrodders reading my code won't be able to live |
| 20:51:43 | BitPuffin | nimrodders is too awkward to say. I'm gonna stick with nimbros |
| 20:52:03 | * | BitPuffin has a feeling that Araq0 despises the word nimbro |
| 20:52:19 | Araq0 | Webskipper: fair enough but i dislike c enough to care about that |
| 20:53:04 | Araq0 | Not to care? Well you know what i mean |
| 20:53:20 | BitPuffin | yeah to not care |
| 20:53:33 | Araq0 | Ah yeah |
| 20:54:17 | BitPuffin | I don't really think it's a wise decision to design a language on the basis that this is what people coming from other languages will expect this to mean |
| 20:54:23 | BitPuffin | you should take what is gooda |
| 20:54:32 | BitPuffin | and leave what is bad and pick what seems best |
| 20:54:37 | BitPuffin | or something :D |
| 20:55:07 | BitPuffin | Araq0: but C is at least better than C++ right? |
| 20:55:25 | webskipper | C++ is shit (in my view) |
| 20:55:28 | Araq0 | Wrong imho |
| 20:55:33 | BitPuffin | whaaaaaat |
| 20:55:41 | BitPuffin | I did not expect that |
| 20:55:51 | BitPuffin | please justify :P |
| 20:56:06 | BitPuffin | dom96: I am never leaving arch again |
| 20:56:52 | fowl | most peoples complaints against c/++ is only syntax |
| 20:57:04 | dom96 | hrm, I may have found a security hole in Northern Ireland's school thingy. |
| 20:57:19 | dom96 | So hard not to abuse this :P |
| 20:57:25 | BitPuffin | sure the syntax sucks but that's not why the language sucks |
| 20:57:32 | Araq0 | Imo c++'s problems nearly all come from c |
| 20:57:34 | BitPuffin | dom96: abuse it and then do responsible disclosure |
| 20:57:50 | BitPuffin | But not much of C is left in C++ imo |
| 20:57:56 | BitPuffin | expect maybe pre processor |
| 20:58:05 | BitPuffin | and sure you can still include the C stuff |
| 20:58:14 | BitPuffin | but it's sort of walled off in a way from the language |
| 20:58:36 | BitPuffin | and what remains is a pile of rotten diarrhea |
| 20:59:03 | BitPuffin | but at least it's a fresh summer smoothie compared to java |
| 20:59:11 | * | Jackneill quit (Remote host closed the connection) |
| 21:01:16 | webskipper | java has other concepts |
| 21:01:40 | webskipper | the main concept is dictatorship |
| 21:02:52 | Araq0 | The main concept is focus on the wrong paradigm, implemented poorly |
| 21:02:56 | BitPuffin | I vomit when I either have to force something that isn't an object into an object or write it in a class and put static on everything |
| 21:03:14 | fowl | forst crass functors |
| 21:03:15 | BitPuffin | Araq0: what's the right paradigm? |
| 21:03:39 | fowl | subject oriented |
| 21:03:42 | fowl | fuck objects |
| 21:03:56 | webskipper | subject orientied - lol |
| 21:04:06 | BitPuffin | is that a thing? |
| 21:04:08 | webskipper | its orientied on ME ^^ |
| 21:04:19 | BitPuffin | yeah wtf |
| 21:04:23 | Araq0 | I'd like to call it "procedural on steroids" |
| 21:04:29 | BitPuffin | "Subject-Oriented Programming is an object-oriented software paradigm" |
| 21:04:42 | BitPuffin | fowl: what was that about objects again? |
| 21:04:44 | Araq0 | But thats clearly bad for marketing |
| 21:04:54 | BitPuffin | Araq0: metaprogramming? |
| 21:05:00 | fowl | metalprogramming* |
| 21:05:05 | BitPuffin | fuck yeah |
| 21:05:09 | Araq0 | Lol |
| 21:05:26 | BitPuffin | tech death metalprogramming |
| 21:05:32 | webskipper | analprogramming |
| 21:05:42 | fowl | analprobegramming* |
| 21:06:06 | BitPuffin | Araq0: what's the steroids in nimrod? |
| 21:06:10 | fowl | Araq0, do you get this joke? http://i.imgur.com/sggIZd3.jpg |
| 21:06:31 | Varriount | Araq, what exactly should I do in the semSubscript proc? Use skipTypes on the given node until I get a nkDotExpr, taking the last node of that, checking if it's an ident node and a type that's possibly a generic, and then instanciating the generic? |
| 21:07:14 | Araq0 | Fowl: i think i do |
| 21:07:15 | BitPuffin | fowl: sounds like a rammstein song |
| 21:08:31 | Araq0 | Bitpuffin: the syntactic flexibility and the metaprogramming |
| 21:08:32 | Araq0 | Perhaps |
| 21:09:46 | BitPuffin | yeah I guess |
| 21:09:52 | BitPuffin | well I guess flexibility in general |
| 21:11:48 | Varriount | The real problem here is that you can't partially instanciate generics, can you? |
| 21:12:11 | * | CarpNet joined #nimrod |
| 21:13:56 | Araq0 | Varriount: check out line 1929 |
| 21:15:30 | Araq0 | It does a shitty check whether its a generic invocation |
| 21:16:33 | Varriount | Araq0, that's where I was working before. It messes up if n.sons[0] is wrapped in something like a nkDotExpr or nkPar |
| 21:17:14 | Araq0 | Better would be to check in semsubscript imdeed |
| 21:18:07 | Varriount | And add a check to go through parens and dotExprs? |
| 21:18:24 | Araq0 | Hell no |
| 21:20:10 | Araq0 | Add a typroc case to semsubscript |
| 21:20:58 | Araq0 | And call explicitgenericinstantiation |
| 21:21:50 | Varriount | It will have to be before the initial call on line ~1020 - "n.sons[0] = semExprWithType(c, n.sons[0])" |
| 21:22:10 | Araq0 | Why? |
| 21:22:19 | Varriount | Thats the part where the compiler crashes. |
| 21:22:52 | * | zahary joined #nimrod |
| 21:22:53 | Araq0 | Thats what you need to fix too then |
| 21:24:17 | Varriount | That would mean modifying... instanciateGenericParamList in types.nim |
| 21:24:46 | Araq0 | Why? |
| 21:25:37 | Varriount | Because that is where the root error is raised. There's a case in instanciateGenericParam list where, if the passed parameter list contains any generic types, an error is intentionally raised. |
| 21:26:46 | Varriount | Sorry, that proc is in semcall, my bad. |
| 21:26:58 | Varriount | And semint |
| 21:27:00 | Araq0 | Well you invoke semexprs for a.b so i dont get it |
| 21:27:02 | Varriount | *seminst |
| 21:27:16 | Varriount | Here, I'll post the traceback. |
| 21:28:05 | Varriount | https://gist.github.com/Varriount/7439073 |
| 21:31:04 | Varriount | semexpr is called with an nkBracket node, which in turn calls semArrayAccess, which calls semSubscript. |
| 21:32:11 | Varriount | semSubscript calls passes the son of the nkBracket node to semExprWithType. In this case, the son is a nkDotExpr. |
| 21:32:27 | * | EXetoC joined #nimrod |
| 21:32:29 | Araq0 | The problem is the generated nkdotcall |
| 21:32:58 | Araq0 | Which transforms a.b into b (a) |
| 21:33:19 | Araq0 | Which is wrong for your use case |
| 21:33:50 | Varriount | Yes. It doesn't have the concrete types needed to instanciate the generic. |
| 21:34:23 | Araq0 | Well but it doesnt have to |
| 21:34:47 | Araq0 | It only needs to lookup, right? |
| 21:37:25 | Varriount | Well, wherever the generic is being instanciated, it's not being passes the concrete type needed. |
| 21:37:31 | Varriount | *passed |
| 21:39:30 | Araq0 | Yes because builtinfieldaccess fails but shouldnt |
| 21:40:15 | Araq0 | What is the example code again? |
| 21:40:28 | Araq0 | That fails to compile |
| 21:40:34 | Varriount | BitPuffin gave it to me, one sec |
| 21:42:09 | Varriount | Araq0, -> https://gist.github.com/Varriount/7439309 |
| 21:43:01 | Varriount | OrionPK was doing something with marshalling |
| 21:44:13 | BitPuffin | I did what? |
| 21:44:38 | Varriount | BitPuffin, sorry, I got you confused with OrionPK |
| 21:44:46 | BitPuffin | I have never seen that code in my life ;_; |
| 21:44:47 | Varriount | It was late, and I was tired. |
| 21:44:50 | BitPuffin | probably |
| 21:48:45 | Varriount | It's too bad that I can't "rewind" the action of a program. A perfect debug tool would be one that records all function calls made, and lets you filter out trivial ones, until you get a "timeline" of a program's execution. |
| 21:49:41 | Varriount | With function calls rising and falling on the graph as they are called by sub, and sub-sub* functions |
| 21:50:51 | Araq0 | Er... |
| 21:51:02 | Araq0 | This cant work |
| 21:51:11 | Araq0 | It makes no sense |
| 21:51:27 | MFlamer | Araq0: I demand you stop what your doing and tell me what the fuck N_NIMCALL(NimStringDesc*, reprEnum)(NI e_69477, TNimType* typ); is doing |
| 21:51:28 | Araq0 | Log is not a module name here |
| 21:51:57 | Araq0 | Mflamer it declares reprenum |
| 21:51:57 | MFlamer | it was worth a try anyway |
| 21:52:17 | Araq0 | Its a fucking prototype |
| 21:52:26 | MFlamer | where is the definition of the function then? |
| 21:52:40 | OrionPK | log is a variable araq0 |
| 21:52:47 | OrionPK | var log = openLog("log2.db") |
| 21:52:51 | Araq0 | Ind |
| 21:52:57 | Araq0 | Eed |
| 21:53:02 | Araq0 | I know |
| 21:53:17 | Araq0 | Hence it cant work |
| 21:53:44 | Varriount | Huh? |
| 21:53:50 | OrionPK | it cant transform log.call[T]() to call[T](log) automatically? |
| 21:54:00 | Araq0 | No sir |
| 21:54:21 | OrionPK | Varriount, see up where I told you what araq would tell us about this ;) |
| 21:54:56 | OrionPK | Fowl told us this was a known issue and wouldnt work, but I think it's definitely a nice-to-have |
| 21:55:00 | Varriount | Because when the log.call expression is parsed, it's not given the type. |
| 21:55:04 | OrionPK | or known behavior, not a known issue |
| 21:55:11 | Araq0 | Its ambiguous like fuck as we experts like to say |
| 21:55:22 | * | fredmorcos quit (Quit: Leaving) |
| 21:55:24 | OrionPK | you dont know the type of log? |
| 21:56:05 | Araq0 | No |
| 21:56:26 | OrionPK | you dont know the [string] generic? |
| 21:56:53 | Araq0 | But log.call is looked up in log |
| 21:57:07 | Araq0 | Log has no call field |
| 21:57:32 | Araq0 | So its transformed into call (log) |
| 21:58:01 | OrionPK | why wouldn't it realize it's a proc not a field |
| 21:58:21 | MFlamer | OK, my search was bunk. I found reprEnum. my bad |
| 21:58:32 | Araq0 | --> call has beem given no types |
| 21:58:59 | OrionPK | maybe generics should be changed to <T> instead of [T] :P |
| 21:59:27 | Varriount | Araq, which is why we need to give it types beforehand, or allow semi-instanciated generics (which sound's painful) |
| 21:59:33 | Araq0 | That doesnt affect your problem at all |
| 21:59:49 | Araq0 | Its really simple |
| 21:59:49 | OrionPK | it knows that <T> is generic not index, so it knows it's a call not a field |
| 22:00:28 | OrionPK | yeah I havent looked at the source code in the compiler where the compiler is crashing |
| 22:00:29 | fowl | OrionPK, but thats a PITA because < and > are operators |
| 22:00:44 | Araq0 | (Call (log))[t](...) |
| 22:00:52 | OrionPK | maybe, it wouldnt be the first language to use <> for generics fowl |
| 22:01:08 | Araq0 | Can you see the problem now? |
| 22:01:48 | Araq0 | The choice of [] is irrelevant here |
| 22:01:49 | OrionPK | I would have thoguht [t] would be attached to Call |
| 22:02:09 | Varriount | OrionPK, remember the AST nodes I showed you? |
| 22:02:16 | OrionPK | vaguely |
| 22:02:20 | Araq0 | Yeah well its not |
| 22:03:03 | OrionPK | anyway |
| 22:03:11 | OrionPK | Varriount, I told you :P |
| 22:03:14 | Varriount | Call |
| 22:03:14 | Varriount | BracketExpr |
| 22:03:14 | Varriount | Ident !"readLog" |
| 22:03:14 | Varriount | Ident !"string" |
| 22:03:14 | Varriount | Ident !"log" |
| 22:03:15 | Varriount | Call |
| 22:03:17 | Varriount | BracketExpr |
| 22:03:19 | Varriount | DotExpr |
| 22:03:19 | Araq0 | And its consistent with obj.f[i] |
| 22:03:21 | Varriount | Ident !"log" |
| 22:03:23 | Varriount | Ident !"readLog" |
| 22:03:25 | Varriount | Ident !"string" |
| 22:03:56 | Varriount | The first block is the one that works. |
| 22:04:07 | OrionPK | yeah |
| 22:05:19 | OrionPK | it's not ambiguous to me as a human, but araq is a computer so it is ambiguous :) |
| 22:05:42 | Varriount | Though, I still don't see why it can't be fixed *quickly* I don't see why it can't be fixed *at all* |
| 22:06:14 | OrionPK | my guess is because it doesnt make any sense to fix |
| 22:06:15 | * | eigenlicht quit (Quit: WeeChat 0.3.2) |
| 22:06:19 | OrionPK | erm |
| 22:06:22 | OrionPK | I mean, to change |
| 22:06:39 | OrionPK | doesnt make any sense to change it, because it works how god intended |
| 22:07:53 | Araq0 | And fyi <> causes enormous problems for c++ and cripples generics in csharp and java |
| 22:08:13 | OrionPK | interesting |
| 22:08:25 | Araq0 | So "other langs do it" is a bs argument |
| 22:10:54 | Araq0 | Either a.b[i] is parsed as (a |
| 22:11:08 | BitPuffin | D solved that with !() |
| 22:11:28 | Araq0 | .b)[i] |
| 22:11:47 | fowl | BitPuffin, almost afraid to ask, wtf is !() |
| 22:12:01 | Varriount | And since nimrod can't partially instanciate generic procs, it fails. |
| 22:12:17 | Araq0 | Or as a.(b[i]) |
| 22:12:55 | Araq0 | You cant have both just because you feel it is not ambiguous |
| 22:12:59 | BitPuffin | fowl: void foo!(T)(T a) { bar(a); } |
| 22:13:15 | OrionPK | if it's a [i] it should be (a.b)[i], if it's [T] it should be a.(b[T]) |
| 22:13:33 | OrionPK | thats why I threw out the <> vs [] thing |
| 22:14:34 | Araq0 | Good point but <> are operators |
| 22:14:38 | OrionPK | I know |
| 22:14:44 | OrionPK | if it's too early to tell whether you're trying to use [i] or [T] |
| 22:15:05 | OrionPK | based on what's in between [ and ] |
| 22:15:12 | Araq0 | Actually i plan to have [. ] |
| 22:15:21 | OrionPK | that might work.. |
| 22:15:53 | Araq0 | But people already dislike {. } |
| 22:15:59 | OrionPK | yeah.. |
| 22:16:05 | OrionPK | people like me ;) |
| 22:16:28 | OrionPK | but some way to differentiate between [i] and [T] seems important at this stage of parsing |
| 22:17:27 | Varriount | I still have hope that it can be fixed without any major language changes. |
| 22:17:28 | fowl | OrionPK, especially when you can have a `[]`() that takes a typedesc as second param |
| 22:17:36 | OrionPK | :S |
| 22:18:12 | Varriount | Can't 'b' be checked to see if it's a generic proc? |
| 22:18:21 | OrionPK | yeah |
| 22:18:37 | OrionPK | if the identifier is already declared, it'd have to look at other modules potentially |
| 22:19:33 | Varriount | Which can be done. |
| 22:22:29 | * | Araq0 quit (Ping timeout: 248 seconds) |
| 22:24:40 | Varriount | :< |
| 22:25:01 | * | Varriount is sorry for bothering Araq... |
| 22:27:44 | OrionPK | so wonder why it cant just try both :P |
| 22:28:21 | OrionPK | (a.b)[i] wasnt found, so instead of crashing it could try a.(b[i]) |
| 22:28:21 | Varriount | OrionPK, I think it can, it's just too much of a hack. |
| 22:29:03 | Varriount | Actually, I just commented out the part where the compiler throws the error, and now it just gives a regular type error |
| 22:29:40 | OrionPK | weird |
| 22:37:23 | * | gradha joined #nimrod |
| 22:37:51 | Varriount | I still don't understand why a.b wouldn't just evaluate to a partially generic function |
| 22:52:56 | zahary | btw, most of the gripes with generics not having support for partial application or suffering from ambiguous syntax are resolved when you use typedesc params instead |
| 22:54:29 | OrionPK | zahary example? |
| 22:54:40 | * | p0nce left #nimrod (#nimrod) |
| 22:55:07 | zahary | instead of mycast[T](x), have mycast(T, x) |
| 22:56:18 | OrionPK | can you then pass the typedesc into a generic [ ]? |
| 22:56:22 | zahary | log.call(T) if we use the example from the current discussion |
| 22:56:30 | zahary | yes |
| 22:56:41 | OrionPK | yeah, thanks I'll give that a shot later tonight |
| 22:56:46 | zahary | procs with typedesc params are generic too |
| 22:57:18 | OrionPK | gotcha |
| 22:57:29 | OrionPK | it's not a really huge deal for my purposes |
| 22:57:56 | OrionPK | it was just a pain in the ass for me to track down why it wasnt compiling |
| 22:58:01 | BitPuffin | zahary: does that solve my problems? |
| 22:58:14 | zahary | BitPuffin, what are your problems? |
| 22:58:19 | OrionPK | too many to count |
| 22:58:36 | BitPuffin | zahary: everything generics basically |
| 22:58:38 | BitPuffin | no but |
| 22:59:15 | BitPuffin | zahary: you know passing values other than ranges to generics, referring to foo.type.T etc |
| 22:59:30 | BitPuffin | both those are needed for my implementation of submatrices |
| 22:59:44 | BitPuffin | which are needed for my implementation of N-dimensional matrix determinants |
| 23:00:13 | * | OrionPK quit (Quit: Page closed) |
| 23:01:08 | zahary | well, have you bugged me before for these. have you filled some bugs already? I missed a lot of messages |
| 23:01:57 | zahary | things like foo.type.T should work, but they are not related to the typedesc params discussed here |
| 23:02:47 | * | Amrykid quit (Excess Flood) |
| 23:04:06 | * | Amrykid_ joined #nimrod |
| 23:04:29 | BitPuffin | zahary: foo.type.T does not work. There is a bug report for it 618, I even began fixing it but might continue tomorrow |
| 23:04:33 | BitPuffin | #618 |
| 23:04:51 | BitPuffin | zahary: I'm not sure if there is a bug report for the passing int values to generics |
| 23:04:53 | * | Amrykid_ is now known as Amrykid |
| 23:04:57 | * | Amrykid quit (Changing host) |
| 23:04:57 | * | Amrykid joined #nimrod |
| 23:05:59 | * | CarpNet quit (Quit: Leaving) |
| 23:07:01 | zahary | This is complicated to fix, the bug happens when the dot syntax is used within the return type of the proc |
| 23:07:58 | zahary | the problem is that the signature is read too early, before the generic is being instantiated - then after instantiation, the return type must be corrected in semtypinst |
| 23:09:30 | BitPuffin | zahary: guess my fixing process was entirely off then :P |
| 23:09:41 | * | enurlyx quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0/20131025151332]) |
| 23:10:10 | BitPuffin | I was kind of blindly doing what Araq told me to https://github.com/BitPuffin/Nimrod/commits/bug-618 |
| 23:10:12 | zahary | well, did you fix some crash that was happening early on? that could be useful |
| 23:10:22 | BitPuffin | for the first part |
| 23:10:27 | BitPuffin | zahary: crash? |
| 23:10:58 | BitPuffin | before those commits I managed to get the error message from saying invalid type '' to invalid type 'T' lol :P |
| 23:15:09 | zahary | well, have fun with the compiler, but this will take you on a long journey |
| 23:16:40 | BitPuffin | :/ |
| 23:16:55 | BitPuffin | is this stuff baggage from being generated from pascal? |
| 23:17:04 | BitPuffin | I mean maybe not this particular thing |
| 23:17:35 | BitPuffin | but I mean are there a lot of errors that come from not being written from scratch in nimrod to be a good poster child for good nimrod code |
| 23:18:21 | BitPuffin | or is it just that it would never get done if it was written to be the best possible nimrod code :P |
| 23:24:10 | zahary | well, what do you mean exactly? part of the complexity comes from that fact that you are implementing a freaking compiler |
| 23:24:59 | BitPuffin | zahary: would a possible solution be to say that during the first pass of reading the signature, if a return type is undefined and spotted as being a nkDotExpr, store a reference to those parts of the code and if generic instantiation "has the answer" set the correct return type otherwise commit compiler suicide? |
| 23:25:38 | BitPuffin | zahary: Yeah I almost wrote that maybe it's just because compiler programming is the messiest kind of programming but didn't :P |
| 23:25:59 | BitPuffin | it feels like a kind of hacky way to do it though |
| 23:26:24 | * | OrionPK joined #nimrod |
| 23:26:50 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=mcyhZEXwfh0 again) |
| 23:28:48 | zahary | yes, that's the outline of the solution. you leave parts of the tyGenericBody dot expression unresolved and then later when you know the real type of the tyGenericBody, you get the final type in seminst/generateInstance |
| 23:29:42 | BitPuffin | zahary: so you think that's the solution to shoot for. Or is there some better more ideal solution? |
| 23:29:47 | zahary | but to fix this properly would be quite complicated. there are other types of expressions that should get similar treatment |
| 23:29:59 | zahary | things like macro calls and when statements |
| 23:30:46 | zahary | proc foo(x: T): select_return_type(T) = |
| 23:31:07 | * | brson joined #nimrod |
| 23:31:08 | BitPuffin | zahary: so it's more or less a deeper problem with an aspect of the compiler architecture |
| 23:31:10 | BitPuffin | ? |
| 23:33:46 | Varriount | BitPuffin, zahary, sounds like my generic problem :p |
| 23:34:24 | BitPuffin | Varriount, zahary: sounds like something crucial to fix :/ |
| 23:34:37 | zahary | yes, it's one of the harder problems in the compiler right now. Varriount, are you working on a language too or you have a similar problem in NImrod? |
| 23:35:03 | Varriount | zahary, obj.genericProc[type]() doesn't work. |
| 23:35:36 | zahary | you missed my previous message where I suggested that typedesc params are the recommended solution nowadays |
| 23:35:38 | Varriount | the dotExpr is resolved without knowledge of the type, and the generic fails |
| 23:35:51 | zahary | make that obj.genericProc(type) and you won't have problems |
| 23:36:32 | zahary | typedesc params are currently much more capable, because they participate in the overload resolution process more properly |
| 23:36:35 | BitPuffin | zahary: any chance you can write something somewhere (I suggest the nimrod wiki on github) what needs to be done to fix it? I mean the proper fix other than this workaround |
| 23:37:02 | BitPuffin | just so that we have some guidlines |
| 23:37:05 | BitPuffin | guidelines* |
| 23:37:37 | Varriount | BitPuffin, warning in the tutorial and/or the manual |
| 23:39:28 | BitPuffin | ar actually, a really well written bug report detailing what the problem is and what is the ideal solution |
| 23:40:02 | Varriount | zahary, you mean arguments without types? |
| 23:41:00 | zahary | Varriount, no. take a look at the section in the manual about typedesc params: |
| 23:41:00 | zahary | http://build.nimrod-code.org/docs/manual.html#typedesc |
| 23:41:31 | Varriount | Ah, thanks |
| 23:41:59 | zahary | proc genericProc(obj: MyType, T: typedesc) is a way to define a proc that will accept a type (it will be a generic proc under the hood and T could be used a generic parameter) |
| 23:42:35 | Varriount | Unfortunately, new users coming from almost any other language will still use generics, instead of typedesc. |
| 23:42:37 | BitPuffin | anyways that would be nice because at the place I'm interning at at the moment I've got fuck all to do so maybe poking around in the compiler is a proper way to spend my time |
| 23:43:11 | OrionPK | zahary that typedesc solution doesnt seem to work w/ iterators |
| 23:43:30 | zahary | BitPuffin, just try to study the code in seminst/generateInstance and see what's going on there (also semtypinst) |
| 23:43:46 | zahary | but you could also try some other easier bug first :) |
| 23:44:01 | BitPuffin | yeah probably |
| 23:44:03 | zahary | OrionPK: what's the example? |
| 23:44:21 | BitPuffin | but this is basically the bug that is stopping me from getting stuff done :P |
| 23:44:24 | OrionPK | a.b(T) where b = iterator (A, T: typedesc): T |
| 23:44:54 | zahary | I'll put in front of my todo list |
| 23:45:26 | BitPuffin | zahary: your todo list must be the longest scroll ever conceived :P |
| 23:45:53 | BitPuffin | well and Araq's |
| 23:48:38 | * | brson quit (Ping timeout: 244 seconds) |
| 23:55:55 | zahary | OrionPK: iterators with typedesc params work for me |
| 23:55:55 | zahary | https://gist.github.com/zah/7440962 |
