Re: [E-devel] [EGIT] [core/efl] master 01/01: efreet: don't try change permissions on runtime dir we don't own.
On Tue, 25 Jun 2013 04:03:28 +0200 Sebastian Dransfeld s...@tango.flipp.net
said:
On 06/24/2013 05:00 AM, Carsten Haitzler (Rasterman) - Enlightenment Git
wrote:
raster pushed a commit to branch master.
commit 8e3d94d66130f16cec0d518a0ad6ec5fae04fec9
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Mon Jun 24 12:00:30 2013 +0900
efreet: don't try change permissions on runtime dir we don't own.
If we should have mode 0700 on runtime dir, shouldn't it be a warning if
we don't own it? Seems like it should be private.
in the common case ... XDG_RUNTIME_DIR ends up being /tmp and so it
ALWAYS bitches... :)
S.
---
src/lib/efreet/efreet_base.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/lib/efreet/efreet_base.c b/src/lib/efreet/efreet_base.c
index 26346e0..93e264c 100644
--- a/src/lib/efreet/efreet_base.c
+++ b/src/lib/efreet/efreet_base.c
@@ -335,13 +335,16 @@ efreet_dirs_init(void)
}
else if ((st.st_mode 0777) != 0700)
{
-ERR(XDG_RUNTIME_DIR=%s is mode %o, changing to 0700,
-xdg_runtime_dir, st.st_mode 0777);
-if (chmod(xdg_runtime_dir, 0700) != 0)
+if (st.st_uid == geteuid())
{
-CRITICAL(Cannot fix XDG_RUNTIME_DIR=%s incorrect mode %o: %s,
- xdg_runtime_dir, st.st_mode 0777, strerror(errno));
-eina_stringshare_replace(xdg_runtime_dir, NULL);
+ERR(XDG_RUNTIME_DIR=%s is mode %o, changing to 0700,
+xdg_runtime_dir, st.st_mode 0777);
+if (chmod(xdg_runtime_dir, 0700) != 0)
+{
+CRITICAL(Cannot fix XDG_RUNTIME_DIR=%s incorrect mode %o:
%s,
+ xdg_runtime_dir, st.st_mode 0777, strerror
(errno));
+eina_stringshare_replace(xdg_runtime_dir, NULL);
+}
}
}
/* hostname */
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
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 --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
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: efreet: don't try change permissions on runtime dir we don't own.
On Tue, 25 Jun 2013 12:18:17 +0900 Jean-Philippe André j...@videolan.org said:
Hi there,
It seems to me changing the permissions will cause problems to users who
happen to run E as root and /tmp is their runtime dir (because
XDG_RUNTIME_DIR points to it or is not set).
We can argue a lot about running stuff as root of course, or even having
/tmp as runtime dir, but I encountered that problem by accident.
As ptrace is blocked on Ubuntu, you have to run gdb and other stuff as root
sometimes, and bad things happen when /tmp suddenly decomes 0700...
Shouldn't /tmp be specifically excluded from the chmod rule?
hmm i guess thats a hole - if u run as root it'll fuck with /tmp perms.. and
that will be most bad...
Cheers,
JP
On Tue, Jun 25, 2013 at 11:03 AM, Sebastian Dransfeld
s...@tango.flipp.netwrote:
On 06/24/2013 05:00 AM, Carsten Haitzler (Rasterman) - Enlightenment Git
wrote:
raster pushed a commit to branch master.
commit 8e3d94d66130f16cec0d518a0ad6ec5fae04fec9
Author: Carsten Haitzler (Rasterman) ras...@rasterman.com
Date: Mon Jun 24 12:00:30 2013 +0900
efreet: don't try change permissions on runtime dir we don't own.
If we should have mode 0700 on runtime dir, shouldn't it be a warning if
we don't own it? Seems like it should be private.
S.
---
src/lib/efreet/efreet_base.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/src/lib/efreet/efreet_base.c b/src/lib/efreet/efreet_base.c
index 26346e0..93e264c 100644
--- a/src/lib/efreet/efreet_base.c
+++ b/src/lib/efreet/efreet_base.c
@@ -335,13 +335,16 @@ efreet_dirs_init(void)
}
else if ((st.st_mode 0777) != 0700)
{
-ERR(XDG_RUNTIME_DIR=%s is mode %o, changing to 0700,
-xdg_runtime_dir, st.st_mode 0777);
-if (chmod(xdg_runtime_dir, 0700) != 0)
+if (st.st_uid == geteuid())
{
-CRITICAL(Cannot fix XDG_RUNTIME_DIR=%s incorrect mode %o:
%s,
- xdg_runtime_dir, st.st_mode 0777,
strerror(errno));
-eina_stringshare_replace(xdg_runtime_dir, NULL);
+ERR(XDG_RUNTIME_DIR=%s is mode %o, changing to 0700,
+xdg_runtime_dir, st.st_mode 0777);
+if (chmod(xdg_runtime_dir, 0700) != 0)
+{
+CRITICAL(Cannot fix XDG_RUNTIME_DIR=%s incorrect mode
%o: %s,
+ xdg_runtime_dir, st.st_mode 0777,
strerror(errno));
+eina_stringshare_replace(xdg_runtime_dir, NULL);
+}
}
}
/* hostname */
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
--
Jean-Philippe André
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
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 --
The Rasterman (Carsten Haitzler)ras...@rasterman.com
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] A nice article I think E devs should read
On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel onef...@gmail.com said: On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL cedric.b...@free.fr wrote: Right now only a thought exercice, but you can get info there : https://phab.enlightenment.org/w/bob/ . Definitely something my LuaJIT experiments will be good for. A daemon could be in charge of generating the JIT and thus sharing information across processes (Does LuaJIT allow for this?). this is way too premature in terms of optimizing imho. sure - having N apps all go run their own jit on the same bit of lua is inefficient. having it jitted once and shared is much better. but how do we share jitted code sensibly so it can be executed in N places safely? we would need to share jitted code inside mmaped shared memory segs mmaped to the same absolute addresses, unless we modified the jit engine to use base address relative code generation... ugh!. or we run it all in the server and ipc results/input to and fro? ... hmm ewww... If that means that some EFL based C code is generating and compiling Lua code, in response to commands from a socket, then yes. If that also includes running the results in a threaded way with message passing, then also yes (same daemon). I have these working already. Designed to deal with thousands of Lua scripts running at once, and using LuaJIT. I've mentioned this before. right now thoughts are along the lines of every object type (widget? or part in edje) is really a bunch of lua to implement it - or to calculate it and hand off to a go implement this state for me code... what i'd like to see is for it to be easily parallelisable into threads. so we can calculate lots of params/parts in parallel when possible (independent calc paths - eg of 2 child branches before parent has to look at results of children) etc. thus why calc vs implement should be stages.. maybe lua tables with functions (methods) to implement calc , implement, etc. etc. - don't know. thought exercise atm. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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: ecore_imf: Add support for wayland
Hello.
On 06/24/2013 08:16 PM, Jan Arne Petersen - Enlightenment Git wrote:
etrunko pushed a commit to branch master.
commit f656aa397f02d70dd51a4e450a021fb582b53732
Author: Jan Arne Petersen jpeter...@openismus.com
Date: Wed Apr 17 11:59:46 2013 +0200
ecore_imf: Add support for wayland
Add an input method module supporting the Wayland input method protocol.
In v2:
- Missing call to ecore_wl_shutdown() in im_module_shutdown()
- Access the already stored 'wayland globals' with
ecore_wl_globals_get()
- Fixed compilation by adding -I(top_srcdir)/src/efl to CFLAGS
- EFL formatting fixes
Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com
E crashes for me after this commit with wayland clients enabled.
display is 0x0 in wl_display_dispatch
e-crashdump.txt attached.
regards
Stefan Schmidt
Thread 1 (Thread 0x7f9deb1c0840 (LWP 16311)):
#0 0x7f9de9cc45d0 in __pause_nocancel ()
at ../sysdeps/unix/syscall-template.S:82
No locals.
#1 signal handler called
No symbol table info available.
#2 wl_display_dispatch (display=0x0) at wayland-client.c:979
No locals.
#3 0x7f9ddb97b5f3 in im_module_init ()
at modules/ecore_imf/wayland/wayland_module.c:124
registry = optimised out
globals = optimised out
global = optimised out
__FUNCTION__ = im_module_init
#4 0x7f9de9ef6e8f in eina_module_load (m=0x11e5f20)
at lib/eina/eina_module.c:329
dl_handle = 0x11e5320
initcall = optimised out
__FUNCTION__ = eina_module_load
#5 0x7f9de9ef7923 in eina_module_list_load (array=0x11ea6d0)
at lib/eina/eina_module.c:557
iterator = optimised out
m = optimised out
i = optimised out
__FUNCTION__ = eina_module_list_load
#6 0x7f9de857cdb4 in ecore_imf_module_init ()
at lib/ecore_imf/ecore_imf_module.c:93
buf = /usr/local/lib/ecore_imf/modules, '\000' repeats 4063 times
path = optimised out
#7 0x7f9de857ac12 in ecore_imf_init () at lib/ecore_imf/ecore_imf.c:35
__FUNCTION__ = ecore_imf_init
#8 0x004e in main (argc=1, argv=0x7fffd913ec18) at e_main.c:392
safe_mode = 0 '\000'
after_restart = 1 '\001'
waslocked = 0 '\000'
t = 1372147084.4547911
tstart = 1372147084.4547911
s = optimised out
buff = 1372147084.5, '\000' repeats 12 times\353,
\350B\000\000\000\000
action = {__sigaction_handler = {
sa_handler = 0x504090 e_sigabrt_act,
sa_sigaction = 0x504090 e_sigabrt_act}, sa_mask = {__val = {
0 repeats 16 times}}, sa_flags = -1073741820,
sa_restorer = 0x20d000}
__FUNCTION__ = main
Detaching from program: /usr/local/bin/enlightenment, process 16311
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
fixed On Tue, Jun 25, 2013 at 12:55 AM, Carsten Haitzler ras...@rasterman.comwrote: On Tue, 11 Jun 2013 10:55:23 +0100 Michael Blumenkrantz michael.blumenkra...@gmail.com said: The old thread was too long for me to see if I fixed everything, so post here if you have a bug that's present using the latest revision. alt+left mouse drag window around to move it. keep dragging. while alt+left mouse is pressed.. also press: ctrl+alt+x to close window... pretty soon after that.. segv. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] A nice article I think E devs should read
On 25/06/13 00:18, Carsten Haitzler (The Rasterman) wrote: On Mon, 24 Jun 2013 11:05:00 +0100 Tom Hacohen tom.haco...@samsung.com said: On 22/06/13 02:42, Carsten Haitzler (The Rasterman) wrote: On Fri, 21 Jun 2013 11:04:32 +0100 Tom Hacohen tom.haco...@samsung.com said: Hey, I often argue against adding new features (and bugs), libs, widgets, etcetera. I often explain my stance in a per case way. However I stumbled across this nice article which explains where I am coming from. You should probably read it, and hopefully be more conscious about it: http://firstround.com/article/The-one-cost-engineers-and-product-managers-dont-consider there's a project you'd love and adore. it's called gnome 3. remove all possibly removable features and options. :) yes. features. code.. they cost more than just development. it's called maintenance. s a project gets bigger (more code. more features) it requires more manpower for maintenance. that's life. You either mistakenly or intentionally got it wrong. I guess me writing E (while actually meaning EFL + E) was also confusing. Obviously if customizability is a main feature of your product, those features are essential and should not be dropped. I was more talking about adding elm widgets just for the sake of it, or thinking about adding things. Also, I don't completely agree with everything he said, but it's still a good read and I think everyone should take some things from it. well his article makes a VERY strong point of never add features.. ever (unless you absolutely must and have no choice and can justify it) in fact it makes a point of removing features. it's a very gnome-like stance. yes - elm has too many. we need to refactor much of it to at least internally be the same widget/core just with differing styles. toggle got refactored into check at some point. we could refactor radio and check to merge. gengrid and genlist should become one. etc. u may notice no new widgets have appeared in elm for a while. this is also why we've talked about bob... punt off every little customization off into snippets of lua... :) edje itself has also become a massive blob of features too... and this is an attempt at finding a better way to manage our feature-pile. Exactly. I didn't mean this text should be followed religiously. I'm just saying, it's an approach people in the e world don't usually take, so it might serve as an eye-opener for them. Well, he makes a very strong point about never adding features, but I didn't mean it about e. I mostly thought about the EFL and API (the things that interest me) when saying what I said (more specifically elementary. ;P). -- Tom. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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: ecore_imf: Add support for wayland
Hello. On 06/25/2013 09:19 AM, Stefan Schmidt wrote: Hello. On 06/24/2013 08:16 PM, Jan Arne Petersen - Enlightenment Git wrote: etrunko pushed a commit to branch master. commit f656aa397f02d70dd51a4e450a021fb582b53732 Author: Jan Arne Petersen jpeter...@openismus.com Date: Wed Apr 17 11:59:46 2013 +0200 ecore_imf: Add support for wayland Add an input method module supporting the Wayland input method protocol. In v2: - Missing call to ecore_wl_shutdown() in im_module_shutdown() - Access the already stored 'wayland globals' with ecore_wl_globals_get() - Fixed compilation by adding -I(top_srcdir)/src/efl to CFLAGS - EFL formatting fixes Signed-off-by: Eduardo Lima (Etrunko) eduardo.l...@intel.com E crashes for me after this commit with wayland clients enabled. display is 0x0 in wl_display_dispatch e-crashdump.txt attached. Devilhors fixed it in git now regards Stefan Schmidt -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Bob. Was: A nice article I think E devs should read
On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel onef...@gmail.com said: On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL cedric.b...@free.fr wrote: Right now only a thought exercice, but you can get info there : https://phab.enlightenment.org/w/bob/ . Definitely something my LuaJIT experiments will be good for. A daemon could be in charge of generating the JIT and thus sharing information across processes (Does LuaJIT allow for this?). this is way too premature in terms of optimizing imho. sure - having N apps all go run their own jit on the same bit of lua is inefficient. having it jitted once and shared is much better. but how do we share jitted code sensibly so it can be executed in N places safely? we would need to share jitted code inside mmaped shared memory segs mmaped to the same absolute addresses, unless we modified the jit engine to use base address relative code generation... ugh!. or we run it all in the server and ipc results/input to and fro? ... hmm ewww... If that means that some EFL based C code is generating and compiling Lua code, in response to commands from a socket, then yes. If that also includes running the results in a threaded way with message passing, then also yes (same daemon). I have these working already. Designed to deal with thousands of Lua scripts running at once, and using LuaJIT. I've mentioned this before. right now thoughts are along the lines of every object type (widget? or part in edje) is really a bunch of lua to implement it - or to calculate it and hand off to a go implement this state for me code... what i'd like to see is for it to be easily parallelisable into threads. so we can calculate lots of params/parts in parallel when possible (independent calc paths - eg of 2 child branches before parent has to look at results of children) etc. thus why calc vs implement should be stages.. maybe lua tables with functions (methods) to implement calc , implement, etc. etc. - don't know. thought exercise atm. My point is that this sort of thing is not just a thought exercise for me, I've done a lot of the work already for another project. I was always keeping Edje Lua in mind when I did it though, thinking some of the work could apply there. Naturally I used EFL for this project. B-) It's a virtual world scripting engine. Second Life / OpenSim virtual worlds are made of 256 x 256 meter sims, with hundreds or thousands of these sims in any given world. Each sim might have several thousand LSL scripts running, and in a lot of cases most of those scripts are just multiple copies of the same dozen scripts. So I've been writing a daemon that generates Lua scripts (translated from pre existing LSL scripts), then compiles and runs them with LuaJIT, using a threaded worker queue with message passing system. Getting it to run fast and use minimal resources is important for this project. I don't want thousands of these same dozen scripts soaking up memory, I want one of each. This daemon will also run in the virtual world viewer, driving Edje UIs via Edje Lua. I got a lot of the bob bits already sorted out, before I knew there was a bob. B-) -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world. signature.asc Description: PGP signature -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Bob. Was: A nice article I think E devs should read
On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel onef...@gmail.com said: On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman) ras...@rasterman.com wrote: On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel onef...@gmail.com said: On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL cedric.b...@free.fr wrote: Right now only a thought exercice, but you can get info there : https://phab.enlightenment.org/w/bob/ . Definitely something my LuaJIT experiments will be good for. A daemon could be in charge of generating the JIT and thus sharing information across processes (Does LuaJIT allow for this?). this is way too premature in terms of optimizing imho. sure - having N apps all go run their own jit on the same bit of lua is inefficient. having it jitted once and shared is much better. but how do we share jitted code sensibly so it can be executed in N places safely? we would need to share jitted code inside mmaped shared memory segs mmaped to the same absolute addresses, unless we modified the jit engine to use base address relative code generation... ugh!. or we run it all in the server and ipc results/input to and fro? ... hmm ewww... If that means that some EFL based C code is generating and compiling Lua code, in response to commands from a socket, then yes. If that also includes running the results in a threaded way with message passing, then also yes (same daemon). I have these working already. Designed to deal with thousands of Lua scripts running at once, and using LuaJIT. I've mentioned this before. right now thoughts are along the lines of every object type (widget? or part in edje) is really a bunch of lua to implement it - or to calculate it and hand off to a go implement this state for me code... what i'd like to see is for it to be easily parallelisable into threads. so we can calculate lots of params/parts in parallel when possible (independent calc paths - eg of 2 child branches before parent has to look at results of children) etc. thus why calc vs implement should be stages.. maybe lua tables with functions (methods) to implement calc , implement, etc. etc. - don't know. thought exercise atm. My point is that this sort of thing is not just a thought exercise for me, I've done a lot of the work already for another project. I was always keeping Edje Lua in mind when I did it though, thinking some of the work could apply there. Naturally I used EFL for this project. B-) It's a virtual world scripting engine. Second Life / OpenSim virtual worlds are made of 256 x 256 meter sims, with hundreds or thousands of these sims in any given world. Each sim might have several thousand LSL scripts running, and in a lot of cases most of those scripts are just multiple copies of the same dozen scripts. So I've been writing a daemon that generates Lua scripts (translated from pre existing LSL scripts), then compiles and runs them with LuaJIT, using a threaded worker queue with message passing system. Getting it to run fast and use minimal resources is important for this project. I don't want thousands of these same dozen scripts soaking up memory, I want one of each. the worker system, message passing etc. would be useful for bob. we dont need the lsl - lua bit. :) but we may definitely generate lua src text FROM multiple sections/snippets of lua that make up an object... :) This daemon will also run in the virtual world viewer, driving Edje UIs via Edje Lua. I got a lot of the bob bits already sorted out, before I knew there was a bob. B-) yes. what is missing there i guess is the implement() method that has to collect results and run in the mainloop. for very simple calculations/work running it in a threads and messaging will be much more overhead than just running it there and then.. so that's going to possibly need some heuaristic to guess where it should be run etc. -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Bob. Was: A nice article I think E devs should read
On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel onef...@gmail.com said:
On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel onef...@gmail.com
said:
On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL cedric.b...@free.fr
wrote:
Right now only a thought exercice, but you can get info there :
https://phab.enlightenment.org/w/bob/ .
Definitely something my LuaJIT experiments will be good for.
A daemon could be in charge of generating the JIT and thus sharing
information across processes (Does LuaJIT allow for this?).
this is way too premature in terms of optimizing imho. sure - having
N apps all go run their own jit on the same bit of lua is
inefficient. having it jitted once and shared is much better. but how
do we share jitted code sensibly so it can be executed in N places
safely? we would need to share jitted code inside mmaped shared
memory segs mmaped to the same absolute addresses, unless we modified
the jit engine to use base address relative code generation... ugh!.
or we run it all in the server and ipc results/input to and fro? ...
hmm ewww...
If that means that some EFL based C code is generating and compiling
Lua code, in response to commands from a socket, then yes. If that
also includes running the results in a threaded way with message
passing, then also yes (same daemon). I have these working
already. Designed to deal with thousands of Lua scripts running at
once, and using LuaJIT. I've mentioned this before.
right now thoughts are along the lines of every object type (widget?
or part in edje) is really a bunch of lua to implement it - or to
calculate it and hand off to a go implement this state for me
code...
what i'd like to see is for it to be easily parallelisable into
threads. so we can calculate lots of params/parts in parallel when
possible (independent calc paths - eg of 2 child branches before
parent has to look at results of children) etc. thus why calc vs
implement should be stages.. maybe lua tables with functions
(methods) to implement calc , implement, etc. etc. - don't know.
thought exercise atm.
My point is that this sort of thing is not just a thought exercise
for me, I've done a lot of the work already for another project. I was
always keeping Edje Lua in mind when I did it though, thinking some of
the work could apply there. Naturally I used EFL for this project.
B-)
It's a virtual world scripting engine. Second Life / OpenSim virtual
worlds are made of 256 x 256 meter sims, with hundreds or thousands of
these sims in any given world. Each sim might have several thousand LSL
scripts running, and in a lot of cases most of those scripts are just
multiple copies of the same dozen scripts. So I've been writing a
daemon that generates Lua scripts (translated from pre existing LSL
scripts), then compiles and runs them with LuaJIT, using a threaded
worker queue with message passing system. Getting it to run fast and
use minimal resources is important for this project. I don't want
thousands of these same dozen scripts soaking up memory, I want one of
each.
This daemon will also run in the virtual world viewer, driving Edje
UIs via Edje Lua.
oh.. and we need to figure out how to sensibly override objects. basically i
can smell objects being very oo-like in that they implement methods. unlike
native we can not just totally override a specific method on an object class
(we want to only keep 1 instance of a class for an object and not generate per
actual object created for efficiency) but we can PATCH a method. i assume
we'd use a metatable with functions stuffed into it to represent a class, for
the basics (please expound on this as u see fit and as to what u think is
good/bad!)... but we can ALSO do things like provide slots or hook points
within a function. let me do a very simple one (please don't nitpick my poor
lua :)):
myclass = {}
function myclass:new()
o = { left = 0; right = 0; size = 0}
-- slot:init-vals
self.__index = self
return setmetatable(o, self)
end
function myclass:layout(obj)
-- slot:pre-calc
self.size = self.left + self.right
-- slot:post-calc
end
now let's say i'm a hacky arty ui person. i want to take the basic object type
myclass but simply add a third element to it - otherwise keep the rest the
same. i really want to patch the code by inserting some code of my own in
available slots like:
slot:init-vals = o.extra = 0
slot:post-calc = size.self += self.extra
so after patching the code becomes:
myclass = {}
function myclass:new()
o = { left = 0; right = 0; size = 0}
o.extra = 0;
-- slot:init-vals
self.__index = self
return setmetatable(o, self)
end
function myclass:layout(obj)
-- slot:pre-calc
self.size = self.left + self.right
self.size += self.extra
-- slot:post-calc
end
think
Re: [E-devel] Bob. Was: A nice article I think E devs should read
On Tue, 25 Jun 2013 19:57:45 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel onef...@gmail.com
said:
On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel
onef...@gmail.com said:
On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL
cedric.b...@free.fr wrote:
Right now only a thought exercice, but you can get info
there : https://phab.enlightenment.org/w/bob/ .
Definitely something my LuaJIT experiments will be good for.
A daemon could be in charge of generating the JIT and thus
sharing information across processes (Does LuaJIT allow for
this?).
this is way too premature in terms of optimizing imho. sure -
having N apps all go run their own jit on the same bit of lua is
inefficient. having it jitted once and shared is much better. but
how do we share jitted code sensibly so it can be executed in N
places safely? we would need to share jitted code inside mmaped
shared memory segs mmaped to the same absolute addresses, unless
we modified the jit engine to use base address relative code
generation... ugh!. or we run it all in the server and ipc
results/input to and fro? ... hmm ewww...
If that means that some EFL based C code is generating and
compiling Lua code, in response to commands from a socket, then
yes. If that also includes running the results in a threaded
way with message passing, then also yes (same daemon). I have
these working already. Designed to deal with thousands of Lua
scripts running at once, and using LuaJIT. I've mentioned this
before.
right now thoughts are along the lines of every object type
(widget? or part in edje) is really a bunch of lua to implement
it - or to calculate it and hand off to a go implement this
state for me code...
what i'd like to see is for it to be easily parallelisable into
threads. so we can calculate lots of params/parts in parallel when
possible (independent calc paths - eg of 2 child branches before
parent has to look at results of children) etc. thus why calc vs
implement should be stages.. maybe lua tables with functions
(methods) to implement calc , implement, etc. etc. - don't know.
thought exercise atm.
My point is that this sort of thing is not just a thought exercise
for me, I've done a lot of the work already for another project. I
was always keeping Edje Lua in mind when I did it though, thinking
some of the work could apply there. Naturally I used EFL for this
project. B-)
It's a virtual world scripting engine. Second Life / OpenSim
virtual worlds are made of 256 x 256 meter sims, with hundreds or
thousands of these sims in any given world. Each sim might have
several thousand LSL scripts running, and in a lot of cases most of
those scripts are just multiple copies of the same dozen scripts.
So I've been writing a daemon that generates Lua scripts
(translated from pre existing LSL scripts), then compiles and runs
them with LuaJIT, using a threaded worker queue with message
passing system. Getting it to run fast and use minimal resources
is important for this project. I don't want thousands of these
same dozen scripts soaking up memory, I want one of each.
This daemon will also run in the virtual world viewer, driving Edje
UIs via Edje Lua.
oh.. and we need to figure out how to sensibly override objects.
basically i can smell objects being very oo-like in that they
implement methods. unlike native we can not just totally override a
specific method on an object class (we want to only keep 1 instance
of a class for an object and not generate per actual object created
for efficiency) but we can PATCH a method. i assume we'd use a
metatable with functions stuffed into it to represent a class, for
the basics (please expound on this as u see fit and as to what u
think is good/bad!)... but we can ALSO do things like provide slots
or hook points within a function. let me do a very simple one
(please don't nitpick my poor lua :)):
myclass = {}
function myclass:new()
o = { left = 0; right = 0; size = 0}
-- slot:init-vals
self.__index = self
return setmetatable(o, self)
end
function myclass:layout(obj)
-- slot:pre-calc
self.size = self.left + self.right
-- slot:post-calc
end
now let's say i'm a hacky arty ui person. i want to take the basic
object type myclass but simply add a third element to it -
otherwise keep the rest the same. i really want to patch the code
by inserting some code of my own in available slots like:
slot:init-vals = o.extra = 0
slot:post-calc = size.self += self.extra
so after patching the code becomes:
myclass = {}
function myclass:new()
o = { left = 0; right = 0; size = 0}
o.extra =
Re: [E-devel] [EGIT] [core/efl] master 01/02: Add missing safety checks for valid proxy objects before trying to call functions on the object
This is auto generated by wayland scanner, do you think we should
include the xml files and generate the source files instead of
including them?
On Tue, Jun 25, 2013 at 10:14 AM, Chris Michael - Enlightenment Git
no-re...@enlightenment.org wrote:
devilhorns pushed a commit to branch master.
commit 0615dfe4ee1636b56086545605ea9dd6dadb95c2
Author: Chris Michael cp.mich...@samsung.com
Date: Tue Jun 25 13:51:53 2013 +0100
Add missing safety checks for valid proxy objects before trying to
call functions on the object
Signed-off-by: Chris Michael cp.mich...@samsung.com
---
src/modules/ecore_imf/wayland/text-client-protocol.h | 19 +++
1 file changed, 19 insertions(+)
diff --git a/src/modules/ecore_imf/wayland/text-client-protocol.h
b/src/modules/ecore_imf/wayland/text-client-protocol.h
index cfea94b..f9de29c 100644
--- a/src/modules/ecore_imf/wayland/text-client-protocol.h
+++ b/src/modules/ecore_imf/wayland/text-client-protocol.h
@@ -409,24 +409,28 @@ wl_text_input_add_listener(struct wl_text_input
*wl_text_input,
static inline void
wl_text_input_set_user_data(struct wl_text_input *wl_text_input, void
*user_data)
{
+ if (!wl_text_input) return;
wl_proxy_set_user_data((struct wl_proxy *) wl_text_input, user_data);
}
static inline void *
wl_text_input_get_user_data(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return NULL;
return wl_proxy_get_user_data((struct wl_proxy *) wl_text_input);
}
static inline void
wl_text_input_destroy(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_destroy((struct wl_proxy *) wl_text_input);
}
static inline void
wl_text_input_activate(struct wl_text_input *wl_text_input, struct wl_seat
*seat, struct wl_surface *surface)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_ACTIVATE, seat, surface);
}
@@ -434,6 +438,7 @@ wl_text_input_activate(struct wl_text_input
*wl_text_input, struct wl_seat *seat
static inline void
wl_text_input_deactivate(struct wl_text_input *wl_text_input, struct wl_seat
*seat)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_DEACTIVATE, seat);
}
@@ -441,6 +446,7 @@ wl_text_input_deactivate(struct wl_text_input
*wl_text_input, struct wl_seat *se
static inline void
wl_text_input_show_input_panel(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_SHOW_INPUT_PANEL);
}
@@ -448,6 +454,7 @@ wl_text_input_show_input_panel(struct wl_text_input
*wl_text_input)
static inline void
wl_text_input_hide_input_panel(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_HIDE_INPUT_PANEL);
}
@@ -455,6 +462,7 @@ wl_text_input_hide_input_panel(struct wl_text_input
*wl_text_input)
static inline void
wl_text_input_reset(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_RESET);
}
@@ -462,6 +470,7 @@ wl_text_input_reset(struct wl_text_input *wl_text_input)
static inline void
wl_text_input_set_surrounding_text(struct wl_text_input *wl_text_input,
const char *text, uint32_t cursor, uint32_t anchor)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_SET_SURROUNDING_TEXT, text, cursor,
anchor);
}
@@ -469,6 +478,7 @@ wl_text_input_set_surrounding_text(struct wl_text_input
*wl_text_input, const ch
static inline void
wl_text_input_set_content_type(struct wl_text_input *wl_text_input, uint32_t
hint, uint32_t purpose)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_SET_CONTENT_TYPE, hint, purpose);
}
@@ -476,6 +486,7 @@ wl_text_input_set_content_type(struct wl_text_input
*wl_text_input, uint32_t hin
static inline void
wl_text_input_set_cursor_rectangle(struct wl_text_input *wl_text_input,
int32_t x, int32_t y, int32_t width, int32_t height)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_SET_CURSOR_RECTANGLE, x, y, width,
height);
}
@@ -483,6 +494,7 @@ wl_text_input_set_cursor_rectangle(struct wl_text_input
*wl_text_input, int32_t
static inline void
wl_text_input_set_preferred_language(struct wl_text_input *wl_text_input,
const char *language)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
Re: [E-devel] [EGIT] [core/efl] master 01/02: Add missing safety checks for valid proxy objects before trying to call functions on the object
H...No, I don't think we should go through the process of generating
them during build as that would mean we would need to use the wayland
scanner during build
The issue here is that I experienced a crash when trying to run
terminology in Enlightenment when E was built with wayland client
support. The problem is that, if we unload the wayland text module, then
wl_text_input, and wl_text_input_manager became NULL, but calls were
still being made into the text-client-protocol...thus causing wl_proxy
segfaults.
There is another issue also with all this imf stuff and how it is done.
That issue is that if we build E with wayland-client support, and try to
start terminology (using the elm x11 engine), then we get a complete
crash of E. This happens because the ecore_imf code is loading the
ecore_imf_wayland module Regardless of the engine which is being used.
IMO, the ecore_imf stuff needs a better way to detect which imf module
to load.
I guess, because the protocol files are generated with wayland-scanner,
then we are stuck with that crappy formatting for those files :( I don't
see what we can do about it right nowand quite frankly, I have too
much on my plate at the moment to even be able to find time to think
about it :(
dh
On 06/25/13 15:24, Eduardo Lima (Etrunko) wrote:
This is auto generated by wayland scanner, do you think we should
include the xml files and generate the source files instead of
including them?
On Tue, Jun 25, 2013 at 10:14 AM, Chris Michael - Enlightenment Git
no-re...@enlightenment.org wrote:
devilhorns pushed a commit to branch master.
commit 0615dfe4ee1636b56086545605ea9dd6dadb95c2
Author: Chris Michael cp.mich...@samsung.com
Date: Tue Jun 25 13:51:53 2013 +0100
Add missing safety checks for valid proxy objects before trying to
call functions on the object
Signed-off-by: Chris Michael cp.mich...@samsung.com
---
src/modules/ecore_imf/wayland/text-client-protocol.h | 19
+++
1 file changed, 19 insertions(+)
diff --git a/src/modules/ecore_imf/wayland/text-client-protocol.h
b/src/modules/ecore_imf/wayland/text-client-protocol.h
index cfea94b..f9de29c 100644
--- a/src/modules/ecore_imf/wayland/text-client-protocol.h
+++ b/src/modules/ecore_imf/wayland/text-client-protocol.h
@@ -409,24 +409,28 @@ wl_text_input_add_listener(struct wl_text_input
*wl_text_input,
static inline void
wl_text_input_set_user_data(struct wl_text_input *wl_text_input, void
*user_data)
{
+ if (!wl_text_input) return;
wl_proxy_set_user_data((struct wl_proxy *) wl_text_input,
user_data);
}
static inline void *
wl_text_input_get_user_data(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return NULL;
return wl_proxy_get_user_data((struct wl_proxy *) wl_text_input);
}
static inline void
wl_text_input_destroy(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_destroy((struct wl_proxy *) wl_text_input);
}
static inline void
wl_text_input_activate(struct wl_text_input *wl_text_input, struct wl_seat
*seat, struct wl_surface *surface)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_ACTIVATE, seat, surface);
}
@@ -434,6 +438,7 @@ wl_text_input_activate(struct wl_text_input
*wl_text_input, struct wl_seat *seat
static inline void
wl_text_input_deactivate(struct wl_text_input *wl_text_input, struct
wl_seat *seat)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_DEACTIVATE, seat);
}
@@ -441,6 +446,7 @@ wl_text_input_deactivate(struct wl_text_input
*wl_text_input, struct wl_seat *se
static inline void
wl_text_input_show_input_panel(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_SHOW_INPUT_PANEL);
}
@@ -448,6 +454,7 @@ wl_text_input_show_input_panel(struct wl_text_input
*wl_text_input)
static inline void
wl_text_input_hide_input_panel(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_HIDE_INPUT_PANEL);
}
@@ -455,6 +462,7 @@ wl_text_input_hide_input_panel(struct wl_text_input
*wl_text_input)
static inline void
wl_text_input_reset(struct wl_text_input *wl_text_input)
{
+ if (!wl_text_input) return;
wl_proxy_marshal((struct wl_proxy *) wl_text_input,
WL_TEXT_INPUT_RESET);
}
@@ -462,6 +470,7 @@ wl_text_input_reset(struct wl_text_input *wl_text_input)
static inline void
wl_text_input_set_surrounding_text(struct wl_text_input *wl_text_input,
const char *text, uint32_t
[E-devel] All of the themes except for dark were migrated to git
Dark was not migrated as requested by Carsten (he wanted a few days extension). Enjoy. -- Tom. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
Massimo Maiurana, il 16/06/2013 09:24, ha scritto: Don't know if it's really a bug, but when I maximize a window it goes partly under a shelf set as above all I don't see this anymore, but there is another problem with a configuration option. By default the battery module is set to suspend the system if battery is low. I would prefer if it would hibernate instead, so I go in advanced options and tell it to hibernate when under 3%, but at next startup the option is set again to suspend. Hibernation does work if I select it from syscon. -- Massimo Maiurana GPG keyID #7044D601 La fede e' credere in cio' che sai non essere vero [Mark Twain] -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
On Tue, Jun 11, 2013 at 11:55 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: The old thread was too long for me to see if I fixed everything, so post here if you have a bug that's present using the latest revision. -- The pager live previews are broken and show noise instead, see screenshot below (it should show a different live preview picture for each desktop). http://www.enlightenment.org/ss/e-51ca2e51d24c10.20360856.jpg I think this was introduced in the last days, maybe not an e but an efl bug. Maybe someone will know of the top of the head what caused it, otherwise I can bisect. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] E18 CFBugs #2
From: tho...@gstaedtner.net Date: Wed, 26 Jun 2013 02:00:18 +0200 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] E18 CFBugs #2 On Tue, Jun 11, 2013 at 11:55 AM, Michael Blumenkrantz michael.blumenkra...@gmail.com wrote: The old thread was too long for me to see if I fixed everything, so post here if you have a bug that's present using the latest revision. -- The pager live previews are broken and show noise instead, see screenshot below (it should show a different live preview picture for each desktop). http://www.enlightenment.org/ss/e-51ca2e51d24c10.20360856.jpg I think this was introduced in the last days, maybe not an e but an efl bug. Maybe someone will know of the top of the head what caused it, otherwise I can bisect. Looks similar: https://phab.enlightenment.org/T187 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] E Korean diner before summer
On 06/13/13 14:31, Cedric BAIL wrote: Hello everyone, Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe starting in the afternoon. Have fun, -- Cedric BAIL So the votes went mostly for sunday june 30 in Seoul: https://phab.enlightenment.org/V1 Let's do it? At what time/place? -- Jérôme Pinot http://ngc891.blogdns.net/ signature.asc Description: Digital signature -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] E Korean diner before summer
On Wed, Jun 26, 2013 at 10:59 AM, Jérôme Pinot ngc...@gmail.com wrote: On 06/13/13 14:31, Cedric BAIL wrote: Hello everyone, Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe starting in the afternoon. Have fun, -- Cedric BAIL So the votes went mostly for sunday june 30 in Seoul: https://phab.enlightenment.org/V1 Let's do it? At what time/place? Yeah ! Gangnam at 5pm ? -- Cedric BAIL -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] E Korean diner before summer
On Wed, 26 Jun 2013 10:59:39 +0900 Jérôme Pinot ngc...@gmail.com said: On 06/13/13 14:31, Cedric BAIL wrote: Hello everyone, Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe starting in the afternoon. Have fun, -- Cedric BAIL So the votes went mostly for sunday june 30 in Seoul: https://phab.enlightenment.org/V1 Let's do it? At what time/place? https://maps.google.com/maps?q=Brick+Oven+New+York+Pizza+Gangnam+Seoul,+Gangnam-gu,+Seoul,+South+Koreahl=enll=37.502913,127.027694spn=0.00177,0.001971sll=37.503283,127.028019sspn=0.003541,0.003943oq=gangnam+new+yorkhq=Brick+Oven+New+York+Pizza+Gangnam+Seoul,hnear=Gangnam-gu,+Seoul,+South+Koreat=mz=19iwloc=Alayer=ccbll=37.502999,127.02777panoid=9RXWSeBE9zHCxRK9K4f8Jgcbp=12,317.69,,0,-2.46 :) -- Jérôme Pinot http://ngc891.blogdns.net/ -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [e-users] E Korean diner before summer
On Wed, Jun 26, 2013 at 11:17 AM, Carsten Haitzler ras...@rasterman.com wrote: On Wed, 26 Jun 2013 10:59:39 +0900 Jérôme Pinot ngc...@gmail.com said: On 06/13/13 14:31, Cedric BAIL wrote: Hello everyone, Who is in for a E-Dinner in Seoul on the 29 evening ? Maybe starting in the afternoon. Have fun, -- Cedric BAIL So the votes went mostly for sunday june 30 in Seoul: https://phab.enlightenment.org/V1 Let's do it? At what time/place? https://maps.google.com/maps?q=Brick+Oven+New+York+Pizza+Gangnam+Seoul,+Gangnam-gu,+Seoul,+South+Koreahl=enll=37.502913,127.027694spn=0.00177,0.001971sll=37.503283,127.028019sspn=0.003541,0.003943oq=gangnam+new+yorkhq=Brick+Oven+New+York+Pizza+Gangnam+Seoul,hnear=Gangnam-gu,+Seoul,+South+Koreat=mz=19iwloc=Alayer=ccbll=37.502999,127.02777panoid=9RXWSeBE9zHCxRK9K4f8Jgcbp=12,317.69,,0,-2.46 We need to booked for that place. I am tasking JP for this as a homework :-) And maybe earlier we can go to some coffee place. -- Cedric BAIL -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ 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: efreet: don't try change permissions on runtime dir we don't own.
On 06/25/2013 10:00 AM, Carsten Haitzler (The Rasterman) wrote: On Tue, 25 Jun 2013 04:03:28 +0200 Sebastian Dransfeld s...@tango.flipp.net said: On 06/24/2013 05:00 AM, Carsten Haitzler (Rasterman) - Enlightenment Git wrote: raster pushed a commit to branch master. commit 8e3d94d66130f16cec0d518a0ad6ec5fae04fec9 Author: Carsten Haitzler (Rasterman) ras...@rasterman.com Date: Mon Jun 24 12:00:30 2013 +0900 efreet: don't try change permissions on runtime dir we don't own. If we should have mode 0700 on runtime dir, shouldn't it be a warning if we don't own it? Seems like it should be private. in the common case ... XDG_RUNTIME_DIR ends up being /tmp and so it ALWAYS bitches... :) I changed the code here and in E to not use /tmp as common case, but a tmpdir created by mkdtemp S. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Enlightenment pngs with embedded iCC profiles
On Sat, 22 Jun 2013 00:03:09 -0500 Doug Newgard scimmi...@outlook.com said: Date: Sat, 22 Jun 2013 13:41:31 +0900 From: ras...@rasterman.com To: enlightenment-devel@lists.sourceforge.net CC: scimmi...@outlook.com Subject: Re: [E-devel] Enlightenment pngs with embedded iCC profiles On Fri, 21 Jun 2013 23:33:19 -0500 Doug Newgard scimmi...@outlook.com said: Date: Sat, 22 Jun 2013 13:20:33 +0900 From: ras...@rasterman.com To: enlightenment-devel@lists.sourceforge.net CC: onef...@gmail.com Subject: Re: [E-devel] Enlightenment pngs with embedded iCC profiles On Sat, 22 Jun 2013 14:12:44 +1000 David Seikel onef...@gmail.com said: On Fri, 21 Jun 2013 22:39:19 -0500 Doug Newgard scimmi...@outlook.com wrote: Date: Sat, 22 Jun 2013 10:44:15 +0900 From: ras...@rasterman.com To: enlightenment-devel@lists.sourceforge.net CC: scimmi...@outlook.com Subject: Re: [E-devel] Enlightenment pngs with embedded iCC profiles On Fri, 21 Jun 2013 16:15:47 -0500 Doug Newgard scimmi...@outlook.com said: I'm sure some of you have seen the warnings generated by libpng 1.6: known incorrect sRGB profile. Now, this is no big deal, it's just a warning, but I still wanted to look into it further. By my count, there are 800 png files in Enlightenment, of which only 6 have embedded iCC profiles, all from HP. The rest are sRGB colorspace, but do not include a profile. There are some good arguments for this (http://imageoptim.com/color-profiles.html http://www.gballard.net/psd/save_for_web_embed_ICC_profile.html) and since this seems to be the default, I've attached the 6 files with the profiles stripped out. As you can see, it doesn't change the image or the colorspace, it just leaves the calibration up to the end user's system. I haven't been able to find just what's wrong with the HP iCC profile being used that the authors of libpng don't like, but it makes sense to standardize the way profiles are handled anyway. And it has the nice side effect of silencing warnings, even if the Debian/Ubuntu users aren't likely to see them for a couple of years. I can just change the iCC profile instead if you would prefer. I've seen multiple people recommend the Argyll sRGB profile, which is still sRGB IEC61966-2.1 and is public domain. Elementary has a lot more pngs with the HP profile, so once I know for sure what people would prefer, I'll fix them, too. Doug what we need to know is what is adding the hp profile causing the warinig. what tool does it? is it gimp? photoshop? imagemagick? otherwise we go creating warnings again if that tool is used... That's a good question. On my machine, GIMP refuses to even export the image with the HP profile, so I doubt that's it unless that's because of libpng 1.6. I do know that the HP profile is not included with GIMP, only their built-in profile which is used for display, it does not get embedded into images. I did find some information about the HP profile in relation to Photoshop, but others said that it didn't come with Photoshop and suggested it may have been included with printer/scanner software. I did find that Photoshop does not embed a profile by default when exporting PNGs. As far as I can tell, Imagemagick doesn't include any iCC profiles, so that can't be it, either. On my system, I have profiles from Colord, Argyll, Oyranos, and Yamma, and none of them include the problem profile. Where this profile came from is sitll a bit of a mystery to me. Look at the SVN / git history for the images with that HP profile. That at least will tell you WHO added them. Than ask that person what they used to make them / last used to massage them / where they got them from. given the images... one i know i created years ago with gimp. others i think came from manowarrior (he did his work with inskacpe and/or photoshop and illustrator?) Yep, git blame on the icons, at least, gives me d6dab499 and f72b2067. The former says icons from manowarrior, the second is optimizing the images. The iCC profile seems to be in the originals from manowarrior. Loading them up in a hex editor, I see a string that says iCCPPhotoshop ICC profile, so this does seem to be originally from Photoshop. I wonder if they're still using it or if it was only in an older version? so... photoshop blame! :) So it would seem. Elementary images attached, 51 of 591 total. I'm also seeing a few in editje, eve, python-efl (taken from elm, I believe), and rage, but this should take care of the bulk of it. done man. done. :) -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)ras...@rasterman.com -- This SF.net email is
Re: [E-devel] Bob. Was: A nice article I think E devs should read
On Tue, 25 Jun 2013 22:26:05 +1000 David Seikel onef...@gmail.com said:
On Tue, 25 Jun 2013 19:57:45 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 25 Jun 2013 19:40:03 +1000 David Seikel onef...@gmail.com
said:
On Tue, 25 Jun 2013 17:02:43 +0900 Carsten Haitzler (The Rasterman)
ras...@rasterman.com wrote:
On Tue, 25 Jun 2013 11:36:10 +1000 David Seikel
onef...@gmail.com said:
On Tue, 25 Jun 2013 10:06:10 +0900 Cedric BAIL
cedric.b...@free.fr wrote:
Right now only a thought exercice, but you can get info
there : https://phab.enlightenment.org/w/bob/ .
Definitely something my LuaJIT experiments will be good for.
A daemon could be in charge of generating the JIT and thus
sharing information across processes (Does LuaJIT allow for
this?).
this is way too premature in terms of optimizing imho. sure -
having N apps all go run their own jit on the same bit of lua is
inefficient. having it jitted once and shared is much better. but
how do we share jitted code sensibly so it can be executed in N
places safely? we would need to share jitted code inside mmaped
shared memory segs mmaped to the same absolute addresses, unless
we modified the jit engine to use base address relative code
generation... ugh!. or we run it all in the server and ipc
results/input to and fro? ... hmm ewww...
If that means that some EFL based C code is generating and
compiling Lua code, in response to commands from a socket, then
yes. If that also includes running the results in a threaded
way with message passing, then also yes (same daemon). I have
these working already. Designed to deal with thousands of Lua
scripts running at once, and using LuaJIT. I've mentioned this
before.
right now thoughts are along the lines of every object type
(widget? or part in edje) is really a bunch of lua to implement
it - or to calculate it and hand off to a go implement this
state for me code...
what i'd like to see is for it to be easily parallelisable into
threads. so we can calculate lots of params/parts in parallel when
possible (independent calc paths - eg of 2 child branches before
parent has to look at results of children) etc. thus why calc vs
implement should be stages.. maybe lua tables with functions
(methods) to implement calc , implement, etc. etc. - don't know.
thought exercise atm.
My point is that this sort of thing is not just a thought exercise
for me, I've done a lot of the work already for another project. I
was always keeping Edje Lua in mind when I did it though, thinking
some of the work could apply there. Naturally I used EFL for this
project. B-)
It's a virtual world scripting engine. Second Life / OpenSim
virtual worlds are made of 256 x 256 meter sims, with hundreds or
thousands of these sims in any given world. Each sim might have
several thousand LSL scripts running, and in a lot of cases most of
those scripts are just multiple copies of the same dozen scripts.
So I've been writing a daemon that generates Lua scripts
(translated from pre existing LSL scripts), then compiles and runs
them with LuaJIT, using a threaded worker queue with message
passing system. Getting it to run fast and use minimal resources
is important for this project. I don't want thousands of these
same dozen scripts soaking up memory, I want one of each.
This daemon will also run in the virtual world viewer, driving Edje
UIs via Edje Lua.
oh.. and we need to figure out how to sensibly override objects.
basically i can smell objects being very oo-like in that they
implement methods. unlike native we can not just totally override a
specific method on an object class (we want to only keep 1 instance
of a class for an object and not generate per actual object created
for efficiency) but we can PATCH a method. i assume we'd use a
metatable with functions stuffed into it to represent a class, for
the basics (please expound on this as u see fit and as to what u
think is good/bad!)... but we can ALSO do things like provide slots
or hook points within a function. let me do a very simple one
(please don't nitpick my poor lua :)):
myclass = {}
function myclass:new()
o = { left = 0; right = 0; size = 0}
-- slot:init-vals
self.__index = self
return setmetatable(o, self)
end
function myclass:layout(obj)
-- slot:pre-calc
self.size = self.left + self.right
-- slot:post-calc
end
now let's say i'm a hacky arty ui person. i want to take the basic
object type myclass but simply add a third element to it -
otherwise keep the rest the same. i really want to patch the code
by inserting some code of my own in available slots like:
slot:init-vals =
