santi | 1 Mar 12:13 2012

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

Hi,

Thanks to you and Mark for your answers, because I don’t know that adsf
exists. This is what I'm looking for.

I've tried to increasing the JVM memory but then I always obtain some memory
problems (stack overflow). I supposed that this problem is because this lisp
project try to load a lot of lisp files from some folders and abcl needs to
compile a lot of files. The only way to compile the project was using
Allegro CL or CLISP. With Allegro CL I use jlinker but there are little
documentation and with CLISP I use Jacol but the same problem.

No problem with the machine compiled files, because I'll run always with
abcl and Windows.

I'll try to compile all files and package with adsf and then try to load
some .fasl into java with abcl and trying to load some lisp functions into
java swing.

Thanks

-----Mensaje original-----
De: Alessio Stalla [mailto:alessiostalla <at> gmail.com] 
Enviado el: miércoles, 29 de febrero de 2012 12:18
Para: santi
CC: armedbear-devel <at> common-lisp.net
Asunto: Re: [armedbear-devel] compiling lisp files outside Java and calling
it after with abcl

On Wed, Feb 29, 2012 at 10:42 AM, santi <scarbonell <at> ono.com> wrote:
(Continue reading)

santi | 1 Mar 12:21 2012

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

Hi,

I'm working with a lisp software called "Babylon". Babylon is a software
from AI that works with frames, prolog....

What I'm trying to do is to load Babylon into a JVM and then call its
functions using a Java interface, for example Java Swing or AWT. This is why
I'm trying to use ABCL to load Babylon into JVM

Thanks

-----Mensaje original-----
De: santi [mailto:scarbonell <at> ono.com] 
Enviado el: jueves, 01 de marzo de 2012 12:13
Para: 'Alessio Stalla'
CC: 'armedbear-devel <at> common-lisp.net'
Asunto: RE: [armedbear-devel] compiling lisp files outside Java and calling
it after with abcl

Hi,

Thanks to you and Mark for your answers, because I don’t know that adsf
exists. This is what I'm looking for.

I've tried to increasing the JVM memory but then I always obtain some memory
problems (stack overflow). I supposed that this problem is because this lisp
project try to load a lot of lisp files from some folders and abcl needs to
compile a lot of files. The only way to compile the project was using
Allegro CL or CLISP. With Allegro CL I use jlinker but there are little
documentation and with CLISP I use Jacol but the same problem.
(Continue reading)

Blake McBride | 1 Mar 17:47 2012

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

Greetings,


To build ABCL you don't need Lisp.  All you have to do is go into the root of the ABCL distribution and type:  ant

This will create dist/abcl.jar which is all you need.

You can run ABCL with:  java -jar abcl.jar

If course, you must have apache ant installed first.  Ant is just a build program like "make".

Hope this helps.

Blake McBride


On Thu, Mar 1, 2012 at 5:13 AM, santi <scarbonell <at> ono.com> wrote:
Hi,

Thanks to you and Mark for your answers, because I don’t know that adsf
exists. This is what I'm looking for.

I've tried to increasing the JVM memory but then I always obtain some memory
problems (stack overflow). I supposed that this problem is because this lisp
project try to load a lot of lisp files from some folders and abcl needs to
compile a lot of files. The only way to compile the project was using
Allegro CL or CLISP. With Allegro CL I use jlinker but there are little
documentation and with CLISP I use Jacol but the same problem.

No problem with the machine compiled files, because I'll run always with
abcl and Windows.

I'll try to compile all files and package with adsf and then try to load
some .fasl into java with abcl and trying to load some lisp functions into
java swing.

Thanks

-----Mensaje original-----
De: Alessio Stalla [mailto:alessiostalla <at> gmail.com]
Enviado el: miércoles, 29 de febrero de 2012 12:18
Para: santi
CC: armedbear-devel <at> common-lisp.net
Asunto: Re: [armedbear-devel] compiling lisp files outside Java and calling
it after with abcl

On Wed, Feb 29, 2012 at 10:42 AM, santi <scarbonell <at> ono.com> wrote:
> Hi,
>
> Thanks for your help.
>
> Because I've a lot of problems of java memory and Truncated class files,
my
> intention is try to compile in the same platform with ABCL, but only
> compile, not to load from ABCL a file and then compile all files. If there
> are some way to compile all files with abcl and package... (I don't know
if
> exists).

First, if you have memory issues, you should try increasing the
maximum heap size of your JVM. The 64M default is increasingly
limiting for Java applications, and while Lisp apps tend to waste less
memory than Java apps with tons of frameworks, I myself raised the
heap size to 256M just to be sure.

That said, you can compile and not load the files on abcl. It depends
on what you're using to compile/load, with asdf it's a matter of using
'compile-op rather than 'load-op. But, the files you'll obtain will
only be loadable by abcl anyway, as Mark explains in his post on the
abcl blog. Still, splitting the compilation and the loading in two
different sessions might help with memory issues if you really can't
give more memory to the JVM.

Alessio


_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Alessio Stalla | 1 Mar 23:46 2012
Picon

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

On Thu, Mar 1, 2012 at 12:21 PM, santi <scarbonell <at> ono.com> wrote:
> Hi,
>
> I'm working with a lisp software called "Babylon". Babylon is a software
> from AI that works with frames, prolog....

Ok, let's try to be more scientific.
The only mentions of Babylon I could find from a quick Google search
date back to the late 90's. Is Babylon available for download
somewhere? Is someone actively developing it? From your words, it
seems like you're already running it on another Lisp implementation.
Is that the case? If yes, which implementation?

ABCL fully implements ANSI Common Lisp, but Babylon might use
implementation-specific extensions, or techniques like tail recursion
that don't work well on ABCL (since you're mentioning stack overflows,
that might be a reason).

> What I'm trying to do is to load Babylon into a JVM and then call its
> functions using a Java interface, for example Java Swing or AWT. This is why
> I'm trying to use ABCL to load Babylon into JVM

If everything else fails, you can always run Babylon where you're
running it now, develop a communication protocol to talk with it
remotely, and use a JVM client with ABCL speaking the same protocol to
do whatever GUI stuff you want. This is easier than it sounds in Lisp
because, security and efficiency concerns aside, you can just send
printed S-expressions back and forth.

Peace,
Alessio
santi | 2 Mar 09:59 2012

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

Hi alessio,

All you say it's correct.

Babylon was developed in 90's using MCL (Machintosh Common Lisp) but an
internal readme says that it is portable to another lisp implementations:
MCL, Allegro, CLisp, CMU, AKCL.... That is why I try to use jlinker with
allegro or Jacol with CLisp, but always, people says "try working with ABCL
because there are a big community and working...." and is a very powerfull
tool to translate lisp to java. The documentation of Jacol or jlinker is
very poor. It's suppose that Babylon it's only work on MAC, but there are a
light version to work with SUN, and this is the version that I'm trying to
compile and this is why I'm trying to add a java interface like Swing or
AWT.

I attach Babylon, if anyone wants to try to compile with ABCL. The only
think to compile is in make.cl and make-sun.cl to put some paths to your
folders in your PC. For example in make.cl in the first line I put this to
compile in D:\ folder

	#-:MCL "D:\\Babylon\\"   ;;; <--- change the pathname string
here!!!! 

If it's not possible to compile with ABCL, how do you try to do a
communication protocol? Some idea or example? Web Services....?

Thanks for your help

-----Mensaje original-----
De: Alessio Stalla [mailto:alessiostalla <at> gmail.com] 
Enviado el: jueves, 01 de marzo de 2012 23:46
Para: santi
CC: armedbear-devel <at> common-lisp.net
Asunto: Re: [armedbear-devel] compiling lisp files outside Java and calling
it after with abcl

On Thu, Mar 1, 2012 at 12:21 PM, santi <scarbonell <at> ono.com> wrote:
> Hi,
>
> I'm working with a lisp software called "Babylon". Babylon is a software
> from AI that works with frames, prolog....

Ok, let's try to be more scientific.
The only mentions of Babylon I could find from a quick Google search
date back to the late 90's. Is Babylon available for download
somewhere? Is someone actively developing it? From your words, it
seems like you're already running it on another Lisp implementation.
Is that the case? If yes, which implementation?

ABCL fully implements ANSI Common Lisp, but Babylon might use
implementation-specific extensions, or techniques like tail recursion
that don't work well on ABCL (since you're mentioning stack overflows,
that might be a reason).

> What I'm trying to do is to load Babylon into a JVM and then call its
> functions using a Java interface, for example Java Swing or AWT. This is
why
> I'm trying to use ABCL to load Babylon into JVM

If everything else fails, you can always run Babylon where you're
running it now, develop a communication protocol to talk with it
remotely, and use a JVM client with ABCL speaking the same protocol to
do whatever GUI stuff you want. This is easier than it sounds in Lisp
because, security and efficiency concerns aside, you can just send
printed S-expressions back and forth.

Peace,
Alessio
Attachment (Babylon-2.3.rar): application/octet-stream, 1716 KiB
_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Blake McBride | 2 Mar 17:33 2012

Re: [armedbear-devel] compiling lisp files outside Java and calling it after with abcl

Greetings Santi,


Speaking for myself, RAR format is a real problem.  Every time I have to use it it is a research project.  It seams like TAR, ZIP or JAR would be a far more convenient format since these formats are widely available and used on any operating system.

Just my 2 cents.

Thanks.

Blake McBride


On Fri, Mar 2, 2012 at 2:59 AM, santi <scarbonell <at> ono.com> wrote:
Hi alessio,

All you say it's correct.

Babylon was developed in 90's using MCL (Machintosh Common Lisp) but an
internal readme says that it is portable to another lisp implementations:
MCL, Allegro, CLisp, CMU, AKCL.... That is why I try to use jlinker with
allegro or Jacol with CLisp, but always, people says "try working with ABCL
because there are a big community and working...." and is a very powerfull
tool to translate lisp to java. The documentation of Jacol or jlinker is
very poor. It's suppose that Babylon it's only work on MAC, but there are a
light version to work with SUN, and this is the version that I'm trying to
compile and this is why I'm trying to add a java interface like Swing or
AWT.

I attach Babylon, if anyone wants to try to compile with ABCL. The only
think to compile is in make.cl and make-sun.cl to put some paths to your
folders in your PC. For example in make.cl in the first line I put this to
compile in D:\ folder

       #-:MCL "D:\\Babylon\\"   ;;; <--- change the pathname string
here!!!!

If it's not possible to compile with ABCL, how do you try to do a
communication protocol? Some idea or example? Web Services....?

Thanks for your help

-----Mensaje original-----
De: Alessio Stalla [mailto:alessiostalla <at> gmail.com]
Enviado el: jueves, 01 de marzo de 2012 23:46
Para: santi
CC: armedbear-devel <at> common-lisp.net
Asunto: Re: [armedbear-devel] compiling lisp files outside Java and calling
it after with abcl

On Thu, Mar 1, 2012 at 12:21 PM, santi <scarbonell <at> ono.com> wrote:
> Hi,
>
> I'm working with a lisp software called "Babylon". Babylon is a software
> from AI that works with frames, prolog....

Ok, let's try to be more scientific.
The only mentions of Babylon I could find from a quick Google search
date back to the late 90's. Is Babylon available for download
somewhere? Is someone actively developing it? From your words, it
seems like you're already running it on another Lisp implementation.
Is that the case? If yes, which implementation?

ABCL fully implements ANSI Common Lisp, but Babylon might use
implementation-specific extensions, or techniques like tail recursion
that don't work well on ABCL (since you're mentioning stack overflows,
that might be a reason).

> What I'm trying to do is to load Babylon into a JVM and then call its
> functions using a Java interface, for example Java Swing or AWT. This is
why
> I'm trying to use ABCL to load Babylon into JVM

If everything else fails, you can always run Babylon where you're
running it now, develop a communication protocol to talk with it
remotely, and use a JVM client with ABCL speaking the same protocol to
do whatever GUI stuff you want. This is easier than it sounds in Lisp
because, security and efficiency concerns aside, you can just send
printed S-expressions back and forth.

Peace,
Alessio

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel


_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
santi | 6 Mar 21:03 2012

Re: [armedbear-devel] compiled errors: debug.assertTrue()

Alesio,

Got compile the file?

Thanks

-----Mensaje original-----
De: Alessio Stalla [mailto:alessiostalla <at> gmail.com] 
Enviado el: martes, 28 de febrero de 2012 13:53
Para: scarbonell <at> ono.com
CC: armedbear-devel <at> common-lisp.net
Asunto: Re: [armedbear-devel] compiled errors: debug.assertTrue()

Hi,

I'm astalla on the LispForum, sorry for not answering there.
The fmcs.bin looks suspicious to me, how exactly are you compiling the
file? Are you specifying the name of the output file? Try omitting it
if that's the case and see if anything changes. Anyway I'll try it by
myself this evening, I'll let you know if I find out what's going
wrong.

Regards,
Alessio

On Tue, Feb 28, 2012 at 12:28 PM, scarbonell <at> ono.com <scarbonell <at> ono.com>
wrote:
> Hi,
>
> When I try to compile the mcs-core.cl file (attached) with java abcl, I
get
> this error:
>
> Failed to get InputStream for
> 'jar:file:D:/otro/kernel/modules/fmcs.bin!/mcs_core_4.cls'
> ABCL Debug.assertTrue() assertion failed!
> java.lang.Error: ABCL Debug.assertTrue() assertion failed!
>
>
>
> Why is this happening? How can I resolved it?
>
>
>
> Thanks
Mark Evenson | 21 Mar 11:50 2012
Picon

[armedbear-devel] ABCL on jdk-1.7.0_03

I've just run abcl-1.1.0-dev the ANSI-COMPILED tests on jdk-1.7.0_03
with reasonable looking results of 31 failures, which is roughly
the same number as those run with jdk-1.6.0_31 (some of the tests
use randomly generated data so they sometimes either fail or succeed).

Previously, I think that we weren't even completing the ANSI-COMPILED
test suite due to issues in the character set encoding, so I think
we should now more fully endorse running ABCL on Java7.
Pascal J. Bourguignon | 26 Mar 18:12 2012
X-Face
Face

[armedbear-devel] run-program :environment nil


(lisp-implementation-version) --> "1.0.1"

The documentation of extensions:run-program is misleading:

    :environment 
        An alist of STRINGs (name . value) describing the new
        environment. The default is to copy the environment of the current
        process.

The alist doesn't describe the NEW environment, it is only MERGED into
the current environment.

Now of course, I consider the current behavior to be a bug:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ("NNTPSERVER=news.individual.net" "ESHELL=/bin/bash"  …)

I would expect:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment 'nil)))
    --> ()

and:

    (text-stream-contents (extensions:process-output
                           (extensions:run-program "env" '()
                                                   :wait t :environment
                                                   '(("LC_CTYPE" . "C")))))
    --> ("LC_CTYPE=C"))

Which would match what the documentation says.

Also, in a shell environment, an empty variable is not the same as an
inexistant variable, so I cannot just loop over all the existing
variables to set them to an empty string.  I see no
SYSTEM::%PROCESS-BUILDER-ENV-REM function…

--

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/
A bad day in () is better than a good day in {}.

_______________________________________________
armedbear-devel mailing list
armedbear-devel <at> common-lisp.net
http://lists.common-lisp.net/cgi-bin/mailman/listinfo/armedbear-devel
Mark Evenson | 27 Mar 14:26 2012
Picon

Re: [armedbear-devel] run-program :environment nil


On Mar 26, 2012, at 6:12 PM, Pascal J. Bourguignon wrote:

> 
> (lisp-implementation-version) --> "1.0.1"
> 
> 
> The documentation of extensions:run-program is misleading:
> 
>    :environment 
>        An alist of STRINGs (name . value) describing the new
>        environment. The default is to copy the environment of the current
>        process.
> 
> The alist doesn't describe the NEW environment, it is only MERGED into
> the current environment.

[…]

Which behavior would you prefer?

We certainly have imprecise documentation here.  The merged environment
behavior what is easiest with the underlying JVM API which is based
on the notion of UNIX exec().  In practice, I would venture that
that most people would expect the merged behavior, as it is the
common pattern for such wrappers around UNIX execv() and friends
which have to copy the environment anyways at an operating system
level before it replaces it with the new code.  (Ok, since every
contemporary OS probably has "copy-on-write" semantics here, I'll
stop making OS-dependent statements of doubtful utility).

I would advocate tightening the documentation.  If Pascal has a
further need here, I'll take a stab at a version which would somehow
"wipe" the inherited environment.

Since the semantics of our EXT:RUN-PROGRAM implementation were
cribbed from SBCL's under the need to implement just as much as
ASDF2 required, we should analyze what SBCL does in this situation
as well.

> Also, in a shell environment, an empty variable is not the same as an
> inexistant variable, so I cannot just loop over all the existing
> variables to set them to an empty string.  I see no
> SYSTEM::%PROCESS-BUILDER-ENV-REM function…

This sounds like you really want the ability to constructs a clean
NEW environment.  If we were able to implement that, would your
need to iterate through existing variables disappear?

Gmane