[Rpcemu] Information for users and developers

Jim Lesurf jcgl at audiomisc.co.uk
Wed May 26 05:32:18 PDT 2010


In article <20100526102559.GA27854 at spod.org>, Peter Howkins
<rpcemu.howkins at marutan.net> wrote:
> On Wed, May 26, 2010 at 10:22:29AM +0100, Jim Lesurf wrote:
> > In article <20100525155455.GA4735 at spod.org>, Peter Howkins
> > <rpcemu.howkins at marutan.net> wrote:
> > 
> > > http://www.marutan.net/rpcemuspoon/
> > 
> > >  I would recommend using a release version of RPCEmu, as opposed to
> > >  using the source code repository (even if you're are a Linux user
> > >  compiling from source), as release versions have had more testing
> > >  and the documentation updated to match them.
> > 
> > I've just looked at the above page and would like to ask about a few
> > points.
> > 
> > I am currently using rpcemu 0.8.2 (not spoon) on my new Xubuntu laptop
> > and it seems fine apart from two minor quirks. One was that getting
> > ArtWorks running seemed awkward for reasons I never understood even
> > though it is now OK.

> I'm afriad that's not really enough info to go on to suggest anything. I
> can successfully use Artworks 1.7 (the latest I have) without any
> noticable issues.

That's Ok. I wasn't asking specifically for a solution as I've found an
arrangement that works. The puzzle is that what works on another Crunchbang
setup doesn't on the Xubuntu one. Even when I copy across the entire rpcemu
directory. Yet all the other RO apps work fine on both. So a puzzle rather
than a problem.

> > The other is that rpcemu insists on using one cpu at the 100 percent
> > level even when all the apps are simply polling and doing nothing. Not
> > particularly good news for a laptop's batteries.  :-)

> Just like RISC OS on a real RISC PC, RISC OS runs the CPU flat out, I
> believe my brother investigated and had success using a new sleeping
> module that used the 'Portable' SWI, and I'll bump the testing of this
> up the list of things to do, as that had the effect of dropping CPU to
> about 5% without the loss of mouseclicks.

> > My first point is that the above page seems to have binaries for
> > Windows and Mac, but not for Linux. Can it also have a binary version
> > for Linux, please? Or is that a problem for some reason?

> Unfortuanately there are just too many versions of Linux (CPU
> architecture (x86/x64/Sparc/ARM/Mips/etc), distribution
> (Ubuntu/redhat/debian/puppy/gentoo/etc x 100), releases) to create a
> universal binary that would run on all of them.

I would suspect that at present a debian/unbuntu package would be useful
for the largest portion of Linux users. Must confess that when I tried
puppy I quickly decided it was a PITA compared with the Ubuntu versions,
and ended up choosing Crunchbang for my ancient laptop. (Again IIUC a
Ubuntu/debian type of distro.)


> However if people are willing to contibute compiled binaries for their
> favourite system (as Paul Stewart has done for Puppy Linux) we can host
> them. For example would you be willing to help by compiling up a Ubuntu
> binary for others to use?

In principle, yes I'd be pleased to do that, or ar least give it a try!

However in practice I currently have no idea what I'd have to do, or how
much time/effort it would take me! Never produced any packaged binaries for
a distro. My few Linux programs thus far are very simple ROX apps that just
open a terminal and save out a file. So just a tgz of the complete ROX app.
If curious to see the limits of my ability, examples are on

http://www.audiomisc.co.uk/software/index.html

If you look at these you can see they are fairly modest and not exactly
well written. Just sort-of work, mostly.  :-)

> > Secondly, as a (fairly new) user rather than someone involved in
> > development I don't find the Release Notes are that easy to understand
> > from the POV of being able to tell, "will I gain something I want from
> > upgrading to the latest version?"  (e.g. does a newer version give
> > control over the cpu loading *without* the problem of losing
> > mousclicks or slugging actual performance?)[1]

> So far every release has had user facing improvements, be it bug fixes
> or new features. Some of them may seem a little arcane perhaps, but
> holding back on very old versions isn't going to do you any favours,
> not least the ability of people to support you. Fixes that might not
> seem obvious are often improving the accuracy of the emulator, meaning
> more software (and OS versions for that matter) are likely to run.

I accept that, and the sense of keeping up with improved versions. Against
it, I mainly use a real Iyonix and ROX on linux for most purposes. So at
present I'm just using rpcemu with an 'eye to the future' as I'd like to
learn more about it, and perhaps encourage its use and development. In time
it may be my main way to use RO apps. And I plan to use it to 'publicise'
using RO elsewhere. e.g. the above software page will be mentioned in an
article in a hifi mag in a few months time, and may get some people
clicking though to find out about rpcemu.

That prompts me to ask: At present the above webpage gives a link to the
non-spoon page on rpcemu. Is that OK as the best place to direct people to
who have not previously known about RO and rpcemu?

Thus far my use of rpcemu has only consisted of installing it and trying it
out with my 'main use' apps (TechWriter Vector AW etc) to ensure they seem
to work fine. Then writing an article for 'Archive' about it so more people
know it exists and are encouraged to give it a go.

In terms of support I'd suspect I may be most useful in terms of trying out
things and then writing articles and documents to attract/encourage/enable
users. Afraid my programming skills are minor - particularly on Linux!
However I am currently in the process of writing some ROX and perhaps more
rpcemu items for 'Archive' which should also eventually appear on the web.

> > Another point is that the page seemed to me to be saying that the
> > spoon editions should be regarded as 'alpha', but in your email you
> > recommend that as users we should take versions from the page.

> In my opinion, all versions of RPCEmu, whether Spoon, from riscos.info
> or even older are Alpha, if you've not been able to crash it, you've
> not been trying hard enough ;-). The Spoon pages explicitly state this
> as previously there has been a fair bit of user disapointment (and lost
> data) from people expecting a 100% finished product in the past. The
> level of stability is very dependant on the apps that people run, as
> such some can honestly state "It works very well for me", however I
> want to encourage people who have problems to come forward, as it would
> be an impossible task for us to test every bit of RISC OS software on
> our own.

Would it help clarify if we collected a list of 'what works and what
crashes' in terms of RO apps, etc? I am still myself confused about this,
and about which versions of RO work OK or not. For obvious reasons I'd love
to have an emulator that was more like 'Iyoemu' in terms of things like
screen mode sizes, etc.  8-]

If someone can outline what would be involved in producing something like a
binary pakage for Ubuntu (and hence I assume debian) I can then decide if I
am up to trying that. At present I have no idea if I would be capable. In
the meantime, when I get the necessary 'round tuit' I'll try installing the
latest sourced spoon version and see how I get on.

Slainte,

Jim

-- 
Electronics  http://www.st-and.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc  http://www.audiomisc.co.uk/index.html




More information about the Rpcemu mailing list