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 #661 SpaceRat

  • Senior Member
  • 1,030 posts

+65
Good

Posted 15 October 2014 - 23:49

"is" checks for identity and "==" for equality.
This is a huge difference.


a = "DVB-C"
b = "DVB-C"

a is b
False

a = "DVB-C"
b = a

a is b
True

"is" means that both variables reference the exactly same object.

Using "is" for equality tests might work under certain conditions, because "identify" necessarily also includes "equality", but it might as well fail if the two sides of the comparison are not created from the same object, because "equality" doesn't imply "identity".

Please avoid tests for identity if you really just mean equality!
1st box: Vu+ Ultimo 4k 4xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
2nd box: Gigablue Quad 4k 2xDVB-S2 FBC / 2xDVB-C / 1.8 TB HDD / OpenATV 6.2
testing boxes: Vu+ Duo² + AX Quadbox HD2400 + 2x Vu+ Solo² + Octagon SF4008
Sats & Pay-TV: Astra 19.2°E + Hotbird 13°E with Redlight / SCT HD / SES Astra HD- / Sky V14 / 4th empire propaganda TV
Card-Server: Raspberry Pi + IPv6-capable oscam
Router: Linksys WRT1900ACS w/ LEDE + Fritz!Box 7390

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

  • PLi® Core member
  • 57,168 posts

+698
Excellent

Posted 16 October 2014 - 06:30

I suggest it is now clarified that we should not do this.... there might be thinks out of control, like (third) party plugins that do strange thinks and than you do not have this under controll.... There is a potential risk that you need to revert this... :(


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


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

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 16 October 2014 - 22:55

This patch allow to translate word "Next" in renderer NextEpgInfo.

Attached Files



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

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 16 October 2014 - 23:35

This patch allow to translate words "Now", "Next" in converter EventName.

 

There may be a need to discuss or not to add a translation to the EPG.
This will allow to translate the notification "no description available" if the EPG is not available.

Attached Files



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

  • PLi® Core member
  • 57,168 posts

+698
Excellent

Posted 17 October 2014 - 06:42

Was pgettext not there to translate it?

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


Re: merge requests for PLi's git #666 blzr

  • PLi® Core member
  • 2,270 posts

+118
Excellent

Posted 17 October 2014 - 09:11

this 'Next' and 'Now' messages are definitely translatable as it is now...
msgctxt "now/next: 'next' event label"
msgid "Next"
msgstr "Następnie"

msgctxt "now/next: 'now' event label"
msgid "Now"
msgstr "Teraz"
@Taapat
pgettext("context", "message") is a correct syntax for multicontext strings...
True sarcasm doesn't need green font...

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

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 17 October 2014 - 15:02

Ok, sorry about this. I do not have mipsel receiver, and therefore not original openpli image.

It seems that I need to correct the work of pgettext.

And what do you think about EPG translation?



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

  • PLi® Core member
  • 14,055 posts

+298
Excellent

Posted 17 October 2014 - 18:53

Of course 'is' not the same as '==', 'is' we can use only if the parameters are identical, and not use if equal is their values.


Using "is" to compare enums, integers and strings is a horribly bad idea. Don't do it. It "happens to work" when Python is smart enough to join objects together (it does that for small integers) but it cannot be relied upon.

There is only one "None" in the system, so using "a is None" is the only safe use of "is" in this context.

Edited by MiLo, 17 October 2014 - 18:53.

Real musicians never die - they just decompose

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

  • PLi® Core member
  • 14,055 posts

+298
Excellent

Posted 17 October 2014 - 18:58

Also when it is running from pyo files, like enigma 2 does....


There is no difference in performance of a loop when running from .py, .pyc or .pyo because once the thing has been converted to bytecode, they're all the same. There's only the overhead of converting from text to code, and that's just once per module.

Python's "optimize" function is highly overrated, apart from removing some docstrings it doesn't really do anything. For historical reasons (read: Plugins) we kept using .pyo files in OpenPLi, but the rest of the embedded world has moved on and no other project really uses .pyo files any longer, they all just use .pyc only.

Edited by MiLo, 17 October 2014 - 18:58.

Real musicians never die - they just decompose

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

  • PLi® Core member
  • 57,168 posts

+698
Excellent

Posted 17 October 2014 - 19:04

OK... indeed only the conversion to bytecode could be different here... that was in fact what I meant...


Edited by littlesat, 17 October 2014 - 19:05.

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


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

  • PLi® Core member
  • 2,345 posts

+121
Excellent

Posted 17 October 2014 - 20:10

@MiLo, littlesat already said no, therefore I do not want to discuss, but if we already have it started again:
I tried to change to is only in places where, for example, compare self.type, the value of which is always small integers. Again, looking at the proposed patches, I see that I have changed too much :( . For myself I have made ​​some adjustments, but I think that the change in the places when compare self.type, and where directly compared with small integer, is to be done safely.
But I respect your opinion that stability in the first place, and if littlesat have said no, then I think the discussion is closed.


Edited by Taapat, 17 October 2014 - 20:11.


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

  • PLi® Core member
  • 14,055 posts

+298
Excellent

Posted 18 October 2014 - 18:22

If you want to seriously contribute, try to get rid of the enumerations. Enumerations don't exist in Python for a good reason: You don't need them. They can usually be replaced with method names, dictionaries and similar constructs (looking up a name in a dictionary costs the same as looking up an enumeration value). The enums in Enigma2 are mostly the result of a C programmer trying to write Python code.


Real musicians never die - they just decompose

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

  • Senior Member
  • 36 posts

+5
Neutral

Posted 3 November 2014 - 12:09

I forked gst-plugin-dvbmediasink on sf.net (the repo is at https://sourceforge..../beyonwiz/tree/ ) and submitted a pull/merge request using the standard sf.net git workflow. I'm not sure if that is the standard process for your development workflow, but the development information on the openpli.org wiki is sketchy at best and I could not find a relevant post in the forums in a reasonable amount of time.

 

The changes are pretty minimal and split up into 7 fairly clean commits. I'm happy to discuss the changes if you need clarification, either using the sf.net collaboration tools, or these forums.

 

Cheers,

 

Peter


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

 


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

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 3 November 2014 - 15:20

Contributions are always valued :)

 

Please, to start with, describe the exact goal of each patch, in a later stage we can discuss the implementation.


* 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 #675 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 6 November 2014 - 05:38

Sorry to take a while to respond - I've been flat out. This is the information from the pull request:
 


This is a whole series of patches that fixes various issues I encountered as I was improving media playback compatibility for Beyonwiz T3 hardware. Changes include:
* fix a typo in video/x-msmpeg capabilities
* add m4 macro directory to keep new versions of autotools happy
* convert (some) magic numbers/constants to enums
* improved handling of codec_type
* made stream type a member variable in anticipation of further changes.

And here's the git log:
 
* 1e05dd9
  Ensure that codec_type is set correctly in all cases.

* efd388b
  Ensure that stream type is initialised correctly.

* c5afbc1
  Print caps to aid in troubleshooting.

* 6d69483
  Convert audio bypass constants/magic numbers to an AUDIOTYPE enum.

* 92dbf91
  Make stream type a member variable and use an enum type with symbolic
  names.

* bfcfd5c
  configure: Add missing m4 macro dir.

* 928e7e6
  Fix a typo in msmpegversion caps.

Edited by peteru, 6 November 2014 - 05:39.

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

 


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

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 6 November 2014 - 09:41

Ok on the queue for review... Please comments.


* 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 #677 peteru

  • Senior Member
  • 36 posts

+5
Neutral

Posted 16 November 2014 - 07:25

Is there anything else I need to do to get changes other than 928e7e6 merged?

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

 


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

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 18 November 2014 - 13:04

Sorry, it appeared to have slipped through.

 

Some of the patches I can apply without seemingly impact, some of them I (and others) will have to take a closer look at.


* 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 #679 Erik Slagter

  • PLi® Core member
  • 46,969 posts

+542
Excellent

Posted 20 November 2014 - 12:06

* 1e05dd9 Ensure that codec_type is set correctly in all cases. Applied to master
* efd388b Ensure that stream type is initialised correctly. Applied to master
* c5afbc1 Print caps to aid in troubleshooting. Applied to master
* 6d69483 Convert audio bypass constants/magic numbers to an AUDIOTYPE enum. Applied to master
* 92dbf91 Make stream type a member variable and use an enum type with symbolic names. Applied to master
* bfcfd5c configure: Add missing m4 macro dir. Applied to master
* 928e7e6 Fix a typo in msmpegversion caps. Applied (previously)

 

It would be very much appreciated if you would add patches to the gst-1.0 branch as well. Some of them don't apply cleanly.


* 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 #680 herpoi

  • Member
  • 15 posts

+1
Neutral

Posted 30 November 2014 - 21:43

This patch add picon widget to NumberZap Screen.

Attached Files


Edited by herpoi, 30 November 2014 - 21:44.



2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users