Re: [E-devel] Eobj - Request for review/comments

[David Seikel]

On Wed, 16 May 2012 17:31:39 +0900 Cedric BAIL 
wrote:

> On Wed, May 16, 2012 at 5:25 PM, Vincent Torri
>  wrote:
> > On Wed, May 16, 2012 at 10:01 AM, Carsten Haitzler
> >  wrote:
> >> On Sun, 15 Apr 2012 15:34:09 +0300 Tom Hacohen
> >>  said:
> >>> On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:
> >>> > 15. eobj_generic_data_* ... i really think this should support
> >>> > passing in a free func for generic data (NULL == dont free it),
> >>> > and previous egenric data is auto-greed if u set new data on
> >>> > top, same when u del - dont bother returning the pointer to it
> >>> > except on get. ALSO for generic data - can u provide a TYPE
> >>> > param - string, opque, eobj, opaque list, object list etc.
> >>> > types. opaque is unknown to eobj, but string can be used to
> >>> > account for memory objects and eobj can be used to have eobj
> >>> > auto unref attached generic data if its another eobj or list of
> >>> > eobj's. this would come it very handy.
> >>>
> >>> I thought about it, but it felt a bit fat to me... The problem is
> >>> that we'd have to save a free function/NULL for every property
> >>> which is kinda wasteful. Especially since you can in most cases
> >>> just have a delete callback and free the properties from there.
> >>> If you really think it's a must, I'll add it.
> >>
> >> i'm coming back to this. i really still think we should have a
> >> free func. if it's null, nothing is freed for u. if not null it's
> >> called on object delete for any remaining properties still there.
> >> cost is just 1 more ptr. :)
> >
> > while you're at it, i mention again that there is already a (C++)
> > library which name (and namespace) is 'eo'. I think that which
> > should use eobj. 'eobj' is not that long. And as another poster
> > said, from an external POV, 'eobj' is more meaningfull than just
> > 'eo'
> 
> Hum, I have changed my mind a little about this issue. As it is a C++
> library, it means C++ namespace. That should never conflict with us.
> It will maybe confuse google. But using a C namespace with a C++
> namespace should work properly without any clash. That's for the
> technical part, now more for the social part. I still prefer eo, but
> we would maybe be a better citizen if we use eobj.

Having just searched my email looking for this thread, I can say that
"eo" is a pain to search on.  :-P

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.


signature.asc
Description: PGP signature
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Cedric BAIL]

On Wed, May 16, 2012 at 5:25 PM, Vincent Torri  wrote:
> On Wed, May 16, 2012 at 10:01 AM, Carsten Haitzler  
> wrote:
>> On Sun, 15 Apr 2012 15:34:09 +0300 Tom Hacohen  
>> said:
>>> On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:
>>> > 15. eobj_generic_data_* ... i really think this should support passing in 
>>> > a
>>> > free func for generic data (NULL == dont free it), and previous egenric
>>> > data is auto-greed if u set new data on top, same when u del - dont bother
>>> > returning the pointer to it except on get. ALSO for generic data - can u
>>> > provide a TYPE param - string, opque, eobj, opaque list, object list etc.
>>> > types. opaque is unknown to eobj, but string can be used to account for
>>> > memory objects and eobj can be used to have eobj auto unref attached
>>> > generic data if its another eobj or list of eobj's. this would come it 
>>> > very
>>> > handy.
>>>
>>> I thought about it, but it felt a bit fat to me... The problem is that
>>> we'd have to save a free function/NULL for every property which is kinda
>>> wasteful. Especially since you can in most cases just have a delete
>>> callback and free the properties from there. If you really think it's a
>>> must, I'll add it.
>>
>> i'm coming back to this. i really still think we should have a free func. if
>> it's null, nothing is freed for u. if not null it's called on object delete 
>> for
>> any remaining properties still there. cost is just 1 more ptr. :)
>
> while you're at it, i mention again that there is already a (C++)
> library which name (and namespace) is 'eo'. I think that which should
> use eobj. 'eobj' is not that long. And as another poster said, from an
> external POV, 'eobj' is more meaningfull than just 'eo'

Hum, I have changed my mind a little about this issue. As it is a C++
library, it means C++ namespace. That should never conflict with us.
It will maybe confuse google. But using a C namespace with a C++
namespace should work properly without any clash. That's for the
technical part, now more for the social part. I still prefer eo, but
we would maybe be a better citizen if we use eobj.
-- 
Cedric BAIL

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

On Wed, May 16, 2012 at 10:01 AM, Carsten Haitzler  wrote:
> On Sun, 15 Apr 2012 15:34:09 +0300 Tom Hacohen  said:
>
>> On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:
>
>> > 15. eobj_generic_data_* ... i really think this should support passing in a
>> > free func for generic data (NULL == dont free it), and previous egenric
>> > data is auto-greed if u set new data on top, same when u del - dont bother
>> > returning the pointer to it except on get. ALSO for generic data - can u
>> > provide a TYPE param - string, opque, eobj, opaque list, object list etc.
>> > types. opaque is unknown to eobj, but string can be used to account for
>> > memory objects and eobj can be used to have eobj auto unref attached
>> > generic data if its another eobj or list of eobj's. this would come it very
>> > handy.
>>
>> I thought about it, but it felt a bit fat to me... The problem is that
>> we'd have to save a free function/NULL for every property which is kinda
>> wasteful. Especially since you can in most cases just have a delete
>> callback and free the properties from there. If you really think it's a
>> must, I'll add it.
>
> i'm coming back to this. i really still think we should have a free func. if
> it's null, nothing is freed for u. if not null it's called on object delete 
> for
> any remaining properties still there. cost is just 1 more ptr. :)

while you're at it, i mention again that there is already a (C++)
library which name (and namespace) is 'eo'. I think that which should
use eobj. 'eobj' is not that long. And as another poster said, from an
external POV, 'eobj' is more meaningfull than just 'eo'

Vincent

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 16/05/12 11:01, Carsten Haitzler (The Rasterman) wrote:
> i'm coming back to this. i really still think we should have a free func. if
> it's null, nothing is freed for u. if not null it's called on object delete 
> for
> any remaining properties still there. cost is just 1 more ptr. :)
>

Oldie! Already added it. :) It's in svn with a free func.

--
Tom.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Sun, 15 Apr 2012 15:34:09 +0300 Tom Hacohen  said:

> On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:

> > 15. eobj_generic_data_* ... i really think this should support passing in a
> > free func for generic data (NULL == dont free it), and previous egenric
> > data is auto-greed if u set new data on top, same when u del - dont bother
> > returning the pointer to it except on get. ALSO for generic data - can u
> > provide a TYPE param - string, opque, eobj, opaque list, object list etc.
> > types. opaque is unknown to eobj, but string can be used to account for
> > memory objects and eobj can be used to have eobj auto unref attached
> > generic data if its another eobj or list of eobj's. this would come it very
> > handy.
> 
> I thought about it, but it felt a bit fat to me... The problem is that 
> we'd have to save a free function/NULL for every property which is kinda 
> wasteful. Especially since you can in most cases just have a delete 
> callback and free the properties from there. If you really think it's a 
> must, I'll add it.

i'm coming back to this. i really still think we should have a free func. if
it's null, nothing is freed for u. if not null it's called on object delete for
any remaining properties still there. cost is just 1 more ptr. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 23/04/12 05:15, Cedric BAIL wrote:
> On Mon, Apr 2, 2012 at 6:58 PM, Tom Hacohen  wrote:
>> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>> * I'm not sure yet about which kinds of refing we want. I'm pretty
>> certain we want named refs and "object" name refs (i.e linking between
>> objects). And I do believe we need weak ref/unref, but again not yet
>> decided.
>
> I am all for weak ref and named ref. You should by the way fix the
> weak ref to remember file and line of their allocation, that would
> help for debugging. Weak ref could have a debug and production mode.
> It could in production just be referencing up the EObj and returning a
> pointer to EObj, but in debug build it would allocate a weak
> reference.
> This means we don't need ref/unref in my opinion (You already know I
> am highly against those).
>

Already there. Do you like what's there atm? Named weak-refs make no 
sense and furthermore, weak-refs are not interchangeable with 
strong-refs, so what you are suggesting doesn't make sense for us. Did 
you look at the current implementations of weak-ref and named-refs? Do 
you like them?

>> 4. Many cases are not checked for validity and are just allowed. I plan
>> on having 2 modes, one for checking those, and the fast mode that will
>> just be fast. Possibly by having a compilation option + env var to turn
>> the checks on.
>
> I am not sure the env var would be practical in all case (due to
> inline for example and change in behaviour).

I'm talking about internal sanity checking, I don't see how that'd matter.
>
>> 5. No docs/proper internal naming yet, but API and examples should be solid.
>
> It would be nice to have a document that explain the design and idea.
> Including what _super (And why it is not named warp10 as it should
> be), what composite means, what are our goal, why we did redesign our
> own object model, and stuff like that.

Yeah, it's in my TODO, somewhere. You have to understand though, it's 
not a top priority comparing to integration into Evas for example. All 
the changes in eobj in the last couple of days were to support the 
integration into evas we are working on at the moment.
>
>> 10. Static class method IDs will be added soon.
>> * Raster suggested a cool idea that will help speed things up, which 
>> is
>> static IDs. It's not done yet, but it's 99% supported.
>
> Don't also forget to use eina_mempool. I will go after repacking
> algorithms when you are done.

I already forgot about it. Though seriously, I know, just didn't get to it.
>
>> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
>> (I need a better name) function that will be called at the end of
>> eobj_do automatically. This will let us defer changes in an easier manner.
>> * I'm not sure about this one. In one hand, it makes it easier to 
>> defer
>> changes, though on the other, it's deference is not optimal, would have
>> been better to just create an infrastructure that will let us do better
>> deference of changes.
>
> What about a pre and post signal emitted when we start a _do command ?

pre: "we are about to possibly do something"? Sounds unneeded. As for 
post: "we possibly did something before" - sounds useless as well. Don't 
you agree? Maybe there are uses for that, but please provide example use 
cases.
>
>> Also, we are also working on automatic eobj bindings generation for
>> other languages, so if you have anything to comment on this matter as
>> well, please do. I see this as one of the most important parts of this
>> change.
>
> Hum, I have a very stupid things to say here. Would it be possible to
> generate bindings at compile time and not at runtime ? Performance
> wise it's a much better option and it would make scripting on good
> speed track. I don't know how you plan to do this bindings generation,
> but if you start from a file description, maybe it could also generate
> the .c/.h file and just put some nice /* *** EOBJECT GENERATOR : YOU
> CAN EDIT CODE BELOW THIS LINE *** */, /* *** EOBJECT GENERATOR : YOU
> SHOULDN'T TOUCH THE LINE BELOW *** */. Just trowing an idea here.

Already like that. Well, without the ugly comments. :)
>
>> Bug reports, comments, suggestions, or whatever are more than welcomed!
>
> Just another comment, eobj_event_callback_del_full and
> eobj_event_callback_del. I would just make
> eobj_event_callback_del_full be eobj_event_callback_del and rename
> eobj_event_callback_del as eobj_event_callback_del_lazy. Reason, is
> that we should encourage the use of the full version (it should really
> have been our only version since day one, sadly we didn't had it when
> we did our first release, so it was added to late). Now that we have a
> chance to fix that, better take it !
>
> That's all I could think about that really matter.

Perhaps. I believe having the same name as what we had before is a big 
advantage (easier for people to "learn"), but I guess I can change it. 
Lets see what 

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Mon, 23 Apr 2012 10:46:36 +0900 Cedric BAIL  said:

> On Tue, Apr 17, 2012 at 5:01 PM, Tom Hacohen  wrote:
> > On 17/04/12 10:55, Carsten Haitzler (The Rasterman) wrote:
> >> i don't see the point. it's just a pointer to something. it's fine as-is.
> >> in this way of doing an api we no longer can use the const attribute to say
> >> anything about the object here. there isn't a lot of point either.
> >
> > I find it nice to have in cases where you want to query the object but
> > not modify it. For example, but not only: when returning textblock
> > cursors (assuming they were Eobj as well) from the textblock API...
> >
> > But ok, if you think it's not needed ATM I'll just wait until I find a
> > concrete use case.
> 
> I do disagree with raster on this. Const is a must, it help compiler
> and developer spot their error more easily. It also help for some
> optimization. I do thing that adding an eo_query(const Eo *obj, ...);
> is worth it. It does means that we do have a new class of function
> pointer in Eo. So we better think about it now, rather than later and
> break our structure and ABI.

you can't do it with varargs as any of the op id macros could set or get,
unless you now complicate things. also there is no optimization the compiler
can sensibly do in any of these situations. so here is what it looks like to
the compiler for 1 get example:

eobj_do(obj, EVAS_COLOR_GET(&r, &g, &b, &a));

fn(void *obj, int id1, void *p1, void *p2, void *p3, void *p4, int end);
vs
fn(const void *obj, int id1, void *p1, void *p2, void *p3, void *p4, int end);

the ONLY optimizing the compiler can do with a const ptr vs non is assume
previously fetched values are the same without a re-fetch and no operations in
between that MAY have affected them. eg:

void *obj = x;

printf("val = %i\n", obj->myval);
f1(obj, 10); // f1 takes const void * for obj
printf("val = %i\n", obj->myval);

in THIS case the compiler can keep the value fetched from the first printf
(myval) and OPTIMIZE without having to deref obj as what obj points to
can/will not have changed. if it was not const for the obj, compiler must re-do
the deref.

BUT... here's the catch... the "cached" value would be in a register and...
that would have been nuked by the func call. so unless it was inlined - it wont
be able to. ALSO for eobj the object struct is opaque to the caller so u never
deref its internals... thus the above never happens. so it doesnt help
optimization at all in these kinds of cases.

as for spotting bugs - doesnt a GET tell you enough? do u think people see the
const before they see a get? as for compiler... what issue will it spot here?
how will the compiler spot anything iuf we add a const in front of the obj ptr
and specialize "gets" ?

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Cedric BAIL]

On Mon, Apr 2, 2012 at 6:58 PM, Tom Hacohen  wrote:
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>        * I'm not sure yet about which kinds of refing we want. I'm pretty
> certain we want named refs and "object" name refs (i.e linking between
> objects). And I do believe we need weak ref/unref, but again not yet
> decided.

I am all for weak ref and named ref. You should by the way fix the
weak ref to remember file and line of their allocation, that would
help for debugging. Weak ref could have a debug and production mode.
It could in production just be referencing up the EObj and returning a
pointer to EObj, but in debug build it would allocate a weak
reference.
This means we don't need ref/unref in my opinion (You already know I
am highly against those).

> 4. Many cases are not checked for validity and are just allowed. I plan
> on having 2 modes, one for checking those, and the fast mode that will
> just be fast. Possibly by having a compilation option + env var to turn
> the checks on.

I am not sure the env var would be practical in all case (due to
inline for example and change in behaviour).

> 5. No docs/proper internal naming yet, but API and examples should be solid.

It would be nice to have a document that explain the design and idea.
Including what _super (And why it is not named warp10 as it should
be), what composite means, what are our goal, why we did redesign our
own object model, and stuff like that.

> 10. Static class method IDs will be added soon.
>        * Raster suggested a cool idea that will help speed things up, which is
> static IDs. It's not done yet, but it's 99% supported.

Don't also forget to use eina_mempool. I will go after repacking
algorithms when you are done.

> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> (I need a better name) function that will be called at the end of
> eobj_do automatically. This will let us defer changes in an easier manner.
>        * I'm not sure about this one. In one hand, it makes it easier to defer
> changes, though on the other, it's deference is not optimal, would have
> been better to just create an infrastructure that will let us do better
> deference of changes.

What about a pre and post signal emitted when we start a _do command ?

> Also, we are also working on automatic eobj bindings generation for
> other languages, so if you have anything to comment on this matter as
> well, please do. I see this as one of the most important parts of this
> change.

Hum, I have a very stupid things to say here. Would it be possible to
generate bindings at compile time and not at runtime ? Performance
wise it's a much better option and it would make scripting on good
speed track. I don't know how you plan to do this bindings generation,
but if you start from a file description, maybe it could also generate
the .c/.h file and just put some nice /* *** EOBJECT GENERATOR : YOU
CAN EDIT CODE BELOW THIS LINE *** */, /* *** EOBJECT GENERATOR : YOU
SHOULDN'T TOUCH THE LINE BELOW *** */. Just trowing an idea here.

> Bug reports, comments, suggestions, or whatever are more than welcomed!

Just another comment, eobj_event_callback_del_full and
eobj_event_callback_del. I would just make
eobj_event_callback_del_full be eobj_event_callback_del and rename
eobj_event_callback_del as eobj_event_callback_del_lazy. Reason, is
that we should encourage the use of the full version (it should really
have been our only version since day one, sadly we didn't had it when
we did our first release, so it was added to late). Now that we have a
chance to fix that, better take it !

That's all I could think about that really matter.
-- 
Cedric BAIL

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Cedric BAIL]

On Tue, Apr 17, 2012 at 5:01 PM, Tom Hacohen  wrote:
> On 17/04/12 10:55, Carsten Haitzler (The Rasterman) wrote:
>> i don't see the point. it's just a pointer to something. it's fine as-is. in
>> this way of doing an api we no longer can use the const attribute to say
>> anything about the object here. there isn't a lot of point either.
>
> I find it nice to have in cases where you want to query the object but
> not modify it. For example, but not only: when returning textblock
> cursors (assuming they were Eobj as well) from the textblock API...
>
> But ok, if you think it's not needed ATM I'll just wait until I find a
> concrete use case.

I do disagree with raster on this. Const is a must, it help compiler
and developer spot their error more easily. It also help for some
optimization. I do thing that adding an eo_query(const Eo *obj, ...);
is worth it. It does means that we do have a new class of function
pointer in Eo. So we better think about it now, rather than later and
break our structure and ABI.
-- 
Cedric BAIL

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 17/04/12 10:55, Carsten Haitzler (The Rasterman) wrote:
> i don't see the point. it's just a pointer to something. it's fine as-is. in
> this way of doing an api we no longer can use the const attribute to say
> anything about the object here. there isn't a lot of point either.

I find it nice to have in cases where you want to query the object but 
not modify it. For example, but not only: when returning textblock 
cursors (assuming they were Eobj as well) from the textblock API...

But ok, if you think it's not needed ATM I'll just wait until I find a 
concrete use case.

Thanks for your comment.

--
Tom.


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Tue, 17 Apr 2012 09:50:19 +0300 Tom Hacohen  said:

i don't see the point. it's just a pointer to something. it's fine as-is. in
this way of doing an api we no longer can use the const attribute to say
anything about the object here. there isn't a lot of point either.

> Dear,
> 
> One more flaw I found (well actually Daniel found it):
> eobj_do accepts "Eobj *" which is obviously not const. This means that 
> eobj_do will always return a warning when passing const objects to it, 
> even if we just query it for information, without changing.
> This means that working with "cost Eobj *" will not be possible anymore.
> 
> I'm thinking about just adding eobj_query that will accept "const Eobj 
> *" and will only let you execute "const compatible" operations on it. 
> What do you think?
> 
> --
> Tom.
> 
> On 02/04/12 12:58, Tom Hacohen wrote:
> > Dear,
> >
> > As some of you may know, my team and I have been working on Eobj, a new
> > objecting system for EFL. The current concept of varargs and having
> > eobj_do (you'll see what I'm talking about) was suggested to me by
> > raster and cedric, but I believe someone else deserves the original
> > credit, so please, if you know who I should be giving credit to, let me
> > know.
> >
> > I uploaded my current Eobj code to:
> > http://www.enlightenment.org/~tasn/eobj.tgz
> > Please feel free to take a look at the "lib" and at the examples in the
> > examples dir. This example code uses cmake, because that's what I find
> > most comfortable to work with, but the final version will be integrated
> > into EFL and will use autotools, or in other words, please don't bother
> > commenting about the build system.
> >
> > It's done and can be integrated into the EFL except for a couple of
> > things that are not yet decided:
> > 1. Thaw/freeze are not implemented yet
> > * Do we want to be able to freeze per object or globally to all
> > objects?
> > * Do we want to be able to freeze per signal or just the whole
> > object? (freezing just per signal can be risky because there might be other
> > signals and applications that expect certain signal sequence and failing
> > to block all will cause inconsistencies).
> > 2. There are still some slow paths - will be fixed as needed.
> > 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
> > * I'm not sure yet about which kinds of refing we want. I'm pretty
> > certain we want named refs and "object" name refs (i.e linking between
> > objects). And I do believe we need weak ref/unref, but again not yet
> > decided.
> > 4. Many cases are not checked for validity and are just allowed. I plan
> > on having 2 modes, one for checking those, and the fast mode that will
> > just be fast. Possibly by having a compilation option + env var to turn
> > the checks on.
> > 5. No docs/proper internal naming yet, but API and examples should be solid.
> > 6. Currently the order of functions called is: object functions, mixin
> > functions and only then, composite object functions - should decide if
> > that's what we want. I like it.
> > 7. Mixin constructors are not called ATM.
> > * Will be fixed. The reason it was not done yet is that MIXINs are
> > 2nd rate citizens, as we don't yet have a use for them in the EFL.
> > 8. Currently only classes have data, not mixins. - Will be extended.
> > * I'm thinking about just letting them use the generic data and make
> > the common case faster...
> > 9. I plan on adding a signal indicating signal callbacks
> > addition/removal. - I.e you'll get a "some registered to 'resize' event"
> > signal.
> > * Very useful in many cases.
> > 10. Static class method IDs will be added soon.
> > * Raster suggested a cool idea that will help speed things up,
> > which is static IDs. It's not done yet, but it's 99% supported.
> > 11. Class type and all of that handling is not yet final.
> > * Currently you have a class type of either:
> > EOBJ_CLASS_TYPE_REGULAR, EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT,
> > EOBJ_CLASS_TYPE_INTERFACE, or EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we
> > need more, or if it should be ditched.
> > 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> > (I need a better name) function that will be called at the end of
> > eobj_do automatically. This will let us defer changes in an easier manner.
> > * I'm not sure about this one. In one hand, it makes it easier to
> > defer changes, though on the other, it's deference is not optimal, would
> > have been better to just create an infrastructure that will let us do better
> > deference of changes.
> > 13. Missing a way to group set/get.
> > * I plan on making a way to say "set and get both modify the same
> > property" which is not yet implemented.
> >
> > Please comment on the API (either the class API or the actual usage API)
> > and especially on the bullets I wrote above.
> >
> > Please also take a look at the elw_boxedbutton "widget" in the evas
> > example which shows t

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

Dear,

One more flaw I found (well actually Daniel found it):
eobj_do accepts "Eobj *" which is obviously not const. This means that 
eobj_do will always return a warning when passing const objects to it, 
even if we just query it for information, without changing.
This means that working with "cost Eobj *" will not be possible anymore.

I'm thinking about just adding eobj_query that will accept "const Eobj 
*" and will only let you execute "const compatible" operations on it. 
What do you think?

--
Tom.

On 02/04/12 12:58, Tom Hacohen wrote:
> Dear,
>
> As some of you may know, my team and I have been working on Eobj, a new
> objecting system for EFL. The current concept of varargs and having
> eobj_do (you'll see what I'm talking about) was suggested to me by
> raster and cedric, but I believe someone else deserves the original
> credit, so please, if you know who I should be giving credit to, let me
> know.
>
> I uploaded my current Eobj code to:
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the
> examples dir. This example code uses cmake, because that's what I find
> most comfortable to work with, but the final version will be integrated
> into EFL and will use autotools, or in other words, please don't bother
> commenting about the build system.
>
> It's done and can be integrated into the EFL except for a couple of
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>   * Do we want to be able to freeze per object or globally to all objects?
>   * Do we want to be able to freeze per signal or just the whole object?
> (freezing just per signal can be risky because there might be other
> signals and applications that expect certain signal sequence and failing
> to block all will cause inconsistencies).
> 2. There are still some slow paths - will be fixed as needed.
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>   * I'm not sure yet about which kinds of refing we want. I'm pretty
> certain we want named refs and "object" name refs (i.e linking between
> objects). And I do believe we need weak ref/unref, but again not yet
> decided.
> 4. Many cases are not checked for validity and are just allowed. I plan
> on having 2 modes, one for checking those, and the fast mode that will
> just be fast. Possibly by having a compilation option + env var to turn
> the checks on.
> 5. No docs/proper internal naming yet, but API and examples should be solid.
> 6. Currently the order of functions called is: object functions, mixin
> functions and only then, composite object functions - should decide if
> that's what we want. I like it.
> 7. Mixin constructors are not called ATM.
>   * Will be fixed. The reason it was not done yet is that MIXINs are 2nd
> rate citizens, as we don't yet have a use for them in the EFL.
> 8. Currently only classes have data, not mixins. - Will be extended.
>   * I'm thinking about just letting them use the generic data and make
> the common case faster...
> 9. I plan on adding a signal indicating signal callbacks
> addition/removal. - I.e you'll get a "some registered to 'resize' event"
> signal.
>   * Very useful in many cases.
> 10. Static class method IDs will be added soon.
>   * Raster suggested a cool idea that will help speed things up, which is
> static IDs. It's not done yet, but it's 99% supported.
> 11. Class type and all of that handling is not yet final.
>   * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR,
> EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, EOBJ_CLASS_TYPE_INTERFACE, or
> EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we need more, or if it should be
> ditched.
> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> (I need a better name) function that will be called at the end of
> eobj_do automatically. This will let us defer changes in an easier manner.
>   * I'm not sure about this one. In one hand, it makes it easier to defer
> changes, though on the other, it's deference is not optimal, would have
> been better to just create an infrastructure that will let us do better
> deference of changes.
> 13. Missing a way to group set/get.
>   * I plan on making a way to say "set and get both modify the same
> property" which is not yet implemented.
>
> Please comment on the API (either the class API or the actual usage API)
> and especially on the bullets I wrote above.
>
> Please also take a look at the elw_boxedbutton "widget" in the evas
> example which shows the API for handling composited objects.
>
> Also, we are also working on automatic eobj bindings generation for
> other languages, so if you have anything to comment on this matter as
> well, please do. I see this as one of the most important parts of this
> change.
>
> There is one noticeable hack in the evas example: the
> eobj_evas_object_set/get functions. They are only there because we don't
> currently use eobj in evas, but w

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 13/04/12 14:02, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen  said:
>
> i have some more things as my brain churned that i didn't add to my previous
> mail:
>
> 15. eobj_generic_data_* ... i really think this should support passing in a
> free func for generic data (NULL == dont free it), and previous egenric data 
> is
> auto-greed if u set new data on top, same when u del - dont bother returning
> the pointer to it except on get. ALSO for generic data - can u provide a TYPE
> param - string, opque, eobj, opaque list, object list etc. types. opaque is
> unknown to eobj, but string can be used to account for memory objects and eobj
> can be used to have eobj auto unref attached generic data if its another eobj
> or list of eobj's. this would come it very handy.

I thought about it, but it felt a bit fat to me... The problem is that 
we'd have to save a free function/NULL for every property which is kinda 
wasteful. Especially since you can in most cases just have a delete 
callback and free the properties from there. If you really think it's a 
must, I'll add it.
> 16. eobj_event_callback_add() can be a macro imho. :)

Done.
> 17. maybe we can shorten callback to cb for brevity, also other full words
> might be shorter? opinions? save typing? generic_data ->  gdata? ...

Perhaps, we just need to decide on better naming. :)
> 18. ok so we have callbacks that are of course called in-line in the stack. 
> i'm
> mulling over if we should use the same callback system to POST events
> (messages) on a queue and then to be able to process them later as part of the
> ecore event loop. you will have to register a message queueing func with eobj
> - but eobj can handle reffing the target obj whenever u pose a msg cb and
> unreffing when msg event is finished in the queue. this can definitely help 
> out
> here. now the obj can choose if it wants to call cb's inline or defer on the
> event queue... :) in fact this can even get quite smart - if in the mainloop 
> it
> queues, if from a thread.. it can use the ecore async infra to send the cb's 
> to
> the mainloop as messages... oooh baby... :)

The biggest advantage (and it's really big in my pov) with inline 
callbacks is that you don't have to allocate data on the heap for the 
event info, you can just allocate data on the stack. It's a big save 
code-wise, and I'm certain performance-wise as well. If you make it 
"dynamic" i.e decided by eobj, you'd have to allocate the data (as the 
callback call my be deferred) which is annoying. Also, signals in many 
cases cause resizes of other objects and deferring those means the code 
we write won't be able to get the up to date info, which is also annoying...
> 19. and speaking of threads... i am wondering if maybe.. just maybe... we 
> might
> not want to provide some locking/unlocking infra for eobj? it probably needs 
> to
> handle recursive locks WITHIN the same thread... :/ let the flames begin!

Nah. :)
> 20. pants on.

Never!

Thanks for reviewing. If you can, please also reply to the questions I 
asked in my first (and second?) posts. For example what I said about the 
"flush" function that we talked about the other day, but not only...

--
Tom.

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 13/04/12 13:17, Carsten Haitzler (The Rasterman) wrote:
> hey tom. some of these i already mentioned to you, but i'll repeat here for 
> the
> good of everyone following:

Yeah, I already fixed some of those just after we talked, but thanks. :)
>
> 1. eobj_data_get() inside the method funcs - please just pass the object class
> data as a pointer to the func - figured out in the handler parent as its more
> efficient. :)

Yeah, done. :)
> 2. passing "op" i think has dubious value. it allows you to implement multiple
> methods using a single function (and switch internally based on op id), BUT i
> think this is rare at best or not needed. frankly slapping __UNUSED__'s all
> thru these funcs is just going to be noisy and pointless. :)

Yep.
> 3. in examples/access... protected really is a pointless complication. it's
> private data and just as visible and modifiable as any other private data. :)

Nah, it's a good example. It's trivial to come up with the way to do it 
yourself, but having an example that does it exactly is good for people 
seeking for the right way of doing stuff.

> 4. aaah varags for list of parent classes... coolio. i was wondering how
> multi-inheritance was going to work.

Yeah. :)
> 5. just as examples, it might be nicer to use named field filling eg:
>
> static const Eobj_Class_Description class_desc = {
>  .name  = "Mixin",
>  .type  = EOBJ_CLASS_TYPE_MIXIN,
>  .ops   = EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID, 
> op_desc,
> MIXIN_SUB_ID_LAST),
>  .events= NULL,
>  .data_size = 0,
>  .constructor   = _constructor,
>  .destructor= _destructor,
>  .class_constructor = _class_constructor,
>  .class_destructor  = NULL
> };
>
> in fact for 0's or NULLS, just leave them out so its easier to read:
>
> static const Eobj_Class_Description class_desc = {
>  .name   = "Mixin",
>  .type   = EOBJ_CLASS_TYPE_MIXIN,
>  .ops= EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID,
> op_desc, MIXIN_SUB_ID_LAST),
>  .constructor= _constructor,
>  .destructor = _destructor,
>  .class_constructor  = _class_constructor,
> };
>
> it's easier to see the field name so u know what it is meant to be used for,
> and skipping "unused" things leads to less cruft to sift through.

I generally agree, but I consider the examples as something people 
should copy & paste from, or at least as test cases (I use them like 
that atm) so I want them to be cross-platform.
>
> 6. eobj.c could be split into class, base class, obj funcs and callback funcs.
> into 4 files. :)

Yeah, messy inside, I know. :)
> 7. eobj_super_do()... wtf?

I used "super" because that's the common naming for that (it's like that 
in python and java among others). It's just for calling the function of 
the super-class, or more correctly, the next on in the mro.

> 8. why is Eobj_Op a uintptr_t? not just an int? any good reason? varargs does
> take care of this for us... ? (and by that same token eobj_do should terminate
> with a: (Eobj_Op)0, not NULL) :)

No idea why I ever made it a uintptr_t, WTH. :) Fixed now.
> 9. imho u want to eobj_ref() and eobj_unref() inside many funcs like 
> eobj_do_()
> to keep a refcount as long as the func is doing things with the obj

You are right, fixed.
> 10. missing the abstraction funcs/macros to "get me the real object pointer
> from Eobj *obj". eg treat it as an id and look up in a table... or as
> a double-pointer etc. :) either way - an abstraction there to sanity check the
> obj ptr and get the REAL obj ptr from it. (theoretically that can be compiled
> into a NOP to just hand u the ptr as-is - but in real life it will be doing
> footwork to do indirect lookups as crash prevention).

Yeah, never got around to it, will do it when I implement the "id" 
system. It's internal anyway...
> 11. eobj_constructor_super()  eobj_destructor_super() ?? pls explain 
> :)

Same as #7, it's just a way to call the next function in the mro in the 
specific case of the constructors/destructors.
> 12. eobj_event_callback_*() - cool. i now raise the spectre of MAYBE 
> supporting
> closures. what in gods green earth would be a closure here? well it would just
> be a callback WHERE maybe we manage the func data for the app OR we add 
> another
> "environment" param. such an environment sould need to be freed for the app
> when cb is deleted (or obj is deleted that cb is on) and any objects 
> references
> from this environment automatically get reffed when added as a cb or unreffed
> later. how to achieve this - not sure. some way to declare the create the
> environment struct and declare what inside of it may be an object handle? this
> of course leads to uglies like lists, hashes or arrays of objects.. and we
> begin to look like eet... anyway - i'm just bringing this up as

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Fri, 13 Apr 2012 21:49:47 +0200 Jorge Luis Zapata Muga
 said:

> On Fri, Apr 13, 2012 at 12:45 PM, Carsten Haitzler 
> wrote:
> > On Thu, 12 Apr 2012 16:44:46 +0200 Jorge Luis Zapata Muga
> >  said:
> >
> >> Hello Tom,
> >>
> >> I haven't checked the code completely yet, don't have much time. Nice
> >> initiative to share the development process, does not happen very
> >> often ... but could you please share the "design decisions" you take
> >> with this new OO approach? (Not from a code POV).
> >
> > well i can answer that. we have a poor-mans object model up in the evas
> > layer - evas object + smart objects. this of course is limiting and doesnt
> > cover things like ecore (timers, animators and other things), and is
> > definitely way too heavy for such things as u need actual evas objects. it
> > also is relatively limited.
> >
> > over the years we have grown a kind-of object model here and many different
> > mechanisms to have callbacks called on objects. there are ecore event
> > handles, evas object event callbacks, evas smart callbacks, edje signal
> > callbacks, edje message callbacks... way way way too many different ways to
> > "get called when an event happens" each with different prototypes u have to
> > keep looking up. there is a lot more besides, and then there is elementary
> > which is in dire need of multiple inheritance for several situations. in
> > addition we have no current way to indirect object lookups to allow for
> > compaction and crash protection. the point of this is to fix all of that in
> > a simple base object system that also compacts our code and makes it easier
> > to write and maintain, allows for better optimisation and cuts the costs of
> > function entry that we currently have in doing magic type checks every func
> > call etc. - we can amortise than now over multiple operations. also now
> > string parent/child relationships so child object get deleted when parent
> > objects go away etc. but this happens all the way at the bottom of the efl
> > stack. not up in evas or elm land.
> 
> yes, true, is kind of complex to manage all such events, signals and
> objects on different libraries, but i suppose that if Elm would have
> been decided to build on top of such libs and not be part of the libs,
> i mean, hide evas, edje and ecore behind it, then this situation might
> be simpler to solve. dont want to sound like trolling here, but etk
> (maybe ewl too, dunno about it), did exactly that, someway it cloned
> the gobject system and managed to hide all the internals of the
> different core libraries, but it was doomed by the fact it wasnt using
> Evas_Objects (or smart objects) as its main object abstraction, but
> now such object system is required.

the etk/ewl approach imho just didn't work well as it had to wrap everything.
wrapping hurts. it just adds yet another layer that isn't really needed and
everything *INSIDE* the wrap just looks odd compared to outside. moving object
stuff all the way down the bottom stops that from happening. it will take a
while for code to migrate over internally but you have to start somewhere. you
will still have a wrapper layer that implements the current api for
compatibility, but that's a necessary evil.

> >> I'm asking because from the above comments you just explain what is
> >> *missing* on your implementation, but given that I started some years
> >> ago a project called "ekeko" (I think it is still under PROTO) which
> >> wanted to solve this problem too and recently I've been developing
> >> "ender" (which for me fits exactly on my OO needs), we might be
> >> sharing several goals, or maybe not ;)
> >
> > ender is close, but it's string based properties don't handle actual method
> > calls, and the strings hurt here. nice for higher up in the stack, but lower
> > down it will hurt performance-wise.
> 
> that's not accurate. ender does have, as you pointed out, a string
> based property system and you have functions to interact with the
> properties of an object using strings, like:
> ender_element_value_set(Ender_Element *e, const char *name, ...);
> which will imply a string -> property lookup, but you also have the
> simplest forms:
> ender_element_property_value_set(Ender_Element *e, Ender_Property
> *prop, ...); which receives the property directly and no need for a
> lookup, is just a matter to export on your lib such Ender_Property in
> a similar way that ecore exports its events, i.e extern Ender_Property
> * OBJECT_ID_PROP;

did you add that since i last looked maybe 2 or 3 months ago? i actually can't
remember where ender is. :) i don't remember seeing this. but also note that
eobj isnt property based. its still methods - but implemented vastly
differently gobject.

> but, beside the question if ender fits here or not, im wondering if
> the OO system is really needed as the base to build the core libraries

after some experience with people new to efl, i have seen LOTS of examples of
people using timers, animat

Re: [E-devel] Eobj - Request for review/comments

[Jorge Luis Zapata Muga]

On Fri, Apr 13, 2012 at 12:45 PM, Carsten Haitzler  wrote:
> On Thu, 12 Apr 2012 16:44:46 +0200 Jorge Luis Zapata Muga
>  said:
>
>> Hello Tom,
>>
>> I haven't checked the code completely yet, don't have much time. Nice
>> initiative to share the development process, does not happen very
>> often ... but could you please share the "design decisions" you take
>> with this new OO approach? (Not from a code POV).
>
> well i can answer that. we have a poor-mans object model up in the evas layer 
> -
> evas object + smart objects. this of course is limiting and doesnt cover 
> things
> like ecore (timers, animators and other things), and is definitely way too
> heavy for such things as u need actual evas objects. it also is relatively
> limited.
>
> over the years we have grown a kind-of object model here and many different
> mechanisms to have callbacks called on objects. there are ecore event handles,
> evas object event callbacks, evas smart callbacks, edje signal callbacks, edje
> message callbacks... way way way too many different ways to "get called when 
> an
> event happens" each with different prototypes u have to keep looking up. there
> is a lot more besides, and then there is elementary which is in dire need of
> multiple inheritance for several situations. in addition we have no current 
> way
> to indirect object lookups to allow for compaction and crash protection. the
> point of this is to fix all of that in a simple base object system that also
> compacts our code and makes it easier to write and maintain, allows for better
> optimisation and cuts the costs of function entry that we currently have in
> doing magic type checks every func call etc. - we can amortise than now over
> multiple operations. also now string parent/child relationships so child 
> object
> get deleted when parent objects go away etc. but this happens all the way at
> the bottom of the efl stack. not up in evas or elm land.

yes, true, is kind of complex to manage all such events, signals and
objects on different libraries, but i suppose that if Elm would have
been decided to build on top of such libs and not be part of the libs,
i mean, hide evas, edje and ecore behind it, then this situation might
be simpler to solve. dont want to sound like trolling here, but etk
(maybe ewl too, dunno about it), did exactly that, someway it cloned
the gobject system and managed to hide all the internals of the
different core libraries, but it was doomed by the fact it wasnt using
Evas_Objects (or smart objects) as its main object abstraction, but
now such object system is required.

>
>> I'm asking because from the above comments you just explain what is
>> *missing* on your implementation, but given that I started some years
>> ago a project called "ekeko" (I think it is still under PROTO) which
>> wanted to solve this problem too and recently I've been developing
>> "ender" (which for me fits exactly on my OO needs), we might be
>> sharing several goals, or maybe not ;)
>
> ender is close, but it's string based properties don't handle actual method
> calls, and the strings hurt here. nice for higher up in the stack, but lower
> down it will hurt performance-wise.

that's not accurate. ender does have, as you pointed out, a string
based property system and you have functions to interact with the
properties of an object using strings, like:
ender_element_value_set(Ender_Element *e, const char *name, ...);
which will imply a string -> property lookup, but you also have the
simplest forms:
ender_element_property_value_set(Ender_Element *e, Ender_Property
*prop, ...); which receives the property directly and no need for a
lookup, is just a matter to export on your lib such Ender_Property in
a similar way that ecore exports its events, i.e extern Ender_Property
* OBJECT_ID_PROP;

but, beside the question if ender fits here or not, im wondering if
the OO system is really needed as the base to build the core libraries
on top of it, I mean, given that Evas already has a kind-of-object
sytem, Ecore has the same thing with its events and different sub
systems, etc, or is better to wrap the already coded core libraries
into something more manageable from an application POV. But i guess
here that the real problem is Elm and its nature to be Evas Objects.

>
> so goals are:
>
> 1. unify callbacks into a single prototype
> 2. unify ref/unref/delete etc.
> 3. allow for multiple inheritance as well as single
> 4. break out the varargs to be able to cut the cost of object checks
> (magic/null etc.) over multiple operations all in 1 go
> 5. allow for greater object optimisations so you can create an object AND set
> all its initial state in 1 function call and thus avoid lots of needless state
> transitions as you set things up. its a much more compact way of doing
> freeze/thaw without the footwork
> 6. put in the layer to allow for object indirection so object pointers can
> become not just a pointer to the obj memory, but a double-indirect (obj **) 

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen  said:

i have some more things as my brain churned that i didn't add to my previous
mail:

15. eobj_generic_data_* ... i really think this should support passing in a
free func for generic data (NULL == dont free it), and previous egenric data is
auto-greed if u set new data on top, same when u del - dont bother returning
the pointer to it except on get. ALSO for generic data - can u provide a TYPE
param - string, opque, eobj, opaque list, object list etc. types. opaque is
unknown to eobj, but string can be used to account for memory objects and eobj
can be used to have eobj auto unref attached generic data if its another eobj
or list of eobj's. this would come it very handy.
16. eobj_event_callback_add() can be a macro imho. :)
17. maybe we can shorten callback to cb for brevity, also other full words
might be shorter? opinions? save typing? generic_data -> gdata? ...
18. ok so we have callbacks that are of course called in-line in the stack. i'm
mulling over if we should use the same callback system to POST events
(messages) on a queue and then to be able to process them later as part of the
ecore event loop. you will have to register a message queueing func with eobj
- but eobj can handle reffing the target obj whenever u pose a msg cb and
unreffing when msg event is finished in the queue. this can definitely help out
here. now the obj can choose if it wants to call cb's inline or defer on the
event queue... :) in fact this can even get quite smart - if in the mainloop it
queues, if from a thread.. it can use the ecore async infra to send the cb's to
the mainloop as messages... oooh baby... :)
19. and speaking of threads... i am wondering if maybe.. just maybe... we might
not want to provide some locking/unlocking infra for eobj? it probably needs to
handle recursive locks WITHIN the same thread... :/ let the flames begin!
20. pants on.

> Dear,
> 
> As some of you may know, my team and I have been working on Eobj, a new 
> objecting system for EFL. The current concept of varargs and having 
> eobj_do (you'll see what I'm talking about) was suggested to me by 
> raster and cedric, but I believe someone else deserves the original 
> credit, so please, if you know who I should be giving credit to, let me 
> know.
> 
> I uploaded my current Eobj code to: 
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the 
> examples dir. This example code uses cmake, because that's what I find 
> most comfortable to work with, but the final version will be integrated 
> into EFL and will use autotools, or in other words, please don't bother 
> commenting about the build system.
> 
> It's done and can be integrated into the EFL except for a couple of 
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>   * Do we want to be able to freeze per object or globally to all
> objects?
>   * Do we want to be able to freeze per signal or just the whole
> object? (freezing just per signal can be risky because there might be other 
> signals and applications that expect certain signal sequence and failing 
> to block all will cause inconsistencies).
> 2. There are still some slow paths - will be fixed as needed.
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>   * I'm not sure yet about which kinds of refing we want. I'm pretty 
> certain we want named refs and "object" name refs (i.e linking between 
> objects). And I do believe we need weak ref/unref, but again not yet 
> decided.
> 4. Many cases are not checked for validity and are just allowed. I plan 
> on having 2 modes, one for checking those, and the fast mode that will 
> just be fast. Possibly by having a compilation option + env var to turn 
> the checks on.
> 5. No docs/proper internal naming yet, but API and examples should be solid.
> 6. Currently the order of functions called is: object functions, mixin 
> functions and only then, composite object functions - should decide if 
> that's what we want. I like it.
> 7. Mixin constructors are not called ATM.
>   * Will be fixed. The reason it was not done yet is that MIXINs are
> 2nd rate citizens, as we don't yet have a use for them in the EFL.
> 8. Currently only classes have data, not mixins. - Will be extended.
>   * I'm thinking about just letting them use the generic data and make 
> the common case faster...
> 9. I plan on adding a signal indicating signal callbacks 
> addition/removal. - I.e you'll get a "some registered to 'resize' event" 
> signal.
>   * Very useful in many cases.
> 10. Static class method IDs will be added soon.
>   * Raster suggested a cool idea that will help speed things up, which
> is static IDs. It's not done yet, but it's 99% supported.
> 11. Class type and all of that handling is not yet final.
>   * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR, 
> EOBJ_CLASS_TYPE_REGULAR_NO_INS

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Thu, 12 Apr 2012 16:44:46 +0200 Jorge Luis Zapata Muga
 said:

> Hello Tom,
> 
> I haven't checked the code completely yet, don't have much time. Nice
> initiative to share the development process, does not happen very
> often ... but could you please share the "design decisions" you take
> with this new OO approach? (Not from a code POV).

well i can answer that. we have a poor-mans object model up in the evas layer -
evas object + smart objects. this of course is limiting and doesnt cover things
like ecore (timers, animators and other things), and is definitely way too
heavy for such things as u need actual evas objects. it also is relatively
limited.

over the years we have grown a kind-of object model here and many different
mechanisms to have callbacks called on objects. there are ecore event handles,
evas object event callbacks, evas smart callbacks, edje signal callbacks, edje
message callbacks... way way way too many different ways to "get called when an
event happens" each with different prototypes u have to keep looking up. there
is a lot more besides, and then there is elementary which is in dire need of
multiple inheritance for several situations. in addition we have no current way
to indirect object lookups to allow for compaction and crash protection. the
point of this is to fix all of that in a simple base object system that also
compacts our code and makes it easier to write and maintain, allows for better
optimisation and cuts the costs of function entry that we currently have in
doing magic type checks every func call etc. - we can amortise than now over
multiple operations. also now string parent/child relationships so child object
get deleted when parent objects go away etc. but this happens all the way at
the bottom of the efl stack. not up in evas or elm land.

> I'm asking because from the above comments you just explain what is
> *missing* on your implementation, but given that I started some years
> ago a project called "ekeko" (I think it is still under PROTO) which
> wanted to solve this problem too and recently I've been developing
> "ender" (which for me fits exactly on my OO needs), we might be
> sharing several goals, or maybe not ;)

ender is close, but it's string based properties don't handle actual method
calls, and the strings hurt here. nice for higher up in the stack, but lower
down it will hurt performance-wise.

so goals are:

1. unify callbacks into a single prototype
2. unify ref/unref/delete etc.
3. allow for multiple inheritance as well as single
4. break out the varargs to be able to cut the cost of object checks
(magic/null etc.) over multiple operations all in 1 go
5. allow for greater object optimisations so you can create an object AND set
all its initial state in 1 function call and thus avoid lots of needless state
transitions as you set things up. its a much more compact way of doing
freeze/thaw without the footwork
6. put in the layer to allow for object indirection so object pointers can
become not just a pointer to the obj memory, but a double-indirect (obj **) OR
even an ID lookup in a table which can allow for complete safety and zero
crashes in object access. as more safety here comes with more overhead - our
varargs fun lets us spread that cost out over maybe 3, 5 or 10 calls,
ultimately actually lowering our costs below what we currently have in efl.

bonuses:
7. we get some method introspection while we're at it
8. we get callback/signal documentation too from the base up (not just smart
callbacks on evas objects)
9. object indirection allows for memory compacting to kill off a lot of the
fragmentation i have seen crop up in apps (like e17) over time as it runs.
10. much better tracking of references


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (Carsten Haitzler)ras...@rasterman.com


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[The Rasterman]

On Mon, 02 Apr 2012 12:58:21 +0300 Tom Hacohen  said:

hey tom. some of these i already mentioned to you, but i'll repeat here for the
good of everyone following:

1. eobj_data_get() inside the method funcs - please just pass the object class
data as a pointer to the func - figured out in the handler parent as its more
efficient. :)
2. passing "op" i think has dubious value. it allows you to implement multiple
methods using a single function (and switch internally based on op id), BUT i
think this is rare at best or not needed. frankly slapping __UNUSED__'s all
thru these funcs is just going to be noisy and pointless. :)
3. in examples/access... protected really is a pointless complication. it's
private data and just as visible and modifiable as any other private data. :)
4. aaah varags for list of parent classes... coolio. i was wondering how
multi-inheritance was going to work.
5. just as examples, it might be nicer to use named field filling eg:

   static const Eobj_Class_Description class_desc = {
.name  = "Mixin",
.type  = EOBJ_CLASS_TYPE_MIXIN,
.ops   = EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID, op_desc,
MIXIN_SUB_ID_LAST),
.events= NULL,
.data_size = 0,
.constructor   = _constructor,
.destructor= _destructor,
.class_constructor = _class_constructor,
.class_destructor  = NULL
   };

in fact for 0's or NULLS, just leave them out so its easier to read:

   static const Eobj_Class_Description class_desc = {
.name   = "Mixin",
.type   = EOBJ_CLASS_TYPE_MIXIN,
.ops= EOBJ_CLASS_DESCRIPTION_OPS(&MIXIN_BASE_ID,
op_desc, MIXIN_SUB_ID_LAST),
.constructor= _constructor,
.destructor = _destructor,
.class_constructor  = _class_constructor,
   };

it's easier to see the field name so u know what it is meant to be used for,
and skipping "unused" things leads to less cruft to sift through.

6. eobj.c could be split into class, base class, obj funcs and callback funcs.
into 4 files. :)
7. eobj_super_do()... wtf?
8. why is Eobj_Op a uintptr_t? not just an int? any good reason? varargs does
take care of this for us... ? (and by that same token eobj_do should terminate
with a: (Eobj_Op)0, not NULL) :)
9. imho u want to eobj_ref() and eobj_unref() inside many funcs like eobj_do_()
to keep a refcount as long as the func is doing things with the obj
10. missing the abstraction funcs/macros to "get me the real object pointer
from Eobj *obj". eg treat it as an id and look up in a table... or as
a double-pointer etc. :) either way - an abstraction there to sanity check the
obj ptr and get the REAL obj ptr from it. (theoretically that can be compiled
into a NOP to just hand u the ptr as-is - but in real life it will be doing
footwork to do indirect lookups as crash prevention).
11. eobj_constructor_super()  eobj_destructor_super() ?? pls explain :)
12. eobj_event_callback_*() - cool. i now raise the spectre of MAYBE supporting
closures. what in gods green earth would be a closure here? well it would just
be a callback WHERE maybe we manage the func data for the app OR we add another
"environment" param. such an environment sould need to be freed for the app
when cb is deleted (or obj is deleted that cb is on) and any objects references
from this environment automatically get reffed when added as a cb or unreffed
later. how to achieve this - not sure. some way to declare the create the
environment struct and declare what inside of it may be an object handle? this
of course leads to uglies like lists, hashes or arrays of objects.. and we
begin to look like eet... anyway - i'm just bringing this up as a possible topic
of discussion.
13. instead of walking_list in obj - use ref/unref? (as above). 1 less base obj
member too.
14. umm stuff. (sorry drawn a blank here).

:)

> Dear,
> 
> As some of you may know, my team and I have been working on Eobj, a new 
> objecting system for EFL. The current concept of varargs and having 
> eobj_do (you'll see what I'm talking about) was suggested to me by 
> raster and cedric, but I believe someone else deserves the original 
> credit, so please, if you know who I should be giving credit to, let me 
> know.
> 
> I uploaded my current Eobj code to: 
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the 
> examples dir. This example code uses cmake, because that's what I find 
> most comfortable to work with, but the final version will be integrated 
> into EFL and will use autotools, or in other words, please don't bother 
> commenting about the build system.
> 
> It's done and can be integrated into the EFL except for a couple of 
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>   * Do we want to be able to freeze per object or 

Re: [E-devel] Eobj - Request for review/comments

[Jorge Luis Zapata Muga]

On Mon, Apr 2, 2012 at 11:58 AM, Tom Hacohen  wrote:
> Dear,
>
> As some of you may know, my team and I have been working on Eobj, a new
> objecting system for EFL. The current concept of varargs and having
> eobj_do (you'll see what I'm talking about) was suggested to me by
> raster and cedric, but I believe someone else deserves the original
> credit, so please, if you know who I should be giving credit to, let me
> know.
>
> I uploaded my current Eobj code to:
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the
> examples dir. This example code uses cmake, because that's what I find
> most comfortable to work with, but the final version will be integrated
> into EFL and will use autotools, or in other words, please don't bother
> commenting about the build system.
>
> It's done and can be integrated into the EFL except for a couple of
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>        * Do we want to be able to freeze per object or globally to all 
> objects?
>        * Do we want to be able to freeze per signal or just the whole object?
> (freezing just per signal can be risky because there might be other
> signals and applications that expect certain signal sequence and failing
> to block all will cause inconsistencies).
> 2. There are still some slow paths - will be fixed as needed.
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>        * I'm not sure yet about which kinds of refing we want. I'm pretty
> certain we want named refs and "object" name refs (i.e linking between
> objects). And I do believe we need weak ref/unref, but again not yet
> decided.
> 4. Many cases are not checked for validity and are just allowed. I plan
> on having 2 modes, one for checking those, and the fast mode that will
> just be fast. Possibly by having a compilation option + env var to turn
> the checks on.
> 5. No docs/proper internal naming yet, but API and examples should be solid.
> 6. Currently the order of functions called is: object functions, mixin
> functions and only then, composite object functions - should decide if
> that's what we want. I like it.
> 7. Mixin constructors are not called ATM.
>        * Will be fixed. The reason it was not done yet is that MIXINs are 2nd
> rate citizens, as we don't yet have a use for them in the EFL.
> 8. Currently only classes have data, not mixins. - Will be extended.
>        * I'm thinking about just letting them use the generic data and make
> the common case faster...
> 9. I plan on adding a signal indicating signal callbacks
> addition/removal. - I.e you'll get a "some registered to 'resize' event"
> signal.
>        * Very useful in many cases.
> 10. Static class method IDs will be added soon.
>        * Raster suggested a cool idea that will help speed things up, which is
> static IDs. It's not done yet, but it's 99% supported.
> 11. Class type and all of that handling is not yet final.
>        * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR,
> EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, EOBJ_CLASS_TYPE_INTERFACE, or
> EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we need more, or if it should be
> ditched.
> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> (I need a better name) function that will be called at the end of
> eobj_do automatically. This will let us defer changes in an easier manner.
>        * I'm not sure about this one. In one hand, it makes it easier to defer
> changes, though on the other, it's deference is not optimal, would have
> been better to just create an infrastructure that will let us do better
> deference of changes.
> 13. Missing a way to group set/get.
>        * I plan on making a way to say "set and get both modify the same
> property" which is not yet implemented.
>
> Please comment on the API (either the class API or the actual usage API)
> and especially on the bullets I wrote above.
>
> Please also take a look at the elw_boxedbutton "widget" in the evas
> example which shows the API for handling composited objects.
>
> Also, we are also working on automatic eobj bindings generation for
> other languages, so if you have anything to comment on this matter as
> well, please do. I see this as one of the most important parts of this
> change.
>
> There is one noticeable hack in the evas example: the
> eobj_evas_object_set/get functions. They are only there because we don't
> currently use eobj in evas, but will be fixed "automatically" once we do.
>
> Bug reports, comments, suggestions, or whatever are more than welcomed!

Hello Tom,

I haven't checked the code completely yet, don't have much time. Nice
initiative to share the development process, does not happen very
often ... but could you please share the "design decisions" you take
with this new OO approach? (Not from a code POV).

I'm asking because from the above comments you just explain what is
*missing* on your implementati

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

Hey,

Thanks a lot for reviewing and sorry for the late reply, I was AFK for a 
couple of days.



On 08/04/12 10:59, Vincent Torri wrote:
> eobj.h -->  Eobj.h (like all other EFL)
> missing EAPI definition in eobj.h

Thanks. It evolved out of a POC so I a lot is bad in that regard. :)
I renamed eobj.h, but I don't see any missing EAPI. Maybe you reviewed a 
very old version of the code?
>
> eina_log.h inclusion useless in eobj.c

Removed that, thanks.
> missing EAPI in front of eobj_ref() in eobj.c

Fixed.
> I like to give a namespace to variables even if they are static (like
> classes  -->  _eobj_classes, same for classes_last_id. You did it for
> the log domain, so do it for the others)
I don't care one way or the other, but I changed it.

> missing _ in front of eobj_class_constructor() and _eobj_class_destructor()

Yes, I know, the reason is that I recently changed them to static and I 
haven't decided yet. It's not a strict convention anyway, so I didn't 
bother until I really decide.

> wrong indentation
> struct {   should be :
> struct
> {

Oops, yeah, did it wrong there.
>
> better organise eobj.c (a bit messy). In order:
>
> macro
> typedef
> struct
> static functions
> API

Yes, should be played with a bit, I know.
>
> same for eobj.h (without static fcts of course)

I know.

As I said in my first email, internally it's a bit messy.
>
> question : why
>
> struct _Eobj
> {
>Eobj *parent;
>   ***
> };
>
> instead of
>
> struct _Eobj
> {
>Eobj parent;
>***
> };

It's a pointer to the parent object in the hierarchy, not "struct 
inheritance". As you can see, it's of the same type of the struct 
itself, making it Eobj parent doesn't make sense and won't even compile.

> it should compile on Windows at first sight
>

That's what I think as well. Lets hope/test. :)

Thanks a lot for your review.

--
Tom.

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

On Mon, Apr 2, 2012 at 11:58 AM, Tom Hacohen  wrote:
>
> Bug reports, comments, suggestions, or whatever are more than welcomed!

eobj.h --> Eobj.h (like all other EFL)
missing EAPI definition in eobj.h

eina_log.h inclusion useless in eobj.c
missing EAPI in front of eobj_ref() in eobj.c
I like to give a namespace to variables even if they are static (like
classes  --> _eobj_classes, same for classes_last_id. You did it for
the log domain, so do it for the others)
missing _ in front of eobj_class_constructor() and _eobj_class_destructor()
wrong indentation
struct {   should be :
struct
{

better organise eobj.c (a bit messy). In order:

macro
typedef
struct
static functions
API

same for eobj.h (without static fcts of course)

question : why

struct _Eobj
{
  Eobj *parent;
 ***
};

instead of

struct _Eobj
{
  Eobj parent;
  ***
};

?

it should compile on Windows at first sight

Vincent

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

Yeah, we got it. You say it so muxh that it's all I think about nowadays. I
can't commit without having flashbacks of you saying it...
On Apr 6, 2012 11:06 AM, "Vincent Torri"  wrote:

> On Fri, Apr 6, 2012 at 9:58 AM, Tom Hacohen  wrote:
> > Yeah, no need to worry. As I said, it'll use whatever we use.
>
> yep. And i'll leave if cmake is used, as i've said before.
>
> Vincent
>
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 05/04/12 20:35, Vincent Torri wrote:
> On Thu, Apr 5, 2012 at 7:28 PM, Tom Hacohen  wrote:
>> I specifically asked not to comment on the build system. More than that,
>> that request was made only because of you. Please try showing a bit of
>> restraint.
> 
> it has hit svn... even if it's in PROTO...

Ecrire has also hit SVN. I get you are enjoying your little veto on
build tools in EFL, but this is going a bit too far to my taste... Don't
you agree?
> 
>> When this code gets into somewhere stable, it'll use whatever build
>> system we'll decide to use (to follow the rest of the efl) be it
>> autotools or cmake.
> 
> thanks for clarifying

>From your response it seems that you got me a bit wrong, what I meant:
don't worry, it'll use whatever we use in the rest of the EFL when the
time comes.

--
Tom.


--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

I specifically asked not to comment on the build system. More than that,
that request was made only because of you. Please try showing a bit of
restraint.

When this code gets into somewhere stable, it'll use whatever build
system we'll decide to use (to follow the rest of the efl) be it
autotools or cmake.

--
Tom.

On 05/04/12 19:27, Vincent Torri wrote:
> build system
> 
> On Thu, Apr 5, 2012 at 5:42 PM, Tom Hacohen  wrote:
>> Hey all,
>>
>> Updates:
>> I've committed the code to
>> http://svn.enlightenment.org/svn/e/trunk/PROTO/eobj/ feel free to tinker
>> with it. :)
>>
>> I changed some things since the last snapshot. I changed the API of some
>> things that weren't perfect, improved the examples, fixed some bugs and
>> generally made things better.
>>
>> As for the list of issues/questions, I finished 7 and 9.
>>
>> --
>> Tom.
>>
>> --
>> Better than sec? Nothing is better than sec when it comes to
>> monitoring Big Data applications. Try Boundary one-second
>> resolution app monitoring today. Free.
>> http://p.sf.net/sfu/Boundary-dev2dev
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> --
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second 
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

build system

On Thu, Apr 5, 2012 at 5:42 PM, Tom Hacohen  wrote:
> Hey all,
>
> Updates:
> I've committed the code to
> http://svn.enlightenment.org/svn/e/trunk/PROTO/eobj/ feel free to tinker
> with it. :)
>
> I changed some things since the last snapshot. I changed the API of some
> things that weren't perfect, improved the examples, fixed some bugs and
> generally made things better.
>
> As for the list of issues/questions, I finished 7 and 9.
>
> --
> Tom.
>
> --
> Better than sec? Nothing is better than sec when it comes to
> monitoring Big Data applications. Try Boundary one-second
> resolution app monitoring today. Free.
> http://p.sf.net/sfu/Boundary-dev2dev
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

Hey all,

Updates:
I've committed the code to 
http://svn.enlightenment.org/svn/e/trunk/PROTO/eobj/ feel free to tinker 
with it. :)

I changed some things since the last snapshot. I changed the API of some 
things that weren't perfect, improved the examples, fixed some bugs and 
generally made things better.

As for the list of issues/questions, I finished 7 and 9.

--
Tom.

--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 02/04/12 14:55, Vincent Torri wrote:
> -ansi : c89
> -pedantic : no gnu extension
>
> so -pedantic can be used

Yeah, but I thought you meant you want me to use both... :) Well, with 
-pedantic it compiles with the same warnings as the rest of the efl, so 
that's fine, I guess. I got:
"warning: ISO C99 requires rest arguments to be used [enabled by default]"
and
"warning: type of bit-field ‘delete_me’ is a GCC extension [-pedantic]"

When compiling with -std=c99 -pedantic.

> i don't think so :) not in evil to edje + efreet. And i don't think
> that elm has a lot of that.
>

One is enough. :)



Again, thanks a lot.

--
Tom.


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

On Mon, Apr 2, 2012 at 1:50 PM, Tom Hacohen  wrote:
> On 02/04/12 14:47, Vincent Torri wrote:
>>
>> that's supported
>
>
> Yep, was explaining why I couldn't compile with -pedantic -ansi, not why I
> think vc++ won't work (I think/hope it will).

-ansi : c89
-pedantic : no gnu extension

so -pedantic can be used

>
>
>>
>> we can fix that, not a problem
>
>
> We do that all over the EFL, but yeah, that can be fixed.

i don't think so :) not in evil to edje + efreet. And i don't think
that elm has a lot of that.

>> i'll check if i have time. which are the deps ?
>
>
> Eina for eobj and all the examples except the evas one. If you want the evas
> example, you'd need elm and it's deps.

ok

Vincent

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 02/04/12 14:50, Tom Hacohen wrote:
> On 02/04/12 14:47, Vincent Torri wrote:
>> that's supported
>
> Yep, was explaining why I couldn't compile with -pedantic -ansi, not why
> I think vc++ won't work (I think/hope it will).
>
>>
>> we can fix that, not a problem
>
> We do that all over the EFL, but yeah, that can be fixed.
>
>> i'll check if i have time. which are the deps ?
>
> Eina for eobj and all the examples except the evas one. If you want the
> evas example, you'd need elm and it's deps.

Thanks btw, for both showing your interest and offering your help.

--
Tom.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 02/04/12 14:47, Vincent Torri wrote:
> that's supported

Yep, was explaining why I couldn't compile with -pedantic -ansi, not why 
I think vc++ won't work (I think/hope it will).

>
> we can fix that, not a problem

We do that all over the EFL, but yeah, that can be fixed.

> i'll check if i have time. which are the deps ?

Eina for eobj and all the examples except the evas one. If you want the 
evas example, you'd need elm and it's deps.

--
Tom.

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

On Mon, Apr 2, 2012 at 1:39 PM, Tom Hacohen  wrote:
> On 02/04/12 14:37, Vincent Torri wrote:
>>
>> which C99 features ? If vc++ can't compile it, i'll really remove that
>> compiler support (only pb with ecore_getopt and vc++, currently)
>
>
> Mostly things that are used in other places of the efl:
> variadic macros,

that's supported

> declaring variables not at the start of a code block,

we can fix that, not a problem

> and possibly other things, I'm not sure.

i'll check if i have time. which are the deps ?

Vincent

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

CC to list.

On 02/04/12 14:39, Tom Hacohen wrote:
> On 02/04/12 14:37, Vincent Torri wrote:
>> which C99 features ? If vc++ can't compile it, i'll really remove that
>> compiler support (only pb with ecore_getopt and vc++, currently)
>
> Mostly things that are used in other places of the efl:
> variadic macros, declaring variables not at the start of a code block,
> and possibly other things, I'm not sure.
>
> Best way I guess, is to compile and check, but I don't have MSVC available.
>
> I'd like to support VC++, so please, let me know if I did anything wrong
> on that regard, and I'll fix it.
>
> --
> Tom.


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Tom Hacohen]

On 02/04/12 13:24, Vincent Torri wrote:
> does it compile and work on windows ? if it compiles with "-ansi
> -pedantic", there will be good chances that it will work.
>

I can't compile with -ansi -pedantic because I rely on C99 features. The 
only important part is the 1 c file in the lib dir (and possibly one 
random example), if you can check those, that would be great. (You 
wouldn't have to use cmake...).

--
Tom.


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eobj - Request for review/comments

[Vincent Torri]

does it compile and work on windows ? if it compiles with "-ansi
-pedantic", there will be good chances that it will work.

Vincent

On Mon, Apr 2, 2012 at 11:58 AM, Tom Hacohen  wrote:
> Dear,
>
> As some of you may know, my team and I have been working on Eobj, a new
> objecting system for EFL. The current concept of varargs and having
> eobj_do (you'll see what I'm talking about) was suggested to me by
> raster and cedric, but I believe someone else deserves the original
> credit, so please, if you know who I should be giving credit to, let me
> know.
>
> I uploaded my current Eobj code to:
> http://www.enlightenment.org/~tasn/eobj.tgz
> Please feel free to take a look at the "lib" and at the examples in the
> examples dir. This example code uses cmake, because that's what I find
> most comfortable to work with, but the final version will be integrated
> into EFL and will use autotools, or in other words, please don't bother
> commenting about the build system.
>
> It's done and can be integrated into the EFL except for a couple of
> things that are not yet decided:
> 1. Thaw/freeze are not implemented yet
>        * Do we want to be able to freeze per object or globally to all 
> objects?
>        * Do we want to be able to freeze per signal or just the whole object?
> (freezing just per signal can be risky because there might be other
> signals and applications that expect certain signal sequence and failing
> to block all will cause inconsistencies).
> 2. There are still some slow paths - will be fixed as needed.
> 3. I'm still uncertain about ref/unref + weak-ref + named-ref.
>        * I'm not sure yet about which kinds of refing we want. I'm pretty
> certain we want named refs and "object" name refs (i.e linking between
> objects). And I do believe we need weak ref/unref, but again not yet
> decided.
> 4. Many cases are not checked for validity and are just allowed. I plan
> on having 2 modes, one for checking those, and the fast mode that will
> just be fast. Possibly by having a compilation option + env var to turn
> the checks on.
> 5. No docs/proper internal naming yet, but API and examples should be solid.
> 6. Currently the order of functions called is: object functions, mixin
> functions and only then, composite object functions - should decide if
> that's what we want. I like it.
> 7. Mixin constructors are not called ATM.
>        * Will be fixed. The reason it was not done yet is that MIXINs are 2nd
> rate citizens, as we don't yet have a use for them in the EFL.
> 8. Currently only classes have data, not mixins. - Will be extended.
>        * I'm thinking about just letting them use the generic data and make
> the common case faster...
> 9. I plan on adding a signal indicating signal callbacks
> addition/removal. - I.e you'll get a "some registered to 'resize' event"
> signal.
>        * Very useful in many cases.
> 10. Static class method IDs will be added soon.
>        * Raster suggested a cool idea that will help speed things up, which is
> static IDs. It's not done yet, but it's 99% supported.
> 11. Class type and all of that handling is not yet final.
>        * Currently you have a class type of either: EOBJ_CLASS_TYPE_REGULAR,
> EOBJ_CLASS_TYPE_REGULAR_NO_INSTANT, EOBJ_CLASS_TYPE_INTERFACE, or
> EOBJ_CLASS_TYPE_MIXIN. I'm not sure if we need more, or if it should be
> ditched.
> 12. Missing a flush function after eobj_do. - I plan on adding a "flush"
> (I need a better name) function that will be called at the end of
> eobj_do automatically. This will let us defer changes in an easier manner.
>        * I'm not sure about this one. In one hand, it makes it easier to defer
> changes, though on the other, it's deference is not optimal, would have
> been better to just create an infrastructure that will let us do better
> deference of changes.
> 13. Missing a way to group set/get.
>        * I plan on making a way to say "set and get both modify the same
> property" which is not yet implemented.
>
> Please comment on the API (either the class API or the actual usage API)
> and especially on the bullets I wrote above.
>
> Please also take a look at the elw_boxedbutton "widget" in the evas
> example which shows the API for handling composited objects.
>
> Also, we are also working on automatic eobj bindings generation for
> other languages, so if you have anything to comment on this matter as
> well, please do. I see this as one of the most important parts of this
> change.
>
> There is one noticeable hack in the evas example: the
> eobj_evas_object_set/get functions. They are only there because we don't
> currently use eobj in evas, but will be fixed "automatically" once we do.
>
> Bug reports, comments, suggestions, or whatever are more than welcomed!
>
> --
> Tom.
>
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
> _