Andy Dougherty (via RT) wrote:
With a a fresh checkout (r9274) I get a number of errors where parrot eventually
gobbles up all the memory on the system. Here's the first such one:
t/op/gc
# Failed test (t/op/gc.t at line 279)
# './parrot --gc-debug "/home/doughe
Juerd:
> Ruud H.G. van Tol:
>> s/($search)/*\1*/go
>
> \1 in Perl 5 is bad style and emits a warning
The point was to give \1 and \&, in the replace part, a very limited
scope.
Maybe even better to limit \1 to the first '(?: ... )' in the search
part.
s/(?:$search)(?:.\1)+/\1/go
xy.xy.xy.x
# New Ticket Created by François PERRAD
# Please include the string: [perl #37312]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37312 >
This small patch enables t/library/pcre.t on Win32.
François Perrad.
pcre.patch
D
TSa <[EMAIL PROTECTED]> writes:
> BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
CATCH Exception { say "Why do you hate freedom?" }
--
Piers Cawley <[EMAIL PROTECTED]>
h
> This small patch enables t/library/pcre.t on Win32.
>
thanks, applied (with minor changes due to a modified README.win32) -- r9281
~jerry
HaloO,
Yuval Kogman wrote:
The try/catch mechanism is not like the haskell way, since it is
purposefully ad-hoc. It serves to fix a case by case basis of out
of bounds values. Haskell forbids out of bound values, but in most
programming languages we have them to make things simpler for the
maint
On Mon, Sep 26, 2005 at 10:19:29PM +0200, Juerd wrote:
: In Perl 6, the match object $/ will instead be used. It's a bit harder
: to use with s///, because it will look ugly, but remember that you can
: always choose to use s^^^ or s[][] or any other of the many
: possibilities instead.
It's alway
On Thu, Sep 29, 2005 at 11:21:20PM -0600, Luke Palmer wrote:
[ discussion on undefs elided ]
Since we can annotate our undefs now, perhaps undefs that would be
generated because there are no previous or next elements get "tagged"
as such. Something like:
# assuming $b and $a are "before"
HaloO Piers,
you wrote:
TSa <[EMAIL PROTECTED]> writes:
BTW, I would call *intentional* exceptions terrorism.
So that would be all exceptions then. They all get implemented somewhere, even
the ones that get thrown by builtins.
I knew that the statement would emotionalize. Sorry to all who
Austin~
On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> Matt Fowles wrote:
>
> >Austin~
> >
> >On 9/29/05, Austin Hastings <[EMAIL PROTECTED]> wrote:
> >
> >
> >>Plus it's hard to talk about backwards. If you say
> >>
> >>for @l -> ?$prev, $curr, ?$next {...}
> >>
> >>what happens when yo
On Fri, Sep 30, 2005 at 18:02:46 +0200, TSa wrote:
> I knew that the statement would emotionalize. Sorry to all who don't
> like it an this list. But somehow I found it describes the impression
> on the handling side somewhat. And I thought it illustrates that exceptions
> shouldn't be considered j
On Fri, Sep 30, 2005 at 17:09:23 +0200, TSa wrote:
> And it is the type system that guaranties the availability
> of the required information e.g. in $!.
$! is polymorphic.
Since CATCH is a topcializer, and you use when blocks to case over
$!, you can check to see if it has the metadata you want
Eeek. Yes, I forgot just how crazy a language it was. :-D
> Yes, that's the plan, but the initial implementation isn't going to
> be a compiler like most people would expect:
>
> For example, something like:
>
> while {$a < 10} { incr a }
>
> while isn't language syntax. it's a command. So, this c
# New Ticket Created by François PERRAD
# Please include the string: [perl #37316]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=37316 >
This patch updates PLATFORMS for MinGW.
$ parrot -V
This is parrot version 0.2.3-d
On 9/30/05, via RT François PERRAD <[EMAIL PROTECTED]> wrote:
> This patch updates PLATFORMS for MinGW.
>
applied, thanks.
On Fri, 30 Sep 2005, Leopold Toetsch via RT wrote:
> Andy Dougherty (via RT) wrote:
>
> > With a a fresh checkout (r9274) I get a number of errors where parrot
> > eventually
> > gobbles up all the memory on the system. Here's the first such one:
> >
> > t/op/gc
> > #
Aloha,
it looks like Test::More 0.61 broke Glib's test suite again, so I'm
beginning to wonder if we're doing something stupid. Hence the
question: How do you properly test an object's overloaded array
dereference operator @{}?
When we initially wrote the tests, we simply used is_deeply() or
eq(
On Fri, 2005-09-30 at 23:13 +0200, Torsten Schoenfeld wrote:
> it looks like Test::More 0.61 broke Glib's test suite again, so I'm
> beginning to wonder if we're doing something stupid. Hence the
> question: How do you properly test an object's overloaded array
> dereference operator @{}?
Does d
On Fri, Sep 30, 2005 at 11:13:13PM +0200, Torsten Schoenfeld wrote:
> Stringification again. Changing the tests back to using is_deeply()
> doesn't change a thing; same failure. That's where I give up. Where's
> the mistake?
There's not really a mistake, more that if a given reference is overlo
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
On 9/30/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Rather than addition Yet Another Feature, what's wrong with just using:
>
> for @list ¥ @list[1...] -> $curr, $next {
> ...
> }
>
> ???
Thanks. I missed that one.
However, I think your point is pretty much the sam
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As I remember it zip hrows
Mark A. Biggar wrote:
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Shouldn't that be:
for [EMAIL PROTECTED], undef] ¥ @list[1...] -> $curr, $next {
...
}
As
Damian Conway wrote:
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
There's nothing particularly wrong with it -- just as ther's nothing
particularly wrong with any number of other "we don't need thi
2005-09-30 Darren Duncan <[EMAIL PROTECTED]>
--
I would like to acknowledge that, despite all the good things that
have come out of it, I have had some significant problems in regards
to the past development of my Rosetta rigorous database porta
hi,
I read that with the new calling conventions, there are a variable number of
registers. So, if I understand correctly, if a function call takes 2
parameters, then there are only 2, and if there are 30 parameters, there will
be a frame holding 30 registers. Is this about right?
How does thi
26 matches
Mail list logo
