Re[2]: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
>>> 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 { }
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
Re: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
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: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
"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[2]: cedet-1.0beta1 /Semantic 2.0 and JDEE-2.3.2
>>> 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) >Michael>global-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
> "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) Michael>global-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
