| 00:00:18 | gradha | going back in time is a useful feature, trust me |
| 00:00:21 | Araq | the latest commit that has been pushed is the breaking commit |
| 00:00:36 | Araq | no need for anything more fancy |
| 00:01:06 | gradha | I'm already thinking about stuff breaking, so being able to request past commits would be good if something unexpected happens and the breaking commit doesn't record |
| 00:01:17 | gradha | then you can fix problems and repeat just the test run |
| 00:01:32 | Araq | *shrug* if it makes you happy |
| 00:03:22 | gradha | huh, conceptually it sounds simple, any advice on real world problems with nimbuild I might need to be aware of? |
| 00:03:35 | gradha | or maybe I should talk tomorrow to dom96? |
| 00:03:50 | Araq | I bet you do want to talk to him |
| 00:04:09 | Araq | his code ... is ... hacked together |
| 00:04:48 | gradha | hah, unbelivable |
| 00:05:09 | gradha | have you ever looked at somebody else's code and thought "oh, it's well written" |
| 00:05:21 | Araq | yeah |
| 00:05:51 | gradha | in nimrod too? |
| 00:05:56 | Araq | but right now only Lua's source code comes to mind ;-) |
| 00:07:01 | Araq | the math stuff written in Nimrod I code reviewed was good |
| 00:07:26 | Araq | your code is always quite clean too iirc |
| 00:07:51 | gradha | more like verbose, which is the complaint I hear most from other developers |
| 00:08:30 | gradha | I should really write a book, about nimrod, the serial killer, whose first victim is a girl named Ruby... |
| 00:18:13 | comex | Araq: C++ is strictly worse than C at very many different things |
| 00:18:37 | Araq | I disagree |
| 00:18:47 | comex | Rust is very unstable and encourages you to write very different code than C |
| 00:18:56 | comex | nimrod, well *shrug* |
| 00:19:07 | Araq | I forgot about Modula 2 btw |
| 00:19:18 | Araq | Modula 2 is exactly C without the bullshit |
| 00:22:08 | comex | perhaps |
| 00:22:10 | comex | never used it |
| 00:22:20 | comex | but C++ also tries to encourage you to write much higher level, often worse code |
| 00:22:58 | Araq | *shrug* that's a feature |
| 00:23:18 | comex | it also implements metaprogramming in such a braindead way that given any large C++ project, there is almost certain to be difficult to understand magic |
| 00:23:35 | comex | C macros can be worse, but they are usually not |
| 00:23:46 | gradha | magic is by definition difficult to understand, otherwise we would not call it magic |
| 00:23:56 | Araq | C's inablitity to express higher level features is certainly not a *feature* |
| 00:24:03 | comex | Araq: it is certainly a feature |
| 00:24:33 | comex | or at least, if you want to support higher level features, you should do it in a way that does not make it easy to produce slow, unmaintainable, hard-to-read code |
| 00:25:26 | comex | but things like templates are not as necessary as they seem - when they are, C suffers, but the high volume of C code is testament to the fact that they are usually not necessary |
| 00:25:36 | comex | and avoiding them often produces better code |
| 00:26:07 | Araq | the high volume of Java code proves nobody needs anything lower level |
| 00:26:22 | Araq | can you see the falacy now? |
| 00:26:54 | comex | C is significantly more expressive than Java. |
| 00:27:43 | Araq | it's not about Java |
| 00:27:54 | Araq | it's an example of your fallacy argument |
| 00:28:00 | comex | what is the fallacy? |
| 00:28:09 | Araq | "the high volume of C code is testament to the fact that they are usually not necessary" |
| 00:29:07 | comex | it is not a proof, but evidence. |
| 00:29:18 | Araq | the high volume of C code is only shows programmer's stubbornness |
| 00:29:19 | comex | the high volume of Java code is testament that its features are usually sufficient to do what is wanted. of course we must look at more than just the volume |
| 00:29:22 | gradha | let me try too "the high volume of sequential code is testament to the fact that concurrent code is usually not necessary" |
| 00:29:34 | comex | there are many more detailed reasons I do not like Java, but the high volume of code is a reasonable counter-argument |
| 00:29:38 | comex | gradha: that would be correct. |
| 00:30:07 | Araq | the high volume of Fortran code is a testament of its superior performance |
| 00:30:20 | comex | no, you are taking it too far |
| 00:30:26 | gradha | comex: weird, I would say that the high volume of sequential code is testament to the fact that concurrent bugfree code is hard to write |
| 00:31:03 | Araq | the high volume could also imply an incredible unexpressive language |
| 00:31:20 | comex | Araq: in Java, it does. in C, it does not, as it is usually more succinct than either Java or C++. |
| 00:31:34 | comex | gradha: those are the same thing. it is due to that difficulty that we only write concurrent code when necessary. |
| 00:32:17 | Araq | comex: that's just bullshit, compare a GTK app in C vs one in C++ |
| 00:32:37 | comex | GTK is a poorly designed C library. |
| 00:32:45 | Araq | and btw C++ proves C is not sufficient |
| 00:32:51 | Araq | so does Objective C |
| 00:32:58 | Araq | otherwise they wouldn't have been invented |
| 00:33:15 | Araq | using your twisted logic at least ... |
| 00:33:22 | comex | no, C++ proves, as you like to say, that programmers are stubborn |
| 00:33:46 | Araq | lol |
| 00:33:49 | gradha | comex: I'm afraid I've seen too many cases of sequential code wasting multicore machienes to consider your statement true, most people don't even think of writing concurrent code because they are not looking for performance |
| 00:33:58 | Araq | C++ was "revolutionary" when it came around |
| 00:34:10 | Araq | all this OO stuff was way too much for most C programmers |
| 00:34:56 | Araq | it certainly doesn't prove stubbornness |
| 00:36:15 | Araq | and btw most C code looks like err = call_some_function(); if (err) goto error; |
| 00:36:18 | comex | stubborn enough to expect the language to do everything for them, in order to make stupid things (but not most non-stupid things) easy |
| 00:36:30 | comex | so does most C++ code, it's better than using exceptions |
| 00:36:32 | Araq | if that doesn't prove the usefulness of exceptions then I dunno |
| 00:37:13 | Araq | it doesn't suffice, you can't compose functions then anymore |
| 00:37:17 | comex | exceptions are ridiculously easy to not pay attention to and then allow to blow up your application |
| 00:37:19 | gradha | what a coincidence, machines are hitting speed limits and suddenly concurrency is important again |
| 00:37:46 | comex | another example of programmers thinking the machine can do everything for them. |
| 00:38:00 | gradha | we are going to see more concurrent programming now, not because it wasn't necessary, but because hardware improvements made it less cost-effective |
| 00:38:44 | comex | gradha: necessary and cost effective are the same thing. |
| 00:39:39 | EXetoC | how many exceptions aren't fatal anyway? at least in some types of applications |
| 00:40:17 | Araq | EXetoC: whether it's fatal or not depends on the use case, a library often can't make this decision |
| 00:40:35 | Araq | so exceptions have been invented to increase modularity |
| 00:41:33 | EXetoC | yes, but it means a lot of convenience for many of the users |
| 00:42:15 | comex | Araq: right, because getting a random NullPointerException from 5 calls deep is modular |
| 00:42:23 | comex | there's a reason why most C++ code I've seen avoids exceptions! |
| 00:42:35 | Araq | in C++ there is no NullPointerException |
| 00:42:40 | comex | anyway, arguing is fun, but i have to go |
| 00:43:09 | comex | have fun ;p |
| 00:43:32 | Araq | it's more fun when the arguments are reasonable ... |
| 00:44:31 | Araq | and btw "ooh this feature is bad in C++, it must be bad in general" is yet another fallacy of yours ... |
| 00:45:46 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
| 00:47:52 | EXetoC | yeah it's very different in other languages |
| 00:50:29 | NimBot | Araq/Nimrod master 604e579 Araq [+1 ±2 -0]: 'nirmod pretty': almost working |
| 00:56:15 | EXetoC | https://github.com/Araq/Nimrod/blob/master/compiler/semexprs.nim#L347 I've hit this. I was trying to create a nested tuple |
| 00:56:22 | EXetoC | trying to reduce it now |
| 01:42:04 | * | DAddYE quit (Remote host closed the connection) |
| 01:43:46 | EXetoC | done. simple workaround as always |
| 02:03:01 | * | q66 quit (Quit: Leaving) |
| 02:43:11 | * | DAddYE joined #nimrod |
| 02:50:17 | * | DAddYE quit (Ping timeout: 261 seconds) |
| 03:03:12 | * | Associat0r quit (Read error: Connection reset by peer) |
| 03:08:13 | * | DAddYE joined #nimrod |
| 04:01:35 | * | EXetoC quit (Quit: WeeChat 0.4.1) |
| 04:03:21 | * | Associat0r joined #nimrod |
| 04:03:22 | * | Associat0r quit (Changing host) |
| 04:03:22 | * | Associat0r joined #nimrod |
| 04:19:22 | * | OrionPK quit (Read error: Connection reset by peer) |
| 04:26:49 | * | xilo quit (Ping timeout: 246 seconds) |
| 04:29:10 | reactormonk | Araq, on what can I build a JS repr? Should it display JS or nimrod objects? |
| 05:42:28 | * | Trix[a]r_za is now known as Trixar_za |
| 06:40:01 | * | Trixar_za is now known as Trix[a]r_za |
| 06:45:07 | * | Trix[a]r_za is now known as Trixar_za |
| 07:14:48 | * | Araq_ joined #nimrod |
| 07:50:14 | * | Trixar_za is now known as Trix[a]r_za |
| 08:32:14 | * | DAddYE quit (Remote host closed the connection) |
| 08:32:44 | * | DAddYE joined #nimrod |
| 08:37:27 | * | DAddYE quit (Ping timeout: 260 seconds) |
| 09:15:23 | dom96 | <Araq> [01:04:09] his code ... is ... hacked together |
| 09:15:31 | dom96 | My code is beautiful. |
| 09:33:30 | * | BitPuffin joined #nimrod |
| 09:45:51 | BitPuffin | Hmm |
| 09:47:29 | BitPuffin | what should I name this collada import library: Cologne (or Collogne), Coloader (or Colloader) or daerod |
| 09:48:37 | * | q66 joined #nimrod |
| 09:56:22 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 10:01:00 | * | BitPuffin joined #nimrod |
| 10:02:34 | dom96 | hey BitPuffin |
| 10:02:42 | BitPuffin | hello dom96! |
| 10:04:57 | BitPuffin | dom96: sup? |
| 10:05:18 | dom96 | hrm, not much really |
| 10:06:09 | dom96 | Trying to work on the async stuff but getting distracted all the time... |
| 10:07:23 | dom96 | BitPuffin: how are things going on your end? |
| 10:17:15 | BitPuffin | dom96: async stuff? |
| 10:17:41 | BitPuffin | dom96: it's gonig pretty okay, not getting too much done really but I'm currently working on a collada import library for nimrod |
| 10:20:58 | dom96 | Yeah, i'm creating a C#-like await thingy: https://github.com/Araq/Nimrod/blob/asyncmacro/tests/compile/tasyncitermacro.nim |
| 10:55:54 | dom96 | bbl |
| 11:11:19 | BitPuffin | dom96: cool! |
| 11:11:20 | BitPuffin | Hu |
| 11:11:22 | BitPuffin | uh* |
| 11:11:33 | BitPuffin | Parsexml vs xmlparser? |
| 11:16:59 | * | Associat0r quit (Quit: Associat0r) |
| 11:27:12 | Araq_ | BitPuffin: daerod sounds cool |
| 11:27:51 | BitPuffin | Araq_: Hmm, and I went with cologne, daerod is pretty nice though, might rename |
| 11:27:52 | Araq_ | dom96: your code certainly can be improved ... you should really learn about GCSE |
| 11:28:21 | Araq_ | "global common subexpression elimination" |
| 11:29:37 | * | Associat0r joined #nimrod |
| 11:29:37 | * | Associat0r quit (Changing host) |
| 11:29:37 | * | Associat0r joined #nimrod |
| 11:37:33 | BitPuffin | Araq_: it's most likely a temporary name anyways like with linagl. If I decide to write my API in nimrod (probably) after evaluating it for a few projects these libs will become part of it |
| 11:38:08 | Araq_ | ok |
| 11:57:26 | * | BitPuffin quit (Ping timeout: 268 seconds) |
| 12:08:01 | * | Araq_ quit (Quit: ChatZilla 0.9.90.1 [Firefox 22.0/20130618035212]) |
| 12:13:15 | * | Associat0r quit (Quit: Associat0r) |
| 13:20:14 | * | Araq_ joined #nimrod |
| 13:20:28 | * | Araq_ quit (Client Quit) |
| 13:25:51 | * | EXetoC joined #nimrod |
| 13:27:05 | dom96 | Araq: Yes, of course it can be. I'll admit that the branches support is a bit messy. |
| 13:37:09 | * | Endy joined #nimrod |
| 13:41:34 | * | BitPuffin joined #nimrod |
| 13:58:03 | * | Araq_ joined #nimrod |
| 13:59:45 | * | Araq_ quit (Client Quit) |
| 14:04:12 | BitPuffin | dom96: Do you anything about progress on values in generic params? |
| 14:06:31 | dom96 | nope, sorry. |
| 14:06:36 | BitPuffin | awh :( |
| 14:06:43 | BitPuffin | kind of need it |
| 14:07:03 | BitPuffin | I'm not gonna do matrices with ranges |
| 14:10:40 | * | [1]Endy joined #nimrod |
| 14:13:40 | * | Endy quit (Ping timeout: 264 seconds) |
| 14:13:40 | * | [1]Endy is now known as Endy |
| 14:14:53 | * | xilo joined #nimrod |
| 14:16:06 | * | Associat0r joined #nimrod |
| 14:16:07 | * | Associat0r quit (Changing host) |
| 14:16:07 | * | Associat0r joined #nimrod |
| 14:19:20 | BitPuffin | EXetoC: okay so I'm just gonna merge, but could you do some trivial change (like add a documentation comment for something |
| 14:19:41 | BitPuffin | EXetoC: and add the unlicense stuff to the commit message |
| 14:22:51 | BitPuffin | "I dedicate any and all copyright interest in this software to the public domain. I make this dedication for the benefit of the public at large and to the detriment of my heirs and successors. I intend this dedication to be an overt act of relinquishment in perpetuity of all present and future rights to this software under copyright law." that stuff |
| 14:25:55 | * | Sergio965 joined #nimrod |
| 14:27:05 | * | Associat0r quit (Quit: Associat0r) |
| 14:48:28 | * | BitPuffin quit (Ping timeout: 264 seconds) |
| 15:01:07 | * | Associat0r joined #nimrod |
| 15:01:07 | * | Associat0r quit (Changing host) |
| 15:01:07 | * | Associat0r joined #nimrod |
| 15:22:31 | * | BitPuffin joined #nimrod |
| 15:25:21 | EXetoC | BitPuffin: adding it now |
| 15:25:40 | BitPuffin | EXetoC: btw I'm switching over to CC0 |
| 15:25:47 | BitPuffin | it's also public domain |
| 15:25:50 | BitPuffin | but it's a bit better written |
| 15:27:25 | BitPuffin | EXetoC: (so your statement will still apply) |
| 15:32:02 | EXetoC | ok |
| 15:32:53 | EXetoC | actually, I'll add it in a couple of hours. |
| 15:33:26 | BitPuffin | EXetoC: okay, tell me when! |
| 15:42:46 | * | BitPuffin quit (Read error: Operation timed out) |
| 16:39:21 | * | Endy quit (Quit: HydraIRC -> http://www.hydrairc.com <- *I* use it, so it must be good!) |
| 17:01:24 | * | DAddYE joined #nimrod |
| 17:08:22 | * | DAddYE_ joined #nimrod |
| 17:09:11 | * | BitPuffin joined #nimrod |
| 17:11:56 | * | DAddYE quit (Ping timeout: 268 seconds) |
| 17:33:28 | * | Associat0r quit (Quit: Associat0r) |
| 17:34:19 | * | DAddYE_ quit (Remote host closed the connection) |
| 17:34:51 | * | DAddYE joined #nimrod |
| 17:50:45 | Araq | BitPuffin: what's wrong with passing 0..N-1 instead of N to a generic matrix? |
| 17:58:09 | EXetoC | it's a start. changing it later won't be that hard, and you can hide some of that with aliases like in the vector module |
| 18:10:40 | EXetoC | BitPuffin: comitting in a minute |
| 18:15:39 | BitPuffin | Araq: it's a bit meh |
| 18:15:52 | BitPuffin | but yeah |
| 18:15:59 | BitPuffin | I might do it just to get started |
| 18:27:12 | EXetoC | there |
| 18:35:31 | NimBot | Araq/Nimrod master 0a9eaf1 Araq [+0 ±5 -0]: 'nimrod pretty' usable |
| 18:56:26 | * | Emmyy joined #nimrod |
| 18:58:06 | Araq | hi Emmyy, welcome |
| 18:58:37 | Emmyy | Hello :) |
| 18:58:41 | BitPuffin | EXetoC: good choice on the tolerance parameter! |
| 18:59:08 | BitPuffin | EXetoC: but why export swizzle characters? |
| 19:02:13 | BitPuffin | Araq: as a temporary workaround. Would it be possible to write a term rewriting parameter that changes the dimension parameter to a vector or a matrix from say N to 0..N-1? That way the public interface would be identical |
| 19:04:14 | EXetoC | maybe someone will need it for some reason. change it if you want |
| 19:07:57 | EXetoC | and when reading the documentation. maybe export it only when nimdoc is defined, at the very least |
| 19:08:25 | EXetoC | nah that would be confusing |
| 19:11:46 | Araq | BitPuffin: values for generics is perhaps 2 weeks off, no need for workarounds |
| 19:17:17 | BitPuffin | EXetoC: hmm, well I guess no one will really use the library until then except for me, and I'll pretty much only use the provided aliases anyways |
| 19:17:21 | EXetoC | maybe just a couple of templates that makes the interface identical |
| 19:17:48 | BitPuffin | EXetoC: I don't really think anyone will need to specify the range |
| 19:17:59 | BitPuffin | EXetoC: not when you can swizzle :P |
| 19:18:54 | BitPuffin | Araq: but anyways, would it be possible? I won't do it, I just want to know if term rewriting macros would be flexible enough |
| 19:22:47 | Araq | I don't think so, TR macros transform code, not declarations |
| 19:47:43 | NimBot | Araq/Nimrod master 3a3ca55 Yury Benesh [+0 ±2 -0]: Fixed libX11, libXrender bindings for macos and linux. |
| 19:47:43 | NimBot | Araq/Nimrod master 7795d2e Yury Benesh [+0 ±4 -0]: Added pkg-config support to xlib, xrender, cairo, cairoxlib |
| 19:47:43 | NimBot | Araq/Nimrod master 096eb6a Yury Benesh [+0 ±2 -0]: Some fixes to xlib wrapper |
| 19:47:43 | NimBot | Araq/Nimrod master 8fc7909 Yury Benesh [+0 ±2 -0]: Fixed XClientMessageEvent struct, added equals operator fot TAtom from unsigned, added xclient union field access proc to XEvent |
| 19:47:43 | NimBot | 4 more commits. |
| 19:48:28 | * | Mat2 joined #nimrod |
| 19:48:30 | Mat2 | hello |
| 19:48:35 | NimBot | Araq/Nimrod master a88ecab EXetoC [+0 ±1 -0]: Add missing SDL symbols. |
| 19:48:35 | NimBot | Araq/Nimrod master 912e613 EXetoC [+0 ±1 -0]: dynlib |
| 19:48:35 | NimBot | Araq/Nimrod master 345155a Araq [+0 ±1 -0]: Merge pull request #530 from EXetoC/master... 2 more lines |
| 19:48:59 | EXetoC | alright! |
| 19:49:03 | EXetoC | Mat2: hi |
| 19:53:13 | Mat2 | hi EXetoC |
| 19:59:24 | NimBot | Araq/Nimrod master 4c9c8f0 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds convenience copyFileWithPermissions to os module. |
| 19:59:24 | NimBot | Araq/Nimrod master f1940fe Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds convenience expandTilde proc around getHomeDir. |
| 19:59:24 | NimBot | Araq/Nimrod master 5e64a40 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Notes kind() getter is used to read TXmlNode.k field. |
| 19:59:24 | NimBot | Araq/Nimrod master d405382 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Adds findAll() convenience procs to xmltree. |
| 19:59:24 | NimBot | 1 more commits. |
| 19:59:39 | Sergio965 | Hi! |
| 19:59:58 | Araq | gah ... so many pull requests ... |
| 20:00:05 | Mat2 | hi Sergio965 and Araq |
| 20:00:56 | Araq | hi Sergio965 and Mat2 |
| 20:01:36 | Sergio965 | HI Mat2 and Araq |
| 20:01:43 | Sergio965 | My name isn't 4 characters. :( |
| 20:01:55 | Sergio965 | Araq: The more pull requests the merrier! |
| 20:02:01 | Mat2 | *g* |
| 20:02:29 | * | Associat0r joined #nimrod |
| 20:02:29 | * | Associat0r quit (Changing host) |
| 20:02:29 | * | Associat0r joined #nimrod |
| 20:03:31 | Araq | well I guess so but I can either fix bugs, work on new features or do code reviews ... |
| 20:05:04 | * | Mat2 added immediate prefetching as optimization for out-of-order architectures with dynamic-register allocation to my compiler |
| 20:07:29 | Araq | Mat2: I think on the fly (G)CSE is easy to do and quite beneficial for any language implementation |
| 20:08:22 | Araq | a jump optimizer is trivial too; loop invariant code motion looks somewhat harder |
| 20:08:31 | Araq | any experience with these? |
| 20:08:41 | EXetoC | hey, you're mixing first and third-person :p |
| 20:08:49 | Sergio965 | loop invariant code motion is pretty sweet. |
| 20:09:20 | BitPuffin | Araq: what'n nimrod pretty? |
| 20:09:23 | Sergio965 | GCSE is pretty easy. |
| 20:09:34 | BitPuffin | hey Mat2! |
| 20:09:43 | Mat2 | Hi BitPuffin |
| 20:09:46 | dom96 | hello everyone |
| 20:09:52 | BitPuffin | o/ dom96 |
| 20:10:03 | Sergio965 | Is that a hand wave? |
| 20:10:06 | BitPuffin | yeah |
| 20:10:09 | dom96 | gah, GCSE is a British thing. |
| 20:10:15 | Sergio965 | ?? |
| 20:10:19 | Sergio965 | British? |
| 20:10:21 | Mat2 | hi dom96 |
| 20:10:23 | BitPuffin | dom96: you mean GCHQ? |
| 20:10:31 | dom96 | Why must you conflate my acronyms? |
| 20:10:41 | Sergio965 | Why must you conflate yourself? |
| 20:10:41 | Sergio965 | :D |
| 20:10:42 | Sergio965 | :o |
| 20:10:44 | Sergio965 | ! |
| 20:10:56 | dom96 | BitPuffin: no |
| 20:10:58 | EXetoC | why are there cat videos on the internet? |
| 20:11:08 | Sergio965 | EXetoC: Why are there cats? |
| 20:11:13 | dom96 | It stands for General Certificate of Secondary Education :P |
| 20:11:18 | BitPuffin | EXetoC: Why are there? |
| 20:11:28 | BitPuffin | EXetoC: Why are? |
| 20:11:32 | BitPuffin | EXetoC: Why? |
| 20:11:33 | Sergio965 | I don't think that's a valid sentence, BitPuffin. |
| 20:11:35 | BitPuffin | EXetoC: ? |
| 20:11:57 | BitPuffin | Sergio965: Depends |
| 20:12:00 | Araq | Sergio965: GCSE is much more important than loop invariant code motion though |
| 20:12:22 | Mat2 | Araq: I have implemented GCSE at the parser level (very Forth related so not common applicable) |
| 20:12:23 | Sergio965 | BitPuffin: The "Why are there?" one. Not sure about the "Why are?" and "Why?" |
| 20:12:48 | Sergio965 | Mat2: At the parser level? That doesn't seem doable…you need data flow analysis. |
| 20:13:06 | Sergio965 | Araq: I agree, but loop invariant code motion is pretty cool. |
| 20:13:35 | Sergio965 | Loop unrolling + GCSE can result in code motion, though. |
| 20:13:41 | Sergio965 | Well, in the equivalent of, I suppose. |
| 20:13:57 | Mat2 | Data flow is known at typing (or parsing) (as written, very Forth related) |
| 20:14:22 | Sergio965 | I suppose it depends on the language. |
| 20:14:31 | Mat2 | yes |
| 20:14:39 | Sergio965 | Not sure how it would work in any language with more than one basic block. |
| 20:15:02 | BitPuffin | Sergio965: :D |
| 20:15:10 | Araq | Sergio965: loop unrolling is irrelevant for a VM |
| 20:15:24 | Sergio965 | Araq: Since when are we talking about VMs?... |
| 20:15:30 | Araq | well I am :P |
| 20:15:42 | Sergio965 | uh. |
| 20:15:49 | Sergio965 | :\ |
| 20:15:56 | Sergio965 | Okay then. :) |
| 20:16:15 | Araq | BitPuffin: what did you use instead of 'len' for vectors again? |
| 20:18:10 | Mat2 | Sergio965: Its doable for dynamic languages though reinterpretation and evaluation (thus can be combined to the process to get the code in a CPS form) |
| 20:19:58 | EXetoC | BitPuffin: plural? |
| 20:20:58 | Sergio965 | Mat2: Sounds you're doing more than "parsing" at that point. |
| 20:25:22 | Mat2 | that's right but I must note that Forth oriented languages are very uncommon in this aspect because parsing can mean state and error check-up, compilation, code-execution, dynamic (re)interpretation and state-modification |
| 20:31:38 | EXetoC | BitPuffin: or what are you getting at? I was just joining in on the randomness |
| 20:31:47 | EXetoC | Sergio965: my sentence? if so, please correct it :> |
| 20:32:50 | Mat2 | anyhow, the whole state of the entire envirionment is always known at every point (at least in my system) |
| 20:34:33 | EXetoC | I should finish my lambda macro some time |
| 20:34:51 | Mat2 | that would be nice |
| 20:38:30 | Mat2 | does Nimrod support closures ? |
| 20:38:40 | EXetoC | yes |
| 20:38:43 | EXetoC | see the closure pragma |
| 20:38:50 | Mat2 | thanks |
| 20:39:53 | dom96 | There is no nice closure syntax though, the do notation fills that gap somewhat. |
| 20:40:21 | EXetoC | ctrl+f ftw :> |
| 20:42:26 | EXetoC | dom96: aren't lvalues implicitly converted? no big deal then |
| 20:43:17 | dom96 | hrm, what do you mean? |
| 20:44:47 | Araq | dom96: come on, don't spread FUD |
| 20:45:03 | Araq | a "nice" closure syntax is a macro away |
| 20:45:28 | Araq | and the syntax that we have is consistent and nice IMO |
| 20:48:21 | * | gradha joined #nimrod |
| 20:49:15 | EXetoC | dom96: the right-hand side of assignments. proc literals seems to be implicitly convertible to closures |
| 20:50:07 | dom96 | Araq: I will believe it when I see it. So you won't introduce any nice shorthand for closures anymore? |
| 20:51:13 | Araq | dom96: that is correct |
| 20:52:01 | Araq | there will be built-in \ macro instead |
| 20:52:26 | dom96 | EXetoC: I would love some syntax sugar, so that instead of writing: proc (x, y: int): int = x + y; I can write: x, y => x + y; or something similar. |
| 20:52:27 | EXetoC | I might be wrong. are nested procedures closures? |
| 20:52:42 | Araq | EXetoC: depends onto wether they capture variables |
| 20:52:51 | EXetoC | ok |
| 20:53:56 | EXetoC | it seems like you can't capture parameters of an outer function though |
| 20:54:00 | EXetoC | or maybe they have to be vars |
| 20:54:39 | EXetoC | no, they are |
| 20:54:42 | dom96 | Araq: I can't say that I am looking forward to that anymore. But I will complain once I can determine whether I hate the macro or not :P |
| 20:54:51 | dom96 | gradha: yo |
| 20:55:00 | gradha | yo |
| 20:55:06 | dom96 | gradha: Still want to add that feature to nimbuild? |
| 20:55:11 | EXetoC | dom96: \(...) is what he suggested |
| 20:55:12 | gradha | yes |
| 20:56:35 | dom96 | gradha: Here is how it should be done: make the tester generate a .json file that nimbuild can read, make the .json file end up in the same dir as the testresults.html file, write some nice code to read 2 .json files and render a diff to the user. |
| 20:59:19 | EXetoC | \(x, y, x + y). he might've suggested \(x + y) too, which would look for single-letter identifier or something like that |
| 21:00:07 | dom96 | why not: \x, y (x + y); actually that looks odd. |
| 21:00:12 | dom96 | When did he suggest this? |
| 21:00:59 | EXetoC | when I asked about it a couple of weeks ago |
| 21:01:36 | EXetoC | dom96: how would that work? using TR macros or something? |
| 21:01:51 | dom96 | EXetoC: probably wouldn't. |
| 21:03:20 | Araq | indeed I suggested \(x + y) |
| 21:03:34 | Araq | it's even shorter than Haskell so it must be good |
| 21:05:04 | dom96 | I don't see how that can work. |
| 21:05:38 | EXetoC | why not? |
| 21:06:03 | dom96 | var x = 5; \(x + y) # do I want the global 'x' or does my closure take two params? |
| 21:06:09 | Mat2 | \(x + y) -> \x.\y.x+y ? |
| 21:06:27 | Araq | dom96: takes 2 params of course :P |
| 21:06:46 | Araq | var xx = 5; \(xx +y) # takes 1 param, captures xx |
| 21:07:08 | dom96 | what? |
| 21:07:14 | Mat2 | ah ok |
| 21:07:21 | dom96 | it's whitespace sensitive? |
| 21:07:40 | EXetoC | no, identifier length |
| 21:10:32 | dom96 | Why? Because we don't scare away enough users thanks to SI? |
| 21:11:06 | Mat2 | sorry, what means SI ? |
| 21:11:10 | * | gradha quit (Quit: bbl, need to watch https://www.youtube.com/watch?v=1ZZC82dgJr8 again) |
| 21:11:15 | dom96 | style insensitivity. |
| 21:11:32 | EXetoC | how is that scary? can't you have a more verbose overload as well? |
| 21:11:38 | DAddYE | (x, x: int) do -> int: x + y |
| 21:11:52 | DAddYE | do (x, x: int) -> int: x + y |
| 21:11:57 | DAddYE | not sure which is correct |
| 21:12:13 | Mat2 | I see no problems out of SI, sorry |
| 21:12:28 | Araq | DAddYE: do (x, y: int) -> int: x + y |
| 21:12:39 | dom96 | AFAIK do notation only works when the last param of your proc expects a closure. |
| 21:12:46 | EXetoC | Mat2: most programmers don't want change |
| 21:13:19 | Araq | dom96: you want \ for a really short notation, I don't see the problem |
| 21:13:40 | Araq | what is it these days that people complain they get what they asked for? |
| 21:13:48 | Mat2 | change is essential to live because life means change |
| 21:13:49 | EXetoC | people in general don't |
| 21:13:59 | dom96 | I certainly didn't ask for this. |
| 21:14:27 | dom96 | What's wrong with Haskell's syntax? |
| 21:14:50 | dom96 | Let me guess, it's not possible with macros. |
| 21:14:55 | Araq | nimrod is not haskell and I'm sick and tired of ever more special cases in the syntax |
| 21:15:15 | Araq | we can do \(x, y, x + y) though easily with a macro |
| 21:15:21 | Sergio965 | Haskell is amazing. |
| 21:16:19 | Mat2 | if we talk about syntax dialects, why not considering ML ? |
| 21:16:31 | DAddYE | Mat2: ruby |
| 21:16:32 | DAddYE | hahah |
| 21:16:45 | Sergio965 | Ruby. Ruby is amazing, too. |
| 21:16:59 | Sergio965 | Every. Language. Is. Amazing. ELIA. |
| 21:17:10 | Mat2 | DAddye: Brainfuck |
| 21:17:12 | Sergio965 | ELIA Language Is Amazing |
| 21:17:16 | dom96 | Araq: I would prefer that. |
| 21:17:17 | Sergio965 | Boom. |
| 21:17:39 | Araq | dom96: fine then |
| 21:17:54 | EXetoC | so not both then? |
| 21:17:58 | Araq | I think it's stupid to stop half way at a short notation, but *shrug* |
| 21:17:58 | dom96 | Araq: But I don't understand why you changed your mind. |
| 21:18:00 | EXetoC | oh well, it's still short |
| 21:18:20 | EXetoC | Araq: I agree |
| 21:19:44 | Araq | maybe we should do \(\x + \y) for auto-declaration of x,y :P |
| 21:19:57 | Araq | nah, bad for nesting lambdas |
| 21:21:26 | BitPuffin | Araq: for length of strings when swizzling, and array length |
| 21:21:55 | BitPuffin | EXetoC: well it was just random |
| 21:22:08 | DAddYE | sorry I'm retarded but what is \() this purpose? |
| 21:23:08 | EXetoC | it's short |
| 21:23:21 | Associat0r | ML syntax has some legacy cruft |
| 21:23:40 | EXetoC | any kind of lambda syntax would encourage composition |
| 21:24:17 | dom96 | Araq: IIRC you said you would implement something along the lines of: \x, y => x + y. I still like that syntax a lot. |
| 21:24:40 | Araq | I said I would implement (x, y :: x + y) |
| 21:24:53 | BitPuffin | EXetoC: ctrl+f? |
| 21:24:57 | BitPuffin | ah |
| 21:24:59 | BitPuffin | search? |
| 21:25:02 | EXetoC | ya |
| 21:25:12 | EXetoC | and grep :> |
| 21:25:21 | Mat2 | Associat0r: Yes but it have two strong variants: Caml and most important: F# |
| 21:26:48 | Associat0r | which still somewhat suffer from the cruft |
| 21:27:17 | Mat2 | ok, please be more precise ! |
| 21:28:00 | Associat0r | well tuple types vs tuple values |
| 21:28:53 | Araq | dom96: any syntax without explicit () is doomed for lambdas IMO, it quickly becomes unreadable, precedences become unclear |
| 21:30:11 | Associat0r | Discriminated Union data ctors that only exist in tupled form |
| 21:30:14 | dom96 | Araq: I think you should still implement that syntax. |
| 21:30:23 | Araq | dom96: which one? |
| 21:30:32 | dom96 | Araq: (x, y :: x + y) |
| 21:30:38 | Associat0r | there is some more |
| 21:31:41 | Mat2 | Associat0r: The type system of ML is eager evaluated as most more common programming languages |
| 21:32:03 | Associat0r | Mat2: yes |
| 21:32:13 | Associat0r | what does this have todo with it? |
| 21:33:05 | Associat0r | Idris and Elm don't suffer from it and are eager too |
| 21:34:29 | Araq | dom96: for marketing a non-builtin lambda seems way better ;-) |
| 21:35:11 | Araq | everybody loves a small core + macros as the overwhelming language design |
| 21:35:33 | Araq | well everybody who thinks macros are a good idea anyway |
| 21:36:03 | Mat2 | ML handles that strict in the sense that the type alone depends state (or state-less). For the F# compiler that is of advantage for efficient usage of the NET environment (the vm.inherent type system) |
| 21:37:25 | Mat2 | I think taht is one reason for choosing ML as 'inspiration' for creating F# |
| 21:37:38 | Associat0r | Mat2: btw why aren't you in ##fsharp? |
| 21:37:40 | BitPuffin | wait what's wrong with haskell, haskell is freaking spectacular :D |
| 21:37:59 | Associat0r | haskell's records are broken |
| 21:39:53 | Mat2 | Associat0r: I do not want to be limited to the NET framework (or its open-source equivalent Mono) |
| 21:40:23 | Associat0r | Mat2: well it's just a runtime |
| 21:41:13 | BitPuffin | Associat0r: but it's also very spectacular |
| 21:41:22 | Mat2 | its one way to rule them all, no thanks |
| 21:41:43 | BitPuffin | Mat2: yeah that's wise |
| 21:42:00 | Associat0r | BitPuffin: Idris is way more spectacular |
| 21:42:34 | Associat0r | Mat2: how do you mean? |
| 21:43:56 | BitPuffin | Associat0r: never heard of it, link? |
| 21:44:24 | * | OrionPK joined #nimrod |
| 21:44:32 | Associat0r | BitPuffin: http://www.idris-lang.org/ |
| 21:44:35 | Mat2 | the NET framework is so special designed, that is onbly fit well to x86 based systems (not to forget Micro$oft operating systems) |
| 21:44:47 | Mat2 | ^only |
| 21:45:07 | BitPuffin | Associat0r: why is it better than haskell? |
| 21:45:25 | Associat0r | BitPuffin: dep types, eager eval, fixed records |
| 21:45:54 | Associat0r | BitPuffin: better syntax for type annotations |
| 21:46:15 | Associat0r | better user definable sugar for DSLs |
| 21:46:20 | Associat0r | and lots more |
| 21:46:30 | BitPuffin | Associat0r: how's performance? |
| 21:46:43 | BitPuffin | Associat0r: does it have a project like cloud haskell? That is like erlang |
| 21:46:45 | dom96 | Araq: From a marketing standpoint a broken implementation, or an implementation which the majority sees as being broken, will cause problems. |
| 21:47:06 | Associat0r | it's designed to have better perf than Haskell |
| 21:47:23 | BitPuffin | Associat0r: Hmm |
| 21:47:32 | Associat0r | BitPuffin: it's still in development |
| 21:47:45 | BitPuffin | Associat0r: anything like yesod for it? |
| 21:47:57 | Associat0r | not sure |
| 21:48:35 | Associat0r | Mat2: I don't think it's true |
| 21:48:52 | EXetoC | make everything a class, and then just market away |
| 21:50:19 | Araq | dom96: not if there are alternative implementations all broken in different ways :-) |
| 21:50:41 | Araq | that's the secret mojo of Perl and C++ |
| 21:51:58 | Mat2 | Associat0r: Well I would hope to be wrong but ... it's an Microsoft invitation, right ? |
| 21:54:10 | Mat2 | that's these corporation which included a check routine just for pushing up a warning message in Win 3.1 when executed with DR-DOS |
| 21:55:17 | Araq | yeah this evil corporation which produces OSes that continue to run my old software ... |
| 21:55:48 | Araq | it's as if they understand what the purpose of an OS is ... running software |
| 21:56:03 | Mat2 | (and informing the user to proceed by pressing F2 loading Win95 if no keyboard was attached) |
| 21:57:20 | Mat2 | Araq: right |
| 21:57:44 | Mat2 | for this purpose there exist emulators |
| 21:58:02 | Araq | and yet wine never works for me |
| 21:58:36 | EXetoC | surprising, huh |
| 21:58:51 | Araq | ok, sometimes it does but often it doesn't |
| 21:58:59 | Araq | I guess I play too uncommon games |
| 21:59:26 | Mat2 | Araq: Wine configuration is not easy |
| 21:59:37 | EXetoC | I've been able to play morrowind and half-life |
| 22:00:54 | * | DAddYE_ joined #nimrod |
| 22:01:06 | Associat0r | Araq: what about VMs? |
| 22:01:09 | EXetoC | it seems like it has improved quite a lot the last couple of years. I still don't really bother though |
| 22:01:20 | Associat0r | Araq: is the perf there yet? |
| 22:03:02 | Araq | Associat0r: I don't think so, my XP is quite slow under virtualBox |
| 22:04:34 | * | DAddYE quit (Ping timeout: 256 seconds) |
| 22:05:19 | Araq | with the PFoo() constructor syntax TFoo.new seems quite redundant and confusing, should we deprecate it? |
| 22:05:50 | Araq | note that TFoo.new returns a 'ref TFoo' but 'new(x)' takes a 'ref TFoo' |
| 22:06:15 | Araq | so var x = TFoo.new is the same as var x: PFoo; new(x) |
| 22:07:05 | Mat2 | time for some sleep, ciao |
| 22:07:13 | Araq | bye Mat2 |
| 22:07:22 | * | Mat2 quit (Quit: Verlassend) |
| 22:13:06 | dom96 | perhaps |
| 22:13:18 | dom96 | If PFoo has some fields, is PFoo() allowed? |
| 22:13:37 | Araq | yeah unless they need to be initialized |
| 22:13:46 | Araq | like 'not nil' fields |
| 22:14:55 | dom96 | hrm, didn't I mention a case where it complained when I tried to construct an object without specifying any fields? |
| 22:15:47 | dom96 | well I can't remember |
| 22:16:42 | NimBot | Araq/Nimrod master c14a0e5 Araq [+0 ±2 -0]: fixes #532 |
| 22:17:04 | Araq | dom96: yeah but range[1..x] needs to be initialized too |
| 22:17:13 | Araq | and I think you stumbled upon that |
| 22:17:25 | Araq | TTimeInfo is affected by this too |
| 22:18:58 | dom96 | why not just allow default for that? |
| 22:19:09 | Associat0r | Araq: what kind of CPU do you have? |
| 22:19:16 | dom96 | for range that would be '1' in that cas.e |
| 22:19:18 | dom96 | *case |
| 22:19:46 | Araq | dom96: that's lots of work for a minor feature |
| 22:22:34 | dom96 | fair enough |
| 22:22:52 | Araq | Associat0r: Intel Core 2 Quad 2.5 Ghz |
| 22:23:50 | * | DAddYE_ quit (Remote host closed the connection) |
| 22:24:14 | EXetoC | what has bothered me the most I think is the inability to create anonymous instances of 'var' |
| 22:24:22 | * | DAddYE joined #nimrod |
| 22:24:25 | Associat0r | Araq: that didn't have hardware virtualization right? |
| 22:25:11 | EXetoC | Associat0r: it's a performance feature as well? I tried to find out, but it's never mentioned |
| 22:26:00 | Associat0r | o it has http://en.wikipedia.org/wiki/Intel_Core_2#Models |
| 22:26:29 | Araq | yeah but I run an old version of vitualbox, maybe it doesn't use it |
| 22:27:01 | Araq | 4.1.18 |
| 22:27:27 | EXetoC | reading up on it now. it might just be that the difference was negligible on early implementations |
| 22:27:37 | Araq | hmm not that old |
| 22:27:41 | Associat0r | https://news.ycombinator.com/item?id=6134424 |
| 22:27:55 | EXetoC | yeah I know |
| 22:28:40 | EXetoC | I don't need to optimize for speed though, so I can just omit 'var' in many cases |
| 22:28:42 | Associat0r | Nimrod could use a mention |
| 22:30:55 | dom96 | Associat0r: Why don't you mention it then? |
| 22:33:33 | Associat0r | I'm not intimately familiar with the lang yet |
| 22:34:08 | Associat0r | same reason that I never mention Rust on HN or reddit |
| 22:37:33 | Araq | everybody always mentions Rust anyway |
| 22:38:23 | Associat0r | Araq: btw are you gonna address null some day? |
| 22:38:50 | Araq | in my reality the compiler implements full "not nil" checking in git HEAD, Associat0r |
| 22:39:10 | Araq | effectively making the type system control flow based |
| 22:39:25 | Araq | it's pretty cool :P |
| 22:39:27 | Associat0r | Araq: I mean no nil by default |
| 22:40:12 | Araq | breaks every wrapper and I'm not sure it's the right default |
| 22:40:35 | Araq | Nimrod is not Java where you use references everywhere |
| 22:41:01 | Araq | when you use 'ref' you likely create some graph like structure where 'nil' is a valid value |
| 22:41:52 | Araq | and algebraic data types instead often end up using a few more bytes |
| 22:43:51 | NimBot | Araq/Nimrod master 6e3a517 Dominik Picheta [+0 ±1 -0]: Improved documentation for macros.newProc. |
| 22:44:32 | NimBot | Araq/Nimrod asyncmacro 3a3ca55 Yury Benesh [+0 ±2 -0]: Fixed libX11, libXrender bindings for macos and linux. |
| 22:44:32 | NimBot | Araq/Nimrod asyncmacro 7795d2e Yury Benesh [+0 ±4 -0]: Added pkg-config support to xlib, xrender, cairo, cairoxlib |
| 22:44:32 | NimBot | Araq/Nimrod asyncmacro 096eb6a Yury Benesh [+0 ±2 -0]: Some fixes to xlib wrapper |
| 22:44:32 | NimBot | Araq/Nimrod asyncmacro 8fc7909 Yury Benesh [+0 ±2 -0]: Fixed XClientMessageEvent struct, added equals operator fot TAtom from unsigned, added xclient union field access proc to XEvent |
| 22:44:32 | NimBot | 31 more commits. |
| 22:45:25 | Associat0r | I see |
| 22:47:01 | Araq | also I think this whole "not null" thing is vastly overblown, proving array indexes correct is also a "solved problem" |
| 22:47:39 | Araq | and yet nobody thinks it needs to be done at compile time or you're stuck in the 80ies |
| 22:47:55 | Associat0r | I don't think it's overblown at all |
| 22:48:55 | Associat0r | needlessly checking for null is boilerplate |
| 22:48:58 | Associat0r | and error prone |
| 22:49:31 | Associat0r | also when something is nullable I want to be forced to check for it |
| 22:49:37 | Araq | well don't check then, let it crash instead |
| 22:49:58 | Araq | I don't want to be forced to check for it |
| 22:50:20 | Araq | often it's not-null due to some very complex invariant |
| 22:50:36 | Araq | that I can't express in the type system |
| 22:50:39 | Associat0r | but why let it crash if it's not supposed to be valid value at all and can be easily prevented |
| 22:51:17 | Araq | so what do you instead? if (x == null) throw new InvalidArgumentException() ? |
| 22:51:40 | Araq | let it crash is Erlang's secret for robustness :P |
| 22:52:42 | Associat0r | null would be None and I would check it with a combinator like getOrElse or pattern match over it |
| 22:52:53 | Associat0r | if I forget about it I would get a compile-time error |
| 22:53:12 | Araq | yeah sure |
| 22:53:35 | Associat0r | if it's not supposed to be null, I wouldn't have to throw an exception |
| 22:54:22 | Associat0r | well not an exception related to null anyway |
| 22:54:28 | Araq | an AST node has an optional type node |
| 22:54:44 | Araq | now check for node.typ != null everywhere in your compiler |
| 22:54:54 | Araq | and tell me it's not annoying and you end up with |
| 22:55:43 | Araq | match node.typ { |
| 22:55:50 | Associat0r | with a combinator it's not annoying |
| 22:55:51 | EXetoC | the "extraction" part doesn't have to be very verbose though |
| 22:55:57 | Araq | None: InternalError("..."); |
| 22:56:07 | Araq | Some(x): < logic here> |
| 22:56:07 | Associat0r | the combinator is supposed to abstract the explicit matching |
| 22:56:09 | Araq | } |
| 22:56:48 | Araq | right the combinator |
| 22:57:00 | Associat0r | also if you don't check for it and it is null in your case it would crash at runtime instead |
| 22:57:12 | Araq | does that happen to involve lots of expensive closures? |
| 22:57:28 | Araq | yeah, it'll crash instead |
| 22:57:38 | Associat0r | doesn't have to be expensive |
| 22:57:40 | EXetoC | x.unwrap() |
| 22:57:43 | Araq | big deal, I'll get a stack trace anyway |
| 22:57:47 | Araq | and fix it |
| 22:57:58 | Araq | same for the internalError() |
| 22:58:40 | Associat0r | well it's a typed language why not leverage the type system? |
| 22:59:03 | Araq | because the type system is not nearly expressive enough for this? |
| 22:59:12 | Araq | unfortunately |
| 23:09:39 | Araq | good night |
| 23:09:46 | EXetoC | so a tagged union is no good? such verbose matches can be abstracted away |
| 23:09:48 | EXetoC | bye |
| 23:10:05 | Associat0r | GN |
| 23:13:36 | BitPuffin | btw Araq, wayland has a stable api now, maybe it's time to add a wrapper for it :) |
| 23:19:49 | EXetoC | !? a.intersects(b) |
| 23:19:58 | EXetoC | abstracting shit is fun in expressive languages :> |
| 23:20:44 | dom96 | Are you guys doing the upcoming Ludum Dare? |
| 23:22:14 | EXetoC | nah |
| 23:22:30 | dom96 | aww why not? |
| 23:24:45 | EXetoC | well, I prefer to re-invent the wheel, and my wheel is fairly square-shaped atm |
| 23:26:12 | dom96 | I would like to try it again, and if someone else competed using Nimrod too it would boost my motivation :P |
| 23:26:58 | * | Sergio965 quit (Read error: Operation timed out) |
| 23:33:39 | dom96 | good night |
| 23:34:47 | EXetoC | someone else then maybe. I'm not a good candidate :> |
| 23:34:50 | EXetoC | bye |
| 23:41:35 | BitPuffin | dom96: I could participate, but I have to work on my real project(s) |