Re: Trying to use Perl5 modules
Where is .can documented?
I saw .can in one of the examples in the pugs distribution, but I didnt
know where it came from, viz., was it related to perl6 or the module
that had been imported.
Not quite sure how the following two statements can be consistent:
'imports from Perl5 modules dont work' and 'there is a workaround with
.can'. From the code examples below, .can seems to be importing the
methods from the modules.
If .can is a universal workaround, then surely a pugs wrapper could be
written for any perl5 module along the lines
use v6-alpha;
use perl5:SomeModule::SomeSubModule;
our aPublicSub := SomeModule::SomeSubModule.can('aPublicSub');
and so on for all the sub's in the module.
Regards,
Richard
Trey Harris wrote:
In a message dated Mon, 11 Sep 2006, Richard Hainsworth writes:
I am trying to find out how to use (in perl6) perl5 modules that
contain subroutines.
Imports from Perl 5 modules don't currently work.
You can workaround this using .can, see below.
use perl5:Time::gmtime;
my $gm = gmtime();
printf The day in Greenwich is %s\n,
(qw(Sun Mon Tue Wed Thu Fri Sat Sun))[ $gm.wday() ];
# note the change from - to .
use v6-alpha;
use perl5:Time::gmtime;
our gmtime := Time::gmtime.can('gmtime');
my $gm = gmtime();
say The day in Greenwich is {(Sun Mon Tue
Wed Thu Fri Sat Sun)[ $gm.wday ] };
There is no printf. You can use a string closure as above, or
say/print with sprintf.
The same goes for your other example:
use perl5:Text::Balanced qw(extract_tagged);
my $txt = 'atagnow and then/atagsome text';
my @ret_pars = extract_tagged($txt); # this is line 8
print join(\n,@ret_pars),\n;
#print [EMAIL PROTECTED] if $@;
# commented this out as caused a compile error, probably another
# variable should be used for errors.
use perl5:Text::Balanced;
our extract_tagged := Text::Balanced.can('extract_tagged');
my $txt = 'atagnow and then/atagsome text';
my @ret_pars = extract_tagged($txt); # this is line 8
.say for @ret_pars;
say $! if $!;
$@ is no more, it's $! for all errors whatever their provender. In
this case there's no need for a join, but you could have written it:
say @ret_pars.join(\n);
if you liked.
All that said, there's a problem with Text::Balanced running under
pugs; @ret_pars is reversed from what it should be. I'm not sure
what's going on.
Trey
Re: Trying to use Perl5 modules
在 Sep 11, 2006 2:07 PM 時，Trey Harris 寫到： In a message dated Mon, 11 Sep 2006, Richard Hainsworth writes: I am trying to find out how to use (in perl6) perl5 modules that contain subroutines. Imports from Perl 5 modules don't currently work. Actually, explicit imports do work (as of a couple weeks ago): use perl5:Time::gmtime gmtime; say gmtime.wday; Implicit imports is not yet supported, though... Audrey
Re: Web.pm or something (Re: the CGI.pm in Perl 6)
At 5:00 PM +0100 9/13/06, David Cantrell wrote: On Tue, Sep 12, 2006 at 03:08:03PM -0700, Darren Duncan wrote: The word CGI generally speaks to an old, weak, and relatively inefficient technology ... modern proper stuff does not spin off a separate process for each server request; it reuses an existing server ala mod_perl. To me the Commong Gateway Interface means a standard method for dealing with data supplied by the user, nothing more. It certainly doesn't specify how you should implement it. Indeed, every mod_perl application I've seen uses CGI. I beg to differ. CGI is very much an implementation detail. It is a gateway protocol for how 2 different processes communicate. See: http://www.w3.org/CGI/ An HTTP server is often used as a gateway to a legacy information system; for example, an existing body of documents or an existing database application. The Common Gateway Interface is an agreement between HTTP server implementors about how to integrate such gateway scripts and programs. And: http://en.wikipedia.org/wiki/Common_Gateway_Interface The Common Gateway Interface (CGI) is a standard protocol for interfacing external application software with an information server, commonly a web server. This allows the server to pass requests from a client web browser to the external application. The web server can then return the output from the application to the web browser. Because this technology generally requires a fresh copy of the program to be executed for every CGI request, the workload could quickly overwhelm web servers, inspiring more efficient technologies such as mod_perl or ASP that allow script interpreters to be integrated directly into web servers as modules, thus avoiding the overhead of repeatedly loading and initializing language interpreters. So CGI is absolutely not a good name for a new and modern module's design where the module's functionality isn't CGI-specific. -- Darren Duncan
