Re: [E-devel] What are we going to release?

[Carsten Haitzler]

On Wed, 06 Dec 2017 19:45:39 -0500 Cedric Bail  said:

> Hi,
> 
> >  Original Message 
> > Subject: Re: [E-devel] What are we going to release?
> > Local Time: December 6, 2017 6:13 AM
> > UTC Time: December 6, 2017 2:13 PM
> > From: dan...@octaforge.org
> > To: enlightenment-devel@lists.sourceforge.net
> >
> > On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote:
> >
> >> Hi all,
> >> As our last release was over 4 months ago I think we really need to
> >> figure
> >> what the next release will be, and when, so we can start focusing on
> >> making
> >> that subsection of our work releasable.
> >> Clearly we are not going to get the interfaces completed any time soon.
> >> The
> >> list of things to port keeps getting longer and we have too many
> >> outstanding patches to count. I have heard suggestions that we could
> >> release a subset, for example Efl_Core and Efl_Net now that they we have
> >> the Efl namespace split into groups.
> >> This would mean releasing the API (
> >> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
> >> efl_net, efl_event or efl_loop and that's about it (as well as eina and
> >> eo
> >> which need to get merged into the non-legacy docs somehow).
> >> Is this a good approach? Right now it seems like we need to focus on
> >> completing portions of this and cut a release of some sort so that we can
> >> have people look at usage, bindings and porting existing code. I'd love
> >> to
> >> get our website updated to filter just the APIs we plan to release soon.
> >> And then generate another section for the work-in-progress completion of
> >> interfaces...
> >>
> >> Hi,
> >>
> >> I told you on IRC already but I'm going to say it here publicly -
> >> personally I don't think it's a good idea to release APIs unless we're
> >> sure that it's really the API we want (i.e. it can be defined in Eolian
> >> once it's stable, it can be used for bindings and it's
> >> real-world-tested, i.e. we're sure of its practicality). I don't see any
> >> real benefit in releasing a subset of our APIs, only potential issues.
> 
> We have been working on EFL interfaces for years now. Literrally. We have to
> do a release in the next 6 months. The main question is how to get there and
> have something good enough for everyone.
> 
> My current take is that we finish cleaning up Efl_Core and Efl_Net for a beta
> release (which mean no further change except if something is really bad) and
> do an EFL release with that. This would make it possible for people who want
> to do binding to start working on it and report problem they have during 1.22
> release cycle. This would be the only time we could still break our API in my
> point of view, but only if it is asked by binding developers. Finally for EFL
> 1.22, we will release an Efl_Ui component. and everything below will also be
> marked stable.

ALL of eo/interfaces is already released as "beta". has been now for a very
long time. how does this change anything? we have NEEDED to make changes that
have broken what we have. i don;'t see this as any change to the current status.

> This mean the remaining question is what is left to do for this. On my side :
> - Remove reference to graphic interface when including Efl_Core/Efl_Net.
> - Finish migration to Eina_Future
> 
> If you have still some stuff on your plate, you should let us know. I do feel
> that for helping Stefan we should open a ticket to track this last task until
> a release.
> 
> Cedric
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


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


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

Re: [E-devel] What are we going to release?

[Carsten Haitzler]

On Wed, 06 Dec 2017 15:13:05 +0100 Daniel Kolesa  said:

> On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote:
> > Hi all,
> > 
> > As our last release was over 4 months ago I think we really need to
> > figure
> > what the next release will be, and when, so we can start focusing on
> > making
> > that subsection of our work releasable.
> > 
> > Clearly we are not going to get the interfaces completed any time soon.
> > The
> > list of things to port keeps getting longer and we have too many
> > outstanding patches to count. I have heard suggestions that we could
> > release a subset, for example Efl_Core and Efl_Net now that they we have
> > the Efl namespace split into groups.
> > This would mean releasing the API (
> > https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
> > efl_net, efl_event or efl_loop and that's about it (as well as eina and
> > eo
> > which need to get merged into the non-legacy docs somehow).
> > 
> > Is this a good approach? Right now it seems like we need to focus on
> > completing portions of this and cut a release of some sort so that we can
> > have people look at usage, bindings and porting existing code. I'd love
> > to
> > get our website updated to filter just the APIs we plan to release soon.
> > And then generate another section for the work-in-progress completion of
> > interfaces...
> 
> Hi,
> 
> I told you on IRC already but I'm going to say it here publicly -
> personally I don't think it's a good idea to release APIs unless we're
> sure that it's really the API we want (i.e. it can be defined in Eolian
> once it's stable, it can be used for bindings and it's
> real-world-tested, i.e. we're sure of its practicality). I don't see any
> real benefit in releasing a subset of our APIs, only potential issues.

I agree with Daniel here. Releasing just for the "need to release something".
These efl core/net API's rely on sharing concepts, interfaces etc. with the
rest of efl if we are to do it right, and that is still evolving as things
solidify. There is no value at all in releasing a subset like this. It's
useless without having a large enough set of epi's to usefully build
applications from top to bottom. Sure - ignore efreet, ethumb, eet etc. in eo
API for now. We could release eo API's without these once eo API is settled on
and releasable. But certainly not some tiny subset like above.

I'm currently working on efl_loop and related in an effort to pad out this bit
and have something for people to look and and reviews, comment on etc. But the
past week or so I've been busy with other things.

> However, I  do think it's maybe a good subset to aim for stabilizing
> first - maybe we could make use of it to set some kind of better
> direction to make our progress faster.
> 
> D5
> 
> > 
> > Thanks,
> > 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
> 


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


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

Re: [E-devel] What are we going to release?

[Cedric Bail]

Hi,

>  Original Message 
> Subject: Re: [E-devel] What are we going to release?
> Local Time: December 6, 2017 6:13 AM
> UTC Time: December 6, 2017 2:13 PM
> From: dan...@octaforge.org
> To: enlightenment-devel@lists.sourceforge.net
>
> On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote:
>
>> Hi all,
>> As our last release was over 4 months ago I think we really need to
>> figure
>> what the next release will be, and when, so we can start focusing on
>> making
>> that subsection of our work releasable.
>> Clearly we are not going to get the interfaces completed any time soon.
>> The
>> list of things to port keeps getting longer and we have too many
>> outstanding patches to count. I have heard suggestions that we could
>> release a subset, for example Efl_Core and Efl_Net now that they we have
>> the Efl namespace split into groups.
>> This would mean releasing the API (
>> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
>> efl_net, efl_event or efl_loop and that's about it (as well as eina and
>> eo
>> which need to get merged into the non-legacy docs somehow).
>> Is this a good approach? Right now it seems like we need to focus on
>> completing portions of this and cut a release of some sort so that we can
>> have people look at usage, bindings and porting existing code. I'd love
>> to
>> get our website updated to filter just the APIs we plan to release soon.
>> And then generate another section for the work-in-progress completion of
>> interfaces...
>>
>> Hi,
>>
>> I told you on IRC already but I'm going to say it here publicly -
>> personally I don't think it's a good idea to release APIs unless we're
>> sure that it's really the API we want (i.e. it can be defined in Eolian
>> once it's stable, it can be used for bindings and it's
>> real-world-tested, i.e. we're sure of its practicality). I don't see any
>> real benefit in releasing a subset of our APIs, only potential issues.

We have been working on EFL interfaces for years now. Literrally. We have to do 
a release in the next 6 months. The main question is how to get there and have 
something good enough for everyone.

My current take is that we finish cleaning up Efl_Core and Efl_Net for a beta 
release (which mean no further change except if something is really bad) and do 
an EFL release with that. This would make it possible for people who want to do 
binding to start working on it and report problem they have during 1.22 release 
cycle. This would be the only time we could still break our API in my point of 
view, but only if it is asked by binding developers. Finally for EFL 1.22, we 
will release an Efl_Ui component. and everything below will also be marked 
stable.

This mean the remaining question is what is left to do for this. On my side :
- Remove reference to graphic interface when including Efl_Core/Efl_Net.
- Finish migration to Eina_Future

If you have still some stuff on your plate, you should let us know. I do feel 
that for helping Stefan we should open a ticket to track this last task until a 
release.

Cedric
--
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] What are we going to release?

[Daniel Kolesa]

On Wed, Dec 6, 2017, at 14:26, Andrew Williams wrote:
> Hi all,
> 
> As our last release was over 4 months ago I think we really need to
> figure
> what the next release will be, and when, so we can start focusing on
> making
> that subsection of our work releasable.
> 
> Clearly we are not going to get the interfaces completed any time soon.
> The
> list of things to port keeps getting longer and we have too many
> outstanding patches to count. I have heard suggestions that we could
> release a subset, for example Efl_Core and Efl_Net now that they we have
> the Efl namespace split into groups.
> This would mean releasing the API (
> https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
> efl_net, efl_event or efl_loop and that's about it (as well as eina and
> eo
> which need to get merged into the non-legacy docs somehow).
> 
> Is this a good approach? Right now it seems like we need to focus on
> completing portions of this and cut a release of some sort so that we can
> have people look at usage, bindings and porting existing code. I'd love
> to
> get our website updated to filter just the APIs we plan to release soon.
> And then generate another section for the work-in-progress completion of
> interfaces...

Hi,

I told you on IRC already but I'm going to say it here publicly -
personally I don't think it's a good idea to release APIs unless we're
sure that it's really the API we want (i.e. it can be defined in Eolian
once it's stable, it can be used for bindings and it's
real-world-tested, i.e. we're sure of its practicality). I don't see any
real benefit in releasing a subset of our APIs, only potential issues.

However, I  do think it's maybe a good subset to aim for stabilizing
first - maybe we could make use of it to set some kind of better
direction to make our progress faster.

D5

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

[E-devel] What are we going to release?

[Andrew Williams]

Hi all,

As our last release was over 4 months ago I think we really need to figure
what the next release will be, and when, so we can start focusing on making
that subsection of our work releasable.

Clearly we are not going to get the interfaces completed any time soon. The
list of things to port keeps getting longer and we have too many
outstanding patches to count. I have heard suggestions that we could
release a subset, for example Efl_Core and Efl_Net now that they we have
the Efl namespace split into groups.
This would mean releasing the API (
https://www.enlightenment.org/develop/api/start) that is prefixed efl_io,
efl_net, efl_event or efl_loop and that's about it (as well as eina and eo
which need to get merged into the non-legacy docs somehow).

Is this a good approach? Right now it seems like we need to focus on
completing portions of this and cut a release of some sort so that we can
have people look at usage, bindings and porting existing code. I'd love to
get our website updated to filter just the APIs we plan to release soon.
And then generate another section for the work-in-progress completion of
interfaces...

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

Re: [E-devel] [EGIT] [core/efl] master 06/06: eolian: pass state where necessary

[Daniel Kolesa]

On Wed, Dec 6, 2017, at 10:22, Jean-Philippe André wrote:
> This breaks the C# bindings as some Eolian APIs are changed :(

Then the C# binding people should fix that themselves. Eolian is
unstable API right now and if you add in new code relying on it then
you're responsible for it. I'm not going to deal with any new bindings
code introduced into our repository at this point, not JS, not C#,
sorry.

D5

> 
> On Wed, Dec 6, 2017 at 12:42 AM, Daniel Kolesa 
> wrote:
> 
> > q66 pushed a commit to branch master.
> >
> > http://git.enlightenment.org/core/efl.git/commit/?id=
> > 8a1f93f698315b43de28b755bce5fc9a4d85d59a
> >
> > commit 8a1f93f698315b43de28b755bce5fc9a4d85d59a
> > Author: Daniel Kolesa 
> > Date:   Tue Dec 5 16:40:04 2017 +0100
> >
> > eolian: pass state where necessary
> >
> > This modifies the API so that global state removal is made
> > possible. It's still used internally for now but externally
> > the state is contained.
> > ---
> >  src/bin/eolian/main.c|   9 ++-
> >  src/bin/eolian_cxx/eolian_cxx.cc |  23 +--
> >  src/bindings/luajit/eolian.lua   |  96 
> >  src/lib/eolian/Eolian.h  | 116 +++---
> > 
> >  src/lib/eolian/eolian_database.c |  20 +++---
> >  src/scripts/elua/modules/lualian.lua |  16 +++--
> >  src/tests/eolian/eolian_parsing.c| 119 ++
> > -
> >  7 files changed, 258 insertions(+), 141 deletions(-)
> >
> > diff --git a/src/bin/eolian/main.c b/src/bin/eolian/main.c
> > index fdb5ca2568..92643c6f7e 100644
> > --- a/src/bin/eolian/main.c
> > +++ b/src/bin/eolian/main.c
> > @@ -430,6 +430,8 @@ main(int argc, char **argv)
> > eina_init();
> > eolian_init();
> >
> > +   Eolian *eos = eolian_new();
> > +
> > const char *dom = "eolian_gen";
> > _eolian_gen_log_dom = eina_log_domain_register(dom, EINA_COLOR_GREEN);
> > if (_eolian_gen_log_dom < 0)
> > @@ -530,7 +532,7 @@ main(int argc, char **argv)
> >
> > if (scan_system)
> >   {
> > -if (!eolian_system_directory_scan())
> > +if (!eolian_system_directory_scan(eos))
> >{
> >   fprintf(stderr, "eolian: could not scan system directory\n");
> >   goto end;
> > @@ -540,14 +542,14 @@ main(int argc, char **argv)
> > const char *inc;
> > EINA_LIST_FREE(includes, inc)
> >   {
> > -if (!eolian_directory_scan(inc))
> > +if (!eolian_directory_scan(eos, inc))
> >{
> >   fprintf(stderr, "eolian: could not scan '%s'\n", inc);
> >   goto end;
> >}
> >   }
> >
> > -   const Eolian_Unit *src = eolian_file_parse(input);
> > +   const Eolian_Unit *src = eolian_file_parse(eos, input);
> > if (!src)
> >   {
> >  fprintf(stderr, "eolian: could not parse file '%s'\n", input);
> > @@ -589,6 +591,7 @@ end:
> >   free(outs[i]);
> > free(basen);
> >
> > +   eolian_free(eos);
> > eolian_shutdown();
> > eina_shutdown();
> >
> > diff --git a/src/bin/eolian_cxx/eolian_cxx.cc b/src/bin/eolian_cxx/eolian_
> > cxx.cc
> > index 134700ae6c..fac96da5e2 100644
> > --- a/src/bin/eolian_cxx/eolian_cxx.cc
> > +++ b/src/bin/eolian_cxx/eolian_cxx.cc
> > @@ -34,6 +34,7 @@ struct options_type
> >  {
> > std::vector include_dirs;
> > std::vector in_files;
> > +   mutable Eolian* state;
> > mutable Eolian_Unit const* unit;
> > std::string out_file;
> > bool main_header;
> > @@ -298,7 +299,7 @@ run(options_type const& opts)
> >
> > for(auto&& name : opts.in_files)
> >   {
> > -   Eolian_Unit const* unit = ::eolian_file_parse(name.c_str());
> > +   Eolian_Unit const* unit = ::eolian_file_parse(opts.state,
> > name.c_str());
> > if(!unit)
> >   {
> > EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
> > @@ -346,17 +347,30 @@ run(options_type const& opts)
> >  }
> >
> >  static void
> > +state_init(options_type const& opts)
> > +{
> > +   Eolian *eos = ::eolian_new();
> > +   if (!eos)
> > + {
> > +EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
> > +  << "Eolian failed creating state";
> > +assert(false && "Error creating Eolian state");
> > + }
> > +   opts.state = eos;
> > +}
> > +
> > +static void
> >  database_load(options_type const& opts)
> >  {
> > for (auto src : opts.include_dirs)
> >   {
> > -if (!::eolian_directory_scan(src.c_str()))
> > +if (!::eolian_directory_scan(opts.state, src.c_str()))
> >{
> >   EINA_CXX_DOM_LOG_WARN(eolian_cxx::domain)
> > << "Couldn't load eolian from '" << src << "'.";
> >}
> >   }
> > -   if (!::eolian_all_eot_files_parse())
> > +   if (!::eolian_all_eot_files_parse(opts.state))
> >   {
> >  EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
> ><< "Eolian failed 

Re: [E-devel] Rust bindings

[Andrew Williams]

I too was looking at a Rust binding.
The auto-generated one has dome bit-pack issues I have not resolved.
Ideally this would be largely automatic through Eo - but first you need to
map the eina equivalent into native space  and that is pretty much manual...

Andy

On Wed, 6 Dec 2017 at 10:13 Vincent Torri  wrote:

> shouldn't binding be automatically generated ?
>
> Vincent
>
> On Wed, Dec 6, 2017 at 3:09 AM, Vinícius dos Santos Oliveira
>  wrote:
> > 2017-12-05 23:54 GMT-03:00 Cedric Bail :
> >
> >> Care to share the link to that repo you found ?
> >>
> >
> > https://github.com/arlowhite/rust-efl
> >
> > --
> > Vinícius dos Santos Oliveira
> > https://vinipsmaker.github.io/
> >
> --
> > 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
>
-- 
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

Re: [E-devel] Rust bindings

[Vinícius dos Santos Oliveira]

2017-12-06 7:12 GMT-03:00 Vincent Torri :

> shouldn't binding be automatically generated ?


Does this have something to do with Eo? Is it ready?

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
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] Rust bindings

[Vincent Torri]

shouldn't binding be automatically generated ?

Vincent

On Wed, Dec 6, 2017 at 3:09 AM, Vinícius dos Santos Oliveira
 wrote:
> 2017-12-05 23:54 GMT-03:00 Cedric Bail :
>
>> Care to share the link to that repo you found ?
>>
>
> https://github.com/arlowhite/rust-efl
>
> --
> Vinícius dos Santos Oliveira
> https://vinipsmaker.github.io/
> --
> 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] [EGIT] [core/efl] master 06/06: eolian: pass state where necessary

[Jean-Philippe André]

This breaks the C# bindings as some Eolian APIs are changed :(

On Wed, Dec 6, 2017 at 12:42 AM, Daniel Kolesa  wrote:

> q66 pushed a commit to branch master.
>
> http://git.enlightenment.org/core/efl.git/commit/?id=
> 8a1f93f698315b43de28b755bce5fc9a4d85d59a
>
> commit 8a1f93f698315b43de28b755bce5fc9a4d85d59a
> Author: Daniel Kolesa 
> Date:   Tue Dec 5 16:40:04 2017 +0100
>
> eolian: pass state where necessary
>
> This modifies the API so that global state removal is made
> possible. It's still used internally for now but externally
> the state is contained.
> ---
>  src/bin/eolian/main.c|   9 ++-
>  src/bin/eolian_cxx/eolian_cxx.cc |  23 +--
>  src/bindings/luajit/eolian.lua   |  96 
>  src/lib/eolian/Eolian.h  | 116 +++---
> 
>  src/lib/eolian/eolian_database.c |  20 +++---
>  src/scripts/elua/modules/lualian.lua |  16 +++--
>  src/tests/eolian/eolian_parsing.c| 119 ++
> -
>  7 files changed, 258 insertions(+), 141 deletions(-)
>
> diff --git a/src/bin/eolian/main.c b/src/bin/eolian/main.c
> index fdb5ca2568..92643c6f7e 100644
> --- a/src/bin/eolian/main.c
> +++ b/src/bin/eolian/main.c
> @@ -430,6 +430,8 @@ main(int argc, char **argv)
> eina_init();
> eolian_init();
>
> +   Eolian *eos = eolian_new();
> +
> const char *dom = "eolian_gen";
> _eolian_gen_log_dom = eina_log_domain_register(dom, EINA_COLOR_GREEN);
> if (_eolian_gen_log_dom < 0)
> @@ -530,7 +532,7 @@ main(int argc, char **argv)
>
> if (scan_system)
>   {
> -if (!eolian_system_directory_scan())
> +if (!eolian_system_directory_scan(eos))
>{
>   fprintf(stderr, "eolian: could not scan system directory\n");
>   goto end;
> @@ -540,14 +542,14 @@ main(int argc, char **argv)
> const char *inc;
> EINA_LIST_FREE(includes, inc)
>   {
> -if (!eolian_directory_scan(inc))
> +if (!eolian_directory_scan(eos, inc))
>{
>   fprintf(stderr, "eolian: could not scan '%s'\n", inc);
>   goto end;
>}
>   }
>
> -   const Eolian_Unit *src = eolian_file_parse(input);
> +   const Eolian_Unit *src = eolian_file_parse(eos, input);
> if (!src)
>   {
>  fprintf(stderr, "eolian: could not parse file '%s'\n", input);
> @@ -589,6 +591,7 @@ end:
>   free(outs[i]);
> free(basen);
>
> +   eolian_free(eos);
> eolian_shutdown();
> eina_shutdown();
>
> diff --git a/src/bin/eolian_cxx/eolian_cxx.cc b/src/bin/eolian_cxx/eolian_
> cxx.cc
> index 134700ae6c..fac96da5e2 100644
> --- a/src/bin/eolian_cxx/eolian_cxx.cc
> +++ b/src/bin/eolian_cxx/eolian_cxx.cc
> @@ -34,6 +34,7 @@ struct options_type
>  {
> std::vector include_dirs;
> std::vector in_files;
> +   mutable Eolian* state;
> mutable Eolian_Unit const* unit;
> std::string out_file;
> bool main_header;
> @@ -298,7 +299,7 @@ run(options_type const& opts)
>
> for(auto&& name : opts.in_files)
>   {
> -   Eolian_Unit const* unit = ::eolian_file_parse(name.c_str());
> +   Eolian_Unit const* unit = ::eolian_file_parse(opts.state,
> name.c_str());
> if(!unit)
>   {
> EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
> @@ -346,17 +347,30 @@ run(options_type const& opts)
>  }
>
>  static void
> +state_init(options_type const& opts)
> +{
> +   Eolian *eos = ::eolian_new();
> +   if (!eos)
> + {
> +EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
> +  << "Eolian failed creating state";
> +assert(false && "Error creating Eolian state");
> + }
> +   opts.state = eos;
> +}
> +
> +static void
>  database_load(options_type const& opts)
>  {
> for (auto src : opts.include_dirs)
>   {
> -if (!::eolian_directory_scan(src.c_str()))
> +if (!::eolian_directory_scan(opts.state, src.c_str()))
>{
>   EINA_CXX_DOM_LOG_WARN(eolian_cxx::domain)
> << "Couldn't load eolian from '" << src << "'.";
>}
>   }
> -   if (!::eolian_all_eot_files_parse())
> +   if (!::eolian_all_eot_files_parse(opts.state))
>   {
>  EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
><< "Eolian failed parsing eot files";
> @@ -368,7 +382,7 @@ database_load(options_type const& opts)
>   << "No input file.";
> assert(false && "Error parsing input file");
>   }
> -   if (!opts.main_header && !::eolian_file_parse(opts.in_
> files[0].c_str()))
> +   if (!opts.main_header && !::eolian_file_parse(opts.state,
> opts.in_files[0].c_str()))
>   {
> EINA_CXX_DOM_LOG_ERR(eolian_cxx::domain)
>   << "Failed parsing: " << opts.in_files[0] << ".";
> @@ -480,6 +494,7 @@ int main(int argc, char **argv)
>  efl::eina::eina_init eina_init;
>  efl::eolian::eolian_init 

Re: [E-devel] Blend2D - a gfx framework with dynamic pipelines support

[Vinícius dos Santos Oliveira]

2017-12-06 4:56 GMT-03:00 Carsten Haitzler :

> [...]


That was very informative. Thank you.

-- 
Vinícius dos Santos Oliveira
https://vinipsmaker.github.io/
--
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