| 00:00:15 | Araq | createFoo operates on fresh data, no need for any locks, but "protected" makes us acquire a lock |
| 00:01:26 | JehanII | Well, yes. The problem here is that result could be passed to another thread before the function returns. |
| 00:01:26 | JehanII | If you can guarantee that doesn't happen, you can optimize the lock away. |
| 00:01:56 | Araq | hmm |
| 00:02:07 | JehanII | The bigger problem is that initialization in any imperative language is a bit of a mess. |
| 00:02:37 | Araq | jup :D |
| 00:03:37 | Araq | well createFoo should operate on "shared" and then we need some mechanism to bless it to "protected" |
| 00:04:41 | JehanII | So, shared ptrs point to the shared heap, but cannot be transmitted to a different thread? |
| 00:05:19 | Araq | yes, they need to be converted to protected first |
| 00:05:37 | JehanII | What it comes down to is that in order for that to be safe, a shared ptr must not be aliased. |
| 00:06:23 | Araq | true. |
| 00:06:23 | * | eigenlicht quit (Ping timeout: 272 seconds) |
| 00:06:59 | Araq | but we can try to count references in debug mode and ensure it's not aliased at runtime |
| 00:07:13 | Araq | or give it some move semantics |
| 00:07:13 | OrionPK | wheres dom |
| 00:07:25 | gradha | does a tyBool -> string proc exist? |
| 00:07:40 | Araq | gradha: typeToString |
| 00:08:20 | gradha | cool |
| 00:09:49 | Araq | JehanII: obviously "cast" is the cheap way out, but I think we need something better |
| 00:10:02 | JehanII | Yeah, I'd agree. |
| 00:11:22 | * | OrionPK quit (Remote host closed the connection) |
| 00:11:33 | Araq | btw we may need a different term for "protected", what's common in the literature? |
| 00:11:43 | JehanII | One alternative would be to get clever with locks. |
| 00:12:03 | JehanII | Use a simple, cheap lock (basically just an int) while it's shared, make it a real one when it's promoted. |
| 00:12:34 | JehanII | I'm not sure there's a universally accepted term. |
| 00:13:03 | JehanII | I think I've seen shared, guarded, separate at least. |
| 00:14:16 | JehanII | synchronized, too. |
| 00:14:52 | * | JehanII left #nimrod ("Leaving") |
| 00:15:05 | * | JehanII joined #nimrod |
| 00:15:26 | JehanII | Sigh, OS X needs focus-follows-mouse. |
| 00:16:47 | Araq | "guarded" seems very good |
| 00:17:15 | Araq | maybe the keyword should even be "guard" and not "lock" then |
| 00:17:27 | gradha | good night, honey badgers |
| 00:17:27 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 00:17:33 | JehanII | Guarded statements are traditionally something different, though. |
| 00:17:52 | JehanII | atomic would be an alternative. |
| 00:18:08 | Araq | oh yeah |
| 00:18:12 | Araq | "atomic" smells like STM |
| 00:18:48 | Araq | anyway |
| 00:18:48 | * | OrionPK joined #nimrod |
| 00:18:53 | Araq | I don't understand your "be clever with locks" proposal |
| 00:19:10 | JehanII | Oh. |
| 00:19:28 | OrionPK | hm |
| 00:19:29 | JehanII | Okay, basically make locks a sum type, int | mutex. |
| 00:19:41 | JehanII | It starts out as an int, 0 for unlocked, 1 for locked. |
| 00:20:03 | JehanII | That makes lock and unlock operations negligibly cheap. |
| 00:20:49 | JehanII | As soon as you promote it to protected, you replace it with a pointer to a proper mutex/rwlock/etc. |
| 00:20:52 | JehanII | You can safely do it, because up to this point, no other thread has access to it. |
| 00:21:10 | JehanII | Hmm, hang on, we'd still need to encode the owning thread in it. |
| 00:21:31 | JehanII | No, never mind, other threads can't see it. |
| 00:21:33 | JehanII | After this, you can do a normal lock/unlock. |
| 00:21:39 | Araq | why do we need the cheap lock in the first place? |
| 00:22:07 | JehanII | So that we can auto-lock result during object creation without incurring the overhead for a full lock. |
| 00:22:52 | JehanII | Hmm, hang on, I think I outsmarted myself there. |
| 00:22:52 | Araq | but why, result is not yet shared |
| 00:23:04 | Araq | well its type is "shared" but it can't been seen by other threads yet |
| 00:23:18 | JehanII | Yeah, I was actually thinking about the case where we are starting out with a protected ptr right away. |
| 00:23:55 | JehanII | Yeah, that won't help. |
| 00:24:12 | Araq | I think the transition from shared -> protected needs to be implicit for convenience but should trigger some runtime check |
| 00:24:53 | * | joelmo joined #nimrod |
| 00:24:53 | Araq | the runtime check needs to ensure it's not aliased |
| 00:25:13 | JehanII | Yeah. |
| 00:25:33 | JehanII | The alternative is to prohibit assignments from one shared ptr to another. |
| 00:26:05 | JehanII | Hmm, no matter how one does it, it'd be hairy. |
| 00:26:18 | Araq | or perhaps we can do that statically |
| 00:26:32 | Araq | that's not feasable I think |
| 00:26:32 | JehanII | See, this is why I have multiple shared heaps myself, gets rid of the problem. :) |
| 00:27:14 | Araq | I can't follow but it's late |
| 00:27:14 | JehanII | Statically means you'd be basically reinventing Rust as a sublanguage of Nimrod? |
| 00:27:27 | JehanII | Eh, shared heaps that have a lock. |
| 00:27:33 | Araq | yeah ... |
| 00:27:43 | JehanII | Objects get created in the heap where they belong while you have a lock for the heap. |
| 00:27:57 | Araq | aha |
| 00:28:16 | Araq | so you extend the heap lock |
| 00:28:35 | Araq | whereas my allocshared returns without the heap lock |
| 00:28:45 | Araq | yours does not? |
| 00:28:55 | JehanII | Yeah. Or I create it in the thread-local heap and put it in the shared heap via a deep copy. |
| 00:29:15 | JehanII | In order to create the object, I need a lock on the heap already. |
| 00:29:36 | Araq | yeah same here |
| 00:29:56 | JehanII | There is some trickiness with creating the first object in a heap. |
| 00:30:57 | Araq | oh btw I forgot 1 thing that's not really relevant there but important anyway: nothing "in" a shared ptr can be seq/strings/refs aka GC'ed memory as that's thread local |
| 00:31:25 | JehanII | Yeah, I think I mentioned that in my email: That strikes me as a bit of a problem. |
| 00:31:57 | JehanII | If you can't have shared GCed memory, then that limits what you can share. |
| 00:32:58 | Araq | yeah but I don't think it's too much of a problem |
| 00:33:18 | Araq | shared memory is for speed and so not using a GC makes sense |
| 00:33:51 | JehanII | Hmm, I'd disagree there. |
| 00:34:19 | JehanII | Think of a shared username -> password table (simple example). |
| 00:34:39 | JehanII | That's shared not because of speed, because it's shared global knowledge required by multiple threads. |
| 00:35:00 | Araq | oh that's what you mean |
| 00:36:22 | JehanII | Or think of a web browser. You may have a GUI thread and an I/O thread, and both manipulate the same document. |
| 00:37:22 | JehanII | Admittedly, I may be biased by my current application domain. |
| 00:38:02 | JehanII | I do computer algebra, and there you have a lot of shared data that is structured, often in a rather complicated fashion. |
| 00:39:02 | Araq | well surely the most general mechanism is a GC that can deal with threads |
| 00:39:43 | JehanII | Yeah. Which is why my solution so far when I needed it has been to use the Boehm GC. :) |
| 00:39:50 | Araq | yeah well we might get one |
| 00:40:00 | Araq | but the bigger problem is that then we either |
| 00:40:14 | Araq | (a) have "shared ref" in addition to all the other pointer types |
| 00:40:14 | JehanII | Pause times generally aren't important for me (that the Boehm GC is non-generational is a bigger problem). |
| 00:40:41 | Araq | (b) conflate "shared ref" with "ref" (which I don't like at all) |
| 00:41:04 | Araq | so not supporting "shared ref" makes things simpler :P |
| 00:41:44 | JehanII | For what it's worth, I do not disagree. |
| 00:41:44 | EXetoC | "lib/system.nim(1362, 7) Error: ambiguous call; both system.<(x: float, y: float): bool and system.<(x: float32, y: float32): bool match for: (float32, float)" did anything related change recently? |
| 00:41:59 | JehanII | Concurrent Garbage Collection is a painful problem. |
| 00:42:45 | Araq | yeah but it's also a painful type system design problem |
| 00:43:05 | EXetoC | this worked before |
| 00:43:25 | Araq | EXetoC: do you use "devel"? |
| 00:43:25 | JehanII | I'm not a type theorist by trade. |
| 00:44:50 | JehanII | Anyhow, I need to head off to bed, or I'll sleepwalk to work tomorrow. |
| 00:45:07 | JehanII | Good night, folks. :) |
| 00:45:15 | * | JehanII quit (Quit: Leaving) |
| 00:45:56 | Araq | same here, good night |
| 00:46:45 | EXetoC | did I use it before? I'll try it |
| 00:47:14 | EXetoC | cya |
| 00:50:03 | EXetoC | Araq: yeah that was it |
| 00:51:31 | Varriount | Huh. I'm shocked at how... simple/unoptimized boost's implementation of directory removal is. |
| 01:09:22 | Demos | does speed even matter for directory removal? |
| 01:09:42 | shevy | only if you want to delete the whole internetz! |
| 01:10:43 | Demos | like if you are working with directories you are probably doing something IO bound in the first place |
| 01:25:03 | * | wan quit (Remote host closed the connection) |
| 01:28:31 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 01:42:33 | Varriount | Demos, speed, maybe not |
| 01:42:43 | Varriount | But open handles? Yes |
| 01:46:04 | Varriount | Personally, I'm quite surprised that neither the Posix specification, the Linux api, nor the Win32 api have functions for recursive removal of a directory - it's a common enough need. |
| 01:47:07 | * | Raynes quit (Ping timeout: 246 seconds) |
| 01:53:49 | * | darkf quit (Read error: Connection reset by peer) |
| 01:54:25 | * | darkf joined #nimrod |
| 01:59:12 | * | Raynes joined #nimrod |
| 01:59:26 | * | Raynes quit (Changing host) |
| 01:59:26 | * | Raynes joined #nimrod |
| 02:06:49 | * | eigenlicht joined #nimrod |
| 02:11:40 | * | DAddYE quit (Remote host closed the connection) |
| 02:27:07 | * | Kooda quit (Ping timeout: 246 seconds) |
| 02:40:55 | * | Kooda joined #nimrod |
| 03:12:55 | * | DAddYE joined #nimrod |
| 03:15:29 | * | brson quit (Quit: leaving) |
| 03:17:19 | * | DAddYE quit (Ping timeout: 246 seconds) |
| 03:33:06 | * | DAddYE joined #nimrod |
| 03:58:24 | * | jcrubino joined #nimrod |
| 05:27:40 | * | Endy joined #nimrod |
| 07:03:30 | * | Demos quit (Ping timeout: 245 seconds) |
| 07:33:27 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 07:37:52 | * | DAddYE joined #nimrod |
| 08:50:18 | * | Endy quit (Ping timeout: 246 seconds) |
| 09:00:12 | * | shevy quit (Ping timeout: 272 seconds) |
| 09:12:50 | * | shevy joined #nimrod |
| 09:16:24 | * | DAddYE quit () |
| 09:32:15 | * | Araq_ joined #nimrod |
| 09:47:08 | * | Endy joined #nimrod |
| 09:52:47 | * | ddl_smurf joined #nimrod |
| 09:55:17 | * | BitPuffin joined #nimrod |
| 09:55:49 | BitPuffin | hey! |
| 09:55:49 | BitPuffin | Araq_: can I read ze article? :) |
| 09:55:49 | dom96 | hello |
| 09:56:28 | BitPuffin | ohai dom diddely dom96 |
| 09:59:04 | Araq_ | no it's not finished, but read the logs |
| 09:59:32 | Araq_ | Jehan was here and he is a concurrency expert :P |
| 10:05:11 | * | [1]Endy joined #nimrod |
| 10:07:38 | * | Endy quit (Ping timeout: 264 seconds) |
| 10:07:58 | * | [1]Endy is now known as Endy |
| 10:08:18 | BitPuffin | Araq_: Well I understand it's not finished ofc :) |
| 10:08:18 | BitPuffin | I just wanna know about the basic idea |
| 10:13:04 | * | io2 joined #nimrod |
| 10:19:27 | * | Endy quit (Ping timeout: 240 seconds) |
| 10:20:15 | * | jcrubino quit (Ping timeout: 246 seconds) |
| 10:23:09 | * | zielmicha joined #nimrod |
| 10:25:49 | * | Araq_ quit (Read error: Connection timed out) |
| 10:28:12 | * | Araq_ joined #nimrod |
| 10:41:26 | * | Araq_ quit (Ping timeout: 240 seconds) |
| 10:44:21 | * | Araq_ joined #nimrod |
| 10:48:43 | * | wan joined #nimrod |
| 10:59:57 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 11:00:12 | BitPuffin | dom96: how was the formals or whatever prom is called in your silly country? |
| 11:00:12 | dom96 | formal |
| 11:00:12 | dom96 | It was great. |
| 11:00:12 | dom96 | Only got back like 2 hours ago |
| 11:00:12 | dom96 | because I stayed over with my friends |
| 11:00:32 | dom96 | BitPuffin: Are you at work now? |
| 11:00:54 | BitPuffin | dom96: ah I see! It's cool... I only waited up for you to play dota with me.. But I guess your friends are more important.. |
| 11:02:28 | BitPuffin | dom96: si |
| 11:02:28 | dom96 | BitPuffin: Even if I didn't stay over with my friends I would have only gotten back at like 4am :P |
| 11:02:28 | BitPuffin | dom96: yes, but that I expected |
| 11:03:33 | dom96 | so you were here at 5am? lol |
| 11:03:33 | dom96 | (your time) |
| 11:05:06 | BitPuffin | yes |
| 11:05:06 | BitPuffin | because I thought we were playing dota |
| 11:05:06 | BitPuffin | </3 |
| 11:05:06 | dom96 | awwww, you're dedicated |
| 11:05:06 | dom96 | Sorry |
| 11:05:12 | dom96 | I don't think playing dota drunk would go well though |
| 11:05:19 | BitPuffin | dom96: haha |
| 11:17:42 | * | NimBot joined #nimrod |
| 11:17:50 | DedicatedPuffin | lol NimBot |
| 11:17:52 | dom96 | DedicatedPuffin: sure |
| 11:18:00 | * | DedicatedPuffin is now known as BitPuffin |
| 11:19:10 | * | zielmicha8 joined #nimrod |
| 11:20:52 | BitPuffin | dom96: sweet |
| 11:21:02 | * | BitPuffin is the dota 2 addict these days |
| 11:23:05 | * | dom96 shouldn't be feeding this addiction |
| 11:26:42 | * | aftershave quit (Quit: Textual IRC Client: www.textualapp.com) |
| 11:27:06 | dom96 | oh! New Sherlock! |
| 11:27:40 | * | aftershave joined #nimrod |
| 11:43:06 | BitPuffin | dom96: no shit sherlock |
| 11:43:29 | BitPuffin | har har |
| 11:43:44 | dom96 | oh you |
| 11:45:37 | BitPuffin | u luv it |
| 11:46:07 | BitPuffin | if only I could play dota 2 at work |
| 11:52:25 | BitPuffin | dom96: http://www.reddit.com/r/DotA2/comments/1i6udf/ |
| 11:55:05 | * | darkf quit (Quit: Leaving) |
| 12:03:46 | * | fntzr joined #nimrod |
| 12:04:46 | BitPuffin | dom96: http://critwhale.com/DotaMap.jpg woa dat advantage for dire mid |
| 12:04:52 | BitPuffin | with secret shop access on mid lane |
| 12:07:48 | * | Araq_ joined #nimrod |
| 12:09:08 | * | dirkk0 joined #nimrod |
| 12:10:50 | BitPuffin | Araq_: the conversation was gerat and all, but didn't say anything about what the model is about |
| 12:11:59 | Araq_ | well the model is about making locks safe and making you insert locks where they are needed |
| 12:14:54 | BitPuffin | Araq_: or not compile? |
| 12:17:26 | * | Araq_ quit (Ping timeout: 240 seconds) |
| 12:27:29 | BitPuffin | dom96: I wonder if they have added new items since that guy made an overview of items |
| 12:39:12 | * | zielmicha8 quit (Ping timeout: 246 seconds) |
| 12:39:33 | * | zielmicha quit (Ping timeout: 246 seconds) |
| 12:49:30 | * | Araq_ joined #nimrod |
| 12:54:06 | * | [1]Endy joined #nimrod |
| 13:08:20 | * | Araq_ quit (Write error: Broken pipe) |
| 13:09:45 | * | Araq_ joined #nimrod |
| 13:11:46 | * | aftersha_ joined #nimrod |
| 13:15:18 | * | aftersha_ quit (Client Quit) |
| 13:23:17 | * | psquid quit (Quit: work) |
| 14:02:36 | OrionPK | dom96 you should send built up response headers in jester when you call "sendHeaders" |
| 14:02:59 | OrionPK | default the headers parameter to the response.data[3] or whatever |
| 14:05:18 | * | io2 quit (Ping timeout: 246 seconds) |
| 14:18:45 | dom96 | hrm, sure. |
| 14:18:52 | dom96 | OrionPK: Make an issue |
| 14:19:36 | dom96 | btw the assert failure you experienced is something I put in in case the compiler chooses the wrong trySendEx implementation |
| 14:19:47 | dom96 | Possibly a compiler bug actually |
| 14:20:15 | dom96 | I haven't had a chance to test async because I was on Windows, and on Windows async httpserver is broken |
| 14:27:07 | * | zielmicha joined #nimrod |
| 14:33:02 | OrionPK | mm ok |
| 14:34:44 | * | zielmicha quit (Ping timeout: 260 seconds) |
| 14:35:14 | * | zielmicha joined #nimrod |
| 14:35:50 | * | fntzr quit (Quit: Leaving) |
| 14:45:44 | * | OrionPK quit (Remote host closed the connection) |
| 14:46:33 | BitPuffin | dom96: only nubs use windows |
| 14:50:06 | * | OrionPK joined #nimrod |
| 14:56:41 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) |
| 14:57:13 | OrionPK | dom96 not sure yet if changing to writing directly to sockets has been worth it |
| 14:57:23 | * | zielmicha quit (Ping timeout: 272 seconds) |
| 14:59:56 | * | aftersha_ joined #nimrod |
| 15:14:07 | * | zielmicha joined #nimrod |
| 15:15:38 | * | Mat3 joined #nimrod |
| 15:15:40 | Mat3 | hi all |
| 15:18:33 | BitPuffin | yo Mat3 |
| 15:20:30 | Mat3 | hi BitPuffin |
| 15:22:22 | BitPuffin | Mat3: wassa? |
| 15:27:56 | Mat3 | not much, low-level coding |
| 15:32:42 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 15:36:38 | BitPuffin | Mat3: interesting! |
| 15:51:03 | shevy | BitPuffin: liar ! |
| 15:51:05 | shevy | ;P |
| 15:57:52 | BitPuffin | shevy: no I like das low levels |
| 15:58:43 | * | zielmicha8 joined #nimrod |
| 16:59:16 | * | Mat3 quit (Quit: Verlassend) |
| 17:05:42 | * | aftersha_ joined #nimrod |
| 17:16:49 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 17:20:24 | * | brson joined #nimrod |
| 17:34:19 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 17:38:47 | * | dirkk0 quit (Quit: This computer has gone to sleep) |
| 17:41:03 | * | Demos joined #nimrod |
| 17:41:12 | * | io2 joined #nimrod |
| 17:52:17 | * | zauberparacelsus joined #nimrod |
| 17:52:40 | zauberparacelsus | How much work is required to create a nimrod binding for a C or C++ library? |
| 18:05:55 | OrionPK | zauberparacelsus a bit more for a C++ library, assuming you dont want to force people to compile their nimrod to c++ |
| 18:06:21 | zauberparacelsus | ok, though what about C? |
| 18:06:37 | OrionPK | it varies on the complexity of the library; if it uses a lot of macros etc |
| 18:06:43 | OrionPK | but usually its fairly easy |
| 18:06:58 | zauberparacelsus | ok |
| 18:07:56 | zauberparacelsus | though it looks like one of the libraries I was thinking of, Irrlicht, might already have bindings |
| 18:08:18 | OrionPK | there's a lot of examples in the nimrod repo |
| 18:08:28 | OrionPK | https://github.com/Araq/Nimrod/tree/master/lib/wrappers |
| 18:08:36 | zauberparacelsus | I'll have to poke around, thanks! |
| 18:08:45 | OrionPK | yep |
| 18:09:01 | OrionPK | take a look at the documentation for c2nim as well |
| 18:09:09 | zauberparacelsus | ok |
| 18:09:48 | zauberparacelsus | one other question: is there anything for Nimrod that's equivalent to the Flask library for Python? |
| 18:10:42 | OrionPK | sorry, no idea what flask is. I'm not a python programmer |
| 18:11:15 | OrionPK | it's for web development? |
| 18:11:24 | zauberparacelsus | aye, a web microframework |
| 18:11:38 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 18:11:57 | zauberparacelsus | I wrote a wiki engine in Python and Flask, and I'm thinking of converting it to Nimrod (or attempting to do so) as a learning project. |
| 18:12:10 | OrionPK | you should look into Jester |
| 18:12:28 | OrionPK | I've also been working on a templating API that works quite well with jester |
| 18:12:45 | zauberparacelsus | oh? Interesting |
| 18:13:06 | zauberparacelsus | What's it based on? I had been using Jinja2 templating with Flask. |
| 18:13:21 | OrionPK | https://dl.dropboxusercontent.com/u/417554/template.png |
| 18:13:45 | OrionPK | it's compile-time template, so it uses nimrods own compiler to do the templating |
| 18:14:04 | zauberparacelsus | oh, I see |
| 18:14:21 | OrionPK | so you can do looping, if/elif/else, etc |
| 18:14:30 | OrionPK | and it transforms your string at compile time into a series of statements |
| 18:14:40 | OrionPK | makes it fairly efficient at runtime |
| 18:17:12 | zauberparacelsus | yeah, though personally I'd prefer something more dynamic for templating. |
| 18:17:31 | OrionPK | more dynamic? |
| 18:17:47 | zauberparacelsus | loading the templates from text files external to the executable |
| 18:18:10 | OrionPK | ah |
| 18:18:29 | OrionPK | that will be doable if nimrod ever gets a JIT compiler |
| 18:18:43 | OrionPK | but it would be less powerful IMO |
| 18:19:08 | OrionPK | to do it without compiler support i mean |
| 18:19:25 | OrionPK | https://dl.dropboxusercontent.com/u/417554/logic_example.png |
| 18:19:35 | OrionPK | this allows you to do much more complex logic right inside the template |
| 18:19:41 | OrionPK | similar to razor in ASP.NET MVC |
| 18:20:05 | OrionPK | and in sublime, at least, we have support for syntax highlighting of the templates |
| 18:20:08 | * | aftersha_ joined #nimrod |
| 18:20:22 | zauberparacelsus | ok |
| 18:24:42 | Araq | hi zauberparacelsus welcome |
| 18:24:48 | zauberparacelsus | heyo |
| 18:25:05 | Araq | OrionPK: we will have a scripting API soon, no need to JIT string templates |
| 18:25:25 | zauberparacelsus | \o/ |
| 18:25:51 | * | dirkk0 joined #nimrod |
| 18:25:56 | OrionPK | araq I still like compiled templates ;) |
| 18:26:18 | Araq | in fact ... I had it wrapped into a module but can't find the code :P |
| 18:27:01 | OrionPK | doh |
| 18:27:26 | OrionPK | given my templates module, how hard would it be for me to support the scripting module |
| 18:27:42 | Araq | dunno |
| 18:29:22 | * | DAddYE joined #nimrod |
| 18:30:26 | zauberparacelsus | oh, another question: does Nimrod have increment and decrement operators? I had missed those when working with Python |
| 18:31:10 | OrionPK | you generally would use Inc and dec |
| 18:32:40 | OrionPK | there's no ++ or -- built in |
| 18:33:13 | * | gradha joined #nimrod |
| 18:33:26 | zauberparacelsus | ok |
| 18:35:03 | * | aftersha_ quit (Quit: Computer has gone to sleep.) |
| 18:36:44 | Araq | zauberparacelsus: you can easily define your own operators in nimrod so if you really "need" them, you can define ++ and -- easily |
| 18:37:01 | OrionPK | araq what about ++op vs. op++ |
| 18:37:38 | Araq | well ok you can only do ++op :-) |
| 18:38:31 | Araq | ... and op.`++` |
| 18:39:08 | Araq | and with a macro you can even have different semantics for the two |
| 18:39:18 | Araq | but that's a hack |
| 18:40:41 | OrionPK | can do and should do are very different here ;) |
| 18:41:33 | Demos | unary operators like that are the devil though |
| 18:51:37 | Araq | ping zahary |
| 18:53:42 | * | shodan45 joined #nimrod |
| 18:55:42 | * | dirkk0 quit (Quit: Leaving) |
| 18:56:55 | zauberparacelsus | Araq: So, what form would the scripting API take? |
| 18:58:19 | Araq | proc execute(code: string): PJson |
| 18:58:40 | Araq | not really PJson but it conveys the right idea |
| 18:59:05 | zauberparacelsus | what's PJson? |
| 18:59:31 | Araq | nimrod's way to describe data in the JSON format |
| 18:59:43 | zauberparacelsus | ok |
| 19:00:47 | Araq | you can then lay proc execute[T](code: string): T on top of that |
| 19:01:11 | Araq | but the low level API cannot be typed |
| 19:17:37 | OrionPK | so araq where is this execute proc at? |
| 19:17:52 | Araq | I lost it :-/ |
| 19:18:00 | OrionPK | doh, gone forever? |
| 19:18:47 | Araq | well perhaps it's on my other computer |
| 19:18:52 | OrionPK | does it just allow you to do the things you can currently do w/ compiletime procs & macros? |
| 19:19:09 | Araq | yes it's a wrapper around vm2 |
| 19:19:14 | OrionPK | mmk |
| 19:38:15 | gradha | hah, this is interesting, when I change the default parameter from "-" to "," the compiler says: "Error: overloaded 'renderParamTypes' leads to ambiguous calls" |
| 19:38:52 | Araq | yeah yeah yeah |
| 19:39:01 | Araq | I know this check ain't perfect |
| 19:39:08 | Araq | better than nothing though |
| 19:39:15 | gradha | aaah, cool, it's because the forward declaration has a different default value |
| 20:10:56 | * | DAddYE_ joined #nimrod |
| 20:10:56 | * | DAddYE quit (Read error: Connection reset by peer) |
| 20:15:58 | * | Demos quit (Quit: Leaving) |
| 20:16:25 | * | Demos joined #nimrod |
| 20:23:19 | * | shodan45 quit (Quit: Konversation terminated!) |
| 20:25:08 | * | shodan45 joined #nimrod |
| 21:01:25 | OrionPK | anyone used zlib's TZStream? |
| 21:09:28 | Araq | I only had one small test program for zlib iirc |
| 21:11:02 | * | [1]Endy quit (Ping timeout: 240 seconds) |
| 21:20:39 | EXetoC | has anything changed with regards to overload resolution? "proc foo*[T](x, y: T) = bar(x, y)" seems to look if bar is available only where foo is defined, and not where it is instantiated |
| 21:24:50 | Araq | that's symbol lookup in generics, not overload resolution but ugh |
| 21:25:01 | Araq | I told zahary to not change this |
| 21:25:23 | Araq | I guess I need to revert his changes if he doesn't show up here soon |
| 21:25:52 | EXetoC | oh |
| 21:26:02 | Araq | however |
| 21:26:15 | Araq | could also be that's documented behaviour :P |
| 21:26:28 | Araq | if "bar" is not overloaded it defaults to "bind" |
| 21:26:40 | Araq | if it's overloaded it's a "mixin" |
| 21:26:59 | Araq | you can always explicitly state what you want though |
| 21:27:35 | Araq | check the manual :P |
| 21:36:54 | EXetoC | I'd rather not have to resort to templates every time, but hopefully it's just a temporary limitation. template + mixin works in this case |
| 21:42:43 | * | DAddYE_ quit (Ping timeout: 272 seconds) |
| 21:42:47 | * | DAddYE joined #nimrod |
| 21:46:24 | * | Varriount|Mobile joined #nimrod |
| 22:11:18 | * | CarpNet joined #nimrod |
| 22:11:42 | * | CarpNet quit (Client Quit) |
| 22:11:53 | Araq | EXetoC: you can use a 'mixin' directly in the generic, no need for a template |
| 22:19:50 | * | Varriount|Mobile quit (Remote host closed the connection) |
| 22:20:06 | * | Varriount|Mobile joined #nimrod |
| 22:22:44 | OrionPK | got it working araq |
| 22:24:31 | Araq | good |
| 22:24:50 | Araq | OrionPK: finished my concurrency model |
| 22:25:00 | OrionPK | good |
| 22:29:47 | * | aftersha_ joined #nimrod |
| 22:34:46 | OrionPK | start to get lots of lovely errors after gzip to much though |
| 22:42:40 | * | Mat3 joined #nimrod |
| 22:42:54 | Mat3 | hi |
| 22:43:10 | gradha | hey |
| 22:43:19 | Mat3 | hi gradha |
| 22:44:22 | Araq | hi Mat3 |
| 22:50:52 | Mat3 | hi Araq |
| 22:53:52 | Mat3 | what's new ? |
| 22:54:23 | Araq | I think I finished nimrod's concurrency model for version 1 |
| 22:54:49 | Mat3 | great news, where cane I find informations about it ? |
| 22:55:01 | Mat3 | ^can |
| 22:55:16 | Araq | well I'm still writing the blog posts |
| 22:56:13 | gradha | Araq: you are doing it wrong |
| 22:56:21 | * | Mat3 reminds me finishing my documentation |
| 22:56:24 | gradha | Mat3: for a small fee you can take a sneak peak |
| 22:56:35 | Araq | lol |
| 22:56:57 | Mat3 | gradha: dream on *g* |
| 22:57:44 | * | darkf joined #nimrod |
| 22:57:55 | Araq | it ensures freedom of data races and deadlocks at compile time and introduces a notion of implicitly unique pointers |
| 22:58:26 | Araq | lol |
| 22:58:38 | Araq | sounds like good marketing |
| 22:58:58 | Mat3 | marketsprech |
| 23:00:22 | Araq | but you'll like it, it's all based on non GC'ed memory |
| 23:00:40 | Araq | should be good for embedded stuff |
| 23:00:44 | Mat3 | great |
| 23:01:25 | dom96 | Araq: If I have a converter getSocket(s: PAsyncSocket): TSocket, and then a proc foo(sock: TSocket | PAsyncSocket) = when sock is TSocket: ... Should this be true when I pass a PAsyncSocket to foo? |
| 23:01:49 | Araq | lol no |
| 23:02:16 | Araq | but it's pointless code |
| 23:02:28 | Araq | proc foo(sock: TSocket) = ... |
| 23:02:37 | Araq | proc foo(sock: PAsyncSocket) = ... |
| 23:02:47 | Araq | you might as well use overloading, you know |
| 23:03:05 | Araq | common implementation can be put into a template |
| 23:03:16 | dom96 | hrm, true. |
| 23:03:24 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 23:03:34 | dom96 | I think it currently is true though. |
| 23:03:57 | dom96 | I guess the compiler will pick the TSocket overload too. |
| 23:04:12 | dom96 | or maybe it's just an issue with `is` |
| 23:05:00 | Mat3 | hi dom96 |
| 23:05:16 | Araq | my bet it's "is" |
| 23:10:28 | * | PortablePuffin joined #nimrod |
| 23:10:31 | * | psquid joined #nimrod |
| 23:10:44 | dom96 | PortablePuffin: DOTA |
| 23:10:51 | dom96 | PortablePuffin: WHERE R U |
| 23:10:59 | PortablePuffin | dom96: SOON |
| 23:11:07 | Mat3 | Araq: Is "write tracking" implemented, as intended in your blog ? |
| 23:11:28 | Araq | no |
| 23:11:41 | * | Boscop is now known as Boscop__ |
| 23:11:46 | Mat3 | hmm |
| 23:12:01 | dom96 | hi Mat3 |
| 23:12:22 | Araq | and it's not necessary for the concurrency model anymore either |
| 23:12:49 | PortablePuffin | woot |
| 23:12:56 | Mat3 | ok, hope you finish your writing soon |
| 23:13:22 | Araq | a simpler variant of it is necessary though |
| 23:13:59 | PortablePuffin | Araq: I'm really excited about it and I'll adopt it immediately in probably two projects initially |
| 23:14:19 | Mat3 | (I think to have an idea of your implementation, let's see) |
| 23:14:37 | PortablePuffin | even though I don't know what it is yet |
| 23:14:45 | PortablePuffin | lol :p |
| 23:15:06 | Araq | lol well it's good some people try to write read world programs with it |
| 23:15:13 | Araq | *real |
| 23:15:31 | * | Mat3 downloading internet ... please wait *lol* |
| 23:18:57 | PortablePuffin | Araq precisely my thought |
| 23:19:31 | Mat3 | get some sleep ciao |
| 23:19:38 | * | Mat3 quit (Quit: Verlassend) |
| 23:20:21 | * | Boscop__ quit (Quit: Page closed) |
| 23:27:41 | gradha | good night, honey badgers |
| 23:27:46 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 23:47:45 | * | BitPuffin joined #nimrod |
| 23:59:28 | * | DAddYE_ joined #nimrod |
| 23:59:28 | * | DAddYE quit (Read error: Connection reset by peer) |
| 23:59:34 | BitPuffin | dom96: okay just a sec :D |
