headers
Eric M. Ludlam | 7 Nov 2002 17:35
Gravatar

Pumpkins

Hi all,

  As promised, here are some links to the catapult my pumpkin
  throwing team built and the competition we were working toward.

  Now perhaps I'll have time to hack some more Emacs code.

http://www.siege-engine.com
http://www.siege-engine.com/MistaBallista.shtml
http://www.siege-engine.com/PunkinChunk2002.shtml

Eric

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
Permalink | Reply | 0 comments |
headers
David Ponce | 15 Nov 2002 20:06
Picon

Re: semantic-find-doc-snarf-comment problem

[...]
>>If you don't have objection I will check it in.
>
>   [ ... ]
>
> This looks like good stuff to me.

Thanks!  I will commit it.

[...]
>> If NOSNARF is 'flex, then return the flex token."
>>!   (let* ((semantic-ignore-comments nil)
>>! 	 (semantic-lex-analyzer #'semantic-comment-lexer))
[...]
> Do we still need `semantic-ignore-comments nil' in here anymore?

Yes I think so, in case `semantic-lex-analyzer' is overrode to use
`semantic-flex'!  IMO we should keep it until we remove the old
`semantic-flex' stuff.

David

-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 15 Nov 2002 19:09
Gravatar

Re[2]: semantic-find-doc-snarf-comment problem

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Eric,
>
>>   Of course, for the situation in `semantic-find-doc-snarf-comment',
>> we could probably just replace use of the full lexer with a mini
>> comment-only lexer common between languages.  That may be more useful
>> and simpler..
>
>Good idea!  Following is a patch (and the change log) to
>semantic-lex.el and semantic-util.el to do that ;-)
>
>I also fixed some nasty bugs in semantic-lex!
>
>If you don't have objection I will check it in.
  [ ... ]

This looks like good stuff to me.

>--- 1722,1729 ----
>  Attempt to strip out comment syntactic sugar.
>  Argument NOSNARF means don't modify the found text.
>  If NOSNARF is 'flex, then return the flex token."
>!   (let* ((semantic-ignore-comments nil)
>! 	 (semantic-lex-analyzer #'semantic-comment-lexer))
>      (if (eq nosnarf 'flex)
>  	(car (semantic-lex (point) (1+ (point))))
>        (let ((ct (semantic-flex-text
  [ ... ]

Do we still need `semantic-ignore-comments nil' in here anymore?
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric M. Ludlam | 15 Nov 2002 13:44
Gravatar

Re[1]: semantic-find-doc-snarf-comment problem

Hi David,

  Good find.  I like your idea of comments on demand.  I wonder if
there is a way for code to look like this:

(semantic-enable-comments
   (lex code here))

  where `semantic-enable-comments' changes the lexer to be a
permutation of the existing lexer, where the analyzer
`semantic-lex-ignore-comments' is changed to `semantic-lex-comments'.

  Of course, for the situation in `semantic-find-doc-snarf-comment',
we could probably just replace use of the full lexer with a mini
comment-only lexer common between languages.  That may be more useful
and simpler..

Eric

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Hello Eric,
>
>While working on some new Java sources, I discovered that the JDEE
>javadoc checker no more work with the new Semantic 2.0.
>
>After more investigation I found that the problem is in the code of
>the function `semantic-find-doc-snarf-comment' which no more work with
>the new `semantic-lex' API :-(
>
>In fact `semantic-find-doc-snarf-comment' implementation is based on
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 18 Nov 2002 15:03
Gravatar

Re[1]: Preparing semantic 1.4.1

Hi David,

  I also have this I never checked in:

*** semantic-texi.el.~1.8.~	Mon May  6 21:31:14 2002
--- semantic-texi.el	Wed Aug 14 18:09:07 2002
***************
*** 49,54 ****
--- 49,55 ----
       ("defvarx" . 1)
       ("defun" . 1)
       ("defunx" . 1)
+      ("defopt" . 1)
       ("deffn" . 2)
       ("deffnx" . 2)
       )

I also needed to add you as a release manager to the project which I
just did.

Lastly, I have the following change to c.bnf which I never tested
because it conflicts with semantic 2.0, but the person I fixed it for
never wrote back, so I'm assuming it worked.

*** c.bnf.~1.59.~	Thu Jun 13 11:05:21 2002
--- c.bnf	Thu Nov 14 20:29:58 2002
***************
*** 348,353 ****
--- 348,358 ----
  	   ( "" )
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ole Laursen | 18 Nov 2002 18:52
Picon
Favicon

Re: Re[1]: Preparing semantic 1.4.1

"Eric M. Ludlam" <eric <at> siege-engine.com> writes:
> Lastly, I have the following change to c.bnf which I never tested
> because it conflicts with semantic 2.0, but the person I fixed it for
> never wrote back, so I'm assuming it worked.

My apologies, I guess that guy is me. I've installed Semantic from a
Debian package and couldn't figure out how to rebuild from the source
package to avoid hosing the setup.

I've looked into it now. The patch seems to partly fix the problem:
with

  void myfunc(int *)
  {
    // contents
  }

the star is not underlined. However, when placing the cursor over the
star, the minibuffer says "Functions: void myfunc (int )" without a
star. Not a big deal though. I never look at the tip anyway, but
looking at the underlined star was annoying.

--

-- 
Ole Laursen
http://www.cs.auc.dk/~olau/

-------------------------------------------------------
This sf.net email is sponsored by: To learn the basics of securing 
your web site with SSL, click here to get a FREE TRIAL of a Thawte 
Server Certificate: http://www.gothawte.com/rd524.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 20 Nov 2002 18:26
Gravatar

Re[1]: Preparing semantic 1.4.1

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Hi Eric,
>
  [ ... ]
>> Lastly, I have the following change to c.bnf which I never tested
>> because it conflicts with semantic 2.0, but the person I fixed it for
>> never wrote back, so I'm assuming it worked.
>> 
>> *** c.bnf.~1.59.~	Thu Jun 13 11:05:21 2002
>> --- c.bnf	Thu Nov 14 20:29:58 2002
>[...]
>
>Thanks! I applied the above patches to my local copy of Semantic v1p4.
>Could you please send me a change log (or bug numbers), so I could
>check these changes in (and close corresponding bug)?
>
>Do we need to apply the semantic-texi.el fix to the trunk too?

Yea, I do need to do that.

Here's a log:

semantic-texi.el:

(semantic-texi-name-field-list): Add `defopt' as a parsable field entry.

c.bnf:

(opt-class-declmods): New
(typeformbase): Support templates after :: operator
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 20 Nov 2002 18:38
Gravatar

Re[1]: Incremental parser problem

This sounds familiar, as though I struggled with it before.
The solution is to always start with the cache after getting the list
of dirty tokens from one of the fetch routines.  (Using eq on the
lists to find a cons match).  I think the splice routine is already
doing this with this code-snippet:

	(let* ((pc (if parent
		       (semantic-nonterminal-children parent)
		     semantic-toplevel-bovine-cache))
	       (nc (cons (car pc) (cdr pc)))  ; new cons cell.
	       )

meaning the list it is splicing into is directly from the cache,
unless the passed in parent token is not originally from the cache.
(An assertion there may answer that question.)

This is some pretty hairy code.  The idea seemed so simple when I
started. ;)

Do you have a reliable reproducible case?

Eric

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Hi Eric,
>
>I think I discovered a nasty problem in the current implementation of
>the incremental parser :-(
>
>In certain cases `semantic-edits-incremental-parser' correctly
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 22 Nov 2002 13:59
Gravatar

Re[2]: Incremental parser problem

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Hi Eric,
>
>[...]
>> Do you have a reliable reproducible case?
>
>Here it is ;-)
>
  [ ... ]

I checked in a fix for this problem.  The insert issue now works.  I
tested remove, but it kept doing a full reparse.  I need to look into
that still.

The problem was with semantic-nonterminal-children, and asking for
tokens with a position only.  This caused it to return a fabricated
list.

Have fun
Eric

--

-- 
          Eric Ludlam:                 zappo <at> gnu.org, eric <at> siege-engine.com
   Home: http://www.ludlam.net            Siege: www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: www.gnu.org

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric M. Ludlam | 28 Nov 2002 14:04
Gravatar

Re[1]: Erlang & Semantic

That's fine with me David.

Eric

>>> "David PONCE" <David.Ponce <at> wanadoo.fr> seems to think that:
>Hi Eric & Vladimir,
>
>>   That's great news.  I've added you as a developer for CEDET.
>
>Welcome to our team Vladimir, and thanks for your help!
>
>> You will find that the source tree in CVS looks a bit different than
>> in the current 1.4 release.  All parsers and support files for
>> languages using "bnf" as the parser currently reside in the
>> cedet/semantic/bovine directory.
>> 
>>   I've CCed David Ponce who is coordinating a 1.4.1 patch release of
>> semantic for me.  Since semantic 2.0 won't have a stable release for a
>> while, it might be worth the time to update the 1.4.1 release
>> candidate after you are able to check in your sources.  I'm not
>> exactly sure how to backtrack a new file to a patch release in a
>> different directory, but David's pretty savvy, so perhaps he knows.
>
>As the 1.4.1 fixes important bugs and is about to be ready now, I
>would prefer to release it as it is.
>
>IMO it would be simpler and cleaner to check the Errlang support in
>the trunk.  Like Python, Errlang would be a great addition to 2.0.
>Even if 2.0 is not yet a stable release I think it works well enough
>today (I use it all the days!) to produce a first alpha or beta
(Continue reading)

Permalink | Reply | 0 comments |

Gmane