Re: jdb bug and quick fix

We should at least take a poll as to who might be using a feature
before we just start removing things.

Have we asked who might be willing to maintain it first?


Ke Lu writes:
 > Carlos Konstanski <[email protected]> writes:
 > 
 > > I prefer jdb over jdebug because jdb has enough functionality for 99%
 > > of my debugging needs, and less gizmos and knobs in the way.  (Jdebug
 > > is indespensible for some situations.)  But there is a bug that
 > > affects code-stepping in jdb.  You can step through code, but the
 > > pointer in the left gutter of the source buffer cannot track the
 > > current line because of a stringp type error.  The error occurs during
 > > the routine for finding the source buffer.  Here's the quick fix:
 > >
 > > In jde-util.el, the function (jde-find-class-source-file) has these as
 > > the first 2 lines:
 > >
 > >   (let* ((verified-name (jde-parse-class-exists class))
 > >          (outer-class (jde-remove-inner-class verified-name))
 > >
 > > This would be good if (jde-parse-class-exists) returned a string, but
 > > it returns a boolean instead.  The call to (jde-remove-inner-class)
 > > throws a '(type stringp nil) error as a result.  Change the code to:
 > >
 > >   (let* ((verified-name (jde-parse-class-exists class))
 > >          (outer-class (jde-remove-inner-class class))
 > >
 > > `class' is the passed-in string argument to
 > > (jde-find-class-source-file).  This is the quick fix.  It seems to
 > > work like it needs to.  But this makes the logical flow in this
 > > function less than ideal.  If we're going to call
 > > (jde-parse-class-exists) to validate the input, we should do something
 > > with that validation before doing more stuff, or fail gracefully.
 > > Something like:
 > >
 > >   (if (jde-parse-class-exists class)
 > >     (let ((outer-class (jde-remove-inner-class class)))
 > >       (do-stuff)
 > >       ...)
 > >     (signal-no-src-found class))
 > >
 > > I will try to spend some time refactoring this function and submitting
 > > it for review.
 > >
 > > Carlos Konstanski
 > It seems jdee will be moved to sourceforge this weekend.
 > I agree the jdebugger is not too stable to use and
 > I advice to remove it in the future.
 > Another problem is:
 > jdb in jdee can't work well when The user.language is not en.
 > My advice is:
 > if it is difficult to parse muti-lanuage msg of jdb's output,
 > Please set -J-Duser.language=en to jdb options by hard coding,
 > (including options of nomal debug, attach to socket and attach to share memory)
 > 


-- 
Paul Landes
[email protected]