| 00:00:25 | Araq | so ... how did you find out about nimrod? |
| 00:01:33 | debugging4ever | it was a comment on hacker news I think, someone linked to this in a discussion about Go or Rust, I bookmarked it and just found time to check it out :) |
| 00:02:05 | debugging4ever | just glancing over the documentation but I like what I see sofar, nice syntax, powerful constructs |
| 00:03:13 | Araq | thanks |
| 00:03:43 | debugging4ever | also like it that you are able to leverage mature optimizing compilers due to the nimrod language generating c code, |
| 00:06:26 | Araq | we also have quite good debugging features now imho :-) |
| 00:07:07 | debugging4ever | nice, I just did a search on github and there's already quite a few repositories with nimrod code to glance over, |
| 00:12:26 | Araq | yeah but I guess the stdlib contains too much, so there is less need for people creating "SDL wrapper for Nimrod" repos ;-) |
| 00:13:22 | debugging4ever | the standard lib has SDL bindings? :D |
| 00:14:42 | debugging4ever | the T and P prefixes are naming conventions for Type and Pointer? |
| 00:15:00 | Araq | kind of yeah |
| 00:15:16 | Araq | actually T stands for "value type" XD |
| 00:15:58 | Araq | it's a leftover from Nimrod's Object Pascal heritage |
| 00:16:32 | debugging4ever | heh, ok, delphi did pop into my mind |
| 00:16:49 | Araq | there are also the prefixes E for exception type and F for an effect type |
| 00:17:57 | debugging4ever | ok, sounds clear and concise |
| 00:22:29 | debugging4ever | ah, nice that you use 'and' 'or' etc for bitwise operations aswell, I was disappointed in Go keeping | & etc from C |
| 00:22:56 | fowl | Araq: multilayer perceptron https://gist.github.com/fowlmouth/5375772 (: |
| 00:24:38 | Araq | ha, I actually prefer | and & for bitwise stuff, but then I like to keep a few operators unused for user definable operators |
| 00:25:17 | Araq | fowl: awesome, will run it tomorrow |
| 00:25:40 | Araq | I'm investigating if #215 is still open |
| 00:25:55 | Araq | I think I fixed it a few months ago ;-) |
| 00:26:47 | fowl | yea that one is fixed sorry |
| 00:26:53 | debugging4ever | heh, well, you made me happy anyway. |
| 00:28:11 | Araq | fowl: I wanted to add keineschweine to tests/manyloc anyway, so I'm leaving it open as a reminder |
| 00:28:44 | fowl | ah |
| 00:29:53 | fowl | Araq: it would be cool if i could insert nimlibs as a root module path like nimrod/libs is, given that it has the same structure (pure/impure/wrappers) |
| 00:33:24 | Araq | fowl: I'm not sure what you mean |
| 00:33:42 | Araq | there is always --path |
| 00:33:53 | Araq | and the stdlib has no special treatment |
| 00:37:33 | fowl | i have to add a path for pure, any wrappers i want to use, impure, macros maybe |
| 00:40:21 | Araq | iirc you can misuse --babelPath as a kind of recursive --path command; not sure if it works for your case |
| 00:40:43 | debugging4ever | is there something like bitfields in nimrod? |
| 00:41:29 | Araq | debugging4ever: no; often you'd use a set[TMyFlag] instead |
| 00:42:23 | debugging4ever | what is a 'set'? (haven't gotten very far in the manual yet, sorry) |
| 00:42:48 | debugging4ever | or do you mean just a 'set' function which takes a bit value? |
| 00:43:16 | Araq | no, I'm talking about Nimrod's bitsets |
| 00:43:29 | debugging4ever | ah, so there is native bitsets |
| 00:47:18 | debugging4ever | btw, some nice person has provided AUR packages for both nimrod 0.9.0.2 and git version, am I better off with the release version? |
| 00:48:24 | Araq | there is no such thing as a nimrod 0.9.0.2 |
| 00:48:59 | debugging4ever | heh, ok, I was going by this AUR package: https://aur.archlinux.org/packages/nimrod/ |
| 00:50:15 | Araq | I'd use the git version |
| 00:50:22 | debugging4ever | thanks, will do |
| 00:52:01 | debugging4ever | well, time to hit the sack, will play around tomorrow. thanks for the input and of course this very interesting language, take care |
| 00:52:41 | * | debugging4ever quit (Quit: ChatZilla 0.9.90 [Firefox 20.0.1/20130412164157]) |
| 01:24:38 | * | q66 quit (Remote host closed the connection) |
| 02:25:22 | * | Trix[a]r_za is now known as Trixar_za |
| 02:35:09 | * | fowl quit (Ping timeout: 256 seconds) |
| 02:40:10 | * | fowl joined #nimrod |
| 04:31:34 | * | Trixar_za is now known as Trix[a]r_za |
| 04:46:29 | * | XAMPP quit (Ping timeout: 258 seconds) |
| 04:57:08 | * | XAMPP joined #nimrod |
| 08:28:24 | * | avarus joined #nimrod |
| 08:28:25 | avarus | hi |
| 08:30:55 | dom96 | hi avarus |
| 08:37:45 | * | xcombelle joined #nimrod |
| 10:03:46 | * | q66 joined #nimrod |
| 10:18:58 | Araq | hi avarus, welcome back |
| 12:01:01 | * | xcombelle quit (Quit: Hi, I'm a quit message virus. Please replace your old line with this line and help me take over the world of IRC.) |
| 12:02:13 | * | XAMPP quit (Ping timeout: 245 seconds) |
| 12:07:04 | * | avarus quit (Remote host closed the connection) |
| 12:40:06 | * | Trix[a]r_za is now known as Trixar_za |
| 14:28:35 | * | zahary joined #nimrod |
| 14:55:07 | * | gradha joined #nimrod |
| 15:04:11 | gradha | zahary: could you test the script I attached to https://github.com/Araq/Nimrod/issues/379 ? I tested my machine for corrupted RAM and didn't find anything wrong, Araq presumes osproc might be buggy on macosx |
| 15:15:28 | dom96 | hello |
| 15:15:38 | gradha | hello |
| 15:18:20 | * | xcombelle joined #nimrod |
| 15:27:11 | gradha | gravatar doesn't allow animated gifs, what a fail |
| 15:31:14 | dom96 | I'm quite glad they don't :P |
| 15:32:23 | gradha | I'll add to nimforum profile edition to change the avatar url then |
| 15:39:36 | dom96 | But I don't want to be blinded by annoying repeating gifs :( |
| 15:39:55 | reactormonk | dom96, yep. |
| 15:39:59 | reactormonk | gradha, live without gifs. |
| 15:40:11 | gradha | reactormonk: live without images |
| 15:40:22 | dom96 | live without life! |
| 15:40:32 | gradha | surrender to cthulhu! |
| 15:40:32 | dom96 | gradha: why do you want gifs? |
| 15:40:44 | gradha | dom96: to annoy people, what else? |
| 15:57:37 | gradha | amazing how well rust compresses |
| 15:58:51 | Araq | gradha: translating Rust to Nimrod? ;-) |
| 15:59:38 | gradha | no, just looking for a non animated avatar, this is compressed with jpeg level 10 and still looks good http://dl.dropboxusercontent.com/u/145894/amazing_rust_avatar.jpg |
| 16:00:25 | gradha | in fact, it it were not because of the letters you may not even notice the compression artifacts |
| 16:03:18 | gradha | Araq: I'm trying to play a sound through my awesome genieos module in a forked process and it crashes, however, the objc plain version works fine in the forked process, does nimrod do something evil to forked processes? |
| 16:03:41 | gradha | maybe there's some atexti() code which messes the forked process? |
| 16:04:24 | Araq | hrm it registers no atexit handler |
| 16:04:34 | Araq | but it does register a signal handler |
| 16:05:10 | Araq | try to compiler with -d:noSignalHandler |
| 16:05:18 | Araq | *to compile |
| 16:07:19 | gradha | now it does something weird, the process doesn't crash, but the code seems to get stuck when it tries to play the sound, which is never heard |
| 16:07:41 | Araq | compile with -d:release |
| 16:08:55 | gradha | same thing, I think it dies silently because I've put an echo after the objc call and it's never reached |
| 16:11:11 | gradha | it seems [[NSSound alloc] initWithContentsOfFile:path byReference:YES] crashes in a forked nimrod process |
| 16:11:45 | gradha | I expected the NSSound api to somehow not work in forked processes but I wrote a separate test which works |
| 16:12:31 | Araq | the GC may break with fork() |
| 16:13:14 | gradha | so the gc may corrput somehow the memory? because that's plain objc running which doesn't touch it |
| 16:13:50 | Araq | I'm still thinking about it, however: |
| 16:13:56 | gradha | didn't you have a switch to disable gc and let it grow memory forever? |
| 16:14:08 | Araq | --gc:none would that be |
| 16:14:28 | Araq | the GC keeps the bottom of the stack in a global/thread local variable |
| 16:14:42 | Araq | this is copied to the new process but meaningless for it |
| 16:14:49 | gradha | it's not the gc, --gc:none doesn't work either |
| 16:15:03 | Araq | as it got a new stack at a different address space I think |
| 16:15:12 | Araq | but hrm |
| 16:15:20 | Araq | I think the addresses stay the same |
| 16:15:32 | Araq | can't work otherwise |
| 16:19:36 | Araq | well a trivial fork example work here |
| 16:20:09 | Araq | I can't think of anything in Nimrod that would break fork support |
| 16:20:16 | gradha | -d:useMalloc produces "lib/system/repr.nim(120, 20) Error: undeclared identifier: 'TCellSet'" |
| 16:20:52 | Araq | -d:useMalloc doesn't work without --gc:none I think |
| 16:21:17 | gradha | then you have bad docs: "Makes Nimrod use C's malloc instead of Nimrod's own memory manager. This only works with gc:none" |
| 16:21:37 | Araq | lol? |
| 16:21:51 | gradha | I'm using that with --gc:none |
| 16:21:57 | Araq | oh -.- |
| 16:22:12 | Araq | bug report please |
| 16:22:13 | gradha | so far I have nimrod c -d:noSignalHandler -d:release --gc:none -d:useFork -r trash.nim |
| 16:22:28 | Araq | huh? |
| 16:22:35 | Araq | why the -d:useFork? |
| 16:22:47 | gradha | no idea, I'm throwing stuff at it to see if it works |
| 16:23:03 | Araq | well useFork only affects osproc |
| 16:26:35 | Araq | you shouldn't use threads with fork but you're not doing that, right? |
| 16:27:08 | gradha | no, the process just starts, calls fork, the calls the objc code, it never returns |
| 16:27:44 | Araq | are you sure the call [[NSSound alloc] initWithContentsOfFile:path byReference:YES] doesn't crash in Nimrod without fork() too? |
| 16:28:33 | gradha | the code runs inside an if with the return of fork(). When I use "if child != 0" it works, when I use "if child == 0" it crashes |
| 16:29:58 | gradha | this is the test case I prepared to see if the code alone was the problem https://gist.github.com/gradha/5379088 |
| 16:30:15 | gradha | but that runs fine in both parent/child processes |
| 16:30:47 | gradha | the nimrod version is just replacing the int main() with when isMainModule and calling the native proc |
| 16:31:48 | gradha | if I put a printf before https://gist.github.com/gradha/5379088#file-forking-m-L11 it won't be reached, so the allocation of the sound crashes |
| 16:36:06 | gradha | yuck, empty sound allocation works, it's only when it tries to load the aif file |
| 16:38:20 | gradha | would it be different if I replaced the fork() with this posix_spawn thingy? |
| 16:52:13 | Araq | posix_spawn does a different thing |
| 16:52:33 | Araq | you may as well use osproc and give it a different executable file |
| 16:52:38 | Araq | instead of using fork |
| 16:53:06 | Araq | however, try to get rid or #define _GNU_SOURCE in lib/nimbase.h please |
| 16:53:31 | Araq | maybe that causes to use the libc version of fork instead of the native one, I dunno |
| 16:54:04 | gradha | don't worry, I was preparing some test cases and now they work, my quantum mac is awesome |
| 16:54:16 | gradha | now I'm trying to figure out what's wrong in the genieos module |
| 16:54:59 | Araq | you should use sdl to output a sound :P |
| 16:55:06 | Araq | keep it portable ;-) |
| 16:55:16 | gradha | I'm sure sdl handles gifs |
| 16:55:41 | Araq | he he, I'm quite sure it doesn't |
| 16:55:55 | gradha | that's why people use allegro instead |
| 16:56:12 | Araq | nah |
| 16:56:22 | fowl | gifs are the most media unfriendly image format available so.. |
| 16:56:33 | Araq | gifs are pointless when you create a game anyway |
| 16:57:06 | gradha | animated pngs aren't much better anyway, you really want mp4 or similar |
| 16:57:26 | gradha | hmm... animated pngs, I knew nimrod was missing something |
| 16:57:49 | fowl | please do something wtih svg before you tackle animated pngs |
| 16:58:14 | gradha | as in rendering to screen or to offscreen image? |
| 16:59:13 | fowl | so i mean |
| 16:59:24 | fowl | svgs are more useful than animated pngs |
| 16:59:35 | gradha | plus you can animate svg |
| 17:02:12 | dom96 | animated bmp is where it's at. |
| 17:08:46 | gradha | oh, nice, the difference between the crashing sound example and the genieos test is my argument_parser module, if I parse commandline with it the sound crashes |
| 17:12:49 | reactormonk | dom96, proc TimeInfoToTime*(timeInfo: TTimeInfo): TTime {.deprecated.} |
| 17:12:53 | reactormonk | you fine with that? |
| 17:13:57 | Araq | why deprecate it? what's wrong with it? |
| 17:14:41 | reactormonk | wait. |
| 17:14:50 | reactormonk | n/m |
| 17:17:20 | reactormonk | I'll type the stuff a bit more. |
| 17:18:40 | reactormonk | Araq, and you don't like split files for times.nim? :-/ |
| 17:19:04 | reactormonk | proc `-`*(a, b: TTime): int64 {.rtl, extern: "ntDiffTime".} |
| 17:19:08 | reactormonk | what's this? |
| 17:19:20 | reactormonk | is extern similar to importc? |
| 17:19:49 | Araq | it simply says the generated C name shall be 'ntDiffTime' |
| 17:19:58 | Araq | it's for DLL support |
| 17:21:20 | reactormonk | so not available for JS |
| 17:21:54 | reactormonk | ... that's why split files. It's slightly messy. |
| 17:23:13 | reactormonk | later. |
| 17:55:42 | reactormonk | how do I convert a float to a time? |
| 17:55:56 | reactormonk | ah, pure convert. |
| 17:56:11 | Araq | gradha: does your argument parser use any unsafe features? ;-) |
| 17:58:55 | gradha | no, but in the trash binary it calls the recycle proc, after some testing I could reproduce the crash in objc only code at http://stackoverflow.com/questions/15991036/why-cant-i-use-cocoa-frameworks-in-different-forked-processes |
| 17:59:17 | gradha | it seems cocoa APIs are crap http://stackoverflow.com/questions/8676371/can-i-call-chdir-or-setenv-after-fork-on-mac-os-x and don't play well with fork() |
| 18:00:48 | gradha | so I have no other option but to execute my own process in the background, what would be the api for that? |
| 18:01:00 | gradha | fork() + exec()? |
| 18:01:06 | Araq | lol no |
| 18:01:10 | Araq | we have osproc for that |
| 18:01:33 | reactormonk | Araq, can I add a converter TTime <-> TTimeInfo ? |
| 18:01:38 | Araq | osproc.startProcess |
| 18:02:06 | gradha | good think I don't care about the return value |
| 18:04:13 | Araq | reactormonk: converters are only for weak-willed |
| 18:04:39 | reactormonk | Araq, or for elegance |
| 18:04:39 | dom96 | reactormonk: what is with you and converters? |
| 18:05:08 | reactormonk | dom96, I don't see why I should write every proc twice, once for ttimeinfo and once with ttime |
| 18:05:33 | dom96 | why do you need to do that? |
| 18:06:03 | Araq | the procs should work with ttime |
| 18:06:09 | dom96 | yeah |
| 18:06:21 | Araq | ttimeinfo is only for displaying stuff |
| 18:06:24 | reactormonk | yup, but in JS, the two things are the same. |
| 18:06:29 | dom96 | TTimeInfo is only an object which provides you with extra info about TTime. |
| 18:06:31 | reactormonk | more or less. |
| 18:06:37 | reactormonk | dom96, and calculations. |
| 18:07:59 | dom96 | true, perhaps it was not wise of me to make the calculation procs work on TTimeInfo. |
| 18:08:31 | reactormonk | nope, you need that |
| 18:08:44 | reactormonk | because a minute is not always 60 seconds |
| 18:09:58 | reactormonk | proc fromSeconds*(seconds: float, time: TTime): TTimeInterval # any idea how to implement this? |
| 18:10:05 | reactormonk | I don't really need it though |
| 18:10:30 | reactormonk | I'll mark it as not implemented for now |
| 18:11:46 | dom96 | Why does it need a TTime? |
| 18:12:02 | reactormonk | because a minute is not always 60 seconds |
| 18:12:36 | dom96 | And how does TTime let you determine what a minute actually is? |
| 18:14:01 | reactormonk | you forward by x seconds and then see how many years/days/... you are apart |
| 18:15:34 | dom96 | Why not create your own TTime? |
| 18:16:39 | reactormonk | Because it's good code so far? |
| 18:18:00 | dom96 | huh? |
| 18:19:53 | reactormonk | given my concerns and result += float(getDaysInMonth(curMonth, anew.year) * 24 * 60 * 60) ... fuck it. |
| 18:19:59 | dom96 | initInterval already allows you to specify seconds. |
| 18:23:52 | reactormonk | proc UTC(time: TTime): float {.importcpp: "getTime", tags:[]} |
| 18:23:55 | reactormonk | proc toSeconds(time: TTime): float = result = time.UTC() |
| 18:23:58 | reactormonk | lib/pure/times.nim(522, 57) Error: type mismatch: got (int) but expected 'float' |
| 18:24:06 | reactormonk | ... what? |
| 18:24:13 | reactormonk | 522 is the second line |
| 18:25:35 | * | Trixar_za is now known as Trix[a]r_za |
| 18:26:13 | dom96 | weird |
| 18:26:30 | dom96 | You sure it's not using a different UTC proc? |
| 18:26:42 | reactormonk | yup |
| 18:27:00 | reactormonk | wait, it is |
| 18:27:13 | * | fowl quit (Ping timeout: 245 seconds) |
| 18:27:16 | reactormonk | but still wtf. |
| 18:29:36 | * | fowl joined #nimrod |
| 18:30:42 | Araq | UTC defined before toSeconds? |
| 18:33:57 | reactormonk | https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/UTC ... apparently not correct. |
| 18:35:04 | reactormonk | https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/valueOf correct. |
| 18:36:08 | reactormonk | fuck, JS is a mess... |
| 18:42:18 | reactormonk | getTzname is annoying without external data |
| 18:42:37 | reactormonk | https://bitbucket.org/pellepim/jstimezonedetect/src/f9e3e30e1e1f53dd27cd0f73eb51a7e7caf7b378/jstz.js?at=default#cl-130 |
| 18:43:18 | Araq | reactormonk: the JS version does not need to be on par feature wise with the C target version; just patch it so that it compiles again |
| 18:43:31 | reactormonk | Araq, empty string or a doassert false? |
| 18:43:37 | Araq | neither |
| 18:43:45 | Araq | 'when not defined(Js)' |
| 18:43:45 | reactormonk | lib/pure/times.nim(185, 14) Error: implementation of 'times.getTzname(): tuple[nonDST: string, DST: string]' expected |
| 18:45:38 | reactormonk | good, it compiles for both JS and C |
| 18:45:43 | reactormonk | how do I test it? |
| 18:46:21 | Araq | well you know how to |
| 18:46:45 | Araq | write an example program, check its output, use -d:nodejs -r for convenience |
| 18:46:59 | dom96 | or just test it in the browser. |
| 18:48:53 | reactormonk | ... are there any tests somewhere in the repo. |
| 18:48:56 | gradha | Araq: do you have a version of osproc.startProcess which searches the binary in the user's $PATH? |
| 18:50:00 | gradha | oh, poUseShell |
| 18:50:02 | Araq | gradha: there is os.findExe |
| 18:50:32 | reactormonk | lib/pure/times.nim(545, 11) Error: system module needs 'addChar' |
| 18:50:35 | reactormonk | ... |
| 18:51:38 | Araq | reactormonk: now that looks like a nice bug :-) |
| 18:51:50 | gradha | Araq: any difference with regards to running with poUseShell? that seems to work well |
| 18:52:07 | Araq | poUseShell doesn't work on windows iirc |
| 18:52:22 | Araq | and it's more efficient to not do it via a shell |
| 18:52:29 | Araq | but sure, if it works for you, it's fine |
| 18:54:41 | reactormonk | Araq, mergh |
| 19:00:18 | reactormonk | Araq, good, updated. |
| 19:00:31 | gradha | last time I checked the tmacro2.nim test was bogging my machine down with a virtual process size of total installed RAM, anything wrong with it? |
| 19:01:14 | reactormonk | Araq, got a nice idea for genRepr? just call toJSON? :-) |
| 19:02:13 | Araq | gradha: takes 24MB of ram here |
| 19:02:16 | gradha | dom96: the builder page lists my builder status as unknown, but the builder runnign says it's running fine and pinging |
| 19:02:36 | dom96 | gradha: That just means it hasn't built anything. |
| 19:02:53 | dom96 | Builder status is updated with the build stage, once your builder is actually building something. |
| 19:02:57 | gradha | dom96: what are the pending commits? |
| 19:03:11 | dom96 | If your builder reconnects, the status will be reset to "Unknown" |
| 19:03:28 | dom96 | gradha: hrm, that seems to be a bug. |
| 19:04:09 | dom96 | gradha: nimbuild is queuing the commits that have been pushed while your builder was disconnected. |
| 19:06:22 | dom96 | NimBot simply needs more commands so that I have the power to control NimBuild :P |
| 19:06:39 | Araq | indeed, it's pretty weak :P |
| 19:06:51 | Araq | it doesn't even pass the Turing test |
| 19:07:06 | dom96 | NimBot: Y U SO STUPID |
| 19:07:33 | Araq | ha, he ignores you. He's smart. |
| 19:07:41 | dom96 | lol |
| 19:08:20 | gradha | Araq: if I run the command manually it works fine, but look at this screencapture the other day, it was consuming everything it could http://dl.dropboxusercontent.com/u/145894/t/tmacro2%20memory%20problem.png |
| 19:10:46 | Araq | gradha: *shrug* ... some pain on macosx is to be expected |
| 19:12:24 | * | xcombelle quit (Remote host closed the connection) |
| 19:14:28 | Araq | ugh |
| 19:14:41 | Araq | how come nobody ever told me --path really sucks? |
| 19:15:02 | Araq | I do: nimrod c tests/manyloc/keineschweine/keineschweine.nim |
| 19:15:18 | Araq | and it wouldn't find sfml |
| 19:15:34 | Araq | because the configuration contains path = "dependencies/sfml" |
| 19:16:21 | fowl | yea |
| 19:16:22 | Araq | but it surely shouldn't contain test/manyloc/keineschweine/dependencies/sfml, right? |
| 19:16:43 | fowl | thats why id like to be able to have repositories |
| 19:16:49 | dom96 | the compiler should try it relative to the directory of the project |
| 19:16:54 | Araq | dom96: indeed |
| 19:16:58 | dom96 | if the path is not absolute ;) |
| 19:17:03 | Araq | yeah |
| 19:17:19 | Araq | now I hope I don't break anything if I change that ... |
| 19:18:43 | dom96 | Don't worry, the God's will forgive you. |
| 19:19:48 | Araq | hrm apparently you can do: path="$projectpath/dependencies/sfml" |
| 19:20:42 | fowl | before you add it let me remove the submodules |
| 19:21:02 | dom96 | hrm perhaps it makes sense to leave the behaviour as-is when using --path on the cmdline |
| 19:21:03 | dom96 | ? |
| 19:21:17 | Araq | fowl: I already did for inclusion into tests/manyloc |
| 19:21:31 | Araq | and the test case should stay static anyway |
| 19:21:45 | Araq | no need to update it |
| 19:22:11 | Araq | we want to ensure the compiler keeps compiling that version of the source |
| 19:22:26 | fowl | oh ok |
| 19:23:08 | fowl | i think i had a memory leak or overlap in there |
| 19:23:34 | Araq | I fixed the closure leak |
| 19:23:59 | fowl | the userdata pointer in cpshape/cpbody was getting touched somehow but i couldnt figure it out |
| 19:24:32 | Araq | *shrug* the test won't be run anyway ;-) |
| 19:24:42 | Araq | it's some nice stress test for the compiler |
| 19:24:57 | fowl | yea |
| 19:25:12 | Araq | you should checkout endb and watchpoints to figure out the corruption |
| 19:30:41 | * | zahary quit (Quit: Leaving.) |
| 19:35:44 | * | zahary joined #nimrod |
| 19:55:32 | NimBot | Araq/Nimrod 1e9ff02 Araq [+49 ±2 -0]: added manyloc test suite; --path now relative to project dir if not absolute |
| 20:05:37 | Araq | reactormonk: the tests still work for the C target too, right? |
| 20:08:08 | reactormonk | Araq, yup |
| 20:10:08 | reactormonk | Araq, at least the ones in times.nim |
| 20:10:53 | Araq | I don't think we have any other :P |
| 20:13:58 | NimBot | Araq/Nimrod e144b8b Simon Hafner [+0 ±1 -0]: added toSeconds and fromSeconds to times. fixes #334 |
| 20:13:58 | NimBot | Araq/Nimrod 321e32d Araq [+0 ±1 -0]: Merge pull request #384 from Tass/master... 3 more lines |
| 20:16:15 | Araq | gradha: https://github.com/gradha/argument_parser/blob/master/examples/ex_wget.nim is a deadlink |
| 20:16:27 | Araq | oh never mind |
| 20:16:42 | gradha | regexes FTW! |
| 20:20:21 | Araq | gradha: what commit triggered it? |
| 20:21:00 | gradha | no idea |
| 20:21:44 | gradha | according to the file dates anything in the last month |
| 20:21:55 | Araq | yay |
| 20:22:05 | Araq | good nothing happened during the last month |
| 20:23:21 | gradha | maybe we could add to nimrod's tester a superb option to compile external repos as test case |
| 20:24:33 | Araq | that has always been babel's real purpose ;-) |
| 20:26:34 | Araq | new_parsed_parameter is superfluous now that we have object constructor expressions, right? |
| 20:27:09 | gradha | it does some compile time tricks with when |
| 20:27:29 | gradha | how do the constructors work with variant objects? |
| 20:27:50 | Araq | obj(kind: value, otherField: 2) |
| 20:28:19 | Araq | the only thing to remember is to set 'kind' first |
| 20:28:29 | gradha | does it compile the other way round? |
| 20:29:35 | gradha | the template is a few keystrokes shorted due to not having to specify the field names |
| 20:29:44 | Araq | yeah but it fails at runtime |
| 20:29:52 | Araq | and yeah well |
| 20:30:04 | Araq | the template does it the deprecated way |
| 20:30:30 | Araq | however, we have thousands of lines that do it this way |
| 20:30:33 | gradha | when will deprecation take effect? |
| 20:30:41 | Araq | after 0.9.2 |
| 20:30:49 | gradha | so at nimrod 3000? |
| 20:34:49 | Araq | the official title would be Nimrod 40K ;-) |
| 20:34:59 | gradha | nice, Nimrod Warhammer |
| 20:36:06 | gradha | so this is why you like sunsets? http://www.wallpapervortex.com/wallpaper-17638_warhammer_40k.html |
| 20:37:39 | Araq | nah that's a coincidence |
| 20:38:00 | gradha | I want to play this version http://users.content.ytmnd.com/1/7/9/17983a1c0ecf7bb249e99a9c03c2d2ed.jpg |
| 20:38:14 | gradha | finally something matching my avatar |
| 20:39:11 | Araq | and I finally got used to your drunken pic |
| 20:39:41 | Araq | now you're some oxidized ferrum instead |
| 20:39:55 | gradha | I would prefer to use this one http://dl.dropbox.com/u/145894/cthugha_avatar.gif but gravatar sucks |
| 20:42:05 | Araq | just make it a png, the animation ain't that important |
| 20:44:02 | gradha | the animation is the good part |
| 20:45:26 | Araq | how kind of you to announce the new argument parser module that breaks the compiler |
| 20:45:53 | gradha | the module seems to work fine, it's the example which breaks it, or is it? |
| 20:46:05 | Araq | I dunno |
| 20:46:20 | Araq | reactormonk's patch broke C code generation and I don't know how |
| 20:46:24 | gradha | all the other examples work, so I though it's a specific problem of that one |
| 20:48:46 | reactormonk | Araq, ... what? |
| 20:48:57 | reactormonk | which one? |
| 20:49:37 | Araq | the one I just applied |
| 20:50:21 | dom96 | This seems the problem: lib/pure/times.nim(526, 24) Error: can have an unlisted effect: TEffect |
| 20:50:31 | reactormonk | damnit |
| 20:52:34 | reactormonk | it compiled :-( |
| 20:52:54 | reactormonk | I really need to read up on the effects system |
| 20:54:15 | Araq | good luck with that ;-) |
| 20:54:24 | Araq | I think only the spec mentions it |
| 20:54:45 | Araq | and then it's like 4 rules that describe how it works |
| 20:54:50 | Araq | but not what it does ;-) |
| 20:57:53 | reactormonk | argh |
| 21:26:46 | Araq | hrm #385 is pretty hard ... |
| 21:27:16 | gradha | I was going to start bisect it, want me to do so? |
| 21:27:30 | Araq | yes please |
| 21:27:46 | gradha | btw, didn't know fork is so evil http://stackoverflow.com/a/15991761/172690 |
| 21:29:19 | Araq | yeah me neither |
| 21:29:53 | Araq | I only knew it can cause problems with locks |
| 21:30:17 | Araq | but it's a nice new argument against unix fanbois |
| 21:50:18 | gradha | updated https://github.com/Araq/Nimrod/issues/385 |
| 22:13:21 | gradha | IIRC to use gcc-mp-4.6 I have to update some dotted linker variable in config/nimrod.cfg, any idea which one? |
| 22:58:04 | Araq | gcc.exe and gcc.linkerExe? |
| 22:58:32 | Araq | and set cc = gcc |
| 22:58:33 | gradha | yes, it's working now, after removing the fast-asm |
| 22:59:44 | Araq | are you sure about the bisect? |
| 22:59:53 | Araq | the patch that broke it looks strange |
| 23:00:06 | gradha | it compiles with the previous commit |
| 23:00:39 | gradha | btw, Aporia compiles with gcc-mp-4.6, so it's the clang version which fails |
| 23:01:26 | Araq | I'm sure zahary is working day and night to figure out the cause ;-) |
| 23:01:41 | Araq | maybe I should install clang, maybe it breaks here on linux too |
| 23:03:16 | Araq | gradha: the thing is ... if I make it return if x.typ.isNil then it fails later during codegen |
| 23:04:24 | gradha | why does the previous version work? |
| 23:04:38 | Araq | I don't know |
| 23:05:22 | gradha | wait, I'll try with the gcc version I have now |
| 23:06:40 | gradha | fails too |
| 23:07:14 | gradha | oh, the stack trace is different |
| 23:08:19 | Araq | uh oh |
| 23:08:33 | Araq | that sounds like some nasty corruption |
| 23:08:39 | Araq | what is the stack trace? |
| 23:09:09 | gradha | ah, no, it's the same, I must have been looking somewhere else |
| 23:09:15 | Araq | ah good |
| 23:20:10 | gradha | isn't also corruption that gcc compiles Aporia but clang not on macosx? |
| 23:26:07 | * | gradha quit (Quit: bbl, have youtube videos to watch) |
| 23:38:39 | dom96 | Araq: I think we should create some benchmarks and include them on the new website once 0.9.2 is released. |
| 23:43:53 | reactormonk | Araq, any idea how to implement genRepr for JS? gotta walk the JS object graph or something else? |
| 23:44:07 | reactormonk | zahary, got me an example session with serve? |
| 23:44:12 | reactormonk | just a console log. |
| 23:47:06 | dom96 | reactormonk: serve is just basically how you usually use idetools from the command line, i.e. nimrod idetools --def --track ..etc. you basically send it whatever you would execute from the command line but without the 'nimrod' |
| 23:47:31 | dom96 | reactormonk: also it seems that it currently requires a project filename when executing nimrod serve. |
| 23:47:43 | reactormonk | dom96, project filename? |
| 23:47:56 | dom96 | The main project file. |
| 23:48:04 | reactormonk | main project file? |
| 23:48:10 | dom96 | For example: for aporia this would be aporia.nim |
| 23:48:23 | dom96 | Your main file |
| 23:48:26 | dom96 | The file you compile |
| 23:48:43 | reactormonk | the file that pulls in all dependencies? |
| 23:48:58 | dom96 | yes |
| 23:49:32 | reactormonk | nimrod serve <project file>? |
| 23:49:37 | dom96 | yeah |
| 23:49:57 | dom96 | you also need to specify --server.type:stdin or --server.type:socket IIRC |