[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Axiom-developer] _*STANDARD_-OUTPUT_* and similar

From: Bill Page
Subject: RE: [Axiom-developer] _*STANDARD_-OUTPUT_* and similar
Date: Fri, 8 Oct 2004 00:20:09 -0400


These symbols with _ look like standard Axiom escapes to
me. In Axiom (starting probably at the bootsys level)
the underscore character acts the same as the \ in C.
I am quite surprized therefore that your change to the
g-error.boot.pamphlet code, removing the _ even compiles
at all. In the bootsys language (as in the Axiom language

 *STANDARD-OUTPUT* : fluid := $texOutputStream

should be a syntax error because of the unescaped special
symbols appearing on the left.

 ... hmmm.

I would look for reasons why the _ are apparently not
being interpreted properly as escapes.

And I'm really glad you are back looking at Axiom on
Windows! It is entirely resistant to my feeble attempts
to figure it out!

Bill Page.

On Thursday, October 07, 2004 10:34 PM Mike Thomas wrote:
> Hi Tim.
> I spent some time this morning on Windows Axiom with 
> particular reference to the sometimes on, sometimes off
> problem with compiling AHYP.spad:
> --------------------------------------------------------------
>    initializing NRLIB AHYP for ArcHyperbolicFunctionCategory
> The syntax of the command is incorrect.
> Error: equal: x is a NULL pointer
> Fast links are on: do (si::use-fast-links nil) for debugging
> Error signalled by RETURN.
> Broken at APPLY.  Type :H for Help.
> BOOT>>
> --------------------------------------------------------------
> There are a couple of problems here:
> 1. interpsys thinks that the syntax of some command or other 
> is incorrect,and
> 2. the error system ends up with a NULL pointer in the GCL C code.
> I managed to isolate problem 2 to a simple case: evaluating 2*y
> at the interpsys prompt, which in my incomplete system leads 
> immediately to an attempt to load the as yet uncompiled polynomial
> domain code in POLY.o, hence an error and then the NULL pointer.
> I then found that in "g-error.boot.pamphlet" the function  
> "sayErrorly()"
> calls "saturnSayErrorly()" which contains the output stream
> variable _*STANDARD_-OUTPUT_*.
> Altering that line as follows restores order to the error reporting:
> ---------------------------------------------------------------------
> $ cvs diff src/interp/g-error.boot.pamphlet
> Index: src/interp/g-error.boot.pamphlet
> ===================================================================
> RCS file: /cvsroot/axiom/axiom/src/interp/g-error.boot.pamphlet,v
> retrieving revision 1.3
> diff -r1.3 g-error.boot.pamphlet
> 175c175
> <   _*STANDARD_-OUTPUT_* : fluid := $texOutputStream
> ---
> >   *STANDARD-OUTPUT* : fluid := $texOutputStream
> ---------------------------------------------------------------------
> However I then found that similar strange variations on 
> various IO related variables and functions exist in the
> interpreter code as shown further down.
> Are these constructs intentional (perhaps some kind of TeXism 
> which my TeX system is not handling properly for example) or an
> unfortunate editing error?
> Cheers
> Mike Thomas.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]