Who likes manga?

do it the official SysMerge (well the Merge in Configure.!Boot)

The PlingBoot update says to use the obey and not the merge utility as it needs to do some things in places the merge utility can’t reach. It’s still not difficult.

the thought of hacking a different copy in like that had never crossed my mind

I very neatly lost a mouthful of tea when I read that. If anybody has actually done this… Oh my God…

Andrew has some very nice machines

FTFY

it puts a clamp on the wimpslot that can’t be removed without a restart.

I think “technical reasons”. Does the machine need a restart? Or would it suffice to fully quit Aemulor?

Might be useful to have an up to date list.

Won’t this be the same list of “desirable but not show stopper” features that we always end up with?

As opposed to things like:

• Is still being developed (and open source if you want to fiddle)
• Uses modern hardware (USB storage, SD cards…)
• Is still being developed
• Uses extremely efficient ARM SoCs
• Is still being developed
• Runs on hardware where 100mbit networking isn’t embarrassing
• Is still being developed
• May soon(ish) support IPv6 and modern crypto
• Is still being developed
• Zippy even on the lower end of the Pi family (compared to the fastest StrongARM processors)
• Is still being developed

I think “technical reasons”. Does the machine need a restart? Or would it suffice to fully quit Aemulor?

Restart (Pi3) RC15

Runs on hardware where 100mbit networking isn’t embarrassing

That’s slightly faster than serial, or did you mean M? Mb/s

The PlingBoot update says to use the obey and not the merge utility as it needs to do some things in places the merge utility can’t reach. It’s still not difficult.

I plead ignorance of the procedure since I don’t have a need to use that on the RO5 platforms I’m updating.
Besides, I’d say that “can’t” probably ought to be replaced with “doesn’t”

the thought of hacking a different copy in like that had never crossed my mind

I very neatly lost a mouthful of tea when I read that.

OK, I fess up, it had crossed my mind that I could piddle around with things in that or a similar fashion and then spend ages wondering what exactly I had broken.

As a side note, for the SSL bounty, ROOL seem dead set on using the old AcornSSL module API as a base (which I think only !Browse uses), rather than our open SSL API (SecureSockets) that is in general use. This means you won’t be able to drop it in for use with Manga or AntiSpam or whatever unfortunately, although we’re looking at the possibility of a “Shim” (more expense, unfortunately).

Given all our source and API is freely available, my preference would be for the ROOL module to offer both APIs, but focus on SecureSockets API to minimise the amount of work programmers have to do (having to re-write every SSL-based program to use the new module would be a major issue, since some aren’t easily modifiable). Thoughts welcomed.

Since I’m playing with mbedTLS at the moment (hoping to find myself on a useful and upward learning curve!), I’ve got a couple of odd thoughts to pass on.

I’m not convinced that the existing SecureSockets API provieds a good enough basis to adhere to. Even something as basic as the “CTX types” are outdated; they only encompass SSLv2, SSLv3 and TLSv1, all of which are deprecated. Also, for anyone developing new stuff, the API is harder to use than necessary; first example being that you have to go through all the process of creating and connecting a socket, then use the Secure_Connect call to connect a secure layer to it, whereas mbedTLS does the whole thing for you – give it the host name and the port number, and it returns with a connected secure socket.

If a new module were to be made from mbedTLS, I don’t know how the Secure_NewCTX, Secure_ConnectCTXToSocket and Secure_AcceptCTXToSocket could be implemented – unless they become null operations, maybe.

I have no knowledge of the AcornSSL API.

All this stuff about creating a new secure module from mbedTLS is hypothetical on my part. I don’t know if I’m clever enough to do it, or even if it’s possible at all. But I’m enjoying the mental exercise of learning some of it.

Even something as basic as the “CTX types” are outdated; they only encompass SSLv2, SSLv3 and TLSv1, all of which are deprecated.

Worse than I thought then. I had assumed that it would have some support for non-depreated security protocols as well as having the deprecated ones that people would need to be rapidly weaned off.

Wow, there’s been a flurry of activity in this thread!

SecureSockets remains © R-Comp despite us offering the source and API for free. I’d prefer that there weren’t separate source repositories/distributions out there.

Sorry about that; I’d read the OpenSSL licence but forgot that the actual SecureSockets bit wasn’t part of it!

How would you like to distribute this? Bear in mind that it’s only reported to work with Manga so far…

could someone do the ARMv7 work on the small (?) amount of assembler to make a definitive build?

I think I tracked down all the assembly and replaced it with C. I’m on an ARMv8 and haven’t seen any crashes.

is this compiled against StubsG for compatibility with older systems too?

No, it’s not using StubsG. It “should” work on 26-bit machines as it’s using the standard CModule shared makefile, which produces 26-bit-compatible modules by default, but I haven’t tested it on anything other than my Pi 3. I’m just stating facts; I’m not going to get into the StubsG debate :)

Just tried this version (1.03) with Hermes 4.12 VRPC-DL RO5.23 (12 May 2017).
When I try and Fetch from ‘gmail’ it stalls.
Stopping the operation and reloading (1.04 StubG version) it works ok.
(note the old version of (1.03) didn’t work either)

It sounds like 1.04 has fixed something there, and I’m happy to try to merge in the changes if the source is available from somewhere.

I have no knowledge of the AcornSSL API.

The AcornSSL module is one of the handlers called by the URL Fetcher. You can see a plain text version of the documentation on the RISC OS Open wiki. I have an HTML version on my hard drive but I can’t remember where I got that from.

I have an HTML version on my hard drive but I can’t remember where I got that from.

Here are some of them linked: http://www.riscos.info/index.php/RISC_OS_Documentation

Back on the Manga topic, I’m getting an abort on data transfer when trying to open Naruto. I suspect it’s a server-side issue as other manga work fine (which will make this a bit tricky to debug if they fix it before Rick can try it!) but obviously it shouldn’t crash the app :)

I’m running Manga 0.20, SecureSockets 1.05 and OS 5.24. I can supply a Debugger log on request.

SecureSockets 1.05

Is this available anywhere yet? It doesn’t seem wise to continue distributing the 2005 version if there’s a newer one available.

I’m getting an abort on data transfer when trying to open Naruto.

It is some weird behaviour in the SSL module. Over to the Versions entry for details:

0.21  2018/04/23

      There is some weirdness (leftover debug code?) that in some
      circumstances will end a block of data with erroneous &0D &0A bytes,
      and begin the following block of data with four hex digits followed
      by an &0D &0A byte pair. This, surprisingly, didn't seem to break
      things, which is why it wasn't noticed.
      It did, however, cause a fatal crash when reading Naruto, because
      the junk data appeared in the middle of a chapter URL, which threw
      the parser into a tizzy and... bang.
      So now the SSL fetcher looks for the &0D &0A marker and if found,
      takes approriate action to suppress the unwanted rubbish. This
      should not conflict with MangaReader as it does not use &0D &0A for
      its line termination...

I’ve pushed an update to the beta track, as usual. Those who don’t believe in letting software check for its own updates (I trust you aren’t using Linux, Windows, Android, iOS, OSX, etc etc etc!) can pop over to http://heyrick.ddns.net/manga/ for the archive.

Is this available anywhere yet? It doesn’t seem wise to continue distributing the 2005 version if there’s a newer one available.

I think digging in the links to R-Comp might be fruitful.¹
NetFetch5 was released at the Wakefield show according to the article on Iconbar saying NetFetch5 was released because of the release of RO5.24 quote: “Release brought forward as RISC OS 5.24 needed update anyway”

¹ One would hope so anyway.

It’s available with Hermes 5.05, released last week. Andrew said yes before so if you wave…

(If this appears twice… bloody forum broken again!)

I think digging in the links to R-Comp might be fruitful.

Here, searching for “rcomp.co.uk” comes up with the last post in January 2014 (huh?), and there (on that site), there doesn’t appear to be an available “get your updates here” page.
Looking for arsvcs (how does that still work? it’s a Demon address!) is a bit more fruitful, but the only thing that looks useful is http://www.arsvcs.demon.co.uk/webster/download/ssl.htm but, alas, the download link is a 404.

So…

Andrew said yes before so if you wave…

I’m waving. :-)

Is this available anywhere yet?

SecureSockets is not freely available. R-Comp only distribute it as part of chargeable applications. They paid for its development.

SecureSockets is not freely available.

" Feel free to include the module with !Manga if you wish. "

I think, since a high vector RISC OS is the way forward, that it would not be entirely useful to supply an old ZP-unhappy version of the module when a newer working one exists.
Plus, it is – at the moment – our only working SSL solution for normal third party applications (eg not baked into a browser or as a non-module shared library).

Check your email :)

PS. Thanks for 0.21; I can confirm that it works now.

They paid for its development.

But not for the recent updates to allow it to work on various recent hardware platforms or high vector OS versions hence, I think, the bit that Rick quotes about feeling free to distribute it with !Manga.

Ideally the functionality would be part of the OS so that R-Comp et al don’t have the task of keeping it up to date.

Ideally the functionality would be part of the OS so that R-Comp et al don’t have the task of keeping it up to date.

This will happen, as part of the network stack upgrades.

Le petit bémol? It’ll be the AcornSSL module that was, as far as I can work out, only ever used by one application, instead of SecureSockets which is currently being used by several applications. <shrugs>

Is SecureSockets v1.05 Zeropain module different from the v1.03 version pointed to from ROOL forum.

(Doesn’t/did’nt Phoenix use AcornSSL)

1.05 is a ZeroPain-patched version of 1.04. It is not the same thing as my rebuild of 1.03.

If anybody is having Manga “freeze” after downloading and parsing the list of available manga, that may be because my server is switched off.
Try giving it a few moments (it should time out after ~8 sec). This only happens when you start Manga, that’s the only time it checks, and if it bothers you (or doesn’t time out correctly), then simply unset the beta track system variables and the check won’t be performed.

Here’s why:

God answering a prayer to remove the
spiders from the attic…

I’ll take a look at the update check code soon(ish) to make sure it works correctly and to have it fail out quicker – getting a reply from the manga server is important, from my server not so much. ;-)

Thankfully my S7 is waterproof because it’s chucking it so excuse me if I now hit Send and leg it the quarter kilometre back home (where there’s stuff all signal)… 😐☔️

Just released v0.22 of Manga:

0.22  2018/06/05

      A problem came to light when my server was off for extended periods
      of time - Manga would fetch the list of new mangas and then hang.
      [reported by Doug Webb]
      It turns out that the initial connection to a server was being done
      in BLOCKING mode, which means that it would simply sit there forever
      trying to connect. As that was about as useful as a chocolate teapot
      I have changed the connection code to perform a non-blocking connect
      with a five second timeout.
      Additionally, when looking for a beta-track update, the mouse pointer
      will briefly appear in green-on-cream (visual confirmation). The
      normal colours will be restored once the check has completed.

Because my server is likely to be off a lot this week (endless thunderstorm warnings), I have dropped the archive on Google Drive: https://drive.google.com/uc?export=download&id=19xuiwtspeZ-WJ28rxUZI65YG4qI_ZDBq

Please let me know if this is good, and if so, I can push it to !Store.

Hi Rick, Thanks for the update and it seems to work as 0.21 locked so I assume the server is off and 0.22 turns the pointer “yellow” at least to my aged eyes.

Couple other points, would it not be good to use the timer tumbler/red timeout pointer combination and is 5s long enough time out if you are on a slow connection?

Subject of course to RISC OS 5 style guides on the visual indicator.

Anyway thanks once again for the update.

so I assume the server is off

Yup. AccuWeather says there may be thunderstorms through the night. I don’t fancy getting up at some horrid time to shut down the server, so I just turned it all off.

would it not be good to use the timer tumbler

You mean the hourglass? My first idea was to do that, but Manga is actually polling, you can do Wimp stuff at that point. That’s why it’s the usual pointer and not the hourglass.

and is 5s long enough time out if you are on a slow connection?

Yes. This timeout is not for transferring data, it’s only for establishing a connection to the remote host. If it takes longer than 5s to do that, you’d be looking at an eternity to retrieve any actual data.
Testing with heyrick.co.uk, connecting and retrieving the control file (usual update checks), the pointer “flickers” if you watch carefully. It’s that quick. And I’m on rural broadband.

Subject of course to RISC OS 5 style guides on the visual indicator.

Oh, you mean that book I never bothered reading. ;-)

Anyway thanks once again for the update.

Good to know it works for you. Thanks for the feedback.