Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
nice ! so you did not chose to have the install commands themselves to use sudo ;))) On Saturday 02 December 2017 00:10, marcel-hollerb...@t-online.de wrote : > Hello, > > so it turned out that this is a ninja bug. > > Ninja has some sort of recompactination if the number of entries in the > .ninja_log and .ninja_deps files are getting too big, then it will cut > off a few, write that into a temp file, and rename that temp file later > to .ninja_log or .ninja_deps, if you ran exactly this time ninja as root > it will place .ninja_log and .ninja_deps as root owned files in the > directory instead of maintaining the old gid / uid of the file. > > tldr: > There is a bugfix: > https://github.com/ninja-build/ninja/pull/1362 > > Greetings, >Marcel Hollerbach > > On Thu, Nov 23, 2017 at 08:57:20AM +0900, Carsten Haitzler wrote: > > On Wed, 22 Nov 2017 20:13:48 + Mike Blumenkrantz > > said: > > > > > I'm on fedora with meson 0.42.1 and ninja 1.8.2 > > > > Can you try doing the "build as user, install as root/sudo" and hit the > > issue > > and details exactly what files are owned by root at that point and what file > > the problem is with and why the permission problem is there? I just can't > > see > > the source of the issue in my build trees. > > > > > On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams > > > wrote: > > > > > > > Hi, > > > > > > > > I'm on Arch and generally try to stay up to date so maybe they have > > > > fixed > > > > it? > > > > Mike? > > > > > > > > On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher wrote: > > > > > > > > > I can't reproduce that root owner ship issue right now. > > > > > I made the changes to my scripts on the 2017/08/17 > > > > > at that time on my archlinux boxes ninja was 1.7.2 and meson was > > > > > 0.41.2 > > > > > since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 then > > > > > 0.43.0 > > > > > maybe it has been fixed in one of them fixed now. > > > > > (but I won't dive into their respective repos to check that ;) > > > > > > > > > > > > > > > On Wednesday 22 November 2017 20:51, Carsten Haitzler wrote : > > > > > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams < > > > > a...@andywilliams.me> > > > > > said: > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I'm glad that it is not affecting you. Jeyzu and I both seem to > > > > > > > have > > > > > hit > > > > > > > this issue (and I guess zmike too as described earlier). > > > > > > > Some times after a "sudo ninja install" I can no longer "ninja" > > > > > > > due > > > > to > > > > > > > permissions issues with files that have become root owned. > > > > > > > > > > > > > > It is unfortunate but it would be good to get a solution that > > > > > > > works > > > > > all the > > > > > > > time for everyone if possible. > > > > > > > > > > > > I checked what files were root owned. I currently don't see a reason > > > > why > > > > > it > > > > > > should fail. Someone show me a reason where it does fail (a file > > > > written > > > > > to as > > > > > > root has to be overwritten as a user or it cannot be deleted as a > > > > user). > > > > > I > > > > > > don't see it. perhaps its a bug in meson in an older version? or a > > > > newer > > > > > one? > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher > > > > > > > > > > > > > > > > > said: > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I confirm, I had to add the above in my build script : > > > > > > > > > > > > > > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps > > > > > > > > > $BUILD_DIR/.ninja_log > > > > > > > > > > > > > > > > 7:14PM ~/C/e/build ⎇ master > ls -al > > > > > > > > total 4.4M > > > > > > > > 4.0K drwxr-xr-x 9 raster raster 4.0K Nov 22 15:36 ./ > > > > > > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../ > > > > > > > > 1.6M -rw-r--r-- 1 raster raster 1.6M Nov 22 15:36 .ninja_deps > > > > > > > > 64K -rw-r--r-- 1 raster raster 61K Nov 22 15:36 .ninja_log > > > > > > > > > > > > > > > > written not as root. (make ninja install was as root). ... ? > > > > > > > > > > > > > > > > > On Wednesday 22 November 2017 08:18, Andrew Williams wrote : > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Compiling as root may be a bad thing but mike is right, > > > > > > > > > > ninja > > > > > install > > > > > > > > hits > > > > > > > > > > log files and other - some times causing root ownership. I > > > > > > > > > > have > > > > > seen it > > > > > > > > > > occasionally myself and have had to either delete the build > > > > tree > > > > > or > > > > > > > > chown > > > > > > > > > > it to myself. > > > > > > > > > > > > > > > > > > > > Perhaps this is a bug we should be reporting but in the > > > > meantime > > > > > our > > > > > > > > docs > > > > > > > > > > should cover it som
Re: [E-devel] [EGIT] [core/enlightenment] master 01/01: music-control - install properly with meson build with icon
On Sat, Dec 02, 2017 at 11:30:08AM +0100, Jérémy Zurcher wrote: > nice ! > > so you did not chose to have the install commands themselves to use sudo ;))) No, sounded a bit too crazy to me :) > > On Saturday 02 December 2017 00:10, marcel-hollerb...@t-online.de wrote : > > Hello, > > > > so it turned out that this is a ninja bug. > > > > Ninja has some sort of recompactination if the number of entries in the > > .ninja_log and .ninja_deps files are getting too big, then it will cut > > off a few, write that into a temp file, and rename that temp file later > > to .ninja_log or .ninja_deps, if you ran exactly this time ninja as root > > it will place .ninja_log and .ninja_deps as root owned files in the > > directory instead of maintaining the old gid / uid of the file. > > > > tldr: > > There is a bugfix: > > https://github.com/ninja-build/ninja/pull/1362 > > > > Greetings, > >Marcel Hollerbach > > > > On Thu, Nov 23, 2017 at 08:57:20AM +0900, Carsten Haitzler wrote: > > > On Wed, 22 Nov 2017 20:13:48 + Mike Blumenkrantz > > > said: > > > > > > > I'm on fedora with meson 0.42.1 and ninja 1.8.2 > > > > > > Can you try doing the "build as user, install as root/sudo" and hit the > > > issue > > > and details exactly what files are owned by root at that point and what > > > file > > > the problem is with and why the permission problem is there? I just can't > > > see > > > the source of the issue in my build trees. > > > > > > > On Wed, Nov 22, 2017 at 1:08 PM Andrew Williams > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > I'm on Arch and generally try to stay up to date so maybe they have > > > > > fixed > > > > > it? > > > > > Mike? > > > > > > > > > > On Wed, 22 Nov 2017 at 15:55 Jérémy Zurcher wrote: > > > > > > > > > > > I can't reproduce that root owner ship issue right now. > > > > > > I made the changes to my scripts on the 2017/08/17 > > > > > > at that time on my archlinux boxes ninja was 1.7.2 and meson was > > > > > > 0.41.2 > > > > > > since then ninja has been upgraded to 1.8.2, and meson to 0.42.1 > > > > > > then > > > > > > 0.43.0 > > > > > > maybe it has been fixed in one of them fixed now. > > > > > > (but I won't dive into their respective repos to check that ;) > > > > > > > > > > > > > > > > > > On Wednesday 22 November 2017 20:51, Carsten Haitzler wrote : > > > > > > > On Wed, 22 Nov 2017 10:36:36 + Andrew Williams < > > > > > a...@andywilliams.me> > > > > > > said: > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > I'm glad that it is not affecting you. Jeyzu and I both seem to > > > > > > > > have > > > > > > hit > > > > > > > > this issue (and I guess zmike too as described earlier). > > > > > > > > Some times after a "sudo ninja install" I can no longer "ninja" > > > > > > > > due > > > > > to > > > > > > > > permissions issues with files that have become root owned. > > > > > > > > > > > > > > > > It is unfortunate but it would be good to get a solution that > > > > > > > > works > > > > > > all the > > > > > > > > time for everyone if possible. > > > > > > > > > > > > > > I checked what files were root owned. I currently don't see a > > > > > > > reason > > > > > why > > > > > > it > > > > > > > should fail. Someone show me a reason where it does fail (a file > > > > > written > > > > > > to as > > > > > > > root has to be overwritten as a user or it cannot be deleted as a > > > > > user). > > > > > > I > > > > > > > don't see it. perhaps its a bug in meson in an older version? or a > > > > > newer > > > > > > one? > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > > On Wed, 22 Nov 2017 at 10:17 Carsten Haitzler > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Wed, 22 Nov 2017 10:33:05 +0100 Jérémy Zurcher > > > > > > > > > > > > > > > > > > > > said: > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > I confirm, I had to add the above in my build script : > > > > > > > > > > > > > > > > > > > > sudo -S chown $USER $BUILD_DIR/.ninja_deps > > > > > > > > > > $BUILD_DIR/.ninja_log > > > > > > > > > > > > > > > > > > 7:14PM ~/C/e/build ⎇ master > ls -al > > > > > > > > > total 4.4M > > > > > > > > > 4.0K drwxr-xr-x 9 raster raster 4.0K Nov 22 15:36 ./ > > > > > > > > > 4.0K drwxr-xr-x 10 raster raster 4.0K Nov 22 15:36 ../ > > > > > > > > > 1.6M -rw-r--r-- 1 raster raster 1.6M Nov 22 15:36 .ninja_deps > > > > > > > > > 64K -rw-r--r-- 1 raster raster 61K Nov 22 15:36 .ninja_log > > > > > > > > > > > > > > > > > > written not as root. (make ninja install was as root). ... ? > > > > > > > > > > > > > > > > > > > On Wednesday 22 November 2017 08:18, Andrew Williams wrote > > > > > > > > > > : > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > Compiling as root may be a bad thing but mike is right, > > > > > > > > > > > ninja > > > > > > install > > > > > > > > > hits > > > > > > > > > > > log files and other - some times causi
Re: [E-devel] [EGIT] [core/efl] master 03/05: efl: Introduce interface Efl.Dup
Is there anyway we could use a more descriptive name? It just seems unnecessarily short. Maybe that’s just me. Andy On Fri, 1 Dec 2017 at 18:50, Davide Andreoli wrote: > 2017-12-01 3:12 GMT+01:00 Jean-Philippe André : > > > On Fri, Dec 1, 2017 at 3:49 AM, Davide Andreoli > > wrote: > > > > > 2017-11-30 3:36 GMT+01:00 Jean-Philippe ANDRÉ : > > > > > > > jpeg pushed a commit to branch master. > > > > > > > > http://git.enlightenment.org/core/efl.git/commit/?id= > > > > bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c > > > > > > > > commit bd5b76508b0b3bdc5d92f5f7db9741c100d47d3c > > > > Author: Jean-Philippe Andre > > > > Date: Wed Nov 29 20:03:16 2017 +0900 > > > > > > > > efl: Introduce interface Efl.Dup > > > > > > > > A few classes allow their objects to be duplicated, so they > should > > > all > > > > use the same interface. > > > > > > > > Also, rename VG's dup to copy_from as it's not conforming to the > > > > definition of dup. > > > > > > > > > > Is'nt the last rename (vg_dup) an abi break ? > > > > > > python-efl apps now crash like this: > > > Traceback (most recent call last): > > > File "/usr/bin/epymc", line 5, in > > > from epymc.main import start_epymc > > > File "/usr/lib/python3.6/site-packages/epymc/main.py", line 32, in > > > > > > from efl import edje > > > ImportError: /usr/local/lib/libedje.so.1: undefined symbol: > > > evas_vg_node_dup > > > > > > A python-efl rebuild fixed the issue, this is why I think it's an abi > > > break. > > > > > > note that the bindings do not use/expose evas_vg in any way > > > > > > > I was under the impression that Evas VG was still "beta". > > In fact I can see EFL_BETA_API_SUPPORT. > > > > Could you double-check on your side what's happening? > > Where is this symbol used? > > > > Probably the symbol is used inside edje. PythonEFL is built with > EFL_BETA_API_SUPPORT on, and I think this is the source of > the issue > > > > > > TIA, > > > > > > > > > > > > > > > > > --- > > > > src/Makefile_Efl.am | 1 + > > > > src/bin/elementary/test_events.c | 10 +- > > > > src/lib/edje/edje_calc.c | 2 +- > > > > src/lib/efl/Efl.h | 1 + > > > > src/lib/efl/interfaces/efl_dup.eo | 17 + > > > > src/lib/efl/interfaces/efl_gfx_path.c | 4 ++-- > > > > src/lib/efl/interfaces/efl_gfx_path.eo| 3 ++- > > > > src/lib/efl/interfaces/efl_gfx_shape.c| 12 +++- > > > > src/lib/efl/interfaces/efl_gfx_shape.eo | 12 +++- > > > > src/lib/efl/interfaces/efl_interfaces_main.c | 1 + > > > > src/lib/evas/canvas/efl_canvas_vg.c | 2 +- > > > > src/lib/evas/canvas/efl_input_event.eo| 13 + > > > > src/lib/evas/canvas/efl_input_focus.c | 2 +- > > > > src/lib/evas/canvas/efl_input_focus.eo| 10 +- > > > > src/lib/evas/canvas/efl_input_hold.c | 2 +- > > > > src/lib/evas/canvas/efl_input_hold.eo | 10 +- > > > > src/lib/evas/canvas/efl_input_key.c | 2 +- > > > > src/lib/evas/canvas/efl_input_key.eo | 10 +- > > > > src/lib/evas/canvas/efl_input_pointer.c | 2 +- > > > > src/lib/evas/canvas/efl_input_pointer.eo | 10 +- > > > > src/lib/evas/canvas/efl_vg.eo | 7 ++- > > > > src/lib/evas/canvas/efl_vg_container.eo | 2 +- > > > > src/lib/evas/canvas/efl_vg_gradient.eo| 2 +- > > > > src/lib/evas/canvas/efl_vg_gradient_linear.eo | 2 +- > > > > src/lib/evas/canvas/efl_vg_gradient_radial.eo | 2 +- > > > > src/lib/evas/canvas/efl_vg_shape.eo | 2 +- > > > > src/lib/evas/canvas/evas_device.c | 2 +- > > > > src/lib/evas/canvas/evas_events.c | 22 > > > +++--- > > > > src/lib/evas/canvas/evas_vg_container.c | 6 +++--- > > > > src/lib/evas/canvas/evas_vg_gradient.c| 4 ++-- > > > > src/lib/evas/canvas/evas_vg_gradient_linear.c | 4 ++-- > > > > src/lib/evas/canvas/evas_vg_gradient_radial.c | 4 ++-- > > > > src/lib/evas/canvas/evas_vg_node.c| 4 ++-- > > > > src/lib/evas/canvas/evas_vg_shape.c | 16 > > > > src/lib/evas/vg/evas_vg_cache.c | 2 +- > > > > 35 files changed, 121 insertions(+), 86 deletions(-) > > > > > > > > diff --git a/src/Makefile_Efl.am b/src/Makefile_Efl.am > > > > index 769abd6298..0584602894 100644 > > > > --- a/src/Makefile_Efl.am > > > > +++ b/src/Makefile_Efl.am > > > > @@ -16,6 +16,7 @@ efl_eolian_files = \ > > > >lib/efl/interfaces/efl_canvas.eo \ > > > >lib/efl/interfaces/efl_config.eo \ > > > >lib/efl/interfaces/efl_control.eo \ > > > > + lib/efl/interfaces/efl_dup.eo \ > > > >lib/efl/interfaces/efl_file.eo \ > > > >lib/efl/interfaces/efl_image_load.eo \ > > > >lib/efl/interfaces/efl_part.eo \ > > > > diff --git
Re: [E-devel] Numerous issues with EFL and E
On Fri, 24 Nov 2017 14:40:04 -0500 "William L. Thomson Jr." wrote: > > 1. Since E 0.22.0 every time I log in I get efreet cache issues. > https://www.enlightenment.org/ss/e-5a1868030754a5.95532007.jpg > ERR<4776>:efreet_cache lib/efreet/efreet_cache.c:169 _cb_server_del() > efreetd connection failed 10 times! check for stale socket files > in /home/wlt/.run//.ecore/efreetd This seems to be related to EFL vs E. Getting this under 0.21.10 on my desktop after reverting back. -- 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
Re: [E-devel] Numerous issues with EFL and E
You all likely do not care, but for those that do I have given up on E 0.22.x on my dual display desktop, reverting back to stable 0.21.10 I haven't any major issues with. 0.22.1 is ok on my laptop but having to constantly restart E from main menu to get Firefox and other stuff to start rendering on screen again. At least no hard lock ups like I had daily on my dual display desktop. I know for 0.23.0 autotools will be dropped for meson due to difficulty in maintaining both. If 2 build systems cannot be maintained, then how is both X and Wayland supposed to be maintained without major work and causing issues for either. Seems like that is already the case now. I must say for some 9yrs of Wayland concept in development, this is not impressive. Not sure if anyone has done the same under E. https://www.phoronix.com/scan.php?page=article&item=gnome-326-x11way Basically Wayland on Gnome is barely equal to X in performance. In a few cases X is better and in almost non Wayland is better. I am really not sure where all this is going, but its a massive amount of work over many years just to get close to equal. I am not impressed. If that same amount of effort over 9 yrs went into X. All maybe further along all around, GTK, QT, EFL, etc. Right now still seems years before Wayland will match X feature for feature and identical performance much less exceeding X in performance. Though I assume EFL/E does already, Test suites could show that for a fact in numbers one way or another. The focus on E supporting Wayland has really destroyed it for X. There are tons of X issues with things like copy paste, etc. Beyond major bugs. I know people do not care to address as they are looking to get rid of X for Wayland. Which makes X users second class citzens. Worse than someone wanting to keep E under autotools vs meson. Either way I am not impressed at all with those Gnome numbers for Wayland vs X. Surely not impressed with all the issues encountered running E under X. Which running under Wayland is not an option for me yet, unless dual display support is there now, copy paste, and other things I need to make a living. Technology is something that last without redesign. We are in some generation that feels we need to redesign the wheel. I consider the following to be true tech, as over many years it has not changed. AC, steering wheel, Unix (os x uses close to 40yr old kernel base), C Those things have remained mostly the same for a very long time, generations. That is technology. I am not sure if Wayland will last as long as say X already has. HAL anyone? https://en.wikipedia.org/wiki/HAL_%28software%29 Or lets toss init for systemd etc... How long was init around? Not even sure when init first came about. Before most of us were born more than likely... On Fri, 24 Nov 2017 14:40:04 -0500 "William L. Thomson Jr." wrote: > I am not filing a bug report on list. I am unable to file bugs. I am > encountering numerous issues. > > 2. I updated Clipboard module to elm_cnp. I was looking to update it > to newer modules/gadget API. Though I am unable to. > https://github.com/Obsidian-StudiosInc/clipboard > > 3. Major issues with Bryce. When I add no wizard to add gadgets must > log out and back. Soon as I go to add gadgets freezes and crashes > E. It was more usable in the past though I have stuck with shelf. > Bryce issues prevented my progress on Clipboard module updating API. > Also stopped me from making a Network Manager module. At least not > using new API I rather not use old like others. > https://github.com/eyoz/oconnection > > 4. My dual display desktop runs away daily. Sometimes I can restart E > in time as it becomes super slow and sluggish. If I fail to in time I > must restart as it ends up stuck at 100% on a single core. On my > laptop windows stop rendering. I filed a bug on that. Those two > issues likely will force me back to 0.21.x > https://phab.enlightenment.org/T6144 -- 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
[E-devel] Blend2D - a gfx framework with dynamic pipelines support
Hi all, I'd like to ask what is your opinion on this library[1]. It's a library where you call all the draw operations that comprise the drawing pipeline, and, when you call `context_end`, the pipeline is compiled (yep, JIT). Somehow exciting because it allows very interesting optimizations. But it's also boring, because you have to recompile the whole pipeline every time some value changes (i.e. probably every frame if you're writing a game). But there is also plans to support a shader language (with a working experimental code for a useless math functions language). With this support added, you could compile the rendering pipeline only once and evaluate it for every frame. The thing I like is support for Bézier curves. It's like OpenGL done for 2D rendering. The API seems a lot like cairo, so it's mostly transparent (except for the shaders). Maybe EFL could add a backend forked from SDL2 using this library to generate the screen bits. Or maybe there is not enough info flowing the higher layers to the lower layers to make this idea actually useful. Maybe some of these ideas could be stolen by the EFL project. I'd like to hear opinion from you guys about this project. You guys are experienced with 2d gfx code and I'd love to hear anything you guys have to say about this project. [1] https://blend2d.com/ -- 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
