| 00:03:35 | * | uku quit (Ping timeout: 272 seconds) |
| 00:08:35 | * | Demos joined #nimrod |
| 00:26:34 | * | kniteli quit (Ping timeout: 265 seconds) |
| 00:37:05 | ldlework | Araq: not sure how to interpret what you just said |
| 00:38:33 | * | kniteli joined #nimrod |
| 00:44:19 | Triplefox | i have only written a little bit each of nim and rust but based on the experiences i think of nim as a more pragmatic language and rust as an exploratory one |
| 00:45:32 | Triplefox | rust does not answer everything so if you use it you may be the explorer with arrows in your back |
| 00:48:13 | Triplefox | i do think the premise of zero-cost abstraction is seductive, just not really necessary for productive applications |
| 00:48:52 | flaviu | I'm debugging the buildbot on arm, it looks like koch is hanging on a syscall. |
| 00:49:02 | flaviu | it hangs strace D: |
| 00:49:19 | ldlework | Triplefox: what do you mean by zero-cost abstraction |
| 00:50:06 | flaviu | ldlework: Borrowed pointers I assume |
| 00:50:14 | fowl | i dislike the form of rusts macros |
| 00:50:25 | Triplefox | it is a term flung about by rustaceans, a use-case of borrowing |
| 00:51:14 | Triplefox | (of course, it is not really "zero" because you can't assume where the costs are so easily) |
| 00:51:51 | flaviu | It's zero enough for practical purposes |
| 00:52:18 | fowl | araqs approach of building ast imperatively is obviously the best. you can do complicated stuff at compiletime, often I am filling tables and looking up information from them in other macros |
| 00:55:21 | ldlework | That is pretty neat |
| 00:57:28 | fowl | someone said go's ability to say import github.com/blah/blah was neat, that was easy to do, the macro clones/updates the repository before the module is imported |
| 01:00:12 | flaviu | Hmm, looks like btrfs doesn't really want to play nice |
| 01:00:42 | fowl | i can see the draw of ADTs, thats probably the only thing i like about rust, their semantics are a bit confusing |
| 01:02:34 | * | darkf joined #nimrod |
| 01:02:55 | Triplefox | when i use the ADT features of haxe it is basically for two things: variant unions, and as a configuration DSL...not so much pattern matching going on, but maybe i'm just not encountering the right use-cases |
| 01:05:39 | * | kniteli quit (Ping timeout: 265 seconds) |
| 01:12:27 | * | saml_ joined #nimrod |
| 01:17:07 | * | kniteli joined #nimrod |
| 01:17:29 | Varriount | gokr: Have you seen the style guide? |
| 01:17:45 | ldlework | flaviu: what're you doing with btrfs? |
| 01:18:08 | flaviu | I have it on my arm device, which I'm using as a build slave |
| 01:18:27 | ldlework | gotcha |
| 01:18:44 | flaviu | I chose it on a whim, I'm just going to replace it with ext4 |
| 01:31:36 | Varriount | gokr: Also, whatever restart magic is placed on the 64 bit builder needs to be placed on the 32 bit builder. |
| 01:33:31 | * | mko quit (Quit: Bye.) |
| 01:36:14 | flaviu | Varriount: Can you force a build on linux-arm5-builder? |
| 01:41:44 | Varriount | Yes. |
| 01:41:54 | Varriount | flaviu: Did I not give you the admin credentials? |
| 01:42:04 | flaviu | nope |
| 01:44:30 | flaviu | BTRFS was getting stuck and causing all sorts of weird issues. I replaced it with ext4 and I want to see what happens |
| 01:45:40 | Varriount | By the way, I restarted the build master with a slightly different config - hopefully that will sort out issues with the tester. |
| 01:49:22 | flaviu | wrt the admin credentials, I'm fairly certain you're supposed to make multiple for auditing reasons |
| 01:51:58 | Varriount | flaviu: I will, however right now I want to get the main builds working. |
| 01:55:19 | * | phI||Ip_ joined #nimrod |
| 01:56:19 | * | phI||Ip quit (Ping timeout: 260 seconds) |
| 01:56:50 | * | Jesin quit (Ping timeout: 291 seconds) |
| 01:56:50 | * | biscarch quit (Ping timeout: 291 seconds) |
| 01:57:01 | * | Jessin joined #nimrod |
| 01:57:33 | * | JStoker quit (Ping timeout: 257 seconds) |
| 01:59:20 | * | biscarch joined #nimrod |
| 02:02:38 | * | JStoker joined #nimrod |
| 02:04:16 | * | JStoker quit (Excess Flood) |
| 02:08:06 | * | JStoker_ joined #nimrod |
| 02:08:07 | * | JStoker_ is now known as JStoker |
| 02:10:35 | * | JStoker quit (Excess Flood) |
| 02:10:55 | * | JStoker joined #nimrod |
| 02:18:02 | * | Jehan_ quit (Quit: Leaving) |
| 02:22:29 | * | q66 quit (Quit: Leaving) |
| 02:31:34 | onionhammer | C/C++ for android update: http://android-developers.blogspot.com/2014/11/utilities-for-cc-android-developers.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+blogspot%2FhsDu+%28Android+Developers+Blog%29 |
| 02:53:07 | * | brson quit (Quit: leaving) |
| 02:53:38 | * | brson joined #nimrod |
| 03:15:44 | * | brson quit (Ping timeout: 265 seconds) |
| 03:53:18 | flaviu | Ok, so `Normalized Binary Names` fails for linux-arm5-builder because it doesn't have a `python` executable |
| 03:54:32 | flaviu | I think, I'm not too sure. Symlinking python2 fixes things |
| 04:01:28 | Varriount | flaviu: Yeah. Later, I'll see about attaching a 'pythonexe' property to the slaves - that will let the build steps use the property to execute the right python binary. |
| 04:01:59 | flaviu | I also think I know why my builds were failing - I was running out of ram |
| 04:02:08 | flaviu | a swap file seems to keep things running |
| 04:02:35 | Varriount | flaviu: Something is up with the tester. It seems to be doing fine on Linux systems, but on windows, the build slave ins't getting any output. |
| 04:02:42 | Varriount | *isn't |
| 04:03:04 | Varriount | flaviu: Is it the release build that is taking up too much ram? |
| 04:03:36 | flaviu | looks like it. Keep in mind "too much ram" = 80MB |
| 04:05:30 | Varriount | flaviu: Ok, I'll also see about attaching a 'skip_release' property to your builder too. |
| 04:06:03 | flaviu | Ok, sounds good. |
| 04:07:21 | flaviu | Well, I've got to sleep. I'll see if it's finished in the morning :P |
| 04:10:20 | ldlework | So it looks like c2nim isn't going to create libtcod bindings automatically |
| 04:11:49 | * | flaviu quit (Ping timeout: 250 seconds) |
| 04:15:25 | ldlework | I think its because it is c++ |
| 04:24:36 | ldlework | hmm got it to work I think |
| 04:24:45 | ldlework | but man doing this to like 30 files |
| 04:25:26 | ldlework | I guess I could be doing it by hand |
| 04:35:04 | * | hsuh quit (Ping timeout: 255 seconds) |
| 04:36:44 | * | hsuh joined #nimrod |
| 04:38:13 | ldlework | hmm |
| 04:38:23 | ldlework | c2nim generated nim code that nim wont compile |
| 04:44:18 | ldlework | Is anyone around? |
| 04:50:17 | fowl | because it keeps c things like _PLATFORM_BASED_DEFINE that you need to remove |
| 04:50:35 | fowl | #ifdefs become when defined(...): ... |
| 05:02:24 | ldlework | fowl: it looks like nim straight up doesn't accept _PREFIXED_NAMES ? |
| 05:04:50 | fowl | correct |
| 05:06:38 | * | hsuh quit (Ping timeout: 255 seconds) |
| 05:06:39 | ldlework | fowl: damn this lib uses tons of preprocessor defines with _ prefixed names |
| 05:08:41 | * | hsuh joined #nimrod |
| 05:10:21 | * | saml_ quit (Quit: Leaving) |
| 05:11:04 | * | bjz joined #nimrod |
| 05:17:26 | * | max_coder joined #nimrod |
| 05:18:59 | * | max_coder left #nimrod (#nimrod) |
| 05:31:50 | Varriount | ldlework: ctrl+h is your best friend |
| 05:32:27 | ldlework | I feel like I'm oging to have to write a script |
| 05:32:33 | ldlework | to perform all the thingies I need to do |
| 05:32:43 | ldlework | ahem |
| 05:32:51 | ldlework | s/thingies/lexical transformations |
| 05:32:57 | * | ehaliewicz joined #nimrod |
| 05:33:03 | Varriount | ldlework: Or you could hack on c2nim |
| 05:39:31 | ldlework | Varriount: what would I do? |
| 05:39:39 | ldlework | make it transform _ names to ... not _ names? |
| 05:40:07 | ldlework | also I don't know anything about parsing let alone conversions and such |
| 05:40:14 | fowl | ldlework, many times just taking the _ out will give you an identifier thats something else |
| 05:40:32 | ldlework | fowl: right so there might be collisions |
| 05:40:41 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 05:41:20 | * | johnsoft joined #nimrod |
| 05:45:44 | Demos | ldlework, well you are gunna need to learn parsing and transformations to write good scripts in any case |
| 05:45:50 | Demos | and it is just generally a good thing to know |
| 05:51:02 | Varriount | Araq, dom96, gokr: I've extended the tester timeout to 3 hours, which should provide an intermediate solution to the build slaves killing the tester due to lack of output. |
| 05:56:17 | Varriount | Araq: Also, what Jehan said earlier about certain thread mechanisms not working on x64 may be true - I'm getting a lot of crash prompts (not just exceptions, but unhandled crashes) when tests are being run. |
| 05:56:38 | Varriount | Araq: Those are causing the Windows error reporting service boxes to come up. |
| 05:57:04 | Varriount | The tests that cause the boxes to come up mostly seem to deal with threading. |
| 06:05:47 | * | BlaXpirit joined #nimrod |
| 06:07:13 | ldlework | Demos: eh I was just thinking sed would do the trick :) |
| 06:07:38 | Demos | yeah, sometimes it does |
| 06:11:37 | fowl | use this for macros http://nimrod-lang.org/c2nim.html#def-directive |
| 06:12:51 | ldlework | can I use that to just cheat? |
| 06:13:05 | ldlework | like perform pre-parse transformations on the C? |
| 06:14:06 | ldlework | or does it just work for C macros |
| 06:14:27 | fowl | you see the example right |
| 06:14:52 | fowl | its like #define |
| 06:15:11 | fowl | good night |
| 06:25:56 | gokr | Varriount: I haven't yet placed restart stuff on either. But the 32 bit is building AFAICT |
| 06:32:42 | kokozedman | hey guys... trying to use c2nim here, and some of the field names are reserved Nim keywords (like "type"), how to get around this? |
| 06:34:29 | kokozedman | doing `type` seems to work, is that the correct way? |
| 06:39:08 | Varriount | kokozedman: Usually you just rename the symbols. |
| 06:39:39 | Varriount | kokozedman: For instance, the standing convention is to use 'typ' instead of 'type' |
| 06:41:59 | kokozedman | oh, I see |
| 06:42:31 | kokozedman | Varriount: I'm hitting roadblocks along the way, can you suggest ways to do a forward declaration of a type? |
| 06:43:06 | kokozedman | in C, you can struct SomeType; and use it ahead before having the implementation... how to do that in Nim? |
| 06:44:17 | Varriount | kokozedman: You can't. However you can merge 'type' blocks together. Types declared in the same type block can reference each other out-of-order |
| 06:44:43 | kokozedman | oh, I didn't know about that... thanks Varriount |
| 06:45:02 | Varriount | kokozedman: If it's not in the manual, it probably should be. |
| 06:49:41 | kokozedman | Varriount: it's not, it only mentions about forward declaractions about procs |
| 06:50:14 | kokozedman | the tutorial sheds more light on this than the manual, but again, only about procs... not types |
| 07:04:24 | Demos | I recall it being /someplace/ |
| 07:04:30 | Demos | possibly in the c2nim docs |
| 07:04:42 | Demos | but yeah, it needs to be more accessible |
| 07:13:55 | * | clone1018__ joined #nimrod |
| 07:14:34 | * | lilmanhibou joined #nimrod |
| 07:16:15 | * | Boscop joined #nimrod |
| 07:17:42 | * | clone1018 quit (Ping timeout: 275 seconds) |
| 07:17:46 | * | clone1018__ is now known as clone1018 |
| 07:19:17 | * | dom96 quit (Excess Flood) |
| 07:23:59 | * | dom96 joined #nimrod |
| 07:29:02 | * | milosn_ joined #nimrod |
| 07:30:34 | * | milosn quit (Write error: Broken pipe) |
| 07:30:43 | * | kniteli quit (Ping timeout: 272 seconds) |
| 07:33:42 | * | milosn_ is now known as milosn |
| 07:43:57 | * | kniteli joined #nimrod |
| 07:49:28 | * | JStoker quit (*.net *.split) |
| 07:49:28 | * | wan quit (*.net *.split) |
| 07:49:28 | * | onionhammer quit (*.net *.split) |
| 07:50:21 | * | kniteli quit (Ping timeout: 272 seconds) |
| 07:52:25 | gokr | Btw, I am messing with Gitlab and Gitlab-CI - and last night I got a build "runner" up in a docker container. Pretty neat. |
| 07:54:43 | * | JStoker joined #nimrod |
| 07:59:53 | * | bjz quit (Ping timeout: 264 seconds) |
| 08:03:01 | * | kniteli joined #nimrod |
| 08:08:44 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 08:09:03 | * | kniteli quit (Ping timeout: 265 seconds) |
| 08:10:33 | * | Demos quit (Read error: Connection reset by peer) |
| 08:14:46 | * | uku joined #nimrod |
| 08:17:58 | * | wan joined #nimrod |
| 08:17:58 | * | onionhammer joined #nimrod |
| 08:20:30 | * | kniteli joined #nimrod |
| 08:25:54 | kokozedman | is there any existing debugging facility to print/dump C Strings? like 00 FF 52 ED ... or similar |
| 08:27:25 | * | bjz joined #nimrod |
| 08:56:05 | NimBot | Araq/Nimrod devel 81353b2 Araq [+0 ±2 -0]: renamed CondVar to Semaphore |
| 08:56:05 | NimBot | Araq/Nimrod devel af84f75 Araq [+0 ±3 -0]: proper fix for stack initialization and threadvar emulation |
| 09:29:23 | * | Trustable joined #nimrod |
| 09:35:55 | * | darkf_ joined #nimrod |
| 09:38:31 | * | darkf quit (Ping timeout: 244 seconds) |
| 09:53:37 | * | darkf_ is now known as darkf |
| 09:56:29 | * | johnsoft quit (Quit: Leaving) |
| 09:56:54 | * | johnsoft joined #nimrod |
| 11:21:51 | * | ehaliewicz quit (Ping timeout: 244 seconds) |
| 11:34:49 | kokozedman | is the {.compile: xxxxx.} broken? Nim doesn't seem to compile the C file, resulting in a not found .o object file |
| 11:42:26 | * | wan quit (*.net *.split) |
| 11:42:26 | * | onionhammer quit (*.net *.split) |
| 11:54:21 | * | lilmanhibou quit (Quit: lilmanhibou) |
| 12:06:12 | * | onionhammer joined #nimrod |
| 12:09:15 | * | irrequietus joined #nimrod |
| 12:30:16 | * | wan joined #nimrod |
| 12:32:40 | * | foodoo joined #nimrod |
| 12:40:50 | * | shevy joined #nimrod |
| 12:40:55 | shevy | will the channel also be renamed? |
| 12:48:52 | * | __flaviu joined #nimrod |
| 12:50:29 | __flaviu | Looks like release build on arm timed out, it's probably easiest to just not bother. |
| 12:54:22 | * | __flaviu quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 12:54:52 | * | dom96_ quit (Ping timeout: 245 seconds) |
| 12:56:55 | * | BitPuffin joined #nimrod |
| 12:58:49 | * | __flaviu joined #nimrod |
| 13:01:51 | * | __flaviu quit (Client Quit) |
| 13:12:54 | * | kemet joined #nimrod |
| 13:28:28 | * | irrequietus quit () |
| 13:41:53 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 13:42:46 | * | johnsoft joined #nimrod |
| 13:53:55 | * | iamanewbie joined #nimrod |
| 13:54:18 | iamanewbie | hello all, before exploring further, when using macros, is the AST typed? |
| 14:07:51 | * | Araq0 joined #nimrod |
| 14:09:02 | Araq0 | hi iamanewbie welcome |
| 14:09:31 | Araq0 | every node in the AST has the same type (PNimrodNode) |
| 14:10:27 | Araq0 | the compiler checks after construction that the AST you build up is valid |
| 14:10:52 | iamanewbie | Araq0: I was actually thinking of the types of the underlying variables and procs. Sorry :-) So, I cannot get variable and proc types? |
| 14:12:02 | Araq0 | no. that's a planned feature. |
| 14:13:16 | iamanewbie | Araq0: OK! Thank you for the answer! |
| 14:15:20 | Araq0 | shevy: yes the channel will be renamed |
| 14:15:39 | iamanewbie | Araq0: In the compiler, I guess we have access to a typed AST? Or is it an alternative form? |
| 14:16:07 | Araq0 | iamanewbie: the compiler uses essentially the very same AST |
| 14:16:22 | Araq0 | every node has "typ" field |
| 14:16:35 | Araq0 | so yes, you can access it easily |
| 14:17:14 | iamanewbie | Araq0: I see. Thank you very much. |
| 14:28:50 | * | darkf quit (Quit: Leaving) |
| 14:33:13 | * | fowl quit (Quit: Leaving) |
| 14:45:54 | gokr | Ha! finally got gitlab-ci to build a trivial Nim project - inside a docker instance with a gitlab runner and Nim in it. Neato! |
| 14:53:02 | kokozedman | is there a existing kind of preferred event loop system? I mean, instead of directly using poll() from posix, might there be an existing facility that will make our life easier? |
| 14:53:17 | gokr | Oh yes. |
| 14:53:45 | gokr | See my article about a socket server: http://goran.krampe.se/2014/10/25/nim-socketserver/ |
| 14:53:46 | kokozedman | I'm looking into juggling sockets and process in one big loop |
| 14:53:54 | gokr | Check that article first :) |
| 14:54:04 | kokozedman | ok, thanks gokr |
| 14:54:25 | gokr | Or if you want to use async stuff - check that code. |
| 14:54:53 | gokr | But that code in my article uses the new "bigbreak" networking stuff - which contains an abstraction of modern polling (epoll etc). |
| 14:55:27 | Araq0 | gokr: bigbreak has been merged into devel |
| 14:55:31 | gokr | Its basically a skeleton for a multithreaded socket server using the "spawn" feature etc. |
| 14:55:45 | gokr | Yeah, sure, will stop referring to bigbreak :) |
| 14:56:10 | kokozedman | does async play well with FileHandle? |
| 14:56:43 | Araq0 | kokozedman: there is some async file handling too |
| 14:57:03 | gokr | So I took a Dockerfile that constructs a Gitlab-CI runner image - and added the build commands for Nimrod. So now using that image I can easily build Nim programs. Docker is pretty neat, but... a bit messy to find the "simple howto" for it. |
| 14:57:20 | kokozedman | to be correct, it's actually process file handle (osproc) |
| 15:00:11 | Araq0 | osproc doesn't play well with async, I'm afraid |
| 15:13:14 | kokozedman | I'm looking into the master's selectors ... what is meant with the when defined(nimdoc)? when document is being generated? |
| 15:13:47 | * | shevy left #nimrod ("I'll be back ... maybe") |
| 15:16:45 | gokr | The "when:" is an "if" during compile time. |
| 15:16:46 | * | BlaXpirit joined #nimrod |
| 15:17:13 | kokozedman | gokr: yes, I am aware of that... but the meaning of nimdoc is what I'm trying to understand |
| 15:17:23 | kokozedman | like, when is nimdoc defined |
| 15:17:30 | gokr | Oh, it means that the compiler is parsing to generate docs. |
| 15:17:34 | gokr | Not compiling. |
| 15:18:01 | kokozedman | oh, ok... makes sense. Thanks for the pointer |
| 15:18:05 | gokr | See "nim --help" :) |
| 16:00:02 | * | untitaker quit (Ping timeout: 255 seconds) |
| 16:07:17 | * | untitaker joined #nimrod |
| 16:08:34 | * | brson joined #nimrod |
| 16:12:07 | * | uku quit (Ping timeout: 255 seconds) |
| 16:12:14 | * | foodoo quit (Remote host closed the connection) |
| 16:21:54 | * | irrequietus joined #nimrod |
| 16:34:01 | * | Araq0 quit (Quit: Page closed) |
| 16:43:28 | * | mko joined #nimrod |
| 16:44:42 | * | flaviu__ joined #nimrod |
| 16:45:19 | flaviu__ | couldn't the tester also keep track of how long each test takes? |
| 16:56:26 | * | gokr quit (Quit: Leaving.) |
| 16:57:26 | * | flaviu__ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:01:00 | * | flaviu__ joined #nimrod |
| 17:03:06 | * | gokr_ joined #nimrod |
| 17:12:39 | * | Trustable quit (Quit: Leaving) |
| 17:19:31 | * | ehaliewicz joined #nimrod |
| 17:22:04 | * | flaviu__ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 17:28:16 | * | kniteli quit (Ping timeout: 265 seconds) |
| 17:28:28 | * | gokr joined #nimrod |
| 17:30:24 | * | Matthias247 joined #nimrod |
| 17:32:04 | * | q66 joined #nimrod |
| 17:35:52 | * | uku joined #nimrod |
| 17:39:43 | * | kniteli joined #nimrod |
| 17:43:12 | * | flaviu__ joined #nimrod |
| 17:51:11 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 17:51:37 | gokr | Any reason we don't have deny() and doDeny()? |
| 18:00:11 | NimBot | nim-lang/nimforum new_async 2aaeaf9 Dominik Picheta [+0 ±4 -0]: Implemented activity timer in JS. |
| 18:14:09 | * | flaviu__ quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 18:17:06 | * | Jessin quit (Quit: Leaving) |
| 18:17:10 | kokozedman | what is RootObj and where can I find more info around it? |
| 18:36:06 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 18:45:11 | * | Jesin joined #nimrod |
| 18:50:05 | * | tillzy joined #nimrod |
| 18:51:39 | * | tillzy quit (Client Quit) |
| 18:52:43 | * | Jesin quit (Quit: Leaving) |
| 19:05:49 | * | ehaliewicz quit (Ping timeout: 244 seconds) |
| 19:11:46 | * | kniteli quit (Ping timeout: 265 seconds) |
| 19:16:58 | * | gokr quit (Quit: Leaving.) |
| 19:23:11 | * | kniteli joined #nimrod |
| 19:27:52 | * | boydgreenfield joined #nimrod |
| 19:28:52 | * | superfunc joined #nimrod |
| 19:35:34 | * | superfunc quit (Ping timeout: 246 seconds) |
| 19:38:51 | wan | Is the `proc stuff(someproc: proc)` notation supported (should I report a bug I found using it)? |
| 19:39:12 | wan | using `proc stuff(someproc: proc())` instead doesn't have that bug |
| 19:48:42 | * | dom96_ joined #nimrod |
| 19:49:14 | dom96_ | wan: The former would be a typeclass I think. |
| 19:49:27 | dom96_ | Typeclasses aren't very stable yet I don't think. |
| 19:51:45 | wan | Alright, I won't report it. I'll keep the test case around to check when it's supposed to be stable then. |
| 19:52:19 | wan | I however will report a bug with cs:none and dirty templates |
| 19:56:10 | * | gokr joined #nimrod |
| 19:56:26 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 20:06:06 | dom96_ | wan: no, do report it |
| 20:18:42 | NimBot | nim-lang/nimforum new_async 374f6f9 Dominik Picheta [+0 ±2 -0]: Improved register and profile pages. |
| 20:21:45 | * | nande joined #nimrod |
| 20:21:47 | * | [CBR]Unspoken quit (Ping timeout: 265 seconds) |
| 20:25:36 | * | uku quit (Ping timeout: 244 seconds) |
| 20:27:11 | * | uku joined #nimrod |
| 20:27:29 | dom96_ | Araq: btw when you're renaming the repo to nim, make the 'n' lowercase please. |
| 20:38:38 | dom96_ | Araq: Seems like bootstrapping on amd64 fails. |
| 20:39:28 | dom96_ | and I don't see any gcc lines with --verbosity:2 |
| 20:39:50 | Araq | well what does our new builder say? |
| 20:40:18 | * | flaviu joined #nimrod |
| 20:40:24 | dom96_ | dunno |
| 20:43:28 | gokr | kokozedman: RootObj is the baseclass for objects. Like "Object" in Java. |
| 20:43:56 | gokr | bootstrapping fails? |
| 20:44:45 | gokr | The latest build is green: http://178.62.143.63:8010/builders/linux-x64-builder/builds/12 |
| 20:51:06 | wan | dom96: I reported my bugs |
| 20:51:43 | wan | dom96: if you don't see gcc caled with --verbosity:2, it means that the compiler either thinks it doesn't have to recompile or that it failed before |
| 20:52:05 | wan | (before trying to run gcc) |
| 20:52:09 | dom96_ | I just tried bootstrapping manually and it fails in the second iteration. |
| 20:55:08 | * | Mat3 joined #nimrod |
| 20:55:34 | Mat3 | hello |
| 20:55:38 | dom96 | https://gist.github.com/dom96/f3a17d41ed3f0bc445de |
| 20:58:15 | * | ftuvbgyrftr joined #nimrod |
| 20:58:38 | * | Mat3 left #nimrod (#nimrod) |
| 20:59:08 | * | Mat3 joined #nimrod |
| 21:00:21 | * | irrequietus quit () |
| 21:07:16 | wan | dom96: I'm on linux64, can't reproduce (both repo on devel, sh build.sh + koch boot, verbosity works as expected, bootstraps fine) |
| 21:07:47 | Araq | hi ftuvbgyrftr welcome |
| 21:09:16 | wan | With a nick like that, it's probable it's just a cat walking on the keyboard |
| 21:11:07 | dom96_ | http://178.62.143.63:5000 |
| 21:11:11 | dom96_ | Thoughts? |
| 21:11:12 | Mat3 | or some kind of code... |
| 21:11:17 | dom96_ | Please test. |
| 21:11:35 | * | hsuh quit (Ping timeout: 244 seconds) |
| 21:12:26 | * | hsuh joined #nimrod |
| 21:12:48 | Mat3 | dom96: I found the design quite unique, looks nice (although a bit dark) |
| 21:15:42 | flaviu | dom96: http://browsershots.org/http://178.62.143.63:5000/ |
| 21:16:18 | dom96_ | I've only really tested it in Firefox. |
| 21:16:35 | flaviu | Chrome 35 specifically doesn't look too good, I assume font sizes are different |
| 21:17:00 | flaviu | You probably want to use percentages and cut off overflow |
| 21:19:40 | dom96_ | 35 is old now |
| 21:20:43 | dom96_ | hrm, that's a serious bug. |
| 21:21:18 | flaviu | I don't think it's a problem with chrome, I think it's a missing font problem |
| 21:21:33 | dom96_ | I think Jester has some cookie bug in it |
| 21:24:46 | wan | unnecessary div below .info_post |
| 21:27:29 | wan | font-size of 10pt on posts but 13pt elsewhere? Fonts are globally too big, better put body font at 10pt |
| 21:27:48 | flaviu | width: 93% on the name should be removed, the gravatar bumped up to 200-300 and width: 100% |
| 21:31:37 | wan | 'preview' makes a date with that format "Tue Nov 11 21:30:23 2014", but ISO format like on the post "2014-11-11 21:11:00" is better |
| 21:31:58 | wan | or at least should be consistent |
| 21:32:27 | * | BitPuffin joined #nimrod |
| 21:33:56 | flaviu | The buttons on the side should be centered and full width, I think I see what you're trying to do there, but I don't think it'll turn out well |
| 21:34:07 | wan | I prefer "#head-links a" with a font-size of 12 or 13pt instead of 14 |
| 21:34:50 | flaviu | I don't actually expect this to be addressed, but it's not responsive. |
| 21:36:28 | wan | gravatar on profile page should float left |
| 21:36:59 | flaviu | Too many floats in .user, you can get rid of them all |
| 21:40:55 | flaviu | Yeah, just keep .user .avatar at 500px. Loading speed is unimportant, it'll stay in cache since the user will be seeing it every time they visit |
| 21:41:00 | * | darrell_ joined #nimrod |
| 21:42:14 | darrell_ | New here. How do I run Nimrod/tests in total? |
| 21:42:44 | darrell_ | Is 'var a\necho a' supposed to segfault? |
| 21:44:16 | wan | you don't want to assign 'a' first? |
| 21:49:26 | wan | dom96: I would bump the alpha of #talk-thread>div from 0.1 to 0.5-0.6 |
| 21:53:12 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 21:56:25 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 21:57:33 | Araq | dom96_: well I'm afraid you have to git bisect to find the cause why bootstrapping now fails |
| 22:01:36 | darrell_ | Found an exception trying to echo object which had nil members |
| 22:02:23 | dom96_ | flaviu: wan: ok, i'm sorry but I don't have time for these changes. |
| 22:02:53 | dom96_ | flaviu: wan: You guys can create a PR though :) |
| 22:03:25 | gokr | Araq: The current build on buildbot went fine for Linux32/64 at least. |
| 22:08:32 | Varriount | Meep |
| 22:09:48 | Varriount | Erm, the buildbot for windows went through as well (the only reason 32 bit failed was because of the wierd output bug) |
| 22:10:13 | gokr | Varriount: Nice work btw. |
| 22:10:24 | Varriount | gokr: For what? |
| 22:10:41 | gokr | Ehrm, well, the buildbot I mean. |
| 22:10:57 | gokr | I got gitlab-ci to work btw, quite nice stuff. |
| 22:11:17 | Varriount | gokr: Oh? Do you think we should be using that instead? |
| 22:11:28 | Varriount | I'm open to change. |
| 22:12:31 | gokr | Well... its not as advanced as buildbot. But slicker and nicely integrated with Gitlab. |
| 22:12:58 | gokr | So I see no reason to change just for the cause of changing. |
| 22:13:08 | gokr | For me it was different - since we are moving to gitlab. |
| 22:13:21 | Varriount | Ah, ok. |
| 22:13:28 | Araq | Varriount: can you patch system/excpt.nim so that the popup window disappears? |
| 22:13:46 | ldlework | We should start building Nim with Docker :P |
| 22:14:00 | gokr | ldlework: I am using docker for gitlab-ci actually. |
| 22:14:02 | Araq | btw the threading bugs were caused by jehan's patch, quite ironically |
| 22:14:05 | ldlework | gokr: nice |
| 22:14:18 | Araq | ldlework: you should start rewrite Docker in Nim |
| 22:14:21 | Varriount | Araq: Silly threads are silly. |
| 22:14:25 | ldlework | Araq: lol! |
| 22:14:29 | gokr | One thing with docker though... IMHO the docs on it are... kinda backwards IMHO. |
| 22:14:42 | ldlework | gokr: the docs ... the docs... OH GOD THE DOCS |
| 22:14:58 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) |
| 22:15:07 | gokr | I would like a howto that explains Dockerfile first, this is how you build your image, this is how you start it etc. |
| 22:15:20 | gokr | But it feels like the docs start with tons of other things first. |
| 22:15:24 | flaviu | ldlework: What advantage would building with docker have? |
| 22:15:39 | ldlework | flaviu: well you wouldn't need to maintain your own build service |
| 22:15:44 | gokr | The nice thing with docker - and vagrant - is that you have perfect control over the build environment. |
| 22:16:06 | ldlework | flaviu: all you need is to add a Dockerfile to Nim's repo, and setup a webhook for github |
| 22:16:18 | flaviu | ldlework: Who provides the servers? |
| 22:16:21 | ldlework | flaviu: we do |
| 22:16:39 | ldlework | Then people can try nim by doing "docker run -it nim/nim -i" |
| 22:16:41 | * | boydgreenfield joined #nimrod |
| 22:16:42 | gokr | ldlework: Which service is that? |
| 22:16:43 | ldlework | or whatever |
| 22:16:50 | ldlework | gokr: The DockerHub has a build service |
| 22:16:54 | gokr | oh |
| 22:16:59 | ldlework | https://hub.docker.com/ |
| 22:17:06 | ldlework | after logging in |
| 22:17:11 | ldlework | add a repo |
| 22:17:15 | ldlework | and it will ask if you want to make it automated |
| 22:17:34 | gokr | Ah, right - I get it. To produce docker images. |
| 22:17:47 | ldlework | gokr: yes, and then if you want to upload the actual binary somewhere |
| 22:17:54 | ldlework | you can just copy the binary out of the image and host it somewhere |
| 22:18:13 | gokr | Pretty neat. |
| 22:18:14 | flaviu | ldlework: Sure, but it's not intended to run an hour of tests |
| 22:18:21 | ldlework | flaviu: our limit is 2 hours |
| 22:18:30 | ldlework | and I don't think it takes an hour to build nim |
| 22:18:45 | gokr | ldlework: Docker is Linux kernel only, right? |
| 22:18:46 | ldlework | And the limits are going to get more flexible in the future |
| 22:18:52 | flaviu | ldlework: 1 hour and 50 min |
| 22:18:53 | flaviu | http://178.62.143.63:8010/builders/linux-x32-builder/builds/16 |
| 22:18:59 | ldlework | gokr: yes, though we just signed a deal with microsoft |
| 22:19:12 | ldlework | so native docker container support is coming to windows sooner than later |
| 22:19:14 | ldlework | :3 |
| 22:19:18 | ldlework | (that's public info) |
| 22:19:26 | flaviu | There is quite a bit of low-hanging performance improvements to be done on the tester |
| 22:19:38 | ldlework | Furthermore |
| 22:19:43 | ldlework | You can daisy chain |
| 22:19:48 | flaviu | ldlework: How about exotic architectures? |
| 22:19:55 | ldlework | send nim to travisci or circleci |
| 22:20:00 | ldlework | if the tests pass have them ping our service |
| 22:20:05 | ldlework | and we'll build the image |
| 22:20:13 | ldlework | flaviu: some people are working on ARM |
| 22:20:36 | flaviu | little or big endian, or both? |
| 22:20:47 | ldlework | I don't really now |
| 22:20:49 | ldlework | know* |
| 22:21:16 | ldlework | I'm so heads down on the build cluster I pay little attention to actual Docker evolutions |
| 22:21:47 | ldlework | Anyway I'm not going to be offended if you don't use Docker |
| 22:22:00 | ldlework | "docker run -it nim/nim -i" is p. nice tho |
| 22:22:07 | gokr | One thing really neat with Docker is the transactional filesystem. When tweaking the Dockerfile and rebuilding - it took just a second. And then I realized how nifty that was :) |
| 22:23:32 | gokr | But what the heck are you doing with "docker --help"? I was totally dumbfounded. |
| 22:23:52 | gokr | (it doesn't show the commands, but if you type just "docker" it does, duh) |
| 22:24:13 | ldlework | docker --help |
| 22:24:16 | flaviu | I'm not officially associated with Nim, but I think that there isn't any point in switching right now because Nim already has the build machines it needs. It definitely looks interesting, especially if ARM builds come out. 10.8 hour builds on my arm machine are a bit ridiculous |
| 22:24:16 | ldlework | shows all that for me |
| 22:24:49 | gokr | ldlework: I am on Docker version 1.0.1, build 990021a |
| 22:24:56 | ldlework | gokr: oh god, upgrade man |
| 22:25:00 | ldlework | we're on 1.3.1 |
| 22:25:09 | gokr | Hmmm, why is that... |
| 22:25:16 | gokr | I thought I did what I was supposed to. |
| 22:25:23 | gokr | Ah, no wait. |
| 22:25:27 | gokr | wrong machine :) |
| 22:26:12 | gokr | ehh. |
| 22:26:37 | Araq | hrm do we support any C compilers that still lack the LL suffix for long long numbers? |
| 22:26:53 | * | Araq doubts it |
| 22:27:01 | Varriount | Araq: Depends on your idea of 'support' |
| 22:27:30 | Varriount | Araq: I distinctly recall configuration code for borland and pelles |
| 22:27:47 | Araq | yeah but nobody uses there |
| 22:27:49 | Araq | *these |
| 22:28:12 | gokr | ldlework: Its the one in Ubuntu 14.04 |
| 22:28:26 | gokr | Ok, so I guess I will use your repo instead then. |
| 22:28:29 | ldlework | gokr: no idea what is in the packages |
| 22:28:36 | ldlework | I just install the binary each time |
| 22:28:37 | Araq | watcom on the other hand should be supported. that would allow us to port the compiler to DOS |
| 22:28:56 | flaviu | does *anyone* still use dos? |
| 22:29:12 | Araq | DOS is the ultimate platform :P |
| 22:29:21 | gokr | watcom... long time ago. TopSpeed? We used that. |
| 22:29:29 | Araq | runs on more machines than the JVM :P |
| 22:29:48 | Araq | thanks to dosbox |
| 22:29:52 | Varriount | Araq: Is excpt.nim the right place for the error message box disabling code? The message boxes only appear when a serious exception happens, like threading errors or unhandled segfaults. |
| 22:30:26 | Araq | Varriount: look at it. it's a big mess. so yes. definitely the right place. |
| 22:30:35 | Varriount | -_- |
| 22:31:05 | Varriount | Where do I put the code? do I just add a new procedure, or insert something into an existing proc? |
| 22:31:05 | flaviu | Araq: I expect you to say that window's behavior here is perfect |
| 22:31:05 | flaviu | /me ducks |
| 22:31:24 | Varriount | flaviu: Well, it is nice to know when a background program crashes. |
| 22:31:51 | * | flaviu listens in horror |
| 22:31:57 | Araq | flaviu: no, you're right. *that* behaviour is just insane |
| 22:32:23 | * | Matthias247 joined #nimrod |
| 22:32:28 | Araq | and causes lots of troubles when running windows as a server |
| 22:32:37 | gokr | ldlework: Now help looks sane :) |
| 22:32:45 | ldlework | hehe |
| 22:32:46 | Varriount | What's so wrong about notifying a user that a program has crashed, rather than just exited? |
| 22:33:03 | Araq | Varriount: that you need to click it away |
| 22:33:17 | Araq | there is an error log anyway which is used for the reporting |
| 22:33:22 | Varriount | Araq: Which is why it can be disabled via the registry or by api call. |
| 22:33:28 | Araq | well yes |
| 22:33:44 | Araq | but when I googled it that solution never came up |
| 22:33:52 | Araq | for reasons I don't understand |
| 22:34:14 | Araq | Varriount: that's deep magical knowledge you came up with here |
| 22:35:04 | Araq | also |
| 22:35:15 | * | superfunc joined #nimrod |
| 22:35:23 | Araq | there could be timeout for the window to disappear |
| 22:35:34 | flaviu | Varriount: Because grandma is not going to care and will just be confused. Poweusers can get that info from the error console. Also, I think it's insane that the layer that deals with segfaults also knows that there's a GUI. |
| 22:36:26 | Varriount | flaviu: Actually, it doesn |
| 22:36:34 | Araq | flaviu: that's not necessarily the case though |
| 22:36:40 | Varriount | flaviu: It's just calling an exception handler. |
| 22:37:02 | flaviu | Varriount: What happens when I run windows headless? |
| 22:37:05 | Varriount | In this case, the default exception handler for unhandled exceptions is to start the windows error reporting dialogue. |
| 22:37:36 | Varriount | flaviu: Modify the appropriate registry keys? |
| 22:39:35 | Varriount | flaviu: Also, without the error dialogue, grandma isn't going to know why her browser just quits. She might be thinking that she's clicking the 'exit' button by mistake. |
| 22:40:30 | flaviu | I have a rebuttal to that, but I don't want to get too off topic |
| 22:40:41 | Mat3 | flaviu: I use DOS infrequently (not MS-DOS however) |
| 22:40:55 | Araq | XD |
| 22:41:06 | Araq | sorry but that's just hilarious |
| 22:41:14 | flaviu | Mat3: For general purpose stuff? |
| 22:41:28 | Varriount | Oh god, that brought back memories. Seeing that hideous "MS-DOS" icon on the desktop. |
| 22:41:51 | Araq | You have not enough EMS memory. |
| 22:42:40 | Araq | seriously there were like 5 different kinds of RAM memory. |
| 22:42:46 | Mat3 | flaviu: For low-level programming (it's nice not to have an operating system hindering hardware access some time) |
| 22:43:07 | * | nande quit (Read error: Connection reset by peer) |
| 22:43:23 | flaviu | I guess that makes sense, although I bet you aren't compiling programs using DOS |
| 22:43:37 | Araq | I'm sure he does |
| 22:43:38 | Mat3 | ehm, no |
| 22:43:45 | Araq | no? |
| 22:44:06 | flaviu | cross-compilers |
| 22:44:20 | Mat3 | exactly |
| 22:44:25 | * | nande joined #nimrod |
| 22:44:46 | flaviu | Araq: No one wants to write C89 or whatever it was |
| 22:45:09 | Araq | C89 is better than C99 |
| 22:45:34 | flaviu | Don't you have to declare all you're variables at the start of the method? |
| 22:45:39 | flaviu | *your |
| 22:45:50 | Araq | at the start of a block { |
| 22:47:16 | * | fowl joined #nimrod |
| 22:48:02 | Araq | Varriount: seriously excpt.nim is the place to put it |
| 22:49:45 | Varriount | Araq: Where? As a new procedure? |
| 22:49:52 | Varriount | Also: http://blogs.msdn.com/b/oldnewthing/archive/2004/07/27/198410.aspx |
| 22:52:34 | Araq | Varriount: well sure. but you have to call it as a top level thing |
| 22:52:57 | Araq | you shouldn't do anything if -d:noSignalHandler is set |
| 22:53:24 | Araq | I think it makes sense to conflate it with that |
| 22:54:43 | Varriount | Araq: Eh, I would rather we let the error dialogue happen by default. |
| 22:55:53 | * | uku quit (Ping timeout: 240 seconds) |
| 22:56:21 | Araq | well you can make it show up for --app:gui |
| 22:56:38 | Araq | but for console applications it makes no sense whatsoever anyway |
| 22:56:55 | Araq | we do print the "no stack trace available" etc. |
| 22:57:34 | Varriount | And what is signal handler fails? |
| 22:57:50 | * | uku joined #nimrod |
| 22:58:13 | Araq | that doesn't happen |
| 23:00:02 | Varriount | Araq: How do exceptions and the GC work when nim is used as a DLL? |
| 23:00:58 | Araq | that was tricky to implement |
| 23:01:05 | * | kniteli quit (Ping timeout: 272 seconds) |
| 23:01:10 | Araq | and I don't remember any details |
| 23:01:51 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 23:01:55 | Varriount | Araq: Well, I hope this doesn't get called when the program is being used as a DLL, because the solution is *process wide* |
| 23:02:50 | Araq | so just disable it when app==console |
| 23:02:57 | Araq | that implies "no DLL" |
| 23:04:04 | flaviu | Varriount: Having fun yet? :P |
| 23:04:55 | Varriount | flaviu: Arguing with Araq? Or implementing the solution? |
| 23:05:09 | flaviu | Implementing the solution |
| 23:05:19 | flaviu | Well, just using the windows APIs I guess |
| 23:05:25 | Varriount | flaviu: The solution is easy. |
| 23:05:44 | Varriount | Like, stupidly easy. |
| 23:06:00 | Varriount | Read the first couple of paragraphs here: http://blogs.msdn.com/b/oldnewthing/archive/2004/07/27/198410.aspx |
| 23:06:53 | flaviu | I have already |
| 23:07:41 | * | Sergio965 joined #nimrod |
| 23:08:02 | * | kemet joined #nimrod |
| 23:08:09 | * | kemet quit (Remote host closed the connection) |
| 23:08:14 | NimBot | Araq/Nimrod devel aae180e Araq [+0 ±1 -0]: fixes #1560 |
| 23:08:14 | NimBot | Araq/Nimrod devel 2d43fca Araq [+1 ±1 -0]: fixes #1593 |
| 23:09:33 | flaviu | Well, I guess they'll be all the commits for the next 24 hours if he wants the ARM tester to keep up :P |
| 23:09:53 | Varriount | flaviu: Yeah, I was just about to remark on that.. |
| 23:10:06 | Varriount | '2 Pending Builds' |
| 23:10:15 | flaviu | BTW, how about keeping data about test length |
| 23:10:41 | Varriount | flaviu: You mean, how long running tests takes? |
| 23:10:44 | gokr | Ha! Was just wondering why the fan started on the old laptop on the floor... |
| 23:10:52 | flaviu | Yes |
| 23:11:24 | Varriount | flaviu: http://178.62.143.63:8010/builders/linux-x32-builder/builds/16 |
| 23:12:07 | Varriount | Run Testament - ( 1 hrs, 39 mins, 37 secs ) |
| 23:12:09 | flaviu | Varriount: I know, but I mean per-test. So we can cut out the tests with high runtime but low volatility. |
| 23:12:24 | flaviu | gctest would be the first I think |
| 23:12:37 | Varriount | flaviu: Talk to araq about that. |
| 23:13:46 | Varriount | flaviu: It could be worse. I read somewhere that, at Microsoft, running all the tests for a fresh Windows build takes 3 days. |
| 23:14:01 | Araq | flaviu: fine with me, but don't cut out them, either make them run faster or have some switch for stress testing |
| 23:14:15 | * | kniteli joined #nimrod |
| 23:14:44 | flaviu | Sure, another possibility is doing a full run every 10 builds or something. Main idea is to add timing info so we can make decisions based on that |
| 23:14:56 | flaviu | I'll send a pr sometime soon |
| 23:15:18 | Araq | ok |
| 23:15:39 | * | Sergio965 quit (Ping timeout: 272 seconds) |
| 23:15:52 | Araq | you should add this timing info to the database |
| 23:16:00 | flaviu | That's the idea |
| 23:16:03 | Araq | both compiletime and runtime |
| 23:16:38 | flaviu | also busy vs idle, so we can intelligently parallize |
| 23:16:56 | Araq | that doesn't work |
| 23:17:00 | Araq | well |
| 23:17:15 | Araq | you can parallize different categories |
| 23:17:20 | Araq | but not within a category |
| 23:17:29 | flaviu | isn't each test independent? |
| 23:17:41 | Araq | yeah but nimcache is not |
| 23:18:09 | flaviu | Its possible to work around that fairly easily |
| 23:18:38 | Araq | with --nimcache ? |
| 23:18:42 | flaviu | Yes. Just dump it in a temporary dir, although I don't know enough to know if that slows things down. |
| 23:19:14 | Araq | yeah that would work |
| 23:27:46 | * | kniteli quit (Ping timeout: 244 seconds) |
| 23:28:04 | Varriount | Isn't it a bad idea to parallelize unit testing? |
| 23:28:21 | Araq | we don't do unit testing |
| 23:28:47 | Araq | if that's not integration testing then I don't know what is |
| 23:28:57 | Varriount | Ok then, integration testing. |
| 23:29:44 | flaviu | Varriount: Why would it be? |
| 23:30:13 | Varriount | flaviu: Uh... race conditions? I don't really know, I think I read about it on some blog post. |
| 23:30:20 | flaviu | The compiler isn't interacting with databases or anything, it can be thought of as pure. Input -> output. No side effects. |
| 23:31:02 | flaviu | Now webapps use the database constantly. Setting a new DB for each test is probably too expense, so it isn't done. |
| 23:31:25 | Varriount | Araq: I'm assuming the right place to call the function that disables windows error reporting is in setSignalHandlers? |
| 23:32:16 | Araq | Varriount: hrm yeah why not |
| 23:32:23 | Araq | or make it a new toplevel statement |
| 23:33:02 | Mat3 | ciao |
| 23:33:41 | Varriount | Araq: Oh, that's safe to do? I always thought that there weren't supposed to be top level function calls in the core runtime files. |
| 23:37:02 | Araq | Varriount: well ... it works but usually gets intialization order wrong |
| 23:38:23 | gokr | I notice we have isNil, but no notNil |
| 23:39:46 | * | Mat3 left #nimrod (#nimrod) |
| 23:39:50 | * | kniteli joined #nimrod |
| 23:43:46 | Varriount | flaviu: By the way, you can control GCC memory usage via environment variables - http://hostingfu.com/article/compiling-with-gcc-on-low-memory-vps |
| 23:44:05 | flaviu | Varriount: It's actually Nim that's the problem |
| 23:44:13 | Varriount | O_o |
| 23:44:46 | flaviu | Nim was something like 50% when I was swapping |
| 23:48:03 | flaviu | Anyway, it doesn't matter too much, I think that nim sleeps while cc is being called |
| 23:49:41 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 23:49:55 | * | johnsoft joined #nimrod |
| 23:53:37 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:54:04 | Araq | hrm I have the perfect use case for exceptions here |
| 23:54:14 | Araq | that I should blog about |
| 23:54:38 | Araq | not having exceptions in this situation would require rewriting thousands of lines of code |
| 23:55:54 | * | kniteli quit (Ping timeout: 265 seconds) |
| 23:59:30 | * | uku quit (Ping timeout: 244 seconds) |