| 00:00:31 | * | Smaehtin quit (Client Quit) |
| 00:02:13 | * | Smaehtin joined #nimrod |
| 00:02:22 | Smaehtin | Anyone alive? |
| 00:02:45 | Smaehtin | Anyone alive that knows how the asm keyword works in Nimrod? |
| 00:04:50 | Smaehtin | I've tried the syntax found at https://github.com/Araq/Nimrod/blob/master/doc/manual.txt line 2161 but I keep getting a "Error: execution of an external program failed" when compiling no matter what asm syntax I use |
| 00:09:45 | EXetoC | no one who knows anything about that is available now I think. try again at reasonable european hours :-) |
| 00:11:49 | EXetoC | cya later |
| 00:11:50 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 01:16:11 | * | BitPuffin quit (Ping timeout: 246 seconds) |
| 01:23:01 | * | Smaehtin quit (Quit: Page closed) |
| 01:23:18 | * | DAddYE quit (Remote host closed the connection) |
| 01:23:53 | * | DAddYE joined #nimrod |
| 01:28:14 | * | DAddYE quit (Ping timeout: 240 seconds) |
| 02:13:26 | * | q66 quit (Quit: Leaving) |
| 02:24:22 | * | DAddYE joined #nimrod |
| 02:28:59 | * | DAddYE quit (Ping timeout: 264 seconds) |
| 03:17:55 | * | DAddYE joined #nimrod |
| 07:44:54 | * | DAddYE quit (Remote host closed the connection) |
| 08:01:02 | * | DAddYE joined #nimrod |
| 08:31:46 | * | DAddYE quit (Remote host closed the connection) |
| 09:05:21 | * | q66 joined #nimrod |
| 09:13:08 | * | wan_ joined #nimrod |
| 09:45:39 | * | Araq_ joined #nimrod |
| 11:01:35 | * | BitPuffin joined #nimrod |
| 11:52:06 | * | Smaehtin joined #nimrod |
| 11:53:59 | Smaehtin | Anyone on here who knows anything about how to use the asm keyword in Nimrod? I tried following the example in the manual (https://github.com/Araq/Nimrod/blob/master/doc/manual.txt) but I keep getting a "Error: execution of an external program failed" when compiling no matter what assembler syntax I use |
| 11:55:41 | * | EXetoC joined #nimrod |
| 12:02:38 | Araq_ | hi Smaehtin |
| 12:02:56 | Araq_ | asm """ mov eax, `x` """ # where x is a nimrod variable |
| 12:03:11 | Araq_ | however the asm syntax depends on the used C compiler |
| 12:03:26 | Araq_ | there is a way to make GCC accept Intel syntax but I forgot how ;-) |
| 12:03:47 | Araq_ | use --parallelbuild:1 to see the error message of the C compiler |
| 12:04:11 | Smaehtin | Yeah, I'm using GCC. asm """ mov $10, %eax """ should be valid |
| 12:05:51 | Smaehtin | Hm |
| 12:05:53 | Smaehtin | main.c:187:6: error: expected string literal before 'mov' |
| 12:08:43 | Smaehtin | This works, however: asm """"mov $10, %eax"""" |
| 12:12:07 | Smaehtin | I guess I should've just read the "Triple quoted string literals" section of the manual :) |
| 12:12:52 | Araq_ | oh yeah |
| 12:13:18 | Araq_ | indeed gcc's broken asm needs everything in quotes |
| 12:13:42 | Araq_ | also you need to specify clobber registers etc. |
| 12:14:18 | Araq_ | it's as if the compiler doesn't know the instructions it accepts |
| 12:14:53 | Smaehtin | Yeah, I don't really like it either. I figured the example was for GCC though since that's what's shipped with the Nimrod installation :) |
| 12:17:07 | Araq_ | if you're good at GCC's asm, please have a look at system/arithm.nim ... I never got that to work for GCC |
| 12:21:38 | comex | Araq_: not broken compared to everything else which is worse :) |
| 12:22:57 | Smaehtin | Github seems to be down here :( |
| 12:23:06 | comex | me too |
| 12:24:01 | comex | https://twitter.com/githubstatus/status/358199381389873153 |
| 12:25:05 | Smaehtin | Great |
| 12:25:19 | Araq_ | comex: I don't agree; intel's compiler knows about clobber registers etc. iirc |
| 12:25:55 | comex | by parsing the assembly? |
| 12:26:09 | Araq_ | sure |
| 12:26:55 | comex | good luck implementing that in a clean way in a compiler whose job is to produce assembly files :) |
| 12:29:00 | Araq_ | Microsoft does this: http://msdn.microsoft.com/en-us/library/5hd5ywk0%28v=vs.71%29.aspx |
| 12:29:53 | Araq_ | but its job is to produce binary files, not assembler listings |
| 12:30:18 | Araq_ | assembler listings can be outputted via some switch of course |
| 12:30:30 | Araq_ | but that doesn't mean the compiler should do that all the time |
| 12:30:36 | comex | of course, a compiler like clang has knowledge about that stuff within the same binary |
| 12:30:44 | comex | and doesn't actually go through text form... |
| 12:30:50 | comex | then again, clang's inline assembly sucks for other reasons |
| 12:30:53 | comex | well, llvm's |
| 12:31:18 | comex | since GitHub's down, want to paste a copy of system/arithm.nim? |
| 12:34:13 | comex | being able to use structure offsets in the assembly is neat though |
| 12:35:15 | comex | however, it seems that MSVC's inline assembler also sucks, because you can't ask the compiler to stick things into particular registers |
| 12:35:35 | Araq_ | oh yeah good point |
| 12:36:01 | comex | of course you can use mov, but it's nice not to produce wasteful code |
| 12:36:26 | Araq_ | on the other hand the movs are most likely not even measurable |
| 12:39:02 | Araq_ | (no, can't paste system/arithm.nim without github either here) |
| 12:39:49 | EXetoC | ok massive test case coming up soon |
| 12:39:57 | comex | oh, i'ts back |
| 12:41:24 | comex | is there a reason you're asking it to put the operands in specific registers? |
| 12:48:28 | Araq_ | I can't remember, I think it didn't work otherwise either |
| 12:48:56 | Araq_ | and of course eax is the return value of the function |
| 12:53:29 | EXetoC | I've created a new issue. I could've removed a couple of modules, but it's not really going to make a difference |
| 12:54:09 | EXetoC | no wait, why does it compile now?? |
| 12:55:20 | EXetoC | didn't z=0 fail before? anyway, I'll just have to commit some changes |
| 13:01:14 | EXetoC | done |
| 13:02:33 | Araq_ | and now it fails? |
| 13:02:58 | EXetoC | ya |
| 13:03:43 | EXetoC | You should get this "gui.nim(44, 37) Error: undeclared identifier: 'z'" if left untouched |
| 13:04:56 | Araq_ | ok |
| 13:09:23 | EXetoC | adding 'when true:' seems to work, but not 'block:' for example |
| 13:09:59 | Araq_ | 'when true' doesn't affect scoping, block does |
| 13:10:07 | Araq_ | looks like a very interesting bug |
| 13:11:01 | EXetoC | does something in this case though |
| 13:11:21 | EXetoC | yeah, very hard to reproduce or trigger |
| 13:14:59 | EXetoC | z=0 works in the first example too btw |
| 13:16:14 | EXetoC | it just looks for 'z' in the current scope. it can be the name of an import too |
| 13:18:10 | EXetoC | what is your uncommitted stuff for? improved compile-time evaluation or something? |
| 13:18:42 | Araq_ | yeah but also a bugfix for clean templates as accessors |
| 13:27:42 | EXetoC | ok |
| 13:34:45 | * | Mat2 joined #nimrod |
| 13:34:50 | Mat2 | hello |
| 13:34:51 | EXetoC | Mat2: YO |
| 13:38:30 | Mat2 | Araq: GAS support Intel sytax with the .intel_syntax direction, and to be said luckily there exist only some incompatibilities in this mode :D |
| 13:40:18 | * | mal``` quit (Ping timeout: 246 seconds) |
| 13:41:45 | Mat2 | (like prefixing word-sizes with the ptr statement in a way which conforms to Microsoft's assembler MASM) |
| 13:42:12 | * | mal`` joined #nimrod |
| 13:51:45 | comex | Mat2: except for the part where .intel_syntax is completely broken on OS X :( |
| 13:55:06 | Mat2 | oh, I don't know that before. Can it be that OS X comes with AS because it incorporating the FreeBSD user-land ? |
| 13:56:08 | comex | it comes with a very old version of gas |
| 13:56:10 | comex | well, it used to |
| 13:57:00 | comex | still does, but clang now uses its integrated assembler instead |
| 13:58:13 | comex | don't actually remember what my issue with intel_syntax was, though |
| 13:59:12 | comex | maybe it's not as bad as I thought |
| 13:59:15 | comex | *yawn* |
| 13:59:59 | Mat2 | I know from my experiences with FreeBSD that the GAS version (there labeled simply AS like the executable) used don't support Intel syntax |
| 14:00:37 | Mat2 | however, clang should compensate for that in form of its IL representation |
| 14:03:41 | Mat2 | and AT&T syntax has the advantage to be exact defined... |
| 14:04:40 | * | Araq_ quit (Read error: Operation timed out) |
| 14:05:29 | Mat2 | otherwise the sources of gas up version 2 should compile fine on OS X |
| 14:05:55 | * | Araq_ joined #nimrod |
| 14:21:59 | * | wan_ left #nimrod (#nimrod) |
| 15:35:53 | EXetoC | beep |
| 15:36:36 | Mat2 | . |
| 15:43:48 | EXetoC | no u |
| 15:44:10 | Mat2 | ?? |
| 15:46:47 | EXetoC | I don't know |
| 15:46:49 | EXetoC | later |
| 15:51:44 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 16:06:00 | * | Mat2 quit (Ping timeout: 276 seconds) |
| 16:47:17 | * | silven_ is now known as silven |
| 16:48:26 | * | Mat2 joined #nimrod |
| 16:54:46 | * | DAddYE joined #nimrod |
| 16:55:41 | DAddYE | Morning PST guys |
| 17:01:48 | EXetoC | hi |
| 17:01:58 | EXetoC | sensible -> sensitive? |
| 17:02:37 | DAddYE | ExetoC yea |
| 17:03:05 | DAddYE | both is my english that is pretty bad and also I should turn off autocorrector on osx :D |
| 17:03:32 | Mat2 | welcome to the club ;) |
| 17:04:01 | DAddYE | EXetoC: I saw something in the forum but have u discussed with Araq to put Nimrod on kickstarted? |
| 17:04:12 | DAddYE | (again corrector) *kickstarter |
| 17:10:20 | EXetoC | it's understandable english though |
| 17:10:23 | EXetoC | no I haven't |
| 17:21:57 | DAddYE | EXetoC: I'm playing a lot with nimrod beside things you already know I'm enjoying it a LOTTTTTTTT |
| 17:22:29 | DAddYE | EXetoC: rewritten libuv wrapper, http wrapper and added a bit of highlevel interface |
| 17:22:59 | EXetoC | great |
| 17:24:19 | EXetoC | I started off with C++, which I abandoned quickly after I found about D, but it also has issues that I can't be bothered with |
| 17:24:49 | Mat2 | what issues have you figured out ? |
| 17:25:01 | * | alexandrus joined #nimrod |
| 17:26:15 | * | DAddYE sadly never found D interesting enough |
| 17:26:28 | EXetoC | and then Rust, which I don't use anymore, but it's still a good language |
| 17:34:03 | EXetoC | Mat2: bad syntax, bad const system, weird struct construction semantics, and tons other small issues, but it adds up |
| 17:34:28 | EXetoC | *tons of |
| 17:36:06 | Mat2 | hmm, that's the characteristic of most languages influenced by C I think |
| 17:36:42 | DAddYE | EXetoC: rust, nice, too young to me a lot of things changes fast (and is good), like heem case sensitive :D, but also there are a lot of things I mean seems a language that stolen a lot of things from others languages sometimes is good others not so "clean" IMHO |
| 17:36:51 | DAddYE | but definitely I like a lot deconstructors |
| 17:41:07 | EXetoC | as in conjunction with match expressions? yeah, it's pretty useful |
| 17:41:56 | EXetoC | or did you mean object destructors? |
| 17:47:10 | EXetoC | probably not. that's a lot less original :> |
| 17:50:05 | DAddYE | EXetoC: IIRC you can use the match directly in the fun (unless they changed this thing again) |
| 17:50:49 | Araq | DAddYE: Rust never was case insensitive |
| 17:51:10 | Araq | but they changed the convention from 'type' to 'Type'# |
| 17:51:28 | Araq | afaik anyway |
| 17:52:09 | DAddYE | haaaa thanks |
| 17:53:14 | Mat2 | don't know Rust but it can only be an C++ inspired language with functional extensions incorporated I think, because it's trendy (and multi-code cpu's more common) |
| 17:54:39 | Mat2 | sadly, I know one language of these type, which offers automatical parallelization of code sequences (which should much more innovative and needed) |
| 17:57:25 | Araq | Mat2: and that is? Parasail? |
| 17:57:55 | EXetoC | it borrows features from many languages, so yes that's likely |
| 17:58:41 | Mat2 | Araq: no, I mean modern APL interpreters |
| 17:58:56 | Araq | auto parallelization requires a cost function IMHO |
| 17:59:13 | Araq | and I know of no language that has that |
| 18:00:49 | Mat2 | it is doable in a static way but need an dynamic (re)evaluation of source-code |
| 18:04:17 | Mat2 | the main problem is synchronisation and that I handle restricting the language to be pure functional at core |
| 18:05:27 | Mat2 | APL is predestinated for cheap parallelisation because of its functional AND array orented characteristics |
| 18:06:42 | Mat2 | basical most sequences are executeble in parallel without problems if the interpreter is able synchronisate array accesses in case of the dynamical state of the interpreter |
| 18:06:56 | Mat2 | and that's a cheap and simple extension |
| 18:07:16 | Mat2 | ^oriented |
| 18:11:57 | Mat2 | ^executable |
| 18:13:04 | Mat2 | APL is somewhat unknown beside special oriented programmers which work in the dataflow industry I must say |
| 18:13:26 | Mat2 | ok, no one else knows this language I bet |
| 18:14:23 | Araq | I do "know" it |
| 18:14:56 | Araq | well I looked at it and couldn't understand anything ;-) |
| 18:15:09 | Mat2 | so I was wrong and that's fine |
| 18:15:30 | Mat2 | dito, it's feared as write-once language |
| 18:17:07 | Araq | hey it's my job to know every programming language |
| 18:18:03 | Mat2 | in reality it's just an alternative, more compact mathematical notation |
| 18:18:36 | Mat2 | I bought some (ok, most) ideas for my own system |
| 18:26:59 | EXetoC | is there a good reason why &= is defined for strings only? |
| 18:27:21 | DAddYE | EXetoC: I asked myself same thing yesterday |
| 18:27:46 | Araq | yeah |
| 18:28:00 | Araq | the reason is nobody made a pull request |
| 18:28:07 | Araq | it's an oversight ;-) |
| 18:28:13 | EXetoC | ok |
| 18:29:40 | DAddYE | EXetoC: I asked myself same thing yesterday |
| 18:30:07 | DAddYE | also we need to support == > and so on for uint8 and so on |
| 18:31:07 | EXetoC | DAddYE: it's defined in the 'unsigned' module, in order to discourage the use of unsigned types |
| 18:31:36 | EXetoC | which I think is reasonable. I rarely need them |
| 18:31:45 | DAddYE | ok |
| 18:31:45 | DAddYE | makes sense |
| 18:31:53 | DAddYE | didn't noticed that module |
| 18:32:18 | Araq | bbl |
| 18:47:04 | EXetoC | speaking of kickstarter, didn't you plan to work on Nimrod full-time, Araq? if so, is that how you'd go about it? seems like the easiest way in general |
| 18:47:13 | * | gradha joined #nimrod |
| 18:47:23 | EXetoC | still fairly hard though, depending on the circumstances, but that'd be awesome and a half |
| 18:47:26 | EXetoC | gradha: yo, wazzup |
| 18:47:48 | gradha | watching the logs, having a shake |
| 18:48:28 | EXetoC | milkshake? protein shake? booty shake? |
| 18:48:58 | gradha | milk + banana + blender |
| 18:50:00 | EXetoC | yum |
| 18:56:29 | EXetoC | maybe we should have a "type TNone = object" in system.nim. I tried to use 'void' for this purpose, but it can't be instantiated |
| 18:56:54 | fowl | where do you need that |
| 19:04:39 | EXetoC | fowl: it's for denoting the absence of a value. T|none for example |
| 19:06:31 | fowl | thats not going to work like its haskell |
| 19:07:26 | EXetoC | I don't know how it works in haskell, but it seems useful |
| 19:08:30 | fowl | use tmaybe[t] https://github.com/fowlmouth/nimlibs/blob/master/fowltek/maybe_t.nim |
| 19:17:40 | EXetoC | I forgot about that |
| 19:19:00 | fowl | nobody is using fowltek yet :( |
| 19:19:03 | fowl | on github at least |
| 19:20:13 | gradha | lack of documentation and visibility may have something to do with that |
| 19:20:14 | EXetoC | as a submodule? I've installed everything using babel |
| 19:21:34 | fowl | gradha, docs are built with the nimrod doc command, docs are lame anyways |
| 19:21:43 | fowl | at the bottom of each module is an example of use |
| 19:22:26 | EXetoC | I don't know if it's a good idea to have 'has' depend on 'isNil' in any way (if present), but it doesn't matter right now |
| 19:22:52 | gradha | fowl: it doesn't matter that you have an example at the bottom if people don't even know why would they want to use the maybe_t module |
| 19:23:13 | fowl | gradha, oh so what do i need? a mission statement for each module? |
| 19:23:23 | EXetoC | I mean when using 'assign'. it might make sense for Maybe |
| 19:23:30 | fowl | its pretty obvious that its a maybe[t] |
| 19:23:47 | gradha | fowl: exactly, I don't even know why would I use a maybe[t] because I haven't used one in my life |
| 19:23:49 | DAddYE | maybe a readme |
| 19:23:59 | DAddYE | with example usage |
| 19:24:20 | gradha | I don't even know why a maybe[t] is useful |
| 19:24:33 | gradha | or what problem does it solve |
| 19:24:41 | gradha | ignorance is bliss they say |
| 19:25:25 | fowl | there is a readme, and there is example usage |
| 19:25:31 | EXetoC | sometimes it's useful to be able to specify the absence of a value |
| 19:25:40 | fowl | but no, im not writing a paragraph for each module to sell it to people |
| 19:26:03 | fowl | im not going to explain when you would use a maybe[t] anyways, or what problem it solves |
| 19:26:09 | fowl | google will answer your questions gradha |
| 19:29:03 | DAddYE | EXetoC: from my low know-how about it should be some like a monad |
| 19:29:09 | DAddYE | but that said no clue |
| 19:29:20 | fowl | EXetoC, i cant reproduce your named arguments problem, as long as you have parenthesis around the args |
| 19:32:48 | EXetoC | fowl: I can't either, which is why my test case is massive |
| 19:33:49 | EXetoC | it even works in my original source now, and I haven't really changed much |
| 19:37:41 | EXetoC | are default arguments as flexible in any other languages? proc f(o: T, bla=o.x()) |
| 19:38:36 | EXetoC | yeah, probably in some dynamic languages |
| 19:41:36 | EXetoC | stupid zombie process! |
| 19:44:49 | fowl | EXetoC, not sure if you can do that |
| 19:45:44 | EXetoC | fowl: you can! |
| 19:45:52 | EXetoC | awesome innit |
| 19:46:53 | Araq | you can? I wonder how |
| 19:47:28 | EXetoC | you don't know, really? :p hopefully it works correctly then |
| 19:48:03 | EXetoC | but I've used it successfuly a couple of times |
| 19:48:06 | Araq | I can't imagine how unless zahary1 made it work |
| 19:48:21 | fowl | because arguments are processed left to right |
| 19:48:42 | Araq | oh I don't wonder why it passes the semantic checking |
| 19:49:05 | Araq | I wonder why it generates correct code |
| 19:49:31 | EXetoC | hopefully it's a feature, because it rox |
| 19:51:55 | Araq | EXetoC: btw kickstarter won't work I'm afraid, especially because I bought a house ... -.-' |
| 19:53:02 | EXetoC | does that mean you're not poor enough for people to care? :p |
| 19:53:17 | DAddYE | EXetoC: hahuahahahaha |
| 19:53:25 | Mat2 | I'm just aksing me the same question right now... |
| 19:53:36 | EXetoC | stupid game keeps crashing. that's a good thing though, because it's a bloody waste of time! |
| 19:54:26 | Araq | well ... you know ... buying a house doesn't imply that you have the money for it |
| 19:54:40 | DAddYE | what is your alternative language to Nimrod aka what do you use once you can't (like maybe at work) |
| 19:55:00 | gradha | EXetoC: so true, I ragequite my last addiction when it could not load the save game "due to corruption", or should I say, incompetent programmers |
| 19:55:03 | EXetoC | I forgot about this 'loan' thing |
| 19:55:32 | DAddYE | Araq: you can ask your employer to give you 1 year of wait time (in Italy there is a law for that I think your country too) |
| 19:56:30 | DAddYE | luuuuuuuuuuuuuuuuuuuuuunch |
| 19:56:34 | Araq | DAddYE: C# |
| 19:56:45 | DAddYE | Araq: sorry for that :( |
| 19:56:56 | DAddYE | :D |
| 19:57:04 | Araq | could be much worse, could be Java instead ;-) |
| 19:58:00 | Mat2 | a lot of ehm ... useful documentation documentation for Java ;) |
| 20:00:49 | EXetoC | gradha: you should've been paranoid like me and created a new entry every time! |
| 20:06:11 | EXetoC | but hopefully you're writing more code now instead |
| 20:10:46 | gradha | nah, switched to watching youtube |
| 20:11:18 | EXetoC | -.- |
| 20:17:12 | dom96 | hi |
| 20:17:40 | gradha | hi |
| 20:19:10 | EXetoC | hi |
| 20:27:22 | Mat2 | hello |
| 20:28:15 | dom96 | hi |
| 20:28:28 | gradha | hi |
| 20:29:28 | EXetoC | YO |
| 20:29:44 | Mat2 | by the way, what means yo ? |
| 20:30:10 | EXetoC | that's the gangsta way of saying hi |
| 20:30:48 | Mat2 | ehm ok |
| 20:33:55 | * | Mat2 must be something like 'mu' in rinzai zen |
| 20:43:06 | dom96 | gradha: so what did you do to fix the builder? |
| 20:44:38 | gradha | the git checkout was broken, purged several times until it caught up |
| 20:45:23 | gradha | also increased the ping timeout, though extreme torrenting still messes it |
| 20:46:04 | gradha | - if epochTime() - state.pinged >= 5.0: # 5 seconds |
| 20:46:04 | gradha | + if epochTime() - state.pinged >= 15.0: # 5 seconds |
| 20:46:33 | gradha | no idea if it helps at all, maybe it's a placebo |
| 20:50:06 | dom96 | the hub may still time you out |
| 20:50:25 | dom96 | and it does seem to be disconnecting sometimes. |
| 20:50:39 | dom96 | Your lag is 18 seconds 0_o |
| 20:50:57 | gradha | yeah baby |
| 20:51:25 | dom96 | I guess i'll make this stuff configurable then |
| 20:51:33 | * | alexandrus quit () |
| 21:30:56 | dom96 | Araq: So I think we need to finally move the csources out of the git repo. |
| 21:31:27 | Araq | as I said, fine with me |
| 21:31:48 | dom96 | Alright. Where do you want to move the C sources to though? |
| 21:31:58 | Araq | nimbuild of course |
| 21:32:32 | dom96 | How will you upload them then if you break bootstrapping? |
| 21:32:43 | dom96 | I was thinking we have two options: |
| 21:33:42 | dom96 | Hosting them on nimrod-code.org, which is I guess what you mean? But then zahary can't upload there. |
| 21:33:51 | dom96 | *is |
| 21:34:17 | Araq | fine |
| 21:34:26 | Araq | let's make another github repo then for them |
| 21:34:34 | dom96 | Yeah, that's the second option. |
| 21:34:41 | Araq | we need to spam github with nimrod projects anyway |
| 21:35:23 | dom96 | we might as well keep it unzipped in the separate github repo then |
| 21:35:48 | dom96 | github can zip it for us if the user has no git installed |
| 21:35:48 | Araq | but the generated C is big |
| 21:35:59 | Araq | but ok |
| 21:36:09 | Araq | sounds good |
| 21:36:11 | dom96 | why would anyone be interested in the diff anyway? |
| 21:36:20 | dom96 | I bet github got better at handling large diffs also. |
| 21:36:33 | Araq | oh yeah hmm |
| 21:36:34 | dom96 | I would guess it's just hidden now if there is too many changes. |
| 21:36:45 | Araq | I don't think so |
| 21:37:02 | dom96 | we can test that easily :P |
| 21:37:52 | dom96 | I'll create the repo in the nimrod-code organisation, or do you want it under your username? |
| 21:38:12 | Araq | the org of course |
| 21:38:50 | dom96 | what should i call it? csources? bootstrap? bootstrappkg, nimboot, nimrod_bootstrap, nim_csources? |
| 21:40:55 | Araq | dunno the 'nim' prefix is getting boring |
| 21:41:12 | dom96 | yeah, it's starting to annoy me. |
| 21:41:37 | dom96 | Whenever I try to autocomplete 'nimrod' after typing 'nim' ... |
| 21:41:48 | Araq | same here |
| 21:42:33 | gradha | sources.nim, you can have dots in the module name IIRC |
| 21:42:51 | dom96 | heh, yeah. Was about to suggest that. Node.js style :P |
| 21:43:15 | Araq | no |
| 21:43:20 | gradha | you could also start prefixing everything with gradha, it's getting fashionable |
| 21:43:46 | dom96 | Araq: yeah, I don't like it either :P |
| 21:44:11 | dom96 | gradha_sources: build your own gradha today! |
| 21:44:27 | Araq | I find it amusing; it comes from the "we don't need no stinkin file extensions on unix" crowd after all |
| 21:45:37 | gradha | I'd name the github module xvsZ745HyV5FLqJc |
| 21:45:48 | gradha | it also serves as a nice random password |
| 21:45:59 | EXetoC | ok this default argument stuff is too bleeding-edge :p |
| 21:46:09 | dom96 | yeah, lets just use an md5 hash of 'sources' |
| 21:46:27 | Araq | EXetoC: doesn't work, hmm? :P |
| 21:46:33 | EXetoC | sometimes |
| 21:47:42 | EXetoC | I'll just have to avoid referencing some of the other arguments |
| 21:47:55 | Araq | yep |
| 21:48:07 | Araq | calls as defaults are fine otherwise |
| 21:48:24 | dom96 | what should I call it then? |
| 21:48:47 | Araq | lets ask DAddYE, he knows these things |
| 21:48:58 | EXetoC | and TMaybe for the others |
| 21:49:36 | DAddYE | Araq: wwwwwhat? |
| 21:49:43 | gradha | name it gamera_eggs |
| 21:49:51 | gradha | gamera_cocoon |
| 21:49:55 | Araq | no |
| 21:50:06 | Araq | we already have the gamera edition |
| 21:50:10 | Araq | that's enough |
| 21:50:11 | DAddYE | Araq: what is the status of vm registers ? |
| 21:50:31 | Araq | DAddYE: I'm testing it |
| 21:51:43 | DAddYE | Araq: what big advantages it will give us? |
| 21:51:49 | DAddYE | other than eval |
| 21:52:21 | Araq | eval speed and it will fix eval bugs |
| 21:52:46 | DAddYE | neat |
| 21:54:47 | DAddYE | Araq: is there a roadmap? |
| 21:54:51 | DAddYE | of nimrod |
| 21:55:47 | Araq | there is my todo.txt |
| 21:56:12 | EXetoC | "error: unknown type name ‘TY209224’ typedef N_INLINE_PTR(tmaybe209230, TY209224) (void)" d'oh |
| 21:56:38 | * | dom96 waits for that name |
| 21:58:06 | Araq | EXetoC: don't use .inline procs as first class |
| 21:58:17 | DAddYE | Araq: shared memory heap -> can't wait |
| 21:58:18 | Araq | but make a bug report of course |
| 21:59:25 | DAddYE | Araq: also this arglist as a type (iterator chaining); variable length type lists for generics | NICE |
| 21:59:57 | DAddYE | Araq: any plan for coroutines ? |
| 22:00:33 | EXetoC | Araq: what do you mean? |
| 22:01:09 | Araq | EXetoC: I'm guessing you're passing a proc around which has been declared .inline, but I could be wrong |
| 22:01:17 | dom96 | Araq: What should I name it!? |
| 22:01:33 | gradha | dom96: everything has been rejected, therefore name it nil |
| 22:02:08 | Araq | dom96: bootnim |
| 22:02:14 | EXetoC | Araq: ah right, forgot to call it |
| 22:02:33 | dom96 | Araq: sounds too much like a tool. |
| 22:02:56 | gradha | looks like Knuth was right |
| 22:03:32 | Araq | DAddYE: yes since many people requested them |
| 22:04:56 | DAddYE | how hard will |
| 22:05:37 | DAddYE | do that? |
| 22:05:42 | DAddYE | (for the current GC) |
| 22:07:32 | Araq | it's not really hard but tedious |
| 22:07:39 | EXetoC | "`type`: TWidgetType|typedesc[none]=none," aiight |
| 22:07:54 | dom96 | ugh screw it, i'm calling it csources |
| 22:08:05 | Araq | dom96: ok good |
| 22:11:03 | Araq | dom96: do you prune the history too? |
| 22:11:13 | dom96 | not right now, no. |
| 22:11:32 | DAddYE | yesterday night I did some nim coding, is there a better way in doing this: https://gist.github.com/DAddYE/47fc075004bcf7c0008e ? |
| 22:11:33 | dom96 | I think we should do that once this bootstrapping method is stable and tested. |
| 22:11:46 | EXetoC | I can even do this: "type parent* = distinct void", and then f(`type`=parent) for increased readability. |
| 22:12:55 | Araq | DAddYE: req.body.add(body) |
| 22:13:15 | DAddYE | without nil check ? |
| 22:13:27 | Araq | instead of req.body = req.body & body |
| 22:13:50 | DAddYE | ok |
| 22:13:56 | Araq | the nil check is necessary unless you use 'safeAdd' |
| 22:14:13 | DAddYE | neat, do you suggest to use it instead? |
| 22:14:28 | DAddYE | safeAdd or assign |
| 22:14:57 | Araq | not really, I think we should make 'add' and 'len' nil safe |
| 22:15:12 | DAddYE | I agree |
| 22:15:22 | Araq | and maybe have an xlen and xadd for the crazy people who can't stand the overhead |
| 22:16:04 | DAddYE | makes sense |
| 22:16:22 | Araq | body = body[0..length - 1] # more efficient: body.setLen(body.len-1) |
| 22:16:37 | Araq | er |
| 22:16:43 | Araq | body.setLen(length-1) |
| 22:17:00 | DAddYE | true! Good catch! |
| 22:17:45 | DAddYE | Araq: also, if you want to write a doc/spec about things missing in system or easy tasks like better docs and so on |
| 22:17:56 | DAddYE | write it somewhere so in my freetime I'll try to help |
| 22:18:27 | DAddYE | the todo.txt is too todo for my current knowledge of nim |
| 22:18:57 | DAddYE | also if you need to "reorganize things" |
| 22:19:08 | DAddYE | aka the boring stuff that no one one todo |
| 22:19:10 | DAddYE | :D |
| 22:19:43 | dom96 | yep, I was right: https://github.com/nimrod-code/csources/commit/246869efea84f76e8972162a64dddee9ab80b4f6 |
| 22:19:44 | dom96 | :D |
| 22:19:56 | dom96 | 2.8 million additions. |
| 22:19:58 | dom96 | Nice. |
| 22:20:01 | EXetoC | he'll do it, and then demand cookies retroactively |
| 22:20:16 | dom96 | DAddYE: Make a better gtk wrapper |
| 22:20:50 | dom96 | But perhaps you need more experience with nimrod to make an idiomatic gtk wrapper. |
| 22:21:12 | DAddYE | dom96: yup |
| 22:21:32 | DAddYE | dom96: right now I'm rewriting / updating libuv and http_parser |
| 22:21:49 | DAddYE | long long plan (if possible) node.nim |
| 22:21:50 | DAddYE | :D |
| 22:22:06 | DAddYE | I know Araq did nimrod to port node.js |
| 22:22:07 | DAddYE | :D |
| 22:25:39 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
| 22:28:12 | Araq | DAddYE: you know he have a JS backend, right? |
| 22:28:15 | Araq | *we |
| 22:28:30 | DAddYE | js is for losers :D |
| 22:29:12 | EXetoC | lol |
| 22:29:31 | DAddYE | qq: a thing like $(at).setLen(length - 1) cannot be valid right? |
| 22:32:58 | Araq | right |
| 22:33:23 | dom96 | Why are you mentioning node.js then? |
| 22:34:04 | DAddYE | dom96: I like libuv but I don't like (so much) js, node is neat |
| 22:34:11 | DAddYE | btw is just exercises |
| 22:34:40 | DAddYE | Araq: so haven't we an alias for $ like toStr() or some like that? |
| 22:37:39 | dom96 | why would we? |
| 22:39:40 | DAddYE | dom96: just because I need to convert a cstring to string in order to use setLen but I want to know if there is a way to avoid to assign a new var with $at |
| 22:40:00 | DAddYE | and so use at.toStr().setLen(..) |
| 22:40:09 | DAddYE | maybe |
| 22:40:15 | EXetoC | ($at)...? |
| 22:40:15 | DAddYE | setLen $a, number |
| 22:40:16 | DAddYE | ? |
| 22:40:33 | dom96 | setLen needs a 'var' I think |
| 22:40:40 | DAddYE | ok |
| 22:40:55 | DAddYE | thinking about that Im stupid |
| 22:41:07 | DAddYE | setLen doesn't return a new string so |
| 22:41:12 | DAddYE | I need a var in any case |
| 23:02:46 | * | Araq_ quit (Ping timeout: 240 seconds) |
| 23:03:08 | * | Araq_ joined #nimrod |
| 23:04:26 | Mat2 | ciao |
| 23:04:43 | * | Mat2 quit (Quit: Verlassend) |
| 23:27:22 | DAddYE | Araq: sounds crazy to you add to ArryLike foo[-1] to get latest result? |
| 23:30:03 | EXetoC | D's approach is good. $ evaluates to the length |
| 23:30:49 | EXetoC | your approach would incur some overhead by default |
| 23:32:54 | DAddYE | so to get latest $foo is enough ? |
| 23:33:17 | EXetoC | foo[$ - 1] |
| 23:33:23 | EXetoC | same as foo[foo.length - 1] |
| 23:33:44 | DAddYE | fantastic |
| 23:33:44 | EXetoC | pretty neat, but $ is obviously occupied already |
| 23:33:51 | DAddYE | yep |
| 23:34:04 | DAddYE | foo[#-1] |
| 23:35:01 | EXetoC | it would be inconsistent since # denotes the beginning of a comment |
| 23:37:04 | DAddYE | true |
| 23:40:08 | EXetoC | Araq: are sum types a planned feature? if not, then maybe you could allow two arguments to be specified for converters, which would allow type parameters of the target type to be extracted |
| 23:43:19 | EXetoC | which would allow things like foo(none), as an alternative to foo(Nothing[SomeType]) |
| 23:44:03 | EXetoC | fowl: thoughts? too much nitpicking? |
| 23:47:21 | EXetoC | nah, just more awesomeness, amirite :> |
| 23:47:24 | EXetoC | later |
| 23:49:42 | * | EXetoC quit (Quit: WeeChat 0.4.1) |