Ovation

Word processor != Document processor.

Point taken. You could always run LaTex on the original Pi though (Iyonix compatible version here:
http://www.flypig.co.uk/?page=armtex&dnload=armtex).

I once pestered Martin to support the unusual RTF documents created by my word processor but without success:

;-)

Version number not bumped as only two minor fixes.

Of course, in 10 years’ time we’ll have forum posts from people saying “I have version 1.50S (24-Oct-2015) and it crashes on my ARMv7 when I do X”, and someone else will say “I also have 1.50S (24-Oct-2015) and it works for me”. In this case, the “broken” version was only available for about a day so it’s probably not a huge problem, but just consider it for the future :)

It was considered. ;-)

Thank you for pointing out the version date. It is buried in a header file someplace. I ought to make a short bit of BASIC to dynamically create a value with the correct date…

If Ovation suddenly fails to load a saved file, throwing Type 5 errors – take a look at the backtrace that appears.

If the function names, reading down the blurb, are relinkbox, relinkbox (again), relink, loadfiles, loadfile, loadanyfile, and main – then this seems to be because Ovation did not correctly shut down the last time (crash? taskkilled?).

Enter, at the command line:

*RMKill Ovation
*Unset Ovation*

and Ovation should then start correctly.

[this appears to concern files with linked text frames…?]

Enter, at the command line:

RMKill Ovation
*Unset Ovation

and Ovation should then start correctly.

The loose approach¹ would be to add the star commands to the Run file and stamp on the effects of the error. Of course you being the way you are I’m sure the root cause will be traced.

¹ I spent a good proportion of this week dealing with suppliers that use the loose approach. I regard it as sad that the task was deemed to need my talents.

I try my old stuff (documents) on ARMX6 with Ricks Ovation, all was working fine.

…version 1.50S…

I’m from the future…

My CD is labeled with 1.50SE.

Short answer: I can’t fix this.

Longer answer: It turns out that something rather odd is going on with the “Ovation” Dynamic Area. I have tried affixing a “random” value (the value of Ovation$Case) to the end of the area (unique name), but things still go wrong.

Proofs

Proof (part 1):
1. Run three copies of Ovation.
2. Drag a file with linked frames to the third copy of Ovation (the last one loaded). It will crash. The other two will not.

This test is infinitely repeatable – if you quit all instances and then load three, the third will crash. But note that the crash will leak a DA, so repeating the test could lead to a dozen “Ovation” DAs, and each time the third instance will crash.

Proof (part 2):

This is more serious. Start Ovation by double-clicking a file with linked text frames. Alt-Break to TaskKill it. Repeat. Repeat again, and as this is the third time, it will crash.

Proof (part 3):

Remove all Ovation DAs. Ovation magically works again. ;-)

Proof (part 4):

A build of Ovation without DA support works. I have 22 (!) copies running with no problems.

How to recover

Here is a short BASIC program to do that. Call it “Recovery” and put it alongside Ovation.

REM >Recovery
REM
REM Fix a broken Ovation that Type5's trying to load
REM a document with linked frames.

REM First, kill the Ovation module
SYS "XOS_CLI", "RMKill Ovation"

REM Then unset all Ovation-related variables
SYS "XOS_CLI", "Unset Ovation$*"

REM Now destroy any lingering Ovation Dynamic Areas
REM (it appears that this is the problem, though no idea why)
area% = -1
REPEAT
  IF (area% = -12345) THEN area% = -1
  SYS "XOS_DynamicArea", 3, area% TO , area% ; err%
  IF (err% AND 1) THEN END : REM No DAs on this machine?
  IF (area% <> -1) THEN
    REM Read the area name and number
    SYS "XOS_DynamicArea", 2, area% TO ,,,,,,,,name$
    IF (name$ = "Ovation") THEN
      REM Yup, one of ours, so say bye-bye.
      SYS "XOS_DynamicArea", 1, area%
      REM Now bodge the count to start again ;-)
      area% = -12345
    ENDIF
  ENDIF
UNTIL (area% = -1)
END

Potential solutions

The ideal solution – finding the bug – is not exactly a viable option. I’ve spent all evening on this instead of watching Liv Moore. ;-)

With that in mind, here are two potential solutions. Which is the preferred?

1. Restrict Ovation to only running a single copy? Things could still go wrong if Ovation crashes; but on the other hand if we know that no other instances of Ovation are permitted, we could auto-clear any stray DAs at startup.

1. Change Ovation back to using application space instead of a DA. This may be a problem on older (26 bit) machines or machines running Aemulor due to “artificial” restrictions on the slot size (28MiB if I remember correctly? though can’t Ovation proxy large images, or was that OPro?); however on modern RISC OS on modern machines, the limit of a single slot is that of available memory.

My preference, as if anybody cares ;-), is a hybrid solution based upon option #2. The !Run file will, by default, set the variable “Ovation$InhibitDAs”. When this variable is set, Ovation will use application space. This will be the default setting.
If people want to edit Really Big documents on machines with largish memory but a restricted WimpSlot (Aemulor & RiscPC era), they can edit the !Run file to switch on DA use (and just don’t load multiple incarnations!).

What say you?

Raik: The build date you quoted earlier in the thread is the same as v1.49 in David’s code. Are you sure you are from the future? ;-)

Are you sure you are from the future? ;-)

I’m not. More “old school”
The Version inside the CD is 1.49.
But the label… Maybe it is better to give a higher number. Referring to Chris Mahoney…

The ideal solution – finding the bug – is not exactly a viable option.

It seems to happen when the DA is located above 2GB, ie the top bit of its address is set. I had to run 5 copies of Ovation to reproduce this. The first 4 copies run fine but the 5th copy (where the DA was above 2 GB) aborts as described.

It seems to happen when the DA is located above 2GB

Thanks. That looks like it is exactly what is going on. An unpleasant signed integer issue; could be a hellish thing to resolve given how much pointer wiggling Ovation gets up to. Might be better in the short term to just use app space (with DA as an option).

Might be better in the short term to just use app space (with DA as an option).

ROOL are certainly in favour of applications using application space.

DAs make sense if you’re running up against the 28MB wimpslot limit, but on RISC OS 5 using a DA when you don’t need one just means you’re needlessly consuming the limited logical address space.

Of course fixing the signed pointer bug would be good too :-)

Oh, and nice work resurrecting an old classic!

What are the pros and cons of running multiple copies of the same application?
I thought is was frowned upon! Many application error if you try.

I think it depends upon the application.

Many application error if you try.

Which? Multiple copies of Edit, Paint, etc work.

My preference, as if anybody cares ;-), is a hybrid solution based upon option #2. The !Run file will, by default, set the variable “Ovation$InhibitDAs”. When this variable is set, Ovation will use application space. This will be the default setting.

Or simply choice. DA (for 26bit RISC OS, where the bug will never occur) or not DA at all (32bit RISC OS).

*RMKill Ovation
*Unset Ovation$*

Not much help, as the restarted Ovation will crash as soon as you try to load the document you had saved.

Gavin – try the little program I posted to remove the DAs.

David – good point, sounds like a good compromise. I’ll do that this evening.

try the little program I posted to remove the DAs.

Alas, makes no difference. If I double click on the Ovation document I had previously saved it still brings up a type 5 error.

DA (for 26bit RISC OS, where the bug will never occur)

This appears to be optimism a step too far. I can reproduce the Type 5 error on OS6.20 VRPC running in 256MB both with the new Ovation 1.50S and a 26bit 1.48S.

And it gets better StrongED 4.69f8 and 4.70a9 both then mess up, on closing a view the top and bottom toolbars remain on the desktop.

From previous experience 64MB is a safer option for VRPC.

Anyway a bug is a bug even if it is swept under the carpet.

This is not to knock Rick’s magnificent achievement but the snag is a broken starting point.

I note that in the Ovation sources neither h.vm nor c.vm (David Pilling December 1988, Memory Manager) contain that little word uint. In 1988 conflating addresses with ints may have been OK, but it seems to be asking for trouble these days.

is a broken starting point.

Perhaps depends on where the DAs are placed? The check will have put code into app space on RO6 (as I’d check if UtilityModule >= 5). We’ll see how that fares.

contain that little word uint.

A what? Oh, you mean unsigned int. ;-)

Oh, and a quick note for Jeffrey. The DA code specifies the maximum size as -1. Oops. Probably better to use app space on big memory machines.

Great stuff, Rick – I really liked Ovation back in the day, and still think it’s a very nicely designed app.

I have a couple of design points. Take a look at this image:

You’ll see that the tool icons in the bottom left are one pixel too high, leading to a thick black line along the bottom of the horizontal scroll bar. This is particularly noticeable in my rather minimalist desktop theme, but is present in all the other screenshots too. Ideally, the icons here should scale exactly to the height of the window’s tool icons (a value which is variable). At the very least, they ought to fit exactly to the standard tool icon height.

A second point – you’ll notice that the selected icon has been inverted to show the selection. This leaves a white line down the left edge. It would be better to have two sprites here, a normal version and a ‘p’ version, to allow selection to be indicated as it is with, say, radio icons in the Wimp.

Which leads to a third point – theming. Recent versions of RO5 make this very easy – drop in a folder with a Theme name containing replacement Sprites, Sprites22, etc, and these are used in preference to the default version. SciCalc demonstrates how this works. It would be nice if the icons in the main windows matched the window furniture in style. A very quick mock-up is here:

I quite enjoy mucking around with sprites (a tragic character flaw, I know), so I’d be very happy to help out designing some variants and updating the code. Let me know if this would be welcome.

Also, look at this image:

Like many RO2-era apps, a few icon backgrounds are filled to Wimp Colour 1, meaning that some icons have a noticeable boxout effect in non-standard themes. This is an easy fix – just updating the templates to use transparent backgrounds. Again, I’d be very happy to work through them and make these fixes, if that would be welcome. We could take the opportunity to make sure that the icon sizes are all Style Guide compliant, too.

Great to see this back in action, Rick – nice work!

Hi Chris,

I probably messed up my calculations for the sprite height. I just doubled the height of everything in the older 2:4 icons.

I notice already that your link icon is less crappy looking than mine. ;-)

I would welcome any help on offer. I have increased the size of the internal sprite area to 8192 bytes (it is a char array in c.wos). Let me know if you need more space. It should be dynamically allocated, and maybe one day it will be…

Also, two notes regarding the templates:
1, Do not alter the order. The non-spellcheck version only loads the first ‘n’ templates, while the spellcheck version loads them all. [It is strange, I load mine by name, but different people = different methods. ;-)]
2, Ensure the text tool is kept as selected when you save the file, or it won’t appear as selected when Ovation starts. [No comment!]

Thank you for your interest in Ovation.

And it gets better StrongED 4.69f8 and 4.70a9 both then mess up,

No surprise there, StrongED likes top-bit-set DAs even less than Ovation. Guttorm Vik tended to use signed comparisons on memory addresses, fine in his day but now…

I ‘fixed’ it, in the way David suggested, a long time ago. Here’s the relevant bits in case it’s of use to anyone:

| Find operating system version
SetEval StrongED$OSVsn 600
RMEnsure UtilityModule 6.00 SetEval StrongED$OSVsn 500
RMEnsure UtilityModule 5.00 SetEval StrongED$OSVsn 400
RMEnsure UtilityModule 4.00 SetEval StrongED$OSVsn 350
RMEnsure UtilityModule 3.50 SetEval StrongED$OSVsn 310
RMEnsure UtilityModule 3.10 SetEval StrongED$OSVsn 200

| Don't use dynamic areas on RISC OS 3.1x or 5.xx.
If StrongED$OSVsn >= 350 Then Set StrongED$UseDA 1 Else Set StrongED$UseDA 0
If StrongED$OSVsn >= 500 AND StrongED$OSVsn < 600 Then Set StrongED$UseDA 0

Okay…

Here’s what’s new

2015/11/07 v1.51RM *released*

* Version suffix changed to "RM" so you know who to blame. ;-)

* Changed the copyright line in Templates to "© APDL and ProAction 2001" to
  match that shown in Raik's picture. This is because my Templates said
  Beebug, and that's only fifteen years out of date...
  
* Ovation doesn't support draggable slots, so why was its memory bar being
  shown in red? It no longer blindly Acks the message so the memory bar is
  green like it ought to be.
  
* Got rid of the dumb crash message that said "Save all open documents with
  new names!, and start Ovation again.". The app is dying, there is no
  possibility of saving anything.
  Now it says "Please report this bug so it can be fixed!".

* The curse of the Type5 on loading certain documents (most likely those
  with linked text frames) seems to come down to signed integer calculations
  with Dynamic Areas that cross the 2GiB boundary. That's when it all goes
  bang. Additionally, the DA is created with the maximum size being specified
  as "all available memory" which might have been reasonable when you may have
  had up to 128MiB installed, but on a machine with a GiB, it can be really
  unfriendly to the logical memory mapping.
  As such, on RISC OS versions 5 or later, Ovation will revert to using the
  application WimpSlot for memory instead of a Dynamic Area.
  
* WimpSlot requirements revised to 576KiB as this is the minimum that Ovation
  will require when using application space for document data.
  
* The default font for new documents is now Trinity, instead of SwissB or
  Homerton (depending on what's in your !Fonts). It is more pleasant reading a
  serif font than a sans-serif one in *print* media, as a desktop publisher
  surely is.
  See: hxxp://www.urbanfonts.com/blog/2013/02/serif-vs-sans-the-final-battle/
  [and plenty more on Google]

* Note - if you don't like my decision, or if you don't like Ovation's other
  defaults (page size, margins, etc); then set Ovation up as you would like it
  and then save a StyleSheet as "<Ovation$Dir>.Default". This will then be
  used as the default styles (including custom paragraph styles, if you like)
  for when Ovation is next loaded.

* Minor change so the menu "Modify frame...   Sh^M" and "Modify line...    Sh^M"
  (Object submenu) appears like that, instead of "Modify frame...me" and
  "Modify line....me".
  This was because Ovation pastes the applicable data into the menu structure,
  and the original menu text read "Modify text frame...", but this distinction
  is not actually made in the code (or the Messages file).

* "Ovation", the module "Ovation" (and the SWI chunk), and the various commands
  are now officially registered with ROOL. Only twenty six years late, eh?

(“hxxp” because Textile sucks)

Here’s where to get it

http://www.heyrick.co.uk/blog/index.php?diary=20151107

And…

Here’s the button that needs pressed so I can go watch Noragami Aragoto…