<div dir="ltr"><div class=""><img class="" id=":16g" tabindex="0" src="https://mail.google.com/mail/u/0/images/cleardot.gif" alt=""></div><div><div><div>Adding
my $0.02 to using ecl with c++, it is quite well possible, but very
tiresome. For every method call, you have to write static wrapper which
will cast all the <br></div>pointer(s) into respectable type and call
the method with arguments. Doing so by hand is very impossible, however,
doing so with automatic wrapper is quite easy.<br>
</div>The downsize is that you end up with 2000 lines of lisp and 4000 lines of c++ wrappers which do nothing. <br><br>Examples:<br><br><br>;;;;; Generating class: e418::game::Event<br>(defclass event ( pointer-container )<br>
())<br><br><br>;;;;; Generating class: e418::ui::Element<br>; Generating method destroy for object Element<br>(defmethod element-destroy ((class element) recursive )<br> (c-code::native-destroy (get-pointer class) recursive ))<br>
<br></div>and on c++:<br><br>//<br>// Generating wrappers for Element<br>//<br><br>// Generating methods for object e418::ui::Element<br>// generating wrapper for method destroy of object Element<br>cl_object _cl_gen_Element_destroy2(cl_<div dir="ltr">
object __wrapped_pointer, cl_object recursive ){<br>
// Converting lisp value to pointer of appropriate type<br> e418::ui::Element* __instance = (e418::ui::Element*) <br> ecl_to_pointer(__wrapped_pointer);<br><br> // Unpacking all arguments from lisp type to c type<br>
bool recursive_unpacked = recursive == ECL_NIL ? false : true;<br> <br> cl_object return_value = ECL_NIL;<br> // Method call <br> __instance->destroy(recursive_unpacked );<br> // Packing return value to lisp, if needed<br>
<br> return return_value;<br>}<br><br><div>Dunno if this is right way to do it, though, but seems to work fine.<br><br></div><div>(Sorry Juan about double the mail, but apparently gmail changed my reply to all to just reply...)<br>
</div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/4 Peter Enerccio <span dir="ltr"><<a href="mailto:enerccio@gmail.com" target="_blank">enerccio@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div><div>Adding my $0.02 to using ecl with c++, it is quite well possible, but very tiresome. For every method call, you have to write static wrapper which will cast all the <br></div>pointer(s) into respectable type and call the method with arguments. Doing so by hand is very impossible, however, doing so with automatic wrapper is quite easy.<br>
</div>The downsize is that you end up with 2000 lines of lisp and 4000 lines of c++ wrappers which do nothing. <br><br>Examples:<br><br><br>;;;;; Generating class: e418::game::Event<br>(defclass event ( pointer-container )<br>
())<br><br><br>;;;;; Generating class: e418::ui::Element<br>; Generating method destroy for object Element<br>(defmethod element-destroy ((class element) recursive )<br> (c-code::native-destroy (get-pointer class) recursive ))<br>
<br></div>and on c++:<br><br>//<br>// Generating wrappers for Element<br>//<br><br>// Generating methods for object e418::ui::Element<br>// generating wrapper for method destroy of object Element<br>cl_object _cl_gen_Element_destroy2(cl_object __wrapped_pointer, cl_object recursive ){<br>
// Converting lisp value to pointer of appropriate type<br> e418::ui::Element* __instance = (e418::ui::Element*) <br> ecl_to_pointer(__wrapped_pointer);<br><br> // Unpacking all arguments from lisp type to c type<br>
bool recursive_unpacked = recursive == ECL_NIL ? false : true;<br> <br> cl_object return_value = ECL_NIL;<br> // Method call <br> __instance->destroy(recursive_unpacked );<br> // Packing return value to lisp, if needed<br>
<br> return return_value;<br>}<br><br><div>Dunno if this is right way to do it, though, but seems to work fine.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">2013/3/4 Juan Jose Garcia-Ripoll <span dir="ltr"><<a href="mailto:juanjose.garciaripoll@gmail.com" target="_blank">juanjose.garciaripoll@gmail.com</a>></span><br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div>On Mon, Mar 4, 2013 at 5:30 PM, Christian Schafmeister <span dir="ltr"><<a href="mailto:chris.schaf@verizon.net" target="_blank">chris.schaf@verizon.net</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><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">I've created a new implementation of Common Lisp that has a core written in C++ completely from scratch but hosts the ECL Common Lisp source code.<br>
</blockquote><div><br></div></div><div>Sounds like a lot of work.</div><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">
It hosts all of the ECL Common Lisp code in the ecl/src/lsp and ecl/src/clos directories of the ECL source tree.<br>
I do not use any part of the ECL CL->C compiler or the byte code compiler.<br>
I've implemented my own CL interpreter and CL->LLVM-IR->native code compiler.<br></blockquote><div><br></div></div><div>I do not understand why you reimplemented the interpreter, but the LLVM thingy looks interesting.</div>
<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">It's purpose is to make possible the seamless interfacing of C++ libraries with Common Lisp code and vice versa.<br>
Within this new implementation it is trivial to interface complex C++ libraries containing classes, virtual functions, overloaded functions etc with Common Lisp code.<br></blockquote><div><br></div></div><div>Sorry, but I do not understand this. There are different things in interfacing Common-Lisp with C++, and none of them requires building a new compiler or a LLVM backend.</div>
<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">Why - you ask? I'd be happy to explain over a beer or coffee sometime.<br>
In a nutshell - I want this for my research and prior to my writing it there was no Common Lisp implementation that interfaces seamlessly with C++.<br>
ECL does a great job with "C" but "C++" is a much more complex language to interface with and I have a lot of C++ code that I need to interface with.</blockquote><div><br></div></div><div>If you state that ECL cannot interface with C++ I would like to see that statement backed with examples. EQL is one example that interfacing is not impossible and, probably, not that hard once you can write C++ inside Common Lisp code.</div>
<div><br></div><div>But most important, the issue of interfacing Common Lisp and C++ consists on many different problems that I do not see how you solve at the same time with the help of LLVM</div><div>
<br>
</div><div>1. Integrating the C++ type system and the Common Lisp one</div><div>2. Being able to call C++ functions from Common Lisp and viceversa</div><div>3. Integrating C++ and Common Lisp memory management</div>
<div>4. Possibly automating the generation of wrappers for C++ code.</div><div>5. Resolving overloading at runtime instead of at compilation time.</div><div>...</div><div><br></div><div>Many issues, some of which are mentioned in SWIG, <a href="http://www.swig.org/Doc1.3/SWIGPlus.html" target="_blank">http://www.swig.org/Doc1.3/SWIGPlus.html</a> but even many of which they (working long in the interface between C++ and dynamic languages) do not have an answer to.</div>
</div><div><br></div><div>Juanjo</div><span><font color="#888888"><div><br></div>-- <br>Instituto de Física Fundamental, CSIC<br>c/ Serrano, 113b, Madrid 28006 (Spain) <br><a href="http://juanjose.garciaripoll.googlepages.com" target="_blank">http://juanjose.garciaripoll.googlepages.com</a>
</font></span></div></div>
<br></div></div><div class="im">------------------------------------------------------------------------------<br>
Everyone hates slow websites. So do we.<br>
Make your web apps faster with AppDynamics<br>
Download AppDynamics Lite for free today:<br>
<a href="http://p.sf.net/sfu/appdyn_d2d_feb" target="_blank">http://p.sf.net/sfu/appdyn_d2d_feb</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>
<br></div></blockquote></div><span class="HOEnZb"><font color="#888888"><br><br clear="all"><br>-- <br>Bc. Peter Vaňušanik<br><a href="http://www.bishojo.tk" target="_blank">http://www.bishojo.tk</a><br>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br>Bc. Peter Vaňušanik<br><a href="http://www.bishojo.tk" target="_blank">http://www.bishojo.tk</a><br>
</div>