Re: [perl #37308] Parrot gobbles up all the memory
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/doughera/src/parrot/parrot-andy/t/op/gc_13.pir"' failed with exit code 131 # Looks like you failed 1 test of 22. Strange. The test succeeds on linux/86 and OS/X 10.3 darwin. Running it through valgrind on the linux box doesn't show any indication of an error. t/op/gc_13 is using continuations for backtracking and a few closures. Maybe you can compare used features of other failing tests, so that the error reason can be narrowed a bit. A debug session could also reveal some error cause. leo
perl6-all@perl.org
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.xy --> xy
But if Perl6 can do the same with
s/($search)(.\1)+/$1/go
by detecting that the possible $1 and $2 and $& (or new equivalents) are
(almost certainly) not going to be used, that's of course best.
A '+' can often be optimized to a {2,}. In this case:
s/($search)+/$1/
only if the resulting count is never used.
--
Grtz, Ruud
[perl #37312] [PATCH] pcre on Win32
# 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 Description: Binary data
Re: Exceptuations
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]>
http://www.bofh.org.uk/
Re: [perl #37312] [PATCH] pcre on Win32
> This small patch enables t/library/pcre.t on Win32. > thanks, applied (with minor changes due to a modified README.win32) -- r9281 ~jerry
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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
maintenance programmer.
My view here is that the parameters in the code pick a point in
the range from free on the one end and bound at the other end.
The unifying concept is constraints. So I see the following boundary
equalities:
unconstraint = free # 0.0
contstraint # 0.0^..^1.0
fully constraint
as the black and white ends with shades of gray in the middle.
And it is the type system that guaranties the availability
of the required information e.g. in $!. In that sense a sub
with a CATCH block is a different type than one without. This
difference is taking into account when dispatching exceptions.
Reentrancy is an implementation detail best left unmentioned.
Uh ohh, in an imperative language with shared state outside
the unshared state of multiple invocations of one sub the reentrance
proplem is just there. Interestingly it is easily unifyable with
shared data.
Assume that every bit of code you can run in perl 6 is first class
code - it gets safety, calls, control flow, exceptions, and so
forth.
Just to synchronize our understanding, I see the following
equivalences from the data and code domains
datacode
class = sub
instance = invocation
To illustrate my view consider
class foo
{
has ...
method ...
}
and match with
sub foo
{
has ... # my named parameters defined in body proposal
BEGIN ...
CATCH ...
label:
}
What I want to say is that calling a sub means creating an
instance of the class that describes---or *constrains*---
the potential invocations. If such an invocation is left
lying in memory unfinished we have a continuation. How concurrent
these continuations are stepped in real time with respect to their
respective inner causal logic is irrelevant to the concept.
But *causality* is important!
The view I believe Yuval is harboring is the one examplified
in movies like The Matrix or The 13th Floor and that underlies
the holodeck of the Enterprise: you can leave the intrinsic
causality of the running program and inspect it. Usually that
is called debugging. But this implies the programmer catches
a breakpoint exception or some such ;)
Exception handling is the programmatic automatisation of this
process. As such it works the better the closer it is in time
and context to the cause and the more information is preserved.
But we all know that a usefull program is lossy in that respect.
It re-uses finite resources during its execution. In an extreme
setting one could run a program *backwards* if all relevant
events were recorded!
Yes, even signals and exceptions.
The runtime is responsible for making these as fast as possible
without being unsafe.
Hmm, I would see the type system in that role. It has all the
information of the interested parties in a longjump. If it knows
there are no potential handlers
It can't be a method because it never returns to it's caller - it's
It beeing the CATCH block? Then I think it *is* in a certain
way a method with $! as it's invocant. HiHi and here a locality
metric for dispatch applies. BTW, how is the signature of a CATCH
block given? Simply
CATCH SomeException {...}
or is inspection with cascaded when mandatory?
a continuation because it picks up where the exception was thrown,
I would say it is given information about. In a way an exception
handler is dispatched on the type of exception.
and returns not to the code which continued it, but to the code that
would have been returned to if there was no exception.
This is the thing that I see is hardly possible from a far away scope.
But fair enough for closely related code.
It is, IMHO a multi though. There is no reason that every
continuation cannot be a multi, because a continuation is just a
sub.
I don't know if there are method continuations - i guess there could
be, but there's no need to permutate all the options when the
options can compose just as well.
My view is that a (free) method type becomes a continuation
as follows:
1) the invocant type is determined
2) the dispatcher selects a matching target
3) this method maker object (like a class for constructing data objects)
is asked to create a not yet called invocation and bind it to the
invocant at hand
4) at that moment we have a not yet invoked sub instance, so
plain subs just start here
5) The signature is checked and bound in the environment of the calling
scope, the callers return continuation is one of the args
6) then this invocation is activated
7a) a return uses the return continuation in such a way that
the invocation is abandoned after the jump
b) a yield keeps the continuation just like a constructed object
and p
perl6-all@perl.org
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 always bothered me a little to use $/ "the object" when you
want to refer explicitly to the string matched, especially if the
object knows it matched more than the string is officially matching.
I think we could go as far as to say that $<> is the name of the text
that would be returned by ~$/ and the number that would be returned
by +$/. If we did that, I think we could get away with making
/frontstuff < \w* > backstuff/
a shorthand for
/ $<>:=( \w* ) /
The space after the < would be required, of course. It works because
in the form, the default is to take the argument as rule,
and here we merely have a null "foo".
That gives us cool things like
s/back \s+ < \d+ > \s+ times/{ $<> + 1 }/
to increment the number of times the quick brown fox jumped over the
lazy dog's back.
Larry
Re: Maybe it's Just Nothing (was: Look-ahead arguments in for loops)
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" and "after" elements
for @list -> ?$b, $c, $?a {
given $b {
when undef but generated { say "a fake undef!"; }
when undef { say "a real undef!"; }
}
}
> Oh, right, and as for my favorite actual usage of for:
>
> for @list, :lookbehind(2) :lookahead(1)
> -> $behind1, $behind2, $value, $ahead {
> ...
> }
Hmm. Something like:
for @list -> $c :behind($b1,$b2) :ahead($a1) { ... }
would seem to make a more direct connection between the variables and
what they are aliased to (if only there wasn't that use/mention problem
with the variables).
I think there needs to be something that clearly and unambiguously says
that C<$c> is the value being iterated over and clearly makes a
correspondence between the other variables and their position relative
to C<$c> even with whatever other syntactic mumbling may be necessary.
(And maybe the proposed use of ? is it, but it feels wrong to me)
But, don't we have something like
for @list.kv -> $i,$x { ... }
and even if I'm misremembering @Larry's blessing on that particular
construct, we certainly have this:
for zip([EMAIL PROTECTED](),@list) -> $i,$x { ... }
And then getting the values fore and aft of the current value is just a
matter of indexing into @list. This seems clearer to me than virtual
parameters that exist on either side of the sliding window of the "real"
parameters.
Also, since for seems to be some kind of non-consumptive iterator, maybe
we can get at it with some magical $?ITERATOR variable if we need to:
for @list -> $x {
my ($b1,$b2) = $?ITERATOR.prev(2);
my ($a) = $?ITERATOR.next;# defaults to next(1)
}
Though that's far more syntax than using zip, but has the advantage
that it would work when @list really is a list rather than an array.
I still like using zip() or .kv and indexing the array directly. Putting
the values in an Array-like thingy seems to be a smallish price to pay
for easily getting at some number of elements before or after the
current element.
Rambling in a pre-caffienated way,
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Exceptuations
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 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 just another tool.
CATCH Exception { say "Why do you hate freedom?" }
I don't. But the freedom of the individual ends where the
community begins.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: Look-ahead arguments in for loops
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 you have two items in the list? I think we're best off
> >>using signature rules: optional stuff comes last.
> >>
> >>
> >
> >I disagree, I think that is an easy call
> >
> >for (1, 2) -> ?$prev, $cur, ?$next {
> > say "$prev -> $cur" if $prev;
> > say $cur;
> > say "$cur -> $next" if $next;
> > say "next";
> >}
> >
> >should print
> >
> >1
> >1 -> 2
> >next
> >1 -> 2
> >2
> >next
> >
> >
> >
> Did you mean:
>
> next
> 1 -> 2 # two spaces
>
> there?
No, my logic is that the loop is run through twice, once with (undef,
1, 2) and once with (1, 2, undef).
Matt
--
"Computer Science is merely the post-Turing Decline of Formal Systems Theory."
-Stan Kelly-Bootle, The Devil's DP Dictionary
Re: Exceptuations
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 just another tool.
I think you're taking it too seriously. I'm 99% sure Piers was
joking.
Regardless, exceptions *are* just another tool. They let you write
safe code in fewer words and with less distraction.
For example, Either you linearly serialize the entire tree of
possible events:
if (my $handle = open "file") {
# the handle is open
if (my $other_file = open "other" :w) {
for =<$handle> -> $line {
unless ($other_file.print($line)) {
$*ERR.print("other could not be written
to: $!"); # disk might be full
if (close $other_file) {
if (close $handle) {
exit 1;
} else { ...; exit 1 }
} else { ...; exit 1 }
}
exit 0;
}
} else {
$*ERR.print("could not open other for writing: $!");
if (close $handle) {
exit 0;
} else {
$*ERR.print("could not close file: $!"); # not
logical,
# since we don't write to file, but this is
"safer"
exit 1;
}
}
} else {
print $*ERR, "could not open file: $!";
exit 1;
}
or you could throw exceptions:
use fatal;
my $handle = open "file";
my $other_file = open "other" :w;
for =<$handle> -> $line {
$other_file.print($line);
}
If you are going to avoid exceptions because they are too much
for your taste, then I think you are misusing a language
that has support for exceptions.
I really don't understand why this has to do with freedom, or it's
restriction. It's your personal (and IMHO bad) taste not to use
exceptions for improving your code, but it's still your choice.
All I was saying is that you could leverage exceptions by letting
the UI code make the handling of exceptions a two way route, instead
of one way.
> > CATCH Exception { say "Why do you hate freedom?" }
>
> I don't. But the freedom of the individual ends where the
> community begins.
I think this is a big exaggeration. The community will not be harmed
if the individual uses exceptions.
On the contrary, i would be much happier to use code that does
through exceptions.
For example, a very useful perl 5 module, UNIVERSAL::require, lets
me write:
$class->require or die $UNIVERSAL::require::ERROR;
instead of
eval "require $class"; die $@ if $@;
but in both cases I have to check for errors, unlike
require Class;
I still prefer $class->require, though, because it feels more
readable to me. I don't say to myself "wtf? why is this code doing
an eval" while reading the code.
In perl 6, we would ideally have:
use fatal;
$class.require; # lives if class exists, dies if class doesn't exist
$class.method; # always lives (if method really exists)
or
use fatal;
try { $class.require } # always lives
$class.method; # might die, but at least it's obvious
or
no fatal;
$class.require; # always lives\
$class.method; # might die
In fact UNIVERSAL::require's author agrees with me:
http://use.perl.org/~schwern/journal/26939
Now, if this were
#!/usr/bin/perl
use fatal;
use Pluginish::App;
sub &infix: ($l, $r) { "$l $r" }; # spacey concatenator
{
Pluginish::App->load_plugins;
CATCH {
when Module::load_error {
if (prompt("The module $!.module_name could not
be loaded because"
s~ "an error occurred ($!). Try to
continue anyway?") {
$!.resume(undef);
} else {
die $!;
}
}
}
Pluginish::App->run;
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /methinks long and hard, and runs away: neeyah!!!
pgpxShOEewGd9.pgp
Description: PGP signature
Re: Exceptuations, fatality, resumption, locality, and the with keyword; was Re: use fatal err fail
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 yourself:
CATCH {
when It::Is::An::Error::I::Can::Deal::With {
deal_with_error_of_kind_foo($!); # it may resume
}
}
> >Reentrancy is an implementation detail best left unmentioned.
>
> the reentrance proplem is just there
No, it's not - the solution is that $! is bound lexically to the
CATCH block. Exceptions that redefine $! keep the old value in the
exception stack inside of each exception, but this does not trample
any CATCH block. It'd be outright stupid to make
CATCH {
handle_error();
warn "$! was thrown within the code yadda";
}
print out completely bogus info becaue handle_error overwrote $!.
We can even deal with this in perl 5:
eval { bad_code };
if ($@) {
{
local $@;
code_that_might_die_in_a_handler;
}
warn "$! was thrown within bad_code";
}
> Just to synchronize our understanding, I see the following
> equivalences from the data and code domains
>
> datacode
>
> class = sub
> instance = invocation
What?
> To illustrate my view consider
didn't help.
> The view I believe Yuval is harboring is the one examplified
> in movies like The Matrix or The 13th Floor and that underlies
> the holodeck of the Enterprise: you can leave the intrinsic
> causality of the running program and inspect it. Usually that
> is called debugging. But this implies the programmer catches
> a breakpoint exception or some such ;)
Err, no.
What I want is for perl 6 to help me write high quality user
interfaces easily.
One aspect of making this easy is letting me bridge between
exception throwing code and the UI layer using continuations.
> Exception handling is the programmatic automatisation of this
> process. As such it works the better the closer it is in time
> and context to the cause and the more information is preserved.
I read that as:
"As such it works the better the farther it is in time and
context from the UI code"
and I must disagree, but it is a matter of style.
As for information preserval:
* every object that inherits Exception can have an arbitrary
number of attributes.
* the base class Exception has code to make it be thrown,
or rethrown cleanly by making the previous value of $! available
as an attribute of the new value of $!
* Exception's constructor knows exactly where everything
happenned (for error reporting, *AND* resuming)
* a transition into a 'use fatal' lexical scope will cause the
throw method to be called on a value being returned, if it is an
exception.
* if the next statement to be executed is not inside a CATCH
block, the error object deletes it's .resume continuation, to
clean up the lexical scope that is still alive inside it. This
should be optional.
> But we all know that a usefull program is lossy in that respect.
> It re-uses finite resources during its execution. In an extreme
> setting one could run a program *backwards* if all relevant
> events were recorded!
That's a job for omniscient debuggers.
Languages with continuations are not debuggers.
Exceptions are not raised for every opcode, just to record the flow.
Exceptions normally do not happen.
> >Yes, even signals and exceptions.
> >The runtime is responsible for making these as fast as possible
> >without being unsafe.
>
> Hmm, I would see the type system in that role. It has all the
> information of the interested parties in a longjump. If it knows
> there are no potential handlers
The type system has nothing to do with code reentrency due to an
icky implementation that shares code.
Since malloc cannot be safely called within a C level signal
handler, the runtime needs to be responsible for setting the virtual
machine instruction pointer to the signal handling code, and to
mark a flag, and at the next opcode dispatch (no longer an unsafe
place) the signal handler will really happen.
This has nothing at all to do with the type system, and doesn't even
have anything to do with perl - this is parrot (or whoever)'s job.
> >It can't be a method because it never returns to it's caller - it's
>
> It beeing the CATCH block?
No, .resume.
I take it back, it could be a method that invokes a continuation.
> metric for dispatch applies. BTW, how is the signature of a CATCH
> block given? Simply
CATCH is just a topicalizer and a trait on the lexical scope.
Within it $! is topicalized, and you use when:
CATCH {
Re: Tcl - compiling expressions
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 code would
> result in creating two PMCs for the args (first arg is {$a <10},
> second is {incr a}), and then lookup the while PIR .sub, and invoke
> it with the two PMC args.
>
> Future versions of the compiler will be able to cheat (presuming the
> while builtin hasn't been overriden) and generate inline-able PIR,
> which should improve performance.)
>
> Regards.
>
[perl #37316] [PATCH] PLATFORMS result with MinGW32
# 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-devel (r9282) built for i386-MSWin32. $ make test Failed TestStat Wstat Total Fail Failed List of Failed --- t\examples\japh.t1 256151 6.67% 12 t\pmc\env.t 3 768123 25.00% 6 9-10 t\pmc\timer.t3 768 83 37.50% 4 6-7 (1 subtest UNEXPECTEDLY SUCCEEDED), 3 tests and 90 subtests skipped. Failed 3/162 test scripts, 98.15% okay. 7/2762 subtests failed, 99.75% okay. Problem with env.t is related by #37301. Problem with timer.t is related by #37116. François Perrad PLATFORMS.patch3 Description: Binary data
Re: [perl #37316] [PATCH] PLATFORMS result with MinGW32
On 9/30/05, via RT François PERRAD <[EMAIL PROTECTED]> wrote: > This patch updates PLATFORMS for MinGW. > applied, thanks.
Re: [perl #37308] Parrot gobbles up all the memory
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 > > # Failed test (t/op/gc.t at line 279) > > > # './parrot --gc-debug > > "/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir"' failed with exit > > code 131 > > # Looks like you failed 1 test of 22. > > Strange. The test succeeds on linux/86 and OS/X 10.3 darwin. Running it > through valgrind on the linux box doesn't show any indication of an error. > > t/op/gc_13 is using continuations for backtracking and a few closures. > Maybe you can compare used features of other failing tests, so that the > error reason can be narrowed a bit. After resetting my ulimit so that the tests can run without adversely impacting other uses of the system, I end up with 267 test failures. I haven't had time to look for common themes. (This is all on Solaris 8/SPARC). Failed 26/162 test scripts, 83.95% okay. 267/2734 subtests failed, 90.23% okay. Failed Test Stat Wstat Total Fail Failed List of Failed --- t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13 t/examples/japh.t 1 256151 6.67% 12 t/library/dumper.t27 691227 27 100.00% 1-27 t/library/getopt_long.t1 256 11 100.00% 1 t/library/md5.t6 1536 66 100.00% 1-6 t/library/parrotlib.t 5 1280 65 83.33% 1-4 6 t/library/pcre.t 1 256 11 100.00% 1 t/library/pge.t4 1024 64 66.67% 2 4-6 t/library/streams.t 18 460820 18 90.00% 1-17 19 t/op/calling.t 1 256371 2.70% 35 t/op/gc.t 1 256221 4.55% 13 t/op/string_cclass.t 2 512 62 33.33% 5-6 t/op/trans.t 1 256191 5.26% 13 t/p6rules/anchors.t 26 665626 26 100.00% 1-26 t/p6rules/backtrack.t 15 384015 15 100.00% 1-15 t/p6rules/builtins.t 41 1049641 41 100.00% 1-41 t/p6rules/capture.t 38 972838 38 100.00% 1-38 t/p6rules/cclass.t18 460818 18 100.00% 1-18 t/p6rules/escape.t19 486419 19 100.00% 1-19 t/p6rules/subrules.t 5 1280 55 100.00% 1-5 t/p6rules/ws.t19 486421 19 90.48% 1-15 18-21 t/pmc/delegate.t 1 256 91 11.11% 9 t/pmc/fixedpmcarray.t 1 256131 7.69% 10 t/pmc/mmd.t1 256301 3.33% 27 t/pmc/namespace.t 1 256151 6.67% 12 t/src/hash.t 1 256101 10.00% 6 5 tests and 100 subtests skipped. So far, I've identified 14 tests that panic with 'Out of mem!'. These all get a null access internal exception, and then try to exit. During Parrot_exit, the exit handlers get called. The very first one apparently tries to do a backtrace, and that backtrace ends up gobbling up all the memory. Here are some examples: # got: 'Null PMC access in clone() # current instr.: '(null)' pc 199 (/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir:123) # called from Sub '(null)' pc 199 (/home/doughera/src/parrot/parrot-andy/t/op/gc_13.pir:123) # Parrot VM: PANIC: Out of mem! # Null PMC access in get_string() # current instr.: 'delegate :: __get_string' pc 50 (/home/doughera/src/parrot/parrot-andy/t/pmc/delegate_9.pir:27) # called from Sub 'delegate :: __get_string' pc 50 (/home/doughera/src/parrot/parrot-andy/t/pmc/delegate_9.pir:27) # Parrot VM: PANIC: Out of mem! # Null PMC access in get_iter() # current instr.: 'cmp_fun' pc 80 (/home/doughera/src/parrot/parrot-andy/t/pmc/fixedpmcarray_10.pir:27) # called from Sub 'cmp_fun' pc 80 (/home/doughera/src/parrot/parrot-andy/t/pmc/fixedpmcarray_10.pir:27) # Parrot VM: PANIC: Out of mem! # got: 'Null PMC access in set_integer_keyed_int() # current instr.: 'Digest :: _md5_init' pc 72 (runtime/parrot/library/Digest/MD5.pir:81) # called from Sub 'Digest :: _md5_init' pc 72 (runtime/parrot/library/Digest/MD5.pir:81) # Parrot VM: PANIC: Out of mem! (all the t/library/md5_*.pir tests fail in the same way). Here's a backtrace from t/op/gc_13.pir [EMAIL PROTECTED] ([EMAIL PROTECTED]) terminated by signal QUIT (Quit) (dbx) where current thread: [EMAIL PROTECTED] =>[1] __sigprocmask(0x0, 0xffbecff0, 0x0, 0x0, 0x0, 0x0), at 0xff0d91f0 [2] _resetsig(0xff0db7f4, 0x0, 0x0, 0x225c98, 0xff0ec000, 0x0), at 0xff0ce56c [3] _sigon(0x225c98, 0xff0f38a8, 0x3, 0xffbed0c4, 0x225c98, 0x5), at 0xff0cdd0c [4] _thrp_kill(0x0, 0x1, 0x3, 0xff0ec000, 0x1, 0x1dbd80), at 0xff0d0d4c [5] raise(0x3, 0x224800, 0x1dbc00, 0x1dbc00, 0x40d320, 0x21f), at 0xff14bce0 [6] mem__internal_allocate_zeroed(0x0, 0x1ccf30, 0x3b, 0x43fc40, 0x226b78,
How to test an overloaded @{} operator?
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(eq_array()), but that stopped working at some point -- I think it was
Test::More 0.60. We then switched to using just is() on the references
which seemed to work for both old and new versions of Test::More (tested
with 0.45 and 0.60). But now there's 0.61 and we fail again.
Concrete details:
We have a package called Glib::Flags which overloads multiple operators,
among them @{}. Now a method called, say, $obj->get returns such an
object. In the beginning we used to test this like so:
is_deeply ($obj->get ('some_flags'), ['value-one', 'value-two']);
With Test::More 0.60 (or a release in its vicinity), this broke and we
got failures like this one:
# Structures begin differing at:
# $got = '[ value-one value-two ]'
# $expected = ARRAY(0x9bfbd94)
Apparently, the stringification operator was called. After some
experimentation, it turned out that is() does exactly what we needed:
is ($obj->get ('some_flags'), ['value-one', 'value-two']);
It even failed if you changed one of the values or added or removed
values! Perfect. Enter Test::More 0.61:
# got: '[ value-one value-two ]'
# expected: 'ARRAY(0x82a8208)'
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?
In case you need it, here's the complete test:
http://cvs.sourceforge.net/viewcvs.py/gtk2-perl/gtk2-perl-xs/Glib/t/c.t?view=markup
--
Thanks,
-Torsten
Re: How to test an overloaded @{} operator?
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 doing it in two steps work? Instead of:
> is_deeply ($obj->get ('some_flags'), ['value-one', 'value-two']);
perhaps:
my @flags = @{ $obj->get( 'some_flags' ) };
is_deeply( [EMAIL PROTECTED], [ 'value-one', 'value-two' ] );
If you're paranoid, you could wrap the dereference in a lives_ok() call
from Text::Exception.
is() and is_deeply() have a little bit of magic that usually does the
right thing. Overloading is magical enough already, so I try never to
cross the streams.
-- c
Re: How to test an overloaded @{} operator?
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 overloaded in several ways its not possible for Test::More to guess which one is the canonical representation. Should this blessed, string and array overloaded hash ref (I'm going to assume its a hash ref) be treated as an array ref or a hash ref or a string? Can't tell. Test::More prefers strings since its the most common type of overloading. You have to make it explicit what you're comparing. So chromatic's suggestion should work, dereference the array ref before hand to eliminate the overloading. And, umm, I'd think a bit about the wisdom of having something which is both string and array overloaded. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern ...they shared one last kiss that left a bitter yet sweet taste in her mouth--kind of like throwing up after eating a junior mint. -- Dishonorable Mention, 2005 Bulwer-Lytton Fiction Contest by Tami Farmer
Re: Look-ahead arguments in for loops
Rather than addition Yet Another Feature, what's wrong with just using:
for @list ¥ @list[1...] -> $curr, $next {
...
}
???
Damian
Re: Look-ahead arguments in for loops
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 same as mine.
Certainly adding this to specialized syntax in signature matching is
an overfeature, so I tried to squish it down into options, which we
can add at will without really complexifying the core language. But
without options, like this, is even better.
Incidentally, the undef problem just vanishes here (being replaced by
another problem). Since zip takes the shorter of its argument lists,
you'll never even execute the case where $next is undef.
Luke
Re: Look-ahead arguments in for loops
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 away extras, not fills in with undef.
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
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 I remember it zip hrows away extras, not fills in with undef.
Drat I did that backwaeds didn't I.
try:
for @list ¥ [EMAIL PROTECTED], undef] -> $curr. $next {
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: Look-ahead arguments in for loops
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 this, because
we can program it" things. Perl5 had many other these: "we don't need a
switch statement", "we don't need function signatures", etc.
My original idea, not consuming optional bindings, is barely a new
feature: just a clarification of the rules in a corner-case of the
language. Others took the idea and ran with it and added the bells as
whistles. I guess the best alternative is to say that optional bindings
aren't allowed in this context -- that leaves the issue open for Perl
6.1 (or a module).
ANNOUNCE: reboot of Rosetta/SQL-Routine development, in Perl 6
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 portability framework. (As a reminder of what this is, a terse, 5-minute introduction can be found at http://darrenduncan.net/OSCON/OSCON2005LightningTalk.txt ). The main problem being that it is taking an order of magnitude too long to come out with a product that is actually useable for practical work. I see one root cause of this being my packrat nature of not wanting to throw out portions of the project (a lot of that being documentation) that I already invested time in, since they could still be useful. Another main problem was a persuit of perfectionism that left me spending too long on little details that could better have been put off until later, and this multiplied by the size of of a system that has a semblence of being over-engineered. Also, in hind-sight it was a mistake to limit certain implementation decisions in the core due to a desire to make a C version later, which is a less expressive tool. I have decided that now is an excellent time to start over and remake the system from the ground up. But while this is an opportunity to change many things, I see the larger scale design of the previous version to still be sound, as well as its planned feature set, and so therefore the new version will look like the old one at a distance. The main difference will be in the details of the API and in the internals, plus the new documentation won't be so verbose. Many valuable lessons were still learned in the first attempt to make this project, and will be applied in the new version. In some respects, the new version will actually be akin to a large refactor of the old, and not so much a rewrite where the fundamental design and feature plan sees change. However, all of the code and documentation is in fact being re-typed, so many things can be changed, even with the old version being a rough guideline to follow. In this process, I also draw a lot of inspiration from Autrijus Tang and his Pugs project, which demonstrates ways to come up with something amazing in a short period of time, and spark strong interest and participation from the wider community, a killer app of development models perhaps. So what are the practical benefits and effects of this reboot, then? Here are the most pertinent: 1. Development speed will be several orders of magnitude faster than before, measured by the rate at which actual useable features are made available to users, even when I'm the sole developer (as I was before). You will actually be able to see progress being made, and I will have more personal satisfaction in my output. 2. Development will now proceed vertically first and horizontally second, rather than the reverse which was true before. This means that at any given period of time, we will have a small number of features that are 100% complete and useable *now* vs a large number of features that are 80% complete and wholly unuseable, which is the case in the older system. 3. Since people will be able to actually use the system for something, whether work or play, it will be a lot easier for them to get excited about it, then turn around and participate in its further development. 4. Perl 6 is now the primary native platform of the Rosetta framework, and Rosetta's design and implementation will be driven by what is considered the most natural and best practices in Perl 6. This action both helps the development of Pugs itself through the extra integration testing it provides, but it also helps anyone that wants to make database using applications in Perl 6 to migrate there faster. The Perl 6 version will not be a port of the Perl 5 version after the latter is done. 5. But because Perl 6 is still very much a moving target, and its implementations unstable, a native Perl 5 version will be developed simultaneously and be kept in full parity with it; this task is made a lot easier by the multiple modules on CPAN or bundled with Perl 5 that give it functionality and syntax like Perl 6 has natively, such as 'version' and 'List::MoreUtils' and 'Class::Std'; but the Perl 5 version should still be very stable and efficient, a good Perl 5 citizen. 6. If you have ideas you want to contribute towards improving Rosetta, it will be a lot easier for me to adopt them now that the pot has been emptied. And don't worry if you think that your ideas were already in my un-stated plans; its always nice to have confirmation of an idea's validity. 7. The code will be visibly smaller and more nimble. 8. Certain classes of features will be available sooner than otherwise. 9. Lastly, I can finally start to build other products of my own that employ Roset
Variable registers
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 this stand WRT the 32 registers in Parrot. Is this still the case, or will this change as well? thanks, klaas-jan
