Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #701 Erik Slagter

  • PLi® Core member
  • 46,957 posts

+541
Excellent

Posted 8 December 2014 - 12:42

An alternative solution might be to stage the dvb headers from the kernel, instead of using the linux-libc-headers.

That sounds to me as an excellent idea. I never understood why one would want to duplicate kernel headers into libc so that they don't match the current kernel (unless maybe you want to compile for an older kernel, which in this case, imho, is irrelevant).


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #702 athoik

  • PLi® Core member
  • 8,458 posts

+327
Excellent

Posted 8 December 2014 - 12:46

Is there a runtime check to get DVB_API_VERSION ?
 
Here they mention the following:

 

If you use newer kernel should work ok why is that a problem ? kernel
syscalls are backward compatible
and we use oldest kernel version of like 2.6.16 for eglibc to build
against so it should not be a problem
to use different versions for kernel and kernel-headers. I think your
problem lies elsewhere

Wavefield T90: 0.8W - 1.9E - 4.8E - 13E - 16E - 19.2E - 23.5E - 26E - 33E - 39E - 42E - 45E on EMP Centauri DiseqC 16/1
Unamed: 13E Quattro - 9E Quattro on IKUSI MS-0916

Re: merge requests for PLi's git #703 MiLo

  • PLi® Core member
  • 14,045 posts

+298
Excellent

Posted 3 January 2015 - 10:02

All boxes share the same libraries, so everything must be compiled against the same kernel headers, regardless of the actual kernel used.

You'll have to use runtime checks for everything that may be kernel dependent. Compile-time checks on kernel features will not work.

We've been doing this in the wrong way since the beginning, that's why we got away with it so long.
Real musicians never die - they just decompose

Re: merge requests for PLi's git #704 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 19 February 2015 - 15:06

Found issue in Input.py:

--- a/lib/python/Components/Input.py
+++ b/lib/python/Components/Input.py
@@ -62,7 +62,7 @@ class Input(VariableText, HTMLComponent, GUIComponent, NumericalTextInput):
                        self.currPos = 0
                        self.Text = u""
                else:
-                       self.Text = text.decode("utf-8", "ignore").decode("utf-8")
+                       self.Text = text.decode("utf-8", "ignore").encode("utf-8")
                self.update()
 
        def getText(self):

Attached Files


Edited by mx3L, 19 February 2015 - 15:06.


Re: merge requests for PLi's git #705 littlesat

  • PLi® Core member
  • 56,272 posts

+691
Excellent

Posted 19 February 2015 - 15:10

Pushed

 0001-Input-fixed-typo-don-t-decode-unicode-but-encode-it.patch   


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #706 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 19 February 2015 - 15:15

Thanks!



Re: merge requests for PLi's git #707 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 20 February 2015 - 05:12

It looks like the same problem is also in insertChar. You may want to amend the patch.

Edited by peteru, 20 February 2015 - 05:13.

"Beauty lies in the hands of the beer holder."

 


Re: merge requests for PLi's git #708 Erik Slagter

  • PLi® Core member
  • 46,957 posts

+541
Excellent

Posted 20 February 2015 - 12:03

Commits cannot be ammend once they're pushed. But it's no problem to make a new commit.


* Wavefrontier T90 with 28E/23E/19E/13E via SCR switches 2 x 2 x 6 user bands
I don't read PM -> if you have something to ask or to report, do it in the forum so others can benefit. I don't take freelance jobs.
Ik lees geen PM -> als je iets te vragen of te melden hebt, doe het op het forum, zodat anderen er ook wat aan hebben.


Re: merge requests for PLi's git #709 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 21 February 2015 - 18:10

After the decode("utf-8") was changed to encode('utf-8') I have a problem with the bouquet name editing if the name is with cyrillic characters.
If I trying to do this, then I have gsod:

File "/usr/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 323, in okClicked
    self["text"].deleteBackward()
  File "/usr/lib/enigma2/python/Components/Input.py", line 217, in deleteBackward
    self.update()
  File "/usr/lib/enigma2/python/Components/Input.py", line 58, in update
    self.text = self.Text.encode("utf-8") + " "
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xd0 in position 14: invalid continuation byte
(PyObject_CallObject(<bound method NumberActionMap.action of <Components.ActionMap.NumberActionMap instance at 0x2cd818cc>>,('OkCancelActions', 'ok')) failed)

I do not have original openpli image, but I think that on it is exactly the same problem.
Try create test bouquet, change the virtual keyboard layout to RU, and rename or delete any of the symbol.
If I simply remove encode('utf-8') then everything works without problems.


Edited by Taapat, 21 February 2015 - 18:12.


Re: merge requests for PLi's git #710 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 21 February 2015 - 18:20

I can confirm it. For lat2 is GSOD too.

 

There must be .decode("utf-8") for input nat. chars ! Why encode for input ? See http://sourceforge.n...dfeb9d45d3d4eb/

 

Please - revert it.

 

 

@mx3L - where you had problem, that you needed change it ?


Edited by ims, 21 February 2015 - 22:48.

Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #711 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 21 February 2015 - 23:29

I'm passing utf-8 encoded string as text to VirtualKeyboard

Screen <class 'Screens.VirtualKeyBoard.VirtualKeyBoard'>(('Editova\xc5\xa5 n\xc3\xa1zov s\xc3\xbaboru',), {'text': 'HDTV by Lidu\xc5\xa1ka(Broadchurch.S02E04.HDTV'}): <type 'exceptions.UnicodeEncodeError'>
Traceback (most recent call last):
  File "/usr/local/e2/lib/enigma2/python/mytest.py", line 226, in create
    return screen(self, *arguments, **kwargs)
  File "/usr/local/e2/lib/enigma2/python/Screens/VirtualKeyBoard.py", line 74, in __init__
    self["text"] = Input(currPos=len(kwargs.get("text", "").decode("utf-8",'ignore')), allMarked=False, **kwargs)
  File "/usr/local/e2/lib/enigma2/python/Components/Input.py", line 25, in __init__
    self.setText(text)
  File "/usr/local/e2/lib/enigma2/python/Components/Input.py", line 65, in setText
    self.Text = text.decode("utf-8", "ignore").decode("utf-8")
  File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
    return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\u0161' in position 12: ordinal not in range(128)
Traceback (most recent call last):
  File "/usr/local/e2/lib/enigma2/python/Components/ActionMap.py", line 46, in action
    res = self.actions[action]()
  File "/usr/local/e2/lib/enigma2/python/Plugins/Extensions/SubsSupport/subtitles.py", line 3760, in editFName
    self.session.openWithCallback(editFnameCB, VirtualKeyBoard, _("Edit Filename"), text= toString(self["fname"].text.strip()))
  File "/usr/local/e2/lib/enigma2/python/mytest.py", line 294, in openWithCallback
    dlg = self.open(screen, *arguments, **kwargs)
  File "/usr/local/e2/lib/enigma2/python/mytest.py", line 305, in open
    dlg.isTmp = True
AttributeError: 'NoneType' object has no attribute 'isTmp'

Sorry guys, you're right, self.Text has to be unicode, and self.text utf-8 encoded string.

This should be alright... please check

diff --git a/lib/python/Components/Input.py b/lib/python/Components/Input.py
index 680e95d..a1afe33 100644
--- a/lib/python/Components/Input.py
+++ b/lib/python/Components/Input.py
@@ -62,7 +62,7 @@ class Input(VariableText, HTMLComponent, GUIComponent, NumericalTextInput):
                        self.currPos = 0
                        self.Text = u""
                else:
-                       self.Text = text.decode("utf-8", "ignore").decode("utf-8")
+                       self.Text = text.decode("utf-8", "ignore")
                self.update()
 
        def getText(self):
@@ -152,7 +152,7 @@ class Input(VariableText, HTMLComponent, GUIComponent, NumericalTextInput):
                self.update()
 
        def insertChar(self, ch, pos=False, owr=False, ins=False):
-               self.Text = self.Text.decode("utf-8", "ignore").decode("utf-8")
+               self.Text = self.Text.decode("utf-8", "ignore")
                if not pos:
                        pos = self.currPos
                if ins and not self.maxSize:



Edited by mx3L, 21 February 2015 - 23:31.


Re: merge requests for PLi's git #712 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 22 February 2015 - 00:00

it is better ;)


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #713 mx3L

  • Senior Member
  • 616 posts

+79
Good

Posted 22 February 2015 - 00:05

Good :),

probably "self.Text = self.Text.decode("utf-8", "ignore")' in insertChar should'nt be there at all since self.Text should be still unicode, so no need to decode it, but it will not raise anything since errors are ignored.



Re: merge requests for PLi's git #714 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 February 2015 - 11:47

And if we have started talk about the input, here is a patch to add Latvian layout in VirtualKeyboard.

Attached Files



Re: merge requests for PLi's git #715 littlesat

  • PLi® Core member
  • 56,272 posts

+691
Excellent

Posted 22 February 2015 - 12:56

Pushed

 

 
txt.gif  0001-Add-Latvian-layout-in-VirtualKeyBoard.patch   1.83KB   1 downloads

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #716 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 22 February 2015 - 13:22

And if we have started talk about the input, here is a patch to add Latvian layout in VirtualKeyboard.

@tappat - you can add LAT into NumericalTextInput too. See into .../tools/NumericalTextInput.py


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #717 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 February 2015 - 13:47

Pushed

Thank you!
 

@tappat - you can add LAT into NumericalTextInput too.

I think about this, but in the end decided not to do so.
In Latvian is addition "soft" letters, and therefore increases the number of characters in a one digit. It seems to me therefore that not comfortable to use NumericalTextInput, and where used only it, could by used without national symbols, but maybe I'm wrong.
I know that other languages have a lot of character, and maybe you have any argument that I'm wrong and it does not interfere input.



Re: merge requests for PLi's git #718 ims

  • PLi® Core member
  • 13,624 posts

+212
Excellent

Posted 22 February 2015 - 13:56

NumericalTextInput is same as SMS mod on GSM phone. May be, you could inspire there...


Kdo nic nedělá, nic nezkazí!

Re: merge requests for PLi's git #719 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 February 2015 - 14:13

Maybe you right. Looked to other languages, it seems that Latvian is not the worst case.

Attached Files



Re: merge requests for PLi's git #720 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 22 February 2015 - 18:13

I did not find an appropriate topic, therefore, decided to write here. I'm sorry if I had to write another place.
I see that in ServiceName been added a new option- TransponderInfo. Very well, now, to show this information will no longer be used non-standard components. 
I have three suggestions:
1. It seems that in the displayed of polarization have been forgotten about circular polarization which begins with the word "circular". The first patch fixed it.
2. I do not know what satellites.xml is in openpli feed, but I use it fromt the site http://satellites-xml.eu/ and there sat name is such as "Astra 4A / SES 5 (4.9E)", of course, that it is not properly displayed. The second patch fixed name, if in the sat name is "(".
3. I add name of the server if in the bouquet is IPTV service.


Edited by Taapat, 22 February 2015 - 18:14.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users