CEDET

I suspect that the version of eieio that came with your debian system
is old.  COGRE requires the most recent version of eieio, which you
will need to add to your load path, in addition to removing the eieio
debian package.  The same is probably true speedbar and semantic.

Good Luck
Eric

>>> Hans Steinraht <hsteinraht@...> seems to think that:
>hi,
>
>I hope I'm at the right group here, but I have a problem while making COGRE.
>
>When I run make I receive the following error:
>!! error (("Given parent class eieio-persistent is not a class"))
>
>When I start emacs after putting the lines:
>(add-to-list 'load-path "/usr/share/emacs/site-lisp/COGRE-0.2")
>(require 'cogre)
>
>in my .emacs (try running it without byte-compiling it) I receive the same
>error.
>
>Maybe someone can tell me why this is?
>
>The complete listing from running make I have put underneath this email.
>
>thanks,
>Hans
>
>
>[root@... COGRE-0.2]# make
>emacs -batch -l hacks-compile-script -f batch-byte-compile picture-hack.el
>Loading 00debian-vars...
>Loading 35elib-startup (source)...
>Loading 50eieio (source)...
>Loading 50html-helper-mode (source)...
>Loading 50jde (source)...
>Loading 50php-elisp (source)...
>Loading 50psgml-init (source)...
>Loading 50semantic (source)...
>Loading 50speedbar (source)...
>While compiling toplevel forms in file
>/usr/share/emacs/site-lisp/COGRE-0.2/picture-hack.el:
>  ** clear-rectangle called with 3 arguments, but accepts only 2
>Wrote /usr/share/emacs/site-lisp/COGRE-0.2/picture-hack.elc
>Done
>emacs -batch -l COGRE-compile-script -f batch-byte-compile cogre.el
>cogre-uml.el uml-create.el
>Loading 00debian-vars...
>Loading 35elib-startup (source)...
>Loading 50eieio (source)...
>Loading 50html-helper-mode (source)...
>Loading 50jde (source)...
>Loading 50php-elisp (source)...
>Loading 50psgml-init (source)...
>Loading 50semantic (source)...
>Loading 50speedbar (source)...
>While compiling toplevel forms in file
>/usr/share/emacs/site-lisp/COGRE-0.2/cogre.el:
>  !! error (("Given parent class eieio-persistent is not a class"))
>While compiling toplevel forms in file
>/usr/share/emacs/site-lisp/COGRE-0.2/cogre-uml.el:
>  !! error (("Given parent class eieio-persistent is not a class"))
>While compiling toplevel forms in file
>/usr/share/emacs/site-lisp/COGRE-0.2/uml-create.el:
>  !! error (("Given parent class eieio-persistent is not a class"))
>Done
>make: *** [COGRE] Error 1
>[root@... COGRE-0.2]# 
>
>_______________________________________________
>cedet-semantic mailing list
>cedet-semantic@...
>https://lists.sourceforge.net/lists/listinfo/cedet-semantic
>

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ultranet.com/~zappo            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

> I suspect that the version of eieio that came with your debian system
> is old.  COGRE requires the most recent version of eieio, which you
> will need to add to your load path, in addition to removing the eieio
> debian package.  The same is probably true speedbar and semantic.

Which reminds me of the fact that I find dependency checking in most
emacs packages to be less than perfect. This dependency checking
should include version checking (unfortunately, a thing that the
require function doesn't provide). So, in this case, could future
versions of cogre (and/or semantic etc.) check for the eieio-version
maybe?  The current naming scheme (e.g. "0.17beta3") probably doesn't
lend itself to an easy "equal-or-bigger" version comparison very well
though.

The alternative, checking for the existence of specific features gets
overboard rather quick I guess.

What do you think? I realize that a full solution is a lot of
work which might not be worth the effort in this case, and also
could need help from emacs. Also, there is a tradeoff between
the versioning granularity and the required features of packages
in heavy development -- but for (developer) releases, it would
be a Good Thing IMHO.

Cheers,
  Colin

>>> Colin Marquardt <c.marquardt@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> I suspect that the version of eieio that came with your debian system
>> is old.  COGRE requires the most recent version of eieio, which you
>> will need to add to your load path, in addition to removing the eieio
>> debian package.  The same is probably true speedbar and semantic.
>
>Which reminds me of the fact that I find dependency checking in most
>emacs packages to be less than perfect. This dependency checking
>should include version checking (unfortunately, a thing that the
>require function doesn't provide). So, in this case, could future
>versions of cogre (and/or semantic etc.) check for the eieio-version
>maybe?  The current naming scheme (e.g. "0.17beta3") probably doesn't
>lend itself to an easy "equal-or-bigger" version comparison very well
>though.
>
>The alternative, checking for the existence of specific features gets
>overboard rather quick I guess.
>
>What do you think? I realize that a full solution is a lot of
>work which might not be worth the effort in this case, and also
>could need help from emacs. Also, there is a tradeoff between
>the versioning granularity and the required features of packages
>in heavy development -- but for (developer) releases, it would
>be a Good Thing IMHO.
  [ ... ]

That is a good idea that had come up recently.  I am hoping to do
this in the future.

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ultranet.com/~zappo            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

> That is a good idea that had come up recently.  I am hoping to do
> this in the future.

The simple thing would be to just provide more features:

(provide 'eieio)
(provide 'eieio-2.0)
(provide 'eieio-2.1)
(provide 'eieio-2.2)
(provide 'eieio-2.3)

And then other code could test this:

(require 'eieio-2.2)

Alex
-- 
http://www.emacswiki.org/

>>> Alex Schroeder <alex@...> seems to think that:
>"Eric M. Ludlam" <eric@...> writes:
>
>> That is a good idea that had come up recently.  I am hoping to do
>> this in the future.
>
>The simple thing would be to just provide more features:
>
>(provide 'eieio)
>(provide 'eieio-2.0)
>(provide 'eieio-2.1)
>(provide 'eieio-2.2)
>(provide 'eieio-2.3)
>
>And then other code could test this:
>
>(require 'eieio-2.2)

I think that might be:

(require 'eieio-2.2 "eieio")

but I get the idea.  I can just see a list of about 100 releases 10
years from now. ;)

Eric

-- 
          Eric Ludlam:                 zappo@..., eric@...
   Home: http://www.ultranet.com/~zappo            Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net               GNU: http://www.gnu.org

"Eric M. Ludlam" <eric@...> writes:

> but I get the idea.  I can just see a list of about 100 releases 10
> years from now. ;)

Hehe, so what.  A hundred new symbols are peanuts.

Alex.
-- 
http://www.emacswiki.org/

"Eric M. Ludlam" <eric@...> writes:

>>>> Alex Schroeder <alex@...> seems to think that:
>>"Eric M. Ludlam" <eric@...> writes:
>>
>>> That is a good idea that had come up recently.  I am hoping to do
>>> this in the future.
>>
>>The simple thing would be to just provide more features:
>>
>>(provide 'eieio)
>>(provide 'eieio-2.0)
>>(provide 'eieio-2.1)
>>(provide 'eieio-2.2)
>>(provide 'eieio-2.3)
>>
>>And then other code could test this:
>>
>>(require 'eieio-2.2)
>
> I think that might be:
>
> (require 'eieio-2.2 "eieio")
>
> but I get the idea.  I can just see a list of about 100 releases 10
> years from now. ;)

IMO, this is requiring too much manual effort, and would not fit too well
for code changes between release cycles (since you might be hesitant to
make a new version). One approach I can imagine would be to put the RCS
Id into a variable and do a substring match on it. That would only make
it one file to change by hand, and allows a nice, custom error message.

Cheers,
  Colin

Colin Marquardt <c.marquardt@...> writes:

> IMO, this is requiring too much manual effort, and would not fit too well
> for code changes between release cycles (since you might be hesitant to
> make a new version). One approach I can imagine would be to put the RCS
> Id into a variable and do a substring match on it. That would only make
> it one file to change by hand, and allows a nice, custom error message.

But then you have to do version string parsing, which is error prone,
and when files get integrated into Emacs, these Ids will go away,
breaking all the existing code.

Alex.
-- 
http://www.emacswiki.org/

Alex Schroeder <alex@...> writes:

> Colin Marquardt <c.marquardt@...> writes:
>
>> IMO, this is requiring too much manual effort, and would not fit too well
>> for code changes between release cycles (since you might be hesitant to
>> make a new version). One approach I can imagine would be to put the RCS
>> Id into a variable and do a substring match on it. That would only make
>> it one file to change by hand, and allows a nice, custom error message.
>
> But then you have to do version string parsing, which is error prone,

Well, the format of version numbers from RCS Ids (there was even a
placeholder for just version numbers, no?) is sufficiently well
documented as to be not a problem I guess, but...

> and when files get integrated into Emacs, these Ids will go away,
> breaking all the existing code.

...this I hadn't thought of. Hmm. If there was an ideal solution to
that problem, it would have been invented and adopted long ago, so
who am I to think I could do it right away... :)

Cheers,
  Colin