Re: [CEDET-devel] Problems with EDE and Emacs 23.1 on Windows
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2010-02-13 21:16:30
|
Hi Paul, Thanks for investigating this issue so closely. Soon after releasing 1.0pre6, it was discovered that on Windows, the use of inode numbers as a means for hashing directories was flawed in that the values weren't useful. As such, the variable ede--disable-inode was added (In CVS) to disable this feature on Windows. This feature exists in the CEDET that is currently integrated into the latest Emacs pre-release. Hopefully, it will be a simple matter of you upgrading to the CVS version and using this variable to fix your issues. Eric On 02/12/2010 01:44 PM, Paul Bibbings wrote: > As I gratefully discovered yesterday, CEDET appears to be just the tool > that I have been looking for, and I have been spending a good while > getting it set up and trying to iron out a few problems. This is to > describe one such problem, and to give a workaround that has resolved it > so that I can at least use the product, whereas I was completely stimied > before. > > Having integrated the full CEDET suite into Emacs 23.1 (on Windows > Vista) I found that I could not actually use EDE to manage projects, and > I was getting all kinds of related errors that kept popping up during > background parsing. To illustrate, whenever I configured a project and > tried to call an action such as building from the menu, I would get > some such error as: > > ede-parent-project: > Wrong type argument: number-or-marker-p, (1536 7 . 26020) > > At present I'm not that familiar with lisp (I program in C++), nor with > Emacs for that matter. However, I managed to chase down the problem > through extensive debugging to the method > ede-directory-get-toplevel-open-project at ede-files.el:178. (I have > what I believe is the most recent release of CEDET, cedet-1.0pre6). > Here's the code: > > (defun ede-directory-get-toplevel-open-project (dir) > "Return an already open toplevel project that is managing DIR." > (let ((ft (file-name-as-directory (expand-file-name dir))) > (all ede-projects) > (ans nil)) > (while (and all (not ans)) > ;; Do the check. > (let ((pd (oref (car all) :directory)) > ) > (cond > ;; Exact text match. > ((string= pd ft) > (setq ans (car all))) > ;; Some sub-directory > ((string-match (concat "^" (regexp-quote pd)) ft) > (setq ans (car all))) > ;; Exact inode match. Useful with symlinks or complex automounters. > ((let ((pin (ede--project-inode (car all))) > (inode (ede--inode-for-dir dir))) > (and (/= pin 0) (equal pin inode))) > (setq ans (car all))) > ;; Subdir via truename - slower by far, but faster than a > ;; traditional lookup. > > ((let ((ftn (file-truename ft)) > (ptd (file-truename (oref (car all) :directory)))) > (string-match (concat "^" (regexp-quote ptd)) ftn)) > (setq ans (car all))) > )) > (setq all (cdr all))) > ans)) > > and here's what I was getting, stepping through in Edebug: > > 180: dir => "d:/CPPProjects/" > ft => "d:/CPPProjects/" > 181: all => (#<ede-proj-project EDE_test>) > 182: ans => nil > 185: pd = (oref (car all) :directory) = "d:/CPPProjects/EDE_test/" > 189: (string= pd tf) => nil > 192: (regexp-quote pd) => "d:/CPPProjects/EDE_test/" > (string-match (concat "^" (regexp-quote pd)) ft) => nil > 195: pin = (ede--project-inode (car all)) => (1536 7 . 26020) > 196: inode = ((ede--inode-for-dir dir) = (1280 3 .23880) > 197: (/= pin 0) BLOWUP! > Wrong type argument: number-or-marker-p, (1536 7 . 26020) > > As I say, I don't know lisp that well, but the problem is clearly at > ede-files.el:197 and the evaluation of (/= pin 0). Now, my sense of > this and the surrounding code led me to feel confident that I could > comment out the immediate context without fundamentaly breaking > anything, so I did just that, with: > > 193 ;; Exact inode match. Useful with symlinks or complex automounters. > ;; ((let ((pin (ede--project-inode (car all))) > ;; (inode (ede--inode-for-dir dir))) > ;; (and (/= pin 0) (equal pin inode))) > ;; (setq ans (car all))) > > and this did indeed appear to solve my immediate problems completely. > > So, can anyone perhaps suggest just why this bit of code was causing all > manner of problems (the one described being just one of many, all of > which were removed with this one modification)? Also, is my suspicion > correct that having removed these lines on my current setup (which, of > course, does not use symlinks) leaves the system viable, at least in the > context of a temporary workaround? > > TIA, and thanks for an impressive collection of tools! > > Regards > > Paul Bibbings > > ------------------------------------------------------------------------------ > SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, > Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW > http://p.sf.net/sfu/solaris-dev2dev > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |