00:01:47 | vbtt_ | compiling one of the examples in the manual: inheritance only works with non-final objects |
00:04:12 | vbtt_ | nm, fixed by '{. inheritable .}' |
00:04:25 | vbtt_ | btw, i broke the compiler :) |
00:04:58 | vbtt_ | Error: internal error: value expected, but got a type |
00:05:47 | Araq | well the value/type unification had its price |
00:06:09 | Araq | it's well known we need a better error message for that |
00:06:23 | Araq | var x = int # likely a typo like this on your part |
00:06:49 | vbtt_ | ok, i modified the code and cant repro now. |
00:10:07 | wan | reactormonk: A server 'via zeromq'? What does that mean? |
00:11:02 | reactormonk | wan, nah, just a server. The data will be grabbed via zmq |
00:11:05 | wan | reactormonk: I made a Mongrel2 handler framework, so it uses zeromq to connect to Mongrel2. Does that count? |
00:11:39 | wan | dom96: What makes you avoid zeromq? |
00:12:11 | dom96 | wan: dependencies |
00:13:47 | wan | I'm confused. Dependencies are never a problem when you use a package manager. Are you on Windows? |
00:14:17 | wan | https://www.archlinux.org/packages/community/x86_64/zeromq/ There's hardly any dependencies |
00:14:38 | reactormonk | dom96, I only see libsodium |
00:14:53 | dom96 | I mean: the dependency on zeromq |
00:15:43 | reactormonk | dom96, NIH? |
00:15:48 | wan | Oh. Yeah, you're stuck with it afterwards, but for a transport library, I don't see any other way |
00:20:44 | wan | reactormonk: nginx+jester should be okay for a general-purpose server. You can try Mongrel2+nawak if you're not scared of Mongrel2 too. |
00:21:43 | wan | dom96: by the way, I can't make jester resist alone agains wrk assaults. I haven't tried behind nginx though. |
00:22:20 | dom96 | wan: I know. Httpserver is not yet ready for that. |
00:22:27 | dom96 | It's only meant to be used for testing. |
00:29:03 | NimBot | Araq/Nimrod devel 139d1ec Araq [+5 ±3 -4]: tester support html generation |
00:29:03 | NimBot | Araq/Nimrod devel b5e61ef Araq [+0 ±1 -0]: tester: htmlgen almost works |
00:29:10 | Araq | good night |
00:30:23 | wan | good night |
00:30:59 | vbtt_ | night |
00:33:04 | dom96 | wan: To be fair I haven't really looked much at zmq. So what does it actually simplify? |
00:34:04 | wan | everything :) |
00:34:18 | wan | Nah, I'm just not that advanced in zmq |
00:34:35 | wan | But the Mongrel2 handler was simple enough to code |
00:35:06 | wan | The api is quite short, especially if you have simple needs |
00:35:52 | wan | It's simpler sockets, where you transmit whole messages at once |
00:36:02 | * | xenagi joined #nimrod |
00:36:24 | wan | The server and client don't need to bind and connect in a specific order |
00:38:43 | dom96 | I just feel that I may as well use raw sockets. |
00:38:59 | dom96 | It's not that hard to. |
00:39:58 | wan | The nimrod/examples/0mq show the nice api that you can end up with |
00:40:12 | wan | It's just less things to worry about than raw sockets |
00:41:28 | dom96 | What worries would that be? |
00:45:02 | wan | With zmq, you get complete messages, not "all that could fit in the buffer, but don't forget to re-recv after if there is more" |
00:46:22 | wan | Now you're making me doubt. I am not sure of what I am writing. |
00:47:17 | wan | I know there are advantages, I am probably too fanboyish after having read the beginning of the zmq book. |
00:47:31 | wan | It sells it very well. |
00:48:32 | wan | http://zguide.zeromq.org/page:all#Chapter-Basics |
00:48:57 | dom96 | hehe |
00:52:45 | wan | Well anyway, the pub-sub sockets are reason enough for me to use zmq |
00:52:52 | dom96 | Someone should Nimrod into the list of languages on there. |
00:53:35 | wan | Yeah, but the book is sooo long, there are a lot of examples to write. |
00:54:11 | dom96 | You don't have to write all the examples, some of the languages listed there don't have even the first example written. |
00:57:57 | wan | You could also just take the python examples, add some 'var' everywhere, and bob's your uncle |
01:02:53 | dom96 | yep heh |
01:18:05 | dom96 | Good night |
01:19:07 | wan | night |
01:32:30 | * | Demos joined #nimrod |
01:43:45 | * | icebattle quit (Quit: Leaving) |
02:03:56 | Demos | agh publishing color textbooks should be punishable by death |
02:16:55 | * | DAddYE quit (Remote host closed the connection) |
02:17:21 | * | DAddYE joined #nimrod |
02:22:18 | * | DAddYE quit (Ping timeout: 276 seconds) |
02:32:23 | * | DAddYE joined #nimrod |
02:51:52 | OrionPK | seems a bit harsh |
02:52:04 | OrionPK | are you from the middle East? |
02:52:17 | Demos | I dun think so, they are like 10x more expensive than a black and white book for zero gain |
02:52:26 | Demos | I am someone who just spend over $500 on textbooks |
02:56:19 | OrionPK | yeah. welcome to university |
03:00:52 | Demos | yeah, looking at my classes I dun think I will have much time to work on nimrod related things... |
03:01:18 | Demos | an intensive linear algebra class and a basic chem class filled with buyswork |
03:14:39 | * | dmac quit (Quit: Leaving.) |
03:17:38 | * | bogomips quit (Ping timeout: 252 seconds) |
03:27:20 | OrionPK | :-\ |
03:27:32 | OrionPK | are you undergrad? what year? |
03:49:58 | Demos | Sophomore and yes |
03:50:14 | OrionPK | figured you would be older, using visual studio and whatnot :p |
03:50:52 | Demos | hehe, no. I like VS, but more than that I recognise that nimrod kinda needs it, being so suited for games |
03:51:42 | Demos | it is nice that you thought that though :D |
03:51:53 | OrionPK | ;) |
03:55:21 | Demos | watching Dexter. Somewhat morbid |
03:56:39 | OrionPK | decent show |
03:57:02 | OrionPK | not sure i liked how it ended though :p |
03:57:20 | Demos | I am just on the pilot |
03:58:16 | Demos | Fuck HBO though, many decent shows that are impossible to find leagally and reasonably priced |
04:00:01 | OrionPK | yeah |
04:00:15 | OrionPK | i have HBO right now |
04:00:27 | OrionPK | but only because I called comcast and they gave me a deal |
04:00:31 | Demos | I guess I could find a video rental place, although I dun know if they exist in places that have access to high-speed internet |
04:00:39 | OrionPK | nah, torrent ftw. |
04:00:42 | Demos | have fun trying to cacnel that in a few months :D |
04:00:49 | Demos | I dont like to torrent on UM's network |
04:00:51 | OrionPK | well, thats what I did |
04:00:54 | OrionPK | it's 12 months though |
04:01:00 | OrionPK | I called in saying i wanted to cancel my TV altogether |
04:01:08 | OrionPK | and they said they'd give me HBO and reduce my bil by like $30/mo |
04:01:16 | OrionPK | "gee okay" |
04:01:21 | Demos | I could pull them from usenet, but that is a monthly fee as well that I dun want to pay |
04:01:25 | OrionPK | I'll call again in 12 months |
04:01:36 | OrionPK | you should just pay for a proxy |
04:01:38 | OrionPK | and torrent |
04:01:53 | OrionPK | i like btguard |
04:01:59 | Demos | but the proxy and the usenet sub are similar prices and usenet can saturate my connection better |
04:02:41 | Demos | also, couch-potato and sickbeard |
04:04:20 | Demos | and you get access to the good ol' comp.lang groups :D |
04:06:28 | * | brson quit (Quit: leaving) |
04:07:05 | OrionPK | either way, small price to payy |
04:24:34 | * | xenagi quit (Quit: Leaving) |
04:47:05 | * | DAddYE_ joined #nimrod |
04:48:45 | * | DAddYE quit (Ping timeout: 245 seconds) |
04:49:31 | * | DAddYE_ quit (Client Quit) |
05:53:04 | * | ddl_smurf joined #nimrod |
05:55:29 | * | achim joined #nimrod |
06:08:28 | * | isenmann joined #nimrod |
06:13:12 | * | dirkk0 joined #nimrod |
06:21:47 | * | dirkk0 quit (Quit: Leaving) |
06:41:00 | * | dmac joined #nimrod |
06:47:37 | * | dmac quit (Ping timeout: 245 seconds) |
07:01:24 | * | Demos quit (Read error: Connection reset by peer) |
07:04:33 | * | viteqqq joined #nimrod |
07:20:47 | * | viteqqq quit (Ping timeout: 272 seconds) |
07:37:16 | * | XAMPP_ quit (Read error: Connection reset by peer) |
07:37:41 | * | XAMPP joined #nimrod |
07:40:09 | * | dmac joined #nimrod |
07:45:45 | * | dmac1 joined #nimrod |
07:50:26 | * | dmac1 quit (Ping timeout: 252 seconds) |
08:15:55 | * | dmac1 joined #nimrod |
08:20:07 | * | dmac1 quit (Ping timeout: 245 seconds) |
08:28:44 | * | Araq_ joined #nimrod |
08:31:32 | * | odc joined #nimrod |
09:02:56 | * | fowl quit (Ping timeout: 252 seconds) |
09:05:48 | * | q66 quit (Quit: Leaving) |
09:09:34 | * | darkf_ joined #nimrod |
09:12:05 | * | darkf quit (Ping timeout: 245 seconds) |
09:14:50 | * | fowl joined #nimrod |
09:16:01 | * | dmac1 joined #nimrod |
09:20:21 | * | dmac1 quit (Ping timeout: 252 seconds) |
09:34:03 | * | dmac quit (Ping timeout: 272 seconds) |
09:36:27 | * | dmac joined #nimrod |
09:37:09 | * | dmac quit (Client Quit) |
09:43:49 | * | dmac joined #nimrod |
09:51:56 | * | darkf_ is now known as darkf |
09:57:21 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
10:01:26 | * | dmac quit (Quit: Leaving.) |
10:17:33 | * | NimBot joined #nimrod |
10:31:53 | * | BitPuffin joined #nimrod |
10:42:57 | * | Araq_ joined #nimrod |
11:02:09 | * | dmac joined #nimrod |
11:07:04 | * | dmac quit (Ping timeout: 265 seconds) |
11:09:12 | * | Araq_ quit (Read error: Operation timed out) |
11:10:09 | * | Araq_ joined #nimrod |
11:40:39 | * | BitPuffin quit (Ping timeout: 276 seconds) |
12:02:23 | * | dmac joined #nimrod |
12:06:40 | * | dmac quit (Ping timeout: 245 seconds) |
13:02:48 | * | dmac joined #nimrod |
13:06:40 | * | darkf quit (Quit: Leaving) |
13:07:14 | * | dmac quit (Ping timeout: 252 seconds) |
13:58:46 | * | [1]Endy joined #nimrod |
14:03:09 | * | dmac joined #nimrod |
14:07:45 | * | dmac quit (Ping timeout: 272 seconds) |
14:21:06 | * | BitPuffin joined #nimrod |
14:31:59 | OrionPK | quiet day |
14:45:03 | Araq_ | yup |
15:03:32 | * | dmac joined #nimrod |
15:07:55 | * | dmac quit (Ping timeout: 245 seconds) |
16:03:47 | * | dmac joined #nimrod |
16:07:58 | * | dmac quit (Ping timeout: 246 seconds) |
16:09:49 | * | viteqqq joined #nimrod |
16:11:20 | * | TylerE joined #nimrod |
16:11:31 | TylerE | How can I tell koch which c toolchain to use? |
16:11:31 | * | BitPuffin quit (Ping timeout: 272 seconds) |
16:11:49 | TylerE | I'm on a windows box with native (mingw) and unix-y (cygwin gcc) toolchain |
16:12:04 | TylerE | the problem is it's compiling with the cygwin gcc but using windows options |
16:12:12 | TylerE | so the build fails when it can't link _wfopen |
16:15:09 | reactormonk | Araq_, https://github.com/Araq/Nimrod/pull/789 can you double-check? Looks good to me. |
16:25:18 | OrionPK | Araq_ did you come to a decision on what you want done w/ select |
16:25:20 | * | shevy joined #nimrod |
17:04:14 | * | dmac joined #nimrod |
17:07:16 | discoloda | sent my pull request for c2nim changes |
17:08:41 | * | dmac quit (Ping timeout: 252 seconds) |
17:34:03 | * | q66 joined #nimrod |
17:37:59 | * | faassen left #nimrod (#nimrod) |
17:53:26 | * | DAddYE joined #nimrod |
17:57:06 | * | brson joined #nimrod |
18:10:01 | * | CarpNet quit (Quit: Leaving) |
18:15:55 | * | dmac joined #nimrod |
18:33:52 | Araq | hi TylerE |
18:34:21 | Araq | did you try changing nimrod.cfg? |
18:49:11 | * | brson quit (Ping timeout: 260 seconds) |
18:50:04 | * | brson joined #nimrod |
18:51:28 | TylerE | no I haven't, but I will |
18:53:16 | * | dmac quit (Quit: Leaving.) |
18:55:14 | TylerE | that worked, yea! |
18:55:48 | TylerE | I have this horrible bastard environment where I'm running zsh+mostly unixy toolchain ontop of Win7 |
18:56:02 | discoloda | heh, ncie |
18:56:03 | TylerE | but I didn't want nimrod compiled against cygwin because then the binaries aren't very portable |
18:56:23 | TylerE | it's actually a nice setup |
18:56:38 | TylerE | I have a fairly decent terminal emulator, and all my unix command line tools |
18:57:00 | TylerE | I've started working from home so I'm on my old gaming pc, not the nice mac I had at my old job, heh |
18:57:05 | TylerE | so I've had to adapt to stay sane |
18:57:19 | * | dmac joined #nimrod |
18:57:40 | discoloda | no linux can seem to use my wireless adapter, so i just ssh into a linux machine to do my development stuff |
18:58:06 | zahary_ | hmm, I never had luck running zsh on windows. did you use the one from cygwin? |
18:58:32 | * | dmac quit (Client Quit) |
19:19:51 | * | Mat3 joined #nimrod |
19:20:49 | Araq | discoloda: please use x.splitFile.ext instead of your string "parsing" stuff |
19:21:01 | * | dmac joined #nimrod |
19:21:06 | Mat3 | hello |
19:21:24 | * | dmac quit (Client Quit) |
19:22:11 | * | dmac joined #nimrod |
19:22:23 | * | dmac quit (Client Quit) |
19:22:26 | discoloda | Araq: sure |
19:30:28 | discoloda | splitFile and changeFileExt return and take different formats for the extension |
19:32:18 | Araq | not really changeFileExt supports what splitFile returns |
19:32:29 | Araq | ... I hope |
19:32:49 | discoloda | im just looking at the docs |
19:33:39 | discoloda | looks like it works both ways |
19:34:11 | * | dmac joined #nimrod |
19:34:23 | * | dmac quit (Client Quit) |
19:35:17 | * | dmac joined #nimrod |
19:40:17 | * | dmac quit (Quit: Leaving.) |
19:41:44 | * | dmac joined #nimrod |
19:42:55 | OrionPK | https://github.com/symisc/vedis |
19:45:21 | discoloda | so, its like sqlite for nosql |
19:45:58 | * | dmac quit (Client Quit) |
19:47:23 | Varriount | Araq: Nimrod is insidiously affecting the way I program. I've started using the word "procedure" when documenting python code. |
19:47:55 | * | BitPuffin joined #nimrod |
19:48:24 | * | BitPuffin quit (Client Quit) |
19:48:40 | * | BitPuffin joined #nimrod |
19:48:55 | * | aftersha_ joined #nimrod |
19:50:42 | Araq | Varriount: cool :-) |
19:56:46 | Araq | discoloda: I don't like the try except, please introduce ERetryParsing and catch only that |
19:57:19 | discoloda | ok |
20:00:43 | discoloda | do you mean a new exception code or something else? |
20:01:53 | Araq | a new one |
20:02:10 | Araq | apart from that it looks good, superb work |
20:02:25 | Araq | if the tests still work that is ;-) |
20:02:55 | OrionPK | this wrt the c2nim stuff? |
20:03:03 | Araq | yes |
20:03:36 | OrionPK | are new tests being added? |
20:04:19 | Araq | yes |
20:04:28 | Varriount | Hey, do for loops accept an following "else" statement, a-la python? |
20:06:40 | Araq | no, use a block instead and break from that |
20:13:52 | Mat3 | will Nimrod support transient closures in future ? |
20:14:22 | reactormonk | Mat3, what's a transient closure exactly? |
20:16:12 | Mat3 | closures with one persisted return argument |
20:16:24 | reactormonk | persisted? |
20:17:11 | Mat3 | which means the variable is bound to a local scope of some sort |
20:17:28 | reactormonk | so you want blocks to have a return value? |
20:18:37 | Mat3 | hmm, good idea |
20:20:45 | reactormonk | do we have zmq, zlib and json bindings in nimrod? |
20:20:55 | Araq | yeah |
20:22:36 | reactormonk | how would you store a bunch of JSON messages? |
20:25:23 | reactormonk | couchdb porbably |
20:25:47 | Araq | postgre has json support now |
20:26:18 | Araq | I'd likely transform it into structured sql and store it in sqlite |
20:26:29 | Araq | but that's just me |
20:28:53 | * | dmac joined #nimrod |
20:29:01 | reactormonk | probably |
20:29:45 | * | mal`` quit (Ping timeout: 276 seconds) |
20:31:23 | * | EXetoC quit (Quit: WeeChat 0.4.2) |
20:33:11 | * | filwit joined #nimrod |
20:34:18 | filwit | seems like the forums have been getting more posts recently |
20:36:01 | * | dmac quit (Quit: Leaving.) |
20:36:12 | Araq | from drdobbs I guess |
20:36:44 | discoloda | hearthstone is pretty good |
20:38:05 | * | dmac joined #nimrod |
20:38:50 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
20:39:25 | * | aftersha_ joined #nimrod |
20:53:42 | * | mal`` joined #nimrod |
20:53:52 | * | Mat3 my documentation effort progresses |
20:58:59 | Araq | Mat3: cool |
21:06:48 | * | [1]Endy quit (Ping timeout: 276 seconds) |
21:12:47 | Mat3 | need some sleep, ciao |
21:13:01 | * | Mat3 quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
21:16:29 | Araq | reactormonk: gradha's documentation patch is fine |
21:16:44 | Araq | but we now merge into devel |
21:17:08 | discoloda | Araq: thanks, and the tests do work |
21:17:50 | Araq | discoloda: tell me when you've updated your patch and I'll happily apply it |
21:17:56 | * | radsoc joined #nimrod |
21:18:14 | discoloda | okay |
21:21:15 | * | DAddYE quit (Remote host closed the connection) |
21:21:52 | * | DAddYE joined #nimrod |
21:22:27 | * | achim quit (Quit: Computer has gone to sleep.) |
21:36:19 | discoloda | Araq: updated |
21:39:33 | * | odc quit (Ping timeout: 252 seconds) |
21:40:54 | filwit | Araq: sorry, was bussy. Did some new article get posted on DrDobbs? |
21:41:02 | filwit | Araq: also, any word on your video? |
21:41:07 | filwit | busy* |
21:42:22 | NimBot | Araq/Nimrod devel 15cd2e9 Vincent Burns [+0 ±1 -0]: Added spliceHeader option to c2nim... 1 more lines |
21:42:22 | NimBot | Araq/Nimrod devel bc6d938 Vincent Burns [+0 ±1 -0]: Lex '\xHH' character constants |
21:42:22 | NimBot | Araq/Nimrod devel d9eba6f Vincent Burns [+0 ±1 -0]: Properly lex floating constants... 4 more lines |
21:42:22 | NimBot | Araq/Nimrod devel 3ddf055 Vincent Burns [+0 ±1 -0]: New expression parser... 2 more lines |
21:42:22 | NimBot | 8 more commits. |
21:43:15 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
21:43:29 | Araq | filwit: sorry I have no new information concerning my video |
21:43:40 | filwit | k |
21:44:06 | filwit | kinda odd how all the videos for the last month have not been released |
21:44:20 | Araq | discoloda: thanks |
21:49:03 | filwit | Araq: about the interfaces forum post. It seems the only argument there is that "interfaces" are 'hard' in Nimrod. Would you ever consider an OOP lib in the stardard libs? (one that provides macros for class/trait declarations) ? |
21:49:28 | filwit | Araq: not suggesting anything, just wondering if you would be against it or not |
21:50:20 | * | tq_ joined #nimrod |
21:50:22 | Araq | no, I'd welcome it |
21:50:32 | Araq | to stop these arguments for good ;-) |
21:50:35 | * | tq_ quit (Client Quit) |
21:50:42 | filwit | okay, great, yeah that's what i was thinking |
21:50:56 | filwit | it took me a good year before i found that was even possible |
21:51:33 | filwit | i'm guessing other's are equally as ignorant, and write of Nimrod as not having the capability or simply that it's too hard to be practical |
21:51:47 | filwit | write off** |
21:54:32 | filwit | not to mention such a lib would make porting existing C++/C#/Java/etc code to Nimrod a bit more realistic |
21:54:50 | filwit | i'll try playing around with a lib for a proposal later |
21:56:52 | Araq | the nice thing is that even the stdlib can make use of such a "class" macro and doc2 will translate it into "standard" nimrod |
21:58:00 | filwit | yeah i noticed the compiler is very good at tracking where code came from even if it's in the body passed to a macro |
21:58:09 | filwit | really good work there |
21:58:38 | dom96 | Wouldn't it be better to generate some "class" specific docs? |
21:58:47 | filwit | makes doing this sort of thing actually possible (it wouldn't work if you couldn't get errors) |
21:59:18 | Araq | dom96: I don't think so, doc2 needs to be able to group by "first argument type" but that's planned already |
21:59:34 | Araq | and should work even when you don't use the class macro |
21:59:49 | dom96 | Also what happened since yesterday? When I asked for sugar for interfaces you were telling me that it "doesn't come up often" |
22:00:00 | dom96 | And now you're all for it? |
22:00:23 | Araq | sorry seems to have been a misunderstanding |
22:00:53 | filwit | either way, the fact that the doc-gen can already work with this sort of macro is awesome |
22:00:58 | Araq | I don't care about an "interface" macro but I surely won't implement "interface" as a core feature in the language |
22:01:30 | Araq | and yes, it doesn't come up often when you know what you're doing |
22:01:49 | dom96 | Ahh, ok. I had a macro in mind yesterday. |
22:02:23 | filwit | yeah, it's funny i thought Interfaces where a big missing feature |
22:02:35 | filwit | but now i can't think of an area i would really be pressed to use them |
22:03:17 | filwit | still, it would be convenient for those that love the style, those that are learning the language, and those that are porting exist codebases |
22:03:37 | dom96 | Yes, and for those people a macro will be perfect. |
22:03:42 | Araq | yeah sure, no disagreement here |
22:03:51 | filwit | plus we could support multi-paradims (class/trait, multi-inheritance, prototype inheritance, etc) |
22:04:10 | filwit | which is kinda like "nah nah nah, look what Nimrod can do :P" |
22:04:20 | dom96 | But we should talk about "the nimrod way" when it comes to these things. |
22:04:21 | filwit | "your language only supports one, pffft" |
22:04:28 | filwit | lol |
22:04:30 | discoloda | hmm, now i can do cs2nim (C# to Nimrod) |
22:05:03 | dom96 | You discourage interfaces and yet we have one instance of them in the stdlib. |
22:05:17 | dom96 | And soon will have a second one if I ever finish my async stuff. |
22:05:31 | Araq | yes. 1 instance. as I said, doesn't come up often |
22:06:23 | dom96 | Methods are in the language and yet they are not used in the stdlib at all :P |
22:06:47 | Araq | discoloda: I created the C++ mode to help anybody who wants to wrap Qt. unfortunately nobody volunteered. Any chance you're interested? :-) |
22:07:13 | Araq | (I mean c++ support in c2nim) |
22:07:43 | Araq | dom96: and in retrospect I wouldn't add them, I think :P |
22:07:48 | * | vbtt_ is now known as vbtt |
22:08:12 | discoloda | yeah, i can continue c2nim. doesnt Qt use an additional preprocessor (qmake) ? |
22:08:14 | dom96 | Yes, and I still have not found a single use case for them. |
22:08:27 | dom96 | I have found a use case for interfaces however. |
22:08:33 | Araq | ask fowl then, he likes them |
22:09:17 | dom96 | Rather than me using these low-level interfaces perhaps you can suggest a better approach? |
22:11:11 | Araq | use closure closure iterators, lol |
22:11:48 | Araq | discoloda: afaict the additional preprocessor is entirely optional |
22:12:21 | filwit | oh, btw, is there a way to detect if a specific overload exists? (aka: when declared(foo.bar(int, string)): |
22:12:44 | Araq | no, indeed you need to workaroud with "compiles" for that |
22:13:18 | Araq | but as I said, we'll collect usages of "compiles" can provide proper ways to do these things as "compiles" is a hack |
22:13:27 | Araq | *and provide |
22:13:39 | filwit | okay. any chance that will be change in the future ? (i'll need this ability to combine script code with editor generated code) |
22:13:56 | dom96 | Araq: Should I even bother trying to figure out how that would work? |
22:14:00 | filwit | (eventually, not right now) |
22:14:05 | reactormonk | Araq, how to merge into devel? |
22:14:17 | Araq | reactormonk: I don't know |
22:14:38 | Araq | filwit: not sure what you're asking |
22:15:10 | filwit | i was asking if "declared(foo.bar(int, string))" would be supported in the future (or something like it)? |
22:15:22 | Araq | dom96: sure |
22:15:30 | Araq | filwit: sure |
22:15:45 | dom96 | Araq: elaborate then |
22:16:35 | filwit | Araq: is it easy to implement (aka, something you think i could manage)? |
22:17:04 | filwit | i imagine it would be, guess i'll just have to try and see |
22:18:42 | filwit | oh, and one more thing (i need to take off), should i be hacking on the devel or master branch? |
22:19:02 | Araq | devel |
22:19:07 | filwit | okay, thanks |
22:19:15 | filwit | g2g, later folks |
22:19:20 | vbtt | strangely, hash(x) == x when x is an integer. |
22:19:21 | * | filwit quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
22:20:02 | Araq | vbtt: iirc that's a feature as small numbers are much more common than large ones |
22:20:38 | Araq | and so when you do 'and M' you get a good distribution |
22:20:49 | Araq | I'm quite sure python does the same |
22:20:58 | vbtt | yes it does (except for a couple of special cases) |
22:21:10 | vbtt | because Python's hash table implementation is optimized for it too. |
22:22:35 | Araq | well Jehan looked at the code and considered it good enough |
22:22:42 | vbtt | ok |
22:23:01 | reactormonk | Araq, done. Let's see if it worked. |
22:23:12 | Araq | (and iirc Jehan wrote python's hash table implementation) |
22:23:48 | vbtt | what, really? |
22:24:09 | reactormonk | nope. |
22:28:38 | Araq | vbtt: yes I think so, but can't find the forum post |
22:31:48 | dom96 | Araq: well? |
22:32:49 | Araq | dom96: well I don't know, you have all sorts of callbacks with strange abstract types and closure closure iterators are not implemented yet |
22:33:19 | Araq | I can tell you what I would do though |
22:34:10 | Araq | I would simply use PObject everywhere until it becomes clear how the types really look like :P |
22:34:27 | Araq | but you're much further in your design already, I think |
22:34:28 | vbtt | switching over to my fav topic - concurrency. you're probably aware but coroutines with async io is the in thing these days. |
22:34:46 | vbtt | parallelism is another story. |
22:35:05 | vbtt | i just want to cast my vote for coroutines with async io. |
22:35:08 | dom96 | Araq: Look at lib/pure/selectors.nim in the newasync branch |
22:35:19 | Araq | yes I'm aware, though most languages don't provide full coroutines |
22:36:25 | reactormonk | does zmq expect a certain type of message? |
22:37:08 | reactormonk | rather, how do I sub with the zmq bindings. |
22:37:19 | Araq | vbtt: we got closure iterators that are with a simple macro just like c#'s async/await |
22:37:45 | Araq | reactormonk: the zmq binding has simple example programs |
22:38:15 | Araq | the message type is string but you can use marshal to get proper typing |
22:39:30 | * | radsoc quit (Ping timeout: 252 seconds) |
22:39:53 | reactormonk | Araq, sadly it doesn't receive anything |
22:40:18 | reactormonk | http://dpaste.com/1551720/ |
22:41:10 | reactormonk | the corresponding ruby script works. http://dpaste.com/1551722/ |
22:42:27 | Araq | reactormonk: I tested it, but I guess a newer zmq version broke stuff |
22:44:03 | reactormonk | the example still kinda works |
22:44:17 | reactormonk | except the data is empty |
22:44:36 | reactormonk | Araq, how did you create it? |
22:44:40 | vbtt | Araq:are closure iterators implemented already? |
22:45:25 | Araq | vbtt: yes but an important feature is missing and they are a bit buggy |
22:45:35 | vbtt | Araq: also, iterators are only one function frame level deep, right? |
22:45:42 | Araq | right |
22:45:59 | Araq | hence they are more like python's generators than coroutines |
22:46:00 | dom96 | Araq: Please? |
22:46:12 | Araq | but c# does the same, so it's fine :P |
22:48:22 | * | brson quit (Ping timeout: 265 seconds) |
22:49:08 | reactormonk | what's the syntax for a pointer literal? Possible at all? |
22:49:45 | vbtt | Araq:not quite. very weak compared to true coroutines with asyncio |
22:50:28 | Araq | dom96: I am still reading it |
22:50:39 | vbtt | Araq: Python is behind in the concurrency area. (and given what you said, so is c#) |
22:51:04 | dom96 | Araq: Thanks. |
22:51:27 | vbtt | anyway, even if not in v1.0, does the design of nimrod allow coroutines in the future? |
22:52:32 | vbtt | basically you have to be able to use heap allocated stack for the coroutines. |
22:53:07 | Araq | I know perfectly well how to implement proper coroutines, thank you |
22:53:25 | Araq | it's quite some work and requires patches to the GC too |
22:53:27 | * | viteqqq quit (Ping timeout: 245 seconds) |
22:54:00 | vbtt | heh ok |
22:54:27 | vbtt | so the reason nimrod doesn't have them is because of the work required or a language design decision? |
22:54:40 | Araq | work required |
22:54:43 | vbtt | ok. |
22:54:55 | Araq | however since it comes up again and again |
22:54:56 | vbtt | just curious - why does the gc need patching? |
22:55:08 | Araq | I'm considering to change the priorities |
22:55:35 | Araq | the GC scans the stack conservatively but only the stack |
22:55:53 | Araq | the GC needs to know when you capture the stack and put it onto the heap |
22:56:22 | Araq | closure iterators don't capture the stack properly and so don't create this problem |
22:56:40 | vbtt | the coroutine reference will be on the main stack, i think (or linked from the main stack) |
22:57:08 | Araq | it doesn't matter |
22:58:48 | Araq | thinking about it ... we could also implement them with threads and a global lock |
22:58:49 | vbtt | ok, i wont worry about the details. just want to say that coroutines that are tied to a single shared thread and shared heap are all I want. |
22:59:25 | Araq | what? |
22:59:27 | vbtt | so all coroutines spawed from a thread run in the same thread - cooperative multitasking and doesn't need any locks on the shared heap either (if the code is written properly) |
23:00:07 | vbtt | when a coroutine calls coroutine.yeild() or sleep(), the thread switches to another coroutine that is ready. |
23:00:27 | vbtt | you *know* it wont switch between one yeild() can the next so you can do atomic operations without locks. |
23:00:48 | vbtt | imo, better than go style coroutines where n routines are mapped on n threads. |
23:00:53 | vbtt | also, probably easier to implement. |
23:00:54 | vbtt | :) |
23:01:27 | vbtt | basically I'm asking for what lua does. |
23:02:12 | Araq | last time I thought about it, I came to the conclusion that stack copying instead of stack pointer switching is preferable for my GC :-) |
23:02:25 | Araq | any opinion on that? |
23:02:40 | Araq | (omg it NEEDS to be O(1)!) |
23:02:51 | vbtt | not sure what you mean. when a coroutine yields the entire stack of the coroutine is copied!? |
23:03:00 | Araq | yeah |
23:03:15 | * | Araq__ joined #nimrod |
23:03:25 | vbtt | sorry that wont work for performance reasons. |
23:03:35 | discoloda | i like the wondering stacks idea from that 'await in c++' video |
23:03:41 | Araq | ha I knew you would say that |
23:03:53 | Araq | you're likely wrong but I didn't benchmark |
23:04:08 | * | Araq_ quit (Ping timeout: 252 seconds) |
23:04:10 | * | shevy left #nimrod ("I'll be back ... maybe") |
23:05:00 | vbtt | maybe i'm wrong. but yeah if the performance is affected the usability is limited. |
23:05:34 | Araq | performance *might* be affected but memory usage goes down but a lot |
23:05:49 | vbtt | in any case, I'd say coroutines getting more and more important for most server development. makes is much easier to write correct, clean code handling large numbers of sessions, with low overhead. |
23:05:55 | Araq | as it can compact the stack, so to speak |
23:06:06 | Araq | and so you can have billions of them |
23:06:28 | vbtt | Araq: I'm not sure why memory usage goes down? You need the stack space for each coroutine anyway. |
23:06:56 | Araq | vbtt: no you only need to store the stack difference |
23:07:26 | Araq | dom96: I don't understand your code, you start with a PSelector interface for no reason and it goes downhill from there |
23:07:43 | Araq | it's as if you want to select at runtime which implementation to use |
23:10:36 | Araq | vbtt: imho this "I need a full coroutines" argument is overblown, especially since nimrod's templates can mitigate the issue |
23:10:52 | dom96 | Araq: Yes. |
23:11:35 | vbtt | Araq: Not sure how templates are related. |
23:11:37 | Araq | dom96: why? can I select epoll on windows? |
23:12:32 | Araq | vbtt: nimrod's iterators may not capture the stack properly, but if you use templates instead of procs you can make "more of the stack" available to an iterator |
23:13:41 | Araq | vbtt: I'd like to play with this before concluding we need full coroutines |
23:13:43 | vbtt | Araq: oh, because it's inlined into the iterator itself? |
23:13:53 | Araq | yes |
23:14:32 | dom96 | Araq: No. |
23:14:43 | vbtt | So I can only use templates from iterators. Hmm, not sure that'll work for my use cases. |
23:15:00 | Araq | dom96: see my point? |
23:15:14 | vbtt | Only if I'm doing very little work in each coroutine - i can write my functions as templates. |
23:15:27 | Araq | vbtt: no, you can call procs in the iterator |
23:15:36 | vbtt | Araq:yes but they cant yeild. |
23:15:39 | Araq | but you can't call "yield" |
23:15:41 | Araq | yes |
23:15:47 | vbtt | yeilds can only happen at the top-level. |
23:15:52 | Araq | yes |
23:16:53 | vbtt | so if I call load_data() which calls get_http() which calls some http library that does async io - it can't yeild when it's waiting for the data.. unless then entire stack is written as templates. |
23:17:26 | vbtt | the utility is composability. even with functional libraries (if nimrod has them) |
23:17:39 | dom96 | Araq: You will be able to select IOCP on Windows. |
23:17:59 | dom96 | But I think you're right, why allow our users choice when we can just force them to use epoll. |
23:18:05 | vbtt | of course iterators work for small, isolated cases where i can write the entire code. but really i want an environment for writing async servers cleanly. |
23:18:42 | vbtt | wihout coroutines, people use callbacks for everything and the code is a huge mess (e.g. nodejs) |
23:18:45 | Araq | dom96: yes or rather support some --define perhaps instead |
23:19:08 | dom96 | Araq: You won't be able to extend it though. |
23:19:35 | Araq | dom96: oh no ... oh wait, yes you would |
23:20:09 | Araq | just add some crappy general event mechanism on top |
23:21:21 | Araq | vbtt: ok, I'm waiting for your patch then :P |
23:22:06 | * | darkf joined #nimrod |
23:22:38 | * | Demos joined #nimrod |
23:22:43 | vbtt | hehe ok. |
23:22:55 | dom96 | Araq: Perhaps we should spend time to come up with a full design for this async stuff. |
23:23:10 | dom96 | Araq: Since copying Python doesn't work. |
23:23:12 | vbtt | i'll poke around the code. |
23:24:08 | vbtt | have you looked at Python gevent? it works pretty well. but has to monkey patch the python stdlib because it wasn't written to support asyncio. |
23:24:17 | Araq | no idea why python even uses base classes and inheritance or interfaces |
23:24:24 | vbtt | gevent uses greenlets (true coroutines for python) |
23:24:26 | dom96 | I'm tired of wasting time. |
23:24:36 | Araq | makes no sense when you have dynamic typing |
23:24:47 | Araq | I never got that part of python |
23:24:58 | Araq | Lua doesn't do that bs |
23:25:59 | vbtt | yeah some python code is inheritance happy - sucks. |
23:26:24 | vbtt | but some places it's useful for implementation inheritance. |
23:27:20 | Araq | dom96: wrap epoll, wrap IOCP, and then think of how to extract what's common |
23:27:33 | Araq | just like osproc does it, for instance |
23:31:36 | * | brson joined #nimrod |
23:33:36 | vbtt | dom96: what are you implementing? |
23:34:24 | dom96 | vbtt: Something like Python's Tulip. |
23:37:43 | vbtt | hmm ok |
23:37:47 | vbtt | interesting. |
23:44:07 | discoloda | whats a common cause for `./koch boot` to fail when it gets to the gcc line |
23:44:22 | Demos | what error are you getting |
23:47:19 | discoloda | Error: execution of an external program failed |
23:47:35 | Demos | what is the output of gcc --version |
23:48:09 | discoloda | gcc (Ubuntu/Linaro 4.8.1-10ubuntu9) 4.8.1 |
23:48:49 | discoloda | it prints a gcc command line, showing a bunch of .o files that i cant find |
23:49:01 | Demos | OK try using --parallelBuild:false (I think) on nimrod's command line |
23:49:29 | Demos | WOWAH GUYZ msys2 uses pacman now |
23:49:36 | Demos | pacman... on windows! |
23:49:59 | discoloda | thats arch linux, right? |
23:50:15 | Demos | well normally yes.. but it is running on windows! |
23:51:31 | dom96 | --parallelBuild:1 |
23:51:48 | Araq | good night |
23:52:33 | Demos | thanks dom that is it |
23:56:37 | discoloda | that didnt work, koch expects .o files to be in compiler/nimcache/. i see them in csources/c_code/1_1/ |
23:59:25 | dom96 | Araq: oh btw, have you looked at that stack trace of the builder? |