Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread The Rasterman 
On Thu, 14 Jan 2016 17:18:03 + Tom Hacohen  said:

> On 14/01/16 01:45, Carsten Haitzler wrote:
> > On Wed, 13 Jan 2016 14:50:20 + Andrew Williams 
> > said:
> >
> >> On Wed, 13 Jan 2016 at 13:22 Tom Hacohen  wrote:
> >>
> >>> On 13/01/16 10:54, David Seikel wrote:
> 
> >>> More specifically, I disagree with raster on the build now and remove
> >>> later. Elementary is a completely separate module (to the point that
> >>> it's in its own repo at the moment!). I think it's very reasonable to
> >>> have a "disable" flag for it. It takes time to build elementary, I don't
> >>> want to waste that time either (if I don't want it).
> >>>
> >>>
> >>>
> >> When it comes to build time I want to be able to get it down to an absolute
> >> minimum.
> >> For me this includes being able to build sub-portions at will.
> >> In an ideal world for me the top level would be an agregation that can
> >> build all/any of the children and each library/module that can sanely be
> >> built seperately should be possible.
> >> To facilitate real test driven development it's critical that you be able
> >> to write a test / feature / bug fix and compile for near-immediate feedback
> >> on your work.
> >>
> >> I know it's not something that everyone shares but pushing against this
> >> flexibility is something that I struggle to see value in.
> >
> > actually our issue right now is you cant build  a sub-module or sub tree.
> > you always have to build from top. this makes devlopement insanely slow as
> > these builds now always take a minute or so rather than a few seconds - as
> > they walk over everything and "skip".
> >
> > while this allows for much better parallel builds for a full build, it
> > severely hurts development builds (where all u want is to rebuild libevas or
> > libeina and not rebuild everything that also depends on it too). this was a
> > mistake and we need to have the old-school subdir build that elm still has
> > back in efl.
> >
> > eolain is creating issues here in that is touching/modifying files that have
> > not actually changed content and thus causing other regenerations by make
> > etc.
> >
> > we need to fix this. eolain maybe needs to generate the new file to
> > filename.tmp then do a comparison of old filename vs filename.tmp - if they
> > are identical, simply throw away filename.tmp. this will be far more
> > efficient for our builds.
> >
> 
> No it's not. Eolian is only regenerating the changes .eo files! It does 
> however regen when Eolian files change or eolian_gen changes, which 
> means that when you change eolian's source code or eina, it'll regen. 
> Sure, we could actually improve it not to "touch" when the output is the 
> same. Will get Daniel on it. :)

i get build issues much higher up these days like i just touch elm_config.h and
i get:

  CC   libelementary_la-elc_ctxpopup.lo
  CC   libelementary_la-elc_fileselector.lo
  CC   libelementary_la-elc_fileselector_button.lo
  CC   libelementary_la-elc_fileselector_entry.lo
  CC   libelementary_la-elc_hoversel.lo
  CC   libelementary_la-elc_multibuttonentry.lo
  CC   libelementary_la-elc_naviframe.lo
  CC   libelementary_la-elc_player.lo
  CC   libelementary_la-elc_scrolled_entry.lo
  CC   libelementary_la-elc_popup.lo
mv: ‘.deps/libelementary_la-elc_hoversel.Tpo’ and
‘.deps/libelementary_la-elc_hoversel.Plo’ are the same file mv:
‘.deps/libelementary_la-elc_fileselector_button.Tpo’ and
‘.deps/libelementary_la-elc_fileselector_button.Plo’ are the same file
Makefile:1488: recipe for target 'libelementary_la-elc_fileselector_button.lo'
failed make[1]: *** [libelementary_la-elc_fileselector_button.lo] Error 1 make
[1]: *** Waiting for unfinished jobs Makefile:1502: recipe for target
'libelementary_la-elc_hoversel.lo' failed make[1]: ***
[libelementary_la-elc_hoversel.lo] Error 1 mv:
‘.deps/libelementary_la-elc_popup.Tpo’ and
‘.deps/libelementary_la-elc_popup.Plo’ are the same file Makefile:1530: recipe
for target 'libelementary_la-elc_popup.lo' failed make[1]: ***
[libelementary_la-elc_popup.lo] Error 1 mv:
‘.deps/libelementary_la-elc_multibuttonentry.Tpo’ and
‘.deps/libelementary_la-elc_multibuttonentry.Plo’ are the same file
Makefile:1509: recipe for target 'libelementary_la-elc_multibuttonentry.lo'
failed make[1]: *** [libelementary_la-elc_multibuttonentry.lo] Error 1 mv:
‘.deps/libelementary_la-elc_naviframe.Tpo’ and
‘.deps/libelementary_la-elc_naviframe.Plo’ are the same file Makefile:1516:
recipe for target 'libelementary_la-elc_naviframe.lo' failed make[1]: ***
[libelementary_la-elc_naviframe.lo] Error 1 mv:
‘.deps/libelementary_la-elc_ctxpopup.Tpo’ and
‘.deps/libelementary_la-elc_ctxpopup.Plo’ are the same file Makefile:1474:
recipe for target 'libelementary_la-elc_ctxpopup.lo' failed make[1]: ***
[libelementary_la-elc_ctxpopup.lo] Error 1 mv:
‘.deps/libelementary_la-elc_fileselector.Tpo’ and
‘.deps/libelementary_la-elc_fileselector.Plo’ are the same file mv:
‘.deps/libelementary_

Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread The Rasterman 
On Thu, 14 Jan 2016 17:25:07 + Tom Hacohen  said:

> On 14/01/16 17:18, Tom Hacohen wrote:
> > On 14/01/16 01:45, Carsten Haitzler wrote:
> >> On Wed, 13 Jan 2016 14:50:20 + Andrew Williams 
> >> said:
> >>
> >>> On Wed, 13 Jan 2016 at 13:22 Tom Hacohen  wrote:
> >>>
>  On 13/01/16 10:54, David Seikel wrote:
> >
>  More specifically, I disagree with raster on the build now and remove
>  later. Elementary is a completely separate module (to the point that
>  it's in its own repo at the moment!). I think it's very reasonable to
>  have a "disable" flag for it. It takes time to build elementary, I don't
>  want to waste that time either (if I don't want it).
> 
> 
> 
> >>> When it comes to build time I want to be able to get it down to an
> >>> absolute minimum.
> >>> For me this includes being able to build sub-portions at will.
> >>> In an ideal world for me the top level would be an agregation that can
> >>> build all/any of the children and each library/module that can sanely be
> >>> built seperately should be possible.
> >>> To facilitate real test driven development it's critical that you be able
> >>> to write a test / feature / bug fix and compile for near-immediate
> >>> feedback on your work.
> >>>
> >>> I know it's not something that everyone shares but pushing against this
> >>> flexibility is something that I struggle to see value in.
> >>
> >> actually our issue right now is you cant build  a sub-module or sub tree.
> >> you always have to build from top. this makes devlopement insanely slow as
> >> these builds now always take a minute or so rather than a few seconds - as
> >> they walk over everything and "skip".
> >>
> >> while this allows for much better parallel builds for a full build, it
> >> severely hurts development builds (where all u want is to rebuild libevas
> >> or libeina and not rebuild everything that also depends on it too). this
> >> was a mistake and we need to have the old-school subdir build that elm
> >> still has back in efl.
> >>
> >> eolain is creating issues here in that is touching/modifying files that
> >> have not actually changed content and thus causing other regenerations by
> >> make etc.
> >>
> >> we need to fix this. eolain maybe needs to generate the new file to
> >> filename.tmp then do a comparison of old filename vs filename.tmp - if
> >> they are identical, simply throw away filename.tmp. this will be far more
> >> efficient for our builds.
> >>
> >
> > No it's not. Eolian is only regenerating the changes .eo files! It does
> > however regen when Eolian files change or eolian_gen changes, which
> > means that when you change eolian's source code or eina, it'll regen.
> > Sure, we could actually improve it not to "touch" when the output is the
> > same. Will get Daniel on it. :)
> 
> Just talked to Daniel about it, and apparently we tried it a few months 
> ago, but it didn't work out well. Autotools didn't like the fact that 
> although it asked us to rebuild bla.eo.h it stayed with the same 
> timestamp... I don't think there's a clean way of doing that.
> 
> Maybe we could just remove the dependency on eolian_gen though, it was 
> more useful doing development, and not as useful now. This should fix 
> the issue too.

i think that is smart. its stable-ish now and the few changes we make, we can
force a rebuild manually.


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


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 02/03: popup: add popup default align config for other profiles.

2016-01-14 Thread Cedric BAIL 
Hello,

Following Andrew's idea, I have pushed a potential fix for this issue
( b2a0b45cad0d72d8f7c95cb1078738d8f5ab2094 ). Let me know if the
problem is fixed for you guys.

Thanks,
  Cedric

On Tue, Jan 12, 2016 at 1:56 AM, Andrew Williams  wrote:
> Hi,
>
> Would this maybe be resolved by bumping the elementary config version and
> moving the 0.5 default setting to a new minor revision? src/lib/elm_config.c
> 
>
> Just a thought,
> Andrew
>
> On Sun, 10 Jan 2016 at 15:44 Andrew Williams  wrote:
>
>> \o/ I though this one was just me!
>>
>> Cheers,
>> Andy
>> On Tue, 5 Jan 2016 at 15:46, Stefan Schmidt 
>> wrote:
>>
>>> Hello.
>>>
>>> On 05/01/16 16:32, Davide Andreoli wrote:
>>> > 2016-01-05 11:26 GMT+01:00 Stefan Schmidt :
>>> >
>>> >> Hello.
>>> >>
>>> >> On 04/01/16 14:11, Davide Andreoli wrote:
>>> >>> 2015-12-20 18:55 GMT+01:00 Davide Andreoli :
>>> >>>
>>>  2015-12-08 1:39 GMT+01:00 taehyub :
>>> 
>>> > cedric pushed a commit to branch master.
>>> >
>>> >
>>> >
>>> >>
>>> http://git.enlightenment.org/core/elementary.git/commit/?id=61648ba5a38bc8ab1e7a4721f17683abc701ebd4
>>> > commit 61648ba5a38bc8ab1e7a4721f17683abc701ebd4
>>> > Author: taehyub 
>>> > Date:   Mon Dec 7 15:53:47 2015 -0800
>>> >
>>> >   popup: add popup default align config for other profiles.
>>> >
>>> >   Summary:
>>> >   The alignment of popup can be different in each profiles.
>>> >   So I added the align configuration of popup.
>>> >   @feature
>>> >
>>>  After this commit (I think) all the popup on my system appear
>>> top-left
>>>  aligned.
>>> 
>>>  Reading the commit seems quite clear that you need a fresh elm config
>>>  to have the popups correcly aligned...   :/
>>> 
>>> >>> So? no one replayed to this  :( cedric?
>>> >>>
>>> >>> I think we still have broken popup align everywhere (unless you wipe
>>> your
>>> >>> elm config)
>>> >> Do we have a phab ticket for this one? If not it would be good to have
>>> >> it so I can put it on my 1.17 task list which keeps track of things we
>>> >> need to take care of before 1.17.
>>> >>
>>> >
>>> >   T3008 created right now
>>> >
>>>
>>> And you already put it into show stoppers, thanks. I will work on the
>>> 1.17 task list tomorrow.
>>>
>>> regards
>>> Stefan Schmidt
>>>
>>>
>>> --
>>> ___
>>> enlightenment-devel mailing list
>>> enlightenment-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>>
>>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Cedric BAIL

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread Tom Hacohen 
On 14/01/16 01:39, Carsten Haitzler wrote:
> On Wed, 13 Jan 2016 10:07:01 + Andrew Williams  
> said:
>
>> Hi,
>>
>> I agree with all your points and consider the merge a good thing. However
>> I'm not sure why we're avoiding a --disable flag for those who specifically
>> don't want it - is it much work to satisfy a use case?
>
> it ENCOURAGES people then to make efl builds without widgets (elm). this is 
> not
> something we'd want to encourage.
>

I disagree. It doesn't encourage that, it just doesn't discourage it as 
much. Package maintainers will build with the widgets, and people who 
know what they are doing and know they need the fat off will use it.

Heck, if you really want, call it 
--disable-elementary-i-really-know-what-i-am-doing-i-dont-like-widgets.

--
Tom.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread Tom Hacohen 
On 14/01/16 17:18, Tom Hacohen wrote:
> On 14/01/16 01:45, Carsten Haitzler wrote:
>> On Wed, 13 Jan 2016 14:50:20 + Andrew Williams  
>> said:
>>
>>> On Wed, 13 Jan 2016 at 13:22 Tom Hacohen  wrote:
>>>
 On 13/01/16 10:54, David Seikel wrote:
>
 More specifically, I disagree with raster on the build now and remove
 later. Elementary is a completely separate module (to the point that
 it's in its own repo at the moment!). I think it's very reasonable to
 have a "disable" flag for it. It takes time to build elementary, I don't
 want to waste that time either (if I don't want it).



>>> When it comes to build time I want to be able to get it down to an absolute
>>> minimum.
>>> For me this includes being able to build sub-portions at will.
>>> In an ideal world for me the top level would be an agregation that can
>>> build all/any of the children and each library/module that can sanely be
>>> built seperately should be possible.
>>> To facilitate real test driven development it's critical that you be able
>>> to write a test / feature / bug fix and compile for near-immediate feedback
>>> on your work.
>>>
>>> I know it's not something that everyone shares but pushing against this
>>> flexibility is something that I struggle to see value in.
>>
>> actually our issue right now is you cant build  a sub-module or sub tree. you
>> always have to build from top. this makes devlopement insanely slow as these
>> builds now always take a minute or so rather than a few seconds - as they 
>> walk
>> over everything and "skip".
>>
>> while this allows for much better parallel builds for a full build, it
>> severely hurts development builds (where all u want is to rebuild libevas or
>> libeina and not rebuild everything that also depends on it too). this was a
>> mistake and we need to have the old-school subdir build that elm still has 
>> back
>> in efl.
>>
>> eolain is creating issues here in that is touching/modifying files that have
>> not actually changed content and thus causing other regenerations by make 
>> etc.
>>
>> we need to fix this. eolain maybe needs to generate the new file to
>> filename.tmp then do a comparison of old filename vs filename.tmp - if they 
>> are
>> identical, simply throw away filename.tmp. this will be far more efficient 
>> for
>> our builds.
>>
>
> No it's not. Eolian is only regenerating the changes .eo files! It does
> however regen when Eolian files change or eolian_gen changes, which
> means that when you change eolian's source code or eina, it'll regen.
> Sure, we could actually improve it not to "touch" when the output is the
> same. Will get Daniel on it. :)

Just talked to Daniel about it, and apparently we tried it a few months 
ago, but it didn't work out well. Autotools didn't like the fact that 
although it asked us to rebuild bla.eo.h it stayed with the same 
timestamp... I don't think there's a clean way of doing that.

Maybe we could just remove the dependency on eolian_gen though, it was 
more useful doing development, and not as useful now. This should fix 
the issue too.

--
Tom.


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread Tom Hacohen 
On 14/01/16 01:45, Carsten Haitzler wrote:
> On Wed, 13 Jan 2016 14:50:20 + Andrew Williams  
> said:
>
>> On Wed, 13 Jan 2016 at 13:22 Tom Hacohen  wrote:
>>
>>> On 13/01/16 10:54, David Seikel wrote:

>>> More specifically, I disagree with raster on the build now and remove
>>> later. Elementary is a completely separate module (to the point that
>>> it's in its own repo at the moment!). I think it's very reasonable to
>>> have a "disable" flag for it. It takes time to build elementary, I don't
>>> want to waste that time either (if I don't want it).
>>>
>>>
>>>
>> When it comes to build time I want to be able to get it down to an absolute
>> minimum.
>> For me this includes being able to build sub-portions at will.
>> In an ideal world for me the top level would be an agregation that can
>> build all/any of the children and each library/module that can sanely be
>> built seperately should be possible.
>> To facilitate real test driven development it's critical that you be able
>> to write a test / feature / bug fix and compile for near-immediate feedback
>> on your work.
>>
>> I know it's not something that everyone shares but pushing against this
>> flexibility is something that I struggle to see value in.
>
> actually our issue right now is you cant build  a sub-module or sub tree. you
> always have to build from top. this makes devlopement insanely slow as these
> builds now always take a minute or so rather than a few seconds - as they walk
> over everything and "skip".
>
> while this allows for much better parallel builds for a full build, it
> severely hurts development builds (where all u want is to rebuild libevas or
> libeina and not rebuild everything that also depends on it too). this was a
> mistake and we need to have the old-school subdir build that elm still has 
> back
> in efl.
>
> eolain is creating issues here in that is touching/modifying files that have
> not actually changed content and thus causing other regenerations by make etc.
>
> we need to fix this. eolain maybe needs to generate the new file to
> filename.tmp then do a comparison of old filename vs filename.tmp - if they 
> are
> identical, simply throw away filename.tmp. this will be far more efficient for
> our builds.
>

No it's not. Eolian is only regenerating the changes .eo files! It does 
however regen when Eolian files change or eolian_gen changes, which 
means that when you change eolian's source code or eina, it'll regen. 
Sure, we could actually improve it not to "touch" when the output is the 
same. Will get Daniel on it. :)

--
Tom.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_config: print an eror message if we fail to save the derived config profile

2016-01-14 Thread Stefan Schmidt 
Hello.

On 14/01/16 16:14, Tom Hacohen wrote:
> On 14/01/16 14:55, Stefan Schmidt wrote:
>> stefan pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=6b84a60928fcdc57f035a22af783355a139b1819
>>
>> commit 6b84a60928fcdc57f035a22af783355a139b1819
>> Author: Stefan Schmidt 
>> Date:   Thu Jan 14 15:53:53 2016 +0100
>>
>>   elm_config: print an eror message if we fail to save the derived 
>> config profile
>> ---
>>src/lib/elm_config.c | 9 -
>>1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/src/lib/elm_config.c b/src/lib/elm_config.c
>> index 647679d..113c92c 100644
>> --- a/src/lib/elm_config.c
>> +++ b/src/lib/elm_config.c
>> @@ -780,8 +780,15 @@ _elm_config_profile_derived_save(const char *profile, 
>> Elm_Config_Derived *derive
>>   if (ef)
>> {
>>ret = eet_data_write(ef, _config_derived_edd, "config", derived, 
>> 1);
>> +if (ret)
>> +  {
>> + ecore_file_mv(buf, buf2);
>> +  }
>> +else
>> +  {
>> + ERR("Error saving Elementary's derived configuration profile 
>> file");
>> +  }
>>eet_close(ef);
>> -if (ret) ecore_file_mv(buf, buf2);
>> }
>>}
>>
>>
> Thanks, though one more comment: is it a good idea to move the file
> before you closed it? I'd expect a flush to happen only on close, even
> if not now, in the future.

Its not a good idea and it was correct before my change. A bit 
embarrassing that I need three commits here. Anyway, fixed now as well.

Last commit for today...

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_config: print an eror message if we fail to save the derived config profile

2016-01-14 Thread Tom Hacohen 
On 14/01/16 14:55, Stefan Schmidt wrote:
> stefan pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=6b84a60928fcdc57f035a22af783355a139b1819
>
> commit 6b84a60928fcdc57f035a22af783355a139b1819
> Author: Stefan Schmidt 
> Date:   Thu Jan 14 15:53:53 2016 +0100
>
>  elm_config: print an eror message if we fail to save the derived config 
> profile
> ---
>   src/lib/elm_config.c | 9 -
>   1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/src/lib/elm_config.c b/src/lib/elm_config.c
> index 647679d..113c92c 100644
> --- a/src/lib/elm_config.c
> +++ b/src/lib/elm_config.c
> @@ -780,8 +780,15 @@ _elm_config_profile_derived_save(const char *profile, 
> Elm_Config_Derived *derive
>  if (ef)
>{
>   ret = eet_data_write(ef, _config_derived_edd, "config", derived, 1);
> +if (ret)
> +  {
> + ecore_file_mv(buf, buf2);
> +  }
> +else
> +  {
> + ERR("Error saving Elementary's derived configuration profile 
> file");
> +  }
>   eet_close(ef);
> -if (ret) ecore_file_mv(buf, buf2);
>}
>   }
>
>

Thanks, though one more comment: is it a good idea to move the file 
before you closed it? I'd expect a flush to happen only on close, even 
if not now, in the future.

--
Tom.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_config: handle eet_data_write possible error return

2016-01-14 Thread Stefan Schmidt 
Hello.

On 14/01/16 14:25, Tom Hacohen wrote:
> On 14/01/16 13:23, Stefan Schmidt wrote:
>> stefan pushed a commit to branch master.
>>
>> http://git.enlightenment.org/core/elementary.git/commit/?id=9ef32f1b59df32ec3c45e753f076c589920fe386
>>
>> commit 9ef32f1b59df32ec3c45e753f076c589920fe386
>> Author: Stefan Schmidt 
>> Date:   Thu Jan 14 14:22:23 2016 +0100
>>
>>   elm_config: handle eet_data_write possible error return
>>
>>   CID: 1347399
>> ---
>>src/lib/elm_config.c | 5 +++--
>>1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/lib/elm_config.c b/src/lib/elm_config.c
>> index 4fc2f3b..647679d 100644
>> --- a/src/lib/elm_config.c
>> +++ b/src/lib/elm_config.c
>> @@ -767,6 +767,7 @@ _elm_config_profile_derived_save(const char *profile, 
>> Elm_Config_Derived *derive
>>{
>>   Eet_File *ef;
>>   char buf[PATH_MAX], buf2[PATH_MAX];
>> +   int ret;
>>
>>   _elm_config_user_dir_snprintf(buf, sizeof(buf), "config/%s",
>> profile ? profile : _elm_profile);
>> @@ -778,9 +779,9 @@ _elm_config_profile_derived_save(const char *profile, 
>> Elm_Config_Derived *derive
>>   ef = eet_open(buf, EET_FILE_MODE_WRITE);
>>   if (ef)
>> {
>> -eet_data_write(ef, _config_derived_edd, "config", derived, 1);
>> +ret = eet_data_write(ef, _config_derived_edd, "config", derived, 1);
>>eet_close(ef);
>> -ecore_file_mv(buf, buf2);
>> +if (ret) ecore_file_mv(buf, buf2);
>> }
>>}
>>
>>
> No error message or anything? :(

Fair point. Missed the opportunity. Fixed now.

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [core/elementary] master 01/01: elm_config: handle eet_data_write possible error return

2016-01-14 Thread Tom Hacohen 
On 14/01/16 13:23, Stefan Schmidt wrote:
> stefan pushed a commit to branch master.
>
> http://git.enlightenment.org/core/elementary.git/commit/?id=9ef32f1b59df32ec3c45e753f076c589920fe386
>
> commit 9ef32f1b59df32ec3c45e753f076c589920fe386
> Author: Stefan Schmidt 
> Date:   Thu Jan 14 14:22:23 2016 +0100
>
>  elm_config: handle eet_data_write possible error return
>
>  CID: 1347399
> ---
>   src/lib/elm_config.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/src/lib/elm_config.c b/src/lib/elm_config.c
> index 4fc2f3b..647679d 100644
> --- a/src/lib/elm_config.c
> +++ b/src/lib/elm_config.c
> @@ -767,6 +767,7 @@ _elm_config_profile_derived_save(const char *profile, 
> Elm_Config_Derived *derive
>   {
>  Eet_File *ef;
>  char buf[PATH_MAX], buf2[PATH_MAX];
> +   int ret;
>
>  _elm_config_user_dir_snprintf(buf, sizeof(buf), "config/%s",
>profile ? profile : _elm_profile);
> @@ -778,9 +779,9 @@ _elm_config_profile_derived_save(const char *profile, 
> Elm_Config_Derived *derive
>  ef = eet_open(buf, EET_FILE_MODE_WRITE);
>  if (ef)
>{
> -eet_data_write(ef, _config_derived_edd, "config", derived, 1);
> +ret = eet_data_write(ef, _config_derived_edd, "config", derived, 1);
>   eet_close(ef);
> -ecore_file_mv(buf, buf2);
> +if (ret) ecore_file_mv(buf, buf2);
>}
>   }
>
>

No error message or anything? :(

--
Tom.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] FOSDEM

2016-01-14 Thread Andrew Williams 
On Mon, 11 Jan 2016 at 18:41 Andrew Williams  wrote:

> Oh, that sounds like fun.
> I'm free that weekend and may be able to hop over to see it and help out.
> If you think I could be of help then I'm sure it could tip the balance for
> me to go :)
>
> Cheers,
> Andrew
>
> On Mon, 11 Jan 2016 at 16:29 Tom Hacohen  wrote:
>
>> On 11/01/16 16:11, Philippe Caseiro wrote:
>> > Hi !
>> >
>> >This year like every year we have a booth @ FOSDEM, but this year we
>> > share 2 tables with the Tizen Community, they will bring a Lot of
>> > demos so thanks to them.
>> >
>> >Like every year we have to manage the booth.
>> >
>> >That's why I send this mail.
>> >
>> >If you attend FOSDEM please answer to this mail.
>> >
>> >   If you want to help @ the booth please tell me.
>> >
>> > Regards
>> >
>>
>> I'm attending and would like to help.
>>
>> --
>> Tom.
>>
>>
Confirmed now that I am attending and would be happy to help as well.

Andy
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] x32 (not x86 32 bit) builds are to be removed from our Jenkins

2016-01-14 Thread David Seikel 
On Thu, 14 Jan 2016 21:19:14 +1030 Simon Lees  wrote:

> 
> 
> On 01/14/2016 09:02 PM, Stefan Schmidt wrote:
> > Hello.
> >
> > We are going to remove the x32 builds from our Jenkins setup. This
> > ABI never really got flying for any users of EFL I heard about.
> > Removing the builds and the actual VM for it will free up resources
> > we can user for other tasks. If you have good arguments for us
> > keeping this speak up now as we are going to remove it next week. I
> > already disabled the related builds to fade it out.
> >
> > Some folks are confused by the x32 name. It is _not_ the x86 32 bit
> > architecture you still might run. We are still supporting this one.
> > x32 is an ABI to use some benefits of the x86_64 architecture while
> > avoiding the 64bit pointer penalty.
> > https://en.wikipedia.org/wiki/X32_ABI
> >
> > regards
> > Stefan Schmidt
> >
> As a point of reference openSUSE has already dropped both x32 (Never 
> took off) and x86 32bit, 32bit arm is obviously still around.

Until now I had never even heard of x32.  lol

I guess I wont miss it.  I do use x86 32 bit builds though.

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


signature.asc
Description: PGP signature
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] x32 (not x86 32 bit) builds are to be removed from our Jenkins

2016-01-14 Thread Simon Lees 


On 01/14/2016 09:02 PM, Stefan Schmidt wrote:
> Hello.
>
> We are going to remove the x32 builds from our Jenkins setup. This ABI
> never really got flying for any users of EFL I heard about. Removing the
> builds and the actual VM for it will free up resources we can user for
> other tasks. If you have good arguments for us keeping this speak up now
> as we are going to remove it next week. I already disabled the related
> builds to fade it out.
>
> Some folks are confused by the x32 name. It is _not_ the x86 32 bit
> architecture you still might run. We are still supporting this one. x32
> is an ABI to use some benefits of the x86_64 architecture while avoiding
> the 64bit pointer penalty. https://en.wikipedia.org/wiki/X32_ABI
>
> regards
> Stefan Schmidt
>
As a point of reference openSUSE has already dropped both x32 (Never 
took off) and x86 32bit, 32bit arm is obviously still around.

Cheers
Simon

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[E-devel] x32 (not x86 32 bit) builds are to be removed from our Jenkins

2016-01-14 Thread Stefan Schmidt 
Hello.

We are going to remove the x32 builds from our Jenkins setup. This ABI 
never really got flying for any users of EFL I heard about. Removing the 
builds and the actual VM for it will free up resources we can user for 
other tasks. If you have good arguments for us keeping this speak up now 
as we are going to remove it next week. I already disabled the related 
builds to fade it out.

Some folks are confused by the x32 name. It is _not_ the x86 32 bit 
architecture you still might run. We are still supporting this one. x32 
is an ABI to use some benefits of the x86_64 architecture while avoiding 
the 64bit pointer penalty. https://en.wikipedia.org/wiki/X32_ABI

regards
Stefan Schmidt

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] Merging Efl and elementary

2016-01-14 Thread Tom Hacohen 
On 14/01/16 01:52, Carsten Haitzler wrote:
> On Wed, 13 Jan 2016 13:25:58 + Tom Hacohen  said:
>
>> On 12/01/16 00:42, Cedric BAIL wrote:
>>> Hello,
>>>
>>> As we are moving forward with a stable API for binding, one of the
>>> main "weirdness" that is still exposed is that you need to actually
>>> require two differents library to use efl. Also the only reason why we
>>> haven't merged elementary so far as been because it still depend on
>>> webkit-efl and webkit-efl depend on elementary.
>>>
>>> I am going to address that during next efl release cycle, by moving
>>> the webkit dependency to be a module (like evas_generic_loaders and
>>> emotion_generic_loaders). Once that is done it will be technically
>>> possible to merge the both of them.
>>>
>>> This open a question, does anyone see any other reason to not merge
>>> elementary ?
>>>
>>> If there is no other problem being seen to do this, there is a few
>>> things that will be impacted :
>>> - elementary developers branch can not be merged into an efl branch
>>> automatically. Developers will have to either finish their patch
>>> before we merge or have to take care themself of doing the move from
>>> an elementary branch to an efl branch.
>>>
>>> - for the same reason, phab patch on elementary that won't have landed
>>> before the merge will also be abandonned and their respective author
>>> will have to move their patch on top of efl new merged tree.
>>>
>>> Due to the above effect, we should come with a clear timeline if and
>>> when we do that merge to allow everyone to handle that big of a change
>>> early enough to not loose time on patching the wrong piece of code.
>>> Also I think this is going to impact efl 1.18 release cycle, and maybe
>>> it should be adapted with maybe a technology preview in the middle of
>>> the release cycle just after the merge ?
>>>
>>> Stefan what is your take on such a big change ?
>>>
>>> Cheers,
>>>
>>
>> As I already told you in private, let me know when, and I'll migrate the
>> Git history.
>>
>> As for the patches/branches: it's actually not that hard, we just need
>> to write a small script that maps previous file locations to new ones.
>> This should work for everything, except for maybe Makefiles.
>>
>> I wonder if git (which already does file moving detection) can handle
>> this gracefully when applying a patch. That is, doing something like:
>> "apply this patch based on commit  and then follow the file moves
>> until HEAD." I'm pretty sure this can be done with changing history, not
>> sure about without.
>
> wouldnt it just work to add an efl/elementary dir inside of which we import 
> the
> entire git history of elm wholesale "as-is" and then from here git mv the 
> files
> or dirs to new locations?
>

That's exactly how it's going to be done (what we did for the EFL too). 
I was just wondering if there was a way to still cleanly and easily 
apply yet-to-be-applied-patches written for elementary.git to this new 
repo without my involvement. I.e just git am SOME_PATCH.patch.

--
Tom.

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] [EGIT] [tools/eflete] master 121/122: Revert "workspace: hide and show demo instead of deletion, to keep all set values"

2016-01-14 Thread Viacheslav Reutskiy 
Hello

On 01/13/2016 05:36 PM, Mike Blumenkrantz wrote:
> Hi,
>
> I realize that this is a project that you are working on, and that many
> times you will have a lot of commits to push at once, but can you avoid
> pushing commits that revert commits made in the same push? Not only does
> this sort of behavior ruin your project's history with nonsense commits,
> but it also creates more noise for anyone who is watching it.
Mike, thanks for the comment. We are trying to follow the efl guidelines,
but this time we be in a hurry and forgot add comment to revert commits.

Thanks.
> Thanks!
>
> On Wed, Jan 13, 2016 at 9:53 AM Vitalii Vorobiov 
> wrote:
>
>> rimmed pushed a commit to branch master.
>>
>>
>> http://git.enlightenment.org/tools/eflete.git/commit/?id=3c59c66ca77e58fafc0cd3c8f853fb43c60bae0d
>>
>> commit 3c59c66ca77e58fafc0cd3c8f853fb43c60bae0d
>> Author: Vitalii Vorobiov 
>> Date:   Wed Jan 13 14:41:04 2016 +0200
>>
>>  Revert "workspace: hide and show demo instead of deletion, to keep all
>> set values"
>>
>>  This reverts commit 59ac43c1672cddeec45e3eb161685fe8c89fcd26.
>>
>>  Change-Id: I1d4c40010f77cb241cb7d9c3e9531fe43dfe6551
>> ---
>>   src/bin/ui/workspace/workspace.c | 6 ++
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git a/src/bin/ui/workspace/workspace.c
>> b/src/bin/ui/workspace/workspace.c
>> index a9d914f..3a4787d 100644
>> --- a/src/bin/ui/workspace/workspace.c
>> +++ b/src/bin/ui/workspace/workspace.c
>> @@ -951,7 +951,7 @@ _mode_changed(void *data,
>>  if ((sd->active_mode == MODE_NORMAL)/* || (sd->active_mode ==
>> MODE_SEPARATE) */)
>>evas_object_hide(sd->groupedit);
>>  else
>> - evas_object_hide(sd->active_mode_object);
>> + evas_object_del(sd->active_mode_object);
>>
>>  mode = elm_radio_state_value_get(obj);
>>
>> @@ -980,8 +980,7 @@ _mode_changed(void *data,
>>   workspace_separate_mode_set(sd->obj, false);
>>   container_border_show(sd->container.obj);
>>
>> -if (!sd->active_mode_object)
>> -  sd->active_mode_object = demo_add(sd->scroller, sd->group);
>> +sd->active_mode_object = demo_add(sd->scroller, sd->group);
>>   evas_object_show(sd->active_mode_object);
>>   container_content_set(sd->container.obj,
>> sd->active_mode_object);
>>
>> @@ -1267,7 +1266,6 @@ _workspace_smart_del(Evas_Object *o)
>>  evas_object_del(sd->highlight.highlight);
>>  demo_group_del(sd->demo_group);
>>  gm_group_edit_object_unload(sd->group);
>> -   evas_object_del(sd->active_mode_object);
>>  _workspace_parent_sc->del(o);
>>   }
>>
>>
>> --
>>
>>
>>
> --
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
Viacheslav Reutskiy (rimmed)


--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel