<div dir="ltr"><div>Hi Matt,</div><div><br></div><div class="gmail_quote">On Fri, Jul 12, 2013 at 12:24 AM, Matthew <span class="" style>Mondor</span> <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net" target="_blank">mm_lists@pulsar-zone.net</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Perhaps a few reminders, if performance is an issue (it might not<br>matter, depending, and are not only addressed to you, but may also<br>serve in the mail archive under this thread):<br></blockquote><div><br></div><div>
Thank you very much for your answer: performance actually is very important in my case and I am most grateful for your comments! </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Functions might be faster than methods </blockquote><div><br></div><div>Something like this?:</div><div><br></div><div>=== definitions ===</div><div><br></div><div>(<span class="" style>defun</span> make-cube (&key (size 1.0))</div>
<div> (<span class="" style>ffi</span>:c-<span class="" style>inline</span> (size) (:double) :pointer-void "new Cube(#0)" :one-liner t))</div>
<div><br></div><div>(<span class="" style>defun</span> cube-get-size (cube)</div><div> (<span class="" style>ffi</span>:c-<span class="" style>inline</span> (cube) (:pointer-void) :double "((Cube*) #0)-><span class="" style>getSize</span>()" :one-liner t))</div>
<div><br></div><div>(<span class="" style>defun</span> cube-set-size (cube size)</div>
<div> (<span class="" style>ffi</span>:c-<span class="" style>inline</span> (cube size) (:pointer-void :double) :void "((Cube*) #0)-><span class="" style>setSize</span>(#1)" :one-liner t))</div><div><br></div>
<div>(<span class="" style>defun</span> cube-delete (cube)</div><div> (<span class="" style>ffi</span>:c-<span class="" style>inline</span> (cube) (:pointer-void) :void "delete ((Cube*) #0)" :one-liner t))</div>
<div><br></div><div>=== tests ===</div><div><br></div><div>;;; A fist cube:</div><div>(<span class="" style>setf</span> cube (make-cube))</div><div>(format t "instance: ~a~%" cube)</div><div>(format t "size: ~a~%" (cube-get-size cube))</div>
<div>(cube-set-size cube 2)</div><div>(format t "new size: ~a~%" (cube-get-size cube))</div><div>(cube-delete cube)</div><div><br></div><div>;;; Experimenting with a second cube instance:</div><div>(<span class="" style>setf</span> cube (make-cube :size 3))</div>
<div>(format t "size: ~a~%" (cube-get-size cube))</div><div>(cube-delete cube)</div><div><br></div><div>=== <span class="" style>protocoll</span> ===</div><div><br></div><div>instance: #<foreign VOID></div>
<div>size: 1.0d0</div><div>
new size: 2.0d0</div><div>size: 3.0d0</div><div><br></div><div>===</div><div><br></div><div>If this is significantly faster I will wrap the Rhino C++ API using this style rather than <span class="" style>CLOS</span> wrappers!</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">(although there also is the concept of sealed classes, which could also help)<br>
</blockquote><div><br></div><div>This sounds interesting! Does this mean that the methods can be dispatched statically during compilation? And is this approach as fast as functional wrappers would be, but allows to still use something like 'get-size' for different classes rather than encoding the class in the name of the function itself (for example by using a prefix like 'cube-' resulting in 'cube-get-size' as in the given example)? </div>
<div><br></div><div>Is something like this implemented for <span class="" style>ECL</span>? If so I would prefer this approach as encoding the "class" in the name of the wrapper functions makes the code unnecessarily verbose.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- MAKE-CUBE (or a variant) could potentially instanciate the object<br> without adding an implicit finalizer, with a corresponding WITH-CUBE<br> or WITH-OBJECT macro responsible for finalization in UNWIND-PROTECT.<br> If I remember the implicit finalization system may be slower<br>
(probably a good idea to test instead of trusting my word on this).<br> WITH-* style macros are also a very common lispy interface, require<br> very few indentation and permit explicit, immediate finalization as<br> an option.<br>
</blockquote><div><br></div><div>Like this?:</div><div><br></div><div>(unwind-protect</div><div> (let ((cube (make-cube :size 10)))</div><div> (format t "size: ~a~%" (cube-get-size cube))</div><div>
(cube-set-size cube 20)</div><div> (format t "new size: ~a~%" (cube-get-size cube)))</div><div> (cube-delete cube))</div><div><br></div><div>Or, after defining the macro</div><div><br></div><div>(<span class="" style>defmacro</span> with-cube ((var &rest <span class="" style>args</span>) &body body)</div>
<div> `(let ((,var (make-cube ,@<span class="" style>args</span>)))</div><div> (unwind-protect</div><div><span style="white-space:pre-wrap"> </span> (<span class="" style>progn</span> ,@body)</div><div> (cube-delete ,var))))</div>
<div><br></div><div>like this?:</div>
<div><br></div><div>(with-cube (cube :size 100)</div><div> (format t "size: ~a~%" (cube-get-size cube))</div><div> (cube-set-size cube 200)</div><div> (format t "new size: ~a~%" (cube-get-size cube)))</div>
<div><br></div><div>In my case, I actually found out that Rhino doesn't like me to finalize any objects anyway and wants to manage them itself: A lisp variable might get out of scope but still exist in the Rhino scene. If I add a <span class="" style>finalizer</span> it forces the destruction of the Rhino object as well - causing Rhino to crash...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">- Alternatively, instead of full finalization+delete/free in WITH-*/GC,<br>
objects could potentially be finalized then cached as slab<br> allocators do; this will help if objects are complex and part of the<br> instanciation+initialization can be preserved.<br></blockquote><div><br></div><div>
Thank you for this as well. I wonder if Rhino internally uses a similar strategy - anyway, in my case I have no other choice than relying on Rhino's internal management.</div><div><br></div><div>Thank you very much for your comments!</div>
<div><br></div><div>If you have some more comments or some information about the concept of sealed classes, I would be most grateful!</div><div><br></div><div>Thanks again,</div><div>Dietrich</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
--<br>Matt<br></blockquote></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jul 12, 2013 at 12:24 AM, Matthew <span class="" style>Mondor</span> <span dir="ltr"><<a href="mailto:mm_lists@pulsar-zone.net" target="_blank">mm_lists@pulsar-zone.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Thu, 11 Jul 2013 20:46:15 +0900<br>
Dietrich Bollmann <<a href="mailto:dietrich@formgames.org" target="_blank">dietrich@formgames.org</a>> wrote:<br>
<br>
> [An answer to my own posting - I hope this is helpful for others with<br>
> similar problems]<br>
><br>
> Hi,<br>
><br>
> Here how I finally solved the problem and wrapped the C++ class (sorry for<br>
> the long delay):<br>
</div>> [...]<br>
<br>
That is pretty nice and clean, thanks for following-up this thread;<br>
<br>
Perhaps a few reminders, if performance is an issue (it might not<br>
matter, depending, and are not only addressed to you, but may also<br>
serve in the mail archive under this thread):<br>
<br>
- Functions might be faster than methods (although there also is the<br>
concept of sealed classes, which could also help)<br>
<br>
- MAKE-CUBE (or a variant) could potentially instanciate the object<br>
without adding an implicit finalizer, with a corresponding WITH-CUBE<br>
or WITH-OBJECT macro responsible for finalization in UNWIND-PROTECT.<br>
If I remember the implicit finalization system may be slower<br>
(probably a good idea to test instead of trusting my word on this).<br>
WITH-* style macros are also a very common lispy interface, require<br>
very few indentation and permit explicit, immediate finalization as<br>
an option.<br>
<br>
- Alternatively, instead of full finalization+delete/free in WITH-*/GC,<br>
objects could potentially be finalized then cached as slab<br>
allocators do; this will help if objects are complex and part of the<br>
instanciation+initialization can be preserved.<br>
--<br>
Matt<br>
<br>
------------------------------------------------------------------------------<br>
See everything from the browser to the database with AppDynamics<br>
Get end-to-end visibility with application monitoring from AppDynamics<br>
Isolate bottlenecks and diagnose root cause in seconds.<br>
Start your free trial of AppDynamics Pro today!<br>
<a href="http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk" target="_blank">http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Ecls-list mailing list<br>
<a href="mailto:Ecls-list@lists.sourceforge.net" target="_blank">Ecls-list@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/ecls-list" target="_blank">https://lists.sourceforge.net/lists/listinfo/ecls-list</a><br>
</blockquote></div><br></div></div>