Editing Text Without Crashing.

While I do see the point of why you say it is done (knowability of source of code being run), this I still feel is a design level bug.

We covered this already. A design level choice to make the default be something that you don’t like is not a bug.

The intent was to address the fact that many applications are failing at higher rates with newer RISC OS ROMs on the EXACT SAME HW as the software runs well with the older ROM. 5.24 seems to be the cut point, something has been getting changed since the 5.24 release that is causing the sometimes strange troubles with programs while running. More often than not the issues are not in any related to zero-page.

Between 5.24 and 5.28 there are a string of beta releases (5.26 is basically a renumber at the time of the licence change) so the next stable after 5.24 is 5.28.

Do you have any kind of bug report about any specific application?

We covered this already. A design level choice to make the default be something that you don’t like is not a bug.

FIRST When will you stop bringing StrongED back to the front, thought we were passed that.

SECOND A design decision that makes a program not easily usable for its intended purpose is an error in design, and thus a design bug.

ENOUGH StrongED, I do not use it for a reason.

Getting on

Do you have any kind of bug report about any specific application?

See what I posted. How am I supposed to report bugs that I can not track the source of. Hence the question of what has changed. I do not have a 5.26 ROM, though every version from 5.25 betas on have caused more of these kinds of behaviours with multiple applciations, including Zap, Netsurf, and random super small WIMP utilities from all kinds of sources.

Can not report a bug if can not gather enough information to report the bug. Though these behaviours happen with so many applications that others must run into them as well. I wish I could report something, that requires more data than just it behaves such and so, which is all the data I have managed.

So sorry I am unable to report a specific bug. Hence the request to address the on going compatibility of applications.

Not postin more for a bit, as the POUNDING DOWN STRONGED BULL CRAP is getting old and I am doing my best to keep this post polite. So will take a bit to calm down now.

StrongED does edit programs as text with physical, not logical, line numbers. The easy thing to do is make these the same:

Global Choices>BASIC>Save with increment of – 1
Global Choices>BASIC>starting with line – 1

Then even throwback works.

This is no longer required for StrongED 4.69 and above. StrongED will scan the BASIC file for the target line number that’s in the throwback message. The BASIC line number is then converted to the corresponding physical line number.

A design decision that makes a program not easily usable for its intended purpose is an error in design, and thus a design bug

Sorry, but if a program (any program) has an option to turn off a feature you don’t like you’re supposed to use the option. What you are not supposed to do is declare it to be buggy.

So sorry I am unable to report a specific bug. Hence the request to address the on going compatibility of applications.

Unfortunately unless you can describe a specific repeatable circumstance that causes an error/ or crash/ or just strange behaviour then the application maintainer can’t reproduce the circumstance on a test machine while logging all system activity.

When I edit a BASIC programme, I may have to add a few new lines of code. So as not to waste too many trees by printing out a complete listing each time I make a change, I keep the line numbers the same except for the lines added.

StrongEd cannot handle this. Zap can. It is not a question of setting options.

Do not get me wrong, there is a lot I do like about StrongED, and if it were not for the Security Error on every action crud I would likely even use StrongED. Though since the design choice was made to make it difficult to be used for its primary purpose, I respectifully decline to use StrongED.

8 years ago I decided to try StrongED, wanting to give it a fair try. I just could not get passed being harassed by the program when attempting to do what is supposed to be the purpose of the program (editing the source of programs, and other text.

So I decided to stick with Zap.

With Respect to Fred, I just am not into being naged for everything I want to do.

Now is it possible to move on without bring up the ghost of StrongED, please?

REM INSERT to make thread readable on low resolution displays.
REM ************************************************************************

Comes back and fixes that newly introduced bug, having forgot to do so just now. ;)

Me thinks someone forgot to copy to RAMDisk before testing, no?

Just a bit of humor (in case missinterpreted).

Unfortunately unless you can describe a specific repeatable circumstance that causes an error/ or crash/ or just strange behaviour then the application maintainer can’t reproduce the circumstance on a test machine while logging all system activity.

I am attempting to tell the maintainer (ROOL) enough information to get in the direction of what may be the cause. Though getting side conversations instead of anything that begins to look at what may be the cause of change withint the RISC OS ROM.

As it is a huge number of utilities and programs, and 90%+ do not ever get into the Zero Page issue, …?

So I repeate, please read some of the example behaviour as described in this thread, can we look at the causes of what may be causing the compatibality issues with ROOL roms after the 5.24 release, getting worse with time to the point I have stopped using the betas, and even the stable 5.28 being pretty bad.

I have taken some looking at the changelogs, though minimal as it is a lot harder to get to than it used to be. Also I am not that good at traking them down.

When I edit a BASIC programme, I may have to add a few new lines of code. So as not to waste too many trees by printing out a complete listing each time I make a change, I keep the line numbers the same except for the lines added.

StrongEd cannot handle this. Zap can. It is not a question of setting options.

The solution to the problem you described previously clearly was a question of setting options – or of understanding how the program works (I certainly didn’t need to set that particular option, and somehow failed to have a problem as a result). The problem you are now describing is a different one, which you appear to be offering to counter the previous solution.

One of the reasons I don’t like sport – football in particular – is because I hate it when a player shoots and the opposing players change the location of the target structure.

That aside, unless I’m misunderstanding, what I take from this is that you keep printed copies of your programs, along with printed changes and additions. That’s um… er… I think I need to replenish my supply of words. I seem to have run out.

That aside, unless I’m misunderstanding, what I take from this is that you keep printed copies of your programs, along with printed changes and additions. That’s um… er… I think I need to replenish my supply of words. I seem to have run out.

A lot of programmers keep printed copies of a lot of there work, it is a good way to have an extra backup that is going to last a lot longer than any digital copies, potentially hundreds of years. It is a good practice, and there is a reason for the saying, if you do not have a hard copy no number of backups matters at all.

That aside, unless I’m misunderstanding, what I take from this is that you keep printed copies of your programs,

Yes, actually only the crucial bits with lots of handwritten notes on them while I am trying to sort out a particular misbehaviour. That way I can reprint a single page to include tweaks and the rest will be correct as the line numbers won’t have changed.

you keep printed copies of your programs, along with printed changes and additions

That reminds me, I have a box and a bit of fan-fold printer paper…

I use it as notepaper, I have been doing since that particular printer was taken out of use in 2004. I may not live long enough to use it all because even scribbled notes tend to be a whiteboard thing most of the time.

Yes, actually only the crucial bits with lots of handwritten notes on them while I am trying to sort out a particular misbehaviour. That way I can reprint a single page to include tweaks and the rest will be correct as the line numbers won’t have changed.

Sounds like you need a CVS

A lot of programmers keep printed copies of a lot of there work, it is a good way to have an extra backup that is going to last a lot longer than any digital copies, potentially hundreds of years.

For anything that isn’t ephemeral, I agree paper copies are far better than digital – I’ve even been published (printed in Learned Publishing no less) on the subject http://clive.semmens.org.uk/Opinion/ElecArchiv.html – where we diverge is in considering computer programs as anything other than ephemeral. I really don’t see how a computer program is of any interest after the hardware it belongs to disappears into history.

One of the reasons I don’t like sport – football in particular – is because I hate it when a player shoots and the opposing players change the location of the target structure.

You shouldn’t need any reason at all to hate football, Vince. It’s just unutterably tedious, especially the managers.

StrongED will scan the BASIC file for the target line number that’s in the throwback message.

I have been using StrongED since it was shareware, so how come I missed that? ;-)

I am not using the latest version ¹, so does it also work for F5 ‘Goto logical line’?

¹ I have everything stable and an aversion to unsettling change.

I keep the line numbers the same except for the lines added.

That is your style of programming and may be not be suited to StrongED.

On the other hand, you could abandon line numbers entirely and just let the editor deal with them.

I could also extol the virtues of throwback.

I have everything stable and an aversion to unsettling change.

This is why I am still running RISCOS 5.23.

I am not using the latest version 1, so does it also work for F5 ‘Goto logical line’?

Introduce some lines to BASIC file, set choices to not strip line numbers, delete some of the lines so the file shows numeric gaps in numbering, save, reload, looks same, F5 30 takes you to physical line 30 not the line with line number 30.

I have everything stable and an aversion to unsettling change.

StrongED (and Zap too I suppose) need people like yourself to thrash the limits and find those extra quirks/bugs.
Once the routine stuff has been done by lesser beings like me, it needs the thorough workout.

StrongED will scan the BASIC file for the target line number that’s in the throwback message.

I am using a somewhat complicated set of programs with a lot of libraries. Quite often the throwback gets the line number right, but the program or library wrong. The line number in the error message matches the one that F5 goes to, so the error report behaves as though the line numbers are a multiple of 1, not of 10. I never display line numbers, in case that makes a difference.

It is unfortunate, for me, that StrongEd cannot edit BASIC programmes. It strips the line numbers making an attempt to find line (say) 631 impossible.

You have two choices. Turn on line numbers so you can manually browse to it, or press F5 and enter the line number.

To turn on line numbers, select Choices in the StrongEd taskbar menu, go to BASIC, untick Strip line numbers and click Save to save the change.

The intent was to address the fact that many applications are failing at higher rates with newer RISC OS ROMs

Are you running any 3rd party software, as errors are fixed as people detail them and your issues haven’t been reported previously. If you post a Repro, the dev team will fix the issues.

Personally, I think RISC OS is far more stable now that earlier builds as so many bugs have been fixed over recent years.

Another issue of some full screen programs is that it will change to the wrong screen mode

Is the correct mode valid? If not, this is expected behaviour. If the mode is valid, please post a Repro as quite a lot of work has been done on the video side over the past few years and this is the first report of an issue.

The intent was to address the fact that many applications are failing at higher rates with newer RISC OS ROMs on the EXACT SAME HW as the software runs well with the older ROM.

The problem is, without reproducable fault reports, bugs of this nature are not going to get fixed.
By all means, stick with 5.24. I am currently sticking with 5.23 for a similar reason, although some of the blame lies with me as I haven’t been bothered to try to figure out what is going wrong. Maybe some day…

More often than not the issues are not in any related to zero-page.

So the program doesn’t abort at all if you turn off the compatibility page, don’t load ZeroPain, and let page zero access raise a memory abort?
Just because it doesn’t seem to be touching zero page when it crashes doesn’t mean it didn’t read bogus information from a null pointer, which is then acted upon some time later – even if it’s the difference between “loading random data that happened to be there” and “loading &0 because there is only dummy data there now”, the code paths taken will not be the same if the program at any point tries comparing the incorrectly read value with NULL. Admittedly, it is a contrived example, but not an impossible one. The only way to be certain that it is zero page safe is to remove zero page and observe it not crashing.

One common issue is strange behaviour of keyboard input in a Wimp Task, though only in that task, often making it unusable.

Can you be more specific? How do you mean strange behaviour? For me, I quite often get rrrrrrepeated keyssssss, and it is extremely weird in that Zap suffers a lot from it, but NetSurf hardly ever (and OvationPro is 50-50).
That said, I believe this problem was fixed a while back.

and have not managed to figure out the source.

Start with describing what exactly is happening. Saying “strange behaviour” isn’t that helpful, as it covers far too many possibilities (*Keyboard France will demonstrate a strange behaviour ;-) ).

Another common issue of many programs that are text mode Star Commands as an AIF, is that it is fairly common for output to get redirected to a secondary output file,

Now that is extremely peculiar, as there’s no mechanism to send any output to a file other than explicitly specifying this in the command line.

If something this weird is happening, it would be useful to have:

• the command that failed (full command line given)
• a list of active modules and their versions
• whether you’re using the real command line or a TaskWindow
• the filename of the file that output is sent to
• is it the same filename each time it happens?
• and how you discovered this – given that a file could have been written nearly anywhere

Another issue of some full screen programs is that it will change to the wrong screen mode (usually wrong color depth)

This is both normal and unavoidable. In the olden days, the VIDC offered a lot of different colour depths ranging from 1bpp monochrome up to 256 colours (64 cols and 4 tints) in the VIDC1 era, or 16M colours on the VIDC2 era. There were numerous steps along the way, like 16 colours, 32K colours…

Modern graphics devices are not as flexible because there’s no point. You’ll often get a paletted 256 colour mode (8bpp), a “high colour” mode (say, 64K 16bpp), and a full 16 million colour mode. There’s no need for stuff like 1bpp black/white or 16 colours because there is sufficient memory these days that if you need a paletted mode, use 256 colours. Otherwise, everybody will be using 16M colours.

The Pi, for example, supports 256 paletted (hence greyscale or colour possible), 64K (16 bit 565 RGB), and 16M. If you ask for MODE 12, you’ll get MODE 15 because the hardware cannot do the 16 colour mode, so it offers the closest it can do.

though clearly be plotting to display memory as if it were the correct mode setting (and looking very strange and unusable as a result).

Probably because the author never expected the mode change to fail, so didn’t bother to check it worked. If you dump 4bpp pixel data into an 8bpp frame buffer… yeah… it’ll go wrong.

These things will work 80% of days, and without any explanation cause these crashes on rare occasions.

What sort of crash? Data Abort? Exception?
If so, stick this into your boot sequence:

Set Debugger$DumpOptions -file -annotated
Set Debugger$AnnotatedFile $.__crash

Then when one of these unexpected crash happens, you’ll get some information written to the file “__crash” in your root directory.

as none of these happen on 5.24 on the SAME HW as they do happen on 5.25 and newer, getting worse with each new release (happening more often).

Just out of interest, what version of the firmware (BOOTCODE.BIN, FIXUP.DAT, START.ELF) are you using?

The random nature of these issues makes any attempt to debug nearly useless.

If things crash crash, then the Debugger can be used to decode what led up to the crash. If something is happening in a seemingly random way, it’s difficult to get an issue to trigger while you’re looking at it. But you can have something to pick up the pieces and look at them.

Personally, I think RISC OS is far more stable now that earlier builds as so many bugs have been fixed over recent years.

+1
Most of the stability coming from fixes to regularly used programmes that messed around with zero-page perhaps?

One thing is sure, with more people having access to the source for the OS, pairing buggy behaviour and a code segment has happened more frequently.

Ok one common example. Suddenly all input into a Wimp Task will be non-alphabetic characters only, even when typing alphabetic characters. I am fairly sure that it is just missing an entire range of characters and replacing them. This will progress, and so long as the application has input focus. Usually have difficulty getting the applicaitons menu when this happens. As it is one of the applications for this example use Zap as the example. Does not matter what Modules are loaded, it is unpredictable, I have ran with only the minimal modules to run the programs I am using and it happens sooner or later. This is the most common behaviour of problem (and the third time this thread I described it in detail).

That can happen with about any application. So far the only application with significant text input that I have not seen it from ever is NetSurf. The newer the ROM the more often the problem accures.

Usually it requires an ALT-Break terminate application when it happens.

As I said no debug information, as i can not predict when it will happen or for what application it will happen.

Now this is the third time I have described this behaviour in detail. I hope it helps to track down what the trouble is.

To quote Rick:

What sort of crash? Data Abort? Exception?
If so, stick this into your boot sequence:
Set Debugger$DumpOptions -file -annotated
Set Debugger$AnnotatedFile $.__crash

Then when one of these unexpected crash happens, you’ll get some information written to the file “__crash” in your root directory.

and to echo a regular suggestion from other quarters: “Run Reporter” and see what the logs from that show.

Next time I switch over to RO5.28 I will use reporter, and see what we get. As stated repeatedly in this thread the issues dissapear when running in RO 5.24 so guess what ROM I am using as a result, unless I need to test a new program (then I will go to 5.28 for a bit).