Custom Query (1030 matches)

Summary: 2D Bitmap arrays print non-readably, #2A(#*101010 #*010101) doesn't read as 2D array, barfs, ...AND... can't create a 2D bitmap using reader.

If you create a 2D bitmap using (make-array '(4 4) :element-type '(mod 2)) The result will print as #2A(#*0000 #*0000 #*0000 #*0000) When you read it back in, the reader barfs:

> Error: Reader error on #<CCL::RECORDING-CHARACTER-INPUT-STREAM #xC75FFE6>, near position 32:
>        Initial contents for #A is inconsistent with dimensions: #2A(#<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4> #<SIMPLE-BIT-VECTOR 4>)

The related bug is that #1A(#*0000 #*0000 #*0000 #*0000) works "just fine" except it creates a 1D array.

Apparently there is no way to create a 2D bitmap from the reader.

When building a standalone binary using SAVE-APPLICATION and :PREPEND-KERNEL T, I found the command line argument processing of the resulting binary undesirable. I have a patch that solves the problem for me, however, it might not be the best way of doing things.

The problem as I see it is as follows: When only one argument (which does not begin with a '-') is provided to a binary which consists of (kernel + heap-image), the current kernel code automatically tries to load that argument as the image even though it should clearly use the image attached to the binary itself. As a result, one has to always use the '--' argument to end processing of the kernel arguments. This behavior is not expected for unix command line tools and shouldn't be expected here either IMHO.

The attached patch provides a sub-optimal solution which basically detects the case when the heap image is already included in the binary and so does not try to load the image from that first argument. The problem with this is that since '--' is not required, other kernel level command line flags, such as -I, -R, -S, etc, that are not passed on to the application may cause some confusion.

Another solution is to completely disable those kernel level flags if the heap image is attached to the kernel, but the loss of control over those parameters is also undesirable.

The initial screen of the Clozure CL Help says "The OpenMCL Doc directory is available [here]." But the link to [here] doesn't do anything. Clicking on it doesn't take you anywhere.

This is in the App Store version of the IDE. I don't know whether the link works in the version of the IDE that can be downloaded from the Clozure website.