[plt-dev] EMERGENCY: drscheme no longer works in today's svn head

Maybe it's time to consider either a pure functional or reactive
functional approach to compiled objects?

Pure functional: the object filename includes a hash that uniquely
identifies the computation that produced the object, including hash of
the mzscheme binary and any used library, options, etc.

Reactive functional: the object pathname is explicit enough to
uniquely identifies the computation that may produced the object
starting from other files in the filesystem or pure functional items
as above, including explicit encoded paths or hashs for the mzscheme
binary, libraries, options, etc.

The problem being of course to garbage collect unreachable objects
when you upgrade your PLT installation.

(Didn't Shriram sermon the Lispers for their sin of not believing in
functional programming?)

OK, I promise I won't suggest that anymore unless prompted.

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
In a country where the sole employer is the State, opposition means death by
slow starvation. The old principle: who does not work does not eat, has been
replaced by a new one: who does not obey shall not eat.- Leon Trotsky




2009/8/27 Robby Findler <robby at eecs.northwestern.edu>:
> Sorry -- this was not aimed at you specifically. In this case, I think
> it is going to be tricky to reproduce.
>
> In any case, I think you probably can get away with deleting all
> compiled/drscheme directories in the future if this happens.
>
> Robby
>
> On Thu, Aug 27, 2009 at 6:30 PM, Matthias Felleisen<matthias at ccs.neu.edu> wrote:
>>
>> On Aug 27, 2009, at 7:26 PM, Robby Findler wrote:
>>
>>> On Thu, Aug 27, 2009 at 6:15 PM, Matthias Felleisen<matthias at ccs.neu.edu>
>>> wrote:
>>>>
>>>> I blew away my tree and compiled the whole thing from scratch. All bugs
>>>> disappeared.
>>>
>>> That makes sense to me.
>>>
>>> The trick is to understand how your .zo files got into the wrong state
>>> in the first place.
>>>
>>> One possible issue: DrScheme shares some of its own instantiation of
>>> various modules with the user's program. Perhaps there is some way
>>> that that can confuse CM? Does that seem possible to anyone?
>>
>> I am sorry, but I don't have time for a proper bug report. I am still trying
>> to write a talk -- for which I need a working drscheme.
>>
> _________________________________________________
>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-dev
>