00:00:01 | * | dapz joined #nimrod |
00:02:05 | * | fowl joined #nimrod |
00:19:11 | * | xenagi joined #nimrod |
00:20:29 | * | fowl quit (Ping timeout: 260 seconds) |
00:23:17 | * | fowl joined #nimrod |
00:33:07 | * | bjz quit (Ping timeout: 245 seconds) |
00:33:52 | * | Sht0 quit (Ping timeout: 272 seconds) |
00:49:01 | Onionhammer | dom96 no, I want kqueue! :P |
00:49:18 | dom96 | implement it then :P |
00:54:57 | * | francisl joined #nimrod |
00:58:23 | Onionhammer | dom96 |
00:58:30 | Onionhammer | i think it's actually a capitalization issue |
00:58:33 | Onionhammer | not an osx issue |
00:59:04 | Onionhammer | it's looking for FD_SET, but it's declared as proc fdSet |
01:02:30 | * | dapz quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
01:09:16 | dom96 | yes. |
01:09:20 | dom96 | Just change it and see if it works. |
01:09:55 | * | q66 quit (Quit: Leaving) |
01:11:38 | Onionhammer | dom96 change 1 thing = fix 5 more things |
01:11:42 | Onionhammer | etc etc etc |
01:16:18 | dom96 | you just need to rename some stuff |
01:16:21 | dom96 | it's not that hard |
01:19:42 | * | dom96 quit (Excess Flood) |
01:21:06 | * | dom96 joined #nimrod |
01:31:35 | Onionhammer | yeah, its just time consuming, and time is a limited comodity |
01:44:47 | * | fowl quit (Ping timeout: 245 seconds) |
01:55:13 | * | icebattl1 quit (Quit: leaving) |
01:59:09 | * | fowl joined #nimrod |
02:27:16 | * | adrusi joined #nimrod |
02:29:49 | * | Sht0 joined #nimrod |
02:46:35 | * | BlameStross left #nimrod (#nimrod) |
02:49:19 | * | francisl quit (Quit: francisl) |
03:00:38 | * | askatasuna quit (Quit: WeeChat 1.0) |
03:22:25 | * | fowl quit (Ping timeout: 272 seconds) |
03:37:36 | * | wkoch joined #nimrod |
03:39:54 | * | wkoch quit (Remote host closed the connection) |
04:24:53 | * | adrusi quit (Quit: adrusi) |
04:25:05 | * | adrusi_ joined #nimrod |
04:25:05 | * | adrusi_ is now known as adrusi |
04:29:56 | * | ARCADIVS joined #nimrod |
04:32:08 | * | adrusi quit (Quit: adrusi) |
04:32:32 | * | adrusi joined #nimrod |
04:32:54 | * | adrusi quit (Client Quit) |
04:33:15 | * | Demos quit (Read error: Connection reset by peer) |
04:54:12 | * | flaviu1 quit (Ping timeout: 246 seconds) |
05:10:27 | * | xenagi quit (Read error: Connection reset by peer) |
05:15:24 | * | gsingh93 joined #nimrod |
05:51:01 | * | gsingh93 quit (Ping timeout: 272 seconds) |
05:51:10 | * | endou_____ quit (Read error: Connection reset by peer) |
05:51:11 | * | clone1018 quit (Ping timeout: 272 seconds) |
05:51:14 | * | zlinn_ quit (Write error: Connection reset by peer) |
05:51:25 | * | TylerE quit (Ping timeout: 260 seconds) |
05:51:48 | * | CARAM quit (Ping timeout: 260 seconds) |
06:10:23 | * | noam_ joined #nimrod |
06:12:55 | * | clone1018 joined #nimrod |
06:13:20 | * | gsingh93 joined #nimrod |
06:13:37 | * | endou_____ joined #nimrod |
06:14:03 | * | noam quit (Ping timeout: 272 seconds) |
06:15:08 | * | TylerE joined #nimrod |
06:16:14 | * | zlinn_ joined #nimrod |
06:17:22 | * | CARAM joined #nimrod |
06:48:49 | * | rg4 quit (Ping timeout: 272 seconds) |
07:08:32 | * | bjz joined #nimrod |
07:13:58 | * | BlaXpirit joined #nimrod |
07:34:28 | * | dapz joined #nimrod |
07:44:46 | * | nimrod joined #nimrod |
07:45:10 | * | nimrod is now known as Guest82625 |
07:45:49 | * | Guest82625 quit (Client Quit) |
08:06:07 | * | Varriount|Mobile joined #nimrod |
08:09:51 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
08:25:36 | * | Matthias247 joined #nimrod |
08:32:01 | * | tdc joined #nimrod |
08:41:44 | * | dapz quit (Quit: Textual IRC Client: www.textualapp.com) |
09:09:17 | * | noam__ joined #nimrod |
09:12:58 | * | noam_ quit (Ping timeout: 258 seconds) |
09:17:41 | * | BitPuffin quit (Ping timeout: 260 seconds) |
09:29:21 | * | tdc quit (Quit: Leaving) |
09:29:35 | * | tdc joined #nimrod |
09:29:59 | * | tdc is now known as Guest8783 |
09:30:08 | * | Guest8783 quit (Remote host closed the connection) |
09:30:18 | * | tdc_ joined #nimrod |
09:31:24 | * | tdc_ quit (Remote host closed the connection) |
09:42:06 | * | tdc_ joined #nimrod |
09:44:14 | * | tdc_ is now known as tdc |
09:50:16 | * | Sht0 quit (Ping timeout: 260 seconds) |
09:50:18 | * | bjz quit (Quit: Textual IRC Client: www.textualapp.com) |
09:50:32 | * | bjz joined #nimrod |
09:54:28 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
10:18:21 | * | bjz quit (Ping timeout: 260 seconds) |
10:21:46 | * | bjz joined #nimrod |
10:27:44 | * | q66 joined #nimrod |
10:34:31 | * | vendethiel joined #nimrod |
10:34:36 | * | tdc quit (Ping timeout: 260 seconds) |
10:38:49 | * | kuzy000_ joined #nimrod |
10:57:28 | * | Trustable joined #nimrod |
11:19:23 | * | Ven joined #nimrod |
11:36:56 | * | brovador joined #nimrod |
11:38:56 | * | brovador quit (Client Quit) |
11:59:07 | * | noam__ is now known as noam |
12:18:09 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
12:35:49 | * | Ven joined #nimrod |
12:44:07 | * | ARCADIVS quit (Quit: WeeChat 0.4.3) |
12:57:01 | * | untitaker quit (Ping timeout: 260 seconds) |
13:03:34 | * | untitaker joined #nimrod |
13:10:22 | * | Fran__ is now known as Fr4n |
13:36:41 | * | flaviu1 joined #nimrod |
13:49:25 | * | flaviu1 quit (Ping timeout: 272 seconds) |
13:55:49 | * | rg4 joined #nimrod |
13:57:52 | * | untitaker quit (Ping timeout: 240 seconds) |
14:04:10 | * | untitaker joined #nimrod |
14:13:33 | * | darkf quit (Quit: Leaving) |
14:14:11 | * | tdc joined #nimrod |
14:42:41 | * | rg4 quit (Quit: WeeChat 1.0) |
14:45:39 | * | rg4 joined #nimrod |
14:45:55 | * | francisl joined #nimrod |
15:01:20 | * | tdc quit (Quit: Leaving) |
15:01:26 | wan | I've just watched Jonathan Blow talk about his ideas for a new programming language for games: https://www.youtube.com/watch?v=TH9VCN6UkyQ |
15:02:13 | wan | He talks about why he wants something to replace C++, and why (for him, at the moment) D, Go and Rust don't fit the bill yet |
15:02:48 | wan | I'm not sure if he encountered Nim yet |
15:03:25 | wan | (btw, this is the developer of Braid. He is a famous indie dev) |
15:05:33 | wan | Nim has a lot of what he's asking for. However, I don't know how we can do joint allocation |
15:18:43 | * | Sht0 joined #nimrod |
15:24:53 | dom96 | wan: Indeed, you should suggest it to him. |
15:25:56 | dom96 | Why doesn't Rust fit the bill for him? |
15:31:29 | * | milosn quit (Ping timeout: 260 seconds) |
15:51:55 | * | Matthias247 quit (Read error: Connection reset by peer) |
15:54:14 | wan | He feels good about variable ownership, but not the way Rust thinks it. He also feels like Rust might be a 'big idea' language (no unsafe things!) and says that they usually are unproven (unproven benefits: does it have drawbacks?) although he knows that he can unsafe{...} things. |
15:55:48 | * | bogen joined #nimrod |
16:00:04 | * | flaviu1 joined #nimrod |
16:03:05 | Varriount | wan, dom96: But what about threading? |
16:05:14 | * | flaviu1 quit (Remote host closed the connection) |
16:07:31 | * | milosn joined #nimrod |
16:10:20 | wan | I don't remember him talking much about threading. That probably means that he's somewhat content with how to use threads in C/C++, and don't plan on using risky (unproven performance) light thread models |
16:10:49 | Varriount | wan: Yes, but Nimrod's threading support is somewhat... restrictive |
16:12:12 | wan | In what way? |
16:12:51 | Varriount | You can't just share objects and data between threads willy-nilly |
16:14:10 | wan | Well if there is still threadAnalysis:off, there's a workaround. |
16:22:47 | * | flaviu1 joined #nimrod |
16:25:46 | * | fowl joined #nimrod |
16:38:10 | * | Trustable quit (Remote host closed the connection) |
16:57:33 | flaviu1 | `_type` isn't a valid identifier :/ |
17:26:35 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
17:37:21 | * | Ven joined #nimrod |
17:37:54 | * | TieSoul quit (Read error: Connection reset by peer) |
17:41:36 | * | Sht0 quit (Ping timeout: 260 seconds) |
17:56:00 | Araq | Varriount: Nim's threading support is just fine, especially for games |
17:56:20 | Araq | well once I finished the incredibly good fork&join support |
17:56:36 | * | demilichsd quit (Ping timeout: 258 seconds) |
18:04:06 | * | will joined #nimrod |
18:08:31 | Triplefox_ | Jon blow is unlikely to ever accept garbage collection, he retreats to arguments about top end performance every time the subject comes up. So to sell him on nim would take a carefully constructed argument that would reassure him that collection won't impact him like in other languages |
18:09:57 | * | demilichsd joined #nimrod |
18:10:45 | Araq | Triplefox_: *shrug* |
18:10:59 | Araq | you can use manual memory management just fine in Nim |
18:11:35 | Triplefox_ | Yeah, it's just the existence of the stuff tends to be a scare point |
18:12:01 | Triplefox_ | Especially if it's used throughout libraries |
18:14:05 | Triplefox_ | If course, c++ already has a similar issue in that library authors will use different subsets |
18:15:05 | Araq | bbl |
18:18:46 | * | flaviu1 quit (Read error: No route to host) |
18:22:45 | * | gsingh93 joined #nimrod |
18:28:50 | * | Matthias247 joined #nimrod |
18:31:09 | shodan45 | heh, was going to post that Jonathan Blow video last night, but everyone seemed to be sleeping |
18:33:21 | shodan45 | I think he made some very good points, but I disagreed on one or 2 fundamental points |
18:40:01 | shodan45 | games don't always have to have extreme performance, see Minecraft or even his own game Braid |
18:40:46 | Ven | shodan45: to be fair, the only reason minecraft wasn't rewrote in a lower-level language is that its whole success is based on plugins |
18:40:56 | Triplefox_ | Yeah, see, that's exactly what he dismisses |
18:41:40 | Triplefox_ | He tends to get evasive in Twitter arguments when points like that are made |
18:43:01 | shodan45 | obviously, some games (or heck, any kind of application) do push boundaries of what's possible |
18:45:12 | shodan45 | but in that case, wouldn't a good programmer use hacks to increase performance in any language? |
18:45:53 | * | EastByte_ is now known as EastByte |
18:46:04 | Trixar_za | With me that's more habit than personal pride |
18:50:31 | shodan45 | Nimrod does seem like a pretty good fit for what he's describing, though |
18:56:25 | shodan45 | I haven't been keeping up with nimrod for the last ~2 months... what have I missed? |
18:56:51 | shodan45 | I saw something about changing the name to just "nim" |
18:57:30 | Triplefox_ | Yeah, that is the new name |
18:57:35 | shodan45 | and something about changing to case-sensitive |
18:58:01 | * | TieSoul joined #nimrod |
18:58:29 | Trixar_za | wait - what? |
19:09:32 | bogen | partially case sensitve |
19:09:49 | bogen | but that will be able to be disabled as far as I know |
19:17:23 | * | dom96 quit (Excess Flood) |
19:18:39 | * | dom96 joined #nimrod |
19:35:14 | * | vendethiel quit (Ping timeout: 272 seconds) |
19:46:50 | * | Jehan_ joined #nimrod |
19:50:19 | * | vendethiel joined #nimrod |
19:56:15 | * | Mat3 joined #nimrod |
19:56:17 | Mat3 | hello |
19:57:15 | dom96 | hi |
20:02:05 | Mat3 | hi dom96 |
20:07:19 | * | vissborg joined #nimrod |
20:15:36 | * | Jesin joined #nimrod |
20:25:04 | * | starless joined #nimrod |
20:25:07 | Onionhammer | heh, in that talk he does want "compile time functions in the same language" |
20:25:09 | Onionhammer | :) |
20:25:29 | shodan45 | Onionhammer: yep! |
20:26:04 | shodan45 | quite a few things he said made me yell "nimrod" at the screen ;) |
20:26:42 | shodan45 | it was surprisingly good for being so long |
20:27:07 | shodan45 | although it was more or less over at 90 minutes in |
20:30:32 | Jehan_ | What talk are you guys talking about? |
20:31:01 | shodan45 | Jehan_: https://www.youtube.com/watch?v=TH9VCN6UkyQ |
20:31:28 | Jehan_ | Ah, Jonathan Blow's. Yeah, I watched it. |
20:31:57 | Jehan_ | I was happy to finally hear someone else say that RAII is not actually a good idea. |
20:33:12 | Mat3 | sorry, what_s RAII ? |
20:33:40 | Jehan_ | Mat3: http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization |
20:34:03 | Triplefox_ | It's a nice pattern for the things it solves |
20:34:05 | Jehan_ | I'd describe the issues differently, though. |
20:34:15 | Triplefox_ | Which i agree aren't that big for games |
20:34:37 | * | xenagi joined #nimrod |
20:35:21 | Jehan_ | In my opinion, the presence of RAII is generally evidence that the language lacks automatic memory management and higher-order functions. RAII is also fundamentally at odds with concurrency except for simple cases. |
20:36:26 | Jehan_ | Even if you can't do automatic memory management (as he says), RAII is a bad choice for a poor man's garbage collector. |
20:38:25 | Jehan_ | Even if you want to do basic reference counting for memory counting, at the very least you need compiler support if you don't want either (1) huge runtime overhead or (2) blow up the code footprint (what he's talking about in the video, also known as the Rule of Three (which should by now be the Rule of Five)). |
20:39:22 | Triplefox_ | I feel like a lot of what the folks looking for precise control need are "lifetime patterns" built in the language... terse ways to describe the strategy they're using |
20:39:51 | Jehan_ | Triplefox_: That's what higher order functions are for. |
20:40:59 | Triplefox_ | Well, that's a general construct that does it, but if you're using the same handful of patterns in the code... |
20:42:03 | EXetoC | but isn't RAII used for semantics too? |
20:42:34 | shodan45 | sorta like python's "with" statement |
20:42:51 | shodan45 | (don't remember if nimrod has that) |
20:43:13 | EXetoC | except then it might not exactly be RAII |
20:44:08 | Jehan_ | shodan45: There's no need for a separate with statement if your language has proper support for higher order functions. |
20:45:07 | Jehan_ | shodan45: You can write the with statement in Nim as a procedure or template, for example. |
20:45:37 | Jehan_ | Smalltalk never had a with statement, because blocks are a key element of the language, so it was never necessary. |
20:45:50 | Triplefox_ | I don't disagree that the semantics of higher order are helpful, i just think that people coming in anew want to be pointed to a standard library of them |
20:46:08 | shodan45 | sure.... "with" isn't strictly necessary in python, either |
20:48:23 | Jehan_ | Triplefox_: Yeah, but the same holds for RAII. |
20:48:40 | Jehan_ | shodan45: The issue in Python is that it doesn't allow for closures that are inline statements. |
20:49:02 | Jehan_ | You can do closures that are expressions, and you can do closures that are explicit defs. |
20:49:28 | shodan45 | python doesn't do many things.... some would say that's a good thing ;) |
20:49:56 | Jehan_ | shodan45: The problem here is not that it doesn't do them, it's that what it does is incomplete. |
20:50:16 | Jehan_ | The functionality is already there with `lambda`, it's just that `lambda` is too limited. |
20:50:51 | Jehan_ | And as a result, Python actually got MORE features (with statements, and arguably iterators). |
20:51:05 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
20:51:29 | Jehan_ | I note that iterators are not equivalent to closures (since you need continuations to implement them fully), but they have a lot of overlapping use cases. |
20:51:53 | Mat3 | well, /me thinks tacit programming is an universal solution by design to the problem RAII adresses as extension |
20:54:07 | * | Ven joined #nimrod |
21:20:47 | * | Mat3 quit (Quit: Verlassend) |
21:21:30 | * | Jesin quit (Quit: Leaving) |
21:23:04 | * | Jesin joined #nimrod |
21:23:24 | * | Demos joined #nimrod |
21:32:41 | * | rg4 quit (Ping timeout: 260 seconds) |
21:37:18 | * | tillzy joined #nimrod |
21:47:27 | Araq | bogen: --cs:partial is effectively not an option |
21:47:55 | Araq | libraries can and will export both Foo and foo and then you have no choice but to enable it |
21:48:27 | Araq | however ... I'm playing with better symbol disambiguation |
21:48:49 | Araq | so that --cs:partial won't be necessary to support what people want |
21:50:00 | Araq | but I'm also not a fan of "the compiler resolves it completely different than the ordinary programmer" |
21:50:20 | Jehan_ | I think the biggest problem is that in Nim's syntax type names can occur in the same places that other identifiers do. |
21:50:21 | * | fowl quit (Ping timeout: 260 seconds) |
21:50:59 | Jehan_ | That's a convenience feature (so you can write int(foo)), but it means you need a way to disambiguate between types and variables/procedures/templates. |
21:51:28 | Araq | Jehan_: it's however also essential for a macro system |
21:51:33 | Jehan_ | Araq: Yeah. |
21:52:16 | Araq | we could require type.Foo for "type context following" |
21:52:20 | Jehan_ | Iv'e been wondering if it could be possible to have types and non-types of the same name and have a different mechanism to disambiguate between them. |
21:52:39 | Jehan_ | If it can't be deduced from the context, with a specific annotation. |
21:52:44 | Araq | yeah and it's quite easy to do |
21:52:50 | * | rg4 joined #nimrod |
21:53:10 | Araq | but I don't think it's acceptable |
21:53:23 | Araq | initTable[type.int]() |
21:53:28 | Araq | vs |
21:53:33 | Araq | initTable[int]() |
21:54:02 | Jehan_ | Well, the idea would be to only use the explicit annotation where the compiler can't infer which is which. |
21:54:17 | Araq | ok that can work |
21:54:50 | Jehan_ | I have no idea how much that would complicate the implementation, though. |
21:55:23 | Araq | well not that much |
21:55:46 | Araq | I need to go through the code anyway to fix some nasty corner case bugs |
21:56:07 | * | Matthias247 quit (Read error: Connection reset by peer) |
21:57:21 | Araq | but as I said, it seems bad that the programmer looks at the case of the first char to determine what is meant |
21:57:30 | Araq | and the compiler does something very different |
21:57:43 | Araq | and might come to the same conclusions |
21:57:58 | Araq | almost always unless it doesn't |
21:58:26 | Araq | and then you have to write type.Foo |
21:59:30 | Araq | it's hard to justify such a design, isn't it? |
21:59:35 | * | johnsoft quit (Ping timeout: 272 seconds) |
22:00:14 | * | fowl joined #nimrod |
22:00:15 | Jehan_ | Hmm, if I try to actually use type.int(x), then the compiler segfaults. |
22:00:19 | * | fowl quit (Changing host) |
22:00:19 | * | fowl joined #nimrod |
22:00:45 | Araq | ok that's a bug of course |
22:00:59 | Araq | but type.Foo is only the suggested syntax |
22:01:04 | Araq | it's not been implemented |
22:01:05 | Jehan_ | Yeah, wasn't a complaint. I just thought I should mention it. |
22:01:11 | Araq | sure |
22:01:12 | Jehan_ | Gotcha. |
22:01:22 | Jehan_ | I thought it was an existing feature that I had been unaware of. |
22:03:51 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:05:59 | * | Ven joined #nimrod |
22:06:22 | * | ehaliewicz joined #nimrod |
22:06:29 | * | tillzy quit (Quit: tillzy) |
22:07:50 | ehaliewicz | are blocks lexically bound inside closures? |
22:08:22 | ehaliewicz | for example, if i declare a block, and inside that block create a closure that breaks from that block |
22:08:34 | ehaliewicz | nvm that doesn't make sense |
22:08:56 | ehaliewicz | maybe it makes sense as long as the closure doesn't leave that scope :) |
22:10:00 | ehaliewicz | doesn't look like it works |
22:10:15 | Araq | closures cannot 'break' outer loops |
22:10:26 | ehaliewicz | ah, ok |
22:10:32 | ehaliewicz | i don't know if there's much use when you have exceptions |
22:10:34 | ehaliewicz | just curious |
22:10:35 | Araq | it's also not necessary, you can use a template instead |
22:11:32 | ehaliewicz | well i was thinking more of a continuation sort of thing |
22:11:40 | ehaliewicz | but again, exceptions are probably what i'm looking for |
22:11:40 | Araq | in fact, that fine grained interaction with control flow is the most important reason why templates even exist |
22:13:13 | Araq | Jehan_: btw I'm implementing a 'guard' annotation |
22:13:25 | Jehan_ | Araq: which does what? |
22:13:32 | Araq | var foo {.guard: LockL.}: int |
22:13:40 | Araq | echo foo # invalid |
22:13:49 | Araq | lock LockL: echo foo # valid |
22:14:21 | Araq | well |
22:14:36 | Araq | top level accesses are assumed to be constructions |
22:14:42 | Araq | so are not prevented |
22:15:27 | Araq | it's all very easy to implement |
22:15:44 | Araq | and as you said, equivalent to the 'not nil' checking |
22:15:55 | Jehan_ | Checked at compile time or runtime? |
22:16:03 | Araq | compile-time |
22:16:33 | Jehan_ | I take it that you can't use that for heap-allocated data, then? |
22:17:40 | Araq | surely you can |
22:17:55 | Araq | the annotation then belongs to a field of an object |
22:18:04 | Araq | type Foo = object |
22:18:18 | Araq | i [.guard: L.}: int |
22:18:24 | Araq | L: Lock |
22:18:32 | Jehan_ | Oh, I see. |
22:18:40 | * | Jesin quit (Quit: Leaving) |
22:19:04 | Araq | that replaces the idea of a 'guarded ptr' |
22:19:22 | * | kuzy000_ quit (Ping timeout: 245 seconds) |
22:19:29 | Araq | it's so simple to implement that I decided to do it for 0.9.6 |
22:19:32 | Jehan_ | Are you requiring a specific implementation for locks or just one that conforms to a certain type signature? |
22:20:02 | Araq | not even that, it doesn't require any particular type |
22:20:14 | Araq | there is some other pragma that works like this: |
22:20:21 | Jehan_ | Also, does it purely allow for mutexes or read-write locks also at this point? |
22:20:39 | Jehan_ | Hmm, if it doesn't require anything, how do you check it? |
22:20:48 | Araq | {.locks: [c.L].}: |
22:20:49 | Araq | inc c.i |
22:21:06 | Araq | where c is of the Foo type defined above |
22:21:15 | Jehan_ | I see. |
22:21:23 | Araq | the trick is that the .locks pragma shouldn not be used directly |
22:21:24 | * | fowl quit (Ping timeout: 246 seconds) |
22:21:35 | Araq | but it's used all various kinds of lock templates |
22:21:45 | Jehan_ | That's a pretty general mechanism and probably also useful for other use cases. |
22:21:58 | * | fowl joined #nimrod |
22:22:08 | Araq | yeah, I love it |
22:22:21 | Araq | it's simple, general and thus powerful |
22:25:08 | Araq | in contrast the deadlock prevention requires some builtin notion of the Lock[Locklevel] type |
22:25:15 | Araq | the idea of valid lock nestings |
22:25:24 | Araq | and some addition to the effect system |
22:25:58 | Araq | so I don't think it'll make it into 1.0 |
22:26:24 | Jehan_ | Deadlock prevention is tricky. |
22:26:41 | Jehan_ | There's a spectrum of possible solutions and each of them has drawbacks. |
22:26:45 | Demos | deadlocks are some of the more obvious threading errors though, which is nice |
22:27:18 | Jehan_ | At the one extreme you get the case where it's too strict and gets into your way of writing code, at the other extreme it's too permissive and you have a hard time testing for bugs. |
22:27:44 | Araq | Jehan_: now I think the most common deadlock is due to a condition variable where the condition never holds |
22:28:00 | Araq | which my deadlock prevention design doesn't address at all |
22:28:11 | Jehan_ | I designed a system to eliminate deadlocks in my Ph.D. thesis, but the problem was that it left a pretty huge footprint on the language and (to a lesser degree) on the modules involved. |
22:28:25 | Jehan_ | Araq: Yes, system level vs. application level deadlock. |
22:28:37 | Jehan_ | You can't really solve the latter without solving the halting problem. |
22:28:46 | Jehan_ | What you CAN do is provide means to recover from it. |
22:29:19 | Araq | what we *could* do for version 1.0 is to warn when lock statements are nested |
22:29:39 | Araq | perhaps in some subtle fashion |
22:29:42 | Jehan_ | That said, you'd be surprised how often nested locking can bite you. |
22:30:09 | Jehan_ | At the same time, sometimes you need some form of nested locking that's not amenable to a simple deadlock prevention algorithm. |
22:30:33 | * | Samson__ joined #nimrod |
22:30:40 | Araq | hi Samson__ welcome |
22:31:14 | Araq | yeah well in general I have simpler use cases than you in mind, I think |
22:31:41 | * | Samson__ quit (Client Quit) |
22:31:50 | Araq | but I've done some analysis in a big system |
22:32:17 | Araq | and ended up to avoid nesting and instead recompute parts of the algorithm instead |
22:32:29 | Araq | to ensure deadlock freedom |
22:32:33 | Jehan_ | Araq: As long as you have an escape mechanism, you're generally going to be fine. |
22:32:50 | Araq | I had no escape mechanism |
22:33:09 | Araq | I also had no multi-lock statement |
22:33:16 | Jehan_ | Most recently, I simply implemented a hierarchy and allowed programmers to have locks that ignored the hierarchy. |
22:33:26 | Araq | instead I rewrote the algorithm |
22:40:30 | Araq | Jehan_: what do you think about a define that simply injects the lock implementation with a global timeout? |
22:41:46 | Jehan_ | Araq: A timeout won't really help you, because the typical implementation is "while not foo: wait(condvar, mutex)" |
22:42:19 | Jehan_ | Unless you let the timeout raise an exception, which can be dangerous. |
22:42:42 | Araq | yeah but that's what I had in mind |
22:42:54 | Araq | acquire essential is then tryAcquire |
22:43:01 | Araq | *essentially |
22:43:29 | Jehan_ | If you do that, you need a mechanism to clean up locks that are still being held. |
22:43:39 | * | BlaXpirit quit (Quit: Quit Konversation) |
22:43:40 | Jehan_ | Or you'll just amplify your problems. |
22:44:13 | Jehan_ | Concurrent code running into undefined behavior is a really sticky issue. |
22:44:22 | Araq | well the release should really be in a 'finally' anyway? |
22:44:48 | Jehan_ | Ideally, you shouldn't work with mutexes and condvars directly, but only through higher level abstractions. |
22:45:02 | Jehan_ | Araq: Not all uses of locks are scoped. They often cannot be. |
22:46:24 | Jehan_ | Which keeps bringing me back to that one design I have in mind that would not only resolve this issue but also make deadlocks impossible. I'm not sure if the costs are worth it. |
22:47:02 | Jehan_ | It basically comes down to any blocking or potentially blocking operation releasing all currently held locks. |
22:47:32 | Jehan_ | And yes, you can design language features so that this is reasonably safe. |
22:49:05 | Jehan_ | Essentially, when you're trying to acquire a new lock, you (conceptually, optimizers can often avoid this) first release all acquired locks, then reacquire them as one single multilock statement. |
22:49:25 | Jehan_ | Any blocking operation temporarily releases all held locks, then reacquires them atomically. |
22:49:47 | Jehan_ | The tricky part is that it's hard to write abstractions over this. |
22:50:12 | Jehan_ | You need to basically annotate functions to say "this function may spontaneously allow other threads access to shared state". |
22:50:22 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
22:50:42 | Jehan_ | Which raises some ugly composability issues. |
22:51:09 | Jehan_ | They can be sidestepped through other mechanisms, but never fully eliminated. |
22:52:39 | Araq | interesting |
22:53:01 | Araq | this is what the first deadlock avoidance mechanism did |
22:53:08 | Araq | that I implemented for nim |
22:53:14 | Araq | but I'm sure you remember |
22:58:12 | * | johnsoft joined #nimrod |
22:59:55 | Araq | Jehan_: one problem that I have with "this is overly restrictive, I know there can be no deadlock here" line of reasoning is that really in general you don't |
23:00:23 | Jehan_ | Araq: By that I mean that you can't have system level deadlock. |
23:00:26 | Araq | you think you do know better and that you don't need hierarchical locking |
23:00:31 | Jehan_ | And you can break application level deadlock safely. |
23:00:36 | * | Varriount quit (Ping timeout: 246 seconds) |
23:00:56 | Araq | but if you can't do it in a formal way that the type system requires you to do |
23:01:11 | Araq | you often really got it wrong in a subtle way |
23:01:28 | Jehan_ | Araq: Not sure what you mean? |
23:02:01 | Araq | I mean if we do the lock level implementation as I suggested in my blog post |
23:02:16 | Araq | then there will be lots of cases where it's simply annoying |
23:02:23 | Araq | and overly restrictive |
23:02:43 | Araq | but I don't know if/how exactly you know for sure what you did is safe |
23:03:24 | Araq | if you don't follow the rules that the formal lock level system implies |
23:05:08 | Jehan_ | Okay, now I understand. I thought you were talking about my half-baked idea. |
23:05:25 | Jehan_ | But yeah, you're right. This stuff is hard to understand. |
23:06:04 | Jehan_ | At the same time, if you need to, you CAN specify formal invariants to show that deadlocks can't occur in systems where a simple nesting-based scheme can't decide that. |
23:06:22 | * | fowl quit (Ping timeout: 240 seconds) |
23:06:24 | * | tillzy joined #nimrod |
23:08:38 | Araq | Jehan_: yeah sure but I claim these are |
23:08:42 | Araq | (a) rare |
23:08:51 | Jehan_ | Yes, they are. |
23:09:02 | Araq | (b) not really stable once you consider refactoring in the real world |
23:09:17 | Jehan_ | Which is why I think a simple way of deadlock prevention with an escape hatch is a good compromise. |
23:09:26 | Araq | (c) circumventable via 'cast' just like everything else |
23:09:35 | Jehan_ | With the understanding that the escape hatch is to be used rarely. |
23:09:49 | Jehan_ | As I said, that's pretty much what I went for. |
23:17:22 | * | imjoe` quit (Ping timeout: 245 seconds) |
23:17:32 | * | fowl joined #nimrod |
23:20:52 | * | hsuh quit (Ping timeout: 240 seconds) |
23:22:30 | * | hsuh joined #nimrod |
23:28:56 | Araq | Jehan_: ok, but what does that mean? lock levels should be done eventually? or is the deadlock avoidance at runtime preferable? |
23:29:41 | Jehan_ | Araq: I don't think there's a "best" implementation there. |
23:30:00 | Jehan_ | If you have a hierarchy of lock levels that is too limited, you CAN run into problems. |
23:30:11 | starless | Jesus Christ. implicit return values? why?? |
23:30:18 | starless | me and nimrod were getting on so well |
23:30:39 | Jehan_ | starless: What do you mean by "implicit return values"? |
23:31:06 | starless | proc boo(): bool = |
23:31:09 | starless | discard |
23:31:11 | starless | returns false |
23:31:13 | starless | no error |
23:31:52 | Jehan_ | Ah, I see. |
23:32:25 | starless | I have never been so shocked. Nimrod is so well designed. |
23:32:43 | * | darkf joined #nimrod |
23:32:54 | Jehan_ | The implicit "result" variable is an Eiffel/Pascal concept. It has its advantages and disadvantages. |
23:33:34 | Jehan_ | Eiffel has it because Eiffel is pretty strict about control flow. There's no goto, break, continue in Eiffel, and thus, also no return. |
23:33:56 | Jehan_ | In other Pascal-like languages, it's discourage also. |
23:34:16 | Jehan_ | So, there needs to be a different way to return the value. |
23:34:53 | Jehan_ | The real "problem", though, is that you can use a variable without having initialized it explicitly. |
23:35:09 | Triplefox_ | i tend to use "result" as my return variable everywhere after using Pascal for a while :D |
23:35:10 | Jehan_ | This, again, has advantages and disadvantages. |
23:35:28 | Jehan_ | Triplefox_: Yeah, my C code usually has a result variable and returns it at the end. |
23:36:47 | starless | So what are the advantages? |
23:36:54 | starless | The disadvantages are glaring at me right now. |
23:37:51 | * | xenagi quit (Quit: Leaving) |
23:40:29 | Jehan_ | One disadvantage of requiring explicit initialization is that it requires flow control analysis, which complicates the language in other ways. |
23:41:15 | Jehan_ | For example: if condition: result = … else: signalError() # raises an exception is safe, but the compiler can't tell. |
23:42:24 | Jehan_ | You could require that you always initialize result before branching, but then programmers would just stick the default value in, anyway. |
23:42:40 | Jehan_ | Which buys you nothing but wastes vertical screen real estate. |
23:45:45 | starless | I guess I'd have to be a language designer to understand. |
23:46:25 | Araq | starless: there is a way to activate what you want, but iirc not for 'result' |
23:47:02 | Araq | can you gist me your real world example how the features bite you? |
23:47:29 | Araq | cause IME the disadvantages are obvious, but also irrelevant |
23:48:41 | Jehan_ | Oh, I forgot another reason why Eiffel has a result variable (somewhat tangential), and that is to be able to express postconditions involving the return value. |
23:48:46 | starless | Araq: anytime I reach the end of a procedure without returning a value I get a default value for the data type |
23:49:16 | Araq | starless: yes and it's an idiom |
23:49:30 | Araq | I use it everywhere |
23:49:45 | Jehan_ | starless: I think what he's asking if that this is actually likely to result in a software defect. |
23:50:13 | starless | Okay, so I was making a text adventure game to toy with the language |
23:50:18 | Jehan_ | Which I personally wouldn't know, one way or another. |
23:50:22 | starless | I prompted the user if they were a boy or a girl |
23:50:29 | starless | case of "yes"...of "no" |
23:50:37 | starless | I put "y" when I tested |
23:50:41 | starless | and it told me I was a girl |
23:50:47 | starless | (sorry, it asks if you are male) |
23:51:12 | starless | it's silly but I see that spiraling into bigger bugs |
23:51:16 | starless | maybe it's just my imagination |
23:51:52 | Jehan_ | I think the culprit here is that case for strings does not require an else clause as for other types. |
23:52:28 | starless | which I also disagreed with but it was marginally forgivable in the sense that you'd always have to give an "else" clause |
23:52:42 | starless | in retrospect perhaps it's not a good idea to make that "else" clause optional |
23:53:55 | Araq | yeah |
23:54:13 | Araq | many people complained about that for string cases |
23:54:25 | Araq | I can change that for bigbreak |
23:55:02 | ehaliewicz | just curious, are exceptions implemented via setjmp/longjmp in the c backend? |
23:55:05 | starless | bigbreak? |
23:56:00 | Jehan_ | ehaliewicz: Yes. |
23:57:30 | Jehan_ | Speaking of which, I see that it uses setjmp() over _setjmp() or sigsetjmp(). |
23:57:38 | * | BitPuffin joined #nimrod |
23:58:07 | starless | Araq: ping |
23:58:12 | starless | really curious |
23:58:18 | Jehan_ | That's probably not a good idea (setjmp() saves the procmask, which is considerable overhead). |
23:58:35 | Jehan_ | starless: bigbreak is the "breaking changes" branch. |
23:59:19 | starless | ah. okay. don't forget the on-site tutorial, then. it mentions strings not needed a default case. |
23:59:37 | starless | and thanks then, for your consideration, Araq. |
23:59:53 | starless | needing* |