Re: Infrastructure | Create evolution-etesync repo under GNOME (#414)

[Tom Hacohen]

Tom Hacohen commented:


Thanks!

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/414#note_923415
You're receiving this email because of your account on gitlab.gnome.org.


___
gnome-infrastructure mailing list
gnome-infrastructure@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-infrastructure

Re: Infrastructure | Create evolution-etesync repo under GNOME (#414)

[Tom Hacohen]

Tom Hacohen commented:


Great, so what's needed to move things forward?

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/414#note_909080
You're receiving this email because of your account on gitlab.gnome.org.


___
gnome-infrastructure mailing list
gnome-infrastructure@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-infrastructure

Re: Infrastructure | Create evolution-etesync repo under GNOME (#414)

[Tom Hacohen]

Tom Hacohen commented:


I'm an outsider, so feel free to ignore me, but here are my thoughts:
Should we maybe put it under the same umbrella as the other EDS modules until 
#333 is decided and comes into effect, and at that point, move this module 
along with the others that will be moved?

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/414#note_904694
You're receiving this email because of your account on gitlab.gnome.org.


___
gnome-infrastructure mailing list
gnome-infrastructure@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-infrastructure

Re: Infrastructure | Create evolution-etesync repo under GNOME (#414)

[Tom Hacohen]

Tom Hacohen commented:


CC @nourmat

-- 
Reply to this email directly or view it on GitLab: 
https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/414#note_903731
You're receiving this email because of your account on gitlab.gnome.org.


___
gnome-infrastructure mailing list
gnome-infrastructure@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-infrastructure

Re: [E-devel] Time for efl-one

[Tom Hacohen]

Hey,

On 28/05/2020 15:17, Marcel Hollerbach wrote:
> 
> Yeah, something like that was planned in the future, or building small
> stubs without code that are just dragging in efl-one.so This way we do
> not have to worry about platforms with problems about symlinks etc.
> The problem is that the parts that are outside efl-one.so are still
> linking to the smaller .so's and not to efl-one.so as that is a little
> bit harder to realize,
> and I first want to ensure that we *really* have a working efl-one.so
> which totally works before investing more time into that.

That actually makes so much more sense than my suggestion. :facepalm:

> 
> The plan for getting everything on efl-one.so looks a little different
> to me:
> - Maybe move ecore_wayland and ecore_drm to a deprecated folder, that is
> not handled as normal efl subproject anymore
> - Move elua to lua bindings and or build it from there
> - Find out what to do about ecore_avahi
> 
> After that our normal code and build structure is in a state where
> everything natively links to efl-one.so simply by calling subdir(...) in
> another directory. We then can also automatically generate the
> "declare_dependency" and "library" calls and shrink down the lib
> meson.build files even more, which should simplify everything overall
> quite a bit.
> 
> But thats for the future, first lets find out how this works out :)

Sure, just wanted to share my thoughts in case it would be too late
later on, but it looks like you are already on it. :)

> efl.pc is sadly not beta anymore, shipped, and used.
> 
> I basically just really want to ensure that everyone understands that
> this is not yet another subproject within efl, but the overall library
> including a lot but not everything. And in the end, its just a name ... :)
> 

Makes sense. :)

Anyhow, again, great job!

--
Tom


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

Re: [E-devel] Time for efl-one

[Tom Hacohen]

On 27/05/2020 12:34, Marcel Hollerbach wrote:
> Hi,
> 
> after quite a big amount of work we have successfully landed this
> morning a update to our build system which enables to build efl as a
> single big .so instead of multiple seperated .so's. The layout is that
> every single .so is merged into efl-one.so except:
> - eolian: no normal app would benefit from it, and it would make our
> build *a lot* more complex
> - ecore_avahi: there is no real user for this within efl, in general i
> dont think anyone is going to benefit from it
> - efl_canvas_wl: This is also not beneficial to a standard efl application
> - elua: This is only for bindings.
> - ecore_drm / wayland : These are deprecated libs, not to confuse with
> ecore_wl2 / ecore_drm2, which is included in efl-one
> - exactness: Not useful for a normal efl app.
> 
> To build efl-one you need to pass: "-Defl-one=true" to meson. After this
> is done, additionally to all the smaller libs, efl-one.so will be build.
> The modules of ecore / evas etc. and all the binaries will link to
> efl-one.so not to the smaller libraries. However, for compatibility
> reasons, and complexity reasons, the small .so's are still build and
> installed.

Great job!

Maybe instead of building small .so's we can just symlink them all to
the efl-one.so? Or would that cause symbol duplications if multiple ones
are used?

If it works though we can just use the efl.so name and not have to call
it efl-one.so.

> 
> If you have an app that you want to test out with efl-one: There is now
> a efl-one.pc file installed, which can be used to link to the correct
> libraries, no other efl dependency is then required.

Why not just efl.pc? Did we ever ship efl.pc/was it ever used? I think
all of the API there was beta anyway.

> 
> From some early profiling: this saves ~1MB of memory when running a efl
> app, i have so far not tested out what impact it has on runtime
> performance or first frame numbers.
> 

Super cool!

--
Tom


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

Bug#955444: python-etesync: use the scrypt dependency instead of pyscrypt, or update to 0.11.1 which requires neither

[Tom Hacohen]

Package: python-etesync
Version: 0.9.2-1

Hi,

I'm the maintainer of the upstream package. While the pip dependency was
listed as pyscrypt, we've always supported both pyscrypt and scrypt,
with the latter being the recommended choice because it's much more
efficient (and still maintained). The former was the default because of
compatibility.

Additionally, if you update to version 0.11.1 (latest), you can even
remove both deps, because it now also supports the scrypt implementation
that's shipped in Python 3.6 and later.

Glad to see it in Debian, and thanks a lot for your great work!

--
Tom

Re: [E-devel] Memory optimizing EO

[Tom Hacohen]

Hey,

As discussed on IRC: all look like promising ideas, just please make
sure to benchmark both speed and memory usage to make sure there are no
regressions.

The eo benchmark suite should already be fairly complete for speed, but
there are no benchmarks for memory usage if memory serves. I'd also have
a look to make sure the tests still work as expected given that they've
only been touched twice since I last worked on Eo in 2016.

Bottom line: looks promising, but please test, test and test. Eo is
*the* hot-path of the EFL, even the smallest changes can have severe
impacts.

--
Tom

On 18/02/2020 16:45, Marcel Hollerbach wrote:
> Hi,
> 
> here a little draft of what i will work on beginning on the 10th of
> march. So until there, its time for discussion.
> 
> == Introduction ==
> Eo is a OOP framework implementation. Classes are basically
> implementations of a set of interfaces / parent class / mixins. Each
> Interface / parent class / mixin, consits of a set of functions.
> The API a Class provides is called the absolut set of functions of a class
> Each element in the absolut set of functions has to have a
> implementation. Which has to be stored somewhere, this piece of code and
> structure is called vtable. Every entry in the vtable consits of the
> implementation of a API, and the source Class. (Which is needed for
> privat data calculation, which is another topic)
> 
> Right now, each function has a ID (fid), this id is globally unique, and
> just incremented for each and every function that gets registered to EO.
> Each vtable of a class has the space to store *all* functions that have
> been registered to the current point.
> Right now this happens in a way where the function ID of each function
> is split into a upper part and a lower part (based on the bit
> representation), this then results in the dich-chain1 ID (dc1) and
> dich-chain2 ID (dc2) which are used to get to the correct slot (pseudo
> code like: vtable->dichchain1[dc1]->dichchain2[dc2]). If a class needs
> to store the function X, then dich-chain1 at space dc1 gets a allocated
> dichchain2, which consists of 0's expect in the slot dc2, there we store
> the implementation and the source.
> 
> == The problem ==
> The problem with this approach is that we waste quite a lot of memory,
> esp. for widgets that do not implement a lot of API which have a close
> fid, leading to the fact that we allocate a lot of dich chain2s where
> only a few slots are really used. If you go and messure how many slots
> we allocate and how many we use we are having a mean value of round
> about 0.36, which is quite bad IMO. In total, we have 35296 slots
> allocated, and we use 16807. (This is already honoring the eo
> optimizations we have, the referenced slots are NOT added to this)
> 
> == The Idea number 1 ==
> What we can do to improve this is: we change the heuristic how we
> allocate fids. We could increment for each class/interface/mixin one dc1
> counter, and for each function in this class/interface/mixin we
> increment a class/interface/mixin privat counter, which will be the dc2.
> We then combine them together to the fid via something like
> dc1*1+dc2. When a eo call then happens, we simply decompose the fid
> like we do it now, and call the two dich chains, like we do it now.
> What this changes in the memory layout is that we fully use each and
> every dichchain2 that we allocate.
> 
> The downside of that method is that we get a longer dichchain1 array,
> right now with elementary_test we are having 32 pointer long dichchain1
> at max, meaning we are allocating in total 2KB over all classes we have.
> 
> With this new idea the dichchain1 will be 190 elements long meaning 70KB
> over all classes we have.
> However, due to the savings in the dichchain2's we are saving round
> about 144KB of allocated data, (1 slot is 8byte). Which means we are
> still having a safe of round about 74KB.
> 
> This is something which I would implement, additional min / max
> checkings or COW on the dichchain1 are probably even saving more.
> 
> == The Idea number 2 ==
> After Idea 1 is implemented, we could work on this.
> Right now we are allocating one dc1 slot *per* class we have. Right now
> we have 26 mixins 90 regulars 13 abstracts and 61 Interfaces (Summing up
> to 190). Which results in the length of the dc1. To improve the
> situation we could go and say that each dc1 ID of a regular class is the
> max of all functions including those of the parent class + 1. That
> means, that fid's are not globally unique anymore, but they are still
> unique within the type they are defined.
> The more interesting thing is, that all regular APIs are now in the same
> dc1 slot, which means, it is enough to allocate the size of the dc1 as
> the size of the sum of iterfaces and mixins, ending up with something
> lower than 15KB per class. Bringing us to saving 130KB of allocated data
> (compared to the state that we have right now).
> 
> Another "downside" of that 

Re: [E-devel] EO compositing "leaking" interfaces

[Tom Hacohen]

That's part of the problem I described in
https://phab.enlightenment.org/T8184 and specifically mentioned this. Eo
is doing nothing wrong, it's working as designed, it's the new
restrictions that were added only to Eolian that are wrong and made
things inconsistent.

Eo doesn't even have a concept of interfaces internally so doing what
you are suggesting will involve some code (specifically saving the
interfaces on the classes and using them). Eo also has the debug binary,
so it can easily be added for eo_debug, just someone needs to do it.

I still maintain however, that the correct thing to do is to unbreak
eolian and revert compositing to how it was..

--
Tom

On 24/10/2019 01:48, Lauro Moura wrote:
> Talking today about some examples using the new API we came up with the
> following situation:
> 
> ```
> Eo *_screen = efl_add(EFL_UI_TEXT_CLASS, ...);
> ...
> Efl_Text_Cursor_Cursor *cursor = efl_text_cursor_get(_screen,
> EFL_TEXT_CURSOR_GET_TYPE_MAIN);
> ```
> 
> The call seems to succeed in C but it is a compilation error in C#, as
> `Efl.Text_Cursor` is not in the inheritance/interface tree of `Efl.Ui.Text`.
> 
> What seems to be happening is:
> 
> * `Efl.Ui.Text` composites with `Efl.Text_Interactive` and `Efl.Text_Markup`
> * `Efl.Ui.Text` internally uses `Efl.Ui.Internal.Text.Interactive` as a
> composite
> * `Efl.Ui.Internal.Text.Interactive` implements `Efl.Text_Interactive`.
> * This satisfies `composite_attach` requirement and will forward the
> `efl_text_interactive` calls to the composite object.
> * `Efl.Ui.Internal.Text.Interactive` *also extends* `Efl.Text_Cursor`
> through `Efl.Canvas.Text`
> 
> Given this, C code seems them to be able to call `Efl.Text_Cursor` methods
> on the `Efl.Ui.Text` instance through its composite, even though
> `Efl.Ui.Text` has no idea `Efl.Text_Cursor` exists.
> 
> This may work in C (but should it?) as we just pass `Eo*` around and do the
> actual checks at runtime, but for strongly typed languages like C# this
> means the generator has no way to know text cursor methods would be
> available through composition and trying a similar code would lead to
> compilation errors.
> 
> Shouldn't Eo somehow (debug build if too expensive?) intercept these calls
> and emit a warning to avoid such usage?
> 
> (For this particular case, a fix could be making `Efl.Ui.Text` declare
> `Efl.Text_Cursor` as a composite, right?)
> 


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

Re: [E-devel] Eolian property setters with return values

[Tom Hacohen]

On 21/10/2019 18:54, Xavi Artigas wrote:
>>
>> Maybe in general we need a way to mark a return/parameter as an error
>> indicator? It's just a half-baked thought, though maybe worth exploring.
>>
> 
> There's already a couple of ideas on Phab in this direction: Add custom
> tags to Eolian ( https://phab.enlightenment.org/T8294 ) or use Eina.Error
> instead of bool when the setter intends to actually return an error.
> To avoid breaking API in the second case, we could use a "lightweight eina
> error" which is actually a boolean (as Marcel suggests).
> I just thought that if we could agree that setters returning bools always
> mean "error", we could avoid the extra complexity.

Sure, though just a convention is not enough. You need to have them
properly marked so it can be enforced by Eolian and that people who are
writing (and reading!) these interfaces know this what it means.

--
Tom

> 
> Xavi
> 
> 
>>
>> --
>> Tom
>>
>> On 21/10/2019 17:49, Xavi Artigas wrote:
>>> Hi people,
>>>
>>> We are encountering a problem when matching EO properties to C#
>> properties,
>>> since the C# ones cannot have a return value.
>>>
>>> We mostly use return values in EO property setters to indicate error
>>> conditions and this is pretty easily matched to C# by throwing an
>>> exception. We just need to know WHEN a returned bool from a setter really
>>> means ERROR and when it is not.
>>> Currently, all property setters in our tree returning a bool use it to
>>> indicate an error, so it is just a matter of we all agreeing that in the
>>> future this will always be the case (and documenting it).
>>> If we agree on this, then the C# bindings can start throwing exceptions
>> on
>>> setters returning FALSE (there's a patch ready, but I cannot access it
>>> right now).
>>>
>>> If nobody has anything against it, I'll land this patch in a week
>> (October
>>> 28th).
>>>
>>> Thanks!
>>> Xavi
>>>
>>> ___
>>> 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
>>
> 
> ___
> 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] Eolian property setters with return values

[Tom Hacohen]

On 21/10/2019 18:51, Marcel Hollerbach wrote:
> On 10/21/19 5:37 PM, Tom Hacohen wrote:
>> I agree it's most of them, though it's not all of them. IIRC there are
>> some that indicate "nothing happened", at least in textblock. It
>> shouldn't be too hard to fix these though.
>>
>> Maybe in general we need a way to mark a return/parameter as an error
>> indicator? It's just a half-baked thought, though maybe worth exploring.
> 
> Maybe some internal "error_flag" type from eolian, which can be
> translated to a Exception in the languages supporting them, or to a
> simple Eina_Bool in case of C ?

Yeah, that's what I had in mind. Not necessarily Eina_Bool, it could be
an int too, or probably whatever?


error_return bool;
or
return bool @error;

Not sure to be honest, needs thinking, but just generally what I had in
mind.



> It can only be returned (so exceptions do work). This would also not
> mean a API/ABI break to C.
Yup, defo.

> 
>>
>> -- 
>> Tom
>>
>> On 21/10/2019 17:49, Xavi Artigas wrote:
>>> Hi people,
>>>
>>> We are encountering a problem when matching EO properties to C#
>>> properties,
>>> since the C# ones cannot have a return value.
>>>
>>> We mostly use return values in EO property setters to indicate error
>>> conditions and this is pretty easily matched to C# by throwing an
>>> exception. We just need to know WHEN a returned bool from a setter
>>> really
>>> means ERROR and when it is not.
>>> Currently, all property setters in our tree returning a bool use it to
>>> indicate an error, so it is just a matter of we all agreeing that in the
>>> future this will always be the case (and documenting it).
>>> If we agree on this, then the C# bindings can start throwing
>>> exceptions on
>>> setters returning FALSE (there's a patch ready, but I cannot access it
>>> right now).
>>>
>>> If nobody has anything against it, I'll land this patch in a week
>>> (October
>>> 28th).
>>>
>>> Thanks!
>>> Xavi
>>>
>>> ___
>>> 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
>>
> 
> 
> ___
> 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] Eolian property setters with return values

[Tom Hacohen]

I agree it's most of them, though it's not all of them. IIRC there are
some that indicate "nothing happened", at least in textblock. It
shouldn't be too hard to fix these though.

Maybe in general we need a way to mark a return/parameter as an error
indicator? It's just a half-baked thought, though maybe worth exploring.

--
Tom

On 21/10/2019 17:49, Xavi Artigas wrote:
> Hi people,
> 
> We are encountering a problem when matching EO properties to C# properties,
> since the C# ones cannot have a return value.
> 
> We mostly use return values in EO property setters to indicate error
> conditions and this is pretty easily matched to C# by throwing an
> exception. We just need to know WHEN a returned bool from a setter really
> means ERROR and when it is not.
> Currently, all property setters in our tree returning a bool use it to
> indicate an error, so it is just a matter of we all agreeing that in the
> future this will always be the case (and documenting it).
> If we agree on this, then the C# bindings can start throwing exceptions on
> setters returning FALSE (there's a patch ready, but I cannot access it
> right now).
> 
> If nobody has anything against it, I'll land this patch in a week (October
> 28th).
> 
> Thanks!
> Xavi
> 
> ___
> 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] RFC: Text interface + advice regarding interface splitting

[Tom Hacohen]

n, why having a struct here, same as above applies to this.
>>
>> Same answer as before. :)
> 
> see above ... :P
> 

Right back at ya.

>>
>>> - efl2_text_raw_editable:
>>>  - Where does this object belong ? We normally only have objects in
>>> efl.canvas / ui / layout. But not in efl. itself.
>>
>> Happy to rename it, though dunno what to. It's somewhere between canvas
>> and ui. It's above canvas as it handles input and deals with X, but
>> below UI because it doesn't have a theme.
> 
> Sounds like a thing for efl.layout ?

It's not a layout though, or does efl.layout also include objects that
don't layout things.

> 
>>
>>>  - Is it doing undo/redo or only emitting the events ?
>>
>> At the moment just events, but Ali is going to fix this.
>>
>>> - efl2_ui_text:
>>>  - Why are here cnp related events ? Isnt that just a normal
>>> insertion / copy operation ? The cut and copy operation could be on a
>>> object that handles cnp, the paste operation as well, paired with a
>>> changed,user event?
>>
>> Fair comment, need to re-evaluate that.
>>
>>>
>>> General notes:
>>> - you used a lot of ptr(...), you cannot use them when you remove @beta
>>> from the file. These files should not use ptr, nor void_ptr.
>>
>> I know. :(
>> I created my branch before there was an alternative (very recently), and
>> haven't updated anything yet.
>>
>>> - You have a few places where you have explicitly x,y,w,h (x,y) in your
>>> API, can you replace them with rect (position) handles from eina, that
>>> would make it more aligned with the rest of efl.
>>>
>>
>> Could you please provide an example?
> 
> I think you replaced all of them in the branch, cannot find them right now.

Ahh, yes, I since understood what you were talking about and fixed it.
Thanks.

> 
> Something else i have spotted while taking a second look:
> - you can remove the ptr(...) stuff in iterator as structs in
> iterators are passed by reference implicitly.

Thanks for the comment, I'll fix it!
> 
> Greetings,
>    bu5hm4n
> 
> 
>>
>> Thanks!
>>
>> -- 
>> Tom
>>
>>> Greetings,
>>>     bu5hm4n
>>>
>>> On 9/19/19 4:15 PM, Tom Hacohen wrote:
>>>> Hey,
>>>>
>>>> As most of you (at least the IRC lurkers) know, I've been recently
>>>> working on the text interfaces. Trying to clean them up and stabilise
>>>> them.
>>>> The discussion and work has been covered on phab at:
>>>> https://phab.enlightenment.org/T8151
>>>>
>>>> And the new (suggested) interfaces are all the files starting with
>>>> "efl2_" in my branch:
>>>> https://git.enlightenment.org/core/efl.git/tree/?h=devs/tasn/ifaces
>>>>
>>>> I'd love to get your feedback and let me know if there's anything I've
>>>> missed. All feedback is welcomed, including bike shedding.
>>>> Some interfaces still have massive FIXMEs at the top, so obviously read
>>>> those before replying to avoid repeating what we already know.
>>>>
>>>>
>>>> As for the advice I mentioned in the title: due to composite object
>>>> regressions as described in T8184, I'm forced to break up the classes
>>>> into interfaces. As discussed at length in the ticket, these interfaces
>>>> would have to be very specific to the classes and not really reusable
>>>> ("cursor_new" is quite specific, obviously).
>>>>
>>>> I can either just do as I said in the ticket, and for every class do a
>>>> big interface, so Efl.Canvas.Text -> Efl.Canvas.Text +
>>>> Efl.Canvas.Text_Interface. This is one way. It's obviously very ugly.
>>>> The other way is to split to a lot of smaller, probably 1/2 property
>>>> interfaces, which is also ugly and quite inefficient
>>>> (classes/interfaces
>>>> are not free).
>>>>
>>>> I'd love to get your input, to what interfaces would you split up these
>>>> two classes:
>>>> 1.
>>>> https://git.enlightenment.org/core/efl.git/tree/src/lib/evas/canvas/efl2_canvas_text.eo?h=devs/tasn/ifaces
>>>>
>>>>
>>>> 2.
>>>> https://git.enlightenment.org/core/efl.git/tree/src/lib/elementary/efl2_text_raw_editable.eo?h=devs/tasn/ifaces
>>>>
>>>>
>>>>
>>>>
>>>> Thanks a lot for your help and feedback!
>>>>
>>>> -- 
>>>> Tom
>>>>
>>>>
>>>> ___
>>>> 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


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

[EGIT] [editors/vim-configs] master 01/01: Update according to eolian changes.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=d3d028da20afd7118eb0e5c99446db6b10a158c1

commit d3d028da20afd7118eb0e5c99446db6b10a158c1
Author: Tom Hacohen 
Date:   Tue Oct 1 17:40:12 2019 +0300

Update according to eolian changes.
---
 syntax/eo.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index c4f8eb3..619df88 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -31,7 +31,7 @@ syn keywordeoStatements return
 
 " syn match  className   "\(\w\+\.\)\+\w\+"
 
-syn match  attributes  
"@\(nonull\|inout\|out\|in\|property\|static\|free\|constructor\|virtual_pure\|auto\|empty\|extern\|beta\|protected\|const\|optional\|nullable\|warn_unused\|owned\|private\|hot\)"
+syn match  attributes  
"@\(nonull\|inout\|out\|in\|property\|static\|free\|constructor\|virtual_pure\|auto\|empty\|extern\|beta\|protected\|const\|optional\|nullable\|warn_unused\|move\|by_ref\|private\|hot\)"
 
 syn match eoLabelMatch   "\w\+:" contains=eoClassBodyLabels
 syn match eoBlockOpener  "\w\+\s*{" 
contains=eoClassBodyBlockOpener,eoInnerBlockOpener

-- 

Re: [E-devel] RFC: Text interface + advice regarding interface splitting

[Tom Hacohen]

Hey,

Sorry for the delay, and thanks for your feedback! Comments are inline.

Just one thing though, while you provided a lot of very valuable
comments, you haven't solved my issue with splitting interfaces, which
is the main thing blocking my work ("the advice"). Any comments on that?



On 27/09/2019 15:22, Marcel Hollerbach wrote:
> Hi,
> 
> after a long read:

Sorry, there's a lot there. :)

> - efl2_text_attribute_factory:
>     - Why having a struct here as handle, i fear that bindings will have
> a very hard time with this, where you actually pass in a struct to the
> remove method, and this one is dead after it.

What's your suggested alternative? Anyhow, why would bindings have a
hard time? Structs have associated free functions and ref/unref, no? I'm
happy with an alternative, but I'd need a lightweight handle for this.

>     - Its also not clear to me how explicit remove plays well with unref.

Remove: removes it from the text object. This means the handle is still
alive, just disassociated from the text object so it doesn't affect it
anymore.

Unref: reduces the refcount in case you reffed it before. Used for when
you kept your own copies.

>     - the `insert` method should return a owned struct handle ? Or is
> the user never really owning any of the structs there ?

It's not owned. If you want to use it, you need to immediately ref it
after it's returned from there. It's done this way so you can safely
ignore the return value when you don't want it, but also use it when you do.

> - efl2_text_font_properties / style_properties: (I have criticized the
> names before, i like the new names.) However, hard to comment more, as i
> do not know much about text property stuff itself.

No worries, these ones are actually less of a problem for me.

> - efl2_text_wrap_properties: Can you document what impact ellipsis and
> wrap do have ?

As in: you have questions, or just commenting about the lack of docs?

> - efl2_text_markup:
>     - I am not entirely sure how item_factory works here. Is the
> item_factory knowing to which Efl2.Text_Markup they belong ? If so,
> shoudnt that be expressed somehow ?

Not sure I understand your question.

> - efl2_text_item_factory:
>     - Again, why having a struct here, same as above applies to this.

Same answer as before. :)

> - efl2_text_raw_editable:
>     - Where does this object belong ? We normally only have objects in
> efl.canvas / ui / layout. But not in efl. itself.

Happy to rename it, though dunno what to. It's somewhere between canvas
and ui. It's above canvas as it handles input and deals with X, but
below UI because it doesn't have a theme.

>     - Is it doing undo/redo or only emitting the events ?

At the moment just events, but Ali is going to fix this.

> - efl2_ui_text:
>     - Why are here cnp related events ? Isnt that just a normal
> insertion / copy operation ? The cut and copy operation could be on a
> object that handles cnp, the paste operation as well, paired with a
> changed,user event?

Fair comment, need to re-evaluate that.

> 
> General notes:
> - you used a lot of ptr(...), you cannot use them when you remove @beta
> from the file. These files should not use ptr, nor void_ptr.

I know. :(
I created my branch before there was an alternative (very recently), and
haven't updated anything yet.

> - You have a few places where you have explicitly x,y,w,h (x,y) in your
> API, can you replace them with rect (position) handles from eina, that
> would make it more aligned with the rest of efl.
> 

Could you please provide an example?

Thanks!

--
Tom

> Greetings,
>    bu5hm4n
> 
> On 9/19/19 4:15 PM, Tom Hacohen wrote:
>> Hey,
>>
>> As most of you (at least the IRC lurkers) know, I've been recently
>> working on the text interfaces. Trying to clean them up and stabilise
>> them.
>> The discussion and work has been covered on phab at:
>> https://phab.enlightenment.org/T8151
>>
>> And the new (suggested) interfaces are all the files starting with
>> "efl2_" in my branch:
>> https://git.enlightenment.org/core/efl.git/tree/?h=devs/tasn/ifaces
>>
>> I'd love to get your feedback and let me know if there's anything I've
>> missed. All feedback is welcomed, including bike shedding.
>> Some interfaces still have massive FIXMEs at the top, so obviously read
>> those before replying to avoid repeating what we already know.
>>
>>
>> As for the advice I mentioned in the title: due to composite object
>> regressions as described in T8184, I'm forced to break up the classes
>> into interfaces. As discussed at length in the ticket, these interfaces
>> would have to be very specific to the classes and not really reusable
>> ("cursor_new" is quite specifi

[E-devel] RFC: Text interface + advice regarding interface splitting

[Tom Hacohen]

Hey,

As most of you (at least the IRC lurkers) know, I've been recently
working on the text interfaces. Trying to clean them up and stabilise them.
The discussion and work has been covered on phab at:
https://phab.enlightenment.org/T8151

And the new (suggested) interfaces are all the files starting with
"efl2_" in my branch:
https://git.enlightenment.org/core/efl.git/tree/?h=devs/tasn/ifaces

I'd love to get your feedback and let me know if there's anything I've
missed. All feedback is welcomed, including bike shedding.
Some interfaces still have massive FIXMEs at the top, so obviously read
those before replying to avoid repeating what we already know.


As for the advice I mentioned in the title: due to composite object
regressions as described in T8184, I'm forced to break up the classes
into interfaces. As discussed at length in the ticket, these interfaces
would have to be very specific to the classes and not really reusable
("cursor_new" is quite specific, obviously).

I can either just do as I said in the ticket, and for every class do a
big interface, so Efl.Canvas.Text -> Efl.Canvas.Text +
Efl.Canvas.Text_Interface. This is one way. It's obviously very ugly.
The other way is to split to a lot of smaller, probably 1/2 property
interfaces, which is also ugly and quite inefficient (classes/interfaces
are not free).

I'd love to get your input, to what interfaces would you split up these
two classes:
1.
https://git.enlightenment.org/core/efl.git/tree/src/lib/evas/canvas/efl2_canvas_text.eo?h=devs/tasn/ifaces
2.
https://git.enlightenment.org/core/efl.git/tree/src/lib/elementary/efl2_text_raw_editable.eo?h=devs/tasn/ifaces


Thanks a lot for your help and feedback!

--
Tom


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

[EGIT] [editors/vim-configs] master 01/01: eolian: update vim synatx file based on recent eolian changes.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=c2ebd6aae1da03bd1d74f8296fbc8dc09e0c68f8

commit c2ebd6aae1da03bd1d74f8296fbc8dc09e0c68f8
Author: Tom Hacohen 
Date:   Wed Aug 28 15:32:44 2019 +0100

eolian: update vim synatx file based on recent eolian changes.
---
 syntax/eo.vim | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index e3602ec..c4f8eb3 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -11,7 +11,7 @@ syn keywordeoType byte ubyte char short ushort int uint 
long ulong llong
 syn keywordeoType ullong int8 uint8 int16 uint16 int32 uint32 int64 uint64
 syn keywordeoType int128 uint128 size ssize intptr uintptr ptrdiff time
 syn keywordeoType float double ldouble bool void
-syn keywordeoType hash string list accessor array iterator
+syn keywordeoType hash string list accessor array iterator future
 syn keywordeoType any_value any_value_ptr stringshare promise void_ptr
 syn keywordeoType __undefined_type
 
@@ -19,7 +19,7 @@ syn keywordeoClassTypes class abstract interface mixin
 syn keywordeoStructure struct enum var
 syn keywordeoTypedef type
 syn keywordeoImport import
-syn keywordeoClassAttributes implements extends
+syn keywordeoClassAttributes implements extends composite
 
 syn keywordeoClassBodyLabels c_prefix event_prefix data contained
 syn keywordeoClassBodyBlockOpener properties methods events constructors 
contained

-- 

[EGIT] [editors/vim-configs] master 01/01: Eolian: update according to eolian changes and fix implements/extends.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=8779a31d4af1342264afc455674bca737ecdc828

commit 8779a31d4af1342264afc455674bca737ecdc828
Author: Tom Hacohen 
Date:   Mon Aug 19 12:52:30 2019 +0100

Eolian: update according to eolian changes and fix implements/extends.
---
 syntax/eo.vim | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index 7559714..e3602ec 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -19,9 +19,10 @@ syn keywordeoClassTypes class abstract interface mixin
 syn keywordeoStructure struct enum var
 syn keywordeoTypedef type
 syn keywordeoImport import
+syn keywordeoClassAttributes implements extends
 
-syn keywordeoClassBodyLabels legacy_prefix eo_prefix event_prefix data 
contained
-syn keywordeoClassBodyBlockOpener properties methods events constructors 
implements contained
+syn keywordeoClassBodyLabels c_prefix event_prefix data contained
+syn keywordeoClassBodyBlockOpener properties methods events constructors 
contained
 
 syn keywordeoInnerBlockOpener set get keys values params contained
 syn keywordeoTypeClass const own free ref contained
@@ -104,6 +105,7 @@ hi def link eoOctalError Error
 
 hi def link eoStructure Structure
 hi def link eoClassTypes Structure
+hi def link eoClassAttributes Statement
 
 hi def link eoType Type
 hi def link eoTypedef Typedef

-- 

[EGIT] [editors/vim-configs] master 01/01: eolian: update vim synatx file based on recent eolian changes.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=f6e51963a4746cbb854ae351fe22be8e077a4aea

commit f6e51963a4746cbb854ae351fe22be8e077a4aea
Author: Tom Hacohen 
Date:   Fri Aug 16 17:35:35 2019 +0100

eolian: update vim synatx file based on recent eolian changes.
---
 syntax/eo.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index c1464b4..7559714 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -30,7 +30,7 @@ syn keywordeoStatements return
 
 " syn match  className   "\(\w\+\.\)\+\w\+"
 
-syn match  attributes  
"@\(nonull\|inout\|out\|in\|property\|class\|free\|constructor\|virtual_pure\|auto\|empty\|extern\|beta\|protected\|const\|optional\|nullable\|warn_unused\|owned\|private\|hot\)"
+syn match  attributes  
"@\(nonull\|inout\|out\|in\|property\|static\|free\|constructor\|virtual_pure\|auto\|empty\|extern\|beta\|protected\|const\|optional\|nullable\|warn_unused\|owned\|private\|hot\)"
 
 syn match eoLabelMatch   "\w\+:" contains=eoClassBodyLabels
 syn match eoBlockOpener  "\w\+\s*{" 
contains=eoClassBodyBlockOpener,eoInnerBlockOpener

-- 

[EGIT] [core/efl] master 01/01: Evas: migrate Evas_BiDi_Direction -> Efl_Text_Bidirectional_Type.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=84e06f7234335836d175cb1583aa91f183b98803

commit 84e06f7234335836d175cb1583aa91f183b98803
Author: Tom Hacohen 
Date:   Wed Aug 7 14:54:45 2019 +0100

Evas: migrate Evas_BiDi_Direction -> Efl_Text_Bidirectional_Type.
---
 src/lib/evas/Evas_Common.h  | 14 ++
 src/lib/evas/canvas/evas_object_textblock.c |  6 +++---
 2 files changed, 9 insertions(+), 11 deletions(-)

diff --git a/src/lib/evas/Evas_Common.h b/src/lib/evas/Evas_Common.h
index bd6102d702..1ae09bf259 100644
--- a/src/lib/evas/Evas_Common.h
+++ b/src/lib/evas/Evas_Common.h
@@ -368,14 +368,12 @@ typedef enum _Evas_Aspect_Control
EVAS_ASPECT_CONTROL_BOTH = 4 /**< Use all horizontal @b and vertical 
container spaces to place an object (never growing it out of those bounds), 
using the given aspect */
 } Evas_Aspect_Control; /**< Aspect types/policies for scaling size hints, used 
for evas_object_size_hint_aspect_set() */
 
-typedef enum _Evas_BiDi_Direction
-{
-   EVAS_BIDI_DIRECTION_NATURAL,
-   EVAS_BIDI_DIRECTION_NEUTRAL = EVAS_BIDI_DIRECTION_NATURAL,
-   EVAS_BIDI_DIRECTION_LTR,
-   EVAS_BIDI_DIRECTION_RTL,
-   EVAS_BIDI_DIRECTION_INHERIT
-} Evas_BiDi_Direction;
+typedef Efl_Text_Bidirectional_Type Evas_BiDi_Direction;
+#define EVAS_BIDI_DIRECTION_NEUTRAL EFL_TEXT_BIDIRECTIONAL_TYPE_NEUTRAL
+#define EVAS_BIDI_DIRECTION_NATURAL EFL_TEXT_BIDIRECTIONAL_TYPE_NATURAL
+#define EVAS_BIDI_DIRECTION_LTR EFL_TEXT_BIDIRECTIONAL_TYPE_LTR
+#define EVAS_BIDI_DIRECTION_RTL EFL_TEXT_BIDIRECTIONAL_TYPE_RTL
+#define EVAS_BIDI_DIRECTION_INHERIT EFL_TEXT_BIDIRECTIONAL_TYPE_INHERIT
 
 /**
  * How the mouse pointer should be handled by Evas.
diff --git a/src/lib/evas/canvas/evas_object_textblock.c 
b/src/lib/evas/canvas/evas_object_textblock.c
index 1135527ad2..e069e04ce7 100644
--- a/src/lib/evas/canvas/evas_object_textblock.c
+++ b/src/lib/evas/canvas/evas_object_textblock.c
@@ -15244,11 +15244,11 @@ 
_efl_canvas_text_efl_canvas_object_paragraph_direction_set(Eo *eo_obj,
 #ifdef BIDI_SUPPORT
Evas_Object_Protected_Data *obj = efl_data_scope_get(eo_obj, 
EFL_CANVAS_OBJECT_CLASS);
 
-   if ((!(o->inherit_paragraph_direction) && (o->paragraph_direction == 
(Evas_BiDi_Direction)dir)) ||
-   (o->inherit_paragraph_direction && ((Evas_BiDi_Direction)dir == 
EVAS_BIDI_DIRECTION_INHERIT)))
+   if ((!(o->inherit_paragraph_direction) && (o->paragraph_direction == dir)) 
||
+   (o->inherit_paragraph_direction && (dir == 
EVAS_BIDI_DIRECTION_INHERIT)))
  return;
 
-   if (dir == (Efl_Text_Bidirectional_Type)EVAS_BIDI_DIRECTION_INHERIT)
+   if (dir == EVAS_BIDI_DIRECTION_INHERIT)
  {
 o->inherit_paragraph_direction = EINA_TRUE;
 Evas_BiDi_Direction parent_dir = EVAS_BIDI_DIRECTION_NEUTRAL;

-- 

Re: [E-devel] Discussions here.

[Tom Hacohen]

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.

[Tom Hacohen]

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.

[Tom Hacohen]

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] FOSDEM 2019

[Tom Hacohen]

Hey,

I'll be there!

Looking forward to seeing everyone!

--
Tom

On Thu, Dec 20, 2018 at 11:25 AM Daniel Zaoui  wrote:
>
> Hi guys,
>
> FOSDEM is coming! A little more than one month! I plan to come. Are there 
> other folks that come too?
>
> Are there good, cheap and close-to-the-center hotels that you can recommend?
>
> See you there
> JackDanielZ
>
>
> ___
> 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] Gitlab

[Tom Hacohen]

I'm all in favour moving to a self-hosted Gitlab instance. Phabricator
is pretty awful and is not very approachable. Also, Gitlab has really
overtaken Phab in both popularity and maturity in the last 5 years
since we switched.

This will also reduce the admin burden of managing Gitolite, and
needing all repo creation to go through me.

So a huge +1 from me.

--
Tom

On Fri, Aug 10, 2018 at 7:09 PM, Mike Blumenkrantz
 wrote:
> Hello,
>
> For some time now, everyone in the community has been expressing
> significant dissatisfaction with the current project management software,
> Phabricator. A number of individuals have proposed switching to Gitlab for
> various reasons.
>
> Some will recall that recently all of the FDO infrastructure migrated from
> Phabricator to Gitlab thanks in large part to an incredible, hand-crafted
> migration script authored by notable open source figure Daniel Stone. While
> this script was not exactly what could be used to migrate our own
> infrastructure, it gave me an idea.
>
> Thanks to a low-pay intern who just graduated and whose name I don't
> recall, work began to modify the original FDO migration script and update
> it to handle various features exclusive to our usage of Phabricator. Thanks
> to generous hosting provided by the basement of the intern's parents, I was
> able to review the work as it progressed to see if it would be worth
> showing to the community.
>
> Weeks have passed, and now, thanks to many sleepless nights and long
> weekends that this devoted intern spent doing devops work, I was able to
> provide justification for more robust hosting and acquire a cloud service
> to host an official proof-of-concept for a Gitlab migration:
>
> https://gitlab-prototype.s-opensource.org/
>
> Some notes:
> * This is read-only for now
> * User creation is disabled, don't bother trying
> * Issues with their comments have been imported
> * Patch submissions have been imported (the intern screwed up some of the
> early imports so there are a few patches without the diff inlined)
>   - Comments on patch submissions cannot be imported because Phabricator
> has no API for retrieving comments on patch review
> * Wiki pages are not imported since some decision-making is required
>
> As is easily noticeable, not all projects have been imported by my intern.
> Importing the repo takes some time on its own, and then running the
> migration script takes a variable amount of time on top of that depending
> on the size of the project (EFL was estimated to take 10+ hours to fully
> import).
>
> Wiki pages have not been imported. On Gitlab, a wiki is project-specific
> and so it is impossible to do a 1:1 copy unless we decided to stick
> everything onto a specific project. We would have to decide how we want to
> do this.
>
> If we decided to switch to Gitlab, there would be a number of questions
> that need to be answered:
> Q: How do we migrate?
> A: Gitlab cannot accurately mirror all of Phabricator, it can only do a
> one-time migration of projects. This means we would at some point lock phab
> and then begin migrating, likely over a weekend for the major projects with
> the remainders being added later.
>
> Q: What happens to phab?
> A: We would likely want to keep phab in read-only mode for a while after
> the migration since all the migrated tickets/patches will provide links to
> it. We can later evaluate if we need to keep it running.
>
> Q: Where would this be hosted?
> A: The provided link here is a cloud service which will be funded for the
> foreseeable future. At present I am very strongly opposed to hosting this
> anywhere on the existing EFL infrastructure since it has been impossible
> for anyone to get access to any part of the server or to have tasks
> reliably handled in anything but a random and notification-less manner. A
> community project cannot have infrastructure which is unable to be
> accessed, managed, or maintained by the community which is using it.
>
> Regards,
> Mike
> --
> 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] FOSDEM

[Tom Hacohen]

I'm also coming. Want to book my travel. When is everyone getting
there/leaving?

I'm thinking doing Friday - Sunday?

--
Tom

On 17 Dec 2017 15:01, "Carsten Haitzler"  wrote:

> On Wed, 22 Nov 2017 18:02:56 + Andrew Williams 
> said:
>
> > Hi,
> >
> > The supplier I work with does not do embroidery.
> > Does anyone who will be attending Fosdem have the ability to get a full
> > shirt with stitching organised?
>
> We did before get caps made that are embroidered. i have one. also towels.
> cedric i think knows who/where...
>
> fyi i've booked my travel to fosdem, so i'll be there. :)
>
> > If not should I go ahead with a t-shirt or do folk feel strongly that it
> is
> > not suitable for us?
> >
> > Thanks,
> > Andy
> >
> > p.s. still wondering if folk would pay for their own shirt or if I need
> to
> > get sponsorship for this?
> >
> > On Thu, 9 Nov 2017 at 00:24 Carsten Haitzler 
> wrote:
> >
> > > On Wed, 08 Nov 2017 22:05:07 + Andrew Williams <
> a...@andywilliams.me>
> > > said:
> > >
> > > > Hi,
> > > >
> > > > I reckon stickers are a minimum :) not sure if we can afford more
> than
> > > that
> > > > to give away.
> > > >
> > > > I also wondered if we should get some new t-shirts - not to give
> away but
> > > > for a little branding and visibility. Would folk be willing to pay
> for
> > > > their own shirt?
> > > >
> > > > I was wondering about “Enlightenment” (with logo) on the front and
> maybe
> > > > “built on EFL” on the back :)
> > >
> > > Can we do more stylish than a t-shirt? Like... A proper collared shirt
> > > maybe
> > > with the logo embroidered? grey/black with white embroidery? :)
> > >
> > > > Looking forward to it,
> > > > Andy
> > > > On Mon, 23 Oct 2017 at 14:31, Philippe Caseiro  >
> > > wrote:
> > > >
> > > > > Hi !!
> > > > >
> > > > >Stand request posted !
> > > > >
> > > > >Now, I will work on some goodies !
> > > > >
> > > > >Some ideas or proposals ?
> > > > >
> > > > > Regards
> > > > >
> > > > > Le mercredi 11 octobre 2017 14:51:03 CEST, Philippe Caseiro a
> écrit :
> > > > > > Le mercredi 11 octobre 2017 13:19:42 CEST, Andrew Williams a
> écrit :
> > > > > >> Hi,
> > > > > >>
> > > > > >> Good shout! I think I could make it this year and would be
> happy to
> > > help
> > > > > >> with the stand and/or put forward a talk (probably around edi
> > > > > >> ;) or getting
> > > > > >> into efl).
> > > > > >
> > > > > > Great !
> > > > > >
> > > > > >>
> > > > > >> One proviso: we would have to do it properly - some fixed
> > > > > >> demos, a story to
> > > > > >> tell and probably some stickers too...
> > > > > >>
> > > > > >> An empty table with a name behind us made me sad :(
> > > > > >
> > > > > > Yes me to this year we will try to have a nice stand !
> > > > > >
> > > > > >
> > > > >
> > > > > --
> > > > > Philippe Caseiro
> > > > >
> > > > > Responsable Cadoles Services & Solutions
> > > > > Ingénieur logiciels libres
> > > > >
> > > > > https://www.cadoles.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
> > > > >
> > > > --
> > > > http://andywilliams.me
> > > > http://ajwillia.ms
> > > >
> > > 
> --
> > > > 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
> > >
> > > --
> > http://andywilliams.me
> > http://ajwillia.ms
>
>
> --
> - 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
>
--
Check out the vibrant tech community on one of the world's most

Re: [E-devel] FOSDEM 2017

[Tom Hacohen]

This one is from last year. ;)

On 17 Dec 2017 15:01, "Carsten Haitzler"  wrote:

> On Mon, 5 Dec 2016 14:09:00 +0100 Philippe Caseiro <
> caseiro.phili...@gmail.com>
> said:
>
> didn't submit... but i'm coming. :)
>
> > Hi, falks
> >
> >Sorry for the late notice I had some personal troubles this year so
> > I'm a little bit late.
> >
> >Please take some time to submit talks this week.
> >
> >One more time I'm very sorry about that delay and the short notice.
> >
> >
> >
> > FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free
> > Software contributors in the world and happens each February in
> > Brussels (Belgium, Europe). Once again, one of the tracks will be the
> > Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which
> > will host Desktop-related talks.
> >
> > We are now inviting proposals for talks about Free/Libre/Open-source
> > Software on the topics of Desktop development, Desktop applications
> > and interoperability amongst Desktop Environments. This is a unique
> > opportunity to show novel ideas and developments to a wide technical
> > audience.
> >
> > Topics accepted include, but are not limited to:
> >
> > Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE,
> > Cinnamon, ReactOS, CDE etc
> > Closed desktops: Windows, Mac OS X, MorphOS, etc (when talking about a
> > FLOSS topic)
> > Software development for the desktop
> > Development tools
> > Applications that enhance desktops
> > General desktop matters
> > Cross-platform software development
> > Web
> > Thin clients, desktop virtualiation, etc
> >
> > Talks can be very specific, such as the advantages/disadvantages of
> > distributing a desktop application with snap vs flatpak, or as general
> > as using HTML5 technologies to develop native applications.
> >
> > Topics that are of interest to the users and developers of all desktop
> > environments are especially welcome. The FOSDEM 2016 schedule might
> > give you some inspiration.
> >
> >
> > Submissions
> >
> > Please include the following information when submitting a proposal:
> >
> > Your name
> > The title of your talk (please be descriptive, as titles will be
> > listed with around 400 from other projects)
> > Short abstract of one or two paragraphs
> > Short bio (with photo)
> > Requested time: from 15 to 45 minutes. Normal duration is 30 minutes.
> > Longer duration requests must be properly justified. You may be
> > assigned LESS time than you request.
> >
> > How to submit
> >
> > All submissions are made in the Pentabarf event planning tool:
> > https://penta.fosdem.org/submission/FOSDEM17
> >
> > To submit your talk, click on "Create Event", then make sure to select
> > the “Desktops” devroom as the “Track”. Otherwise your talk will not be
> > even considered for any devroom at all.
> >
> > If you already have a Pentabarf account from a previous year, even if
> > your talk was not accepted, please reuse it. Create an account if, and
> > only if, you don’t have one from a previous year. If you have any
> > issues with Pentabarf, please contact desktops-devroom AT lists DOT
> > fosdem DOT org.
> >
> >
> > Deadline
> >
> > The deadline for submissions is December 5th 2016.
> >
> > FOSDEM will be held on the weekend of 4 & 5 February 2017 and the
> > Desktops DevRoom will take place on Sunday, February 5th 2017.
> >
> > We will contact every submitter with a “yes” or “no” before December 11th
> > 2016.
> >
> > Recording permission
> >
> > The talks in the Desktops DevRoom will be audio and video recorded,
> > and possibly streamed live too.
> >
> > In the "Submission notes" field, please indicate that you agree that
> > your presentation will be licensed under the CC-By-SA-4.0 or CC-By-4.0
> > license and that you agree to have your presentation recorded. For
> > example:
> >
> > "If my presentation is accepted for FOSDEM, I hereby agree to license
> > all recordings, slides, and other associated materials under the
> > Creative Commons Attribution Share-Alike 4.0 International License.
> > Sincerely, ."
> >
> > If you want us to stop the recording in the Q & A part (should you
> > have one), please tell us. We can do that but only for the Q & A part.
> >
> > More information
> >
> > The official communication channel for the Desktops DevRoom is its
> > mailing list desktops-devr...@lists.fosdem.org.
> >
> > Use this page to manage your subscription:
> > https://lists.fosdem.org/listinfo/desktops-devroom
> >
> >
> > Organization
> >
> > The Desktops DevRoom 2017 is managed by a team representing the most
> > notable open desktops:
> >
> > Pau Garcia i Quiles, KDE
> > Christophe Fergeau, Gnome
> > Michael Zanetti, Unity
> > Philippe Caseiro, Enlightenment
> > Jérome Leclanche, Razor
> >
> > If you want to join the team, please contact desktops-devroom AT lists
> > DOT fosdem DOT org.
> >
> >
> >
> > --
> > Philippe Caseiro
> >
> > Change your computer life
> > http://www.sourcemage.org
> > 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

I meant that you *should* configure something like this. I don't
remember if it was per project or global, but I remember there was
something.

--
Tom.

On Thu, Nov 30, 2017 at 7:46 AM, Stefan Schmidt <ste...@osg.samsung.com> wrote:
> Hello.
>
>
> On 11/29/2017 06:04 PM, Tom Hacohen wrote:
>> You need to add them to "ignore branches" on phab. Stefan? :P
>
> I never configured something like this on Phab. Did you mean someone else?
>
> 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

--
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] Git Feature/ Proposal

[Tom Hacohen]

You need to add them to "ignore branches" on phab. Stefan? :P

On Wed, Nov 29, 2017 at 4:30 AM, Jean-Philippe André <j...@videolan.org> wrote:
> Hi,
>
> Patches pushed to a feature branch should not close the opened revisions or
> tickets on phab, only mention the commit ids.
>
> Not sure who can make sure of this?
>
> Thanks,
>
>
> On Thu, Nov 23, 2017 at 7:52 AM, Simon Lees <sfl...@suse.de> wrote:
>
>>
>>
>> On 22/11/17 18:42, Andrew Williams wrote:
>> > Can we instead ask people to pull master into their branch before asking
>> > for review / merging it up to master? That’s pretty common practice - in
>> > fact for a long lived branch I would expect that to happen on a regular
>> > basis.
>> >
>> > Andy
>>
>> Yeah I presumed this would be a minimal expectation of any review, I
>> guess it should be explicitly documented somewhere.
>>
>> > On Wed, 22 Nov 2017 at 02:56, Jean-Philippe André <j...@videolan.org>
>> wrote:
>> >
>> >> My problem is that those branches won't be in sync with master.
>> >> This will lead to merge conflicts. I am these days reviewing a lot of
>> work
>> >> done in dev branches or phab patches and it almost never applies nicely
>> on
>> >> master, because the interfaces change.
>> >> A lot of work is done in branches (model, c#, eo widgets, ...) and those
>> >> tasks are both long term and involve more than a single dev. They
>> require
>> >> constant rebasing on master or the final rebase will be a nightmare.
>> Right
>> >> now this is done by people pulling other devs branches, and then
>> rebasing
>> >> onto master in their own dev branch.
>> >>
>> >> Rewriting history on a shared branch has major downsides too. No problem
>> >> for dev branches as there's only one committer, but anyone pulling a
>> >> rewritten history will endure pain.
>> >>
>> >> Honestly I don't have a solution.
>> >>
>> >> It's a move in the right direction, but I'm not sure it's solving the
>> >> problems I'm facing :(
>> >>
>> >>
>> >>
>> >> 2017-11-22 3:43 GMT+09:00 Tom Hacohen <t...@stosb.com>:
>> >>
>> >>> Only problem would be the commit emails being resent (because
>> >>> technically they are new commits). One can mitigate that by first
>> >>> pushing them to a dev branch. Commits there have first been there
>> >>> don't trigger emails.
>> >>>
>> >>> On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
>> >>> <michael.blumenkra...@gmail.com> wrote:
>> >>>> In the issue where a significant rebase against master is necessary
>> >> then
>> >>>> it's trivial enough to either push to a new feature branch or delete
>> >> and
>> >>>> re-create the existing branch.
>> >>>>
>> >>>> On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen <t...@stosb.com> wrote:
>> >>>>
>> >>>>> As Mike said, the rebase/sync to master is being done locally before
>> >>>>> the merge. If you are talking about keeping this branch in sync with
>> >>>>> master constantly while developing, yes it's a problem. But I guess
>> >>>>> it's not intended for long term features.
>> >>>>>
>> >>>>> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>> >>>>> <michael.blumenkra...@gmail.com> wrote:
>> >>>>>> I don't see a difference in the merge process? A feature branch
>> >>> should be
>> >>>>>> treated exactly the same as master; the only difference is that
>> >> it's a
>> >>>>>> branch which people must specifically pull in order to use instead
>> >> of
>> >>>>> being
>> >>>>>> master.
>> >>>>>>
>> >>>>>> When merging, you can either do a regular rebase/merge as in the git
>> >>>>>> practices documentation or you can choose to rebase/squash on the
>> >>>>> branched
>> >>>>>> commits prior to pushing the merge. There is no rewriting within the
>> >>>>>> branch, but you can still rewrite anything which has not been pushed
>> >>> to
&g

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

Only problem would be the commit emails being resent (because
technically they are new commits). One can mitigate that by first
pushing them to a dev branch. Commits there have first been there
don't trigger emails.

On Tue, Nov 21, 2017 at 6:40 PM, Mike Blumenkrantz
<michael.blumenkra...@gmail.com> wrote:
> In the issue where a significant rebase against master is necessary then
> it's trivial enough to either push to a new feature branch or delete and
> re-create the existing branch.
>
> On Tue, Nov 21, 2017 at 1:36 PM Tom Hacohen <t...@stosb.com> wrote:
>
>> As Mike said, the rebase/sync to master is being done locally before
>> the merge. If you are talking about keeping this branch in sync with
>> master constantly while developing, yes it's a problem. But I guess
>> it's not intended for long term features.
>>
>> On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
>> <michael.blumenkra...@gmail.com> wrote:
>> > I don't see a difference in the merge process? A feature branch should be
>> > treated exactly the same as master; the only difference is that it's a
>> > branch which people must specifically pull in order to use instead of
>> being
>> > master.
>> >
>> > When merging, you can either do a regular rebase/merge as in the git
>> > practices documentation or you can choose to rebase/squash on the
>> branched
>> > commits prior to pushing the merge. There is no rewriting within the
>> > branch, but you can still rewrite anything which has not been pushed to
>> > master just prior to pushing it to master.
>> >
>> > On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <j...@videolan.org>
>> > wrote:
>> >
>> >> Hey,
>> >>
>> >> If we can't rewrite history on those branches (rebase and push -f), how
>> >> should we proceed with the merge to/from master?
>> >> Usually when we merge a branch to master, we rebase it on top of master
>> >> first and then rebase. That's how our history remains linear and simple.
>> >>
>> >> What's the idea here? I wonder.
>> >>
>> >> Thanks for implementing this btw,
>> >>
>> >> 2017-11-21 8:49 GMT+09:00 Tom Hacohen <t...@stosb.com>:
>> >>
>> >> > I'm not sure about jenkins, that's Stefan's role.
>> >> >
>> >> > Anyhow, pushed the changes according to the wiki. Please consider
>> >> > especially mentioning probies when you say "everyone can push to".
>> >> >
>> >> > --
>> >> > Tom.
>> >> >
>> >> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> >> > <michael.blumenkra...@gmail.com> wrote:
>> >> > > I've added all the necessary info to the documentation at
>> >> > >
>> >>
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> >> > >
>> >> > > If the jenkins concept is not possible then feel free to remove, but
>> >> the
>> >> > > rest should be in line with what we want.
>> >> > >
>> >> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen <t...@stosb.com> wrote:
>> >> > >
>> >> > >> So what has been decided? What should I do? I need specs,
>> preferably
>> >> > >> already added to the git wiki page so there are docs for this
>> thing.
>> >> > >>
>> >> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> >> ras...@rasterman.com
>> >> > >
>> >> > >> wrote:
>> >> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> >> > >> > <michael.blumenkra...@gmail.com> said:
>> >> > >> >
>> >> > >> >> Key points for the implementation:
>> >> > >> >>
>> >> > >> >> * all commits send mails to the list
>> >> > >> >> * no rewrite of pushed commits
>> >> > >> >>
>> >> > >> >> Things to consider:
>> >> > >> >> * how are feature/ branches deleted?
>> >> > >> >>  - maybe anyone can delete?
>> >> > >> >
>> >> > >> > Good point. these need deletion. after a few years it'll be a
>> mess
>> >> of
>> >> > old
>> >> 

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

As Mike said, the rebase/sync to master is being done locally before
the merge. If you are talking about keeping this branch in sync with
master constantly while developing, yes it's a problem. But I guess
it's not intended for long term features.

On Tue, Nov 21, 2017 at 3:12 PM, Mike Blumenkrantz
<michael.blumenkra...@gmail.com> wrote:
> I don't see a difference in the merge process? A feature branch should be
> treated exactly the same as master; the only difference is that it's a
> branch which people must specifically pull in order to use instead of being
> master.
>
> When merging, you can either do a regular rebase/merge as in the git
> practices documentation or you can choose to rebase/squash on the branched
> commits prior to pushing the merge. There is no rewriting within the
> branch, but you can still rewrite anything which has not been pushed to
> master just prior to pushing it to master.
>
> On Mon, Nov 20, 2017 at 9:00 PM Jean-Philippe André <j...@videolan.org>
> wrote:
>
>> Hey,
>>
>> If we can't rewrite history on those branches (rebase and push -f), how
>> should we proceed with the merge to/from master?
>> Usually when we merge a branch to master, we rebase it on top of master
>> first and then rebase. That's how our history remains linear and simple.
>>
>> What's the idea here? I wonder.
>>
>> Thanks for implementing this btw,
>>
>> 2017-11-21 8:49 GMT+09:00 Tom Hacohen <t...@stosb.com>:
>>
>> > I'm not sure about jenkins, that's Stefan's role.
>> >
>> > Anyhow, pushed the changes according to the wiki. Please consider
>> > especially mentioning probies when you say "everyone can push to".
>> >
>> > --
>> > Tom.
>> >
>> > On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
>> > <michael.blumenkra...@gmail.com> wrote:
>> > > I've added all the necessary info to the documentation at
>> > >
>> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>> > >
>> > > If the jenkins concept is not possible then feel free to remove, but
>> the
>> > > rest should be in line with what we want.
>> > >
>> > > On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen <t...@stosb.com> wrote:
>> > >
>> > >> So what has been decided? What should I do? I need specs, preferably
>> > >> already added to the git wiki page so there are docs for this thing.
>> > >>
>> > >> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <
>> ras...@rasterman.com
>> > >
>> > >> wrote:
>> > >> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> > >> > <michael.blumenkra...@gmail.com> said:
>> > >> >
>> > >> >> Key points for the implementation:
>> > >> >>
>> > >> >> * all commits send mails to the list
>> > >> >> * no rewrite of pushed commits
>> > >> >>
>> > >> >> Things to consider:
>> > >> >> * how are feature/ branches deleted?
>> > >> >>  - maybe anyone can delete?
>> > >> >
>> > >> > Good point. these need deletion. after a few years it'll be a mess
>> of
>> > old
>> > >> > feature branches no one will ever look at again. The merge to master
>> > >> should
>> > >> > contain all the history and log that is needed at that point for
>> > history
>> > >> > digging.
>> > >> >
>> > >> >> * do probies get feature/ push access?
>> > >> >>  - seems like they should?
>> > >> >>
>> > >> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen <t...@stosb.com> wrote:
>> > >> >>
>> > >> >> > Yeah, good idea.
>> > >> >> >
>> > >> >> > I'll take a look into implementing it soon.
>> > >> >> >
>> > >> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <
>> > a...@andywilliams.me
>> > >> >
>> > >> >> > wrote:
>> > >> >> > > Hi,
>> > >> >> > >
>> > >> >> > > That sounds great - the ability to work together on features
>> > >> off-master
>> > >> >> > > would be really helpful.
>> > >> &

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

I'm not sure about jenkins, that's Stefan's role.

Anyhow, pushed the changes according to the wiki. Please consider
especially mentioning probies when you say "everyone can push to".

--
Tom.

On Mon, Nov 20, 2017 at 3:27 PM, Mike Blumenkrantz
<michael.blumenkra...@gmail.com> wrote:
> I've added all the necessary info to the documentation at
> https://www.enlightenment.org/contrib/devs/git-guide.md#Feature_Branches
>
> If the jenkins concept is not possible then feel free to remove, but the
> rest should be in line with what we want.
>
> On Mon, Nov 13, 2017 at 6:54 AM Tom Hacohen <t...@stosb.com> wrote:
>
>> So what has been decided? What should I do? I need specs, preferably
>> already added to the git wiki page so there are docs for this thing.
>>
>> On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> > On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
>> > <michael.blumenkra...@gmail.com> said:
>> >
>> >> Key points for the implementation:
>> >>
>> >> * all commits send mails to the list
>> >> * no rewrite of pushed commits
>> >>
>> >> Things to consider:
>> >> * how are feature/ branches deleted?
>> >>  - maybe anyone can delete?
>> >
>> > Good point. these need deletion. after a few years it'll be a mess of old
>> > feature branches no one will ever look at again. The merge to master
>> should
>> > contain all the history and log that is needed at that point for history
>> > digging.
>> >
>> >> * do probies get feature/ push access?
>> >>  - seems like they should?
>> >>
>> >> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen <t...@stosb.com> wrote:
>> >>
>> >> > Yeah, good idea.
>> >> >
>> >> > I'll take a look into implementing it soon.
>> >> >
>> >> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <a...@andywilliams.me
>> >
>> >> > wrote:
>> >> > > Hi,
>> >> > >
>> >> > > That sounds great - the ability to work together on features
>> off-master
>> >> > > would be really helpful.
>> >> > >
>> >> > > Andy
>> >> > >
>> >> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> >> > > michael.blumenkra...@gmail.com> wrote:
>> >> > >
>> >> > >> After some discussions about git organization, it's become clear
>> to me
>> >> > that
>> >> > >> we should be trying to enact some changes which facilitate
>> >> > collaboration,
>> >> > >> both between existing contributors and keeping in mind future
>> >> > contributors.
>> >> > >>
>> >> > >> The current git branch policy is this:
>> >> > >>
>> >> > >> * master
>> >> > >> * $project-$version
>> >> > >> * devs/$name/$branchname
>> >> > >>
>> >> > >> No others are allowed. This fits many use cases, but it does not
>> >> > actually
>> >> > >> help us work towards collaborating on features/patchsets and
>> instead
>> >> > >> promotes developing in isolation.
>> >> > >>
>> >> > >> A simple proposal could improve this without requiring or
>> significantly
>> >> > >> changing our workflow: add "feature/" branches. For example, if
>> Cedric
>> >> > and
>> >> > >> I decide to work on a "feature" which scrapes the archive of this
>> >> > mailing
>> >> > >> list and then crashes the session of anyone who replies to this
>> thread,
>> >> > we
>> >> > >> might jointly create a branch named "feature/discussion_helper"
>> and push
>> >> > >> commits to it.
>> >> > >>
>> >> > >> A key point of this proposal would be that the feature/ branches
>> must
>> >> > >> trigger mails to the mailing list just like stable branches. This
>> would
>> >> > >> increase visibility for feature branches as well as promote further
>> >> > >> collaboration even from those who are not directly involved in
>> creating
>> >> > t

Re: [E-devel] Terminology, one of the coolest linux terminal emulators

[Tom Hacohen]

Very nice.

On Mon, Nov 20, 2017 at 10:24 PM, Boris Faure  wrote:
> Hi :)
>
> Linux.com published an article [1] on the top 5 coolest linux terminal
> emulators.
>   Terminology is nicely described there. You shall all be proud of it
> and the great work on EFL!
>
> Thanks!
>
> 1.  
> https://www.linux.com/learn/intro-to-linux/2017/11/5-coolest-linux-terminal-emulators
> --
> Boris Faure
> Pointer Arithmetician
>
> --
> 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] Git Feature/ Proposal

[Tom Hacohen]

So what has been decided? What should I do? I need specs, preferably
already added to the git wiki page so there are docs for this thing.

On Wed, Nov 8, 2017 at 11:57 PM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Wed, 08 Nov 2017 21:39:15 + Mike Blumenkrantz
> <michael.blumenkra...@gmail.com> said:
>
>> Key points for the implementation:
>>
>> * all commits send mails to the list
>> * no rewrite of pushed commits
>>
>> Things to consider:
>> * how are feature/ branches deleted?
>>  - maybe anyone can delete?
>
> Good point. these need deletion. after a few years it'll be a mess of old
> feature branches no one will ever look at again. The merge to master should
> contain all the history and log that is needed at that point for history
> digging.
>
>> * do probies get feature/ push access?
>>  - seems like they should?
>>
>> On Wed, Nov 8, 2017 at 2:42 PM Tom Hacohen <t...@stosb.com> wrote:
>>
>> > Yeah, good idea.
>> >
>> > I'll take a look into implementing it soon.
>> >
>> > On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams <a...@andywilliams.me>
>> > wrote:
>> > > Hi,
>> > >
>> > > That sounds great - the ability to work together on features off-master
>> > > would be really helpful.
>> > >
>> > > Andy
>> > >
>> > > On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
>> > > michael.blumenkra...@gmail.com> wrote:
>> > >
>> > >> After some discussions about git organization, it's become clear to me
>> > that
>> > >> we should be trying to enact some changes which facilitate
>> > collaboration,
>> > >> both between existing contributors and keeping in mind future
>> > contributors.
>> > >>
>> > >> The current git branch policy is this:
>> > >>
>> > >> * master
>> > >> * $project-$version
>> > >> * devs/$name/$branchname
>> > >>
>> > >> No others are allowed. This fits many use cases, but it does not
>> > actually
>> > >> help us work towards collaborating on features/patchsets and instead
>> > >> promotes developing in isolation.
>> > >>
>> > >> A simple proposal could improve this without requiring or significantly
>> > >> changing our workflow: add "feature/" branches. For example, if Cedric
>> > and
>> > >> I decide to work on a "feature" which scrapes the archive of this
>> > mailing
>> > >> list and then crashes the session of anyone who replies to this thread,
>> > we
>> > >> might jointly create a branch named "feature/discussion_helper" and push
>> > >> commits to it.
>> > >>
>> > >> A key point of this proposal would be that the feature/ branches must
>> > >> trigger mails to the mailing list just like stable branches. This would
>> > >> increase visibility for feature branches as well as promote further
>> > >> collaboration even from those who are not directly involved in creating
>> > the
>> > >> feature. The initial feature development could be done in a dev/ branch,
>> > >> and then it could later move to a feature/ branch once it has
>> > progressed to
>> > >> the point where it is ready for public visibility and increased
>> > >> collaboration.
>> > >>
>> > >> Lastly, feature branches would not be required use, just encouraged.
>> > This
>> > >> allows people to continue the current EFL standard of always committing
>> > >> only to master without any prior testing or branching, the need for
>> > which
>> > >> has defeated other proposals which would prevent such action.
>> > >>
>> > >> I think this could yield significant improvements to the community's
>> > >> overall workflow without massively changing the structure under which
>> > the
>> > >> everyone has been functioning.
>> > >>
>> > >>
>> > --
>> > >> Check out the vibrant tech community on one of the world's most
>> > >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> > >> ___
>> > >

Re: [E-devel] Git Feature/ Proposal

[Tom Hacohen]

Yeah, good idea.

I'll take a look into implementing it soon.

On Tue, Nov 7, 2017 at 8:50 PM, Andrew Williams  wrote:
> Hi,
>
> That sounds great - the ability to work together on features off-master
> would be really helpful.
>
> Andy
>
> On Tue, 7 Nov 2017 at 16:15, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
>> After some discussions about git organization, it's become clear to me that
>> we should be trying to enact some changes which facilitate collaboration,
>> both between existing contributors and keeping in mind future contributors.
>>
>> The current git branch policy is this:
>>
>> * master
>> * $project-$version
>> * devs/$name/$branchname
>>
>> No others are allowed. This fits many use cases, but it does not actually
>> help us work towards collaborating on features/patchsets and instead
>> promotes developing in isolation.
>>
>> A simple proposal could improve this without requiring or significantly
>> changing our workflow: add "feature/" branches. For example, if Cedric and
>> I decide to work on a "feature" which scrapes the archive of this mailing
>> list and then crashes the session of anyone who replies to this thread, we
>> might jointly create a branch named "feature/discussion_helper" and push
>> commits to it.
>>
>> A key point of this proposal would be that the feature/ branches must
>> trigger mails to the mailing list just like stable branches. This would
>> increase visibility for feature branches as well as promote further
>> collaboration even from those who are not directly involved in creating the
>> feature. The initial feature development could be done in a dev/ branch,
>> and then it could later move to a feature/ branch once it has progressed to
>> the point where it is ready for public visibility and increased
>> collaboration.
>>
>> Lastly, feature branches would not be required use, just encouraged. This
>> allows people to continue the current EFL standard of always committing
>> only to master without any prior testing or branching, the need for which
>> has defeated other proposals which would prevent such action.
>>
>> I think this could yield significant improvements to the community's
>> overall workflow without massively changing the structure under which the
>> everyone has been functioning.
>>
>> --
>> 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
>>
> --
> http://andywilliams.me
> http://ajwillia.ms
> --
> 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] GitFlow

[Tom Hacohen]

Intended to be would maybe be more appropriate, and then the statement
would still apply. With that being said, I'm sorry to hear that it has
changed, you guys should be spanking b0rokers more, don't let them
win.

Regardless of that, as said on IRC, the reason why we do trunk
(master) based development is that we all run master all the time and
thus test as many configurations as possible all the time. I don't see
why we need a rolling-branch that is more stable (master in the
gitflow terminology) than the development trunk, because we'll all
just switch to develop and that's it.
Andy claims that there are compelling cases. I've read some blog posts
over the years about it, and I'm not convinced.

--
Tom.


On Thu, Oct 26, 2017 at 5:14 PM, Mike Blumenkrantz
<michael.blumenkra...@gmail.com> wrote:
> 'Our master is already considered "stable" and in a release state, so it
> really doesn't match our workflow.'
>
> Things have changed a bit since you've been gone, and this is not even
> remotely close to being true anymore. As far as all of my use cases go
> (everyday use on X, testing on Wayland, basic application functionality),
> master has been completely unusable for this entire release cycle. Based on
> the current workflow of write code -> commit directly to master without any
> form of testing, it seems like this will continue to be the case for the
> foreseeable future.
>
> I am in no way directing this at you personally, but for us to be basing
> any decision on the above statement is, at this time, nothing more than a
> false premise (https://en.wikipedia.org/wiki/False_premise) argument.
>
> On Thu, Oct 26, 2017 at 8:39 AM Tom Hacohen <t...@stosb.com> wrote:
>
>> I accidentally hit send, didn't mean to.
>> Here is my full reply:
>> It's possible, yes, but it doesn't address my initial concerns, which
>> are that edi will stick out compared to the other e projects. This
>> will be considered a success by you for sure, and I don't see us
>> changing the efl to follow, so it'll stay different.
>> Furthermore, once you publish a tag/branch they should remain there,
>> so even if we don't like it, it'll have to stay in edi or at least edi
>> will be different.
>> Btw, changing HEAD to be "develop" rather than "master" is a bit more
>> intrusive and painful.
>>
>> Additionally, I just took a look at this gitflow thing, and noticed
>> that it's pretty much what we do but worse (apart of the poor mistake
>> that we did which is having the stable branches be named per repo
>> rather than having a consistent name, that is, efl-1.7 instead of
>> stable-1.17).
>> We never needed a "hotfix" branch, the "release" branch has always
>> proved sufficient for us (I can see the potential need, we just never
>> hit it). After taking a second look, he deletes branches afterwards,
>> so it's a workflow we can and already do here.
>> Release branches we already have.
>> We name our tags v1.17.0 compared to 1.17.0 which I think is better.
>> I don't see the advantage of having a "develop" branch in addition to
>> master given our workflow. Our master is already considered "stable"
>> and in a release state, so it really doesn't match our workflow.
>>
>> So I'm not really impressed with this suggestion (and in particular
>> GitFlow), and I don't think it can be done in a way that is possible
>> to revert or is compatible with what we do.
>> As I said, if you want to test it, test it with your own dev branches,
>> show us that the workflow works and just configure your tools for this
>> testing period, I don't see why the test period needs to have the
>> formal names.
>>
>> You mentioned having tools that work with it, what exactly?
>>
>> As a side note, I'm OK with changing the stable release branches to
>> "release-x.y" if people are OK with that, instead of the per repo
>> naming, this will make it slightly more compatible for you, and
>> actually makes sense regardless (was a mistake in the first place).
>>
>> --
>> Tom
>>
>> On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen <t...@stosb.com> wrote:
>> > It is possible, yes.
>> >
>> > On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>> >> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <
>> a...@andywilliams.me> said:
>> >>
>> >>> Hi,
>> >>>
>> >>> You are absolutely right - the “show it with a smaller project and
>> prove
>> >>> it’s worth is exactly why I brought it up. I

Re: [E-devel] GitFlow

[Tom Hacohen]

I accidentally hit send, didn't mean to.
Here is my full reply:
It's possible, yes, but it doesn't address my initial concerns, which
are that edi will stick out compared to the other e projects. This
will be considered a success by you for sure, and I don't see us
changing the efl to follow, so it'll stay different.
Furthermore, once you publish a tag/branch they should remain there,
so even if we don't like it, it'll have to stay in edi or at least edi
will be different.
Btw, changing HEAD to be "develop" rather than "master" is a bit more
intrusive and painful.

Additionally, I just took a look at this gitflow thing, and noticed
that it's pretty much what we do but worse (apart of the poor mistake
that we did which is having the stable branches be named per repo
rather than having a consistent name, that is, efl-1.7 instead of
stable-1.17).
We never needed a "hotfix" branch, the "release" branch has always
proved sufficient for us (I can see the potential need, we just never
hit it). After taking a second look, he deletes branches afterwards,
so it's a workflow we can and already do here.
Release branches we already have.
We name our tags v1.17.0 compared to 1.17.0 which I think is better.
I don't see the advantage of having a "develop" branch in addition to
master given our workflow. Our master is already considered "stable"
and in a release state, so it really doesn't match our workflow.

So I'm not really impressed with this suggestion (and in particular
GitFlow), and I don't think it can be done in a way that is possible
to revert or is compatible with what we do.
As I said, if you want to test it, test it with your own dev branches,
show us that the workflow works and just configure your tools for this
testing period, I don't see why the test period needs to have the
formal names.

You mentioned having tools that work with it, what exactly?

As a side note, I'm OK with changing the stable release branches to
"release-x.y" if people are OK with that, instead of the per repo
naming, this will make it slightly more compatible for you, and
actually makes sense regardless (was a mistake in the first place).

--
Tom

On Thu, Oct 26, 2017 at 1:20 PM, Tom Hacohen <t...@stosb.com> wrote:
> It is possible, yes.
>
> On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler <ras...@rasterman.com> 
> wrote:
>> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <a...@andywilliams.me> 
>> said:
>>
>>> Hi,
>>>
>>> You are absolutely right - the “show it with a smaller project and prove
>>> it’s worth is exactly why I brought it up. I was in the process of doing so
>>> and hit this roadblock. No intention to beat a dead horse - I actually
>>> thought I was doing what was agreed.
>>>
>>> Apologies if I got the wrong end of the stick.
>>
>> Well I think doing this with edi is fine. is it possible to have just edi 
>> have
>> different branch naming schemes? i don't know. if it's not then we have
>> problems. but i think we;re on the same page atm "try this in a smaller scale
>> and show it improves things - us that to convince everyone else". :)
>>
>>> Andy
>>>
>>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler <ras...@rasterman.com> wrote:
>>>
>>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams <a...@andywilliams.me>
>>> > said:
>>> >
>>> > We had this discussion before in just one place I believe until you asked
>>> > for
>>> > specific branch names to be allowed. You wanted us to change how we branch
>>> > and
>>> > work with efl/e etc. the last time. I don't remember there being agreement
>>> > with
>>> > you on needing a change as I don't see our current model being bad or
>>> > broken
>>> > or causing trouble (discussion already had) vs gitflow. I don't know why
>>> > you're
>>> > bringing it back up as if there wasn't a consensus already. I believe the
>>> > last
>>> > discussion was roughly:
>>> >
>>> > "There is no agreement that any change is needed. The change you propose
>>> > does
>>> > nothing to actually improve anything by it's proposal. It just shuffles
>>> > chairs,
>>> > BUT if you really think it's so much better, try it on smaller projects
>>> > first
>>> > and show/prove it to be worth it".
>>> >
>>> > Or something to that effect. Most people were just silent on the topic.
>>> >
>>> > > Hi list,
>>> > >
>>> > > This conversation seems t

Re: [E-devel] GitFlow

[Tom Hacohen]

It is possible, yes.

On Thu, Oct 26, 2017 at 10:50 AM, Carsten Haitzler <ras...@rasterman.com> wrote:
> On Thu, 26 Oct 2017 07:19:51 + Andrew Williams <a...@andywilliams.me> 
> said:
>
>> Hi,
>>
>> You are absolutely right - the “show it with a smaller project and prove
>> it’s worth is exactly why I brought it up. I was in the process of doing so
>> and hit this roadblock. No intention to beat a dead horse - I actually
>> thought I was doing what was agreed.
>>
>> Apologies if I got the wrong end of the stick.
>
> Well I think doing this with edi is fine. is it possible to have just edi have
> different branch naming schemes? i don't know. if it's not then we have
> problems. but i think we;re on the same page atm "try this in a smaller scale
> and show it improves things - us that to convince everyone else". :)
>
>> Andy
>>
>> On Thu, 26 Oct 2017 at 00:58, Carsten Haitzler <ras...@rasterman.com> wrote:
>>
>> > On Wed, 25 Oct 2017 20:15:45 + Andrew Williams <a...@andywilliams.me>
>> > said:
>> >
>> > We had this discussion before in just one place I believe until you asked
>> > for
>> > specific branch names to be allowed. You wanted us to change how we branch
>> > and
>> > work with efl/e etc. the last time. I don't remember there being agreement
>> > with
>> > you on needing a change as I don't see our current model being bad or
>> > broken
>> > or causing trouble (discussion already had) vs gitflow. I don't know why
>> > you're
>> > bringing it back up as if there wasn't a consensus already. I believe the
>> > last
>> > discussion was roughly:
>> >
>> > "There is no agreement that any change is needed. The change you propose
>> > does
>> > nothing to actually improve anything by it's proposal. It just shuffles
>> > chairs,
>> > BUT if you really think it's so much better, try it on smaller projects
>> > first
>> > and show/prove it to be worth it".
>> >
>> > Or something to that effect. Most people were just silent on the topic.
>> >
>> > > Hi list,
>> > >
>> > > This conversation seems to have now happened in many places and it seems
>> > > that a few key individuals don't really see why we should be looking at
>> > > different branching models. I understand that opinion but if we don't try
>> > > new things then we will never be able to engage with new process or
>> > > technologies so I am keen to try gitflow nonetheless.
>> > >
>> > > So at this point I would like this thread to record a definitive
>> > decision.
>> > > Will we allow reduced branch name restrictions on our git repositories or
>> > > not?
>> > > Thanks,
>> > > Andy
>> > >
>> > > On Mon, 23 Oct 2017 at 11:43 Andrew Williams <a...@andywilliams.me>
>> > wrote:
>> > >
>> > > > Hi TAsn,
>> > > >
>> > > > Thanks for the reply. In gitflow these are the standards and they need
>> > to
>> > > > work across different users hence why having the developer namespace
>> > is not
>> > > > quite enough. Additionally the hotfix is not catered for in our current
>> > > > scheme (as I understand it).
>> > > > One nice thing with gitflow is the plugin that manages all the branches
>> > > > for you. If you have custom schemes then every person looking to take
>> > up
>> > > > development has to configure it before getting started, so the
>> > defaults are
>> > > > best if possible.
>> > > >
>> > > > I appreciate that consistency is important but taken so stringently it
>> > > > means we can never try anything new... An earlier discussion on
>> > GitFlow led
>> > > > to raster saying that he would need to see it working to understand the
>> > > > value - so I would like to do just that.
>> > > >
>> > > > I understand that folk don't necessarily see the value, but I have done
>> > > > and would like to try it for the projects that I am managing. That
>> > > > shouldn't be too onerous I think? Also as apps move from autotools to
>> > meson
>> > > > we already have a reduced consistency between projects.
>> > > >
>> > > > Thanks,
>> > > > Andy
>> > >

[E-devel] E git administrators

[Tom Hacohen]

Hey,

I added zmike as an admin to our Git infrastructure. He rightfully
pointed out that we currently have no representation in his timezone
(America), and that our bus factor is kind of low.

Just wanted to post it here so everyone is aware.

The list of mostly available git admins is thus: Beber, zmike and
myself, in no particular order.

--
Tom.

--
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] GitFlow

[Tom Hacohen]

Heya,

I don't quite understand what you are trying to do here. I mean, I
understand you are trying to have these, but what are these branches
for? If it's for you developing your own features why not put it in a
dev branch?

We have these enforcements because we want to enforce branch names to
follow a consistent pattern across the repos. I don't mind changing it per se,
though:
1. I don't really see an obvious value with gitflow.
2. I'd prefer if it was consistent across repos.

Maybe people don't agree with this, but my take towards the e repos is
similar to that
of the GNU project. Have everything follow similar guidelines and be
mostly similar,
making it easier for devs to jump across projects. Yes, that
consistency sometimes
comes with a price, but I think that it's worth it.

Looking forward to hearing what other people think.

--
Tom.

On Sat, Oct 21, 2017 at 4:18 PM, Andrew Williams  wrote:
> Hi git admins,
>
> I'm setting up gitflow on Edi but I can't push to origin because of the
> branch naming rules. Can you please open up the ability to have remote
> branches matching the patterns "develop", "feature/*", "bugfix/*",
> "release/*", "hotfix/*" and "support/*"?
>
> I'd really appreciate it thanks.
> Oh and to those who worried about "changing to develop branch is an extra
> step" don't fear as HEAD can be pointed to develop instead of master if
> that's what folk are looking to have set up :)
>
> Cheers,
> Andrew
>
> --
> http://andywilliams.me
> http://ajwillia.ms
> --
> 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] Taking over as maintainer of ecrire

[Tom Hacohen]

Replying to both of you in one go.

On Wed, May 10, 2017 at 1:38 AM, Simon Lees <sfl...@suse.de> wrote:
>
>
> On 05/10/2017 08:39 AM, William L. Thomson Jr. wrote:
>> I finally got in touch with Tom Hacohen/tasn. Turns out IRC was best
>> form, as phab and mailing list were not, go figure. Seems I have Tom's
>> blessing to take over ecrire[1]. Which there is no rush to do
>> officially. I have already informally taken it over and proceeded with
>> tags, release, etc[2].

Phab is the worst way to reach me, IRC and direct emails are best, and
mailing list is somewhere in the middle.
I guess I just missed your mailing list post.

>>
>> Main question over time is how to merge this back into enlightment, or
>> keep it separate etc. My goal is not to make this my project, but to be
>> the default text edit for EFL. Not to diminish ePad, or the
>> development efforts on that. Just clarifying my interests in ecrire and
>> making it for the community vs myself. Though I am scratching my itches
>> first of course.
>>
>> I already have CI and CD via travis setup in the repo I have it now[2],
>> along with Coverity. I plan to merge my branch into master. Not sure if
>> it is easiest to just mirror that back into the enlightment ecrire git
>> repo. I like the release setup I have now. Though long term would like
>> it to be one of the apps on the download page or as an alternative phab
>> list of applications.
>>
>> I am fairly open to what ever work flow, and no rush. Just looking to
>> mention it to others for discussion and to start what ever process if
>> any. Otherwise I will just keep on as is :)
>>
>> 1. https://phab.enlightenment.org/T5411 (some screenshots outdated).
>> 2. https://github.com/Obsidian-StudiosInc/ecrire
>>
> Hi,
>
> Not being a expert on all our tooling, but I believe someone should be
> able to create you a "Probie" account which would give you commit access
> just to the ecrire git repo and might make working within enlightenments
> ecosystem easier, ie you can use the same review tools and enlightenment
> devs will be able to contribute whereas on github we'd all need to
> create pull requests etc.

Nope, probie is not good enough, and we don't do access per repo. We either
trust people with access (to everything) or we don't to anything. I personally
don't like this approach, but it has its advantages.

After that, giving access is as simple as asking anyone with commit access to
add the pubkey and info.txt to the devs git repo.

--
Tom.

--
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] edevelop.slack.com experiment

[Tom Hacohen]

Heya,

I personally think it's a bad idea to rely on a proprietary tool for
open source development, and from what I remember, I'm not the only
one.
This is partially why we self host git and not use Github et al.

Long live IRC.

https://xkcd.com/1782/

--
Tom

On Tue, Mar 21, 2017 at 2:52 PM, Gustavo Sverzut Barbieri
 wrote:
> Hi all,
>
> I'm doing an experiment with slack.com as IRC alternative. I'm no
> expert in slack, first time I ever used, if you have more experience
> let me know so I can add you as admin.
>
> The biggest annoyance at the time is sign up that requires an
> invitation, I sent to some in this list, others can do based on
> domains such as @samsung.com, @osg.samsung.com and so on... but they
> do not allow comcast.net or gmail.com to auto-join.
>
> So if you want to join, let me know your email and I'll send the invitation.
>
> I've added some interesting plugins as people were demanding
> voice/video calls at some point, these 2 can be better than simply
> keeping a google Hangouts open all the time (and night!):
>
>  /appear edevelop
>
> creates an appear.in video/voice chat https://appear.in/edevelop
> just click to join, no app or registration is required. Seems to have
> a 8 person limit.
>
>  /hangout
>
>  creates a hangout invitation link and post to channel, people can
> click to join. Marcel told it also has a limit on video users.
>
> Since we often need to remember people of stuff:
>
>  /remind [@person or #channel] [what] [when]
>  /remind me to drink water at 3pm every day
>  /remind me on June 1st to wish Linda happy birthday
>  /remind #team-alpha to update the project status every Monday at 9am
>  /remind @jessica about the interview in 3 hours
>  /remind @peter tomorrow "Please review the office seating plan"
>
> or:
>
>   /todo @okra fix ephoto!
>   /mytodo help vtorri with ecore-con on win32
>
>
> It can integrate with jenkins as well, but I don't have the permission
> to do that in our jenkins.
>
> So far, the web-browser version is as usable as the app, at least on
> Linux/Chrome, so no install is required. It looks quite nice and also
> provides phone applications (iOS version is very good). I also liked
> that it have built-in "pastebin", just click the "[+]" at the left
> side of the message box to send one.
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
>
> --
> 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: nftables: masquerade sets wrong source address

[Tom Hacohen]

On Thu, Dec 22, 2016 at 4:56 PM, Tom Hacohen <t...@stosb.com> wrote:
>
>
> On 22 Dec 2016 12:35, "Florian Westphal" <f...@strlen.de> wrote:
>
> Tom Hacohen <t...@stosb.com> wrote:
>> I'm sorry for repeating myself, however I'd like to stress out again,
>> that while your workaround fixes an inconsistency between iptables and
>> nftables, the scenario itself is caused by the buggy behaviour of
>> masquerade with "lo", and that needs to be fixed too. The workaround
>> above, and any fixes to that issue will only fix the dropping of the
>> packets, but the wrong rewrite will still be there.
>
> The 'wrong rewrite' also occurs with iptables.
>
> It doesn't cause connectivity issues because in iptables the nat table
> always registers the output hook.
>
> (I agree that nft masquerade should not cause these connectivity issues,
>  but I think proper ruleset fix is to use meta iif to restrict masq to
>  the correct interface(s)).
>
>
> Yes, iptables so misbehaves here. I know you agree about not causing the
> connectivity issues, but don't you agree that the wrong rewrite shouldn't
> happen? For both iptables and nftables?
>
> I already use oif to restrict the masquerade, I'm not trying to solve it for
> myself, because I already have a working workaround. I'm trying to help
> reporting and resolving a bug.
>
> --
> Tom

Resending as plain text.

Yes, iptables so misbehaves here. I know you agree about not causing
the connectivity issues, but don't you agree that the wrong rewrite
shouldn't happen? For both iptables and nftables?

I already use oif to restrict the masquerade, I'm not trying to solve
it for myself, because I already have a working workaround. I'm trying
to help reporting and resolving a bug.

--
Tom
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nftables: masquerade sets wrong source address

[Tom Hacohen]

On Wed, Dec 21, 2016 at 2:39 AM, Liping Zhang <zlpnob...@gmail.com> wrote:
> 2016-12-20 23:16 GMT+08:00 Tom Hacohen <t...@stosb.com>:
>> On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang <zlpnob...@gmail.com> wrote:
>>> According to the explanations in nftables wifi:
>>> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
>>>
>>> You should add the following nft rules(I agree this is tricky and
>>> unfriendly for the end user):
>>> # nft add chain nat prerouting { type nat hook prerouting priority 0 \; }
>>>
>>> But unfortunately,  even if you add the above rule, you will still fail to
>>> connect to a local server.
>>>
>>
>> Correct, doesn't change anything.
>>
>>> Now add another nft rules listed below, you can probably make everything
>>> work fine:
>>> # nft add chain nat output { type nat hook output priority 0 \; }
>>>
>>
>> Haven't tried it. Why would it change things? Have you tried it?
>
> I tried it and it did take effect. But my test scenario may be
> different with yours.
> So can you try it?

Tried it, and it works.

>
> [...]
>>> In iptables, nat output chain always exists, so there's no
>>> such problem.
>>>
>>> But I think that enforcing the user to add a nat output chain
>>> in nftables is not a good idea, so probably we need a following
>>> patch(I only list the ipv4 part):
>>
>> Interesting. Maybe that's why it continued to work after iptables has
>> already been loaded on the box.
>> As said above though, I believe the problem is the masquerade setting
>> the wrong ip, and not (only?)
>> the fact that my setup happens to work with iptables but doesn't with 
>> nftables.
>
> As I analyzed, the main difference is that nat OUTPUT hook always
> exist in iptables, so the reply packet's destination ip address will be 
> modified
> in OUTPUT hook. While in nftables, without nft output chain, the reply 
> packet's
> destination ip address will be modified in PREROUTING hook. Then we try to
> do routing lookup, and the packets will be dropped because the incoming 
> packets'
> destination ip address is 127.0.0.1
>
> But I think that enforcing the user  to add the following nft rule is
> not friendly:
> # nft add chain nat output { type nat hook output priority 0 \; }
>
> This will become more tricky. Do you agree with this?
>
> So I send the related patch to try to improve it.

It's definitely not user friendly to have to add it, especially since
I expected having a chain with no rules to be a noop.
I don't know how nftables works well enough to comment on one design
choice or another, so I can't comment if this needs to be fixed, but
this definitely feels inconsistent and buggy.

I'm sorry for repeating myself, however I'd like to stress out again,
that while your workaround fixes an inconsistency between iptables and
nftables, the scenario itself is caused by the buggy behaviour of
masquerade with "lo", and that needs to be fixed too. The workaround
above, and any fixes to that issue will only fix the dropping of the
packets, but the wrong rewrite will still be there.

Please let me know if there's anything else you'd like me to test.

--
Tom.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: nftables: masquerade sets wrong source address

[Tom Hacohen]

On Sat, Dec 17, 2016 at 2:18 PM, Liping Zhang  wrote:
> According to the explanations in nftables wifi:
> https://wiki.nftables.org/wiki-nftables/index.php/Performing_Network_Address_Translation_(NAT)
>
> You should add the following nft rules(I agree this is tricky and
> unfriendly for the end user):
> # nft add chain nat prerouting { type nat hook prerouting priority 0 \; }
>
> But unfortunately,  even if you add the above rule, you will still fail to
> connect to a local server.
>

Correct, doesn't change anything.

> Now add another nft rules listed below, you can probably make everything
> work fine:
> # nft add chain nat output { type nat hook output priority 0 \; }
>

Haven't tried it. Why would it change things? Have you tried it?

> [ cc netfilter-dev group ]
>
> For loopback connection, the request packets will traverse:
> OUTPUT->POSTROUTING->PREROUTING->INPUT
> and the source ip will be modified in nat POSTROUTING hook.

The problem is that the IP incorrectly changes to the wrong one.

>
> Meanwhile the reply packets will also traverse:
> OUTPUT->POSTROUTING->PREROUTING->INPUT
> and if nat OUTPUT hook exist, the destination ip will be modified
> in it, and re-route will happen. Otherwise, the destination ip will
> be modified at nat PREROUTING hook, and the dst entry will
> be dropped. In such situation(i.e. nat OUTPUT doesn't exist),
> we will try to do routing lookup and packets will be dropped
> at ip_route_input_slow->martian_destination.

I think that all throughout this thread we've been analysing the
behaviour in the broken scenario
instead of just fixing it (which I see your latest patch may actually
do, and that's good).
It doesn't matter where the packet goes through after it's been
wrongly rewritten, the
problem is that it has.

>
> Furthermore, if ipt_rpfilter is configured, the reply packet maybe
> dropped at there.
>

It's off.


> In iptables, nat output chain always exists, so there's no
> such problem.
>
> But I think that enforcing the user to add a nat output chain
> in nftables is not a good idea, so probably we need a following
> patch(I only list the ipv4 part):

Interesting. Maybe that's why it continued to work after iptables has
already been loaded on the box.
As said above though, I believe the problem is the masquerade setting
the wrong ip, and not (only?)
the fact that my setup happens to work with iptables but doesn't with nftables.

Don't you agree?

Thanks,
Tom.

>
> diff --git a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> index f8aad03..5bc9b22 100644
> --- a/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> +++ b/net/ipv4/netfilter/nf_nat_l3proto_ipv4.c
> @@ -344,8 +344,21 @@ nf_nat_ipv4_in(void *priv, struct sk_buff *skb,
>
> ret = nf_nat_ipv4_fn(priv, skb, state, do_chain);
> if (ret != NF_DROP && ret != NF_STOLEN &&
> -   daddr != ip_hdr(skb)->daddr)
> -   skb_dst_drop(skb);
> +   daddr != ip_hdr(skb)->daddr) {
> +   const struct rtable *rt = skb_rtable(skb);
> +   int err;
> +
> +   if (rt) {
> +   if (rt->rt_flags & RTCF_LOCAL) {
> +   err = ip_route_me_harder(state->net, skb,
> +RTN_UNSPEC);
> +   if (err < 0)
> +   ret = NF_DROP_ERR(err);
> +   } else {
> +   skb_dst_drop(skb);
> +   }
> +   }
> +   }
>
> return ret;
>  }
>
>>
>> With this, connections to localhost fail because the masquerade line
>> sets the source IP to that of the wlp1s0 interface, and not of the lo
>> interface.
>>
>> Here is output from the log:
>> IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00
>> SRC=192.168.86.18 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64
>> ID=64500 DF PROTO=TCP SPT=36844 DPT=8000 WINDOW=43690 RES=0x00 SYN
>> URGP=0
>>
>> You can see how the source ip is wrong. This is from running "curl"
>> trying to connect to a local http server on port 8000.
>>
>> Removing the masquerade line, or changing it to: "oifname wlp1s0
>> masquerade" fixes it, but this is just a workaround that will fail in
>> more complex situations.
>>
>> I would have loved to provide you with tracing information, but
>> unfortunately I never got that to work for me.
>>
>> Tried with kernels: 4.8.12 and 4.4.35 on arch linux. Nft version is 0.6.
>>
>> Please let me know if there's any other info you'd like me to provide you 
>> with.
>>
>> Thanks,
>> Tom.
>> --
>> To unsubscribe from this list: send the line "unsubscribe netfilter" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majord...@vger.kernel.org
More 

Re: [E-devel] Eo: static methods or C syntax sugar for class methods?

[Tom Hacohen]

On 20/12/16 11:03, Gustavo Sverzut Barbieri wrote:
> On Mon, Dec 19, 2016 at 11:05 PM, Jean-Philippe André  
> wrote:
>> Hi,
>>
>> On 19 December 2016 at 21:10, Gustavo Sverzut Barbieri 
>> wrote:
>>
>>> Hi all,
>>>
>>> In Efl.Net I've created couple of "constructors" functions to help the
>>> user with common tasks, such as:
>>>
>>
>> Hmm. Sorry to be pedantic, but you've created @class functions, not
>> constructor functions. :)
>>
>> src/lib/ecore_con/efl_net_ip_address.eo:
>>>
>>>- create(port, address)
>>>- create_sockaddr(sockaddr)
>>>- parse(string)
>>>- resolve(string, family, flags) (returns a promise)
>>>
>>> In many languages that's easy to use:
>>>
>>> efl.net.ip_address.create(1234, "127.0.0.1")
>>>
>>> But in C it's a bitch:
>>>
>>>efl_net_ip_address_create(EFL_NET_IP_ADDRESS_CLASS, 1234, "127.0.0.1");
>>>
>>
>> EO constructors would instead be used as follows:
>> efl_add(EFL_NET_IP_ADDRESS_CLASS, NULL, efl_net_ip_address_set(1234,
>> "127.0.0.1"));
>>
>> Not saying it looks any better, really. But that's what constructors are,
>> in EO.
>
> argh... my bad with naming conventions, how should we call what I
> meant? Creators? Factories?
>

Factories most likely.



--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/intel
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 01/01: Eo: remove unreachable code in isa.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=78bbd29720ea21cda59ec96ddba9aa1f165ccba0

commit 78bbd29720ea21cda59ec96ddba9aa1f165ccba0
Author: Tom Hacohen <t...@stosb.com>
Date:   Thu Dec 15 11:18:24 2016 +

Eo: remove unreachable code in isa.

This condition can never be true. It can't be NULL here. A NULL here
would have caused a crash earlier, though it can only be NULL if an
allocation fails, which is something that we don't really handle
for smallish allocations.

CID1366823
---
 src/lib/eo/eo.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index 9cf10d9..9cb8a67 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -1662,7 +1662,6 @@ err_obj:
return EINA_FALSE;
 
 err:
-   if (!data) return EINA_FALSE;
ERR("Object %p is not a valid object in this context: object domain: %d, "
"current domain: %d, local domain: %d, available domains: [%s %s %s 
%s]."
" Are you trying to access this object from another thread?",

-- 

Re: [E-devel] [E-b0rk] Build failed in Jenkins: nightly_efl_gcc_x86_64 #1417

[Tom Hacohen]

On 13/12/16 10:26, Stefan Schmidt wrote:
> Hello.
>
> On 13/12/16 02:15, Gustavo Sverzut Barbieri wrote:
>> Stefan,
>>
>> Could you check the environment where the test runs? In the log
>> https://build.enlightenment.org/job/nightly_efl_gcc_x86_64/ws/src/test-suite.log
>> I see:
>>
>> WARNING: your system miss '::1 localhost' or '::1 localhost6' in /etc/hosts
>> 98%: Checks: 54, Failures: 1, Errors: 0
>> tests/ecore_con/ecore_con_test_efl_net_ip_address.c:1149:F:Efl_Net_Ip_Address:ecore_test_efl_net_ip_address_ipv6_resolve_ok:0:
>> Expected error=0 (success), got 1073741834 (Couldn't resolve host
>> name) resolving=[::1]
>>
>> maybe the machine is not IPv6-enabled? or nswitch.conf disables something?
>
> Not IPv6 enabled. No entry for ::1 in /etc/hosts and no inet6 address or
> such shown with ip a. Beber (cc'ed) is handling the systems. He would
> know why he has IPv6 disabled on them.
>
> While I agree that we should have IPv6 everywhere our tests should still
> work on systems without or do you disagree? I would expect it falls back
> to IPv4. Something we also need to keep in mind are systems without
> internet or even without network. But that is a generic problem for the
> test suite and not really related to your ecore_con revamp.

I think that we are at this point in life that there's no excuse to not 
having IPv6. We shouldn't handle this case in our test suite, but 
instead encourage people to start using it, or at the very least, 
prepare their systems.

--
Tom.


--
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: elementary: atspi accepts UTF-8 text

[Tom Hacohen]

Based on your commit message, your change looks wrong. Atspi accepts 
utf-8 not markup, it should be passed utf-8 without the markup.

I think the code that was there was correct, but furthermore, this code 
was just recently put there to fix an issue, so please speak to whoever 
added it.

Also, please elaborate more in the commit message, it's lacking.

Thanks!

--
Tom

On 08/12/16 14:22, Shinwoo Kim wrote:
> kimcinoo pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=4a8d37195f19c8435c33721fb3fd994783b6a351
>
> commit 4a8d37195f19c8435c33721fb3fd994783b6a351
> Author: Shinwoo Kim 
> Date:   Thu Dec 8 23:21:35 2016 +0900
>
> elementary: atspi accepts UTF-8 text
> ---
>  src/lib/elementary/elm_atspi_bridge.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/src/lib/elementary/elm_atspi_bridge.c 
> b/src/lib/elementary/elm_atspi_bridge.c
> index 237b47c..7d004cd 100644
> --- a/src/lib/elementary/elm_atspi_bridge.c
> +++ b/src/lib/elementary/elm_atspi_bridge.c
> @@ -2078,9 +2078,7 @@ _accessible_property_get(const Eldbus_Service_Interface 
> *interface, const char *
>  ret = elm_interface_atspi_accessible_name_get(obj);
>  if (!ret)
>ret = "";
> -char *plain_text = evas_textblock_text_markup_to_utf8(NULL, ret);
>  eldbus_message_iter_basic_append(iter, 's', ret);
> -free(plain_text);
>  return EINA_TRUE;
>   }
> else if (!strcmp(property, "Description"))
>


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] eo_isa() buggy

[Tom Hacohen]

On 07/12/16 20:18, Gustavo Sverzut Barbieri wrote:
> On Wed, Dec 7, 2016 at 12:00 PM, Tom Hacohen <t...@osg.samsung.com> wrote:
>> Hey,
>>
>> I just pushed 5424cdbd810042ba59e71bec6b8d91cb6a2c3e9c that I hope
>> should fix it. This commit fixes a bug I've known for a while and just
>> forgot to fix. From your description, I believe it is the same issue,
>> but please verify.
>>
>> Thanks for reporting.
>
> great fix, but didn't fix my issue yet. Try with the
> efl_net_dialer_simple_example using SSL:
>
> ./src/examples/ecore/efl_net_dialer_simple_example ssl localhost:1234
>
> This uses:
>
> Efl.Net.Dialer.Ssl -> Efl.Net.Dialer, Efl.Net.Socket.Ssl
>
> Efl.Net.Dialer -> Efl.Net.Socket -> Efl.Io.Reader, Efl.Io.Writer
>
> Efl.Net.Socket.Ssl -> Efl.Loop_User, Efl.Net.Socket -> Efl.Io.Reader,
> Efl.Io.Writer
>
> what's funny is that it works for other complex hierarchies, such as:
>
> Efl.Net.Dialer.Tcp -> Efl.Net.Dialer, Efl.Net.Socket.Tcp
>
> Efl.Net.Socket.Tcp -> Efl.Net.Socket.Fd -> Efl.Loop_Fd. Efl.Net.Socket
> -> Efl.Io.Reader, Efl.Io.Writer
>
> as you can see, it's even more complex since uses Efl.Net.Socket.Fd!
>
>

Are you sure you tested with my fix? I just ran the example and got:

% ./efl_net_dialer_simple_example ssl localhost:1234
INFO: sending 'Hello World!'
INFO: end of stream.
-- BEGIN RECEIVED DATA --
-- END RECEIVED DATA--
INFO: done receiving
^C
INFO: main loop finished.

Looks correct to me.

--
Tom

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] efl-1.16 01/02: Eo gdb: Add workaround for gdb oddities.

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=1a39c10ccbbe9be8e92165268e06329c2ccd2649

commit 1a39c10ccbbe9be8e92165268e06329c2ccd2649
Author: Tom Hacohen <t...@stosb.com>
Date:   Thu Dec 8 11:03:25 2016 +

Eo gdb: Add workaround for gdb oddities.

These workarounds are required to make sure the plugin works across
gdb and python versions.
---
 data/eo/eo_gdb.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index f56be99..c330dc3 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -55,7 +55,7 @@ class Eo_resolve(gdb.Function):
 gdb.Function.__init__(self, 'eo_resolve')
 
 def invoke(self, arg):
-obj_id = int(arg.cast(zero_uintptr_t.type))
+obj_id = int(str(arg.cast(zero_uintptr_t.type)), 0)
 
 mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
 table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
@@ -112,7 +112,7 @@ class Eo_data_get(gdb.Function):
 return null_void_ptr
 
 # Check if not mixin
-if int(kls['desc']['type']) != 3:
+if int(kls['desc']['type'].cast(zero_uintptr_t.type)) != 3:
 return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
   .format(ptr, kls['data_offset']))
 else:

-- 

[EGIT] [core/efl] master 01/01: Eo gdb: Add workaround for gdb oddities.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=874071ca42d59d0870b2f7055c15d878cbdf1368

commit 874071ca42d59d0870b2f7055c15d878cbdf1368
Author: Tom Hacohen <t...@stosb.com>
Date:   Thu Dec 8 11:03:25 2016 +

Eo gdb: Add workaround for gdb oddities.

These workarounds are required to make sure the plugin works across
gdb and python versions.
---
 data/eo/eo_gdb.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index e02dd10..2f86fdc 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -66,7 +66,7 @@ class Eo_resolve(gdb.Function):
 gdb.Function.__init__(self, 'eo_resolve')
 
 def invoke(self, arg):
-obj_id = int(arg.cast(zero_uintptr_t.type))
+obj_id = int(str(arg.cast(zero_uintptr_t.type)), 0)
 
 mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
 table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
@@ -124,7 +124,7 @@ class Eo_data_get(gdb.Function):
 return null_void_ptr
 
 # Check if not mixin
-if int(kls['desc']['type']) != 3:
+if int(kls['desc']['type'].cast(zero_uintptr_t.type)) != 3:
 return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
   .format(ptr, kls['data_offset']))
 else:

-- 

[EGIT] [core/efl] efl-1.16 02/02: Eo gdb: Fix data_get calculation.

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=46d08ae4152210c8aa7a34dd1acea812f68b9bda

commit 46d08ae4152210c8aa7a34dd1acea812f68b9bda
Author: Tom Hacohen <t...@stosb.com>
Date:   Thu Dec 8 11:15:21 2016 +

Eo gdb: Fix data_get calculation.

I forgot to account for the offset from the beginning of the eo object.
---
 data/eo/eo_gdb.py | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index c330dc3..e403bf9 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -113,8 +113,9 @@ class Eo_data_get(gdb.Function):
 
 # Check if not mixin
 if int(kls['desc']['type'].cast(zero_uintptr_t.type)) != 3:
-return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
-  .format(ptr, kls['data_offset']))
+return gdb.parse_and_eval(
+'(void *) (((char *) {}) + _eo_sz + {})'
+.format(ptr, kls['data_offset']))
 else:
 extn_off = ptr['klass']['extn_data_off']
 if int(extn_off) == 0:
@@ -124,8 +125,9 @@ class Eo_data_get(gdb.Function):
 while int(extn_off[i]['klass']) != 0:
 kls = extn_off[i]['klass']
 if kls['desc']['name'].string() == kls_name:
-return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
-  .format(ptr, kls['data_offset']))
+return gdb.parse_and_eval(
+'(void *) (((char *) {}) + _eo_sz + {})'
+.format(ptr, kls['data_offset']))
 i += 1
 
 return null_void_ptr

-- 

Re: [E-devel] eo_isa() buggy

[Tom Hacohen]

Hey,

I just pushed 5424cdbd810042ba59e71bec6b8d91cb6a2c3e9c that I hope 
should fix it. This commit fixes a bug I've known for a while and just 
forgot to fix. From your description, I believe it is the same issue, 
but please verify.

Thanks for reporting.

--
Tom.

On 07/12/16 02:14, Gustavo Sverzut Barbieri wrote:
> eo_isa(o, iface) is buggy as shown with:
>
>   EINA_LOG_LEVELS=eo:4 EFL_RUN_IN_TREE=1 libtool --mode=execute sh
> ./src/scripts/eo/eo_debug
> ./src/examples/ecore/efl_net_dialer_simple_example ssl localhost:1234
>
> It will report Efl_Net_Dialer_Ssl fails efl_isa() with both
> Efl_Io_Reader and Efl_Io_Writer, not in the message but also seems to
> fail Efl_Io_Closer (not a critical error for that usage).
>
> These are declared as:
>
> class Efl.Net.Dialer.Ssl (Efl.Net.Socket.Ssl, Efl.Net.Dialer);
> class Efl.Net.Socket.Ssl (Efl.Loop_User, Efl.Net.Socket);
> interface Efl.Net.Dialer (Efl.Net.Socket);
> interface Efl.Net.Socket (Efl.Io.Reader, Efl.Io.Writer, Efl.Io.Closer);
>
> then both Efl.Net.Socket.Ssl AND Efl.Net.Dialer would lead to these 3
> interfaces.
>
> Log (removed function names to be shorter) also says they are added to
> the methods vtable:
>
> DBG<20851>:eo lib/eo/eo.c:1334 Started building extensions list for
> class 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1366 Finished building extensions list for
> class 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1371 Started building MRO list for class
> 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1382 Finished building MRO list for class
> 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1390 Started building Mixins list for class
> 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1404 Finished building Mixins list for class
> 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1444 Added 'Efl_Io_Writer' extension
> DBG<20851>:eo lib/eo/eo.c:1444 Added 'Efl_Io_Closer' extension
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Net_Socket' to MRO
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Io_Closer' to MRO
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Io_Reader' to MRO
> DBG<20851>:eo lib/eo/eo.c:699 Set functions for class
> 'Efl_Net_Socket':0x556186c12ff0
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53989c40->(nil)
> 'efl_net_socket_address_local_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53989e00->(nil)
> 'efl_net_socket_address_local_set'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53989fa0->(nil)
> 'efl_net_socket_address_remote_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5398a160->(nil)
> 'efl_net_socket_address_remote_set'
> DBG<20851>:eo lib/eo/eo.c:699 Set functions for class
> 'Efl_Net_Socket':0x556186c12ff0
> DBG<20851>:eo lib/eo/eo.c:1535 Finished building class 'Efl_Net_Socket'
> DBG<20851>:eo lib/eo/eo.c:1334 Started building extensions list for
> class 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1366 Finished building extensions list for
> class 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1371 Started building MRO list for class
> 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1382 Finished building MRO list for class
> 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1390 Started building Mixins list for class
> 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1404 Finished building Mixins list for class
> 'Efl_Net_Socket_Ssl'
> DBG<20851>:eo lib/eo/eo.c:1444 Added 'Efl_Net_Socket' extension
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Net_Socket_Ssl' to MRO
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Loop_User' to MRO
> DBG<20851>:eo lib/eo/eo.c:1457 Added 'Efl_Object' to MRO
> DBG<20851>:eo lib/eo/eo.c:699 Set functions for class
> 'Efl_Net_Socket_Ssl':0x556186c134c0
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53c0ed80->0x7fdc539b5220 'efl_constructor'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53c0ef40->0x7fdc539b5270 'efl_destructor'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc53c0f0e0->0x7fdc539b53f0 'efl_finalize'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133f7e0->0x7fdc539b5560
> 'efl_io_closer_close'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133edb0->0x7fdc539b5620
> 'efl_io_closer_closed_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133f2d0->0x7fdc539b5670
> 'efl_io_closer_close_on_exec_set'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133f120->0x7fdc539b56c0
> 'efl_io_closer_close_on_exec_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133f640->0x7fdc539b5710
> 'efl_io_closer_close_on_destructor_set'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc5133f490->0x7fdc539b5750
> 'efl_io_closer_close_on_destructor_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc51340aa0->0x7fdc539b57a0
> 'efl_io_reader_read'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc513405b0->0x7fdc539b5890
> 'efl_io_reader_can_read_set'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc51340400->0x7fdc539b5930
> 'efl_io_reader_can_read_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc51340900->0x7fdc539b5950
> 'efl_io_reader_eos_set'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc51340750->0x7fdc539b5a00
> 'efl_io_reader_eos_get'
> DBG<20851>:eo lib/eo/eo.c:747 0x7fdc513419b0->0x7fdc539b5a20
> 'efl_io_writer_write'
> DBG<20851>:eo lib/eo/eo.c:747 

[EGIT] [core/efl] master 01/01: Eo: Fix efl_isa() sometimes returning wrong results with extensions

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=5424cdbd810042ba59e71bec6b8d91cb6a2c3e9c

commit 5424cdbd810042ba59e71bec6b8d91cb6a2c3e9c
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 13:55:13 2016 +

Eo: Fix efl_isa() sometimes returning wrong results with extensions

This fixes an issue where efl_isa() wouldn't work for extensions or
ancestors of extensions of a class.

Example:
Class A implements interface F2
F2 inherits from interface F1
obj is of class A

Before this patch efl_isa(obj, F1) would return false, now it returns
true as expected.

This is just one example, there is a whole array of variations to this
issue that are now fixed.

Thanks to Gustavo for reminding me of this.

@fix
---
 src/lib/eo/eo.c | 45 +
 src/tests/eo/interface/interface_main.c |  3 +++
 2 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index c4c6a5f..20cf56d 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -228,14 +228,14 @@ _eo_op_class_get(Efl_Object_Op op)
 }
 
 static inline Eina_Bool
-_vtable_func_set(Eo_Vtable *vtable, const _Efl_Class *klass, Efl_Object_Op op, 
Eo_Op_Func_Type func)
+_vtable_func_set(Eo_Vtable *vtable, const _Efl_Class *klass, Efl_Object_Op op, 
Eo_Op_Func_Type func, Eina_Bool allow_same_override)
 {
op_type_funcs *fsrc;
size_t idx1 = DICH_CHAIN1(op);
Dich_Chain1 *chain1 = >chain[idx1];
_vtable_chain_write_prepare(chain1);
fsrc = >chain2->funcs[DICH_CHAIN_LAST(op)];
-   if (fsrc->src == klass)
+   if (!allow_same_override && (fsrc->src == klass))
  {
 const _Efl_Class *op_kls = _eo_op_class_get(op);
 ERR("Class '%s': Overriding already set func %p for op %d (%s) with 
%p.",
@@ -746,7 +746,7 @@ _eo_class_funcs_set(Eo_Vtable *vtable, const Efl_Object_Ops 
*ops, const _Efl_Cla
 
 DBG("%p->%p '%s'", op_desc->api_func, op_desc->func, 
_eo_op_desc_name_get(op_desc));
 
-if (!_vtable_func_set(vtable, klass, op, op_desc->func))
+if (!_vtable_func_set(vtable, klass, op, op_desc->func, EINA_FALSE))
   return EINA_FALSE;
 
 last_api_func = op_desc->api_func;
@@ -1224,6 +1224,25 @@ _eo_class_isa_func(Eo *eo_id EINA_UNUSED, void 
*class_data EINA_UNUSED)
/* Do nonthing. */
 }
 
+static void
+_eo_class_isa_recursive_set(_Efl_Class *klass, const _Efl_Class *cur)
+{
+   const _Efl_Class **extn_itr;
+
+   _vtable_func_set(>vtable, klass, cur->base_id + cur->ops_count,
+ _eo_class_isa_func, EINA_TRUE);
+
+   for (extn_itr = cur->extensions ; *extn_itr ; extn_itr++)
+ {
+_eo_class_isa_recursive_set(klass, *extn_itr);
+ }
+
+   if (cur->parent)
+ {
+_eo_class_isa_recursive_set(klass, cur->parent);
+ }
+}
+
 static inline void
 _eo_classes_release(void)
 {
@@ -1509,25 +1528,7 @@ efl_class_new(const Efl_Class_Description *desc, const 
Efl_Class *parent_id, ...
/* Mark which classes we implement */
if (klass->vtable.size)
  {
-const _Efl_Class **extn_itr;
-
-for (extn_itr = klass->extensions ; *extn_itr ; extn_itr++)
-  {
- const _Efl_Class *extn = *extn_itr;
- /* Set it in the dich. */
- _vtable_func_set(>vtable, klass, extn->base_id +
-   extn->ops_count, _eo_class_isa_func);
-  }
-
-_vtable_func_set(>vtable, klass, klass->base_id + 
klass->ops_count,
-  _eo_class_isa_func);
-
-if (klass->parent)
-  {
- _vtable_func_set(>vtable, klass,
-   klass->parent->base_id + klass->parent->ops_count,
-   _eo_class_isa_func);
-  }
+_eo_class_isa_recursive_set(klass, klass);
  }
 
_eo_class_constructor(klass);
diff --git a/src/tests/eo/interface/interface_main.c 
b/src/tests/eo/interface/interface_main.c
index e9e145b..8f07bb2 100644
--- a/src/tests/eo/interface/interface_main.c
+++ b/src/tests/eo/interface/interface_main.c
@@ -35,6 +35,9 @@ main(int argc, char *argv[])
sum = interface2_ab_sum_get2(obj);
fail_if(sum != a + b + 1);
 
+   fail_if(!efl_isa(obj, INTERFACE_CLASS));
+   fail_if(!efl_isa(obj, INTERFACE2_CLASS));
+
efl_unref(obj);
efl_object_shutdown();
return 0;

-- 

[EGIT] [core/efl] master 02/02: Eo tests: Adjust according to latest commit.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=900b1726e6c8205c8f6c9c74ffa6579e2c15809f

commit 900b1726e6c8205c8f6c9c74ffa6579e2c15809f
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 13:18:41 2016 +

Eo tests: Adjust according to latest commit.
---
 src/tests/eo/suite/eo_test_init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/tests/eo/suite/eo_test_init.c 
b/src/tests/eo/suite/eo_test_init.c
index 9bf0d9b..1f82be4 100644
--- a/src/tests/eo/suite/eo_test_init.c
+++ b/src/tests/eo/suite/eo_test_init.c
@@ -21,7 +21,7 @@ START_TEST(eo_test_init_shutdown)
Eo *obj;
 
fail_if(!efl_object_init());
-   ck_assert_str_eq("Efl_Object", efl_class_name_get(EFL_OBJECT_CLASS));
+   ck_assert_str_eq("Efl.Object", efl_class_name_get(EFL_OBJECT_CLASS));
 
/* XXX-1: Essential for the next test to assign the wrong op. */
obj = efl_add(SIMPLE_CLASS, NULL);
@@ -34,7 +34,7 @@ START_TEST(eo_test_init_shutdown)
fail_if(efl_object_shutdown());
 
fail_if(!efl_object_init());
-   ck_assert_str_eq("Efl_Object", efl_class_name_get(EFL_OBJECT_CLASS));
+   ck_assert_str_eq("Efl.Object", efl_class_name_get(EFL_OBJECT_CLASS));
 
/* XXX-1: Verify that the op was not cached. */
ck_assert_int_eq(0xBEEF, simple2_class_beef_get(SIMPLE2_CLASS));

-- 

[EGIT] [core/efl] efl-1.16 01/02: Eo gdb: Implement eo_data_get to get eo data.

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=7492b67e65b48a7835c5fee671b181803a7e5896

commit 7492b67e65b48a7835c5fee671b181803a7e5896
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 12:33:59 2016 +

Eo gdb: Implement eo_data_get to get eo data.

Like 79d76fb25ece4ffbf5785b4be2b030f062ef9f2c, this is useful when
debugging a core dump.

It accepts a valid pointer to an object, for example as returned from
$eo_resolve, and a name of a class or mixin, and returns a pointer to
the private data. Essentially the same as efl_data_scope_get(), but also
works on core dumps, and accepts a class name instead of a class
pointer.

Usage:
Print the pointer:
 (gdb) print $eo_data_get($eo_resolve(obj), "Efl_Canvas_Object")
 $1 = (void *) 0x55eb9290

Use it directly (e.g. to print a value):
 (gdb) print ((Evas_Object_Protected_Data *) $eo_data_get($eo_resolve(obj),
  "Efl_Canvas_Object"))->last_event_type
 $2 = EVAS_CALLBACK_MOUSE_UP

@feature
---
 data/eo/eo_gdb.py | 49 +
 1 file changed, 49 insertions(+)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index e54797d..6a58a6c 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -81,3 +81,52 @@ class Eo_resolve(gdb.Function):
 
 
 Eo_resolve()
+
+
+class Eo_data_get(gdb.Function):
+def __init__(self):
+gdb.Function.__init__(self, 'eo_data_get')
+
+def invoke(self, ptr, kls_name):
+ptr = ptr.cast(null_ptr.type)  # Make sure it's the right type
+
+if int(ptr) == 0:
+gdb.write('Object is not a valid pointer (NULL).\n')
+return null_ptr
+
+kls_name = kls_name.string()
+extns = ptr['klass']['mro']
+kls = None
+
+i = 0
+while int(extns[i]) != 0:
+if extns[i]['desc']['name'].string() == kls_name:
+kls = extns[i]
+i += 1
+
+if kls is None:
+gdb.write('Class "{}" not found in the object mro.\n'
+  .format(kls_name))
+return null_ptr
+
+# Check if not mixin
+if int(kls['desc']['type']) != 3:
+return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
+  .format(ptr, kls['data_offset']))
+else:
+extn_off = ptr['klass']['extn_data_off']
+if int(extn_off) == 0:
+return null_ptr
+
+i = 0
+while int(extn_off[i]['klass']) != 0:
+kls = extn_off[i]['klass']
+if kls['desc']['name'].string() == kls_name:
+return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
+  .format(ptr, kls['data_offset']))
+i += 1
+
+return null_ptr
+
+
+Eo_data_get()

-- 

[EGIT] [core/efl] efl-1.16 02/02: Eo gdb: Be more strict with types and convert Eo * to uintptr_t.

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=692276ad548eb6d00ffbc399c9af3226574342af

commit 692276ad548eb6d00ffbc399c9af3226574342af
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 12:50:52 2016 +

Eo gdb: Be more strict with types and convert Eo * to uintptr_t.

This should make the results cleaner and also solve potential conversion
issues in some version combinations of gdb and python.
---
 data/eo/eo_gdb.py | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index 6a58a6c..f56be99 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -45,7 +45,9 @@ MASK_GENERATIONS = (MAX_GENERATIONS - 1)
 MASK_OBJ_TAG = (1 << (REF_TAG_SHIFT))
 
 
-null_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+null_void_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+null_eo_object_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+zero_uintptr_t = gdb.parse_and_eval('(uintptr_t) 0')
 
 
 class Eo_resolve(gdb.Function):
@@ -53,7 +55,7 @@ class Eo_resolve(gdb.Function):
 gdb.Function.__init__(self, 'eo_resolve')
 
 def invoke(self, arg):
-obj_id = int(arg)
+obj_id = int(arg.cast(zero_uintptr_t.type))
 
 mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
 table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
@@ -63,19 +65,19 @@ class Eo_resolve(gdb.Function):
 
 if (obj_id == 0) or (tag_bit == 0):
 gdb.write('Pointer is NULL or not a valid object.\n')
-return null_ptr
+return null_eo_object_ptr
 
 entries = 
gdb.parse_and_eval('_eo_ids_tables[{0}]'.format(mid_table_id))
 
 if int(entries) == 0:
 gdb.write('Pointer is not a valid object.\n')
-return null_ptr
+return null_eo_object_ptr
 
 entry = entries[table_id]['entries'][entry_id]
 
 if (not entry['active']) or (int(entry['generation']) != generation):
 gdb.write('Pointer is no longer active.\n')
-return null_ptr
+return null_eo_object_ptr
 
 return entry['ptr']
 
@@ -88,11 +90,11 @@ class Eo_data_get(gdb.Function):
 gdb.Function.__init__(self, 'eo_data_get')
 
 def invoke(self, ptr, kls_name):
-ptr = ptr.cast(null_ptr.type)  # Make sure it's the right type
+ptr = ptr.cast(null_eo_object_ptr.type)  # Cast to correct type
 
 if int(ptr) == 0:
 gdb.write('Object is not a valid pointer (NULL).\n')
-return null_ptr
+return null_void_ptr
 
 kls_name = kls_name.string()
 extns = ptr['klass']['mro']
@@ -107,7 +109,7 @@ class Eo_data_get(gdb.Function):
 if kls is None:
 gdb.write('Class "{}" not found in the object mro.\n'
   .format(kls_name))
-return null_ptr
+return null_void_ptr
 
 # Check if not mixin
 if int(kls['desc']['type']) != 3:
@@ -116,7 +118,7 @@ class Eo_data_get(gdb.Function):
 else:
 extn_off = ptr['klass']['extn_data_off']
 if int(extn_off) == 0:
-return null_ptr
+return null_void_ptr
 
 i = 0
 while int(extn_off[i]['klass']) != 0:
@@ -126,7 +128,7 @@ class Eo_data_get(gdb.Function):
   .format(ptr, kls['data_offset']))
 i += 1
 
-return null_ptr
+return null_void_ptr
 
 
 Eo_data_get()

-- 

[EGIT] [core/efl] master 02/02: Eo gdb: Be more strict with types and convert Eo * to uintptr_t.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=ddf940320dba33e9b3e52aa5ba4ddc1b8ca1c499

commit ddf940320dba33e9b3e52aa5ba4ddc1b8ca1c499
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 12:50:52 2016 +

Eo gdb: Be more strict with types and convert Eo * to uintptr_t.

This should make the results cleaner and also solve potential conversion
issues in some version combinations of gdb and python.
---
 data/eo/eo_gdb.py | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index ec4d21c..e02dd10 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -56,7 +56,9 @@ MASK_GENERATIONS = (MAX_GENERATIONS - 1)
 MASK_OBJ_TAG = (1 << (REF_TAG_SHIFT))
 
 
-null_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+null_void_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+null_eo_object_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+zero_uintptr_t = gdb.parse_and_eval('(uintptr_t) 0')
 
 
 class Eo_resolve(gdb.Function):
@@ -64,7 +66,7 @@ class Eo_resolve(gdb.Function):
 gdb.Function.__init__(self, 'eo_resolve')
 
 def invoke(self, arg):
-obj_id = int(arg)
+obj_id = int(arg.cast(zero_uintptr_t.type))
 
 mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
 table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
@@ -74,20 +76,20 @@ class Eo_resolve(gdb.Function):
 
 if (obj_id == 0) or (tag_bit == 0):
 gdb.write('Pointer is NULL or not a valid object.\n')
-return null_ptr
+return null_eo_object_ptr
 
 entries = gdb.parse_and_eval('_eo_gdb_main_domain->tables[0]->' +
  'eo_ids_tables[{0}]'.format(mid_table_id))
 
 if int(entries) == 0:
 gdb.write('Pointer is not a valid object.\n')
-return null_ptr
+return null_eo_object_ptr
 
 entry = entries[table_id]['entries'][entry_id]
 
 if (not entry['active']) or (int(entry['generation']) != generation):
 gdb.write('Pointer is no longer active.\n')
-return null_ptr
+return null_eo_object_ptr
 
 return entry['ptr']
 
@@ -100,11 +102,11 @@ class Eo_data_get(gdb.Function):
 gdb.Function.__init__(self, 'eo_data_get')
 
 def invoke(self, ptr, kls_name):
-ptr = ptr.cast(null_ptr.type)  # Make sure it's the right type
+ptr = ptr.cast(null_eo_object_ptr.type)  # Cast to correct type
 
 if int(ptr) == 0:
 gdb.write('Object is not a valid pointer (NULL).\n')
-return null_ptr
+return null_void_ptr
 
 kls_name = kls_name.string()
 extns = ptr['klass']['mro']
@@ -119,7 +121,7 @@ class Eo_data_get(gdb.Function):
 if kls is None:
 gdb.write('Class "{}" not found in the object mro.\n'
   .format(kls_name))
-return null_ptr
+return null_void_ptr
 
 # Check if not mixin
 if int(kls['desc']['type']) != 3:
@@ -128,7 +130,7 @@ class Eo_data_get(gdb.Function):
 else:
 extn_off = ptr['klass']['extn_data_off']
 if int(extn_off) == 0:
-return null_ptr
+return null_void_ptr
 
 i = 0
 while int(extn_off[i]['klass']) != 0:
@@ -138,7 +140,7 @@ class Eo_data_get(gdb.Function):
   .format(ptr, kls['data_offset']))
 i += 1
 
-return null_ptr
+return null_void_ptr
 
 
 Eo_data_get()

-- 

[EGIT] [core/efl] master 01/02: Eo gdb: Implement eo_data_get to get eo data.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=5614e46f1f01aa02a779358177907fc08223f3ac

commit 5614e46f1f01aa02a779358177907fc08223f3ac
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Dec 7 12:33:59 2016 +

Eo gdb: Implement eo_data_get to get eo data.

Like 79d76fb25ece4ffbf5785b4be2b030f062ef9f2c, this is useful when
debugging a core dump.

It accepts a valid pointer to an object, for example as returned from
$eo_resolve, and a name of a class or mixin, and returns a pointer to
the private data. Essentially the same as efl_data_scope_get(), but also
works on core dumps, and accepts a class name instead of a class
pointer.

Usage:
Print the pointer:
 (gdb) print $eo_data_get($eo_resolve(obj), "Efl_Canvas_Object")
 $1 = (void *) 0x55eb9290

Use it directly (e.g. to print a value):
 (gdb) print ((Evas_Object_Protected_Data *) $eo_data_get($eo_resolve(obj),
  "Efl_Canvas_Object"))->last_event_type
 $2 = EVAS_CALLBACK_MOUSE_UP

@feature
---
 data/eo/eo_gdb.py | 49 +
 1 file changed, 49 insertions(+)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index 76b8fbd..ec4d21c 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -93,3 +93,52 @@ class Eo_resolve(gdb.Function):
 
 
 Eo_resolve()
+
+
+class Eo_data_get(gdb.Function):
+def __init__(self):
+gdb.Function.__init__(self, 'eo_data_get')
+
+def invoke(self, ptr, kls_name):
+ptr = ptr.cast(null_ptr.type)  # Make sure it's the right type
+
+if int(ptr) == 0:
+gdb.write('Object is not a valid pointer (NULL).\n')
+return null_ptr
+
+kls_name = kls_name.string()
+extns = ptr['klass']['mro']
+kls = None
+
+i = 0
+while int(extns[i]) != 0:
+if extns[i]['desc']['name'].string() == kls_name:
+kls = extns[i]
+i += 1
+
+if kls is None:
+gdb.write('Class "{}" not found in the object mro.\n'
+  .format(kls_name))
+return null_ptr
+
+# Check if not mixin
+if int(kls['desc']['type']) != 3:
+return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
+  .format(ptr, kls['data_offset']))
+else:
+extn_off = ptr['klass']['extn_data_off']
+if int(extn_off) == 0:
+return null_ptr
+
+i = 0
+while int(extn_off[i]['klass']) != 0:
+kls = extn_off[i]['klass']
+if kls['desc']['name'].string() == kls_name:
+return gdb.parse_and_eval('(void *) (((char *) {}) + {})'
+  .format(ptr, kls['data_offset']))
+i += 1
+
+return null_ptr
+
+
+Eo_data_get()

-- 

[EGIT] [core/efl] master 01/01: Static deps unibreak: Update to latest version.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=abb7310506ce825404788b7674f2bf3961c9df45

commit abb7310506ce825404788b7674f2bf3961c9df45
Author: Tom Hacohen <t...@stosb.com>
Date:   Tue Dec 6 12:45:40 2016 +

Static deps unibreak: Update to latest version.

This version supports Unicode 9.0 and includes many fixes.
Reference git hash: fe1ce2e78c19fa2b4b7a92b1864a12b432da6ec6

This version is not yet released, but now is a better time to sync it,
and there are no code changes expected, only "admin" work.

Main changes:
Unicode 9.0 support
Many fixes in the lineberaking algorithm to now pass the Unicode
reference test data.

@feature
---
 src/static_libs/libunibreak/AUTHORS |   2 +
 src/static_libs/libunibreak/ChangeLog   | 165 
 src/static_libs/libunibreak/linebreak.c | 192 +++-
 src/static_libs/libunibreak/linebreak.h |  10 +-
 src/static_libs/libunibreak/linebreakdata.c | 176 +++--
 src/static_libs/libunibreak/linebreakdef.c  |  10 +-
 src/static_libs/libunibreak/linebreakdef.h  |  25 ++--
 src/static_libs/libunibreak/wordbreak.c |  71 +-
 src/static_libs/libunibreak/wordbreakdata.c |  97 --
 src/static_libs/libunibreak/wordbreakdef.h  |   5 +
 10 files changed, 627 insertions(+), 126 deletions(-)

diff --git a/src/static_libs/libunibreak/AUTHORS 
b/src/static_libs/libunibreak/AUTHORS
index 1b4f4b4..34b5c9a 100644
--- a/src/static_libs/libunibreak/AUTHORS
+++ b/src/static_libs/libunibreak/AUTHORS
@@ -9,3 +9,5 @@ Thomas Klausner.  Autoconfiscated and libtoolized liblinebreak.
 Tom Hacohen.  Added word boundaries support.
 
 Petr Filipsky.  Added incremental processing for line-breaking.
+
+Andreas Röver. Added grapheme boundaries support.
diff --git a/src/static_libs/libunibreak/ChangeLog 
b/src/static_libs/libunibreak/ChangeLog
index f6c4a3d..cad33cf 100644
--- a/src/static_libs/libunibreak/ChangeLog
+++ b/src/static_libs/libunibreak/ChangeLog
@@ -1,3 +1,168 @@
+2016-12-04  Wu Yongwei  <wuyong...@gmail.com>
+
+   Simpify implementation about RI pairing.
+   * src/linebreak.c (treat_first_char): Get rid of the special
+   processing in the first character.
+   (get_lb_result_lookup): Refactor implementation.
+
+2016-12-03  Wu Yongwei  <wuyong...@gmail.com>
+
+   * tools/test.txt: Make a statement more precise.
+
+2016-12-03  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreak.c (get_lb_result_lookup): Simplify code and fix a
+   corner case about LB21a.
+   (treat_first_char): There is no need to treat first character of
+   Hebrew specially now.
+
+2016-12-03  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreakdef.h (struct LineBreakContext): Add new field
+   cLb30aRI.
+   * src/linebreak.c (lb_init_break_context): Initialize cLb30aRI.
+   (treat_first_char): Deal with leading RI.
+   (get_lb_result_lookup): Count RI characters and allow breaking
+   between each pair occurrence.
+
+2016-12-03  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreak.c (baTable): Fix a few missing entries.
+
+2016-12-03  Wu Yongwei  <wuyong...@gmail.com>
+
+   Fix test failure regarding Object Replacement Character (U+FFFC).
+   * src/linebreakdef.h (enum LineBreakClass): Move LBP_CB so that it
+   can be included in the pair table.
+   * src/linebreak.c (baTable): Add break action about LBP_CB.
+   (treat_first_char): Remove customization about LBP_CB.
+   (get_lb_result_simple): Ditto.
+   (get_lb_result_lookup): Change assertion about the maximum valid
+   baTable index.
+
+2016-11-29  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreak.c (ends_with): New static function.
+   (ENDS_WITH): New macro.
+   (resolve_lb_class): Use ENDS_WITH to make the code cleaner.
+
+2016-11-28  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreak.c (resolve_lb_class): Resolve LBP_CJ to LBP_NS if
+   lang ends with "-strict".
+   * src/tests.c: Use "-strict" in line breaking test.
+
+2016-11-26  Wu Yongwei  <wuyong...@gmail.com>
+
+   * .clang-format: `Modernize' the clang-format configuration with
+   Clang 3.8.
+
+2016-11-26  Wu Yongwei  <wuyong...@gmail.com>
+
+   * src/linebreak.c (get_lb_result_lookup): Fix an issue that
+   combining marks are not correctly dealt with.
+
+2016-11-23  Tom Hacohen  <t...@stosb.com>
+
+   * src/wordbreak.c (set_wordbreaks): Fix to pass the test suite.
+
+2016-11-22  Andreas Röver  <roe...@users.sf.net>
+
+   Add grapheme breaking support.
+   * AUTHORS: Add `Andreas Röver'.
+   * src/Makefile.am (include_HEADERS): Add header files for grapheme
+   breaking.
+   (libunibreak_la_SO

Re: [E-devel] [EGIT] [core/efl] master 03/03: eo: if EO_DEBUG, check if efl_super() object 'isa' the given class.

[Tom Hacohen]

This is wrong, and as JP and Stefan said, breaks things. First of all, 
why add code to the non-debug variation? Also, if you're already adding 
to the non-debug variation, why not include it in the commit message? 
This is very misleading.

Anyhow, as the tests clearly show, efl_super() is also used with class 
functions, so it needs to work. The efl_isa() line should work on 
classes too (I think), but the is_object is plain-wrong, and definitely 
shouldn't be outside the ifdef, but also not inside. It just doesn't 
belong there.

Furthermore, while I'm all in favour of this test in the eo_debug 
scenario, I disagree with the statement in the commit message. If you 
have such mistakes you are doing something very wrong, because the 
recommended way of using efl_super is with the macro "MY_CLASS" that 
should be defined to the current relevant class in the source file in 
order to avoid such mistakes as you described...

--
Tom.

On 02/12/16 16:51, Gustavo Sverzut Barbieri wrote:
> barbieri pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=04450c4ee03fd20271ec4f911667acea10ba1375
>
> commit 04450c4ee03fd20271ec4f911667acea10ba1375
> Author: Gustavo Sverzut Barbieri 
> Date:   Fri Dec 2 14:49:06 2016 -0200
>
> eo: if EO_DEBUG, check if efl_super() object 'isa' the given class.
>
> A common error is to copy & paste efl_super() calls and forget to fix
> the class. If usin EO_DEBUG, then use efl_isa() to error.
> ---
>  src/lib/eo/eo.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
> index 9719034..e86f052 100644
> --- a/src/lib/eo/eo.c
> +++ b/src/lib/eo/eo.c
> @@ -318,6 +318,11 @@ efl_super(const Eo *obj, const Efl_Class *cur_klass)
>  {
> EO_CLASS_POINTER_GOTO(cur_klass, klass, err);
>
> +   if (EINA_UNLIKELY(!_eo_is_a_obj(obj))) goto err_obj;
> +#ifdef EO_DEBUG
> +   if (EINA_UNLIKELY(!efl_isa(obj, cur_klass))) goto err_obj_hierarchy;
> +#endif
> +
> /* FIXME: Switch to atomic operations intead of lock. */
> eina_spinlock_take(&_super_class_lock);
> _super_class = klass;
> @@ -326,6 +331,14 @@ efl_super(const Eo *obj, const Efl_Class *cur_klass)
>  err:
> _EO_POINTER_ERR("Class (%p) is an invalid ref.", cur_klass);
> return NULL;
> +err_obj:
> +   _EO_POINTER_ERR("Object (%p) is an invalid ref, class=%p (%s).", obj, 
> cur_klass, efl_class_name_get(cur_klass));
> +   return NULL;
> +#ifdef EO_DEBUG
> +err_obj_hierarchy:
> +   _EO_POINTER_ERR("Object (%p) class=%p (%s) is not an instance of class=%p 
> (%s).", obj, efl_class_get(obj), efl_class_name_get(obj), cur_klass, 
> efl_class_name_get(cur_klass));
> +#endif
> +   return NULL;
>  }
>
>  EAPI Eina_Bool
>


--
___
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/05: Eo: Add efl_replace() function.

[Tom Hacohen]

I never liked the stringshare function that does it, so it comes with no 
surprise that I don't like this one either.

Regardless of that, I find the name very confusing. I didn't understand 
what it does when I saw the name nor when I read the docs. I had to read 
the code to understand what it's for... I'd change the name and fix the 
docs.

--
Tom.

On 02/12/16 17:35, Guilherme Iscaro wrote:
> bdilly pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=81782414dfba9a8a69ea42a4dd5b01fc19170d88
>
> commit 81782414dfba9a8a69ea42a4dd5b01fc19170d88
> Author: Guilherme Iscaro 
> Date:   Fri Dec 2 11:16:33 2016 -0200
>
> Eo: Add efl_replace() function.
>
> This new function adds a new way to safely replace Eo pointer values.
> ---
>  src/lib/eo/Eo.h | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
> index 8c81544..244478b 100644
> --- a/src/lib/eo/Eo.h
> +++ b/src/lib/eo/Eo.h
> @@ -1334,6 +1334,28 @@ EAPI int efl_callbacks_cmp(const 
> Efl_Callback_Array_Item *a, const Efl_Callback_
>   EFL_CALLBACK_PRIORITY_DEFAULT, data)
>
>  /**
> + * @def Replace the previously Eo pointer with new content.
> + *
> + * @param storage The object to replace the old reference. It can not be @c 
> NULL.
> + * @param new_obj The new object. It may be @c NULL.
> + *
> + * The string pointed by @c storage must be previously an Eo or
> + * @c NULL and it will be efl_unref(). The @a new_obj will be passed
> + * to efl_ref() and then assigned to @c *storage.
> + *
> + * @see efl_ref()
> + * @see efl_unref()
> + */
> +static inline void
> +efl_replace(Eo **storage, Eo *new_obj)
> +{
> +   if (!storage || *storage == new_obj) return;
> +   efl_ref(new_obj);
> +   efl_unref(*storage);
> +   *storage = new_obj;
> +}
> +
> +/**
>   * @}
>   */
>
>


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

[EGIT] [core/efl] master 01/01: Emacs config: Also remove from extra_dist.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=3302ce54998ab66adeddbe273cf105309061a809

commit 3302ce54998ab66adeddbe273cf105309061a809
Author: Tom Hacohen <t...@stosb.com>
Date:   Mon Dec 5 12:35:40 2016 +

Emacs config: Also remove from extra_dist.
---
 data/Makefile.am | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/data/Makefile.am b/data/Makefile.am
index 8645929..ce13137 100644
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -73,9 +73,6 @@ mimedir = $(datadir)/mime/packages
 mime_DATA = edje/edje.xml
 EXTRA_DIST += $(mime_DATA)
 
-EXTRA_DIST += \
-edje/edje-mode.el
-
 # Helper for people using EDJ
 include ../src/Makefile_Edje_Helper.am
 

-- 

[EGIT] [editors/emacs-configs] master 01/01: Initial import for emacs config files.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/emacs-configs.git/commit/?id=aa190cb127749c90392b7b1288758ba0ee422b95

commit aa190cb127749c90392b7b1288758ba0ee422b95
Author: Tom Hacohen <t...@stosb.com>
Date:   Mon Dec 5 12:34:21 2016 +

Initial import for emacs config files.
---
 edje-mode.el | 513 +++
 eo-mode.el   | 398 +
 2 files changed, 911 insertions(+)

diff --git a/edje-mode.el b/edje-mode.el
new file mode 100644
index 000..b0d8602
--- /dev/null
+++ b/edje-mode.el
@@ -0,0 +1,513 @@
+;;; edje-mode-el -- Major mode for editing Edje files
+
+;; Author: Gustavo Sverzut Barbieri <barbi...@gmail.com>
+;; Created: 2007-07-23
+;; Keywords: Edje major-mode
+;; Url: http://barbieri-playground.googlecode.com/svn/dot-files/edje-mode.el
+;;  (if you find this file have problems, check that Url and request 
update)
+
+;; Copyright (C) 2007 Gustavo Sverzut Barbieri <barbi...@gmail.com>
+
+;; This program is free software; you can redistribute it and/or
+;; modify it under the terms of the GNU General Public License as
+;; published by the Free Software Foundation; either version 2 of
+;; the License, or (at your option) any later version.
+
+;; This program is distributed in the hope that it will be
+;; useful, but WITHOUT ANY WARRANTY; without even the implied
+;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
+;; PURPOSE.  See the GNU General Public License for more details.
+
+;; You should have received a copy of the GNU General Public
+;; License along with this program; if not, write to the Free
+;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+;; MA 02111-1307 USA
+
+;;; Commentary:
+;;
+;; This mode is based on tutorial from Scott Andrew Borton:
+;; http://two-wugs.net/emacs/mode-tutorial.html
+
+
+(defvar edje-mode-hook nil)
+
+(defun number-or-nil-to-string (v  default)
+  (cond ((numberp v) (number-to-string v))
+((stringp v) (if (string= v "") (number-to-string default) v))
+(t   (number-to-string default
+
+(defun non-empty-string (s)
+  (and (not (eq 'nil s))
+   (not (string= "" s
+
+(defun edje-new-program-action-signal-emit (source emission)
+  "Insert new program SIGNAL_EMIT"
+  (interactive "ssource: \nsemission: ")
+  (insert
+   (concat
+"   action: SIGNAL_EMIT \"" source "\" \"" emission "\";\n"
+)))
+
+(defun edje-new-program-action-state-set (state value target)
+  "Insert new program STATE_SET"
+  (interactive "sstate: \nsvalue (0.0): \nstarget: ")
+  (insert
+   (concat
+"   action: STATE_SET \"" state "\" "
+   (number-or-nil-to-string value 0.0) ";\n"
+"   target: \"" target "\";\n"
+)))
+
+(defun edje-new-program-action (action)
+  "Insert new program action"
+  (interactive "saction: ")
+  (setq action (upcase action))
+  (cond ((string= action "STATE_SET")
+ (edje-new-program-action-state-set "" 0.0 ""))
+((string= action "SIGNAL_EMIT")
+ (edje-new-program-action-signal-emit "" ""))
+))
+
+(defun edje-new-program (name signal source action)
+  "Insert new program block"
+  (interactive "sname: \nssignal: \nssource: \nsaction: ")
+  (insert
+   (concat
+"\n"
+"program {\n"
+"   name: \"" name "\";\n"
+
+(if (non-empty-string signal)
+(concat "   signal: \"" signal "\";\n"))
+
+(if (non-empty-string source)
+(concat "   source: \"" source "\";\n"))
+))
+
+  (edje-new-program-action action)
+
+  (insert
+   (concat
+"}\n"
+"\n"
+)))
+
+(defun edje-new-desc-relative (x y  defx defy)
+  "Insert new part description 'relative' line"
+  (interactive "sx: \nsy: ")
+  (insert
+   (concat
+"  relative: "
+(number-or-nil-to-string x defx) " "
+(number-or-nil-to-string y defy) ";\n"
+)))
+
+(defun edje-new-desc-offset (x y  defx defy)
+  "Insert new part description 'offset' line"
+  (interactive "sx: \nsy: ")
+  (insert
+   (concat
+"  offset: "
+(number-or-nil-to-string x defx) " "
+(number-or-nil-to-string y defy) ";\n"
+)))
+
+(defun edje-new-desc-inherit (name val)
+  "Insert new part description 'inherit' line"
+  (interactive "sname: \nsvalue: ")
+  (insert
+   (concat
+&qu

[EGIT] [core/efl] master 01/01: Emacs configs: Move to designated repo.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=92f8e013eaa62da6658556924f9a08cf31c75565

commit 92f8e013eaa62da6658556924f9a08cf31c75565
Author: Tom Hacohen <t...@stosb.com>
Date:   Mon Dec 5 12:34:43 2016 +

Emacs configs: Move to designated repo.
---
 data/edje/edje-mode.el | 513 -
 data/eo/eo-mode.el | 398 --
 2 files changed, 911 deletions(-)

diff --git a/data/edje/edje-mode.el b/data/edje/edje-mode.el
deleted file mode 100644
index b0d8602..000
--- a/data/edje/edje-mode.el
+++ /dev/null
@@ -1,513 +0,0 @@
-;;; edje-mode-el -- Major mode for editing Edje files
-
-;; Author: Gustavo Sverzut Barbieri <barbi...@gmail.com>
-;; Created: 2007-07-23
-;; Keywords: Edje major-mode
-;; Url: http://barbieri-playground.googlecode.com/svn/dot-files/edje-mode.el
-;;  (if you find this file have problems, check that Url and request 
update)
-
-;; Copyright (C) 2007 Gustavo Sverzut Barbieri <barbi...@gmail.com>
-
-;; This program is free software; you can redistribute it and/or
-;; modify it under the terms of the GNU General Public License as
-;; published by the Free Software Foundation; either version 2 of
-;; the License, or (at your option) any later version.
-
-;; This program is distributed in the hope that it will be
-;; useful, but WITHOUT ANY WARRANTY; without even the implied
-;; warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
-;; PURPOSE.  See the GNU General Public License for more details.
-
-;; You should have received a copy of the GNU General Public
-;; License along with this program; if not, write to the Free
-;; Software Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-;; MA 02111-1307 USA
-
-;;; Commentary:
-;;
-;; This mode is based on tutorial from Scott Andrew Borton:
-;; http://two-wugs.net/emacs/mode-tutorial.html
-
-
-(defvar edje-mode-hook nil)
-
-(defun number-or-nil-to-string (v  default)
-  (cond ((numberp v) (number-to-string v))
-((stringp v) (if (string= v "") (number-to-string default) v))
-(t   (number-to-string default
-
-(defun non-empty-string (s)
-  (and (not (eq 'nil s))
-   (not (string= "" s
-
-(defun edje-new-program-action-signal-emit (source emission)
-  "Insert new program SIGNAL_EMIT"
-  (interactive "ssource: \nsemission: ")
-  (insert
-   (concat
-"   action: SIGNAL_EMIT \"" source "\" \"" emission "\";\n"
-)))
-
-(defun edje-new-program-action-state-set (state value target)
-  "Insert new program STATE_SET"
-  (interactive "sstate: \nsvalue (0.0): \nstarget: ")
-  (insert
-   (concat
-"   action: STATE_SET \"" state "\" "
-   (number-or-nil-to-string value 0.0) ";\n"
-"   target: \"" target "\";\n"
-)))
-
-(defun edje-new-program-action (action)
-  "Insert new program action"
-  (interactive "saction: ")
-  (setq action (upcase action))
-  (cond ((string= action "STATE_SET")
- (edje-new-program-action-state-set "" 0.0 ""))
-((string= action "SIGNAL_EMIT")
- (edje-new-program-action-signal-emit "" ""))
-))
-
-(defun edje-new-program (name signal source action)
-  "Insert new program block"
-  (interactive "sname: \nssignal: \nssource: \nsaction: ")
-  (insert
-   (concat
-"\n"
-"program {\n"
-"   name: \"" name "\";\n"
-
-(if (non-empty-string signal)
-(concat "   signal: \"" signal "\";\n"))
-
-(if (non-empty-string source)
-(concat "   source: \"" source "\";\n"))
-))
-
-  (edje-new-program-action action)
-
-  (insert
-   (concat
-"}\n"
-"\n"
-)))
-
-(defun edje-new-desc-relative (x y  defx defy)
-  "Insert new part description 'relative' line"
-  (interactive "sx: \nsy: ")
-  (insert
-   (concat
-"  relative: "
-(number-or-nil-to-string x defx) " "
-(number-or-nil-to-string y defy) ";\n"
-)))
-
-(defun edje-new-desc-offset (x y  defx defy)
-  "Insert new part description 'offset' line"
-  (interactive "sx: \nsy: ")
-  (insert
-   (concat
-"  offset: "
-(number-or-nil-to-string x defx) " "
-(number-or-nil-to-string y defy) ";\n"
-)))
-
-(defun edje-new-desc-inherit (name val)
-  "Insert new part description 'inherit' line"
-  (interactive "sname: \nsvalue: ")
-  (insert

[EGIT] [core/efl] efl-1.16 02/02: Eo gdb: add a way to resolve Eo ids from GDB without a running process

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=34efbca16e954d994a26d730753b8fbd1d4a37ec

commit 34efbca16e954d994a26d730753b8fbd1d4a37ec
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Nov 18 08:44:21 2016 +

Eo gdb: add a way to resolve Eo ids from GDB without a running process

This is a backport of 79d76fb25ece4ffbf5785b4be2b030f062ef9f2c.

Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.

This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.

Usage:
 Print the pointer:
 (gdb) print $eo_resolve(obj)
 $1 = (_Eo_Object *) 0x559bbe70

 Use it directly (e.g. to print the class name):
 (gdb) $eo_resolve(obj)->klass->desc.name

This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.

@feature
---
 data/eo/eo_gdb.py | 83 +--
 1 file changed, 81 insertions(+), 2 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index 2191210..e54797d 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -1,4 +1,83 @@
-# Implement eo_break that'll break on a macro/subid/whatever.
-
 import gdb
 
+"""
+All of this script relies heavily on Eo internals and will break if they
+change. Need to make sure this is always in sync.
+"""
+
+ptr_size = int(gdb.parse_and_eval('sizeof(void *)'))
+
+if ptr_size == 4:
+# 32 bits
+BITS_MID_TABLE_ID = 5
+BITS_TABLE_ID = 5
+BITS_ENTRY_ID = 12
+BITS_GENERATION_COUNTER = 9
+REF_TAG_SHIFT = 31
+DROPPED_TABLES = 0
+DROPPED_ENTRIES = 4
+else:
+# 64 bits
+BITS_MID_TABLE_ID = 11
+BITS_TABLE_ID = 11
+BITS_ENTRY_ID = 12
+BITS_GENERATION_COUNTER = 29
+REF_TAG_SHIFT = 63
+DROPPED_TABLES = 2
+DROPPED_ENTRIES = 3
+
+# /* Shifts macros to manipulate the Eo id */
+SHIFT_MID_TABLE_ID = (BITS_TABLE_ID + BITS_ENTRY_ID + BITS_GENERATION_COUNTER)
+SHIFT_TABLE_ID = (BITS_ENTRY_ID + BITS_GENERATION_COUNTER)
+SHIFT_ENTRY_ID = (BITS_GENERATION_COUNTER)
+
+# /* Maximum ranges */
+MAX_MID_TABLE_ID = (1 << BITS_MID_TABLE_ID)
+MAX_TABLE_ID = ((1 << BITS_TABLE_ID) - DROPPED_TABLES)
+MAX_ENTRY_ID = ((1 << BITS_ENTRY_ID) - DROPPED_ENTRIES)
+MAX_GENERATIONS = (1 << BITS_GENERATION_COUNTER)
+
+# /* Masks */
+MASK_MID_TABLE_ID = (MAX_MID_TABLE_ID - 1)
+MASK_TABLE_ID = ((1 << BITS_TABLE_ID) - 1)
+MASK_ENTRY_ID = ((1 << BITS_ENTRY_ID) - 1)
+MASK_GENERATIONS = (MAX_GENERATIONS - 1)
+MASK_OBJ_TAG = (1 << (REF_TAG_SHIFT))
+
+
+null_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+
+
+class Eo_resolve(gdb.Function):
+def __init__(self):
+gdb.Function.__init__(self, 'eo_resolve')
+
+def invoke(self, arg):
+obj_id = int(arg)
+
+mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
+table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
+entry_id = (obj_id >> SHIFT_ENTRY_ID) & MASK_ENTRY_ID
+tag_bit = (obj_id) & MASK_OBJ_TAG
+generation = obj_id & MASK_GENERATIONS
+
+if (obj_id == 0) or (tag_bit == 0):
+gdb.write('Pointer is NULL or not a valid object.\n')
+return null_ptr
+
+entries = 
gdb.parse_and_eval('_eo_ids_tables[{0}]'.format(mid_table_id))
+
+if int(entries) == 0:
+gdb.write('Pointer is not a valid object.\n')
+return null_ptr
+
+entry = entries[table_id]['entries'][entry_id]
+
+if (not entry['active']) or (int(entry['generation']) != generation):
+gdb.write('Pointer is no longer active.\n')
+return null_ptr
+
+return entry['ptr']
+
+
+Eo_resolve()

-- 

[EGIT] [core/efl] efl-1.16 01/02: Eo gdb: remove old and broken gdb macro.

[Tom Hacohen]

tasn pushed a commit to branch efl-1.16.

http://git.enlightenment.org/core/efl.git/commit/?id=0a278f566ab60bd63da02670937c4c4b11ff8052

commit 0a278f566ab60bd63da02670937c4c4b11ff8052
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Nov 18 07:31:39 2016 +

Eo gdb: remove old and broken gdb macro.
---
 data/eo/eo_gdb.py | 39 ---
 1 file changed, 39 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index aafe881..2191210 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -2,42 +2,3 @@
 
 import gdb
 
-def symbol_equal_to_string(symbol, string):
-   return (symbol != None) and (symbol.name == string)
-
-class Eo_step(gdb.Command):
-   STEP_LIMIT = 10
-   def __init__(self):
-  gdb.Command.__init__(self, "eo_step", gdb.COMMAND_OBSCURE)
-  self.START_FUNC = "_eo_call_resolve"
-  self.SKIP_FUNC = "_eo_do_start"
-
-   def invoke (self, arg, from_tty):
-  # Get to the call resolve function.
-  i = 0
-  while not symbol_equal_to_string(gdb.selected_frame().function(), 
self.START_FUNC):
- if symbol_equal_to_string(gdb.selected_frame().function(), 
self.SKIP_FUNC):
-gdb.execute("finish", False, to_string=True)
-
- if i > Eo_step.STEP_LIMIT:
- break
- else:
- i += 1
- gdb.execute("step", False, to_string=True)
-
-  # If we found the function, return from it, otherwise, fail.
-  if symbol_equal_to_string(gdb.selected_frame().function(), 
self.START_FUNC):
- gdb.execute("finish", False, to_string=True)
-  else:
- print("Search limit reached, you tried calling eo_step too far from 
an eo_do.")
- return
-
-  # Step until we move to a different function. FIXME: The hook can 
confuse us, needs to be solved.
-  cur_func = gdb.selected_frame().function()
-  while gdb.selected_frame().function() == cur_func:
- gdb.execute("stepi", False, to_string=True)
-
-  # One last call to skip into the implementation
-  gdb.execute("step", True)
-
-Eo_step()

-- 

[EGIT] [core/efl] master 01/01: Eo gdb: Remove redundant variable setting.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=0431dd24fd971149878ccbfb48c87f500d9b027c

commit 0431dd24fd971149878ccbfb48c87f500d9b027c
Author: Tom Hacohen <t...@stosb.com>
Date:   Mon Dec 5 12:06:20 2016 +

Eo gdb: Remove redundant variable setting.

These were hardcoded values I used for debugging, they are not used anymore,
they are instead calculated at runtime.
---
 data/eo/eo_gdb.py | 9 -
 1 file changed, 9 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index 995aff4..76b8fbd 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -7,15 +7,6 @@ change. Need to make sure this is always in sync.
 
 ptr_size = int(gdb.parse_and_eval('sizeof(void *)'))
 
-SHIFT_MID_TABLE_ID = 0x30
-MASK_MID_TABLE_ID = 0x7ff
-SHIFT_TABLE_ID = 0x25
-MASK_TABLE_ID = 0x7ff
-SHIFT_ENTRY_ID = 0x1a
-MASK_ENTRY_ID = 0x7ff
-MASK_GENERATIONS = 0x3ff
-MASK_OBJ_TAG = 0x4000
-
 if ptr_size == 4:
 # 32 bits
 BITS_MID_TABLE_ID = 5

-- 

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

On 23/11/16 11:45, Daniel Bünzli wrote:

On Wednesday 23 November 2016 at 12:28, Tom Hacohen wrote:

I took a look at the ICU sources, and they explicitly mention this case,
so it seems I was mistaken with interpreting the intention of the UAX. I
still find it confusing, but based on this thread, it seems to just be me.


It's not only you, I also sometimes get confused by it (see for example [1] and 
subsequent messages). Maybe the operational model could be clarified a bit.


The comment I quoted from the ICU sources clarifies the intention. Maybe 
a comment similar to one would be helpful?


Also, thinking about it a bit more, the operational order makes sense 
when you consider the CR LF case and extended characters, however it is 
still not obvious from the wording.


Thanks again.

--
Tom.

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

On 23/11/16 11:20, Philippe Verdy wrote:

2016-11-23 12:00 GMT+01:00 Tom Hacohen <t...@osg.samsung.com
<mailto:t...@osg.samsung.com>>:


Also take another look at
http://www.unicode.org/reports/tr29/#Grapheme_Cluster_and_Format_Rules
<http://www.unicode.org/reports/tr29/#Grapheme_Cluster_and_Format_Rules>
specifically the table that shows another way of writing the ignore
rule. This again shows my understanding of rule 4 is correct.

Specially look at the following equivalence:
X Y × Z W   ⇒   X (Extend | Format)* Y (Extend | Format)* ×
Z (Extend | Format)* W


This expansion does not occur before rule WB4; it cannot be used to
transform rules WB1 to WB3c; this is explicitly stated in the algorithm.
And because the rule WB3c handles your case, you are misinterpreting the
specs as if it was applying there too...



I took a look at the ICU sources, and they explicitly mention this case, 
so it seems I was mistaken with interpreting the intention of the UAX. I 
still find it confusing, but based on this thread, it seems to just be me.


Sorry for the noise.

The comment from the ICU source code:
# Rule 3c   ZWJ x (Extended_Pict | EmojiNRK).  Precedes WB4, so no 
intervening Extend chars allowed.


Thanks for your help,
Tom

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

On 23/11/16 11:11, Daniel Bünzli wrote:


On Wednesday 23 November 2016 at 12:00, Tom Hacohen wrote:

This looks like a mistake statement rather than a binding rule.

Well at least to me it's pretty clear that this is not the case.



Even if that's true, look at my second statement (which you redacted in
your reply):


I'm not arguing whether the boundaries produced by this process is good or not. 
I'm just saying that to me, the test data is consistent with the operational 
model and rules of UAX#29 as it exists.


I'm arguing it's not, and I still don't agree with your understanding of 
the operational model, again, take a look at what I wrote in my last email:


Also take another look at 
http://www.unicode.org/reports/tr29/#Grapheme_Cluster_and_Format_Rules 
specifically the table that shows another way of writing the ignore 
rule. This again shows my understanding of rule 4 is correct.


Specially look at the following equivalence:
X Y × Z W ⇒ X (Extend | Format)* Y (Extend | Format)* × Z 
(Extend | Format)* W


--
Tom

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

On 23/11/16 10:52, Daniel Bünzli wrote:

On Wednesday 23 November 2016 at 11:22, Tom Hacohen wrote:

Thank you for your reply, but I don't think the UAX, specifically the
line you quoted implies that. The line you quoted says that the process
is terminated when a rule matches and produces a boundary status. In
Table 1[1], the right-arrow (which is used in rule 4) is listed as a
boundary symbol,


Precisely, rules with this *symbol* do not produce a boundary *status* which is 
either boundary or not boundary as mentioned in parens in the line I quoted.


This looks like a mistake statement rather than a binding rule.




so I would argue that one should stop the process and start it again from the 
start.


At least in the current UAX there is no mention of an idea of stopping and 
restarting the process at all.


Even if that's true, look at my second statement (which you redacted in 
your reply):


Furthermore, in the clarification to rule 4[2] it clearly states: "The 
main purpose of this rule is to always treat a grapheme cluster as a 
single character—that is, as if it were simply the first character of 
the cluster".

This again sides with my understanding that:
X Extendend Y
should behave exactly the same as
X Y
after the extended part.
Which is exactly what I'm arguing for.


Also take another look at 
http://www.unicode.org/reports/tr29/#Grapheme_Cluster_and_Format_Rules 
specifically the table that shows another way of writing the ignore 
rule. This again shows my understanding of rule 4 is correct.


Specially look at the following equivalence:
X Y × Z W 	⇒ 	X (Extend | Format)* Y (Extend | Format)* × Z (Extend | 
Format)* W


--
Tom

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

On 23/11/16 10:01, Daniel Bünzli wrote:

On Tuesday 22 November 2016 at 13:07, Tom Hacohen wrote:

However, looking at the test case and the UAX[2], this does not look
correct. More specifically, because of rule 4:
ZWJ Extended GAZ -> ZWJ GAZ
And then according to rule 3c, there should be no break opportunity
between them.


I'd say this is not the right operational model. From [1]:

"The rules are processed from top to bottom. As soon as a rule matches and produces 
a boundary status (boundary or no boundary) for that offset, the process is 
terminated."

So in this case between COMBINING DIAERESIS and HEAVY BLACK HEART rule WB4 
quicks in. It does not produce a boundary status, it only changes your offset 
context to ZWJ GAZ, as you mention. Now you continue applying the rules 
sequentially with WB6 which does not match, with WB7 which does not match,... 
and you'll get to WB999 which matches and produces a boundary status.

After WB4 you do not restart the matching process from the beginning, as you 
do, leading you to say that WB3c should apply.


Hey Daniel,

Thank you for your reply, but I don't think the UAX, specifically the 
line you quoted implies that. The line you quoted says that the process 
is terminated when a rule matches and produces a boundary status. In 
Table 1[1], the right-arrow (which is used in rule 4) is listed as a 
boundary symbol, so I would argue that one should stop the process and 
start it again from the start.


Furthermore, in the clarification to rule 4[2] it clearly states: "The 
main purpose of this rule is to always treat a grapheme cluster as a 
single character—that is, as if it were simply the first character of 
the cluster".

This again sides with my understanding that:
X Extendend Y
should behave exactly the same as
X Y
after the extended part.
Which is exactly what I'm arguing for.

--
Tom

[1] http://www.unicode.org/reports/tr29/#Table_Boundary_Symbols
[2] http://www.unicode.org/reports/tr29/#Grapheme_Cluster_and_Format_Rules

Re: Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

You said:
> So ignore it and test whever the last symbols glues with ZWJ (it should,
> so there's no break in the reference implementation).

Which makes me think you misread the example I quoted. There is a break 
in the reference implementation, though I argue (like you just did) that 
there shouldn't be. So I think you agree with me and also think it's broken.


Otherwise, I'm not sure I fully understand what you are saying, but if 
what you are saying is correct, then following the same logic, other 
rules would fail, specifically:


÷ 0061 × 2060 × 0030 ÷  #  ÷ [0.2] LATIN SMALL LETTER A (ALetter) × 
[4.0] WORD JOINER (Format_FE) × [9.0] DIGIT ZERO (Numeric) ÷ [0.3]


After the FE here there's no BREAK because:
ALetter Format Numeric -> ALetter Numeric
Which then following rule 9.0 is a no-break.

This is exactly the rule (4) as described in my previous email, just 
with a different follow-up rule (9 instead of 3c). I don't see how rule 
precedence would matter here, as there is no case for which two rules apply.


--
Tom.

On 23/11/16 02:49, Philippe Verdy wrote:

IMHO, the ZWJ should glue with the last symbol following your examples.
But the combining diaeresis following the ZWJ extends it (even if in my
opinion it is "defective" and would likely display on a dotted ciurcle
in renderers, but not defective for the string definition of combining
sequences).
So ignore it and test whever the last symbols glues with ZWJ (it should,
so there's no break in the reference implementation).

WB4: X (Extend | Format | ZWJ)*→X

Extend: [ExtendGrapheme_Extend=Yes]  This includes:
  General_Category = Nonspacing_Mark (this includes the combining diaeresis)
  General_Category = Enclosing_Mark
  U+200C ZERO WIDTH NON-JOINER
  plus a few General_Category = Spacing_Mark needed for canonical
equivalence.

So yes we have: ZWJ "COMBINING DIERESIS" (EBG|Glue_After_Zwj) → ZWJ
(EBG|Glue_After_Zwj) from rule WB4 eliminate the combining mark from the
input queue

But rule WB3c comes before and prohibits it:

WB3c: ZWJ × (Glue_After_Zwj | EBG)

This means that you have first:

ZWJ "COMBINING DIERESIS" GAZ →  ZWJ × "COMBINING DIERESIS" EBG

and this does not match the rule WB4 which is not matching for:

X × (Extend | Format | ZWJ)*→X

(it cannot remove the extenders if there's a no-break before them, it is
valid only when the break oppotunity is still unspecified. As soon as a
rule as produced a "break here" or "nobreak here" at a given position,
you must advance after this position (the rules are based on a small
finite state machine). So after :

ZWJ "COMBINING DIERESIS" GAZ →  ZWJ × "COMBINING DIERESIS" EBG

it just remains in your input queue:

"COMBINING DIERESIS" EBG  (because "ZWJ ×" is already processed, and so
ZWJ is elminated)

Now comes WB4: X (Extend | Format | ZWJ)* → X

There's no more any "X" to match before the combining diaeresis: your
input queue starts by the combining diareasis matching "X", the
following character (EBG) does not match within "(Extend | Format |
ZWJ)*" (which matches an empty string and does not contain the combining
diaresis already matched in "X"), rule WB4 has then no replacement
effect and preserves the initial "X" (i.e. the combining diaeresis)

.







2016-11-22 13:07 GMT+01:00 Tom Hacohen <t...@osg.samsung.com
<mailto:t...@osg.samsung.com>>:

Dear,

I recently updated libunibreak[1] according to unicode 9.0.0. I
thought I implemented it correctly, however it fails against two of
the tests in the reference test data:

÷ 200D × 0308 ÷ 2764 ÷ #  ÷ [0.2] ZERO WIDTH JOINER (ZWJ_FE) × [4.0]
COMBINING DIAERESIS (Extend_FE) ÷ [999.0] HEAVY BLACK HEART
(Glue_After_Zwj) ÷ [0.3]

and

÷ 200D × 0308 ÷ 1F466 ÷ #  ÷ [0.2] ZERO WIDTH JOINER (ZWJ_FE) ×
[4.0] COMBINING DIAERESIS (Extend_FE) ÷ [999.0] BOY (EBG) ÷ [0.3]


More specifically, it fails in both after the "combining diaeresis".
My implementation marks it as a break, whereas the test data as not.
The reference implementation, as expected, agrees with the test data.


However, looking at the test case and the UAX[2], this does not look
correct. More specifically, because of rule 4:
ZWJ Extended GAZ -> ZWJ GAZ
And then according to rule 3c, there should be no break opportunity
between them. The reference implementation, however, uses rule 999
here, which I believe is incorrect.


Am I missing anything, or is this an issue with the reference test
data and reference implementation?

Thanks,
Tom.

[1]: https://github.com/adah1972/libunibreak
<https://github.com/adah1972/libunibreak>
[2]: http://www.unicode.org/reports/tr29/#WB1
<http://www.unicode.org/reports/tr29/#WB1>

Potential contradiction between the WordBreak test data and UAX #29

[Tom Hacohen]

Dear,

I recently updated libunibreak[1] according to unicode 9.0.0. I thought 
I implemented it correctly, however it fails against two of the tests in 
the reference test data:


÷ 200D × 0308 ÷ 2764 ÷ #  ÷ [0.2] ZERO WIDTH JOINER (ZWJ_FE) × [4.0] 
COMBINING DIAERESIS (Extend_FE) ÷ [999.0] HEAVY BLACK HEART 
(Glue_After_Zwj) ÷ [0.3]


and

÷ 200D × 0308 ÷ 1F466 ÷ #  ÷ [0.2] ZERO WIDTH JOINER (ZWJ_FE) × [4.0] 
COMBINING DIAERESIS (Extend_FE) ÷ [999.0] BOY (EBG) ÷ [0.3]



More specifically, it fails in both after the "combining diaeresis". My 
implementation marks it as a break, whereas the test data as not. The 
reference implementation, as expected, agrees with the test data.



However, looking at the test case and the UAX[2], this does not look 
correct. More specifically, because of rule 4:

ZWJ Extended GAZ -> ZWJ GAZ
And then according to rule 3c, there should be no break opportunity 
between them. The reference implementation, however, uses rule 999 here, 
which I believe is incorrect.



Am I missing anything, or is this an issue with the reference test data 
and reference implementation?


Thanks,
Tom.

[1]: https://github.com/adah1972/libunibreak
[2]: http://www.unicode.org/reports/tr29/#WB1

[EGIT] [core/efl] master 01/02: Eo gdb: remove old and broken gdb macro.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=3dd51bf53de9003e0e3ba396a5c0f2b10c44c1fd

commit 3dd51bf53de9003e0e3ba396a5c0f2b10c44c1fd
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Nov 18 07:31:39 2016 +

Eo gdb: remove old and broken gdb macro.
---
 data/eo/eo_gdb.py | 39 ---
 1 file changed, 39 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index aafe881..2191210 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -2,42 +2,3 @@
 
 import gdb
 
-def symbol_equal_to_string(symbol, string):
-   return (symbol != None) and (symbol.name == string)
-
-class Eo_step(gdb.Command):
-   STEP_LIMIT = 10
-   def __init__(self):
-  gdb.Command.__init__(self, "eo_step", gdb.COMMAND_OBSCURE)
-  self.START_FUNC = "_eo_call_resolve"
-  self.SKIP_FUNC = "_eo_do_start"
-
-   def invoke (self, arg, from_tty):
-  # Get to the call resolve function.
-  i = 0
-  while not symbol_equal_to_string(gdb.selected_frame().function(), 
self.START_FUNC):
- if symbol_equal_to_string(gdb.selected_frame().function(), 
self.SKIP_FUNC):
-gdb.execute("finish", False, to_string=True)
-
- if i > Eo_step.STEP_LIMIT:
- break
- else:
- i += 1
- gdb.execute("step", False, to_string=True)
-
-  # If we found the function, return from it, otherwise, fail.
-  if symbol_equal_to_string(gdb.selected_frame().function(), 
self.START_FUNC):
- gdb.execute("finish", False, to_string=True)
-  else:
- print("Search limit reached, you tried calling eo_step too far from 
an eo_do.")
- return
-
-  # Step until we move to a different function. FIXME: The hook can 
confuse us, needs to be solved.
-  cur_func = gdb.selected_frame().function()
-  while gdb.selected_frame().function() == cur_func:
- gdb.execute("stepi", False, to_string=True)
-
-  # One last call to skip into the implementation
-  gdb.execute("step", True)
-
-Eo_step()

-- 

[EGIT] [core/efl] master 02/02: Eo gdb: add a way to resolve Eo ids from GDB without a running process

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=79d76fb25ece4ffbf5785b4be2b030f062ef9f2c

commit 79d76fb25ece4ffbf5785b4be2b030f062ef9f2c
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Nov 18 08:44:21 2016 +

Eo gdb: add a way to resolve Eo ids from GDB without a running process

Normally when debugging Eo with gdb you can just use any of the internal
eo functions to resolve the id to its internal pointer. However, when
loading a coredump you can't execute any code, not even the id resolve
code.

This change adds a gdb function that resolves the id to its pointer form
without executing any code in the process space. This plugin is
essentially the id resolve code written in python as a gdb function.

Usage:
 Print the pointer:
 (gdb) print $eo_resolve(obj)
 $1 = (_Eo_Object *) 0x559bbe70

 Use it directly (e.g. to print the class name):
 (gdb) $eo_resolve(obj)->klass->desc.name

This plugin requires that the coredump would be loaded with the exact
same libeo.so binary (or at least one that hasn't changed eo internals),
and that the debug symbols for libeo.so would be available for gdb to
use.

Note:
This feature is incomplete and only resolves IDs that are owned by the
main thread and in the main domain. This is not a big issue at the
moment, because almost all of our IDs are like that.

@feature
---
 data/eo/eo_gdb.py | 104 --
 src/lib/eo/eo.c   |   6 
 2 files changed, 108 insertions(+), 2 deletions(-)

diff --git a/data/eo/eo_gdb.py b/data/eo/eo_gdb.py
index 2191210..995aff4 100644
--- a/data/eo/eo_gdb.py
+++ b/data/eo/eo_gdb.py
@@ -1,4 +1,104 @@
-# Implement eo_break that'll break on a macro/subid/whatever.
-
 import gdb
 
+"""
+All of this script relies heavily on Eo internals and will break if they
+change. Need to make sure this is always in sync.
+"""
+
+ptr_size = int(gdb.parse_and_eval('sizeof(void *)'))
+
+SHIFT_MID_TABLE_ID = 0x30
+MASK_MID_TABLE_ID = 0x7ff
+SHIFT_TABLE_ID = 0x25
+MASK_TABLE_ID = 0x7ff
+SHIFT_ENTRY_ID = 0x1a
+MASK_ENTRY_ID = 0x7ff
+MASK_GENERATIONS = 0x3ff
+MASK_OBJ_TAG = 0x4000
+
+if ptr_size == 4:
+# 32 bits
+BITS_MID_TABLE_ID = 5
+BITS_TABLE_ID = 5
+BITS_ENTRY_ID = 11
+BITS_GENERATION_COUNTER = 6
+BITS_DOMAIN = 2
+BITS_CLASS = 1
+REF_TAG_SHIFT = 30
+SUPER_TAG_SHIFT = 31
+DROPPED_TABLES = 0
+DROPPED_ENTRIES = 4
+else:
+# 64 bits
+BITS_MID_TABLE_ID = 11
+BITS_TABLE_ID = 11
+BITS_ENTRY_ID = 11
+BITS_GENERATION_COUNTER = 26
+BITS_DOMAIN = 2
+BITS_CLASS = 1
+REF_TAG_SHIFT = 62
+SUPER_TAG_SHIFT = 63
+DROPPED_TABLES = 2
+DROPPED_ENTRIES = 3
+
+# /* Shifts macros to manipulate the Eo id */
+SHIFT_DOMAIN = (BITS_MID_TABLE_ID + BITS_TABLE_ID +
+BITS_ENTRY_ID + BITS_GENERATION_COUNTER)
+SHIFT_MID_TABLE_ID = (BITS_TABLE_ID +
+  BITS_ENTRY_ID + BITS_GENERATION_COUNTER)
+SHIFT_TABLE_ID = (BITS_ENTRY_ID + BITS_GENERATION_COUNTER)
+SHIFT_ENTRY_ID = (BITS_GENERATION_COUNTER)
+
+# /* Maximum ranges */
+MAX_DOMAIN = (1 << BITS_DOMAIN)
+MAX_MID_TABLE_ID = (1 << BITS_MID_TABLE_ID)
+MAX_TABLE_ID = ((1 << BITS_TABLE_ID) - DROPPED_TABLES)
+MAX_ENTRY_ID = ((1 << BITS_ENTRY_ID) - DROPPED_ENTRIES)
+MAX_GENERATIONS = (1 << BITS_GENERATION_COUNTER)
+
+# /* Masks */
+MASK_DOMAIN = (MAX_DOMAIN - 1)
+MASK_MID_TABLE_ID = (MAX_MID_TABLE_ID - 1)
+MASK_TABLE_ID = ((1 << BITS_TABLE_ID) - 1)
+MASK_ENTRY_ID = ((1 << BITS_ENTRY_ID) - 1)
+MASK_GENERATIONS = (MAX_GENERATIONS - 1)
+MASK_OBJ_TAG = (1 << (REF_TAG_SHIFT))
+
+
+null_ptr = gdb.parse_and_eval('(_Eo_Object *) 0')
+
+
+class Eo_resolve(gdb.Function):
+def __init__(self):
+gdb.Function.__init__(self, 'eo_resolve')
+
+def invoke(self, arg):
+obj_id = int(arg)
+
+mid_table_id = (obj_id >> SHIFT_MID_TABLE_ID) & MASK_MID_TABLE_ID
+table_id = (obj_id >> SHIFT_TABLE_ID) & MASK_TABLE_ID
+entry_id = (obj_id >> SHIFT_ENTRY_ID) & MASK_ENTRY_ID
+tag_bit = (obj_id) & MASK_OBJ_TAG
+generation = obj_id & MASK_GENERATIONS
+
+if (obj_id == 0) or (tag_bit == 0):
+gdb.write('Pointer is NULL or not a valid object.\n')
+return null_ptr
+
+entries = gdb.parse_and_eval('_eo_gdb_main_domain->tables[0]->' +
+ 'eo_ids_tables[{0}]'.format(mid_table_id))
+
+if int(entries) == 0:
+gdb.write('Pointer is not a valid object.\n')
+return null_ptr
+
+entry = entries[table_id]['entries'][entry_id]
+
+if (not entry['active']) or (int(entry['generation']) != generation):
+gdb.write('Pointer is no long

Re: [E-devel] [EGIT] [core/enlightenment] master 02/03: Merge branch 'master' of git+ssh://git.enlightenment.org/core/enlightenment

[Tom Hacohen]

I was away, so the reply is a bit late, but: you should "git log" or 
better yet: "git log --graph" before you push to make sure it does what 
you intended.

Furthermore, always do "git pull --rebase", not "git pull". You can 
change this as a setting.

--
Tom.

On 02/11/16 11:50, Stephen Houston wrote:
> Bahhh. Thought I did rebase. My bad. Git and I are still working on our
> relationship.
>
> On Wed, Nov 2, 2016, 3:41 AM Stefan Schmidt  wrote:
>
>> Hello.
>>
>> On 01/11/16 20:21, Stephen okra Houston wrote:
>>> okra pushed a commit to branch master.
>>>
>>>
>> http://git.enlightenment.org/core/enlightenment.git/commit/?id=722ef6442630a5598bec8ec55bb3d309518f7440
>>>
>>> commit 722ef6442630a5598bec8ec55bb3d309518f7440
>>> Merge: 7304758 4d86c98
>>> Author: Stephen okra Houston 
>>> Date:   Tue Nov 1 13:28:33 2016 -0500
>>>
>>> Merge branch 'master' of git+ssh://
>> git.enlightenment.org/core/enlightenment
>>
>> Let me remind you that we do not do merges. The only exception is fast
>> forward merge commits for a bigger patch series. This merge commit needs
>> to have a good commit message describing the whole series though.
>>
>> To me this looks more as if you merge a branch you worked in into master
>> without rebasing. Please avoid this in the future.
>>
>> regards
>> Stefan Schmidt
>>
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>>
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> 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] EDD 2017 location discussion

[Tom Hacohen]

On 01/11/16 10:51, Stefan Schmidt wrote:
> Hello.
>
> On 01/11/16 11:19, Tom Hacohen wrote:
>> And London, we can probably get hosting at the London hackspace, if not,
>> there are more options. With the pound as low as it is, it's going to be
>> like going to a 3rd world countries for you all. :P
>
> Pretty sure London will just raise the prices even more when the pound
> keeps falling and falling.
>
> If you (or someone else) are standing up as local organiser and the
> meeting location at the hackerspace can get confirmed I see this as an
> valid option. If these two are sorted out it should get added to the
> wiki page.

As you know, I'm going travelling a bit starting from early in the 
morning tomorrow, so I won't have any time to check.

I think this should probably be a two step process.

1. Choose where we want to go.
2. Verifying it can be done before we fully commit.

By the time it's decided I'll already be back and will be able to 
confirm the hackspace and any other "organisation" that may be required.

--
Tom.

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] EDD 2017 location discussion

[Tom Hacohen]

And London, we can probably get hosting at the London hackspace, if not, 
there are more options. With the pound as low as it is, it's going to be 
like going to a 3rd world countries for you all. :P

--
Tom


On 01/11/16 10:16, Andrew Williams wrote:
> I forgot to add Edinburgh to the list.
> I'm happy to organise and I think CodeBase (the tech incubator I am in)
> will provide event space if we book far enough ahead.
>
> I'll update phab,
> Andy
> On Tue, 1 Nov 2016 at 10:11, Tom Hacohen <t...@osg.samsung.com> wrote:
>
>> On 01/11/16 09:58, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> Thinking ahead about EDD 2017 it would be good if we could settle for a
>>> location towards the end of the year.
>>>
>>> After this years EDD I already asked for location proposals which have
>>> been collected here:
>>> https://phab.enlightenment.org/w/events/location_proposals/
>>>
>>> I will put out a phab vote for it over the next weeks but wanted to
>>> bring it up here for discussion to sort out valid and likely proposals
>>> from the rest.
>>>
>>> Here we go with the list and my comments on it:
>>>
>>> Australia (proposed by David Seikel)
>>> * Local organiser: None
>>> * Meeting space offering: None
>>>
>>> + Nice country to visit
>>> - To high travel costs for almost all attendees
>>> - Unlikely to attract many community people without company baking
>>> - No local organiser or meeting space proposed
>>>
>>>
>>> Malta (proposed by Jonathan Aquilina)
>>> * Local organiser: Jonathan Aquilina
>>> * Meeting space offering: None
>>>
>>> + Within Europe
>>> + Travel costs for people from Europe might/should be ok (tourist
>> flights)
>>> - Not sure how easy it it to get there from outside of the EU (VISA, etc)
>>> - Meeting space offering is missing
>>>
>>>
>>> USA (proposed by Stephen Houston)
>>> * Local organiser: Stephen Houston
>>> * Meeting space offering: None
>>>
>>> o USA is big. Would this be east middle or west?
>>> + We have a bunch of developers from there
>>> - To high travel costs for many attendees
>>> - We did it once on the west coast and sadly almost only people with
>>> company baking attended
>>> - Meeting space offering is missing
>>>
>>>
>>> Tel Aviv (proposed by Tom Hacohen)
>>> * Local organiser: None
>>> * Meeting space offering: None
>>>
>>> - No local organiser or meeting space (Originally there was Samsung
>>> Israel listed here but as far as I understand that would not be possible)
>>>
>>>
>>> Paris (proposed by Nicolas Aguirre)
>>> * Local organiser: Nicolas Aguirre
>>> * Meeting space offering: OpenWide office
>>>
>>> + Within Europe
>>> + Served us very well this year
>>> + Organiser and meeting space available
>>>
>>>
>>> Toulouse (proposed by Nicolas Aguirre)
>>> * Local organiser: Nicolas Aguirre
>>> * Meeting space offering: OpenWide office
>>>
>>> + Within Europe
>>> + Organiser and meeting space available
>>>
>>>
>>> Seoul (proposed by Hermet Park)
>>> * Local organiser: Hermet Park
>>> * Meeting space offering: Somewhere in Seoul
>>>
>>> - To high travel costs for almost all non-company attendees
>>> - Unlikely to attract many community people without company baking
>>> + Would give a lot local Samsung EFL developers the chance to attend
>>> + Organiser and meeting space available
>>
>> I don't think I proposed Israel, but anyhow, local organiser would be
>> JackDanielZ, and surely we could find a place if needed...
>>
>> My take: australia, us and korea are probably very unlikely.
>>
>> Malta sounds like the best idea.
>>
>> --
>> Tom.
>>
>>
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> enlightenment-devel mailing list
>> enlightenment-devel@lists.sourceforge.net
>> https://lists.sourceforge.n

Re: [E-devel] EDD 2017 location discussion

[Tom Hacohen]

On 01/11/16 09:58, Stefan Schmidt wrote:
> Hello.
>
> Thinking ahead about EDD 2017 it would be good if we could settle for a
> location towards the end of the year.
>
> After this years EDD I already asked for location proposals which have
> been collected here:
> https://phab.enlightenment.org/w/events/location_proposals/
>
> I will put out a phab vote for it over the next weeks but wanted to
> bring it up here for discussion to sort out valid and likely proposals
> from the rest.
>
> Here we go with the list and my comments on it:
>
> Australia (proposed by David Seikel)
> * Local organiser: None
> * Meeting space offering: None
>
> + Nice country to visit
> - To high travel costs for almost all attendees
> - Unlikely to attract many community people without company baking
> - No local organiser or meeting space proposed
>
>
> Malta (proposed by Jonathan Aquilina)
> * Local organiser: Jonathan Aquilina
> * Meeting space offering: None
>
> + Within Europe
> + Travel costs for people from Europe might/should be ok (tourist flights)
> - Not sure how easy it it to get there from outside of the EU (VISA, etc)
> - Meeting space offering is missing
>
>
> USA (proposed by Stephen Houston)
> * Local organiser: Stephen Houston
> * Meeting space offering: None
>
> o USA is big. Would this be east middle or west?
> + We have a bunch of developers from there
> - To high travel costs for many attendees
> - We did it once on the west coast and sadly almost only people with
> company baking attended
> - Meeting space offering is missing
>
>
> Tel Aviv (proposed by Tom Hacohen)
> * Local organiser: None
> * Meeting space offering: None
>
> - No local organiser or meeting space (Originally there was Samsung
> Israel listed here but as far as I understand that would not be possible)
>
>
> Paris (proposed by Nicolas Aguirre)
> * Local organiser: Nicolas Aguirre
> * Meeting space offering: OpenWide office
>
> + Within Europe
> + Served us very well this year
> + Organiser and meeting space available
>
>
> Toulouse (proposed by Nicolas Aguirre)
> * Local organiser: Nicolas Aguirre
> * Meeting space offering: OpenWide office
>
> + Within Europe
> + Organiser and meeting space available
>
>
> Seoul (proposed by Hermet Park)
> * Local organiser: Hermet Park
> * Meeting space offering: Somewhere in Seoul
>
> - To high travel costs for almost all non-company attendees
> - Unlikely to attract many community people without company baking
> + Would give a lot local Samsung EFL developers the chance to attend
> + Organiser and meeting space available

I don't think I proposed Israel, but anyhow, local organiser would be 
JackDanielZ, and surely we could find a place if needed...

My take: australia, us and korea are probably very unlikely.

Malta sounds like the best idea.

--
Tom.


--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

[EGIT] [core/efl] master 02/02: Input events cache: use the new mechanism to reuse eo objects.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f2e049c81853d4f1a57b61d57688248c3da4

commit f2e049c81853d4f1a57b61d57688248c3da4
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Oct 28 13:20:56 2016 +0100

Input events cache: use the new mechanism to reuse eo objects.
---
 src/lib/evas/canvas/efl_input_pointer.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/lib/evas/canvas/efl_input_pointer.c 
b/src/lib/evas/canvas/efl_input_pointer.c
index 2214871..68c13bc 100644
--- a/src/lib/evas/canvas/efl_input_pointer.c
+++ b/src/lib/evas/canvas/efl_input_pointer.c
@@ -34,6 +34,7 @@ _del_hook(Eo *evt)
  efl_ref(evt);
  efl_parent_set(evt, NULL);
   }
+efl_reuse(evt);
 s_cached_event = evt;
  }
else

-- 

[EGIT] [core/efl] master 01/02: Eo: Add a method to mark objects for reuse.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f736946d10d519fe959bef84914e4ca3d91e7db8

commit f736946d10d519fe959bef84914e4ca3d91e7db8
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Oct 28 13:19:10 2016 +0100

Eo: Add a method to mark objects for reuse.

This informas eo an object is going to get reused/cached, so eo can
reset the object appropriately.

@feature.
---
 src/lib/eo/Eo.h  | 11 +++
 src/lib/eo/eo.c  |  9 -
 src/lib/eo/eo_base_class.c   |  4 ++--
 src/lib/eo/eo_private.h  |  2 +-
 src/tests/eo/suite/eo_test_general.c | 21 +
 5 files changed, 43 insertions(+), 4 deletions(-)

diff --git a/src/lib/eo/Eo.h b/src/lib/eo/Eo.h
index 4ca0713..8c81544 100644
--- a/src/lib/eo/Eo.h
+++ b/src/lib/eo/Eo.h
@@ -1097,6 +1097,17 @@ EAPI void efl_del_intercept_set(Eo *obj, 
Efl_Del_Intercept del_intercept_func);
 EAPI Efl_Del_Intercept efl_del_intercept_get(const Eo *obj);
 
 /**
+ * @brief Clears the object so it can be reused (for example in a cache)
+ * @param obj The object to mark for reusal
+ *
+ * This assumes the destructor has been called on the object, so it
+ * should probably only be used from the del intercept.
+ *
+ * @see efl_del_intercept_set()
+ */
+EAPI void efl_reuse(const Eo *obj);
+
+/**
  * @def efl_xref(obj, ref_obj)
  * Convenience macro around efl_xref_internal()
  * @see efl_xref()
diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index ad8306d..1da4566 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -856,7 +856,7 @@ _efl_add_end(Eo *eo_id, Eina_Bool is_ref, Eina_Bool 
is_fallback)
   {
  efl_ref(eo_id);
   }
-_efl_object_parent_sink(eo_id);
+_efl_object_parent_sink_set(eo_id, EINA_TRUE);
  }
 
if (is_fallback)
@@ -867,6 +867,13 @@ _efl_add_end(Eo *eo_id, Eina_Bool is_ref, Eina_Bool 
is_fallback)
return ret;
 }
 
+EAPI void
+efl_reuse(const Eo *_obj)
+{
+   Eo *obj = (Eo *) _obj;
+   efl_object_override(obj, NULL);
+   _efl_object_parent_sink_set(obj, EINA_FALSE);
+}
 /*/
 
 EAPI const Efl_Class *
diff --git a/src/lib/eo/eo_base_class.c b/src/lib/eo/eo_base_class.c
index c79d213..5ef3509 100644
--- a/src/lib/eo/eo_base_class.c
+++ b/src/lib/eo/eo_base_class.c
@@ -535,10 +535,10 @@ _efl_object_del(const Eo *obj, Efl_Object_Data *pd 
EINA_UNUSED)
 }
 
 void
-_efl_object_parent_sink(Eo *obj)
+_efl_object_parent_sink_set(Eo *obj, Eina_Bool sink)
 {
Efl_Object_Data *pd = efl_data_scope_get(obj, EFL_OBJECT_CLASS);
-   pd->parent_sunk = EINA_TRUE;
+   pd->parent_sunk = sink;
 }
 
 EOLIAN static void
diff --git a/src/lib/eo/eo_private.h b/src/lib/eo/eo_private.h
index 035d84c..99f667a 100644
--- a/src/lib/eo/eo_private.h
+++ b/src/lib/eo/eo_private.h
@@ -196,7 +196,7 @@ typedef struct
int line;
 } Eo_Xref_Node;
 
-void _efl_object_parent_sink(Eo *obj);
+void _efl_object_parent_sink_set(Eo *obj, Eina_Bool sink);
 
 static inline
 Eo *_eo_header_id_get(const Eo_Header *header)
diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index bb34b7d..b956eae 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -1230,6 +1230,12 @@ _del_intercept(Eo *obj)
efl_del_intercept_set(obj, NULL);
efl_unref(obj);
 }
+
+static void
+_del_intercept_reuse(Eo *obj)
+{
+   efl_reuse(obj);
+}
 #endif
 
 START_TEST(efl_del_intercept)
@@ -1270,6 +1276,21 @@ START_TEST(efl_del_intercept)
fail_if(!intercepted);
fail_if(efl_isa(obj, klass));
 
+   /* Check reuse works as expected. */
+   Eo *parent = efl_add(SIMPLE_CLASS, NULL);
+   obj = efl_add(klass, NULL);
+   fail_if(!obj);
+   ck_assert_int_eq(efl_ref_get(obj), 1);
+   efl_parent_set(obj, parent);
+   ck_assert_int_eq(efl_ref_get(obj), 1);
+   efl_del_intercept_set(obj, _del_intercept_reuse);
+   efl_del_intercept_set(obj, NULL);
+   /* This essentially checks it get unsunk */
+   ck_assert_int_eq(efl_ref_get(obj), 1);
+   efl_parent_set(obj, parent);
+   ck_assert_int_eq(efl_ref_get(obj), 1);
+   efl_del(obj);
+
efl_object_shutdown();
 #endif
 }

-- 

[EGIT] [core/efl] master 02/03: Eo: Fix references of objects

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=25242e6af9b44ce0b31c66396ba1afbc75bb29a8

commit 25242e6af9b44ce0b31c66396ba1afbc75bb29a8
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Oct 21 15:02:27 2016 +0100

Eo: Fix references of objects
---
 src/lib/eo/eo.c  |  8 ++--
 src/lib/eo/eo_base_class.c   | 22 +-
 src/lib/eo/eo_private.h  |  2 ++
 src/tests/eo/suite/eo_test_general.c |  4 ++--
 4 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index 8ce82f3..ad8306d 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -850,9 +850,13 @@ _efl_add_end(Eo *eo_id, Eina_Bool is_ref, Eina_Bool 
is_fallback)
Eo *ret = efl_finalize(eo_id);
ret = _efl_add_internal_end(eo_id, ret);
 
-   if (is_ref && efl_parent_get(eo_id))
+   if (is_ref)
  {
-efl_ref(eo_id);
+if (efl_parent_get(eo_id))
+  {
+ efl_ref(eo_id);
+  }
+_efl_object_parent_sink(eo_id);
  }
 
if (is_fallback)
diff --git a/src/lib/eo/eo_base_class.c b/src/lib/eo/eo_base_class.c
index f64ebca..bc85105 100644
--- a/src/lib/eo/eo_base_class.c
+++ b/src/lib/eo/eo_base_class.c
@@ -39,6 +39,7 @@ typedef struct
unsigned short event_freeze_count;
Eina_Bool  deletions_waiting : 1;
Eina_Bool  callback_stopped : 1;
+   Eina_Bool  parent_sunk : 1; // If parent ref has already 
been settled (parent has been set, or we are in add_ref mode
 } Efl_Object_Data;
 
 typedef enum {
@@ -533,9 +534,17 @@ _efl_object_del(const Eo *obj, Efl_Object_Data *pd 
EINA_UNUSED)
  }
 }
 
+void
+_efl_object_parent_sink(Eo *obj)
+{
+   Efl_Object_Data *pd = efl_data_scope_get(obj, EFL_OBJECT_CLASS);
+   pd->parent_sunk = EINA_TRUE;
+}
+
 EOLIAN static void
 _efl_object_parent_set(Eo *obj, Efl_Object_Data *pd, Eo *parent_id)
 {
+   Eo *prev_parent = pd->parent;
if ((pd->parent == parent_id) ||
((parent_id) && (!_eo_id_domain_compatible(parent_id, obj
  return;
@@ -552,10 +561,6 @@ _efl_object_parent_set(Eo *obj, Efl_Object_Data *pd, Eo 
*parent_id)
 // this error is highly unlikely so move it out of the normal
 // instruction path to avoid l1 cache pollution
 else goto err_impossible;
-
-/* Only unref if we don't have a new parent instead and we are not at
- * the process of deleting the object.*/
-if (!parent_id && !eo_obj->del_triggered) efl_unref(obj);
  }
 
/* Set new parent */
@@ -569,16 +574,23 @@ _efl_object_parent_set(Eo *obj, Efl_Object_Data *pd, Eo 
*parent_id)
  pd->parent = parent_id;
  parent_pd->children = eina_inlist_append(parent_pd->children,
   EINA_INLIST_GET(eo_obj));
+ if (!prev_parent && pd->parent_sunk) efl_ref(obj);
+ pd->parent_sunk = EINA_TRUE;
   }
 else
   {
  pd->parent = NULL;
+ if (prev_parent) efl_unref(obj);
  // unlikely this error happens, so move it out of execution path
  // to improve l1 cache efficiency
  goto err_parent;
   }
  }
-   else pd->parent = NULL;
+   else
+ {
+pd->parent = NULL;
+if (prev_parent && !eo_obj->del_triggered) efl_unref(obj);
+ }
 
EO_OBJ_DONE(obj);
return;
diff --git a/src/lib/eo/eo_private.h b/src/lib/eo/eo_private.h
index 54975ff..035d84c 100644
--- a/src/lib/eo/eo_private.h
+++ b/src/lib/eo/eo_private.h
@@ -196,6 +196,8 @@ typedef struct
int line;
 } Eo_Xref_Node;
 
+void _efl_object_parent_sink(Eo *obj);
+
 static inline
 Eo *_eo_header_id_get(const Eo_Header *header)
 {
diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index 648f733..e142d67 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -611,8 +611,8 @@ START_TEST(efl_refs)
 
efl_parent_set(obj2, obj);
efl_parent_set(obj3, obj);
-   ck_assert_int_eq(efl_ref_get(obj2), 1);
-   ck_assert_int_eq(efl_ref_get(obj3), 1);
+   ck_assert_int_eq(efl_ref_get(obj2), 2);
+   ck_assert_int_eq(efl_ref_get(obj3), 2);
 
efl_del(obj);
efl_del(obj2);

-- 

[EGIT] [core/efl] master 01/03: Eo test: Fix cleanup of objects.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=6c8489c3b76ab1d5548e7786c9b7e6fcfddba581

commit 6c8489c3b76ab1d5548e7786c9b7e6fcfddba581
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Oct 21 15:18:46 2016 +0100

Eo test: Fix cleanup of objects.
---
 src/tests/eo/suite/eo_test_general.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index f0548d7..648f733 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -589,6 +589,11 @@ START_TEST(efl_refs)
ck_assert_int_eq(efl_ref_get(obj2), 1);
ck_assert_int_eq(efl_ref_get(obj3), 2);
 
+   efl_del(obj);
+   efl_del(obj2);
+   efl_unref(obj3);
+   efl_del(obj3);
+
/* Setting and removing parents. */
obj = efl_add(SIMPLE_CLASS, NULL);
obj2 = efl_ref(efl_add(SIMPLE_CLASS, obj));

-- 

[EGIT] [core/efl] master 03/03: Eo: Add test for refcount in efl_add_ref

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=047d88caa00db9e9b31c88682703462d0d6fa201

commit 047d88caa00db9e9b31c88682703462d0d6fa201
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Oct 21 15:25:52 2016 +0100

Eo: Add test for refcount in efl_add_ref

This commits adds a regression test to the previous commit.
---
 src/tests/eo/suite/eo_test_general.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index e142d67..bb34b7d 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -618,6 +618,33 @@ START_TEST(efl_refs)
efl_del(obj2);
efl_del(obj3);
 
+   /* Setting and removing parents for add_ref */
+   obj = efl_add(SIMPLE_CLASS, NULL);
+   obj2 = efl_add_ref(SIMPLE_CLASS, obj);
+   obj3 = efl_add_ref(SIMPLE_CLASS, NULL);
+
+   ck_assert_int_eq(efl_ref_get(obj2), 2);
+   ck_assert_int_eq(efl_ref_get(obj3), 1);
+
+   efl_parent_set(obj2, obj3);
+   efl_parent_set(obj3, obj);
+   ck_assert_int_eq(efl_ref_get(obj2), 2);
+   ck_assert_int_eq(efl_ref_get(obj3), 2);
+
+   efl_parent_set(obj2, NULL);
+   efl_parent_set(obj3, NULL);
+   ck_assert_int_eq(efl_ref_get(obj2), 1);
+   ck_assert_int_eq(efl_ref_get(obj3), 1);
+
+   efl_parent_set(obj2, obj);
+   efl_parent_set(obj3, obj);
+   ck_assert_int_eq(efl_ref_get(obj2), 2);
+   ck_assert_int_eq(efl_ref_get(obj3), 2);
+
+   efl_del(obj);
+   efl_del(obj2);
+   efl_del(obj3);
+
/* Just check it doesn't seg atm. */
obj = efl_add(SIMPLE_CLASS, NULL);
efl_ref(obj);

-- 

Re: [E-devel] Repos sending mails to git@lists

[Tom Hacohen]

On 20/10/16 20:50, Bruno Dilly wrote:
> Hey guys,
>
> I realized apparently changes on apps/eruler are not sent to our git mails
> list.
>
> How is it managed? Do we have a list of repos with hooks to send emails to
> such list? Could you guys please add eruler to this list?
>
> Thanks in advance
>

All repos send mails unless the commits are already available on the 
server (for example, the commits are in a branch).

--
Tom.

--
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

[EGIT] [core/efl] master 02/03: Eo: Fix reference leak when failing to resolve function.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=5a659fafd22de295f8a4fb276e343f0da870779f

commit 5a659fafd22de295f8a4fb276e343f0da870779f
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Oct 19 16:14:15 2016 +0100

Eo: Fix reference leak when failing to resolve function.

When resolving a function for an object the object would get reference,
and then in some failure cases won't be freed.

I suspect this is a regression following the reshuffling that was done
in that function recently.

Thanks to zmike for investigating and reporting this.

Fixes T4740

@fix
---
 src/lib/eo/eo.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/lib/eo/eo.c b/src/lib/eo/eo.c
index 8324b21..8ce82f3 100644
--- a/src/lib/eo/eo.c
+++ b/src/lib/eo/eo.c
@@ -513,7 +513,11 @@ err_func_src:
ERR("in %s:%d: you called a pure virtual func '%s' (%d) of class '%s'.",
file, line, func_name, cache->op, klass->desc->name);
 err:
-   if (is_obj) _eo_obj_pointer_done((Eo_Id)eo_id);
+   if (is_obj)
+ {
+_efl_unref(obj);
+_eo_obj_pointer_done((Eo_Id)eo_id);
+ }
return EINA_FALSE;
 
// yes - special "move out of hot path" code blobs with goto's for

-- 

[EGIT] [core/efl] master 03/03: Eo: Add a regression test for ref leak in function resolve

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=d952b350982aa8ad7575fcceec18d0075034b41c

commit d952b350982aa8ad7575fcceec18d0075034b41c
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Oct 19 16:20:19 2016 +0100

Eo: Add a regression test for ref leak in function resolve

This adds a regression test for the last commit.
---
 src/tests/eo/suite/eo_test_general.c | 61 
 1 file changed, 61 insertions(+)

diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index 3974924..f0548d7 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -966,6 +966,66 @@ START_TEST(eo_magic_checks)
 }
 END_TEST
 
+/* resolve issues */
+
+static Eina_Bool
+_a_print(Eo *obj EINA_UNUSED, void *class_data EINA_UNUSED)
+{
+   printf("Hey\n");
+
+   return EINA_TRUE;
+}
+
+EFL_FUNC_BODY(resolve_a_print, Eina_Bool, EINA_FALSE);
+
+static Eina_Bool
+_multi_class_initializer(Efl_Class *klass)
+{
+   EFL_OPS_DEFINE(ops,
+ EFL_OBJECT_OP_FUNC(resolve_a_print, _a_print),
+   );
+
+   return efl_class_functions_set(klass, , NULL);
+}
+
+START_TEST(efl_func_resolve)
+{
+   efl_object_init();
+
+   /* Usually should be const, not const only for the test... */
+   static Efl_Class_Description class_desc = {
+EO_VERSION,
+"Inherit",
+EFL_CLASS_TYPE_REGULAR,
+0,
+_multi_class_initializer,
+NULL,
+NULL
+   };
+
+   const Efl_Class *klass = efl_class_new(_desc, SIMPLE_CLASS, NULL);
+   fail_if(!klass);
+
+   Eo *obj = efl_add(klass, NULL);
+   fail_if(!resolve_a_print(obj));
+   efl_unref(obj);
+
+
+   obj = efl_add(SIMPLE_CLASS, NULL);
+   fail_if(!obj);
+   efl_manual_free_set(obj, EINA_TRUE);
+
+   fail_if(resolve_a_print(obj));
+
+   efl_unref(obj);
+
+   fail_if(!efl_destructed_is(obj));
+   efl_manual_free(obj);
+
+   efl_object_shutdown();
+}
+END_TEST
+
 START_TEST(efl_add_do_and_custom)
 {
Simple_Public_Data *pd = NULL;
@@ -1485,6 +1545,7 @@ void eo_test_general(TCase *tc)
tcase_add_test(tc, efl_weak_reference);
tcase_add_test(tc, eo_generic_data);
tcase_add_test(tc, eo_magic_checks);
+   tcase_add_test(tc, efl_func_resolve);
tcase_add_test(tc, efl_add_do_and_custom);
tcase_add_test(tc, eo_pointers_indirection);
tcase_add_test(tc, efl_add_failures);

-- 

[EGIT] [core/efl] master 01/03: Eo: Remove no longer relevant tests.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/core/efl.git/commit/?id=f4eb94a7d8d2b57cc7856596e6489c339482e9dd

commit f4eb94a7d8d2b57cc7856596e6489c339482e9dd
Author: Tom Hacohen <t...@stosb.com>
Date:   Wed Oct 19 16:14:03 2016 +0100

Eo: Remove no longer relevant tests.
---
 src/tests/eo/suite/eo_test_general.c | 74 
 1 file changed, 74 deletions(-)

diff --git a/src/tests/eo/suite/eo_test_general.c 
b/src/tests/eo/suite/eo_test_general.c
index a48192f..3974924 100644
--- a/src/tests/eo/suite/eo_test_general.c
+++ b/src/tests/eo/suite/eo_test_general.c
@@ -966,79 +966,6 @@ START_TEST(eo_magic_checks)
 }
 END_TEST
 
-/* MULTI */
-
-static Eina_Bool
-_a_print(Eo *obj EINA_UNUSED, void *class_data EINA_UNUSED)
-{
-   printf("Hey\n");
-
-   return EINA_TRUE;
-}
-
-static Eina_Bool
-_class_hi_print(Efl_Class *klass EINA_UNUSED, void *class_data EINA_UNUSED)
-{
-   printf("Hi\n");
-
-   return EINA_TRUE;
-}
-
-EFL_FUNC_BODY(multi_a_print, Eina_Bool, EINA_FALSE);
-EFL_FUNC_BODY_CONST(multi_class_hi_print, Eina_Bool, EINA_FALSE);
-
-static Eina_Bool
-_multi_class_initializer(Efl_Class *klass)
-{
-   EFL_OPS_DEFINE(ops,
- EFL_OBJECT_OP_FUNC(multi_a_print, _a_print),
- EFL_OBJECT_OP_FUNC(multi_class_hi_print, _class_hi_print),
-   );
-
-   return efl_class_functions_set(klass, , NULL);
-}
-
-START_TEST(eo_multiple_do)
-{
-   efl_object_init();
-
-   /* Usually should be const, not const only for the test... */
-   static Efl_Class_Description class_desc = {
-EO_VERSION,
-"Inherit",
-EFL_CLASS_TYPE_REGULAR,
-0,
-_multi_class_initializer,
-NULL,
-NULL
-   };
-
-   const Efl_Class *klass = efl_class_new(_desc, SIMPLE_CLASS, NULL);
-   fail_if(!klass);
-
-   Eo *obj = efl_add(klass, NULL);
-   fail_if(!obj);
-
-   Eina_Bool ca, cb, cc;
-
-   ca = cb = cc = EINA_FALSE;
-   ca = simple_a_print(obj);
-   cb = multi_a_print(obj);
-   cc = multi_a_print(obj);
-   fail_if(!(ca && cb && cc));
-
-   ca = cb = cc = EINA_FALSE;
-   ca = simple_class_hi_print(klass);
-   cb = multi_class_hi_print(klass);
-   cc = multi_class_hi_print(klass);
-   fail_if(!(ca && cb && cc));
-
-   efl_unref(obj);
-
-   efl_object_shutdown();
-}
-END_TEST
-
 START_TEST(efl_add_do_and_custom)
 {
Simple_Public_Data *pd = NULL;
@@ -1558,7 +1485,6 @@ void eo_test_general(TCase *tc)
tcase_add_test(tc, efl_weak_reference);
tcase_add_test(tc, eo_generic_data);
tcase_add_test(tc, eo_magic_checks);
-   tcase_add_test(tc, eo_multiple_do);
tcase_add_test(tc, efl_add_do_and_custom);
tcase_add_test(tc, eo_pointers_indirection);
tcase_add_test(tc, efl_add_failures);

-- 

Re: [E-devel] Server De spanking is required

[Tom Hacohen]

Sorry, I misread what you wrote!

We could maybe put the link to my mirror somewhere? Though I doubt that 
would be helpful, and I'm not in favour of making it "official".

On 17/10/16 13:53, Andrew Williams wrote:
> Agreed, that's what I meant
> On Mon, 17 Oct 2016 at 13:40, Tom Hacohen <t...@osg.samsung.com> wrote:
>
>> On 16/10/16 00:40, Andrew Williams wrote:
>>> Right now if we continue to have issues it seems a lot like GitHub or
>> other
>>> services may be more available than our own?
>>> Things have come a long way since sourceforge.
>>>
>>> Andy
>>>
>>> P.s. If we advertise an automated clone all it means is someone couldn't
>>> push if our core server were not available - pull or clone should work
>> fine.
>>>
>>
>> Two pull targets (i.e a r/o clone like now) is not a problem. Having two
>> push targets is. We already had a long discussion about this and I
>> explained why this is a really bad idea.
>>
>> --
>> Tom.
>>
>>> On Sun, 9 Oct 2016 at 09:54, Carsten Haitzler <ras...@rasterman.com>
>> wrote:
>>>
>>>> On Sun, 09 Oct 2016 08:17:23 +0200 Jonathan Aquilina <
>>>> jaquil...@eagleeyet.net>
>>>> said:
>>>>
>>>>> Regarding version control repos, why not offload to github which is
>> free
>>>>> even for those projects which are open source.
>>>>
>>>> hell no. after having offloaded to sourecforge and finding servers going
>>>> down
>>>> or things needing to be done that require admin control, no. we run ours
>>>> because
>>>> anything else is generally worse.
>>>>
>>>>> Bertrand, where do you need a hand. If you are saying this is a kernel
>>>>> issue why not update the system and reboot. Also what is the host
>> system
>>>>> running distro wise?
>>>>>
>>>>> On 2016-10-09 02:20, Carsten Haitzler wrote:
>>>>>
>>>>>> On Sat, 08 Oct 2016 11:16:28 +0200 Jonathan Aquilina
>>>>>> <jaquil...@eagleeyet.net> said:
>>>>>>
>>>>>>> anything I can help with. Would a server from soyoustart.com help in
>>>>>>> anyway. I am willing to get the project one and take charge of its
>>>>>>> maintenance
>>>>>>
>>>>>> we have a very big beefy server. we're not running out of disk space,
>>>>>> processing power etc. (8 core xeon @ 2.2ghz, 48gb ram, 1tb or so of
>>>> disk
>>>>>> space available across both ssd and hdd fully redundant raid0'd).
>>>>>>
>>>>>> the issue is a software issue i suspect in the host system kernel and
>>>> we
>>>>>> just don't know why or what. (my suspicious is due to it needing a
>>>> reboot
>>>>>> to fix).
>>>>>>
>>>>>> we have used a fair bit of disk space but tbh the largest user is
>>>> jenkins
>>>>>> (253gb) and it probably could do with a cleanup after a few years to
>>>> lean it
>>>>>> back down. we probably could shut down and archive the cvs and svn
>> vm's
>>>>>> )extract out the cvs and svn db data to a compressed tarball and make
>>>> that
>>>>>> available and otherwise nuke the vm's). that should cut that down to
>>>> 1-2gb
>>>>>> saving about 18gb. web is using 52gb - i think that might do with some
>>>>>> trimming/compacting. phab is using 55gb - same. playschool is 66gb -
>>>> maybe
>>>>>> trim too and re-compact down? e5v1 is pretty fat too (29g). the build
>>>> vm's
>>>>>> are pretty bug (10 of them ranging from 270k to 65g - funny the
>>>> windows10
>>>>>> vm for builds is only 18g. the gentoo ones are mostly 60gb or so -
>>>> windows
>>>>>> is leaner than gentoo! :) )... and of course jenkins is at 253g.
>>>>>>
>>>>>> actually man we're fat on disk space usage. we really could do with a
>>>> trim
>>>>>> there. the images are qcow2 images. we need to trim.
>>>>>>
>>>>>> On 2016-10-07 13:42, Mike Blumenkrantz wrote:
>>>>>>
>>>>>> Is there some way we could prevent this from happening? All the
>>>> services
>>>>>> were unavailable for 8+ h

Re: [E-devel] Server De spanking is required

[Tom Hacohen]

On 09/10/16 10:15, Jonathan Aquilina wrote:
> Hi Carsten,
>
> I think a good way forward would be to get a small server, I would even
> be willing to sponsor a vps and use puppet. It would make automation
> deployments and system management alot easier. I am going to be setting
> up puppet for my own systems. Would you be interested in such
> automation? Also what about infrastructure monitoring?

Just a side comment that has only been casually mentioned.

Beber is a bonafide sysadmin. He's been maintaining our infra for a long 
time. We have a complex infra already in store. I think he uses "salt" 
(a puppet alternative) to manage our numerous servers, though I'm not 
sure. Help would always be appreciated, but it should go through him in 
order to avoid trouble.

The problem here is not with server X, or server Y. The problem here is 
with the host node hosting our VMs. It is the one having issues. Maybe 
as raster implied later in this thread, it just needs to be updated. Who 
knows.

--
Tom.

>
> On 2016-10-09 11:10, Carsten Haitzler wrote:
>
>> On Sun, 09 Oct 2016 10:57:57 +0200 Jonathan Aquilina 
>> 
>> said:
>>
>>> what can i do to help get things sorted out as you had mentioned below
>>> though. I am eager to help.
>>
>> well talk with beber. if he trusts you then some debugging. the system is
>> running an oldish 3.18 kernel so who knows if an update fixes it or not. :) 
>> we
>> could so with cutting down our storage usage as we use 750g or so right now 
>> out
>> of 1tb. i think beber could do with help with some deployment work - andy
>> williams asked a few weeks back to set u a vm for a project of his.
>>
>> On 2016-10-09 10:55, Carsten Haitzler wrote:
>>
>> On Sun, 09 Oct 2016 08:17:23 +0200 Jonathan Aquilina
>>  said:
>>
>> Regarding version control repos, why not offload to github which is free
>> even for those projects which are open source.
>> hell no. after having offloaded to sourecforge and finding servers going
>> down or things needing to be done that require admin control, no. we run
>> ours because anything else is generally worse.
>>
>> Bertrand, where do you need a hand. If you are saying this is a kernel
>> issue why not update the system and reboot. Also what is the host system
>> running distro wise?
>>
>> On 2016-10-09 02:20, Carsten Haitzler wrote:
>>
>> On Sat, 08 Oct 2016 11:16:28 +0200 Jonathan Aquilina
>>  said:
>>
>> anything I can help with. Would a server from soyoustart.com help in
>> anyway. I am willing to get the project one and take charge of its
>> maintenance
>> we have a very big beefy server. we're not running out of disk space,
>> processing power etc. (8 core xeon @ 2.2ghz, 48gb ram, 1tb or so of disk
>> space available across both ssd and hdd fully redundant raid0'd).
>>
>> the issue is a software issue i suspect in the host system kernel and we
>> just don't know why or what. (my suspicious is due to it needing a reboot
>> to fix).
>>
>> we have used a fair bit of disk space but tbh the largest user is jenkins
>> (253gb) and it probably could do with a cleanup after a few years to lean it
>> back down. we probably could shut down and archive the cvs and svn vm's
>> )extract out the cvs and svn db data to a compressed tarball and make that
>> available and otherwise nuke the vm's). that should cut that down to 1-2gb
>> saving about 18gb. web is using 52gb - i think that might do with some
>> trimming/compacting. phab is using 55gb - same. playschool is 66gb - maybe
>> trim too and re-compact down? e5v1 is pretty fat too (29g). the build vm's
>> are pretty bug (10 of them ranging from 270k to 65g - funny the windows10
>> vm for builds is only 18g. the gentoo ones are mostly 60gb or so - windows
>> is leaner than gentoo! :) )... and of course jenkins is at 253g.
>>
>> actually man we're fat on disk space usage. we really could do with a trim
>> there. the images are qcow2 images. we need to trim.
>>
>> On 2016-10-07 13:42, Mike Blumenkrantz wrote:
>>
>> Is there some way we could prevent this from happening? All the services
>> were unavailable for 8+ hours yesterday and it was incredibly disruptive.
>>
>> On Thu, Oct 6, 2016 at 11:09 PM Bertrand Jacquin 
>> wrote:
>>
>> Unspanked(tm)
>>
>> On Fri, Oct 07, 2016 at 12:18:07PM +1030, Simon Lees wrote: *** SPANK SPANK
>> SPANK!!! Enlightenment server is over capacity
>>
>> Please wait a moment and try again later.
>> For more information, take a look at #e on IRC, server irc.freenode.org.
>>
>> --
>>
>> Simon Lees (Simotek)http://simotek.net
>>
>> Emergency Update Team   keybase.io/simotek
>> SUSE LinuxAdeliade Australia, UTC+9:30
>> GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
>>
>> --
>> Check out the vibrant tech community on one of 

Re: [E-devel] Server De spanking is required

[Tom Hacohen]

On 16/10/16 00:40, Andrew Williams wrote:
> Right now if we continue to have issues it seems a lot like GitHub or other
> services may be more available than our own?
> Things have come a long way since sourceforge.
>
> Andy
>
> P.s. If we advertise an automated clone all it means is someone couldn't
> push if our core server were not available - pull or clone should work fine.
>

Two pull targets (i.e a r/o clone like now) is not a problem. Having two 
push targets is. We already had a long discussion about this and I 
explained why this is a really bad idea.

--
Tom.

> On Sun, 9 Oct 2016 at 09:54, Carsten Haitzler  wrote:
>
>> On Sun, 09 Oct 2016 08:17:23 +0200 Jonathan Aquilina <
>> jaquil...@eagleeyet.net>
>> said:
>>
>>> Regarding version control repos, why not offload to github which is free
>>> even for those projects which are open source.
>>
>> hell no. after having offloaded to sourecforge and finding servers going
>> down
>> or things needing to be done that require admin control, no. we run ours
>> because
>> anything else is generally worse.
>>
>>> Bertrand, where do you need a hand. If you are saying this is a kernel
>>> issue why not update the system and reboot. Also what is the host system
>>> running distro wise?
>>>
>>> On 2016-10-09 02:20, Carsten Haitzler wrote:
>>>
 On Sat, 08 Oct 2016 11:16:28 +0200 Jonathan Aquilina
  said:

> anything I can help with. Would a server from soyoustart.com help in
> anyway. I am willing to get the project one and take charge of its
> maintenance

 we have a very big beefy server. we're not running out of disk space,
 processing power etc. (8 core xeon @ 2.2ghz, 48gb ram, 1tb or so of
>> disk
 space available across both ssd and hdd fully redundant raid0'd).

 the issue is a software issue i suspect in the host system kernel and
>> we
 just don't know why or what. (my suspicious is due to it needing a
>> reboot
 to fix).

 we have used a fair bit of disk space but tbh the largest user is
>> jenkins
 (253gb) and it probably could do with a cleanup after a few years to
>> lean it
 back down. we probably could shut down and archive the cvs and svn vm's
 )extract out the cvs and svn db data to a compressed tarball and make
>> that
 available and otherwise nuke the vm's). that should cut that down to
>> 1-2gb
 saving about 18gb. web is using 52gb - i think that might do with some
 trimming/compacting. phab is using 55gb - same. playschool is 66gb -
>> maybe
 trim too and re-compact down? e5v1 is pretty fat too (29g). the build
>> vm's
 are pretty bug (10 of them ranging from 270k to 65g - funny the
>> windows10
 vm for builds is only 18g. the gentoo ones are mostly 60gb or so -
>> windows
 is leaner than gentoo! :) )... and of course jenkins is at 253g.

 actually man we're fat on disk space usage. we really could do with a
>> trim
 there. the images are qcow2 images. we need to trim.

 On 2016-10-07 13:42, Mike Blumenkrantz wrote:

 Is there some way we could prevent this from happening? All the
>> services
 were unavailable for 8+ hours yesterday and it was incredibly
>> disruptive.

 On Thu, Oct 6, 2016 at 11:09 PM Bertrand Jacquin >>
 wrote:

 Unspanked(tm)

 On Fri, Oct 07, 2016 at 12:18:07PM +1030, Simon Lees wrote: *** SPANK
>> SPANK
 SPANK!!! Enlightenment server is over capacity

 Please wait a moment and try again later.
 For more information, take a look at #e on IRC, server
>> irc.freenode.org.

 --

 Simon Lees (Simotek)http://simotek.net

 Emergency Update Team   keybase.io/simotek
 SUSE LinuxAdeliade Australia, UTC+9: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

 --
 Bertrand


>> --
 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 

Re: [E-devel] Server Down

[Tom Hacohen]

This is actually not an Einstein quote, just commonly and falsely 
attributed to him. :)

On 17/10/16 12:57, Stephen Houston wrote:
> Hey Einstein... how dare you question Einstein!! :-)
>
> On Mon, Oct 17, 2016, 6:54 AM Tom Hacohen <t...@osg.samsung.com> wrote:
>
>> On 15/10/16 17:11, Stephen Houston wrote:
>>> This is getting REALLY annoying at how often this happens and never gets
>>> fixed.  Insanity is defined as doing the same thing over and over
>> expecting
>>> a different result.
>>>
>>
>> Not the definition of insanity[1].
>>
>> 1: https://en.wikipedia.org/wiki/Insanity
>>
>>> On Sat, Oct 15, 2016 at 6:08 AM Al Poole <nets...@gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> Seems there are server issues.
>>>>
>>>> Just letting someone know (if not already).
>>>>
>>>> As usual:
>>>>
>>>> Spank, Spank, Spank!
>>>>
>>>>
>> --
>>>> 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
>>>
>>
>>
>>
>> --
>> 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
>


--
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] Server Down

[Tom Hacohen]

On 15/10/16 17:11, Stephen Houston wrote:
> This is getting REALLY annoying at how often this happens and never gets
> fixed.  Insanity is defined as doing the same thing over and over expecting
> a different result.
>

Not the definition of insanity[1].

1: https://en.wikipedia.org/wiki/Insanity

> On Sat, Oct 15, 2016 at 6:08 AM Al Poole  wrote:
>
>> Hi,
>>
>> Seems there are server issues.
>>
>> Just letting someone know (if not already).
>>
>> As usual:
>>
>> Spank, Spank, Spank!
>>
>> --
>> 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
>


--
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] github mirror

[Tom Hacohen]

On 09/10/16 13:08, Vincent Torri wrote:
> Hey
>
> responding to 
> https://www.mail-archive.com/enlightenment-devel@lists.sourceforge.net/msg87948.html,
> i can also have a mirror of the EFL and E, and others
>
> I also usually setup my projects or projects I'm working on with
> drone.io, with compilation on Linux and Windows (see for example :
> https://drone.io/github.com/luser-dr00g/xpost)
>
> Just tell me if you're interested

I already set up a mirror a year ago:

https://github.com/tasn/enlightenment
https://github.com/tasn/efl

--
Tom

--
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-users] Terminology interprets < as >

[Tom Hacohen]

On 04/10/16 15:23, Ross Vandegrift wrote:
> On Tue, Oct 04, 2016 at 03:16:34PM +0100, Tom Hacohen wrote:
>>> On one system, terminology is interpreting presses of "<" as if I
>>> pressed ">".   Comma is unaffected.  No other application does this.
>>> Remote terminology doesn't do it, so I think it must be in the local
>>> config.
>>>
>>> Any ideas on how I can track this down?
>>>
>>
>> What's your local? System? What about other mirrored characters like ()
>> and {}?
>
> Terminology 0.9.1, EFL 1.16, Debian jessie, X11.  (), {}, and [] are all
> fine.  Maybe I'll update EFL this afternoon if I can't figure it out.
>
> So weird.

Extremely.

Is "<" rendered as "<", or as ">"? Could you maybe try a different shell 
(I'm just making random suggestions at this point)?

--
Tom


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Terminology interprets < as >

[Tom Hacohen]

On 04/10/16 15:13, Ross Vandegrift wrote:
> Hi all,
>
> On one system, terminology is interpreting presses of "<" as if I
> pressed ">".   Comma is unaffected.  No other application does this.
> Remote terminology doesn't do it, so I think it must be in the local
> config.
>
> Any ideas on how I can track this down?
>

What's your local? System? What about other mirrored characters like () 
and {}?


--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

[EGIT] [editors/vim-configs] master 01/01: Eo: Add ref tag.

[Tom Hacohen]

tasn pushed a commit to branch master.

http://git.enlightenment.org/editors/vim-configs.git/commit/?id=8a6682cb492cf1b739160374713ac0968b72b3fd

commit 8a6682cb492cf1b739160374713ac0968b72b3fd
Author: Tom Hacohen <t...@stosb.com>
Date:   Fri Sep 30 15:08:42 2016 +0100

Eo: Add ref tag.
---
 syntax/eo.vim | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/syntax/eo.vim b/syntax/eo.vim
index 1b0ac17..d3bee08 100644
--- a/syntax/eo.vim
+++ b/syntax/eo.vim
@@ -23,7 +23,7 @@ syn keywordeoClassBodyLabels legacy_prefix eo_prefix 
event_prefix data conta
 syn keywordeoClassBodyBlockOpener properties methods events constructors 
implements contained
 
 syn keywordeoInnerBlockOpener set get keys values params contained
-syn keywordeoTypeClass const own free contained
+syn keywordeoTypeClass const own free ref contained
 syn keywordfunctionKeywords constructor destructor finalize virtual legacy
 syn keywordeoStatements return
 

--