| 00:00:00 | Araq | proc makeCString(x: string): PRope = strutils.escape(x).toRope |
| 00:00:18 | reactormonk | yeah, about that |
| 00:07:52 | reactormonk | Araq, ehh, I found a scoping issue with templates |
| 00:09:53 | reactormonk | curl http://sprunge.us/ZAZN > foo.nim && nimrod -d:nodejs foo.nim && node nimcache/foo.js |
| 00:10:04 | reactormonk | http://sprunge.us/HhWB |
| 00:10:47 | Araq | yeah yeah yeah, I know I know |
| 00:13:02 | reactormonk | looks rather ugly to fix |
| 00:15:22 | reactormonk | I think I should look out for a job in QA |
| 00:28:41 | * | SchalaZeal joined #nimrod |
| 00:29:09 | SchalaZeal | Is openarray deprecated in favor of varargs? |
| 00:29:32 | Araq | SchalaZeal: no, but they are slightly different |
| 00:30:48 | SchalaZeal | hmm |
| 00:30:52 | SchalaZeal | how? |
| 00:31:47 | Araq | read the manual |
| 00:33:20 | SchalaZeal | hmm... I'm reading the latest and it says nothing for openarrays |
| 00:33:29 | SchalaZeal | just varargs |
| 00:34:41 | SchalaZeal | oh! |
| 00:34:59 | SchalaZeal | tutorial has it |
| 00:38:51 | * | Zerathul quit (Quit: ChatZilla 0.9.89 [Firefox 18.0.2/20130201065344]) |
| 00:43:52 | SchalaZeal | hmm... in the middle of making another JS wrapper, wondering if this would be accurate: proc browserOpera*(): bool{.importcpp: "Prototype.Browser.Opera", nodecl.} |
| 00:44:09 | reactormonk | SchalaZeal, nope, use importc |
| 00:44:13 | SchalaZeal | okay |
| 00:44:21 | reactormonk | and the nodecl isn't necessary iirc |
| 00:44:29 | SchalaZeal | ah... |
| 00:45:49 | SchalaZeal | I was trying to wrap EaselJS last week when I came across something troubling: a child class that apparently redefines a superclass's variable |
| 00:46:04 | reactormonk | huh |
| 00:46:35 | SchalaZeal | like.... hmm... |
| 00:47:45 | SchalaZeal | EaselJS's DisplayObject and its child class BitmapAnimation both have two separate `cache` variables |
| 00:48:28 | SchalaZeal | oh |
| 00:48:30 | SchalaZeal | wait...no |
| 00:48:59 | SchalaZeal | we have an instance of the equivalent of multi-methods here |
| 00:49:52 | SchalaZeal | thing is... should I use method syntax for a JS wrapper? |
| 00:50:25 | Araq | you shouldn't |
| 00:51:18 | SchalaZeal | well right now I have one field in TDisplayObject called cache, a proc pointer, and then in a child class TBitmapAnimation there's an overriding of that |
| 00:51:32 | SchalaZeal | or polymorphism |
| 00:51:35 | SchalaZeal | not sure |
| 00:52:21 | Araq | you have to think differently to approach JS wrapping ;-) |
| 00:53:33 | Araq | it's not hard: you have to do is to ensure that nimrod's primitive JS backend will produce the proper JS *syntax* |
| 00:54:01 | Araq | in JS: obj.f(x) |
| 00:54:03 | SchalaZeal | hmm |
| 00:54:32 | SchalaZeal | so a string object could be an int for all it cares? |
| 00:54:44 | SchalaZeal | hypothetically speaking |
| 00:55:02 | Araq | yes |
| 00:55:14 | SchalaZeal | that DOES make it easier |
| 00:56:49 | SchalaZeal | Hmm... when I importc, do I have to specify it exactly how it's typed in the JS file? |
| 00:57:51 | SchalaZeal | Because in JS you can call it like Prototype.Browser.WebKit, however... here's how it's written in the source: https://github.com/sstephenson/prototype/blob/ecacc02/src/prototype/prototype.js#L76 |
| 00:58:11 | Araq | how it's called is what matters |
| 00:58:19 | SchalaZeal | ah |
| 00:58:24 | SchalaZeal | that clears things up |
| 00:59:01 | Araq | proc p() {.importc: "Prototype.Browser.WebKit.DoIt".} |
| 00:59:02 | Araq | p() |
| 00:59:07 | Araq | will produce: |
| 00:59:19 | Araq | Prototype.Browser.WebKit.DoIt(); |
| 01:00:27 | * | fowl joined #nimrod |
| 01:00:35 | SchalaZeal | I see |
| 01:05:11 | Araq | ok good catch the manual doesn't mention openarrays ... |
| 01:05:18 | Araq | fixing that |
| 01:11:29 | reactormonk | Araq, I assume the scoping is uglier to fix? |
| 01:12:07 | * | SchalaZeal quit (Quit: Konversation terminated!) |
| 01:12:32 | Araq | reactormonk: it's in genRepr(), ecmasgen.nim:1223 |
| 01:13:39 | Araq | dunno how to fix it |
| 01:16:47 | * | SchalaZeal joined #nimrod |
| 01:18:49 | reactormonk | Araq, why is true 1 and false 0 in the JS backend? |
| 01:20:35 | Araq | ugh, bug |
| 01:23:05 | SchalaZeal | Also, I just realised something. If Nimrod may have a Java generator (say for Android apps or something similar) or a C# generator for CLR.... I don't know how Nimrod would handle interfaces. |
| 01:23:40 | reactormonk | SchalaZeal, well, produce jvm bytecode for starters ;-) |
| 01:23:55 | Araq | Nimrod runs on Android, ask gradha when he's around |
| 01:24:05 | SchalaZeal | ah |
| 01:24:20 | reactormonk | Araq, and go through the pull requests once in a while |
| 01:24:44 | SchalaZeal | also I'm trying to port something from Dart, which uses interfaces... so uhm....... yeah I have no idea what to do there |
| 01:25:13 | Araq | again, how is an interface invoked? obj.m(x)? |
| 01:25:40 | SchalaZeal | well see, you could have class Foo extends Bar implements Baz |
| 01:25:44 | Araq | then it's: proc m(obj: A, x: B) {.importcpp.} |
| 01:26:21 | Araq | declare a converter for the type relation |
| 01:27:37 | SchalaZeal | like if........ Listener is implemented by Foo, Bar, Baz, have type Listener = ref TFoo | ref TBar | ref TBaz? |
| 01:28:46 | Araq | converter toListener(x: Foo): Listener = return cast[Listener](x) |
| 01:28:54 | Araq | converter toListener(x: Bar): Listener = return cast[Listener](x) |
| 01:29:01 | Araq | converter toListener(x: Baz): Listener = return cast[Listener](x) |
| 01:29:10 | SchalaZeal | hmm |
| 01:29:11 | Araq | or perhaps: |
| 01:29:24 | Araq | converter toListener(x: Foo | Bar | Baz): Listener = return cast[Listener](x) |
| 01:29:52 | SchalaZeal | I'm wondering why not use a proc/method for that? |
| 01:29:53 | Araq | if the compiler doesn't chew on that |
| 01:30:19 | Araq | because the converter will be called for implicitly to do the type conversion |
| 01:30:26 | SchalaZeal | ah |
| 01:30:43 | Araq | converters only have names for consistency |
| 01:30:55 | Araq | so that you can invoke them explicitly too |
| 01:31:47 | SchalaZeal | I see. So does the type definition for Listener I specified apply or do you mean something different? |
| 01:32:17 | Araq | hrm |
| 01:32:27 | Araq | I would make it a first class type |
| 01:32:37 | Araq | type Listener = ref object |
| 01:33:05 | SchalaZeal | ah ok |
| 01:40:11 | Araq | good night |
| 01:40:18 | SchalaZeal | night |
| 01:42:02 | * | SchalaZeal quit (Quit: Konversation terminated!) |
| 02:16:53 | * | Anaphaxeton joined #nimrod |
| 02:25:35 | * | Anaphaxeton quit (Ping timeout: 255 seconds) |
| 02:26:09 | * | q66 quit (Quit: Quit) |
| 02:28:16 | * | Anaphaxeton joined #nimrod |
| 02:47:43 | * | Anaphaxet0n joined #nimrod |
| 02:47:59 | * | Anaphaxeton quit (Read error: Connection reset by peer) |
| 02:51:37 | * | Anaphaxet0n quit (Client Quit) |
| 03:00:23 | * | Anaphaxeton joined #nimrod |
| 03:02:46 | * | Anaphaxeton quit (Client Quit) |
| 03:11:42 | * | Anaphaxeton joined #nimrod |
| 03:26:02 | * | rking joined #nimrod |
| 03:48:03 | reactormonk | Araq, WTF? stuff is final by default? |
| 04:17:22 | reactormonk | proc foo(x:seq[any]) = echo 1 # crashes the compiler |
| 06:57:59 | shevy | hehe |
| 08:05:39 | * | gour joined #nimrod |
| 09:36:07 | * | gour quit (Quit: WeeChat 0.4.0) |
| 10:04:30 | * | gour joined #nimrod |
| 10:09:37 | * | gour quit (Quit: WeeChat 0.4.0) |
| 10:45:48 | * | fowl quit (Ping timeout: 264 seconds) |
| 11:38:33 | * | q66 joined #nimrod |
| 11:45:21 | * | fowl joined #nimrod |
| 11:47:19 | * | gour joined #nimrod |
| 11:54:08 | * | gour quit (Quit: WeeChat 0.4.0) |
| 12:21:42 | * | gour joined #nimrod |
| 13:24:24 | * | gour quit (Quit: WeeChat 0.4.0) |
| 13:39:38 | dom96 | hello |
| 13:40:15 | * | gour joined #nimrod |
| 13:49:00 | * | gour quit (Quit: WeeChat 0.4.0) |
| 13:53:02 | * | gour joined #nimrod |
| 14:08:48 | gour | reactormonk: ping...i re-build and re-installed nimrod from the scratch and today I get the following: http://pastebin.com/uaBhBrr5 |
| 14:31:08 | * | FreeArtMan joined #nimrod |
| 14:35:28 | Araq | gour: interesting ... |
| 14:35:38 | Araq | so it looks like some heisenbug ... :-/ |
| 14:56:25 | gour | ?? |
| 15:00:56 | * | gour wonders whether Araq consider quantum mechanics or something else |
| 15:11:59 | * | mwcampbell joined #nimrod |
| 15:18:18 | Araq | welcome mwcampbell |
| 15:18:33 | mwcampbell | Hi. I've been here before, though it's been over a year. |
| 15:18:53 | Araq | oh alright |
| 15:19:14 | Araq | well it's still at 0.9.0 :-/ |
| 15:19:38 | mwcampbell | I wasn't going to ask about your release timeline. :) |
| 15:20:06 | Araq | hey, plan is 1.0.0 at the end of this year ... |
| 15:20:10 | mwcampbell | Nimrod always accesses libraries other than libc by loading DLLs or .so's at runtime, right? |
| 15:20:38 | Araq | that's the default implementation for most wrappers, yes |
| 15:21:03 | mwcampbell | So there's an alternative, if I want to, say, statically link libcurl? |
| 15:21:39 | Araq | yeah, but you have to edit libcurl.nim to do that |
| 15:22:01 | mwcampbell | Speaking of libcurl, why do you have both a libcurl wrapper and your own HTTP and FTP clients? |
| 15:22:39 | Araq | libcurl wrapper was first and may be less risky to use ;-) |
| 15:23:12 | mwcampbell | I'll use the pure-Nimrod client if I can, because your dead code elimination is awesome. |
| 15:23:20 | Araq | :D |
| 15:24:07 | Araq | the networking stuff tends to be not as stable as the interface constantly adapts to new language features ;-) |
| 15:24:45 | Araq | for instance, the async stuff now uses closures but may change again to use Nimrod's new first class iterators |
| 15:25:11 | Araq | which provide C#-like await/async features as a side-effect :-) |
| 15:25:28 | mwcampbell | nice |
| 15:27:20 | mwcampbell | Back to an earlier topic, I think it might be a mistake to load shared libraries at runtime by default rather than referencing them at link time. The latter enables more static analysis (e.g. "dumpbin /imports" to see a program's dependencies) |
| 15:27:39 | Araq | I noticed ;-) |
| 15:27:46 | mwcampbell | (dumpbin is a tool from VC) |
| 15:28:19 | Araq | it's nice to not require "devel"-stuff on linux or import libraries |
| 15:30:04 | mwcampbell | Is there any way to use Nimrod with the MSVC toolchain? |
| 15:30:39 | Araq | yeah and zahary uses their debugger for nimrod code |
| 15:30:54 | mwcampbell | Nice. |
| 15:31:10 | Araq | I don't do it, so I can't say how good it works in practice |
| 15:31:15 | mwcampbell | For a project that I'm thinking of doing in Nimrod, one requirement is portability to Windows CE. (yes, old Windows CE) |
| 15:31:25 | gour | hmm |
| 15:31:40 | mwcampbell | I'll take care of any CE-specific issues that come up |
| 15:31:51 | Araq | excellent |
| 15:32:10 | Araq | I don't think we use any advanced features of the win API |
| 15:32:39 | mwcampbell | I already know that the DLL names are all different |
| 15:32:51 | gour | so, nimrod is quite capable to do multi-platform (gui) projects? |
| 15:33:16 | * | FreeArtMan quit (Ping timeout: 246 seconds) |
| 15:33:36 | mwcampbell | gour: Nimrod has bindings for Win32 and GTK. |
| 15:34:11 | * | FreeArtMan joined #nimrod |
| 15:34:32 | gour | mwcampbell: yeah, i'm looking for gtk3, but having qt/wx would be nice as well |
| 15:35:09 | mwcampbell | Qt and wx would be difficult because they're C++ APIs |
| 15:35:31 | * | gour nods |
| 15:36:02 | gour | but, iirc there was some talk to improved |
| 15:36:13 | gour | C++ side of ffi |
| 15:36:19 | gour | *improve |
| 15:36:36 | gour | or maybe i'm wrong |
| 15:36:49 | mwcampbell | Another option would be to do your application back-end in Nimrod and give it a C API, then do the front-end in C++ with whatever toolkit you want. |
| 15:37:08 | mwcampbell | see the cross-calculator example |
| 15:37:33 | Araq | you should really at least consider lazarus for the front-end |
| 15:37:39 | gour | i'd rather stay away from C(++) |
| 15:37:49 | Araq | native UI with UI builder on Mac, Windows and Linux |
| 15:38:14 | mwcampbell | Speaking of Nimrod exporting a C API, what happens if Nimrod functions are called from multiple threads? |
| 15:38:15 | gour | Araq: what would be the place for nimrod then, why not pascal all over? |
| 15:38:26 | mwcampbell | Do I have to call NimMain or some other initialization function in each thread first? |
| 15:39:34 | Araq | you have to call NimMain, yes; I'm not sure it's been tested for multi-threading |
| 15:39:44 | Araq | good point, will look into that |
| 15:41:24 | mwcampbell | Araq: I guess this is off-topic here, but I'm curious about why you like Object Pascal better than C++. In both cases, OO was added on to an ancestral language. |
| 15:41:50 | mwcampbell | Also, how similar is Lazarus to Delphi? |
| 15:42:18 | mwcampbell | I can see some Pascal/Delphi influence in Nimrod. The "T" prefix by convention for user-defined types, for instance. |
| 15:48:15 | Araq | gour: I can't follow, what's the difference between C++ and Pascal for the frontend for that matter? you can also simply use C++ for the whole application then |
| 15:49:44 | gour | Araq: the question is, why not doing whole project in pascal instead of just front-end? |
| 15:50:20 | Araq | gour: why not doing the whole project in C++ instead of just front-end? |
| 15:52:06 | Araq | mwcampbell: the differences between OP and C++ are not small: C++ added OO on top of a weakly typed language |
| 15:53:13 | Araq | the OO additions to pascal feel much less bolted on IMO |
| 15:53:39 | gour | Araq: i simply believe to deserve something better than C(++) in 21st century |
| 15:53:51 | gour | i used C++ in the era of zortech c++ |
| 15:55:10 | Araq | but anyway, Nimrod is not particularly object oriented anyway, so that's not where I put the focus on for a programming language comparison |
| 15:55:58 | gour | but nimrod is modern, type-safe language etc. |
| 15:55:59 | mwcampbell | Now you've got me curious about Object Pascal and Lazarus... |
| 15:56:15 | gour | me too :-) |
| 15:56:44 | Araq | *shrug* I'm not worried :-) |
| 15:57:25 | Araq | I don't use it anymore, I use Nimrod instead |
| 15:57:42 | Araq | maybe you'll come to the same conclusions ;-) |
| 16:00:06 | mwcampbell | I suspect that Nimrod is better for programming in the large simply because it has garbage collection. |
| 16:00:36 | mwcampbell | And the project I mentioned earlier that involves a port to Windows CE may well still be a good fit for Nimrod. |
| 16:00:56 | mwcampbell | But for right now, I've got this very small project to do, that's dominated by the GUI and calls to the Windows API. I may just do that one in Pascal with Lazarus |
| 16:01:03 | mwcampbell | (once I learn the language) |
| 16:06:50 | Araq | Nimrod also has a macro system, a more advanced type system, an effect system and yet kicks python's ass for scripting :P |
| 16:20:12 | q66 | Araq, btw, i finally added macros to my lang |
| 16:24:06 | Araq | q66: well? how powerful have you made them? |
| 16:24:32 | q66 | Araq, for now they can't extend the syntax and they are non-hygienic, but i'll add hygiene eventually |
| 16:24:39 | q66 | they're quite powerful, but simple |
| 16:25:03 | q66 | the basic idea is that macro is like a function that runs at compile time - it takes inputs that are implicitly quoted, and it's supposed to return an AST node |
| 16:25:15 | q66 | so e.g. |
| 16:25:15 | q66 | macro add(a, b) -> quote (unquote a + unquote b) |
| 16:25:23 | q66 | you could write that like |
| 16:25:26 | q66 | macro add(a, b) do |
| 16:25:31 | q66 | return quote (......) |
| 16:25:32 | q66 | end |
| 16:25:50 | q66 | and in that form you can execute different stuff (like node processing) at compile time as well |
| 16:26:02 | Araq | check out how nimrod does it then |
| 16:26:16 | q66 | the expansion syntax is then like |
| 16:26:18 | Araq | I think the split between template and macro is quite nice in nimrod |
| 16:26:21 | q66 | print(add!(5, 10)) |
| 16:26:42 | Araq | because for simple macros ("templates") you don't have to deal with quoting |
| 16:26:56 | q66 | I roughly based mine on this http://elixir-lang.org/getting_started/5.html |
| 16:27:07 | q66 | of course my AST is totally different |
| 16:32:10 | gour | Araq: dmitry (http://www.dmitry-kazakov.de/) active in Ada does not like (read some threads) generics considering them unstable, but not sure whether it is in general or just implementation in Ada...maybe you know about it? |
| 16:34:06 | Araq | well Ada's generics were quite useless for what I liked to do with them back in the days |
| 16:34:27 | Araq | that's all I know about it |
| 16:34:48 | Araq | I recently figured out that GNAT's "unbounded_string" is a bad joke |
| 16:35:14 | gour | ok, that's useful to know |
| 16:35:18 | Araq | in fact, it's one of the worst pieces of code I've ever seen in a standard library |
| 16:36:08 | Araq | it copies the whole string whenever you append a single character |
| 16:36:21 | gour | interesting algorithm |
| 16:37:07 | Araq | and then the compiler likely copies that again into your variable as strings have value semantics in Ada |
| 16:37:39 | Araq | oh it also mallocs the new buffer of course |
| 17:05:21 | gour | Araq: i must say that lazarus/fpc look tempting...thank you for the pointer |
| 17:06:48 | * | fowl quit (Quit: Leaving) |
| 18:10:20 | dom96 | Araq: Talked to the github guy today in person and he said that the linguist stuff should be done in a weeks time. |
| 18:11:53 | Araq | dom96: ok ... |
| 18:17:25 | Araq | I believe that when I see it, sorry dom96 |
| 18:17:48 | dom96 | same :P |
| 18:17:56 | dom96 | just giving you an update ;) |
| 18:26:27 | reactormonk | gour, so it should work by now |
| 18:27:29 | reactormonk | Araq, btw, I buggered around old issues |
| 18:28:38 | Araq | I noticed, reactormonk thanks for that ... |
| 18:28:54 | Araq | I got 20 mails full of noninformation |
| 18:28:59 | Araq | :P |
| 18:29:00 | reactormonk | Araq, lawl |
| 18:29:16 | reactormonk | Araq, disable it then |
| 18:29:22 | Araq | you know ... these bugs may be old |
| 18:29:33 | Araq | but that doesn't mean somebody fixed them in the meantime |
| 18:29:39 | reactormonk | Araq, I checked. |
| 18:30:03 | reactormonk | Araq, those without any comments of mine aren't fixed. |
| 18:30:30 | Araq | what do you mean? |
| 18:30:40 | Araq | they are all not fixed |
| 18:30:45 | reactormonk | Araq, some are |
| 18:30:55 | Araq | not in my opinion |
| 18:31:10 | Araq | often there is some underlying issue that at least I want to look at again |
| 18:31:13 | reactormonk | that's good enough. |
| 18:36:08 | Araq | how come you have the rights to close bugs btw? |
| 18:36:56 | reactormonk | Araq, I don't |
| 18:54:32 | mwcampbell | Araq: You mentioned earlier that one advantage of loading DLLs dynamically at run time is that you don't need import libraries. But on Windows, at least, there's a way to create the import library from the DLL |
| 18:55:00 | Araq | mwcampbell: yeah but this is not reliable |
| 18:55:31 | Araq | afaik you can't really determine the calling convention |
| 19:02:50 | reactormonk | Araq, what is a calling convention exactly? |
| 19:05:56 | reactormonk | Is it as lowlevel as how the arguments go onto the stack? |
| 19:06:25 | Araq | reactormonk: exactly |
| 19:10:19 | gour | reactormonk: should i update nimrod or its mode? |
| 19:11:18 | reactormonk | gour, if it works, nope |
| 19:14:11 | * | shevy quit (Read error: Operation timed out) |
| 19:24:43 | gour | reactormonk: i do not see that it works..."foobar". gives nothing, there is no 'suggestion' buffer etc. |
| 19:27:39 | reactormonk | gour, but the above nimrod idetools works? |
| 19:28:50 | gour | reactormonk: yeah, that was that 'shell command', but withing emacs, nothing |
| 19:29:31 | * | shevy joined #nimrod |
| 19:30:49 | reactormonk | gour, anything in /tmp/nimrod-idetools-stderr ? |
| 19:34:50 | gour | reactormonk: nope, it does not even exist today |
| 19:35:15 | reactormonk | :-( |
| 19:37:48 | reactormonk | gour, grab *scratch*, (debug-on-entry 'nimrod-call-idetools) |
| 19:38:06 | reactormonk | go to EOL, hit C-x C-e |
| 19:38:11 | reactormonk | try again with "foobar". |
| 19:38:41 | reactormonk | gour, or wait, first go to the . and M-x ac-complete-nimrod-completions |
| 19:41:22 | gour | reactormonk: it reports writing some /tmp/nimrod-suggest* file |
| 19:42:02 | reactormonk | gour, couldn't surpress that so far :-/ |
| 19:44:09 | reactormonk | gour, then try the debug stuff |
| 19:44:43 | reactormonk | to undebug, call (cancel-debug-on-entry 'nimrod-call-idetools) (write it to scratch, C-x C-e with the cursor after the ) ) |
| 19:45:49 | gour | ok, debug is off |
| 19:46:03 | reactormonk | it should be on... |
| 19:46:18 | gour | i mean, it's cancelled |
| 19:46:35 | reactormonk | don't do that yet. That's just here for cleaning up. |
| 19:47:11 | gour | ahh, too late...i already executed cancel-xyz statement |
| 19:47:17 | gour | should i activate it again? |
| 19:47:22 | reactormonk | yes. |
| 19:47:57 | reactormonk | then call ac-complete-nimrod-completions somewhere appropriate |
| 19:49:24 | gour | i did on the point of "foobar". |
| 19:49:32 | reactormonk | cool |
| 19:49:36 | reactormonk | does the debugger pop up? |
| 19:49:55 | gour | no |
| 19:50:13 | reactormonk | good |
| 19:50:22 | gour | only report about written file in minibuffer |
| 19:50:58 | reactormonk | ... wtf? |
| 19:51:19 | reactormonk | The only place where I write that file is inside the method nimrod-call-idetools |
| 19:52:14 | reactormonk | the debugger pops up only if I call it via ac-complete* |
| 19:52:26 | gour | something is strange... |
| 19:52:37 | reactormonk | emacs version? |
| 19:52:42 | gour | 24.2.1 |
| 19:52:59 | reactormonk | ... whut |
| 19:55:49 | Araq | reactormonk: Because local > imported. So it isn't ambiguous. And this keeps the naming for both targets the same. |
| 19:55:56 | Araq | good to know |
| 19:56:05 | Araq | I wasn't aware of that rule ... |
| 19:56:10 | Araq | :P |
| 19:56:44 | reactormonk | Araq, ... what? You wrote the freaking compiler |
| 19:57:16 | Araq | exactly |
| 19:57:31 | Araq | I know it has been introduced for templates |
| 19:57:41 | Araq | that it also works for procs is ... hm |
| 19:57:56 | reactormonk | unexpected sideeffect? |
| 19:58:06 | reactormonk | the compiler works in mysterious ways. |
| 19:58:19 | Araq | I guess zahary did it this way for consistency |
| 19:58:29 | Araq | so that we have the same rules for procs and templates |
| 19:59:24 | Araq | in fact, I always wondered if we should consider scopes for overloading resolution |
| 19:59:51 | reactormonk | imo yes. |
| 20:01:42 | reactormonk | zahary, doc for serve? :-) |
| 20:06:11 | mwcampbell | Has anyone developed a web application server framework for Nimrod yet? |
| 20:07:13 | mwcampbell | Not necessarily a full-stack framework like Rails or Django, with ORM, form helpers, etc. Just a way to receive HTTP requests, call a function based on the URL, and send responses. |
| 20:07:32 | reactormonk | Araq, do we have an http server lib? |
| 20:09:28 | Araq | mwcampbell: "Jester" does that |
| 20:09:53 | Araq | though most recent versions of the compiler can't compiler it anymore ;-) I'll fix it once I find the time |
| 20:10:26 | Araq | reactormonk: httpserver is part of the stdlib |
| 20:11:15 | Araq | mwcampbell: we also have a JavaScript backend, you can compile a subset of nimrod to JS |
| 20:11:37 | Araq | meaning that you can at least re-use your input validation stuff on the client |
| 20:15:12 | * | gour wonders if nimrod is going to be web-development framework or push itself as system language :-) |
| 20:15:36 | reactormonk | gour, web? unlikely |
| 20:22:47 | mwcampbell | Can the HTTP server in the standard library only handle one request at a time? |
| 20:34:30 | * | XAMPP quit (Quit: Leaving) |
| 20:40:20 | Araq | mwcampbell: it's not multi-threaded, but it can work in async mode |
| 20:43:45 | reactormonk | mwcampbell, node-style |
| 20:48:31 | mwcampbell | And in async mode it can handle more than one request at a time? |
| 20:48:48 | mwcampbell | I ask because I notice some request-related fields in TServer |
| 20:49:34 | dom96 | hrm, that's a good question. |
| 20:50:21 | mwcampbell | It seems to me that there should be a TRequest type, a new instance of which is created for each request. |
| 20:52:14 | dom96 | Jester can handle multiple simultaneous downloads. |
| 20:52:17 | dom96 | Just tested this. |
| 20:54:54 | mwcampbell | What's the URL for Jester? |
| 20:55:06 | dom96 | From the implementation of httpserver it seems that it currently does not support multiple simultaneous requests. |
| 20:55:14 | dom96 | Jester can use the httpserver module or the scgi module. |
| 20:55:24 | dom96 | https://github.com/dom96/jester |
| 20:55:52 | mwcampbell | I think I like SCGI better anyway |
| 20:56:00 | Araq | it's not important anyway, is it? you should use something like nginx |
| 20:56:22 | * | gour runs hiawatha happily |
| 20:56:37 | Araq | otherwise you need to re-implement its efficient handling of static pages, load balancing, logging, etc. |
| 20:56:48 | dom96 | indeed. |
| 20:57:05 | dom96 | httpserver is absolutely fine for testing. |
| 20:57:45 | Araq | mwcampbell: http://forum.nimrod-code.org/ is built on Jester |
| 20:57:47 | dom96 | We can always improve it, but it's not that important. I doubt it will ever be as good as nginx. |
| 20:58:08 | dom96 | and build.nimrod-code.org :) |
| 20:58:25 | reactormonk | gour, oh, I got to strip away the "" |
| 21:03:50 | gour | np |
| 21:05:40 | reactormonk | seems to be something else... whatever. |
| 21:06:23 | * | gour quit (Quit: WeeChat 0.4.0) |
| 21:10:18 | reactormonk | Araq, should I separate the kwin and the other commits? |
| 21:10:50 | Araq | I don't care much if every commit is acceptable :P |
| 21:10:57 | reactormonk | well, are they? |
| 21:11:25 | Araq | did you change the makeJSString stuff? |
| 21:12:06 | reactormonk | nope. What should it be? |
| 21:12:14 | Araq | I told you |
| 21:13:15 | * | gour joined #nimrod |
| 21:13:21 | reactormonk | Never heard of reusability? |
| 21:13:56 | Araq | what's that to do with it? |
| 21:13:57 | reactormonk | I can add an {.inline.} if that helps |
| 21:14:04 | Araq | what are you talking about? |
| 21:15:41 | reactormonk | well, it's 3 code points I'd sed into there, not just good old strutils.escape |
| 21:16:21 | Araq | I told you to make a proc makeJSString(s: string): PRope and use that in ecmasgen.nim |
| 21:16:43 | Araq | aka rename makeCString to makeJSString |
| 21:17:00 | reactormonk | oh, meh. Didn't read carefully enough. Sorry |
| 21:17:08 | Araq | np |
| 21:18:23 | reactormonk | sure I shouldn't call it makeECMAString? ^^ |
| 21:20:34 | * | FreeArtMan quit (Ping timeout: 244 seconds) |
| 21:20:43 | Araq | nah, I'm about rename all this ecma crap |
| 21:20:56 | Araq | everybody calls it javascript |
| 21:21:19 | Araq | in fact, I'll happily accept a pull request that renames it |
| 21:22:47 | reactormonk | there we go. |
| 21:27:05 | * | gour quit (Quit: WeeChat 0.4.0) |
| 21:38:13 | * | XAMPP joined #nimrod |
| 21:38:13 | * | XAMPP quit (Changing host) |
| 21:38:13 | * | XAMPP joined #nimrod |
| 21:40:17 | * | XAMPP quit (Read error: Connection reset by peer) |
| 21:42:12 | reactormonk | Araq, oh well, force pushing killed your comment |
| 21:42:55 | mwcampbell | I was looking at the captcha module in nimforum, and I noticed that the Cairo objects are explicitly destroyed at the end of createCaptcha. Is there not a way to let the garbage collector clean them up? |
| 21:44:23 | Araq | mwcampbell: there is |
| 21:44:32 | Araq | we have both finalizers and destructors |
| 21:44:47 | Araq | however C bindings use neither |
| 21:45:06 | Araq | however, destructors are still not completely implemented |
| 21:45:23 | Araq | and finalizers require you to wrap the object in a GC'ed object |
| 21:46:57 | * | gour joined #nimrod |
| 21:47:43 | gour | reactormonk: does 0.14. solve the problem? |
| 21:48:24 | gour | .profile does not work here...besides, i use zsh, but found the following (if 0.1.4 is not solution) - https://github.com/purcell/exec-path-from-shell |
| 22:02:59 | gour | now it works with exec-path-from-shell package |
| 22:08:38 | reactormonk | gour, just customize nimrod-command |
| 22:09:23 | gour | reactormonk: ok, but the question remain how to use it without invoking ac-complete-* ? |
| 22:10:07 | reactormonk | gour, oh, good old tab. auto-complete should do that with the settings I used |
| 22:11:03 | gour | reactormonk: where to set those things? i've seemingly everything installed and the dialog pops-up when invoked manually' |
| 22:11:14 | reactormonk | gour, let me look it up |
| 22:18:37 | reactormonk | gour, what is 'Ac Trigger Key'? |
| 22:18:41 | reactormonk | ... in customize |
| 22:22:10 | gour | oops...its' nil |
| 22:23:31 | reactormonk | new version published |
| 22:23:42 | reactormonk | ... which sets the trigger key to tAB |
| 22:23:53 | reactormonk | gour, no oops, my fault to not see it. |
| 22:24:29 | reactormonk | can't help any further with the nimrod-command except to tell you to customize it :-( |
| 22:25:37 | gour | reactormonk: how one defines tab? as TAB? |
| 22:26:06 | reactormonk | gour, package-list-packages => update |
| 22:28:24 | gour | cool, now it works |
| 22:28:29 | reactormonk | \o/ |
| 22:28:50 | reactormonk | next stage is to use the signature somehow |
| 22:29:03 | reactormonk | Araq, pull pull pull >:) |
| 22:29:16 | gour | heh...now i'm just sad why Araq told me about lazarus :-/ |
| 22:30:29 | reactormonk | ^^ |
| 22:33:58 | Araq | gour: why? |
| 22:34:30 | gour | Araq: 'cause it looks good and reactormonk just helped me to make nimrod-mode working |
| 22:35:35 | NimBot | Araq/Nimrod f7f8230 Simon Hafner [+0 ±1 -0]: rawEcho hack for kwin target |
| 22:35:35 | NimBot | Araq/Nimrod 029b654 Simon Hafner [+0 ±1 -0]: fix for exit code of compiler (JS bug?) |
| 22:35:35 | NimBot | Araq/Nimrod bddbfde Simon Hafner [+0 ±1 -0]: hack for long string literals in C bugs in JS. Fixed. |
| 22:35:35 | NimBot | Araq/Nimrod c8ae632 Araq [+0 ±3 -0]: Merge pull request #327 from Tass/master... 3 more lines |
| 22:36:41 | Araq | gour: I told you about it months ago |
| 22:37:08 | Araq | I'm sure you'll forget about it soon and will return |
| 22:37:12 | gour | yes, but then I could not hear |
| 22:37:47 | gour | really? it can produce native-looking guis for every platform |
| 22:38:00 | gour | which looks better than e.g. having gtk on mac |
| 22:38:41 | reactormonk | gour, tk tile should be good too |
| 22:39:23 | Araq | gour: you cannot use FPC/Lazarus anyway because it is not Ada :P |
| 22:40:46 | gour | reactormonk: well, i've heard that new(er) Tk looks much better using native look, but have to see something |
| 22:41:14 | gour | Araq: i'm not so attached to Ada as i was to haskell/D...so, everything is possible ;) |
| 22:53:42 | gour | i forgot most of the pascal and not familiar with fpc's extensions, but i'm sure there is no question that nimrod is much better designed as a whole...however, the question is whether writing multi-platform gui apps is niche which it wants to cover or is more suitable for other tasks (like gaming, as system language etc.) |
| 23:18:52 | Araq | gour: the real question IMO is what kind of widgets you need |
| 23:19:25 | Araq | for instance I really prefer GTK's source editor over Lazarus's |
| 23:20:19 | Araq | and if you don't need any advanced widgets IUP could be an alternative too |
| 23:20:35 | gour | IUP? |
| 23:20:55 | gour | i believe that gtk+ would be good-enough |
| 23:21:05 | Araq | http://www.tecgraf.puc-rio.br/iup/ |
| 23:22:32 | gour | not sure if it's not simple enough...there is also question about the support |
| 23:24:06 | gour | doesn't lazarus use gtk (on linux)? |
| 23:24:13 | Araq | it does |
| 23:24:42 | Araq | and can also use QT but I don't know how stable the QT backend is |
| 23:25:05 | gour | the work is done for cocoa as well |
| 23:25:36 | Araq | true; iup should get a cocoa backend too |
| 23:25:53 | Araq | but apparently they removed that goal |
| 23:26:05 | Araq | too much work I guess |
| 23:26:24 | gour | but there are anyway no iup bindings for nimrod, right? |
| 23:26:37 | Araq | there are :P |
| 23:26:42 | gour | ohh |
| 23:27:03 | gour | what about gtk3? soon? |
| 23:27:14 | Araq | ask dom96 |
| 23:27:38 | gour | ahh, right, he is IDE guy |
| 23:27:47 | dom96 | hah |
| 23:28:02 | dom96 | According to Araq I'm the sockets guy :P |
| 23:28:08 | Araq | gour: http://www.tecgraf.puc-rio.br/iup/en/toolkits.html |
| 23:28:23 | dom96 | As for gtk3, in my opinion it's not worth supporting yet. |
| 23:29:08 | dom96 | A nicer gtk2 wrapper is planned, perhaps I will create a gtk3 wrapper at the same time. |
| 23:29:25 | gour | hhm team - 2, last update - 2011/04...it's not very thrilling |
| 23:30:30 | Araq | that's not up to date |
| 23:30:31 | gour | dom96: gtk bindings are mostly wrapper over C API or there is some type-security which nimrod can provide? |
| 23:31:08 | Araq | nimrod almost always improves type safety at least a bit |
| 23:31:16 | Araq | as the language is stricter than C |
| 23:31:25 | dom96 | yes, but I want to add some extra safety to the gtk wrappers |
| 23:31:37 | gour | what about memory management? |
| 23:31:40 | dom96 | as well as perhaps closure support for the signals |
| 23:32:02 | Araq | memory management is as bad as in C for the gtk wrapper |
| 23:32:15 | gour | hmm |
| 23:32:50 | Araq | but it's not that bad for GTK, is it? |
| 23:33:28 | Araq | stuff ends up being owned by the window and released once the window is closed |
| 23:33:39 | Araq | (I think) |
| 23:34:22 | dom96 | GTK has its own reference counting mechanism. |
| 23:37:43 | * | mwcampbell quit (Quit: Leaving) |
| 23:38:24 | * | gour --> sleep |
| 23:39:09 | gour | tomorrow i plan to do some 'divination' to discern what is the status of language candidates, including nimrod... |
| 23:39:12 | gour | 'night |
| 23:39:17 | * | gour quit (Quit: WeeChat 0.4.0) |
| 23:51:39 | * | mwcampbell joined #nimrod |