Who likes manga?

I mean, there’s a version 1.04 of the AcornHTTP module. Does it need to be constantly rebuilt?

I’m not an expert on “agile”, but I thought the point was that rebuilding everything each time was a quick way to flag up if something unexpected had broken.

Anyway, we’re talking about the RISC OS build system here, running on RISC OS using the DDE and some hand-crafted applications to do the magic – not a modern CI system built for the purpose…

If a dependency has changed, can Git flag this somehow?

That’s what I’m asking.

I’m not an expert on “agile”, but I thought the point was that rebuilding everything each time was a quick way to flag up if something unexpected had broken.

Our fault then for not trying it out and beta testing it at the time then:-)

I agree we have limiting factors include little resource so like many I try to help test things to my limited abilities.

I’m not an expert on “agile”, but I thought the point was that rebuilding everything each time was a quick way to flag up if something unexpected had broken.

I do agile (it’s moderately awful, but at least it isn’t Prince-2), and yes, continuous build/integration/test is a core part of it. And an exquisite torment to setup properly. It is critical in a continuous-build environment for there to be a clear and unambiguous identifier for each iteration of the build, and this is especially important with a modular project. In a git environment, it’s common to see a commit ref in the help text somewhere, so that when it goes boom, the user can pick through the smoking remains and tell the developers what went wrong and, more importantly, which build it went wrong in. Otherwise, what’s the point?. Every time a module is built with the same version number and date, the universe kills a kitten. Please, think of the kittens.

What about a CRC check on the newly generated modules with the same version number – and then compare with the last version?

Then flaging a result if different.

Please, think of the kittens.

I think we’re going to need more kittens.
Because I’m seeing an HTTP fetcher that hasn’t changed, and ZLib that hasn’t changed, and three different versions of what you get when you glue the two together.
That ain’t right.

I’ve not had enough cake yet today to look at the longer sequence, but I think you’re chasing shadows with the second sample given, they’re functionally the same:

        LDR     a1,[sp,#&010]  ; loads word at SP+16          LDRB    a1,[sp,#&013]     ; loads byte at SP+19
        MOV     a1,a1,LSR #16  ; a1 = top halfword of SP+16   LDRB    ip,[sp,#&012]     ; loads byte at SP+18
                                                              MOV     a1,a1,LSL #24
                                                              ORR     a1,a1,ip,LSL #16
                                                              MOV     a1,a1,LSR #16     ; a1 = top halfword of SP+16
        CMP     a1,#&11                                       CMP     a1,#&11
        LDRB    a1,[sp,#&011]                                 LDRB    a1,[sp,#&011]
        BNE     |somewhere|                                   BNE     |somewhere|
        ADD     a2,a1,#3                                      ADD     a2,a1,#3
        CMP     a2,v3                                         CMP     a2,v3
        BLS     |elsewhere|                                   BLS     |elsewhere|

04/09/20 – AcornHTTP 1.04 22 Apr 2020 Size 42312 so the same
19/10/2020 – 5.28 download – AcornHTTP 1.04 22 Apr 2020 Size 42300
25/10/2020 – 5.29 Beta – AcornHTTP 1.04 22 Apr 2020 Size 42300
22/12/2020 – 5.29 Beta – AcornHTTP 1.04 22 Apr 2020 Size 42400

So in summary, the stable release worked, but some of the nightly betas could be suspect. Isn’t that what the nightly betas are for? All the components that go into RISC OS have hugely complicated interdependencies, changing the central assembler macros (like Push and Pull) can certainly produce different assembler binaries just as much as C would, that’s why there are Product files to tie a specific set together.

What about a CRC check on the newly generated modules with the same version number – and then compare with the last version?

All the packaged goods have MD5 checksums, and are denoted by a -1 -2 -3 etc suffix on the download. For example FontPrint has had 3 version 1.37’s and nobody noticed, though I suspect that’s rather more to do with there being very few people stepping up and testing them like Doug does.

Manga 0.54 on a Titanium, OS 5.29 (26 Jan 2021) and OS 5.20

With AcornHTTP 1.04 as in the current beta HardDisc download.

Choose a manga here, then press Go!

Error from (unknown): Internal error, trap while in trap handler: Not enough memory, stack overflow, pc = FC1800A8: registers at 00021A10

*where
Address &2059C49C is at offset &0000BD88 in module 'AcornHTTP'
*

Or sometimes this.

00000001: Manga: The manga information file is damaged. Please try again, or try a different manga.

Using a version of AcornHTTP 1.04 build with DDE29c, cc vsn 5.83, the manga loads but does not display.

1B000000: Error from Manga: Unrecoverable error in run time system: Not enough memory, malloc failed, (heap overwritten)

A complete disc image built with DDE29c was installed on a USB memory stick and booted into, whereupon Manga 0.54 ran perfectly.

Similary an OS5.28 HardDisc image was also good.

Manga: The manga information file is damaged. Please try again, or try a different manga.

That means that the file, when received, was less than 1024 bytes in length. So it’s probably exactly correct, given they’re usually at least 10K in size.

Error from Manga: Unrecoverable error in run time system: Not enough memory, malloc failed, (heap overwritten)

Yes, I’ve seen that. It’s either heap overwritten or a full trap in trap handler crash. Either way, don’t use that version of AcornHTTP.

New version of Manga. Whee!

V0.55 makes the choice of http or https be a user option. It also now alphabetically sorts the epic-big list of manga. Huge difference!

It’s available from my site, the self-update gizmo, or (since now I know the borkage isn’t my fault) from Store.
Store now offers a mangahere version. ;-)

Manga also detects the faulty AcornHTTP module and errors out with a message if it finds it.

I have included the code below (it’s a short BASIC program) in case anybody else wants to make use of this, although it appears that it’s only myself and Recce that use the fetcher. Hmm…

REM >CheckHTTP
REM
REM For Manga; detect buggy AcornHTTP module

REM Look up the "AcornHTTP" module number
SYS "XOS_Module", 18, "AcornHTTP" TO ,,,c% ; f%
IF (f% AND 1) THEN END : REM Error? Just bail...

REM Check its version
t% = c% + c%!20
IF ( (t%?13 = ASC("0")) AND (t%?14 = ASC("4")) ) THEN
  REM Version is x.04

  REM Check its length
  IF (c%!-4 = 64416) THEN
    ERROR 17, " some sort of message here! "
  ENDIF
ENDIF
END

The message I have is This version of the AcornHTTP module is defective and WILL crash. You can download a working version (along with explanation) from http://heyrick.ddns.net/manga/ but I removed it from the above because it wouldn’t size correctly in NetSurf.

Hi Rick,

Thanks for the update to 0.55.

Trying the Beta track auto download root from 0.54 gives the following error:

Error when recieveing data:File to big.

So manually updated to 0.55.

Error when recieveing data:File to big.

Updates are stored in !Scrap. Is that disc full? Filled it up with manga? ;-)

The command *Info <Wimp$ScrapDir>.Manga.Update.* should show what’s in there (just in case there’s some overly large file stuck in there). You should see a short file called _update, possibly one called _changelist if you asked for more info, and finally the update archive itself called _updatezip. The update should be ~167K.
Just fired up v0.54 and fetched it locally from the server. No problems.

This isn’t AcornHTTP, by the way. ;-) The update fetcher uses the original socket-level HTTP fetcher that I wrote myself for the first version of Manga, and never got converted to use the URL method (if it ain’t broke…).

Hi Rick,

59GB free on SSD and also get same issue on my ARMBook.

In the Manga.Update Scrap Directory I see a file called _update created with a Data type and then when I hit the download I get a _updatezip being created and then the error.

Once I acknowledge the error the file is deleted.

Update

_Update file contains this:

object “MANGA”
{
version 0.55
lastmodified 2021/01/30
updatepath /manga/manga_0-55.zip
changelist /manga/changelist.txt
updateaction openarchive
notice "Now uses MangaHere as a source, traps the faulty AcornHTTP module, and sorts the big list of manga. "
operatingsys RISCOS
}

and never got converted to use the URL method (if it ain’t broke…).

I remember why it stayed as-was. When Manga first went SSL, I duped the code and added in the bits necessary to get SecureSockets running. When the host then updated to a modern incarnation of https, I had to ditch SecureSockets because it was too old. Indeed, the AcornHTTP module had to be patched to allow it to work with sites using SNI. Now, both fetch mechanisms go via the URL fetcher and AcornHTTP, and the user can choose whether or not to do it securely (usefully, the site doesn’t try to auto-redirect, but it may in the future). This is one of the failings of the URL fetcher – it doesn’t support redirection, and getting information out of it regarding where to redirect to is a palaver (essentially, repeat the failed command with the magic value to get headers sent back, and parse them yourself).
I left the updater using the original HTTP fetcher because WebJames/RISC OS doesn’t do TLS so if the user his “use encrypted” set, it would try to contact the host that way. The original fetcher is straight HTTP, always.

_Update file contains this:

Standard update notification file (at /manga/update.txt). Says the version, the date, where to file the archive, where to find the list of changes, what OS it is for, and a short textual message to display.
The update action is not used, it is there in case I should ever add functionality to it.

What is failing is the attempt to fetch /manga/manga_0-55.zip – I wonder why.

Anybody else have this problem? Anybody else use the self-update system? That’s not a bit of code I’ve been near in a long time.

Hi Rick,

So just to make sure nothing else in !System is causing the issue I installed a one from 18th Oct 2020 and also installed the Siune Nomine ACornHTTP/URL etc from their system update.

It still fails.

Tried it on my Iyonix and it errors with:

Unable connect to socket (36) – Think it was this as it flashed up quickly then all subsequent requests give the same error as the ARMX6 and ARMBook.

update

Unable to connect to socket (36) – Can not fetch file

Just managed to get that on the Iyonix by reseting all the sockets and retrying again.

Hi Rick,

Tried the Manga 0.54 to 0.55 Beta track update on a Pandaboard running 5.28 and it gave the same error.

Tried the Manga 0.54 to 0.55 Beta track update

Special version for you – http://heyrick.ddns.net/manga/doug4.zip

It is built with fetcher debugging turned on (to DADebug as usual). If you hold Shift while it is starting up (you’ll need to keep it held for a few seconds, it builds the big menu first!) then it will defeat the version checking to always report that there’s a new version available (so you can try downloading).

The thing I’m not entirely understanding is that the fetcher will already have fetched the update file, and possibly the more info file using the same method…

The AcornHTTP module only supports HTTP 1.0, which I don’t think anyone has used in donkey’s years.

Is there an HTTP expert in the house? Does anyone know how much HTTP 1.1 differs from 1.0?

It would be nice to get 1.1 support, just before the world goes to 2.0 :-)

Does anyone know how much HTTP 1.1 differs from 1.0?

Not as much as you might think, given that it largely codifies the various extensions to HTTP 1.0.

• Supports virtual hosting via the use of the “Host:” line in the header
• Supports compression/decompression
• Supports chunked transfers
• Supports byte-range transfers (such as used by resumable downloads)
• Supports persistent connections
• Supports pipelined connections
• Supports multiple languages
• Supports OPTIONS to request information on the server without actually requesting any document

AcornHTTP already supports Host (a lot of the internet would break without it), and it would appear to support compressed files. I’m not entirely sure what a “chunked” transfer is.

The way persistent connections works is to open a connection to the server and fire off multiple requests on the same connection, whereas the older HTTP 1.0 treated each request as a new connection. I’m not sure how well this would work with AcornHTTP due to how it is designed. That said, I don’t think that it is necessarily that critical. Separate connections would work, they’d just be suboptimal.
[it’s perhaps better for a browser that can look at the requirements of a page and know in advance that it needs to fetch twenty pictures; AcornHTTP doesn’t really know anything, it’s the client that instructs the fetcher]

The AcornHTTP module only supports HTTP 1.0

If you’re up to baking a test build (or hacking in Zap), I’d suggest just tweaking it to be 1.1 and see what, if anything, breaks.

Nota: a fullscreen mode would be nice :)

Good luck fetching this: http://heyrick.ddns.net/manga/doug5.zip

The walls are full of water from the recent heavy rains, I’m having quite a time trying to download “Into The Badlands” because streaming it is a mess of blockies. Whodathunk WiFi couldn’t cope with a damp metre thick stone wall? :-)

This one has the debugging off, but still has the hold-down-shift thingy to force it to believe there’s an update.

And, yes, I think I’ve found the problem. But, first… you’re not using SDFS are you?

You see, because I am handling all the socket stuff myself (it’s a very early fetcher), I am looking out for the read attempt to return one of three values. Zero, to mean that the connection has closed. -1 to mean there’s an error message. Or any positive value as a number of bytes to transfer to file.

Zero means connection closed and not just zero bytes available, as not having data is the error EWOULDBLOCK, in other words “if I were to do this, I’d be blocking the system until something happens”. In other words, nothing to see here, come back later.

So, -1 and EWOULDBLOCK is okay, we can just ignore that (keep on reading until there is something). Any other -1 is a proper error.

Now, what was happening was that I was trapping -1 and any error code other than EWOULDBLOCK and reporting it as an error, this is expected. However, due to some shonkiness in my if clause, if the reply was -1 and it was EWOULDBLOCK, it would fall through to attempt to write -1 bytes to the file. Now, it appears that SDFS might not be able to handle chunked BPUT, so FileSwitch internally would call single BPUT repeatedly. However, -1 would fail the conditionals and drop out. In other words, trying to write -1 bytes would pretty much have no effect. Which is why I never experienced the problem.

Your filing system, on the other hand, does support chunked BPUT. The “Too big” error is literally the first thing the code checks for, and it’s not surprising it had an itty bitty accident given that I just told it to write -1 bytes. Or, in other words, a mere 4,294,967,296 bytes. =:-)

The version linked should have this fixed.

Hi Rick,

The walls are full of water from the recent heavy rains,

Oh , sorry to hear that makes my minor leak which came through the light fitting with suitable bang and smaqoke the other week look like a walk in the park. Hope it gets sorted soon.

you’re not using SDFS are you?

The main drive , SSD, is off SCSI but I have two SDFS icons on the ARMX6 and both are in use along with another SCSI based drive and CDFS.

Good news 0.55c works so thanks for the fix and for the explanation and repeat after me 100 times… :-)

Take care.

Doug

Hope it gets sorted soon.

Oh, it’s been like that for hundreds of years.

You know how people refer to harddiscs as “spinning rust”? Well, around here that’s a more literal description.

Good news 0.55c works so thanks for the fix

Glad to know that bug has been nailed to the wall.

Version 0.56 is available from my site. Not on Store yet (as I might do more tomorrow if the weather is as miserable as today).

• Crash-recovery mechanism – it will look for its files left open in Scrap and close them.
• Nukes cookies all the time now, so fast readers don’t get screwed by the anti-leech mechanism in the site.
• Implemented “What’s new?”. It only shows 20 entries (any more means dealing with JSON). Because the site receives many updates (I counted 67 since midnight), the what’s new content is always refetched. I don’t bother trying to parse or make sense of the chapter numbers. You’ll see that there are at least three different methods of specifying this.
• Un-greyed the “Surprise me”. It was disabled by accident. Didn’t need to be, as it works entirely locally.

http://heyrick.ddns.net/manga/