[Ecls-list] Load and filenames.

[Dustin Long]

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

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