JDEE

Also rejected for the reason of the previous email.  Also, will you
start putting these in one long email?

Thanks.

Ludovic Courtès writes:
 > * jde/lisp/jde-db.el (jde-debug): Simplify the definition of MAIN-CLASS
 >   (renamed from APPLICATION-MAIN-CLASS).
 > ---
 >  jde/lisp/jde-db.el |   22 ++++++----------------
 >  1 files changed, 6 insertions(+), 16 deletions(-)
 > 
 > diff --git a/jde/lisp/jde-db.el b/jde/lisp/jde-db.el
 > index 5d7c822..6e7a41d 100644
 > --- a/jde/lisp/jde-db.el
 > +++ b/jde/lisp/jde-db.el
 > @@ -1592,26 +1592,16 @@ With a negative prefix, prompts for the main class name."
 >        (jde-bug-debug-app)
 >    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
 >      (let* ((debugger (jde-db-get-the-debugger))
 > -           (application-main-class
 > -            (let ((main-class (if (and (integerp prefix) (< prefix 0))
 > -				  (jde-read-class-name
 > -				   jde-run-application-class)
 > -				  jde-run-application-class)))
 > -              (if (or
 > -                   (not main-class)
 > -                   (string= main-class ""))
 > -                  (setq main-class
 > -                        (if (buffer-file-name)
 > -                            (concat (jde-db-get-package)
 > -                                    (file-name-sans-extension 
 > -                                     (file-name-nondirectory (buffer-file-name))))
 > -                          (read-string "Java class to debug: "))))
 > -              main-class))
 > +	   (main-class (if (and (integerp prefix) (< prefix 0))
 > +			   (jde-read-class-name
 > +			    jde-run-application-class)
 > +			 (or jde-run-application-class
 > +			     (jde-read-class-name))))
 >             (cmd-set (oref debugger cmd-set))
 >             (launch-cmd (oref cmd-set launch-app)))
 >  
 >  
 > -      (jde-db-create-debuggee-app debugger application-main-class)
 > +      (jde-db-create-debuggee-app debugger main-class)
 >  
 >        (if (not (oref debugger running-p))
 >            (jde-db-debugger-start debugger))
 > -- 
 > 1.6.1.3
 > 
 > 
 > 
 > ------------------------------------------------------------------------------
 > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
 > trial. Simplify your report design, integration and deployment - and focus on 
 > what you do best, core application coding. Discover what's new with 
 > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
 > _______________________________________________
 > jdee-users mailing list
 > jdee-users@...
 > https://lists.sourceforge.net/lists/listinfo/jdee-users


-- 
Paul Landes
landes@...

Paul Landes <landes@...> writes:

> Also rejected for the reason of the previous email.

This patch merely factorizes code in `jde-debug'.  Is it already done
elsewhere?

> Also, will you start putting these in one long email?

You'd prefer all patches to be bundled in a single email, right?

If so, I can do it, of course.  Sending separate messages for different
patches is a habit in other free software projects I work on.

Thanks,
Ludo'.

Hmmmm, another idea is to create people like you who have been
submitting a lot of patches an account on SF and give tracker access.
This wouldn't be a commit priv, but would allow you to put your
patches directly into SF for tracking.  Then you could just paste in
tracker IDs or URLs or something.

Ideas?


Ludovic Courtès writes:
 > Paul Landes <landes@...> writes:
 > 
 > > Also rejected for the reason of the previous email.
 > 
 > This patch merely factorizes code in `jde-debug'.  Is it already done
 > elsewhere?
 > 
 > > Also, will you start putting these in one long email?
 > 
 > You'd prefer all patches to be bundled in a single email, right?
 > 
 > If so, I can do it, of course.  Sending separate messages for different
 > patches is a habit in other free software projects I work on.
 > 
 > Thanks,
 > Ludo'.
 > 
 > 
 > ------------------------------------------------------------------------------
 > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
 > trial. Simplify your report design, integration and deployment - and focus on 
 > what you do best, core application coding. Discover what's new with 
 > Crystal Reports now.  http://p.sf.net/sfu/bobj-july
 > _______________________________________________
 > jdee-users mailing list
 > jdee-users@...
 > https://lists.sourceforge.net/lists/listinfo/jdee-users


-- 
Paul Landes
landes@...

Paul Landes <landes@...> writes:

> Hmmmm, another idea is to create people like you who have been
> submitting a lot of patches an account on SF and give tracker access.
> This wouldn't be a commit priv, but would allow you to put your
> patches directly into SF for tracking.  Then you could just paste in
> tracker IDs or URLs or something.

As far as I'm concerned, using git-svn to maintain patches locally it
not a problem, as far as I don't end up having a local branch that
diverges too much from trunk because patches haven't been reviewed for
inclusion---but so far you've been very fast at reviewing!

I actually even prefer git-svn + email over SF's web interface.

Do you prefer using SF's web patch tracker?

Thanks,
Ludo'.

Ludovic Courtès writes:
 > Paul Landes <landes@...> writes:
 > 
 > > Hmmmm, another idea is to create people like you who have been
 > > submitting a lot of patches an account on SF and give tracker access.
 > > This wouldn't be a commit priv, but would allow you to put your
 > > patches directly into SF for tracking.  Then you could just paste in
 > > tracker IDs or URLs or something.
 > 
 > As far as I'm concerned, using git-svn to maintain patches locally it
 > not a problem, as far as I don't end up having a local branch that
 > diverges too much from trunk because patches haven't been reviewed for
 > inclusion---but so far you've been very fast at reviewing!
 > 
 > I actually even prefer git-svn + email over SF's web interface.

I've not used it enough to get a good sense.  The reporting features
seem nice, but for us that's less useful.  Mail is fine as well.  The
only thing I care about is really ease of applying the patch to look
at it and test it.  The less I have to munge paths the faster it gets
in.

We need to standardize on patches and it could be your way.  If so,
I'd apply the patches the same every time.  However, most submit in a
way that doesn't require path stripping and have been.  I think the
overall effort is reduced if you submit patches like others.

Thanks Ludovic.

Paul Landes <landes@...> writes:

> We need to standardize on patches and it could be your way.  If so,
> I'd apply the patches the same every time.  However, most submit in a
> way that doesn't require path stripping and have been.  I think the
> overall effort is reduced if you submit patches like others.

Do you think adding `-p1' increases the patch installation effort?

My guess is that the time it takes to review a patch and discuss it
largely dominates the time it takes to type `-p1'.

If you think otherwise, I can manually remove `a/' and `b/' in future
patches, but that takes more time than adding `-p1' on the command line.

Thanks,
Ludo'.