Custom Query (1030 matches)

I'm using Windows 8.1 and CCL 1.11-r16635 (wx86cl64.exe). When I start wx86cl64 and call (quit), the binary does not quit. It just hangs there with no further activity.

? (quit)

I've tested this with the 64-bit binary and with the 32-bit binary. This issue does not happen all the time. With the 32-bit binary (wx86cl.exe) this hang does not occur as often as with the 64-bit binary. The 64-bit binary seems to hang on (quit) with a much higher likelihood on my windows. Windows 8.1 and Windows 10 seem to behave identical.

In the windows taskmanager I see that the wx86cl64 binary changes from two thread to one thread when I call (quit). After this the application seems to hang on its last thread.

Furthermore I've noticed that I can avoid the problem quite reliably when I change the compatibility setting of the wx86cl64.exe binary to Windows7. (This setting can be changed in the properties dialogue for the file wx86cl64.exe)

I've seen that there is a similar ticket already:

http://trac.clozure.com/ccl/ticket/1142

However I did not rebuild my lisp image and I don't see any error message at all (or at least I don't know where to look for an error message). If this is related to the same cause then just close this ticket.

Any help on this is appreciated.

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

next = (LispObj *)header;

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.

From Mikel:

The IDE's Hemlock implements Visit File and binds it to C-x C-v, but its behavior, in context of a Cocoa application, is bizarre. If you use it to choose an existing file, it quite correctly opens the file in the current buffer and window, but without informing the Cocoa app that the file associated with the buffer and window has changed. The result is that Hemlock thinks the file associated with the buffer is at the pathname you just visited, while the IDE thinks it's the file that you originally opened in the window. If these are different files (and they certainly can be), wackiness ensues the next time you decide to save the file. The exact results presumably depend on whether you decide to use C-x C-s or Command-S to save the file.