[Ecls-list] compile-file-pathname bug

[Gabriel Dos Reis]

Juan Jose Garcia-Ripoll <juanjose.garciaripoll at googlemail.com> writes:

| On Sat, May 16, 2009 at 10:17 PM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
>> I understand that; but I believe ECL could be improved there too.  For
>> example, if the file extension is not one that is listed for input Lisp
>> source files (e.g. .lisp), then ECL could attempt to load it as a FASL.
>
| That has caused a lot of problems in the past, specially in Windows,
| with really annoying messages popping up all the time about files
| being corrupt: following what you say, the loading of binary files has
| to be tried first, and sometimes the files are lisp sources, not

Not exactly.  Here is what I propose:

  * if the file extension is one of .lisp (or .lsp, or a set of
    well-documented popular extensions), then load as an input Lisp
    source file 

  * otherwise, commit to loading a FASL.  A native dynamically loadable
    module, (either EFL, PE, or MACH) has a magic numnber.  If that
    magic number isn't present in the ultimate native module, then error
    -- this happens even before Windows get a chance of throwing popups.
    Otherwise, the magic number is there: just proceed as a FASL, if it
    fails, then it fails (just like today). 

Is that something you can agree to?
I understand that a variant of that caused problems in the past.  I
suspect that happened because the magic numbers where not tested?

| binaries, and Windows does not just return -1 when the loading fails:
| it annoys the user with a popup. I also have a strong opiniong against
| feeding _anything_ to the dynamic linker just because the user says
| so.

Yes, but then even if the file had the 'right' extension (as the current
situation in ECL), that in itself does not necessarily mean that the
content is right.  So, one gets the same problem.  So, I'm not sure the
current restriction prevents that from happening.

>> At the moment ECL seems to the only free implementation that refuses to
>> honor user-supplied file extension.  That in particular (among other
>> things) excludes ECL as a bootstrapping Lisp system for SBCL.
>
| That is because there is not enough interest. I am sure that the
| extensions issue is not such a fundamental obstacle.

Since I raised this issue, I received a private email from another
fellow ECL user who sent me what he had done in the past in trying to
get ECL as bootstrapping system for SBCL.

>
>> That  would be OK, if the benefits far exceed the drawbacks.  However, I do
>> not think we have enough compeling reasons for ECL to stay in that state.
>
| As I said, I am open to suggestions and change, but you have to
| understand that while the change to COMPILE-FILE[-PATHNAME] is minor,
| the change of the loader has other deeper implications.

I understand that.  I do hope we will come to a workable solution.
(note that SBCL also uses native Windows DLLs; I'm not sure this 
particular issue is a stumbling block; so, I suspect it is workable.)

-- Gaby