Re: [E-devel] Work items for 1.16

[Stefan Schmidt]

Hello.

Another update here. Looking at this with 1.16 in mind for tomorrow I 
wonder if we can really release tomorrow. We will see.
I removed the ones marked as high as we need to focus on the show stoppers.

This comes up from my personal run through phab. Might be misguided,
wrong or I might even had forgotten something.
Speak up if this is the case.

Please have a look at the following and see if you can help to fix them.

Phab show stopper:
--
https://phab.enlightenment.org/T2715 evas object delete crash
https://phab.enlightenment.org/T2815Multi touch does not work
https://phab.enlightenment.org/T2807gl-drm engine not functional
https://phab.enlightenment.org/T2791render hang in read()

regards
Stefan Schmidt


--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] elm_cell: new container widget suggestion

[Conrad Um]

I suggest a new container widget, elm_cell, which makes resizing and adding
padding outside convenient. This widget allows developers to make a complex
layout without edc, but doesn't try to replace it. It provides a middle
level difficulty and flexibility between EFL novices and experts.
https://phab.enlightenment.org/D3262

Assume that you are an app developer who receives the layout specification
like the next.
http://imgur.com/E1HfxJF

It has outside padding between window and its main contents, and subobjects
have different padding size between them.
Of course, you can make this with edc & elm_layout clearly. However, if you
try to implement this with basic containers like box, grid or table, you
will have a great difficulty. Moreover, the implemented one can have
problems because of complex structures.

Following problems will occur when existing containers are used.
1. Grid: If child object is resized after packed, grid does not reflect
change.
2. Box, Table: Different padding size between children is not supported.

Learning EDC becomes a high barrier to newcomers to EFL. I agree that
expert EFL developer should learn edc. However, the developers who make EFL
application first should have an easier way than now not to make them give
up.
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Work items for 1.16

[Michael Blumenkrantz]

On Mon, 2 Nov 2015 14:04:35 +0100
Stefan Schmidt  wrote:

> Hello.
> 
> Another update here. Looking at this with 1.16 in mind for tomorrow I 
> wonder if we can really release tomorrow. We will see.
> I removed the ones marked as high as we need to focus on the show stoppers.
> 
> This comes up from my personal run through phab. Might be misguided,
> wrong or I might even had forgotten something.
> Speak up if this is the case.
> 
> Please have a look at the following and see if you can help to fix them.
> 
> Phab show stopper:
> --
> https://phab.enlightenment.org/T2715 evas object delete crash
> https://phab.enlightenment.org/T2815Multi touch does not work
> https://phab.enlightenment.org/T2807gl-drm engine not functional

This one was resolved today so I have created 
https://phab.enlightenment.org/T2818
to maintain the count of this list.

> https://phab.enlightenment.org/T2791render hang in read()
> 
> regards
> Stefan Schmidt
> 
> 
> --
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

--
___
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 ecore_con test failure in the nightlies blocks many other tests 
right now

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: 8.77% (8.49%) failed.
https://build.enlightenment.org/

Unique Jenkins build failures:
o Open:
EFL unit test failures in ecore_con

https://build.enlightenment.org/view/Nightly/job/nightly_efl_gcc_x86_64/1022/

o Resolved:
Build timeout in changely_elm_clang_x86_64

o Random:

Clang scan-build:
o EFL scan-build reports N/A (N/A) issues.
https://build.enlightenment.org/job/nightly_efl_clang_x86_64/lastSuccessfu
lBuild/artifact/scan-build/build/
o Elementary scan-build reports 85 (85) issues.
https://build.enlightenment.org/job/nightly_elm_clang_x86_64/lastSuccessfulBuild/artifact/scan-build/build

Unit tests:
o 564 (560) unit tests for efl and none failing

Coverage:
o EFL total coverage is at 34.4% (34.4%) lines and 38.1% (38.1%) functions
https://build.enlightenment.org/view/Test%20Coverage/

Coverity:
o EFL: Outstanding defects 68 (69) with a density of 0.09 (0.09)
o Elm: Outstanding defects 7 (7) with a density of 0.01 (0.01)
o Evas Generic Loaders: Outstanding defects 0 (0) with a density of 0
(0)
o Emotion Generic Players: Outstanding defects 0 (0) with a density of
0 (0)
o Enlightenment: Outstanding defects 39 (39) with a density of 0.14 (0.14)
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: 646 (644)
https://phab.enlightenment.org/maniphest/report/burn/
o Pending patch reviews: 121 (109)

regards
Stefan Schmidt

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] 1.16 postponed by a day

[Stefan Schmidt]

Hello.

After travel and a weekend off I just started to catch up on what 
happened wrt 1.16 status.

With all these last minute changes, failing jenkins tests, etc I will 
not release it today.

I hope that until tomorrow things will have cleared up but nothing 
promised just yet.

regards
Stefan Schmidt

--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eo "design review"

[Jean-Philippe André]

Hi,

Le lun. 2 nov. 2015 à 09:24, Felipe Magno de Almeida <
felipe.m.alme...@gmail.com> a écrit :

> OK,
>
> So, I tried to take a stab at it during the weekend.
>
> I think all the optimizations are actually hurting performance. I
> wanted to test removing eo_do and the whole machinery for stacks etc.
> And just use the _eo_obj_pointer_get. However, for some reason, mixins
> and composites stopped working and I don't have much time to
> investigate.
>
> I think this test should be done. Afterall, if we write a lock-free
> table_ids data structure, then we would be _much_ better off than
> using TLS and allocations all over the place.
> And eo_do seems cool at first, but reviewing the code in EFL while
> doing this modification we can see that eo_do creates a lot of pain
> and workarounds, to name two: eo_do_ret and eo_do_part. And a lot of
> others.
>
> I've #define'ed eo_do to just call the functions within. All the
> functions receive the Eo* object which calls on. And to replace
> eo_do_super I've added to eolian the generation for
> eo_super_function_name which takes as first parameter the Eo_Class
> that would be passed to eo_do_super.
>
> I think that eo_do is very likely hurting performance. So we should at
> least prove that it does give better performance before we start using
> macros all over the place, which will be necessary to avoid some TLS.
>
> I pushed the modifications to devs/fellipealmeida/eo_optimizations
> if anyone wants to try it out. And, tt is a mess, of course.
>
> BTW, I'd rather we would keep the optimizations more focused so
> we can achieve more. For example, if we depend solely on the
> ids_table and function/data lookup (_dich_func_get),
> instead of caching results in stacks with allocations and stuff.
> Then we can tailor it to make it much more optimized with
> lock-free algorithms and better data structures.
>

This sounds promising. After using EO a bit I have to say I don't really
like the eo_do(obj, call()) syntax. On the other hand the obj = eo_add() is
nicer than Felipe's changes :)

I tested your code a bit, with eo_suite test to see what works. It seems
you didn't modify class functions to be class functions instead of object
functions, which makes the suite fail. This leads me to this question:

Is there (or was there) any reason for class functions to have the same
syntax as an object function even though they don't apply to the same kind
of "thing"? (Eo_Class vs Eo object)

Why are classes Eo objects? (beyond sharing code). I think we can further
optimize out some checks if we make a clear difference.

Best regards,
jp
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel