| 00:34:25 | * | rgc quit (Read error: Connection reset by peer) |
| 00:45:19 | * | Pisuke quit (Read error: Connection reset by peer) |
| 00:46:26 | * | Pisuke joined #nimrod |
| 00:46:51 | * | EXetoC quit (Quit: WeeChat 1.0.1) |
| 01:07:30 | * | Lorxu quit (Ping timeout: 244 seconds) |
| 01:15:46 | * | Fran__ joined #nimrod |
| 01:17:16 | * | Francisco quit (Ping timeout: 250 seconds) |
| 01:36:40 | * | brson quit (Quit: leaving) |
| 01:36:47 | * | brson joined #nimrod |
| 01:39:32 | * | Jehan_ quit (Ping timeout: 260 seconds) |
| 01:50:13 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 01:50:31 | * | perturbation joined #nimrod |
| 02:14:37 | * | perturbation quit (Quit: Leaving) |
| 02:18:46 | * | flaviu quit (Ping timeout: 240 seconds) |
| 02:28:11 | * | kshlm joined #nimrod |
| 03:04:35 | * | kshlm quit (Ping timeout: 265 seconds) |
| 03:17:33 | reactormonk | gokr, the basic idea is to keep autogenerated code separate |
| 03:19:57 | * | rpag joined #nimrod |
| 03:21:17 | * | xenagi quit (Quit: Leaving) |
| 03:38:20 | * | kshlm joined #nimrod |
| 03:38:22 | * | fowl quit (Quit: Leaving) |
| 03:43:08 | * | dapz joined #nimrod |
| 03:43:33 | * | brson quit (Quit: leaving) |
| 04:00:53 | * | dapz quit (Read error: Connection reset by peer) |
| 04:06:22 | * | Demos quit (Read error: Connection reset by peer) |
| 04:20:35 | * | fowl joined #nimrod |
| 05:00:15 | * | nande quit (Remote host closed the connection) |
| 05:04:12 | * | gokr_ quit (Read error: Connection reset by peer) |
| 05:06:39 | * | gokr_ joined #nimrod |
| 05:06:39 | * | gokr_ quit (Remote host closed the connection) |
| 05:07:11 | * | gokr_ joined #nimrod |
| 05:33:48 | * | BlaXpirit joined #nimrod |
| 06:06:09 | * | gokr_ quit (Ping timeout: 246 seconds) |
| 06:06:49 | * | gokr_ joined #nimrod |
| 06:31:37 | * | bjz quit (Ping timeout: 255 seconds) |
| 06:34:11 | * | gokr_ quit (Ping timeout: 272 seconds) |
| 06:36:10 | * | gokr_ joined #nimrod |
| 06:53:25 | * | Francisco joined #nimrod |
| 06:56:46 | * | Fran__ quit (Ping timeout: 240 seconds) |
| 06:57:57 | * | bjz joined #nimrod |
| 07:04:01 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 07:08:50 | * | gokr_ quit (Remote host closed the connection) |
| 07:09:05 | * | gokr_ joined #nimrod |
| 07:17:33 | * | gokr_ quit (Ping timeout: 246 seconds) |
| 07:21:44 | * | gokr_ joined #nimrod |
| 07:45:38 | * | q66[lap] joined #nimrod |
| 07:46:05 | * | khmm joined #nimrod |
| 07:46:57 | * | gokr_ quit (Ping timeout: 246 seconds) |
| 07:48:12 | * | Trustable joined #nimrod |
| 07:49:15 | * | gokr_ joined #nimrod |
| 07:52:02 | * | khmm quit (Read error: Connection reset by peer) |
| 07:56:05 | * | gokr_ quit (Ping timeout: 258 seconds) |
| 07:58:49 | * | gokr_ joined #nimrod |
| 08:05:35 | * | leehambley joined #nimrod |
| 08:14:38 | * | leehambley quit (Quit: Linkinus - http://linkinus.com) |
| 08:25:17 | * | rpag quit (Ping timeout: 245 seconds) |
| 08:26:02 | * | rpag joined #nimrod |
| 08:36:34 | * | xcombelle joined #nimrod |
| 09:02:25 | * | rgrau joined #nimrod |
| 09:22:46 | * | bjz quit (Ping timeout: 240 seconds) |
| 10:09:16 | * | bjz joined #nimrod |
| 10:14:49 | * | EXetoC joined #nimrod |
| 10:35:40 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 10:44:56 | * | q66[lap] joined #nimrod |
| 10:50:43 | * | io2 joined #nimrod |
| 11:00:58 | * | bjz quit (Ping timeout: 250 seconds) |
| 11:13:58 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 11:25:49 | * | Jehan_ joined #nimrod |
| 11:26:41 | * | kemet joined #nimrod |
| 11:29:41 | * | bjz joined #nimrod |
| 11:45:17 | * | kshlm quit (Ping timeout: 260 seconds) |
| 11:55:48 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 11:59:03 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 12:29:17 | * | khmm joined #nimrod |
| 12:43:59 | * | [CBR]Unspoken quit (Remote host closed the connection) |
| 12:46:32 | * | [CBR]Unspoken joined #nimrod |
| 12:48:49 | * | gokr quit (Quit: Leaving.) |
| 12:57:03 | * | gokr_ quit (Ping timeout: 246 seconds) |
| 12:57:11 | * | gokr_ joined #nimrod |
| 13:00:02 | * | kemet quit (Ping timeout: 255 seconds) |
| 13:12:52 | * | gokr joined #nimrod |
| 13:12:53 | * | gokr_ quit (Read error: Connection reset by peer) |
| 13:16:25 | * | gokr quit (Remote host closed the connection) |
| 13:16:31 | * | gokr_ joined #nimrod |
| 13:18:25 | * | gokr_ quit (Client Quit) |
| 13:24:23 | * | gokr joined #nimrod |
| 13:24:24 | * | kshlm joined #nimrod |
| 13:26:06 | * | bjz quit (Ping timeout: 240 seconds) |
| 13:27:33 | * | gokr quit (Client Quit) |
| 13:28:09 | * | gokr joined #nimrod |
| 13:29:07 | * | jagillion joined #nimrod |
| 13:30:33 | * | bjz joined #nimrod |
| 13:31:57 | * | untitaker quit (Ping timeout: 265 seconds) |
| 13:34:04 | gokr | Trying to finish another article ;) |
| 13:38:43 | * | untitaker joined #nimrod |
| 13:47:00 | * | io2 joined #nimrod |
| 13:49:57 | * | darkf quit (Quit: Leaving) |
| 13:51:25 | * | kemet joined #nimrod |
| 13:51:53 | * | kemet quit (Client Quit) |
| 13:52:20 | * | kemet joined #nimrod |
| 13:53:02 | * | kemet quit (Client Quit) |
| 13:53:27 | * | q66[lap] joined #nimrod |
| 13:57:01 | * | Jehan_ quit (Quit: Leaving) |
| 14:01:53 | * | Jesin quit (Quit: Leaving) |
| 14:06:40 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 14:09:14 | * | gokr quit (Quit: Leaving.) |
| 14:13:36 | * | Jesin joined #nimrod |
| 14:22:53 | * | jagillion quit (Quit: jagillion) |
| 14:27:40 | * | q66[lap] quit (Ping timeout: 250 seconds) |
| 14:28:51 | * | BlaXpirit joined #nimrod |
| 14:40:14 | * | kshlm quit (Ping timeout: 250 seconds) |
| 14:40:15 | * | kaushal_ joined #nimrod |
| 14:46:54 | * | saml quit (Read error: Connection reset by peer) |
| 14:47:22 | * | saml joined #nimrod |
| 14:47:49 | * | khmm quit (Ping timeout: 260 seconds) |
| 14:51:32 | * | kaushal_ quit (Quit: Konversation terminated!) |
| 15:08:31 | * | jagillion joined #nimrod |
| 15:10:03 | * | jagillion quit (Client Quit) |
| 15:32:08 | * | BitPuffin joined #nimrod |
| 15:52:14 | * | gokr_ joined #nimrod |
| 16:13:01 | * | Demos joined #nimrod |
| 16:19:41 | * | io2 joined #nimrod |
| 16:38:54 | * | brson joined #nimrod |
| 16:41:34 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 17:02:04 | * | Demos quit (Ping timeout: 255 seconds) |
| 17:04:08 | * | io2 quit (Quit: ...take irc away, what are you? genius, billionaire, playboy, philanthropist) |
| 17:08:40 | * | xcombelle_ joined #nimrod |
| 17:22:13 | * | xcombelle quit (Disconnected by services) |
| 17:22:22 | * | xcombelle_ is now known as xcombelle |
| 17:22:53 | * | xcombelle_ joined #nimrod |
| 17:23:15 | * | xcombelle quit (Quit: Quitte) |
| 17:23:34 | * | xcombelle_ quit (Remote host closed the connection) |
| 17:23:46 | * | xcombelle joined #nimrod |
| 17:25:31 | * | rgrau quit (Remote host closed the connection) |
| 17:42:02 | * | noam quit (Read error: Connection reset by peer) |
| 17:42:33 | * | noam joined #nimrod |
| 17:47:07 | * | Demos joined #nimrod |
| 17:47:40 | * | askatasuna joined #nimrod |
| 18:05:16 | Araq | ping Varriount__ |
| 18:17:17 | * | gokr_ quit (Read error: Connection reset by peer) |
| 18:17:29 | * | gokr_ joined #nimrod |
| 18:22:33 | * | oldclone quit (Remote host closed the connection) |
| 18:22:55 | * | clone1018_ joined #nimrod |
| 18:24:02 | * | Triplefox quit (Ping timeout: 245 seconds) |
| 18:25:19 | * | Triplefox joined #nimrod |
| 18:35:33 | * | gokr_ quit (Remote host closed the connection) |
| 18:35:46 | * | gokr_ joined #nimrod |
| 18:43:13 | * | Demos quit (Ping timeout: 265 seconds) |
| 18:47:23 | * | gokr joined #nimrod |
| 18:47:52 | gokr | Evening folks |
| 18:48:05 | Araq | servus |
| 18:48:16 | gokr | Family in bed, time for hacking ;) |
| 18:48:45 | Araq | I'm hacking NSIS support to niminst |
| 18:49:04 | Araq | it's lots of fun, things just work :-) |
| 18:49:05 | gokr | Ah, NSIS is quite nice, although it was many years ago I used it. |
| 18:49:16 | gokr | Yeah, IIRC it was quite a pleasure - and just a single script too. |
| 18:49:32 | gokr | So you are mainly on windows or? |
| 18:49:34 | Araq | the scripting language kind of sux, but I'm generating the script anyway |
| 18:50:01 | Araq | I'm mostly on windows, sometimes on Linux, never on osx |
| 18:50:03 | gokr | yeah, but it got the job done. And it was quite easy to find snippets and examplkes. |
| 18:50:09 | Araq | yup |
| 18:50:38 | gokr | We support win and osx for our client, so I had to get myself an MBP to be able to build the VM for OSX etc. |
| 18:50:59 | gokr | Otherwise I am on Ubuntu, but we use mainly CentOS so far for our servers. But we are moving to Ubuntu. |
| 18:51:15 | gokr | I love my Lenovo X220. |
| 18:52:13 | Araq | I used to use Linux much more, but it keeps getting worse. regressions everywhere. |
| 18:52:21 | gokr | So I am writing an article on c2nim usage - doing a wrapper for Hyperdex. It works now I think, the wrapper. Next step is to make some Nimiomatic unpure middle layer. |
| 18:52:24 | Araq | maybe it's my distro though |
| 18:52:30 | gokr | Which distro is that? |
| 18:54:06 | gokr | I had a "source distro" period a few years back. Lunar Linux. Was fun, but a time sink. |
| 18:54:25 | gokr | Now I just use Ubuntu because it mostly just works. |
| 18:55:06 | gokr | But tools like Vagrant and Docker etc are interesting for developers. We use Vagrant to auto test our installers/system on different distros. |
| 18:55:50 | gokr | (Vagrant basically automates VirtualBox and Docker is basically a chroot on steroids) |
| 18:56:26 | gokr | I think Vagrant is great for a build farm, not sure if the Nim farm uses something like that? |
| 18:58:25 | Araq | we use nimbuild ... |
| 18:58:57 | gokr | yeah, I know you guys wrote your own - just curious if it uses say Vagrant to build for different OSes etc. |
| 18:59:23 | Araq | no, we use some of GCC's testing machines |
| 18:59:33 | gokr | Oh? they offer that? |
| 19:00:12 | Araq | for selected open source software |
| 19:00:22 | Araq | dom96 managed to convince them :-) |
| 19:00:28 | gokr | nice! :) |
| 19:02:32 | gokr | So, using c2nim - I noticed you can do fairly much in the header file before running c2nim - but... say I need to add some "type uint16_t = uint16" etc, can I do that in the header file somehow - or do I need to massage the nim file afterwards? |
| 19:03:16 | * | vendethiel quit (Ping timeout: 250 seconds) |
| 19:03:55 | Araq | you can use #mangle, that does something similar |
| 19:04:12 | gokr | Ah... I see it. |
| 19:04:23 | gokr | Reading the manual page a bit more closely ;) |
| 19:04:30 | Araq | there is no #emit support yet |
| 19:05:00 | Araq | the manual is *dense*, easy to overlook things |
| 19:05:14 | gokr | Which is why my little article might help someone later. |
| 19:05:19 | gokr | I hope. |
| 19:05:25 | Araq | me too |
| 19:05:42 | Araq | but when I write docs I know nobody reads it anyway |
| 19:05:55 | gokr | I am reading it now :) |
| 19:06:34 | Araq | so my hope was if I keep things slim, maybe more people read it |
| 19:06:42 | gokr | Yeah. |
| 19:07:08 | gokr | So would you prefer type "aliases" or the mangle approach? For these int guys. |
| 19:09:57 | * | noam quit (Read error: Connection reset by peer) |
| 19:10:11 | * | noam joined #nimrod |
| 19:11:03 | wan | "nobody reads it anyway" I know I do. When I discovered Nimrod, I read the tutorial in its entirety. And when I want to recall myself certain things, I grep in the manual and read the corresponding part. |
| 19:11:18 | wan | So not nobody |
| 19:11:44 | gokr | Yeah, I would never have been here if I hadn't been able to read the tutorials/manual to get a grip on the languae. |
| 19:11:46 | gokr | language. |
| 19:17:31 | gokr | mangles worked nicely, thanks. |
| 19:21:13 | Araq | well yes, I prefer mangle over these excessive type aliases |
| 19:21:46 | Araq | I mean IF uint16_t is uint16 then it's rather pointless, and if it is not, it's confusing as hell |
| 19:21:55 | * | q66[lap] joined #nimrod |
| 19:22:03 | gokr | Hehe, definitely so. |
| 19:23:39 | * | Sergio965 joined #nimrod |
| 19:24:34 | Araq | wan: well I know I don't read anything. reading is work. I mostly skim and guess things. |
| 19:26:18 | gokr | In Smalltalk I read a lot of code to understand things. The env is built for browsing and debugging. But... in these more static environments I tend to read more "external docs" since I can't as easily cross reference or just run a little snippet and see what happens. |
| 19:27:11 | gokr | I am curious about debugging - I played with it, but it didn't seem there was any command to actually show the source - is it? Thus it felt more designed to be integrated with an editor/IDE. |
| 19:29:13 | * | Sergio965 quit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 19:30:54 | Araq | the nim debugger is barely working and not really maintained |
| 19:31:18 | Araq | what works is GDB and --debugInfo --lineDir:on |
| 19:31:43 | Araq | there is also --embedSrc but who needs that when there is --lineDir |
| 19:32:12 | Araq | well it works not only with gdb, the visual studio debugger is also used |
| 19:32:14 | * | vendethiel joined #nimrod |
| 19:32:42 | gokr | Oh, so the VS debugger works "as it should" with Nim source code etc? |
| 19:33:16 | gokr | I mean, debugging the resulting C code is not my cup of tea :) |
| 19:33:33 | Araq | it's quite good yes. but I mostly use 'echo' and .injectStmt |
| 19:34:18 | gokr | So... somehow there is a mapping from the C code to Nim line numbers or? |
| 19:34:24 | Araq | yes |
| 19:34:34 | gokr | But not to individual expressions I presume? |
| 19:34:40 | gokr | Its line by line debugging? |
| 19:34:44 | Araq | yes |
| 19:35:09 | gokr | This is interesting - so... any IDE that can use gdb could do this basically? |
| 19:37:04 | Araq | it generates C's #line directives |
| 19:37:11 | Araq | it works with everything |
| 19:37:40 | gokr | I haven't been in the C world in a long time, at least not "seriously". |
| 19:38:19 | gokr | I sense a subject for the next article here. |
| 19:39:05 | * | vendethiel- joined #nimrod |
| 19:39:33 | * | vendethiel quit (Ping timeout: 272 seconds) |
| 19:39:50 | Araq | well generating C has its advantages ;-) |
| 19:40:02 | gokr | Definitely so. |
| 19:40:03 | Araq | even in the days of LLVM |
| 19:40:43 | gokr | The Squeak VM is built by transpiling a subset of Smalltalk (slang) to C (or C++ I think for the Cog VM). |
| 19:41:47 | Araq | but yes. a debugging guide for Nim would be awesome |
| 19:41:55 | gokr | Yup. |
| 19:42:14 | Araq | especially if you tell people how to use .injectStmt to get superb watchpoint support |
| 19:42:23 | gokr | That VM thingy ... that I guess you use for compile time Nim execution? How complete is that? |
| 19:42:35 | gokr | (please tell :)) |
| 19:43:16 | * | skyfex joined #nimrod |
| 19:43:29 | Araq | it doesn't support the FFI and ptr/ref semantics are still quite broken |
| 19:43:41 | gokr | Btw, Amber which is a pretty darn cool Smalltalk that compiles and runs in js - I know the guy who wrote it. He was thinking on how to make a really good debugger. |
| 19:43:49 | Araq | as these are hard to model in a VM |
| 19:43:57 | gokr | And he decided to actually build an Amber interpreter (in Amber) - to get proper debugging. |
| 19:44:28 | Araq | you can't do that realistically for systems programming |
| 19:44:40 | gokr | No, perhaps not. |
| 19:44:45 | gokr | But... for many other domains? |
| 19:45:22 | gokr | http://amber-lang.net |
| 19:45:37 | gokr | (if you press that button a Smalltalk IDE (the old one) opens up in the page) |
| 19:45:52 | gokr | I notice the ASTDebugger is actually in there. |
| 19:48:04 | gokr | Amber is mainly written in itself - I wonder if it could be ported to Nim, humhum. |
| 19:55:03 | Araq | what's the point though? usually the language designer likes his language better than anything else |
| 19:55:25 | gokr | Oh, no I meant... the boot part. |
| 19:55:45 | gokr | So Amber has a small "kernel" in js, and then the rest is written in Amber. |
| 19:55:55 | Araq | oh btw, to answer your question: a standard 'class' macro is planned. well we like to pick the winner eventually. |
| 19:56:02 | gokr | And.. I think Nicolas basically needs stuff like closures etc . |
| 19:56:29 | gokr | So the boot.js is about... well, less than 1000 lines at least. |
| 19:56:33 | * | boydgreenfield joined #nimrod |
| 19:56:36 | Araq | that said, I don't think it ends up in a mess |
| 19:56:46 | gokr | Ah, great! |
| 19:56:55 | Araq | the macros ultimately all compile down to object + procs or methods |
| 19:57:10 | Araq | so I don't see any interop problems arising |
| 19:57:24 | gokr | Yeah, I know - but it sure will be helpful if we can keep the proliferation to a minimum. |
| 19:58:08 | gokr | I always wonder how macro enabled languages affect the advancement of IDEs. |
| 19:58:53 | gokr | Avi Bryant (sharp Smalltalker who created www.seaside.st) said something about that - the fact that Smalltalk doesn't really have macros - made the IDE possible. |
| 19:59:18 | gokr | If the code turns too much into "free form" - then the IDE can't really reason, browse, analyze etc. |
| 19:59:27 | gokr | Although hygienic is much better. |
| 20:00:11 | gokr | But still, I wonder how a "Smalltalk style" IDE could be made for Nim - browsers and cross referencing tools etc. |
| 20:00:31 | Araq | hrm dunno. it is a hard problem, hygiene doesn't help you much here |
| 20:00:53 | gokr | It always saddened me when VisualAge was "dumbed down" to Eclipse. |
| 20:01:31 | Araq | however, it's easy to come up with heuristics to get it to work |
| 20:01:40 | gokr | yeah |
| 20:01:49 | gokr | At least there is lots of type info :) |
| 20:02:46 | gokr | You never entertained the idea of a "always in runtime" Nim? Like Smalltalk is? |
| 20:03:13 | gokr | The C part of course makes that ... very hard. |
| 20:03:43 | Araq | well a REPL basically has all these problems, so yeah we think about it all the time |
| 20:03:58 | Araq | people here *really* want a REPL |
| 20:04:41 | gokr | Hehe. Can't help smiling there. |
| 20:05:32 | gokr | When you go "all live" like Smalltalk - then you end up with issues like data migration etc. Which of course is why Smalltalk has #become: and so on. |
| 20:06:19 | gokr | But the power from always being able to edit your app as its running, is pretty darn powerful. |
| 20:13:04 | Araq | yeah but there is a time when people use your app and you're not debugging anymore |
| 20:13:19 | Araq | I really like the compiletime vs runtime split |
| 20:13:58 | Araq | not to mention that "can edit everything at runtime" sounds like a security desaster waiting to happen |
| 20:14:04 | gokr | Do note that Smalltalks compile to bytecode, but the compilation unit is "method" typically. |
| 20:14:48 | gokr | And the "edit everything" of course depends on available mechanisms in the image. If there is no Compiler class, no tools etc, then its just as safe as any other. |
| 20:14:54 | * | johnsoft quit (Read error: Connection reset by peer) |
| 20:15:10 | gokr | It hasn't prevented JP Morgan from building one of the most advanced derivative system handling trillions of dollars :) |
| 20:15:31 | * | johnsoft joined #nimrod |
| 20:15:50 | gokr | Nor did it prevent TI to run one of their whole fab factories in Smalltalk. |
| 20:16:07 | Araq | as an outsider this means nothing. Cobol didn't stop them to handle trillions of dollars either |
| 20:16:33 | gokr | I agree, I just mean that "oh, its dynamic and there can't be trusted" is... an easy pun to make. |
| 20:16:38 | EXetoC | conclusion: cobol is awesome |
| 20:17:01 | gokr | I can agree on many "faults" in Smalltalk, but its typically not "can't be trusted". |
| 20:18:13 | Araq | I disagree. I'm sure many people argued Bash can be trusted. |
| 20:18:22 | gokr | Hehe! |
| 20:18:45 | Araq | speaking of which |
| 20:18:59 | Araq | the Bash bug would have been prevented with Nim's effect system. |
| 20:19:04 | Araq | Worth an article. :-) |
| 20:19:09 | gokr | Definitely! |
| 20:19:33 | gokr | I haven't really read much about that part of Nim. |
| 20:20:07 | EXetoC | doit! articleize |
| 20:20:30 | EXetoC | multitask |
| 20:21:12 | gokr | Btw, just so you know - whenever I start blabbering about Smalltalk - its because the *experience* of working in a Smalltalk IDE is so amazing and I really would like to ... "inject" some of these thoughts into Nim - since Nim is so darn awesome on tons of other aspects. So don't misinterpret it as criticism or "Smalltalk is better". |
| 20:22:14 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 20:24:33 | * | boydgreenfield joined #nimrod |
| 20:33:01 | * | Matthias247 joined #nimrod |
| 20:36:20 | * | xcombelle quit (Quit: Quitte) |
| 20:36:50 | Araq | fyi: http://www.tele-task.de/archive/video/flash/16130/ |
| 20:41:41 | * | boydgreenfield quit (Quit: boydgreenfield) |
| 20:42:51 | gokr | Aha, DCI, by Trygve |
| 20:43:33 | gokr | Father of MVC - did an internship at PARC and came up with it then. I have met him, he is actually working in Squeak doing his tooling - Baby something. |
| 20:44:10 | gokr | BabyUML :) |
| 20:46:46 | gokr | I wrote SqueakMap (the first Nimble of Squeak one can say) and he has some stuff on there. |
| 20:46:58 | gokr | I admit I haven't read up on DCI properly. |
| 20:47:06 | gokr | Araq: You have? |
| 20:47:54 | Araq | no, I'm watching his talk, but it's mostly wrong |
| 20:48:48 | gokr | Btw, as a funny article perhaps on OO - Joe Armstrong bashed OO in an article many years ago. I wrote a debunk on it (http://goran.krampe.se/2009/06/26/joe-is-wrong/) and then I met him at a conference and we talked a lot! I helped him hook up Erlang with Squeak. |
| 20:49:35 | gokr | Later we met again and he said to me "Yeah, you were right. That article I wrote was before I understood OO.". That was kinda funny. |
| 20:49:56 | gokr | Now he claims Erlang is the only true OO lang, hehe, and in a philosophical sense I can buy what he means. |
| 20:50:50 | gokr | Coplien is a long time... OO guy. But I admit not having read much from him. |
| 20:51:27 | gokr | I used to attend OOPSLA slavishly every yeary. But it turned into crap so then I attend ESUG instead (Smalltalk conf), typically in Europe. |
| 20:52:26 | * | shodan45 joined #nimrod |
| 20:52:46 | * | Demos joined #nimrod |
| 20:53:45 | Araq | yeah I agree. Erlang is OO and like any OO system it simply doesn't work well. ;-) |
| 20:54:15 | gokr | Hehe, you are very anti OO, that's interesting. |
| 20:54:33 | gokr | (although the definition of OO is... not clear) |
| 20:54:59 | gokr | Alan Kay's latest definition of OO is kinda funny. |
| 20:55:35 | gokr | This was from ... 2003: "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme LateBinding of all things." |
| 20:56:35 | Demos | OO seems to have no meaning, the meanings it does have are often wrong and/or not a good idea in the first place |
| 20:56:51 | gokr | But Alan is very ... open minded. He never settled for anything. And he feels Lisp is the greatest language ever created :) |
| 20:57:43 | gokr | Its worth remembering that Alan "coined the term", but he has always felt the focus ended up wrong - on the structures. And not on messaging as perhaps being the more important aspect. |
| 20:57:58 | Araq | so lets go through the list ... "messaging" for me means *asyncronous* messaging |
| 20:58:10 | Araq | that's not what Smalltalk does |
| 20:58:15 | gokr | Well, first Smalltalks were actually asynch. |
| 20:58:22 | gokr | But not Smalltalk-80. |
| 20:58:36 | * | Sergio965 joined #nimrod |
| 20:58:39 | Araq | interesting, i didn't know that |
| 20:58:42 | gokr | They experimented for like 10 years with various Smalltalks - testing different ideas. |
| 20:58:58 | * | Sergio965 quit (Client Quit) |
| 20:59:00 | gokr | And as I said Alan wasn't pleased with the 80 version that was the one that got out in the wild. |
| 20:59:20 | Araq | oh wait, the guys is right |
| 20:59:21 | gokr | These guys were doing lots of research - and they still do. |
| 20:59:40 | gokr | In fact, Alan was annoyed with the Smalltalk community not "moving on". |
| 20:59:57 | * | Sergio965 joined #nimrod |
| 21:00:16 | gokr | Btw, Traits was born too in the Smalltalk community. Then borrowed over into Fortress and then spread. |
| 21:00:55 | gokr | And how Traits was born is an interesting discussion too. I know how it came about and it ended up not at all as it was first meant. |
| 21:01:08 | gokr | Sorry for rambling. |
| 21:01:53 | gokr | Araq: Did you ever read Dan's article on Smalltalk? Dan Ingalls is the "real" architect, Alan was the visionary. |
| 21:02:01 | gokr | Its short and nice, let me find it. |
| 21:02:31 | * | Jehan_ joined #nimrod |
| 21:03:02 | gokr | Even if you don't agree on parts of it - its a very interesting article that everyone can read and contemplate a bit on: http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html |
| 21:03:33 | Araq | Demos: OO is actually very well defined by Cook's papers |
| 21:03:58 | Demos | Araq, oh yes I guess I have read those |
| 21:04:05 | gokr | What paper is that? |
| 21:04:17 | gokr | Being a Smalltalker I am skeptic :) |
| 21:05:04 | Demos | his point is that the central idea with OOP is that you can have operations that do not know about their operands, and that this is not always a good idea |
| 21:05:27 | * | flaviu joined #nimrod |
| 21:05:28 | Araq | http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf |
| 21:05:31 | Jehan_ | For what it's worth, I think the lack of OOP support is one of Nim's major weaknesses. :) |
| 21:05:31 | gokr | Thanks |
| 21:06:25 | * | Sergio965 quit (Quit: Bye! :)) |
| 21:06:27 | Jehan_ | Not an issue I'm going to litigate, though. :) |
| 21:10:49 | gokr | Jehan_: When you say "lack" - what specific parts are you reffering to lacking? |
| 21:10:55 | gokr | referring. |
| 21:11:43 | Jehan_ | gokr: Nim has only some limited approximations of OOP features. |
| 21:12:36 | gokr | Please do tell more :) |
| 21:13:44 | gokr | Btw, that essay ... at least contains one really odd statement. |
| 21:14:21 | Araq | well that's debatable. it has single inheritance and multi methods. and macros can implement a 'class' structure. and it's not a coincidence that 'class' is not reserved keyword. |
| 21:14:21 | Jehan_ | Umm, what's there to tell? Variant types (while a useful abstraction tool in their own right) are limited compared to traditional OOP. Similarly, Nim's methods are lacking several things that you'd expect in an OOP system. |
| 21:14:54 | gokr | "Since Smalltalk is dynamically typed, classes are only used as constructors." Ehm, what? |
| 21:15:09 | Jehan_ | Not to mention the difficult argument whether multiple dispatch is a good or bad thing. |
| 21:15:27 | gokr | But multiple dispatch is optional, right? |
| 21:15:39 | Jehan_ | gokr: Optional in what way? |
| 21:16:19 | Jehan_ | The problem is if you have more than one argument that's polymorphic, multiple dispatch can break encapsulation. |
| 21:16:20 | gokr | I mean, you can dispatch on the "receiver" or on several, or oh.. no? I need to check how Nim works. |
| 21:16:35 | Jehan_ | What makes the argument difficult is that you can argue that this is either a feature or a bug. |
| 21:16:48 | Araq | multiple dispatch is a good thing in the sense that's not any harder to reason about it than single dispatch. |
| 21:16:52 | gokr | Slate has multiple dispatch - but you decide in the signature which parameters to dispatch on. |
| 21:17:03 | Jehan_ | Another problem is that there's really no good way to define "super" methods with multiple dispatch. |
| 21:17:24 | Jehan_ | And Nim doesn't support a "next method" mechanism, the closest thing. |
| 21:18:16 | Araq | a macro easily patches over that :P |
| 21:18:49 | Jehan_ | One thing I also haven't sorted out yet is how Nim decides what methods are considered if you have them distributed over several modules. |
| 21:18:56 | Araq | generate a fooSuper proc for any method foo and then you can influence |
| 21:19:05 | Jehan_ | Araq: The problem with a macro-based approach is that you'll get multiple incompatible implementations. |
| 21:19:45 | gokr | Araq: Btw, Slate has macros too - might want to check how it does it. |
| 21:19:47 | Araq | only until we decided which macro should end up in the stdlib |
| 21:20:14 | EXetoC | yay macros |
| 21:20:45 | Araq | Jehan_: C++ and Qt proves that you can end up with these problems even if you have a builtin class mechanism |
| 21:21:05 | Jehan_ | Araq: I blame C++ for that. |
| 21:21:27 | Araq | there is always the problem of how much RTTI you wish to support |
| 21:21:47 | Araq | C++ as a systems programming language is an unfortunate position here |
| 21:21:48 | gokr | Slate uses delegation btw for inheritance, and it uses multiple dispatch. |
| 21:22:00 | gokr | And I think Julia has multi dispatch too, doesn't it? |
| 21:22:07 | Araq | but I wouldn't blame it for the problem |
| 21:22:34 | gokr | Personally I like languages to explore delegation mechanisms much more than "classes". |
| 21:22:44 | Jehan_ | As a result of C++'s design, C++ libraries tend to be weighed down with implementation considerations rather than providing clean abstractions. |
| 21:23:06 | Jehan_ | And much of Qt's hacks are due to the lack of clean higher-order function support in C++. |
| 21:23:12 | gokr | Which (going back to Traits) was the idea behind the Traits research (new ways of composition of behavior) - and funny enough it ended up as "yet another class thingy". |
| 21:24:15 | Jehan_ | Which reminds me, the Cake pattern is a very useful thing that is difficult to support in Nim. |
| 21:24:21 | Araq | Qt's hacks are due to the lack of reflection in C++ |
| 21:24:32 | Jehan_ | Or in C++, for that matter. |
| 21:24:42 | Araq | not as much as due to lacking clean higher order functions |
| 21:27:20 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 21:30:41 | Araq | Jehan_: what's the "cake pattern"? |
| 21:32:33 | Jehan_ | http://www.cakesolutions.net/teamblogs/2011/12/19/cake-pattern-in-depth |
| 21:33:11 | EXetoC | will "foo.bar x=1, y=2" be supported? |
| 21:35:42 | * | askatasuna quit (Ping timeout: 245 seconds) |
| 21:36:04 | Araq | bli bla blub ... "service" ... "component" ... "factory" |
| 21:36:17 | Araq | "mock" |
| 21:36:20 | Araq | "manager" |
| 21:36:33 | gokr | I agree, I hate this stuff. |
| 21:36:44 | gokr | I hate DI blabla. |
| 21:39:42 | Jehan_ | Araq: Short version: it solves the mutually recursive module problem. |
| 21:40:45 | Araq | ok but calling the resulting stuff "modules" is the real problem |
| 21:41:24 | Araq | how can you use any of them without the others? you can't. ergo, not a module system. |
| 21:42:26 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 21:42:53 | gokr | Bracha to the rescue: http://gbracha.blogspot.se/2007/12/some-months-ago-i-wrote-couple-of-posts.html |
| 21:45:04 | gokr | The Java people (and C# btw and more) make more and more intricate ways of never writing down a class name - since that (oh my!) would create a dependency on something real. |
| 21:45:35 | gokr | So they end up with factories and registries and god knows what. DI out the butt. |
| 21:47:18 | flaviu | gokr: factories are fine. The problem is that people see _Design Patterns_ as a checklist, not a dictionary. |
| 21:47:55 | gokr | Such code is horrendous to understand IMHO. Funny enough the Smalltalk community (and I guess Python etc) never got entangled in this, and I presume it has to do with the difference in type systems and module mechanisms. Recursive dependencies are fine and if not, well, classes are actually objects - you can send those around too. |
| 21:48:06 | gokr | flaviu: Yeah, sure. |
| 21:48:48 | gokr | The basic Factory pattern is allright, the original GOF book is quite fine. But the whole DI etc, somewhere down the line it became silly. |
| 21:49:04 | Araq | " Static type based overloading is a truly bad idea, with no redeeming value whatsoever. Multiple dispatch is related, but dynamic, and so much better." meh, I disagree. |
| 21:49:21 | gokr | And many patterns are indeed "workarounds" for limitations in languages. |
| 21:49:23 | * | q66 joined #nimrod |
| 21:49:53 | gokr | From Bracha? |
| 21:50:04 | EXetoC | eh |
| 21:50:17 | gokr | Yeah, it was. Gilad Bracha is opinionated :) |
| 21:50:31 | gokr | But he is pretty good at putting his finger on stuff. |
| 21:50:58 | gokr | He is building Newspeak - a modern kindof Smalltalk I would call it. |
| 21:51:40 | gokr | http://en.wikipedia.org/wiki/Gilad_Bracha |
| 21:51:58 | gokr | He worked on the precursor to Hotspot among other things. |
| 21:51:59 | Jehan_ | Araq: A class is a module of which there can be more than one instance. |
| 21:53:31 | gokr | Araq: His paper on pluggable type systems may be of interest: http://bracha.org/pluggableTypesPosition.pdf |
| 21:54:15 | Jehan_ | flaviu: That's a great way to put it. |
| 21:55:21 | gokr | Its about optional type systems etc - given his influence in Strongtalk and Dart, but can be worth reading through as a language designer :) |
| 21:57:39 | Jehan_ | http://dl.acm.org/citation.cfm?id=570532 |
| 21:58:06 | Jehan_ | (about design patterns) |
| 21:58:07 | flaviu | Jehan_: ACM requires a subscription |
| 21:58:33 | Jehan_ | flaviu: Yeah, but the abstract should give you the basic idea. |
| 21:58:56 | gokr | It says patterns are good? Of course they are. |
| 21:59:46 | Jehan_ | gokr: No, it doesn't. The study is more specific. |
| 21:59:53 | gokr | No sorry, it states that comments using pattern names etc - improves it. Right. |
| 21:59:58 | Demos | also, 360-560 LOC |
| 22:00:01 | Jehan_ | It's about whether documented design patterns can aid with maintenance of programs. |
| 22:00:18 | * | Lorxu joined #nimrod |
| 22:00:21 | gokr | But I agree - design patterns is about communication of design. Its easier to communicate with names on stuff. |
| 22:00:29 | Araq | Jehan_: that is a definition that doesn't match how many/most people think about class/module |
| 22:00:45 | gokr | If I say, yeah, this is a variant of the Flyweight pattern - then of course that will give information. |
| 22:00:46 | Araq | plus it defines "class", but not "module" |
| 22:00:52 | Jehan_ | Araq: Then they need to learn. |
| 22:01:32 | Jehan_ | For example, in Eiffel, a class IS a module. Meyer is pretty explicit about that. |
| 22:01:42 | gokr | Newspeak makes the same connection. |
| 22:02:04 | gokr | (class and module) |
| 22:02:06 | * | leehambley joined #nimrod |
| 22:02:10 | Araq | so? Modula 2 is about modules too |
| 22:02:14 | Demos | OK something that bothers me about traits is that they seem to overlap way to much with other mechanisms. Like being able to dump stuff in a namespace, interfaces, generics, and "concepts" |
| 22:02:31 | Araq | and I'm pretty sure Wirth used a different definition of module for modula 2... |
| 22:03:07 | Jehan_ | Demos: Traits are only different from abstract classes in Scala because Scala needed/wanted interop with Java and Java has very specific constraints on abstract classes. |
| 22:03:14 | gokr | Coming from Smalltalk where Traits was born - we were very excited at first. Then ... well, we started wondering about how *useful* they are in contrast to how much the complicate things. |
| 22:03:20 | Jehan_ | Other languages with MI do not distinguish between the two concepts. |
| 22:03:46 | Demos | Jehan_, Rust is the confusing one. They just seem like a fancy name for something that is not really special |
| 22:03:56 | Jehan_ | Araq: And Modula-2 modules are also different from ML modules. |
| 22:04:06 | Araq | Jehan_: yes. exactly my point. |
| 22:04:31 | Jehan_ | Araq: Insisting that one specific definition of module is THE correct one doesn't help. |
| 22:05:08 | Jehan_ | Module is an overloaded term for a lexical container that contains other definitions, variables, constants, procedures, types. |
| 22:05:51 | Jehan_ | Classes give you the same thing, with the difference that they can be instantiated multiple times. |
| 22:06:06 | Araq | yes exactly. *my* definition includes a notion of "can be re-used without hand waving" :P |
| 22:06:41 | Jehan_ | I don't care about the exact terminology, my point is that a class as a concept has everything a module has, plus multiple instantiation. |
| 22:06:49 | gokr | As with many things there is no exact definition of these words. |
| 22:07:53 | gokr | Jehan_: But... in Smalltalk a class is an object. :) So.... the "Module = Class" doesn't fly in all contexts. |
| 22:08:06 | Jehan_ | Which makes it immensely useful for concurrency, for example, where traditional module systems have their problems. |
| 22:08:09 | gokr | (and with "an object" I mean - its an instance of a metaclass) |
| 22:08:18 | Jehan_ | gokr: One doesn't exclude the other. |
| 22:08:30 | gokr | No, but the waters get muddy. |
| 22:08:38 | Jehan_ | Besides, I didn't say "module = class". There's no equality. |
| 22:08:45 | gokr | But I do agree that they concepts are very close. |
| 22:08:57 | Jehan_ | A class is an object in a different way than a module is a class. |
| 22:10:39 | gokr | In Smalltalk a class in an object like any other. Most other languages don't have this meta recursion. |
| 22:10:59 | gokr | "is an" |
| 22:11:20 | Jehan_ | gokr: Only because of Smalltalk's reflection capabilities. |
| 22:11:37 | gokr | No... |
| 22:11:59 | gokr | They are there. They are real. They aren't just created if you ask for them or so. |
| 22:12:01 | Jehan_ | Other than that, class methods and class variables are a pretty common concept. |
| 22:13:07 | gokr | I am not sure what you mean with "Only because...". |
| 22:13:35 | Araq | Jehan_: the "multiple instantiation" feature is both a blessing and a curse |
| 22:13:42 | Jehan_ | As in, "that's the only real practical difference"? |
| 22:13:46 | Jehan_ | Araq: In what way? |
| 22:13:58 | gokr | Its not like "reflection" was added to Smalltalk, or like its a separate feature. Classes *are* objects. |
| 22:14:36 | Araq | Jehan_: that it introduces the aliasing problems |
| 22:14:40 | Jehan_ | It's a core feature, yes. |
| 22:14:49 | Jehan_ | Araq: Huh? |
| 22:15:56 | Araq | well it leads to a 1 to N mapping between symbols and runtime objects |
| 22:16:15 | Araq | imagine a language that only has global variables |
| 22:16:43 | Araq | contrary to common wisdom this is actually damn easy to analyse and reason about |
| 22:17:25 | Jehan_ | Unless, of course, you have multiple threads. |
| 22:17:35 | Jehan_ | At which point it gives you additional headaches instead. |
| 22:17:58 | Araq | no, I don't think so. |
| 22:18:07 | Araq | it's impractical, yes |
| 22:18:09 | gokr | Ehm... with only global variables - you mean "no modules"? |
| 22:18:22 | gokr | As in no imports etc, a single namespace. |
| 22:18:28 | Araq | but "hard to analyse" is not its problem |
| 22:18:35 | * | Lorxu quit (Ping timeout: 258 seconds) |
| 22:18:36 | Jehan_ | gokr: No, he means static vs. heap memory. |
| 22:20:36 | Jehan_ | Araq: If you want a clear 1-to-1 relation, there's objects in Scala, once routines in Eiffel, expanded types in Eiffel, inheritance in pretty much any OO language. |
| 22:20:53 | * | Demos_ joined #nimrod |
| 22:21:29 | * | leehambley quit (Quit: Linkinus - http://linkinus.com) |
| 22:23:46 | * | johnsoft quit (Ping timeout: 240 seconds) |
| 22:24:14 | * | johnsoft joined #nimrod |
| 22:24:16 | * | Demos quit (Ping timeout: 255 seconds) |
| 22:27:41 | gokr | Is this stuff in some stdlib these days? https://github.com/fowlmouth/nimlibs/blob/master/fowltek/pointer_arithm.nim |
| 22:28:39 | * | vendethiel- quit (Ping timeout: 272 seconds) |
| 22:29:10 | * | vendethiel joined #nimrod |
| 22:29:36 | gokr | fowl: Perhaps you know :) |
| 22:29:39 | Araq | Jehan_: nevertheless there is not a single OO language that is used for embedded programming. And no FP language either. it's all C, Ada, C++, maybe Forth |
| 22:29:59 | Jehan_ | Araq: Yeah, but I'm not interested in embedded programming. |
| 22:30:11 | Jehan_ | Embedded programming makes different trade-offs. |
| 22:30:35 | Jehan_ | It incurs costs that I don't want for my purposes and has benefits that don't help me. |
| 22:31:38 | Demos_ | fwiw I think that nimrod does a really good job of being very simple but providing more tools than anyone else to provide interfaces in any way that you may want |
| 22:31:45 | Araq | fair enough, but I rather take inspiration from stuff that truely works |
| 22:32:09 | gokr | Araq: Lars Bak felt otherwise: http://esug.org/data/ESUG2003/tuesday/Lars+Bak+ESUG.pdf |
| 22:32:30 | gokr | But I agree - even if it could be used - they aren't used. |
| 22:32:32 | Demos_ | "expected a dict object" I see, how interesting |
| 22:32:53 | Araq | instead of stuff that works because somebody says so that has a nice haircut and time to blog about the world |
| 22:33:00 | Araq | (no offense, gokr ;-) ) |
| 22:33:16 | Jehan_ | Araq: Umm, different application domains have different needs. |
| 22:33:17 | gokr | Mmm, Lars Bak is not someone with a nice haircut. |
| 22:33:27 | Jehan_ | There's no universal "stuff that truly works". |
| 22:34:53 | gokr | He is after all perhaps the most experience VM designer/implementor in the world :) |
| 22:41:13 | Araq | Jehan_: I'm not so sure about that. quite some studies show that verification works and is cost effective. |
| 22:41:59 | Jehan_ | Araq: Depends on the size of your software. |
| 22:42:13 | gokr | How about a Tektronix TDS 500 Series Oscilloscope from 1987? 64 kb RAM? Does it count as embedded? :) |
| 22:42:24 | Jehan_ | And whether the mechanisms your language have are sufficiently powerful to form abstractions for the problem domain. |
| 22:43:11 | Jehan_ | The stuff I'm working on (computer algebra), automated verification is essentially useless. |
| 22:43:30 | Jehan_ | Because the invariants themselves are non-trivial mathematical problems. |
| 22:44:59 | Jehan_ | Embedded software tends to still deal with pretty straightforward stuff. This is why you can use things like SPARK for them. |
| 22:46:49 | Jehan_ | But once you hit stuff that Coq and Isabelle struggle with … /shrug |
| 22:51:03 | Jehan_ | Hmm. iMac with 5k retina display? This is … tempting. |
| 22:52:38 | Araq | well it depends. but for instance, an index ouf of bounds is never correct and you don't need a spec of any sort to detect it compile-time either |
| 22:53:29 | Araq | verifying array bounds is quite useful |
| 22:55:08 | * | Trustable quit (Quit: Leaving) |
| 22:58:39 | Jehan_ | Yes, but not a trivial exercise in my world, either. |
| 22:59:20 | Jehan_ | Or so trivial that it's not an important source of software defects. |
| 23:02:03 | gokr | Silly question (trying to learn how to fish) - I have a cstring and wants to make a string of it (I got length too, not null terminated) - how do I find out how? |
| 23:04:25 | Araq | use theindex.html |
| 23:04:44 | Araq | but it's not that useful when you're really helpless |
| 23:04:59 | Araq | use $ to get a string out of it |
| 23:05:01 | gokr | Mmmm, I did... but not sure what to search for perhaps. |
| 23:05:17 | gokr | But... where does the len come into play? |
| 23:05:52 | Araq | I don't think there is a $ for you. but it's no big deal: |
| 23:06:04 | Araq | proc `$`(x: cstring; len: int): string = |
| 23:06:12 | Araq | result = newString(len) |
| 23:06:28 | Araq | copyMem(addr(result[0]), x, len) |
| 23:08:43 | gokr | Cool |
| 23:24:48 | gokr | Araq: But how does an operator with 2 args work? "mycstring $ len"? |
| 23:25:22 | gokr | Just so I don't misunderstand something, 2 args for an operator turns it into an infix op, right? |
| 23:26:06 | Araq | not quite, but close enough for a newbie ;-) |
| 23:26:36 | Araq | so yes, infix notation works |
| 23:28:23 | Araq | the compiler has no notion of a 2 args operator: |
| 23:28:58 | Araq | proc `$`(a,b: int; dummy = 8): int = a+b |
| 23:29:07 | Araq | echo 4$4 # works |
| 23:29:21 | * | xenagi joined #nimrod |
| 23:29:37 | Araq | it's simply that the infix notation passes 2 operands to $ |
| 23:29:50 | gokr | Right, I found that part in the manual now. |
| 23:30:05 | Araq | whether that makes sense is then left for overloading resolution to decide |
| 23:30:45 | gokr | It looks pretty funky though with "cstring $ len" or? I mean, from a style standpoint. |
| 23:30:55 | gokr | It feels dirty :) |
| 23:31:33 | Araq | I think it makes perfect sense |
| 23:31:45 | gokr | oki |
| 23:32:03 | Araq | there is a binary $ for WideCString already |
| 23:32:39 | gokr | Ah, ok |
| 23:37:43 | * | tillzy joined #nimrod |
| 23:40:38 | Varriount__ | Araq: pong |
| 23:40:45 | * | Varriount__ is now known as Varriount |
| 23:41:08 | Araq | Varriount: I produced a web installer, will upload it soon |
| 23:41:23 | Araq | but I don't know how you do the 32 vs 64 bit builds |
| 23:41:51 | Araq | I'm only building 32 and leave the 64 version to you :P |
| 23:43:16 | Araq | mingw and the docs are now optional downloads and the installer is only 3MB :-) |
| 23:45:31 | Varriount | Araq: I download the 64 bit mingw-w64? |
| 23:45:58 | Araq | yeah but you have nice scripts to build both 32 and 64 versions of Nim |
| 23:46:03 | Araq | I don't |
| 23:46:50 | * | xenagi quit (Read error: Connection reset by peer) |
| 23:47:02 | * | xenagi joined #nimrod |
| 23:47:45 | * | darkf joined #nimrod |
| 23:49:09 | fowl | gokr, pointer_arithm is in a stdlib, i consider fowltek to be my stdlib |
| 23:49:21 | gokr | :) |
| 23:53:58 | Varriount | Araq: You want a 64 bit build of nimrod, or of mingw? |
| 23:54:08 | Araq | of nimrod |
| 23:54:20 | Araq | I already uploaded the mingw stuff |
| 23:54:41 | Araq | and thanks to the new installer, we don't need to bundle mingw with it at all |
| 23:54:57 | gokr | Muaahaaa! Nimrod just called HyperDex properly. yiha. |
| 23:57:43 | EXetoC | amazing innit |
| 23:58:19 | Varriount | Araq: https://github.com/nimrod-code/kickstart/blob/master/win-kickstart.bat |
| 23:58:21 | gokr | As a stumbling n00b any step is a win :) |
| 23:58:31 | Varriount | What is hyperdex? |
| 23:58:43 | gokr | Its a freakishly cool nosql db. |
| 23:58:48 | Varriount | Is it related to a pokedex? |
| 23:59:00 | gokr | Ehm. no? www.hyperdex.org |
| 23:59:11 | gokr | Silly fast, fully master less. |
| 23:59:46 | * | xenagi quit (Read error: Connection reset by peer) |