[Ecls-list] Help needed, really

[Gabriel Dos Reis]

On Sun, Jan 2, 2011 at 4:53 PM, Juan Jose Garcia-Ripoll
<juanjose.garciaripoll at googlemail.com> wrote:
> 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, it 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.

I certainly do believe ECL is hiding the information.  And we can agree to
disagree on that.  That is OK.

> 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 are complaining about flame war (called me things when it was
no warranted), yet you are doing exactly what you complaining about -- and
what is irritating.  See below.

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

I first try to convey an idea to you.  I noticed that when I tried to give a
name, the discussion went instantaneously in the wrong direction because
you were focused on the name I gave.  So, I refrain from giving a specific
name so that you don't get sidetracked.  Instead, I have been trying to
convey the general idea to you.  Do you seriously believe we would have gotten
anywhere if I insisted on a particular name and you were consistently
nitpicking on it?

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

The problem as I explained in the private conversation was that the
CFLAGS/LDFLAGS
that ECL provides are useless.

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

>From that information, I see key things:
   * 64-bit
   * SPARC V9
   * optionally ELF

That is not all that can be inferred, but it is far better than nothing.

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

I suspect this paragraph illustrates a key difference in our approach.  I am
of the opinion that something is better than nothing and I'm a believer in
refinement based on actual practice.  Your messages seem to indicate that
if you cannot have a perfect solution, there is no point in giving it
a try.  Both
are valid phisolophy, even if incompatible.   If your point is that you don't
have a perfect solution therefore you don't want to consider, them fine just
say so.

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

I only proposed to limit the number of platform (something of "primary
platforms) only if you insist that all information must be precise.
I was looking for ways *foward*.  Now, I realize that was a futile search
in front of a determine opposition.


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

First I did not "disregard it as stupid answer" (I believe that must be your
words, so own them.)  You suggested that in the private conversion, and
I explained why it as inadequate, taking as example the very platforms
where you reported the original problem.  It was repeated here again, and I
offered again an explanation of why it does not work.  Do you believe explaining
why it does not work is "disregarding it as a stupid answer"?  Or was that
a device to start a flame war and then complain about it?

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

Exactly which message and which sentences did I "take this as you
attacking other implementations"?

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

I did give you the hints in private conversion and mention it here: I looked
at the *FEATURES* of GCL and other Lisp systems that were working.
You theorized that something would fail with GCL because of Autoconf, and
I repeated something I said earlier, which was that Autoconf was being
used in the other cases too (including OpenAxiom itself)

> 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

When I tried (in private conversation) to be very specific, you instantly shot
the whole idea down by nitpicking on the choice of words.  Then, I explained
that maybe my being too precise and using a certain word implied to you
something I did not mean, so I backtracked from being too specific on certain
names, and only tried to get the *idea* to you by offering several examples.
I don't believe it is fair to complain that I'm too vague when you instantly
nitpick on too precise names.

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

I fully understand and appreciate the complexity of getting into OS internals.
I fully appreciate the benefits of the abstraction barrier provided by C
as a target language.  However, that very choice also has some serious
drawbacks, and the challenge is to offer enough remedies without
getting into the traps of very low-level details and offloading too much
complexities on users.

When I originally made the suggestion of providing binary information, I was
perfectly available working with you in determining how things can be done.
However, the very first reply and the followings messages were consistently
"no, can't do."   And the reasons were almost invariably about why something
I did not suggest was not good idea or too complex.

I was actually looking for something like "OK, that sounds sensible and useful.
How can we can there."  When, the discussion moved here, at the exception
of very few the impression of a barrage of "can't do" in the face of
examples "yes, it can be done" only reinforced.

As I explained a few days ago, today was a busy day for me and an even much
longer and busier day is awaiting me tomorrow.  This has unexpectedly
consumed already much more time than I would have thought and there is
nothing to
show for it.  So, let's just drop it.  I'll make OpenAxiom builds with ECL on
platforms where I know this issue does not show up.

-- Gaby