Re: [E-devel] efl interfaces -> generic messaging

[The Rasterman]

On Fri, 11 Mar 2016 16:06:30 -0800 Cedric BAIL  said:

> Oh, that's a massive mail !

sorry - i'm brain dumping and trying to fill everyone in. i'm reaching out for
input and i want to at least express as much as possible for people to have a
good idea.

> On Fri, Mar 11, 2016 at 1:38 AM, Carsten Haitzler 
> wrote:
> > so ... something that was discussed was the idea of generic messaging for
> > objects. We have this already in EFl in 3 forms:
> >
> > 1. ecore events (anyone can allocate/create a new event type and set up a
> > handler)
> >
> > 2. evas smart object callbacks (any smart object can have anyone call the
> > smart callback by string name and thus it can be created ad-hoc and
> > listened to by anyone who can access the object).
> >
> > 3. edje signals (a signal string and a source string) that anyone can emit
> > on an edje object (and the edje edc can emit and listen to too) and any one
> > can listen to if they have the edje object - also this is exposed in elm
> > widgets too)
> 
> Edje signal will need to be manually binded anyway. So we can ignore
> them for the future of this discussion. And it is fine as this is just
> one more callback infrastructure. Problem shows up when we have to
> bind large number of function signature.

oh i'm not thinking of using this for edje signals - but i was just talking
about the whole functionality/way they work being something this does too if it
can do async messages within a thread (as that's how edje signals work - async
in a queue, processed later). just saying that the concept has been used before
on a large scale and this can fit into the same concept.

> [snip]
> 
> > there are 2 ways to see messages. synchronous and asynchronous.
> >
> > async messages are actually how edje implements signals right now within the
> > mainloop. async messages are also the best way for one loop to message
> > another simply by sending a message over (adding it to a queue on the
> > target loop) and triggering a wakeup on the loop if needed. this is also a
> > great way to "replace" ecore events with the ability to create new "global
> > messages on the mainloop" that anyone who knows the message id info can
> > listen to WITHIN a single loop context, not just between loops.
> >
> > sync messages are very much the smart callback replacement which when you
> > call (send) the message all callbacks are called "in-line" and by the time
> > your send/call func returns, all callbacks that listen for messages have
> > been called and are done. in addition to this due to some comments/requests
> > it would be GOOD to allow messages to propagate around the object tree. for
> > example they should be able to propagate to parent objects (optionally) and
> > optionally also down the tree to children. should this also work with async
> > messages? good question. it's a lot more painful to do.
> 
> It is also to be said that we can implement async message on top of
> sync message by either triggering them in a job or after a thread
> execution.

i was thinking the message impl will "do this for yu" and you dont need to set
up a job in the callback and duplicate the message content for the job etc.
etc. :)

> > so here come questions for all
> >
> > messages are SO useful that imho they belong in the eo base class. we have
> > string key -> void * tags on every object because they are so useful. (in
> > fact we should add/augment these to be able to do eo object references in
> > keys directly and automatically ref/unref the object stored in the key -
> > this would save a lot of maintenance code handling this in apps and allow
> > tagged key-value objects to be auto-freed when their reference goes away or
> > the object owning it does - but that is another topic).
> >
> > so i think i should add this to base. i see few if any objects that
> > could/would/should not use this. in fact if we provide propagation around an
> > object tree then you want all objects to do this because it otherwise can
> > break the tree when propagating when one object in the tree can't do
> > messages.
> >
> > so - any objections to this being in base. the value imho is far greater to
> > be here than splitting it out to another class.
> 
> Well, you have not discussed the main issue that we still don't know
> how to handle. How do you describe the structure passed as a parameter
> to this generic message ? If you don't, then there is no need to do

e... i described it already. in this mail.

{
  Eo *src;
  struct {
const char *str;
int id;
  } head;
  struct {
const char *str;
Eo *obj;
  } data;
};

that's the event info - done like all other event info. if you need to get more
complex that's what data.obj is for. you can create an object and have a whole
class with properties and interfaces and more. in future we could create
"database" objects - objects that can store and retrieve complex data. for MOSt
uses the data.str will do.

> 

Re: [E-devel] efl interfaces -> generic messaging

[Cedric BAIL]

Oh, that's a massive mail !

On Fri, Mar 11, 2016 at 1:38 AM, Carsten Haitzler  wrote:
> so ... something that was discussed was the idea of generic messaging for
> objects. We have this already in EFl in 3 forms:
>
> 1. ecore events (anyone can allocate/create a new event type and set up a
> handler)
>
> 2. evas smart object callbacks (any smart object can have anyone call the
> smart callback by string name and thus it can be created ad-hoc and listened 
> to
> by anyone who can access the object).
>
> 3. edje signals (a signal string and a source string) that anyone can emit on
> an edje object (and the edje edc can emit and listen to too) and any one can
> listen to if they have the edje object - also this is exposed in elm widgets
> too)

Edje signal will need to be manually binded anyway. So we can ignore
them for the future of this discussion. And it is fine as this is just
one more callback infrastructure. Problem shows up when we have to
bind large number of function signature.

[snip]

> there are 2 ways to see messages. synchronous and asynchronous.
>
> async messages are actually how edje implements signals right now within the
> mainloop. async messages are also the best way for one loop to message another
> simply by sending a message over (adding it to a queue on the target loop) and
> triggering a wakeup on the loop if needed. this is also a great way to
> "replace" ecore events with the ability to create new "global messages on the
> mainloop" that anyone who knows the message id info can listen to WITHIN a
> single loop context, not just between loops.
>
> sync messages are very much the smart callback replacement which when you call
> (send) the message all callbacks are called "in-line" and by the time your
> send/call func returns, all callbacks that listen for messages have been 
> called
> and are done. in addition to this due to some comments/requests it would be
> GOOD to allow messages to propagate around the object tree. for example they
> should be able to propagate to parent objects (optionally) and optionally also
> down the tree to children. should this also work with async messages? good
> question. it's a lot more painful to do.

It is also to be said that we can implement async message on top of
sync message by either triggering them in a job or after a thread
execution.

> so here come questions for all
>
> messages are SO useful that imho they belong in the eo base class. we have
> string key -> void * tags on every object because they are so useful. (in fact
> we should add/augment these to be able to do eo object references in keys
> directly and automatically ref/unref the object stored in the key - this would
> save a lot of maintenance code handling this in apps and allow tagged 
> key-value
> objects to be auto-freed when their reference goes away or the object owning 
> it
> does - but that is another topic).
>
> so i think i should add this to base. i see few if any objects that
> could/would/should not use this. in fact if we provide propagation around an
> object tree then you want all objects to do this because it otherwise can 
> break
> the tree when propagating when one object in the tree can't do messages.
>
> so - any objections to this being in base. the value imho is far greater to be
> here than splitting it out to another class.

Well, you have not discussed the main issue that we still don't know
how to handle. How do you describe the structure passed as a parameter
to this generic message ? If you don't, then there is no need to do
anything big. We could just add an simple function to register new
event from a string name and return a pointer to this new
Eo_Event_Description. That's it. If we want to have binding support,
we need to describe the data passed along that event. No idea how to
do so at all.

> now for async vs sync. the base class implementation would make all messages 
> by
> default be synchronous. it would simply call the event callback for messages
> directly when sent and if propagation is enabled, propagate to 
> parents/children
> (and avoid loops ... i'm mulling how to do this - as long as you only 
> propagate
> one way it's not a problem).
>
> objects like the mainloop will override the message calls and make messages
> ASYNC by default because you really need to if you are sending from one loop 
> in
> one thread to another. any object that needs or thinks async messages are
> better will override. we can have a class anyone who wants mainloop driven
> async messages can inherit from to get the implementation. the message apis 
> can
> have a a property to query if the messages are sync or async.

Maybe not, you could just rely on loop.begin/loop.end and send the
message in between those call. Arguably you could have that code
directly inside an overrided eo_callback_call and enforce the
begin/end, something like :

Eina_Bool
efl_loop_eo_callback_call(loop, event, data)
{
   efl_loop_begin(loop);
   

Re: [E-devel] Eo: Changes to syntax

[David Seikel]

On Fri, 11 Mar 2016 12:28:19 + Tom Hacohen 
wrote:

> On 09/03/16 16:23, Tom Hacohen wrote:
> > On 03/03/16 10:22, Tom Hacohen wrote:
> >> On 01/03/16 09:05, Tom Hacohen wrote:
> >>> Hey,
> >>>
> >>> The Eo syntax is going to be changing once more, and this time, I
> >>> really think/hope it'll be the last time. We plan on stabilizing
> >>> Eo and all of the functions on top of it in the next few months,
> >>> so that doesn't leave us much more time to change it again. :)
> >>>
> >>> These changes will remove the need for the eo_do family of
> >>> functions. Functions will now look like normal C functions (which
> >>> they are). There are many benefits to that, and we have many cool
> >>> new ideas.
> >>>
> >>> For more info: https://phab.enlightenment.org/w/eo/
> >>>
> >>> I'm sending this email as an head's up, as I'll be starting to
> >>> work on migrating to the new Eo syntax (and implementing it)
> >>> today. Felipe and I have actually already started (needed to for
> >>> the PoC), but I plan on pushing my changes to master soon.
> >>>
> >>> If you have any issues/suggestions/comments with the proposal,
> >>> please let me know, either in pm, irc or just here.
> >>>
> >>
> >> Changes are in! I still haven't migrated eo_add to the new syntax
> >> (it uses a non portable gcc extension in the meanwhile), but
> >> otherwise everything is in. Took me *much* less time than I
> >> thought it would, so yay. :P
> >>
> >> I decided to push it now instead of letting it rest in my branch
> >> for a while because literally every hour that passed introduced
> >> more merge conflicts for me, so the benefits from stabilising it
> >> more in my branch were diminished by the new conflicts and issues
> >> that could arise.
> >>
> >> If you have an application that uses the Eo api, you can use my
> >> script https://devs.enlightenment.org/~tasn/migrate_eo.py to
> >> migrate your code. When using the script you should keep two
> >> things in mind: 1. You are only allowed to run it *once* per
> >> source code, because the changes to eo_add() would otherwise
> >> accumulate and your code will be wrong. If you need to correct
> >> something you've done wrong, reset the code to the previous state
> >> and run the script again on the original code. 2. The migration
> >> script is not perfect. In particular it can't deal with some
> >> corner cases like: eo_do(obj, a_set(1),
> >> /* b_set(2),
> >>   g_set(4), */
> >>c_set(2));
> >> Or abominations like:
> >> eo_do(obj, if (a_get())
> >>do_something());
> >>
> >> So please be aware of that and *manually* review your changes
> >> after the script has run.
> >>
> >> If your code does have these cases, I recommend you either get rid
> >> of them, or manually migrate that code before running the script
> >> (remove the relevant eo_do).
> >>
> >> Follow the wiki page mentioned in the previous email for more
> >> information about Eo and what else needs changing.
> >>
> >> Please let me know about any regressions (there shouldn't be any)
> >> or any issues you may face.
> >
> > I'm now pushing my changes to eo_add. I'm pushing it now for the
> > same reason I pushed the previous changes in.
> >
> > I created a new script that assumes the code has already been
> > migrated with the previous (migrate_eo.py) script. This script is
> > called migrate_eo_add.py and can be found at:
> > https://devs.enlightenment.org/~tasn/migrate_eo_add.py
> >
> > When using the script you should keep two things in mind:
> > 1. You are only allowed to run it *once* per source code, because
> > the changes to eo_add() would otherwise accumulate and your code
> > will be wrong. If you need to correct something you've done wrong,
> > reset the code to the previous state and run the script again on
> > the original code. 2. The migration script is not perfect. In
> > particular it can't deal with cases like missing {} for
> > if/for/while content so for example,
> >
> > if ()
> >  return eo_add(...)
> >
> > would break.
> > 3. If you are fancy and use the same variable inside eo_add and
> > outside, for example like:
> > parent = eo_add(CLASS, parent);
> >
> > your code will break. I suggest you use a temporary variable.
> >
> > So please be aware of that and *manually* review your changes after
> > the script has run.
> >
> > If your code does have these cases, I recommend you either get rid
> > of them, or manually migrate that code before running the script
> > (remove the relevant eo_do).
> >
> >
> >
> > Sorry, but C++ will break until the C++ guys fix it. I'm now in the
> > process of migrating the rest of our applications. Hopefully this
> > will be the last disruption of this sort.
> >
> 
> Good news! I came up with a way to sanely support the old syntax (was 
> discussed on the ML in this thread in my mail on the 10/3 at 11:52
> UTC.
> 
> I'm reverting my changes, and will be pushing everything shortly.

So right now isn't a good time to be updating EFL from 

Re: [E-devel] [EGIT] [core/efl] master 01/02: eeze: remove trailing whitespace

[Stefan Schmidt]

Hello.

On 11/03/16 18:10, Mike Blumenkrantz wrote:
> I was saving that!

Be more careful with your hidden stash of whitespaces. If I clear them 
out before the next winter comes you might have not enough to keep alive 
over the cold time.

regards
Stefan Schmidt

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/02: eeze: remove trailing whitespace

[Mike Blumenkrantz]

I was saving that!

On Fri, Mar 11, 2016 at 12:07 PM Stefan Schmidt 
wrote:

> stefan pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=969bd17ab781e93b8c5a50e47f34c5d159b1f091
>
> commit 969bd17ab781e93b8c5a50e47f34c5d159b1f091
> Author: Stefan Schmidt 
> Date:   Fri Mar 11 17:10:07 2016 +0100
>
> eeze: remove trailing whitespace
>
> Nothing to see here, just stumbled over it when reading through the
> file.
> ---
>  src/lib/eeze/eeze_net.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/lib/eeze/eeze_net.c b/src/lib/eeze/eeze_net.c
> index 8c6b386..47887d7 100644
> --- a/src/lib/eeze/eeze_net.c
> +++ b/src/lib/eeze/eeze_net.c
> @@ -326,7 +326,7 @@ eeze_net_list(void)
>  net = eeze_net_new(i->if_name);
>  if (net) ret = eina_list_append(ret, net);
>   }
> -
> +
> if_freenameindex(ifs);
> return ret;
>  }
>
> --
>
>
>
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: eolian generator: check fwrite return value currectly

[Daniel Kolesa]

On Fri, Mar 11, 2016 at 3:14 PM, Michaël Bouchaud  wrote:
> and what about the close of fd if blen is 0

You're right, I missed that.

D5

>
> 2016-03-11 14:16 GMT+01:00 Daniel Kolesa :
>
>> q66 pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=97adf6d52bd726520524873e846c3f847439cf55
>>
>> commit 97adf6d52bd726520524873e846c3f847439cf55
>> Author: Daniel Kolesa 
>> Date:   Fri Mar 11 13:16:34 2016 +
>>
>> eolian generator: check fwrite return value currectly
>>
>> This fixes CID 1327247.
>>
>> @fix
>> ---
>>  src/bin/eolian/main.c | 14 --
>>  1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/bin/eolian/main.c b/src/bin/eolian/main.c
>> index 77ad87f..f545960 100644
>> --- a/src/bin/eolian/main.c
>> +++ b/src/bin/eolian/main.c
>> @@ -105,8 +105,18 @@ _write_file(const char *filename, const Eina_Strbuf
>> *buffer, Eina_Bool append)
>>  return EINA_FALSE;
>>   }
>>
>> -   if (eina_strbuf_length_get(buffer))
>> - fwrite(eina_strbuf_string_get(buffer), 1,
>> eina_strbuf_length_get(buffer), fd);
>> +   size_t blen = eina_strbuf_length_get(buffer);
>> +   if (!blen)
>> + return EINA_TRUE;
>> +
>> +   if (fwrite(eina_strbuf_string_get(buffer), 1, blen, fd) != blen)
>> + {
>> +fprintf(stderr, "eolian: could not write '%s' (%s)\n",
>> +filename, strerror(errno));
>> +fclose(fd);
>> +return EINA_FALSE;
>> + }
>> +
>> fclose(fd);
>> return EINA_TRUE;
>>  }
>>
>> --
>>
>>
>>
>
>
> --
> Michaël Bouchaud (yoz) 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: eolian generator: check fwrite return value currectly

[Michaël Bouchaud]

and what about the close of fd if blen is 0

2016-03-11 14:16 GMT+01:00 Daniel Kolesa :

> q66 pushed a commit to branch master.
>
>
> http://git.enlightenment.org/core/efl.git/commit/?id=97adf6d52bd726520524873e846c3f847439cf55
>
> commit 97adf6d52bd726520524873e846c3f847439cf55
> Author: Daniel Kolesa 
> Date:   Fri Mar 11 13:16:34 2016 +
>
> eolian generator: check fwrite return value currectly
>
> This fixes CID 1327247.
>
> @fix
> ---
>  src/bin/eolian/main.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/src/bin/eolian/main.c b/src/bin/eolian/main.c
> index 77ad87f..f545960 100644
> --- a/src/bin/eolian/main.c
> +++ b/src/bin/eolian/main.c
> @@ -105,8 +105,18 @@ _write_file(const char *filename, const Eina_Strbuf
> *buffer, Eina_Bool append)
>  return EINA_FALSE;
>   }
>
> -   if (eina_strbuf_length_get(buffer))
> - fwrite(eina_strbuf_string_get(buffer), 1,
> eina_strbuf_length_get(buffer), fd);
> +   size_t blen = eina_strbuf_length_get(buffer);
> +   if (!blen)
> + return EINA_TRUE;
> +
> +   if (fwrite(eina_strbuf_string_get(buffer), 1, blen, fd) != blen)
> + {
> +fprintf(stderr, "eolian: could not write '%s' (%s)\n",
> +filename, strerror(errno));
> +fclose(fd);
> +return EINA_FALSE;
> + }
> +
> fclose(fd);
> return EINA_TRUE;
>  }
>
> --
>
>
>


-- 
Michaël Bouchaud (yoz) 
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] eo_add - Request for comments

[Tom Hacohen]

Hey,

As you may have noticed I reverted the patches regarding eo_add(). The 
reason for that is that following complaints (why didn't you say 
anything following my proposal and *before* I did all the work?!?!) I 
came up with a better way to do it that will let us keep the current 
syntax except for one thing, which is what this post is about.

If you are interested in the implementation details of this solution, 
feel free to ask on IRC or the other thread.

Anyhow, as part of this solution, we need to define a macro that will be 
used inside eo_add. At the moment it's called eoid (and not a macro 
yet), so eo_add() looks like this:
obj = eo_add(CLASS, parent, efl_text_set(eoid, "test"));

I'd like to change "eoid" to something that is:
1. more meaningful.
2. less likely to clash.

I was thinking (and q66 likes it too) eo_self could work.

So the above example will become:
obj = eo_add(CLASS, parent, efl_text_set(eo_self, "test"));

Do you have any ideas for a better name for this? I rather like eo_self. 
I just really don't want to change it again, so whatever we go with now 
will be what we end up with.

Please let me know if you have better alternatives.

Thanks,
Tom.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

[Tom Hacohen]

On 09/03/16 16:23, Tom Hacohen wrote:
> On 03/03/16 10:22, Tom Hacohen wrote:
>> On 01/03/16 09:05, Tom Hacohen wrote:
>>> Hey,
>>>
>>> The Eo syntax is going to be changing once more, and this time, I really
>>> think/hope it'll be the last time. We plan on stabilizing Eo and all of
>>> the functions on top of it in the next few months, so that doesn't leave
>>> us much more time to change it again. :)
>>>
>>> These changes will remove the need for the eo_do family of functions.
>>> Functions will now look like normal C functions (which they are). There
>>> are many benefits to that, and we have many cool new ideas.
>>>
>>> For more info: https://phab.enlightenment.org/w/eo/
>>>
>>> I'm sending this email as an head's up, as I'll be starting to work on
>>> migrating to the new Eo syntax (and implementing it) today. Felipe and I
>>> have actually already started (needed to for the PoC), but I plan on
>>> pushing my changes to master soon.
>>>
>>> If you have any issues/suggestions/comments with the proposal, please
>>> let me know, either in pm, irc or just here.
>>>
>>
>> Changes are in! I still haven't migrated eo_add to the new syntax (it
>> uses a non portable gcc extension in the meanwhile), but otherwise
>> everything is in. Took me *much* less time than I thought it would, so
>> yay. :P
>>
>> I decided to push it now instead of letting it rest in my branch for a
>> while because literally every hour that passed introduced more merge
>> conflicts for me, so the benefits from stabilising it more in my branch
>> were diminished by the new conflicts and issues that could arise.
>>
>> If you have an application that uses the Eo api, you can use my script
>> https://devs.enlightenment.org/~tasn/migrate_eo.py to migrate your code.
>> When using the script you should keep two things in mind:
>> 1. You are only allowed to run it *once* per source code, because the
>> changes to eo_add() would otherwise accumulate and your code will be
>> wrong. If you need to correct something you've done wrong, reset the
>> code to the previous state and run the script again on the original code.
>> 2. The migration script is not perfect. In particular it can't deal with
>> some corner cases like:
>> eo_do(obj, a_set(1),
>> /* b_set(2),
>>   g_set(4), */
>>  c_set(2));
>> Or abominations like:
>> eo_do(obj, if (a_get())
>>  do_something());
>>
>> So please be aware of that and *manually* review your changes after the
>> script has run.
>>
>> If your code does have these cases, I recommend you either get rid of
>> them, or manually migrate that code before running the script (remove
>> the relevant eo_do).
>>
>> Follow the wiki page mentioned in the previous email for more
>> information about Eo and what else needs changing.
>>
>> Please let me know about any regressions (there shouldn't be any) or any
>> issues you may face.
>
> I'm now pushing my changes to eo_add. I'm pushing it now for the same
> reason I pushed the previous changes in.
>
> I created a new script that assumes the code has already been migrated
> with the previous (migrate_eo.py) script. This script is called
> migrate_eo_add.py and can be found at:
> https://devs.enlightenment.org/~tasn/migrate_eo_add.py
>
> When using the script you should keep two things in mind:
> 1. You are only allowed to run it *once* per source code, because the
> changes to eo_add() would otherwise accumulate and your code will be
> wrong. If you need to correct something you've done wrong, reset the
> code to the previous state and run the script again on the original code.
> 2. The migration script is not perfect. In particular it can't deal with
> cases like missing {} for if/for/while content so for example,
>
> if ()
>  return eo_add(...)
>
> would break.
> 3. If you are fancy and use the same variable inside eo_add and outside,
> for example like:
> parent = eo_add(CLASS, parent);
>
> your code will break. I suggest you use a temporary variable.
>
> So please be aware of that and *manually* review your changes after the
> script has run.
>
> If your code does have these cases, I recommend you either get rid of
> them, or manually migrate that code before running the script (remove
> the relevant eo_do).
>
>
>
> Sorry, but C++ will break until the C++ guys fix it. I'm now in the
> process of migrating the rest of our applications. Hopefully this will
> be the last disruption of this sort.
>

Good news! I came up with a way to sanely support the old syntax (was 
discussed on the ML in this thread in my mail on the 10/3 at 11:52 UTC.

I'm reverting my changes, and will be pushing everything shortly.

--
Tom.


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___

Re: [E-devel] [EGIT] [core/efl] master 01/01: eo del interceptor: add the ability to intercept deletions of eo objects

[The Rasterman]

On Fri, 11 Mar 2016 11:20:18 + Tom Hacohen  said:

> On 10/03/16 23:29, Carsten Haitzler wrote:
> > On Thu, 10 Mar 2016 16:07:58 + Tom Hacohen  said:
> >
> >> On 08/03/16 13:39, Tom Hacohen wrote:
> >>> Hey,
> >>>
> >>> Wouldn't it better if the intercept function could return a value saying
> >>> "actually, the object is good to go, just delete it normally", like in
> >>> your example, if the object is already in the right thread, it should
> >>> just delete immediately, no?
> >>
> >> To be honest, giving it a bit more thought I don't see how that is
> >> useful. I think that it's an extreme corner case that is not worth the
> >> trouble, and I'm very much against adding this kind of API because we
> >> actually have uses for them. I'm talking about code using them. Adding
> >> this won't break API so we can wait with adding it until when we
> >> actually need it.
> >
> > actually it will be used soon - specifically for generic messages between
> > lop objects. this is the only way to ensure "safe destruction" of an Eo *
> > payload.
> >
> >> An alternative would be to deal with the cleanup in the destructor. So
> >> you for example free data that is thread agnostic, and when you have
> >> code that needs to be run in a specific loop, you can set manual free
> >> and defer the cleanup to that thread, so most of the object is
> >> destructed in the destructing thread, but the relevant parts are cleaned
> >> in the correct thread. This is implemented per object and is much cleaner.
> >
> > this is far more complex than just queing the deletion as a whole on another
> > thread.
> >
> >> I like it better, but even if we choose to go with the idea in this
> >> commit, I'd say: revert it until needed. I talked to Felipe about it on
> >> IRC and he agrees.
> >
> > see above. i added this because it will be needed soon. like in the coming
> > weeks/months.
> 
> My point is, and it's a point I make all the time about API design. Why 
> not add it when *actually* needed (not a week before or a month before)?
> This ensure the API is actually good and doesn't end up unused. 
> Preferably it should be used by someone other than the original author 
> to ensure it's at least usable.

because i have limited time and like to get work done is small manageable chunks
that each can be done and stand on its own. it is how i have always done things
and as my time has reduced the size of chunks has gone down. i do NO
T like to maintain a branch locally that i keep having to keep in sync with
master. i mentioned all the use cases - caching objects, cross-thread deletion
etc. etc. - just because it isn't USED doesn't not mean it's not USEFUL. if we
applied this principle throughout all of efl we may as well just remove all of
elm api because elm api is not used in efl. it's "user facing". don't add a
feature to elm because efl or elm itself doesn't use it.

is the feature useful? is it complex? is it hard to maintain? those are the
criteria, not "do we use it ourselves in efl - unless we do we won't support
it".

:)

> I don't care enough to argue about this one, because it doesn't harm any 
> of the Eo hot paths, but I still think it's a bad idea to introduce it 
> so early (and in this case, a bad idea in general).
> 
> --
> Tom
> 


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


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] T-shirt for the upcoming 2016 EDDs

[The Rasterman]

On Fri, 11 Mar 2016 10:57:43 + Tom Hacohen  said:

> On 11/03/16 09:36, Stefan Schmidt wrote:
> > Hello.
> >
> > On 11/03/16 03:14, Carsten Haitzler wrote:
> >> On Wed, 2 Mar 2016 16:12:49 +0100 Stefan Schmidt 
> >> said:
> >>
> >>> Hello.
> >>>
> >>> At our initial Enlightenment Developer Day in Barcelona 2012 we had some
> >>> T-shirts for the event.
> >>> We failed since to do this again which is a bit sad. Luckily we have a
> >>> bit more time in advance for the 2016 edition this year and I wonder if
> >>> someone wants to pick this up.
> >>>
> >>> o We would need a new design (maybe a contest if we have some more
> >>> proposals)
> >>> o We would need to query the sizes from attendees
> >>> o We would need to get the shirts printed and shipped to some place in
> >>> Paris (or someone needs to arrange getting them there)
> >> or printed in paris and someone local picks them up?
> >
> >
> > That would also be a good alternative.
> >
> >>
> >>> Money wise I think we can ask the foundation to pay for them upfront and
> >>> we cash the money in at the event. Say 15-20€ per shirt?
> >> they should be a bit cheaper than that no? like ~10?
> >
> > Its not Asia here. We are not getting all the things super cheap. ;)
> >
> > More seriously, I'm happy either way. I would see 20€ as upper limit. If
> > we get some quality shirts for less I'm all in.
> > I just would try to avoid to cheap offerings. For example the grey shirt
> > handed out at the EFL seminar during SOSCON did not even survive one
> > washing. The logo was peeling of directly.
> >
> >>> Does this sounds like a good idea? Anyone picking this up? Unlikely
> >>> Cedric or myself will be able to handle this.
> >> cedric is a bit far away... :)
> >
> > Who knows if he is not on a flight to Europe or Asia right now. With
> > Cedric you never know. :)
> >
> > I was mostly referring to the other things we handle for EDDs. Would be
> > great if the shirt things was handled by someone else. If we have enough
> > interest. Andy already offered his logistic help. We basically miss a
> > design I would think.
> 
> Let's look into dry-fit shirts or something that is actually nice to 
> wear. :P I know cedric is addicted to his Samsung dry-fit shirt...

can you look for something maybe in london? if you take the eurostar to paris
then it's largely irrelevant - the extra weight wont matter.

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


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 01/01: eo del interceptor: add the ability to intercept deletions of eo objects

[Tom Hacohen]

On 10/03/16 23:29, Carsten Haitzler wrote:
> On Thu, 10 Mar 2016 16:07:58 + Tom Hacohen  said:
>
>> On 08/03/16 13:39, Tom Hacohen wrote:
>>> Hey,
>>>
>>> Wouldn't it better if the intercept function could return a value saying
>>> "actually, the object is good to go, just delete it normally", like in
>>> your example, if the object is already in the right thread, it should
>>> just delete immediately, no?
>>
>> To be honest, giving it a bit more thought I don't see how that is
>> useful. I think that it's an extreme corner case that is not worth the
>> trouble, and I'm very much against adding this kind of API because we
>> actually have uses for them. I'm talking about code using them. Adding
>> this won't break API so we can wait with adding it until when we
>> actually need it.
>
> actually it will be used soon - specifically for generic messages between lop
> objects. this is the only way to ensure "safe destruction" of an Eo * payload.
>
>> An alternative would be to deal with the cleanup in the destructor. So
>> you for example free data that is thread agnostic, and when you have
>> code that needs to be run in a specific loop, you can set manual free
>> and defer the cleanup to that thread, so most of the object is
>> destructed in the destructing thread, but the relevant parts are cleaned
>> in the correct thread. This is implemented per object and is much cleaner.
>
> this is far more complex than just queing the deletion as a whole on another
> thread.
>
>> I like it better, but even if we choose to go with the idea in this
>> commit, I'd say: revert it until needed. I talked to Felipe about it on
>> IRC and he agrees.
>
> see above. i added this because it will be needed soon. like in the coming
> weeks/months.

My point is, and it's a point I make all the time about API design. Why 
not add it when *actually* needed (not a week before or a month before)?
This ensure the API is actually good and doesn't end up unused. 
Preferably it should be used by someone other than the original author 
to ensure it's at least usable.

I don't care enough to argue about this one, because it doesn't harm any 
of the Eo hot paths, but I still think it's a bad idea to introduce it 
so early (and in this case, a bad idea in general).

--
Tom

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Eo: Changes to syntax

[Tom Hacohen]

On 11/03/16 02:52, Jean-Philippe André wrote:
> On 11 March 2016 at 00:51, Tom Hacohen  wrote:
>
>> On 10/03/16 12:36, Carsten Haitzler wrote:
>>> On Thu, 10 Mar 2016 15:46:19 +0900 Jean-Philippe André <
>> j...@videolan.org> said:
>>>
 On 10 March 2016 at 15:05, Carsten Haitzler 
>> wrote:

> On Thu, 10 Mar 2016 07:42:22 +0200 Daniel Zaoui <
>> daniel.za...@samsung.com>
> said:
>
>> On Wed, 09 Mar 2016 16:23:04 +
>> Tom Hacohen  wrote:
>>
>>> On 03/03/16 10:22, Tom Hacohen wrote:
 On 01/03/16 09:05, Tom Hacohen wrote:
> Hey,
>
> The Eo syntax is going to be changing once more, and this time, I
> really think/hope it'll be the last time. We plan on stabilizing
> Eo and all of the functions on top of it in the next few months,
> so that doesn't leave us much more time to change it again. :)
>
> These changes will remove the need for the eo_do family of
> functions. Functions will now look like normal C functions (which
> they are). There are many benefits to that, and we have many cool
> new ideas.
>
> For more info: https://phab.enlightenment.org/w/eo/
>
> I'm sending this email as an head's up, as I'll be starting to
> work on migrating to the new Eo syntax (and implementing it)
> today. Felipe and I have actually already started (needed to for
> the PoC), but I plan on pushing my changes to master soon.
>
> If you have any issues/suggestions/comments with the proposal,
> please let me know, either in pm, irc or just here.
>

 Changes are in! I still haven't migrated eo_add to the new syntax
 (it uses a non portable gcc extension in the meanwhile), but
 otherwise everything is in. Took me *much* less time than I thought
 it would, so yay. :P

 I decided to push it now instead of letting it rest in my branch
 for a while because literally every hour that passed introduced
 more merge conflicts for me, so the benefits from stabilising it
 more in my branch were diminished by the new conflicts and issues
 that could arise.

 If you have an application that uses the Eo api, you can use my
 script https://devs.enlightenment.org/~tasn/migrate_eo.py to
 migrate your code. When using the script you should keep two things
 in mind: 1. You are only allowed to run it *once* per source code,
 because the changes to eo_add() would otherwise accumulate and your
 code will be wrong. If you need to correct something you've done
 wrong, reset the code to the previous state and run the script
 again on the original code. 2. The migration script is not perfect.
 In particular it can't deal with some corner cases like:
 eo_do(obj, a_set(1),
 /* b_set(2),
g_set(4), */
 c_set(2));
 Or abominations like:
 eo_do(obj, if (a_get())
 do_something());

 So please be aware of that and *manually* review your changes after
 the script has run.

 If your code does have these cases, I recommend you either get rid
 of them, or manually migrate that code before running the script
 (remove the relevant eo_do).

 Follow the wiki page mentioned in the previous email for more
 information about Eo and what else needs changing.

 Please let me know about any regressions (there shouldn't be any)
 or any issues you may face.
>>>
>>> I'm now pushing my changes to eo_add. I'm pushing it now for the same
>>> reason I pushed the previous changes in.
>>>
>>> I created a new script that assumes the code has already been
>>> migrated with the previous (migrate_eo.py) script. This script is
>>> called migrate_eo_add.py and can be found at:
>>> https://devs.enlightenment.org/~tasn/migrate_eo_add.py
>>>
>>> When using the script you should keep two things in mind:
>>> 1. You are only allowed to run it *once* per source code, because the
>>> changes to eo_add() would otherwise accumulate and your code will be
>>> wrong. If you need to correct something you've done wrong, reset the
>>> code to the previous state and run the script again on the original
>>> code. 2. The migration script is not perfect. In particular it can't
>>> deal with cases like missing {} for if/for/while content so for
>>> example,
>>>
>>> if ()
>>>   return eo_add(...)
>>>
>>> would break.
>>> 3. If you are fancy and use the same variable inside eo_add and
>>> outside, for example like:
>>> parent = eo_add(CLASS, parent);
>>>
>>> your code will break. I 

Re: [E-devel] T-shirt for the upcoming 2016 EDDs

[Tom Hacohen]

On 11/03/16 09:36, Stefan Schmidt wrote:
> Hello.
>
> On 11/03/16 03:14, Carsten Haitzler wrote:
>> On Wed, 2 Mar 2016 16:12:49 +0100 Stefan Schmidt  
>> said:
>>
>>> Hello.
>>>
>>> At our initial Enlightenment Developer Day in Barcelona 2012 we had some
>>> T-shirts for the event.
>>> We failed since to do this again which is a bit sad. Luckily we have a
>>> bit more time in advance for the 2016 edition this year and I wonder if
>>> someone wants to pick this up.
>>>
>>> o We would need a new design (maybe a contest if we have some more
>>> proposals)
>>> o We would need to query the sizes from attendees
>>> o We would need to get the shirts printed and shipped to some place in
>>> Paris (or someone needs to arrange getting them there)
>> or printed in paris and someone local picks them up?
>
>
> That would also be a good alternative.
>
>>
>>> Money wise I think we can ask the foundation to pay for them upfront and
>>> we cash the money in at the event. Say 15-20€ per shirt?
>> they should be a bit cheaper than that no? like ~10?
>
> Its not Asia here. We are not getting all the things super cheap. ;)
>
> More seriously, I'm happy either way. I would see 20€ as upper limit. If
> we get some quality shirts for less I'm all in.
> I just would try to avoid to cheap offerings. For example the grey shirt
> handed out at the EFL seminar during SOSCON did not even survive one
> washing. The logo was peeling of directly.
>
>>> Does this sounds like a good idea? Anyone picking this up? Unlikely
>>> Cedric or myself will be able to handle this.
>> cedric is a bit far away... :)
>
> Who knows if he is not on a flight to Europe or Asia right now. With
> Cedric you never know. :)
>
> I was mostly referring to the other things we handle for EDDs. Would be
> great if the shirt things was handled by someone else. If we have enough
> interest. Andy already offered his logistic help. We basically miss a
> design I would think.

Let's look into dry-fit shirts or something that is actually nice to 
wear. :P I know cedric is addicted to his Samsung dry-fit shirt...


--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] UI syntax, letter 2

[Tom Hacohen]

On 10/03/16 12:44, Carsten Haitzler wrote:
> On Thu, 10 Mar 2016 07:51:01 +0100 Simon Lees  said:
>
>>
>>
>> On 03/10/2016 02:14 AM, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 9 Mar 2016 15:44:57 +0100 Simon Lees  said:
>>>


 On 03/09/2016 08:29 AM, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 9 Mar 2016 17:08:54 +1000 David Seikel  said:
>
>> On Wed, 9 Mar 2016 15:39:45 +0900 Carsten Haitzler (The Rasterman)
>>  wrote:
>>
 * fixed indentation (4 spaces) or not fixed
>>>
>>> i personally think 2 spaces is fine. 4 is just "too much". the reason
>>> is most monospace fonts are taller than they are wide so "2" ends up
>>> a nice diagonal like:
>>
>> Aren't you the guy that made 3 space indenting the standard around
>> here?  ;-P
>
> :-P~

 Well 4 is what most of the civilized world has agreed / standardized on
 so I guess its not going to be that :P

 On a more serious note, as someone who's brain is more visual spacial
 oriented and much prefers and finds it much easyer to look at shapes and
 colors rather then a wall of text 4 is significantly easier to read but
 if were going to keep doing the crazyness of indenting braces then 2 is
 fine because it really ends up being 4 ie

 if (bob.isABogan())
{
  doSomething();
}

 is pretty similar to what a "Normal person" would do

 if (bob.isABogan())
 {
  doSomething();
 }
>>>
>>> since there are no {}'s then you end up with (with 4 spaces):
>>>
>>> blahblah(xxx)
>>>  blah2whatever(yyy)
>>>  blah3boo(zzz)
>>>  wootwoot(x)
>>>  boobooboo(7)
>>>  weee(y)
>>>  abracadabra(hey)
>>>
>>> with 2 it just looks nicer:
>>>
>>> blahblah(xxx)
>>>blah2whatever(yyy)
>>>blah3boo(zzz)
>>>  wootwoot(x)
>>>boobooboo(7)
>>>  weee(y)
>>>abracadabra(hey)
>>>
>>> each indent comes out at a "visually" approximate 45 degrees due to general
>>> font sizing. also it's far nicer on the typer if they have to indent - hit
>>> space twice not 4 times. sure you COULD modify your editor to make tab == 4
>>> spaces and force that BUT then you break your editor for the rest of the
>>> unix world that has agreed on tab == 8 spaces. windows thinks tab == 4
>>> spaces. so - make people hit space 4 times instead of 2? why? that's a bit
>>> silly.
>>
>> Normally people don't hit space 4 times, normally they have there editor
>> configured so that the tab key inserts 4 spaces rather then a \t :)
>
> that is what i said.. and they have it configured to 8 spaces because that is
> the standard (except on windows), so they have to reconfigure their editor 
> JUSt
> for this... or they have fucked up tab sizes as now tab != 8 spaces for many
> documents... so they are going to be stuck really hitting space 4 times or
> dealing with the above pain.

I don't know what backwards editor you're using (well, I do), but for me 
it's very easy to change configuration per project (and I do), and 
anyhow tabs are 4 spaces for me by default (my configuration).

I'm forced to do very bad things to my configuration just to write code 
for the EFL because the EFL uses crazy weird indentation rules, so that 
same logic already doesn't apply for the EFL.

--
Tom.

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] UI syntax, letter 2

[Simon Lees]

On 03/11/2016 12:35 AM, Carsten Haitzler (The Rasterman) wrote:
> On Thu, 10 Mar 2016 17:39:58 + Tom Hacohen  said:
> 
>> On 09/03/16 06:39, Carsten Haitzler wrote:
>>> On Tue, 08 Mar 2016 18:14:42 +0200 Yakov Goldberg 
>>> said:
>>>
 Hello everyone,
 I had discussions with Tom and as a result updated wiki page.

 You can find it here:
 https://phab.enlightenment.org/w/ui_builders_format/


 Most things are clear there are several questions to be discussed:

 * fixed indentation (4 spaces) or not fixed
>>>
>>> i personally think 2 spaces is fine. 4 is just "too much". the reason is
>>> most monospace fonts are taller than they are wide so "2" ends up a nice
>>> diagonal like:
>>>
>>> \
>>>   \
>>>\
>>>
>>> but well more actual 45 degrees. :)
>>
>> You call it a nice diagonal, I call it too compact. I don't think this 
>> argument holds any water because it's never really a nice 45, it's more 
>> like:
>>
>> \
>>   |
>>   |
>>   \
>>|
>>\
>> |
>> |
>>   \
>>|
>>|
>>
>> So you don't really get any aesthetic benefits, and it's better to 
>> optimise for readability not "prettiness" to support this argument I 
>> bring forth exhibit A: http://www.perlmonks.org/?node_id=45213
>> Pretty, but not useful. :)
> 
> i find the diagonal more readable. in fact the more you indent, the more you 
> go
> over 80 columns and have to horiz scroll or wrap or be forced to make very 
> wide
> windows ... so the less indenting - the MORE usable because it creates LESS
> side-effects.
> 
> the more something indents the more the eye has to scan along to find the next
> line start and that is a cost. i'm not discussing pretty as in "it looks like 
> a
> nice image". i'm discussing that it looks nicer from the point of view of
> someone editing text and being able to follow the flow, avoid excess
> wrapping/scrolling etc.

The thing here is that not everyone's eyes / brain work the same, yours
for example "scans along to find the next line start" mine on the other
had picks out the shapes from the indentation and spacing and breaks
them into blocks then uses that to figure out flow etc which is why I
find more spacing easier then less and your probably the opposite.


> 
>>>
 * Widget vs Elm.Widget: all widgets - are they Elm Widgets only and thus
 "Elm" can be skipped or we want to use namespace
>>>
>>> yes. in fact we will skip elm in eo api. they'll be efl.ui. - you want
>>> the ability to strip the efl.ui bit away though so people are not writing
>>>
>>>Efl.Ui.Button (...)
>>>
>>> as opposed to:
>>>
>>>Button (...)
>>>
>>> which is what they should
>>
>> I say that as a rule it should be Efl.Ui.Button, but as a special case 
>> we allow dropping "Efl.Ui". So "Terminology.Ui.Foo" will have to use the 
>> full namespace, but for example "Efl.Ui.Button" could be called either 
>> like that or without the namespace."
>>
>>>
 * button vs Button: starts with capital letter?
>>>
>>> i prefer smalls... i don't see the value of forcing people to hit an extra
>>> shift when it provides no extra syntatic/semantic value.
>>
>> I'd say capitalised if only to be consistent with Eolian. I don't think 
>> it's that much trouble hitting "shift" compared to the readability and 
>> consistency benefits.
>>
>>>
>>> if you supported variables for example then it may be useful to
>>> differentiate object types/constructors as "Button" vs a variable which
>>> might be "button", but then this begins to become a programming language.
>>
>> Please, no.
>>
>>>
>>> actually you MAY need to support this. edje_cc supports basic math like:
>>>
>>> (2+3)/8
>>>
>>> it'll evaluate as edje_cc goes - this is REALLY helpful in making your stuff
>>> readable as you can actually give fractions like 2/3 as opposed to
>>> 0.6 :) since edje_cc also supports cpp this effectively
>>> allows for variable substitution with math..
>>>
>>> of course loading a file into a gui editor and writing it back out may lose
>>> this math magic so it'd only be useful for purely "hand edited" stuff...
>>
>> I'm against that. with loss of precision you get visual artefacts. To 
>> take your example, using: 1/3, 1/3 and 1/3 would lead to 0.33 all 
>> around, which is maybe not a big deal when doing weights (because we 
>> deal with it), when doing things that should fill the area (like 
>> percentage or pixels) would cause a missing pixel. It's better to be 
>> explicit and let the user know that 0.33 * 3 is not 100 and they'll deal 
>> with it on their own. Especially for a simplistic UI language that 
>> should be easy and noob friendly.
>>
>>>
 * callbacks format - options:
   Button()
 on clicked("callback_name")
 on("clicked", "callback_name")
>>>
>>> the first one... :)
>>>
   #and whether allow or not property modification and object creations
   #in callbacks:
 

[E-devel] efl interfaces -> generic messaging

[The Rasterman]

so ... something that was discussed was the idea of generic messaging for
objects. We have this already in EFl in 3 forms:

1. ecore events (anyone can allocate/create a new event type and set up a
handler)

2. evas smart object callbacks (any smart object can have anyone call the
smart callback by string name and thus it can be created ad-hoc and listened to
by anyone who can access the object).

3. edje signals (a signal string and a source string) that anyone can emit on
an edje object (and the edje edc can emit and listen to too) and any one can
listen to if they have the edje object - also this is exposed in elm widgets
too)

all of this is incredibly useful to have be "loosely defined" and "adhoc". eo
events are far more formal and a different use case, with a much higher
"barrier of entry" to create and deal with. to add new event types on an object
you have to inherit form it - create a whole new class and then extend. this is
not trivial work in any language and is FAR more than simply ad-hoc
sending/receiving messages on an object.

so thus the idea of being able to generically message an object and have
listeners (which could be the object itself or someone else) be able to get
events and respond.

there are 2 ways to see messages. synchronous and asynchronous.

async messages are actually how edje implements signals right now within the
mainloop. async messages are also the best way for one loop to message another
simply by sending a message over (adding it to a queue on the target loop) and
triggering a wakeup on the loop if needed. this is also a great way to
"replace" ecore events with the ability to create new "global messages on the
mainloop" that anyone who knows the message id info can listen to WITHIN a
single loop context, not just between loops.

sync messages are very much the smart callback replacement which when you call
(send) the message all callbacks are called "in-line" and by the time your
send/call func returns, all callbacks that listen for messages have been called
and are done. in addition to this due to some comments/requests it would be
GOOD to allow messages to propagate around the object tree. for example they
should be able to propagate to parent objects (optionally) and optionally also
down the tree to children. should this also work with async messages? good
question. it's a lot more painful to do.

so here come questions for all

messages are SO useful that imho they belong in the eo base class. we have
string key -> void * tags on every object because they are so useful. (in fact
we should add/augment these to be able to do eo object references in keys
directly and automatically ref/unref the object stored in the key - this would
save a lot of maintenance code handling this in apps and allow tagged key-value
objects to be auto-freed when their reference goes away or the object owning it
does - but that is another topic).

so i think i should add this to base. i see few if any objects that
could/would/should not use this. in fact if we provide propagation around an
object tree then you want all objects to do this because it otherwise can break
the tree when propagating when one object in the tree can't do messages.

so - any objections to this being in base. the value imho is far greater to be
here than splitting it out to another class.

now for async vs sync. the base class implementation would make all messages by
default be synchronous. it would simply call the event callback for messages
directly when sent and if propagation is enabled, propagate to parents/children
(and avoid loops ... i'm mulling how to do this - as long as you only propagate
one way it's not a problem).

objects like the mainloop will override the message calls and make messages
ASYNC by default because you really need to if you are sending from one loop in
one thread to another. any object that needs or thinks async messages are
better will override. we can have a class anyone who wants mainloop driven
async messages can inherit from to get the implementation. the message apis can
have a a property to query if the messages are sync or async.

now how would this look like:

efl_message_send(obj, 37/*Message ID*/, "MessageString", "Payload String",
message_payload_obj);

message id, message string and message payload obj can all be NULL if you want
(any of them can be but you'd likely want at least payload string or payload
obj to be something).

when you send a message the payload obj (if not null) will be ref++'d. when the
message callbacks are done it will be ref--'d. this way is stays around for as
long as the message is alive. the message event info would probably be:

{
  Eo *src;
  struct {
const char *str;
int id;
  } head;
  struct {
const char *str;
Eo *obj;
  } data;
};

the reason to have src object in the event info is for propagation - if the
event has propagated, you likely want to know the original object it came from.
of course the src object has to be 

Re: [E-devel] T-shirt for the upcoming 2016 EDDs

[Stefan Schmidt]

Hello.

On 11/03/16 03:14, Carsten Haitzler wrote:
> On Wed, 2 Mar 2016 16:12:49 +0100 Stefan Schmidt  
> said:
>
>> Hello.
>>
>> At our initial Enlightenment Developer Day in Barcelona 2012 we had some
>> T-shirts for the event.
>> We failed since to do this again which is a bit sad. Luckily we have a
>> bit more time in advance for the 2016 edition this year and I wonder if
>> someone wants to pick this up.
>>
>> o We would need a new design (maybe a contest if we have some more
>> proposals)
>> o We would need to query the sizes from attendees
>> o We would need to get the shirts printed and shipped to some place in
>> Paris (or someone needs to arrange getting them there)
> or printed in paris and someone local picks them up?


That would also be a good alternative.

>
>> Money wise I think we can ask the foundation to pay for them upfront and
>> we cash the money in at the event. Say 15-20€ per shirt?
> they should be a bit cheaper than that no? like ~10?

Its not Asia here. We are not getting all the things super cheap. ;)

More seriously, I'm happy either way. I would see 20€ as upper limit. If 
we get some quality shirts for less I'm all in.
I just would try to avoid to cheap offerings. For example the grey shirt 
handed out at the EFL seminar during SOSCON did not even survive one 
washing. The logo was peeling of directly.

>> Does this sounds like a good idea? Anyone picking this up? Unlikely
>> Cedric or myself will be able to handle this.
> cedric is a bit far away... :)

Who knows if he is not on a flight to Europe or Asia right now. With 
Cedric you never know. :)

I was mostly referring to the other things we handle for EDDs. Would be 
great if the shirt things was handled by someone else. If we have enough 
interest. Andy already offered his logistic help. We basically miss a 
design I would think.

regards
Stefan Schmidt

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] enlightenment systems

[Jonathan Aquilina]

I too am interested in helping out with enlightenment infrastructure :)

On 2016-03-10 18:25, Stefan Schmidt wrote:

> Hello.
> 
> Sorry, for the delay here. I was on vacation when it arrived and nearly 
> missed it. Good that Mike pointed it out to me.
> 
> On 18/02/16 08:13, Jonathan Aquilina wrote: 
> 
>> Good Morning,
>> 
>> I noticed a thread about the apache user and having a single system
>> admin who has very little time. I am willing to step up to the plate and
>> help out in a sys admin fashion. What time zone is the current sysadmin
>> in? I am based in europe if that helps at all having someone available
>> when the other person is asleep. I can hop on irc if anyone would like
>> to chat.
> 
> Its great to hear that you have interested in helping out with it!
> 
> Beber  (cc'ed) handles our systems and he would be the one you should 
> talk to.
> He is also in Europe so the timezone benefit would be void. :)
> 
> Obviously we are not handing out root access to our servers 
> light-heartedly. Many of our core devs do not have root access either.
> Its about building trust over time and actions. In the end this is 
> really up to beber how he wants to handle this.
> 
> Never the less there should be a way to work it all out and having a 
> second admin available would be great!
> 
> regards
> Stefan Schmidt
> 
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
 
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel