[Ecls-list] Load and filenames.

Dustin Long dlong at progmatism.com
Fri May 30 17:32:14 UTC 2008

On Fri, May 30, 2008 at 1:21 PM, Mark Hoemmen <mark.hoemmen at gmail.com>

> Juan Jose Garcia-Ripoll wrote:
> > On Fri, May 30, 2008 at 7:09 PM, Waldek Hebisch
> > <hebisch at math.uni.wroc.pl> wrote:
> >> Presumably ECL can decide if a file is Lisp source or not.  If it
> >> is not a Lisp source than it is a fasl or invalid file.  I would
> >> think that 'dlopen' (or equivalent) can report to ECL errors
> >> due to loading of invalid binaries.
> >
> > Unfortunately, this is not true. We cannot rely on in the dynamic
> > linker to detect whether a file is binary or not. This caused serious
> > problems in some ports, some time ago. Instead of returning -1 and
> > failing, the linker would bother the user with error messages about
> > corrupt binaries, and so on. I think this happened mainly in the
> > Windows port, but it is nonetheless too unsafe to rely on that.
> Furthermore, if the system's implementation of dlopen() happens to be
> broken, then trying to link an invalid object file could cause troubles.
> I imagine one could store the object file suffix that ECL uses, and then
> use that to guess the file suffix.  So if you try
> (load "baz")
> it would first look for "baz.lisp", and if that file didn't exist, it
> would try "baz.fas" or whatever ECL uses for the object file suffix.

I'm pretty sure ECL already does this. The problem is when the file is
actually called "baz".

Isn't there a "external-format" parameter to load that allows you to specify
the type? Is this something that can be done with this?

> This seems easy enough to implement that those who desire the feature
> could submit their own patch and not pester our hard-working Juanjo
> about it, no? ;-)
> mfh
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ecls-list mailing list
> Ecls-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ecls-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/ecl-devel/attachments/20080530/86593a04/attachment.html>

More information about the ecl-devel mailing list