| 00:00:35 | EXetoC | it should run properly now that you've fixed your audio system |
| 00:01:30 | EXetoC | OrionPKM: it does include everything that is in the system directory |
| 00:02:16 | EXetoC | most of it anyway, depending on what is defined and what have you |
| 00:03:03 | fowl | Kooda, that cant work |
| 00:03:24 | fowl | Kooda, its should throw an error though |
| 00:03:27 | Kooda | Yep |
| 00:03:40 | Kooda | I was expecting this to fail at compile time |
| 00:03:47 | Varriount | Kooda, whatcha working on? |
| 00:04:06 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 00:04:59 | Kooda | fowl: does this mean I have one more bug report to do? /o\ |
| 00:05:22 | Kooda | Varriount: just messing around with the language ^^' |
| 00:05:43 | Varriount | Kooda, have fun. It helps if you can think like Araq |
| 00:05:50 | Kooda | Heh |
| 00:06:09 | Kooda | I don’t think like him, I found one bug per day of use ^^ |
| 00:06:32 | EXetoC | fowl: as in not currently? |
| 00:07:25 | Varriount | Kooda, when you take into account that mainly Araq, plus one or two others, have developed nimrod (which is quite complex, as languages go) bugs shouldn't be a surprise |
| 00:08:20 | fowl | Kooda, yes |
| 00:08:24 | Kooda | Varriount: sure! I don’t really care, in fact I like finding bugs, it helps :) |
| 00:10:08 | BitPuffin | EXetoC: oh, forgot to check! :D |
| 00:10:56 | fowl | EXetoC, no, unlike an array, each index of a tuple can be a different type |
| 00:11:43 | EXetoC | fowl: of course you could check that constants are used in the for loops etc, but I don't know if it's too magic |
| 00:11:47 | Kooda | Oh, maybe I just use an array here ^^' |
| 00:11:53 | Kooda | I should just* |
| 00:12:16 | Kooda | EXetoC: yep, in fact I was expecting the compiler to unfold the loop for me ^^' |
| 00:14:00 | EXetoC | ok |
| 00:14:42 | Kooda | OR throwing an error at compile time. :) |
| 00:14:51 | EXetoC | Kooda: or you can cast when needed |
| 00:15:10 | Kooda | ? |
| 00:15:48 | Kooda | From array to tuple? |
| 00:17:28 | EXetoC | instead of using an array, if it makes sense for the interface. I focus on usability first, so my matrix type is tuple[x, y, z, w: TVec4], and then I just cast to an array of floats when needed. easy as pie |
| 00:17:32 | EXetoC | or cake |
| 00:17:51 | Kooda | Heh |
| 00:18:38 | Kooda | I want to keep the fields names though, and it’s just 4 (evil-unsigned) integers :) |
| 00:23:49 | * | dom96_and quit (Quit: Bye) |
| 00:25:04 | EXetoC | ok, but only this one time |
| 00:25:29 | Kooda | What do you mean? |
| 00:25:40 | BitPuffin | EXetoC: you forgot the public domain thingy :D |
| 00:25:57 | EXetoC | bah |
| 00:26:17 | BitPuffin | EXetoC: add a comment explaining that it is in the public domain and refer to COPYING.txt and add to you commit message: |
| 00:26:34 | BitPuffin | The author or authors of this code dedicate any and all copyright interest in this code to the public domain. We make this dedication for the benefit of the public at large and to the detriment of our heirs and successors. We intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this code under copyright law. |
| 00:26:54 | BitPuffin | anyways |
| 00:26:57 | BitPuffin | I have to sleeep now |
| 00:26:59 | BitPuffin | goodnight! |
| 00:27:03 | Kooda | ’night! :) |
| 00:27:11 | * | brson joined #nimrod |
| 00:27:14 | BitPuffin | see you guys |
| 00:27:16 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 00:30:58 | boydgreenfield | Newbie question: Can any one point me to a either the best docs/tutorial on interfacing with C and/or a good example implementation module? I'm trying to import/use a C implementation of the MurmurHash3 hashing algorithm (vs. reimplementing it), and have not yet figured out the best place to start w/ regards to FFI, the .compile, .importc, etc. pragmas. Many thanks in advance for the help! |
| 00:31:25 | OrionPKM | I think murmur is already wrapped on babel |
| 00:32:52 | * | webskipper quit (Ping timeout: 264 seconds) |
| 00:32:54 | boydgreenfield | Oh really? I'll look to that implementation first then... |
| 00:33:30 | boydgreenfield | (Ah, that's in pure Nimrod though) |
| 00:34:36 | boydgreenfield | (And it's only a 32-bit implementation) |
| 00:43:10 | fowl | boydgreenfield, heres an example of a small wrapper https://github.com/fowlmouth/nim-termbox/blob/master/termbox.nim |
| 00:43:29 | boydgreenfield | fowl: thx! |
| 00:47:55 | OrionPKM | fowl i like how the file ends with Magnitude's catch phrase |
| 00:48:00 | OrionPKM | "Pop pop!" |
| 00:48:42 | fowl | lol |
| 00:59:22 | joelmo | this is not working for me, should it work: nimrod idetools --eval 'echo("hi")' |
| 00:59:38 | joelmo | command line(1, 1) Error: argument for command line option expected: '--eval' |
| 01:00:51 | joelmo | i use 9.2 |
| 01:01:36 | fowl | use : after --eval |
| 01:03:28 | joelmo | seems to be working but where does the output go |
| 01:15:24 | * | xenagi joined #nimrod |
| 01:24:49 | boydgreenfield | Another newbie question (sorry!): var x = 14688674573012802306'u64 (which is > 2**63, but < 2**64) |
| 01:25:02 | boydgreenfield | gives me the following error: "bloom_filter.nim(113, 10) Error: number 14688674573012802306 out of valid range" |
| 01:25:23 | boydgreenfield | How should I input a number > 2**63 and < 2**64 if I want it in a test case? |
| 01:32:42 | * | q66_ joined #nimrod |
| 01:35:06 | Varriount | boydgreenfield, is there any specific reason you need a number that large? |
| 01:35:38 | boydgreenfield | Varriount: Not really... I just have a hash function that outputs 2 64-bit unsigned integers |
| 01:35:55 | boydgreenfield | Varriount: So I suppose I got the 1/64 chance test case that is outside of the range of a signed 64-bit int |
| 01:36:02 | * | q66 quit (Ping timeout: 246 seconds) |
| 01:37:04 | Varriount | boydgreenfield, unfortunately, we don't have any bignum implementations at the moment. |
| 01:37:39 | Varriount | And without seeing your code, I don't know what changes could be made to alleviate the problem |
| 01:37:52 | boydgreenfield | Varriount: No worries. Would you suggest just taking it as a signed 64-integer and then taking the absolute value? – I don't need the additional hash space. |
| 01:38:12 | Varriount | Whats the source of your integer? |
| 01:40:05 | boydgreenfield | MurmurHash3 hash function |
| 01:40:28 | Varriount | And it gives you an unsigned int? |
| 01:40:30 | boydgreenfield | the current C code I'm wrapping just outputs an unsigned 64-bit integer |
| 01:41:02 | Varriount | boydgreenfield, and you are using it to do..? |
| 01:41:20 | boydgreenfield | Varriount: Good hash function for a bloom filter implementation |
| 01:42:11 | Varriount | First off, my knowledge of such things is mostly theoretical, but couldn't you just cast the unsigned int to a signed one? |
| 01:42:33 | Varriount | I mean, the only difference between the two is how the data is interpreted. |
| 01:43:53 | boydgreenfield | No, absolutely -- I just wasn't sure if it was worth having negative indices to the bit array (i.e., getting cast to a negative integer) vs. having a slightly smaller hash space. |
| 01:44:10 | boydgreenfield | I was really just curious because I was trying to assert hash_output == big_unsigned_integer |
| 01:44:15 | Varriount | I really couldn't say. |
| 01:44:34 | boydgreenfield | and I got that error message, which I found somewhat cryptic given that it's a valid uint64 |
| 01:44:47 | Varriount | One moment.. |
| 01:44:52 | * | brson quit (Ping timeout: 264 seconds) |
| 01:46:44 | * | brson joined #nimrod |
| 01:51:24 | Varriount | boydgreenfield, this is probably a stupid question, and I should have realized this before, but isn't an unsigned int supposed to go up to 18,446,744,073,709,551,615? |
| 01:51:36 | Varriount | *64 bit unsigned int |
| 01:52:08 | boydgreenfield | Yep |
| 01:52:13 | boydgreenfield | That's why I found it odd. |
| 01:52:23 | boydgreenfield | 14688674573012802306 < 18446744073709551616 (2**64) |
| 01:52:30 | Varriount | Or wait.. *looks at integer page on wikipedia* |
| 01:52:36 | boydgreenfield | but > 2**63 (9223372036854775808) |
| 01:52:42 | boydgreenfield | I may have this wrong too... :) |
| 01:53:25 | boydgreenfield | (It also doesn't really matter, I've just cast them as int64s, which also have mod and other various operations implemented for them which are missing for unsigned ints) |
| 01:53:53 | Varriount | boydgreenfield, so here's an odd thing, which I think is a bug in nimrods range checking |
| 01:54:59 | * | ics joined #nimrod |
| 01:55:51 | Varriount | boydgreenfield, I think this is a bug. |
| 02:04:05 | boydgreenfield | Varriount: Got it. Ok -- now for another silly question. Is there a way to turn off overflow checking / exception handling for a function (maybe a pragma?)? I have something that may end up doing 2**63 * 4, for example, which overflows but I really don't care that it overflows as I take the final answer mod some_value_less_than_2**64. But I'd prefer not to have to take the modulus multiple times on various inputs. Again this |
| 02:04:05 | boydgreenfield | relates to hashing. |
| 02:04:20 | boydgreenfield | (EOverflow specifically) |
| 02:04:22 | Varriount | boydgreenfield, nimrod --advanced |
| 02:04:38 | Varriount | there's a list of runtime checks that you can turn off |
| 02:04:53 | Varriount | nimrod c --rangeCheck:off should do it |
| 02:04:55 | boydgreenfield | Can one do it for a specific "unsafe" function though? |
| 02:04:59 | boydgreenfield | vs. the whole program? |
| 02:05:06 | Varriount | I think so.. |
| 02:05:27 | Varriount | boydgreenfield, http://nimrod-code.org/manual.html#compilation-option-pragmas |
| 02:05:36 | Varriount | boydgreenfield, congratulations, you found a bug. |
| 02:05:37 | boydgreenfield | Thx, will look. |
| 02:06:25 | Varriount | Nimrod is doing static range checks on integers, and is checking them against the int64 range |
| 02:06:40 | * | Varriount gives a cookie to boydgreenfield |
| 02:06:45 | boydgreenfield | found it. |
| 02:06:50 | boydgreenfield | mm thx! |
| 02:10:17 | Varriount | boydgreenfield, you use the negative indices feature of arrays? |
| 02:10:24 | fowl | boydgreenfield, you can {.push checks: off.} in your function |
| 02:10:51 | boydgreenfield | fowl: having trouble getting that work at the moment. Can I only do it for a proc? (vs. isMainModule code) |
| 02:11:26 | Varriount | You can't attach it as a procedure pragma? |
| 02:12:25 | Varriount | boydgreenfield, put {.push checks:off.} at the start of your procedure body, and then {.pop.} at the end of the body |
| 02:12:41 | fowl | i just tried it |
| 02:12:48 | fowl | the push/pop need to be outside the function |
| 02:12:56 | Varriount | -_- |
| 02:23:14 | boydgreenfield | Cool got it working. Thanks both! |
| 02:32:12 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 02:32:13 | * | fundamental quit (Ping timeout: 246 seconds) |
| 02:32:52 | boydgreenfield | Incidentally the behavior in the isMainModule code piece is a bit weird to me (but maybe this is by design). E.g., {checks: off} disables assertions successfully in a isMainModule block but still raises EOverflow exceptions. Gist example: https://gist.github.com/boydgreenfield/7866606 |
| 02:33:50 | Varriount | boydgreenfield, bug report? |
| 02:34:36 | Varriount | boydgreenfield, also, see if --implicitStatic:off helps any |
| 02:34:51 | boydgreenfield | Varriount: Sure, happy to add unless it's only supposed to be for procs (but then I guess there's mb a documentation shortfall) |
| 02:35:11 | boydgreenfield | Varriount: same. |
| 02:38:09 | Varriount | You know, if I didn't have to go to classes, I would be happy to fix these errors. |
| 02:38:40 | Varriount | It's like, they call out to me, crying for someone to fix them. |
| 02:42:30 | boydgreenfield | I'll take a look at where they're getting raised and see if I can generate a PR... but that is *somewhat* unlikely given I've only been playing around w/ nimrod for a few days |
| 02:44:44 | fowl | lol |
| 02:45:41 | * | fundamental joined #nimrod |
| 02:47:53 | boydgreenfield | Varriount: I'm on 0.9.2, were you seeing the "invalid number" bug for unsigned 64-bit integers over 2**63 on 0.9.3 as well? (e.g., 9223372036854775798'u64) |
| 02:48:11 | boydgreenfield | Want to confirm before opening GitHub issue and trying to track down underlying issue. |
| 02:52:54 | Varriount | boydgreenfield, I run the nimrod using the master branch. Yes, I see the range check issue |
| 02:53:30 | boydgreenfield | Got it. Tracked down where it's getting raised in the lexer, but there's a somewhat more complex issue as the TKUInt64 type isn't implemented |
| 02:53:51 | boydgreenfield | so I'll open an issue but can't do a PR w/o really getting up to speed on how the lexer works |
| 02:54:10 | Varriount | boydgreenfield, well, if you can say that "the TKUInt64" type isn't implemented, then that's a great help |
| 02:54:49 | Varriount | It's likely that you could copy whatever code handles the other number literals, and modify it to fit, if you wanted to. |
| 03:05:58 | boydgreenfield | Well, I'll give it a shot in the next day or two hopefully. |
| 03:06:27 | boydgreenfield | issue in the meantime as a flag for anybody experiencing the same issue: https://github.com/Araq/Nimrod/issues/723 |
| 03:07:32 | Varriount | boydgreenfield, thanks. |
| 03:07:54 | boydgreenfield | (And this is where it's unfortunate that I never took any CS classes in college) |
| 03:07:57 | boydgreenfield | Varriount: np. |
| 03:10:48 | Varriount | I have finals for the next two weeks. |
| 03:11:28 | Varriount | And of course, my math professor just gave us a test on something we learned 1 class (2 days) beforehand |
| 03:17:08 | OrionPKM | so its fresh in your mind |
| 03:17:27 | fundamental | that sounds pretty normal |
| 03:18:00 | boydgreenfield | Varriount: FYI if you still want to take a look at that Bloom filter implementation, it's fairly usable at this point: www.github.com/boydgreenfield/nimrod-bloom |
| 03:20:12 | * | ics joined #nimrod |
| 03:20:48 | boydgreenfield | and *very* fast now |
| 03:21:19 | Varriount | OrionPKM, fundamental, let me restate that. SHe tried to teach us a major section on conics in 45 minutes. |
| 03:21:43 | Varriount | And the professor got her own questions wrong half the time. |
| 03:22:48 | fundamental | Varriount: heh, a few years back I saw a professor get sacked after students started skipping her sections and going to another professor's time slot. usually attempted teaching is better than "figure it out on your own as it will be on the exam" |
| 03:24:17 | * | Varriount grumbles |
| 03:24:41 | fundamental | :p |
| 04:07:28 | * | xenagi quit (Quit: Leaving) |
| 04:28:02 | * | brson quit (Quit: leaving) |
| 04:31:20 | * | DAddYE joined #nimrod |
| 04:31:20 | * | DAddYE quit (Remote host closed the connection) |
| 04:31:26 | * | DAddYE joined #nimrod |
| 04:37:42 | * | DAddYE quit (Remote host closed the connection) |
| 04:38:09 | * | DAddYE joined #nimrod |
| 04:40:29 | * | DAddYE quit (Read error: Connection reset by peer) |
| 04:40:52 | * | DAddYE joined #nimrod |
| 04:41:03 | * | DAddYE quit (Remote host closed the connection) |
| 04:41:10 | * | DAddYE_ joined #nimrod |
| 06:08:20 | * | isenmann joined #nimrod |
| 06:26:33 | * | hoverbear quit (Quit: Hibernating, be back soon.) |
| 06:47:46 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:16:34 | * | boydgreenfield joined #nimrod |
| 07:46:02 | * | XAMPP_ quit (Ping timeout: 240 seconds) |
| 07:49:37 | * | webskipper joined #nimrod |
| 07:54:39 | boydgreenfield | Another newbie question if folks are around: adding the -d:release flag to the compiler simply creates a non-debug build? Is that ever going to optimize away work if the answers aren't being used? (like some optimization flags on certain C compilers?) Curious because I'm seeing a ~5x speedup which... is either really awesome or concerning, but I'm not sure what to think. |
| 07:55:01 | PortablePuffin | fundamental: you probably want to be running the git version! |
| 07:55:41 | PortablePuffin | boydgreenfield: It does optimizations |
| 07:57:07 | boydgreenfield | PortablePuffing: I guess my more specific question is how it compares to various C compiler -O levels. I'm essentially curious if the 1M lookups I do in this test are getting (partially) optimized away: https://github.com/boydgreenfield/nimrod-bloom/blob/master/bloom.nim |
| 07:57:32 | boydgreenfield | Because timing went from ~1.3secs to ~0.25 secs |
| 07:57:47 | PortablePuffin | who's PortablePuffing? |
| 07:58:04 | boydgreenfield | (It looks good given the counter... but it's just an astonishing speedup) |
| 07:58:12 | boydgreenfield | sorry :). Puffin* |
| 07:58:19 | PortablePuffin | anyways I think you can see which flags are passed when compiling |
| 07:58:22 | PortablePuffin | :D |
| 07:58:37 | boydgreenfield | (too used to typing "ing" ) |
| 07:58:57 | PortablePuffin | But iirc one of the flags is -O3 |
| 08:00:03 | fowl | boydgreenfield, there is also the optimizing flag -O |
| 08:03:33 | boydgreenfield | Hmm. |
| 08:04:24 | fowl | another thing you lose is stacktraces and assertions |
| 08:04:52 | boydgreenfield | Yep seeing that in the docs now. |
| 08:05:32 | boydgreenfield | Ok, wow. I *think* the C compiler is just doing some terrific work in this case (makes some sense given the low-level nature of the code). |
| 08:09:00 | boydgreenfield | (I'm coming from Python-land, so it's just a rather startling difference to pass a flag and get a 5x win) |
| 08:14:10 | PortablePuffin | haha |
| 08:14:53 | PortablePuffin | well look at the linea that start with, "gcc" (or whichever compiler you're using) to see the flags |
| 09:01:09 | * | PortablePuffin quit (Read error: Connection reset by peer) |
| 09:05:47 | * | PortablePuffin joined #nimrod |
| 09:06:05 | NimBot | nimrod-code/packages master 360c363 boydgreenfield [+0 ±1 -0]: Add bloom package... 2 more lines |
| 09:06:05 | NimBot | nimrod-code/packages master a008a44 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Merge pull request #41 from boydgreenfield/patch-1... 2 more lines |
| 09:22:09 | webskipper | Is there a difference between nimrod installer and build.bat in zip package ? Because the build.bat can't find my gcc.... |
| 09:22:26 | webskipper | no probs with prev nimrod version installed by the installer |
| 09:23:44 | Araq | yeah something is broken, I know |
| 09:23:52 | Araq | need to rebuild the zip, I know |
| 09:23:56 | webskipper | oh I see mingw is not in |
| 09:25:01 | webskipper | argh win is pain :D |
| 09:26:28 | webskipper | I copied the dist folder, seems to work now |
| 09:36:31 | * | ccedrik joined #nimrod |
| 09:38:26 | * | CarpNet joined #nimrod |
| 09:39:37 | Araq | hi ccedrik welcome |
| 09:40:38 | fowl | Araq, i want to rename existsFile to fileExists |
| 09:40:58 | Araq | fowl: -.- |
| 09:41:11 | Araq | dirExists too then? |
| 09:41:16 | fowl | yes |
| 09:41:27 | Araq | I suppose I can live with an alias |
| 09:41:28 | fowl | its more english |
| 09:41:50 | Araq | it's inconsistent though |
| 09:42:02 | fowl | inconsisten with what |
| 09:42:39 | * | promswet quit (Remote host closed the connection) |
| 09:42:53 | Araq | verb+noun is the common way of naming procs, "hasKey" |
| 09:43:44 | Araq | createDir |
| 09:44:38 | fowl | exists is a different kind of verb |
| 09:44:47 | Araq | perhaps we should name it "isFile" and "isDir"? |
| 09:45:40 | Kooda | checkForThatDirToExist :x |
| 09:47:11 | fowl | i dont like isfile/isdir >_> |
| 09:47:16 | Araq | maybe our naming convention should forbid "exists" as a verb :P |
| 09:47:53 | webskipper | I propose to put the link to http://build.nimrod-lang.org/ on http://nimrod-lang.org/download.html |
| 09:48:12 | fowl | in ruby its File.exists?("somefile") |
| 09:48:42 | * | radsoc joined #nimrod |
| 09:50:03 | Araq | webskipper: well in theory releases are more stable than the github version |
| 09:50:55 | fowl | thats bs i've never seen instability on github |
| 09:51:30 | Araq | fowl: oh really? git version doesn't compile keineschweine anymore ;-) |
| 09:51:58 | Araq | in fact, I'm working on that right now |
| 09:52:00 | fowl | thats probably my fault |
| 09:52:13 | Araq | well it's a test, so it doesn't change |
| 09:52:15 | fowl | i noticed it hangs up on endians |
| 09:52:31 | fowl | (the one from fowlmouth/keineschweine) |
| 09:52:42 | fowl | oh yeah i want to add swapendian16() to endians |
| 09:52:54 | Araq | what's that? |
| 09:53:13 | fowl | like the other swap endian functions, for 16 bits |
| 09:54:39 | Araq | alright go ahead |
| 09:54:59 | Araq | fileExists is fine with me too, but make it an alias for existsFile please |
| 09:55:20 | fowl | ok |
| 09:55:21 | webskipper | Araq: let the user choose. it makes sense to link the unstable releases too. |
| 09:57:23 | Araq | webskipper: ok, fair enough |
| 09:57:33 | Kooda | fowl: speaking of swapendian*, I checked the implementation, I think it’s possible to do better. Modern CPU have byte swap instructions. (that’s why I use ntoh(s|l) instead) |
| 09:58:44 | webskipper | Araq: ty |
| 10:06:16 | Araq | Kooda: that code isn't optimized at all |
| 10:10:19 | webskipper | Have we @annotation annotations in nimrod ? |
| 10:11:43 | Araq | we have {.pragmas-} |
| 10:12:02 | Araq | and you can create your own and process them in a macro |
| 10:13:32 | fowl | lol the documentation for swap says that it's faster than tmp = a; a = b; b = tmp; but that is what swap() does |
| 10:13:51 | Kooda | xD |
| 10:15:01 | * | ccedrik quit (Remote host closed the connection) |
| 10:16:00 | Araq | fowl: that depends on the type though. It surely is faster for strings :P |
| 10:16:04 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 10:17:40 | webskipper | btw: is there a hardware coded swap instruction by intel / amd ? |
| 10:18:00 | webskipper | I guess it makes sense because lot of algs use swap() |
| 10:20:54 | Araq | http://x86.renejeschke.de/html/file_module_x86_id_21.html |
| 10:21:34 | webskipper | aah, nice - BSWAP :D |
| 10:22:50 | webskipper | seems to change the order only |
| 10:23:57 | webskipper | http://en.wikipedia.org/wiki/Compare-and-swap |
| 10:24:41 | webskipper | since 80486 ^^ |
| 10:25:20 | Araq | well compare-and-swap is something entirely different |
| 10:31:47 | webskipper | http://en.wikibooks.org/wiki/X86_Assembly/Data_Transfer#Data_swap |
| 10:32:21 | * | ics quit (Ping timeout: 245 seconds) |
| 10:34:06 | * | ics joined #nimrod |
| 11:04:37 | * | q66_ is now known as q66 |
| 11:56:03 | * | Varriount quit (Read error: Connection reset by peer) |
| 11:56:32 | * | Varriount joined #nimrod |
| 12:15:40 | * | webskipper quit (Read error: Connection reset by peer) |
| 12:16:17 | * | DAddYE_ quit (Remote host closed the connection) |
| 12:45:46 | * | BitPuffin joined #nimrod |
| 12:59:07 | EXetoC | BitPuffin: now my example branch showing up |
| 12:59:38 | EXetoC | and it claims that no changes have been made when I try to create a pull request |
| 12:59:45 | dom96 | hello people |
| 13:00:14 | EXetoC | hi |
| 13:04:25 | EXetoC | *doesn't show up |
| 13:05:15 | EXetoC | someone said that the branch had to be closed so that it'd accept the commit. do I have to re-open it now? |
| 13:06:39 | BitPuffin | ahoy EXetoC |
| 13:06:53 | BitPuffin | EXetoC: who said that and what woot? |
| 13:06:59 | BitPuffin | EXetoC: re-open it if you closed |
| 13:07:29 | BitPuffin | hey dom96 |
| 13:07:30 | EXetoC | I tried to find a way to commit only a message. so is that what it takes? closing and opening |
| 13:08:19 | BitPuffin | EXetoC: maybe, but you can make a new commit anyway, putting a comment in the source file about that it's in the public domain and see COPYING.txt for details. And put in the commit message the thingy you know |
| 13:08:27 | BitPuffin | I have no idea if you need to reopen or not |
| 13:08:29 | BitPuffin | maybe you do |
| 13:12:43 | fowl | you should just push to the branch to add to the PR |
| 13:12:54 | fowl | then again, idk what yall talking about |
| 13:14:33 | EXetoC | fowl: This is for a repository in mercurial |
| 13:14:33 | BitPuffin | fowl: we are talking about hg and bb |
| 13:17:51 | fowl | o |
| 13:18:22 | BitPuffin | p |
| 13:26:33 | EXetoC | the example is gone. can't be bothered with this right now |
| 13:27:35 | BitPuffin | EXetoC: I still see the PR lol |
| 13:27:49 | BitPuffin | ah |
| 13:27:52 | BitPuffin | you deleted the repo |
| 13:27:54 | BitPuffin | lol |
| 13:28:21 | BitPuffin | why did you do that |
| 13:31:54 | BitPuffin | dom96: maybe me or someone should create an aur pkg for libtarsnap |
| 13:32:00 | BitPuffin | to make it easy to use scrypt |
| 13:32:19 | dom96 | why is libtarsnap required? |
| 13:32:47 | EXetoC | that doesn't even seem to be a thing |
| 13:33:00 | BitPuffin | dom96: because scrypt is in there |
| 13:33:48 | fowl | aur is good |
| 13:34:07 | fowl | isnt there a scrypt impl in a crypto lib already covered though |
| 13:35:01 | BitPuffin | fowl: ? like what |
| 13:35:39 | * | zielmicha joined #nimrod |
| 13:36:30 | fowl | idk im not a crypto-monkey |
| 13:37:11 | xlq | I don't think scrypt is very popular. (Maybe you're thinking of bcrypt, which is more popular.) |
| 13:37:13 | BitPuffin | fowl: what kind of monkey are you then |
| 13:37:30 | fowl | the one that never gets anything done :( |
| 13:37:40 | BitPuffin | he's probably confusing it with bcrypt yeah |
| 13:37:48 | BitPuffin | scrypt is much newer |
| 13:38:36 | fowl | write something useful |
| 13:38:39 | fowl | like nimcoin |
| 13:38:49 | fowl | premine 10,000 of them |
| 13:38:51 | fowl | get rich later |
| 13:39:41 | BitPuffin | no u |
| 13:42:45 | * | zielmicha quit (Ping timeout: 265 seconds) |
| 13:42:47 | BitPuffin | no EBadParameters ? |
| 13:43:23 | EXetoC | ? |
| 13:43:41 | * | zielmicha joined #nimrod |
| 13:45:04 | BitPuffin | EXetoC: yeah like if someone provided bad data |
| 13:45:12 | BitPuffin | like an id for something that doesn't exist |
| 13:48:21 | Araq | there is EInvalidValue |
| 13:49:03 | Araq | which has the same fuzzy feeling |
| 13:49:04 | EXetoC | I saw that one, but thought the description was very specific |
| 13:49:24 | Araq | lol? how can "invalid value" be specific? |
| 13:49:37 | BitPuffin | EInvalidValue = object of ESynch |
| 13:49:38 | BitPuffin | is the exception class for string and object conversion errors. |
| 13:49:58 | BitPuffin | this has nazing to do with conversions |
| 13:50:03 | Araq | damn |
| 13:50:10 | Araq | my docs disagree with me |
| 13:50:15 | BitPuffin | hahaha |
| 13:50:17 | BitPuffin | :D |
| 13:50:21 | BitPuffin | well you could always update the docs |
| 13:50:29 | BitPuffin | it's an appropriate error I think |
| 13:51:17 | Araq | well I don't think the stdlib cares about this piece of documentation but I dunno |
| 13:51:17 | BitPuffin | in fact I'm gonna use it here |
| 13:51:21 | BitPuffin | so you better ;) |
| 13:56:03 | fowl | EInvalidValue - to be used for anything except invalid values |
| 13:56:21 | BitPuffin | damn it |
| 14:09:03 | * | Varriount quit (Ping timeout: 260 seconds) |
| 14:11:13 | EXetoC | BitPuffin: I deleted the branch because I had no clue what was going on, so I just wanted to start from scratch |
| 14:11:57 | EXetoC | and then vim failed me. maybe it doesn't even cache small files -.- |
| 14:13:53 | BitPuffin | EXetoC: haha :D |
| 14:13:56 | BitPuffin | noob |
| 14:13:58 | BitPuffin | jk |
| 14:19:51 | BitPuffin | EXetoC: you'll figure it out :D |
| 14:23:39 | BitPuffin | EXetoC: easy peasy |
| 14:26:07 | BitPuffin | EXetoC: tbh I've never done a PR with hg before |
| 14:26:17 | * | xlq left #nimrod (#nimrod) |
| 14:26:18 | BitPuffin | but it should be straight forward most likely :D |
| 14:29:18 | EXetoC | so how much experience *do* you have? must be a specific feature set of hg that you think is better |
| 14:31:51 | BitPuffin | EXetoC: Well I know how to do the same things or more that I know in git and have found hg to just do everything in a way that makes more sense |
| 14:31:55 | BitPuffin | and I came from gitt |
| 14:32:09 | BitPuffin | it's not like I started with hg and got grumpy at git because it's different |
| 14:36:35 | BitPuffin | one thing to keep in mind is hg branch != git branch |
| 14:36:42 | BitPuffin | hg bookmark ~= git branch |
| 14:37:52 | BitPuffin | what |
| 14:38:04 | BitPuffin | since when does statements from templates need to be discarded |
| 14:38:11 | BitPuffin | s/from/in/ |
| 14:38:37 | BitPuffin | this seems fishy |
| 14:40:13 | EXetoC | is there a value at the end? |
| 14:40:37 | BitPuffin | shouldn't these be best friends? https://gist.github.com/BitPuffin/3f02d0488c67d169124c |
| 14:41:09 | BitPuffin | Araq: yell at me!! |
| 14:41:32 | EXetoC | does getRow return anything? and why templates? |
| 14:41:57 | fowl | gah getfromwhere |
| 14:42:23 | fowl | im going to write a smalltalk-to-nimrod language :p |
| 15:01:01 | * | noam_ joined #nimrod |
| 15:01:29 | * | noam quit (*.net *.split) |
| 15:03:41 | * | gradha joined #nimrod |
| 15:17:05 | PortablePuffin | exeteoc: yeah they do |
| 15:17:19 | PortablePuffin | exetoc: because why not :D |
| 15:18:58 | EXetoC | more forced inline madness? :p anyway, if it returns a value then it has to be discarded |
| 15:20:06 | EXetoC | no wait |
| 15:21:20 | EXetoC | too few details, and that doesn't even compile on its own |
| 15:22:24 | EXetoC | but the value returned on the last line isn't discarded, so it should work. just use functions and see what happens |
| 15:22:55 | * | tylere joined #nimrod |
| 15:24:00 | EXetoC | and if for whatever reason you don't want to use functions, try to change the return type from expr to some actual type |
| 15:24:19 | * | fntzr joined #nimrod |
| 15:25:30 | PortablePuffin | EXetoC yeah that's what I considered |
| 15:25:42 | PortablePuffin | it's just sqlite |
| 15:25:50 | PortablePuffin | it should work |
| 15:28:04 | EXetoC | what should? |
| 15:28:38 | EXetoC | nvm |
| 15:30:05 | Kooda | If somebody has the time someday, I would really need an explanation about integers in nimrod ^^' |
| 15:34:58 | tylere | Kooda: What about them? |
| 15:35:11 | tylere | They seem pretty garden-variety to me |
| 15:37:10 | Kooda | I keep hurting myself with them x) |
| 15:38:42 | EXetoC | why? |
| 15:40:56 | EXetoC | The differences from C for example that I can think of are the fact that overflow checking is supported, and that unsigned operators need to be imported explicitly |
| 15:43:30 | Kooda | unsigned integers are completly incompatible with signed ones |
| 15:45:40 | EXetoC | unsigned operations are so rare that I'm not bothered by having to perform an explicit conversion to signed |
| 15:45:49 | EXetoC | or the other way around |
| 15:46:39 | Kooda | It’s not rare in my case. |
| 15:46:42 | EXetoC | maybe it's a common use pattern for you, but if it's really necessary then you must be writing really low level code |
| 15:46:52 | Kooda | I’m working with memory locations and offsets |
| 15:47:02 | Kooda | I am |
| 15:47:25 | EXetoC | still, it's just 5-ish additional characters in some cases |
| 15:48:43 | EXetoC | x + y.int8 ... x.uint8 + y |
| 15:49:27 | EXetoC | I don't recommend trying to shorten it, but you could if you really wanted to |
| 15:50:05 | EXetoC | unless this isn't the issue. if not, please elaborate |
| 15:53:07 | tylere | So how far are we from cutting a 0.9.3 release? |
| 15:53:50 | OrionPKM | 0.9.4 release |
| 15:54:07 | gradha | tylere: christmas|hannukah |
| 15:54:10 | tylere | cool |
| 15:54:11 | EXetoC | I've never heard of an ETA |
| 15:54:16 | EXetoC | rly |
| 15:54:22 | tylere | so odd minor vers are dev versions? |
| 15:54:23 | gradha | EXetoC: note how I didn't mention year |
| 15:54:24 | tylere | makes sense |
| 15:54:28 | EXetoC | true |
| 15:54:39 | OrionPKM | gradha, hannukah is already over ;P |
| 15:54:41 | dom96 | Before Christmas I think. |
| 15:55:02 | gradha | OrionPKM: you mean, there's not going to be any more hannukahs? Poor people |
| 15:55:11 | OrionPKM | not until 2014 |
| 15:57:12 | EXetoC | BitPuffin: this is how you'd extend that alloc interface: https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim#L14 |
| 15:58:37 | gradha | dom96: you look saner today |
| 15:58:54 | dom96 | gradha: I didn't look sane before? |
| 15:58:56 | fowl | there should be an issue goal |
| 15:58:59 | Kooda | EXetoC: oh, seems to be exactly what I need. |
| 15:59:05 | Kooda | I started implementing something like that |
| 15:59:09 | gradha | dom96: you had some weird _and attached and stuff |
| 15:59:10 | fowl | like 100 issues til .9.4 |
| 15:59:28 | dom96 | gradha: I see. |
| 15:59:55 | EXetoC | Kooda: no unsigned ints though. complain to fowl if necessary |
| 16:00:06 | Kooda | fowl: does pointer_arithm works with the pointer type? |
| 16:01:00 | EXetoC | try it. but my guess would be that you'd have to work with a concrete type |
| 16:01:19 | Kooda | EXetoC: in fact, I have 32 bits offsets and I’m not sure it’s safe to use int32 for that. Will it raise an exception if I overflow the 2-complement? |
| 16:01:22 | EXetoC | alternatively, a set of overloads could be provided |
| 16:01:51 | fowl | Kooda, it has to be a concrete type (what is the size of void?) |
| 16:01:59 | Kooda | Because it’s anoying to use uint*, for example I can’t do setLen(mystr, myuint) |
| 16:02:06 | Kooda | fowl: one byte |
| 16:02:50 | Kooda | Well, in fact, it depends… I have to think about it a bit more |
| 16:03:22 | fowl | Kooda, if unsigned ints really annoy you, you can do `converter toint (some: uint32): int32 = int32(some)` |
| 16:03:26 | Kooda | For now I only use byte pointers, but I only read uint32 with it |
| 16:03:41 | EXetoC | try this: var x = int.high; x += 1. doesn't work for int16, int32 etc |
| 16:03:45 | Kooda | fowl: yes, but what about overflow? |
| 16:05:06 | EXetoC | I assume that's a bug. surely it should be triggered no matter what. it's very limited otherwise |
| 16:05:14 | fowl | Kooda, how likely is that |
| 16:05:38 | fowl | Kooda, you could instead converter uint32 to int64 |
| 16:06:02 | Kooda | But then I’ll lose memory for nothing |
| 16:06:26 | EXetoC | ok I see that you've reported a similar (bug?) |
| 16:06:38 | Kooda | Yep |
| 16:07:12 | Kooda | I’m really thinking in C now, maybe that’s my problem. ^^ |
| 16:07:45 | EXetoC | many aspects of the language naturally maps to C concepts |
| 16:09:25 | * | rallipilot quit (Remote host closed the connection) |
| 16:09:47 | * | Varriount joined #nimrod |
| 16:10:05 | Kooda | I’ll think about that a bit more. Could I show it here for review after that? |
| 16:10:34 | Varriount | Good morning! |
| 16:11:17 | Varriount | Anyone know why I get an error about the folder "testability" not being found? |
| 16:12:19 | gradha | Varriount: maybe you lack a folder named "testability"? |
| 16:12:27 | gradha | Varriount: is that nimrod related? |
| 16:13:02 | Varriount | gradha, yes |
| 16:13:37 | Varriount | Nevermind, it fixed itself. |
| 16:13:38 | gradha | Varriount: my git checkout doesn't contain the case insensitive workd testability |
| 16:14:22 | gradha | maybe it's some nimbuild thingy? |
| 16:14:28 | Varriount | (I forgot to run my symlink-mirroring script) |
| 16:15:00 | tylere | fowL: What is this "converter" magic? I don't see that mentioned in the tutorial |
| 16:15:53 | tylere | n/m, found it in the manual |
| 16:15:53 | gradha | tylere: not everything can fit in the tutorial, look up "Convertible relation" in the manual |
| 16:15:54 | tylere | neat |
| 16:16:05 | tylere | feels a bit like implicits in scala |
| 16:16:29 | Varriount | gradha, I think it's a new compiler file. I was mistaken when I said 'folder'. They way I store nimrod, I have one common directory that has all it's files (but not folders, they are created) symlinked |
| 16:16:50 | Varriount | *symlinked to directories for 64 and 32 bit builds |
| 16:17:08 | EXetoC | do you think there should be more shortcuts for applying an operation to individual tuple and/or array elements? |
| 16:17:17 | Varriount | EXetoC, yes. |
| 16:18:00 | Varriount | However, I also think that dogs should fly. So my opinion may not be worth much. |
| 16:18:32 | tylere | I kinda miss python's anonymous tuples a bit |
| 16:18:49 | Varriount | I thought you could make anonymous tuples? |
| 16:18:50 | EXetoC | anonymous as in (1, 2)? |
| 16:18:58 | tylere | can you? |
| 16:18:58 | EXetoC | yes that's one |
| 16:19:06 | EXetoC | fk yeah! |
| 16:19:32 | tylere | ahh, so you can! |
| 16:19:52 | Varriount | Today I Learned: Nimrod has anonymous tuples |
| 16:20:03 | Varriount | *Today tylere Learned |
| 16:20:06 | fowl | lies |
| 16:20:08 | fowl | oh |
| 16:20:50 | tylere | The only limitation seems to be that array-style access only works with constants, unlike in python where you can essentially treat it like a read-only array, even loop over it |
| 16:21:14 | gradha | tylere: doesn't the field accessor work? |
| 16:21:20 | gradha | or was it fields? |
| 16:21:30 | tylere | gradha: if it's an anonymous tuple there are no field names |
| 16:21:41 | tylere | var x = (1,2,3,"foo") |
| 16:21:43 | fowl | gradha, difference between dynamic/static |
| 16:21:50 | fowl | tylere, * |
| 16:21:59 | gradha | tylere: can't you use len on the tuple and a simple loop? |
| 16:22:07 | EXetoC | but apparently you can't do tuple[int, int]. that's very minor though, since giving the individual elements a name doesn't really add any restrictions |
| 16:23:26 | EXetoC | tylere: what do you mean? this works, and a isn't a constant: "var a = (1, 2, 3); echo a[0]" |
| 16:23:55 | EXetoC | *'a' |
| 16:24:20 | EXetoC | (highly ambiguous correction) |
| 16:24:22 | fowl | EXetoC, but this doesnt: var i = 1; echo a[i] |
| 16:24:40 | gradha | tylere: len doesn't work, but field does -> for field in x.fields: echo repr(field) |
| 16:25:11 | Varriount | Sorry that the windows bots went down - I think my power went out last night due to the snowfall |
| 16:25:46 | zielmicha | quoteIfContainsWhite is evil |
| 16:26:05 | Varriount | zielmicha, I saw some bug reports about that, what does it do? |
| 16:26:06 | zielmicha | almost any piece of code using it in Nimrod is incorrect |
| 16:26:21 | zielmicha | it is supposed to quote like shell, but not exactly |
| 16:26:30 | gradha | zielmicha: I think it's because of that that argument parsing doesn't work very well sometimes and I wrote my own module |
| 16:26:35 | Varriount | zielmicha, then point out the places where it needs fixing, and fix it. |
| 16:26:42 | Varriount | Or get someone else to fix it. |
| 16:26:47 | * | boydgreenfield joined #nimrod |
| 16:27:03 | zielmicha | I'm going to do it. See https://github.com/Araq/Nimrod/issues/726 for proposed solution. |
| 16:27:51 | * | Varriount claps for zielmicha |
| 16:28:07 | Varriount | zielmicha, what was it's intender purpose? |
| 16:28:19 | EXetoC | fowl: oh. well he was being a bit vague. do you think it should work? |
| 16:28:23 | gradha | zielmicha: I think this is another place where it all fails beautifully https://github.com/Araq/Nimrod/issues/274 |
| 16:28:47 | EXetoC | fowl: I wouldn't mind being restricted to using constants, since it's a little less magic |
| 16:28:54 | fowl | EXetoC, no, it cant possibly work |
| 16:29:23 | Varriount | Magic! *throws glitter at EXetoC* |
| 16:29:37 | EXetoC | fowl: there's nothing impossible about it, but it would involve some magic like I said |
| 16:29:55 | EXetoC | but anyway your answer was no :p |
| 16:30:16 | fowl | EXetoC, say you have for n in 0 .. 3: echo mytuple[n] this calls $ on mytuple[n], which may change types in each iteration (int, array, string, char) |
| 16:30:43 | Varriount | fowl, but what if the type doesn't have a $ proc? |
| 16:30:56 | EXetoC | which implies a potential exception raised |
| 16:30:57 | fowl | Varriount, eh? |
| 16:31:18 | EXetoC | = magic |
| 16:31:36 | Varriount | Oh. nevermind. Anyone know where the magic regarding system procedures like "high" is? |
| 16:31:50 | Varriount | I mean, in the compiler code. |
| 16:34:38 | fowl | Varriount, grep -i mhigh /your/Nimrod/compiler/*.nim |
| 16:34:55 | Varriount | I'm on windows. |
| 16:35:11 | fowl | i'm sorry :( |
| 16:35:17 | EXetoC | get yourself an ack then |
| 16:35:19 | gradha | Varriount: there should be a dog you can ask stuff there |
| 16:35:25 | fowl | EXetoC, it cannot work. |
| 16:35:34 | Varriount | gradha, no, you're thinking of the paperclip |
| 16:35:44 | Varriount | The dog ran away. |
| 16:35:58 | gradha | Varriount: you could try to use nimgrep, but only if Araq allows you to |
| 16:36:05 | fowl | EXetoC, for n in 0..3: var it = mytuple[n] # it is going to be different sizes each iteration, stack smashing |
| 16:36:13 | gradha | Varriount: tools/nimgrep.nim |
| 16:36:20 | Varriount | gradha, http://antyweb.pl/wp-content/uploads/2012/08/If+Microsoft+Windows+were+a+hammer_490b8d_3924408-600x400.jpg |
| 16:36:40 | gradha | Varriount: there are rumors it's a cross platform grep, even better than the original |
| 16:36:42 | EXetoC | fowl: different example though |
| 16:37:19 | fowl | EXetoC, i wrote a macro for someone who wanted to do this |
| 16:37:37 | fowl | https://gist.github.com/fowlmouth/aa06e723494708c8d21b |
| 16:37:44 | EXetoC | so, not impossible :p but what crazy fool needed it? |
| 16:38:21 | fowl | EXetoC, it is impossible....my macro unrolls the loop by duplicating code |
| 16:39:29 | EXetoC | I didn't mention any particular restrictions. ok I think we're done :p |
| 16:39:48 | fowl | you wanted to use it in a for loop! |
| 16:39:50 | fowl | i still win!! |
| 16:40:10 | fowl | EXetoC, btw, if {.unroll.} actually worked, this would be conceptually fine |
| 16:40:27 | * | tylere is currently renewing his love/hate relationship with project euler |
| 16:41:27 | Varriount | fowl! |
| 16:41:47 | tylere | Oh, I have a question about let.... is let just reference immutability or total immutability? If I do something like let x = @[1,2,3] can I mutate the array or is that not allowed? |
| 16:41:56 | Varriount | Why did you remove most of windows.nim, *without* checking whether it was used by other libs? |
| 16:41:56 | tylere | s/array/seq |
| 16:42:18 | gradha | tylere: in the case of a sequence immutability is shallow |
| 16:42:21 | fowl | Varriount, more fun that way |
| 16:42:32 | Varriount | fowl, terminal.nim imports windows.nim |
| 16:42:40 | * | Varriount slaps fowl around a bit with a cosmic mackeral. |
| 16:42:41 | EXetoC | fowl: using for in conjunction with 'fields' for example doesn't perform any magic? |
| 16:42:46 | fowl | Varriount, change it to use winlean please |
| 16:43:34 | gradha | tylere: I'd expect you can't change an array entry but the entry itself could be a mutable object |
| 16:44:17 | * | PortablePuffin quit (Ping timeout: 250 seconds) |
| 16:44:24 | fowl | EXetoC, read the description of fields |
| 16:44:29 | tylere | gradha: that appears to be more or less the case from poking at it in the repl |
| 16:44:54 | gradha | tylere: arrays and seqs have the same shallow behaviour |
| 16:45:05 | gradha | tylere: also, repl usage is discouraged due to many limitations |
| 16:45:10 | tylere | gradha: I understand ;) |
| 16:45:27 | tylere | I guess I'm a bit more used to Scala, where most things are actually pointers internally |
| 16:45:55 | tylere | so "immuatable" vars really generally means you just can't assign an entirely new object, but can mutate the underlying object more-or-less at will |
| 16:46:05 | Varriount | fowl, and what of the modules that require things in windows.nim, that winlean does not provide? |
| 16:46:18 | Varriount | Or the other windows modules? |
| 16:46:41 | fowl | Varriount, well they shouldnt but if you find any let me know |
| 16:47:14 | gradha | tylere: it's difficult for a language to guarantee total immutability, after all, if you create your own object and assign it with let, how do you do a constructor? |
| 16:47:42 | tylere | sure |
| 16:48:03 | Varriount | fowl, terminal.nim, dialogs.nim |
| 16:48:09 | OrionPKM | dom96 babel search win => nimrod-glfw, nim-glfw |
| 16:48:27 | Varriount | And no, simply changing windows to winlean does *not* fix it. |
| 16:48:37 | dom96 | OrionPKM: yes? |
| 16:48:41 | fowl | dialogs is going to be babel-ified |
| 16:48:55 | Varriount | And terminal? |
| 16:49:00 | OrionPKM | dom96 shouldn't "windows" be a result? |
| 16:49:16 | * | Varriount is miffed |
| 16:49:25 | dom96 | OrionPKM: Did you run 'babel update'? |
| 16:49:25 | OrionPKM | since there's a package called "windows" now |
| 16:49:27 | OrionPKM | yes |
| 16:49:30 | OrionPKM | it's in the lis |
| 16:49:33 | OrionPKM | babel list* |
| 16:50:16 | fowl | Varriount, i doubt you need the full windows wrapper for conIO stuff |
| 16:50:33 | dom96 | OrionPKM: hrm, indeed. |
| 16:50:36 | Varriount | fowl, *I* don't need it, terminal.nim needs it. |
| 16:50:44 | * | gradha is disturbed by a google image search of mittens |
| 16:50:52 | Varriount | And all the other window's wrappers. |
| 16:50:57 | OrionPKM | dom96 search doesnt look at pkg titles? |
| 16:51:06 | dom96 | OrionPKM: it should |
| 16:51:12 | dom96 | so it's a bug |
| 16:51:13 | gradha | OrionPKM: try "babel install babel" |
| 16:51:32 | OrionPKM | gradha nou |
| 16:51:44 | gradha | OrionPKM: unfortunately it's still difficult to know which version of babel, but some of them should work, hopefully latest |
| 16:51:53 | dom96 | gradha: it doesn't work for me |
| 16:52:26 | gradha | dom96: well, I have this on my todo: |
| 16:52:31 | gradha | At the moment the search command will exit if a (partial) |
| 16:52:31 | gradha | [tag match is found |
| 16:52:31 | gradha | first](https://github.com/nimrod-code/babel/blob/master/babel.nim#L368). |
| 16:52:31 | gradha | Maybe it should keep trying with names and instead use a |
| 16:52:31 | gradha | hash table to avoid repeating displaying the same package? |
| 16:52:50 | dom96 | hrm, that's probably it. |
| 16:53:06 | Varriount | dom96, any way to change the download and install directories for babel? |
| 16:53:16 | EXetoC | fowl: you're implying that a loop can only be transformed in so many ways |
| 16:53:20 | dom96 | Varriount: Not currently |
| 16:53:29 | Varriount | -_-* |
| 16:53:34 | fowl | EXetoC, what |
| 16:55:02 | gradha | Varriount: it really did snow, you have a snowflake on your head |
| 16:57:40 | Varriount | Yes. And it's currently vaporizing under the heat of my irritation |
| 16:58:10 | Varriount | I doubt you would like it if half your stuff stopped compiling. |
| 16:58:31 | NimBot | nimrod-code/babel master 94ff509 Dominik Picheta [+0 ±1 -0]: Implemented tag querying for git. Ref #18. |
| 16:58:31 | NimBot | nimrod-code/babel master c6fa301 Dominik Picheta [+0 ±1 -0]: Search will now continue even if packages are found based on tag name. |
| 16:58:43 | Varriount | dom96, why does babel contain what looks to be a wholesale copy of nimrod? |
| 16:58:56 | * | hoverbear joined #nimrod |
| 16:59:04 | dom96 | Please check if you guys can still install packages because ^^ might've broken some things. |
| 16:59:21 | dom96 | Varriount: a wholesale copy of Nimrod? |
| 16:59:30 | fowl | scrypt.nim installs |
| 16:59:33 | gradha | awww, now https://github.com/nimrod-code/babel/pull/19 doesn't merge |
| 16:59:35 | tylere | Is there any shortcut for var foo: seq[int] = @[]? |
| 16:59:45 | EXetoC | fowl: for loop as for loop. I don't care what part of the statement performs the bloody operation |
| 16:59:47 | Varriount | dom96, the directory structure looks like a copy of nimrod |
| 16:59:48 | fowl | tylere, var foo = newseq[int]() |
| 16:59:57 | tylere | cool, thanks |
| 17:00:19 | fowl | EXetoC, sorry but wtf are you talking about |
| 17:00:57 | dom96 | Varriount: ~/.babel? |
| 17:01:07 | EXetoC | dick |
| 17:01:09 | dom96 | how does it? |
| 17:01:15 | Varriount | No, babel, the repo, the install directory. |
| 17:01:31 | EXetoC | that attitude |
| 17:02:45 | dom96 | Varriount: I don't see the resemblance |
| 17:03:24 | Varriount | dom96, |
| 17:03:25 | Varriount | https://gist.github.com/Varriount/7875923 |
| 17:04:32 | gradha | maybe the git command does weird stuff on windows and stargated your nimrod checkout into babel? |
| 17:04:36 | fowl | EXetoC, i dont want to explain anymore why regular for loops wont work with tuples, is there more you wanted to talk about |
| 17:04:55 | Varriount | gradha, I just did a fresh clone. |
| 17:05:03 | dom96 | what, that's the nimrod repo? |
| 17:05:46 | Varriount | Thats the file tree of what I have after I clone and build babel |
| 17:06:57 | gradha | it's amazing, considering that https://github.com/nimrod-code/babel doesn't even have directories |
| 17:07:20 | Varriount | I know. Which is why I'm puzzled. |
| 17:07:50 | fowl | you're drunk Varriount |
| 17:08:00 | gradha | Varriount: you did mention erlier doing symlink stuff, that's could be satanic |
| 17:08:03 | Varriount | I don't drink. |
| 17:08:21 | * | PortablePuffin joined #nimrod |
| 17:08:24 | gradha | Varriount: hah, it's never too late to start! |
| 17:08:24 | Varriount | fowl, I dislike anything alchoholic. It all tastes like rubbing alchohol to me. |
| 17:08:36 | dom96 | high then? |
| 17:08:37 | fowl | even beer? |
| 17:09:02 | Varriount | fowl, yes. dom96, I wouldn't even know *where* to get drugs, even if I did have the inclination. |
| 17:09:23 | gradha | Varriount: at the chemical level drinking alcohol is the same as drinking coke, the difference coke is more boring and you are legally allowed to destroy your liver with it and have diabetes |
| 17:10:16 | Varriount | I don't drink soda, except on special, rare occasions. |
| 17:10:29 | EXetoC | fowl: I meant magic everything, including 'for' |
| 17:10:36 | EXetoC | PortablePuffin: still hacking the compiler? |
| 17:10:38 | * | PortablePuffin quit (Read error: Connection reset by peer) |
| 17:10:58 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 17:10:58 | gradha | Varriount: in that case the only other thing you could be high on is maybe sugar. Still, quite unlikely to have stargated your babel checkout |
| 17:11:15 | fowl | EXetoC, you dont need magic for, someone just needs to implement {.unroll.} |
| 17:12:14 | * | BitPuffin quit (Quit: WeeChat 0.4.2) |
| 17:12:27 | gradha | Varriount: have you tried to replicate it on another directory? |
| 17:14:31 | EXetoC | fowl: apparently that's neither magic nor regular then, but ok case closed |
| 17:14:43 | * | boydgreenfield joined #nimrod |
| 17:15:30 | * | PortablePuffin joined #nimrod |
| 17:17:35 | Araq | what? who removed windows.nim? |
| 17:18:40 | fowl | <- |
| 17:18:55 | Araq | why? |
| 17:19:14 | fowl | it was on the list of things to make into babel packages |
| 17:19:17 | * | boydgreenfield quit (Ping timeout: 265 seconds) |
| 17:20:09 | Araq | well that's too bad, add it back then |
| 17:22:35 | fowl | k |
| 17:23:26 | gradha | hmmm... looks like "git revert e3d3cf5f8fe7e5030f7d1db316e684dd484111d3" would undo that |
| 17:24:56 | fowl | will you do it then |
| 17:25:14 | gradha | sure |
| 17:25:47 | fowl | thanks |
| 17:25:54 | OrionPKM | can probably also remove the babel package hten |
| 17:29:26 | * | brson joined #nimrod |
| 17:29:26 | * | Varriount_ joined #nimrod |
| 17:29:44 | * | Varaway joined #nimrod |
| 17:29:51 | NimBot | Araq/Nimrod master 18ad6db Grzegorz Adam Hankiewicz [+8 ±0 -0]: Revert "removed windows". Refs #698.... 2 more lines |
| 17:29:51 | NimBot | Araq/Nimrod master f05bad8 Grzegorz Adam Hankiewicz [+8 ±0 -0]: Merge pull request #727 from gradha/pr_recovers_windows_code... 2 more lines |
| 17:32:04 | * | Varriount quit (Ping timeout: 246 seconds) |
| 17:32:04 | * | Varaway is now known as Varriount |
| 17:33:21 | NimBot | nimrod-code/packages master 6433df0 Billingsly Wetherfordshire [+0 ±1 -0]: Update packages.json... 2 more lines |
| 17:49:45 | Kooda | If anyone has some time, I would like this to be reviewed :) https://kooda.upyum.com/bazar/tmp/nimrod/ |
| 17:52:44 | * | boydgreenfield joined #nimrod |
| 17:53:50 | * | DAddYE joined #nimrod |
| 17:56:34 | Araq | Kooda: utilitites.stringAt is horrible |
| 17:56:46 | Kooda | Explain |
| 17:56:48 | Araq | result = newString(size) |
| 17:56:55 | Kooda | Ok :) |
| 17:56:57 | Araq | instead of = ""; setLen() |
| 17:57:03 | Kooda | Yep |
| 17:57:05 | dom96 | Kooda: "This Connection is Untrusted" :( |
| 17:57:13 | Kooda | dom96: self-signed cert |
| 17:57:26 | Araq | and it looks inefficient |
| 17:57:28 | dom96 | i'll trust it then |
| 17:58:10 | Araq | but I guess it's the best one can do here |
| 17:58:18 | Kooda | I’m open to any suggestion, I don’t do much low-level work |
| 17:59:34 | Araq | meh it's good enough I guess |
| 17:59:46 | Araq | you need to change TFSEntry to do better |
| 17:59:54 | Kooda | How? |
| 18:00:22 | Araq | for "name" you could use a (cstring,len) pair |
| 18:00:42 | Araq | but that's harder to work with so ... it's fine |
| 18:01:02 | Kooda | Hm, yes. And the names will disapear someday |
| 18:01:10 | Kooda | (they only are in the debug rom) |
| 18:02:14 | tylere | Suggestion: single argument (The target array) version of ReadBytes that reads the entire file |
| 18:04:06 | Kooda | I use a TMemFile her |
| 18:04:08 | Kooda | here* |
| 18:06:23 | * | CarpNet quit (Quit: Leaving) |
| 18:07:29 | Kooda | If you have any documentation or ideas about binary file parsing, please tell me. :) |
| 18:07:39 | Kooda | I was thinking of implementing a DSL for that |
| 18:07:53 | tylere | Kooda: I was thinking about that the other day |
| 18:08:03 | tylere | I tend to think python's struct module is a good way to implement |
| 18:08:11 | tylere | and can probably be essentially ported to nim |
| 18:08:18 | tylere | although it would probably require macros |
| 18:08:23 | tylere | at least to do it efficiently |
| 18:08:57 | Kooda | I was also thinking about something like python’s struct yes |
| 18:09:11 | Kooda | Yes, and I don’t really like strings in DSL |
| 18:09:22 | Kooda | They are not easily checked at compile time |
| 18:09:25 | tylere | in a really really ideal world you'd probably have some sort of C struct converter also |
| 18:09:55 | Kooda | I’m wondering if it would be possible to do a parser from binary to nimrod object |
| 18:10:11 | Kooda | So, pretty much that yes |
| 18:11:01 | tylere | I don't think TMemFile will actually work me |
| 18:11:13 | tylere | because I do need to mutate but _don't_ want those changes written to disk |
| 18:11:17 | Varriount_ | dom96, the builders might go down for a bit. I found out the reason why I was getting nimrod's directory copied into babel's |
| 18:11:26 | * | Varriount quit (Disconnected by services) |
| 18:12:04 | tylere | The project I have in mind is a Z-Machine intepretor, if you're familiar |
| 18:12:17 | * | Varaway joined #nimrod |
| 18:13:28 | tylere | (if you're not, it's basically the simplest VM/emulator project you could do that's actually useable and wortewild) |
| 18:13:38 | tylere | it can run all the old text adventure games, Zork, etc |
| 18:13:59 | fowl | dom has a gbemulator in the works |
| 18:14:07 | tylere | and the format is well documents and you're not emulating physical hardware, so you don't have to worry about timing or anything, or even graphics |
| 18:14:14 | tylere | neat |
| 18:14:19 | tylere | that's a bit beyond my skills |
| 18:15:26 | * | Varriounz joined #nimrod |
| 18:15:34 | * | Varriounz is now known as Varriount |
| 18:16:31 | * | Varaway quit (Ping timeout: 245 seconds) |
| 18:20:08 | * | Varriount quit (Quit: Meep!) |
| 18:21:53 | Araq | oh btw gradha, let for sequences is not shallow immutable, it's "deep" in the sense that no element of the sequence may be modified |
| 18:24:25 | tylere | good to know |
| 18:24:38 | tylere | makes sense given how value-oriented nimrod is |
| 18:25:12 | gradha | sorry, I meant the objects of the sequence can be changed, mutated, or whatever you call them |
| 18:26:21 | gradha | I guess I have a different concept of deepness then |
| 18:26:41 | Kooda | tylere: didn’t know about it. I only knew about chip8 |
| 18:28:28 | * | fntzr quit (Quit: Leaving) |
| 18:29:02 | tylere | Kooda: It's a really cool thing, historically |
| 18:29:03 | fowl | it would be more fair to say that let acts like T *const instead of const T* |
| 18:29:08 | tylere | arguably the very first VM |
| 18:29:27 | tylere | They had these text adventure games, circa 1980 or so, and of course at that time you had ten-gazillion home platforms |
| 18:29:36 | tylere | pc, apple, amiga, commodore, armstrad, etc |
| 18:29:52 | tylere | so they wrote a VM optimized for their exact use case, which they only had to port once per platform |
| 18:30:14 | tylere | and then all of their games just bundled the interpreter with the game file, which was sort of a psuedo-executable |
| 18:30:42 | Kooda | tylere: that’s nice : |
| 18:30:43 | Kooda | :) |
| 18:30:43 | tylere | it does run a lot like a real computer...there's a static heap, a stack, a call stack, a current instruciton pointer... |
| 18:31:01 | Kooda | Ok :D |
| 18:31:37 | tylere | but unlike real hardware theres no bios, or interrupts, or timers, or anything like that so it's much easier to emulate, since you don't have to worry about any of that, or making it run "real time" |
| 18:34:24 | Araq | scummvm in nimrod would be cooler though |
| 18:34:25 | Kooda | The files I show you are our first step at making a clone of the Zelda64 engine ^^ |
| 18:35:16 | Kooda | It reads the filesystem from the ROM, I was able to watch some textures already :) |
| 18:35:43 | tylere | neat |
| 18:35:56 | tylere | not working on a general-purpose n64 emu? |
| 18:35:59 | tylere | just zelda? |
| 18:36:07 | tylere | Araq: agreed, but that's a harder project ;) |
| 18:36:31 | tylere | Araq: I wanted something substantial, but also something I could conceivable get working in maybe 2 weeks of evenings or something |
| 18:36:36 | Araq | *shrug* just c2nim all of scummvm |
| 18:36:43 | Kooda | tylere: just zelda yes |
| 18:37:04 | Kooda | Araq: that would be a huge test case for c2nim :D |
| 18:38:18 | Kooda | tylere: it would work for Ocarina of Time and Majora’s Mask, since they use pretty much the same engine. |
| 18:38:32 | Kooda | Our goal is not to emulate, it’s to have a native version of it |
| 18:38:54 | tylere | gotcha |
| 18:40:17 | * | viteqqq joined #nimrod |
| 18:40:33 | fowl | cool |
| 18:41:04 | tylere | Is there any stdlib function to dump seqs/arrays (possibly nested) to stdout? |
| 18:41:11 | tylere | echo only seems to work with a basic types |
| 18:41:15 | Kooda | $? repr? |
| 18:41:15 | Varriount_ | tylere, echo(repr(x)) |
| 18:41:23 | tylere | ahh, repr |
| 18:41:24 | tylere | duh |
| 18:41:29 | tylere | that's even the same as in pythion |
| 18:42:25 | Varriount_ | The only time I have had repr() not work is in the case of nimrod compiler data structures. |
| 18:42:32 | * | Varriount_ is now known as Varriount |
| 18:43:08 | Kooda | Unsigned integers are also messed up :x |
| 18:43:21 | OrionPKM | araq, any ideas on how I might build an easily parseable index (ala http://nimrod-lang.org/theindex.html )? |
| 18:43:26 | tylere | hrrm... while stdin.ReadLine(line): doen't work as expected |
| 18:43:32 | OrionPKM | but with XML or JSON |
| 18:43:34 | tylere | it sigsegvs with an illegal storge access |
| 18:43:51 | Araq | var line = "" |
| 18:44:00 | Araq | should fix that |
| 18:44:01 | Varriount | tylere, see the rdstdin if you need standard input |
| 18:44:38 | OrionPKM | araq i'd like to make a quick doc lookup in our ST plugin |
| 18:44:47 | Varriount | Araq, why is the procedure for reading from standard input (user input) in it's own module, with no other functions? |
| 18:45:04 | Varriount | Wouldn't it make sense to put it in a module like terminal? |
| 18:45:06 | Araq | Varriount: becuase it depends on gnu readline on linux |
| 18:45:08 | tylere | Varriount: I'm trying to read piped in text, not do a prompt |
| 18:45:48 | tylere | although I guess it should work |
| 18:46:07 | gradha | OrionPKM: during the generation of the index, *.idx files are temporarily generated, you could concatenate and parse those |
| 18:46:33 | OrionPKM | what generates the index? |
| 18:46:42 | Araq | OrionPKM: just follow "koch web" |
| 18:46:48 | OrionPKM | mmk |
| 18:46:58 | Araq | that's what I do, I never remember anything |
| 18:47:15 | Araq | ultimately it's generated by the compiler of course |
| 18:47:23 | OrionPKM | right |
| 18:48:27 | Varriount | Emptying Recycle Bin... 15GB Remaining |
| 18:49:10 | EXetoC | PortablePuffin: I think you told me to add a notice about COPYING.txt as well, and in the commit message. surely that's not necessary. I added it to the source file though in the second commit |
| 18:51:09 | Araq | dom96: any idea how we should integrate babel into http://nimrod-lang.org/lib.html ? |
| 18:52:29 | dom96 | loop through packages.json, clone them and run nimrod doc on them? |
| 18:52:42 | Varriount | Araq, do like what python is doing. Add a basic version of babel capable of updating itself |
| 18:53:06 | Varriount | Possibly in ./tools/ |
| 18:53:35 | Araq | dom96: well I'd like to add only marked packages |
| 18:53:40 | * | ossiana joined #nimrod |
| 18:53:40 | * | ossiana quit (Remote host closed the connection) |
| 18:54:18 | Araq | Varriount: no idea what you mean. Python is famous for its huge stdlib + PyPI split |
| 18:54:36 | dom96 | Araq: Could use the tags to determine which. |
| 18:54:57 | Araq | dom96: nah, I guess I'll have my own list somewhere |
| 18:55:13 | Araq | otherwise people can simply claim it's stdlib like quality |
| 18:55:16 | Varriount | Araq, well, you probably haven't been following recent developments |
| 18:55:20 | tylere | Suggestion: Module documentation broken out by the type of the first argument, for none-basic types. So, all the TFile functions grouped together for instance |
| 18:55:30 | fowl | :D |
| 18:55:41 | fowl | tags: ["araq-approved"] |
| 18:56:09 | Varriount | Araq, what is being done is that a bootstrap version of pip (successor to easy_install) is being included in python's scripts directory |
| 18:56:41 | dom96 | Araq: or you could check if they are in the nimrod-code org. |
| 18:56:51 | Araq | tylere: we know. nobody is implementing that though. |
| 18:56:52 | Varriount | That way, pip can be updated seperately from the stdlib, while still being part of it. |
| 18:57:19 | Araq | dom96: hmm good point |
| 18:57:59 | tylere | Araq: I may have to dive into the nimrod doc generating code at somepoint. Is that part of koch? Is there any roadmap that lays all this out? |
| 18:58:02 | * | fowl is wrapping llvm-c |
| 18:58:52 | * | tylere is now known as TylerE_Meeting |
| 18:58:55 | Araq | tylere: it all starts with "koch", koch doesn't do much itself though, it's a delegator because I can't remember the various tools and how to invoke them |
| 18:59:24 | Araq | it's all not documented but following the source is reasonably easy |
| 18:59:50 | Varriount | I like koch. |
| 19:01:36 | * | zahary___ joined #nimrod |
| 19:01:40 | Araq | wow, how come? |
| 19:04:12 | * | zahary__ quit (Ping timeout: 252 seconds) |
| 19:04:50 | gradha | fowl: aren't you meant to use llvm to wrap C libraries for nimrod instead? |
| 19:06:50 | OrionPKM | araq nimrod dump doesn't list babel paths, should it? |
| 19:07:11 | Araq | I guess it should |
| 19:07:28 | Araq | but this whole babel path needs to be re-thought |
| 19:07:31 | EXetoC | Araq: why? you don't? seems like a useful tool aggregator |
| 19:08:02 | Araq | EXetoC: well I like it, but people at various times suggested it's from hell and I should use "make" instead |
| 19:08:24 | EXetoC | :E |
| 19:08:29 | gradha | because make is less hellish? |
| 19:08:35 | Varriount | ^ |
| 19:08:53 | Araq | because "make" can deal with recursive dependencies so easily ;-) |
| 19:08:54 | Varriount | Araq, koch is much, much better than make |
| 19:09:17 | Araq | I know. bootstrapping is a big recursive dependency |
| 19:09:25 | Araq | which "make" can't handle |
| 19:10:08 | Varriount | Araq, it took me 2 weeks to compile a half-baked build of gcc. It took me 20 minutes to build nimrod. |
| 19:10:45 | Araq | Varriount: yes. but those are boring facts. These people live in the amazing Unix land instead. |
| 19:11:01 | fowl | gradha, its a vm though |
| 19:11:16 | Araq | Where nothing works, but that's a well thought out feature. |
| 19:12:03 | Varriount | Make is a vm? |
| 19:12:42 | fowl | gradha, what did you mean use it to wrap c libraries? was that a joke |
| 19:12:58 | gradha | fowl: I had the impression that clang is based on llvm, which is used by projects like dao to create bindings https://github.com/daokoder/dao-tools |
| 19:13:49 | Varriount | fowl, gradha, there's also an in-development extension for pypy, which uses llvm to generate run-time bindings for C++ libs |
| 19:14:16 | gradha | fowl: also questions like http://stackoverflow.com/questions/19011238/how-to-find-lines-of-objective-c-method-implementations-using-libclang suggest it is possible to use clang to parse C/C++ code, including #defines |
| 19:15:05 | gradha | fowl: that particular example doesn't speak about defines, but you can use the tags libclang tag there to find others which might |
| 19:15:30 | fowl | why is there so much confusion about clang |
| 19:15:53 | fowl | clang is a c compiler, it uses llvm as its backend |
| 19:16:19 | Araq | fowl: that's what you think. I heard clang can also cure cancer. |
| 19:16:46 | gradha | the other day my mother said libclang caught a thief at the supermarket trying to steal some groceries |
| 19:19:11 | gradha | fowl: what are you going to use llvm for? |
| 19:20:37 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 19:21:10 | fowl | gradha, exacerbating existing inequalities |
| 19:26:01 | Araq | tests/compile/tisop.nim ... gah, zahary___ your tests are killing me |
| 19:33:28 | * | PortablePuffin2 joined #nimrod |
| 19:33:45 | Varriount | Is the fact that os.removeDir skips files starting with '.' a bug, or a feature? |
| 19:34:01 | Varriount | And, does this happen on Linux, or only Windows? |
| 19:34:04 | PortablePuffin2 | EXetoC: sec |
| 19:35:50 | * | PortablePuffin quit (Ping timeout: 245 seconds) |
| 19:39:09 | Araq | no idea, check the source |
| 19:39:32 | gradha | Varriount: I'm not seeing any skipping of files |
| 19:39:57 | Varriount | Ok, probably icky Windows stuff then |
| 19:42:13 | gradha | Varriount: well, it looks like windows actually does skip such files |
| 19:42:22 | gradha | os.nim, like 344 |
| 19:42:32 | gradha | there's a skipFindData which checks for '.' being the first character |
| 19:42:51 | Varriount | Why? |
| 19:43:25 | Varriount | Is it for the '.' and '..' directories? |
| 19:43:32 | gradha | maybe Araq got annoyed at sharing folders with unix |
| 19:43:43 | gradha | there are other explicit tests for '.' and '..' |
| 19:44:36 | Araq | iirc the OS API lists the meta directories '.' and '..' as actual directories |
| 19:46:48 | gradha | maybe windows skipFindData should use that kind of check instead of only looking at the first char |
| 19:47:00 | gradha | the non windows part of the code does it separately |
| 19:47:42 | Araq | ah so that's the bug lol |
| 19:51:09 | joelmo | is anyone using nimrod.vim for code completion? I have not got the completion to work, looking at the source now, anyone know what s:CurrentNimrodFile() is supposed to do? |
| 19:52:39 | * | EXetoC2 joined #nimrod |
| 19:53:10 | EXetoC2 | PortablePuffin2 ok |
| 19:53:40 | * | EXetoC2 is now known as PortableEXetoC |
| 19:57:33 | * | shodan45 joined #nimrod |
| 20:03:16 | * | PortableEXetoC quit (Ping timeout: 246 seconds) |
| 20:06:51 | Varriount | Araq, are you working on a fix for the bug we just discussed? If not, I will. |
| 20:09:05 | * | PortablePuffin2 quit (Ping timeout: 240 seconds) |
| 20:11:48 | gradha | joelmo: I'm not sure vim autocompletion is finished, you could ask zahary___ about that |
| 20:20:36 | gradha | Araq: is presuming a ProcDef has a FormalParams node as the 4th child standard practice or are there constants to access the children? |
| 20:22:12 | TylerE_Meeting | Araq: I may take a pass at a new doc generator/modifying the existing one |
| 20:22:55 | Araq | Varriount: no, please do it |
| 20:23:16 | gradha | TylerE_Meeting: since you are at it, figure out a good way to hiperlink procs by name, now they are just numbered hrefs |
| 20:23:40 | Araq | TylerE_Meeting: feel free but in general I'm picky, so perhaps make it a "nimrod doc3" command in the compiler |
| 20:24:02 | TylerE_Meeting | Araq: Is there really a good reason to even make it part of the compiler? |
| 20:24:07 | TylerE_Meeting | I'm looking at docgen.nim |
| 20:24:20 | TylerE_Meeting | I see that it has lots of imports of compiler specific modules |
| 20:24:30 | Araq | well it uses the semantic pass of the compiler which is easily 30K lines |
| 20:24:55 | OrionPKM | how about a new doc command to generate JSON :) |
| 20:24:59 | OrionPKM | while ur at it TylerE_Meeting |
| 20:25:00 | OrionPKM | :P |
| 20:25:08 | Araq | but hey, I'm sure you can do without like the first version "nimrod doc" did :P |
| 20:25:32 | TylerE_Meeting | I really really don't want to write a parse :P |
| 20:26:07 | OrionPKM | it'd be cool if all the compiler did was generate JSON, and then we just had a separate tools/doc.nim to take the json and put it into html/whatever |
| 20:26:15 | gradha | TylerE_Meeting: how's the meeting going? any new plans for llvm? |
| 20:26:27 | TylerE_Meeting | nothing that exciting |
| 20:26:31 | TylerE_Meeting | nad I'm actually out now |
| 20:26:44 | TylerE_Meeting | but I'm leaving for how in like 30 minutes so didn't feel like identing to nickserv again |
| 20:28:39 | TylerE_Meeting | I have to say Araq I'm pretty impressed |
| 20:28:43 | TylerE_Meeting | poking around the compiler code |
| 20:28:55 | TylerE_Meeting | and I actually understand about 90% of what's it appears to be doing |
| 20:29:02 | TylerE_Meeting | which is about 80% more than I expected |
| 20:29:29 | joelmo | gradha: ok thank you, it seems to not be ready as of now, dom96 you make use of idetools in aporia, how is that working now? |
| 20:29:39 | Araq | you're obviously kidding. I use parameter names like c, n and t. |
| 20:29:49 | TylerE_Meeting | heh |
| 20:29:52 | Araq | nobody can understand that, it's voodoo |
| 20:30:00 | TylerE_Meeting | I meant just like how the commands are parsed and called |
| 20:30:22 | TylerE_Meeting | e.g. it took me less than about 2 minutes with grep to figure out where a "doc3" command would go |
| 20:30:28 | zielmicha | Araq: at least there are type declarations |
| 20:31:03 | Araq | TylerE_Meeting: ah so you know how to use grep. That's unfair. |
| 20:31:20 | gradha | zielmicha: how are your plans going on rewriting 99% of the compiler due to that quoting issue? |
| 20:31:36 | zielmicha | not bad |
| 20:31:39 | Araq | ah wb zielmicha |
| 20:31:48 | zielmicha | actually I'm planning to rewrite 99% of stdlib |
| 20:32:03 | gradha | cool |
| 20:32:06 | zielmicha | bad not everything at once |
| 20:32:33 | dom96 | joelmo: It doesn't use CAAS yet, it just executes nimrod idetools ... for each query. |
| 20:33:22 | Araq | zielmicha: what are your plans for quoteIfContainsWhite? |
| 20:33:37 | Araq | btw dom96 you were right |
| 20:33:43 | Araq | it broke code |
| 20:33:51 | zielmicha | deprecate and copy to osproc as quoteShell |
| 20:33:57 | dom96 | That's nice to hear heh |
| 20:34:01 | zielmicha | it didn't break code - it was broken from beginning |
| 20:34:11 | zielmicha | just in a different way |
| 20:34:19 | * | BitPuffin joined #nimrod |
| 20:34:22 | gradha | it needs more xml |
| 20:34:23 | Araq | that's your opinion |
| 20:34:27 | dom96 | it worked for some specific use cases though |
| 20:34:54 | zielmicha | you are right |
| 20:35:27 | zielmicha | but I don't like anyone being able to execute arbitrary code on my laptop, maybe you do |
| 20:36:27 | BitPuffin | EXetoC: I never told you to add COPYING.txt to the commit message, I said that you could add it to the source file and in that commit message you could add the thing about dedicating to public domain etc |
| 20:36:44 | dom96 | zielmicha: that again depends on your use case |
| 20:36:56 | BitPuffin | seems like you may have done the right thing anyways :D |
| 20:37:17 | EXetoC | BitPuffin: I might've read only half of the words as usual |
| 20:37:23 | BitPuffin | or let's see |
| 20:37:51 | BitPuffin | yeah seems good enough :) |
| 20:37:55 | BitPuffin | I'll merge! |
| 20:38:26 | Araq | zielmicha: when you allow osproc with user input, you're already quite screwed |
| 20:38:35 | BitPuffin | EXetoC: done :D thanks! |
| 20:38:53 | Araq | and we also have a taint mode and an effects system to fight such things |
| 20:38:59 | BitPuffin | EXetoC: hg wasn't that bad eh? :D |
| 20:39:15 | gradha | accepting user input is so last century, cool code these days magically generates the input the user needs |
| 20:39:50 | * | dymk quit (Ping timeout: 240 seconds) |
| 20:40:57 | * | dymk joined #nimrod |
| 20:44:01 | * | PortableEXetoC joined #nimrod |
| 20:45:04 | Araq | hi PortableEXetoC welcome |
| 20:45:18 | Araq | are you EXetoC's mum? |
| 20:46:13 | * | dom96 wonders if Araq is looking to meet someone's mum. |
| 20:46:41 | gradha | MILH = mothers I'd like to hack? |
| 20:47:00 | PortableEXetoC | Not rly |
| 20:47:01 | * | Araq thinks dom96 was absent for too long so he doesn't get the joke |
| 20:48:08 | dom96 | You asked the same thing to PortablePuffin right? |
| 20:48:28 | dom96 | Perhaps you don't get my joke :P |
| 20:48:41 | EXetoC | BitPuffin: seems like a bad idea to voice my opinion of it after two days |
| 20:48:42 | Araq | perhaps |
| 20:48:44 | BitPuffin | oh snappitididdely |
| 20:48:52 | BitPuffin | EXetoC: probably |
| 20:49:01 | BitPuffin | EXetoC: but you can give your first impressions! |
| 20:49:37 | BitPuffin | alrighty |
| 20:49:44 | BitPuffin | let's fix this fucking template error |
| 20:50:16 | EXetoC | procs pls |
| 20:50:37 | BitPuffin | but they are just shortcuts |
| 20:50:43 | BitPuffin | they don't need to be their own procs |
| 20:50:44 | Araq | dom96: explain your joke :p |
| 20:50:45 | BitPuffin | :( |
| 20:50:58 | BitPuffin | Araq: jokes should not be explained |
| 20:51:01 | dom96 | ^ |
| 20:51:18 | EXetoC | aren't all functions? what's the point? |
| 20:51:29 | Araq | well I'm a german so you need to teach me humor |
| 20:52:55 | BitPuffin | Araq: wanna hear a joke? |
| 20:53:23 | dom96 | btw isn't the honey badger a mascot for bitcoin? |
| 20:53:27 | EXetoC | BitPuffin: the basics are pretty much identical in hg, and then I had that commit message issue, and the proposed solutions seemed a little silly |
| 20:53:36 | EXetoC | maybe there's an appropriate extension that deals with this |
| 20:53:41 | gradha | dom96: bitcoin has a mascot? |
| 20:53:54 | Araq | dom96: that would be bad, but ours is a badger with a crown anyway |
| 20:54:03 | BitPuffin | EXetoC: I don't understand what the issue was o.O |
| 20:54:11 | Araq | BitPuffin: sure |
| 20:54:28 | BitPuffin | Araq: golang |
| 20:54:30 | BitPuffin | hahahahhaha :D |
| 20:54:32 | BitPuffin | kidding |
| 20:54:34 | BitPuffin | :P |
| 20:54:44 | EXetoC | BitPuffin: I had made my changeset public, and so I couldn't amend the commit (message) |
| 20:54:49 | gradha | dom96: http://bitcoinexaminer.org/is-alpaca-the-mascot-of-bitcoin/ |
| 20:54:56 | Araq | I'll laugh later |
| 20:55:07 | BitPuffin | Araq: when nimrod takes over? :D |
| 20:55:14 | dom96 | gradha: Araq: I don't think it's official, but it has something to do with this video: http://www.youtube.com/watch?v=4r7wHMg5Yjg |
| 20:55:37 | BitPuffin | EXetoC: hg commit --amend should work lol |
| 20:55:42 | BitPuffin | or what do yo umean |
| 20:55:44 | BitPuffin | ah |
| 20:55:50 | dom96 | Yeah, people are calling Bitcoin "the honey badger of money" |
| 20:55:52 | BitPuffin | you mean it didn't show up when you pushed? |
| 20:55:58 | BitPuffin | I'm pretty sure in git you need to push -f |
| 20:56:01 | BitPuffin | probably the same in hg |
| 20:56:03 | BitPuffin | or well |
| 20:56:03 | EXetoC | BitPuffin: hg simply disallowed it |
| 20:56:05 | BitPuffin | maybe not |
| 20:56:19 | BitPuffin | EXetoC: but how can that happen on a local repo |
| 20:57:01 | EXetoC | I don't think I was able to create a commit that contained only a message |
| 20:57:07 | EXetoC | I don't know |
| 20:57:31 | dom96 | This is cool: http://lightpack.tv/ |
| 20:57:53 | BitPuffin | EXetoC: hmm |
| 20:58:23 | BitPuffin | template selectUserIdWhere*(predicate: string{lit}, args: varargs[string]): expr = |
| 20:58:25 | BitPuffin | db.getRow(sql("select id from users where " & predicate), args) |
| 20:58:33 | BitPuffin | I can't fathom why that has to be discarded |
| 20:58:52 | BitPuffin | but sure I'll proc it |
| 20:58:59 | gradha | dom96: this is much better http://www.youtube.com/watch?v=gPmIDB8L-Fs I want one for xmas |
| 20:59:00 | BitPuffin | seems like a bug to me |
| 20:59:34 | EXetoC | stmt? actual type as return type? assign to result? |
| 21:00:31 | OrionPKM | heh, lucy lalas |
| 21:01:12 | dom96 | gradha: I want one but it needs to have a crown and it needs to quote Araq hah |
| 21:01:49 | gradha | dom96: I can smell a stinky kickstarter brewing, not that I'd give a fuck about that |
| 21:01:59 | BitPuffin | so EXetoC return type didn't work |
| 21:02:13 | BitPuffin | neither did result |
| 21:02:31 | dom96 | gradha: Did you hear that DjangoCon is happening on an island!? I want the same for NimCon. |
| 21:02:44 | BitPuffin | Error: expression 'result = getRow(db, sql"select 1 from ? where ? = ?", ["users", "id", id])' has no type (or is ambiguous) |
| 21:02:46 | * | zahary___ is now known as zahary_ |
| 21:02:52 | * | PortablePuffin joined #nimrod |
| 21:02:58 | BitPuffin | ahhh |
| 21:03:02 | gradha | DjangoCon? Is that some australian furry creature? |
| 21:03:04 | BitPuffin | maybe the base of it all needs to be the type :p |
| 21:03:36 | Araq | BitPuffin: templates have no 'result' |
| 21:03:54 | dom96 | oh what, last years one was in Poland! |
| 21:04:01 | BitPuffin | Araq: no I know |
| 21:04:15 | BitPuffin | I was trying it to try to get rid of the error |
| 21:04:20 | BitPuffin | but it did give me better information |
| 21:04:22 | dom96 | gradha: http://2014.djangocon.eu/ |
| 21:04:22 | BitPuffin | I think |
| 21:05:02 | gradha | man, these web type programmers sure like having parties, rather than actually doing something useufl |
| 21:05:30 | dom96 | oh yeah, if NimCon happens we need to spend 90% of the time writing code. |
| 21:05:44 | Araq | wait what? |
| 21:05:45 | gradha | only 10% for blackjack and hookers? |
| 21:06:01 | Araq | gradha said what everybody thought ;-) |
| 21:06:48 | NimBot | Araq/Nimrod master ce3eac7 Zahary Karadjov [+0 ±1 -0]: fix computed dynlib names; fixes #718 |
| 21:07:16 | dom96 | I guess that means NimCon will happen in LA lol |
| 21:07:22 | Araq | uh oh |
| 21:07:22 | gradha | dom96: I don't think the djangocon people coded anything for the whole gig |
| 21:07:48 | Araq | zahary_: you messed with dynlib names? :-/ |
| 21:08:12 | OrionPKM | Las Vegas |
| 21:08:58 | gradha | dom96: just look at that picture, both seem stoned, hiding their faces because the alcohol content is so high they are plugging their laptops into water |
| 21:09:06 | BitPuffin | https://gist.github.com/BitPuffin/55d18b9a5a31bb5f833b this one i don't get why line 6 has to be discarded |
| 21:09:08 | BitPuffin | I've reversed it |
| 21:09:16 | BitPuffin | so that the base thing is a proc |
| 21:09:19 | BitPuffin | and the shortcuts templates |
| 21:09:32 | dom96 | gradha: haha, nice observation. |
| 21:10:07 | * | PortableEXetoC2 joined #nimrod |
| 21:10:09 | * | PortableEXetoC quit (Read error: Connection reset by peer) |
| 21:10:38 | zielmicha | is there a way to convert iterator into seq? |
| 21:10:41 | zielmicha | in one line |
| 21:10:47 | Araq | BitPuffin: I don't know either, make a proper bug report |
| 21:10:54 | gradha | zielmicha: sequtils should have a toSeq |
| 21:10:59 | * | brihat joined #nimrod |
| 21:11:23 | OrionPKM | just do toSeq(iterator()), not iterator().toSeq() |
| 21:11:46 | zielmicha | ok, I tried the second variant |
| 21:12:05 | BitPuffin | Araq: yeah okay |
| 21:12:07 | BitPuffin | will do boss |
| 21:17:28 | * | PortablePuffin quit (Ping timeout: 246 seconds) |
| 21:21:18 | * | TylerE_Meeting quit (Quit: home) |
| 21:33:43 | BitPuffin | Araq: is it fine if I just copy paste the code I showed you? |
| 21:33:53 | BitPuffin | or do I have to write a nicer bug report |
| 21:34:22 | EXetoC | always a test case :p |
| 21:34:40 | BitPuffin | btw gotta check first that it's not in the latest compiler |
| 21:34:43 | Araq | BitPuffin: if I can't compile it, I can't fix it |
| 21:35:04 | BitPuffin | alright |
| 21:35:11 | BitPuffin | dayum brutha |
| 21:35:11 | EXetoC | nub:p |
| 21:35:26 | BitPuffin | EXetoC: well sometimes he tells me I don't have to write a testcase |
| 21:36:59 | EXetoC | no way |
| 21:38:31 | BitPuffin | uh |
| 21:38:33 | BitPuffin | dafuq |
| 21:38:38 | BitPuffin | test case succeeds |
| 21:38:41 | BitPuffin | ._. |
| 21:38:52 | EXetoC | yay |
| 21:39:08 | BitPuffin | no not yay because then I'm getting the most cryptic error in all history of nimrod |
| 21:41:43 | dom96 | BitPuffin: I think you should implement bcrypt in pure Nimrod |
| 21:42:38 | BitPuffin | dom96: hell no |
| 21:42:51 | BitPuffin | dom96: why would I even want that btw |
| 21:42:55 | BitPuffin | scrypt is better |
| 21:43:08 | dom96 | But then there is a dependency on libtarsnap :( |
| 21:43:28 | EXetoC | so what commits should have that public domain statement? I think you said only those that contains significant changes, which is ambiguous |
| 21:43:38 | EXetoC | and that's never done for other licenses |
| 21:43:51 | * | Amrykid quit (Excess Flood) |
| 21:43:52 | BitPuffin | dom96: well then why not just implement scrypt in pure nimrod |
| 21:43:58 | BitPuffin | but hell do I have that time :P |
| 21:44:02 | * | Amrykid joined #nimrod |
| 21:44:07 | BitPuffin | grow some balls, it's easy to get libtarsnap |
| 21:44:22 | BitPuffin | EXetoC: hmm well that's just to be careful |
| 21:44:26 | dom96 | BitPuffin: Well I just thought that there are more implementations of bcrypt available to copy from |
| 21:44:26 | BitPuffin | maybe I should add a waiver file |
| 21:44:45 | dom96 | BitPuffin: it doesn't look like it is |
| 21:45:04 | BitPuffin | EXetoC: but really I'd say at the last commit of a PR is fine |
| 21:45:15 | BitPuffin | dom96: it's extremely easy |
| 21:45:20 | BitPuffin | I can make it a oneliner even |
| 21:45:45 | BitPuffin | guess I'm gonna have to do it |
| 21:47:04 | BitPuffin | wget https://www.tarsnap.com/download/tarsnap-autoconf-1.0.35.tgz && tar -xvf tarsnap-autoconf-1.0.35.tgz && cd tarsnap-autoconf-1.0.35 && ./configure && ./make && sudo cp ./lib/libtarsnap.a /usr/local/lib && sudo ldconfig |
| 21:47:08 | BitPuffin | dom96: try that ^ |
| 21:47:09 | dom96 | I wonder why the arch package doesn't contain it. |
| 21:47:16 | BitPuffin | me too |
| 21:47:26 | BitPuffin | well probably because it statically links |
| 21:47:31 | BitPuffin | but still |
| 21:47:35 | BitPuffin | should be included imo |
| 21:47:37 | EXetoC | that's one big annoyance in some cases |
| 21:47:49 | BitPuffin | dom96: TRY IT |
| 21:47:53 | BitPuffin | I haven't tested it |
| 21:47:55 | * | dom96 dislikes dependencies |
| 21:48:03 | BitPuffin | dom96: yo mom dislikes dependencies |
| 21:48:14 | dom96 | I'll try it later |
| 21:48:21 | BitPuffin | no now |
| 21:48:25 | dom96 | no |
| 21:48:30 | BitPuffin | otherwise I won't add it to the repo |
| 21:48:47 | dom96 | haven't you already? |
| 21:48:55 | BitPuffin | I haven't added the oneliner no |
| 21:48:58 | BitPuffin | I just wrote it for you |
| 21:49:00 | BitPuffin | now |
| 21:49:10 | dom96 | oh the "one liner" |
| 21:49:11 | BitPuffin | but apparently that didn't mean anything to you! |
| 21:49:22 | BitPuffin | it fits on one line in my terminal |
| 21:50:39 | BitPuffin | and I don't even have full HD res |
| 21:50:48 | BitPuffin | http://www.pasteall.org/pic/show.php?id=63773 proof |
| 21:51:00 | BitPuffin | dom96: what do you say now dom diddely ninety six? |
| 21:51:08 | BitPuffin | WHO IS YOUR GOD |
| 21:52:14 | BitPuffin | ah I see an error |
| 21:52:24 | BitPuffin | wget https://www.tarsnap.com/download/tarsnap-autoconf-1.0.35.tgz && tar -xvf tarsnap-autoconf-1.0.35.tgz && cd tarsnap-autoconf-1.0.35 && ./configure && make && sudo cp ./lib/libtarsnap.a /usr/local/lib && sudo ldconfig |
| 21:52:44 | Araq | BitPuffin: nice background image |
| 21:52:55 | BitPuffin | Araq: thanks! |
| 21:53:10 | BitPuffin | it's HR Giger |
| 21:53:11 | Araq | but it's missing a predator |
| 21:54:19 | * | XAMPP joined #nimrod |
| 21:54:19 | * | XAMPP quit (Changing host) |
| 21:54:19 | * | XAMPP joined #nimrod |
| 21:57:00 | BitPuffin | dom96: https://bitbucket.org/BitPuffin/scrypt.nim happy now |
| 21:57:03 | BitPuffin | I did everything for you |
| 21:57:34 | BitPuffin | instead of working on what I really _should_ work on |
| 21:58:05 | BitPuffin | now I have to maintain that link aaaaaaaagh |
| 22:04:05 | BitPuffin | AHA! |
| 22:04:07 | BitPuffin | Test case fails! |
| 22:04:46 | NimBot | nimrod-code/babel master 1084b15 Grzegorz Adam Hankiewicz [+0 ±2 -0]: Makes search case insensitive. |
| 22:04:46 | NimBot | nimrod-code/babel master 2406776 Dominik Picheta [+0 ±2 -0]: Merge branch 'pr_case_insensitive_search' of https://github.com/gradha/babel into gradha-pr_case_insensitive_search... 3 more lines |
| 22:05:19 | EXetoC | BitPuffin: merge that important commit |
| 22:06:21 | BitPuffin | Araq: https://github.com/Araq/Nimrod/issues/729 |
| 22:06:52 | BitPuffin | now updated with compiler error |
| 22:06:58 | gradha | Araq: why do IdentDefs end in an empty node instead of the node containing the type of the parameter list? |
| 22:07:13 | Araq | BitPuffin: how is that a bug? |
| 22:07:43 | BitPuffin | Araq: how is it not? |
| 22:07:43 | Araq | gradha: sometimes ther can be a '= value' after the ': type' |
| 22:07:56 | BitPuffin | you were the one who said make a bug report |
| 22:08:09 | BitPuffin | oh wait |
| 22:08:10 | Araq | well you described it differently |
| 22:08:11 | BitPuffin | haha |
| 22:08:19 | gradha | Araq: ah, had forgotten that. Is there a convenience proc which "unrolls" the IdentDefs when the user specifies multiple parameters of the same type? |
| 22:08:20 | BitPuffin | well hm |
| 22:08:21 | BitPuffin | sec |
| 22:08:39 | BitPuffin | Araq: damn it |
| 22:08:41 | BitPuffin | close |
| 22:09:01 | BitPuffin | where am I calling it without saving gah |
| 22:09:20 | EXetoC | you did assign something to the value returned by the call before |
| 22:09:43 | EXetoC | but that might not matter |
| 22:09:57 | BitPuffin | it is only called in templates |
| 22:09:59 | BitPuffin | so wtf |
| 22:10:10 | BitPuffin | don't close yet |
| 22:12:17 | BitPuffin | honestly wtf |
| 22:12:26 | BitPuffin | there is nowhere it is called without being stored from what I can see |
| 22:12:54 | BitPuffin | https://gist.github.com/BitPuffin/eb87f1c8a4bc1e032420 |
| 22:12:57 | BitPuffin | can you guys see anything? |
| 22:13:25 | BitPuffin | obviously not with gh syntax highlighting |
| 22:13:42 | BitPuffin | it complains about line 31 |
| 22:13:56 | EXetoC | line 79? doesn't it usually complain if a comment precedes it? |
| 22:14:16 | EXetoC | I mean succeed |
| 22:14:33 | BitPuffin | oh come on |
| 22:14:51 | BitPuffin | oh it was that |
| 22:14:56 | BitPuffin | wt-fin-f |
| 22:14:58 | EXetoC | or follows, to be grammatically correct |
| 22:15:14 | EXetoC | BitPuffin: but the error was reported in the template? |
| 22:15:31 | EXetoC | hm yeah |
| 22:15:36 | Araq | it usually says "instantiation from here" |
| 22:16:56 | BitPuffin | fixed it all |
| 22:17:25 | BitPuffin | Araq: it didn't |
| 22:17:43 | BitPuffin | only dbhelpers.nim(31, 14) Error: value returned by statement has to be discarded |
| 22:18:05 | EXetoC | I think you can just edit that issue then, and add that information |
| 22:18:46 | EXetoC | since it is discarded there as well, at line 11 |
| 22:19:21 | EXetoC | I hope there's a way to add line numbers to code blocks |
| 22:19:42 | EXetoC | on github |
| 22:21:02 | BitPuffin | sec |
| 22:22:43 | BitPuffin | why the hell can't I even reproduce that lol |
| 22:23:50 | BitPuffin | https://gist.github.com/BitPuffin/7882082 |
| 22:23:53 | BitPuffin | no problem apparently |
| 22:24:30 | BitPuffin | EXetoC: tell me what's different |
| 22:24:33 | BitPuffin | I neeeeed youuu lol |
| 22:27:17 | EXetoC | I don't remember if the comment was in a template before, but it is now |
| 22:27:32 | EXetoC | but I don't know if that's significant |
| 22:30:36 | Araq | can anybody please have a look whether tests/compile/tmacro2.nim compiles? |
| 22:31:33 | gradha | it seems to do for me, outputting 42 and 77 among other stuff |
| 22:31:46 | Araq | hmm alright, too bad |
| 22:31:52 | Araq | crashes my vm |
| 22:32:06 | gradha | I'm on commit f05bad885a6c03c50e3b925ed7edfd9ae9fba8e8 if that's of any help |
| 22:32:29 | gradha | hmmm... or maybe not, can't remember if I recompiled after updating |
| 22:32:44 | Araq | no worries |
| 22:33:07 | Araq | remind me to never ever rewrite an entire subsystem of the compiler again |
| 22:33:33 | Araq | takes months to get all the edge cases to work |
| 22:33:58 | gradha | since you mention rewriting, I'm implementing macros to replace the importobjc pragma |
| 22:34:32 | Araq | that sounds like a bad idea |
| 22:34:51 | gradha | it can't be worse than a pragma nobody can't use |
| 22:35:00 | Araq | hey |
| 22:35:10 | Araq | it's useful, look at my examples! |
| 22:35:14 | EXetoC | can't or can? :p |
| 22:35:24 | gradha | ok, ok, it works for a subset of all objc methods |
| 22:35:30 | Araq | yep |
| 22:35:59 | Araq | I guess you need an importobjcClassMethod pragma :P |
| 22:36:21 | gradha | I was thinking of making a babel objcbridge module, because I'm finding there are different ways you could interact with objc classes |
| 22:36:29 | gradha | and for each you would like a different macro/way of importing |
| 22:36:55 | gradha | there's the case where you have an objc class you want to make visible from nimrod, and viceversa, a nimrod object you would like objc code to call |
| 22:37:10 | Araq | actually we need to generalize importobjc |
| 22:37:42 | Araq | nah |
| 22:37:58 | * | hoverbear quit (Ping timeout: 246 seconds) |
| 22:38:03 | Araq | objective C's syntax is too strange for format strings to describe it |
| 22:42:43 | gradha | I've tried to use high(PNimrodNode) but it says the argument for high is invalid, any ideas? |
| 22:42:56 | Araq | use len? |
| 22:43:21 | gradha | so it's broken? len works, been using that |
| 22:43:32 | Araq | no, it's simply not implemented |
| 22:43:50 | Araq | and overloading for 'high' used to be tricky |
| 22:44:02 | Araq | should work easily nowadays |
| 22:44:35 | gradha | wow, nimrod has documentation from the future |
| 22:45:25 | Araq | gah |
| 22:45:31 | BitPuffin | adding objective c to c2nim would be really cool |
| 22:45:42 | Araq | proc high exists for PNimrodNode ... |
| 22:45:48 | Araq | damn |
| 22:45:58 | gradha | Araq: that's why I was asking… |
| 22:46:04 | Araq | -.- |
| 22:46:08 | BitPuffin | Araq: what was the release date for the new version again? |
| 22:46:16 | Araq | BitPuffin: shut up |
| 22:46:43 | BitPuffin | Araq: actually it wasn't meant to rub it in your face I was legitimally wondering |
| 22:46:57 | gradha | BitPuffin: next hannukah |
| 22:47:18 | BitPuffin | gradha: next bratwurst holiday |
| 22:47:32 | gradha | yum |
| 22:47:44 | gradha | actually we should make an irc barbaque for the release day |
| 22:48:14 | BitPuffin | yeah totally |
| 22:48:22 | BitPuffin | we'll bbq and link pictures |
| 22:48:31 | BitPuffin | it will be cozy |
| 22:48:39 | Araq | gradha: make a bug report then please, though it's 1-line fix |
| 22:48:46 | gradha | I'll bring the alcohol, and drink it for all of you |
| 22:48:55 | Varriount | Is it possible to use conditionals in the 'do' parts of case statements? Like case 3; of 2 or 3: foo() ? |
| 22:49:31 | Araq | no case statements lack guards, unfortunately |
| 22:49:51 | Araq | I want that feature pretty badly though, so there is hope |
| 22:50:09 | Varriount | Araq, I was wondering if it could be done for the file deletion bug |
| 22:50:22 | BitPuffin | gradha: sounds like a bbq with uncle Grzegorz |
| 22:50:22 | Araq | for your example 'of 2, 3' exists |
| 22:50:55 | gradha | BitPuffin: I prefer Mr Alcohol Badger |
| 22:51:06 | Araq | BitPuffin: release date was 16th of december |
| 22:51:34 | Araq | but maybe we should try something different this time |
| 22:51:43 | gradha | awww... should I cancel the striptease party? |
| 22:52:05 | EXetoC | 24th? 31st? |
| 22:53:00 | BitPuffin | Araq: but then how will the programmers get their gifts on time? |
| 22:54:01 | Araq | well I guess I can always cut the number of planned features and release what we have |
| 22:54:15 | BitPuffin | focus on bug fixes imo |
| 22:54:19 | gradha | BitPuffin: gifts == bugs? |
| 22:54:24 | BitPuffin | gradha: probably |
| 22:54:55 | * | PortablePuffin joined #nimrod |
| 23:02:21 | * | zielmicha quit (Ping timeout: 252 seconds) |
| 23:05:10 | * | brson quit (Ping timeout: 240 seconds) |
| 23:05:11 | * | radsoc quit (Ping timeout: 250 seconds) |
| 23:05:48 | * | ics joined #nimrod |
| 23:07:55 | * | brson joined #nimrod |
| 23:19:52 | NimBot | nimrod-code/babel master 93a11fc Dominik Picheta [+0 ±2 -0]: Remote tag querying for search and list. |
| 23:50:05 | NimBot | Araq/Nimrod master b9bf351 Zahary Karadjov [+0 ±1 -0]: in successful compilations with verbosity:0, all output is suppressed (useful for combing with --run) |
| 23:50:25 | Araq | ping zahary_ |
| 23:54:31 | EXetoC | BitPuffin: have you testeded the example? |
| 23:55:19 | BitPuffin | EXetoC: not yet no |
| 23:55:25 | BitPuffin | EXetoC: trying to get a thing done first |
| 23:55:30 | BitPuffin | although it's getting near bedtime |
| 23:55:35 | BitPuffin | just gonna fix this one bug |
| 23:55:43 | EXetoC | but this is reaaaally important stuff man |
| 23:55:46 | EXetoC | ok it can wait |
| 23:56:28 | BitPuffin | EXetoC: well does it work for you? lol |
| 23:56:35 | BitPuffin | I assume you tested it before you PR'd |
| 23:57:23 | EXetoC | kinda |
| 23:58:14 | * | zahary joined #nimrod |
| 23:58:29 | Araq | ah zahary is here |
| 23:58:34 | PortableEXetoC2 | Lol |
| 23:58:52 | zahary | sorry for not being around, I'm on a very crappy 3G connection |
