| 00:08:59 | NimBot | Varriount/Nimrod-Sublime plugins/nimcheck 0b573a5 Clay Sweetser [+0 ±1 -0]: Allow user to choose an error to go to. Clean up code. |
| 00:11:04 | NimBot | Araq/Nimrod master 74aa666 Araq [+6 ±0 -0]: added test cases from strange loop event |
| 00:11:04 | NimBot | Araq/Nimrod master 64bd5e7 Araq [+0 ±1 -0]: bugfix: doc generation for actors.nim works again |
| 00:11:49 | Varriount | Man, it's just a flurry of activity today. |
| 00:12:29 | Varriount | OrionPK: Do you think that we should include a nimrod binary with the plugin? Or perhaps a link of some sort? |
| 00:13:16 | Araq | Varriount: and it just gets better, stay tuned |
| 00:14:30 | * | dom96 tunes out |
| 00:15:39 | * | Demos joined #nimrod |
| 00:16:27 | * | io2 quit () |
| 00:16:56 | OrionPK | varriount nah, instead if it doesnt find something maybe just launch a new tab w/ instrucions |
| 00:19:24 | Varriount | Bah. I just found out that a nice program I bought a couple of years ago is no longer available for download. |
| 00:19:37 | OrionPK | doh |
| 00:40:01 | * | dmac1 joined #nimrod |
| 00:41:01 | NimBot | Varriount/Nimrod-Sublime master 6e720c2 Varriount [+0 ±1 -0]: Updated license... 2 more lines |
| 00:44:17 | * | dmac1 quit (Ping timeout: 252 seconds) |
| 01:09:51 | Varriount | OrionPK: In the nimrod-sublime repo, in project.py, how much of the 'Utility' class is copied code? |
| 01:10:30 | NimBot | Araq/Nimrod devel af6b805 Araq [+0 ±18 -0]: case consistency improvements |
| 01:10:30 | NimBot | Araq/Nimrod devel 0eb7856 Araq [+0 ±1 -0]: new vm: bugfix |
| 01:10:30 | NimBot | Araq/Nimrod devel 82be2ed Araq [+0 ±1 -0]: bugfix: renderer supports 'ptr' etc. as type constraint |
| 01:10:30 | NimBot | Araq/Nimrod devel f2ea470 Araq [+0 ±2 -0]: fixes db_sqlite |
| 01:10:30 | NimBot | 2 more commits. |
| 01:11:25 | Araq | Varriount: check out our new testing framework, you'll love it :P |
| 01:11:35 | OrionPK | Varriount pretty much just Utility.get_project |
| 01:11:55 | * | dmac1 joined #nimrod |
| 01:12:05 | Varriount | OrionPK: It's kinda.. odd, to have a java-like static class pattern |
| 01:12:30 | OrionPK | static classes are my jam man, I'm not a python programmer :p |
| 01:13:10 | Varriount | OrionPK: You've been hitting the java too much. |
| 01:13:20 | OrionPK | I never touch java |
| 01:13:35 | Araq | zahary, zahary__ testament/tester has the new tester for now, check it out |
| 01:13:35 | OrionPK | in nimrod basically everything is static functions, unless you make methods :p |
| 01:14:35 | Varriount | Just as a future tip, in python, you typically just use module-level functions instead of having class/object methods decorated with the staticmethod decorator |
| 01:15:05 | Araq | good night |
| 01:15:05 | Varriount | Araq: Good night |
| 01:15:25 | OrionPK | im not bothered |
| 01:16:10 | dom96 | Araq: hehe, funny how you are always against putting things in too many directories and now all tests are categorised into directories :P |
| 01:16:30 | dom96 | Is 2014 the year when the stdlib gets categories too? :P |
| 01:29:55 | dom96 | Araq: Here is the stack trace I got with mark and sweep: https://gist.github.com/dom96/5b88232dea2d76e87d97 |
| 01:32:10 | Varriount | I wonder if there's a way you can tell gdb to trace a program's execution in its entirity, and work backward from the point where a program crashed, like a reverse step |
| 01:34:54 | dom96 | good night |
| 01:42:10 | OrionPK | Varriount when u gonna merge ur check plugin? |
| 01:42:46 | Varriount | OrionPK: When I add the command metadata to the other files |
| 01:44:07 | * | dmac1 quit (Quit: Leaving.) |
| 02:35:26 | * | brson quit (Quit: leaving) |
| 02:35:53 | * | brson joined #nimrod |
| 03:00:14 | * | dmac1 joined #nimrod |
| 03:05:21 | * | dmac1 quit (Ping timeout: 272 seconds) |
| 03:51:40 | * | brson quit (Quit: Lost terminal) |
| 03:52:14 | * | brson joined #nimrod |
| 04:00:51 | * | dmac1 joined #nimrod |
| 04:03:53 | * | brson quit (Ping timeout: 272 seconds) |
| 04:05:11 | * | dmac1 quit (Ping timeout: 260 seconds) |
| 04:32:28 | * | fowl quit (Quit: Leaving) |
| 04:36:53 | * | fowl joined #nimrod |
| 04:56:13 | * | Demos quit (Read error: Connection reset by peer) |
| 05:01:00 | * | dmac1 joined #nimrod |
| 05:05:32 | * | dmac1 quit (Ping timeout: 252 seconds) |
| 06:01:23 | * | dmac1 joined #nimrod |
| 06:06:02 | * | dmac1 quit (Ping timeout: 252 seconds) |
| 06:13:03 | * | BitPuffi1 quit (Ping timeout: 260 seconds) |
| 06:54:18 | * | dmac1 joined #nimrod |
| 07:01:19 | * | dmac1 quit (Quit: Leaving.) |
| 07:08:58 | * | fowl quit (Read error: Connection reset by peer) |
| 07:15:25 | * | fowl joined #nimrod |
| 07:16:58 | * | dmac1 joined #nimrod |
| 07:18:06 | * | dmac quit (Disconnected by services) |
| 07:18:09 | * | dmac1 is now known as dmac |
| 07:25:11 | * | dmac quit (Quit: Leaving.) |
| 07:30:35 | * | dmac joined #nimrod |
| 07:58:58 | * | bogomips joined #nimrod |
| 08:16:06 | * | dmac quit (Quit: Leaving.) |
| 08:26:06 | * | Araq_ joined #nimrod |
| 08:27:58 | * | odc joined #nimrod |
| 08:59:21 | * | achim joined #nimrod |
| 09:15:54 | * | girvo joined #nimrod |
| 09:16:20 | * | dmac joined #nimrod |
| 09:16:46 | girvo | hi everyone |
| 09:18:24 | odc | 'morning |
| 09:20:06 | girvo | I have been playing with c2nim lately, but I am certain that I'm thinking about it the wrong way :( |
| 09:21:07 | girvo | If theres a nice binary library (a .so in this case) with standard C headers (various .h files), the correct way to access said library would be to run `c2nim' on those `include/SomeLib.h' files, correct? |
| 09:21:33 | * | dmac quit (Ping timeout: 272 seconds) |
| 09:26:52 | girvo | brb |
| 09:30:50 | fowl | girvo, yes |
| 09:31:57 | * | girvo quit (Ping timeout: 272 seconds) |
| 09:36:16 | * | CarpNet joined #nimrod |
| 09:56:17 | zahary__ | I've made a Light Table plugin for nimrod, anyone want to give it a try? |
| 09:56:21 | zahary__ | https://github.com/zah/nimrod.lt |
| 10:06:11 | * | radsoc joined #nimrod |
| 10:16:46 | * | dmac joined #nimrod |
| 10:17:23 | Araq_ | zahary__: what's wrong with using ERecoverable error in vmgen and catching only that in sem.nim? |
| 10:18:32 | zahary__ | I guess nothing, but the vmgen is not using ERecoverable yet? |
| 10:19:09 | * | zahary__ left #nimrod (#nimrod) |
| 10:19:16 | Araq_ | yeah ... |
| 10:19:24 | * | zahary__ joined #nimrod |
| 10:21:20 | * | dmac quit (Ping timeout: 265 seconds) |
| 10:38:32 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 10:57:00 | * | achim quit (Quit: Textual IRC Client: http://www.textualapp.com/) |
| 11:16:59 | * | dmac joined #nimrod |
| 11:21:31 | * | dmac quit (Ping timeout: 260 seconds) |
| 11:44:01 | * | Araq_ joined #nimrod |
| 11:46:42 | Araq_ | hi bogomips welcome |
| 11:46:50 | bogomips | hello :) |
| 11:53:18 | * | BitPuffi1 joined #nimrod |
| 12:13:56 | * | BitPuffi1 is now known as BitPuffin |
| 12:17:18 | * | dmac joined #nimrod |
| 12:22:25 | * | dmac quit (Ping timeout: 272 seconds) |
| 12:41:45 | * | radsoc quit (Ping timeout: 252 seconds) |
| 12:47:03 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 13:04:06 | * | radsoc joined #nimrod |
| 13:17:38 | * | dmac joined #nimrod |
| 13:22:13 | * | dmac quit (Ping timeout: 248 seconds) |
| 13:22:51 | dom96 | zahary__: lots of errors when I created a new file, saved it as test.nim and started typing. |
| 13:23:08 | * | darkf quit (Quit: Leaving) |
| 13:23:58 | zahary__ | dom96, I assume you are talking about nimrod.lt? |
| 13:24:03 | dom96 | Discovering how to do things in light table is very difficult. |
| 13:24:07 | dom96 | zahary__: yes. |
| 13:24:08 | zahary__ | can you post a stack trace with an error? |
| 13:24:48 | dom96 | https://gist.github.com/dom96/45cdfe4ddf512f78af1a |
| 13:24:54 | zahary__ | I've tested in on a few computers so far, but they are all synced to my Dropbox folder so maybe there is something wrong with the installation |
| 13:26:14 | zahary__ | hmm, that's an error in the CodeMirror mode (lexer). can I have your source file - maybe it's genuine error |
| 13:27:12 | * | Araq_ joined #nimrod |
| 13:28:22 | dom96 | I literally just created a new file called test.nim and started typing |
| 13:31:21 | zahary__ | yes, but since that's a lexing problem, it matters what you typed :) |
| 13:31:53 | dom96 | I just hit random keys lol |
| 13:31:58 | zahary__ | :) |
| 13:32:08 | dom96 | Probably something like 'asdafagdgsdafdsdf' |
| 13:37:26 | zahary__ | doh, that was easy to fix, but now I'm too lazy to produce a new release |
| 13:37:38 | dom96 | lol |
| 13:38:52 | zahary__ | would you clone my repo in your plugins folder? I'll be able to push fixed more often |
| 13:39:16 | zahary__ | push fixes |
| 13:39:38 | dom96 | yeah, I did that. |
| 13:40:59 | dom96 | What can your plugin actually do? |
| 13:41:18 | dom96 | Does it support suggest and compilation/execution of .nim files? |
| 13:41:57 | zahary__ | ok, I pushed a fix |
| 13:42:38 | zahary__ | it supports just "def" right now. The next things on my list are suggest and eval |
| 13:48:50 | * | girvo joined #nimrod |
| 13:50:17 | girvo | hey all |
| 13:51:12 | dom96 | hi girvo |
| 13:51:18 | girvo | I noticed something interesting, when going through some of the wrapper libs, I saw that they came from Pascal libraries. I was wondering how that works? |
| 13:51:31 | dom96 | pas2nim :P |
| 13:51:45 | girvo | wait |
| 13:51:47 | girvo | seriously? lol |
| 13:51:53 | girvo | I didn't even know that was a thing |
| 13:52:16 | girvo | holy crap, awesome. |
| 13:53:05 | dom96 | Yes, the compiler was originally written in pascal. |
| 13:53:21 | dom96 | So instead of manually translating it to Nimrod Araq wrote pas2nim to do it quicker. |
| 13:53:41 | girvo | shit, cool. I suppose that explains the similar syntax (which I love) |
| 13:54:43 | girvo | What compatibility is better, pascal or C? |
| 13:55:03 | girvo | in terms of linking to a library that already exists, I'm just trying to get a nice API already heh |
| 13:55:12 | dom96 | Probably C. |
| 13:55:46 | girvo | Okay. I had a question before about it, but had to bail before getting an answer |
| 13:56:35 | girvo | Say I have a C library as a .so file, the way `c2nim' is supposed to work is by taking the `includes/MyLib.h' headers and converting those? I was trying to play with it today and got stumped |
| 13:56:46 | dom96 | yes |
| 13:57:16 | dom96 | http://build.nimrod-lang.org/docs/c2nim.html#dynlib-directive |
| 13:57:26 | Araq_ | girvo: pascal wrappers have the advantage of having stricter type information but unfortunately they often also contain new bugs, so I don't wrap those anymore |
| 13:57:45 | * | [1]Endy joined #nimrod |
| 13:57:46 | Araq_ | wrapping directly from C reduces the chance of an error |
| 13:58:00 | girvo | Araq_: alright, cheers |
| 13:58:04 | girvo | dom96: Sweet, thanks! |
| 13:58:05 | Araq_ | and yeah, c2nim works but you need to tweak the headers so that it likes them |
| 13:59:23 | Araq_ | girvo: check if the stuff hasn't been wrapped for you already; might already be a babel package :-) |
| 13:59:30 | girvo | Araq_: I tried to get it to deal with SDL2's latest headers, but it chokes on lots of it heh |
| 13:59:48 | Araq_ | sdl2 is a babel package afaik |
| 14:00:06 | girvo | Araq_: Yeah I did that, there are some handy wrappers in there but I struggled to get them to work D: I need more practice heh |
| 14:00:51 | girvo | Araq_: Fowltek has a wrapper, but its incomplete, apart from that no SDL2 wrappers I could find |
| 14:01:44 | * | [2]Endy joined #nimrod |
| 14:02:03 | Araq_ | well ask fowl then, he's here in irc |
| 14:02:15 | girvo | so, now for a really dumb question. The sfml wrapper examples compiled fine, but couldn't find the libcsfml.so files in my include, why would that be? |
| 14:02:24 | girvo | oh! lol, neat :) |
| 14:03:08 | girvo | fowl: In particles.nim for your sfml wrapper, it says classlib needs to be in path, but the gist underneat 404's, was wondering what it was? |
| 14:03:30 | * | dirkk0 joined #nimrod |
| 14:04:23 | * | [1]Endy quit (Ping timeout: 260 seconds) |
| 14:05:23 | * | aftersha_ joined #nimrod |
| 14:07:21 | Araq_ | well I guess you need to install libcsfml.so then? |
| 14:08:36 | girvo | Araq_: See, I had, heh. Thats why I got confused. No big deal, anyway |
| 14:10:16 | girvo | Araq_: With c2nim, I get this a lot on various header files: Error: ';' expected -- usually to do with things like `#if defined ALLEGRO_IPHONE' having no semicolon after it. Whats the typical way of repairing that? |
| 14:11:11 | fowl | girvo, c2nims pre processor doesnt seem to like "defined x" you have to put parens around it, i have started an allegro5 wrapper you could pick up |
| 14:11:34 | girvo | fowl: Ah cool, I ran into the same issue with "extern" calls in SDL2's header |
| 14:11:44 | girvo | fowl: I'll gladly have a play with it! |
| 14:11:56 | fowl | girvo, my sdl2 wrapper isnt incomplete, but sdl2_net and sdl2_mixer are |
| 14:12:39 | girvo | fowl: ok cool, I might take another look tonight then |
| 14:13:12 | fowl | girvo, that note about classlib is old, you need fowltek though, that can be installed through babel |
| 14:13:38 | girvo | fowl: yeah I pulled down fowltek through babel yesterday. pretty cool stuff |
| 14:14:42 | fowl | allegro5 so far: https://github.com/fowlmouth/allegro5 |
| 14:14:52 | girvo | fowl: Oh heck, I totally missed the main fowltek/sdl2.nim file. My bad :/ |
| 14:15:25 | fowl | as you can see allegro wrapper is barely started but its nicely sectioned at least :p |
| 14:16:28 | girvo | fowl: Hahaha :) I want to get used to c2nim and porting over C-libs, so I'll help work on allegro |
| 14:17:58 | * | dmac joined #nimrod |
| 14:23:01 | * | dmac quit (Ping timeout: 272 seconds) |
| 14:23:29 | * | [1]Endy joined #nimrod |
| 14:24:16 | * | [3]Endy joined #nimrod |
| 14:27:17 | * | [2]Endy quit (Ping timeout: 248 seconds) |
| 14:27:49 | * | [1]Endy quit (Ping timeout: 248 seconds) |
| 14:28:27 | * | radsoc quit (Ping timeout: 252 seconds) |
| 14:32:13 | * | zahary__ is now known as zahary_ |
| 14:41:30 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 14:45:36 | * | radsoc joined #nimrod |
| 14:48:32 | * | girvo quit (Quit: Leaving) |
| 15:00:07 | * | faassen joined #nimrod |
| 15:02:26 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 15:10:37 | * | aftersha_ joined #nimrod |
| 15:18:18 | * | dmac joined #nimrod |
| 15:22:45 | * | dmac quit (Ping timeout: 248 seconds) |
| 15:27:37 | * | achim joined #nimrod |
| 15:41:05 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 15:41:21 | * | BitPuffin joined #nimrod |
| 15:47:39 | dom96 | Seems the Nimrod talk will be late. |
| 15:48:15 | OrionPK | what on earth are they doing w/ it |
| 15:48:22 | OrionPK | was it filmed in front of a green screen? |
| 15:48:27 | dom96 | haha |
| 15:48:52 | dom96 | Comparing the dates on http://www.infoq.com/strange-loop-2013/ to https://thestrangeloop.com/news/strange-loop-2013-video-schedule it seems that they were all released late. |
| 15:50:01 | dom96 | In any case, just keep refreshing http://www.infoq.com/presentations/nimrod |
| 15:51:12 | dom96 | oooh |
| 15:51:14 | BitPuffin | I wonder if I can somehow use nimrod as the scripting language for my C++ engine |
| 15:51:19 | BitPuffin | that would be fun |
| 15:51:19 | dom96 | "Note that the date specifies the *week of release*, not a particular day." |
| 15:54:18 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 15:55:10 | BitPuffin | Araq: would the VM allow an applications to execute nimrod code as part of the same process through a library for example? |
| 16:13:04 | dom96 | BitPuffin: You know what the easiest to do that would be? To write it in Nimrod not C++ :P |
| 16:16:28 | BitPuffin | dom96: well shut up |
| 16:16:32 | BitPuffin | dom96: xD |
| 16:16:42 | BitPuffin | dom96: I have good reasons to write it in C++ |
| 16:16:48 | dom96 | *easiest way |
| 16:16:57 | dom96 | Oh? |
| 16:17:08 | BitPuffin | dom96: yes |
| 16:17:52 | dom96 | Tell me these reasons :P |
| 16:18:07 | EXetoC | industry support? |
| 16:18:38 | * | dmac joined #nimrod |
| 16:18:46 | BitPuffin | dom96: every time I talk to recruiters I feel like I have to proove that I know C++ |
| 16:18:55 | BitPuffin | is it prove or proove |
| 16:18:57 | BitPuffin | prove maybe |
| 16:18:59 | BitPuffin | no |
| 16:19:00 | dom96 | ahh |
| 16:19:01 | BitPuffin | proove |
| 16:19:04 | dom96 | it's prove |
| 16:19:08 | BitPuffin | läl |
| 16:19:32 | Varriount | 'prove' is one of those wierd english words. |
| 16:19:44 | Varriount | *weird |
| 16:19:45 | BitPuffin | you mean weird? |
| 16:19:46 | BitPuffin | ehehe |
| 16:19:48 | BitPuffin | xD |
| 16:19:49 | EXetoC | weird |
| 16:20:02 | BitPuffin | pff words |
| 16:20:04 | BitPuffin | who needs them |
| 16:20:26 | dom96 | BitPuffin: Why not just make a game using sfml or something in C++ as proof instead of creating a whole engine? |
| 16:20:36 | BitPuffin | dom96: because fuck sfml |
| 16:20:40 | Varriount | Languages are organic, and thus you often get the proverbial platypus cropping up among all the other animals in the grammatical ecosystem. |
| 16:20:47 | BitPuffin | dom96: anyways I'm not writing the physics engine by hand |
| 16:21:16 | BitPuffin | Varriount: "proverbial platypus"? Are you trying to show off :P |
| 16:22:37 | Varriount | BitPuffin: Me, show off? That would be as likely as a diamond covered ladybug eating gold aphids. |
| 16:23:14 | BitPuffin | lål |
| 16:23:22 | BitPuffin | EXetoC: start playing dota or be punched |
| 16:23:34 | dom96 | BitPuffin: You never play with me anymore. |
| 16:23:43 | * | dmac quit (Ping timeout: 272 seconds) |
| 16:23:47 | EXetoC | dom96: surprised that anyone would want to use some widespread language instead? :p |
| 16:23:53 | Varriount | dom96: I recently looked up sfml, and I kept thinking to myself "what's the catch"? |
| 16:24:09 | dom96 | EXetoC: Not surprised just disappointed. |
| 16:24:31 | BitPuffin | dom96: that sounded terribly wrong |
| 16:24:39 | EXetoC | yeah well :> |
| 16:24:43 | BitPuffin | dom96: yes I do we played like 2-3 days ago |
| 16:24:55 | BitPuffin | dom96: It's not like I love C++ all of a sudden |
| 16:24:59 | BitPuffin | so don't be disappoint |
| 16:25:16 | dom96 | BitPuffin: Our relationship is falling apart, you're not using Nimrod, we don't play as often as we used to anymore... what happened to us? </3 |
| 16:25:21 | BitPuffin | Varriount: I wonder "what's the fuzz about" |
| 16:25:24 | dom96 | lol |
| 16:25:28 | BitPuffin | dom96: ;_; |
| 16:25:58 | dom96 | Varriount: IMO it's a pretty good library |
| 16:26:26 | BitPuffin | dom96: and now you are saying sfml is pretty good |
| 16:26:34 | BitPuffin | dom96: it's all falling apart |
| 16:26:47 | dom96 | lol |
| 16:26:56 | dom96 | BitPuffin: I think we should see other people. |
| 16:27:04 | BitPuffin | dom96: so now you are cheating on me? |
| 16:27:08 | dom96 | BitPuffin: I truly hope we can remain great internet strangers. |
| 16:27:32 | dom96 | BitPuffin: I never said that! |
| 16:27:43 | BitPuffin | dom96: so now you wanna cheat on me? |
| 16:27:51 | BitPuffin | What happened when you said I was the only one.. |
| 16:28:02 | Varriount | dom96, BitPuffin: Obligatory xkcd comic -> http://xkcd.com/632/ |
| 16:28:04 | BitPuffin | sentence fail |
| 16:32:55 | dom96 | Argh. I dislike this period when I feel like I should be revising but I also want to program and then I feel guilty about not revising so I end up doing nothing. |
| 16:33:51 | bstrie | Araq: reading this concurrency post, "When holding a lock at level L one can only acquire new locks of levels < N." <-- is N supposed to be L there? |
| 16:38:25 | EXetoC | BitPuffin: got no time for games like I said |
| 16:38:43 | dom96 | EXetoC is wise. |
| 16:40:19 | BitPuffin | EXetoC: stahp |
| 16:40:24 | dom96 | OrionPK: Are you making an alternative to jester too? |
| 16:40:27 | BitPuffin | EXetoC: you do play games |
| 16:40:42 | BitPuffin | EXetoC: in fact when I was the wise one you FORCED me to play fo |
| 16:43:01 | BitPuffin | dom96: plus you ruined my tries to convince filwit that dota is great |
| 16:43:10 | dom96 | lol |
| 16:43:17 | EXetoC | that was some time ago. anyway, I might consider such games, because they don't require constant attention |
| 16:43:18 | dom96 | filwit is too cool for dota |
| 16:43:42 | BitPuffin | dota is too cool for everyone |
| 16:44:20 | OrionPK | dom96 im making something higher level than jester for blogging |
| 16:44:43 | dom96 | why not build on top of jester then? |
| 16:45:15 | OrionPK | because originally i wanted it to be on top of another http server like mongoose |
| 16:45:24 | OrionPK | and I still havent given up on that |
| 16:45:41 | BitPuffin | would be neat if you could plug jester to different servers |
| 16:45:55 | dom96 | you can |
| 16:47:16 | BitPuffin | dom96: I don't mean putting jester behind a web server |
| 16:47:28 | BitPuffin | I mean switching out the web server powering jester |
| 16:47:59 | EXetoC | as in using SCGI (http = false)? |
| 16:48:24 | BitPuffin | oh you can do that? |
| 16:48:38 | dom96 | of course |
| 16:48:45 | EXetoC | yes, but it doesn't work for me. I need to report that bug |
| 16:48:53 | dom96 | that is effectively putting jester behind a web server though |
| 16:49:46 | dom96 | I guess you want some sort of feedRequest callback or something. |
| 16:49:55 | BitPuffin | yaman |
| 16:50:25 | dom96 | httpserver will soon be good enough :P |
| 16:50:34 | dom96 | if only I didn't have exams right now... |
| 16:50:36 | dom96 | *sigh* |
| 16:50:49 | BitPuffin | you've been saying soon since I started using nimrod |
| 16:51:48 | dom96 | lol |
| 16:51:53 | dom96 | soon can mean many things |
| 16:52:01 | OrionPK | if I could handle a ton of concurrent requests w/ pure nimrod, that'd be nice ;0 |
| 16:52:17 | dom96 | You will be able to once I finish async |
| 16:52:23 | dom96 | new async that is |
| 16:53:46 | OrionPK | webframe is just a bit better than jester w/ my template stuff |
| 16:54:08 | EXetoC | soon < ∞ |
| 16:54:30 | OrionPK | also its going to handle pre-compilation of RST and master pages and stuff |
| 16:54:51 | OrionPK | so you'll be able to drop assets/articles etc into a folder and have them get processed and optimized |
| 16:55:59 | BitPuffin | EXetoC: soon = ∞ |
| 17:01:56 | Varriount | OrionPK: "Webframe"? |
| 17:02:54 | OrionPK | the platform I'm building to move my blog onto |
| 17:04:02 | Varriount | OrionPK: link? |
| 17:05:10 | OrionPK | it's not really ready for public consumption |
| 17:05:29 | OrionPK | Dom just found it by looking at my github |
| 17:05:50 | OrionPK | this is why I used my own svn server for familiar :-) |
| 17:06:22 | Varriount | Pfft, svn |
| 17:07:00 | * | dirkk0 quit (Quit: This computer has gone to sleep) |
| 17:07:15 | OrionPK | right now it's basically a clone of jester, functionality wise, but it lacks some things jester has and has some things jester does t |
| 17:07:17 | OrionPK | doesnt |
| 17:08:05 | BitPuffin | sounds like duplication of effort |
| 17:08:21 | reactormonk | what encoding does a string have in nimrod? |
| 17:09:39 | BitPuffin | reactormonk: utf-8 I believe |
| 17:09:40 | OrionPK | maybe, but my slogan is "webframe doesnt joke around" :P |
| 17:09:46 | BitPuffin | lol |
| 17:13:08 | EXetoC | reactormonk: it's just a sequence of bytes. see the unicode module |
| 17:16:40 | EXetoC | " |
| 17:19:08 | * | dmac joined #nimrod |
| 17:20:39 | EXetoC | "åäö".len -> 6, sequtils.toSeq(unicode.runes("åäö")) -> 3 |
| 17:21:42 | * | icebattle joined #nimrod |
| 17:22:17 | OrionPK | Varriount so does the folder/filesystem change detection stuff exist in the std lib? |
| 17:22:21 | BitPuffin | EXetoC: ie utf-8 |
| 17:23:45 | * | dmac quit (Ping timeout: 265 seconds) |
| 17:27:37 | EXetoC | the literal you mean? |
| 17:28:41 | BitPuffin | EXetoC: no I mean that's how utf-8 works |
| 17:29:02 | BitPuffin | for special characters such as ö it uses two characters in order to get enough bytes |
| 17:31:40 | EXetoC | yes but I was referring to this: "Per convention, all strings are UTF-8 strings, but this is not enforced. For example, when reading strings from binary files, they are merely a sequence of bytes" |
| 17:34:18 | BitPuffin | ah right |
| 17:34:44 | EXetoC | and he might be able to infer some things based on those results |
| 17:37:42 | BitPuffin | yea |
| 18:01:36 | * | DAddYE joined #nimrod |
| 18:09:44 | * | brson joined #nimrod |
| 18:12:21 | vbtt | anyone know when the strangeloop video will be available for general public? |
| 18:12:46 | Araq | bstrie: yes, it's a simple typo |
| 18:13:16 | * | dirkk0 joined #nimrod |
| 18:15:02 | * | dmac joined #nimrod |
| 18:15:09 | dom96 | vbtt: http://www.infoq.com/presentations/nimrod |
| 18:16:58 | * | dmac quit (Client Quit) |
| 18:18:49 | * | dmac joined #nimrod |
| 18:21:58 | vbtt | dom96:"This is a restricted presentation that can only be viewed by Strange Loop 2013 attendees! The public release of this presentation will be sometime in the next 6 months - date to be determined." |
| 18:22:10 | dom96 | Yeah, it's not release yet. |
| 18:22:12 | dom96 | *released |
| 18:22:44 | vbtt | yup, do you know when it will be? |
| 18:23:01 | dom96 | Sometime during this week according to https://thestrangeloop.com/news/strange-loop-2013-video-schedule |
| 18:23:07 | dom96 | Other than that I have no idea. |
| 18:23:44 | vbtt | nice! |
| 18:33:45 | * | radsoc quit (Ping timeout: 245 seconds) |
| 18:56:45 | Araq | hmmm ... how do I produce different tabs with javascript? |
| 19:07:07 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 19:09:31 | OrionPK | different tabs? |
| 19:09:36 | OrionPK | browser tabs? |
| 19:10:02 | Araq | no, within the same web page |
| 19:10:10 | Araq | all content statically generated |
| 19:10:33 | OrionPK | not sure what you mean then |
| 19:10:43 | Araq | http://www.elated.com/articles/javascript-tabs/ |
| 19:10:54 | Araq | this seems to do what I want but looks rather complex |
| 19:10:54 | OrionPK | oh |
| 19:11:03 | OrionPK | the basic principal is easy |
| 19:11:10 | Araq | I'm not even sure I need JS for that |
| 19:11:11 | OrionPK | just hide/show tab content elements tied to links |
| 19:11:28 | OrionPK | you need JS to change the CSS class/style of elements probably |
| 19:11:39 | OrionPK | when you click an associated tab |
| 19:11:59 | Araq | I think I've seen that done with pure CSS |
| 19:12:38 | OrionPK | there's no ":click" option in CSS.. maybe you could do it with :focus or :active, but it'd be dodgy probably |
| 19:16:20 | EXetoC | click + anchor? |
| 19:16:46 | * | brson quit (Quit: leaving) |
| 19:16:49 | Araq | meh I'll just copy&paste |
| 19:17:03 | * | brson joined #nimrod |
| 19:17:16 | Araq | and it won't work because I already have some css and the C part of it is broken by design |
| 19:18:07 | EXetoC | the purpose is to reduce repetition? you can't use a template engine? |
| 19:19:00 | EXetoC | I don't know what other reasons there are, apart from reducing the amount of GET's |
| 19:22:57 | discoloda | C type parsing is a pita |
| 19:24:57 | vbtt | how much of the nimrod compiler is written in nimrod vs. c? |
| 19:25:58 | Araq | well I'm talking of the "cascading feature" |
| 19:26:13 | discoloda | i think its all nimrod, but im just trying to improve c2nim |
| 19:26:41 | Araq | vbtt: nimbase.h is the only hand-written C in the whole distribution |
| 19:26:47 | vbtt | cool |
| 19:27:33 | * | achim quit (Quit: Computer has gone to sleep.) |
| 19:31:20 | vbtt | how can i dump the generated C code? |
| 19:31:56 | Araq | just look at the nimcache directory, it's kept |
| 19:32:50 | Araq | use --embedsrc |
| 19:33:05 | Araq | then the compiler produces the nimrod code in comments in the C code |
| 19:33:15 | vbtt | Araq: thx |
| 19:35:50 | Araq | discoloda: indeed C type parsing makes you mad |
| 19:46:20 | * | pe7ed27 joined #nimrod |
| 19:47:30 | zahary | Araq, I appreciate the new test persistence backend |
| 19:48:10 | zahary | do you just explore it with some sqlite viewer or you have some script that you haven't commited? (e.g. to see a diff with the previous commit) |
| 19:48:19 | Araq | I'm writing a html generator :-) |
| 19:48:25 | Araq | will upload it tonight |
| 19:48:30 | zahary | ok |
| 19:48:39 | Araq | already works, but I want to have "tabs" |
| 19:48:43 | Araq | one tab per commit |
| 19:48:44 | zahary | :) |
| 19:49:42 | * | [Pete_27] quit (Ping timeout: 276 seconds) |
| 19:49:50 | Araq | I hope this makes development much faster |
| 19:49:57 | Araq | but we'll see |
| 19:50:31 | zahary | didn't tablizer preach that directories can't organize anything :P |
| 19:50:31 | Araq | in case you didn't notice, the "spec" part of the test directly indiciates what to do with the test |
| 19:50:56 | Araq | no need for any explicit reject/compile/run distinction |
| 19:51:28 | * | gradha joined #nimrod |
| 19:51:29 | Araq | yeah yeah yeah, tablizer is old stuff though and the file system still is no database |
| 19:52:07 | zahary | hmm, my git client doesn't show any diffs for the tests. what's new in the specs? |
| 19:52:32 | Araq | and to my defense ... we kepts adding tests beyond its breaking point, there was no conscious design decision involved really |
| 19:52:58 | Araq | there is nothing new in the specs |
| 19:53:17 | Araq | I noticed the reject/compile/run distinction is not necessary on the directory level |
| 19:53:25 | zahary | the tests directory certainly looks more impressive the current way :) |
| 19:53:26 | Araq | as the spec already has that information implicitly |
| 19:54:48 | Araq | yeah ... I plan to go through each category individually |
| 19:55:02 | Araq | but I just noticed we have almost 100 categories ... huh |
| 19:56:04 | zahary | should we use symlinks to turn the directories into tags? |
| 19:56:11 | zahary | windows users might suffer |
| 19:56:41 | Araq | bah, I still dislike symlinks :P |
| 19:56:54 | Araq | I wanted to tag tests in the spec section |
| 19:58:25 | Araq | oh ... I wanted to ask you: what's the relation of "unique" and "destructor"? |
| 19:58:42 | zahary | unique as in pointers? |
| 19:58:50 | Araq | yes |
| 19:59:05 | Araq | seems useful to conflate both concepts |
| 19:59:20 | Araq | but I'm not sure about all the consequences |
| 19:59:48 | zahary | they seem pretty orthogonal to me. naturally, you run the destructor when the unique pointer goes out of scope (considering it hasn't been trasnfered to another proc) |
| 20:02:33 | Araq | why orthogonal? you can't really invoke the destructor when the pointer escapes |
| 20:02:58 | Araq | and escaping is tracked with the uniqueness mechanism, sort of |
| 20:04:45 | Araq | hey gradha I reviewed your docgen changes, they look fine to me |
| 20:07:17 | dom96 | If the talk were to be released now we may just beat our current user record here. |
| 20:07:41 | gradha | Araq: do you want them in master, devel, or both? |
| 20:08:14 | zahary | I see what you mean, but destructors are about the clean up code (manually or automatically written); uniqueness on the other hand is life-time characteristic of the object; |
| 20:09:37 | zahary | one way to approach unique pointers for example is to limit their use to stack locations (this allows perfect tracking without any runtime checks); in such a world, it woudn't make sense to not allow destructable fields in heap objects |
| 20:09:38 | * | BitPuffin joined #nimrod |
| 20:10:25 | Araq | gradha: devel though I can't see it breaks anything |
| 20:10:51 | zahary | I was about to say that you also care whether an object will have stack or heap location, but the compiler can indeed determine that with escape analysis for uniques |
| 20:12:05 | gradha | Araq: all new changes into devel from now on? |
| 20:12:41 | Araq | gradha: yes |
| 20:16:30 | Araq | in fact, I consider the whole proc f(p: ptr T) idea wrong, zahary |
| 20:16:48 | zahary | what? |
| 20:17:15 | Araq | it should be explicit whether "p" is stored somewhere or not ... |
| 20:17:29 | zahary | the idea of raw pointers? |
| 20:17:36 | Araq | yeah |
| 20:17:49 | Araq | proc f(s: cstring) |
| 20:17:53 | Araq | f "valid?" |
| 20:18:10 | Araq | it almost always is unless 'f' stores the cstring somewhere |
| 20:18:33 | Araq | well let me elaborate |
| 20:18:55 | Araq | whether the conversion string->cstring is valid depends on what "f" does with the cstring |
| 20:19:30 | Araq | so it would be nice if "f" could tell us that fact |
| 20:20:38 | Araq | and the write tracking does not help either: proc f(s: cstring) {writes: someGlobal.} |
| 20:20:51 | Araq | # still insufficient information about "s" |
| 20:21:00 | zahary | I was thinking the other night when you asked about lent. besides my argument that regular value accepting procs are "lent", because they don't usually use addr, it occurred to me that "lent" is computable from the definition anyway |
| 20:21:05 | zahary | so I could say the same here |
| 20:23:20 | Araq | yeah, looks pretty easy to compute whether the pointer is lent or not |
| 20:23:30 | zahary | you could track it on a param level; in the body of this proc "s" is not passed to any ... |
| 20:23:59 | Araq | yeah it's quite close to what we do for the write tracking |
| 20:24:27 | Araq | I think I can enhance the algorithm to compute that additionally |
| 20:33:52 | OrionPK | is there a way I can do a template where the input value can either be a raw set of values or a string.. e.g. treat query("something") the same as query(something), where if the input is not a string astToStr is called |
| 20:35:28 | Varriount | zahary: What did you mean, windows users might suffer if there were symlinks? |
| 20:35:53 | * | achim joined #nimrod |
| 20:36:34 | zahary | well, what does git do whet it sees a symlink? mklink requires admin account IIRC |
| 20:37:03 | fowl | OrionPK, yes use a language with dynamic typing |
| 20:37:06 | zahary | *when it sees* |
| 20:37:14 | Varriount | zahary: Ah, true. |
| 20:37:22 | OrionPK | in nimrod :P |
| 20:37:24 | Araq | OrionPK: seems easy to do |
| 20:37:27 | gradha | OrionPK: I think you can make a macro for the type checking, and call the macro inside your template on the parameter to get always the string |
| 20:37:38 | Araq | you can also use overloading |
| 20:37:47 | OrionPK | i think it needs to be immediate |
| 20:38:10 | Araq | template foo(x: expr{string}): expr = x |
| 20:38:22 | Araq | template foo(x: expr): expr = astToStr(x) |
| 20:38:31 | Araq | er, you need |
| 20:38:42 | Araq | template foo(x: string): expr = x |
| 20:40:58 | Araq | Varriount: I don't want symlinks even if they work on windows |
| 20:41:38 | * | DAddYE quit (Remote host closed the connection) |
| 20:44:21 | * | [3]Endy quit (Ping timeout: 248 seconds) |
| 20:44:55 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 20:47:43 | * | achim quit (Quit: Computer has gone to sleep.) |
| 21:00:53 | vbtt | stupid q: why cant I define object types with object[name: string, age: int] |
| 21:02:18 | dom96 | You might as well just make it a tuple then. |
| 21:02:30 | gradha | vbtt: object variants would be quite difficult to read with that syntax |
| 21:02:47 | zahary | well, he is asking to support both just like tuples |
| 21:03:49 | dom96 | I guess there is no harm in allowing that. |
| 21:06:44 | * | viteqqq joined #nimrod |
| 21:07:10 | OrionPK | araq Error: illformed AST: string |
| 21:07:13 | vbtt | right, just starting out and saw the tuple syntax, very easy. then assumed the object syntax also allows that same shorthand but didn't work :( |
| 21:08:10 | Araq | OrionPK: :-/ |
| 21:08:42 | Araq | vbtt: you can't have anonymous object types though |
| 21:08:50 | OrionPK | ive never had much luck w/ parameter contraints |
| 21:09:29 | Araq | so I don't think [] for objects buys you anything |
| 21:10:04 | Araq | OrionPK: no, I corrected that version |
| 21:10:21 | Araq | expr{string} is not valid indeed, expr{lit} would be |
| 21:10:36 | Araq | but you want simply "string" here |
| 21:10:39 | OrionPK | yeah |
| 21:10:48 | OrionPK | needs to be immediate though i think |
| 21:11:03 | Araq | yeah |
| 21:11:14 | vbtt | Araq: i see. it just allows one-line-definitions. |
| 21:11:43 | vbtt | not a big deal, but i just expected it to work based on the principle of consistency. |
| 21:12:53 | Araq | that principle is at odds with the principle of organic growth |
| 21:14:13 | vbtt | yeah i suppose. |
| 21:14:51 | OrionPK | araq hmm this works with query() as a template |
| 21:15:01 | OrionPK | but not as an operator i.e. `?` |
| 21:15:24 | Araq | that's quite impossible |
| 21:15:43 | OrionPK | mmk |
| 21:15:50 | vbtt | object variants look awesome, btw. |
| 21:16:50 | Araq | usually people are furious they don't work like in ML, vbtt ... |
| 21:18:10 | vbtt | meh, it fits my python/c mind. concise syntax for a common pattern which is easy to understand. |
| 21:18:39 | vbtt | i'm not sure how ml is different (i have only superficial knowledge of ocaml) |
| 21:19:03 | vbtt | are invalid fields caught at compile time or run time? |
| 21:19:29 | Araq | run time but the compiler can warn about it too |
| 21:19:42 | Araq | forgot how I named that switch though |
| 21:20:25 | vbtt | shouldn't it always be a compile time error? |
| 21:20:37 | vbtt | it's most certainly a bug, no? |
| 21:20:44 | Araq | well that's exactly what people complain about :P |
| 21:21:19 | Araq | but checking it at runtime allows for lots of idioms which are otherwise nearly impossible |
| 21:21:40 | vbtt | Ah I see. |
| 21:21:51 | Araq | for i in 0 .. safeLen(n): echo n.kids[i] |
| 21:22:10 | vbtt | well runtime error is better than nothing. |
| 21:22:17 | Araq | for i in 0 .. <safeLen(n): echo n.kids[i] |
| 21:22:33 | Araq | --> safeLen returns 0 if n.kids must not be accessed |
| 21:22:46 | Araq | easy to do in nimrod, impossible in ML |
| 21:23:48 | vbtt | surely safelen() checks that n.kind == WithKids? |
| 21:24:02 | Araq | yes |
| 21:24:18 | Araq | and with proper post conditions for "safeLen" you can do it statically |
| 21:24:22 | Araq | but we're not there yet |
| 21:24:25 | vbtt | ah cool. |
| 21:24:52 | Araq | hence a warning "cannot prove field access correct" |
| 21:24:59 | vbtt | i was gonna say the complier could even infer the post conditions. |
| 21:25:29 | vbtt | that warming is pretty good - is there a way to 'tag' the line of code to silence the warning? |
| 21:25:45 | * | io2 joined #nimrod |
| 21:25:51 | Araq | {.push warning[FieldAccess]: off.} |
| 21:26:05 | vbtt | nice |
| 21:26:26 | Araq | but you can only surround the whole proc with that .push and .pop |
| 21:27:09 | vbtt | oh, I can't do {.with .. .}? i have to write both push and pop? |
| 21:27:32 | Araq | yeah |
| 21:27:58 | Araq | but hey, "with" is already a keyword ;-) |
| 21:28:50 | vbtt | oh well. |
| 21:29:45 | Araq | zahary: I think you missed my remark about how we can support fork&join with a thread local GC'ed heap |
| 21:30:08 | * | DAddYE joined #nimrod |
| 21:30:19 | * | DAddYE quit (Remote host closed the connection) |
| 21:30:25 | * | DAddYE_ joined #nimrod |
| 21:30:42 | zahary | I missed it indeed |
| 21:31:05 | Araq | it's quite easy to do: the parent thread stops its GC and passes its allocator to the children which then can do new(allocator, x); |
| 21:31:42 | Araq | where the "new(allocator)" uses a lock, the version without the allocator doesn't use a lock |
| 21:32:15 | Araq | hence the parent needs to disable the GC for the duration of the fork&join |
| 21:32:24 | zahary | you mean the user cooperates by writing his proc differently? |
| 21:32:45 | Araq | and must join() for the child threads |
| 21:32:46 | zahary | or the compiler generates alternative procs for used inside the parallel blocks |
| 21:33:18 | * | DAddYE_ quit (Client Quit) |
| 21:33:19 | Araq | I'm only talking about the runtime, not about any interface or type system additions |
| 21:33:19 | vbtt | parent also needs to disable all new allocations, no? |
| 21:33:31 | Araq | vbtt: yes, it needs to join() |
| 21:33:51 | * | radsoc joined #nimrod |
| 21:34:09 | Araq | afterwards it can continue to run with no locking on "new" |
| 21:34:11 | vbtt | so parent cant do anything else between fork and join. |
| 21:34:20 | Araq | yup |
| 21:34:47 | Araq | but that's not a problem, just use enough child threads to keep the cores busy |
| 21:35:07 | Araq | the problem is how to design the type system to support it safely |
| 21:35:23 | vbtt | ok, sounds like a pattern for parallelism. |
| 21:35:30 | zahary | well, ok, but that's one big issue to figure out. the problem I was going to cite is that the user would find it hard to cooperate, because of the likeliness of calling code not written with parallel tasks in mind |
| 21:36:05 | zahary | and generating alternative bodies will lead to some code bloat |
| 21:36:21 | * | odc quit (Ping timeout: 251 seconds) |
| 21:37:01 | Araq | ha, says the guy who introduced implicit generics :P |
| 21:37:32 | Araq | but yeah, I'm not thinking about generating alternative bodies |
| 21:37:44 | zahary | :) hey, I'm still advocating the bloated handling of maybeAsgnRef |
| 21:39:04 | Araq | however the pattern is quite important and as I said, easily supported with what we already have |
| 21:39:44 | Araq | one idea is that "ref" et. a. becomes "foreign ref" when passed to a thread |
| 21:40:01 | Araq | and new(allocator) returns a "foreign ref" |
| 21:40:55 | Araq | but this is not sound; we need to introduce proper regions then |
| 21:41:05 | zahary | a TLS run-time solution to detect the mode wouldn't probably be that bad |
| 21:41:36 | vbtt | fwiw, I think most parallelism cases can be implemented by building on top iterators. |
| 21:41:41 | vbtt | *top of iterators. |
| 21:41:50 | Araq | oh yeah that was one idea, new without the allocator can check in debug mode the collector hasn't been put into "parallel mode" |
| 21:41:57 | radsoc | /msg Varriount Hi Varriount (sorry for this private message but I don't want to interrupt Araq) I just tried your plugin. Nice. But it made me upgrade to ST3: I couldn't build after installing your package on ST2 (on windows): weird, no? The syntax highlighting is better indeed ("_" support!) but I have a question: why some types are highlighted as keywords (int, string, seq...) and not other one (such as pointer)? |
| 21:42:34 | zahary | what is your stackless GC btw? |
| 21:42:52 | Araq | the pure refcounting gc |
| 21:43:15 | gradha | radsoc: your secret is safe with us |
| 21:43:32 | radsoc | lol |
| 21:43:41 | zahary | based on the advanced papers? |
| 21:43:58 | Araq | no stack tracing and so every library which does nasty stuff such as running your callback on the background thread works |
| 21:45:12 | vbtt | it's awesome that i can use type like this: proc f(x): type(x) = return x |
| 21:46:23 | zahary | so, non-deferred, but does it try to reduce the refcount updates? |
| 21:46:49 | Araq | zahary: I studied the paper in detail and came to the conclusion I can implement something better instead. I'm a bragger, I know, but the paper misses lots of common idioms |
| 21:48:05 | Araq | but that was already months ago and unfortunately I don't remember the details |
| 21:48:29 | zahary | alright, but still, you'll be aiming for an advanced algorithm to reduce the refcounts? |
| 21:49:10 | vbtt | fwiw, shared allocator doesn't sound that nice. high allocation rate will produce high contention. |
| 21:49:20 | vbtt | =very low scaling factor |
| 21:49:47 | Araq | vbtt: you can do lockfree allocation or lock stripes |
| 21:49:59 | vbtt | could you have thread-local allocators that just merge with the parent memory at join()? |
| 21:50:13 | Araq | hmm, nice |
| 21:50:23 | Araq | that works :-) |
| 21:50:48 | vbtt | typically each parallel routine will do it's work and then return a ref to an object |
| 21:51:06 | Araq | zahary: I don't even know when I get to implement the pure rc gc ... |
| 21:51:10 | vbtt | if each routine is modifying shared data in the parent, it's gonna suck anyway. |
| 21:52:43 | Araq | vbtt: we need "shared ref" at the type system level so that "shared ref <- ref" produces an atomic update somehow |
| 21:53:22 | Araq | or maybe enforces some locking like my "guarded ptr" idea |
| 21:53:35 | vbtt | Araq:I'm not sure what specific use case you're going for. |
| 21:54:06 | EXetoC | radsoc: always use non-channel windows, or use /query <nick> :> |
| 21:54:07 | vbtt | Araq:have you looked at persistent data structures like the ones clojure uses? |
| 21:54:41 | vbtt | what does 'shared ref' mean? it's an object shared across threads? |
| 21:55:06 | Araq | persistent data structures only help by being immutable and so you can read them without any locks |
| 21:55:25 | Araq | they don't at all help with parallel memory allocations |
| 21:55:31 | vbtt | right |
| 21:55:42 | vbtt | actually no |
| 21:55:59 | Araq | clojure simply uses jvm's advanced shared heap GC and calls it a day |
| 21:56:14 | Araq | I can't see what to learn from that, sorry |
| 21:57:11 | Araq | vbtt: ok ok |
| 21:57:17 | vbtt | it just uses persistent data structures to provide concurrency that's all. |
| 21:57:20 | vbtt | anyway, i may be off topic. |
| 21:57:47 | Araq | actually immutability greatly helps the GC, albeit indirectly |
| 21:58:08 | Araq | because it's a perfect fit for the 3 color invariant |
| 21:58:12 | vbtt | i'm not really sure what you're trying to solve here. there are many use cases for wanting multiple threads - 1) threads operating on different parts of a shared data (e.g array) 2) threads generatign new objects and returning which combines into one structure... |
| 21:58:40 | gradha | the docgen changes don't work on devel because renderer depends on types and types dependes on renderer |
| 21:59:02 | vbtt | 3) concurrency (i.e. threads are mostly working on isolated data with very mostly read-only shared state and very few updates to shared state. |
| 21:59:39 | Araq | well IME "multiple threads are building a shared hash table" is a key example, it comes up again and again |
| 22:00:02 | Araq | or take simply filling an array in parallel |
| 22:00:10 | Araq | easy when it's an array of ints |
| 22:00:20 | Araq | currently impossible when it's an array of strings |
| 22:00:30 | Araq | that's what I'm after |
| 22:01:38 | Araq | gradha: check the deps on master and fix devel accordingly if possible |
| 22:01:53 | gradha | zahary: you made types import render for tyFromExpr, how can I avoid the circular dependency? I want types.typeToString |
| 22:03:23 | Araq | vbtt: what "shared ref" means it exactly the question we don't know the answer. could mean "foreign ref", could mean "allocated on a shared GCed heap" |
| 22:05:51 | zahary | gradha, usually dependency cycles are broken by introducing a proc pointer |
| 22:06:17 | zahary | the depended upon module gets its dependency set from outside |
| 22:06:38 | vbtt | Araq: in your examples, contention on the shared data structure is going to kill the performance anyway. To avoid that the workers should mostly run free of contention and at times return large chunks of generated data to the parent. |
| 22:06:49 | vbtt | it's trivial with messaging but involves copy overhead. |
| 22:07:56 | vbtt | here's another suggestion. solve this with specially marked data structures that implement two interfaces - one for the parent and one for each worker. when you pass such a data structure to a spawned routine, it can only use the worker interface. |
| 22:08:29 | vbtt | hmm, you still need a way to allocate in the parent's memory space. |
| 22:09:12 | Araq | yeah |
| 22:09:19 | vbtt | so I think you may need another version of the alloc() function, that can allocate in another 'heap'. |
| 22:09:23 | Araq | also I think you are slightly misunderstanding my idea |
| 22:09:26 | vbtt | ok |
| 22:09:51 | Araq | "new()" for the child thread still exists and allocates on this child's heap |
| 22:10:02 | Araq | "new(allocator)" allocates on the parent's heap |
| 22:10:32 | Araq | depending on what you do in "child", lots of stuff still is not contented |
| 22:10:59 | gradha | zahary: the changes I added to renderer.nim don't really depend on that module, but don't seem to fit into types, maybe I should add a typesrenderer.nim? |
| 22:11:33 | Araq | gradha: yeah sounds good |
| 22:12:25 | vbtt | Araq:in practice, if multiple cpus are writing to the same memory pages, theres going to a lot of low level shutting around of data - even if you dont have explicit locking. |
| 22:12:52 | Araq | really? "same pages"? IME it's only about same cache lines |
| 22:14:18 | * | viteqqq quit (Ping timeout: 252 seconds) |
| 22:15:38 | vbtt | depends on the cpus i guess. if they're multiple caches mapped to the same data.. |
| 22:16:46 | vbtt | each core has it's own L1 and L2 cache, no? |
| 22:17:01 | Araq | yes |
| 22:17:07 | vbtt | and local caches will grow over time, IMO |
| 22:17:33 | Araq | well I was ambiguous |
| 22:18:01 | Araq | what I mean is that you need to align non-shared data on cache lines to avoid false sharing |
| 22:18:07 | vbtt | all I'm suggesting is designing systems that mostly operate on exclusive data with fewer 'sync points' is probably a good idea. |
| 22:18:43 | Araq | vbtt: we agree on this point. also avoiding copies is not all that important afaict |
| 22:19:03 | vbtt | so from a high level - generating strings into a shared list - each core generates a list of strings, once each list is a sufficient size (or after a certain time) the list is swapped over to the parent and merged (without copying..) |
| 22:19:40 | vbtt | Araq:if avoiding copying is not all that important then just implement message based copying (using the iterator protocol) and be done with it :) |
| 22:20:18 | Araq | well that's what channels currently do |
| 22:20:34 | Araq | but passing a tree over a channel causes a copy of the whole tree |
| 22:20:55 | Araq | and then it needs to be copied again into the thread local heap via "recv" |
| 22:21:23 | Araq | not even Erlang does it this way, I think |
| 22:21:57 | vbtt | Erlang copies every message, unless you use the 'external' binary objects. |
| 22:22:14 | vbtt | why do you need two copies? |
| 22:22:38 | discoloda | i think Erlang's message queues are multiple writer, single reader |
| 22:24:38 | Araq | vbtt: 'send' requires a copy and so does 'recv' |
| 22:25:17 | Araq | it's possible to use only 1 copy but this doesn't want when you want to implement work stealing |
| 22:25:24 | Araq | *doesn't work |
| 22:28:00 | vbtt | yeah erlang doesn't have channels, you send messages to processes directly. |
| 22:28:25 | vbtt | or maybe it has channels but the standard messaging is sent to a pid not a channel. |
| 22:29:10 | * | radsoc quit (Ping timeout: 245 seconds) |
| 22:29:24 | discoloda | means any process can allocate memory on behalf of another process when a message is sent |
| 22:29:50 | vbtt | Araq: your use cases (generated hash table or list) doesn't require work stealing. |
| 22:30:04 | Araq | that doesn't change anything, vbtt |
| 22:30:19 | Araq | so send to a process, not to a channel |
| 22:30:45 | Araq | can you construct the message in the process's heap while the process is running? no you can't |
| 22:31:14 | Araq | so you copy into a locked section of memory, its inbox |
| 22:31:32 | Araq | and then the process can read from that, requiring the second copy |
| 22:31:48 | vbtt | why not? you allocate a largish arena for local use and allocate within that, once the arena is full, you pass control back to the parent. i think you suggested something similar already. |
| 22:31:48 | Araq | you can avoid 1 copy by introducing a rendevous |
| 22:32:16 | Araq | I can't see that work for erlang |
| 22:32:22 | Araq | but anyway |
| 22:32:36 | Araq | the rendevous stuff is exactly what I'm planning to implement |
| 22:33:04 | reactormonk | Does a string have an encoding? Or just undefined? |
| 22:33:14 | reactormonk | Aka "a list of bytes" |
| 22:33:35 | Araq | reactormonk: depends on how you use it, use the taint mode and check the encoding of your inputs |
| 22:34:02 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/779 |
| 22:34:26 | NimBot | Araq/Nimrod master de30ba7 Satish BD [+0 ±1 -0]: Define $ operator for TRune |
| 22:34:26 | NimBot | Araq/Nimrod master 1988330 Satish BD [+0 ±1 -0]: Define $ operator for TRune |
| 22:34:26 | NimBot | Araq/Nimrod master 1ef50ee Andreas Rumpf [+0 ±1 -0]: Merge pull request #779 from brihat/master... 2 more lines |
| 22:34:56 | vbtt | Araq: ok then! |
| 22:36:01 | vbtt | Araq: another suggesting that might simplify the semantics of the language while allowing the shared memory allocation: require use of iterators to generate data in the worker routines. |
| 22:36:07 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/777 on a different topic |
| 22:36:30 | vbtt | the good thing about iterators is the semantics are like adding to a list - you're always growing the result list. |
| 22:37:05 | vbtt | so - internally the worker adds items to a buffer arena and when it's full, it's swapped back to the parent with no copying. |
| 22:37:17 | Araq | vbtt: I need to think about that one |
| 22:37:43 | Araq | reactormonk: the convention is clearly haystack needle btw |
| 22:37:48 | vbtt | also - instead of defining any shared ref, I just have write a regular iterator, when it's invoked from spawn() it's automatically uses a different allocator. |
| 22:38:54 | vbtt | why have the user worry about 'shared ref or ref'? |
| 22:39:41 | NimBot | Araq/Nimrod master 3fcbbb8 Billingsly Wetherfordshire [+0 ±1 -0]: Update os.nim... 2 more lines |
| 22:39:41 | NimBot | Araq/Nimrod master d15ab4c Andreas Rumpf [+0 ±1 -0]: Merge pull request #777 from fowlmouth/patch-4... 2 more lines |
| 22:40:20 | Araq | vbtt: shared memory surely is convenient too |
| 22:40:34 | OrionPK | someone should put csources/ in gitignore for the main repo |
| 22:40:41 | reactormonk | Araq, so fileExists? |
| 22:41:53 | OrionPK | why not a template for those? |
| 22:42:39 | Araq | OrionPK: the manual says don't use a template when a proc suffices |
| 22:42:48 | Araq | I know nobody cares :P |
| 22:42:55 | OrionPK | lol |
| 22:43:05 | OrionPK | whats the reasoning for the manual saying that? |
| 22:43:18 | Araq | princimple of least power or whatever it's called |
| 22:43:21 | OrionPK | dont use a proc when a template suffices :p |
| 22:43:28 | Araq | *principle |
| 22:43:42 | NimBot | Varriount/Nimrod-Sublime plugins/nimcheck eadd0c1 Clay Sweetser [+1 ±1 -1]: Rename nimchecker.py to NimCheck.py... 3 more lines |
| 22:44:19 | Araq | OrionPK: http://en.wikipedia.org/wiki/Rule_of_least_power |
| 22:44:58 | vbtt | Araq: perhaps flesh out the use cases a bit? I'm not sure what trade offs you're going for. IME most shared memory uses can be solved by picking the right data structure - e.g. shared read heavy with occasional writes? use persistent ds. shared write heavy with single worker read? use queue (or the iterator approach i described). etc. |
| 22:48:41 | * | dirkk0 quit (Quit: This computer has gone to sleep) |
| 22:48:55 | Araq | reactormonk: delphi uses fileExists so it can't be bad |
| 22:49:36 | gradha | Allegro (C) too http://www.udel.edu/CIS/software/dist/allegro-4.2.1/docs/html/alleg030.html#file_exists |
| 22:52:26 | vbtt | fwiw, i'm looking at the user manual and it's starting to look like a really nice language :) |
| 22:53:04 | Araq | yeah but we lack interfaces and without interfaces you can't write useful software |
| 22:53:04 | vbtt | of course there are a few things not to my taste but overall it looks awesome - a great systems type language. |
| 22:53:20 | vbtt | is that in the plan for 1.0? |
| 22:53:34 | Araq | I hate interfaces with a passion fwiw |
| 22:54:03 | reactormonk | Araq, ^^ |
| 22:54:08 | vbtt | do you really need interfaces? |
| 22:54:11 | gradha | Araq: on that note I just answered on the forum, maybe you should rebrand generics |
| 22:54:13 | Araq | have yet to see use cases which are not cargo cult programming, streams are the obvious exception |
| 22:54:59 | reactormonk | Araq, functors? |
| 22:55:15 | Araq | but we managed to implement streams without interfaces ... |
| 22:55:17 | Araq | :P |
| 22:55:56 | reactormonk | Araq, you can replace interfaces with conventions |
| 22:56:04 | Araq | vbtt: I don't need interfaces and I am happier without them |
| 22:56:12 | vbtt | so dont implement them? |
| 22:56:30 | vbtt | if you still have polymorphism, you dont really need interfaces. |
| 22:57:02 | Araq | yeah, ... I don't use polymorphism either, but we have that |
| 22:57:07 | vbtt | I like implicit interfaces (i.e. duck typing :) - but statically checked would be awesome. |
| 22:58:00 | Araq | maybe I should implement them and say have fun, they don't really work well with an effects system, but what do I know ... |
| 22:59:38 | dom96 | We just need some syntax sugar for what is done in streams.nim |
| 22:59:55 | vbtt | if i can create a list of objects of different types, iterate over it and call a method that exist of all types, and it's statically checked, then i'm good. dont need interfaces. |
| 23:00:14 | Araq | dom96: really? why? implementing a stream is no big deal |
| 23:00:32 | Araq | and doesn't come up often |
| 23:00:45 | vbtt | the problem with interfaces-as-a-feature is people get interface-happy. |
| 23:00:48 | dom96 | Araq: To keep people happy. |
| 23:01:06 | Araq | vbtt: exactly and they even consider it good code/engineering |
| 23:01:09 | vbtt | soon you'll have addable, subtractable, divisible, addablesubtractable, and every combination thereof. |
| 23:01:12 | gradha | fuck happiness, will nimrod make me money? |
| 23:02:00 | Araq | gradha: I'm not sure what you're implying here |
| 23:02:11 | OrionPK | money is for schmucks |
| 23:02:31 | Araq | gradha: that we should optimize for popularity? |
| 23:02:38 | gradha | I can live on money, but I can't live on happiness, so I would prefer a tool to get the former |
| 23:02:49 | gradha | Araq: in this case, interfaces == popular |
| 23:02:52 | OrionPK | but when ur happy u can die happy |
| 23:02:58 | vbtt | btw, if I do 'var x = MyObject()' does it go on the stack or heap? |
| 23:03:03 | dom96 | Araq: We're already caving into people's demands. |
| 23:03:06 | OrionPK | interfaces would be nice.. |
| 23:03:18 | Varriount | Can't you get 'interfaces' already by simply using templates and assertions? |
| 23:03:19 | vbtt | heh, make sure you're happy too, or you wont like to work on your language :) |
| 23:05:10 | Varriount | Also, don't the abstract type thingies zaharies been working on pretty much implement interfaces? |
| 23:06:37 | dom96 | They do indeed. |
| 23:06:44 | Araq | Varriount: zahary implements "static interfaces" which I like very much |
| 23:06:48 | vbtt | you can always add things to the language, but it's harder to take them away (that's what language designers have been saying anyway) |
| 23:06:57 | Araq | but people ask for "dynamic interfaces" |
| 23:07:02 | dom96 | We should get those finished and change streams to use them |
| 23:07:14 | Varriount | "Dynamic Interfaces"? |
| 23:07:28 | vbtt | ..just on that principle, you could leave out interfaces and see how people use the language. |
| 23:07:29 | vbtt | what's a dynamic interfaces? |
| 23:08:10 | Araq | dom96: that's exactly what doesn't work |
| 23:08:26 | Araq | because streams pretty much require dynamic binding to fight excessive code bloat |
| 23:08:27 | OrionPK | dynamic binding |
| 23:08:46 | Araq | vbtt: I made up these terms |
| 23:08:47 | gradha | good night, honey badgers |
| 23:08:56 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 23:08:57 | OrionPK | night grader |
| 23:09:11 | dom96 | Well then I think that justifies at least some sugar. |
| 23:09:28 | dom96 | My selectors module uses the same approach that streams uses. |
| 23:09:41 | Varriount | You mean, runtime additions of conversion routines for those data structures which fulfill some sort of interface? |
| 23:10:57 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 23:11:11 | dom96 | And if a stream doesn't implement some proc under the interface it is silently ignored. Something which i'm not sure is the best idea. |
| 23:13:26 | Araq | we could easily crash instead :P |
| 23:13:38 | dom96 | Yes, is there a reason we don't? |
| 23:14:10 | Araq | can't remember |
| 23:14:21 | Araq | usually I have my reasons |
| 23:15:51 | dom96 | Perhaps I shouldn't be doing it the way streams is doing it then? |
| 23:15:59 | vbtt | btw, how do I put objects of different types in the same seq? |
| 23:16:23 | Varriount | vbtt: You don't? |
| 23:17:33 | * | DAddYE joined #nimrod |
| 23:17:34 | Varriount | vbtt: If you have a limited number of types that you need to contain, you could use an object type with conditional fields. |
| 23:19:32 | Varriount | If you aren't concerned about space, you can also use a sequence of tuples the same way. Object varients would take less space though. |
| 23:20:05 | Varriount | (If I"m not mistaken, object varients use unions with the C backend) |
| 23:20:52 | Araq | yes, they use unions |
| 23:20:57 | vbtt | hm ok |
| 23:21:23 | vbtt | so all objects in a sequence have to be the same type? |
| 23:21:32 | Araq | essentially yes |
| 23:21:54 | Araq | you can do use inheritance and "ref object" and put different things into the same seq |
| 23:22:34 | Araq | but if they are different types, why put them into the same seq? |
| 23:23:03 | Araq | usually you want to do the same stuff on every item in a seq |
| 23:23:14 | Araq | which is rather hard to do when they are of different types |
| 23:23:52 | Varriount | Araq: What if you have a sequence of abstract types which fulfill an interface? |
| 23:24:33 | Araq | Varriount: I use seq[proc () {.closure.}] then :P |
| 23:24:52 | vbtt | Araq: e.g. a sequence of strings interpolated with placeholder objects. then have a function that iterates over it, joining strings and rendering placeholders. |
| 23:25:26 | vbtt | i can probably do it with variants, but was trying to avoid another type definition. |
| 23:25:39 | Araq | "sequence of strings interpolated with placeholder objects" sounds exactly like I would never do |
| 23:25:55 | Varriount | vbtt: why placeholder objects? |
| 23:26:26 | vbtt | Varriount:e.g. a template that's being rendered |
| 23:26:44 | vbtt | you convert the placeholders to strings a a specific time, then join all strings. |
| 23:27:05 | Varriount | vbtt: That sounds suspiciously like what echo() does to stringify it's arguments |
| 23:28:07 | vbtt | the example is just to demonstrate the need for a sequence of disparate types. |
| 23:28:41 | Araq | the example is bad to show that, sorry |
| 23:28:52 | vbtt | echo renders all params right away. in my example you create the list once, then possibly render it later within different contexts for resolving placeholders. |
| 23:28:59 | vbtt | ok |
| 23:29:13 | Araq | seq[tuple{s: string, transform: proc (s: string): string]] does the trick |
| 23:29:30 | Araq | seq[tuple[s: string, transform: proc (s: string): string]] |
| 23:30:05 | Araq | if you want polymorphism over the "string" type, you can easily hide that in the closure |
| 23:30:21 | Araq | seq[proc (): string] |
| 23:30:41 | Varriount | Or if you want a quick, dirty, and unsafe solution, look to the above use of refs |
| 23:31:43 | Araq | for years I keep explaining closures are a cool replacement for common OO idioms |
| 23:31:50 | Araq | nobody listens to me! ;-) |
| 23:32:42 | Varriount | Araq: To be fair, I've known you for less than 6 months, and vbtt has known you for even less. |
| 23:34:33 | vbtt | I'm not too committed to OO idioms, in fact I dont like inheritance very much. |
| 23:34:51 | Araq | and what you hide in the closure stays typesafe without any inheritance and type conversions that can fail at runtime |
| 23:34:55 | vbtt | But my example doesn't have anything to do with OO. |
| 23:35:08 | Araq | maybe not |
| 23:35:23 | Araq | it's about some laziness |
| 23:35:49 | vbtt | yes :) |
| 23:36:30 | vbtt | and about ad-hoc polymorphism. |
| 23:38:02 | Araq | depends on your terminology, I know "ad-hoc polymorphism" as a synonym for "overloading" |
| 23:40:07 | vbtt | if you're familiar with python then that's what i was getting at. I can add objects of any type to a list, then iterate over it and access methods/fields on each object. if it's missing i get a runtime error. in a statically typed language, I was hoping to do the same but with static checking. or perhaps a requirement that i use a swich/case on typ |
| 23:40:07 | vbtt | e. |
| 23:40:45 | vbtt | this might require full program type analysis though. |
| 23:41:10 | Araq | well there are at least 3 solutions, case object, object + inheritance or closures |
| 23:41:20 | Araq | or a combination of these |
| 23:41:41 | vbtt | right - none of them are ad-hoc although all qualify for 'polymorphism' and quite acceptable for a static language. |
| 23:42:08 | Araq | all more verbose than python's solution but you can always try to patch a macro over that |
| 23:42:34 | vbtt | it's reasonable even without macros. i'm just getting a feel for the language and testing limits. |
| 23:42:43 | Araq | ok |
| 23:44:17 | * | io2 quit () |
| 23:48:49 | vbtt | is nimrod used in production? how unstable are the semantics and standard lib? |
| 23:49:04 | vbtt | ps: when is 1.0 planned? |
| 23:49:21 | Araq | some people use it in production but these are quiet |
| 23:49:45 | Araq | semantics and lib are stable |
| 23:49:58 | Araq | 1.0 planned for the end of the year |
| 23:50:06 | vbtt | ok |
| 23:50:17 | Araq | the biggest upcoming change is the saner concurrency model |
| 23:50:42 | * | vbtt quit (Remote host closed the connection) |
| 23:51:04 | * | vbtt_ joined #nimrod |
| 23:51:08 | vbtt_ | ah, something i am most interested in |
| 23:51:46 | vbtt_ | :) |
| 23:51:47 | Araq | well ok the sockets related stuff is in constant flux |
| 23:51:55 | Araq | so parts of the stdlib are stable |
| 23:52:17 | * | darkf joined #nimrod |
| 23:52:47 | dom96 | "Unlike other Windows API functions, ConnectEx() must be loaded at runtime" |
| 23:52:49 | dom96 | yay |
| 23:54:02 | reactormonk | I'm looking for a general-purpose server I can run a bit of data collection, via zmq. Anyone knows of good offers? |
| 23:54:23 | Araq | dom96 knows a good offer |
| 23:54:40 | dom96 | huh? |
| 23:54:54 | Araq | you tend to know these things ... |
| 23:55:23 | dom96 | I tend to stay away from zmq so no. |
| 23:56:04 | Araq | zmq is just some compiled software |
| 23:56:06 | reactormonk | dom96, I'm interested in a server, not comments about zmq :-P |
| 23:56:19 | Araq | runs on any os, dom96 |