[plt-dev] Re: problem with optimistic compilation

One more thing -- because bugs happen in the application,
implementation or underlying system, I have found that atomicity in
filesystem operations is very useful in avoiding corrupt half-compiled
objects that pollute the build in ways that the user doesn't always
suspect (and therefore spends countless hours chasing).

Lacking a transaction interface to the filesystem from the OS, you can
cheaply achieve atomicity in the creation of object files by first
non-atomically creating an object file with a temporary name (such as
foo.o.tmp or foo.o.tmp-$HOSTNAME-$PID-$TIMESTAMP) and atomically
rename it when it is complete (bonus if you check whether it creates
any change, and abort the new file if no change was necessary - you'll
play much nicer with timestamp-based dependency managers).

In my experience, implementing such a technique is cheap, and leads to
much more robust (and faster) incremental building of large systems.

(I haven't checked, so maybe PLT already does that in which case,
congratulations!)

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
The program isn't debugged until the last user is dead.




2009/8/12 Dave Gurnell <d.j.gurnell at gmail.com>:
>> What if you actively want to use two (or more) different versions of
>> PLT? Say, one for "stable" developments, one for experimenting with
>> the implementation?
>
> I do this a fair bit, and my code is big enough to make compilation a
> practical necessity. I use the mzc && mzscheme solution.
>
> However, there are still some oddities. I have loads of dev links to
> PLaneT packages, and those have to be recompiled too.
>
> Sometimes (not sure what the trigger for this is) mzc doesn't follow the
> dependencies properly and I have to some bytecode nuking to get things
> working.
>
>> If that scenario is probable/supported, then you might still
>> automatically compile, but put the compiled files in directories the
>> name of which identify the implementation.
>
> This is something I'd be very much in favour of. I think it would fix all of
> the above problems.
>
> Cheers,
>
> -- Dave
>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>