[Top][All Lists]

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

RE: [Axiom-developer] Re: [#330 generating 3d plot from hyperdoc fails]g

From: Page, Bill
Subject: RE: [Axiom-developer] Re: [#330 generating 3d plot from hyperdoc fails]gazonk again
Date: Mon, 18 Dec 2006 14:07:38 -0500

On Tuesday, December 19, 2006 1:30 AM Tim Daly wrote:
> > > The gazonk-name function, previously discussed, should handle
> > > this problem. I'm not sure why it wasn't applied.
> > > 
> > 
> > Tim, is this a problem with Axiom or with GCL? If it is GCL
> > has anyone submitted a patch?
> ummm, that would be a source of debate i'd guess.
> arguably there is a failure in axiom causing the file to remain.

What does Axiom care about temporary files generated by GCL?
Isn't the goal just to compile and load a Lisp function?

> arguably there should never be a gcl failure leaving the file.

Yes, probably.
> of course, if there are multiple users of the system you can have
> name collisions because they are both writing to the same temp
> file name and do not have permission to erase each others files.

Do you mean to suggest that GCL can not be successfully used on a
multi-user system? Surely this is not a problem with must software
intended to run on unix/linux? There is a standard unix function
to create unique temporary file names in a multi-user environment.

> perhaps these files are left around from a previously failing
> axiom build. however axiom plays with the default system path
> names of gcl so that, by design, it never writes outside of 
> the build directory so this should not happen.

In my experience the gazonk files are always created in /tmp
in all version of Axiom I have used so far - for both explicit
SPAD compiles ")compile xxx.spad" and for implicit function
compiles ")set function compile on". The axiom draw operation
always seems to try to compile it's first argument and for some
reason leaves some gazonk files in the /tmp directory - not only
when it fails but all the time.  If the resulting gazonk file is
owned by the current user then everything is ok. But if the file
is owned by another user/group to which I do not have write
access, then the next time someone else tries to use the Axiom
draw function, an error like this:

>> System error: Cannot create the file /tmp/gazonk0.fn.

occurs. Does this error message originate with GCL or with
something else that Axiom is trying to do with/too this file?

Bill Page.

reply via email to

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