[Antik-devel] Reader macro for sharp-m returns literal foreign-array (patch included)

[Liam Healy]

On Fri, Dec 9, 2011 at 4:04 PM, James Wright <james at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/antik-devel/attachments/20111209/e5d459cb/attachment.html>