Re: [E-devel] Developer access suggestion for lauromoura
+1 2019년 9월 5일 (목) 오후 10:22, Christopher Michael 님이 작성: >+1 from me also. Seems to be doing good work on this bindings. > >dh > >On 9/5/19 9:11 AM, Mike Blumenkrantz wrote: > > +1 > > On Thu, Sep 5, 2019 at 7:08 AM Hermet Park [1] > wrote: > > > ++ > > On Thu, Sep 5, 2019 at 7:23 PM Carsten Haitzler [2] > wrote: > > > On Thu, 5 Sep 2019 11:25:21 +0200 Xavi Artigas [3] > > said: > > ++ > > > Hi, > > Lauro Moura has been working on the mono bindings for a long time now. > I think we could speed up development if he had commit rights instead > > of > > having to wait for his partners to push his patches for him. > > What do you think? > Xavi > > ___ > enlightenment-devel mailing list > [4]enlightenment-devel@lists.sourceforge.net > [5]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > - Codito, ergo sum - "I code, therefore I am" -- > Carsten Haitzler - [6]ras...@rasterman.com > > > > ___ > enlightenment-devel mailing list > [7]enlightenment-devel@lists.sourceforge.net > [8]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > -- > Regards, Hermet > > ___ > enlightenment-devel mailing list > [9]enlightenment-devel@lists.sourceforge.net > [10]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > ___ > enlightenment-devel mailing list > [11]enlightenment-devel@lists.sourceforge.net > [12]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > References > >1. mailto:hermetp...@gmail.com >2. mailto:ras...@rasterman.com >3. mailto:xavierarti...@gmail.com >4. mailto:enlightenment-devel@lists.sourceforge.net >5. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >6. mailto:ras...@rasterman.com >7. mailto:enlightenment-devel@lists.sourceforge.net >8. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >9. mailto:enlightenment-devel@lists.sourceforge.net > 10. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > 11. mailto:enlightenment-devel@lists.sourceforge.net > 12. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] evas_canvas_image_cache_flush segfault problem
Took another look at this issue using enlightenment and I was wrong in saying it worked in e22/23. Suppose I didn't play with it long enough. All versions of e are effected. For the record in my tests I disable compositing. Can even cause the crash with e in git. I didn't look at the backtraces of any other info. Assuming it is prob similar wot what moksha is throwing. Screenshot below was creating by mousing over the menu entries for the problematic apps a few times and then closing menu. Reopen menu and start run evry and start bouncy there. Now try to edit bouncy window icon. Segfault. This was e23 but same in all e versions: https://i.imgur.com/F4cOWEV.png The specific steps need to induce the segfault may vary some but seems to always happen. On Wed, Sep 4, 2019 at 11:01 AM Rbt. Y-Lee wrote: > Thanks for taking the time to look over this Hermet. > > Update efl to the latest commit this morning: > > test@test-VirtualBox:~/Code/efl$ git show > commit c5b88ca745b5f457975963914bb2f319705f5c7e (HEAD -> master, > origin/master, origin/HEAD) > Author: Hermet Park > Date: Wed Sep 4 20:01:53 2019 +0900 > > ector: add FIXME for coming issues. > > We have no any test resouce but it seems very weird code... > Leave a comment for future task. > > Not super familiar with using valgrind but anyways the output with a few > different options: > > https://pastebin.com/LP8pYJj7 > > For the below output I unloaded a few modules to avoid noise from them: > > https://pastebin.com/T3z1wvEj > https://pastebin.com/aE2zi8pQ > https://pastebin.com/kWd52E1v > > A lot of output and a few things clearly that needs fixed in moksha but > perhaps in this you or someone else can better understand the issue at hand. > > Meanwhile I am in Hurricane Dorians path (SC US) so hoping for the best > and I will respond to future msgs if and when I have internet and power. > Usually lose that for a day or two during hurricanes. Anyways let me know > if you need more info > > Thanks > > Robert > > > > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] efl eo iface direction - call cost and API design
This mail seems to cover up 2 quite unrelated things: a bug (fix), and the general discussion about efl-interfaces. The bug you have fixed in EFL is pretty much unrelated to eo or the file interface. It was added in f10a3c9ee36cd270045f7e30fd3716ef15e3106d which is not related to the work that was put into the file interface in the last release. I also have to admit here that i cannot fully agree with your reasoning for 5 instead of 1 eo call. efl_file_simple_load is not a eo call. Additionally, file_set key_set and load are executed right after each other, which makes use of the eo_id cache here, which only leaves the function pointer lookup, not the pointer lookup, which cuts off a lot of cost. The unload here is a special case which is happening here in edje itself (prior to your commit, not anymore), not every object does call that. Additionally, normal usage of that API, outside the legacy wrappers and outside edje, will probebly only result in file_set and load. I also tend to agree with you that we need to be carefull with what we are doing via eo calls, and what can be combined, however, the file set API is not a good example to showcase that, as this API most of the time results in a heavy operation performed afterwards, so the cost you pay after calling that API is a lot higher than the cost calling the API itself. Comparing that for example to our writer / reader API in eo, if you often need to know if something is readable now you will all the time call the same API over and over again, just to query a time little boolean flag, which gets set by some foreign entity. For me comparing those two examples, efl.file makes a lot more sense than for example Efl.Io.Reader/Writer. Additionally, there is another cost of eo that we cannot really cut off, like the cost we are paying for moving a object. A little introduction: If you move a layout via efl_gfx_entity_geometry_set you will actaully call: (On the widget object) - canvas_object (geometry_set gets translated to position_set) - widget (position_set) - canvas_object again (position_set) In the widget layer there is another call with geometry_set on the canvas object which calls: - canvas_layout - canvas_group - canvas_object So in this one call we have 6 lookups where we are looking up, the real eo_id, the func-ptr, and the pd. However, the reasoning for eo as a security layer there is a little bit weak, we are in inheritance, we KNOW that the object we are calling on is valid. Additionally, we can calc the pd pointer by adding the diff between the two classes to the next inheritance step, so all the work that is currently done by eo can be basically saved at compile time. The methods for applying that to the efl tree are not there yet, that needs more work, I would also love to serve here numbers, but I had other things to do. I am not aware of any interface where we said goodbye to performance for the sake of clean and nice API. So as a example, the new Grid and List widget have a common interface for doing placement, that saves us a lot of duplicated code. The interfaces are designed in a way that eo funcs are called as few as possible, so the handing over of the items etc. are only involving eo for batching (like give me now 100 items starting *there*), which means, we have 1-3 eo calls per placement of items for "managing" the items, the placement itself then of course does not get around the fact of calling geometry_set, which involves calling eo api. The setup for all this also went quite a few rounds in terms of developing it, and at any time performance was a reason for this, so I am wondering a little bit where 1) and 2) and 3) are coming from. Additionally, I would be interested in 5) I do not see damage right now, yes, you found a bug in a revision, but I guess that would happen with or without eo and with or without the interface work. The tradeoff you are making here is something I have not seen so far, there are interfaces which surely did this, but those are beta, and they are also kind of out of the view for now, as (speaking for me here) i am focusing on the new widgets here, and I have not seen that much work going into something outside of that (beside Xavi's work on improving docs just *everywhere*) All I can say about that: there is the efl: api board, where there are tickets for each class/interface, so we can at least try to keep an overview of the insane amount of classes and interfaces we have, the items there are currently something to look into, the Efl.Io things are *not* in there. And I cannot locate any class that is in the stabilized column that has problems with the purity over performance thing brought up here :) Greetings, bu5hm4n On 9/5/19 2:45 PM, Carsten Haitzler (The Rasterman) wrote: > I'm noticing a bit of a trend of what I might call "endless fiddling towards > perceived perfection". This fiddling is adding cost/overhead,
Re: [E-devel] Discussions here.
On 05/09/2019 14:41, Carsten Haitzler (The Rasterman) wrote: > On Thu, 5 Sep 2019 20:28:50 +0900 Hermet Park said: > >> I think it's just preference problem. >> >> Anyhow, I prefer e-devel discussion >> >> But both are fine to me because both do functions enough. > > phab can't thread so it becomes impossible to deal with really :( knowing what > i have and have not read yet in some discussion thread just doesn't work as > the > web ui doesn't tell me - i just have a huge list to scroll. :( > That's a major part of it, but for me it's also the noise. I don't need to look at every patch that goes in or every bug report. I do however want to go through every high-level discussion. -- Tom ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Discussions here.
On Thu, 5 Sep 2019 20:28:50 +0900 Hermet Park said: > I think it's just preference problem. > > Anyhow, I prefer e-devel discussion > > But both are fine to me because both do functions enough. phab can't thread so it becomes impossible to deal with really :( knowing what i have and have not read yet in some discussion thread just doesn't work as the web ui doesn't tell me - i just have a huge list to scroll. :( > On Thu, Sep 5, 2019 at 6:05 PM Tom Hacohen wrote: > > > Hey, > > > > That's something I've been complaining about both on IRC and recently on > > phab too, so glad to see you take action about it! > > > > It's really hard to follow what's going on in the EFL world if you just > > want to follow the high-level design discussions rather than every typo > > fix patch / bug. I don't have enough time to follow everything that's > > going on on Phab, which means I miss the high-level discussions (if they > > even happen), which is a pity.I'm sure I'm not the only one. > > > > -- > > Tom > > > > On 03/09/2019 18:31, Carsten Haitzler (The Rasterman) wrote: > > > I've noticed over time - the last few years a lot of discussion has > > broken down > > > for various reasons. It's being moved to phab as tickets or review where > > it > > > SHOULD be a discussion here on the mailing list. > > > > > > Years ago we agreed on how to work. Phab would be for review and bug > > tickets. > > > Mailing list would be for discussion of things like design or broader > > issues, > > > and major direction/design changes. > > > > > > It's time to bring things back here. Phab is not the right forum for > > > discussions. Tickets are not replacements for mailing list threads. > > > > > > So can we do what we agreed to do years ago - use our tools > > appropriately? Many > > > of you will remember these discussions on how to work together, so you > > know > > > what I'm talking about. Can we do that? :) > > > > > > > > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Regards, Hermet > > ___ > 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Developer access suggestion for lauromoura
+1 from me also. Seems to be doing good work on this bindings. dh On 9/5/19 9:11 AM, Mike Blumenkrantz wrote: +1 On Thu, Sep 5, 2019 at 7:08 AM Hermet Park [1] wrote: ++ On Thu, Sep 5, 2019 at 7:23 PM Carsten Haitzler [2] wrote: On Thu, 5 Sep 2019 11:25:21 +0200 Xavi Artigas [3] said: ++ Hi, Lauro Moura has been working on the mono bindings for a long time now. I think we could speed up development if he had commit rights instead of having to wait for his partners to push his patches for him. What do you think? Xavi ___ enlightenment-devel mailing list [4]enlightenment-devel@lists.sourceforge.net [5]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - [6]ras...@rasterman.com ___ enlightenment-devel mailing list [7]enlightenment-devel@lists.sourceforge.net [8]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Regards, Hermet ___ enlightenment-devel mailing list [9]enlightenment-devel@lists.sourceforge.net [10]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list [11]enlightenment-devel@lists.sourceforge.net [12]https://lists.sourceforge.net/lists/listinfo/enlightenment-devel References 1. mailto:hermetp...@gmail.com 2. mailto:ras...@rasterman.com 3. mailto:xavierarti...@gmail.com 4. mailto:enlightenment-devel@lists.sourceforge.net 5. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 6. mailto:ras...@rasterman.com 7. mailto:enlightenment-devel@lists.sourceforge.net 8. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 9. mailto:enlightenment-devel@lists.sourceforge.net 10. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 11. mailto:enlightenment-devel@lists.sourceforge.net 12. https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Developer access suggestion for lauromoura
+1 On Thu, Sep 5, 2019 at 7:08 AM Hermet Park wrote: > ++ > > On Thu, Sep 5, 2019 at 7:23 PM Carsten Haitzler > wrote: > > > On Thu, 5 Sep 2019 11:25:21 +0200 Xavi Artigas > > said: > > > > ++ > > > > > Hi, > > > > > > Lauro Moura has been working on the mono bindings for a long time now. > > > I think we could speed up development if he had commit rights instead > of > > > having to wait for his partners to push his patches for him. > > > > > > What do you think? > > > Xavi > > > > > > ___ > > > 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 > > > > > > > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > -- > Regards, Hermet > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] efl eo iface direction - call cost and API design
I'm noticing a bit of a trend of what I might call "endless fiddling towards perceived perfection". This fiddling is adding cost/overhead, making things slower and adding bugs. I do not intend to point fingers here so do NOT take this as "this person is at fault" or personally as the issue is more one of a trend and almost everyone seems to be on the bandwagon. For example, the changes from file_set that take a file + group now set them separately as 2 keys. Like now edje_file_set() does: efl_file_unload() <- this breaks things btw and adds a bug efl_file_simple_load() efl_file_set() efl_file_key_set() efl_file_load() This has gone from 1 eo call that it was a while ago to a file_set to 5 of them now as it has to get the values via eo API etc. and added breaks in behavior. That's 5x the EO call cost added there to the same functionality. I probably have missed some more calls I'd find if I dig enough. Eo API is expensive. It adds a safety layer and call abstraction that isn't free. There has been a lot of work to try and shave down its cost and it's unlikely to get staggeringly faster any time soon, if ever. Certainly not unless major effort is put to profiling it and making carefully crafted memory layouts and specific architecture optimizations. Everyone should be designing APIs to go through the EO call API as *LITTLE AS POSSIBLE*. That means things like file_set should not have split up file and key. More objects are also costly. Events/callbacks are not cheap either. This means probably rolling more into a single API call, single object or single event and doing these calls less and always considering design from THAT point of view. This may not be perfect but it's practical and performant. There is a limit to how much you can merge of course, but the above split of file and key is a fairly pointless split (key can always just be NULL or some bindings/langs can tag it as an optional argument and C can just use NULL to indicate it isn't there). Also consider how often the API is called. The file_set()s are called a lot during startup/setup of a window/app/object and sub objects. It's not good to go add costs to things that have lots of calls already going on. I brought up the whole efl.io interface design a few weeks ago too (on my todo list to go redo) with it also going in and out a lot and being costly. Can we please take a few big steps back and: 1. Stop the fiddling around the edges hunting for perfect design but forgetting performance. It's busy work too that endlessly delays a stable EO API. If it doesn't make high impact better design, then perhaps don't do it? 2. When something is done, stop thinking about perfect API design and consider the costs. That is life and design has to work around it. There is already a mountain of this peppered throughout eo API and it's not good. 3. If you are going to try a whole new design then try it in isolation as an experiment that isn't beneath existing API and so it won't break things or have major performance impacts. 4. Can we bring these kinds of design change discussions to the mailing list? Like splitting up file and key IMHO is a fairly big change in design that has impacts all over like above and changes a fairly large API design premise that has been with EFL for well over a decade. 5. Start undoing some of the damage done. 6. Looking for ways to improve EO API not in terms of purity but in terms of performance? :) -- - Codito, ergo sum - "I code, therefore I am" -- Carsten Haitzler - ras...@rasterman.com ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Discussions here.
I think it's just preference problem. Anyhow, I prefer e-devel discussion But both are fine to me because both do functions enough. On Thu, Sep 5, 2019 at 6:05 PM Tom Hacohen wrote: > Hey, > > That's something I've been complaining about both on IRC and recently on > phab too, so glad to see you take action about it! > > It's really hard to follow what's going on in the EFL world if you just > want to follow the high-level design discussions rather than every typo > fix patch / bug. I don't have enough time to follow everything that's > going on on Phab, which means I miss the high-level discussions (if they > even happen), which is a pity.I'm sure I'm not the only one. > > -- > Tom > > On 03/09/2019 18:31, Carsten Haitzler (The Rasterman) wrote: > > I've noticed over time - the last few years a lot of discussion has > broken down > > for various reasons. It's being moved to phab as tickets or review where > it > > SHOULD be a discussion here on the mailing list. > > > > Years ago we agreed on how to work. Phab would be for review and bug > tickets. > > Mailing list would be for discussion of things like design or broader > issues, > > and major direction/design changes. > > > > It's time to bring things back here. Phab is not the right forum for > > discussions. Tickets are not replacements for mailing list threads. > > > > So can we do what we agreed to do years ago - use our tools > appropriately? Many > > of you will remember these discussions on how to work together, so you > know > > what I'm talking about. Can we do that? :) > > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Developer access suggestion for lauromoura
++ On Thu, Sep 5, 2019 at 7:23 PM Carsten Haitzler wrote: > On Thu, 5 Sep 2019 11:25:21 +0200 Xavi Artigas > said: > > ++ > > > Hi, > > > > Lauro Moura has been working on the mono bindings for a long time now. > > I think we could speed up development if he had commit rights instead of > > having to wait for his partners to push his patches for him. > > > > What do you think? > > Xavi > > > > ___ > > 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 > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Developer access suggestion for lauromoura
On Thu, 5 Sep 2019 11:25:21 +0200 Xavi Artigas said: ++ > Hi, > > Lauro Moura has been working on the mono bindings for a long time now. > I think we could speed up development if he had commit rights instead of > having to wait for his partners to push his patches for him. > > What do you think? > Xavi > > ___ > 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Developer access suggestion for lauromoura
Hi, Lauro Moura has been working on the mono bindings for a long time now. I think we could speed up development if he had commit rights instead of having to wait for his partners to push his patches for him. What do you think? Xavi ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Discussions here.
Hey, That's something I've been complaining about both on IRC and recently on phab too, so glad to see you take action about it! It's really hard to follow what's going on in the EFL world if you just want to follow the high-level design discussions rather than every typo fix patch / bug. I don't have enough time to follow everything that's going on on Phab, which means I miss the high-level discussions (if they even happen), which is a pity.I'm sure I'm not the only one. -- Tom On 03/09/2019 18:31, Carsten Haitzler (The Rasterman) wrote: > I've noticed over time - the last few years a lot of discussion has broken > down > for various reasons. It's being moved to phab as tickets or review where it > SHOULD be a discussion here on the mailing list. > > Years ago we agreed on how to work. Phab would be for review and bug tickets. > Mailing list would be for discussion of things like design or broader issues, > and major direction/design changes. > > It's time to bring things back here. Phab is not the right forum for > discussions. Tickets are not replacements for mailing list threads. > > So can we do what we agreed to do years ago - use our tools appropriately? > Many > of you will remember these discussions on how to work together, so you know > what I'm talking about. Can we do that? :) > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Discussions here.
Hey, That's something I've been complaining about both on IRC and recently on phab too, so glad to see you take action about it! It's really hard to follow what's going on in the EFL world if you just want to follow the high-level design discussions rather than every typo fix patch / bug. I don't have enough time to follow everything that's going on on Phab, which means I miss the high-level discussions (if they even happen), which is a pity.I'm sure I'm not the only one. -- Tom On 03/09/2019 18:31, Carsten Haitzler (The Rasterman) wrote: > I've noticed over time - the last few years a lot of discussion has broken > down > for various reasons. It's being moved to phab as tickets or review where it > SHOULD be a discussion here on the mailing list. > > Years ago we agreed on how to work. Phab would be for review and bug tickets. > Mailing list would be for discussion of things like design or broader issues, > and major direction/design changes. > > It's time to bring things back here. Phab is not the right forum for > discussions. Tickets are not replacements for mailing list threads. > > So can we do what we agreed to do years ago - use our tools appropriately? > Many > of you will remember these discussions on how to work together, so you know > what I'm talking about. Can we do that? :) > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
