Thread: [CEDET-devel] Clang completion on Linux sources
Brought to you by:
zappo
From: Lluís <xs...@gm...> - 2013-09-20 17:32:28
|
Hi! I've been trying semantic/bovine/clang.el and found out that it does not return any results. The culprit of the problem seems to be in 'semantic-clang-args-from-project', which is unable to establish the compilation flags because 'ede-proj-project-p' is false for a 'ede-object-root-project' that is an instance of 'ede-linux-project'. The result of this test kind of baffles me, since without knowing about semantic, it seems to me like the result of that test should be true. Thanks, 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 |
From: David E. <de...@ra...> - 2013-09-24 20:41:20
|
Lluís writes: > Hi! I've been trying semantic/bovine/clang.el and found out that it does not > return any results. I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and it showed some problems with finding system headers. I'll take a look at it soon. > The culprit of the problem seems to be in 'semantic-clang-args-from-project', > which is unable to establish the compilation flags because 'ede-proj-project-p' > is false for a 'ede-object-root-project' that is an instance of > 'ede-linux-project'. > > The result of this test kind of baffles me, since without knowing about > semantic, it seems to me like the result of that test should be true. Again, I'd suggest to use ede-cpp-root projects. I don't know why the Linux project behaves this way. It's probably a bug. Frankly, I don't know how useful the Linux project type is; I've never used it. If it is just confusing, maybe it would be better to remove it, or at least to disable it by default. -David |
From: Lluís <xs...@gm...> - 2013-09-26 21:37:23
|
Eric M Ludlam writes: > The earlier question about different make commands in different sub > directories can be handled similarly for anything that would be > generally helpful. The purpose of the custom project type is to have a > home for that sort of thing because there isn't a more generic type that > would work well for Linux sources. Well, I think the root of my question is whether it is possible to have some common project type that allows project auto-detection (like linux or automake), but that also supports loading information from the disk (i.e., a Project.ede file on the root of the project that contains further customizations set by the user). With this base feature, other things can be implemented on top (like project-specific compilation commands). This could be implemented by setting listed variables as buffer local. In the case of project-specific slot values, I'm at a loss. Actually, I was naively expecting the project customization buffer to be able to do so. The next step I see is to have the same with project configurations, so that enabling a configuration can override the value of some variables and/or project slots. The truth is that cedet is so big and complex that I don't even know if some of these features are already available. 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 |
From: Lluís <xs...@gm...> - 2013-09-30 19:50:57
|
Eric M Ludlam writes: > On 09/26/2013 05:37 PM, Lluís wrote: >> Eric M Ludlam writes: >> >>> The earlier question about different make commands in different sub >>> directories can be handled similarly for anything that would be >>> generally helpful. The purpose of the custom project type is to have a >>> home for that sort of thing because there isn't a more generic type that >>> would work well for Linux sources. >> >> Well, I think the root of my question is whether it is possible to have some >> common project type that allows project auto-detection (like linux or automake), >> but that also supports loading information from the disk (i.e., a Project.ede >> file on the root of the project that contains further customizations set by the >> user). > The reason it isn't like that is mostly historical. I took a couple > runs at this with the old 'simple' project, but that didn't work very > well. The current better sample is the 'generic' project that has a > distinct 'configuration' feature that is saved independently of the > discovered project type (such as Makefile, Scons, etc). > If I recall, it was a little too aggressive in picking up projects, so > it is off by default. I hadn't thought of using that framework as > underpinnings to other base project types such as Linux or Emacs. There > are a lot of similarities in how they work. >> With this base feature, other things can be implemented on top (like >> project-specific compilation commands). This could be implemented by setting >> listed variables as buffer local. In the case of project-specific slot values, >> I'm at a loss. Actually, I was naively expecting the project customization >> buffer to be able to do so. > I think the generic project will have one configuration at the top as > opposed to several. Having more seems useful. >> The next step I see is to have the same with project configurations, so that >> enabling a configuration can override the value of some variables and/or project >> slots. >> >> The truth is that cedet is so big and complex that I don't even know if some of >> these features are already available. > I agree. Project management is a hard problem, and there are too many > different kinds of configurations for any one system/person to handle > all of them well. When people who use the system have insights that we > can get into the core, it makes it a little easier to move things forward. As I see it, the project class hierarchy should add some common base that handles project-specific tuning by: - Overwriting slots (last thing after class initialization) - Defining other variables as buffer-local for every buffer handling files inside the project. Dir-locals achieve exactly that, so I'm not sure if dir-locals should be able to overwrite project slots, or if EDE projects should instead re-implement dir-locals at the project level... BTW, having these on a Project.ede file might not be the best option, since these files are already used by EDE for another purpose. The class hierarchy could be something like: - base (handles aforementioned features) - auto : base (David's project identification using VCS root directory detection) - linux, etc : base (as they are) If this makes sense, I could give the base a try to implement slot/variable overriding, but I'm not sure about the dir-locals thing. 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 |
From: Evgeniy D. <dus...@ma...> - 2013-09-30 23:07:24
Attachments:
extend-ede.el
|
On Mon, Sep 30, 2013 at 09:50:46PM +0200, Lluís wrote: > As I see it, the project class hierarchy should add some common base that > handles project-specific tuning by: > > - Overwriting slots (last thing after class initialization) > - Defining other variables as buffer-local for every buffer handling files > inside the project. Dir-locals achieve exactly that, so I'm not sure if > dir-locals should be able to overwrite project slots, or if EDE projects > should instead re-implement dir-locals at the project level... > > BTW, having these on a Project.ede file might not be the best option, since > these files are already used by EDE for another purpose. > > The class hierarchy could be something like: > > - base (handles aforementioned features) > - auto : base (David's project identification using VCS root directory > detection) > - linux, etc : base (as they are) > > If this makes sense, I could give the base a try to implement slot/variable > overriding, but I'm not sure about the dir-locals thing. > Just my two cents, when I start using cedet, I dig into this list and cedet source code, and get idea to write my-ede-cpp-root-project class (see attachment), and use it to manage my c/c++ projects like this: (my-ede-cpp-root-project "sdcv" :file "~/projects/stardict/sdcv-code/CMakeLists.txt" :include-path '("~/projects/stardict/sdcv-code/src" "~/projects/stardict/sdcv-code/src/lib") :system-include-path '("/usr/include" "/usr/include/glib-2.0" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4" ) :custom_build_cmd "make -k -j9 -C /tmp/build-sdcv" :path_to_exe "/tmp/build-sdcv/sdcv" ) -- /Evgeniy |
From: David E. <de...@ra...> - 2013-09-25 20:38:07
|
David Engster writes: > Lluís writes: >> Hi! I've been trying semantic/bovine/clang.el and found out that it does not >> return any results. > > I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and > it showed some problems with finding system headers. I'll take a look at > it soon. I've updated the clang.el code to work with newer versions. >> The culprit of the problem seems to be in 'semantic-clang-args-from-project', >> which is unable to establish the compilation flags because 'ede-proj-project-p' >> is false for a 'ede-object-root-project' that is an instance of >> 'ede-linux-project'. >> >> The result of this test kind of baffles me, since without knowing about >> semantic, it seems to me like the result of that test should be true. > > Again, I'd suggest to use ede-cpp-root projects. I don't know why the > Linux project behaves this way. It's probably a bug. Turns out the Linux project type uses ede-project as superclass and not ede-proj-project. This also means that it does not have a 'variables' slot from which I could parse includes. -David |
From: Eric M. L. <er...@si...> - 2013-09-26 01:52:43
|
On 09/25/2013 04:37 PM, David Engster wrote: > David Engster writes: >> Lluís writes: >>> Hi! I've been trying semantic/bovine/clang.el and found out that it does not >>> return any results. >> >> I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and >> it showed some problems with finding system headers. I'll take a look at >> it soon. > > I've updated the clang.el code to work with newer versions. > >>> The culprit of the problem seems to be in 'semantic-clang-args-from-project', >>> which is unable to establish the compilation flags because 'ede-proj-project-p' >>> is false for a 'ede-object-root-project' that is an instance of >>> 'ede-linux-project'. >>> >>> The result of this test kind of baffles me, since without knowing about >>> semantic, it seems to me like the result of that test should be true. >> >> Again, I'd suggest to use ede-cpp-root projects. I don't know why the >> Linux project behaves this way. It's probably a bug. > > Turns out the Linux project type uses ede-project as superclass and not > ede-proj-project. This also means that it does not have a 'variables' > slot from which I could parse includes. I don't do linux dev myself so I can't help much on the details, but if there is some common features that would be handy in linux, feel free to add them to the linux project type. I assume the include lists or whatever are relatively constant or derivable. The earlier question about different make commands in different sub directories can be handled similarly for anything that would be generally helpful. The purpose of the custom project type is to have a home for that sort of thing because there isn't a more generic type that would work well for Linux sources. Eric |
From: Lluís <xs...@gm...> - 2013-09-26 13:06:07
Attachments:
ede-linux.patch
|
David Engster writes: > David Engster writes: >> Lluís writes: >>> Hi! I've been trying semantic/bovine/clang.el and found out that it does not >>> return any results. >> >> I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and >> it showed some problems with finding system headers. I'll take a look at >> it soon. > I've updated the clang.el code to work with newer versions. I tried to change it to use the information I added to the linux project (see below), but looks like the "call-process" does not return anything at all (tried putting the results in a buffer and it's always empty). BTW, I did not try your changes. >>> The culprit of the problem seems to be in 'semantic-clang-args-from-project', >>> which is unable to establish the compilation flags because 'ede-proj-project-p' >>> is false for a 'ede-object-root-project' that is an instance of >>> 'ede-linux-project'. >>> >>> The result of this test kind of baffles me, since without knowing about >>> semantic, it seems to me like the result of that test should be true. >> >> Again, I'd suggest to use ede-cpp-root projects. I don't know why the >> Linux project behaves this way. It's probably a bug. > Turns out the Linux project type uses ede-project as superclass and not > ede-proj-project. This also means that it does not have a 'variables' > slot from which I could parse includes. And what's the difference between both? How much would it cost to "update" the linux project definition to use "ede-proj-project"? (if that's what it shoudl use). Who does fill the "variables" slot in? And more importantly, why are these features not common to all project types? What I did for now (see attachment) is establish an "include-path" slot and update the file-finding method accordingly. Most of it is independent of that slot, although the slot itself should be changed to whatever generic mechanism that allows handling all the project types with the same code (if that's possible). Actually it's a little bit more elaborated than adding an "include-path" slot, since it knows about out-of-tree builds and architecture-specific include paths. Note that the patch might not show the most lispy coding style... Lluis |
From: Lluís <xs...@gm...> - 2013-09-26 21:29:40
Attachments:
ede-linux.patch
|
Lluís writes: > David Engster writes: >> David Engster writes: >>> Lluís writes: >>>> Hi! I've been trying semantic/bovine/clang.el and found out that it does not >>>> return any results. >>> >>> I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and >>> it showed some problems with finding system headers. I'll take a look at >>> it soon. >> I've updated the clang.el code to work with newer versions. > I tried to change it to use the information I added to the linux project (see > below), but looks like the "call-process" does not return anything at all (tried > putting the results in a buffer and it's always empty). > BTW, I did not try your changes. Well, now it works. See the updated patch which includes clang support for the linux project (as well as updated linux project suport for ede). Still, I'm not sure if the "ede/linux.el" changes I did are the way to go. Lluis |
From: Eric M. L. <er...@si...> - 2013-09-27 12:21:14
|
On 09/26/2013 05:37 PM, Lluís wrote: > Eric M Ludlam writes: > >> The earlier question about different make commands in different sub >> directories can be handled similarly for anything that would be >> generally helpful. The purpose of the custom project type is to have a >> home for that sort of thing because there isn't a more generic type that >> would work well for Linux sources. > > Well, I think the root of my question is whether it is possible to have some > common project type that allows project auto-detection (like linux or automake), > but that also supports loading information from the disk (i.e., a Project.ede > file on the root of the project that contains further customizations set by the > user). The reason it isn't like that is mostly historical. I took a couple runs at this with the old 'simple' project, but that didn't work very well. The current better sample is the 'generic' project that has a distinct 'configuration' feature that is saved independently of the discovered project type (such as Makefile, Scons, etc). If I recall, it was a little too aggressive in picking up projects, so it is off by default. I hadn't thought of using that framework as underpinnings to other base project types such as Linux or Emacs. There are a lot of similarities in how they work. > With this base feature, other things can be implemented on top (like > project-specific compilation commands). This could be implemented by setting > listed variables as buffer local. In the case of project-specific slot values, > I'm at a loss. Actually, I was naively expecting the project customization > buffer to be able to do so. I think the generic project will have one configuration at the top as opposed to several. Having more seems useful. > The next step I see is to have the same with project configurations, so that > enabling a configuration can override the value of some variables and/or project > slots. > > The truth is that cedet is so big and complex that I don't even know if some of > these features are already available. I agree. Project management is a hard problem, and there are too many different kinds of configurations for any one system/person to handle all of them well. When people who use the system have insights that we can get into the core, it makes it a little easier to move things forward. Eric |
From: Lluís <xs...@gm...> - 2013-09-30 19:39:16
|
Lluís writes: > Lluís writes: >> David Engster writes: >>> David Engster writes: >>>> Lluís writes: >>>>> Hi! I've been trying semantic/bovine/clang.el and found out that it does not >>>>> return any results. >>>> >>>> I'm afraid the code has bit-rotted. I just tested it with clang 3.3, and >>>> it showed some problems with finding system headers. I'll take a look at >>>> it soon. >>> I've updated the clang.el code to work with newer versions. >> I tried to change it to use the information I added to the linux project (see >> below), but looks like the "call-process" does not return anything at all (tried >> putting the results in a buffer and it's always empty). >> BTW, I did not try your changes. > Well, now it works. See the updated patch which includes clang support for the > linux project (as well as updated linux project suport for ede). > Still, I'm not sure if the "ede/linux.el" changes I did are the way to go. It works for me... anyone objects to committing this? Lluis > === modified file 'lisp/cedet/ede/linux.el' > --- lisp/cedet/ede/linux.el 2013-01-31 20:50:32 +0000 > +++ lisp/cedet/ede/linux.el 2013-09-26 20:46:47 +0000 > @@ -34,6 +34,7 @@ > (require 'ede) > (require 'ede/make) > +(require 'cl) > (declare-function semanticdb-file-table-object "semantic/db") > (declare-function semanticdb-needs-refresh-p "semantic/db") > @@ -46,6 +47,19 @@ > :group 'ede > :version "24.3") > +(defcustom project-linux-build-directory 'ask > + "Build directory." > + :group 'project-linux > + :type '(choice (const :tag "Same as source directory" 'same) > + (const :tag "Ask the user" 'ask))) > + > +(defcustom project-linux-architecture-default 'ask > + "Target architecture to assume when not auto-detected." > + :group 'project-linux > + :type '(choice (string :tag "Architecture name") > + (const :tag "Ask the user" 'ask))) > + > + > (defcustom project-linux-compile-target-command (concat ede-make-command " -k -C %s SUBDIRS=%s") > "*Default command used to compile a target." > :group 'project-linux > @@ -109,10 +123,99 @@ > (defclass ede-linux-project (ede-project eieio-instance-tracker) > ((tracking-symbol :initform 'ede-linux-project-list) > - ) > + (build-directory :initarg :build-directory > + :type string > + :documentation "Build directory.") > + (architecture :initarg :architecture > + :type string > + :documentation "Target architecture.") > + (include-path :initarg :include-path > + :type list > + :documentation "Include directories. > +Contains both common and target architecture-specific directories.")) > "Project Type for the Linux source code." > :method-invocation-order :depth-first) > + > +(defun ede-linux--get-build-directory (dir) > + "Detect build directory for sources in DIR. > +If DIR has not been used as a build directory, fall back to > +`project-linux-build-directory'." > + (or > + ;; detected build on source directory > + (and (file-exists-p (expand-file-name ".config" dir)) dir) > + ;; use configuration > + (case project-linux-build-directory > + (same dir) > + (ask (read-directory-name "Select Linux' build directory: " dir))))) > + > + > +(defun ede-linux--get-archs (dir) > + "Returns a list of architecture names found in DIR." > + (let ((archs-dir (expand-file-name "arch" dir)) > + archs) > + (when (file-directory-p archs-dir) > + (setq archs > + (cl-remove-if-not > + (lambda (elem) > + (and > + (not (string= elem ".")) > + (not (string= elem "..")) > + (not (string= elem "x86_64")) ; has no separate sources > + (file-directory-p > + (expand-file-name elem archs-dir)))) > + (directory-files archs-dir)))))) > + > + > +(defun ede-linux--detect-architecture (dir) > + "Try to auto-detect the architecture as configured in DIR. > +DIR is Linux' build directory. If it cannot be auto-detected, > +returns `project-linux-architecture-default'." > + (let ((archs-dir (expand-file-name "arch" dir)) > + (archs (ede-linux--get-archs dir)) > + arch found) > + (or (and archs > + ;; Look for /arch/<arch>/include/generated > + (progn > + (while (and archs (not found)) > + (setq arch (car archs)) > + (when (file-directory-p > + (expand-file-name (concat arch "/include/generated") > + archs-dir)) > + (setq found arch)) > + (setq archs (cdr archs))) > + found)) > + project-linux-architecture-default))) > + > +(defun ede-linux--get-architecture (dir bdir) > + "Try to auto-detect the architecture as configured in BDIR. > +Uses `ede-linux--detect-architecture' for the auto-detection. If > +the result is `ask', let the user choose from architectures found > +in DIR." > + (let ((arch (ede-linux--detect-architecture bdir))) > + (case arch > + (ask > + (completing-read "Select target architecture: " > + (ede-linux--get-archs dir))) > + (t arch)))) > + > + > +(defun ede-linux--include-path (dir bdir arch) > + "Returns a list with include directories. > +Returned directories might not exist, since they are not created > +until Linux is built for the first time." > + (map 'list > + (lambda (elem) (format (concat (car elem) "/" (cdr elem)) arch)) > + ;; XXX: taken from the output of "make V=1" > + (list (cons dir "arch/%s/include") > + (cons bdir "arch/%s/include/generated") > + (cons dir "include") > + (cons bdir "include") > + (cons dir "arch/%s/include/uapi") > + (cons bdir "arch/%s/include/generated/uapi") > + (cons dir "include/uapi") > + (cons bdir "include/generated/uapi")))) > + > ;;;###autoload > (defun ede-linux-load (dir &optional rootproj) > "Return an Linux Project object if there is a match. > @@ -121,13 +224,19 @@ > ROOTPROJ is nil, since there is only one project." > (or (ede-linux-file-existing dir) > ;; Doesn't already exist, so let's make one. > - (let ((proj (ede-linux-project > - "Linux" > - :name "Linux" > - :version (ede-linux-version dir) > - :directory (file-name-as-directory dir) > - :file (expand-file-name "scripts/ver_linux" > - dir)))) > + (let* ((bdir (ede-linux--get-build-directory dir)) > + (arch (ede-linux--get-architecture dir bdir)) > + (include-path (ede-linux--include-path dir bdir arch)) > + (proj (ede-linux-project > + "Linux" > + :name "Linux" > + :version (ede-linux-version dir) > + :directory (file-name-as-directory dir) > + :file (expand-file-name "scripts/ver_linux" > + dir) > + :build-directory bdir > + :architecture arch > + :include-path include-path))) > (ede-add-project-to-global-list proj)) > )) > @@ -247,12 +356,18 @@ > (let* ((ext (file-name-extension name)) > (root (ede-project-root proj)) > (dir (ede-project-root-directory root)) > + (bdir (oref proj build-directory)) > (F (cond > ((not ext) nil) > ((string-match "h" ext) > - (or (ede-linux-file-exists-name name dir "") > - (ede-linux-file-exists-name name dir "include")) > - ) > + (let ((dirs (oref proj include-path)) > + found) > + (while (and dirs (not found)) > + (setq found > + (or (ede-linux-file-exists-name name bdir (car dirs)) > + (ede-linux-file-exists-name name dir (car dirs)))) > + (setq dirs (cdr dirs))) > + found)) > ((string-match "txt" ext) > (ede-linux-file-exists-name name dir "Documentation")) > (t nil))) > === modified file 'lisp/cedet/semantic/bovine/clang.el' > --- lisp/cedet/semantic/bovine/clang.el 2013-09-25 20:33:41 +0000 > +++ lisp/cedet/semantic/bovine/clang.el 2013-09-26 21:24:30 +0000 > @@ -310,6 +310,18 @@ > (concat "=" (cadr spp))))) > (oref proj spp-table)) > (list (concat "-I" (ede-project-root-directory proj))))) > + ;; Similarly for ede-linux-project > + ((ede-linux-project-child-p proj) > + (let* ((root (ede-project-root-directory proj)) > + (dir (file-name-directory (buffer-file-name))) > + (rel-dir (substring dir (length root)))) > + (append > + (list (format "-include%s/include/linux/kconfig.h" root)) > + (mapcar (lambda (inc) (concat "-I" inc)) > + (oref proj include-path)) > + (list (concat "-I" root rel-dir) > + (concat "-I" (oref proj build-directory) rel-dir) > + "-D__KERNEL__")))) > ;; For more general project types it's a bit more difficult. > ((ede-proj-project-p proj) > ;; Get the local and configuration variables. > -- > "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 > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel -- "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 |
From: David E. <de...@ra...> - 2013-09-30 19:57:17
|
Lluís writes: >> Still, I'm not sure if the "ede/linux.el" changes I did are the way to go. > > It works for me... anyone objects to committing this? I'd have no problem with extending the Linux project type like this. The only nitpick is >> +(require 'cl) [...] >> + (cl-remove-if-not which we cannot use since ede/linux.el is merged with Emacs proper, where usage of 'cl at runtime is not allowed (you could use cl-lib, but that's only available since 24.3). -David |
From: Lluís <xs...@gm...> - 2013-10-04 13:36:06
|
David Engster writes: > Lluís writes: >>> Still, I'm not sure if the "ede/linux.el" changes I did are the way to go. >> >> It works for me... anyone objects to committing this? > I'd have no problem with extending the Linux project type like this. > The only nitpick is >>> +(require 'cl) > [...] >>> + (cl-remove-if-not > which we cannot use since ede/linux.el is merged with Emacs proper, > where usage of 'cl at runtime is not allowed (you could use cl-lib, but > that's only available since 24.3). I've just checked in a version of the patch without using cl. Happy hacking! -- "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 |
From: David E. <de...@ra...> - 2013-10-05 11:05:13
|
Lluís writes: > I've just checked in a version of the patch without using cl. Erm, did you maybe forget to push? Cause I'm not seeing anything... -David |
From: Lluís <xs...@gm...> - 2013-10-05 18:37:47
|
Opps! True; thx! :) David Engster writes: > Lluís writes: >> I've just checked in a version of the patch without using cl. > Erm, did you maybe forget to push? Cause I'm not seeing anything... > -David > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel -- "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 |