Lazyness and IO
I was thinking about lazyness and IO and worked out this potenial
gotcha. In essence its quite simmler to the pipe buffering problems
you sometimes can get in perl5.
my IO $news = io("nntp://nntp.perl.org",:rw); # Open a nntp connection
my $banner = =$news # Throw away the banner. So far so good.
say($news,"group perl.perl6.language"); # Also no problem
my $status = =$news;
say($news,"listgroup");
my @artical <= grep { True .. /^.$/ } <= for =$news; # Is this
# construction
# right? Anyway
# you should get
# what I'm trying
# todo.
say($news,"article @artical[0]");
for =$news -> {say};
# What happens at this point? Lazyness means that only the first
# artical number has been read. Does my for loop here have the side
# effect of causing the rest of artical list to be read into @artical?
# This is what I would hope would happen.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: The Use and Abuse of Liskov
Luke wrote: A variant a is said to be _more specific than_ a variant b if: * Every type in a's signature is a subset (derived from or equal) of the corresponding type in b's signature. * At least one of these is a proper subset (not an equality). A variant is dispatched if there is a unique most specific method applicable to the given arguments. That is, there exists an applicable variant a such that for all other applicable variants x, a is more specific than x. How did you think pure ordering worked? Were we arguing over different definitions of that algorithm? Yes. I had wrongly assumed that the algorithm required "orderability" along all paths. Some (though not all) of my arguments were indeed predicated on that assumption, and are hence invalid. I obviously need to reconsider your (actual ;-) proposed dispatch scheme, almost certainly by playing with Class::Multimethods::Pure. I'll try to make time to do that this week, though with OSCON looming, my tuits are even more pitifully limited than usual. Thanks for persevering with this, Luke (and everyone else). It's this kind of passionate commitment to finding the best possible design solutions that has made/is making/will make Perl 6 insanely great. Damian
Re: Test::Harness::Straps - changes?
On Fri, Jul 29, 2005 at 03:57:07PM -0700, Michael G Schwern ([EMAIL PROTECTED]) wrote: > This is, IMHO, the wrong place to do it. The test should not be responsible > for decorating results, Test::Harness should be. It means you can decorate > ANY test, not just those that happen to use Test::Builder. This also coincides with the premise that Test::Harness::Straps are just parsing TAP from any given source. xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
Re: Test::Harness::Straps - changes?
On Fri, 2005-07-29 at 15:57 -0700, Michael G Schwern wrote: > This is, IMHO, the wrong place to do it. The test should not be > responsible for decorating results, Test::Harness should be. I also meant in Test::Harness. -- c
Re: Test::Builder::STDOUT ?
On Fri, Jul 29, 2005 at 03:26:17PM +0100, Adrian Howard wrote:
> On 29 Jul 2005, at 06:07, Michael G Schwern wrote:
> >BEGIN { *STDERR = *STDOUT }
> >
> >That'll handle anything, Test::Builder or not.
>
> Nope. T::H::S turns
>
> analyse_file( 'foo.t' )
>
> into something like
>
> open(FILE, "/usr/bin/perl foo.t|" )
>
> so the test script will get it STDERR disassociated from the piped
> STDOUT.
Perhaps you misunderstand. I mean to put that BEGIN { *STDERR = *STDOUT }
in the test script. foo.t never prints to STDERR. Here's a simple
demonstration:
$ perl -wle 'BEGIN { *STDERR = *STDOUT } use Test::More tests => 1; is( 23, 42
)' > test.out
$ cat test.out
1..1
not ok 1
# Failed test in -e at line 1.
# got: '23'
# expected: '42'
# Looks like you failed 1 test of 1.
Or perhaps I misunderstand.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
-- Jayne Cobb, "Firefly"
Re: Test::Harness::Straps - changes?
On Fri, Jul 29, 2005 at 02:49:07PM -0700, chromatic wrote: > Only a little? I might have to apply the cluestick with some force. > > > So is there a plan (he asks curiously)? > > I would really like to see objects representing different types of > tests, so that you can decorate the test classes with roles to display > their output the way you want it when you iterate over the results. This is, IMHO, the wrong place to do it. The test should not be responsible for decorating results, Test::Harness should be. It means you can decorate ANY test, not just those that happen to use Test::Builder. It neatly avoids the problem of hoping that the test author happened to code the way you need. JUnit's model, where the test runner and the test are together in the same process, has this problem. You can't separate the runner from the tests. If the author didn't think to display it how you like you're screwed. That said, the idea is to reduce Test::Harness::runtests() to this. my $strap = Test::Harness::Straps->new; $strap->decorator(Test::Harness::Decorator::Default->new); $strap->analyze_file($_) for @ARGV; You have a parser (Straps) and you hand it a decorator (which is currently all the Test::Harness code outside of Straps). The parser runs the tests and as it sees each event it informs the decorator which can do whatever it wants. Print it to the screen. Send an email. Output HTML or XML. Release the hounds... whatever. You want a different format you write your own decorator. That's been the plan since Straps came into being. The major stumbling block has been the total lack of tests for Test::Harness' output. That and the existing decoration code is pretty heinous in places. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern I do have a cause though. It's obscenity. I'm for it. - Tom Lehrer
Re: Test::Harness::Straps - changes?
On Fri, 2005-07-29 at 22:27 +0100, Adrian Howard wrote: > However, munging together my own command together with various > _private looking methods to pass to IPC::Run3 and then poking around > in a results hash all seems a little gnarly. Only a little? I might have to apply the cluestick with some force. > So is there a plan (he asks curiously)? I would really like to see objects representing different types of tests, so that you can decorate the test classes with roles to display their output the way you want it when you iterate over the results. I like how the Perl 6 port of Test::Builder turned out, at least for modeling test data: http://www.perl.com/pub/a/2005/07/28/test_builder_p6.html I haven't done much more in Perl 5 land than say "Hey, here's what I'd like to see" though, and most of that is this message. -- c
Does it cost anything to use a big pmc everywhere?
[Accidentally posted to Google Groups first] I'm finally doing some work on Leo's PIR Z-machine interpreter. (I've added about 15 opcodes to the 10 or so he started with. Luckily, he did a lot of the infrastructure stuff that scared me as a PIR newbie. The tester I wrote while developing Plotz passes 85 tests. Mostly.) The compiler translates Z-code into PIR, then compiles and runs it. The image of the Z-file (where the Z-machine stores its global variables and other useful things) is stored in a global called Image. So if you need to access one of the Z-machine's global variables, you emit code like: .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) where the last line is a macro that pulls the global variable out of the Z-machine memory. But Leo was smart and, while translating, says to only load image (i.e. to only output the first two lines) once per Z-code subroutine. Now here's the problem. My Z-code emitted code like this: if $I17 == 3 goto L1234 .local pmc image image = global 'Image' .GET_WORD($I181 , image, 692) L1234: print "yes, blah" .GET_WORD($I182 , image, 692) If $I17==3, then when we get to the second GET_WORD we exit with an error because we don't know what image is. So I think to avoid these problems I need to declare image at the top of every Z-code sub. My question is, is there any cost associated with always declaring this array holding 50-500K ints, other than having one P register always full? Since everything else in the translated code is integers & strings I'm not really worried about filling my P registers. The only other option I can think of is keeping track of how my scopes are nesting while translating, which sounds like a disaster. This is what I get for trying to develop in PIR after ignoring the mailing list for 6 months and not reading the basic docs. Thanks, -Amir Karger It's better to write me at [EMAIL PROTECTED] Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs
Test::Harness::Straps - changes?
Earlier today chromatic kindly gave me a gentle tap with the cluestick which let me figure out how to give T::H::S STDERR & STDOUT, which means my mates test results are now toddling off to a SQLite database quite happily. However, munging together my own command together with various _private looking methods to pass to IPC::Run3 and then poking around in a results hash all seems a little gnarly. Coincidentally in another thread... On 29 Jul 2005, at 21:15, Michael G Schwern wrote: [T::H::S gnarlyness] *sigh* Test::Builder and Test::Harness are completely different beasties. One is used to make test programs and one is used to run test programs and parse the output. That said, making the above a whole lot easier is planned. So is there a plan (he asks curiously)? Adrian
Re: Curious use of .assuming in S06
On Fri, Jul 29, 2005 at 12:53:03PM -0700, Brent 'Dax' Royal-Gordon wrote:
> Autrijus Tang <[EMAIL PROTECTED]> wrote:
> > In S06's Currying section, there are some strange looking examples:
> >
> > &textfrom := &substr.assuming(:str($text) :len(Inf));
> >
> > &textfrom := &substr.assuming:str($text):len(Inf);
> >
> > &woof ::= &bark:(Dog).assuming :pitch;
> >
> > Why is it allowed to omit comma between adverbial pairs, and even
> > omit parens around method call arguments? Is .assuming a special form?
>
> Isn't this just another form of the syntactic rule that gives us
> @array.grep:{ ... } ?
I thought that only applies to adverbial blocks, not arbitary
adverbial (named) pairs. Hm, S04 uses this:
leave :from(Loop) :label <== 1,2,3;
So maybe this is as intended? (If so, tests welcome. :-))
Thanks,
/Autrijus/
pgptQmKblgnJL.pgp
Description: PGP signature
Re: Test::Builder::Module
On Fri, Jul 29, 2005 at 02:56:53PM +0100, Adrian Howard wrote:
> >Calling builder() is safer than Test::Builder->new as it is forward
> >compatible for a day when each module will be able to have its own
> >Test::Builder object rather than the strict singleton it is now.
> [snip]
>
> In that case should we be encouraging people to write
>
> sub ok ($;$) {
> Test::Simple->builder->ok(@_);
> }
>
> instead of using a package lexical, in case people want to swap
> modules at runtime?
Yep, I was thinking about just that this morning... err, afternoon.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
Re: Test::Builder::Module
On Fri, Jul 29, 2005 at 09:06:48AM -0400, Geoffrey Young wrote:
> Michael G Schwern wrote:
> > What I'm looking for is ideas about more things it could do that would
> > be useful for most testing libraries. What scaffolding do module authors
> > find themselves implementing?
>
> if there were a better way to do this:
>
> push @ISA, qw(Test::Harness::Straps);
> $Test::Harness::Strap = __PACKAGE__->new;
> $Test::Harness::Strap->{callback} = sub { ... };
>
> it would be awesome.
*sigh* Test::Builder and Test::Harness are completely different beasties.
One is used to make test programs and one is used to run test programs and
parse the output.
That said, making the above a whole lot easier is planned.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Don't try the paranormal until you know what's normal.
-- "Lords and Ladies" by Terry Prachett
Re: Curious use of .assuming in S06
Autrijus Tang <[EMAIL PROTECTED]> wrote:
> In S06's Currying section, there are some strange looking examples:
>
> &textfrom := &substr.assuming(:str($text) :len(Inf));
>
> &textfrom := &substr.assuming:str($text):len(Inf);
>
> &woof ::= &bark:(Dog).assuming :pitch;
>
> Why is it allowed to omit comma between adverbial pairs, and even
> omit parens around method call arguments? Is .assuming a special form?
Isn't this just another form of the syntactic rule that gives us
@array.grep:{ ... } ?
--
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]>
Perl and Parrot hacker
Curious use of .assuming in S06
In S06's Currying section, there are some strange looking examples: &textfrom := &substr.assuming(:str($text) :len(Inf)); &textfrom := &substr.assuming:str($text):len(Inf); &woof ::= &bark:(Dog).assuming :pitch; Why is it allowed to omit comma between adverbial pairs, and even omit parens around method call arguments? Is .assuming a special form? This is S06-specific; neither A06 nor E06 exhibits this syntax. Thanks, /Autrijus/ pgp7dyDQHVzbp.pgp Description: PGP signature
Re: Complete type inferencing
On Fri, Jul 29, 2005 at 06:36:45PM +0200, "TSa (Thomas Sandla�)" wrote:
> you wrote:
> >Interested readers can consult Manfred Widera's similar work for Scheme,
> >in his "Complete Type Inference in Functional Programming" paper.
>
> Uih, you call a 300 page book a paper? I'm impressed.
Well, it's his dissertation, and Dissertation.does(Paper), including
book-length ones. :-)
> If that is the thing you read between tramp stations here's one of my
> favorites which is the thesis of Vassily Litvinov. It's about CBP.
>
> http://www.cs.washington.edu/research/projects/cecil/www/Papers/vass-thesis.html
Yes, I'm aware of Theta's static where clauses, but Perl 6's where
clause is much more dynamic and almost always undecidable.
In Litvinov's paper, where clauses are determinisitic at compile time,
as a way to encode structural subtyping (aka duck typing). In Perl 6
pseudo-syntax, it would be something like this:
sub foo (
$obj where { .can(
name => 'bar',
signature => :(() returns Int),
) }
) returns Int {
$obj.bar();
}
It's a bit verbose, but I don't know if there is a way to express named
methods to .can succintly. A long name in .can(&bar:(() returns Int))
won't do, as &bar would have been a variable lookup.
=begin digression
As an aside, arguably we could have dropped the braces and write:
Any $obj where .can(...)
Except this is yet another violation of no-auto-bracing rule that can
result in ambiguous parses; I think it's a misfeature to allow
Str where /^[isnt⎪arent⎪amnot⎪aint]$/;
This is much more consistent:
Str where { /^[isnt⎪arent⎪amnot⎪aint]$/ };
=cut
The important difference is that the .can() call in Perl 6 would be a
runtime call. It has to be that way, because .can is not a special
form; it's just a normal method returning a boolean. If you really
want static treatment, that needs a special form:
sub foo (
$obj can bar:(() returns Int)
) returns Int {
$obj.bar();
}
It will allow constructs such as this:
my subtype Duck
has $.half_life
can doom:()
can quake:(() returns Wolfenstein);
# Automagically satisfied iff $obj's interface is compatible
$obj.does(Duck);
Such implicitly-declared Roles is certainly powerful, and we can apply
the same inferencing treatment as for nominal subtyping violations --
fatal error under closed/finalized, raise warning by default.
I think it's cute, and adds real power of row polymorphism to the
language, iff Perl 6 indeed adopts a compile-time inferencing engine.
> BTW, have we as a list considered approaching Universities for assistence?
> E.g. I regard Perl6 as a worthwhile research subject and/or platform.
> After all Manfred Widera's thesis was done at a German University.
It seems to me that to approach researchers for assistance, one need to
give a formal treatment of the language, or at least a specification
that can lead to unambiguous implementations. Which is why I'd like to
formalize the internal language (PIL), basic types and meta-object
protocol, after all... :-)
Thanks,
/Autrijus/
pgppN7W1Hwxa1.pgp
Description: PGP signature
Re: lazy list syntax?
Just wondering - would 'reverse =$foo' call '$foo.previous()' ? - Flavio 2005/7/29, Aankhen <[EMAIL PROTECTED]>: > On 7/29/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote: > > Is "for =" only for filehandles? I tried: > > No, it's for anything that supports iteration... `=$foo` == > `$foo.next()`, if I recall correctly. It's probably not yet > implemented. > > Aankhen
Re: Complete type inferencing
HaloO Autrijus, you wrote: Interested readers can consult Manfred Widera's similar work for Scheme, in his "Complete Type Inference in Functional Programming" paper. Uih, you call a 300 page book a paper? I'm impressed. If that is the thing you read between tramp stations here's one of my favorites which is the thesis of Vassily Litvinov. It's about CBP. http://www.cs.washington.edu/research/projects/cecil/www/Papers/vass-thesis.html My brain on the other hand needs months to understand such things. And then I get most of it wrong. But I'll continue trying to be of help on the list. BTW, have we as a list considered approaching Universities for assistence? E.g. I regard Perl6 as a worthwhile research subject and/or platform. After all Manfred Widera's thesis was done at a German University. -- $TSa.greeting := "HaloO"; # mind the echo!
Re: Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
HaloO,
Adriano Ferreira wrote:
Only
sub foobar (@args) { push @args, 42 }
would change @some_array in
foobar @some_array;
That is how I undestood that. Can someone confirm this belief?
I share your belief. It's up to others to confirm it. I just
want to add that I further believe that the push call is dispatched
on the type of the array and only succeeds if @array.does(Pushable).
I guess a default array does this or another role that implies it.
--
$TSa.greeting := "HaloO"; # mind the echo!
Re: [perl #36567] t/perl/Parrot_Docs.t doesn't clean up properly.
On Fri, 15 Jul 2005, Chromatic wrote: > On Fri, 2005-07-15 at 08:27 -0700, Andy Dougherty wrote: > > > After running 'make test', Parrot leaves the following files lying around > > in /tmp. I think there's from t/perl/Parrot_Docs.t. > > > There are two problems: > > 1. Parrot should clean up after itself. > > 2. Parrot should probably pick directory names less > > likely to collide with other legitimate uses of /tmp. > > Agreed. This patch appears to fix #1. If there are no objections in a > day or two, I'll apply it. Thanks. Applied as revision 8731. -- Andy Dougherty [EMAIL PROTECTED]
Complete type inferencing
On Fri, Jul 29, 2005 at 04:59:21AM +0800, Autrijus Tang wrote:
> However, my intuition is that a soft-typed system, with clearly defined
> dynamic parts translated to runtime coerce and dependent types, that can
> work exactly as Perl 5 did at first, but provide sensible inferencing
> and compile-time diagnostics as you gradually provide annotations, is
> really the way forward.
Several people replied off-list to point out the SBCL/CMUCL system does
inferencing and static+runtime type tagging for Common Lisp. After
playing with it a bit, it seems that "soft typing" does not naturally
describe my initial intuition, as it never rejects any programs.
When types cannot be inferred, it merely inserts runtime assertions.
What I'm designing is a system that can decide on one of five classes of
judgements for each PIL term:
0. Untyped
As in Perl 5, nothing is done for $x or the call to $x.close.
Runtime failures are never detected until the actual call is made.
sub f (Any $x) { $x.close }
f(42);
1. Asserted
The usual case for Perl 6 functions, due to its default "Item"
signature for parameters. In the example below, I assume that ::* cannot
be changed freely to do away with ::*IO at runtime. (If it could, then
assertions won't be of much use in general.)
sub f (IO $x) { $x.close }
f(open('/etc/passwd'));
As both &f and &open may be rebound at runtime, we cannot guarantee that
this will not go wrong. However, we can insert an runtime assertion for $x
in &f's scope, so we can avoid doing the same assertion in &*IO::close
again. If IO is declared as final, then &*IO::close can also be resolved
statically.
2. Well-typed
This term's type is provably sound, and can be optimized at will
without any runtime checks. An example:
{
my sub f (IO $x) { $x.close }
my sub g () returns IO { open('/etc/passwd') }
f(g());
}
Here the call to &f and $x.close doesn't need assertions, as &g's return
type took care of it. Under "use optimized", many more terms can be
resolved statically and checked in this manner.
3. Warning
Under certain circumstances, this term's type can be shown to be unsound,
but we cannot prove statically that this will come to pass:
my sub f (IO $x) { $x.close }
my sub identity ($y) returns IO|Str { $y }
f(identity("/etc/passwd"));
Here the call to &identity masked a potential type incompatibility.
We know that if the IO half of the junctive type is chosen then it
will typecheck; on the other hand, nothing in &identity or $y tells
whether it will return IO or Str. Hence we can raise a warning that
says "this call can potentially go wrong had it returned Str".
4. Error
This is a type error:
my sub f (IO $x) { $x.close }
f("/etc/passwd");
Note that this can still be made to work at runtime by introducing
&coerce: from Str to IO, or make Str a subtype of IO. Therefore
in the absence of optimization hints of "closed" for Str and "final"
for IO, the compiler should only raise a severe warning, that says
"if you don't do something, this will fail at runtime".
However, if the user had provided the neccessary optimization hints:
use optimize :classes< close finalize >;
my sub f (IO $x) { $x.close }
f("/etc/passwd");
Then there is no way it could have worked, and the compiler should
reject this program.
Interested readers can consult Manfred Widera's similar work for Scheme,
in his "Complete Type Inference in Functional Programming" paper.
Feedback, preferably on-list, are most welcome. :-)
Thanks,
/Autrijus/
pgpmOuOsKeqPW.pgp
Description: PGP signature
Re: [svn ci] (r8717) Win32 Dynclasses
Woot! None of the tests are currently failing on OS X, though there are several TODOs hey. Many (All??) of the failing tests are TODOs: perhaps the test harness isn't happy about TODOs on win32, for some reason. Do TODO tests report as passed in the core suite? If so, it's probably something with lib/Parrot/Test/Tcl.pm ... Thanks for your work on this, Jonathan! On Jul 28, 2005, at 4:11 PM, Jonathan Worthington wrote: Hi, Dynclasses now work on Win32 when building Parrot with the MS Visual Studio compiler. That means that all t\dynclass\*.t passes. :-) I've also (after ci'ing a fix to config/gen/makefiles/tcl.in) managed to build Partcl on Win32 and run the tests. Here's what I'm seeing. Failed Test Status Wstat Total Fail Failed List of Failed -- t\cmd_expr.t 433 6.98% 41-43 t\cmd_linsert.t51 20.00% 2 t\cmd_proc.t 41 25.00% 4 t\cmd_source.t 21 50.00% 1 t\cmd_string.t374 10.81% 16, 33-35 t\cmd_time.t 11 100.00% 1 t\tcl_backslash.t 162 12.50% 12, 14 t\tcl_command_subst.t 101 10.00% 10 t\tcl_misc.t 121 8.33% 12 t\tcl_pir_compiler.t 31 33.33% 3 Failed 10/39 test scripts, 74.36% okay. 16/266 subtests failed, 93.98% okay. Any problems, let me know. Take care, Jonathan
Re: Test::Builder::STDOUT ?
On 29 Jul 2005, at 02:58, chromatic wrote: If you can use your own test harness, use Test::Harness::Straps::analyze() or Test::Harness::Straps::analyze_fh() to collect STDERR and STDOUT from the tested process. Ah. That would make sense. Much more sensible. Off to play. Adrian
Re: Test::Builder::STDOUT ?
On 29 Jul 2005, at 06:07, Michael G Schwern wrote:
BEGIN { *STDERR = *STDOUT }
That'll handle anything, Test::Builder or not.
Nope. T::H::S turns
analyse_file( 'foo.t' )
into something like
open(FILE, "/usr/bin/perl foo.t|" )
so the test script will get it STDERR disassociated from the piped
STDOUT.
Adrian
Re: Test::Builder::Module
On 29 Jul 2005, at 11:31, Michael G Schwern wrote:
I've just implemented the oft requested Test::Builder::Module. Its a
superclass for all Test::Builder based modules that implements an
import()
method to match what Test::More does and a builder() method to get the
Test::Builder object.
Nice.
[snip]
Calling builder() is safer than Test::Builder->new as it is forward
compatible for a day when each module will be able to have its own
Test::Builder object rather than the strict singleton it is now.
[snip]
In that case should we be encouraging people to write
sub ok ($;$) {
Test::Simple->builder->ok(@_);
}
instead of using a package lexical, in case people want to swap
modules at runtime?
[snip]
What scaffolding do module authors find themselves implementing?
import() and builder() is all I can think of.
[snip]
Can't think of anything else that would belong in a base class.
Adrian
Re: Test::Builder::Module
Michael G Schwern wrote:
> What I'm looking for is ideas about more things it could do that would
> be useful for most testing libraries. What scaffolding do module authors
> find themselves implementing?
if there were a better way to do this:
push @ISA, qw(Test::Harness::Straps);
$Test::Harness::Strap = __PACKAGE__->new;
$Test::Harness::Strap->{callback} = sub { ... };
it would be awesome.
--Geoff
Re: [perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
Michael G Schwern (via RT) wrote: Parrot cannot start up if either STDOUT or STDERR are closed. Fixed in trunk - r8730 Now a Undef PMC is stored as the PIO STDxx PMC. This will give nice effects if you print something. leo
[perl #36682] Configure.pl warning
# New Ticket Created by Michael G Schwern # Please include the string: [perl #36682] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36682 > rsync'ing the latest parrot from cvs.perl.org and running configure on OS X 10.3.9 using fink's perl 5.8.6 I get the following warning: Generating build files..value for 'parrot_exe_def' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Step.pm line 232, line 667. value for 'ld_parrot_exe_def' in config/gen/makefiles/root.in is undef at lib/Parrot/Configure/Step.pm line 232, line 668. value for 'cc_building_dynclass_flag' in config/gen/makefiles/dynclasses_pl.in is undef at lib/Parrot/Configure/Step.pm line 232, line 34. ..done. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick
Re: GMC for dummies
On Mon, Jul 25, 2005 at 10:33:37PM -0400, Bob Rogers wrote: [snip] > > This is sounding more and more like the CMUCL gencgc algorithm, which > uses what I understand is a classic approach. Instead of an IGP list, > it write-protects all oldspace pages (hence my earlier question), > unprotecting them transparently when one is stored into, so that it only > needs to scan writable pages to look for newspace pointers. It is my > intuition that this would be less overhead than an IGP list, but I > suspect this is data-dependent, and would take benchmarking to prove. > On a POSIX-ish OS, this approach involves a system call to change the protection on each page, plus a signal handler that gets invoked whenever such a page is stored into, and then another system call to unprotect the page. [snip] > > That's OK; if Leo believes it will work, then I'm sure it will. My > quibbles were about speed and complexity, and I don't want to distract > you with unproven assertions about things that might not matter. System calls aren't cheap, and page table manipulations are not necessarilly cheap either. Whether this performance tradeoff is worth it is going to be both OS- and processor-specific. It also lurches into the realm of signal handlers, where POSIX guarantees very little behavior that is portable behavior, but operating systems may allow much more, but the allowed behaviors form an ever-changing and largely disjoint set. In summary, just about any algorithm that avoids page table manipulations and signal handlers is likely to be more portable, and will quite likely be faster. -- Ed M
[perl #36683] Test failures on OS X 10.3.9
# New Ticket Created by Michael G Schwern
# Please include the string: [perl #36683]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/rt3/Ticket/Display.html?id=36683 >
The latest parrot build is failing as follows on OS X 10.3.9.
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/dynclass/gdbmhash.t 13 332813 13 100.00% 1-13
t/library/pcre.t 1 256 11 100.00% 1
t/pmc/eval.t 3 768143 21.43% 12-14
The full test output is attached. This Parrot was built using fink's
perl 5.8.6 and fink's pcre (4.2) and gdbm (1.8.0) libraries.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
-- Jayne Cobb, "Firefly"
Compiling with:
xx.c
cc -I/sw/include -fno-common -no-cpp-precomp -pipe -I/usr/local/include -pipe
-fno-common -Wno-long-double -g -Wall -Wstrict-prototypes -Wmissing-prototypes
-Winline -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings
-Waggregate-return -Winline -W -Wno-unused -Wsign-compare -Wformat-nonliteral
-Wformat-security -Wpacked -Wdisabled-optimization -falign-functions=16
-Wno-shadow -I./include -DHAS_JIT -DPPC -DHAVE_COMPUTED_GOTO -I. -o xx.o -c xx.c
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;' docs
bleadperl -e '-d or mkdir $_,0777 or die foreach @ARGV' ops
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
dynclasses
bleadperl -e 'chdir shift @ARGV; system q{make}, @ARGV; exit $? >> 8;'
compilers/pge
make[1]: Nothing to be done for `all'.
bleadperl t/harness --gc-debug --running-make-test t/library/*.t t/op/*.t
t/pmc/*.t t/run/*.t t/native_pbc/*.t imcc/t/*/*.t t/dynclass/*.t t/p6rules/*.t
t/src/*.t t/perl/*.t
t/library/dumper...ok
t/library/getopt_long..ok
t/library/md5..ok
t/library/parrotlibok
t/library/pcre.
# Failed test (t/library/pcre.t at line 33)
# got: 'ok 1
# no extension: file 'libpcre'
# '
# expected: 'ok 1
# ok 2
# ok 3
# ok 4
# ok 5
# '
# './parrot --gc-debug "/usr/local/src/parrot/t/library/pcre_1.pir"' failed
with exit code 42
# Looks like you failed 1 test of 1.
dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 1
Failed 1/1 tests, 0.00% okay
t/library/pge..ok
t/library/sort.ok
t/library/streams..ok
t/library/yaml_parser_syck.ok
t/op/00ff-dos..ok
t/op/00ff-unix.ok
t/op/64bit.skipped
all skipped: 64bit INTVAL platforms only
t/op/arithmetics...ok
t/op/basic.ok
t/op/bitwise...ok
t/op/calling...ok
t/op/comp..ok
t/op/conv..ok
t/op/debuginfo.ok
3/8 skipped: getline/setline changes not finished
t/op/gcok
t/op/globals...ok
t/op/hacks.ok
2/2 skipped: no universal SIGFPE handling
t/op/ifunless..ok
t/op/info..ok
t/op/integer...ok
t/op/interpok
t/op/jit...ok
t/op/jitn..ok
t/op/lexicals..ok
t/op/literal...ok
t/op/macro.ok
1/18 skipped: Await exceptions
t/op/numberok
t/op/randomok
t/op/rxok
1/23 skipped: Pending some sort of lowercasing op
t/op/spawnwok
t/op/stacksok
3/56 skipped: no stack limit currently
t/op/stringok
7/156 skipped: various reasons
t/op/string_cclass.ok
t/op/string_cs.ok
t/op/stringu...ok
t/op/time..ok
t/op/trans.ok
t/op/types.ok
t/pmc/arrayok
t/pmc/bigint...ok
t/pmc/boolean..ok
t/pmc/builtin..ok
t/pmc/complex..ok
t/pmc/config...ok
t/pmc/coroutineok
2/13 skipped: various reasons
t/pmc/delegate.ok
t/pmc/env..ok
t/pmc/eval.
# Failed test (t/pmc/eval.t at line 358)
# got: 'directory_pack segment 'BYTECODE_EVAL_1' used size 14 but
reported 12
#
# '
# expected: 'hello from foo_1
# hello from foo_2
# '
# './parrot --gc-debug "/usr/local/src/parrot/t/pmc/eval_12.pir"' failed with
exit code 1
# Failed test (t/pmc/eval.t at line 402)
# got: 'directory_pack segment 'BYTECODE_EVAL_1' used size 14 but
reported 12
#
# '
#
Re: Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
On 7/29/05, Ingo Blechschmidt <[EMAIL PROTECTED]> wrote:
> Or is @args always readonly and the declaration ([EMAIL PROTECTED] is rw) is
> an
> error?
The declaration ([EMAIL PROTECTED] is rw) can't be outlawed as it is how Perl 5
default sig translates to Perl 6.
IMHO @args as a parameter works like a 'my' variable in subroutine
scope. In C arguments will be copied and (possibly) flattened (as
the parameter is slurpy) and stuffed into @args. In C it is the
same, but instead of copying, the elements of @args will be aliased to
the actual parameter items. And the point here is "aliased to
parameter ITEMS".
If you change @args with a 'push' or other operation that changes the
array, not its elements, it changes the subroutine variable, as the
connection to @some_array were lost, leaving in the case of bar the
connection to the elements of @some_array.
In conclusion,
foo @some_array;
bar @some_array;
are both ok, but changes are not seen from the caller's perpective, as
'push' operated on subroutine parameter @args.
Only
sub foobar (@args) { push @args, 42 }
would change @some_array in
foobar @some_array;
That is how I undestood that. Can someone confirm this belief?
Adriano.
Re: An idea for doing pack.
On Thu, 28 Jul 2005 15:46:14 +0300, Yuval Kogman
<[EMAIL PROTECTED]> wrote:
[...]
> I like your Pack object - that is the parsed template, but I'd also
> like to be able to generate these templates with a programmatic
> interface that isn't string concatenation...
>
> Is it just a simple data structure? Or do you have anything in mind?
I was thinking of having it compile down to as close to native code as
possable. But this may be premature optimization.
> Will we have more powerful nesting? I think this is in order
> nowadays.
Thinking about it the declarations are very similar to (un)pack
templates. So it may be possable to build them up from them. If my
compile template macro took a name and that name was then treated as a
new declaration we could do something like this.
Pack::compile byte {
@^_ :=: { pack => &chr, unpack => &ord }
}
Pack::compile null {
0x00 :=: byte
}
Indeed I can see the pack module as creating all of the builtins this
way. Further more this approach makes it concivable to have a set of
methods on the Pack object itself for example.
method Pack::declaration() returns Array of Pack
is doc("The declarations that this pack consists of in the
order of there application") {...}
method Pack::packer() returns Code is doc("The code that will
be run to pack using this pack object") {...}
method Pack::unpacker() returns Code is doc("The code that will
be run to unpack using this pack object") {...}
Mm if we have something that returns previousely defined
delarions and a constructor.
method Pack::declaration(::Class $class,Str $name) returns Pack is
doc("The Pack object which corrasponds to this declaration") {...}
method Pack::new(::Class $class,@declaration of Pack) returns
Pack is doc("Create a new Pack object composed of declarations") {...}
This would allow the best of both worlds. A template based system for
those of us who are creating our Pack's at compile time, and also an
OOish programmatic interface for thouse of us who need something more
convenient then string concatination.
> Actually, to be really wicked, I think that packing is just applying
> rules in reverse (this is tricky and indeterminate, since there are
> no alternatives or options in unpacking/packing), and unpacking is
> the opposite, with two exceptions:
>
> captures are converted by looking at the binary data and
> interpreting it, not just stuffing it in a string
>
> the syntax is different
The other diffrence is that unpacking makes use of pattens of fixed
length so it doesn't need to parse its input.
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
Re: [perl #36597] [PATCH]Dominance Frontiers
Patrick R. Michaud wrote: ... I'm able to reproduce this with the code below Good catch. I'll be very happy to add the above PIR segment to the imcc test suite if someone can tell me which imcc/t/*/*.t file it should go in. Probably time to start a new subdir: imcc/t/cfg/df.t or some such. Pm leo
Test::Builder::Module
I've just implemented the oft requested Test::Builder::Module. Its a
superclass for all Test::Builder based modules that implements an import()
method to match what Test::More does and a builder() method to get the
Test::Builder object.
The upshot is that writing a test module is now reduced to this:
package Test::Simple;
# inherit import() and builder()
use base qw(Test::Builder::Module);
@EXPORT = qw(ok);
# replaces $Test = Test::Builder->new;
my $Test = Test::Simple->builder;
sub ok ($;$) {
$Test->ok(@_);
}
1;
That implements all of Test::Simple. Means you no longer have to rely on
Test::More to set the plan, you can inherit the same logic.
builder() is like Test::More->builder. It provides a way to get at a
testing module's underlying Test::Builder object. Calling builder() is
safer than Test::Builder->new as it is forward compatible for a day when
each module will be able to have its own Test::Builder object rather than
the strict singleton it is now.
I've checked Test::Builder::Module into the repo, but its not documented
yet. What I'm looking for is ideas about more things it could do that would
be useful for most testing libraries. What scaffolding do module authors
find themselves implementing? import() and builder() is all I can think
of.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
Just call me 'Moron Sugar'.
http://www.somethingpositive.net/sp05182002.shtml
Slurpy "is rw" arrays ([EMAIL PROTECTED] is rw)
Hi,
are the following assumptions correct?
sub foo ([EMAIL PROTECTED]) { push @args, 42 }
sub bar ([EMAIL PROTECTED] is rw) { push @args, 42 }
foo @some_array; # dies ("Can't modify constant array...")
bar @some_array;
# works, but does not change @some_array, as the * causes &bar to
# receive a *new* array (which happens to contain @some_array's
# elements), right?
# @args is only an array constructed by the parameter binding code;
# @args =:= @some_array is false (consider bar(@some_array, 42)).
bar 1,2,3; # works too
Or is @args always readonly and the declaration ([EMAIL PROTECTED] is rw) is an
error?
--Ingo
--
Linux, the choice of a GNU | Perfection is reached, not when there is no
generation on a dual AMD | longer anything to add, but when there is
Athlon!| no longer anything to take away.
Re: [perl #36597] [PATCH]Dominance Frontiers
On Thu, Jul 28, 2005 at 03:39:33PM -0400, Andy Dougherty wrote: > On Thu, 28 Jul 2005, Will Coleda wrote: > > > Applying your patch to a pristine build yields only the backtrack.t failure: > > #2 eats 100% of the CPU until I kill it: it doesn't behave that way in > > svn-head. > > I can confirm the backtrack #2 failure under SPARC/Solaris. I can't say > what other tests may have changed; the script I had running the comparison > got stuck at backtrack.t and never finished. Just to add to the picture -- I also tried applying df.patch to a fresh checkout of parrot/trunk (r8727), and also observed the same problem of getting stuck on test #2 in t/p6rules/backtrack.t . (FWIW, I'm running Fedora Core 4.) Some additional investigation reveals that with df.patch applied it's the PIR compiler that is getting stuck. I'm able to reproduce this with the code below, which doesn't do anything useful other than demonstrate that the compiler gets stuck when one tries to compile: $ cat x4.pir .sub foo print "started\n" bsr R1 goto end R1: goto R2 if $I0 goto R2 bsr R2 R2: ret end: .end $ parrot -t -v -o x4.pbc x4.pir debug = 0x0 Reading x4.pir using optimization '0' (0) Starting parse... at which point the process is stuck until interrupted somehow. The problem seems to be with the exact goto/if/bsr sequence given in R1 -- remove any of them or reorder them and the code successfully compiles. I completely grant that the specific sequence of statements that trigger this problem is bizarre -- it only occurred in PGE because of a missing optimization in PGE's code generator. The cut operator (for backtracking control) generated a "goto R2" statement to handle the cut, but then also generated the code that would've performed the backtracking had the cut not been present. Note that having the extra code after the goto doesn't change the syntactic or semantic correctness at all -- it just causes the compiler to choke somehow (when df.patch is applied). I'll definitely fix PGE to not generate the unnecessary code following the "goto", but it seems to me that the compiler should not hang on something like this in any case. I'll be very happy to add the above PIR segment to the imcc test suite if someone can tell me which imcc/t/*/*.t file it should go in. Then I'll fix PGE to not generate the code it should not have been generating in the first place. :-) Hope this helps! Pm
Re: Accessing Hash with strings/keys
On Jul 29, 2005, at 10:38, Klaas-Jan Stol wrote: Anybody an idea what I'm doing wrong here? By far the simplest thing is either look at the opcode in ops/core_ops.c or use a debugger and set a breakpoint at the appropriate opcode, e.g. Parrot_set_p_p_kc (or _kic) and step on from there (The keyed_str variants are only used internally to avoid constructing key PMCs at runtime. For opcodes this isn't a problem because these key pmcs are created just once at PBC load tine) Thanks, klaas-jan leo
Re: [perl #36677] Parrot cannot startup if STDERR or STDOUT is closed
On Thu, Jul 28, 2005 at 12:31:33PM -0700, jerry gay via RT wrote: > i've added a new test t/run/exit.t that checks parrot exit codes under > different scenarios. the 8 subtests all pass on win32. These tests pass, and yet: $ perl -wle 'close STDOUT; system "parrot --version"; print STDERR $? >> 8' Parrot IO: Failed init layer(unix). 66 It appears to be your redirect which is doing it. $ perl -wle 'close STDOUT; system "parrot --version >/dev/null 2>&1 "; print STDERR $? >> 8' 0 It must be reopening STDERR and STDOUT. -- Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
Re: End-of-program global destruction is now guaranteed
| | > I look forward to your perl.com article. :) | | It goes up on Thursday afternoon. Would that be 'Porting Test::Builder to Perl 6' ? Excellent Article. As an aside , I am looking for more Perl 6 material, but I would say the 'Perl 6 and Parrot Essentials' is out of date. Is there anything else in the pipeline, or are the usual online sources the best way to keep up? Thanks Gav... -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.338 / Virus Database: 267.9.7/60 - Release Date: 28/07/2005
Accessing Hash with strings/keys
Hi,
I'm trying to extend the standard Hash PMC, if it returns "None",
because there was no value at the specified key, then I want to override
this behaviour by returning something else. In order to do that, I
should know what methods are called. That's where I'm running into
trouble. I can just do a
fprintf(stderr, "");
to check if the method is called.
Now, when I do:
P0 = new .Hash
P1 = P0[42]
and
I0 = 42
P1 = P0[I0]
the method
PMC *get_pmc_keyed_int(INTVAL)
gets called (as I would expect). So, I can just override this method,
and if the return value of SUPER() is "None", then I return my own stuff
("nil" to be exact). So, when I try to index the hash with a string like:
P1 = P0["hi"]
or
S0 = "hi"
P1 = P0[S0]
I would expect the method
PMC *get_pmc_keyed_str(STRING *)
gets called. It seems to me this is not the case. The same is true for
indexing with a PMC:
P2 = new .Key
P2 = "hello"
P1 = P0[P2]
This should call (I think)
PMC *get_pmc_keyed(PMC *)
Well, that would be logical, right? (I can't find any other suitable
methods in hash.pmc that could be called, because the return value
should be a PMC)
Anybody an idea what I'm doing wrong here?
Thanks,
klaas-jan
Re: lazy list syntax?
On 7/29/05, Flavio S. Glock <[EMAIL PROTECTED]> wrote: > Is "for =" only for filehandles? I tried: No, it's for anything that supports iteration... `=$foo` == `$foo.next()`, if I recall correctly. It's probably not yet implemented. Aankhen
