| 00:00:36 | Araq | Varriount: just import compiler/vm.nim |
| 00:01:06 | ldlework | Mat3: impressed at how bad it is, and how cultish people who like it seem |
| 00:01:43 | ldlework | I've never heard a Golang user give a reasonable reflection upon go |
| 00:01:46 | ldlework | It doesn't have any faults |
| 00:02:05 | ldlework | Each fault is really actually just a SUPER CLEVER design decision by Pike because he understands how to make our lives better |
| 00:02:52 | Mat3 | hmm, probably a lot of newer languages these time waste ressources by maintain 'cultish' marketing? |
| 00:02:53 | ldlework | "I like that X (is totally broken) works that way" |
| 00:02:58 | ldlework | ^ |
| 00:03:04 | ldlework | This is how you know you're talking to a Golang programmer |
| 00:03:18 | ldlework | MOST programmers in any other language wont hesitate to critque their own language |
| 00:03:23 | ldlework | and point out its stupid flaws |
| 00:03:37 | ldlework | but not golang programmers, they're like mesmorized into massochism |
| 00:04:00 | Jehan_ | Mat3: I think that's mostly just a natural effect of language fandom. Same as you'll get with video games or movies, just applied to languages. Not a conscious thing. |
| 00:05:07 | Joe_knock | Wait hold on. Doesn't JavaScript have the same GoLang thing going on? |
| 00:05:11 | ldlework | I had someone I work with claim that the fact that you cannot use Go interfaces with its built-in map type obviates ENTIRE CLASSES OF PROBLEMS |
| 00:05:22 | ldlework | I mean holy shit |
| 00:05:29 | ldlework | This guy is -super incredibly smart- |
| 00:05:32 | Jehan_ | Joe_knock: What do you mean? |
| 00:05:35 | ldlework | smarter than I by leaps |
| 00:05:53 | Mat3 | Jehan_: that's sad but true in my opinion |
| 00:06:11 | Joe_knock | The whole node.js, angular, x-library.js people? |
| 00:06:20 | * | darkf joined #nimrod |
| 00:06:48 | Jehan_ | Joe_knock: Insofar as there's a fair amount of fandom, in my experience, yes, but that goes for most languages once they break critical mass. |
| 00:06:56 | ldlework | Joe_knock: sure but node and angular and so on are not -fundamentally broken- |
| 00:07:50 | Mat3 | yesterday, I waste some hours trying to discuss with a person, who wan't me to believe in efficient (I mean by ressource usage) static compilation of dynamic languages like Smalltalk ?!??? |
| 00:07:55 | Jehan_ | Joe_knock: I could tell the difference between before Ruby became popular and after, for example. |
| 00:08:42 | Joe_knock | Mat3: You should show them efficient by saying "watch Bayern Munich play football" ;) |
| 00:08:53 | Jehan_ | Mat3: You can do some really surprising stuff with dynamic languages these days. Not sure what the specific claims are, but they are not inherently outlandish. |
| 00:09:35 | Joe_knock | The JIT compilers do make languages like Julia/etc somewhat "fast" |
| 00:10:38 | * | Boscop__ joined #nimrod |
| 00:10:39 | Araq | Mat3: what's the status of your C compiler? we need it for a proper REPL |
| 00:11:04 | Varriount | Araq: Eh.. how can a compiler act as a repl? |
| 00:11:26 | Araq | it's fine if it doesn't really care about C's corner cases, the codegen can always avoid them |
| 00:11:35 | Araq | Varriount: in memory compilation? |
| 00:11:36 | Jehan_ | Varriount: I think when it compiles to memory. |
| 00:12:04 | Araq | the nice thing about this solution is that even .emit works then |
| 00:12:38 | Mat3 | Araq: I think to be finish end of november (two weeks free time for working on it) |
| 00:12:49 | * | Boscop_ quit (Read error: Connection reset by peer) |
| 00:13:02 | Varriount | But will such a solution work? What's the difference between this and doing something hackish with gcc? |
| 00:13:03 | Araq | yummy |
| 00:13:39 | Araq | Varriount: gcc and llvm are big dependencies and don't support in memory codegen |
| 00:13:54 | Araq | maybe llvm now does but building llvm is a pain |
| 00:14:20 | Jehan_ | Araq: I saw an example the other week about how to do it with LLVM, but yeah, the dependency is a bit of a pain. |
| 00:14:47 | Mat3 | Varriount: As I progress, it seem to work well |
| 00:17:25 | Mat3 | Jehan_: From my own experiences, JIT compilation has some advantages yes (it is by design only ressource intensive compared to AOT compilation) |
| 00:18:11 | Jehan_ | Mat3: What do you mean by "resource intensive"? Memory, CPU usage? Both? Something else? |
| 00:18:34 | Mat3 | mainly memory intensive, to a lesser extend CPU usage |
| 00:19:28 | Jehan_ | Mat3: Hmm, I've found memory usage to be largely a function of the more aggressive optimizations, not necessarily a JIT vs. AOT thing. |
| 00:19:48 | Varriount | If only we had a static compiler that could attach a runtime optimizer to a program. |
| 00:19:56 | * | Joe_knock left #nimrod ("Leaving") |
| 00:20:34 | Jehan_ | Varriount: That's largely what LLVM does? |
| 00:21:05 | Varriount | It does? I thought llvm was just a compiler. |
| 00:21:08 | Mat3 | Jehan_: Excactly and because runtime latency still matters for JIT compilers this is a weak point (that's one reason why even Google switched now to an AOT framework for there new Android version as I know) |
| 00:21:12 | Jehan_ | It's officially a JIT, but works more like an incremental in-memory AOT compiler, last I checked. |
| 00:21:59 | Jehan_ | Mat3: Hmm, the benchmarks I saw for Android with/without AOT didn't indicate a major difference. Of course, that may simply AOT compilation being relatively weak still. |
| 00:22:17 | Jehan_ | Varriount: LLVM has both an AOT and a JIT option. |
| 00:22:23 | Araq | did anybody look at Psycho's code? |
| 00:22:29 | Jehan_ | Araq: Where? |
| 00:22:36 | Varriount | Isn't android AOT compilation mainly for the memory benefits? |
| 00:22:45 | Araq | I mean the python JIT thing |
| 00:22:56 | Jehan_ | Oh, Psyco. |
| 00:23:07 | Araq | oh, my bad |
| 00:23:28 | Jehan_ | Araq: Last I checked, it's been abandoned? |
| 00:23:47 | Varriount | It was abandoned in favor of Pypy |
| 00:23:56 | Araq | yeah I just thought it should be easier to grasp than LuaJIT :-) |
| 00:24:04 | Jehan_ | Heh. |
| 00:24:17 | Araq | and who wants to read pypy, lol. |
| 00:24:34 | Jehan_ | I deeply, deeply admire Mark Pall's skill, but … that at the same time makes me reluctant to rely on LuaJIT. |
| 00:24:44 | Varriount | Jehan_: I don't simply mean bytecode and a jit compiler, I mean optimization of already compiled assembly code at runtime. |
| 00:25:11 | Jehan_ | Varriount: Hmm, you lost me. What specific use case do you have in mind? |
| 00:25:26 | Varriount | Jehan_: Nothing in particular, just general optimizations. |
| 00:25:58 | Jehan_ | Varriount: If you're talking about just compiled assembly code without any IR, then doing further optimizations is already pretty hard. |
| 00:29:15 | Mat3 | Jehan_: I noticed better (read lesser) memory usage. However it is still a work in progress at moment |
| 00:30:09 | Jehan_ | Mat3: I see. I have to admit that I'm not really following Android much these days. |
| 00:33:05 | Araq | btw it's "Mike Pall", Jehan_ |
| 00:33:18 | Araq | and I think he's german :-) |
| 00:33:20 | Jehan_ | Oops, typo. I know that it's Mike. |
| 00:33:27 | Jehan_ | And yeah, he's from Munich, as far as I know. |
| 00:33:43 | Araq | too bad we can't summon him to come here |
| 00:33:52 | Jehan_ | Araq: methodDef does a linear search of gMethods? |
| 00:34:06 | Araq | quite possible |
| 00:34:33 | Araq | now that we have working hash tables, we can change that |
| 00:34:40 | Jehan_ | Hmm, this is going to be an O(n^2) bottleneck for a large number of methods. On the other hand, it should be pretty easy to make it a hash table. |
| 00:34:50 | Araq | I didn't have them when I wrote it |
| 00:35:04 | Jehan_ | Just looking at it to see where dispatcher generation is getting messed up in brianrogoff's example. |
| 00:35:43 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 00:36:52 | Mat3 | Araq: He seem to be very busy |
| 00:37:37 | milosn | hmmm if i do this: let devnull = open("/dev/null", fmReadWrite) |
| 00:37:58 | milosn | how do i get id of the fd? |
| 00:38:07 | milosn | of the 'devnull' i mean |
| 00:38:11 | milosn | evening btw |
| 00:38:29 | Araq | getFileHandle or fileHandle |
| 00:38:32 | Jehan_ | milosn: getFileHandle(devnull), I think. |
| 00:38:55 | Jehan_ | Oops, yeah, fileHandle for 0.9.6. |
| 00:39:04 | Jehan_ | I'm used to working with bigbreak. |
| 00:43:10 | milosn | Jehan_: seems to be working |
| 00:44:27 | milosn | ive poked with some daemonize() code i have in python and made nimrod version :), so i needed dup(fh_devnull, 0) and friends |
| 00:45:21 | milosn | this should really belong someplace in one of the modules |
| 00:45:51 | milosn | or maybe not, cause its *nix specific |
| 00:45:54 | Jehan_ | milosn: If you're working so low level, you may want to use posix.nim directly. |
| 00:46:08 | milosn | Jehan_: i am using posix.nim :) |
| 00:46:25 | Jehan_ | Oh, in that case, you should use posix.open()? |
| 00:46:25 | milosn | but there is no proc to daemonize process |
| 00:46:40 | milosn | or i am missing something |
| 00:47:11 | milosn | you mean: let devnull = posix.open("/dev/null", fmReadWrite) |
| 00:47:12 | Jehan_ | milosn: double fork? |
| 00:47:29 | Mat3 | ciao |
| 00:47:31 | Jehan_ | posix.open("/dev/null", posix.O_RDWR)? |
| 00:47:34 | * | Mat3 quit (Quit: Verlassend) |
| 00:47:41 | milosn | Jehan_: i can try that :) |
| 00:47:55 | Jehan_ | That should get you a handle or -1 upon failure. |
| 00:47:58 | milosn | let me see in docs how it works exactly |
| 00:48:23 | Jehan_ | open(path, fmRead) dispatches to fopen(). |
| 00:48:42 | Jehan_ | And returns a FILE * (hidden behind an opaque type). |
| 00:56:32 | Varriount | Araq: I don't see where the part of the installer which creates shortcuts is missing. |
| 01:09:21 | Araq | Varriount: me neither but it should be changed anyway |
| 01:14:46 | Araq | Jehan_: any objections against the static_call idea? |
| 01:15:00 | Jehan_ | Araq: You mean as an alternative to super? |
| 01:15:06 | Araq | yes |
| 01:15:33 | Jehan_ | What exactly would it look like? I imagine you'd somehow upcast one or more arguments? |
| 01:15:56 | Araq | static_call meth(Foo(f), Bar(b)) |
| 01:16:11 | Araq | you convert to what you need |
| 01:16:25 | Araq | static_call prevents that the dispatcher is used |
| 01:16:49 | fowlmouth | lame |
| 01:16:59 | Jehan_ | Hmm. Let me look at the semantics and think about whether they'd match reasonable needs. |
| 01:17:05 | Araq | IMHO much cleaner than "call-next" |
| 01:17:09 | Jehan_ | I'm not too crazy about the name "static_call", though. |
| 01:17:10 | fowlmouth | just make method(supertype(x)) work, its explicit enough |
| 01:17:16 | Jehan_ | Araq: Yeah, but semantics are different. |
| 01:17:39 | Araq | fowlmouth: no. it's crazy. |
| 01:17:54 | Araq | let x = Foo(y); m(x) # dynamic call |
| 01:18:05 | Jehan_ | Araq: I'm just wondering whether next-method has a sensible application that static_call doesn't. |
| 01:18:06 | Araq | m(Foo(y)) # static call?! wtf |
| 01:18:21 | fowlmouth | Araq, theres an old issue about this |
| 01:18:27 | Araq | I know |
| 01:18:34 | Jehan_ | Actually, I know that it's got a applications in computer algebra, but that's a weird type system, anyway. |
| 01:18:51 | Jehan_ | I'm wondering if there's something more realistic also. |
| 01:18:54 | Araq | and there is a reason I didn't implement it yet, fowlmouth |
| 01:19:02 | Jehan_ | Ugh, give me half an hour, brb. |
| 01:20:44 | Araq | no worries, just post it here, I'm sleeping |
| 01:20:51 | Araq | good night |
| 01:23:36 | Jehan_ | Okay, in this case I won't rush it. |
| 01:28:26 | NimBot | Araq/Nimrod devel 6e37201 Reimer Behrends [+0 ±1 -0]: Various atomics fixes for gcc/clang.... 4 more lines |
| 01:28:26 | NimBot | Araq/Nimrod devel eaa5a25 Andreas Rumpf [+0 ±1 -0]: Merge pull request #1608 from rbehrends/fix-atomics... 2 more lines |
| 01:33:45 | * | Trustable quit (Quit: Leaving) |
| 01:34:11 | * | Boscop_ joined #nimrod |
| 01:38:00 | * | Boscop__ quit (Ping timeout: 244 seconds) |
| 02:38:35 | * | AFKMorpork is now known as AMorpork |
| 03:32:58 | * | kemet joined #nimrod |
| 03:36:00 | * | kemet quit (Remote host closed the connection) |
| 03:44:04 | * | dom96_ quit (Ping timeout: 244 seconds) |
| 03:48:54 | * | brson quit (Quit: leaving) |
| 03:52:18 | * | dom96_ joined #nimrod |
| 05:03:18 | * | Boscop__ joined #nimrod |
| 05:06:52 | * | Boscop_ quit (Ping timeout: 240 seconds) |
| 05:36:43 | * | q66[lap] joined #nimrod |
| 05:37:56 | * | Jehan_ quit (Quit: Leaving) |
| 05:39:46 | * | q66[lap]_ quit (Ping timeout: 250 seconds) |
| 06:07:49 | * | Hakaslak joined #nimrod |
| 06:23:30 | * | xenagi quit (Read error: Connection reset by peer) |
| 06:46:48 | Varriount | Araq: Would you like the builder to test that the compiler can compile using the C++ backend? |
| 06:51:57 | * | kemet joined #nimrod |
| 07:21:14 | * | peter__ joined #nimrod |
| 07:21:44 | peter__ | hi |
| 07:32:50 | * | peter__ quit (Quit: Leaving) |
| 08:01:44 | * | BlaXpirit joined #nimrod |
| 08:03:37 | * | kemet quit (Ping timeout: 258 seconds) |
| 08:29:24 | * | Demos quit (Read error: Connection reset by peer) |
| 08:45:49 | * | darkf quit (Quit: Leaving) |
| 08:46:47 | * | darkf joined #nimrod |
| 09:01:26 | * | untitaker quit (Ping timeout: 264 seconds) |
| 09:11:24 | gokr | Varriount: yes :) |
| 09:18:04 | * | Fran__ joined #nimrod |
| 09:20:03 | * | Francisco quit (Ping timeout: 264 seconds) |
| 09:30:41 | gokr | Araq: I like static_call - but I can agree that the name isn't that... well, it looks clunky. Underscores btw? Not "callStatic"? Or "resolve"? |
| 09:30:52 | * | untitaker joined #nimrod |
| 09:36:21 | * | skyfex quit (Quit: (null)) |
| 09:36:40 | gokr | Btw, I presume you looked at DynASM? But... perhaps its a slightly different beast. |
| 09:43:25 | Varriount | gokr: 'resolve' sounds rather nice, actually. |
| 10:06:37 | * | irrequietus joined #nimrod |
| 10:36:20 | * | BlaXpirit quit (Read error: Connection reset by peer) |
| 10:37:19 | * | BlaXpirit joined #nimrod |
| 10:39:07 | gokr | Regarding the C++ - the reason I said "yes" is that most probably that's the backend we will end up having to use. |
| 10:47:01 | Varriount | gokr: What makes you think that? |
| 10:47:19 | gokr | C++? Because a very important part of our picture is Urho3D. |
| 10:47:51 | Varriount | gokr: The C backend (on bigbreak) has a mixed mode that *should* be able to interface with C++ headers |
| 10:48:06 | gokr | Ah, ok, then in that case... dunno! :) |
| 10:48:20 | gokr | If that works - then sure. |
| 10:48:40 | Varriount | Anyway, the configuration for the new buildbot is about 75% done. Right now I'm testing what's been written so far. |
| 10:48:57 | * | johnsoft quit (Ping timeout: 256 seconds) |
| 10:49:39 | Varriount | After reading 'Windows Internals', which details how the OS sets up page tables and such with the CPU, what virtualbox does is even more magical to me. |
| 10:49:50 | gokr | Hehe. |
| 10:49:58 | gokr | Using vagrant? |
| 10:50:28 | gokr | Ok, gotta drive my daughter, and then lots of other "weekend things", later |
| 10:50:51 | gokr | (we use vagrant to build stuff on various Linuxes and also to make an appliance) |
| 10:51:03 | Varriount | gokr: Buildbot |
| 10:55:32 | gokr | Oh, it too uses vbox or? |
| 11:07:12 | * | gokr_ quit (Remote host closed the connection) |
| 11:12:28 | Varriount | gokr: I'm using vbox to test the bot |
| 11:13:00 | Varriount | However, for some reason, I can't get my host computer to connect to the bot hosted in the vm... |
| 11:13:24 | * | AMorpork is now known as AFKMorpork |
| 11:21:09 | * | kemet joined #nimrod |
| 11:22:10 | Varriount | Be back in a bit, I need to sleep. |
| 11:23:35 | * | johnsoft joined #nimrod |
| 11:52:09 | * | BlaXpirit quit (Quit: Quit Konversation) |
| 11:55:26 | * | Matthias247 joined #nimrod |
| 11:58:32 | * | flaviu joined #nimrod |
| 12:01:04 | * | untitaker quit (Ping timeout: 245 seconds) |
| 12:15:12 | Araq | gokr: static_call vs staticCall is the same in nim |
| 12:16:08 | Araq | 'resolve' is nice, but doesn't capture the essence |
| 12:16:18 | Araq | I think I'll name it procCall |
| 12:19:48 | * | gokr_ joined #nimrod |
| 12:22:29 | * | irrequietus quit () |
| 12:22:48 | * | irrequietus joined #nimrod |
| 12:27:36 | * | untitaker joined #nimrod |
| 12:39:50 | * | Trustable joined #nimrod |
| 12:44:34 | * | kemet quit (Ping timeout: 256 seconds) |
| 13:03:30 | * | darkf quit (Quit: Leaving) |
| 13:18:17 | * | Jehan_ joined #nimrod |
| 13:21:47 | Jehan_ | Araq: I note that immediate macros/templates with varargs do not work, but that there's basically a TODO item in the source code for resolving this. What approach did you have in mind for overloading resolution for immediate macros/templates? |
| 13:22:39 | Araq | immediate macros/templates by definition do not participate in overloading resolution |
| 13:23:45 | Jehan_ | Yeah, I understand that this would be … well, impossible. :) |
| 13:24:03 | Araq | we can fix it with some special rules |
| 13:24:04 | Jehan_ | The question is how varargs is going to be treated in this case. |
| 13:24:15 | Araq | but I'm not sure it's worth it |
| 13:24:33 | Araq | better is to get rid of immediate |
| 13:24:39 | Jehan_ | Umm ... |
| 13:24:43 | Jehan_ | Umm ... |
| 13:24:48 | Araq | though this has its own problems ... |
| 13:24:52 | Jehan_ | That would be a problem. |
| 13:25:28 | Jehan_ | This would pretty much make any macro that defines a new identifier based on a parameter impossible. |
| 13:25:40 | Jehan_ | Unless you plan to introduce a new type for that case. |
| 13:26:11 | Araq | nah, the idea is that semchecking of operands depends on the param type involved |
| 13:26:28 | Araq | template t(x: expr, y, z: int) = ... |
| 13:26:36 | Araq | t(unknownIdent, 3, 4) # valid |
| 13:26:57 | Araq | t(unknownIdent, 8, unknownIdent) # invalid |
| 13:27:08 | Jehan_ | Yes. The price of having immediate macros is that you can't really overload the macro's name, but that's a price I'd be willing to pay. |
| 13:27:26 | Jehan_ | Hmm, I see. |
| 13:27:49 | Araq | this is already implemented but I'm sure it fails for corner cases |
| 13:27:51 | Jehan_ | So basically, expr would serve as an "anything" type (stmt probably, too, to a lesser degree). |
| 13:28:05 | Jehan_ | Hmm. |
| 13:28:05 | Araq | and doesn't work for 'stmt' yet |
| 13:28:48 | Araq | so yeah, 'expr' and 'stmt' are the 2 meta types that mean "do not even semcheck the argument" |
| 13:29:31 | Araq | this is like unifying proc/methods via a 'dynamic' keyword that works on parameter basis |
| 13:29:42 | Araq | if you know what I mean |
| 13:30:06 | Jehan_ | Yeah. |
| 13:30:58 | Jehan_ | Varargs alone should be relatively easy to fix by adapting fixImmediateParams() |
| 13:31:32 | Araq | quite possible, but I don't remember how the code even looks like ;-) |
| 13:32:04 | Araq | I gotta go, see you later |
| 13:40:23 | * | irrequietus quit (Ping timeout: 240 seconds) |
| 13:51:57 | * | bjz quit (Read error: Connection reset by peer) |
| 13:52:16 | * | bjz joined #nimrod |
| 14:07:00 | * | BitPuffin joined #nimrod |
| 14:09:35 | milosn | ummm i am trying to remember, ive seen a module in std lib that does have basic templating functionality |
| 14:09:49 | milosn | templating as in html/xml templates and such |
| 14:09:56 | milosn | not language templates :) |
| 14:10:16 | milosn | can anyone point me again where that actually was? kill me i cant find it again |
| 14:29:31 | * | AFKMorpork is now known as AMorpork |
| 14:31:10 | * | irrequietus joined #nimrod |
| 14:31:50 | dom96 | milosn: is htmlgen what you're looking for? |
| 14:33:30 | * | Matthias247 quit (Read error: Connection reset by peer) |
| 14:33:31 | milosn | dom96: no |
| 14:33:41 | milosn | this was more like crude and basic templating engine |
| 14:33:55 | milosn | but i think it might fit my purpose :) |
| 14:34:37 | dom96 | Maybe you mean this? https://github.com/nimrod-code/nimforum/blob/master/forms.tmpl |
| 14:36:41 | milosn | hmmm |
| 14:36:51 | milosn | looks familiar but not sure :) |
| 15:01:52 | * | xenagi joined #nimrod |
| 15:04:49 | * | gokr_ quit (Ping timeout: 245 seconds) |
| 15:06:12 | * | gokr_ joined #nimrod |
| 15:12:14 | milosn | dom96: which module is this? |
| 15:12:28 | milosn | sorry had to run away for a bit longer moment :D |
| 15:12:44 | dom96 | it's not a module |
| 15:12:51 | dom96 | http://build.nimrod-lang.org/docs/filters.html |
| 15:12:53 | dom96 | it's filters |
| 15:13:10 | milosn | ah |
| 15:13:13 | milosn | that could be it |
| 15:13:38 | milosn | dom96: thats it, thanks |
| 15:13:41 | milosn | ill have a look |
| 15:14:08 | gokr | dom96: Been any "HTML as DSL" attempts in Nim? |
| 15:14:15 | milosn | oh no |
| 15:14:25 | milosn | dont waist time with that |
| 15:14:27 | milosn | :) |
| 15:14:30 | gokr | That approach has been working very well in Seaside and Amber (Smalltalks). |
| 15:14:35 | milosn | imo DSL for HTML is erm |
| 15:14:39 | milosn | whats the word :D |
| 15:14:47 | gokr | Waste time? I have built extensive systems using that technieq. |
| 15:15:02 | gokr | Seaside is a beautiful framework. |
| 15:15:15 | milosn | i know seaside, from some tutorials |
| 15:15:18 | flaviu | gokr: yes, I think fowl did at one point. Let me see if I can dig it up. |
| 15:15:21 | milosn | long time ago tho |
| 15:15:44 | milosn | gokr: nothing beats quick and dirty general purpose templating |
| 15:15:52 | gokr | So Seaside is "all server side" HTML generation - albeit with some ... jQuery etc stuff added for completion in search fields etc. |
| 15:15:56 | milosn | depends really on the project needs, when i think of it better |
| 15:16:08 | gokr | milosn: For complex interfaces, I don't agree. |
| 15:16:17 | milosn | you think so? hmmm |
| 15:16:31 | gokr | The component model of Seaside is superb - but of course, got HTML5 then Amber is the way to go (if you are a Smalltalker). |
| 15:16:38 | gokr | s/got/for |
| 15:17:01 | gokr | The DSL was an enabler for a real component model. |
| 15:17:06 | dom96 | gokr: I think there are some nimble packages |
| 15:17:09 | dom96 | can't remember the names though |
| 15:17:14 | gokr | And to be able to embed callbacks easily for doing advanced UI interactions. |
| 15:17:28 | gokr | But Amber does something similar - but all on the client side. |
| 15:17:35 | flaviu | ok https://github.com/flyx/emerald |
| 15:17:57 | flaviu | I misremembered the name, it's not fowl, it's flyx's |
| 15:18:14 | gokr | smalltalkhub.com being one fairly advanced HTML5 website built in Amber. |
| 15:18:25 | gokr | (a github clone kinda) |
| 15:19:32 | gokr | flaviu: Thanks. |
| 15:20:42 | gokr | So it looks like server side templating, but yes, similar to Seaside I guess. Of course, the trick with Seaside was then making a component model with this (so components can "render themselves" in a composition) - and add callbacks (hehe, somehow. Seaside uses continuations). |
| 15:53:27 | * | untitaker quit (Quit: ZNC - http://znc.in) |
| 15:55:47 | * | Trustable quit (Quit: Leaving) |
| 16:03:33 | * | BitPuffin quit (Ping timeout: 258 seconds) |
| 16:23:51 | Onionhammer | milosn are you referring to nim templates |
| 16:23:53 | Onionhammer | https://github.com/onionhammer/nim-templates |
| 16:26:50 | * | untitaker joined #nimrod |
| 16:27:43 | Onionhammer | subsyntax highlighting is supported in NimLime w/ my templating module |
| 16:27:50 | Onionhammer | in sublimetext |
| 16:39:08 | * | q66[lap] quit (Quit: Textual IRC Client: www.textualapp.com) |
| 16:55:26 | * | vendethiel joined #nimrod |
| 17:00:15 | * | hsuh quit (Ping timeout: 244 seconds) |
| 17:07:56 | * | hsuh joined #nimrod |
| 17:13:25 | Varriount | Araq: Ping |
| 17:16:06 | * | hsuh quit (Ping timeout: 264 seconds) |
| 17:18:13 | fowlmouth | Onionhammer, nimlime is really nice |
| 17:21:21 | * | kemet joined #nimrod |
| 17:22:40 | * | kemet quit (Client Quit) |
| 17:23:07 | * | kemet joined #nimrod |
| 17:24:32 | * | kemet quit (Client Quit) |
| 17:24:54 | * | kemet joined #nimrod |
| 17:44:29 | * | hsuh joined #nimrod |
| 17:47:30 | * | Matthias247 joined #nimrod |
| 17:48:06 | * | Jesin quit (Quit: Leaving) |
| 17:48:29 | * | quasinoxen quit (Ping timeout: 255 seconds) |
| 17:51:26 | * | Jehan_ quit (Quit: Leaving) |
| 17:57:29 | * | kemet quit (Ping timeout: 260 seconds) |
| 17:58:05 | * | Ven joined #nimrod |
| 17:59:36 | * | Hakaslak quit (Quit: TODO: Generate 'Part & Quit Message') |
| 18:01:22 | * | hsuh quit (Ping timeout: 240 seconds) |
| 18:01:50 | * | Jesin joined #nimrod |
| 18:15:05 | * | Demos joined #nimrod |
| 18:22:27 | * | OrionPK joined #nimrod |
| 18:24:29 | * | Onionhammer quit (Ping timeout: 255 seconds) |
| 18:29:33 | * | hsuh joined #nimrod |
| 18:35:55 | flaviu | Is nimbot not working at all? |
| 18:37:55 | * | hsuh quit (Ping timeout: 255 seconds) |
| 18:38:30 | * | onionhammer joined #nimrod |
| 18:41:04 | * | BlaXpirit joined #nimrod |
| 18:41:51 | * | fowlmouth quit (Read error: Connection reset by peer) |
| 18:49:00 | Araq | flaviu: what makes you think so? |
| 18:49:02 | Araq | Varriount: pong |
| 18:51:54 | * | ARCADIVS quit (Quit: ARCADIVS) |
| 18:53:13 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 18:55:27 | * | AMorpork is now known as AFKMorpork |
| 18:57:35 | flaviu | Araq: I'm sending it commands, but I'm not getting an access denied back |
| 18:58:03 | Varriount | Araq: Do you want the builder to test that the compiler bootstraps using the C++ backend? |
| 18:58:25 | Araq | Varriount: sure |
| 19:01:11 | * | gokr_ quit (Remote host closed the connection) |
| 19:01:24 | * | gokr_ joined #nimrod |
| 19:05:53 | * | hsuh joined #nimrod |
| 19:44:08 | * | xenagi quit (Read error: Connection reset by peer) |
| 19:46:41 | * | irrequietus quit (Ping timeout: 260 seconds) |
| 19:50:10 | * | xcombelle joined #nimrod |
| 20:00:41 | * | Jesin quit (Quit: Leaving) |
| 20:09:29 | * | Fran__ is now known as Francisco |
| 20:10:26 | * | Ven joined #nimrod |
| 20:12:37 | flaviu | I used a negative number in substr, but nothing crashed |
| 20:12:45 | flaviu | Debug mode btw |
| 20:15:41 | * | mbenadda_ joined #nimrod |
| 20:16:36 | * | irrequietus joined #nimrod |
| 20:28:38 | * | Dispatch joined #nimrod |
| 20:36:47 | * | Ven quit (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 20:38:04 | * | Ven joined #nimrod |
| 20:39:43 | gokr | When I build a nim module as an .so library - the names get mangled. Ehm, is there some system around this? |
| 20:40:22 | gokr | I mean, I want to call this code from somewhere else - and... do I need to build some scanning of the library to get the proper names out or? |
| 20:41:08 | flaviu | gokr: Yep, there's a way to avoid it. 1 sec |
| 20:41:54 | flaviu | https://github.com/Araq/Nimrod/blob/devel/lib/pure/pegs.nim does it |
| 20:42:58 | flaviu | gokr: relevant manual section http://nimrod-lang.org/manual.html#exportc-pragma |
| 20:43:36 | gokr_ | Thanks! |
| 20:45:35 | * | gokr quit (Ping timeout: 265 seconds) |
| 20:49:10 | Varriount | Araq: A side effect of having csource branches correspond to Nim branches is that it makes this buildbot config so much more simple. |
| 20:53:04 | * | silven quit (Ping timeout: 272 seconds) |
| 21:10:41 | flaviu | https://github.com/Araq/Nimrod/blob/devel/lib/pure/oids.nim#L53 looks fishy |
| 21:12:01 | * | Jesin joined #nimrod |
| 21:14:30 | Varriount | Araq: What is koch clean supposed to do? |
| 21:16:23 | Varriount | flaviu: Muahahahaha! |
| 21:16:33 | flaviu | ? |
| 21:16:55 | flaviu | That's not intentional, I hope |
| 21:21:59 | flaviu | Also, "Invalid cross-device link" when moving a file |
| 21:23:53 | flaviu | Anyone have any idea what's going on? Perhaps movefile doesn't support moving directories |
| 21:24:58 | flaviu | https://github.com/Araq/Nimrod/pull/1618 is a very straight-forward bugfix, if anyone wants to merge. I don't see there being any problems with doing so. |
| 21:25:22 | Varriount | flaviu: Are you moving a directory with a hardlink or symlink in it? |
| 21:26:23 | Varriount | flaviu: I'll merge it in a couple of seconds, however can I hold off until I get another bit of the new buildbot up? |
| 21:26:38 | Varriount | I want to test recieving changes from github hooks. |
| 21:30:21 | Varriount | Araq: Which would you prefer, a build service hosted by another party (travis.ci) or something hosted by us (buildbot) |
| 21:32:32 | * | Jehan_ joined #nimrod |
| 21:39:30 | Varriount | Araq: http://imgur.com/XtSKsu9 |
| 21:42:06 | NimBot | Araq/Nimrod bigbreak a77dc8e Flaviu Tamas [+0 ±1 -0]: Remove extra trailing zero |
| 21:42:06 | NimBot | Araq/Nimrod bigbreak 2e53e63 Varriount [+0 ±1 -0]: Merge pull request #1618 from flaviut/patch-3... 2 more lines |
| 21:51:06 | Araq | for fuck's sake |
| 21:51:20 | Araq | oidToString is *exported* |
| 21:51:31 | Araq | you can't simply get rid of the trailing zero |
| 21:52:02 | Araq | Varriount: revert that PR please |
| 21:52:02 | NimBot | Araq/Nimrod revert-1618-patch-3 cbe733a Varriount [+0 ±1 -0]: Revert "Remove extra trailing zero" |
| 21:52:22 | NimBot | Araq/Nimrod bigbreak cbe733a Varriount [+0 ±1 -0]: Revert "Remove extra trailing zero" |
| 21:52:22 | NimBot | Araq/Nimrod bigbreak 598b43e Varriount [+0 ±1 -0]: Merge pull request #1619 from Araq/revert-1618-patch-3... 2 more lines |
| 21:52:27 | Jehan_ | Is there a reason why it's exported? |
| 21:52:41 | Varriount | <3 Github |
| 21:53:13 | Araq | Jehan_: dunno, but I wrote it. I usually have my reasons. |
| 21:53:49 | Jehan_ | :) |
| 21:54:29 | Jehan_ | It seems just that it's awfully low-level functionality that doesn't appear to be particularly time-critical. |
| 21:55:21 | Araq | now having said that, the code indeed is wrong |
| 21:55:43 | Araq | it should really do newString(24) |
| 21:59:39 | Araq | Varriount: dunno yet. hosted by another party costs money? |
| 22:07:30 | * | superfunc joined #nimrod |
| 22:08:53 | Araq | Jehan_: thought about my staticCall proposal? |
| 22:09:47 | * | silven joined #nimrod |
| 22:10:01 | Jehan_ | Araq: I was thinking about it, and both "static call" and "next method" have benefits that the other doesn't have. But for the time being, static call would solve more immediate needs in a more intuitive fashion. |
| 22:10:27 | Jehan_ | I think that static call is not the best name, and not just because "static" is already horribly overloaded. |
| 22:10:46 | Araq | well I will likely name it procCall |
| 22:11:31 | Jehan_ | redispatch? |
| 22:12:14 | Araq | well but it doesn't even invoke the (runtime) dispatcher |
| 22:12:43 | Araq | "nodispatch" ? |
| 22:12:56 | Jehan_ | dispatch can also be computed at compile time. |
| 22:13:17 | Jehan_ | Isn't re-dynamic-dispatch. :) |
| 22:13:31 | Araq | sure, but I usually don't use it for compile-time mechanisms |
| 22:13:48 | * | xcombelle quit (Quit: Quitte) |
| 22:13:58 | Jehan_ | I take it you don't have to match an existing method signature directly but that the compiler will figure out the most specific signature for you? |
| 22:14:18 | Araq | yeah |
| 22:14:27 | Jehan_ | I just think it's generally nice to have a single word for core mechanisms. |
| 22:15:39 | Araq | I even thought of "nail" but I guess that's too weird |
| 22:15:48 | Araq | nail foo(a, b) |
| 22:15:55 | Jehan_ | Heh. :) |
| 22:18:26 | Araq | "grip"? |
| 22:18:43 | Jehan_ | Um ... |
| 22:18:47 | Araq | "hold"? |
| 22:18:49 | * | Francisco quit (Ping timeout: 260 seconds) |
| 22:19:01 | Araq | "cling"? |
| 22:19:02 | * | Fr4n joined #nimrod |
| 22:19:05 | Jehan_ | Not really the meaning you want to convey. |
| 22:19:19 | Jehan_ | After all, you're still calling a method, you don't just fix argument types. |
| 22:19:59 | Jehan_ | call or dispatch or send or invoke are verbs that convey that meaning. |
| 22:20:24 | Araq | well it depends. the call syntax is there too |
| 22:20:41 | Araq | m(a, b) is obviously a call, right? |
| 22:21:34 | Araq | so 'nail m(a, b)' does that call but holds the 'm' |
| 22:24:12 | Araq | claw m(a, b) # hrm |
| 22:25:51 | Jehan_ | All flowery words, too. |
| 22:26:05 | Jehan_ | I'd prefer static call over either. |
| 22:29:53 | Araq | argh ... I hate it when the compiler is smarter than me |
| 22:30:08 | Araq | I've been hunting a phantom again |
| 22:30:44 | Araq | but hrm |
| 22:32:01 | Jehan_ | Heh. :) |
| 22:32:26 | Jehan_ | I was wondering at times the other night whether I was hunting a phantom, too. |
| 22:32:35 | Jehan_ | But in the end, it was a subtle sharing issue. |
| 22:32:59 | Jehan_ | Interestingly enough, not one that immutable data structures/functional programming would have prevented. |
| 22:34:56 | Araq | well it looks like my effect system extension for higher order functions could be better |
| 22:35:38 | Jehan_ | Context? |
| 22:35:43 | * | sdw joined #nimrod |
| 22:35:53 | Araq | hi sdw welcome back |
| 22:35:57 | sdw | Hi Araq |
| 22:36:15 | Araq | Jehan_: well I'm fixing bugs that the convex hull example showed |
| 22:36:23 | Jehan_ | Ah. |
| 22:36:31 | Jehan_ | Me too, see PR. |
| 22:36:34 | Araq | and interestingly the compiler complains it's not gcsafe |
| 22:37:06 | Jehan_ | Hmm. |
| 22:37:33 | Jehan_ | I don't see higher order functions in there, though? |
| 22:38:05 | Jehan_ | Oops, different example. |
| 22:38:08 | * | Jehan_ cannot read. |
| 22:38:28 | * | irrequietus quit () |
| 22:38:44 | flaviu | Varriount: Sorry, I stepped away. Thanks for merging. |
| 22:38:44 | flaviu | No, the directory doesn't contain any symlinks |
| 22:39:18 | flaviu | Has movefile been tested on linux with dirs? |
| 22:43:11 | Araq | obviously "moveFile" is not supposed to be used with *dirs* |
| 22:47:58 | Jehan_ | flaviu: It calls rename(3) underneath, so I'd suspect that it does. |
| 22:49:19 | flaviu | I'm not sure why it fails then. "Invalid cross-device link" isn't one of the error codes in the man page |
| 22:50:50 | Jehan_ | Huh. |
| 22:52:21 | * | tinAndi joined #nimrod |
| 22:55:16 | Jehan_ | flaviu: Just tried a simple example on Linux, and it works. |
| 22:55:26 | Jehan_ | You don't have an odd mount point somewhere? |
| 22:55:34 | flaviu | I'm moving from tmpfs to btrfs |
| 22:55:51 | flaviu | The error code isn't mentioned in the man page :/ |
| 22:58:09 | flaviu | Python also hit this oddity! |
| 22:58:18 | flaviu | relevant bug http://bugs.python.org/issue212317 |
| 22:59:38 | Jehan_ | EXDEV oldpath and newpath are not on the same mounted file system. |
| 22:59:38 | Jehan_ | (Linux permits a file system to be mounted at multiple points, |
| 22:59:38 | Jehan_ | but rename() does not work across different mount points, even |
| 22:59:38 | Jehan_ | if the same file system is mounted on both.) |
| 23:00:09 | flaviu | I used a C-f that didn't catch that, my bad |
| 23:06:44 | Araq | I know you cannot hear it anymore, but it's typical |
| 23:07:29 | Araq | linux could copy/remove in these cases where move doesn't work |
| 23:08:02 | * | fowl joined #nimrod |
| 23:08:49 | flaviu | Araq: I actually don't like this particular issue. Linux should do exactly that. |
| 23:09:26 | flaviu | What annoys me is that you claim windows is superior - which is great at times when I'd just spent *three* hours waiting for it to update |
| 23:10:18 | Jehan_ | Araq: That's actually what `mv` does. But it's not something that a system call should do. |
| 23:10:58 | flaviu | Yep, mv does what's expected. |
| 23:11:17 | * | Fr4n quit (Ping timeout: 264 seconds) |
| 23:12:10 | Araq | Jehan_: er. but who says it's a system call really? often it's in libc instead. |
| 23:12:28 | * | Fr4n joined #nimrod |
| 23:12:31 | * | Dispatch quit (Ping timeout: 246 seconds) |
| 23:13:14 | Araq | that's just an implementation detail that is used to define the API |
| 23:13:26 | Jehan_ | And there are libraries that have functions to do renames across devices, too. |
| 23:14:51 | flaviu | Python has shutil.move |
| 23:14:55 | Jehan_ | It's a bit more than an implementation detail, moving a directory from one filesystem to another is a fairly involved operation. |
| 23:16:55 | Araq | flaviu: as opposed to linux? that has no big updates? |
| 23:17:16 | flaviu | ... I'm not even going to respond to that |
| 23:28:52 | * | fowl coughs |
| 23:30:58 | Jehan_ | Want some lozenges? :) |
| 23:34:47 | * | darkf joined #nimrod |
| 23:39:43 | * | sdw quit (Ping timeout: 258 seconds) |
| 23:42:00 | Varriount | Araq: If you look at the link to the screenshot I posted, you'll see that the entire build process can be split into steps. |
| 23:43:07 | Varriount | I can also split the steps into builds, which show up as new columns. |
| 23:43:49 | Araq | ok, nice |
| 23:44:17 | * | johnsoft quit (Ping timeout: 264 seconds) |
| 23:44:30 | * | johnsoft joined #nimrod |
| 23:58:00 | * | Fr4n quit (Ping timeout: 272 seconds) |
| 23:58:15 | * | Fr4n joined #nimrod |
| 23:58:55 | * | sdw joined #nimrod |
| 23:58:57 | * | Trustable joined #nimrod |