Re: [E-devel] [RFC] One binary to rule them all, packagers opinion needed

[The Rasterman]

On Fri, 21 Oct 2016 15:14:20 -0700 Cedric BAIL  said:

i've been mulling this. i followed the feedback so far. basically 2 main things:

1. this is intended to improve performance. especially startup times.
2. this is highly problematic in terms of portability and is going to create
lots of code and build paths.
3. this makes debugging and other things a nightmare (ps names are all the
same .. well depending on tool etc.)
4. generally the issue of complexity in our build requires for portability etc.

#4 isn't something we can solve right now, but has a better solution if we go
for a greater internal redesign. but not today. some other day. we have to live
with what we have right now.

i am always for improvements. but this really makes this method a very very
very hard ask to do this. i've thought about it and i think this is far TOO
radical a change as it means different execution methods, library production,
linking and so much more os by os. it's kind of insane though theoretically
doable on *nix. i've checked and PIE seems to be urtterly unportable (windows
can't do it based on my reading). the proposal would be workable ONLY if we
could do it unversally so it wouldn't bitrot and it'd work. this is actually
why quicklaunch did .so's instead of PIE because that WORKS portably

so here is what i think is sane:

1. merge libraries aggressively. this reduces linking time BETWEEN efl libs and
thus an efl lib .so when loaded has the libs that were merged already linked
together. i propose we try and get down to maybe 3 or 4 .so's this will close
the gap.

how do we make this portable? well on *nix we can install symlinks from our
old .so major versions TO the new merged ones. but what on windows? the best i
can think of for windows is produce "empty" dll's that ONLY contain like a
dummy function and the correct linking to other efl libs they depend on eg if
we merged eina, eo, ecore, efl into "efl" then eina depends on efl, eo, depend
on efl and ecore depends on efl. thus link any one of these and you got your
symbols from before plus more. this solution ALSO works on *nix ... so we could
use it as a start with symlinks being an optimization of it. yes it means 2
install paths unfortunately. we COULD do it as a post-install that "rm's"
the .so's we installed and replaces them by symlinks which makes this kind of
sane to keep around.

2. move quicklaunch further down to core (efl core) so its not only up in elm
land. this would make it a core capability. we STILL should load .so's/dylibs
or dll's if there, and try PIE binaries... but we should work here on windows
too. make it a core feature low down the stack

3. use quicklaunch mode for e. since efl will be there then this will work.
this does not MEAN we have to use it for all apps nor does it mean we MUST use
it for e... but this would help

these above should get almost all the benefit of the PIE thing with the least
of the downsides. we still have ps name issues though. :( we need to dig more
to try our best to make this "ok" but this means we still work normally. as
long as the "quicklaunch" binary uses very few efl symbols, loading efl libs
and linking will be a much lower cost as we do less intra-lib linking and
minimal app <-> lib linking. in fact we could make a single libefl.so as a
build option if symlinks and dependency .so's as above work. this should be
almost the same cost as the pie binary proposal but is portable.

> Hello,
> 
> Before I embark on a crazy idea that may just break everything, I
> would like to get some feedback. So one of the problem we are facing
> with EFL is that with all those separated library we end up with some
> serious time during application startup dedicated to linking. A work
> around has been quicklaunch, but it is mostly unused. Also it does
> only improve things once it has started, not much during startup time
> where you still have to do all the linking.
> 
> With PIE and -rdynamic that we use today on quicklaunch binary, we use
> dlopen to get symbol from it and load this binary as if they were
> library... So maybe we can actually use that same mechanism to
> actually statically link efl with the quicklaunch server binary and
> make all efl .so library just a symlink to that binary. Now,
> enlightenment could actually try to rely on quicklaunch to start
> itself and start other application. This should speed up boot time and
> application start up time. The reason to make it the default way of
> doing things is to make sure that it is maintained and work.
> 
> Now some of the drawback. First it is a trick, meaning most people
> that will try to dig in will get confused at first on what is going on
> and we need to document it. Building EFL is going to become even more
> complex (I don't know yet how to generate the proper symlink), let's
> enjoy more of the autofoo dark art. All binary will happear as if they
> are just a fork of enlightenment and you will need to use some flags

Re: [E-devel] Enlightenment on OpenIndiana

[The Rasterman]

On Mon, 24 Oct 2016 17:30:09 +0200 Aurélien Larcher
 said:

> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
> 
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
> 
> Again last week-end I updated our components
> 
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
> 
> and gave it a try... without success.
> 
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
> 
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
> 
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.

can you get a proper gdb backtrace of processes that hang. the below i THINK
is saying terminology is hanging in getpid(). ... no idea what pstack normally
says. elementary_Test is hung waiting for a reply from the xserver. thats what
it looks like.

both of these hangs would be fairly and squarely "an os/system issue on
solaris". getpid() hanging and never returning? that should NEVER happen. it's
just getting the current process id. the other - waiting on xserver. it
SHOULDNT even be talking tot he xserver. see the manual page on XPending:

   The XPending function returns the number of events that have been
   received from the X server but have not been removed from the event
   queue.  XPending is identical to XEventsQueued with the mode
   QueuedAfterFlush specified.

it really should very likely not be going and asking the xserver anything. we
want to know if any events are buffered/queued locally (already read from the
fd so the fd wont go active since the data is already out of the fd buffer and
into internal xlib buffers).

i don't know what to say... both of the traces i see smell to me like really
nasty OS issues at a glance. show me more info to say they are not, but this
would imply opensolaris is really badly broken. especially getpid() hanging.

> Kind regards
> 
> Aurelien
> 
> 
> helios> pstack `pgrep terminology`
> 12876:terminology
> -  lwp# 1 / thread# 1  
>  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
>  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
>  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
>  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
>  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
>  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> -  lwp# 2 / thread# 2  
>  feefb5b9 lwp_park (0, 0, 0)
>  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) + 6a
>  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> fef6e000, fe698408) + 8f
>  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> fe66b000) + 2e
>  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
>  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e, 3) + 9e
>  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90240) + 88
>  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> -  lwp# 3 / thread# 3  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 4 / thread# 4  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 5 / thread# 5  
>  feefb5b9 lwp_park (0, 0, 0)
>  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> 81428d8) + 19
>  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
>  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c) + 3f
>  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> feed7c7e, 3) + 3f
>  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90a40) + 88
>  feefb560 

Re: [E-devel] Making documentation for all elements of a eo file mandatory for new files

[The Rasterman]

On Sat, 22 Oct 2016 00:43:30 +0200 Stefan Schmidt  said:

> Hello.
> 
> TL;DR: If you are committing new eo files I expect them to have full 
> docs from now one. Also help with the ones you are currently working on.

this is actually looking pretty decent below now in terms of progress. :)

> Longer version:
> If you look at the commit log you can see that I started another crusade 
> on getting our doc coverage for eo files.
> 
> Right now we have the following stats for our documentation efforts:
> 
> === CLASS SECTION: 269 out of 864 (31%) ===
> 
> Classes:   255 (documented:   93 or  36%)
> Interfaces: 57 (documented:   22 or  39%)
> Mixins: 28 (documented:   28 or 100%)
> Events:524 (documented:  126 or  24%)
> 
> === FUNCTION SECTION: 6440 out of 7790 (83%) ===
> 
> Methods:  1016 (documented:  936 or  92%)
>Method params:  1667 (documented: 1401 or  84%)
>Method returns:  493 (documented:  310 or  63%)
> Getters:  1059 (documented:  970 or  92%)
>Getter returns:  175 (documented:  105 or  60%)
>Getter keys: 120 (documented:   89 or  74%)
>Getter values:  1197 (documented:  924 or  77%)
> Setters:   845 (documented:  779 or  92%)
>Setter returns:   69 (documented:   43 or  62%)
>Setter keys:  57 (documented:   49 or  86%)
>Setter values:  1092 (documented:  834 or  76%)
> 
> === TYPE SECTION: 1240 out of 1775 (70%) ===
> 
> Aliases:84 (documented:9 or  11%)
> Structs:82 (documented:   57 or  70%)
> Struct fields: 191 (documented:  156 or  82%)
> Enums: 170 (documented:  154 or  91%)
> Enum fields:  1248 (documented:  864 or  69%)
> 
> === VARIABLE SECTION: 56 out of 56 (100%) ===
> 
> Constants:   0 (documented:0 or 100%)
> Globals:56 (documented:   56 or 100%)
> 
> === TOTAL: 8005 out of 10485 (76%) ===
> 
> Which means we have 2480 undocumented items.
> 
> I'm willing to work on this and I actually doing it already but if your 
> working area covers some eo files please make sure that you document all 
> bits in there. Some might look silly on a first glace (enums fields, 
> etc) but getting this to a 100% coverage, and keeping it, really helps 
> the doc efforts. We are using these to generate our documentation and 
> after some time for setup and migration of the older doxygen docs we 
> will switch to them. An example how they look like is here (design and 
> layout is up for suggestions but need to stay aligned with our www theme 
> to have a consistent look):
> https://devs.enlightenment.org/~stefan/dokuwiki/doku.php?id=docs:efl:auto:reference
> 
> To keep track on the progress you can use:
> src/bin/elua/elua src/scripts/elua/apps/gendoc.lua -src/lib/
> 
> To get an output of what items are still need docs use the verbose flag:
> src/bin/elua/elua src/scripts/elua/apps/gendoc.lua -v src/lib/
> 
> regards
> Stefan Schmidt
> 
> --
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
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: evas_callbacks: restore error message behaviour from MAGIC_CHECK

[The Rasterman]

On Mon, 24 Oct 2016 17:02:54 +0900 Jean-Philippe André  said:

> On 24 October 2016 at 16:45, Jean-Philippe André  wrote:
> 
> >
> >
> > On 24 October 2016 at 16:11,  wrote:
> >
> >> On Mon, Oct 24, 2016 at 12:21:19PM +0900, Jean-Philippe André wrote:
> >> > Hey Marcel,
> >> >
> >> > On 23 October 2016 at 16:45,  wrote:
> >> >
> >> > > I am not wondering thats its YOU dont who dont like my change... :)
> >> > >
> >> > > Well there are two reasons to NOT have a Error message.
> >> > >
> >> > > First, it was before like that, so before it was completly valid, no
> >> > > error, now you will have a shitload of error messages in your console.
> >> > > Which was the case since evas_object_event_callback_del_full was
> >> called
> >> > > on cursor objects, undependent from if they are NULL or not. So if you
> >> > > dont want to have this NULL check, feel free the go to all api calls
> >> in
> >> > > EFL and check if they are valid.
> >> > >
> >> > > Also, complete eo works like that, if you call things on a NULL
> >> object,
> >> > > nothing will happen ... So i guess the same for evas_object_*
> >> functions
> >> > > should be the case.
> >> > >
> >> > > So no, its a correct usecase.
> >> > >
> >> >
> >> > Not really.
> >> > It's not because it was silently ignored that the calls were actually
> >> valid.
> >> >
> >> > In fact doing something on NULL (except del) should trigger an error or
> >> > warning message.
> >> > Hiding error messages is really just that: it's hiding an invalid code
> >> path.
> >>
> >> This does not make sense.
> >>
> >> Honestly, why should:
> >>
> >> ecore_event_handler_del(NULL)
> >>
> >> be fine but:
> >>
> >> evas_object_event_callback_del_full(NULL)
> >>
> >> give a error ?
> >>
> >> Even more, all the functions from eo, just dont do anything, why
> >> should this single function give a error? Sure its usefull to get
> >> warned, HEY you are doing this on a null obj, but if we do so it should
> >> be consistent over all the api, and not just those few evas api´s.
> >> But i guess this will not fit into anyones time scheudle. :)
> >>
> >
> > If you call an EO function on a NULL object you get an error message (a
> > cryptic one btw, should be improved).
> >
> 
> ^^ I was wrong, didn't compile properly :) (now the coffee has finally
> kicked in)
> And yes, adding ERR on NULL calls triggers a ton of ERR messages.
> 
> My bad. I get your point then.

which is why this should be DBG(). :) leave ERR for real errors.

libc doesnt complain or segv when you free(NULL). so by the same token i kind
of see efl_func(NULL...) where thats the obj is like free(NULL) - its a nop op.
maybe you didnt intend it... but we shouldnt be hellishly noisy all day about
it.

all that happens is code getys littered with

if (obj) api(obj);

we already have a tonne of it and all it does is make code slower and bigger
and longer.

> > So the above scenario where you call a function that silently does nothing
> > on NULL is not going to happen much as we move to EO.
> >
> > One way or another remember that those are only debug logs. Not a
> > functional change.
> > More debug is usually better, maybe ERR is too high a level. But ignoring
> > errors silently is a sure way to add bugs in the future :)
> >
> 
> As you said on IRC, this could be a feature of eo_dbg.
> 
> Best regards,
> jp
> 
> 
> >
> >
> > > Let's instead fix the root causes for those calls on NULL.
> >> > Yes, that more work, and it also shows more error logs in existing
> >> careless
> >> > apps. In the long run, this helps.
> >> >
> >> > Best regards,
> >> >
> >> >
> >> > On Sun, Oct 23, 2016 at 08:56:10AM +0200, Davide Andreoli wrote:
> >> > > > hey, I don't like this change. passing a NULL obj to those functions
> >> > > can't
> >> > > > be correct and an error message is imo the right think to do.
> >> > > > In fact yesterday I spotted 2 hidden bugs in python-efl thanks to
> >> the
> >> > > > message you removed.
> >> > > > Do you have a correct use case for this? or you are just lazy and
> >> don't
> >> > > > want to see errors on console?  :P
> >> > > >
> >> > > > 2016-10-22 20:32 GMT+02:00 Marcel Hollerbach <
> >> > > marcel-hollerb...@t-online.de>
> >> > > > :
> >> > > >
> >> > > > > bu5hm4n pushed a commit to branch master.
> >> > > > >
> >> > > > > http://git.enlightenment.org/core/efl.git/commit/?id=
> >> > > > > 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> >> > > > >
> >> > > > > commit 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> >> > > > > Author: Marcel Hollerbach 
> >> > > > > Date:   Sat Oct 22 19:26:47 2016 +0200
> >> > > > >
> >> > > > > evas_callbacks: restore error message behaviour from
> >> MAGIC_CHECK
> >> > > > >
> >> > > > > before changing MAGIC_CHECK to eo_isa passing NULL to a
> >> function
> >> > > would
> >> > > > > result in nothing, now it gives a error message. This
> >> 

Re: [E-devel] SSH access to e5

[The Rasterman]

On Mon, 24 Oct 2016 20:59:41 +0200 Jonathan Aquilina 
said:

> Hi Raster, 
> 
> I am still having no luck whats so ever. I think there are further
> quirks with the server. I will touch base with you on irc tomorrow but I
> think what you showed me in that other thread with regards to my ip is
> that it is still blocked :( 
> 
> Feel free to email me off list so we can sort this out together as I am
> very eager to get going with trying to iron out server isssues.

lets get together on irc like yesterday and figure out why... i see nothing in
the logs... :( 

0 19:08:05 e5 /var/log # grep -r jaqu .
0 19:08:10 e5 /var/log #


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


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[The Rasterman]

On Tue, 25 Oct 2016 07:31:33 +1030 Simon Lees  said:

> 
> 
> On 10/25/2016 04:12 AM, Cedric BAIL wrote:
> > On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt 
> > wrote:
> >> On 12/09/16 19:01, Cedric BAIL wrote:
> >>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt 
> >>> wrote:
>  On 10/09/16 01:29, Cedric BAIL wrote:
> > I fully agree with Andrew. I have yet to review what still need to be
> > done regarding Efl new interface task, but I hope that 1.19 will be
> > our final call. We do now have time to cleanup example and check that
> > things look fine.
> 
>  Please correct me if I did not get you two correctly here.
> 
>  You both think we should release 1.19 only once the interface work is
>  fully done? Be it in 3 months or in a year?
> >>>
> >>> I hope that we will be done by November.
> >>
> >>
> >> You still hope this?
> > 
> > Nope. Not anymore, should have updated this thread last week. We have
> > been unable to secure someone to work on genlist/gengrid and it will
> > not be done for 1.19. Blocking on efl interface to be done for 1.19 is
> > now useless in my opinion (or wishfull thinking). I think we would be
> > even fine with a shorter dead line. Just let me merge eo/efl/ecore and
> > that would be the only really important change for this release.
> > 
> 
> From a Distro / application perspective this is quite painful, what
> happened with 1.18 and I guess what will continue to happen basically
> every efl release a bunch of apps using eo break so they need to put out
> a point release just to fix building which means that release needs to
> be packaged etc For this reason i'm hesitant to push any eo based
> apps such as enventor into anything other then an unstable part of the
> distro. Atleast the showstoper based release forces those who want Y and
> Z into releases to also get X done. If someone can't get this finished
> basically everyone working on eo based apps are currently wasting there
> time because know one can use them and they probably should be finishing
> this work instead. I was starting to consider pushing eo based apps
> based off the fact there would only be one more break but I guess I'm
> back to holding off.

we have made it clear "dont use eo in any apps you plan to ship/release". not
until its stable. i am unsure how efl can be held in any way responsible for
this unless we break legacy (non eo) api...


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


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[The Rasterman]

On Mon, 24 Oct 2016 10:49:27 +0200 Stefan Schmidt  said:

> Hello.
> 
> On 13/09/16 00:31, Simon Lees wrote:
> >
> >
> > On 09/13/2016 12:28 AM, Stefan Schmidt wrote:
> >> Hello.
> >>
> >> On 10/09/16 01:29, Cedric BAIL wrote:
> >>> Hello,
> >>>
> >>> I fully agree with Andrew. I have yet to review what still need to be
> >>> done regarding Efl new interface task, but I hope that 1.19 will be
> >>> our final call. We do now have time to cleanup example and check that
> >>> things look fine.
> >>
> >> Please correct me if I did not get you two correctly here.
> >>
> >> You both think we should release 1.19 only once the interface work is
> >> fully done? Be it in 3 months or in a year?
> >>
> >
> > I think we should still aim for whatever has been set but the interface
> > work should be treated as a showstopper bug ie if something is still
> > missing or not quite finished we wait.
> 
> Makes me think of e17. :P

eo+interfaces is a massive amount of work. it's re-doing 50% of our api and
design that has been built up over a decade+. it's done by a fairly small crew
too. and the rest of the ship has to keep moving. it's not surprising it's
taking a long time.

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


--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python-Efl doesn't compile

[Simon Lees]

On 10/25/2016 08:58 AM, Andrew Williams wrote:
> That could work but it may have needed lots more env passed in. On IRC dave
> pointed out that sudo -E should work, and it did :)
> 
While it works it also adds additional security risks due to the
potential for environment variable injection so its use should be
strongly discouraged.

> On Mon, 24 Oct 2016 at 20:46, Massimo Maiurana  wrote:
> 
>> Uh?
>>
>> I usually install in /opt/e17 via sudo just exporting
>> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/e17/lib/pkgconfig, maybe you can
>> set something similar in your scripts.
>>
>> Bye
>> Massimo
>>
>> Andrew Williams ha scritto il 24/10/2016 alle 20:59:
>>> Hi,
>>>
>>> The sudo python setup.py install does not work as sodos pkgconfig cannot
>>> find efl it seems...
>>>
>>> Andy
>>>
>>> On Mon, 24 Oct 2016 at 18:26, Davide Andreoli 
>>> wrote:
>>>
 2016-10-23 21:42 GMT+02:00 Andrew Williams :

> My apologies you are quite right - it is building just fine. Sorry for
> that, my info was out of date
>

 :)


> I can't get it installed however - perhaps you can help? Regular user
> cannot write to site-packages but sudo does not have efl paths setup.
>> Is
 it
> possible to make it work like the main build so your user does all of
>> the
> building and sudo can blindly install?
>

 sure, try:
 python setup.py build
 sudo python setup.py install


>
> Many thanks indeed - if I solve this I can include it in Efler as I
 hoped.
> (And egitu and a bunch of those great apps)
>

 Great, If you add it to efler I highly suggest to go with python3 by
 default,
 just use python3 in all the setup.py commands.

 (and sadly I have no time to maintain egitu atm, it have some small
>> issues,
 but it's usable, I use it every time I use git, it just have some issue
 with refreshing
 the contents at the correct time)


>
> Andrew
>
> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
> wrote:
>
>> 2016-10-22 16:18 GMT+02:00 Andrew Williams :
>>
>>> I'm pretty sure the python bindings have not been updated in a while.
> As
>>> our development moves on so quickly these unmaintained portions fall
>> behind
>>> fast.
>>>
>>
>> really sure? did you follow the git commit list? maybe you missed my
>> commits from the last week
>> We (me and kuuko) do our best to keep the bindings in sync also during
> the
>> development phases. We usually are behind efl by one week or so!
>>
>> I'm a bit offended that you put python-efl in the "unmaintained" land,
>> seems all my effort to constantly update the bindings to
>> #FollowTheWhiteRabbit
>> really goes into the void :(
>>
>> btw, you are just wrong: python-efl is one of the most maintained bit
>> outside
>> the core libs, and is currently in sync with efl master :P
>>
>>
>>
>>>
>>> If we can resolve this then I will be able to pop python-efl and the
> apps
>>> that rely on it into the Efler app installer :)
>>>
>>> Andrew
>>>
>>> On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
>> wrote:
>>>
 I don't know if it's something wrong in my setup, but lately
 I'm not able to build Python bindings anymore. I attach the build
 log
>> to
 preserve its lines length.

 --
 Massimo Maiurana
 Ragusa (RG)

 
>>> --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, SlashDot.org! http://sdm.link/slashdot
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
>> 
> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net

Re: [E-devel] Python-Efl doesn't compile

[Andrew Williams]

By way of an additional apology Python-efl can now be installed / managed
from efler.

I have not got any of the great Python apps in there yet as it's currently
only capable of using the e.org git - is there any reason why egitu etc are
available only on GitHub?

Thanks for the help,
Andy
On Mon, 24 Oct 2016 at 20:46, Massimo Maiurana  wrote:

> Uh?
>
> I usually install in /opt/e17 via sudo just exporting
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/e17/lib/pkgconfig, maybe you can
> set something similar in your scripts.
>
> Bye
> Massimo
>
> Andrew Williams ha scritto il 24/10/2016 alle 20:59:
> > Hi,
> >
> > The sudo python setup.py install does not work as sodos pkgconfig cannot
> > find efl it seems...
> >
> > Andy
> >
> > On Mon, 24 Oct 2016 at 18:26, Davide Andreoli 
> > wrote:
> >
> >> 2016-10-23 21:42 GMT+02:00 Andrew Williams :
> >>
> >>> My apologies you are quite right - it is building just fine. Sorry for
> >>> that, my info was out of date
> >>>
> >>
> >> :)
> >>
> >>
> >>> I can't get it installed however - perhaps you can help? Regular user
> >>> cannot write to site-packages but sudo does not have efl paths setup.
> Is
> >> it
> >>> possible to make it work like the main build so your user does all of
> the
> >>> building and sudo can blindly install?
> >>>
> >>
> >> sure, try:
> >> python setup.py build
> >> sudo python setup.py install
> >>
> >>
> >>>
> >>> Many thanks indeed - if I solve this I can include it in Efler as I
> >> hoped.
> >>> (And egitu and a bunch of those great apps)
> >>>
> >>
> >> Great, If you add it to efler I highly suggest to go with python3 by
> >> default,
> >> just use python3 in all the setup.py commands.
> >>
> >> (and sadly I have no time to maintain egitu atm, it have some small
> issues,
> >> but it's usable, I use it every time I use git, it just have some issue
> >> with refreshing
> >> the contents at the correct time)
> >>
> >>
> >>>
> >>> Andrew
> >>>
> >>> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
> >>> wrote:
> >>>
>  2016-10-22 16:18 GMT+02:00 Andrew Williams :
> 
> > I'm pretty sure the python bindings have not been updated in a while.
> >>> As
> > our development moves on so quickly these unmaintained portions fall
>  behind
> > fast.
> >
> 
>  really sure? did you follow the git commit list? maybe you missed my
>  commits from the last week
>  We (me and kuuko) do our best to keep the bindings in sync also during
> >>> the
>  development phases. We usually are behind efl by one week or so!
> 
>  I'm a bit offended that you put python-efl in the "unmaintained" land,
>  seems all my effort to constantly update the bindings to
>  #FollowTheWhiteRabbit
>  really goes into the void :(
> 
>  btw, you are just wrong: python-efl is one of the most maintained bit
>  outside
>  the core libs, and is currently in sync with efl master :P
> 
> 
> 
> >
> > If we can resolve this then I will be able to pop python-efl and the
> >>> apps
> > that rely on it into the Efler app installer :)
> >
> > Andrew
> >
> > On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
>  wrote:
> >
> >> I don't know if it's something wrong in my setup, but lately
> >> I'm not able to build Python bindings anymore. I attach the build
> >> log
>  to
> >> preserve its lines length.
> >>
> >> --
> >> Massimo Maiurana
> >> Ragusa (RG)
> >>
> >> 
> > --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
>  
> >>> --
>  Check out the vibrant tech community on one of the world's most
>  engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>  ___
>  enlightenment-devel mailing list
>  enlightenment-devel@lists.sourceforge.net
>  

Re: [E-devel] Python-Efl doesn't compile

[Andrew Williams]

That could work but it may have needed lots more env passed in. On IRC dave
pointed out that sudo -E should work, and it did :)

On Mon, 24 Oct 2016 at 20:46, Massimo Maiurana  wrote:

> Uh?
>
> I usually install in /opt/e17 via sudo just exporting
> PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/e17/lib/pkgconfig, maybe you can
> set something similar in your scripts.
>
> Bye
> Massimo
>
> Andrew Williams ha scritto il 24/10/2016 alle 20:59:
> > Hi,
> >
> > The sudo python setup.py install does not work as sodos pkgconfig cannot
> > find efl it seems...
> >
> > Andy
> >
> > On Mon, 24 Oct 2016 at 18:26, Davide Andreoli 
> > wrote:
> >
> >> 2016-10-23 21:42 GMT+02:00 Andrew Williams :
> >>
> >>> My apologies you are quite right - it is building just fine. Sorry for
> >>> that, my info was out of date
> >>>
> >>
> >> :)
> >>
> >>
> >>> I can't get it installed however - perhaps you can help? Regular user
> >>> cannot write to site-packages but sudo does not have efl paths setup.
> Is
> >> it
> >>> possible to make it work like the main build so your user does all of
> the
> >>> building and sudo can blindly install?
> >>>
> >>
> >> sure, try:
> >> python setup.py build
> >> sudo python setup.py install
> >>
> >>
> >>>
> >>> Many thanks indeed - if I solve this I can include it in Efler as I
> >> hoped.
> >>> (And egitu and a bunch of those great apps)
> >>>
> >>
> >> Great, If you add it to efler I highly suggest to go with python3 by
> >> default,
> >> just use python3 in all the setup.py commands.
> >>
> >> (and sadly I have no time to maintain egitu atm, it have some small
> issues,
> >> but it's usable, I use it every time I use git, it just have some issue
> >> with refreshing
> >> the contents at the correct time)
> >>
> >>
> >>>
> >>> Andrew
> >>>
> >>> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
> >>> wrote:
> >>>
>  2016-10-22 16:18 GMT+02:00 Andrew Williams :
> 
> > I'm pretty sure the python bindings have not been updated in a while.
> >>> As
> > our development moves on so quickly these unmaintained portions fall
>  behind
> > fast.
> >
> 
>  really sure? did you follow the git commit list? maybe you missed my
>  commits from the last week
>  We (me and kuuko) do our best to keep the bindings in sync also during
> >>> the
>  development phases. We usually are behind efl by one week or so!
> 
>  I'm a bit offended that you put python-efl in the "unmaintained" land,
>  seems all my effort to constantly update the bindings to
>  #FollowTheWhiteRabbit
>  really goes into the void :(
> 
>  btw, you are just wrong: python-efl is one of the most maintained bit
>  outside
>  the core libs, and is currently in sync with efl master :P
> 
> 
> 
> >
> > If we can resolve this then I will be able to pop python-efl and the
> >>> apps
> > that rely on it into the Efler app installer :)
> >
> > Andrew
> >
> > On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
>  wrote:
> >
> >> I don't know if it's something wrong in my setup, but lately
> >> I'm not able to build Python bindings anymore. I attach the build
> >> log
>  to
> >> preserve its lines length.
> >>
> >> --
> >> Massimo Maiurana
> >> Ragusa (RG)
> >>
> >> 
> > --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> >> ___
> >> enlightenment-devel mailing list
> >> enlightenment-devel@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
>  
> >>> --
>  Check out the vibrant tech community on one of the world's most
>  engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>  ___
>  enlightenment-devel mailing list
>  enlightenment-devel@lists.sourceforge.net
>  https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> >>> 
> >>> --
> >>> Check out the vibrant tech community on one of the 

Re: [E-devel] Enlightenment on OpenIndiana

[Simon Lees]

On 10/25/2016 02:00 AM, Aurélien Larcher wrote:
> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
> 
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
> 
> Again last week-end I updated our components
> 
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
> 
> and gave it a try... without success.
> 
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
> 
All Linux distro's are building without xcb enabled as its actually
slower in this use case, but it seems like you are also building without
xcb as well which is correct. The rest of your configure flags for efl
also look sensible.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Simon Lees]

On 10/25/2016 04:12 AM, Cedric BAIL wrote:
> On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt  
> wrote:
>> On 12/09/16 19:01, Cedric BAIL wrote:
>>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
>>> wrote:
 On 10/09/16 01:29, Cedric BAIL wrote:
> I fully agree with Andrew. I have yet to review what still need to be
> done regarding Efl new interface task, but I hope that 1.19 will be
> our final call. We do now have time to cleanup example and check that
> things look fine.

 Please correct me if I did not get you two correctly here.

 You both think we should release 1.19 only once the interface work is
 fully done? Be it in 3 months or in a year?
>>>
>>> I hope that we will be done by November.
>>
>>
>> You still hope this?
> 
> Nope. Not anymore, should have updated this thread last week. We have
> been unable to secure someone to work on genlist/gengrid and it will
> not be done for 1.19. Blocking on efl interface to be done for 1.19 is
> now useless in my opinion (or wishfull thinking). I think we would be
> even fine with a shorter dead line. Just let me merge eo/efl/ecore and
> that would be the only really important change for this release.
> 

From a Distro / application perspective this is quite painful, what
happened with 1.18 and I guess what will continue to happen basically
every efl release a bunch of apps using eo break so they need to put out
a point release just to fix building which means that release needs to
be packaged etc For this reason i'm hesitant to push any eo based
apps such as enventor into anything other then an unstable part of the
distro. Atleast the showstoper based release forces those who want Y and
Z into releases to also get X done. If someone can't get this finished
basically everyone working on eo based apps are currently wasting there
time because know one can use them and they probably should be finishing
this work instead. I was starting to consider pushing eo based apps
based off the fact there would only be one more break but I guess I'm
back to holding off.

-- 

Simon Lees (Simotek)http://simotek.net

Emergency Update Team   keybase.io/simotek
SUSE LinuxAdeliade Australia, UTC+9:30
GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B



signature.asc
Description: OpenPGP digital signature
--
The Command Line: Reinvented for Modern Developers
Did the resurgence of CLI tooling catch you by surprise?
Reconnect with the command line and become more productive. 
Learn the new .NET and ASP.NET CLI. Get your free copy!
http://sdm.link/telerik___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python-Efl doesn't compile

[Massimo Maiurana]

Uh?

I usually install in /opt/e17 via sudo just exporting
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/e17/lib/pkgconfig, maybe you can
set something similar in your scripts.

Bye
Massimo

Andrew Williams ha scritto il 24/10/2016 alle 20:59:
> Hi,
> 
> The sudo python setup.py install does not work as sodos pkgconfig cannot
> find efl it seems...
> 
> Andy
> 
> On Mon, 24 Oct 2016 at 18:26, Davide Andreoli 
> wrote:
> 
>> 2016-10-23 21:42 GMT+02:00 Andrew Williams :
>>
>>> My apologies you are quite right - it is building just fine. Sorry for
>>> that, my info was out of date
>>>
>>
>> :)
>>
>>
>>> I can't get it installed however - perhaps you can help? Regular user
>>> cannot write to site-packages but sudo does not have efl paths setup. Is
>> it
>>> possible to make it work like the main build so your user does all of the
>>> building and sudo can blindly install?
>>>
>>
>> sure, try:
>> python setup.py build
>> sudo python setup.py install
>>
>>
>>>
>>> Many thanks indeed - if I solve this I can include it in Efler as I
>> hoped.
>>> (And egitu and a bunch of those great apps)
>>>
>>
>> Great, If you add it to efler I highly suggest to go with python3 by
>> default,
>> just use python3 in all the setup.py commands.
>>
>> (and sadly I have no time to maintain egitu atm, it have some small issues,
>> but it's usable, I use it every time I use git, it just have some issue
>> with refreshing
>> the contents at the correct time)
>>
>>
>>>
>>> Andrew
>>>
>>> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
>>> wrote:
>>>
 2016-10-22 16:18 GMT+02:00 Andrew Williams :

> I'm pretty sure the python bindings have not been updated in a while.
>>> As
> our development moves on so quickly these unmaintained portions fall
 behind
> fast.
>

 really sure? did you follow the git commit list? maybe you missed my
 commits from the last week
 We (me and kuuko) do our best to keep the bindings in sync also during
>>> the
 development phases. We usually are behind efl by one week or so!

 I'm a bit offended that you put python-efl in the "unmaintained" land,
 seems all my effort to constantly update the bindings to
 #FollowTheWhiteRabbit
 really goes into the void :(

 btw, you are just wrong: python-efl is one of the most maintained bit
 outside
 the core libs, and is currently in sync with efl master :P



>
> If we can resolve this then I will be able to pop python-efl and the
>>> apps
> that rely on it into the Efler app installer :)
>
> Andrew
>
> On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
 wrote:
>
>> I don't know if it's something wrong in my setup, but lately
>> I'm not able to build Python bindings anymore. I attach the build
>> log
 to
>> preserve its lines length.
>>
>> --
>> Massimo Maiurana
>> Ragusa (RG)
>>
>> 
> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

 
>>> --
 Check out the vibrant tech community on one of the world's most
 engaging tech sites, SlashDot.org! http://sdm.link/slashdot
 ___
 enlightenment-devel mailing list
 enlightenment-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

>>> 
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! 

[EGIT] [core/efl] master 01/01: eina: fix shutdown

[Marcel Hollerbach]

bu5hm4n pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=cf643b627cb467eeb725477908eef928573d6635

commit cf643b627cb467eeb725477908eef928573d6635
Author: Marcel Hollerbach 
Date:   Mon Oct 24 21:13:39 2016 +0200

eina: fix shutdown

in eina_file we are using eina_hash, eina_hash is using eina_rbtree, so
we should ensure that rbtree is shutted down AFTER file is shutted down.

fix T4753
---
 src/lib/eina/eina_main.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/lib/eina/eina_main.c b/src/lib/eina/eina_main.c
index 7238002..118b340 100644
--- a/src/lib/eina/eina_main.c
+++ b/src/lib/eina/eina_main.c
@@ -145,7 +145,6 @@ EAPI Eina_Inlist *_eina_tracking = NULL;
S(ustrbuf);
S(quadtree);
S(simple_xml);
-   S(file);
S(prefix);
S(value);
S(tmpstr);
@@ -154,6 +153,7 @@ EAPI Eina_Inlist *_eina_tracking = NULL;
S(cpu);
S(thread_queue);
S(rbtree);
+   S(file);
S(safepointer);
S(promise);
 /* no model for now
@@ -194,7 +194,6 @@ static const struct eina_desc_setup _eina_desc_setup[] = {
S(ustrbuf),
S(quadtree),
S(simple_xml),
-   S(file),
S(prefix),
S(value),
S(tmpstr),
@@ -203,6 +202,7 @@ static const struct eina_desc_setup _eina_desc_setup[] = {
S(cpu),
S(thread_queue),
S(rbtree),
+   S(file),
S(safepointer),
S(promise)
 /* no model for now

-- 

Re: [E-devel] Python-Efl doesn't compile

[Davide Andreoli]

2016-10-24 20:56 GMT+02:00 Massimo Maiurana :

> Davide Andreoli ha scritto il 24/10/2016 alle 19:16:
> > 2016-10-23 21:35 GMT+02:00 Massimo Maiurana :
> >
> >> Davide Andreoli ha scritto il 23/10/2016 alle 21:19:
> >>> Hi
> >>> this is somehow related to a commit I have done some days ago to
> cleanup
> >>> compiler warnings.
> >>>
> >>> It build fine here, seems you have a more strict compiler than mine :/
> >>> The error is:
> >>> cc1: some warnings being treated as errors
> >>>
> >>> there is a warning:
> >>>   "error: format not a string literal and no format arguments
> >>> [-Werror=format-security]"
> >>> that is threated as an error for you.
> >>>
> >>> Are you using some particular build environment? cflags?
> >>
> >> No, I just run setup.py in a default environment and the only option
> >> that I feed to it is --prefix. I don't know where that
> >> -Werror=format-security comes from, how I disable it on the command
> line?
> >>
> >
> > dunno how to disable on command line but you can try to add:
> > "-Wno-format-security" inside the "common_cflags" list
> > in setup.py around line 215, there are others warnings that are disabled
> > there,
> > you can add your. Please let me know if it work so that I can add it as
> > default.
>
> Yes, adding this to setup.py does the trick :)
>

Great, I pushed the fix in master right now.
again, thanks for reporting this


>
> To do the same thing on the command line it is enough to prepend the
> following variable tuning before the setup.py execution:
>
> CPPFLAGS="$CPPFLAGS -Wno-format-security"
>
> Bye
>
> --
> Massimo Maiurana
> Ragusa (RG)
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [bindings/python/python-efl] master 01/01: some cc don't like the way cython use EINA_LOG macros

[Dave Andreoli]

davemds pushed a commit to branch master.

http://git.enlightenment.org/bindings/python/python-efl.git/commit/?id=0b03f8b2f3ccd5e97920a737065c237fa6ccb2a7

commit 0b03f8b2f3ccd5e97920a737065c237fa6ccb2a7
Author: Dave Andreoli 
Date:   Mon Oct 24 21:15:03 2016 +0200

some cc don't like the way cython use EINA_LOG macros

In some system we saw the compilation fail with this error:
efl/eo/efl.eo.c:1137:60: error: format not a string literal and no format 
arguments [-Werror=format-security]
   EINA_LOG_DOM_INFO(__pyx_v_3efl_2eo_PY_EFL_EO_LOG_DOMAIN, 
__pyx_k_Initializing_efl_eo);

so just ignore those warnings
---
 setup.py | 1 +
 1 file changed, 1 insertion(+)

diff --git a/setup.py b/setup.py
index 4dd46b6..9167492 100755
--- a/setup.py
+++ b/setup.py
@@ -213,6 +213,7 @@ packages = ["efl"]
 common_cflags = [
 "-Wno-deprecated-declarations", # we bind deprecated functions
 "-Wno-unused-variable", # eo_instance_from_object() is unused
+"-Wno-format-security", # some cc don't like the way cython use EINA_LOG 
macros
 # "-Werror", "-Wfatal-errors" # use this to stop build on first warnings
 ]
 

-- 

[E-devel] SSH access to e5

[Jonathan Aquilina]

Hi Raster, 

I am still having no luck whats so ever. I think there are further
quirks with the server. I will touch base with you on irc tomorrow but I
think what you showed me in that other thread with regards to my ip is
that it is still blocked :( 

Feel free to email me off list so we can sort this out together as I am
very eager to get going with trying to iron out server isssues.
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python-Efl doesn't compile

[Andrew Williams]

Hi,

The sudo python setup.py install does not work as sodos pkgconfig cannot
find efl it seems...

Andy

On Mon, 24 Oct 2016 at 18:26, Davide Andreoli 
wrote:

> 2016-10-23 21:42 GMT+02:00 Andrew Williams :
>
> > My apologies you are quite right - it is building just fine. Sorry for
> > that, my info was out of date
> >
>
> :)
>
>
> > I can't get it installed however - perhaps you can help? Regular user
> > cannot write to site-packages but sudo does not have efl paths setup. Is
> it
> > possible to make it work like the main build so your user does all of the
> > building and sudo can blindly install?
> >
>
> sure, try:
> python setup.py build
> sudo python setup.py install
>
>
> >
> > Many thanks indeed - if I solve this I can include it in Efler as I
> hoped.
> > (And egitu and a bunch of those great apps)
> >
>
> Great, If you add it to efler I highly suggest to go with python3 by
> default,
> just use python3 in all the setup.py commands.
>
> (and sadly I have no time to maintain egitu atm, it have some small issues,
> but it's usable, I use it every time I use git, it just have some issue
> with refreshing
> the contents at the correct time)
>
>
> >
> > Andrew
> >
> > On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
> > wrote:
> >
> > > 2016-10-22 16:18 GMT+02:00 Andrew Williams :
> > >
> > > > I'm pretty sure the python bindings have not been updated in a while.
> > As
> > > > our development moves on so quickly these unmaintained portions fall
> > > behind
> > > > fast.
> > > >
> > >
> > > really sure? did you follow the git commit list? maybe you missed my
> > > commits from the last week
> > > We (me and kuuko) do our best to keep the bindings in sync also during
> > the
> > > development phases. We usually are behind efl by one week or so!
> > >
> > > I'm a bit offended that you put python-efl in the "unmaintained" land,
> > > seems all my effort to constantly update the bindings to
> > > #FollowTheWhiteRabbit
> > > really goes into the void :(
> > >
> > > btw, you are just wrong: python-efl is one of the most maintained bit
> > > outside
> > > the core libs, and is currently in sync with efl master :P
> > >
> > >
> > >
> > > >
> > > > If we can resolve this then I will be able to pop python-efl and the
> > apps
> > > > that rely on it into the Efler app installer :)
> > > >
> > > > Andrew
> > > >
> > > > On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
> > > wrote:
> > > >
> > > > > I don't know if it's something wrong in my setup, but lately
> > > > > I'm not able to build Python bindings anymore. I attach the build
> log
> > > to
> > > > > preserve its lines length.
> > > > >
> > > > > --
> > > > > Massimo Maiurana
> > > > > Ragusa (RG)
> > > > >
> > > > > 
> > > > --
> > > > > Check out the vibrant tech community on one of the world's most
> > > > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > > > ___
> > > > > enlightenment-devel mailing list
> > > > > enlightenment-devel@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > > >
> > > > 
> > > > --
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > >
> > > 
> > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> > 
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> 

Re: [E-devel] Python-Efl doesn't compile

[Massimo Maiurana]

Davide Andreoli ha scritto il 24/10/2016 alle 19:16:
> 2016-10-23 21:35 GMT+02:00 Massimo Maiurana :
> 
>> Davide Andreoli ha scritto il 23/10/2016 alle 21:19:
>>> Hi
>>> this is somehow related to a commit I have done some days ago to cleanup
>>> compiler warnings.
>>>
>>> It build fine here, seems you have a more strict compiler than mine :/
>>> The error is:
>>> cc1: some warnings being treated as errors
>>>
>>> there is a warning:
>>>   "error: format not a string literal and no format arguments
>>> [-Werror=format-security]"
>>> that is threated as an error for you.
>>>
>>> Are you using some particular build environment? cflags?
>>
>> No, I just run setup.py in a default environment and the only option
>> that I feed to it is --prefix. I don't know where that
>> -Werror=format-security comes from, how I disable it on the command line?
>>
> 
> dunno how to disable on command line but you can try to add:
> "-Wno-format-security" inside the "common_cflags" list
> in setup.py around line 215, there are others warnings that are disabled
> there,
> you can add your. Please let me know if it work so that I can add it as
> default.

Yes, adding this to setup.py does the trick :)

To do the same thing on the command line it is enough to prepend the
following variable tuning before the setup.py execution:

CPPFLAGS="$CPPFLAGS -Wno-format-security"

Bye

-- 
Massimo Maiurana
Ragusa (RG)

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [RFC] One binary to rule them all, packagers opinion needed

[Cedric BAIL]

On Mon, Oct 24, 2016 at 1:11 AM, Stefan Schmidt  wrote:
> Hello.
>
> On 22/10/16 00:53, Cedric BAIL wrote:
>> On Fri, Oct 21, 2016 at 3:31 PM, Stefan Schmidt  
>> wrote:
>>> On 22/10/16 00:14, Cedric BAIL wrote:
 Before I embark on a crazy idea that may just break everything, I
 would like to get some feedback. So one of the problem we are facing
 with EFL is that with all those separated library we end up with some
 serious time during application startup dedicated to linking. A work
 around has been quicklaunch, but it is mostly unused. Also it does
 only improve things once it has started, not much during startup time
 where you still have to do all the linking.

 With PIE and -rdynamic that we use today on quicklaunch binary, we use
 dlopen to get symbol from it and load this binary as if they were
 library... So maybe we can actually use that same mechanism to
 actually statically link efl with the quicklaunch server binary and
 make all efl .so library just a symlink to that binary. Now,
 enlightenment could actually try to rely on quicklaunch to start
 itself and start other application. This should speed up boot time and
 application start up time. The reason to make it the default way of
 doing things is to make sure that it is maintained and work.
>>>
>>> Are there actual numbers about speed improvement? Are we really needed
>>> this speedup so badly? As you can already see from this two sentences
>>> I'm not really in favor of it. See below for some arguments.
>>
>> Yes, it does, but really depends on your hardware.
>
> And by making it the default your are forcing this quite ugly change to
> all EFL users while only certain hardware setups would really see a
> significant benefit.

Well, the pay off on startup is paying a lot more on the lower end of
the spectrum for sure, but the memory saving will pay off for
everyone. Statically linking efl and initializing them once for the
entire system, means that a lot of the memory consumption issue we
see, like the eo one, would not be a problem anymore. This also would
include loading the system theme once and avoid duplicating that data
across the system. Overall everyone benefit, just the biggest visible
change are obviously on the lower end if you want to notice it (EFL
application on my laptop would never come close to the memory
consumption of Firefox !).

>>   For example, on
>> Raspberry Pi out of the 4s it takes to startup elemines, 1s can be
>> saved by quicklaunch. We are talking of a 25% improvement here. It
>> will also likely push us to improve further quicklaunch
>> infrastructure.
>
> 4 seconds?? Full 4 seconds to get started? I have a hard time to believe
> that. Maybe some of the system configuration is badly? Really slow SD
> card? And anyway, what does elimines do the other 3 seconds of startup?

Yes, Raspberry Pi is slow. SD is slow. The other hardware we have in
mind is max three times faster. And yes, we are mostly targeting the
lower end of the spectrum.

Also no elemines doesn't do the other 3 seconds. It spend part of its
time reading configuration, decompressing the theme, loading jpeg and
connecting to X. Basically 80 to 90% of the time is spend in efl
itself.

> Does other efl apps have the same problem? Terminology? Rage?
> You are asking for a drastic change with quite some downsides here so I
> hope it is not just based on data from one app in one hardware
> configuration. :)

Bigger application like Terminology take much longer to start. I have
no profiled them to tell exactly where the times goes, but for sure
the first 3s are identical. Terminology has a special mode to have one
process for all session and any further start is blazingly fast. Which
is the situation we want for all application without specific code
change per application.

>   We should be able to preconnect to X/Wayland and save
>> for the new process that is starting. We should also be able to pre
>> load the theme which would also save a lot of memory as those data
>> would be shared among all process. Elementary should be able to pre
>> load profile too and save that to every process. So first step is a
>> 25% win for sure. Further down the line, I bet we can save up to 60%
>> of our startup time. Basically some people are trying to push E/EFL
>> even further into smaller embeded device and they are requesting our
>> assistance.
>
> You are asking for it as default! Not as some way to make EFL better
> suited for specific scenarios. A big difference in my eyes. I understand
> the not being tested problem well enough (I deal with not normally
> tested code paths myself during all the QA work), but that should not
> mean we make something very specific our default. Default should be
> generic. e are not enabling architecture based compiler optimizations
> either but leave that to the user.

I am afraid it will bit rot to much. Also I 

[EGIT] [core/enlightenment] master 01/01: disable elementary softcursor mode for wayland compositing

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/enlightenment.git/commit/?id=f7592166eb37ca97837be505d6d8ab99342cf00e

commit f7592166eb37ca97837be505d6d8ab99342cf00e
Author: Chris Michael 
Date:   Mon Oct 24 13:52:09 2016 -0400

disable elementary softcursor mode for wayland compositing

This commit disables elementary softcursor mode when running as a
wayland compositor. This stops any EFL Wayland Client apps from
creating their own mouse pointer and thus we do not have 2 mouse
pointers on EFL apps anymore.

Signed-off-by: Chris Michael 
---
 src/bin/e_comp_wl.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/bin/e_comp_wl.c b/src/bin/e_comp_wl.c
index 5a88430..8607427 100644
--- a/src/bin/e_comp_wl.c
+++ b/src/bin/e_comp_wl.c
@@ -2831,6 +2831,7 @@ e_comp_wl_init(void)
 if (e_randr2_init())
   e_randr2_screens_setup(-1, -1);
 elm_config_preferred_engine_set("wayland_shm");
+elm_config_softcursor_mode_set(ELM_SOFTCURSOR_MODE_OFF);
  }
e_util_env_set("WAYLAND_DEBUG", "0");
e_util_env_set("ELM_DISPLAY", "wl");

-- 

Re: [E-devel] Schedule discussion for 1.19

[Cedric BAIL]

On Mon, Oct 24, 2016 at 1:48 AM, Stefan Schmidt  wrote:
> On 12/09/16 19:01, Cedric BAIL wrote:
>> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
>> wrote:
>>> On 10/09/16 01:29, Cedric BAIL wrote:
 I fully agree with Andrew. I have yet to review what still need to be
 done regarding Efl new interface task, but I hope that 1.19 will be
 our final call. We do now have time to cleanup example and check that
 things look fine.
>>>
>>> Please correct me if I did not get you two correctly here.
>>>
>>> You both think we should release 1.19 only once the interface work is
>>> fully done? Be it in 3 months or in a year?
>>
>> I hope that we will be done by November.
>
>
> You still hope this?

Nope. Not anymore, should have updated this thread last week. We have
been unable to secure someone to work on genlist/gengrid and it will
not be done for 1.19. Blocking on efl interface to be done for 1.19 is
now useless in my opinion (or wishfull thinking). I think we would be
even fine with a shorter dead line. Just let me merge eo/efl/ecore and
that would be the only really important change for this release.
-- 
Cedric BAIL

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Enlightenment on OpenIndiana

[Cedric BAIL]

Hi !

On Mon, Oct 24, 2016 at 8:30 AM, Aurélien Larcher
 wrote:
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
>
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
>
> Again last week-end I updated our components
>
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
>
> and gave it a try... without success.
>
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
>
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
>
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.

I would recommend to do a git bisect in your case. Build efl manually
in 1.12 git branch, check that it still work. Then build efl from 1.16
branch and see if it broken. If it is, you can then start with a git
bisect. It should pin point you to the commit that borked things for
you. Be aware, that for every step in the git bisect of efl, you have
to recompile elementary on the same day/time more or less as the
commit in efl that you are testing. It is going to be very painful do
to .eo file syntax changing all the time, so you may have to go back
and forth, maybe skip some commit. Sadly it is likely going to be
still the easiest way to figure out what went wrong.

Cheers,
-- 
Cedric BAIL

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python-Efl doesn't compile

[Davide Andreoli]

2016-10-23 21:42 GMT+02:00 Andrew Williams :

> My apologies you are quite right - it is building just fine. Sorry for
> that, my info was out of date
>

:)


> I can't get it installed however - perhaps you can help? Regular user
> cannot write to site-packages but sudo does not have efl paths setup. Is it
> possible to make it work like the main build so your user does all of the
> building and sudo can blindly install?
>

sure, try:
python setup.py build
sudo python setup.py install


>
> Many thanks indeed - if I solve this I can include it in Efler as I hoped.
> (And egitu and a bunch of those great apps)
>

Great, If you add it to efler I highly suggest to go with python3 by
default,
just use python3 in all the setup.py commands.

(and sadly I have no time to maintain egitu atm, it have some small issues,
but it's usable, I use it every time I use git, it just have some issue
with refreshing
the contents at the correct time)


>
> Andrew
>
> On Sun, 23 Oct 2016 at 20:29, Davide Andreoli 
> wrote:
>
> > 2016-10-22 16:18 GMT+02:00 Andrew Williams :
> >
> > > I'm pretty sure the python bindings have not been updated in a while.
> As
> > > our development moves on so quickly these unmaintained portions fall
> > behind
> > > fast.
> > >
> >
> > really sure? did you follow the git commit list? maybe you missed my
> > commits from the last week
> > We (me and kuuko) do our best to keep the bindings in sync also during
> the
> > development phases. We usually are behind efl by one week or so!
> >
> > I'm a bit offended that you put python-efl in the "unmaintained" land,
> > seems all my effort to constantly update the bindings to
> > #FollowTheWhiteRabbit
> > really goes into the void :(
> >
> > btw, you are just wrong: python-efl is one of the most maintained bit
> > outside
> > the core libs, and is currently in sync with efl master :P
> >
> >
> >
> > >
> > > If we can resolve this then I will be able to pop python-efl and the
> apps
> > > that rely on it into the Efler app installer :)
> > >
> > > Andrew
> > >
> > > On Sat, 22 Oct 2016 at 12:58 Massimo Maiurana 
> > wrote:
> > >
> > > > I don't know if it's something wrong in my setup, but lately
> > > > I'm not able to build Python bindings anymore. I attach the build log
> > to
> > > > preserve its lines length.
> > > >
> > > > --
> > > > Massimo Maiurana
> > > > Ragusa (RG)
> > > >
> > > > 
> > > --
> > > > Check out the vibrant tech community on one of the world's most
> > > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > > ___
> > > > enlightenment-devel mailing list
> > > > enlightenment-devel@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > >
> > > 
> > > --
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > ___
> > > enlightenment-devel mailing list
> > > enlightenment-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > >
> >
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > ___
> > enlightenment-devel mailing list
> > enlightenment-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Python-Efl doesn't compile

[Davide Andreoli]

2016-10-23 21:35 GMT+02:00 Massimo Maiurana :

> Davide Andreoli ha scritto il 23/10/2016 alle 21:19:
> > Hi
> > this is somehow related to a commit I have done some days ago to cleanup
> > compiler warnings.
> >
> > It build fine here, seems you have a more strict compiler than mine :/
> > The error is:
> > cc1: some warnings being treated as errors
> >
> > there is a warning:
> >   "error: format not a string literal and no format arguments
> > [-Werror=format-security]"
> > that is threated as an error for you.
> >
> > Are you using some particular build environment? cflags?
>
> No, I just run setup.py in a default environment and the only option
> that I feed to it is --prefix. I don't know where that
> -Werror=format-security comes from, how I disable it on the command line?
>

dunno how to disable on command line but you can try to add:
"-Wno-format-security" inside the "common_cflags" list
in setup.py around line 215, there are others warnings that are disabled
there,
you can add your. Please let me know if it work so that I can add it as
default.

Thanks for reporting


>
> --
> Massimo Maiurana
> Ragusa (RG)
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 03/03: evas: Fix framespace object clipping detection

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=9c9c8809a7d90a5ab61c2c930c4cdaeb1d8e8c6a

commit 9c9c8809a7d90a5ab61c2c930c4cdaeb1d8e8c6a
Author: Chris Michael 
Date:   Mon Oct 24 13:05:44 2016 -0400

evas: Fix framespace object clipping detection

This patch fixes an issue where border icons were missing when running
EFL Wayland client applications. This also fixes the issue where
softcursor mouse pointers would not draw over bottom window border.

Signed-off-by: Chris Michael 
---
 src/lib/evas/canvas/evas_render.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/src/lib/evas/canvas/evas_render.c 
b/src/lib/evas/canvas/evas_render.c
index 19fdbd7..6b846ae 100644
--- a/src/lib/evas/canvas/evas_render.c
+++ b/src/lib/evas/canvas/evas_render.c
@@ -189,11 +189,10 @@ _is_obj_in_framespace(Evas_Object_Protected_Data *obj, 
Evas_Public_Data *evas)
 {
if (obj->is_frame) return EINA_TRUE;
 
-   return !RECTS_INTERSECT(obj->cur->geometry.x, obj->cur->geometry.y,
-   obj->cur->geometry.w, obj->cur->geometry.h,
-   evas->framespace.x, evas->framespace.y,
-   evas->viewport.w - evas->framespace.w,
-   evas->viewport.h - evas->framespace.h);
+   return RECTS_INTERSECT(0, -evas->framespace.y,
+  evas->viewport.w, evas->viewport.h,
+  obj->cur->geometry.x, obj->cur->geometry.y,
+  obj->cur->geometry.w, obj->cur->geometry.h);
 }
 
 static inline void

-- 

[EGIT] [core/efl] master 02/03: elementary: Don't always show pointer object

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f56dc8d0c36d45d318f430fb04eae8b2dccd9f14

commit f56dc8d0c36d45d318f430fb04eae8b2dccd9f14
Author: Chris Michael 
Date:   Mon Oct 24 09:47:47 2016 -0400

elementary: Don't always show pointer object

If we are using softcursor mode during intercept show, then we should
check that the pointer is actually in the canvas before showing it
else we end up with mouse pointers drawn on the canvas even when the
mouse itself is nowhere near a window.

Signed-off-by: Chris Michael 
---
 src/lib/elementary/efl_ui_win.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index df7702d..4f62271 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -2773,7 +2773,8 @@ _elm_win_obj_intercept_show(void *data,
 #if 0
 ecore_evas_show(sd->pointer.ee);
 #endif
-evas_object_show(sd->pointer.obj);
+if (evas_pointer_inside_get(sd->evas))
+  evas_object_show(sd->pointer.obj);
  }
evas_object_show(obj);
 #ifdef ELEMENTARY_X

-- 

[EGIT] [core/efl] master 01/03: elementary: Don't try to set pointer edj if there is no pointer

[Christopher Michael]

devilhorns pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=3686a8aa8982517acd3a761e06969cc259b00f18

commit 3686a8aa8982517acd3a761e06969cc259b00f18
Author: Chris Michael 
Date:   Mon Oct 24 09:33:53 2016 -0400

elementary: Don't try to set pointer edj if there is no pointer

If we don't have the sd->pointer.obj here, then there is no need to
try and set the edje theme for it.

Signed-off-by: Chris Michael 
---
 src/lib/elementary/efl_ui_win.c | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/src/lib/elementary/efl_ui_win.c b/src/lib/elementary/efl_ui_win.c
index 6d750b3..df7702d 100644
--- a/src/lib/elementary/efl_ui_win.c
+++ b/src/lib/elementary/efl_ui_win.c
@@ -922,6 +922,7 @@ _elm_win_mouse_in(Ecore_Evas *ee)
if (sd->wl.win)
  ecore_wl2_window_cursor_from_name_set(sd->wl.win, NULL);
 
+   if (!sd->pointer.obj) return;
ecore_evas_object_cursor_set(sd->ee, sd->pointer.obj,
 ELM_OBJECT_LAYER_CURSOR,
 sd->pointer.hot_x, sd->pointer.hot_y);
@@ -935,6 +936,7 @@ _elm_win_mouse_out(Ecore_Evas *ee)
if (!sd) return;
 
 #ifdef HAVE_ELEMENTARY_WL2
+   if (!sd->pointer.obj) return;
sd->pointer.obj = ecore_evas_cursor_unset(sd->ee);
 #endif
 }
@@ -3521,12 +3523,15 @@ _elm_win_frame_cb_move_start(void *data,
if (sd->wl.win)
  ecore_wl2_window_cursor_from_name_set(sd->wl.win, NULL);
 
-   if (!strcmp(source, "elm"))
- _elm_theme_object_set(sd->obj, sd->pointer.obj,
-   "pointer", "base", "move");
-   else
- _elm_theme_object_set(sd->obj, sd->pointer.obj,
-   "pointer", "base", "default");
+   if (sd->pointer.obj)
+ {
+if (!strcmp(source, "elm"))
+  _elm_theme_object_set(sd->obj, sd->pointer.obj,
+"pointer", "base", "move");
+else
+  _elm_theme_object_set(sd->obj, sd->pointer.obj,
+"pointer", "base", "default");
+ }
 #else
(void)source;
 #endif
@@ -3555,6 +3560,7 @@ _elm_win_frame_cb_move_stop(void *data,
 #ifdef HAVE_ELEMENTARY_WL2
if (sd->wl.win)
  ecore_wl2_window_cursor_from_name_set(sd->wl.win, NULL);
+   if (!sd->pointer.obj) return;
_elm_theme_object_set(sd->obj, sd->pointer.obj, "pointer", "base", 
"default");
 #endif
 }
@@ -3626,6 +3632,8 @@ _elm_win_frame_cb_resize_show(void *data,
Evas_Coord mw = 1, mh = 1, hx = 0, hy = 0;
int i;
 
+   if (!sd->pointer.obj) return;
+
i = sd->rot / 90;
if (!strcmp(source, "elm.event.resize.t"))
  _elm_theme_object_set(sd->obj, sd->pointer.obj, "pointer", "base",
@@ -3678,6 +3686,7 @@ _elm_win_frame_cb_resize_hide(void *data,
if (sd->resizing) return;
 
 #ifdef HAVE_ELEMENTARY_WL2
+   if (!sd->pointer.obj) return;
_elm_theme_object_set(sd->obj, sd->pointer.obj, "pointer", "base", 
"default");
 #endif
 }

-- 

Re: [E-devel] Enlightenment on OpenIndiana

[Daniel McLellan]

I actually got this to build some time ago on OI, and I recall that here
were issues with the preprocessor and comments.   Not sure if this helps.

On Mon, Oct 24, 2016 at 11:30 AM, Aurélien Larcher <
aurelien.larc...@gmail.com> wrote:

> Hi,
> some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
> 1.12.3 for OpenIndiana and it has been provided in our repository
> since then.
> Vincent and Boris kindly helped me back then.
>
> I have been willing to update the packages but applications fail to
> start since my tests with EFL 1.16 and I have not found the time to
> dig further.
>
> Again last week-end I updated our components
>
> https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e
>
> and gave it a try... without success.
>
> While I could run all expedite tests with gl and sdl engines (xlib
> crashes at one test, most likely due to a X11 bug), applications like
> elementary_config, elementary_test, rage, terminology fail to start
> properly: they hang right after the window appears.
> I am trying to figure out if there is a regression in libxcb between
> 1.11 and 1.11.1.
>
> If there is any interest, I would like to provide any debugging
> information that would help Enlightenment become a solid alternative
> to MATE on OpenIndiana.
>
> As I am unfamiliar with the EFL codebase, I do not know which type of
> information would be suitable.
> Find below pstack outputs which may provide a starting point to an
> expert eye (in case similar issue has already been encountered with
> BSDs for instance).
> I can provide more debugging information, tests logs and give ssh
> access to a machine.
>
> Kind regards
>
> Aurelien
>
> 
> 
> helios> pstack `pgrep terminology`
> 12876:terminology
> -  lwp# 1 / thread# 1  
>  feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
>  fe9c8fef ecore_main_loop_begin (febf4409) + 36f
>  febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
>  0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
>  0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
>  08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
> -  lwp# 2 / thread# 2  
>  feefb5b9 lwp_park (0, 0, 0)
>  feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) + 6a
>  feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
> fef6e000, fe698408) + 8f
>  feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
> fe66b000) + 2e
>  feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
>  fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e, 3)
> + 9e
>  fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90240) + 88
>  feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
> -  lwp# 3 / thread# 3  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 4 / thread# 4  
>  fedd1400 _eina_internal_call(), exit value = 0x
> ** zombie (exited, not detached, not yet joined) **
> -  lwp# 5 / thread# 5  
>  feefb5b9 lwp_park (0, 0, 0)
>  feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
> 81428d8) + 19
>  feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
>  fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c) +
> 3f
>  fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
> feed7c7e, 3) + 3f
>  fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda90a40) + 88
>  feefb560 _lwp_start (fda90a40, 0, 0, 0, 0, 0)
> -  lwp# 6 / thread# 6  
>  feeffcc5 pollsys  (fb87fc30, 1, fb87fd68, 0)
>  fee9730f pselect  (13, fb87fde0, fb87fe60, fb87fee0, fb87fd68, 0) + 1bf
>  fee97618 select   (13, fb87fde0, fb87fe60, fb87fee0, fb87fdd8, 41197acd)
> + 8e
>  fe9bde8f _timer_tick_core (0, 83a7f10, fb87ff98, fe9cf948, fee0c000,
> 813a988) + 15f
>  fe9cf96c _ecore_direct_worker (83a7f10, 6, fb87ffc8, fedd1429,
> feed7c7e, 3) + 3c
>  fedd1432 _eina_internal_call (813a988, 0, 0, 0) + 32
>  feefb3cb _thrp_setup (fda91a40) + 88
>  feefb560 _lwp_start (fda91a40, 0, 0, 0, 0, 0)
>
> 
> 
> helios> pstack 9171
> 9171:elementary_test
> -  lwp# 1 / thread# 1  
>  feeff475 __so_recvmsg (a, 80473f8, 8000, 0) + 15
>  fe0dc229 __xnet_recvmsg (a, 80473f8, 0, fd110d4c, 0, 1) + 25
>  fd110122 _xcb_in_read (81eab10, fe37, 80474c8, fe36239b) + 82
>  fd110e71 xcb_poll_for_event (81eab10, 0, 0, feda5550, 0, 81ac380) + 91
>  fd1c2ed5 poll_for_response (fd1c3a49, fd2b6000, 8047538, fd1ae469,
> 

[EGIT] [core/efl] master 07/07: docs: fileselector: improve docs for enum, events and keyword usage

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=cc49d3e1de96c3e6168411a0991b803966d4b1f6

commit cc49d3e1de96c3e6168411a0991b803966d4b1f6
Author: Stefan Schmidt 
Date:   Mon Oct 24 17:41:52 2016 +0200

docs: fileselector: improve docs for enum, events and keyword usage
---
 src/lib/elementary/elm_fileselector.eo   | 10 +-
 src/lib/elementary/elm_fileselector_button.eo|  2 +-
 src/lib/elementary/elm_fileselector_entry.eo |  6 +++---
 src/lib/elementary/elm_interface_fileselector.eo | 17 +
 4 files changed, 18 insertions(+), 17 deletions(-)

diff --git a/src/lib/elementary/elm_fileselector.eo 
b/src/lib/elementary/elm_fileselector.eo
index f6f0bb5..77945b1 100644
--- a/src/lib/elementary/elm_fileselector.eo
+++ b/src/lib/elementary/elm_fileselector.eo
@@ -26,7 +26,7 @@ class Elm.Fileselector (Elm.Layout, 
Elm.Interface.Fileselector,
 ]]
  }
  values {
-visible: bool; [[true to show buttons, false to hide.]]
+visible: bool; [[$true to show buttons, $false to hide.]]
  }
   }
}
@@ -63,10 +63,10 @@ class Elm.Fileselector (Elm.Layout, 
Elm.Interface.Fileselector,
   Elm.Interface.Atspi_Widget_Action.elm_actions.get;
}
events {
-  done;
-  activated;
-  selected,invalid;
-  directory,open;
+  done; [[Called when OK button was pressed]]
+  activated; [[Called when the filesector was activated]]
+  selected,invalid; [[Called when fileselector was selected]]
+  directory,open; [[Called when a directory was opened]]
}
 
 }
diff --git a/src/lib/elementary/elm_fileselector_button.eo 
b/src/lib/elementary/elm_fileselector_button.eo
index 46cd057..5ac08ce 100644
--- a/src/lib/elementary/elm_fileselector_button.eo
+++ b/src/lib/elementary/elm_fileselector_button.eo
@@ -21,7 +21,7 @@ class Elm.Fileselector_Button (Elm.Button, 
Elm.Interface.Fileselector)
   Elm.Interface.Fileselector.mode;
}
events {
-  file,chosen;
+  file,chosen; [[Called when a file was chosen in the fileselector]]
}
 
 }
diff --git a/src/lib/elementary/elm_fileselector_entry.eo 
b/src/lib/elementary/elm_fileselector_entry.eo
index 2b46f04..9481a70 100644
--- a/src/lib/elementary/elm_fileselector_entry.eo
+++ b/src/lib/elementary/elm_fileselector_entry.eo
@@ -25,9 +25,9 @@ class Elm.Fileselector_Entry (Elm.Layout, 
Elm.Interface.Fileselector,
   Efl.Part.part;
}
events {
-  changed;
-  activated;
-  file,chosen;
+  changed; [[Called when the entry changed]]
+  activated; [[Called when the entry was activated]]
+  file,chosen; [[Called when a file was chosen in the fileselector]]
   press;
}
 
diff --git a/src/lib/elementary/elm_interface_fileselector.eo 
b/src/lib/elementary/elm_interface_fileselector.eo
index b888586..3d18012 100644
--- a/src/lib/elementary/elm_interface_fileselector.eo
+++ b/src/lib/elementary/elm_interface_fileselector.eo
@@ -15,14 +15,15 @@ enum Elm.Fileselector.Mode
 
 enum Elm.Fileselector.Sort
 {
-   by_filename_asc = 0,
-   by_filename_desc,
-   by_type_asc,
-   by_type_desc,
-   by_size_asc,
-   by_size_desc,
-   by_modified_asc,
-   by_modified_desc,
+   [[Fileselector sorting modes]]
+   by_filename_asc = 0, [[Alphabetical sort by ascending filename, default]]
+   by_filename_desc, [[Alphabetical sorting by descending filename]]
+   by_type_asc, [[Sort by file type]]
+   by_type_desc, [[Sort by file type description]]
+   by_size_asc, [[Sort by ascending file size]]
+   by_size_desc, [[Sort by descending file size]]
+   by_modified_asc, [[Sort by ascending modified date]]
+   by_modified_desc, [[Sort by descending modified date]]
last [[Sentinel (helper) value, not used.]]
 }
 

-- 

[EGIT] [core/efl] master 02/07: docs: atspi: add docs for events in accessible

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f52dc9792752a46a990b20af40d74c7b5e0bb013

commit f52dc9792752a46a990b20af40d74c7b5e0bb013
Author: Stefan Schmidt 
Date:   Mon Oct 24 13:28:52 2016 +0200

docs: atspi: add docs for events in accessible
---
 src/lib/elementary/elm_interface_atspi_accessible.eo | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/lib/elementary/elm_interface_atspi_accessible.eo 
b/src/lib/elementary/elm_interface_atspi_accessible.eo
index 25e7287..912c7ec 100644
--- a/src/lib/elementary/elm_interface_atspi_accessible.eo
+++ b/src/lib/elementary/elm_interface_atspi_accessible.eo
@@ -433,13 +433,13 @@ mixin Elm.Interface.Atspi_Accessible ()
   }
}
events {
-  property,changed: string;
-  children,changed: Elm.Atspi.Event.Children_Changed.Data;
-  state,changed: Elm.Atspi.Event.State_Changed.Data;
-  bounds,changed: Elm.Atspi.Event.Geometry_Changed.Data;
-  visible,data,changed;
-  active,descendant,changed;
-  added;
-  removed;
+  property,changed: string; [[Called when roperty has changed]]
+  children,changed: Elm.Atspi.Event.Children_Changed.Data; [[Called when 
children have changed]]
+  state,changed: Elm.Atspi.Event.State_Changed.Data; [[Called when tate 
has changed]]
+  bounds,changed: Elm.Atspi.Event.Geometry_Changed.Data; [[Called when 
bounds have changed]]
+  visible,data,changed; [[Called when visibility has changed]]
+  active,descendant,changed; [[Called when active state of descendant has 
changed]]
+  added; [[Called when item was added]]
+  removed; [[Called when item was removed]]
}
 }

-- 

[EGIT] [core/efl] master 04/07: docs: emotion: add missing docs for efl canvas video events

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f8ef2fec5858debb8dca2766f76747de0a938a70

commit f8ef2fec5858debb8dca2766f76747de0a938a70
Author: Stefan Schmidt 
Date:   Mon Oct 24 17:02:23 2016 +0200

docs: emotion: add missing docs for efl canvas video events

Also make use of $true keyword while being there.
---
 src/lib/emotion/efl_canvas_video.eo | 40 ++---
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/src/lib/emotion/efl_canvas_video.eo 
b/src/lib/emotion/efl_canvas_video.eo
index 9715347..b7be070 100644
--- a/src/lib/emotion/efl_canvas_video.eo
+++ b/src/lib/emotion/efl_canvas_video.eo
@@ -40,8 +40,8 @@ class Efl.Canvas.Video (Efl.Canvas.Group, Efl.File, 
Efl.Player, Efl.Image, Efl.I
 \@ref emotion_object_file_set.
   ]]
   legacy: emotion_object_init;
-  return: bool; [[true if the specified module was successfully
-  initialized for this object, false 
otherwise.]]
+  return: bool; [[$true if the specified module was 
successfully
+  initialized for this object, $false 
otherwise.]]
  }
  values {
   module_filename: string; [[The name of the module to be
@@ -77,24 +77,24 @@ class Efl.Canvas.Video (Efl.Canvas.Group, Efl.File, 
Efl.Player, Efl.Image, Efl.I
 Efl.Image.smooth_scale.get;
}
events {
-frame,decode;
-position,change;
-length,change;
-frame,resize;
-playback,start;
-playback,stop;
-volume,change;
-channels,change;
-title,change;
-progress,change;
-ref,change;
-button,num,change;
-button,change;
-open,done;
-position,save,done;
-position,save,fail;
-position,load,done;
-position,load,fail;
+frame,decode; [[Called when the frame was decoded]]
+position,change; [[Called when the position changed]]
+length,change; [[Called when the length changed]]
+frame,resize; [[Called when the frame was resized]]
+playback,start; [[Called when playback started]]
+playback,stop; [[Called when playback stopped]]
+volume,change; [[Called when volume changed]]
+channels,change; [[Called when the channels changed]]
+title,change; [[Called when the title changed]]
+progress,change; [[Called when the progress changed]]
+ref,change; [[Called when ref changed]]
+button,num,change; [[Called when button number changed]]
+button,change; [[Called when button changed]]
+open,done; [[Called when the files was opened]]
+position,save,done; [[Called when the position was saved]]
+position,save,fail; [[Called when saving the position failed]]
+position,load,done; [[Called when the position loaded]]
+position,load,fail; [[Called when loading the position failed]]
}
 }
 

-- 

[EGIT] [core/efl] master 01/07: docs: atspi: add docs for atspi accessible enums

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=cba20188f6437d8ae125b5aae4f00f7b2469c760

commit cba20188f6437d8ae125b5aae4f00f7b2469c760
Author: Stefan Schmidt 
Date:   Mon Oct 24 13:18:26 2016 +0200

docs: atspi: add docs for atspi accessible enums
---
 .../elementary/elm_interface_atspi_accessible.eo   | 332 ++---
 1 file changed, 166 insertions(+), 166 deletions(-)

diff --git a/src/lib/elementary/elm_interface_atspi_accessible.eo 
b/src/lib/elementary/elm_interface_atspi_accessible.eo
index 1bafd34..25e7287 100644
--- a/src/lib/elementary/elm_interface_atspi_accessible.eo
+++ b/src/lib/elementary/elm_interface_atspi_accessible.eo
@@ -12,184 +12,184 @@ enum Elm.Atspi.Type
 enum Elm.Atspi.Role
 {
[[Describes the role of an object visible to AT-SPI Clients.]]
-   invalid,
-   accelerator_label,
-   alert,
-   animation,
-   arrow,
-   calendar,
-   canvas,
-   check_box,
-   check_menu_item,
-   color_chooser,
-   column_header,
-   combo_box,
-   date_editor,
-   desktop_icon,
-   desktop_frame,
-   dial,
-   dialog,
-   directory_pane,
-   drawing_area,
-   file_chooser,
-   filler,
-   focus_traversable,
-   font_chooser,
-   frame,
-   glass_pane,
-   html_container,
-   icon,
-   image,
-   internal_frame,
-   label,
-   layered_pane,
-   list,
-   list_item,
-   menu,
-   menu_bar,
-   menu_item,
-   option_pane,
-   page_tab,
-   page_tab_list,
-   panel,
-   password_text,
-   popup_menu,
-   progress_bar,
-   push_button,
-   radio_button,
-   radio_menu_item,
-   root_pane,
-   row_header,
-   scroll_bar,
-   scroll_pane,
-   separator,
-   slider,
-   spin_button,
-   split_pane,
-   status_bar,
-   table,
-   table_cell,
-   table_column_header,
-   table_row_header,
-   tearoff_menu_item,
-   terminal,
-   text,
-   toggle_button,
-   tool_bar,
-   tool_tip,
-   tree,
-   tree_table,
-   unknown,
-   viewport,
-   window,
-   extended,
-   header,
-   footer,
-   paragraph,
-   ruler,
-   application,
-   autocomplete,
-   editbar,
-   embedded,
-   entry,
-   chart,
-   caption,
-   document_frame,
-   heading,
-   page,
-   section,
-   redundant_object,
-   form,
-   link,
-   input_method_window,
-   table_row,
-   tree_item,
-   document_spreadsheet,
-   document_presentation,
-   document_text,
-   document_web,
-   document_email,
-   comment,
-   list_box,
-   grouping,
-   image_map,
-   notification,
-   info_bar,
-   last_defined,
+   invalid, [[Role: invalid]]
+   accelerator_label, [[Role: accelerator label]]
+   alert, [[Role: alert]]
+   animation, [[Role: animation]]
+   arrow, [[Role: arrow]]
+   calendar, [[Role: calendar]]
+   canvas, [[Role: canvas]]
+   check_box, [[Role: check box]]
+   check_menu_item, [[Role: check menu item]]
+   color_chooser, [[Role: color chooser]]
+   column_header, [[Role: column header]]
+   combo_box, [[Role: combo box]]
+   date_editor, [[Role: data editor]]
+   desktop_icon, [[Role: desktop icon]]
+   desktop_frame, [[Role: desktop frame]]
+   dial, [[Role: dial]]
+   dialog, [[Role: dialog]]
+   directory_pane, [[Role: directory pane]]
+   drawing_area, [[Role: drawing area]]
+   file_chooser, [[Role: file chooser]]
+   filler, [[Role: filler]]
+   focus_traversable, [[Role: focus traversable]]
+   font_chooser, [[Role: font chooser]]
+   frame, [[Role: frame]]
+   glass_pane, [[Role: glass pane]]
+   html_container, [[Role: HTML container]]
+   icon, [[Role: icon]]
+   image, [[Role: image]]
+   internal_frame, [[Role: internal frame]]
+   label, [[Role: label]]
+   layered_pane, [[Role: layered pane]]
+   list, [[Role: list]]
+   list_item, [[Role: list item]]
+   menu, [[Role: menu]]
+   menu_bar, [[Role: menu bar]]
+   menu_item, [[Role: menu item]]
+   option_pane, [[Role: option pane]]
+   page_tab, [[Role: page tab]]
+   page_tab_list, [[Role: page tab list]]
+   panel, [[Role: panel]]
+   password_text, [[Role: password text]]
+   popup_menu, [[Role: popup menu]]
+   progress_bar, [[Role: progress bar]]
+   push_button, [[Role: push button]]
+   radio_button, [[Role: radio button]]
+   radio_menu_item, [[Role: radio menu item]]
+   root_pane, [[Role: root pane]]
+   row_header, [[Role: row header]]
+   scroll_bar, [[Role: scroll bar]]
+   scroll_pane, [[Role: scroll pane]]
+   separator, [[Role: separator]]
+   slider, [[Role: slider]]
+   spin_button, [[Role: spin button]]
+   split_pane, [[Role: split pane]]
+   status_bar, [[Role: status bar]]
+   table, [[Role: table]]
+   table_cell, [[Role: table cell]]
+   table_column_header, [[Role: table column header]]
+   table_row_header, [[Role: table row header]]
+   tearoff_menu_item, [[Role: tearoff menu item]]
+   terminal, [[Role: terminal]]
+   text, [[Role: text]]
+   toggle_button, [[Role: toggle button]]
+   tool_bar, [[Role: too bar]]
+   tool_tip, [[Role: tool tip]]
+   tree, [[Role: tree]]
+   tree_table, [[Role: tree table]]
+   unknown, [[Role: unknown]]
+   viewport, [[Role: 

[EGIT] [core/efl] master 05/07: docs: edje: consistent use of $true and $false keywords

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=e81acf70e67f6111cd266ed70efe38867e4dc125

commit e81acf70e67f6111cd266ed70efe38867e4dc125
Author: Stefan Schmidt 
Date:   Mon Oct 24 17:15:31 2016 +0200

docs: edje: consistent use of $true and $false keywords
---
 src/lib/edje/edje_object.eo | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/src/lib/edje/edje_object.eo b/src/lib/edje/edje_object.eo
index 0ad4b2d..2160275 100644
--- a/src/lib/edje/edje_object.eo
+++ b/src/lib/edje/edje_object.eo
@@ -12,7 +12,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
 [[Edje will automatically update the size hints on itself.
 
   By default edje doesn't set size hints on itself. With this 
function
-  call, it will do so if update is true. Be carefully, it cost a 
lot to
+  call, it will do so if update is $true. Be carefully, it cost a 
lot to
   trigger this feature as it will recalc the object every time it 
make
   sense to be sure that's its minimal size hint is always 
accurate.]]
  }
@@ -37,7 +37,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
   @since 1.1.0]]
  }
  values {
-rtl: bool; [[new value of flag true/false]]
+rtl: bool; [[new value of flag $true/$false]]
  }
   }
   @property language {
@@ -633,7 +633,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
   Note: unlike Evas, Edje colors are not pre-multiplied. That is,
   half-transparent white is 255 255 255 128.]]
 legacy: null;
-return: bool; [[true on sucess, false on failure.]]
+return: bool; [[$true on sucess, $false on failure.]]
  }
  get {
 [[Get Edje color class.
@@ -648,7 +648,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
   Note: unlike Evas, Edje colors are not pre-multiplied. That is,
   half-transparent white is 255 255 255 128.]]
 legacy: null;
-return: bool; [[true if found or false if not found and all values
+return: bool; [[$true if found or $false if not found and all 
values
 are zeored.]]
  }
  keys {
@@ -697,7 +697,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
   Note: unlike Evas, Edje colors are not pre-multiplied. That is,
   half-transparent white is 255 255 255 128.]]
 legacy: null;
-return: bool; [[true if found or false if not found and all
+return: bool; [[$true if found or $false if not found and all
 values are zeroed.]]
  }
  keys {
@@ -1342,7 +1342,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
 part: string; [[The part name]]
  }
  values {
-prediction: bool; [[If true, the prediction feature is allowed.]]
+prediction: bool; [[If $true, the prediction feature is allowed.]]
  }
   }
   part_text_hide_visible_password {
@@ -1507,7 +1507,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
  get {
 [[Returns whether the cursor points to a format.
   \@ref evas_textblock_cursor_is_format]]
-return: bool; [[true if it's true, false otherwise.]]
+return: bool; [[$true if the cursor points to a format, $false 
otherwise.]]
  }
  keys {
 part: string; [[The part name]]
@@ -1516,10 +1516,10 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
   }
   @property part_text_cursor_is_visible_format {
  get {
-[[Return true if the cursor points to a visible format
+[[Return $true if the cursor points to a visible format
   For example \\t, \\n, item and etc.
   \@ref evas_textblock_cursor_format_is_visible_get]]
-return: bool; [[true if it's true, false otherwise.]]
+return: bool; [[$true if the cursor points to a visible format, 
$false otherwise.]]
  }
  keys {
 part: string; [[The part name]]
@@ -1552,7 +1552,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, Efl.File, 
Efl.Container, Efl.Part)
 part: string; [[The part name]]
  }
  values {
-allow: bool; [[true to enable, false otherwise]]
+allow: bool; [[$true to enable, $false otherwise]]
  }
   }
   part_text_select_begin @const {
@@ -1815,7 +1815,7 @@ class Edje.Object (Efl.Canvas.Group.Clipped, 

[EGIT] [core/efl] master 03/07: docs: eo: make consistent use of $true in docs

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=ea7c0ca516fae86bc99c6328accda259bd0d5de2

commit ea7c0ca516fae86bc99c6328accda259bd0d5de2
Author: Stefan Schmidt 
Date:   Mon Oct 24 16:52:48 2016 +0200

docs: eo: make consistent use of $true in docs

Make use of the $true keyword instead of going with Ein_True or just true. 
We
need to change this tree-wide in the docs.
---
 src/lib/eo/efl_object.eo | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/src/lib/eo/efl_object.eo b/src/lib/eo/efl_object.eo
index 537a179..703c53f 100644
--- a/src/lib/eo/efl_object.eo
+++ b/src/lib/eo/efl_object.eo
@@ -3,9 +3,9 @@ import eina_types;
 struct Efl.Event.Description {
 [[This struct holds the description of a specific event.]]
 name: string; [[name of the event.]]
-unfreezable: bool; [[Eina_True if the event cannot be frozen.]]
-legacy_is: bool; [[Internal use: if is a legacy event.]]
-restart: bool; [[Eina_True if when the event is triggered again from a 
callback, it should start from where it was]]
+unfreezable: bool; [[$true if the event cannot be frozen.]]
+legacy_is: bool; [[Internal use: $true if a legacy event.]]
+restart: bool; [[$true if when the event is triggered again from a 
callback, it should start from where it was]]
 }
 
 struct Efl.Event {
@@ -322,7 +322,7 @@ abstract Efl.Object ()
callbacks of the same priority are called in reverse order of
creation.
  ]]
- return: bool; [[Return true when the callback has been successfully 
added.]]
+ return: bool; [[Return $true when the callback has been successfully 
added.]]
  params {
 @in desc: ref(const(Efl.Event.Description)); [[The description of 
the event to listen to]]
 @in priority: Efl.Callback_Priority; [[The priority of the 
callback]]
@@ -332,7 +332,7 @@ abstract Efl.Object ()
   }
   event_callback_del {
  [[Del a callback with a specific data associated to it for an event.]]
- return: bool; [[Return true when the callback has been successfully 
removed.]]
+ return: bool; [[Return $true when the callback has been successfully 
removed.]]
  params {
 @in desc: ref(const(Efl.Event.Description)); [[The description of 
the event to listen to]]
 @in func: Efl.Event_Cb; [[the callback to delete]]
@@ -347,7 +347,7 @@ abstract Efl.Object ()
callbacks of the same priority are called in reverse order of
creation.
  ]]
- return: bool; [[Return true when the callback has been successfully 
added.]]
+ return: bool; [[Return $true when the callback has been successfully 
added.]]
  params {
 @in array: ref(const(Efl.Callback_Array_Item)); [[an 
#Efl_Callback_Array_Item of events to listen to]]
 @in priority: Efl.Callback_Priority; [[The priority of the 
callback]]
@@ -358,7 +358,7 @@ abstract Efl.Object ()
  [[Del a callback array with a specific data associated to it for an
event.
  ]]
- return: bool; [[Return true when the callback has been successfully 
removed.]]
+ return: bool; [[Return $true when the callback has been successfully 
removed.]]
  params {
 @in array: ref(const(Efl.Callback_Array_Item)); [[an 
#Efl_Callback_Array_Item of events to listen to]]
 @in user_data: const(void_ptr); [[The data to compare]]

-- 

[EGIT] [core/efl] master 06/07: docs: ecore: make consistent use of $true and $false keywords in docs

[Stefan Schmidt]

stefan pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f4ae4bfb69a70c5343f0ccaa88ea0d420e00427d

commit f4ae4bfb69a70c5343f0ccaa88ea0d420e00427d
Author: Stefan Schmidt 
Date:   Mon Oct 24 17:21:48 2016 +0200

docs: ecore: make consistent use of $true and $false keywords in docs
---
 src/lib/ecore/ecore_poller.eo | 2 +-
 src/lib/ecore/efl_loop.eo | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/lib/ecore/ecore_poller.eo b/src/lib/ecore/ecore_poller.eo
index e0e2dec..d1703e9 100644
--- a/src/lib/ecore/ecore_poller.eo
+++ b/src/lib/ecore/ecore_poller.eo
@@ -42,7 +42,7 @@ class Ecore.Poller (Efl.Object)
  [[Polling interval rate of the poller.]]
  set {
 legacy: ecore_poller_poller_interval_set;
-return: bool; [[true on success, false on failure.]]
+return: bool; [[$true on success, $false on failure.]]
  }
  get {
 legacy: ecore_poller_poller_interval_get;
diff --git a/src/lib/ecore/efl_loop.eo b/src/lib/ecore/efl_loop.eo
index e416e1f..2cd3e24 100644
--- a/src/lib/ecore/efl_loop.eo
+++ b/src/lib/ecore/efl_loop.eo
@@ -2,7 +2,7 @@ import efl_types;
 
 struct Efl.Loop.Arguments {
argv: const(array);
-   initialization: bool; [[Set to true when the program should initialize its 
internal state. This happen once per process instance.]]
+   initialization: bool; [[Set to $true when the program should initialize its 
internal state. This happen once per process instance.]]
 }
 
 class Efl.Loop (Efl.Object)
@@ -89,7 +89,7 @@ class Efl.Loop (Efl.Object)
 @in klass: const(Efl.Class); [[The class provided by the 
registered provider.]]
 @in provider: const(Efl.Object); [[The provider for the newly 
registered class that has to provide that said Efl.Class.]]
  }
- return: bool; [[true if successfully register, false otherwise.]]
+ return: bool; [[$true if successfully register, $false otherwise.]]
   }
   unregister {
  [[Will unregister a manager of a specific class that was previously 
registered and answered by eo.provider_find.]]
@@ -97,7 +97,7 @@ class Efl.Loop (Efl.Object)
 @in klass: const(Efl.Class); [[The class provided by the provider 
to unregister for.]]
 @in provider: const(Efl.Object); [[The provider for the registered 
class to unregister.]]
  }
- return: bool; [[true if successfully unregistered, false otherwise.]]
+ return: bool; [[$true if successfully unregistered, $false 
otherwise.]]
   }
}
events {

-- 

[E-devel] Enlightenment on OpenIndiana

[Aurélien Larcher]

Hi,
some time ago I packaged Enlightenement 0.19.3 then 0.19.5 with EFL
1.12.3 for OpenIndiana and it has been provided in our repository
since then.
Vincent and Boris kindly helped me back then.

I have been willing to update the packages but applications fail to
start since my tests with EFL 1.16 and I have not found the time to
dig further.

Again last week-end I updated our components

https://github.com/alarcher/oi-userland/tree/e_latest/components/desktop/e

and gave it a try... without success.

While I could run all expedite tests with gl and sdl engines (xlib
crashes at one test, most likely due to a X11 bug), applications like
elementary_config, elementary_test, rage, terminology fail to start
properly: they hang right after the window appears.
I am trying to figure out if there is a regression in libxcb between
1.11 and 1.11.1.

If there is any interest, I would like to provide any debugging
information that would help Enlightenment become a solid alternative
to MATE on OpenIndiana.

As I am unfamiliar with the EFL codebase, I do not know which type of
information would be suitable.
Find below pstack outputs which may provide a starting point to an
expert eye (in case similar issue has already been encountered with
BSDs for instance).
I can provide more debugging information, tests logs and give ssh
access to a machine.

Kind regards

Aurelien


helios> pstack `pgrep terminology`
12876:terminology
-  lwp# 1 / thread# 1  
 feeff915 getpid   (fafc, 400fa919, 8046118, fe9c8db9) + 15
 fe9c8fef ecore_main_loop_begin (febf4409) + 36f
 febf4417 elm_run  (0, 0, 752f0031, 81414f0, 40001415, 0) + 17
 0806a559 elm_main (1, 804769c, 8047668, 806aa0d, 80bc000, 8047648) + e59
 0806aa26 main (804765c, fef786e8, 8047690, 8062cb3, 1, 804769c) + 36
 08062cb3 _start   (1, 80477fc, 0, 8047808, 8047824, 804782f) + 83
-  lwp# 2 / thread# 2  
 feefb5b9 lwp_park (0, 0, 0)
 feef55f8 cond_wait_queue (fe698408, fe6983ec, 0, 1, 83088f8, 83088f8) + 6a
 feef5c70 __cond_wait (fe698408, fe6983ec, fe657c9a, fe66b000,
fef6e000, fe698408) + 8f
 feef5cc4 cond_wait (fe698408, fe6983ec, fe50123b, fe5cf036, fe65965a,
fe66b000) + 2e
 feef5d0d pthread_cond_wait (fe698408, fe6983ec, fdb9ef98, fe5ced59) + 24
 fe5cedde evas_thread_worker_func (0, 2, fdb9efc8, fedd1429, feed7c7e, 3) + 9e
 fedd1432 _eina_internal_call (80bf5c0, 0, 0, 0) + 32
 feefb3cb _thrp_setup (fda90240) + 88
 feefb560 _lwp_start (fda90240, 0, 0, 0, 0, 0)
-  lwp# 3 / thread# 3  
 fedd1400 _eina_internal_call(), exit value = 0x
** zombie (exited, not detached, not yet joined) **
-  lwp# 4 / thread# 4  
 fedd1400 _eina_internal_call(), exit value = 0x
** zombie (exited, not detached, not yet joined) **
-  lwp# 5 / thread# 5  
 feefb5b9 lwp_park (0, 0, 0)
 feeef15e sema_wait (81428d8, fef726c0, fd97ef28, feef41d9, fee0c000,
81428d8) + 19
 feee22cd sem_wait (81428d8, fee10018, fda90a40, feef3e46) + 35
 fedd24af eina_thread_queue_wait (8142898, fd97ef7c, fd97ef98, fe5c5c9c) + 3f
 fe5c5cbf _evas_common_scale_sample_thread (0, 5, fd97efc8, fedd1429,
feed7c7e, 3) + 3f
 fedd1432 _eina_internal_call (8199d80, 0, 0, 0) + 32
 feefb3cb _thrp_setup (fda90a40) + 88
 feefb560 _lwp_start (fda90a40, 0, 0, 0, 0, 0)
-  lwp# 6 / thread# 6  
 feeffcc5 pollsys  (fb87fc30, 1, fb87fd68, 0)
 fee9730f pselect  (13, fb87fde0, fb87fe60, fb87fee0, fb87fd68, 0) + 1bf
 fee97618 select   (13, fb87fde0, fb87fe60, fb87fee0, fb87fdd8, 41197acd) + 8e
 fe9bde8f _timer_tick_core (0, 83a7f10, fb87ff98, fe9cf948, fee0c000,
813a988) + 15f
 fe9cf96c _ecore_direct_worker (83a7f10, 6, fb87ffc8, fedd1429,
feed7c7e, 3) + 3c
 fedd1432 _eina_internal_call (813a988, 0, 0, 0) + 32
 feefb3cb _thrp_setup (fda91a40) + 88
 feefb560 _lwp_start (fda91a40, 0, 0, 0, 0, 0)


helios> pstack 9171
9171:elementary_test
-  lwp# 1 / thread# 1  
 feeff475 __so_recvmsg (a, 80473f8, 8000, 0) + 15
 fe0dc229 __xnet_recvmsg (a, 80473f8, 0, fd110d4c, 0, 1) + 25
 fd110122 _xcb_in_read (81eab10, fe37, 80474c8, fe36239b) + 82
 fd110e71 xcb_poll_for_event (81eab10, 0, 0, feda5550, 0, 81ac380) + 91
 fd1c2ed5 poll_for_response (fd1c3a49, fd2b6000, 8047538, fd1ae469,
8239780, fedcb840) + 135
 fd1c34cf _XEventsQueued (8239780, 2, fecf68fb, fed14000) + 5f
 fd1b2712 XPending (8239780, 8168910, fecff0d0, feda681b) + 62
 fe56c14a _ecore_x_fd_handler_buf (8239780, 816aad0, 80475b8, feda53d2) + 1a
 feda6854 _ecore_main_fd_handlers_buf_call (fed1469c, 3f, edb4,
4005c842, fed1469c, 8047610) + 74
 feda8d6e ecore_main_loop_begin (feda9039, fedcb000, 8047648,
feda6114, 4102, 8168960) + ee
 feda9047 

Re: [E-devel] Making documentation for all elements of a eo file mandatory for new files

[Stefan Schmidt]

Hello.

On 24/10/16 10:27, Stefan Schmidt wrote:
> Hello.
>
> On 24/10/16 05:15, Jean-Philippe André wrote:
>> Hi Stefan,
>>
>> On 22 October 2016 at 07:43, Stefan Schmidt  wrote:
>>
>> I assume gendoc.lua should be run against /share/eolian/include
>> rather than the internal lib folder?
>
> Well, with your effort to remove many of the unnecessary installed EO
> files this makes sense. So far it did not really make much of a
> difference thought and allowed for quicker testing (no need to make sure
> all old EO files are removed and installing the latest before running
> docgen)
>
>> This unfortunately fails with "bad argument #2 to
>> 'eolian_function_scope_get' (cannot convert 'nil' to 'unsigned int')".
>
> Hmm, I will see if I can reproduce this. Maybe Daniel does know more.

I had to remove all installed eo files first but after this and a frsh 
install of efl it works for me:

stefan@workmachine efl (master) $ find /usr/local/ -name *.eo | wc -l
323
stefan@workmachine efl (master) $ elua 
/usr/local/share/elua/apps/gendoc.lua /usr/local/share/eolian/include/
=== CLASS SECTION: 263 out of 843 (31%) ===

Classes:   240 (documented:   88 or  37%)
Interfaces: 55 (documented:   21 or  38%)
Mixins: 28 (documented:   28 or 100%)
Events:520 (documented:  126 or  24%)

=== FUNCTION SECTION: 6053 out of 7309 (83%) ===

Methods:   940 (documented:  861 or  92%)
   Method params:  1519 (documented: 1293 or  85%)
   Method returns:  451 (documented:  286 or  63%)
Getters:  1015 (documented:  934 or  92%)
   Getter returns:  163 (documented:  105 or  64%)
   Getter keys: 118 (documented:   89 or  75%)
   Getter values:  1133 (documented:  866 or  76%)
Setters:   814 (documented:  749 or  92%)
   Setter returns:   71 (documented:   45 or  63%)
   Setter keys:  57 (documented:   49 or  86%)
   Setter values:  1028 (documented:  776 or  75%)

=== TYPE SECTION: 1230 out of 1756 (70%) ===

Aliases:79 (documented:9 or  11%)
Structs:81 (documented:   57 or  70%)
Struct fields: 191 (documented:  156 or  82%)
Enums: 167 (documented:  151 or  90%)
Enum fields:  1238 (documented:  857 or  69%)

=== VARIABLE SECTION: 56 out of 56 (100%) ===

Constants:   0 (documented:0 or 100%)
Globals:56 (documented:   56 or 100%)

=== TOTAL: 7602 out of 9964 (76%) ===

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Making documentation for all elements of a eo file mandatory for new files

[Stefan Schmidt]

Hello.

On 24/10/16 11:27, Jean-Philippe André wrote:
> Hey Stefan,
>
> On 24 October 2016 at 17:27, Stefan Schmidt  wrote:
>>
>> [...]
>>> Also, I would argue that quite often an obvious parameter, getter return,
>>> etc... doesn't need to be documented, so the goal shouldn't be 100%
>>> coverage :)
>>
>> I expected that someone will bring this up. :)
>>
>> What is the real downside of doing it thought? It will cost you 2
>> seconds to write the doc for the return. Initially it will look obvious
>> and it might stay this way. It could also happen that some special
>> conditions need to be added. With the switch to a wiki based doc system
>> we also want to lower the barrier for users to contribute (on the wiki
>> side and not in the repo directly). Giving them the basic doc at hand to
>> edit and extent is important in my opinion.
>>
>> Even obvious parameters like len look a lot better being described as
>> "Length of the appended string" in the docs.
>>
>> A last, very selfish, argument is that giving out exceptions for some
>> cases makes it hard to track if we have all the needed other bits
>> documented (tooling can not make the decision here if somethign is so
>> obvious that it does not need a doc. That is even a different taste
>> between people. :))
>> 
>>
>
> In fact, it's a matter of choice. I agree with you as well (yes, I'm
> contradicting myself).
>
> Either the documentation generator duplicates the string or a human does it.
> I'm fine with either. Human-written doc can potentially look better but it
> means we'll have a lot of empty spots until we fill them in.

Sure, but we are not to bad. With 76% off all items covered. That is 
even for files that will not be part of our public API.

When we focus on the eo files meant as public API (removing non public 
eo files from install and running the generator on the installed files 
only) we wil have a reduced total number and, maybe, a higher documented 
level.

In any case I'm willing to bring this forward and will continue to work 
on the empty spots.

> As for stalling the documentation work, I believe the more you will expose
> those stats and doc pages, the more incentive we will have to remove
> excessive eo files and document those that need to be.

I hope so to :)

Maybe I should add them to the QA report each week. (and rename it to 
Stefan's weekly statistic newsletter. ;))

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Weekly news from the automated build and QA front

[Stefan Schmidt]

Hello.

Summary:
o The DNS lookup problem is not fixed so no build job have been run last 
week
o Coverity, CI and unit test runs are outdated (besides the failed builds)


This should give everyone an overview over what has happened in the last
week on the QA front. The numbers in parentheses reflect the values from
last week to give you a trend.

CI:
o Overall build statistic: 38.92% (12.43%) failed.
https://build.enlightenment.org/

Unit tests:
o 886 (886) unit tests for efl

Coverage:
o EFL total coverage is at N/A (N/A) lines, N/A (N/A) functions and N/A 
(N/A) branches
https://build.enlightenment.org/view/Test%20Coverage/

Coverity:
o EFL: Outstanding defects 85 (85) with a density of 0.08 (0.08)
o Enlightenment: Outstanding defects 1 (1) with a density of 0 (0)
o Terminology: Outstanding defects 0 (0) with a density of 0 (0)
o Rage: Outstanding defects 0 (0) with a density of 0 (0)

Phab:
o Total bug count: 988 (983)
https://phab.enlightenment.org/maniphest/report/burn/
o Pending patch reviews: 99 (107)

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Making documentation for all elements of a eo file mandatory for new files

[Jean-Philippe André]

Hey Stefan,

On 24 October 2016 at 17:27, Stefan Schmidt  wrote:
>
> [...]
> > Also, I would argue that quite often an obvious parameter, getter return,
> > etc... doesn't need to be documented, so the goal shouldn't be 100%
> > coverage :)
>
> I expected that someone will bring this up. :)
>
> What is the real downside of doing it thought? It will cost you 2
> seconds to write the doc for the return. Initially it will look obvious
> and it might stay this way. It could also happen that some special
> conditions need to be added. With the switch to a wiki based doc system
> we also want to lower the barrier for users to contribute (on the wiki
> side and not in the repo directly). Giving them the basic doc at hand to
> edit and extent is important in my opinion.
>
> Even obvious parameters like len look a lot better being described as
> "Length of the appended string" in the docs.
>
> A last, very selfish, argument is that giving out exceptions for some
> cases makes it hard to track if we have all the needed other bits
> documented (tooling can not make the decision here if somethign is so
> obvious that it does not need a doc. That is even a different taste
> between people. :))
> 
>

In fact, it's a matter of choice. I agree with you as well (yes, I'm
contradicting myself).

Either the documentation generator duplicates the string or a human does it.
I'm fine with either. Human-written doc can potentially look better but it
means we'll have a lot of empty spots until we fill them in.


As for stalling the documentation work, I believe the more you will expose
those stats and doc pages, the more incentive we will have to remove
excessive eo files and document those that need to be.


Best regards,

-- 
Jean-Philippe André
--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EFL cross compilation for Windows

[Stefan Schmidt]

Hello.

On 21/10/16 16:44, Andrii Kroitor wrote:
> Yes, this allows to compile working binaries for Windows from Linux system.
> At least after this patch will be merged:
> https://phab.enlightenment.org/D4357
>
> I have not tried to build python efl yet, but I can check it next week.
>
> It is possible to prepare precompiled packages, but I'm not familiar
> with package maintenance and distribution.
> So I have a few question about this:
> What should be included into package?
> - binaries (for sure)
> - includes and other installed files?
> - some meta info about package?
> - all dependencies or only their list?


I honestly have no clue at all how windows packaging is done. What I 
would expect as a user or developer is thought that all binaries, 
dll/libs and header files are installed so I can start developing with it.

> Where can they be hosted? Win-builds are inactive for a long time, so I
> doubt that we can reach their maintainer.

Vincent said he is in contact with him. Maybe reach out to him if the 
are plans for a new release?

> Should these packages be updated and uploaded manually?

If the path with win builds does not work out we could host the windows 
binaries next to our source tarballs. Only for releases thought.

> It would be perfect if someone has working build server able to build
> EFL on Linux so we could add Windows build to it.

Before anyone screams Jenkins here. I will only consider new things it 
handles when its current problems are sorted and we have a longer period 
of stable usage.

We had cross builds for efl with mingw for some time but the cross build 
slave started crashing and after this dragged out for over a year I 
disabled the mingw builds.

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Stefan Schmidt]

Hello.

On 13/09/16 00:31, Simon Lees wrote:
>
>
> On 09/13/2016 12:28 AM, Stefan Schmidt wrote:
>> Hello.
>>
>> On 10/09/16 01:29, Cedric BAIL wrote:
>>> Hello,
>>>
>>> I fully agree with Andrew. I have yet to review what still need to be
>>> done regarding Efl new interface task, but I hope that 1.19 will be
>>> our final call. We do now have time to cleanup example and check that
>>> things look fine.
>>
>> Please correct me if I did not get you two correctly here.
>>
>> You both think we should release 1.19 only once the interface work is
>> fully done? Be it in 3 months or in a year?
>>
>
> I think we should still aim for whatever has been set but the interface
> work should be treated as a showstopper bug ie if something is still
> missing or not quite finished we wait.

Makes me think of e17. :P

regards
Stefan Schmidt

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Schedule discussion for 1.19

[Stefan Schmidt]

Hello.

On 12/09/16 19:01, Cedric BAIL wrote:
> On Mon, Sep 12, 2016 at 7:58 AM, Stefan Schmidt  
> wrote:
>> Hello.
>>
>> On 10/09/16 01:29, Cedric BAIL wrote:
>>> Hello,
>>>
>>> I fully agree with Andrew. I have yet to review what still need to be
>>> done regarding Efl new interface task, but I hope that 1.19 will be
>>> our final call. We do now have time to cleanup example and check that
>>> things look fine.
>>
>> Please correct me if I did not get you two correctly here.
>>
>> You both think we should release 1.19 only once the interface work is
>> fully done? Be it in 3 months or in a year?
>
> I hope that we will be done by November.


You still hope this?

I see the old pattern we had with feature based releases creeping in 
again. We Say we can't release until X is done. Everybody work on Y and 
Z and X does only progress slowly.

The goal with time based releases was to de-couple this and get a 
release out with Y and Z ready while work on X keeps going and at some 
point X will be done and it will be in the next release.

The whole style of not releasing until X is done is really only fine in 
theory. Its not like everybody would have a unified view here and would 
jump on the tasks and the threat of the release only going out when done 
would speed things up.

What I see is the opposite to be honest. 1.18 was released over two 
months ago and the thing everybody wants as blocker for 1.19 
(interfaces) is progressing slowly and maybe even declining. At least 
that is my feeling from what I see in the repo, the ml and IRC.

(Nobody working on interfaces should feel being blamed here thought. 
This work is huge. But because it is so huge and important to get done 
well I would like to see this de-coupled from the release process)

regards
Stefan Schmidt


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Making documentation for all elements of a eo file mandatory for new files

[Stefan Schmidt]

Hello.

On 24/10/16 05:15, Jean-Philippe André wrote:
> Hi Stefan,
>
> On 22 October 2016 at 07:43, Stefan Schmidt  wrote:
>
>> Hello.
>>
>> TL;DR: If you are committing new eo files I expect them to have full
>> docs from now one. Also help with the ones you are currently working on.
>>
>> Longer version:
>> If you look at the commit log you can see that I started another crusade
>> on getting our doc coverage for eo files.
>>
>> Right now we have the following stats for our documentation efforts:
>>
>> === CLASS SECTION: 269 out of 864 (31%) ===
>>
>> Classes:   255 (documented:   93 or  36%)
>> Interfaces: 57 (documented:   22 or  39%)
>> Mixins: 28 (documented:   28 or 100%)
>> Events:524 (documented:  126 or  24%)
>>
>> === FUNCTION SECTION: 6440 out of 7790 (83%) ===
>>
>> Methods:  1016 (documented:  936 or  92%)
>>Method params:  1667 (documented: 1401 or  84%)
>>Method returns:  493 (documented:  310 or  63%)
>> Getters:  1059 (documented:  970 or  92%)
>>Getter returns:  175 (documented:  105 or  60%)
>>Getter keys: 120 (documented:   89 or  74%)
>>Getter values:  1197 (documented:  924 or  77%)
>> Setters:   845 (documented:  779 or  92%)
>>Setter returns:   69 (documented:   43 or  62%)
>>Setter keys:  57 (documented:   49 or  86%)
>>Setter values:  1092 (documented:  834 or  76%)
>>
>> === TYPE SECTION: 1240 out of 1775 (70%) ===
>>
>> Aliases:84 (documented:9 or  11%)
>> Structs:82 (documented:   57 or  70%)
>> Struct fields: 191 (documented:  156 or  82%)
>> Enums: 170 (documented:  154 or  91%)
>> Enum fields:  1248 (documented:  864 or  69%)
>>
>> === VARIABLE SECTION: 56 out of 56 (100%) ===
>>
>> Constants:   0 (documented:0 or 100%)
>> Globals:56 (documented:   56 or 100%)
>>
>> === TOTAL: 8005 out of 10485 (76%) ===
>>
>> Which means we have 2480 undocumented items.
>>
>> I'm willing to work on this and I actually doing it already but if your
>> working area covers some eo files please make sure that you document all
>> bits in there. Some might look silly on a first glace (enums fields,
>> etc) but getting this to a 100% coverage, and keeping it, really helps
>> the doc efforts. We are using these to generate our documentation and
>> after some time for setup and migration of the older doxygen docs we
>> will switch to them. An example how they look like is here (design and
>> layout is up for suggestions but need to stay aligned with our www theme
>> to have a consistent look):
>> https://devs.enlightenment.org/~stefan/dokuwiki/doku.php?
>> id=docs:efl:auto:reference
>>
>> To keep track on the progress you can use:
>> src/bin/elua/elua src/scripts/elua/apps/gendoc.lua -src/lib/
>>
>> To get an output of what items are still need docs use the verbose flag:
>> src/bin/elua/elua src/scripts/elua/apps/gendoc.lua -v src/lib/
>
>
>
> Thanks for sharing this.
>
> One thing to note though is that a massive number of undocumented APIs are
> not meant to be part of our EO set of APIs. Either because they are not
> well (re)designed (eg. Ecore_Audio) or because they are meant to be
> internals (eg. Ector).

Yeah, I know. You brought this very valid point up once before and I did 
not forget about it. It leads to stalling the documentation effort 
thought. When you brouht it up I stopped the effort and thought I will 
wait until 1.18 is out and the current EO files are final. Didn't happen 
and we are still off by a good margin to come to this state. I feel I 
might even better keep going here and spent some later obsolete time on 
eo files instead of not working on it at all. :)

None the less your refresher is appreciated and I will try to keep the 
various areas in mind and focus on others.


  I'll try to remove some of the EO files from the
> install, step by step.

:)

> I assume gendoc.lua should be run against /share/eolian/include
> rather than the internal lib folder?

Well, with your effort to remove many of the unnecessary installed EO 
files this makes sense. So far it did not really make much of a 
difference thought and allowed for quicker testing (no need to make sure 
all old EO files are removed and installing the latest before running 
docgen)

> This unfortunately fails with "bad argument #2 to
> 'eolian_function_scope_get' (cannot convert 'nil' to 'unsigned int')".

Hmm, I will see if I can reproduce this. Maybe Daniel does know more.

> Also, I would argue that quite often an obvious parameter, getter return,
> etc... doesn't need to be documented, so the goal shouldn't be 100%
> coverage :)

I expected that someone 

Re: [E-devel] [RFC] One binary to rule them all, packagers opinion needed

[Stefan Schmidt]

Hello.

On 22/10/16 00:53, Cedric BAIL wrote:
> On Fri, Oct 21, 2016 at 3:31 PM, Stefan Schmidt  
> wrote:
>> On 22/10/16 00:14, Cedric BAIL wrote:
>>> Before I embark on a crazy idea that may just break everything, I
>>> would like to get some feedback. So one of the problem we are facing
>>> with EFL is that with all those separated library we end up with some
>>> serious time during application startup dedicated to linking. A work
>>> around has been quicklaunch, but it is mostly unused. Also it does
>>> only improve things once it has started, not much during startup time
>>> where you still have to do all the linking.
>>>
>>> With PIE and -rdynamic that we use today on quicklaunch binary, we use
>>> dlopen to get symbol from it and load this binary as if they were
>>> library... So maybe we can actually use that same mechanism to
>>> actually statically link efl with the quicklaunch server binary and
>>> make all efl .so library just a symlink to that binary. Now,
>>> enlightenment could actually try to rely on quicklaunch to start
>>> itself and start other application. This should speed up boot time and
>>> application start up time. The reason to make it the default way of
>>> doing things is to make sure that it is maintained and work.
>>
>> Are there actual numbers about speed improvement? Are we really needed
>> this speedup so badly? As you can already see from this two sentences
>> I'm not really in favor of it. See below for some arguments.
>
> Yes, it does, but really depends on your hardware.

And by making it the default your are forcing this quite ugly change to 
all EFL users while only certain hardware setups would really see a 
significant benefit.

  For example, on
> Raspberry Pi out of the 4s it takes to startup elemines, 1s can be
> saved by quicklaunch. We are talking of a 25% improvement here. It
> will also likely push us to improve further quicklaunch
> infrastructure.

4 seconds?? Full 4 seconds to get started? I have a hard time to believe 
that. Maybe some of the system configuration is badly? Really slow SD 
card? And anyway, what does elimines do the other 3 seconds of startup?

Does other efl apps have the same problem? Terminology? Rage?
You are asking for a drastic change with quite some downsides here so I 
hope it is not just based on data from one app in one hardware 
configuration. :)

  We should be able to preconnect to X/Wayland and save
> for the new process that is starting. We should also be able to pre
> load the theme which would also save a lot of memory as those data
> would be shared among all process. Elementary should be able to pre
> load profile too and save that to every process. So first step is a
> 25% win for sure. Further down the line, I bet we can save up to 60%
> of our startup time. Basically some people are trying to push E/EFL
> even further into smaller embeded device and they are requesting our
> assistance.


You are asking for it as default! Not as some way to make EFL better 
suited for specific scenarios. A big difference in my eyes. I understand 
the not being tested problem well enough (I deal with not normally 
tested code paths myself during all the QA work), but that should not 
mean we make something very specific our default. Default should be 
generic. e are not enabling architecture based compiler optimizations 
either but leave that to the user.

>>> Now some of the drawback. First it is a trick, meaning most people
>>> that will try to dig in will get confused at first on what is going on
>>> and we need to document it. Building EFL is going to become even more
>>> complex (I don't know yet how to generate the proper symlink), let's
>>> enjoy more of the autofoo dark art.
>>
>> To be honest here, this one alone is a killer in my opinion. What we
>> have is already complex enough. I often enough find myself in situation
>> where I bang my head against the wall until I get the system to do what
>> I want.
>
> Yes, that is not going to improve this way for sure.

I your proposal we would just need to live with this?

>>>   All binary will happear as if they
>>> are just a fork of enlightenment and you will need to use some flags
>>> to ps/top and friends to ask them to read /proc to get the new command
>>> line otherwise all binary have the same name.
>>
>> And that one is the nail in the coffin in my opinion.
>>
>>> I think that quicklaunch will require also to be improved by being
>>> made more robust/with a larger set of feature (nicely opposing goal).
>>> Eventually it should handle application restart for example (What
>>> enlightenment_start does today)... which annoy me a bit. Also we would
>>> likely be on a path to reimplement systemd --user here. Something I
>>> have tried to avoid for some time.
>>>
>>> Ok, does anyone see some serious blocker to this idea ? Impact on
>>> packager to much ? Something I missed ? Something that need to be
>>> clarified ?
>>
>> I have a hard time to see that 

Re: [E-devel] [EGIT] [core/efl] master 01/02: evas_callbacks: restore error message behaviour from MAGIC_CHECK

[Jean-Philippe André]

On 24 October 2016 at 16:45, Jean-Philippe André  wrote:

>
>
> On 24 October 2016 at 16:11,  wrote:
>
>> On Mon, Oct 24, 2016 at 12:21:19PM +0900, Jean-Philippe André wrote:
>> > Hey Marcel,
>> >
>> > On 23 October 2016 at 16:45,  wrote:
>> >
>> > > I am not wondering thats its YOU dont who dont like my change... :)
>> > >
>> > > Well there are two reasons to NOT have a Error message.
>> > >
>> > > First, it was before like that, so before it was completly valid, no
>> > > error, now you will have a shitload of error messages in your console.
>> > > Which was the case since evas_object_event_callback_del_full was
>> called
>> > > on cursor objects, undependent from if they are NULL or not. So if you
>> > > dont want to have this NULL check, feel free the go to all api calls
>> in
>> > > EFL and check if they are valid.
>> > >
>> > > Also, complete eo works like that, if you call things on a NULL
>> object,
>> > > nothing will happen ... So i guess the same for evas_object_*
>> functions
>> > > should be the case.
>> > >
>> > > So no, its a correct usecase.
>> > >
>> >
>> > Not really.
>> > It's not because it was silently ignored that the calls were actually
>> valid.
>> >
>> > In fact doing something on NULL (except del) should trigger an error or
>> > warning message.
>> > Hiding error messages is really just that: it's hiding an invalid code
>> path.
>>
>> This does not make sense.
>>
>> Honestly, why should:
>>
>> ecore_event_handler_del(NULL)
>>
>> be fine but:
>>
>> evas_object_event_callback_del_full(NULL)
>>
>> give a error ?
>>
>> Even more, all the functions from eo, just dont do anything, why
>> should this single function give a error? Sure its usefull to get
>> warned, HEY you are doing this on a null obj, but if we do so it should
>> be consistent over all the api, and not just those few evas api´s.
>> But i guess this will not fit into anyones time scheudle. :)
>>
>
> If you call an EO function on a NULL object you get an error message (a
> cryptic one btw, should be improved).
>

^^ I was wrong, didn't compile properly :) (now the coffee has finally
kicked in)
And yes, adding ERR on NULL calls triggers a ton of ERR messages.

My bad. I get your point then.



> So the above scenario where you call a function that silently does nothing
> on NULL is not going to happen much as we move to EO.
>
> One way or another remember that those are only debug logs. Not a
> functional change.
> More debug is usually better, maybe ERR is too high a level. But ignoring
> errors silently is a sure way to add bugs in the future :)
>

As you said on IRC, this could be a feature of eo_dbg.

Best regards,
jp


>
>
> > Let's instead fix the root causes for those calls on NULL.
>> > Yes, that more work, and it also shows more error logs in existing
>> careless
>> > apps. In the long run, this helps.
>> >
>> > Best regards,
>> >
>> >
>> > On Sun, Oct 23, 2016 at 08:56:10AM +0200, Davide Andreoli wrote:
>> > > > hey, I don't like this change. passing a NULL obj to those functions
>> > > can't
>> > > > be correct and an error message is imo the right think to do.
>> > > > In fact yesterday I spotted 2 hidden bugs in python-efl thanks to
>> the
>> > > > message you removed.
>> > > > Do you have a correct use case for this? or you are just lazy and
>> don't
>> > > > want to see errors on console?  :P
>> > > >
>> > > > 2016-10-22 20:32 GMT+02:00 Marcel Hollerbach <
>> > > marcel-hollerb...@t-online.de>
>> > > > :
>> > > >
>> > > > > bu5hm4n pushed a commit to branch master.
>> > > > >
>> > > > > http://git.enlightenment.org/core/efl.git/commit/?id=
>> > > > > 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
>> > > > >
>> > > > > commit 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
>> > > > > Author: Marcel Hollerbach 
>> > > > > Date:   Sat Oct 22 19:26:47 2016 +0200
>> > > > >
>> > > > > evas_callbacks: restore error message behaviour from
>> MAGIC_CHECK
>> > > > >
>> > > > > before changing MAGIC_CHECK to eo_isa passing NULL to a
>> function
>> > > would
>> > > > > result in nothing, now it gives a error message. This
>> restores the
>> > > old
>> > > > > behaviour.
>> > > > > ---
>> > > > >  src/lib/evas/canvas/evas_callbacks.c | 9 +
>> > > > >  1 file changed, 9 insertions(+)
>> > > > >
>> > > > > diff --git a/src/lib/evas/canvas/evas_callbacks.c
>> > > > > b/src/lib/evas/canvas/evas_callbacks.c
>> > > > > index 7842e7c..18117bf 100644
>> > > > > --- a/src/lib/evas/canvas/evas_callbacks.c
>> > > > > +++ b/src/lib/evas/canvas/evas_callbacks.c
>> > > > > @@ -386,6 +386,7 @@ evas_object_event_callback_add(Evas_Object
>> > > *eo_obj,
>> > > > > Evas_Callback_Type type, Eva
>> > > > >  EAPI void
>> > > > >  evas_object_event_callback_priority_add(Evas_Object *eo_obj,
>> > > > > Evas_Callback_Type type, Evas_Callback_Priority priority,
>> > > > > Evas_Object_Event_Cb func, const void *data)
>> > > 

Re: [E-devel] [EGIT] [core/efl] master 01/02: evas_callbacks: restore error message behaviour from MAGIC_CHECK

[Jean-Philippe André]

On 24 October 2016 at 16:11,  wrote:

> On Mon, Oct 24, 2016 at 12:21:19PM +0900, Jean-Philippe André wrote:
> > Hey Marcel,
> >
> > On 23 October 2016 at 16:45,  wrote:
> >
> > > I am not wondering thats its YOU dont who dont like my change... :)
> > >
> > > Well there are two reasons to NOT have a Error message.
> > >
> > > First, it was before like that, so before it was completly valid, no
> > > error, now you will have a shitload of error messages in your console.
> > > Which was the case since evas_object_event_callback_del_full was
> called
> > > on cursor objects, undependent from if they are NULL or not. So if you
> > > dont want to have this NULL check, feel free the go to all api calls in
> > > EFL and check if they are valid.
> > >
> > > Also, complete eo works like that, if you call things on a NULL object,
> > > nothing will happen ... So i guess the same for evas_object_* functions
> > > should be the case.
> > >
> > > So no, its a correct usecase.
> > >
> >
> > Not really.
> > It's not because it was silently ignored that the calls were actually
> valid.
> >
> > In fact doing something on NULL (except del) should trigger an error or
> > warning message.
> > Hiding error messages is really just that: it's hiding an invalid code
> path.
>
> This does not make sense.
>
> Honestly, why should:
>
> ecore_event_handler_del(NULL)
>
> be fine but:
>
> evas_object_event_callback_del_full(NULL)
>
> give a error ?
>
> Even more, all the functions from eo, just dont do anything, why
> should this single function give a error? Sure its usefull to get
> warned, HEY you are doing this on a null obj, but if we do so it should
> be consistent over all the api, and not just those few evas api´s.
> But i guess this will not fit into anyones time scheudle. :)
>

If you call an EO function on a NULL object you get an error message (a
cryptic one btw, should be improved).
So the above scenario where you call a function that silently does nothing
on NULL is not going to happen much as we move to EO.

One way or another remember that those are only debug logs. Not a
functional change.
More debug is usually better, maybe ERR is too high a level. But ignoring
errors silently is a sure way to add bugs in the future :)


> Let's instead fix the root causes for those calls on NULL.
> > Yes, that more work, and it also shows more error logs in existing
> careless
> > apps. In the long run, this helps.
> >
> > Best regards,
> >
> >
> > On Sun, Oct 23, 2016 at 08:56:10AM +0200, Davide Andreoli wrote:
> > > > hey, I don't like this change. passing a NULL obj to those functions
> > > can't
> > > > be correct and an error message is imo the right think to do.
> > > > In fact yesterday I spotted 2 hidden bugs in python-efl thanks to the
> > > > message you removed.
> > > > Do you have a correct use case for this? or you are just lazy and
> don't
> > > > want to see errors on console?  :P
> > > >
> > > > 2016-10-22 20:32 GMT+02:00 Marcel Hollerbach <
> > > marcel-hollerb...@t-online.de>
> > > > :
> > > >
> > > > > bu5hm4n pushed a commit to branch master.
> > > > >
> > > > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > > > > 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> > > > >
> > > > > commit 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> > > > > Author: Marcel Hollerbach 
> > > > > Date:   Sat Oct 22 19:26:47 2016 +0200
> > > > >
> > > > > evas_callbacks: restore error message behaviour from
> MAGIC_CHECK
> > > > >
> > > > > before changing MAGIC_CHECK to eo_isa passing NULL to a
> function
> > > would
> > > > > result in nothing, now it gives a error message. This restores
> the
> > > old
> > > > > behaviour.
> > > > > ---
> > > > >  src/lib/evas/canvas/evas_callbacks.c | 9 +
> > > > >  1 file changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/src/lib/evas/canvas/evas_callbacks.c
> > > > > b/src/lib/evas/canvas/evas_callbacks.c
> > > > > index 7842e7c..18117bf 100644
> > > > > --- a/src/lib/evas/canvas/evas_callbacks.c
> > > > > +++ b/src/lib/evas/canvas/evas_callbacks.c
> > > > > @@ -386,6 +386,7 @@ evas_object_event_callback_add(Evas_Object
> > > *eo_obj,
> > > > > Evas_Callback_Type type, Eva
> > > > >  EAPI void
> > > > >  evas_object_event_callback_priority_add(Evas_Object *eo_obj,
> > > > > Evas_Callback_Type type, Evas_Callback_Priority priority,
> > > > > Evas_Object_Event_Cb func, const void *data)
> > > > >  {
> > > > > +   if(!eo_obj) return;
> > > > > EINA_SAFETY_ON_FALSE_RETURN(efl_isa(eo_obj,
> > > EFL_CANVAS_OBJECT_CLASS));
> > > > > Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj,
> > > > > EFL_CANVAS_OBJECT_CLASS);
> > > > >
> > > > > @@ -408,6 +409,7 @@ evas_object_event_callback_
> > > priority_add(Evas_Object
> > > > > *eo_obj, Evas_Callback_Type
> > > > >  EAPI void *
> > > > >  evas_object_event_callback_del(Evas_Object *eo_obj,
> > > Evas_Callback_Type

[EGIT] [website/www-content] master 01/01: Wiki page debian-start changed with summary [] by Pierre Couderc

[Pierre Couderc]

WWW-www.enlightenment.org pushed a commit to branch master.

http://git.enlightenment.org/website/www-content.git/commit/?id=e78f45d792738ca6b2f2baf45322452a8e310c2d

commit e78f45d792738ca6b2f2baf45322452a8e310c2d
Author: Pierre Couderc 
Date:   Mon Oct 24 00:14:11 2016 -0700

Wiki page debian-start changed with summary [] by Pierre Couderc
---
 pages/distros/debian-start.txt | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/pages/distros/debian-start.txt b/pages/distros/debian-start.txt
index 8996868..faee6f4 100644
--- a/pages/distros/debian-start.txt
+++ b/pages/distros/debian-start.txt
@@ -106,8 +106,22 @@ Set the script executable:
 chmod ug+x build_enlight.sh
 
 
-Then, execute the script. Once done, you can reboot and choose Enlightenment 
as a window manager.
+Then, execute the script to compile and install enlightenment. 
+== Run ==
+A minimum run-time environment requires :
+
+aptitude install dbus-x11 xinit xorg
+
+and creating ./xinitrc :
+
+exec enlightenment_start
+
+then running startx.
+
+These run-time requirements may be provided - or not - by a session manger. In 
this case, you can reboot and choose Enlightenment as a window manager.
+
 
+== Lubuntu ==
 If you're running Lubuntu, you may need to add another repo (as root):
 
 

-- 

Re: [E-devel] [EGIT] [core/efl] master 01/02: evas_callbacks: restore error message behaviour from MAGIC_CHECK

[marcel-hollerbach]

On Mon, Oct 24, 2016 at 12:21:19PM +0900, Jean-Philippe André wrote:
> Hey Marcel,
> 
> On 23 October 2016 at 16:45,  wrote:
> 
> > I am not wondering thats its YOU dont who dont like my change... :)
> >
> > Well there are two reasons to NOT have a Error message.
> >
> > First, it was before like that, so before it was completly valid, no
> > error, now you will have a shitload of error messages in your console.
> > Which was the case since evas_object_event_callback_del_full was called
> > on cursor objects, undependent from if they are NULL or not. So if you
> > dont want to have this NULL check, feel free the go to all api calls in
> > EFL and check if they are valid.
> >
> > Also, complete eo works like that, if you call things on a NULL object,
> > nothing will happen ... So i guess the same for evas_object_* functions
> > should be the case.
> >
> > So no, its a correct usecase.
> >
> 
> Not really.
> It's not because it was silently ignored that the calls were actually valid.
> 
> In fact doing something on NULL (except del) should trigger an error or
> warning message.
> Hiding error messages is really just that: it's hiding an invalid code path.

This does not make sense.

Honestly, why should:

ecore_event_handler_del(NULL)

be fine but:

evas_object_event_callback_del_full(NULL)

give a error ?

Even more, all the functions from eo, just dont do anything, why
should this single function give a error? Sure its usefull to get
warned, HEY you are doing this on a null obj, but if we do so it should
be consistent over all the api, and not just those few evas api´s.
But i guess this will not fit into anyones time scheudle. :)

> Let's instead fix the root causes for those calls on NULL.
> Yes, that more work, and it also shows more error logs in existing careless
> apps. In the long run, this helps.
> 
> Best regards,
> 
> 
> On Sun, Oct 23, 2016 at 08:56:10AM +0200, Davide Andreoli wrote:
> > > hey, I don't like this change. passing a NULL obj to those functions
> > can't
> > > be correct and an error message is imo the right think to do.
> > > In fact yesterday I spotted 2 hidden bugs in python-efl thanks to the
> > > message you removed.
> > > Do you have a correct use case for this? or you are just lazy and don't
> > > want to see errors on console?  :P
> > >
> > > 2016-10-22 20:32 GMT+02:00 Marcel Hollerbach <
> > marcel-hollerb...@t-online.de>
> > > :
> > >
> > > > bu5hm4n pushed a commit to branch master.
> > > >
> > > > http://git.enlightenment.org/core/efl.git/commit/?id=
> > > > 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> > > >
> > > > commit 0180da708dda0d95fc34ec68c7d65d2df9ab4f95
> > > > Author: Marcel Hollerbach 
> > > > Date:   Sat Oct 22 19:26:47 2016 +0200
> > > >
> > > > evas_callbacks: restore error message behaviour from MAGIC_CHECK
> > > >
> > > > before changing MAGIC_CHECK to eo_isa passing NULL to a function
> > would
> > > > result in nothing, now it gives a error message. This restores the
> > old
> > > > behaviour.
> > > > ---
> > > >  src/lib/evas/canvas/evas_callbacks.c | 9 +
> > > >  1 file changed, 9 insertions(+)
> > > >
> > > > diff --git a/src/lib/evas/canvas/evas_callbacks.c
> > > > b/src/lib/evas/canvas/evas_callbacks.c
> > > > index 7842e7c..18117bf 100644
> > > > --- a/src/lib/evas/canvas/evas_callbacks.c
> > > > +++ b/src/lib/evas/canvas/evas_callbacks.c
> > > > @@ -386,6 +386,7 @@ evas_object_event_callback_add(Evas_Object
> > *eo_obj,
> > > > Evas_Callback_Type type, Eva
> > > >  EAPI void
> > > >  evas_object_event_callback_priority_add(Evas_Object *eo_obj,
> > > > Evas_Callback_Type type, Evas_Callback_Priority priority,
> > > > Evas_Object_Event_Cb func, const void *data)
> > > >  {
> > > > +   if(!eo_obj) return;
> > > > EINA_SAFETY_ON_FALSE_RETURN(efl_isa(eo_obj,
> > EFL_CANVAS_OBJECT_CLASS));
> > > > Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj,
> > > > EFL_CANVAS_OBJECT_CLASS);
> > > >
> > > > @@ -408,6 +409,7 @@ evas_object_event_callback_
> > priority_add(Evas_Object
> > > > *eo_obj, Evas_Callback_Type
> > > >  EAPI void *
> > > >  evas_object_event_callback_del(Evas_Object *eo_obj,
> > Evas_Callback_Type
> > > > type, Evas_Object_Event_Cb func)
> > > >  {
> > > > +   if(!eo_obj) return NULL;
> > > > EINA_SAFETY_ON_FALSE_RETURN_VAL(efl_isa(eo_obj,
> > > > EFL_CANVAS_OBJECT_CLASS), NULL);
> > > > Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj,
> > > > EFL_CANVAS_OBJECT_CLASS);
> > > > _eo_evas_object_cb_info *info;
> > > > @@ -436,6 +438,7 @@ evas_object_event_callback_del(Evas_Object
> > *eo_obj,
> > > > Evas_Callback_Type type, Eva
> > > >  EAPI void *
> > > >  evas_object_event_callback_del_full(Evas_Object *eo_obj,
> > > > Evas_Callback_Type type, Evas_Object_Event_Cb func, const void *data)
> > > >  {
> > > > +   if(!eo_obj) return NULL;
> > > > EINA_SAFETY_ON_FALSE_RETURN_VAL(efl_isa(eo_obj,
> > > >