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

[Camm Maguire]

Greetings!  2.6.8pre uses an approximate scheme using the pid in the
file name, at least on unix.  Is this not available on windows?  cvs
head has (si::with-temp-file...) using mkstemp.  If this could be
ported to windows too, we could get gazonk to use this mechanism.  See
do-recompile in gcl_callhash.lsp for example usage.

It is not clear to me from the below if you are describing gcl
standard behavior, or the axiom modified behavior.

Out of office for one week.

Take care,

"Page, Bill" <address@hidden> writes:

> 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?
> 
> Regards,
> Bill Page.
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah