Re: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2

2003-12-18 Thread Paul Kinnucan
 Michael == Michael Schierl [EMAIL PROTECTED] writes:

Michael On Tue, 9 Dec 2003 18:03:26 -0500, Paul Kinnucan wrote:
 Michael Schierl writes:
  On Thu, 6 Nov 2003 13:17:50 -0500, Paul Kinnucan wrote:
 
  When I use that one with cedet-1.0beta1c on emacs-21.3
  (Windows), it works as long as i only edit one file. When I
  open the second file (or do a M-x jde-mode RET in the first
  one), I see
 

 I was not able to get cedet-1.0beta1c to load on my Windows
 system, let alone work with the JDEE 2.3.3.

Michael Hmm, my windows system (w/ cygwin) did not make any
Michael problems. just run make and then add the line mentioned
Michael in the INSTALL file into .emacs (it will create the
Michael needed load path itself).

Michael Some investigation with lots of (message)s and
Michael edebug-sessions later, i noticed that the error does not
Michael occur when i disable
Michael jde-project-context-switching-enabled-p. It does not
Michael occur either when i load the project manually afterwards
Michael (huh?).

Michael After some stepping through jde-set-variables-init-value,
Michael the problem is (funcall set symbol val-to-set) on
Michael jde-enable-senator.

Michael So the shortest hack to make it work with latest cedet
Michael seems to be changing the set function for
Michael jde-enable-senator.

Michael Now i simply use:

Michael (defcustom jde-enable-senator t
Michael   Enable senator minor mode.
Michael This mode provides Java-aware buffer navigation and
Michael searching commands.
Michael   :group 'jde-project :type 'boolean :set '(lambda (sym
Michael   val)
Michael   ;; Starting with version 1.4 beta 12 Semantic
Michael   ;; can globally enable `senator-minor-mode'.
Michael   ;; So don't override the global setting in
Michael   ;; JDE's buffers.
Michael   (or (and (boundp 'global-senator-minor-mode)
Michaelglobal-senator-minor-mode)
Michael  t ;;  added
Michael  by me
Michael   (mapc
Michael(lambda (buff)
Michael  (save-excursion
Michael(set-buffer buff) (senator-minor-mode
Michael(if val 1 -1
Michael(jde-get-java-source-buffers)))
Michael  (set-default sym val)))

Michael which seems to work as expected (although i might have
Michael broken senator, but I don't care about that on my
Michael machine).

This effectively disables the resetting of existing open buffers
when a user customizes jde-enable-senator. I would rather fix the
bug then cripple a function in order to avoid it. I've narrowed
the problem, i.e., resetting the value of jde-enable-senator
triggers the error:

  Setting JDE variables to startup values... [3 times]
  wisent-java-tags-lexer: 
  Wrong type argument: stringp, nil


to the java version of the semantic-parse-region function. However, I
cannot get any further because the semantic java parser is implemented
via macros that cannot be enabled for edebugging, which is the only
way I know how to find the exact line that causes a particular
error. (BTW, I find the heavy reliance on macros a serious problem
with the design of semantic 2.0; it makes debugging problems with
semantic next to impossible, at least that has been my experience so
far.)  Perhaps Eric or David can find the line that causes the error
or suggest a way for me to find it so this bug can be fixed.

Paul
 

Michael Perhaps that helps tracking down the bug (which occurs on
Michael my Linux box as well).

Michael Another bug: Since jde-2.3.3 jde-build-ant-command uses '
Michael chars here instead of  to enclose the build file name -
Michael however ant (or my shell, which is plain old command.com)
Michael does not like that... Would be helpful to have a custom
Michael option for that.

Michael Michael




Re[2]: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2

2003-12-18 Thread Eric M. Ludlam
 Paul Kinnucan [EMAIL PROTECTED] seems to think that:
 Michael == Michael Schierl [EMAIL PROTECTED] writes:
  [ ... ]
Michael (defcustom jde-enable-senator t
Michael   Enable senator minor mode.
Michael This mode provides Java-aware buffer navigation and
Michael searching commands.
Michael   :group 'jde-project :type 'boolean :set '(lambda (sym
Michael   val)
Michael   ;; Starting with version 1.4 beta 12 Semantic
Michael   ;; can globally enable `senator-minor-mode'.
Michael   ;; So don't override the global setting in
Michael   ;; JDE's buffers.
Michael   (or (and (boundp 'global-senator-minor-mode)
Michaelglobal-senator-minor-mode)
Michael t ;;  added
Michael by me
Michael   (mapc
Michael(lambda (buff)
Michael  (save-excursion
Michael(set-buffer buff) (senator-minor-mode
Michael(if val 1 -1
Michael(jde-get-java-source-buffers)))
Michael (set-default sym val)))

Michael which seems to work as expected (although i might have
Michael broken senator, but I don't care about that on my
Michael machine).

This effectively disables the resetting of existing open buffers
when a user customizes jde-enable-senator. I would rather fix the
bug then cripple a function in order to avoid it. I've narrowed
the problem, i.e., resetting the value of jde-enable-senator
triggers the error:

  Setting JDE variables to startup values... [3 times]
  wisent-java-tags-lexer: 
  Wrong type argument: stringp, nil


to the java version of the semantic-parse-region function. However, I
cannot get any further because the semantic java parser is implemented
via macros that cannot be enabled for edebugging, which is the only
way I know how to find the exact line that causes a particular
error. (BTW, I find the heavy reliance on macros a serious problem
with the design of semantic 2.0; it makes debugging problems with
semantic next to impossible, at least that has been my experience so
far.)  Perhaps Eric or David can find the line that causes the error
or suggest a way for me to find it so this bug can be fixed.
  [ ... ]

Hi Paul ( co)

  In semantic 2.0 we are spending brain power on a pair of goals in the
parser generation area.  Make it fast, and make it easy to implement
new languages.

  The best way to make a lexer fast is to cut back on the number of
regexp matches and remove as many function calls as possible.
Side-effect: funny-macros for constructing custom lexers.

  On the make it easy side, Emacs Lisp is just not a great language
for making an easy-to-read lexical analyzer.  The macros let you write
and mix individual analyzers in a convenient high-level way.

  As for debugging, there is the `semantic-lex-debug' command.  This
lets you debug the meaning of an analyzer, and is unfortunately not
what you are really looking for.

  Also, it is easy to just re-evaluate the lexer construction element,
and toggle-debug-on-error to see what aspect of a given lexer is
failing, which is what I usually use.

  I will try and track you down at work sometime to see what solutions
there may be.

Eric

-- 
  Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED]
   Home: http://www.ludlam.netSiege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net   GNU: www.gnu.org


Re: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2

2003-12-18 Thread Kai Grossjohann
Eric M. Ludlam [EMAIL PROTECTED] writes:

   On the make it easy side, Emacs Lisp is just not a great language
 for making an easy-to-read lexical analyzer.  The macros let you write
 and mix individual analyzers in a convenient high-level way.

My understanding was that Common Lisp has a configurable reader that
is flexible enough so that one does not need to use lexers.  Is this
true?

I wonder if it would be a workable approach to augment Emacs to have a
better reader, then to use that as the lexer.

I don't have practical experience with building parsers.
Theoretically, one wouldn't need a lexer, just something that returns
the next character from the input would be sufficient and the rest
could be done from the grammar.  (I mean that one doesn't need lex and
could do everything in yacc instead.)  But that makes parsers
difficult to write, and also probably slow.  So one does need lexers.
But the theory seems to imply that the lexers don't need to be
all-powerful: if the lexer is too stupid, then one can still do it
from the grammar.

So would it work in practice to just use an augmented Lisp reader as
the lexer?

Kai



Re: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2

2003-12-18 Thread Michael Schierl
Paul Kinnucan schrieb:

 This effectively disables the resetting of existing open buffers
 when a user customizes jde-enable-senator. I would rather fix the
 bug then cripple a function in order to avoid it. 

Sure. But it is better to cripple a feature out of my jde i (and 
probably others) never use instead of changing load path (for older 
semantic version) and restarting emacs whenever i want to use jde or 
not...

 I've narrowed
 the problem, i.e., resetting the value of jde-enable-senator
 triggers the error:
 
   Setting JDE variables to startup values... [3 times]
   wisent-java-tags-lexer:
   Wrong type argument: stringp, nil

BTW: working.el seems to have fun with duplicating messages and 
confusing the user debugging it:

(progn
  (message One)
  (message Two)
  (working-status-forms Doing stuff done
(working-status 10)
(working-status 80)
(working-status 90)
(working-status t))
  (message Three!))

produces:

One
Two [2 times]
Three!

 to the java version of the semantic-parse-region function. However, I
 cannot get any further because the semantic java parser is implemented
 via macros that cannot be enabled for edebugging, which is the only
 way I know how to find the exact line that causes a particular
 error. 

Same for me ;) That's why i stopped there with debugging. Further more, 
it does work when you call that (senator-minor-mode 1) function by hand, 
so there must be some side effect with the code calling it.


 (BTW, I find the heavy reliance on macros a serious problem
 with the design of semantic 2.0; it makes debugging problems with
 semantic next to impossible, at least that has been my experience so
 far.)  Perhaps Eric or David can find the line that causes the error
 or suggest a way for me to find it so this bug can be fixed.

it could work to expand the macros into a temp buffer and edebug 
there - but that is not easy either. to make it a bit easier:

(defun make-expanded-macro ()
  Treat the current `defun' around point as a macro
and expand it into a temp buffer.
  (interactive)
  (let (beg end expr)
(beginning-of-defun)
(setq beg (point))
(end-of-defun)
(setq end (point))
(setq expr (read (buffer-substring beg end)))
(with-current-buffer (get-buffer-create *expanded-macros*)
  (emacs-lisp-mode)
  (goto-char (point-max))
  (insert \n\n\n 
  (prin1-to-string (macroexpand expr
(pop-to-buffer (get-buffer-create *expanded-macros*

Michael


Re[2]: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2

2003-12-18 Thread Eric M. Ludlam
 Kai Grossjohann [EMAIL PROTECTED] seems to think that:
Eric M. Ludlam [EMAIL PROTECTED] writes:

   On the make it easy side, Emacs Lisp is just not a great language
 for making an easy-to-read lexical analyzer.  The macros let you write
 and mix individual analyzers in a convenient high-level way.

My understanding was that Common Lisp has a configurable reader that
is flexible enough so that one does not need to use lexers.  Is this
true?

This I don't know, but it sounds like something CL would do.

I wonder if it would be a workable approach to augment Emacs to have a
better reader, then to use that as the lexer.

I have thought of this often.  My consideration was something like
'parse-partial-sexp'.  The Emacs syntax-table really is exactly the
way to build a nice lexical analyzer.

I don't have practical experience with building parsers.
Theoretically, one wouldn't need a lexer, just something that returns
the next character from the input would be sufficient and the rest
could be done from the grammar.  (I mean that one doesn't need lex and
could do everything in yacc instead.)  But that makes parsers
difficult to write, and also probably slow.  So one does need lexers.
But the theory seems to imply that the lexers don't need to be
all-powerful: if the lexer is too stupid, then one can still do it
from the grammar.
  [ ... ]

Lexical analysis is nice because matching characters is really easy to
to do compared to actual syntax parsing.

Regexp matching is nice because you can have fairly complex lexical
tokens such as #include.  Mixed mode code such as C preprocessor
and C code is made simpler to handle this way.

Semantic's lexers are pretty simple.  Syntax table regexps such as
\s. or \s_ are used so specific generic analyzers can be used
in most lexers.

Anyway, the problem is how to debug a lexer.  I can imagine this
being even more difficult if it were a built-in. ;)

If you were to look at a lex file sometime, it's syntax and content
is usually really simple, along the lines of (from the man page):

if|then|begin|end|procedure|function {  some action here }

which basically says if you see the characters i f, it makes a
token if.  Your action then does whatever.

Semantic lex analyzers are the same, and could be:

(define-lex-simple-regexp-analyzer my-analyzer
  obligatory docstirng
  if\\|then\\|begin\\|end\\|procedure\\|function
  'keyword
  0  ; index into the regexp
  (other code here))

so it is very similar.  What is different is that you have to then
combine your named analyzers via the define-lex call.

Another big difference is that the semantic lexer can skip over lists
like { a method body } as a single token.  The process of identifying
those characters is very fast (an Emacs built in) and when tagging a
file, often those characters are not needed anyway.  This short cut is
what makes the C and Java semantic parsers fast enough to be usable in
while editing without getting in the way too much.

Have fun
Eric

-- 
  Eric Ludlam: [EMAIL PROTECTED], [EMAIL PROTECTED]
   Home: http://www.ludlam.netSiege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net   GNU: www.gnu.org