2010/2/14 Sander van der Burg - EWI <[email protected]>: > So, what are you guys going to do? Implementing a clean room implementation > of ATerm with the same interfaces or forking ATerm? And if so, why should > this ATerm version developed inside the Nix repository?
Nix does not need ATerm, Nix need maximal sharing to implements maximal laziness. The garbage collection is almost useless because all terms are kept alive in the ATermMap which is used to cache reduce operations. So the garbage collection is just a way to lose some evaluation time. Some manipulations are done to convert data to structure which are easy to manipulate and to structure which are easy to store. These conversions are costly, why don't we just use one data format? What I want to do is to keep the minimal amount of features required by Nix to optimize the code in consequence. For sure optimizing it will break the ATerm API. And as I've experienced a lot of difficulties to debug the ATerm library (due to all the crap that you don't want to understand). We don't have access to their repository. We don't see them interacting with the code. I never got answer from their issue tracker. We can't follow the last version. We need a patch to make it works. They depends on the assembly language. The library is not thread safe. So I consider it as a dead dependency which is not well suited for our usage. If I succeed to make it as I think of it, I will probably take it out of Nix to use it in my work place too. > -----Oorspronkelijk bericht----- > Van: [email protected] namens Lluís Batlle > Verzonden: zo 14-2-2010 17:28 > Aan: Eelco Dolstra - EWI > CC: [email protected] > Onderwerp: [Nix-dev] Re: [Nix-commits] SVN commit: nix - 19980 - viric > -nix/branches > > Hello Eelco, > > I had the feeling that it becomes hard for us to follow the aterm > development. You mentioned about they not accepting your fixes, we > have newer aterm versions provoking segfaults around, either in i686 > and x86_64, ... And so we are meanwhile stuck to an old aterm library. > > As the aterm functionality is not that big, and most of its benefits > rely on its efficiency (correct me if I understood wrong), I thought > that we could have a "slower-but-reliable" implementation of that. > Pierron also got cought by the idea of getting rid of aterm, and being > already two, we decided to start on something. At least, making a > branch. > > Pierron has been thinking on all this the weekend, and he even thinks > that a new implementation can beat the performance of aterm (I assume, > "easily"). I don't know his ideas concrete, maybe whenever he can > commit something, we can keep on talking on this. > > I'm pushing him to get first something api-compatible with aterm, and > then we will see what to do next. > > Do you think we go the wrong way? > > Thank you, > Lluís. > > 2010/2/14 Eelco Dolstra <[email protected]>: >> Llus Batlle wrote: >> >>> Author: viric >>> Date: 2010-02-13 16:27:50 +0000 (Sat, 13 Feb 2010) >>> New Revision: 19980 >>> >>> You can view the changes in this commit at: >>> https://svn.nixos.org/viewvc/nix?rev=19980&view=rev >>> >>> Added: >>> nix/branches/noaterm/ >>> >>> Log: >>> Creating a branch to try to get a nix without aterm. >> >> Can you give some background on this? What is the reason for getting rid >> of it? >> >> -- >> Eelco Dolstra | http://www.st.ewi.tudelft.nl/~dolstra/ >> > _______________________________________________ > nix-dev mailing list > [email protected] > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > > _______________________________________________ > nix-dev mailing list > [email protected] > https://mail.cs.uu.nl/mailman/listinfo/nix-dev > > -- Nicolas Pierron http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/ Lars Rasmussen (Google IO 2009) - Icland is an icland. _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
