[Nix-dev] Re: [Nix-commits] SVN commit: nix - 19980 - viric -nix/branches

[Nicolas Pierron]

2010/2/14 Sander van der Burg - EWI <S.vanderBurg at tudelft.nl>:
> 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: nix-dev-bounces at cs.uu.nl namens Lluís Batlle
> Verzonden: zo 14-2-2010 17:28
> Aan: Eelco Dolstra - EWI
> CC: nix-dev at cs.uu.nl
> 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 <e.dolstra at tudelft.nl>:
>> 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
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at cs.uu.nl
> 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.