| 00:06:42 | * | Clinteger\c quit (Ping timeout: 276 seconds) |
| 00:10:56 | * | Clinteger\c joined #nimrod |
| 00:10:56 | * | Clinteger\c quit (Changing host) |
| 00:10:56 | * | Clinteger\c joined #nimrod |
| 00:12:09 | * | darkf joined #nimrod |
| 00:37:54 | Araq | good night |
| 00:48:25 | * | icebattle quit (Quit: leaving) |
| 01:10:39 | * | carum quit (Remote host closed the connection) |
| 01:26:53 | * | DAddYE_ quit (Remote host closed the connection) |
| 01:27:39 | * | DAddYE joined #nimrod |
| 01:32:03 | * | DAddYE quit (Remote host closed the connection) |
| 01:32:35 | * | DAddYE joined #nimrod |
| 01:37:43 | * | DAddYE quit (Ping timeout: 272 seconds) |
| 02:21:51 | * | askatasuna joined #nimrod |
| 02:25:49 | * | brson quit (Quit: leaving) |
| 02:39:00 | * | dmac joined #nimrod |
| 03:03:05 | EXetoC | so `==`(string, cstring) results in a pointer comparison? it seems kind of useless then |
| 03:11:32 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 03:40:35 | Demos | well sometimes "did this cstring come from this string?" is useful. `==` is probably not a good operator for it though |
| 04:00:28 | * | ics joined #nimrod |
| 04:59:35 | * | DAddYE joined #nimrod |
| 05:44:37 | filwit | trying to update babel, but says: Unsatisfied dependency: nimrod (>= 0.9.3) |
| 05:46:12 | filwit | i have my compilers setup just fine, anyway i can just bypass that check? |
| 06:10:21 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 06:30:29 | * | xtagon quit (Ping timeout: 248 seconds) |
| 06:36:36 | * | foodoo joined #nimrod |
| 06:52:51 | * | micklat joined #nimrod |
| 07:07:53 | foodoo | I really like the quotes that are all over Nimrod's webpage+documentation |
| 07:10:28 | Araq | hi foodoo, welcome |
| 07:12:04 | foodoo | Ah, the creator! |
| 07:12:50 | foodoo | I really like the design choices that you have made with Nimrod |
| 07:13:18 | Araq | thank you :-) |
| 07:13:30 | foodoo | Especially some stuff that I miss in Python like declaration of a new variable |
| 07:14:00 | foodoo | And also the "magic" result variable. I call my return value result most of the time anyway so that was a real wow-moment when I read about it |
| 07:14:34 | Araq | ha, many dislike it |
| 07:14:52 | Araq | can't be good, only delphi and eiffel use it ... ;-) |
| 07:15:02 | foodoo | I think it's a nice convention. You immediately know that this is going to be the value that will be returned |
| 07:15:25 | Araq | yeah plus 'return' conflates 'result' with control flow |
| 07:15:46 | Araq | so it's not like the traditional way is cleaner |
| 07:16:18 | foodoo | I don't quite understand |
| 07:16:31 | foodoo | what do you mean by cleaner? |
| 07:17:36 | foodoo | (I never programmed in Delphi or Eiffel) |
| 07:20:08 | Araq | IMO 'result' is cleaner than 'return' because 'return' also affects control flow |
| 07:20:17 | foodoo | ah, I see |
| 07:26:15 | * | ics joined #nimrod |
| 07:42:11 | Araq | bbl |
| 07:42:15 | micklat | Kudos to the creator! Total newb here. Compiling Aporia fails with "analysis not implemented for: nkFinally". Any suggestions? |
| 07:42:38 | foodoo | I just played around with c2nim. I tried it with several header files (ncurses.h, stdio.h, signal.h) and it couldn't parse these files. I know this is a hard problem and you might be interested in a solution that the Terra programming language (terralang.org) uses: They simply use Clang/LLVM as a library to do the parsing so that they actually have a real compiler that does the heavy lifting. |
| 07:45:35 | foodoo | micklat: Let me see if I can reproduce the problem. But I'm also new to the language. Which operating system are you on? |
| 07:46:05 | foodoo | Okay, the latest git snapshot compiles flawlessly on my system (ArchLinux 64bit) |
| 07:46:20 | micklat | Thanks foodoo. I use linux and the git head of nimrod. |
| 07:47:16 | foodoo | Which distribution? |
| 07:48:21 | foodoo | Araq: Wow, interfaces to Lua and Python in the standard library. That's cool :) |
| 07:48:44 | micklat | ubuntu 12.04 |
| 07:50:51 | micklat | The full error is: lib/pure/osproc.nim(620, 4) Error: internal error: analysis not implemented for: nkFinally |
| 07:50:59 | foodoo | ah, thanks |
| 07:54:41 | foodoo | quit("execve call failed: " & $strerror(errno)) |
| 07:54:52 | foodoo | is that also your line 620? |
| 07:54:54 | micklat | I tried uncommenting "threadAnalysis:off" in aporia.nimrod.cfg, following https://github.com/nimrod-code/Aporia/issues/49, now the error is further down the line |
| 07:56:05 | micklat | yes, that's my 620 |
| 07:56:25 | micklat | anyway, it seems like the nimrod compiler is missing some case |
| 07:56:41 | micklat | I guess I'll file a bug report |
| 07:57:25 | foodoo | But it's still strange that I don't have the same error |
| 07:58:37 | micklat | yes, I suppose. |
| 07:59:13 | micklat | Are you using the head of both nimrod and Aporia? What's your compilation command? I use "babel build" |
| 07:59:50 | foodoo | I use nimrod 0.9.2 from the ArchLinux repository (precompiled by someone else) |
| 08:00:39 | foodoo | ArchLinux has something like build-scripts for packages. There's a commuinty build script for Aporia and it works fine (It doesn't use babel) |
| 08:03:22 | * | Demos quit (Read error: Connection reset by peer) |
| 08:04:45 | micklat | Yes, the problem does not seem to occur with nimrod 0.9.2 |
| 08:08:47 | foodoo | proc bye() = |
| 08:08:50 | foodoo | echo "bye" |
| 08:09:29 | foodoo | This function doesn't have a return value. But I still have to discard the return value when I call it. Is that correct? (At least the compiler says so) |
| 08:15:42 | micklat | foodoo: I tried your test and don't get a message about discard. I tried both 0.9.2 and head. |
| 08:16:17 | micklat | How do you call it? I just write bye() on its own line and it works |
| 08:17:17 | foodoo | funny. Now it works |
| 08:28:09 | * | foodoo quit (Quit: so long and thanks for the fishing rod) |
| 08:28:14 | * | noam quit (Read error: Connection reset by peer) |
| 08:28:38 | * | noam joined #nimrod |
| 08:33:48 | * | [1]Endy joined #nimrod |
| 09:04:31 | * | filwit quit (Ping timeout: 260 seconds) |
| 09:14:21 | * | psquid quit (Ping timeout: 245 seconds) |
| 09:20:51 | * | askatasuna quit (Ping timeout: 260 seconds) |
| 09:28:18 | * | DAddYE quit (Remote host closed the connection) |
| 09:39:18 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:46:37 | Araq | hi micklat welcome |
| 09:46:54 | micklat | Hi. |
| 09:47:06 | Araq | I suspect there is a corruption in the compiler itself that causes it to misbehave on macosx |
| 09:47:44 | micklat | Are you referring to the internal error I reported earlier (https://github.com/Araq/Nimrod/issues/882) ? |
| 09:47:45 | Araq | this bug has been there for a long time, I run a hard stress test on the compiler/GC combination but that didn't find anything |
| 09:47:58 | Araq | yes |
| 09:48:05 | micklat | I'm not using max OS |
| 09:48:14 | Araq | oh |
| 09:48:19 | Araq | that's new :-) |
| 09:49:02 | micklat | It's ubuntu, 12.04 |
| 09:49:18 | Araq | maybe it's the same issue though |
| 09:49:34 | micklat | anything you'd like me to try? |
| 09:49:41 | Araq | please bootstrap with --gc:markAndSweep |
| 09:49:49 | Araq | with or without -d:release |
| 09:49:58 | Araq | and see if the compiler then eats aporia |
| 09:50:06 | micklat | pass that to Koch right? |
| 09:50:30 | Araq | right |
| 10:00:05 | micklat | same error |
| 10:00:28 | micklat | which is kinda expected, isn't it? the error doesn't seem to be GC-related |
| 10:00:45 | Araq | good |
| 10:01:02 | Araq | what's the error message again? |
| 10:01:12 | Araq | (not the nkFinally stuff please) |
| 10:01:40 | micklat | the nkFinally stuff is the error message |
| 10:01:50 | micklat | you mean the error I get if I disable thread analysis? |
| 10:01:53 | Araq | yes |
| 10:05:23 | micklat | http://pastebin.com/ExFj2YBh |
| 10:06:22 | micklat | gcc version 4.6.3 |
| 10:11:58 | Araq | ok thanks |
| 10:13:37 | Araq | looks like yet another lovely regression |
| 10:17:46 | Araq | micklat: can you please try the 'master' branch? |
| 10:18:21 | micklat | sure. |
| 10:34:47 | * | [2]Endy joined #nimrod |
| 10:36:47 | micklat | with master, M&S, and threadAnalysis:off, I get "SIGSEGV: Illegal storage access. (Attempt to read from nil?)" |
| 10:37:59 | * | [1]Endy quit (Ping timeout: 245 seconds) |
| 10:38:15 | micklat | I get the same error with threadAnalysis:off commented out. |
| 10:38:29 | Araq | well that leads to the question: what compiler does dom96 use to test aporia? |
| 10:39:39 | micklat | would you like me to file another bug report? |
| 10:43:01 | Araq | sure why not |
| 10:43:14 | Araq | however git bisect would be most useful to see where the regression comes from |
| 10:44:07 | micklat | how do I do that? |
| 10:44:47 | micklat | ok, I'm checking the git manual |
| 10:50:44 | Araq | it looks like my changes to the lambda lifting algorithm broke it |
| 10:57:25 | micklat | do you still want that bisect? |
| 10:57:57 | Araq | yes please |
| 10:58:30 | Araq | brb |
| 11:03:07 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 11:11:58 | * | psquid joined #nimrod |
| 11:16:50 | * | aftersha_ joined #nimrod |
| 11:23:00 | dom96 | Araq: hah, so my hunch was right. |
| 11:23:10 | dom96 | Araq: I don't recompile Aporia often. |
| 11:28:55 | * | io2 joined #nimrod |
| 11:35:00 | * | BillPhilson joined #nimrod |
| 11:35:04 | * | BillPhilson left #nimrod (#nimrod) |
| 12:12:54 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 12:30:21 | micklat | Araq: I'm having a bit of a problem with the bisection. With revisions before 2b4173, the compiler fails to build itself, with: "gc_ms.nim(62, 2) Error: undeclared identifier: 'InstantiateForRegion'" |
| 12:30:42 | micklat | could it be that the c sources I used are incompatible with these older versions? |
| 12:31:01 | Araq | micklat: no, it's because things change to quickly |
| 12:37:19 | Araq | micklat: edit compiler/nimrod.nimrod.cfg and remove the --cs:partial switch and it should work |
| 12:37:44 | Araq | but you really don't have to use --gc:markAndSweep and then it should work too |
| 12:45:02 | micklat | doesn't seem to work. I'll try again with a clean clone |
| 12:56:56 | micklat | No, that didn't fix it |
| 12:57:09 | Araq | micklat: ok, don't worry |
| 12:57:21 | Araq | I will find and fix it later |
| 12:57:31 | Araq | I need to go now, bbl |
| 12:57:37 | micklat | cheers |
| 12:59:06 | * | dmac quit (Ping timeout: 252 seconds) |
| 13:05:43 | EXetoC | what does 'cres' (var cres: PState) in builder.nim stand for? |
| 13:10:19 | dom96 | closure result probably |
| 13:10:20 | dom96 | why? |
| 13:13:14 | EXetoC | I don't get it |
| 13:13:56 | dom96 | closures can't capture the implicit 'result' var |
| 13:15:58 | EXetoC | ok. it's just a little cryptic. haven't encountered that name before |
| 13:17:18 | EXetoC | I wanted to add support for packages, but I don't know if it's feasible without a babel API |
| 13:18:34 | dom96 | I think the tester should have an option to test all babel packages. |
| 13:19:34 | EXetoC | that should be done in an isolated VM then |
| 13:20:16 | dom96 | perhaps. |
| 13:21:40 | dom96 | You could just create a babeltest dir, clone all the babel packages there and run babel build. |
| 13:25:15 | * | aftersha_ joined #nimrod |
| 13:44:45 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 13:55:41 | * | psquid quit (Ping timeout: 245 seconds) |
| 13:56:07 | * | psquid joined #nimrod |
| 13:56:19 | * | foodoo joined #nimrod |
| 14:00:57 | * | epsylon` is now known as epsylon |
| 14:09:04 | * | darkf quit (Quit: Leaving) |
| 14:17:14 | * | aftersha_ joined #nimrod |
| 14:21:10 | * | zahary joined #nimrod |
| 14:21:26 | * | oxful joined #nimrod |
| 14:22:33 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 14:25:11 | * | noam quit (Ping timeout: 265 seconds) |
| 14:26:57 | * | noam joined #nimrod |
| 14:30:01 | renesac | I'm still failing on how to make templates with optional arguments AND be able to use the do notation: |
| 14:30:01 | renesac | https://gist.github.com/ReneSac/715730359e06c472f683 |
| 14:30:17 | renesac | Error: expression 'swtest()' has no type (or is ambiguous) |
| 14:31:16 | renesac | probably falls within the "slightly wrong" thing Araq said about my understanding of templates return values |
| 14:32:34 | dom96 | I don't think the 'do' is needed. |
| 14:34:52 | renesac | it is |
| 14:35:02 | renesac | was my first error trying to make this template work |
| 14:35:10 | renesac | it isn't documented (yet) |
| 14:36:25 | dom96 | That's weird. |
| 14:36:25 | * | PortableEXetoC joined #nimrod |
| 14:36:46 | renesac | Araq said something about it being needed to avoid ambiguities |
| 14:37:06 | dom96 | I see. |
| 14:37:21 | renesac | from what I observed, it is needed when the template is used as expression and not as a statment |
| 14:38:55 | renesac | well, I would like the "do" filling the last argument to the function, and let me not fill the optional arguments before it |
| 14:39:06 | renesac | I will make a feature request about it |
| 14:39:23 | dom96 | well I dunno. |
| 14:39:27 | renesac | but right now, I would like to understand why that won't work |
| 14:41:16 | * | truff__ quit (Quit: Connection closed for inactivity) |
| 14:42:43 | * | io2 quit () |
| 14:44:21 | * | foodoo quit (Ping timeout: 245 seconds) |
| 14:54:24 | PortableEXetoC | Test |
| 14:56:56 | renesac | tested |
| 14:58:24 | PortableEXetoC | No i was just testing my internets |
| 14:59:02 | renesac | right |
| 14:59:54 | * | aftersha_ joined #nimrod |
| 15:02:19 | PortableEXetoC | 50 ms ping out in the woods. Not bad |
| 15:08:56 | * | renesac is now known as renesac|away |
| 15:24:39 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 15:24:43 | * | foodoo joined #nimrod |
| 15:39:26 | foodoo | When I try the code on the frontpage of nimrod-lang.org I get the following error: |
| 15:39:29 | foodoo | stdin.nim(4, 23) Error: undeclared identifier: 'lines' |
| 15:39:40 | foodoo | Looks like stdin.lines is not defined. Do I need to import something? |
| 15:41:25 | OrionPK | that should work with just system |
| 15:41:54 | OrionPK | stdin is a TFile in the system module, and lines(TFile) is also in the system module |
| 15:42:22 | OrionPK | if your module is named stdin it might be confusing it |
| 15:42:59 | * | aftersha_ joined #nimrod |
| 15:44:08 | foodoo | that's it :D |
| 15:44:47 | OrionPK | cool |
| 15:45:37 | foodoo | poor Nimrod compiler was confused by badly chosen file name |
| 15:47:38 | foodoo | NimBot: type( "foo" ) |
| 15:48:26 | foodoo | NimBot: 1 + 1 |
| 15:48:45 | foodoo | NimBot: help |
| 15:48:57 | dom96 | NimBot doesn't do code eval |
| 15:49:49 | foodoo | What can it do then? |
| 15:50:17 | dom96 | It logs this channel, !seen, and commit announcements. |
| 15:53:01 | OrionPK | oh shit |
| 15:53:04 | OrionPK | this is exciting |
| 15:53:24 | reactormonk | Araq, GoSC? |
| 15:58:23 | foodoo | what is exciting? |
| 15:59:12 | OrionPK | Araq the leak.nim looks good w/ devel |
| 15:59:41 | NimBot | Araq/Nimrod newasync d4c53dc Araq [+0 ±5 -0]: 'bind' default for clean templates |
| 15:59:41 | NimBot | Araq/Nimrod newasync 5ef71bb Araq [+0 ±3 -0]: made some tests green |
| 15:59:41 | NimBot | Araq/Nimrod newasync 65d572a Araq [+0 ±1 -0]: fixed definition of culong on win64 |
| 15:59:41 | NimBot | Araq/Nimrod newasync 89f9b36 Araq [+0 ±1 -0]: attempt to improve line information for '!=' etc. templates |
| 15:59:41 | NimBot | 423 more commits. |
| 16:01:09 | OrionPK | Araq the leak one testing websockets still looks like it's leaking a bit |
| 16:02:03 | OrionPK | araq https://dl.dropboxusercontent.com/u/417554/leak.zip |
| 16:03:05 | OrionPK | it's stable in the console, but the usage in task manager is still going up |
| 16:04:50 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 16:07:00 | NimBot | Araq/Nimrod newasync 0715001 Dominik Picheta [+3 ±1 -0]: Added new sockets modules: asyncio2, net, and sockets2. |
| 16:09:28 | OrionPK | yay progress on async ;) |
| 16:09:46 | * | psquid quit (Ping timeout: 245 seconds) |
| 16:10:54 | dom96 | indeed. :) |
| 16:12:47 | OrionPK | im on hiatus til mid march probably |
| 16:13:07 | OrionPK | buying a house |
| 16:13:34 | * | ddl_smurf joined #nimrod |
| 16:15:04 | dom96 | oh, so you won't be around much? |
| 16:16:02 | OrionPK | correct |
| 16:16:44 | OrionPK | except weekend mornings and downtime at work :) |
| 16:30:16 | dom96 | hehe, good. |
| 16:55:21 | * | PortableEXetoC quit (Quit: cake) |
| 17:21:47 | dom96 | Araq: ping |
| 17:23:15 | * | Demos joined #nimrod |
| 17:39:30 | foodoo | http://pastebin.com/CCQx5tje Project Euler Problem #1 solved :) |
| 17:42:53 | Araq | dom96: pong |
| 17:43:14 | Araq | renesac|away: I think it's a bug |
| 17:43:31 | Araq | foodoo: thanks we know about LLVM :P |
| 17:44:44 | Araq | was more fun to write my own parser and it works really nicely when you use it the way it's meant to be used instead of throwing shit at it and wondering why it can't read your mind |
| 17:46:37 | foodoo | Well, was just a suggestion |
| 17:47:02 | foodoo | Didn't seem that obvious to me when I first learned about Terra |
| 17:47:05 | EXetoC | Araq: what do you mean? |
| 17:47:13 | EXetoC | either way, it does a pretty good job |
| 17:47:50 | foodoo | EXetoC: There is the programming language Terra (http://terralang.org) that uses LLVM to compile C headers to compatible Terra code |
| 17:49:17 | EXetoC | yeah I saw that |
| 17:50:31 | EXetoC | I guess you get a token stream or something |
| 17:51:28 | Araq | foodoo: I've looked into LLVM before starting c2nim |
| 17:51:58 | Araq | LLVM compiles slowly, and didn't provide #define in a way that is necessary for header translation |
| 17:52:03 | * | ics joined #nimrod |
| 17:52:07 | Araq | I suspect this changed by now |
| 17:52:50 | foodoo | could be. I'm not too familiar with LLVM |
| 17:59:42 | dom96 | Araq: Futures are in the branch. Now tell me how to get 'await'. |
| 18:00:02 | foodoo | Does Nimrod support multiple assignment? |
| 18:00:25 | Araq | 'await' is just sugar for 'yield', dom96 |
| 18:00:39 | dom96 | Yes. I know. |
| 18:01:03 | dom96 | That's my attempt: https://gist.github.com/dom96/11ba488a29b1fa2abe64 |
| 18:02:36 | Araq | foodoo: no, but 'swap' is builtin |
| 18:03:47 | foodoo | Araq: thanks. Although swap() won't work for fibbonacci numbers |
| 18:04:00 | dom96 | Araq: Unfortunately the generic cannot be instantiated |
| 18:04:23 | * | filwit joined #nimrod |
| 18:05:03 | Araq | dom96: how could it? |
| 18:05:43 | dom96 | Araq: I'm not saying it should be possible. But I'm not sure how else to do the await thing |
| 18:05:54 | dom96 | It's not just a simple case of aliasing 'await' to 'yield' |
| 18:07:20 | Araq | your test iterator yields what p.recv(sock, 10) yields |
| 18:07:39 | Araq | which is likely PFuture[string] so I don't see your problem |
| 18:09:24 | dom96 | come on |
| 18:09:34 | dom96 | there is another yield right above that |
| 18:09:51 | dom96 | and you should know that it's not always a string |
| 18:10:47 | Araq | oh sorry |
| 18:13:54 | * | micklat quit (Remote host closed the connection) |
| 18:14:42 | Araq | well I'm not sure, but have a look at my tasks example |
| 18:15:50 | Araq | each task has the return type 'void' |
| 18:16:46 | * | shodan45 sighs |
| 18:16:49 | * | filwit quit (Read error: No route to host) |
| 18:16:59 | shodan45 | I wish I had time to play with nimrod more :( |
| 18:17:16 | * | filwit joined #nimrod |
| 18:17:27 | Araq | shodan45: I wish I could fix bugs quicklier :-( |
| 18:17:32 | EXetoC | Araq: was anything not in tmongo.nim tested at some point? `[]` for example |
| 18:18:04 | EXetoC | just curious, because I'm trying to fix it among other things, and I don't know if you can use bson_find in that way |
| 18:18:36 | Araq | EXetoC: everything in tmongo.nim was tested at one point |
| 18:20:37 | EXetoC | that's the only way the modules were tested? ok |
| 18:21:08 | shodan45 | how's that nimrod VM thing going? |
| 18:21:40 | Araq | shodan45: slowly and painfully |
| 18:24:41 | Araq | dom96: I think PFuture[T] can't work for reasons like this |
| 18:25:46 | Araq | you yield what you want to wait on |
| 18:26:06 | dom96 | That is what I want to wait on :P |
| 18:26:15 | Araq | I know |
| 18:26:31 | Araq | hence all events you wait for need to have the same type |
| 18:26:46 | dom96 | I'm glad i'm trying this now instead of porting everything to it and then finding out that it may not work. |
| 18:28:59 | dom96 | The future has a callback that I can set. |
| 18:29:11 | dom96 | Could I perhaps set a closure which would wake up the iterator? |
| 18:29:27 | dom96 | and then just yield void? |
| 18:32:27 | dom96 | argh, I think that ends up with the same problem |
| 18:34:40 | * | askatasuna joined #nimrod |
| 18:35:04 | Araq | every event lib either uses a union or inheritance for a reason, dom96 |
| 18:35:08 | Araq | hi askatasuna welcome |
| 18:35:56 | Araq | you use 'yield' to return control flow to the dispatcher |
| 18:36:21 | Araq | you can either pass a context to the iterator and set in the context what you're waiting for |
| 18:36:42 | Araq | or you yield it instead |
| 18:36:55 | Araq | yielding it is much cleaner, I think |
| 18:37:41 | Araq | every iterator that you register for the dispatcher must have the same type |
| 18:38:37 | * | aftersha_ joined #nimrod |
| 18:45:37 | filwit | dom96: any way I can get babel to build with a user-defined version of nimrod? |
| 18:45:56 | dom96 | filwit: Change the .babel file |
| 18:46:46 | filwit | so removing the check will still work? |
| 18:46:55 | dom96 | yes |
| 18:47:05 | Araq | lol |
| 18:47:06 | dom96 | well. The checks are there for a reason. |
| 18:47:13 | filwit | okay, why is the check so high then? |
| 18:47:18 | Araq | exactly what I told you, dom96 :P |
| 18:47:20 | filwit | it's just not tested? |
| 18:47:30 | dom96 | Araq: shhhh |
| 18:47:35 | dom96 | Actually. |
| 18:47:37 | dom96 | It won't work. |
| 18:47:47 | dom96 | You need --noBabelPaths |
| 18:47:53 | dom96 | Which 0.9.2 does not have |
| 18:49:04 | filwit | damn, okay. Kinda liked my compiler setup (could test 0.9.2 without having to rebuild) but i'll just get rid of the Arch version and make my git/master the default |
| 18:49:34 | dom96 | You can just compile babel manually. |
| 18:49:51 | filwit | okay, i'll take that rout |
| 18:50:00 | dom96 | In fact, you have to do that anyway lol |
| 18:50:34 | filwit | BSD license :) |
| 18:51:49 | shodan45 | what microcontrollers have people used with nimrod? I think I saw AVR somewhere, any others? MSP430? |
| 18:52:00 | shodan45 | 8051? |
| 18:54:06 | dom96 | Araq: So the dispatcher should have a list of all the iterators and what they are waiting for? |
| 18:54:20 | Araq | dom96: I think so |
| 18:54:23 | dom96 | hrm |
| 18:55:13 | filwit | shodan45, I've never personally tried to program a microcontroller or heard of any Nimrod projects with them. Guys? |
| 18:55:46 | dom96 | Araq: Perhaps I could generate some sort of ID for each iterator and then wake the iterator up in the future's callback |
| 18:56:07 | dom96 | Although these iterators will have no way of returning values. |
| 18:56:14 | shodan45 | hah! nimrod on the eevblog forum! |
| 18:57:23 | shodan45 | eep... not very encouraging: http://www.eevblog.com/forum/microcontrollers/interesting-compilerinterpreter/ |
| 18:58:27 | dom96 | oh yes, I already read that. |
| 18:59:25 | EXetoC | untyped lolwut |
| 18:59:55 | shodan45 | it's fun when different "parts" of your life intersect... I'm a long time subscriber to EEVBlog on youtube :) |
| 19:00:36 | filwit | dom96: built src/babel directly; certain things run fine (./babel update, --help, ect) but not ./babel install opengl |
| 19:00:51 | filwit | dom96: is there something more i need to do to "install" babel from this point? |
| 19:01:29 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 19:02:21 | dom96 | put the binary in ~/.babel/bin |
| 19:02:34 | dom96 | but why does installing opengl fail? |
| 19:02:37 | Araq | shodan45: nimrod simply works :P use --os:standalone and read the docs |
| 19:02:37 | filwit | k |
| 19:02:58 | EXetoC | silly whitespace arguments |
| 19:02:59 | Araq | dom96: the point of iterators and 'yield' is to get rid of callbacks |
| 19:03:00 | * | DAddYE joined #nimrod |
| 19:03:32 | dom96 | Araq: Yes, but it would be nice to be able to compose these things |
| 19:04:20 | Araq | dom96: but you easily can |
| 19:04:36 | Araq | just define some 'OR' and 'AND' events that you can wait on |
| 19:04:39 | filwit | dom96: i believe the soft-link in ~/.babel/bin/babel is pointing to an outdated executable (when i updated, I noticed the folder refactoring) |
| 19:04:56 | filwit | one sec |
| 19:06:33 | dom96 | Araq: Say for example I want to create a 'readLine' iterator. |
| 19:06:50 | dom96 | It will need to return a string at the end |
| 19:07:06 | dom96 | 'OR' and 'AND' events won't really help I don't think. |
| 19:07:42 | filwit | wait.. i already have a 'babel' on my machine and it's not Nimrod related... |
| 19:08:04 | EXetoC | openbabel |
| 19:08:17 | filwit | bleh.. nim-babel |
| 19:09:02 | filwit | or babel-nim, something like that (i have nimrod, nimrod-git, nimrod-fil for my compilers, so it fits) |
| 19:09:24 | dom96 | It seems that many people have that openbabel thing. I wonder why? |
| 19:09:37 | dom96 | Are you actually actively using it? |
| 19:10:37 | filwit | pretty sure it's a dictionary library used by some help centers. It's on my machine probably because of KDE or an old Gnome install |
| 19:10:39 | EXetoC | I don't know what the binary is for |
| 19:10:50 | filwit | just look at the dep in arch |
| 19:10:51 | EXetoC | I had it I think, but wasn't aware of it |
| 19:11:18 | dom96 | 'openbabel' is a "chemical toolbox". |
| 19:11:28 | dom96 | not sure about other babel's |
| 19:11:32 | filwit | openbabel is required by kdeedu-kalzium |
| 19:12:48 | Araq | dom96: a readline iterator is a producer, not a consumer |
| 19:12:57 | filwit | kde has all these games and weird applications that are kinda cool, but I never really use them |
| 19:13:16 | EXetoC | ""The compiler generates optimized C code" so why wouldn't you just write it in C anyway?" |
| 19:13:20 | dom96 | Araq: And what does that mean? |
| 19:13:22 | Araq | I described how consumers can work, not producers |
| 19:13:45 | EXetoC | but then, why stop at C? |
| 19:13:48 | askatasuna | hello everyone, Araq, it's a pleasure to be here. Still reading the docs, I'm sure I'll have worthy questions soon enough. |
| 19:14:11 | dom96 | Araq: Ok, then I am saying that I would like a mix of both. |
| 19:14:34 | Araq | dom96: I made up these terms but 'readline' is not something that you register to the dispatcher is it? |
| 19:14:54 | Araq | it's not a task, it's what a task might want to use |
| 19:15:10 | shodan45 | ok, I'm not reading any more of that eevblog thread.... hardware people suck at software (and usually vice versa....) |
| 19:16:24 | Araq | EXetoC: indeed, "The C compiler generates optimized assembler" so why wouldn't you just write in assembler anyway? |
| 19:17:11 | shodan45 | assembler just generates binaries, so.... |
| 19:17:17 | shodan45 | :) |
| 19:17:26 | dom96 | Araq: Yes, but consider that readLine may want to use 'recv'. |
| 19:18:25 | dom96 | hello askatasuna. Welcome to #nimrod :) |
| 19:19:09 | filwit | dom96: babel's installed now, but when i try to install opengl ($ babel-git install opengl ) i get: Unsatisfied dependency: nimrod (> 0.9.2) |
| 19:19:52 | dom96 | filwit: Why don't you just rename the nimrod 0.9.2 binary to 'nimrod92' or something? |
| 19:20:10 | filwit | it's part of Arch |
| 19:20:24 | filwit | but I guess i'll just get rid of it |
| 19:20:35 | shodan45 | Araq: you have anything like "a history of nimrod" somewhere? (how old is it, anyway?) |
| 19:20:52 | Araq | dom96: gah, designing this is a pita, look at how c# does it please |
| 19:20:56 | filwit | it's not that important, i'm mostly working off of devel now anyways, it's just some of my macros stuff required 0.9.2 |
| 19:22:05 | Araq | dom96: C# has the same restrictions mostly, Python is dynamically typed so we can't copy it |
| 19:23:17 | EXetoC | shodan45: in other words: use magnetized needles for all your programming needs |
| 19:25:30 | dom96 | Araq: I don't think C#'s await has these restrictions. |
| 19:27:59 | Araq | dom96: maybe but I do know they use the same transformation |
| 19:28:37 | dom96 | Async methods in C# return a Task<TResult> |
| 19:28:53 | dom96 | Which is basically equivalent to our PFuture[T] |
| 19:29:10 | filwit | damn, after uninstalling nimrod from Arch, babel tells me: Couldn't find Nimrod version. |
| 19:29:52 | filwit | btw, is nimrod itself part of babel? |
| 19:30:05 | filwit | guess i can just check.. |
| 19:30:05 | dom96 | Well babel obviously needs the nimrod compiler in the PATH to build things. |
| 19:30:10 | dom96 | no. |
| 19:31:44 | filwit | oh, duh. sorry i'm retarded, just renamed the compilers.. |
| 19:34:12 | filwit | everything's working now |
| 19:34:39 | dom96 | good |
| 19:35:42 | filwit | babel's root dir probably shouldn't have a 'babe' executable in it right? that's probably leftover from before I updated it? |
| 19:36:07 | dom96 | how did that happen lol |
| 19:36:23 | filwit | well the source used to be in the root directory |
| 19:36:39 | filwit | and it built the exe directly into the root, idk |
| 19:37:00 | filwit | when i did git pull, it changed the file structure, but left the executable |
| 19:37:06 | filwit | i think |
| 19:37:49 | dom96 | oh. I thought you meant there was literally an exe named 'babe' without the 'l'. |
| 19:37:57 | dom96 | Misspelling I guess |
| 19:40:18 | filwit | yeah, misspelled that one |
| 19:45:42 | filwit | btw, the way modules and packages work now is great, Araq |
| 19:46:00 | dom96 | Araq: looks like I found a c gen error: https://gist.github.com/dom96/cec842c2d241c9e14d92 |
| 19:46:07 | Araq | filwit: thank you. you're the only one who thinks that though |
| 19:46:28 | Araq | dom96: this is not supported |
| 19:46:42 | Araq | I think ... |
| 19:46:49 | filwit | i like how i can have a Foo.nim alongside a 'Foo/..' directory, and then 'import Foo, Foo.Bar, Foo.Baz' |
| 19:47:34 | dom96 | Araq: Well this was my crazy idea about how to do it. |
| 19:47:51 | dom96 | In any case, it still generates incorrect C code so it's a bug. |
| 19:47:56 | Araq | sure |
| 19:48:19 | dom96 | There is another problem in that code too: the closure would need to be generic. |
| 19:48:29 | dom96 | *callback closure |
| 19:49:08 | Araq | I'm thinking that a void iterator should be able to yield just anything |
| 19:49:31 | Araq | we need to weaken the typing a bit here |
| 19:49:59 | dom96 | I don't think we can. |
| 19:50:11 | dom96 | var value = await p.recv(sock, 50) |
| 19:50:24 | dom96 | otherwise the compiler won't be able to infer the return type... |
| 19:50:36 | dom96 | I'm starting to wonder if this is doable with macros |
| 19:51:26 | dom96 | zahary: you there? |
| 19:54:21 | dom96 | zahary once told me how to do it. But I now can't remember. |
| 19:54:52 | Araq | me neither, I don't like this async stuff at all tbh |
| 19:55:36 | Araq | it's just one huge workaround for a collaborative tasking system |
| 19:55:52 | dom96 | I do like it. |
| 19:56:02 | dom96 | But I don't know how it should be implemented under the hood. |
| 19:56:35 | dom96 | oh, here we go: https://gist.github.com/zah/4096467 |
| 19:57:20 | dom96 | It seems that zahary assumes that iterators can return generics. |
| 19:58:32 | dom96 | Which according to you cannot happen right? |
| 19:59:47 | * | aftersha_ joined #nimrod |
| 20:02:08 | Araq | well he uses TPromise[..] and calls it a day |
| 20:02:42 | Araq | that's the nice thing about pseudo code. it always compiles :P |
| 20:02:50 | dom96 | lol |
| 20:05:11 | dom96 | In any case that was his expectation. |
| 20:05:34 | dom96 | and he even does the exact same thing I tried. |
| 20:05:40 | dom96 | The promise has a callback |
| 20:05:46 | dom96 | and he continues the iteration in the callback |
| 20:07:27 | Araq | well yes |
| 20:07:49 | Araq | but having both callbacks and 'yield' doesn't improve anything IMHO |
| 20:07:59 | foodoo | Is it still planned to abolish the Tsomething types? |
| 20:08:08 | foodoo | (with the leading T) |
| 20:08:08 | Araq | foodoo: yup |
| 20:08:37 | dom96 | Araq: It does. |
| 20:08:45 | Araq | dom96: how so? |
| 20:08:51 | dom96 | Araq: Otherwise you have a mess like in my asyncmacro branch |
| 20:09:10 | dom96 | Callbacks mean that you can always choose the callback style if you really want it. |
| 20:09:14 | filwit | Araq: does {.descructor.} still work? or was that depreciated? I didn't find it in the index last i checkted. |
| 20:09:14 | Araq | I see a mess in any case |
| 20:09:16 | * | micklat joined #nimrod |
| 20:09:28 | dom96 | In any case, how else do you want it to work if not via callbacks? |
| 20:09:36 | Araq | filwit: it kind of works, there are bugs left wrt generics |
| 20:09:47 | filwit | okay |
| 20:10:03 | Araq | well all I can think of is my tasking style, dom96 |
| 20:10:17 | Araq | it's simple and works but doesn't support everything you want to support |
| 20:10:57 | Araq | though I think I need to weaken the typing for 'yield' somehow |
| 20:11:52 | Araq | but I really think in threads/processes/tasks |
| 20:12:17 | micklat | Araq & dom96: I'm following your conversation with the help of the log, but I don't manage to grasp the question you're grappling with. Can you provide any pointer, perhaps? I'm curious |
| 20:12:50 | Araq | micklat: how to implement C#'s async/await in detail on top of a classic event loop |
| 20:12:58 | Araq | brb |
| 20:13:10 | dom96 | Araq: Think a little wider then heh |
| 20:13:12 | * | brson joined #nimrod |
| 20:14:16 | micklat | I gather that there will be some compiler support for coroutines, right? |
| 20:14:58 | dom96 | There already kind of is. Although apparently they're not proper coroutines. |
| 20:15:23 | micklat | the question seems to be about typing? |
| 20:16:24 | dom96 | Yes. I want to yield a PFuture which contains a generic value field. |
| 20:16:59 | dom96 | And yielding that is not possible right now. |
| 20:17:07 | dom96 | I'm not sure how else it should be done though |
| 20:17:23 | micklat | I'm very new, so please bear with me. Does the compiler instantiate all generics into monomorphic types before code generation? |
| 20:18:02 | dom96 | oh, Araq will have to answer that. I'm not familiar with such details. |
| 20:19:11 | micklat | are you using closure iterators for the coroutines, and an event loop that calls these iterators? |
| 20:19:53 | dom96 | Well currently the event loop works on the Futures which contain a callback which gets called upon their completion. |
| 20:20:06 | dom96 | My plan was to advance the closure iterators in that callback. |
| 20:20:26 | micklat | and where did you get stuck? |
| 20:21:19 | micklat | if you'd rather not be interrogated like this, please say so and I'll stop. You didn't invite this |
| 20:21:28 | dom96 | hehe. I don't mind. |
| 20:21:44 | dom96 | Well, I got stuck when I found out that I can't just yield a generic. |
| 20:28:31 | Araq | micklat: yes about the monomorphization |
| 20:29:15 | Araq | and yes our coroutine support is the "closure iterators" which are more like python's generators as they cannot capture the full stack |
| 20:30:58 | Araq | dom96: I think you should have PEvent which is not generic, but an inheritance hierarchy and then iterator (): PEvent for the major control flow |
| 20:32:17 | Araq | and then you register these iterators to the dispatcher |
| 20:32:18 | * | DAddYE quit (Remote host closed the connection) |
| 20:32:40 | Araq | this covers 80% of all use cases already |
| 20:32:52 | * | DAddYE joined #nimrod |
| 20:33:10 | Araq | and more elaborate stuff hits a wall quickly because iterators cannot capture the full stack anyway |
| 20:33:50 | Araq | (plus I think more complex control flow is unmaintainable anyway and needs to be rewritten :P ) |
| 20:33:57 | * | brihat quit (Quit: Leaving.) |
| 20:34:13 | dom96 | I dunno, it sounds very convoluted. |
| 20:34:27 | Araq | it's crystal clear, man |
| 20:34:42 | Araq | just think about how an http server works |
| 20:34:58 | filwit | it's so crystal clear it's got a hint of blue in it |
| 20:35:01 | dom96 | It's also less efficient. |
| 20:35:09 | filwit | sorry, had to do the breaking bad reference |
| 20:35:10 | dom96 | The dispatcher will need to handle callbacks and the iterators |
| 20:35:29 | dom96 | filwit: Crystal blue persuasionnnnn |
| 20:35:38 | filwit | :D |
| 20:35:45 | Araq | request comes in, you do some database queries in asyncronous fashion and then you produce the html and send it over the wire |
| 20:35:51 | dom96 | filwit: Breaking Bad, Lost and GoT references are always welcome here. |
| 20:36:07 | Araq | no, I don't get GoT references |
| 20:36:12 | * | brihat joined #nimrod |
| 20:36:49 | filwit | well i haven't watched Lost in awhile, and never finished it, so i guess that balances it out |
| 20:36:53 | filwit | :P |
| 20:37:03 | dom96 | I wish we had some way to summon zahary |
| 20:37:11 | Araq | dom96: it's not less efficient |
| 20:37:12 | filwit | then again, i don't really know any GoT quotes anyways.. |
| 20:37:17 | dom96 | Like a bat signal or something |
| 20:37:31 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 20:37:42 | dom96 | What do we say to death? Not today. |
| 20:39:10 | filwit | ah, of course |
| 20:40:54 | Araq | I'm the mother of dragons |
| 20:42:13 | dom96 | "I am Daenerys Stormborn of House Targaryen, of the blood of old Valyria. I am the dragons daughter..." |
| 20:42:57 | dom96 | Anyway. |
| 20:43:25 | Araq | dom96: you need basic io events and then 'AND' and 'OR' |
| 20:43:41 | dom96 | Araq: I will wait for zahary and ask him. |
| 20:44:09 | Araq | why? we did that already and neither of us really understands his proposals |
| 20:44:23 | dom96 | Because I am sick of wasting time. |
| 20:44:45 | dom96 | I don't want to rewrite it again if he tells me it's wrong. |
| 20:45:02 | Araq | but that is the plan anyway |
| 20:45:18 | Araq | we won't get the first version right anyway |
| 20:45:28 | Araq | so make it simple instead |
| 21:01:56 | micklat | dom96: why is having a non-generic PEvent is less efficient? |
| 21:02:34 | dom96 | "The dispatcher will need to handle callbacks and the iterators" |
| 21:02:40 | dom96 | But according to Araq I am wrong anyway. |
| 21:04:17 | micklat | let me see if I get this straight. The dispatcher sees an IO event. It calls a callback associated with the socket. The callback gets the socket, reads or writes to it. |
| 21:04:52 | micklat | then the callback signals to the dispatcher to advance one of the iterators |
| 21:05:15 | micklat | the dispatcher doesn't need to see the value received via the socket |
| 21:05:54 | micklat | is that what you and Araq are talking about? |
| 21:06:43 | dom96 | yes |
| 21:07:02 | micklat | and what was the supposedly faster alternative? |
| 21:07:53 | dom96 | The callbacks themselves advancing the iterators. |
| 21:08:22 | micklat | and this is a problem because you want the callback to be generic? |
| 21:10:59 | dom96 | no, it's a problem because I want the iterator to be generic |
| 21:11:49 | Araq | dom96: the iterator cannot be generic as you showed |
| 21:12:05 | dom96 | yes, I am aware. |
| 21:12:19 | Araq | so make it not generic for now please |
| 21:12:55 | micklat | can't he write a generic iterator and instantiate it to get a monomorphic iterator? |
| 21:13:10 | * | io2 joined #nimrod |
| 21:13:15 | Araq | ultimately you're designing a heterogeneous container. Generics do not work for that. |
| 21:14:00 | micklat | you mean the socket interface provides a heterogenous stream of values? |
| 21:14:31 | Araq | I mean the dispatcher has a heterogeneous list of things that are waiting for something |
| 21:14:52 | micklat | why does the dispatcher need to know what these things are waiting for? |
| 21:15:13 | Araq | I thought that is his job |
| 21:15:33 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 21:15:33 | Araq | to dispatch back to the task when the event occurred |
| 21:16:30 | micklat | the dispatcher sees an IO event, calls a non-generic callback that handles the event. The callback knows the type of the thing it's waiting for, but the dispatcher only knows about the socket and the callback, not what's coming in via the socket. What am I missing? |
| 21:17:34 | Araq | it's callback based, that's what you're missing |
| 21:17:46 | micklat | I don't follow. |
| 21:17:56 | Araq | we want to avoid callbacks |
| 21:19:17 | Araq | ping ddl_smurf |
| 21:20:22 | ddl_smurf | ? |
| 21:20:37 | Araq | micklat: even with your way "IO event" can be heterogeneous, so it still needs a heterogeneous list of stuff |
| 21:21:14 | micklat | or a record of closures |
| 21:21:43 | Araq | micklat: that's the same, but fair enough |
| 21:23:13 | Araq | ddl_smurf: well you know how async really works, right? so please help us |
| 21:24:40 | micklat | dom96: is your idea implemented anywhere? when I look at asyncio2 I see something that looks like callbacks, so that can't be it. |
| 21:24:56 | ddl_smurf | trying to catch up, one thing isn't clear though: what is the iterator interating over ? |
| 21:25:27 | dom96 | Araq: The dispatcher is not aware of what the futures are waiting on. |
| 21:25:43 | dom96 | Well, for IOCP at least. |
| 21:25:57 | dom96 | Because in IOCP you get a completion event when a requested operation finishes. |
| 21:26:18 | dom96 | micklat: That's where the futures are implemented, yes. |
| 21:26:46 | Araq | ddl_smurf: nothing, think of it as primitive coroutine |
| 21:27:11 | ddl_smurf | this is to write pseudo-sync code that can run async ? |
| 21:27:17 | micklat | dom96: any hint at how anyone intends to avoid callbacks then? |
| 21:27:37 | ddl_smurf | as in, yield control out and return with data ? |
| 21:27:50 | Araq | ddl_smurf: exactly |
| 21:29:48 | ddl_smurf | why is the tight coupling with sockets/io/dispatch needed ? |
| 21:31:04 | ddl_smurf | ah, you're arguing callbacks are more desirable to avoid than the coupling ? |
| 21:31:54 | Araq | I argue callbacks suck for anything |
| 21:32:21 | ddl_smurf | but they are compatible with generics if im following correctly |
| 21:34:39 | ddl_smurf | if you don't like callbacks, what is the method you're recommending to "dynamic dispatch" ? |
| 21:34:48 | EXetoC | event loops? |
| 21:37:01 | micklat | IMHO, if you reject runtime indirection (closures/callbacks) you're only left with compile-time indirection (macros) |
| 21:39:24 | Araq | well obvioulsy I'm aware callbacks are necessary for this |
| 21:40:11 | ddl_smurf | i don't know of a good way to do this, windows has waitforobjects() but to emulate that efficiently on other platforms is difficult |
| 21:40:12 | EXetoC | so the only available alternative is one that sucks? oh well :> |
| 21:40:33 | Araq | but I want the high level API design to not expose them as much as possible |
| 21:40:39 | ddl_smurf | which means that whatever is forwarding the iteration would be hard to get generic |
| 21:41:26 | Araq | but I already said how I think it should be done |
| 21:42:26 | micklat | Sorry if I bothered you with my questions. Good night. |
| 21:42:55 | ddl_smurf | micklat: you did not, as far as my experience goes with this channel, any input is welcome |
| 21:43:29 | Araq | yup |
| 21:43:36 | micklat | oh, good. |
| 21:43:48 | ddl_smurf | araq: in your suggestion, how do you matchup the event with the iterator ? |
| 21:43:53 | Araq | the only thinng that is forbidden here is to criticize c2nim :P |
| 21:45:03 | Araq | ddl_smurf: the iterator tells the dispatcher what it is waiting on, the dispatcher invokes the iterator again, when that event occurred |
| 21:45:43 | micklat | what exactly is the problem with callbacks? having to write them? you accept the performance hit but want to hide the callback behind a nice interface? |
| 21:46:07 | ddl_smurf | so the future object (which i assume is some kind .net optional, or super basic promise) is what you yield and gets filled in |
| 21:46:08 | ddl_smurf | ? |
| 21:46:12 | Araq | micklat: the convoluted control flow that happens when you need to nest them |
| 21:46:15 | dom96 | micklat: People fear "callback hell" |
| 21:46:29 | Araq | ddl_smurf: yes |
| 21:46:43 | dom96 | ddl_smurf: The problem is we can't yield it. Because it's a generic, and we can't yield generics :\ |
| 21:47:11 | Araq | my proposal is to not make it generic and voila, everythings works |
| 21:47:13 | ddl_smurf | why does it need to be typed ? |
| 21:47:25 | Araq | it doesn't |
| 21:47:28 | micklat | why can't future inherit event? |
| 21:47:28 | ddl_smurf | socket isn't spitting types |
| 21:47:46 | Araq | micklat: that's what I propose, I think |
| 21:48:11 | micklat | and what is the objection to that? |
| 21:48:24 | ddl_smurf | you are building this on top of some kind of event loop lib that makes different event types homogenous right ? |
| 21:49:19 | ddl_smurf | so there is one common dispatcher, to whom you ask to iterate you ? |
| 21:50:20 | Araq | ddl_smurf: in my proposal, yes |
| 21:50:35 | ddl_smurf | what is still unclear to me is how, when the dispatcher gets the event, how it find the appropriate iterator |
| 21:50:57 | Araq | well it keeps a table[event, iter] |
| 21:51:10 | dom96 | There are no events here. |
| 21:51:12 | Araq | and so knows what to invoke for each event |
| 21:51:12 | dom96 | Only futures. |
| 21:51:29 | dom96 | These futures promise to contain either an error or any type T. |
| 21:51:49 | dom96 | A callback is associated with a future and it becomes invoked when that future completes. |
| 21:51:51 | Araq | dom96: that might be our misunderstanding then |
| 21:51:54 | ddl_smurf | so basically you have an event loop sending events, all caught by a dispatcher that does a lookup and then forwards that to the iterator |
| 21:52:27 | dom96 | That is all that is implemented. There are no iterators yet, we are in the process of discussing how they should be made to work. |
| 21:52:29 | ddl_smurf | what is surprising with this approach is that the whole point of most event libraries really pretty much boils down to already doing exactly that, albeit via callbacks yes |
| 21:53:01 | dom96 | The goal here is to have C#'s await-like functionality on top of the futures |
| 21:53:44 | Araq | no, the goal here is to be able to write async code almost as if it were sync code |
| 21:54:00 | ddl_smurf | for windows its relatively easy, your future is pretty much a WaitHandle derivate |
| 21:54:02 | Araq | futures are not essential for me |
| 21:54:35 | ddl_smurf | how would you get the return value without futures after the yield ? |
| 21:55:06 | dom96 | The futures are already implemented on top of IOCP |
| 21:55:18 | Araq | I'd simply return them in the 'event' that is yielded, ddl_smurf |
| 21:55:32 | Araq | might be better to call it 'request' then |
| 21:55:38 | Araq | but whatever |
| 21:56:15 | Araq | let foo = await readLineAsync(f) --> |
| 21:56:39 | Araq | let tmp = readLineAsync(f); yield tmp; let foo = tmp.line |
| 21:57:40 | ddl_smurf | dom96: i don't get your criticism of this approach ? sorry |
| 21:57:52 | dom96 | huh? |
| 21:58:15 | ddl_smurf | why would this need generics ? |
| 21:58:52 | dom96 | I'm not criticising it. But I also don't understand what Araq has in mind. |
| 21:59:16 | dom96 | ddl_smurf: Because the Future may contain any type of data. |
| 21:59:49 | micklat | dom96: that's true, but it gets downcast to a base type that is non-generic upon yielding |
| 21:59:51 | ddl_smurf | yes but it doesn't need to, whatever readlineasync returns can specify the type of the data no ? |
| 22:00:10 | micklat | I meant upcast, I think |
| 22:00:12 | EXetoC | variants + RTTI + checks? |
| 22:00:12 | ddl_smurf | there might even be no data |
| 22:00:56 | dom96 | Yes, and how should readLineAsync do that? |
| 22:01:12 | dom96 | There is no way to store types in an object AFAIK |
| 22:01:31 | ddl_smurf | tstringeventfuture = object ? |
| 22:01:56 | Araq | type Request = ref object |
| 22:02:26 | Araq | Req[T] = ref object of Request |
| 22:02:32 | Araq | data: T |
| 22:02:39 | ddl_smurf | (don't forget about error handling btw, seems like PIA with this) |
| 22:03:02 | * | DAddYE joined #nimrod |
| 22:03:09 | Araq | proc readLineAsync(f: File): Req[string] |
| 22:03:16 | Araq | iterator worker(): Request = |
| 22:03:48 | Araq | let r = Req[string]() |
| 22:03:54 | Araq | yield r |
| 22:04:01 | Araq | echo r.data |
| 22:04:40 | ddl_smurf | / throw r.error if r.error |
| 22:04:47 | dom96 | Araq: Are you expecting 'await readLineAsync' to be translated into that? |
| 22:04:56 | Araq | dom96: indeed |
| 22:05:17 | dom96 | And how will the macro know what readLineAsync's return type is? |
| 22:05:29 | Araq | ddl_smurf: exception propagation is no problem with my approach |
| 22:05:32 | OrionPK | araq did you see my message? |
| 22:05:42 | Araq | OrionPK: got the zip, thanks |
| 22:05:57 | * | askatasuna quit (Ping timeout: 248 seconds) |
| 22:05:59 | OrionPK | cool. were you able to repro? |
| 22:06:11 | Araq | dom96: 'await' can be a simple template |
| 22:06:28 | dom96 | Furthermore, how does the request know that you want readLineAsync? |
| 22:06:38 | dom96 | You don't mention it at all in the iterator |
| 22:06:38 | ddl_smurf | so the Request object knows how to read/parse ? |
| 22:07:03 | Araq | template await(x: expr): expr = (let tmp = x; yield tmp; tmp.data) |
| 22:07:23 | dom96 | oh right |
| 22:07:54 | dom96 | That may work. |
| 22:07:59 | Araq | ddl_smurf: not sure what you mean |
| 22:08:21 | ddl_smurf | can you pseudo code readLineAsync please ? |
| 22:09:27 | Araq | proc readLineAsync(f: File): Req[string] = |
| 22:10:10 | Araq | let dispatcher = getGlobalDispatcher() # bah, I guess this means the dispatcher should be passed around |
| 22:10:28 | Araq | return dispatcher.waitForReadline() |
| 22:10:44 | dom96 | yes. |
| 22:10:46 | Araq | ok ok, I don't know how the OS's event stuff works :P |
| 22:11:04 | dom96 | Asyncio2 requires the dispatcher to be passed around |
| 22:11:07 | ddl_smurf | the os's event stuff pretty much does use callbacks |
| 22:11:23 | ddl_smurf | but your method puts all reading/parsing logic into the dispatcher |
| 22:11:48 | ddl_smurf | very difficult to provide custom things you can wait on |
| 22:12:06 | Araq | and yet that's exactly what we want, ddl_smurf |
| 22:12:30 | ddl_smurf | so the real async event is going to be basic |
| 22:12:39 | Araq | well not so much custom, but basic IO, timers and then to OR and AND them |
| 22:12:47 | ddl_smurf | something like read and later on get a buffer |
| 22:13:09 | ddl_smurf | who is buffering the file to find the first line end ? |
| 22:13:32 | Araq | is that important? |
| 22:13:35 | ddl_smurf | (also i'm no so conviced about propagating errors but i don't remember enough nimrod to say for sure) |
| 22:14:13 | ddl_smurf | its important because you want the buffer to be common between calls on the same file, and cleaned up rather aggressively (you also want a maxlinelength) |
| 22:14:51 | * | foodoo quit (Ping timeout: 245 seconds) |
| 22:15:20 | ddl_smurf | some protocols are also interesting, switching between text and binary |
| 22:15:36 | ddl_smurf | so the buffer really needs to live near the lowest level |
| 22:15:56 | Araq | I can't see how this is relevant at this point |
| 22:16:46 | ddl_smurf | since it's hard to add methods like dispatcher.waitForReadline(f) |
| 22:17:03 | ddl_smurf | say i want a dispatcher.waitForXMLStanza(f) |
| 22:18:05 | micklat | wouldn't it be better to bind each socket/file/connection to a single dispatcher, rather than pass the dispatcher around? |
| 22:18:42 | ddl_smurf | maybe have a sub-dispatcher for that file sounds good yeah |
| 22:18:48 | dom96 | Sure, but we can always worry about that later. |
| 22:19:05 | ddl_smurf | but you do want some mecanism to wait for more than one thing simultaneously |
| 22:19:05 | filwit | woah, what there's a kwin binding in babel? That's cool.. |
| 22:19:29 | Araq | micklat: you mean the AsyncFile object has a pointer to the dispatcher? sounds reasonable |
| 22:19:35 | micklat | yes |
| 22:20:09 | dom96 | I think a global dispatcher would suffice, no? |
| 22:20:32 | Araq | imo yes, definitely and it keeps things simple |
| 22:20:35 | ddl_smurf | well one per thread then |
| 22:20:42 | Araq | well make it thread-local, yup |
| 22:20:43 | micklat | what's the benefit of a single dispatcher? |
| 22:20:59 | micklat | if you have a single dispatcher, then only one thread does IO |
| 22:21:07 | micklat | can be a bottleneck, no? |
| 22:21:24 | micklat | or maybe I'm being a bit silly because the os handles that behind the scenes |
| 22:21:28 | Araq | nah, why? the actual IO is done by the OS |
| 22:21:32 | micklat | right |
| 22:21:46 | ddl_smurf | thread local means one per thread, but looks like a global, ie picks the one from the same thread |
| 22:21:58 | micklat | but the dispatcher's thread still does some work, no? |
| 22:22:00 | Araq | ddl_smurf: exactly the way I want it |
| 22:22:15 | * | aftersha_ joined #nimrod |
| 22:22:33 | Araq | ddl_smurf: we have no global GC, so you can't mix refs easily |
| 22:22:34 | ddl_smurf | sure |
| 22:23:00 | ddl_smurf | but i still think a further indirection between the dispatcher and the user is useful |
| 22:23:01 | dom96 | IIRC you can only have one IO completion port per thread anyway. |
| 22:23:07 | ddl_smurf | ie request the dispatcher for the file |
| 22:24:05 | micklat | it depends on whether the OS lets you wait on everything you want to wait on with a single completion port |
| 22:24:26 | ddl_smurf | araq say you have read(file, callback), which is pretty much what the os gives you |
| 22:24:45 | micklat | nah, ignore what I wrote |
| 22:24:49 | ddl_smurf | can you show me how dispatcher.waitForReadline uses that then "translates" to iterations ? |
| 22:25:13 | ddl_smurf | ie what the call to read and callback look like ? |
| 22:26:21 | ddl_smurf | what i have difficulty with is understanding the lifecycle of the file, which you want to be able to follow |
| 22:27:42 | * | askatasuna joined #nimrod |
| 22:30:42 | Araq | well there 2 ways, ddl_smurf |
| 22:31:05 | Araq | (1) make the callback call directly into the iterator that requested the line |
| 22:31:52 | Araq | (2) provide a callback that sets something in a data structure that is periodically polled by the dispatcher |
| 22:32:57 | Araq | or do you still think about the buffer handling? |
| 22:34:39 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 22:36:35 | ddl_smurf | i mean there will be some logic before returning to the yield call |
| 22:36:45 | ddl_smurf | and i don't like polling at all |
| 22:37:26 | ddl_smurf | (at very least decoding to a string, then looking for a line separator, and keeping the extra data for the next call) |
| 22:38:07 | Araq | well it's not real polling but something like it to support AND and OR |
| 22:39:34 | ddl_smurf | the dispatcher is already "OR", no ? i don't get what you mean by it |
| 22:40:04 | Araq | well maybe I'm wrong and that's not necessary |
| 22:40:55 | Araq | I'm still not sure where do you think a problem is |
| 22:41:26 | Araq | buffer handling is something the aync file object does |
| 22:42:06 | ddl_smurf | unless you can reinject data to the buffer, you need a separate buffer for things like reading line by line |
| 22:43:20 | dom96 | Araq: https://gist.github.com/dom96/61bb0b210ec7497565d5 |
| 22:43:33 | dom96 | Araq: It compiles but crashes on line 13 |
| 22:43:40 | dom96 | Am I being too ambitious again? :P |
| 22:44:26 | dom96 | Although it is what you suggested. It doesn't get to my ambitious code even. |
| 22:45:21 | Araq | not too ambitious |
| 22:45:26 | Araq | and bah |
| 22:45:27 | * | isaacdownlow joined #nimrod |
| 22:45:28 | dom96 | oh, just realised I forgot to return retFuture |
| 22:45:32 | dom96 | But that's unrelated to the crash |
| 22:45:33 | * | isaacdownlow left #nimrod ("Leaving") |
| 22:45:45 | dom96 | I guess your approach simply doesn't work? |
| 22:45:55 | Araq | hey, it works |
| 22:46:12 | Araq | once I fix that compiler bug ... |
| 22:46:13 | dom96 | well, it segfaults. |
| 22:46:17 | dom96 | hehe |
| 22:46:19 | dom96 | ok |
| 22:46:27 | dom96 | well if that code works i'll be happy |
| 22:46:38 | dom96 | Because it is pretty much what I had in mind. |
| 22:46:49 | Araq | yay |
| 22:47:03 | * | psquid joined #nimrod |
| 22:48:21 | Araq | what's this 'cbVoid' stuff? |
| 22:48:25 | Araq | looks frightening |
| 22:48:31 | dom96 | lol |
| 22:48:47 | dom96 | I added another callback to the future |
| 22:49:03 | dom96 | One which avoids the generics |
| 22:49:12 | dom96 | i.e. I put it in the PFutureVoid |
| 22:49:51 | * | [2]Endy quit (Ping timeout: 245 seconds) |
| 22:50:05 | dom96 | btw does the name 'void' work in this context? |
| 22:50:56 | Araq | dunno what it means here |
| 22:51:10 | Araq | it's not PFuture[void], is it? |
| 22:51:17 | dom96 | no |
| 22:51:24 | dom96 | Well it means that the value is missing |
| 22:51:28 | dom96 | or rather |
| 22:51:31 | dom96 | it's "hidden" |
| 22:51:43 | dom96 | because it is technically there |
| 22:53:23 | dom96 | it's exactly how you defined your 'Request' |
| 22:53:36 | dom96 | But I don't want to name it PFuture and PFut[T] |
| 22:54:10 | Araq | I noticed, yes |
| 22:54:20 | dom96 | Araq: Do you want me to push this cbVoid stuff so that you can run this gist and fix the bug? |
| 22:55:36 | Araq | dom96: of course |
| 22:56:17 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 22:58:54 | NimBot | Araq/Nimrod newasync 55fbb17 Dominik Picheta [+0 ±1 -0]: Added a generic-lacking version of PFuture. |
| 22:58:57 | dom96 | there you go |
| 23:09:55 | * | micklat quit (Remote host closed the connection) |
| 23:28:36 | Demos | there is an example in the manual of a "name" proc that accepts a typedesc, does that actually exist? |
| 23:29:59 | Araq | Demos: in the typetraits module |
| 23:30:05 | Demos | thank you |
| 23:31:10 | Demos | aaaaand it is returning "typedesc" |
| 23:31:21 | * | askatasuna joined #nimrod |
| 23:35:21 | Araq | yeah, nothing works in nimrod wonderland these days |
| 23:35:31 | filwit | wonderland? |
| 23:45:57 | dom96 | Interesting: http://www.reddit.com/r/gaming/comments/1xdggv/flappy_bird_dev_dong_nguyen_just_tweeted_this/ |
| 23:46:52 | dom96 | $50K per week doesn't buy happiness it seems. |
| 23:48:02 | dom96 | *per day |
| 23:48:28 | Araq | interesting aporia already uses a closure iterator |
| 23:48:50 | dom96 | of course |
| 23:48:58 | dom96 | For the text highlighting |
| 23:49:35 | * | darkf joined #nimrod |
| 23:57:30 | Araq | dom96: aporia and the async issue might be the same bug |
| 23:57:36 | Araq | so I'm fixing aporia first |
| 23:57:38 | dom96 | ok good |
| 23:58:37 | NimBot | Araq/Nimrod devel 4e0759b Araq [+0 ±5 -0]: fixes 'newSeq[T]' instantiation bug |
| 23:58:37 | NimBot | Araq/Nimrod devel d449117 Araq [+0 ±1 -0]: fixes #882; fixes #853 |
| 23:58:37 | NimBot | Araq/Nimrod devel 3e8f8d1 Araq [+0 ±1 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |