[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 11:15 PM, Gabriel Dos Reis <gdr at cs.tamu.edu> wrote:
>> | 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
>>
>>  * 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
>> Is that something you can agree to?
>
| Please understand that I am not just being stubborn. I know about

I never implied that.  I'm sure you have reasons.  

I'm just not sure my understanding of your reasons really matches the
benefits of  ECL being the only free Lisp implementation with a singular
behaviour for compile-file-pathname. 

| magic files, but I did not have the knowledge nor the time to
| implement them and found the current approach sufficient -- sincerely,
| what is gained by forcing your own extension on compiled files that
| can not be done by using temporary directories or real temporary names
| (mkstemp)? -- But I am not opposing to this change.

Forcing singular implementation details on user is something
is sometimes unavoidable.  However it should be kept to the minimum, and
done only if the benefits of doing so far outweight the drawbacks.  For
example, I very much appreciate ECL's feature of linking programs as
done traditionally (e.g. not dumping memory) -- which makes ECL quite
portable. On the other hand, it is not obvious to me the benefits of the
ECL's singular behaviour for compile-file-pathname outweight the 
drawbacks.

At the moment, ECL's target for dynamically loadable modules fall into
three camps: ECL, PE, MACH.  Please correct me if that list is short.
  

| I do not find I can do it right now myself

OK.

>
>> 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.
>
| Well, the point is that right now we are not trying with every file
| the binary approach. Hence no problems with errors.

I suspect I did not make myself clear.  My understanding of your
explanation of forcing '.fas' and not letting the user chose his own is
that, that way the system 'knows' that a file with '.fas' extension
is a FASL, therefore does not get into trouble with Windows opening
annoying popupss when the (binary) loads fails for wrong format.  My
point is that, just forcing '.fas' is no solution -- it is not a problem
you can solve by forcing a particular extension even when the user
wanted a different one.  The simple reason being that the extension does
not make the content OK and the content is the problem.  Consider: 

   % cat > HelloWorld.java
   import java.io.*;

   public class HelloWorld {
      static public void main(String[] args) {
         System.out.println("Hello Word");
      }
   }
   EOF
   % javac HelloWorld && mv HelloWorld.class HelloWorld.fas
   % ecl
   ECL (Embeddable Common-Lisp) 9.4.1
   Copyright (C) 1984 Taiichi Yuasa and Masami Hagiya
   Copyright (C) 1993 Giuseppe Attardi
   Copyright (C) 2000 Juan J. Garcia-Ripoll
   ECL is free software, and you are welcome to redistribute it
   under certain conditions; see file 'Copyright' for details.
   Type :h for Help.  Top level.
   > (load "HelloWorld")

   ;;; Loading #P"/tmp/HelloWorld.fas"
   LOAD: Could not load file #P"/tmp/HelloWorld.fas" (Error:
   "/tmp/HelloWorld.fas: invalid ELF header")
   Broken at SI:BYTECODES.No restarts available.
   Broken at SI:BYTECODES.
   >> 

Note that what I propose is NOT: try all possible binary formats, then
fall back to Lisp.  

-- Gaby