ArmedBear / J

(sorry for the previous incorrect post)

I gather this is the place to post bugs.
I'm trying to port a program that I currently use mainly in clisp.
Below is the first bug I hit.  I've reduced it quite a ways so I
think you should have little trouble reproducing and understanding it.

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.

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


==== transcript

/tmp/abcl-src-0.0.11/abcl
Armed Bear Common Lisp 0.0.11 (built Sun Oct 26 2008 13:31:54 -0800)
Java 1.5.0_10 Sun Microsystems Inc.
Java HotSpot(TM) Client VM
Low-level initialization completed in 0.448 seconds.
Startup completed in 1.674 seconds.
Type ":help" for a list of available commands.
CL-USER(1): (load "/tmp/build1")
#<PACKAGE "AP5">
INFO
ASK
RECOMPILE
NEVERCOMPILE
*CHANGED*
STARTFILE
STOPFILE
*START-TIME*
COMPILE-AP5
Error loading /tmp/build1 at line 10 (offset 316)
Debugger invoked on condition of type PROGRAM-ERROR:
  Unrecognized keyword argument :RECOMPILE
Restarts:
  0: TOP-LEVEL Return to top level.
[1] AP5(2): :bt
  0: (BACKTRACE-AS-LIST)
  1: (INVOKE-DEBUGGER #<PROGRAM-ERROR {70AD76}>)
  2: (AP5::COMPILE-AP5 :RECOMPILE T)
  3: (SYSTEM::%LOAD #P"/tmp/build1" NIL NIL T)
  4: (LOAD "/tmp/build1")
  5: (SYSTEM::%EVAL (LOAD "/tmp/build1"))
  6: (EVAL (LOAD "/tmp/build1"))
  7: (SYSTEM:INTERACTIVE-EVAL (LOAD "/tmp/build1"))
[1] AP5(3): 
====
The complaint that recompile is an unknown keyword argument to 
compile-ap5 seems unjustified to me (see below).
If I remove the defvars from /tmp/compile.lsp below then the 
problem goes away.
==== /tmp/build1
(in-package :cl-user)
(defpackage "AP5" (:use "CL") (:nicknames "ap5"))
(in-package :ap5)
(load "/tmp/compile.lsp" :print t)
(setf source-default-path "/backup/shuttle/home/don/ap5-2006/foo.lsp"
      bin-default-path "/tmp/build-ap5/foo.fas")
(ensure-directories-exist bin-default-path)

(COMPILE-AP5 :recompile t)
;;(compile-ap5 :ask t)

==== /tmp/compile.lsp
(in-package "AP5")


(defvar info nil)
(defvar ask nil)
(defvar recompile nil)
(defvar nevercompile nil)
(defvar *changed* nil)
(defvar startfile nil)
(defvar stopfile t)
(defvar *start-time* 0)

(defun compile-ap5 (&key recompile nevercompile info ask
			  (break-at-end #+symbolics t) startfile (stopfile t)
			 &aux *changed* (*start-time* (get-universal-time))
			 #+(or symbolics ti) (global:inhibit-fdefine-warnings t))
; (compile-load "sys-depend")
  (declare (special  generator-cost-record record-expensive-and-costs))
)

[j-devel] bug report From: <don-sourceforge-xxz@is...> - 2008-10-26 23:38 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 ...

[j-devel] Filed as http://trac.common-lisp.net/armedbear/ticket/15 From: Mark Evenson <evenson@pa...> - 2008-10-27 16:43 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."

Re: [j-devel] bug report From: Mark Evenson <evenson@pa...> - 2008-10-27 16:59 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.

[j-devel] Filed as http://trac.common-lisp.net/armedbear/ticket/15 From: <don-sourceforge-xxz@is...> - 2008-10-27 17:01 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.

Re: [j-devel] bug report From: <don-sourceforge-xxz@is...> - 2008-10-27 17:16 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.

Re: [j-devel] Filed as http://trac.common-lisp.net/armedbear/ticket/15 From: Mark Evenson <evenson@pa...> - 2008-10-28 07:20 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."

Re: [j-devel] bug report From: Andras Simon <asimon@ma...> - 2008-10-28 11:30 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

Re: [j-devel] bug report From: Erik Huelsmann <ehuels@gm...> - 2008-11-05 20:36 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 >

3 messages have been excluded from this view by a project administrator.