[Ecls-list] Help needed, really

Sun Jan 2 22:53:39 UTC 2011

On Sun, Jan 2, 2011 at 9:41 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> Because of ECL's design decision to target the C programming language,
> and the C programming language has lots ot parameters left to the
> implementation, i*t is certainly ECL's responsability to document choices
> that affect inter-operation with other C library* -- at least if ECL
> claims
> to be embeddable.  It has to document enough of the characteristics
> so that a knowledgeable person can construct a compatible library.

First this paragraph, because it summarizes the spirit of this discussion. I
have marked in bold what is relevant.
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.
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.
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.

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.

* 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.

* 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?)

* 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
juanjo at sage:~$ file bin/ecl
bin/ecl: ELF 64-bit MSB executable, SPARC V9, version 1 (SYSV), dynamically
linked (uses shared libs), not stripped
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*?

* 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.

* 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.

* 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.

* At another point I try to *learn* 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 *(as ECL does)*, how does this tell you whether SBCL is
32-bit or 64-bit.

* 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?

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.

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.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://juanjose.garciaripoll.googlepages.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20110102/0a292fbe/attachment.html>