Qi on ABCL

10 messages Options
Embed this post
Permalink
Alessio Stalla

Qi on ABCL

Reply Threaded More More options
Print post
Permalink
Hello Mark,

as promised, I made a quick attempt at running Qi on ABCL. I'm CC'ing
the ABCL mailing list.

I've gotten Qi to load (but only interpreted, see below), just making
trivial modifications to "Qi 9.2.txt" (basically just adding a few
read-time conditionals for ABCL). If I understood it correctly this is
not Qi's source but is rather auto-generated from another file,
however I don't know how to do the generation myself, so I directly
modified the end product - it should be easy to backport my little
fixes to the source.

However, Qi is not working properly. (qi::qi) gives me the Qi REPL: if
I type simple expressions at the REPL, like (and true false), it gives
me errors about undefined functions (e.g. and in the case before). I
initially thought it was the thing you mentioned - the readtable
behavior reverting to upcase somewhere - since for non-alphabetic
functions, like mathematical operators, things work smoothly. However,
evaluting this:

(READTABLE-CASE (EVAL *READTABLE*))

returns :PRESERVE, so it seems the readtable is set up ok while Qi is
running. Then I investigated a little bit more and discovered it's
actually a package problem: prefixing all symbols with qi: works. In
fact, (EVAL *PACKAGE*) ==> #<PACKAGE "COMMON-LISP-USER">

I don't know how to fix this, but maybe you can point me to the right direction.
I've also seen test suites in the Qi directory but I don't know how to
run them (should I just load them?).

Instead, regarding compilation:

1. I spotted a bug in ABCL that prevented it to correctly compiling
files with a space in their name (the generated Java class contained
the space in its name and this is not valid).
2. ABCL's compiled files usually (always?) have a textual prologue
with a few Lisp forms that load the actual code. This textual prologue
starts with a commented Emacs mode-line. Since Qi redefines ; to be a
regular character, ABCL chokes when loading Qi interpreted (which
changes the meaning of ;) and then Qi compiled. I temporarily
commented out the code writing the mode-line in my copy of ABCL.
3. After fixing 1. and 2., loading the compiled file works up to a
certain point, then it basically crashes without much explanation
("maximum error depth exceeded"??). However, while loading it
complains about the redefinition of many Common Lisp operators, so
maybe the problem is related to packages just like in the interpreted
case.

In summary, we could be a little step away from Qi working on ABCL, if
it all amounts to an incorrect handling of packages. Yes, I'm being
too optimistic today :)

Cheers,
Alessio

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Kevin Reid

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On May 31, 2009, at 8:37, Alessio Stalla wrote:

> 2. ABCL's compiled files usually (always?) have a textual prologue
> with a few Lisp forms that load the actual code. This textual prologue
> starts with a commented Emacs mode-line. Since Qi redefines ; to be a
> regular character, ABCL chokes when loading Qi interpreted (which
> changes the meaning of ;) and then Qi compiled. I temporarily
> commented out the code writing the mode-line in my copy of ABCL.

This sounds like an ABCL bug: recognition of compiled files ought not  
to depend on the current readtable, yes?

(However, CLHS just says of LOAD that "The manner in which a source  
file is distinguished from a compiled file is implementation-
dependent.")

--
Kevin Reid                            <http://homepage.mac.com/kpreid/>



------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Alessio Stalla

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On Sun, May 31, 2009 at 2:56 PM, Kevin Reid <[hidden email]> wrote:

> On May 31, 2009, at 8:37, Alessio Stalla wrote:
>
>> 2. ABCL's compiled files usually (always?) have a textual prologue
>> with a few Lisp forms that load the actual code. This textual prologue
>> starts with a commented Emacs mode-line. Since Qi redefines ; to be a
>> regular character, ABCL chokes when loading Qi interpreted (which
>> changes the meaning of ;) and then Qi compiled. I temporarily
>> commented out the code writing the mode-line in my copy of ABCL.
>
> This sounds like an ABCL bug: recognition of compiled files ought not
> to depend on the current readtable, yes?
>
> (However, CLHS just says of LOAD that "The manner in which a source
> file is distinguished from a compiled file is implementation-
> dependent.")
>

The problem is not how abcl distinguishes a source file from a
compiled one, but how the compiled code interacts with the readtable
while loaded.
The hyperspec just says: "load binds *readtable* and *package* to the
values they held before loading the file".
In Qi's case, the readtable is the default one (no copy-readtable is
ever done afaik). When loading Qi interpreted, the form
(SET-SYNTAX-FROM-CHAR #\; #\v) is evaluated, and the default readtable
is side-effected. Then the same readtable is used while loading the
compiled file, and this is what causes the problem. (Apparently it is
necessary for Qi to be loaded first in order to compile Qi itself).

So, the default readtable being used is not an ABCL bug imho; it's
probably what other implementations do as well. What is a little more
dubious is ABCL inserting something in the compiled file (the mode
line) which was not there in the source file, and which can have
unforeseen behavior if the readtable happens to be modified. On the
other hand, even if abcl didn't do so, things could go equally wrong
if some code redefined e.g. the syntax associated with the open paren
#\( , so probably it is really Qi's behavior (modifying the readtable
without first copying it) which is questionable. Since the fix was
easy, I didn't ask Mark to change Qi but directly modified abcl.
Probably the safest thing to do is to control whether the mode line is
output looking at some variable. Qi could then set this variable to
its liking, while the default would remain what abcl does now.

Alessio

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Robert Dodier

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
In reply to this post by Alessio Stalla

--- On Sun, 5/31/09, Alessio Stalla <[hidden email]> wrote:

> Probably the safest thing to do is to control whether the
> mode line is output looking at some variable. Qi could
> then set this variable to its liking, while the default
> would remain what abcl does now.

I dunno. Introducing another global variable just increases
confusion with little benefit. I'll advise against it.

Sounds like resolving the problem is up to Qi; I don't see
why ABCL shouldn't be able to emit arbitrary junk into its
compiled files. Be that as it may, in the interest of playing
nice with Qi, ABCL might suppress the mode line. But it
should be unconditional, either always or never.

Watching from the sidelines,

Robert Dodier



     

------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp as they present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com 
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Alessio Stalla

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
The problem is non-existent, since I was actually trying the wrong
version of Qi... the current one does not have the problem. But, in
general, I agree that adding a new variable for such an insignificant
thing would be overkill.

Bye,
Alessio

On Mon, Jun 1, 2009 at 6:55 PM, Robert Dodier <[hidden email]> wrote:

>
> --- On Sun, 5/31/09, Alessio Stalla <[hidden email]> wrote:
>
>> Probably the safest thing to do is to control whether the
>> mode line is output looking at some variable. Qi could
>> then set this variable to its liking, while the default
>> would remain what abcl does now.
>
> I dunno. Introducing another global variable just increases
> confusion with little benefit. I'll advise against it.
>
> Sounds like resolving the problem is up to Qi; I don't see
> why ABCL shouldn't be able to emit arbitrary junk into its
> compiled files. Be that as it may, in the interest of playing
> nice with Qi, ABCL might suppress the mode line. But it
> should be unconditional, either always or never.
>
> Watching from the sidelines,
>
> Robert Dodier
>
>
>
>
>

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Alessio Stalla

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
In reply to this post by Alessio Stalla
Ok, I've tried Qi II...

I found out the problem with the readtable case:
ABCL uses an ad-hoc readtable for loading compiled code ("fasl"
files). These files consist partly of textual Lisp forms, partly of
binary files for compiled functions. So the textual code when read
back is read with default readtable settings, including :upcase
behavior, even if some symbols to be read are not uppercase.
To circumvent the problem, I changed the fasl readtable to have a
default case of :preserve instead of :upcase. This fixes the issue
with Qi and should not give other problems, since this readtable is
only used to read back printed Lisp code, which has already the
correct case.
However, probably the optimal solution would be to both write and read
the fasl code with default i/o settings, since case is not the only
possible source of confusion: *print-base* comes to my mind, for
example.

Qi II has still the other issue Qi had: the Qi REPL is run in package
:cl-user instead of :qi. However, I launch the REPL myself with
(qi::qi) since I have no saved image, so maybe I'm missing the fact
that the qi function expects to be called when *package* is already
:qi.

Apart from that, things seems to run fine. I've only tried some
snippets from the 15-min tutorial though. If you have some test suite
to verify Qi is functioning properly, let me know.

Bye,
Alessio

On Mon, Jun 1, 2009 at 11:06 AM, Alessio Stalla <[hidden email]> wrote:

> Oh, sorry, you're right! I downloaded it from the Google Code page,
> and I didn't look at the lambda associates page... well, it helped
> uncover a bug in abcl, so, it wasn't completely wasted time :)
>
> Now, on to Qi II...
>
> Bye,
> Alessio
>
> On Mon, Jun 1, 2009 at 2:10 AM, Mark Tarver <[hidden email]> wrote:
>> Hi,
>>
>> You're running a very old Qi there.  Qi I; Qi II is the one to use. Actually
>> in Qi II ; is not redefined by SET-SYNTAX..,
>> though the readtable is made case preserving.
>>
>> Mark
>> ----- Original Message ----- From: "Alessio Stalla"
>> <[hidden email]>
>> To: <[hidden email]>
>> Cc: <[hidden email]>
>> Sent: Sunday, May 31, 2009 1:37 PM
>> Subject: Qi on ABCL
>>
>>
>>> Hello Mark,
>>>
>>> as promised, I made a quick attempt at running Qi on ABCL. I'm CC'ing
>>> the ABCL mailing list.
>>>
>>> I've gotten Qi to load (but only interpreted, see below), just making
>>> trivial modifications to "Qi 9.2.txt" (basically just adding a few
>>> read-time conditionals for ABCL). If I understood it correctly this is
>>> not Qi's source but is rather auto-generated from another file,
>>> however I don't know how to do the generation myself, so I directly
>>> modified the end product - it should be easy to backport my little
>>> fixes to the source.
>>>
>>> However, Qi is not working properly. (qi::qi) gives me the Qi REPL: if
>>> I type simple expressions at the REPL, like (and true false), it gives
>>> me errors about undefined functions (e.g. and in the case before). I
>>> initially thought it was the thing you mentioned - the readtable
>>> behavior reverting to upcase somewhere - since for non-alphabetic
>>> functions, like mathematical operators, things work smoothly. However,
>>> evaluting this:
>>>
>>> (READTABLE-CASE (EVAL *READTABLE*))
>>>
>>> returns :PRESERVE, so it seems the readtable is set up ok while Qi is
>>> running. Then I investigated a little bit more and discovered it's
>>> actually a package problem: prefixing all symbols with qi: works. In
>>> fact, (EVAL *PACKAGE*) ==> #<PACKAGE "COMMON-LISP-USER">
>>>
>>> I don't know how to fix this, but maybe you can point me to the right
>>> direction.
>>> I've also seen test suites in the Qi directory but I don't know how to
>>> run them (should I just load them?).
>>>
>>> Instead, regarding compilation:
>>>
>>> 1. I spotted a bug in ABCL that prevented it to correctly compiling
>>> files with a space in their name (the generated Java class contained
>>> the space in its name and this is not valid).
>>> 2. ABCL's compiled files usually (always?) have a textual prologue
>>> with a few Lisp forms that load the actual code. This textual prologue
>>> starts with a commented Emacs mode-line. Since Qi redefines ; to be a
>>> regular character, ABCL chokes when loading Qi interpreted (which
>>> changes the meaning of ;) and then Qi compiled. I temporarily
>>> commented out the code writing the mode-line in my copy of ABCL.
>>> 3. After fixing 1. and 2., loading the compiled file works up to a
>>> certain point, then it basically crashes without much explanation
>>> ("maximum error depth exceeded"??). However, while loading it
>>> complains about the redefinition of many Common Lisp operators, so
>>> maybe the problem is related to packages just like in the interpreted
>>> case.
>>>
>>> In summary, we could be a little step away from Qi working on ABCL, if
>>> it all amounts to an incorrect handling of packages. Yes, I'm being
>>> too optimistic today :)
>>>
>>> Cheers,
>>> Alessio
>>>
>>
>>
>

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Erik Huelsmann

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> wrote:
> Ok, I've tried Qi II...
>
> I found out the problem with the readtable case:
> ABCL uses an ad-hoc readtable for loading compiled code ("fasl"
> files). These files consist partly of textual Lisp forms, partly of
> binary files for compiled functions. So the textual code when read
> back is read with default readtable settings, including :upcase
> behavior, even if some symbols to be read are not uppercase.

Well, the problem is a little bit deeper:

(intern "a")
--> |a|

however, if you run

(dump-form t (intern "a"))

I don't expect you to see "|a|", based on what I see in
Symbol.writeToString() and the fact that %stream-output-object
effectively uses that to produce its output.

I think that's the deeper issue we're looking at here.

> To circumvent the problem, I changed the fasl readtable to have a
> default case of :preserve instead of :upcase. This fixes the issue
> with Qi and should not give other problems, since this readtable is
> only used to read back printed Lisp code, which has already the
> correct case.

Well, since it's our FASL format and our reader, I guess we can work
with this workaround for now. Could you commit it please. When you do,
I'll file an issue on our issue(s)  with writeToString() and the fact
that it differs from using PRINT.

> However, probably the optimal solution would be to both write and read
> the fasl code with default i/o settings, since case is not the only
> possible source of confusion: *print-base* comes to my mind, for
> example.

Well, the issue is not the default reader settings, but the problem
that the "|" characters don't get added in the right place.

As I said before: I have an issue with the fact that we have all these
writeToString things: they are generally incompatible with regular
PRINT code. Next to that it's not completely transparent (to me) when
the regular PRINT code is being used and when the writeToString stuff.

> Qi II has still the other issue Qi had: the Qi REPL is run in package
> :cl-user instead of :qi. However, I launch the REPL myself with
> (qi::qi) since I have no saved image, so maybe I'm missing the fact
> that the qi function expects to be called when *package* is already
> :qi.
>
> Apart from that, things seems to run fine. I've only tried some
> snippets from the 15-min tutorial though. If you have some test suite
> to verify Qi is functioning properly, let me know.

Thanks for taking your time to have this evaluation! Let's get Qi
working soon and add it to our list of "known working" programs!

Bye,

Erik.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Alessio Stalla

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On Tue, Jun 2, 2009 at 9:39 AM, Erik Huelsmann <[hidden email]> wrote:

> On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> wrote:
>> Ok, I've tried Qi II...
>>
>> I found out the problem with the readtable case:
>> ABCL uses an ad-hoc readtable for loading compiled code ("fasl"
>> files). These files consist partly of textual Lisp forms, partly of
>> binary files for compiled functions. So the textual code when read
>> back is read with default readtable settings, including :upcase
>> behavior, even if some symbols to be read are not uppercase.
>
> Well, the problem is a little bit deeper:
>
> (intern "a")
> --> |a|
>
> however, if you run
>
> (dump-form t (intern "a"))
>
> I don't expect you to see "|a|", based on what I see in
> Symbol.writeToString() and the fact that %stream-output-object
> effectively uses that to produce its output.
>
> I think that's the deeper issue we're looking at here.

Hmm, I see.

>> To circumvent the problem, I changed the fasl readtable to have a
>> default case of :preserve instead of :upcase. This fixes the issue
>> with Qi and should not give other problems, since this readtable is
>> only used to read back printed Lisp code, which has already the
>> correct case.
>
> Well, since it's our FASL format and our reader, I guess we can work
> with this workaround for now. Could you commit it please. When you do,
> I'll file an issue on our issue(s)  with writeToString() and the fact
> that it differs from using PRINT.

Sure. I'll also commit the fix for class-name-from-filespec in
jvm.lisp which included spaces in the class name.

>> However, probably the optimal solution would be to both write and read
>> the fasl code with default i/o settings, since case is not the only
>> possible source of confusion: *print-base* comes to my mind, for
>> example.
>
> Well, the issue is not the default reader settings, but the problem
> that the "|" characters don't get added in the right place.

Ok, thanks for clarifying this.

> As I said before: I have an issue with the fact that we have all these
> writeToString things: they are generally incompatible with regular
> PRINT code. Next to that it's not completely transparent (to me) when
> the regular PRINT code is being used and when the writeToString stuff.

What if writeToString() simply called PRINT?

>> Qi II has still the other issue Qi had: the Qi REPL is run in package
>> :cl-user instead of :qi. However, I launch the REPL myself with
>> (qi::qi) since I have no saved image, so maybe I'm missing the fact
>> that the qi function expects to be called when *package* is already
>> :qi.
>>
>> Apart from that, things seems to run fine. I've only tried some
>> snippets from the 15-min tutorial though. If you have some test suite
>> to verify Qi is functioning properly, let me know.
>
> Thanks for taking your time to have this evaluation! Let's get Qi
> working soon and add it to our list of "known working" programs!

Yes, I believe we're close.

Bye,
Alessio

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Erik Huelsmann

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On Tue, Jun 2, 2009 at 11:47 AM, Alessio Stalla <[hidden email]> wrote:

> On Tue, Jun 2, 2009 at 9:39 AM, Erik Huelsmann <[hidden email]> wrote:
>> On Tue, Jun 2, 2009 at 2:52 AM, Alessio Stalla <[hidden email]> wrote:
>>> Ok, I've tried Qi II...
>>>
>>> I found out the problem with the readtable case:
>>> ABCL uses an ad-hoc readtable for loading compiled code ("fasl"
>>> files). These files consist partly of textual Lisp forms, partly of
>>> binary files for compiled functions. So the textual code when read
>>> back is read with default readtable settings, including :upcase
>>> behavior, even if some symbols to be read are not uppercase.
>>
>> Well, the problem is a little bit deeper:
>>
>> (intern "a")
>> --> |a|
>>
>> however, if you run
>>
>> (dump-form t (intern "a"))
>>
>> I don't expect you to see "|a|", based on what I see in
>> Symbol.writeToString() and the fact that %stream-output-object
>> effectively uses that to produce its output.
>>
>> I think that's the deeper issue we're looking at here.
>
> Hmm, I see.

Well, I looked closer at the issue and when run from the REPL,
(dump-form (intern "a") *standard-output*) produces |a| as expected.
So, it looks like something in Qi may be binding *print-escape* or
*print-readably* to NIL and DUMP-FORM isn't installing a binding of
its own.

I'll do some tests this evening at home, if you can describe to me
what steps I need to take to be able to run Qi II.

With kind regards,


Erik.

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
Alessio Stalla

Re: Qi on ABCL

Reply Threaded More More options
Print post
Permalink
On Wed, Jun 3, 2009 at 1:27 PM, Erik Huelsmann <[hidden email]> wrote:
> Well, I looked closer at the issue and when run from the REPL,
> (dump-form (intern "a") *standard-output*) produces |a| as expected.
> So, it looks like something in Qi may be binding *print-escape* or
> *print-readably* to NIL and DUMP-FORM isn't installing a binding of
> its own.
>
> I'll do some tests this evening at home, if you can describe to me
> what steps I need to take to be able to run Qi II.

You should be able to run Qi II by doing the following:

1. download Qi II from the lambdassociates.org website (not the one on
Google Code which is an old version)
2. put the files attached to this mail in the Lisp folder, overwriting
existing files
3. start up abcl and load install.lsp (which compiles Qi and quits abcl)
4. load run_abcl.lsp

you should get at the Qi prompt. Evaluating (and true false)
lowercased should give false (duh). You can load test.qi to run test
code.

That's all.

Bye,
Ale




------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
armedbear-j-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel

install.lsp (3K) Download Attachment
features_load_1.lsp (8K) Download Attachment
run_abcl.lsp (952 bytes) Download Attachment