592 replies to this topic

[littlesat]

Yep indeed… but not a real added value. More a work-a-round other images make…

[Frenske]

Just to be clear...

 

In other images (not PLi) if you make a backup of slot 0, you can back up all slots on block so when restored all slots are restored.

 

I assume in this case you are referring to a full backup of the image in slot 0. Is my assumption correct?

In my opinion this isn’t really useful as I wanted to flash another OpenPLi image in slot 0. Now I have a homebuild in slot 0 and would like to have an original NB in slot 0.

In that case it doesn’t offer a simple solution to place another image in slot 0. At the moment I even can’t flash a ‘new’ image other then via USB and next I must reinstall all Multiboot images. 

[littlesat]

There is still actually a lack of a recovery image…. A full backup of slot 0 with all the others included what other images do is actually a work-a-round and therefore the vuplus multiboot is still sub-optimal. But we are aware of it and as long nobody will make a mini recovery image than this will be the fact.

 

I just committed an image branding selection in FlashImage while keeping the alternate image as it always was…. But on the h7 box I do not get many from the feeds…

[littlesat]

Why

with open("/STARTUP", 'w') as f:  
f.write(self.STARTUP)

as 

open(“/STARTUP”, ‘w’).write(self.STARTUP)

does the same job?

 

and in kexecinit we have an if box x then y that needs to be relocated to SystemInfo.py…. Maybe via the existing key

Edited by littlesat, 29 April 2023 - 16:10.

[Huevos]

Why

with open("/STARTUP", 'w') as f:  
f.write(self.STARTUP)

as 

open(“/STARTUP”, ‘w’).write(self.STARTUP)

does the same job?

No.

>>> x = open("/etc/enigma2/settings")
>>> dir(x)
['_CHUNK_SIZE', '__class__', '__del__', '__delattr__', '__dict__', '__dir__', '__doc__', '__enter__', '__eq__', '__exit__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__lt__', '__ne__', '__new__', '__next__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '_checkClosed', '_checkReadable', '_checkSeekable', '_checkWritable', '_finalizing', 'buffer', 'close', 'closed', 'detach', 'encoding', 'errors', 'fileno', 'flush', 'isatty', 'line_buffering', 'mode', 'name', 'newlines', 'read', 'readable', 'readline', 'readlines', 'reconfigure', 'seek', 'seekable', 'tell', 'truncate', 'writable', 'write', 'write_through', 'writelines']
>>>

Using the "with" statement ensures that both __enter__() and __exit__() are called.

[littlesat]

As far I know it does exactly the same… the file is created. Your example give an x that says active. I do not do the x= your example is not a valid argument here. There the file stays open until you do x.close(). My example the file is directly closed so exactly the same.

Edited by littlesat, 29 April 2023 - 22:50.

[Huevos]

You really should read PEP343 written Guido van Rossum, the creator of python, in 2005.

Edited by Huevos, 29 April 2023 - 23:16.

[scriptmelvin †]

My example the file is directly closed so exactly the same.

But this is up to the implementation. In CPython (the one PLi uses) the file is indeed closed when its refcount drops to zero, but no guarantees in other implementations. Using context manager (with keyword) guarantees that the file closes after the with block in any implementation, even when an exception is raised.

[littlesat]

As far I can see PEP343 is not relevant here as I except no exceptions here and even with an exception the file will be closed as far I know. But a good discussion. There is no ‘input’ that is handled that could cause an exception. A write is also not included in the examples as far I can see. In what other environment can this go wrong because when this is the case we should consider to redo it on other places. I see a lot of other images that open the file, write and then close in three rows. For me this oneline I also learned more the 10 years ago that it was the right way to do and should always work in all conditions was right. The PEP is just about the when the with command was introduced in 2005 with some examples of opening files and processing them as input

For enigma2 it seems to be fine but when there is indeed a risk this could be wrong then we have more places to adapt.

Edited by littlesat, 30 April 2023 - 08:09.

[rantanplan]

https://forums.openp...dpost&p=1536472

[littlesat]

Looks like a self. is forgotten…. Multiple times

Edited by littlesat, 30 April 2023 - 21:21.

[scriptmelvin †]

As far I can see PEP343 is not relevant here as I except no exceptions here and even with an exception the file will be closed as far I know. But a good discussion. There is no ‘input’ that is handled that could cause an exception. A write is also not included in the examples as far I can see. In what other environment can this go wrong because when this is the case we should consider to redo it on other places. I see a lot of other images that open the file, write and then close in three rows. For me this oneline I also learned more the 10 years ago that it was the right way to do and should always work in all conditions was right. The PEP is just about the when the with command was introduced in 2005 with some examples of opening files and processing them as input

For enigma2 it seems to be fine but when there is indeed a risk this could be wrong then we have more places to adapt.

 

I think it should be fine. The one-liner open(...).write(...) is used all over the place (over a 100 times), and in CPython it works fine. And it was all we had before context manager was introduced.

[Huevos]

 

As far I can see PEP343 is not relevant here as I except no exceptions here and even with an exception the file will be closed as far I know. But a good discussion. There is no ‘input’ that is handled that could cause an exception. A write is also not included in the examples as far I can see. In what other environment can this go wrong because when this is the case we should consider to redo it on other places. I see a lot of other images that open the file, write and then close in three rows. For me this oneline I also learned more the 10 years ago that it was the right way to do and should always work in all conditions was right. The PEP is just about the when the with command was introduced in 2005 with some examples of opening files and processing them as input

For enigma2 it seems to be fine but when there is indeed a risk this could be wrong then we have more places to adapt.

 

I think it should be fine. The one-liner open(...).write(...) is used all over the place (over a 100 times), and in CPython it works fine. And it was all we had before context manager was introduced.

 

That is fine if you want to run a pattern that was replaced 18 years ago, but doesn't mean it is better because "this is what we have always used". TBH, I can't believe this has been brought up as "wrong". If PLi team doesn't like this please change, but there is nothing wrong with the original.

[littlesat]

I still think the PEP is not related here. What I'm more interesting about is that in CPython it works fine. In what does it not work fine? And is this a good reason/risk that we need to change it.

[rantanplan]

Because you will be asked about it...
Backport of the multiboot in 8.3 is still being considered, isn't it?

[rantanplan]

https://forums.openp...-3#entry1541495

 

Here a very experienced and technically skilled user reports about problems regarding the new 'Kexec-Multiboot'!
This user is certainly far superior to me and many others here of Linux and also e2 knowledge.

Why not address that now?

The problems described are independent of the image in the boot area.
It was Pli in the R range and vice versa also an ATV.

I ask again as not the owner of such a box.
VU+ images were previously fine.
The users had little or no interest in a multiboot solution.
Neutrino has had a multiboot solution since 2019.
This solution is open and clearly recognizable to everyone as a real flash partition multiboot.

If a problem is now presented loud and clear, why not immediately take it seriously as a warning?

The many questions about using the new Kexec Multiboot have still not been described.
The hint to leave the (R-Image) as untouched as possible is still missing.

I think all this is very unfortunate for the users of the VU+ boxes.

 

Also for developers who test images, a multiboot that cannot be relied on becomes a problem.
The question is :
Can you rely on it?
Why do the blue images coming from the 'pre-kernel' appear?
 

[littlesat]

The dark blue images is what I expected to happen. The implementations misses a real recovery system as the recovery is the image in slot 0. Actually where you got the dark blue screen there belongs the recovery stuff, the way to select a slot etc…
With keeping the limitations in mind the multiboot is working fine here… but I agree someone needs to find time to fix it or indeed another solution could be tried.

Edited by littlesat, 20 May 2023 - 07:50.

[Dimitrij]

rantanplan

What exactly are the problems?

Can you give me the exact link.

[littlesat]

That user at the link does indeed not exactly give the issues. But I can tell you that the image in slot 0 for example can break things.

[Dimitrij]

 

But I can tell you that the image in slot 0 for example can break things.

I noticed this, for example:

VU+ DUO4K display not working