| 00:52:24 | NimBot | nimrod-code/Aporia ab6539e Dominik Picheta [+0 ±2 -0]: Language comment syntax is now updated when changing syntax highlighting... 2 more lines |
| 00:52:24 | NimBot | nimrod-code/Aporia 432b07d Dominik Picheta [+0 ±2 -0]: Hidden language definitions are now respected as being hidden. |
| 00:52:24 | NimBot | nimrod-code/Aporia f0910d0 Dominik Picheta [+0 ±2 -0]: Better user feedback when trying to Comment lines when no comment... 2 more lines |
| 00:52:24 | NimBot | nimrod-code/Aporia 8b0ee78 Dominik Picheta [+0 ±2 -0]: Opening files through the Recently opened files menu now adds the open... 2 more lines |
| 01:40:39 | * | q66 quit (Quit: Quit) |
| 06:47:38 | * | XAMPP_8 quit (Ping timeout: 245 seconds) |
| 08:51:09 | * | fowl joined #nimrod |
| 11:44:30 | * | Araq_ joined #nimrod |
| 11:56:46 | * | Araq_ quit (Quit: ChatZilla 0.9.89 [Firefox 17.0.1/20121128204232]) |
| 12:14:47 | NimBot | nimrod-code/Aporia 2c9db51 Dominik Picheta [+0 ±2 -0]: Fixed some Windows calling convention issues. |
| 12:53:30 | * | q66 joined #nimrod |
| 14:43:56 | * | XAMPP-8 joined #nimrod |
| 15:11:02 | * | XAMPP-8 quit (Quit: Leaving) |
| 16:49:55 | * | gradha joined #nimrod |
| 16:50:58 | gradha | given "var t1 = "Hello"; var t2 : pointer = addr(t1)" how do I dereference t2 back into a string? |
| 16:57:29 | dom96 | cast[ptr string](t2)[] |
| 17:06:10 | gradha | it's interesting that echo repr(addr(var)) doesn't output the same thing as assigning the addr to a variable and repr'ing the variable |
| 17:06:37 | gradha | in the first case it shows an arrow and the value the address is pointing to, in the second only the address |
| 17:07:49 | gradha | is it because addr doesn't return a pointer type, but whatever it returns can be assigned to a var of pointer type? |
| 17:10:11 | gradha | so doing the cast for repr works, so pointer is a generic address and "ptr type" is a pointer to a certain type and repr can extend the information then |
| 17:21:07 | gradha | zahary1 or zahary_: if you use the JumpToDef() inside vim and this action would open a file which you have opened in another vim instance, the editor seems to hang, but really it is waiting for you to say if you are ok with opening the file in read only mode |
| 17:21:46 | gradha | zahary1 or zahary_: pressing enter open the file in read only mode, do you know if JumpToDef() could be made to open the file always in read only mode instead of asking? |
| 18:07:40 | * | FreeArtMan joined #nimrod |
| 18:52:27 | Araq | gradha: indeed 'repr' uses only the information available at compile-time |
| 18:52:40 | Araq | perhaps it supports inheritance, I dunno ;-) |
| 19:17:36 | gradha | if there is a proc using a generic, is it ok if I specify the generic in the call? say myProc[string]() |
| 19:56:51 | * | FreeArtMan quit (Quit: Leaving) |
| 20:41:35 | reactormonk | what's the syntax again for defining procs inline? |
| 20:41:42 | reactormonk | http://sprunge.us/eIXX |
| 20:45:53 | gradha | shouldn't it be "proc() =" since it doesn't return anything? |
| 20:48:09 | gradha | var foo = proc() = echo "foo" |
| 20:48:12 | gradha | foo() |
| 20:56:05 | reactormonk | http://sprunge.us/UNFZ |
| 20:56:08 | reactormonk | hm |
| 20:56:53 | gradha | maybe that doesn't work in the repl, works for me in a source file |
| 20:58:17 | gradha | yes, I can reproduce that in the interactive version, you will have to use a source file |
| 21:45:55 | Araq | gradha: I deliberately threw out 'cast' in tut1 |
| 21:46:11 | Araq | people overuse it |
| 21:47:02 | Araq | this low level stuff doesn't belong in tut1 |
| 21:47:54 | reactormonk | Araq, maybe important for talking to C apis? |
| 21:48:34 | Araq | I don't recall tut1 dealing with the FFI ... :P |
| 21:48:51 | reactormonk | Araq, do I have to parse the argstring myself from the idetools? |
| 21:49:07 | Araq | what is the argstring? |
| 21:49:18 | Araq | you mean the parameter list? if so then yes |
| 21:49:21 | reactormonk | yes. |
| 21:49:39 | reactormonk | got me the compiler code for that? |
| 21:50:58 | gradha | why not throw out addr as well? I see no point in explaining how to get pointers if you can't transform them to their original self back |
| 21:51:43 | Araq | addr is still in tut1? |
| 21:51:53 | Araq | sure, throw that out too then |
| 21:52:49 | dom96 | hello |
| 21:53:07 | Araq | gradha, what about #317 ? |
| 21:53:36 | Araq | we used to have a missing 'close' in that code but that should have been fixed months ago |
| 21:54:01 | gradha | I don't even know what is failing, the test suite is a little bit cryptic |
| 21:54:35 | gradha | how can I run that particular test case? |
| 21:55:04 | Araq | tester test tfile.nim iirc |
| 21:55:11 | Araq | tester.nim(138) callCompiler |
| 21:55:13 | Araq | osproc.nim(688) outputStream |
| 21:55:14 | Araq | os.nim(205) OSError |
| 21:55:16 | Araq | Error: unhandled exception: Too many open files [EOS] |
| 21:55:23 | Araq | how is that not clear? ;-) |
| 21:56:23 | gradha | well, so the problem is not in the server test case but in the tester suite program? talk about obvious |
| 21:58:09 | Araq | that's what I think, yes |
| 21:58:39 | Araq | I guess osproc still has some handle leak that only shows up for macosx |
| 22:29:16 | gradha | the stack trace doesn't make sense with the error "too many open files", since it's pointing at a close. Why would close() raise the exception of too many open files? |
| 22:30:05 | gradha | also, does koch redirect output? I added echos to osproc but I'm not seing them |
| 22:33:04 | gradha | ah, no, wrong files |
| 22:33:14 | gradha | that's why the echos weren't happening |
| 22:50:55 | * | XAMPP-8 joined #nimrod |
| 22:55:12 | gradha | Araq: if you are on linux what does ulimit -a tell you about number of open files? if on windows, what's the open file limit there? |
| 22:56:34 | dom96 | linux here: 1024 |
| 22:57:20 | gradha | the default on mac seems to be 256, when I reduce it to 30 the test suite fails earlier |
| 23:04:43 | dom96 | startProcess looks quite complex |
| 23:20:31 | * | q66 quit (Quit: Quit) |
| 23:23:10 | dom96 | hrm, "Go to definition" on one of the 'close' functions in osproc goes to the definition of TProcess |
| 23:27:55 | dom96 | gradha: Doesn't the stack trace point at a open? |
| 23:28:50 | gradha | I've added to https://github.com/Araq/Nimrod/issues/317 the most recent stacktrace |
| 23:30:23 | dom96 | I suspect that the fact that the (input/output/error)Stream functions seem like fields makes it really easy to call them in a loop, creating a lot of file descriptors. |
| 23:31:36 | dom96 | gradha: osproc.nim(688) outputStream is a call to open() from what I can see. |
| 23:34:13 | gradha | yes |
| 23:34:35 | dom96 | I believe I may have found the bug |
| 23:34:53 | dom96 | tester.nim:138 |
| 23:34:57 | dom96 | outp is never closed |
| 23:35:20 | gradha | isn't it closed on line 148? |
| 23:35:29 | gradha | or is that just closing "the parent"? |
| 23:36:56 | dom96 | PFileStream.close exists |
| 23:37:03 | dom96 | and calls close on the TFile |
| 23:37:08 | dom96 | please try closing 'outp' |
| 23:37:24 | dom96 | after the 'close(p)' call |
| 23:38:48 | dom96 | Araq: IMO this (input/output/error)Stream business is bad API design :P |
| 23:38:50 | gradha | argh, ulimit doesn't let me compile now |
| 23:39:04 | Araq | dom96: why? |
| 23:39:16 | Araq | it doesn't open anything |
| 23:39:38 | dom96 | it does |
| 23:39:43 | dom96 | It opens a TFile |
| 23:39:50 | Araq | and the close of TProcess is supposed to close everything that's necessary |
| 23:40:27 | dom96 | I recall calling outputStream in a loop and it failed with the "Too many open files" error. |
| 23:40:44 | Araq | lol |
| 23:40:50 | Araq | good you never fixed it :P |
| 23:41:07 | dom96 | I think I mentioned it to you :P |
| 23:43:01 | dom96 | But if I didn't, I apologise. |
| 23:43:34 | gradha | I'm running the test suite with the diff I added to https://github.com/Araq/Nimrod/issues/317 and seems to work |
| 23:43:52 | gradha | I'm running with ulimit -n 10 and it has well gone past the previous runs |
| 23:44:12 | dom96 | great |
| 23:44:13 | Araq | cool |
| 23:44:40 | dom96 | So we should get the TProcess object to store these streams or something like that. |
| 23:44:41 | Araq | I'd never imagined that wrapping the stream in a TFile uses up another file handle |
| 23:44:49 | Araq | dom96: true |
| 23:44:58 | Araq | and it should all be closed when you close the process |
| 23:45:05 | dom96 | yep. |
| 23:48:43 | gradha | while searching for this bug I found it actually worrying that you can have the open/close functions for a type in different files |
| 23:49:11 | gradha | it will really help if the doc tool will generate information related on type |
| 23:49:24 | gradha | or if the idetools would allow scanning for something like this |
| 23:50:32 | * | gradha quit (Quit: Leaving) |