| 01:48:01 | * | NimBot joined #nimrod |
| 01:50:00 | * | JStoker joined #nimrod |
| 01:50:00 | * | rking joined #nimrod |
| 01:51:37 | * | XAMPP quit (*.net *.split) |
| 01:51:38 | * | ccssnet quit (*.net *.split) |
| 01:59:23 | * | comex joined #nimrod |
| 02:00:57 | * | XAMPP joined #nimrod |
| 02:03:22 | * | _ponce joined #nimrod |
| 02:04:54 | * | ccssnet joined #nimrod |
| 05:54:01 | Zor | Araq: still around? |
| 07:40:05 | * | gour joined #nimrod |
| 07:50:05 | * | FreeArtMan joined #nimrod |
| 08:37:57 | Araq | Zor: now I'm around |
| 08:40:35 | gour | morning all |
| 08:40:48 | Araq | hi gour |
| 08:41:29 | gour | we're missing you yesterday |
| 08:42:21 | Araq | yeah I got this stupid thing called "real life" ... :P |
| 08:42:51 | gour | :-) |
| 08:43:58 | gour | i was/am wondering why i fiddle with nimrod after giving up on D2 and deciding to use Ada which provides larger community, more support, stable language etc. |
| 08:44:17 | gour | and thought that maybe i'm simpy dumb :-) |
| 08:45:14 | Araq | well my advertisement is over, use it or use Ada |
| 08:45:44 | Araq | or Haskell |
| 08:46:08 | gour | i do re-read tut1, and believe nimrod is smaller/nicer language than Ada |
| 08:47:12 | gour | i like FP stuff, but monads are not pragmatic solutions for my use-case and the fact i do notown phd in cs |
| 08:47:43 | gour | i'll try to work on my project wiht nimrod ;) |
| 08:47:53 | Araq | ok ;-) |
| 08:49:24 | gour | got some help here yesterday, and converted part of my header by changing it a bit...got stuff like |
| 08:49:26 | gour | proc swe_calc_ut*(tjd_ut: cdouble; ipl: int32; iflag: int32; xx: ptr cdouble; |
| 08:49:28 | gour | serr: cstring): int32 |
| 08:49:57 | gour | now i wonder what is required to be able to call those C functions? |
| 08:50:15 | Araq | #dynlib etc. in the C header |
| 08:53:16 | gour | my ideal scenario would be to include 3rd party C lib in my project and then being able to build C lib, nimrod bindings and the rest of the project without touching original sources/header. what do you suggest? |
| 08:58:01 | Araq | depends on the C lib, for simple C libs, I'd use {.compile: "file1.c".} |
| 09:04:14 | gour | ok |
| 09:07:41 | gour | nimrod's mantra is "Nimrod combines Lisp's power with Python's readability and C's performance." the last two are pretty obvious, but i wonder about the 1st one, especially considering it seems you're not big fan of OOP (Dijkstra quote) - i'm also not - but curious in regard to FP 'cause Lisp is often quoted as FP (albeit non-pure) language? |
| 09:14:29 | Araq | I like FP, but I prefer local state in functions over recursion |
| 09:20:12 | gour | tail call optimization is possible in nimrod? |
| 09:21:35 | Araq | gcc does it |
| 09:21:44 | gour | some algorithms are simply elegant when done recursively |
| 09:22:29 | Araq | that's not my point |
| 09:22:39 | gour | that bothered me in haskell, that due to laziness and attempt to have performant code, one loses practically all of it's elegance |
| 09:22:57 | gour | ohh...pls. explain? |
| 09:23:25 | * | fowl joined #nimrod |
| 09:23:42 | Araq | pure FP prefers recursion over a simple 'while' loop |
| 09:23:57 | Araq | I prefer the 'while' loop |
| 09:24:13 | gour | ahh, yes...no loops in haskell...that's not pragmatic |
| 09:24:20 | gour | i agree with you |
| 09:24:31 | Araq | but it's all a bit fuzzy since FP abstracts over it immediately and gives you 'fold' and 'map' |
| 09:24:33 | gour | haskell is purity to the extremes |
| 09:25:01 | Araq | and fold and map are sweet ;-) |
| 09:25:05 | gour | right...and folds and map are cute |
| 09:25:11 | gour | :-) |
| 09:26:58 | gour | so, it's possible to write some nice FP-like code in nimrod? |
| 09:27:18 | * | fowl left #nimrod (#nimrod) |
| 09:28:17 | gour | based on my short encounter with ada, it seems it', bug language...otoh, nimrod feels, based on what i've seen, as lot of power in very compact package. is my observation correct or totally off? |
| 09:28:29 | gour | *it's big |
| 09:31:25 | Araq | hard to answer; it's not as small as you think it is, but not big either |
| 09:32:28 | gour | smaller than D2? |
| 09:33:43 | Araq | everything is :P |
| 09:34:36 | gour | lol |
| 09:37:40 | gour | i gave up on Emacs (quickly felt pain in wrist), but i'm not vim power-user either...was considering to use geany...do you recommend aporia? |
| 09:37:52 | gour | (over vim) |
| 09:37:54 | * | fowl joined #nimrod |
| 09:47:33 | * | gour quit (Disconnected by services) |
| 09:47:36 | * | gour_ joined #nimrod |
| 09:47:48 | * | gour_ is now known as gour |
| 09:49:00 | Araq | I use aporia and can't think of any feature that geany provides over aporia for nimrod programming |
| 09:50:37 | gour | that's nice...some docs would be good |
| 09:51:40 | gour | nimrod does not have any logo? of course, not utterly important, but i'm thinking when providing packages for some distro to have some icon...but it's not top priority |
| 09:51:59 | Araq | we have icons, the windows version uses it |
| 09:52:54 | * | gour is checking... |
| 09:56:00 | * | gour likes 'ortgogonality' of koch/nimrod icons |
| 10:58:00 | * | q66 joined #nimrod |
| 11:15:28 | * | FreeArtMon joined #nimrod |
| 11:15:36 | * | FreeArtMon quit (Client Quit) |
| 11:18:35 | * | comex quit (Remote host closed the connection) |
| 11:41:08 | * | apriori_ joined #nimrod |
| 11:55:52 | Araq | hi apriori_, I'm still fixing generic converters in '=' |
| 11:56:18 | Araq | which is what your code does and my test doesn't |
| 12:14:28 | apriori_ | hi Araq, ok.. thank you |
| 12:51:16 | apriori_ | Araq: found some more issues with overload resolution and "var" types |
| 12:51:57 | apriori_ | e.g. in cases you got a proc which returns a var T which is an element of a param which is also a var type and you have two procs: |
| 12:52:14 | apriori_ | 1. working on a normal param and returning a normal T |
| 12:52:20 | apriori_ | 2. working on a var param and returning a var T |
| 12:52:51 | apriori_ | the compiler will still complain, although, it should now, e.g. due to direct return calls or yield that the overload with var/var should match |
| 12:52:55 | apriori_ | and there is no ambigious cal |
| 12:53:52 | apriori_ | if that was too confusing, I might also put that into an example |
| 12:54:05 | Araq | yeah I know about this |
| 12:54:19 | Araq | not sure it's as useful as you think it is |
| 12:54:33 | Araq | because for the 'items' iterator I prefer the read-only view |
| 12:54:52 | apriori_ | but what if you want a writable iterator? |
| 12:55:00 | Araq | so we have items for read-only view and 'mitems' for the 'var T' iterator |
| 12:55:04 | apriori_ | hm |
| 12:55:26 | apriori_ | well... |
| 12:55:28 | Araq | where 'm' stands for 'mutable' or 'modifyable' |
| 12:55:35 | apriori_ | yeah, I understand |
| 12:56:40 | apriori_ | problem is.. I also have the same issue with operator [] for my matrices |
| 12:57:08 | Araq | I know |
| 12:57:09 | apriori_ | eigen2/eigen3 "solved" that similar issue by defining coeffRef |
| 12:57:27 | Araq | tables.nim provides [] and 'mget' |
| 12:57:32 | apriori_ | that for sure works.. but.. well, just my opinion.. that restriction is somewhat bogus/random |
| 12:58:04 | Araq | which is not *that* bad |
| 12:58:17 | Araq | I agree it's not exactly elegant |
| 12:58:36 | apriori_ | which is again a matter of taste.. I'd prefer to be able to express mathematic operations as close to the established mathmatical style as possible |
| 12:58:49 | Araq | but we'll see how the planned 'var T' implicit conversions break |
| 12:59:11 | Araq | oh |
| 12:59:25 | Araq | AST based overloading could be the solution :D |
| 12:59:56 | Araq | you make [] declare a 'var T' unless the input arg is a 'const' or 'let' :-) |
| 13:00:08 | Araq | s/declare/return |
| 13:00:40 | apriori_ | okay, gonna try that.. |
| 13:00:53 | apriori_ | btw.. did you think about somehow allowing more custom constraints? |
| 13:01:30 | Araq | I ensured you can templatize the constraints |
| 13:01:30 | apriori_ | say, one would define a proc which does some checks on a type (only the type, not a var/instance of it).. or a template, or whatever.. and use that in the constraint specification |
| 13:01:58 | Araq | yeah we considered it |
| 13:02:08 | Araq | but overloading resolution is slow enough as it is |
| 13:02:26 | Araq | and we have other plans for OR |
| 13:02:38 | apriori_ | okay |
| 13:02:45 | gour | there is some some calculus math lib available for nimrod? |
| 13:03:06 | apriori_ | gour: nope... I'm still (slowly) progressing with a matrix library |
| 13:03:28 | gour | apriori_: so, nothing for finding zero values etc.? |
| 13:03:45 | apriori_ | problem is.. as usual.. I want too much too quick.. I'd prefer to unify the view of "huge matrices", "game size matrices" and "school size" matrices (and vectors) |
| 13:04:03 | apriori_ | gour: you mean numerical functions? nope... |
| 13:04:08 | * | gour just unsubscribed from ada newsgroup if it speaks something to you |
| 13:04:23 | apriori_ | yes, ada tells us something |
| 13:04:39 | gour | apriori_: ok, but it seems nimrod is nice language to write such things in it |
| 13:04:51 | gour | apriori_: :-) |
| 13:04:53 | apriori_ | gour: it is... |
| 13:05:42 | apriori_ | I just wrote a very simple template just defining "matrixSingleArgProc":. which is essentially generates wrappers for any named single arg functino for matrices, so that that is called for each element |
| 13:06:01 | apriori_ | that elimnated a hell lot of enerving boilerplate |
| 13:07:24 | apriori_ | gour: I'd even think, nimrod could allow to easily write quite some efficient simulation/math code.. without the user having to know that much about math |
| 13:07:39 | apriori_ | it could rewrite expressions to more efficient ones using the TR macros etc. |
| 13:08:21 | apriori_ | Araq: I really wondered when I found out, that eigen2/eigen3 has something like that, too.. though using c++ expression templates |
| 13:08:40 | Araq | we know about C++ expression templates |
| 13:08:51 | Araq | and designed TR macros as a superior solution |
| 13:09:01 | apriori_ | yup.. they are... |
| 13:09:07 | apriori_ | much easier to write |
| 13:09:37 | Araq | you can implement expression templates in Nimrod too but it's as tedious with types constructing an AST |
| 13:15:16 | apriori_ | Araq: does AST based overloading work for generics? |
| 13:15:31 | Araq | can't see why it shouldn't |
| 13:15:40 | * | gour is going to re-read tut2 |
| 13:15:59 | apriori_ | gour: note that the tuturial is not as fast updated as the manual |
| 13:16:11 | apriori_ | if you really want to dig in further, rather read the manual for all the details |
| 13:17:01 | gour | apriori_: yeah, i noticed disclaimer, but i still believe there is some nice overview of more advanced features presented there...manuall feels more like reference manual to me |
| 13:17:13 | apriori_ | gour: which it is :P |
| 13:17:57 | apriori_ | Araq: I'm just not quite sure about the syntax |
| 13:18:06 | gour | apriori_: heh, manual usually triggers something more like tutorial or user guide...but, np |
| 13:18:07 | apriori_ | say in: proc `[]=`*[M, N, T] (matrix: var TMatrixNM{lit}[M, N, T], a: M, b: N, v: T) |
| 13:18:14 | Araq | nope |
| 13:18:31 | Araq | it's tmatrix[m,n,t]{lit} |
| 13:18:53 | apriori_ | vector.nim(54, 53) Error: type expected |
| 13:18:55 | apriori_ | in that variant |
| 13:18:59 | apriori_ | proc `[]=`*[M, N, T] (matrix: var TMatrixNM[M, N, T]{lit}, a: M, b: N, v: T) = |
| 13:19:10 | gour | D says it easy to be picked by Java/C(++) programmers...what could be said for Nimrod? python/pascal/...? |
| 13:19:23 | Araq | hrm, may be an oversight of mine, apriori_ |
| 13:19:44 | apriori_ | gour: well.. nimrod is indeed a bit different |
| 13:19:56 | Araq | gour: nimrod is easy for everybody until you figure it's not ;-) |
| 13:20:03 | apriori_ | gour: thouh I think, people understanding basic templatisation will understand nimrod better.. |
| 13:20:20 | apriori_ | gour: therefore I'd say, java programmer would have the most problems with it |
| 13:20:33 | Araq | and then after months people come back and thank me ;-) |
| 13:20:44 | gour | apriori_: i was using C++ when it does not have templates...if anyone of you heard about zortech c++ |
| 13:20:46 | apriori_ | yup.. we did :) |
| 13:20:59 | apriori_ | gour: nope, don't know about that |
| 13:21:09 | apriori_ | ah |
| 13:21:16 | * | gour never touched, fortunately, java |
| 13:21:16 | apriori_ | the digital mars compiler.. |
| 13:21:35 | gour | yeah, its author is now pushing D |
| 13:21:53 | apriori_ | yup.. we know about D.. |
| 13:21:56 | Araq | ok, ok, I got a single user who thanked me after months :D |
| 13:21:58 | apriori_ | and its.. "marketing" |
| 13:22:19 | gour | Araq: where is this user? |
| 13:23:01 | Araq | gour: http://forum.nimrod-code.org/t/100/1 |
| 13:23:11 | apriori_ | Araq: an oversight.. so it's not implemented? |
| 13:23:15 | Araq | "adrianv" |
| 13:23:37 | Araq | apriori_: it's likely a 1 line fix, let me have a look |
| 13:24:32 | gour | maybe i should consider joining to improve Araq's karma...although i really prefer mailing lsits/newsgroup |
| 13:30:42 | Araq | ah apriori_ the problem is the 'var T' here |
| 13:30:54 | Araq | you have to use (var xyz){lit} |
| 13:31:03 | apriori_ | ah, ok |
| 13:31:04 | apriori_ | tying |
| 13:36:04 | gour | tut2- mut. rec. types sections says: "In Nimrod these types can only be declared within a single type section." is it valid for recurs. types only or in general for declaring new types? |
| 13:36:07 | apriori_ | Araq: k, seems to work |
| 13:36:34 | Araq | gour: for rec types only |
| 13:37:37 | gour | Araq: ta |
| 13:38:55 | Araq | I have to go, see you later |
| 13:38:59 | apriori_ | Araq: bye |
| 13:39:03 | apriori_ | and thanks |
| 13:39:28 | Araq | no, I have to thank you for helping to get the math part of the stdlib done |
| 13:39:36 | apriori_ | some day ^^ |
| 13:39:46 | Araq | or at least playing with it ;-) |
| 13:40:00 | apriori_ | at the very minimum I stress the hell out of your compiler :P |
| 13:40:16 | Araq | yeah I noticed ;-) |
| 13:40:17 | gour | is there any helper lib for marshalling between C <---> Nimrod ? |
| 13:40:35 | apriori_ | gour: be more precise please |
| 13:40:39 | Araq | gour: there is no marshalling needed most of the time |
| 13:40:42 | Araq | bye |
| 13:40:43 | apriori_ | you can wrap (import) c strucs right away |
| 13:40:48 | apriori_ | *structs |
| 13:41:57 | gour | apriori_: i've 3rd party lib for which i need nimrod binding, e.g. C lib stores result in double*[] and i want to use some higher-level data structure in nimrod, or instead of fiddling with #defines i want to have separate enumeration set in nimrod etc. |
| 13:42:40 | gour | (to avoid or-ing integer flags...) |
| 13:42:47 | apriori_ | yes, i understand |
| 13:43:20 | gour | in haskell i'd first provide just C wrapper and then higher-level haskell-ish API |
| 13:43:27 | gour | similar in nimrod. |
| 13:43:30 | apriori_ | that works in nimrod, too |
| 13:43:39 | apriori_ | https://github.com/apriori/nimCL/blob/master/cl/cl_ext.nim |
| 13:43:42 | apriori_ | see that for example |
| 13:43:58 | apriori_ | that was mostly automatically constructed by c2nim from the header files |
| 13:44:53 | apriori_ | so you can wrap a c routine using the usual types |
| 13:45:09 | apriori_ | for c specifically there exists cint, cstring etc. |
| 13:45:57 | gour | required C lib is simplas as far as types are concerned... |
| 13:45:58 | apriori_ | and shoud should prefer to use those in the wrapper, because e.g. int in nimrod is a platform dependent alias for either int32 or int64 (depending on arch) |
| 13:46:31 | gour | how are you happy with c2nim? |
| 13:46:43 | apriori_ | well, it does some decent job |
| 13:46:54 | apriori_ | for some cases it's not that useful.. |
| 13:46:58 | apriori_ | but it will save your a lot of time |
| 13:47:02 | apriori_ | *you |
| 13:47:39 | * | gour notices apriori_ has some D-stuff-related-repos ;) |
| 13:47:52 | apriori_ | e.g. in my case OpenCL defines "shitloads" of constants via C macros.. |
| 13:48:10 | apriori_ | and really wasn't too happy thinking about porting those over manually.. c2nim did just that.. |
| 13:48:19 | apriori_ | especially, if you're new to nimrod, it helps |
| 13:48:31 | apriori_ | e.g. if you didnt quite know about shl for shift left etc. |
| 13:48:39 | apriori_ | gour: and yes, I did some D stuff before |
| 13:48:43 | apriori_ | but I'm no longer happy with D |
| 13:48:46 | gour | yeah, my lib aslo has bunch of #defines which we want to put in sets |
| 13:49:04 | apriori_ | yeah, bit sets are nice |
| 13:49:26 | * | gour also gave up on D2 and wanted to use Ada instead...seing it as more stable/supported platform...and now fiddling with Nimrod |
| 13:49:45 | apriori_ | you can e.g. define an enum over all flag values, build a set over set and then use set.incl and set.excl to set and unset the flag |
| 13:50:26 | apriori_ | well, I learned a lot (especially, to hate java, which I have to use at work, even more) using nimrod |
| 13:50:48 | apriori_ | in java I constantly miss the macros and templates nimrod has.. to fight boilerplate |
| 13:50:56 | gour | for type-safety, i'd like to break all thsoe #defines into specific sets 'cause they (un)set quite different options |
| 13:51:07 | apriori_ | yeah, easily doable |
| 13:51:40 | apriori_ | I wanted to do the same for the OpenCL wrapper.. but didnt really find the motivation to do that (because it would also mean, I'd have to maintain that) |
| 13:51:41 | gour | i never did templates in C++, in D they seem a bit convoluted...same for macros 'cause never did any lispy language |
| 13:52:02 | gour | which editor you use' |
| 13:52:05 | gour | ? |
| 13:52:14 | apriori_ | it will take some time, till you get used to all the "fancy" features |
| 13:52:22 | apriori_ | aporia, a project by dom96 |
| 13:52:40 | apriori_ | it provides a simple, minimalistic yet functional IDE for nimrod |
| 13:52:56 | * | gour thinks nimrod deserves much more users...i'll try to provide package, even non-official, for debian |
| 13:53:02 | apriori_ | https://github.com/nimrod-code/Aporia |
| 13:53:12 | * | gour already built aporia :-) |
| 13:53:16 | apriori_ | hehe, ok |
| 13:53:21 | apriori_ | and yes, I agree |
| 13:53:45 | apriori_ | but.. since we're short on manpower, I think it might be preferable if you work on some code instead of maintaining packages |
| 13:53:46 | gour | there should be debian/ubuntu/fedora packages |
| 13:54:14 | apriori_ | frankly.. users that are not even able (or more: lazy) to build the compiler are not that useful either right now |
| 13:54:16 | gour | apriori_: well, i plan to use nimrod for very concrete multi-platfrom gui project |
| 13:54:31 | apriori_ | but I understand.. it would lower the barrier to actually start using nimrod |
| 13:54:36 | gour | with geeks only, it won't have much users |
| 13:55:33 | apriori_ | I had a discussion with someone at my work 2 days ago.. he considered "yield" a "fancy, yet uneeded feature"...and praised the java iterator API :/ |
| 13:55:57 | apriori_ | I felt geekish then.. although I just didnt get it :P |
| 13:56:01 | gour | strange...python has it for quite some time |
| 13:56:09 | apriori_ | even C# has it |
| 13:56:14 | apriori_ | afaik |
| 13:56:29 | gour | dunno C# |
| 13:57:59 | apriori_ | gour: I really recommend you get familiar with templates at some time |
| 13:58:18 | gour | apriori_: for generic programming? |
| 13:58:25 | apriori_ | far more than that |
| 13:58:39 | apriori_ | say... you got a code snippet.. |
| 13:58:45 | apriori_ | which is used over and over again.. |
| 13:58:47 | gour | now ican only think about that |
| 13:59:02 | apriori_ | its somewhat identical, but not exactly identical.... templates can help with that |
| 13:59:22 | apriori_ | because in nimrod you can actually pass expressions to a template |
| 13:59:32 | gour | not identical in terms of parameters, types or something else' |
| 13:59:33 | apriori_ | not only types, or type instances |
| 13:59:34 | gour | ? |
| 13:59:51 | apriori_ | giving an example |
| 14:00:24 | apriori_ | https://gist.github.com/4295271 |
| 14:00:34 | apriori_ | that's generic on operator level |
| 14:00:45 | apriori_ | of course one could also use closures/function parameters for that |
| 14:01:00 | apriori_ | notice in the template, the call to "op" |
| 14:01:42 | gour | interesting |
| 14:01:58 | apriori_ | and you also see |
| 14:02:04 | apriori_ | the templates gets the entire contest of the function |
| 14:02:08 | apriori_ | all variable defintions etc. |
| 14:02:25 | apriori_ | *context |
| 14:02:27 | apriori_ | not contest :P |
| 14:02:46 | gour | :-) |
| 14:03:30 | gour | you know haskell and type-classes? |
| 14:03:39 | apriori_ | I know haskell... a bit at least |
| 14:03:57 | apriori_ | and yeah, also about type classes |
| 14:04:40 | gour | nimrod has, btw, very beautiful syntax |
| 14:04:52 | apriori_ | yup, I like it too ;) |
| 14:05:12 | apriori_ | gour: btw, a tr macro |
| 14:05:14 | apriori_ | template optimizeCrossOfSameVector*{cross(a, a)}(a: expr) : expr = cast[type(a)]([ 0, 0, 0 ]) |
| 14:05:34 | apriori_ | although definetly not the prefered usage for TR macro, because those should not change semantics |
| 14:05:59 | gour | macros is another thing we have to wrap our mind around |
| 14:06:06 | apriori_ | one could better use ast based overloading now, to properly implement that |
| 14:06:16 | apriori_ | macros will get some time to get used to |
| 14:06:25 | apriori_ | but see them as code generators |
| 14:06:40 | apriori_ | within the boundaries of the nimrod syntax, you do some wicket stuff with it |
| 14:06:48 | gour | i'd like to some more FP techniques in nimrod than oop stuff |
| 14:07:09 | gour | s/some/use some |
| 14:09:06 | apriori_ | gour: btw: https://github.com/fowlmouth/nimlibs/blob/master/macros/classlib.nim |
| 14:09:40 | apriori_ | see that as an example.. scroll down to the part after "when isMaiModule" to see examples of the usage of the macros |
| 14:11:58 | apriori_ | so you could pass in some AST of nimrod code into a macro, process that there and emit a completely different AST.. e.g. to form some kind of DSL |
| 14:12:19 | gour | mind-blowing |
| 14:40:26 | apriori_ | gour: something like type classes should actually be possible in nimrod |
| 14:40:56 | apriori_ | with macros that define templates.. e.g. for the operations in the type class instance |
| 14:40:56 | gour | i'm reading about generics in tut2 now |
| 14:41:30 | gour | i've to come to macros yet |
| 14:41:36 | apriori_ | take your time ^^ |
| 14:49:35 | apriori_ | dom96: do you happen to be here? |
| 14:49:46 | dom96 | yep. |
| 14:49:51 | dom96 | What's up? |
| 14:49:55 | apriori_ | I've got a short question |
| 14:50:02 | apriori_ | assuming you call a macro: |
| 14:50:06 | apriori_ | someMacro blub, moep: |
| 14:50:08 | apriori_ | var test = 1 |
| 14:50:40 | apriori_ | is it possible to get the params blub, moep only in the macro, without defining a terminating element for the arglist? |
| 14:50:59 | apriori_ | like.. distinguishing actual calling args and "passed in body" |
| 14:53:04 | dom96 | hrm, |
| 14:53:17 | dom96 | someMacro (blub, moep): ... |
| 14:53:27 | apriori_ | dom96: with variable arg list? |
| 14:53:28 | dom96 | (blub, moep) # -> This is now one param. |
| 14:53:37 | dom96 | I'm not sure if that works actually |
| 14:53:50 | apriori_ | the static param style works |
| 14:54:04 | fowl | apriori_: callsite() |
| 14:54:23 | apriori_ | fowl: callsite seems to include all |
| 14:54:27 | apriori_ | which is not what I want |
| 14:54:39 | apriori_ | callsite includes blub, moep and the var section statement |
| 15:01:55 | apriori_ | hrm |
| 15:02:08 | apriori_ | varargs might work.. but I got no clue how to iterate over a varargs[expr] |
| 15:02:19 | apriori_ | it doesnt seem to have items defined |
| 15:02:42 | apriori_ | someExpr.len seems to be right.. but then someExpr[i] not |
| 15:02:50 | gour | before nimrod, did you use some other language from the category of 'obscure' ones? |
| 15:03:05 | apriori_ | gour: nope.. unless you include D |
| 15:03:40 | gour | apriori_: heh, not sure what would D users say about it :-) |
| 15:03:50 | apriori_ | gour: they would likely yell :P |
| 15:04:09 | gour | or create >100posts thread about it |
| 15:04:50 | gour | btw, are you happy with forum or any interest for mailing list (possibly subscribed to gmane)? |
| 15:05:20 | apriori_ | I'm not really representative there.. but I prefer IRC/forums |
| 15:05:33 | apriori_ | mailing lists tend to get.. cluttered and unorganized |
| 15:06:02 | gour | i prefer nntp..automatic archive ,easy following, threading, etc. |
| 15:06:11 | dom96 | apriori_: You should create a blog post saying exactly why you're using Nimrod instead of D. :P |
| 15:06:14 | gour | forums are, imho, pain to follow |
| 15:06:23 | Araq | apriori_: tell the guy that 'yield' is not "fancy" at all and Java completely and utterly lacks a thing that's called "control flow abstraction" ;-) |
| 15:06:31 | apriori_ | dom96: or I shouldn't.. because I dont want to deal with the shitstorm ^^ |
| 15:06:43 | apriori_ | Araq: completely agreed |
| 15:07:35 | apriori_ | Araq: but.. really, I could rather talk to a wall instead.. he is a guy who just _loves_ oop structure bloat.. tons of interfaces, factories, wrapped constructors everywhere |
| 15:08:08 | * | gradha joined #nimrod |
| 15:08:26 | apriori_ | gour: agreed on the follow, yes |
| 15:10:08 | * | gour notices that even felix has ml |
| 15:12:43 | apriori_ | Araq: could you give a hint on how to iterate over varargs[expr]? |
| 15:14:16 | Araq | I have no idea :-) |
| 15:14:25 | apriori_ | ok |
| 15:14:29 | Araq | use 'callsite' to iterator over that |
| 15:14:35 | Araq | *iterate |
| 15:14:51 | apriori_ | yeah, guess I can only define a terminating element then |
| 15:15:09 | Araq | hu? |
| 15:15:12 | apriori_ | to distinguish the params.. and the body param |
| 15:15:23 | apriori_ | I'd like to distinguish in: |
| 15:15:29 | apriori_ | someMacro blub, moep: |
| 15:15:31 | apriori_ | someBody |
| 15:15:43 | apriori_ | the body and the both (variable count) params |
| 15:15:45 | Araq | well callsite[-1] is the body |
| 15:16:06 | apriori_ | hm |
| 15:17:01 | apriori_ | index out of bounds ^^ |
| 15:17:45 | apriori_ | I didnt really expect something else :P |
| 15:18:43 | Araq | you're in a macro, right? |
| 15:18:47 | apriori_ | yes |
| 15:19:20 | apriori_ | I just wanted to write a "search and replace" macro |
| 15:19:49 | Araq | hrm, I could swear macros.`[]` supports a negative index... :D |
| 15:20:01 | Araq | maybe only in my dreams ... |
| 15:20:15 | apriori_ | trying to deactivate bound checks |
| 15:20:18 | Araq | let x = callsite(); x[x.high] should work though |
| 15:20:32 | Araq | you can't deactivate bound checks for compile time code |
| 15:20:38 | apriori_ | ok |
| 15:20:45 | fowl | x.len - 1 |
| 15:21:46 | apriori_ | well, you assume the body is always only one statement |
| 15:21:53 | apriori_ | problems start, if that's no longer the case |
| 15:22:14 | Araq | you need the 'do' notation to pass more than 1 block |
| 15:22:16 | fowl | apriori_: the body should be wrapped in nnkDo |
| 15:24:16 | apriori_ | ok |
| 15:28:41 | dom96 | fowl: nice job on the csfml particles demo, very cool. |
| 15:29:20 | gradha | Araq: yesterday I fought with nimrod's importc pragma, I wanted to load a library with dynlib, check for a symbol, and set a different prefix for an importc. Didn't manage to get it working. Can you provide any advice on that? |
| 15:29:36 | Araq | I already did |
| 15:30:23 | Araq | check out the undocumented feature that the opengl wrapper uses ;-) |
| 15:33:11 | fowl | dom96: thanks |
| 15:33:41 | dom96 | fowl: btw i'm making a game for ludum dare and using your sfml wrapper. |
| 15:35:29 | fowl | cool |
| 15:39:14 | gradha | ah, so there where a few hours left for yesterdays log |
| 15:40:08 | * | zahary joined #nimrod |
| 15:42:46 | Araq | zahary: in your example the param was an interior pointer but on stack |
| 15:43:01 | Araq | the pointer itself is on the stack |
| 15:45:39 | Araq | that said, the implicit 'const&' parameter passing mode causes some problems; can't see any better solution though; C |
| 15:46:09 | Araq | ++ is more verbose about it but that's it |
| 15:47:14 | apriori_ | gotto go guys |
| 15:47:15 | apriori_ | bye |
| 15:47:17 | apriori_ | *gotta |
| 15:47:21 | * | apriori_ quit (Quit: Konversation terminated!) |
| 15:48:25 | zahary | sorry, I lost my connection the other day. my example was that it's still possible to have memory corruption in such situations |
| 15:49:17 | Araq | yeah and we should find a solution |
| 15:49:30 | zahary | I have a partial solution tho. now, I don't immediately release the memory sequence/string buffer is deallocated. instead I free it in the next garbage collection if there are no pointers into it |
| 15:49:58 | zahary | this can lead to hard to find bugs, but it can't corrupt memory |
| 15:50:19 | Araq | why not set the deallocated pointers to 'nil' instead in the GC? |
| 15:50:56 | zahary | how will that help? just changes the nature of the latent bug |
| 15:51:15 | Araq | I consider aliasing into a sequence that you setLen to 0 an edge case |
| 15:51:50 | zahary | I had the idea to raise exception if I detect pointer into the released memory, but that's not reliable enough because of false-positives |
| 15:51:53 | Araq | so ensuring the programmer's code crashes should be enough (?) |
| 15:53:42 | Araq | and I consider D worse than nimrod as its type system doesn't distinguish ptr from ref, nor array from seq |
| 15:54:05 | Araq | but alright, I'll be more humble again ;-) |
| 15:54:06 | zahary | explicit GC pointers are nice, yes |
| 15:57:38 | Araq | in fact, the GC should set these pointers to 'nil' only in debug mode |
| 15:58:04 | zahary | you mean the contents of the buffer, right? |
| 15:58:18 | zahary | or stack pointers I detect? |
| 15:58:52 | Araq | the stack scanning already checks for interior pointers, but your example was more complex |
| 15:59:05 | * | fowl is now known as fowl|asus |
| 15:59:16 | Araq | you had a seq[object] and then aliased into that via parameter passing |
| 15:59:30 | Araq | and then deallocated that sequence explicitly via setLen |
| 15:59:37 | zahary | yes |
| 16:00:02 | Araq | you need to do: |
| 16:00:19 | Araq | var y = param # keep alive |
| 16:00:23 | Araq | setLen(s, 0) |
| 16:00:28 | Araq | use(y) |
| 16:01:08 | Araq | and need to somehow make the programmer aware of it in debug mode |
| 16:01:20 | Araq | imo the GC doesn't need to keep it alive longer per se |
| 16:01:50 | Araq | or maybe we need an assertion in setLen |
| 16:02:21 | zahary | I don't quite follow. which pointer you think I'll be able to set to nil? the param? |
| 16:03:25 | zahary | my other idea was to protect the page in debug builds and intercept reads into it |
| 16:03:36 | zahary | the page of the deallocated buffer |
| 16:03:46 | Araq | the GC'ed memory inside the object that param points to |
| 16:04:39 | zahary | alright, the contents of the buffer. I can do that, maybe even 0xCC will be a better value |
| 16:04:59 | Araq | but I'm assuming a pointer within this object is the problem and not the sequence itself |
| 16:06:19 | Araq | which is not the case. hm. |
| 16:06:41 | Araq | the allocator already has the option 'overwriteFree' btw |
| 16:07:14 | Araq | in mmdisp.nim, dunno if you're aware of it |
| 16:07:51 | zahary | even when we paint the memory with a bad value, we still has to keep it around until the next collection. otherwise, it may be allocated to another object |
| 16:08:44 | Araq | but the interior pointer already keeps it alive |
| 16:08:54 | Araq | it's just that either a) setlen is buggy |
| 16:09:18 | Araq | or b) the problem is really another GC'ed pointer within the object |
| 16:10:30 | zahary | no, it doesn't. the old code was deallocating the memory straight away |
| 16:10:42 | zahary | this is growObj in gc.nim |
| 16:16:46 | Araq | ok, but growObj is only called from setlen I think |
| 16:18:40 | Araq | alright so growObj calls 'rawDealloc' when it really shouldn't |
| 16:19:08 | Araq | but well, seqs are value-based |
| 16:19:28 | Araq | so the asumption was there can't be aliases to it left |
| 16:19:42 | Araq | it grows the sequence, can't do that so needs to reallocate |
| 16:20:07 | Araq | and frees the old buffer since 'setLen' takes a 'var' and so does 'add' |
| 16:21:04 | zahary | are you explaining the problem to yourself or you're trying to explain something to me? |
| 16:21:20 | Araq | to myself and see if you disagree :D |
| 16:26:22 | zahary | alright, yes, strings and sequences are serial objects (the buffer itself always have refcount 1), so growObj was "safe" for them. btw, I like your unsafeNew idea - at some point we could make it the only built-in primitive for the GC |
| 16:26:32 | dom96 | fowl|asus: seems declaration of newTexture*(filename: cstring ... is wrong, should have a area: PIntRect param too. |
| 16:27:46 | fowl|asus | dom96: csfml uses C/SFML 2.0 from HEAD, not the rc |
| 16:27:49 | Araq | problem is 'unsafeNew' breaks ropes.nim in a very weird way |
| 16:27:50 | zahary | we could reuse the openarray "type" to make the intention more explicit |
| 16:27:50 | zahary | type sequence[T] = object |
| 16:27:50 | zahary | len: int |
| 16:27:50 | zahary | data: openarray[T] |
| 16:28:14 | Araq | and I haven't found the time to debug it |
| 16:28:29 | zahary | what do you know about the problem so far? |
| 16:29:00 | zahary | I'll have trouble merging ropes.nim, because I have non-trivial local modifications too |
| 16:29:19 | Araq | it produces .c code where every literal has its length appended as its *ascii* representation |
| 16:29:20 | fowl|asus | dom96: do you mean this one: proc newTexture*(image: PImage, area: PIntRect = nil): PTexture {.cdecl, importc: "sfTexture_createFromImage", dynlib: LibG.} |
| 16:29:43 | fowl|asus | dom96: oh nvm i see it |
| 16:30:07 | Araq | so it produces: 4leng1(4int 1a) |
| 16:30:12 | Araq | or something like that |
| 16:30:23 | gour | D has structs and classes providing different semantics and performance trade.ofs...what is nimrod's equivalent for structs? |
| 16:30:24 | Araq | which btw puts GCC into an endless loop apparently |
| 16:30:37 | Araq | gour: 'object' or 'tuple' |
| 16:31:25 | gour | Araq: i wonder about tuple due to having ordered fields and if there is some performance issue to just use object? |
| 16:31:49 | fowl|asus | dom96: just pushed a fix |
| 16:32:17 | Araq | gour: object is a nominal type, tuple is a structural type, the overhead is 0 in any case unless you use inheritance |
| 16:32:19 | dom96 | thanks. btw it might be a good idea to get rid of line 1004. |
| 16:32:39 | gour | Araq: great |
| 16:34:01 | fowl|asus | dom96: why? |
| 16:34:34 | dom96 | fowl|asus: because if you don't have HEAD compiled it complains about a missing symbol, and dead code elimination doesn't get rid of it because it's used in that 'let' |
| 16:36:52 | Araq | zahary: reusing the openarray type is not a bad idea; it will ultimately cause problems because you can then do: obj.data = someParam |
| 16:36:54 | fowl|asus | dom96: better they find out sooner than later |
| 16:37:23 | Araq | so we need to allow assignment for openArray and allow openArrays in other places |
| 16:37:54 | zahary | it could be superficial, tyOpenArray is replaced with something as soon as you parse the type |
| 16:38:14 | Araq | yeah, otherwise it will be buggy for years |
| 16:38:48 | dom96 | fowl|asus: well alright, it's your choice |
| 16:40:09 | fowl|asus | there are a few other functions that arent in the RC and id rather them get an error right away than down the line when they use a function thats missing |
| 16:41:12 | Araq | so ... I'd like to allow growObj to dealloc |
| 16:41:43 | Araq | but then overwriting the memory doesn't help |
| 16:42:03 | Araq | another alloc could come along in the meantime and re-use that block of memory |
| 16:42:38 | zahary | well, keep on repeating what I said 10 minutes ago :P |
| 16:43:50 | zahary | I have another plan how to speed up some of the stack bound sequences and strings and buy us back some of the lost inefficiency |
| 16:44:21 | zahary | you remember my checkpoint allocator, right? I've used it for similar purposes in C++ for years |
| 16:46:37 | Araq | sorry, I don't remember :P |
| 16:47:29 | Araq | btw is there any other solution than giving string and sequence literals the GC object header (type + RC) now that we often don't copy strings/seqs? |
| 16:49:04 | zahary | it's bump pointer allocator with checkpoints |
| 16:49:04 | zahary | when you enter the function you do |
| 16:49:04 | zahary | var top = current_top and then when you exit the function you restore the current top thus throwing away all the memory that was allocated in the current scope |
| 16:49:38 | Araq | what's a checkpoint? |
| 16:49:48 | zahary | we also use with non-scoped checkpoints "throw everything since the last rendered frame" |
| 16:49:57 | zahary | maybe you remember this description |
| 16:50:01 | Araq | *what exactly is the checkpoint in this setting? |
| 16:51:19 | zahary | the *checkpoint* is the place you get the current position of the bump pointer allocator (the top variable) |
| 16:52:17 | Araq | alright, I was wondering if it maybe refers to the implicit 'finally: setback()' that C++'s RAII provides you with |
| 16:54:56 | dom96 | fowl|asus: well I think it's worse if you can't use it at all because you don't have the latest version from GIT. |
| 16:59:36 | Araq | well the fix looks much easier to me, zahary |
| 16:59:46 | Araq | no need for any special logic |
| 17:00:00 | Araq | just keep the old seq in the ZCT and don't dealloc it |
| 17:00:18 | gour | manual says: "Unfortunately, d + 12.TDollar is not allowed either, because...", but we consider it is "fortunately" :-) |
| 17:00:38 | zahary | you don't read my messages, do you? :P |
| 17:01:02 | Araq | let me check ... |
| 17:01:07 | zahary | to quote myself: |
| 17:01:07 | zahary | I have a partial solution tho. now, I don't immediately release the memory sequence/string buffer is deallocated. instead I free it in the next garbage collection if there are no pointers into it |
| 17:01:07 | zahary | this can lead to hard to find bugs, but it can't corrupt memory |
| 17:02:51 | Araq | yeah, well, I read it |
| 17:02:57 | Araq | but got it only now :P |
| 17:03:14 | Araq | I thought that you put in some special logic for this case |
| 17:03:30 | Araq | like a "checkpoint" allocator :P |
| 17:03:42 | zahary | as usual, I've eaten some words :) it should be *where the sequence/string is deallocated* |
| 17:04:07 | zahary | the checkpoint allocator is for speed |
| 17:04:23 | zahary | very fast allocations and noop deallocations |
| 17:04:51 | zahary | it's safe only for dumb buffers tho - these that don't have ref pointers into them |
| 17:06:13 | zahary | in C++, I've also gathered statistics that over 90% of the time you can grow a string or vector buffer "in-place" |
| 17:06:58 | zahary | this is possible when there are no other allocations in between the reallocs |
| 17:06:58 | zahary | happens when you append to a string for example in a loop |
| 17:07:38 | Araq | yeah I know |
| 17:07:41 | fowl|asus | dom96: i could branch it for 2.0 RC maybe |
| 17:07:58 | Araq | but 90% is suprising |
| 17:08:28 | Araq | whenever you generate something more complex like a .c file (different sections) it can't work that well |
| 17:08:31 | zahary | well, depends on the application I guess. after all, in C++ I manually choose the places where to use the allocator |
| 17:08:54 | gradha | I'm using exportc for a global variable, but it doesn't appear in the generated .h file, how can I make it appear there for use by C code? |
| 17:09:32 | Araq | gradha: sounds like a bug |
| 17:09:39 | zahary | well, the normal allocator always allocates a new buffer and copies the old one, so the bump-pointerness is still faster than free-lists, etc |
| 17:10:13 | zahary | also, it's useful only for stack bound strings as I said |
| 17:10:26 | zahary | the ropes in cgen won't qualify to use it |
| 17:10:41 | zahary | i.e. the proc sections, etc |
| 17:10:49 | dom96 | fowl|asus: that might work |
| 17:11:08 | Araq | I thought about generating a C AST instead of the ropes |
| 17:11:33 | Araq | you can do some transformations on that then |
| 17:11:43 | Araq | and the ropes are already very expensive trees |
| 17:11:52 | zahary | it's quite a lot of work |
| 17:12:04 | Araq | unfortunately yes |
| 17:12:22 | Araq | and 'emit' means we don't have the full C AST around |
| 17:13:16 | Araq | the ropes are fundamentally unfixable though |
| 17:13:34 | Araq | thanks to them being immutable you can't really change the API |
| 17:13:45 | Araq | without breaking lots of code |
| 17:13:55 | zahary | the API of what? |
| 17:20:39 | Araq | the API of ropes.nim |
| 17:23:36 | zahary | I told you about my compile-time rope formatting attempt, right? |
| 17:23:36 | zahary | I was able to transform expressions like linecg(module, "$1 = $2", a, b) into line(concat(a, glovalVarHavingTheValue(" = "), b)) |
| 17:23:52 | Araq | yeah I remember |
| 17:24:12 | zahary | unfotrunately, it's a net loss for the compiler itself |
| 17:24:28 | Araq | how so? :D |
| 17:24:46 | Araq | keeping the ropes alive doesn't help locality? |
| 17:25:41 | zahary | for a while I picked only hotspots in the compiler and it was working out, but after I applied it more broadly, the cost of macro execution trumped the better run-time code |
| 17:25:58 | Araq | ah yeah, bootstrapping |
| 17:26:40 | zahary | should improve the compilation of Aporia tho, and I will revisit it once we have some form of macros in a DLL (I have some ideas about how to gradually introduce them on demand with pragmas) |
| 17:26:52 | Araq | improving evals.nim is suprisingly hard |
| 17:27:08 | Araq | I thought about a proper bytecode VM |
| 17:27:34 | Araq | but it's a lot of work; especially since you want to get nice stack traces and introspection capabilities |
| 17:27:51 | Araq | the AST evaluation gives all that for free |
| 17:27:58 | zahary | yes, sounds like a lot of work. |
| 17:30:40 | Araq | for a start, we really need pack and unpack primitives to transform an AST-based value into a packed C-compatible value |
| 17:31:54 | zahary | I think it's better if you only use the packed form. have an attacked Type objects that contains a hash table with field-to-offset |
| 17:32:00 | zahary | attached |
| 17:32:49 | Araq | the packed form can't work on the ASTs easily |
| 17:33:46 | zahary | what do you mean? |
| 17:35:16 | Araq | macros.`[]` is a built-in which relies on evals.nim working on ASTs |
| 17:35:24 | Araq | not on bytes |
| 17:35:56 | Araq | nothing that can't be solved though |
| 17:40:07 | zahary | I don't imagine that these magics will change (the AST magic type is already a C type). I was referring to user-defined types |
| 17:41:35 | zahary | and my plan for compiling macros in DLLs relies on using alternative version of macros.nim where the definitions of the magic functions are just given as regular procs |
| 17:43:28 | Araq | aha, I see |
| 18:06:43 | * | gour now knows there is asm keyword in nimrod |
| 18:30:16 | gradha | does nimrod have some sort of automatic magical marshaling/serialization? meaning I have a random TObject and I can save it to disk and load it later |
| 18:30:43 | Araq | gradha: the 'marshal' module? |
| 18:33:45 | gradha | the restriction means I have to detect the version of the object or it would load incorrectly? |
| 18:37:36 | Araq | the restriction means you can't use inheritance with it |
| 18:38:07 | Araq | well you can, but ensure that you know the real type |
| 18:38:25 | Araq | and not some sub/supertype |
| 18:38:51 | gradha | ah, ok, because I was reading now the code and it seems to save key/value, so adding/removing fields should work |
| 18:39:15 | Araq | it saves as json, yeah |
| 18:39:30 | Araq | and of course, feel free to improve it |
| 18:39:38 | Araq | looks hard to do though :P |
| 18:39:50 | Araq | and I think even C# has the same restriction |
| 18:44:21 | Araq | however, ignoring missing values should be easy to implement |
| 18:51:39 | Zor | Araq: do you disallow interior pointers in nimrod? |
| 18:52:01 | Araq | Zor: pretty much yes |
| 18:53:07 | Zor | any particular reason why? |
| 18:53:47 | Araq | our write barrier is already expensive enough |
| 18:54:30 | Zor | what do you use a write barrier for exactly? |
| 18:54:55 | Araq | incremental GC |
| 18:55:20 | Araq | can't think of any efficient GC algorithm that doesn't either require a write or a read barrier |
| 18:55:45 | Araq | and a read barrier looks very troublesome |
| 18:56:09 | Araq | Azul does that but they had to implement hardware support for it |
| 18:56:32 | Araq | I'm not aware of any other GC in production that uses a read barrier |
| 18:56:58 | * | comex joined #nimrod |
| 18:58:19 | Araq | Nimrod's GC is based on reference counting, Zor; copying collectors often use card marking in the write barrier instead |
| 18:58:38 | Araq | which is likely to be cheaper |
| 18:58:50 | Araq | and I think interior pointers are not that much of a problem for card marking |
| 18:58:59 | Zor | right, I'm curious what you use the write barrier for in a reference counting scheme |
| 18:59:16 | Zor | I know how most other algorithms work, just not really familiar with RC |
| 18:59:49 | Araq | a = b |
| 18:59:53 | Araq | becomes: |
| 19:00:03 | Araq | decRC(a) |
| 19:00:08 | Araq | incRC(b) |
| 19:00:10 | Araq | a = b |
| 19:00:24 | Araq | that's called the write barrier |
| 19:04:56 | * | comex quit (Remote host closed the connection) |
| 19:04:58 | Zor | I assume you only insert dec/inc calls when you statically know that you're dealing with an RC'd type |
| 19:05:14 | Araq | exactly |
| 19:05:54 | Zor | do the dec/inc barrier calls check for null? |
| 19:06:01 | Araq | and there are quite some optimizations applied to reduce the cost |
| 19:06:14 | Araq | they do check for null, yes |
| 19:06:34 | Araq | we'll optimize that away too some day |
| 19:07:50 | * | comex joined #nimrod |
| 19:08:25 | Zor | what do your object headers look like? |
| 19:08:45 | Araq | RC + some bits in the same word + type info word |
| 19:09:40 | Araq | I planned some "chunk GC" which would require a type info word only per 64K chunk |
| 19:10:12 | Araq | but dunno if I'll ever find the time to implement that idea |
| 19:10:56 | Zor | I don't think a type info word is going to be the end of the world anyway |
| 19:12:57 | Zor | so how do you optimize insertion of write barriers? some kind of liveness analysis? |
| 19:16:50 | Araq | a type info word is pretty bad: seems like it's more and more paying off to compress your stuff and decompress on the fly |
| 19:16:51 | Araq | since CPUs are fast and RAM not so much; a word is 8 bytes on 64bit machines, so it's an overhead of 16 bytes for every object; and now have a look how many words I'm writing here that are less than 16 chars in length |
| 19:19:28 | Araq | Zor: search for "Deferrent Reference Counting", Deutsch-Bobrow garbage collector and Christoper's partial mark-sweep garbage collector |
| 19:24:50 | Zor | I can't seem to find the latter |
| 19:25:35 | Araq | python's GC implements it |
| 19:26:05 | Araq | there was a good description about it somewhere; it's cycle collection for when you already have reference counts |
| 19:27:21 | Araq | http://arctrix.com/nas/python/gc/ |
| 19:49:05 | gour | Zor: did we meet in D channel in the past? |
| 19:51:05 | Zor | gour: probably |
| 19:52:47 | gour | Zor: heh, so this place is becoming refugees for (un)satisfied D users :-) |
| 19:57:38 | * | gour quit (Quit: WeeChat 0.3.8) |
| 20:11:28 | * | shevy2 joined #nimrod |
| 20:12:31 | * | shevy quit (Read error: Operation timed out) |
| 21:53:48 | * | gradha quit (Quit: gradha) |
| 22:20:40 | Zor | Araq: so, does nimrod have 'ref' (a la c#)? |
| 22:21:11 | Araq | Zor: yes and that's indeed where the interior pointers come from |
| 22:22:08 | Araq | (it's called 'var' in Nimrod though; 'ref' is a traced pointer, 'ptr' is an unsafe/untraced pointer) |
| 22:23:19 | Zor | do you have var returns? |
| 22:23:44 | Araq | yeah and it's still a loophole in the system :-) |
| 22:24:02 | Araq | we will fix it with alias analysis |
| 22:26:17 | Zor | so you cannot take the address of a field in nimrod? |
| 22:26:23 | Zor | other than with var |
| 22:26:37 | Araq | you can with 'ptr' but that's unsafe and not the GC's business |
| 22:26:53 | Araq | the address of operator is called 'addr' and declared to be unsafe |
| 22:27:02 | Araq | this solves many problems :-) |
| 22:27:19 | Zor | heh |
| 22:29:10 | Araq | in fact 'ptr' can be used to easily create weak references |
| 22:29:48 | Araq | so IMO this design is beautiful :D |
| 22:41:26 | dom96 | It's so beautiful I want to marry it. |
| 22:41:57 | Araq | yeah and it'll get more complex with the shared heap :P |
| 22:44:26 | Zor | I've been trying to think of a use case for var returns but I honestly cannot come up with one |
| 22:44:33 | Zor | I've never found myself needing it |
| 22:44:54 | Araq | hash table that returns a modifyable value? |
| 22:45:45 | Araq | the builtin array accessor returns a "var" so to speak |
| 22:46:29 | Araq | in C# it's mitigated by 'class' being a reference type |
| 22:46:46 | Araq | this is not so in Nimrod |
| 22:49:44 | * | FreeArtMan quit (Read error: Connection reset by peer) |
| 22:57:01 | Araq | Zor: how does Rust deal with its different pointer types now? (I'm not up to date) |
| 22:58:12 | Zor | ~ is an owned pointer, everytime you copy a ~ pointer, the pointed-to data is deeply copied (conceptually - the compiler optimizes a lot of cases to not actually copy) |
| 22:58:37 | Zor | * is a plain old pointer |
| 22:58:54 | Zor | @ is a gc'd pointer (currently RC'd, but they want to move to gc) |
| 22:59:15 | Zor | & is a borrowed pointer (I don't know the semantics of these fully, I think Niko has blog posts about them) |
| 23:02:16 | Araq | isn't ~ a pointer that "moves" the data? |
| 23:02:41 | Araq | never heard of a deeply copied pointer before |
| 23:09:46 | Zor | "Copying an owned box is a "deep" operation: it involves allocating a new owned box and copying the contents of the old box into the new box." |
| 23:10:27 | Zor | I'm not sure if copying a local var typed to be ~T to another such var is a copy per se, it might be a move in the current language semantics |
| 23:13:37 | Araq | what is commonly used for argument passing? |
| 23:16:43 | Zor | & is preferred where possible I think |