<div class="gmail_quote">On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis <span dir="ltr"><<a href="mailto:gdr@integrable-solutions.net">gdr@integrable-solutions.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Because of ECL's design decision to target the C programming language,<br>
and the C programming language has lots ot parameters left to the<br>
implementation, i<b>t is certainly ECL's responsability to document choices<br>
that affect inter-operation with other C library</b> -- at least if ECL claims<br>
to be embeddable.  It has to document enough of the characteristics<br>
so that a knowledgeable person can construct a compatible library.</blockquote><div><br></div><div>First this paragraph, because it summarizes the spirit of this discussion. I have marked in bold what is relevant.</div><div>

1) Parameters left to the implementation. ECL does not take any choice itself. The person who configures ECL does, by choosing to pass any CFLAGS/LDFLAGS, or by using the default configuration parameters.</div><div>2) Documentation. ECL does not have a way to name the choices done by the user right now, because those choices are in the CFLAGS/LDFLAGS.</div>

<div>3) Offer enough information to build compatible libraries. Your sentece seems to imply that we hide information, and all your emails have had this implication. Nothing is hidden, it is provided in the exported CFLAGS, either in ECL itself (through dedicated variables, through functions to compile and link), or in scripts. We simply do not provide names for those choices because, as I have insisted thousands of times, I do not have them.</div>

<div><br></div><div>Now, (and this goes to Samium) I did not reopen this discussion in the public to open a flame war. I expected it to be constructive and the knowledgeable lot help me understand what I am missing and the things I could do to solve this problem. But overall I see the same patterns repeated that lead the private discussion to a stall and uneasy feelings, at least on my side.</div>

<div><br></div><div>* You, Gabriel, insist on the need to provide information to users, but give no precise names nor do you explain how I should offer this information.</div><div><br></div><div>* Current isolation techniques, such as scripts providing valid CFLAGS/LDFLAGS, which are standard for known and supported software (KDE, gnome, apache, etc), are disregarded as useless. We have to provide "names" that the user can turn back into compiler flags (what level of isolation is this for a user?)</div>

<div><br></div><div>* Back to the topic of gathering information from binary files. I answer back that I do not know how to process that information. I do not even have the faintest idea of what is useful for you out of this</div>

<div><div>juanjo@sage:~$ file bin/ecl</div><div>bin/ecl: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically linked (uses shared libs), not stripped</div><div>How and what should I isolate? Hardcoded names? Grepping strings? Should I grep the output of "file" for a set of known keywords ("ELF", "COFF", "SPARC", X86-64, the list of processor names, etc) and turn them into *features*?</div>

</div><div><br></div><div>* I add a couple of sentences about choices that appear in different compilers and turn executables incompatible, even if they have the same "binary" format. Those choices change the sizes of floating points, activate/deactivate the use of __thread local storage, ... the number is very large and I would not even know how to keep track of those. But they will definitely make your software incompatible with ECL's binary. Again I am just misdirecting the conversation, and this remark is disregarded.</div>

<div><br></div><div>* When I mention that the task of providing those users (actually power users) with the required information would need to keep a database of per-platform, per-compiler, sets of binary modes and compiler/linker modes, or valid keywords/options/arguments... all this hardcoded knowledge in the autoconf file, going back to the AKCL tradition, which caused so many problems, you say that this is not needed. At other places you switch back and say that, if needed, the number of platforms should be limited for this knowledge to be precise.</div>

<div><br></div><div>* At some point it is mentioned that I am overcomplicating everything, that OpenAxiom only needs to know whether ECL is 64bits or 32bits. I answer with a remark that all I understand as 32-bit or 64-bit is related to pointer sizes. You disregard this as a stupid answer which I write to make you angry and do not provide any constructive information on how I should learn what is called 32-bits or not.</div>

<div><br></div><div>* At another point I try to <b>learn</b> what other lisps are doing and how they are doing it. You take this as me attacking other implementations without failing to see that my emails are honest and that I learnt nothing. If SBCL just provides :sparc <b>(as ECL does)</b>, how does this tell you whether SBCL is 32-bit or 64-bit.</div>

<div><br></div><div>* I have mentioned repeated times (and this seems to tire you), that ECL learns its host and build CPU from Autoconf, and that this has caused a problem. You seem to imply that I am whinning, and when I move on to GCL to see how it does it, and I am unable to build it on my system, and I read through the configuration files and again learn nothing and (mistakenly) conclude that it should be affected by the same problem, you disregard it with a "here it works" and again an accusation of me attacking some other lisp. Wouldn't it have been more productive to give me a hint why your copy builds fine and gets the right host name?</div>

<div><br></div><div>You said that this is an awkward way of starting the year, but you seem to fail to see how this is making me feel personally. I must be utterly incompetent because I fail to see the ways to do what you are asking, and moreover I even fail to see what information you really need -- which oscillates between very little and very much, with the permanent implication that it is either obvious, known everywhere or easily accessible... --- And all the time you seem to imply that I am just twisting your words, but again, *I* must be the moron because I just write down what I understand.</div>

<div><br></div><div>I started precisely the ECL project because I was not able to build some software on my system and I was not clever enough to fill a configuration file, and much less learn the innards of the OS I was using. I shied away always from the philosophy of knowing all the platforms where my programs should work and their inner details and stick to POSIX, C, C99 or whatever standards were available, avoiding complications of binary formats, loaders, linkers and the like. Because I know my limitations, and because I know that there are people who do this (systems programming, garbage collectors, knowing a lot of OS details and the like) much better than me. Well, maybe after all I am not suited for the job.</div>

<div><br></div><div>Juanjo</div><div> </div></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><br>