| 00:06:50 | Araq | good night |
| 00:09:15 | * | freezerburnv quit (Quit: freezerburnv) |
| 00:12:02 | * | filwit joined #nimrod |
| 00:12:11 | flaviu1 | Well, it turns out its actually LGPL, and the code is written in Javascript, not python, but the general idea is the same |
| 00:13:06 | filwit | yeah. Personally i wish comments where just not part of the AST, but whatever, will take it |
| 00:14:03 | EXetoC | they won't be for long |
| 00:14:36 | flaviu1 | No one seems to be considering having the AST be reversible fully into code. |
| 00:15:14 | flaviu1 | Beyond a certain pass, yeah, comments and other formatting information could be stripped. But they should start out as part of the AST |
| 00:16:38 | filwit | it's just annoying to have to be care with their indentation |
| 00:16:49 | filwit | plus, it breaks this sort of thing... |
| 00:16:53 | filwit | # does something |
| 00:16:58 | filwit | if condition: |
| 00:16:59 | filwit | ... |
| 00:17:05 | filwit | # does something else |
| 00:17:08 | filwit | else: |
| 00:17:09 | filwit | ... |
| 00:17:10 | * | Demos joined #nimrod |
| 00:17:16 | EXetoC | I'm mostly annoyed by the fact that you can't comment out a field for example without moving said line |
| 00:17:29 | filwit | ^ yeah exactly |
| 00:17:39 | * | brson joined #nimrod |
| 00:18:22 | filwit | i just the the only positives or AST comments are very obscure at best, and probably better suited a pragma anyways |
| 00:18:33 | flaviu1 | That's unrelated to having comments in the AST, that could be done in another way |
| 00:19:20 | filwit | sure, but it's kinda a waist of effort at this point to have comments part of the AST for reasons no one currently cares about |
| 00:19:29 | * | brson_ quit (Ping timeout: 264 seconds) |
| 00:20:10 | filwit | i mean, it could be nice for some IDE rendering (where comments get folded and stuff appropriately) |
| 00:20:38 | flaviu1 | Maybe, but the entire point of Roslyn is to basically have a reversible AST and to use it for tooling. Say, renaming all instances of a variable could be done fairly easily. |
| 00:21:24 | filwit | yeah actually i supposed that makes some sense |
| 00:21:52 | filwit | but you could probably do such things without AST comments and still not damage most of the comments. |
| 00:22:14 | flaviu1 | Well, the thing is that nimrod tries to be very clever with its comments |
| 00:22:21 | filwit | i guess refactoring a lot of code around would be a problem without them tho |
| 00:23:33 | flaviu1 | So it groups comments together, and when it can't do so reasonably, it gives up and throws an error out. |
| 00:28:06 | * | nande quit (Remote host closed the connection) |
| 00:37:56 | * | perturbation joined #nimrod |
| 00:37:59 | filwit | in markdown, can you have image links? |
| 00:38:05 | filwit | guess i should google... |
| 00:40:13 | * | bjz joined #nimrod |
| 00:44:34 | filwit | yep, it works. Added screenshots to the Kate repo, flaviu1 |
| 00:44:47 | * | bjz quit (Ping timeout: 260 seconds) |
| 00:45:00 | filwit | this is going to bug me though... i need one more color to make them even (damn you OCD!) |
| 00:45:25 | filwit | oh well, good for now |
| 00:45:59 | filwit | oh you already sent the PR, cool |
| 00:48:15 | filwit | flaviu1: merged your PR. Please update the Install text with instructions on where to place the file (just copy my formatting please) |
| 00:52:12 | filwit | flaviu1: nevermind, i'm updating the readme anyways, i'll add it |
| 00:55:22 | filwit | probably need to softlink the repo files instead of telling people to copy them anyways |
| 01:00:58 | flaviu1 | I was away grabbing something to eat |
| 01:01:57 | flaviu1 | Colors look very nice, I'll update the readme |
| 01:03:52 | filwit | k, thanks |
| 01:05:10 | flaviu1 | Ok, sent |
| 01:08:31 | filwit | merged. thanks |
| 01:15:37 | * | bjz joined #nimrod |
| 01:15:41 | * | Jesin quit (Ping timeout: 255 seconds) |
| 01:19:55 | * | brson quit (Quit: leaving) |
| 01:20:11 | * | brson joined #nimrod |
| 01:21:14 | filwit | flaviu1: i like that, in your NimByExample, you use `of` instead of commas to indicate derivative types.. but why do you put () brackets around that, and not around half your function calls in other examples? |
| 01:21:56 | * | saml_ joined #nimrod |
| 01:22:23 | filwit | `class Animal of TObject: ...` feels much more like C++/C#/Java/etc than `class(Animal of TObject): ...` |
| 01:26:06 | filwit | also, why do you pull reference off the callsite vs pass them is as parameters (eg `macro class(head:expr, body:stmt)`) |
| 01:26:10 | filwit | ? |
| 01:27:51 | * | Jesin joined #nimrod |
| 01:47:04 | * | q66 quit (Quit: Leaving) |
| 01:51:44 | * | brson quit (Ping timeout: 276 seconds) |
| 01:52:19 | Demos | filwit: I am pretty sure the parens are something pascal programmers will recognise |
| 01:53:03 | filwit | Demos: which is a much small group of potential viewers than the Java/C#/C++ group |
| 01:53:22 | Demos | are there any plans to remove doc comments (##s) from the AST? I thought there were not |
| 01:53:47 | Demos | filwit: yeah, I did not actually know you could do class(T of B) until you said it, but I was pointing out where it comes from |
| 01:53:50 | filwit | no, doc comments need to be part of th AST |
| 01:54:06 | filwit | Demos, i see |
| 01:54:53 | * | brson joined #nimrod |
| 01:54:55 | * | noam quit (Read error: Connection reset by peer) |
| 02:03:11 | * | hoverbear joined #nimrod |
| 02:15:49 | * | BitPuffin quit (Ping timeout: 252 seconds) |
| 02:42:58 | * | dLog quit (Read error: Connection reset by peer) |
| 02:43:58 | * | dLog joined #nimrod |
| 02:52:42 | * | Skrylar joined #nimrod |
| 03:13:35 | flaviu1 | filwit: Sorry, I was away again |
| 03:13:44 | flaviu1 | That actually isn't my code, that's fowl's |
| 03:14:07 | filwit | np. ah, okay |
| 03:15:20 | flaviu1 | I'm adding comments in the markdown to indicate contributors, but should probably find a better way to do that |
| 03:15:45 | * | def- joined #nimrod |
| 03:16:01 | flaviu1 | Yeah, I also thought that the ting with parameters was a bit weird |
| 03:16:36 | flaviu1 | I might change that, but I haven't found time so far |
| 03:17:19 | filwit | there's also an optimization/code-simplification you can do to the OOP macros with getAst() for generating the type nodes |
| 03:18:04 | filwit | anyways, i'll clean it up and gist it, see what fowl says about it |
| 03:18:28 | flaviu1 | Ok, thanks. I'm not really familiar with this particular way of using macros |
| 03:19:20 | * | def-_ quit (Ping timeout: 252 seconds) |
| 03:41:02 | * | Varriount_ joined #nimrod |
| 03:42:30 | * | Varriount quit (Ping timeout: 258 seconds) |
| 03:46:03 | * | perturbation quit (*.net *.split) |
| 03:46:03 | * | vendethiel quit (*.net *.split) |
| 03:46:04 | * | flaviu1 quit (*.net *.split) |
| 03:46:06 | * | Xuerian quit (*.net *.split) |
| 03:46:12 | * | vendethiel joined #nimrod |
| 03:46:13 | * | Xuerian joined #nimrod |
| 03:46:27 | * | perturbation joined #nimrod |
| 03:46:52 | * | flaviu1 joined #nimrod |
| 03:52:17 | * | brson quit (Ping timeout: 255 seconds) |
| 03:58:22 | * | krusipo joined #nimrod |
| 04:00:32 | * | krusipo_ quit (Remote host closed the connection) |
| 04:06:07 | * | nande joined #nimrod |
| 04:20:41 | fowl | flaviu1, the full macro would have more options like not forcing ref types, the parameter parsing section is there to be expanded on |
| 04:21:57 | flaviu1 | I don't really like how the parameters are obtained in the way they are, I think the code might be cleaner if it just took an `stmt` as a parameter |
| 04:22:23 | fowl | i was trying to keep the body of the macro short for the example, it can get big quick though |
| 04:23:19 | fowl | flaviu1, nvm, im tripping |
| 04:23:54 | Demos | are working on the OOP macro? |
| 04:24:38 | flaviu1 | fowl gave me a macro to use, and filwit thinks that it could be made better with some changes |
| 04:24:40 | flaviu1 | http://flaviut.github.io/nimrod-by-example/oop_macro.html |
| 04:24:45 | fowl | flaviu1, i was thinking about clibpp's class macro, now that im looking at it i dont see how this can be simplified, the superclass needs to be extracted |
| 04:25:52 | flaviu1 | If he simplifies it, I'll merge it. I'm not familiar with this problem though, so I can't really comment |
| 04:26:06 | filwit | flaviu1, fowl: i modified the OOP stuff. I took some liberties, so this is just more of "how i would write it": https://gist.github.com/PhilipWitte/56a2e702a9b6e17feb3a |
| 04:26:33 | Demos | does it generate vtables? |
| 04:26:37 | fowl | filwit, you use weird capitalization |
| 04:26:47 | fowl | NnkProcDef |
| 04:26:56 | filwit | fowl, yeah, mostly cause of my syntax highlighting makes PascalCase look different |
| 04:27:01 | * | saml_ quit (Quit: Leaving) |
| 04:27:18 | flaviu1 | That's a bit odd, but I can fix it before merging. |
| 04:27:25 | filwit | but also cause i prefer "const values" as Capitals (i also capitalize module names) |
| 04:28:18 | filwit | flaviu1, fowl, either way, not saying my style is better or anything.. just that it should be consistent (and there was some odd stuff in your OOP macro, fowl, like the callsite thing) |
| 04:28:33 | fowl | filwit, i dont think this `result[0][0][2][0][2] = recList` is very appealing, it looks nicer when you build it as a tree |
| 04:29:11 | filwit | yeah i was going to explain that, but thought your node-tree comment did a good job of explaining what was going on |
| 04:29:34 | filwit | mostly it's about optimization. getAst should be faster i believe |
| 04:29:39 | flaviu1 | The tree building is nice, but I wasn't really a fan of the big if expression in the middle |
| 04:29:49 | fowl | filwit, i used to do that in macros but its hard to tell whats going on when you look at it later |
| 04:30:19 | flaviu1 | I don't like the templates, maybe we could show off quasiquotes? |
| 04:30:23 | fowl | filwit, optimizing at compiletime, sure |
| 04:30:27 | filwit | here, i also made a version without the proto stuff, but combining your trees.. one sec |
| 04:30:40 | filwit | i agree, it's too confusing for newbs |
| 04:30:56 | Demos | again, does it generate vtables or use nimrod's multimethods |
| 04:31:10 | flaviu1 | Demos: it uses standard methods |
| 04:31:22 | flaviu1 | like the `method` keyword, so whatever that implies |
| 04:31:33 | Demos | then I think hiding the self param is very strange, since it is no different from any other param. |
| 04:31:49 | Demos | anyway I was hoping that it could be ABI compatible with COM |
| 04:31:50 | filwit | k i updated the gist |
| 04:31:56 | flaviu1 | But the primary goal here is to be accessible for learning, not much else |
| 04:32:12 | Demos | yeah I understand, but I am concerned that it may have strange behavior |
| 04:32:33 | filwit | Demos, injecting the self param is part of the convenience of OOP stuff really |
| 04:32:38 | Demos | who knows though. Also the whole "Nimrod by example" website/tutorial looks really nice |
| 04:33:13 | filwit | flaviu1, fowl: i updated the gist without the proto stuff. But i combined your two tree building parts |
| 04:33:24 | flaviu1 | Demos: Thanks, but I'm switching to another generator so the appearance will change |
| 04:33:28 | Demos | filwit: yeah, that is true, but the reason methods go "inside" classes is because of the vtable |
| 04:33:39 | filwit | flaviu1, fowl: again, just "my version". take what you want from it |
| 04:33:39 | Demos | I meant the content |
| 04:34:03 | flaviu1 | filwit: I think I'll take everything, but use quasiquotes. Those are the cleanest way to do things |
| 04:34:48 | filwit | Demos: no it's about encapsulating conceptual concept, not just technical aspects of dynamic dispatch |
| 04:35:06 | fowl | did you change "self" to "this" |
| 04:35:07 | filwit | flaviu1: not a bad idea |
| 04:35:20 | filwit | fowl: yeah sorry, lol |
| 04:35:31 | Demos | well I like that self is seperate, but then again I think java style objects do way to much for one construct |
| 04:35:33 | flaviu1 | fowl: Seems like it, probably to resonate better with Java people |
| 04:35:43 | filwit | fowl: but honestly i think 'this' will "speak to more people" (because of the popularity of Java/C++/C#) |
| 04:35:53 | fowl | w/e |
| 04:36:04 | Demos | anyway. The macro is a really good demonstration of nimrod's macro system. And it would be even better if it generated vtables |
| 04:36:09 | Demos | :D |
| 04:36:41 | filwit | Demos, Nimrod's methods are better than VTables :P |
| 04:37:06 | filwit | i think once Araq give's them another "once over" they will probably out-perform VTables |
| 04:37:14 | Demos | this is true, except that if you generate vtables then you can use the sugar provided by the macro to interop with COM and GObject |
| 04:37:24 | Demos | I don't doubt it |
| 04:37:58 | Demos | although I suspect that they are more "global" than vtbls, anyway I am not interested in using vtbls because of technical issues, I am interested in them for interop |
| 04:38:44 | Demos | writing code that is like obj.lpvtbl.DoSomething(obj, cast[ptr base](someOtherObject)) gets old sometimes |
| 04:39:17 | Demos | although I dont really write code like that it is what I am seeing when I go and write examples/tests for the Direct3D wrapper |
| 04:39:26 | filwit | flaviu1: i changed all the `things.add item` to `things.add(item)`.. which is just my preference, but either way, I think the demo should attempt to follow a standard with most calls, at least of a similar type (aka, `add(item)` should be consistent everywhere, but `echo ".."` is just fine too) |
| 04:39:26 | fowl | Demos, in c++ i used generic types for base classes |
| 04:39:49 | Demos | CRTP? |
| 04:40:19 | fowl | Demos, ie, type Shape = CircleShape|RectangleShape|ConvexShape |
| 04:40:31 | Demos | that is a bit of an orthogonal issue (lets forget about dependent base classes and specializations for now |
| 04:40:37 | filwit | flaviu1, fowl: i know it's kinda "nimrod's way" to be style insensitive (which i agree with).. but for a demo, it's probably less confusing if things are similar throughout. Should probably have a slide which talks about how things can work either way though. |
| 04:40:43 | Demos | fowl: that is not c++ code |
| 04:40:56 | fowl | Demos, sry, for c++ interop |
| 04:41:36 | Demos | yeah, I am just casting for now. Also that generates more code than casting I think |
| 04:42:03 | fowl | Demos, nah, the functions are importcpp'd, no code is generated |
| 04:42:10 | filwit | Demos: override the `.` operator and attempt to find symbols on the VTable before throwing an error. |
| 04:42:49 | filwit | though that sounds like a bit of overkill really |
| 04:42:55 | Demos | yeah that would work to avoid the .lpvtbl thing, but I do not want to do it /in/ the wrapper |
| 04:43:02 | filwit | macros which generate appropriate symbols probably would work better really |
| 04:43:15 | filwit | yeah i see what you're saying |
| 04:43:48 | Demos | yeah I may do that if I ever make a nicer wrapper, but the low level C wrapper will just be as raw as can be, it makes it eaiser to maintain and fix ABI issues |
| 04:44:20 | fowl | forking my oop macro to fowltek/classlib |
| 04:44:22 | filwit | flaviu1: the problem with using Macros.quote() to generate things is that inject the recList doesn't seem to work (which is why i did use it in the proto stuff) |
| 04:44:32 | fowl | theres going to be so many options your eyeballs will melt |
| 04:44:41 | fowl | configurable out the mf wazoo |
| 04:45:09 | fowl | injectedParamName = this |
| 04:45:40 | * | fowl puts that on the TODO list |
| 04:47:00 | filwit | i was really tempted at one point to use `class Foo of Bar pure cdecl`, `func foo of int noInit inline` everywhere |
| 04:47:39 | filwit | aka, every word (except that one directly following the `of` statement) would lower into a pragma |
| 04:48:03 | filwit | it's fully possible, but the '*' export symbol still doesn't work with macros |
| 04:48:21 | fowl | how so |
| 04:48:33 | filwit | well, last i tried it crashed the compiler |
| 04:48:53 | fowl | exporting a macro crashed the compiler? |
| 04:49:05 | filwit | i mean this: `class Foo*: ...` crashed the compiler (because of the *) |
| 04:50:04 | filwit | so you either have to make your OOP macro always export stuff, or make overloads, or different macros, or something else besides what everything else in nimrod uses for export |
| 04:50:35 | fowl | well there is no postfix expr |
| 04:50:39 | fowl | you know that |
| 04:50:52 | filwit | ahh.. that's probably it |
| 04:50:55 | filwit | forgot |
| 04:51:15 | fowl | i think araq is convinced to add it though |
| 04:51:49 | filwit | it would be nice, then we could more easily do that, plus add in some C-style stuff like ++ |
| 04:52:06 | Demos | oh dear god no |
| 04:52:08 | filwit | but idk the technical reason exactly for it not being around, so idk |
| 04:52:11 | fowl | filwit, dont bring that up if you want this feature |
| 04:52:21 | Demos | :d |
| 04:52:31 | filwit | heh, no one said y'all can't have your dumb 'inc' operator as well |
| 04:52:31 | fowl | lol |
| 04:52:35 | Demos | .inc is just fine |
| 04:52:42 | Demos | we already have it! |
| 04:52:46 | flaviu1 | inc is fine, ++ is bad |
| 04:52:55 | filwit | no it's not *sigh* |
| 04:53:04 | Demos | in particular ++c vs c++ is bad |
| 04:53:09 | flaviu1 | Nimrod doesn't even need ++, no one will use C-style for loops |
| 04:53:25 | Demos | and we already have a way to do it, so lets all just use inc |
| 04:53:38 | filwit | inc is used everywhere right now, flaviu1 |
| 04:53:45 | flaviu1 | and if someone uses ++ in a clever way to make their code more concise, they're an idiot that hates readability |
| 04:54:01 | filwit | and no, i will never use 'inc'. i would much rather just type '+= 1' |
| 04:54:55 | Demos | +=1 is just fine as well |
| 04:54:56 | filwit | flaviu1: well i agree the ++ pre/postfix difference is a poor design |
| 04:55:27 | filwit | but i think 'i++' is much better than 'i.inc' because it "feels" like 'i += ..' |
| 04:55:55 | filwit | simplification is an important part of UI design, which syntax is part of |
| 04:56:06 | flaviu1 | Nimrod already prefers using words over symbols, which is something I really like |
| 04:56:35 | filwit | i wish that where more true, actually |
| 04:57:04 | Demos | I tend to use inc(i) myself, but w/e |
| 04:57:05 | filwit | but there are a lot of places where that isn't true, then again, i've noticed they seem to be going away |
| 04:58:05 | flaviu1 | filwit: I just grepped the compiler, inc(i) is never part of an expression, its always on its own line |
| 04:58:22 | filwit | Demos: i actually don't mind using "i += 1", i remember trying to teach an engineering friend programming once, and he understood '+=' pretty quick but was confused about '++' |
| 04:58:40 | Demos | yeah that is fine |
| 04:58:52 | Demos | but ++ is just duplicateing functionality for no good reason |
| 04:58:57 | filwit | flaviu1: that doesn't make me like the word 'inc' over '++' any more |
| 04:59:29 | flaviu1 | fair enough, I will never use inc as n.inc |
| 04:59:32 | filwit | flaviu1: the reason i like '++' is because it's closer to it's cousin operator '+=' which is used everywhere in math (which is a focus of my game related code) |
| 05:00:14 | filwit | flaviu1: but i really don't mind just using += anyways, so it's a moot issue of mine really |
| 05:00:57 | Demos | I have NEVER seen += used in math |
| 05:01:07 | Demos | or do you mean math related code? |
| 05:01:12 | filwit | math code |
| 05:01:17 | Demos | ah |
| 05:01:18 | filwit | not.. math math |
| 05:01:21 | filwit | :P |
| 05:01:21 | flaviu1 | I only use inc when it can be read as 'increment variable x', like in the VM, where its 'increment program counter' or in a parser 'increment cursor' |
| 05:01:48 | flaviu1 | IMO, it helps readability a bit. |
| 05:02:18 | Demos | I do the same |
| 05:02:44 | filwit | the only operator in Nimrod that I think would help with noobs is "str & str" |
| 05:02:57 | filwit | it should be "str + str", like Javascript and C# |
| 05:03:00 | filwit | and Java |
| 05:03:03 | filwit | IMO |
| 05:03:33 | Demos | NOOOOOOOOOOOOOOOOOOOOOPEEEEEEEE |
| 05:03:34 | flaviu1 | That adds ambiguity and is weird |
| 05:03:47 | Demos | I think using + for string concat is really a poor design choice of other langues |
| 05:04:10 | flaviu1 | Definitely a very poor design choice |
| 05:04:11 | filwit | nah, it's about simplifying the learning curve Demos |
| 05:04:26 | filwit | and "array addition" doesn't make much sense anywhere anyways |
| 05:04:44 | flaviu1 | filwit: The learning curve should never be simplified at the expense of loosing preciseness |
| 05:04:54 | filwit | it's not tho |
| 05:05:09 | flaviu1 | I'm sure it was harder for the noobs to grasp that addition also is string concat |
| 05:05:10 | filwit | it's just a more common operator for the more common operation |
| 05:05:25 | Demos | it is a different operation than addition |
| 05:05:32 | Demos | thus it should be a different operator |
| 05:05:49 | filwit | seriously tho, when i say "this string PLUS this other string" what do you folks think more people are going to think you mean? |
| 05:06:14 | Demos | ease of learning is not totally related to syntax, and anyone who knows enough of another language to really be more confortable with other syntax will have no trouble just translateing the concepts |
| 05:06:17 | filwit | they're not going to think "every char gets added with the other chars!" |
| 05:06:31 | Demos | there should be no + operation on a string |
| 05:06:32 | flaviu1 | filwit: They might, it depends on their background |
| 05:06:44 | Demos | this string AND another string is just fine |
| 05:07:20 | filwit | Demos: that's just a cop-op argument against a logical improvement really tho. all you're saying is "i'm smart enough to know the difference, so other's should be too"... which is a bad path to follow for language popularity |
| 05:07:44 | flaviu1 | Nimrod shouldn't carry around other languages' poor design choices. As Demos said, `&` is read as and, and so is much more precise |
| 05:08:14 | Demos | flaviu1: it is not that it is more precise, it is more that it is not the same operation as addition. |
| 05:08:21 | filwit | flaviu1: okay, statistically speaking. Honestly, you have to admit that the common thought is going to be string combination (concat) not array addition (which doesn't even work with differen length strings) |
| 05:08:55 | Demos | filwit: sure, but it is not unheard of to use other operators |
| 05:08:58 | filwit | flaviu1: i personally think + is much better design choice |
| 05:09:10 | Demos | and most people admit that using + for string concat was a design mistake in java/c++ |
| 05:09:38 | filwit | flaviu1: from a design perspective, it's using common operators to apply to common type-specific tasks of the same 'logical' thing (addition) |
| 05:10:02 | filwit | Demos: i don't believe you, sorry |
| 05:10:05 | flaviu1 | Addition should not be overloaded to mean anything but mathematical addition. |
| 05:10:28 | filwit | Demos: i think those are just the people you've talked too. In my experience, most people like + for strings in JS and C# |
| 05:10:55 | Demos | have the people you talked to used anything else? do they really care that much? is this what people worry about? |
| 05:10:57 | filwit | flaviu1: i disagree, operators are not just "math things" anywhere in programing |
| 05:11:05 | flaviu1 | lua uses `..`, but I don't see anyone saying that they'd like lua, except for its pesky concatenation operator |
| 05:11:56 | Demos | so you expect that things with the same operators share the same laws |
| 05:12:15 | flaviu1 | Visual basic has `&` too. |
| 05:12:20 | Demos | "foo" & "bar" is not the same as "bar" & "foo" for example |
| 05:12:28 | flaviu1 | From the VB docs: "The & operator is recommended for string concatenation because it is defined exclusively for strings and reduces your chances of generating an unintended conversion" |
| 05:12:36 | filwit | flaviu1, Demos: arguments from popularity aside (because these things are usually biased anyways), i just think it makes more sense on logical grounds, because "addition" is a common "concept" and + is what we're all taught (from early ages) to convey that concept |
| 05:13:01 | flaviu1 | sorry, can't agree with you there. |
| 05:13:02 | Demos | sure, but addition is not what you are doing to those strings |
| 05:13:42 | filwit | you see +/= used all the time with jokes that use pictures... |
| 05:14:02 | filwit | Demos, yes "addition" is what i'm going for |
| 05:14:07 | Demos | it does not commute, also there is no string s' such that (g + s) + s' = g |
| 05:14:24 | filwit | again, what does "add these two pieces of text" mean? |
| 05:14:32 | Demos | nothing |
| 05:14:38 | filwit | yes it does |
| 05:14:41 | Demos | there is no operation that behaves like addition on text |
| 05:14:49 | filwit | ask any person on the street and they can give you a logical answer |
| 05:15:14 | Demos | no, they can give you a truthey answer |
| 05:15:15 | filwit | that means it has a common definition, even if that's not the "official meaning" written down somehweree |
| 05:15:31 | filwit | truthey still applies |
| 05:15:45 | Demos | it really does not, not to programming languages. Well maybe to perl |
| 05:16:02 | filwit | i disagree, we use "common terms" in every part of programming |
| 05:17:06 | filwit | and again, i know people who prefer this in JS and C#.. and even if they where novices (which not all of them are) then that would actually speak to it's ability to convey it's meaning well |
| 05:18:58 | flaviu1 | In SQL, `||` is used. In PHP, `.` is used. In some proprietary IBM language, `::`, `?:`, and `+` are used. In Lingo, `&` is used. In Fortran, `//` is used. |
| 05:19:09 | filwit | too me, have two operators is kinda like having two settings button on a page. It's usually better design to have one, context sensitive, settings button |
| 05:19:28 | filwit | flaviu1: yes i've used these languages, i know.. |
| 05:20:00 | flaviu1 | If anything, just write some words that will make people using `&` feel superior to the inferior, `+` using plebeians with their ambiguous statements. |
| 05:20:15 | Demos | well to me it is like having two buttons in a car, it is usually better than having one context sensitive button |
| 05:20:25 | filwit | flaviu1 :P |
| 05:21:22 | Demos | but I hardly think the string concat operator will be what really brings people to nimrod, heck I would hate to deal with anyone who was attracted by just the stupid concatination opeartor |
| 05:23:00 | filwit | people always say that when i bring these things up. I'm not saying this (at least not this alone) would detract from popularity, but paper-cuts do add up, and just because you might not like some people doesn't mean they don't have things to contribute which may make your life easier at the end of the day. |
| 05:23:51 | flaviu1 | filwit: I understand and agree with many of your paper-cuts, but this one doesn't really fly as a papercut for me. |
| 05:24:44 | filwit | flaviu1: sure, but so far all i've heard from everyone as to why not, is that "it's a math term" which I've feel i've made good argument against |
| 05:24:56 | Demos | right, except most of the changes you propose remove all the little things that make nimrod such a nice language, at least for me. |
| 05:25:41 | Demos | well I thought I made a decent argument, the operations have different properties, and thus should perhaps be visually different |
| 05:26:18 | Demos | there is almost nothing useful that concatination and addition share in terms of properties, also I think having them be the same operator could make generic code harder to write |
| 05:26:29 | flaviu1 | Maybe so, but while I don't know why I like `&` so much, I do thing that it is the way to go and far superior to `+` |
| 05:26:29 | filwit | so why don't we have different operators for float vs int? |
| 05:26:45 | filwit | (actually, in nimrod we DO have different operators for uint...) |
| 05:26:55 | flaviu1 | filwit: Nope, that was a design mistake |
| 05:27:03 | filwit | i agree |
| 05:27:04 | Demos | they share the same mathmatical properties (well more or less, floats are a bit strange) |
| 05:27:10 | flaviu1 | IIRC they're only there for backwards compatiblity |
| 05:27:20 | flaviu1 | You're supposed to use the uint module now |
| 05:27:22 | filwit | Demos: and you seem your slippery slope |
| 05:27:30 | Demos | how so |
| 05:27:43 | filwit | Demos: because the data type isn't as important as the action |
| 05:27:47 | Demos | floats at least approximately have the same properties for addition as ints |
| 05:27:53 | filwit | here, + conveys "addition" |
| 05:28:04 | filwit | which is about "what it does" not "what it's working on" |
| 05:28:29 | filwit | so if the concept *can* be applied, because this is such a commonly understood term, it should have meaning |
| 05:28:29 | flaviu1 | filwit: If anything, Demos has a point about overload resolution |
| 05:28:40 | filwit | i missed it, sorry one sec |
| 05:29:50 | filwit | i'm not seeing what Demos said about overload resolution... |
| 05:29:53 | filwit | can you quote? |
| 05:30:09 | flaviu1 | (01:25:52 AM) Demos: there is almost nothing useful that concatination and addition share in terms of properties, also I think having them be the same operator could make generic code harder to write |
| 05:31:01 | Demos | but string concatination is NOT addition, indeed it is the addition operation that makes ints and floats a vector space, but strings are not a vector space, at least not under concatination |
| 05:31:28 | Demos | that was in responce to filwits earlier thing, not my own quote :D |
| 05:32:43 | filwit | Demos: it doesn't matter. My argument boils down to this: "if i ask a laymen to 'add' two strings together, statistically speaking, what will he do? Will he understand? How would he think to represent this (as a laymen) in mathematical terms?" |
| 05:32:53 | flaviu1 | filwit: My comment about feeling superior is completely serious btw. If not done too thickly, people would really eat it up. I know I would |
| 05:33:03 | filwit | Demos: so basically, + should have the most common meaning, when applied to strings (or arrays) |
| 05:33:17 | filwit | Demos: and it doesn't really have that meaning. |
| 05:33:32 | Demos | my argument comes down to the fact that in the long run we should not care what the laymen thinks addition means, but what it actually menas |
| 05:33:59 | filwit | Demos: that's good for parsers, but not for humans |
| 05:34:10 | filwit | Demos, and designing for humans is how you gain popularity |
| 05:34:29 | filwit | flaviu1: sorry, i'm not sure exactly what you where saying about that then |
| 05:34:35 | flaviu1 | filwit: You could drop in `+` for string addition without changing the language |
| 05:35:11 | filwit | yes i know, and I might in the future. But the goal here is not to attract ME, but OTHERS, which means making it the standard in the docs |
| 05:35:27 | flaviu1 | filwit: Mention that `&` avoids ambiguity, maybe make a joke about javascript. People will see it as a positive thing |
| 05:36:02 | Demos | I am with flaviu1 on this one, and I am fairly sure that Araq will not like changeing the concat operator just for shits and giggles |
| 05:37:11 | filwit | i know Araq will never change this |
| 05:37:40 | filwit | that doesn't mean i'm going to agree with things i don't agree with, that would be intellectually dishonest |
| 05:38:12 | flaviu1 | I understand you're trying to make the language more approachable, which is admirable, but I doubt anyone here agrees with you in that this is a way to that goal. |
| 05:38:40 | flaviu1 | People are more likely to go away once they try it and run across a bug or something |
| 05:38:41 | filwit | sure, but anyone "here" might be the keyword there |
| 05:38:48 | Demos | OK suppose I want to write a function that is generic and the parameter is any type that is a member of an abelian group (has an opperation that commutes, has an identity and inverse, associates, and is closed), how do I write this typeclass? |
| 05:39:06 | Demos | how does this typeclass become much harder to write if we use + for string concat |
| 05:39:12 | filwit | flaviu1: oh, don't get me wrong, this is a minor issue |
| 05:39:54 | filwit | Demos: imagine it takes in a type with + overloads... same issue |
| 05:39:59 | flaviu1 | I was actually thinking if there was a community of programmers we could poll fairly quickly. |
| 05:40:35 | Demos | right, the point is that if you overload stuff you better make damn sure you satisfy all the expected laws |
| 05:40:35 | flaviu1 | I mean, you can't do A/B testing with a programming language, which would be ideal, but a poll might work pretty well |
| 05:41:15 | Demos | the result of the poll would be "seriously, this of all things is what they need input on" |
| 05:41:44 | flaviu1 | Well, I was also thinking of putting lambda syntax up to poll |
| 05:41:50 | filwit | flaviu1: i've tried to say "design by statistical analysis" a bunch of times, but Araq always says he doesn't agree with that (which I agree, pure democracy is dumb). |
| 05:42:17 | flaviu1 | filwit: We can't do design by statistical analysis, unless we have statistics. |
| 05:42:27 | filwit | flaviu1: but it would be useful to know what a larger community (especially outside of those Nimrod has already attracted) think |
| 05:42:34 | Demos | design by statistical analysis fails when you realize that asking people what they want and then doing it is a really bad way to give them what they want |
| 05:42:39 | filwit | flaviu1: agreed :) |
| 05:42:45 | flaviu1 | But yeah, consideration of statistics is very important |
| 05:43:15 | filwit | Demos: back to your argument about generics... does + really "make sense" for strings in the first place? |
| 05:43:27 | filwit | Demos: you have to check for these conditions, or just hope for the best |
| 05:43:49 | Demos | filwit: no, it does not. That is my point |
| 05:43:59 | filwit | Demos: no i mean the way it works right now |
| 05:44:15 | filwit | Demos: like a generic function which attempted to `str + str` (today) |
| 05:44:23 | Demos | no |
| 05:44:28 | Demos | and it should not compile |
| 05:44:58 | filwit | but it compiles now i'm pretty sure? |
| 05:44:59 | Demos | the idea was a function like proc specialMathFucntion(param: abelian) |
| 05:45:01 | Demos | no |
| 05:45:04 | Demos | it would not |
| 05:45:09 | filwit | okay, i guess I'm thinking of D |
| 05:45:14 | filwit | where strings are just arrays |
| 05:45:19 | Demos | I mean if you made a "+" proc it would |
| 05:46:08 | Demos | also, I think arrays of equal lenght and of the same type do form an abelian group with + |
| 05:46:22 | Demos | but that is based on intuition at 2:00AM |
| 05:46:38 | Demos | look I gotta sleep |
| 05:46:55 | * | Demos quit (Remote host closed the connection) |
| 05:47:42 | flaviu1 | Its nearly 2 AM for me too, but ##programming seems like a fine place to get some surveys filled out |
| 05:47:52 | filwit | :D |
| 05:47:56 | filwit | yeah, same here |
| 05:48:04 | filwit | guess we're all close to the east coast |
| 05:49:57 | filwit | i just joined ##programming. I'm fully done talking about this issue (especially since i know it wont ever change), but let me know if you ask there. Would like to see what people say. |
| 05:52:29 | * | flaviu1 quit (Ping timeout: 264 seconds) |
| 05:57:30 | * | nequitans_ joined #nimrod |
| 06:00:38 | * | nequitans_ quit (*.net *.split) |
| 06:01:51 | * | filwit quit (Quit: Leaving) |
| 06:06:44 | * | nande quit (Read error: Connection reset by peer) |
| 06:42:43 | * | hoverbear quit () |
| 06:44:05 | * | hoverbear joined #nimrod |
| 06:44:10 | * | hoverbear quit (Max SendQ exceeded) |
| 06:44:49 | * | hoverbear joined #nimrod |
| 06:44:53 | * | hoverbear quit (Max SendQ exceeded) |
| 06:45:31 | * | hoverbear joined #nimrod |
| 06:56:44 | * | hoverbear quit () |
| 07:22:26 | * | io2 joined #nimrod |
| 08:30:35 | * | kunev joined #nimrod |
| 08:35:14 | * | egp_ joined #nimrod |
| 08:36:57 | egp_ | Hello people. I am just starting to know about Nimrod, and I have two questions: what will it take to compiler for Android and iOS? Where can I read about this (I am currently googling for this on nimrod's site). |
| 08:37:44 | egp_ | I wanted to do my own compiler for Windows, Linux, Android, iOS set of targets... based on oberon-line LL(1) syntax, but was suggested to check Nimrod |
| 08:38:36 | egp_ | I currently know extremely little about Android and iOS though. |
| 08:39:18 | egp_ | oberon-like* |
| 08:39:49 | egp_ | to compile* |
| 08:46:14 | * | kemet joined #nimrod |
| 09:37:07 | * | dLog_ joined #nimrod |
| 09:42:29 | * | kunev_ joined #nimrod |
| 09:44:16 | * | EXetoC quit (Ping timeout: 265 seconds) |
| 09:44:16 | * | kunev quit (Ping timeout: 265 seconds) |
| 09:44:17 | * | dLog quit (Ping timeout: 265 seconds) |
| 09:44:18 | * | untitaker quit (Ping timeout: 265 seconds) |
| 09:45:37 | * | EXetoC joined #nimrod |
| 09:46:16 | * | untitaker joined #nimrod |
| 09:53:13 | * | kemet quit (Ping timeout: 245 seconds) |
| 10:14:14 | * | Matthias247 joined #nimrod |
| 10:29:19 | * | egp_ quit (Quit: Ухожу я от вас (xchat 2.4.5 или старше)) |
| 11:20:19 | * | saml_ joined #nimrod |
| 11:46:05 | * | Varriount|Mobile joined #nimrod |
| 11:47:59 | * | BitPuffin joined #nimrod |
| 12:14:35 | * | untitaker quit (Ping timeout: 240 seconds) |
| 12:21:25 | * | untitaker joined #nimrod |
| 12:31:57 | Araq | Varriount|Mobile: your patch for #1203 is wrong unfortunately |
| 12:32:30 | Araq | type construction in general needs to prevent that 'ptr void' (and other invalid types) are constructed |
| 12:33:54 | NimBot | Araq/Nimrod devel f5ed8f3 Jostein Berre Eliassen [+0 ±2 -0]: added getTotalSharedMem et al. |
| 12:33:54 | NimBot | Araq/Nimrod devel 2b72e02 Andreas Rumpf [+0 ±2 -0]: Merge pull request #1208 from jbe/shared_mem_stats... 2 more lines |
| 12:36:11 | Araq | reactormonk: what's the status of #1130 ? |
| 12:37:35 | NimBot | Araq/Nimrod devel a7db33e Billingsly Wetherfordshire [+0 ±1 -0]: added md5 functions from <openssl/md5.h> |
| 12:37:35 | NimBot | Araq/Nimrod devel 3571635 Billingsly Wetherfordshire [+0 ±1 -0]: i left an {.importc.} in there |
| 12:37:35 | NimBot | Araq/Nimrod devel 794b035 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1126 from fowlmouth/patch-1... 2 more lines |
| 12:47:07 | * | q66 joined #nimrod |
| 12:47:07 | * | q66 quit (Changing host) |
| 12:47:07 | * | q66 joined #nimrod |
| 12:51:30 | reactormonk | Araq, fuck it, ruby it is. |
| 12:57:03 | reactormonk | Araq, anything to convert T to T not nil ? |
| 13:01:27 | * | freezerburnv joined #nimrod |
| 13:05:01 | * | darkf quit (Quit: Leaving) |
| 13:06:47 | BitPuffin | reactormonk: ruby? |
| 13:07:13 | BitPuffin | ah |
| 13:07:18 | BitPuffin | you mean porting their code |
| 13:27:28 | * | freezerburnv quit (Quit: freezerburnv) |
| 13:31:44 | EXetoC | does the test suite sometimes eat exceptions? |
| 13:33:14 | * | kunev_ quit (Quit: Lost terminal) |
| 13:37:47 | EXetoC | it happens after the suite section too, but not when it is omitted. gah |
| 13:41:40 | EXetoC | so something is having a global effect then I guess |
| 13:53:30 | Varriount_ | Araq: "Type construction in general" as opposed to..? |
| 13:53:48 | * | Varriount|Mobile quit (Quit: AndroIRC - Android IRC Client ( http://www.androirc.com )) |
| 13:53:55 | * | Varriount_ is now known as Varriount |
| 13:54:19 | Varriount | Araq: The patch prevents the ptr void type from being constructed. |
| 14:19:24 | * | Demos joined #nimrod |
| 14:38:24 | Varriount | Hi Demos |
| 14:38:44 | * | hoverbear joined #nimrod |
| 14:51:33 | Varriount | Hey hoverbear |
| 14:52:02 | Demos | Varriount: hey Varriount |
| 15:04:02 | Varriount | Araq: Ping |
| 15:09:07 | * | OrionPK quit (Ping timeout: 252 seconds) |
| 15:15:48 | Araq | Varriount: pong |
| 15:16:12 | Varriount | Araq: Type contruction in general, as opposed to..? |
| 15:16:30 | Araq | as opposed to checking it only in 'cast' |
| 15:16:38 | Araq | but maybe I misread your patch |
| 15:18:01 | BitPuffin | solution: implement everything wint |
| 15:18:09 | BitPuffin | with cast !!!1111oneone |
| 15:19:02 | Varriount | Araq: I use the same technique used elsewhere in the lib - validating that the type is valid via typeAllowed |
| 15:19:08 | Varriount | *in the compiler |
| 15:19:26 | Araq | yes, but semTypeNode or something should call typeAllowed |
| 15:19:39 | Araq | 'cast' has nothing to do with it |
| 15:20:32 | Varriount | Araq: Wouldn't that mess up generic parameters? |
| 15:21:38 | BitPuffin | and macros? |
| 15:21:39 | hoverbear | Varriount Hey! |
| 15:22:51 | Araq | Varriount: quite possible but our test suite should tell us if that's the case |
| 15:23:13 | BitPuffin | you can't rely on a test suite |
| 15:23:17 | Varriount | Araq: Also, I forgot to mention, my fix prevents non-concrete types from being used as cast parameters |
| 15:23:18 | BitPuffin | always be paranoid |
| 15:23:40 | Araq | Varriount: really? how so? |
| 15:24:31 | Varriount | Araq: discard cast[NonConcreteType](concreteVariable) currently passes semantic checking, and causes an error in the code generation stage |
| 15:25:35 | Varriount | Yes, it's silly, but it does cause an error. |
| 15:26:00 | Araq | ok, so semTypeNode needs a wantConcreteType: bool |
| 15:26:38 | BitPuffin | only old people play boule |
| 15:26:39 | Araq | and we need to decide for every usage of semTypeNode what to pass |
| 15:29:05 | BitPuffin | a good nome for a procedure to decide what should pass or not is Gandalf |
| 15:30:41 | Araq | BitPuffin: lol |
| 15:30:55 | Araq | I like it |
| 15:31:19 | BitPuffin | Didn't think you would hehe :) |
| 15:32:06 | Araq | gandalf: slurp "this" |
| 15:32:28 | Araq | fits the rest of the language |
| 15:32:49 | BitPuffin | true |
| 15:32:56 | BitPuffin | we already have so many stupid names in programming |
| 15:33:00 | BitPuffin | might as well go on a rampage |
| 15:34:14 | Araq | hmm so semTypeNode grows a flags parameter ... why does this *always* happen in the compiler? |
| 15:36:17 | Varriount | Araq: Because 90% of a compiler is corner cases. |
| 15:37:14 | Araq | really? I thought it's a simple AST walker that deals with + and - operators :P |
| 15:37:43 | Varriount | Araq: So where in semTypeNode should I place the typeAllowed()? |
| 15:38:10 | Araq | there is only 1 place where it can be put |
| 15:43:31 | * | silven quit (Read error: Connection reset by peer) |
| 15:43:44 | * | silven joined #nimrod |
| 15:43:47 | * | saml_ quit (Quit: Leaving) |
| 15:44:27 | Varriount | Araq: Which is? |
| 15:44:57 | Araq | at the very end for 'result' |
| 15:45:12 | * | silven quit (Read error: Connection reset by peer) |
| 15:45:12 | Araq | you need to ensure that proc doesn't use 'return' for this to work |
| 15:48:20 | Varriount | Well, using echo(typeAllowed(result, skParam)) leads to many 'false' being printed to the console |
| 15:48:52 | * | silven joined #nimrod |
| 15:49:31 | Araq | aha now we're getting somewhere |
| 15:49:51 | Araq | well 'skParam' might not be the correct choice |
| 15:49:55 | Araq | but hmm |
| 15:50:05 | Araq | I guess this means I'm wrong |
| 15:50:17 | Araq | forgot about the symKind that typeAllowed takes |
| 15:50:49 | Varriount | Araq: I do see the sense in moving this to semTypeNode though, it reduces the number of redundant calls to typeAllowed() |
| 15:51:34 | Araq | no, the symKind suggests that most of code already calls it in the appropriate context |
| 15:52:01 | Araq | so ... your fix for 'cast' only is much better |
| 15:53:18 | BitPuffin | isn't kind of most software corner cases |
| 15:54:00 | * | OrionPK joined #nimrod |
| 15:54:34 | BitPuffin | Araq: do you guess you are wrong or are you wrong? :) |
| 15:59:41 | * | Jehan_ joined #nimrod |
| 16:01:47 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 16:06:51 | Araq | BitPuffin: I am wrong. happy now? |
| 16:07:21 | BitPuffin | yes :D |
| 16:07:23 | BitPuffin | I'm just teasing you ya know |
| 16:13:27 | * | springbok joined #nimrod |
| 16:40:03 | * | Jesin quit (Ping timeout: 252 seconds) |
| 17:06:48 | * | ack006 joined #nimrod |
| 17:07:20 | Araq | hi ack006 wb |
| 17:07:39 | ack006 | hi, long time no see :-) |
| 17:09:24 | Araq | bbl |
| 17:12:57 | Varriount | Araq: ping |
| 17:19:09 | * | ack006 quit (Quit: Leaving) |
| 17:27:04 | * | flaviu1 joined #nimrod |
| 17:45:38 | Araq | Varriount: pong |
| 17:46:11 | Varriount | Araq: How would I go about fixing this bug: https://github.com/Araq/Nimrod/issues/1142 |
| 17:46:51 | Varriount | Araq: Also, when do you want to talk about compiler stuff/issues on Skype/VNUG? |
| 17:47:08 | Araq | ah yeah, that's a bit tricky to fix :P |
| 17:47:33 | Araq | I can't sykpe now but perhaps in 1 hour |
| 17:48:32 | * | caioarie1e joined #nimrod |
| 17:48:55 | * | ashey1 joined #nimrod |
| 17:51:39 | * | caioariede quit (Ping timeout: 252 seconds) |
| 18:06:08 | BitPuffin | Araq: is evals.nim gonna get removed? |
| 18:08:31 | flaviu1 | BitPuffin: and nimlexbase, pbraces, transf |
| 18:09:58 | BitPuffin | well all the old unused stuff |
| 18:13:42 | Araq | BitPuffin: it's already not used anywhere |
| 18:14:00 | Araq | flaviu1: transf will stay |
| 18:14:35 | BitPuffin | Araq: no but it's existence is confusing and bloating |
| 18:14:46 | BitPuffin | we use version control for a reason |
| 18:14:55 | flaviu1 | And be extended dramatically with all the lowering passes currently in cgen? |
| 18:14:57 | flaviu1 | :P |
| 18:15:21 | Araq | flaviu1: maybe we rename it into "iterinliner" :P |
| 18:20:50 | flaviu1 | Araq: Ok, I've fixed backwards compatibility. https://github.com/Araq/Nimrod/pull/1089 |
| 18:35:28 | NimBot | Araq/Nimrod devel 6d3fbf9 flaviut [+0 ±1 -0]: Allow for nil chaining in JSON |
| 18:35:28 | NimBot | Araq/Nimrod devel 4ff5112 flaviut [+0 ±1 -0]: Add a couple words to docs |
| 18:35:28 | NimBot | Araq/Nimrod devel db7fee6 flaviut [+0 ±1 -0]: Add tests for the nil passthrough |
| 18:35:28 | NimBot | Araq/Nimrod devel 64d3b9a flaviut [+0 ±1 -0]: Fix subtle mistake in docs and formatting |
| 18:35:28 | NimBot | 4 more commits. |
| 18:35:36 | Araq | flaviu1: thank you |
| 18:36:18 | Araq | Varriount: please merge #1114 manually |
| 18:36:28 | flaviu1 | Thanks for pulling, I've been meaning to fix it for the past couple days, but I haven't found time |
| 18:41:21 | fowl | oh cool |
| 18:44:05 | NimBot | Araq/Nimrod devel dd6c5f8 Grzegorz Adam Hankiewicz [+1 ±5 -0]: Adds documentation about koch. |
| 18:44:05 | NimBot | Araq/Nimrod devel f79dd72 Grzegorz Adam Hankiewicz [+0 ±1 -0]: Updates list of files to build in doc directory. |
| 18:44:05 | NimBot | Araq/Nimrod devel e2f771a Grzegorz Adam Hankiewicz [+0 ±1 -0]: Removes accidental module docstring. |
| 18:44:05 | NimBot | Araq/Nimrod devel 72ff19f Grzegorz Adam Hankiewicz [+0 ±1 -0]: Mentions useFFI and garbage collector options. |
| 18:44:05 | NimBot | 2 more commits. |
| 18:48:59 | * | perturbation quit (Quit: Leaving) |
| 18:51:17 | NimBot | Araq/Nimrod devel ce773b7 Reimer Behrends [+0 ±1 -0]: Fixed readAllBuffer() to avoid adding garbage bytes at end.... 5 more lines |
| 18:51:17 | NimBot | Araq/Nimrod devel 6ae4626 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1221 from rbehrends/readallbuf-fix... 2 more lines |
| 18:51:49 | Varriount | It's a PR party! |
| 18:55:02 | BitPuffin | I'd call it a mergo party |
| 18:55:15 | Jehan_ | I call it spam. :) |
| 18:55:37 | Jehan_ | But then I'm in a bad mood because I have to write C++ code at the moment. |
| 18:57:04 | BitPuffin | lol |
| 18:58:09 | Varriount | Eew |
| 19:00:03 | BitPuffin | hey, at least you can put an int in a C++ template parameter without getting your dick cut off |
| 19:01:08 | Jehan_ | I'm not sure I want to know what caused that comment ... |
| 19:02:40 | BitPuffin | haha |
| 19:02:44 | BitPuffin | it's not as bad as it sounds |
| 19:02:46 | Jehan_ | I have to admit, C++ isn't half bad for those situations where you can just plug in a conservative GC, ignore destructors and such and pretend it's a high-level language. |
| 19:02:48 | BitPuffin | lol that sounded weird |
| 19:03:18 | BitPuffin | what I mean is: put an int in a generic parameter and our compiler explodes |
| 19:03:22 | Jehan_ | Until you find out the hard way that the [] operator for vectors, unlike at(), doesn't do bound checks. |
| 19:03:43 | BitPuffin | yeah |
| 19:03:44 | Jehan_ | BitPuffin: Yeah, but I'm generally not tempted to do that. |
| 19:03:57 | Varriount | BitPuffin: What kind of compiler do you use? |
| 19:03:59 | BitPuffin | Jehan_: well you don't work with math libs probably then :P |
| 19:04:12 | BitPuffin | Varriount: what kind of nimrod compiler? |
| 19:04:29 | Jehan_ | BitPuffin: Well, I do work on computer algebra systems. Does that count? |
| 19:05:03 | BitPuffin | Jehan_: depends, are you trying to implement n-dimensional matrices in a non-stupid way? |
| 19:05:04 | Jehan_ | I mean, it's math, just probably not the math you were referring to. |
| 19:05:19 | BitPuffin | but yeah I guess it counts as math lib |
| 19:05:22 | BitPuffin | :P |
| 19:06:31 | flaviu1 | Wow, http://i.imgur.com/2wcnKcx.png |
| 19:06:36 | Jehan_ | BitPuffin: Well, I work with matrices over rings, but … let's just say we're involved in a debate as to how to clean up the existing code. |
| 19:06:39 | * | freezerburnv joined #nimrod |
| 19:07:10 | BitPuffin | Jehan_: :P |
| 19:07:52 | BitPuffin | someone's i3 can't handle firefox |
| 19:08:07 | Jehan_ | The individual pieces of code aren't actually bad. It's just that the system as a whole has grown – let's call it "organically" – over the years, as the result of various research projects, student thesis work, and such. |
| 19:08:34 | flaviu1 | Nah, the issue there is that I used dmenu to run scrot, and firefox hasn't had a chance to redraw itself in the instant between dmenu closing and scrot taking a screenshot |
| 19:09:20 | BitPuffin | Jehan_: mhm. Well at least in my case what I want to do is allow someone to say let m: TMatrix[float, 8 11] = ... |
| 19:09:32 | BitPuffin | and that almost works |
| 19:09:37 | BitPuffin | but the compiler still hates me |
| 19:09:50 | BitPuffin | flaviu1: gotcha |
| 19:11:19 | Jehan_ | BitPuffin: I would just keep the dimensions as instance variables of the class rather than trying to make C++ jump through hoops. |
| 19:17:00 | BitPuffin | Jehan_: well I want compiletime stuff etc |
| 19:17:15 | BitPuffin | so for example |
| 19:18:16 | Jehan_ | Oh, you're trying to make Nimrod do that? Gotcha. |
| 19:18:18 | BitPuffin | proc `*`[T, R, C, N](a: TMatrix[T, R N], b: TMatrix[T, N C]): TMatrix[T, R, C] = ... |
| 19:18:21 | BitPuffin | yeah |
| 19:18:22 | BitPuffin | exactly |
| 19:19:36 | BitPuffin | this neatly let's me define multipilication for every matrix kinds where multiplication is mathematically defined |
| 19:19:42 | BitPuffin | or not compile |
| 19:19:46 | BitPuffin | which is nice imo |
| 19:20:19 | Jehan_ | Hmm. |
| 19:20:22 | BitPuffin | most game matrices are square though but I am kind of perfectionist about it. And I like to experiment |
| 19:20:52 | Jehan_ | I have to admit that I belong to the school that likes static typing, but also thinks that you can make a typechecker do too much. |
| 19:21:37 | BitPuffin | well here it's just a consequence of how it works |
| 19:21:47 | BitPuffin | you aren't making it do anything it shouldn't be able to do |
| 19:22:04 | Jehan_ | You gain the biggest benefits from typechecking when you use it to (1) document your code or (2) to catch clerical errors. |
| 19:22:19 | Jehan_ | BitPuffin: Oh, I don't want to discourage you. |
| 19:22:24 | BitPuffin | just that if a doesn't have N columns and b doesn't have N rows, then they aren't the same type :P |
| 19:22:33 | Jehan_ | I just think there are diminishing returns here. |
| 19:22:53 | Jehan_ | What do you do if the matrix size can't be specified at compile time? |
| 19:23:39 | BitPuffin | well the whole point is that for most stuff you'll use this for it will be known at compile time |
| 19:23:48 | Jehan_ | I see. |
| 19:23:59 | BitPuffin | you'd probably not use this for a network based runtime math service |
| 19:24:14 | BitPuffin | but you'd use it for graphics and physics etc |
| 19:31:01 | fowl | just write the two main macro types you until you can do it fully |
| 19:31:13 | fowl | two main matrix types* |
| 19:35:14 | Araq | Jehan_: looks like I need to learn from this: https://h21007.www2.hp.com/portal/download/files/unprot/hpux/MakingConditionVariablesPerform.pdf |
| 19:35:34 | Araq | unfortunately my brain is already sleeping ... |
| 19:36:25 | Jehan_ | Heh. The problem is that to do it portably (not just across operating systems, but across different hardware configurations) can be more art than science. |
| 19:37:42 | Araq | hmm skimming it again, it doesn't seem to apply since we have no queue in the first place |
| 19:39:00 | BitPuffin | fowl: I might have to, that doesn't really solve the perfectionist situation |
| 19:39:19 | Jehan_ | There are also a few tricks that they don't even talk about, such as having two mutexes for a queue. |
| 19:39:56 | * | Matthias247 joined #nimrod |
| 19:40:21 | Jehan_ | One for the head, one for the tail (you may need to grab both for certain operations, but done right, you can increase concurrency considerably this way). |
| 19:42:47 | Jehan_ | The major problem is that you are dealing with two conflicting constraints, though. |
| 19:44:01 | Jehan_ | A thread blocking while there are unused processors is bad (because blocking is an expensive operation). But a thread not blocking while all processors are in use can also be bad (if it isn't doing anything productive), because it occupies a processor without contributing. |
| 19:46:19 | Jehan_ | A common compromise if you know that a lock is always going to be held only for a short period is to do a short busy wait (ideally performing real work for the duration) and only blocking if the lock is still unavailable. |
| 19:46:34 | Jehan_ | Same principle applies to synchronization mechanisms other than mutexes, of course. |
| 19:47:33 | Jehan_ | Also, something important to know about POSIX condition variables: they may experience spurious wakeups without them actually being signaled. |
| 19:47:52 | Araq | yeah that's what I tried with the fast cond var hack |
| 19:48:08 | Araq | a short busy wait |
| 19:49:21 | Jehan_ | My personal recommendation would be to start out with a simple, by-the-book implementation and then tune it to improve performance. |
| 19:50:22 | Jehan_ | The interesting part is that a lot of actual workloads cannot really be improved much. |
| 19:51:51 | Jehan_ | Or, alternatively, they're so hopelessly stuck in a serialization bottleneck that nothing can help. :) |
| 19:52:49 | BitPuffin | Varriount: I think I added you on skype |
| 19:54:49 | BitPuffin | if your name is Clay |
| 19:56:43 | BitPuffin | Here I thought your name was Varriount |
| 19:56:45 | BitPuffin | I feel so betrayed |
| 19:56:48 | BitPuffin | lol |
| 19:57:11 | Varriount | BitPuffin: Try caly sweetser, I didn't get it. |
| 19:57:15 | Varriount | *Clay |
| 20:00:54 | BitPuffin | Varriount: it only let's me call phone |
| 20:00:56 | BitPuffin | for some reason lol |
| 20:02:57 | Araq | Jehan_: "they may experience spurious wakeups without them actually being signaled." yeah I know |
| 20:03:00 | BitPuffin | err okay it says call phone |
| 20:03:09 | BitPuffin | but if I actually try it says add phone number |
| 20:10:11 | * | caioarie1e quit (Ping timeout: 240 seconds) |
| 20:10:26 | * | caioariede joined #nimrod |
| 20:11:38 | flaviu1 | Feedback please: http://i.imgur.com/57UMZO4.png |
| 20:12:12 | * | Skrylar quit () |
| 20:15:17 | Varriount | flaviu1: Nice. Very clean. |
| 20:15:35 | Varriount | flaviu1: How do you get your tabs to line up that way? |
| 20:16:25 | flaviu1 | And addon, Tree Style Tab |
| 20:17:11 | fowl | flaviu1, can you put it on a softer background |
| 20:17:43 | flaviu1 | fowl: I want that too, do you have any sites that have a background you like? |
| 20:18:00 | flaviu1 | Its easier to take colors than to come up with them myself |
| 20:20:59 | fowl | flaviu1, check this site out http://www.colourlovers.com/ |
| 20:25:03 | Varriount | flaviu1: I wonder if filwit's new design's encompass the tutorial as well |
| 20:25:41 | flaviu1 | I assume it does, since most of his design will be in CSS, which can be transferred over |
| 20:29:43 | BitPuffin | flaviu1: oh so you are actually working on documentation mainly rather than design? |
| 20:29:59 | BitPuffin | I was worried that there were some duplication of effort due to communication misses |
| 20:30:12 | BitPuffin | but thank god if you are improving the tutorial |
| 20:30:16 | flaviu1 | BitPuffin: I'm actually doing the By Example thing |
| 20:30:39 | BitPuffin | learn nimrod by example? |
| 20:30:44 | flaviu1 | And I'm making the design nice so people don't bleed out their eyes and run away |
| 20:30:46 | flaviu1 | Yea |
| 20:30:54 | BitPuffin | cool |
| 20:40:28 | Jehan_ | flaviu1: Like "Learn Lua in 15 Minutes"? That'd be really nice, yes. :) |
| 20:41:11 | flaviu1 | More inspired by http://rustbyexample.com/, but yes |
| 20:49:43 | * | ashey1 quit (Quit: WeeChat 0.3.8) |
| 20:53:37 | NimBot | Araq/Nimrod devel 6608fcc Clay Sweetser [+0 ±1 -0]: Update 'isCastable' and 'semCast' doc-comments |
| 20:53:37 | NimBot | Araq/Nimrod devel c4f77ec Clay Sweetser [+0 ±1 -0]: Fix issue #1203 |
| 20:53:37 | NimBot | Araq/Nimrod devel 9d68fe3 Clay Sweetser [+0 ±1 -0]: Rename some variables in the isCastable code |
| 20:53:37 | NimBot | Araq/Nimrod devel cbe25a4 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1229 from Varriount/fix-1203... 2 more lines |
| 20:55:21 | Araq | looks like I need to fix some bugs soon ... not many PRs left |
| 20:56:44 | Jehan_ | I can always run a madlibs code generator on the standard lib and submit the results. :) |
| 20:57:07 | BitPuffin | Araq: you should be fixing bugs regardles ya little goof :) |
| 20:57:24 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 20:58:13 | EXetoC | you might be on to something |
| 20:58:31 | Araq | Jehan_: what's a madlibs code generator? |
| 20:59:23 | * | io2 joined #nimrod |
| 21:00:23 | flaviu1 | Araq: Have you seen that graph I posted? The resolved bug count is outpacing the bug count! |
| 21:00:36 | Jehan_ | Mad libs is basically a way to randomly generate grammatically correct, but nonsensical text: http://en.wikipedia.org/wiki/Mad_Libs |
| 21:00:53 | Jehan_ | Applying the technique to code is left as an exercise to the reader. :) |
| 21:00:57 | * | Jehan_ quit (Read error: Connection reset by peer) |
| 21:01:03 | BitPuffin | really low hanging fruit is good to leave to us noobs though |
| 21:01:31 | flaviu1 | http://en.wikipedia.org/wiki/Markov_chain |
| 21:10:58 | * | Jehan_ joined #nimrod |
| 21:25:36 | Araq | flaviu1: yeah that graph is pretty nice |
| 21:25:58 | Araq | the bug count is pretty meaningless though |
| 21:26:10 | Araq | we have lots of feature requests in there |
| 21:30:18 | flaviu1 | If you made an "Eradicate all Bugs" milestone, the numbers might be a bit more accurate, but too much work for a useless graph |
| 21:40:30 | Araq | tpi.nim(17, 9) Error: cannot prove: k <= len(ch) + -1 |
| 21:40:40 | Araq | people will hate me for this ... |
| 21:42:52 | * | brson joined #nimrod |
| 21:46:19 | dom96 | flaviu1: You're not using gitbook anymore? how come? |
| 21:46:29 | dom96 | or are you just changing the style of it? |
| 22:10:55 | flaviu1 | dom96: I'm not using gitbook any more |
| 22:11:13 | flaviu1 | Gitbook was a huge pain |
| 22:11:42 | dom96 | I see. Why not just reuse Gitbook's style? |
| 22:12:17 | flaviu1 | I've actually never done any CSS, so I want to mess with it a bit. |
| 22:12:28 | flaviu1 | But my most recent revision is nicer than Gitbook IMO |
| 22:12:52 | flaviu1 | http://i.imgur.com/DJLSN5y.png |
| 22:12:55 | Araq | why not use nimrod's docgen instead? |
| 22:13:39 | dom96 | A bit too grey |
| 22:13:45 | dom96 | IMO |
| 22:13:52 | flaviu1 | Araq: Sorry, but its ugly |
| 22:14:13 | Araq | you can configure it via CSS like anything else, flaviu1 |
| 22:15:33 | flaviu1 | I guess I could, but I'm quite happy with nanoc right now |
| 22:15:56 | flaviu1 | dom96: Where would you like to see more color? |
| 22:16:37 | dom96 | Sorry. But I simply dislike the background color. |
| 22:17:04 | flaviu1 | I don't want it to be white, but do you have any colors you prefer? |
| 22:17:37 | dom96 | Not really, I would prefer white. |
| 22:18:00 | dom96 | also your <code> needs more padding on the left and right |
| 22:18:40 | * | Jehan_ quit (Quit: Leaving) |
| 22:18:42 | flaviu1 | Inline code or block code? |
| 22:18:46 | dom96 | inline |
| 22:18:48 | Araq | Varriount: did we fix "could not import: CreateSymbolicLinkW" ? |
| 22:25:43 | flaviu1 | dom96: Thanks, that looks better |
| 22:26:51 | fowl | flaviu1, i like that background |
| 22:27:04 | flaviu1 | fowl: No, the inline code horizontal padding |
| 22:28:06 | flaviu1 | I'm never getting rid of that background, its awesome |
| 22:33:35 | * | freezerburnv quit (Quit: freezerburnv) |
| 22:34:45 | EXetoC | looks good. #FFF sucks |
| 22:34:54 | EXetoC | too bright |
| 22:39:15 | dom96 | EXetoC: perhaps you should adjust your monitors brightness? :P |
| 22:39:23 | BitPuffin | Araq: does the docgen spit out classes for all the shit? |
| 22:39:26 | BitPuffin | I mean all the elements |
| 22:39:29 | BitPuffin | in the generated html |
| 22:40:28 | * | freezerburnv joined #nimrod |
| 22:41:05 | Araq | BitPuffin: almost. butI decided to make it compatible with what python's docutils produces |
| 22:41:22 | Araq | was a mistake, i think |
| 22:41:35 | Araq | nobody cares about that anyway |
| 22:41:52 | Araq | and the classes they use don't make much sense |
| 22:42:36 | * | hoverbear quit () |
| 22:43:41 | * | hoverbear joined #nimrod |
| 22:44:43 | flaviu1 | Really interesting how rust decided to go the exception-free route. Less flexible, but easier to implement and simpler. |
| 22:48:55 | Araq | for the usual definition of "simple": "simple until I really need the feature. And then it's a pita to create a workaround and the human being is doing a compiler's job" |
| 22:50:06 | * | Skrylar joined #nimrod |
| 22:50:10 | Araq | that said, I still like my "error stack" idea very much. |
| 22:50:24 | fowl | flaviu1, why did they? llvm has cheap exceptions |
| 22:50:55 | Araq | and might make it an experimental feature for nimrod |
| 22:52:16 | Araq | fowl: the reasoning behind it is that 'raise' unwinds the *stack* but not the heap and so it's a fragile mechanism. |
| 22:54:02 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 22:54:04 | Araq | and usually it's an implementation detail if the heap is affected or not. |
| 22:55:47 | dom96 | Hrm. https://hola.org/challenge_js?utm_source=bext |
| 22:56:46 | dom96 | 25% faster than glibc, is that even possible with JS? |
| 22:57:14 | * | BitPuffin joined #nimrod |
| 22:57:24 | Araq | shouldn't be hard ... :P |
| 22:58:25 | dom96 | Araq: Do it then, $500 for first prize isn't bad. |
| 22:58:55 | Araq | $500 is not nearly enough money to make me program in javascript |
| 22:59:00 | Araq | but hmm |
| 22:59:06 | Araq | I could use nimrod |
| 22:59:14 | dom96 | Actually. Let me do it instead, I need the money :P |
| 23:01:22 | * | darkf joined #nimrod |
| 23:05:52 | * | freezerburnv quit (Quit: freezerburnv) |
| 23:06:40 | flaviu1 | fowl: I don't know, but I bet its from areas of ideological purity, and also a systems language can't use exceptions in certain areas. |
| 23:06:58 | flaviu1 | Araq: What is the error stack idea? |
| 23:09:21 | Araq | flaviu1: in a nutshell: 'raise' doesn't unwind the stack but pushes the error unto a global stack that you can query whenever you feel like. |
| 23:10:29 | * | freezerburnv joined #nimrod |
| 23:10:32 | Araq | on program exit the first error + its stack trace is listed, like an exception that has no 'except' handler right now |
| 23:11:46 | Araq | this can be used similar to a Lisp like condition system |
| 23:18:30 | dom96 | 'night |
| 23:18:56 | Araq | same here, goot night |
| 23:19:00 | Araq | *good |
| 23:19:51 | flaviu1 | I dunno, I prefer rust's approach with Fail, Ok |
| 23:20:55 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 23:22:11 | Araq | meh, C-like error handling sucks |
| 23:22:35 | springbok | amen, brother... |
| 23:23:18 | flaviu1 | I somewhat disagree, but I'll let you sleep |
| 23:23:57 | Varriount | Araq: Not yet. |
| 23:25:43 | * | freezerburnv quit (Quit: freezerburnv) |
| 23:32:33 | * | freezerburnv joined #nimrod |
| 23:34:13 | * | ehaliewicz joined #nimrod |
| 23:34:41 | BitPuffin | Araq: well you could probably do it in like 1-2 hours |
| 23:34:52 | BitPuffin | if you are as much of a bamf as you claim to be |
| 23:35:15 | BitPuffin | so think about it $250-500 dollsars/h is a pretty fuckin good pay |
| 23:39:53 | BitPuffin | hmm |
| 23:40:01 | BitPuffin | flaviu1: rust doesn't really do it C-style does it? |
| 23:40:17 | flaviu1 | It an Either ADT |
| 23:40:25 | flaviu1 | But it calls it Result |
| 23:40:46 | flaviu1 | I missed a few words |
| 23:42:10 | flaviu1 | Anyway, you basically get the benefits of Java-style tracked exceptions, with no overhead and much less implementation complexity. |
| 23:42:29 | * | ehaliewi` joined #nimrod |
| 23:42:45 | * | ehaliewi` quit (Remote host closed the connection) |
| 23:43:18 | Araq | flaviu1: no this is wrong |
| 23:45:11 | * | freezerburnv quit (Quit: freezerburnv) |
| 23:45:11 | * | ehaliewicz quit (Ping timeout: 260 seconds) |
| 23:45:54 | NimBot | Araq/Nimrod new_spawn 40baebe Araq [+1 ±3 -0]: pi test compiles, but crashes randomly |
| 23:47:19 | Araq | the Either ADT's overhead is often greater than exceptions |
| 23:47:51 | Araq | you can hide all these 'if's in a monad but that doesn't mean they are not there in the generated code |
| 23:48:07 | Araq | slowing down the common case |
| 23:48:53 | BitPuffin | how does exceptions get away from the ifs? |
| 23:49:11 | Araq | exceptions, if done via tables as most C++ implementations do them, do not slow down the common case |
| 23:49:37 | BitPuffin | but you take a beating when things go wrong? |
| 23:49:46 | Araq | yes. |
| 23:50:24 | BitPuffin | well one thing you often see though which kind of defeats the purpose of no overhead exceptions |
| 23:50:30 | BitPuffin | I guess it's exception abuse |
| 23:50:33 | BitPuffin | but some people do |
| 23:50:34 | flaviu1 | I like the way python does exceptions, where they aren't particularly exceptional. In cases like those, Option and Either work great. |
| 23:50:42 | BitPuffin | if someInput != whatIExpected: raise .... |
| 23:51:02 | BitPuffin | flaviu1: you a punny guy :P |
| 23:51:11 | BitPuffin | "exceptional" |
| 23:51:35 | flaviu1 | You may get a bit more overhead, but most methods to use exceptions will be things like IO, where a tiny bit more overhead is irrelevant. |
| 23:51:52 | flaviu1 | Haha, I didn't see that. I was just reusing wording I've read before, I never noticed that |
| 23:53:14 | BitPuffin | well if you are using python |
| 23:53:21 | BitPuffin | you are probably not worried about overhed |
| 23:54:54 | flaviu1 | I know, which is why I like ADTs in this case. You get to avoid the overhead of doing things the python way, and you keep the readability and excellent performance. |
| 23:56:03 | Araq | if readByte() != Ok: return Faliure |
| 23:56:11 | Araq | if readWord() != Ok: return Faliure |
| 23:56:16 | Araq | if readWord() != Ok: return Faliure |
| 23:56:28 | Araq | -> human compiler at work |
| 23:57:16 | flaviu1 | TBH, I feel that exceptions are like using a hash table. You're promised O(1) everything, which sounds nice, but with resizing and all, you get a giant constant factor |
| 23:57:40 | Varriount | BitPuffin: Actually, abusing exceptions for flow control in python can make things much slower |
| 23:58:05 | Varriount | BitPuffin: Mainly because of stack traces |
| 23:58:27 | flaviu1 | Want to hear a funny joke? Scala doesn't have a break statement, so they use exceptions to emulate one. |
| 23:58:48 | Varriount | Wat |
| 23:58:51 | flaviu1 | But the JVM optimizer is so good, that the overhead is only maybe double of just using a goto |
| 23:59:17 | Araq | yup, the JVM optimizes the heck out of non-local control flow |
