Is there any standard way to distribute CL libraries without
source? For example in C you would distribute object files with
include headers. Is there anything similar in CL?
--
Who's your mama?
Spiros Bousbouras <······@gmail.com> writes:
> Is there any standard way to distribute CL libraries without
> source? For example in C you would distribute object files with
> include headers. Is there anything similar in CL?
Yes. Compiled source files (which are often called "fasl files"). No
need to distribute separate header files - fasl files have all the info
in them for a lisp implementation to get information on functions and
such. And you can get that information also from the fasl files.
The name of the compiled files (actually, the filename ending) is
implementation dependent and may also be platform dependent (so there
are for example also .xfasl files - can't remember right now which
implementation that is).
See your implementation's manual.
Frank
On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
> Spiros Bousbouras <······@gmail.com> writes:
> > Is there any standard way to distribute CL libraries without
> > source? For example in C you would distribute object files with
> > include headers. Is there anything similar in CL?
>
> Yes. Compiled source files (which are often called "fasl files"). No
> need to distribute separate header files - fasl files have all the info
> in them for a lisp implementation to get information on functions and
> such. And you can get that information also from the fasl files.
If the functions have type declarations do the fasl files also contain
those? In other words can someone receiving fasl files make sure
that the functions are called with arguments of the right type?
> The name of the compiled files (actually, the filename ending) is
> implementation dependent and may also be platform dependent (so there
> are for example also .xfasl files - can't remember right now which
> implementation that is).
What about the format of the files? Is that also implementation
dependent
or can fasl files produced with one implementation be used with
another?
--
Who's your mama?
On 17 maio, 18:18, Spiros Bousbouras <······@gmail.com> wrote:
> On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
>
> > Spiros Bousbouras <······@gmail.com> writes:
> > > Is there any standard way to distribute CL libraries without
> > > source? For example in C you would distribute object files with
> > > include headers. Is there anything similar in CL?
>
> > Yes. Compiled source files (which are often called "fasl files"). No
> > need to distribute separate header files - fasl files have all the info
> > in them for a lisp implementation to get information on functions and
> > such. And you can get that information also from the fasl files.
>
> If the functions have type declarations do the fasl files also contain
> those? In other words can someone receiving fasl files make sure
> that the functions are called with arguments of the right type?
If the implementation actually support those type declaration, then,
yes, the fasl file will have the type declarations and optimizations
you gave. If it will check the arguments types, then this is
implementation dependent. I know that both CMUCL and SBCL will do type
checking (unless you write (declare (optimize speed (safety 0))) )
> > The name of the compiled files (actually, the filename ending) is
> > implementation dependent and may also be platform dependent (so there
> > are for example also .xfasl files - can't remember right now which
> > implementation that is).
>
> What about the format of the files? Is that also implementation
> dependent
> or can fasl files produced with one implementation be used with
> another?
fasl files are implementation dependent. And, I agree, this is a bad
thing when you want to distribute them.
On 17 May, 22:37, gugamilare <··········@gmail.com> wrote:
> fasl files are implementation dependent. And, I agree, this is a bad
> thing when you want to distribute them.
Have there been any companies selling Lisp libraries instead of
complete programmes? If yes how did they deal with the issue?
--
Who's your mama?
gugamilare wrote:
> On 17 maio, 18:18, Spiros Bousbouras <······@gmail.com> wrote:
>> On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
>>
>>> Spiros Bousbouras <······@gmail.com> writes:
>>>> Is there any standard way to distribute CL libraries without
>>>> source? For example in C you would distribute object files with
>>>> include headers. Is there anything similar in CL?
>>> Yes. Compiled source files (which are often called "fasl files"). No
>>> need to distribute separate header files - fasl files have all the info
>>> in them for a lisp implementation to get information on functions and
>>> such. And you can get that information also from the fasl files.
>> If the functions have type declarations do the fasl files also contain
>> those? In other words can someone receiving fasl files make sure
>> that the functions are called with arguments of the right type?
>
> If the implementation actually support those type declaration, then,
> yes, the fasl file will have the type declarations and optimizations
> you gave. If it will check the arguments types, then this is
> implementation dependent. I know that both CMUCL and SBCL will do type
> checking (unless you write (declare (optimize speed (safety 0))) )
This is incomplete information, since it only covers type declarations.
But you can also use assert, check-type, typep, typecase and method
specializers to define types for function arguments, and then you will
definitely get the type checks you want, in a portable way.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 17 Mai, 23:18, Spiros Bousbouras <······@gmail.com> wrote:
> On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
>
> > Spiros Bousbouras <······@gmail.com> writes:
> > > Is there any standard way to distribute CL libraries without
> > > source? For example in C you would distribute object files with
> > > include headers. Is there anything similar in CL?
>
> > Yes. Compiled source files (which are often called "fasl files"). No
> > need to distribute separate header files - fasl files have all the info
> > in them for a lisp implementation to get information on functions and
> > such. And you can get that information also from the fasl files.
>
> If the functions have type declarations do the fasl files also contain
> those? In other words can someone receiving fasl files make sure
> that the functions are called with arguments of the right type?
As lisp is dynamically typed, the program may signal a type error
condition at runtime. If it signals such an error depends on the
settings of the optimization declarations.
Some CL implementations can also warn you if you use a function with
wrong types. How those implementations organize this (static) type
information is not specified. A good rule of thumb for CL systems is,
that the system has all necessary static information available at
runtime, because most of the time compilation is done within the
running lisp system. Conceptually there should be no difference
between compiling a source or loading the result. Technically one CAN
order CL to execute arbitrary code in different phases including when
compiling a file; so there might be a difference in the final result.
> > The name of the compiled files (actually, the filename ending) is
> > implementation dependent and may also be platform dependent (so there
> > are for example also .xfasl files - can't remember right now which
> > implementation that is).
>
> What about the format of the files? Is that also implementation
> dependent
> or can fasl files produced with one implementation be used with
> another?
It's implementation dependent.
ciao,
Jochen
Spiros Bousbouras <······@gmail.com> writes:
> On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
>> Spiros Bousbouras <······@gmail.com> writes:
>> > Is there any standard way to distribute CL libraries without
>> > source? For example in C you would distribute object files with
>> > include headers. Is there anything similar in CL?
>>
>> Yes. Compiled source files (which are often called "fasl files"). No
>> need to distribute separate header files - fasl files have all the info
>> in them for a lisp implementation to get information on functions and
>> such. And you can get that information also from the fasl files.
>
> If the functions have type declarations do the fasl files also contain
> those? In other words can someone receiving fasl files make sure
> that the functions are called with arguments of the right type?
Yes, but it works the way that your functions are then making sure that
they are called with arguments of the right type - if done correctly
they will signal an error to the caller of either not matching types or
not finding a suitable function to call because the arguments types' do
not match.
> What about the format of the files? Is that also implementation
> dependent
> or can fasl files produced with one implementation be used with
> another?
Yes, the Common Lisp ANSI Standard doesn't define the format of fasl
files. As such, they most likely are not "transportable" between Lisp
implementations.
Frank
Spiros Bousbouras wrote:
> On 17 May, 21:58, Frank GOENNINGER <······@googlemail.com> wrote:
>> Spiros Bousbouras <······@gmail.com> writes:
>>> Is there any standard way to distribute CL libraries without
>>> source? For example in C you would distribute object files with
>>> include headers. Is there anything similar in CL?
>> Yes. Compiled source files (which are often called "fasl files"). No
>> need to distribute separate header files - fasl files have all the info
>> in them for a lisp implementation to get information on functions and
>> such. And you can get that information also from the fasl files.
>
> If the functions have type declarations do the fasl files also contain
> those? In other words can someone receiving fasl files make sure
> that the functions are called with arguments of the right type?
Yes.
>> The name of the compiled files (actually, the filename ending) is
>> implementation dependent and may also be platform dependent (so there
>> are for example also .xfasl files - can't remember right now which
>> implementation that is).
>
> What about the format of the files? Is that also implementation
> dependent
Yes.
> or can fasl files produced with one implementation be used with
> another?
Most of the time, the fasl files are not even compatible across
different versions of the same implementation on the same platform.
I would recommend to forget about fasl files, and just distribute the
source code.
Pascal
--
ELS'09: http://www.european-lisp-symposium.org/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On May 17, 2:43 pm, Pascal Costanza <····@p-cos.net> wrote:
>
> I would recommend to forget about fasl files, and just distribute the
> source code.
Yes. You pretty much have to given the rate at which some
implementations update their fasl formats.
But I suppose it wouldn't be that hard to write a source obfuscator
for Lisp. Someone has probably done it...
-- Scott
Scott Burson wrote:
> On May 17, 2:43 pm, Pascal Costanza <····@p-cos.net> wrote:
>> I would recommend to forget about fasl files, and just distribute the
>> source code.
>
> Yes. You pretty much have to given the rate at which some
> implementations update their fasl formats.
>
> But I suppose it wouldn't be that hard to write a source obfuscator
> for Lisp. Someone has probably done it...
there's always http://rot13.com/ :)
On 19 maio, 06:30, namekuseijin <···················@gmail.com> wrote:
> Scott Burson wrote:
> > On May 17, 2:43 pm, Pascal Costanza <····@p-cos.net> wrote:
> >> I would recommend to forget about fasl files, and just distribute the
> >> source code.
>
> > Yes. You pretty much have to given the rate at which some
> > implementations update their fasl formats.
>
> > But I suppose it wouldn't be that hard to write a source obfuscator
> > for Lisp. Someone has probably done it...
>
> there's alwayshttp://rot13.com/:)
The problem with any code obfuscator it that it is easily reversible.
And you will provide the source code for retrieving back the code.
I believe that this is a bad thing. Not that I care, I am probably
never going to distribute binaries without distributing their source.
From: Pascal J. Bourguignon
Subject: Re: Distributing Lisp libraries without source
Date:
Message-ID: <87tz3j2wix.fsf@galatea.local>
Spiros Bousbouras <······@gmail.com> writes:
> Is there any standard way to distribute CL libraries without
> source? For example in C you would distribute object files with
> include headers. Is there anything similar in CL?
If you really needed to distribute portable CL library binaries, then
I assume it means you have some non trivial code to _sell_ to some
well paying customers. In these conditions, you should have the
resources needed to develop a binary format to distribute, with a
portable CL loader to compile your binary library on the target CL
implementation. Of course, this binary library loader would have to
be distributed in source form, it would be better if it was freely
distributed anyways.
--
__Pascal Bourguignon__
On 17 May, 23:29, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Spiros Bousbouras <······@gmail.com> writes:
> > Is there any standard way to distribute CL libraries without
> > source? For example in C you would distribute object files with
> > include headers. Is there anything similar in CL?
>
> If you really needed to distribute portable CL library binaries, then
> I assume it means you have some non trivial code to _sell_ to some
> well paying customers.
That's the scenario I was thinking. Do you know of any company
which does or did this ?
> In these conditions, you should have the
> resources needed to develop a binary format to distribute, with a
> portable CL loader to compile your binary library on the target CL
> implementation.
So a precompiled library could not be distributed ?
> Of course, this binary library loader would have to
> be distributed in source form, it would be better if it was freely
> distributed anyways.
--
Who's your mama?
From: Pascal J. Bourguignon
Subject: Re: Distributing Lisp libraries without source
Date:
Message-ID: <87iqjz2vjg.fsf@galatea.local>
Spiros Bousbouras <······@gmail.com> writes:
> On 17 May, 23:29, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>> In these conditions, you should have the
>> resources needed to develop a binary format to distribute, with a
>> portable CL loader to compile your binary library on the target CL
>> implementation.
>
> So a precompiled library could not be distributed ?
Yes, it could. But you would have to provide an open source library to
load portably the precompiled library into any CL implementation.
--
__Pascal Bourguignon__
On May 18, 12:50 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Spiros Bousbouras <······@gmail.com> writes:
> > On 17 May, 23:29, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
> >> In these conditions, you should have the
> >> resources needed to develop a binary format to distribute, with a
> >> portable CL loader to compile your binary library on the target CL
> >> implementation.
>
> > So a precompiled library could not be distributed ?
>
> Yes, it could. But you would have to provide an open source library to
> load portably the precompiled library into any CL implementation.
... which, incidentally, is the situation you get with Java and CLR.
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
On 18 Mai, 10:11, Marco Antoniotti <·······@gmail.com> wrote:
> On May 18, 12:50 am, ····@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
> > Spiros Bousbouras <······@gmail.com> writes:
> > > On 17 May, 23:29, ····@informatimago.com (Pascal J. Bourguignon)
> > > wrote:
> > >> In these conditions, you should have the
> > >> resources needed to develop a binary format to distribute, with a
> > >> portable CL loader to compile your binary library on the target CL
> > >> implementation.
>
> > > So a precompiled library could not be distributed ?
>
> > Yes, it could. But you would have to provide an open source library to
> > load portably the precompiled library into any CL implementation.
>
> ... which, incidentally, is the situation you get with Java and CLR.
Which makes ABCL a viable option
ciao,
Jochen
On May 22, 1:57 pm, ····@crispylogics.com wrote:
> On 18 Mai, 10:11, Marco Antoniotti <·······@gmail.com> wrote:
>
>
>
> > On May 18, 12:50 am, ····@informatimago.com (Pascal J. Bourguignon)
> > wrote:
>
> > > Spiros Bousbouras <······@gmail.com> writes:
> > > > On 17 May, 23:29, ····@informatimago.com (Pascal J. Bourguignon)
> > > > wrote:
> > > >> In these conditions, you should have the
> > > >> resources needed to develop a binary format to distribute, with a
> > > >> portable CL loader to compile your binary library on the target CL
> > > >> implementation.
>
> > > > So a precompiled library could not be distributed ?
>
> > > Yes, it could. But you would have to provide an open source library to
> > > load portably the precompiled library into any CL implementation.
>
> > ... which, incidentally, is the situation you get with Java and CLR.
>
> Which makes ABCL a viable option
Yep. ABCL is a very interesting option. I just wish I had more time
to work on it. FTTB I will test my libraries on it and report bugs.
Cheers
--
Marco
ELS 2009 www.european-lisp-symposium.org
Spiros Bousbouras <······@gmail.com> writes:
> So a precompiled library could not be distributed ?
Well, you could.
But there wouldn't be a single format that would directly be
distributable.
One solution would be to provide binary formats for all combinations of
platform and lisp implementation you want to support. This might
involve implementation version as well.
Most libraries are distributed in source form simply to avoid the need
to provide such a multiplicity of compiled forms. Not to mention the
need to (sometimes) have multiple platforms available to do the
compilation. Some lisp implemenations (e.g., SBCL) do come with
cross-compilers, so that simplifies it a little bit.
But you would need to provide a variety of binary formats.
--
Thomas A. Russ, USC/Information Sciences Institute