Custom Query (1030 matches)
Results (379 - 381 of 1030)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #434 | invalid | Search files dialog | ||
| Description |
A simple grep dialog, ala MCL. I used this all the time! |
|||
| #1349 | fixed | CCL 1.11 does not build on Raspberry Pi 2 B | ||
| Description |
After obtaining a copy of Clozure CL 1.11 via: $ svn co http://svn.clozure.com/publicsvn/openmcl/release/1.11/linuxx86/ccl using my Raspberry Pi 2 B, the armcl runs, but it appears to have the "… lisp-kernel binary that is included in the Subversion repository uses the soft-float ABI." I would like to use the hard-float ABI so have attempted to recompile the code. Following the ideas found at http://trac.clozure.com/ccl/wiki/PlatformNotes#LinuxARM I changed directory and did the make clean && make step. I have repeated these steps numerous times making a number of changes over time. But the out-of-the-box code itself, with NO CHANGES, compiles with this warning: cc -include ../platform-linuxarm.h -c ../albt.c -DLINUX -DARM -D_REENTRANT -D_GNU_SOURCE -DSVN_REVISION="16704" -g -O2 -marm -march=armv6 -Wno-format -o albt.o ../albt.c: In function ‘walk_stack_frames’: ../albt.c:95:14: warning: assignment from incompatible pointer type
and results in a segmentation fault. I have commented this line of code out to remove the error and remade this. The build looked good, but as it always does, it results in: # ./armcl Segmentation fault No matter what changes I make, such as changing armV6 to armV7-a in the Makefile, commenting out warning lines, and even including none at all, I get this segmentation fault. It appears the CCL cannot be compiled on the Raspberry Pi 2 B even with no changes to the code downloaded via svn. Yet, it runs in soft-float mode directly after download, but I cannot rebuild it in soft or hard float mode. |
|||
| #585 | fixed | Small patch to contrib code (paine's workpersistence.lisp) | ||
| Description |
On my machine workpersistence.lisp writes a Hemlock editor window to the workpersistence.text file even when I have closed that window. The attached file contains a couple extra lines of code that seem to fix that. Let me know if there is a better venue for patching. |
|||
