> Hi, few notes: > > 1. whole UI related stuff should be done using common import + UI.call > as it is already attached to component system and it is not written in > ruby. What is this common import and UI.call? I don't follow. > > 2. yast.py is basically reimplementation of yast stuff in python. I am > not sure if it is right way, as anything you will need you have to > reimplement Yes, the yast.py code is wrong. I'm trying to think of a good way to use the ruby Wizard code, etc. You mention there is a way to be able to call functions between yast modules? > > 3. your modules is not possible to call from rest of YaST. For ycp, > perl and ruby it is possible to call it from each other. > > So in short. Your approach is more like wrapper for c++ parts > ( currently only UI ) and rewrite for rest. > > In general if you need only UI from YaST, then I suggest to use direct > approach and use libyui python bindings - > https://github.com/libyui/libyui-bindings . But as I said this approach > prevent you to use any part written in ruby and also rest of YaST > cannot call your methods. > > It miss some layer from ycp-ui-bindings, but provide all needed to > build UI. > > Josef > > >> On 10/03/2017 01:31 AM, Josef Reidinger wrote: >>> V Mon, 2 Oct 2017 10:48:46 -0600 >>> David Mulder <[email protected]> napsáno: >>> >>>> What ruby-debug packages did you want installed? I'm not familiar >>>> with ruby or it's packaging. I see a 'debuginfo' package, but it's >>>> only available for ruby2.4+ >>> It depends what system ruby you use. but it looks like it use >>> ruby2.2 then package is libruby2_2-2_2-debuginfo >>> >>> Josef >>> >>>> On 10/02/2017 10:08 AM, Josef Reidinger wrote: >>>>> This stack looks like zero pointer access which is quite strange. >>>>> Can you install ruby-debug packages, to get some defaults? Ideally >>>>> it have to debugged by gdb to see what is going wrong. >>>>> >>>>> Josef >>>>> >>>>> >>>>> V Mon, 2 Oct 2017 10:03:58 -0600 >>>>> David Mulder <[email protected]> napsáno: >>>>> >>>>>> Here are the results from valgrind: >>>>>> >>>>>> ==32174== Invalid read of size 8 >>>>>> ==32174== at 0x18E99855: ??? >>>>>> (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== by >>>>>> 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== >>>>>> by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) >>>>>> ==32174== by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) >>>>>> ==32174== by 0x231AA140: >>>>>> QAbstractEventDispatcherPrivate::allocateTimerId() >>>>>> (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by 0x231AA7B8: >>>>>> QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, >>>>>> QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by >>>>>> 0x231DC54D: QObject::startTimer(int, Qt::TimerType) >>>>>> (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by >>>>>> 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== >>>>>> by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174== >>>>>> by 0x2AF5B8D1: dbus_connection_send_with_reply >>>>>> (in /lib64/libdbus-1.so.3.14.11) ==32174== by 0x287C553C: ??? >>>>>> (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== by 0x231DAF61: >>>>>> QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) >>>>>> ==32174== Address 0x0 is not stack'd, malloc'd or (recently) >>>>>> free'd ==32174== >>>>>> ==32174== >>>>>> ==32174== Process terminating with default action of signal 11 >>>>>> (SIGSEGV): dumping core >>>>>> ==32174== Access not within mapped region at address 0x0 >>>>>> ==32174== at 0x18E99855: ??? >>>>>> (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== by >>>>>> 0x18D75C4A: ??? (in /usr/lib64/libruby2.2.so.2.2.0) ==32174== >>>>>> by 0x18E2C29D: ??? (in /usr/lib64/libruby2.2.so.2.2.0) >>>>>> ==32174== by 0x5295B8F: ??? (in /lib64/libpthread-2.25.so) >>>>>> ==32174== by 0x231AA140: >>>>>> QAbstractEventDispatcherPrivate::allocateTimerId() >>>>>> (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by 0x231AA7B8: >>>>>> QAbstractEventDispatcher::registerTimer(int, Qt::TimerType, >>>>>> QObject*) (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by >>>>>> 0x231DC54D: QObject::startTimer(int, Qt::TimerType) >>>>>> (in /usr/lib64/libQt5Core.so.5.9.0) ==32174== by >>>>>> 0x287C59F5: ??? (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== >>>>>> by 0x2AF70CDC: ??? (in /lib64/libdbus-1.so.3.14.11) ==32174== >>>>>> by 0x2AF5B8D1: dbus_connection_send_with_reply >>>>>> (in /lib64/libdbus-1.so.3.14.11) ==32174== by 0x287C553C: ??? >>>>>> (in /usr/lib64/libQt5DBus.so.5.9.0) ==32174== by 0x231DAF61: >>>>>> QObject::event(QEvent*) (in /usr/lib64/libQt5Core.so.5.9.0) >>>>>> ==32174== If you believe this happened as a result of a stack >>>>>> ==32174== overflow in your program's main thread (unlikely but >>>>>> ==32174== possible), you can try to increase the size of the >>>>>> ==32174== main thread stack using the --main-stacksize= flag. >>>>>> ==32174== The main thread stack size used in this run was >>>>>> 8388608. >>>>>> >>>>>> Full results are attached. >>>>>> >>>>>> >>>>>> On 10/02/2017 09:51 AM, Josef Reidinger wrote: >>>>>>> V Mon, 2 Oct 2017 09:34:27 -0600 >>>>>>> David Mulder <[email protected]> napsáno: >>>>>>> >>>>>>>> I've written a yast module in python (can be found here: >>>>>>>> https://github.com/dmulder/yast-gpmc ), and have encountered >>>>>>>> some issues. >>>>>>>> >>>>>>>> * When exiting the module, it always crashes, with a backtrace. >>>>>>>> It appears that yast is crashing in a destructor somewhere. >>>>>>>> <main>: [BUG] Segmentation fault at 0x000000000017f0 >>>>>>>> ruby 2.2.6p396 (2016-11-15 revision 56800) [x86_64-linux-gnu] >>>>>>>> >>>>>>>> -- Control frame information >>>>>>>> ----------------------------------------------- c:0001 p:0000 >>>>>>>> s:0002 E:0025e0 TOP [FINISH] >>>>>>>> >>>>>>>> >>>>>>>> -- Machine register context >>>>>>>> ------------------------------------------------ RIP: >>>>>>>> 0x00000000000017f0 RBP: 0x00007f69a34388c0 RSP: >>>>>>>> 0x00007f699f6b9a98 RAX: 0x00007f69983cff90 RBX: >>>>>>>> 0x00007f69980eb2a0 RCX: 0x00007f6998002e80 RDX: >>>>>>>> 0x00007f699f6b9cf0 RDI: 0x00007f69980eb2a0 RSI: >>>>>>>> 0x00007f69980eb2a0 R8: 0x00007f69984dadc8 R9: >>>>>>>> 0x00007f69984dada0 R10: 0x000055efbe7e7660 R11: >>>>>>>> 0x0000000000040614 R12: 0x00007f699f6b9cf0 R13: >>>>>>>> 0x00007f6998002150 R14: 0x00007f69980eb2a0 R15: >>>>>>>> 0x00007f699f6b9cf0 EFL: 0x0000000000010206 >>>>>>>> >>>>>>>> -- C level backtrace information >>>>>>>> ------------------------------------------- >>>>>>> output is not much helpful, can you debug it with gdb and >>>>>>> valgrind and print where it is badly accessed? >>>>>>> >>>>>>>> * Yast doesn't recognize python modules that are installed, and >>>>>>>> doesn't add them to the menu. >>>>>>>>> l /usr/local/share/YaST2/clients/gpmc.py >>>>>>>> -rw-r--r-- 1 root root 2057 Sep 28 09:03 >>>>>>>> /usr/local/share/YaST2/clients/gpmc.py >>>>>>>>> sudo yast2 gpmc >>>>>>>> No such client module gpmc >>>>>>>> >>>>>>> It is known limitation of python bindings. Perl and python >>>>>>> bindings does not have support for clients. Only ruby bindings >>>>>>> have it and it was a bit tricky to add it. >>>>>>> If you want to add it to python, check how ruby ones are done: >>>>>>> >>>>>>> https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2CCRubyClient.h >>>>>>> https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClientComponent.h >>>>>>> >>>>>>> actual call of client >>>>>>> https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/Y2RubyClientComponent.cc#L53 >>>>>>> https://github.com/yast/yast-ruby-bindings/blob/master/src/binary/YRuby.cc#L237 >>>>>>> >>>>>>> so in short. You have to have Component creator for clients, >>>>>>> then client component which do then actual call of python >>>>>>> method that somehow invoke python code.
-- David Mulder SUSE Labs Software Engineer - Samba [email protected] SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
