Re: [E-devel] problems with eo method overloading

[Jean-Philippe André]

Hi,

On 17 August 2016 at 04:55, Gustavo Sverzut Barbieri 
wrote:

> On Tue, Aug 16, 2016 at 3:37 PM, Tom Hacohen  wrote:
> > No, that is a no go, because you don't always want to methods as EAPI
> > (think internal classes).
>

All eo symbols are currently marked as EOAPI which means EAPI EAPI_WEAK.
So there is no such thing as a purely internal class at the moment, at
least not with eolian_gen.


> > The correct thing would be to add the warning/error.
>
> what are you talking about? It's the same that .eo.h does if you
> properly #define ..._PROTECTED... I'm not suggesting to change that
> behavior, just to auto-fix for the user when that is possible.
>

Remember that on Windows you have 4 different versions of EAPI:
1. dllexport used when compiling the library
2. dllimport used from outside the library
3. defined to nothing, when compiling a file in the library but without
DLL_EXPORT defined (note: no idea how it gets defined... autofoo magic?) No
idea when this happens.
4. reset to nothing, at the end of the main header

One way or another, EAPI is already there in the eo.c file. I believe for
Linux it would need to be added to the function signature (not only its
implementation). But for Windows this will not work as EAPI is reset at
that point.

So the best you can do is error out if the eo.c file is included and
PROTECTED isn't defined.

-- 
Jean-Philippe André
--
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Re: [E-devel] problems with eo method overloading

[Gustavo Sverzut Barbieri]

On Tue, Aug 16, 2016 at 3:37 PM, Tom Hacohen  wrote:
> No, that is a no go, because you don't always want to methods as EAPI
> (think internal classes).
>
> The correct thing would be to add the warning/error.

what are you talking about? It's the same that .eo.h does if you
properly #define ..._PROTECTED... I'm not suggesting to change that
behavior, just to auto-fix for the user when that is possible.



-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

No, that is a no go, because you don't always want to methods as EAPI
(think internal classes).

The correct thing would be to add the warning/error.

--
Tom.

On Tue, Aug 16, 2016 at 6:49 PM, Gustavo Sverzut Barbieri <
barbi...@gmail.com> wrote:

> On Tue, Aug 16, 2016 at 11:43 AM, Felipe Magno de Almeida
>  wrote:
> > On Tue, Aug 16, 2016 at 11:39 AM, Tom Hacohen 
> wrote:
> >> On 16/08/16 15:38, Tom Hacohen wrote:
> >
> > [snip]
> >
> >>> According to Daniel there are no ifdefs in the .eo.c... So I don't
> >>> understand the problem...
> >>
> >> Actually, I can see why there would still be a problem because of the
> >> weak symbols thing.
> >>
> >> I guess the best way then, as you suggested is to do the ifndef. We can
> >> probably do an error, not a warning.
> >
> > I've fell in this problem before, but don't remember which error I
> received.
> > It took me a while to figure out that I forgot to #define _PROTECTED.
> > So the error would be good indeed. But only if there are some functions
> > defined as protected.
> >
> > OTOH, can't the .eo.c file just re-declare the functions as weak symbols
> > or something?
>
> this is what I propose... it's a matter of writing the EAPI method();
>
>
> --
> Gustavo Sverzut Barbieri
> --
> Mobile: +55 (16) 99354-9890
>
> 
> --
> ___
> 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] problems with eo method overloading

[Gustavo Sverzut Barbieri]

On Tue, Aug 16, 2016 at 11:43 AM, Felipe Magno de Almeida
 wrote:
> On Tue, Aug 16, 2016 at 11:39 AM, Tom Hacohen  wrote:
>> On 16/08/16 15:38, Tom Hacohen wrote:
>
> [snip]
>
>>> According to Daniel there are no ifdefs in the .eo.c... So I don't
>>> understand the problem...
>>
>> Actually, I can see why there would still be a problem because of the
>> weak symbols thing.
>>
>> I guess the best way then, as you suggested is to do the ifndef. We can
>> probably do an error, not a warning.
>
> I've fell in this problem before, but don't remember which error I received.
> It took me a while to figure out that I forgot to #define _PROTECTED.
> So the error would be good indeed. But only if there are some functions
> defined as protected.
>
> OTOH, can't the .eo.c file just re-declare the functions as weak symbols
> or something?

this is what I propose... it's a matter of writing the EAPI method();


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

On 16/08/16 15:38, Tom Hacohen wrote:
> On 16/08/16 15:27, Tom Hacohen wrote:
>> On 16/08/16 15:19, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Aug 16, 2016 at 11:09 AM, Tom Hacohen 
>>> wrote:
 On 16/08/16 14:48, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen 
> wrote:
>> On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
>>> it seems at the end was a missing "#define ..._PROTECTED" in the .c
>>> file that includes the generated .eo.c.
>>>
>>> I wonder: shouldn't the generated .eo.c write:
>>> #ifndef ..._PROTECTED
>>> #define ..._PROTECTED
>>> #endif
>>>
>>
>> No. The .eo.c should be included at the end of the .c file and the
>> .eo.h
>> is at the beginning. You need to define the protected before the .h.
>
> what about one of these in the .eo.c:
>
> 1 - define the methods and maybe warn the user (would help me)
> #ifndef .._PROTECTED
> // replicate all methods locally to avoid issues
> #warning "you should define ..._PROTECTED before including .eo.c"
> EAPI ... methods...()
> #endif
>
>
> 2 - fail
> #ifndef ..._PROTECTED
> #error "Your class/interface/mixin declares @protected methods, you
> must define ..._PROTECTED before including .eo.c otherwise it won't
> work"
> #endif

 Maybe we should just get rid of this define altogether... If your code
 works without the define, then there's nothing in the .eo.c that should
 require it. So I guess this is just extraneous and should be removed.

 Daniel?
>>>
>>> AFAIU the symbol won't be exported and will result in NULL being used.
>>>
>>> If you remove the PROTECT define, then you either need to generate
>>> another file (ie: .eo.protected.h) or it will always be accessible to
>>> wider public.
>>>
>>> I'm not sure there is any blocker from external users calling
>>> protected stuff other than hiding the symbol.
>>>
>>>
>>
>> No, you got me wrong, I meant remove the define from the .eo.c and keep
>> it in the .eo.h.
>>
>> I don't see a case where you would want to not have this piece of code
>> included in the .eo.c.
>
> According to Daniel there are no ifdefs in the .eo.c... So I don't
> understand the problem...

Actually, I can see why there would still be a problem because of the 
weak symbols thing.

I guess the best way then, as you suggested is to do the ifndef. We can 
probably do an error, not a warning.

--
Tom.


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

Re: [E-devel] problems with eo method overloading

[Felipe Magno de Almeida]

On Tue, Aug 16, 2016 at 11:39 AM, Tom Hacohen  wrote:
> On 16/08/16 15:38, Tom Hacohen wrote:

[snip]

>> According to Daniel there are no ifdefs in the .eo.c... So I don't
>> understand the problem...
>
> Actually, I can see why there would still be a problem because of the
> weak symbols thing.
>
> I guess the best way then, as you suggested is to do the ifndef. We can
> probably do an error, not a warning.

I've fell in this problem before, but don't remember which error I received.
It took me a while to figure out that I forgot to #define _PROTECTED.
So the error would be good indeed. But only if there are some functions
defined as protected.

OTOH, can't the .eo.c file just re-declare the functions as weak symbols
or something?

> --
> Tom.

Regards,
-- 
Felipe Magno de Almeida

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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

On 16/08/16 15:27, Tom Hacohen wrote:
> On 16/08/16 15:19, Gustavo Sverzut Barbieri wrote:
>> On Tue, Aug 16, 2016 at 11:09 AM, Tom Hacohen  wrote:
>>> On 16/08/16 14:48, Gustavo Sverzut Barbieri wrote:
 On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen  wrote:
> On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
>> it seems at the end was a missing "#define ..._PROTECTED" in the .c
>> file that includes the generated .eo.c.
>>
>> I wonder: shouldn't the generated .eo.c write:
>> #ifndef ..._PROTECTED
>> #define ..._PROTECTED
>> #endif
>>
>
> No. The .eo.c should be included at the end of the .c file and the .eo.h
> is at the beginning. You need to define the protected before the .h.

 what about one of these in the .eo.c:

 1 - define the methods and maybe warn the user (would help me)
 #ifndef .._PROTECTED
 // replicate all methods locally to avoid issues
 #warning "you should define ..._PROTECTED before including .eo.c"
 EAPI ... methods...()
 #endif


 2 - fail
 #ifndef ..._PROTECTED
 #error "Your class/interface/mixin declares @protected methods, you
 must define ..._PROTECTED before including .eo.c otherwise it won't
 work"
 #endif
>>>
>>> Maybe we should just get rid of this define altogether... If your code
>>> works without the define, then there's nothing in the .eo.c that should
>>> require it. So I guess this is just extraneous and should be removed.
>>>
>>> Daniel?
>>
>> AFAIU the symbol won't be exported and will result in NULL being used.
>>
>> If you remove the PROTECT define, then you either need to generate
>> another file (ie: .eo.protected.h) or it will always be accessible to
>> wider public.
>>
>> I'm not sure there is any blocker from external users calling
>> protected stuff other than hiding the symbol.
>>
>>
>
> No, you got me wrong, I meant remove the define from the .eo.c and keep
> it in the .eo.h.
>
> I don't see a case where you would want to not have this piece of code
> included in the .eo.c.

According to Daniel there are no ifdefs in the .eo.c... So I don't 
understand the problem...

--
Tom.


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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

On 16/08/16 15:19, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 16, 2016 at 11:09 AM, Tom Hacohen  wrote:
>> On 16/08/16 14:48, Gustavo Sverzut Barbieri wrote:
>>> On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen  wrote:
 On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
> it seems at the end was a missing "#define ..._PROTECTED" in the .c
> file that includes the generated .eo.c.
>
> I wonder: shouldn't the generated .eo.c write:
> #ifndef ..._PROTECTED
> #define ..._PROTECTED
> #endif
>

 No. The .eo.c should be included at the end of the .c file and the .eo.h
 is at the beginning. You need to define the protected before the .h.
>>>
>>> what about one of these in the .eo.c:
>>>
>>> 1 - define the methods and maybe warn the user (would help me)
>>> #ifndef .._PROTECTED
>>> // replicate all methods locally to avoid issues
>>> #warning "you should define ..._PROTECTED before including .eo.c"
>>> EAPI ... methods...()
>>> #endif
>>>
>>>
>>> 2 - fail
>>> #ifndef ..._PROTECTED
>>> #error "Your class/interface/mixin declares @protected methods, you
>>> must define ..._PROTECTED before including .eo.c otherwise it won't
>>> work"
>>> #endif
>>
>> Maybe we should just get rid of this define altogether... If your code
>> works without the define, then there's nothing in the .eo.c that should
>> require it. So I guess this is just extraneous and should be removed.
>>
>> Daniel?
>
> AFAIU the symbol won't be exported and will result in NULL being used.
>
> If you remove the PROTECT define, then you either need to generate
> another file (ie: .eo.protected.h) or it will always be accessible to
> wider public.
>
> I'm not sure there is any blocker from external users calling
> protected stuff other than hiding the symbol.
>
>

No, you got me wrong, I meant remove the define from the .eo.c and keep 
it in the .eo.h.

I don't see a case where you would want to not have this piece of code 
included in the .eo.c.

--
Tom.

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

Re: [E-devel] problems with eo method overloading

[Gustavo Sverzut Barbieri]

On Tue, Aug 16, 2016 at 11:09 AM, Tom Hacohen  wrote:
> On 16/08/16 14:48, Gustavo Sverzut Barbieri wrote:
>> On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen  wrote:
>>> On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
 it seems at the end was a missing "#define ..._PROTECTED" in the .c
 file that includes the generated .eo.c.

 I wonder: shouldn't the generated .eo.c write:
 #ifndef ..._PROTECTED
 #define ..._PROTECTED
 #endif

>>>
>>> No. The .eo.c should be included at the end of the .c file and the .eo.h
>>> is at the beginning. You need to define the protected before the .h.
>>
>> what about one of these in the .eo.c:
>>
>> 1 - define the methods and maybe warn the user (would help me)
>> #ifndef .._PROTECTED
>> // replicate all methods locally to avoid issues
>> #warning "you should define ..._PROTECTED before including .eo.c"
>> EAPI ... methods...()
>> #endif
>>
>>
>> 2 - fail
>> #ifndef ..._PROTECTED
>> #error "Your class/interface/mixin declares @protected methods, you
>> must define ..._PROTECTED before including .eo.c otherwise it won't
>> work"
>> #endif
>
> Maybe we should just get rid of this define altogether... If your code
> works without the define, then there's nothing in the .eo.c that should
> require it. So I guess this is just extraneous and should be removed.
>
> Daniel?

AFAIU the symbol won't be exported and will result in NULL being used.

If you remove the PROTECT define, then you either need to generate
another file (ie: .eo.protected.h) or it will always be accessible to
wider public.

I'm not sure there is any blocker from external users calling
protected stuff other than hiding the symbol.


-- 
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

On 16/08/16 14:48, Gustavo Sverzut Barbieri wrote:
> On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen  wrote:
>> On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
>>> it seems at the end was a missing "#define ..._PROTECTED" in the .c
>>> file that includes the generated .eo.c.
>>>
>>> I wonder: shouldn't the generated .eo.c write:
>>> #ifndef ..._PROTECTED
>>> #define ..._PROTECTED
>>> #endif
>>>
>>
>> No. The .eo.c should be included at the end of the .c file and the .eo.h
>> is at the beginning. You need to define the protected before the .h.
>
> what about one of these in the .eo.c:
>
> 1 - define the methods and maybe warn the user (would help me)
> #ifndef .._PROTECTED
> // replicate all methods locally to avoid issues
> #warning "you should define ..._PROTECTED before including .eo.c"
> EAPI ... methods...()
> #endif
>
>
> 2 - fail
> #ifndef ..._PROTECTED
> #error "Your class/interface/mixin declares @protected methods, you
> must define ..._PROTECTED before including .eo.c otherwise it won't
> work"
> #endif

Maybe we should just get rid of this define altogether... If your code 
works without the define, then there's nothing in the .eo.c that should 
require it. So I guess this is just extraneous and should be removed.

Daniel?

--
Tom.


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

Re: [E-devel] problems with eo method overloading

[Gustavo Sverzut Barbieri]

On Tue, Aug 16, 2016 at 7:08 AM, Tom Hacohen  wrote:
> On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
>> it seems at the end was a missing "#define ..._PROTECTED" in the .c
>> file that includes the generated .eo.c.
>>
>> I wonder: shouldn't the generated .eo.c write:
>> #ifndef ..._PROTECTED
>> #define ..._PROTECTED
>> #endif
>>
>
> No. The .eo.c should be included at the end of the .c file and the .eo.h
> is at the beginning. You need to define the protected before the .h.

what about one of these in the .eo.c:

1 - define the methods and maybe warn the user (would help me)
#ifndef .._PROTECTED
// replicate all methods locally to avoid issues
#warning "you should define ..._PROTECTED before including .eo.c"
EAPI ... methods...()
#endif


2 - fail
#ifndef ..._PROTECTED
#error "Your class/interface/mixin declares @protected methods, you
must define ..._PROTECTED before including .eo.c otherwise it won't
work"
#endif




--
Gustavo Sverzut Barbieri
--
Mobile: +55 (16) 99354-9890

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

Re: [E-devel] problems with eo method overloading

[Tom Hacohen]

On 16/08/16 04:38, Gustavo Sverzut Barbieri wrote:
> it seems at the end was a missing "#define ..._PROTECTED" in the .c
> file that includes the generated .eo.c.
>
> I wonder: shouldn't the generated .eo.c write:
> #ifndef ..._PROTECTED
> #define ..._PROTECTED
> #endif
>

No. The .eo.c should be included at the end of the .c file and the .eo.h 
is at the beginning. You need to define the protected before the .h.

--
Tom


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

Re: [E-devel] problems with eo method overloading

[Gustavo Sverzut Barbieri]

it seems at the end was a missing "#define ..._PROTECTED" in the .c
file that includes the generated .eo.c.

I wonder: shouldn't the generated .eo.c write:
#ifndef ..._PROTECTED
#define ..._PROTECTED
#endif


On Mon, Aug 15, 2016 at 7:03 PM, Gustavo Sverzut Barbieri
 wrote:
> Hi all,
>
> If you get my branch devs/barbieri/efl-io-interfaces [1] you can see
> that the example efl_io_copier_example will fail to run with a strange
> error as below.
>
> The class hierarchy is:
>
>  - Efl.Io.Reader (interface), defines "can_read" property.
>  - Efl.Io.Reader.Fd (mixin on top of Efl.Io.Reader), implements "can_read"
>  - Efl.Io.Stdin (class on top of Efl.Loop.Fd and Efl.Io.Reader.Fd),
> links Efl.Loop.Fd "read" event to set "can_read = True".
>
> It is analogous for Efl.Io.Stdout, replacing "read" with "write".
> There is also a "Efl.Io.File" that goes much beyond that and use all
> the interfaces and open(2) a file.
>
> Now to the error:
>
> $ ./src/examples/ecore/efl_io_copier_example  - - # run stdin -> stdout
>
> # ignore "ERROR: unknown option -.
>
> ERR<4202>:eo lib/eo/eo.c:581 _eo_class_funcs_set() Class
> 'Efl_Io_Reader_Fd': NULL API not allowed (NULL->0x7f9d238c3c30
> 'efl_io_reader_can_read_get').
> ERR<4202>:eo lib/eo/eo.c:549 _efl_object_api_op_id_get() Unable to
> resolve op for api func 0x7f9d238c3940
> ERR<4202>:eo lib/eo/eo.c:581 _eo_class_funcs_set() Class
> 'Efl_Io_Writer_Fd': NULL API not allowed (NULL->0x7f9d238c4710
> 'efl_io_writer_can_write_get').
> ERR<4202>:eo lib/eo/eo.c:549 _efl_object_api_op_id_get() Unable to
> resolve op for api func 0x7f9d238c4450
> INFO: copy source=0x40003004 (Efl_Io_Stdin) to
> destination=0x40004005 (Efl_Io_Stdout)
>
> As you can see, efl_io_reader_can_read_get() fails to be detected
> although it was present in the Efl.Io.Reader.Fd [3][4]. Then when
> Efl.Loop.Fd triggers event "read", it will set
> efl_io_reader_can_read_set() [5] and it crashes when the signal
> activates:
>
> ==11923== Jump to the invalid address stated on the next line
> ==11923==at 0x0: ???
> ==11923==by 0x4E53A30: _efl_io_stdin_event_read (efl_io_stdin.c:16)
> ==11923==by 0x508FC97: _efl_object_event_callback_call 
> (eo_base_class.c:1176
> )
> ==11923==by 0x508E7A3: efl_event_callback_call (in 
> /home/gustavo/Development
> /git/efl/src/lib/eo/.libs/libeo.so.1.18.99)
> ==11923==by 0x4E51B98: _efl_loop_fd_read_cb (efl_loop_fd.c:34)
> ==11923==by 0x4E4FF11: _ecore_call_fd_cb (ecore_private.h:333)
> ==11923==by 0x4E4FF11: _ecore_main_fd_handlers_call (ecore_main.c:1974)
> ==11923==by 0x4E4FF11: _ecore_main_loop_iterate_internal 
> (ecore_main.c:2339)
> ==11923==by 0x4E503E6: ecore_main_loop_begin (ecore_main.c:1286)
> ==11923==by 0x109B1F: main (efl_io_copier_example.c:254)
> ==11923==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==11923==
> ==11923==
> ==11923== Process terminating with default action of signal 11
> (SIGSEGV): dumping core
> ==11923==  Bad permissions for mapped region at address 0x0
> ==11923==at 0x0: ???
> ==11923==by 0x4E53A30: _efl_io_stdin_event_read (efl_io_stdin.c:16)
> ==11923==by 0x508FC97: _efl_object_event_callback_call
> (eo_base_class.c:1176)
> ==11923==by 0x508E7A3: efl_event_callback_call (in
> /home/gustavo/Development/git/efl/src/lib/eo/.libs/libeo.so.1.18.99)
> ==11923==by 0x4E51B98: _efl_loop_fd_read_cb (efl_loop_fd.c:34)
> ==11923==by 0x4E4FF11: _ecore_call_fd_cb (ecore_private.h:333)
> ==11923==by 0x4E4FF11: _ecore_main_fd_handlers_call (ecore_main.c:1974)
> ==11923==by 0x4E4FF11: _ecore_main_loop_iterate_internal 
> (ecore_main.c:2339)
> ==11923==by 0x4E503E6: ecore_main_loop_begin (ecore_main.c:1286)
> ==11923==by 0x109B1F: main (efl_io_copier_example.c:254)
>
> If you try with the Efl.Io.File version by giving the example some
> real file, you get a similar error with the other class:
>
> $ ./src/examples/ecore/efl_io_copier_example  /tmp/src /tmp/dst
> ERR<12045>:eo lib/eo/eo.c:581 _eo_class_funcs_set() Class 'Efl_Io_Writer_Fd': 
> NU
> LL API not allowed (NULL->0x4e53710 'efl_io_writer_can_write_get').
> ERR<12045>:eo lib/eo/eo.c:581 _eo_class_funcs_set() Class 'Efl_Io_Reader_Fd': 
> NU
> LL API not allowed (NULL->0x4e52c30 'efl_io_reader_can_read_get').
> ERR<12045>:eo lib/eo/eo.c:626 _eo_class_funcs_set() Class 'Efl_Io_File': 
> Can't f
> ind api func description in class hierarchy (0x5d918f0->0x4e54c70) 
> (efl_io_reade
> r_read).
> ERR<12045>:eo lib/eo/eo.c:549 _efl_object_api_op_id_get() Unable to
> resolve op for api func 0x4e543d0
> ERROR: could not open '/tmp/src' for read.
>
> This was due efl_io_reader_read() not found.
>
> Then clearly I'm missing some detail with eolian/.eo files, advices?
>
> BR,
>
>
> [1] 
> https://git.enlightenment.org/core/efl.git/log/?h=devs/barbieri/efl-io-interfaces
> [2] 
>