<<15-12-2012>>

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:01ZorAraq: still around?
07:40:05*gour joined #nimrod
07:50:05*FreeArtMan joined #nimrod
08:37:57AraqZor: now I'm around
08:40:35gourmorning all
08:40:48Araqhi gour
08:41:29gourwe're missing you yesterday
08:42:21Araqyeah I got this stupid thing called "real life" ... :P
08:42:51gour:-)
08:43:58gouri 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:17gourand thought that maybe i'm simpy dumb :-)
08:45:14Araqwell my advertisement is over, use it or use Ada
08:45:44Araqor Haskell
08:46:08gouri do re-read tut1, and believe nimrod is smaller/nicer language than Ada
08:47:12gouri like FP stuff, but monads are not pragmatic solutions for my use-case and the fact i do notown phd in cs
08:47:43gouri'll try to work on my project wiht nimrod ;)
08:47:53Araqok ;-)
08:49:24gourgot some help here yesterday, and converted part of my header by changing it a bit...got stuff like
08:49:26gourproc swe_calc_ut*(tjd_ut: cdouble; ipl: int32; iflag: int32; xx: ptr cdouble;
08:49:28gour serr: cstring): int32
08:49:57gournow i wonder what is required to be able to call those C functions?
08:50:15Araq#dynlib etc. in the C header
08:53:16gourmy 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:01Araqdepends on the C lib, for simple C libs, I'd use {.compile: "file1.c".}
09:04:14gourok
09:07:41gournimrod'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:29AraqI like FP, but I prefer local state in functions over recursion
09:20:12gourtail call optimization is possible in nimrod?
09:21:35Araqgcc does it
09:21:44goursome algorithms are simply elegant when done recursively
09:22:29Araqthat's not my point
09:22:39gourthat bothered me in haskell, that due to laziness and attempt to have performant code, one loses practically all of it's elegance
09:22:57gourohh...pls. explain?
09:23:25*fowl joined #nimrod
09:23:42Araqpure FP prefers recursion over a simple 'while' loop
09:23:57AraqI prefer the 'while' loop
09:24:13gourahh, yes...no loops in haskell...that's not pragmatic
09:24:20gouri agree with you
09:24:31Araqbut it's all a bit fuzzy since FP abstracts over it immediately and gives you 'fold' and 'map'
09:24:33gourhaskell is purity to the extremes
09:25:01Araqand fold and map are sweet ;-)
09:25:05gourright...and folds and map are cute
09:25:11gour:-)
09:26:58gourso, it's possible to write some nice FP-like code in nimrod?
09:27:18*fowl left #nimrod (#nimrod)
09:28:17gourbased 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:29gour*it's big
09:31:25Araqhard to answer; it's not as small as you think it is, but not big either
09:32:28goursmaller than D2?
09:33:43Araqeverything is :P
09:34:36gourlol
09:37:40gouri 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:52gour(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:00AraqI use aporia and can't think of any feature that geany provides over aporia for nimrod programming
09:50:37gourthat's nice...some docs would be good
09:51:40gournimrod 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:59Araqwe 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:52Araqhi apriori_, I'm still fixing generic converters in '='
11:56:18Araqwhich is what your code does and my test doesn't
12:14:28apriori_hi Araq, ok.. thank you
12:51:16apriori_Araq: found some more issues with overload resolution and "var" types
12:51:57apriori_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:14apriori_1. working on a normal param and returning a normal T
12:52:20apriori_2. working on a var param and returning a var T
12:52:51apriori_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:55apriori_and there is no ambigious cal
12:53:52apriori_if that was too confusing, I might also put that into an example
12:54:05Araqyeah I know about this
12:54:19Araqnot sure it's as useful as you think it is
12:54:33Araqbecause for the 'items' iterator I prefer the read-only view
12:54:52apriori_but what if you want a writable iterator?
12:55:00Araqso we have items for read-only view and 'mitems' for the 'var T' iterator
12:55:04apriori_hm
12:55:26apriori_well...
12:55:28Araqwhere 'm' stands for 'mutable' or 'modifyable'
12:55:35apriori_yeah, I understand
12:56:40apriori_problem is.. I also have the same issue with operator [] for my matrices
12:57:08AraqI know
12:57:09apriori_eigen2/eigen3 "solved" that similar issue by defining coeffRef
12:57:27Araqtables.nim provides [] and 'mget'
12:57:32apriori_that for sure works.. but.. well, just my opinion.. that restriction is somewhat bogus/random
12:58:04Araqwhich is not *that* bad
12:58:17AraqI agree it's not exactly elegant
12:58:36apriori_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:49Araqbut we'll see how the planned 'var T' implicit conversions break
12:59:11Araqoh
12:59:25AraqAST based overloading could be the solution :D
12:59:56Araqyou make [] declare a 'var T' unless the input arg is a 'const' or 'let' :-)
13:00:08Araqs/declare/return
13:00:40apriori_okay, gonna try that..
13:00:53apriori_btw.. did you think about somehow allowing more custom constraints?
13:01:30AraqI ensured you can templatize the constraints
13:01:30apriori_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:58Araqyeah we considered it
13:02:08Araqbut overloading resolution is slow enough as it is
13:02:26Araqand we have other plans for OR
13:02:38apriori_okay
13:02:45gourthere is some some calculus math lib available for nimrod?
13:03:06apriori_gour: nope... I'm still (slowly) progressing with a matrix library
13:03:28gourapriori_: so, nothing for finding zero values etc.?
13:03:45apriori_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:03apriori_gour: you mean numerical functions? nope...
13:04:08*gour just unsubscribed from ada newsgroup if it speaks something to you
13:04:23apriori_yes, ada tells us something
13:04:39gourapriori_: ok, but it seems nimrod is nice language to write such things in it
13:04:51gourapriori_: :-)
13:04:53apriori_gour: it is...
13:05:42apriori_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:01apriori_that elimnated a hell lot of enerving boilerplate
13:07:24apriori_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:39apriori_it could rewrite expressions to more efficient ones using the TR macros etc.
13:08:21apriori_Araq: I really wondered when I found out, that eigen2/eigen3 has something like that, too.. though using c++ expression templates
13:08:40Araqwe know about C++ expression templates
13:08:51Araqand designed TR macros as a superior solution
13:09:01apriori_yup.. they are...
13:09:07apriori_much easier to write
13:09:37Araqyou can implement expression templates in Nimrod too but it's as tedious with types constructing an AST
13:15:16apriori_Araq: does AST based overloading work for generics?
13:15:31Araqcan't see why it shouldn't
13:15:40*gour is going to re-read tut2
13:15:59apriori_gour: note that the tuturial is not as fast updated as the manual
13:16:11apriori_if you really want to dig in further, rather read the manual for all the details
13:17:01gourapriori_: 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:13apriori_gour: which it is :P
13:17:57apriori_Araq: I'm just not quite sure about the syntax
13:18:06gourapriori_: heh, manual usually triggers something more like tutorial or user guide...but, np
13:18:07apriori_say in: proc `[]=`*[M, N, T] (matrix: var TMatrixNM{lit}[M, N, T], a: M, b: N, v: T)
13:18:14Araqnope
13:18:31Araqit's tmatrix[m,n,t]{lit}
13:18:53apriori_vector.nim(54, 53) Error: type expected
13:18:55apriori_in that variant
13:18:59apriori_proc `[]=`*[M, N, T] (matrix: var TMatrixNM[M, N, T]{lit}, a: M, b: N, v: T) =
13:19:10gourD says it easy to be picked by Java/C(++) programmers...what could be said for Nimrod? python/pascal/...?
13:19:23Araqhrm, may be an oversight of mine, apriori_
13:19:44apriori_gour: well.. nimrod is indeed a bit different
13:19:56Araqgour: nimrod is easy for everybody until you figure it's not ;-)
13:20:03apriori_gour: thouh I think, people understanding basic templatisation will understand nimrod better..
13:20:20apriori_gour: therefore I'd say, java programmer would have the most problems with it
13:20:33Araqand then after months people come back and thank me ;-)
13:20:44gourapriori_: i was using C++ when it does not have templates...if anyone of you heard about zortech c++
13:20:46apriori_yup.. we did :)
13:20:59apriori_gour: nope, don't know about that
13:21:09apriori_ah
13:21:16*gour never touched, fortunately, java
13:21:16apriori_the digital mars compiler..
13:21:35gouryeah, its author is now pushing D
13:21:53apriori_yup.. we know about D..
13:21:56Araqok, ok, I got a single user who thanked me after months :D
13:21:58apriori_and its.. "marketing"
13:22:19gourAraq: where is this user?
13:23:01Araqgour: http://forum.nimrod-code.org/t/100/1
13:23:11apriori_Araq: an oversight.. so it's not implemented?
13:23:15Araq"adrianv"
13:23:37Araqapriori_: it's likely a 1 line fix, let me have a look
13:24:32gourmaybe i should consider joining to improve Araq's karma...although i really prefer mailing lsits/newsgroup
13:30:42Araqah apriori_ the problem is the 'var T' here
13:30:54Araqyou have to use (var xyz){lit}
13:31:03apriori_ah, ok
13:31:04apriori_tying
13:36:04gourtut2- 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:07apriori_Araq: k, seems to work
13:36:34Araqgour: for rec types only
13:37:37gourAraq: ta
13:38:55AraqI have to go, see you later
13:38:59apriori_Araq: bye
13:39:03apriori_and thanks
13:39:28Araqno, I have to thank you for helping to get the math part of the stdlib done
13:39:36apriori_some day ^^
13:39:46Araqor at least playing with it ;-)
13:40:00apriori_at the very minimum I stress the hell out of your compiler :P
13:40:16Araqyeah I noticed ;-)
13:40:17gouris there any helper lib for marshalling between C <---> Nimrod ?
13:40:35apriori_gour: be more precise please
13:40:39Araqgour: there is no marshalling needed most of the time
13:40:42Araqbye
13:40:43apriori_you can wrap (import) c strucs right away
13:40:48apriori_*structs
13:41:57gourapriori_: 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:40gour(to avoid or-ing integer flags...)
13:42:47apriori_yes, i understand
13:43:20gourin haskell i'd first provide just C wrapper and then higher-level haskell-ish API
13:43:27goursimilar in nimrod.
13:43:30apriori_that works in nimrod, too
13:43:39apriori_https://github.com/apriori/nimCL/blob/master/cl/cl_ext.nim
13:43:42apriori_see that for example
13:43:58apriori_that was mostly automatically constructed by c2nim from the header files
13:44:53apriori_so you can wrap a c routine using the usual types
13:45:09apriori_for c specifically there exists cint, cstring etc.
13:45:57gourrequired C lib is simplas as far as types are concerned...
13:45:58apriori_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:31gourhow are you happy with c2nim?
13:46:43apriori_well, it does some decent job
13:46:54apriori_for some cases it's not that useful..
13:46:58apriori_but it will save your a lot of time
13:47:02apriori_*you
13:47:39*gour notices apriori_ has some D-stuff-related-repos ;)
13:47:52apriori_e.g. in my case OpenCL defines "shitloads" of constants via C macros..
13:48:10apriori_and really wasn't too happy thinking about porting those over manually.. c2nim did just that..
13:48:19apriori_especially, if you're new to nimrod, it helps
13:48:31apriori_e.g. if you didnt quite know about shl for shift left etc.
13:48:39apriori_gour: and yes, I did some D stuff before
13:48:43apriori_but I'm no longer happy with D
13:48:46gouryeah, my lib aslo has bunch of #defines which we want to put in sets
13:49:04apriori_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:45apriori_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:26apriori_well, I learned a lot (especially, to hate java, which I have to use at work, even more) using nimrod
13:50:48apriori_in java I constantly miss the macros and templates nimrod has.. to fight boilerplate
13:50:56gourfor type-safety, i'd like to break all thsoe #defines into specific sets 'cause they (un)set quite different options
13:51:07apriori_yeah, easily doable
13:51:40apriori_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:41gouri never did templates in C++, in D they seem a bit convoluted...same for macros 'cause never did any lispy language
13:52:02gourwhich editor you use'
13:52:05gour?
13:52:14apriori_it will take some time, till you get used to all the "fancy" features
13:52:22apriori_aporia, a project by dom96
13:52:40apriori_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:02apriori_https://github.com/nimrod-code/Aporia
13:53:12*gour already built aporia :-)
13:53:16apriori_hehe, ok
13:53:21apriori_and yes, I agree
13:53:45apriori_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:46gourthere should be debian/ubuntu/fedora packages
13:54:14apriori_frankly.. users that are not even able (or more: lazy) to build the compiler are not that useful either right now
13:54:16gourapriori_: well, i plan to use nimrod for very concrete multi-platfrom gui project
13:54:31apriori_but I understand.. it would lower the barrier to actually start using nimrod
13:54:36gourwith geeks only, it won't have much users
13:55:33apriori_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:57apriori_I felt geekish then.. although I just didnt get it :P
13:56:01gourstrange...python has it for quite some time
13:56:09apriori_even C# has it
13:56:14apriori_afaik
13:56:29gourdunno C#
13:57:59apriori_gour: I really recommend you get familiar with templates at some time
13:58:18gourapriori_: for generic programming?
13:58:25apriori_far more than that
13:58:39apriori_say... you got a code snippet..
13:58:45apriori_which is used over and over again..
13:58:47gournow ican only think about that
13:59:02apriori_its somewhat identical, but not exactly identical.... templates can help with that
13:59:22apriori_because in nimrod you can actually pass expressions to a template
13:59:32gournot identical in terms of parameters, types or something else'
13:59:33apriori_not only types, or type instances
13:59:34gour?
13:59:51apriori_giving an example
14:00:24apriori_https://gist.github.com/4295271
14:00:34apriori_that's generic on operator level
14:00:45apriori_of course one could also use closures/function parameters for that
14:01:00apriori_notice in the template, the call to "op"
14:01:42gourinteresting
14:01:58apriori_and you also see
14:02:04apriori_the templates gets the entire contest of the function
14:02:08apriori_all variable defintions etc.
14:02:25apriori_*context
14:02:27apriori_not contest :P
14:02:46gour:-)
14:03:30gouryou know haskell and type-classes?
14:03:39apriori_I know haskell... a bit at least
14:03:57apriori_and yeah, also about type classes
14:04:40gournimrod has, btw, very beautiful syntax
14:04:52apriori_yup, I like it too ;)
14:05:12apriori_gour: btw, a tr macro
14:05:14apriori_template optimizeCrossOfSameVector*{cross(a, a)}(a: expr) : expr = cast[type(a)]([ 0, 0, 0 ])
14:05:34apriori_although definetly not the prefered usage for TR macro, because those should not change semantics
14:05:59gourmacros is another thing we have to wrap our mind around
14:06:06apriori_one could better use ast based overloading now, to properly implement that
14:06:16apriori_macros will get some time to get used to
14:06:25apriori_but see them as code generators
14:06:40apriori_within the boundaries of the nimrod syntax, you do some wicket stuff with it
14:06:48gouri'd like to some more FP techniques in nimrod than oop stuff
14:07:09gours/some/use some
14:09:06apriori_gour: btw: https://github.com/fowlmouth/nimlibs/blob/master/macros/classlib.nim
14:09:40apriori_see that as an example.. scroll down to the part after "when isMaiModule" to see examples of the usage of the macros
14:11:58apriori_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:19gourmind-blowing
14:40:26apriori_gour: something like type classes should actually be possible in nimrod
14:40:56apriori_with macros that define templates.. e.g. for the operations in the type class instance
14:40:56gouri'm reading about generics in tut2 now
14:41:30gouri've to come to macros yet
14:41:36apriori_take your time ^^
14:49:35apriori_dom96: do you happen to be here?
14:49:46dom96yep.
14:49:51dom96What's up?
14:49:55apriori_I've got a short question
14:50:02apriori_assuming you call a macro:
14:50:06apriori_someMacro blub, moep:
14:50:08apriori_var test = 1
14:50:40apriori_is it possible to get the params blub, moep only in the macro, without defining a terminating element for the arglist?
14:50:59apriori_like.. distinguishing actual calling args and "passed in body"
14:53:04dom96hrm,
14:53:17dom96someMacro (blub, moep): ...
14:53:27apriori_dom96: with variable arg list?
14:53:28dom96(blub, moep) # -> This is now one param.
14:53:37dom96I'm not sure if that works actually
14:53:50apriori_the static param style works
14:54:04fowlapriori_: callsite()
14:54:23apriori_fowl: callsite seems to include all
14:54:27apriori_which is not what I want
14:54:39apriori_callsite includes blub, moep and the var section statement
15:01:55apriori_hrm
15:02:08apriori_varargs might work.. but I got no clue how to iterate over a varargs[expr]
15:02:19apriori_it doesnt seem to have items defined
15:02:42apriori_someExpr.len seems to be right.. but then someExpr[i] not
15:02:50gourbefore nimrod, did you use some other language from the category of 'obscure' ones?
15:03:05apriori_gour: nope.. unless you include D
15:03:40gourapriori_: heh, not sure what would D users say about it :-)
15:03:50apriori_gour: they would likely yell :P
15:04:09gouror create >100posts thread about it
15:04:50gourbtw, are you happy with forum or any interest for mailing list (possibly subscribed to gmane)?
15:05:20apriori_I'm not really representative there.. but I prefer IRC/forums
15:05:33apriori_mailing lists tend to get.. cluttered and unorganized
15:06:02gouri prefer nntp..automatic archive ,easy following, threading, etc.
15:06:11dom96apriori_: You should create a blog post saying exactly why you're using Nimrod instead of D. :P
15:06:14gourforums are, imho, pain to follow
15:06:23Araqapriori_: 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:31apriori_dom96: or I shouldn't.. because I dont want to deal with the shitstorm ^^
15:06:43apriori_Araq: completely agreed
15:07:35apriori_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:26apriori_gour: agreed on the follow, yes
15:10:08*gour notices that even felix has ml
15:12:43apriori_Araq: could you give a hint on how to iterate over varargs[expr]?
15:14:16AraqI have no idea :-)
15:14:25apriori_ok
15:14:29Araquse 'callsite' to iterator over that
15:14:35Araq*iterate
15:14:51apriori_yeah, guess I can only define a terminating element then
15:15:09Araqhu?
15:15:12apriori_to distinguish the params.. and the body param
15:15:23apriori_I'd like to distinguish in:
15:15:29apriori_someMacro blub, moep:
15:15:31apriori_someBody
15:15:43apriori_the body and the both (variable count) params
15:15:45Araqwell callsite[-1] is the body
15:16:06apriori_hm
15:17:01apriori_index out of bounds ^^
15:17:45apriori_I didnt really expect something else :P
15:18:43Araqyou're in a macro, right?
15:18:47apriori_yes
15:19:20apriori_I just wanted to write a "search and replace" macro
15:19:49Araqhrm, I could swear macros.`[]` supports a negative index... :D
15:20:01Araqmaybe only in my dreams ...
15:20:15apriori_trying to deactivate bound checks
15:20:18Araqlet x = callsite(); x[x.high] should work though
15:20:32Araqyou can't deactivate bound checks for compile time code
15:20:38apriori_ok
15:20:45fowlx.len - 1
15:21:46apriori_well, you assume the body is always only one statement
15:21:53apriori_problems start, if that's no longer the case
15:22:14Araqyou need the 'do' notation to pass more than 1 block
15:22:16fowlapriori_: the body should be wrapped in nnkDo
15:24:16apriori_ok
15:28:41dom96fowl: nice job on the csfml particles demo, very cool.
15:29:20gradhaAraq: 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:36AraqI already did
15:30:23Araqcheck out the undocumented feature that the opengl wrapper uses ;-)
15:33:11fowldom96: thanks
15:33:41dom96fowl: btw i'm making a game for ludum dare and using your sfml wrapper.
15:35:29fowlcool
15:39:14gradhaah, so there where a few hours left for yesterdays log
15:40:08*zahary joined #nimrod
15:42:46Araqzahary: in your example the param was an interior pointer but on stack
15:43:01Araqthe pointer itself is on the stack
15:45:39Araqthat said, the implicit 'const&' parameter passing mode causes some problems; can't see any better solution though; C
15:46:09Araq++ is more verbose about it but that's it
15:47:14apriori_gotto go guys
15:47:15apriori_bye
15:47:17apriori_*gotta
15:47:21*apriori_ quit (Quit: Konversation terminated!)
15:48:25zaharysorry, I lost my connection the other day. my example was that it's still possible to have memory corruption in such situations
15:49:17Araqyeah and we should find a solution
15:49:30zaharyI 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:58zaharythis can lead to hard to find bugs, but it can't corrupt memory
15:50:19Araqwhy not set the deallocated pointers to 'nil' instead in the GC?
15:50:56zaharyhow will that help? just changes the nature of the latent bug
15:51:15AraqI consider aliasing into a sequence that you setLen to 0 an edge case
15:51:50zaharyI 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:53Araqso ensuring the programmer's code crashes should be enough (?)
15:53:42Araqand I consider D worse than nimrod as its type system doesn't distinguish ptr from ref, nor array from seq
15:54:05Araqbut alright, I'll be more humble again ;-)
15:54:06zaharyexplicit GC pointers are nice, yes
15:57:38Araqin fact, the GC should set these pointers to 'nil' only in debug mode
15:58:04zaharyyou mean the contents of the buffer, right?
15:58:18zaharyor stack pointers I detect?
15:58:52Araqthe 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:16Araqyou had a seq[object] and then aliased into that via parameter passing
15:59:30Araqand then deallocated that sequence explicitly via setLen
15:59:37zaharyyes
16:00:02Araqyou need to do:
16:00:19Araq var y = param # keep alive
16:00:23Araq setLen(s, 0)
16:00:28Araq use(y)
16:01:08Araqand need to somehow make the programmer aware of it in debug mode
16:01:20Araqimo the GC doesn't need to keep it alive longer per se
16:01:50Araqor maybe we need an assertion in setLen
16:02:21zaharyI don't quite follow. which pointer you think I'll be able to set to nil? the param?
16:03:25zaharymy other idea was to protect the page in debug builds and intercept reads into it
16:03:36zaharythe page of the deallocated buffer
16:03:46Araqthe GC'ed memory inside the object that param points to
16:04:39zaharyalright, the contents of the buffer. I can do that, maybe even 0xCC will be a better value
16:04:59Araqbut I'm assuming a pointer within this object is the problem and not the sequence itself
16:06:19Araqwhich is not the case. hm.
16:06:41Araqthe allocator already has the option 'overwriteFree' btw
16:07:14Araqin mmdisp.nim, dunno if you're aware of it
16:07:51zaharyeven 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:44Araqbut the interior pointer already keeps it alive
16:08:54Araqit's just that either a) setlen is buggy
16:09:18Araqor b) the problem is really another GC'ed pointer within the object
16:10:30zaharyno, it doesn't. the old code was deallocating the memory straight away
16:10:42zaharythis is growObj in gc.nim
16:16:46Araqok, but growObj is only called from setlen I think
16:18:40Araqalright so growObj calls 'rawDealloc' when it really shouldn't
16:19:08Araqbut well, seqs are value-based
16:19:28Araqso the asumption was there can't be aliases to it left
16:19:42Araqit grows the sequence, can't do that so needs to reallocate
16:20:07Araqand frees the old buffer since 'setLen' takes a 'var' and so does 'add'
16:21:04zaharyare you explaining the problem to yourself or you're trying to explain something to me?
16:21:20Araqto myself and see if you disagree :D
16:26:22zaharyalright, 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:32dom96fowl|asus: seems declaration of newTexture*(filename: cstring ... is wrong, should have a area: PIntRect param too.
16:27:46fowl|asusdom96: csfml uses C/SFML 2.0 from HEAD, not the rc
16:27:49Araqproblem is 'unsafeNew' breaks ropes.nim in a very weird way
16:27:50zaharywe could reuse the openarray "type" to make the intention more explicit
16:27:50zaharytype sequence[T] = object
16:27:50zahary len: int
16:27:50zahary data: openarray[T]
16:28:14Araqand I haven't found the time to debug it
16:28:29zaharywhat do you know about the problem so far?
16:29:00zaharyI'll have trouble merging ropes.nim, because I have non-trivial local modifications too
16:29:19Araqit produces .c code where every literal has its length appended as its *ascii* representation
16:29:20fowl|asusdom96: do you mean this one: proc newTexture*(image: PImage, area: PIntRect = nil): PTexture {.cdecl, importc: "sfTexture_createFromImage", dynlib: LibG.}
16:29:43fowl|asusdom96: oh nvm i see it
16:30:07Araqso it produces: 4leng1(4int 1a)
16:30:12Araqor something like that
16:30:23gourD has structs and classes providing different semantics and performance trade.ofs...what is nimrod's equivalent for structs?
16:30:24Araqwhich btw puts GCC into an endless loop apparently
16:30:37Araqgour: 'object' or 'tuple'
16:31:25gourAraq: i wonder about tuple due to having ordered fields and if there is some performance issue to just use object?
16:31:49fowl|asusdom96: just pushed a fix
16:32:17Araqgour: object is a nominal type, tuple is a structural type, the overhead is 0 in any case unless you use inheritance
16:32:19dom96thanks. btw it might be a good idea to get rid of line 1004.
16:32:39gourAraq: great
16:34:01fowl|asusdom96: why?
16:34:34dom96fowl|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:52Araqzahary: reusing the openarray type is not a bad idea; it will ultimately cause problems because you can then do: obj.data = someParam
16:36:54fowl|asusdom96: better they find out sooner than later
16:37:23Araqso we need to allow assignment for openArray and allow openArrays in other places
16:37:54zaharyit could be superficial, tyOpenArray is replaced with something as soon as you parse the type
16:38:14Araqyeah, otherwise it will be buggy for years
16:38:48dom96fowl|asus: well alright, it's your choice
16:40:09fowl|asusthere 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:12Araqso ... I'd like to allow growObj to dealloc
16:41:43Araqbut then overwriting the memory doesn't help
16:42:03Araqanother alloc could come along in the meantime and re-use that block of memory
16:42:38zaharywell, keep on repeating what I said 10 minutes ago :P
16:43:50zaharyI 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:21zaharyyou remember my checkpoint allocator, right? I've used it for similar purposes in C++ for years
16:46:37Araqsorry, I don't remember :P
16:47:29Araqbtw 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:04zaharyit's bump pointer allocator with checkpoints
16:49:04zaharywhen you enter the function you do
16:49:04zaharyvar 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:38Araqwhat's a checkpoint?
16:49:48zaharywe also use with non-scoped checkpoints "throw everything since the last rendered frame"
16:49:57zaharymaybe you remember this description
16:50:01Araq*what exactly is the checkpoint in this setting?
16:51:19zaharythe *checkpoint* is the place you get the current position of the bump pointer allocator (the top variable)
16:52:17Araqalright, I was wondering if it maybe refers to the implicit 'finally: setback()' that C++'s RAII provides you with
16:54:56dom96fowl|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:36Araqwell the fix looks much easier to me, zahary
16:59:46Araqno need for any special logic
17:00:00Araqjust keep the old seq in the ZCT and don't dealloc it
17:00:18gourmanual says: "Unfortunately, d + 12.TDollar is not allowed either, because...", but we consider it is "fortunately" :-)
17:00:38zaharyyou don't read my messages, do you? :P
17:01:02Araqlet me check ...
17:01:07zaharyto quote myself:
17:01:07zaharyI 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:07zaharythis can lead to hard to find bugs, but it can't corrupt memory
17:02:51Araqyeah, well, I read it
17:02:57Araqbut got it only now :P
17:03:14AraqI thought that you put in some special logic for this case
17:03:30Araqlike a "checkpoint" allocator :P
17:03:42zaharyas usual, I've eaten some words :) it should be *where the sequence/string is deallocated*
17:04:07zaharythe checkpoint allocator is for speed
17:04:23zaharyvery fast allocations and noop deallocations
17:04:51zaharyit's safe only for dumb buffers tho - these that don't have ref pointers into them
17:06:13zaharyin C++, I've also gathered statistics that over 90% of the time you can grow a string or vector buffer "in-place"
17:06:58zaharythis is possible when there are no other allocations in between the reallocs
17:06:58zaharyhappens when you append to a string for example in a loop
17:07:38Araqyeah I know
17:07:41fowl|asusdom96: i could branch it for 2.0 RC maybe
17:07:58Araqbut 90% is suprising
17:08:28Araqwhenever you generate something more complex like a .c file (different sections) it can't work that well
17:08:31zaharywell, depends on the application I guess. after all, in C++ I manually choose the places where to use the allocator
17:08:54gradhaI'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:32Araqgradha: sounds like a bug
17:09:39zaharywell, 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:13zaharyalso, it's useful only for stack bound strings as I said
17:10:26zaharythe ropes in cgen won't qualify to use it
17:10:41zaharyi.e. the proc sections, etc
17:10:49dom96fowl|asus: that might work
17:11:08AraqI thought about generating a C AST instead of the ropes
17:11:33Araqyou can do some transformations on that then
17:11:43Araqand the ropes are already very expensive trees
17:11:52zaharyit's quite a lot of work
17:12:04Araqunfortunately yes
17:12:22Araqand 'emit' means we don't have the full C AST around
17:13:16Araqthe ropes are fundamentally unfixable though
17:13:34Araqthanks to them being immutable you can't really change the API
17:13:45Araqwithout breaking lots of code
17:13:55zaharythe API of what?
17:20:39Araqthe API of ropes.nim
17:23:36zaharyI told you about my compile-time rope formatting attempt, right?
17:23:36zaharyI was able to transform expressions like linecg(module, "$1 = $2", a, b) into line(concat(a, glovalVarHavingTheValue(" = "), b))
17:23:52Araqyeah I remember
17:24:12zaharyunfotrunately, it's a net loss for the compiler itself
17:24:28Araqhow so? :D
17:24:46Araqkeeping the ropes alive doesn't help locality?
17:25:41zaharyfor 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:58Araqah yeah, bootstrapping
17:26:40zaharyshould 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:52Araqimproving evals.nim is suprisingly hard
17:27:08AraqI thought about a proper bytecode VM
17:27:34Araqbut it's a lot of work; especially since you want to get nice stack traces and introspection capabilities
17:27:51Araqthe AST evaluation gives all that for free
17:27:58zaharyyes, sounds like a lot of work.
17:30:40Araqfor a start, we really need pack and unpack primitives to transform an AST-based value into a packed C-compatible value
17:31:54zaharyI 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:00zaharyattached
17:32:49Araqthe packed form can't work on the ASTs easily
17:33:46zaharywhat do you mean?
17:35:16Araqmacros.`[]` is a built-in which relies on evals.nim working on ASTs
17:35:24Araqnot on bytes
17:35:56Araqnothing that can't be solved though
17:40:07zaharyI 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:35zaharyand 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:28Araqaha, I see
18:06:43*gour now knows there is asm keyword in nimrod
18:30:16gradhadoes 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:43Araqgradha: the 'marshal' module?
18:33:45gradhathe restriction means I have to detect the version of the object or it would load incorrectly?
18:37:36Araqthe restriction means you can't use inheritance with it
18:38:07Araqwell you can, but ensure that you know the real type
18:38:25Araqand not some sub/supertype
18:38:51gradhaah, ok, because I was reading now the code and it seems to save key/value, so adding/removing fields should work
18:39:15Araqit saves as json, yeah
18:39:30Araqand of course, feel free to improve it
18:39:38Araqlooks hard to do though :P
18:39:50Araqand I think even C# has the same restriction
18:44:21Araqhowever, ignoring missing values should be easy to implement
18:51:39ZorAraq: do you disallow interior pointers in nimrod?
18:52:01AraqZor: pretty much yes
18:53:07Zorany particular reason why?
18:53:47Araqour write barrier is already expensive enough
18:54:30Zorwhat do you use a write barrier for exactly?
18:54:55Araqincremental GC
18:55:20Araqcan't think of any efficient GC algorithm that doesn't either require a write or a read barrier
18:55:45Araqand a read barrier looks very troublesome
18:56:09AraqAzul does that but they had to implement hardware support for it
18:56:32AraqI'm not aware of any other GC in production that uses a read barrier
18:56:58*comex joined #nimrod
18:58:19AraqNimrod's GC is based on reference counting, Zor; copying collectors often use card marking in the write barrier instead
18:58:38Araqwhich is likely to be cheaper
18:58:50Araqand I think interior pointers are not that much of a problem for card marking
18:58:59Zorright, I'm curious what you use the write barrier for in a reference counting scheme
18:59:16ZorI know how most other algorithms work, just not really familiar with RC
18:59:49Araqa = b
18:59:53Araqbecomes:
19:00:03AraqdecRC(a)
19:00:08AraqincRC(b)
19:00:10Araqa = b
19:00:24Araqthat's called the write barrier
19:04:56*comex quit (Remote host closed the connection)
19:04:58ZorI assume you only insert dec/inc calls when you statically know that you're dealing with an RC'd type
19:05:14Araqexactly
19:05:54Zordo the dec/inc barrier calls check for null?
19:06:01Araqand there are quite some optimizations applied to reduce the cost
19:06:14Araqthey do check for null, yes
19:06:34Araqwe'll optimize that away too some day
19:07:50*comex joined #nimrod
19:08:25Zorwhat do your object headers look like?
19:08:45AraqRC + some bits in the same word + type info word
19:09:40AraqI planned some "chunk GC" which would require a type info word only per 64K chunk
19:10:12Araqbut dunno if I'll ever find the time to implement that idea
19:10:56ZorI don't think a type info word is going to be the end of the world anyway
19:12:57Zorso how do you optimize insertion of write barriers? some kind of liveness analysis?
19:16:50Araqa 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:51Araqsince 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:28AraqZor: search for "Deferrent Reference Counting", Deutsch-Bobrow garbage collector and Christoper's partial mark-sweep garbage collector
19:24:50ZorI can't seem to find the latter
19:25:35Araqpython's GC implements it
19:26:05Araqthere was a good description about it somewhere; it's cycle collection for when you already have reference counts
19:27:21Araqhttp://arctrix.com/nas/python/gc/
19:49:05gourZor: did we meet in D channel in the past?
19:51:05Zorgour: probably
19:52:47gourZor: 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:40ZorAraq: so, does nimrod have 'ref' (a la c#)?
22:21:11AraqZor: yes and that's indeed where the interior pointers come from
22:22:08Araq(it's called 'var' in Nimrod though; 'ref' is a traced pointer, 'ptr' is an unsafe/untraced pointer)
22:23:19Zordo you have var returns?
22:23:44Araqyeah and it's still a loophole in the system :-)
22:24:02Araqwe will fix it with alias analysis
22:26:17Zorso you cannot take the address of a field in nimrod?
22:26:23Zorother than with var
22:26:37Araqyou can with 'ptr' but that's unsafe and not the GC's business
22:26:53Araqthe address of operator is called 'addr' and declared to be unsafe
22:27:02Araqthis solves many problems :-)
22:27:19Zorheh
22:29:10Araqin fact 'ptr' can be used to easily create weak references
22:29:48Araqso IMO this design is beautiful :D
22:41:26dom96It's so beautiful I want to marry it.
22:41:57Araqyeah and it'll get more complex with the shared heap :P
22:44:26ZorI've been trying to think of a use case for var returns but I honestly cannot come up with one
22:44:33ZorI've never found myself needing it
22:44:54Araqhash table that returns a modifyable value?
22:45:45Araqthe builtin array accessor returns a "var" so to speak
22:46:29Araqin C# it's mitigated by 'class' being a reference type
22:46:46Araqthis is not so in Nimrod
22:49:44*FreeArtMan quit (Read error: Connection reset by peer)
22:57:01AraqZor: how does Rust deal with its different pointer types now? (I'm not up to date)
22:58:12Zor~ 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:37Zor* is a plain old pointer
22:58:54Zor@ is a gc'd pointer (currently RC'd, but they want to move to gc)
22:59:15Zor& is a borrowed pointer (I don't know the semantics of these fully, I think Niko has blog posts about them)
23:02:16Araqisn't ~ a pointer that "moves" the data?
23:02:41Araqnever heard of a deeply copied pointer before
23:09:46Zor"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:27ZorI'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:37Araqwhat is commonly used for argument passing?
23:16:43Zor& is preferred where possible I think