ArmedBear / J

Further testing shows the problem is this line:
(defvar recompile nil)

Somehow that makes the recompile keyword parameter below not work.

(defun compile-ap5 (&key recompile nevercompile info ask
 ...

Don Cohen wrote:

Filed as [issue 15][1]

[1]: http://trac.common-lisp.net/armedbear/ticket/15

I rewrote your test case to the simplest possible showing the error.  If 
you think you have other errant behavior that I missed, let us know.

Thanks for the bug report!

Mark
-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

Don Cohen wrote:
[…]
> 
> BTW, I think defpackage is not working right either, since I found
> that I got different results reloading the code below (which does
> defpackage) than exiting and restarting abcl.

DEFPACKAGE currently doesn't "redefine" packages, meaning that ABCL will 
ignore any subsequent DEFPACKAGE form for an already defined package. 
Interestingly this behavior is allowed by ANSI, but no other CL 
implementation has this behavior.  Could this explain the behavior you see?

> While I'm at it, is multiprocessing (multithreading) supported in
> abcl?  If so, what interfaces are supported?

Insofar that Java is inherently multithreaded and you can create 
arbitrary object ABCL supports threading, but I don't think much 
"thought" has been given to what sort of effects multiple threads of 
dispatch would have.

There are some primitives (MAKE-THREAD, MAPCAR-THREADS, …) that show up 
in LispThread.java plus a mailbox data structure in Mailbox.java that 
sort of handles message synchronization patterns, but I have never 
gotten much further than demonstrating that I could fire off separating 
different threads of control.  If you get any experience, please report 
back here.

Mark Evenson writes:

 > [1]: http://trac.common-lisp.net/armedbear/ticket/15
Thanks, I was not aware of such a bug list.
Will I be notified when it's fixed?
Any idea when that might be?
I'd very much like to be able to port the rest of this app 
(see ap5.com)  Previous experience suggests that it also makes
a good test case for a lisp implementation.
Also I'd appreciate answers to questions about multiprocessing.
I don't see that post in 
http://sourceforge.net/mailarchive/forum.php?forum_name=armedbear-j-devel
I wonder why not.

DEFPACKAGE currently doesn't "redefine" packages, meaning that ABCL
  will ignore any subsequent DEFPACKAGE form for an already defined
  package.  Interestingly this behavior is allowed by ANSI, but no
  other CL implementation has this behavior.  Could this explain the
  behavior you see?
It sure could!  Fortunately I don't think I actually rely on that
redefinition, other than in attempting to debug.
I guess it would suffice to delete the package and then recreate it.

  Insofar that Java is inherently multithreaded and you can create
  arbitrary object ABCL supports threading, but I don't think much
  "thought" has been given to what sort of effects multiple threads
  of dispatch would have.

Lisp implementations that support threads normally provide a little
more support in order to limit the amount of understanding of the 
underlying implementation needed in order to use threads.
For instance, two user threads should be able to intern into the same
package without the user having to introduce a lock.

I'll start without multiple processes.

Don Cohen wrote:
> Mark Evenson writes:
> 
>  > [1]: http://trac.common-lisp.net/armedbear/ticket/15
> Thanks, I was not aware of such a bug list.
> Will I be notified when it's fixed?
> Any idea when that might be?

Such a bug list is very new (less than a week).

You can subscribe to the [RSS feed associated with this bug][15], to be 
  notified.

We do not currently have a release schedule or priorities assigned to 
bugs, so we can't tell you when it will be fixed.  Without having looked 
at the ABCL compiler with respect to your problem, I think this kind of 
error would either be fairly easy to fix but when one of us gets the 
time to look at this cannot be promised.

[15]: feed://trac.common-lisp.net/armedbear/ticket/15?format=rss

[…]
> I don't see that post in 
> http://sourceforge.net/mailarchive/forum.php?forum_name=armedbear-j-devel
> I wonder why not.

It appears that the sourceforge archive has stopped updating that 
particular "view" (our posts are appearing in [other views][1]. 
Personally, I would use the much nicer [gmane view][2] to read the archives.

[1]: 
http://sourceforge.net/mailarchive/forum.php?set=custom&viewmonth=200810&viewday=27&forum_name=armedbear-j-devel&style=threaded&max_rows=100&submit=Change+View


[2]: http://news.gmane.org/gmane.editors.j.devel

-- 
"A screaming comes across the sky.  It has happened before, but there is
nothing to compare to it now."

On Mon, 27 Oct 2008, Mark Evenson wrote:

> There are some primitives (MAKE-THREAD, MAPCAR-THREADS, ?) that show up
> in LispThread.java plus a mailbox data structure in Mailbox.java that
> sort of handles message synchronization patterns, but I have never
> gotten much further than demonstrating that I could fire off separating
> different threads of control.  If you get any experience, please report
> back here.

Multithreading is used in ABCL's support for Slime. Mailbox, in
particular, was included to satisfy Slime's needs. At least AFAIR. So
you may have some experience with MT in ABCL, after all.

Andras

Thanks, I filed this as ticket #22.

Bye,

Erik.

On Mon, Oct 27, 2008 at 12:38 AM, Don Cohen
<don-sourceforge-xxz@...> wrote:
>
> Further testing shows the problem is this line:
> (defvar recompile nil)
>
> Somehow that makes the recompile keyword parameter below not work.
>
> (defun compile-ap5 (&key recompile nevercompile info ask
>  ...
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> armedbear-j-devel mailing list
> armedbear-j-devel@...
> https://lists.sourceforge.net/lists/listinfo/armedbear-j-devel
>