On Fri, Dec 9, 2011 at 4:04 PM, James Wright <james@chumsley.org> wrote:

Hi,

I have encountered the following problem a couple of times before,
although not as reproducibly as the memory corruption issue from my
previous message: If I use the #m reader macro in a function
somewhere, dump an SBCL core image, load the image, and call the
function, I get memory corruption. I have mostly dealt with it up
until now by not using the #m() notation in anything that I plan to
dump to a binary.

This is odd. There is a make-load-form for foreign-arrays, so I assumed this would work. Example?

I believe that the cause is that the #m macro returns a foreign-array
object directly (when foreign-array is the default grid type). If it
returned a `make-grid' form instead, it would operate identically on
e.g. the REPL. It would have the advantage, however, of being usable
in a dumped image, since the array would be created at run-time
instead of at read-time, and hence no foreign-pointers would be saved
into the image.

My intent is that it be analogous to #, e.g. #(1.0d0 2.0d0) expands to a (CL) array. I used to have it the way you want but I changed it as of 3e610bd4d5261 to be analogous to the regular array macro (in fact, #m should make a CL array if grid:*default-grid-type* is set accordingly; I'm still not sure about the wisdom of doing that). I had a good reason for changing it, but I can't recall exactly what it was. Something was not working right is all I recall.

By the way, do you know about grid:grid? Maybe that's what you want. It's a function, so it evaluates its arguments
(grid:grid pi pi pi)
#m(3.141592653589793d0 3.141592653589793d0 3.141592653589793d0)

I've attached a patch that changes the #m reader macro to return a
creation form instead of a literal. I hope you'll consider adding it.
I've pasted a repl session below that demonstrates the difference.

Thanks,
James

I think I'd like to figure out why #m can't be saved before I consider changing this back.

Liam