| 00:00:18 | Araq | test5 tests a sequence of tuples |
| 00:07:53 | dom96 | well that's just weird. |
| 00:08:15 | dom96 | unknown file(1, 0) Error: '{' expected for an object expected [EJsonParsingError] |
| 00:08:22 | dom96 | I get this when trying to reproduce. |
| 00:08:44 | dom96 | the generated json seems fine |
| 00:23:33 | * | q66 quit (Quit: Quit) |
| 00:29:45 | Araq | good night |
| 00:56:50 | dom96 | !lag |
| 00:56:50 | NimBot | 10001ms between me and the server. |
| 00:57:10 | dom96 | !lag |
| 00:57:10 | NimBot | 10001ms between me and the server. |
| 01:03:31 | dom96 | !lag |
| 01:03:31 | NimBot | 7ms between me and the server. |
| 04:46:20 | * | XAMPP_ joined #nimrod |
| 04:49:40 | * | XAMPP quit (Ping timeout: 246 seconds) |
| 05:18:01 | * | XAMPP_ quit (Read error: Connection reset by peer) |
| 05:18:25 | * | XAMPP_ joined #nimrod |
| 07:49:27 | * | FreeArtMan joined #nimrod |
| 07:50:11 | Araq | wb FreeArtMan |
| 07:54:39 | * | FreeArtMan quit (Ping timeout: 252 seconds) |
| 08:36:36 | * | FreeArtMan joined #nimrod |
| 08:55:18 | Araq | FreeArtMan: if you like to develop kernel modules, the stdlib will need some patches for that; best way is to try and nag me whenever there is a problem ;-) |
| 08:56:04 | Araq | after that do a pull request and perhaps add an article to the wiki ... :D |
| 09:02:01 | Araq | but I have to go, see you later |
| 09:16:13 | FreeArtMan | ok |
| 10:22:02 | * | fowl_ joined #nimrod |
| 10:25:23 | * | fowl quit (Ping timeout: 255 seconds) |
| 11:02:16 | * | ekselkiu joined #nimrod |
| 11:09:06 | * | FreeArtMan quit (Ping timeout: 264 seconds) |
| 11:32:14 | * | q66 joined #nimrod |
| 11:37:10 | dom96 | !ping |
| 11:37:10 | NimBot | pong |
| 11:43:43 | Araq | dom96: I think I already know the marshal bug ;-) |
| 11:44:04 | Araq | dunno yet what the best fix will be though |
| 11:46:08 | dom96 | ok |
| 12:00:50 | dom96 | Araq: http://build.nimrod-code.org/beta Almost done! :P |
| 12:02:41 | Trixar_za | How do I se the damn away nick with this thing :/ |
| 12:07:54 | Trixar_za | There we go |
| 12:08:10 | Trixar_za | I hate upgrading stuff that breaks backward compatibility every release |
| 12:20:57 | Araq | dom96: excellent :Dd |
| 12:21:12 | Araq | I annotated sockets.nim, you may have a look over it |
| 13:11:32 | Araq | ping zahary |
| 17:26:46 | * | Trixar_za is now known as Trix[a]r_za |
| 18:51:19 | * | gradha joined #nimrod |
| 18:59:00 | Araq | ping zahary |
| 19:01:42 | Araq | ping gradha |
| 19:01:54 | gradha | pong Araq |
| 19:02:48 | Araq | I've implemented #250 |
| 19:03:01 | Araq | as the compiler already did the check for codegen |
| 19:03:18 | gradha | didn't you say it was a PITA? |
| 19:03:24 | gradha | I was expecting you to close it |
| 19:03:30 | * | FreeArtMan joined #nimrod |
| 19:03:45 | Araq | but the warning is turned off per default and the stdlib uses the 'var a = a' idiom |
| 19:04:06 | Araq | there was also a request to warn about shadowing 'result' |
| 19:04:23 | gradha | excellent, more options always feels like christmas |
| 19:04:36 | Araq | I dunno ... |
| 19:04:59 | Araq | the docs about compiler switches are already excessive ... |
| 19:05:50 | gradha | well, wading through all C warning/error switches always requires a good afternoon anyway |
| 19:06:07 | gradha | at least if you want to understand what they do, rather than quickly read them |
| 19:06:25 | gradha | such is the reality of compilers |
| 19:06:45 | Araq | what's up with #174 btw? still valid? |
| 19:07:29 | gradha | haven't checked in a while, I'll see again when I come to implementing the iOS todo example |
| 19:07:40 | Araq | ok |
| 19:07:46 | gradha | I'll fire it up now to see how it goes |
| 19:09:16 | Araq | I hate it when the list of issues becomes too long ... |
| 19:09:27 | Araq | and I have to page |
| 19:10:01 | zahary | hi Araq, what's new? |
| 19:10:25 | Araq | wanted to talk with you again about first class iterators |
| 19:11:31 | Araq | 1) I still wasn't able to find out whether C# 5 captures the full stack or not |
| 19:11:46 | zahary | it doesn't |
| 19:11:57 | Araq | 2) first class 'yield' cannot be made compile-time evaluable without rewriting evals.nim |
| 19:12:20 | Araq | which is not a bad thing I guess since people want it to be a real VM anyway |
| 19:12:41 | zahary | rewriting? not merely augmenting? why so? |
| 19:12:49 | zahary | haven't thought about it at all |
| 19:13:10 | Araq | we can only evaluate structured control flow |
| 19:13:20 | Araq | 'yield' is too unstructured ;-) |
| 19:13:34 | Araq | consider this: |
| 19:13:42 | Araq | while cond: |
| 19:13:46 | Araq | stmts |
| 19:13:54 | Araq | yield value |
| 19:13:56 | zahary | but the transform to closure will happen before evals? why wouldn't it just work? |
| 19:14:10 | Araq | the closure is not the problem |
| 19:14:25 | zahary | aha, it's the lack of gotos? |
| 19:14:29 | Araq | yes |
| 19:14:32 | zahary | I see |
| 19:14:55 | Araq | we can't eval goto with the current approach |
| 19:15:21 | zahary | well, I would list this as known limitation for now |
| 19:15:24 | Araq | ok, rewriting as an "interpreter loop" would work as well I guess |
| 19:15:43 | Araq | (we talked about it: rewrite everything to fit a single while+case statement) |
| 19:18:03 | Araq | but meh, rewriting evals to use a proper bytecode is fun :-) |
| 19:18:06 | zahary | I was thinking through the necessary steps of integrating the compilation of macros to DLLs with my new compilation scheme. it wouldn't be extremely hard to do |
| 19:18:45 | Araq | yeah but I'd prefer to have a proper nimrod interpreter now |
| 19:19:02 | Araq | we get a REPL for free then |
| 19:19:38 | Araq | and having a "scripting layer" that's statically typed is sweet too |
| 19:19:55 | zahary | it's useful to have an interpreter, yes |
| 19:20:34 | Araq | plus we can add it to the stdlib and implement 'eval' |
| 19:20:36 | zahary | what about the other idea of reusing lua? it's more exotic, but it too might work |
| 19:21:23 | Araq | reusing the JS backend sounds like a better plan then |
| 19:21:53 | Araq | JS supports 'try' for a start |
| 19:22:50 | zahary | I woudn't argue the details - it's true that there are usable JS implementations out there |
| 19:24:30 | Araq | well Lua is fine with me too, it's a nicer dependency than "v8" or spidermonkey |
| 19:24:39 | Araq | much easier to build I'm sure |
| 19:24:44 | zahary | you can also implement iterators as true coroutines in the current design I guess - i.e. allocate additional stack for them |
| 19:25:30 | Araq | the problem is we use recursion in evals.nim and thus have not much control over the stack |
| 19:25:46 | Araq | and so we can't have continuations in evals.nim easily |
| 19:27:11 | zahary | what do you mean? ok, we use recursion, but all functions work on EvalContext (which contains the stack) - can't we allocate another EvalContext for the coroutine? |
| 19:28:12 | Araq | the stack doesn't contain the control flow within a single proc |
| 19:29:09 | Araq | nkWhileStmt is interpreted with a Nimrod while loop |
| 19:29:17 | Araq | you can't resume that easily |
| 19:29:34 | zahary | what you mean is that we cannot interrupt the execution at a given point and resume it later? |
| 19:29:42 | Araq | yes |
| 19:29:46 | gradha | Araq: updated https://github.com/Araq/Nimrod/issues/174 with current git nimrod and latest xcode warnings |
| 19:30:49 | zahary | we can if we allocate a stack in the evaluator itself too, but ok, this is getting complicated |
| 19:32:41 | Araq | I tried to eliminate the recusion in evals.nim years ago btw |
| 19:32:57 | Araq | I think it's impossible without introducing a bytecode |
| 19:33:31 | gradha | If you need the generated source that xcode tries to compile you can get it at http://dl.dropbox.com/u/145894/nimrod/system.m and replace the other paths in the url |
| 19:35:23 | Araq | gradha: the missing prototypes are worrysome; does hello.nim have the same problem? |
| 19:35:52 | gradha | what hello.nim? |
| 19:36:06 | Araq | 'echo "hello world"' |
| 19:36:21 | gradha | ah, you mean compiling that |
| 19:36:59 | Araq | but yeah (2) is interesting but not very important |
| 19:37:37 | Araq | number 3) is: using 'iterator' and 'yield' for async programming reads horrible |
| 19:38:09 | Araq | so I plan to have: |
| 19:38:17 | Araq | proc p() {.async.} = |
| 19:38:22 | Araq | await downloadUrl() |
| 19:38:41 | Araq | where 'await' is a simple template that aliases 'yield' |
| 19:38:49 | zahary | it's not bad - I have suggested it in my gist after all :) |
| 19:39:10 | Araq | and 'async' transforms the proc into an iterator returning a 'PEvent' |
| 19:39:35 | Araq | I still think 'event' is a much better term than 'promise' as promise for me has something to do with threads |
| 19:39:48 | gradha | hallo.nim shows the same problem as backend.nim, missing NimMain prototype |
| 19:40:10 | gradha | the other missing prototypes are in system.m, which I presume is the same for every generation |
| 19:40:28 | Araq | is NimMain invoked before it's defined? |
| 19:40:28 | zahary | about the "event vs promise" debate, I personally like the C# meaning of `event` (what in C++ we call signals/slots, publish/subscribe) |
| 19:41:25 | zahary | promise is an object with a bit more semantics - it can be resolved, it can be rejected, and I also like some modern developments when another onProgress event is added for reporting progress from the async operation |
| 19:42:05 | gradha | I think the problem is that whatever.m generated file doesn't include its own whatever.h file |
| 19:42:20 | Araq | nor should it |
| 19:42:31 | Araq | the compiler only generates the header for you |
| 19:43:26 | zahary | some libraries also call it `deferred` btw, to add another name to the list |
| 19:44:20 | Araq | gradha: do you mean the bug only shows up when you use --generateHeader |
| 19:44:53 | Araq | well it's an "event loop" and the iterators request the event to wait for |
| 19:45:03 | Araq | it's the natural term for me |
| 19:45:06 | gradha | it's not really a bug, it's a warning that I enabled in llvm named "Missing Function Prototypes" |
| 19:45:17 | Araq | it's a bug |
| 19:45:38 | Araq | missing prototypes cause strange conversions (everything is converted to 'int' or something) |
| 19:45:41 | gradha | it's not a default warning, if I disable it there are no complaints |
| 19:46:00 | Araq | missing prototypes are bugs |
| 19:46:03 | gradha | ok |
| 19:46:29 | zahary | what I am saying is that by calling this thing event, you miss the opportunity to call `events` the much more widely useful signals/slots |
| 19:46:54 | gradha | my question is as follows: if whatever.m doesn't include whatever.h, where NimMain is defined for external code, maybe you should re-prototype it at the beginning of whatever.m |
| 19:47:03 | zahary | btn.onClick do: |
| 19:47:03 | zahary | …. |
| 19:47:03 | zahary | that's the events I'm talking about |
| 19:47:16 | gradha | hmm... in fact, this example only uses a single nimrod file, if I had two would I have two NimMain header prototypes? |
| 19:47:58 | gradha | I'll try with some more nimrod files and get back to you later |
| 19:48:01 | dom96 | I agree with zahary, that's what I associate the term 'event' with. |
| 19:48:02 | Araq | so what? two identical prototypes are no bug |
| 19:48:28 | Araq | alright then |
| 19:48:29 | gradha | ok then |
| 19:48:31 | zahary | async.TEvent vs events.TEvent ? |
| 19:48:42 | Araq | that's confusing |
| 19:48:52 | dom96 | and indeed we do already have an events module :P |
| 19:48:55 | zahary | that's my point |
| 19:48:59 | zahary | unnecessary clash |
| 19:49:15 | Araq | the events module needs to changed anyway |
| 19:49:22 | Araq | it was written before we had closures |
| 19:49:45 | zahary | in fact, the implementation of TPromise (or whatever it's called) should consist of 3 events - success, failure, progress |
| 19:50:04 | zahary | event is the primitive publish/subscribe object |
| 19:50:11 | zahary | list of closures to be called |
| 19:50:22 | Araq | nah not in my book :P |
| 19:50:58 | Araq | it's the base class for an hierarchy of promises that epoll supports |
| 19:51:26 | Araq | something like: file handle, socket handle, timer, ... |
| 19:51:37 | zahary | epoll should not concert itself with promises - promises are resolved with normal callbacks (which is what epoll calls) |
| 19:52:13 | Araq | you've looked at titer8, right? |
| 19:52:47 | zahary | what about it? |
| 19:53:14 | Araq | that's what I imagine: the even loop supports a simple list of iterators that 'yield' what they await |
| 19:53:19 | Araq | *event loop |
| 19:53:42 | Araq | nothing too fany ... error handling will be done with exceptions |
| 19:54:08 | zahary | it can't be handled with exceptions |
| 19:54:19 | Araq | why not? |
| 19:54:20 | zahary | let me find a link to article that explains that |
| 19:54:30 | Araq | ok |
| 19:55:59 | zahary | https://gist.github.com/3889970 |
| 19:56:41 | zahary | also, explain in details what you mean by "the even loop supports a simple list of iterators that 'yield' what they await |
| 19:56:41 | zahary | *event loop" |
| 19:57:44 | zahary | the event loop works by you requesting some async operation like "send these bytes over the network", and the operating system posting a "operation complete" object in your event queue (completion port on windows, epoll queue on linux, etc) |
| 19:58:09 | zahary | this is why the fundamental primitive is "the operation complete" object has arrived - execute that callback |
| 19:58:49 | zahary | promises add additional sugar over this by allowing multiple interested parties to be notified when the callback is executed |
| 20:02:29 | gradha | Araq: I have added more .nim files to the ios example, now each of them defines its own NimMain in the objc generated code. I'm using --noMain to compile, but maybe that only takes effect at the nimrod level |
| 20:03:05 | gradha | maybe compiling .nim files individually is not the right way to generate C/objC code and I have to compile through a "project" file? |
| 20:03:58 | Araq | indeed you should never compile .nim files individually |
| 20:04:25 | gradha | yay! |
| 20:04:53 | Araq | zahary: I wonder whether that's the reason why in C# 'await' is not simply compiled into a yield |
| 20:04:56 | gradha | in that case everything is wrong so far, I'll look up on projects and report later |
| 20:05:07 | Araq | gradha: good |
| 20:05:43 | Araq | zahary: which would be my next question: they say something about how the compiler transforms it into CPS form |
| 20:05:58 | Araq | but I don't get why they even need to do that |
| 20:06:15 | zahary | araq, indeed await should return reject value in case of failure - it's also a good idea to allow the user to add custom handling by adding else or except block |
| 20:06:15 | zahary | var x = await downlaod(url) |
| 20:06:15 | zahary | else: … |
| 20:06:43 | Araq | they could simply promote all variables to the heap as I do ... :-) |
| 20:07:19 | * | fowl_ quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 20:07:26 | zahary | CPS is alternative strategy - you can try digging though this project to understand the implications |
| 20:07:26 | zahary | http://maxtaco.github.com/coffee-script/ |
| 20:09:37 | zahary | I personally haven't yet read much about it, but it's apparent that in Iced coffee-script the integration goes a bit further as it interacts with for loops and other stuff like that |
| 20:10:29 | zahary | await |
| 20:10:29 | zahary | for k,i in keywords |
| 20:10:29 | zahary | search k, defer out[i] |
| 20:10:36 | * | fowl joined #nimrod |
| 20:10:53 | Araq | CPS is much more complicated to implemented |
| 20:11:15 | Araq | and you need a good inliner for it |
| 20:11:57 | Araq | and you need to do some tricks so that the "returns" are predicted by the CPU as good as an ordinary return |
| 20:12:44 | zahary | I personally find promises really beatiful and easy to work with in the projects where I've used them and the with the iced model it's harder to imagine what's actually going to happen (to execute the code in your head to to speak) |
| 20:13:50 | Araq | I'm still thinking how to do error handling with my approach :P |
| 20:13:56 | zahary | it's nice to see this await / defer span other control flow structures, but it's easy to translate their code to regular promises |
| 20:20:05 | Araq | the gist is very convincing though |
| 20:20:49 | Araq | things that don't compose properly are not good design |
| 20:21:00 | zahary | well, this is really solved problem - you are not the first one to think about it. |
| 20:21:00 | zahary | it's not that exceptions are incompatible with async code - you can use them but they must be converted to rejected promises when they leave the async boundary of the code |
| 20:25:47 | Araq | so as far as I can see Nimrod's yield implementation is just fine for promises, right? |
| 20:26:03 | zahary | yes, it's fine |
| 20:26:08 | Araq | it's just that the API will be more complex than I would prefer |
| 20:26:34 | zahary | this is the runtime stack with async code: epoll() -> thin_net_framework_layer() -> user_iterator() - you don't want the exception from the user code to go through thin_network_layer, you want anyone waiting on the job the user_iterator is performing (download files for instance) to be notified that it failed |
| 20:27:51 | zahary | now imagine what this waiting code looks like - it itself waits on the promise |
| 20:27:51 | zahary | await download_files() - so this promise gets rejected and possible handled here or otherwise just result in further rejection of the bigger async job that has "download files" as part of it |
| 20:31:25 | Araq | I dunno, in sync mode an exception isn't propagated to multiple "listeners" either |
| 20:31:44 | zahary | well, multiple listeners is just a convenience |
| 20:32:26 | zahary | most of the code has single listener - multiple listeners are cool, because they allow you to write some abstracted code that works over "any task" |
| 20:32:47 | Araq | can't think of a really useful example for that; maybe for UIs ... |
| 20:33:07 | zahary | for example, in AJAX powered website, you want to add hourglass to any operation that talks to the network |
| 20:33:39 | Araq | UIs yes :P |
| 20:34:03 | zahary | no problem - it just hooks all ajax promises and add onProgress, onComplete callbacks that update the hourglass |
| 20:35:12 | zahary | in practice, it's easy to find useful application of this capability once you have it |
| 20:36:05 | Araq | dunno, "list of listeners" is one of my favourite anti patterns |
| 20:36:15 | zahary | heresy :) |
| 20:36:31 | Araq | say if you notify every item/task that a new item(task arrived |
| 20:36:35 | zahary | publish/subscribe is one of the best things ever in my book :) |
| 20:37:00 | Araq | congratulations you transformed O(1) into O(n) for 'append' |
| 20:37:53 | zahary | well, why would I notify every other item? it's publish/subscribe - only who really cares should subsribe |
| 20:37:53 | Araq | I prefer 'pull' over 'push' for that reason |
| 20:38:13 | Araq | yeah but if you have some filter that comes afterwards |
| 20:38:19 | FreeArtMan | O(n) => n < 1.0 =D |
| 20:38:34 | Araq | then the publisher has no choice to but to publish it to everyone |
| 20:38:53 | zahary | the publisher calls event.fire() |
| 20:39:37 | Araq | "pull" == "ok, I really need it" |
| 20:39:48 | Araq | "push" == "here, may be interesting to you" |
| 20:39:50 | zahary | whoever called event.subscribe do: … gets notifed. I agree that filtering now events would be bad, but why does the design require such filters? |
| 20:40:00 | zahary | it unified multiple events into one? |
| 20:40:22 | Araq | I guess it's mostly bad coding ;-) |
| 20:41:49 | Araq | but I can see why it's pretty useful for game programming ;-) |
| 20:43:07 | zahary | well, the real reason it's useful is because it allows for reusable code |
| 20:43:31 | Araq | it decouples stuff, yeah |
| 20:44:31 | Araq | maybe one more reason why I don't like it :P |
| 20:44:52 | zahary | you don't like code reuse? |
| 20:45:10 | Araq | decoupling often makes debugging harder |
| 20:45:31 | Araq | and I spend most of my time debugging things |
| 20:45:58 | zahary | the fact that code reuse is broken in most language is the single greatest reason why I'm interested in languages like nimrod |
| 20:46:52 | * | XAMPP_ quit (Quit: Leaving) |
| 20:47:08 | * | XAMPP joined #nimrod |
| 20:48:41 | Araq | when you have g(f(x)) it's pretty obvious how to debug it; make it a[i] = f(x); g(a[i]) and you have a much harder time; because now you have to find out where the wrong write operation occured |
| 20:49:11 | Araq | I'm using a[i] here for some indirections |
| 20:49:34 | Araq | possibly persisting it into a database and using it much later |
| 20:50:01 | Araq | but it's the old "mutable state is evil" thing and I digress |
| 20:51:23 | zahary | we should talk one day about reversable debuggers btw (debugging backwards in time) |
| 20:51:23 | zahary | while it's true that indirection adds to complexity, it's really a small price to pay for enabling the creating of reusable libraries - reusing a library that have been debugged and optimized for 10 years is much greater reduction in complexity |
| 20:56:44 | Araq | I don't disagree |
| 20:57:23 | Araq | I tried some reversable debugger for C |
| 20:57:29 | Araq | can't remember its name |
| 20:57:39 | Araq | was some comercial GNU debugger addition |
| 20:57:52 | FreeArtMan | zerobug? |
| 20:58:02 | Araq | but I was underwhelmed by its performance and documenation ;-) |
| 20:59:03 | zahary | reversable debuggers could really be improved with some high-level knowledge about the data types - instead of remembering the low level memory details of pushing an element to the sequence, just write "add element" event in the trace |
| 20:59:28 | zahary | I mean * to a sequence * (to serve as example) |
| 20:59:49 | Araq | yeah I read some papers about reversible computing |
| 21:00:10 | Araq | the consensus was that it's very hard and limited |
| 21:00:18 | Araq | iirc |
| 21:01:36 | zahary | I've read some papers too and I though about it for a while and I'd love to try implementing the concept at some point in the future |
| 21:02:22 | zahary | it's like compile-as-a-service to me - eventually inevitable development of technology |
| 21:03:54 | Araq | interestingly there were some algorithms that interact very badly with a generational GC |
| 21:04:06 | Araq | I can't remember the details |
| 21:04:20 | Araq | but ML really lost against C because of this |
| 21:04:21 | zahary | it's not really reversable computing btw - the easier approach is to use tracing (record a log of what is happening) |
| 21:04:38 | Araq | true they are different |
| 21:04:46 | Araq | logging is much easier :-) |
| 21:04:49 | zahary | you can then reply the log to arrive at any point in time |
| 21:05:41 | Araq | yeah and it's only a macro away |
| 21:06:07 | Araq | logging for every 'if' with the values involved in the condition makes a pretty decent "explain" system |
| 21:09:47 | Araq | problem is: if you automate it too much, you quickly get lost in too much data |
| 21:10:45 | zahary | have you watched this: |
| 21:10:46 | zahary | http://www.youtube.com/watch?v=xpI8hIgOyko |
| 21:10:59 | zahary | the interface is the amazing thing that hooked me up |
| 21:13:13 | gradha | 6 year old video about backwards debugging, seems like a pun |
| 21:15:18 | gradha | offtopic: does somebody use bash/readline completion-prefix-display-length feature? |
| 21:15:19 | zahary | the video is really cool, recommended - it's hard to implement these systems even now, but as I said the debugging experience is so much greater that the development is inevitable |
| 21:15:38 | Araq | ha, I actually watched it |
| 21:15:45 | Araq | noticed it only works for java and lost interest :P |
| 21:16:16 | zahary | :) try to ignore that |
| 21:17:30 | Araq | in fact, visual studio supports reverse debugging |
| 21:17:52 | Araq | I don't use it ;-) |
| 21:17:58 | zahary | not in the same way as shown in the video |
| 21:18:08 | Araq | yeah it can only go back a few lines or something |
| 21:18:13 | zahary | but also proves my point that microsoft are working on it :) |
| 21:19:15 | gradha | microsoft research tends to do fun stuff, shame it rarely reaches a real/commercial product |
| 21:20:24 | Araq | gradha: I don't know what a bash/readline completion-prefix-display-length feature is ... |
| 21:20:38 | gradha | mauaha, but I'm glad you asked |
| 21:21:04 | gradha | it's a feature I proposed around 2003 http://lists.gnu.org/archive/html/bug-bash/2005-12/msg00022.html |
| 21:21:28 | gradha | it reduces visual clutter when completing filenames with tab (or anything using readline really) |
| 21:22:10 | gradha | example inside nimrod's examples directory: |
| 21:22:11 | gradha | $ ls cross_...calculator/ ...todo/ |
| 21:22:21 | gradha | so you type cross_<tab> |
| 21:22:32 | gradha | and instead of showing again the prefix in the suggestions it shows the ellipsis |
| 21:22:52 | gradha | the nice thing is you can visually see the first character to disambiguate the completion conflict |
| 21:23:04 | gradha | it's really really sweet, especially for long filenames |
| 21:23:25 | gradha | I had forgotten about it but got included in readline 6.0, released around 2009 |
| 21:23:44 | Araq | aha |
| 21:23:50 | Araq | well my bash doesn't do that |
| 21:24:01 | gradha | now even poor mac users like me can enjoy it (using macports, though) |
| 21:24:14 | gradha | you only need to add something like "set completion-prefix-display-length 3" to .inputrc |
| 21:24:20 | gradha | weren't you on linux? |
| 21:24:30 | gradha | I would expect that to have updated versions |
| 21:24:33 | Araq | yes I am |
| 21:26:10 | dom96 | Araq: So i'm looking at your tags in the sockets module. Shouldn't bindAddr be FWriteIO? |
| 21:27:20 | gradha | the completion prefix is disabled by default, you would need to update your .inputrc and start a new shell to see if it works |
| 21:27:58 | dom96 | gradha: I recently switched from Bash to zsh. |
| 21:28:50 | gradha | it should be available there too if zsh uses gnu's readline, does it? |
| 21:28:59 | dom96 | i have no idea |
| 21:29:23 | Araq | gradha: doing it right now |
| 21:30:19 | Araq | doesn't work |
| 21:31:04 | Araq | dom96: should it? I dunno |
| 21:31:14 | Araq | binding an address is no write operation, is it? |
| 21:31:35 | Araq | it doesn't send anything over the socket |
| 21:32:58 | dom96 | sure, but it 'binds' the socket to an address and port. |
| 21:33:26 | dom96 | Seems more of a write than a read. |
| 21:34:37 | Araq | really? who is the receiver then? |
| 21:34:57 | dom96 | The OS? |
| 21:35:11 | Araq | doesn't count :P |
| 21:35:45 | dom96 | Well it changes the state of the environment, so it's a write no? |
| 21:36:08 | gradha | Araq: the option completion-prefix-display-length is listed in my "man readline" page, you could check that to see if your distro has included it, and if not bug the maintainers |
| 21:36:25 | Araq | pretty much every effect results in a write on the OS level |
| 21:36:31 | Araq | so that doesn't count |
| 21:36:54 | Araq | reading from a file updates the current file position |
| 21:37:06 | Araq | but that's not the point of the effect system |
| 21:37:56 | dom96 | hrm, I guess that makes sense. |
| 21:37:58 | * | gradha quit (Read error: Connection reset by peer) |
| 21:39:22 | * | gradha joined #nimrod |
| 21:39:33 | Araq | I wanted to emphasize the "lookup" aspect of bindAddr instead so I picked FReadIO |
| 21:39:50 | Araq | however the more abstract FIO would be fine too |
| 21:41:48 | Araq | completion-prefix-display-length (0) |
| 21:41:50 | Araq | The length in characters of the common prefix of a list of pos‐ |
| 21:41:51 | Araq | sible completions that is displayed without modification. When |
| 21:41:53 | Araq | set to a value greater than zero, common prefixes longer than |
| 21:41:54 | Araq | this value are replaced with an ellipsis when displaying possi‐ |
| 21:41:56 | Araq | ble completions. |
| 21:41:59 | Araq | so yeah, the manual says it exists |
| 21:42:17 | gradha | in that case you should research why .inputrc is not being read by your shell |
| 21:42:28 | gradha | or maybe it's another file on your system? |
| 21:42:36 | Araq | well I modified .bashrc ... |
| 21:43:20 | gradha | that's different, bash and readline are separate entities and have their own etc files |
| 21:43:32 | gradha | or so do the man pages say, at least |
| 21:43:37 | Araq | indeed it works with .inputrc :D |
| 21:43:41 | gradha | awesome |
| 21:44:00 | Araq | now if only it would be the default :P |
| 21:44:11 | gradha | yeah, such a simple feature and makes life so much easier |
| 21:44:42 | Araq | sane defaults are not open source's strength :P |
| 21:44:55 | gradha | sad but true |
| 21:45:12 | Araq | how else can you sell support? ;-) |
| 21:47:49 | Araq | now what's the switch to make autocompletion case insensitive? |
| 21:48:13 | gradha | maybe completion-ignore-case |
| 21:49:49 | Araq | thanks |
| 21:51:39 | gradha | btw, I updated https://github.com/Araq/Nimrod/issues/174 but I'm afraid I'm not making much sense in my comments so I defaulted to zipping you all the files and let you figure out the problems |
| 21:53:07 | gradha | heh, sorry |
| 21:53:50 | gradha | as said before, if you let some time go I will eventually reach this and try to fix it myself, so don't waste too much time with it |
| 21:54:30 | * | Trix[a]r_za is now known as Trixar_za |
| 21:55:08 | Araq | alright |
| 21:55:26 | Araq | I'm making doc2 the default for the documentation instead ;-) |
| 21:55:46 | Araq | so gradha take a look at the db_ modules |
| 21:56:36 | Araq | they now list their effects but I cheated a bit |
| 21:56:48 | gradha | cheated? |
| 21:57:17 | Araq | insert only lists FWriteDB but you could pass arbitrary SQL to it |
| 21:57:44 | Araq | maybe 'getRow' is a better example |
| 21:58:17 | Araq | the SQL could delete the entire database and yet getRow pretends to only read from the DB |
| 21:58:32 | gradha | uff, I would have settled for FDBIO and called it a day |
| 21:58:38 | Araq | I don't think there is a better solution though |
| 21:58:55 | Araq | you can indeed only care about FDb ... |
| 21:59:14 | gradha | neither do I, unless you restricted some custom procs to specific actions, as in the module builds the sql statement itself |
| 21:59:54 | Araq | well the sql query is already a distinct string to prevent against sql injection attacks |
| 22:01:31 | Araq | zahary: is there a reason why skLocalVars lacks 'skResult'? |
| 22:02:05 | zahary | nope, it's a oversight |
| 22:02:35 | Araq | alright |
| 22:02:52 | dom96 | Araq: connect is FWriteIO if the socket is an ssl socket. :P |
| 22:03:14 | dom96 | but I suppose that doesn't really matter. |
| 22:03:38 | Araq | that's a hard one, the effect is static |
| 22:03:50 | Araq | you can't model that 'if' |
| 22:04:18 | dom96 | yeah, well you marked ``handshake`` as FReadIO, FWriteIO... actually you made a typo there lol |
| 22:04:40 | Araq | what typo? |
| 22:04:47 | dom96 | {.tags: [FReadIO, RWriteIO].} |
| 22:05:05 | Araq | er, ... the compiler should have caught that |
| 22:05:17 | Araq | ah but it's in a 'when' statement, right? |
| 22:05:29 | dom96 | yeah |
| 22:06:21 | Araq | I still think it's much nicer than having everything in an underspecified IO monad :P |
| 22:07:32 | Araq | zahary: the C backend also seems to not zeroMem the result sometimes |
| 22:08:02 | Araq | I noticed it with the new first class iterators |
| 22:08:07 | dom96 | Araq: Why didn't you simply annotate the posix wrapper? |
| 22:08:09 | zahary | skLocalVars is quite new |
| 22:08:28 | Araq | but I haven't looked into the issue yet |
| 22:08:58 | Araq | dom96: it's much more flexible this way |
| 22:09:08 | Araq | I can deliberately hide effects this way |
| 22:09:13 | Trixar_za | My connection sucks :( |
| 22:09:24 | dom96 | ahh, alright. |
| 22:09:55 | Araq | Trixar_za: read the logs then instead, I often do that too |
| 22:10:20 | Trixar_za | Yeah, I do that for for here, my own network's main channel and slitaz (all logged) |
| 22:10:27 | Trixar_za | Kind of sucks for other things though |
| 22:10:54 | Trixar_za | Since I'm struggling I started wondering if I could write a dialer |
| 22:11:28 | Araq | what about changing the main aim for slitaz? |
| 22:11:44 | Araq | I don't really need a distro that runs all from RAM |
| 22:11:46 | dom96 | Araq: hrm, wouldn't a FBlocking effect be useful? |
| 22:12:26 | Araq | hrm, indeed |
| 22:13:02 | Araq | but then this doesn't really work because it works with async sockets too |
| 22:13:05 | Trixar_za | Not really the aim Araq. Just to be small and to run on older hardware. The runs in ram thing is just a LiveCD/LiveUSB gimmick. |
| 22:13:26 | Trixar_za | Which TinyCore ran a mile with |
| 22:14:17 | dom96 | Araq: Damn, yeah. :\ |
| 22:15:28 | Trixar_za | Speaking of TinyCore, I tried it the other day. I kind of liked it. It was simple with a set purpose. |
| 22:17:28 | gradha | wrt the FReadDB/FWriteDB I would now create FDBIO and let FReadDB/FWriteDB inherit from that, so maybe in the future more orm-like procs which constructed their sql statements could guarantee the tags, otherwise nothing prevents you from concatenating "; DROP table;" to even getRow. Though you would have to be a really mean programmer to do that yourself. |
| 22:17:56 | gradha | in fact, maybe FDBIO is not needed at all and plain IO, or maybe you could have a db_ module with in ram database? |
| 22:18:59 | gradha | you can create an in memory sqlite database http://www.sqlite.org/inmemorydb.html so I don't think tags help much in that situation |
| 22:19:18 | dom96 | Araq: A way to guarantee that a function will not block would be nice I think. |
| 22:19:42 | Araq | argh ... FReadDb should inherit from FDb ... |
| 22:19:47 | Araq | not from FReadIO |
| 22:20:24 | Araq | gradha: it doesn't matter if the database is in RAM or on some disc; that's not the point |
| 22:20:43 | Araq | the point is that I can do: |
| 22:21:16 | Araq | proc main() {.tags: [db_sqlite.FReadDb, db_mysql.FWriteDb].} = ... |
| 22:21:41 | Araq | and the compiler validates that I'm reading from the sqlite database and writing to the mysql database |
| 22:22:13 | Araq | ok, parametrized effects would be even more useful for this |
| 22:22:44 | Araq | but also more work to implement |
| 22:22:54 | gradha | but wouldn't you have to implement a complete sql parser to validate that? |
| 22:23:20 | Araq | ok, it "validates" it with the tags only |
| 22:23:32 | gradha | and something you can't guarantee at runtime if the program builds the sql |
| 22:23:58 | Araq | true but the distinct string tries to prevent that |
| 22:24:13 | Araq | so it's much better than nothing already |
| 22:25:13 | Araq | oh btw |
| 22:25:28 | Araq | we have a quite complete SQL parser in the stdlib ... |
| 22:26:52 | gradha | interesting type hapiness... |
| 22:28:44 | * | ekselkiu quit (Ping timeout: 260 seconds) |
| 22:30:51 | Araq | parsing the query and assertion it doesn't contain a 'drop' command is a sweet idea :-) |
| 22:30:51 | * | gradha quit (Read error: Connection reset by peer) |
| 22:32:21 | * | FreeArtMan quit (Ping timeout: 265 seconds) |
| 22:36:38 | Araq | zahary: what about supporting 'yield promise except EIO' directly in the language? |
| 22:36:39 | * | NimBot_ joined #nimrod |
| 22:36:40 | * | NimBot_ quit (Remote host closed the connection) |
| 22:37:21 | * | NimBot_ joined #nimrod |
| 22:38:30 | dom96 | !lag |
| 22:38:31 | NimBot | 7ms between me and the server. |
| 22:38:31 | NimBot_ | 95ms between me and the server. |
| 22:38:35 | dom96 | interesting |
| 22:39:55 | Araq | if the event loop wraps every exception via 'try except: send(getCurrentException())' we lose exception tracking ... |
| 22:44:50 | reactormonk | !lag |
| 22:44:50 | NimBot | 7ms between me and the server. |
| 22:44:50 | NimBot_ | 95ms between me and the server. |
| 22:47:05 | * | NimBot_ quit (Remote host closed the connection) |
| 22:47:39 | * | NimBot_ joined #nimrod |
| 22:47:47 | Araq | !lag |
| 22:47:47 | NimBot | 7ms between me and the server. |
| 22:47:47 | NimBot_ | Unknown. |
| 22:47:53 | Araq | !lag |
| 22:47:53 | NimBot | 7ms between me and the server. |
| 22:47:54 | NimBot_ | 100ms between me and the server. |
| 22:48:42 | Araq | NimBot hinders NimBot_ ... |
| 22:48:51 | dom96 | They're at war. |
| 22:48:59 | dom96 | The old one doesn't want to be replaced. |
| 22:49:03 | Araq | yeah and NimBot always wins |
| 22:49:17 | dom96 | But NimBot doesn't trust anyone. |
| 22:49:23 | Araq | kick Nimbot and see what happens |
| 22:49:34 | dom96 | !trusted |
| 22:49:34 | NimBot_ | Trusted users: dom96@unaffiliated/dom96 |
| 22:49:59 | dom96 | hah. If only it had auto-rejoin logic... |
| 22:51:24 | dom96 | I am curious what causes this though |
| 22:51:32 | dom96 | Quite a big difference |
| 22:51:44 | dom96 | omg |
| 22:51:47 | dom96 | I know what it is. |
| 22:52:05 | Araq | epochTime vs cpuTime? |
| 22:52:09 | dom96 | [NimBot_] morgan.freenode.net :Chicago, IL, USA |
| 22:52:14 | dom96 | [NimBot] wolfe.freenode.net :Manchester, England |
| 22:52:18 | Araq | lol |
| 22:52:18 | dom96 | lol |
| 22:52:33 | Araq | can't believe you missed *that* :P |
| 22:52:33 | dom96 | Mystery solved |
| 22:52:48 | dom96 | You missed it too :P |
| 22:52:59 | * | NimBot_ quit (Remote host closed the connection) |
| 22:52:59 | Araq | lol? |
| 22:53:22 | * | NimBot_ joined #nimrod |
| 22:53:33 | Araq | now stop it |
| 22:53:40 | dom96 | yeah yeah |
| 22:53:44 | dom96 | btw join #nimbuild |
| 22:56:17 | Araq | so ... is nimbuild done yet? |
| 22:56:37 | dom96 | not really |
| 22:56:57 | dom96 | But I am in the process of setting it up so that it can be tested. |
| 22:57:33 | Araq | ok |
| 22:57:46 | Araq | ping zahary |
| 23:04:01 | dom96 | ok, everything is running. |
| 23:16:56 | Araq | excellent |
| 23:18:16 | dom96 | :O |
| 23:18:29 | dom96 | Well, it didn't crash yet :D |
| 23:18:40 | dom96 | Take a look: http://build.nimrod-code.org/beta |
| 23:19:58 | Araq | sweet |
| 23:21:00 | dom96 | aww, the current commit hash got reset |
| 23:24:49 | Trixar_za | That looks awesome |
| 23:26:02 | dom96 | thanks :) |
| 23:26:14 | * | q66 quit (Quit: Quit) |
| 23:30:01 | dom96 | good night |
| 23:30:42 | Trixar_za | Goodnight dom96 |
| 23:30:55 | Trixar_za | Also how did an hour and half go by without me noticing? |
| 23:31:10 | Araq | Trixar_za: alcohol? |
| 23:31:28 | Trixar_za | Nope, I'm sober. But I did fix a minor bug |
| 23:31:34 | Trixar_za | But no way that took an hour... |
| 23:32:25 | Trixar_za | I was a little surprised that it worked exactly like I wanted the first time I tested it |
| 23:33:05 | Araq | you should finally code in nimrod; I heard some people are willing to help in this channel ... |
| 23:35:36 | Trixar_za | Really? I never noticed :P |
| 23:38:51 | Araq | that's because people don't have problems with nimrod, it simply works :P |
| 23:39:05 | Araq | so instead we can rant about unix all the time |
| 23:40:57 | Trixar_za | Ah, my other past time |
| 23:49:39 | Trixar_za | Eh, what the hell |