cedet-eieio Mailing List for CEDET
Brought to you by:
zappo
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
(4) |
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(4) |
Dec
(14) |
2003 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
(5) |
May
(3) |
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2006 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(12) |
Jul
(4) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
|
Feb
(6) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(7) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
(10) |
Jul
(11) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(5) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
(23) |
Mar
(2) |
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(2) |
Nov
|
Dec
|
From: Sylvain S. <syl...@ya...> - 2016-10-20 06:27:14
|
I found my mistake. As a new elisp programmer I still get confused with quotation... Best, Sylvain. Sylvain Salvati writes: > Dear list, > > I ma trying to use eieio to write code in elisp. But I am stuck with a > problem related to polymorphism. Here is a simple example showing my > problem > > (defclass a() > ((a :initarg :a > :initform 0)) > "class a") > > (defclass b() > ((b :initarg :b > :initform 0)) > "class b") > > (defmethod nb ((xa a)) > (oref xa :a)) > > (defmethod nb ((xb b)) > (oref xb :b)) > > (setq xa (a)) > > (setq xb (b)) > > (nb xa) ;;yields 0 as expected > > (nb xb) ;;also yields 0 > > (mapcar 'nb '(xa xb)) ;; yields cl-no-applicable-method (nb xa) > > I create two classes a and b and they both have a method nb. When I have > a list made of objects that can be either a's or b's I would expect to > be able to map the method nb on the list, but this fails. Is there a > workaround this problem. > > Thanks, > > Sylvain. |
From: Sylvain S. <syl...@ya...> - 2016-10-19 17:14:08
|
Dear list, I ma trying to use eieio to write code in elisp. But I am stuck with a problem related to polymorphism. Here is a simple example showing my problem (defclass a() ((a :initarg :a :initform 0)) "class a") (defclass b() ((b :initarg :b :initform 0)) "class b") (defmethod nb ((xa a)) (oref xa :a)) (defmethod nb ((xb b)) (oref xb :b)) (setq xa (a)) (setq xb (b)) (nb xa) ;;yields 0 as expected (nb xb) ;;also yields 0 (mapcar 'nb '(xa xb)) ;; yields cl-no-applicable-method (nb xa) I create two classes a and b and they both have a method nb. When I have a list made of objects that can be either a's or b's I would expect to be able to map the method nb on the list, but this fails. Is there a workaround this problem. Thanks, Sylvain. |
From: Przemysław W. <esp...@cu...> - 2014-11-29 21:47:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 29.11.2014 o 14:16, Eric Ludlam pisze: > On 11/29/2014 05:26 AM, Przemysław Wojnowski wrote: [...] >> 3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)? EIEIO is on >> language level and Speedbar on GUI level, so both are in completely >> different worlds - it's like having dependency from JDK to Eclipse. This >> dependency makes all programs that use EIEIO (OO system) to depend on >> Speedbar, which they may not need. If a class wants to have Speedbar >> support then Speedbar should provide helper classes, not EIEIO. > > Are you thinking of a build/load dependency from eieio-opt.el? Everything > in eieio-opt is optional. It is fine to use eieio without it, or > eieio-speedbar. > > The two sets of speedbar support are different though. The stuff in > eieio-opt is for displaying all classes current loaded into Emacs. The > eieio-speedbar stuff is for creating your own classes that have a tree > hierarchy of their own, and their own mode. For example, in EDE you can > browse all the project trees. I just meant that OO layer (EIEIO) and visual tool operating on it (Speedbar) are separate concerns. OO layer, being just above basic language primitives, provides abstractions for constructing programs in OO way - for example a tool for graphical browsing/editing structures of programs built using such OO layer. So, OO layer should has no dependencies (even conceptual) to programs built on top of it. Actually, Speedbar already contains couple of modes (plugins?) for other parts of Emacs (files, buffers, info, etc.), so why sp-eieio.el is not there too? I'm not a maintainer of EIEIO, but only learning it and just wanted to understand some of the decisions. If you disagree, just ignore my emails. :-) Thanks! Przemyslaw > > That said, if someone wants to pull the speedbar class browser into it's > own utility fcn, that would be fine with me. > > Eric -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUej7iAAoJEC3CE3LuBFUoNKEP/jzH1Nd3xh8oVFJrgNkLbbwy u/pcrUJlugfY5CIb8EZjubMxc/OPjJqywAPL/U89xB6t+8exFPe0pGumcXo3Mh0j wq/on5Fu/pRTZuMGMjx5K/Y9u/j/kDhsZOgC4//YE6T9gAP9SqYq2EPtra6N3lW9 mRSNZaRAl/o3Nmmt+L64BHMJvJqCSv2I6pMqMH6qT4xouG+ZeBuowqejVR6/V462 6Sxh8o9ERhd+vGdSFCTsgDe2ZICERwPWn5s4LKxHnKKiHmsIwcP43AUpM+ASFjvW ptVwzCtuP+utJW4iu/zPZ+ZBOwdSULNLnASymr4wuSDLWgHh6MmANovArivo3m5L L0Q/vSnqrZ0QowWyVMDQfomCYu+oiK8V3z7RjN5z6virv7JSN8j6scRb5d+0p7VV kD07DbBDN65gL4Ds6Vp21xxFLqoJPCJUPp7DskwM01YI9qDxI6PHkgiuGrMAe0l6 Qkt2q7Mha2HlxTocFxOmiOkIFnu4VSjapf2YeDdfaeuBFf7bE0X/GhqmLqMu3pef gehnZGkWfXpG8Pj+BFo72mpmyQbT9Zeyz9l5OWD23Fx3L3/7DQJ6cC+kILhuLdy4 pshCbQ7LfVCiJcaeSmsLK8KWtiZUpFHHAdXz0o4ivkr+fq3/5ORiDkNehZ1d4Dxm mjftvbacebyQIZ1NVZiR =n4M8 -----END PGP SIGNATURE----- |
From: Eric L. <er...@si...> - 2014-11-29 13:16:38
|
On 11/29/2014 05:26 AM, Przemysław Wojnowski wrote: > Hello everybody, > > While learning EIEIO I've encountered the following issues: > 1. 'describe-class' docs says: > "(describe-class CLASS &optional HEADERFCN) > > Describe a CLASS defined by a string or symbol. > If CLASS is actually an object, then also display current values of that object." > > So, the second sentence says that the argument can be an object, and then the > function will display values of that object, right? But the following gives error: [...] > ELISP> (let ((p (point "a point" :x 1 :y 2))) > (describe-class p)) > *** Eval error *** Wrong type argument: symbolp, [object point "a point" 1 2] > > Am I missing something? Hi Przemyslaw I think this is a bug in the doc. I suspect the doc was the intent but the code changed over time and the doc wasn't updated. There isn't a handy way to display an object other than the data-debug tool which is completely separate. I'll submit a fix to my local copy, though I think the maintenance is moving off to Emacs core RSN if not already so I'm not sure yet if it will be propagated. > 2. Why constructor functions have instance name as required parameter? > According to the info doc it's for debugging purposes: > "Each instance is given a name, so different instances can be easily > distinguished when debugging." > But it's such a rare case and providing a name for every object makes > constructors just impractical. When someone needs to name things for debugging > purposes he/she can easily add a slot for such purpose. Having the name was important to me while I was working on my projects, such as eieio, and other parts of CEDET. I agree is is a bit annoying when just assembling a few simple classes for a test or what-not. I would not be opposed to having the string/name be optional in the future. > 3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)? > EIEIO is on language level and Speedbar on GUI level, so both are in completely > different worlds - it's like having dependency from JDK to Eclipse. This > dependency makes all programs that use EIEIO (OO system) to depend on Speedbar, > which they may not need. > If a class wants to have Speedbar support then Speedbar should provide helper > classes, not EIEIO. Are you thinking of a build/load dependency from eieio-opt.el? Everything in eieio-opt is optional. It is fine to use eieio without it, or eieio-speedbar. The two sets of speedbar support are different though. The stuff in eieio-opt is for displaying all classes current loaded into Emacs. The eieio-speedbar stuff is for creating your own classes that have a tree hierarchy of their own, and their own mode. For example, in EDE you can browse all the project trees. That said, if someone wants to pull the speedbar class browser into it's own utility fcn, that would be fine with me. Eric |
From: Przemysław W. <esp...@cu...> - 2014-11-29 10:53:08
|
Hello everybody, While learning EIEIO I've encountered the following issues: 1. 'describe-class' docs says: "(describe-class CLASS &optional HEADERFCN) Describe a CLASS defined by a string or symbol. If CLASS is actually an object, then also display current values of that object." So, the second sentence says that the argument can be an object, and then the function will display values of that object, right? But the following gives error: ELISP> (defclass point () ((x :initarg :x :type number) (y :initarg :y :type number))) point ELISP> (let ((p (point "a point" :x 1 :y 2))) (describe-class p)) *** Eval error *** Wrong type argument: symbolp, [object point "a point" 1 2] Am I missing something? 2. Why constructor functions have instance name as required parameter? According to the info doc it's for debugging purposes: "Each instance is given a name, so different instances can be easily distinguished when debugging." But it's such a rare case and providing a name for every object makes constructors just impractical. When someone needs to name things for debugging purposes he/she can easily add a slot for such purpose. 3. Why EIEIO has dependency on Speedbar (eieio-speedbar.el)? EIEIO is on language level and Speedbar on GUI level, so both are in completely different worlds - it's like having dependency from JDK to Eclipse. This dependency makes all programs that use EIEIO (OO system) to depend on Speedbar, which they may not need. If a class wants to have Speedbar support then Speedbar should provide helper classes, not EIEIO. Hope you don't get it wrong (as an attack), but as constructive critique. After all, EIEIO is great piece of software. Cheers, Przemyslaw |
From: Jorge A. N. <elc...@de...> - 2014-01-24 23:39:23
|
El vie, 24-01-2014 a las 21:00 +0100, David Engster escribió: > Jorge Araya Navarro writes: > > I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I > > try to start Emacs, I run into this error: > > > > Debugger entered--Lisp error: (void-function eieio-object-name-string) > > [...] > > > This happens with both bazar snapshot and the latest snapshot 8634 on http:// > > www.randomsample.de/cedet-snapshots/. > > Maybe this error is happening because eieio-object-name-string is still named > > object-name-string until Emacs 24.4? > > The CEDET development version also ships with an up-to-date EIEIO, which > should override the one in Emacs. > > What happens when you do > > emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el > > Does that work? > > -David > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > cedet-eieio mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-eieio I manage to make it works, now I have no errors!! My issue was happening because of this line of code on my .emacs.d/init.el file: ;; programas elisp que no estan en elpa (let ((default-directory "~/.emacs.d/otros/")) (normal-top-level-add-subdirs-to-load-path)) my cedet snapshot was sitting on ~/.emacs.d/otros/, but I don't fully know the correlation between my lines of elisp and this issue. This happens because you don't know what are you doing, do not follow my example and study elisp, kids :) Thanks for the support!! :) -- Pax et bonum. Jorge Araya Navarro. Diseñador publicitario, programador Python/C++ y colaborador en Parabola GNU/Linux-libre. |
From: Jorge A. N. <elc...@de...> - 2014-01-24 23:25:52
|
El vie, 24-01-2014 a las 21:00 +0100, David Engster escribió: > Jorge Araya Navarro writes: > > I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I > > try to start Emacs, I run into this error: > > > > Debugger entered--Lisp error: (void-function eieio-object-name-string) > > [...] > > > This happens with both bazar snapshot and the latest snapshot 8634 on http:// > > www.randomsample.de/cedet-snapshots/. > > Maybe this error is happening because eieio-object-name-string is still named > > object-name-string until Emacs 24.4? > > The CEDET development version also ships with an up-to-date EIEIO, which > should override the one in Emacs. > > What happens when you do > > emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el > > Does that work? > > -David > > > ------------------------------------------------------------------------------ > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > _______________________________________________ > cedet-eieio mailing list > ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-eieio Oh my God!, yes that works, this is what I get from the *Message* buffer: For information about GNU Emacs and the GNU system, type C-h C-a. Loading /home/jorge/.emacs.d/otros/cedet/cedet-remove-builtin.el (source)...done Loading autoloads from CEDET development. Parsing *srecode-map-tmp* (LALR)...done Just for the record, this is what I get if I try to run Emacs as I always do: Loading /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el (source)... Loading /home/jorge/.emacs.d/otros/cedet/cedet-remove-builtin.el (source)...done Package assoc is obsolete! For information about GNU Emacs and the GNU system, type C-h C-a. What should I do now? load "cedet/cedet-remove-builtin.el" before "cedet/cedet-devel-load.el" (maybe it makes no sense, but I have to try something, right?) -- Pax et bonum. Jorge Araya Navarro. Diseñador publicitario, programador Python/C++ y colaborador en Parabola GNU/Linux-libre. |
From: David E. <de...@ra...> - 2014-01-24 20:05:13
|
Jorge Araya Navarro writes: > I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I > try to start Emacs, I run into this error: > > Debugger entered--Lisp error: (void-function eieio-object-name-string) [...] > This happens with both bazar snapshot and the latest snapshot 8634 on http:// > www.randomsample.de/cedet-snapshots/. > Maybe this error is happening because eieio-object-name-string is still named > object-name-string until Emacs 24.4? The CEDET development version also ships with an up-to-date EIEIO, which should override the one in Emacs. What happens when you do emacs -Q -l /home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el Does that work? -David |
From: Jorge A. N. <elc...@de...> - 2014-01-24 08:23:27
|
Hello! I'm trying to use the lastes version of CEDET on GNU Emacs 24.3.1, but when I try to start Emacs, I run into this error: Debugger entered--Lisp error: (void-function eieio-object-name-string) eieio-object-name-string([object ede-project-autoload "android" "ANDROID ROOT" ede/android "AndroidManifest.xml" "" unbound nil ede-android-load ede-android-project nil t t]) ede-add-project-autoload([object ede-project-autoload "android" "ANDROID ROOT" ede/android "AndroidManifest.xml" "" unbound nil ede-android-load ede-android-project nil t t]) eval-buffer(#<buffer *load*-529733> nil "/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" nil t) ; Reading at buffer position 704 load-with-code-conversion("/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" "/home/jorge/.emacs.d/otros/cedet/lisp/cedet/ede/loaddefs.el" nil t) load("ede/loaddefs" nil nomessage) byte-code("\300\301!\210\300\302!\210\300\303!\210\300\304!\210\300\305!\210\300\306!\210\307\310\311\312#\207" [require cedet eieio eieio-speedbar ede/source ede/base ede/auto load "ede/loaddefs" nil nomessage] 4) require(ede) (let ((CEDETDIR (file-name-directory (or load-file-name (buffer-file-name))))) (if (boundp (quote cedet-bootstrap-in-progress)) nil (load-file (expand-file-name "cedet-remove-builtin.el" CEDETDIR))) (add-to-list (quote load-path) CEDETDIR) (add-to-list (quote load-path) (expand-file-name "lisp/cedet" CEDETDIR)) (add-to-list (quote load-path) (expand-file-name "lisp/eieio" CEDETDIR)) (add-to-list (quote load-path) (expand-file-name "lisp/speedbar" CEDETDIR)) (require (quote eieio)) (require (quote ede)) (if (boundp (quote cedet-bootstrap-in-progress)) nil (message "Loading autoloads from CEDET development.") (load (expand-file-name "lisp/eieio/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/speedbar/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/loaddefs.el" CEDETDIR) nil t t) (load (expand-file-name "lisp/cedet/ede/loaddefs.el" CEDETDIR) nil t t) (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))) (require (quote cedet-compat))) eval-buffer(#<buffer *load*-93862> nil "/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil t) ; Reading at buffer position 2893 load-with-code-conversion("/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" "/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil nil) load("/home/jorge/.emacs.d/otros/cedet/cedet-devel-load.el" nil nil t) load-file("~/.emacs.d/otros/cedet/cedet-devel-load.el") eval-buffer(#<buffer *load*> nil "/home/jorge/.emacs.d/init.el" nil t) ; Reading at buffer position 218 load-with-code-conversion("/home/jorge/.emacs.d/init.el" "/home/jorge/.emacs.d/init.el" t t) load("/home/jorge/.emacs.d/init" t t) #[0 "\205\262 [...] [init-file-user system-type delayed-warnings-list user-init-file inhibit-default-init inhibit-startup-screen ms-dos "~" "/_emacs" windows-nt "/.emacs" directory-files nil "^\\.emacs\\(\\.elc?\\)?$" "~/.emacs" "^_emacs\\(\\.elc?\\)?$" (initialization "`_emacs' init file is deprecated, please use `.emacs'") "~/_emacs" t load expand-file-name "init" file-name-as-directory "/.emacs.d" file-name-extension "elc" file-name-sans-extension ".el" file-exists-p file-newer-than-file-p message "Warning: %s is newer than %s" sit-for 1 "default"] 7 "\n\n(fn)"]() This happens with both bazar snapshot and the latest snapshot 8634 on http://www.randomsample.de/cedet-snapshots/. Maybe this error is happening because eieio-object-name-string is still named object-name-string until Emacs 24.4? Well, I have no clue, so I hope for some help here! :) -- Pax et bonum. Jorge Araya Navarro. Diseñador publicitario, programador Python/C++ y colaborador en Parabola GNU/Linux-libre. |
From: Sergey P. <qwe...@ya...> - 2013-05-24 06:23:03
|
On Fri, 24 May 2013 05:46:40 +0500, Eric M. Ludlam <er...@si...> wrote: > On 05/21/2013 06:30 AM, Sergey wrote: >> On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam wrote: >> >>> On 04/14/2013 11:41 AM, Sergey Petrov wrote: >>>> Hello, I receive following warning during any (e.g. from quick start >>>> section in manual) method evaluation: >>>> Warning: Unused lexical variable `scoped-class' >>>> Does eieio works with lexical binding correctly? >>> >>> Hi Sergey, >>> >>> Sorry for the slow response. >>> >>> The scoped-class feature in EIEIO would indeed break lexical binding. >>> I'm not that familiar with lexical binding, or how to 'fix' EIEIO to >>> work with it. >>> >>> I'm open to suggestions to how to fix it from the list. >>> >>> Eric >> >> >> Thank you. I just wanted a peaceful co-existence for my lexical closures >> with eieio classes and methods in the same .el file. >> Probably, the following patch will solve this 'problem'. >> >> *** eieio.el 2013-05-21 11:20:04.133759895 +0500 >> *** 1235,1241 **** > > Hi Sergey, > > Based on this line number, I think you have an old version of eieio. To > aid with byte-compilation in Emacs, eieio.el was split into both > eieio.el, and eieio-core.el in the CEDET bzr repository. > > You will also find in that same fcn I recently updated it to fix the > scoped-class problem so it shouldn't have lexical binding issues anymore. > > Perhaps you can try out the latest from CEDET/bzr, and it will fix your > issue? > > Eric Yes, in bzr version it is ok. Thank you Eric, and sorry for troubling you. |
From: Eric M. L. <er...@si...> - 2013-05-24 00:46:50
|
On 05/21/2013 06:30 AM, Sergey wrote: > On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam wrote: > >> On 04/14/2013 11:41 AM, Sergey Petrov wrote: >>> Hello, I receive following warning during any (e.g. from quick start >>> section in manual) method evaluation: >>> Warning: Unused lexical variable `scoped-class' >>> Does eieio works with lexical binding correctly? >> >> Hi Sergey, >> >> Sorry for the slow response. >> >> The scoped-class feature in EIEIO would indeed break lexical binding. >> I'm not that familiar with lexical binding, or how to 'fix' EIEIO to >> work with it. >> >> I'm open to suggestions to how to fix it from the list. >> >> Eric > > > Thank you. I just wanted a peaceful co-existence for my lexical closures > with eieio classes and methods in the same .el file. > Probably, the following patch will solve this 'problem'. > > *** eieio.el 2013-05-21 11:20:04.133759895 +0500 > *** 1235,1241 **** Hi Sergey, Based on this line number, I think you have an old version of eieio. To aid with byte-compilation in Emacs, eieio.el was split into both eieio.el, and eieio-core.el in the CEDET bzr repository. You will also find in that same fcn I recently updated it to fix the scoped-class problem so it shouldn't have lexical binding issues anymore. Perhaps you can try out the latest from CEDET/bzr, and it will fix your issue? Eric |
From: Sergey <qwe...@ya...> - 2013-05-21 10:30:57
|
On Tue, 07 May 2013 05:27:56 +0500, Eric M. Ludlam wrote: > On 04/14/2013 11:41 AM, Sergey Petrov wrote: >> Hello, I receive following warning during any (e.g. from quick start >> section in manual) method evaluation: >> Warning: Unused lexical variable `scoped-class' >> Does eieio works with lexical binding correctly? > > Hi Sergey, > > Sorry for the slow response. > > The scoped-class feature in EIEIO would indeed break lexical binding. > I'm not that familiar with lexical binding, or how to 'fix' EIEIO to > work with it. > > I'm open to suggestions to how to fix it from the list. > > Eric Thank you. I just wanted a peaceful co-existence for my lexical closures with eieio classes and methods in the same .el file. Probably, the following patch will solve this 'problem'. *** eieio.el 2013-05-21 11:20:04.133759895 +0500 *** 1235,1241 **** ;; is faster to execute this for not byte-compiled. ie, install this, ;; then measure calls going through here. I wonder why. (require 'bytecomp) ! (let ((byte-compile-warnings nil)) (byte-compile `(lambda (&rest local-args) ,doc-string --- 1235,1242 ---- ;; is faster to execute this for not byte-compiled. ie, install this, ;; then measure calls going through here. I wonder why. (require 'bytecomp) ! (let ((byte-compile-warnings nil) ! (lexical-binding nil)) (byte-compile `(lambda (&rest local-args) ,doc-string |
From: Eric M. L. <er...@si...> - 2013-05-07 00:28:05
|
On 04/14/2013 11:41 AM, Sergey Petrov wrote: > Hello, I receive following warning during any (e.g. from quick start > section in manual) method evaluation: > Warning: Unused lexical variable `scoped-class' > Does eieio works with lexical binding correctly? Hi Sergey, Sorry for the slow response. The scoped-class feature in EIEIO would indeed break lexical binding. I'm not that familiar with lexical binding, or how to 'fix' EIEIO to work with it. I'm open to suggestions to how to fix it from the list. Eric |
From: Sergey P. <qwe...@ya...> - 2013-04-14 15:41:46
|
Hello, I receive following warning during any (e.g. from quick start section in manual) method evaluation: Warning: Unused lexical variable `scoped-class' Does eieio works with lexical binding correctly? |
From: Stefan M. <mo...@ir...> - 2013-03-29 21:41:06
|
> Could please eieio-oref/eieio-oset be avoided? oref/oset are so often > used that people will start aliasing them anyways. CLOS seems to live just fine with `slot-value', so why not just use `cl-slot-value'? [ BTW, since setf is now part of core Elisp, we don't need oset. ] > How about replacing eieio-, the most awkward prefix in existence, with Actually, I find it easy to type, because of the "ei" repetition and because the "o" is right next to the "i". Stefan |
From: Vitalie S. <spi...@gm...> - 2013-03-29 10:20:59
|
>> Stefan Monnier <mo...@ir...> >> on Thu, 14 Feb 2013 17:16:21 -0500 wrote: >>> Actually, there's a misunderstanding here: >>> - setf was indeed part of CL, but being a macro it was accepted >>> (i.e. you don't need to have it defined at run-time, since it's >>> macro-expanded during compilation). >>> - setf is part of core Elisp in Emacs-24.3. >>> So maybe we don't need oref/oset at all. >> Yes, although I like "(oset foo bar 'baz)" much better than the verbose >> (setf (cl-slot-value foo 'bar) 'baz) >> But I can understand that you want to get rid of it, and package writers >> can still define their own macros/accessors. > I actually don't particular care if we keep them or not, except that if > we keep them, we need to give them a prefix. Could please eieio-oref/eieio-oset be avoided? oref/oset are so often used that people will start aliasing them anyways. How about replacing eieio-, the most awkward prefix in existence, with simple "eo-", standing for Emacs Objects? Then eoref/eoset can be used as (almost) namespace clean alternatives. Vitalie |
From: Eric M. L. <er...@si...> - 2013-02-20 23:41:44
|
On 02/19/2013 02:49 PM, David Engster wrote: > Stefan Monnier writes: >> For the CL package we solved this problem by leaving the "cl.el" package >> as a "compatibility package" only required by the packages that haven't >> been updated to use the new names. CL was so widely used that it will >> take a *long* time to get rid of all uses of the old names, whereas >> EIEIO's use is not as pervasive, so we don't necessarily have to do the >> same for it. >> This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el" >> (with clean names, autoloaded from cl-lib) and then make eieio.el >> into a simple compatibility package full of aliases. > > What to do with the other files like eieio-base then? We cannot rename > it to cl-eieio-base.el because of name clashes, but it also provides > part of the public, CLOS-like functions. There is nothing in eieio-base from CLOS. Those are all just handy base-classes / concepts that I used elsewhere in CEDET. > To summarize the options so far: > > 1) Prefix everything with eieio- and be done with it. Create obsolete > aliases for the old names and get rid of them "soon" (Emacs > 25?). Alternatively, create an eieio-compat package with aliases for > the old names. > > 2) Prefix everything with eieio- and create cl- aliases for the > CLOS-like functionality. Those aliases may be defined in > > 2a) the eieio* files itself, or > 2b) in a separate cl-whatever.el file. > > As in 1), define obsolete aliases for the old names or use a compat > package. > > 3) Rename eieio to cl-eieio with clean names (i.e., eieio- and > cl-prefixes), autoloaded from cl-lib, and make eieio.el a simple > compatibility package full of aliases. > > I'm currently pretty much tied on "2b)+compat package" and 3). I am fine with most of these ideas, but agree with David that option 3 is pretty good. Eric |
From: Stefan M. <monnier@IRO.UMontreal.CA> - 2013-02-19 21:55:34
|
>> Only if we can hope to get rid of those aliases soon, because we'd >> rather not have those compatibility aliases use up the namespace even >> when all the packages in use have been updated to use the "clean" names. > Well, you've started aliasing `class-name' in your patch, so I thought > that was the plan. Either these aliases will stay as they are until they're removed, or we can move them to a separate package. I saw no need to make such a choice at this point. Stefan |
From: David E. <de...@ra...> - 2013-02-19 19:49:17
|
Stefan Monnier writes: >> I meant a compat package in CEDET upstream, so that it can run on older >> Emacsen if we stop shipping our own EIEIO version. As long as we're >> obsolete-aliasing the old names, I don't see why we would need a compat >> package in Emacs? > > Only if we can hope to get rid of those aliases soon, because we'd > rather not have those compatibility aliases use up the namespace even > when all the packages in use have been updated to use the "clean" names. Well, you've started aliasing `class-name' in your patch, so I thought that was the plan. > For the CL package we solved this problem by leaving the "cl.el" package > as a "compatibility package" only required by the packages that haven't > been updated to use the new names. CL was so widely used that it will > take a *long* time to get rid of all uses of the old names, whereas > EIEIO's use is not as pervasive, so we don't necessarily have to do the > same for it. > This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el" > (with clean names, autoloaded from cl-lib) and then make eieio.el > into a simple compatibility package full of aliases. What to do with the other files like eieio-base then? We cannot rename it to cl-eieio-base.el because of name clashes, but it also provides part of the public, CLOS-like functions. To summarize the options so far: 1) Prefix everything with eieio- and be done with it. Create obsolete aliases for the old names and get rid of them "soon" (Emacs 25?). Alternatively, create an eieio-compat package with aliases for the old names. 2) Prefix everything with eieio- and create cl- aliases for the CLOS-like functionality. Those aliases may be defined in 2a) the eieio* files itself, or 2b) in a separate cl-whatever.el file. As in 1), define obsolete aliases for the old names or use a compat package. 3) Rename eieio to cl-eieio with clean names (i.e., eieio- and cl-prefixes), autoloaded from cl-lib, and make eieio.el a simple compatibility package full of aliases. I'm currently pretty much tied on "2b)+compat package" and 3). -David |
From: Stefan M. <mo...@ir...> - 2013-02-19 03:26:49
|
> I meant a compat package in CEDET upstream, so that it can run on older > Emacsen if we stop shipping our own EIEIO version. As long as we're > obsolete-aliasing the old names, I don't see why we would need a compat > package in Emacs? Only if we can hope to get rid of those aliases soon, because we'd rather not have those compatibility aliases use up the namespace even when all the packages in use have been updated to use the "clean" names. For the CL package we solved this problem by leaving the "cl.el" package as a "compatibility package" only required by the packages that haven't been updated to use the new names. CL was so widely used that it will take a *long* time to get rid of all uses of the old names, whereas EIEIO's use is not as pervasive, so we don't necessarily have to do the same for it. This said, maybe it would make sense to move "eieio.el" to "cl-eieio.el" (with clean names, autoloaded from cl-lib) and then make eieio.el into a simple compatibility package full of aliases. Stefan |
From: Stefan M. <mo...@ir...> - 2013-02-19 03:15:44
|
>> eieio's extensive abuse of eval-and-compile is a real pain in the rear! >> Does the additional patch below make it work for you? > Yes, it now compiles. Thanks. I installed it into Emacs's trunk. Stefan |
From: David E. <de...@ra...> - 2013-02-18 21:32:18
|
Stefan Monnier writes: >>> Actually, there's a misunderstanding here: >>> - setf was indeed part of CL, but being a macro it was accepted >>> (i.e. you don't need to have it defined at run-time, since it's > >>> macro-expanded during compilation). >>> - setf is part of core Elisp in Emacs-24.3. >>> So maybe we don't need oref/oset at all. >> Yes, although I like "(oset foo bar 'baz)" much better than the verbose >> (setf (cl-slot-value foo 'bar) 'baz) >> But I can understand that you want to get rid of it, and package writers >> can still define their own macros/accessors. > > I actually don't particular care if we keep them or not, except that if > we keep them, we need to give them a prefix. OK. I guess we'd have to use eieio-oref/oset then, since those functions are not from CLOS (given that 'cl' means that thing I thought it means, but I might just be confused :) ). >> Our problem on the CEDET side is that we want to stay compatible with >> older Emacsen, so we'll need some compat package. > > We can either introduce an eieio-compat package full of defaliases, or > do what we did with cl/cl-lib and turn eieio.el into a deprecated compat > package (and introduce a new package eieio-lib to replace it). I meant a compat package in CEDET upstream, so that it can run on older Emacsen if we stop shipping our own EIEIO version. As long as we're obsolete-aliasing the old names, I don't see why we would need a compat package in Emacs? -David |
From: David E. <de...@ra...> - 2013-02-18 20:55:41
|
Stefan Monnier writes: >>>>>> In toplevel form: >>>>>> eieio.el:168:1:Error: Symbol's function definition is void: >>>>>> eieio--class-parent > >>>>> Can you (setq byte-compile-error t debug-on-error t) so as to get >>>>> a backtrace? >>>> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just >>>> don't get a backtrace with debug-on-error. >>> No, I meant byte-compile-debug sorry. >> Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I >> gzipped it. > > eieio's extensive abuse of eval-and-compile is a real pain in the rear! > Does the additional patch below make it work for you? Yes, it now compiles. -David |
From: Stefan M. <mo...@ir...> - 2013-02-17 17:08:48
|
>>>>> In toplevel form: >>>>> eieio.el:168:1:Error: Symbol's function definition is void: >>>>> eieio--class-parent >>>> Can you (setq byte-compile-error t debug-on-error t) so as to get >>>> a backtrace? >>> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just >>> don't get a backtrace with debug-on-error. >> No, I meant byte-compile-debug sorry. > Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I > gzipped it. eieio's extensive abuse of eval-and-compile is a real pain in the rear! Does the additional patch below make it work for you? Stefan --- lisp/emacs-lisp/eieio.el.orig 2013-02-17 12:06:09.252331190 -0500 +++ lisp/emacs-lisp/eieio.el 2013-02-17 12:06:20.336456193 -0500 @@ -121,10 +121,9 @@ (list 'aref x ,index)) defs) (setq index (1+ index)))) - `(progn + `(eval-and-compile ,@(nreverse defs) - (eval-and-compile - (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index))))) + (defconst ,(intern (format "eieio--%s-num-slots" prefix)) ,index)))) (eieio--define-field-accessors class (-unused-0 ;;FIXME: not sure, but at least there was no accessor! |
From: David E. <de...@ra...> - 2013-02-14 22:27:02
|
Stefan Monnier writes: >>>> In toplevel form: >>>> eieio.el:168:1:Error: Symbol's function definition is void: >>>> eieio--class-parent >>> Can you (setq byte-compile-error t debug-on-error t) so as to get >>> a backtrace? >> Did you mean `byte-compile-error-on-warn'? Anyway, I'm afraid I just >> don't get a backtrace with debug-on-error. > > No, I meant byte-compile-debug sorry. Ah OK, I didn't know that one. Now I get a trace, but it's huge, so I gzipped it. -David |