Re: `` redirection bug
On Sat 28 Oct, Vincent Lefevre wrote: > ...but after the 40th file, the CRC was > written to the taskwindow instead of being redirected: Did you know that unpack can do checksums? I've used the backtick operator quite a lot and not found any problems, except that it sometimes "forgets" to remove its temporary files from the scrap dir. I was also using a task window for output. Ah wait, I've just looked back and noticed that my program (which was running the ANT whois binary) wrapped the call in a function that returned false if it was not successful. The main program then evaluates the function up to five times to get a successful reply before giving up and this would have hidden any one off problems from me. Sorry. Perhaps you could do the same kind of thing. PS. Is anyone working on a port of Perl 5.6 ? -- James Taylor PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Platform independent pathnames
Hi all, I'm writing a Perl program to take a directory containing a website in a kind of "source" form and then (via various template files and automatic hierarchic navbar creation) to output a directory containing the complete site ready for upload. A major part of the program is that it has to calculate relative paths between all the pages, the graphics, and the navbar items, making sure that they are written into the HTML in the standard Unix format. At the same time it has to know where all the source and destination files are by native absolute pathname, and be able to convert between the two freely. The program will run on RISC OS during the initial development of sites, but then I also wish to be able to give it to my clients so that they can update their sites themselves - and they could be running Windows, Linux, MacOS or anything else. Obviously Perl is nicely portable, but I have a problem with how to perform all the pathname manipulations and conversions in a platform independent manner. It's rather a headache and your assistance would be much appreciated. I've had a look at File::Spec and children but do not seem to be able to get it to work. I'm also confused by the automatic format conversion the the RISC OS port does on pathnames. In a way this should make it easier, but because I'm in a state of doubt already, I am starting to doubt my understanding of the automatic conversion behaviour and scope. Specific problems I've had are in the use of File::Spec->canonpath() which does not seem to perform the tidying operations it promises. I'd like to have this program written by Monday morning, but right now I don't know where to start, because the treatment of pathnames is so central to the whole thing. Can someone please explain to me what I need to know. Thanks. -- James Taylor Based in Hammersmith, London, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Platform independent pathnames
In news:local.riscos-perl> on Sat 03 Feb, Nicholas Clark wrote: > > Aagh. In File::Spec I find references to RISCOS::File::Spec but > 1: it's buggy ($^O is "riscos", not "RISCOS") > 2: I can't find a copy anywhere of RISCOS::File::Spec Whoops! :-( > This would suggest that to use File::Spec you'll need to be in "conversion" > mode. (the default, as you stated) Yes, not only that, but I would also like to write a single script that need not know about any platform, but which is platform independent. This is why I was looking at File::Spec and friends because I was hoping that I could do Unix pathnames in File::Spec::Unix for the HTML embedded paths, and native pathname stuff using File::Spec whatever platform the script was running on. Although, when I read the File::Spec docs there didn't seem to be an easy way to convert back and forth between native and Unix format. > How to turn the conversion on and off is documented in RISCOS::FileSpec, > which will be in !Perl.riscos.RISCOS.FileSpec/pm > by default use RISCOS; or use RISCOS::FileSpec; will turn the conversion > off. (which may seem mad, but the intent was a script knowing it wanted to > run on RISC OS would likely start > > #!perl -w > use RISCOS; > > and at that point conversions are off. Whereas a written-for-unix script > with hardwired '/' directory separators and no idea of "use RISCOS;" will > (should) just work Yes, I see the motivation. I've tried reading the RISCOS::FileSpec documentation but get very confused when it starts to talk about all the different cases under which it does certain things. I decided to steer well clear of platform specific modules and write something that would work without needing to know what platform it was running on. Unfortunately, this does not seem to be possible. I'll try asking the folks on comp.lang.perl.misc it's just that they won't be aware of problems that might exists in the RISC OS version's implementation of supposedly platform independent modules. -- James Taylor Based in Hammersmith, London, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
GD graphics library
On comp.sys.acorn.programmer the following came up: In article <[EMAIL PROTECTED]>, Alex Waugh <[EMAIL PROTECTED]> wrote: > > On Tue, 12 Jun 2001, James Taylor wrote: > > > > Yes, I've heard of the ImageMagick and GD graphics libraries which > > both have Perl interfaces. I haven't looked into them yet, but they > > are high on my list of things to master next. > [snip] > > GD has already been ported, and my PHP port can use GD. I would very much like to be able to use GD on RISC OS but don't know where to start when it comes to getting it working via Perl. Please could someone help me out. Thanks. PS. I tried CC'ing my Usenet posting to this list but the listbot refused, which I found surprising given that it seemed like such a logical thing to want to do. Oh well, hope you can help anyway. Thanks. Yours, -- James Taylor <[EMAIL PROTECTED]> PGP public key available: 0x3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02 Please do not give my email address to anyone else without my prior permission, and do not send me any bulk mailings or SPAM of any kind.
Re: GD graphics library
On Wed 13 Jun, Richard Proctor wrote: > > On Wed 13 Jun, James Taylor wrote: > > > > I would very much like to be able to use GD on RISC OS but don't > > know where to start when it comes to getting it working via Perl. > > Please could someone help me out. Thanks. > > On the plus side I have done it, one the minus I cant find where > I put it :-( Can you remember roughly what was required to get it to work? If it is a simple matter of downloading a Perl-only CPAN module then I can do it for myself, however, if it involves some C hacking I will have to rely on someone who knows what they are doing. > The perl in question doesnt any longer use GD - its output > is now textual. Do I assume correctly, that by saying "perl" with a lower case P, you mean the executable, and that what you are saying here is that a new GD-aware perl would need to be compiled for this to work? If there's any chance of getting GD to work on RISC OS, and therefore for me to be able not only to practise using GD from Perl, but also to write useful little graphics utilities on RISC OS, then I'd be very interested. I can't be the only RISC OS Perl programmer that would find GD on RISC OS an exciting prospect. Any further help would be much appreciated. Thanks. PS. I'm moving house this week and at some point will have to disconnect and pack the computer. As a result I won't have much time to play with all this until I get settled into the new place. Ironic how the timing of these things work isn't it. :-( Oh well... -- James Taylor Based in Hammersmith, London, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: GD graphics library
On Thu 28 Jun, Matthew Somerville wrote: > > In message <[EMAIL PROTECTED]> > James Taylor <[EMAIL PROTECTED]> wrote: > > > > If there's any chance of getting GD to work on RISC OS, and therefore for > > me to be able not only to practise using GD from Perl, but also to write > > useful little graphics utilities on RISC OS, then I'd be very interested. I > > can't be the only RISC OS Perl programmer that would find GD on RISC OS an > > exciting prospect. > > I'm not sure if this has already been said, and apologies if it has, but PHP > for RISC OS (available from <http://www.ecs.soton.ac.uk/~ajw498/> along with > a StrongHelp manual of the online manual available at > <http://www.php.net/manual/> and a webserver WebJames that handles Perl and > PHP) has GD support built in, is similar to Perl in many ways, and can be > used as simply as follows: [snip] Thanks, but it is the ways in which PHP is not similar to Perl which cause me to disfavour it. I'm sold on Perl and so would like to be able to use GD from Perl. Given that it has already been ported for use with PHP, I wanted to know how to get it working with Perl. Sadly this mailing list wasn't very forthcoming. I get the impression that Richard Proctor is the only other person still subscribed. > I don't see why GD support couldn't be compiled in with Perl from > source, but then you have to decide do you want GD pre 1.6 which > outputs GIFs (as RISC OS PHP currently uses) or post 1.6 which > outputs PNGs? Oh PNGs naturally. :-) -- James Taylor Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: GD graphics library
On Fri 29 Jun, Nicholas Clark wrote: > > Hmm. It appears that his source zip does contain gd's source. Is there any chance you could find a moment to look at what would be involved in getting the Perl GD module to interface with it? Please... > I'm still subscribed. > I'm also subscribed to rather a lot of other lists, and usually > distracted by bleadperl on unix. [aargh. Crays and UTS. aargh] Oh dear, I guess that means you're far too busy to take a look at GD then. :-( There's a chance that it might be easy to do, isn't there? Maybe you could just have a quick look... Pretty please... :-) -- James Taylor Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: GD graphics library
On Sat 30 Jun, Geoff Youngs wrote: > > Have you considered using fly (until someone does)? The RISC OS version > is available from http://www.w3perl.com/fly/fly-1.6.5.RiscOS.zip I'll check it out, thanks, but the main reason for wanting to use the GD Perl module locally on RISC OS is to learn how to use it for generating web graphics on the fly (no pun intended) so although 'fly' may be useful for many things I suspect that it will not teach me what I need to know. -- James Taylor Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Shock: rand function is not uniform!
Hi fellow Perl users! The rand() function as implemented in RISC OS Perl 1.13 for the RiscPC is *not* uniform as it should be. Some time ago, when I was experimenting with this, I wrote the attached program to demonstrate the problem but it's just dawned on me that I never even mentioned this problem to the mailing list. So here I am doing just that. The attached program should not be run in a task window because it needs to be able to change mode and plot a probability distribution graph. If you run it you will notice that values in the middle of rand's range are far less likely to occur than values at either end. Another thing I've noticed is that the rate of change in the probability appears to be linear in the lower half of the range and non-linear in the upper half. Weird eh? Does anyone (Nick?) know why rand has this behaviour or, even better, know how to fix it? PS. I tried writing my own random number generator in Perl but, although it works and is uniform, it is unfortunately really quite slow. If anyone's interested, I can post it. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02 DispRand,102 Description: application/riscos
Re: Shock: rand function is not uniform!
On Fri 15 Feb, James Taylor wrote: > > The rand() function as implemented in RISC OS Perl 1.13 for > the RiscPC is *not* uniform as it should be. Err... It's been awfully quiet since I posted that. Is there anybody there? Does anybody care? > ...my own random number generator in Perl... > If anyone's interested, I can post it. I take it the answer is no then? :-( -- James Taylor Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Mon 18 Feb, Richard Proctor wrote:
>
> The rand function in the current riscos perl is based on the C
> function "rand", which is well known to be less the ideal.
Less than ideal? That's rather an understatement. Did you run
the program I attached which plots a graph of its distribution?
>From the graph it is clear that the probability of getting a
value in the middle of rand's range is around about a *quarter*
of the probability of getting values at the two extremes of
its range. Now I don't think you could describe that as
anything less than an unmitigated disaster!
> if/when we move riscos perl to the more recent version which
> uses the C fucntion rand48 which is more random.
I really don't think the problem with Perl's rand has anything
to do with any minor randomness failings in C's rand. I have
written an equivalent test program in C and it is clear from
the graph that whatever failings C's rand might have, it is
at least approximately uniform. The same goes for C's
_ANSI_rand() function which is supposed to be even less
good. I have also tested Perl's rand function on various
Unix boxes and found that it behaves properly. In comparison,
RISC OS Perl's rand function is *so* broken that I can only
think that there's a bug in the way it was implemented.
[Re: alternative random function]
> Go ahead post it.
Okay, thanks, here you go:
{
my @q; # Holds random number queue
# init_random() parameters:
# Either a number to use as a seed
# or none to seed on PID and time
sub init_random (;$) {
my $seed = shift;
if (defined $seed) {
srand $seed;
} else {
srand(($$ + ($$ << 15)) ^ time);
}
@q = ();
push @q, int rand(1 << 31) while @q < 55;
}
# random() parameters:
# Either a multiplier $mul for an int between 0<=x<$mul
# or none for a float between 0<=x<1,
# See Knuth vol 2 sec 3.2.2 eq 7 for the algorithm used
sub random (;$) {
my $mul = shift;
init_random unless @q;
my $next = ($q[-24] + $q[-55]) % (1 << 31);
push @q, $next;
shift @q;
if (defined $mul) {
return int $next / (1 << 31) * $mul;
} else {
return $next / (1 << 31);
}
}
}
Hope that's helpful to someone... :-)
--
James Taylor <[EMAIL PROTECTED]>
Based in Southam, Cheltenham, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Mon 18 Feb, Nicholas Clark wrote: > > My general understanding about random numbers on computers > is that the question to ask is 'well, how "random" do you > want it?' in that it's very hard for an essentially > non-random machine to fake "random" numbers for you; Thank you Nick, but I really don't think this is an issue with pseudo random number generators per se, it appears to be a bug in the *particular* rand function used by RISC OS Perl. I noticed that the copy of UnixLib you have on your website provides a rand function. I can't think why you would choose to use that rand function instead of the standard one provided by C but if you did then maybe the problem lies there. PS. Who maintains UnixLib anyway, and where can I get hold of the latest version? -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Mon 18 Feb, Justin Fletcher wrote: > > Did you run it over an infinite period of time ? The only thing > that is clear from empirical evidence is that on that run, things > were that way. Whilst it might be less than ideal... Ha! I'm not sure you've quite grasped the magnitude of the issue. I attached a small Perl program to my first post to demonstrate the problem. You can run that as many times as you like and you still get the same, *extremely* distorted, probability distribution. Please look at the problem before passing comment. > You keep saying 'C's rand'; I don't know what you mean. I'm referring to Acorn C in each of the places where you asked this. The shared C library provides rand() but you have to link with AnsiLib to get _ANSI_rand(). > Sorry if that seems critical, but your comments are unclear. No problem. :-) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Tue 19 Feb, Justin Fletcher wrote: > > James Taylor wrote: > > > > Please look at the problem before passing comment. > > Still, it's empirical evidence; whilst it may be skewed there's > very little you can say from empirical evidence other than that > over the period... I said this. I think your condescension is rather unnecessary. You *still* haven't run the program have you? Please run it, understand it, and only then make such comments, otherwise you run the risk of seeming foolish. > > I'm referring to Acorn C > > Perl isn't built with Acorn C, though; I now know that UnixLib was used to the *exclusion* of the standard Acorn CLib. Previously I thought UnixLib would only be used for the things not provided by CLib which is why I thought it strange that rand() shouldn't work. I stand corrected, thank you. > if you want to comment on the randomness of perl; > you will have to use UnixLib. As a user of Perl I can comment on the randomness of Perl regardless of whether I also happen to be a user of UnixLib. In fact, I've never used UnixLib and I'm not familiar with its workings. If I were, I'd just replace its rand function with a C equivalent of the Mitchell-Moore generator I posted here recently. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Tue 19 Feb, Justin Fletcher wrote: > > I think your belief that empirical evidence is proof is > wrong; which is what I'm stating. When lightning strikes the same point a thousand times. Even you might have to admit that, while empirical evidence may not be able to prove anything for certain, there comes a point when you have to stop ignoring its overwhelming significance. When you manage to run the test program the sheer statistical significance of the results will be obvious to you. So for the third or fourth time, *please* look at the problem and take the time to understand it before criticising me. > James Taylor wrote: > > > > You *still* haven't run the program have you? > > Please run it, understand it, and only then make such > > comments, otherwise you run the risk of seeming foolish. > > It didn't work. Ah, then this clearly needs to be addressed first. Why didn't it work? What error messages did you get? Did you give it a large enough wimpslot? Were you running it from the command line or a taskwindow? etc, etc... > You began by talking about perl rand function then went off > to talk about C rand functions and their implication, which > as I stated made little sense, so I can only assume that you > where unsure what you meant on other fronts. It is arrogant to assume that confusion must necessarily be someone else's when it's just as likely to be your own. The reason I mentioned C rand functions was because Perl is written in C and is thus dependent on the C library's rand function actually working. I now know that the C library in question is UnixLib and that its rand function is therefore probably duff. Can you demonstrate otherwise? > Your statements were making it out as if the results were the > only factors - they're not; they are indicative of an > underlying issue which has now been addressed. What do you mean by "has now been addressed"? Do you mean to say that you've fixed the UnixLib duff rand? Sorry if that seems critical, but your comments are unclear. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Shock: rand function is not uniform!
On Tue 19 Feb, Roger Horne wrote: > > The question of the randomness of numbers is dealt with in the > Perl Cookbook as: > > ## > Problem > > You want to generate numbers that are more random than > Perl's random numbers. Limitations of your C library's > random number generator seeds will sometimes cause problems. > The sequence of pseudo-random numbers may repeat too soon > for some applications. I do *not* believe we're dealing with a random number generator that is simply poor quality. Even the poorest random number generators are uniform - our rand() isn't. No, we don't have a poor random number generator we've got a fundamentally broken one. The difference is that a poor one is tolerable but a broken one can and should be fixed. Please would people stop assuming that I'm quibbling over quality when I am in fact trying to point out a fundamental flaw. It's like a hire-car rep trying to tell a complaining customer that the quality of the car cannot be guaranteed when the hapless customer has been given a dead camel! > Solution > > Use a different random number generator, such as those provided by > the Math::Random and Math::TrulyRandom modules from CPAN: Unfortunately both of these are written in C and cannot simply be installed in the RISC OS version of Perl. A better solution would be to fix the bug in UnixLib rand() in the first place, or perhaps replace it altogether. > (Not that I understand any of it. Random numbers to me are things > that my fingers type in unintentionally when I try to enter a PIN.) It would seem that the author of UnixLib rand() may have had the same problem. :-) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
On Fri 15 Mar, David H Wild wrote: > I recently downloaded a Risc OS version of Python. This comes with a > "front end" program which allows you to type Python commands and returns > the appropriate action. > > Would it be possible for a similar program to be produced for Perl, please? I haven't played with Python yet so I'm not sure if this is what you're after, however, I wrote myself the two attached Perl programs for testing purposes. They take Perl expressions and evaluate them. You can even define small subroutines on one line and then call them in subsequent lines. They use OS_ReadLine rather than the operator so that I can use the history and editing features of the line editor module. EvalLoopS evaluates things in scalar context and EvalLoopL evaluates them in list context (unless you type scalar in front, of course). I also have the run action of Perl files set to run them in a task window for convenience. Hope that helps. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02 EvalLoopS,102 Description: application/riscos EvalLoopL,102 Description: application/riscos
Re: Front end for Perl
On Sat 16 Mar, Rafiq Ismail (ADMIN) wrote: > > I've always used perl -de 0 to set up a debugger session in interactive > mode, under linux. Unfortunately, I never got around to setting perl up > on my archie, so I'm not sure if this will work for you. Yes, it seems to work. Good suggestion, thanks Fiq. :-) PS. Could I ask people not to email me direct when they are responding to the list. I simply don't need to get the same message twice to benefit from it. There are even some people who do this on Usenet, can you believe it! I'm sure it's well intentioned but it get's quite irritating after a while. :-/ -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
Fiddle-dee-dee! Having just chastised someone for posting AND emailing, I find myself having to do just that because of... well, shall we say "wibbly finger syndrome". Sorry David. On Sat 16 Mar, David H Wild wrote: > > In article <[EMAIL PROTECTED]>, > James Taylor <[EMAIL PROTECTED]> wrote: > > > > I also have the run action of Perl files set to run > > them in a task window for convenience. > > Thank you very much - they should be very useful. My pleasure. :-) > Can you post how you altered the run action? I was going to > try this, but wasn't sure how to do it. Hmmm, I'm not sure I went about this in the most orthodox manner. First I changed the last line of the !Perl.!Run file from: /.Perl %*0 to: If ""="commands" then /.Perl %*0 else TaskWindow "/.Perl %*0" 1024k Perl -quit Then I realised that the !Perl.!Boot file was resetting the run action each time so I commented out line 46 as follows: | Set Alias$@RunType_102 WimpSlot 1024K|m /.Perl %%*0 This has the advantage that I can double click Perl files to run them in a task window but still run them from the F12 command line directly. The only limitation is that you can't run Perl programs from a task window's star prompt unless you prefix it with *perl. However, some time later I spotted that it might have been easier just to have uncommented line 57 of the !Boot file: | Set Alias$@RunType_102 Taskwindow |".Perl %%*0|" -wimpslot 2048k -name |"Perl 5.005" -display -quit Although, I'm happy that I did it my way because uncommenting line 57 does not allow Perl programs to be run at the F12 star prompt (unless prefixed with *perl of course). Hmmm, I can't help feeling there ought to be a way to arrange for all three situations (double clicking, F12 star prompt, and task window star prompt) to work smoothly. I suppose all it would need is someone to write a code variable to detect the environment appropriately. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
On Sun 17 Mar, Geoff Youngs wrote: > > You could try <http://www.intersect-uk.co.uk/~iugeoff/perlrun.zip> Wow, that works very well, thanks. Aww shucks, did you knock that up just for little ol' me? -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
On Mon 18 Mar, Geoff Youngs wrote: > > And the evaluator on dbl-click also makes sense. You might consider using the list context version though because it can be used to test things in both list and scalar context (by putting 'scalar' as the first word) whereas the scalar context version cannot be used for evaluating things in list context. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
On Tue 19 Mar, Nicholas Clark wrote: > > On Mon, Mar 18, 2002 at 11:33:16PM +, James Taylor wrote: > > > > On Mon 18 Mar, Geoff Youngs wrote: > > > > > > And the evaluator on dbl-click also makes sense. > > > > You might consider using the list context version though > > Or making select double click one context, and adjust the other Or wrapping the loop in something that allows you to switch between the two at will. Hmmm, why don't I just do that now... Oh, and I can allow multi line input... Oh, and I can separate the user and main program namespaces... Oh, and I can distinguish strings, numbers and undef values... Hmmm, it started out neat, and now looks ugly. Why do I let these things get the better of me? I ought to just stop while I'm ahead. Oh well, new program attached. Usage is simple: Type some Perl code, multiple lines of it if you wish, and finish with a blank line. It will then report the return value. If your input consists of nothing more than the word 'scalar' or 'list' it will switch to that mode. Of course the debugger is much more flexible: perl -de 0 :-) PS. I apologise for the cuddled elses, some people don't like them (including Larry Wall et al) but my eyes find it hard to follow code where a solitary close brace can't be relied upon to be the end of a control structure. If you find any bugs or suboptimal bits, please let me know, I'm here to learn after all. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02 EvalLoop,102 Description: application/riscos
Re: Equivalent to BASIC's OSCLI?
On Tue 19 Mar, Richard Torrens (RiscOS) wrote:
>
> How does one pass a command from Perl to the CLI?
There Is More Than One Way To Do It, in fact I can think of
around six depending on exactly what you want to do. You
would probably think of the system() command as being most
similar to Basic's OSCLI(). Example:
system("command arg1 arg2") and die $!;
Of course OSCLI() will behave more like Perl's exec() in
some situations and that may or may not be what you want.
Both system() and exec() can be called in two different ways
depending on whether you want to use the shell (although I
doubt that they do anything different in the RISC OS version
because all tasks have to be started with a command line).
I'll leave you to look up the fine details in your favourite
source of documentation.
Finally, you may wish to capture the output of a command and
there are several ways of doing that too. You could just say:
$output = `command arg1 arg2`;
$output = qx(command arg1 arg2); # Same thing
Or you can use the open() command to open a file handle to
the input or output of the external program. There are also
modules called IPC::Open2 and IPC::Open3 that allow you to
both read and write to a program the same time. Again, I think
I should leave you to check the docs for the gory details.
So many choices! Isn't Perl fun?!
--
James Taylor <[EMAIL PROTECTED]>
Based in Southam, Cheltenham, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Front end for Perl
On Tue 19 Mar, James Taylor wrote: > > If you find any bugs or suboptimal bits, please let me know, > I'm here to learn after all. Whoops! Found one already. @answer needs declaring so that people can run it under "use strict" if they wish. I suggest changing line 44 to say: my (@answer, $listmode); Sorry, for the inconvenience. Hope it proves useful. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Uses for Perl
On Wed 20 Mar, Richard Torrens (RiscOS) wrote: > > Since the list is a bit quiet Well, not really, not in relative terms anyway. Granted, it's not like comp.lang.perl.misc (thank goodness). > - what do peolle here use Perl for? Pretty much everything. I use it for all the small everyday data manipulation tasks I used to write Basic programs for, and all the ones I didn't bother to write Basic programs for because it would have been too much work. My main use is for web development, both online and off. I also use it for simple network clients, games, and puzzle solving algorithms. I even wrote a list based Game Of Life program in it once, but it was grotesquely slow - Basic has to be better for some things I suppose. My ambition is to develop a decent Wimp library in Perl, but until someone ports Perl as a language module it will remain impractical to write small wimp programs in it because each one would require such a huge wimpslot. Just imagine it though! Perl as a module would mean no ten second wait while it loads off disc *every* time, and the ability to run multiple Wimp programs and still have memory left. Basic would be rendered almost redundant as the core language. Ahhh, just the thought of it makes me feel warm all over. Maybe one day... *if* I keep my fingers crossed... > As James says 'Isn't Perl fun?'... It gives you so much power to do anything you want that it's almost magic. Well, *I* certainly get that Harry Potter feeling when I think of an excuse to write something in Perl. :-D -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Uses for Perl
On Thu 21 Mar, Steve Bradburn wrote: > > Then I looked into PHP, and now all my Perl scripts have > been replaced by PHP pages. Traitor! Deserter! ;-) > It seems easier to handle a PHP script (with embedded HTML) in > any directory than Perl scripts in the cgi-bin This depends on the nature of the web applications you're writing. For certain applications it is much easier to maintain them if the "business logic" is clearly separated from the UI presentation. Personally, I much prefer to use HTML templates so that there is no HTML at all in my code, and no code in my HTML. > (I know it needn't be this way with other hosts). Quite so. The hosts I use all allow Perl scripts to be named *.cgi and run from anywhere in the document tree. For anyone else wishing to write large web applications in Perl in a more manageable way, I thoroughly recommend first reading this excellent comparative review of the main web templating systems and frameworks: http://www.perl.com/pub/a/2001/08/21/templating.html I find the introduction quite ironic because I started out using the HTML::Template module and was happy with the results for quite a long time. However, with each new version, HTML::Template seems to move further away from its initial simplicity, and with increasing complexity comes ever more surprising "features" (bugs). As a result I'm seriously considering writing my own much simpler and bug free templating system to replace it, thus moving in the opposite direction to that which the introduction espouses. I had to back-grade from the latest version of HTML::Template because something they've done has broken it on RISC OS. (I think it's a File::Spec related problem but I didn't look into it any further than that.) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: A problem
On Sun 24 Mar, Richard Torrens (RiscOS) wrote: > > It'd not strictly a Perl problem but I'm doing it in Perl... It's not a Perl problem at all! > The problem: how can I tell when Blackhole has finished expiry > and is ready to accept the previous backups? I don't know how Blackhole structures its rubbish directory but perhaps you can look to see how it does it. Your backup program could then create an empty file in a position that Blackhole's expiry process will get to last of all. Then all your program needs to do is poll for the existence of that marker file and when it is gone you will know that Blackhole has finished. Of course, you will probably need to time stamp the marker file to ensure that it will be expired correctly. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: A problem
On Sun 24 Mar, Richard Torrens (RiscOS) wrote: > > In article <[EMAIL PROTECTED]>, > James Taylor <[EMAIL PROTECTED]> wrote: > > > > Then all your program needs to do is poll for the existence > > of that marker file and when it is gone you will know > > that Blackhole has finished. > > I had not thought of that - but Blackhole single tasks during deletions. Then where's the problem? If it single tasks, any program running in a taskwindow on the same machine will not get control back until Blackhole stops single tasking. At this point you know that it has finished and is ready. > Whether a networked command can check the existemce of a file, > I don't know. Trials I have made along these lines throw up an > error window 'Please insert disc etc.' It seems I've misunderstood you. I thought the backup was being controlled by a Perl program running on the machine with Slackhole (whoops typo) Blackhole on it and that files were being copied from that machine onto another on the network. Correct me if I've got this wrong but if you are remotely initiating a reboot on this machine and expecting Blackhole to perform its expiry as part of its startup before it begins to multitask, then all you need is a Filer_Run command in Blackhole's !Run file to trigger off some other program once Blackhole has finished. That other program might be as simple as an obey file that creates an empty marker file on the remote machine, or as complex as a full Perl program to carry on with the backup process. It occurs to me that you wouldn't need to perform a reboot either if you could just send Blackhole a faked Wimp message with a menu clicked reason code. (!Keystroke will do this kind of thing for you if you don't wish to write a little program yourself.) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Latest version of perl?
On Sun 24 Mar, Vincent Lefevre wrote: > > perl froze my machine twice in the last week. Perl freezes the whole machine every time I try to run it on my father's RISC OS 4 RiscPC. I still haven't upgraded to RO4 myself, mainly for fear of encountering such problems. I was trying to run a small network client that works fine on my own machine. Perhaps networking has been broken by RO4? Could RO4 users out there please confirm that my father's experience is a one off and that !Perl 1.13 does work. > I suppose the cause is the UnixLib bug. There seem to be plenty of bugs in UnixLib (that's the trouble with OPC). Which bug are you referring to specifically? What are its symptoms? > But this bug has recently been fixed. Is there a version of > perl that has been compiled and linked with the fixed > version of UnixLib? If anyone succeeds in producing a more up to date Perl for RISC OS, or even just a recompile with a less buggy UnixLib, *please* make it available and let the list know. Thanks. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: A problem
On Tue 26 Mar, Richard Torrens (RiscOS) wrote: > > In article <[EMAIL PROTECTED]>, > James Taylor <[EMAIL PROTECTED]> wrote: > > > > Then where's the problem? If it single tasks, any program running > > in a taskwindow on the same machine will not get control back > > until Blackhole stops single tasking. At this point you know that > > it has finished and is ready. > > Agreed. > > But some operations are on one computer, others on another. Unless > these take place in the correct sequence - there is a problem. Perhaps what you need is two Perl programs talking to each other over the network. It looks fairly easy to do with the standard IO::Socket modules although I've not tried it myself. > Roscli is the command for !OscliD and WO_ is in WindOpen I'm not familiar with OscliD but if you're running it, I hope there's no possibility of anyone on the network being able to abuse it. At least if you wrote two Perl programs talking to each other over IP, you could build in a little security. They wouldn't even need to pass real star commands between them, just messages to indicate to each other that the next stage of the backup procedure should be triggered. > There's a funny in ShareFS about closing a file on a remote > computer. This messes up Perl's open statement, so you cannot > check it for success. Interesting, can you give more details? > Keystroke can do rather too much. I find it impossible to > remember half of what it can do! You're not the only one! In the end I decided it would be easier just to write my own program than try to learn how to use Keystroke. Those that make the effort to learn it say it's revolutionised their lives. I suppose it's no different to learning Perl or Emacs. :-) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Latest version of perl?
On Thu 28 Mar, Vincent Lefevre wrote: > > On Tue, Mar 26, 2002 at 21:58:43 +, James Taylor wrote: > > > > There seem to be plenty of bugs in UnixLib (that's the trouble > > with OPC). Which bug are you referring to specifically? > > I think the one related to the callback, You speak as if we should know what that is. Is there somewhere that we can find out more - maybe a list of known bugs and whether they have been fixed, and if so in which version? http://hard-mofo.dsvr.net/unixlib/ doesn't seem to have much about the state of current development, and certainly no bug database or development schedule. Thanks. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Latest version of perl?
On Fri 29 Mar, Vincent Lefevre wrote: > > I still get problems with perl 1.15 I think you mean 1.13. (Unless there's a new version I don't know about?) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Latest version of perl?
On Fri 29 Mar, Vincent Lefevre wrote: > > On Fri, Mar 29, 2002 at 03:01:35 +, James Taylor wrote: > > > > I think you mean 1.13. > > No, 1.15. > > > (Unless there's a new version I don't know about?) > > AFAIK, it wasn't distributed publicly. Err... so how did you get a copy? How would I get a copy? What are the differences? Shouldn't it be up on flirble.org for everyone? -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Latest version of perl?
On Fri 29 Mar, Vincent Lefevre wrote: > > On Fri, Mar 29, 2002 at 10:24:08 +, James Taylor wrote: > > > > How would I get a copy? > > I can mail it to you if you want (but not before tonight). That's kind but don't you think we should ask Nick first? I'm going to be away for the weekend so I guess I'll have to pick up this conversation again on Tuesday. > > Shouldn't it be up on flirble.org for everyone? > > I don't know. Nick? Are you reading this? -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Until loop
On Mon 01 Apr, Richard Torrens (RiscOS) wrote:
>
> In article <[EMAIL PROTECTED]>,
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> >
> > On Mon, Apr 01, 2002 at 09:47:49AM +0100,
> > Richard Torrens (RiscOS) wrote:
> > >
> > > Can anyone tell me why the following gets stuck?
> > >
> > > until ($ENV{'BlackHole$BinDir'} eq "") {
> > > system ('Unset BlackHole$BinDir');
> > > }
> > >
> > > It gets stuck in a loop as if the test is only tested once.
> >
> > From memory, I think that's pretty close to what actually happens.
> > I think that perl is actually caching things as they get read in %ENV.
Yes, I've just tested this and it looks like Perl populates
each entry in %ENV as you first read from it and then caches
it assuming that this will not change unless you explicitly
do so through the %ENV mechanism. As you said, saying
delete $ENV{'varname'}
is the correct way to unset a system variable so that %ENV stays
in synch. This caching behaviour is presumptuous of the environment
being Unix-like, ie. private to the process rather than shared
between all processes as it is on most other OSes. I think this
behaviour should be considered a bug because even on a Unix
system you might wish to be able to read environment variables
that were exported by a child process. It should certainly be
fixed on ports to OSes with global environment variables.
> > Try this
> >
> > delete $ENV{'BlackHole$BinDir'};
> >
> > in place of the loop. I think it should work (not in a position to
> > test it right now) as I think it will punch out to the real RISC OS
> > environment and delete it there (with no error if it never was there
> > in the first place)
Yes, it works exactly as you (Nick) expected. In addition, while a
particular %ENV entry does not exist, the %ENV mechanism always
reads from the OS and does not use a cached empty value. So
although Richard cannot use %ENV to spot when a variable becomes
*unset*, he could wait for a variable to be *set* for the first
time with something as simple as:
sleep 1 until $ENV{'Blackhole$Finished'};
Richard Torrens (RiscOS) wrote:
>
> Yes. Unfortunately I'm not really trying to merely unset a SysVar here.
[snip]
> I am really trying to test when this deletion has finished as during
> deletions BlackHole is single tasking and the network won't then
> respond work. So after this has terminated I want to feed a signal to
> the loop to release it.
If your Perl program is running in a taskwindow on the same
machine as the Slackhole it's waiting for then it won't get
control back until Blackhole has finished its single tasking.
All you need is something like:
system 'Filer_Run ADFS::HD5.$.DataApps.!BlakHole2' and die $!;
sleep 1; # To give the Wimp time to respond to the Filer_Run
# Blackhole now does its thing single tasking
# Now we've got control back so the backup process can continue
What's wrong with that? When I suggested it before, you seemed
quite positive about the idea. What's changed?
> Setting an Env variable seemed sensible. But not
> if the until {} loop won't read it.
Well, if all else fails you can of course just talk to RISC OS
directly by using a kernelswi call. Here is a subroutine that
will read any type of system variable directly:
sub readvarval ($) {
my $name = shift;
my ($regs, $buffer, $len);
$buffer = "\0" x 1024; # Max length of buffer
$regs = kernelswi('OS_ReadVarVal', $name, $buffer, length $buffer, 0, 3);
return '' unless defined $regs; # Var not found or buffer overflow
$len = (unpack 'i*', $regs)[1]; # R1 = length of string value
return unpack "a$len", $buffer;
}
You will also need to say "use RISCOS::SWI;" at the top of your script.
--
James Taylor <[EMAIL PROTECTED]>
Based in Southam, Cheltenham, UK.
PGP key available ID: 3FBE1BF9
Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Until loop
e doesn't unset its variables when it quits. The idea was to > unset something in the obey file and detect when this was reset. I hope my other posting helps with reading system variables, but I can't see how this helps you because you cannot read the system variables on a remote machine, and you don't need to read them on the local machine if you're only waiting for a single tasking operation to finish anyway. I can't help feeling you're not telling us the full story. > But this is problematical - really I should also climb inside > Blackhole's RunImage and do things there, Eh? Why do you want to do that? > but that's not easy as it's compressed Basic. What? It's free software and the author still wants to hide his source? That would give me concern about what he's really trying to hide... ;-) -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: Warnings switch
On Tue 25 Jun, David H Wild wrote: > > putting "#! -w" as the first line of the program, I think you mean "#!perl -w" probably. Putting "#! -w" has no effect as far as I can see. It certainly doesn't turn warnings on, as intended. -- James Taylor <[EMAIL PROTECTED]> Based in Southam, Cheltenham, UK. PGP key available ID: 3FBE1BF9 Fingerprint: F19D803624ED6FE8 370045159F66FD02
Re: how to generate random number between the range -10 to 10
On Thu 06 Mar, Andrew Green wrote: > > In article <[EMAIL PROTECTED]>, > kenwin charles <[EMAIL PROTECTED]> wrote: > > > > is it possible you can assist me on how to generate random number > > between the range -10 to 10. > > my $num = int(rand 21) - 10; Yes, but please bear in mind that the RISC OS port of Perl does not produce random numbers uniformly from the rand() function. There is a bug in UnixLib upon which RISC OS Perl is dependent, that causes the random number to be generated incorrectly. There was a thread of discussion about the problem on this very mailing list a while back. See the archives at: http://www.mail-archive.com/riscos%40perl.org/msg00106.html Random number generation is poorly understood by most people and, in that thread, I seem to recall having quite a bit a trouble convincing people to look at the facts. Hopefully, we won't have that problem a second time round. :-) -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: newbie seeks advice on cgi.pm
On Tue 03 Jun, [EMAIL PROTECTED] wrote: > > Goto search.cpan.org and look for CGI. > CPAN is you friend. Much to my frustration, I find that CPAN modules rarely just install and work on RISC OS. Many require a compilation step which I cannot get to work. Even those that do not require compilation seem to have failings. For instance, I had been successfully using HTML::Template for both CGI applications and whole site generation offline. Sadly, about a year ago, one of the updates broke the module on RISC OS. This may have had something to do with its reliance upon File::Spec which doesn't appear to work correctly on RISC OS, although I never delved any deeper. Instead, I just stuck with the earlier version, warts and all. In my experience, the only sure way of getting bug-free code is to write it myself. I therefore tend to be wary of using other people's code. My point is that it is not wise to rely on modules that are created and maintained by people who have no knowledge of the limitations of our platform. This is especially true when so many modules require other modules in a web of dependencies. If any of those dependencies change, or any of those modules require compilation, or introduce a bug, or start using Perl 5.6 features, etc, then the whole web of modules suddenly fails to work on RISC OS. It might take you quite a while to trigger those bugs, and unless you want to go through the code of all the involved modules looking for the problem, you're stuck. Don't expect the much lauded cooperative Perl community to notice and correct such problems. These module maintainers don't test on RISC OS and, quite frankly, they are unlikely to care. Given that we're very much on our own in using RISC OS, I advise being self-reliant and not reliant upon CPAN. > A big repository of useful and _never_touch_ modules. You're absolutely right, never touch them! Write your own code, it's the only way to be sure. -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: File::Find
On Sun 15 Jun, "stephane HAbeTT roux" wrote:
>
> I'm trying to use the File::Find module with port 1.13 of version 5.005
>
> My main problem is that directory names are returned by this module,
> along with file names of course. Is that the standard behaviour or
> someting wrong with the RISC OS port ?
It is perfectly standard behaviour. If you wish to ignore
directories then simply test for them in the first line
of your "wanted()" routine like so:
find(sub {
return if -d; # Returns without doing anything if this is a directory
# Process files here
}, '/dir/to/scan');
--
James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: The 5.8.0 port anyone?
On Tue 01 Jul, Glyn Royds wrote: > > Back in March Alex reported that he had a port of 5.8.0 but his site is down > :( Does anyone else know where this (or even 5.6) could be found? I'd also love to get my hands on a later version of Perl for RISC OS, but I recall Alex Waugh saying that his port was not complete and was very much alpha test only. > 5.005 doesn't get along too happily with the sprintf'ing (%b016) > that I need :-( What is %b016 supposed to do? Perhaps it would be better to write a routine for Perl 5.005 to do it. That way you wouldn't be dependent on 5.8 and could run your program on RISC OS using a more stable version of Perl. -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: The 5.8.0 port anyone?
On Wed 02 Jul, Glyn Royds wrote:
>
> James Taylor <[EMAIL PROTECTED]> wrote:
> >
> > What is %b016 supposed to do? Perhaps it would be better to write a
> > routine for Perl 5.005 to do it.
>
> It converts a number to binary, padded out to 16 characters with 0's.
> As something of a perl novice I was about to start writing a routine
> to do the same
Well, here's one:
sub tobinary ($$) {
my $mask = 1 << shift;
my $value = shift;
my $binary;
$binary .= ($value & $mask) ? '1' : '0' while $mask >>= 1;
return $binary;
}
Just pass it the wordsize and the integer value to convert.
Example:
print tobinary 16, 0x0AF5;
10100101
Hope that helps.
--
James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: The 5.8.0 port anyone?
On Wed 02 Jul, James Taylor wrote: > > On Wed 02 Jul, Glyn Royds wrote: > > > > It converts a number to binary, padded out to 16 characters with 0's. > > As something of a perl novice I was about to start writing a routine > > to do the same > > Well, here's one: [...snip...] And if you know it will always be a 16-bit integer you can use pack/unpack like this: unpack 'B16', pack 'n', $value; ...which is bound to be quicker than my subroutine solution. -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: trailing spaces
On Wed 20 Aug, Colin Foster wrote: > > Is there an easy way to remove the trailing > spaces in the string "TRAILING SPACES " Hmmm, I'm not sure whether to give you a fish or a fishing rod. The fish is: $string =~ s/ +$//; But, more usefully, the fishing rod is: Learning Perl, 3rd edition http://www.oreilly.com/catalog/lperl3/ or: The site for people learning Perl http://learn.perl.org/ or even: Online Perl documentation http://www.perldoc.com/ -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: trailing spaces
On Thu 21 Aug, Roger Horne wrote: > > On Wed 20 Aug, James Taylor wrote: > > > > But, more usefully, the fishing rod is: > > > > Learning Perl, 3rd edition > > http://www.oreilly.com/catalog/lperl3/ > > That was the 1st (out of many) Perl book that I bought and > I found it awful. Really? I found it clear and easy. I enjoyed the humour too. > Horses for courses I suppose, but so far as I was > concerned Programming Perl was immeasurably better. Agreed, every serious Perl programmer is lost without Programming Perl: http://www.oreilly.com/catalog/pperl3/ > The one I use most is, I think, the Perl Cookbook. Strangely, although I have it, I tend to refer to it only when I'm completely stumped (ie. rarely). However, I agree that it is a great book. http://www.oreilly.com/catalog/cookbook/ > A point that I have never seen dealt with is why, in order to > trim at both ends, the recipe uses > $string =~s/^\s+//; > $string =~s/\s+$//; > rather than say > $string =~s[^\s*(.*?)\s*$][$1]; There's a very good reason for that. The first pair do not require any backtracking and can execute very quickly. The latter technique can involve a great deal of backtracking and, in the worst case, could take a very long time indeed. As a contrived example, run this: $string = ' a' . ' ' x 10 . 'z '; print "Starting first trim method\n"; $string =~ s/^ +//; $string =~ s/ +$//; print "Finished\n"; # Instantly $string = ' a' . ' ' x 10 . 'z '; print "Starting second trim method\n"; $string =~ s/^ *(.*?) *$/$1/; print "Finished\n"; # Six minutes later... zzz... I understand the natural desire to express the conceptually atomic trim operation as a single line. The idiom I sometimes use is: s/^ +//, s/ +$// for $string; Even better, this generalises neatly for more than one string: s/^ +//, s/ +$// for $string1, $string2, $string3; s/^ +//, s/ +$// for @whole_file_of_lines; PS. There's rather too much netlag on this mailing list. When I posted my response to Colin I thought I was the first but in fact there were four other people ahead of me, and I may find that this post is redundant for the same reason. Sigh. -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
Re: how to set up !Perl
too Unix specific and I don't know enough about porting Unix software. (If anyone else has had success in this area and can offer tips, I'd love to know.) The bottom line is that many Perl modules cannot be installed on RISC OS and furthermore none of the modules that depend on those other modules can be installed either. Bummer eh? >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. The last line there is the directory into which you may install any modules you find which are Perl-only and are not dependent upon other modules that require compilation. Yes, there are a few. > I cannot believe that I am supposed to rearrange all the packages > into directories > /home/riscos/cross/local/lib/perl5/5.8.0/riscos-aof > /home/riscos/cross/local/lib/perl5/5.8.0 > /home/riscos/cross/local/lib/perl5/site_perl/5.8.0/riscos-aof > /home/riscos/cross/local/lib/perl5/site_perl/5.8.0 > /home/riscos/cross/local/lib/perl5/site_perl Where did you get those directories from? > It is equally hard to believe that I am supposed to edit the start of > each and every supplied script to make it change @INC at compile time; I've never found that necessary on my own machine. It tends to be necessary only on systems where you cannot update the central module repository but where you can install modules into your own home directory. > apart from that, attempts to do it failed. Is there a way to do it > globally? You shouldn't need to on RISC OS, but if you wanted to add specific directories to the setting of PerlSiteLib$Path in the !Perl.!Boot file then nobody would stop you. > 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, but you may not find it as convenient as you were hoping. > 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. :-) Good luck! -- James Taylor, Cheltenham, Gloucestershire, UK. PGP key: 3FBE1BF9
