Custom Query (1030 matches)
Results (940 - 942 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #104 | invalid | Race condition creating temporary file names for (open ... :if-exists :supersede) | ||
| Description |
If an existing output file is opened with :IF-EXISTS :SUPERSEDE in effect, OPEN renames the original file to a temporary file name. The code which tests for uniqueness of temporary file names is subject to race conditions (e.g., it is possible that two threads/processes could both conclude that the same temporary file name was available at about the same time and rename different files to the same temporary file name, clobbering at least one original.) Some C library routines attempt to address this by making the test for availability be "open, creating and failing if the file exists". If everything which contends for the same pathname uses that method, that avoids conflicts. It might also be possible to minimize the possibility of collisions by incorporating a representation of process/thread IDs in the generated temporary filenames. Any scheme which tries to handle this is only viable if all contenders use the same scheme. |
|||
| #103 | fixed | x8664 callbacks, single-float return. | ||
| Description |
The "portable" parts of the expansion of DEFCALLBACK generated code which coerced SINGLE-FLOAT results to DOUBLE-FLOATs. This behavior is really PPC-specific, and should be moved to the platform-specific FFI code that deals with callback return values. A symptom is that: (defcallback two (:float)
(ff-call two :float) would likely return the low 32 bits of 2.0d0 rather than 2.0f0. (This was fixed in changeset:7134 and changeset:7135); the bug's been present in the x8664 FFI forever.) |
|||
| #102 | fixed | SLIME bugs on x8664 | ||
| Description |
I'm entering these SLIME / debugging problems as a Trac Ticket in light of a customer's recent e-mail about their Lisp requirements ("It would be awfully nice if the debugging information generated by the compiler allowed for easier debugging, e.g., better display of args and locals, return from frame, restart frame. Integration with Slime is a must.") SLIME has not been updated to account for recent changes made in OpenMCL to support x86-64 processors. You may run into bugs running on those platforms. The SLIME backtrace sometimes shows incorrect information. return-from-frame and apply-in-frame do not work reliably. (If they work at all, it's pure luck.) |
|||
