[Openmcl-devel] *initial-process* and *current-process*

[Gary Byers]

On Fri, 24 Jun 2011, Gabriel Dos Reis wrote:

> On Thu, Jun 23, 2011 at 8:26 PM, Gary Byers <gb at clozure.com> wrote:
> [...]
>> The set of per-thread bindings (STANDARD-INITIAL-BINDINGS) may change from
>> release to release; changes that involve public variables should be (and
>> generally have been) documented.
>>
>> The general model of how dynamic bindings work hasn't changed in a
>> very long time (CCL has never really implemented another model), and
>> this model is likely to be either very similar to in most respects or
>> identical to that used in other implementations in its observable
>> behavior. ?The set of things that're automatically thread-local is
>> probably larger in CCL than in other implementations and there may be
>> a stronger relationship between the bindings in effect in the creating
>> thread and those established in the created thread in other
>> implementations than there is in CCL. ?(In CCL, there's essentially no
>> such relationship.)
>
> In concrete terms:


>  1.  I installed CCL-1.6 in a separate directory (/tmp/ccl-1.6/), which its
>       script driver  /tmp/ccl-1.6/ccl.
>
>  2. I checked out the 1.4.x branch of OpenAxiom:
>      svn co https://open-axiom.svn.sf.net/svnroot/open-axiom/1.4.x oa.svn
>
>  3. I configured OpenAxiom with CCL-1.6
>       mkdir oa.build    ## sibling to oa.svn
>       cd oa.build
>        ../oa.svn/configure --with-lisp=/tmp/ccl-1.6/ccl
>        ## lot of configure outputs
>        make all-boot   ## finishes normally
>
>     b. I configure afresh OpenAxiom with CCL trunk like above but with
>             --with-lisp=/tmp/ccl.svn/ccl
>         make all-boot  ## fails.
>
> I've looked at all the possibilities.  The symptoms are as I described
> before: SAVE-APPLICATION only saves the "prior state" of the global
> special variables, not the values they have at the time of SAVE-APPLICATION
> (as does CCL-1.6.)
>
> This is on an x86-64 running openSUSE-11.3 (I doubt the linux brand matters).
> Are you able to reproduce the success with CCL-1.6 and the failure with
> CCL-trunk?
>
> -- Gaby
>
>

Yes.  At the point at which things seem to differ (where the trunk lisp starts
failing), the make output looks like:

### this is the 1.6 output:
../../src/driver/open-axiom --execpath=../lisp/lisp --make --main="|AxiomCore|::|topLevel|"\
 		--system=../../x86_64-unknown-linux-gnu \
 		--prologue='(pushnew :open-axiom-boot *features*)' \
 		 --output=strap/bootsys --load-directory=strap strap/initial-env.lx64fsl strap/utility.lx64fsl strap/tokens.lx64fsl strap/includer.lx64fsl strap/scanner.lx64fsl strap/pile.lx64fsl strap/ast.lx64fsl strap/parser.lx64fsl strap/translator.lx64fsl
../../src/driver/open-axiom --execpath=strap/bootsys --translate --import=skip --output=stage1/utility.clisp ../../../oa.svn/src/boot/utility.boot
../../src/driver/open-axiom --execpath=../lisp/lisp --output=stage1/utility.lx64fsl --compile --load-directory=stage1 stage1/utility.clisp
../../src/driver/open-axiom --execpath=strap/bootsys --translate --import=skip --output=stage1/tokens.clisp ../../../oa.svn/src/boot/tokens.boot

### and this is the equivalent output where the trunk CCL was used:

../../src/driver/open-axiom --execpath=../lisp/lisp --make --main="|AxiomCore|::|topLevel|"\
 		--system=../../x86_64-unknown-linux-gnu \
 		--prologue='(pushnew :open-axiom-boot *features*)' \
 		 --output=strap/bootsys --load-directory=strap strap/initial-env.lx64fsl strap/utility.lx64fsl strap/tokens.lx64fsl strap/includer.lx64fsl strap/scanner.lx64fsl strap/pile.lx64fsl strap/ast.lx64fsl strap/parser.lx64fsl strap/translator.lx64fsl
../../src/driver/open-axiom --execpath=strap/bootsys --translate --import=skip --output=stage1/utility.clisp ../../../oa.svn/src/boot/utility.boot
../../src/driver/open-axiom --execpath=../lisp/lisp --output=stage1/utility.lx64fsl --compile --load-directory=stage1 stage1/utility.clisp
> Error of type FILE-ERROR: File #P"stage1/utility.clisp" not found
> While executing: CCL::FCOMP-FIND-FILE, in process toplevel(2).

e.g., it looks like the command before the last one was expected to create
stage1/utility.lisp but failed to do so.  I don't know why (or even have
a good idea of where to look), but hopefully we're  both seeing the same
thing.

I don't know whether the global special variables that you see as having
unexpected values are application-specific, standard CL/CCL things, or some
mixture.  The only post-1.6 change to code related to SAVE-APPLICATION
that I can think of might cause the user-specified toplevel-function to
run with (ordinarily) slightly different values for some of the standard
steam variables (*TERMINAL-IO* and some other things that're SYNONYM-STREAMs
to it.)  Are these variables among those that have unexpected values ?