Re: takers wanted - a perl job
From: Joshua Juran <[EMAIL PROTECTED]> Date: Sat, 25 Jun 2005 01:05:35 -0400 On Jun 24, 2005, at 11:02 PM, Bob Rogers wrote: > Since Complex could also be considered a Number, but of a very > different > sort, it might be worth constructing the type hierarchy to reflect > this: > >Scalar > Number > Real > Integer > Float > Complex This is inaccurate. All integers are reals (in fact, all integers are rationals and all rationals are reals), but floats are not all integers. Factorial should be defined for integers but not floats. That's pretty much what I thought I had said. But I notice that the indentation on Float used a tab, but not on Integer, so I'll bet your mail client displayed them differently. (I've converted them all to spaces above.) Also, all reals are complex numbers (with a zero imaginary component). That is mathematically accurate, but inconvenient to implement [1]. Here's my suggested hierarchy with abstract types in lowercase and instantiable types capitalized: scalar number (possibly complex) real rational integer Integer BigInt Ratio Float Complex Quaternion String ... Except for Quaternion, this is very close to the Common Lisp type hierarchy for "number" [1], which was the inspiration for my proposal. I had left out rational and Ratio because I don't think any of the Parrot core languages require them, but it would make life easier down the road if "rational" were included in the core type hierarchy. FWIW, the main difference is that CL also subdivides Complex into (complex float) and (complex rational), but that is best left to a Lisp-specific subclass in any case. Also, what about non-scalar numbers such as vectors and matrices? Will we have operators for dot-product and cross-product? Or is this another HLL issue? Josh I think it's an HLL thing; it seems like a big piece to implement in Parrot. Such an implementation might be useful to support perl6 hyperoperators, but IMHO this is better left to generated PIR. -- Bob [1] http://www.lispworks.com/documentation/HyperSpec/Body/t_number.htm, "Notes" at the bottom of the page.
[perl #36385] Some Tests Failing on Win32 for 8443 revision
# New Ticket Created by Craig # Please include the string: [perl #36385] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=36385 > Downloaded revision 8443 of Parrot to Windows XP Pro using SVN. When using 'nmake' 7.10.3077, some of the test are failing. According to the gettingstarted.pod, none of the tests should fail. Attached is myconfig and the output from 'nmake test' with STDERR at the end of the file. Please not this is my first attempt at using Parrot, so its most likely that I'm missing the obivous. Thanks, Craig Fjord.pasm 1 print "He's pining for the fjords. \n" 2 end Output from various attemts to excute fjord.pasm. Fjord.pasm - ASCII format E:\usr\local\parrot-0.2.1-devel\bin>parrot fjord.pasm error:imcc:syntax error, unexpected EOM, expecting '\n' in file 'fjord.pasm' line 2 Fjord.pasm - Unicode format E:\usr\local\parrot-0.2.1-devel\bin>parrot fjord.pasm error:imcc:syntax error, unexpected $end, expecting PARROT_OP in file 'fjord.pasm' line 1 Compiling with: xx.c cl -nologo -GF -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DNO_HASH_SEED -Zi -I.\include -DHAS_JIT -DI386 -I. -Fo xx.obj -c xx.c E:\Perl\bin\perl.exe -e "chdir shift @ARGV; system 'nmake', @ARGV; exit $? >> 8;" docs E:\Perl\bin\perl.exe -e "-d or mkdir $_,0777 or die foreach @ARGV" ops E:\Perl\bin\perl.exe -e "chdir shift @ARGV; system 'nmake', @ARGV; exit $? >> 8;" dynclasses E:\Perl\bin\perl.exe -e "chdir shift @ARGV; system 'nmake', @ARGV; exit $? >> 8;" compilers\pge E:\Perl\bin\perl.exe t\harness --gc-debug --running-make-test t\library\*.t t\op\*.t t\pmc\*.t t\native_pbc\*.t imcc\t\*\*.t t\dynclass\*.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.ok 1/1 skipped: no pcre-config 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\spawnwdubious Test returned status 3 (wstat 768, 0x300) DIED. FAILED tests 4-6 Failed 3/6 tests, 50.00% okay 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...skipped all skipped: No BigInt Lib configured 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.ok t\pmc\exceptionok t\pmc\fixedbooleanarrayok t\pmc\fixedfloatarray..ok t\pmc\fixedintegerarrayok t\pmc\fixedpmcarrayok t\pmc\fixedstringarray.ok t\pmc\floatok t\pmc\floatvalarrayok t\pmc\freeze...ok t\pmc\globals..ok t\pmc\hash.ok t\pmc\integer..ok t\pmc\intlist..ok t\pmc\io...ok 1/31 skipped: clone not finished yet t\pmc\iter.ok 1/41 skipped: N/Y: length of rest of array t\pmc\key..ok t\pmc\managedstructok t\pmc\mmd..ok t\pmc\multiarray...ok t\pmc\multisub.ok t\pmc\n_arithmeticsok t\pmc\namespace...
What is the default MRO?
Hi, What is parrot's default method resolution order? Is it like the old Python MRO (left-to-right, depth-first)? Is it like the new Python MRO [1] (left-to-right, depth-first, but discard all but the last occurrence of duplicates)? [1] "Unifying types and classes in Python 2.2" by Guido van Rossum http://www.python.org/2.2/descrintro.html Regards, Roger Browne
PGE now supports grammars, built-in rules
I've just checked in changes to PGE that enable it to support
grammars, as well as some more built-in rules (,
, , , etc.). To create a new grammar,
just create a subclass of "PGE::Rule" and install new rules into
the new grammar's namespace:
.sub main @MAIN
load_bytecode "PGE.pbc"
.local pmc p6rule
p6rule = find_global "PGE", "p6rule"
$P0 = getclass "PGE::Rule"
$P1 = subclass $P0, "MyClass"
# create a custom MyClass::alpha rule
$P0 = p6rule("<[abcde]>")
store_global "MyClass", "alpha", $P0
$P0 = p6rule("^ ")
$P1 = $P0("ab23") # matches "ab23"
$I0 = $P1.__get_bool()
print $I0
print "\n"
$P1 = $P0("zz23") # doesn't match zz23
$I0 = $P1.__get_bool()
print $I0
print "\n"
.end
I've added some more tests for the above, but many many more
are needed. If anyone wants to request (or better yet, submit
patches for) other of the default built-in rules, I'll be glad
to add them.
Pm
is_deeply() and code refs
Currently, throwing is_deeply() a code ref causes it to barf.
perl -MTest::More -wle 'print is_deeply sub {}, sub {}'
WHOA! No type in _deep_check
This should never happen! Please contact the author immediately!
# Looks like your test died before it could output anything.
is_deeply() doesn't know what to do with code refs. What should it do?
What it *shouldn't* do is what Test.pm does, namely execute the code ref and
compare the values returned. It would just compare the refernces.
This much is obvious, this should pass:
is_deeply \&foo, \&foo;
The same code ref is being compared. But here's the tricky part.
is_deeply sub { 42 }, sub { 42 };
Does that pass? ie. Are we just comparing the reference value or should
is_deeply() decompile the subroutine and see if they contain the same code?
(Technical considerations aside, for the moment).
Given that is_deeply() considers these to be equivalent:
is_deeply [ 42 ], [ 42 ];
I think comparing the decompiled source code is consistent, but is it
useful? Anyone have use cases for this?
--
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: is_deeply() and code refs
I'll chime in, as I'm the one who initially raised the idea : )
I'll start with a use-case: my initial motivation for having is_deeply
handle coderefs came up while building certain unit tests for a
rewrite of DBD::Mock. Several of the worker functions return complex
data structures -- which may contain coderefs -- and I'd like to
simply hand the whole lot off to is_deeply and have the work done for
me.
My inital strategy for implementing this was a two-tiered approach.
First, compare the references; if they're the same, return true, go no
futher. If they differ, however, say if anonymous subs were thrown
into the mix, then use B::Deparse to decompile both subs, comparing
their textual representations.
My initial quick-glance at B::Deparse's documentation mentions
something about perl optimising certain constants away, which could
well throw a spanner into the works. Storable uses B::Deparse when
serialising coderefs, though, so I'm certain there's a way around
this.
Collin Winter
On 6/25/05, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Currently, throwing is_deeply() a code ref causes it to barf.
>
> perl -MTest::More -wle 'print is_deeply sub {}, sub {}'
> WHOA! No type in _deep_check
> This should never happen! Please contact the author immediately!
> # Looks like your test died before it could output anything.
>
>
> is_deeply() doesn't know what to do with code refs. What should it do?
>
> What it *shouldn't* do is what Test.pm does, namely execute the code ref and
> compare the values returned. It would just compare the refernces.
>
> This much is obvious, this should pass:
>
> is_deeply \&foo, \&foo;
>
> The same code ref is being compared. But here's the tricky part.
>
> is_deeply sub { 42 }, sub { 42 };
>
> Does that pass? ie. Are we just comparing the reference value or should
> is_deeply() decompile the subroutine and see if they contain the same code?
> (Technical considerations aside, for the moment).
>
> Given that is_deeply() considers these to be equivalent:
>
> is_deeply [ 42 ], [ 42 ];
>
> I think comparing the decompiled source code is consistent, but is it
> useful? Anyone have use cases for this?
>
>
> --
> 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: is_deeply() and code refs
On Sun, Jun 26, 2005 at 12:08:35AM -0400, Collin Winter wrote: > My inital strategy for implementing this was a two-tiered approach. > First, compare the references; if they're the same, return true, go no > futher. If they differ, however, say if anonymous subs were thrown > into the mix, then use B::Deparse to decompile both subs, comparing > their textual representations. That's what I'm thinking. > My initial quick-glance at B::Deparse's documentation mentions > something about perl optimising certain constants away, which could > well throw a spanner into the works. Storable uses B::Deparse when > serialising coderefs, though, so I'm certain there's a way around > this. That shouldn't matter because any oddities B::Deparse applies to one code ref it will apply to the other. For equivalent code the decompiled result should be the same. -- 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: is_deeply() and code refs
> > My initial quick-glance at B::Deparse's documentation mentions > > something about perl optimising certain constants away, which could > > well throw a spanner into the works. Storable uses B::Deparse when > > serialising coderefs, though, so I'm certain there's a way around > > this. > > That shouldn't matter because any oddities B::Deparse applies to one code > ref it will apply to the other. For equivalent code the decompiled > result should be the same. After tinkering with B::Deparse for a bit, I think this particular "oddity" may just be a result of poorly-written docs (or, more probably, poorly-read on my part). The module seems to do the right thing in all cases I could come up with (i.e., it only optimises out truly-useless constants), so it should be safe to use for this particular purpose. With this matter sorted, I've started on the code and requisite tests to make the new stuff work. Collin Winter
Fwd: [CPAN Upload: P/PE/PETDANCE/Test-Harness-2.51_02.tar.gz: [EMAIL PROTECTED]
I've just uploaded Test::Harness 2.51_02. It turns off the timer by default, and adds a --timer switch to prove. Please try it out and see if all is well because I'm going to make it 2.52 tomorrow. And now, I must go to bed so I can drive to Toronto... xoxo, Andy -- Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
