| 01:57:48 | * | shevy joined #nimrod |
| 04:20:16 | * | btbytes joined #nimrod |
| 04:20:31 | * | btbytes left #nimrod (#nimrod) |
| 04:22:49 | * | btbytes joined #nimrod |
| 06:27:26 | * | btbytes left #nimrod (#nimrod) |
| 07:25:23 | * | nolan1 joined #nimrod |
| 07:33:32 | reactormonk | Araq, can the idetools tell about type errors or do I just parse the error messages for that? |
| 10:29:59 | * | q66 joined #nimrod |
| 13:30:08 | dom96 | reactormonk: You can use 'nimrod check' but parsing the error messages from that is not exactly trivial. |
| 15:37:19 | * | XAMPP joined #nimrod |
| 17:37:37 | * | gradha joined #nimrod |
| 17:50:39 | gradha | I'm looking at the algorithm and sequtils modules but I can't figure if it's possible to write a one liner to transforms the string keys of a table into a sequence of integers |
| 17:50:57 | gradha | at the moment I'm doing "for key in table.keys(): |
| 17:51:04 | gradha | int_list.add(key.parseInt) |
| 17:51:25 | gradha | the equivalent python one liner with list comprehension would be int_list = [int(x) for x in table.keys()] |
| 17:52:07 | gradha | also, now I write "var int_list : seq[int]" and another line "int_list = @[]" to initialize |
| 17:52:29 | gradha | maybe there's a less caveman way of doing that |
| 17:53:17 | gradha | it seems that sequtils would welcome a "map" template, similar to filter, but which returns the applied proc without filtering |
| 17:53:40 | dom96 | gradha: http://build.nimrod-code.org/docs/system.html#513 |
| 17:54:10 | gradha | I was just going to say that "map" in the index links to the htmlgen module |
| 17:54:34 | dom96 | for some reason or other Araq decided to name it "each" instead of "map". |
| 17:55:01 | gradha | I'm more worried about how many other perls might be hidden in system |
| 17:55:16 | gradha | yet it's so big it scares reading through it from a to z |
| 17:56:43 | dom96 | what do you suggest we do to fix that? |
| 17:57:25 | gradha | at the moment the only thing I can think of is putting a prominent link in sequtils documentation linking the system map |
| 17:57:44 | gradha | that's were the "functional" like procs are found, but map was missing |
| 17:58:05 | gradha | *adding to my todo list* |
| 17:58:42 | dom96 | ideally, the index should list 'map' as an alias for 'each' to make it easier to search |
| 17:59:00 | gradha | I think I can make that work too |
| 17:59:12 | dom96 | I think there might be a pragma or something to do that |
| 18:05:59 | dom96 | see you later |
| 18:06:08 | gradha | bye |
| 18:24:29 | * | nolan1 joined #nimrod |
| 18:39:01 | gradha | Araq: what is the encoding of literals found in nimrod code? is it guaranteed they are utf8? |
| 18:40:05 | gradha | s/nimrod code/nimrod source code/ |
| 19:30:24 | gradha | meh, looks like I'm out of luck with functional http://pastebin.com/1nrWZKJU |
| 19:30:46 | gradha | Araq: tell me if that's the return value bug or something new you want a github issue |
| 20:01:16 | reactormonk | what did you use for the dependency management part of babel? Just write your own algo? |
| 21:46:15 | * | gradha joined #nimrod |
| 22:54:20 | dom96 | reactormonk: well. Currently there is no dependency management; it's not implemented yet. |
| 22:54:44 | reactormonk | libalpm? ;-) |
| 22:57:06 | dom96 | libalpm doesn't seem to be documented at all. |
| 22:59:56 | reactormonk | that's likely |
| 23:00:09 | reactormonk | And I assume dpkg is a monster |
| 23:00:54 | dom96 | yeah. Also, I dislike such dependencies :P |
| 23:01:16 | dom96 | But then again, it would be better than nothing. |
| 23:02:38 | reactormonk | http://scholar.google.com/scholar?q=dependency+management+algorithm ^^ |
| 23:03:49 | dom96 | I wish I had enough time to implement all this stuff. |
| 23:04:05 | reactormonk | more like energy? |
| 23:04:26 | dom96 | That too. |
| 23:04:54 | reactormonk | I assume a quick & dirty implementation will do - but reading one or two good papers may help |
| 23:08:22 | dom96 | Would be awesome if you could implement it :) |
| 23:08:35 | reactormonk | I know. |
| 23:08:59 | reactormonk | But let's go shopping for now. |
| 23:11:06 | reactormonk | dom96, quick thoughts: how about enforcing the API not to change in a minor version? |
| 23:11:10 | reactormonk | Static analysis ftw |
| 23:11:49 | dom96 | interesting idea |
| 23:12:12 | dom96 | that would be a nice feature yes. |
| 23:12:20 | dom96 | But might annoy some people. |
| 23:12:51 | reactormonk | Sure it will. But it also enables you to say 'works with this version, so we can go up to the next major version' |
| 23:13:47 | gradha | not like a proc won't change behaviour just because it keeps it's prototype... |
| 23:14:48 | dom96 | There are definitely more important things to consider with babel. |
| 23:15:02 | reactormonk | sure. And typing doesn't guarantee semantics |
| 23:15:04 | * | dom96 is still not satisfied with the current way it works |
| 23:20:40 | gradha | so I got "Error: unhandled exception: error while reading from file [EIO]", how do I check what's the actual error? |
| 23:21:09 | dom96 | that is the actual error, what do you mean? |
| 23:21:18 | gradha | something went wrong, but I don't know what |
| 23:21:34 | gradha | I just get an exception thrown out, and the program stops with a backtrace |
| 23:21:53 | dom96 | don't you get a traceback? |
| 23:22:02 | gradha | yes, to input.readAll() |
| 23:23:06 | dom96 | Anything in the readAll proc? |
| 23:23:25 | gradha | time to dig in |
| 23:23:43 | dom96 | yes, most likely. |
| 23:23:59 | gradha | oh, readAll presumes the file position is zero when it is called |
| 23:24:07 | gradha | since I called setFilePos that's invalid |
| 23:24:15 | dom96 | there you go |
| 23:24:34 | dom96 | perhaps that's a bug with readAll? |
| 23:25:11 | gradha | wait, it's not, rawFileSize is more complicated |
| 23:26:11 | gradha | it could be a bug in ftell/fseek, meh, time to log everything |
| 23:26:39 | dom96 | Why is there two readAll with the same prototype in system? 0_o |
| 23:28:02 | dom96 | That looks like a bug. |
| 23:30:09 | gradha | the source I'm looking at has a single readAll |
| 23:30:49 | * | AlexLibman joined #nimrod |
| 23:30:58 | gradha | confirmed, rawFileSize returns the whole file size, so readAll presumes you won't have seeked inside of it |
| 23:31:07 | gradha | maybe I could add a readRest? |
| 23:31:07 | dom96 | the docgen is failing I guess |
| 23:31:31 | dom96 | maybe readAll should check this? |
| 23:31:51 | dom96 | rawFileSize-filePos? |
| 23:31:52 | gradha | yes readAll could be made more lax to allow this |
| 23:32:51 | gradha | it's funny that rawFileSize considers the fseeked case and returns to the previous position |
| 23:38:48 | dom96 | maybe there is a reason readAll behaves this way |
| 23:39:34 | gradha | follow your own bug!... err... adventure! https://github.com/Araq/Nimrod/issues/298 |
| 23:41:43 | dom96 | lol |
| 23:51:30 | dom96 | "# do not blame me; blame the ANSI C standard this is so brain-damaged" |
| 23:51:33 | dom96 | :D |
| 23:52:10 | gradha | hardly any news |
| 23:56:36 | gradha | wow, nimrod actually has references to clearerr, though not in the expected places |
| 23:57:07 | dom96 | to what? |
| 23:57:27 | gradha | if you read EOF you are supposed to call clearerr() if you plan on doing anything else with the stream |
| 23:57:38 | gradha | I guess the number of cases is so small nobody ever cares |
| 23:57:49 | dom96 | I see |
| 23:57:55 | gradha | or wait, maybe it's not feof, errno in general |
| 23:58:12 | gradha | the manpage isn't that clear either |
| 23:58:35 | gradha | ah, yes, eof requires clearerr |
| 23:59:46 | gradha | I wonder if this is useful for processes which read files other processes are appending to and then you need to seek back or something |