| 00:48:05 | * | q66 quit (Remote host closed the connection) |
| 00:52:52 | * | q66 joined #nimrod |
| 01:49:59 | * | XAMPP quit (Quit: My code has no bug's, just random features) |
| 02:01:21 | * | XAMPP joined #nimrod |
| 02:10:51 | * | filwit joined #nimrod |
| 02:11:06 | filwit | Araq, are you around? |
| 02:11:28 | dom96 | welcome back filwit! |
| 02:11:46 | dom96 | It's 3am where Araq is, I'm quite certain he is sleeping. |
| 02:25:30 | filwit | hi dom96 :) would say "long time" but we've been talking over Steam for awhile now |
| 02:25:39 | dom96 | ;) |
| 02:26:13 | * | q66 quit (Remote host closed the connection) |
| 02:57:05 | filwit | Hey Araq, after talking to Dom for awhile on Steam, I realized I should stop in and, at least, apologize for the way I ditched out on Nimrod awhile ago. |
| 03:02:03 | * | filwit quit (Ping timeout: 260 seconds) |
| 03:15:17 | * | filwit joined #nimrod |
| 03:19:35 | reactormonk | filwit, want to code anything? ^^ |
| 03:19:52 | reactormonk | filwit, or tinker around? |
| 03:20:15 | reactormonk | filwit, I'd like to know how to use nimrod serve, but zahary didn't leave any docs |
| 03:20:35 | * | filwit quit (Ping timeout: 255 seconds) |
| 03:25:23 | * | filwit joined #nimrod |
| 03:26:20 | filwit | reactormonk: sorry, got disconnected. could you reiterate what you where saying? |
| 03:28:15 | dom96 | reactormonk: I don't think filwit knows anything about nimrod serve. |
| 03:28:19 | filwit | reactormonk: I'm not sure what you mean by "nimrod serve". I was never a core developer of Nimrod. |
| 03:36:42 | dom96 | good night |
| 03:38:39 | reactormonk | filwit, I know. Read the source ;-) |
| 03:43:31 | reactormonk | and fiddle around with input |
| 03:46:07 | filwit | hey, sorry i missed par of the conversation and now don't have the logs |
| 03:46:20 | filwit | so i'm not sure what the source is :-/ |
| 03:46:58 | filwit | or did you mean, just read the Nimrod source? |
| 03:47:21 | filwit | in that case, I have actually read a bit of it |
| 03:51:50 | reactormonk | filwit, yeah, find out how nimrod serve works and document it - zahary doesn't seem to do it :-( |
| 03:52:52 | filwit | ahh, i see. Yeah documentation on the Nimrod internals was scarce when I was looking at it |
| 03:54:52 | reactormonk | filwit, not-so-much internal there |
| 03:54:56 | reactormonk | idetools got some documentation |
| 03:55:39 | filwit | i haven't followed the Nimrod updates in awhile, so I'm not sure what has changed |
| 03:59:17 | * | Anaphaxeton joined #nimrod |
| 04:03:27 | reactormonk | filwit, zahary added nimrod serve as compiler where you connect to via tcp or pipes |
| 04:03:34 | reactormonk | but I have no clue how to talk to it |
| 04:03:47 | * | fowl quit (Ping timeout: 248 seconds) |
| 04:03:48 | reactormonk | Big bonus: implement swank :-) |
| 04:04:25 | filwit | oh i see what you're saying now. Yes Dom told me compiler-as-a-service was added |
| 04:05:16 | filwit | very cool i know Dom wants to use if for Aporia |
| 04:05:43 | filwit | I'm not really here to start working on Nimrod again though |
| 04:06:15 | reactormonk | worth a try |
| 04:07:27 | filwit | I like the project and think Araq is an top-notch developer, but I think there are some big problems with Nimrod, for my purposes |
| 04:09:12 | filwit | I am mostly just here because I used to enjoy talking with everyone, and I left rather abruptly and never came back with explanation. |
| 04:09:26 | reactormonk | fix them :> |
| 04:10:03 | filwit | that is the problem, originally i thought Nimrod was practically perfect, it just lacked a few things |
| 04:10:50 | filwit | now I believe there are some fundamental design choices that stand in it's way, and are not good |
| 04:11:05 | filwit | and suggesting to change those things is completely unrealistic |
| 04:12:03 | reactormonk | now you are with? |
| 04:12:12 | filwit | no one |
| 04:12:48 | filwit | things happened in my life which removed a lot of my spare time to fiddle with languages |
| 04:13:00 | filwit | but i do comments and support D |
| 04:13:05 | filwit | comment on** |
| 04:13:36 | filwit | and for a time, I thought that was more suited for my game engines (and still do) |
| 04:14:10 | filwit | the problem I see with Nimrod, mostly has to do with consistency and encapsulation (i'm more of an OOP purist, in a way) |
| 04:15:16 | filwit | I wanted a language which would be useful as a game scripting language, and though nimrod fit that bill well |
| 04:16:08 | filwit | the problem is it's difficult to instantiate objects and work with type-specific global variables (static vars) in Nimrod |
| 04:17:00 | filwit | which would really complicate the game scripts overall, and I think fundamentally goes against the way humans mentally search for information |
| 04:18:51 | filwit | the problem is changing something like that in Nimrod would require waaay to much work, it would virtually be requesting a new language, and that's not fare of me to ask of someone else without contributing and equal amount of work in return (which I don't have time for). |
| 04:19:10 | filwit | which is the reason I basically ditched out awhile back. |
| 04:20:52 | filwit | That said, I really respect Araq as a developer and think he's one of the smartest people I've ever met. I just disagree with him on some fundamental issues (like hierarchy and encapsulation, like I said). |
| 04:38:59 | * | fowl joined #nimrod |
| 04:57:59 | * | filwit quit (Quit: Leaving) |
| 05:14:58 | * | Anaphaxeton quit (Remote host closed the connection) |
| 05:15:54 | * | Anaphaxeton joined #nimrod |
| 05:41:53 | * | Anaphaxeton quit (Ping timeout: 255 seconds) |
| 06:33:11 | * | fowl quit (Ping timeout: 255 seconds) |
| 06:42:00 | * | gour joined #nimrod |
| 07:13:24 | * | FreeArtMan joined #nimrod |
| 07:29:09 | * | fowl joined #nimrod |
| 09:06:36 | * | gour quit (Disconnected by services) |
| 09:06:37 | * | gour_ joined #nimrod |
| 10:39:31 | * | fowl quit (Ping timeout: 248 seconds) |
| 10:45:28 | * | XAMPP_8 joined #nimrod |
| 11:24:49 | * | q66 joined #nimrod |
| 11:57:47 | * | XAMPP_8_ joined #nimrod |
| 12:01:07 | * | XAMPP_8 quit (Ping timeout: 248 seconds) |
| 12:23:32 | * | Anaphaxeton joined #nimrod |
| 12:52:21 | * | Anaphaxeton quit (Quit: Αποχώρησε) |
| 13:18:30 | * | q66 quit (Remote host closed the connection) |
| 13:19:21 | * | q66 joined #nimrod |
| 13:20:43 | * | q66 quit (Remote host closed the connection) |
| 13:24:30 | * | q66 joined #nimrod |
| 13:27:11 | * | q66 quit (Remote host closed the connection) |
| 13:34:10 | * | q66 joined #nimrod |
| 13:40:01 | * | XAMPP_8_ quit (Ping timeout: 245 seconds) |
| 14:23:52 | * | Anaphaxeton joined #nimrod |
| 14:36:02 | * | FreeArtMan quit (Read error: Operation timed out) |
| 14:37:09 | * | q66 quit (Remote host closed the connection) |
| 14:38:29 | * | q66 joined #nimrod |
| 14:39:59 | * | zahary joined #nimrod |
| 14:44:57 | * | Anaphaxeton quit (Quit: Αποχώρησε) |
| 14:46:55 | * | Anaphaxeton joined #nimrod |
| 14:48:37 | * | q66 quit (Remote host closed the connection) |
| 14:51:54 | * | q66 joined #nimrod |
| 14:55:27 | * | q66 quit (Remote host closed the connection) |
| 14:55:37 | * | Anaphaxeton quit (Read error: Connection reset by peer) |
| 15:01:04 | * | q66 joined #nimrod |
| 15:04:01 | * | FreeArtMan joined #nimrod |
| 15:16:09 | * | Anaphaxeton joined #nimrod |
| 15:21:50 | * | FreeArtMan quit (Quit: rm -rf /) |
| 15:26:43 | * | gour_ is now known as gour |
| 15:58:10 | * | Anaphaxeton quit (Quit: Αποχώρησε) |
| 16:10:21 | * | Anaphaxeton joined #nimrod |
| 16:14:40 | * | q66 quit (Remote host closed the connection) |
| 16:14:57 | * | q66 joined #nimrod |
| 16:27:48 | * | Anaphaxeton quit (Read error: Connection reset by peer) |
| 16:39:48 | gour | "Later versions of Nimrod will support the FFI at compile time." means post 1.0? |
| 16:44:07 | reactormonk | gour, possible. |
| 16:44:20 | * | filwit joined #nimrod |
| 16:44:42 | filwit | hello Nimrod peoples! |
| 16:45:28 | filwit | is Araq around? |
| 16:45:32 | gour | hiya filwit |
| 16:45:40 | filwit | hi gour |
| 16:46:54 | gour | not yet |
| 16:47:18 | filwit | okay, that's fine |
| 16:47:37 | filwit | guess I'll just wait around in here for awhile |
| 16:51:03 | gour | interested for nimrod again? |
| 16:51:56 | filwit | half-n-half |
| 16:52:39 | filwit | i used to think Nimrod was close to perfect, but many of my ideas have changed since then on language design |
| 16:53:26 | gour | really? |
| 16:53:27 | filwit | that said, i still think Nimrod is "one of the few" language that gets most things right (performance, GC, power) |
| 16:53:49 | filwit | and i would love to see Nimrod get bigger |
| 16:53:58 | gour | i've decided to use nimrod for my project (multi-platform gui desktop app) as general-programming lang |
| 16:54:14 | filwit | awesome! |
| 16:54:28 | filwit | what kind of project exactly? |
| 16:54:52 | gour | something like http://saravali.de/ |
| 16:55:35 | filwit | oh interesting |
| 16:55:56 | gour | no gaming here :-) |
| 16:56:05 | filwit | :) |
| 16:56:46 | gour | i've chosen nimrod from the {ada,fpc/lazarus,nimrod,ocaml} set |
| 16:57:15 | gour | so far, i practically like all the design choices |
| 16:57:41 | gour | and yes, i was considering haskell & D2 in the past ;) |
| 16:57:51 | filwit | well I'm glad you like it. I disagree with some fundamental things |
| 16:58:06 | gour | e.g.? |
| 16:58:17 | filwit | i've sorta stepped between D and Nimrod as far as language design goes |
| 16:58:35 | filwit | both get things right where the other doesn't, IMO |
| 16:58:41 | gour | too much chaos in D for my taste |
| 16:58:52 | filwit | yes, i agree |
| 16:59:10 | filwit | the syntax is too complicated, and there's too many keywords |
| 16:59:18 | * | gour nods |
| 16:59:28 | filwit | though Nimrod is only just shy of that |
| 16:59:43 | filwit | it does make things better when using generics, etc |
| 16:59:48 | filwit | (to the user anyways) |
| 17:00:11 | Araq | so filwit I'm here and welcome back :-) |
| 17:00:18 | filwit | hi Araq |
| 17:00:26 | filwit | it's been awhile |
| 17:00:42 | filwit | good to talk to you again, though |
| 17:01:16 | filwit | idk if you read the log from last night, but I really wanted to say sorry for the way i ditched out suddenly on Nimrod before |
| 17:01:39 | gour | Araq: am i considered as being uninterrupted Nimrod 'user' ? |
| 17:01:49 | Araq | yeah I read the logs |
| 17:02:00 | Araq | nice you come back to apologize |
| 17:02:18 | Araq | as I implemented a few features just for you ;-) |
| 17:02:20 | filwit | there was multiple things that happened, but ultimately the reason why i didn't show back up here again is because I felt bad for basically ditching right after I said (to you directly) that I "would just leave" |
| 17:02:51 | filwit | great, i'm glad to hear things are move along |
| 17:02:57 | filwit | I would like to hear about the new features |
| 17:03:12 | Araq | no, I meant the closed features requests |
| 17:03:34 | Araq | you should have got a github notification for those |
| 17:03:35 | filwit | yeah I saw that those had been closed :) |
| 17:03:45 | Araq | gour: you are not considered to be a nimrod user yet :P |
| 17:04:01 | Araq | gour: as you still think you'll come very far with .noSideEffect. :P |
| 17:04:13 | gour | Araq: ohh, what shall i do to qualify? |
| 17:04:27 | gour | lol |
| 17:05:06 | Araq | filwit: you know that 'class' can be implemented as a macro, right? |
| 17:05:11 | reactormonk | Araq, can the idetools get whether you inferenced nosideffect? |
| 17:05:15 | Araq | and in fact, people have done exactly that |
| 17:05:31 | Araq | reactormonk: not yet, but it's not hard either |
| 17:05:43 | filwit | Araq: with statics & sub-classes? |
| 17:06:25 | filwit | Araq: a lot of the designs I used to think worked well before (like UFCS) I really don't like today |
| 17:06:25 | Araq | filwit: it can be done, I'm not sure if there are macros out there that support them |
| 17:06:41 | gour | any plan for mailing list or you'll stay with irc & forum? |
| 17:07:07 | Araq | we also have a stack overflow group which I never visit, gour |
| 17:07:17 | Araq | so ... please no mailing list |
| 17:07:19 | reactormonk | Araq, issue? |
| 17:07:23 | gour | ok |
| 17:07:40 | Araq | reactormonk: ugh, please not now, we already have to many open tickets |
| 17:07:48 | reactormonk | Araq, ok |
| 17:08:04 | Araq | filwit: so tell me about the designs you like |
| 17:08:04 | filwit | i noticed the number of open issues has grown a lot |
| 17:08:45 | Araq | yeah, partly due to lack of time on my part |
| 17:09:20 | filwit | pure OOP & strict, simple consistency |
| 17:09:41 | reactormonk | Araq, my pull request should kill two of them |
| 17:09:49 | filwit | ah i thought it might have just been more people where using and reporting issues :} |
| 17:09:59 | Araq | that the reason, yes |
| 17:10:04 | Araq | *the other |
| 17:10:17 | filwit | I say "pure OOP" btw, but I don't really mean it in the classical C# sense |
| 17:10:47 | Araq | the problem is: OO is not well defined |
| 17:10:49 | filwit | i just mean it as the first form of encapsulation (and therefore how we search for variable names) |
| 17:11:01 | filwit | yes, i know |
| 17:11:02 | Araq | I tend to define it as "dynamic binding" |
| 17:11:15 | Araq | and with that definition, there is no pure OO ;-) |
| 17:11:32 | Araq | as you cannot replace every 'if' with polymorphism |
| 17:11:34 | filwit | well that only accounts for function execution |
| 17:11:41 | Araq | you can make 'if' part of the bool object |
| 17:11:45 | Araq | like smalltalk does |
| 17:12:01 | filwit | i don't really OOP as a way of execution |
| 17:12:14 | filwit | but a way of catagorizing data |
| 17:12:37 | filwit | i was trying to explain to Dom last night about statics vs globals |
| 17:12:51 | filwit | (statics in an OOP language vs Nimrod globals) |
| 17:12:56 | Araq | but that's not OO, that's most likely an abstract data type |
| 17:13:27 | filwit | sure it is, all Object Oriented means things are "thought of" as objects |
| 17:13:41 | filwit | and that included their global, object-specific settings |
| 17:14:26 | Araq | statics are globals, only the scoping rules are different |
| 17:14:39 | filwit | yes exactly |
| 17:14:56 | filwit | and that's an important difference when trying to look of a variable (mentally) |
| 17:15:38 | filwit | the think I really don't like about C-style type/func/global separation, and UFCS |
| 17:16:04 | filwit | is it really complicates how the end-developer remembers where a specific variable is |
| 17:16:10 | filwit | or a specific function |
| 17:16:48 | filwit | i didn't realize that until I tried making issue 132 (https://github.com/Araq/Nimrod/issues/132) |
| 17:17:23 | filwit | and i had to try and follow your crazy abbreviation all over the place :P |
| 17:17:54 | filwit | no but seriously, it is a fundamental issue |
| 17:18:00 | Araq | it's not |
| 17:18:05 | Araq | it is just some aesthetic preference |
| 17:18:17 | Araq | you like nouns, I like verbs |
| 17:18:40 | filwit | i knew you where going to say that :) |
| 17:18:41 | gour | verbs = action :-) |
| 17:18:54 | filwit | but i actually think it's more scientific that just oppinion |
| 17:18:58 | Araq | and a macro can easily patch over it |
| 17:18:59 | filwit | opinion* |
| 17:19:32 | dom96 | hi there filwit |
| 17:19:42 | filwit | well, if it's a fundamental issue (like i believe), then macros should be needed to patch it |
| 17:19:46 | filwit | hi Dom :) |
| 17:20:27 | filwit | see, the reason it's not just a matter of opinion, is due to how someone finds something when looking through code he's not familiar with |
| 17:20:34 | filwit | (in my opinion) |
| 17:20:50 | filwit | when I see a function "foo(x, y)" |
| 17:21:18 | filwit | in Nimrod or C, it could be comming from anywhere in the 50 includes (or their includes) |
| 17:21:43 | filwit | in C#, that's not the case. Find the type, find the functions/var/whatever |
| 17:21:54 | filwit | and in reverse, when you're writing code |
| 17:22:04 | reactormonk | filwit, idetools tells you straight ahead where your proc is coming from |
| 17:22:05 | filwit | you think "i need to write this to the Console" |
| 17:22:22 | Araq | you are wrong about C# |
| 17:22:28 | filwit | so you start by typing "Console", and you know exactly what your options are after that |
| 17:22:31 | Araq | it has overloading just like Nimrod |
| 17:22:32 | Araq | in fact |
| 17:22:40 | Araq | it has like 5 different contexts |
| 17:22:48 | Araq | each with different overloading/lookup rules |
| 17:22:58 | * | FreeArtMan joined #nimrod |
| 17:23:03 | Araq | in Nimrod you only have 1-2 contexts depending on how you look at it |
| 17:23:05 | filwit | yes, Partial types, extension functions, hierarchy |
| 17:23:06 | filwit | i know |
| 17:23:14 | * | Anaphaxeton joined #nimrod |
| 17:23:45 | Araq | if you really care about that, you need to do it like Go does |
| 17:23:47 | filwit | I don't think C# is perfect, btw (far from it), but I even with those things, "pure OOP" helps you find what you're looking for |
| 17:24:25 | filwit | what exactly does Go do that you're talking about? |
| 17:24:32 | Araq | once idetools works you indeed have to move your mouse over the 'foo' to see where it is coming from |
| 17:24:40 | Araq | big deal :P |
| 17:24:55 | filwit | i also mentioned how you write code |
| 17:25:02 | filwit | it makes a big difference |
| 17:25:16 | Araq | obj.| # suggestions here please |
| 17:25:22 | Araq | works too in aporia |
| 17:25:39 | Araq | well as good as the idetools implementation is working right now anyway |
| 17:25:41 | filwit | yes, now do global varaibles |
| 17:25:45 | filwit | variables |
| 17:25:50 | Araq | gObj.| ? |
| 17:25:51 | filwit | and sub-types |
| 17:26:13 | filwit | yes exactly, you had to change the name |
| 17:26:23 | Araq | not really |
| 17:26:27 | Araq | module.obj.| |
| 17:26:28 | filwit | GC.dosomething vs GC_somevar |
| 17:26:45 | Araq | yeah, big difference |
| 17:26:52 | Araq | '.' is sexy, '_' is not |
| 17:27:09 | filwit | it's not just about "sexy" it's consistency |
| 17:27:23 | filwit | it's about finding and associating information |
| 17:28:02 | filwit | when you separate things, it doesn't enforce and rules on how to classify things |
| 17:28:26 | filwit | ultimately a programmer can categorize something however |
| 17:28:41 | filwit | i know you're going to say it's completely arbitrary |
| 17:28:47 | filwit | and ultimately, you're right |
| 17:29:21 | filwit | i can write bad names for things |
| 17:29:49 | filwit | my points, is that if they'res not any rules to it, you're going to get a ton of people writing bad names waay more often |
| 17:29:58 | filwit | and it's going to really confuse "the right way" |
| 17:30:15 | filwit | and that becomes a problem with reading other peoples code |
| 17:30:37 | filwit | when I hacked on Aporia, everything was easy |
| 17:31:04 | filwit | but when I tried to modify Nimrod itself, it was incredibly difficult to even find what I was looking for |
| 17:31:05 | Araq | until? |
| 17:31:29 | gour | filwit: that's hacking app vs compiler. isn't it a big difference? |
| 17:31:44 | Araq | the compiler also uses dynamic typing |
| 17:31:51 | filwit | i have hacked on large projects before, gour |
| 17:32:04 | Araq | which is the real issue you encountered |
| 17:32:30 | filwit | dynamic typing? |
| 17:32:35 | Araq | it basically only uses PSym, PType and PNode everywhere |
| 17:32:44 | filwit | ah i see |
| 17:32:44 | Araq | 3 types |
| 17:32:56 | Araq | dynamic typing would mean 1 type, ok ;-) |
| 17:33:24 | Araq | and it's been translated from Pascal btw |
| 17:33:49 | Araq | which put some restrictions on the design |
| 17:34:09 | filwit | yeah i remember that, and please don't think I'm putting down your work. Obviously you can code better than most everyone I know. |
| 17:34:53 | Araq | plus the compiler contains a big recursive dependency |
| 17:34:53 | filwit | i understand that Nimrod is a big project, and not all the code internals are perfect |
| 17:35:05 | Araq | and Nimrod's module system doesn't handle cycles well |
| 17:35:24 | Araq | which means often I resorted to include instead of import |
| 17:35:42 | Araq | which means it's even more difficult to find stuff |
| 17:36:11 | gour | filwit: i did not mean small vs big, but the nature of projects |
| 17:37:35 | filwit | gour: sure, but it doesn't really have too much to with what I'm saying |
| 17:38:26 | filwit | gour: ultimately i was using Aporia vs. Nimrod as a code complexity level at which Nimrods flat function calls breaks down (IMO) |
| 17:38:35 | filwit | to illustrate ** |
| 17:39:06 | filwit | btw, when D first added UFCS, i was all for the feature, now I think it's a big problem for the language |
| 17:39:53 | Araq | brb |
| 17:40:18 | filwit | i hope the best for both Nimrod and D, but I'm admittedly a perfectionist, and there are things I disagree with about both strongly |
| 17:40:50 | gour | there is no perfection in CS ;) |
| 17:41:04 | filwit | CS ? |
| 17:41:11 | gour | computer science |
| 17:41:12 | filwit | oh, nvr |
| 17:41:21 | filwit | yeah, don't know why that didn't register |
| 17:41:39 | filwit | and yeah, things are really hard to get right in language design, i agree |
| 17:41:58 | filwit | i actually started making my own Toy language (like I told Dom last night) |
| 17:42:23 | gour | i like that nimrod is very pragmatic for real world with beautiful syntax...something i haven't encountered since haskell |
| 17:42:53 | filwit | yes I really like certain things about Nimrod's syntax |
| 17:42:58 | filwit | no ';' |
| 17:43:02 | gour | ..but much more useful for practical worl |
| 17:43:04 | gour | *work |
| 17:43:08 | filwit | keywords are simple, etc |
| 17:43:21 | gour | very clean and readable |
| 17:43:48 | filwit | what I find very telling about Nimrod, is that you have two different "new()" functions to create a type vs an array |
| 17:43:56 | gour | not bloated as ada.. |
| 17:44:23 | filwit | I've never used ADA but I really don't like VB-style syntax |
| 17:45:16 | gour | i'm also not at all impressed with Go & Rust attempts...so nothing much is left if we exclude lispy-ones & java stuff |
| 17:45:36 | filwit | Go is not so bad |
| 17:45:40 | filwit | Rust is horrible |
| 17:45:47 | filwit | waaay to many symbols |
| 17:46:10 | dom96 | I don't find Go all that impressive. It doesn't have generics for example. |
| 17:46:42 | filwit | Go generics just haven't been made yet |
| 17:46:48 | filwit | but it was always intended to have them |
| 17:46:53 | filwit | that said, i agree with you |
| 17:47:00 | filwit | i don't like Go for other reasons |
| 17:47:08 | filwit | (no overloads or operators) |
| 17:47:19 | dom96 | Also that visibility is determined by whether the first letter of a symbol is uppercase... |
| 17:47:21 | filwit | and no hierarchy |
| 17:47:23 | Araq | and yet you argued against overloading |
| 17:47:38 | filwit | i never argued against overloading... |
| 17:47:47 | filwit | i think overloading is very important |
| 17:47:56 | Araq | foo(a, b) is not as "readable" with overloading |
| 17:48:16 | Araq | well it's superficial anyway as it's resolved at compile-time |
| 17:48:26 | filwit | sure it is, because you know what 'a' and 'b' |
| 17:48:38 | Araq | not really, it can get complex |
| 17:48:40 | filwit | even if it's foo(GlobObj.a, b) |
| 17:48:49 | Araq | but as I said, it's a mouse-over away |
| 17:49:02 | Araq | like type inference |
| 17:49:02 | filwit | it should be an "eyes over" |
| 17:49:23 | Araq | with the proper device it may be one day ;-) |
| 17:49:51 | Araq | also I'm a bit annoyed that you consider Nimrod's syntax VB-like |
| 17:50:00 | filwit | no i never said that |
| 17:50:04 | filwit | i was talking about ADA |
| 17:50:10 | Araq | oh alright |
| 17:50:45 | filwit | a bit off-topic. I have found a way to do memory safety without a GC |
| 17:50:57 | Araq | no you have not |
| 17:51:09 | filwit | yeah that's what i thought too |
| 17:51:11 | filwit | for the longest time |
| 17:51:19 | Araq | *I* thought I found a way |
| 17:51:29 | Araq | until I realized I subtly changed the requirements :P |
| 17:51:33 | filwit | then I hear that Parasail language is actually doing (my same) idea now |
| 17:51:55 | filwit | oh it's true, Dynamic arrays still require extra bookkeeping |
| 17:52:01 | filwit | but they are the only ones |
| 17:52:11 | filwit | and they *can be* self contained |
| 17:52:21 | Araq | well it depends on how you define memory safety |
| 17:52:22 | filwit | (ie, they manage their own lists) |
| 17:52:32 | Araq | it's either easy or impossible to do without a GC then |
| 17:52:58 | filwit | memory safety meaning: if you check a reference to a variable that was deleted, it is NULL |
| 17:53:11 | * | exhu joined #nimrod |
| 17:53:12 | filwit | and variables are automatically cleaned up |
| 17:53:22 | filwit | (implicitly) |
| 17:53:23 | Araq | Ada is memory safe without a GC since the 80ies |
| 17:53:31 | filwit | what really? |
| 17:53:48 | Araq | if you don't use the heap, yes :P |
| 17:54:02 | filwit | well that's not fair |
| 17:54:10 | gour | why not? |
| 17:54:11 | filwit | lol |
| 17:54:22 | filwit | cause you _have_ to use the heap |
| 17:54:24 | filwit | at some point |
| 17:54:45 | Araq | nah |
| 17:55:07 | Araq | you can "easily" avoid it. always. |
| 17:55:34 | filwit | well anyways, my idea is very simple and it works** (on paper) |
| 17:55:38 | Araq | but you have to give up your dynamically sized arrays then |
| 17:56:19 | Araq | which is what you need to do for guaranteed bounded memory usage anyway |
| 17:56:21 | filwit | are you talking about ADA or my idea? |
| 17:56:25 | Araq | about ada |
| 17:56:31 | filwit | oh |
| 17:56:59 | filwit | yeah that sounds restrictive |
| 17:58:51 | filwit | anyways, I'm glad to be talking with you folks again |
| 17:59:17 | filwit | sorry i left so suddenly. |
| 17:59:29 | filwit | i will help in small ways (like graphics and stuff) if I can |
| 18:01:09 | Araq | awesome |
| 18:01:15 | filwit | and I do hope Nimrod does well, it does get many thing right |
| 18:01:35 | Araq | thanks |
| 18:02:13 | Araq | about memory safety: |
| 18:02:36 | Araq | when you have traditional alloc/free, there are 3 things that can go wrong: |
| 18:02:42 | Araq | a) forget to 'free' something |
| 18:02:49 | Araq | b) 'free' something twice |
| 18:03:04 | Araq | c) access to something that has been freed |
| 18:03:18 | Araq | (c) is the crucial point |
| 18:03:25 | Araq | (a) does not produce crashes |
| 18:03:53 | Araq | and (b) can be easily checked in the memory allocator if it uses per type/per size allocations |
| 18:04:26 | filwit | my idea handles all three |
| 18:04:38 | Araq | then I'm interested :-) |
| 18:05:03 | filwit | in my idea, you have a strict distinction between a "memory owner" (var), and a "memory reference" (ref) |
| 18:05:13 | filwit | (there's also unmanaged 'ptr' types) |
| 18:05:34 | filwit | vars are non-null, they are allocated "at definition" |
| 18:05:46 | filwit | refs cannot "own" memory |
| 18:06:16 | filwit | vars are automatically cleaned at the end of the scope (or deleted with their containing type, etc) |
| 18:06:25 | gour | a) produces leaks which can eventually cause crashe, right? |
| 18:07:06 | Araq | "out of memory" doesn't count as crash ;-) |
| 18:07:07 | filwit | refs are automatically set to null at the end of the scope, either statically (when the compiler can determine it) or though a dynamic ref list |
| 18:07:21 | filwit | there are some tricks, but it works |
| 18:07:30 | filwit | the biggest problem is Dynamic Arrays |
| 18:07:37 | filwit | which i have found a good solution too |
| 18:08:00 | filwit | for the longest time i thought there was some obvious thing I was missing about the design |
| 18:08:12 | Araq | "a dynamic ref list"? does that mean you track the locations that contain the pointer? |
| 18:08:15 | filwit | but then the new language Parasail basically said it was doing the same thing |
| 18:08:58 | filwit | no... it's hard to picture.. let me right a simple Gist so you can see real quick |
| 18:09:24 | filwit | basically var/ref are very tightly linked to their containing scope |
| 18:09:30 | filwit | one sec |
| 18:12:02 | filwit | https://gist.github.com/PhilipWitte/4962210 |
| 18:13:33 | filwit | so that's the basic idea, there is more to it obviously (like how functions return variables, etc) |
| 18:14:56 | filwit | (basically a returned var isn't cleaned up, but instead "injected" [theoretically speaking] into the scope that called the function, and it's cleaned up at the end of that [unless returned from their as well]) |
| 18:18:00 | gour | Araq: have you ever used modula-2? |
| 18:18:23 | Araq | gour: only played with it for a couple of days iirc |
| 18:18:41 | Araq | I was happy to find an implementation for the PC |
| 18:18:57 | Araq | it was some commercial compiler, I don't remember the name |
| 18:19:22 | Araq | filwit: your gist doesn't show up for me |
| 18:19:58 | filwit | hmm.... |
| 18:20:11 | Araq | filwit: interesting, it was my thought too that part of the problem is that algol conflated the execution stack with the data stack |
| 18:20:51 | gour | Araq: was it, in your opinion, improvement over pascal? |
| 18:21:14 | Araq | so that the data's lifetime ends when the proc returns and so it has to copy things back or pass an implicit pointer to the result |
| 18:21:49 | filwit | Araq: yeah exactly |
| 18:21:50 | filwit | https://gist.github.com/PhilipWitte/4962210 |
| 18:21:54 | filwit | ^ can you see that? |
| 18:22:11 | * | gour could see it |
| 18:22:39 | filwit | also: here's an illustration of the Dynamic Array problem: https://gist.github.com/PhilipWitte/4962210 |
| 18:22:48 | filwit | shit.. that's the same one... |
| 18:23:00 | filwit | https://gist.github.com/PhilipWitte/4962255 |
| 18:23:15 | filwit | ^dynamic array problem. (I have a solution) |
| 18:23:47 | filwit | (it's sorta-simple, but complicated to explain) |
| 18:24:07 | filwit | but yes, basically the lifetime of an object is directly tied to its scope |
| 18:24:18 | filwit | refs are only there to point to other variables |
| 18:24:30 | filwit | to link things together dynamically |
| 18:24:46 | filwit | but they can never own data, and you can't "delete" a var |
| 18:25:00 | filwit | so you'll never get a "dangling reference" and then loose it |
| 18:25:01 | * | XAMPP_8_ joined #nimrod |
| 18:25:53 | filwit | also, not there's a difference (in my pseudo code) between '=' and '=>' |
| 18:26:23 | filwit | '=' is always "copy data", and '=>' is "set reference" |
| 18:26:35 | filwit | => can only be used on ref types |
| 18:27:10 | filwit | but refs (if not null) can also use '=' |
| 18:28:00 | exhu | filwit, not sure if it'll work with recursion/cycles |
| 18:28:04 | filwit | in that way, you only really need on "type" (no struct/class)... granted, you'd have to do a lot of static analysis to optimize away virtual tables, etc |
| 18:28:19 | filwit | exhu: how so? |
| 18:28:30 | filwit | exhu: what are your thoughts? |
| 18:29:00 | filwit | i'm pretty sure recursion should work (to an extent) though idk what you mean by "cycles" exactly |
| 18:29:15 | filwit | i also never liked recursion as a programming practice... |
| 18:30:08 | filwit | ... so i wouldn't even really care if something else was done in it's place (if that's even possible) |
| 18:30:20 | Araq | gour: modula 2 is not too bad, better than ISO pascal and oberon, but it's dead |
| 18:30:24 | filwit | also, remember there's always the "ptr" type, which is entirely unmanaged |
| 18:30:38 | exhu | filwit, you have to create object somewhere (heap), how can it store all in a function |
| 18:30:50 | filwit | so any issues involving the var/ref structure could be worked around (manually) with 'ptr' |
| 18:31:28 | Araq | so essentially 'ref' is a *weak* reference in your language |
| 18:31:31 | filwit | exhu: var's are actually references when they need to be. It's not about heap vs stack |
| 18:31:40 | filwit | exhu: it's about "ownership" |
| 18:32:05 | filwit | Araq: yes, but no ref-counting required |
| 18:32:33 | filwit | Araq: plus, all references are direct (like C), no need to point to a managed heap |
| 18:32:57 | gour | how long is 'do notation' presenrt in nimrod? i haven't notice it before |
| 18:33:15 | filwit | Araq: so it's also should be faster to access type data (Type* vs Type** <- GC languages) |
| 18:33:16 | Araq | gour: it's currently broken, that's how new it is |
| 18:33:25 | gour | :-) |
| 18:33:47 | filwit | anyways, thanks for taking a look at it Araq |
| 18:33:57 | filwit | (and exhu, gour) |
| 18:34:11 | Araq | filwit: the problem is: is 'ref' a first class citizen in your language? |
| 18:34:18 | filwit | yes |
| 18:35:19 | filwit | however, 'ref' aren't guaranteed to "own" their data. They're just pointers that get automatically set to null when their pointed data is deleted |
| 18:35:45 | filwit | you can't do: ref r = new Foo() |
| 18:35:51 | Araq | but you cannot do that without runtime overhead in the general case |
| 18:36:27 | filwit | actually, i've thought about it awhile, and many man cases can be statically optimized out |
| 18:36:45 | filwit | because vars are always tied to their scope |
| 18:36:53 | filwit | the compiler can figure a lot of stuff out |
| 18:37:08 | filwit | but yes, in some cases (like with Dynamic Arrays), you need more bookkeeping |
| 18:37:13 | Araq | arrayOfRefs[complexFoo(x,y)] => someRef |
| 18:37:32 | Araq | # resets every ref at scope exit? |
| 18:37:59 | filwit | no, the bookkeeping is handedled by the dynamic array itself |
| 18:38:43 | filwit | wait one sec, let me think about that |
| 18:38:54 | Araq | you need to create a list of locations to set to 'nil' at scope exit for the general case |
| 18:39:08 | filwit | yes exactly |
| 18:39:10 | Araq | it's true you can sometimes optimize it away |
| 18:39:32 | Araq | but note that the list needs to be growable at runtime for the general case |
| 18:39:40 | filwit | often you can (because of the other restrictions), but yes Dynamic Arrays need to retain a "reverse ref list" |
| 18:40:15 | Araq | you cannot keep that list in the dynamic array |
| 18:40:31 | Araq | you would need a stack of these lists then in the dynamic array |
| 18:40:32 | filwit | that "revers list" is used to set check-n-null references when an item is removed from the array, etc |
| 18:40:42 | filwit | damn.. Araq |
| 18:40:47 | filwit | your freaking smart |
| 18:41:08 | Araq | the list is scope bound |
| 18:41:18 | Araq | but not to the same scope as your dynamic array |
| 18:41:21 | Araq | ;-) |
| 18:42:02 | filwit | well that's not a problem |
| 18:42:11 | filwit | all the list is used for is to set refs to null |
| 18:42:28 | filwit | and it's just a stack that can be used by any dynamic array |
| 18:42:46 | filwit | (so they're not constantly allocating every time you reference something in them) |
| 18:42:53 | filwit | (it's more for optimization) |
| 18:43:15 | Araq | well yeah you have a shadow stack |
| 18:43:15 | filwit | There's also another layer |
| 18:43:41 | filwit | see the problem is you would have a lot of those "reverse references" being created |
| 18:43:57 | filwit | say you have a loop, which references something, then dereferences it |
| 18:44:02 | Araq | yep |
| 18:44:30 | filwit | you wouldn't want to, on dereference, search the shadow-stack just to see if the ref was pointing to the dynamic array |
| 18:44:35 | filwit | (if that makes sense) |
| 18:44:53 | filwit | so what you can do, is make two types of refs |
| 18:45:01 | filwit | one that's dynamic, and one that's static |
| 18:45:15 | filwit | you still only have one ref keyword |
| 18:45:19 | filwit | and the compiler chooses |
| 18:46:01 | filwit | but the dynamic ref will contain and extra reference to the shadow stack, then when you reset that ref, it tell informs the shadow stack |
| 18:46:23 | filwit | so you avoid searching the list that way |
| 18:46:34 | Araq | perhaps but you're reinventing automatic memory management aka GC |
| 18:46:45 | filwit | lol |
| 18:46:48 | Araq | the question is: why? |
| 18:46:59 | Araq | what is your problem with GC? |
| 18:47:10 | filwit | no problem, just an improvement |
| 18:47:34 | reactormonk | Araq, too much attention seeking people in the IRC to get coding` ^^ |
| 18:48:09 | filwit | reactormonk: sorry if i'm taking to much of everyone's time |
| 18:48:42 | reactormonk | filwit, I enjoy these theoretic discussions as well, but they are not bound to get us anywhere |
| 18:49:08 | filwit | np, I will leave you to it then |
| 18:49:33 | reactormonk | filwit, ask Araq, it's his time. |
| 18:50:00 | exhu | a bit offtopic (GC stuff is not my strongest side, especially after some beer =), but is there a yaml parser in/for nimrod? |
| 18:50:10 | Araq | I have a headache anyway, reactormonk :P |
| 18:50:23 | reactormonk | Araq, too much beer? |
| 18:50:28 | reactormonk | exhu, iirc nope |
| 18:50:31 | reactormonk | exhu, use JSON |
| 18:50:43 | Araq | exhu: reactormonk is right |
| 18:50:48 | exhu | reactormonk, i don't like curly braces =) |
| 18:51:16 | Araq | use c2nim to wrap a yaml parser then |
| 18:51:28 | Araq | I started a yaml parser once and then decided the spec is too big |
| 18:51:46 | Araq | it's overengineered IMHO |
| 18:51:48 | reactormonk | exhu, maybe bring the spirit of nimrod over a yaml parser |
| 18:52:00 | Araq | and yet is not really as nice for config stuff as ini files |
| 18:52:42 | Araq | JSON on the hand lacks important syntactic sugar for config files ... |
| 18:53:09 | Araq | and is underengineered with quotes everywhere |
| 18:53:19 | reactormonk | Araq, it's a simple XML |
| 18:53:28 | Araq | argh not again |
| 18:53:37 | reactormonk | >:) |
| 18:53:41 | Araq | XML is for *documents* aka semi-structured data |
| 18:53:46 | Araq | JSON is not |
| 18:54:01 | reactormonk | JSON is kinda structured data |
| 18:54:17 | Araq | JSON is not semistructured, it is structured, yes |
| 18:54:51 | exhu | the company i work for has released several game titles with a lot of yaml for configs, UI etc. so i don't see why ini/json is syntactically better. however i'd choose the already implemented json/ini parser, ok. |
| 18:55:13 | exhu | XML is hell! |
| 18:55:17 | Araq | exhu: alright interesting |
| 18:56:04 | Araq | it's a question of taste, I still prefer ini files over yaml |
| 18:56:26 | exhu | have not used ini since 1990s |
| 18:57:31 | Araq | zahary: I came up with a generational GC algorithm for the compiler and then I found it's quite like this one: http://doc.pypy.org/en/latest/garbage_collection.html#minimark-gc |
| 18:58:52 | Araq | except that mine will not use a moving collector for the nursery |
| 18:59:44 | exhu | BTW i have started writing ORM in nimrod for my small sqlite app, but then confronted the problem of limited RTTI (TAny can tell you that the field is of type "object" and not TMyEntity, TMyAnotherEntity etc. And then i found a lot of articles in the internet about how bad ORM is at all -) Now thinking over the method to describe my tables and runtime representation in one place... |
| 19:01:36 | Araq | I would use a DSL for that |
| 19:01:47 | Araq | and let macros generate a typesafe ORM |
| 19:02:16 | Araq | but I think it's currently too hard as the type API is incomplete |
| 19:03:08 | exhu | I tried to develop a solution with templates and macros, but it's too complex. Another idea was to describe data structures in yaml and generate sql schema and requests, validation etc from yaml. |
| 19:03:37 | Araq | sounds like a plan |
| 19:03:47 | exhu | i don't want to make the same overengineering as java frameworks do. |
| 19:05:08 | exhu | so i decided to not write ORM but to use strings and dynamic hash tables rather than objects/tuples. |
| 19:05:33 | Araq | you can "easily" convert the hash back into an object |
| 19:06:10 | Araq | don't ask me how, copy&paste how marshal.nim does it :P |
| 19:10:59 | exhu | Araq, thanks, this module may be of some use to me. |
| 19:12:05 | exhu | about INI files, how hierarchies/trees can be handled in ini files? it's about sections and name=value AFAIK |
| 19:31:10 | Araq | exhu: true but that's a feature |
| 19:31:25 | Araq | but I always thought you could easily extend the syntax a bit: |
| 19:31:29 | Araq | [section] |
| 19:31:37 | Araq | [[subsection A]] |
| 19:31:41 | Araq | key = value |
| 19:31:47 | Araq | [[subsection B]] |
| 19:31:49 | Araq | etc. |
| 19:55:46 | exhu | i see |
| 19:55:59 | exhu | i'll also try lua -) |
| 20:25:46 | * | exhu quit (Quit: Ex-Chat) |
| 20:26:16 | * | XAMPP_8_ quit (Ping timeout: 245 seconds) |
| 20:37:12 | NimBot | Araq/Nimrod 8009eb2 Simon Hafner [+5 ±21 -5]: EcmaScript => JS. Fixes #330... 3 more lines |
| 20:37:12 | NimBot | Araq/Nimrod e59ae14 Araq [+5 ±21 -5]: Merge pull request #333 from Tass/master... 3 more lines |
| 21:13:00 | * | filwit quit (Quit: Leaving) |
| 21:21:30 | * | FreeArtMan quit (Quit: rm -rf /) |
| 21:25:20 | * | gour quit (Quit: WeeChat 0.4.0) |
| 21:55:06 | * | Anaphaxeton quit (Quit: Αποχώρησε) |
| 22:01:59 | * | Anaphaxeton joined #nimrod |
| 22:08:33 | reactormonk | Araq, how would I set node to run the js tests? |
| 22:09:02 | Araq | well the 'node' executable has to be in your path |
| 22:09:20 | Araq | and you need to pass -d:nodejs to the compiler but you know that |
| 22:12:32 | reactormonk | Araq, yep, but does it run it with node? |
| 22:12:48 | Araq | what do you mean? |
| 22:13:07 | reactormonk | the tests. |
| 22:13:11 | Araq | nimrod js -r -d:nodejs helloworld.nim |
| 22:13:14 | Araq | works for me |
| 22:13:20 | reactormonk | oh. ok. |
| 22:13:30 | reactormonk | stuff in tests/ that is |
| 22:13:32 | Araq | and the tests don't work |
| 22:14:30 | * | XAMPP-8 joined #nimrod |
| 22:15:04 | Araq | have a look at tests/specials, runJsTests |
| 22:15:26 | Araq | they are not active as the test machines have no node installed |
| 22:27:59 | reactormonk | huh |
| 22:28:02 | reactormonk | install it? |
| 22:29:50 | Araq | I can't be bothered :P |
| 23:06:09 | * | Zerathul joined #nimrod |
| 23:06:11 | * | XAMPP-8 quit (Ping timeout: 248 seconds) |
| 23:49:21 | * | Zerathul quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344]) |
| 23:50:00 | reactormonk | should be easy on a linux box |
| 23:51:58 | reactormonk | Araq, btw: http://asmjs.org/spec/latest/ |