312 replies to this topic

[littlesat]

And it is still slightly wrong... Now when there is no '+' we always have a space.... I thing "%s%d" iso "%s %d" should do it...

 

[resolved]

Edited by littlesat, 15 December 2023 - 14:38.

[littlesat]

+1...

 

Always you should strive to avoid warnings... they are a warning that it can go wrong... and you never want to have things in code that can behave unpredicted...

No, you should look at it the other way around.

[DimitarCC]

 

 

he problem is that %d comes from localized text in m_text_time -> Simply do not do that as simply the compiler cannot now the content... ERROR is what it should give here... Sounds like VIX (or oe-a) played with the compiler so such things are allowed... This is also not 'structured' programming as in c++ you cannot see what is really happening.... I know this is a pain.... Better keep the %d visible in cpp.. makes readable code and only translate the text... b.t.w. this field is even new...

 

At least we understand how to fix this and I know in python you do not see the %d then for the translation... When we want to have it still there then indeed we need to strip it off but we can than (later) if it is kept decide were it may appear in the text...

 

Unless this I think it is valid this is an ERROR and not a warning... because in the string the %d is not guaranteed there... and the compiler does really not know what is inside that string... What should it do if the %d is really not there? I think it is a 'wonder' that VIX does compile it... or give just a warning. 

 

I checked the rest of the code when this is resolved then as far I can see it can be merged...

 

Default c++ behavior in c++11 is that to be a warning not error. You (PLi) has played with the compiler to make all warnings errors. This is not the default behavior for sure.

 

If you make that error in that particular case you limit the functionality of c++ without obvious reason imho. You can not construct dynamic format strings just because of that. That is not right.

 

Anyway i fixed the code for PLi, But that not means that is right....

 

No, you should look at it the other way around.

We compile with a more recent version and would fool the system using the c11 flag.
This is done to keep something running, because it's too convenient to fix the errors that are in c17.
I really don't know much about programming languages, but something like this should be obvious to everyone.

Either you compile with the old compiler version c11 (i.e. gcc4) or you also repair errors.
 

 

 

And that is the point....It is not error in normal c++ no matter the version of the compiler. You made it as error. So generally nothing to fix. And how you can form dynamic format strings? This is available in all programming languages that i know. And in no one of them it complains about that. And you prevent it....It doesnt seems right. Anyway its not importnat anymore...

I would not do it in the way you did it...But its not my call...

Edited by DimitarCC, 15 December 2023 - 14:53.

[DimitarCC]

And it is still slightly wrong... Now when there is no '+' we always have a space.... I thing "%s%d" iso "%s %d" should do it...

 

[resolved]

 

OK. But that space doesnt really matter since the text is right aligned always...But you fixed it so OK.

[littlesat]

Yep...

And maybe also consider to do the same for ViX... I know the chance is small that it could go wrong as it is called in cpp with the %d in the string... but you never know what happens in the future...

I agree with you that it is helpfull to have the %d in python in case there is a language that writes the min behind the text or somewhere in between... but bringing the code from python to cpp has his limitations here.... (I also hate this of course). And warnings are also a red flag for me... and when it is an error then it is mandatory to work-a-round it...

 

And I'm sure we have still a number of warnings in openPLi that need attention,  but we at least should avoid adding new onces and especially not add some on purpose...

Edited by littlesat, 15 December 2023 - 14:55.

[rantanplan]

And how you can form dynamic format strings? This is available in all programming languages that i know. And in no one of them it complains about that. And you prevent it....It doesnt seems right. Anyway its not importnat anymore...

I would not do it in the way you did it...But its not my call...

 

The point here is to make it clear that 'warnings' were not declared 'errors' during compiler development for nothing.
Of course, this could be used as a warning using a trick.
There is still an error that is only covered up here.
The fact that the compilation then runs successfully does not alleviate the problem.

Unfortunately, the warnings are simply ignored far too often, as you can see here in the course of the discussion.
It gives the impression that warnings are not a problem.
This is too short-sighted and will lead to unusual problems that no one can understand.
The approach of only updating the compiler version and then covering up the problems declared as bugs within these updated versions is a wrong path.
Then it's really better to continue working with the old compiler.

(googleTranslate)

 

[DimitarCC]

And still...what problem is possibility to define dynamic format strings from variable? This is a feature not a problem. So for that particular case i think that forcing to prevent/exclude that feature is wrong.

 

In other case i could agree, but not for that particular one.

[littlesat]

I agree that wat you want to do is a nice feature. But the compiler gives in the way it was implemented a warning. So it should be done differently... The compiler cannot know what in python is forwarded there to the c++ code.

 

I have no idea if the compiler is smart enough when you check for the %d being in the string might also be sufficient.

Edited by littlesat, 15 December 2023 - 16:02.

[DimitarCC]

unfortunately compiler wants now format string to be literal something between "....". Any try to use variable in it will fail like this.

I know it is made as a warning so to notify the developer that it can not check for correct format string when it is a variable.

But on purpose is not made error initially since if the developer pass the correct code you can use this feature of c++.

 

Anyway its done now differently. So lets move further.

Edited by DimitarCC, 15 December 2023 - 16:08.

[littlesat]

Anyway its done now differently. So lets move further.

 

I agree....

Edited by littlesat, 15 December 2023 - 16:12.

[Dimitrij]

Maybe it’s worth making a separate menu for setting the services list?

 

[littlesat]

I would say do a suggestion…

[Huevos]

I think you are confused between errors and warnings.

 

A compiler error is when your program is wrong, and the compiler has no idea how to produce runnable code from it.

 

A compiler warning is where the compiler can't guarantee your code will run, even though the code is valid.

 

Certain code syntax will always cause warnings because "the compiler can't guarantee your code will run", e.g. dynamic values.

 

If you promote those warnings to errors you make it impossible to compile valid code.

Edited by Huevos, 15 December 2023 - 20:03.

[Huevos]

 

Maybe it’s worth making a separate menu for setting the services list?

 

 

Yes and accessible from ChannelSelection screen from the context menu. Same with MovieSelection. And no idea why your EPG setup is missing from setup.xml.

[littlesat]

…

Edited by littlesat, 15 December 2023 - 21:13.

[Dimitrij]

[UsageConfig] not update refreshServiceList many times if init

[WanWizard]

OE-A was always master in adding configs instead of trying to avoid them as much as possible.. (LOL)

 

Afaik you are the only one allergic to config items. I don't have a problem with them, providing they have a sensible default.

 

And it would be improved for users if we reorganize the current menu mess, where there seems to have been a contest on who could cram the most random config values into one screen...

[littlesat]

It was not only me… also pieterg that time prefered to avoid them. Every thing that can be tweaked needs continuously support and makes the stuff complicated and promotes spaghetti code. All the config stuff in the channel selection is a classic example of it.
But at the end for those who want to tweak… at enigma2’it is possible…

In the skin the menu has a limit width and there are items in Dutch language that do not fit. Maybe the translation could be adapted…

Edited by littlesat, 16 December 2023 - 14:41.

[Pr2]

You cannot adapt a translation to a particular skin! This will make no sense to have a lot of abbreviation when skin provide enough room. It is the skin that needs to adapt to text and not the opposite.

Some languages are more verbose than others and it's skins that have to deal with it.

[littlesat]

It is always smart trying to translate as compact as possible…