| 00:00:44 | Araq | Jehan_: do you know why actors.nim is so slow? I never looked into it, cause it's crap either way |
| 00:01:10 | Jehan_ | Araq: No idea, I've never looked at it. |
| 00:01:33 | Jehan_ | Do you have an example that shows it being slow or is that just an impression? |
| 00:01:49 | Araq | well I benchmarked it against threads+channels once and it's like gradha says |
| 00:02:11 | Araq | got some speedup of 1.8 on a 4 core machine |
| 00:02:41 | Araq | and with threads+channels close to factor 4 |
| 00:02:48 | Jehan_ | There's honestly a lot that can go wrong. |
| 00:03:20 | Jehan_ | For example, it's pretty easy to write actor code that doesn't actually exploit all cores if actors sit idle a lot of the time. |
| 00:03:56 | Jehan_ | Write an actor system that simulates a token ring, as an extreme case, and you'll never get a speedup. |
| 00:04:20 | Jehan_ | Excessive blocking can also be a problem. |
| 00:04:41 | Araq | well according to gradha it's all in the 'sync' |
| 00:04:54 | Araq | which seems unrealistic |
| 00:05:18 | Araq | also I don't know if he profiled it properly / at all |
| 00:06:02 | Jehan_ | Hmm. Also, if each actor only executes short fragments of code, execution will be dominated by message passing overhead. |
| 00:07:24 | Araq | yeah well all this "light weight" concurrency doesn't make much sense to me |
| 00:08:40 | * | Boscop quit (Read error: Connection reset by peer) |
| 00:08:47 | * | flaviu joined #nimrod |
| 00:08:56 | Araq | it's not "light weight" on the hardware level and most PCs out there still have 4 cores or less |
| 00:08:57 | * | brson joined #nimrod |
| 00:09:05 | * | Boscop joined #nimrod |
| 00:09:16 | Jehan_ | Yup. |
| 00:09:58 | Jehan_ | It's really not possible with current hardware to efficiently break execution up in very small concurrent slices, except with compiler support. |
| 00:10:06 | * | superfunc quit (Ping timeout: 260 seconds) |
| 00:10:37 | Araq | not sure what a compiler can do here |
| 00:11:16 | Araq | most compilers are handicapped because there is no execution cost analysis anywhere |
| 00:11:35 | flaviu | just looking to learn here, what you consider lightweight concurrency/which model do you prefer? |
| 00:11:52 | Araq | and when functions are often block boxes, how can a compiler do any kind of cost analysis? |
| 00:12:00 | Araq | *black boxes |
| 00:13:29 | * | brson quit (Client Quit) |
| 00:13:37 | * | brson joined #nimrod |
| 00:15:32 | Jehan_ | Araq: It requires language support, too. Something like what, e.g., ParaSail does. |
| 00:20:59 | Araq | flaviu: usually a simple fork&join parallelism at the top level is enough to keep all the cores busy |
| 00:21:32 | Araq | you don't have to introduce micro parellelism everywhere and fight with its complexities |
| 00:21:43 | Araq | it depends on the domain of course |
| 00:22:08 | Araq | but I never had problems to use all the cores on a server |
| 00:22:41 | Araq | which you don't want to do anyway, usually it also runs other important things as well |
| 00:23:36 | Jehan_ | You also run into composability problems, which is another reason why fine-grained parallelism can be problematic. |
| 00:25:20 | Araq | or let's look at it this way: |
| 00:25:47 | Araq | say Mozilla re-implements Firefox in Rust and it runs good on your smart phone |
| 00:26:12 | Araq | and since it scales perfectly the browser is 16 times faster on your home PC |
| 00:26:43 | Araq | so ... |
| 00:27:00 | Araq | this either means it's too slow on phone |
| 00:27:23 | Araq | or you don't notice the 16x speedup on your PC at all |
| 00:27:38 | Araq | because it would be more than fast enough either way |
| 00:28:23 | Araq | IMO this means they spend a lot of effort for nothing |
| 00:31:49 | Jehan_ | Araq: That's a special case, though. |
| 00:32:57 | Jehan_ | And you can argue that it allows for, e.g., web apps that aren't really targeted at phone/tablet users. |
| 00:33:24 | Araq | yeah I guess |
| 00:34:42 | Araq | for web apps the JS stack is most important though |
| 00:35:32 | Araq | which is 1 component, you don't excessive parallelism everywhere to make it "scale" |
| 00:35:39 | Araq | *don't need |
| 00:46:47 | Jehan_ | Again, web browsers are really a special case. |
| 00:47:05 | Jehan_ | An important special case, but 99.99% of the world won't develop a web browser. |
| 00:47:49 | Jehan_ | Parallelism is pretty much always important for server-side stuff, HPC, and can be pretty important for desktop applications. |
| 00:48:01 | Jehan_ | Oh, and I finally saw gradha's post and wrote an answer. |
| 00:48:16 | Araq | flaviu: in general I don't think this "small actors that communicate via message passing" is a good way to do software engineering. This means Smalltalk-like OO, Erlang-like FP or microkernels in OS design are all misguided. The resulting systems are too hard to debug and reason about. Feel free to disagree. |
| 00:48:16 | Jehan_ | TLDR version: parallelizing os.sleep is an exercise in futility. |
| 00:48:40 | Araq | ah lol |
| 00:49:23 | Jehan_ | Araq: I know Erlang programmers who'd disagree, though arguably that's because of Erlang's superior VM. |
| 00:51:44 | Araq | let me guess: the erlang debugger gives you a global view over the system state ;-) |
| 00:52:30 | flaviu | My problem is that I want more-fine-grained than just top-level parallelism like you originally said, but I don't want to deal with shared memory |
| 00:53:02 | flaviu | I do like the idea of channels |
| 00:53:28 | Araq | but you do want to deal with shared memory: |
| 00:54:00 | Araq | merge(sort(a[0..x]), sort(a[x+1.. a.high])) |
| 00:54:14 | * | saml_ joined #nimrod |
| 00:54:47 | Jehan_ | Erlang doesn't have shared memory. |
| 00:55:12 | Jehan_ | It has really, really lightweight processes so that you can emulate shared memory via cheap RPC. |
| 00:55:21 | Araq | I didn't mean to imply that |
| 00:55:55 | Araq | it also has a builtin database for shared memory |
| 00:57:40 | Araq | Jehan_: well there is definitely a problem with the actors' implementation |
| 00:58:00 | Jehan_ | Araq: I wouldn't be surprised, I haven't had a close look at it. |
| 00:58:35 | Jehan_ | However, running gradha's example with a real worker thread did utilize all cores on my machine and seemed to have a reasonable speedup. |
| 01:00:05 | Araq | oh? with the actors module? ok then |
| 01:02:22 | Jehan_ | Araq: Yeah. |
| 01:03:04 | Jehan_ | I can't tell if there aren't perhaps more subtle problems or how efficient the message passing is without further investigation, though. |
| 01:03:14 | * | Trustable quit (Quit: Leaving) |
| 01:06:11 | Jehan_ | Araq: Is there a way to specialize generic implementations for entire type classes? |
| 01:07:01 | Araq | I don't think so |
| 01:07:18 | Araq | but I never played with type classes tbh |
| 01:08:34 | Jehan_ | I'm really mostly interested in having specialized implementations for all TSignedInt or such. |
| 01:08:48 | Araq | can you please run tests\parallel\tinvalid_array_bounds.nim ? |
| 01:09:01 | Jehan_ | With what version? devel? |
| 01:09:20 | Araq | yeah, any version is fine |
| 01:10:29 | Jehan_ | I get a compile error. |
| 01:10:38 | Jehan_ | tests/parallel/tinvalid_array_bounds.nim(16, 14) Error: (0)..(15) not disjoint from (i)..(i) |
| 01:10:49 | Araq | ok I get the same |
| 01:11:34 | Jehan_ | Specialized implementations: I can do overloading for each individual integral type, but that's a bit cumbersome. |
| 01:11:52 | Araq | yeah well we'll get it |
| 01:11:54 | Jehan_ | And doesn't allow me to do one for enums. |
| 01:12:05 | Jehan_ | It's nothing that's terribly critical. |
| 01:12:33 | Jehan_ | I need it to optimize serialization for common cases. |
| 01:12:53 | Jehan_ | where I can also use a `when` clause most of the time so far. |
| 01:13:23 | Araq | ok gotcha |
| 01:13:53 | Araq | damn ... why does it never say "can prove: i + 1 > 30" |
| 01:14:32 | Araq | I surely implemented that, why else would I have written this test? |
| 01:14:49 | Jehan_ | Heh. :) |
| 01:15:03 | Araq | pretty impressive though |
| 01:15:23 | Araq | a[i]; a[i+1] is a valid sequence when you inc i, 2 |
| 01:16:06 | Araq | the compiler complains when you do inc(i) |
| 01:22:44 | NimBot | Araq/Nimrod devel 18ded6c Andreas Rumpf [+41 ±146 -4]: Merge pull request #1363 from Araq/devel... 2 more lines |
| 01:22:44 | NimBot | Araq/Nimrod devel 76011e4 Araq [+1 ±4 -0]: progress on 'spawn' |
| 01:22:44 | NimBot | Araq/Nimrod devel 86b654c Araq [+0 ±0 -0]: Merge branch 'master' of https://github.com/Araq/Nimrod into devel |
| 01:22:44 | NimBot | Araq/Nimrod devel 037d7e4 Araq [+1 ±9 -0]: Merge branch 'devel' of https://github.com/Araq/Nimrod into devel |
| 01:23:03 | Araq | good night |
| 01:23:21 | Varriount | Good night. |
| 01:33:34 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 01:50:30 | * | Jehan_ quit (Quit: Leaving) |
| 02:24:18 | * | bogen left #nimrod (#nimrod) |
| 02:25:01 | * | bogen joined #nimrod |
| 02:40:08 | * | q66 quit (Quit: Leaving) |
| 03:24:45 | * | gsingh93 joined #nimrod |
| 04:01:46 | * | saml_ quit (Ping timeout: 255 seconds) |
| 04:23:49 | * | flaviu quit (Ping timeout: 260 seconds) |
| 04:28:19 | * | brson quit (Quit: leaving) |
| 05:06:42 | * | superfunc joined #nimrod |
| 05:22:38 | * | bogen left #nimrod (#nimrod) |
| 05:50:25 | * | superfunc quit (Ping timeout: 244 seconds) |
| 06:19:41 | * | gsingh93 quit (Quit: Connection closed for inactivity) |
| 08:00:16 | * | superfunc joined #nimrod |
| 08:06:00 | * | skyfex joined #nimrod |
| 08:38:52 | * | kunev joined #nimrod |
| 08:38:58 | * | zahary joined #nimrod |
| 08:48:31 | * | zahary quit (Quit: Leaving.) |
| 08:50:39 | dom96 | good morning |
| 09:06:33 | * | Matthias247 joined #nimrod |
| 09:09:09 | dom96 | yay, forum is still alive. |
| 09:41:57 | * | superfunc quit (Ping timeout: 245 seconds) |
| 09:43:35 | * | Francisco joined #nimrod |
| 09:45:58 | * | Fr4n quit (Ping timeout: 260 seconds) |
| 09:54:32 | NimBot | dom96/jester new-async 9e44471 Dominik Picheta [+0 ±1 -0]: Changes for new URI parser. |
| 09:55:54 | NimBot | Araq/Nimrod devel eb6ac2a Dominik Picheta [+0 ±1 -0]: Asynchttpserver now uses new uri module for URL parsing. |
| 09:55:54 | NimBot | Araq/Nimrod devel 8b08e98 Dominik Picheta [+1 ±6 -0]: Merge branch 'devel' of github.com:Araq/Nimrod into devel |
| 10:29:01 | Araq | hi dom96 ... so what's missing for 0.9.6 from your point of view? |
| 10:29:15 | dom96 | async files |
| 10:29:25 | dom96 | async irc,ftpclient,scgi .. etc |
| 10:29:53 | Araq | well no, that are features |
| 10:30:09 | Araq | we need some bugfix release |
| 10:30:27 | Araq | maybe we should name it 0.9.4.2 ? |
| 10:30:34 | dom96 | well then we shouldn't call it 0.9.6 I don't think |
| 10:30:56 | dom96 | yeah, maybe |
| 10:31:43 | dom96 | You will need to add a 'MinorMinorVersion' constant to system.nim though lol |
| 10:39:57 | NimBot | Araq/Nimrod devel ef2f377 Dominik Picheta [+0 ±4 -0]: Added SafeDisconn for accept. |
| 10:41:04 | dom96 | I think it would be nice to get all modules to use the new async stuff |
| 10:41:23 | dom96 | then we can release 0.9.6 |
| 10:41:37 | dom96 | Getting that done shouldn't take too long. |
| 10:41:46 | dom96 | Also async db modules |
| 10:41:49 | Araq | muhaha |
| 10:41:57 | dom96 | and varriount needs to finish his file monitoring module |
| 10:42:06 | Araq | "shouldn't take long" ... yeah I've heard this before |
| 10:42:15 | dom96 | lol |
| 10:42:31 | dom96 | It shouldn't take long as long as I don't hit any bad bugs :P |
| 10:42:40 | dom96 | if I do then we can just give up lol |
| 10:42:55 | Araq | ok fair enough |
| 10:45:05 | Araq | any objections with breaking code and doing declared vs defined ? |
| 10:46:00 | dom96 | no, do it. |
| 10:46:12 | Araq | ok, will write forum post about it though |
| 10:46:28 | dom96 | alright |
| 10:49:44 | * | EXetoC joined #nimrod |
| 10:50:13 | Araq | dom96: the db_* modules need to be designed differently |
| 10:50:25 | Araq | the string based data typing doesn't work properly |
| 10:50:51 | Araq | I think we need dbj_* modules that use JSON instead of strings |
| 10:51:29 | dom96 | argh, too much work lol |
| 10:51:41 | Araq | no, it's easy |
| 10:57:33 | Araq | meh this is stupid, I'll introduce a deprecation warning |
| 11:01:00 | dom96 | Do you think the async* naming convention is fine? or should I put all these async module into a 'async' directory? |
| 11:01:04 | dom96 | *modules |
| 11:02:27 | Araq | no idea, I guess the longish names are annoying |
| 11:02:51 | Araq | do we keep non async versions around? |
| 11:03:07 | Araq | if so what should be the default? |
| 11:05:12 | * | kunev quit (Ping timeout: 272 seconds) |
| 11:07:09 | dom96 | the default? |
| 11:07:16 | dom96 | We have net and asyncnet for example. |
| 11:07:29 | dom96 | sync should be default I think |
| 11:07:38 | dom96 | as in it shouldn't have a prefix |
| 11:28:34 | NimBot | Araq/Nimrod devel a2ec3c9 Dominik Picheta [+0 ±2 -0]: Fix asyncnet example. Rearrange net code. |
| 11:31:56 | Araq | ok then you can't really use a directory unless it's not in the path |
| 11:32:20 | Araq | currently every subdir ends up in path for convenience |
| 11:32:47 | dom96 | Yeah, it's not in the path though right? |
| 11:33:05 | dom96 | lib/async doesn't exist so why would would it be in the path |
| 11:33:48 | Araq | cause we add it? |
| 11:34:08 | dom96 | just leave it out of the path |
| 11:34:09 | Araq | so this is the first time we require users import async.ftpclient |
| 11:34:14 | dom96 | yeah |
| 11:34:19 | Araq | meh :P |
| 11:34:32 | * | Araq is reminded of .NET |
| 11:34:59 | Araq | but ok, let's do it |
| 11:35:02 | dom96 | I think it's sexy :P |
| 11:35:06 | dom96 | and most people will too |
| 11:35:08 | Araq | people love dots |
| 11:35:25 | dom96 | I prefer import async/ftpclient |
| 11:35:26 | dom96 | :P |
| 11:35:38 | dom96 | that is still supported right? |
| 11:35:45 | Araq | right |
| 11:35:49 | Araq | but thinking about it |
| 11:36:04 | Araq | your approach has a serious drawback, I think |
| 11:36:12 | dom96 | what is that? |
| 11:36:19 | Araq | once we move async.ftpclient into its babel package |
| 11:36:42 | dom96 | what |
| 11:36:43 | Araq | and then we have multiple babel packages that should all end up in "async", perhaps |
| 11:36:56 | dom96 | you mean a dummy .babel file? |
| 11:37:04 | Araq | no, a real babel package |
| 11:37:21 | dom96 | so you want to get rid of these from the stdlib? |
| 11:37:47 | Araq | yeah because their development speed is different from the compiler's |
| 11:38:11 | dom96 | I disagree. |
| 11:38:20 | Araq | they are definitely part of the "batteries included" though |
| 11:39:09 | dom96 | Even so, if there are multiple babel packages with an async dir in them it will work. |
| 11:39:39 | dom96 | It only makes sense to put these modules in a babel package if they are still in development though. |
| 11:40:15 | dom96 | I guess that is technically the case. |
| 11:40:23 | dom96 | But the base of them is stable. |
| 11:40:31 | dom96 | There is nothing experimental about them. |
| 11:41:08 | dom96 | I just need to expose some generic FTP stuff in the sync ftpclient |
| 11:41:30 | dom96 | Rewrite some stuff to use it, and reuse the code in the async version but add some awaits in there :P |
| 11:42:17 | Araq | ok fine, whatever |
| 11:42:39 | dom96 | Should asyncdispatch be in the async dir too? |
| 11:42:42 | dom96 | I guess it should. |
| 11:42:56 | Araq | and now the fun happens |
| 11:43:10 | Araq | async.asyncdispatch? |
| 11:43:12 | dom96 | or perhaps I should just call it async :P |
| 11:43:19 | Araq | async.dispatch? |
| 11:43:25 | Araq | async.async ? |
| 11:43:45 | Araq | std.array.Array ? |
| 11:43:55 | Araq | (D style) |
| 11:43:57 | dom96 | will the compiler get confused if there is a module by the name of 'async' and a dir by the name of 'async'? |
| 11:44:00 | Araq | ( D style) |
| 11:44:20 | Araq | I don't think so but that doesn't mean it's a good idea |
| 11:45:07 | Araq | io.async.async # now we're talking |
| 11:45:08 | dom96 | async.core :P |
| 11:45:25 | Araq | as opposed to non IO async ... :P |
| 11:45:38 | dom96 | ugh, stop being silly |
| 11:45:51 | dom96 | It's a waste of time. |
| 11:45:56 | Araq | async.core is pretty cool |
| 11:46:05 | Araq | go for it |
| 11:46:08 | dom96 | good |
| 11:46:18 | Araq | but async.dispatch is fine too I think |
| 11:46:35 | dom96 | core is shorter and describes it better |
| 11:47:17 | dom96 | and is the reverse of what clojure calls it lol |
| 11:50:17 | dom96 | hrm, what is system/inclrtl? |
| 11:50:25 | dom96 | and why is it included in asyncdispatch? |
| 11:51:56 | Araq | that provides the .rtl pragma |
| 11:52:05 | Araq | which is used for DLL generation |
| 11:52:13 | Araq | dunno if asyncdispatch uses it |
| 11:54:55 | dom96 | hrm, to import the sync net module I have to write 'import "../net"' |
| 11:55:07 | dom96 | That sounds like it could bring problems when disambiguating. |
| 11:56:21 | dom96 | Araq: Shall I continue? |
| 11:57:10 | Araq | no, why do you need to import ../net ? |
| 11:57:21 | Araq | that shouldn't be necessary if net is in the path |
| 11:58:01 | dom96 | yes, but the async net is in the same dir as the other modules. |
| 11:58:06 | dom96 | So it thinks that I want to import it |
| 11:59:13 | Araq | ugh, don't do it then |
| 11:59:40 | dom96 | :( |
| 11:59:40 | Araq | confusing&sexy is worse than ugly&working |
| 12:00:27 | dom96 | Would it be hard to implement a "import blah as B" syntax? |
| 12:00:40 | Araq | it's already implemented |
| 12:01:37 | dom96 | well then there is no problem |
| 12:01:42 | dom96 | when was this implemented? |
| 12:01:54 | Araq | 0.9.4 has it |
| 12:02:29 | Araq | but net vs async.net is meh |
| 12:02:37 | dom96 | why? |
| 12:02:57 | Araq | I think it's confusing :P |
| 12:03:05 | dom96 | What's confusing about it? |
| 12:03:29 | dom96 | oh... bah. |
| 12:03:29 | Araq | async.core needs net, not async.net |
| 12:03:42 | Araq | that doesn't feel right |
| 12:03:48 | dom96 | Why does importing async.net mean that the module name will be net in the code? |
| 12:04:19 | Araq | because the compiler has no notion of a "directory" within nimrod code |
| 12:04:35 | Araq | it's simply not a concept in the language |
| 12:04:41 | dom96 | Well... |
| 12:04:52 | Araq | the compiler is concerned with *modules* |
| 12:04:53 | dom96 | This means that everyone will need to use the 'as' stuff |
| 12:05:05 | dom96 | Consider changing this. |
| 12:05:08 | dom96 | Please |
| 12:05:27 | Araq | no, it's quite some work and it doesn't make any sense |
| 12:06:02 | dom96 | Why doesn't it make sense? |
| 12:06:58 | dom96 | Regarding the fact that async.core needs net. Well... net contains basic socket functionality. |
| 12:07:07 | dom96 | async.net builds on top of async.core |
| 12:07:15 | dom96 | so async.core shouldn't import it |
| 12:09:19 | Araq | meh fine I don't care |
| 12:09:25 | Araq | C# here we come |
| 12:10:13 | dom96 | No. If you don't want it this way then tell me. |
| 12:10:19 | Araq | so if I do |
| 12:10:22 | dom96 | Otherwise you will blame me later for any small issues that arise. |
| 12:10:29 | Araq | import async.net |
| 12:10:34 | Araq | can you do |
| 12:10:38 | Araq | net.foo(bar)? |
| 12:10:45 | Araq | or can you only do |
| 12:10:55 | Araq | async.net.foo(bar)? |
| 12:11:06 | dom96 | Only the latter. |
| 12:11:18 | Araq | and if I do |
| 12:11:23 | Araq | import async/net |
| 12:11:32 | Araq | then it's net.foo ? |
| 12:12:51 | dom96 | no |
| 12:12:54 | dom96 | it's still the same |
| 12:13:07 | Araq | and if I do import net and have async in path? |
| 12:13:55 | dom96 | error |
| 12:14:07 | dom96 | if lib/pure is also in the path that is |
| 12:14:32 | Araq | this breaks everything |
| 12:15:20 | Araq | and improves nothing |
| 12:17:03 | * | darkf quit (Quit: Leaving) |
| 12:17:09 | Araq | gah, I really hate this obsession with dots and hierarchies and directories |
| 12:17:18 | dom96 | how so? |
| 12:17:32 | Araq | directories suck, there is not a single tool that handles them conveniently |
| 12:18:11 | Araq | the order is wrong, I think file.io.stdlib, and not stdlib.io.file |
| 12:18:27 | dom96 | I think you're exaggerating a bit, unless I am unaware that when I import a module there are two modules with the same name and the compiler does some magic to determine which one to pick |
| 12:21:17 | Araq | in my opinion filesystems that don't support arbitrary nesting are a feature |
| 12:22:42 | Araq | anyway, consider it a vote against an async/ directory |
| 12:35:24 | dom96 | ok, let's see what other people vote :P |
| 12:45:02 | * | EXetoC quit (Quit: WeeChat 0.4.3) |
| 13:07:57 | * | q66 joined #nimrod |
| 13:18:45 | * | n3t joined #nimrod |
| 13:26:10 | dom96 | hello n3t |
| 13:27:10 | n3t | Hi. |
| 13:41:05 | Araq | n3t: welcome |
| 13:41:53 | n3t | Hello. Nice people on IRC channel. It is pretty uncommon ;) |
| 14:19:01 | Araq | dom96: ping |
| 14:36:36 | * | flaviu joined #nimrod |
| 14:37:11 | Araq | hey flaviu |
| 14:37:21 | flaviu | hi Araq |
| 14:37:31 | Araq | I'm wondering if having to keep a whitelist for 'defined' is acceptable |
| 14:38:09 | flaviu | 'defined'? |
| 14:38:44 | Araq | so somewhere there would be list like [release, debug, ssl, useWinAnsi, booting, ...] and then the compiler can check there is no typo in 'defined(boting)' |
| 14:42:16 | flaviu | Oh, I see. It'd be best if the defined whitelist could also modified by the use. Maybe when the user passes `--defined:foo`, it could add `foo` to the witelist |
| 14:43:34 | flaviu | That's assuming that you're using something a bit more complex than string comparison here though. |
| 14:49:30 | Araq | hmm good idea |
| 14:49:41 | Araq | we already have --define and --undefine |
| 14:50:21 | dom96 | Araq: sup? |
| 14:51:44 | Araq | dom96: read the logs please |
| 14:51:48 | Araq | it's about defined |
| 14:52:13 | dom96 | I think we should make adding to the whitelist explicit |
| 14:52:28 | Araq | when we have a whitelist somewhere we can make the compiler smart enough to properly support the new defined vs declared |
| 14:53:16 | dom96 | I don't see how flaviu's idea would work. As soon as someone doesn't write --defined: foo all code that uses ``when defined(foo)`` would fail to compile no? |
| 14:53:32 | Araq | yeah |
| 14:53:45 | Araq | in some .cfg you need to have --undef:foo then |
| 14:54:29 | flaviu | dom96: No, my idea has more heuristics. If someone had not written `--defined:foo` but had written `--defined:fod`, then it would emit a warning |
| 14:54:39 | dom96 | I'd rather see something like {.defineWhitelist: [foo].} at the top of the source file. |
| 14:54:56 | Araq | no way, it has to be in the config file |
| 14:55:20 | Araq | we have no {.define.} pragma for good reasons |
| 14:56:39 | dom96 | so --defined will add to the whitelist and --define will define it? |
| 14:56:55 | Araq | something like that, yes |
| 14:57:22 | Araq | we need a better name for --defined though |
| 14:57:25 | dom96 | yes |
| 14:57:51 | dom96 | flaviu: Do you think the async modules should go into an async directory and be imported via: import async.net, async.core etc? |
| 14:58:09 | flaviu | That sounds good to me |
| 14:59:29 | dom96 | Araq doesn't like it |
| 15:00:50 | flaviu | Well, I do, but I'm not going to argue since these sort of things never end up going anywhere |
| 15:02:05 | dom96 | that's not true |
| 15:08:11 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 15:11:56 | * | gkoller joined #nimrod |
| 15:12:07 | dom96 | flaviu: If you want to play around with the async stuff or got nothing else to do you could help me rewrite some of the modules in the stdlib which use the old async module. |
| 15:12:30 | dom96 | It'll be a good test for it. |
| 15:12:49 | dom96 | if you're interested then you pick whichever module you want |
| 15:12:55 | dom96 | I have to leave for a while bbl |
| 15:22:38 | Araq | I think it should be --symbol |
| 15:22:44 | Araq | same here, bbl |
| 15:24:11 | * | n3t quit (Quit: Leaving) |
| 15:58:51 | flaviu | dom96: Sorry, I'm busy with other things |
| 16:00:37 | * | EXetoC joined #nimrod |
| 16:03:23 | * | bogen joined #nimrod |
| 16:07:10 | * | ics quit (Ping timeout: 255 seconds) |
| 16:07:53 | * | ics joined #nimrod |
| 16:30:06 | * | gkoller quit (Ping timeout: 272 seconds) |
| 16:31:41 | * | gkoller joined #nimrod |
| 17:04:29 | * | gkoller quit (Ping timeout: 260 seconds) |
| 17:11:57 | * | Demos joined #nimrod |
| 17:21:51 | * | def- left #nimrod (#nimrod) |
| 17:27:28 | * | ics quit (Ping timeout: 250 seconds) |
| 17:28:10 | * | ics joined #nimrod |
| 17:30:00 | * | Demos_ joined #nimrod |
| 17:33:06 | * | Demos quit (Ping timeout: 250 seconds) |
| 17:38:18 | * | kunev joined #nimrod |
| 17:42:03 | * | Trustable joined #nimrod |
| 18:29:49 | * | kunev quit (Ping timeout: 255 seconds) |
| 18:46:54 | * | jpoirier joined #nimrod |
| 18:47:55 | * | Matthias247 joined #nimrod |
| 18:52:18 | * | Trustable quit (Quit: Leaving) |
| 18:57:51 | * | fran__ joined #nimrod |
| 18:59:26 | * | Francisco quit (Ping timeout: 250 seconds) |
| 19:09:18 | * | kunev joined #nimrod |
| 19:19:35 | * | bogen left #nimrod (#nimrod) |
| 19:24:59 | * | superfunc joined #nimrod |
| 19:50:42 | * | superfunc quit (Ping timeout: 245 seconds) |
| 20:01:45 | * | Boscop quit (Read error: Connection reset by peer) |
| 20:02:08 | * | Boscop joined #nimrod |
| 20:02:09 | * | Boscop quit (Changing host) |
| 20:02:09 | * | Boscop joined #nimrod |
| 20:04:04 | * | Jehan_ joined #nimrod |
| 20:16:31 | dom96 | I put all the async stuff into an async folder and I don't want to erase that work. So how about we decide how to proceed? |
| 20:17:22 | dom96 | Araq: I don't suppose people preferring 'import async.core' will convince you? |
| 20:17:23 | * | kunev quit (Ping timeout: 264 seconds) |
| 20:19:25 | Araq | no but go ahead |
| 20:32:46 | dom96 | Well it seems importing 'async.net' and 'net' doesn't work. |
| 20:33:22 | dom96 | it's complaining about a redefinition of 'net' |
| 20:33:43 | dom96 | is this a bug or how it was designed? |
| 20:35:07 | Araq | that's how it's been designed |
| 20:37:14 | dom96 | Yeah, it should really use 'async.net' for disambiguation then. |
| 20:40:20 | dom96 | I'm going to hold off on this and create issues for a proper discussion. |
| 20:40:32 | Araq | yeah well, I'll happily patch the compiler for your misguided design |
| 20:42:08 | Araq | I mean seriously ... using different module names for different modules is not overly restrictive |
| 20:44:44 | dom96 | ok. As you wish. |
| 20:45:05 | Araq | and |
| 20:45:16 | Araq | import async.net as anet should work |
| 20:45:36 | dom96 | I won't put these modules in an async dir. |
| 20:46:38 | Jehan_ | The one problem I have with the module semantics is that you can't really have two libraries with an identically named module each. |
| 20:46:50 | Jehan_ | Or rather, that there's no way to disambiguate that I know of. |
| 20:47:33 | dom96 | There is. |
| 20:47:38 | dom96 | You do what Araq wrote above. |
| 20:47:43 | Araq | thinking about it ... |
| 20:47:55 | Araq | without different babel packages codegen will fail |
| 20:48:03 | Araq | it will name both net.c ... |
| 20:48:51 | Jehan_ | dom96: I know, I'm talking about having them at the top level. |
| 20:49:28 | dom96 | Jehan_: In that case you should put their parent dir in your compilation path. |
| 20:49:50 | dom96 | Then import pkgA/module as moduleA; import pkgB/module as moduleB |
| 20:50:34 | Jehan_ | dom96: That's what I've been doing. Still an issue with third-party libraries that don't follow that convention. |
| 20:50:56 | Jehan_ | As they also have to structure their internal usage accordingly. |
| 20:51:10 | dom96 | I'm not sure how else it can work. |
| 20:51:25 | dom96 | Babel needs to enforce this convention. |
| 20:52:02 | dom96 | Araq: So what are you saying? It won't work? You are rethinking this and think I may be right? or what? |
| 20:52:11 | Jehan_ | Allow module qualification by package, prioritize modules local to the package over external modules. |
| 20:52:40 | Araq | dom96: it won't work and I consider this a feature |
| 20:53:09 | Araq | so name your module 'net' and 'asyncnet' or 'web' or 'anet' or whatever |
| 20:54:09 | dom96 | Jehan_: That requires more babel support from the compiler I think. |
| 20:55:58 | Jehan_ | dom96: Dunno. But that packages can pollute the global module namespace is a problem. |
| 20:56:40 | dom96 | It won't be a problem once babel enforces the convention. |
| 20:56:58 | dom96 | I will only allow modules to be in the global namespace if their name matches the name of the package for example. |
| 20:57:20 | Araq | btw this *whole* discussion only exists because 'async.net' is sexy and 'async_net' is not ... |
| 20:57:33 | dom96 | I still haven't thought about it all that much though. |
| 20:58:58 | dom96 | Araq: I think it's more about being organised than about sexiness. |
| 20:59:08 | Jehan_ | dom96: Even without babel, there's the problem with having a module that's named the same as something in the stdlib. |
| 20:59:15 | Araq | but it's not |
| 20:59:19 | Araq | you want to use |
| 20:59:23 | Araq | import async.net |
| 20:59:35 | Araq | and then async.net.foo everywhere |
| 20:59:55 | Araq | and disallow net.foo |
| 21:00:12 | dom96 | For babel this will be necessary |
| 21:00:15 | Araq | you really want to replace _ by . because it looks better |
| 21:00:18 | dom96 | and making it easy for the user is good. |
| 21:00:35 | Araq | you might as well patch your font instead of patching the compiler |
| 21:01:01 | dom96 | Maybe for babel you should just replace the dot with nothing. |
| 21:01:19 | dom96 | So that I don't need to write: import jester/utils as jesterUtils |
| 21:01:28 | dom96 | just to be able to disambiguate it |
| 21:02:17 | dom96 | I suppose what you want is for package writers to name their modules pkgName_module.nim |
| 21:03:43 | dom96 | Makes perfect sense of course, who wants to navigate these pesky directories. |
| 21:03:53 | dom96 | Lets just put all our files in the same place |
| 21:03:55 | dom96 | and prefix them |
| 21:04:05 | dom96 | with some categories |
| 21:04:53 | dom96 | Our OS will just have a root partition with a billion files |
| 21:05:51 | dom96 | Much easier than navigating these blasphemous hierarchies right? |
| 21:07:29 | Araq | here is some user interface that works: https://www.google.com |
| 21:07:54 | Araq | billions of websites and yet I don't have to navigate through some petty hierarchy |
| 21:08:30 | dom96 | Yeah, let me just grab my supercomputer to search through my files. |
| 21:09:10 | Jehan_ | http://www.asktog.com/columns/085BrowseVsSearch.html |
| 21:11:48 | Jehan_ | What I'd do, incidentally, is to allow something like "import package:module". Including special packages for the stdlib and local modules. E.g.: import foolib:bar; import stdlib:os; import local:os |
| 21:12:12 | Jehan_ | With a package qualifier, search would go local -> stdlib -> packages (in some defined order) |
| 21:12:21 | Jehan_ | s/With/Without/ |
| 21:13:31 | Araq | dom96: thinking about it some further ... the async directory can get its own fake babel file and then it should work |
| 21:13:37 | dom96 | Indeed. What if I don't know what I am searching for? |
| 21:13:51 | dom96 | Araq: I'm way ahead of you. |
| 21:14:00 | dom96 | it did work. |
| 21:14:10 | Araq | ok good |
| 21:14:14 | dom96 | But I already deleted it. |
| 21:14:53 | Araq | whatever |
| 21:15:46 | * | Joe_knock joined #nimrod |
| 21:16:14 | Araq | dom96: when you don't know what you're searching for I fail to see how async.core and async.net helps to find it |
| 21:16:42 | Araq | these names are chosen for being sexy, nothing more, nothing less |
| 21:17:11 | Araq | it's ok to be sexy, but it's not ok to pretend it's about anything else |
| 21:18:40 | dom96 | why does the nimrod repo have any directories at all then? |
| 21:20:54 | Araq | we even have lib/pure/collections, but look at what the stdlib does: it adds it to your path, so you can do: import tables |
| 21:21:40 | Jehan_ | That's actually a problem with compatibility (the way it works now). |
| 21:21:52 | Jehan_ | Adding a new module to the stdlib can break existing code. |
| 21:22:07 | Araq | not really |
| 21:22:18 | Araq | project specific modules are preferred |
| 21:22:32 | Jehan_ | Oh? Okay, that's good. |
| 21:22:46 | Jehan_ | Wait. |
| 21:23:02 | dom96 | what about babel packages? |
| 21:23:14 | dom96 | Araq: That doesn't answer my question |
| 21:23:23 | Jehan_ | So, what if I import foo from the stdlib, the stdlib:foo module imports bar, but I have a bar module in my project? |
| 21:23:43 | dom96 | Araq: You say you hate directories and yet you use them |
| 21:24:10 | Jehan_ | Do stdlib modules importing another module prefer stdlib modules also? |
| 21:25:26 | Araq | Jehan_: I planned to do this, but this is also used as a feature ... so that you can override modules |
| 21:25:40 | Jehan_ | Umm ... |
| 21:26:03 | Jehan_ | I think that creates more problems than it solves. |
| 21:26:51 | * | saml_ joined #nimrod |
| 21:26:57 | Jehan_ | I really think that import should prefer related modules (i.e., project modules import other project modules first, stdlib modules import other stdlib modules first, package modules import other modules from the same package first). |
| 21:28:23 | Araq | dom96: I don't know what to answer. The question is too childish to take it seriously. |
| 21:34:26 | Araq | Jehan_: actually I planned to have an elaborate scheme to do overriding, so yeah, this will be done differently in the future |
| 21:35:56 | dom96 | To me it seems a bit arbitrary where you decide that hierarchies are fine and where you decide they are not |
| 21:36:09 | Araq | they are never fine |
| 21:36:25 | Araq | but they can be the lesser of 2 evils, given existing OSes and file systems |
| 21:36:46 | dom96 | however I think that an 'async' dir is barely a hierarchy |
| 21:36:54 | Araq | the dir is fine |
| 21:37:09 | Araq | making people aware of it is not what the stdlib currently does |
| 21:37:46 | Araq | and causes problems and I'm tired of this bike shedding with the perfectly fine module system |
| 21:38:10 | Araq | it already has more features than anything else out there |
| 21:38:28 | Araq | but no no no, I wanna use the dot in yet one more circumstance |
| 21:39:21 | Araq | a _ doesn't cut it, it needs to be a . |
| 21:40:52 | Araq | btw I recently put some grouping in compiler/, every module got its own subdirectory. I never pushed this change because it's annoying as hell to navigate |
| 21:41:41 | Araq | and for some modules the category was not easy to determine |
| 21:41:57 | * | superfunc joined #nimrod |
| 21:48:35 | Varriount | Hello! |
| 21:49:17 | Jehan_ | That's what ctags is for. :) |
| 21:49:36 | Jehan_ | Which reminds me that I really need to figure out a way to generate decent ctags for Nimrod. |
| 21:52:44 | Araq | Jehan_: fixing "nimrod idetools" seems more useful |
| 21:52:51 | Araq | hi Varriount |
| 21:53:27 | Jehan_ | Araq: idetools is inherently more powerful, but also more cumbersome to set up. |
| 21:53:47 | Jehan_ | ctags are more limited, but are simple and work. |
| 21:54:13 | Varriount | Araq: Updated https://github.com/Araq/Nimrod/pull/1467 |
| 21:55:07 | NimBot | Araq/Nimrod devel 7c3a28a Clay Sweetser [+0 ±1 -0]: Fix #1424 |
| 21:55:07 | NimBot | Araq/Nimrod devel 7a09b3b Clay Sweetser [+0 ±1 -0]: Fix #1424 some more |
| 21:55:07 | NimBot | Araq/Nimrod devel 74213fc Varriount [+0 ±1 -0]: Update semexprs.nim |
| 21:55:07 | NimBot | Araq/Nimrod devel 94131e1 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1467 from Varriount/fix-1424... 2 more lines |
| 21:57:07 | Varriount | Araq: If you want an example of "uneeded subdirectories", point to the CPython source layout. |
| 21:57:52 | Araq | Varriount: no need. every Java project in existance is an example. |
| 21:58:05 | Varriount | Oh yeah. *shudder* |
| 22:01:18 | Araq | ugh ... we really have lots of conditional defines |
| 22:01:20 | Jehan_ | Well, Java is designed under the assumption that you use an IDE to navigate the hierarchy. |
| 22:01:54 | Jehan_ | Something that I'm not a fan of, to be clear. |
| 22:02:15 | Araq | no, even under this assumption, the design has lots of problems |
| 22:02:21 | Varriount | Araq: Yeah, but the conditional defines are there to help distinguish things. Where would we be without defined(windows)? |
| 22:03:24 | Araq | Varriount: yes but I'm trying to introduce defined vs declared |
| 22:03:34 | Araq | and it's lots of work |
| 22:09:28 | * | saml_ quit (Read error: Connection reset by peer) |
| 22:11:20 | dom96 | So async is now stable enough to handle the forum. |
| 22:11:38 | Araq | YAAYY! |
| 22:11:39 | dom96 | Please do test it everyone. |
| 22:12:58 | Varriount | dom96: Can/Should the builder be updated to use it? |
| 22:13:54 | dom96 | hrm. |
| 22:13:58 | dom96 | It should be possible. |
| 22:14:16 | dom96 | You can do that if you want, in a new branch. |
| 22:14:30 | dom96 | Getting the stdlib modules to use it is more important though. |
| 22:14:45 | Araq | I can imagine lots of more important things, yeah |
| 22:15:04 | * | superfunc quit (Ping timeout: 272 seconds) |
| 22:16:22 | * | fran__ quit (Ping timeout: 260 seconds) |
| 22:23:47 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 22:25:21 | dom96 | good night |
| 22:32:38 | Varriount | Araq: Updated https://github.com/Araq/Nimrod/pull/1461 |
| 22:35:04 | Araq | Varriount: I guess it's fine this way but I'll pull tomorrow |
| 22:35:18 | Varriount | Araq: Do you think there's a better way? |
| 22:41:59 | Araq | Varriount: no |
| 22:50:28 | * | darkf joined #nimrod |
| 22:50:35 | * | darkf quit (Changing host) |
| 22:50:35 | * | darkf joined #nimrod |
| 22:53:32 | Araq | good night |
| 22:59:43 | * | Jehan_ quit (Quit: Leaving) |
| 23:23:04 | * | bogen joined #nimrod |
| 23:56:13 | * | xenagi joined #nimrod |