| 00:09:42 | gradha | this is promising http://www.i-programmer.info/news/167-javascript/6734-asmjs-gets-faster.html |
| 00:09:55 | gradha | they added a float32 type and the performance went up |
| 00:10:12 | gradha | if they keep adding native types soon they will outperform compiled code |
| 00:14:39 | gradha | good night, honey badgers |
| 00:14:45 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 00:17:10 | * | brson joined #nimrod |
| 00:24:22 | NimBot | Araq/Nimrod vm2 1c6bd59 Michał Zieliński [+0 ±1 -0]: add quoteShell to osproc.nim |
| 00:24:22 | NimBot | Araq/Nimrod vm2 db0da97 Michał Zieliński [+0 ±1 -0]: Deprecate quoteIfContainsWhite in favor of osproc.quoteShell. |
| 00:24:22 | NimBot | Araq/Nimrod vm2 6895423 Michał Zieliński [+0 ±5 -0]: Use quoteShell in stdlib, where appropriate. |
| 00:24:22 | NimBot | Araq/Nimrod vm2 8f854bb Grzegorz Adam Hankiewicz [+0 ±1 -0]: Mentions static alternatives to quit(). |
| 00:24:22 | NimBot | 38 more commits. |
| 00:38:47 | * | brson quit (Ping timeout: 240 seconds) |
| 00:40:42 | * | brson joined #nimrod |
| 00:49:43 | * | boydgreenfield joined #nimrod |
| 01:13:08 | * | Varriount_ joined #nimrod |
| 01:14:55 | * | Varriount quit (Ping timeout: 245 seconds) |
| 01:29:11 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 01:33:48 | * | boydgreenfield joined #nimrod |
| 01:40:23 | * | brson quit (Read error: Operation timed out) |
| 01:42:52 | * | brson joined #nimrod |
| 02:03:58 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:20:27 | * | boydgreenfield joined #nimrod |
| 02:30:53 | boydgreenfield | Can anyone point me to a good example of the || iterator using proper/appropriate annotation? (Or relevant deeper docs, for some reason I'm only seeing: http://build.nimrod-lang.org/docs/system.html#482) |
| 02:30:57 | boydgreenfield | Thx! |
| 02:37:26 | * | brson quit (Quit: leaving) |
| 03:31:52 | * | yodi joined #nimrod |
| 03:36:45 | * | yodi left #nimrod (#nimrod) |
| 04:26:22 | * | xenagi quit (Quit: Leaving) |
| 05:14:42 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 05:55:26 | NimBot | Araq/Nimrod master f62f465 Satish BD [+0 ±8 -0]: Correct the spelling of the word 'implicitly' |
| 05:55:26 | NimBot | Araq/Nimrod master d4fe419 Simon Hafner [+0 ±8 -0]: Merge pull request #774 from brihat/master... 2 more lines |
| 06:00:36 | * | OrionPKM quit (Remote host closed the connection) |
| 06:09:37 | * | OrionPKM joined #nimrod |
| 07:29:24 | * | ics joined #nimrod |
| 07:49:10 | * | Sergio965 joined #nimrod |
| 07:56:14 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 07:57:33 | * | boydgreenfield joined #nimrod |
| 08:25:20 | * | ics quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 08:35:13 | * | ics joined #nimrod |
| 08:51:56 | * | Araq_ joined #nimrod |
| 08:56:11 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 08:56:29 | * | zielmicha joined #nimrod |
| 09:08:33 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 09:18:00 | * | aftershave quit (Quit: Textual IRC Client: www.textualapp.com) |
| 09:19:05 | * | aftershave joined #nimrod |
| 09:29:24 | * | zahary quit (Quit: Leaving.) |
| 09:32:35 | * | girvo joined #nimrod |
| 09:33:59 | girvo | Hi all |
| 09:34:55 | girvo | Just as a neat thing I came across -- an excellent editor for cross-platform Nimrod dev, is TextAdept, based on Scintilua (sic). I'm working on a language plugin for it to handle some more advanced stuff, and building AdeptSense (think Intellisense) for the standard libraries |
| 09:36:23 | Araq_ | hi girvo. cool. |
| 09:36:38 | Araq_ | you know about idetools, right? |
| 09:36:55 | girvo | Araq_ yep! |
| 09:37:18 | girvo | Araq_ thats' what i'm integrating. I've never used Lua before, so it's slow going, but its easier than I expected :) |
| 09:39:22 | Kooda | Hey, that thing looks awesome! http://zhehaomao.com/project/2013/12/20/vector.html |
| 09:42:11 | girvo | I'll be chucking it up on github (same name as here) |
| 09:42:33 | girvo | Kooda: Yeah Vector is neat. Check out ArrayFire for something really similar and a bit further along :) |
| 09:45:51 | Kooda | Looks nice, too bad it’s not open :Þ |
| 09:46:23 | Kooda | Is there an open implementation of OpenCL yet? |
| 10:02:17 | Araq_ | nimrod will soon support an OpenCL backend :P |
| 10:04:33 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 10:06:42 | * | psquid quit (Quit: work) |
| 10:07:27 | fowl | good morning |
| 10:15:41 | Kooda | Araq_: that would be awesome :3 |
| 10:18:19 | * | girvo joined #nimrod |
| 10:50:59 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 10:57:48 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 25.0.1/20131112160018]) |
| 11:26:10 | * | girvo joined #nimrod |
| 11:50:43 | fowl | parseopt is deprecated? o.o |
| 12:27:15 | * | BitPuffin joined #nimrod |
| 12:32:10 | * | girvo quit (Quit: My iMac has gone to sleep. ZZZzzz…) |
| 12:41:43 | * | zielmicha quit (Ping timeout: 260 seconds) |
| 12:45:00 | * | Sergio965 joined #nimrod |
| 12:45:49 | * | Sergio965 quit (Client Quit) |
| 12:48:59 | * | zielmicha joined #nimrod |
| 13:00:28 | zielmicha | fowl: use parseopt2 |
| 13:00:55 | zielmicha | it has same API, but slightly different behaviour, and it doesn't break on arguments containing spaces |
| 13:01:09 | fowl | is --foo 32 supported |
| 13:01:49 | * | Sergio965 joined #nimrod |
| 13:03:20 | * | Sergio965 quit (Client Quit) |
| 13:28:57 | * | Smaehtin joined #nimrod |
| 13:30:13 | Smaehtin | Hey everyone, I'm trying to embed a resource (.res) file into my program on Windows. Does anyone know how to do this? Thanks in advance. |
| 13:31:13 | * | darkf quit (Quit: Leaving) |
| 13:44:13 | * | zielmicha quit (Ping timeout: 246 seconds) |
| 13:45:54 | Smaehtin | My bad, I was looking for compiler options but stumbled across the {.link.} pragma which did the job. Nevermind, I'm out! :) |
| 13:45:59 | * | Smaehtin quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client) |
| 14:57:53 | * | fredmorcos joined #nimrod |
| 15:12:33 | dom96 | 'ello |
| 15:17:45 | * | boydgreenfield joined #nimrod |
| 15:18:35 | fowl | greetings dom |
| 15:18:40 | fowl | dom96, is '96 your birth year? |
| 15:18:49 | dom96 | no. |
| 15:18:53 | dom96 | Haven't you already asked me that? |
| 15:19:02 | fowl | no |
| 15:20:36 | dom96 | well then i'm surprised it took you this long to ask me it heh |
| 15:24:18 | * | fredmorcos quit (Quit: Leaving) |
| 15:34:57 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 15:36:00 | * | ddl_smurf joined #nimrod |
| 15:38:16 | * | ddl_smurf quit (Client Quit) |
| 15:39:50 | * | gradha joined #nimrod |
| 15:43:17 | * | Endy joined #nimrod |
| 15:48:29 | tylere | Why is is there no cast from char to string? |
| 15:48:40 | tylere | Surely a character is trivially convertible to a length-1 string |
| 15:48:45 | gradha | because a char is not a string, use $ |
| 15:49:00 | gradha | a cstring requires an additional null terminating character |
| 15:49:14 | gradha | a "real" string likely has other information, like length, to make other operations faster than cstring |
| 15:49:21 | gradha | so a single char doesn't cut it, sorry |
| 15:49:45 | tylere | I'm not saying it IS a string |
| 15:49:55 | tylere | but why is there no standard converter function? |
| 15:50:03 | gradha | it is called `$` |
| 15:50:18 | gradha | a cast is not a converter function, it's "presume this thing is this other thing" |
| 15:51:10 | tylere | or actually, perhaps more to the point, a built in converter from seq[char] to string |
| 15:51:41 | gradha | tylere: if you keep changing the specification, I won't ever answer |
| 15:51:52 | gradha | use strutils.join for your 2.0 spec |
| 15:52:07 | tylere | gradha: that's funny |
| 15:52:13 | tylere | that's what I *am* trying to use |
| 15:52:17 | dom96 | It's because type safety is important. |
| 15:52:19 | tylere | but strutils.join requires an array of strings |
| 15:52:22 | tylere | not an array of chars |
| 15:52:39 | gradha | ah, indeed, sorry about that |
| 15:53:28 | gradha | I think you need to map $ over the chars, then use join on the result |
| 15:53:28 | tylere | and that's what prompted this whole internal debate about how char should have a converter to string... |
| 15:53:41 | tylere | yea, that's what I'm doing |
| 15:53:53 | gradha | converters are dangerous |
| 15:54:03 | gradha | you end up converting stuff by accident |
| 15:54:11 | gradha | and then blame the language for not having types |
| 15:54:25 | gradha | but presumably you can write a converter for char->string |
| 15:54:55 | gradha | but why do you have seqs of chars anyway? it's like the wrong structure for most purposes |
| 15:56:39 | fowl | tylere, if you want this to work then just write the converter for it |
| 15:57:42 | gradha | maybe add a proc `$`(chars: seq[char]): string to unicode for convenience/parallelism? |
| 15:58:06 | tylere | gradha: working on a bigint library |
| 15:58:21 | tylere | this code is in the `$` for my bigint type |
| 15:58:58 | dom96 | if seq[char] is a string anyway then why are you using seq[char] in the first place? |
| 15:59:17 | gradha | maybe insertions and deletions are critical for bigint? |
| 15:59:23 | tylere | it's being built up one char at a time |
| 15:59:31 | gradha | tylere: strings are good for that |
| 15:59:33 | dom96 | strings are mutable. |
| 15:59:34 | tylere | the actual underlying datastructure is a seq[int8] |
| 16:00:18 | dom96 | You can perform the same actions on them as you can on a seq[char] |
| 16:00:38 | tylere | ahh |
| 16:00:50 | tylere | looks like I might have been bitten by a pythonism here then |
| 16:01:03 | tylere | in python repeatedly appending to a string is...bad |
| 16:01:07 | dom96 | seems so |
| 16:02:08 | * | MFlamer joined #nimrod |
| 16:02:24 | gradha | tylere: remember about newStringOfCap, you can create a good buffer and modify without allocations if you expect certain sizes |
| 16:02:47 | tylere | ahh, cool |
| 16:05:05 | tylere | I mean, if I were doing this for real I'd wrap gnump or something |
| 16:05:07 | tylere | but I'm not |
| 16:05:16 | tylere | so this is just sort of a toy implementation |
| 16:05:48 | dom96 | I'm sure Araq will help you optimise it. |
| 16:06:06 | tylere | the most trivial optimization would be to use packed BCD instead of int8s |
| 16:06:12 | tylere | that way I could store 2 digits per byte |
| 16:06:20 | tylere | that'd be slower to actually operate on though |
| 16:10:40 | tylere | but really my plan is to implement everything naively...and then profile to figure out where the actual hotspots are |
| 16:21:01 | tylere | Is there any magic proc to implement subscript notation on a user type? |
| 16:22:59 | gradha | I don't understand half of https://en.wikipedia.org/wiki/Double_subscript_notation but maybe you could use a range[T] |
| 16:23:52 | fowl | tylere, `[]` |
| 16:24:07 | tylere | fowl: ahh, yea, I probably should have tried the obvious |
| 16:37:53 | * | ddl_smurf joined #nimrod |
| 16:45:01 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 17:05:21 | Araq | tylere: "implement first, then profile" is unlikely to work for a bignum library, but building a prototype is a good idea to understand the problem domain |
| 17:05:44 | tylere | Araq: Yea, probably ;) |
| 17:05:55 | tylere | like I said earlier, if I was doing this for real I'd just wrap a c library |
| 17:06:06 | Araq | nah |
| 17:06:09 | tylere | but basically my goal is something just good enough to be useful for euler problems |
| 17:06:12 | tylere | which sets the bar fairly low |
| 17:06:22 | Araq | native nimrod is the way to go in the long run |
| 17:06:40 | Araq | this way you can properly use Nimrod's GC |
| 17:07:09 | Araq | wrapping C means either destructors (not ideal) or finalizers (not ideal either) for bignums |
| 17:47:15 | * | DAddYE joined #nimrod |
| 17:47:24 | Araq | DAddYE! |
| 17:47:34 | DAddYE | hello Araq!!!!!!!!!!!!!! |
| 17:49:08 | Araq | I'm still waiting for your PRs :P |
| 17:49:33 | Araq | but no worries, might start with the consistency stuff tonight |
| 17:50:32 | DAddYE | Araq: awesome!!!!!!! |
| 17:53:47 | Araq | so ... how do we do this release? |
| 17:53:57 | Araq | people requested a beta this time |
| 17:55:54 | dom96 | tell people to test head |
| 17:56:39 | Araq | well I'll run the tester over every babel package |
| 17:56:49 | Araq | thing is, time is running short for a beta |
| 17:57:02 | Araq | I only have time for a release :P |
| 17:57:48 | dom96 | noooo |
| 17:58:27 | fowl | Araq, should fileExists/dirExists be inline or rtl, extern like fileExists/dirExists |
| 18:01:28 | gradha | release, then have a new year patchfix version, twice the reddits |
| 18:01:37 | gradha | but more importantly, twice the drama |
| 18:18:51 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 18:34:45 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 18:51:39 | Araq | fowl: inline I guess |
| 18:54:17 | Araq | http://www.rawstory.com/rs/2013/12/22/fired-public-relations-executive-justine-sacco-apologizes-for-racist-aids-tweet/ has that hit reddit already? |
| 18:57:25 | dom96 | I've never even heard of her |
| 18:58:26 | gradha | damn, I guess she won't be able to announce the new nimrod release then |
| 18:58:28 | * | boydgreenfield joined #nimrod |
| 18:58:44 | dom96 | This is why I tell Araq to create a twitter account. |
| 18:58:53 | dom96 | This kind of outrage gives popularity. |
| 18:58:53 | fowl | for drama? |
| 19:06:42 | Araq | no, Araq is supposed to be the friendly guy who happened to invent a PL |
| 19:06:55 | Araq | for drama we need Atrollaq |
| 19:07:09 | * | Araq is now known as Atrollaq |
| 19:07:23 | gradha | Atrollaq: so did you fix the stderr/stdout problem? |
| 19:07:58 | Atrollaq | gradha: do you mean the redirections you like to give to osproc? |
| 19:08:16 | gradha | Atrollaq: unix, in general |
| 19:09:13 | Atrollaq | ah I see |
| 19:09:30 | Atrollaq | well I'm using Haiku now |
| 19:09:42 | gradha | does Haiku webscale? |
| 19:09:52 | Atrollaq | ported Wine myself, can run every software I care about |
| 19:10:39 | dom96 | Haiku sucks. RISC OS is where it's at. |
| 19:11:36 | dom96 | Because it was developed by Englishmen. |
| 19:12:36 | NimBot | Araq/Nimrod vm2 10b213d Araq [+0 ±3 -0]: tcnstseq works again |
| 19:12:36 | NimBot | Araq/Nimrod vm2 6d4acfe Araq [+0 ±6 -0]: vm: FFI improvements |
| 19:12:48 | Atrollaq | so gradha here is the thing |
| 19:13:32 | Atrollaq | please check out vm2, and run tools/detect/detect.nim |
| 19:13:35 | gradha | the thing |
| 19:14:03 | Atrollaq | and paste the generated macosx_$cpu_consts.nim here please |
| 19:14:14 | Atrollaq | Varriount_: same for a 64bit windows build |
| 19:14:29 | Atrollaq | dom96: same for linux please |
| 19:14:42 | dom96 | RISC OS is more important. |
| 19:14:55 | Atrollaq | so run it on risc os too then |
| 19:15:19 | dom96 | Too much effort. |
| 19:22:54 | * | dom96_and joined #nimrod |
| 19:26:42 | * | Atrollaq is waiting for results ... |
| 19:26:57 | dom96_and | Well. |
| 19:27:05 | gradha | wasn't there a special test which always failed? |
| 19:27:15 | dom96_and | I have no access to my computer now. |
| 19:27:29 | * | Atrollaq is now known as Araq |
| 19:28:10 | * | shodan45 joined #nimrod |
| 19:29:51 | gradha | keineschweine on mac: undeclared identifier 'MAP_ANONYMOUS' |
| 19:30:23 | gradha | aporia fails too |
| 19:30:54 | Araq | yeah well I thought I told you what to run ... |
| 19:31:45 | gradha | that one succeds and fails at the same time, a quantum computation breakthrough? |
| 19:33:18 | Araq | do you have macos_$cpu_consts.nim file? |
| 19:34:08 | gradha | yes, I'm pasting the build too if it helps http://pastebin.com/VbPeZV46 |
| 19:35:03 | gradha | macosx_amd64_const.nim http://pastebin.com/mnf3Z04K |
| 19:45:45 | Araq | gradha: can you somehow do the same for macosx_x86 ? |
| 19:46:00 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 19:47:07 | gradha | compile with --cpu:i386 ? |
| 19:47:59 | Araq | that's not enough you need a 32bit clang/gcc |
| 19:48:37 | gradha | hmmm |
| 19:51:15 | gradha | do you see anything in http://stackoverflow.com/questions/13642536/how-can-i-compile-a-library-in-32bit-on-a-64bit-mac-machine-mountain-lion useful to get what you want? |
| 19:53:41 | Araq | you need to change detect.nim so that it passes -m32 to gcc |
| 19:54:05 | Araq | but it's not too important, I can't imagine the values will change for 32 bit build |
| 19:54:14 | Araq | uh oh ... famous last words ... |
| 19:56:49 | gradha | so only -m32 for the const embedded in detect.nim? |
| 19:58:08 | Araq | I think so, yes |
| 19:59:15 | dom96_and | Araq: what about the nimbuild corruption? |
| 19:59:29 | dom96_and | Will that not be fixed for the release? |
| 20:00:06 | tylere | 32bit intel osx is a pretty narrow target anyway |
| 20:00:55 | gradha | here's macosx with -m32 http://pastebin.com/VAA2aF8a |
| 20:01:13 | Araq | dom96_and: it's no showstopper for the release anymore. otherwise we'll never release. Also I'm quite sure it's some channel bug, not a GC bug. |
| 20:01:31 | gradha | here's the diff between versions http://pastebin.com/8Vka6utZ |
| 20:03:01 | Araq | now that's handy, thanks |
| 20:06:19 | fowl | lets not release til after valentines day |
| 20:06:25 | fowl | there are still many bugs |
| 20:08:22 | gradha | it's hard to capture new developers without releases, plus, isn't this software below 1.0? |
| 20:10:03 | Araq | well vm2 is ready, so that's a reason for a release |
| 20:11:03 | OrionPKM | it's ready? yay |
| 20:11:38 | Araq | well libFFI can run stdout.write "muhaha" on windows |
| 20:11:53 | Araq | and it never could before :P |
| 20:11:59 | OrionPKM | that is the true test |
| 20:12:22 | Araq | who's on linux now? |
| 20:12:31 | Araq | who wants to run detect.nim? |
| 20:13:23 | OrionPKM | Idk what changed, but my irc app seems to be eating up less ram. slightly less |
| 20:14:02 | OrionPKM | hovers around 9mb instead of 2mb with that times.nim issue |
| 20:14:14 | OrionPKM | instead of 20* |
| 20:14:34 | * | Mat3 joined #nimrod |
| 20:14:54 | Mat3 | hi all |
| 20:18:19 | Araq | hi Mat3 |
| 20:18:33 | Mat3 | hi Araq |
| 20:18:52 | Mat3 | how you doing before christmas ? |
| 20:20:17 | OrionPKM | araq? Christmas? humbug |
| 20:23:40 | Mat3 | well, independent from personality, it's a set of offical free-days here |
| 20:25:50 | tylere | it's alive! |
| 20:25:51 | tylere | https://github.com/tylereaves/euler/blob/master/bigint.nim |
| 20:26:58 | tylere | (for very generous definitions of alive) |
| 20:27:05 | tylere | but adding of positive integers works |
| 20:28:30 | * | Endy quit (Ping timeout: 241 seconds) |
| 20:30:44 | Araq | Mat3: I decided to not sleep anymore to get 0.9.4 out |
| 20:31:13 | Mat3 | ehm, ok... how's the progress ? |
| 20:31:28 | OrionPKM | u can sleep when ur dead |
| 20:34:13 | Araq | progress is ... slow, but steady |
| 20:40:43 | OrionPKM | with the new VM can nim files be run without compilation? |
| 20:41:06 | OrionPKM | similar to python file.py |
| 20:41:13 | Araq | yeah but don't expect miracles |
| 20:41:41 | OrionPKM | cool.. I only really want it during development |
| 20:41:49 | fowl | but does it run entitty |
| 20:41:53 | fowl | thats the real question |
| 20:42:04 | fowl | ill test it in a minute |
| 20:42:29 | OrionPKM | have u tried a nakefile? |
| 20:42:33 | Araq | run detect.nim please |
| 20:43:06 | Araq | nakefiles love os and osproc, the vm doesn't ... |
| 20:43:14 | OrionPKM | :/ |
| 20:44:04 | Mat3 | Araq: I think to be finish my work somewhere february and will upload a flash installer for the duinomite-mini board first |
| 20:44:33 | fowl | i dont think nake uses osproc |
| 20:46:55 | Araq | OrionPKM: you could try to re-activate the tiny C backend ... supporting the FFI at compile time is hard and will always be limited, unfortunately |
| 20:50:16 | Araq | unless Mat3 gives us a JIT ... ;-) |
| 20:54:11 | Mat3 | as written, somewhere february I think (one will need a translator for .nim files, because the JIT environment execute a tensed Nimrod dialect) |
| 20:56:43 | Araq | ah so thats what you meant |
| 20:58:08 | shodan45 | wait, a new release is pending? |
| 20:58:25 | shodan45 | I need to lurk more in #nimrod, I guess |
| 20:59:38 | Araq | well "pending" is relative ... |
| 21:03:21 | shodan45 | no offense to those involved, but what's the point of a nimrod VM? |
| 21:03:36 | Mat3 | Araq: On the pro side, it will run on a lot of embedded boards natively inclusive arduino class ones (as firmware alternative) - in direct concurrency to projects like eLua |
| 21:05:55 | Mat3 | shodan45: interactive development and realtime error handling on embedded boards (for example important for mission-critical systems) |
| 21:06:46 | Mat3 | navigation systems, large offset-printer stacks etc. |
| 21:07:23 | Mat3 | some medicinical systems - these kind of stuff |
| 21:07:38 | shodan45 | Mat3: hmm how do people manage error handling on embedded when using C/C++? |
| 21:09:34 | shodan45 | in my very limited experience with embedded stuff, I've used a serial connection for error handling/debugging |
| 21:10:13 | Mat3 | there don't, because I know of no C based interactive environment. Typical C programmers cross compile and get paid for endless service workarounds |
| 21:10:46 | Araq | actually I disagree with Mat3 here :-) |
| 21:10:58 | shodan45 | Mat3: so you're saying that you want to put devs out of work? :P |
| 21:11:06 | Araq | IMO embedded stuff should be proven correct and never touched again |
| 21:13:33 | Araq | Mat3: so please elaborate. How will this nimrod->subset->run pipeline work in practice? |
| 21:15:03 | Mat3 | you can't verify correctness of software in applications in work-situations which are not clearly evaluable, Araq |
| 21:15:49 | Mat3 | beside errors as result from human nature |
| 21:16:05 | Araq | well a NullPointerException for instance is never the desired behaviour |
| 21:16:26 | Araq | so proving the absense of these already is useful |
| 21:16:41 | Araq | same for index out of bounds, etc. |
| 21:17:03 | shodan45 | this reminds me of a segfault I found in PHP a few years ago |
| 21:17:25 | Araq | there are lots of bugs that don't require a specification |
| 21:18:18 | shodan45 | the "PHP devs" (I use the term loosely) actually told me it it was expected behavior |
| 21:18:32 | Mat3 | there are chances for bugs, which relate to implicite shortcomings |
| 21:19:19 | Araq | admittedly crashing might be preferable over silently producing the wrong output, though |
| 21:19:50 | Araq | so it's a hard question, I wonder what studies exist about this |
| 21:20:32 | Mat3 | the software for a press stack for example need to be adjusted for each stack because of nuancable different speed for each paper-roll |
| 21:21:44 | Mat3 | it is expensive to patch the firmware for each delivered product. Better is a flexible firmware which can be patched on the fly without reflashing |
| 21:23:03 | * | tylere quit (Ping timeout: 240 seconds) |
| 21:24:56 | Mat3 | it can be also critcal for personal health to sell a software which can't be adjusted at realtime for installed systems (one broken roll will easily kill people in there way) |
| 21:25:55 | Araq | well you can't expect the doctor to patch the firmware in realtime ... :P |
| 21:26:07 | * | Demos_ joined #nimrod |
| 21:26:50 | Mat3 | for your example not, but the firmware can be programmed to patch itself this way |
| 21:27:08 | Mat3 | <- self healing systems |
| 21:27:32 | Araq | sounds horrible to me but I trust you ;-) |
| 21:28:06 | Araq | ("Oh no, firmware updated and got a new critical bug. Too bad, people dead") |
| 21:28:24 | Mat3 | all this stuff is standard for satellite systems (as other example). Personally I know of some medicinical systems which work that way |
| 21:29:24 | Mat3 | or think of the many self-adjusting (and externally adjustable) ABS systems in cars |
| 21:29:59 | Araq | quite terrifying. So people patch satellites' firmwire in realtime before they crash in orbit? |
| 21:30:06 | Araq | *firmware |
| 21:30:12 | Mat3 | yes |
| 21:30:20 | Araq | well better than letting it crash I guess |
| 21:30:54 | Mat3 | <- realtime in the sense of fastest communication way |
| 21:35:23 | Mat3 | get some sleep, ciao |
| 21:35:34 | Araq | wait |
| 21:35:38 | * | Mat3 quit (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) |
| 21:35:48 | Araq | oh well |
| 21:43:58 | Varriount_ | Araq, you pinged me? |
| 21:44:42 | Araq | yes. please read the history |
| 21:44:46 | * | Varriount_ is now known as Varriount |
| 21:44:57 | Varriount | Araq, I read it, but paste what? |
| 21:45:08 | Varriount | Oh, ok |
| 21:45:32 | Varriount | By the way, I am yet again superbly impressed with German artistry and creativity |
| 21:45:51 | Varriount | Araq, -> http://rabbit.daedalic.de/en/ |
| 21:46:09 | Varriount | I played that adventure game all the way through. I was crying at the end. |
| 21:46:12 | Demos_ | is that written in nimrod? |
| 21:46:42 | Varriount | No. But it has an *amazing* story |
| 21:47:21 | Varriount | For me, adventure games (such as monkey island, etc) are the perfect mixture of my two favorite things: stories, and puzzles. |
| 21:47:42 | Demos_ | myst and its sequals are probably my favorite games ever |
| 21:47:48 | Demos_ | the current state of adventure games is pretty sad |
| 21:48:28 | Varriount | It's a pity that I grew up at the point in time where the genre of adventure games was dying. |
| 21:48:58 | Varriount | Demos_, these days, it's all shooters and tactical simulations. |
| 21:49:12 | Varriount | Or storyless escape-the-room games. |
| 21:49:45 | Demos_ | well cyan worlds is working on a new game, and there are things like Machinarium and Kairo |
| 21:50:09 | Varriount | Yeah. |
| 21:52:22 | Varriount | Araq, any certain way on how I'm supposed to compile and/or run detect.nim |
| 21:54:03 | Araq | nimrod should say you're on win64 and so should be your gcc/clang |
| 21:55:46 | Varriount | Araq, I get this -> https://gist.github.com/Varriount/8105536 |
| 21:56:28 | Araq | well it's successful |
| 21:56:48 | Araq | detect detects which header files your compiler knows about |
| 21:57:01 | Araq | so yeah, errors are expected and don't harm |
| 21:58:20 | Varriount | Araq, so... is this for anything in particular? |
| 21:58:51 | Araq | it's for native backends/vm2 |
| 21:59:04 | Demos_ | oh, I wrote a minElement and a count function for algorithm.nim, not sure how idomatic they are though |
| 21:59:25 | Varriount | Araq, should I have rebuilt nimrod with the vm2 branch? |
| 21:59:31 | * | BitPuffin joined #nimrod |
| 21:59:55 | Araq | Demos_: make a PR and you'll get a code review for free |
| 22:00:16 | Araq | Varriount: yeah ... |
| 22:00:48 | Araq | btw does that fix the macro problem you were having? |
| 22:01:15 | Varriount | Araq, yes. |
| 22:01:42 | Araq | cool, I'll merge then |
| 22:03:30 | Demos_ | allright, I made a pr |
| 22:05:47 | Varriount | Araq, I updated the gist with the output from detect.nim built with a nimrod built from the vm2 branch |
| 22:06:38 | Varriount | Araq, the only difference between the two is that in the vm2 version, the lines aren't cut off |
| 22:06:53 | shodan45 | is there a list of projects that use nimrod? (aside from libraries, etc) |
| 22:07:37 | Araq | shodan45: I don't think so :-/ but it's not widely used |
| 22:07:57 | Araq | Varriount: windows_amd64_consts.nim should be somewhere |
| 22:08:17 | Varriount | Want me to run and compile that? |
| 22:08:25 | Araq | no pastebin that |
| 22:08:34 | Demos_ | no sane person would use nimrod for a real project at this point, it is only version 0.9.4 |
| 22:08:53 | Araq | no, it's at version 0.9.2 |
| 22:09:03 | Demos_ | sorry, been on master for too long |
| 22:09:05 | Varriount | Demos_, I use it for scrupts. |
| 22:09:09 | Varriount | *scripts |
| 22:10:34 | Varriount | Araq, ->https://gist.github.com/Varriount/8105714 |
| 22:10:36 | gradha | shodan45: I think you can coerce github into telling you about nimrod repos |
| 22:11:50 | * | BitPuffin quit (Ping timeout: 240 seconds) |
| 22:12:25 | * | BitPuffin joined #nimrod |
| 22:12:43 | Araq | Varriount: thanks |
| 22:18:56 | Varriount | Hm, what would be a good procedure name for getting the kind of filesystem object pointed to by a path? |
| 22:19:26 | Araq | 'things_you_should_never_ask_part_8' |
| 22:20:04 | Varriount | *gasp* using underscores!? |
| 22:20:55 | Araq | that was part 7 ;-) |
| 22:21:53 | Varriount | Well, unless you say otherwise, it's going to be called getTargetKind |
| 22:22:28 | Araq | filesystemTargetKind or fsTargetKind sound better |
| 22:22:28 | Varriount | getPathKind is confusing, and might possibly be better used for a future proc that guesses what OS a path comes from. |
| 22:23:10 | Varriount | Hm. Choices choices... |
| 22:23:52 | Varriount | fsPathKind I think, otherwise the procedure get's too long. |
| 22:23:59 | Varriount | *procedure name |
| 22:24:20 | Araq | type FileSystem = enum fat16, fat32, other ? |
| 22:24:26 | Varriount | Er, no |
| 22:25:03 | Araq | type FileSystem = enum dos, unix, other ? |
| 22:25:14 | Varriount | fsTargetKind("c/python/python.exe") -> pcFile |
| 22:25:24 | Araq | gah |
| 22:25:31 | Varriount | Gah? |
| 22:25:32 | Araq | that's some shitty name then |
| 22:25:55 | Varriount | Well, I need a better one. |
| 22:26:13 | Araq | classifyPath("boo") -> pcFile |
| 22:26:37 | Varriount | Ooh, that's much better. Once again I concede to your brilliance. |
| 22:27:07 | Araq | thanks. I'm not sure I like though. :-) |
| 22:27:14 | Araq | *like it |
| 22:27:52 | Araq | we need enum inheritance so that "none" is a valid value for that |
| 22:27:57 | Varriount | Araq, just so you know my reasoning, such a procedure is more efficient that using a series of existsXXX procedures to get the thing pointed to by a path. |
| 22:28:17 | Araq | I know your reasoning |
| 22:28:41 | Varriount | Woah, I never knew you were a mind reader! |
| 22:28:48 | Varriount | :3 |
| 22:29:20 | Araq | ask DAddYE. I debugged his code without seeing anything of it :P |
| 22:32:20 | Araq | TPathComponent doesn't have pcNone and we can't add it as that would break code |
| 22:32:39 | Varriount | Araq, acutally, we can, as long as we add it to the end. |
| 22:32:49 | Araq | lol no |
| 22:32:55 | Araq | what makes you think so? |
| 22:33:00 | Araq | case comp |
| 22:33:13 | Varriount | Oh. darn. |
| 22:33:15 | Araq | of pcfile..pcLinkToDir: compiles() |
| 22:33:26 | Araq | <-- doesn't compile anymore then |
| 22:33:32 | Araq | however |
| 22:33:34 | Varriount | Araq, well, right now, I just throw an error. |
| 22:33:44 | Araq | hmm ok I guess |
| 22:33:48 | Araq | the alternative is: |
| 22:33:57 | Araq | type TNewPath = enum ... |
| 22:34:21 | Araq | type TPathComponent = range[pcFile..pcLinkToDir] |
| 22:34:49 | Varriount | Araq, but at some point in time, there have to be breaking changes of one sort or another. |
| 22:35:09 | Varriount | Otherwise you end up with *tons* of compatibility code |
| 22:35:27 | Araq | yes |
| 22:35:35 | Araq | we have a deprecation path for that |
| 22:35:44 | Araq | which we try to follow |
| 22:35:50 | Varriount | Is it written down anywhere? |
| 22:37:39 | Araq | no, but it's simple: |
| 22:38:01 | Araq | version N: add .deprecated. and document it in news.txt |
| 22:38:15 | Araq | version N+1 or N+X: remove the feature and document it in news.txt |
| 22:38:47 | Araq | for language changes the compiler doesn't produce errors but warnings about a soon to be removed feature |
| 22:39:02 | Araq | and then later the warning becomes an error |
| 22:39:21 | Araq | sometimes this doesn't work, but that is rare |
| 22:39:52 | gradha | good night, honey badgers |
| 22:39:57 | * | gradha quit (Quit: bbl, need to watch http://www.youtube.com/watch?v=dEf4PJZXBxA again) |
| 22:40:43 | dom96_and | Demos_: depends what you mean by real but you could argue that many of my nimrod projects are "real". |
| 22:41:08 | Demos_ | well OK jester is real, but like big money makin projects |
| 22:42:02 | Demos_ | nimrod is not really a stable language at this point, so most of the code written in it is going to be library and compiler code. I meant projects with substantial money behind them |
| 22:42:15 | Varriount | So Araq, how would one depracate and update TPathComponent |
| 22:42:20 | Araq | Demos_: at least ventor3000 uses it in a commercial setting :P |
| 22:42:28 | Araq | Varriount: already showed you the solution |
| 22:43:32 | Araq | create a new enum with all the values + pcNone and make TPathComponent a range of that, no need to deprecate anything |
| 22:44:05 | Araq | this might trigger some bugs related to 'range' in the compiler but that's a good thing ;-) |
| 22:44:36 | dom96_and | The language spec is quite stable. The compiler could be a bit more stable, but if you've got a company which uses nimrod all you have to do is hire Araq and you've got an expert on your side fixing bugs for you :p |
| 22:47:59 | Araq | speaking of which |
| 22:48:13 | Araq | I'm gonna deprecate the "nil" *statement* |
| 22:48:24 | OrionPKM | I wouldn't use jester in a prod system |
| 22:48:28 | OrionPKM | not yet |
| 22:48:30 | Araq | an empty 'discard' is the better solution |
| 22:48:34 | fowl | noooo |
| 22:48:37 | fowl | nil is less characters |
| 22:48:40 | * | Demos_ quit (Ping timeout: 272 seconds) |
| 22:48:51 | Araq | nil is ambiguous, fowl |
| 22:49:01 | Araq | especially with the expr/stmt unification |
| 22:49:15 | fowl | new keyword: nvm |
| 22:49:19 | fowl | :p |
| 22:49:37 | Araq | well actually the compiler can handle the ambiguity |
| 22:49:44 | Araq | but it sucks for reading imho |
| 22:49:54 | Araq | also it would simply the compiler :P |
| 22:50:37 | Varriount | ^ Which is in desperate need of good simplification |
| 22:51:05 | Varriount | So Araq, how do you feel about TPathClassifications? |
| 22:51:36 | Araq | I still think you end up with 1 additional kernel call in many cases |
| 22:52:03 | Araq | which is bad for the non-existing language comparing os module benchmarks |
| 22:52:25 | dom96_and | OrionPKM: works well for nimforum |
| 22:52:41 | Varriount | What, for 'classifyPath' versus 'if existsFile.. else if existsDir' ? |
| 22:52:46 | Varriount | Araq, ^ |
| 22:53:03 | Araq | Varriount: where do we do that though? |
| 22:53:17 | OrionPKM | dom96_and wouldnt call that highly demanding by any means |
| 22:54:05 | OrionPKM | I'm more concerned about the foundation underneath the house than the house itself WRT jester |
| 22:54:17 | dom96_and | OrionPKM: according to benchmarks jester is better than most frameworks out there. |
| 22:54:41 | OrionPKM | it could be a lot faster if httpserver was faster |
| 22:54:42 | Varriount | Araq, walkDir, walkDirRec, my new makeSymlink (when on windows) |
| 22:54:58 | OrionPKM | dom96_and Java beats it last I checked ;0 |
| 22:55:00 | dom96_and | Of course. The point is that it's secondly fast enough. |
| 22:55:08 | * | psquid joined #nimrod |
| 22:55:19 | dom96_and | *definitely |
| 22:55:29 | Araq | Varriount: so read the impl of walkDir et.al. |
| 22:55:47 | Araq | they don't call existsDir/existsFile |
| 22:56:18 | Varriount | Araq, where do you think I got most of the implementation for classifyPath from? |
| 22:56:28 | dom96_and | If you have a website that gets as many visits as facebook then you will have enough money to optimise jester anyway. |
| 22:56:52 | Varriount | Araq, in any case, it also provides *users* (that is other programmers) a way to get the type of a single path |
| 22:57:06 | OrionPKM | :P |
| 22:57:26 | OrionPKM | like I said dom, i'm more worried about the standard library than about jester itself |
| 22:57:29 | dom96_and | Facebook used PHP and jester is currently faster than it. And that's without even trying. |
| 22:58:04 | OrionPKM | it's the not even trying part that tells me even you dont think it's ready for a big production system |
| 22:58:08 | dom96_and | What I said still splits to the stdlib |
| 22:58:21 | dom96_and | *applies |
| 22:58:40 | Araq | OrionPKM: so help us with the stdlib please. And sorry, PRs that break lots of code are not acceptable. |
| 22:58:46 | Varriount | And anyone who does benchmarks on filesystem functions should A: Know better than to benchmark IO bound calculations, and B:Perform benchmarks on how to perform certain actions as well as test the available procedures. |
| 22:59:04 | OrionPKM | araq it's on my to-do list... |
| 22:59:10 | Araq | yay :D |
| 22:59:14 | OrionPKM | at least to look at sockets/httpserver |
| 22:59:56 | dom96_and | OrionPKM: look at the way it's done in scgi |
| 23:00:04 | OrionPKM | I'd really like to see jester get truly top-tier performance |
| 23:00:10 | Araq | Varriount: alright. |
| 23:00:15 | OrionPKM | not 'good-enough for nim forums' :P |
| 23:00:23 | dom96_and | Most of httpserver should be rewritten though imo |
| 23:00:31 | OrionPKM | I agree |
| 23:01:09 | Varriount | I wonder how well a networking engine written with the entity-processing paradigm would work. |
| 23:01:15 | OrionPKM | you should know im not trying to criticize any of ur work dom96_and |
| 23:01:25 | Araq | no, we need working first class iterators and make that the base of a libevent styled system |
| 23:01:32 | OrionPKM | just think that some parts aren't going to scale well as the language matures |
| 23:01:41 | Araq | and then rewrite httpserver to sue that |
| 23:01:42 | dom96_and | OrionPKM: don't worry. I don't think that. |
| 23:01:46 | Araq | *use that |
| 23:01:56 | dom96_and | Araq: indeed |
| 23:02:18 | OrionPKM | yep, I agree araq |
| 23:02:22 | dom96_and | OrionPKM: those things can always be improved |
| 23:02:59 | dom96_and | Many languages don't even have good async stuff in their stdlib |
| 23:03:09 | Araq | dom96_and: yeah but the lack of async stuff is a show stopper |
| 23:03:11 | OrionPKM | araq I feel like maybe we shouldnt walk on egg shells about breaking changes in the stdlib, nim is still < 1 |
| 23:03:41 | Varriount | I have to somewhat agree with OrionPKM in that regard. |
| 23:03:44 | OrionPKM | do you really want a lot of deprecated cruft in the stdlib stuck around for years? |
| 23:04:02 | Araq | yes. because otherwise it breaks my code |
| 23:04:09 | dom96_and | I disagree |
| 23:04:15 | OrionPKM | change your code |
| 23:04:18 | OrionPKM | or dont |
| 23:04:26 | OrionPKM | if you dont change your code it keeps working, it just stops building :P |
| 23:04:31 | dom96_and | compile-time error is better than a confusing run time error |
| 23:05:04 | dom96_and | And that select change would be very subtle indeed |
| 23:05:07 | * | darkf joined #nimrod |
| 23:05:21 | OrionPKM | well |
| 23:05:27 | Araq | endless bikeshedding is not the solution |
| 23:05:31 | OrionPKM | the change would be to make it how you WOULD expect it to be |
| 23:05:32 | OrionPKM | :p |
| 23:05:39 | OrionPKM | as a 3rd party developer |
| 23:05:56 | Araq | right now the tester needs to learn about babel and some things broke |
| 23:06:00 | Araq | with things moving to babel |
| 23:06:22 | Araq | that means we work on fixing things that previously worked |
| 23:06:26 | dom96_and | Araq: remember to mention the move to babel in the news btw |
| 23:06:26 | OrionPKM | you've just distributed the problem to outside of your control araq |
| 23:06:30 | Araq | as opposed to fix *bugs* |
| 23:07:14 | OrionPKM | you start to depend on babel packages, they change, your code breaks, |
| 23:07:23 | Araq | slow evolution is the only thing that works with the stdlib |
| 23:07:36 | Araq | you don't like osproc.nim? fine then create your own |
| 23:07:40 | OrionPKM | I agree by-and-large araq |
| 23:07:48 | OrionPKM | but |
| 23:07:51 | OrionPKM | it's pre 1.0 |
| 23:08:03 | OrionPKM | people should expect breaking changes |
| 23:08:09 | Araq | everything that slows down my development speed is bad, sorry |
| 23:08:29 | Araq | especially since the project is still incredibly dependent on me |
| 23:09:28 | Araq | you can do things differently when you have the resources for it |
| 23:09:35 | Araq | but we haven't |
| 23:11:29 | OrionPKM | ok |
| 23:12:07 | dom96_and | We also want to attract people. We won't do that if we break their code constantly. |
| 23:12:29 | OrionPKM | we also wont by having a ton of confusing old functions in the std lib |
| 23:12:49 | OrionPKM | legacy kruft |
| 23:13:02 | Araq | I disagree |
| 23:13:27 | Araq | the fact is that *every* successful stdlib has some kruft |
| 23:13:49 | OrionPKM | before it even gets to 1.0 |
| 23:14:02 | OrionPKM | born with birth defects :p |
| 23:14:08 | Araq | yes |
| 23:14:28 | Araq | arguably C had lots of kruft that ended in the Ansi standard |
| 23:14:46 | Araq | dunno if they had versions back then |
| 23:15:14 | Araq | C#'s stdlib is full of old stuff, Java's is much worse |
| 23:15:16 | OrionPKM | what about a babel package containing the old stdlib :P |
| 23:15:32 | Araq | well the compiler itself depends on the stdlib |
| 23:15:34 | Varriount | That's an interesting idea. |
| 23:15:53 | Araq | you can't just put it into a babel package and pretend it doesn't exist |
| 23:15:55 | dom96_and | Doesn't D have two stdlibs? |
| 23:16:01 | OrionPKM | lol |
| 23:16:08 | Araq | yeah and that almost killed D |
| 23:16:28 | Varriount | dom96, yes. They arose out of a big split in the community, if I remember my reading right. |
| 23:16:31 | dom96_and | Yeah. Sounds like a good reputation booster for nimrod then :p |
| 23:16:33 | fowl | it does? |
| 23:17:16 | OrionPKM | lol |
| 23:21:41 | NimBot | Araq/Nimrod vm2 738fb2e Araq [+3 ±4 -0]: NoFakeVars progress |
| 23:22:00 | Varriount | FakeVars? |
| 23:22:30 | Araq | it's in system.nim, look it up |
| 23:51:32 | * | dom96_and quit (Quit: Bye) |
| 23:52:56 | * | MFlamer quit (Ping timeout: 240 seconds) |
| 23:53:26 | * | Reisen quit (Remote host closed the connection) |