Re: [E-devel] Runtime/linking issue for the Edgar module in E

2020-04-17 Thread Carsten Haitzler
On Fri, 17 Apr 2020 23:20:25 +0200 Davide Andreoli 
said:

> I found a way to get a bit more info, the python error while importing and
> failing is:
> ImportError: /usr/lib/python3.8/site-packages/efl/
> eo.cpython-38-x86_64-linux-gnu.so: undefined symbol: PyUnicode_FromFormat

oh. ... so it is a symbol problem. :) That i believe is provided by
libpython3.8.so ... edgar is linked to this... my guess is then python is
dlopening the pytno-efl binding .so files and expecting the symbols to link
up... but they don't.

an idea. dlopen libpython3.8.so and use RTDL_GLOBAL to put python symbols in
the global namespace instead of linking to libpython at compile time - do it
runtime? then edgar can also choose at runtime either python 2 or python3 libs
- dlsym the symbols you need from these... ? just trying the dlopen and
stuffing it into global namespace may help...

> eo.cpython-38-x86_64-linux-gnu.so is the python-efl module that bind the eo
> library,
> PyUnicode_FromFormat is a normal CPython function that should work...
> the edgar module does not get correctly linked to python?
> 
> Il giorno ven 17 apr 2020 alle ore 21:54 Carsten Haitzler <
> ras...@rasterman.com> ha scritto:
> 
> > On Fri, 17 Apr 2020 19:33:30 +0200 Davide Andreoli  > >
> > said:
> >
> > hmm no. removing RTLD_LOCAL makes no difference. so there goes that idea. i
> > have python-efl bindings installed - i can run ecoonman-bin as a test.
> > there is
> > no output i see from python complaining... knowing what exactly fails will
> > be
> > key to finding out why. like cant find a symbol? missing link/dependency on
> > load? something else? as there is nothing telling me what... it needs much
> > deeper digging
> >
> > > Hi guys,
> > > I'm lost in trying to fix the Edgar module to run again in E. Since some
> > > months the python import machinery does not work anymore and the edgar
> > > module is not able anymore to import the python efl bindings.
> > >
> > > Nothing has changed in Edgar nor in python-efl and I'm able to correctly
> > > use the machinery in a simple test app (attached), it just does not work
> > > when used inside an E module. I suspect something related to the new
> > meson
> > > build, but not sure at all.
> > >
> > > The simple test attached can be built as:
> > > gcc -o test_py test_py.c `python-config --cflags --libs --embed`
> > > `pkg-config --libs --cflags efl-ui`
> > > when run it print OK, that means the python-efl module has been found and
> > > linked. While the same code in edgar fails on the import_efl__eo() call.
> > > Note the test also need the attached .h file to build
> > >
> > > To build/run this simple code of course python-efl must be installed
> > > https://phab.enlightenment.org/w/projects/python_bindings_for_efl/
> > >
> > > The edgar module instead is documented here:
> > > https://phab.enlightenment.org/w/emodules/edgar/
> > >
> > > Any help/ideas would be appreciated as I really don't have any idea atm
> > >
> > > The same issue has been recently raised also on the e-user mailing list
> > >
> > > Thanks
> > > DaveMDS
> >
> >
> > --
> > - Codito, ergo sum - "I code, therefore I am" --
> > Carsten Haitzler - ras...@rasterman.com
> >
> >


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



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


Re: [E-devel] Runtime/linking issue for the Edgar module in E

2020-04-17 Thread Davide Andreoli
I found a way to get a bit more info, the python error while importing and
failing is:
ImportError: /usr/lib/python3.8/site-packages/efl/
eo.cpython-38-x86_64-linux-gnu.so: undefined symbol: PyUnicode_FromFormat

eo.cpython-38-x86_64-linux-gnu.so is the python-efl module that bind the eo
library,
PyUnicode_FromFormat is a normal CPython function that should work...
the edgar module does not get correctly linked to python?

Il giorno ven 17 apr 2020 alle ore 21:54 Carsten Haitzler <
ras...@rasterman.com> ha scritto:

> On Fri, 17 Apr 2020 19:33:30 +0200 Davide Andreoli  >
> said:
>
> hmm no. removing RTLD_LOCAL makes no difference. so there goes that idea. i
> have python-efl bindings installed - i can run ecoonman-bin as a test.
> there is
> no output i see from python complaining... knowing what exactly fails will
> be
> key to finding out why. like cant find a symbol? missing link/dependency on
> load? something else? as there is nothing telling me what... it needs much
> deeper digging
>
> > Hi guys,
> > I'm lost in trying to fix the Edgar module to run again in E. Since some
> > months the python import machinery does not work anymore and the edgar
> > module is not able anymore to import the python efl bindings.
> >
> > Nothing has changed in Edgar nor in python-efl and I'm able to correctly
> > use the machinery in a simple test app (attached), it just does not work
> > when used inside an E module. I suspect something related to the new
> meson
> > build, but not sure at all.
> >
> > The simple test attached can be built as:
> > gcc -o test_py test_py.c `python-config --cflags --libs --embed`
> > `pkg-config --libs --cflags efl-ui`
> > when run it print OK, that means the python-efl module has been found and
> > linked. While the same code in edgar fails on the import_efl__eo() call.
> > Note the test also need the attached .h file to build
> >
> > To build/run this simple code of course python-efl must be installed
> > https://phab.enlightenment.org/w/projects/python_bindings_for_efl/
> >
> > The edgar module instead is documented here:
> > https://phab.enlightenment.org/w/emodules/edgar/
> >
> > Any help/ideas would be appreciated as I really don't have any idea atm
> >
> > The same issue has been recently raised also on the e-user mailing list
> >
> > Thanks
> > DaveMDS
>
>
> --
> - Codito, ergo sum - "I code, therefore I am" --
> Carsten Haitzler - ras...@rasterman.com
>
>

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


Re: [E-devel] Runtime/linking issue for the Edgar module in E

2020-04-17 Thread The Rasterman
On Fri, 17 Apr 2020 19:33:30 +0200 Davide Andreoli 
said:

hmm no. removing RTLD_LOCAL makes no difference. so there goes that idea. i
have python-efl bindings installed - i can run ecoonman-bin as a test. there is
no output i see from python complaining... knowing what exactly fails will be
key to finding out why. like cant find a symbol? missing link/dependency on
load? something else? as there is nothing telling me what... it needs much
deeper digging

> Hi guys,
> I'm lost in trying to fix the Edgar module to run again in E. Since some
> months the python import machinery does not work anymore and the edgar
> module is not able anymore to import the python efl bindings.
> 
> Nothing has changed in Edgar nor in python-efl and I'm able to correctly
> use the machinery in a simple test app (attached), it just does not work
> when used inside an E module. I suspect something related to the new meson
> build, but not sure at all.
> 
> The simple test attached can be built as:
> gcc -o test_py test_py.c `python-config --cflags --libs --embed`
> `pkg-config --libs --cflags efl-ui`
> when run it print OK, that means the python-efl module has been found and
> linked. While the same code in edgar fails on the import_efl__eo() call.
> Note the test also need the attached .h file to build
> 
> To build/run this simple code of course python-efl must be installed
> https://phab.enlightenment.org/w/projects/python_bindings_for_efl/
> 
> The edgar module instead is documented here:
> https://phab.enlightenment.org/w/emodules/edgar/
> 
> Any help/ideas would be appreciated as I really don't have any idea atm
> 
> The same issue has been recently raised also on the e-user mailing list
> 
> Thanks
> DaveMDS


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



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


Re: [E-devel] Runtime/linking issue for the Edgar module in E

2020-04-17 Thread The Rasterman
On Fri, 17 Apr 2020 19:33:30 +0200 Davide Andreoli 
said:

it may also be that i changed modules to load with RTDL_LOCAL in e_module_new()
to have them not leak symbols to the rest of e when people are not careful to
use static and careful namespacing.

> Hi guys,
> I'm lost in trying to fix the Edgar module to run again in E. Since some
> months the python import machinery does not work anymore and the edgar
> module is not able anymore to import the python efl bindings.
> 
> Nothing has changed in Edgar nor in python-efl and I'm able to correctly
> use the machinery in a simple test app (attached), it just does not work
> when used inside an E module. I suspect something related to the new meson
> build, but not sure at all.
> 
> The simple test attached can be built as:
> gcc -o test_py test_py.c `python-config --cflags --libs --embed`
> `pkg-config --libs --cflags efl-ui`
> when run it print OK, that means the python-efl module has been found and
> linked. While the same code in edgar fails on the import_efl__eo() call.
> Note the test also need the attached .h file to build
> 
> To build/run this simple code of course python-efl must be installed
> https://phab.enlightenment.org/w/projects/python_bindings_for_efl/
> 
> The edgar module instead is documented here:
> https://phab.enlightenment.org/w/emodules/edgar/
> 
> Any help/ideas would be appreciated as I really don't have any idea atm
> 
> The same issue has been recently raised also on the e-user mailing list
> 
> Thanks
> DaveMDS


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



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


[E-devel] Runtime/linking issue for the Edgar module in E

2020-04-17 Thread Davide Andreoli
Hi guys,
I'm lost in trying to fix the Edgar module to run again in E. Since some
months the python import machinery does not work anymore and the edgar
module is not able anymore to import the python efl bindings.

Nothing has changed in Edgar nor in python-efl and I'm able to correctly
use the machinery in a simple test app (attached), it just does not work
when used inside an E module. I suspect something related to the new meson
build, but not sure at all.

The simple test attached can be built as:
gcc -o test_py test_py.c `python-config --cflags --libs --embed`
`pkg-config --libs --cflags efl-ui`
when run it print OK, that means the python-efl module has been found and
linked. While the same code in edgar fails on the import_efl__eo() call.
Note the test also need the attached .h file to build

To build/run this simple code of course python-efl must be installed
https://phab.enlightenment.org/w/projects/python_bindings_for_efl/

The edgar module instead is documented here:
https://phab.enlightenment.org/w/emodules/edgar/

Any help/ideas would be appreciated as I really don't have any idea atm

The same issue has been recently raised also on the e-user mailing list

Thanks
DaveMDS
/* Generated by Cython 0.29.14 */

#ifndef __PYX_HAVE_API__efl__eo
#define __PYX_HAVE_API__efl__eo
#ifdef __MINGW64__
#define MS_WIN64
#endif
#include "Python.h"

static PyObject *(*__pyx_api_f_3efl_2eo_object_from_instance)(Eo *) = 0;
#define object_from_instance __pyx_api_f_3efl_2eo_object_from_instance
static Eo *(*__pyx_api_f_3efl_2eo_instance_from_object)(PyObject *) = 0;
#define instance_from_object __pyx_api_f_3efl_2eo_instance_from_object
#if !defined(__Pyx_PyIdentifier_FromString)
#if PY_MAJOR_VERSION < 3
  #define __Pyx_PyIdentifier_FromString(s) PyString_FromString(s)
#else
  #define __Pyx_PyIdentifier_FromString(s) PyUnicode_FromString(s)
#endif
#endif

#ifndef __PYX_HAVE_RT_ImportFunction
#define __PYX_HAVE_RT_ImportFunction
static int __Pyx_ImportFunction(PyObject *module, const char *funcname, void (**f)(void), const char *sig) {
PyObject *d = 0;
PyObject *cobj = 0;
union {
void (*fp)(void);
void *p;
} tmp;
d = PyObject_GetAttrString(module, (char *)"__pyx_capi__");
if (!d)
goto bad;
cobj = PyDict_GetItemString(d, funcname);
if (!cobj) {
PyErr_Format(PyExc_ImportError,
"%.200s does not export expected C function %.200s",
PyModule_GetName(module), funcname);
goto bad;
}
#if PY_VERSION_HEX >= 0x0207
if (!PyCapsule_IsValid(cobj, sig)) {
PyErr_Format(PyExc_TypeError,
"C function %.200s.%.200s has wrong signature (expected %.500s, got %.500s)",
 PyModule_GetName(module), funcname, sig, PyCapsule_GetName(cobj));
goto bad;
}
tmp.p = PyCapsule_GetPointer(cobj, sig);
#else
{const char *desc, *s1, *s2;
desc = (const char *)PyCObject_GetDesc(cobj);
if (!desc)
goto bad;
s1 = desc; s2 = sig;
while (*s1 != '\0' && *s1 == *s2) { s1++; s2++; }
if (*s1 != *s2) {
PyErr_Format(PyExc_TypeError,
"C function %.200s.%.200s has wrong signature (expected %.500s, got %.500s)",
 PyModule_GetName(module), funcname, sig, desc);
goto bad;
}
tmp.p = PyCObject_AsVoidPtr(cobj);}
#endif
*f = tmp.fp;
if (!(*f))
goto bad;
Py_DECREF(d);
return 0;
bad:
Py_XDECREF(d);
return -1;
}
#endif


static int import_efl__eo(void) {
  PyObject *module = 0;
  module = PyImport_ImportModule("efl.eo");
  if (!module) goto bad;
  if (__Pyx_ImportFunction(module, "object_from_instance", (void (**)(void))&__pyx_api_f_3efl_2eo_object_from_instance, "PyObject *(Eo *)") < 0) goto bad;
  if (__Pyx_ImportFunction(module, "instance_from_object", (void (**)(void))&__pyx_api_f_3efl_2eo_instance_from_object, "Eo *(PyObject *)") < 0) goto bad;
  Py_DECREF(module); module = 0;
  return 0;
  bad:
  Py_XDECREF(module);
  return -1;
}

#endif /* !__PYX_HAVE_API__efl__eo */

// gcc -o test_py test_py.c `python-config --cflags --libs --embed` `pkg-config --libs --cflags efl-ui` &&  ./test_py

#include 
#include 

#include 
#include "efl.eo_api.h"



int main() {
   printf("Hello, World! \n");

   Py_Initialize();

   if (import_efl__eo() != 0)
   {
  printf("ERROR: Cannot import python-efl \n");
  return 1;
   }
   else
   {
  printf("OK \n");   
   }

   Py_Finalize();
   printf("DONE \n");
   return 0;
}
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


Re: [E-devel] e 0.24 release coming right after efl 1.24

2020-04-17 Thread Carsten Haitzler
On Thu, 16 Apr 2020 22:13:15 -0700 Ross Vandegrift  said:

> On Wed, Apr 15, 2020 at 08:13:01AM +0100, Carsten Haitzler wrote:
> > i want to kill the text console. i just don't see the point. it's so
> > limited. it's no longer even ext mode. it's graphics mode with the kernel
> > emulating text on it for you.
> 
> For day-to-day, I agree.  But it's nice when I've junked up my WM or its
> libraries and need an easy way to reinstall good packages... :)

and that's what things like kmscon are for - a userspace gui that provides a
terminal emulator. for example. instead of a kernel text mode thing it's a
graphics mode application like any of the wayland compositors or running nay
efl app in the vt - it takes over and renders the vt and handles input ... but
in userspace. this app would also then be responsible for configuring backlight
too.

also keep in mind that the vt is totally cooperative already. ctrl+alt+f1/f2/f3
etc. is handled by processes. you can run chvt but the vt owner has to
voluntarily give it up. if it doesn't, it's hung. if it's wayland compositors -
if that compositor hangs and doesn't handle the chvt request or the actual
ctrl+alt+f1/f2/f3 keys then voluntarily give it up and request a switch to that
other vt (hoping the new vt owner takes over properly). it's already unreliable
because of this... so something in userspace like kmscon really wouldn't be
worse. especially if it were done as a static binary for emergencies.

> > a graphical session with a fullscreen terminology gives the same
> > effect/result just with a lot of added bonuses. hell terminology runs in a
> > vt (but won't control backlight due to that needing infra that needs root
> > access).
> 
> Is there a way to force terminology to open a specific /dev/tty?  I just
> tried to replace agetty in getty@.service with terminology.  It almost
> works.  But it doesn't pick up the active terminal.  The process runs,
> but nothing is drawn.

https://raymii.org/s/tutorials/Run_software_on_tty1_console_instead_of_login_getty.html

but my exec line is:
ExecStart=-/usr/bin/agetty --skip-login --noissue --login-options "-f raster"
%I linux

then i used ~/.profile (or ~/.zprofile for me as i use zsh):

if test -n "$XDG_VTNR"; then
  export E_WL_FORCE=drm
  exec enlightenment_start >& .esession-log
fi

to launch e - replace enlightenment_star with terminology and it'll run that
instead.

> (I'm not saying this a good idea, terminology is scary to run as root.
> But still, would be a fun trick.)

yeah. this was something i was mulling - have a lock-down mode of some sort ...
but then you'd lose the ability to show images, play video, handle file
paths/urls etc. and lose a lot of the settings too... but given enough
disabling it would be able to run without allowing the user to get the host
terminal running as root to do much bad.

> > at some point the kernel probably needs to wire up backlight to kms. also
> > ddc controls probably need to be wired up with that too. you know e can
> > control monitor backlights just like it controls your laptop internal
> > screen backlight? you can adjust brightness of each external monitor
> > individually and e will also... fade these in and out to/from min to max
> > etc. alongside your laptop internal backlight... :) it's lout of the box if
> > you have libddcutil installed.
> 
> I saw you mention this, but haven't had a chance to try it.  Been
> testing without docking.  Definitely a cool feature though.
> 
> Ross
> 


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



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