Territory_ConvertOrdinalsToTime subreason?
12 posts, 4 voices
Martin Avison (27)
1494 posts
|
I have been having problems with a Territory_ConvertOrdinalsToTime which returned an error “Unsupported subreason” on RO5.19 (but not on RO5.18). I have no idea what ‘subreason’ it is objecting to, as I am passing r0=-1 (current territory), plus pointers to the input and output time blocks in r1 & r2. What am I doing wrong? It may be relevant that this is on an oldish 5.19, dated 31 Oct 2012, but with the latest Autrialian Territory loaded, and timezone set to +8 for Western Autralia. This is after discovering that Territory_DaylightSaving gave an error ‘Message Z9_2013 not found’ (RO519 dated 23 Jul 2012) or ‘No rule for given timezone’ (RO519 dated 31 Oct 2012). However, this was with the UK Territory with timezone set to +8 (DST) and passing a time zone obtained from Territory_ReadCurrentTimeZone … which was -1. So it was not really suprising! But loading the (correct) Australian Territory has just created another error elsewhere! |
Sprow (202)
1158 posts
|
Territory_ConvertOrdinalsToTime is just mapped internally to a different call handled by the TerritoryManager, so you need a matched pair (or the corresponding RMENSUREs). The (internal) flags were changed in the territory modules version 0.57, which will include the ones on the download page, and manager 0.55. So you’d either need to update your system ROM to get that manager, or make a softloading version to test with on an older OS. |
|
Martin Avison (27)
1494 posts
|
Thanks Rob, that explains it. I wondered if it was a mismatch, but could not tell from my understanding of the changes. Trouble is, this is for an Australian user, so it makes it more difficult to dictate how they should update their ROM, and even harder to describe how to create an older territory module! And anyway, I still probably have to try and cope with the error happening! By the way, did you ever consider my request to enable DaylightSaving 4 & 5 (and possibly other swis) to take a timezone of -1 to indicate ‘use current’ like territory? |
|
Sprow (202)
1158 posts
|
Since 5.19 is an unstable beta version, there’s no reason to hang on to crusty ones from months ago if (as in this instance) there’s a problem or incompatibility discovered which is known to be resolved in a more recent beta. I certainly wouldn’t try to code round the mismatch in your app – an appropriate RMENSURE would be the most you might want to add.
I did when last looking at the module. The problem was that Territory_ReadCurrentTimeZone already uses -1 to mean “not known within this territory” and typical usage would be to pass on that value unchanged, which currently would give an error (as it should). I was uneasy about changing it to -2 (or some other invalid value) to free up -1 to mean the special “current” value. Then I probably got distracted with something else. |
Chris Hall (132)
3554 posts
|
Since 5.19 is an unstable beta version, there’s no reason to hang on to crusty ones from months ago if (as in this instance) there’s a problem or incompatibility discovered which is known to be resolved in a more recent beta. One difficulty is that Pandaboard and Beagleboard users are holding on to ROM builds dated 16th May 2012 – the last version tested and distributed by R-Comp to PandaLand/ARMiniX and ARMini subscribers. The situation with the Pi is simpler, in that the official beta version of 5.19 is held on the ROOL site as well as the latest daily build. Any problems with the daily build and you can download the official one again. It is also difficult to pick out the optimum time to upgrade as development proceeds in parallel – an important item gets fixed and a tiny, unimportant one breaks. I have tried to pick out the major improvements from May 2012 to Nov 2012 (after which the RC5 to RC6, 7 and 8 changes are explicitly mentioned) but it is surprisingly difficult as one is overwhelmed with detail as soon as one tries. I have tried to capture the current position here – see under ‘Hardware’ but am sure I have not quite got it right yet! I know this will be resolved once 5.20 appears as all users, Pi, Pandaboard, Beagleboard, Iyonix will be expected to upgrade to 5.20 but the task of testing and finishing 5.20 should not be underestimated. |
|
Martin Avison (27)
1494 posts
|
I am not sure what I would need to RMensure, though, as I cannot include any for Territory modules (how do I know which they would be using?). But I do need to cater for eg an Australian user setting UTC+8 while using the UK Territory, as this can easily happen. So I need to be aware of the error situations. However, although it is easy to cater for those who have a matching set of !Boot, ROM and Territory module, as Chris points out there are a lot of good reasons why there many variations on that theme. I need to cater for the likely ones, but not the obscure ones … deciding where to draw that line is not easy. One significant problem is the difficulty of updating !Boot for anyone who has used RO for some time. I recently tried to put the latest 5.19 on my Iyonix as a quick test, but unless I updated !Boot it failed miserably as the screen mode stuff seemed to fail horribly without a new !Configure. So I gave up (for the moment, until I have more time).
Agreed! |
|
Chris Hall (132)
3554 posts
|
One significant problem is the difficulty of updating !Boot for anyone who has used RO for some time. What is needed is an incremental HardDisc4 structure. For example for those who update from 5.18 to 5.20. The old !IyoUpWch application used to do this – somewhat easier when only a single hardware platform (Iyonix) existed. It is a matter of examining the HardDisc4 contents that were ‘standard’ when 5.18 was released and that which is current now. Then produce a ‘what to delete’ and ‘what to add/modify’ compendium so that the user can understand what is being changed (and can revert if he gets problems). So far as the Raspberry Pi is concerned, the ROM changes from RC6 (Nov 2012) to RC8 (Mar 2013) did not require any change in HardDisc4 (although one or two things such as !!VCHIQ on the disc became unnecessary as it got included in the ROM). So far as the Iyonix was concerned, the upgrade from 5.10 to 5.16 and 5.18 did not require any disc changes either. Many of the earlier rom updates, before 5.10, did require disc updates. So this (the necessary changes to HardDisc4 to support an upgrade from 5.16/5.18 to 5.20) is a task that can be done now so that it is ready as and when 5.20 gets released. In fact, many of the changes can be done and will work under 5.16/5.18 – only a few will require the later rom. |
Rick Murray (539)
13840 posts
|
Can I create a UK-EU territory; for expats in Europe that want a UK territory only with euros and defaulting to CET timezone (as is most of mainland Europe except IIRC Portugal) ? |
|
Sprow (202)
1158 posts
|
I certainly wouldn’t try to code round the mismatch in your app – an appropriate RMENSURE would be the most you might want to add. I meant to simply RMENSURE the required territory manager and refuse to run if not met. I agree you should be using the X form of the SWI and doing something graceful, but not to bother trying to emulate the removed behaviour (which was wrong anyway).
Indeed, though the daylight saving rules for UK are different to Australia (or historically have been including the anomaly in 2000 for the Olympics).
It really is worth drumming home that RISC OS is more than just a ROM image, the disc, and in particular !Boot should be considered part of the OS too. By most metrics (amount of source, size of binary) the disc image is actually more than the ROM. It’s also worth mentioning that the disc image is backwards compatible, with a few minor niggles right back to RISC OS 3.10. So users can try out 5.19 (with updated !Boot) now, and roll back to 5.18 if something odd happens. Unfortunately people’s inclination to fiddle around inside !Boot makes an automatic updater very hard to deal with all the cases – especially as the earlier disc images (harking back to Iyonix times) had a number of mistakes in it, like loading all the sprites twice just to slow things down. My upgrade strategy would simply be rename !Boot out of the way, grab the new one, reboot (so the skeleton is copied out of ROxxxHook) and reapply settings using only the configure plugins. That just leaves any extra apps in Boot/Resources and a sys merge (again, using the configure plugin).
The territory concept ends at country boundaries (because it also influences the messages) rather than covering whole continents, so I’m not sure how a pan central Europe one would fit. |
|
Martin Avison (27)
1494 posts
|
Nope! Unlike Alarm, my application has to run on ALL varieties of RO, from 3.50 onwards. It should never refuse to run, or fail with an error. It must adapt to it’s environment. I am aware Australia has different DST rules from UK. But in this case I need to ensure my program can fall back to the DST rules defined within it (and user-changable), even when RISC OS is used for time setting.
Indeed. Trouble is, !Boot is also more than ‘just’ part of RISC OS! For example: Choices; !Scrap; extra things in PreDesk, Tasks, Resources, Library, Modules, and Utils, apart from any more subtle changes. It might help if !Boot configure ‘Look at’ and ‘Run’ enabled things to be temporarily excluded (like Select). I try and keep as much of ‘my stuff’ separate, but it is not easy.
Yup, that is how I intend to do it, BUT I need some time, and when I can afford to have a machine that may (will) not operate as I need until I get it fully sorted. Indeed, I have already tried that sort of technique on my BeagleBoard. But if the list of things to do puts me off, it will be even more daunting for newer users! I really applaud your work in getting back to a new universal !Boot – it must have taken a lot of effort. But unless there is a simple upgrade process, I can forsee many users having problems. |
|
Chris Hall (132)
3554 posts
|
My upgrade strategy would simply be rename !Boot out of the way, grab the new one, That is, of course, the simplest way to try the new ROM. What would be nice is if there was a way of comparing the pre-upgrade !Boot with the vanilla !Boot contemporary with the pre-upgrade ROM version in an intelligent way so that the bits that have been added over the years can be listed so that the user is reminded that they need to be added again. Even better if it could indicate where they might have come from. Fonts are easy – they can just be copied over from old to new. Things like AWViewer in Boot.Resources can just be copied. Some modules that used to be soft-loaded are now in ROM and so should not be copied over. Zap is a good example – when it is installed it requires !ZapFonts and !ZapUser to be put inside !Boot somewhere. Going to a new !Boot will stop Zap working. I did originally try to keep a backup of !Boot before I added anything to it but soon gave up. There is an opportunity on the Raspberry Pi, where the filecore partition has not changed from RC6 to RC8, to accompany the next ROM upgrade for the Pi with an incremental HardDisc4 update. Another help to the user would be a description of the changes to the standard HardDisc4 image, file by file, with comments. I do have the 15 Jan 2010 vanilla ROOL HardDisc4 image, which corresponds to the upgrade to 5.16, and so I could do such a comparison between that and the current HardDisc4 image. I’m not sure I could explain why each change was made though… |
|
Chris Hall (132)
3554 posts
|
I do have the 15 Jan 2010 vanilla ROOL HardDisc4 image, which corresponds to the upgrade to 5.16, and so I could do such a comparison between that and the current HardDisc4 image. The comparison between the 3May2013 and 15Jan2010 HardDisc4 images is as given below. There are some interesting additions – such as 520Hook, SparkFS now being part of the standard image. |
