[rdnzl-devel] Re: rdnzl, multiprocessing, Allegro, windows, locking

[Roger Corman]

I think if I were doing this, I would write a C++ function which converts the .NET array to a native array (of native point structs). This could be called via the Lisp native interface (exporting it via a DLL) and then use the native interface to operate on it. Allegro CL should be able to handle that part very efficiently with its built-in FFI.

Roger
--------------
At 01:56 PM 12/27/2006, Edi Weitz wrote:
>[Please use the mailing list.]
>
>On Mon, 25 Dec 2006 13:17:28 -0800, "Richard Fateman" <fateman at cs.berkeley.edu> wrote:
>
>> We're using Allegro CL, and microsoft's ink routines, which
>> ultimately return to us "strokes" which we can decompose as arrays
>> of points, each containing an X and a Y.
>>
>> This decomposition, as we have written it, crosses the lisp - .net
>> boundary too often.  Presumably with the right magic, we can just
>> access the arrays once.  Suggestions?  (I'd rather do this
>> extraction in Lisp....)
>>
>> ;;; Here's our way convert a stroke to a list of (x . y) points.
>>
>> (defun decode-one-stroke (as) ;a stroke
>>   (let ((netarray
>>       [GetPoints as])
>>       (list-of-points nil))
>>     (do-rdnzl-array (v netarray (nreverse list-of-points))
>>       (push (cons [%X v ][%Y v]) list-of-points)
>>       )))
>
>Have you tried "direct calls"?
>
>  http://weitz.de/rdnzl/#direct
>
>This might yield a noticeable performance gain, but the main problem
>of crossing the boundary too often will still be there.
>
>Right now, there's no way to overcome this.  You'd have to write low
>level C++ code using something like (the equivalent of) LispWork's
>WITH-DYNAMIC-LISP-ARRAY-POINTER on the Lisp side to get a .NET array
>into the Lisp world in one fell swoop.  But this would solve only half
>of it, as you'd still have to get at the x/y coordinates of each
>point, crossing the boundary once again.  ATM I have no idea how a
>general solution could look like.
>
>Cheers,
>Edi.
>_______________________________________________
>rdnzl-devel mailing list
>rdnzl-devel at common-lisp.net
>http://common-lisp.net/cgi-bin/mailman/listinfo/rdnzl-devel