| 00:14:02 | * | Varriount gives a cookie to renesac |
| 00:14:24 | * | Demos should really learn a "scripting" language |
| 00:15:08 | renesac | *chomp* *chomp* humm |
| 00:15:15 | renesac | thanks for the cookie |
| 00:15:59 | renesac | but I still haven't understood this template thing very well to make a PR for the docs |
| 00:16:25 | renesac | it seems that the last expression in a template definition is the return value, if the return isn't a stmt? |
| 00:16:49 | EXetoC | Demos: learn nimrod then, in a couple of months :> |
| 00:16:58 | Demos | hehe |
| 00:17:40 | renesac | nimrod seems pretty able to do some scripting tasks |
| 00:17:51 | EXetoC | create a json bridge! |
| 00:18:09 | renesac | if only it had python's or perl's wealthy of modules |
| 00:19:24 | renesac | fowl, you made some python bindings, but the examples shows only an "eval" thing |
| 00:20:22 | renesac | how hard would it be to really import and use python modules, if I don't care about the overhead of a python interpreter and constant conversions to and from PyObject? |
| 00:21:40 | EXetoC | without touching the API? :p |
| 00:21:42 | fowl | i didnt make those bindings |
| 00:22:13 | renesac | oh, then who made this: https://github.com/nimrod-code/python |
| 00:22:13 | renesac | ? |
| 00:22:18 | Demos | well one of the goals of learning a scripting language would be to do really quick algos with no reguard to data structures or speed |
| 00:22:37 | fowl | renesac, says (c) 2010 araq |
| 00:22:49 | renesac | oh, indeed |
| 00:23:28 | EXetoC | I don't think there's a big difference when you have type inference and all |
| 00:23:33 | fowl | renesac, my guess is its not hard, python is a scripting language, this use is the real intended use for the language |
| 00:24:51 | renesac | could I just "pyimport: sqlalchemy" on top of my nimrod module, or this is also a pipe dream? |
| 00:24:59 | renesac | XD |
| 00:27:11 | EXetoC | in need of a weekend project? implement that and "nimrod py"! |
| 00:28:38 | renesac | all weekends for the rest of the year? |
| 00:29:13 | EXetoC | I was thinking maybe one or two. is that too optimistic? |
| 00:29:21 | renesac | I have no idea |
| 00:29:53 | renesac | that was what I was asking for |
| 00:30:07 | renesac | if such a thing is even possible |
| 00:30:57 | Demos | I am bisecting that wierd winlean error |
| 00:33:16 | Demos | there are a lifetime of weekend projects to do for nimrod |
| 00:34:56 | EXetoC | rly |
| 00:35:06 | renesac | of course |
| 00:35:30 | renesac | I'm doing that benchmark module now, anyway |
| 00:43:18 | * | ddl_smurf quit (Quit: ddl_smurf) |
| 00:43:28 | renesac | I was actually interested in using python's scientific libraries with nimrod |
| 00:44:13 | renesac | so the performance would actually be a point (otherwise, I should just use python) |
| 00:44:46 | renesac | use nimrod as a better cython, like Araq was saying the other day (not in those words) |
| 00:44:46 | Demos | well if you are using python from nimrod it will be as slow or slower than python without nimrod |
| 00:45:06 | renesac | not necessarily |
| 00:45:19 | renesac | if I'm using numpy arrays, many operations can be done in nimrod |
| 00:45:34 | renesac | and then I call some stat function or plotting from python at the end |
| 00:45:36 | renesac | for example |
| 00:45:52 | renesac | like you would do using cython to speedup part of your python code |
| 00:46:59 | renesac | this topic covers it (I don't know what happened after this with julia): https://groups.google.com/forum/#!msg/julia-dev/YftOOEfcwrk/7q3cm2y3Xs4J |
| 00:47:49 | Demos | it is strange that compileing python yields such a speed boost |
| 00:48:07 | renesac | for every integer addition in python |
| 00:48:23 | renesac | the compiler must look at the boxed type, do many checks, etc |
| 00:48:28 | renesac | and then make the operation |
| 00:49:34 | Demos | well nothing is stoping it from just doing the operation! |
| 00:49:56 | Demos | although, I suppose.... |
| 00:50:17 | renesac | *the interpreter |
| 00:50:27 | Demos | well cython must be a different language than python. Only a subset of python works right? |
| 00:50:44 | renesac | actually, most of it works |
| 00:50:54 | renesac | it is more like a superset, with type definitions, etc |
| 00:51:04 | Demos | very strange |
| 00:51:08 | Demos | I should learn python |
| 00:51:08 | renesac | but if you just compile unmodified python code you don't get much boost |
| 00:51:11 | Demos | or more perl |
| 00:51:19 | Demos | oh, OK I can sleep easy now |
| 00:51:20 | renesac | perl is dying |
| 00:51:26 | Demos | perl is funny |
| 00:52:13 | renesac | it sure is funny: http://stackoverflow.com/questions/11695110/why-is-this-program-valid-i-was-trying-to-create-a-syntax-error |
| 00:52:17 | renesac | XD |
| 00:53:50 | EXetoC | :E |
| 01:00:35 | Demos | Varriount! |
| 01:01:15 | Demos | never mind |
| 01:57:49 | * | xenagi joined #nimrod |
| 01:59:16 | * | DAddYE quit (Remote host closed the connection) |
| 01:59:50 | * | DAddYE joined #nimrod |
| 02:00:49 | * | DAddYE_ joined #nimrod |
| 02:04:25 | * | DAddYE quit (Ping timeout: 250 seconds) |
| 02:05:11 | * | DAddYE_ quit (Ping timeout: 245 seconds) |
| 02:22:24 | Demos | hm maybe we should have the compiler always pick library files if you have a file of the same name in your tree. Or even better warn... I should look into that |
| 02:26:31 | * | BitPuffi1 quit (Ping timeout: 272 seconds) |
| 02:44:05 | * | DAddYE joined #nimrod |
| 02:51:53 | brson | when's the next nimrod release? |
| 03:19:58 | Demos | when it's done |
| 03:49:21 | * | Demos quit (Read error: Connection reset by peer) |
| 03:55:52 | * | BitPuffi1 joined #nimrod |
| 04:01:18 | * | xenagi quit (Read error: Connection reset by peer) |
| 04:05:25 | * | brson quit (Quit: leaving) |
| 04:05:51 | * | Demos joined #nimrod |
| 04:43:25 | * | CarpNet quit (Ping timeout: 272 seconds) |
| 04:53:54 | * | noam joined #nimrod |
| 04:56:43 | * | CarpNet joined #nimrod |
| 05:07:53 | Demos | is https://gist.github.com/e9c41f65f3f677b20b77 valid code? |
| 05:24:29 | * | CarpNet quit (Ping timeout: 272 seconds) |
| 05:31:14 | * | xtagon quit (Ping timeout: 246 seconds) |
| 05:35:46 | * | Demos quit (Quit: ERC Version 5.3 (IRC client for Emacs)) |
| 06:23:00 | * | dmac joined #nimrod |
| 06:44:21 | * | CarpNet joined #nimrod |
| 07:03:17 | * | CarpNet quit (Ping timeout: 272 seconds) |
| 07:21:10 | * | CarpNet joined #nimrod |
| 07:56:01 | * | BitPuffi1 quit (Ping timeout: 245 seconds) |
| 08:02:38 | * | BitPuffi1 joined #nimrod |
| 09:17:54 | * | ddl_smurf joined #nimrod |
| 09:23:46 | * | DAddYE quit (Remote host closed the connection) |
| 09:59:46 | * | BitPuffi1 quit (Ping timeout: 245 seconds) |
| 10:20:36 | * | BitPuffi1 joined #nimrod |
| 10:29:15 | * | dmac quit (Ping timeout: 250 seconds) |
| 10:49:44 | * | BitPuffi1 quit (Quit: WeeChat 0.4.2) |
| 10:49:59 | * | BitPuffin joined #nimrod |
| 11:46:09 | * | io2 joined #nimrod |
| 12:09:50 | * | io2 quit (Ping timeout: 264 seconds) |
| 12:52:12 | * | io2 joined #nimrod |
| 13:28:28 | * | [1]Endy joined #nimrod |
| 14:11:53 | * | [2]Endy joined #nimrod |
| 14:15:05 | * | [1]Endy quit (Ping timeout: 265 seconds) |
| 14:40:26 | * | darkf quit (Quit: Leaving) |
| 15:07:55 | * | Mordecai joined #nimrod |
| 15:09:40 | * | Demos joined #nimrod |
| 15:09:41 | * | psquid quit (Ping timeout: 272 seconds) |
| 15:33:24 | * | Demos quit (Ping timeout: 245 seconds) |
| 15:59:29 | * | noam quit (Ping timeout: 246 seconds) |
| 16:28:17 | Discoloda | is there a place on freenode i can ask some source liscensing questions? |
| 17:15:14 | * | DAddYE joined #nimrod |
| 17:24:35 | * | BitPuffin quit (Ping timeout: 272 seconds) |
| 17:34:24 | * | BitPuffin joined #nimrod |
| 18:01:53 | * | BitPuffin quit (Ping timeout: 260 seconds) |
| 18:15:47 | * | DAddYE quit (Remote host closed the connection) |
| 18:16:21 | * | DAddYE joined #nimrod |
| 18:21:14 | * | DAddYE quit (Ping timeout: 265 seconds) |
| 18:32:08 | Varriount | Meep. Good morning! |
| 18:34:15 | Varriount | Araq: So, any particular reason we can't easily have arrays whose size is determined at run-time (I mean, we can, with alloc and such, but why can't we do it without alloc?) |
| 18:37:34 | io2 | the fact that nimrod made the cover of dr dobbs is pure awesomeness |
| 18:38:07 | * | Varriount is trying to optimize his cartesian product iterator |
| 18:43:53 | dom96 | Varriount: I think it's because you can't allocate on the stack at runtime. |
| 18:45:44 | * | DAddYE joined #nimrod |
| 18:47:29 | renesac | dom96, you can with alloca? |
| 18:47:46 | Varriount | Or unsafeNew |
| 18:48:08 | renesac | the problem is stack overflow |
| 18:48:25 | EXetoC | Varriount: on the stack? |
| 18:48:30 | * | Demos joined #nimrod |
| 18:48:50 | EXetoC | you get a ref |
| 18:49:21 | EXetoC | Demos: hi. similar functions are annotated with {.compileTime.}. have you tried that? |
| 18:50:07 | dom96 | renesac: oh, interesting. |
| 18:50:40 | dom96 | Varriount: Doesn't that allocate on the heap? |
| 18:51:55 | Araq | Varriount: what's wrong with using a sequence? |
| 18:52:38 | EXetoC | slower than incrementing the stack pointer? |
| 18:53:03 | Araq | *shrug* so wrap and use alloca ... |
| 18:53:27 | Araq | or wait until the compiler gets smarter and performs an escape analysis |
| 18:54:27 | * | BitPuffin joined #nimrod |
| 18:55:43 | Araq | I prefer the latter |
| 18:57:07 | renesac | hum, alloca also prevents function inlining |
| 18:58:22 | renesac | well, it sholdn't... if the stack can be rolled back while inside a function.... |
| 18:59:03 | renesac | I'm not sure if that is possible though... |
| 18:59:55 | Araq | I still think the root cause is the decade old conflation of the control flow stack with the data stack |
| 19:00:25 | reactormonk | dom96, btw, how should babel handle dependencies? Not at all? |
| 19:00:46 | dom96 | reactormonk: No, it should handle them. And it does. |
| 19:00:57 | Araq | the only question is what abstraction models the 2 different stacks appropriately |
| 19:01:07 | reactormonk | dom96, cool. Haven't seen any dependency specs in packages.json yet, that's why I'ma sking |
| 19:01:13 | * | Demos quit (Ping timeout: 252 seconds) |
| 19:01:26 | dom96 | reactormonk: It's specified in the .babel files. |
| 19:01:38 | reactormonk | dom96, oh. kk. |
| 19:01:54 | Araq | or maybe there is no abstraction for that and you basically have to use assembler |
| 19:02:08 | reactormonk | dom96, what do you do if two different libs depend on lib A of two different versions? |
| 19:02:39 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/867 is just a symptom of that? |
| 19:02:42 | EXetoC | it tries to install both |
| 19:02:57 | renesac | Araq, with two stacks and a heap, you can't have them just growing towards each other at oposite directions |
| 19:02:58 | EXetoC | I mean, whichever is needed for said package |
| 19:03:09 | dom96 | yes, both are installed. |
| 19:03:27 | renesac | but with huge address spaces from 64 bit this shouldn't be a problem... |
| 19:04:05 | Araq | renesac: the control flow stack can easily be fixed size since only return addresses are stored in there |
| 19:05:19 | reactormonk | Araq, can you use return in a macro? |
| 19:05:42 | reactormonk | dom96, how does the nimrod namespace handle the load there? |
| 19:05:47 | Araq | reactormonk: yes |
| 19:06:18 | reactormonk | Araq, http://nimrod-lang.org/tut2.html#statement-macros does that work as intended? |
| 19:06:22 | dom96 | reactormonk: You have to build using babel. Babel then passes the paths explicitly to the compiler. |
| 19:06:28 | renesac | Araq, in a template that returns a value, the value of the last statement is returned? |
| 19:06:48 | reactormonk | dom96, for each library in specific? |
| 19:07:07 | reactormonk | ... sounds plausible. Cool. |
| 19:07:08 | Araq | renesac: that's one way to look at it, but it's slightly wrong :P |
| 19:08:03 | dom96 | reactormonk: No. For each binary package. |
| 19:08:33 | reactormonk | dom96, what's the difference between binary package and library? |
| 19:09:04 | dom96 | Libraries are meant to be imported, binary packages are meant to be compiled. |
| 19:09:16 | renesac | Araq, you should write that documentation then... |
| 19:10:06 | Araq | you write it, i correct it |
| 19:10:23 | reactormonk | dom96, so in case of [D [C [A_1]] [B [A_2]]], how do you build it? |
| 19:11:47 | dom96 | reactormonk: nimrod c --path:~/.babel/pkgs/C-ver --path:~/.babel/pkgs/A_1-ver --path:~/.babel/pkgs/B-ver --path:~/.babel/pkgs/A_2-ver d.nim |
| 19:12:45 | renesac | ok... I will try latter |
| 19:12:54 | * | renesac is now known as renesac|away |
| 19:17:38 | * | io2 quit (Ping timeout: 264 seconds) |
| 19:19:06 | reactormonk | dom96, so how will the import in B work to pick up A_2? |
| 19:19:31 | dom96 | import A_2/module |
| 19:20:11 | reactormonk | they're both called A/module, but have two different versions. |
| 19:20:12 | * | brson joined #nimrod |
| 19:20:20 | reactormonk | aka `import A` |
| 19:22:38 | dom96 | Ahh, that's not allowed. |
| 19:22:40 | Araq | reactormonk: we have discussed this problem to death already and it's academic until it comes up in practice |
| 19:23:09 | Araq | especially as long as we have ~50 packages in babel |
| 19:23:48 | dom96 | AFAIK there are no easy solutions to this problem. |
| 19:24:17 | dom96 | Might be interesting to see what the ruby/python/perl/node.js package managers do in this situation. |
| 19:25:48 | reactormonk | dom96, ruby bails. |
| 19:26:00 | reactormonk | Araq, kk, I'll take your word for it. |
| 19:26:21 | dom96 | reactormonk: Really? Does it just give an error? |
| 19:26:30 | Araq | reactormonk: bailing is exactly the wrong solution IME |
| 19:26:46 | Araq | I download myself and try it instead |
| 19:26:54 | reactormonk | dom96, yup |
| 19:26:56 | dom96 | I now wonder what you mean by "bails" |
| 19:27:05 | reactormonk | well, bundle that is. |
| 19:27:09 | Araq | chances are high it works anyway and the version spec was wrong |
| 19:27:26 | reactormonk | for rubygems, it just installs both and includes both and hopes it works |
| 19:27:28 | Araq | ok, in ruby's case chances are high that it doesn't work either way ... |
| 19:27:37 | reactormonk | or actually, the version specified first winds. |
| 19:27:39 | reactormonk | *wins |
| 19:28:01 | dom96 | Perhaps we should do that. |
| 19:28:06 | reactormonk | with bundle, you get an error. Just because ruby has global namespace and it's not possible to separate by version. |
| 19:28:24 | dom96 | Maybe i'll just make it a warning. |
| 19:28:26 | reactormonk | nimrod has file-local namespace, so with some quirky magic, it should be possible. |
| 19:28:40 | reactormonk | dom96, make it error out for now. |
| 19:28:55 | dom96 | That's what it does. |
| 19:29:01 | reactormonk | or a warning when it's just minor versions |
| 19:29:10 | Araq | add some --force flag |
| 19:29:52 | Araq | we have static typing, installing and hoping for the best has a chance of either working or producing a compiler error |
| 19:31:20 | reactormonk | which doesn't annotate functionality, but yup |
| 19:31:37 | reactormonk | it should be possible to bend around the include paths per file, somehow |
| 19:31:59 | reactormonk | but then the compiler has to be babel-aware etc. |
| 19:32:03 | dom96 | indeed. |
| 19:32:06 | dom96 | I suggested that initially. |
| 19:32:13 | dom96 | But it would require serious compiler patches. |
| 19:32:36 | reactormonk | Araq, https://github.com/Araq/Nimrod/pull/849 <- could you take a look at that? |
| 19:33:10 | Araq | reactormonk: don't pull, I think I fixed it properly |
| 19:34:07 | reactormonk | Araq, then write back |
| 19:37:28 | reactormonk | btw, when will you purge the nimrod repo from build/csources*, if at all? |
| 19:47:01 | Varriount | dom96: You could use symlinks to *dump* the appropriate packages into the roots packages directory |
| 19:47:53 | dom96 | That would end up conflicting because the two versions have the same names. |
| 19:47:56 | Varriount | Sorta like what I do to easily edit and build 1 source tree for both 32 and 64 bit |
| 19:48:14 | Varriount | dom96: Not if the versions are specified in the babel file |
| 19:48:34 | Varriount | If the babel file specifies the dependancies and their versions |
| 19:48:44 | Araq | symlinks are evil |
| 19:48:54 | Varriount | ^ A conveniant evil |
| 19:49:19 | dom96 | oh, I think I just got what you mean. |
| 19:49:24 | Varriount | They let me easily build 32 and 64 bit versions of the builder, and of nimrod |
| 19:49:39 | Varriount | Without having to keep 2 separate source trees. |
| 19:50:05 | dom96 | I wonder if the compiler could deal with those. |
| 19:50:33 | Varriount | dom96: It should. It already does (The compiler largely ignores symlinks,and just treats them as what they point to |
| 19:51:05 | dom96 | That would work but I don't think symlinks are well supported on Windows, are they? |
| 19:51:15 | Varriount | They are, actually |
| 19:51:38 | Varriount | The only.. inconsistancy is that on windows, symlnk creation is restricted to admins |
| 19:51:54 | Varriount | And in that case, you could just copy the package directories instead |
| 19:51:58 | dom96 | Yeah, that's a problem. |
| 19:52:36 | Varriount | dom96: Not if you copy. |
| 19:53:39 | dom96 | Not sure if that's a good idea... |
| 19:53:44 | Varriount | Why not? |
| 19:54:52 | Araq | dom96: the zeta-OS-09 doesn't support symlinks, so that is not a portable solution |
| 20:05:52 | Araq | zielmicha-cloud_: just a friendly reminder: we want your vfork patch |
| 20:06:10 | Varriount | What's a v-fork? |
| 20:06:30 | * | io2 joined #nimrod |
| 20:07:42 | reactormonk | Araq, zeta-OS is dead |
| 20:07:49 | reactormonk | ... some random internet source |
| 20:08:53 | Varriount | dom96: Currently, how does babel make sure that a package with a dependancy on a specific version of another package, get's built with that other package? |
| 20:09:12 | reactormonk | Araq, and haiku supports symlinks. |
| 20:14:20 | * | xtagon joined #nimrod |
| 20:42:51 | Araq | Varriount: requiring a specific version itself is a bug |
| 20:43:26 | Araq | you can't reasonably require that, you might as well embed that package then into your code base |
| 20:45:09 | Araq | reactormonk: FAT doesn't support symlinks |
| 20:56:05 | * | bstrie_ is now known as bstrie |
| 20:59:05 | * | [2]Endy quit (Ping timeout: 246 seconds) |
| 21:09:24 | * | Mat3 joined #nimrod |
| 21:09:27 | Mat3 | hi all |
| 21:11:30 | Araq | hi Mat3 |
| 21:13:01 | Mat3 | hi Araq. And finally here it is, the ultimatly 6502 based 64 bit design: https://github.com/fachat/af65k |
| 21:15:56 | Mat3 | (the author states: "timing is horrible. Currently ISE says it runs with less than 14MHz" - for me not suprising for accumulator-store design with Z80 like opcode prefixes) |
| 21:16:43 | Araq | meh that other link was way more impressive |
| 21:17:02 | Araq | the new general purpose cpu with a call instruction that takes 1 cycle |
| 21:17:16 | Araq | and the splitted instruction stream |
| 21:17:27 | Araq | I want that CPU already :-) |
| 21:17:36 | Mat3 | yes, very inspiring |
| 21:22:06 | Mat3 | anyhow; I think these english company with its 4096 core processor is also very attractive. Sadly there seem not to sell single CPU's |
| 21:29:28 | Varriount | Araq: Requiring a specific version prevents breakage |
| 21:29:38 | * | io2 quit (Ping timeout: 264 seconds) |
| 21:29:46 | Varriount | Or otherwise developers could never make breaking changes to their libraries |
| 21:30:36 | Araq | ok, if you mean something like 2.x to allow for bugfixes, I agree |
| 21:31:08 | Araq | if you mean *exactly* version 2.4 then I argue that's broken |
| 21:31:37 | Varriount | Araq: Depends on what versioning system is used. |
| 21:42:57 | * | Mordecai quit (Ping timeout: 252 seconds) |
| 21:52:36 | Mat3 | is the Dr. Dobbs article about nimrod published now ? |
| 21:56:30 | Araq | no |
| 21:56:38 | Araq | 11th of february is release |
| 21:56:50 | Mat3 | thanks, good to know |
| 21:59:05 | * | Mordecai joined #nimrod |
| 21:59:09 | * | Mordecai quit (Changing host) |
| 21:59:09 | * | Mordecai joined #nimrod |
| 22:01:51 | Mat3 | need some sleep, ciao |
| 22:02:02 | * | Mat3 quit (Quit: Verlassend) |
| 23:11:22 | * | filwit joined #nimrod |
| 23:30:19 | Araq | hi filwit |
| 23:30:35 | filwit | Araq: I got the VM to work with my macros now by a) removing the unused check at vmgen:1319, b) removing the assert at vm:~425, and c) changing the assert at vm:82 to the following: |
| 23:30:38 | NimBot | Araq/Nimrod devel 3ff11d2 Araq [+1 ±3 -0]: bugfix: immediate templates are preferred consistently (danger: breaks code) |
| 23:30:38 | NimBot | Araq/Nimrod devel 2b8d7a8 Araq [+1 ±16 -0]: tyTypeDesc and tyRange always have 1 child; this might be tyNone but it is required for skipTypes |
| 23:30:38 | NimBot | Araq/Nimrod devel efcdadf Araq [+0 ±3 -0]: case consistency for -d:useWinAnsi |
| 23:30:38 | NimBot | Araq/Nimrod devel 45379a6 Araq [+0 ±10 -0]: stdlib compiles mostly without warnings again |
| 23:30:38 | NimBot | 1 more commits. |
| 23:30:42 | filwit | case n.kind: |
| 23:30:50 | filwit | of mkMetaNode: return n.sons[0] |
| 23:30:58 | filwit | of mkStmtList: return n |
| 23:31:04 | filwit | else: # fail... |
| 23:31:06 | Araq | we have skipMeta for that |
| 23:31:20 | Araq | and your fix is wrong, sorry |
| 23:31:27 | filwit | i figured |
| 23:31:44 | filwit | i was just letting you know how it got it to work, still not sure exactly what is going on |
| 23:32:28 | filwit | i'm guessing i'm just adding a safe-guard to a lower-level part of the processing stack instead of fixing the node-tree appropriately early on |
| 23:33:05 | Araq | I still have 4 major building lots ... |
| 23:33:16 | filwit | building lots? |
| 23:33:23 | Araq | Vm, closure bugs, gc bugs and exception handling bugs |
| 23:33:53 | Araq | and all of them have a bus factor of 2 ... |
| 23:33:53 | filwit | ah, well i'm not really asking you to look at my bug right now. just wanted to share in case you had any insight |
| 23:34:16 | Araq | well the good news is I know how to fix my vm |
| 23:34:29 | filwit | that is good news, lol :) |
| 23:35:00 | filwit | or are you talking about doing some major architecture change? |
| 23:35:27 | Araq | nah, I'm patching into hell |
| 23:38:40 | filwit | how are you going to be changing the structure tho? |
| 23:39:41 | Araq | producing nkRefTy wrappers properly |
| 23:40:23 | Araq | oh filwit I think I fixed your bug properly |
| 23:40:28 | Araq | the one you made a PR for |
| 23:41:02 | filwit | great. what was wrong with my fix? |
| 23:42:24 | Araq | you only fixed 1 place |
| 23:42:32 | Araq | I fixed it everywhere, I hope |
| 23:43:24 | filwit | ah i see, problem with my limited test cases then. glad it wasn't something i wasn't understanding correctly. |
| 23:46:28 | filwit | quick question, why is the body of skipMeta surrounded in () brackets? |
| 23:46:56 | filwit | the if statement? |
| 23:47:14 | Araq | there is some issue with the expr/stmt unification in expressions that I didn't look into |
| 23:47:20 | filwit | ah, of course, cause you're not using 'return', silly question |
| 23:47:25 | Araq | the () enforces it's parsed as an expression |
| 23:50:59 | filwit | btw, have you ever considered (eventually) adding in variant-object param "guards"/"filters" |
| 23:51:31 | Araq | no idea what that is |
| 23:51:36 | Araq | but yes |
| 23:51:40 | filwit | proc foo(n:PNimrodNode.kind(nkMetaNode)) |
| 23:51:47 | Araq | lol, yes |
| 23:51:56 | Araq | in fact |
| 23:51:57 | * | Discoloda quit (Quit: leaving) |
| 23:52:20 | Araq | I planned a blog post about "dispatch tables" and that they are superior to what we have with multi methods |
| 23:52:42 | Araq | and that we should get rid of 'method' as nimrod's meta programming can do even cooler things |
| 23:53:00 | Varriount | Araq: But what about overriding things? |
| 23:53:25 | filwit | Varriount: he said dispatch tables (aka, virtual functions) |
| 23:54:01 | filwit | interesting, i always thought you believed your method approach was superior to vtables |
| 23:54:11 | filwit | but then i never really looked into it |
| 23:54:15 | Araq | I'm not talking of vtables |
| 23:54:33 | EXetoC | does my PR make sense or is there more to it? |
| 23:54:46 | Araq | and fyi it's well known nimrod's methods are not entirely optimized and perform worse than vtables |
| 23:55:11 | filwit | Araq: yeah i remember you telling me that awhile ago (about the performance). |
| 23:55:22 | filwit | Araq: though at the time you said you thought you could close the gap |
| 23:55:32 | EXetoC | (xml attribute escaping) |
| 23:55:41 | Araq | filwit: that's still true |
| 23:56:29 | * | ics joined #nimrod |
| 23:56:52 | filwit | Araq: i really like Zahary's generic objects, and I'm interested to know exactly what you come up with as a vtable/method replacement. |
| 23:58:02 | filwit | if objects can eventually be derived from generic types as a way to enforce behavior, that's a real winner |
| 23:58:51 | Araq | you mean the type classes? |
| 23:59:04 | filwit | yes |
| 23:59:15 | Araq | yeah, you've got to love them ... :-) |