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:

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.

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

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

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

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

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

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

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

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

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

[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

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?