<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.emacs.eieio">
    <title>gmane.emacs.eieio</title>
    <link>http://blog.gmane.org/gmane.emacs.eieio</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/157"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/124"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/119"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/117"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/115"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/109"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/106"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/104"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/98"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/97"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/94"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/92"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/90"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/83"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/81"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/79"/>
        <rdf:li rdf:resource="http://comments.gmane.org/gmane.emacs.eieio/78"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/157">
    <title>warnings in methods with enabled lexical-binding</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/157</link>
    <description>&lt;pre&gt;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?
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis &amp;amp; visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
cedet-eieio mailing list
cedet-eieio&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio
&lt;/pre&gt;</description>
    <dc:creator>Sergey Petrov</dc:creator>
    <dc:date>2013-04-14T15:41:39</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/124">
    <title>defining methods based on built-in ELisp types</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/124</link>
    <description>&lt;pre&gt;I recently started to use EIEIO in my ELisp programming.  Coming from
CLOS, I naturally started to define methods like

  (defmethod foo ((x string) ...))

  (defmethod foo ((x cons)) ...)

But this seems to be unsupported.  It looks like this lack of
functionality is behind item #2 on the EIEIO wish list ("Method
dispatch for built-in types").  Has there been any progress on this
front?

&lt;/pre&gt;</description>
    <dc:creator>Jesse Alama</dc:creator>
    <dc:date>2012-10-10T11:48:45</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/119">
    <title>Major mode for EIEIO custom buffers</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/119</link>
    <description>&lt;pre&gt;Hi,

I think it would be an improvement if eieio-custom.el had its own major 
mode for the buffers it creates.

I need this because I have a minor mode that defines new key bindings for 
RET and TAB, which shadow the ones in widget-keymap. This is easily 
remedied, but it requires a hook for the buffers that eieio-custom creates. 
Rather than just adding a hook, it seems more sensible to create a simple 
major mode, as this would also improve documentation.

I've included a simple patch below.

Regards,

Leo

-----------------------------------------------------------------

diff -ruN old/eieio-custom.el new/eieio-custom.el
--- old/eieio-custom.el2012-06-06 14:55:00.258634000 +0100
+++ new/eieio-custom.el2012-06-06 15:05:15.311976000 +0100
&amp;lt; at &amp;gt;&amp;lt; at &amp;gt; -332,6 +332,16 &amp;lt; at &amp;gt;&amp;lt; at &amp;gt;
 Optional argument GROUP is the sub-group of slots to display."
   (eieio-customize-object obj group))
 
+(defvar eieio-custom-mode-map
+  (let ((map (make-sparse-keymap)))
+    (set-keymap-parent map widget-keymap)
+    map)
+  "Keymap for EIEIO Cus&lt;/pre&gt;</description>
    <dc:creator>Leo P White</dc:creator>
    <dc:date>2012-06-06T14:29:38</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/117">
    <title>defclass :initform behavior</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/117</link>
    <description>&lt;pre&gt;EIEIO's DEFCLASS doesn't seem to handle :INITFORM in the same manner
as does Common Lisp CLOS. There does seem to have been some discussion
of this back in 2010 ('Constructor -- lambda expression' (From: Frank
&amp;lt;some.frank&amp;lt; at &amp;gt;gm...&amp;gt; - 2010-05-29 19:44)) on this list but the issue
doesn't seem to have been resolved.

Common Lisp specifies that the form provided to :INITFORM is evaluated
only at the time a new member of the class is generated:

CL-USER&amp;gt; (defvar x 0)
X
CL-USER&amp;gt; (setf x 0)
0
CL-USER&amp;gt; x
0
CL-USER&amp;gt; (defclass xyz ()
  ((name
    :initarg :name
    :initform (setf x (1+ x))
    :type number)))
#&amp;lt;STANDARD-CLASS XYZ&amp;gt;
CL-USER&amp;gt; x
0
CL-USER&amp;gt; 


Contrast this with EIEIO:

ELISP&amp;gt; (defvar x 0)
x
ELISP&amp;gt; (setf x 0)
0
ELISP&amp;gt; x
0
ELISP&amp;gt; (defclass xyz ()
  ((name
    :initarg :name
    :initform (setf x (1+ x))
    :type number)))
xyz
ELISP&amp;gt; x
1


In EIEIO, DEFCLASS seems to evaluate the form passed to :INITFORM at
time of DEFCLASS invocation. Is this the intended behavior?

The EIEIO documents indicate, "The value &lt;/pre&gt;</description>
    <dc:creator>David A. Thompson</dc:creator>
    <dc:date>2012-05-28T00:49:04</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/115">
    <title>cedet versions and compatibility</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/115</link>
    <description>&lt;pre&gt;When I look around, I see cedet 1.0, 1.0pre3 and 1.0beta7.  What is the
compatibility of these versions?

beta7 is installed at work, and it might be difficult to get it upgraded.  I
have code that works with pre3, but appears to not work with beta7.  Is
there a good way to get it to work with everything, or should I just try to
get cedet upgraded?

Troy
------------------------------------------------------------------------------
10 Tips for Better Web Security
Learn 10 ways to better secure your business today. Topics covered include:
Web security, SSL, hacker attacks &amp;amp; Denial of Service (DoS), private keys,
security Microsoft Exchange, secure Instant Messaging, and much more.
http://www.accelacomm.com/jaw/sfnl/114/51426210/_______________________________________________
cedet-eieio mailing list
cedet-eieio&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio
&lt;/pre&gt;</description>
    <dc:creator>Troy Daniels</dc:creator>
    <dc:date>2011-07-21T19:15:47</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/109">
    <title>call-next-method invocation order</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/109</link>
    <description>&lt;pre&gt;Hi there,

I'm not sure maybe there's a problem with (call-next-method)'s 
invocation order with multiple inheritance;

Check this tree out

  +--base
       +--derived1
       |    +--derived2
       |         +--derived3
       +--derivedX
            +--derived3

And here's the code for it;
Well it's kinda a complex example but the point why I bother you guys 
with it is if I run this example on Allegro CL I get a different result;
BTW if I add  :method-invocation-order :depth-first to class derived2 I 
get the same result as on Allegro CL;

As I'm not an expert in CL I'll leave it up to you guys what to do with it;

Thanks
Frank


(require 'cl)
(require 'eieio)

(defclass base ()
  ())
(defmethod func ((this base))
  (foo this))
(defmethod foo ((this base))
  (message "base::foo"))

(defclass derivedX (base)
  ())

(defclass derived1 (base)
  ())
(defmethod foo ((this derived1))
  (message "derived1::foo"))

(defclass derived2 (derived1)
  ()
;;;  :method-invocation-order :depth-first
)
(defmethod foo ((&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-07-18T20:15:29</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/106">
    <title>:method-invocation-order :depth-first</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/106</link>
    <description>&lt;pre&gt;Hi,

Is the :method-invocation-order :depth-first a common lisp feature?

Just curious as I'd like to know how portable this feature is;

Thanks
Frank


------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-07-18T08:25:28</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/104">
    <title>compiling error</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/104</link>
    <description>&lt;pre&gt;Hello,

I tried to byte-compile-file this

(require 'eieio)

(defclass foo ()
  ())

(defmethod bar ((this foo))
  )


and I get this error

`eieio.el:8:1:Error: Symbol's value as variable is void: filename'

How can I get it to compile my file?

Thanks
Frank




------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-07-02T08:14:34</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/98">
    <title>More default methode issues</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/98</link>
    <description>&lt;pre&gt;Hi,

This looks like a glitch to me.


(require 'eieio)

(defclass foo ()
  ())

(defmethod func (this)
  (message "func default %s" this))

(defmethod func :before ((this foo))
  (message "func foo :before %s" this))

;; (defmethod func :primary ((this foo))
;;   (message "func foo :primary %s" this)
;;   123)

(defmethod func :after ((this foo))
  (message "func foo :after %s" this))

;; This one is probably OK.
(func (make-instance 'foo))

;; Must be wrong as a methode which is bound for class foo is called!
;; I assume the default methode should be called.
(func 666)


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-06-05T07:41:44</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/97">
    <title>Parent's slot overwriting</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/97</link>
    <description>&lt;pre&gt;Hi,

Please try this.  I get an error if I try to evaluate the child class.

Regards,
Frank

(require 'eieio)

(defclass foo ()
  ((field :type string)))

(defclass bar ()
  ((field :type wholenum)))

;; I get an error here.
;; Apparently there's a typecheck done for field.
;;
;; The documentation says:
;;   If the new class has a slot with the same name as the parent,
;;   the new slot overrides the parent's slot.
;;
;; Is this supposed to throw an error in this case?
(defclass child (bar foo)
  ((field :type vector)))

;; This evaluates fine.
;; (defclass child (bar foo)
;;   ((field :type wholenum)))  ;; bar's field type matches child's 
field type


------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-06-04T18:30:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/94">
    <title>Default methods :before and :after aren't called</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/94</link>
    <description>&lt;pre&gt;Hi,

Is this correct behaviour? It looks like only the :primary default 
method gets called even if there are :before and :after ones defined?


(require 'eieio)

(defclass foo ()
  ())

(defmethod func :before (this)
  (message "default method :before: %s" this))

(defmethod func :primary (this)
  (message "default method :primary: %s" this))

(defmethod func :after (this)
  (message "default method :after: %s" this))


(defmethod func :before ((this foo))
  (message "foo's method :before: %s" this))

(defmethod func :primary ((this foo))
  (message "foo's method :primary: %s" this)
  123)

(defmethod func :after ((this foo))
  (message "foo's method :after: %s" this))


(func (make-instance 'foo))
;; I'll get this which looks correct to me.
;;
;; foo's method :before: [object foo foo]
;; foo's method :primary: [object foo foo]
;; foo's method :after: [object foo foo]
;; 123


(defclass bar ()
  ())


(func (make-instance 'bar))
;; Hmmm what about the :before and :after default methods?
;;
;; default method&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-06-02T18:21:36</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/92">
    <title>Constructor -- lambda expression</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/92</link>
    <description>&lt;pre&gt;Hey there again,

Another question:

(defclass foo ()
  ((bar :initform (lambda () (make-vector 10 nil)))))

(make-instance 'foo)
;; results in [object foo "foo" (lambda nil (make-vector 10 nil))]

Isn't the lambda expression of the :initform supposed to be evaluated at 
instantiation time?


------------------------------------------------------------------------------
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-05-29T19:44:17</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/90">
    <title>Constructor</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/90</link>
    <description>&lt;pre&gt;Hi there,
I have a question regarding constructors.

I'm fairly new to EIEIO and Emacs but I was wondering how to do this:

Lets say I have this class:

(defclass foo ()
  ((size :initarg :size
     :type wholenum)
   (vec :initform (make-vector size nil)
    :protection :protected)))

Which embed's a vector.

My question is how do I get VEC initialized.  This code obviously 
doesn't work.  Can I somehow reference the previously initialized 
arguments (in this case SIZE) in an initform?

Is it possible to write my own constructor which executes before the 
default constructor like this?

(defmethod foo :before :static ((obj foo) &amp;amp;rest args)
  )

Thanks

------------------------------------------------------------------------------
&lt;/pre&gt;</description>
    <dc:creator>Frank</dc:creator>
    <dc:date>2010-05-29T19:23:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/83">
    <title>Yet another multiple inheritence problem</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/83</link>
    <description>&lt;pre&gt;Hi,

I'm back with yet another multiple inheritance problem (too many mixins,
I guess) ;)

My class graph looks like this:

                        eieio-default-superclass
                                   |
               +-------------------+-------------------+
               |                   |                   |
          rudel-state    rudel-impersonator    rudel-delegator
               |                   |                   |
               +-------------------+-------------------+
                                   |
                            rudel-obby-state     e-def-sup
                                   |                |
                  +----------------+                |
                  |                                 |
   rudel-obby-client-connection-state    rudel-obby-document-handler
                  |                                 |
                  +----------------+----------------+
                                   |
                  rudel-obby-client-state-subscrib&lt;/pre&gt;</description>
    <dc:creator>Jan Moringen</dc:creator>
    <dc:date>2009-12-08T03:04:32</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/81">
    <title>eieio.el: another constructor question</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/81</link>
    <description>&lt;pre&gt;Hi,

while working with a class hierarchy similar to this

 a
/ \
b c
\ /
 d

I discovered surprising (to me) behavior. Each class has an
initialize-instance method and they run in one of the expected orders:
d, b, c, a.

The surprising part: each initialize-instance method uses
call-next-method. The methods of d and b provide replacement arguments
and extent the list of initargs with :c 'c and :d 'd respectively.
However, when c uses (call-next-method) the eieio-generic-call-arglst of
the original call (to initialize-instance of d) is used. I expected the
replacement arguments provided in the initialize-instance methods of d
and b to be propagated to the call of c's initialize-instance.

With instrumented methods that print their arguments, the following
happens:

(d "" :a 'a)
| d (:a a)
| b (:a a :d d)
| c (:a a :d d :b b)
| a (:a a)           ; (call-next-method) in c calls a's 
                     ; initialize-instance with original argument list

I expected the result to be more like this:

(d "" :a 'a&lt;/pre&gt;</description>
    <dc:creator>Jan Moringen</dc:creator>
    <dc:date>2009-11-16T02:04:42</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/79">
    <title>eieio.el: initialize-instance: strange behavior with simple class hierarchy</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/79</link>
    <description>&lt;pre&gt;Hi,

I think I may have found a bug in EIEIO. If it is not a bug, it is at
least surprising behavior.

I discovered the problem when working with a class hierarchy that looks
like this

a
+-d

b
+-c
  +-d

a and b have initialize-instance :after methods, d has a primary
initialize-instance method.

When creating a d object, I expect the constructors to run as follows:

     1. (initialize-instance d)
     2. (initialize-instance b)
     3. (initialize-instance a)

or

     1. (initialize-instance d) 
     2. (initialize-instance a) 
     3. (initialize-instance b)

but what really happens is

     1. (initialize-instance d) 
     2. (initialize-instance b) 
     3. (initialize-instance a)
     4. (initialize-instance b)
     5. (initialize-instance a)

I think, this is wrong, but maybe I did not understand :after or
call-next-method correctly.

Redefining the involved classes and methods changes something and
sometimes makes the duplicate runs go away.

The attached code should produce the problem with CVS C&lt;/pre&gt;</description>
    <dc:creator>Jan Moringen</dc:creator>
    <dc:date>2009-09-26T01:46:31</dc:date>
  </item>
  <item rdf:about="http://comments.gmane.org/gmane.emacs.eieio/78">
    <title>failed to emerge eieio</title>
    <link>http://comments.gmane.org/gmane.emacs.eieio/78</link>
    <description>&lt;pre&gt;------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july_______________________________________________
cedet-eieio mailing list
cedet-eieio&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio
&lt;/pre&gt;</description>
    <dc:creator>李玉北</dc:creator>
    <dc:date>2009-08-08T07:16:18</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.emacs.eieio">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.emacs.eieio</link>
  </textinput>
</rdf:RDF>
