CEDET

I added a link to the CEDET homepage that points at the sourceforge bzr 
setup page.

I don't know if that page can be modified to the CEDET specifics.

Browsing bzr will eventually reveal the developer doc when that is 
eventually checked in.  At the moment, we are transitioning from CVS to bzr.

Eric

On 09/26/2010 03:58 PM, Oleksandr Gavenko wrote:
> Such searches in Google take no result:
>
>     site:http://cedet.sourceforge.net/ svn
>     site:http://cedet.sourceforge.net/ vcs
>     site:http://cedet.sourceforge.net/ bzr
>     site:http://cedet.sourceforge.net/ git
>     site:http://cedet.sourceforge.net/ hg
>
> I found  https://sourceforge.net/scm/?type=bzr&group_id=17886
> with link:
>
>     bzr://cedet.bzr.sourceforge.net/bzrroot/cedet (read-only)
>
> and  https://sourceforge.net/scm/?type=cvs&group_id=17886
> with link:
>
>     $ cvs -d:pserver:anonymous@... login
>
>     $ cvs -z3
> -d:pserver:anonymous@... co -P
> modulename
>
> I try run:
>
> bash# bzr clone bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/trunk cedet
> bzr: ERROR: Not a branch:
> "bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/trunk/".
> bash# bzr clone bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/ cedet
> bzr: ERROR: Not a branch: "bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/".
>
> It would be nice have "Obtain sources" item in left sidebar
> of http://cedet.sourceforge.net/ with actual instruction for
> getting source, and links where dev VCS, release snapshots.
>
> Also nice have DVCS read only mirror if development
> done in CVS/SVN.
>
> PS.
> After browsing through web interface to bzr on sourceforge
> I found code/trunk dir and this work:
>
>     $  bzr clone bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk
> cedet
>
> But don't know is this development trunk?
>
> Please clear where people can found CEDET sources on:
>
>       http://cedet.sourceforge.net
>

Hi,

Semantic will go off and do work, even when in knows there is nothing to 
do.  It is basically pre-parsing files for you, and that work is not 
related to comments or strings.

If you have a particularly large code base, and you would rather wait 
when you ask for something instead of the idle interruptions, you should 
turn off the following:

semantic-idle-work-parse-neighboring-files-flag
semantic-idle-work-update-headers-flag

You could also just move out when it happens here:

semantic-idle-scheduler-work-idle-time

I posted on stackoverflow about this recently on a question with an 
Emacs tag.  I need to get that info merged into the CEDET info file still.

Eric

On 09/30/2010 09:54 AM, Nate Schley wrote:
> Eric,
>
> I find that often, when place the cursor in // a code comment
>   or "a literal string", I find myself waiting for semantic to digest
> gobs of files in an apparent attempt to look up what should be ignored.
> Happily, ^G works eventually, but it is an interruption to the workflow.
>
> As an enhancement to your excellent SW, may I suggest first checking to
> see if the point lies in a comment or literal string before charging off
> into the look-up task.
>
> FWIW, I'm working in C++ with more kSLOCs than you can shake a stick at.
> --
> Thanks,
>
> Nate
>

On 09/26/2010 04:11 PM, Oleksandr Gavenko wrote:
> GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) from GNU ftp.
>
> CEDET source latest from
>
>     bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk
>
> I visit ~/devel/cedet/cedet-build.el and
>     M-x eval-buffer
>     M-x cedet-build-in-default-emacs
>
> And in spawned Emacs in *Compile-Log* buffer there are a lot of:
>
> eieio.el:2550:13:Error: Symbol's value as variable is void: filename
> eieio.el:2550:13:Error: Symbol's value as variable is void: filename
> eieio-custom.el:331:1:Error: Symbol's value as variable is void: filename
> eieio-base.el:56:1:Error: Symbol's value as variable is void: filename
> chart.el:179:1:Error: Symbol's value as variable is void: filename
> linemark.el:242:1:Error: Symbol's value as variable is void: filename
> lmcompile.el:56:1:Error: Symbol's value as variable is void: filename
> semantic-scope.el:97:1:Error: Symbol's value as variable is void: filename
> ...........       ..............     ............
>
> Its OK?
>

I seem to remember this being related to the version of the byte 
compiler being used, though if you have Emacs 23.2, and the latest 
CEDET, you should be in good shape.

It comes out from eieio-comp.el around line 100 where it is attempting 
to just print out the current compilation function.

If this is broken, the quickest fix is to turn off byte-compile-verbose. 
  Eventually someone with Emacs 23.2 will probably want to find a better 
way to implement that feature than pulling in the filename from some 
other functions scope.

Eric

On 2010-09-26 23:27, Oleksandr Gavenko wrote:
>    From  docs:
>
> (cedet-gnu-global-version-check&optional NOERROR)
>
> Check the version of the installed GNU Global command.
> If optional programatic argument NOERROR is non-nil, then
> instead of throwing an error if Global isn't available, then
> return nil.
>
> So to proper enable GNU Global I wrote:
>
>    (when (cedet-idutils-version-check t)
>      (add-to-list 'ede-locate-setup-options 'ede-locate-idutils)
>     )
>
> But evaluation of (cedet-idutils-version-check t) take BackTrace:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>     inversion-<(nil (full 4 0))
>     inversion-check-version(nil nil "4.0")
>     cedet-idutils-version-check(t)
>     eval((cedet-idutils-version-check t))
>     eval-last-sexp-1(nil)
>     eval-last-sexp(nil)
>     call-interactively(eval-last-sexp nil nil)
>
GNU Emacs 23.2.1 (i386-mingw-nt5.1.2600) from GNU ftp.

CEDET source latest for current day from

    bzr://cedet.bzr.sourceforge.net/bzrroot/cedet/code/trunk

-- 
Best regards!

On 09/26/2010 04:27 PM, Oleksandr Gavenko wrote:
>    From  docs:
>
> (cedet-gnu-global-version-check&optional NOERROR)
>
> Check the version of the installed GNU Global command.
> If optional programatic argument NOERROR is non-nil, then
> instead of throwing an error if Global isn't available, then
> return nil.
>
> So to proper enable GNU Global I wrote:
>
>    (when (cedet-idutils-version-check t)
>      (add-to-list 'ede-locate-setup-options 'ede-locate-idutils)
>     )
>
> But evaluation of (cedet-idutils-version-check t) take BackTrace:
>
> Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
>     inversion-<(nil (full 4 0))
>     inversion-check-version(nil nil "4.0")
>     cedet-idutils-version-check(t)
>     eval((cedet-idutils-version-check t))
>     eval-last-sexp-1(nil)
>     eval-last-sexp(nil)
>     call-interactively(eval-last-sexp nil nil)
>

This is because the output of fnid was unexpected.  If after getting 
this you look in the buffer "*CEDET fnid*" you will see the output, and 
it should be of the form:

/someplace/fnid - 4.4

or whatever the version is.  If it doesn't say that, then there is 
probably some issue with idutils.

I checked in a change that should prevent the error.

Eric

On Sun, Sep 19, 2010 at 23:22, David Engster wrote:
> Well, I'd bet the 'explicit' thing is also not working? :-)
>
> This can be fixed by adding the token
>
> %token EXPLICIT "explicit"
> %put EXPLICIT summary "Forbids implicit type conversion: explicit <constructor>"
>
> in c.by.

        explicit Exifdatum(const ExifKey& key, const Value* pValue =0);

Yes, with these two lines that works too. Thanks!

Andreas

Andreas Huggel writes:
> On Sun, Sep 19, 2010 at 21:07, David Engster <deng@...> wrote:
>> their type that matters. Hence I think that tag-similar-p should check
>> the arguments; I attached a patch.
>
> This patch fixes all of the reported "wrong jumps" for overloaded
> functions except for this case in class Exifdatum:
>
>         std::string toString() const;                     // wrong jump
>         std::string toString(long n) const;

Those are nice test cases you got there. ;-) This one indeed fell
through. While tag-similar-p checks if both tags have the same number of
attributes, it also counts the attributes which should be ignored. As it
so happens, the first toString doesn't have :arguments, but it does have
a :prototype-flag, so the number of attributes with the (wrong) second
implementation is the same.

It's not hard to hack a little workaround, but I guess Eric wants to
rewrite that function anyway. :-) (Actually, to really catch everything,
one would have to check if both tags really have the same set of
attributes).

-David

On 09/19/2010 11:40 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> I discovered that this AM too.  There are a bunch of funny cases with
>> arguments though.  In the tests there are examples where the arg name
>> exists in one place but not another, for example, so I have some new
>> stuff to make that work.
>
> I see that you allow one name to be blank. But if I remember correctly,
> in overloaded functions the name doesn't matter at all and can be
> different. This is why in my patch I override the name with this hack
>
>   (setq tmp1 (append '("name") (cdr (nth counter args))))
>   (setq tmp2 (append '("name") (cdr (nth counter v))))
>
> so that the recursive call to tag-similar-p will effectively ignore
> it. Adding something like :name to ignore-attributes is nicer, for sure.
>

I hadn't checked your patch earlier because I had written mine before 
you posted.

The info about names being irrelevant is interesting.  It indicates that 
how the comparison is made should be mode specific, and that the 
comparison system probably is too complex for semantic-tag.el. 
semantic-tag.el has traditionally been only very simple code. 
semantic-tag-ls.el is where I've put language specific, yet relatively 
simple stuff.

I'm usually a bit wary of modifying tags.  The code you have above looks 
safe.  Sometimes tags from the main database can get modified 
unexpectedly, so you could use `semantic-tag-clone' to do the same thing.

David, if you'd like to keep poking at this that would be great.  I 
still need to figure out bzr.

Eric

Eric M. Ludlam writes:
> The info about names being irrelevant is interesting.  It indicates that 
> how the comparison is made should be mode specific, and that the 
> comparison system probably is too complex for semantic-tag.el. 
> semantic-tag.el has traditionally been only very simple code. 
> semantic-tag-ls.el is where I've put language specific, yet relatively 
> simple stuff.

I think it would make sense to make semantic-tag-similar-p a mode-local
function, with the current implementation being the default, ignoring
sublists of tags. I can then create a specific override for C(++).

> I'm usually a bit wary of modifying tags.  The code you have above looks 
> safe.  Sometimes tags from the main database can get modified 
> unexpectedly, so you could use `semantic-tag-clone' to do the same thing.

Yes, one has to be careful not to modify tags in-place, I already
experienced issues with that. But since I don't modify but only append
the cdr, I don't see how the tag could be modified, but using tag-clone
surely is less hacky, so I see your point.

David

On 09/19/2010 11:40 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> I discovered that this AM too.  There are a bunch of funny cases with
>> arguments though.  In the tests there are examples where the arg name
>> exists in one place but not another, for example, so I have some new
>> stuff to make that work.
>
> I see that you allow one name to be blank. But if I remember correctly,
> in overloaded functions the name doesn't matter at all and can be
> different. This is why in my patch I override the name with this hack
>
>   (setq tmp1 (append '("name") (cdr (nth counter args))))
>   (setq tmp2 (append '("name") (cdr (nth counter v))))
>
> so that the recursive call to tag-similar-p will effectively ignore
> it. Adding something like :name to ignore-attributes is nicer, for sure.
>

I have finally figured out the basics of bzr, and have checked in 
changes for tag-similar-p.  As discussed, it has mode overrides, and C 
mode.  In there, it will completely ignore names for arguments as you 
specify above, and the tests validate it.  The code is now in 
semantic-tag-ls.el too.

Since this is my first batch of bzr checkins that I think have made, it 
would be great if folks could give it a try.  I also checked in past 
diffs I had posted here.

Thanks
Eric

On 09/19/2010 11:22 AM, David Engster wrote:
> Andreas Huggel writes:
>> On Sun, Sep 19, 2010 at 21:07, David Engster<deng@...>  wrote:
>>> their type that matters. Hence I think that tag-similar-p should check
>>> the arguments; I attached a patch.
>>
>> This patch fixes all of the reported "wrong jumps" for overloaded
>> functions except for this case in class Exifdatum:
>>
>>          std::string toString() const;                     // wrong jump
>>          std::string toString(long n) const;
>>
>> That's already much better, thanks!
>
> Well, I'd bet the 'explicit' thing is also not working? :-)
>
> This can be fixed by adding the token
>
> %token EXPLICIT "explicit"
> %put EXPLICIT summary "Forbids implicit type conversion: explicit<constructor>"
>
> in c.by.
>
> This already avoids that the keyword is identified as a type. To be
> extra sure, we could also add something like
>
>     | EXPLICIT
>       ()
>
> for example in builtin-type (although it's not a type, but where else to
> put this?).

This could be added to the DECLMOD rule, which includes things like 
EXTERN and STATIC.  I know it is just for constructors, but c.by can't 
find constructors since it doesn't keep a state table to check against 
along the way.

Eric

Eric M. Ludlam writes:
> Since this is my first batch of bzr checkins that I think have made, it 
> would be great if folks could give it a try.  I also checked in past 
> diffs I had posted here.

Maybe I'm mistaken, but from the logs it seems to me that you directly
pushed to trunk from within a task branch, meaning you did

bzr push bzr+ssh://CEDET-URL/code/trunk

while still in the 'similarp' branch. This is not a good idea with
bzr. Maybe this is OK as long as there are no merges from trunk
involved, but in any case, I'd avoid it. In Bazaar, revision numbers are
always specific to a certain branch. If you push a task branch upstream,
this will make upstream a mirror of your task branch, possibly with new
revision numbers. This can lead to a strange history display for other
developers which are again merging your changes from trunk (because they
are in fact merging the history of your task branch).

Bzr encourages a 'merge to local trunk branch and push' workflow: When
you have finished some feature on a separate task branch, usually
involving several smaller commits, you merge those changes into the
trunk and then push. This is described in Lluis' docs in the last
paragraph titled "Merging into the mainline". You would then choose a
commit messages which shortly summarizes the changes you did in that
task branch; in the normal history view with 'bzr log', you'd only see
that summary, not the single commits you did in that branch.

By doing so, you get a hierarchical history, which can be seen fully by
using "bzr log -n0" instead of the default "bzr log", which uses "-n1".
Just try those two commands on the Emacs repo to get an impression. The
latter will only show you the merge messages ("flat view"), while the
former will also display the commits contained in those merges (those
are indented).

If you think this stuff is overkill, I'd say just work directly on the
trunk; this pretty much gives you a workflow like an 'offline CVS', in
which you explicitly have to push changes upstream.

-David

On 09/24/2010 10:25 AM, David Engster wrote:
> Eric M. Ludlam writes:
>> Since this is my first batch of bzr checkins that I think have made, it
>> would be great if folks could give it a try.  I also checked in past
>> diffs I had posted here.
>
> Maybe I'm mistaken, but from the logs it seems to me that you directly
> pushed to trunk from within a task branch, meaning you did
>
> bzr push bzr+ssh://CEDET-URL/code/trunk
>
> while still in the 'similarp' branch. This is not a good idea with
> bzr. Maybe this is OK as long as there are no merges from trunk
> involved, but in any case, I'd avoid it. In Bazaar, revision numbers are
> always specific to a certain branch. If you push a task branch upstream,
> this will make upstream a mirror of your task branch, possibly with new
> revision numbers. This can lead to a strange history display for other
> developers which are again merging your changes from trunk (because they
> are in fact merging the history of your task branch).
>
> Bzr encourages a 'merge to local trunk branch and push' workflow: When
> you have finished some feature on a separate task branch, usually
> involving several smaller commits, you merge those changes into the
> trunk and then push. This is described in Lluis' docs in the last
> paragraph titled "Merging into the mainline". You would then choose a
> commit messages which shortly summarizes the changes you did in that
> task branch; in the normal history view with 'bzr log', you'd only see
> that summary, not the single commits you did in that branch.
>
> By doing so, you get a hierarchical history, which can be seen fully by
> using "bzr log -n0" instead of the default "bzr log", which uses "-n1".
> Just try those two commands on the Emacs repo to get an impression. The
> latter will only show you the merge messages ("flat view"), while the
> former will also display the commits contained in those merges (those
> are indented).
>
> If you think this stuff is overkill, I'd say just work directly on the
> trunk; this pretty much gives you a workflow like an 'offline CVS', in
> which you explicitly have to push changes upstream.

Hi David,

I figured some of that out after the fact.  I had used the checkout 
branch technique first just to get some little stuff in.  That meant I 
head 'trunk' as a checkout.  When I went to merge similarp into trunk it 
failed (as far as I can remember) because it wasn't the right kind of 
trunk.  Reading through I saw how push worked, tried it, and it did stuff.

I suspect I would use a checkout of trunk for most things, since I do 
lots of small patches, but I like the idea of having branches for bigger 
tasks.  I then am stuck with deleting trunk each time I do an operation?

The nice thing about my CVS workflow was that I just pointed Emacs at 
it, and I was good to go.  All the branching means I have to restart 
Emacs all the time.  If I'm deleting trunk a lot that would be a challenge.

I'm sure there's a good workflow to use.  I just need to break away from 
my old one.

Eric

Eric M. Ludlam writes:
> I figured some of that out after the fact.  I had used the checkout 
> branch technique first just to get some little stuff in.  That meant I 
> head 'trunk' as a checkout.  When I went to merge similarp into trunk it 
> failed (as far as I can remember) because it wasn't the right kind of 
> trunk.  Reading through I saw how push worked, tried it, and it did stuff.
>
> I suspect I would use a checkout of trunk for most things, since I do 
> lots of small patches, but I like the idea of having branches for bigger 
> tasks.  I then am stuck with deleting trunk each time I do an operation?

No. You can do 'bzr unbind' to convert a checkout into a regular
branch (and 'bind' does vice versa). But you already see that using
checkouts with task branches make stuff actually more complicated.

I don't see a reason to use checkouts at all, unless you're developing
something entirely on your own (and are always online). Instead, for
(relatively) quick fixes, just work on the trunk branch, do your
commits, and do 'bzr push <URL>' when finished (you only have to specify
the URL the first time; it will be remembered afterwards).

This has two main advantages over checkouts: You can do commits while
offline, and the commits can be much more granular, since you don't have
to worry about breaking the build upstream - you only push when you've
finished something. You probably remember that my continuous integration
testing for CEDET sometimes reported build errors because you were right
in the middle of fixing something when the build-test ran.

> The nice thing about my CVS workflow was that I just pointed Emacs at 
> it, and I was good to go.  All the branching means I have to restart 
> Emacs all the time.  If I'm deleting trunk a lot that would be a challenge.

You should never have to delete the trunk branch. Restarting Emacs with
a changed load-path would only be necessary to test a task branch. As
you already wrote, task branches are really useful for bigger stuff. For
example, I'm currently using a task branch for the F90 support,
regularly merging from trunk to detect conflicts early on. This makes a
later merge into the trunk much easier.

CEDET is different from projects like Emacs in that ~99% of the commits
are done by you. Hence, stuff like 'merging from trunk' is not as
crucial to you, since your trunk branch will almost always be
up-to-date, and you can just avoid creating a conflict with one of your
task branches in the first place. Actually, it's people like me which
profit much more from a DVCS than you. I can work for weeks on some
feature, regularly merge from trunk to detect conflicts early on, and
then merge or push a separate branch for you to review.

So, I'd also like to thank Lluis for the terrific work he has done so
far with the bzr transition!

-David

> Since this is my first batch of bzr checkins that I think have made, it
> would be great if folks could give it a try.  I also checked in past
> diffs I had posted here.

I've re-run my black-box tests from above with bzr revision 7986 and
emacs 22.3.1 on Mac OS X 10.6.4
Out of the 26 issues reported earlier, 20 are fixed. Great! The
remaining cases are:

    class EXIV2API Exifdatum : public Metadatum {
    public:
        explicit Exifdatum(const ExifKey& key, const Value* pValue
=0);   // no impl
        std::string toString() const;   // wrong jump
        std::string toString(long n) const;   // ok!
    };

    class EXIV2API ExifData {
    public:
        iterator erase(iterator pos);   // no impl
        iterator erase(iterator beg, iterator end);   // no impl
        iterator findKey(const ExifKey& key);   // no impl
        const_iterator findKey(const ExifKey& key) const;   // no impl
    };


Andreas

Berndl, Klaus <klaus.berndl <at> capgemini.com> writes:

> 
> Hi,
> 
> See the option `ecb-prescan-directories-for-emptyness'...
> 






Problem solved by this line in the ECB configuration part in ".emacs"

'(ecb-excluded-directories-regexps (quote ("agschaef")))

aneesh.kumar@... (Aneesh Kumar K.V) writes:

> After the sync with CEDET 1.0, ede-linux support seems to be
> broken. Visting a linux kernel directory gives the error
>
> ede-directory-project-p: Cannot open load file: ede-linux

Should be fixed now, thanks for the report.