developer survey on contribution policies
Hi all, I'm gathering input on developer perspectives about CLAs and other contribution policies. The primary motivation for the survey is an active conversation around CLAs in the OpenStack project, but also some personal curiosity on my part. It's been something like a decade since I worked on a CLA for Perl, and in retrospect I still wonder whether it was a good fit. I would find it enormously valuable to hear your thoughts, if you can spare 5 minutes to click through the questions: http://survey.lohutok.net/ I'm aiming for a broad and diverse representation of developer communities, so feel free to pass this along to anyone you think might be interested. Thanks, Allison
Re: Future Directions for Parrot and Rakudo
On 06/24/2013 04:34 PM, Darren Duncan wrote: So you're saying then that Jonathan's post wasn't an official statement from the Parrot dev team after the group decided what to do? It certainly read that way to me. Jonathan's statement on parrot-dev was the first I heard of it, and as far as I know wasn't the result of any conversations with anyone. It is his own personal opinion, which he's entitled to hold, but does not reflect any official policy of the Parrot project. Allison
Re: Future Directions for Parrot and Rakudo
On 06/21/2013 10:07 AM, Jonathan "Duke" Leto wrote: Howdy, The future of Parrot and Rakudo Perl 6 are on divergent paths. I am dedicated to a successful future for Parrot which is independent of Rakudo Perl 6. As soon as Rakudo Perl 6 works on MoarVM (the spiritual successor of the m0 branch in parrot.git) [0], anything that Rakudo depends on that is not deemed necessary by Parrot core developers will be removed. This is not a decision you have the right or authority to make, Jonathan. Everyone else, please calm down. Parrot architecture decisions have always been, and will always be, made by open discussion between all participants in the project. Jonathan has expressed his opinion, and there are many legitimate reasons to disagree with his opinion. Discussions will continue. Allison
Re: sound distribution practices
On 04/08/2012 07:13 AM, Alessandro Ghedini wrote:
>> - Debian will package each supported release of Parrot.
>
> Isn't this what's already happening? I mean, we already package stable Parrot
> releases and therefore we can only package Rakudo releases that run on such
> Parrot versions.
Just being explicit about the intentions, since not everyone is involved
in Debian packaging.
> A third, and IMO more elegant, solution (that I just thought about), would be
> to do (sort of) both and copy what the perl package does to maintain
> compatibility with XS modules:
>
> * perl-base provides a virtual package called "perlapi-X.Y.Z" (where X.Y.Z is
> a perl release version such as 5.14.2)
>
> * then, using an automatic script, the XS packages are told, at build time, to
> depend on the perlapi they were built with (Perl packages add a dependency
> on the "${perl:Version}" variable which is replaced by a script, with simply
> "perl" for normal modules and by "perlapi-X.Y.Z" for XS modules at build
> time).
>
> This would allow us to:
>
> * not break Rakudo every time Parrot is updated
> * handle the Rakudo rebuilds sort of automatically without the need to make
> modifications to the Rakudo packaging every time
> * avoid random breakage during testing migrations and partial stable updates
> * scale the whole process if/when other Parrot-based compiler will be uploaded
> to Debian
This is a *much* better solution than using Breaks.
> All this (and your solutions too) would be, of course, more work than a simple
> Breaks in the parrot package is, though, my solution, once put in place (and
> to
> do this we can steal and adapt the code from perl) sort of maintains itself.
>
> To do this the Parrot packaging side would only need to
>
> a) add a "Provides: parrotapi-X.Y.Z" to the parrot package (we would probably
>need to move the bytecode libraries shipped by parrot-devel to parrot or to
>their own package too, in order to simplify this) which would need to be
>updated just like libparrotX.Y.Z is already, and
> b) parrot should ship a "dh_parrot" script which would handle the automatic
>dependencies substitutions (see the dh_perl script shipped by the
>"debhelper" package).
>
> Now, we kind of already agreed for the move of the bytecode libraries out of
> the
> parrot-devel package (did we?)
We at least agreed to move relevant bundles of bytecode libraries out to
separate binary packages (which the parrot-devel package Depends on),
but I don't think that quite catches all of them. We'll be helped by the
fact that Parrot recently had a thread about cleaning out the library
set, so we may have fewer to deal with. I'll follow up on that in a
separate thread.
> and I'd like to volunteer to write the dh_parrot
> script. Once this is done Parrot and Rakudo packging would become much more
> independant one from the other than they are now and make our lives easier
> too :)
Thanks!
Allison
Re: sound distribution practices
On 04/08/2012 11:08 AM, Alessandro Ghedini wrote: > I think I don't understand... NQP and Rakudo *do* ship compiled bytecode, and > would of course need to be rebuilt when a new Parrot release is uploaded. The > whole point of parrotapi-* is to make sure that Parrot and its libraries are > not updated on the users systems (or migrate to testing) until the rebuild of > the compilers is done. This way we avoid that Parrot-based compilers don't > break > in the period of time between the Parrot upload and the compilers rebuild > (which > may be more or less long). > > But the PBC libraries built from Parrot *do* break the compilers if they are > updated before the compilers themselves and the other Parrot packages, and > that > is why they need to be "constrained" by the parrotapi-* mechanism too. Making > them depend on parrotapi-* is just one way, the other would be to make parrot > striclty depend (as in (= X.Y.Z)) on them. I'm agreeing with you, +1, we should go ahead. Use parrotapi-* both for external packages like NQP and Rakudo, and for binary packages built from the Parrot source package (if they contain compiled bytecode, or other version-dependent compiled output like dynpmcs, PMC .dump files, dynops, output of pmc2exe, etc...). Allison
Re: sound distribution practices
trategies to keep the minimum required version as low as possible. Like "soft launching" new features so they're simply not available when they depend on a newer Parrot feature. > Generally, I think things are currently more -Odevelopment than > -Odistribution. I agree that makes things harder for those working on > distributions, and I'm interested to make things better - I want it to > be as easy for people to get their hands on recent Rakudo releases, and > having it packaged for distributions does help with that. On the other > hand, it's also an accurate reflection of the current state of both > projects: in need of development work, and optimizing for it. I guess that raises the question for me of whether Rakudo is ready to be packaged. I don't have any trouble with Parrot packaging, but I do get a regular series of unusual requests from the Rakudo packagers. If the Rakudo project is totally focused on the use-case of downloading the source code or checking out from git and compiling from source, maybe it's just not ready for packaging. I'm sure all the Rakudo packagers will agree with me that they'd really hate to remove it from Debian. But, if packaging isn't something Rakudo wants to support, then we shouldn't force the project into a different mindset. To give you an idea of what Debian packaging is looking for, take a skim through the upstream guide: http://wiki.debian.org/UpstreamGuide > Also just to check - are you packaging Rakudo compiler releases, or > Rakudo distribution releases (which are the ones we more intend for > packaging)? Mostly asking due to the timing of the email; we didn't do a > distribution release for March (so last interested one to package was in > Feb), and the next one is due this month. I'm not building the packages for Rakudo, so can't answer. I've CC'd the Rakudo packaging team. Allison
Re: sound distribution practices
On 04/08/2012 09:29 AM, Alessandro Ghedini wrote: > > If we go down the "split to different libraries" path, those libraries should > depend on parrotapi-* too so that not only Parrot isn't updated but the > libraries aren't too. Or alternatively parrot should strictly depend on them. Makes sense for the libraries that move to separate source packages. But, would it be necessary for libraries in binary packages built from the parrot source package? Allison
Re: sound distribution practices
On 04/08/2012 10:01 AM, Alessandro Ghedini wrote: > > The parrotapi-* thing would avoid an update of the parrot package, but there's > nothing that would avoid an update of, say, libdata-dumper-parrot, and it > would > leave the system with an older version of parrot and a newer version of the > bytecode library, which, as Patrick pointed out, are not compatible. If the > library depends on parrotapi-* too, it is not updated until every other > parrotapi-* reverse dependencies are ready to be updated. Then +1 to updating all the binary packages that contain compiled bytecode, with a Depends on parrotapi-*. Allison
Re: sound distribution practices
Patrick and I just chatted on the phone, here's a summary of the working
scenario we reached:
- Rakudo will deliver a Rakudo release for each supported ("stable")
Parrot release, a few days after the Parrot release.
- Debian will package each supported release of Parrot.
Debian packages for Rakudo will either:
- Rebuild the old Rakudo packages on the new Parrot packages (since the
old compiled bytecode, etc won't work on a different version of Parrot), or
- Package the new version of Rakudo at exactly the same time as the new
version of Parrot. Define the version requirements so tightly (=) that
the Rakudo packages require exactly one version of Parrot.
The first alternative is better, and will be the first preference. But
it needs stable APIs from Parrot, so old Rakudo packages consistently
work on newer versions of Parrot. This is mostly working, but the
exceptions are pain points for packaging (we've got one coming up for 4.3).
Allison
sound distribution practices
Okay, instead of just complaining about this, I want to do something about it. The Rakudo packages are so fragile on Debian, that they need special constraints to make sure the Parrot packages are held back until the Rakudo packages are updated. So, why is Rakudo so dependent on one specific month release of Parrot? Parrot isn't moving so fast that the APIs are all changing every month. Is NQP or Rakudo not respecting API boundaries? Are there some libraries currently shipping in Parrot that should be in NQP, Rakudo, or broken out into their own distributions instead? Rakudo should be able to run on any Parrot release within the past year (at least). The fact that it can't is a sign of poor software. We need to figure out what's broken and fix it. I'm happy to help. Highly motivated too, as it would remove a regular source of irritation. Allison
[perl #63360] [PATCH] Update configure script and makefiles for installed Parrot
On Fri Feb 20 00:36:36 2009, alli...@perl.org wrote:
>
> - There's still a problem with the installed test libraries. I'll look
> into it and provide an additional patch.
Ah, it wasn't a problem with the test libraries, just with Rakudo's
t/harness (using a hardcoded path to the parrot executable). Attached
git patch to fix the test target.
Allison
>From 90672654a8f2600dbc8b67f4f46286d1ed2b7279 Mon Sep 17 00:00:00 2001
From: Allison Randal
Date: Mon, 23 Feb 2009 18:03:30 -0800
Subject: [PATCH] Also fix t/harness to use installed Parrot executable when requested, instead of looking for the executable in a 'parrot/' subdirectory.
---
build/Makefile.in |4 ++--
t/harness | 16 ++--
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/build/Makefile.in b/build/Makefile.in
index 3244ff0..9c88b2e 100644
--- a/build/Makefile.in
+++ b/build/Makefile.in
@@ -149,7 +149,7 @@ CLEANUPS = \
# NOTE: eventually, we should remove --keep-exit-code and --fudge
# as the goal is that all tests must pass without fudge
-HARNESS_WITH_FUDGE = $(PERL) t/harness --fudge --keep-exit-code
+HARNESS_WITH_FUDGE = $(PERL) -I$(TOOLS_DIR) t/harness --bindir=$(BIN_DIR) --fudge --keep-exit-code
HARNESS_WITH_FUDGE_JOBS = $(HARNESS_WITH_FUDGE) --jobs
@@ -243,7 +243,7 @@ codetest:
coretest: perl6.pbc
# prove t/pmc
- $(PERL) t/harness t/00-parrot t/01-sanity
+ $(PERL) -I$(TOOLS_DIR) t/harness --bindir=$(BIN_DIR) t/00-parrot t/01-sanity
fulltest: coretest spectest codetest
diff --git a/t/harness b/t/harness
index 48f2aab..26327fe 100644
--- a/t/harness
+++ b/t/harness
@@ -20,21 +20,25 @@ our %harness_args = (
verbosity => 0,
);
-if (-d 'parrot') {
-$harness_args{exec} = ['parrot/parrot', 'perl6.pbc'];
-} else {
-$harness_args{compiler} = 'perl6.pbc';
-}
-
GetOptions(
'tests-from-file=s' => \my $list_file,
'fudge' => \my $do_fudge,
'verbosity=i' => \$harness_args{verbosity},
+'bindir=s' => \$harness_args{bindir},
# A sensible default is num_cores + 1.
# Many people have two cores these days.
'jobs:3'=> \$harness_args{jobs},
);
+if ($harness_args{bindir}) {
+$harness_args{exec} = [$harness_args{bindir}.'/parrot', 'perl6.pbc'];
+} elsif (-d 'parrot') {
+$harness_args{exec} = ['parrot/parrot', 'perl6.pbc'];
+} else {
+$harness_args{compiler} = 'perl6.pbc';
+}
+
+
my @pass_through_options = grep m/^--?[^-]/, @ARGV;
my @files = grep m/^[^-]/, @ARGV;
--
1.5.6.3
[svn:parrot-pdd] r36125 - trunk/docs/pdds
Author: allison
Date: Wed Jan 28 16:50:06 2009
New Revision: 36125
Modified:
trunk/docs/pdds/pdd28_strings.pod
Log:
[pdd] Add descriptions for 'compare' and 'equal' functions. Catch an
unconverted old function name.
Modified: trunk/docs/pdds/pdd28_strings.pod
==
--- trunk/docs/pdds/pdd28_strings.pod (original)
+++ trunk/docs/pdds/pdd28_strings.pod Wed Jan 28 16:50:06 2009
@@ -342,11 +342,11 @@
Conversion will be done with a function called C:
-INTVAL string_grapheme_copy(STRING *src, STRING *dst)
+INTVAL Parrot_str_grapheme_copy(STRING *src, STRING *dst)
Converting a string from one format to another involves creating a new empty
string with the required attributes, and passing the source string and the new
-string to C. This function iterates through the source
+string to C. This function iterates through the
source
string one grapheme at a time, using the character set function pointer
C (which may read ahead multiple characters with strings that
aren't in NFG). For each source grapheme, the function will call
@@ -536,6 +536,29 @@
Chop the requested number of graphemes off the end of a string without
modifying the original string.
+=head3 Parrot_str_compare (was string_compare)
+
+Compare two strings to each other. Return 0 if they are equal, 1 if the first
+is greater and -1 if the second is greater. Uses character set collation order
+for the comparison. (Two strings that are logically equivalent in terms of
+display, but stored in different normalizations are not equal.)
+
+=head3 Parrot_str_grapheme_compare
+
+Compare two strings to each other. Return 0 if they are equal, 1 if the first
+is greater and -1 if the second is greater. Uses NFG normalization to compare
+the two strings.
+
+=head3 Parrot_str_equal (was string_equal)
+
+Compare two strings, return 1 if they are equal, 0 if they are not equal.
+
+{{DEPRECATION NOTE: The return value is reversed from the current logic.}}
+
+=head3 Parrot_str_grapheme_equal
+
+Compare two strings using NFG normalization, return 1 if they are equal, 0 if
+they are not equal.
=head2 Internal String Functions
[svn:parrot-pdd] r36076 - trunk/docs/pdds
Author: allison
Date: Tue Jan 27 20:35:00 2009
New Revision: 36076
Modified:
trunk/docs/pdds/pdd28_strings.pod
Log:
[pdd] Regularizing string API function names to fit the pattern of a
three-character subsystem identifier.
Modified: trunk/docs/pdds/pdd28_strings.pod
==
--- trunk/docs/pdds/pdd28_strings.pod (original)
+++ trunk/docs/pdds/pdd28_strings.pod Tue Jan 27 20:35:00 2009
@@ -340,7 +340,7 @@
=head3 Conversions between normalization form, encoding, and charset
-Conversion will be done with a function called C:
+Conversion will be done with a function called C:
INTVAL string_grapheme_copy(STRING *src, STRING *dst)
@@ -362,41 +362,41 @@
Parrot's external API will be renamed for the standard "Parrot_*" naming
conventions.
-=head3 Parrot_string_set (was string_set)
+=head3 Parrot_str_set (was string_set)
Set one string to a copy of the value of another string.
-=head3 Parrot_string_new_COW (was Parrot_make_COW_reference)
+=head3 Parrot_str_new_COW (was Parrot_make_COW_reference)
Create a new copy-on-write string. Creating a new string header, clone the
struct members of the original string, and point to the same string buffer as
the original string.
-=head3 Parrot_string_reuse_COW (was Parrot_reuse_COW_reference)
+=head3 Parrot_str_reuse_COW (was Parrot_reuse_COW_reference)
Create a new copy-on-write string. Clone the struct members of the original
string into a passed in string header, and point the reused string header to
the same string buffer as the original string.
-=head3 Parrot_string_write_COW (was Parrot_unmake_COW)
+=head3 Parrot_str_write_COW (was Parrot_unmake_COW)
If the specified Parrot string is copy-on-write, copy the string's contents
to a new string buffer and clear the copy-on-write flag.
-=head3 Parrot_string_concat (was string_concat)
+=head3 Parrot_str_concat (was string_concat)
Concatenate two strings. Takes three arguments: two strings, and one integer
value of flags. If both string arguments are null, return a new string created
according to the integer flags.
-=head3 Parrot_string_append (was string_append)
+=head3 Parrot_str_append (was string_append)
Append one string to another and return the result. In the default case, the
return value is the same as the first string argument (modifying that argument
in place). If the first argument is COW or read-only, then the return value is
a new string.
-=head3 Parrot_string_from_cstring (was string_from_cstring)
+=head3 Parrot_str_from_cstring (was string_from_cstring)
Create a Parrot string from a C string (a C). Takes two arguments, a C
string, and an integer length of the string (number of characters). If the
@@ -405,16 +405,16 @@
{{NOTE: the integer length isn't really necessary, and is under consideration
for deprecation.}}
-=head3 Parrot_string_new
+=head3 Parrot_str_new
Return a new string with the default encoding and character set. Accepts one
argument, a C string (C) to initialize the value of the string.
-=head3 Parrot_string_new_noinit (was string_make_empty)
+=head3 Parrot_str_new_noinit (was string_make_empty)
Returns a new empty string with the default encoding and chararacter set.
-=head3 Parrot_string_new_init (was string_make_direct)
+=head3 Parrot_str_new_init (was string_make_direct)
Returns a new string of the requested encoding, character set, and
normalization form, initializing the string value to the value passed in. The
@@ -429,49 +429,49 @@
C and C can look up the encoding or
character set structs. }}
-=head3 Parrot_constant_string_new (was const_string)
+=head3 Parrot_str_constant_new (was const_string)
Creates and returns a new Parrot constant string. Takes one C string (a C) as an argument, the value of the constant string. The length of the C
string is calculated internally.
-=head3 Parrot_string_resize (was string_grow)
+=head3 Parrot_str_resize (was string_grow)
Resize the string buffer of the given string adding the number of bytes passed
in the integer argument. If the argument is negative, remove the given number
of bytes. Throws an exception if shrinking the string buffer size will
truncate the string (if C will be longer than C).
-=head3 Parrot_string_length (was string_compute_strlen)
+=head3 Parrot_str_length (was string_compute_strlen)
Returns the number of characters in the string. Combining characters are each
counted separately. Variable-width encodings may lookahead.
-=head3 Parrot_string_grapheme_length
+=head3 Parrot_str_grapheme_length
Returns the number of graphemes in the string. Groups of combining characters
count as a single grapheme.
-=head3 Parrot_string_byte_length (was string_length)
+=head3 Parrot_str_byte_length (was string_length)
Returns the number of bytes in the string. The character width of
variable-width encodings is ignored. Combining chara
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote: So you're saying that multiple inheritance in its current state should be allowed to continue, and that there's only a problem with ATTRs if a PMC tries to extend two PMCs, both of which have their own ATTRs? I'm saying that multiple inheritance between two C-level PMCs with different attributes never worked before, so it's no loss that it doesn't work now. If this is the case, I'm happy. The PMCs I've found which use multiple inheritance (LuaFunction, TclInt and TclFloat) all have one parent which appears to be a generic or abstract PMC type for that language (LuaAny and TclObject, respectively). I'll get to work on a patch to propagate ATTRs to children and post it here when it gets close to ready. Sounds good. Thanks! Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote:
The PMC UnionVal deprecation can't be completed until Parrot has
improved ATTR
reuse between extending PMCs. I'm rewriting code to minimize dependence on
the PMC_x_val macros, but I can't eliminate them completely without better
inheritance support. I'd like to implement whatever the long-term
solution is, which seems to mean multiple inheritance regarding ATTRs.
I've been puzzling over how to implement this in a way that would work
similarly to the current PMC_x_val macros. The problem with allowing
multiple inheritance is that we can't simply copy ATTRs from parents
into the same slot in their children when multiple parents have an ATTR
in the same slot.
This doesn't make sense. The PMC_x_val macros accessed the union value
of the PMC. Any PMC that used them had a fixed set of attributes, either:
- a buffer
- two pointers
- two integers
- a float, or
- a string
Because it was a union value, the PMC could use one and only one of the
alternatives, and the parent and child had to use the same alternative.
So, when you're translating an old-style PMC to a new-style PMC, you'll
define one of:
- a buffer
ATTR void * _bufstart;
ATTR size_t _buflen;
- two pointers
ATTR DPOINTER * _struct_val;
ATTR PMC * _pmc_val;
- two integers
ATTR INTVAL _int_val;
ATTR INTVAL _int_val2;
- a float
ATTR FLOATVAL _num_val;
- a string
ATTR STRING * _string_val;
And hopefully give it a more meaningful name than the original.
Parent and child had to have the same struct in the original (because
every PMC defined the same union val struct), and so still have to have
the same struct in the new version. It is progress: at least the struct
members will have more meaningful names, and it will become possible to
subclass these older PMCs from within PIR. More progress will come later
with enhancements to inheritance, but that's no reason to hold up the
deprecation of the union struct.
The best I've been able to come up with is to use yet another Hash to
store the ATTRs, turning the GETATTR/SETATTR macros into something like
the following (modulo supporting code):
#define GETATTR_PMCType_foo(interp, pmc, x) {
x = (AttrTypeGoesHere)parrot_hash_get(interp, pmc->attr_hash,
key_new_cstring(interp, "PMCType_foo"));
}
This would allow the accessor macros to work on PMCs similarly to how
PMC_x_val is used now, i.e. they'll DTRT as long as the PMC is in the
right inheritance tree.
This is overkill. Accessor macros already work on PMCs similarly to how
PMC_x_val is used.
Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Jonathan Worthington wrote: I'm curious - is anyone else doing a HLL on Parrot that uses morph? If nobody is, is it worth spending time on, or even worth keeping? 'morph' was added specifically for the Perl 5 behavior of changing types when assigned to. But really, a more accurate representation of Perl 5 behavior would be to have a single Scalar PMC that can act as a string, int, or number. So, yes, it's possible that 'morph' could be deprecated. It needs a review of current uses to make sure that they're either unnecessary (most examples I've seen are), or can be cleanly substituted with something else. Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto wrote: Allison Randal wrote: (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) When I say "attributes", I mean the things that are declared in .pmc files right after the pmclass line, e.g. ATTR INTVAL foo_refs; /*foo refcount*/ These do not appear to be passed down to extending PMCs. This is a problem for e.g UnManagedStruct/ManagedStruct, where PMC_int_val is used the same way by both PMCs. Right, at the moment it is absolutely required that the first ATTR declarations of the child are manual copies of the ATTR declarations of the parent. Otherwise, the inheritance won't work at all. (Ultimately, inheritance will automatically copy the parent's attributes and prepend them onto the front of the child's attribute list, but at the moment it has to be done manually.) What I'd like is for the pmc2c code to be smart enough to make ATTRs from an extended PMC accessible by an extending PMC through the GET_ATTR/SET_ATTR macros. If I could get a description of how such a patch should behave from our architect, I'd be glad to write one up and submit it for review. The fix actually goes in a different place. The GET_ATTR/SET_ATTR macros will be correctly generated for all child attributes. What really needs to change is to add the parent's attribute list to the child's attribute list during PMC parsing in Pmc2c. Take a look at lib/Parrot/Pmc2c/Parser.pm. (I can give more specific guidance after the release, working on milestone items at the moment.) Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Patrick R. Michaud wrote: Just for the record, AFAICT none of PGE/PCT/Rakudo make use of morph any longer. We now have the 'copy' opcode to do what the "morph workaround" was doing (and I don't think copy is using VTABLE_morph). We've been ripping out morph in all the core PMCs too. So, I'm comfortable transitioning to just a PMC argument to morph. Allison
Re: [perl #41825] [BUG] morph vtable override not working in PIR
Andrew Whitworth via RT wrote: Okay, I did some work on this last night, and here's the current status. 1) Modified the behavior of the "morph" PIR override so that it takes a string in trunk. We previously weren't able to override this method at all, so nobody is used to the "old way" at the PIR level. This does mean that for the time-being the PIR implementation of "morph" is different from the C implementation of it. However, the benefit is that the PIR-level API doesn't need to change later when the C-level API does. 2) Created a branch "morph_pmc_type" to make the switch from "void morph(INTVAL type)" to "void morph(STRING *type)". Most of the conversion is already done. I have some more changes to make and some general cleanup before I call the work in the branch "done", however. 3) I've added a test for the behavior to t/oo/vtableoverride.t in trunk If nobody has any complaints about this work, I'll add the old flavor of morph to DEPRECATED.pod, and then merge the branch in sometime after 0.9.0 or 0.9.1. Not a string, a PMC (like Coke said). String type names are almost as bad as type IDs. And check the performance on the branch, as I'm not sure how heavily PGE is using morph. We may need both integer and PMC versions of morph for the internals, but only allow the PMC one to be overridden from PIR. Allison
Re: [perl #48014] [DEPRECATED] PMC union struct
Christoph Otto via RT wrote: I'm running into a snag trying to implement this. It turns out that many lines which use the PMC_x_val macros use them on different types of PMCs, especially parents and children (e.g. FixedPMCArray and ResizablePMCArray). There are also some instances where the PMCs with a related purpose but no inheritance (e.g. RetContinuation and ExceptionHandler) have the unionval used in the same way on a line of code. What's the right way to fix these cases to use the GETATTR/SETATTR macros? Tough to answer without looking at the code, but... The GET_ATTR/SET_ATTR macros will work on inherited attributes as well as child attributes. (Actually, at the moment you're required to declare all parent attributes in the ATTR list before the child attributes, so inherited attributes *are* child attributes.) If two unrelated PMCs are being called in the same line of code, that probably means it should really be a vtable function call instead of direct access into the data struct. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Bob Rogers wrote: I can't log in, though that may just be because I've forgotten the password. But the odd thing is that the "Reset Password" page says "The email and username do not match a known account", even though I know my ID is "rgrjr" and there are only a few possible email addresses I would have used (and Firefox even remembered my first choice). Your account had no email address associated with it. I just deleted the old account, so re-register and I'll regrant you permissions. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Bob Rogers wrote: What about those of us who can't log in? I can't even reset my password, let alone update anything . . . It won't let you log in at all? Or, once you log in it won't let you do anything? I just reset your password, let me know if you don't get an automated email about the update. Allison
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Allison Randal wrote: Our trac admins report that this is caused by users who don't have their email authenticated (that is, Trac sends you a test email, and you confirm that you got it, so Trac knows the address is valid). When we upgraded, existing users needed to re-authenticate their email addresses, but the upgrade process doesn't include resending the authentication emails. When you update your email address in trac, it should resend the authentication request. Once you confirm the change, you'll be set. I just confirmed this with my account. Adding a name and email address under 'Preferences' destroyed my privileges, and made the following error message appear at the top of each page: Warning: It also emailed me a verification message, and once I followed the steps in the message, my permissions were all restored. Our admins also mentioned that this unhelpful error message is filed as a bug in the TracAccountManager plugin: http://trac-hacks.org/ticket/4125 Allison
[svn:parrot-pdd] r35378 - in trunk: . config/gen/makefiles docs docs/pdds include/parrot lib/Parrot/Docs/Section src src/gc src/pmc src/stm
Author: allison Date: Sat Jan 10 19:55:39 2009 New Revision: 35378 Modified: trunk/docs/pdds/pdd09_gc.pod Changes in other areas also in this revision: Added: trunk/include/parrot/gc_api.h - copied unchanged from r35374, /branches/pdd09gc_part2/include/parrot/gc_api.h trunk/include/parrot/gc_mark_sweep.h - copied unchanged from r35374, /branches/pdd09gc_part2/include/parrot/gc_mark_sweep.h trunk/include/parrot/gc_pools.h - copied unchanged from r35374, /branches/pdd09gc_part2/include/parrot/gc_pools.h trunk/src/gc/api.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/api.c trunk/src/gc/gc_malloc.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/gc_malloc.c trunk/src/gc/generational_ms.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/generational_ms.c trunk/src/gc/incremental_ms.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/incremental_ms.c trunk/src/gc/mark_sweep.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/mark_sweep.c trunk/src/gc/pools.c - copied unchanged from r35374, /branches/pdd09gc_part2/src/gc/pools.c Removed: trunk/include/parrot/dod.h trunk/include/parrot/headers.h trunk/include/parrot/smallobject.h trunk/src/gc/dod.c trunk/src/gc/gc_gms.c trunk/src/gc/gc_ims.c trunk/src/gc/smallobject.c trunk/src/headers.c Modified: trunk/MANIFEST trunk/config/gen/makefiles/root.in trunk/docs/debug.pod trunk/docs/memory_internals.pod trunk/docs/pmc.pod trunk/include/parrot/parrot.h trunk/include/parrot/settings.h trunk/lib/Parrot/Docs/Section/C.pm trunk/src/cpu_dep.c trunk/src/gc/resources.c trunk/src/inter_run.c trunk/src/pmc.c trunk/src/pmc/array.pmc trunk/src/pmc/deleg_pmc.pmc trunk/src/pmc/integer.pmc trunk/src/stacks.c trunk/src/stm/backend.c trunk/src/thread.c Log: [pdd09gc] Merging the pdd09gc_part2 branch into trunk for r34686 to r35374. GC refactor: reorganize code for sanity and maintainability. Modified: trunk/docs/pdds/pdd09_gc.pod == --- trunk/docs/pdds/pdd09_gc.pod(original) +++ trunk/docs/pdds/pdd09_gc.podSat Jan 10 19:55:39 2009 @@ -567,14 +567,14 @@ The PMC has some sort of active destructor, and will have that destructor called when the PMC is destroyed. The destructor is typically called from -within C. +within C. =item PObj_custom_mark_FLAG The C vtable slot will be called during the GC mark phase. The mark function must call C for all non-NULL objects (Buffers and PMCs) that PMC refers to. This flag is typically tested and the custom mark -VTABLE method called from C. +VTABLE method called from C. =item PObj_data_is_PMC_array_FLAG
Re: [perl #61870] [BUG] [META] Trac system borks authenticated user's privileges
Our trac admins report that this is caused by users who don't have their email authenticated (that is, Trac sends you a test email, and you confirm that you got it, so Trac knows the address is valid). When we upgraded, existing users needed to re-authenticate their email addresses, but the upgrade process doesn't include resending the authentication emails. When you update your email address in trac, it should resend the authentication request. Once you confirm the change, you'll be set. Allison
[svn:parrot-pdd] r34684 - trunk/docs/pdds
Author: allison Date: Tue Dec 30 18:53:27 2008 New Revision: 34684 Modified: trunk/docs/pdds/pdd07_codingstd.pod Log: [pdd] Remove the 'HISTORY' section from expected documentation, as it is no longer used. Be explicit on our policy about author information in individual files. Remove a legacy perl6-ism. Modified: trunk/docs/pdds/pdd07_codingstd.pod == --- trunk/docs/pdds/pdd07_codingstd.pod (original) +++ trunk/docs/pdds/pdd07_codingstd.pod Tue Dec 30 18:53:27 2008 @@ -840,11 +840,6 @@ successors, e.g. benchmarks of differing hash algorithms, essays on how to do integer arithmetic. -=item HISTORY - -Record major changes to the file, e.g. "we moved from a linked list to a hash -table implementation for storing Foos, as it was found to be much faster". - =item SEE ALSO Links to pages and books that may contain useful information relevant to the @@ -852,6 +847,10 @@ =back +Don't include author information in individual files. Author information can be +added to the CREDITS file. (Languages are an exception to this rule, and may +follow whatever convention they choose.) + =item Per-section comments If there is a collection of functions, structures or whatever which are @@ -924,15 +923,13 @@ =head2 Extensibility -If Perl 5 is anything to go by, the lifetime of Perl 6 will be at least -seven years. During this period, the source code will undergo many major -changes never envisaged by its original authors -- c.f. threads, unicode in -perl 5. To this end, your code should balance out the assumptions that make -things possible, fast or small, with the assumptions that make it difficult -to change things in future. This is especially important for parts of the -code which are exposed through APIs -- the requirements of source or binary -compatibility for such things as extensions can make it very hard to change -things later on. +Over the lifetime of Parrot, the source code will undergo many major changes +never envisaged by its original authors. To this end, your code should balance +out the assumptions that make things possible, fast or small, with the +assumptions that make it difficult to change things in future. This is +especially important for parts of the code which are exposed through APIs -- +the requirements of source or binary compatibility for such things as +extensions can make it very hard to change things later on. For example, if you define suitable macros to set/test flags in a struct, then you can later add a second word of flags to the struct without breaking source
Re: [perl #58410] [TODO] Deprecate n_* variants of the math opcodes
Will Coleda via RT wrote:
On Thu Aug 28 00:03:51 2008, alli...@perl.org wrote:
The plan is to make the regular variants (like 'add') create a new
destination PMC, and then deprecate the old n_* variants (like 'n_add').
Does this include n_not , n_bnot, and n_bnots ?
Yes. The 'not', 'abs', 'bnot', and 'bnots' opcodes already have
2-argument variants, the 'n_*' alternates are unnecessary.
The task also involves modifying the corresponding vtable functions
('logical_not', 'absolute', 'binary_not', 'binary_nots') so they return
a new PMC, rather than morphing the existing destination PMC. (Many of
them already do this, so the 'n_*' variants were actually already doing
the same thing as the regular opcodes.)
Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: Apparently "remove the files" isn't exactly what was meant here. This probably removes the need for the remove_pic branch, which is in the process of taking this to its literal extreme. We do need to remove the files, and the remove_pic branch is on the right track. There's just a couple lines of code here and there that have to be kept. The only other place to look is in the JIT code. In src/jit.c, in the 'parrot_build_asm' function, it's using the 'pic_callr__' opcode to invoke a NCI function/JITted sub. src/jit.c:1624 (op_func[PARROT_OP_pic_callr___pc].fn)(jit_info, interp); This opcode may need a new non-PIC variant, and should certainly be converted to use one of the standard calling conventions (PCC or C). (I can come back and look into it in a few days, I'm providing information here to help guide anyone else who takes a crack at it.) BTW, the other failing test in the remove_pic branch was simply because there are fewer elements in the packfile directory now that 'pic_index' has been removed. Fixed in r34401. Allison
Re: [perl #60048] [BUG] [MMD] CGP Does Not Work with PCC Runcore Reentry
Will Coleda via RT wrote: I created a branch (remove_pic) to remove src/pic.c; This led to the removal of pic.ops, and changes in imc, packfile... lots of references to PIC. chromatic mentioned on #parrot that if we remove PIC, we're going to break all the predereferenced runcores. After some discussion, this probably means ripping out: 16:42 <@chromatic> Everything other than the default core, the nearly-useless profiling core, and the gc-debug core. He mentioned this in a conversation, but I don't believe it. AFAICT, he's drawing the conclusion from the fact that these cores call some functions (or a function) in src/pic.c. But, the functions I've examined had a small nugget of code that could be moved out of PIC, so the rest of the PIC function could be safely deleted. CGP is too important to be deprecated over something as small as this. Allison
Re: Optimizing PMC-based MMD
chromatic wrote: Within the cmp op bodies, we *know* the arity and most of the types of MMD- participant arguments at compile time. We can get the types of PMC participants within the body of the op itself. Thus we could avoid most of the argument marshalling and counting and analysis if we had a way to perform cached MMD lookup without constructing a CallSignature PMC. That would clear up a third of the work. This we should open up to general discussion. The consequence of short-cutting like this is that individual PMCs will no longer be able to override 'cmp' to do something other than multi-dispatch. At the moment, developers still have the option of providing their own quick comparison, which gives an even more extreme speedup than this shortcut. So, question for language developers and other PMC developers, how important is the ability to define a 'cmp' vtable function that's called when the 'cmp' opcode is invoked? Or, is defining a 'cmp' multi for your PMC type enough? Another area for optimization is invoking a Sub from a signature PMC; I believe we're throwing away and recalculating valuable information, though we may have to wait for dramatic improvements until we can unify contexts and CallSignature. Providing a new way of invoking Subs that uses CallSignatures all the way down is already planned in the coming series of calling conventions refactors. The final opportunity for optimization is making the PMC multis defined in PMCs use PCC instead of C calling conventions. Corresponding multis written in PIR already use PCC, and we want to support that, so we should unify our approach. That would remove the NCI expense here, though that's probably minor in comparison to the CallSignature PMC expense. Changing all NCI calls to something more like PCC calls is already planned in the coming series of calling conventions refactors. Changing the Pmc2c generator to build PCC subs instead of NCI Subs is a quick change that could happen now. The calling conventions refactors are non-critical (some will likely land after 1.0), because the interface will stay the same, it's only the internals that will change. Allison
Re: [perl #60046] [META] November 2008 release
James Keenan via RT wrote: On Wed Dec 17 13:29:59 2008, kjs wrote: I thought I closed it last time. Trying again :-) kjs The ticket has 3 dependencies which are still open. Is it possible that the ticket cannot be resolved until these dependencies are resolved? Yes, but you can just remove the dependencies. Clearly the release has already happened without them, so they aren't really dependencies. Allison
[svn:parrot-pdd] r33985 - trunk/docs/pdds
Author: allison Date: Tue Dec 16 14:03:21 2008 New Revision: 33985 Modified: trunk/docs/pdds/pdd22_io.pod Log: [pdd] Remove section on Deprecated Opcodes from I/O PDD, now that all of them have been removed. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podTue Dec 16 14:03:21 2008 @@ -492,8 +492,7 @@ $P0 = readline $P1, $P2 Retrieves a single line from a stream into a string. Calling -C flags the stream as operating in line-buffer mode (see -C below). +C flags the stream as operating in line-buffer mode. The asynchronous version takes an additional final PMC callback argument, and only returns a status object. When the readline operation @@ -575,52 +574,6 @@ =back -=head3 Deprecated opcodes - -=over - -=item * - -C provides low-level access to the attributes of a stream -object. It takes a stream object, an integer flag to select a command, -and a single integer argument for the command. It returns an integer -indicating the success or failure of the command. - -This opcode has been replaced with methods on the FileHandle object, but -is kept here for reference. See RT #48589 - -The following constants are defined for the commands that C can -execute: - - 0PIOCTL_CMDRESERVED - No documentation available. - 1PIOCTL_CMDSETRECSEP - Set the record separator. [This doesn't actually work at the - moment.] - 2PIOCTL_CMDGETRECSEP - Get the record separator. - 3PIOCTL_CMDSETBUFTYPE - Set the buffer type. - 4PIOCTL_CMDGETBUFTYPE - Get the buffer type - 5PIOCTL_CMDSETBUFSIZE - Set the buffer size. - 6PIOCTL_CMDGETBUFSIZE - Get the buffer size. - -The following constants are defined as argument/return values for the -buffer-type commands: - - 0PIOCTL_NONBUF - Unbuffered I/O. Bytes are sent as soon as possible. - 1PIOCTL_LINEBUF - Line buffered I/O. Bytes are sent when a newline is - encountered. - 2PIOCTL_BLKBUF - Fully buffered I/O. Bytes are sent when the buffer is full. - -=back - =head2 Filesystem Opcodes [Okay, I'm seriously considering moving most of these to methods on the
[svn:parrot-pdd] r33695 - in trunk: . compilers/imcc compilers/pct/src/PCT config/gen/makefiles docs docs/pdds include/parrot languages/WMLScript/src languages/lua languages/lua/src/lib languages/perl
Author: allison Date: Mon Dec 8 21:16:33 2008 New Revision: 33695 Modified: trunk/docs/pdds/pdd22_io.pod Changes in other areas also in this revision: Added: trunk/src/io/core.c - copied unchanged from r33691, /branches/pdd22io_part2/src/io/core.c trunk/src/io/socket_api.c - copied unchanged from r33691, /branches/pdd22io_part2/src/io/socket_api.c trunk/src/io/socket_unix.c - copied unchanged from r33691, /branches/pdd22io_part2/src/io/socket_unix.c trunk/src/io/socket_win32.c - copied unchanged from r33691, /branches/pdd22io_part2/src/io/socket_win32.c trunk/src/io/utf8.c - copied unchanged from r33691, /branches/pdd22io_part2/src/io/utf8.c Removed: trunk/src/io/io.c trunk/src/io/io_buf.c trunk/src/io/io_layers.c trunk/src/io/io_passdown.c trunk/src/io/io_stdio.c trunk/src/io/io_unix.c trunk/src/io/io_utf8.c trunk/src/io/io_win32.c trunk/src/io/unix_socket.c trunk/src/io/win32_socket.c trunk/src/pmc/parrotio.pmc Modified: trunk/MANIFEST trunk/compilers/imcc/instructions.c trunk/compilers/imcc/main.c trunk/compilers/imcc/parser_util.c trunk/compilers/imcc/pbc.c trunk/compilers/pct/src/PCT/HLLCompiler.pir trunk/config/gen/makefiles/root.in trunk/docs/tests.pod trunk/include/parrot/io.h trunk/include/parrot/string_funcs.h trunk/languages/WMLScript/src/wmlsstdlibs.pir trunk/languages/lua/luac2pir.pir trunk/languages/lua/luad.pir trunk/languages/lua/src/lib/luaaux.pir trunk/languages/lua/src/lib/luaperl.pir trunk/languages/perl6/src/classes/Object.pir trunk/src/debug.c trunk/src/dynoplibs/myops.ops trunk/src/embed.c trunk/src/events.c trunk/src/exceptions.c trunk/src/extend.c trunk/src/gc/dod.c trunk/src/gc/register.c trunk/src/global.c trunk/src/inter_create.c trunk/src/interpreter.c trunk/src/io.c trunk/src/io/api.c trunk/src/io/buffer.c trunk/src/io/io_private.h trunk/src/io/unix.c trunk/src/io/win32.c trunk/src/jit.c trunk/src/malloc.c trunk/src/multidispatch.c trunk/src/oo.c trunk/src/ops/io.ops trunk/src/ops/ops.num trunk/src/packdump.c trunk/src/packfile.c trunk/src/packfile/pf_items.c trunk/src/packout.c trunk/src/pbc_merge.c trunk/src/pdump.c trunk/src/pmc/coroutine.pmc trunk/src/pmc/filehandle.pmc trunk/src/pmc/pccmethod_test.pmc trunk/src/pmc/sub.pmc trunk/src/pmc/unmanagedstruct.pmc trunk/src/runops_cores.c trunk/src/spf_vtable.c trunk/src/stacks.c trunk/src/stm/backend.c trunk/src/string.c trunk/src/sub.c trunk/src/thread.c trunk/src/trace.c trunk/src/warnings.c trunk/t/compilers/imcc/syn/op.t trunk/t/op/interp.t trunk/t/op/string_cs.t trunk/t/op/stringu.t trunk/t/pmc/filehandle.t trunk/t/pmc/io.t trunk/t/pmc/parrotio.t trunk/t/src/basic.t trunk/t/src/compiler.t trunk/t/src/exit.t trunk/t/src/extend.t trunk/t/src/warnings.t trunk/t/steps/auto_pmc-01.t Log: [pdd22io] Merging the pdd22io_part2 branch into trunk for r32922 to r33687. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podMon Dec 8 21:16:33 2008 @@ -250,6 +250,15 @@ Accessor (get only) for the I/O stream's read mode. This returns the mode string used to open the I/O stream. +=item C + + $S0 = $P1.encoding() + $P0.encoding($S1) + +Accessor (get and set) for the I/O stream's encoding attribute. Currently, +the only valid value to set is 'utf8' which turns on UTF-8 reading/writing +mode for the stream. The default behavior is fixed-width 8-bit characters. + =item C [RT #48312] $I0 = $P1.get_fd()
[svn:parrot-pdd] r33688 - trunk/docs/pdds
Author: allison Date: Mon Dec 8 19:45:45 2008 New Revision: 33688 Modified: trunk/docs/pdds/pdd15_objects.pod Log: [pdd] Caught documented name inconsistent with implemented name. Modified: trunk/docs/pdds/pdd15_objects.pod == --- trunk/docs/pdds/pdd15_objects.pod (original) +++ trunk/docs/pdds/pdd15_objects.pod Mon Dec 8 19:45:45 2008 @@ -297,7 +297,7 @@ =over 4 -=item new() +=item instantiate() Instantiate a new object from the class. Set the instantiated flag on the class.
[svn:parrot-pdd] r33181 - trunk/docs/pdds/draft
Author: allison
Date: Mon Nov 24 23:41:10 2008
New Revision: 33181
Modified:
trunk/docs/pdds/draft/pdd14_numbers.pod
Log:
[pdds] Add interface definition for Integer PMC.
Modified: trunk/docs/pdds/draft/pdd14_numbers.pod
==
--- trunk/docs/pdds/draft/pdd14_numbers.pod (original)
+++ trunk/docs/pdds/draft/pdd14_numbers.pod Mon Nov 24 23:41:10 2008
@@ -49,9 +49,172 @@
=head2 Integer PMC
+The C PMC is a high-level integer type, providing the features of a
+integer data type appropriate for use in a high-level language. Some languages
+may be able to use Parrot's C directly as their integer data type,
+others may subclass C to add their own functionality, and others may
+implement their own high-level integer data type.
+
+The C PMC has a single attribute, the integer value.
+
+=head3 Integer Vtable Functions
+
+=over 4
+
+=item init()
+
+Initialize the C to 0.
+
+=item set_pmc(PMC *value) and set_integer_same(PMC* value)
+
+Set the C to the integer value of the PMC argument.
+
+=item set_integer_native(INTVAL value)
+
+Set the C to the passed-in integer value.
+
+=item set_number_native(FLOATVAL value), set_bool(INTVAL value),
set_bigint_int(INTVAL value), set_string_native(STRING *value)
+
+Morphs the C PMC to a C, C, C, or C
+PMC, and sets the value from the passed in value.
+
+{{NOTE: the morphing behavior is currently under consideration and may be
+rejected.}}
+
+=item get_integer()
+
+Retrieves the integer value of the C.
+
+=item get_bool()
+
+Returns the boolean value of the C (false if 0, true otherwise).
+
+=item get_number()
+
+Returns the integer value of the C as a floating-point number.
+
+=item get_bignum()
+
+Returns the integer value of the C in a new C PMC.
+
+=item get_string() and get_repr()
+
+Returns the integer value of the C as a string.
+
+=item [add|subtract|multiply|divide|floor_divide|modulus|pow]_int(INTVAL b,
PMC *dest)
+
+Add/subtract/multiply/divide/modulus/exponent an integer value with the
+C PMC, and return the result as a new PMC (the C parameter is
+unused). Overflow of the native integer storage auto-promotes the result PMC
+to a C.
+
+=item i_[add|subtract|multiply|divide|floor_divide|modulus|pow]_int(INTVAL b)
+
+Add/subtract/multiply/divide/modulus/exponent an integer value with the
+C PMC, and set the C to the resulting value. Overflow of the
+native integer storage auto-promotes the C to a C.
+
+{{NOTE: there is some discussion of having this promotion of storage happen
+purely internally (perhaps by swapping vtables), rather than converting to a
+different PMC type.}}
+
+=item i_[add|subtract|multiply|divide|floor_divide|modulus|pow]_float(INTVAL b)
+
+Add/subtract/multiply/divide/modulus/exponent an integer value with the
+C PMC, and set the C to the resulting value, morphing it to a
+C.
+
+=item increment()
+
+Add 1 to the value of the integer.
+
+=item decrement()
+
+Subtract 1 from the value of the integer.
+
+=item absolute()
+
+Return an C PMC set to the absolute value of the current C.
+
+=item i_absolute()
+
+Set the C to the absolute value of itself.
+
+=item freeze()
+
+Freeze the C PMC for storage.
+
+=item thaw()
+
+Thaw the C PMC from storage.
+
+
+=back
+
+=head3 Integer Multis
+
+Many of the math vtable functions are defined instead as multiple dispatch
+functions.
+
+=over 4
+
+=item [add|subtract|multiply|divide|floor_divide|modulus|pow](PMC *value, PMC
*dest)
+
+Perform the addition/subtraction/multiplication/division/modulus/exponent
+operation, and return a new PMC containing the resulting value. Multiple
+dispatch variants are defined for C, C, C, C,
+and C.
+
+Overflow of the native integer storage auto-promotes the result PMC to a
+C.
+
+=item i_[add|subtract|multiply|divide|floor_divide|modulus|pow](PMC *value)
+
+Perform the addition/subtraction/multiplication/division/modulus/exponent
+operation, morphing the C to the passed in type, and setting it to the
+result. Multiple dispatch variants are defined for C, C,
+C, and C.
+
+Overflow of the native integer storage auto-promotes the C to a
+C.
+
+=item is_equal(PMC *value)
+
+Compare the C to the passed in PMC, return true (1) if they are equal,
+and false (0) otherwise. Multiple dispatch variants are defined for C
+and C. {{NOTE: Presumably the C, C, and C
+cases are all covered by C.}}
+
+=item cmp(PMC *value)
+
+Compare the C to the passed in PMC, return 1 if C is greater,
+-1 if the PMC is greater, and 0 if they are equal. Multiple dispatch variants
+are defined for C, C, and C. {{NOTE: Presumably the
+C and C cases are covered by C.}}
+
+=item cmp_num(PMC *value)
+
+Compare the C to the passed in PMC, return 1 if C is greater,
+-1 if the PMC is greater, and 0 if they are equal. Multiple dispatch variants
+are defined for C, C, and C. {{NOTE: Presumably the
+C and C cases are covered by C.}}
+
+=back
+
+=head3 Integer Methods
+
+=over 4
+
+=item get_as_base(INTVAL base)
+
+Conver
[svn:parrot-pdd] r33178 - trunk/docs/pdds/draft
Author: allison Date: Mon Nov 24 21:33:52 2008 New Revision: 33178 Removed: trunk/docs/pdds/draft/pdd04_datatypes.pod Log: [pdds] Deleting the now completly redundant datatypes PDD (number 4 is now available for reuse).
[svn:parrot-pdd] r33177 - trunk/docs/pdds/draft
Author: allison
Date: Mon Nov 24 21:32:51 2008
New Revision: 33177
Modified:
trunk/docs/pdds/draft/pdd14_numbers.pod
Log:
[pdds] Descriptions of the native integer and float types.
Modified: trunk/docs/pdds/draft/pdd14_numbers.pod
==
--- trunk/docs/pdds/draft/pdd14_numbers.pod (original)
+++ trunk/docs/pdds/draft/pdd14_numbers.pod Mon Nov 24 21:32:51 2008
@@ -3,20 +3,56 @@
=head1 NAME
-docs/pdds/pdd14_bignum.pod - Big Numbers
+docs/pdds/pdd14_numbers.pod - Parrot Numbers
=head1 ABSTRACT
-{{ NOTE: needs to be compared to current behavior of bignum library.
-Future directions?}}
-
-This document describes the big number library, the functionality it provides
-and some internal details of interest to people making use of the library.
-Some of the areas in which the big number library meet with the rest of Parrot
-are also discussed.
+This PDD describes Parrot's numeric data types.
=head1 DESCRIPTION
+This PDD details the basic numeric datatypes that the Parrot core knows how to
+deal with, including the core numeric PMCs.
+
+=head2 Integer data types
+
+Parrot provides a native integer data type, generally known as an "Int". The
+size of the integer is chosen at Parrot configuration time, the same size as
+platform-native integers. In C, the typedefs C and C are
+native signed and unsigned integers respectively. The semantics of native
+integer data types are the same as the semantics of their C equivalents.
+
+Integer data types have a dedicated register set. In PIR, the C register
+variables (C<$I0>, etc.) and C<.param>s or C<.local>s declared with the C
+type are native integers. Native unsigned integers are not accessibly directly
+in PIR. Many opcodes or vtable functions are defined with variants that take
+native integer arguments. When passed to a subroutine or method call, a native
+integer may be autoboxed as an C PMC, or as an HLL type mapped to
+C.
+
+
+=head2 Floating-point data types
+
+Parrot provides a native floating-point data type, generally known as a "Num".
+The size of the float is chosen at Parrot configuration time, the same size as
+platform-native floats. In C, the typedef C is a native float data
+type. The semantics of the native float data type are the same as the semantics
+of the C equivalent.
+
+Float data types have a dedicated register set. In PIR, the C register
+variables (C<$N0>, etc.) and C<.param>s or C<.local>s declared with the C
+type are native floats. Many opcodes or vtable functions are defined with
+variants that take native float arguments. When passed to a subroutine or
+method call, a native float may be autoboxed as a C PMC, or as an HLL
+type mapped to C.
+
+
+=head2 Integer PMC
+
+=head2 Float PMC
+
+=head2 BigNum PMC
+
The big number library provides Parrot with both a collection of (nearly)
infinite precision numeric types and an implementation of an extended decimal
arithmetic (EDA).
@@ -378,48 +414,9 @@
IBM's Standard Decimal Arithmetic, with tests
L<http://www2.hursley.ibm.com/decimal/>
-Perl's Math::Big* modules.
-
-=head1 VERSION
-
-=head2 CURRENT
-
-Maintainer: Alex Gough ([EMAIL PROTECTED])
-Class: Internals
-PDD Number: 14
-Version: $Id$
-Status: Informational
-Last Modified: $Id$
-PDD Format: 1
-Language: English
+The Perl modules Math::BigInt and Math::BigFloat.
-=head2 HISTORY
-
-=over 4
-
-=item version 1.1
-
-The first version is more a description of the state of the art than a plan
-for the future. The author believes this is akin to learning how to crawl
-before trying to run. Leaving the ground is considered Right Out with
-attempts being left as an exercise for the interested reader.
-
-=back
-
-=head1 CHANGES
-
-=over 4
-
-=item Version 1.0
-
-None. First version
-
-=item Version 1.1
-
-Special values added, exception handling updated to suit EDA, more rounding
-types added, TODO added. PDD number bagged.
-
-=back
+Alex Gough's suggestions for bigint/bignum implementation.
=cut
[svn:parrot-pdd] r33174 - trunk/docs/pdds/draft
Author: allison Date: Mon Nov 24 20:30:27 2008 New Revision: 33174 Added: trunk/docs/pdds/draft/pdd14_numbers.pod - copied unchanged from r33169, /trunk/docs/pdds/draft/pdd14_bignum.pod Removed: trunk/docs/pdds/draft/pdd14_bignum.pod Log: [pdds] Renaming PDD 14, preparing for merge of three PDDs.
Re: [perl #60626] [DEPRECATED] Old-style MMD functions
Will Coleda via RT wrote: * Parrot_mmd_add_function - src/inter_create.c //make_interpreter Delete that line from src/inter_create.c. Also delete the line before which initializes 'interp->binop_mmd_funcs' to NULL. These two lines are initializing the storage for the old MMD subsystem, which is never used anymore. Note that this implies deprecating all functions that refer to 'interp->binop_mmd_funcs'. (It looks like those are all caught in this list, just double-check to make sure. Ah, I don't see 'dump_mmd' in this list, it can also be removed, as it doesn't do anything anymore.) * mmd_cvt_to_types - src/multidispatch.c //Parrot_mmd_get_cached_multi_sig 'Parrot_mmd_get_cached_multi_sig' is only called by 'mmd_distance', which is only called by 'Parrot_mmd_sort_candidates'. 'Parrot_mmd_sort_candidates' is called all over the place (I standardized on that when I did the MMD cleanup). Let's see what chromatic's MMD sort cleanup does. If it eliminates the call to 'mmd_distance' then problem solved. If not, then let's break the deprecation of 'mmd_cvt_to_types' out into a separate ticket for refactoring the unholy trio of 'mmd_cvt_to_types', 'Parrot_mmd_get_cached_multi_sig', and 'mmd_distance'. Allison
[svn:parrot-pdd] r32918 - in trunk: . config/gen/makefiles docs/pdds include/parrot lib/Parrot/Pmc2c src src/io src/pmc t/pmc
Author: allison Date: Wed Nov 19 17:50:32 2008 New Revision: 32918 Modified: trunk/docs/pdds/pdd22_io.pod Changes in other areas also in this revision: Added: trunk/include/parrot/io_portable.h - copied unchanged from r32916, /branches/pdd22io/include/parrot/io_portable.h trunk/include/parrot/io_unix.h - copied unchanged from r32916, /branches/pdd22io/include/parrot/io_unix.h trunk/include/parrot/io_win32.h - copied unchanged from r32916, /branches/pdd22io/include/parrot/io_win32.h trunk/src/io.c - copied unchanged from r32916, /branches/pdd22io/src/io.c trunk/src/io/api.c - copied unchanged from r32916, /branches/pdd22io/src/io/api.c trunk/src/io/buffer.c - copied unchanged from r32916, /branches/pdd22io/src/io/buffer.c trunk/src/io/portable.c - copied unchanged from r32916, /branches/pdd22io/src/io/portable.c trunk/src/io/unix.c - copied unchanged from r32916, /branches/pdd22io/src/io/unix.c trunk/src/io/unix_socket.c - copied unchanged from r32916, /branches/pdd22io/src/io/unix_socket.c trunk/src/io/win32.c - copied unchanged from r32916, /branches/pdd22io/src/io/win32.c trunk/src/io/win32_socket.c - copied unchanged from r32916, /branches/pdd22io/src/io/win32_socket.c trunk/src/pmc/filehandle.pmc - copied unchanged from r32916, /branches/pdd22io/src/pmc/filehandle.pmc trunk/t/pmc/filehandle.t - copied unchanged from r32916, /branches/pdd22io/t/pmc/filehandle.t Modified: trunk/MANIFEST trunk/config/gen/makefiles/root.in trunk/include/parrot/io.h trunk/lib/Parrot/Pmc2c/Parser.pm Log: [pdd22io] Merging the pdd22io branch into trunk for r32120 to r32916. Modified: trunk/docs/pdds/pdd22_io.pod == --- trunk/docs/pdds/pdd22_io.pod(original) +++ trunk/docs/pdds/pdd22_io.podWed Nov 19 17:50:32 2008 @@ -49,11 +49,10 @@ =head2 Concurrency Model for Asynchronous I/O -Currently, Parrot only implements synchronous I/O operations. For the -1.0 release the asynchronous operations will be implemented separately -from the synchronous ones. There may be an implementation that uses one -variant to implement the other someday, but it's not an immediate -priority. +Currently, Parrot only implements synchronous I/O operations. Initially, +the asynchronous operations will be implemented separately from the +synchronous ones. There may be an implementation that uses one variant +to implement the other someday, but it's not an immediate priority. Synchronous opcodes are differentiated from asynchronous opcodes by the presence of a callback argument in the asynchronous calls. Asynchronous @@ -90,7 +89,7 @@ [See L<http://en.wikipedia.org/wiki/Asynchronous_I/O>, for a relatively comprehensive list of asynchronous I/O implementation options.] -=head2 I/O PMC API +=head2 FileHandle PMC API Methods @@ -108,7 +107,7 @@ =item C - $P0 = new ParrotIO + $P0 = new 'FileHandle' Creates a new I/O stream object. [Note that this is usually performed via the C opcode.] @@ -124,9 +123,10 @@ I/O stream. $S2 is a file path and $S3 is an optional mode for the stream (read, write, read/write, etc), using the same format as the C opcode: 'r' for read, 'w' for write, 'a' for append, and 'p' for -pipe. When the mode is set to write or append, a file is created without -warning if none exists. When the mode is read (without write), a -nonexistent file is an error. +pipe. When the optional mode argument is not passed, the default is read mode. +When the mode is set to write or append, a file is created without warning if +none exists. When the mode is read (without write), a nonexistent file is an +error. The asynchronous version takes a PMC callback as an additional final argument. When the open operation is complete, it invokes the callback @@ -171,12 +171,11 @@ $P0 = $P1.read($I2, $P3) Retrieves a specified number of bytes $I2, from a stream $P1 into a -string $S0. By default it reads in bytes, but the ParrotIO object can be -configured to read in code points instead, by applying a C or -similar role to the object [the syntax for applying a role to an object -has yet to be defined in PDD 15]. If there are fewer bytes remaining in -the stream than specified in the read request, it returns the remaining -bytes (with no error). +string $S0. By default it reads in bytes, but the FileHandle object can +be configured to read in code points instead, by setting the character +set and encoding on the filehandle object. If there are fewer bytes +remaining in the stream than specified in the read request, it returns +the remaining bytes (with no error). The asynchronous version takes an additional final PMC callback argument $P3, and only returns a status object $P0. When the read operation is @@ -214,26 +213,13 @@ =ite
Re: [perl #60564] [TODO] Refactor contexts to be PMCs
Patrick R. Michaud via RT wrote: Can (should) we do one or more of the following...? 1. Mark GC as a dependency for this ticket 2. Mark this ticket as "stalled" waiting for GC issues 3. Move this ticket to the new Trac ticket queue This would help remove this from our "active ticket" queue, since we're not likely to make much progress on it until after GC refactors are done. Go with #2 for now. I only submitted the ticket so the patch wouldn't be lost on my laptop. The GC refactor will start in 2 weeks, so the wait won't be terribly long, but it's good to have the status show that this isn't a ticket in need of active work. Allison
Re: [perl #60564] [TODO] Refactor contexts to be PMCs
Andrew Whitworth via RT wrote: Since I'm monkeying around in the relevant code anyway, this might be a good task for the next calling_conventions branch. Or, if you prefer, we could create a second branch for this conversion and do the work there. The general consensus on this one is to wait until after the GC refactor (which is the next big branch after the I/O). Contexts are recycled so rapidly, that the current GC would be really slow. Allison
Re: [perl #49276] [TODO] Refactor tools/util/smokeserv-server.pl
Will Coleda wrote: Is the smoke server still used? Can support for the smoke server be dropped? +1 from me; I vote for smolder. +1, on not maintaining two independent solutions for the same problem. Allison
Re: [perl #43831] [CAGE] Document how we do function decoration
Andrew Whitworth via RT wrote: 1) Rename this ticket to something more descriptive 2) Rename seatbelts.pod to something more descriptive, like /docs/dev/C_Functions.pod or something. 3) Expand that documentation to include more cases (ARGIN, ARGMOD, ARGOUT, all the *_NULLOK variants of those, etc). Agreed. Once 2) and 3) are done, ticket can be closed. Allison
Re: [perl #53210] [TODO] change new_from_string to init_str
Andrew Whitworth via RT wrote: On Tue Apr 22 10:05:57 2008, [EMAIL PROTECTED] wrote: We've been kicking around the idea of removing new_from_string for a while, but the pushback is always that it's useful to be able to create a new PMC with some initialization data, without first creating a PMC initializer that has to be garbage collected. So, instead of removing it entirely, make it a standard initialization option, passing a string argument instead of a PMC argument. [...] Is this idea still being kicked around? What would all the new interfaces look like? This seems like the kind of update that could be tackled in the next month if we wanted something that was more internally consistent. - Would need a new vtable function 'init_str'. void init_str(STRING *initializer) Or alternatively, if we find we need to exactly duplicate the interface of 'new_from_string': void init_str(STRING *initializer, INTVAL flags) - The 'new' opcode would need two additional variants that take a STRING initializer instead of a PMC initializer: =item B(out PMC, in STR, in STR) =item B(out PMC, in PMC, in STR) - The 'pmc_new' function would need two new variants, in addition to 'pmc_new' (which calls VTABLE_init), 'pmc_new_init' (which takes an extra PMC argument and calls VTABLE_init_pmc), and 'pmc_new_noinit' (which doesn't call any vtable init), and the constant versions of each. pmc_new_init_str(PARROT_INTERP, INTVAL base_type, ARGIN(STRING *init)) Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Martin D Kealey wrote: What about keeping track of where the exception was originally created? If we have lazy exceptions, then knowing where the fault they represent was detected is probably more important than were (exactly) it was triggered. Or does this all amount to the same thing? Is an exception only "lazy" because there's an enclosing dynamic scope that catches it and transmogrifies it into an Uncaught Exception? Or if not, could we have both back-traces available? A "created_by" back-trace and a "thrown_by" back-trace? Theoretically, yes. But 99% of the time, the useful information is where the exception was thrown, so the extra effort of tracking both doesn't add enough value to be worth it. But, if someone did need to track both (perhaps for a research project), they could just subclass the Exception class and add a creation backtrace. Allison
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
Will Coleda via RT wrote: This appears to be the only .pragma; should we leave a placeholder or just remove .pragma entirely when we remove this particular one? Nuke it. Allison
[perl #31143] [TODO] Interpreter - share MMD tables
On Wed Oct 15 17:48:28 2008, Whiteknight wrote: > > With the pdd27mmd branch merged in now, what's the status of this request? The MMD table is now just a namespace, and namespaces are shareable between interpreters. So, resolved. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Patrick R. Michaud wrote: On Fri, Oct 24, 2008 at 12:18:40PM -0700, Allison Randal wrote: (I suppose technically we should stop calling this a "stack trace" since it's not a stack. But "return continuation chain trace" is just too verbose.) "backtrace" Exactly the word I was looking for. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda wrote: Allison Randal wrote: ...you expect 'rethrow' to keep the stack trace of the original 'die'? Yes. The way to do this is to add stack trace information to the Exception's 'stacktrace' attribute when the exception is first thrown, and print that out for an unhandled exception, instead of printing out the literal current path of execution. (This is why I added the 'stacktrace' attribute.) But, the implementation isn't currently using this feature. Largely, we just haven't decided what information to store in 'stacktrace'. I'd say a data structure is more useful than a string, because it can be manipulated by various HLLs to the format of their stacktrace dumps. So, what information do the HLL developers want from the original stack trace? (I suppose technically we should stop calling this a "stack trace" since it's not a stack. But "return continuation chain trace" is just too verbose.) Allison
Re: [perl #60048] CGP Does Not Work with PCC Runcore Reentry
chromatic (via RT) wrote: Several tests fail with the CGP runcore (parrot -C) when multidispatch re-enters bytecode -- in specific, anything that calls into src/pic.c from Parrot_pcc_invoke_sub_from_sig_object causes failures. The problem appears to be that CGP's PIC tries to poke into the bytecode directly to find get_params and similar opcodes, while parameter-passing information is in a context after Parrot_pcc_invoke_sub_from_sig_object. One workaround is to enforce the use of the normal runcore only for calls back into Parrot from Parrot_pcc_invoke_sub_from_sig_object, but that's just a workaround. A better solution is to fix the PIC code to look in the appropriate place in the context for return values. That seems like a good task for the calling conventions branch. I've been debating whether src/pic.c should be removed entirely. It's a swodge of code that only gives a tiny speedup for 4 opcodes: 'infix', 'get_params', 'set_args', and 'set_returns'. And the 'infix' opcode has been deprecated and will be removed in the calling conventions branch (it was a nasty hack for the old MMD system). And it's not even really the right speedup for 'get_params', 'set_args', and 'set_returns'. There are also a pile of old, nasty MMD functions that should be deleted and are only called from src/pic.c. Allison
Re: Parrot on mobile platforms?
Ovid wrote: I can't speak for Android, but I know one of the constraints on the iPhone is memory. This, as I recall, is part of the reason why they don't have garbage collection available and force people to manage memory directly (this, I might add, is a pain). Since I generally don't worry about memory, I've no idea if Parrot is a memory hog. It's light on memory compared to other virtual machines, but would require some work to get it down to mobile phone size. That being said, I can't imagine Apple would be terribly keen to endorse anything which requires jail breaking the phone. Don't we have contacts in Apple? Getting official approval for trying this out might be a nice thing. In fact, I already know an iPhone developer who would be a great fit for a challenge like this (if he's interested). Yes, but the mobile group is completely separate from the open source group. Still, it's worth asking. Allison
Re: [perl #60044] [BUG?] rethrow just throwing?
Will Coleda (via RT) wrote: I would expect both of these programs to output the same thing, but it looks like rethrow is generating the same output that throw would here. What is the difference supposed to be between these two ops? The two ops are intentionally almost entirely the same. The only difference is that 'throw' creates a new iterator of exception handlers, while 'rethrow' pulls the next exception handler off the iterator. So, 'rethrow' cannot be called on an exception that hasn't been thrown before. And if 'throw' is called on an exception that's already been thrown before, it will return to the first exception handler again, instead of the next exception handler in the chain of handlers. $ cat foo.pir sub foo :main bar() end sub bar baz() end sub baz die "eek" end $ ../../parrot foo.pir eek current instr.: 'baz' pc 24 (foo.pir:10) called from Sub 'bar' pc 19 (foo.pir:6) called from Sub 'foo' pc 7 (foo.pir:2) $ cat bar.pir sub foo :main push_eh eh bar() pop_eh end eh: .get_results($P0) rethrow $P0 end sub bar baz() end sub baz die "eek" end $ ../../parrot bar.pir eek current instr.: 'foo' pc 16 (bar.pir:9) I don't understand the problem. Is it that you expect 'rethrow' to keep the stack trace of the original 'die'? Allison
[perl #46677] [TODO] [C] Merge fixedbooleanarray.pmc with functions from BigInt PMC
On Tue Sep 23 22:34:38 2008, cotto wrote: > > I propose to reject this ticket. Reducing code duplication is a good > idea, but it's not at all clear to me what this ticket is referring to. > If someone cares to point out what code should be merged, great. > Otherwise this ticket is too vague to be useful. Ticket rejected, and comment removed from code in r32039. Allison
[perl #40392] [CAGE] convert C to a catchable exception
On Mon Sep 22 06:37:24 2008, Whiteknight wrote: > > Sept 08 milestone came and went. Any updates on this ticket? Maybe this > ticket should be closed out (since it's vague) and replaced with another > ticket or tickets for individual places where exit_fatal should be > replaced with real_exception, if any. In the process of changing 'internal_exception' to 'exit_fatal' we reviewed those calls, and changed as many as possible to real exceptions. (Basically, if it could be converted to an exception, it was, if it couldn't be, it was left as 'exit_fatal'.) Closing this ticket. Allison
Re: [perl #59240] Automate publishing of docs/*
Chris Davaz wrote: Ahh, cool I didn't even know we had parrot.org. Publishing docs/book/* would be nice. On Tue, Sep 23, 2008 at 10:27 PM, Will Coleda: On Tue, Sep 23, 2008 at 9:04 AM, via RT Chris Davaz: I suggest we automate the publishing of everything under docs/* and putting it under parrotcode.org/docs in HTML format for easy access. This would probably help productivity and maybe even attract new developers. Just my two cents... we're moving to http://www.parrot.org/ ; I think Allison has said we're going to automate this publishing process. Yes, we're moving to docs.parrot.org, a site generated using a fork of the perldoc.perl.org generation code. (Ideally, this will end up being the 'make html' target, so anyone can generate a mirror of the same site.) Allison
Re: [perl #58988] [RFC] Parrot_get_runtime_prefix function
NotFound (via RT) wrote: The Parrot_get_runtime_prefix in src/library.c return a char *, forcing the places that currently uses it to be more complicated than desired for no real gain. I added and used a STRING * variant named Parrot_get_runtime_path (that name makes more sense to me) in r31216 The question is: must we retain the old variant, kill it, deprecate it, use his name for the new version, or revert the change and stay with the char * way? 'STRING *' is vastly preferable to 'char *' anywhere it can be used. Mark the old one as deprecated, replace all calls to 'Parrot_get_runtime_prefix' with calls to 'Parrot_get_runtime_path', and after a standard one release deprecation cycle remove the old function. Allison
Re: [perl #36249] [TODO] Document policy on breakage, er, backward compatibility.
jerry gay wrote: 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. Change that to 1.0, which is when we'll start guaranteeing API stability. And, we have discussed it considerably. The most likely scenario so far is: - Yearly major release (1.0, 2.0, 3.0...), which may contain substantial API changes. - Half-yearly minor release (1.5, 2.5, 3.5...), which may contain minor API changes, and deprecation notices for the next major release. - Regular (two/three month?) point releases (1.x.x, 2.x.x...) primarily bug and security fixes, which will contain no API deletions, but may contain minor API additions, and deprecation notices for the next major or minor release. This continues our time-based release policy, which has worked well for the development release process. Features that don't make it into one major or minor release get rolled into the branch for the next major or minor release, so we don't have an insane rush to cram features in just before a release. Allison
Re: [perl #45965] [RFC] Should slot names still have __ in front?
chromatic wrote: On Wednesday 15 October 2008 17:33:58 Will Coleda via RT wrote: With the attached patch, parrot builds and tests with no errors[0]. A re-configure is necessary to regenerate a file. [0] well, no additional or unexpected errors. Works for me. +1 to apply. +1 Allison
Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin
James Keenan via RT wrote: On Sat Oct 18 16:28:22 2008, coke wrote: I'm submitting some every night at midnight on my osx/x86 box; if it's obviously a temp directory and the right time frame, it's probably me. Coke, can you confirm that the test is failing for you now? And, what version of Mac OS? So it seems to be failing consistently on Darwin regardless of platform. It's passing on Mac OS 10.5.5 on my Intel laptop. Which makes it difficult to debug the failure. Also, tonight I confirmed that the failure began at the recent merge in r31668. For the record, the svn diff of the test file at that point was: $ svn diff -r 31667:31668 t/op/bitwise.t Index: t/op/bitwise.t === --- t/op/bitwise.t (revision 31667) +++ t/op/bitwise.t (revision 31668) @@ -552,11 +552,11 @@ loop: if $P1 > 100 goto done ## shift number and i_number into $P2 and $I2. -n_shl $P2, number, $P1 +shl $P2, number, $P1 $I1 = $P1 shl $I2, i_number, $I1 ## compare in I registers. -$P3 = n_mod $P2, integer_modulus +$P3 = mod $P2, integer_modulus $I3 = $P3 if $I2 >= 0 goto pos_check ## The register op gave a negative result, but the modulus will always be However, as this test is passing on many other platforms, it's quite possible that the failure is due to something that happened elsewhere in r31668. I would suggest reverting that one change to see if it solves the problem, but the n_mod and n_shl opcodes don't exist anymore. Could you run the attached modified version of the test file and send me the output? Allison ## The PMC shl op will promote Integer to Bigint when needed. We can't stuff a ## BigInt in an I register, but we can produce the same result modulo wordsize. ## [Only we cheat by using the word size minus one, so that we don't have to ## deal with negative numbers. -- rgr, 2-Jun-07.] .sub main :main ## Figure out the wordsize. We need integer_modulus because assigning a ## too-big BigInt throws an error otherwise. .include 'sysinfo.pasm' .local int i_bytes_per_word, i_bits_per_word_minus_one .local pmc bits_per_word_minus_one, integer_modulus i_bytes_per_word = sysinfo .SYSINFO_PARROT_INTSIZE i_bits_per_word_minus_one = 8 * i_bytes_per_word dec i_bits_per_word_minus_one bits_per_word_minus_one = new 'Integer' bits_per_word_minus_one = i_bits_per_word_minus_one integer_modulus = new 'BigInt' integer_modulus = 1 integer_modulus <<= bits_per_word_minus_one ## Test shifting a positive number. new $P0, 'Integer' set $P0, 101 test_shift($P0, integer_modulus) ## Test shifting a negative number. set $P0, -101 test_shift($P0, integer_modulus) .end .sub test_shift .param pmc number .param pmc integer_modulus new $P1, 'Integer' set $P1, 1 .local int i_number i_number = number ## Start the loop. loop: if $P1 > 100 goto done ## shift number and i_number into $P2 and $I2. say "\nno error before shl" $S0 = typeof number print "typeof first argument 'number' is " say $S0 $S0 = typeof $P1 print "typeof second argument '$P1' is " say $S0 shl $P2, number, $P1 say "no error after shl" $S0 = typeof $P2 print "typeof result '$P2' is " say $S0 $I1 = $P1 shl $I2, i_number, $I1 ## compare in I registers. say "\nno error before mod" $S0 = typeof $P2 print "typeof first argument '$P2' is " say $S0 $S0 = typeof integer_modulus print "typeof second argument 'integer_modulus' is " say $S0 $P3 = mod $P2, integer_modulus say "no error after mod" $S0 = typeof $P3 print "typeof result '$P3' is " say $S0 $I3 = $P3 if $I2 >= 0 goto pos_check ## The register op gave a negative result, but the modulus will always be ## positive. If the truncated result is correct, then the difference will ## be the most negative INTVAL, which is the only number for which -x==x. $I4 = $I3 - $I2 $I5 = - $I4 if $I4 == $I5 goto ok goto bad pos_check: if $I2 == $I3 goto ok bad: print "oops; not ok: " print i_number print ' << ' print $I1 print ' gives I ' print $I2 print ' vs. P ' print $P3 print ".\n" print $I5 print "\n" ok: ## set up for the next one inc $P1 goto loop done: print "done.\n" .end
Re: [perl #59636] [BUG] t/op/bitwise.t fails on Darwin
James Keenan via RT wrote: Still failing on Darwin/PPC as of r32014: http://smolder.plusthree.com/app/public_projects/tap_stream/6320/163 Looking at the specific test in question, this may be an integer size problem. And I should note that it's also been failing on Darwin/i386: http://smolder.plusthree.com/app/public_projects/tap_stream/6316/163 What version of Darwin and what x86 hardware? Allison
Re: [perl #57438] [DEPRECATED] [PDD19] .pragma n_operators
Andrew Whitworth via RT wrote: After the pdd27mmd merge, all the n_* opcodes are gone now. I assume the ".pragma n_operators" can disappear with them? Yes. (The n_* opcodes aren't quite all gone yet, but nearly and soon.) Allison
Re: [perl #46295] [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation
Andrew Whitworth via RT wrote: The pdd15oo branch was merged in and conversation on this ticket stopped almost a year ago now. Is there still outstanding documentation work to do on this topic, besides the general "all documentation should be improved" work that always needs to be done? Are there any specific changes in the code that have not yet been reflected in the documentation? This ticket can be closed. We have a general documentation review pass coming up preparing for the 1.0 release, and this is just part of that. Doesn't need a separate ticket. Allison
[perl #38432] [BUG] Exception thrown from constructor leads to oddness
On Wed Oct 15 12:42:23 2008, coke wrote: > Here's yet another updated version (this time for the exception handler) > of the test that doesn't segfault, but still generates incorrect output > (generates both an OK line and a NOK line) It looks like the exception handler is resuming after the exception is handled. (Resuming by default, instead of only resuming when the resume continuation is explicitly invoked.) Allison
Re: [perl #59544] open(null) kills parrot
NotFound wrote: Where to put a test for this? There is no t/ops/io.t and creating a file for each io opcode seems excessive Create a t/ops/io.t. We'll add to it in the I/O milestone (the next one on the list, which I'll create a branch for later this week). Allison
Re: [perl #59704] [BUG] Integer pow vtable promotes to float.
Will Coleda (via RT) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #59704] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=59704 > sub main :main $P1 = new 'Integer' $P1 = 2 $P2 = new 'Integer' $P2 = 3 $P3 = $P1 ** $P2 $S0 = typeof $P3 say $S0 $P3 = $P1 ** 3 $S0 = typeof $P3 say $S0 end generates "Float\nInteger", I'm pretty sure that before the MMD merge it would have been "Integer\nInteger". I've TODO'd some partcl tests until this is resolved. The semantics of inherited vtable functions and multiple dispatch changed in the MMD branch. In the old system, an inherited vtable function would be completely ignored for the small subset of vtable functions that commonly multiply dispatch. The new semantics respect inherited vtable functions. There was a VTABLE 'pow' in scalar that had previously been ignored in Integer, but was now being used (it called 'set_number_native' which morphed the destination to a Float). So, I changed scalar's 'pow' to a MULTI in r31880, and it works fine. Allison
Re: [perl #59782] [PATCH] add pmc_cmp VTABLE function
Christoph Otto (via RT) wrote: In response to a question about comparison operators in Pipp*, Allison suggested that I add a variant cmp VTABLE function which returns a PMC instead of an INTVAL. This patch adds such a function, named pmc_cmp. It's named pmc_cmp rather than cmp_pmc to try to avoid confusion with the other cmp_* functions, since the type name in this function name refers to the return type rather than the argument type. Hmmm... we don't use that convention anywhere else (putting the type first to indicate that it's a return type, rather than an argument type). The closest we come is the 'get' and 'set' vtable functions which are 'get__keyed_'. The 'shift' and 'pop' vtable functions both use 'shift_pmc' and 'pop_pmc' to indicate that the return type is a PMC. So, let's stick with 'cmp_pmc' for this one. Otherwise, thumbs up, looks great! Allison
Re: [RFC][PATCH] Rename Rakudo's "spectest_regression" to "spectest"
Moritz Lenz wrote: jerry gay wrote: A combined harness is much better in terms of reporting. Yes. the tests we expect to pass reliably should be the default tests we run. we expect all spectest_regression tests to pass reliably. the default test target should always be named 'test'. it seems natural that we add spectest_regression to the 'test' makefile target. additionally, this would have possibly prevented the 74 failures post-mdd-merge, since allison didn't know about the additional test target in the makefile. well, if reading the README is too much even for our architect then we shouldn't assume that anybody else does ;-) Another thing that would be helpful for languages in trunk is something like a TESTME file. It should briefly say exactly what steps a core developer should take to test that their changes haven't broken the language, and if failures are expected or all tests should pass. Also, anything strange like having multiple test harnesses running in sequence instead of aggregating the results in one report. (That one caught me on Rakudo's 'make test' too. I thought all the test were passing, and then found that the final "All tests pass" report was hiding earlier failures in a different summary.) The README is quite verbose and intended for people who want to use the language. Even after reading it, it's not straightforward to decide what to test and whether failures are relevant. What would be really ideal is if core developers could just run 'make languagetest' in the repository root and get a single report of all the language failures, and know for sure that any failures are their responsibility. But, we're a long way away from that. Allison
Re: [perl #59658] Build failure in src/pmc/float.c -- non-constant intiializer
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. Allison
[svn:parrot-pdd] r31755 - trunk/docs/pdds/draft
Author: allison Date: Tue Oct 7 08:04:35 2008 New Revision: 31755 Modified: trunk/docs/pdds/draft/pdd01_overview.pod Log: [pdd] New introduction for Overview PDD. Modified: trunk/docs/pdds/draft/pdd01_overview.pod == --- trunk/docs/pdds/draft/pdd01_overview.pod(original) +++ trunk/docs/pdds/draft/pdd01_overview.podTue Oct 7 08:04:35 2008 @@ -3,11 +3,11 @@ =head1 NAME -docs/pdds/pdd01_overview.pod - A high-level overview of the Parrot system +docs/pdds/pdd01_overview.pod - A high-level overview of Parrot =head1 ABSTRACT -A high-level overview of the Parrot system. +A high-level overview of the Parrot virtual machine. =head1 VERSION @@ -15,23 +15,15 @@ =head1 DESCRIPTION -The following diagram gives a rough outline of the architecture of -Parrot and the relationship between its major components, ranging from -the components closest to the high-level languages targeting Parrot, -down to those closest to the operating system. - - +---+ - |Parser Grammar Engine (PGE)| - +---+ - | Tree Grammar Engine (TGE) | - +-+-+ - | PASM | PIR | - | (assembly language) | (intermediate language) | - +-+-+ - | Parrot Interpreter (IMCC) | - +---+ - |Extensions | - +---+ +Parrot is a virtual machine for dynamic languages like Python, PHP, Ruby, and +Perl. A dynamic language is one that allows things like extension of the code +base, subroutine and class definition, and altering the type system at +runtime. Static languages like Java or C# restrict these features to compile +time. If this sounds like an edgy idea, keep in mind that Lisp, one of the +prime examples of a dynamic language, has been around since 1958. The basic +paradigm shift to dynamic languages leads the way to other more advanced +dynamic features like higher-order functions, closures, continuations, and +coroutines. =head1 IMPLEMENTATION
[svn:parrot-pdd] r31668 - in trunk: . compilers/imcc compilers/nqp/src compilers/pct/src/PAST compilers/pirc/src config/auto config/gen config/gen/makefiles docs docs/pdds docs/stm editor examples/ben
Author: allison Date: Sun Oct 5 04:30:01 2008 New Revision: 31668 Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod Changes in other areas also in this revision: Added: trunk/docs/multidispatch.pod - copied unchanged from r31667, /branches/pdd27mmd/docs/multidispatch.pod trunk/include/parrot/multidispatch.h - copied unchanged from r31667, /branches/pdd27mmd/include/parrot/multidispatch.h trunk/lib/Parrot/Pmc2c/MULTI.pm - copied unchanged from r31667, /branches/pdd27mmd/lib/Parrot/Pmc2c/MULTI.pm trunk/src/multidispatch.c - copied unchanged from r31667, /branches/pdd27mmd/src/multidispatch.c trunk/src/pmc/callsignature.pmc - copied unchanged from r31667, /branches/pdd27mmd/src/pmc/callsignature.pmc trunk/src/pmc/cpointer.pmc - copied unchanged from r31667, /branches/pdd27mmd/src/pmc/cpointer.pmc trunk/t/pmc/multidispatch.t - copied unchanged from r31667, /branches/pdd27mmd/t/pmc/multidispatch.t Removed: trunk/docs/mmd.pod trunk/include/parrot/mmd.h trunk/src/mmd.c trunk/t/pmc/mmd.t Modified: trunk/MANIFEST trunk/compilers/imcc/parser_util.c trunk/compilers/nqp/src/Grammar.pg trunk/compilers/pct/src/PAST/Compiler.pir trunk/compilers/pirc/src/pirutil.c trunk/config/auto/pmc.pm trunk/config/gen/makefiles/root.in trunk/config/gen/parrot_include.pm trunk/docs/stm/internals.pod trunk/editor/pir-mode.el trunk/examples/benchmarks/overload.pir trunk/examples/namespace/namespace_dump.pir trunk/examples/past/01-sub.pir trunk/examples/past/four_plus_one.pir trunk/include/parrot/inter_call.h trunk/include/parrot/interpreter.h trunk/include/parrot/parrot.h trunk/languages/PIR/src/pasm/pasm_instr.pg trunk/languages/PIR/src/pasm/pasm_pmc.pg trunk/languages/cardinal/src/parser/grammar.pg trunk/languages/lolcode/src/builtins/math.pir trunk/languages/perl6/src/builtins/assign.pir trunk/languages/perl6/src/parser/actions.pm trunk/languages/perl6/src/parser/grammar-oper.pg trunk/lib/Parrot/Pmc2c/Method.pm trunk/lib/Parrot/Pmc2c/PMC.pm trunk/lib/Parrot/Pmc2c/PMC/Object.pm trunk/lib/Parrot/Pmc2c/PMC/delegate.pm trunk/lib/Parrot/Pmc2c/PMCEmitter.pm trunk/lib/Parrot/Pmc2c/Parser.pm trunk/src/dynpmc/foo.pmc trunk/src/dynpmc/rational.pmc trunk/src/inter_call.c trunk/src/inter_create.c trunk/src/oo.c trunk/src/ops/bit.ops trunk/src/ops/cmp.ops trunk/src/ops/core.ops trunk/src/ops/math.ops trunk/src/ops/ops.num trunk/src/ops/pic.ops trunk/src/ops/pmc.ops trunk/src/ops/string.ops trunk/src/pic.c trunk/src/pmc/array.pmc trunk/src/pmc/bigint.pmc trunk/src/pmc/complex.pmc trunk/src/pmc/default.pmc trunk/src/pmc/fixedpmcarray.pmc trunk/src/pmc/float.pmc trunk/src/pmc/hash.pmc trunk/src/pmc/integer.pmc trunk/src/pmc/multisub.pmc trunk/src/pmc/object.pmc trunk/src/pmc/pair.pmc trunk/src/pmc/resizablepmcarray.pmc trunk/src/pmc/scalar.pmc trunk/src/pmc/undef.pmc trunk/src/utils.c trunk/src/vtable.tbl trunk/t/compilers/pge/02-match.t trunk/t/examples/namespace.t trunk/t/op/bitwise.t trunk/t/op/calling.t trunk/t/op/lexicals.t trunk/t/pmc/bigint.t trunk/t/pmc/delegate.t trunk/t/pmc/integer.t trunk/t/pmc/n_arithmetics.t trunk/t/pmc/objects.t trunk/t/pmc/ref.t trunk/t/pmc/ro.t trunk/t/pmc/string.t trunk/t/stm/basic_mt.t Log: [pdd27mmd] Merging the pdd27mmd branch into trunk for r30235 to r31667. Modified: trunk/docs/pdds/pdd27_multiple_dispatch.pod == --- trunk/docs/pdds/pdd27_multiple_dispatch.pod (original) +++ trunk/docs/pdds/pdd27_multiple_dispatch.pod Sun Oct 5 04:30:01 2008 @@ -124,7 +124,7 @@ Return a function pointer to the best matching candidate for the current call arguments, and set up the interpreter preparing for invocation. This vtable -function calls C from the public MMD API, but +function calls C from the public MMD API, but may be changed to call C. =item set_integer_keyed_int, set_number_keyed_int, set_string_keyed_int @@ -189,7 +189,7 @@ =over 4 -=item Parrot_mmd_sort_candidate_list +=item Parrot_mmd_sort_manhattan Performs a multiple dispatch lookup on an array of subroutines. The call signature to match is pulled from the current interpreter, following the @@ -254,7 +254,7 @@ =head1 REFERENCES docs/mmd.pod -src/mmd.c +src/multidispatch.c src/pmc/multisub.pmc =cut
Re: [svn:parrot] r31385 - trunk/docs/book
Patrick R. Michaud wrote: I'm not at all arguing that this automatically means we should call them "methods", but at a conceptual level they certainly seem a lot like methods, and the vtable implementations contain references to things like SELF and STATICSELF that make them look awfully method-like. Regardless, I'll be happy to call them entries, methods, functions or whatever the consensus and documentation ends up saying they are. :-) They're all executable code entities of one sort or another. It's mainly a matter of choosing names that clearly mark different things as different. I picked "vtable functions" because they're directly invoked C function pointers (even the PIR vtable overrides are C function pointers that then do an override lookup). This differentiates them from from "methods" which are sub-like objects that take an invocant argument passed separately from the other arguments, are stored in the Class object, and can be invoked using the obj.'method'() syntax. There are plenty of other possible naming schemes, but this one works well enough for our purposes. Oh, and "vtable entries" was another common old way of referring to them, but I've been updating those to "vtable function" too, because "entry" seems a little vague (though, it's technically accurate, because the "vtable" is a whole set of functions (a "table" of functions) for the PMC, so a single vtable function is an entry in that vtable). Allison
Re: [svn:parrot] r31385 - trunk/docs/book
jerry gay wrote: 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. Yup. "vtable functions" is what I've been standardizing on everywhere I find the old "vtable method". Allison
Re: [svn:parrot] r31305 - in branches/pdd27mmd: include/parrot src
chromatic wrote: On Sunday 21 September 2008 03:17:18 [EMAIL PROTECTED] wrote: +dod_unregister_pmc(interp, sig_object); [...] That's far away from registering the PMC; is there a way to move them closer together? We could register it after it's returned from 'Parrot_build_sig_object_from_varargs' instead of as soon as it's created in the function. That'd only be a few lines away with the register and unregister the same function. But with the current garbage collector, I feel safer registering the signature object as soon as it's created. Allison
Re: throw oddities in pdd23
Stephen Weeks wrote: Commit 31294 implements this behavior. Can I get confirmation that it's correct? Just looked over the diff. Perfect. Thanks! Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: It's also a little unique that the "take/yield" can happen from called subs deep within the coroutine, and doesn't have to occur within the coroutine itself. That's a general characteristic of all the control exceptions: they can be caught by any outer dynamic scope, not just the immediate surrounding dynamic scope. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
jerry gay wrote: Patrick R. Michaud wrote: 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 ;-) I wouldn't mind. I mean, various languages will certainly have a type called "Hash", but that doesn't mean the core Parrot type needs to be. And really, it would fit in better with our general PMC naming scheme, and might open up the door for "AssociativeStringArray", "AssociativeIntegerArray", and "AssociativeBooleanArray". 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. H... yeah, I like that idea. Especially since 'break' and 'continue' mean different things in different languages and different contexts (like 'break' and 'continue' in gdb, for example). Allison
Re: New Parrot mailing list
Andy Dougherty wrote: I use NNTP. I much prefer the command-line news interface to Google Groups, but I guess I wouldn't go so far as to say I would have "difficulty" switching to a regular email subscription. Or, to put it another way: If there were an NNTP interface, I would definitely use it, but I wouldn't want anyone else to be stuck implementing and maintaining it just for my occasional use. I wonder why no one has developed a command-line NNTP-like interface for email? Maybe following mailing lists via RSS and feed readers has satisfied the need enough that no one got around to it? This looks interesting, if anyone's motivated: http://www.methodize.org/nntprss/ Allison
Re: New Parrot mailing list
James E Keenan wrote: That's false. I replied to the newsgroup, which is mirrored by the mailing list. Whenever I've posted to the list (independent of posts to RT), the posts have been mirrored by the mailing list. You asked we to "forward this on," so I did exactly what I've done for hundreds of other posts over the last two years. Makes sense. There's likely a delay from the time a post goes to the newsgroup before it makes it to the mailing list, so I replied to the direct message (where you CC'd the newsgroup), long before it hit the mailing list. (IIRC, I've been caught by this before.) Thanks for forwarding it on, exactly as I asked. :) Allison
Re: New Parrot mailing list
James E Keenan wrote: > I set up the Google Group, because I know a number of people are using it. Can I see a show of hands of people who are only using NNTP and would have difficulty switching to a regular email subscription or Google Group? (I can't send to a newsgroup from my email client, so Jim, could you forward this on?) And only just now found that Jim had CC'd the parrot mailing list as well as the news group that I wasn't able to reply to. I wouldn't be sad to see NNTP go. Allison
Re: New Parrot mailing list
Patrick R. Michaud wrote: On Thu, Sep 18, 2008 at 11:00:31AM +0200, Allison Randal wrote: We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). Will we also be able to get svn commits to the new mailing list, or at least to *a* mailing list? The svn commits are a different mailing list, which will stay where it is until we move the subversion server to parrot.org. (Then the new commits mailing list will be [EMAIL PROTECTED]) The new mailing list will not automatically update tickets in the RT queue, for that CC <[EMAIL PROTECTED]> on the message. Wouldn't it be possible to have the new mailing list manager check for [perl #n] in the message subject and automatically forward it (controlling for loops as appropriate)? Yes, almost certainly. But we're also moving to a new ticket queue, so I'd rather not invest the time in hacking up the new infrastructure to interface with the old infrastructure. There's a question on the new system of whether we should continue to have tickets forward to the main development list like we do now, or have them forward to a separate 'parrot-tickets' mailing list like we do with commit log messages. What seems best to you all? (If we do separate the lists, anyone has the option to have them all file into the same mail folder, it just gives others the option of separating ticket traffic from regular messages.) Allison
Re: Parrot 0.7.1 "Manu Aloha" released
Patrick R. Michaud wrote: I sent the appropriate patch to the webmaster, but it hasn't been applied yet (and I lack a commit bit for the parrotcode.org site). Once that's applied, the url should be fixed. Thanks, applied. I also updated parrot.org. Allison
New Parrot mailing list
The new Parrot mailing list (replacing perl6-internals/parrot-porters) is <[EMAIL PROTECTED]>. If you were subscribed to the old list, you're now subscribed to the new list. If you were a digest subscriber to the old list, you're now a digest subscriber to the new list. More information about the list and public archives are available at: http://lists.parrot.org/mailman/listinfo/parrot-dev A Google group for the list has been created at: http://groups.google.com/group/parrot-dev We'll likely end up with messages scattered between both lists for a little while, but the perl6-internals/parrot-porters addresses are deprecated and will be disabled after a sensible deprecation cycle (and after the automatic RT posts have been shifted to parrot-dev). The new mailing list will not automatically update tickets in the RT queue, for that CC <[EMAIL PROTECTED]> on the message. Allison
Re: throw oddities in pdd23
Stephen Weeks wrote: This has now been committed to trunk. I'm pretty sure that I updated every exception handler in the tree. Apologies if my comments on this thread and update to the exceptions PDD weren't clear. The resume continuation should continue to live within the exception object, not be passed as a separate argument to the handler. The change to remove the exception message string as a separate parameter to the handler is correct, thanks for making that. -- (The current text of PDD23 is accurate:) Active exception handlers (if any) will be invoked with I as the only parameter, and the return continuation stored within that exception object. -- Please revert the branch merge or make another update. Thanks! Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: What's the language-agnostic term for this, then? Well, 'gather' is basically a clever use of a coroutine, and 'take' is basically a 'yield'. But, what's unique about the construct is that it aggregates the results. So, 'gather' is an "aggregating coroutine" and 'take' is an "aggregating yield". To allow for a distinction in the control exception types, call it 'CONTROL_YIELD_AGGREGATE'. "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. Allison
Re: ExceptionHandler enhancement proposal
Bob Rogers wrote: Yes, once we have the ability to have exception handlers only handle specific types of exceptions, then they'll allow all other types of exceptions to pass through. (Which means we won't end up with the infinite exception handler loops we currently get if exception handlers aren't disabled as soon as they're used.) Are you sure? What if the body of a catch-all error handler signals an error? Methinks the handler must truly be taken out of scope before it is invoked in order to avoid infinite exception handler loops. Yes, of course a catch-all exception handler will always catch all exceptions. But, a catch-all exception handler is intended to catch all exceptions, and therefore can't make any assumptions about the exception object other than the defined standard exception interface. The problem now isn't that the same exception handler is being called twice (once on the first exception, and once on the exception thrown from within the handler). The problem is that the exception handlers were written assuming that they'd only ever get one kind of exception. When they get a different kind of exception the second time, they aren't expecting it, and make some terrible mistake, which throws another exception, but they don't know how to handle that one and make a terrible error and throw another exception, and so get themselves into an infinite loop. The 'can_handle' method is the only required interface for checking whether a particular handler will accept a particular exception. All other checks should be hidden behind that method. Hmm. The only way to find out whether a Lisp handler will handler a given exception is to call it; if the answer is yes, it will never return. So I'm hoping a 'can_handle' method that either returns false or transfers control to somewhere else can be made to work. For that, you would implement a catch-all handler (completely ignoring 'can_handle'), and then rethrow any exceptions you can't handle. Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: I'm not sure about this last comment -- I think I can imagine that other language implementations (including new ones we haven't thought of yet but suddenly becomes possible with Parrot) might want to make use of gather/take semantics if they're readily available -- especially because they can be very hard to otherwise implement when they're not readily available. And compile-time constants are pretty cheap. :-) Absolutely. But for that it shouldn't be called "CONTROL_TAKE", because that's meaningless outside Perl 6. So, I think we can't always say "oh, only one dynamic language needs this feature so it shouldn't be global" -- we need to also consider those dynamic-languages-yet-to-be-written because Parrot is such an incredible platform for creating them. Yes, that's not the principle. The principle is that global things should be language-agnostic, and not use terminology that's confusing to all the other languages. Allison
Re: [perl #46651] [TODO] [C] Make a better interface for hash creation
Christoph Otto via RT wrote: On Mon Oct 22 07:01:59 2007, pcoch wrote: In src/pmc/hash.pmc:thaw() there is the todo item: /* TODO make a better interface for hash creation ... do this. Where do we want to go with this? Ax the ticket. Vague plans for future change aren't useful. Allison
Re: [perl #56468] [TODO] use more VTABLE to avoid subclassing errors.
Vasily Chekalkin wrote: And another question. Should all lvalue occurences of PMC_*_val(SELF) be replaced with VTABLE_set_*_native? (Except for VTABLE method implementation of cause) In general, yes. You'll have to check each PMC to see if they have the appropriate VTABLE_set_*(_native) vtable function defined. (Ultimately, the storage for these PMCs should all be changed to ATTRs and the accessors to GET_ATTR_* and SET_ATTR_*.) Allison
Re: [svn:parrot] r31049 - in trunk: include/parrot languages/perl6/src/builtins languages/perl6/src/parser languages/perl6/t
Patrick R. Michaud wrote: On Sat, Sep 13, 2008 at 01:55:05PM -0400, Will Coleda wrote: +CONTROL_TAKE } exception_type_enum; Tcl can currently deal with OK, CONTINUE, BREAK, ERROR, and RETURN. What's TAKE? TAKE is like CONTROL_RETURN except that it signals that we expect execution to continue after the point of the TAKE. It's quite similar to a .yield operation for coroutines. Would CONTROL_YIELD make more sense? I would have known what yield meant. It might be a bit misleading, because it doesn't actually correspond to a .yield (and thus I can envision CONTROL_YIELD as yet another exception type). I'm still brainstorming ways to get the gather/take semantics we need by using Parrot's .yield, but so far I haven't come up with a good way to do it. Eventually we'll need to stop defining exception types as a global enum, and let individual languages define their own. EXCEPTION_TAKE really doesn't make sense for anything other than Perl 6. Not today, but someday. Allison
Re: [perl #58794] [PATCH] remove the obsolete .past search in try_bytecode_extensions
Reini Urban (via RT) wrote: Old: Guess extensions, so that the user can drop the extensions leaving it up to the build process/install whether or not a .pbc, .pasm, .past or a .pir file is used. New: Search only for .pbc, .pasm, and .pir in that order. The .past file-extension is *long* deprecated said particle on #parrot. Thanks, approved for application in trunk. Allison
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
NotFound wrote: By the way, as mentioned in other thread there is a problem with plain %s in parrot printf-alike functions. It does not handle well a NULL c string. This must be fixed. And before, given the current implementation, the behavior of string_make and his successor in the strings pdd, when receiving a NULL c string must be documented and implemented, or we risk to plague the code base with lots of more workarounds. This should be submitted as a separate ticket with example code/error messages. Allison
Re: [perl #58236] [TODO][PDD19] make decision on open issue on .return directive in pdd19
Klaas-Jan Stol wrote: Allison: I made the following changes in pirc/new: .arg -> .set_arg .result -> .get_result .return -> .tailcall (in context of .return foo() , which thus is now: .tailcall foo() ) .return -> .set_return (in long-style returning : .begin/end_return .yield -> .set_yield ( in long-style yielding : .begin/end_yield) From your answers in your previous reply I deduce you support such changes. Can you reconfirm, then I'll make the appropriate changes in PDD19. Thumbs up, thanks! Allison
Re: [perl #39313] [TODO] or [BUG] improve PMC compiler
Klaas-Jan Stol wrote: This ticket doesn't seem to be closeable as is.Would it be good enough if pmc2c.pl spit out an error on the above definition, or is this even something that pmc2c.pl should be concerned about? The goal of the ticket should be for pmc2c.pl to entirely parse the input PMC files. Either passing through uncooked C, or doing transformations. Silently dropping code on the floor is not acceptable. Pmc2c is just a series of regular expressions. It looks for specific patterns, and if it finds them, builds relevant C code out of them. It has no ability to check for arbitrary syntax that *doesn't* match a pattern. It's a preprocessor (macro substitution), not a language parser. What could be done is have it dump anything leftover after the extraction into the resulting C file. Then you'd get a C error on compilation. wouldn't a PGE-based compiler be helpful? Yes, certainly desirable, but we're not shooting for that level of bootstrapping in the 1.0 release. When we eliminate all dependencies on Perl, we'll move over to a PGE-based compiler, and keep the generated C code checked into the repository like we keep the generated flex/bison files checked in. Allison
Re: ExceptionHandler enhancement proposal
Stephen Weeks wrote:
ExceptionHandler currently has a can_handle method that checks whether
the EH has been disabled or not. I propose adding some attributes to
store the minimum severity the EH will handle and the list of exception
types the EH will handle, methods to set and get these properties, and
extend can_handle to check the exception against these properties.
Yes, this was spec'd but not yet implemented, and can be implemented
now. ('can_handle' was intended to be expanded for this.)
Once this is in place, I understand we can remove the "disable exception
handler" functionality currently in place and replace it with setting
handled types appropriately.
Yes, once we have the ability to have exception handlers only handle
specific types of exceptions, then they'll allow all other types of
exceptions to pass through. (Which means we won't end up with the
infinite exception handler loops we currently get if exception handlers
aren't disabled as soon as they're used.)
Questions that have been raised about this proposal on IRC include:
* Minimum severity, range of severities, list of severities?
Minimum and maximum (which define a range if both are set). Let's skip
selective lists ("I'll handle severity 2, 8, and 42" is less useful).
* List of types, or single type?
- Note that you could create multiple EHs that refer to the same
label or sub that handle different exception types.
A list of types. Ultimately exception types will likely be more than
just integer types, but the integer types will do for now.
Also, the 'can_handle' method can be overloaded to check *any* attribute
of the exception to decide if that handler can handle it. We may want to
canonize this by allowing Parrot's ExceptionHandler PMC to store a sub
object that is run by 'can_handle' on the exception to determine if it's
appropriate.
Any proposals on naming or other API considerations?
The 'can_handle' method is the only required interface for checking
whether a particular handler will accept a particular exception. All
other checks should be hidden behind that method.
Any other thoughts or comments?
Make it so, Mr. Crusher. :)
Allison
Re: [perl #58866] calling a PIR sub with 206 params segfaults parrot
Christoph Otto (via RT) wrote: I was looking at #45357 ([TODO] Which exception should be thrown with register overflow?) and found that Parrot doesn't like subs with more than 205 params. This seems like a perfectly reasonable limit, but perhaps the behavior could be more user-friendly.* Maybe an EXCEPTION_ERR_OVERFLOW should be thrown here instead? Using the attached patch to reproduce: $ perl mktoomanyargs.pl>toomanyargs.pir && ./parrot toomanyargs.pir Segmentation fault (core dumped) *On the other hand, we may choose to be overtly hostile to users who do things like call subs with 206 parameters. It's a design decision. 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. Allison
Re: [perl #58886] [BUG] :named argument handling in PIR
Will Coleda (via RT) wrote: [...] I would expect one of the following things to happen here, either: - an error is generated when test2 is parsed because there is no name for the named parameter, or - test2's blarg .param should default to being named 'blarg', so both calls should work identically. Even more confusing, this code: Yes, we need better error checking and better error reporting in named argument handling. We need a general invocation refactor, but can do it in small stages. Let's go with defaulting to the same name as the .param on the bare :named. Allison
Re: throw oddities in pdd23
Patrick R. Michaud wrote: PDD23:67 has: : =item B> : : Throw an exception consisting of the given I PMC. Active exception : handlers (if any) will be invoked with I as the only parameter. : : : =item B [ , I ]> : : Throw an exception consisting of the given I PMC after taking : a continuation at the next opcode. When a I is passed in, : it will use that instead. Active exception handlers (if any) will be : invoked with I and the given continuation as parameters. This looks weird in a couple of respects. The second C opcode shows I as an optional parameter, which would seem to be in conflict with the first form (i.e., they end up being identical if I is omitted). Next, reading the above makes it look as though exception handlers can sometimes be invoked with a single parameter (the exception) and sometimes with two parameters (the exception and a continuation). Perhaps it would be better to have a consistent calling interface? (I do suppose we could say that the second parameter is always optional.) I suspect much of the confusion comes from when C was (apparently) eliminated in favor of a single C opcode, but pdd23 wasn't made internally consistent. Yes, C and C were collapsed into one opcode, and left some editing junk behind. I just changed it to one entry for C. Also, note that the single-argument C opcode is currently doing more than simply cause exception handlers to be invoked -- it's also takes a resume continuation and stores it in the I PMC itself (src/ops/core.ops:817). This would seem to be in conflict with the next sentence at pdd23:80 : : Any type of PMC can be thrown as an exception. Clearly we cannot use the single-argument C on a PMC that doesn't have a "resume" attribute for us to store the resume continuation. Personally I like the idea that "any PMC can be thrown as an exception", which would seem to argue against forcing resume continuations into the thrown PMC (which might not have a slot for them). So, rather than saying that anything thrown as an exception contains its resume continuation, perhaps we should say that all handlers are invoked with the exception and resume continuation as arguments, and the single-argument throw simply takes a continuation at the next instruction to pass to the handler(s). Alternatively, we could say that C only places a resume continuation into PMCs that "does exception", but somehow I find this less desirable than the above approach. Okay, PDD cleaned up. The code to directly support throwing any arbitrary type would require significant circumlocution (read: inefficient, difficult to maintain), so it's not desirable. It's not just a matter of removing the return continuation from the exception object, we'd have to remove all metadata from the exception object (stacktrace, payload, handler iterator, type and severity information), and either pass all that information as arguments throughout the system (expensive and error-prone) or store it as global state information (error-prone, and bad for a clean implementation of concurrency). But, an individual HLL can store any arbitrary PMC value as the payload of an exception object, and act as if it had thrown an arbitrary PMC as an exception. Allison
[svn:parrot-pdd] r31186 - trunk/docs/pdds
Author: allison Date: Tue Sep 16 13:12:27 2008 New Revision: 31186 Modified: trunk/docs/pdds/pdd23_exceptions.pod Log: [pdd] Clarifying the description of the 'throw' opcode, and the necessary interface of thrown exceptions. Modified: trunk/docs/pdds/pdd23_exceptions.pod == --- trunk/docs/pdds/pdd23_exceptions.pod(original) +++ trunk/docs/pdds/pdd23_exceptions.podTue Sep 16 13:12:27 2008 @@ -64,27 +64,17 @@ Pop the most recently pushed exception handler off the exception handler stack. -=item B> - -Throw an exception consisting of the given I PMC. Active exception -handlers (if any) will be invoked with I as the only parameter. - - =item B [ , I ]> -Throw an exception consisting of the given I PMC after taking -a continuation at the next opcode. When a I is passed in, -it will use that instead. Active exception handlers (if any) will be -invoked with I and the given continuation as parameters. - -Any type of PMC can be thrown as an exception. However, if there's any chance -of cross-language calls -- and in a Parrot environment, cross-language -operations are kind of the point -- then you should be prepared to catch -exception classes you would never have thrown yourself. - -That said, it is recommended that any thrown PMC that can possibly escape your -private sandbox should meet the minimal interface requirements of the -C class, described below. +Throw an exception consisting of the given I PMC, after taking a +continuation at the next opcode. When a I is passed in, it will +use that instead of generating a new continuation. Active exception handlers +(if any) will be invoked with I as the only parameter, and the +return continuation stored within that exception object. + +PMCs other than Parrot's Exception PMC may also be thrown, but they must +support the interface of an Exception PMC. An HLL may implement throwing any +arbitrary type of PMC, by storing that PMC as the payload of an Exception PMC. Exception handlers can resume execution immediately after the C opcode by invoking the resume continuation which is stored in the exception object.
Re: [svn:parrot] r30941 - branches/pdd27mmd/src
NotFound wrote: On Wed, Sep 10, 2008 at 9:21 AM, Allison Randal <[EMAIL PROTECTED]> wrote: chromatic wrote: That C string leaks. We should have a diagnostic printf which supports the %Ss format we use in exception formatting strings. We have one, it's called PIO_fprintf. But, it's only used once in the repository, in an STM macro. We have more: PIO_printf, PIO_eprintf, Parrot_printf, Parrot_eprintf and Parrot_fprintf. The Parrot_ ones are a wrapper around the PIO_s, with added check for extern usage, and that does not need #include io files. Yes, to be more accurate, we have a whole range of PIO functions. But, the fact that they're used so rarely makes me doubt whether they're particularly reliable. The eprintf ones are adequate for diagnostic messages. But note that his usage with a NULL interpreter argument is flawed, only adequate for plain strings. But if you have a parrot string surely you have a parrot interpreter. Aye, that part shouldn't be a problem. Allison
