| 00:03:24 | * | brson quit (Ping timeout: 245 seconds) |
| 00:04:28 | * | brihat joined #nimrod |
| 00:04:44 | * | brson joined #nimrod |
| 00:12:09 | * | Demos quit (Quit: Textual IRC Client: www.textualapp.com) |
| 00:14:03 | * | brson_ joined #nimrod |
| 00:17:19 | * | brson quit (Ping timeout: 250 seconds) |
| 00:18:47 | * | psquid joined #nimrod |
| 00:25:37 | * | xenagi quit (Read error: Connection reset by peer) |
| 00:26:07 | reactormonk | Varriount, make a repo in nimrod-code, call it python-itertools |
| 00:32:09 | brihat | wow, so happy to see Nimrod in Dr Dobbs: http://dc.ubm-us.com/i/245989 |
| 00:32:15 | brihat | well explained Araq |
| 00:38:36 | brihat | Or the direct link here: http://www.drdobbs.com/open-source/nimrod-a-new-systems-programming-languag/240165321 |
| 00:40:55 | filwit | yeah i remember Araq talking about how being featured on DrDobbs a few days ago |
| 00:40:59 | filwit | has been reddited? |
| 00:41:12 | brihat | i dont know |
| 00:41:34 | filwit | doesn't look like it |
| 00:41:50 | filwit | but i don't want to reddit it without getting an Okay from Araq first |
| 00:42:30 | brihat | why? it's public and out on the interwebs already! |
| 00:43:12 | filwit | you're probably right, i just remember him saying not to reddit something a little while ago |
| 00:43:18 | filwit | though i don't think it was this.. |
| 00:44:54 | brihat | I just submitted to HN: https://news.ycombinator.com/item?id=7194014 |
| 00:45:22 | filwit | k, screw it i'll reddit it |
| 00:45:40 | brihat | ok! |
| 00:48:57 | filwit | crap, submitted under subreddit 'nimrod' but not 'programming'.. how to edit? |
| 00:49:14 | filwit | or is 'nimrod' automatically seen from 'programming'? |
| 00:49:21 | filwit | http://www.reddit.com/r/nimrod/comments/1x8am6/dr_dobbs_nimrod_a_new_systems_programming_language/ |
| 00:50:22 | brihat | I don't see it on /r/programming/new |
| 00:50:25 | filwit | doesn't look like it's coming up under 'programming', damn |
| 00:50:27 | filwit | yeah |
| 00:50:41 | filwit | shit, can you edit the post or do i need to resubmit? |
| 00:51:28 | brihat | i dont have a reddit account, sorry |
| 00:52:05 | filwit | Anyone? |
| 00:52:24 | filwit | first time i've actually posted something on reddit besides comments |
| 00:53:02 | filwit | do i just submit two, one under 'programming' and one under 'nimrod'? or can i comma/space separate the subreddit field? |
| 00:53:12 | filwit | guess i should just google this sort of thing.. |
| 00:54:11 | brihat | probably u can resubmit under /r/programming |
| 00:54:46 | filwit | yeah i guess someone says to just post to twice to multiple subreddits, okay |
| 00:59:35 | Varriount | reactormonk: You think it's good enough for a repo? |
| 01:01:48 | reactormonk | Varriount, I paste everything into a repo. |
| 01:06:44 | filwit | http://www.reddit.com/r/programming/comments/1x8chx/dr_dobbs_nimrod_a_new_systems_programming_language/ |
| 01:06:51 | filwit | god that took longer than it should have |
| 01:07:21 | filwit | sweet.js looks really cool for Javascript devs: http://sweetjs.org/ |
| 01:07:43 | filwit | nice macro system |
| 01:08:08 | brihat | cool, i see it at the top here: http://www.reddit.com/r/programming/new |
| 01:09:00 | * | DAddYE_ joined #nimrod |
| 01:09:55 | filwit | yep! |
| 01:10:08 | filwit | vote it up folks |
| 01:11:55 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 01:13:56 | * | DAddYE_ quit (Remote host closed the connection) |
| 01:14:31 | * | DAddYE joined #nimrod |
| 01:18:11 | reactormonk | Varriount, just do it. |
| 01:19:22 | Varriount | reactormonk: I'll submit it later tonight. I'm fixing it up a bit. |
| 01:19:28 | Varriount | Unless you need it right now? |
| 01:19:50 | Varriount | (Also, fyi, I'm only notified by my irc client when my name is mentioned) |
| 01:27:17 | reactormonk | Varriount, nah |
| 01:27:26 | reactormonk | Varriount, I'm currently busy flashing my phone |
| 01:27:44 | Varriount | Ah, I have spent happy/maddening hours doing that before. |
| 01:28:29 | Varriount | I'll never know why companies try to keep people from doing it (Asus, I know, allows you to do all sorts of things, provided you agree to voiding your warreny) |
| 01:28:33 | Varriount | *warrenty |
| 01:28:42 | reactormonk | Varriount, I unlocked it already, htc was kinda open about that |
| 01:37:34 | * | whatelse quit (Quit: Page closed) |
| 01:39:18 | Varriount | Hrm, anyone here knowledgable about sorting algorithms? |
| 01:39:19 | * | [Pete_27] quit (Ping timeout: 252 seconds) |
| 01:39:30 | Varriount | Nimrod needs a timsort implementation |
| 01:40:05 | * | [Pete_27] joined #nimrod |
| 01:40:34 | reactormonk | yup |
| 01:50:58 | * | brson_ quit (Quit: leaving) |
| 02:02:05 | * | DAddYE quit (Remote host closed the connection) |
| 02:02:40 | * | DAddYE joined #nimrod |
| 02:07:11 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 02:28:54 | EXetoC | that was an annoying bug. TBson doesn't like to be copied |
| 02:42:51 | * | dmac joined #nimrod |
| 02:57:32 | * | carum joined #nimrod |
| 03:03:03 | * | DAddYE joined #nimrod |
| 03:07:29 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 03:10:57 | * | Demos joined #nimrod |
| 03:12:59 | * | DAddYE joined #nimrod |
| 03:20:41 | * | carum quit (Remote host closed the connection) |
| 03:43:39 | * | dmac quit (Ping timeout: 252 seconds) |
| 04:01:38 | filwit | wasn't there a {.descutor.} or something pragma before? |
| 04:01:43 | filwit | can't find it in the index |
| 04:01:46 | filwit | was that removed? |
| 04:04:26 | * | CarpNet quit (Ping timeout: 245 seconds) |
| 04:04:52 | * | CarpNet joined #nimrod |
| 04:53:19 | * | DAddYE quit (Remote host closed the connection) |
| 04:53:45 | * | DAddYE joined #nimrod |
| 04:57:33 | Demos | filwit: I remember it as well |
| 04:58:12 | Demos | I am having some trouble instanciateing a generic using a typedesc (from inside a template) any tips? |
| 04:58:39 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 04:58:54 | filwit | no but it sounds like a bug with a recent change to devel |
| 04:59:02 | Demos | oh dear god |
| 04:59:55 | Demos | it is on newseq, so it looks like I get into the generic proc and newseq fails |
| 05:00:46 | filwit | hmm... can you post a gist i can try? |
| 05:03:27 | Demos | perhaps the Error: cannot instantiate: 'T' should include the type you tried. and let me generate a nice minimal case |
| 05:04:01 | * | carum joined #nimrod |
| 05:04:57 | Demos | https://gist.github.com/8857579 |
| 05:05:19 | filwit | yeah that's the problem i'm having with the macro stuff, it's rather complicated to isolate the problem (though I recently found it has to do with adding a Node inside a if-statement inside a macro). |
| 05:05:23 | filwit | thanks |
| 05:05:34 | Demos | sorry, wrong code |
| 05:06:49 | Demos | let me repost |
| 05:06:49 | Demos | https://gist.github.com/8857591 |
| 05:07:41 | Demos | yeah, are you working on fixing macros bugs or just writing macros yourself |
| 05:08:00 | Demos | one issue I am having is that incorrect code tends to be rejected with really bad error messages |
| 05:09:04 | filwit | i'm trying to fix a bug related to a OOP macro i'm writing |
| 05:09:21 | filwit | one sec |
| 05:12:14 | * | carum quit (Remote host closed the connection) |
| 05:13:39 | * | carum joined #nimrod |
| 05:16:30 | filwit | Demos: that doesn't work even when it's a proc |
| 05:16:47 | filwit | Demos: seems to be something other than what I originally thought (it's a bug with system.nim) |
| 05:16:55 | Demos | I dont think so |
| 05:17:09 | Demos | the function that is on line 394 is just newSeq |
| 05:17:14 | Demos | and it points to the first line |
| 05:17:40 | filwit | ahh,, wait a sec |
| 05:17:51 | filwit | well, no nevermind |
| 05:18:04 | filwit | it doesn't build on any version of the compiler |
| 05:18:15 | filwit | so it's not a recent bug or anything |
| 05:18:24 | Demos | well it could be wrong code |
| 05:18:37 | filwit | it's possible, though i don't see how or why |
| 05:18:58 | filwit | possibly a template can't just do nothing? |
| 05:19:24 | filwit | no that's not it of course.. |
| 05:19:35 | Demos | yeah same thing if I inject it |
| 05:19:40 | Demos | mmmm that is |
| 05:20:11 | filwit | oh, of course using template/proc doesn't matter cause first parameter is a typedesc.. doh |
| 05:20:31 | filwit | i almost wish 'template' was required for those or something, kinda confusing sometimes |
| 05:21:25 | Demos | I dont really care that it is not, esp since since you often want to do computations on these sorts of things from macros |
| 05:21:42 | filwit | wtf.. something is really wrong here, hold on |
| 05:25:04 | filwit | okay finally i got a stack-trace on devel |
| 05:25:17 | Demos | for my error? |
| 05:25:20 | filwit | yeah |
| 05:25:25 | * | DAddYE joined #nimrod |
| 05:26:02 | filwit | compiler crashes on devel when you use "proc newSeqAlias[T](): seq[T] = ..." |
| 05:26:15 | Demos | that is wonderful but I actually have to go, just realized that I need to go catch a bus |
| 05:26:27 | filwit | whoops, i meant turn that into: "proc newSeqAlias[T:typedesc](): seq[T] = ..." |
| 05:26:36 | filwit | okay, later |
| 05:27:01 | Demos | hm, that is strange, replace the param of test with an expr and see if it works... |
| 05:27:19 | filwit | yeah i'm trying different things and looking at the stack trace |
| 05:27:29 | filwit | i'll let you know if i find anything |
| 05:28:30 | filwit | has to be 'typedec' (expr doesn't work) or Nimrod wont compile it (thinks it's bad syntax cause it can't enforce it's a typedesc for return type) |
| 05:31:30 | * | Demos quit (Ping timeout: 250 seconds) |
| 05:45:47 | * | ics joined #nimrod |
| 05:49:47 | * | xtagon quit (Ping timeout: 260 seconds) |
| 05:53:53 | * | Demos joined #nimrod |
| 05:54:00 | Demos | ck |
| 05:54:02 | Demos | ok back |
| 05:54:27 | filwit | well the stack-trace was due to a bug in devel which, after i pulled, it went away |
| 05:55:06 | filwit | compiler still can't seem to initialize a seq of a 'None' which is what it things 'T' is |
| 05:55:43 | filwit | so some but with templates not passing on their generic types to sequences or something along those lines |
| 05:56:18 | filwit | i probably wont be able to fix it anytime soon, so I would report it if it isn't already a known issue |
| 05:56:32 | Demos | well lets see if it is only sequences |
| 05:57:33 | filwit | good idea, but I'm setting it aside for the moment. I've made a test case for it, so If you don't end up fixing it I'll continue to try |
| 05:58:07 | filwit | I'm going to continue fixing my macros stuff tonight |
| 05:58:20 | Demos | wowah seems to work when sequences are not involved |
| 05:58:36 | filwit | yeah cause seq's in the compiler are somewhat special |
| 05:59:32 | Demos | yeah. For my needs I could implement a regular old dynamicly sized array that just does not use GC'd memory |
| 05:59:38 | Demos | assuming destructors work |
| 06:00:39 | filwit | destruction should work fine, and you can always fall back to malloc/free if you had too |
| 06:05:51 | * | Demos_ joined #nimrod |
| 06:06:00 | Demos | right, but I dont want to manually manage stuff like that |
| 06:07:07 | filwit | of course |
| 06:07:28 | * | carum quit (Remote host closed the connection) |
| 06:07:29 | Demos | that bug is known as issue #853 |
| 06:08:19 | Demos | being able to implement seqs as a pure library feature would be great, but I suspect that garbage collection related stuff is going on that I really know nothing about |
| 06:09:50 | filwit | yeah |
| 06:12:13 | * | carum joined #nimrod |
| 06:17:24 | * | Discoloda joined #nimrod |
| 06:21:29 | Demos_ | does nimrod have generic specialization? or do people just use the is operator |
| 06:22:16 | filwit | i believe so, like: proc foo[T:int|float] |
| 06:22:42 | filwit | called type-classes? |
| 06:23:03 | filwit | http://nimrod-lang.org/manual.html#type-class_1295114935 |
| 06:23:16 | Demos_ | right but if I have proc foo[T] as well how does overload resolution work |
| 06:23:25 | Demos_ | most constrained first? |
| 06:23:46 | filwit | most like just like parameter overloading, but I have no idea for sure, sorry |
| 06:24:00 | filwit | likely* |
| 06:24:55 | Demos_ | right, I need to have many of my function gcref stuff in the ref | string case |
| 06:28:54 | * | carum quit (Remote host closed the connection) |
| 06:30:51 | * | ddl_smurf quit (Ping timeout: 260 seconds) |
| 06:33:07 | * | carum joined #nimrod |
| 06:45:29 | * | carum quit (Remote host closed the connection) |
| 06:48:03 | Demos_ | how do I do pointer arithmetic? succ is not working |
| 06:48:32 | Demos_ | do I just cast the pointer to an int? |
| 06:49:51 | * | carum joined #nimrod |
| 06:52:06 | * | Demos_ quit (Quit: Textual IRC Client: www.textualapp.com) |
| 06:56:51 | * | Demos quit (Ping timeout: 245 seconds) |
| 07:01:02 | * | vbtt joined #nimrod |
| 07:02:15 | vbtt | Hi |
| 07:02:34 | reactormonk | vbtt, sup |
| 07:03:29 | reactormonk | vbtt, what nimrod are you writing today? |
| 07:04:21 | vbtt | reactormonk: not much really |
| 07:06:26 | vbtt | nimrod is on reddit again |
| 07:06:59 | reactormonk | tha't s the idea |
| 07:07:30 | vbtt | reactormonk: I want to write a few serious things in nimrod but waiting for syntax and features to settle a bit |
| 07:12:18 | reactormonk | vbtt, start something smaller then, Varriount mentioned itertools |
| 07:13:45 | vbtt | Unfortunately don't have much free time :( |
| 07:15:53 | vbtt | Are you writing nimrod? |
| 07:16:35 | reactormonk | vbtt, from time to time https://github.com/Araq/Nimrod/commits/devel |
| 07:17:37 | vbtt | Cool. |
| 07:18:20 | vbtt | I might write more blog posts or docs cos that's easier with the intermittent free time i have |
| 07:20:46 | reactormonk | vbtt, perfect |
| 07:21:23 | reactormonk | btw, |
| 07:21:26 | reactormonk | http://www.reddit.com/r/nottheonion/ |
| 07:32:35 | vbtt | Later, guys. |
| 07:32:42 | * | vbtt quit (Quit: Bye) |
| 08:02:50 | * | carum quit (Remote host closed the connection) |
| 08:03:18 | * | carum joined #nimrod |
| 08:25:27 | * | aftershave_ joined #nimrod |
| 08:56:28 | * | filwit quit (Quit: Leaving) |
| 09:07:31 | * | carum quit (Remote host closed the connection) |
| 09:09:02 | * | carum joined #nimrod |
| 09:09:59 | * | Eruquen left #nimrod ("Leaving") |
| 09:13:11 | * | carum quit (Ping timeout: 245 seconds) |
| 09:40:11 | * | DAddYE quit (Remote host closed the connection) |
| 10:13:07 | * | awestroke joined #nimrod |
| 10:32:21 | * | ics quit (Ping timeout: 245 seconds) |
| 10:33:40 | * | ics joined #nimrod |
| 11:41:49 | * | carum joined #nimrod |
| 11:50:35 | * | carum quit (Ping timeout: 272 seconds) |
| 12:24:20 | * | darkf quit (Quit: Leaving) |
| 12:28:53 | * | awestroke quit (Ping timeout: 248 seconds) |
| 12:29:36 | * | psquid quit (Quit: meal -> work) |
| 12:59:45 | * | isenmann quit (Quit: Leaving.) |
| 13:29:28 | * | awestroke joined #nimrod |
| 13:55:35 | * | BitPuffin joined #nimrod |
| 14:40:39 | dom96 | hello |
| 14:55:48 | Varriount | dom96: Good morning |
| 14:56:00 | Varriount | You have the new asyncio stuff done? |
| 14:56:27 | Varriount | Or semi-done? Or even half-done? (I'm desperate) |
| 14:58:26 | dom96 | Varriount: Do you need something to do? |
| 14:58:39 | dom96 | semi-done. |
| 14:58:45 | Varriount | Somewhat. Although I'm in class right now. |
| 15:02:35 | dom96 | Might be able to get it done by today |
| 15:07:41 | dom96 | But please try to figure out why reading process output is out of order when osproc merges stderr and stdout. |
| 15:07:57 | * | Demos joined #nimrod |
| 15:22:35 | * | [1]Endy joined #nimrod |
| 15:23:33 | Demos | wow. someone submitted a proposal to add templates (like nimrod's) to c++... |
| 15:23:49 | dom96 | Really? Link? |
| 15:25:48 | Demos | http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3883.html |
| 15:26:04 | Demos | I think it may have macros as well, but the syntax is pretty bad |
| 15:26:31 | Demos | they seem to say "we propose a new astnode template constraint, we have no idea what the hell astnodes are allowed to be" |
| 15:26:57 | dom96 | oh, I thought it mentioned Nimrod... |
| 15:27:28 | Varriount | Demos: "The idea comes from the AngularJS templating system" |
| 15:27:47 | Varriount | Yeah, translating a javascript feature to C++ is going to work so well... |
| 15:27:51 | Demos | no, it does not. But the idea seems to be similar. I saw that as well but yeah |
| 15:28:28 | Demos | also Raymond Chen blogged about iocps and OVERLAPPED structures yesterday |
| 15:30:01 | Demos | yeah, I feel like that paper will get shot down pretty hard as "really needs a test implementation" |
| 15:32:28 | EXetoC | dom96: today? great |
| 15:32:43 | dom96 | EXetoC: /maybe/ :P |
| 15:33:48 | dom96 | Indeed. Raymond Chen's blog helped me quite a bit with IOCP |
| 15:33:59 | * | dom96 is considering buying his book |
| 15:35:01 | * | [2]Endy joined #nimrod |
| 15:35:05 | Demos | yeah some of those docs are really helpful, one of the few places with in depth informaton on the rationale behind com |
| 15:38:15 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 15:46:58 | * | randallsquared quit (Quit: Off for now...) |
| 15:55:22 | OrionPK | yay IOCP |
| 15:55:55 | * | Demos quit (Ping timeout: 252 seconds) |
| 15:56:45 | OrionPK | IO clown posse |
| 15:59:33 | Varriount | Araq: http://www.heise.de/newsticker/meldung/Uneasy-Rider-Radfahren-in-Las-Vegas-2087813.html |
| 16:03:00 | * | awestroke quit (Remote host closed the connection) |
| 16:08:23 | * | ddl_smurf joined #nimrod |
| 16:20:44 | Varriount | dom96: I just wish that there was a similar book for the linux kernal |
| 16:29:51 | EXetoC | dom96: I have no choice but to take that back then |
| 16:50:07 | * | carum joined #nimrod |
| 16:50:24 | dom96 | hi carum |
| 16:53:47 | * | truff__ quit (Read error: Connection reset by peer) |
| 16:54:42 | * | carum quit (Ping timeout: 265 seconds) |
| 16:55:06 | * | truff__ joined #nimrod |
| 17:21:56 | NimBot | Araq/Nimrod devel 6c04256 Araq [+1 ±5 -0]: bugfix: codegen issue that caused getGMTime() to leak memory |
| 17:21:56 | NimBot | Araq/Nimrod devel 201fe49 Araq [+1 ±5 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 17:24:30 | Araq | so we're on reddit again ... |
| 17:24:47 | Araq | and when somebody bothers to look at the forum, what do they see? |
| 17:25:03 | Araq | a regression, (;) didn't work anymore |
| 17:25:15 | bstrie | "The (simplified) rule is that the first character of the operator determines the precedence." <-- can I see the docs on this? |
| 17:25:26 | bstrie | (from the dobbs article) |
| 17:25:31 | Araq | the table is in the manual, bstrie |
| 17:25:37 | bstrie | will look |
| 17:27:27 | Araq | you know guys, when you post on reddit, you could check the first impression is a good one ... but aparently nobody really cares ... |
| 17:29:27 | Araq | OrionPK: can you check the leak is also gone for your real code? I only checked the getGMTime loop |
| 17:48:41 | EXetoC | Araq: I do; I just haven't done anything about it. There's no list of related issues, right? A couple of things comes to mind (no auto-validated examples, no cookbook etc) |
| 17:49:51 | NimBot | Araq/Nimrod devel 84eb9df Araq [+0 ±2 -0]: tester compiles again |
| 17:50:28 | EXetoC | I might look into that, if there isn't anything more urgent |
| 17:50:35 | Araq | EXetoC: yeah auto-validated examples would be good |
| 17:50:59 | Araq | though atcually I still think the tests cover most things |
| 17:51:31 | Araq | except that getting 600 tests to work at the same time is a task that nobody can handle, apparently |
| 17:53:18 | EXetoC | what's the issue? |
| 17:54:42 | Araq | we're humans, that's the issue |
| 18:00:53 | EXetoC | don't you mean a handful of tests at the same time? I don't know what you're referring to exactly, but it's not yet a parallel process IIRC |
| 18:01:03 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 18:04:04 | Araq | no, I mean things like "ok, I fixed bug #xyz but now tests a, b, c and fail ..." |
| 18:09:23 | EXetoC | as in not everyone runs the test suite? |
| 18:10:32 | NimBot | Araq/Nimrod devel bd3a215 EXetoC [+0 ±1 -0]: Export procs that are useful elsewhere. |
| 18:10:32 | NimBot | Araq/Nimrod devel 81838b0 Andreas Rumpf [+0 ±1 -0]: Merge pull request #877 from EXetoC/times-symbol-export... 2 more lines |
| 18:11:44 | Araq | EXetoC: the tests suite runs for too long and nobody can compare ~600 tests to see what now fails that didn't use to fail before |
| 18:12:07 | Araq | the new tester improves things substantially, but still misses the 'diff' feature |
| 18:13:07 | * | CarpNet quit (Quit: Leaving) |
| 18:13:45 | OrionPK | Araq when i get some time, i'll let you know |
| 18:20:40 | Araq | ping renesac |
| 18:21:15 | Araq | ping dom96 |
| 18:22:37 | BitPuffin | Araq: if you ever want advice on how to not do syntax, check out objective-c blocks |
| 18:22:49 | BitPuffin | http://fuckingblocksyntax.com/ |
| 18:25:51 | EXetoC | :E |
| 18:28:35 | * | filwit joined #nimrod |
| 18:28:55 | Araq | hi filwit |
| 18:29:05 | filwit | 165 upvotes on the reddit, not bad |
| 18:29:08 | filwit | hey Araq |
| 18:29:32 | Araq | you know the Dr Dobbs article will be released officially on 11th of february |
| 18:30:02 | filwit | damn, see, i knew there was something telling me not to post it |
| 18:30:09 | Araq | yup |
| 18:30:22 | filwit | sorry man, should have talked to you first |
| 18:30:34 | Araq | also the top post in our forum is another embarrassing regression |
| 18:31:37 | filwit | crap, well now i kinda screwed that release all up |
| 18:31:47 | Araq | no worries |
| 18:33:11 | filwit | well i was worried the whole time cause i remember you posting something saying not to post some announcement till later. Should have done more digging before posting an article i was unsure about. |
| 18:33:37 | filwit | just figured since it was already public it had been released |
| 18:33:51 | Araq | yeah funny thing is |
| 18:34:11 | Araq | Dr Dobbs content management system sucks so they have to date it back |
| 18:34:27 | Araq | and then they update the release date to get to the frontpage |
| 18:34:35 | Araq | something like that anyway |
| 18:35:12 | filwit | ahh, i see. well that was confusing but still not a good excuse. I'll make sure to check with you before posting any future articles. |
| 18:35:23 | Araq | thank you |
| 18:35:58 | filwit | in the mean time, there have been a couple of questions asked on the reddit that I didn't know how to answer the best |
| 18:36:18 | Araq | oh really? now who would thought that |
| 18:36:18 | filwit | as long as it's out there and on the /r/programming/hot, might as well do our best to answer them |
| 18:39:41 | Discoloda | BitPuffin: as a C programmer, i understand the block syntax. C type syntax is just fucked up |
| 18:40:20 | BitPuffin | Discoloda: I also know C |
| 18:40:26 | BitPuffin | Discoloda: and it does not make sense |
| 18:40:29 | BitPuffin | Like I understand it |
| 18:40:32 | Araq | filwit: you know, this is exactly what annoys me the most |
| 18:40:36 | BitPuffin | but I can't see how it is in any way logical |
| 18:41:31 | Araq | do I want to answer the guys who think Haskell and Clojure is the solution for everything? |
| 18:41:38 | Araq | no, I don't |
| 18:42:24 | filwit | well i was talking about the guy asking for a official grammar, and the guy asking about Nimrod's RAII support |
| 18:42:25 | dom96 | Araq: yo, sup? |
| 18:43:50 | Araq | dom96: have a look at https://github.com/Araq/Nimrod/issues/852 |
| 18:44:20 | dom96 | Araq: You should stop stereotyping reddit. |
| 18:44:44 | Discoloda | BitPuffin: the only thing new is the block primary expression: "^returnType(params){...}" the rest are just function pointers using ^ instead of * |
| 18:44:50 | dom96 | What's interesting is that we seem to have reached a saturation point of reddit users. |
| 18:45:03 | dom96 | or at least the users who are willing to join our IRC channel. |
| 18:45:19 | Araq | we also have a saturation point for github watchers |
| 18:45:33 | dom96 | indeed |
| 18:45:49 | dom96 | Which means that we need to do something differently. |
| 18:45:56 | dom96 | So you better start answering questions :P |
| 18:46:05 | BitPuffin | Discoloda: yeah which is weird |
| 18:46:15 | BitPuffin | Discoloda: I guess the C function pointer syntax doesn't really make sense |
| 18:46:19 | BitPuffin | so that's why it's weird :P |
| 18:46:37 | Araq | dom96: yeah ... I prefer to go jogging instead though |
| 18:47:09 | dom96 | Araq: You could do both. |
| 18:47:23 | filwit | the manual would be good reference to respond to the grammer question? |
| 18:47:40 | filwit | heya, I was planning on going jogging today too |
| 18:47:58 | filwit | (probably won't happen like the last five times i planned to do it) |
| 18:48:13 | Araq | filwit: the grammar is in the manual but doesn't entirely relfect reality |
| 18:48:28 | filwit | okay, i'll post that then. |
| 18:48:30 | Araq | it comes pretty close as it's generated from the parser though |
| 18:49:47 | filwit | oh, btw, i ran into something rather annoying i didn't realize about overloading by typedesc[T].. that is, the compiler see's typedesc[Foo] and typedesc[Bar] as the same thing |
| 18:50:33 | Araq | well typedesc[T] has only recently got *somewhat* stable |
| 18:51:13 | * | DAddYE joined #nimrod |
| 18:51:33 | filwit | well I'm not asking why the code isn't working really, I will do the best to fix any bugs related to my problems from now on, but I wasn't sure if this was *wanted* behaviour or not |
| 18:51:38 | filwit | behavior* |
| 18:51:43 | filwit | is it? |
| 18:52:01 | Araq | no, makes no sense to me |
| 18:52:30 | Araq | of course the guy to really ask is in a never ending holiday |
| 18:52:41 | filwit | ah, i see |
| 18:53:34 | filwit | well for the moment it's not completely blocking my engine development. But I'm glad to hear it's not expected, and that the two different typedesc's should cause an overload. |
| 18:54:02 | filwit | i'll talk to Zahary more about how to fix it when he's back from vaca |
| 18:55:36 | dom96 | would be nice if someone could fix Aporia on Mac OS X: https://github.com/nimrod-code/Aporia/issues/49 |
| 18:57:52 | dom96 | filwit: s/grammer/grammar/ |
| 18:58:00 | dom96 | (On your reddit post) |
| 18:58:15 | filwit | k, let me update one sec |
| 18:59:57 | filwit | dom96: i have a Mac, I'll try and take a look at the bug sometime this weekend, but mostly am focused on getting my project rolling now. |
| 19:00:29 | filwit | i've been hunting this macro bug for the last three days.. damn VM is complicated to just jump right into |
| 19:01:20 | dom96 | Araq: Do you want me to fix #852? |
| 19:01:22 | filwit | oh, and where did OpenGL lib move too? Babel? |
| 19:01:32 | dom96 | filwit: yes |
| 19:01:38 | filwit | k |
| 19:04:49 | filwit | i hate the whole "who's backing this.." question.. |
| 19:05:28 | dom96 | This is just depressing :( http://www.reddit.com/r/programming/comments/1x8chx/dr_dobbs_nimrod_a_new_systems_programming_language/cf9iinr |
| 19:05:52 | filwit | i get why it's viable to a degree.. but it's like "oh, the language looks good, seems to be pretty stable and well designed, but i'm don't want to support it if no one else has already.." |
| 19:06:58 | filwit | i wouldn't say that's depressing, but it is slightly true |
| 19:07:47 | filwit | really, we need a "star app", Linux's Apache, MS's Visual Studios, etc |
| 19:07:59 | Araq | this post is not depressing, it is *spot on* |
| 19:08:26 | filwit | something that get's a lot of people interested in Nimrod because Nimrod was the language used to write said "star app" |
| 19:08:41 | Araq | filwit: even that doesn't really help |
| 19:08:56 | filwit | i think it will help a lot actually, but we will see |
| 19:09:10 | Araq | it's the old "killer app" idea |
| 19:09:28 | dom96 | The reality that we will likely never have a big corporate sponsor is not depressing? |
| 19:09:48 | Araq | Ruby got Rails, but Rails was a killer app to *build web apps* |
| 19:10:02 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 19:10:12 | filwit | yes exactly |
| 19:10:14 | Araq | it wasn't an some flying birds game |
| 19:10:44 | filwit | well obviously, i didn't mean some "consumable", lol |
| 19:11:04 | filwit | i think either dom's Jester or my Game Engine could fit the bill for "star app" |
| 19:11:28 | filwit | meaning it get's a lot more people using Nimrod because they want to do something with our project, and therefor need to use Nimrod |
| 19:14:41 | filwit | ultimately, we don't know what's around the corner, but Nimrod has a lot of potential so it doesn't really do anyone any good to think it'll never get anywhere |
| 19:22:04 | * | DAddYE_ joined #nimrod |
| 19:24:35 | * | DAddYE_ quit (Remote host closed the connection) |
| 19:25:08 | * | DAddYE_ joined #nimrod |
| 19:25:37 | * | DAddYE quit (Read error: Connection reset by peer) |
| 19:26:44 | Araq | well either way, getting 0.9.4 out with decent async support can't be bad for nim |
| 19:30:21 | dom96 | If you want it to be decent then we will need to have a period for porting the current sockets stuff to the new async as well as for testing. |
| 19:32:13 | dom96 | Getting all of that done could take months. |
| 19:40:47 | * | ics joined #nimrod |
| 19:57:29 | * | tdc joined #nimrod |
| 19:59:58 | * | xtagon joined #nimrod |
| 20:00:28 | * | XAMPP quit (Quit: Drink all the Booze; Hack all the Things; Kill all the Humans;) |
| 20:02:11 | * | carum joined #nimrod |
| 20:03:53 | * | [1]Endy joined #nimrod |
| 20:06:29 | * | [2]Endy quit (Ping timeout: 248 seconds) |
| 20:14:27 | * | io2 joined #nimrod |
| 20:40:41 | Araq | hi carum welcome |
| 20:41:13 | carum | /mode $me +x |
| 20:41:16 | carum | errr. |
| 20:41:17 | carum | hi |
| 20:46:01 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 21:10:14 | * | Demos joined #nimrod |
| 21:11:28 | Demos | filwit, you say your game engine could be a star app... got a link? |
| 21:12:36 | * | tdc quit (Quit: Leaving) |
| 21:14:20 | Araq | dom96: I think we really should change how the compiler generates the C filenames |
| 21:14:33 | Araq | nobody likes the way I do it :P |
| 21:14:46 | Demos | I was just thinking about that. We need to make it so that if my project is (wait for a gist) |
| 21:14:51 | filwit | Demos: no source code yet. initial design though can be found here: http://reign-studios.net/philipwitte/hymn/ |
| 21:15:42 | filwit | Demos: my statement about my project being the "star app" wasn't that it currently is, only that it's one of the projects that *could* be (there are a lot of people who want to write games) |
| 21:15:54 | Araq | we could make the compiler go up the hierarchy until it finds a babel file |
| 21:16:04 | Demos | yeah, I just wanted to look at some design. And nice design docs btw |
| 21:16:25 | Araq | the directory with the babel file in it is then the package name |
| 21:17:12 | filwit | Demos: thanks. Currently I have two code bases for the project, the engine is rendering instances polygons objects and I'm working on a basic animation system and editor. Once those two things are in a better state I'll put it on github. |
| 21:17:59 | filwit | Demos: the other code base for the project has to do with how the code connects to the editor through domain-specific macros. I'm currently fixing bugs in my way on that one, so Idk how long it will take. |
| 21:18:04 | * | brson joined #nimrod |
| 21:18:05 | Demos | https://gist.github.com/barcharcraz/207ad7e332a95880b1a4 |
| 21:19:39 | dom96 | Araq: sure |
| 21:20:12 | Araq | Demos: tbh I don't follow your proposal |
| 21:20:17 | Demos | I have been toying around with my ideas for a very decentrailized game engine (i.e the scene is really a list of procs and an id, the data is elsewhere), hitting those macro walls I was talking about yesterday. |
| 21:20:52 | Demos | and Araq I just mean that "external" modules will never import stuff from the local project |
| 21:21:19 | Araq | this is unfortunately not true, Demos |
| 21:21:26 | Demos | projectDir/winlean.nim would be user code that just happened to be in a file called winlean (contrived I know) |
| 21:22:02 | Araq | external modules can import from your project |
| 21:22:14 | Demos | I know Araq, I hit a hard to find bug a few days ago that convinced me it should be true, and I realized that it is somewhat related to changeing the names of c files |
| 21:22:36 | Araq | see the toy OS example on github |
| 21:22:45 | Araq | it introduces its own panicoverride |
| 21:23:06 | Araq | though I guess this should be done explicitly some pragma instead ... |
| 21:23:32 | filwit | Demos: this is essentially what I've been doing as well. I've toyed with lots of ideas with the Macros, and I have some cool ideas for how I can use domain-specific stuff for "built-in" state machine game-objects can use without performance overhead when they don't need them. Kinda like a blend between Unity3D and MS Expression Blend (if anyone's familiar with that software) |
| 21:24:18 | Araq | filwit: do you have a gist which triggers the 'unused' vm bug? |
| 21:24:37 | Araq | I feel like fixing something simple ... |
| 21:24:42 | Demos | right. I did like the builtin state machine things you had. I suppose you could have a vector of object ids that are going to jump and then a function that is called every frame to deal with those, callbacks could also happen |
| 21:24:44 | filwit | Demos: ultimately though, most of the game-engine is pretty straight forward. The only optimized way to do certain thing's is rather clear-cut by now, and I'm so i'm working on that. |
| 21:25:18 | filwit | Araq: I've been trying to isolate the problem for awhile now. I've recently found it has something to do with ocpNAdd inside an if-block. |
| 21:25:32 | Araq | lol |
| 21:25:35 | filwit | Araq: so i'll try and make a gist really fast based on that. |
| 21:25:45 | Araq | that's what I know already from your stack traces :P |
| 21:25:48 | Demos | I also don't really like having procs part of the ship type (presumably there is a vtable being generated and whatnot) |
| 21:26:06 | Demos | but who knows, you have the implementation experience |
| 21:26:50 | filwit | the thing about game-engine stuff is you're biggest concern is batching things. |
| 21:26:54 | filwit | for performance |
| 21:27:39 | filwit | you have to separate the execution of objects into isolated peice (i guess that could be said about any realtime-sensitic app which moves memory around) |
| 21:28:11 | filwit | and things are constantly spawning/dying, so you need to memory pool everything |
| 21:28:34 | filwit | my idea about 'part's isn't that they're complete classes like a Java/C# object |
| 21:28:37 | Demos | yeah, that is how I cam to the design I have been working on. I am not sure how well it will work though. By storing parts of the scene in globals (managed strictly ofc, they can appear to be part of a scene but they are not) I can actually know the type of all my things, and avoid type erasure completely |
| 21:28:51 | Demos | are they like "prefabs" |
| 21:28:52 | filwit | in fact, all allocation and deallocation is mostly editor defined for each 'part' |
| 21:29:39 | filwit | 'part's are mostly just 'logic' for and editor defined thing (although it works both ways, so programmers can define things the editor sees) |
| 21:30:18 | * | io2 quit (Remote host closed the connection) |
| 21:31:20 | Demos | I still do not like them bundled together, but the fact is they usually are, and I can see a transformation between what I am doing and what it looks like you are doing. |
| 21:32:04 | filwit | Demos: your idea is something similar to mine it seems (about storing globals). My idea is to have all software modules (mainly the 'Canvas') be regular game nodes, subject to state-machine editing |
| 21:34:34 | Demos | yeah, I have a type TSceneNode[T] = object[data: seq[seq[T]]] and a macro MakeComponent that if called like MakeComponent(int) will make a global var intSceneNode: TSceneNode[T] and an "add component" overload that takes a scene id and an int. Update functions are just proc updateInts(sceneId) = ... |
| 21:35:09 | filwit | Demos: it also means you control the rendering order completely, since Canvas can be a dependant child of the specific state of any other game-object. Eg. Gui objects which 'render' their own clipped-scene/mask-layers/etc. |
| 21:35:48 | Demos | well I hadle that by just calling each update function once per frame and expecting them to loop in whatever order they want |
| 21:36:12 | filwit | exactly |
| 21:36:38 | Demos | what is a dependent child? |
| 21:37:12 | filwit | call order |
| 21:38:02 | filwit | part's define a multi-directional hierarchy, or rather, their sub-parts do. |
| 21:38:26 | Demos | I think I would do that with an if WeAreInTheProperState: render, or have the proper state's signal the rendering code |
| 21:38:42 | filwit | the editor will reflect this and allow the scene to be sorted in different hiearchtical ways: Rendering, Physics, Project (user defined), etc.. |
| 21:41:34 | filwit | parts scan income 'var's for other known part types, and builds the appropriate execution trees |
| 21:42:15 | filwit | one for rendering, one for updating, etc. This is needed when you want user-defined rendering sorting control (like Unity's rendering layers) |
| 21:43:18 | Demos | my solution would jut be to look at the other components, it you want user defined rendering control than you would write a proc (and add it to the scene) that does that in a user defined way |
| 21:45:04 | filwit | The problem is then artist-type designers can't edit the rendering order at that point |
| 21:45:14 | filwit | you need editor control for popularity |
| 21:45:36 | filwit | and my idea is to remove much of the programming workload all together |
| 21:46:26 | filwit | look up Microsoft's Project Spark game's "scripting" and you'll see some of my directions for editor-defined things. |
| 21:46:51 | filwit | I encourage you to make your idea though |
| 21:47:17 | Araq | how many component parts are there in a typical engine? |
| 21:47:29 | Demos | right. The idea is that you define rendering order in code as essentially "undefined" and then have a update proc that goes and defines it in the way you want. all the trees and whatnot that you would have in a traditional "scene graph" would just be constructed locally or done via refs. We shall see. I have something like this (but without the global state thing) in c++, but c++ is just terrable |
| 21:47:54 | filwit | eventually it would be cool to work on a joined project with some of your folks here, so i'm glad to see a lot of interested people on the Nimrod community |
| 21:48:54 | filwit | Araq: quite a few, but mostly these mains ones: Rendering, Animation, Physics + Some form of Logic-block/scripting system. |
| 21:49:49 | Araq | well from time to time I think about how I would design a component system ;-) |
| 21:50:09 | filwit | you need good math libraries first, and good rendering techniques. I know how to do all those. Plus i'm going to port Reign SDK's modified Jitter Physics engine to Nimrod |
| 21:50:47 | filwit | Araq: it would be interesting to know your ideas on that. My main focus with mine is "editor driven" |
| 21:50:49 | Demos | Araq, apperently Prototype had: 1544 game object defs, 145 behaviors, and 335 data types (135 of those were props) |
| 21:52:24 | Demos | Also, I came to the conclusion you only need one callback like "event" avalible to each component |
| 21:52:38 | Araq | Demos: thanks for the numbers |
| 21:54:09 | Demos | that is from "Theory and Practice of Game Object Component Architecture" presented at GDC'09 |
| 21:54:11 | filwit | Demos: You usually need to seporate processing into "what executes per frame" and "what executes per physics-step", plus these days you also want "what executes per input-step" for raw-input devices + vsync systems |
| 21:55:19 | Araq | well I would design an entity as an object [header, data: array [0..0xff, ptr Component]] but don't allocate the full array, but only what's necessary |
| 21:55:25 | filwit | To do that, you could have one event object with a case statement, true, but I'm not sure exactly why you would want that really. The idea behind game-engines is to make things simple for everyone so they can focus on their app |
| 21:55:32 | filwit | ^ Demos |
| 21:56:20 | Demos | right, but those are not events that any run-of-the-mill system can trigger. My idea is that you have the OnUpdate event. And if instead of making more events you make more components so you only need to handle that one event |
| 21:56:23 | Araq | the header has a bitset which describes which components may exist |
| 21:57:13 | Araq | and then you need to know your data so that the uncommon components are stored towards the end of the array |
| 21:58:15 | filwit | Araq: are you doing this for performance reasons? You eventually need pools of each component type, so having a pool of (basically) seq[component] for top-level game objects (since their structures mostly only change on birth) |
| 21:58:43 | Araq | (instead of 'ptr Component' you might want indexes instead for networking and persistency) |
| 21:59:06 | Araq | filwit: the classic way is that the header tells you the offset of where to find the component afaict |
| 21:59:18 | Araq | but this is a double indirection |
| 22:00:03 | Demos | my idea is to have a seperate array for each component, that way I know their size. Ofc you need an indirect call /someplace/ but you can manage once per component type I think |
| 22:00:03 | Araq | in my scheme the Animation component would always be at the same offset |
| 22:00:28 | Demos | Araq, isnt that pretty much the same as a struct though |
| 22:00:46 | Araq | pretty much yes |
| 22:01:21 | Araq | but I have a bitset header :P |
| 22:01:58 | Araq | so it's a safe variable length struct ... perhaps |
| 22:02:24 | filwit | accept it's not variable length |
| 22:02:28 | filwit | except* |
| 22:02:49 | Araq | filwit: read what I wrote, it is |
| 22:03:24 | filwit | well i mean it has a max 0xff size |
| 22:03:37 | Araq | the array part is flexible length but you lie to the compiler |
| 22:03:48 | filwit | ah, i understand |
| 22:03:54 | Araq | well I thought 0xff is the upper bound |
| 22:04:00 | filwit | i thought you did that for memory performance of something |
| 22:04:14 | Demos | speaking of which, how does one do pointer arithmatic in nimrod? |
| 22:04:19 | Araq | well it's faster than a seq this way |
| 22:04:39 | filwit | 0xff is 16 unique items right? |
| 22:04:41 | Araq | Demos: fowl has a module for it, everybody else uses 'cast[int](x)' |
| 22:04:45 | filwit | or is that 256? |
| 22:04:51 | Araq | 256 |
| 22:04:58 | filwit | ah, okay that makes more sense |
| 22:05:53 | Demos | does fowl's module do a + 3 = a + sizeof(a) * 3? |
| 22:06:08 | Araq | Demos: I think so |
| 22:06:12 | Demos | sweet |
| 22:06:50 | Demos | I ended up needing to write a dynamic array that uses alloc because of the seq[T] bug |
| 22:07:01 | filwit | what my system does is, each core Service Node (Rendering, Physics, etc) maintains a list of objects. I'm not sure if I'll be using a linked-list of some for of memory pool for these entirely yet |
| 22:07:14 | Araq | Demos: you mean the 'newseq[T]' bug? |
| 22:07:18 | Demos | I do |
| 22:07:32 | Araq | ok, will fix that then now |
| 22:07:35 | Demos | can I make a seq with @[] to bypass that? |
| 22:07:35 | Araq | looks easy |
| 22:08:16 | Araq | you can do: var s: seq[T]; newSeq(s, sizeHere) I think |
| 22:08:20 | filwit | sorry, not list of objects, list of callbacks to parts that provide functionality to the service (through macro pragmas) |
| 22:08:35 | dom96 | Araq: Would it be easy to expand type aliases in error messages? |
| 22:08:46 | Araq | dom96: no |
| 22:08:57 | Araq | well it is very easy to do it |
| 22:09:11 | Araq | but it's also annoying as hell when you do it always |
| 22:09:32 | Demos | It is better than not having any idea what is wrong, maybe do it on --verbosity:4 |
| 22:09:36 | Araq | so the compiler needs to look at what it wrote and then annotate module.stuff where necessary |
| 22:09:36 | dom96 | It would be very useful in certain cases though. |
| 22:09:49 | filwit | yeah i'm going to work on my project now as well. I'll try and isolate the issue and make a gist for you to see later Araq |
| 22:10:01 | dom96 | Instead of having to hunt down the definition the compiler should be able to tell you. |
| 22:10:26 | Araq | dom96: as I said, it's very easy but I think the compiler should be smart instead of verbose |
| 22:10:44 | Araq | it should say 'int' unless it's 'myevilmodule.int' |
| 22:11:05 | dom96 | Make it smart then if you so wish. |
| 22:16:19 | Araq | lol, my workaround works |
| 22:16:40 | dom96 | whoo, accept works :) |
| 22:16:54 | Araq | and this means everybody uses newSeq[T](...) and nobody how it originally worked |
| 22:16:58 | * | carum quit (Remote host closed the connection) |
| 22:17:26 | Araq | except of course the compiler itself and so zahary missed he broke it ... |
| 22:18:02 | Araq | you guys should really program the same style the compiler uses ... :P |
| 22:18:31 | filwit | no.. |
| 22:18:40 | filwit | :P |
| 22:18:44 | EXetoC | wut |
| 22:19:12 | dom96 | I never use newSeq. |
| 22:19:16 | dom96 | @[] ftw |
| 22:19:25 | Demos | so I would say newSeq(s, sizeof(int)) or whatever |
| 22:19:39 | Araq | Demos: that is the workaround, yes |
| 22:19:52 | Araq | except for the 'sizeof(int)' part |
| 22:19:59 | Araq | you give to it the number of elements |
| 22:20:07 | Araq | like for the other newSeq |
| 22:20:22 | Demos | oh? and then newSeq(s) fails, it is not just newSeq[T]() that fails |
| 22:20:38 | Araq | just tested it |
| 22:20:51 | Araq | newsSeq(s, 32) # compiles |
| 22:21:02 | Araq | newSeq(s, 32) # compiles |
| 22:21:14 | Araq | s = newSeq[T](32) # fails |
| 22:21:41 | filwit | woah... what? |
| 22:21:51 | * | brihat quit (Ping timeout: 245 seconds) |
| 22:22:04 | filwit | template params can be passed to the regular param body? |
| 22:22:21 | filwit | param list* |
| 22:22:36 | filwit | or is that just an overload? |
| 22:23:24 | Araq | just an overload |
| 22:24:40 | filwit | oh wait duh, i was reading 's' as a typedesc |
| 22:27:06 | * | carum joined #nimrod |
| 22:27:33 | * | carum quit (Remote host closed the connection) |
| 22:27:38 | * | brihat joined #nimrod |
| 22:31:07 | Araq | funny bug |
| 22:31:17 | Araq | it works when I do this: |
| 22:31:34 | Araq | proc someOther[T](len: int): seq[T] = newSeq(result, len) |
| 22:31:35 | Araq | proc foo[T](x: T) = |
| 22:31:37 | Araq | var s = someOther[T](34) |
| 22:31:38 | Araq | #newSeq[T](34) |
| 22:31:40 | Araq | foo 23 |
| 22:32:06 | Araq | but not when I call newSeq instead of someOther even though newSeq is defined in exactly this way in system.nim |
| 22:42:05 | filwit | Araq: i isolated the problem I'm having with Macros. Here's a gist: https://gist.github.com/PhilipWitte/8873506 |
| 22:42:20 | filwit | i'll be trying to fix it |
| 22:42:58 | Araq | well that's easy |
| 22:43:17 | Araq | the 'if' statement has type 'void' because the 'else' statement has type 'void' |
| 22:43:17 | filwit | hint? |
| 22:43:47 | Araq | the 'then' block still has type PNimrodNode 'cause that's what 't.add' returns |
| 22:44:02 | filwit | ohh..... |
| 22:44:05 | Araq | well technically it got 'void' too |
| 22:44:25 | filwit | so i need a discard? it's just not giving good error messages? |
| 22:44:37 | Araq | no, it's a vmgen bug |
| 22:44:47 | Araq | 'discard' is only a workaround |
| 22:45:15 | filwit | damn, that works! |
| 22:45:26 | filwit | awesome, at least i can move on now. |
| 22:45:34 | Araq | hey |
| 22:45:39 | Araq | fix my vmgen bug instead |
| 22:45:43 | filwit | sure |
| 22:46:03 | filwit | though i'm not sure how exactly, what you're saying is genIf isn't doing what it's suppose to? |
| 22:46:19 | filwit | (i mean, that's the problem area right?) |
| 22:46:54 | * | psquid joined #nimrod |
| 22:46:57 | filwit | i hack-fixed it, let me revert my changes real quick |
| 22:57:48 | Araq | hmm the only strange thing about this bug is that it ever worked ... |
| 22:58:53 | filwit | i'm still not sure what's going on, i need to dumpTree and if statement to understand the node-tree better. one sec |
| 23:14:16 | dom96 | Araq: Are variables captured byval or byref in closures? |
| 23:14:26 | Araq | byref |
| 23:14:47 | Araq | unless it is not possibe :P |
| 23:15:04 | dom96 | So if I allocated some variable on the stack, pass its address to a C function and capture that variable in my closure then the variable will stay alive until the closure is executed? |
| 23:15:51 | Araq | yeah that should work |
| 23:17:20 | Araq | you don't allocate it on the stack then btw |
| 23:17:34 | Araq | the compiler allocates it in the heap for you then |
| 23:17:42 | dom96 | oh, interesting. |
| 23:19:44 | Araq | n.sons[0..0] = [callOp, calleeName] # splicing surely is unfamiliar |
| 23:25:49 | dom96 | yay, send works. |
| 23:26:27 | Araq | dom96: it's called '&=' now :P |
| 23:26:35 | EXetoC | can I add type-based overloads to the allocation procs? |
| 23:27:13 | Araq | EXetoC: yes but I won't merge until the 'newSeq' bug is fixed |
| 23:27:18 | EXetoC | actually, I don't know |
| 23:27:29 | Araq | otherwise the bug will affect those as well |
| 23:27:29 | dom96 | Araq: For now. I will delete those silly aliases one of these days... :P |
| 23:27:51 | Araq | dom96: and break generic programming? |
| 23:28:07 | dom96 | Also, it cannot work for this case. |
| 23:28:15 | dom96 | Since send returns a Future |
| 23:28:30 | Araq | I see, good point |
| 23:28:50 | dom96 | Araq: Remember when BitPuffin wanted to add all those little aliases? |
| 23:29:00 | EXetoC | Araq: should I include any pragmas? |
| 23:29:11 | EXetoC | dom96: such as? |
| 23:29:13 | Araq | EXetoC: make it inline procs |
| 23:29:14 | dom96 | Araq: You're halfway there :P |
| 23:29:16 | * | carum joined #nimrod |
| 23:29:17 | EXetoC | ok |
| 23:29:21 | dom96 | EXetoC: I can't remember |
| 23:29:33 | Araq | dom96: aliases are ruby style and everybody loves ruby |
| 23:29:38 | filwit | best solution is usually one alias IMO |
| 23:29:44 | Araq | so we'll copy ruby now |
| 23:29:44 | dom96 | Araq: I hate Ruby. |
| 23:29:47 | filwit | not everyone lovs ruby |
| 23:29:55 | filwit | i don't know about or love ruby |
| 23:30:03 | dom96 | Araq: Now, stop adding aliases! |
| 23:30:18 | * | Araq <3 Ruby |
| 23:30:52 | dom96 | I believe Araq is no longer of a sound mind. I am taking over this project. |
| 23:31:13 | Araq | you don't have what it takes |
| 23:31:15 | filwit | hostile takeover of Araq's repo |
| 23:31:17 | filwit | lol |
| 23:31:23 | Araq | you are not even an alcoholic yet |
| 23:31:45 | filwit | do you drink and program on Nimrod? |
| 23:31:56 | Araq | occasionally |
| 23:32:39 | filwit | (was a trick question. correct answer = "only on weekdays") |
| 23:33:00 | dom96 | Yeah, you better hope I don't become one or else nimrod-lang.org won't last long lol |
| 23:33:45 | Araq | hmm I keep forgetting about your admin powers |
| 23:33:46 | EXetoC | löl |
| 23:33:51 | filwit | lol |
| 23:34:07 | dom96 | :P |
| 23:34:21 | Demos | are aliases something more than just little functions that call other functions? I don't know ruby |
| 23:34:48 | filwit | they're different way to access the same behavior |
| 23:35:00 | filwit | s.new(...) vs s = TS.new(...) |
| 23:35:05 | filwit | ect |
| 23:35:08 | filwit | etc* |
| 23:35:42 | filwit | (and yes, they're just proc/template in Nimrod) |
| 23:35:49 | Demos | what is that TS. syntax? is that like method call syntax but with generics instead of the first param? |
| 23:36:12 | Araq | Demos: yes |
| 23:36:15 | filwit | no i just meant it's was s's type |
| 23:36:22 | filwit | err, yes |
| 23:36:26 | Demos | I figured, is it valid? |
| 23:36:38 | Araq | sometimes |
| 23:36:56 | filwit | proc foo(T:typedesc[Foo], ...) = # warning, doesn't overload entirely properly yet |
| 23:37:04 | Araq | I didn't create the feature so it's buggy :P |
| 23:37:23 | filwit | but does work when there's no ambiguity in the following parameters |
| 23:38:15 | filwit | you can write it shorter too: proc foo(t:type Foo, ...) |
| 23:39:47 | Araq | filwit: is that shorter notation documented? |
| 23:40:08 | filwit | idk, but it works |
| 23:40:21 | filwit | i haven't read through the docs in months |
| 23:40:48 | filwit | though i recently took a look at the tracking part |
| 23:41:10 | filwit | and the finally:/excpet: blocks, didn't realize they where stand-alone statements now, which is cool |
| 23:41:11 | Araq | well I'm not sure, |
| 23:41:12 | Demos | why the hell not just proc foo[T](Foo: T, ...)? |
| 23:41:32 | Demos | maybe that is just nicer for me because of c++ |
| 23:41:37 | Araq | type(x) is T if x's type is T |
| 23:41:52 | Araq | but type(T) is typedesc[T] ? |
| 23:42:08 | Araq | well it makes some sense I guess |
| 23:42:39 | Araq | is typedesc[typedesc[T]] == typedesc[T] ? |
| 23:43:00 | filwit | i just assumed it was typedesc[T], but I never really checked. I always write 'typedesc[T]' cause i wanted to avoid any added execution 'type T' would probably add |
| 23:43:04 | Demos | well type(typedesc[T]) could be a typedesc2 |
| 23:43:07 | Demos | or something like that |
| 23:43:39 | Demos | in the end types of types of types are not useful and having them is really just typesystem masterbation imo |
| 23:43:48 | Araq | Demos: no it would be typedesc[typedesc[T]] |
| 23:43:56 | Demos | true |
| 23:44:02 | EXetoC | let's cap it at typedesc99 then |
| 23:45:02 | Demos | typedescs are a really underdocumented concept... |