Planned web site down time

Where’s Building RISC OS for the Risc PCpen, or whatever it was called? I wanted to use it as a test page but I guess it’s been deleted. There are such things as orphanages, you know!

You mean Building RISC OS for the Risc PC? (Easily found via the all pages index)

I’ve noticed the bug where it says “AnonymousCoward” instead of the real editor’s name; I’ll look into that later (not that urgent).

While investigating AnonymousCoward for this case, why not also change the default to something more meaningful like ‘RISC OS user’ (or just ‘ROOL visitor’ if you think the other’s a bit too “fanboy”)?

You mean Building RISC OS for the Risc PC?

Thanks but no, it was something like the link I gave. I recalled it as being a page probably created in error and unimportant enough to trash!

[Edit: https://www.riscosopen.org/wiki/documentation/files/rool_cog.png]

Where’s Building RISC OS for the Risc PCpen

Deleted. Just make edits to the page you really want to edit. Any new revision within half an hour of an old revision by the same author is coalesced.

why not also change the default to something more meaningful like ‘RISC OS user’

There is no default – Anonymous edits are never permitted. I’ve simply overlooked somewhere that the Wiki either stores or reads back a user name and doesn’t realise it should be asking Hub for details.

#* p<. [[File:Riscosinstallation-tb-v1-01.png|RISC OS Supervisor prompt launching GUI:pic]]

Um, that’s gibberish :-) – what were you trying to achieve? The media asset insertion syntax is quite limited, as described on the help page. If I get rid of the “#*” in there (a Textile list can either be ordered – “#” – or unordered – “*” but not both and it doesn’t make sense to open a new paragraph just after a list item) and remove the “File:” bit at the start, the edit works:

p<. [[Riscosinstallation-tb-v1-01.png|RISC OS Supervisor prompt launching GUI:pic]]

This:

p=. [[rool_cog.png|ROOL cog:pic]]

…also does work, since you can see it working at the bottom of this page:

• https://www.riscosopen.org/wiki/documentation/show/Wiki
• https://www.riscosopen.org/wiki/documentation/source/Wiki

…so if it failed for you then something more complicated is happening.

There are no errors logged that I can find around 23:30 but I’m not sure of the exact time of your edit, nor of the page you’re trying to edit. This had probably better carry on by e-mail. If you could send me details of the page you are attempting to edit and the browser etc. you’re using along with the error you see and, if possible, the time of day – any of those bits of information could be valuable, so as much as you can tell me ideally – then I’ll look into it further.

Thanks for bearing with me. I’ll drop you an email, hopefully this week. As for the Textile list format, it’s the sort of markup I used in this post… fine, perhaps that only works in the forum and not the wiki. I’d rather not have to recommence the list numbering (or ditch it), that’s all.

On a more positive note, the site also appears to render more quickly under Midori on AIOS. Thanks.

it’s the sort of markup I used in this post

I stand corrected, since Textile renders that fine. I had no idea it supported that kind of list format for nesting.

The “File:” part is definitely spurious but with that removed the Wiki syntax bit ought to have worked and if Textile was happy with your list formatting then that part would work too. Textile wouldn’t raise an exception if unhappy anyway, it’d just render the text verbatim rather than treat it as markup.

In other news, the Wiki has been “promoted” to be a top-level link from the navigation bar – “Documents” takes you straight there. The Home page has been rearranged a bit to hopefully make it a bit easier to find things too.

Textile won’t recognise “+” or " " in an anchor name.

I don’t have that problem, but (surprise, surprise) I have a different one… sorry. Do you know if it’s possible to use an anchor in a wikilink? I’d like to link as follows:

[[Cortex-A8 software compatibility list#networking|NetSurf browser]]

but that assumes the intention to create a new page with the anchor as part of the title itself. (I didn’t try creating it, but wouldn’t doing so – if it works – create problems with navigation on the Using the Cortex-A8 port page?) I’ve also (in desperation) tried including # or %23 but they’re no help either.

“Content size (224 kilobytes) exceeds the maximum (100 kilobytes) set for this wiki”

Is there any chance that this could be increased, please?

Do you know if it’s possible to use an anchor in a wikilink?

No. The recommendation is to make sure that you link to the main page first with Wiki syntax to avoid making the page an orphan, then link to anchors – if necessary – using Textile. I think avoiding anchors with page structure in general might be a good idea though. So, you’d have something like this, if you really want to use anchors ¹:

• [[Main page]]
  • "Main page subsection1":wiki/pagename#anchor1
  • "Main page subsection2":wiki/pagename#anchor1

[100K limit] Is there any chance that this could be increased, please?

Ah, I forgot to increase that when I made the new Wiki live. It’s been changed to 1024K.

¹ It seems to make some sense to use anchors in PRM like documents (reason codes, that kind of thing) more than anywhere else, but every situation is different so it’s impossible to make cast iron rules.

Going back a bit – a while ago, I wrote:

…can’t remember whether the old wiki used to use the page title as an h1 heading at the top of pages. It doesn’t now (and perhaps never did – in which case never mind, I guess).

It never did. The new one did but that led to duplicate titles for pages which included their own, so I got rid of the layout title and left it up to page authors to decide.

I may change my mind on that. There seem to be more pages without titles than with and it’s quite disorientating when they’re missing.

Having played around with a few things I realised that Instiki’s document template had some silly things in it so tidied up the code there and ended up re-instating the use of a H1 level heading taken from the document’s title. This made more sense in the specifications I was looking at and works well for the software information pages. It’s probably the right thing to do overall since the “Documentation” title, permanently present previously, wasn’t really of much use apart from reminding you that you were still on the Wiki. See this change.

Related, I’ve updated the Wiki CSS to use the now-centralised table styling. Tables have no borders unless you ask for them. Scroll to the last post in these forum search results for the correct Textile markup, or use <table class="bordered"...> if you feel compelled to write raw XHTML directly for some reason.

Finally, I’ve made sure all the specifications referenced from the Wiki home page render properly and are under a new category, Specification. If you want to join in the discussion about the range of Wiki categories that we should use, please see this forum thread.

This is a copy of a comment I’ve added to the news post associated with this forum thread.

I’ve identified a serious problem in the bug tracker that causes Ruby processes to get stuck spinning in a tight loop under certain conditions and this interferes badly with the wider hosting environment, especially as more and more such processes begin to accumulate. If you’ve had problems with the ROOL site running very slowly or generating errors instead of serving pages recently, that’s a symptom of this problem.

The fault is triggered by attempts to view particular files in the Subversion repository. Something goes wrong inside a piece of code that handles syntax colouring. This code has not been changed in the recent web site upgrade so the failure is currently a mystery and probably points to bugs or incompatibilities in supporting pieces of software, such as shared bits of library code, or possibly even the Ruby interpreter itself – we are using a faster, lighter weight Ruby interpreter for the updated ROOL site compared with the one that we ran before.

As a temporary measure I have disabled Subversion browsing. RISC OS code is in CVS and that’s unaffected – only the web site sources in Subversion cannot be viewed through the web interface. You can still download tarballs and look at Changeset information.

If you try to browse Subversion, you’ll be asked to log into Hub if you haven’t already, then additionally asked to log into the bug tracker itself. This is something a public user would never normally have to do. No public login credentials are available. The whole point is that access to this mechanism is temporarily shut off in order to basically save the bug tracker from itself!

I don’t know when this will be fixed but hopefully not many people will care too much anyway, since the overwhelming majority of interest is in the RISC OS sources in CVS.

Hopefully this is now fixed so source browsing has been enabled for the Subversion tree again.

[100K limit] Is there any chance that this could be increased, please?

Ah, I forgot to increase that when I made the new Wiki live. It’s been changed to 1024K.

Is there any chance of increasing it a little further please (4096K?), so that SD card images can be uploaded?

Increased to 10MB, to give headroom for 4MB and 8MB images if necessary, plus some headroom for extra data if necessary. If the size of the attachments area starts getting out of hand the I might have to shrink it but things look fine at the moment.

Brilliant! Thanks very much.