Patrick R. Michaud wrote:
On Sat, Mar 17, 2007 at 06:16:08PM -0400, Will Coleda wrote:
On Mar 17, 2007, at 4:37 PM, Patrick R. Michaud wrote:
Could we also do some multi-dispatch here or typechecking of $P2
so that it could also be a whitespace-separated string of subnames
to import?
Steven Pritchard wrote:
I spent some more time getting a package built for Fedora. It
probably goes without saying, but this is still a bit difficult. If
anyone is interested, here's my current package:
Thanks, Steve. Have you kept a list of the things that are difficult
about the process?
Thanks, Mike, and welcome to the bird house. :)
Mike Mattie wrote:
In short parrot needs work on the install target, and I need to
justify the value of the target to the project before proposing any
changes.
The install process is generally known to need work, and critical to the
1.0
chromatic wrote:
My theory: the all Parrot developers work from within the tree, so
installation paths are either not present or wrong problem is a big problem.
Agreed. And we don't work from the installation paths because the
installation paths are broken. Can we break out of this cycle
Made a few more text edits in r17591. Paul Cochrane's changes approved,
ticket resolved.
Jerry Gay (via RT) wrote:
...an Exporter PMC that defines an api for
exporting.
Proposed interface:
$P0 = new Exporter
$P0.import($P1, ['KeyTo'; 'ImportedNamespace'], $P2)
where $P1 is the current namespace, and $P2 is an array of sub names to
import. It'd be even better if we could have the
Sam Vilain wrote:
Will Coleda wrote:
FYI, all six patches were just opened as tickets.
41809 is a dup of 41803
41810 is a dup of 41804
41811 is a dup of 41805
41812 is a dup of 41807
41813 is a dup of 41806
These have all been applied and resolved, or rejected.
Thanks,
Allison
Emacs users, what's the appropriate equivalent to the relevant part of:
# Local Variables:
# mode: cperl
# cperl-indent-level: 4
# fill-column: 100
# End:
# vim: expandtab shiftwidth=4:
for PIR files? Is this workable?
# Local Variables:
# mode: pir
Will Coleda wrote:
Having a limit is more than reasonable, agreed: the goal of this patch
was to bring the code into agreement with the docs.
Consider this a poke to the Architect to verify/replace the previous
overturn of the original 32-register limit.
The advantage of allowing unlimited
Namespaces have an export feature. A bit clunky, but a definite
improvement over the .IMPORT macro. I've replaced all instances of
.IMPORT with the export_to method, except
languages/PIR/examples/test.pir, because it seems to just be a generic
syntax example.
On Tue Mar 13 16:10:04 2007, [EMAIL PROTECTED] wrote:
[library/Test::More] add isnt() to test inequality - ints only
refactor the is() :multi for integers into a _cmp_ok() function, and
then use that to provide is() and isnt()
I spent some time poking at refactoring this patch and #41806
Thanks, applied in r17469.
I know I started the spread of the .IMPORT macros through the PIR-based
test files while I was working with Sam on the SMOP prototype, but when
I see sane, maintainable code using a documented interface like
find_global, replaced with a cryptic hackish macro (e.g. passing in
the '_' variable
Matt Diephouse wrote:
Jonathan Worthington [EMAIL PROTECTED] wrote:
Will Coleda (via RT) wrote:
So, since we can we can already get the current namespace with:
current_ns = interp['namespace']
This isn't a full replacement of the functionality we'd lose, since
you may want to get the
Leopold Toetsch wrote:
Am Donnerstag, 8. März 2007 20:25 schrieb Jerry Gay:
either move this to experimental.ops, or remove it entirely. i vote to
remove it. we don't need temporary hacks as core ops.
[...]
I'd rather have it in experimental.ops until these string issues are resolved.
Move
Jerry Gay (via RT) wrote:
it's old, not used anywhere, and defunct. let's list it in
DEPRECATED.pod before 0.4.10, and remove it before the following
release.
Agree.
Allison
We're splitting off the Parrot project manager role from the Perl 6
project manager role, to make better use of the time and energy of
available volunteers. Will Coke Coleda has graciously agreed to take
on the PM responsibilities for Parrot, and Jesse Vincent will continue
as PM for Perl 6.
Theodore Katseres wrote:
I managed to get parrot to build on aix-ppc-gcc4.0.0
smoked too ;)
Excellent! :)
Allison
Sam Vilain wrote:
Is it intended that if languages need to make changes to the behaviour
of existing obejcts through their type, that something may follow up
after this and replace the old objects with objects of the new type?
Yes. Some languages will want that behavior, and some won't, so
Alek Storm (via RT) wrote:
This patch adds the add_attr, rem_attr, and rem_attr_str vtable
methods. These will come in handy for Ruby's metaclasses or
Smalltalk's class objects. The only PMC currently affected by this is
ParrotClass, and the rem_attr and rem_attr_str methods are still
I've just checked in an updated version of
docs/pdds/draft/pdd01_overview.pod for review. A few questions/comments:
- The standard parser, bytecode compiler, optimizer, interpreter
breakdown has appeared in every overview of Parrot since the dawn of
time, but it's awfully vague. I'm redoing
Klaas-Jan Stol wrote:
hi,
attached a patch updating DEPRECATED.pod.
it adds the deprecated ops from http://www.parrotcode.org/docs/ops/var.html
Thanks, applied in r17206.
Allison
Klaas-Jan Stol wrote:
Looks good. I'd like to change the $P0 and $P1 to use actual variable
names (it's clearer for examples), but I can do that before I apply it
tomorrow.
yes, good point. I was trying to save lines, but clarity is better.
Anyone can, really. I'm happy to apply it
Fixed in r17210.
Aldo Calpini wrote:
Allison Randal ha scritto:
We do. Unfortunately we can't rely on Perl 5 for the configure system.
It may seem like an easy way to gain cross-compilation in the short
term, but in the long term it will hurt us.
Miniparrot is the right way to go. It certainly needs work
chromatic wrote:
+if (saved_log_data == NULL)
+return;
+
saved = saved_log_data;
mem_sys_free(saved-reads);
mem_sys_free(saved-writes);
I'm not sure this is the right fix; there's little reason to use an STMLog PMC
if it doesn't get a valid transaction log. My
Patrick R. Michaud wrote:
I think I prefer
to take one night's rest and get it right in the morning, than to
force it out this evening and perhaps have to clean up a lot of
small mistakes.)
Sensible.
1. The t/library/pg.t tests require libpq.so to be installed
in order to run -- should I be
Aldo Calpini wrote:
1) does anybody have objections to patching the current build system for
cross-compilation (even yes, but not now because... objections)?
Not at all. Cross-compilation is definitely a core goal for Parrot.
2) does anybody already have a .plan or something in mind about
Nicholas Clark wrote:
If you're adding before or after an existing named stage, the ambiguity is
to which one you mean. Except having now studied the PIR, I can see that
there isn't ambiguity, because it's all of them.
There's no test for this though. Hence why I didn't realise.
Good point.
On Thu Jan 11 09:58:32 2007, [EMAIL PROTECTED] wrote:
I've held off on applying it because Allison said we need a
deprecation cycle
for the name() - get_name() rename.
I've made a note in DEPRECATED.pod that the method is being renamed
(r17030). Go ahead and apply this patch immediately after
On Sat Jan 27 11:39:15 2007, [EMAIL PROTECTED] wrote:
This patch allows object vtable method overrides for find_method,
get_attr,
get_attr, get_attr_str, set_attr, set_attr_str, and get_class. Now these
can be overridden in PIR using the :vtable flag or prefixing their
respective names with
Sam Vilain wrote:
multi-sub?
skip string
skip int, string
I just committed (r17010) a version of the original patch, shifted over
to a multisub.
Allison
Nicholas Clark wrote:
What happens if you add a stage with the same name as an existing stage?
It gets added twice. You might repeat a stage like optimize_tree or
display_benchmarks after each transformation.
Is ambiguity acceptable?
What kind of ambiguity?
Allison
Why the reversed order of arguments from Test::Builder.skip? It seems that:
skip(5, 'lengthy message about reasoning')
is more readable than:
skip('lengthy message about reasoning', 5)
Is the assumption that skipping a single test with a message is more
common than skipping a number of tests
Kevin Te wrote:
I was just starting to port Class::MOP to C PMCs, I would be happy to
help port smop to C PMCs.
Great, let's meet on #parrot later this week.
Allison
This is a failing test Leo added in r16783. It looks to me like calling:
o = new 'MyClass', $P0
actually should call init_pmc, rather than init, even when $P0 is null.
Leo, are you saying the choice between init and init_pmc should be
based on the content of the argument rather than the
James Keenan wrote:
Which leads to my next questions:
Given a knowledge of a dynamic language (I believe there's one called
Perl 5), what is the trajectory for learning PIR?
Is there any tutorial in the docs?
There's docs/imcc/syntax.pod. Not a tutorial, but a decent introduction.
Is
Klaas-Jan Stol wrote:
hi,
IIRC, IMCC started as a kind of pre-processor for PASM, in other words,
it allowed more readable shortcuts for several constructs. Eventually,
everything was translated to pure PASM, that is, 1 long list of real
Parrot instructions (no .sub/.end blocks etc).
Yes,
I spent yesterday pair programming with Sam Vilain on a prototype object
model written in PIR. We actually wrote two prototypes. The first one
had 2 levels of meta objects and the system was getting pretty
convoluted, so we scrapped it and started over.
I just checked in the second prototype
Answering some questions from PDD 22.
- On naming, let's go with a simple 'IO'. It's in the parrot namespace,
so ['parrot';'IO']. IO is the base class, and may have other children
such as ['parrot'; 'IO'; 'Socket'] (perhaps a role).
- That said, I'll keep the text using more generic
Will Coleda (via RT) wrote:
... at least in the repository. The primary purpose of the MANFEST is to
make sure that the generated release isn't missing any files, neh? So, when
you're working out of the repository, you already know the canonical list.
The primary purpose of a MANIFEST in
James E Keenan wrote:
Do we have answers to the following questions?
1. What code is still unwritten that we will need to have Parrot ready
to go (where ready to go is defined as: ready for a Perl 6 alpha)?
(I'll leave aside the question of when *that* will be ready.)
The canonical list of
Jerry Gay (via RT) wrote:
i'll make any agreed upon changes based on your comments, and if
accepted, commit shortly thereafter.
I give it a thumbs up.
Allison
Will Coleda wrote:
While it would be possible to implement
the basic functionality by wrapping existing subs in other subs,
I'm not sure that would help with
[trace info], which provides a way to report on all the traces that are
currently set.
Isn't that more a matter of setting a flag on
On Tue Jan 16 12:05:17 2007, [EMAIL PROTECTED] wrote:
Attached patch adds new syntax documentation to docs/imcc/syntax.pod and
fixes some typos there. It now also indicates where various flags are
explained.
Applied in r16678.
Is the shorthand syntax for function calls (($P0, a :slurpy) =
Matt Diephouse wrote:
I actually prefer the dot. I don't like the possible ambiguity between
types and local variables:
.local string MyClass
MyClass = '...'
$P0 = new MyClass # is this a type or a string?
At that point, what we're really talking about is sigils. So, why put
sigils
PMC Class name IDs ... will require a dot in front
My preference is to eliminate the dot in classname IDs. Lodge your
objections now, before it's made fact in 0.4.9.
Allison
The :vtable feature has been implemented. Any remaining bugs in the
implementation should be submitted as separate tickets.
Ah, this explains why I wasn't able to duplicate the bug on the SPARC
box Sun loaned to us. It's a brand-new box, with the latest Perl, etc.
Is there a way we could get one of our Cage Cleaners access to the box
you're testing on? Or duplicate the configuration? I'll check with
Robert to see
Larry Wall wrote:
The Perl 6 perspective on this is that error values should be allowed to
be as interesting as you like. The lower level routine goes ahead and
pregenerates the exception object but returns it as an interesting
error value instead of throwing it. Then the calling code can
Jonathan Worthington wrote:
I like the look of this, but if I wanted to go about implementing it I
feel I'm kinda short of what that means implementation wise. I'm happy
enough with flattening composition and all that jazz, but a little extra
guidance on what you're expecting to compose into
I've just moved pdd22 out of the clip directory, marking it as ready for
beginning implementation efforts. Comments on the pdd are welcomed. A
few things worth highlighting:
- I/O layers will be replaced with role composition.
- Parrot's concurrency model for async I/O is a modified form of
I've just checked in the modified Punie code that runs on the improved
compiler tools. I sent various comments to the list as I went through
the port, so I won't repeat them here. A few more comments from the end
of the porting process:
- I like the way PAST-pm handles conditionals. It makes
An older article, but an interesting peek into a system with multiple
interacting concurrency models:
http://developer.apple.com/technotes/tn/tn2028.html
Allison
This is impressive, though this particular implementation is admittedly
limited (no static checking, and doesn't handle errors in the C code
gracefully):
http://people.csail.mit.edu/jrb/Projects/alien-goo.htm
Allison
On 12/20/06, Jonathan Worthington [EMAIL PROTECTED] wrote:
Patch attached that cleans up the code to return PMCNULL instead of
undef anyway. I don't really want to apply this until I hear a design
decision...
The design decision is: let's be consistent and use null.
jerry gay wrote:
let's
Paul Cochrane wrote:
The problem that I'm trying to solve
here is: how do we add the settings information to perl language files
such that it doesn't cause problems with __END__ and __DATA__ blocks,
is testable by perlcritic, emacs *and* vim pick up their settings
values, and it doesn't
Paul Cochrane wrote:
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
Nicholas Clark wrote:
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
to every source file, and a maintenance burden. Both vim and emacs allow
top-level settings of these preferences, which is a more appropriate
place for them.
This assumes that all the projects you use
Nicholas Clark wrote:
To seek clarification - having those as global settings for cperl isn't
likely to be an issue? Or having them in editor blocks?
I meant globally.
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl
On Sat Jan 29 06:17:10 2005, leo wrote:
Matt Diephouse [EMAIL PROTECTED] wrote:
I already use that workaround in some of my code, but that sorta
defeats the purpose of testing the filehandle itself. The filehandle
should become false after it returns the last line of the file - not
the
Patrick, what's the best way to pass-through string types from a
compiler to Parrot without doing full string processing? To pass the
current tests, Punie only needs Parrot's single- and double-quoted
strings, but Past-pm is escaping them. So:
print \n;
reaches the PIR translation as:
In Punie or Perl 6, when I execute a simple statement:
print 2;
It prints 21. This is because a) the return value of a successful
print is 1, b) the main routine is returning the value of the last
statement (note this is correct for Perl, but isn't correct for all
languages), and c)
Patrick R. Michaud wrote:
What revision number are you working with? I think this was fixed in
a later revision of HLLCompiler.
Aye, this was yesterday. Working now.
Allison
Patrick R. Michaud wrote:
PAST-pm expects it to be pretty rare that a HLL's string literal
format will exactly match what works as a string literal in PIR, so
PAST::Val nodes expect the HLL to have already decoded the string
constant according to whatever rules the HLL uses. Then PAST-pm
can
In Punie or Perl 6, when I execute a simple statement:
print 2;
It prints 21. This is because a) the return value of a successful
print is 1, b) the main routine is returning the value of the last
statement (note this is correct for Perl, but isn't correct for all
languages), and c)
Will Coleda wrote:
Given the current :method and .yield implementations, the following code:
$ cat foo.pir
.sub main :main
$P1 = newclass 'foo'
$P2 = new 'foo'
$S1 = $P2.'bork'()
say $S1
$P3 = new 'foo'
$S1 = $P3.'bork'()
say $S1
.end
.namespace [ 'foo']
.sub bork :method
$I0 = 0
loop:
Bob Rogers wrote:
This is also my definition of dynamic scoping. Were you not aware of
this behavior of local, or are we talking about different things
entirely?
I was talking about the lifetime of the temporization not static vs.
dynamic scoping.
But, this does help me better understand
Bob Rogers wrote:
Allison Randal wrote:
The proposal starts off talking about Perl 5's 'local' and Perl 6's
'temp'. They are lexical in nature (though they're more feature-rich
than simple lexicals). They only exist within a specific lexical scope,
and roll back on exiting
Matt Diephouse wrote:
One common use of anonymous subs in a dynamic language is
for later exporting them into another package (or multiple different
packages). In that case, you really don't want the sub to retain a link
to its defining namespace, you want it to fully adopt the namespace it's
... that chromatic AIM'd me:
http://debasishg.blogspot.com/2006/11/threadless-concurrency-on-jvm-aka-scala.html
Worth a read.
Allison
Patrick R. Michaud wrote:
On Mon, Nov 27, 2006 at 09:20:08PM -0800, Allison Randal wrote:
chromatic's suggestion is to replace the series of manual calls in
HLLCompiler's 'compile' method with an iterator over an array of
compiler tasks.
I very much agree with chromatic -- indeed
I'll split my replies into separate threads to make it easier to wrap
our brains around individual chunks.
Patrick R. Michaud wrote:
Clear boundaries between components: (Fuzzy boundaries of abstraction
make it difficult to allow for other implementations of the AST/OST or
customization of
Patrick R. Michaud wrote:
Also, out of curiosity, which high-level constructs in punie aren't
working?
What I've found so far are:
- The top-level AST structure is off: my temporary hack to replace
PAST::Stmt and PAST::Exp with PAST::Stmts is producing extra temporary
variables in the PIR
to push the design to the next stage of evolution. :)
Patrick R. Michaud wrote:
On Sun, Nov 26, 2006 at 08:30:32PM -0800, Allison Randal wrote:
- Is there no way to indicate what type of variable a PAST::Var is?
Scalar/Array/Hash? (high-level types, not low-level types)
Sure, that's what 'vtype
Patrick R. Michaud wrote:
I'll gladly add PAST::Stmt and PAST::Exp nodes if that's at all
useful. Just because they're there doesn't mean a compiler has to
use them. :-)
Well, I came to the conclusion that PAST::Exp was useless a while ago.
(Its entire point of existence was as a dummy
Patrick R. Michaud wrote:
Now implemented in r15882 as shown above, sans the helper 'init'
method (which I'll add later tonight). Examples are in
languages/perl6/ and languages/abc/ .
Definitely an improvement. Hmm... okay, I see what you're going for.
Creating subclass of HLLCompiler for
This fragment of a reply is the random bits that didn't make it into
other topic-centered replies.
Patrick R. Michaud wrote:
On Sun, Nov 26, 2006 at 08:30:32PM -0800, Allison Randal wrote:
Excellent. Just as a general overall response -- PAST-pm is by
no means finished, so many of the items
How about Partridge? It starts with 'p', it's a bird, and brings to
mind Partridge in a Pear Tree which goes with the theme of tree-based
compiler tools (PGE outputs trees, TGE munges trees). We can pretend we
named it after Kurt Partridge for his work on ZPL or Andrew Partridge
for his work
Bob Rogers wrote:
- Overall, I want the implementation of dynamic binding to be tied in
more closely with the implementation of globals and lexicals.
Particularly lexicals. They're already operating under the same scope
constraints as locals. They already have storage for named
Overall, the POST implementation is usable and I really like the new HLL
compiler module. I've got Punie working with the new toolchain to the
point that it's generating valid PIR code for many low-level constructs,
but some of the high-level constructs that worked under the previous
toolchain
Matt Diephouse wrote:
Let's try this again, starting from the Tcl side of things. Tcl code
can exist outside of subroutines. This, for example, is a valid Tcl
program:
set number 5
puts $number
[...]
But things get a
little hairier when we start using namespaces in Tcl:
namespace eval
Ben Morrow wrote:
...but that's just a braino on Matt's part, and his point still stands
for the code
package Test;
sub apply {
my $func = shift;
$func-(shift) while @_;
}
package Foo;
use vars qw/$line/; # can't use our as that also creates a lexical
chromatic wrote:
The only time I've ever used properties in PIR was to mark an object
initializer, but we have better ways to handle that now too. I don't object
to having them, but I do think we ought to have at least one good use case to
help decide what they need to do and how to do
Patrick R. Michaud wrote:
We might want to resurrect the 'compile' opcode as an indirect syntax
for making the 'compile' method call.
Maybe, but I can't see that this is worthy of a special opcode
(and presumably a vtable slot?). There's just not a lot of
difference between:
$P0 =
Leopold Toetsch wrote:
Please don't. Opcodes are very limited re calling conventions. Mehthods are by
far more flexible when it comes to pass arguments to compilers.
I believe we've been through this conversation before. I don't mean
coding a completely different opcode, I just mean using
chromatic wrote:
Properties:
I don't remember what problem these try to solve. It's difficult to discuss
one way or the other without an example.
They're solving the problem of allowing attribute-like information to be
attached to an object at runtime. In Perl 5, objects are blessed
Leopold Toetsch wrote:
And, I do think making the PASM and PIR compilers capable of being used
as standard compiler objects is a superior solution.
We currently can't pass any arguments to PASM/PIR compilers. You can't change
trace or debug options for eval. This is a serious limitation,
jerry gay wrote:
ick -- that feels wrong for parrot. we've always tried to make parrot
act in a consistent way across platforms wherever possible, so i'd
rather see the fix in Parrot_sprintf rather than in t/op/sprintf.t.
For the record: we decided in the weekly meeting yesterday to go with
Matt Diephouse wrote:
Would anyone be inconvenienced if the set_pmc vtable and the
setref and deref opcodes were removed? Note that if you are using set
_pmc but are not using assign_pmc, then you may not be
inconvenienced because right now the default assign_pmc vtable calls
set_pmc.
These
Patrick R. Michaud wrote:
Or, in claiming that compilers have an API, should we instead
say that the canonical compilation sequence is to use compreg
to obtain a compiler object (not an invokable sub), and then
compile the source via a 'compile' method on the compiler object?
For example:
I just finished reviewing docs/dev/pmc_object_design_meeting_notes.pod,
which is a summary of a design discussion I asked particle to lead at
the hackathon last weekend. It's a fantastic piece of work, and nicely
organizes the ideas we've been kicking around the past few months.
Thanks to
Larry Wall wrote:
Indeed, that's part of why Perl 6 eventually threw out properties
entirely, on the supposition that properties are simply attributes
that are mixed in at run-time rather than compiled in.
From an HLL perspective, I agree. But there's always more than one way
to satisfy an
Leopold Toetsch wrote:
We have basically the problem that classes are only constructed at runtime,
which has 2 negative impacts: associating the vtable info with the class
needs some helper storage like the props and namespaces can only be vaguely
attached to the correct class at runtime
I've finished a first pass through PDD 25 on threading/concurrency. It's
largely a collection of prior thinking on the subject. Before I start
kicking it into a more structured form, I'd like to do an initial round
of discussion. This is your chance to mention anything you hoped or
expected
Joshua Gatcomb wrote:
All negativity aside, there are a great deal of valuable points made in the
thread
which make it worth reading. While it has lost a bit of momentum - it is
still
being updated with new posts almost daily.
Excellent. Thanks for the pointer, Joshua. Definitely some good
Jonathan Worthington wrote:
error:imcc:'init' is not a v-table method, but was used with :vtable.
in file 'TGE/Rule.pir' line 49
leo++ fixed half of this when he cleaned up the validation code, but
there was another problem too. Fixed that in 15048, so this should work
now.
This is
Jonathan Worthington wrote:
This is why properties seemed like a good fit: the vtable entries in
namespaces are optional, out-of-band information, only used in
loading. But, they could just as well be implemented as a separate
attribute in the namespace class.
Agree; looking now at what I
Jonathan Worthington wrote:
Hi,
As of r15039, :vtable and :vtable(...) are now both implemented.
See example code at the end of this email.
Awesome!
As of now, please use this new syntax. I have left in support for the
old __-prefix lookup as plenty of old code is using it; please
note
Jonathan Worthington wrote:
This is a good place to start, but I agree it's not what we want
ultimately. Chip and I talked about attaching a data structure of
vtable entries as a property on the namespace object.
I implemented this to test it out and it kinda worked. However,
properties
601 - 700 of 845 matches
Mail list logo
