| 00:59:01 | * | q66 quit (Quit: Quit) |
| 02:19:15 | * | shevy2 is now known as shevy |
| 05:17:33 | * | JStoker quit (Excess Flood) |
| 05:28:30 | * | JStoker joined #nimrod |
| 05:28:30 | * | JStoker quit (Excess Flood) |
| 05:32:24 | * | JStoker joined #nimrod |
| 05:32:25 | * | JStoker quit (Excess Flood) |
| 05:33:30 | * | JStoker joined #nimrod |
| 08:05:53 | * | zahary1 quit (Ping timeout: 255 seconds) |
| 08:06:28 | * | zahary joined #nimrod |
| 09:15:38 | * | JStoker quit (Ping timeout: 255 seconds) |
| 09:18:34 | * | dom96 quit (Ping timeout: 240 seconds) |
| 09:22:13 | * | dom96 joined #nimrod |
| 09:31:02 | * | JStoker joined #nimrod |
| 10:20:58 | * | Trix[a]r_za is now known as Trixar_za |
| 12:05:10 | * | apriori_ joined #nimrod |
| 13:01:40 | * | Trixar_za is now known as Trix[a]r_za |
| 13:26:51 | * | q66 joined #nimrod |
| 14:36:28 | * | apriori_ quit (Quit: Konversation terminated!) |
| 14:53:34 | * | FreeArtMan joined #nimrod |
| 16:04:07 | * | apriori_ joined #nimrod |
| 17:33:38 | * | apriori_ quit (Quit: Konversation terminated!) |
| 18:32:03 | * | zahary quit (Read error: No route to host) |
| 18:32:07 | * | zahary1 joined #nimrod |
| 18:44:20 | * | fowl quit (Ping timeout: 260 seconds) |
| 19:06:59 | * | zahary1 quit (Ping timeout: 252 seconds) |
| 19:15:52 | * | fowl joined #nimrod |
| 19:25:59 | * | zahary joined #nimrod |
| 19:43:03 | * | shevy quit (Ping timeout: 245 seconds) |
| 19:56:17 | * | shevy joined #nimrod |
| 20:37:22 | * | Vladar joined #nimrod |
| 20:55:45 | Araq | ping zahary |
| 21:26:06 | zahary | hi |
| 21:26:18 | * | gradha joined #nimrod |
| 21:27:01 | Araq | I've been thinking about unlocked[T] vs locked[T] |
| 21:27:29 | gradha | dom96: thanks for fixing the irc logs, they are useful |
| 21:28:14 | Araq | a shared object starts as 'unlocked' and you can't to anything with it except to 'lock' it |
| 21:28:36 | Araq | as even read accesses are potentially racy |
| 21:29:07 | Araq | however this means you can do the same with: |
| 21:29:27 | Araq | type TProtected = distinct T |
| 21:30:00 | Araq | template lock(x: TProtected, body: stmt) # in 'body' of type 'T' |
| 21:32:14 | zahary | I'm not sure what is the problem you are talking about, but it's certainly possible to have an API like this: |
| 21:32:14 | zahary | var access = unlock(locked) |
| 21:32:14 | zahary | access.doStuff |
| 21:33:08 | Araq | well I consider the locking stuff to be solved ;-) |
| 21:33:21 | Araq | and now I'm thinking about preventing races |
| 21:33:29 | Araq | and the idea is to do this: |
| 21:33:54 | Araq | type TShared = object {.protected: someLock.} |
| 21:34:12 | Araq | and I'm thinking what you can do with TShared ... |
| 21:34:25 | Araq | and it turns out: not much ;-) |
| 21:34:25 | zahary | usually, instances are protected by locks, not types |
| 21:34:32 | gradha | dom96: the stuff at http://build.nimrod-code.org, can I contribute my laptop to building the mac stuff? If so, tell me what is involved in that, and if it can be offline sometimes |
| 21:34:35 | zahary | or this is distinct type here? |
| 21:35:27 | Araq | well my idea is to introduce a 'protected' pragma for types, but yeah I think 'distinct' can do exactly the same |
| 21:35:53 | Araq | and yes I'm aware that instances are protected by locks but that's too hard |
| 21:36:30 | Araq | it's better to restrict the locks so that static analysis can do useful things |
| 21:37:02 | zahary | I've seen a library for C++ that's doing: |
| 21:37:02 | zahary | var access = unlock(locked) |
| 21:37:02 | zahary | access.doStuff |
| 21:37:02 | zahary | access here is a scoped lock object that hase predefined operator -> (proxy type in nimrod terms, all operations are redirected to the unlocked instance) |
| 21:39:20 | Araq | hu? |
| 21:39:27 | Araq | unlock(locked) ? |
| 21:39:29 | dom96 | gradha: You most certainly can, however, perhaps it might be better if you wait for the new nimbuild to be finished. |
| 21:39:51 | Araq | shouldn't it be: lock(protected)? |
| 21:40:26 | Araq | it's safe to do stuff when you have the lock |
| 21:40:27 | zahary | locked is an instance of a mutex guarded object (that's what you mean by protected too, right?) |
| 21:40:37 | Araq | (right) |
| 21:42:27 | zahary | ah, yes. it should be `lock`, saw the typo and the question now |
| 21:42:56 | Araq | ok well yeah that's the idea |
| 21:43:23 | Araq | the effect system does some lock inference but apart from that there is not much we can do |
| 21:43:54 | Araq | for instance you can't do: someP(protected) |
| 21:44:37 | Araq | as someP will read or even write protected (that's the point of passing it to 'someP' after all!) which is not safe |
| 21:45:09 | Araq | well I mean 'someP' doesn't take a protected but the underlying object type |
| 21:53:42 | Araq | partition(a: protectedArray, i: int): tuple[x, y: array] |
| 21:54:02 | Araq | can be done in the library, but has some problems: |
| 21:54:39 | Araq | the views x and y and then unprotected and the code can afterwards do unsafe things with them |
| 21:55:00 | Araq | for instance if you do: threadA(x); threadB(x) # typo |
| 21:55:52 | Araq | so it's preferable to let partition do the thread creation and pass in the block you want to perform for each array view |
| 21:56:21 | gradha | well, waiting is not a problem |
| 21:57:37 | Araq | gradha: but 0.9.2 should be out before christmas and it would be nice if the test suite runs on mac os x ;-) |
| 21:57:52 | Araq | dom96: what's missing for nimbuild? |
| 21:59:51 | dom96 | remote builders need to be tested |
| 22:00:20 | Araq | isn't that exactly what gradha wants to do? |
| 22:00:29 | dom96 | other than that, not that much IIRC. |
| 22:02:32 | dom96 | Well. I'd rather test them myself first. |
| 22:16:47 | Araq | zahary: any ideas? |
| 22:18:41 | zahary | haven't thought much about that, but in AMP, the partition logic is built right into the parallel_for function |
| 22:19:09 | zahary | you say parallel_for(normal_array) do (partition): |
| 22:22:10 | Araq | well now we know why ;-) |
| 22:44:58 | Vladar | What is "Error: internal error: getTypeDescAux(tyExpr)" ? |
| 22:45:48 | * | Trix[a]r_za is now known as Trixar_za |
| 22:49:03 | Araq | Vladar: a bug ... |
| 22:52:05 | Araq | likely caused by wrong code of yours though |
| 22:52:23 | Araq | bug report please |
| 23:00:39 | Vladar | Araq, oh, it when I try to declare var of type `any` |
| 23:09:26 | Vladar | Should I post it to bugreport anyway? |
| 23:09:54 | zahary | is this TAny from the runtime-info module or any from system? |
| 23:10:22 | Vladar | from system |
| 23:11:06 | zahary | `any` from system is valid only as a param type. what are your expectations when you declare such var? what should happen? |
| 23:11:51 | Vladar | actually I tried a seq[any] |
| 23:12:45 | zahary | aha, this as param? this is intended to work indeed, file a bug |
| 23:14:30 | zahary | btw, seq[any] is equivalent to just seq |
| 23:14:30 | zahary | proc foo(x: seq) = |
| 23:16:20 | Vladar | I mean, when you declare is as var, it should tell you where you messed up. |
| 23:17:02 | zahary | any case of internal error should be fixed in general :) |
| 23:18:04 | Vladar | it got me some time to figure out why it throws this error on me ) |
| 23:19:33 | Vladar | zahary, also, just tried foo(x: seq) and it says: Error: invalid type: 'proc (seq)' |
| 23:20:24 | Vladar | and with foo(x: seq[any]) : Error: ambiguous identifier: 'any' -- use a qualifier |
| 23:20:30 | zahary | hmm, I think one of my test cases was using exacty this |
| 23:22:36 | * | JStoker quit (Excess Flood) |
| 23:23:20 | zahary | doesn't work for me too. I'll take a look later. |
| 23:24:41 | Vladar | I'll post a bugreport about it then |
| 23:31:32 | dom96 | Araq: Just remembered the big issue, the process output is not saved properly. |
| 23:32:05 | Araq | oh yeah ... :-/ |
| 23:32:24 | * | gradha quit (Quit: gradha) |
| 23:33:35 | * | q66 quit (Quit: Quit) |
| 23:48:59 | Araq | zahary: you need to teach 'types.typeAllowed' about implicit generic types like standalone 'seq' |
| 23:48:59 | * | ponce joined #nimrod |
| 23:49:11 | Araq | wb ponce |
| 23:49:11 | zahary | I know |
| 23:49:18 | ponce | hi Araq |
| 23:49:32 | ponce | it's this time of the year :) |
| 23:49:44 | ponce | I was wondering about vector instruction support in Nimrod |
| 23:49:57 | ponce | (not asking anything in particular of course) |
| 23:50:31 | Araq | I've seen some benchmarks where nimrod was faster than C because it relied on GCC to auto vectorize |
| 23:50:32 | * | JStoker joined #nimrod |
| 23:50:50 | Araq | whereas the C version used explicit instructions ... |
| 23:50:56 | ponce | eh |
| 23:51:27 | Araq | but it's all an 'importc' away anyway |
| 23:51:36 | ponce | there is often some #pragma that might be useful in some C++ compilers |
| 23:51:54 | ponce | right |
| 23:52:40 | ponce | can importc pragma node be generated by Nimrod macros? |
| 23:53:15 | ponce | (is it even reasonable to expect that?) |
| 23:59:45 | Araq | you can do that, yes |