Re: [E-devel] [EGIT] [core/efl] master 02/02: eina_matrix: Add since tags to all new functions in 1.14

[Cedric BAIL]

On Thu, Apr 9, 2015 at 3:02 PM, ChunEon Park  wrote:
> The reason using the matrix is efficient in computing multiple factors - 
> position, rotation, scale ..-  at one time.
>
> eina matrix shouldn't be designed for only svg but for more common cases.
> evas 3d will also need the eina matrix and app may uses them for their matrix 
> also.

Just to be sure we are talking about the same thing. Eina_Matrix3 is
only suitable for 2D. You need a fourth component for it to be used
for 3D.

> we should design it for more common case.
> so the default usage should be this,

I don't mind the change. If nobody raise their voice against such a
change I will do it early next week.

> matrix m;
> matrix_identify(m);
> matrix_translate(m);
> matrix_rotate(m);
> matrix_scale(m);
>
> 
> -Regards, Hermet-
>
> -Original Message-
> From: "Cedric BAIL"
> To: "Enlightenment developer list";
> Cc:
> Sent: 2015-04-09 (목) 17:03:04
> Subject: Re: [E-devel] [EGIT] [core/efl] master 02/02: eina_matrix: Add since 
> tags to all new functions in 1.14
>
> Hello,
>
> On Thu, Apr 9, 2015 at 7:44 AM, ChunEon Park  wrote:
>> Current matrix usage seems going wrong.
>> I found the current matrix usage is this.
>>
>> matrix m;
>> matrix_translate(m, ...);
>>
>> matrix m2;
>> matrix_rotation(m, ...);
>>
>> matrix m3;
>> matrix_scale(m, ...);
>>
>> matrix m4;
>> matrix_compose(m, m2, m4);
>>
>> matrix m5;
>> matrix_compose(m3, m4, m5);
>>
>> it's unnecessary and inefficient.
>> Rather than, default matrix usage should be designed to compose of the 
>> transforms.
>>
>> matrix m;
>> matrix_identify(m);
>> matrix_translate(m);
>> matrix_rotate(m);
>> matrix_scale(m);
>>
>> if you focused to single factor transform rather than composition
>> then single vector is enough to use rather than matrix.
>
> I am not to sure I understand what you mean correctly here. Your
> suggestion would be to actually apply the transformation on an
> existing matrix doing the set + compose in one step instead of two and
> simplifying the operation by knowing where the zero already are in the
> composition operation. The reason it is like this, is that in SVG you
> only read the matrix once, but you compose it almost every single
> frame. It made the core more compact and easier to read, but I can
> understand that in different usage scenario you would want to have a
> more optimized code path. I guess it can be done.
> --
> Cedric BAIL
>
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Cedric BAIL

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Tom Hacohen]

On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote:
> On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen  said:
>
>> On 08/04/15 11:26, thomasg wrote:
>>> On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen 
>>> wrote:
 On 08/04/15 10:20, Stefan Schmidt wrote:
> Hello.
>
> At the EFL Dev Day US during the talk from Lars he brought up the point
> that EFL is heavily outdated in many distros and platforms. While I
> instantly agree to this I wondered how bad it really is.
>
> I think as a developer as well as a user it makes sense for us to know
> what versions of EFL and friends are packaged in which distros and
> platforms. Thus I started to pull together a wiki page for it.
>
> https://phab.enlightenment.org/w/packaging_status/
>
> Its a tedious work and I only started today. Feel free to jump in and
> update the links and versions for your beloved distro. Please go with
> main package repositories first. You can add a line for a overlay/ppa if
> it is well maintained. When filling a new field please add the link as
> you can already see in existing entries. That way we have a page where
> we can easily look for the latest versions and update.
>
> My plan is to fill in more items over time (hoping for some
> crowdsourcing here) and run a quick update of versions numbers once a
> month (already set a calendar entry for it).

 I wrote "latest" for every package of Arch. It's too crazy to maintain
 it for Arch, and it's always up to date anyway.
>>>
>>> If it's too crazy to update a wiki page, no wonder the maintainers
>>> might find it crazy to do up-to-date packaging :P
>>
>> It's too crazy for us to maintain 2000 boxes of a table. :)
>> Yes btw, we release too often nowadays (the micro releases), and it's
>> becoming more and more annoying to stay up to date, and I think that's
>> why Arch has been so slow recently with micro releases for the efl.
>
> look at:
>
> https://www.enlightenment.org/doku.php?id=download-latest
>
> look at the top - it's a bunch of variables for version of that package. 
> that's
> it. url and label is generates from the vars. just update those vars at 
> release
> of anything (add more vars and table entries when new stuff is being released
> that wasn't before).
>
>

I'm talking about two things:
1. Maintaining the 2000 cells of the table. You have to check the 
distro's websites (or script it, and then it's fine) in order to update 
those. Your approach doesn't matter there.
2. Building new EFL packages. Building a newer version is easy, that's 
not the problem. The problem is testing. At our current rate, if 
maintainers follow our releases they need to build and *test* packages 
way too often, and testing takes time.

--
Tom.


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/04: Edje: Remove excessive casts and use type Edje_Object

[Felipe Magno de Almeida]

On Thu, Apr 9, 2015 at 3:50 PM, Tom Hacohen  wrote:
> On 08/04/15 07:37, Jean-Philippe André wrote:
>> @Eo guys,

[snip]

>> Evas_Image for evas_object_image functions,
>> Evas_Object for generic evas_object functions,
>> And Eo only as a last resort?
>>
>> I spotted those in the ABI report.
>
> The Evas_Image and etc. are new. We should use them when appropriate
> (think normal OOP, common ancestor). However I'd be wary about using
> them now as iirc they should be BETA_API. Maybe I'm wrong and they
> aren't yet.
>
> Either way, in the .eo files, you should definitely use the correct
> class, in the form of: Elm.Button or Edje.Object.

Yes. True. And _not_ Edje_Object, but Edje.Object. They are both going to
work for C, but for other languages that is quite different.

> --
> Tom.

Regards,
-- 
Felipe Magno de Almeida

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/04: Edje: Remove excessive casts and use type Edje_Object

[Tom Hacohen]

On 08/04/15 07:37, Jean-Philippe André wrote:
> @Eo guys,
>
> On Wed, Apr 8, 2015 at 3:25 PM, Conrad Meyer  wrote:
>
>> jpeg pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=0c21b91f0fe5dd61080aaba7902907837d842c26
>>
>> commit 0c21b91f0fe5dd61080aaba7902907837d842c26
>> Author: Conrad Meyer 
>> Date:   Wed Apr 8 14:34:46 2015 +0900
>>
>>  Edje: Remove excessive casts and use type Edje_Object
>>
>>  Use type Edje_Object instead of Eo in legacy EAPI's.
>
>
> I saw lots of inconsistent type usage when going through Evas legacy
> headers.
> Do we want to use stronger type names? I.e.:
>
> Evas_Image for evas_object_image functions,
> Evas_Object for generic evas_object functions,
> And Eo only as a last resort?
>
> I spotted those in the ABI report.

The Evas_Image and etc. are new. We should use them when appropriate 
(think normal OOP, common ancestor). However I'd be wary about using 
them now as iirc they should be BETA_API. Maybe I'm wrong and they 
aren't yet.

Either way, in the .eo files, you should definitely use the correct 
class, in the form of: Elm.Button or Edje.Object.

--
Tom.




--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Tom Hacohen]

On 09/04/15 10:22, Stefan Schmidt wrote:
> Hello.
>
> On 09/04/15 10:47, Tom Hacohen wrote:
>> On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen  
>>> said:
>>>
 On 08/04/15 11:26, thomasg wrote:
> On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen 
> wrote:
>> On 08/04/15 10:20, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> At the EFL Dev Day US during the talk from Lars he brought up the point
>>> that EFL is heavily outdated in many distros and platforms. While I
>>> instantly agree to this I wondered how bad it really is.
>>>
>>> I think as a developer as well as a user it makes sense for us to know
>>> what versions of EFL and friends are packaged in which distros and
>>> platforms. Thus I started to pull together a wiki page for it.
>>>
>>> https://phab.enlightenment.org/w/packaging_status/
>>>
>>> Its a tedious work and I only started today. Feel free to jump in and
>>> update the links and versions for your beloved distro. Please go with
>>> main package repositories first. You can add a line for a overlay/ppa if
>>> it is well maintained. When filling a new field please add the link as
>>> you can already see in existing entries. That way we have a page where
>>> we can easily look for the latest versions and update.
>>>
>>> My plan is to fill in more items over time (hoping for some
>>> crowdsourcing here) and run a quick update of versions numbers once a
>>> month (already set a calendar entry for it).
>> I wrote "latest" for every package of Arch. It's too crazy to maintain
>> it for Arch, and it's always up to date anyway.
> If it's too crazy to update a wiki page, no wonder the maintainers
> might find it crazy to do up-to-date packaging :P
 It's too crazy for us to maintain 2000 boxes of a table. :)
 Yes btw, we release too often nowadays (the micro releases), and it's
 becoming more and more annoying to stay up to date, and I think that's
 why Arch has been so slow recently with micro releases for the efl.
>>> look at:
>>>
>>> https://www.enlightenment.org/doku.php?id=download-latest
>>>
>>> look at the top - it's a bunch of variables for version of that package. 
>>> that's
>>> it. url and label is generates from the vars. just update those vars at 
>>> release
>>> of anything (add more vars and table entries when new stuff is being 
>>> released
>>> that wasn't before).
>>>
>>>
>> I'm talking about two things:
>> 1. Maintaining the 2000 cells of the table. You have to check the
>> distro's websites (or script it, and then it's fine) in order to update
>> those. Your approach doesn't matter there.
>
> Its easy to make it sounding scarry when using factor 10. Its actually
> 231 cells. Not all of them need to be updated.
>
> If someone wants to script this I would be happy. Given that I do not
> see this happening I will do it manually and see how this goes.
>
>> 2. Building new EFL packages. Building a newer version is easy, that's
>> not the problem. The problem is testing. At our current rate, if
>> maintainers follow our releases they need to build and *test* packages
>> way too often, and testing takes time.
>>
>
>>From what current rate do you talk here? We have two stable updates for
> 1.13 which out for two months. That sounds like we are still having one
> stable update per months on average.
>
> Which is more or less what we had all the time. Around 3-4 stable
> updates per major release. A month is not enough time to update a package?
>
> I try to not have to many of them (my initial goal has been 4-5 but I
> decreased this over time) but they are essentially bug fixes which we
> should offer our users.
> If you take 1.13.2 as example there was a evas use after free fix which
> was tracked for a long time and it was asked by the user to make a
> stable update with this.
>
> So in summary it means balancing the needs of updates and reducing the
> amount of updates we do. I think one stable update per month on average
> is good.


The original point has become moot ever since you said you only wanna 
update it once a month, it's OK (I guess) to spend 15minutes a month on 
that, and the value is obviously worth it.

Stable update a month is great. I did the math wrong, I was under the 
impression it was once every two weeks (and I think I mentioned that).

Bottom line: sorry for the noise.

--
Tom.



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
e

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Stefan Schmidt]

Hello.

On 09/04/15 12:29, Leif Middelschulte wrote:
>> Am 09.04.2015 um 11:22 schrieb Stefan Schmidt :
>>
>> Hello.
>>
>> On 09/04/15 10:47, Tom Hacohen wrote:
>>> On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote:
 On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen  
 said:

> On 08/04/15 11:26, thomasg wrote:
>> On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen 
>> wrote:
>>> On 08/04/15 10:20, Stefan Schmidt wrote:
 Hello.

 At the EFL Dev Day US during the talk from Lars he brought up the point
 that EFL is heavily outdated in many distros and platforms. While I
 instantly agree to this I wondered how bad it really is.

 I think as a developer as well as a user it makes sense for us to know
 what versions of EFL and friends are packaged in which distros and
 platforms. Thus I started to pull together a wiki page for it.

 https://phab.enlightenment.org/w/packaging_status/

 Its a tedious work and I only started today. Feel free to jump in and
 update the links and versions for your beloved distro. Please go with
 main package repositories first. You can add a line for a overlay/ppa 
 if
 it is well maintained. When filling a new field please add the link as
 you can already see in existing entries. That way we have a page where
 we can easily look for the latest versions and update.

 My plan is to fill in more items over time (hoping for some
 crowdsourcing here) and run a quick update of versions numbers once a
 month (already set a calendar entry for it).
>>> I wrote "latest" for every package of Arch. It's too crazy to maintain
>>> it for Arch, and it's always up to date anyway.
>> If it's too crazy to update a wiki page, no wonder the maintainers
>> might find it crazy to do up-to-date packaging :P
> It's too crazy for us to maintain 2000 boxes of a table. :)
> Yes btw, we release too often nowadays (the micro releases), and it's
> becoming more and more annoying to stay up to date, and I think that's
> why Arch has been so slow recently with micro releases for the efl.
 look at:

 https://www.enlightenment.org/doku.php?id=download-latest

 look at the top - it's a bunch of variables for version of that package. 
 that's
 it. url and label is generates from the vars. just update those vars at 
 release
 of anything (add more vars and table entries when new stuff is being 
 released
 that wasn't before).


>>> I'm talking about two things:
>>> 1. Maintaining the 2000 cells of the table. You have to check the
>>> distro's websites (or script it, and then it's fine) in order to update
>>> those. Your approach doesn't matter there.
>> Its easy to make it sounding scarry when using factor 10. Its actually
>> 231 cells. Not all of them need to be updated.
>>
>> If someone wants to script this I would be happy. Given that I do not
>> see this happening I will do it manually and see how this goes.
> https://phab.enlightenment.org/P116  php 
> script fetches the current arch linux package version of the efl.
> I also wrote a bash script (https://phab.enlightenment.org/P115 
> ) that creates a transparent .png since 
> that might be easier to include in the wiki.

Cool. Are you willing to extend this script to work for all listed
distros in the wiki? Arch alone does not bring me much but if we can
cover a lot more distros and generate the table for it that would help.
Even if I had to do some updates on my own.

regards
Stefan Schmidt

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Enlightenment-release] EFL, Elementary and friends 1.14 alpha tarballs

[Davide Andreoli]

So, this is a full bt with debug enabled for expedite, the crash is on app
startup

#0  0x4009ed7d in ?? ()
No symbol table info available.
#1  0x7fffedff6b90 in ?? () from
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.319.72
No symbol table info available.
#2  0x7fffedcdfee7 in ?? () from
/usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.319.72
No symbol table info available.
#3  0x7fffec80fce3 in shader_array_flush (gc=0x9d2590) at
modules/evas/engines/gl_common/evas_gl_context.c:3301
texuv_ptr = 0xc71d70 ""
texuv3_ptr = 0x0
vertex_ptr = 0xc68d60 ",\001\202"
color_ptr = 0x0
texuv2_ptr = 0x0
texa_ptr = 0x0
texsam_ptr = 0x0
mask_ptr = 0x0
MASK_TEXTURE = 33985
i = 1
gw = 720
gh = 420
pipe_done = 2
setclip = 0 '\000'
fbo = 0 '\000'
#4  0x7fffec80d308 in evas_gl_common_context_flush (gc=0x9d2590)
at modules/evas/engines/gl_common/evas_gl_context.c:2683
No locals.
#5  0x7fffef5327e7 in eng_outbuf_push_updated_region (ob=0x73d940,
update=0xb7a9c0, x=0, y=0, w=720, h=420)
at modules/evas/engines/gl_x11/evas_x_main.c:1430
No locals.
#6  0x77233d2d in eng_output_redraws_next_update_push
(data=0x73d830, surface=0xb7a9c0, x=0, y=0, w=720,
h=420, render_mode=EVAS_RENDER_MODE_SYNC) at
modules/evas/engines/software_generic/evas_engine.c:3425
re = 0x73d830
#7  0x77161def in evas_render_updates_internal
(eo_e=0x80040021, make_updates=1 '\001',
do_draw=1 '\001', done_func=0x0, done_data=0x0, do_async=0 '\000') at
lib/evas/canvas/evas_render.c:2486
off_x = 0
off_y = 0
ru = 0x7fff0001
offset = 1
fx = 0
fy = 0
eo_obj = 0x80048025
obj = 0xbc5580
e = 0x6a5840
ll = 0x0
surface = 0xb7a9c0
clean_them = 0 '\000'
alpha = 0 '\000'
r = 0x0
ux = 0
uy = 0
uw = 720
uh = 420
cx = 0
cy = 0
cw = 720
ch = 420
i = 5
j = 1
redraw_all = 0
haveup = 1 '\001'
render_mode = EVAS_RENDER_MODE_SYNC
clip_rect = {x = -134387280, y = 32767, w = -150436532, h = 32767}
__FUNCTION__ = "evas_render_updates_internal"
#8  0x77162e86 in evas_render_updates_internal_wait
(eo_e=0x80040021, make_updates=1 '\001',
do_draw=1 '\001') at lib/evas/canvas/evas_render.c:2801
ret = 0x0
e = 0x6a5840
#9  0x77162f00 in _evas_canvas_render_updates
(eo_e=0x80040021, e=0x6a5840)
at lib/evas/canvas/evas_render.c:2817
No locals.
#10 0x770d61c0 in evas_canvas_render_updates () at
../src/lib/evas/canvas/evas_canvas.eo.c:328
_r = 0x0
___call = {obj = 0x80040021, klass = 0x4007,
  func = 0x77162eb5 <_evas_canvas_render_updates>, data =
0x6a5840}
___is_main_loop = 1 '\001'
___op = 74
_func_ = 0x77162eb5 <_evas_canvas_render_updates>
#11 0x770d9c4a in evas_render_updates (obj=0x80040021) at
../src/lib/evas/canvas/evas_canvas.eo.c:
ret = 0x0
__FUNCTION__ = "evas_render_updates"
#12 0x71d8e7e1 in _ecore_evas_x_render (ee=0x736a70) at
modules/ecore_evas/engines/x/ecore_evas_x.c:763
updates = 0x0
rend = 0
ll = 0x0
ee2 = 0x0
edata = 0x737cf0
#13 0x76c24737 in _ecore_evas_idle_enter (data=0x0) at
lib/ecore_evas/ecore_evas.c:167
ee = 0x736a70
t1 = 0
t2 = 0
rend = 0
now = 1790.054790506
__FUNCTION__ = "_ecore_evas_idle_enter"
#14 0x769eddcf in _ecore_call_task_cb (func=0x76c24126
<_ecore_evas_idle_enter>, data=0x0)
at lib/ecore/ecore_private.h:305
r = 0 '\000'
#15 0x769ee36d in _ecore_idle_enterer_call () at
lib/ecore/ecore_idle_enterer.c:177
ie = 0x6c6120
__FUNCTION__ = "_ecore_idle_enterer_call"
#16 0x769f2a3a in _ecore_main_loop_iterate_internal (once_only=0)
at lib/ecore/ecore_main.c:1869
next_time = -1
#17 0x769f0e5d in ecore_main_loop_begin () at
lib/ecore/ecore_main.c:982
No locals.
#18 0x00403aaa in main (argc=, argv=0x7fffe698)
at main.c:1340
anim = 0x8013209a
ee = 0x736a70
resolution = 0x0
engine = 0x7fffe9d8 "opengl_x11"
resolution_index = 
test = -1
resolution_list = 0 '\000'
tests_list = 0 '\000'
async = 0 '\000'
all_tests = 0 '\000'
quit_option = 0 '\000'
values = {{strp = 0x7fffe4f8, boolp = 0x7fffe4f8
"\330\351\377\377\377\177", shortp = 0x7fffe4f8,
intp = 0x7fffe4f8, longp = 0x7fffe4f8, ushortp =
0x7fffe4f8, uintp = 0x7fffe4f8,
ulongp = 0x7fffe4f8, doublep = 0x7fffe4f8, listp =
0x7fffe4f8, ptrp = 0x7fffe4f8}, {
   

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Stefan Schmidt]

Hello.

On 08/04/15 11:20, Stefan Schmidt wrote:
> Hello.
>
> At the EFL Dev Day US during the talk from Lars he brought up the point
> that EFL is heavily outdated in many distros and platforms. While I
> instantly agree to this I wondered how bad it really is.
>
> I think as a developer as well as a user it makes sense for us to know
> what versions of EFL and friends are packaged in which distros and
> platforms. Thus I started to pull together a wiki page for it.
>
> https://phab.enlightenment.org/w/packaging_status/
>
> Its a tedious work and I only started today. Feel free to jump in and
> update the links and versions for your beloved distro. Please go with
> main package repositories first. You can add a line for a overlay/ppa if
> it is well maintained. When filling a new field please add the link as
> you can already see in existing entries. That way we have a page where
> we can easily look for the latest versions and update.
>
> My plan is to fill in more items over time (hoping for some
> crowdsourcing here) and run a quick update of versions numbers once a
> month (already set a calendar entry for it).

Thanks to everyone who helped and filled in some rows of the table!

We miss information for: elive, Linux Mint, Mageia, CentOS, RHEL,
Windows and Tizen.

If someone has knowledge about them/uses packages from them please add
it to the wiki. I will try to fill out the blank cells next week.

regards
Stefan Schmidt

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] Question about evas_object_box_smart APIs

[조재현]

Hello~ This is Jaehyun Cho.
 
In efl/src/lib/evas/canvas/evas_object_box.c, evas_object_box_smart_set() 
always returns nothing and evas_object_box_smart_class_get() always returns 
NULL.
So are those APIs actually not used by application developers? like deprecated 
APIs?
 
Thanks,
Jaehyun Cho. 
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [Enlightenment-release] EFL, Elementary and friends 1.14 alpha tarballs

[Davide Andreoli]

2015-04-09 3:23 GMT+02:00 Jean-Philippe André :

> Hi Davide,
>
> Since this is most likely my fault (as I introduced lots of changes in the
> GL/X11 engine), would you mind sharing more details about your
> architecture?
>
Sure, I'm on linux mint debian edition, that is quite a debian testing

>
> - driver version? (nvidia proprietary, right?)
>
Yes, closed driver, I think version 319.72
I can probably update to a newer version, will try in the evening


> - EGL or GLX? (glx is default if you don't pass any special ./configure
> options)
>
I do not give any compiler flags so I'm using GLX...Can you please explain
me the difference? what is better?

>
> If you have some time, would you be able to use git bisect and pinpoint the
> exact commit that makes all GL stuff fail? That would probably help. Also a
> full backtrace with all debugging symbols would help (ie.  CFLAGS="-O0
> -g").
>
I tryied an automatic git bisect yet but without success, too much changes
in that
period that made the repo quite unusable at random points.
I will provide a better bt in the evening

Thanks for the help


>
> Thanks in advance!
>
>
> On Thu, Apr 9, 2015 at 9:09 AM, Carsten Haitzler 
> wrote:
>
> > On Wed, 8 Apr 2015 23:18:26 +0200 Davide Andreoli <
> d...@gurumeditation.it>
> > said:
> >
> > and the bt's end up inside the driver .. crashing. both.
> >
> > i have efl git (1.14) here, nvidia closed drivers (346.35) and no crashes
> > here.
> >
> > > Testing 1.14 alpha1 here and I have lots of trouble with the opengl
> > engine:
> > > E20 segfault on start and the same for every elm app (always using the
> gl
> > > engine)
> > >
> > > Using nvidia closed driver, no issue with lots of other stuff that use
> > gl,
> > > and the
> > > same driver was working well with older efl...so please don't tell me
> > that
> > > is a driver issue :P
> > >
> > > I'm attaching both a terminology bt taken with gdb and the E
> > crashdump.txt,
> > > both seems to
> > > be related to the shader_array_flush function.
> > >
> > > Please let me know what else I can do to help
> > >
> > >
> > > This is a first bt of terminology:
> > >
> > > #0  0x4009edbd in ?? ()
> > > #1  0x7fffe7052b90 in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.319.72
> > > #2  0x7fffe6d3bee7 in ?? () from
> > > /usr/lib/x86_64-linux-gnu/libnvidia-glcore.so.319.72
> > > #3  0x7fffe586c0be in shader_array_flush (gc=0xa40b10) at
> > > modules/evas/engines/gl_common/evas_gl_context.c:3301
> > > #4  0x75b6a469 in eng_output_redraws_next_update_push
> > > (data=0x7af7a0, surface=0xbe4650, x=,
> > > y=, w=, h=,
> > > render_mode=EVAS_RENDER_MODE_SYNC)
> > > at modules/evas/engines/software_generic/evas_engine.c:3425
> > > #5  0x75acca16 in evas_render_updates_internal
> > > (eo_e=eo_e@entry=0x80064033,
> > >
> > > make_updates=make_updates@entry=1 '\001', do_draw=do_draw@entry=1
> > > '\001', done_func=done_func@entry=0x0,
> > > done_data=done_data@entry=0x0, do_async=do_async@entry=0 '\000')
> at
> > > lib/evas/canvas/evas_render.c:2486
> > > #6  0x75acd947 in evas_render_updates_internal_wait
> > > (eo_e=0x80064033, make_updates=,
> > > do_draw=) at lib/evas/canvas/evas_render.c:2801
> > > #7  0x75a5560a in evas_canvas_render_updates () at
> > > ../src/lib/evas/canvas/evas_canvas.eo.c:328
> > > #8  0x75a58f43 in evas_render_updates (obj=) at
> > > ../src/lib/evas/canvas/evas_canvas.eo.c:
> > > #9  0x7fffe8799c3c in _ecore_evas_x_render (ee=0x762fb0) at
> > > modules/ecore_evas/engines/x/ecore_evas_x.c:763
> > > #10 0x755ad301 in _ecore_evas_idle_enter (data=)
> > at
> > > lib/ecore_evas/ecore_evas.c:167
> > > #11 0x757d1d39 in _ecore_call_task_cb (data=,
> > > func=)
> > > at lib/ecore/ecore_private.h:305
> > > #12 _ecore_idle_enterer_call () at lib/ecore/ecore_idle_enterer.c:177
> > > #13 0x757d4c7b in _ecore_main_loop_iterate_internal
> > > (once_only=once_only@entry=0)
> > > at lib/ecore/ecore_main.c:1869
> > > #14 0x757d50e7 in ecore_main_loop_begin () at
> > > lib/ecore/ecore_main.c:982
> > > #15 0x77a3fee5 in elm_run () at elm_main.c:1097
> > > #16 0x00413964 in elm_main (argc=argc@entry=1,
> > > argv=argv@entry=0x7fffe6f8)
> > > at main.c:925
> > > #17 0x0040c67c in main (argc=1, argv=0x7fffe6f8) at
> > main.c:961
> > >
> > >
> > >
> > > And this the e-crashdump.txt
> > >
> > > Thread 3 (Thread 0x7f2af1e74700 (LWP 23169)):
> > > #0  0x7f2aff6b2974 in pthread_cond_wait@@GLIBC_2.3.2 () from
> > > /lib/x86_64-linux-gnu/libpthread.so.0
> > > No symbol table info available.
> > > #1  0x7f2aff18e62c in eina_condition_wait (cond=0x7f2aff468b00
> > > ) at
> > > ../src/lib/eina/eina_inline_lock_posix.x:415
> > > No locals.
> > > #2  evas_thread_worker_func (data=, thread= > out>)
> > > at lib/evas/common/evas_thread_render.c:75
> > > cmd = 
> > > len = 
> > >   

Re: [E-devel] Make unit tests for new EAPI's mandatory

[Stefan Schmidt]

Hello.

On 01/04/15 14:30, Stefan Schmidt wrote:
> Hello.
>
> I brought this up during the recent EFL Dev Day and we discussed it a bit.
>
> Now I want to bring it here for wider discussion and give everybody a
> chance to have its say.
>
> Background is that we struggle to have a good testing coverage with unit
> tests of our code base. We have initiatives to improve this (which is
> very much welcome!) but we also need to address one of the root causes here.
> If you look at our current test coverage status you will see that some
> parts are way better than others:
> https://build.enlightenment.org/view/Test%20Coverage/
>
> When we bring new EAPI's we should try as hard as possible to have good
> unit tests committed together with the new EAPI's.
>
> I want to make this mandatory for cases where unit tests are possible.
> Cases which have specific hardware requirements or need interaction
> might be harder and I'm willing to accept the fact that sometimes it is
> almost impossible. But in many many of our newly added EAPI's added
> units tests for them is doable. Libs like eina, eo, eolian and eet
> should be straight forward.
>
> What I propose is that we have it mandatory to add test cases for new
> EAPI's and add an explanation to the commit message if you do _not_
> submit the unit tests and give a technical reason for it.
>
> What do you folks think about it? The feedback I got during the dev day
> was people are happy with it as long as it covers valid exceptions.
The feedback I got was only positive and after over a week everybody
should have been able to say if he/she disagrees.

If you bring in new EAPI's it is mandatory from now on to add test cases
for them. If you tried and failed due to technical problems describe in
the commit message what hindered you to add test cases for them.

regards
Stefan Schmidt

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: eina_matrix: Add since tags to all new functions in 1.14

[ChunEon Park]

The reason using the matrix is efficient in computing multiple factors - 
position, rotation, scale ..-  at one time.

eina matrix shouldn't be designed for only svg but for more common cases.
evas 3d will also need the eina matrix and app may uses them for their matrix 
also.

we should design it for more common case.
so the default usage should be this,

matrix m;
matrix_identify(m);
matrix_translate(m);
matrix_rotate(m);
matrix_scale(m);


-Regards, Hermet-

-Original Message-
From: "Cedric BAIL" 
To: "Enlightenment developer list"; 
Cc: 
Sent: 2015-04-09 (목) 17:03:04
Subject: Re: [E-devel] [EGIT] [core/efl] master 02/02: eina_matrix: Add since 
tags to all new functions in 1.14
 
Hello,

On Thu, Apr 9, 2015 at 7:44 AM, ChunEon Park  wrote:
> Current matrix usage seems going wrong.
> I found the current matrix usage is this.
>
> matrix m;
> matrix_translate(m, ...);
>
> matrix m2;
> matrix_rotation(m, ...);
>
> matrix m3;
> matrix_scale(m, ...);
>
> matrix m4;
> matrix_compose(m, m2, m4);
>
> matrix m5;
> matrix_compose(m3, m4, m5);
>
> it's unnecessary and inefficient.
> Rather than, default matrix usage should be designed to compose of the 
> transforms.
>
> matrix m;
> matrix_identify(m);
> matrix_translate(m);
> matrix_rotate(m);
> matrix_scale(m);
>
> if you focused to single factor transform rather than composition
> then single vector is enough to use rather than matrix.

I am not to sure I understand what you mean correctly here. Your
suggestion would be to actually apply the transformation on an
existing matrix doing the set + compose in one step instead of two and
simplifying the operation by knowing where the zero already are in the
composition operation. The reason it is like this, is that in SVG you
only read the matrix once, but you compose it almost every single
frame. It made the core more compact and easier to read, but I can
understand that in different usage scenario you would want to have a
more optimized code path. I guess it can be done.
-- 
Cedric BAIL

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] exception for some ecore-drm APIs getting merged after freeze

[Tom Hacohen]

On 09/04/15 17:11, Stefan Schmidt wrote:
> Hello.
>
> Yesterday I got informed there there are some patches that should still
> go into 1.14 because the enhance ecore-drm and will be needed for e20
> wayland side.
>
> It turned out to be more than I hoped for so I bring it up here. I
> merged some of the fixes already and rebased the rest on master and
> pushed it here:
> https://git.enlightenment.org/core/efl.git/log/?h=devs/stefan/ecore-drm-features-rebased
>
> Plus side:
> + This branch also contains fixes, not all off them are features and new
> APIs
> + It was only one day after the freeze and we had other things coming in
> that late. Normally I don't shout at people until after beta
> + It is needed for having better wayland drm support in e20 (which might
> not be able to wait until efl 1.15)
> + It is isolated to ecore-drm and the evas drm engine only. So now users
> besides E wayland
>
> Negative side
> + This branch was way bigger than I hoped for and mixed features with
> fixes and formatting patches so it was hard to review
> + 12 new API's that late make me grumpy
> + This was not written in a day and could have been merged in in smaller
> pieces over time.
>
> In the end two point really make me thing we should just merge this in
> now. Needed for E20 wayland support which might happen before efl-1.15
> and the most important thing: isolated to ecore-drm and evas drm engine
> only.
> Even if this screws up hell we should not really see problems with it. I
> had a look at the API naming and they are in line with what we have and
> nothing stroke me problematic.
>
> Have your own view if you think this should not go in and speak up
> quickly as I want to merge this tomorrow if I hear no hard complains
> about it.
>

That's fine to make an exception. It's our first (or second?) try with a 
much longer last freeze period. Under normal circumstances the freeze 
period would have started next week anyway. I think it's OK to give it a 
pass this time. It's only 2 days late anyway.

My concern though, as always, is the quality of the API. The annoying 
100 lines of code dumps are very annoying and impossible to review 
(see the latest Efl.Gfx dump). Have you reviewed everything and happy 
with the results?

--
Tom.



--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Leif Middelschulte]

> Am 09.04.2015 um 11:22 schrieb Stefan Schmidt :
> 
> Hello.
> 
> On 09/04/15 10:47, Tom Hacohen wrote:
>> On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote:
>>> On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen  
>>> said:
>>> 
 On 08/04/15 11:26, thomasg wrote:
> On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen 
> wrote:
>> On 08/04/15 10:20, Stefan Schmidt wrote:
>>> Hello.
>>> 
>>> At the EFL Dev Day US during the talk from Lars he brought up the point
>>> that EFL is heavily outdated in many distros and platforms. While I
>>> instantly agree to this I wondered how bad it really is.
>>> 
>>> I think as a developer as well as a user it makes sense for us to know
>>> what versions of EFL and friends are packaged in which distros and
>>> platforms. Thus I started to pull together a wiki page for it.
>>> 
>>> https://phab.enlightenment.org/w/packaging_status/
>>> 
>>> Its a tedious work and I only started today. Feel free to jump in and
>>> update the links and versions for your beloved distro. Please go with
>>> main package repositories first. You can add a line for a overlay/ppa if
>>> it is well maintained. When filling a new field please add the link as
>>> you can already see in existing entries. That way we have a page where
>>> we can easily look for the latest versions and update.
>>> 
>>> My plan is to fill in more items over time (hoping for some
>>> crowdsourcing here) and run a quick update of versions numbers once a
>>> month (already set a calendar entry for it).
>> I wrote "latest" for every package of Arch. It's too crazy to maintain
>> it for Arch, and it's always up to date anyway.
> If it's too crazy to update a wiki page, no wonder the maintainers
> might find it crazy to do up-to-date packaging :P
 It's too crazy for us to maintain 2000 boxes of a table. :)
 Yes btw, we release too often nowadays (the micro releases), and it's
 becoming more and more annoying to stay up to date, and I think that's
 why Arch has been so slow recently with micro releases for the efl.
>>> look at:
>>> 
>>> https://www.enlightenment.org/doku.php?id=download-latest
>>> 
>>> look at the top - it's a bunch of variables for version of that package. 
>>> that's
>>> it. url and label is generates from the vars. just update those vars at 
>>> release
>>> of anything (add more vars and table entries when new stuff is being 
>>> released
>>> that wasn't before).
>>> 
>>> 
>> I'm talking about two things:
>> 1. Maintaining the 2000 cells of the table. You have to check the
>> distro's websites (or script it, and then it's fine) in order to update
>> those. Your approach doesn't matter there.
> 
> Its easy to make it sounding scarry when using factor 10. Its actually
> 231 cells. Not all of them need to be updated.
> 
> If someone wants to script this I would be happy. Given that I do not
> see this happening I will do it manually and see how this goes.
https://phab.enlightenment.org/P116  php 
script fetches the current arch linux package version of the efl.
I also wrote a bash script (https://phab.enlightenment.org/P115 
) that creates a transparent .png since 
that might be easier to include in the wiki.

cheers,
Leif
> 
>> 2. Building new EFL packages. Building a newer version is easy, that's
>> not the problem. The problem is testing. At our current rate, if
>> maintainers follow our releases they need to build and *test* packages
>> way too often, and testing takes time.
>> 
> 
>> From what current rate do you talk here? We have two stable updates for
> 1.13 which out for two months. That sounds like we are still having one
> stable update per months on average.
> 
> Which is more or less what we had all the time. Around 3-4 stable
> updates per major release. A month is not enough time to update a package?
> 
> I try to not have to many of them (my initial goal has been 4-5 but I
> decreased this over time) but they are essentially bug fixes which we
> should offer our users.
> If you take 1.13.2 as example there was a evas use after free fix which
> was tracked for a long time and it was asked by the user to make a
> stable update with this.
> 
> So in summary it means balancing the needs of updates and reducing the
> amount of updates we do. I think one stable update per month on average
> is good.
> 
> regards
> Stefan Schmidt
> 
> 
> --
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
> ___

Re: [E-devel] HELP WANTED: Distro/platform packaging status of efl and E

[Stefan Schmidt]

Hello.

On 09/04/15 10:47, Tom Hacohen wrote:
> On 09/04/15 01:14, Carsten Haitzler (The Rasterman) wrote:
>> On Wed, 08 Apr 2015 12:31:13 +0100 Tom Hacohen  
>> said:
>>
>>> On 08/04/15 11:26, thomasg wrote:
 On Wed, Apr 8, 2015 at 11:27 AM, Tom Hacohen 
 wrote:
> On 08/04/15 10:20, Stefan Schmidt wrote:
>> Hello.
>>
>> At the EFL Dev Day US during the talk from Lars he brought up the point
>> that EFL is heavily outdated in many distros and platforms. While I
>> instantly agree to this I wondered how bad it really is.
>>
>> I think as a developer as well as a user it makes sense for us to know
>> what versions of EFL and friends are packaged in which distros and
>> platforms. Thus I started to pull together a wiki page for it.
>>
>> https://phab.enlightenment.org/w/packaging_status/
>>
>> Its a tedious work and I only started today. Feel free to jump in and
>> update the links and versions for your beloved distro. Please go with
>> main package repositories first. You can add a line for a overlay/ppa if
>> it is well maintained. When filling a new field please add the link as
>> you can already see in existing entries. That way we have a page where
>> we can easily look for the latest versions and update.
>>
>> My plan is to fill in more items over time (hoping for some
>> crowdsourcing here) and run a quick update of versions numbers once a
>> month (already set a calendar entry for it).
> I wrote "latest" for every package of Arch. It's too crazy to maintain
> it for Arch, and it's always up to date anyway.
 If it's too crazy to update a wiki page, no wonder the maintainers
 might find it crazy to do up-to-date packaging :P
>>> It's too crazy for us to maintain 2000 boxes of a table. :)
>>> Yes btw, we release too often nowadays (the micro releases), and it's
>>> becoming more and more annoying to stay up to date, and I think that's
>>> why Arch has been so slow recently with micro releases for the efl.
>> look at:
>>
>> https://www.enlightenment.org/doku.php?id=download-latest
>>
>> look at the top - it's a bunch of variables for version of that package. 
>> that's
>> it. url and label is generates from the vars. just update those vars at 
>> release
>> of anything (add more vars and table entries when new stuff is being released
>> that wasn't before).
>>
>>
> I'm talking about two things:
> 1. Maintaining the 2000 cells of the table. You have to check the 
> distro's websites (or script it, and then it's fine) in order to update 
> those. Your approach doesn't matter there.

Its easy to make it sounding scarry when using factor 10. Its actually
231 cells. Not all of them need to be updated.

If someone wants to script this I would be happy. Given that I do not
see this happening I will do it manually and see how this goes.

> 2. Building new EFL packages. Building a newer version is easy, that's 
> not the problem. The problem is testing. At our current rate, if 
> maintainers follow our releases they need to build and *test* packages 
> way too often, and testing takes time.
>

>From what current rate do you talk here? We have two stable updates for
1.13 which out for two months. That sounds like we are still having one
stable update per months on average.

Which is more or less what we had all the time. Around 3-4 stable
updates per major release. A month is not enough time to update a package?

I try to not have to many of them (my initial goal has been 4-5 but I
decreased this over time) but they are essentially bug fixes which we
should offer our users.
If you take 1.13.2 as example there was a evas use after free fix which
was tracked for a long time and it was asked by the user to make a
stable update with this.

So in summary it means balancing the needs of updates and reducing the
amount of updates we do. I think one stable update per month on average
is good.

regards
Stefan Schmidt


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] exception for some ecore-drm APIs getting merged after freeze

[Stefan Schmidt]

Hello.

Yesterday I got informed there there are some patches that should still
go into 1.14 because the enhance ecore-drm and will be needed for e20
wayland side.

It turned out to be more than I hoped for so I bring it up here. I
merged some of the fixes already and rebased the rest on master and
pushed it here:
https://git.enlightenment.org/core/efl.git/log/?h=devs/stefan/ecore-drm-features-rebased

Plus side:
+ This branch also contains fixes, not all off them are features and new
APIs
+ It was only one day after the freeze and we had other things coming in
that late. Normally I don't shout at people until after beta
+ It is needed for having better wayland drm support in e20 (which might
not be able to wait until efl 1.15)
+ It is isolated to ecore-drm and the evas drm engine only. So now users
besides E wayland

Negative side
+ This branch was way bigger than I hoped for and mixed features with
fixes and formatting patches so it was hard to review
+ 12 new API's that late make me grumpy
+ This was not written in a day and could have been merged in in smaller
pieces over time.

In the end two point really make me thing we should just merge this in
now. Needed for E20 wayland support which might happen before efl-1.15
and the most important thing: isolated to ecore-drm and evas drm engine
only.
Even if this screws up hell we should not really see problems with it. I
had a look at the API naming and they are in line with what we have and
nothing stroke me problematic.

Have your own view if you think this should not go in and speak up
quickly as I want to merge this tomorrow if I hear no hard complains
about it.

regards
Stefan Schmidt


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 03/04: Edje: Remove excessive casts and use type Edje_Object

[Felipe Magno de Almeida]

On Wed, Apr 8, 2015 at 3:37 AM, Jean-Philippe André  wrote:
> @Eo guys,
>
> On Wed, Apr 8, 2015 at 3:25 PM, Conrad Meyer  wrote:
>
>> jpeg pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/core/efl.git/commit/?id=0c21b91f0fe5dd61080aaba7902907837d842c26
>>
>> commit 0c21b91f0fe5dd61080aaba7902907837d842c26
>> Author: Conrad Meyer 
>> Date:   Wed Apr 8 14:34:46 2015 +0900
>>
>> Edje: Remove excessive casts and use type Edje_Object
>>
>> Use type Edje_Object instead of Eo in legacy EAPI's.
>
>
> I saw lots of inconsistent type usage when going through Evas legacy
> headers.
> Do we want to use stronger type names? I.e.:
>
> Evas_Image for evas_object_image functions,
> Evas_Object for generic evas_object functions,
> And Eo only as a last resort?
>
> I spotted those in the ABI report.

I don't know about legacy. But I think the type name used should
convey the most restricted set of objects where all valid types
are part of this set. IOW, stronger type names.

This helps C++ static type checking and will avoid unecessary
downcasting on C++ and other static typing languages.

I think we should make this a guideline and/or policy.

Regards,
-- 
Felipe Magno de Almeida

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/efl] master 02/02: eina_matrix: Add since tags to all new functions in 1.14

[Cedric BAIL]

Hello,

On Thu, Apr 9, 2015 at 7:44 AM, ChunEon Park  wrote:
> Current matrix usage seems going wrong.
> I found the current matrix usage is this.
>
> matrix m;
> matrix_translate(m, ...);
>
> matrix m2;
> matrix_rotation(m, ...);
>
> matrix m3;
> matrix_scale(m, ...);
>
> matrix m4;
> matrix_compose(m, m2, m4);
>
> matrix m5;
> matrix_compose(m3, m4, m5);
>
> it's unnecessary and inefficient.
> Rather than, default matrix usage should be designed to compose of the 
> transforms.
>
> matrix m;
> matrix_identify(m);
> matrix_translate(m);
> matrix_rotate(m);
> matrix_scale(m);
>
> if you focused to single factor transform rather than composition
> then single vector is enough to use rather than matrix.

I am not to sure I understand what you mean correctly here. Your
suggestion would be to actually apply the transformation on an
existing matrix doing the set + compose in one step instead of two and
simplifying the operation by knowing where the zero already are in the
composition operation. The reason it is like this, is that in SVG you
only read the matrix once, but you compose it almost every single
frame. It made the core more compact and easier to read, but I can
understand that in different usage scenario you would want to have a
more optimized code path. I guess it can be done.
-- 
Cedric BAIL

--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel