<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 11, 2013 at 3:31 PM, Anton Vodonosov <span dir="ltr"><<a href="mailto:avodonosov@yandex.ru" target="_blank">avodonosov@yandex.ru</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">Maybe it is impossible to give a 100% guarantee to cross compile any CL code.<br></div></div>
But I guess more than 93% of useful libraries are not affected but such issues and<br>
can be cross-compiled as is, without even tuning them.<br></blockquote><div><br></div><div style>You know, as well as I do, that failure of a couple of libraries can ruin quite many other dependencies :-)</div><div style>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am curious to know what are the specialized arrays? (used in clx)?<br></blockquote><div><br></div><div style>
Buffers, prebuilt data, etc.</div>
<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note, that the target has the same runtime library - ECL.<br>
So the most troublesome things for cross compilation are properties<br>
of the underlying platform that are visible through the CL;<br>
not the properties of the given CL implementation.<br></blockquote><div><br></div><div style>I agree, but they are there.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

And the underlying platform is abstracted very much by CL.<br>
Endiannes is abstracted by function cl:ldb - zero byte is the less significant<br>
byte of an integer, doesn't matter how the integer layed out in memory.<br></blockquote><div><br></div><div style>Not really. There is code out there that uses endianness to write down data from 32-bit buffers in one way or another. How binary files are written depends on platform dependent details. Similar to the built int type classes, such as integer types or specialized arrays.</div>

<div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So I still think cross-compilation of Lisp code has significant potential.<br></blockquote><div><br>
</div>
<div style>I do not deny it. I just simply say that lisp coders are not used to write code that works that way-</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


Mocl is even trying to make business on it.<br></blockquote><div><br></div><div style>And they are forced to cooperate with library authors revising what they do.</div><div style> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

On the other hand, it is not always necessary. Loading the system<br>
from source code on target and running interpretter may be OK for many applications.</blockquote><div><br></div><div style>Totally agree. We are saying the same thing, just exposing different aspects of the same problem. <br>

</div></div><div class="gmail_extra"><br></div>Juanjo<br clear="all"><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>
</div></div>