[E-devel] 1.20.7 edje_cc illegal instruction error
Hello, I tried to compile, but always fails: /bin/sh: 2. sor: 4171 illegal instruction(core dumped) EFL_RUN_IN_TREE=1 ../src/bin/edje/edje_cc -id . -fd . -id ./modules/ethumb/emotion modules/ethumb/emotion/template.edc modules/ethumb/emotion/template.edj I have an Intel(R) Celeron(R) CPU B815 processor, and - for compatibility reasons - I want to compile it with -march=k8. I tried to open a ticket in Phabricator, but massively marked as spam: https://phab.enlightenment.org/T6989 I tried to compile with -march=k8-sse3 and -march=x86-64, but the build also fails with „illegal instrucion” error. Any ideas? -- R. -- 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] End of Week: Phab Report
Hi, Stefan usually sends this mail on Mondays, but I'm not usually as motivated as him on that day so I'm doing it today so everyone can enjoy it over the weekend or when they wake up on Monday. TICKETS https://phab.enlightenment.org/maniphest/query/hpAKElh.jGsu/#R 81 "urgent" tasks open which we should be considering for the alpha release Not all of these may NEED to be resolved for a release to happen. If you see a ticket that has the 1.21 milestone tagged but realistically will not or cannot be fixed in time, please untag the milestone! https://phab.enlightenment.org/maniphest/query/J.XvOeCxrS2D/#R 8 regression tickets which must be resolved before the final 1.21 release https://phab.enlightenment.org/maniphest/query/.A.JB1lE_L6b/#R 17 untriaged tasks which should have a severity tagged PATCHES https://phab.enlightenment.org/differential/query/gIFEVr3jmk.q/#R 32 patches awaiting review Patch review is important too! Build status is green at present, tests are all passing as well. 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
Re: [E-devel] Clouseau Is Broken
Is there a reason why the clouseau wrapper no longer works? Surely that functionality could have been kept to avoid cases like this... On Fri, Jun 15, 2018 at 3:19 AM Daniel Zaoui wrote: > Hi, > > I updated the wiki (https://phab.enlightenment.org/w/projects/clouseau/) > with references to the article that Marcel provided. > > You are right, the wiki should have been updated. I will flog myself :-) > > Anyway, I pushed a patch to not have to enable the clouseau debugging from > elm config. So you will just have to run the daemon, your app and then the > clouseau client. > > I will soon deal with the infinite loop. > > D2 > > On Thu, 14 Jun 2018 21:41:36 +0200 > Marcel Hollerbach wrote: > > > Just as a site note, there is a wiki article called clouseau. > > Which is found under the category debugging :) > > > > > https://www.enlightenment.org/playground/Tools/Clouseau/about-clouseau.md > > > > Greetings, > > bu5hm4n > > > > On 06/14/2018 06:07 PM, Stephen Houston wrote: > > > I have created a ticket here for Clouseau being broken: > > > https://phab.enlightenment.org/T7017 > > > > > > Basically - There is no documentation on how to use clouseau, and > > > when you finally figure it out, you get an endless progressbar. > > > > > > As we are making a big push to fix things and clean up our code > > > base for an alpha release soon - Clouseau is a tool that is very > > > useful in debugging and helping to find and fix problems. I > > > suggest we get this resolved ASAP. > > > > > > Stephen > > > > -- > > > 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] Build systems
We have made our decision and are going to be on meson for the foreseeable future. We just moved and changing build systems on a project this size is a massive amount of work. Not going to change. On Fri, Jun 15, 2018, 2:17 PM William L. Thomson Jr. < wlt...@obsidian-studios.com> wrote: > On Thu, 24 May 2018 17:54:32 -0400 > "William L. Thomson Jr." wrote: > > > To toss another out there, also Gradle, seems it maybe more robust in > > ways than Bazel or Buck. > > https://docs.gradle.org/current/userguide/native_software.html > > Rather interesting, I had not noticed at the time of mention. Gradle is > used to build JavaFX. Which a considerable portion is native code, not > Java. Making it a tad difficult for me to package as there is nothing > to build the native code other than gradle. Other projects tend to mix > in like make for the native parts, even Maven. > https://github.com/javafxports/openjdk-jfx > > Look in native directories, just headers and c files. > > https://github.com/javafxports/openjdk-jfx/tree/develop/modules/javafx.graphics/src/main > > They have Travis building under OS X for example and Linux. > https://travis-ci.org/javafxports/openjdk-jfx > > Then Appveyor for Windows > https://ci.appveyor.com/project/javafxports-github-bot/openjdk-jfx > > The one aspect I like of gradle is no middle wear. Both CMake and Meson > are middle wear. They both output to another format responsible for the > build. Where this seems to do direct building. No generation of some > file something else uses for build. > > No clue as to using like ccache or other stuff for native code. But > does make Gradle rather interesting. I would not even consider using > Meson for building Java code. That Gradle can do Java and other > languages. May make it start to rise to the top for build systems. > It has to be hands down the easiest one to install on any OS. > > -- > William L. Thomson Jr. > > -- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Build systems
On Thu, 24 May 2018 17:54:32 -0400 "William L. Thomson Jr." wrote: > To toss another out there, also Gradle, seems it maybe more robust in > ways than Bazel or Buck. > https://docs.gradle.org/current/userguide/native_software.html Rather interesting, I had not noticed at the time of mention. Gradle is used to build JavaFX. Which a considerable portion is native code, not Java. Making it a tad difficult for me to package as there is nothing to build the native code other than gradle. Other projects tend to mix in like make for the native parts, even Maven. https://github.com/javafxports/openjdk-jfx Look in native directories, just headers and c files. https://github.com/javafxports/openjdk-jfx/tree/develop/modules/javafx.graphics/src/main They have Travis building under OS X for example and Linux. https://travis-ci.org/javafxports/openjdk-jfx Then Appveyor for Windows https://ci.appveyor.com/project/javafxports-github-bot/openjdk-jfx The one aspect I like of gradle is no middle wear. Both CMake and Meson are middle wear. They both output to another format responsible for the build. Where this seems to do direct building. No generation of some file something else uses for build. No clue as to using like ccache or other stuff for native code. But does make Gradle rather interesting. I would not even consider using Meson for building Java code. That Gradle can do Java and other languages. May make it start to rise to the top for build systems. It has to be hands down the easiest one to install on any OS. -- William L. Thomson Jr. pgp2Pg7hZ7W_d.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Windows CI via AppVeyor
Since EFL has support for Windows. Someone may want to consider adding AppVeyor to the Github mirror for CI under Windows. https://en.wikipedia.org/wiki/AppVeyor https://ci.appveyor.com/ Then there will be CI for Linux, OS X and Windows. Which would push EFL further ahead of others. -- William L. Thomson Jr. pgpH7i9zBjyRM.pgp Description: OpenPGP digital signature -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [EGIT] [core/efl] master 01/01: evas vg: prevent a corner-case crash.
Yes, I was referring to unit tests. It would be ideal if a unit test could
be added for all issues to ensure that they do not occur again.
On Fri, Jun 15, 2018 at 12:39 AM Hermet Park wrote:
> ok, will.
>
> On Fri, Jun 15, 2018 at 12:41 PM, Vincent Torri
> wrote:
>
> > On Fri, Jun 15, 2018 at 4:05 AM, Hermet Park
> wrote:
> > > Eo* obj = evas_object_vg_add(canvas);
> > > Efl_VG* root = evas_vg_container_add(obj);
> > > evas_object_vg_root_node_set(obj, root);
> > > efl_parent_set(root, NULL);
> > >
> > > **crash**
> >
> > maybe a unit test should be added ?
> >
> > Vincent
> >
> > >
> > >
> > > On Fri, Jun 15, 2018 at 1:17 AM, Mike Blumenkrantz <
> > > michael.blumenkra...@gmail.com> wrote:
> > >
> > >> Are there tests for any of these things that are being fixed?
> > >>
> > >> On Thu, Jun 14, 2018 at 12:11 PM Hermet Park
> > wrote:
> > >>
> > >> > hermet pushed a commit to branch master.
> > >> >
> > >> >
> > >> > http://git.enlightenment.org/core/efl.git/commit/?id=
> > >> c8c0dbb32bd7f38b0faf524b1a55585f99d1cb17
> > >> >
> > >> > commit c8c0dbb32bd7f38b0faf524b1a55585f99d1cb17
> > >> > Author: Hermet Park
> > >> > Date: Fri Jun 15 01:00:53 2018 +0900
> > >> >
> > >> > evas vg: prevent a corner-case crash.
> > >> >
> > >> > tbh, current vg interfaces a little bit bad... here is one
> > scenario
> > >> to
> > >> > this
> > >> > stupid case.
> > >> >
> > >> > efl_parent_set() and evas_object_vg_root_node_set() both do
> > re-parent
> > >> > job. They could be conflicted if user calls both apis in either
> > way.
> > >> >
> > >> > efl_parent_set(root_node, NULL); but Vg Object still keeps the
> > root
> > >> > node
> > >> > which is just a dangling pointer that occurs a crash while
> > rendering.
> > >> > ---
> > >> > src/lib/evas/canvas/efl_canvas_vg_object.c | 2 ++
> > >> > src/lib/evas/canvas/evas_vg_node.c | 23
> > +++
> > >> > src/lib/evas/canvas/evas_vg_private.h | 5 +
> > >> > 3 files changed, 30 insertions(+)
> > >> >
> > >> > diff --git a/src/lib/evas/canvas/efl_canvas_vg_object.c
> > >> > b/src/lib/evas/canvas/efl_canvas_vg_object.c
> > >> > index c39fc5b980..cfd1898326 100644
> > >> > --- a/src/lib/evas/canvas/efl_canvas_vg_object.c
> > >> > +++ b/src/lib/evas/canvas/efl_canvas_vg_object.c
> > >> > @@ -172,6 +172,8 @@ _efl_canvas_vg_object_root_node_set(Eo *obj,
> > >> > Efl_Canvas_Vg_Object_Data *pd, Efl_
> > >> >
> > >> > // set the parent so that vg canvas can render it.
> > >> > efl_parent_set(pd->user_entry->root, pd->root);
> > >> > +
> > >> > +efl_canvas_vg_node_root_set(root_node, obj);
> > >> > }
> > >> > else if (pd->user_entry)
> > >> > {
> > >> > diff --git a/src/lib/evas/canvas/evas_vg_node.c
> > >> > b/src/lib/evas/canvas/evas_vg_node.c
> > >> > index ac054d4c07..1427beb693 100644
> > >> > --- a/src/lib/evas/canvas/evas_vg_node.c
> > >> > +++ b/src/lib/evas/canvas/evas_vg_node.c
> > >> > @@ -322,9 +322,24 @@ _efl_canvas_vg_node_efl_object_parent_set(Eo
> > *obj,
> > >> > {
> > >> > Efl_Canvas_Vg_Container_Data *cd = NULL;
> > >> > Efl_Canvas_Vg_Container_Data *old_cd;
> > >> > + Efl_Canvas_Vg_Node_Data *nd;
> > >> > Efl_VG *old_parent;
> > >> > Eina_Bool parent_container = EINA_TRUE;
> > >> >
> > >> > + nd = efl_data_scope_get(obj, MY_CLASS);
> > >> > +
> > >> > + //No, prevent infinite calls parent_set() -> root_node_set() ->
> > >> > parent_set() -> ...
> > >> > + if (nd->parenting) return;
> > >> > +
> > >> > + //Cut off root node from vg object if it does
> > >> > + if (nd->vg_obj)
> > >> > + {
> > >> > +nd->parenting = EINA_TRUE;
> > >> > +evas_object_vg_root_node_set(nd->vg_obj, NULL);
> > >> > +nd->parenting = EINA_FALSE;
> > >> > +nd->vg_obj = NULL;
> > >> > + }
> > >> > +
> > >> > if (efl_isa(parent, EFL_CANVAS_VG_CONTAINER_CLASS))
> > >> > cd = efl_data_scope_get(parent,
> EFL_CANVAS_VG_CONTAINER_CLASS);
> > >> > else if (efl_isa(parent, EFL_CANVAS_VG_OBJECT_CLASS))
> > >> > @@ -707,6 +722,14 @@ _efl_canvas_vg_node_efl_gfx_path_interpolate(Eo
> > >> *obj,
> > >> > Efl_Canvas_Vg_Node_Data *p
> > >> > return EINA_TRUE;
> > >> > }
> > >> >
> > >> > +void
> > >> > +efl_canvas_vg_node_root_set(Efl_VG *node, Efl_VG *vg_obj)
> > >> > +{
> > >> > + Efl_Canvas_Vg_Node_Data *nd = efl_data_scope_get(node,
> MY_CLASS);
> > >> > + nd->vg_obj = vg_obj;
> > >> > +}
> > >> > +
> > >> > +
> > >> > EOLIAN static Efl_VG *
> > >> > _efl_canvas_vg_node_efl_duplicate_duplicate(const Eo *obj,
> > >> > Efl_Canvas_Vg_Node_Data *pd)
> > >> > {
> > >> > diff --git a/src/lib/evas/canvas/evas_vg_private.h
> > >> > b/src/lib/evas/canvas/evas_vg_private.h
> > >> > index 4ff8b2bb45..cc43fb03ab 100644
> > >> > --- a/src/lib/evas/canvas/evas_vg_private.h
> > >> > +++ b/src/lib/evas/canvas/evas_vg_private.h
> > >> > @@ -62,6 +62,8 @@ struct _Efl_Canvas_Vg_Node_Data
> > >> >
Re: [E-devel] Clouseau Is Broken
Hi, I updated the wiki (https://phab.enlightenment.org/w/projects/clouseau/) with references to the article that Marcel provided. You are right, the wiki should have been updated. I will flog myself :-) Anyway, I pushed a patch to not have to enable the clouseau debugging from elm config. So you will just have to run the daemon, your app and then the clouseau client. I will soon deal with the infinite loop. D2 On Thu, 14 Jun 2018 21:41:36 +0200 Marcel Hollerbach wrote: > Just as a site note, there is a wiki article called clouseau. > Which is found under the category debugging :) > > https://www.enlightenment.org/playground/Tools/Clouseau/about-clouseau.md > > Greetings, > bu5hm4n > > On 06/14/2018 06:07 PM, Stephen Houston wrote: > > I have created a ticket here for Clouseau being broken: > > https://phab.enlightenment.org/T7017 > > > > Basically - There is no documentation on how to use clouseau, and > > when you finally figure it out, you get an endless progressbar. > > > > As we are making a big push to fix things and clean up our code > > base for an alpha release soon - Clouseau is a tool that is very > > useful in debugging and helping to find and fix problems. I > > suggest we get this resolved ASAP. > > > > Stephen > > -- > > 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
