Android application to manipulate sd image from the site

If you look at the threads on multi-core / multi-threading, they’ve been running for years, but as far as I can tell nobody has thought to build a project plan on how to achieve them.

As far as I’m aware there hasn’t been a concensus for how to move forward. Me? I support the idea of mini kernels on the other cores which run independent and talk to the host in a Tube-like manner. It may not be the best in the long term but I think it is the most realistic to actually be implemented and perhaps the least disruptive to RISC OS as it currently is.

Looking at them as an overall task, they’re near impossible but broken down into a detailed project with hundreds of smaller tasks, they’re all pretty trivial to implement.

Are you volunteering?

The root problem here is that next to nobody understands the RISCOS source

The source isn’t the hard part. It is understanding what is going on that is sometimes difficult. I’ve read the entire thing about Filecore and file system structure and I’m still lost.

and build flow diagrams showing interdependencies. This needs to be done under an SPSS / QA type framework so analysis of code changes can be performed and test plans built following all code changes.

I think the problem is one of time. The people capable of that may feel that their time is better spent developing the system, fixing problems, etc etc.

I’d expect to see every other line of code have a comment so you can read what’s going on in English and not have to decode registers etc. The simple rule here is, if your mother can’t follow it – you’ve not documented it enough!

Every other line? I’d consider that over commented unless something devious is going on. For example if you are loading a FSCB into R7, you shouldn’t need to point this out every time you reference R7. A person that can’t remember that probably shouldn’t be messing with the FS. ;-)

aaaa

aaaa

aaaaa

aaaaa

it seems the system doesn’t even have a real way to know if all the modules that an application require are available

For the majority of applications, RMEnsure commands are used in the application !Run files to ensure that the correct modules and versions are available for the application. Why should the system itself need to know?

AFAIK there is no direct SWI equivalent of RMensure which does mean making that type of check in Modules is not so simple.

For the majority of applications, RMEnsure commands are used in the application !Run files to ensure that the correct modules and versions are available for the application. Why should the system itself need to know?

For no reason :) RISC OS has a RISC approach, where complexity is deferred to the application (a RISC processor deferred complexity to code). IMHO, for example, encapsulation should be provided by the needed SDK, not RISC OS itself. If it’s a core functionality, when it’s not an option any more. In a way, you loose modularity here.

It take time to get used with RISC OS and RISC philosophy :)

aaaa

Does the system allow for example to unload shared module automatically when they are not needed ?

The application, on closing, could RMKill any module it had loaded but how could you be sure that no other application was using that module?

The system doesn’t need to know this for running application if the application itself check for it,

Ah, but if you were thinking of killing off a loaded module you’d need to know what, if any, other applications are using it. You would almost need to have a table of registered applications for each module and only allow the kill when there were no registered items.

http://gerph.org/riscos/ramble/modularity.html

I think I would have to raise a flag over this: Users are highly resistant to upgrading, because the system has been able to be modularly extensible (and also because that is just the way that they are). It is an interesting perspective to have on a system where traditionally the operating system was supplied on ROM – and changing ROM is expensive and complicated (opening up a machine and swapping out ROMs is no big deal for me¹ but it was a deal-breaker for others).
I have only ever bought two ROM sets in my life. RISC OS 3.10 when it was released as ROMs (as it offered a lot over RISC OS 2) and RISC OS 3.7 (for my RiscPC which came with 3.6; because of better networking and apps in ROM).
I never upgraded to RISC OS 4 because at the times when I was around the scene, it didn’t really offer enough incentives that were personally appealing to justify the price.
Things are different these days. Okay, we have a choice of one version of RISC OS, but it’s pretty easy to install the stable releases as and when, or roll with the nightlies; and asides from cost (or lack of), the installation is immediate (no waiting for stuff to arrive in the post) and simple – just place this file here and boot it. If you thought to keep a copy of the previous image, you could even roll back if you wanted.
Okay, the major increments may be a bit harder and involve messing with !Boot, but that’s all pretty easy compared to delving into the machine. It’s been a long time since I last had my RiscPC open. I’m trying to imagine how much stuff (podules etc) I’d need to move just to be able to see the OS ROMs.
It might sound like random excuses, but it all does factor into the decision, which basically boiled down to “if the current setup ain’t broke…”.

That may have been part of why users were “highly resistant”. Either that, or they just don’t conduct well.

His complaint about random junk in “page zero” being accessed from all over the place by random modules – that is absolutely Beeb-style coding. The ARM doesn’t have a special addressing mode to privilege/favour the first page in memory. So this stuff probably should have been held in a proper part of allocated module workspace and accessed by other modules using a proper API. Instead of claiming the first 32K and stuffing all sorts of things in there. Page zero is a horror show. :-)

it seems the system doesn’t even have a real way to know if all the modules that an application require are available or not when loading an application.

As far as I am aware, the system has no way of knowing what resources an application requires when loading it. You, as the programmer, should be aware of your dependencies so you can place the necessary *RMEnsure lines into the !Run file. The program should run without problems once you have established that the modules necessary are all present and loaded.

That the order in which they are loaded in the rom can trigger bugs or not due to this kind of issues.

That’s a really specialist problem, and is nothing to do with applications; it was specifically pointed out in Justin’s ramble as an example of the side effects of collusion between modules. Modules that directly depend on stuff inside other modules need to be started in the correct order.

However, even without the collusion, you cannot say anything about the problems regarding the order of modules in ROM because that is the operating system. Only once the last module has started is RISC OS ready to start acting as a proper OS. Before that, things will by necessity have dependencies.

Let’s try an example or two. !Edit, the ever-famous simple text editor (upon which I have coded most of the BASIC that I have ever written, and my entire website up until around 2004ish).
Edit lives in a fake filing system called ResourceFS. Edit cannot install itself until ResourceFS has started. Which cannot install itself until FileSwitch has started. Amusingly it doesn’t depend so much upon CLib as the offsets are hardcoded by the linker; but it’s probably a good idea if the library has at least initialised itself before being used!
DOSFS needs FileCore and FileSwitch. SDFS probably needs those plus SDIODriver. The SDFSFiler needs all of what SDFS needs as it needs SDFS itself.

Do you see why rearranging the placement of modules is tricky?

It’s really not something made with a clear hierarchy in mind,

Running user add-ons in kernel level is not something made with a clear anything in mind. It – the ability to arbitrarily “upgrade” many components of the operating system (held in ROM) was pretty impressive back in the late ‘80s; and the system design as a whole owes a lot to how the BBC MOS worked (think of modules like paged ROMs). It does not, unfortunately, scale to today’s expectations.
Though, as annoying/weird as this might seem in 2015 – we need to get over it. It isn’t going to change. Well, it can, certainly. But the result would not be RISC OS. It would likely end up as some nondescript POSIXish *nix clone. There’s enough of them in the world already…

Going back to this:

it seems the system doesn’t even have a real way to know if all the modules that an application require are available or not when loading an application.

Neither does Windows.

Top of a VB module:

Public Declare Function PtrIIC_Enquire Lib "PtrIIC.dll" () As Integer

A little further down, in the initialisation routine:

  Err.Clear
  On Error Resume Next
  Value = PtrIIC_Enquire
  If (Err.Number <> 0) Then
    ' cope with damaged installations
    MsgBox "Whinge whinge whinge Oi! You! Where's my bl**dy DLL?"
    GoTo MissingMod
  EndIf

Obviously that isn’t the actual message, but it shows that neither VB nor Windows have a mechanism for “knowing” what dependencies you add in, so you have to either specifically check their presence, or be like most coders and just crash if the DLL isn’t present… Grr…

So, that RISC OS doesn’t have this either isn’t really a big surprise.

¹ I lie. I thought the b***ard RISC OS 2 ROMs were welded in. I’m surprised I didn’t trash my A3000 trying to get the things out…times four.

aaaa

aaaaa

Ah, but if you were thinking of killing off a loaded module you’d need to know what, if any, other applications are using it. You would almost need to have a table of registered applications for each module and only allow the kill when there were no registered items.

Yeah well that’s in big part the point of having the system being able to figure dependency chain automatically :)

Grr-Argh!

One of the versions of Windows that I used – I suspect W98SE – had a nice feature that would prevent your system resources directory filling up with rubbish. If you were to uninstall an application and it was the last registered user of a resource DLL (i.e. the installer “installed” the DLL and was now “uninstalling” it), the operating system would tell you that there were no other programs using the DLL and would you like to delete it?

You learn pretty quickly to always answer NO because a toddler that can’t even walk could count better than Windows. And trying to reinsert a deleted DLL when you realise half a dozen programs still require it… it’s a mess. The first part of the fun is actually getting a copy of the DLL – sometimes running an installer and not clicking on it will leave the files unpacked (but possibly still compressed) in TEMP. The second part of the fun is wrestling with regsvr32 where it does what it damn well pleases and not what you asked it. The third part of the fun is the hoping/praying stage where you run the program to see if it worked. The fourth part of the fun is firing up RegEdit and trying to remember where in the registry the DLL installation count is held so you can enter a big value like 9999 so you won’t be bothered by this problem again…at least, not for that DLL.

aaaa

With the com system, an application can require directX7 interface, and have a directx7 interface, and knowing version of interface and that sort of thing after the application is actually loaded, dynamically.

…provided that you stick to the COM system. A lot of the Windows API and many third-party DLLs (and probably little ones a person makes themselves) are outside of the COM world. VB.Net calls this “unmanaged” and says that they are accessed using the “PInvoke” method. The documentation strongly implies that all of the safety nets do not exist for unmanaged (non-COM) code.
VB5/6 is older, but probably works along the same lines. Things are looked after automatically if they are embedded components or references (including so-called ActiveX controls), but when you are calling the Windows API, you’re pretty much on your own. Declare will set it up so you can call the library function as if it was a procedure, but it is up to you to verify that it is there, that it makes sense, and the data passed to and fro. If I remember correctly, GDI+ is a good one for weird parameter passing.

Err… Relevance here? DLLs are sorta like modules. Or something. Um.

that loads massive amount of plugin that make the whole computer shake on hard drive read and the cpu heat increase of 15/20% while it resolve and load up the hundred of dll =)

Whoa. That sounds pretty epic. Not even Firefox with <clicky-clicky> 887 tabs (most loaded inactive via BarTab) starting up makes that kind of physical distress occur.

I suggest a different computer. Or maybe a different browser. Or maybe both. ;-)

aaaa

aaaa

aaaaa

Getting waaaay off topic now…

But now, if you want to make application that work, do not crash, being able to use dizains of dll, plugins, components, like rich html application, well you can, and rather easily with visual studio,

…only so long as the stuff you want to use is COM. The Windows API is not so any calls to Windows functions that to not have a handy COM equivalent (which is probably most of them) will be unprotected unsanitised un-whatever. All of the nice friendly tidy environment breaks the moment you want to do something out of remit of the proscribed methods and functions.

It’s not like it has to construct a zillion polygon mesh from a compressed packed archive or something like this.

Mmm, like trying to get MikuMikuDance running. How hard is it to render a low-res bit of (raytraced?) video? ;-)

After i’m not sure what you do with your web browser,

A lot of “oh, that looks interesting, I’ll look at it later”. After a few months of that, you realise your “look at it later” list is about to hit four digits.
I periodically dump the entire lot to bookmarks and, well, “later” never arrives as I’m looking at something else.

but try to have even only 4 tabs,

Hah! 4 tabs is for wimps. My phone has more than 4 tabs open (ROOL, TheRegister, TVTropes, HorribleSubs, and some other random things).

load up complex page, that do ajax, javascript, canvas, webgl, use flash, make dynamic request, with the developper tools network tracking and js debugger, then close page, reopen them, close them reopen them. Or refresh the page if you prefer.

I have no idea about half of that stuff, and the other half would probably be blocked by ABP+ and/or NoScript.
Amazon (full site), that takes a lot of processing oomph. So does eBay.

Do this like for 4h like to develop plugins,

How about several months between reboots as the machine can go to standby and trickle off battery/mains. Does that count?

tell me how many memory it use ?

It is Firefox. It uses loads.

How much is in the swap ?

Nothing. There is no swap (C: and D: are SSDs, E: is a SD card). The spinning rust is a USB drive and it’s kind of slow for a USB3 special-whoo-hoo-fast drive.

How long it take to move all this fragmented pile of virtual page and dll ?

It doesn’t. That’s why I say Windows’ virtual memory management is rubbish. The computer is a bit slow, but that’s because the system drive (C:) only has about 150MiB free on it. It’s a 4GiB drive and between Windows, My Documents and Settings, and iTunes, the thing is pretty much full.

If you have a large enough amount of memory (at least 2GiB, pref. more), why not try disabling swap and seeing if your machine runs any better? It’ll go a bit pear shaped if you run out of memory (random stuff will just “die”) but when it is running it ought to run a heck of a lot faster as it won’t be swapping stuff to disc.

And, back sort of closer to the general direction of the topic (maybe).

All of the nice friendly tidy environment breaks the moment you want to do something out of remit of the proscribed methods and functions.

We have a handy SWI that will tell you if a name or SWI number matches up with anything. Easy to check if resources are loaded.

you realise your “look at it later” list is about to hit four digits.

Our browser isn’t that smart, so this isn’t an issue on RISC OS.

load up complex page, that do ajax, javascript, canvas, webgl, use flash, make dynamic request, with the developper tools network tracking and js debugger, then close page, reopen them, close them reopen them. Or refresh the page if you prefer.

Ditto previous reply.

It is Firefox. It uses loads.

NetSurf is memory-hungry by RISC OS standards, but a mere blip on the radar compared to “big browser” on other platforms.

How much is in the swap ?

RISC OS is saved that trauma too. Anyway, there’s plenty of free memory, unless your name is David. ;-)

aaaa

aaaa

aaaa

Didn’t watch everything on the site, but for example in the section about the filer, i think he is focusing too much on superficial things, ok rounded icons, adding tabs, moving menu, not saying it’s not important, but to me it’s not necessarily at this level that i would expect someone working as ‘system developer’ would be working on, the only purpose should be to provide software infrastructure to do this, he seems more to have a user based point of view, to correct superficial things, rather than truly archictecture design.

[…]

More often than not, it’s the long term goal that gets lost whilst people focus in trivial issues as you point out.

IIRC, Justin made it very clear somewhere in his rambles¹ that there were, in his opinion, plenty of more important things to do than implement rounded buttons on the desktop, but that in the end it was trivial stuff like that which got users excited and parting with their cash for Select subscriptions. And ROL had neither the luxury of a large team of developers who could split the workload, nor such a large pool of paying customers that they could afford to ignore any of them².

¹ I’m sure I remember it from finally reading them a few months ago, but I can’t at present track it down.

² At least, not after they’d upset those of us who had gone down the 32-bit route.