Patrick R. Michaud wrote:
I'm curious... is this code implying that any PMC class that
may be subclassed in PIR needs to explicitly check for when
that is happening and delegate to the proxy somehow?
Originally that was the reason for the
if (PObj_is_object_TEST(SELF)) ... portion of the
Resolved in r22089 with a patch from Juan Natera (Pabellon) at the PPW
Hackathon.
A good place to start is by adding POD to the tutorial files already in
the directory. I added POD to many, but not to all. In r22071, I added a
one sentence descriptions this illustrates X to the files that had no
POD, which could be expanded into full descriptions.
Thanks! Applied to the pdd15oo branch in r22075, to be rolled into trunk
along with the rest of the branch.
Leopold Toetsch wrote:
This implies (for me), that whatever silly morph requests like above would be
issued, a PMC always has the needs of 'one size fits all'. This will preclude
any optimzations of creating smaller spezialised PMCs as well as it seems to
going the PMC_data indirection hell
Bob Rogers wrote:
I could only find a few find_type hits in t/**/*.t; these are now fixed.
(I assume this is because I'm late to the party.)
Great contributions all around. Thanks everybody!
All of the rest (besides the implementation of the op itself) seems
to be in documentation.
James E Keenan wrote:
Allison Randal wrote:
So, how about we make both --fatal-step and --verbose-step accept
either a step number or step name.
Didn't I hear someone recently remark, Simplification is a good idea?
;-)
This is doable, but it will take me at least 9 separate test files
chromatic wrote:
On Friday 05 October 2007 14:02:32 [EMAIL PROTECTED] wrote:
Modified: branches/pdd15oo/src/pmc/namespace.pmc
===
=== --- branches/pdd15oo/src/pmc/namespace.pmc (original)
+++
Klaas-Jan Stol wrote:
I think it should be something like this:
/* RT46099 Check we don't already have this parent. */
/* If we have already added a method with this name... */
if (VTABLE_exists_keyed_str(interp, _class-all_parents,
VTABLE_name(interp, parent))) {
Allison Randal wrote:
Patrick R. Michaud wrote:
In pdd15oo, there seems to be an issue about using load_bytecode
to load :method subs after a class has been created.
Working now for both load_bytecode and the eval case.
One problem: with this change, every named method is inserted
Klaas-Jan Stol (via RT) wrote:
a code snippet like this:
the_value = new 'Type'
the_value = 42
is in my eyes not clear. It seems as if the first line creates an object,
and it seems to be discarded on the second line, as some value is assigned
to the_value.
The key thing to keep in mind is
It's a timing issue. Methods are currently loaded into the class from
the namespace when the class is created. So, if you call load_bytecode
after newclass, it helpfully inserts the methods into the namespace, but
the class doesn't pick them up. (This has been on my radar for a while,
I just
It's worth exploring, and may lead to other experiments in parallel GC..
Parrot allows multiple different GC systems, so you shouldn't encounter
significant problems on the Parrot side, but if you do, let us know and
we'll fix them. I don't know if Harmony's parallel GC was designed to be
Patrick R. Michaud wrote:
At any rate, pgc.pir and Perl6Grammar.pir (used to compile
grammars into PIR) both want the ability to compile and install rules
at runtime, so we really need the eval version to work before
we can progress much. Either that or I'll come up with a workaround
for
Patrick R. Michaud wrote:
In the case of dynamically generated code, using add_method is
somewhat more challenging because we can't perform the add_method
until after the PIR source has been compiled and loaded into the
namespace.
Aye. There's a dividing line that's more a matter of style
Stefan Parvu wrote:
What is the future of Parrot and GC systems ? Are we gonna have in near
future similar GCs what the JVM has at this moment:
- serial collector
- parallel collector
- concurrent collector ?
The design document for Parrot's GC system is scheduled to be completed
Jan
Patrick R. Michaud wrote:
In pdd15oo, there seems to be an issue about using load_bytecode
to load :method subs after a class has been created.
Working now for both load_bytecode and the eval case. Turns out to be
very few lines of code to make it work. I also added Patrick's examples
as
James E Keenan wrote:
But I didn't actually implement this. What I actually implemented was
specifying the configuration step name *as an alternative to* specifying
a portion of the step's description. While this satisfied particle's
original request, it led to some ugly code in
I just haven't gotten to enabling arrays as a valid input. You'll have
it this afternoon.
Allison
Patrick R. Michaud wrote:
How does one create a new class with a name determined dynamically
at runtime?
For example, suppose I have a string like 'PGE::Perl6Grammar', and
from that I want to
Also, need to change license reference in editor/pasm.el. (It currently
gives a URL for Artistic 1.0.)
Allison
Patrick R. Michaud wrote:
Slowly PGE and PGE::Perl6Regex are being updated to work with pdd15oo.
What sort of changes do you end up making? It shouldn't touch anything
other than the lines of code creating a new class and instantiating a
new object. (And really, it shouldn't even touch
Patrick R. Michaud wrote:
It did occur to me this morning that we can stick with the
flat-namespace model that PGE and other tools have been
using up-to-now, and make the switch to using multilevel namespaces
sometime later. Either way there's going to be a big conversion
cycle involved
Patrick R. Michaud wrote:
How does one create a new class with a name determined dynamically
at runtime?
For example, suppose I have a string like 'PGE::Perl6Grammar', and
from that I want to create a ['PGE';'Perl6Grammar'] class. The code
$ cat z1.pir
.sub main :main
$S0 =
Allison Randal wrote:
The two remaining big things are PGE and multiple dispatch,
and then test cleanup.
The MMD tests are all passing now, so I'm working on test cleanup.
Allison
Yes, NULL should never make it to the PIR level, only PMCNULL should.
I'll dig into this code example next.
Will Coleda wrote:
I'm assuming PMCNULL is the good (parrot) kind of null, and null is the
bad (well, to us, anyway) (C) kind.
I would hazard a guess that anything that is returning
Patrick R. Michaud wrote:
When looking at a trace output (-t1), what's the difference
between PMCNULL and (null)? For example:
$ cat y.pir
.namespace ['Foo']
.sub main :main
$P1 = get_class ['Foo']
$P2 = $P1
$P0 = get_hll_namespace ['Foo']
$P1 = get_class
Bernhard Schmalhofer via RT wrote:
languages/m4/README:15
What is the legal situation for Parrot m4?
Personally I would like to put 'languages/m4' under Artistic 2.0.
But I'm not sure whether this isn't a derived work. I implemented Parrot
m4 by:
i. Looking at the GNU m4 source code
ii.
Jerome Quelin wrote:
here's a patch for examples/streams.
if you ack it, i'll apply it (i should still have the commit bit).
Looks great! Go ahead and apply it to the pdd15oo branch.
Thanks!
Allison
Patrick R. Michaud wrote:
On Tue, Oct 02, 2007 at 07:19:30AM -0700, jerry gay wrote:
On 10/2/07, Klaas-Jan Stol [EMAIL PROTECTED] wrote:
[...]
but that fails with Class 'STMQueue' doesn't exist
[...]
since the pdd isn't clear on the return value from get_class when a
class isn't found, i'll
Jonathan Worthington wrote:
Hi,
I've only been notable in Parrot for the last month by my absence. It's
partly been down to a lack of time, though even when I've had the time
I've just not had the energy or been far from in the right state of mind
to have the concentration Parrot guts needs.
Patrick R. Michaud wrote:
To be consistent with Hash and some of the other aggregates, the
set opcode should return PMC null _only_ when fetching a PMC from
an aggregate, if fetching a string or number it should return
the empty string or zero.
$P0 = new 'ResizablePMCArray'
$P1 =
Jerome Quelin wrote:
other question: which directory has the higher priority for you?
They all need to be fixed before we roll the branch back into the trunk,
so they're all equally important.
Allison
Klaas-Jan Stol (via RT) wrote:
Hi,
This proposal is about resolving method names: bare words or quoted
it might be that i'm not well informed on this issue, so please correct me
where I go wrong.
IMCC currently allows for method call syntax like this:
foo.bar()
foo.bar()
Both invoke the
My goal was to wrap up the pdd15oo branch by the end of September. We're
quite close. The two remaining big things are PGE and multiple dispatch,
and then test cleanup. Thanks to chromatic and particle for their work
on the tests.
I've been giving chromatic small tasks to work on, which seems
Nuno 'smash' Carvalho wrote:
Still working on it. Sorry, but haven't had much free time lately, but
i'll try to finish this ASAP.
Great.
KJS, you might take a pass over it too. You've had a lot of good cleanup
suggestions.
Allison
[EMAIL PROTECTED] wrote:
The big overall cunning plan is to remove .local for this purpose
(defining labels), and to use .local ONLY for declaring variables.
Then, once all .local (in macros) are replaced by .label, we can
start replacing .syms by .local, so that .sym can be removed
from the
Patrick,
I've reworked the PMCProxy system so it actually works now. (Not just
for PGE, it was causing other failed tests in other systems.) This takes
care of your problem with using Hash's keyed set_* and get_* operations
in its subclass PGE::Match.
I also fixed a few compile errors that
Klaas-Jan Stol wrote:
Hi,
I've spent some time on refactoring imcc's parser and lexer a bit (only
minor) and I guess the time has come for some design decisions, if possible.
Currently, IMCC handles both PIR and PASM. smash++ suggested that PDDs
should be finished for both PASM and PIR.
Once
Patrick R. Michaud wrote:
This ended up being discussed on IRC -- just to complete this thread
I'll note that we settled on the 'typeof' opcode to return the
class (or PMCProxy) object for a PMC:
$P1 = typeof $P0# $P1 is class object / PMC proxy of $P0
And committed on the pdd15oo
Klaas-Jan Stol (via RT) wrote:
I propose to remove the optional comma for .sub flags. [...]
sub :load :init :main
# ...
end
Agreed and approved. Please take the usual deprecation steps, and make a
quick note of the syntax change in the draft PIR PDD
(docs/pdds/draft/pdd19_pir.pod).
Jonathan Worthington wrote:
PMC* get_attr_keyed(PMC* key, STRING* idx)
void set_attr_keyed(PMC* key, STRING* idx, PMC* value) :write
_keyed is consistent, but not particularly descriptive - it's not
*really* a keyed access that we're doing here. _super maybe is better,
though I'm not sure I
Paul Cochrane wrote:
=item *
Under the Compiler PMC API section within the explanation of the
Cload_library method there is the text:
On failure, an exception is thrown. {XXX - I'd settle for a universal error
pmc interface. Hm, sounds like a new pdd. TODO}
We've got an exceptions
[EMAIL PROTECTED] wrote:
I already added it to DEPRECATED.pod before the last release and
removed it afterwards; it's gone already.
Awesome. Many thanks!
Allison
James Keenan (via RT) wrote:
In the meantime, however, we can provide users with an --abort-step
option to Configure.pl. This would work in a manner analogous to the
current --verbose-step option, i.e., the user gets to name one and
only one step whose failure causes Configure.pl to
Nicholas Clark wrote:
On Thu, Sep 20, 2007 at 02:13:11PM -0700, chromatic wrote:
Hoist that declaration up a bit, or C89 compilers will complain. Is there a
GCC warning that we could enable here?
Ah, the beauties of cut-n-paste (which is evil, but allowed in the
process of a refactor).
Andy Dougherty wrote:
I had two questions:
1. Is the order of elements in struct PMC deliberate?
Nope, just the order I copied them in when collapsing the struct.
struct PMC {
Parrot_UInt flags;
UnionVal cache;
VTABLE *vtable;
kjs wrote:
In order to keep PIR syntax clean, I propose to remove the - syntax for
method calls, as it is the same as the dot-notation.
Also agreed. Get it into DEPRECATED.pod now so we can remove it after
the next release.
Allison
Andy Lester wrote:
On Sep 18, 2007, at 9:04 AM, [EMAIL PROTECTED] wrote:
-FUNCDOC: mark_special
+=item Cmark_special
This is a perfect example of why I want us to use FUNCDOC and not POD.
Who says that we are presenting functions as =item lists? Why is it
presented in C? =item
Andy Lester wrote:
We decided to remove FUNCDOC in May soon after it appeared. At the time
it only appeared in a couple of files, so I was surprised to it now
scattered over a couple of dozen files.
Who is we? I was entirely unaware of it. I've yanked POD on every
file that I've headerized,
Andy Lester wrote:
The FUNCDOC hoohah points out something that has been bugging me for a
while and that now is actionable: I don't know WTF is going on any more.
I'm very out of touch, even though I sometimes sort of try to keep an
eye on what's going on. It's no way to be involved in a
PGE relies on an assumption of the old object metamodel that's no longer
valid: that defining a method in the namespace of the class will allow
you to call it as a class method. More specifically, PGE::Match is a
subclass of Hash. It defines a method 'new' in the PGE::Match namespace,
and then
Paul Cochrane (via RT) wrote:
(DEPRECATED: The list as a whole may be surrounded by parentheses.)
Yes, this would remove the parens from the first string argument to
set_args, set_returns, get_params, and get_results. So the pdd would become:
set_opcode flags0, flags1, ..., flagsN,
jerry gay wrote:
i'd rather see FUNCDOC stay. it allows us to specify just the parts of
the documentation that we need to, and generates the rest from the
source. this allows us to skip
=item void myfunc(does_not, match, source)
because it's generated from the source, so is always up to
Patrick R. Michaud wrote:
The one I'm likely to want to go with is to follow Perl 6's model,
which is that 'new' will be a method on a PGE::Match proto-object.
Indeed, I think that PGE also relies on Match objects themselves
being able to respond to 'new'.
So, the model I'd expect to
I agree with backing out the change. Not for the fact that it causes
Configure to exit, but for the fact that it leaves Configure no control
over whether it exits. Better to return a value reporting lack of
success, that Configure can use to exit if it chooses to do so. (I'll
say more in reply
For perspective, keep in mind that we will eventually be refactoring the
Perl 5-based configure system anyway, to remove the dependency on an old
install of Perl 5. So, the behavior of the current prototype
configuration system is more important than the internal structure of
the code.
James
The hash opcode and vtable function are deprecated in PDD 17. (Neither
are used or useful.)
I just launched PDD 17 out of the drafts directory, which marks it as
ready for implementation. Jonathan Worthington and chromatic have
volunteered to work with me on implementing the refinements to the PMC
design.
Allison
James Keenan via RT wrote:
I've been discussing with Alan Rocker a research project in which we
would develop a table or spreadsheet that maps all the Configure.pl
command-line options to the configuration steps in which they are, can
be, cannot be, or should not be used. We're doing this as
Paul Cochrane wrote:
=item *
Under Language Standards and Portability there is the todo item:
{{ RT#45359: Enumerate all other non-C89 assumptions that Parrot
depends on. }}
Currently we have such assumptions as:
In addition, C code may assume that any pointer value can be coerced to
Klaas-Jan Stol (via RT) wrote:
I propose to change this into:
HLL_map Integer, TclNumber
Agreed and approved.
for reasons of consistency (and aren't the type id's thrown out completely?)
Yup. They're headed toward complete and permanent removal (kicked the
bucket, shuffed off 'is mortal
I just checked in (r21293) a substantial change to the PDD 17 section
PMCs and high-level objects, detailing the inheritance strategy from
low-level PMCs to high-level classes.
We've been poking around the edges of the problem since we started the
new metamodel, but this is a radical
Andy Dougherty wrote:
Trivial example: Configure.pl currently supports many incompatible ways
to say no (excerpts from Configure.pl --help)
--nomanicheckDon't check the MANIFEST
--cgoto=0Don't build cgoto core - recommended when short of mem
--without-gdbm
Nicholas Clark wrote:
On Thu, Sep 13, 2007 at 10:37:59PM -0700, Allison Randal wrote:
The conclusion after a good bit of discussion earlier this year was that
returning a status object for every synchronous operation was far too
heavyweight. Exceptions don't get a high vote as an alternative
chromatic wrote:
On Thursday 13 September 2007 18:17:21 [EMAIL PROTECTED] wrote:
-where Cobj is a pointer to a Cpobj_t structure:
+where Ccache is a pointer to a CUnionVal union:
I'm not sure that's true. *vtable is a pointer to a VTABLE, but I believe
that the UnionVal struct members get
Klaas-Jan Stol (via RT) wrote:
I propose to remove the bareword method to be recognized as :method.
Agreed.
Allison
Klaas-Jan Stol (via RT) wrote:
I think it'd be good to make a decision on this: either remove the .global
directive and the associated grammar rules (making it a few lines shorter),
or implement it.
Kill it. The notion of globals (as stored in the namespace) in Parrot
has been greatly
Klaas-Jan Stol (via RT) wrote:
Therefore, in order to keep IMCC simple and remove syntax redundancy, I
propose to remove the .pcc_sub directive from IMCC.
Agreed. If there are any remaining differences, they're implementation
artifacts and should be merged.
Allison
On Sep 12, 2007, at 6:21 PM, Will Coleda wrote:
On Sep 12, 2007, at 11:38 AM, Klaas-Jan Stol (via RT) wrote:
I propose removing the .sym directive for normal cases (not for the
macro
stuff).
If we're doing that, I think it would make sense to
- remove .sym everywhere.
- change the thing
Klaas-Jan wrote:
On Sep 13, 6:18 am, [EMAIL PROTECTED] (Patrick R. Michaud) wrote:
On Wed, Sep 12, 2007 at 09:07:00AM -0700, Klaas-Jan Stol wrote:
I propose to make IMCC a bit stricter and have it enforce to use the
appropriate closing directive. So, close .pcc_begin_return with a
Paul Cochrane wrote:
Therefore, I
thought it'd be a good idea to stimulate some discussion on list, so
that something can be distilled from this to help out our architect
and those brave enough to implement the design :-)
Excellent. Many thanks.
=item *
In the Composition subsection of the
We will deprecate all types for .local other than string, num, int, and pmc.
Allison
I'll be attending the Pittsburgh Perl Workshop to present and host a
Parrot hackathon:
http://pghpw.org
October 13-14, 2007
I'll be on hand to help new contributors get started, answer questions,
and work on code. October 13th also happens to be the Parrot bug
squashing day for the month
Both the old and new metamodels allow you to set and get an attribute
for a parent class that has the same name as an attribute in the child
class (Perl 6 and .NET both use this feature in different forms). The
old metamodel used this syntax:
# Foo has an attribute named 'j'
newclass $P1,
Andrew Dougherty wrote:
Meanwhile, this patch should clean up some bit rot and document it all a
little better.
Thanks, applied.
Allison
jerry gay wrote:
On 8/29/07, Patrick R. Michaud [EMAIL PROTECTED] wrote:
On Wed, Aug 29, 2007 at 02:44:13PM +0200, Paul Cochrane wrote:
Hi all,
I've recently added a test to the coding standards tests which checks
for a copyright statement, and that the copyright date is up to date.
After a
PMCNULL is a singleton, so PMCNULL always equals PMCNULL.
Undef allows morphing and interesting values of Undef (with attached
properties and possibly roles) so it can't be just a singleton. But,
Undef can report itself as equal to other Undefs. Let's make it so.
It's likely that undefined
Saturday, July 28th, we'll have a Parrot hackathon in Portland. The
location is to-be-determined (chromatic's house if there aren't more
than 10 of us). Drop me a note if you plan to join and I'll update you
with details.
Allison
chromatic wrote:
PARROT_API
PMC *
key_next(SHIM_INTERP, PMC *key /*NN*/)
{
return key-pmc_ext ? (PMC *)PMC_data(key) : NULL;
}
Is this in need of fixing? If so, how? If not, is there a better
function to show off what needs fixing?
This isn't a great example, as the guts of hashes and
Jonathan Worthington wrote:
Hi,
Just looking at the Class and Object PMCs and a couple of things concern
me.
1) Inside the method finding code I see this has been added:
if ( ! PMC_IS_NULL(namespace)
VTABLE_exists_keyed_str(interp, namespace, name)) {
PMC
Andy Lester wrote:
I guess I don't see the need to document a standard C behavior with a
macro.
If you had read all the way through the message, you would see that the
biggest benefit is the ability to hang debugging hooks off the macro.
We have a number of these kinds of debugging hooks
]
To: Allison Randal [EMAIL PROTECTED]
This can be a bit brittle -- you have to be careful when changing the
type of dst else you could end up with over or underflow.
memcpy(dst, src, sizeof(FOO));
I do like memcpy because it serves as a red flag that a potentially
medium to large size hunk of memory
All XXX notes should be attached to an RT ticket.
[EMAIL PROTECTED] wrote:
Author: petdance
Date: Sun Jun 17 23:21:22 2007
New Revision: 19081
Modified:
trunk/include/parrot/register.h
Log:
add an XXX note
Modified: trunk/include/parrot/register.h
Additions and corrections welcome.
--
New in 0.4.13
- Languages:
+ Updated Lisp, Lua, PHP (Plumhead), Python (Pynie), ABC,
WMLScript, and Tcl (ParTcl).
+ Perl 6 passes all but one of the sanity tests.
+ PGE supports latest Perl 6 grammar syntax. Perl 6 and ABC parsers
updated to
While putting together the news entries for the 0.4.13 release, I ended
up doing a code review on PMCProxy.
It looks like every low-level PMC is creating a proxy object for itself
and these proxies are stored in the interpreter global parrot_interp_t.
I intended that proxies would only be
Patrick R. Michaud wrote:
perl6 is now passing all of the 01-sanity tests.
Rockin'! A lot of commits went into that this month. Thanks guys!
Allison
Leopold Toetsch wrote:
Am Dienstag, 19. Juni 2007 16:52 schrieb Patrick R. Michaud:
perl6 is now passing all of the 01-sanity tests.
Woot.
Wouldn't that qualify for a 0.5.0 release number.
Not yet, but when we have PGE and Perl 6 switched over to the new object
model it will. (i.e. we
Release cut and tagged. You may now return to commits as usual.
Allison
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.13
Clifton. Parrot (http://parrotcode.org/) is a virtual machine aimed
at running all dynamic languages.
Parrot 0.4.13 can be obtained via CPAN (soon), or follow the
download instructions at http://parrotcode.org/source.html.
Parrot
Jonathan Scott Duff wrote:
- Misc:
+ Updated Parrot distribution to Artistic License 2.0, from dual
Artistic 1/GPL license.
Does this mean that Parrot is no longer dual licensed?
Yes. Under section 4(c)(ii) of Artistic 2.0 you can redistribute the
code under the GPL (any
I just signed an agreement with O'Reilly that assigns the full copyright
in the book Perl 6 and Parrot Essentials to The Perl Foundation. The
text is out-of-date, but can be updated much more rapidly than it can be
rewritten from scratch.
I'll check the Parrot parts into:
Andy Dougherty wrote:
I think the exit code stuff has been changed (this test used to get
reported as failing) but the $builder-diag weirdness is unchanged.
Okay, thanks! We'll work on it some more for the next release.
Allison
Resolved in r19096.
James Keenan via RT wrote:
I therefore ask: Why should we not stipulate that 'VERSION =
PARROT_VERSION' is the *sole* way to set VERSION in an .ops file? In
that case, (a) we could eliminate the aforementioned 'if' stanza in
Parrot::OpsFile::read_ops() and (b) we could probably get away
With the next release roughly a day away, please refrain from making
any major changes in trunk. If you have major changes, hold on to
them, create a branch, or create a [PATCH] ticket. Generally, just
keep the release in mind while making any commits.
Any bug fixes or changes to HLLs or
Andy Lester wrote:
When you write up the notes, can you please include a bullet about my
compiler work?
Will do. And anyone else with NEWS items, drop me a note. I'm reviewing
commits and posts tonight to compile the list.
Allison
On Mon Feb 20 16:23:46 2006, jhoblitt !-- x -- at hawaii.edu wrote:
On Tue, Feb 21, 2006 at 01:03:59AM +0100, Leopold Toetsch wrote:
On Feb 20, 2006, at 23:44, Joshua Hoblitt via RT wrote:
What happened to the factorial PASM example? It seems to have
disappeared and it hasn't
Allison Randal wrote:
I'm about half-way through a quick classification of the failing PDD 15
tests (in t/pdd15oo). A number of the failures are quick things anyone
could pick off, so I'll share the list:
http://rakudo.org/parrot/index.cgi?pdd_15_remaining_features
We're only failing 157 out
I'm about half-way through a quick classification of the failing PDD 15
tests (in t/pdd15oo). A number of the failures are quick things anyone
could pick off, so I'll share the list:
http://rakudo.org/parrot/index.cgi?pdd_15_remaining_features
We're only failing 157 out of 764 tests, so we're
On Tue, Jun 12, 2007 at 01:13:44PM -0700, Mark Glines wrote:
I just came up with an artificial benchmark and found that gcc-3.4.6
runs slightly faster with #pragma once protecting a header that includes
lots of other headers. (a chain of 200 other headers, in my test.) By
slightly, I mean
401 - 500 of 845 matches
Mail list logo
