Re: [perl #39714] [TODO] Refactor IMCC to remove static globals
On Thu, Feb 12, 2009 at 15:53, Will Coleda w...@coleda.com wrote: On Thu, Feb 12, 2009 at 6:09 PM, kjstol parrotc...@gmail.com wrote: On Thu, Feb 12, 2009 at 9:22 PM, Will Coleda via RT parrotbug-follo...@parrotcode.org wrote: On Tue Jul 04 19:30:44 2006, autri...@gmail.com wrote: IMCC currently relies on a lot of static globals to carry state, and cannot reliably restore them when an error occurs. (grep for static and FIXME global in the IMCC tree.) Allison had ruled that reentrancy should be possible for IMCC, and this would be a good refactoring project. We've rejected a lot of clean up IMCC tickets with the thought that we eventually want PIRC to take over. Anyone think this falls into the same category? I would like to indicate that while most of PIRC's done, it's not finished yet. Major issue now is the bug with STRING and FLOATVAL constants bug (there's 1 or 2 tickets on that). I haven't really had the energy or time to work on that recently. The rest is just a matter of test+fix cycle; I'm sure there's all sorts of cases that should be tested more properly than I've done. So, although I'm confident that together we can fix PIRC, don't throw out imcc just yet.. kjs To be clear, I'm not saying throw out IMCC, I'm saying, Let's not bother trying to fix tricky bits of IMCC if we're just going to throw it out later. i want to go into production (1.0) knowing what's broken in imcc rather than hiding the broken things in closed/rejected tickets. what do we get by hiding bugs? surprises. i could use fewer of those--my teeth still hurt from that surprise trip to the dentist this week. ~jerry
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: 1) Are we going to be relying on libraries to handle our BigInt/BigNum implementations, or are we intending to roll our own? we can't rely on external libraries, whether for bignum, unicode, gc, or anything else. we can detect and use them, however, if they exist. ~jerry
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 08:45, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: On Thu Feb 05 08:40:47 2009, particle wrote: On Thu, Feb 5, 2009 at 08:26, Andrew Whitworth via RT parrotbug-follo...@parrotcode.org wrote: 1) Are we going to be relying on libraries to handle our BigInt/BigNum implementations, or are we intending to roll our own? we can't rely on external libraries, whether for bignum, unicode, gc, or anything else. we can detect and use them, however, if they exist. ~jerry Okay, maybe rely was the wrong word to use. Current implementation of BigInt.pmc uses GMP if it's available, else it throws exceptions that there is no bug number library present to implement the behavior. Same is true of the unicode charset and ICU. We don't require ICU or GMP to build parrot, but we don't implement these behaviors without them. but we do implement these behaviors, at least some of them. for example, i don't have icu installed, but i can still use french quotes in rakudo. i'll get an exception if i try to downcase a string of japanese text (a silly example, but it won't throw if i have icu) because not all unicode functionality has been implemented natively *yet*. Question is: Are we going to do this same thing for BigNum (use a library if present, throw sane exceptions otherwise), or are we going to roll our own BigNum implementation? we will roll our own bignum, and give users the ability to use gmp or another external library at configure time. until we do roll our own, we should provide a default implementation that throws descriptive exceptions. ~jerry
Re: [perl #37993] [BUG] optimized parrot behaves differently than non-optimized (win32-msvc)
On Thu, Feb 5, 2009 at 10:44, Reini Urban via RT parrotbug-follo...@parrotcode.org wrote: On Thu Jan 29 06:05:13 2009, Whiteknight wrote: On Wed Dec 24 05:39:54 2008, Whiteknight wrote: On Tue Dec 23 19:02:17 2008, jk...@verizon.net wrote: On Sat Jun 14 17:15:32 2008, jk...@verizon.net wrote: Would it be possible to test Parrot on Win32 non-optimized and optimized so as to see whether this is still a bug? This neg -0 = 0 error is observable on msvc and mingw. It is caused by the msvcrt.dll (aka the libc) for windows and is therefore parrot and compiler independent. cygwin is not affected, since newlib has this correct. We could work around it in the op for neg (DWIM) or keep it as expected platform semantics. I would vote for platform unity, and fix the neg -0 case. +1 for fixing -0 to work the same everywhere. ~jerry
Re: [perl #36330] [TODO] Create a BigNum PMC
On Thu, Feb 5, 2009 at 10:23, Will Coleda w...@coleda.com wrote: On Thu, Feb 5, 2009 at 1:12 PM, chromatic chroma...@wgz.org wrote: On Thursday 05 February 2009 08:57:18 jerry gay wrote: we will roll our own bignum, and give users the ability to use gmp or another external library at configure time. That sounds like a fantastic recipe for hard-to-debug configuration problems and all of the joys of fixing copious amounts of bugs we don't even know about. We're pretty decent at writing VMs and compiler tools and languages. If we were also good at writing transcendental and arbirtrary precision math libraries, we'd probably already have written one. -- c My 2 cents: it's ok to rely on external libraries. If they don't exist on our core platforms, we could do something crazy like help port them. We do not need to reinvent every wheel. We're already reinventing several as it stands. silly me. i keep getting caught up in old-think lately. of course, we've changed direction on this point, and the new-think is that we do plan on relying on external libraries where it makes sense. we need sane overflow semantics for our numeric pmcs if gmp isn't found, and sane exceptions for unicode operations if icu isn't available. a big warning in the configure output if icu or gmp isn't found would certainly be a nice addition, so users know what they're in store for if they don't have the (all but)? required external libraries installed. sorry for the confusion. ~jerry
Re: [perl #59790] t/stm/basic_mt.t #4 hangs on several platforms
On Sat, Jan 31, 2009 at 16:06, James Keenan via RT parrotbug-follo...@parrotcode.org wrote: The t/stm/*.t tests have gone away (when or whence I do not know), so I propose we close this ticket. Any objections? the STM subsystem has been removed. close the ticket, and all other STM-related tickets. ~jerry
Re: [svn:parrot] r36057 - in trunk: . config/auto config/auto/format config/gen/config_h include/parrot src t/compilers/imcc/syn t/op
On Tue, Jan 27, 2009 at 10:58, Nicholas Clark nw...@colon.colondot.net wrote:
On Tue, Jan 27, 2009 at 10:24:46AM -0800, parti...@cvs.perl.org wrote:
-gen_sprintf_call(tc, info, ch);
-ts = cstr2pstr(tc);
+/* check for Inf and NaN values */
+if (thefloat == PARROT_FLOATVAL_INF_POSITIVE) {
+ts = cstr2pstr(PARROT_CSTRING_INF_POSITIVE);
+}
+else if (thefloat ==
PARROT_FLOATVAL_INF_NEGATIVE) {
+ts = cstr2pstr(PARROT_CSTRING_INF_NEGATIVE);
+}
+/* XXX for some reason, this comparison isn't
working
+else if (thefloat == PARROT_FLOATVAL_NAN_QUIET)
{
No, it is working :-)
NaN != NaN.
Hence why = has 4 possible return values.
+ts = cstr2pstr(PARROT_CSTRING_NAN_QUIET);
+}
+*/
+else if (thefloat != thefloat) {
The above is the valid test for a NaN.
Note, Intel chose that the default optimiser setting on their compiler should
be buggy. (Advice from Klortho #11912). The perl 5 Linux hints file suggests
that one needs to add -we147 to enable correct floating point behaviour.
The best test that I'm aware of for is it NaN or Inf? is val != val * 0;
Then, NaN is val != val, +Inf is val 0, -Inf is val 0;
thanks! patched up in r36071 and r36072.
~jerry
Re: [perl #62010] [PATCH] fix PARROT_EXPORT visibility=default for gcc other than 4.x
On Thu, Jan 8, 2009 at 15:42, Mark Glines m...@glines.org wrote: donald.hun...@gmail.com wrote: I was pretty averse to adding an additional configure step myself. The problem is that warnings.pm checks specifically for supported compiler flags and I didn't want to include other things there. The bug is that gcc.pm is hardcoded for version 4.x rather than checking. I didn't want to add a duplicate check for -fvisibility=hidden in this file. As I understand it, -fvisibility=hidden goes hand in hand with __attribute__((visibility(default) so a single check covers both. If you want to implement the fix as an explicit check for __attribute__((visibility(default) in gcc.pm then that would work. Perhaps the simplest thing to do is just move my check into warnings.pm after all. My guess is that it's never right to use -fvisibility=hidden without also using __attribute__ ... so if one is used then the other needs to be as well. That seems to be the best argument for keeping them in the same place. Is there any version of gcc which accepts -fvisibility=hidden but not __attribute__((visibility(default)))? If not, then I'm worrying about nothing, and we can probably just use the existing check for both. But I agree, neither of these features makes much sense without the other. decoupling is usually a good thing, but here i don't think it's worth it. stick this functionality in an existing configure step. ~jerry
Re: [perl #57492] [CAGE] Explore possible speedups of t/configure/*.t tests
On Sun, Nov 23, 2008 at 13:26, James Keenan via RT [EMAIL PROTECTED] wrote: On Mon Sep 08 18:43:49 2008, [EMAIL PROTECTED] wrote: On Tue Aug 19 19:28:43 2008, [EMAIL PROTECTED] wrote: A net total of 5 t/configure/*.t files were eliminated tonight as part of r30368 (RT 57780). And I've been able to consolidate a few more over the past few weeks. We now have 47 tests, down from a high of about 61. If anyone wants to suggest specific t/configure/*.t tests which could be merged (in the sense that their individual tests could logically sit within the same file), please speak up. Otherwise, I will resolve this ticket within 7 days. the use_ok tests can all go in one file, so they're only run once. ~jerry
Re: [perl #60624] [DEPRECATED] PARROT_API changes to PARROT_EXPORT
On Tue, Nov 18, 2008 at 05:16, Andrew Whitworth [EMAIL PROTECTED]wrote: On Mon, Nov 17, 2008 at 9:50 PM, via RT Jerry Gay [EMAIL PROTECTED] wrote: # New Ticket Created by Jerry Gay # Please include the string: [perl #60624] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60624 from DEPRECATED.pod: =item PARROT_API changes to PARROT_EXPORT [post 0.8.1] The PARROT_API name suggests something that is not the case yet. This will become PARROT_EXPORT after November 2008 release. (We will reintroduce PARROT_API on specific functions where appropriate post 1.0.0.) this is the rt tracking ticket. the work has begun in the api2export branch. Is this the only purpose of the branch, to change PARROT_API to PARROT_EXPORT? If so, it seems like it could be done in a single sed job and not need an entire branch for it. --Andrew Whitworth yes, that's the purpose. however, it can't be done until after release, it must be tested on multiple platforms since it affects the build, and some files (like NEWS and DEPRECATED.pod) don't change. the branch will likely be merged with trunk today or tomorrow. it builds on windows, and i will test it on linux now. branches are cheap. ~jerry
Re: [perl #60566] Broken link to Debian packages
On Sat, Nov 15, 2008 at 23:37, via RT Matt Kraai [EMAIL PROTECTED] wrote: # New Ticket Created by Matt Kraai # Please include the string: [perl #60566] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60566 Howdy, The link to the Debian packages on http://www.parrot.org/download is broken, apparently because line preceding it is a partial copy. The attached patch may make the issue clearer. -- Matt http://ftbfs.org/ --- download~ 2008-11-15 23:35:15.0 -0800 +++ download2008-11-15 23:35:23.0 -0800 @@ -107,7 +107,6 @@ !-- lia href=http://ftp.debian.org/debian/pool/main/p/parrot/;Debian Packages/a/li p--/p -lia href=http://alioth.debian.org/projects/pkg-parrot/ lia href=http://alioth.debian.org/projects/pkg-parrot/;Debian Packages/a/li lia href=http://www.gentoo-portage.com/dev-lang/parrot Gentoo/a/li lia href=http://www.freebsd.org/cgi/ports.cgi?query=parrot Freebsd/a/li fixed at http://www.parrot.org/download. thanks for reporting. ~jerry
Re: [perl #60568] Re: Broken link to Debian packages
On Sat, Nov 15, 2008 at 23:39, via RT Matt Kraai [EMAIL PROTECTED] wrote: # New Ticket Created by Matt Kraai # Please include the string: [perl #60568] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60568 On Sat, Nov 15, 2008 at 11:37:20PM -0800, Matt Kraai wrote: The link to the Debian packages on http://www.parrot.org/download is broken, apparently because line preceding it is a partial copy. The attached patch may make the issue clearer. I forgot to add that it would be nice if there was a link on each page indicating how and where to report problems. It took me a bit of searching before I finally found instructions on the How to Get Involved page. -- Matt http://ftbfs.org/ good point, but not related to this ticket. i've added #60578 to track this issue. ~jerry
Re: [perl #60098] [BUG] load_bytecode couldn't find file 'P6object.pbc'
On Fri, Oct 24, 2008 at 8:49 AM, via RT Canol Gökel [EMAIL PROTECTED] wrote: # New Ticket Created by Canol Gökel # Please include the string: [perl #60098] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60098 After doing the Windows installation via setup-parrot-0.8.0.exe I cannot run the perl 6 compiler. When I do for example: perl6 example.pl It gives this error: load_bytecode couldn't find file 'P6object.pbc' current instr.: 'onload' pc 0 (src/gen_builtins.pir:28) called from Sub 'parrot;Perl6;Compiler;main' pc -1 ((unknown file):-1) this seems to be a bug, perhaps in the code that generates the perl6 executable. in the meantime, you can remove perl6.exe (in the bin/ dir) and create perl6.cmd (same dir) with the following contents: @echo off rem adjust the path below to suit your environment set PARROT_ROOTDIR=c:\parrot-0.8.0 %PARROT_ROOTDIR%\bin\parrot.exe %PARROT_ROOTDIR%\languages\perl6\perl6.pbc %* ~jerry
Re: [perl #60070] [BUG] make opsrenumber causes build to fail
On Wed, Oct 22, 2008 at 10:49 PM, Patrick R. Michaud (via RT)
[EMAIL PROTECTED] wrote:
# New Ticket Created by Patrick R. Michaud
# Please include the string: [perl #60070]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60070
In the lex branch I'm trying to add a new opcode, but
I'm running into a build issue with opcode renumbering --
after adding an opcode and running make opsrenumber,
attempting to rebuild parrot fails with:
/usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145,
$op line 11.
make: *** [lib/Parrot/OpLib/core.pm] Error 9
In fact, this failure appears even if a new opcode isn't added --
simply performing make opsrenumber followed by make results in
the same error:
$ svn up
At revision 32122.
$ make opsrenumber
/usr/bin/perl tools/dev/opsrenumber.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
$ make
[...]
/usr/bin/perl tools/build/ops2pm.pl src/ops/core.ops src/ops/bit.ops
src/ops/cmp.ops src/ops/debug.ops src/ops/experimental.ops src/ops/io.ops
src/ops/math.ops src/ops/object.ops src/ops/pic.ops src/ops/pmc.ops
src/ops/set.ops src/ops/stm.ops src/ops/string.ops src/ops/sys.ops
src/ops/var.ops
skipped opcode is also in src/ops/ops.num at lib/Parrot/Ops2pm.pm line 145,
$op line 11.
make: *** [lib/Parrot/OpLib/core.pm] Error 9
$
Since a number of steps have changed since the last time I worked
with adding/removing opcodes (April 2008), and I have little idea
what might be causing this, I'm filing this ticket in hopes that
someone can clear things up for me.
this is definitely fallout from the mmd branch merge. seems ops.skip
hasn't been modified, and make opsrenumber was never run after opcodes
were modified.
i wrote a hack that suggests all ops from ops.skip should be removed:
#!perl
use strict;
use warnings;
open my($NUM), '', 'ops.num'
or die $!;
open my($SKIP), '', 'ops.skip'
or die $!;
my $seen = {};
while ($SKIP) {
next unless m/^(\w+)/;
$seen-{$1}++;
}
while ($NUM) {
next unless m/^(\w+)/;
--$seen-{$1}
if defined $seen-{$1};
}
print $seen-{$_} ? ($_,$/) : ()
for keys %$seen;
=
c:\usr\local\parrot\main\src\opsseen.pl
c:\usr\local\parrot\main\src\ops
=
it returns no results, suggesting that all ops be removed from ops.skip.
indeed, after this, i am able to rebuild parrot, even with an added
opcode to core.ops (and running make opsrenumber).
however, i'm too tired to wait for the test suite to finish running,
so i'm reporting this before i hit the sack and will pick it up on the
morrow if nobody beats me to it.
~jerry
Re: Fw: Running Perl 6 Tests
On Mon, Oct 20, 2008 at 8:55 AM, Ovid [EMAIL PROTECTED] wrote: It would help if I sent this to the correct mailing list. Oops. Cheers, Ovid --- On Mon, 20/10/08, Ovid [EMAIL PROTECTED] wrote: I've been doing some work integrating Perl 6 into vim and now I'm trying to figure out how to run individual Perl 6 tests. It appears that the incantation is along the lines of: perl t/harness --verbosity 1 t/01-sanity/02-counter.t However, in digging further, I found this: perl t/harness --verbosity 1 t/02-test-pm/1-basic.t That starts off with Statement not terminated properly at line 87, near (\Hello Wo and goes downhill from there. In fact, in reading through the Makefile, I don't see that this gets run unless you do 'make testtest' (added by particle back in Dec 2007). This doesn't appear to be documented. Is it supposed to be run? Should those Perl 6 tests be valid? testtest and 02-test-pm/ should either be ripped out or heavily modified. it was intended to be tests required to pass in order to run pugs' Test.pm. rakudo never did use pugs' Test.pm, and no longer attempts to. these tests are failing, and not run by default. i'd like to see requirements for rakudo's Test.pm tested instead. Also, the way that t/00-parrot/06-op-inplace.t is written forces the test numbers to be out of sequence. This causes make test to fail, even though it's merely a parse error. The Test.pm module appears to work (I've only checked it superficially), so why not use that to make some of these tests a bit easier to write? Are we trying to avoid loading modules while testing core features? yes, 00-parrot tests are prerequisites to running Test.pm. they can't use the module to perform their tests. it does indeed look like the test numbers are out of order. ...time passes... it seems infix:**= is broken. the fix isn't obvious to me. perplexing... doubly so as t/spec/S03-operators/assign.t passes these. ~jerry ~jerry
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Thu, Oct 16, 2008 at 6:49 AM, jerry gay [EMAIL PROTECTED] wrote: On Wed, Oct 15, 2008 at 11:42 AM, Andrew Whitworth via RT [EMAIL PROTECTED] wrote: On Wed Jul 30 11:57:39 2008, coke wrote: PDD19 lists this as deprecated now, changing from an [RFC] to [DEPRECATED], re-opening from stalled. The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit .namespace [] in these situations. Since PCT is one of the biggest producers of PIR code, we obviously can't move forward on the deprecation of this feature until CodeString is updated to emit [] for an empty namespace instead of just saying .namespace. I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? since .namespace and .namespace [] mean the same thing, i don't see a reason this can't be converted in trunk and piecemeal. it's already listed as deprecated, so it's just a matter of tuits. i think i have some. am i alone? i've committed one-line changes to pge and tge that seem to have modified the behavior of .namespace with the root namespace to emit empty brackets in r32051. if this can be verified independently, this ticket can be closed. ~jerry
Re: [perl #59940] [patch] convert perl tests to parrot
On Fri, Oct 17, 2008 at 4:00 PM, Mark Grimes [EMAIL PROTECTED] wrote:
The attached patch now includes the pir/pasm_error_output* tests in
pir. I have also added t/pmc/complex.t. Couple of issues:
1) I am not sure how to deal with pcc_sub's so I put them into
t/pmc/objects-pcc_sub.t
2) There appears to be a bug that shows up in complex.t -
complex_divide_by_zero_*(). I have skip'ed those tests and will submit
a simplified bug report and test.
This drops the test run time for these from 24 seconds to less than 2.
Also, this patch should hopefully apply cleanly. I had to make some
changes to the $Id: line in the patch by hand.
-Mark
On Fri, Oct 17, 2008 at 10:35 AM, Mark Grimes [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2008 at 12:39 AM, Christoph Otto via RT
[EMAIL PROTECTED] wrote:
You can fix the foo_error_bar tests by using an exception handler to
catch the (appropriate type of) exception.
The simplest way is to use push_eh with a label. If the exception is
raised, control will jump to that label. t/pmc/resizablestringarray.t
uses this style.
Thanks Christoph. That is pretty straight forward. I'll update and
send a new patch.
when I was on my PIRifying binge, but I didn't have nearly enough
patience at the time.
Agreed. Takes quite a bit of patients, but I have put together a vim
function and perl script that takes care of some of the more common
test idioms automatically. I'll make it public after I clean it up a
bit more.
Any suggestion on how to deal the the .pcc_sub tests. I admit, I don't
quite understand what pcc_sub are, and I get an error whenever they
are included:
error:imcc:syntax error, unexpected PCC_SUB, exprint $end ('.pcc_sub')
There are two tests in object.t that use them.
s/\.pcc_sub/\.sub/g; ## this will fix it
~jerry
Re: [perl #48549] [DEPRECATED] [PDD19] Let .namespace (no args) have empty brackets
On Wed, Oct 15, 2008 at 11:42 AM, Andrew Whitworth via RT [EMAIL PROTECTED] wrote: On Wed Jul 30 11:57:39 2008, coke wrote: PDD19 lists this as deprecated now, changing from an [RFC] to [DEPRECATED], re-opening from stalled. The big hangup for this ticket is that various parts of PCT and the CodeString PMC do not support empty brackets, and therefore PCT does not emit .namespace [] in these situations. Since PCT is one of the biggest producers of PIR code, we obviously can't move forward on the deprecation of this feature until CodeString is updated to emit [] for an empty namespace instead of just saying .namespace. I know pmichaud was talking about a major rewrite of PGE in the future, maybe this change could be included in the laundry list of things to do during that time? since .namespace and .namespace [] mean the same thing, i don't see a reason this can't be converted in trunk and piecemeal. it's already listed as deprecated, so it's just a matter of tuits. i think i have some. am i alone? ~jerry
Re: [perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
On Thu, Oct 16, 2008 at 10:12 AM, Andrew Whitworth via RT [EMAIL PROTECTED] wrote: On Sat Jun 11 13:08:49 2005, chip wrote: Short version: Up through version 0.8 or so, we promise to break everything constantly (but not until we have a good reason). After that, we will establish version number thresholds below which individual APIs will not change. For example, only on a major version change are we allowed to even consider breaking the embedding API. On the other hand, we may break pasm somewhat more frequently: humans should only write pir, not pasm, and it's not against the law to abuse silicon-based life forms. Has anybody put any thought into this? Do we have any documents or drafts which address this issue? We are getting close enough to the 0.8 release that's mentioned here as a specific milestone for getting this done. replace 0.8 with 0.50 or so. we're not close enough to release at 0.8 to worry about this yet. ~jerry
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
On Tue, Oct 14, 2008 at 7:23 AM, Andy Dougherty [EMAIL PROTECTED] wrote: On Sat, 11 Oct 2008, Allison Randal via RT wrote: jerry gay wrote: .\src\pmc\float.c(3340) : warning C4204: nonstandard extension used : non-constant aggregate initializer there are now hundreds of these warnings in that build. we do have warnings ratcheted up pretty high, but i don't think it's worth relaxing them for this construct unless it's very difficult to change the code generator--i assume this is generated code, since it's in so many pmc .c files. i may get a chance to investigate further this evening, if somebody hasn't beaten me to it. Yes, that's generated code, it's part of the initialization of MULTIs declared in a PMC. I was hoping to avoid all those C strings. But, try r31879. Yes, that works fine. works fine here, too. thanks. ~jerry
Re: [svn:parrot] r31791 - trunk/t/pmc
On Wed, Oct 8, 2008 at 1:59 PM, Nicholas Clark [EMAIL PROTECTED] wrote: On Wed, Oct 08, 2008 at 01:48:17PM -0700, chromatic wrote: In general, filesystems are case-insensitive, not platforms. I believe Mac OS X's Hateful File System Plus is one offender, though you can use UFS instead. HFS+ itself can be set to case sensitive. I have a machine partitioned so that it has a case sensitive partition, as well as a boot partition with the default. I have no idea whether NTFS can be set to case sensitive. I wouldn't be surprised if it can, and that that would thoroughly surprise most programs :-) Likewise, *nix can mount file systems from machines that are not case sensitive. You just can't know. i believe ntfs 5.0 can be set case sensitive--i haven't been crazy enough to try. give me a method of detecting the file system upon which these tests are running, and i'll give you a box of doughnuts. i might even modify the test. ~jerry
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
On Mon, Oct 6, 2008 at 12:00 PM, via RT Andy Dougherty
[EMAIL PROTECTED] wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #59658]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59658
Trying to compile today's parrot on:
SunOS xxx 5.8 Generic_117350-02 sun4u sparc SUNW,Ultra-5_10
with Sun's compiler:
cc: WorkShop Compilers 4.2 30 Oct 1996 C 4.2
it failed with the following errors:
src/pmc/float.c
/home/doughera/src/parrot/parrot-cc/tools/build/../../lib/Parrot/Pmc2c/PCCMETHOD.pm,
line 465: warning: statement not reached
[ repeated 17 times ]
./src/pmc/float.c, line 3340: non-constant initializer: op U*
./src/pmc/float.c, line 3341: non-constant initializer: op U*
./src/pmc/float.c, line 3342: non-constant initializer: op U*
[ 21 more similar errors ]
./src/pmc/float.c, line 3454: cannot recover from previous errors
Looking at src/pmc/float.c, the first lines in question are:
const multi_func_list _temp_multi_func_list[] = {
{ CONST_STRING(interp, is_equal),/* line 3340 */
CONST_STRING(interp, IJPP),/* line 3341 */
CONST_STRING(interp, Float,Float), /* line 3342 */
(funcptr_t) Parrot_Float_multi_is_equal_Float },
which ultimately expand to:
const multi_func_list _temp_multi_func_list[] = {
{ ( interp ) - const_cstring_table [ 515 ],
( interp ) - const_cstring_table [ 84 ],
( interp ) - const_cstring_table [ 639 ],
(funcptr_t) Parrot_Float_multi_is_equal_Float },
which indeed are non-constant initializers. GNU cc accepts this, as do
more modern compilers from Sun (such as version 5.9). I'm guessing it's
a C99 thing, but I don't actually know.
What to do about it? I suppose I could go in and rewrite those statements
(and similar ones that crop up in other PMCs) but I certainly won't
have any time to do that any time soon.
Should anyone care? It's certainly an old compiler, but it's the only
Sun compiler I have available on SPARC, and SPARC has often been a very
helpful platform for debugging alignment and endian issues in parrot.
msvc 9.0 (the most recent version) also complains:
.\src\pmc\float.c(3340) : warning C4204: nonstandard extension used
: non-constant aggregate initializer
there are now hundreds of these warnings in that build. we do have
warnings ratcheted up pretty high, but i don't think it's worth
relaxing them for this construct unless it's very difficult to change
the code generator--i assume this is generated code, since it's in so
many pmc .c files. i may get a chance to investigate further this
evening, if somebody hasn't beaten me to it.
~jerry
Re: [perl #59374] [BUG] pmc2c produces incorrect code for RETURN(INTVAL -1)
On Fri, Sep 26, 2008 at 9:11 AM, Patrick R. Michaud (via RT) [EMAIL PROTECTED] wrote: # New Ticket Created by Patrick R. Michaud # Please include the string: [perl #59374] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=59374 Summary: pmc2c produces incorrect code for returning negative integer constants, as in RETURN(INTVAL -1) Longer description: In the set_readline_interactive method of the ParrotIO PMC line 200 reads RETURN(INTVAL -1); This is supposed to return a value of -1 when the method is called and the readline library is not present. However, when run this is actually returning 1 (readline is not present in the example below): $ cat z.pir .sub main :main .local pmc stdin stdin = getstdin $I0 = stdin.'set_readline_interactive'(1) say $I0 .end $ ./parrot z.pir 1 Looking at the code generated in src/pmc/parrotio.c (line 775 on my system), we see: /*BEGIN RETURN INTVAL -1 */ /*BEGIN GENERATED ACCESSORS */ #line 777 ./src/pmc/parrotio.pmc CTX_REG_INT(_ctx, 0) = 1; I think somewhere the minus sign is being lost when the code is being generated. This also occurs earlier in the method for a couple of instances of RETURN(INTVAL -2): /*BEGIN RETURN INTVAL -2 */ /*BEGIN GENERATED ACCESSORS */ #line 722 ./src/pmc/parrotio.pmc CTX_REG_INT(_ctx, 0) = 2; Pm indeed. the code in parse_p_args_string in lib/Parrot/Pmc2c/PCCMETHOD.pm was losing the minus sign. i've committed a fix in r31441. after the change: [EMAIL PROTECTED]:~/parrot/trunk$ ./parrot z.pir -1 ~jerry
Re: [svn:parrot] r31385 - trunk/docs/book
On Wed, Sep 24, 2008 at 4:31 PM, chromatic [EMAIL PROTECTED] wrote: On Wednesday 24 September 2008 11:22:22 [EMAIL PROTECTED] wrote: Modified: trunk/docs/book/ch04_pir_subroutines.pod trunk/docs/book/ch09_hlls.pod Log: [Book] Add some basic info about VTables and HLL namespaces. Modified: trunk/docs/book/ch04_pir_subroutines.pod --- trunk/docs/book/ch04_pir_subroutines.pod (original) +++ trunk/docs/book/ch04_pir_subroutines.pod Wed Sep 24 11:22:22 2008 @@ -490,6 +490,63 @@ =head3 VTABLE Methods They're not really methods in any PIR or C sense though (I usually use the term entry), as they're not really inherited nor invoked through a dispatch scheme and they're stored elseways from methods on classes and PMCs, and I've never seen them spelled other than VTABLE in the source and vtable in discussion. Otherwise, the information here is correct. i believe (without looking) that the pmc pdd calls them vtable functions. i really wish the vtable methods meme would die. they're not methods. they are a collection functions which define the api to access the pmc, parrot's abstract data type. ~jerry
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what's the difference between gather and aggregating coroutine? lipstick. but seriously, folks, what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. but aren't hashes that funny key on your phone you type after you've entered your credit card info? oh, right, that's pound. huh? i thought that's an outdated form of currency. let's call it octothorpe. wait, what? you store your dispatch table in an octothorpe? we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. a related point: wherever these constructs are defined, they need to be documented. you may think CONTROL_RETURN is obviously for return statements, but many will find it quite strange that return is an Exception at all. ~jerry
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote: On Thu, Sep 18, 2008 at 8:37 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote: Aggregating coroutine and aggregating yield aren't nearly as zippy as 'gather' and 'take', but they're more meaningful to a broader audience, which may help the feature spread. I don't buy this. The Perl 6 terms are well chosen, and as soon as you know what they mean in the context of programming, you won't forget. The other versions ... well, let's leave it at easy to forget. (OK, one more thing -- the word coroutine scares people. Gather does not.) I'm rather hoping and expecting that gather and take become the meaningful names for this feature, much like grep started out as a Unix shell command but is now the language-agnostic term for extract things from a list matching a pattern. Now *this* I agree with. The first system to make a feature standard gets first try at standardizing the name. If they've chosen the name well, there's a decent chance it will stick. what some refer to as traits, perl 6 calls roles. what some refer to as associative arrays, perl calls hashes. [...] we need to be precise in naming constructs, rather than using common names. scientists call a chanterelle mushroom by its proper name, Cantharellus cibarius. Other languages have adopted the Perl shortname of hash as well, including Ruby and this odd little creature known as Parrot. Perhaps we should rename Parrot's Hash class to AssociativePMCArray? 1/2 ;-) we should call gather and take by their proper names where they're defined. aggregating coroutine is more precise and descriptive than is gather, however gather is much easier to say in polite company, and is therefore a better name to use at the language level. By this reasoning, we should also change the other exceptions: .CONTROL_RETURN = .CONTROL_SUB_RETURN (or .CONTROL_SUB_EXIT) .CONTROL_BREAK= .CONTROL_LOOP_EXIT .CONTROL_CONTINUE = .CONTROL_LOOP_NEXT and perhaps add .CONTROL_LOOP_REPEAT there as well. Note that I'm not at all opposed to this -- if we're going to do it for one, we really ought to do it for all. agreed. precision is of little benefit unless it's consistent across related functionality. ~jerry
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
On Tue, Sep 16, 2008 at 11:45 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: On Tue Sep 16 15:00:24 2008, [EMAIL PROTECTED] wrote: On Tuesday 16 September 2008 14:47:58 NotFound wrote: It certainly shouldn't segfault. But, the question is: why does it segfault at 206 parameters? Throwing an exception to avoid an error we don't understand isn't good for the long-term health of the VM. The problem is located inside compilers/imcc/pcc.c:pcc_get_args function. It has the comment /* XXX check avail len */ just at the point where the segfault happens. char buf[1024] is the variable overrunned. That sounds like a bog-standard static variable overflow, where each parameter requires five bytes of storage. If that's a good rule of thumb, we could malloc/free that buffer instead, and then beat anyone who uses more than a dozen parameters. -- c Looking at the code, it's 5n+1. r31200 changes the static buffer to a dynamic one of the correct size. The original PIR code now runs without segfaulting, as does a version with 20,000 int params. make test also passes, so nothing new appears to be broken. With the assumption that the said beatings will be a manual process, I'm marking this resolved. you didn't mention it, but i sincerely hope you committed a test with 20,000 params that proves this and makes sure we don't regress in a future revision. parrot needs much more stress testing like this, and it would be a shame to miss this opportunity. ~jerry
Re: [perl #58742] [TODO] Marker for RTs re SmartLinks
On Tue, Sep 16, 2008 at 5:14 AM, James Keenan via RT [EMAIL PROTECTED] wrote: On Tue Sep 16 00:08:29 2008, [EMAIL PROTECTED] wrote: On Monday 15 September 2008 20:06:11 James Keenan via RT wrote: See patch attached. The patch eliminates smartlink-related code from Parrot, but does not touch anything in languages/. It contains some commented out code that should probably just go away. Otherwise, +1. Yes, this was a first version of the patch which I rushed out largely to see what effect deleting the code would have on the Parrot and Perl 6 'make test' suites. (Answer: none, accounting for deleted tests.) My plan is to fine tune it by also deleting some comments referring to smartlinks in other tests such as t/pmc/object.t. parrot needs a way for us to measure spec coverage in our test suite. i started the current smartlinks code as an experiment in using moose, and as a reaction to the mess of smartlink code that's in the pugs repo. however, i'm not married to the code, so rip it out if you like--i never completed it, anyway. a few things about the smartlink code currently in pugs that needs to be addressed to work well with parrot: * parrot both follows the parrot design documents, and the perl 6 spec docs (mainly pge). this is not possible in pugs' system * it should be well-tested. if pugs' system is used, hopefully the tests can be used there as well * it should be easily maintainable. i don't find the pugs' code easy to read. i'd *love* to see smartlinks working in parrot. one of the big problems in the parrot test suite is our lack of ability to measure the test coverage of both code and spec. although smartlinks likely won't offer us solid quantitative metrics, it will provide important visual qualitative measures. oh, one other thing--there was a comment about a perl 6 syntax for smartlinks somewhere. that's outside the scope of this project, as all the spec/design docs are written in perl 5 pod. it's something to think about, but something we'll only address when we have a need (perhaps when/if the spec docs are rewritten in perl 6 pod?) ~jerry
Re: [perl #58934] [CAGE] 'make fulltest' says PASS at the end, although some tests failed
On Tue, Sep 16, 2008 at 12:27 PM, via RT Moritz Lenz [EMAIL PROTECTED] wrote: # New Ticket Created by Moritz Lenz # Please include the string: [perl #58934] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58934 'make fulltest' runs several chunks of tests, and does not show a final summary. So although some tests in some chunks fail, the last thing that the tester sees is something along these lines: ===( 35 )==All tests successful. Files=10, Tests=108, 29 wallclock secs ( 0.04 usr 0.02 sys + 19.55 cusr 1.44 csys = 21.05 CPU) Result: PASS make[1]: Leaving directory `/home/moritz/src/parrot' If only the last chunk succeeded. This is very misleading, and probably dangerous. At the very least it should say something like WARNING: not all tests were successful, scroll up to find out which failed. This could be done by collecting the return values from the various 'make test*' calls. Even better would be real summary at the end listing the failed tests. (Observed with perl-5.10.0 and Test::Harness 3.11, parrot as of shortly-before 0.7.1) Moritz -- Moritz Lenz http://moritz.faui2k3.org/ | http://perl-6.de/ parrot's fulltest runs the harness multiple times without a very clear distinction. as i understand, this behavior can now be changed, as we require T::H 3. the fulltest target must be modified to report the results from each harness run together at the end, rather than seperately after each harness run. ~jerry
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Thu, Sep 11, 2008 at 4:47 PM, James Keenan via RT [EMAIL PROTECTED] wrote: I'm trying to see if we can move this ticket toward resolution. I think that it has remained unresolved for so long because the original post originally called for two steps: (a) removal from Configure.pl of configuration steps which probed for features only used in specific language implementations; (b) development of a way to conduct such language-specific probes in the language directory trees after 'perl Configure.pl' and 'make' have been run. There were two specific steps cited for removal per (a): auto::python and auto::m4. By June of this year I had removed both of those from Parrot configuration. So that leaves us with (b). particle wrote: languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. Barney responded: One thing that held me back from using something like 'dotnet/Configure.pl' was that 'dotnet/Configure.pl' currently needs to be explicitly called after the main 'Configure.pl' has run. This is bad for universal languages testing. And that's where discussion left off three months ago. I am recommending the following: (1) Mark this ticket resolved. (2) Conduct discussion on list or IRC as to the best architecture/model for language-specific probes. (3) Once we've come to such resolution on (2), open a new RT to implement what we've decided. particle, Barney: Any objections? 's fine with me. ~jerry
Re: Why Some MMD Tests Fail
On Mon, Sep 8, 2008 at 1:09 AM, Allison Randal [EMAIL PROTECTED] wrote: a) Do abstract base classes as currently implemented in Parrot serve any useful purpose? If not, eliminate them. can they be replaced by roles? ~jerry
Re: [perl #39117] [TODO] Using v?snprintf/strlcpy/strlcat when useful
On Sun, Sep 7, 2008 at 2:07 PM, Andy Dougherty [EMAIL PROTECTED] wrote: On Sat, 6 Sep 2008, Christoph Otto via RT wrote: On Wed May 10 11:01:34 2006, stmpeters wrote: I'm taking a look at it. I should have something working this evening for the configs. Adding the HAS_BLAH's will take some additional time. Steve Peters [EMAIL PROTECTED] when useful is vague does not indicate why the extra configuration machinery is justified by whatever benefit we'd get from using these functions. If someone would like to make the requirements a little tighter or make the case for implementing this request (or even implement it), they'd be encouraged. Otherwise this ticket isn't very useful. It would be good to either go somewhere with this or reject this request. These functions are typically used in place of the plain sprintf and strcat family as a way to be explicitly careful about buffer overflows. Plain sprintf and strcat are both widely used in the parrot source. Replacing them when it would ease future maintenance and help ensure parrot is not susceptible to buffer overflows is a quite sensible path forward. As you correctly observe, no one has actually done anything about it yet. That doesn't mean it's not worth doing, however. I'd say it should simply stay as an open ticket. +1 ~jerry
Re: [perl #56382] [RFC] Making Test::Harness 3 available without including it in core parrot.
On Tue, Jul 1, 2008 at 7:17 AM, Will Coleda via RT
[EMAIL PROTECTED] wrote:
On Thu Jun 26 11:01:00 2008, [EMAIL PROTECTED] wrote:
chromatic wrote:
T::H 3 is only a requirement for people who want to type 'make
smolder' (and
eventually I hope 'make smoke'), so probing for it without bundling
it seems
eminently sensible to me.
Agreed. That's what we do with TAP::Harness::Archive.
Based on recent emails to the list, apparently 'make test' in trunk
seems to now require T::H 3. (not just for 'make smolder').
If we can do without T::H 3 for simple 'make test', that would be nice.
If we need it, then we need to have a graceful exit message on make test
and not the error we get now.
T::H 3 has been listed as a required dependency for many test-related
enhancements, such as parallel testing, aggregated testing, and smoke
testing. let's make it a requirement, rather than an optional
dependency. if it proves too burdensome for folks to upgrade, we can
rollback.
We also need to add a config probe to test for the version of T:H
available, and if it is NOT the minimum version, warn the user that
'make test' will fail to work for them.
We also need to see if we can require a specific version in
Bundle::Parrot. I'm not sure that's possible. particle?
yes, it's possible. easy, even. it's done is svn, and i can release to
cpan on short notice.
I don't particularly mind requiring T::H 3 even for 'make test', but we
definitely need to be careful about it. We should probably declare this
in our requirements in the tarball we post to CPAN as well so that don't
automatically fail most of our cpan testers.
that's what Makefile.PL is for. if we require Bundle::Parrot there, we
can make sure cpan testers have what they need. if we do the same in
Configure.pl, then we can make sure svn users have what they need,
too.
something like:
eval { require Bundle::Parrot };
if ($@) {
die Bundle::Parrot has not been installed, Configure.pl cannot continue.;
}
that is, if Bundle:: modules get registered with perl. i'm not sure
that's the case. anyone know better?
~jerry
Re: [svn:parrot-pdd] r30569 - trunk/docs/pdds
On Fri, Sep 5, 2008 at 2:36 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: On Tue, Sep 2, 2008 at 12:43 PM, Allison Randal [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: This must make the following syntax rule illegal: target = null because if null is declared as a .local, you can't know whether you want to nullify target, or want to set target's value to that of the .local variable null. I take it this is no problem; just stick to null target if you actually want to set target to 0/null. Yes, that's reasonable. The syntactic sugar was confusing in that case anyway. (Seemed like you were assigning a null value to the destination register, rather than nullifying the PMC in the destination register.) This belongs in a general category of opcodes where the standard transformation of call the opcode with the first argument stuck before an '=' sign doesn't really make sense. Allison the problem seems to be a bit bigger than I had foreseen. The issue is that ops with the first operand marked as 'OUT' may be rewritten as: target = op [operand [, operand]*]? However, consider the following: .local pmc getstdin $P0 = getstdin How should this be resolved? is the opcode 'getstdin' meant here, or is it the value of the .local getstdin. This problem occurrs with all ops, not only with single-operand ops. kjs the sugar for what can be on the left side of an equals sign needs to be changed. simply having a first parameter with OUT isn't enough. the same thing happens for $P0 = push $S1 which is legal pir syntax, but obscure at best. ops must have some means of specifying (perhaps an attribute like C:returns or C:rvalue?) that allows them to be on the right side of the equals. only this class of ops allows the syntax described above. in the case of .local pmc getstdin ... $P0 = getstdin this can be resolved because the (now) compiler knows (either during parsing or semantic analysis) that the Cgetstdin op is not allowed to be an rvalue and lookup Cgetstdin in the list of C.locals as a fallback. ~jerry
Re: [perl #58610] [ PATCH ] Broken link on parrotcode.org dev page - list item Parrot Testing Status
On Fri, Sep 5, 2008 at 9:59 AM, via RT Ronald Schmidt [EMAIL PROTECTED] wrote: # New Ticket Created by Ronald Schmidt # Please include the string: [perl #58610] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=58610 I applied for an account and built what seems to me to be an appropriate Parrot Testing Status page. My proposed link target is http://www.parrot.org/wiki/some-testing-status-tools . If someone wants to set me up as a site editor I will fix the link myself otherwise the page is available for someone else to fix the link. you're now an editor. have at it! ~jerry
Re: My Parrot 0.7.0 patches (cygwin)
On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban [EMAIL PROTECTED] wrote: I'll go now for something like #IF(key1|key2(key3!key4)) #IFNOT(key1|key2(key3!key4)) And probably a shortcut for the negative else clause, like #IF(cygwin): #ELSE: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. i know it was all caps before, but do we need to continue that trend? i find it ugly. stealing the markers from perl 6's test suite compiler directives, and using lower case and full english words, i suggest: #?if(foo|bar) ... #?else if(baz) ... #?else ... #?unless(quux) ... ~jerry
Re: 57548-CONDITIONED_LINE_enh
On Tue, Aug 26, 2008 at 9:16 AM, Reini Urban [EMAIL PROTECTED] wrote: jerry gay schrieb: On Tue, Aug 26, 2008 at 2:34 AM, Reini Urban [EMAIL PROTECTED] wrote: I'll go now for something like #IF(key1|key2(key3!key4)) #IFNOT(key1|key2(key3!key4)) I went for #UNLESS(expr): here. Also #ELSIF(expr): And probably a shortcut for the negative else clause, like #IF(cygwin): #ELSE: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. i know it was all caps before, but do we need to continue that trend? i find it ugly. stealing the markers from perl 6's test suite compiler directives, and using lower case and full english words, i suggest: #?if(foo|bar) ... #?else if(baz) ... #?else ... #?unless(quux) ... Okay, also fine. With or without the ending double-colon? the colon is unnecessary. the ending paren and a mandatory whitespace is enough. ~jerry
Re: My Parrot 0.7.0 patches (cygwin)
On Tue, Aug 26, 2008 at 11:00 AM, Allison Randal [EMAIL PROTECTED] wrote: jerry gay wrote: #+ and #- is lisp so I don't want to destroy #+ the syntax rules. #IF(): is quite short and easy to read. i know it was all caps before, but do we need to continue that trend? i find it ugly. All-caps is the Parrot coding standard for macros and #defines, and these fall in the same general category. in c code, i agree. this is not c, however. it is for a makefile template, where the makefile macro names (e.g. CP=$(PERL) -M...) are in all-caps. i think it would be easier to distinguish the makefile template generator macros from the makefile macros if they weren't the same case. #?else IFCONFIG=bar over #?ELSE IFCONFIG=bar i suppose it's just paint, though. i can live with either way, so i'll defer to you. ~jerry
Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak
On Fri, Aug 22, 2008 at 7:20 PM, Will Coleda [EMAIL PROTECTED] wrote: On Sat, Aug 16, 2008 at 11:39 PM, James Keenan via RT 4. Parrot::OpsRenumber::renum_op_map_file() has been revised so that it will behave properly before Parrot 1.0 -- when deletion of opcodes is still permitted -- and after 1.0 -- when no deletions are permitted. This flexibility is attained by providing it with the Parrot major version as an argument. This before-and-after functionality is tested in a heavily revised t/tools/ops2pm/05-renum_op_map_file.t. Several new sample files used in testing have been added to the distribution. I know you were implementing Jerry's requirement here, and that's good. I do wonder what the plan is for opcodes that are marked deprecated (which we can do today.) ; once they go past deprecated (before 1.0, we'd just delete them), what will happen when they are executed? will we add a :removed pragma on the opcode definition that will simply throw an exception when they are invoked? Will we just silently translate them to a noop? What about the case when we experimentally add an opcode between official releases, but back it out before the next release? What counts as an official release? How are we going to number the intervening releases? Do we have a version indicator to mark as stable/unstable/experimental/Don't Touch This Without A Hazmat Suit? What about experimental.ops? is that going to survive with its special treatment into post-1.0? I apologize for not asking these questions immediately following Jerry's original post, but I thought I had until version 0.99 to think about it. =-) These questions asked... I'm don't think they block application of the patch at all; I think these are all questions that should be answered in a new docs/project/release_strategy.pod which can then spawn TODOs as necessary. agreed. we still have time to address these questions. it would be nice if they weren't lost, though. i suggest a wiki page rather than a mess of rt tickets for better tracking at this point. seems to me that the wiki approach will allow us to collect and organize these thoughts as they occur, and serve as a solid draft when we formalize them later. 5. The name of the program that invokes Parrot::OpsRenumber is changed from tools/dev/ops_renum.mak to tools/dev/opsrenumber.pl. It is, after all, a Perl 5 program, so we provide it with a file name extension consistent with other programs in tools/dev/. 6. A new makefile target, renumberops, invokes tools/dev/opsrenumber.pl. Please review, particularly lib/Parrot/OpsRenumber.pm and t/tools/ops2pm/05-renum_op_map_file.t, which is where most of the really new stuff is found and/or demonstrated. I don't have any questions regarding these tests that are unique to these particular tests. it strikes me that the makefile target and the script name should be the same. there's still too much irregularity in parrot's naming conventions across the board--opcodes, pir syntax, makefiles, scripts, directories, filenames, c functions, etc. we'll concentrate on this in earnest as we approach our first general availability release (whether we call that release 1.0 or 2009R1 or Ball of Mud), however there's no reason to hold off. if anybody sees anything that looks a bit out of place (e.g. dynops vs. dynoplibs) take note of it by opening a CAGE ticket in rt. it may take some project team input to settle upon the preferred naming convention, but implementing that work can be done by any contributor and applied by any committer. ~jerry
Re: [CAGE] clean up stray test files
On Wed, Aug 20, 2008 at 2:32 PM, Allison Randal [EMAIL PROTECTED] wrote: Running 'make test' now fills the main directory of the repository with junk files like: test_98093.out test_37653.c test_98093.ldo test_97159.c The offending tests need to be modified to clean up after themselves. make sure to use File::Temp for any files created via Perl 5. these files should be written to an appropriate temp directory for the platform, not to the root of the parrot source directory. ~jerry
Re: Parrot 0.7.0 Severe Macaw - permissions
On Tue, Aug 19, 2008 at 1:13 PM, Jesse Vincent [EMAIL PROTECTED] wrote: [List-CC changed] On Aug 19, 2008, at 4:10 PM, Reini Urban wrote: Bob Rogers schrieb: On behalf of the Parrot team, I'm proud to announce Parrot 0.7.0 Severe Macaw. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. There are several module permissions missing for rgrjr See http://search.cpan.org/~rgrjr/parrot-0.7.0/ so that http://search.cpan.org/dist/parrot still shows 0.6.4 Wasn't there a plan to add all the various Parrot:: classes to the 'noindex' list? Can the owner or someone from modules please add these: Parrot::Configure::Options::Test::Prepare Parrot::Harness::DefaultTests Parrot::Harness::Options Parrot::Harness::Smoke Parrot::Pmc2c::Attribute Parrot::Pmc2c::PMC::PrintTree Parrot::SearchOps Parrot::Test::Util::Runloop -- Reini Urban http://phpwiki.org/ http://murbreak.at/ i'd rather we don't index any perl modules in the distro. the no_index directive in META.yml should probably read something like: no_index: directory: - lib but that won't fix this release. ~jerry
Re: unified languages-test
On Mon, Aug 18, 2008 at 11:41 AM, Will Coleda [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 2:29 PM, Michael Peters [EMAIL PROTECTED] wrote: Will Coleda wrote: The eventual goal of this cleanup is to get these tests running via smolder to give core developers more feedback on their commits. The aborted test in this file can be TODOd if we can't fix the root cause before release. To this end, how would we like this to be done. I've been thinking about creating a separate project for Rakudo and then having it's full test suite, spec test and spec_test_regression all going as separate tags so they can be viewed separately. Rakudo would, at the moment, need its own version anyway, since you can't run rakudo via the unified harness. I could create a separate project for each built-in language (might be too many) or just have a misc-languages project. But it might be helpful to have each big language (Rakudo, pipp, cardinal) have their own projects so that they have their own RSS feeds. I am of two minds: - the tcl developer in me wants a feed for my language so I can easily track it. - the parrot developer wants an aggregated feed that shows all the languages so I can easily see if I broke something. Can we start with the fine-grained version and provide an aggregated version? We can decide on the aggregated version later, if necessary. (just languages? just some of them? all of them -and- core parrot?) yes, please. this is what rss aggregation is for. before parrot's general availability release, we will be moving many if not most of the languages out of the parrot repository. this will make languages-smolder (or a similar parrot make target) less relevant, and rss aggregation more important. anyone know of an aggregated feed generator, so one can build a personalized feed of feeds and subscribe to that? we can host it at parrot.org once we have that infrastructure set up. ~jerry
Re: unified languages-test
On Mon, Aug 18, 2008 at 11:51 AM, Will Coleda [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 2:50 PM, jerry gay [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 11:41 AM, Will Coleda [EMAIL PROTECTED] wrote: On Mon, Aug 18, 2008 at 2:29 PM, Michael Peters [EMAIL PROTECTED] wrote: Will Coleda wrote: The eventual goal of this cleanup is to get these tests running via smolder to give core developers more feedback on their commits. The aborted test in this file can be TODOd if we can't fix the root cause before release. To this end, how would we like this to be done. I've been thinking about creating a separate project for Rakudo and then having it's full test suite, spec test and spec_test_regression all going as separate tags so they can be viewed separately. Rakudo would, at the moment, need its own version anyway, since you can't run rakudo via the unified harness. I could create a separate project for each built-in language (might be too many) or just have a misc-languages project. But it might be helpful to have each big language (Rakudo, pipp, cardinal) have their own projects so that they have their own RSS feeds. I am of two minds: - the tcl developer in me wants a feed for my language so I can easily track it. - the parrot developer wants an aggregated feed that shows all the languages so I can easily see if I broke something. Can we start with the fine-grained version and provide an aggregated version? We can decide on the aggregated version later, if necessary. (just languages? just some of them? all of them -and- core parrot?) yes, please. this is what rss aggregation is for. before parrot's general availability release, we will be moving many if not most of the languages out of the parrot repository. this will make languages-smolder (or a similar parrot make target) less relevant, and rss aggregation more important. anyone know of an aggregated feed generator, so one can build a personalized feed of feeds and subscribe to that? we can host it at parrot.org once we have that infrastructure set up. ~jerry We are running one now: http://planet.parrotcode.org/ i don't think you caught my meaning. i want to give users the ability to create a feed of tcl's tests, rakudo's spectest_regression, and parrot's testj target from the gsoc_nci branch, and have that made available to them for subscription. as far as i'm aware, with planet.parrotcode, the administrator picks the feeds that are aggregated. ~jerry
Re: [perl #57942] [BUG] Smolder failure [linelength, compilers/pirc]
On Fri, Aug 15, 2008 at 9:39 AM, Bob Rogers [EMAIL PROTECTED] wrote: From: Geoffrey Broadwell [EMAIL PROTECTED] Date: Fri, 15 Aug 2008 09:07:46 -0700 . . . It seems then that we have two remaining options: 1. Don't run codingstd as part of smolder. 2. Differentiate a codingstd failure and a real failure in smolder. . . . Seems to me that codingstd should give the same result on all platforms. If so, it ought to be run separately, on a single designated platform. true only if platform-specific generated files are excluded from coding standards checking. i'm not certain (without looking) whether this is the case. ~jerry
Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak
On Sat, Aug 9, 2008 at 3:50 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
On Sat Aug 09 10:31:37 2008, [EMAIL PROTECTED] wrote:
On Saturday 09 August 2008 06:33:46 James Keenan via RT wrote:
What purpose remains, then, for either tools/dev/ops_renum.mak or
my
alternative, tools/dev/opsrenumber.pl? Is such a program only
intended
to provide a number for newly added opcodes?
Hm, I missed the question the first time. The program renumbers
opcodes when
adding or removing one or more opcodes. (Removing is less likely as
time
goes by, but we reserve the right to do so for the forseeable future.)
Hmm ... it appears to me that particle took a harder line earlier in
this RT against removal: in an attempt to keep bytecode compatible
across versions of parrot, opcodes can never be deleted.
Do we have a disagreement there? If not, I'd like to know whether my
replacement script DTRT or needs fixing ('cause I'm more confused than
when i started).
let me clarify: after 1.0, in order to allow bytecode to be work
across parrot releases (where there may be new or deprecated opcodes),
opcode numbers can never be reused. before parrot is production ready
(before 1.0) we have not made any promise of bytecode compatibility
across releases, other than that it'd be great if we can do it (which
means we can reuse opcode numbers if we want to, but i still find it
unlikely as it's counter-cultural.
i don't see any disagreement between myself and chromatic.
~jerry
Re: [perl #57636] [TODO][PDD19] Document the reason for :unique_reg flag
On Thu, Aug 7, 2008 at 5:44 AM, Jonathan Worthington [EMAIL PROTECTED] wrote: Klaas-Jan Stol wrote: I think basically the question remans; is there any way we could do without the :unique_reg? Yes: 1) Add the reference-taking op and register reference PMC to the Parrot core. 2) Make IMCC specially aware of this op so that it never re-uses this register. also, if i understand satisfy patrick's use case in pge, 3) add the ability to select the register allocator used, or disable it, within a sub. a programmer who knows what he's doing should have the ability to disable the register allocator and manage registers himself. the scope of the action must be limited to make the intent clear and to ease maintenance programming; it must occur at the sub level rather than at the file level. ~jerry
Re: Reason for attributes.t fail
On Thu, Aug 7, 2008 at 3:26 AM, Jonathan Worthington [EMAIL PROTECTED] wrote:
Hi,
Rakudo is currently failing t\spec\S12-class\attributes.t. This turns out
not to be an issue with attributes, but rather exceptions. The test does:
my $c = Counter.new();
try {
$c.x
}
ok($!, 'no public accessor for private attribute');
And fails because the Exception PMC does not implement the get_bool vtable
method (which I'm guessing must have changed when we merged pdd25cx). I'm
not sure what the best solution for this is...in the meantime, I have fudged
that test, so the rest of attributes.t passes again now.
seems to me this is trying to test whether there's a defined value in
$!. however, you've jumped straight into blaming parrot's Exception
PMC, without considering the expected perl 6 behavior. does Exception
inherit from Object, and if so, doesn't Object's .true method by
default return .defined? if so, then we should be wrapping Exception
PMCs in perl 6 objects, and the inherited .true method will make this
test work.
of course, this is purely conjecture based on my fuzzy recollections.
maybe someone with more confidence on this topic can speak to it?
~jerry
Re: time op inconsistent on Win32
On Thu, Aug 7, 2008 at 12:40 PM, Ron Blaschke [EMAIL PROTECTED] wrote: Jonathan Worthington wrote: Hi, I've just been looking at the time op, and what it returns is somewhat platform specific. * On Win32, it's the number of seconds since January 1, 1601 If I remember correctly, some parts of Windows use 100ns ticks since 1601 to represent time. Not sure if computers were in common use in the 17th century, though. * In other codepaths, it appears to be the number of seconds since January 1, 1970. I'm thinking we should correct the Win32 version to do the same as the others for consistency? Or should we keep these platform specific and make code that cares check what OS we are on and work it out (don't like this option so much, since we're meant to be abstracting the OS away...) Opinions? +1 for using seconds since 1970. I can adjust this if you guys agree. we definitely need date/time pmc(s?) not only to have a common epoch across platforms, but to deal with 2038. in particular, we should leverage schwern's work on perl to address the 2038 bug. ~jerry
Re: Branching
On Tue, Aug 5, 2008 at 1:47 PM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote: We also need to think about deprecation cycles. If you deprecate a feature in 1 version and then it disappears in the next then the time between when my code works and when it doesn't is only 6 months. Some distros provide support for several years. Which reminds me: chromatic, what was your reasoning for major releases being every three months, instead of four or six? I agree we don't want to go much beyond six months for our major releases, but with at least two major distros that aim for decent freshness (Ubuntu and Fedora) using six month release cycles, I'm curious what we gain with a shorter cycle than that. A six month release cycle makes deprecation-and-removal a one year affair, which isn't too bad. And we can fairly tell users who want more stability than that to use the slow distro that matches each fast distro we aim for -- Debian instead of Ubuntu, RHEL/CentOS instead of Fedora, for example. (Separately, I agree that one month point releases seem to work well for us. I don't see any reason to change that.) please start a new thread as this has moved off-topic. ~jerry
Re: [perl #56716] [TODO]: speed up the configure tests
On Wed, Jul 30, 2008 at 4:25 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
On Tue Jul 29 11:01:12 2008, particle wrote:
the failing test:
t/steps/auto_ctags-01ok 1/31
# Failed test 'Got expected result'
# at t/steps/auto_ctags-01.t line 65.
t/steps/auto_ctags-01NOK 17/31# got:
'yes'
# expected: 'no'
# Looks like you failed 1 test of 31.
t/steps/auto_ctags-01dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 17
Failed 1/31 tests, 96.77% okay
the source looks like:
is($step-result(), q{no}, Got expected result);
I modified the test in r29891. Could you svn up and reconfigure and let
me know your results on Win32?
i got three unexpectedly succeeding tests in t/steps/auto_ctags-01.t (16-18).
i removed the TODO block in r29901.
~jerry
Re: [perl #56716] [TODO]: speed up the configure tests
On Tue, Jul 29, 2008 at 4:28 AM, James Keenan via RT
[EMAIL PROTECTED] wrote:
I have prepared a patch which represents an 'svn diff' between trunk and
the 'parallel' branch at the point of the branch's inception. Rather
than swamp your inboxes, I'm posting it here:
http://thenceforward.net/parrot/diff.trunk.parallel.txt
This patch is more for review than application. Because the number of
t/steps/*.t test files has been reduced from 227 to 74, there's been a
tremendous amount of text movement. So it's not surprising that when I
do the 'svn merge', I'll have plenty of conflicts to resolve. And I
doubt that 'patch' will apply the patch cleanly.
For those of you who are interested in benchmarking the difference, I
recommend you do a checkout of the parallel branch and run 'perl
Configure.pl --test=configure', as I've included a line reporting the
elapsed time. Then do a fresh checkout from trunk, copy the version of
lib/Parrot/Configure/Options/Test.pm found in 'parallel' into trunk and
running Configure.pl there in the same way. Since, as I said in a
previous post, there is considerable variance in the time Configure.pl
takes, you should probably configure in each branch 3 times to get a
good idea of any speed improvements.
i haven't reviewed the patch, but i have run the tests. here's the
results from both branches, synchronized to r29844.
trunk:
All tests successful, 16 tests skipped.
Files=287, Tests=3946, 145 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
All tests successful, 16 tests skipped.
Files=287, Tests=3946, 140 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
All tests successful, 16 tests skipped.
Files=287, Tests=3946, 142 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
c:\usr\local\parrot\trunkack -af t\configure t\steps | wc -l
301
branches/parallel:
Files=133, Tests=3332, 76 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Failed 1/133 test programs. 1/3332 subtests failed.
Files=133, Tests=3332, 76 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Failed 1/133 test programs. 1/3332 subtests failed.
Files=133, Tests=3332, 75 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU)
Failed 1/133 test programs. 1/3332 subtests failed.
c:\usr\local\parrot\parallelack -af t\configure t\steps | wc -l
147
the failing test:
t/steps/auto_ctags-01ok 1/31
# Failed test 'Got expected result'
# at t/steps/auto_ctags-01.t line 65.
t/steps/auto_ctags-01NOK 17/31# got: 'yes'
# expected: 'no'
# Looks like you failed 1 test of 31.
t/steps/auto_ctags-01dubious
Test returned status 1 (wstat 256, 0x100)
DIED. FAILED test 17
Failed 1/31 tests, 96.77% okay
the source looks like:
is($step-result(), q{no}, Got expected result);
this test assumes i don't have ctags installed, but i do. of course,
configure knows better than any tester, so it's better to test that
the 'result' method returns one of the allowed values, and doesn't
assume one or the other. something like:
like($step-result(), qr/(yes|no)/, Got allowed value from
'result' method);
i expect there may be similar tests of -result() that need
modification, though i haven't verified that.
overall, i'm impressed at the 50% speedup. given that these are
relatively fast tests, it makes sense that since there are half as
many files (and therefore half as many invocations of perl), the tests
take half the time to run. other than my concern about the testing
strategy that led to my failing test, i think it's ready for trunk.
it seems that only files in t/steps/ have been refactored, and that
t/configure/ has been left alone. is that correct, and if so, can it
be similarly refactored? another 50% speedup would put these tests in
the 30-40s range, which is much nicer than the 2+ minutes it takes in
trunk today.
~jerry
Re: [perl #57358] Enable parallel testing
On Mon, Jul 28, 2008 at 10:27 AM, Eric Wilhelm [EMAIL PROTECTED] wrote: # from Moritz Lenz # on Monday 28 July 2008 09:52: That's not -just- with the patch, though, is it? I presume you've set TEST_JOBS to be something other than '1' ... I've set it to 2, and obeserve the errors below. With serial testing I get a PASS (r29828). Yes. TEST_JOBS=1 doesn't change anything. It looks like most of the tests in t/steps might potentially conflict. To smoke out the resource conflicts in the test suite, one would have to run $n jobs -- but that will forkbomb your system. Another check is to run each against each other with `prove -j 2 $test_n $test_i` Tests need to be written defensively for arbitrary parallelization to be possible. If that's too much coding, the non-optimal serial within a directory scheme (or other forms of work division) would have to be used. i encourage you to try this out in the 'parallel' branch of the repository. it's not synchronized with the latest changes to trunk, but you can do that locally (for a refresher, read docs/project/committer_guide.pod). work has been done to consolidate the test files in that branch, and although they may not address all the requirements for parallel testing to succeed, that is a related goal and seems like a good place to achieve them. ~jerry
Re: [perl #57344] [TODO] Change runtime/parrot/* to runtime/*
On Sun, Jul 27, 2008 at 1:56 PM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Sun, Jul 27, 2008 at 10:08:06AM -0700, Geoffrey Broadwell wrote: In the source repository, the 'parrot' in runtime/parrot/foo is pointless. It's a singleton directory, and it's redundant. I think that the point of runtime/parrot/ is that we may also someday have runtime/perl6/, runtime/pynie/, runtime/cardinal/, etc. directories, which will be the canonical location for language-specific runtime libraries. yes, that was the point at the time it was introduced. however, it confuses the source tree with the install tree, and goes against a parrot policy. in the source tree (a.k.a. your working copy), we've set up the infrastructure for runtime/ to contain multiple language-level subdirs for runtime components (library, include, pmc, etc.) the intent is precisely as you suggest above. however, the project team has set a clear policy which states that in the source tree, languages must be self-contained. this policy is in place so it will be easy to transition any language from the parrot repository to an external repository. we still have some work to do to make this policy both true and easy for hll developers to implement, which will happen before parrot 1.0. following the policy, the intent is that each language in the source tree have its own runtime directory under the language root directory (e.g. languages/perl6/runtime/). if it is determined that installations of the parrot vm and parrot hlls will use a common prefix for a runtime root directory (e.g. /usr/lib/parrot/runtime/), then runtime components for both the vm and hlls may be installed to that shared location. that's an install tree policy, and as far as i'm concerned, it hasn't been addressed yet (along with many other install-related policies.) ~jerry
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Thu, Jul 17, 2008 at 7:44 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: On Thu Jul 17 15:53:12 2008, julianalbo wrote: On Thu, Jul 17, 2008 at 9:59 PM, Christoph Otto via RT [EMAIL PROTECTED] wrote: With this patch, the new tests still pass on Linux/x86. The patch uses STRING-strstart to avoid leaking a malloc'd buffer when throwing an exception, which may or may not be considered kosher in this situation. Can't you use real_exception(interp, NULL, E_SystemError, %Ss, errmsg_pstring); ? Using internal details of parrot strings must be avoided. I agree. I just didn't know real_exception was smart enough to do that trick. The attached patch (v5) properly fixes the problem on my system. There shouldn't be any remaining issues, but the patch ought to be tested on a another *nix and Windows. iirc we shouldn't be assuming interp in macros (it should always be passed). i could be wrong, so i've copied the man with the feathered broom for an official ruling. ~jerry
Re: .parrot_current_rev
On Tue, Jul 15, 2008 at 6:52 AM, Reini Urban [EMAIL PROTECTED] wrote: The file .parrot_current_rev is missing in the Release, and also the revision is nowhere mentioned in any Release Note, not the ChangeLog and not in news. This is annoying, because you don't know if a particular bugfix is included or not. Worse, the logic the set the current revision for svn updates is wrong. (NotMuch brought this up yesterday on #parrot) .parrot_current_rev is not updated on a svn up, it is just the cache for $Parrot::Revision::current, but the cache is not ensured to be cleared when doing a Configure.pl. Only a make realclean will get you a correct revision in bugreports. Configure should enforce a fresh cache update if there's a .svn subdir available, otherwise you'll get false bugreports. -- .parrot_current_rev should be (re)generated every time Configure.pl is successfully run. if this is not the current behavior, it's broken. ~jerry
Re: CPAN-Permissions for Perl 5 Modules
i seem to recall that we agreed instead to noindex the Parrot:: modules... Nobody is expected to use them outside parrot anyway. On 7/15/08, chromatic [EMAIL PROTECTED] wrote: On Tuesday 15 July 2008 17:23:20 James E Keenan wrote: Bernhard Schmalhofer wrote: for Parrot 0.6.4 following Perl 5 modules were not indexed: Parrot::Configure::Options::Test::Prepare Parrot::Pmc2c::PMC::PrintTree Barney: I know that I wrote the two modules above (or, at least, refactored them into their current form). What, if anything, should I have done when I wrote/committed them. It's only a CPAN indexing issue. Whenever a release manager uploads a new bundle, he or she needs to change permissions for all new indexed modules to allow the PARROTRE group to upload new versions. Unless/until you're a release manager yourself, you can safely ignore this. (The implication is that Bernhard should go into PAUSE right now and check that he's not listed as the primary first-come, first-served maintainer for any Parrot modules.) -- c -- Sent from Gmail for mobile | mobile.google.com
Re: [svn:parrot] r28816 - trunk/languages/perl6/tools
On Wed, Jul 2, 2008 at 11:06 PM, chromatic [EMAIL PROTECTED] wrote: $ parrot perl6.pbc --output=buggy.pir --trace=PIR buggy.p6 s/trace/target/
Re: [perl #53976] [PATCH] Remove tools/dev/ops_renum.mak
On Wed, Jul 2, 2008 at 4:03 AM, James Keenan via RT [EMAIL PROTECTED] wrote: Second, two notes about the branch: In a fresh checkout, if I 'make renumberops' with no local modifications, src/ops/ops.num changes. If I rename the op store_lex to barf_lex, and run 'make renumberops', the opcode barf_lex doesn't show up in src/ops/ops.num. (But, store_lex vanishes) I have found the code which causes (at least the) 2nd problem Coke describes and know how to fix it. See the opsrenum branch. But whether my fix is correct or not depends on two questions: (1) Is the following passage from the inline comments in src/ops/ops.num still valid? # once an opcode is added to this file it should never be # removed. Opcodes that are in here but that have no corresponding # function backing them (because, for example, they've been deleted, # which shouldn't ever happen once we hit production) should be mapped # by the ops processing programs to an exception op If it *is* valid, then any renaming of an opcode should leave that op's *current* name and number in number.ops unchanged. The *new* name for the opcode should presumably be pushed on to the end of the list. But this runs counter to the generally programming principle that we should get rid of old, unused code. Why is this case different? Which leads to the next question: (2) Why do we maintain number.ops as a *static file of source code at all*? Why is it in the repository? If a given Parrot developer, for a given instance of Parrot configuration and build, renumbers the opcodes (either because the list of opcodes has changed or just for the hell of it), why must that renumbering be inflicted on all other Parrot developers -- which it would be as the result of 'svn ci'? Thank you very much. kid51 opcodes are the very heart of bytecode. if the opcodes change, then the bytecode is invalid. if opcode #1 (noop) was changed to something like (delete_harddisk), and parrot is rebuilt, than any existing bytecode (.pbc file) that contains a noop instruction will instead perform delete_harddisk. that's *never* the right thing to do--it means bytecode can never be shared reliably across parrot builds. portable bytecode is one of the main goals of parrot. therefore, in an attempt to keep bytecode compatible across versions of parrot, opcodes can never be deleted. instead, if opcodes are deprecated, their function bodies should throw an exception explaining that the opcode is no longer supported. like the comment says, this will be strictly enforced after parrot 1.0, but is a good rule to follow now as well. the design team reserves the right to make architectural changes that impact the opcode numbers, of course, until we have a production-ready product. ~jerry
Re: [perl #56310] [Patch] unset $(PERLDOC) breaks building on OS X
On Tue, Jun 24, 2008 at 7:15 PM, via RT Seneca Cunningham [EMAIL PROTECTED] wrote: # New Ticket Created by Seneca Cunningham # Please include the string: [perl #56310] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=56310 The switch to using $(PERLDOC) in docs/Makefile without defining PERLDOC anywhere breaks my build. The attached patch resolves this by adding the definition of PERLDOC to config/gen/makefiles/docs.in. End of run with broken Makefile: herodotus:build-20080624 seneca$ make -j2 [...] make -C docs perl -MExtUtils::Command -e mkpath ops perldoc -ud packfile-c.pod ../src/packfile.c Perldoc (Pod::Perldoc::ToPod) output saved to packfile-c.pod ud ops/bit.pod ../src/ops/bit.ops make[1]: ud: Command not found make[1]: [ops/bit.pod] Error 127 (ignored) perl -MExtUtils::Command -e ExtUtils::Command::chmod 0644 ops/bit.pod Cannot chmod 0644 ops/bit.pod:No such file or directory at /System/Library/Perl/5.8.8/ExtUtils/Command.pm line 241. make[1]: *** [ops/bit.pod] Error 2 make: *** [docs.dummy] Error 2 make: *** Waiting for unfinished jobs jit2c: JITed 144 (+ 141 vtable) of 1243 ops herodotus:build-20080624 seneca$ -- Seneca Cunningham [EMAIL PROTECTED] Index: config/gen/makefiles/docs.in === --- config/gen/makefiles/docs.in(revision 28692) +++ config/gen/makefiles/docs.in(working copy) @@ -6,6 +6,7 @@ RM_F = @rm_f@ MKPATH = @mkpath@ CHMOD = @chmod@ +PERLDOC = @perldoc@ # long list of .pod files POD = @pod@ thanks, applied as r28693. ~jerry
Re: [perl #43857] [TODO] Refactor config probes that are used only by language implementation
On Sun, Jun 22, 2008 at 3:38 AM, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: James Keenan via RT schrieb: On Fri Jul 13 09:58:33 2007, bernhard wrote: There are several config probes that are only used for language implementations. Examples are config/auto/m4.pm and config/auto/python.pm. Please find attached two files. The first greps the repository for mentions of 'm4'. The second is a patch which eliminates config/auto/m4.pm and the associated test file and updates the MANIFEST. Configure.pl, make and make test all perform without error after this config step is eliminated. When I switch into languages/m4, then call 'make' and 'make test', I get the same test failures in t/regex/002_tokens.t either way. So my belief is that removing this step causes no harm to the m4 language implementation itself. I will apply this patch to trunk in about 2 days if there is no objection. Thank you very much. kid51 AFAIK 'languages/m4/config/makefiles/root.in' is the only place where the config entry 'has_gnu_m4' is used. It is meant as a doublecheck of the 'm4' tests. If 'GNU m4' is available then the m4 tests should be run with 'GNU m4' as well. This should make sure that the Parrot implementation behaves the same way as the reference implementation. So 'has_gnu_m4' is not essential to the implementation of 'Parrot m4'. In r28633 I removed the use of 'has_gnu_m4' and the config step auto::m4.pm can now be removed. But the real scope of ticket RT#43857 is something different. Language implementations may need config probes that are only relevant for that particular language. Therefore there should be some kind of infrastructure set up, so that those probes can be placed within the language dir. Taking 'Plumhead' as an example, I would have liked to set up probes checking for 'phc', 'antlr' and 'xsltproc'. I didn't do so because I didn't want to clutter the Parrot config. languages/dotnet/ has its own configure.pl, and m4, plumhead, etc. should follow that model. if there are things that can be done to make the process of developing a language-specific configure engine easier, i'd love to hear them. ~jerry
Re: [perl #56020] [OK]: Report on Parrot Build Fest at YAPC
On Thu, Jun 19, 2008 at 9:34 AM, Ovid [EMAIL PROTECTED] wrote: --- Packy Anderson [EMAIL PROTECTED] wrote: On Jun 18, 2008, at 11:51 AM, Parrot via RT wrote: Successful parrot build on ancient Debian/i386 system, most of the way through make test (it's taking _forever_, mostly because this is a PII 266 system) $ uname -a Linux daffy 2.2.19pre17 #1 Tue Mar 13 22:37:59 EST 2001 i686 unknown ... and make test finished: All tests successful (1 subtest UNEXPECTEDLY SUCCEEDED), 30 tests and 595 subtests skipped. Files=585, Tests=11192, 2674 wallclock secs (2176.58 cusr + 203.55 csys = 2380.13 CPU) This looks like you're using an older version of Test::Harness. If you upgrade, it will break things down further, including telling you which test in which test program unexpectedly succeeded. thanks for pointing that out. we're in the process of requiring TH3, so we can get smolder working with parrot. the default test summary report is harder for us to use in development (since it contains multiple lines per file, it's not easy to highlight the filenames in the terminal and get them to open in an editor for examination), but we'll work with it until we find or create something better. the benefits of better todo/skip/failure reporting and working with smolder outweigh the rest. ~jerry
Re: Parrot and Smolder
On Tue, Jun 17, 2008 at 10:31 AM, Michael Peters [EMAIL PROTECTED] wrote:
I've got this working pretty well on my checkout (except that the current
revision, #28476, doesn't build). You can do a make smolder_test and have
the
results sent to the Smolder server. I talked with chromatic and some others
about removing some of the old existing smoke stuff, but I'll do that later.
So now the question is how do I send this as a patch. It touches several files
and adds new ones. Is a simple svn diff good enough? If so, it's attached.
excellent! this came together quickly and simply, by the looks of it.
the patch format is fine, especially for a first patch (for more
details of our precise requirements you can read
docs/submissions.pod). one gotcha, you've got 'use Config;' which
pulls info from perl, when you should be using Parrot::Config instead.
it should be an easy switch from $Config{myarchname} to
$PConfig{archname}, if i understand correctly.
as far as i'm concerned, with that simple change this patch can be
applied--and anyone familiar with perl can make that change, it
doesn't have to be michael.
~jerry
Re: [perl #52776] [PATCH] Allow @foo@ syntax when setting config data.
On Sat, Jun 7, 2008 at 3:26 AM, Bernhard Schmalhofer [EMAIL PROTECTED] wrote: On Fri, Jun 06, 2008 at 11:17:33PM -0700, Will Coleda via RT wrote: Let's borrow the syntax from the makefile generation itself, and just have RM_F's definition be: +rm_f = '@perl@ -MExtUtils::Command -e rm_f', [...] Sound good to me. Additionally (though it won't help the original problem, it will help remove a ton of boilerplate), we can also eliminate all the RM_F = @rm_f@ boilerplate in the makefiles, and simply use @rm_f@ where we now use $(RM_F) Actually I don't mind having things like RM_F = /home/coke/bin/perl -MExtUtils::Command -e rm_f defined on top of Makefiles. It is standard Makfile syntax. When editing the generated Makefile, for testing and development, it easier to change the global definition of a variable than to change all ocurrances. agreed. so how about we generate a makefile that is full of all the macros we need RM_F, PERL, CP, etc, and include it in all makefiles as they're generated? ~jerry
Re: [perl #55304] [PATCH] eval_(dies|lives)_ok methods for rakudo's Test.pm, and more tests
On Fri, Jun 6, 2008 at 7:34 PM, Vasily Chekalkin [EMAIL PROTECTED] wrote: jerry gay wrote: On Wed, Jun 4, 2008 at 2:46 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Oops, forgot to attach patch. Now it's really there. thanks, applied as of r28074. ~jerry This is wrong patch. eval() shouldn't throws any exceptions. Correct patch for 'eval()' and Test.pm attached. would you reformat this in universal diff format please? my patch program doesn't speak git. ~jerry
Re: [perl #55332] [BUG] can't build parrot on win32 + strawberry perl
On Thu, Jun 5, 2008 at 3:16 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: somehow a fresh checkout has resolved the problem (but my other sandbox was still up to date according to svn status...) anyhow, this ticket can be rejected. kjs i had this same problem, and it was resolved the same way, for win32+msvc. dunno if it's a missing make dep or svn foolishness or what, but it distracted me from parrot work for hours. ~jerry
Re: [perl #55304] [PATCH] eval_(dies|lives)_ok methods for rakudo's Test.pm, and more tests
On Wed, Jun 4, 2008 at 2:46 PM, Moritz Lenz [EMAIL PROTECTED] wrote: Oops, forgot to attach patch. Now it's really there. thanks, applied as of r28074. ~jerry
[CAGE] STICKY_FILES is a poor name
in parrot's main makefile (config/gen/makefiles/root.in) there's a variable named STICKY_FILES that collects all the files that should be removed during 'make realclean'. it's an awful name. something more descriptive, like CONFIGURE_GENERATED_FILES or similar would be better. a general going-over of the variable names in the makefile template might be nice, but that may be another ticket. ~jerry
Re: Create a sub of a particular type
On Fri, May 16, 2008 at 5:31 PM, Bob Rogers [EMAIL PROTECTED] wrote: From: Jonathan Worthington [EMAIL PROTECTED] Date: Sat, 17 May 2008 01:38:46 +0200 Bob Rogers wrote: It is a good idea. I think I would call it :class, though. I did ponder that, and then worried that people would confuse it with putting a method into a certain class, which isn't what this is for... Jonathan Good point. And :sub_class or :sub_type would probably be even more confusing. And :invokable_class is probably too verbose (and probably also too general). :use_class? From: Will Coleda [EMAIL PROTECTED] Date: Fri, 16 May 2008 20:20:32 -0400 It could be a pmc instead of a class. How about :type ? Perhaps we want to save that for declaring return types? But, considering Jonathan's point, :type is probably better for this after all. is this limited to subclasses of Sub? if not, perhaps :pmctype is more descriptive. if so... :invokeable_type? :type seems too easy to get confused about. anyway, good idea, jonathan! ~jerry
Re: New Committer: Andrew Whitworth
On Fri, May 9, 2008 at 6:03 AM, Will Coleda [EMAIL PROTECTED] wrote: After some administrative snafus, we've finally gotten Andrew's commit bit assigned! I have assigned him several tickets in RT as penance. ^_^ wonderful! as a point of introduction, andrew has provided a number of quality patches in the recent months over a number of subsystems and hlls, and has been accepted by Google Summer of Code to create the garbage collector specified in PDD09. welcome, and good luck on your project! ~jerry
Re: [perl #53916] [PATCH] Rewrite of docs/book/Chapter1
On Fri, May 9, 2008 at 10:27 AM, chromatic [EMAIL PROTECTED] wrote: - I'm not sure how accurate or useful the discussion of formal roles is. For example, we seem to be doing fine without a pumpking, and this is the only place I've ever heard the term platform porter for the canonical list of parrot roles and responsibilities, see docs/project/roles_responsibilities.pod. you'll find platform porter listed there. listed as well is pumpking, which should be removed. i suggest the chapter text and the text in that file should be kept very close in line, if not identical. ~jerry
Re: [perl #53270] [TODO] Rename/refactor _handle_mswin32()
On Fri, Apr 25, 2008 at 8:38 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote: (Subtle note -- the || really wants to be //, but as I recall we're not allowed to assume that // is there yet.) correct, parrot depends on perl 5.8, so we can't rely on //. so i strongly suggest you use the idiomatic (however verbose) perl5 equivalent: defined $foo ? $foo : $default correctness++ ~jerry
Re: [perl #53344] [PATCH] Misplaced brace in src/gc/dod.c
On Fri, Apr 25, 2008 at 9:12 AM, via RT Andy Dougherty [EMAIL PROTECTED] wrote: # New Ticket Created by Andy Dougherty # Please include the string: [perl #53344] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=53344 I tripped over this while working on a stacks patch. It prevents compilation without debugging. --- parrot-svn/src/gc/dod.c Fri Apr 25 07:55:47 2008 +++ parrot-andy/src/gc/dod.cFri Apr 25 09:29:55 2008 @@ -218,8 +218,8 @@ else if (p-pmc_ext PMC_metadata(p)) fprintf(stderr, GC: error obj %p (%s) has properties\n, (void *)p, (char*)p-vtable-whoami-strstart); -} # endif +} # if GC_VERBOSE /* buffer GC_DEBUG stuff */ if (GC_DEBUG(interp) PObj_report_TEST(obj)) thanks, i've already fixed it in trunk, since i ran into it as well. ~jerry
Re: Notes on removing stack.ops, further steps
On Tue, Apr 22, 2008 at 5:46 AM, Will Coleda [EMAIL PROTECTED] wrote: On Tue, Apr 22, 2008 at 2:52 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: Tonight I resolved RT#52838 and RT#52840, eliminating the saveall/restoreall opcodes, the register stack, and fixing up tests and other items to avoid save/restore/etc. opcodes. I've also created a userstack branch where I've got the details for removing the rest of stack.ops . I've already implemented and tested it (it's pretty straightforward), but since DEPRECATED.pod says that these opcodes are to be removed post 0.7.0 it's too early to commit these changes to trunk. One of the interesting features of removing stack.ops is that we no longer need the STACK_ENTRY_INT, STACK_ENTRY_FLOAT, or STACK_ENTRY_STRING types in src/stacks.c, as those were being used only by the save/restore opcodes. Should we see about removing these entry types from the code, or should we leave them there in case we come up with a need for them in the future? I'd remove them. There's always subversion if we need to get them back later. +1 Thanks for the cleanup work! +1 ~jerry
Re: mod_parrot uses string_nprintf
On Tue, Apr 22, 2008 at 6:55 AM, Donald Hunter [EMAIL PROTECTED] wrote: Hi, I'm trying to build mod_parrot against Parrot 0.6.1 and have found that string_nprintf no longer exists. I see from ticket #44053 that the function was removed since it had no users. What's the preferred solution? Re-introduce string_nprintf or modify mod_parrot to use another method? submit a patch against mod_parrot to update it to use what's currently in parrot. there is certainly one or more parrot functions that can be used to replace the functionality of string_nprintf. i'm not sure jeff has a list for patch submissions, but if you submit it to this list, either he or i will review and apply it. that is, if it's not fixed before you get your patch submitted. however, if you want to contribute, we'll certainly wait to see what you can come up with. ~jerry
working out kinks in the parrot release process
one consistent trouble spot in the parrot release process is the CPAN upload process. often times, we have trouble with perl modules that have been added, deleted, or renamed causing the release to be marked as 'unauthorized'. dealing with unauthorized releases involves intervention from a pause admin. the reason we run into trouble at all is because we're indexing modules in the parrot repo. with the exception of a few (Parrot::Embed comes to mind), i don't see a need to index any of the modules. they're all parrot-specific, and we don't use CPAN's bug tracker or rating systems to maintain those modules. therefore, i'd like to make parrot 0.6.1 the last release that's ever listed as unauthorized due to module ownership problems. let's update the metadata to refrain from indexing modules under the Parrot:: namespace, except where it makes sense. also, i'd like to automate more of the release process. currently, we have a period of time where the link on the website for the most recent parrot will point to the previous release of parrot, until the new distro propagates to the cpan mirrors. in order to overcome this problem, and to automate one more release step, i propose the following: write a piece of code that watches http://svn.perl.org/parrot/tags/ for a new tag that matches /RELEASE_.*/, and when that occurs, run 'make release VERSION=`cat version`', and updates a link on the website to point to that tarball. we can then use that tarball to do a final test, and upload it to cpan. comments welcome. ~jerry
Re: working out kinks in the parrot release process
On Wed, Apr 16, 2008 at 1:49 PM, Mark Glines [EMAIL PROTECTED] wrote: On Wed, 16 Apr 2008 13:45:22 -0700 jerry gay [EMAIL PROTECTED] wrote: also, i'd like to automate more of the release process. currently, we have a period of time where the link on the website for the most recent parrot will point to the previous release of parrot, until the new distro propagates to the cpan mirrors. in order to overcome this problem, and to automate one more release step, i propose the following: write a piece of code that watches http://svn.perl.org/parrot/tags/ for a new tag that matches /RELEASE_.*/, and when that occurs, run 'make release VERSION=`cat version`', and updates a link on the website to point to that tarball. we can then use that tarball to do a final test, and upload it to cpan. comments welcome. Does this mean dalek needs a CPAN account now? no, no. the cpan upload would still be manual, but we'd use the url from parrotcode.org for the tarball, rather than uploading from our local machine. ~jerry
Re: [perl #52894] config detection perldoc failing due to write permissions
On Mon, Apr 14, 2008 at 1:25 PM, via RT Andy_Bach @ wiwb. uscourts. gov [EMAIL PROTECTED] wrote: # New Ticket Created by [EMAIL PROTECTED] # Please include the string: [perl #52894] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52894 config/auto/perldoc.pm uses a hardcoded, local path for a temp file to output perldoc -d to write to. perldoc also seems to use suid. So, if that file or the local fs is not writeable, the test fails even if perldoc is available. By changing the path to use /tmp, at least, the test will succeed. On *nix. Hmm Okay, I guess I need to find the OS agnostic version of this. yes please. File::Temp is used throughout parrot, so there's plenty examples to copy from. ~jerry
Parrot 0.6.1 Bird of Paradise Released
Aloha! On behalf of the Parrot team, I'm proud to announce Parrot 0.6.1 Bird of Paradise. Parrot (http://parrotcode.org/) is a virtual machine aimed at running all dynamic languages. Parrot 0.6.1 can be obtained via CPAN (soon), or follow the download instructions at http://parrotcode.org/source.html. For those who would like to develop on Parrot, or help develop Parrot itself, we recommend using Subversion or SVK on the source code repository to get the latest and best Parrot code. Parrot 0.6.1 News: - Specification + drafted pdd29_compiler_tools.pod + updated pdd28_character_sets.pod draft + updated pdd19_pir.pod draft - Languages + c99: added independent C pre-processor + HQ9+: reimplemented with PCT + Lua: . reimplementation with PCT, using PAST and POST . behavior aligned wih 5.1.3 + Rakudo: . implemented basic I/O, including '$*IN', '$*OUT', '$*ERR', 'prefix:=' . implemented simple typing and runtime type checking . added basic multi-method dispatch . expanded named argument handling, including Pair and colonpairs . added 'Whatever' and 'Capture' classes . implemented 'handles' trait verb . added 'loop' statement . implemented 'given', 'when', 'for', 'while', 'until' statement modifiers . implemented Hash methods '.keys' and '.values' . fixed bug to get '.WHAT' working correctly . initial implementation of 'eval' - Compilers + NQP: . created a bootstrapped build, see 'make boot' . added 'infix:', 'infix:=', 'infix:', 'infix:=' relational operators . added 'postfix:++', 'postfix:--' operators + PCT: . added methods specifying default behaviors in PAST, reducing repeated code . improved symbol table lookup + PGE: . removed deprecated code including: P6Regex, P6Grammar, PAST-pm - Miscellaneous + notable speedups during compilation and execution of parrot and HLLs + pdb (the parrot debugger) can now catch parrot exceptions + better detection of glibc and gettext during configuration + various bugfixes, code cleanups, deprecations, and coding standard fixes Mahalo to all our contributors for making this possible, and our sponsors for supporting this project. Enjoy! ~jerry
Re: macro PIR needs
On Mon, Apr 14, 2008 at 5:03 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: IMCC's macro processor doesn't currently allow for uniquely generated variable names. It's in the pdd (19), but not yet implemented. You're right in that it only works for labels. kjs On Mon, Apr 14, 2008 at 1:32 PM, François Perrad [EMAIL PROTECTED] wrote: In Lua libraries, I wrote many time the same piece of code. The purpose of this code is to register each function. So, I try to write the following PIR macro : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm also note that .Sub is deprecated, and should be replaced by 'Sub' ~jerry
release prep: NEWS, CREDITS and PLATFORMS updates welcome
as of r26974, i've updated the NEWS file for the release. it's been a busy month, especially for languages. i've updated information on the languages with which i'm most familiar, but your input is most welcome. also, could somebody peruse the svn log since the last release (r26484) and add update CREDITS? we've had a few new contributors, and i want to make sure they are not forgotten. ~jerry
Re: macro PIR needs
On Mon, Apr 14, 2008 at 10:21 AM, Will Coleda [EMAIL PROTECTED] wrote: On Mon, Apr 14, 2008 at 12:54 PM, François Perrad [EMAIL PROTECTED] wrote: Original Message Subject: Re: macro PIR needs Date: Mon, 14 Apr 2008 18:03:44 +0200 From: François Perrad [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: jerry gay [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] jerry gay wrote: On Mon, Apr 14, 2008 at 5:03 AM, Klaas-Jan Stol [EMAIL PROTECTED] wrote: IMCC's macro processor doesn't currently allow for uniquely generated variable names. It's in the pdd (19), but not yet implemented. You're right in that it only works for labels. kjs On Mon, Apr 14, 2008 at 1:32 PM, François Perrad [EMAIL PROTECTED] wrote: In Lua libraries, I wrote many time the same piece of code. The purpose of this code is to register each function. So, I try to write the following PIR macro : .macro register(tname, fname) .const .Sub $fname = .fname $fname.'setfenv'(_lua__GLOBAL) set $P1, .fname .tname[$P1] = $fname .endm also note that .Sub is deprecated, and should be replaced by 'Sub' ~jerry Perhaps in the future, but currently, NO. The syntax new $P0, 'Sub' is OK. But with .const, the only is way .const .Sub funct = 'funct' François. This currently only works in the type_ids branch. When I merge trunk to branch (trying to do so weekly or so), I've been updating this syntax so that when we merge back, hopefully it'll be painless. -- Will Coke Coleda my apologies. it'll be fully deprecated in a few days, i expect. ~jerry
Re: [perl #52838] [CORE] Remove the saveall and restoreall ops
On Sun, Apr 13, 2008 at 7:36 PM, chromatic [EMAIL PROTECTED] wrote: On Sunday 13 April 2008 19:30:50 Bob Rogers wrote: From: James Keenan via RT [EMAIL PROTECTED] Date: Sun, 13 Apr 2008 19:13:01 -0700 But here is a patch which partially implements the objective of this RT. Excellent; thank you. Did you want to apply it, or shall I? What's missing is a revision of docs/pdds/draft/pdd19_pir.pod. 'saveall' and 'restoreall' are used within a code example in this doc, and I don't know what should go in their places. This is in the section called Stack calling conventions, which this ticket together with #52842 will make obsolete. So, unless there are screams of protest, the whole section should be deleted. Still to be addressed is this portion of the OP: When these are gone, the instructions can be removed from src/ops/stack.ops, and the reg_stack member of struct Parrot_Context can be removed. I will be happy to do this (if nobody with more tuits gets there first). I move to hold these patches until after the release on Tuesday. Is that soon enough for everyone? +1 ~jerry
Re: [perl #52776] [configure][BUG] $(RM_F) uses $(PERL)
On Fri, Apr 11, 2008 at 12:15 PM, via RT Bernhard Schmalhofer [EMAIL PROTECTED] wrote: # New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #52776] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52776 In the Makefile templates the line RM_F = @rm_f@ is frequently used. This usually expands to RM_F = $(PERL) -MExtUtils::Command -e rm_f This utterly fails when $(PERL) isn't set up. So a saner expansion of $(RM_F) and friends is neede. every parrot makefile depends on perl being available on the system. we should make sure every makefile template matches /[EMAIL PROTECTED]@$/ ~jerry
Re: [perl #52788] gettext not being detected
thanks for the reports. i needed some feedback on this step in order to make it more portable. in order to do this correctly, i needed to determine if GNU libc is installed. from the gettext overview (http://www.gnu.org/software/gettext/manual/gettext.html#Overview): Note that on GNU systems, you don't need to link with libintl because the gettext library functions are already contained in GNU libc. since other config steps, like auto::backtrace, also want to know if GNU libc is available, i created a new config step: auto::glibc. i then modified the auto::gettext link command based on the information returned from auto::glibc. note that i have not modified auto::backtrace, since i don't have a platform with GNU libc on which to test changes. based on reports on #parrot, as of 26949, gettext detection working everywhere i know of (windows, darwin, linux). marking this ticket resolved. ~jerry
Re: get_namespace Oddity
On Sun, Apr 6, 2008 at 10:30 AM, Bob Rogers [EMAIL PROTECTED] wrote: From: Bob Rogers [EMAIL PROTECTED] Date: Sun, 6 Apr 2008 13:25:33 -0400 From: chromatic [EMAIL PROTECTED] Date: Sun, 6 Apr 2008 09:52:34 -0700 ... compounded by the fact that I can't seem to get any of the existing namespace ops to do what I want in a concise, non-hacky way. What am I missing? I notice that changing get_root_namespace to get_hll_namespace makes the code you posted work. That seems completely backwards, though, so I can't say that I understand it either . . . Aha! It's because they're both in the default HLL, the namespace for which is called parrot. So this also works: test_namespace = get_root_namespace [ 'parrot'; 'Test'; 'More' ] Not sure if that's any more intuitive, though. by default, everything you write in pir is in the [ 'parrot' ] hll namespace. therefore, get_root_namespace [ 'parrot', 'Foo' ] is equivalent to get_hll_namespace [ 'Foo' ] unless there's been a previous HLL directive for the non-default hll. clear as mud? ~jerry
Re: What in lieu of the Cpioctl opcode?
On Sun, Apr 6, 2008 at 4:13 PM, Bob Rogers [EMAIL PROTECTED] wrote: I notice that Cpioctl is deprecated in favor of methods on the ParrotIO object (per RT #48589), but I can't figure out what. Is this because the new methods have not been implemented yet? TIA, precisely. allison and i were talking about this today. i/o implementation is due on 1 may, as per http://www.perlfoundation.org/parrot_grant_from_nlnet. however, it will likely be delivered late, as concurrency isn't yet complete and mmd is next on allison's list. i don't think there's anything blocking it's implementation other than a short supply of tuits. if you find any, let me know. ~jerry
Re: tutorial, blog, hackathon
On Thu, Apr 3, 2008 at 10:20 PM, Allison Randal [EMAIL PROTECTED] wrote: Joshua McAdams wrote: The dorms that we have this year have large common areas that we have 24x7 access too. I can investigate them more if I need too. This would be excellent. If the hackathon is the weekend before YAPC::NA, will the dorms and common areas be available then? (I.e., would I be able to check in on the evening of June 13?) yes, we'll have dorm access at least as early as the Friday before the conference. The dorms sound workable. Is it the same dorms as last time YAPC::NA was in Chicago? i'm pretty sure it is. is there a suggested dorm that we could all book rooms close together in? maybe one that has a comfy common area in which to hack the weekend away? maybe one with a/c (at least in the common area, hopefully throughout)? i'm ready to book a room asap, and it'd be nice to be nearby other parrot hackers. birds of a feather ~jerry
Re: [perl #52288] [install] undefined reference to `Parrot_set_executable_name', linking failed
On Wed, Apr 2, 2008 at 4:50 AM, Christian Aperghis [EMAIL PROTECTED] wrote: Andy Dougherty a écrit : On Tue, 1 Apr 2008, Christian Aperghis-Tramoni wrote: I have exactly the same problem under a Debian system. Configure works properly but make ends with the same message error : pbc_to_exe.o: In function `main': pbc_to_exe.c:(.text+0x64): undefined reference to `Parrot_set_executable_name' collect2: ld returned 1 exit status linking failed current instr.: 'link_file' pc 769 (pbc_to_exe.pir:369) called from Sub 'main' pc 124 (pbc_to_exe.pir:32) make: *** [pbc_to_exe] Error 1 My guess is the same as it was in the original problem report -- do you have a previously installed libparrot somewhere (perhaps in /usr/local/lib?) I have not yet heard back from the original poster whether this is the source of the problem, but it seems a reasonable possibility to me. Note that this problem does not appear on a Centos or a MacOsX System. My guess is that those systems do not have a previously installed libparrot somewhere where the linker can find it. If what you are suggesting is right, depending of the system we are working on we cannot perform an upgrade of parrot without removing the former installation. this is correct, until we start versioning our libparrot libraries, which is a platform-dependent task we haven't attacked yet. for example: libparrot.so.0.6.0-devel ~jerry
Re: [PDD19] some remarks/proposals
On Wed, Apr 2, 2008 at 12:29 PM, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
hi,
i have some remarks/proposals on the current PDD 19 (PIR).
It already is full with proposals and issues that must be resolved
before it can be pushed out of draft status, but I figured now is the
time (as it will soon be worked on, I heard)
shall i provide this as a patch, or can i go ahead and commit my {{
PROPOSAL }} stuff?
please feel free to commit it. we'll see the patch on-list after you
commit, anyway.
~jerry
Re: [perl #52220] Test 335 of t/op/01-parse_ops.t segfaults
On Fri, Mar 28, 2008 at 9:42 PM, via RT Seneca Cunningham [EMAIL PROTECTED] wrote: # New Ticket Created by Seneca Cunningham # Please include the string: [perl #52220] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=52220 herodotus:parrot seneca$ ./parrot t/op/01-parse_ops_335.pasm Bus error Crash reporter log: Process: parrot [80742] Path:./parrot Identifier: parrot Version: ??? (???) Code Type: PPC (Native) Parent Process: bash [70067] Date/Time: 2008-03-28 21:31:41.314 -0400 OS Version: Mac OS X 10.5.2 (9C31) Report Version: 6 Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x003c Crashed Thread: 0 Thread 0 Crashed: 0 libparrot.dylib 0x00952b38 INS + 2104 (parser_util.c:749) 1 libparrot.dylib 0x0092d1b4 yyparse + 4276 (imcc.y:824) 2 libparrot.dylib 0x0093cf24 compile_to_bytecode + 500 (main.c:955) 3 libparrot.dylib 0x0093d2b0 imcc_run + 608 (main.c:1058) 4 parrot 0x2434 main + 148 (main.c:56) 5 parrot 0x2340 start + 64 Thread 0 crashed with PPC Thread State 32: srr0: 0x00952b38 srr1: 0x0200f030 dar: 0x003c dsisr: 0x4000 r0: 0xr1: 0xbfffedb0r2: 0xr3: 0x r4: 0x0095a694r5: 0xfefefeffr6: 0x80808080r7: 0x r8: 0xr9: 0x0008 r10: 0x62fefeff r11: 0x00808080 r12: 0x00808080 r13: 0x r14: 0x r15: 0x r16: 0x r17: 0x r18: 0x r19: 0x r20: 0x r21: 0x r22: 0x r23: 0x r24: 0x r25: 0x r26: 0xb754 r27: 0x000c r28: 0x r29: 0x01849600 r30: 0xbfffedb0 r31: 0x00952318 cr: 0x44000422 xer: 0x0004lr: 0x00952b18 ctr: 0x9615b140 vrsave: 0x Binary Images: 0x1000 - 0x6ffb +parrot ??? (???) 7ffd39642fcd0719a153e352cf920993 /opt/src/perl6/svn-clean-only/parrot/parrot 0x9000 - 0xbffd libutil.dylib ??? (???) dacc21eea7647ba1bee44ffc0124489d /usr/lib/libutil.dylib 0x73000 -0x97fdf +libreadline.5.2.dylib ??? (???) /opt/readline52_20071129/lib/libreadline.5.2.dylib 0x125000 - 0x20bff7 +libicuuc.38.dylib ??? (???) /usr/local/lib/libicuuc.38.dylib 0x24a000 - 0x26bff1 libmx.A.dylib ??? (???) /usr/lib/libmx.A.dylib 0x5f - 0x9ca2e7 +libparrot.dylib ??? (???) f4bc26f0b488b86c4b627c18c03a6c99 /opt/src/perl6/svn-clean-only/parrot/blib/lib/libparrot.dylib 0xbe - 0x16b5fff +libicudata.38.dylib ??? (???) /usr/local/lib/libicudata.38.dylib 0x8fe0 - 0x8fe30b23 dyld 96.2 (???) 39109181acbf30fed542e6c9abcf1798 /usr/lib/dyld 0x90779000 - 0x9077eff6 libmathCommon.A.dylib ??? (???) /usr/lib/system/libmathCommon.A.dylib 0x91b7a000 - 0x91be1ffb libstdc++.6.dylib ??? (???) a4e9b10268b3ffac26d0296499b24e8e /usr/lib/libstdc++.6.dylib 0x91cf1000 - 0x91d22fff libncurses.5.4.dylib ??? (???) 56daabc03ccebeaebb5e5efcbe594bd0 /usr/lib/libncurses.5.4.dylib 0x921e8000 - 0x921f3ffb libgcc_s.1.dylib ??? (???) ea47fd375407f162c76d14d64ba246cd /usr/lib/libgcc_s.1.dylib 0x95aff000 - 0x95bb9fff libcrypto.0.9.7.dylib ??? (???) 4ea3d7e9a1c28ac7b17ed80873fe6598 /usr/lib/libcrypto.0.9.7.dylib 0x96151000 - 0x962eafe3 libSystem.B.dylib ??? (???) 754231f5e52ed8418f89f1f3369caf58 /usr/lib/libSystem.B.dylib 0x8000 - 0x9703 libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib ouch. the contents of t/op/01-parse_ops_335.pasm should be somewhere between 2 and 12 lines. could you paste it inline? it would help us find the op(s) causing the segfault. ~jerry
Re: [perl #51916] Error in tests after build
On Tue, Mar 25, 2008 at 7:34 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On Fri Mar 21 19:23:13 2008, [EMAIL PROTECTED] wrote: No, and it appears not be part of Bundle::Parrot on CPAN, either. We'll have to rectify this. Coke asked me to pose this question for general discussion: If individual languages -- as distinct from Parrot itself -- require non-core modules from CPAN, should such modules go into Bundle::Parrot? Should we create a Bundle::Parrot::Languages? Should we create a Bundle::Parrot::SomeSpecificLanguage? no, definitely not. languages must be self-contained. that means any modules/libraries necessary for a particular language implementation must be checked for by the language itself, and not by parrot. languages/dotnet gets this right, by having its own Configure.pl. other languages must move to that standard. Bundle::Parrot is for perl modules that are required to build and develop parrot core, and parrot core only. ~jerry
Re: [perl #51916] Error in tests after build
On Wed, Mar 26, 2008 at 6:29 AM, Will Coleda [EMAIL PROTECTED] wrote: On Wed, Mar 26, 2008 at 7:21 AM, jerry gay [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 7:34 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On Fri Mar 21 19:23:13 2008, [EMAIL PROTECTED] wrote: No, and it appears not be part of Bundle::Parrot on CPAN, either. We'll have to rectify this. Coke asked me to pose this question for general discussion: If individual languages -- as distinct from Parrot itself -- require non-core modules from CPAN, should such modules go into Bundle::Parrot? Should we create a Bundle::Parrot::Languages? Should we create a Bundle::Parrot::SomeSpecificLanguage? no, definitely not. languages must be self-contained. As the one who started this mantra, the original intent here was to get all the configuration information out of core parrot... that means any modules/libraries necessary for a particular language implementation must be checked for by the language itself, and not by parrot. ...Agreed. languages/dotnet gets this right, by having its own Configure.pl. other languages must move to that standard. Bundle::Parrot is for perl modules that are required to build and develop parrot core, and parrot core only. This is the part that I think is open for discussion. I hesitated to add language-specific stuff to B::P, but: While we're bundling the languages in the repository, I think it does make some sense for this to support the entire repository. Balkanizing further at this stage is arguably going to make it more difficult to get HLL developers contributing. Note that we already include Test::Base which is used by APL: If we do go this route for B::P, this should be removed. -- Will Devil's Advocate Coleda ok. replacing parrot core with parrot distro in my earlier message puts us in agreement. however, i want to propose the following points: configure detection for non-core parrot functionality (e.g. language-specific libraries) should be distinguished from core configuration steps somehow (visually and/or otherwise). this will help us rip out a language from the distro when it's determined that it is time to become an external language, or to go the way of the dodo. Bundle::Parrot is currently optimized for parrot developers, because the distrobution is similarly optimized. as it stands, perhaps adding HLL-specific modules to Bundle::Parrot is in line with current thinking. however, i'm not certain that Bundle::Parrot will continue to be a development-specific bundle, or whether it will become user-centric as we approach 1.0. as i see it in my head, Bundle::Parrot would become a user-specific bundle, and something else (Bundle::Parrot::Devel?) would be the development-specific module. i don't mind proliferation of bundles under the Bundle::Parrot:: namespace, so Bundle::Parrot::APL which includes Test::Base and Bundle::Parrot seems reasonable to me. i'll couch that by letting you know that i've been called loony on more than one occasion. ~jerry
Re: [perl #52130] [BUG] postconfigure tests hanging on feather.
On Wed, Mar 26, 2008 at 9:43 AM, James Keenan via RT [EMAIL PROTECTED] wrote: On Wed Mar 26 07:27:44 2008, coke wrote: On feather, when running 'make test', the following tests both hang in an svn checkout: t/postconfigure/03-revision.t # hangs after test 4 t/postconfigure/04-revision.t # hangs after test 4 If I hit control-C when the hang occurs, the tests proceed with all tests passing. I'll try to look into this. What's puzzling is that we get tested on *many* Linux boxes but the overwhelming majority report no problem here. something to do with svk being on the box but never having been run by that user? istr something like this before. iirc hitting enter will make the problem go away, never to return, because svk is waiting for input. it's just a guess, but if that's the problem, I HATE THAT PROBLEM. i'd love to see it go away for good. ~jerry
Re: Deprecating PAST-pm
On Wed, Mar 26, 2008 at 10:50 AM, Patrick R. Michaud [EMAIL PROTECTED] wrote: On Tue, Mar 25, 2008 at 09:32:46PM -0700, [EMAIL PROTECTED] wrote: Modified: trunk/apps/p3/cgi-pir/slides.pir trunk/compilers/past-pm/PAST/Node.pir trunk/compilers/past-pm/POST/Node.pir ... are we at or near a point that past-pm could be removed from the repository? What languages or tools are still using PAST-pm ? ack -af PAST-pm, on a recent revision suggests the following files mention PAST-pm: compilers\past-pm\Makefile compilers\past-pm\PAST-pm.pbc compilers\past-pm\PAST-pm.pir compilers\pct\README compilers\pct\src\PAST.pir config\gen\makefiles\past-pm.in DEPRECATED.pod languages\lua\doc\status.pod languages\lua\src\lua51.pir languages\pheme\pheme.pir languages\plumhead\ChangeLog lib\Parrot\Docs\Section\Compilers.pm MANIFEST MANIFEST.generated NEWS runtime\parrot\library\PAST-pm.pbc t\compilers\past-pm\hllcompiler.t t\compilers\past-pm\past.t t\compilers\past-pm\post.t paring down this list and searching the handful of remaining files for valid content seems like a good CAGE task. ~jerry
Re: [perl #40817] [TODO] track generated files during the configure/make process
On Sun, Mar 23, 2008 at 7:49 PM, James Keenan via RT
[EMAIL PROTECTED] wrote:
Hmm, the more I look at this, the more I realize that even the improved
version of my patch is not ready for prime time. While it DWIMs when
you call 'perl Configure.pl', it doesn't when you call 'perl
Configure.pl --test' (as I do frequently). We only want
MANIFEST.configure.generated to be opened or appended to when we are
actually configuring -- not when we're running tests either
pre-configuration or during 'make test'.
Any ideas as to how this might be salvaged?
i suggest have the functions that write to files check as to whether
they should write or not.
of course, DRY suggests that's best handled by calling another function.
for example,
sub append_configure_log {
my $target = shift;
return if $conf-i_should_not_append_the_configure_log($target);
...
}
~jerry
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
On Sun, Mar 23, 2008 at 6:21 PM, James Keenan via RT [EMAIL PROTECTED] wrote: On Sat Mar 22 10:38:42 2008, doughera wrote: Just be careful that 'use lib' doesn't look outside of the parrot source tree. If pmc2c.pl is normally invoked from the root directory, then ../lib and ../../lib are looking outside of the parrot source. This is wrong, since there is no guarantee that stuff stored in ../../lib is even remotely suitable for parrot, or indeed for any other use. Suppose that at the top of tools/build/pmc2c.pl, we simply state this: use Getopt::Long (); use FindBin qw($Bin); use lib $Bin/../../lib; use Parrot::Pmc2c::Pmc2cMain (); $Bin here is tools/build/. We go two levels up, then back down to the lib/ underneath the top-level Parrot directory. That lib/ is the one in which we'll start looking for Parrot::Pmc2c::Pmc2cMain. So that should mean we're not looking in the wrong places -- correct? why not put the location of parrot's lib dir in Parrot::Config::Generated, and look it up when needed? ~jerry
Re: [perl #38194] [TODO] build - optimize pmc2c.pl
On Sun, Mar 23, 2008 at 9:39 PM, chromatic [EMAIL PROTECTED] wrote: On Sunday 23 March 2008 20:58:24 jerry gay wrote: why not put the location of parrot's lib dir in Parrot::Config::Generated, and look it up when needed? Isn't Parrot::Config::Generated *in* Parrot's lib dir? a minor detail :( ~jerry
Re: [perl #49758] [BUG] rakudo segfaults after No scope found for PAST::Var error
On Mon, Mar 17, 2008 at 10:21 AM, Will Coleda via RT [EMAIL PROTECTED] wrote: On Mon Mar 17 09:34:24 2008, cognominal wrote: $?SUB is not reset between two evals so the outer to an undefined block. I am not sure this is the best place to reset $?SUB. At least if seems to fix the bug. Index: /Users/stef/svn/parrot/compilers/pct/src/PAST/Compiler.pir = == --- /Users/stef/svn/parrot/compilers/pct/src/PAST/Compiler.pir (revision 26447) +++ /Users/stef/svn/parrot/compilers/pct/src/PAST/Compiler.pir (working copy) @@ -71,7 +71,9 @@ unless null blockpast goto have_blockpast blockpast = new 'ResizablePMCArray' set_global '@?BLOCK', blockpast - have_blockpast: +have_blockpast: +null $P0 +set_global '$?SUB', $P0 .return self.'as_post'(past, 'rtype'='v') .end This avoids the segfault, so +1. This does make me notice, though, that PAST::Compiler is using several perl6 variables, which confuses me. PAST::Compiler uses the Perl 6 naming convention for variables because it's *way* better than hungarian notation, however it does assume HLL writers know some Perl 6. i don't think this is too much of a stretch, since parsers and action grammars are written in subsets of Perl 6 already if using PCT and NQP. ~jerry
Re: [perl #41165] [PATCH] appropriate handle CRLE in Here Docs
On Sun, Mar 16, 2008 at 8:09 AM, James Keenan via RT [EMAIL PROTECTED] wrote: There's been no activity in this RT for more than a year, so I am resolving the ticket. we have a category for this called 'stalled'. it's a better reflection of status than 'closed' in cases like this in my opinion. ~jerry
Re: [svn:parrot] r26321 - in trunk/languages/perl6: config/makefiles src/classes src/pmc
On Wed, Mar 12, 2008 at 10:36 AM, chromatic [EMAIL PROTECTED] wrote:
On Tuesday 11 March 2008 22:59:11 [EMAIL PROTECTED] wrote:
Modified:
trunk/languages/perl6/config/makefiles/root.in
trunk/languages/perl6/src/classes/Bool.pir
trunk/languages/perl6/src/pmc/perl6bool.pmc
Log:
[rakudo] implement auto{increment,decrement} semantics as per S03
--- trunk/languages/perl6/src/classes/Bool.pir(original)
+++ trunk/languages/perl6/src/classes/Bool.pirTue Mar 11 22:59:10
2008
@@ -30,6 +31,7 @@
.sub 'ACCEPTS' :method
.param pmc topic
+say foo
.return (self)
.end
Is this vestigial?
i'm sure it is. it's been removed in r26335.
~jerry
