headers
Chris Wilson | 6 Feb 2005 20:00

NullPointerException in J 0.21.0

Hi Peter and all,

Thanks for an excellent and continually improving editor! I have been 
happily using J as my main C code editor for a few years now.

J just threw an exception at me when I was using tab completion in the 
address bar. After that, I could not use keyboard input any more in J, 
although the mouse works. At least I can shut J down cleanly using the 
mouse :-(

I had seen this before on older versions, and about a week ago I upgraded 
from 0.20.2 to 0.21.0, in the hope that that would fix the problem, but I 
don't think it has.

I hope that this stack trace will provide you some useful information for 
diagnosing this. Platform is Linux on i686, Fedora Core 2, Java 
j2sdk-1.4.2_03-fcs.

Cheers, Chris.

java.lang.NullPointerException
         at 
org.armedbear.j.OpenFileTextFieldHandler.isExcluded(OpenFileTextFieldHandler.java:571)
         at 
org.armedbear.j.OpenFileTextFieldHandler.getCompletions(OpenFileTextFieldHandler.java:480)
         at 
org.armedbear.j.OpenFileTextFieldHandler.tab(OpenFileTextFieldHandler.java:411)
         at 
org.armedbear.j.DefaultTextFieldHandler.keyPressed(DefaultTextFieldHandler.java:226)
         at
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Graves | 6 Feb 2005 21:09

Re: NullPointerException in J 0.21.0

On Sun, 6 Feb 2005 at 19:00:56 +0000, Chris Wilson wrote:
> Hi Peter and all,
>
> Thanks for an excellent and continually improving editor! I have been 
> happily using J as my main C code editor for a few years now.
>
> J just threw an exception at me when I was using tab completion in the 
> address bar. After that, I could not use keyboard input any more in J, 
> although the mouse works. At least I can shut J down cleanly using the 
> mouse :-(
>
> I had seen this before on older versions, and about a week ago I upgraded 
> from 0.20.2 to 0.21.0, in the hope that that would fix the problem, but I 
> don't think it has.

This bug was fixed in CVS shortly after the 0.21.0 release.

One of these days I should really try to get around to doing another
release. Until then (and maybe even thereafter) your best bet is to get
the source via anonymous CVS and build it yourself.

Sorry for the inconvenience!

-Peter

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chris Wilson | 6 Feb 2005 22:22

Re: NullPointerException in J 0.21.0

Hi Peter,

> One of these days I should really try to get around to doing another
> release. Until then (and maybe even thereafter) your best bet is to get
> the source via anonymous CVS and build it yourself.
>
> Sorry for the inconvenience!

No problem, I have done that now, but I second the idea of a new release.

Cheers, Chris.
--

-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |

-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
Permalink | Reply | 0 comments |
headers
Peter Graves | 6 Feb 2005 22:29

0.21.0.1

A new development snapshot (j 0.21.0.1, abcl 0.0.4.1) is available:

    http://armedbear.org/j.zip          (source)
    http://armedbear.org/j-jar.zip      (just j.jar)

Long time no snapshot. Thanks to Chris Wilson for waking me up.

Among other things, this snapshot fixes the NullPointerException that
occurred with 0.21.0 under certain circumstances when doing tab
completion in the location bar, which is the bug that Chris mentioned
in his mail to the development list.

This snapshot adds support for proper use of the system menu on Mac OS
X, but being Mac-less myself, I have no idea how to set this up. Thanks
to Brian Mastenbrook and Slava Pestov for their help with the code.

There is also a new special effect associated with incrementalFind.
Please let me know if I need to make it configurable.

This snapshot adds preliminary support (on Linux only) for Allegro
Common Lisp in slime-for-j (Alt X, "slime alisp"), in addition to the
pre-existing preliminary support for ABCL (Alt X, "slime") and SBCL
(Alt X, "slime sbcl").

Except for ABCL, slime-for-j requires jpty on Unix platforms. Since
it's not platform-independent, jpty is not included in j-jar.zip, so
you'll need to build it from source.

ABCL in this snapshot fails 114 out of 20137 total tests in the ANSI
test suite (99.43% compliance).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alex Mizrahi | 8 Feb 2005 12:02
Picon

strange performance

Hello, All!

i have strange performance issues when ABCL works with sevlet -- from
debugger (that is separate thread, spawned by lisp itself) function that
generates html works about 4 msecs, but in servlet itself (that runs in
threads spawned by web-server) it works about 100 msecs, that is not very
good 8-]
i believe problem is with threads -- something like if they are not
initialized, variable lookup is too slow. can i do something with it?

by the way, i've tried working with SQL server from ABCL -- works quite
fine. so i'm going to try using it in some quite serious web-dev project
(after some more stability test) -- i believe it will be faster and more
pleasant to do in Common Lisp than in PHP even if i'll have to do some tools
and somewhat debug implementation 8-] so far it appears to be quite
stable -- better than in my previous experience with CMUCL with mod_lisp. i
even tried to compile function while it's being benchmarked by two
processes -- it didn't crash, and looks like became somewhat faster 8-]

With best regards, Alex 'killer_storm' Mizrahi.

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 2 comments |
headers
Andras Simon | 8 Feb 2005 14:05
Picon

Re: strange performance


On Tue, 8 Feb 2005, Alex Mizrahi wrote:

> Hello, All!
>
> i have strange performance issues when ABCL works with sevlet -- from
> debugger (that is separate thread, spawned by lisp itself) function that
> generates html works about 4 msecs, but in servlet itself (that runs in
> threads spawned by web-server) it works about 100 msecs, that is not very
> good 8-]
> i believe problem is with threads -- something like if they are not
> initialized, variable lookup is too slow. can i do something with it?

I can't comment on this.

>
> by the way, i've tried working with SQL server from ABCL -- works quite
> fine. so i'm going to try using it in some quite serious web-dev project
> (after some more stability test) -- i believe it will be faster and more
> pleasant to do in Common Lisp than in PHP even if i'll have to do some tools
> and somewhat debug implementation 8-] so far it appears to be quite
> stable -- better than in my previous experience with CMUCL with mod_lisp. i
> even tried to compile function while it's being benchmarked by two
> processes -- it didn't crash, and looks like became somewhat faster 8-]

If you do a lot of calls to Java, you might want to give
http://www.math.bme.hu/~asimon/lisp/jfli-abcl.tar a try. I cleaned it
up a bit a few weeks ago, so it may actually work.

(This is OT, but if you get desperate, have a look at CMUCL + Portable
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 8 Feb 2005 14:47

Re: strange performance

On Tue, 8 Feb 2005 at 13:02:43 +0200, Alex Mizrahi wrote:
> Hello, All!
>
> i have strange performance issues when ABCL works with sevlet -- from
> debugger (that is separate thread, spawned by lisp itself) function that
> generates html works about 4 msecs, but in servlet itself (that runs in
> threads spawned by web-server) it works about 100 msecs, that is not very
> good 8-]
> i believe problem is with threads -- something like if they are not
> initialized, variable lookup is too slow. can i do something with it?

Hmmm...

I haven't used ABCL's threads much myself, apart from slime-for-j,
which is not a very demanding application.

When I first implemented threads, however, my test was to run the ANSI
tests (the subset of them that ABCL could handle at that time, using
ABCL's custom driver program) in two threads simultaneously, and I got
it to the point where running two instances in separate threads took
only a little bit more than twice as long as it took to run one
instance in one thread, so I don't think threading per se is a
bottleneck. But I haven't tried this in a long time. (I think the tests
have grown and evolved in such a way that it wouldn't work very well
now, although I don't think it would necessarily be slow).

In any case I doubt that threads would cause a 25x slowdown. (Maybe
it's thread creation that is slow? But still, 25x...)

You might want to try ABCL's poor excuse for a profiler:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Graves | 10 Feb 2005 13:10

SOURCE-PATHNAME changes and slime-for-emacs

Hi Andras,

SOURCE-LOCATION in swank-abcl.lisp in the slime-for-emacs source is
currently defined like this:

    (defun source-location (symbol)
      (when (ext:source symbol)
        `(((,symbol)
           (:location 
            (:file ,(namestring (ext:source-pathname symbol)))
            (:position ,(or (ext:source-file-position symbol) 0) t)
            (:snippet nil))))))

I'm about to make a backwards-incompatible change to the way source
locations are reported by EXT:SOURCE and EXT:SOURCE-PATHNAME.

Heretofore, EXT:SOURCE-PATHNAME would either hold the pathname of the
relevant source file or NIL, and if EXT:SOURCE returned something other
than NIL, EXT:SOURCE-PATHNAME would return a valid pathname.

In an attempt to provide more meaningful style-warnings about the
redefinition of functions and macros, I need to record a bit more
information. The goal here is to suppress redefinition warnings if the
redefinition occurs in the same context as the original definition,
where "same context" means either the redefinition occurs in the same
source file as the original definition, or both the original definition
and the redefinition were typed in to the repl (or pasted in via slime).

So, I'm going to make EXT:SOURCE-PATHNAME return the keyword :TOP-LEVEL
if the definition in question came from the repl. For what it's worth,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Graves | 10 Feb 2005 14:02

Re: SOURCE-PATHNAME changes and slime-for-emacs

On Thu, 10 Feb 2005 at 04:10:34 -0800, Peter Graves wrote:
> I'm about to make a backwards-incompatible change to the way source
> locations are reported by EXT:SOURCE and EXT:SOURCE-PATHNAME.

I've now committed this change to CVS.

Thanks for your support.

-Peter

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 1 comment |
headers
Andras Simon | 10 Feb 2005 20:24
Picon

Re: SOURCE-PATHNAME changes and slime-for-emacs


On Thu, 10 Feb 2005, Peter Graves wrote:

> On Thu, 10 Feb 2005 at 04:10:34 -0800, Peter Graves wrote:
>> I'm about to make a backwards-incompatible change to the way source
>> locations are reported by EXT:SOURCE and EXT:SOURCE-PATHNAME.
>
> I've now committed this change to CVS.

And I've committed your modified source-location to slime CVS.

Thanks!

Andras

-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
Permalink | Reply | 0 comments |

Gmane