Front page | perl.riscos |
Postings from September 2003
Re: how to set up !Perl
From: Ben Kal
September 18, 2003 15:52
Re: how to set up !Perl
Message ID: firstname.lastname@example.org
In a message of 13 Sep 2003 you wrote:
> On Sat 13 Sep, Ben Kal wrote:
>> I was glad to see that Perl is available for RISC OS, so I
>> copied it from the latest Foundation RISC User cd (that was
>> version 5.005) and even downloaded Alex Waugh's version 5.8.0.
> I haven't tried Alex Waugh's 5.8.0 because it didn't sound like he was
> confident that it was finished. Stability and completeness have always
> been higher priority for me than new features. Perhaps Alex will let us
> know if things have changed since.
Alex Waugh himself advised me not to use his Perl 5.8.0 until he shall have
solved the problem of the difference between his default @INC and the
directory structure containing the modules. Big problem nr. 2 solved.
>> Then I wanted to set things up so that I would be able to
>> really do Perl programming under RISC OS, but failed.
> I wonder what you mean by "really do".
Not more than: being able to work under RISC OS on Perl scripts that are
either RISC OS specific or operating system neutral. It would be nice to
have the freedom not only to edit but also to test under RISC OS a Perl
script intended for use under Linux. Some limitations in RISC OS Perl are
acceptable, if I know which those are and there are not too many of them.
And I expect that all there is in a distribution of RISC OS Perl (not only
the binary but also the packages and scripts) can somehow be made to work,
otherwise why where these things included?
> Perl on RISC OS is unfortunately not practical in all the places you may
> have used Basic. This is because Basic is a "language module" that stays
> resident in memory and can start Basic programs instantly and with only
> about 8K overhead per program. In contrast, when a Perl program runs, a
> massive 1Mb of application memory is required to load a *separate* copy of
> the perl executable each time.
No consideration to me. My Risc PC has 45 Mb memory and more could be
added. Almost never use non-multitasking Basic programs, so no plans to
replace them by Perl scripts. Also no plans to build a system that could
overload my machine by calling too many Perl scripts.
> So that I can have a *little* more flexibility over where to run Perl
> progs from, I made a few small alterations as follows:
> Leave line 57 of the !Perl.!Boot file commented out.
> Comment out line 46 of the !Perl.!Boot file which sets the runtype so that
> the perl executable is started directly.
> Delete the last two lines of the !Perl.!Run file and replace them with the
> following three lines:
> If "<Wimp$State>"="desktop" then TaskWindow "/<Obey$Dir>.Perl %*0" 1024k
> Perl -quit
> If "<Wimp$State>"="commands" then WimpSlot 1024k
> If "<Wimp$State>"="commands" then /<Obey$Dir>.Perl %*0
> The result of these alterations (after a reboot of course) is that you can
> run Perl progs from the command line, or double-click them to run them in
> a task window. However, when typing into a task window Wimp$State is
> "desktop" and this causes each command to launch into a new task window
> (rather like launching X applications from within an xterm).
I tried your alterations and they seem to result in an acceptable way of
working. Big problem nr. 1 solved.
> Of course, the !PerlRun application is designed to detect when you are
> within a task window and do the right thing accordingly. I don't use it
> myself, although I probably should. However, I'm surprised you could not
> get it to work for you.
For the moment, I do not bother to look at !PerlRun again.
>> 1. I see no way to make the Risc PC gracefully handle running Perl scripts:
>> - by double clicking a script file in the desktop (how to pass parameters
>> then if needed?);
> Parameters can never be passed to a double-clicked file. This is not a
> Perl limitation, it is a natural result of the fact you're double-clicking
> the file rather than typing a command line.
I knew, believe me. But somewhere in the documentation about RISC OS Perl I
found that double clicking a Perl script by runs Perl, without any
qualification about those scripts needing parameters passed to them or not.
Always willing to believe that I have missed something (maybe RISC OS Perl
would have been fitted with a mechanism to make double clicked scripts ask
parameters they need before running?) I asked the stupid question.
>> I found !PerlRun which seems designed to solve this problem, but if I use
>> that I invariably get a 'No writable memory at this address' message.
> I'm sorry, I can't think what would have caused that. Does it make a
> difference when you set the Wimp's "Next" slot to more than 1024K?
I believe that what I saw happening was that I got this error message
regardless of how big I made the "Next" Wimpslot.
> One of my gripes about the RISC OS Perl situation is that so many modules
> require compilation via a "make install". I have never managed to get that
> to work on RISC OS because it is too Unix specific and I don't know enough
> about porting Unix software.
I suppose you mean modules that are available from CPAN but are not present
in the RISC OS Perl distribution? I can live with that, if only the modules
that are in the RISC OS Perl distribution do work. Because of its origin
Perl will forever only offer its full functionality under Unix, I think.
>> Perl very often reports that it cannot find a certain package in a list
>> of directories in @INC (yes I know what that is for) that in no way
>> corresponds to the directory structure within !Perl.
> *perl -MWibble
> Can't locate Wibble.pm in @INC (@INC contains: /PerlPrivLib:zip /PerlArchLib:
> /PerlPrivLib: /PerlSiteArchLib: /PerlSiteLib: .).
> BEGIN failed--compilation aborted.
> Hmmm, those are path variables which you can see like this:
> *show Perl*$Path
> Perl$Path : ADFS::HD.$.!Boot.Resources.!Perl.
> PerlArchLib$Path : ADFS::HD.$.!Boot.Resources.!Perl.riscos.
> PerlP$Path : ADFS::HD.$.!BOOT.Resources.!Scrap.ScrapDirs.ScrapDir.
> PerlPrivLib$Path : ADFS::HD.$.!Boot.Resources.!Perl.lib.,ADFS::HD.$.!Boot.Resources.!Perl.more-lib.
> PerlScript$Path : ADFS::HD.$.!Boot.Resources.!Perl.scripts.
> PerlSiteLib$Path : ADFS::HD.$.!Boot.Resources.!Perl.lib.site_perl.
Ah! So the RISC OS Perl*$Path variables come out as @INC in Perl. Something
like this was what I was looking for.
>> I cannot believe that I am supposed to rearrange all the packages
>> into directories
> Where did you get those directories from?
This is what Alex Waugh's Perl 5.8.0 reports as the value of @INC when it
cannot find a module.
>> Please, can someone enlighten me on how to solve these
>> problems, so that I can *conveniently* use RISC OS Perl?
> Well, I've done my best, ....
Certainly, thank you very much!
> .... but you may not find it as convenient as you were hoping.
After further experimenting I have come to the conclusion that probably most
of the provided scripts work, but that this is often far from apparent at a
first try, because you have to know what the script is supposed to do and
what paramaters it needs in exactly which form (for instance, I now know
that a full RISC OS pathname has to be really, really full: '$.something' or
'ADFS::$.something' does not suffice, it has to be 'ADFS::4.$.something').
Otherwise, the output often looks like Perl and/or the script is simply
>> And of course, if someone is able and willing to write such instructions,
>> publish them on the internet and make RISC OS Ltd add them to their next
>> Foundation User cd.
> I think the functionality of !PerlRun could be added to the !Perl
> application itself and then no such instructions would be necessary. I
> might have a go at that. I certainly wouldn't wish you to duplicate the
> waffle I wrote above. :-)
To do that *I* would first have to gain more experience with RISC OS Perl.
And I think that people new to RISC OS Perl, even those with Perl experience
on other platforms, will much appreciate more information on the
peculiarities of RISC OS Perl.
Anjelierstraat 1, 2014 TC Haarlem, Netherlands
tel +31 23 5324909, email@example.com