[Ecls-list] Help needed, really

[Samium Gromoff]

I am replying to several mails, by different authors here, sorry for
that.

On Sat, 01 Jan 2011 13:13:36 -0600, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
> At the moment, since the discussion is stall and it does not appear that
> ECL is willing to make itself more useful (at least as far as OpenAxiom
> is concerned) on these multilib-platforms, and after reading indication
> that ECL intentionally put misleading information regarding platforms on
> *FEATURES*, I've disabled attempts to build OpenAxiom with ECL on know
> problematic platforms.

My impression was that ECL doesn't /add/ information anywhere -- it merely
/forwards/ whatever is fed to it by autoconf.  It's not intent, merely a
lack of sophistication.

Juan, am I right?

Gabrial wrote:
> Finally, instead of requiring every ECL user to conceive of her or his
> own brittle way to get the information that ECL possesses, it sounds to
> me to me to be a good abstraction for ECL to provide a reliable way to
> get hold on it, once.  If there is a bug, we know there is only one
> place to fix.

and elsewhere:
> On POSIX systems, ECL can just issue `file
> test-program-linked-against-required-c-lib' and use the output to
> determine the binary flavour.  On non-posix systems (not many, among the
> platforms where this actually matters.), it can have its own custom
> program to look at the header of the test program.  Certainly using
> Autoconf's triplet in an improved way may remove the need to have to
> write custom header reading program.

and elsewhere:
> You link this dummy C file against the GMP library just the same way you
> currently build and link ECL against the GMP.  The configuration/build
> requirements remains exactly the same.  If GMP is system-wide installed,
> you just proceed to link the dummy file against the library, using
> exactly the same flags as you currently do.  If you have to build GMP,
> you build that library first (as you currently do), then you link the
> dummy C file against that with exactly the same flags as you do today.
> Nothing changes there.  You do not need to infer the binary personality
> before you link against GMP.  The purpose of that dummy program is
> solely to give the same binary personality that the ECL program and
> library would have.  The only reason you would do that before proceeding
> with the remaining ECL build is so that you can cache that information
> in the ECL image (e.g. *FEATURES*) if you so chose to.  You can very
> well just build the usual ecl program, then determine the binary
> personally, and put that in some file that gets installed with the the
> ECL system and make it available to users later.

This added step sounds entirely reasonable, if we decide that ECL should
export this information.  I, also, can easily imagine Juan's
unwillingness to develop, debug and maintain this inference.  Which
raises the questions:

Would Gabriel be interested to develop and maintain these parts of ECL?
Perhaps some common ground with GCL can be found?

Would Juan be willing to accept this code?

elsewhere, Gabriel wrote:
> I'm just saying that the binary information is one that comes from the
> RESULTING program or library, not the size of the C integer types
> used.

I find it impossible to believe that the ABI is a mere link-time
abstraction, and not something completely deterministically exposed
through a combination of the C type system and preprocessor information,
although I can see that it is the harder way of obtaining the ABI.

On Sun, 2 Jan 2011 03:49:46 -0600, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:
> On Sun, Jan 2, 2011 at 3:21 AM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
> 
> > * Autoconf triplets. ECL currently exports them as *features* and as the
> > output of other functions but they do not work. They are unreliable and OS
> > X, where OpenAxiom failed to build because of this, is an example.
> 
> Autoconf reports the same triplet to ECL that it reports to OpenAxiom
> Yet, OpenAxiom builds successfuly with SBCL and GCL on that same
> machine with the same machine.

Absent analysis of how the autoconf information is used by these
implementations, this is a fairly useless observation, as for SBCL, as
an example, we already know that it has, by its virtue of being a full
compiler (and a less portable one, as a result), full information of the
target ABI.  GCL, on the other hand, must maintain some normalisation.

elsewhere, Juan-Jose Garcia Ripoll wrote:
> * 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.

Well, he does, with a /certain/ level of concreteness -- see above --
however, I can completely understand your desire to avoid performing the
work required to turn the aforementioned not-entirely-concrete
suggestions into a result satisfactory to the authors of the suggestions.

It makes sense to let the interested parties do the work, then.

elsewhere, Gabriel wrote:
> > Most Lisp compilers take significant amounts of work to make them build
> > on a different configuration.  ECL often just works.  Asking it to try
> > and deduce a bunch of information about that configuration would make it
> > much less portable than it is.
> 
> Bunch of information already contained in the "just working ECL"
> That is the part that is being consistently missed in this discussion.

You seem to consistently miss, that the process, by the means of which
this information is added to the ECL binary,
_is_not_described_by_the_ECL_source_code_.

In other words -- garbage in, garbage out -- :I686 is what ECL got from
autoconf.  If GCL copes with that -- it must be doing normalisation --
which Juan is not interested in maintaining.

-- 
regards,
  Samium Gromoff
--
"Actually I made up the term 'object-oriented', and I can tell you I
did not have C++ in mind." - Alan Kay (OOPSLA 1997 Keynote)