Textile: Table not possible in forum?

Now that my BeagleBoard is up and running, I was going to update the hardware compatibility page, but before that, I thought I’d practice a little Textile formatting, so I pasted the text of the current compatibility page into a test posting in the “Tests” forum. However, it only showed up as literal HTML tags, like <table>, not as a formatted table.

I then made a smaller test, using some code from the Textile Quick Reference (reproduced below), but that still didn’t work:

Are there more limiting rules for formatting in forum postings, compared to other pages at this site?

Let’s find out! This is copied directly from the “Tables” section of the reference page.

...Yep, looks like there’s a double escape problem there. Rails applications often use slightly different Textile processor versions and set different options; it’s always been a slightly unreliable thing too, so the different options can sometimes have unpredictable side effects. Just have to live with it for now I’m afraid.

You can practice editing in the Wiki anyway, since any page you write can have an arbitrary number of revisions applied so just keep making changes until you’re happy.

Yes; I found a page where I could practice some Textile, but it still behaved a little differently from this site on some content (apparently, some additional functionality has been added to this site, which didn’t render properly on the above test page), so I needed a few round trips with saving before the page looked “reasonable”.

I’ve updated the hardware compatibility list with my hardware, now that my BeagleBoard is up and running.

Furthermore, I found it difficult to find things in that list, as all kinds of devices were mixed together, so I’ve taken the liberty to split the table up according to device type (USB hubs, keyboards and mice, etc.), but feel free to revert it if this is not desirable, or adjust the formatting.

The spacing between each section became rather large (using a <br/> tag), but I found no way to make it smaller, while still leaving some space between them.

Also, the formatting – especially of the later sections – became a little funky, but again, I found no way to fix that…

...split the table up according to device type…

Thanks – good idea. I’ve now made a couple of additions and put some in-page links near the top.

Also, the formatting – especially of the later sections – became a little funky, but again, I found no way to fix that…

Examining markup from other docs can be pretty helpful too, as you’ve probably seen.

This , and other general issues , are a source of continued hassle

Is Collaboa still maintained? Is there a plan to upgrade the site software (or other such solution), some time please?

Belatedly…

...yes, but it’s a big job. It took ages to get the original site integration working. Since then, Collaboa has completely died, so we’d have to shift to something like Retrospectiva or RedMine. There’s then the biggest issue, the Wiki; Retrospectiva and RedMine both have their own, but it may be better or worse than our current one. The headache is data migration. For completely new packages, I have to figure out how to get content from the old system into the new. This is harder if the data is more complex/interlinked. For the Wiki, I expected to be able to migrate over to Instiki without issue but in practice it was a train wreck with lots of formatting problems and broken links.

In short every now and then I try again, bang my head against the same problems for a week, then give up in frustration and put it back down the To Do list to revisit in the near future.

I’m currently working on a new sub-application for the site and that runs on a comparatively modern Rails version. For this, I decided to upgrade Hub too. It took quite a lot of fiddling around to get Hub running on Rails 2 versus Rails 1. it almost works, but the DRb server which manages the shared login across applications is running on a different Ruby version. Certain operations cause it to hang deep within the Ruby runtime; this shouldn’t happen; but it’s extremely hard to debug. So even innocuous things like “making something I wrote run on a newer and theoretically entirely compatible version of the runtime” seems to cause headaches.

I used to really like Ruby / Ruby On Rails but several years of exposure to their complete and utter disregard for any kind of API stability and arrogant ivory tower approach to ignoring critical bug reports etc., even when patches are supplied to fix things, have definitely coloured my view. There doesn’t seem to be much in the way of an alternative though – Django’s immaturity and hacky template language left me very unimpressed – so right now, Rails still seems to be the ‘least worst’. Faint praise.

In short every now and then I try again, bang my head against the same problems for a week, then give up in frustration and put it back down the To Do list to revisit in the near future.

Thanks for the update. I thought something like this was probably the case.

Is the HTML export of no use? And would it be valid to submit a GSoC application for migration of Instiki to Creole?

It’s a question of migrating from one Wiki to another, so HTML export isn’t helpful (well, it’d destroy the original source and make editing ported pages very tiresome). There doesn’t seem to be much point in translating to a different Wiki language, that’ll just compound compatibility issues.

For clarity since I sense some confusion, the current Wiki runs on i2. This is what used to drive the Ruby On Rails wiki, back when Instiki was unreliable and became completely stagnant for a long time. Since then Instiki’s been revived and gained lots of features but it still feels quite shaky. Then again, it’s hard to imagine it being much worse than i2, which falls over almost daily.