Hello,
In windows, the environment variable TEMP points to a safe temporary directory. By definition it must be sane for correct system behavior. On Tue, 13 Dec 2005 10:29:17 -0500, Camm Maguire wrote: > Greetings! What is a good default tmp dir on windows/mingw? > > Am about to commit a patch to cvs head and Version_2_6_8pre fixing > this, and also putting the process id in the tmp filename to prevent > collisions between forked child processes. > > Take care, > > Robert Dodier <[EMAIL PROTECTED]> writes: > >> On 12/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> >> > 1. bugs 132888 and 1356617: function $describe fails >> > Today I have posted something to 1328888. >> > The $describe problem is related to a $compile problem. >> > Does someone know, where compile in Windows GCL >> > creates the temporary gazonk files? >> >> the "describe" problem happens because maxima >> calls lisp COMPILE in cl-info.lisp. GCL wants to write >> intermediate files in the current directory. this problem >> has been reported to the GCL project. >> (http://savannah.gnu.org/bugs/?func=detailitem&item_id=14821) >> >> i have committed a change to cl-info.lisp to #-gcl >> the calls to COMPILE. we can reenable the calls >> when GCL fixes COMPILE's use of intermediate files. >> >> i have looked for other calls to COMPILE, and i believe >> the only other call is from $COMPILE; i don't believe >> COMPILE is called incidentally to some unrelated >> function exception for in cl-info.lisp. >> >> > 2. bug 1328900 missing line break in 5.9.2 output >> > (C1) load("F:\\home\\maxima\\stringproc"); >> > (D1) F:/home/maxima/stringproc.lisp >> > (C2) for n from 0 thru 10 do sprint(fib(n))$0 1 1 2 3 5 8 13 21 34 55 >> > (C3) printf(true,"~5,2f ~5,2f~%",1.2345,9.8765)$ 1.23 9.88 >> > >> > That is not really pretty printing! >> >> do i understand correctly that the above output was >> generated in xmaxima ? >> >> i have observed the same behavior in xmaxima in ms windows, >> but the command line maxima (also in ms windows) >> shows the output on the line after the input. >> it appears that the behavior shown above is due >> to xmaxima failing to echo the carriage return which >> causes the input to be entered. i'm not sure what can >> or should be done about that. >> >> best, >> robert dodier >> >> _______________________________________________ >> Maxima mailing list >> [EMAIL PROTECTED] >> http://www.math.utexas.edu/mailman/listinfo/maxima >> >> >> -- Stève Toléqué Chemical Engineering Colorado School of Mines _______________________________________________ Gcl-devel mailing list Gcl-devel@gnu.org http://lists.gnu.org/mailman/listinfo/gcl-devel
