| 00:00:41 | * | darkf quit (Quit: Leaving) |
| 00:03:56 | * | darkf joined #nimrod |
| 00:05:48 | * | willwillson quit (Ping timeout: 250 seconds) |
| 00:07:14 | ldlework | gokr1: does gradha ever come in here? |
| 00:07:30 | gokr1 | Not sure |
| 00:08:29 | gokr1 | I guess you saw: http://forum.nimrod-lang.org/t/141 |
| 00:11:07 | * | Trustable quit (Quit: Leaving) |
| 00:14:21 | ldlework | no |
| 00:17:24 | Jehan_ | Nim has a destructor pragma. |
| 00:17:36 | Jehan_ | Which handles stack allocations/deallocations. |
| 00:18:09 | Jehan_ | Heap finalization is currently done using new(variable, finalizer). |
| 00:18:20 | Jehan_ | I believe Araq mentioned he wanted to unify the approaches. |
| 00:18:56 | Jehan_ | Personally, I think there's little need for RAII in any language that has automatic memory management and higher order functions. |
| 00:20:50 | ldlework | Jehan_: did you read my article? |
| 00:21:20 | Jehan_ | Which article? I was mostly idle and there were a ton of URLs flying around ... |
| 00:21:26 | Jehan_ | None of which I looked at. |
| 00:21:34 | ldlework | blog.ldlework.com/a-cursory-look-at-meta-programming-in-nim/ |
| 00:21:38 | ldlework | ^ |
| 00:23:00 | Jehan_ | Neat. :) |
| 00:23:21 | Jehan_ | I see you've discovered getAst() already. |
| 00:23:49 | ldlework | I think will showed me that one |
| 00:25:06 | gokr1 | ok, gnite |
| 00:27:12 | ldlework | o/ |
| 00:34:58 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 00:35:22 | Varriount | ldlework: ping |
| 00:35:28 | ldlework | hi |
| 00:35:49 | Varriount | ldlework: You need to insert a comma on line 9, after the second word. |
| 00:36:29 | Varriount | I'd also suggest revising that sentence - while it's not a run-on, it's a bit long. |
| 00:36:42 | ldlework | Varriount: heh ok |
| 00:38:11 | Varriount | ldlework: Your nickname is interesting. I kept wondering why tab completion wasn't working for your nickname until I discovered that, in my client's font, uppercase I and lowercase l look the same |
| 00:38:20 | ldlework | Varriount: ;) |
| 00:40:17 | * | xenagi quit (Quit: Leaving) |
| 00:41:21 | * | dapz joined #nimrod |
| 00:42:59 | * | boydgreenfield joined #nimrod |
| 00:44:22 | * | superfunc_ quit (Ping timeout: 246 seconds) |
| 00:53:12 | * | mko quit (Quit: Bye.) |
| 01:10:40 | * | BitPuffin joined #nimrod |
| 01:15:10 | * | brson quit (Quit: leaving) |
| 01:15:38 | * | brson joined #nimrod |
| 01:24:47 | * | BitPuffin quit (Ping timeout: 255 seconds) |
| 01:32:25 | * | dapz quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 01:35:58 | * | Jehan_ quit (Quit: Leaving) |
| 01:58:14 | * | BitPuffin joined #nimrod |
| 02:00:15 | * | superfunc joined #nimrod |
| 02:01:14 | Varriount | gokr1: Oooh! I have an item for the 'Common Critisisms' page - Why Nimrod doesn't use wide character strings by default, or use utf-8 aware slicing |
| 02:01:40 | Varriount | The only problem is that I don't know how to justify that design decision very well... |
| 02:05:47 | * | BitPuffin quit (Remote host closed the connection) |
| 02:10:13 | * | flaviu quit (Ping timeout: 258 seconds) |
| 02:10:17 | * | BitPuffin joined #nimrod |
| 02:11:58 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 02:14:11 | * | ____________Josh joined #nimrod |
| 02:14:34 | * | Jesin quit (Quit: Leaving) |
| 02:15:01 | ____________Josh | I want to start hacking, basically on anything would like to know the lanauge to start off with and resources to learn from? |
| 02:15:28 | Varriount | ____________Josh: Have you read the tutorials? |
| 02:16:10 | * | Jesin joined #nimrod |
| 02:21:40 | ____________Josh | what tutorials ? |
| 02:23:23 | superfunc | ____________Josh: http://nim-lang.org/tut1.html |
| 02:23:35 | superfunc | http://nim-lang.org/tut2.html |
| 02:23:54 | superfunc | ____________Josh: http://nimrod-by-example.github.io/ <-- Start with this one |
| 02:24:16 | superfunc | Then read the two other tutorials I linked |
| 02:24:38 | Varriount | superfunc saves the day yet again! :3 |
| 02:24:45 | superfunc | After that, you could read the language manual if you like: http://nim-lang.org/manual.html |
| 02:24:56 | superfunc | I'm quite the secretary, I've been told |
| 02:25:59 | * | ____________Josh quit (Ping timeout: 255 seconds) |
| 02:26:39 | Varriount | superfunc: I wouldn't mind developing Nim as a job. I quite like typing up tutorials, documentation, and the like. |
| 02:27:01 | * | ____________Josh joined #nimrod |
| 02:27:11 | Varriount | The only problem is that A: I can't develop Nim as a job, and B: I'm too meticulous to do anything quickly. |
| 02:27:17 | ____________Josh | never heard of the language before :s |
| 02:28:18 | superfunc | Tell your friends |
| 02:28:49 | superfunc | Varriount: I don't mind doing it, I just need the initial kick to do it |
| 02:29:08 | ldlework | ____________Josh: contribute to nim-by-example |
| 02:29:14 | * | BitPuffin quit (Ping timeout: 250 seconds) |
| 02:29:38 | ldlework | or I mean Varriount |
| 02:29:45 | ____________Josh | Thank you and I will |
| 02:30:17 | superfunc | I was thinking about adding a section on Nimble to Nim by example, but I thought it may be too self-explanatory |
| 02:30:54 | * | Varriount is now known as Idlework |
| 02:31:13 | Idlework | Now we're twins. :D |
| 02:33:49 | * | Idlework is now known as Varriount |
| 02:35:17 | Varriount | Araq: I've fixed the compiler configuration code when compiling to c++, however I think there may be some information missing for other C++ compilers in nim.cfg - I can only find default configuration options for c++ |
| 02:35:25 | Varriount | I mean, for g++ |
| 02:38:18 | * | ____________Josh left #nimrod (#nimrod) |
| 02:42:57 | ldlework | superfunc: nothing is too self-explanatory |
| 02:42:57 | Varriount | Araq: Oh, and you'll be happy to know that the Nim compiler compiles succesfully into a c++ program. |
| 02:47:18 | superfunc | Ok, when I finish the post I'm writing on the library I'm finishing up, I'll go ahead and do that |
| 02:48:55 | superfunc | I think I need to switch my blog to nim |
| 02:49:05 | superfunc | I'm so fucking sick of dependency hell in haskell |
| 02:49:16 | Varriount | I think we'll need a new and improved Jester first. |
| 02:49:37 | superfunc | What's the matter with it? or ipsum genera for that matter? |
| 02:49:49 | Varriount | superfunc: I dunno, I just hear... things |
| 02:49:58 | Varriount | >_> |
| 02:50:01 | Varriount | <_< |
| 02:50:26 | Varriount | superfunc: What are things like on the haskell side? |
| 02:51:38 | superfunc | even regarding the new stuff in the new-async branch? |
| 02:51:46 | superfunc | idk either way, just curious |
| 02:53:22 | superfunc | I use hakyll right now, which is similar to jekyll. The package itself is nice, but it causes a bunch of dependency issues with the packages I need for research work |
| 03:08:13 | * | superfunc quit (Ping timeout: 246 seconds) |
| 03:11:41 | * | fowl quit (Quit: Leaving) |
| 03:13:59 | * | johnsoft quit (Read error: Connection reset by peer) |
| 03:35:03 | * | kshlm joined #nimrod |
| 03:37:46 | * | brson quit (Ping timeout: 256 seconds) |
| 03:46:40 | * | kemet joined #nimrod |
| 03:47:52 | * | kemet quit (Client Quit) |
| 03:48:22 | * | kemet joined #nimrod |
| 03:50:13 | * | johnsoft joined #nimrod |
| 03:51:31 | * | kemet quit (Client Quit) |
| 03:51:40 | * | kshlm quit (Quit: Konversation terminated!) |
| 03:51:58 | * | kshlm joined #nimrod |
| 03:52:24 | * | kemet joined #nimrod |
| 03:53:23 | * | kemet quit (Client Quit) |
| 03:54:15 | * | kemet joined #nimrod |
| 03:59:08 | * | kemet quit (Remote host closed the connection) |
| 03:59:33 | * | kemet joined #nimrod |
| 04:04:02 | * | kemet quit (Ping timeout: 245 seconds) |
| 04:12:19 | * | boydgreenfield joined #nimrod |
| 04:12:43 | boydgreenfield | Does anyone get the following error with recent version of Babel (v0.4 installed on latest devel branch): `Cloning latest tagged version: expected SRV RR, found RR type 1` |
| 04:12:52 | boydgreenfield | Some kind of git tag-related error, I believe |
| 04:13:28 | Varriount | boydgreenfield: Perhaps something wrong with github? |
| 04:13:52 | boydgreenfield | Varriount: Weird, it’s intermittent. Some Googling reveals some kind of DNS or authorized hosts issue. |
| 04:18:09 | boydgreenfield | Varriount: Intermittent, but still obnoxious. Does appear to be something GitHub-side though |
| 05:23:59 | Demos | Does anyone know if one can write something like c++'s unique ptr in nimrod, I dont actually care about doing it but I am interested to see if it is possible to provide custom behavior for the addr and [] operators? |
| 05:24:18 | Varriount | Demos: What is C++ unique ptr? |
| 05:25:07 | Demos | just a class that overrides operator&, operator*, and operator-> to do something to the enclosed pointer, and has special ownership semantics |
| 05:25:21 | Demos | actually it may not override operator& |
| 05:25:52 | Varriount | Demos: Well, you can already override [] |
| 05:26:12 | Demos | but can you override the no-param deref version |
| 05:26:21 | Demos | and you can override . |
| 05:26:32 | Varriount | Hrm, I don't know... |
| 05:48:29 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 05:54:28 | * | rpag quit (Ping timeout: 258 seconds) |
| 06:11:54 | * | kemet joined #nimrod |
| 06:12:29 | * | kemet quit (Client Quit) |
| 06:16:07 | * | darkf_ joined #nimrod |
| 06:17:16 | * | Demos quit (Quit: Leaving) |
| 06:18:36 | * | darkf quit (Ping timeout: 265 seconds) |
| 06:18:44 | * | darkf joined #nimrod |
| 06:18:52 | * | darkf quit (Changing host) |
| 06:18:52 | * | darkf joined #nimrod |
| 06:21:26 | * | darkf_ quit (Ping timeout: 265 seconds) |
| 06:39:00 | * | kshlm quit (Quit: Konversation terminated!) |
| 06:40:48 | * | kshlm joined #nimrod |
| 07:47:28 | * | johnsoft quit (Ping timeout: 265 seconds) |
| 07:48:31 | * | johnsoft joined #nimrod |
| 08:00:02 | gokr1 | Morning folks |
| 08:30:05 | * | willwillson joined #nimrod |
| 08:45:45 | * | kaushal_ joined #nimrod |
| 08:46:00 | * | kshlm quit (Ping timeout: 244 seconds) |
| 08:50:43 | * | kaushal_ is now known as kshlm |
| 09:14:53 | * | Trustable joined #nimrod |
| 09:20:58 | * | [CBR]Unspoken quit (Quit: Leaving.) |
| 09:21:16 | * | [CBR]Unspoken joined #nimrod |
| 09:50:17 | * | khmm joined #nimrod |
| 09:50:49 | * | khmm_ joined #nimrod |
| 10:02:08 | * | kshlm quit (Remote host closed the connection) |
| 10:02:35 | * | kshlm joined #nimrod |
| 11:39:20 | NimBot | nimrod-code/packages master 4ae8798 Will Szumski [+0 ±1 -0]: add GNU GMP wrapper |
| 11:39:20 | NimBot | nimrod-code/packages master 3c124b9 Dominik Picheta [+0 ±1 -0]: Merge pull request #92 from cowboy-coders/master... 2 more lines |
| 11:44:05 | gokr1 | It seems to a n00b like me that I can call a "super proc" by doing a type conversion of a parameter (to a base class) and then just call it. But... for methods I am kinda screwed, right? |
| 11:48:15 | * | parametaortho joined #nimrod |
| 11:51:22 | * | kshlm quit (Ping timeout: 240 seconds) |
| 11:55:44 | * | kemet joined #nimrod |
| 12:00:25 | * | untitaker quit (Ping timeout: 260 seconds) |
| 12:06:33 | * | untitaker joined #nimrod |
| 12:24:07 | Varriount | gokr1: Hm. I don't know, have you tried casting for methods as well? |
| 12:24:16 | gokr1 | Yeah |
| 12:25:43 | gokr1 | Didn't work. Endless recursion :) |
| 12:26:12 | gokr1 | Its logical that it doesn't work, just not sure... what to do. |
| 12:29:31 | Varriount | What does C++ do in these cases? |
| 12:36:20 | gokr1 | In C++ as far as I can remember you use the class name as a prefix to the method to call. |
| 12:36:37 | gokr1 | So there is no "super" keyword as in Smalltalk - but you do MySuperClass::yadda(1) |
| 12:37:21 | gokr1 | It was a long time since I used C++ :) |
| 12:37:51 | willwillson | couldn't you just put common functionality in a template or something? |
| 12:41:30 | gokr1 | Mmmm, not sure, but... this feels like a missing piece. |
| 12:41:40 | gokr1 | I may have missed some mechanism of course. |
| 12:43:33 | * | rpag joined #nimrod |
| 12:46:07 | Varriount | gokr1: I don't think so. |
| 12:46:50 | gokr1 | You never felt the need to call "super"? :) |
| 12:46:54 | Varriount | gokr1: Multimethods (And OO) aren't as heavily integrated in Nim as in other languages. |
| 12:47:04 | gokr1 | I know, which is why I am testing the "borders" |
| 12:48:46 | Varriount | gokr1: Thoe whole of the nimrod standard library only uses multimethods 3 times - and thats just in the logging module. |
| 12:49:19 | Varriount | What's usually done is something like what streams.nim does |
| 12:49:20 | gokr1 | For a standard lib its not surprising. |
| 12:49:34 | gokr1 | I mean, most stdlib stuff isn't that complicated. |
| 12:49:52 | gokr1 | Ok, I will look there. |
| 12:50:44 | Varriount | gokr1: Essentially, the type has members which hold each of the overridable procs. |
| 12:51:01 | Varriount | er 'overridable' |
| 12:54:44 | * | dom96_ quit (Ping timeout: 244 seconds) |
| 13:04:32 | * | dom96_ joined #nimrod |
| 13:09:33 | Varriount | gokr1: You see what streams.nim does? |
| 13:09:48 | gokr1 | Sorry, got distracted. And need to go :) |
| 13:09:58 | gokr1 | But I suspect it attaches procs as members, right? |
| 13:10:32 | Varriount | Yeah. |
| 13:10:50 | * | kemet quit (Quit: Instantbird 1.5 -- http://www.instantbird.com) |
| 13:11:02 | gokr1 | I will look closer later |
| 13:11:07 | Varriount | I guess that's kinda like a vtable? |
| 13:11:33 | * | kshlm joined #nimrod |
| 13:11:41 | Varriount | Hi kshlm |
| 13:15:40 | Varriount | gokr1: It's not very space efficient, so there's probably a better way of doing things. |
| 13:16:16 | gokr1 | right |
| 13:17:29 | gokr1 | I guess Andreas can actually add some kind of "super" thingy for methods - it doesn't sound like a very hard problem given that he already has dynamic lookup in methods. |
| 13:18:02 | gokr1 | So that you could call like "mySuperMethod(super(this))" |
| 13:18:36 | gokr1 | So "super(x)" would make sure that we try resolving mySuperMethod using the super type of this, instead of its type. |
| 13:18:45 | gokr1 | Oh, well, gotta run for a few h. |
| 13:19:46 | gokr1 | Another interesting corner case - i tried making a distinct type of a distinct type of int. That works fine. Borrowing though only works from int - in other words, it always borrows from the "base" type. |
| 13:20:18 | gokr1 | Yes, crazy corner case - I just got curious :) |
| 13:25:48 | Varriount | gokr1: Actually, multimethods work via if statements |
| 13:25:51 | * | Araq0 joined #nimrod |
| 13:26:07 | Varriount | Hi Araq, we were just talking about multimethods |
| 13:26:20 | Araq0 | gokr1: it's a feature request that a type conversion inhibits dynamic binding |
| 13:27:00 | Araq0 | but I'm not sure that's the way to provide this feature |
| 13:27:36 | Varriount | there's also this -> http://forum.nimrod-lang.org/t/463 |
| 13:30:51 | Araq0 | too bad 'static mymethod(x,y)' already means something different, otherwise we could use that, but hrm |
| 13:31:16 | Araq0 | we can do 'super mymethod(x, y)' |
| 13:43:19 | willwillson | what if you wanted to invoke mymethod(x, super y)? |
| 13:51:00 | dom96_ | what if you have a big hierarchy, will we end up with super super super mymethod? |
| 13:53:12 | * | darkf quit (Quit: Leaving) |
| 13:54:24 | * | dom96_ quit (Quit: Page closed) |
| 13:56:13 | Araq0 | well 'super' is not the best name for it |
| 13:56:37 | Araq0 | but the point is, the static types used to invoke mymethod are used for dispatching |
| 13:57:03 | Araq0 | so, no there is no 'super super' |
| 14:14:14 | * | BitPuffin joined #nimrod |
| 14:18:51 | * | irrequietus joined #nimrod |
| 14:18:53 | * | irrequietus quit (Changing host) |
| 14:18:53 | * | irrequietus joined #nimrod |
| 14:21:24 | * | eigenlicht joined #nimrod |
| 14:26:05 | * | Demos joined #nimrod |
| 14:36:02 | * | dom96_ joined #nimrod |
| 14:40:40 | * | BitPuffin quit (Read error: Connection reset by peer) |
| 14:42:27 | * | BitPuffin joined #nimrod |
| 14:51:57 | * | saml_ joined #nimrod |
| 15:10:05 | * | mko joined #nimrod |
| 15:12:23 | * | willwillson quit (Ping timeout: 240 seconds) |
| 15:15:33 | * | kuzy000_ joined #nimrod |
| 15:18:22 | * | kuzy000_ quit (Read error: Connection reset by peer) |
| 15:20:23 | * | Demos quit (Quit: Leaving) |
| 15:27:14 | * | gokr joined #nimrod |
| 15:49:04 | * | kemet joined #nimrod |
| 16:02:42 | * | Fran__ is now known as Francisco |
| 16:04:54 | * | irrequietus quit () |
| 16:07:10 | * | brson joined #nimrod |
| 16:09:28 | * | irrequietus joined #nimrod |
| 16:13:40 | * | kuzy000 joined #nimrod |
| 16:14:21 | * | kuzy000 quit (Read error: Connection reset by peer) |
| 16:29:34 | * | vissborg quit (Max SendQ exceeded) |
| 16:32:15 | * | vissborg joined #nimrod |
| 16:33:20 | * | kemet quit (Ping timeout: 256 seconds) |
| 16:34:40 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 16:35:02 | * | dom96_ quit (Ping timeout: 256 seconds) |
| 16:35:40 | * | johnsoft joined #nimrod |
| 16:36:10 | * | Francisco quit (Ping timeout: 256 seconds) |
| 16:49:28 | * | will joined #nimrod |
| 16:50:35 | gokr1 | Normally one do not skip classes in doing super calls, that is extremely rare. |
| 16:50:41 | * | irrequietus quit () |
| 16:51:21 | gokr1 | In Smalltalk you can't skip - in C++ you can, but, I would consider it extremely bad style. |
| 16:52:44 | gokr1 | I will be here later, busy now. But... I would say a reasonably convenient super call is fairly important for "regular OO". |
| 17:12:58 | * | kshlm quit (Ping timeout: 258 seconds) |
| 17:14:49 | NimBot | nimrod-code/packages master c81b5dd Adam Chesak [+0 ±1 -0]: Changed name. |
| 17:14:49 | NimBot | nimrod-code/packages master 7e46927 Dominik Picheta [+0 ±1 -0]: Merge pull request #93 from achesak/master... 2 more lines |
| 17:16:19 | * | Francisco joined #nimrod |
| 17:32:12 | * | irrequietus joined #nimrod |
| 17:33:09 | * | parametaortho quit (Quit: zzzzzzzzzz) |
| 17:44:03 | * | rpag quit (Quit: Leaving) |
| 17:44:20 | * | dom96_ joined #nimrod |
| 17:44:29 | * | rpag joined #nimrod |
| 17:45:12 | dom96_ | Varriount: When creating issues could you please give them labels? |
| 17:54:32 | * | Araq0 quit (Quit: Page closed) |
| 18:00:01 | * | dom96_ quit (Ping timeout: 246 seconds) |
| 18:01:44 | * | Francisco quit (Ping timeout: 256 seconds) |
| 18:02:26 | * | Francisco joined #nimrod |
| 18:19:27 | * | Matthias247 joined #nimrod |
| 18:20:26 | * | khmm quit (Ping timeout: 256 seconds) |
| 18:21:03 | * | khmm_ quit (Ping timeout: 244 seconds) |
| 18:41:46 | * | saml_ quit (Quit: Leaving) |
| 18:49:15 | Trustable | OT: What do you guys think about D (-lang) in comparison to Nim? |
| 18:52:33 | Araq | am I allowed to answer? |
| 18:52:41 | Trustable | My opinion: Nim produces much smaller binaries (Hello World: 58 kB / 600 kB). I like the syntax of Nim much better. What more differences are there? |
| 18:52:48 | Trustable | Araq: yes please :) |
| 18:53:23 | Araq | D's template system is further developed than Nim's generics are (for now) and its slice features is worth copying |
| 18:53:43 | ldlework | Please copy good things from other languages |
| 18:53:50 | ldlework | Please be the opposite of Go |
| 18:53:54 | ldlework | Please please |
| 18:54:10 | Araq | its memory safety is however a bad joke, IMHO |
| 18:54:29 | Araq | and it relies on a particularly inefficient global stop the world GC |
| 18:54:54 | Araq | partly caused by its semantics that are hostile to an efficient GC implementation |
| 18:55:08 | Trustable | ah yes, in my understanding a reference counting is the better solution. |
| 18:55:43 | Araq | there are lots of other minor things that would annoy me to no end |
| 18:56:01 | Araq | for instance, length returns an unsigned number |
| 18:56:36 | ldlework | how is that annoying? |
| 18:56:56 | Araq | didn't you read my rant about unsigned integers? |
| 18:57:25 | rpag | when i lasted look at D it had two competing standard libraries |
| 18:57:33 | rpag | was kinda weird |
| 18:57:40 | Araq | rpag: they only have one now |
| 18:57:41 | rpag | but thats so long ago, it may be "fixed" |
| 18:57:55 | rpag | Araq, which one won? :) |
| 18:58:01 | Araq | phobos of course |
| 18:58:15 | Araq | they threw away tango. problem solved ;-) |
| 18:58:35 | Trustable | phobos was the original one, right? |
| 18:58:43 | Araq | yes |
| 18:59:30 | Trustable | Another difference: D passes objects always by reference. |
| 19:00:29 | * | johnsoft quit (Read error: Connection reset by peer) |
| 19:01:13 | * | johnsoft joined #nimrod |
| 19:04:32 | Araq | ldlework: we're copying from lots of other languages. however, stealing slices is not that easy and the language is already complex enough. our major focus is on stability now. |
| 19:04:55 | ldlework | Araq: that's a good idea! |
| 19:05:33 | ldlework | Araq: I mostly meant that when you point out to someone how like, maps are not extensible in Go they go "That's a great thing! It eliminates an entire class of problems!" |
| 19:05:48 | ldlework | and you die a little inside |
| 19:06:49 | rpag | go is super simple |
| 19:08:12 | ldlework | yeah but the justification seems to be to keep the compiler simple too and therefore keep it fast |
| 19:08:31 | ldlework | but languages like Nim and Rust show that you don't need to have a language like Go to achieve at least the speed |
| 19:08:38 | Trustable | The most annoying think in Go: The compiler does not allow you to have unused variables. |
| 19:08:59 | Araq | well from a marketing pespective they are doing it completely right. |
| 19:09:08 | ldlework | creating a language that makes you work in ways that have been solved by better language design just to make the lives of the maintainers of the language easier seems a very bad way to go about it |
| 19:09:16 | Araq | start super simple so that every programmer feels in full control |
| 19:09:21 | ldlework | and they've somehow convinced users of Go that this premise is good for users of Go |
| 19:09:31 | Araq | and then bloat it in following decades |
| 19:09:44 | Araq | see Java for another example |
| 19:09:44 | ldlework | Araq: I doubt they will bloat it much |
| 19:10:30 | Araq | I cannot see how they will be able to avoid generics in the very long run |
| 19:10:35 | ldlework | I think Go is a blip on the radar served by free limelight and its users will awaken in a few years disillusioned by their huge leap backwards when languages like Rust and Nim and friends keep popping up on their RSS feeds or whatever people use |
| 19:12:06 | rpag | i think its got a big enough foothold to be around for many years to come by now |
| 19:12:24 | ldlework | yeah it has some big users now too |
| 19:12:49 | Araq | yup |
| 19:12:57 | rpag | but everything becomes perl, sooner or later :D |
| 19:13:02 | ldlework | heh |
| 19:15:55 | Araq | what do you mean? languages are all becoming perlish? |
| 19:16:30 | ldlework | Araq: no they fall into obscurity |
| 19:16:35 | rpag | yeah |
| 19:16:45 | Araq | ah lol, yeah |
| 19:17:02 | ldlework | Do you guys like Rust? |
| 19:17:04 | Araq | I hope I copied enough from Lisp so that won't happen for Nim :P |
| 19:17:23 | Araq | well Lisp is obscure too, I guess |
| 19:17:37 | Araq | but it remained a good reputation |
| 19:18:07 | rpag | indeed |
| 19:22:16 | Araq | ldlework: Rust is handicapped by paranoia |
| 19:23:25 | Araq | no exceptions, no flexible overloading |
| 19:24:17 | Araq | no courage to get rid of {} and semicolons |
| 19:24:47 | ldlework | Araq: the last one doesn't bother me at all |
| 19:24:58 | Araq | explicit 'unsafe' blocks where Nim's approach works much better |
| 19:25:08 | ldlework | Araq: what is Nim's approach |
| 19:25:39 | Araq | use keywords 'addr' and 'cast' and ensure nothing else can break safety |
| 19:25:58 | Araq | well a few corner cases crept into the language so that this doesn't hold |
| 19:26:06 | Araq | but we're getting there |
| 19:26:53 | ldlework | Araq: I don't understand how you're relating unsafe and Nim's addr and cast |
| 19:27:03 | ldlework | but I don't understand enough about Nim's data model yet |
| 19:32:57 | gokr1 | ldlework: addrs gives you a ptr - thus unsafe shit can follow. cast forces bits to be available as "something else", pretty unsafe too. |
| 19:33:06 | gokr1 | Right? |
| 19:36:20 | gokr1 | In Smalltalk "super" is just a ref to "this" - but sending messages to that guy starts method lookup "one step higher" in the superclass chain. |
| 19:37:31 | gokr1 | So... it felt pretty Nimmish to have some kind of "super(x)" that can be used for one or more args - thus making their dynamic type be "one step higher" in that call. |
| 19:48:55 | * | irrequietus quit () |
| 19:50:18 | Araq | gokr1: meth(super(x), super(y), z) is weird though |
| 19:50:41 | gokr1 | But you would quite seldomly use two supers. |
| 19:50:46 | Araq | static_call meth(x, y, z) is much easier to understand |
| 19:51:04 | gokr1 | And... what does "static_call" do you mean? |
| 19:51:29 | Araq | so the call to 'meth' does not go via the dynamic dispatching mechanism |
| 19:51:37 | gokr1 | Ok. |
| 19:51:57 | Araq | well 'static_call' is not really sexy |
| 19:52:13 | Araq | but 'static meth(...)' already exists and means something different |
| 19:52:30 | gokr1 | So... static_call + a type conversion to a parent type - would cause the "super method" to be called? |
| 19:52:41 | * | nande joined #nimrod |
| 19:52:45 | Araq | yes |
| 19:59:10 | * | BlaXpirit joined #nimrod |
| 19:59:17 | Araq | as i said, there is a proposal that a type conversion within a method call inhibits dynamic dispatching |
| 19:59:26 | Araq | but when: |
| 19:59:32 | Araq | m(Obj(a)) |
| 19:59:38 | Araq | is different from: |
| 19:59:49 | Araq | let x = Obj(a); m(x) |
| 20:00:04 | Araq | that doesn't feel right |
| 20:00:07 | gokr1 | I agree. |
| 20:00:39 | gokr1 | It sounds like a "hack" solution. ;) |
| 20:01:17 | gokr1 | Just read about static/semistatic |
| 20:01:34 | Araq | is semistatic still in the docs? |
| 20:01:53 | gokr1 | Think so, nim-lang is the same site as nimrod-lang, right? |
| 20:02:00 | gokr1 | I read at nim-lang. |
| 20:02:02 | Araq | right |
| 20:02:10 | gokr1 | http://nim-lang.org/manual.html#static-statement-expression |
| 20:03:09 | * | Jehan_ joined #nimrod |
| 20:04:41 | Jehan_ | In multi-method languages, there's generally a "next method" approach being used rather than some form of "super" call. In the case of single dispatch, of course, "next method" maps directly to calling the method on a superclass. |
| 20:06:10 | gokr1 | Mmmm, I gotta check what slate does... |
| 20:07:48 | Araq | Jehan_: I think 'next' is a weird name for it |
| 20:08:02 | Araq | 'up' seems more intuitive |
| 20:08:20 | Jehan_ | Araq: It's not necessarily "up", it can also be "sideways". |
| 20:09:02 | Jehan_ | call-next-method in CLOS, next-method in Dylan, TryNextMethod() in GAP. |
| 20:10:23 | Jehan_ | It's called this way because it's the next method in the ordering imposed by specificity. |
| 20:11:05 | gokr1 | Slate calls it "resend" |
| 20:11:09 | Jehan_ | That said, multiple dispatch is something that's seen so little practical use that there may be a better solution. |
| 20:12:35 | gokr1 | In Slate I do know the params that are meant to participate in dynamic lookup are marked with a @. Nim resolves on all object types, right? |
| 20:15:26 | Jehan_ | gokr1: Yes. |
| 20:17:04 | Araq | btw we do de-virtualization. I recently discovered this. :-) |
| 20:19:03 | Jehan_ | Devirtualization is just a fancy term that C++ introduced, but something that can happen pretty naturally in other languages. |
| 20:21:21 | Jehan_ | Interestingly, while the dispatch mechanism could use improvement, it surprisingly seems to beat C++'s dispatch table approach for up to a fairly high number of subclasses. |
| 20:21:57 | gokr1 | Araq: Interesting paper, check conclusion: http://homepages.mcs.vuw.ac.nz/~alex/files/MuscheviciPotaninTemperoNobleOOPSLA2008.pdf |
| 20:22:15 | gokr1 | (about how much multidispatch is used in multidispatch langs) |
| 20:23:32 | Jehan_ | Speaking of interesting papers, I recommend a look at: http://archive.computerhistory.org/resources/text/Knuth_Don_X4100/PDF_index/k-9-pdf/k-9-u2293-Record-Handling-Hoare.pdf |
| 20:23:36 | gokr1 | I know its an impossible question - but how much slower is a method compared to a proc? And can anyone give some experience on mixing procs/methods in an OO Nim codebase? |
| 20:23:41 | Jehan_ | It's essentially the Ur-OOP paper. |
| 20:24:15 | Jehan_ | Interestingly enough, Hoare's original vision of object-oriented programming was much closer to ML than Simula or Smalltalk. |
| 20:24:40 | Jehan_ | gokr1: It's largely a matter of branch prediction. Plus, inability to inline. |
| 20:29:49 | Araq | gokr1: "nimgame" uses methods heavily and so does some of fowl's stuff, afaik |
| 20:30:40 | Araq | Jehan_: inlining is possible with link time optimizations. which every good C compiler does these days. |
| 20:30:41 | gokr1 | I haven't programmed in any multimethod language - I do recall feeling "nausea" when trying to read Slate code - since it was more like a "sea of procedures" than more easily discerned objects with behavior. |
| 20:31:21 | Jehan_ | Araq: That's not what I mean. If dispatch is truly dynamic, you cannot figure out which method to inline. |
| 20:31:23 | gokr1 | But it does seem useful to be able to dispatch on at least one of the arguments - thus having overloaded methods in a "class" (sorry for using the term). |
| 20:31:44 | Jehan_ | Unless you have very few candidates, that's usually prohibitive. |
| 20:31:50 | gokr1 | ("at least one of the arguments" in addition to the "receiver" I mean) |
| 20:32:01 | Trustable | Small question: How can a method call the method of the parent class? |
| 20:32:11 | Jehan_ | gokr1: Outside of Computer Algebra, I know few actual applications. |
| 20:32:37 | gokr1 | Trustable: Its exactly what we are discussing - it can't. At least not easily. Araq posted in the forum on how to split out the code in a proc - and call that. |
| 20:32:43 | Jehan_ | Applications that aren't just as easily handled by double dispatch, that is. |
| 20:32:52 | Jehan_ | Or by parametric polymorphism. |
| 20:33:13 | Jehan_ | As I keep pointing out, lots of people use subtyping polymorphism where parametric polymorphism is the superior choice. |
| 20:33:15 | will | with the static_call idea, would you be able to get the super class in a generic method? |
| 20:33:16 | gokr1 | Jehan_: Yes, double dispatch occurs relatively often in complex Smalltalk systems - so that's where I could see it being used. |
| 20:33:38 | Jehan_ | gokr1: One of the problems with multi-methods is that they break encapsulation. |
| 20:34:51 | Trustable | Is it planned to add the feature to call parent method? |
| 20:34:54 | gokr1 | As in, one can "hijack" calls by defining methods for a type from another module? |
| 20:35:11 | gokr1 | Trustable: We are kinda discussing our options :) |
| 20:35:48 | Trustable | Good. In my opinion this feature would be important. |
| 20:35:58 | gokr1 | will: Yes, the idea with that particular solution was to simply "bypass" dynamic dispatch and call a method "as it was a proc". |
| 20:36:01 | Jehan_ | gokr1: Pretty much, introducing specializations that the original module didn't anticipate. |
| 20:36:58 | gokr1 | I just read on lambda the ultimate that indeed one problem identified was how new code can "disrupt" old code in interesting ways that regular single dispatch OO code can't., |
| 20:37:29 | will | gokr1: but how do you know what type you should convert a generic parameter to for static dispatch |
| 20:37:33 | Trustable | I would implement it like in PHP: "parent::MyMethod(this, ..)" |
| 20:38:45 | Jehan_ | will: That's what I was wondering, too. It's not a problem if you have an implementation for every possible type signature, but if there are gaps in the coverage, you may not know what the actual type of an argument is. |
| 20:38:52 | gokr1 | Trustable: There is no relation between a type "parent" and a method "MyMethod" in Nim, AFAIK. They are just free procedures - but with dynamic dispatch. |
| 20:39:15 | gokr1 | will: Good point. |
| 20:39:19 | Jehan_ | Trustable: Only works for single dispatch. |
| 20:40:02 | Jehan_ | As I said, the conventional approach is a "next method" kind of thing. |
| 20:40:03 | * | madphage joined #nimrod |
| 20:40:22 | gokr1 | Trustable: In other words, methods don't "belong" to a type, they just have one or more arguments that are objects - and their types are used for dispatch. |
| 20:41:01 | madphage | i like to think of traditional OO as a consistent bag of partially applied functions |
| 20:41:12 | gokr1 | Jehan_: Can you elaborate on how you think parametric polymorphism (is that the term we use for generics?) "solves" this issue? |
| 20:41:13 | madphage | and I wish often for ad-hoc OO |
| 20:41:15 | * | Ven joined #nimrod |
| 20:41:16 | Trustable | gokr1: ok, I understand that. But is this a reason not to implement such a feature with static dispatch? |
| 20:41:26 | gokr1 | Jehan_: Since I am not that well versed in how to apply those. |
| 20:41:44 | Jehan_ | gokr1: That's not the term "we" use for generics, it's the usual term in the literature. :) |
| 20:41:58 | Jehan_ | "Generics" is a bit more colloquial. |
| 20:42:35 | gokr1 | Jehan_: I know, but... just curious if I need to look it up vs "generics" |
| 20:42:41 | Jehan_ | gokr1: The thing is, if you don't need dynamic dispatch, parametric polymorphism can handle both single and multiple dispatch statically. |
| 20:43:44 | Jehan_ | That's, e.g., what Haskell's type classes do. |
| 20:44:08 | gokr1 | Jehan_: My simple minded perception is that parametric polymorphism causes a combinatorial explosion - and that... it feels like you would still end up holding a Banan in a "Fruit" variable. |
| 20:44:33 | Jehan_ | More importantly, parametric polymorphism deals with constructors and the binary operator problem more cleanly where that approach is sufficient. |
| 20:45:13 | Jehan_ | gokr1: Hmm, I'd say the latter is more something you could say about dynamic dispatch. |
| 20:45:26 | Jehan_ | Combinatorial explosion is an implementation issue. |
| 20:45:32 | Jehan_ | And how much you overuse it. |
| 20:45:52 | madphage | gokr1: most folks confuse parametric polymorphism with its code gen implications from c++, so e.g. if you have a template function that takes in two types, you have to gen a new version of that function for each pair of types |
| 20:46:28 | Jehan_ | In principle, a polymorphic proc f[T1, …, Tn](…) only introduces a family of procedures, one for each actual type combinations being used. These can all be shared (see OCaml, Haskell, Ada). |
| 20:46:40 | madphage | but its also possible to implement parametric polymorphism via generating a function that takes in virtual table style arguments, and hard codes the correct virtual tables at each call site |
| 20:47:24 | Jehan_ | Even if you generate one for each set of type parameters, there's usually very little code explosion that happens. |
| 20:47:56 | Jehan_ | C++ has a problem because it doesn't have a native metaprogramming model, so it abuses templates for metaprogramming. |
| 20:48:02 | madphage | yeah |
| 20:48:29 | madphage | there's a role for virtual table implemented generics in addition to code gen ones |
| 20:48:38 | Jehan_ | MLton, for example, also generates one instance for each and doesn't have the problems. |
| 20:48:40 | madphage | post-hoc binary plugin loading being one |
| 20:48:50 | Jehan_ | madphage: Aye. |
| 20:49:25 | Jehan_ | It's still tricky to have both value and reference types in the same position. |
| 20:49:42 | Jehan_ | Or, why OCaml encodes integers with having their lowest bit set to 1. |
| 20:49:42 | * | gokr1 notes PICs were discussed back in july... |
| 20:50:10 | Jehan_ | … and boxes floats. |
| 20:50:51 | gokr1 | OCaml does tagged small integers? Smalltalk too, interesting. |
| 20:51:02 | madphage | yeah, though I view generics as a potential solution to that issue |
| 20:51:43 | Jehan_ | gokr1: Yeah, but for different reasons. |
| 20:52:15 | madphage | specifically, if the compiler itself is late-bindable, you always have the option of specializing a function to the value type version of something |
| 20:52:40 | madphage | but there's more complexity to ref vs. value than just that part |
| 20:52:42 | Jehan_ | madphage: Yup, as I said, you can pick one or the other option. |
| 20:53:55 | madphage | so, I want to start playing with nimrod soon |
| 20:54:12 | madphage | is it in a lot of flux at the moment? |
| 20:54:36 | madphage | not entirely clear from the website, seems like a name change and some backwards incompatible stuff is eminent |
| 20:54:45 | * | Varriount|Mobile joined #nimrod |
| 20:55:16 | gokr1 | Personally I think its very playable. |
| 20:55:18 | gokr1 | :) |
| 20:55:24 | Varriount|Mobile | Meep |
| 20:55:29 | Trustable | I agree, no problem so far. |
| 20:56:04 | gokr1 | madphage: If you want my experiences during the last ... week, its at: http://goran.krampe.se/category/nim |
| 20:56:13 | madphage | nice! thanks for the link |
| 20:56:58 | gokr1 | I am currently trying to write down my ... exploration of the OO space in Nim - which is why I also bumped into the "can't call super methods" thing. |
| 20:57:00 | Varriount|Mobile | Araq: Is there anything that can be done to fix the disparity in performance between multimethods, case statements, and vtables? |
| 20:58:01 | Araq | Varriount|Mobile: well in theory you can get them all to the speed of 'case' statements. but it's quite some work. |
| 20:58:48 | Araq | hi madphage welcome |
| 21:00:19 | madphage | hi Araq, I like your language values |
| 21:01:01 | madphage | look forward to playing with nim soon |
| 21:03:52 | Araq | Jehan_: I still think my algorithm of doing "polymorphic inline caches" is novel. ;-) |
| 21:04:17 | Jehan_ | Araq: Hmm, which algorithm? |
| 21:05:59 | Araq | well I mean my heuristic for "subtype checking" |
| 21:06:13 | Araq | "instanceof" checking |
| 21:06:21 | Araq | or whatever you wanna call it |
| 21:10:16 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 21:12:48 | * | comex is now known as ditzex |
| 21:13:51 | Jehan_ | Hmm, I haven't looked at the actual algorithm, so I can't say much about it. |
| 21:17:05 | Araq | well the new idea in it is to also cache the knowledge that A is *not* a subtype of B |
| 21:17:36 | Trustable | gokr1: I like your article http://goran.krampe.se/2014/10/20/i-missed-nim/ |
| 21:19:24 | * | Varriount|Mobile joined #nimrod |
| 21:20:35 | gokr1 | Trustable: Thanks :) |
| 21:20:58 | Jehan_ | So, system() returns a 16-bit value, but exit() only uses 8 bits, and as a result, exit(system(…)) doesn't work as expected ... |
| 21:25:38 | gokr1 | Araq: I think this page describes the PIC in Cog in fair detail, ctrl-F "Hölzle" to find the section: http://clementbera.wordpress.com/2013/08/09/the-cog-vm-lookup/ |
| 21:25:58 | * | gokr quit (Ping timeout: 258 seconds) |
| 21:26:02 | * | superfunc joined #nimrod |
| 21:26:11 | superfunc | Sup everyone |
| 21:28:03 | Varriount|Mobile | Hey superfunc |
| 21:29:24 | superfunc | How goes it? |
| 21:35:20 | * | fowl joined #nimrod |
| 21:36:04 | Varriount|Mobile | Too much work, not enough time. |
| 21:36:29 | Varriount|Mobile | Especially not enough time for Nim development |
| 21:39:49 | fowl | hrm |
| 21:39:55 | Jehan_ | gokr1: The biggest problem with caching method lookup is that these days in a multi-threaded system, that requires thread-local caches. |
| 21:39:57 | * | madphage quit (Quit: Page closed) |
| 21:40:07 | gokr1 | Don't be mad at me... but... non local return? Not in Nim, right? |
| 21:40:12 | gokr1 | Jehan_: right |
| 21:40:14 | Jehan_ | Which are not always fast to access, depending on your system. |
| 21:40:23 | fowl | my external hd is not readable from windows now, but in linux ntfs3g said it was fixed (and it reads on linux) |
| 21:40:28 | Jehan_ | *cough* Apple *cough* |
| 21:40:34 | fowl | i guess it was my fault for using ntfs :< |
| 21:46:51 | superfunc | Jehan_: I had a quick question. If I have a method returnig a Maybe[Thing] why can't it infer the type when I say result = nothing() in the method ? |
| 21:47:01 | * | BitPuffin quit (Ping timeout: 265 seconds) |
| 21:47:29 | superfunc | I can work around t by saying result = nothing[Thing]() |
| 21:48:29 | Jehan_ | For the same reason the following doesn't work: |
| 21:48:31 | Jehan_ | var s: seq[int] |
| 21:48:31 | Jehan_ | s = newSeq() |
| 21:48:54 | * | betawaffle quit (Quit: Oh Noes! My ZNC!) |
| 21:49:28 | Jehan_ | Basically, type inference is a fairly local thing. |
| 21:50:03 | Jehan_ | You can work around it by having a special constant and a converter. |
| 21:50:36 | Jehan_ | I think I posted an implementation a while ago on the forum, that one can be adapted accordingly. |
| 21:50:49 | superfunc | Ok, I was working on some monads in nim for fun and I ran into that, thanks for explaining it. I'll go ahead and implement the workaround tonight when I can look yours up |
| 21:50:54 | * | Varriount|Mobile quit (Read error: Connection reset by peer) |
| 21:51:17 | Jehan_ | http://forum.nimrod-lang.org/t/597 towards the end. |
| 21:51:32 | Jehan_ | The hack is in the comment part. |
| 21:51:46 | superfunc | Thanks, I appreciate it |
| 21:52:00 | Jehan_ | Basically, you write a converter from NoType to Option[T] to get what you need. |
| 21:52:59 | superfunc | Simple enough, now to do some cooler monads |
| 21:56:00 | * | betawaffle joined #nimrod |
| 22:00:29 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 22:03:44 | Araq | gokr1: you can use exceptions for non-local returns |
| 22:03:58 | Araq | I'm not saying it's a good idea. |
| 22:04:04 | gokr1 | Araq: Yeah, I started looking at that - just "for fun". |
| 22:04:12 | gokr1 | But I dropped it :) |
| 22:04:34 | Araq | usually a template that has a return is a nicer workaround |
| 22:04:37 | gokr1 | As you know - Smalltalk is full of it - but typically not something you use in app code when you have things like iterators, break etc |
| 22:04:59 | gokr1 | Hey, this is slick: proc sick？(x: string): bool = x == "sick" |
| 22:05:09 | gokr1 | Muuahaha! |
| 22:05:26 | gokr1 | This works fine: echo(sick？("sick")) |
| 22:06:08 | gokr1 | A so called "FULLWIDTH QUESTION MARK", U+FF1F |
| 22:06:22 | Jehan_ | I was about to ask whether you used Unicode … :) |
| 22:06:31 | Jehan_ | Yeah, sick alright … :) |
| 22:06:39 | gokr1 | I kinda like the idea of boolean procs with "?" at the end, not something Smalltalk has - but I always think it looks nice in code. |
| 22:09:18 | Araq | I don't think ? in an identifier mixes all that well with userdefinable operators |
| 22:09:42 | gokr1 | Mmm, dunno. Ruby does it, right? |
| 22:13:57 | superfunc | Ruby also does monkey patching, ew |
| 22:14:29 | gokr1 | I am not saying I like Ruby - but I don't think they "suffer" from being able to use "?" in method names. |
| 22:15:13 | Jehan_ | Honestly, it depends on whether it results in reasonable lexical rules. |
| 22:15:32 | Jehan_ | Dylan allows you to stuff a whole lot more than just question marks in identifiers without breaking stuff. |
| 22:15:52 | Jehan_ | Mind you, you'll need more whitespace in Dylan, but it still works. |
| 22:16:17 | * | Mat3 joined #nimrod |
| 22:16:20 | Mat3 | hi all |
| 22:17:33 | Trustable | Hi |
| 22:18:28 | Jehan_ | gokr1: By the way, what do you need non-local returns for? |
| 22:18:36 | gokr1 | Need? :) |
| 22:19:06 | gokr1 | Smalltalk uses them quite a lot - mainly for control structures etc. |
| 22:19:51 | Mat3 | hello Trustable |
| 22:20:43 | gokr1 | It also means you can (I would say) make closure based interfaces work more "natural". This ... as a Smalltalker I just don't even think about it anymore. |
| 22:21:12 | Mat3 | gokr1: makes sense, because the classic Smalltalk approach was compiling to a stack based VM (where all arguments like return statements are global) |
| 22:22:05 | gokr1 | "return statements are global"... |
| 22:22:10 | gokr1 | Not sure I follow. |
| 22:23:18 | Mat3 | references to at runtime generated objects which holding a value (and these references where 'visible' to all objects independent of there 'context') |
| 22:28:38 | Jehan_ | Hmm, I eschew return in general. |
| 22:30:18 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 22:30:58 | Mat3 | anyhow; Is it save to assume, code which compiles for Nim 0.9.6 will also compile for 0.10 (which do not relate on specific libraries) ? |
| 22:31:22 | Jehan_ | Mat3: Modulo renaming/case sensitivity issues. |
| 22:31:35 | gokr1 | Only? |
| 22:31:44 | gokr1 | I mean, no other big changes? |
| 22:32:19 | Varriount | There might be some misc changes that slipped through. |
| 22:33:36 | * | xenagi joined #nimrod |
| 22:34:07 | Varriount | superfunc: Monkey patching is something that is - if not common practice - a readily available tool in sufficiently dynamic languages. |
| 22:35:45 | superfunc | Varriount: doesn't mean it doesn't make me uncomfortable lol |
| 22:36:25 | gokr1 | Jehan_: Have you built any "substantial" OO code in Nim? Its an honest question - I would value any insight from such an experience, like... if you felt you never really needed methods etc. |
| 22:38:17 | Varriount | gokr1: You should talk with filwit - he's the one that's been doing a bunch of OO stuff in Nim. |
| 22:38:30 | Jehan_ | gokr1: Actually, I've mostly not been using OO in Nim. |
| 22:38:47 | Jehan_ | Been using more of an ML/CLU-like style. |
| 22:38:58 | gokr1 | And is that because... you decided not to, or because you are used to not doing OO? |
| 22:39:40 | Jehan_ | gokr1: Actually, I'm very used to doing OO. |
| 22:39:53 | Jehan_ | It's more of a "when in Rome, do as the Romans do" thing. |
| 22:40:21 | Jehan_ | OO support in Nim is fairly limited compared to the alternatives. |
| 22:41:12 | gokr1 | I mean, both me and Ron are long time Smalltalkers - our minds are fairly wired - but more importantly, we have a HUGE system written in Smalltalk. This is why I want to see how Nim would fare if we start porting stuff over. We can of course adapt, but, you know. |
| 22:41:40 | Jehan_ | For what it's worth, my Ph.D. thesis involved a concurrency model on top of Eiffel and involved writing an Eiffel compiler, so I'm fairly certain I have some OO experience. :) |
| 22:41:53 | gokr1 | On the other hand Nim seems flexible enough to sort of "deal" with any issues. |
| 22:42:11 | gokr1 | Jehan_: I never used Eiffel but a friend of mine was heavily into it. |
| 22:43:02 | Jehan_ | gokr1: The thing I'd mostly be worried about is the speed of the dispatch mechanism. |
| 22:43:03 | Mat3 | Jehan_: Which concurrency model ? |
| 22:43:14 | Jehan_ | Mat3: The one I designed for my thesis? :) |
| 22:43:56 | Mat3 | sure, what describes your approach best ? |
| 22:44:35 | Jehan_ | Synchronization contracts. |
| 22:44:59 | Jehan_ | Also, it's completely memory-safe. No data races possible. |
| 22:45:16 | superfunc | Jehan_: if you don't mind me asking, what do you work on now? |
| 22:45:23 | Jehan_ | Not that that's anything novel, but lots of language designers can't seem to hack that part. |
| 22:45:38 | Jehan_ | superfunc: Computer Algebra systems and the parallelization thereof. |
| 22:46:02 | superfunc | So, still in academia? |
| 22:46:09 | * | boydgreenfield joined #nimrod |
| 22:46:20 | superfunc | Just curious, as I'll have to make that decision in a few years |
| 22:46:21 | Jehan_ | Kinda sorta. |
| 22:46:23 | * | flaviu joined #nimrod |
| 22:46:35 | Jehan_ | I'm not on any tenure track career path. |
| 22:46:58 | Jehan_ | I figured out years ago that a job where my main activity would be writing grant proposals wasn't for me. :) |
| 22:47:39 | superfunc | I'll bet lol |
| 22:48:24 | superfunc | I'll likely end up in industry of some sort, hopefully still working in the PL area |
| 22:48:40 | Jehan_ | So, technically I'm in academia, but I'm working more like a software developer. |
| 22:49:04 | Jehan_ | It's a pretty narrow niche, but few software developers have the background in math etc. to deal with what I'm doing. |
| 22:49:13 | Mat3 | reads like some kind of Actor based model |
| 22:49:24 | Jehan_ | Mat3: It isn't. It's a shared memory model. |
| 22:50:57 | Mat3 | hmm |
| 22:51:00 | superfunc | Jehan_: sounds like a nice middle ground |
| 22:51:13 | gokr1 | Jehan_: So you work now or doing your thesis? |
| 22:51:19 | Jehan_ | gokr1: Work. |
| 22:51:36 | gokr1 | Contractor? |
| 22:52:39 | Jehan_ | No. Technically, a research fellow as they'd say in the UK. |
| 22:52:51 | Jehan_ | Until one year ago, I worked on this: http://www-circa.mcs.st-and.ac.uk/hpcgap.php |
| 22:54:04 | Jehan_ | And yes, one of the people on that list is the original author of GHC. Scarily smart guy. :) |
| 22:54:33 | * | Trustable quit (Quit: Leaving) |
| 22:54:54 | superfunc | Jehan_: heh, my advisor worked on ghc for his phd at Glasgow in the 90s |
| 22:55:15 | boydgreenfield | Has anybody experienced this issue w/ Babel – would love help troubleshooting if so: https://github.com/nimrod-code/nimble/issues/64 |
| 22:55:21 | Jehan_ | superfunc: Just to be clear, I'm not a big fan of lazy functional programming languages. |
| 22:55:34 | superfunc | Lol, duly noted |
| 22:56:38 | superfunc | My jury is still out, need more data before I make an opinion |
| 22:56:40 | Jehan_ | I still think experience with Haskell is a pretty essential part of a CS education, of course. |
| 22:57:45 | superfunc | Agreed |
| 23:04:14 | * | rpag_ joined #nimrod |
| 23:04:38 | gokr1 | flaviu: What OS and CPU are you on? Just curious about that bench we did |
| 23:07:01 | Jehan_ | boydgreenfield: That looks like a DNS problem. |
| 23:07:38 | Mat3 | need some sleep, ciao |
| 23:07:41 | * | rpag_ quit (Client Quit) |
| 23:07:48 | * | rpag quit (Ping timeout: 265 seconds) |
| 23:07:52 | * | Mat3 quit (Quit: Verlassend) |
| 23:13:23 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 23:15:17 | flaviu | gokr1: Linux 3.17.1-1-ARCH x86_64 / Phenom(tm) II X4 965 |
| 23:16:23 | gokr1 | Perhaps you used a newer nodejs. |
| 23:16:39 | flaviu | v0.10.32 |
| 23:16:46 | gokr1 | Mmm, mine is 0.10.25 |
| 23:17:05 | gokr1 | Oh well, whatever. |
| 23:17:23 | flaviu | looks like I'm out of date too :P 0.10.33 is the latest |
| 23:17:31 | * | superfunc_ joined #nimrod |
| 23:24:16 | * | superfunc_ quit (Quit: Page closed) |
| 23:25:01 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 23:27:25 | superfunc | flaviu: love the phenom 2, I built so many budget gaming pcs for my friends with those in high school |
| 23:28:22 | flaviu | Yep. Still compatible $ per benchmark point with the latest cpus, although power is pretty shoddy |
| 23:29:32 | flaviu | *comparable |
| 23:31:06 | * | rpag joined #nimrod |
| 23:32:36 | * | BitPuffin joined #nimrod |
| 23:32:58 | BitPuffin | Araq: C89/90 does not have 64 bit ints afaik, how do you deal with that since that's what you're compiling to? |
| 23:39:42 | Jehan_ | BitPuffin: C89 says nothing about integer sizes at all, except that the shorter types must be subsets of the bigger types? |
| 23:40:43 | Jehan_ | stdint.h and minimum int sizes came with C99. |
| 23:44:20 | fowl | hola BitPuffin |
| 23:52:33 | * | boydgreenfield joined #nimrod |