On Wed, 20 Apr 2005, [ISO-8859-2] BÁRTHÁZI András wrote:
I'm just wondering, if the following would be possible with Perl 6 or not?
XML
$a=Content #1Content #2;
[snip]
The ideas coming from Comega, the next version of CSharp(?). Here's an intro
about it:
Some time ago I asked a somewhat related qu
Are the -X functions still going to be there? I definitely hope so!
However, to come to the actual question, it has happened to me to have to
do, in perl5 that is:
perl -lne 's/^"//;s/"$//;print if -e'
or (less often)
perl -lne '$o=$_;s/^"//;s/"$//;print $o if -e'
Ok: no much harm done (to my fi
It has been published at perl6.language, but have no reply.
In perl v5.8.6 built for MSWin32-x86-multi-thread:
my $i = 1;
print $i++, ++$i; # 1 3
my $i = 1;
print ++$i, $i++; # 3 2
in pugs:
my $i = 1;
say $i++, ++$i; # 1 3
my $i = 1;
say ++$i, $i++; # 2 2
which is right?(I think perl5 is) or
Chip Salzenberg <[EMAIL PROTECTED]> writes:
> According to Michael G Schwern:
>> In the same way that we have open() not fopen, fdopen, freopen... we
>> can choose the safest and most sensible technique for determining
>> the cwd and use that.
>
> And there is more than one open. Perl does have f
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> In classes/float.pmc, the MMD_DEFAULT branch of i_subtract tries to
> return a value, even though the function is defined as 'void'.
Thanks, applied.
leo
On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote:
> It has been published at perl6.language, but have no reply.
>
> In perl v5.8.6 built for MSWin32-x86-multi-thread:
>
> my $i = 1;
> print $i++, ++$i; # 1 3
> my $i = 1;
> print ++$i, $i++; # 3 2
>
> in pugs:
>
> my $i = 1;
> say $i++,
Are default values supported for attributive parameters in an argument list?
I wish to convert these 2 subroutines to perl6:
sub foo {
my $self = shift;
$self->{foo} = defined $_[0] ? shift : undef;
}
sub bar {
my $self = shift;
$self->{bar} = defined $_[0] ? shift : $DEFAULT;
}
Is th
Carl Franks skribis 2005-04-21 11:29 (+0100):
> I wish to convert these 2 subroutines to perl6:
> sub foo {
> my $self = shift;
> $self->{foo} = defined $_[0] ? shift : undef;
> }
> sub bar {
> my $self = shift;
> $self->{bar} = defined $_[0] ? shift : $DEFAULT;
> }
> Is this correct?
Thos
Johan Vromans skribis 2005-04-21 8:22 (+0200):
> This is exactly the point (I think) Schwern is trying to make. There
> is 'open', that will do most of the time. If a novice user asks how to
> open a file, you can say "Well, just 'open $fh, $file'". If you want
> more than vanilla file access, th
Paul Johnson <[EMAIL PROTECTED]> writes:
> I think I understand the implementation details leading to each
> behaviour, but rather than saying which was "right", I think I'd be
> quite happy to see Perl6 copy (the ideas behind) C's rules regarding
> sequence points and undefined behaviour. I'm no
On Wed, Apr 20, 2005 at 11:30:09PM -0400, Stevan Little wrote:
> It would also allow for code like this:
>
> force_todo(1, 5, 10 .. 15, 25);
>
> Which (IMHO) is nicer than having to do this in the t/force_todo file:
>
> t/my_test.t 1 5 10 11 12 13 14 15 25
>
> I also think that havi
On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote:
> On Thu, Apr 21, 2005 at 04:32:41PM +0800, fayland wrote:
>
> > It has been published at perl6.language, but have no reply.
> >
> > In perl v5.8.6 built for MSWin32-x86-multi-thread:
> >
> > my $i = 1;
> > print $i++, ++$i; # 1 3
> >
> On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote:
> It certainly makes more sense to me that the answer would be 2 2. But
> however it ends up, so long as we know what the answer will be, we can
> utilize it effectively in our programs.
The trick with this construct usually in C is
On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
> We'll make continuations available in Perl for people who ask for
> them specially, but we're not going to leave them sitting out in the
> open where some poor benighted pilgrim might trip over them unawares.
Sorry for replying so late,
Hi,
Stevan Little iinteractive.com> writes:
> - Should we remove all the todo_* functions and just use the
> t/force_todo file?
the idea was that t/force_todo lists the tests which are only
TODOed because of release preparation, and the todo_* functions
mark tests which are real TODO te
On Thu, Apr 21, 2005 at 02:28:52PM +0100, Matthew Walton wrote:
> > On Thu, Apr 21, 2005 at 11:45:27AM +0200, Paul Johnson wrote:
>
> > It certainly makes more sense to me that the answer would be 2 2. But
> > however it ends up, so long as we know what the answer will be, we can
> > utilize it e
Ingo,
On Apr 21, 2005, at 10:03 AM, Ingo Blechschmidt wrote:
- Should we do away with the t/force_todo file and introduce a
force_todo() function?
The idea is to move from the more centralized t/force_todo file to a
more decentralized force_todo() function which would accept a list of
test numbers
Hi,
Stevan Little wrote:
>> The idea was that t/force_todo can be deleted/cleared after a
>> release, so all tests which were only force_todoed were instantly
>> unTODOed.
>
> Unfortunately that is not how it is being used though. It sticks
> around, and in some cases maybe even being used as a i
On Thu, Apr 21, 2005 at 04:30:07PM +0300, wolverian wrote:
: On Tue, Apr 12, 2005 at 04:17:56AM -0700, Larry Wall wrote:
: > We'll make continuations available in Perl for people who ask for
: > them specially, but we're not going to leave them sitting out in the
: > open where some poor benighted
On Thu, Apr 21, 2005 at 10:18:17AM +0200, Michele Dondi wrote:
: Are the -X functions still going to be there? I definitely hope so!
Certainly. They're useful, and one of the things people love about Perl.
In fact, we're enhancing them to be stackable, so you can say
if -r -w -x $filename {
On Thu, 21 Apr 2005 08:36:28 -0700, [EMAIL PROTECTED] (Larry Wall) wrote:
>
> Hmm, maybe that's not such a bad policy. I wonder what other "dangerous"
> modules we might have. Ada had UNCHECKED_TYPE_CONVERSION, for instance.
>
How about
use RE_EVAL; # or should that be REALLY_EVIL?
>
On Thu, Apr 21, 2005 at 08:22:29AM +0200, Johan Vromans wrote:
: >From the perspective of 'current directory' there should also be a
: simple and elegant way that will do in most cases. Advanced tricks can
: be made possible using separate modules and such.
Yes, easy things should be easy, and har
Larry Wall skribis 2005-04-21 8:54 (-0700):
> if $filename ~~ -r & -w & -x {...}
Just curious - would the following dwym?
if (&prefix:<-r> & &prefix:<-w> & &prefix:<-x>)($filename) { ... }
> It seems to me that -e «$_» would handle most of these cases, as long as
> whitespace always com
On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote:
> Although after some discussion with nothingmuch on IRC, I think I have
> come to good compromise.
>
> We remove all the todo_ functions, and we add a named param "todo" to
> all our test functions. This would allow test level TODO-
"use matchpairs" not working. Currently having perl 5.0 in my system.
Please suggest.
Manoj
On Apr 21, 2005, at 12:00 PM, Nathan Gray wrote:
On Thu, Apr 21, 2005 at 11:17:11AM -0400, Stevan Little wrote:
Although after some discussion with nothingmuch on IRC, I think I have
come to good compromise.
We remove all the todo_ functions, and we add a named param "todo" to
all our test function
Larry Wall <[EMAIL PROTECTED]> wrote:
> Assuming we
> rehuffmanize "kill" to "sendsignal" or some such, we have:
"signal" is a verb as well as a noun.
sub alarm ($secs) {
{ signal $*PID, Signal::ALARM }.cue(:delay($secs));
}
It even reads pretty nicely: "signal 4242".
--
Brent 'D
On Thu, Apr 21, 2005 at 01:51:36PM -0700, Brent 'Dax' Royal-Gordon wrote:
: Larry Wall <[EMAIL PROTECTED]> wrote:
: > Assuming we
: > rehuffmanize "kill" to "sendsignal" or some such, we have:
:
: "signal" is a verb as well as a noun.
:
: sub alarm ($secs) {
:{ signal $*PID, Signal::A
On Thu, Apr 21, 2005 at 06:40:54PM +0200, Juerd wrote:
: Larry Wall skribis 2005-04-21 8:54 (-0700):
: > if $filename ~~ -r & -w & -x {...}
:
: Just curious - would the following dwym?
:
: if (&prefix:<-r> & &prefix:<-w> & &prefix:<-x>)($filename) { ... }
It might do what you mean. Per
Now that we're using SVN,
Leopold Toetsch wrote:
> Some outdated files:
>
>lib/Parrot/PackFile/*
>lib/Parrot/PackFile.pm
>lib/Parrot/PackFile2.*
>
> what is:
>
>lib/Parrot/String.pm old packfile code?
>lib/Parrot/Types.pm same?
>lib/Parrot/Key.pm same?
All the ab
Matt Diephouse wrote:
Leopold Toetsch wrote:
classes/pmcarray.pmc wrapper for PerlArray
I'm not sure what was discussed here.
I believe this is a remnant from before it was decided that we'd use "Resizable" and
"Fixed" for container types; Anything that's using PMCArray should be switched t
I've encountered some multimethod dispatch funnyness tonight. The
included code which one would expect to produce a value of 1 ends up
printing a value of 3.
Changing "a" and "b" to be regular Integer types seems to work. Can
anybody shed any more light on this?
-c
.sub _main @MAIN
.local
Cory Spencer <[EMAIL PROTECTED]> wrote:
> For examples of what it can currently do, look in the lisp/ subdirectory
> in the files loaded at run time (bootstrap.l system.l and primitives.l).
>
> Anyone who would like to have a peek at what I've got so far is invited to
> download the 0.1.0 release
33 matches
Mail list logo
