| 00:00:24 | filwit | dom96: interesting |
| 00:08:37 | filwit | how to iterate by ref/var in a for statement? |
| 00:10:05 | filwit | for ref x in someseq: ... somehow? or do i need to make an iterator which returns a var/ref type or something? |
| 00:10:37 | filwit | or do you just cast to a 'var T' inside the loop? |
| 00:10:45 | Araq | oh hell no |
| 00:11:00 | filwit | yeah i thought that sounded sketchy |
| 00:11:07 | Araq | you do it by system.mitems |
| 00:11:16 | filwit | okay |
| 00:11:20 | Araq | if that exists ... I don't remember |
| 00:11:26 | Araq | if not, write it |
| 00:11:57 | filwit | okay |
| 00:12:06 | Araq | I use an index fwiw, I prefer x[i] = ... over a = ... |
| 00:12:33 | Araq | in fact, I thought about requiring deref for 'var T' |
| 00:13:10 | filwit | i really don't think that's a good idea. i think iterating by ref is much cleaner code. the intent of the code is very clear |
| 00:13:40 | filwit | does this work, btw: for item, index in someseq.someIterator: ... ? |
| 00:13:54 | Demos | I like the way it works now. We really do not need the whole clusterfuck that is type qualifiers |
| 00:14:12 | filwit | i wasn't suggesting adding them |
| 00:14:14 | Araq | for index, item in pairs(...), filwit |
| 00:14:20 | filwit | Araq: thanks |
| 00:14:26 | Araq | however I think we should get rid of it |
| 00:14:38 | filwit | in favor of what? |
| 00:14:51 | Araq | this solution means you need a pairs iterator for every items you write |
| 00:15:06 | dom96 | Me and Araq discussed this before. |
| 00:15:08 | Araq | that's just absurd |
| 00:15:35 | Araq | instead we should do: |
| 00:15:51 | dom96 | and I forgot what we came up with |
| 00:16:22 | * | io2 quit (Ping timeout: 252 seconds) |
| 00:16:40 | Araq | template foreach(x, y: expr, body) {.immediate.} = |
| 00:16:49 | Araq | var i {.inject.} = 0 |
| 00:16:58 | Araq | for x in y: |
| 00:17:00 | Araq | body |
| 00:17:04 | Araq | inc i |
| 00:17:33 | Araq | it's ugly that it's no 'for' anymore but *shrug* |
| 00:18:03 | filwit | this for performance? |
| 00:18:19 | Araq | another solution was to have something like: |
| 00:18:34 | filwit | you mentioned not needing to always iterator over pairs, why is that a bad thing? performance? |
| 00:18:50 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:19:00 | Araq | for index i, item in x: where 'index' is keyword-like in this context |
| 00:20:11 | Araq | filwit: speed is not affected but 'pairs' is a more recent addition |
| 00:20:18 | filwit | i don't get the need for the keyword. doesn't the comma explain the purpose enough? |
| 00:20:26 | Araq | no, it doesn't |
| 00:20:35 | filwit | what is the ambiguity? |
| 00:20:42 | Araq | for x, y in table # invokes the pairs iterator |
| 00:20:55 | Araq | for x in seq # invokes the items iterator |
| 00:21:03 | dom96 | If anything we should go for full explicitness: for i: int, item: var T in x: |
| 00:21:20 | filwit | Araq: that sounds perfect, that's how it works right now? |
| 00:21:29 | Araq | filwit: yes |
| 00:21:39 | filwit | why change it then? that's a great system? |
| 00:21:41 | EXetoC | dom96: ok,but that doesn't have to be the index |
| 00:21:49 | Araq | but this means you need to come up with lots of 'pairs' iterators |
| 00:21:56 | Araq | which are boilerplate |
| 00:22:15 | Araq | also if you have items and mitems you then need pairs and mpairs ... |
| 00:22:22 | filwit | this is why you need an "OOP" lib, to write that boilerplate for you.. |
| 00:22:33 | Demos | https://gist.github.com/barcharcraz/4543b539411eebdeb841 |
| 00:22:36 | Demos | is that a bug |
| 00:23:59 | Araq | Demos: zahary thinks so, I'm not sure |
| 00:24:00 | dom96 | ahh, and we can't just define a generic pairs since generic iterators are not supported right? |
| 00:24:16 | Araq | wrong |
| 00:24:20 | Araq | generic iterators work |
| 00:24:37 | filwit | Araq: somewhere you could just write a macro 'loop' which transformed a iterator into two procs, items & pairs. then use it as a pragma |
| 00:24:37 | Araq | and yeah that sounds like an idea, dom96 |
| 00:24:42 | * | Araq feels stupid |
| 00:24:46 | dom96 | haha |
| 00:24:58 | EXetoC | I knew you didn't know your stuff |
| 00:25:09 | filwit | 'loop's probably a bad name of course |
| 00:26:58 | filwit | yeah nevermind, dom's solution is much better |
| 00:30:18 | filwit | mitems doesn't exist, btw |
| 00:30:25 | filwit | hmmm.. |
| 00:33:57 | filwit | for i, s in e.services: s[i].update() # Error: for a 'var' type a variable needs to be passed |
| 00:34:29 | NimBot | Araq/Nimrod devel 6e3f194 Araq [+0 ±2 -0]: compiles on sparc again |
| 00:35:22 | Araq | filwit: this is not how it works |
| 00:36:37 | Araq | for i, s ....: s[i] # wtf? |
| 00:36:40 | NimBot | dom96/jester master ef675d4 Dominik Picheta [+0 ±1 -0]: Change default staticDir to use getCurrentDir() |
| 01:08:50 | * | ics joined #nimrod |
| 01:25:14 | * | pe7ed27 joined #nimrod |
| 01:30:01 | * | [Pete_27] quit (*.net *.split) |
| 01:33:25 | Demos | so if I want access to the typename of a typedesc in a macro what should I do? |
| 01:34:55 | Araq | wait for zahary to fix the typedesc issues |
| 01:35:14 | Demos | wonderful |
| 01:35:25 | Araq | or alternatively wait until he blames me for it |
| 01:35:46 | Araq | you could pass the type name to the macro yourself, you know |
| 01:36:10 | Demos | what do you mean? |
| 01:36:19 | Demos | just as an expr? |
| 01:36:33 | Araq | as a string |
| 01:36:40 | Araq | but as an expr is worth a try too |
| 01:37:15 | Demos | right, so do T.name in a generic and then pass that to the macro |
| 01:37:45 | Demos | does nimrod have c++ style generic specialization? |
| 01:38:02 | NimBot | Araq/Nimrod devel d87579f Araq [+0 ±3 -0]: fixes #885 |
| 01:38:24 | Araq | Demos: pretty much |
| 01:40:26 | Araq | dom96: please try again |
| 01:40:40 | Araq | but I don't think that fixes it already |
| 01:40:52 | Araq | good night |
| 01:40:54 | Demos | I have a global that I am generateing in a macro with a name like typeSceneNode and I need a proc that returns a SceneNode based on the type. Essentially just pasteing the type's name and "SceneNode" together to form an identifier. I was thinking I could generate a specialized generic proc along with the global that retrives it |
| 01:59:09 | * | brson quit (Quit: leaving) |
| 01:59:42 | * | brson joined #nimrod |
| 02:03:06 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 02:33:21 | * | DAddYE quit (Remote host closed the connection) |
| 02:33:49 | * | DAddYE joined #nimrod |
| 02:35:05 | Demos | can generics take compile time constant values as type params? |
| 02:36:49 | Demos | never mind |
| 02:37:59 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 02:42:59 | * | DAddYE joined #nimrod |
| 02:43:15 | * | DAddYE quit (Client Quit) |
| 02:45:45 | dom96 | Araq: --cs:partial is default now? |
| 02:49:29 | dom96 | Araq: Yeah, it still crashes. |
| 02:53:14 | Demos | static[T] generic args do not seem to work |
| 02:57:00 | dom96 | good night |
| 03:25:27 | EXetoC | Demos: that's slightly different from the example. for a long time now, only types and range values have been allowed for type parameters |
| 03:26:04 | Demos | the only difference is that I removed the Number constriant on T |
| 03:26:16 | Demos | but still, that is super annoying |
| 03:26:34 | EXetoC | https://bitbucket.org/BitPuffin/linagl/src/9f05f3b06186a4fbc41d347e3121befdf157e65d/src/linagl/matrix.nim?at=default |
| 03:26:46 | Demos | right, I saw that |
| 03:26:47 | * | xtagon joined #nimrod |
| 03:26:57 | EXetoC | ok |
| 03:27:15 | xtagon | Hey everyone |
| 03:27:35 | EXetoC | hello there, human |
| 03:27:37 | Demos | but just allowing any kind of constant values would be nice, or even just a small subset like integers and chars |
| 03:27:40 | EXetoC | or bot. who knows |
| 03:28:24 | xtagon | I'm human as far as I can tell. There is always the possibiltiy that I'm a bot programmed to think I'm human. |
| 03:29:04 | EXetoC | Demos: I'm pretty sure it's planned, but it was months ago that bitpuffin asked about it |
| 03:30:01 | Demos | for a "classical" linear algebra library it is pretty critical, I am thinking of just trying to wrap eigen, but it would be hella messy and require cpp codegen |
| 03:30:03 | EXetoC | moaaar metaprogramming :> |
| 03:41:04 | Demos | hm how do I even go about wrapping a library that needs this kind of stuff when I can not use constant template params? ... templates could work |
| 03:45:07 | EXetoC | just not between brackets I think |
| 03:45:14 | EXetoC | I guess you can wrap it somehow |
| 03:46:19 | Demos | yeah. It is /really/ tricky since you /MUST/ use value typers for this sort of thing |
| 03:48:55 | EXetoC | linagl's approach isn't relevant? |
| 03:49:17 | EXetoC | you could treat ranges as integers if you really wanted to |
| 03:59:11 | Demos | well if I wanted linagl's approach I would just use linagl. Using ranges is far from ideal |
| 04:09:27 | Demos | I was all looking forward to how much c++ style metaprogramming improved when "member functions" are no longer tied to the object |
| 04:13:47 | Varriount | Hi guys |
| 04:14:02 | Varriount | Sorry I haven't been on all day, I've been feeling a bit sick |
| 04:14:51 | * | Varriount sneezes on Demos |
| 04:21:07 | * | DAddYE joined #nimrod |
| 04:22:51 | * | XAMPP joined #nimrod |
| 04:40:10 | xtagon | What's up Varriount? |
| 04:40:52 | Varriount | Not much. I"m likely gonna have to stay up all night and all day in order to get my sleep schedule back on track |
| 04:41:14 | Varriount | When you wake up at 8 in the afternoon, something is wrong. |
| 04:41:54 | xtagon | That's no fun. Happened to me when I was sick a couple weeks ago. |
| 04:42:04 | xtagon | Hard to sleep when you're vomiting all night |
| 04:42:16 | Varriount | >_< |
| 04:42:29 | Varriount | In the meantime, I'm gonna work on a nimrod port of python's itertools. |
| 04:43:18 | Varriount | (Although, I have no idea how to implement the permutation or combinatorial generators) |
| 04:43:24 | xtagon | Cool. I'm re-writing some Ruby scripts into Nimrod programs because I hate having to re-install their dependancies every time I change the system Ruby version |
| 04:43:59 | Demos | Varriount, you crashed skyrim and made my controller get stuck in vibrato mode... look what you have done! |
| 04:44:24 | Varriount | Good. I've never played skyrim. Now you can share my pain. |
| 04:45:21 | Demos | I wrote like 5 lines of code today... ran into compiler bug after compiler bug |
| 04:46:14 | Varriount | *shrug* what do you expect, when nimrod has 2-3 compiler devs, with no big backing from other companies. |
| 04:46:34 | Varriount | Quite frankly, I'm astonished at how much Araq has done. |
| 04:46:58 | Varriount | Demos: What kind of compiler bug? |
| 04:51:04 | * | DAddYE quit (Remote host closed the connection) |
| 04:51:30 | * | DAddYE joined #nimrod |
| 04:53:51 | Varriount | Huh. Today I learned that you can drag a folder or file onto the command prompt to get its path pasted in. |
| 04:55:51 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 04:55:58 | Demos | wowah neat |
| 04:56:20 | Demos | Varriount, the now-solved newSeq[T] bug and the fact that static[T] type params do not work |
| 04:57:52 | Varriount | Demos: That newseq bug is still apparent |
| 04:58:03 | Varriount | Or rather, I think Araq mistakenly closed it. |
| 04:59:25 | Varriount | Since the commit that closed it has nothing to do with newSeq[], just thread analysis, and also the fact that the latest nimrod versions (built from latest devel about 5 minutes ago) still show the bug. |
| 05:03:22 | * | shodan45 quit (Remote host closed the connection) |
| 05:03:41 | * | shodan45 joined #nimrod |
| 05:07:42 | Varriount | Hi shodan45 |
| 05:09:20 | Demos | oh, damn |
| 05:10:09 | * | DAddYE joined #nimrod |
| 05:22:04 | Varriount | Demos: Am I correct? |
| 05:29:34 | Varriount | Gr. parseutils isn't compiling for my itertools module |
| 05:34:18 | Demos | maybe, I ended up working around it |
| 05:34:47 | Demos | I was having a problem making a proc that returned a seq[T] though |
| 05:34:53 | Demos | a generic proc that is |
| 05:46:20 | Varriount | Demos: This is odd. My itertools module has little unit tests, the way that the stdlib tends to have. |
| 05:46:36 | Varriount | And they don't work anymore, despite once working |
| 05:47:36 | Varriount | And they don't work anymore, despite once working |
| 05:47:48 | Varriount | Woops, sorry, wrong window |
| 05:51:20 | Varriount | Demos: Can you look at this and tell me if anything is wrong with it? -> https://gist.github.com/Varriount/8894927 |
| 06:00:11 | * | xtagon quit (Quit: Leaving) |
| 06:11:24 | * | DAddYE quit (Remote host closed the connection) |
| 06:11:51 | * | DAddYE joined #nimrod |
| 06:15:45 | * | [1]Endy joined #nimrod |
| 06:16:03 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 06:56:34 | * | DAddYE joined #nimrod |
| 07:07:45 | * | shodan45 quit (Quit: Konversation terminated!) |
| 07:08:02 | Demos | what error are you getting? |
| 07:08:15 | Demos | cause I think I was getting errors with generic iterators as well |
| 07:09:43 | * | brson_ joined #nimrod |
| 07:10:55 | * | brson quit (Ping timeout: 246 seconds) |
| 07:26:50 | * | vbtt joined #nimrod |
| 07:27:08 | * | awestroke joined #nimrod |
| 07:31:59 | * | vbtt quit (Quit: Bye) |
| 08:01:16 | * | foodoo joined #nimrod |
| 08:23:11 | Araq | Varriount: afaict I fixed the 'newSeq' bug |
| 08:23:24 | Araq | the example still doesn't compile but that's because it makes no sense |
| 08:23:53 | Araq | temp3.nim(32, 32) Error: type mismatch: got (TSet[seq[int]], TSet[int]) |
| 08:23:54 | Araq | but expected one of: |
| 08:23:56 | Araq | system.==(x: bool, y: bool): bool |
| 08:23:57 | Araq | ... |
| 09:01:51 | * | aftersha_ joined #nimrod |
| 09:03:58 | * | delian66 quit (Quit: Terminated!) |
| 09:08:39 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:23:41 | Araq | dom96: for your gist, I get |
| 09:23:48 | * | renesac|away quit (Ping timeout: 252 seconds) |
| 09:23:52 | Araq | "undeclared identifier: p" |
| 09:23:55 | Araq | -.- |
| 09:24:29 | * | Araq can't fix compiler bugs with code that cannot reasonably compile |
| 09:47:00 | * | DAddYE quit (Remote host closed the connection) |
| 09:47:59 | * | Demos quit (Read error: Connection reset by peer) |
| 10:16:22 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 10:17:33 | * | aftersha_ joined #nimrod |
| 10:18:32 | * | [2]Endy joined #nimrod |
| 10:22:09 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 10:26:18 | * | brson_ quit (Quit: leaving) |
| 10:42:30 | * | [1]Endy joined #nimrod |
| 10:44:53 | * | [2]Endy quit (Ping timeout: 248 seconds) |
| 10:45:00 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 10:47:21 | * | [2]Endy joined #nimrod |
| 10:48:07 | * | DAddYE joined #nimrod |
| 10:50:36 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 10:52:37 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 11:17:57 | dom96 | Araq: gah: https://gist.github.com/dom96/61bb0b210ec7497565d5 |
| 11:38:31 | * | DAddYE joined #nimrod |
| 11:40:09 | * | io2 joined #nimrod |
| 11:40:27 | Araq | dom96: for the new async/sockets stuff please use -d:useSSL instead of -d:SSL |
| 11:40:43 | Araq | the 'use', 'no' prefixes are a convention now |
| 11:41:04 | dom96 | Right ok. But I still think we should separate defined() and compilerDefined() |
| 11:42:58 | * | DAddYE quit (Ping timeout: 252 seconds) |
| 11:52:53 | * | zahary quit (Quit: Leaving.) |
| 11:53:10 | * | zahary joined #nimrod |
| 11:55:17 | Araq | I agree |
| 11:55:29 | Araq | it breaks code in very subtle ways though |
| 11:55:48 | zahary | hi, I'm back home |
| 11:55:53 | Araq | unless we special case the list of currently existing defines |
| 11:56:05 | Araq | then the compiler could issue a warning |
| 11:56:08 | dom96 | zahary: hey |
| 11:56:15 | Araq | that your code will ignore forever :P |
| 11:56:18 | dom96 | zahary: Have you read our async discussion yesterday? |
| 11:56:19 | Araq | hi zahary wb |
| 11:56:49 | Araq | the world depends on your bugfixes |
| 11:56:55 | Araq | are you happy? ;-) |
| 11:57:11 | dom96 | Araq: I think getting rid of warnings might actually be one of the good things Go has done. |
| 11:58:02 | Araq | dom96: no, that doesn't work, you need them at least for transition periods |
| 11:58:09 | zahary | dom96: for the async stuff, there was a more detailed gist that was originally yours I think - you showed me some example transformations and I wrote some counter examples |
| 11:59:44 | dom96 | Araq: Transition periods? |
| 12:00:21 | Araq | just look at the deprecation of the 'nil' statement |
| 12:00:43 | Araq | according to you the compiler should error out already, breaking every single project out there |
| 12:00:49 | dom96 | oh I see. |
| 12:00:56 | dom96 | Yeah, true. |
| 12:01:22 | dom96 | But people are lazy. I still haven't fixed the nil stuff in any of my projects. |
| 12:01:28 | dom96 | If it was an error I would be forced to do so. |
| 12:02:08 | Araq | no, this doesn't work |
| 12:02:14 | dom96 | zahary: I'm trying to find it now. Can you look at asyncio2 and see if i'm doing it right? |
| 12:02:39 | dom96 | https://gist.github.com/dom96/0c73a80b0dba2453956a |
| 12:02:43 | dom96 | That's it, isn't it? |
| 12:02:51 | Araq | we don't even recompile stuff that often |
| 12:02:55 | zahary | yeah, that's it |
| 12:03:07 | Araq | others told us aporia doesn't compile with devel, dom96 |
| 12:03:12 | dom96 | Araq: true |
| 12:03:46 | dom96 | zahary: Ahh. It looks like your example does it exactly the same way Araq suggested to me yesterday. |
| 12:05:47 | dom96 | I wonder if maybe i should just provide one completion callback with no params. The user can always capture the future. |
| 12:07:38 | Araq | dom96: I need Future[T] for the new concurrency stuff too. I wonder if we should use different types or the same types |
| 12:08:32 | Araq | but I don't think they can share the implementation ... |
| 12:08:56 | dom96 | Why not? |
| 12:09:01 | Araq | will use Delayed[T] then instead I guess |
| 12:09:31 | dom96 | It would be nice to keep the types the same. |
| 12:09:45 | dom96 | What will it be used for in your new concurrency stuff? |
| 12:10:16 | Araq | dom96: my stuff needs compiler support and needs to be safe for inter thread communication |
| 12:11:49 | dom96 | It's still a value container though right? |
| 12:12:08 | Araq | right |
| 12:12:09 | dom96 | Is it a promise to a threads return value? |
| 12:12:17 | Araq | right |
| 12:12:55 | dom96 | How about you call it ThreadFuture and inherit from Future? |
| 12:13:13 | Araq | your Future[string] can have a trivial implementation, mine requires voodoo |
| 12:13:55 | Araq | meh what's the point in inheritng from your Future, they are incompatible |
| 12:14:12 | dom96 | They will share the same interface, no? |
| 12:14:17 | dom96 | i.e. callbacks. |
| 12:14:21 | Araq | no |
| 12:14:34 | dom96 | How will yours work then? |
| 12:16:49 | Araq | proc read*[T](f: var Future[T]): T = |
| 12:16:50 | Araq | if f.isNil: |
| 12:16:52 | Araq | raise newException(EInvalidValue, "attempt to read from future twice") |
| 12:16:53 | Araq | let w = f |
| 12:16:55 | Araq | f = nil |
| 12:16:56 | Araq | await(w.resultReady) |
| 12:16:58 | Araq | result = w.copyResult(w.result) |
| 12:16:59 | Araq | signal(w.resultRead) |
| 12:17:21 | dom96 | Why disallow multiple reading? |
| 12:17:35 | Araq | 'await' and 'signal' operate on condition variables here |
| 12:18:12 | Araq | dom96: because it simplifies things |
| 12:18:14 | dom96 | You should store the value in the future. |
| 12:18:30 | dom96 | It will be an annoying gotcha. |
| 12:18:30 | Araq | no |
| 12:18:37 | dom96 | Because my futures allow this. |
| 12:18:46 | dom96 | And then people will get confused. |
| 12:18:52 | Araq | well I will name it Delayed[T] |
| 12:19:07 | Araq | no confusing, it works differently and has a different name |
| 12:19:46 | Araq | this is designed for max performance, dom96 |
| 12:19:48 | dom96 | Is there any way to tell when yours can be read without blocking? |
| 12:20:38 | dom96 | Maybe I could wrap your Delayed in my own Future :P |
| 12:20:46 | Araq | good question |
| 12:21:07 | Araq | let me see if posix's condition vars support that |
| 12:21:09 | dom96 | For those who can sacrifice some performance for consistency |
| 12:22:28 | dom96 | but anyway, please fix the bug. |
| 12:22:50 | dom96 | I have homework to get done unfortunately. |
| 12:23:17 | Araq | yeah, that can be easily supported |
| 12:23:32 | Araq | pthread_cond_timedwait() |
| 12:30:51 | zahary | dom96: I've added one more comment to the gist |
| 12:31:31 | dom96 | zahary: This is my current prototype: https://gist.github.com/dom96/61bb0b210ec7497565d5#file-gistfile1-nim-L28 |
| 12:39:12 | * | DAddYE joined #nimrod |
| 12:39:18 | zahary | do you do the equivalent of my wrapYield on the second yielding from the iterator? |
| 12:42:26 | dom96 | yeah, that happens in cbVoid |
| 12:43:24 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 13:01:15 | Araq | bbl |
| 13:18:27 | foodoo | btw: what does "bbl" stand for? be back later? |
| 13:18:31 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 13:18:40 | dom96 | ya |
| 13:19:46 | * | darkf quit (Quit: Leaving) |
| 13:23:53 | * | renesac joined #nimrod |
| 13:39:56 | * | DAddYE joined #nimrod |
| 13:44:07 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 13:49:25 | * | aftersha_ joined #nimrod |
| 14:01:58 | * | io2 quit () |
| 14:03:37 | * | foodoo quit (Ping timeout: 250 seconds) |
| 14:19:27 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 14:30:29 | * | filwit quit (Ping timeout: 248 seconds) |
| 14:38:56 | * | awestroke quit (Remote host closed the connection) |
| 14:39:41 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 14:40:41 | * | DAddYE joined #nimrod |
| 14:44:53 | * | DAddYE quit (Ping timeout: 248 seconds) |
| 15:11:27 | EXetoC | Araq: why is ObjectID represented by Toid? I suppose it was a matter of simplicity |
| 15:11:57 | EXetoC | and there's currently no cross-platform way to get the hostname, right? and then there's the process ID |
| 15:12:09 | EXetoC | but it doesn't matter. I'll keep it simple for now |
| 15:14:00 | Araq | tester/testament/backend.nim shows how to get the hostname |
| 15:15:16 | EXetoC | I should've examined the grep output more carefully |
| 15:19:10 | EXetoC | 'when' as an expression. neat |
| 15:19:51 | * | micklat joined #nimrod |
| 15:41:27 | * | DAddYE joined #nimrod |
| 15:44:06 | EXetoC | ok JSON can't be used. all BSON types needs to be represented |
| 15:45:53 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 16:08:05 | Araq | micklat: no time for a proper forum answer but you can do ~foo.bar(baz) where ~ is a macro that then rewrites it to what you need |
| 16:08:24 | Araq | I picked ~ cause it looks like a snake |
| 16:09:28 | EXetoC | clever |
| 16:20:39 | micklat | thanks for the tip. I still haven't looked into the delegates that Zahary suggested. |
| 16:23:31 | * | BitPuffin joined #nimrod |
| 16:23:44 | BitPuffin | dom96: I will be steraming soon so finish your homework |
| 16:23:48 | BitPuffin | dom96: or at least me ready to rt |
| 16:31:04 | Araq | the delegates will get a different syntax |
| 16:31:33 | Araq | so ... I now have a desktop that *scrolls* on win7 |
| 16:31:45 | Araq | any idea how to go back to the normal resolution? |
| 16:32:00 | Araq | and no, I didn't change the resolution |
| 16:32:13 | Araq | but something else by chance |
| 16:34:24 | dom96 | BitPuffin: I am ready |
| 16:34:36 | dom96 | well, i have one more homework exercise to do |
| 16:34:43 | dom96 | but i'm eating right now anyway |
| 16:35:00 | dom96 | Araq: ETA on bug fix? |
| 16:36:41 | Araq | ~1 hour |
| 16:37:27 | EXetoC | dom96: dude, you need to get one of those treadmill desks |
| 16:38:02 | dom96 | EXetoC: lol why? |
| 16:42:12 | * | DAddYE joined #nimrod |
| 16:44:00 | * | DAddYE_ joined #nimrod |
| 16:44:00 | * | DAddYE quit (Read error: Connection reset by peer) |
| 16:45:26 | BitPuffin | dom96: okay sweet then it will be nice |
| 16:48:26 | * | DAddYE_ quit (Ping timeout: 246 seconds) |
| 16:52:43 | dom96 | BitPuffin: So what are you going to be working on again? |
| 16:58:07 | * | ics joined #nimrod |
| 16:59:19 | EXetoC | dom96: efficiency |
| 17:01:09 | EXetoC | in terms of KLOC's per minute |
| 17:08:58 | dom96 | Doesn't sound very practical |
| 17:23:01 | * | [1]Endy joined #nimrod |
| 17:30:57 | micklat | delegators don't seem to support calls of the form a.b.c(x,y,z) where b is not recognized as a member of a, or do they? what happens when the member accesses are nested? |
| 17:42:39 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 17:44:05 | * | aftersha_ joined #nimrod |
| 17:44:47 | * | DAddYE joined #nimrod |
| 17:46:25 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 17:49:21 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 18:01:32 | * | filwit joined #nimrod |
| 18:11:48 | filwit | http://i.imgur.com/jVqCc95.gif |
| 18:12:21 | Araq | honey badger? |
| 18:12:25 | filwit | found on reddit labeled "Honey badgers don't give a shit" |
| 18:12:30 | filwit | lol |
| 18:12:39 | filwit | thought it was relevant |
| 18:14:19 | * | foodoo joined #nimrod |
| 18:15:49 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 18:27:33 | * | XAMPP quit (Quit: Drink all the Booze; Hack all the Things; Kill all the Humans;) |
| 18:31:56 | Araq | zahary: this scope based lambda lifting doesn't work |
| 18:32:46 | Araq | it's way too complex to figure out the "proper" scope where the closure should be generated |
| 18:33:12 | Araq | I think we should really allocate on function entry and be done with it |
| 18:33:27 | Araq | this also has the benefit of matching JS's semantics |
| 18:33:56 | Araq | and is more efficient |
| 18:34:12 | OrionPK | araq im getting an error on devel (but not main) compiling my templates.nim module |
| 18:34:14 | OrionPK | identifier expected, but found '(open|open|open)' |
| 18:34:41 | OrionPK | when I call value.parse_to_close(index, open='{', close='}') |
| 18:35:16 | OrionPK | signature: parse_to_close(value: string, index: int, open,close: char) |
| 18:35:58 | Araq | OrionPK: is parse_to_close a template? |
| 18:36:08 | OrionPK | no, it's a proc |
| 18:39:13 | Araq | OrionPK: make a bug report, but it's trivial to fix |
| 18:41:18 | OrionPK | k |
| 18:45:30 | * | DAddYE joined #nimrod |
| 18:47:11 | OrionPK | araq it is being called from w/in a template |
| 18:47:26 | Araq | OrionPK: I know |
| 18:47:40 | OrionPK | ok |
| 18:48:14 | dom96 | BitPuffin: well? You streaming or what? |
| 18:49:26 | dom96 | Nope, he's playing Dota... |
| 18:50:03 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 18:54:09 | BitPuffin | lol |
| 18:54:11 | BitPuffin | noob dom96 |
| 18:55:08 | EXetoC | BitPuffin: your game should be at v1.2 now according to my estimates :> |
| 18:55:45 | BitPuffin | EXetoC: :P |
| 18:57:48 | Araq | BitPuffin: I want a new realtime strategy game, build one |
| 18:57:59 | dom96 | BitPuffin: who u calling newb u newb |
| 19:01:57 | BitPuffin | Araq: buy one |
| 19:02:00 | BitPuffin | dom96: you! |
| 19:02:06 | BitPuffin | Okay I'm gonna poop and then stream |
| 19:06:30 | OrionPK | streamed poop? |
| 19:06:32 | OrionPK | world first? |
| 19:07:01 | dom96 | Yep. It's for the Olympics. |
| 19:07:09 | EXetoC | that's where the tubes come in |
| 19:07:28 | EXetoC | Ted Stevens was on to something after all |
| 19:09:14 | OrionPK | i havent been able to watch much lympics this year |
| 19:11:12 | * | comex_ is now known as comex |
| 19:11:25 | dom96 | I haven't watched any of it yet. |
| 19:11:45 | dom96 | The only reason I am even aware it's happening is because of reddit. |
| 19:12:06 | OrionPK | ah |
| 19:12:10 | OrionPK | im watching ski jumpin now |
| 19:18:33 | * | Mat3 joined #nimrod |
| 19:18:36 | Mat3 | hi all |
| 19:19:57 | * | foodoo quit (Ping timeout: 250 seconds) |
| 19:20:40 | BitPuffin | dom96: it's live |
| 19:20:44 | BitPuffin | can you come check if shit is working |
| 19:20:56 | dom96 | Yep. Seems to work. |
| 19:21:11 | dom96 | The image size is a bit small though. |
| 19:21:48 | micklat | Araq: if I override `~`, won't it break the other uses of this character? |
| 19:22:15 | Mat3 | Araq: Read the Dr. Dobbs article, nice overview |
| 19:22:26 | Araq | oh hi Mat3 |
| 19:22:36 | micklat | I'd have to do it as an immediate macro, so I won't have type info telling me that the first element in the path is a python object |
| 19:22:37 | BitPuffin | dom96: I know |
| 19:22:44 | BitPuffin | dom96: I'm trying to make sure music and shit works |
| 19:22:47 | dom96 | BitPuffin: that's better. |
| 19:23:09 | BitPuffin | dom96: I have set up sound wrong |
| 19:23:24 | dom96 | The delay is quite large lol |
| 19:23:38 | Araq | micklat: ~ isn't used in system.nim and you can always do: import foo except `~` |
| 19:24:22 | BitPuffin | dom96: yeah |
| 19:24:25 | BitPuffin | dom96: tell me if you hear music |
| 19:24:33 | dom96 | BitPuffin: will do |
| 19:25:02 | dom96 | BitPuffin: I can hear your mic if that helps |
| 19:25:06 | micklat | I see in the manual that ~ is used in patterns, so a module author will have to avoid mixing the two uses in the same module, right? |
| 19:26:32 | dom96 | BitPuffin: yeah, you fixed it. |
| 19:27:12 | BitPuffin | dom96: alright it seems to be working |
| 19:27:15 | BitPuffin | let me just tweet then |
| 19:27:23 | Araq | micklat: ~ for patterns is special cased, it won't cause a conflict, I think |
| 19:27:24 | dom96 | You already tweeted like twice lol |
| 19:27:41 | micklat | I think I'll try |
| 19:28:09 | Araq | micklat: but surely this is only a temporary solution until overloading of '.' works satisfactory |
| 19:28:17 | BitPuffin | if you guys wanna watch http://www.twitch.tv/bitpuffin |
| 19:28:44 | micklat | Araq: I hope so. Any idea when you might get to that? |
| 19:29:06 | dom96 | BitPuffin: That music is very relaxing. |
| 19:29:20 | BitPuffin | dom96: hell yeah |
| 19:29:25 | BitPuffin | dom96: can you hear me well over it? |
| 19:29:34 | EXetoC | also, got a rough estimate for user-defined copy construction? |
| 19:29:46 | dom96 | BitPuffin: yeah |
| 19:30:19 | Araq | neither '.' nor overloading of '=' are for 0.9.4 and '.' isn't really required for version 1 ... sorry |
| 19:30:26 | filwit | how to get the module name from insdie a macro? |
| 19:30:40 | dom96 | BitPuffin: hrm, the video seems to freeze when you're using the terminal |
| 19:30:42 | EXetoC | ok |
| 19:30:47 | Araq | filwit: I don't think you can get this information |
| 19:30:50 | dom96 | BitPuffin: something weird is happening. |
| 19:30:59 | BitPuffin | dom96: what? |
| 19:31:00 | filwit | Araq: :-\ k |
| 19:31:17 | filwit | Araq: the filename? |
| 19:31:31 | dom96 | BitPuffin: yeah, it's weird. |
| 19:31:37 | dom96 | BitPuffin: let me refresh |
| 19:31:41 | Araq | there is macros.lineinfo iirc |
| 19:32:04 | * | ics joined #nimrod |
| 19:32:06 | filwit | ah, right, that was it |
| 19:32:12 | filwit | thanks |
| 19:32:54 | dom96 | BitPuffin: seems better now. |
| 19:33:02 | BitPuffin | dom96: cool |
| 19:33:21 | dom96 | BitPuffin: Why are your line numbers the other way around lol |
| 19:33:33 | Araq | filwit: btw should we rollback to the old vm? |
| 19:34:41 | dom96 | BitPuffin: argh, same problem again :( |
| 19:35:17 | dom96 | It's as if I am getting 1 frame per 20 seconds |
| 19:35:31 | * | DAddYE joined #nimrod |
| 19:36:18 | * | dom96 tries it on his iPad |
| 19:37:22 | BitPuffin | dom96: weird |
| 19:37:30 | dom96 | BitPuffin: I think you should try lowering the quality |
| 19:37:38 | BitPuffin | dom96: don't have any drops :s according to cocoasplit |
| 19:37:38 | BitPuffin | dom96: I have tried that once |
| 19:37:43 | BitPuffin | believe I still had the same prob |
| 19:37:44 | filwit | Araq: idk, I never looked at the old vm, hard to compare |
| 19:37:50 | BitPuffin | or I'm not even sure if the problem is with me or not |
| 19:38:01 | dom96 | BitPuffin: well it's unwatchable for me :( |
| 19:38:08 | filwit | Araq: i would rather focus on going forward with one system that makes the most sense on paper |
| 19:38:31 | filwit | Araq: if you think the new VM design is better, let's just fix the bugs in it |
| 19:38:46 | BitPuffin | dom96: hrm :/ |
| 19:39:05 | dom96 | and there is no way for me to lower the quality |
| 19:39:07 | Araq | filwit: but it is not better :-/ |
| 19:39:22 | filwit | Araq: what is different about it? |
| 19:40:08 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 19:40:14 | dom96 | BitPuffin: Like when you're transitioning I get a single frame sometimes between the transition, and then it updates after 5 seconds |
| 19:40:30 | Araq | it's faster by a factor 20 but it's harder to maintain and introduces new bugs, filwit |
| 19:40:44 | Araq | and the bugs it fixes could also be easily fixed in the old vm |
| 19:41:19 | BitPuffin | dom96: could be a bug when switching desktop I guess |
| 19:41:25 | BitPuffin | but other than that it should be fine? |
| 19:41:39 | dom96 | BitPuffin: but it's not just during that. |
| 19:41:52 | BitPuffin | dom96: what do you mean with transitioning then? |
| 19:41:52 | Mat3 | Araq: What optimizations have you done in the new VM ? |
| 19:41:54 | filwit | Araq: everything seems pretty straight forward with this design as far as I can tell. It maps the Runtime AST pretty well. Speed sounds nice. The only thing I'm not fully understanding is how 'TDest' variables are being used. I though they would be stack indices, but it doesn't look like it. |
| 19:41:55 | dom96 | and see the value under 'pending out' |
| 19:42:12 | dom96 | BitPuffin: I'm just giving an example of where I am sure that it freezes. |
| 19:42:40 | BitPuffin | dom96: hmm |
| 19:42:47 | BitPuffin | well I'll try lowering the quality then |
| 19:43:11 | dom96 | ok |
| 19:43:16 | Araq | Mat3: no optimizations, just a 3 operand bytecode format |
| 19:43:33 | Araq | filwit: they are stack indices |
| 19:43:40 | EXetoC | 1080p is good enough. lower it to that |
| 19:43:48 | filwit | Araq: I'm not completely apposed to reverting back if there is just too much to handle, though I would prefer some more time to tinker with the new one. If it really does get 20x speed improvement, that's a nice thing. |
| 19:43:53 | BitPuffin | dom96: what about now |
| 19:44:09 | BitPuffin | dom96: is the text readable now? |
| 19:44:12 | Araq | filwit: ok then |
| 19:44:24 | filwit | Araq: that's what I thought originally, but why do they go into negative all the time? header stuff? |
| 19:44:27 | EXetoC | or maybe you don't even have 2160p/4320p yet. if so, get with the times |
| 19:44:46 | Araq | filwit: -1 means 'unused' that's all |
| 19:45:08 | filwit | ahh.. that, okay |
| 19:45:32 | dom96 | BitPuffin: No :\ |
| 19:45:37 | BitPuffin | dom96: hrm :'/ |
| 19:45:46 | BitPuffin | dom96: shitty wifi xD |
| 19:45:49 | filwit | marking as unused is how you free up stack memory? |
| 19:46:08 | Araq | no |
| 19:46:19 | dom96 | BitPuffin: I can see "Pending Out" accumulating. I'm guessing you don't want that to happen. |
| 19:46:36 | * | [1]Endy joined #nimrod |
| 19:46:49 | BitPuffin | dom96: Yeah I believe it's fine if it doesn't go too high |
| 19:46:54 | filwit | Araq: i'm trying to understand why you said adding to a Node was returning nil and causing the if-statement to become nil |
| 19:46:55 | BitPuffin | which it kind of was when I had higher quality |
| 19:47:58 | dom96 | BitPuffin: Perhaps you should just record the video and upload it to youtube later? |
| 19:48:02 | Araq | filwit: the codegen translates x = y + z differently from x+y |
| 19:48:12 | BitPuffin | dom96: nah |
| 19:48:18 | BitPuffin | dom96: I have to try one day with ethernet |
| 19:48:25 | dom96 | BitPuffin: ok |
| 19:48:25 | Araq | x+y means an unkown destination, so it allocates a temporary to store the result in |
| 19:48:30 | BitPuffin | dom96: could just be that the upload is not as good as in the old house |
| 19:48:39 | BitPuffin | where I had 10mb up |
| 19:48:44 | Araq | but for x = y + z we know the target slot |
| 19:48:52 | Mat3 | Araq: I guess your implemented ISA is a canonical RISC one (like the Lua VM) |
| 19:48:53 | Araq | and so no temporary is necessary |
| 19:48:58 | dom96 | BitPuffin: damn, that's pretty good. |
| 19:49:14 | BitPuffin | dom96: here it is like |
| 19:49:16 | BitPuffin | 1 perhaps |
| 19:49:19 | BitPuffin | dom96: wanna play dota? |
| 19:49:19 | Araq | Mat3: indeed, I copied Lua's design |
| 19:49:31 | BitPuffin | dom96: :P |
| 19:49:37 | dom96 | BitPuffin: nah |
| 19:49:42 | Araq | the 3 operand code that's produced is impressively efficient |
| 19:49:45 | BitPuffin | dom96: noob |
| 19:49:51 | Araq | oh I lied, Mat3 |
| 19:49:51 | dom96 | I'm waiting for Araq to fix a bug for me. |
| 19:50:05 | Araq | I perform basic jump optimizations |
| 19:50:07 | BitPuffin | dom96: perfect, one game then |
| 19:50:17 | filwit | Araq: i noticed the regs[ra/rb/rc] used everywhere |
| 19:50:32 | * | micklat quit (Remote host closed the connection) |
| 19:50:32 | dom96 | BitPuffin: I'd rather play HearthStone :P |
| 19:50:43 | BitPuffin | dom96: no! |
| 19:51:04 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 19:52:35 | filwit | Araq: thanks for the explanation, that helps a bit, though i'm still not seeing how the 'dest' var at vmgen:genIf:305 is incorrect (above 0) due to this. |
| 19:52:42 | * | BitPuffin joined #nimrod |
| 19:53:02 | BitPuffin | dom96: you and your FartStone |
| 19:53:14 | filwit | Araq: i have a couple more things to try |
| 19:55:41 | dom96 | BitPuffin: ooh, also. New Top Gear. |
| 19:57:22 | BitPuffin | dom96: noob |
| 20:05:55 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 20:22:54 | * | XAMPP joined #nimrod |
| 20:31:14 | * | carum joined #nimrod |
| 20:33:31 | * | [1]Endy joined #nimrod |
| 20:36:18 | * | carum quit (Remote host closed the connection) |
| 20:36:24 | * | DAddYE joined #nimrod |
| 20:40:59 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 20:48:08 | NimBot | Araq/Nimrod devel 14f4a23 Dominik Picheta [+2 ±0 -0]: Epoll wrapper + selectors module. |
| 20:48:08 | NimBot | Araq/Nimrod devel 38fb681 Dominik Picheta [+0 ±2 -0]: Epoll now works. |
| 20:48:08 | NimBot | Araq/Nimrod devel dc99441 Dominik Picheta [+540 ±233 -539]: Merge branch 'devel' into newasync |
| 20:48:08 | NimBot | Araq/Nimrod devel 0715001 Dominik Picheta [+3 ±1 -0]: Added new sockets modules: asyncio2, net, and sockets2. |
| 20:48:08 | NimBot | 3 more commits. |
| 20:48:27 | Araq | uh oh ... |
| 20:48:57 | Araq | damn, I merged newasync into devel ... |
| 20:49:01 | Araq | dom96: is that a problem? |
| 20:49:18 | dom96 | ... |
| 20:49:35 | Araq | stupid "git diff" didn't tell me! |
| 20:49:53 | dom96 | Be careful. |
| 20:50:03 | dom96 | You're lucky though because it shouldn't be a problem. |
| 20:50:28 | dom96 | As the other modules are still there. |
| 20:50:48 | Araq | ok good |
| 20:51:06 | Araq | I'll leave them in then |
| 20:58:04 | * | dmac joined #nimrod |
| 20:59:20 | * | aftersha_ joined #nimrod |
| 21:04:03 | * | ddl_smurf joined #nimrod |
| 21:04:05 | * | [1]Endy quit (Ping timeout: 248 seconds) |
| 21:15:56 | * | micklat joined #nimrod |
| 21:18:45 | micklat | Araq: yay your snake method works! |
| 21:24:22 | Mat3 | ciao |
| 21:26:46 | Araq | lol of course it does |
| 21:27:16 | * | Mat3 quit (Quit: Verlassend) |
| 21:28:45 | reactormonk | Araq, GSoC? |
| 21:30:33 | Araq | reactormonk: what do I need to do for that? |
| 21:32:42 | reactormonk | Araq, http://www.google-melange.com/gsoc/homepage/google/gsoc2014 and organize http://pastebin.com/0ZMtJFdB |
| 21:33:00 | reactormonk | I think dom96 is interested in helping |
| 21:33:10 | micklat | I still can't build python lists, though, I keep running into https://github.com/Araq/Nimrod/issues/888 |
| 21:33:18 | micklat | well, enough for one day I guess |
| 21:34:25 | reactormonk | micklat, could you reduce the problem? |
| 21:34:40 | micklat | I can try, sure |
| 21:35:16 | reactormonk | micklat, py2.nim(16, 7) Error: cannot open 'python' |
| 21:35:33 | micklat | you need to babel install python first |
| 21:36:03 | EXetoC | Araq: were the changes staged? if so, then you need to specify --cached |
| 21:36:53 | dom96 | Once you do 'git merge', git diff won't help you. |
| 21:37:09 | * | DAddYE joined #nimrod |
| 21:37:15 | Araq | bbl |
| 21:37:47 | EXetoC | that was the problem? |
| 21:39:44 | reactormonk | micklat, you are aware that converters are auto-applied? |
| 21:39:54 | reactormonk | so the compiler won't know if you want converter to_list*(vals: openarray[PPyRef]): PPyRef = |
| 21:39:56 | micklat | yes, |
| 21:39:56 | reactormonk | or |
| 21:40:01 | reactormonk | converter to_tuple*(vals: openarray[PPyRef]): PPyRef = |
| 21:40:25 | micklat | didn't see that |
| 21:40:31 | micklat | thanks |
| 21:40:49 | reactormonk | and there will be conflicts between openarray and converters |
| 21:41:14 | reactormonk | to_py converters are fine, but please make everything else not a converter. |
| 21:41:26 | * | DAddYE quit (Ping timeout: 245 seconds) |
| 21:42:25 | micklat | what's wrong with to_PPyRef? |
| 21:42:45 | micklat | it's really handy |
| 21:42:57 | reactormonk | that's good. |
| 21:43:18 | reactormonk | otherwise, keep it to to_py and from_py and don't use openarrays in converters... that will confuse the compiler. |
| 21:44:34 | micklat | ok, I've made to_tuple and to_list non-converters |
| 21:44:38 | micklat | doesn't fix the problem though |
| 21:45:21 | reactormonk | hm. |
| 21:45:39 | reactormonk | did you make anything that uses openarrays procs? |
| 21:47:32 | micklat | there's still one to_py converter: converter to_py*[T](vals: openarray[T]): PPyRef = |
| 21:47:40 | reactormonk | huh |
| 21:47:45 | micklat | so I'll try that |
| 21:47:58 | reactormonk | delete it |
| 21:49:03 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 21:49:38 | micklat | still the same problem |
| 21:50:08 | reactormonk | hmmm |
| 21:50:33 | micklat | I'll try to isolate it now |
| 22:04:21 | micklat | reactormonk: I'm mostly through. Notice the last 3 lines here: https://gist.github.com/micklat/8906673 |
| 22:05:08 | micklat | the problem occurs when the converter is supposed to kick into action |
| 22:06:31 | reactormonk | micklat, huh. Bug Araq. |
| 22:06:49 | micklat | thanks though |
| 22:08:41 | reactormonk | micklat, I think the convention is `initList` |
| 22:08:56 | micklat | instead of what? |
| 22:09:00 | micklat | new_list? |
| 22:09:18 | reactormonk | yup |
| 22:09:22 | reactormonk | just make it init_list |
| 22:09:47 | micklat | ok |
| 22:11:57 | micklat | well, thanks for all the help |
| 22:12:06 | micklat | my wife really wants me to go to bed now |
| 22:12:11 | micklat | night |
| 22:12:11 | reactormonk | micklat, np, check by again. And add your debugging to the issue |
| 22:12:25 | micklat | sure |
| 22:12:30 | * | micklat quit (Remote host closed the connection) |
| 22:26:44 | * | DAddYE joined #nimrod |
| 22:33:11 | * | zahary quit (Ping timeout: 272 seconds) |
| 22:35:49 | reactormonk | how can I tell the compiler to spew out the command it uses for gcc? |
| 22:38:49 | reactormonk | somehow --listCmd doesn't do it |
| 22:38:57 | filwit | --paralleBuild:true or something like that |
| 22:39:14 | filwit | --parallelBuild:on maybe? |
| 22:39:27 | dom96 | it should do that by default. |
| 22:39:30 | reactormonk | --parallelBuild:1 for error messages |
| 22:39:40 | dom96 | remove your nimcache and bin |
| 22:39:40 | filwit | ^ that's it |
| 22:39:50 | reactormonk | http://pastebin.com/ms0suhe2 |
| 22:40:15 | reactormonk | nope, doesn't help |
| 22:43:36 | dom96 | whoa what |
| 22:43:37 | dom96 | await.nim(88, 15) Error: ambiguous call; both sockets2.$(p: TPort): string and macros.$(s: PNimrodSymbol): string match for: (Error Type) |
| 22:48:20 | dom96 | Araq: hrm, the compiler doesn't like when I try capturing a 'Sym'. |
| 22:58:31 | Araq | dom96: what do you mean? |
| 22:59:22 | dom96 | Araq: Whenever I use a macro to generate variable assignments using genSym and then I generate code which also captures those symbols in a closure the compiler complains |
| 22:59:34 | dom96 | If I change the genSym usage to newNimIdent it works again |
| 22:59:44 | dom96 | *newIdentNode |
| 23:02:41 | Araq | are you sure it's the capturing? and not some other bug so that the sym doesn't get a proper type assigned? |
| 23:03:06 | dom96 | Dunno. |
| 23:03:29 | dom96 | I'm fairly sure my code generation is correct since it works with idents. |
| 23:03:42 | dom96 | if that's what you're asking |
| 23:04:01 | dom96 | I get an illegal capture error if that helps. |
| 23:04:40 | filwit | recently discovered debug() is really useful to dumping to temp files and inspecting/comparing the node tree inside vmgen |
| 23:05:02 | filwit | from* inside vmgen |
| 23:06:26 | dom96 | Araq: Is there a way to get rid of the implicit result var? |
| 23:06:29 | * | Demos joined #nimrod |
| 23:07:08 | Araq | dom96: no. why? |
| 23:07:34 | dom96 | Araq: Because the user's proc body will be wrapped in an iterator who's return type will be different. |
| 23:07:51 | dom96 | I guess I can just redefine result to whatever I wish? |
| 23:08:14 | Araq | the macro should check 'result' is not used, I guess |
| 23:08:32 | Araq | but please |
| 23:08:46 | Araq | make 'await' work and focus on the other missing parts |
| 23:08:58 | Araq | the 'async' pragma is only a syntax game |
| 23:09:11 | Araq | and I'm not sure nim's macros are up for that |
| 23:09:29 | dom96 | The async pragma is the most important |
| 23:09:37 | Araq | why? |
| 23:10:00 | dom96 | because it takes care of a lot more boilerplate than await |
| 23:10:27 | Araq | ok ... |
| 23:11:17 | dom96 | well hrm |
| 23:11:38 | dom96 | I guess that's not quite true |
| 23:11:44 | dom96 | But in any case, I've already started it |
| 23:11:46 | dom96 | and it's almost finished |
| 23:11:50 | dom96 | I may as well get it done |
| 23:12:02 | Araq | ok but I won't fix any bugs |
| 23:12:12 | Araq | today |
| 23:12:18 | dom96 | lol |
| 23:12:20 | reactormonk | dom96, do you want to pull this GSoC off? I can help, but I'm not sure I can go full on it, because I need to finish my masters thesis this summer. |
| 23:12:35 | dom96 | Araq: In my timezone or yours? :P |
| 23:12:44 | reactormonk | Araq, btw: https://github.com/Araq/Nimrod/pull/896 |
| 23:12:47 | Araq | mine :P |
| 23:12:59 | dom96 | reactormonk: There is far too much work associated with getting it done I think. |
| 23:13:26 | reactormonk | dom96, I assume it's about as much work as coding it yourself |
| 23:13:39 | dom96 | We need all sorts of tax forms, ideas, mentors, plans for what happens when mentors are unavailable and blah blah |
| 23:13:43 | Araq | reactormonk: kudos |
| 23:13:43 | reactormonk | dom96, except you get a reduction on the bus-problem and some publicity |
| 23:13:57 | reactormonk | Araq, does the fix hold? |
| 23:14:07 | Araq | dunno lol |
| 23:14:21 | reactormonk | what does d.k == locNone check for? |
| 23:14:22 | dom96 | Next summer I will force Araq to do it. Since I will be at uni then :P |
| 23:15:11 | reactormonk | Araq, if that frees you up some time for the GSoC, I can come back with my half bitcoin. |
| 23:15:26 | Araq | wow |
| 23:15:35 | Araq | how much is that in euro now? |
| 23:15:38 | * | musicalchair quit (Ping timeout: 265 seconds) |
| 23:16:01 | reactormonk | it's about again as much as you get for the GSoC |
| 23:16:12 | EXetoC | dom96: surely you'll be writing Nimrod code for monies by then. have some faith |
| 23:16:24 | reactormonk | hmm, it kinda dropped to 660 per BTC :-/ |
| 23:16:28 | reactormonk | so not as much. |
| 23:16:31 | reactormonk | 660$. |
| 23:16:38 | dom96 | EXetoC: Perhaps. |
| 23:16:44 | EXetoC | reactormonk: can I have one of those |
| 23:16:57 | NimBot | Araq/Nimrod devel 829a76d Araq [+0 ±1 -0]: nofoward doesn't exist yet; fixes #890 |
| 23:17:03 | dom96 | reactormonk: Weren't you going to give Araq 1BTC at one point? |
| 23:17:09 | dom96 | What was that for again? |
| 23:17:55 | reactormonk | no idea |
| 23:18:49 | * | Discoloda quit (Ping timeout: 245 seconds) |
| 23:19:09 | Araq | gah ... must stop fixing bugs ... |
| 23:19:15 | * | Araq is a machine |
| 23:19:18 | reactormonk | Araq, if you think the PR holds, pull it. |
| 23:21:47 | NimBot | Araq/Nimrod devel 17ea0d1 Simon Hafner [+1 ±0 -1]: moved the tests for TSet to the correct place |
| 23:21:47 | NimBot | Araq/Nimrod devel fe21f02 Simon Hafner [+0 ±1 -0]: fixes #887 |
| 23:21:47 | NimBot | Araq/Nimrod devel e6cdccc Andreas Rumpf [+1 ±1 -1]: Merge pull request #896 from reactormonk/set_fix... 2 more lines |
| 23:22:50 | NimBot | Araq/Nimrod devel a9d3551 Simon Hafner [+0 ±2 -0]: removed explicit return in the documentation |
| 23:22:50 | NimBot | Araq/Nimrod devel 21b0eba Simon Hafner [+0 ±3 -0]: tracked down a few more returns |
| 23:22:50 | NimBot | Araq/Nimrod devel a5d8714 Andreas Rumpf [+0 ±3 -0]: Merge pull request #867 from reactormonk/no_explicit_return... 2 more lines |
| 23:23:15 | Araq | reactormonk: kudos |
| 23:26:41 | * | Discoloda joined #nimrod |
| 23:28:06 | reactormonk | Araq, that one was easier |
| 23:28:56 | * | brson joined #nimrod |
| 23:28:57 | * | musicalchair joined #nimrod |
| 23:33:22 | reactormonk | Araq, gotta say an occasional echo statement makes debugging easier ;-) |
| 23:33:46 | * | DAddYE quit (Remote host closed the connection) |
| 23:34:01 | Araq | reactormonk: we also have 'debug' in the compiler |
| 23:34:12 | reactormonk | Araq, which does what? |
| 23:34:35 | Araq | can print a PSym, PNode or PType |
| 23:36:17 | reactormonk | why not define $ for those? |
| 23:37:50 | Araq | predates $ |
| 23:38:05 | Demos | where is the code/how does it print PNodes? |
| 23:38:13 | Demos | (does it print the whole tree) |
| 23:38:21 | Araq | (yes) |
| 23:38:36 | Araq | Demos: echo renderTree(n) is often more useful though |
| 23:38:54 | Araq | as that doesn't overwhelm you with irrelevant details |
| 23:39:26 | Demos | presumably putting this in a when not defined(booting) block is a good idea |
| 23:40:24 | Araq | why? |
| 23:41:17 | Demos | well if I am debugging something in the compiler I would not want the compiler to output a metric shitton of stuff while compileing itself |
| 23:41:58 | Araq | bah, just use 'koch temp c mybug.nim' to debug the compiler |
| 23:42:16 | Araq | bootstrap when the bug is fixed later |
| 23:42:17 | reactormonk | Araq, koch temp? never heard of. |
| 23:42:26 | reactormonk | I just booted the compiler ^^ |
| 23:42:29 | Demos | ah, yeah. that command is not documented |
| 23:42:38 | Araq | well it is new |
| 23:42:58 | Araq | zahary had a script for it like forever |
| 23:43:17 | Araq | and I was doing the slow route too until I switched back to win |
| 23:43:33 | Araq | here the linking times are killing me, so I needed something faster |
| 23:51:16 | Araq | note to myself: aks zahary what the fuck the semantics of typedesc and typedesc[T] really are ... |
| 23:52:28 | NimBot | Araq/Nimrod devel c4091e9 Araq [+0 ±1 -0]: fixes #889 |
| 23:52:28 | NimBot | Araq/Nimrod devel bb74d6a Araq [+1 ±4 -1]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 23:52:42 | Araq | filwit: I hope I fixed the 'unused' bug for good |
| 23:53:00 | filwit | i'll pull the changes and test |
| 23:56:20 | Demos | OK temp is supah nice |
| 23:56:28 | reactormonk | Demos, can you document it? |
| 23:56:58 | Demos | I was just doing that and I saw the documentation, it is the last line in koch's help output and there are no []s around options |
| 23:57:16 | reactormonk | ah cool |
| 23:57:18 | reactormonk | didn't see that |
| 23:57:31 | Demos | heh same |
| 23:58:16 | filwit | Araq: okay, what you did with clearDest() is along the same lines as what I was thinking, though I didn't know about freeTemp() |
| 23:58:57 | filwit | Araq: it doesn't work though.. now it simply runs into the vm:425 runtime assert at deref |
| 23:59:15 | Araq | filwit: that is some other bug though |
| 23:59:19 | filwit | Araq: though I fixed this before, i was thinking it had something to do with the code-gen |
| 23:59:43 | Araq | no this is an unrelated bug which I might fix tomorrow |
| 23:59:56 | Araq | I know how to fix it :P |
