CEDET

Hi,

I'm using ede-cpp-root-project to create an ede-project from existing files.

(ede-cpp-root-project "FLANN"
                :name "Flann1.8"
                :file
"~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt"
:include-path '("/test/"
                                "/examples/"
"/src/cpp/flann/"
"/src/cpp/flann/algorithms/"
                                "/src/cpp/flann/io/"
"/src/cpp/flann/mpi/"
"/src/cpp/flann/nn/"
"/src/cpp/flann/util/"
                               )
                :system-include-path '("/usr/include/"
"usr/include/c++/4.7/")
                :spp-table '(("isUnix" . "")
                             ("BOOST_TEST_DYN_LINK" . "")))

However, when opening any .cpp or .h file there are some unsolved includes,
most of them coming from files within the directories defined in the
:include-path field. I thought that listing all includes directories as I
do was enough for semantic to analyse and solve all dependencies and so.

Semantic-c-describe-environment gives this as output

Include Path Summary:
  This file's project include is handled by:
    EDE : #<ede-cpp-root-target
/home/carrenom/Documents/PhD/Code/Kd-Trees_NNS/Flann/src/cpp/flann/util/>
     with the system path:
    /usr/include/
    usr/include/c++/4.7/

  This file's system include path is:
    /usr/include
    /usr/lib/gcc/x86_64-linux-gnu/4.7/include/
    /usr/local/include/
    /usr/lib/gcc/x86_64-linux-gnu/4.7/include-fixed/
    /usr/include/x86_64-linux-gnu/
    /usr/include/

So my definition is not working. Is there something I forgot to include? Do
I have to use semantic-add-system-include with each directory?

Regards,

Pamela

Re: [CEDET-devel] Unsolved includes using ede-cpp-root-project definition From: Lluís <xscript@gm...> - 2013-05-07 20:19 Pamela Carreño writes: > Hi, > I'm using ede-cpp-root-project to create an ede-project from existing files. > (ede-cpp-root-project "FLANN" > :name "Flann1.8" > :file "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt" I think EDE does not expand filenames for you (maybe that should be implemented, or at least clearly documented). Try this instead: :file (expand-file-name "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt") BTW, this reminds me that all my 'ede-cpp-root-project' are guarded with a 'file-exists-p', as EDE otherwise throws out an error complaining about non-existing files. Is there a reason for this behaviour? Wouldn't it be more comfortable to check that inside EDE? Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth

Re: [CEDET-devel] Unsolved includes using ede-cpp-root-project definition From: Eric M. Ludlam <eric@si...> - 2013-05-12 21:36 On 05/07/2013 04:19 PM, Lluís wrote: > Pamela Carreño writes: > >> Hi, >> I'm using ede-cpp-root-project to create an ede-project from existing files. > >> (ede-cpp-root-project "FLANN" >> :name "Flann1.8" >> :file "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt" > > I think EDE does not expand filenames for you (maybe that should be implemented, > or at least clearly documented). Try this instead: > > :file (expand-file-name "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt") > I checked, and I'm pretty sure the :file is expanded. For example, see this from ede/cpp-root.el: (let ((f (expand-file-name (oref this :file)))) ... (oset this :file f) Is there something else causing problems? > BTW, this reminds me that all my 'ede-cpp-root-project' are guarded with a > 'file-exists-p', as EDE otherwise throws out an error complaining about > non-existing files. > > Is there a reason for this behaviour? Wouldn't it be more comfortable to check > that inside EDE? What do you propose EDE do if the incoming file doesn't exist? Wouldn't it still throw an error, or do you think it needs a better error? Thanks Eric

Re: [CEDET-devel] Unsolved includes using ede-cpp-root-project definition From: Pamela Carreño <carrenopamela@gm...> - 2013-05-13 07:41 Attachments: Message as HTML      Hi, thank you for your replies. I tried using :file (expand-file-name "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt") as LLuis suggested, however it did not work and there are still several unsolved includes. I tried to use semantic-add-system-include for every directory like this (defun my-flann-semantic-hook () (setq FLANN-base-dir "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/") (semantic-add-system-include (concat FLANN-base-dir "test/") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "examples/") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/algorithms") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/io") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/mpi") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/nn") 'c++-mode) (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/util") 'c++-mode)) (add-hook 'semantic-init-hooks 'my-flann-semantic-hook) and although Semantic-c-describe-environment now list every path... It did not work at all. What else can I try? Thanks, Pamela On Sun, May 12, 2013 at 11:36 PM, Eric M. Ludlam <eric@...: > On 05/07/2013 04:19 PM, Lluís wrote: > >> Pamela Carreño writes: >> >> Hi, >>> I'm using ede-cpp-root-project to create an ede-project from existing >>> files. >>> >> >> (ede-cpp-root-project "FLANN" >>> :name "Flann1.8" >>> :file "~/Documents/PhD/Code/Kd-**Trees_NNS/Flann/CMakeLists.**txt" >>> >> >> I think EDE does not expand filenames for you (maybe that should be >> implemented, >> or at least clearly documented). Try this instead: >> >> :file (expand-file-name "~/Documents/PhD/Code/Kd-** >> Trees_NNS/Flann/CMakeLists.**txt") >> >> > I checked, and I'm pretty sure the :file is expanded. For example, see > this from ede/cpp-root.el: > > (let ((f (expand-file-name (oref this :file)))) > ... > (oset this :file f) > > Is there something else causing problems? > > > BTW, this reminds me that all my 'ede-cpp-root-project' are guarded with a >> 'file-exists-p', as EDE otherwise throws out an error complaining about >> non-existing files. >> >> Is there a reason for this behaviour? Wouldn't it be more comfortable to >> check >> that inside EDE? >> > > What do you propose EDE do if the incoming file doesn't exist? Wouldn't > it still throw an error, or do you think it needs a better error? > > Thanks > Eric > -- Pamela Carreño Medrano PhD. candidate in Computer Science IRISIA Lab/ Seaside team University of Southern Brittany - UBS Vannes, France

Re: [CEDET-devel] Unsolved includes using ede-cpp-root-project definition From: Pamela Carreño <carrenopamela@gm...> - 2013-05-13 12:28 Attachments: Message as HTML      Hi again, I was able to solve my problem, it seems that everything was related to the #include statements in the source-code and now after executing C-u M-x bovinate almost all the dependencies are solved. However, every time I initialize a new emacs session I'm obligated to call bovinate, is there a possible way to do it only once? Regards, Pamela On Mon, May 13, 2013 at 9:41 AM, Pamela Carreño <carrenopamela@...: > Hi, > > thank you for your replies. I tried using > > :file (expand-file-name "~/Documents/PhD/Code/Kd- > Trees_NNS/Flann/CMakeLists.txt") as LLuis suggested, however it did not > work and there are still several unsolved includes. > > I tried to use semantic-add-system-include for every directory like this > > (defun my-flann-semantic-hook () > (setq FLANN-base-dir "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/") > (semantic-add-system-include (concat FLANN-base-dir "test/") 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "examples/") 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann") > 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir > "src/cpp/flann/algorithms") 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/io") > 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/mpi") > 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/nn") > 'c++-mode) > (semantic-add-system-include (concat FLANN-base-dir "src/cpp/flann/util") > 'c++-mode)) > (add-hook 'semantic-init-hooks 'my-flann-semantic-hook) > > and although Semantic-c-describe-environment now list every path... It > did not work at all. > > What else can I try? > > Thanks, > > Pamela > > > On Sun, May 12, 2013 at 11:36 PM, Eric M. Ludlam <eric@...: > >> On 05/07/2013 04:19 PM, Lluís wrote: >> >>> Pamela Carreño writes: >>> >>> Hi, >>>> I'm using ede-cpp-root-project to create an ede-project from existing >>>> files. >>>> >>> >>> (ede-cpp-root-project "FLANN" >>>> :name "Flann1.8" >>>> :file "~/Documents/PhD/Code/Kd-**Trees_NNS/Flann/CMakeLists.**txt" >>>> >>> >>> I think EDE does not expand filenames for you (maybe that should be >>> implemented, >>> or at least clearly documented). Try this instead: >>> >>> :file (expand-file-name "~/Documents/PhD/Code/Kd-** >>> Trees_NNS/Flann/CMakeLists.**txt") >>> >>> >> I checked, and I'm pretty sure the :file is expanded. For example, see >> this from ede/cpp-root.el: >> >> (let ((f (expand-file-name (oref this :file)))) >> ... >> (oset this :file f) >> >> Is there something else causing problems? >> >> >> BTW, this reminds me that all my 'ede-cpp-root-project' are guarded with >>> a >>> 'file-exists-p', as EDE otherwise throws out an error complaining about >>> non-existing files. >>> >>> Is there a reason for this behaviour? Wouldn't it be more comfortable to >>> check >>> that inside EDE? >>> >> >> What do you propose EDE do if the incoming file doesn't exist? Wouldn't >> it still throw an error, or do you think it needs a better error? >> >> Thanks >> Eric >> > > > > -- > Pamela Carreño Medrano > PhD. candidate in Computer Science > IRISIA Lab/ Seaside team > University of Southern Brittany - UBS > Vannes, France >

Re: [CEDET-devel] Unsolved includes using ede-cpp-root-project definition From: Lluís <xscript@gm...> - 2013-05-13 14:54 Eric M Ludlam writes: > On 05/07/2013 04:19 PM, Lluís wrote: >> Pamela Carreño writes: >> >>> Hi, >>> I'm using ede-cpp-root-project to create an ede-project from existing files. >> >>> (ede-cpp-root-project "FLANN" >>> :name "Flann1.8" >>> :file "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt" >> >> I think EDE does not expand filenames for you (maybe that should be implemented, >> or at least clearly documented). Try this instead: >> >> :file (expand-file-name "~/Documents/PhD/Code/Kd-Trees_NNS/Flann/CMakeLists.txt") >> > I checked, and I'm pretty sure the :file is expanded. For example, see > this from ede/cpp-root.el: > (let ((f (expand-file-name (oref this :file)))) > ... > (oset this :file f) > Is there something else causing problems? I just re-checked, and using "~" in my ":file" does not "activate" the project when I edit a file from it (although it does not complain about a non-existing ":file"). >> BTW, this reminds me that all my 'ede-cpp-root-project' are guarded with a >> 'file-exists-p', as EDE otherwise throws out an error complaining about >> non-existing files. >> >> Is there a reason for this behaviour? Wouldn't it be more comfortable to check >> that inside EDE? > What do you propose EDE do if the incoming file doesn't exist? Wouldn't > it still throw an error, or do you think it needs a better error? I think that attribute ":file" should act as a "guard" to know whether and when to associate a project to another file. Thus creating an "ede-cpp-root-project" with a non-existing ":file" should not complain (but the project should exist in EDE, just in case the file is created later). Lluis -- "And it's much the same thing with knowledge, for whenever you learn something new, the whole world becomes that much richer." -- The Princess of Pure Reason, as told by Norton Juster in The Phantom Tollbooth

Hello all,

I installed the latest repository version of CEDET and disabled the version
that is bundled with Emacs 24.3. After skimming the manual and reading Alex
Ott's article "A Gentle Introduction to CEDET" I made several additions to
my .emacs file. Once I made all of the recommended changes, I tried to edit
a simple Java file. Code completion with auto-complete is functional, but
extremely slow, even after the trying the same function from the same class
twice (System.out.println). I would also add that CEDET does not seem to
pick up the methods of the objects statically in the packages either. I am
not sure if this is an error or functionality that just needs to be added
at a later date.

My second problem is that when I try to edit a C file, auto-complete (I am
using version 1.4 that comes in the package repository) does not bring up
any completions. I tried several configuration changes to my ,emacs file in
an effort to get the auto-complete menu to work. It works great in Emacs
Lisp mode. Additionally, normal semantic completion works fine once
enabled. Can anyone give me a hand with either of these issues?

By the way, the link to "smart completion debugging" in the CEDETmanual is
broken.

Thank you,

Stephen

Re: [CEDET-devel] semanticdb-javap; cc-mode, CEDET, and auto-complete-1.4 From: Eric M. Ludlam <eric@si...> - 2013-05-12 21:48 Hi Stephen, I'm not that familiar with auto-complete, but if you check the Emacs Wiki: http://www.emacswiki.org/emacs/AutoComplete you will find this text: If you are using the current development version of AutoComplete (0.20 at the time of this edit) be aware that ac-source-semantic is now included in the package. Furthermore, if you are using the semantic source, make sure that you have required semantic-ia in your init file. If you do not then it falls back to a method of gathering the tags that appears to not check the semantic cache slowing the whole thing up rather tremendously (especially with omnicompletion). Eric On 05/07/2013 09:00 PM, Stephen Debique wrote: > Hello all, > > I installed the latest repository version of CEDET and disabled the > version that is bundled with Emacs 24.3. After skimming the manual and > reading Alex Ott's article "A Gentle Introduction to CEDET" I made > several additions to my .emacs file. Once I made all of the recommended > changes, I tried to edit a simple Java file. Code completion with > auto-complete is functional, but extremely slow, even after the trying > the same function from the same class twice (System.out.println). I > would also add that CEDET does not seem to pick up the methods of the > objects statically in the packages either. I am not sure if this is an > error or functionality that just needs to be added at a later date. > > My second problem is that when I try to edit a C file, auto-complete (I > am using version 1.4 that comes in the package repository) does not > bring up any completions. I tried several configuration changes to my > ,emacs file in an effort to get the auto-complete menu to work. It works > great in Emacs Lisp mode. Additionally, normal semantic completion works > fine once enabled. Can anyone give me a hand with either of these issues? > > By the way, the link to "smart completion debugging" in the CEDETmanual > is broken. > > Thank you, > > Stephen > > > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and > their applications. This 200-page book is written by three acclaimed > leaders in the field. The early access version is available now. > Download your free book today! http://p.sf.net/sfu/neotech_d2d_may > > > > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel

Re: [CEDET-devel] semanticdb-javap; cc-mode, CEDET, and auto-complete-1.4 From: Stephen Debique <stephen.debique@gm...> - 2013-05-13 02:27 Attachments: Message as HTML      Hi Mr. Ludlam, Thanks for your reply and help. I have seen the aforementioned emacs wiki entry and I do have require semantic/ia in my .emacs file. I also think the wiki statement about semantic being in the package for ac-sources is irrelevant in my particular case. You still have to add ac-source-semantic as an ac-source regardless. I had already tried not adding it before emailing the list. I will add that even when I do not use the autocomplete package the native CEDET "intellisense" is still slower in Java mode than in other modes, though faster than when autocomplete is added to the mix. I suspect it may have to do with the dependence on javap but I could be terribly off on that attempt of code sleuthing. Once I lose the autocomplete package, the "intellisense" works in cc-mode as well, however, sans the fancy autocomplete menu (whose utility is debatable I suppose). Regards, Stephen On Sun, May 12, 2013 at 5:48 PM, Eric M. Ludlam <eric@...: > Hi Stephen, > > I'm not that familiar with auto-complete, but if you check the Emacs Wiki: > > http://www.emacswiki.org/**emacs/AutoComplete<http://www.emacswiki.org/emacs/AutoComplete> > > you will find this text: > > If you are using the current development version of AutoComplete (0.20 > at the time of this edit) be aware that ac-source-semantic is now > included in the package. Furthermore, if you are using the semantic > source, make sure that you have required semantic-ia in your init > file. If you do not then it falls back to a method of gathering the > tags that appears to not check the semantic cache slowing the whole > thing up rather tremendously (especially with omnicompletion). > > Eric > > > On 05/07/2013 09:00 PM, Stephen Debique wrote: > >> Hello all, >> >> I installed the latest repository version of CEDET and disabled the >> version that is bundled with Emacs 24.3. After skimming the manual and >> reading Alex Ott's article "A Gentle Introduction to CEDET" I made >> several additions to my .emacs file. Once I made all of the recommended >> changes, I tried to edit a simple Java file. Code completion with >> auto-complete is functional, but extremely slow, even after the trying >> the same function from the same class twice (System.out.println). I >> would also add that CEDET does not seem to pick up the methods of the >> objects statically in the packages either. I am not sure if this is an >> error or functionality that just needs to be added at a later date. >> >> My second problem is that when I try to edit a C file, auto-complete (I >> am using version 1.4 that comes in the package repository) does not >> bring up any completions. I tried several configuration changes to my >> ,emacs file in an effort to get the auto-complete menu to work. It works >> great in Emacs Lisp mode. Additionally, normal semantic completion works >> fine once enabled. Can anyone give me a hand with either of these issues? >> >> By the way, the link to "smart completion debugging" in the CEDETmanual >> is broken. >> >> Thank you, >> >> Stephen >> >> >> >> ------------------------------**------------------------------** >> ------------------ >> Learn Graph Databases - Download FREE O'Reilly Book >> "Graph Databases" is the definitive new guide to graph databases and >> their applications. This 200-page book is written by three acclaimed >> leaders in the field. The early access version is available now. >> Download your free book today! http://p.sf.net/sfu/neotech_**d2d_may<http://p.sf.net/sfu/neotech_d2d_may> >> >> >> >> ______________________________**_________________ >> Cedet-devel mailing list >> Cedet-devel@... <Cedet-devel@...> >> https://lists.sourceforge.net/**lists/listinfo/cedet-devel<https://lists.sourceforge.net/lists/listinfo/cedet-devel> >> >

The user documentation linked at
http://www.randomsample.de/cedetdocs/semantic/semantic/Semantic-manuals.html#Semantic-manuals
contains a link to the user manual
http://www.randomsample.de/cedetdocs/semantic/semantic-user/index.html#Top
which is broken, and should actually be
http://www.randomsample.de/cedetdocs/semantic/user-guide/
Other links are broken as well.

Someone please fix this, as it is quite off-putting to new users to
find the links to the user documentation broken.

Re: [CEDET-devel] broken documentation links From: David Engster <deng@ra...> - 2013-05-08 20:51 Florian Dold writes: > Other links are broken as well. Thanks for the report. This should be fixed, but I had to change the directory structure, so all links are changed now. -David

I suddenly discovered my Info-directory-list variable was broken. It
didn't have a path that I'd added in the INFOPATH environment variable.

I think a setq in cedet-devel-load.el (bzr version of CEDET) is
responsible. After making the change below -- I've just copied the
corresponding bit from cedet-1.1, but don't know whether this is the
right thing to do -- things are working again, so I thought I'd report.

Not subscribed to the list. It'd be great if you could please cc me in
on replies. 

Thanks,
Mandar.

--- Output of "bzr diff" ---

=== modified file 'cedet-devel-load.el'
--- cedet-devel-load.el 2013-04-06 03:12:12 +0000
+++ cedet-devel-load.el 2013-04-23 11:26:23 +0000
@@ -56,9 +56,14 @@
     (load (expand-file-name "lisp/cedet/cogre/loaddefs.el" CEDETDIR) nil t t)
     (load (expand-file-name "lisp/cedet/srecode/loaddefs.el" CEDETDIR) nil t t)
     (load (expand-file-name "lisp/cedet/semantic/loaddefs.el" CEDETDIR) nil t t)
-    (setq Info-directory-list
-         (cons (expand-file-name "doc/info" CEDETDIR)
-               Info-default-directory-list)))
+    (let ((fulldocpath (expand-file-name "doc/info" CEDETDIR)))
+      (if (featurep 'info)
+          (progn
+            (condition-case nil ; Not all emacs versions have this.
+                (info-initialize)
+              (error nil))
+            (add-to-list 'Info-directory-list fulldocpath))
+        (add-to-list 'Info-default-directory-list fulldocpath))))
 
   ;; Load in COMPAT code - This is because NEW CEDET code may use this
   ;; for compatibility reasons, but Emacs integrated code removes it.

Re: [CEDET-devel] Info-directory-list: use add-to-list instead of setq? From: Eric M. Ludlam <eric@si...> - 2013-05-07 00:42 Hi Mandar, Thanks for the patch. I think you identified the right stuff in that this needs to be able to run before info loads. I worry though about changing the default info path though. Maybe the right thing is to have an eval-after-load call to just update the info load path after other configurations run. Perhaps someone who is more familiar with Info init on the mailing list can lend some advice? Eric On 04/23/2013 07:42 AM, Mandar Mitra wrote: > I suddenly discovered my Info-directory-list variable was broken. It > didn't have a path that I'd added in the INFOPATH environment variable. > > I think a setq in cedet-devel-load.el (bzr version of CEDET) is > responsible. After making the change below -- I've just copied the > corresponding bit from cedet-1.1, but don't know whether this is the > right thing to do -- things are working again, so I thought I'd report. > > Not subscribed to the list. It'd be great if you could please cc me in > on replies. > > Thanks, > Mandar. > > --- Output of "bzr diff" --- > > === modified file 'cedet-devel-load.el' > --- cedet-devel-load.el 2013-04-06 03:12:12 +0000 > +++ cedet-devel-load.el 2013-04-23 11:26:23 +0000 > @@ -56,9 +56,14 @@ > (load (expand-file-name "lisp/cedet/cogre/loaddefs.el" CEDETDIR) nil t t) > (load (expand-file-name "lisp/cedet/srecode/loaddefs.el" CEDETDIR) nil t t) > (load (expand-file-name "lisp/cedet/semantic/loaddefs.el" CEDETDIR) nil t t) > - (setq Info-directory-list > - (cons (expand-file-name "doc/info" CEDETDIR) > - Info-default-directory-list))) > + (let ((fulldocpath (expand-file-name "doc/info" CEDETDIR))) > + (if (featurep 'info) > + (progn > + (condition-case nil ; Not all emacs versions have this. > + (info-initialize) > + (error nil)) > + (add-to-list 'Info-directory-list fulldocpath)) > + (add-to-list 'Info-default-directory-list fulldocpath)))) > > ;; Load in COMPAT code - This is because NEW CEDET code may use this > ;; for compatibility reasons, but Emacs integrated code removes it. > > > ------------------------------------------------------------------------------ > Try New Relic Now& We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app,& servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel >

Hello,

I'm working on a mixed c / c++ project and I'm finding myself having to
add the system includes twice, once for each mode. Is there a way I can
add them to both in one call.

Thanks,

Simon

Re: [CEDET-devel] semantic-add-system-include for multiple modes From: Eric M. Ludlam <eric@si...> - 2013-05-07 00:31 On 04/18/2013 09:20 AM, Simon Brown wrote: > Hello, > > I'm working on a mixed c / c++ project and I'm finding myself having to > add the system includes twice, once for each mode. Is there a way I can > add them to both in one call. Unfortunately, you do have to bind include paths to each mode. Often you can configure an variable for C and have it work with C++ if C++ never specified anything, but since C and C++ already have both created their own include paths, you need to update them independently. Eric

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>
<div>Hi all,</div>

<div>loading cedet (bzr version 8557)&nbsp; with Emacs 24.2.1 (and equally emacs 24.3.1) leads to the following warning:</div>

<div>&nbsp;</div>

<div>Warning (initialization): An error occurred while loading &#96;/home/martin/.emacs.d/init.el&#39;:</div>

<div>error: eieio is already loaded.&nbsp; Removing CEDET now would be unwise.</div>

<div>&nbsp;</div>

<div>I uploaded a full backtrace here http://pastebin.com/n6sPhgXz</div>

<div>&nbsp;</div>

<div>This error occurs even if I use an init file for emacs that only contains the following line:</div>

<div>(load-file &quot;~/tools/emacs/cedet/cedet-devel-load.el&quot;)</div>

<div>&nbsp;</div>

<div>Everything works fine Emacs 23.4 though.</div>

<div>&nbsp;</div>

<div>Cheers</div>

<div>Martin</div>

<div>&nbsp;</div>

<div>&nbsp;</div>
</div></div></body></html>

Re: [CEDET-devel] Emacs24 Cedet launch error From: Martin Zapf <martin.zapf@gm...> - 2013-04-30 16:39 Hi all, Apologies for sending my previous email as HTML, here the text-version: Loading cedet (bzr version 8557)  with Emacs 24.2.1 (and equally emacs 24.3.1) leads to the following warning:   Warning (initialization): An error occurred while loading `/home/martin/.emacs.d/init.el': error: eieio is already loaded.  Removing CEDET now would be unwise.   I uploaded a full backtrace here http://pastebin.com/n6sPhgXz   This error occurs even if I use an init file for emacs that only contains the following line: (load-file "~/tools/emacs/cedet/cedet-devel-load.el")   Everything works fine Emacs 23.4 though.   Cheers Martin

Re: [CEDET-devel] Emacs24 Cedet launch error From: Tomasz Gajewski <tomga@wp...> - 2013-05-01 20:28 "Martin Zapf" <martin.zapf@...> writes: > This error occurs even if I use an init file for emacs that only > contains the following line: (load-file > "~/tools/emacs/cedet/cedet-devel-load.el") Problem is probably due to some package installed and initialized in /etc/emacs/site-start.d or similar (I assume you are on some linux flavour). If I correctly remember doxymacs is a package that causes this problem although it is probably not the only one. Generally this problem is an unpleasant one because there is no workaround on the user side. You can disable site init but you loose initializaion of all other packages so I don't consider this a good solution. You can only uninstall package from system and that is what I've done. Hope this helps. Regards Tomasz Gajewski

Re: [CEDET-devel] Emacs24 Cedet launch error From: Martin Zapf <martin.zapf@gm...> - 2013-05-02 16:54 Hi Tomasz, Thanks a million for your help! As you assumed correctly, doxymacs was indeed the culprit. After removing it, cedet loads without any hick-up. Cheers, Martin. > Gesendet: Mittwoch, 01. Mai 2013 um 22:28 Uhr > Von: "Tomasz Gajewski" <tomga@...> > An: "Martin Zapf" <martin.zapf@...> > Cc: cedet-devel@... > Betreff: Re: [CEDET-devel] Emacs24 Cedet launch error > > "Martin Zapf" <martin.zapf@...> writes: > > > This error occurs even if I use an init file for emacs that only > > contains the following line: (load-file > > "~/tools/emacs/cedet/cedet-devel-load.el") > > Problem is probably due to some package installed and initialized in > /etc/emacs/site-start.d or similar (I assume you are on some linux > flavour). If I correctly remember doxymacs is a package that causes this > problem although it is probably not the only one. > > Generally this problem is an unpleasant one because there is no > workaround on the user side. You can disable site init but you loose > initializaion of all other packages so I don't consider this a good > solution. You can only uninstall package from system and that is what > I've done. > > Hope this helps. > > Regards > Tomasz Gajewski >

David Engster writes:
> David Engster writes:
>> David Engster writes:
>>> The subject says it all. Clone from
>>>
>>> (git|http)://git.randomsample.de/cedet.git
>>
>> Unfortunately, the doc/texi directory is missing files somehow. I have
>> no idea why. If I cannot fix this, that mirror may be short-lived...
>
> And the whole semantic/tests directory is missing, so clearly this
> conversion does not work, either. :-(
>
> I've taken the mirror down again. Sorry, I should've tested it a little
> bit longer before publishing it.

The weirdest thing happened: I filed a bug, and it got fixed.

So, the mirror is back, though I'll wait a bit this time before
announcing it on the web page. Please let me know if you experience any
problems.

-David

On 03/05/2013 04:21 PM, David Engster wrote:
> Eric M. Ludlam writes:
>>>     - linemark.el
>>
>> Hmmm.  It is used by the matlab-emacs project on sourceforge.  And
>> someone copied that to support B++, or some language like that.
>
> Maybe we could check it in there, then. I'll look into it.

I checked linemark.el into the matlab-emacs repository, and updated 
build files there.

I couldn't find the old B+ code I mentioned.

Anyway, I don't know if any more dependencies for linemark.

Eric

Re: [CEDET-devel] Spring cleaning From: Alex Ott <alexott@gm...> - 2013-04-02 06:37 Attachments: Message as HTML      Hi I agree about having special place for projects with "work in progress" status. I usually prefer to do such things as separate branches in Git & use Github to publish them. I really don't know how it's better to organize this for bzr (and I don't want to spend much time to learn it - I would hack CEDET instead)... On Wed, Mar 6, 2013 at 2:47 AM, Eric M. Ludlam <eric@...: > On 03/05/2013 04:21 PM, David Engster wrote: > > Eric M. Ludlam writes: > >>> - linemark.el > >> > >> Hmmm. It is used by the matlab-emacs project on sourceforge. And > >> someone copied that to support B++, or some language like that. > > > > Maybe we could check it in there, then. I'll look into it. > > > >>> - ast.el: This was used by David Ponce for the Wisent C-grammar, > which > >>> is already in obsolete. I'd absolute love to see someone picking > >>> this up, but there's still a *lot* of work to be done to reach > the > >>> same feature-set as our current Bovine grammar (like, extending > it > >>> for C++...). > >> > >> There should be an unfinished projects area, like contrib. There are > >> lots of good ideas around that never quite make it, and just need > >> someone with the drive to make them work. I think the maven support was > >> like that for a while. > > > > I'm not happy with the 'contrib' directory at all. Most of the stuff > > there isn't working, and we regularly get bug reports about it. I also > > wouldn't encourage anyone to really work on that stuff, since we don't > > have papers for it. It's really unfortunate. I'd actually like to > > discourage people to use packages from there. > > Hmmm. I can see your point, as that stuff did not convert well. In the > old system they didn't really take up much time. They are kind of > home-less now though. > > > Anyway, regarding and 'unfinished' directory for stuff like the Wisent C > > grammar, I'm all for it. What else should go in there? > > To be a bit roughshod about it, anything not adopted into Emacs proper. > It could include Alex Ott's new java EDE packages, Arduino/Android > support, cogre, and anything else not adopted. > > That would make it pretty clear what was going on during merges. > > To be more conservative though, projects like Alex's java support could > just start there, and move into the main directories when "done". Alex > would have to let us know if those packages are "ready" for the mainline > at the moment. I don't really know since I don't code much Java. > > I can't think of anything else off the top though. > > Eric > > > ------------------------------------------------------------------------------ > Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester > Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the > endpoint security space. For insight on selecting the right partner to > tackle endpoint security challenges, access the full report. > http://p.sf.net/sfu/symantec-dev2dev > _______________________________________________ > Cedet-devel mailing list > Cedet-devel@... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > -- With best wishes, Alex Ott http://alexott.net/ Twitter: alexott_en (English), alexott (Russian) Skype: alex.ott

On 03/27/2013 11:30 PM, Joe Steeve wrote:
> Hello all,
>
> I know this is a sensitive topic and many people consider it
> sacrilegious. If this has already been discussed here and decided upon,
> please let me know.
>
> I have just asked two questions on this list so far. And, all the
> replies for the two questions have come as personal email. These replies
> should have come to the list so that it gets archived and is available
> for others to find when they google.
>
> Can we please have the 'reply-to' header munged by mailman to point to
> this list?

Hi Joe,

I received all my replies from you back via the mailing list.  The 
messages should be sent to you, and to the list both.

The reason to not force a reply to is sometimes people post who are not 
on the mailing list, and then they would never get any replies to their 
email.

This email, for example is going to both you and the cedet-devel list. 
I think mailman might be stripping you off it's actual sender list since 
it see's you in the to: field.

Eric

Re: [CEDET-devel] [OT] Request to munge the 'reply-to' header for this mailing list From: Joe Steeve <joe.steeve@gm...> - 2013-03-28 11:45 Attachments: signature.asc      On Thursday 28 March 2013 05:05 PM, Eric M. Ludlam wrote: > This email, for example is going to both you and the cedet-devel list. I > think mailman might be stripping you off it's actual sender list since > it see's you in the to: field. Yes, that was the problem. :) -- .o. I'm a Free man. I use Free Software. ..o ooo http://www.joesteeve.org/

On 03/27/2013 11:20 PM, Joe Steeve wrote:
>
> Hello Eric,
>
> Thanks for the reply.
>
> On Thursday 28 March 2013 07:34 AM, Eric M. Ludlam wrote:
>> To hard-code a project, you might have a file:
>>
>> ~/.srecode/moreatemplatesforC++.srt
>>
>> an in there, a line such as:
>>
>> set project "/path/to/my/project"
>
> I understood that bit from the doc. However, this means a template
> cannot be shared between projects. Am I right?

Right, they are for only one project at time.

When I had started, I had assumed that a project might have a subdir 
related to it's development that EDE would find (I never got that far) 
so if you had two copies of a project, they would each have their own 
template directory.  Thus no sharing.

 > I am curious about how the "local variables" attribute of EDE works.
 > The docs say that something there will make it project specific. Will
 > it make sense to create a dictionary of variables from there which get
 > loaded for each project separately? Do dictionaries behave like buffer
 > locals?

EDE project local variables are like buffer local variables.  These are 
distinct from variables in SRecode, unless an SRecode argument or 
template is pulling in an Emacs variable in some way.

Eric

1 message has been excluded from this view by a project administrator.

Previous Messages

Next Messages