[j-devel] void in jfli-abcl

[Alex Mizrahi <killerstorm@ne...>]

hello

how can i do method returining void in jfli new-class?
in example i see declarations like

("setValueAt" "void" (:public :synchronized)

however it isn't working - it says it cannot find package of void..
:void isn't working as well..
here is a backtrace:

(ERROR "must supply package-qualified classname")
  33:
(JFLI::SPLIT-PACKAGE-AND-CLASS "void")
  34:
(JFLI::CANONIC-CLASS-SYMBOL "void")
  35:
(FIND-JAVA-CLASS "void")
  36:
(JFLI::FIND-JAVA-CLASS-IN-MACRO "void")
  37:
((FLET JFLI::PROCESS-METHOD-DEF) ("doGet" "void" :PUBLIC ((REQ
"javax.servlet.http.HttpServletRequest")

with best regards, Alex 'killer_storm' Mizrahi.

Re: [j-devel] pprint bug

[Peter Graves <peter@ar...>]

On Fri, 8 Oct 2004 at 20:38:11 +0200, Andras Simon wrote:
> Perhaps this is a good time to ask why you decided to adapt closette,
> and not pcl (or its CMUCL/SBCL version). Just curious.

Well, it was a long time ago, and there was really no hope of getting
ABCL to run PCL at that time. I don't think the CMUCL and SBCL versions
of PCL are really very portable, despite the name.

Closette had the advantage of being much smaller and more approachable
(less than 2000 lines vs. around 20,000 lines for PCL). And at the time
I started working with Closette I hadn't really decided to do a full
ANSI CL, so I was even entertaining the crazy idea that Closette might
end up being enough of a CLOS by itself.

In the long term I think most of the Closette code will go away and
ABCL will end up with a more-or-less home-grown CLOS implementation,
but in the early days Closette provided a useful outline for the code
and a rough framework to build on. Performance is terrible, but that's
mostly my fault.

-Peter

Re: [j-devel] pprint bug

[Andras Simon <asimon@ma...>]

On Fri, 8 Oct 2004, Peter Graves wrote:

> On Fri, 24 Sep 2004 at 16:15:26 +0200, Andras Simon wrote:
>> (defun listener-eval (&rest x))
>>
>> (let ((*print-circle* t))
>>      (pprint (list 'apply
>>                    '((listener-eval "(setq a (backtrace-as-list)) ")
>>                    "COMMON-LISP-USER"
>>                     123))))
>>
>> Debugger invoked on condition of type TYPE-ERROR:
>>    The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream.
>>
>> I would've liked to trigger the bug with a simpler case but this is
>> how far I could get.
>
> This morning I checked in new versions of print.lisp and pprint.lisp
> that fix this bug.

Thanks Peter, this fix lets me pretty print frames in backtraces in
slime, which makes them much more readable.

> With these changes, ABCL in current CVS fails 114 out of 18159 tests in
> the ANSI test suite, down from 164 failures out of 17942 tests two
> weeks ago.

Impressive figures!

> Barring interrupts, my next project (starting today) will be to fix the
> aforementioned awful CLOS slowness.

Perhaps this is a good time to ask why you decided to adapt closette,
and not pcl (or its CMUCL/SBCL version). Just curious.

Andras

Re: [j-devel] pprint bug

[Peter Graves <peter@ar...>]

On Fri, 24 Sep 2004 at 16:15:26 +0200, Andras Simon wrote:
> (defun listener-eval (&rest x))
>
> (let ((*print-circle* t))
>      (pprint (list 'apply
>                    '((listener-eval "(setq a (backtrace-as-list)) ")
>                    "COMMON-LISP-USER"
>                     123))))
>
> Debugger invoked on condition of type TYPE-ERROR:
>    The value #S(XP::XP-STRUCTURE :BASE-STREAM #<STREAM @ #x17cd15d> :LINEL 70 .....) is not of type character output stream.
>
> I would've liked to trigger the bug with a simpler case but this is
> how far I could get.

This morning I checked in new versions of print.lisp and pprint.lisp
that fix this bug.

I've spent the last two weeks working on ABCL's printer (and pretty
printer). One big change is that pprint.lisp is now loaded directly in
boot.lisp. In previous versions, the pretty printer was autoloaded, in
the hope of making startup faster, but that led to a number of other
problems (including this particular bug), and it turned out that the
startup cost is not very high after all.

With these changes, ABCL in current CVS fails 114 out of 18159 tests in
the ANSI test suite, down from 164 failures out of 17942 tests two
weeks ago.

The apparent hang in PRINT.CONS.RANDOM.2 (which I've commented out for
now) is really due to ABCL's awful CLOS slowness and not to any issue
with the test or what it's primarily testing; reducing N from 50 to 10
allows the test to finish without error on the same day it starts.

There are still some printer-related test failures, mostly having to do
with the pretty-printing of circular lists.

Barring interrupts, my next project (starting today) will be to fix the
aforementioned awful CLOS slowness.

Thanks for your support.

-Peter