Re: [E-devel] Get an IRC meeting togther?
On Thursday, 19 April 2018 06:59:51 ACST, William L. Thomson Jr. wrote: > Pre meeting, per meeting, developer activities page > > It is a good idea to as part of any roll call, for each to say what > they are working on, plan to, amount of time they plan to spend in > development for the next month. Along with anything else they feel > others should know about their activities past, present or future. That > is something good for recurring, every meeting. My experience of this particularly in meetings of more then 5 people is you spend 90% of the meeting just going around saying what you've done and are working on and very little time discussing the issues that need to be discussed, while we have a long list of agenda items i'm against doing this. If we get to a point were we are meeting regularly and the agenda has thinned out a bit then maybe. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther? (IRC Channel Merge)
When is the date for this meeting. Also can we add something to the agenda? On 19/04/2018 03:13, Simon Lees wrote: > > > On 18/04/18 18:42, Stefan Schmidt wrote: >> This ticket has items on: >> >> o How to handle EFL proposals >> o Project and or release roadmap >> o Build breakages from commits >> o IRC channel merge > > No idea if i'll make the meeting but this one should be a simple no. > There are plenty of times when we have too much chat volume to squeeze > everything into one channel especially when people are talking detailed > design / implementation in #edevelop, occasionally it feels like we need > a 3rd channel. We should encourage everyone in #edevelop to be in #e and > all non technical discussions to happen in #e though. > > A better question is what are we going to migrate away from slack too > when they close there irc bridge, it was the one competitive advantage > they had over any of the other providers. > signature.asc Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther? (IRC Channel Merge)
On 18/04/18 18:42, Stefan Schmidt wrote: > This ticket has items on: > > o How to handle EFL proposals > o Project and or release roadmap > o Build breakages from commits > o IRC channel merge No idea if i'll make the meeting but this one should be a simple no. There are plenty of times when we have too much chat volume to squeeze everything into one channel especially when people are talking detailed design / implementation in #edevelop, occasionally it feels like we need a 3rd channel. We should encourage everyone in #edevelop to be in #e and all non technical discussions to happen in #e though. A better question is what are we going to migrate away from slack too when they close there irc bridge, it was the one competitive advantage they had over any of the other providers. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
On Wed, 18 Apr 2018 22:41:01 + Stephen Houston wrote: > All of that can be discussed - I was not necessarily suggesting that > we need to make changes there - as that was advocated for in other > threads, tickets, etc... and didn't gain any traction. What I do mean > is that whatever our process is, we need to define it and document it > so it is clear. For sure! It can be a work in progress, and start with something simple. Run it by Carsten, etc :) Maybe you all can start with a developers list page and assign roles/titles and play with stuff from there. It seems most were on board with the idea of a developer list page. Add some titles there you go :) -- William L. Thomson Jr. pgpQ51PoWje2f.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
All of that can be discussed - I was not necessarily suggesting that we need to make changes there - as that was advocated for in other threads, tickets, etc... and didn't gain any traction. What I do mean is that whatever our process is, we need to define it and document it so it is clear. On Wed, Apr 18, 2018, 5:09 PM William L. Thomson Jr. < wlt...@obsidian-studios.com> wrote: > On Wed, 18 Apr 2018 21:38:12 + > Stephen Houston wrote: > > > I would say one agenda item needs to be development of a structure > > plan... i.e. determine what the process is for decision making in the > > project. Who, what, where, when, and why and document that. > > If your meaning like project organization, leadership, etc. I recommend > looking at other projects models that are successful and working. Try > to avoid re-inventing the wheel. Though hybrid cherry plucking I think > is acceptable. Better than invention... Please avoid invention!!! > > I highly recommend AGAINST something like Gentoo's partial GLEP 39 > https://www.gentoo.org/glep/glep-0039.html ( invented pile of dung ) > > The previous GLEP 4 was better and may work for E > https://www.gentoo.org/glep/glep-0004.html > > Debian has an interesting model with a global annually elected lead. > Though I am not sure such would apply to E, with like Carsten's role. I > believe Ian remained around Debian in some capacity, till his departing. > > I some what see Carsten as playing a BDFL type of role. Which some see > as controversial, but that can also be necessary. Part of Gentoo's > demise was loss of such role and move it to a council, rule by > committee, or death by committee... > > All around depending on long term. If wanting a foundation, funding > development etc. I HIGHLY recommend looking at and adopting any of > FreeBSD Foundation's model. I think Debian and FreeBSD are the best. > Though Gnome maybe of consideration given it has corporate interest > which may fit better for like Samsungs role. Gnome is the only that > gives businesses some role, via its Advisory Board. > > https://www.debian.org/intro/organization > https://www.freebsdfoundation.org/what-we-do/ > https://www.freebsd.org/doc/en/books/dev-model/model-orgstruct.html > https://www.gnome.org/foundation/governance/ > https://wiki.gnome.org/AdvisoryBoard > > -- > William L. Thomson Jr. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
On Wed, 18 Apr 2018 21:38:12 + Stephen Houston wrote: > I would say one agenda item needs to be development of a structure > plan... i.e. determine what the process is for decision making in the > project. Who, what, where, when, and why and document that. If your meaning like project organization, leadership, etc. I recommend looking at other projects models that are successful and working. Try to avoid re-inventing the wheel. Though hybrid cherry plucking I think is acceptable. Better than invention... Please avoid invention!!! I highly recommend AGAINST something like Gentoo's partial GLEP 39 https://www.gentoo.org/glep/glep-0039.html ( invented pile of dung ) The previous GLEP 4 was better and may work for E https://www.gentoo.org/glep/glep-0004.html Debian has an interesting model with a global annually elected lead. Though I am not sure such would apply to E, with like Carsten's role. I believe Ian remained around Debian in some capacity, till his departing. I some what see Carsten as playing a BDFL type of role. Which some see as controversial, but that can also be necessary. Part of Gentoo's demise was loss of such role and move it to a council, rule by committee, or death by committee... All around depending on long term. If wanting a foundation, funding development etc. I HIGHLY recommend looking at and adopting any of FreeBSD Foundation's model. I think Debian and FreeBSD are the best. Though Gnome maybe of consideration given it has corporate interest which may fit better for like Samsungs role. Gnome is the only that gives businesses some role, via its Advisory Board. https://www.debian.org/intro/organization https://www.freebsdfoundation.org/what-we-do/ https://www.freebsd.org/doc/en/books/dev-model/model-orgstruct.html https://www.gnome.org/foundation/governance/ https://wiki.gnome.org/AdvisoryBoard -- William L. Thomson Jr. pgpau0wjiNSFd.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
I would say one agenda item needs to be development of a structure plan... i.e. determine what the process is for decision making in the project. Who, what, where, when, and why and document that. On Wed, Apr 18, 2018, 4:16 PM Christophe Sadoine wrote: > On 18 April 2018 at 18:12, Stefan Schmidt wrote: > > > > This ticket has items on: > > > > o How to handle EFL proposals > > o Project and or release roadmap > > o Build breakages from commits > > o IRC channel merge > > o Regular meetings > > o Jenkins build status > > o Changes to beta APIs > > o Moving away from phab > > > > Above you mentioned timed releases for the meeting. > > > > Given the ticket covers _way_ more items besides releases and roadmaps I > asked for clarification. > > > > You asked for a meeting, I asked for the agenda. > > I can write a rough agenda with list of priorities to speak about. > I consider that some of the items above have already been discussed > (as written in the ticket) and would not be brought up unless someone > wants to. > We can also decide and say it shouldn't last more than 1 or 2 hours? I > think 1hour is good. > If some items didn't get discussed, they can be debated in a later > meeting if we want to do one or in the ticket. > > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
Pre meeting, per meeting, developer activities page It is a good idea to as part of any roll call, for each to say what they are working on, plan to, amount of time they plan to spend in development for the next month. Along with anything else they feel others should know about their activities past, present or future. That is something good for recurring, every meeting. Rather than spend time at the meeting. May have a phab page/issue or something per meeting. For each to put such down like in a table format or something. That way each can review just prior to meeting and have insight into each other. Which may help with speeding up discussion in meeting. Either way tends to help keep everyone be on the same page, awareness of what is going on over all, etc. Also can help others outside the project know who is working on what without having to follow commits. May even make that part of some meeting template for topics, date, time, who will attend, who will not, and anything else for each meeting. -- William L. Thomson Jr. pgp1UBNsbQFNs.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
On 18 April 2018 at 18:12, Stefan Schmidt wrote: > > This ticket has items on: > > o How to handle EFL proposals > o Project and or release roadmap > o Build breakages from commits > o IRC channel merge > o Regular meetings > o Jenkins build status > o Changes to beta APIs > o Moving away from phab > > Above you mentioned timed releases for the meeting. > > Given the ticket covers _way_ more items besides releases and roadmaps I > asked for clarification. > > You asked for a meeting, I asked for the agenda. I can write a rough agenda with list of priorities to speak about. I consider that some of the items above have already been discussed (as written in the ticket) and would not be brought up unless someone wants to. We can also decide and say it shouldn't last more than 1 or 2 hours? I think 1hour is good. If some items didn't get discussed, they can be debated in a later meeting if we want to do one or in the ticket. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 02/09: efl: use efl_add_ref to create objects which have no parent
On April 18, 2018 12:48 AM, Carsten Haitzler wrote:
> On Tue, 17 Apr 2018 19:33:02 -0400 Cedric Bail ced...@ddlm.me said:
> > On March 29, 2018 10:58 AM, Carsten Haitzler ras...@rasterman.com wrote:
> > > On Thu, 29 Mar 2018 13:17:43 -0400 Cedric Bail ced...@ddlm.me said:
> > > > On March 28, 2018 8:06 PM, Carsten Haitzler ras...@rasterman.com wrote:
> > > > > On Wed, 28 Mar 2018 12:37:35 -0400 Cedric Bail ced...@ddlm.me said:
> > > > > > On March 27, 2018 10:32 PM, Carsten Haitzler ras...@rasterman.com
> > > > > > wrote:
> > > > > > > On Tue, 20 Mar 2018 17:57:47 -0700 Cedric BAIL cedric.b...@free.fr
> > > > > > > said:
> > > > > > >
> > > > > > > Ideally yes, but at least for the _example, it requires to spend
> > > > > > > some
> > > > > > > more time to move them to use EFL_MAIN, which should be done in a
> > > > > > > different patch not related to fixing the usage of efl_add.
> > > > >
> > > > > some use EFL_MAIN ... otherwise efl_main_loop_get() will work. but
> > > > > moving to efl_add_ref() isn't the "right direction" for most of these.
> > > >
> > > > Yeah, I haven't been a big fan of efl_main_loop_get and did tend to
> > > > avoid
> > > > it. I should use it more often in the future.
> > >
> > > it'd be good to stop doing that... :) long term at least. the slow and
> > > steady steps are to fix our parenting in efl and examples. :) i fixed it
> > > for you - or well i fixed everything i saw you changed. it may not be
> > > perfect, but it's a step in the right direction imho :) point out if i got
> > > something wrong. i didn't do "Extensive" work like you say and convert to
> > > EFL_MAIN or within efl modify code to pass parents around many levels down
> > > or something.
> >
> > So I have been working on finishing correcting the lifecycle of eo object by
> > making sure that efl_invalidate does happen before any efl_destructor code
> > (Currently in master, it is possible to get efl_invalidate to be called
> > after
> > the object destructor as it is called inside efl.object.destructor). This
> > means that efl_del and efl_parent_{get,set} are a typical wrong piece of
> > code
> > in the destructore. The patch 2fb5cc3ad09f6aaf82b5d1131ac5ed22ed848bd4 is
> > wrong in a lot of place that I had to give up fixing it due to time
> > constraint (basically it assume our use before invalidate was
> > efl_add/efl_del, while the closest to our pattern was efl_add_ref with
> > efl_unref in the desstructor). I have a branch devs/cedric/lifecycle with
> > all
> > the change in it including a revert of your patch. I can't land this patch
> > at
> > the moment as the old eo base efl_future lifecycle is a complete wreck with
> > this change, so I will focus back on removing efl_future. If you had time in
> > the mean time to check your patch and see how to fix it, it would be great.
>
> wait wait. first. some objects. actually a fair few objects need to know their
> parents to find their loop provider etc. an they need to do this on "shut
> down"
> to delete stuff etc. from here. so my question will be:
>
> where should an object do this "shut down" in the invalidate or in destructor.
> you seem to say that it mys be in invalidate which means invalidate
> effectifely
> is the "meat" of the destructor, just the object keeps itself around with some
> minimal content until destructor is called. so what you are doing is ensuring
> there is ALWAYS the sequence of invalidate then destroy, right?
So yes, invalidate should always happen before the destructor.
> so i'm not sure what's wrong with that patch - can you detail it? i simply
> moved to having a parent instead of no parent in many cases, and used efl_del
> again like it used to be which should clear out the only reference to the
> object by unparenting it etc. etc. ...
The problem is that efl_del in a destructor will always be either wrong or bad.
Wrong as in you are not the parent/owner of that reference and are trying to
destroy it manually during destructor. Bad as in the child object has already
lost its parent during the invalidate call on the parent, and if it is the only
reference you had on it, it will be dead when reaching the destructor. So
during destructor calling efl_del is likely accessing a dead object. Basically
if we do efl_add, we should not need to call efl_del in the majority of case,
just NULL the reference in the structure during invalidate, that's it. It does
simplify the code a lot actually, but it differ from the code pattern we have
and require more work than just replacing efl_add_ref/efl_unref by
efl_add/efl_del.
> if you reverted the patch you would have lost all the "correct" parenting so
> i'm not sure that that is going to be better at all, unless you kept that and
> it's a partial revert really. i haven't looked at your branch yet, but it's
> kind of not making a lot of sense in this email right now. i am not sure what
> needs fixing where and how from this email at all, so it'd be nice for you
Re: [E-devel] Get an IRC meeting togther?
On Wed, 18 Apr 2018 11:12:04 +0200 Stefan Schmidt said: > Hello. > > > On 04/18/2018 10:57 AM, Carsten Haitzler (The Rasterman) wrote: > > On Wed, 18 Apr 2018 10:32:46 +0200 Stefan Schmidt > > said: > > > >> Hello. > >> > >> > >> On 04/18/2018 09:59 AM, Carsten Haitzler (The Rasterman) wrote: > >>> specifically: > >>> > >>> https://phab.enlightenment.org/T6740 > >>> > >>> timed releases, roadmaps (release, project) etc. it'll be far better to do > >>> this quickly round-trip wise. > >>> > >> Do you consider all items in this ticket as the agenda for the meeting or > >> only the discussion on timed vs feature release and project roadmap? > > did you read the ticket? :) > > > > I did and I have no idea why you would reply to my clear question with > another question. :-) I even read > > This ticket has items on: > > o How to handle EFL proposals > o Project and or release roadmap > o Build breakages from commits > o IRC channel merge > o Regular meetings > o Jenkins build status > o Changes to beta APIs > o Moving away from phab > > Above you mentioned timed releases for the meeting. > > Given the ticket covers _way_ more items besides releases and roadmaps I > asked for clarification. > > You asked for a meeting, I asked for the agenda. whats in the ticket, . i did say "etc.", though i think the priority should be on releases/roadmap. a lot is incidental. a lot of these we can put to bed quickly. -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
Hello. On 04/18/2018 10:57 AM, Carsten Haitzler (The Rasterman) wrote: > On Wed, 18 Apr 2018 10:32:46 +0200 Stefan Schmidt > said: > >> Hello. >> >> >> On 04/18/2018 09:59 AM, Carsten Haitzler (The Rasterman) wrote: >>> specifically: >>> >>> https://phab.enlightenment.org/T6740 >>> >>> timed releases, roadmaps (release, project) etc. it'll be far better to do >>> this quickly round-trip wise. >>> >> Do you consider all items in this ticket as the agenda for the meeting or >> only the discussion on timed vs feature release and project roadmap? > did you read the ticket? :) > I did and I have no idea why you would reply to my clear question with another question. :-) I even read This ticket has items on: o How to handle EFL proposals o Project and or release roadmap o Build breakages from commits o IRC channel merge o Regular meetings o Jenkins build status o Changes to beta APIs o Moving away from phab Above you mentioned timed releases for the meeting. Given the ticket covers _way_ more items besides releases and roadmaps I asked for clarification. You asked for a meeting, I asked for the agenda. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
On Wed, 18 Apr 2018 10:32:46 +0200 Stefan Schmidt said: > Hello. > > > On 04/18/2018 09:59 AM, Carsten Haitzler (The Rasterman) wrote: > > specifically: > > > > https://phab.enlightenment.org/T6740 > > > > timed releases, roadmaps (release, project) etc. it'll be far better to do > > this quickly round-trip wise. > > > > Do you consider all items in this ticket as the agenda for the meeting or > only the discussion on timed vs feature release and project roadmap? did you read the ticket? :) > Having a clear agenda for the meeting should help us to stay focused and > maybe even come to some conclusion. > > regards > Stefan Schmidt > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Get an IRC meeting togther?
Hello. On 04/18/2018 09:59 AM, Carsten Haitzler (The Rasterman) wrote: > specifically: > > https://phab.enlightenment.org/T6740 > > timed releases, roadmaps (release, project) etc. it'll be far better to do > this quickly round-trip wise. > Do you consider all items in this ticket as the agenda for the meeting or only the discussion on timed vs feature release and project roadmap? Having a clear agenda for the meeting should help us to stay focused and maybe even come to some conclusion. regards Stefan Schmidt -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Get an IRC meeting togther?
specifically: https://phab.enlightenment.org/T6740 timed releases, roadmaps (release, project) etc. it'll be far better to do this quickly round-trip wise. Vote: https://phab.enlightenment.org/V33 -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elm_dbus_menu: add missing const for Eina_List
On Wed, 18 Apr 2018 02:13:25 + YEONGJONG LEE said:
that change looks correct. it's returning a const which implies don't free it -
it's constant (it isn't - it's actually just the internal list).
> Hello,
>
> I'm sure this is right.
> See https://phab.enlightenment.org/D5953
>
> Sorry, i forgot to revise commit title :(
>
> Regards
> Yeongjong Lee
>
> 원본 이메일
> 보낸 사람: Stefan Schmidt
> 날짜: 18/4/17 오후 3:11 (GMT+09:00)
> 받은 사람: Enlightenment developer list <
> enlightenment-devel@lists.sourceforge.net>, YeongJong Lee <
> yj34@samsung.com>
> 제목: Re: [E-devel] [EGIT] [core/efl] master 01/01: elm_dbus_menu: add
> missing const for Eina_List
>
> Hello.
>
>
> On 04/17/2018 04:10 AM, YeongJong Lee wrote:
> > sanghyeonlee pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=c943c4a2ffd51d9c7a1f4dd95f99721b1cb9148e
> >
> > commit c943c4a2ffd51d9c7a1f4dd95f99721b1cb9148e
> > Author: YeongJong Lee
> > Date: Tue Apr 17 11:08:25 2018 +0900
> >
> > elm_dbus_menu: add missing const for Eina_List
> >
> > Summary:
> > This fixes following warning
> >
> > ../src/lib/eina/eina_list.h:1421:10: warning: assignment discards
> ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
> >
> > Test Plan: make
> >
> > Reviewers: SanghyeonLee
> >
> > Reviewed By: SanghyeonLee
> >
> > Subscribers: cedric
> >
> > Differential Revision: https://phab.enlightenment.org/D5952
> > ---
> > src/lib/elementary/elm_dbus_menu.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/lib/elementary/elm_dbus_menu.c
> b/src/lib/elementary/elm_dbus_menu.c
> > index 0bf096347d..73b8a7bf0b 100644
> > --- a/src/lib/elementary/elm_dbus_menu.c
> > +++ b/src/lib/elementary/elm_dbus_menu.c
> > @@ -333,8 +333,7 @@ _root_layout_build(Elm_DBus_Menu *dbus_menu,
> Eina_List *property_list,
> > {
> > char *property;
> > Eldbus_Message_Iter *layout, *array, *pair, *variant;
> > - Eina_List *l;
> > - const Eina_List *it;
> > + const Eina_List *l, *it;
> > Elm_Object_Item *obj_item;
> >
> > layout = eldbus_message_iter_container_new(iter, 'r', NULL);
> > @@ -422,8 +421,7 @@ _elm_dbus_menu_add(Eo *menu)
> > {
> > Elm_DBus_Menu *dbus_menu;
> > Elm_Object_Item *obj_item;
> > - const Eina_List *it;
> > - Eina_List *l;
> > + const Eina_List *it, *l;
> >
> > ELM_MENU_CHECK(menu) NULL;
> >
> > @@ -457,7 +455,6 @@ _elm_dbus_menu_add(Eo *menu)
> > return dbus_menu;
> >
> > error_hash:
> > - eina_iterator_free(it);
> > eina_hash_free(dbus_menu->elements);
> > error_menu:
> > free(dbus_menu);
> >
>
> You commit message does only mention adding the const qualifier but nothing
> about this iterator free you remove.
>
> Are you sure this is right or has this been committed accidentally?
>
> regards
> Stefan Schmidt
>
>
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 원본 이메일 보낸 사람: Stefan Schmidt
> 날짜: 18/4/17 오후 3:11 (GMT+09:00) 받은 사람:
> Enlightenment developer list < enlightenment-devel@lists.sourceforge.net>,
> YeongJong Lee < yj34@samsung.com> 제목: Re: [E-devel] [EGIT] [core/efl]
> master 01/01: elm_dbus_menu: add missing const for Eina_List
> Hello.
>
>
> On 04/17/2018 04:10 AM, YeongJong Lee wrote:
> > sanghyeonlee pushed a commit to branch master.
> >
> >
> http://git.enlightenment.org/core/efl.git/commit/?id=c943c4a2ffd51d9c7a1f4dd95f99721b1cb9148e
> >
> > commit c943c4a2ffd51d9c7a1f4dd95f99721b1cb9148e
> > Author: YeongJong Lee
> > Date: Tue Apr 17 11:08:25 2018 +0900
> >
> > elm_dbus_menu: add missing const for Eina_List
> >
> > Summary:
> > This fixes following warning
> >
> > ../src/lib/eina/eina_list.h:1421:10: warning: assignment discards
> ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
> >
> > Test Plan: make
> >
> > Reviewers: SanghyeonLee
> >
> > Reviewed By: SanghyeonLee
> >
> > Subscribers: cedric
> >
> > Differential Revision: https://phab.enlightenment.org/D5952
> > ---
> > src/lib/elementary/elm_dbus_menu.c | 7 ++-
> > 1 file changed, 2 insertions(+), 5 deletions(-)
> >
> > diff --git a/src/lib/elementary/elm_dbus_menu.c
> b/src/lib/elementary/elm_dbus_menu.c
> > index 0bf096347d..73b8a7bf0b 100644
> > --- a/src/lib/elementary/elm_dbus_menu.c
> > +++ b/src/lib/elementary/elm_dbus_menu.c
> > @@ -333,8 +333,7 @@ _root_layout_build(Elm_DBus_Menu *dbus_menu,
> Eina_List *property_list,
> > {
> > char *property;
> > Eldbus_Message_Iter *layout, *array, *pair, *variant;
> > - Eina_List *l
Re: [E-devel] [EGIT] [core/efl] master 02/09: efl: use efl_add_ref to create objects which have no parent
On Tue, 17 Apr 2018 19:33:02 -0400 Cedric Bail said:
> On March 29, 2018 10:58 AM, Carsten Haitzler wrote:
> > On Thu, 29 Mar 2018 13:17:43 -0400 Cedric Bail ced...@ddlm.me said:
> > > On March 28, 2018 8:06 PM, Carsten Haitzler ras...@rasterman.com wrote:
> > > > On Wed, 28 Mar 2018 12:37:35 -0400 Cedric Bail ced...@ddlm.me said:
> > > > > On March 27, 2018 10:32 PM, Carsten Haitzler ras...@rasterman.com
> > > > > wrote:
> > > > > > On Tue, 20 Mar 2018 17:57:47 -0700 Cedric BAIL cedric.b...@free.fr
> > > > > > said:
> > > > > Ideally yes, but at least for the _example, it requires to spend some
> > > > > more time to move them to use EFL_MAIN, which should be done in a
> > > > > different patch not related to fixing the usage of efl_add.
> > > >
> > > > some use EFL_MAIN ... otherwise efl_main_loop_get() will work. but
> > > > moving to efl_add_ref() isn't the "right direction" for most of these.
> > >
> > > Yeah, I haven't been a big fan of efl_main_loop_get and did tend to avoid
> > > it. I should use it more often in the future.
> >
> > it'd be good to stop doing that... :) long term at least. the slow and
> > steady steps are to fix our parenting in efl and examples. :) i fixed it
> > for you - or well i fixed everything i saw you changed. it may not be
> > perfect, but it's a step in the right direction imho :) point out if i got
> > something wrong. i didn't do "Extensive" work like you say and convert to
> > EFL_MAIN or within efl modify code to pass parents around many levels down
> > or something.
>
> So I have been working on finishing correcting the lifecycle of eo object by
> making sure that efl_invalidate does happen before any efl_destructor code
> (Currently in master, it is possible to get efl_invalidate to be called after
> the object destructor as it is called inside efl.object.destructor). This
> means that efl_del and efl_parent_{get,set} are a typical wrong piece of code
> in the destructore. The patch 2fb5cc3ad09f6aaf82b5d1131ac5ed22ed848bd4 is
> wrong in a lot of place that I had to give up fixing it due to time
> constraint (basically it assume our use before invalidate was
> efl_add/efl_del, while the closest to our pattern was efl_add_ref with
> efl_unref in the desstructor). I have a branch devs/cedric/lifecycle with all
> the change in it including a revert of your patch. I can't land this patch at
> the moment as the old eo base efl_future lifecycle is a complete wreck with
> this change, so I will focus back on removing efl_future. If you had time in
> the mean time to check your patch and see how to fix it, it would be great.
wait wait. first. some objects. actually a fair few objects need to know their
parents to find their loop provider etc. an they need to do this on "shut down"
to delete stuff etc. from here. so my question will be:
where should an object do this "shut down" in the invalidate or in destructor.
you seem to say that it mys be in invalidate which means invalidate effectifely
is the "meat" of the destructor, just the object keeps itself around with some
minimal content until destructor is called. so what you are doing is ensuring
there is ALWAYS the sequence of invalidate then destroy, right?
so i'm not sure what's wrong with that patch - can you detail it? i simply
moved to having a parent instead of no parent in many cases, and used efl_del
again like it used to be which should clear out the only reference to the
object by unparenting it etc. etc. ...
if you reverted the patch you would have lost all the "correct" parenting so
i'm not sure that that is going to be better at all, unless you kept that and
it's a partial revert really. i haven't looked at your branch yet, but it's
kind of not making a lot of sense in this email right now. i am not sure what
needs fixing where and how from this email at all, so it'd be nice for you to
explain some more...
> Cedric
>
> PS: there are still bug regarding the lifecycle of the focus manager in that
> branch that I haven't had time to figure out yet, will get to it later.
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
- Codito, ergo sum - "I code, therefore I am" --
Carsten Haitzler - ras...@rasterman.com
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: elm_dbus_menu: add missing const for Eina_List
On Wed, 18 Apr 2018 08:53:09 +0200 Stefan Schmidt said: > Hello. > > > On 04/18/2018 04:13 AM, YEONGJONG LEE wrote: > > Hello, > > > > I'm sure this is right. > > See https://phab.enlightenment.org/D5953 > > OK, I can see now what happened. > > You did actually do everything correct. Having two patches for two different > issues you found. Resulting in D5952 and D5953. > > SangHyeon, please do not ask to have such things merged together in one patch. > These have been two different issues (free call and const attribute) and they > should not be lumped together just because they are in the same file. > > We want atomic patches in this project. One issue handled per patch. that would always be best. sometimes it's hard to split apart work especially if you are chasing bug A and find bug B that affects bug A and it'd in the same file and functions and splitting the changes out is kind of hard as you have to undo parts of your fix for A to separate B out etc.. but indeed asking to merge whats is already split out is bad as it's extra work to make a change worse -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
