[info-mcl] process crash

[Gary Byers]

If anyone's interested in hosting an RMCL svn repository, a compressed version
of the repository that I've been using (in "svnadmin dump" format) is in:

<ftp://clozure.com/pub/rmcl-svn.dump.gz>

On a Unix system, doing something like:

$ gzcat rmcl-svn.dump.gz | svnadmin load

will recreate an svn repository in the current directory; I assume (but don't
know) that the dump file could also be useful to get things set up on Google
Code or similar services.

Most of the text files are set to use CR for line termination, which is what
MPW and (for the most part) MCL of this vintage prefer/require; this generally
means that command-line tools like 'svn diff' generate CR-terminated gibberish;
web-based tools (like you'd find on Google Code) may or may not do a better
job of dealing with CR-termination.

The 'PPCCL' application and some other binary files that contain resource
forks are stored in AppleDouble format (so the resource fork and HFS metadata
are kept in a file whose name starts with "._")

The repository contains a couple of shell scripts named 'postcheckout' and
'precheckin';  these scripts handle splitting/joining AppleDouble files
and set the type/creator fields on MCL and MPW source files.  The 'postcheckout'
script runs an Apple tool that (by "design", if you want to call it that)
recursively descends a directory looking for AppleDouble files to convert;
that tool gets confused by what it finds in .svn directories but doesn't
seem to do any damage there.

All of this is sort of workable but somewhat awkward (mostly because of
the resource fork and line-termination issues), and as I said I honestly
don't know if or how well web-based tools deal with these issues; I suppose
that that likely depends on the tools.

We have funding to Rosetta-ize MCL 5.2 (which actually prefers LF-termination)
so some of these issues will eventually become less prevalent (though they won't
likely disappear completely.)

>From my point of view, it'd be great if someone did want to host and/or administer
a public repository (I'm not too interested in doing either ...), and the ideal
situation for me would be one where I have commit access to that repository but
rarely have to use it ...




On Mon, 3 Aug 2009, Doug Currie wrote:

> I would welcome a pubic repository of the RMCL code.
>
> Assuming that Clozure already has an internal repository, I wonder how this 
> might affect (complicate or facilitate) Clozure's further work with the code, 
> should that happen.
>
> e
>
> On Aug 3, 2009, at 2:02 PM, Alexander Repenning wrote:
>
>> have not done much testing but for the simple cases seems to work. Thanks 
>> Gary!
>> 
>> Would people mind/object/protest/welcome if RMCL would be checked into 
>> Google Code? It would make updating and tracking RMCL (via svn) quite a bit 
>> simpler. I doubt there will be many changes but even just a handful of 
>> updates would be tricky to track as diff fragments distributed in various 
>> emails.
>> 
>> Alex
>
>
> -- 
> Doug Currie, CTO
> Parallel Simulation Technology LLC
> 5 Dartmouth Drive
> Auburn, NH  03032 USA
> Tel. 603-644-4500     main
> Tel. 603-622-3749 x41 direct
>
>
>