gmane.emacs.eieio

Re: warnings in methods with enabled lexical-binding

Sergey Petrov — 2013-05-24T06:22:51

On Fri, 24 May 2013 05:46:40 +0500, Eric M. Ludlam <eric< at >siege-engine.com>  
wrote:



Yes, in bzr version it is ok. Thank you Eric, and sorry for troubling you.

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: warnings in methods with enabled lexical-binding

Eric M. Ludlam — 2013-05-24T00:46:40

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

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may

Re: warnings in methods with enabled lexical-binding

Sergey — 2013-05-21T10:30:45



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.el2013-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


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic

Re: warnings in methods with enabled lexical-binding

Eric M. Ludlam — 2013-05-07T00:27:56

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

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and 
their applications. This 200-page book is written by three acclaimed 
leaders in the field. The early access version is available now. 
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

warnings in methods with enabled lexical-binding

Sergey Petrov — 2013-04-14T15:41:39

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 & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter_______________________________________________
cedet-eieio mailing list
cedet-eieio< at >lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cedet-eieio

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-19T21:55:26

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

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Re: Cleaning up the EIEIO namespace

David Engster — 2013-02-19T19:49:02

Well, you've started aliasing `class-name' in your patch, so I thought
that was the plan.


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 tie

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-19T03:15:34

Thanks.  I installed it into Emacs's trunk.


        Stefan

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb

Re: Cleaning up the EIEIO namespace

David Engster — 2013-02-18T21:32:06

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 :) ).


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

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/

Re: Cleaning up the EIEIO namespace

David Engster — 2013-02-18T20:55:28

Yes, it now compiles.

-David

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-17T17:08:41

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
< at >< at > -121,10 +121,9 < at >< at >
                  (list 'aref x ,index))
               defs)
         (setq index (1+ index))))
-    `(progn
+    `(eval-and-compile
        ,< at >(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!

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news,

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-14T22:17:50

No, I meant byte-compile-debug sorry.


Let me get back to you on this one, later,


        Stefan

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-14T22:16:21

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.


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).


No, it can be autoloaded, like the definitions in cl-macs, cl-seq, and
cl-extra get autoloaded.


        Stefan

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-14T14:30:27

Can you (setq byte-compile-error t debug-on-error t) so as to get
a backtrace?


It's defined (as a macro) by the call to (eieio--define-field-accessors
class ...)  which is kind of a "mini cl-defstruct".


        Stefan

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Re: Cleaning up the EIEIO namespace

David Engster — 2013-02-13T16:31:42

In toplevel form:
eieio.el:168:1:Error: Symbol's function definition is void: eieio--class-parent

I also cannot find a definition for eieio--class-parent, but maybe it's
hidden somewhere?


Eric already posted links to the hyperspec where this can be looked
up. From your bug report #10781, the following names are from CLOS:

* Most of the slot-* names, like slot-boundp, slot-exists-p, etc.
* make-instance, initialize-instance
* with-slots
* class-name, class-of
* next-method-p, call-next-method
* defgeneric, defclass, defmethod

Now, whether to include them in the cl- or the eieio-namespace - I don't
have a terribly strong opinion on that one. If it's deemed too hack-ish,
then so be it, and we just prefix everything with eieio-. [Eric, if you
feel more strongly about those names, then please speak up. :-) ]

Actually, the most critical thing is 'oref' and 'oset', because this is
used extensively (~1800 times in CEDET), and it is not from
CLOS. Prefixing that with 'eieio-' would make code using EIEIO very
v

Re: Cleaning up the EIEIO namespace

Stefan Monnier — 2013-02-13T02:47:51

It was largely mechanical, tho.


Hmm.. there are both eieio-class-parent as well as eieio--class-parent,
but I'm not sure why that would cause a byte-compile error.


I don't know CLOS either.  I also don't know EIEIO enough to know for
sure which functions are "internal" (and can hence move to "eieio-" or
even "eieio--" without any problem) and which are "exported", so that
renaming them has to be done more carefully (with obsolete aliases).


OK.


Sounds good,


        Stefan

------------------------------------------------------------------------------
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb

Re: defining methods based on built-in ELisp types

Jesse Alama — 2012-10-13T17:53:21


Ah, I didn't realize that such a route would be available.  Sounds
quite doable.


I'd be happy to help.  I haven't signed papers yet with the FSF.  Can
you let me know how to get started with that process?

Re: defining methods based on built-in ELisp types

Eric M. Ludlam — 2012-10-12T22:45:43

If your goal is just adding methods to built-in types, that might be 
possible.  If the check that the input class is an eieio class was 
removed, or if there is a way to verify that 'string' or whatever else 
is a built-in type, the methods aren't strictly tied into the class 
structure.

It is when the method is called that more logic is needed to first check 
for eieio class, followed by some identified built-in type.  It might 
not be too bad.

Remove or augment class check in eieio--defmethod, then somewhere in 
eieio-generic-call reverse the addition of built-in types.

Hmmm.  Could be interesting.  Have you signed papers w/ the FSF for 
contributions to Emacs?

Eric

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd

Re: defining methods based on built-in ELisp types

Jesse Alama — 2012-10-12T09:26:41


I figured that this would probably involve some low-level hacking.
The typical use case that I have in mind is where I define methods
based on a the (primitive) type of the first argument to help clean up
my code.  I find that the three methods

  (defgeneric foo (x))
  (defmethod foo ((x cons)) ...)
  (defmethod foo ((x string)) ...)
  (defmethod foo ((x sequence)) ...)

is more elegant and maintainable, and promotes greater type safety,
more clearly than

  (defun foo (x)
    (cond ((consp x) ...)
          ((stringp x) ...)
          ((sequencep x) ...)
          (t (error "Don't know how to handle '%s'" x))))

or

  (defun foo-cons (x) (...))
  (defun foo-string (x) (...))
  (defun foo-sequence (x) (...))
  (defun foo (x)
    (cond ((consp x) (foo-cons x))
          ...))

base system classes (or types) isn't a problem.

Jesse

Re: defining methods based on built-in ELisp types

Eric M. Ludlam — 2012-10-12T01:54:48

As far as I know, no one has looked into how to make that work.  Most of 
the projects I've worked on have only needed new classes, not extensions 
of built-in types.

I suspect any such feature would need to be done from Emacs core.   I 
suppose it could be faked from the outside, but there would be no useful 
features to inherit from the base type since they have no methods. ;)

Eric


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev

defining methods based on built-in ELisp types

Jesse Alama — 2012-10-10T11:48:45

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?