Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.misc > #2165 > unrolled thread

VRPC on a USB pen

Back to article view | Back to comp.sys.acorn.misc

Contents

  VRPC on a USB pen druck <news@druck.freeuk.com> - 2011-10-29 16:33 +0100
    Re: VRPC on a USB pen David Pitt <pittdj@pittdj.co.uk> - 2011-10-29 16:52 +0100
      Re: VRPC on a USB pen Stuart <Spambin@argonet.co.uk> - 2011-10-29 18:12 +0100
      Re: VRPC on a USB pen patric <patric@invalid.net> - 2011-10-29 18:11 +0000
        Re: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-30 22:25 +0000
          Re: VRPC on a USB pen Folderol <folderol@ukfsn.org> - 2011-10-30 22:37 +0000
            Re: VRPC on a USB pen Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-10-31 01:00 +0000
          Re: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-10-30 22:36 +0000
          Re: VRPC on a USB pen Chris Hughes <news@noonehere.co.uk> - 2011-10-31 18:53 +0000
            Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 20:09 +0100
              Re: VRPC on a USB pen fwibbler <thedoctor@thedeathzone.free-online.co.uk> - 2011-11-01 11:20 +0000
                Re: VRPC on a USB pen Bob Latham <bob@sick-of-spam.invalid> - 2011-11-01 12:02 +0000
                  Re: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-01 12:31 +0000
                    Re: VRPC on a USB pen Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-01 15:52 +0100
                      Re: VRPC on a USB pen "Ste (news)" <steve@revi11.plus.com> - 2011-11-01 18:12 +0000
                        Re: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-01 22:14 +0000
                        Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 18:02 +0100
                          Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-02 18:04 +0100
                          Re: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-02 22:08 +0000
                  Re: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-11-01 12:54 +0000
                Re: VRPC on a USB pen Stuart <Spambin@argonet.co.uk> - 2011-11-01 12:23 +0000
                  Re: VRPC on a USB pen fwibbler <thedoctor@thedeathzone.free-online.co.uk> - 2011-11-01 16:47 +0000
                Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 21:06 +0100
              Re: VRPC on a USB pen Michael Gerbracht <nospam@cityweb.de> - 2011-11-04 17:12 +0000
                Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-04 20:00 +0100
                  Re: VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-11-04 20:36 +0000
                    Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-05 06:20 +0100
                      Re: VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-11-05 06:24 +0000
                  Re: VRPC on a USB pen Michael Gerbracht <nospam@cityweb.de> - 2011-11-05 16:19 +0000
                    Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-05 17:54 +0100
                      Re: VRPC on a USB pen Michael Gerbracht <nospam@cityweb.de> - 2011-11-06 16:37 +0000
                        Re: VRPC on a USB pen Ron Briscoe <ron.briscoe@blueyonder.co.uk> - 2011-11-06 20:09 +0000
                          Re: VRPC on a USB pen Michael Gerbracht <nospam@cityweb.de> - 2011-11-13 10:51 +0000
                            Re: VRPC on a USB pen Russell Hafter News <see.sig@walkingingermany.invalid> - 2011-11-19 10:12 +0000
                    Re: VRPC on a USB pen Ron Briscoe <ron.briscoe@blueyonder.co.uk> - 2011-11-05 21:44 +0000
                      Re: VRPC on a USB pen Dr Peter Young <pnyoung@ormail.co.uk> - 2011-11-06 09:24 +0000
                        Re: VRPC on a USB pen Ron Briscoe <ron.briscoe@blueyonder.co.uk> - 2011-11-06 19:59 +0000
                          Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-07 04:04 +0100
                            Re: VRPC on a USB pen cferris@freeRemoveuk.com.invalid - 2011-11-07 10:04 +0000
                              Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-07 18:06 +0100
                              Re: VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-11-07 18:59 +0000
                                Re: VRPC on a USB pen SG nws <nwsgrp@ntlworld.com> - 2011-11-07 19:24 +0000
                                  Re: VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-11-07 21:25 +0000
                          SmartMenu - was: VRPC on a USB pen David Pitt <pittdj@pittdj.co.uk> - 2011-11-07 05:33 +0000
                            Re: SmartMenu - was: VRPC on a USB pen Dr Peter Young <pnyoung@ormail.co.uk> - 2011-11-08 21:54 +0000
                              Re: SmartMenu - was: VRPC on a USB pen Doug Webb <doug.j.webb@btinternet.com> - 2011-11-08 22:11 +0000
                                Re: SmartMenu - was: VRPC on a USB pen David Pitt <pittdj@pittdj.co.uk> - 2011-11-09 06:38 +0000
                              Re: SmartMenu - was: VRPC on a USB pen David Pitt <pittdj@pittdj.co.uk> - 2011-11-09 06:20 +0000
                              Re: SmartMenu - was: VRPC on a USB pen Richard Ashbery <basura@invalid.addr.uk> - 2011-11-09 13:29 +0000
                                Re: SmartMenu - was: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-09 16:34 +0100
                                  Re: SmartMenu - was: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-09 16:59 +0000
                                    Re: SmartMenu - was: VRPC on a USB pen Richard Ashbery <basura@invalid.addr.uk> - 2011-11-09 19:40 +0000
                                      Re: SmartMenu - was: VRPC on a USB pen Chris Hughes <news@noonehere.co.uk> - 2011-11-09 21:45 +0000
                                Re: SmartMenu - was: VRPC on a USB pen Dr Peter Young <pnyoung@ormail.co.uk> - 2011-11-09 14:56 +0000
                                Re: SmartMenu - was: VRPC on a USB pen druck <news@druck.freeuk.com> - 2011-11-09 20:32 +0000
                                  Re: SmartMenu - was: VRPC on a USB pen Dr Peter Young <pnyoung@ormail.co.uk> - 2011-11-09 22:03 +0000
                                    Re: SmartMenu - was: VRPC on a USB pen druck <news@druck.org.uk> - 2011-11-09 22:32 +0000
                                    Re: SmartMenu - was: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-11-09 23:02 +0000
                                      Re: SmartMenu - was: VRPC on a USB pen Vince M Hudd <vinceh@softrock.co.uk> - 2011-11-10 15:44 +0000
                                        Re: SmartMenu - was: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-11-10 20:13 +0000
                                          Re: SmartMenu - was: VRPC on a USB pen Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-11-10 23:36 +0000
                                            Re: SmartMenu - was: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-11 05:45 +0100
                                              Re: SmartMenu - was: VRPC on a USB pen Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-11 16:40 +0100
                                                Re: SmartMenu - was: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-12 02:10 +0100
                                                  Re: SmartMenu - was: VRPC on a USB pen Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-11-12 07:48 +0000
                                                  Re: SmartMenu - was: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-12 09:18 +0000
                                                  Re: SmartMenu - was: VRPC on a USB pen Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-12 11:44 +0100
                                          Re: SmartMenu - was: VRPC on a USB pen Vince M Hudd <vinceh@softrock.co.uk> - 2011-11-11 09:32 +0000
                                            Re: SmartMenu - was: VRPC on a USB pen Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-11-13 12:22 +0000
                                              Re: SmartMenu - was: VRPC on a USB pen Steve Fryatt <news@stevefryatt.org.uk> - 2011-11-13 13:30 +0000
                                                Re: SmartMenu - was: VRPC on a USB pen Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-11-15 01:20 +0000
                                              Re: SmartMenu - was: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-13 22:11 +0100
                                                Re: SmartMenu - was: VRPC on a USB pen Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-14 19:08 +0100
                                                Re: SmartMenu - was: VRPC on a USB pen David Pitt <pittdj@pittdj.co.uk> - 2011-11-14 19:25 +0000
                                        Re: SmartMenu - was: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-11 05:38 +0100
                                    Re: SmartMenu - was: VRPC on a USB pen Richard Ashbery <basura@invalid.addr.uk> - 2011-11-12 13:31 +0000
                  Re: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-06 12:56 +0000
            Re: VRPC on a USB pen Jess <phantasm_39@hotmail.com> - 2011-11-01 10:50 +0000
      Re: VRPC on a USB pen druck <news@druck.freeuk.com> - 2011-10-29 19:39 +0100
        Re: VRPC on a USB pen Tim Hill <tim@invalid.org.uk> - 2011-10-29 20:24 +0100
    Re: VRPC on a USB pen Sion <s.cleaver@mail.com> - 2011-10-29 09:46 -0700
      Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-29 20:40 +0200
      Re: VRPC on a USB pen druck <news@druck.freeuk.com> - 2011-10-29 19:41 +0100
        Re: VRPC on a USB pen "Ste (news)" <steve@revi11.plus.com> - 2011-10-30 21:49 +0000
    Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-29 20:26 +0200
      Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-29 20:47 +0200
        Re: VRPC on a USB pen Tim Hill <tim@invalid.org.uk> - 2011-10-29 20:28 +0100
          Re: VRPC on a USB pen druck <news@druck.org.uk> - 2011-10-29 23:40 +0100
            Re: VRPC on a USB pen Tim Hill <tim@invalid.org.uk> - 2011-10-29 23:45 +0100
              Re: VRPC on a USB pen druck <news@druck.org.uk> - 2011-10-30 00:00 +0100
                Re: VRPC on a USB pen Tim Hill <tim@invalid.org.uk> - 2011-10-30 00:03 +0100
                Re: VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-10-30 06:38 +0000
        Re: VRPC on a USB pen Stuart <Spambin@argonet.co.uk> - 2011-10-29 23:52 +0100
        Re: VRPC on a USB pen Andrew Hodgkinson <ahodgkin@rowing.org.uk> - 2011-10-31 17:22 +0000
          Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 20:12 +0100
          VRPC on a USB pen Dave Symes <dave@triffid.co.uk> - 2011-10-31 21:21 +0000
            Re: VRPC on a USB pen Andrew Hodgkinson <ahodgkin@rowing.org.uk> - 2011-11-14 13:15 +0000
      Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-29 21:21 +0200
        Re: VRPC on a USB pen druck <news@druck.org.uk> - 2011-10-29 23:52 +0100
          Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-10-31 00:07 +0100
            Re: VRPC on a USB pen Theo Markettos <theom+news@chiark.greenend.org.uk> - 2011-10-31 01:05 +0000
      Re: VRPC on a USB pen Chris Hughes <news@noonehere.co.uk> - 2011-10-31 18:48 +0000
        Re: VRPC on a USB pen Rick Murray <heyrickmail-usenet@yahoo.co.uk> - 2011-11-01 20:23 +0100

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

#2430 — Re: SmartMenu - was: VRPC on a USB pen

The following bytes were arranged on 10 Nov 2011 by Steve Fryatt :

> On 10 Nov, Vince M Hudd wrote in message
>     <mpro.lugbpk00aretu03i0.vinceh@softrock.co.uk>:
>
> > Steve Fryatt <news@stevefryatt.org.uk> wrote:
> >
> > [...]
> >
> > > I hate to say it, but this is *precisely* the problem that package
> > > managers are designed to sort out...
> >
> > Except that all the package management in the world won't help if the
> > writer of the software shoves the module in the application directory and
> > loads it from there - which is what seems to be happening here.
>
> It's a lot simpler to say "this package is dependent on the WimpSWIVe
> package" (to the package manager, not the user) and point the !Run file to
> the place that the WimpSWIVe package installs the module than it is to try
> and write instructions to tell the user how to set it all up manually.

Except that the package manager, if it's written properly, will
undoubtedly install it in System:Modules.  Which we have already
established more than one developer seems to have a blind spot for
loading modules from in the first place.

Artificial Intelligence will never be a match for Human Stupidity. ;-P

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#2434 — Re: SmartMenu - was: VRPC on a USB pen

On 11/11/2011 00:36, Martin Bazley wrote:

> Except that the package manager, if it's written properly, will
> undoubtedly install it in System:Modules.

So what we need is a dependency-aware package manager where an 
application can be installed, and as a part of this, the required 
dependencies can be pulled from a central resource to ensure not only 
can you get the latest version, but also one appropriate for your 
system. This will, then, be inserted into the *correct* place - perhaps 
this location specified in the HTTP response header, like:

HTTP 200 OK
Content-Length: 12345
Content-Type: application/binary
Content-Name WimpSwiV
X-Put-Here-Stupid: <pathpathpath>
etc.

:-)


What we need, besides writing that, is to define a "dependency" file to 
hide inside the application directory, which is laid out like:
MODULE SharedCLibrary 5.03
MODULE FrontEnd 1.23
- in other words:
<type><space><name><space><version>
The type allows for other potential stuff, such as "FONT" or "UNICODE" 
(for a Unicode font).

This can then be pulled out of the archive and automatically scanned to 
check everything is present.

In other words, a super-sexy RISC OSified nice and friendly version of 
what Linux kinda already does. ;-)


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2446 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ebca885$0$2494$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 11/11/2011 00:36, Martin Bazley wrote:

>> Except that the package manager, if it's written properly, will
>> undoubtedly install it in System:Modules.

> So what we need is a dependency-aware package manager [...]

Like the one we already have? When reading the remainder of your 
posting I could not help wondering whether you had a look at the 
package management solution that has been available for years.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#2458 — Re: SmartMenu - was: VRPC on a USB pen

On 11/11/2011 16:40, Martin Wuerthner wrote:

>> So what we need is a dependency-aware package manager [...]
> Like the one we already have? When reading the remainder of your
> posting I could not help wondering whether you had a look at the
> package management solution that has been available for years.

I am aware of RiscPkg. I was thinking aloud at something generic which 
is capable of resolving application requirements in a manner quite 
distinct to "bung it all into the archive, let the installer sort it out".
And yes, this does imply internet connectivity. :-)


I did note in the help:
--8<--------
   As a safety measure, RiscPkg will not overwrite files that already
   exist. Instead, it displays all conflicting pathnames in a window and
   cancels the installation. This is most likely to happen for modules
   and fonts. If you wish to proceed with the installation then you must
   either delete the conflicting files or move them to another location.
   (The latter course of action is recommended in case you wish to
   revert.)
--8<--------

Which would imply that the package manager is not yet up to *upgrading* 
(with optional revert backup?) system resources - thus again requiring 
the user to potentially need understand the !Boot structure in order to 
delve in and delete/rename the module.

Perhaps it wouldn't be too difficult to maintain something like:
   Choices:RiscPkg.Backup.Module.<moduletitle>.<version>.<file>
so if replacing Xyzzy version 1.23 with 1.24, it will know the old one 
can be pulled out of:
   Choices:RickPkg.Backup.Module.Xyzzy.1-23.Xyzzy
[note: I specify Choices instead of Scrap as rollback backups are a 
little less temporary than the usual stuff in Scrap]


Is the existent package manager capable of coping with *different* 
modules depending on OS version? And installing them into the correct 
place (as opposed to the fallback of dumping into !System.Modules and 
hoping)?


I've just had a play, and it is a nice start, but needs a lot of polish, 
for example:
   * Is it just me, or does it seem to revert to OS font when you use
     the "Package "blah" >" submenu? Thankfully F12-Enter restores.
   * Double-clicking a package ought to open a More Info window which
     describes the package better than a line whizzing off the screen.
     It should also tell you what status "hua ia" means in actual words.
   * ^I doesn't.
   * Having used package management on Ubuntu, I know that "Commit" was
     the option to "download this stuff and install it". Hardly
     intuitive for a newbie, though.

Has it really not been developed since 2004, or is the version linked 
off the site an old one?
<rummage>
Ah, there's a newer one. But RiscPkg wouldn't attempt to update itself - 
conflict with existing files (see above quote).
<quit>
<rename>
<restart>
<commit>
<quit>
<delete-old>
<start-new>

Ah, that's better. Still doesn't respond to keypresses, but it now has a 
rudimentary info window and no longer messes up the font thing. This 
definitely has potential.


Hmmm...

   NettleSSH
   <install>
   <double-click>
   "File 'System:Modules.Network.SockWatch' not found"

...which is sort of the point I was making. Looking in the package file, 
there's a file describing what it is, and a file detailing the 
copyright, but there's no file listing specific DEPENDENCIES for RiscPkg 
to deal with. Not like "Depends: <otherpackage>", but actual resource 
(module, font, etc) level where your system can be queried to see what 
you have and it updated if necessary from a central resource.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2460 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ebdc772$0$5663$ba4acef3@reader.news.orange.fr>
 on 12 Nov 2011 Rick Murray  wrote:

> On 11/11/2011 16:40, Martin Wuerthner wrote:
> 
> >> So what we need is a dependency-aware package manager [...]
> > Like the one we already have? When reading the remainder of your
> > posting I could not help wondering whether you had a look at the
> > package management solution that has been available for years.
> 
> I am aware of RiscPkg. I was thinking aloud at something generic which 
> is capable of resolving application requirements in a manner quite 
> distinct to "bung it all into the archive, let the installer sort it out".
> And yes, this does imply internet connectivity. :-)

[snip]

> I've just had a play, and it is a nice start, but needs a lot of polish, 
> for example:

Try PackMan -- it uses the same underlying package system, but *is* a more
polished interface which is being actively maintained.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [next] | [standalone]

#2462 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ebdc772$0$5663$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> Perhaps it wouldn't be too difficult to maintain something like:
>    Choices:RiscPkg.Backup.Module.<moduletitle>.<version>.<file>
> so if replacing Xyzzy version 1.23 with 1.24, it will know the old one
> can be pulled out of:
>    Choices:RickPkg.Backup.Module.Xyzzy.1-23.Xyzzy
> [note: I specify Choices instead of Scrap as rollback backups are a
> little less temporary than the usual stuff in Scrap]

It uses a packages folder in resources, so that would be a better 
location.

Hopefully Packman will implement something like this. (If it hasn't 
already.)

-- 
Jess                   Iyonix

[toc] | [prev] | [next] | [standalone]

#2463 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ebdc772$0$5663$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 11/11/2011 16:40, Martin Wuerthner wrote:

>>> So what we need is a dependency-aware package manager [...]
>> Like the one we already have? When reading the remainder of your
>> posting I could not help wondering whether you had a look at the
>> package management solution that has been available for years.

> I am aware of RiscPkg. I was thinking aloud at something generic which
> is capable of resolving application requirements in a manner quite
> distinct to "bung it all into the archive, let the installer sort it out".

... which is not at all what RiscPkg does. Quite to the contrary. So, 
I cannot see in which point your thinking offers anything that RiscPkg 
does not.

> I did note in the help:
> --8<--------
>    As a safety measure, RiscPkg will not overwrite files that already
>    exist. Instead, it displays all conflicting pathnames in a window and
>    cancels the installation. This is most likely to happen for modules
>    and fonts. If you wish to proceed with the installation then you must
>    either delete the conflicting files or move them to another location.
>    (The latter course of action is recommended in case you wish to
>    revert.)
> --8<--------

> Which would imply that the package manager is not yet up to *upgrading*
> (with optional revert backup?) system resources - thus again requiring
> the user to potentially need understand the !Boot structure in order to
> delve in and delete/rename the module.

No, that is a misunderstanding. The whole point of RiscPkg *is* to 
upgrade system resources, and that is what it does.

What it does not do is overwrite files that are not yet managed by 
RiscPkg, which is what happens when you first introduce package 
management on your system, and that behaviour is quite a good idea. 
Once you allow RiscPkg to manage a specific system resource (by moving 
it away and repeating installation), it will do so and from then on 
upgrade it automatically.

Admittedly, the process of RiscPkg taking control of a given resource 
could be improved. Rather than aborting installation and requiring 
manual user action, RiscPkg should display a warning box asking the 
user for permission to take control of the given resource, and if 
permitted, should then move the existing file to a safe location 
itself rather than expecting the user to do it.

> Is the existent package manager capable of coping with *different*
> modules depending on OS version? And installing them into the correct
> place (as opposed to the fallback of dumping into !System.Modules and
> hoping)?

No, and it would be a very bad idea if it did because this is not how 
RISC OS works. Each module has exactly one correct place, which is 
independent of the OS version the machine happens to run, and the 
package manager can put it exactly there.

RISC OS itself offers the means of making applications load the 
correct module automatically depending on the system version. There is 
no need for the package manager to do anything about that.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#2439 — Re: SmartMenu - was: VRPC on a USB pen

Steve Fryatt <news@stevefryatt.org.uk> wrote:
> On 10 Nov, Vince M Hudd wrote in message
>     <mpro.lugbpk00aretu03i0.vinceh@softrock.co.uk>:
> > Steve Fryatt <news@stevefryatt.org.uk> wrote:

> > > I hate to say it, but this is *precisely* the problem that package
> > > managers are designed to sort out...
 
> > Except that all the package management in the world won't help if the
> > writer of the software shoves the module in the application directory
> > and loads it from there - which is what seems to be happening here.

> It's a lot simpler to say "this package is dependent on the WimpSWIVe
> package" (to the package manager, not the user) and point the !Run file to
> the place that the WimpSWIVe package installs the module than it is to try
> and write instructions to tell the user how to set it all up manually.

And it's even easier still to just load the module from within the
application directory - even if using a package manager. There's no
guarantee that a developer who makes poor choices like that is suddenly
going to make only good ones because he's using a package manager.

Package managers aren't supplied with a free dose of clue.

-- 
Soft Rock Software:                   http://www.softrock.co.uk
Vince M Hudd:                         http://misc.vinceh.com/about-vinceh/
RISCOSitory:                          http://www.riscository.com

[toc] | [prev] | [next] | [standalone]

#2468 — Re: SmartMenu - was: VRPC on a USB pen

The following bytes were arranged on 11 Nov 2011 by Vince M Hudd :

> Steve Fryatt <news@stevefryatt.org.uk> wrote:
> > It's a lot simpler to say "this package is dependent on the WimpSWIVe
> > package" (to the package manager, not the user) and point the !Run file to
> > the place that the WimpSWIVe package installs the module than it is to try
> > and write instructions to tell the user how to set it all up manually.
>
> And it's even easier still to just load the module from within the
> application directory - even if using a package manager. There's no
> guarantee that a developer who makes poor choices like that is suddenly
> going to make only good ones because he's using a package manager.
>
> Package managers aren't supplied with a free dose of clue.

Which is exactly the point I was trying to make.  It's depressing how
many people contrived to fundamentally misunderstand it.

If a developer is incapable of following the existing, defined
procedures for loading modules, what on earth makes people think they
would magically follow the defined procedures for installing them?  All
the package management in the world won't stop humans being humans.
It's nothing like the magic bullet its proponents claim it to be.  My
experiences with RPMs led me to uncover this inconvenient fact.

-- 
  __<^>__
 / _   _ \         You always find something in the last place you look.
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [next] | [standalone]

#2469 — Re: SmartMenu - was: VRPC on a USB pen

On 13 Nov, Martin Bazley wrote in message
    <3ec17c3152.martin@blueyonder.co.uk>:

> The following bytes were arranged on 11 Nov 2011 by Vince M Hudd :
> 
> > Package managers aren't supplied with a free dose of clue.
> 
> Which is exactly the point I was trying to make.  It's depressing how many
> people contrived to fundamentally misunderstand it.

Hello, pot; meet kettle.

> If a developer is incapable of following the existing, defined procedures
> for loading modules, what on earth makes people think they would magically
> follow the defined procedures for installing them?

We're talking about a third-party module that, IIRC, was distributed either
with the software that originally used it or in a zip file with no wrapping
or instruction.  What /were/ other developers supposed to do with it?  They
could either hide it inside their own application and so avoid having to get
the user to install it, or they could present the user with a two-stage
installation process and wordy instructions.

Were WimpSWIVe to be packaged, I'd guess that it would be set to install
into a central location and any clients, when packaged, would be updated
accordingly.  And we would have the best of both worlds: a one-step
installation, while WimpSWIVe and the client are treated as separate
entities with a dependency.

> All the package management in the world won't stop humans being humans.
> It's nothing like the magic bullet its proponents claim it to be.  My
> experiences with RPMs led me to uncover this inconvenient fact.

My experience with Debian's packaging system has been pretty positive, at
least once I'd realised that there were benefits for *me* in working with it
and not fighting it at every stage. 

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[toc] | [prev] | [next] | [standalone]

#2504 — Re: SmartMenu - was: VRPC on a USB pen

The following bytes were arranged on 13 Nov 2011 by Steve Fryatt :

> On 13 Nov, Martin Bazley wrote in message
>     <3ec17c3152.martin@blueyonder.co.uk>:
>
> > If a developer is incapable of following the existing, defined procedures
> > for loading modules, what on earth makes people think they would magically
> > follow the defined procedures for installing them?
>
> We're talking about a third-party module that, IIRC, was distributed either
> with the software that originally used it or in a zip file with no wrapping
> or instruction.  What /were/ other developers supposed to do with it?

They could follow the *existing*, *defined* *procedures* for installing
modules, which is that, unless they are really closely tied into the
application they came with (which WimpSWIVe is not) and thus useless to
any other program which might wish to load them, they are distributed
inside a template !System directory with just enough of the directory
structure in place to determine the module's location in the real thing.
This dummy !System is then dropped onto !SysMerge, which will examine
its contents, ignore any ones which are older than versions already
present, make backups of any which are upgrades on pre-existing
versions, and copy files into the main !System directory as appropriate.

Why am I describing this process to you?  Is it now clear what I meant
by "contriving to misunderstand"?

Look no further than NetSurf for an example of exactly how it's supposed
to work.  The Iconv, Tinct, SharedULib and URI modules could quite
easily have been force-loaded from inside the !NetSurf application, as
apparently a number of applications relying on WimpSWIVe have done, but
there are very good reasons why they aren't.

Even RiscPkg enforces this convention - all system resources must be
distributed inside a subdirectory called 'System' containing a partial,
dummy hierarchy leading to modules in their conventional places.
Converting this to a format parseable by SysMerge (or it might work
anyway - I haven't actually tried) is a matter of adding a leading "!"
to the name "System", and this is only because of a bad decision taken
when writing the policy manual.  (Another example, incidentally, of
RiscPkg's intervention in the process being less than necessary.)

Others have pointed out that the RiscPkg application itself is a bit
braindead about this whole business, both loading and installing sides,
which serves perfectly to illustrate my original point about how, even
in applications distributed via package systems which are supposed to
eliminate, among others, precisely this problem, there is still oodles
of scope for the creators of distributed software to get it hopelessly
wrong.  Packaging will not solve, and demonstrably has not solved, this
problem.

> They could either hide it inside their own application and so avoid
> having to get the user to install it, or they could present the user
> with a two-stage installation process and wordy instructions.

I quote once again from the NetSurf archive:

---8<------8<------8<------8<------8<------8<------8<------8<---
Installation
------------

Installation is a three step process:

   1.  Use the Boot Merge facility provided by Configure to merge
       the supplied !Boot directory with the one on your system.

       If there is no !Boot merge facility on your system, simply
       drag the supplied !Boot over your existing boot structure.

   2.  Use the System Merge facility provided by Configure to merge
       the supplied !System directory with the one on your system.

   3.  Drag the !NetSurf application directory to a place on your
       hard disc.
--->8------>8------>8------>8------>8------>8------>8------>8---

This is as *complicated* as installation instructions get.  In the
theoretical WimpSWIVe example we are considering, step 1 is not
necessary, and I'd personally say that the second paragraph of step 1 is
not necessary, full stop.  Given that it is standard procedure for
absolutely everything in RISC OS, most users will not need to be
informed of step 3 either.

More complicated procedures for 'premium' free software may exist -
DigitalCD and StrongED being two particularly bad examples - but, by and
large, they are rare, and try to smooth over the difficult bits when
they do arise.  DigitalCD, for example, automatically upgrades its skins
and plugins when first run, although I think there's a gap in the market
for a tool to automate its tiresome and tedious exhortation to 'merge
your MimeMap file with the one supplied'!

> Were WimpSWIVe to be packaged, I'd guess that it would be set to install
> into a central location

You mean, like, !System?

> and any clients, when packaged, would be updated accordingly.  And we
> would have the best of both worlds: a one-step installation, while
> WimpSWIVe and the client are treated as separate entities with a
> dependency.

Indeed.  I'm not denying the attractiveness of such a state of affairs,
nor am I claiming that RISC OS's current system isn't imperfect in ways
that a package manager might theoretically, technically, have the
capability to rectify.  But for as long as computers remain the
grudging, efficient servants of emotional, unreliable humans, your
scenario will never ever ever happen, not if a successor a thousand
times improved upon RiscPkg were to emerge.  Until such time as Skynet
can rise up and enslave us all, the human factor will continue finding
new and ingenious ways to bollocks up any distribution standard you care
to dream up.

> > All the package management in the world won't stop humans being humans.
> > It's nothing like the magic bullet its proponents claim it to be.  My
> > experiences with RPMs led me to uncover this inconvenient fact.
>
> My experience with Debian's packaging system has been pretty positive, at
> least once I'd realised that there were benefits for *me* in working with it
> and not fighting it at every stage.

Speak for yourself.  At most stages I haven't had any choice.  Do you
have any idea how outdated Scientific Linux's official repositories are?
More than once I've been caught out by software demanding dependencies
which are either absent or newer than the latest official version
available for any RHEL clone anywhere.  The situation isn't helped by
infighting among the various third-party repository maintainers, each of
whom provide a very slightly different subset of all theoretically
compatible software, which is apparently enough to cause critical
incompatibilities if you enable the wrong combination at the same time,
and sometimes even none of them have it.

Let me quote just one example, from just this very morning.  Today I
started a Haskell module in my university course, and unsurprisingly one
of the lecturer's first assignments was to go away and install the
Haskell compiler and associated tools (collectively referred to on
haskell.org as the 'platform' package).

Easier said than done!  Needless to say, it was neither pre-installed
nor available on any compatible third-party repositories.  Apparently
(after hours of Googling, I determined I'm by no means the first person
to suffer from these problems) Haskell's flat refusal to support RHEL
of any stripe, or vice versa, or both, is the stuff of legend.  If your
system isn't listed on the list of packages, you are instead forced to
build it from source.

A large percentage of the 'platform' bundle was, naturally, written in
Haskell (standard libraries and that sort of thing), which meant you
needed GHC, the Haskell compiler, installed before you could build the
'platform' bundle.  Where was the recommended place to download GHC? Oh,
yes... the 'platform' bundle.  Well, the packages, at any rate,
presumably via some of these famous dependencies... the same could not
be said for the 'source' zip.

So the very first thing I had to do was to download the compiler
separately (thankfully I didn't have to build *that* from source), in
what was supposed to be a 'one-step' process, purely to bootstrap the
rest of the archive.  This meant I had to first download, and manually
install via an old-school terminal window and faffing about in /usr/lib
(oh, how I miss those drags and drops of single directories - even RISC
OS GCC manages it!), the compiler, before I could even think about
downloading the 'platform' source zip and attempting to compile, and
subsequently install, that.

I did eventually manage to get things up to this stage, and immediately
ran up against another hurdle.  It seemed that the compiler wouldn't
work, because I didn't have the libgmp shared library installed.  Off I
went to the GNOME package installer again, always my first port of call
in such circumstances, although usually with diminishing hope and
expectations each time.  Much to my surprise, it turned up a perfect
match, and what's more swore blind that it was already installed.

By this point the air in between my vision and my laptop screen had
turned such a deep shade of blue I could squint and pretend I was
running Windows instead.  After yet more Googling, I eventually found
the answer by accident, after following a piece of advice (on an
Ubuntu-centric blog) which looked harmless enough and potentially
vaguely relevant to my issue, which as it turned out was exactly the
same problem the author was suffering from.  It appears there has been a
spate of libgmp packages which create the libgmp.so.3 symlink, but
neglect to create the libgmp.so symlink which GCC rather firmly insists
upon being present.  This, I am pretty sure, is a bug.  All I know is
that I created such a symlink and everything magically worked (bar a
second, more successful, trip to the SL repository to install another
dependency, in this case freeglut).

And all this was *before* I had even got a whiff of the 'platform'
goodies at all.  I subsequently had to repeat the process, this time
with GHC installed, in order to compile everything else.  This took so
long I could have installed an (imaginary) purpose-built platform
package over a dial-up connection in less time.

I still haven't completed the last step, which is to update lots and
lots of what I can only assume are platform-independent Haskell-designed
packages.

You might argue that all of my problems (except possibly the libgmp one)
were the product precisely of my *not* having installed from a one-stage
package, rather than stepping through all the stages they eliminate
(most of which, I would like once again to remind you, would not occur
on RISC OS).  To say this is to miss the point entirely.  My woes are a
*direct consequence* of one of the fatal flaws of the package system -
namely, that it makes it a hell of a lot easier to fail to support a
certain system.

This is by no means the first problem I have had with packages simply
not existing, and it won't be the last.  The amount of software
theoretically compatible with one's computer is severely constrained by
how many or few programs have been laboriously packaged up for your
distro (in the process duplicating much effort expended on every other
distro simultaneously), and further constrained by the presence of
packages which are theoretically available for one's distro, but list as
dependencies packages or version numbers which are not (usually, in the
case of version numbers, entirely spuriously, as in the case of the RISC
OS applications which *RMEnsure the version of the Toolbox modules which
the author happened to have on their computer, regardless of actual
compatibility, or whether such a number even exists on the other fork).

All of these problems stem solely from the decision to standardise
software updates through a package system.  I think I mentioned in my
last post which was as long as this one that if there was one thing
which had finally convinced me to change my mind about RiscPkg from
merely ambivalent to firmly opposed, it was my experience of fighting -
yes, I do believe that is the appropriate word - with a mature packager
with widespread community support.  RiscPkg is only barely hanging
together because the RISC OS community is simply so small (only *one*
somewhat-incompatible-in-obscure-ways schism!  Imagine!) and developers
so few that the cats can be relatively easily herded.  I repeat:
packaging will never solve more problems than it causes.  On a system
like RISC OS, where unaided installations are comparatively trivial,
we're better off without.

-- 
  __<^>__   === RISC OS is a work of art.  Some people adore it,  ===
 / _   _ \  === others can't see the point of it, and it's really ===
( ( |_| ) ) === expensive.                                        ===
 \_>   <_/  ======================= Martin Bazley ===================

[toc] | [prev] | [next] | [standalone]

#2474 — Re: SmartMenu - was: VRPC on a USB pen

On 13/11/2011 13:22, Martin Bazley wrote:

> Which is exactly the point I was trying to make.  It's depressing how
> many people contrived to fundamentally misunderstand it.

Why is it up to *ME* to understand it?

Sure, as a developer, yes. But as an end-user, NO. I want to download a 
package and have everything set up nicely. A boring lame-ass Windows 
installer can manage this much...

Furthermore, there is a somewhat hysterical FAIL in RiscPkg itself where 
the !Run states:
   RMEnsure SharedUnixLibrary 1.02 RMLoad System:Modules.SharedULib
   RMEnsure SharedUnixLibrary 1.02 RMLoad <RiscPkg$Dir>.Resources.Sh...
                                   ...aredULib

For some reason, my SharedULib isn't always found (System: equates to 
Sys:500.,Sys:360.,Sys:310.,HostFS:$.!Boot.Resource.!System. and it is in 
310 so it *ought* to be found). Anyway, in case SharedULib is not 
loaded, instead of doing the right thing and complaining that a system 
resource is missing, it will instead load the built-in one will be 
loaded, and this is v1.02. Kiss goodbye to any hope of running NetSurf 
for that SharedULib is so ancient it has barnacles hanging off it, and 
as if that isn't enough, attempting to load a newer one (even after 
quitting RiscPkg) complains about active clients - SharedULib refuses to 
die.


Perhaps I am fundamentally misunderstanding the purpose of a package 
manager. Perhaps you are fundamentally misunderstanding the problem at hand.


Now read back through this thread, look at the points raised (ie the 
package manager expects you to move system files out of the way before 
it will install and subsequently "manage" them, etc) and ask yourself if 
any of this will make a hell of a lot of sense to a newbie? Remember the 
target audience of the likes of the RaspberryPi. This is supposed to be 
a simple operation. Perhaps with a dose of magic applied, yes. For if it 
was a simple extract-and-copy, that could be seen to with an Obey file...


> If a developer is incapable of following the existing, defined
> procedures for loading modules, what on earth makes people think they
> would magically follow the defined procedures for installing them?

How about the package management (or whatever) *enforcing* the correct 
procedure?
I'll give you an example. My Windows installer (the Clickteam one) will 
let me put a DLL pretty much anywhere. I tend to put private DLLs within 
the application directory, as - for example - an IIC-over-LPT thingy for 
my Teletext software does not belong cluttering up Windows\System32 any 
more than the God-awful mess it already is). HOWEVER, if I put a DLL 
anywhere other than the 'correct' place, it is not integrated into 
Window. It cannot be 'registered' (some service thingy I don't fully 
understand), the user-count is not altered, etc. So I can have a private 
DLL essentially separate to the system, or one integrated with it. 
Them's my choices.

Likewise under RISC OS, there are few *correct* places to put resources, 
and many incorrect places. The installer/package-manager should make it 
'difficult' to do it wrongly, and fairly easy to do it correctly.

That said, the idea I postulated right at the beginning was that a 
package carries a list of system dependencies and these would be 
resolved by the manager *independently* of the package itself. It would 
install (or update, if necessary), modules and such - all the pieces 
necessary for the packaged product to work. Again, we run into a failing 
here with the "NettleSSH" package which neither contains, nor attempts 
to install, the "SockWatch" module.

Don't mistake limitations of what you think a package manager should 
actually do with limitations of the problem at hand.

And yes, I'm asking for the moon on a stick. :-) But, then, people used 
to the Ubuntu "pick a program and in it goes" or the Windows "setup.exe" 
will be used to stuff generally "just installing".


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2489 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ec03264$0$2520$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> Furthermore, there is a somewhat hysterical FAIL in RiscPkg itself where
> the !Run states:
>    RMEnsure SharedUnixLibrary 1.02 RMLoad System:Modules.SharedULib
>    RMEnsure SharedUnixLibrary 1.02 RMLoad <RiscPkg$Dir>.Resources.Sh...
>                                    ...aredULib

> For some reason, my SharedULib isn't always found (System: equates to
> Sys:500.,Sys:360.,Sys:310.,HostFS:$.!Boot.Resource.!System. and it is in
> 310 so it *ought* to be found).

That depends on what Sys$Path equates to. The fact that the module is 
not found via System:Modules.SharedULib indicates that something is 
broken on your system. You would expect programs to fail under such 
circumstances.

-- 
Martin
---------------------------------------------------------------------
Martin Wuerthner         MW Software      http://www.mw-software.com/
        RISC OS Software for Design, Printing and Publishing
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#2491 — Re: SmartMenu - was: VRPC on a USB pen

In message <4ec03264$0$2520$ba4acef3@reader.news.orange.fr>
  Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 13/11/2011 13:22, Martin Bazley wrote:

>> Which is exactly the point I was trying to make.  It's depressing how
>> many people contrived to fundamentally misunderstand it.

> Why is it up to *ME* to understand it?

> Sure, as a developer, yes. But as an end-user, NO. I want to download a
> package and have everything set up nicely. A boring lame-ass Windows
> installer can manage this much...

> Furthermore, there is a somewhat hysterical FAIL in RiscPkg itself where
> the !Run states:
>    RMEnsure SharedUnixLibrary 1.02 RMLoad System:Modules.SharedULib
>    RMEnsure SharedUnixLibrary 1.02 RMLoad <RiscPkg$Dir>.Resources.Sh...
>                                    ...aredULib

And it goes on. Within !RiscPkg.!RunImage are three further lines, for 
the truly undecided, :-

RMEnsure SharedUnixLibrary 1.07 RMLoad System:Modules.SharedULib
RMEnsure SharedUnixLibrary 1.07 RMLoad UnixLib:Modules.SharedULib
RMEnsure SharedUnixLibrary 1.07 Error XYZ

And !RiscPkg does not register the SharedUnixLibrary as a dependancy.

-- 
David Pitt

MessengerPro 6 on an ARMini running RISC OS 5

[toc] | [prev] | [next] | [standalone]

#2433 — Re: SmartMenu - was: VRPC on a USB pen

On 10/11/2011 16:44, Vince M Hudd wrote:

> Except that all the package management in the world won't help if the writer
> of the software shoves the module in the application directory and loads it
> from there - which is what seems to be happening here.

It isn't helped by people saying "that's what package management tools 
are for" - maybe there are some people here who might want to distribute 
something and actually understand *how* !Boot works.

This is why I said in my earlier message about taking apart !Boot to see 
how it works. Do you fiddle with the Choices:Boot and System:Modules, or 
delve around to find "hook" stuff? Which has precedence? Are they *both* 
used (i.e. your OS hook followed by "generic stuff") or is only one 
used? The setup is logical, but not exactly straightforward.


Best wishes,

Rick.

[toc] | [prev] | [next] | [standalone]

#2465 — Re: SmartMenu - was: VRPC on a USB pen

In article <278ca22f52.pnyoung@pnyoung.ormail.co.uk>, Dr Peter Young
<pnyoung@ormail.co.uk> wrote:
> On 9 Nov 2011  druck <news@druck.freeuk.com> wrote:

> > On 9 Nov 2011 Richard Ashbery <basura@invalid.addr.uk> wrote:

> >> In article <b9e91d2f52.pnyoung@pnyoung.ormail.co.uk>, Dr Peter
> >> Young

> >> [snip]

> >>> I'm very new to the ARMini (it just arrived the afternoon), but
> >>> if I try to run SmartMenu it comes up with the weird error
> >>> message "WimpSWIVe cannot be quit right now, as some clients
> >>> are still using it". What am I doing wrong, please?

> >> Place in Boot.Choices.Boot.PreDesk and reboot - avoids all the
> >> trouble.

> > Except when a later version is installed in to the correct place in
> > !System and then you find you are never using it.

> OK. For the ignorant, please, where is the correct place in !System?

> With best wishes,

!System.310.Modules

David pointed out this is not so easy because SmartMenu, Fullnames and
WimpLog need their !Run files modifying. As Steve pointed out you have
to know what you are doing.

None of these apps have used Druck's suggestion to provide a System
merge utility and that's the easy bit.

In the meantime I will look into Steve's suggestion - a Package manager
as it appears to be the best solution - what's the best one to get
started?

How do I determine where the module is loaded from - I'm sure I used a
simple command line utility in the passed. Anyone?

Richard

[toc] | [prev] | [next] | [standalone]

#2334

In message <4eb43655$0$30764$ba4acef3@reader.news.orange.fr>
          Rick Murray <heyrickmail-usenet@yahoo.co.uk> wrote:

> On 04/11/2011 18:12, Michael Gerbracht wrote:

>> I am especially missing the ability of !Paint to import and export some more
>> file formats (PNG...).

> That's a reasonable request - if only JPEG, PNG, and BMP initially. It
> would be fairly easy to cobble on BMP (I did so to FYEO2), but the maths
> behind the other two are more than my itty-bitty brain could handle,
> although we have JPEGRender which might be able to act as, at least, a
> loader?

These were provided by a the system, not paint, and are available to 
any program.

>> Support for alpha-Sprites...

> In what context? The filer? The desktop generally?

Generally

ROL really need to get all this good work in a form that can be loaded 
onto RO 5 and SOLD. I would buy it.

-- 
Jess                   Iyonix

[toc] | [prev] | [next] | [standalone]

#2235

In message <3fa3ee2a52.chris@o2.co.uk>
          Chris Hughes <news@noonehere.co.uk> wrote:

> Obviously I would not say I am happy about it all, I know some work
> has been done on ROL version of RISCOS, but I know there are personal
> issues for one of the main developers (which are a private matter) and
> had an impact. But I do wish they would communicate better.

>> The general buzz at the show this weekend really did seem to be RISC OS 5
>> and the Beagleboard/ARMini; wandering around and talking with punters,
>> RISC OS 6 and Select might as well have not existed.

> Well ARMini is good (I have one), but to me RO 5 takes me back 10
> years.

Maybe the new systems will finally get ROL to do the obvious thing and 
provide their improved components as something that can be purchased 
to load on RO 5 (with an included licence for RISC OS desktop use.)

I would love to be able to purchase the bits that I lost when I went 
from an adjust RPC to my Iyonix.

-- 
Jess                   Iyonix

[toc] | [prev] | [next] | [standalone]

#2184

On 29 Oct 2011 David Pitt <pittdj@pittdj.co.uk> wrote:

> In message <639dd42952.druck@druck.freeuk.net>
>   druck <news@druck.freeuk.com> wrote:

>> I've just read on the show twitter feed that ROL are doing a RISC OS
>> emulator on a USB pen - only 5 1/2 years after I suggested it.

> It is ROOL doing the pens.

Ah that'll tech me to read things on the Iyonix with it's 2048x1536 
display instead of the netbook at half that and twice as close!

---druck

-- 
The ARM Club Free Software - http://www.armclub.org.uk/free/
32 bit Conversions Page    - http://www.armclub.org.uk/32bit/

[toc] | [prev] | [next] | [standalone]

#2186

In article <75aee52952.druck@druck.freeuk.net>, druck
<news@druck.freeuk.com> wrote:
> On 29 Oct 2011 David Pitt <pittdj@pittdj.co.uk> wrote:

> > In message <639dd42952.druck@druck.freeuk.net> druck
> >   <news@druck.freeuk.com> wrote:

> >> I've just read on the show twitter feed that ROL are doing a RISC OS
> >> emulator on a USB pen - only 5 1/2 years after I suggested it.

> > It is ROOL doing the pens.

> Ah that'll tech me to read things on the Iyonix with it's 2048x1536
             ^^^^
> display instead of the netbook at half that and twice as close!

Still not working!!!!!   :-D

-- 
Tim Hill of timil.com . . .
* supports TFT & shares in cheaper ethical telecoms http://tjrh.eu/phone
* has a genuine & spam-proof address for Usenet http://www.invalid.org.uk/
* accepts incoming email: substitute postmaster@ for tim@

... "No more be grieved at that which thou hast done" Sonnet 35

[toc] | [prev] | [next] | [standalone]

Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6  Next page →

Back to top | Article view | comp.sys.acorn.misc

csiph-web