Rewriting assembler modules in C

beta’s at the current rate (which is NOT every night)

It says nightly on the downloads page?

Indeed it does, and if we had a new version every night we would have 365 a year.
The build process runs every night and only rebuilds if something has changed. The changes that trigger that only arise from approved merges which doesn’t occur every day so the effect is an intermittent overnight rebuild.

What I’m suggesting is a much less predictable build that occurs more regularly that provides a bleeding edge testing.
The more frequent updates arising from changes that have had a less thorough viewing/examination than the current betas get and thus less delay.

A testing stream does sound like something to think about, though I guess it would take some doing at ROOL HQ.

Indeed it would, but I believe the idea of a git repository is that deliberate forking and subsequent selective merging is facilitated.

Indeed it would, but I believe the idea of a git repository is that deliberate forking and subsequent selective merging is facilitated.

On would hope so, given that changes currently get into the codebase via the creation of branches and the raising of merge requests on them.

What you’re describing appears to be exactly the process already in use, except for the automated building of branches which aren’t master.

What you’re describing appears to be exactly the process already in use, except for the automated building of branches which aren’t master.

Branch, singular, was what I was thinking, to reduce the overhead.
Of course if you think the community has the need for more forks for a playful development and probable folding back of the content into the master then fine.

I’m aware that it’s merely an extension of the current process, that was why I suggested it rather than some radical new process.

Of course if you think the community has the need for more forks for a playful development and probable folding back of the content into the master

You’re aware that usually all changes start in their own branch, which is eventually merged (if desired) and deleted? It’s not a case of “if the community has the need for”; that’s how work is already managed.

You’re aware that usually all changes start in their own branch, which is eventually merged (if desired) and deleted? It’s not a case of “if the community has the need for”; that’s how work is already managed.

The words “eventually” and “if desired” should be combined with “not seen by the general user base”.

Part of the reason for things like github is to make things available to the userbase in a shared fashion, part is to make alternate builds easy.

Bear in mind that the average RO user is perfectly capable of testing a ready built item but probably doesn’t have the knowledge to build it nor the tools to build it. IIRC you’re one of the proponents of a cheaper/free development tool set, so you ought to understand the desire by a number of people to perhaps join in.

For those that don’t have the tools, and particularly those without the knowledge of building a ROM, or even a single softload module, testing is something they can do.

More testers, more progress.

@DavidS I guess that ROOL ought to have you down in their database as a registered developer so would be eligible for a half-price update?

Part of the reason for things like github is to make things available to the userbase in a shared fashion, part is to make alternate builds easy.

The primary reason in the case of RISC OS itself is to facilitate easy collaborative development.

For those that don’t have the tools, and particularly those without the knowledge of building a ROM, or even a single softload module, testing is something they can do.

Which is why I also said, and you snipped, “except for the automated building of branches which aren’t master”.

That’s going to be the fun bit to manage, as I predict that anything which isn’t “curated” is likely to result in unhappiness. Simply building nominated branches overnight, every night, and making them available to download is — even with lots of warnings — going to increase the amount of “customer support” required to prevent “misunderstandings”.

Which is why I also said, and you snipped, “except for the automated building of branches which aren’t master”.

Really?
So what was this?

What you’re describing appears to be exactly the process already in use, except for the automated building of branches which aren’t master.

Branch, singular, was what I was thinking, to reduce the overhead.
Of course if you think the community has the need for more forks for a playful development and probable folding back of the content into the master then fine.

I’m aware that it’s merely an extension of the current process, that was why I suggested it rather than some radical new process.

From which you selected the 2nd and 3rd lines of my reply, so at that time you noted the use of the term master

The question for me is, when did I say that the alpha (for want of a better label) should be something that “isn’t curated” at all?
I will aid your search – just look for the actual phrase I used: “The more frequent updates arising from changes that have had a less thorough viewing/examination than the current betas get and thus less delay.”

I’ve made a table of assembler modules, here, with sizes in terms of raw lines.

I’ve made a table of assembler modules, here, with sizes in terms of raw lines.

Which prompts the thought that if one were looking to make space in the ROM then wouldn’t these be ideal candidates for bouncing into the disc image?

PDumper24 	Printing.PDumpers.PDumper24 	1272
PDumperDM 	Printing.PDumpers.PDumperDM 	1307
PDumperIW 	Printing.PDumpers.PDumperIW 	1074
PDumperLJ 	Printing.PDumpers.PDumperLJ 	1398
PDumperE2 	Printing.PDumpers.PDumperE2 	1256
PDumperCX 	Printing.PDumpers.PDumperCX 	2631
PDumperCX2 	Printing.PDumpers.PDumperCX 	2631
PDumperSP 	Printing.PDumpers.PDumperSP 	589
PDriver 	Printing.Modules.PDriver 	1517

Which prompts the thought that if one were looking to make space in the ROM then wouldn’t these be ideal candidates for bouncing into the disc image?

But would Printers need altering to softload the required modules according to which printer definition files were active?

Note that I’ve avoided the PDF acronym problem – and, anyway, aren’t acronyms what you use to hold the roof up when you replace bay windows? Yes, I know it’s not an acronym anyway, liberties for comedic purposes!

After all, ’tis the season to be jolly!

Which prompts the thought that if one were looking to make space in the ROM then wouldn’t these be ideal candidates for bouncing into the disc image?

They already are on disc. When I do the next version, I’ll see if I can get it to mark modules that are in ROM.

Edit: I’ve put in a column now to show the components in ROM.

@Julie
Many thanks for producing this data table – really interesting and useful reading. It highlights the low hanging fruit that developers could tackle first. As you are someone who has recently tackled converting modules from ARM To C code, you are an ideal person to perhaps help other developers tackle other ARM modules.

With your recent Converting modules to C modules wiki page I was thinking a more in-depth walk-through tutorial would also be a good idea for any developers who perhaps just need an extra bit of help to get them started. I do realise I’m nominating you for extra work, when you have done so much already. ‘The willing horse gets flogged the most’ saying comes to mind, so apologies, and feel free to decline, politely or otherwise. Just an idea.

I’ll have a go at writing a diary while I do a translation. It would be too personal for the wiki though; I could put it up as I go along, but I’m not sure where.

@Julie
That would be really great. Thank you. I look forward to it.

I did not, after all, think of anything to write.

If anyone is looking to have a go at one and needs help please let us know.