Jump to content

Photo

i386 python-efl docs, wrong symlink _gv.i686-linux-gnu.so

python-efl libgv-python

  • Please log in to reply
6 replies to this topic

#1 ylee

ylee

    King of the Software Page

  • Moderators
  • 1583 posts
  • LocationSouth Carolina, USA

Posted 01 April 2017 - 06:28 PM

Yak-shaving seems to be the story of my life when programming. 
 
<Background-Info>

Spoiler

</Background-Info>
 
So to summarize my original problem was to code a font-selection dialog in py-efl as fully functional as the gtk or other toolkit versions complete with a  font style setting. Sounds simple enough and a little research revealed I should have access to the style information of a font using the py-efl function:  elementary.font_properties_get. After all enventor does the same thing using the c function: elm_font_properties_get. In a perfect world the python version of the function would function exactly like the C version. 
 
Well no such luck :(  A little testing and all attempts to use  efl.elementary.font_properties_get() resulted in an error similar to one below:
 
 

Traceback (most recent call last):
  File "efl/evas/efl.evas_object_smart.pxi", line 446, in efl.evas._smart_callback (efl/evas/efl.evas.c:78724)
  File "font.py", line 164, in font_demo_set
    print elementary.font_properties_get("Liberation Sans Narrow:style=Bold Italic")
  File "efl/elementary/__init__.pyx", line 1037, in efl.elementary.__init__.font_properties_get (efl/elementary/__init__.c:17689)
TypeError: efl.elementary.__init__.FontProperties.__new__(): not enough arguments

This led naturally to me looking thru the Source code for py-efl itself. Didn't help much probably because I am not that familiar with the cython stuff that implements py-efl. So I rewrote my tests in C and low and behold it worked fine. The mystery deepens and a couple of hours had passed completely unproductive. Now I usually am not the sort to ask anyone  for help but considering I do know Kai Huuhko pretty well and he works on py-efl and is a Bodhi team member I ask him on FB about how to use this function. After explaining the error and what I was attempting to do, his response:
 
 

Oh there's a bug there
Should have the object type as arg for __new__
...
I'd better get a working env setup then so I can fix it :)
...
Yeah it didn't have tests written for it and no one needed it, so it's been just sitting there for years with that issue you just found

 
And fix it he did, in of course py-efl git. I suppose it pays to have friends that are e-devs. Much thanks Kai :D
 
Now this explains my difficulty three or four years ago getting a py-efl font-selection dialog implemented and may in fact be one of the reasons  tbradbeer gave up work on eText.
 
But nonetheless this led to my next problem I had to compile and install EFL from git and py-efl also from git to test Kai's fix. Fortunately I keep some VMs around for such tasks and have one with Bodhi4.x installed, moksha stripped out and EFL and e21 compiled from git already created. I fired it up and installed the latest py-efl and in my brief test it seems efl.elementary.font_properties_get functioned correctly. 
 
After testing the font_properties function I decide to go ahead and create the Docs for py-efl as I had already went thru the build process and assuming i have the needed packages installed it should  be a simple:
 

python setup.py build_doc

Plus I like having the docs around as it is a fairly common occurrence for the enlightenment documentation online to be down. Of course the documentation is in the source files BUT that is not nearly as nice as having it in HTML or similar format.
 
Well the documentation built but sadly it lacked the inheritance and other diagrams, wtf :( 
 
So I re-examined the dependencies needed and took another look the at the README and INSTALL files in py-efl to no avail. Googled the issue again with no results. 
 
Now for the record and for the google juice this problem had became the fact the python-efl documents fail to build correctly on bodhi 4.x so we may as well say python-efl documents fail to build correctly on Ubuntu 16.04,  xenial.

 

bodhi@bodhi-VirtualBox:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Bodhi Linux
Release: 16.04
Codename: xenial

All needed packages seem installed:
 
 

bodhi@bodhi-VirtualBox:~$ dpkg -l | grep graphviz
ii  graphviz                            2.38.0-12ubuntu2.1                       i386         rich set of graph drawing tools
ii  libgv-python                        2.38.0-12ubuntu2.1                       i386         Python bindings for graphviz
ii  python-pygraphviz                   1.3.1-0ubuntu2                           i386         Python interface to the Graphviz graph layout and visualization package

Note one thing this is a 386 virtual image that is is to say I installed 32 bit Bodhi/ubuntu in my Virtual machine.
 
So after more research I end up taking a look at the python-efl/doc/config.py file, since I read:
 
 

Besides using raster images (PNG, JPG, etc.), diagrams can be included with the `sphinx.ext.graphviz`_ extension.
 
Graphviz_ is an open source graph visualisation software. Graph visualisation is a way of representing structural information as diagrams of abstract graphs and networks.
 
It must be installed before the extension can be used.
 
Including the extension in the project configuration file
The Graphviz extension is included with Sphinx, but the extension must be enabled in the conf.py file:

 

In said file I find the code:
 

# -- Inheritance Diagram ------------------------------------------------------


try:
    import gv
except ImportError:
    pass
else:
    extensions.append('sphinx.ext.inheritance_diagram')

 
Hmm inheritance diagrams will not be created if python is unable to import the gv module. Maybe that is the problem so i opened a terminal and :
 
 

bodhi@bodhi-VirtualBox:~$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gv
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/dist-packages/gv.py", line 28, in <module>
    _gv = swig_import_helper()
  File "/usr/lib/python2.7/dist-packages/gv.py", line 20, in swig_import_helper
    import _gv
ImportError: No module named _gv

 Yep module gv fails to load even tho libgv-python SHOULD install it: No module named _gv.

 

 Further examination reveals:
 
 

bodhi@bodhi-VirtualBox:~$ dpkg-query -L libgv-python 
/.
/usr
/usr/lib
/usr/lib/python2.7
/usr/lib/python2.7/dist-packages
/usr/lib/python2.7/dist-packages/gv.py
/usr/lib/python2.7/dist-packages/libgv_python27.i386-linux-gnu.so
/usr/share
/usr/share/doc
/usr/share/doc/libgv-python
/usr/share/doc/libgv-python/copyright
/usr/share/man
/usr/share/man/man3
/usr/share/man/man3/gv.3python.gz
/usr/lib/python2.7/dist-packages/_gv.i686-linux-gnu.so
/usr/share/doc/libgv-python/changelog.Debian.gz

Now I have no idea what you gather from that but after a few moments of looking at it it looked fishy to me. Notice libgv_python27.i386-linux-gnu.so and _gv.i686-linux-gnu.so. Why the mismatch and why does it seem I have a 686 file stuck in here. As noted above this is a 32 bit install. Another WTF moment.
 
Indeed _gv.i686-linux-gnu.so is a link to a non-existent file :(
 
 

bodhi@bodhi-VirtualBox:~$ cd /usr/lib/python2.7/dist-packages/
bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ ls -l *gv*so
lrwxrwxrwx 1 root root    32 Jan  5 16:17 _gv.i686-linux-gnu.so -> libgv_python27.i686-linux-gnu.so
-rw-r--r-- 1 root root 93880 Jan  5 16:17 libgv_python27.i386-linux-gnu.so
bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ 

 

Shown perhaps more clearly in pcmanfm:
 

8cqcaOJ.png


Well fortunately, this is not the first time I have saw broken links or problems like this. To fix the issue:
 

bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ sudo ln -s libgv_python27.i386-linux-gnu.so _gv.i386-linux-gnu.so 
 

And verification:
 

bodhi@bodhi-VirtualBox:/usr/lib/python2.7/dist-packages$ python
Python 2.7.12 (default, Nov 19 2016, 06:48:10) 
[GCC 5.4.0 20160609] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import gv
>>> 

Now cding to the right location and:
 

python setup.py build_doc

Works as expected and builds the documents complete with diagrams :D
 
NZryhQZ.png

 
 
It should be noted about half way thru this meandering debugging I finally had enough to google and found that this issue with building python-efl docs is the 386 version of a reported Ubuntu/Launchpad bug: libgv-python: wrong symlink from _gv.x86_64-linux-gnu.so.
 
Sounds simple enough and after the fact it usually does but this tale illustrates what i mean by yak shaving as well as why seemingly simple things seem to take so long for me. Now gotta get back to my font selection dialog which is what brought all this up in the first place  B)  B)

 

EDIT:

 

For the record I have reported this issue upstream: LP: 1678532


"No technology can ever be too arcane or complicated for the black t-shirt crowd."




A big thank you to everyone who contributes to Bodhi Linux


#2 ylee

ylee

    King of the Software Page

  • Moderators
  • 1583 posts
  • LocationSouth Carolina, USA

Posted 03 April 2017 - 02:15 PM

The rant above was inspired by my recent work in continuing an old abandoned EFL programming project, namely trying to implement a Font Selection Dialog in python-efl. So this is just an update, my first fully functional py-efl Font Selection demo program beta version 1 (lol):

 

c5iwx6P.png


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#3 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4608 posts
  • LocationZeist, The Netherlands

Posted 03 April 2017 - 03:03 PM

Looks good, even including previews. Kudos.

 

Any ideas about getting a wordwrap function done in Epad?

 

Enjoy,

Charles



#4 ylee

ylee

    King of the Software Page

  • Moderators
  • 1583 posts
  • LocationSouth Carolina, USA

Posted 03 April 2017 - 03:18 PM

Looks good, even including previews. Kudos.

 

Any ideas about getting a wordwrap function done in Epad?

 

Enjoy,

Charles

 

Thanks Charles :D

 

Word wrap I had implemented once in ePad. Jeff broke it with the way he implemented line numbers. It was either removed or commented out, forget which and too lazy to look. Anyways it was hard to add back and preserve his line number feature so I sorta left it at that.

 

I haven't forgot about it tho. And I am pretty sure I know how to do it in C but had issues trying to implement in python-efl. Doing it in C requires low level access to efl-evas textblock in  the entry. Something I never figured out how to do in python and may not be possible. Low level access to stuff is not what python usually allows. But I need to re-examine it, things may have changed, I may be able to find another way, I may have been mistaken back then, py-efl may be able to be patched to allow such a thing, and so on.

 

But i agree, ePad needs word wrap, the font selection dialog above as well as a preference dialog implemented to be fully functional. And perhaps some way to deal with its slow load speed. Anyways hopefully I will get around to it  B)  B)


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#5 DOOMguy

DOOMguy

    Member

  • Members
  • 234 posts

Posted 05 April 2017 - 11:55 PM

Font selection looks sweet especially after all the hard work. Only one question remains: Ylee, when are we going to drop the word "beta" and simply call it version 1?


Unsolicited advice for learning linux, that won't cost you anything


#6 ylee

ylee

    King of the Software Page

  • Moderators
  • 1583 posts
  • LocationSouth Carolina, USA

Posted 06 April 2017 - 10:40 AM

Font selection looks sweet especially after all the hard work. Only one question remains: Ylee, when are we going to drop the word "beta" and simply call it version 1?

 

Much thanks for the kudos DOOMguy :D

 

While I have a degree in computer science and have coded all my adult life, in reality I am a brick mason and as a mason I have to say there is nothing at all hard or difficult about programming. Frustrating sometimes certainly, time consuming yes. Hard ... hard is when you work in mud up to your knees and move over 25 tons of concrete block as fast as possible, it is not sitting in an air conditioned room, typing googling and thinking. lol

 

Anyway, my attention right now is jumping back and forth between several things I think I need to implement, learn or do. So beta will be dropped from the font selection dialog once I solve a couple more outstanding issues to my satisfaction. One being the 'proper' and easiest way to determine what font is used in an elm-entry from the elementary theme in use ( In python-efl, straight C code offers several ways of doing so not available in py-efl as far as I can tell). Another being trying to decide what to do about font families: The gtk Font selection dialog will display Sans and Serif for example in the list of fonts, these are not really fonts but font families so do not show up in my py-efl dialog (nor in enventers) and what font is displayed when a user selects say Sans will depend upon how the user has fontconfig set up. This is a design question for me more than a coding problem. Should I include Sans and Serif family in the font list or ignore it? If I do how about Cursive or other possible families? If I do decide to include it is it relevant to non-latin non-english users? Speaking only english and using only english locales I'm completely clueless about the latter.

 

There is also one or two other minor design choices I need to decide upon ... nor really worth going into here. 

 

So lets assume I decide on all the above solve what remaining issues my OCD nature is focusing on currently and add this code to to ePad (its intended usage). Then I will remove Beta from its description once enough users have tested it with a variety of fonts, locales, config options and whatnot that I feel fairly confident that it works at least as reliably as EFL itself.

 

Depending on my motivation and time availability it should be added to ePad within a week or two. Maybe sooner but I can't promise that and it seems unlikely thinking about my RW concerns ...

 

One more thing than should be noted updating epad in bodhis repos to include this font selection dialog is not as simple as simply updating the epad deb file. Python-efl deb files both 386 and 686 have to be rebuilt with Kai's patch added to py efl (see my first post here). Maybe also py3-efl debs file too. That in itself is time consuming busy work altho not really hard to do ...


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#7 Jeff

Jeff

    Lead Developer

  • Developer
  • 12517 posts
  • LocationBloomington, IL

Posted 07 April 2017 - 06:30 PM

Something I intended to do but never got around to was making it so when you toggled word wrap on it simply turned line numbering off. 






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users