Important software compatibility notice
|
I’ll see what can be done :) |
|
Excellent news. |
|
Jon: as a short-term bodge, can’t ADFFS just refuse to do the 26/32-bit magic if VProtect is present? As previously said, VProtect is fairly pointless on 32-bit platforms. |
|
!!!!! Wow, that’s a pretty big omission.
Care to share? Always fun to look at the differences. |
|
In the past, I’ve encountered some very peculiar bugs in ABC. Some of the bugs are actually intended behaviour. ABC does not have LOCAL variables only PRIVATE variables (they are in scope statically for the function or procedure not via the stack as they revert to their global equivalents when the procedure or function in which they are defined calls another function or procedure. Most confusing. |
|
The alternative can be just as confusing. When I used to use ABC for quite a lot of applications I made a point of always passing ‘LOCAL’ variables into other PROCs/FNs as parameters. Saved a lot of heartache. |
|
Yes, I agree. I had cheated and had certain global variables that were exactly that except for a brief interval – when the program was doing a specific thing – so I called a particular procedure to do that thing, made these variables LOCAL while it was doing it. The problem was that that procedure called lots of other procedures and functins that referenced these global variables – the ones that were temporarily LOCAL to the calling procedure. Too many to add them to the parameter list. All perfectly legal in BASIC, correct structured programming, worked perfectly in the other compiler RiscBASIC (which was vastly superior to ABC). Just didn’t work when I tried to get the programme to work under ABC (RISCBasic not developed beyond StrongARM and the Iyonix had now appeared) due to this horrendous bug (sorry feature, as it was documented). Also it won’t provide line number references for any run time error message so I had to interleave alternate lines ‘line%=23455’ and add an error handler to announce the ‘line number’. |
|
In the past, I’ve encountered some very peculiar bugs in ABC. In BASIC, Here’s the list that I found:
This is also true for any other leading value, while all other characters seem to be properly ignored. Doesn’t this look like a real bug? |
|
If the compiler is now being worked on could this ‘LOCAL’ feature/bug be removed or might it stop some programs from working? |
|
Another request for the new ABC compiler:
The current version of ABC doesn’t accept this. You’re supposed to write:
Not really an issue, perhaps, but still extra work, especially with multi dimensional variables. |
|
For the time being, I think the priority is to make sure the current version works as it always has, but on modern hardware and OS versions (eg. ZPP etc). New or altered functionality will likely come later. Usual problem – not enough time for a small number of people to do a lot of work! |
|
That is sensible – get what exists working everywhere before changing things. However…
By “release into the ROOL tree”, would this be the open or the closed part? If ABC is released into the open part, then some of the work in fixing niggles (re. Paul’s oddities) and supporting some of the later BBC BASIC additions could be crowdsourced. In other words, us. ;-) |
|
ABC is currently part of the ROOL dev CD, I think. This may have some bearing on how it is handled. At this stage I don’t know any more. |
|
Since installing zpain I find that the frequency with which startup freezes (while the desktop background is being rendered) has increased. Using RO 5.21 on Rpi2. I am also getting “undefined instruction at &FC38775C” from Messenger Pro (7.08) occasionally. |
|
It’s nice to see (from discussion on archive-on-line) that the Zero Pain debate has progressed beyond the denial stage of a change project and into the resistance phase – see Project Steps – so we should soon be in the cooperation or rebuilding phase where the overall effect starts getting positive. |
|
I could go a bit Borg and say resistance is futile but those wishing to resist can step sideways and backwards into the alternate universe of RO6. One thing of note is that (sticking with the universe analogy) the leakage from this universe to that in the form of fixed code/programs will benefit that other universe. |
|
Not necessarily – if anything RISC OS 5 specific is to be used1, it makes software as incompatible with 4/6 as software written with that in mind was with RISC OS 3.7 back in the day. 1 Leading to the age-old question of whether we should use facilities present in RISC OS 5, or eschew them in favour of older facilities in order to remain compatible with a stagnant (abandoned?) version? Obviously it is a harder call if one is writing commercial software as the balance of supported systems can directly affect potential users (and thus cash flow), however over the years a lot has been added to RISC OS 5, and – emulation aside – the alternative runs on increasingly ancient hardware. Surely there comes a point when it makes sense to use what’s right here instead of being tied to the past? There’s enough of this already in our fair lands… |
|
Fixing ZeroPain problems is stopping programs accessing memory they should not be accessing. |
|
Which was the point I was making, and I think is the point of Zeropain. Fixing the faults doesn’t make the code incompatible with any version of OS. |
|
Have any of the core Apps / Modules been updated in the HD image for ZeroPain? I’m just wondering if I should be reporting two ZeroPain I’ve seen for NetSurf and Menu, or if I should be updating my !Boot with the latest. |
|
I’ve just spent the day recompiling todays TungstenDev distribution over and over again before realising the data aborts I was getting are caused by not running zeropain – I think the person who decided to do this has a sadistic streak. Anyway I was disappointed to find that amu from dde25 is affected. Presumably it’s now been fixed? The zeropain entry below was caused when !Builder was run after installing todays rom.
|
|
Is there a way to turn off the output from zeropain? I don’t need the 1MB output from a rom compilation accumulating. |
|
Always. Every malfunction you see. I hope to submit a patch to Netsurf tonight to prevent a few null dereferences. |
|
ROOL are aware that the DDE has issues, but I’m not sure if it’s actually been fixed yet. |
|
Edit the file Boot.Choices.Boot.PreDesk. Although I suppose if you made the location it sent data to be null: then the output should be blackholed |