Release: Parrot 0.4.7, Caique
[ I'll post this to use.perl.org when CPAN has had a chance to mirror. ] On behalf of the Parrot team, I'm proud to announce Parrot 0.4.7, Caique! What is Parrot? Parrot is a virtual machine aimed at running all dynamic languages. The Parrot project home page is parrotcode.org. You may now (or soon) grab Parrot 0.4.7 from: http://www.cpan.org/authors/id/CHIPS/parrot-0.4.7.tar.gz New in Parrot 0.4.7: * New languages: PHP (Plumhead), Forth * Updated languages: Ruby (Cardinal), Tcl, Lua * Active Python language development is hosted at pirate.tangentcode.com * Compilers: + PGE updated with more expressions, latest changes to S05 + new Perl6 grammar compiler * Integration: + Perl 5 module Parrot::Embed allows easy embedding of a Parrot runtime into a Perl 5 program * PIR: + new :init pragma for subs that must run before the main function + new :vtable pragma to identify subs that override PMC vtable methods, eliminating the need for special subroutine names + PIR parser/compiler does not stop on first syntax error + Vanilla register allocator (register alligator) greatly improves performance compiling large functions + Eliminated limit on number of PIR macros * PMCs: + hash lookups return null instead of None for missing keys * Design: + PDD13 Bytecode files: format and manipulation - new + PDD10 Embedding - new + PDD25 Concurrency - rewritten + PDD15 Objects - new section on redesign requirements + PDD07 Coding standards - significant updates and automated tests * Test Suite: + Many many more new tests * Build Process: + autoconf compatible install options * Misc: + Namespace refinements + Coroutine improvements + An impressive swarm of other bugfixes and enhancements If you'd like to develop on Parrot (or help develop Parrot itself), we recommend that you keep up with the latest and best Parrot code by using Subversion or SVK to access our source code repository; see instructions at http://www.parrotcode.org/source.html . Thanks to all our contributors for making this possible, and our sponsors for supporting this project. Share Enjoy! -- Chip Salzenberg [EMAIL PROTECTED]
Re: Coding Standard Questions
On Tue, Oct 17, 2006 at 04:01:36PM -0500, Andy Lester wrote:
if ( foo ) {
bar();
}
else {
bat();
}
Well, that's not correct either: Our coding standards already say to omit
needless braces, and don't space inside the parens of if/while/etc. Thus,
this is the preferred format:
if (foo)
bar();
else
baz();
--
Chip Salzenberg [EMAIL PROTECTED]
Re: Coding Standard Questions
On Tue, Oct 17, 2006 at 11:41:06PM +0200, Leopold Toetsch wrote: Anything that has the smallest smell of ever needing an extra statement after if or else shall use braces in the first place (IMHO). Predicting the future is something humans are bad at, sadly. -- Chip Salzenberg [EMAIL PROTECTED]
Re: r15330 - in trunk: . compilers/imcc docs docs/pdds include/parrot src
On Fri, Nov 10, 2006 at 10:51:14PM -0500, Bob Rogers wrote: From: [EMAIL PROTECTED] Date: Fri, 10 Nov 2006 11:12:21 -0800 (PST) Author: chip Date: Fri Nov 10 11:12:20 2006 New Revision: 15330 . . . Log: Remove the :maybe_flat feature, which was intended to help Perl 6, but they never used it. Substantially improve editorial quality of pdd03 (++particle). This seems to make t/op/calling.t test #15 fail (titled maybe flatten + slurpy param); the passed arrays are not flattened. Is it OK to just flush it? I've now done so, thanks. -- Chip Salzenberg [EMAIL PROTECTED]
pls ignore commits w/o content
It seems that I've managed to confuse svk again, as it continues to re-commit old log messages with no content. -- Chip Salzenberg [EMAIL PROTECTED]
String.to_int() vs. opcode
(For those not watching CVS, Leo's just added a METHOD to_int() to String.) Seems like this is the kind of thing that needs to have a common subroutine in the C source so it can be used elsewhere, and an opcode so it's usable with an S register. And once you've done that, the METHOD becomes redundant. -- Chip Salzenberg [EMAIL PROTECTED]
Re: String.to_int() vs. opcode
On Fri, Aug 25, 2006 at 03:32:12PM -0400, Will Coleda wrote: What about 'say'? It's a method, not an opcode, and: say $S0 works just fine. Well, 'say' is a parrotio METHOD, not a String METHOD: METHOD INTVAL say(STRING *s) so the SELF is an io PMC and nothing is hard. Expressing to_int() as a method where the SELF is a String PMC leaves the string registers out in the cold. The 'say' opcode also requires hackery in src/builtin.c; but since requires hackery seems to be the status quo ante for half of Parrot, perhaps I should let that go unmentiond. Oops, too late. (Bitter? Oh, a *tad*.) I do think pulling too hard at this thread might require a closer look at what's current in src/pmc/ vs. src/*.c vs src/ops/ (where's there's smoke...): a lot of the current state has been a result of organic (rather than planned) growth. No kidding. :-/ -- Chip Salzenberg [EMAIL PROTECTED]
Re: SKIPs Are Now a Code Smell
On Sat, Aug 19, 2006 at 07:17:03PM -0700, chromatic wrote: Thus, I suggest that we collectively unskip all of the tests that might possibly pass on all platforms, tighten the skip conditions to their minimum necessities, use TODO instead of SKIP absolutely everywhere possible, and delete the tests that don't matter anymore. I'm Chip Salzenberg, and I approve of this message. I've just checked in a CAGE task for this. Thanks. -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 10:48:59AM -0400, Will Coleda wrote: The way you phrase the question, you're not going to get any of these answers. Who is programming parrot on their *physical* VT100? =-). The primary reason for an 80 column limit is developer convenience, I think. Well, that's fair. Many of us are old enough to have used such limited hardware, but it's all surely been relegated to the trashheap by now. So: Would anyone be inconvenienced by exceeding 80 columns regularly; and, how? I don't think any of us will quit if you come back with a higher number. Except maybe Jerry. =-) He'll threaten to quit until I change the pdd and .t files and then he'll start bugging people who write short lines. P.S.: Seems only fair that if we're sticking with C89, we stick with 1989 terminal sizes. =-) Some selectivity is in order, or we'll have to target 1989 memory sizes, disk capacities, and network bandwidth PS: Allison gets to specify the doc formatting, if she likes. Exceptions are technically trivial. See the bottom of the pdds for how a given file can override the default word wrap column. -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 07:28:14PM +0200, Leopold Toetsch wrote: 80, or 100, or 132 are all some arbitrary limits. But the latter is already inconvenient on a 12 powermac with reasonable font size [1]. That's an interesting and modern metric: minimum common screen size divided by minimum readable font size. (For me that comes out to 150 columns; a 12 display triggers my claustrophobia.) [1] reasonable for the old eyes of folks that actually have punched hollerith cards, when they were younger, like e.g. yours sincerly Right there with you. My school's punch card machines were in the same room as the TRS-80 Model I (THE COMPUTER ROOM). These kids today with their hula hoops and fax machines and intarwebs... -- Chip Salzenberg [EMAIL PROTECTED]
Re: End the Hollerith Tyranny? (linelength.t)
On Mon, Aug 21, 2006 at 06:05:08PM -0400, Mr. Shawn H. Corey wrote: Don't forget that some programs, like mailers, wrap at 80 characters. I don't know of any mailer that is hard-coded at any given column width. Do you? -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #40204] line numbers of runtime errors are one too low
On Sun, Aug 20, 2006 at 07:12:12AM -0700, Leopold Toetsch via RT wrote: Am Sonntag, 20. August 2006 02:43 schrieb Will Coleda: [1] http://rt.perl.org/rt3/Public/Bug/Display.html?id=38594 and WTF - who dared to close that (coke--) This isn't the same error, it's a different one. Do you intend to have a new ticket for each PIR snippet with wrong line numbers? If too many RT tickets is our largest problem then ... well, anyway, it's not. When the apparent reported bug was fixed, closing the ticket was right. Besides, it's not like they aren't a renewable resource. :-) -- Chip Salzenberg [EMAIL PROTECTED]
[perl #40065] STM first merge tracking ticket
first merge done. yeah baby
Re: [perl #40178] None Must Die
On Thu, Aug 17, 2006 at 12:13:30PM -0700, Leopold Toetsch via RT wrote: Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg: The None class serves no useful (portable) purpose and it should be removed, especially from the public interface of Hash. I've started fixing that. Yay, leo++ The current only safe replacement is: $I0 = exist hsh['no_such_key'] ... This can *later* be optimized to: $P0 = hsh['no_such_key'] ifnull $P0 / unless $P0 ... So you're planning to (1) change the tests/usercode so they work with both the old and new Hash interfaces; then (2) change Hash; then (3) re-optimize the tests and usercode to use the isnull test? That is the long way around, but it'll keep the users working. Works for me. :-) A releated change: $S0 = hsh['no_such_key'] used to return an empty STRING*, it'll soon return a NULL STRING*. Good choice. Folks, please check your usage of testing for existing hash keys. Well, we (core hackers) changing the interface out from underneath them, so if their code breaks, we should fix it up, if we can. Code outside the svn tree (e.g. pirate) is of course beyond our reach. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #40178] None Must Die
{DESIGNER ALERT - Allison, what think?}
On Thu, Aug 17, 2006 at 12:31:11PM -0700, Patrick R. Michaud via RT wrote:
I rely on the return empty string behavior. In particular, changing it
to return NULL will mean in many places that I will have to replace
single-line key lookups
$S0 = hsh['key']
with
$S0 = hsh['key']
unless null $S0 goto label
$S0 = ''
label:
Indeed. I think we can reduce the pain of dealing with this to the point
where you'll hardly feel it. For example, I really like Python's lookup
semantic where you can provide the default value on the call.
How about a 'default' opcode that provides a value instead of null? It
would work for strings and PMCs. Something like:
$S0 = default hsh['key'], ''
or
$P0 = new .Undef
...
$P1 = default hsh['key1'], $P0
$P1 = default hsh['key2'], $P0
...
It would work without the lookups too:
$S0 = default $S0, ''# if $S0 is null, assign it ''
what say?
--
Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #40178] None Must Die
On Fri, Aug 18, 2006 at 12:17:58AM +0200, Leopold Toetsch wrote: A lot of src/string string_ operations are capable of dealing with NULL strings currently [1]. *But* that's AFAIK specificied nowhere, and might just be an accident, i.e. an extra (unneeded/unwanted) check for A NULL argument. A consistent behavior would make all these things just errors, the same as we got with the Null PMC, which has been created for this very reason - the same as a SEGV in C, when accessing a NULL ptr. Indeed, these _should_ all be errors. However, there is often no direct way to indicate an error when the output type has no out-of-band values, like INTVAL. And exceptions are still too expensive. So at present I'd consider this a misbug. -- Chip Salzenberg [EMAIL PROTECTED]
Re: None Is Dead
{ not replying to the ticket }
On Fri, Aug 18, 2006 at 01:10:07AM +0200, Leopold Toetsch wrote:
Am Donnerstag, 17. August 2006 08:24 schrieb Chip Salzenberg:
The None class serves no useful (portable) purpose and it should be
removed, especially from the public interface of Hash.
... and the None class is gone.
$P0 = hsh['no_such_key']
returns the NULL PMC
Rockin'. Totally.
$S0 = hsh['no_such_key']
is unchanged and returns ''
Good. I don't know whether we'll keep this, but the strategy of how to use
null strings is a bit fuzzy to me, so it's just as well not to cause users
pain until we know we mean it.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: More review of current stm branch code
On Fri, Aug 11, 2006 at 04:38:59PM -0400, Charles Reiss wrote:
On 8/10/06, Chip Salzenberg [EMAIL PROTECTED] wrote:
/* XXX is it okay to combine flatten/slurpy into one flag? */
The answer is No: flat is an output flag, slurpy_array is an input
flag, and there's no guarantee that the input and output flags won't
conflict with each other. So I guess this means that something has to
change.
I suppose trying to make '@' mean something different for signatures and
for calls from C (as I have done) is a Bad Idea as long as the same code
is used to parse the signatures in both cases. The easy solution is to
choose a character other than '@' for one of the directions though I can't
think of what might be most natural ('F' for flat?).
To provide a general ability to wrap any call from C, then you need to add
named parameter support too; flat arrays are _so_ Perl 5. Would '%' and 'N'
work for you? :-) (also see below)
MORE QUESTIONS
* The '@' character for native call signatures is new, and AFAICT is just
syntactic sugar, since the caller could do the array creation himself.
Could you explain what you would have to do if you didn't introduce this
feature? (I'm not necessarily against it, mind you, I just want to know
what the deal is.)
It is just syntactic sugar. So, not using would be as you describe, having
the (most likely PIR) caller construct the array manually. My use of this
feature is only to allow naturally passing an arbitrary number of
arguments to the subroutine that is first executed in a new thread, which
I feel is quite convenient.
Well, as it happens, we've been wanting support for variadic PMC METHODs for
a Long Time. Since you're already introducing necessary infrastructure, are
you inclined to add some PMC METHOD syntactic sugar too, so that we can
conveniently define METHODs that accept arbitrary parameter lists? (This
is not a merge blocker, of course; just a wishlist item.)
* Another comment asks:
# autogenerate for exotic types
# (XXX is this appropriate or do we want them to each
# be explicitly cleared to have the variant?)
Well, that depends. Is there currently any way for a named METHOD to
specify whether it is :write, and if so, is this used? If so, then yes,
making an automatic ro variant is OK. If not, then I think we might
want such a thing...?
The read-only variant generation currently does not handle NCI methods
at all. There are number of implementation options; the best I can
think of is to override findmethod (in the read-only type) to check
for a property on the found method PMC that would indicates it writes
(or vice-versa).
That's actually kind of neat; at least, it's clearly the least bad of all
the options I see.
The only minor downside IMO is that in order to get adequate speed we'll
need to dedicate an easy-to-see flag bit somewhere visible in the method PMC
to mean :write, and there are only so many of those. But fast threading
is hardly a minor feature, so I don't mind that cost at all.
A bigger issue for automatic read-only variant generation is that MMD
methods currently don't do any read-onlyness detection. (Sorry!) (This is
not quite as much as a problem as it may seem because things like String
and Integer, being designed to allow subclassing, call vtable methods from
their MMD methods to do any manipulation.)
Understood, agreed.
As a stopgap solution, it would be easy to reverse the logic I have
now and default to not generating a read-only version except when the
.pmc file says it is okay instead of the other way around.
Well, this is still 0.4, not 1.0. If you can just tell us on the list what
we shouldn't do, so we can include it in the release notes, then I don't
mind having only partial protection. For obvious reasons, nobody's using
the thread support right now, so it won't break anything. ...Or will it?
--
Chip Salzenberg [EMAIL PROTECTED]
Re: More review of current stm branch code
On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: I wrote: The read-only variant generation currently does not handle NCI methods at all. There are number of implementation options; the best I can think of is to override findmethod (in the read-only type) to check for a property on the found method PMC that would indicates it writes (or vice-versa). This is done (w/ s/findmethod/find_method/ of course), returning PMCNULL instead of a method that would write. (This prevents it from being called, but doesn't yield helpful errors.) Yow, done already! Excellent. (Shoulda read the followup first.) It also does not allow .pmc files to overide the default idea of whether a vtable method is read-only. This remains unresolved though I'm not certain it should be allowed. The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? A bigger issue for automatic read-only variant generation is that MMD methods currently don't do any read-onlyness detection. (Sorry!) This is now fixed. Yow^2! Nice work. -- Chip Salzenberg [EMAIL PROTECTED]
stm ready (was Re: More review of current stm branch code)
So, given the below, looks like we've got everything sewn up and the long-awaited day of the STM merge is upon us. Charles, care to do the honors? On Tue, Aug 15, 2006 at 06:31:38PM -0400, Charles Reiss wrote: On 8/15/06, Chip Salzenberg [EMAIL PROTECTED] wrote: On Sat, Aug 12, 2006 at 08:14:52PM -0400, Charles Reiss wrote: I wrote: It also does not allow .pmc files to overide the default idea of whether a vtable method is read-only. This remains unresolved though I'm not certain it should be allowed. The hard part of doing it correctly is handling inheritance. It's an interface guarantee, and as such I think it's OK that it can't be overridden in a derived class. Agree? Er, when I first read that I thought you meant that with respect to the inheritance issue, but reading again I'm not sure. Yes, that's what I meant. But, anyways, looking over pmc2c I found that doing it 'properly' was not too difficult, so I've done that (read/writeness is inherited by default and can be overridden). Works For Me, thanks. I provide the feature in the hope that people will think really hard before using it to violate interface guarantees. Big friendly warnings are the right first step. If people start ignoring the signs and wandering onto the live minefields, we'll have to start thinking about audio warnings and fierce guards with pointed sticks. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Review of current stm branch code
On Fri, Aug 11, 2006 at 11:46:37AM +0100, Sam Phillips wrote: Six years into the project the Parrot team, responsible for the Perl6 internals finaly get round to arguing about what style of C brackets and indenting they are going to use.. It's not an argument.[*] If people kept talking about it, and if I kept trying to persuade them, back forth... then, it'd be an argument. [*] It's abuse. Arguments are down the hall. -- Chip Salzenberg [EMAIL PROTECTED]
Review of current stm branch code
core_type;
+}
hash = PMC_struct_val(type_hash);
-if (!hash-entries)
+if (!hash-entries) {
return core_type;
+}
Something I'm hoping to stamp out is the use of curlies for all if/else
clauses, which makes code taller without making it substantially clearer.
I'd appreciate if you'd use a no-curlies-when-possible style.
OTOH, if you don't want to do this right away, I'd be OK with a merge
first, and fixing the curlies later.
OTGH, the project needs automated filters for more coding standards,
including one that that notes (and optionally kills) the excess curlies.
* params of type const Parrot_Interp
-void pt_thread_prepare_for_run(Parrot_Interp d, Parrot_Interp s);
+void pt_thread_prepare_for_run(Parrot_Interp d, const Parrot_Interp s);
What's the purpose of this? It doesn't protect *s from changes. [time
passes] I now see that some of the existing functions already have this
construct. Perhaps you were just imitating them?
--
Chip Salzenberg [EMAIL PROTECTED]
More review of current stm branch code
More on the STM branch: ANSWERS, FOR A CHANGE * A comment asks: /* XXX is it okay to combine flatten/slurpy into one flag? */ The answer is No: flat is an output flag, slurpy_array is an input flag, and there's no guarantee that the input and output flags won't conflict with each other. So I guess this means that something has to change. * Another comment asks: # autogenerate for exotic types # (XXX is this appropriate or do we want them to each # be explicitly cleared to have the variant?) Well, that depends. Is there currently any way for a named METHOD to specify whether it is :write, and if so, is this used? If so, then yes, making an automatic ro variant is OK. If not, then I think we might want such a thing...? MORE QUESTIONS * The '@' character for native call signatures is new, and AFAICT is just syntactic sugar, since the caller could do the array creation himself. Could you explain what you would have to do if you didn't introduce this feature? (I'm not necessarily against it, mind you, I just want to know what the deal is.) ANOTHER NAMING THING * Please rename 'ro_variant' to something ending in '_vtable', e.g. 'ro_variant_vtable', to make clear that it's not a class pointer or type number. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Review of current stm branch code
On Thu, Aug 10, 2006 at 07:11:15PM -1000, Joshua Hoblitt wrote: On Thu, Aug 10, 2006 at 07:19:21PM -0700, Chip Salzenberg wrote: * useless curlies OTGH, the project needs automated filters for more coding standards, including one that that notes (and optionally kills) the excess curlies. This is a bad joke, right? How much of your life are you intending to spend on chasing down hard to find missing braces bugs? If avoiding the possibility of hard-to-find bugs, were my priority, I wouldn't enjoy writing C and C++. Or Perl. Or PL/I. Seriously: I am serious. Many of the changes I have in mind for the Parrot source code are based on reducing the visual footprint of constructs without changing their meaning, and eliminating needless words^Wbraces is one way to do that. Anyone who needs braces to avoid/detect errors is probably just not acclimated to the C language, and/or failing to indent properly (that's what smart editors are for; no snide Python remarks please). And Parrot is written in the complete C language, not some intersection of C and Perl. I'd rather invest my extra vertical space into some well-chosen comments and blank lines between phrases, which can convey useful meaning, rather than braces around one-line if/else clauses, which are just noise. -- Chip Salzenberg [EMAIL PROTECTED]
can somebody convert an MS Project 97 file for me?
If you have MS Project 98 or Project 2000 installed, and can load-and-save a project file for me, please mail me. adTHANSKvance -- Chip Salzenberg [EMAIL PROTECTED]
Parrot 0.4.6 Released!
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.6, the most recent close-to-monthly release of Parrot. I'm particularly pleased to report that Parrot 0.4.6 includes the beginnings of a Ruby implementation (named Cardinal), thanks to the work of Kevin Tew. What is Parrot? Parrot is a virtual machine aimed at running all dynamic languages. The Parrot project home page is http://www.parrotcode.org/. You may now grab Parrot 0.4.6 from: http://www.cpan.org/authors/id/CHIPS/parrot-0.4.6.tar.gz New in Parrot 0.4.6: - New languages: Ruby (Cardinal), Javascript (ecmascript) - Updated languages: Tcl, dotnet, bc, Pheme, Punie, WMLScript - Updated compilers: PGE, TGE - IMCC updates: + .loadlib directive expresses dependencies + .namespace with no parameter goes to HLL root + lexer is reentrant (reentrant grammar in progress) - Namespace improvements: + new suite of opcodes to access namespaces and globals (find_global and store_global will be phased out) + namespace '' no longer means HLL root - Design document updates: namespaces (pdd23), basic types (pdd17), embedding - Updated tool requirements for developers: flex 2.5.33, bison 2.1, perl 5.6.1 - New to-do list for people new to Parrot: cage/todo.pod - The usual plethora of bugfixes and enhancements If you decide to develop on Parrot (or help develop Parrot itself), we strongly recommend that you keep up with the latest and best Parrot code by accessing our source code repository. Instructions for doing this are at http://www.parrotcode.org/source.html. I'd like to thank all our contributors for making this possible, and our sponsors for supporting this project. Share Enjoy! Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o
On Tue, Aug 08, 2006 at 06:19:18PM -0700, Allison Randal wrote: Leopold Toetsch wrote: Am Montag, 17. Juli 2006 21:11 schrieb chromatic: After discussing the idea with Allison, we both believe that Parrot should be able to produce a single PBC file from a command like: parrot -o all_files.pbc file1.pir file2.pir ... filen.pir Well, that exists already and is named pbc_merge. pbc_merge takes .pbc input only, but this shouldn't be a problem. pbc_merge doesn't allow multiple :load routines. That's a bug, Shirley. What we're looking for is more of a Parrot version of .par/.jar/.pkg: bundle up all the files you need for a particular application into a single file. Not a PBC, but some form of archive or package format. I don't see any harm in .zip and .tar and [archive method of choice] plugins. -- Chip Salzenberg [EMAIL PROTECTED]
Parrot 0.4.6 Released! {p2-only announcement}
{{ This announcement is going to p2 only. Once CPAN has propagated the
tarball far and wide, the announcement will go out for everyone else. }}
On behalf of the Parrot team, I'm proud to announce Parrot 0.4.6, the most
recent close-to-monthly release of Parrot. I'm particularly pleased to
report that Parrot 0.4.6 includes the beginnings of a Ruby implementation
(named Cardinal), thanks to the work of Kevin Tew.
What is Parrot? Parrot is a virtual machine aimed at running all dynamic
languages. The Parrot project home page is http://www.parrotcode.org/.
You may now (or very soon) grab Parrot 0.4.6 from this URL:
http://www.cpan.org/authors/id/CHIPS/parrot-0.4.6.tar.gz
New in Parrot 0.4.6:
- New languages: Ruby (Cardinal), Javascript (ecmascript)
- Updated languages: Tcl, dotnet, bc, Pheme, Punie, WMLScript
- Updated compilers: PGE, TGE
- IMCC updates:
+ .loadlib directive expresses dependencies
+ .namespace with no parameter goes to HLL root
+ lexer is reentrant (reentrant grammar in progress)
- Namespace improvements:
+ new suite of opcodes to access namespaces and globals
(find_global and store_global will be phased out)
+ namespace '' no longer means HLL root
- Design document updates:
namespaces (pdd23), basic types (pdd17), embedding
- Updated tool requirements for developers:
flex 2.5.33, bison 2.1, perl 5.6.1
- New to-do list for people new to Parrot:
cage/todo.pod
- The usual plethora of bugfixes and enhancements
If you decide to help develop on Parrot (or help develop Parrot itself), we
strongly recommend that you keep up with the latest and best Parrot code by
accessing our source code repository. Instructions for doing this are at
http://www.parrotcode.org/source.html.
I'd like to thank all our contributors for making this possible, and our
sponsors for supporting this project.
Share Enjoy!
Chip Salzenberg [EMAIL PROTECTED]
svk is generating almost-empty change sets
FYI, the change sets you're seeing that have only modifications to the meta info for 'trunk' are being generated by 'svk push', and I don't know why. But they seem harmless enough. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)
The whole question of packfiles is something I hadn't approached before, and now that I have, I wonder: Why does a packfile needs to exist at all when compiling into the in-memory interpreter? There are some answers to that question I'd accept, but it's still a question that needs answering. As for any further improvements, I fear they will have to wait for 0.4.7. PS: Cage cleaners should detect and possibly correct all that namespace pollution. Yuck. -- Chip Salzenberg [EMAIL PROTECTED]
[CAGE] Fix symbol table namespace pollution
Extern functions and variables must have names that begin with CParrot. -- Chip Salzenberg [EMAIL PROTECTED]
[CAGE] Fix non-symbol-table namespace pollution in public headers
Public headers are the ones in Cinclude/parrot directory. These are included by embedders and extenders. They must not declare or define any symbol that isn't clearly Parrot-specific. Prefixing symbols with CParrot or CPARROT is the easiest safest way, but it can lead to a lot of verbosity, so I'm willing to entertain exceptions or new conventions. It's OK for public headers might have non-public parts protected with C#ifdef PARROT_IN_CORE. Those non-public parts might #define shorter versions of the public symbols, e.g. C#define foo Parrot_foo. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Fix symbol table namespace pollution
On Thu, Aug 03, 2006 at 01:29:20PM -0500, Andy Lester wrote: I am way out of tuits lately. Can you please add this to cage/ todo.pod for me? Or someone? Already done. -- Chip Salzenberg [EMAIL PROTECTED]
Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops
For those of you not watching the Parrot subversion log (and why not?):
* Opcodes {get,make}*namespace and {get,set}*global again accept arrays of
names in place of constant keys ...
* ... obviating the corresponding Namespace PMC methods, which are now gone.
* Time to 'make realclean'.
(And of course I repeat a gentle reminder that the old find_global and
store_global opcodes will eventually [eventually!] go away, so convert
to the {get,make}*namespace and {get,set}*global opcodes instead.)
In the process of the above change, these more fundamental low-level changes
were needed (or at least helpful):
* Keys passed to opcodes as plain values -- i.e. as namespace or class
identifier rather than for their classic indexing purpose -- are now
encoded in opcodes differently, as _pc (inconst PMC) rather than
the historical and ambiguous _kc (inconst KEY).
* Therefore if you can get a Key PMC into a PMC register, many of the
key-accepting opcodes will accept the key via the register. However,
some won't; see Note below.
* Op parameters in PMC used to be silently treated as invar PMC (i.e.
no PMC constants allowed). This is no longer true. However, most
opcodes still behave just like before, thanks to a massive search-and-
replace of in PMC with invar PMC.
Note on an insteresting design issue: The new 'subclass' opcode variants
demonstrates the inherent ambiguity between class names and class PMCs;
merely being a PMC or not isn't enough to distinguish the intent of
specifying class vs. class name. (Keys are PMCs.) This should be resolved
in a general way for all class-accepting opcodes.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: Fix symbol table namespace pollution
On Thu, Aug 03, 2006 at 11:51:40AM -0700, jerry gay wrote: can not the rt repository be canon for cage cleaners tasks? it is already for bugs, todo items, and patches. there is a link to rt already in the See Also section of cage/todo.pod. if you prefer, i can add this task to cage/todo.pod. That would be fairly neat, actually. Searches should be easy since cage isn't a term of art in the Parrot source. A link on parrotcode.org to an appropriately pre-formatted search would improve the ease of use. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Fix symbol table namespace pollution
On Thu, Aug 03, 2006 at 03:03:08PM -0400, Will Coleda wrote: http://www.parrotcode.org/cage-cleaners/todo.html Hey, that's neat. http://xrl.us/owsd (Link to rt.perl.org) Hey, that's neater! Enjoy. Done, thanks. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39986] Create Default PackFile for New Interpreter (Parrot C API)
On Thu, Aug 03, 2006 at 12:05:13PM -0700, chromatic wrote: On Thursday 03 August 2006 11:18, Chip Salzenberg wrote: The whole question of packfiles is something I hadn't approached before, and now that I have, I wonder: Why does a packfile needs to exist at all when compiling into the in-memory interpreter? There are some answers to that question I'd accept, but it's still a question that needs answering. The trivial answer is that there are a lot of functions where Parrot assumes it has compiled code available. But the compiled code wouldn't necessarily have to live in a structure compatible with on-disk storage. But of course such a commonality would simplify things. OK. PS: Cage cleaners should detect and possibly correct all that namespace pollution. Yuck. In the external API, you mean? Isn't there a bug for creating macros to avoid prefixing Parrot_ to all internal-only functions? Yes, but that's at least potentially orthogonal: pollution ne inconvenience. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39778] Segfault when using a Namespace with an Iterator
So, is the namespace iteration working now ... at least enough to close the ticket that says segfault in large friendly lettes? -- Chip Salzenberg [EMAIL PROTECTED]
Re: Parrot news: namespace ops good, (some) namespace methods bad; key-accepting ops
On Thu, Aug 03, 2006 at 11:18:04AM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
(And of course I repeat a gentle reminder that the old find_global and
store_global opcodes will eventually [eventually!] go away, so convert
to the {get,make}*namespace and {get,set}*global opcodes instead.)
Which reminds me that we need to propagate the change to lexicals too:
get_lexical and set_lexical, instead of find_lex and store_lex. We might
as well make it one deprecation cycle for the whole set.
Matt suggests that the get meme is better for retrieving from a single
known location, while the find meme is better for looking in multiple
places until success. If you agree, then find_lex can remain with its
current name. As can, for similar reasons, find_type.
OTOH, I'll grant that store isn't as good a cognate as find, but I'm not
sure we have a good word for look around until you find the thing I name,
and then set it to this value.
So if we can't find a really good pair of words to replace get/set in the
searching case like lexicals, then maybe we'll just have to use get/set and
let the lex be the clue.
PS: In some HLLs (e.g. Tcl (AFAIK))) there is no searching to speak of,
so it's not a universally applicable concept.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39926] :init attribute (was Re: Implement .loadlib pragma in IMCC)
On Thu, Aug 03, 2006 at 01:31:26PM -0700, Allison Randal via RT wrote: Patrick R. Michaud wrote: I'd like there to be an :init pragma to mark subs that are to be executed anytime the file is loaded. In the case of loading from the command line, the :init subs should be executed prior to the :main sub. Agreed and approved. Cool. So noted in http://rt.perl.org/rt3/Ticket/Display.html?id=39926. I was going to say approved and added to the relevant PDD, but there doesn't seem to be a PDD documenting these subroutine attributes. Ah, the PIR pdd rears its nonexistent head again. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39776] [BUG] PGE core dump
On Mon, Jul 10, 2006 at 02:18:21PM -0500, Patrick R. Michaud wrote: I totally agree that PGE probably needs to provide better syntax error checking in situations such as this, thus I'm leaving this ticket open, or will add a new more descriptive one soon. But why the core dump in this case? Why not a thrown exception? (I ask to know whether I should try to fix this before 0.4.6) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39756] [EMAIL PROTECTED]: tru64 core dump: t/examples/japh_10.pasm
Wow. So I've just learned that our test harness ignores seg faults. Which
explains why t/examples/japh.t keeps reporting all tests successful when
actually they're mostly segfaulting and otherwise failing.
This particular japh uses threading, which is known not to work until the
STM work by Charles Reiss (woggle) is merged.
I'm deferring this ticket appropriately.
On Thu, Jul 06, 2006 at 11:12:34PM -0700, Jarkko Hietaniemi wrote:
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #39756]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39756
(dbx) run --gc-debug t/examples/japh_10.pasm
run --gc-debug t/examples/japh_10.pasm
thread 0x3 signal Segmentation fault at [clone_interpreter:63
+0xc,0x120122738
] d-run_core = s-run_core;
(dbx) p d
(nil)
(dbx) where
0 clone_interpreter(dest = 0x14049f618, self = 0x1404a22c8)
[src/pmc/parrotinterpreter.pmc:63, 0x120122738]
1 pt_thread_run(interp = 0x1401c4000, dest_interp = 0x14049f618, sub =
0x14049f500) [src/thread.c:147, 0x1200b8e58]
2 pt_thread_run_3(interp = 0x1401c4000, dest_interp = 0x14049f618, sub =
0x14049f500) [src/thread.c:221, 0x1200b8ff4]
3 pcf_v_JOP( = 0x1200bea5c, = 0x1200bea5c, = 0x1200bea5c, interpreter =
0x1401c4000, self = 0x14022d608) [src/nci.c:3266, 0x1201d0520]
4 Parrot_NCI_invoke( = 0x1200c48c4, = 0x1200c48c4, interpreter =
0x1401c4000, pmc = 0x14022d608, next = 0x1404deb10) [src/pmc/nci.c:146,
0x120178668]
5 Parrot_invokecc_p(cur_opcode = 0x1404deb00, interpreter = 0x1401c4000)
[src/ops/core.ops:414, 0x1200c48c0]
6 runops_slow_core(interpreter = 0x1401c4000, pc = 0x1404deb00)
[src/runops_cores.c:180, 0x12014b208]
7 runops_int( = 0x1404dea00, = 0x1404dea00, interpreter = 0x1401c4000,
offset = 0) [src/interpreter.c:775, 0x1200f9bb8]
8 runops(interpreter = 0x1401c4000, offs = 0) [src/inter_run.c:81,
0x1200f7f60]
9 runops_args(interpreter = 0x1401c4000, sub = 0x14049f640, obj =
0x1401214c0, meth = (nil), sig = 0x140061298 = vP, ap = struct {
_a0 = 0x11fffbf40
_offset = 24
}) [src/inter_run.c:182, 0x1200f8290]
10 Parrot_runops_fromc_args(interpreter = 0x1401c4000, sub = 0x14049f640,
sig
= 0x140061298 = vP) [src/inter_run.c:276, 0x1200f8460]
11 Parrot_runcode(interpreter = 0x1401c4000, argc = 1, argv = 0x11fffc028)
[src/embed.c:802, 0x1200a6384]
12 main(argc = 1, argv = 0x11fffc028) [compilers/imcc/main.c:681,
0x120088f60]
(dbx)
Summary of my parrot 0.4.5 (r13183) configuration:
configdate='Fri Jul 7 00:08:51 2006'
Platform:
osname=dec_osf, archname=alpha-dec_osf
jitcapable=0, jitarchname=nojit,
jitosname=dec_osf, jitcpuarch=alpha
execcapable=0
perl=/u/vieraat/vieraat/jhi/Perl/Platform/OSF1/bin/perl
Compiler:
cc='cc', ccflags='-std -D_INTRINSICS -fprm d -ieee -I/p/include
-DLANGUAGE_C -pthread -D_XOPEN_SOURCE=500',
Linker and Libraries:
ld='ld', ldflags=' -L/p/lib',
cc_ldflags='',
libs='-lm -lutil -lpthread -laio -lrt -lgmp'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -expect_unresolved * -O4 -msym
-std -L/p/lib',
load_ext='.so', ld_load_flags='-shared -expect_unresolved * -O4 -msym
-std -L/p/lib'
Types:
iv=long, intvalsize=8, intsize=4, opcode_t=long, opcode_t_size=8,
ptrsize=8, ptr_alignment=8 byteorder=12345678,
nv=double, numvalsize=8, doublesize=8
--
Chip Salzenberg [EMAIL PROTECTED]
[perl #39754] [EMAIL PROTECTED]: tru64 core dump: t/pmc/resizablebooleanarray_20.pasm
This ticket now depends on ResizeableBooleanArray rewrite.
[perl #39753] [EMAIL PROTECTED]: tru64 core dump: t/pmc/io_1.pir
Until we know what these I/O ops should do, seg faults aren't unexpected. Nor are they something we can meaningfully fix. This ticket now depends on the review of the I/O pdd.
[perl #39752] [EMAIL PROTECTED]: tru64 core dump: t/op/lexicals_27.pir
Fixed in svn. Actual bug was causing malloc(0). Proximate bug is that, on tru64, malloc(0) fails. :-)
[perl #39751] unbug - [EMAIL PROTECTED]: tru64 core dump: t/dynoplibs/myops_4.pir
parrot obeys you when you ask it politely to halt and catch fire
[perl #39750] [EMAIL PROTECTED]: tru64 core dump: t/examples/japh_12.pasm
Fixed in svn by deleting that never-will-work-again japh, which hacked internals in an amazingly evil way.
Impending release of Parrot 0.4.6
Parrot 0.4.6 will be released Real Soon Now, probably this weekend. No code slush will be needed ... assuming I can manipulate Subversion to my will and create a release branch. Smokes and PLATFORMS would welcome your attention. -- Chip Salzenberg [EMAIL PROTECTED]
Parrot: Evolution v2 presentation
I've just delivered v2 of Parrot: Evolution at OSCON '06. This presentation is a bit different in content but looks a lot more, well, plain. Not that there's anything wrong with that. I suggested to the people present that they might visit http://use.perl.org/~chip/journal/30455 where I link to the presentation which is at http://feather.perl6.nl/~chip/oscon06/OSCON06-ParrotEvolutionV2.pdf Share and enjoy! -- Chip Salzenberg [EMAIL PROTECTED]
new {get,set}*global opcodes from pdd21 are available
If you check the current pdd21, the global variable opcodes are now:
{get,set}_global
{get,set}_hll_global
{get,set}_root_global
These opcodes are now available. (Don't forget to 'make realclean'.)
The old {fetch,store}_global are soon to meet an abrupt, if honored, end.
Convert when convenient, but don't tarry.
Share Enjoy!
--
Chip Salzenberg [EMAIL PROTECTED]
Parrot users: 'make realclean'
Just a note for those who don't watch the commit logs: (1) why don't you? :-) (2) you'll want to 'make realclean' and rebuild after you update next Share Enjoy! -- Chip Salzenberg [EMAIL PROTECTED]
Re: Namespace.get_namespace() vs. optional params
On Mon, Jul 17, 2006 at 02:01:08PM -0700, Allison Randal wrote: Long-term, we need to minimize the differences between low-level PMCs and Parrot objects defined in PIR code. That may mean allowing optional arguments and named parameter passing. But, I want to keep the PDDs focused on driving us toward a 1.0 release, and this isn't a necessary feature. I've added a TODO ticket, in case somebody with spare tuits wanders by. Let the yaks go unshaved, Allison It is not I who am crazy -- it is I who am _mad_! -- Chip Salzenberg [EMAIL PROTECTED]
get_root_namespace opcode vs. interpinfo {cage cleaners?}
Allison, I suppose that given get_root_namespace, that we should get rid of Cinterpinfo .INTERP_ROOT_NAMESPACE? If that's true, then a good little cleanup task would be removing all usage of the latter and replacing it with the former. -- Chip Salzenberg [EMAIL PROTECTED]
flex/bison version for Parrot?
What versions of flex and bison will work now? I'd like to make Configure.perl (or perhaps the Makefile at runtime?) choke on --maintainer if the right versions aren't found. -- Chip Salzenberg [EMAIL PROTECTED]
another item for the cage list: INTVAL_MAX etc.
(I'd have added this myself, Andy, but you're the keeper of the cage/todo.pod document structure.) New thing: RT #39855: configuration: define MIN/MAX macros for all integral typedefs For example, if INTVAL is long, then config.h should include: #include limits.h #define INTVAL_MIN LONG_MIN #define INTVAL_MAX LONG_MAX ... etc. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39867] Configure.perl --maintainer should check flex/bison versions
On Tue, Jul 18, 2006 at 10:48:45AM -1000, Joshua Hoblitt wrote: I believe ambs I fixed this before the bug was filed. ;) Bugs fixed before they're filed? Now _that's_ a process failure mode I can live with! :-) -- Chip Salzenberg [EMAIL PROTECTED]
Namespace.get_namespace() vs. optional params
Looking over the recent editorial improvements in pdd21, I need to point out that, right now, if a method is written in C, it can't have optional arguments. (This is per Leo; I haven't checked into how/why this restriction arose.) Thus, to support both of these interfaces: =item get_namespace $P1 = $P2.get_namespace($P3) +$P1 = $P2.get_namespace() We'll have to either write the method in PIR (which isn't necessarily a problem, though it will be a hair slower) or switch to MMD (I don't know yet what that will do; for all I know it'll work perfectly the first time, but it's just another thing to do as part of the conversion). Mind you, I'm OK with this, but it's something to be aware of. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Parrot should limit its own stack usage?
On Mon, Jul 17, 2006 at 09:26:12PM -0400, Bob Rogers wrote: But what I really meant was: Shouldn't Parrot do a 'setrlimit' on itself in order to detect these sorts of bugs sooner, and more usefully? Or, maybe 'ulimit -s' would be appropriate before running test cases? Running the test suite (or at least most of it) under ulimit is indeed a good idea. Whoever jumps in on this, please be prepared to adjust the value as reports come in from the field. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Source cleanup ideas (pending STM merge)
I've got a few source cleanups in mind, and I figured I'd share the ideas I have kicking around my head, and ask if anyone else has been thinking of cleanups as well. Note that I don't want to make the eventual STM merge more difficult than necessary, so I don't think we can make these cleanups yet, particularly because these cleanups are mostly around the interpreter structure, which of course is everywhere. Ideas I've got: * standarizing on interp or maybe even intr as the interpreter variable, for brevity consistency * a macro for declaring the interpreter argument, and maybe a macro for passing it (BTW, our Perl experience teaches us that somebody is going to want to make the interpreter a C++ object for Windows environments, and it wouldn't hurt to make that possible, or at least work in that direction, as long as clarity doesn't suffer) * eliminating the CONTEXT(interp-ctx)-foo usage in favor of the much simpler interp-ctx-foo , or similar simplification * automated processing that would make a macro to let us write somefunc(interp,a,b,c) while the linkage is Parrot_somefunc(interp,a,b,c) for namespace cleanup Once the STM merge is done, I will enjoy crying Havoc! and letting slip the cage cleaners of war. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Source cleanup ideas (pending STM merge)
On Mon, Jul 17, 2006 at 09:38:22PM -0500, Andy Lester wrote: I've dumped all your suggestions into cage/todo.pod. Thanks. That you're editing cage and herding the cage cleaners is a load off my mind. -- Chip Salzenberg [EMAIL PROTECTED]
Re: PDD 23 Exceptions - ready for implementation
On Sat, Jul 08, 2006 at 04:51:38PM -0700, Allison Randal wrote: Chip did a fantastic job on the Exceptions PDD. With a few refinements, I'm pronouncing it ready to implement. montgomery-burns Excellent. /montgomery-burns Mad properties to Allison for creating the first draft (updating is so much easier than starting from scratch!) and to Bob Rogers for explaining to me the Common Lisp perspective on EH. Most languages have something worth learning from, and I like CL's EH. Now if it only had continuations }:-) BTW, for those of you keeping score at home, refining namespaces will come before exception implementaiton. Exceptions are important, but if you can't even find your variables, you're pretty much up the creek. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39777] Macro array considered lame
On Mon, Jul 10, 2006 at 12:09:08AM -0500, Vishal Soni wrote: -#define N_MACROS 4096 +#define N_MACROS 8192 Thanks, applied. But we can all see where this is going. Will no one rid me of this troublesome fixed-size array for macros? -- Chip Salzenberg [EMAIL PROTECTED]
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 01:55:39PM -0500, Patrick R. Michaud wrote: On Wed, Jul 12, 2006 at 11:36:56AM -0700, chromatic wrote: On Wednesday 12 July 2006 11:27, Patrick R. Michaud wrote: The perl6 compiler has a custom string type, currently called Perl6Str. What's the canonically correct mechanism for creating an object of that type? $P0 = new 'Perl6Str' $P0 = new .Perl6Str $P0 = new [ 'Perl6Str' ] I tend to use: .local int str_type str_type = find_type [ 'Perl6Str' ] .local pmc p6str p6str= new str_type Along similar lines... - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED]
Re: Creating a New Object (was Re: [TODO] Implement .loadlib pragma in IMCC)
On Wed, Jul 12, 2006 at 12:15:07PM -0700, Chip Salzenberg wrote: - If another HLL wants to create a Perl6Str, how does it do it? - If another HLL wants to create a subclass of Perl6Str...? I just realized that I misinterpreted these questions. I thought that the first question was asking how some random HLL can create its own class that also has the name 'Perl6Str' -- i.e. a name collision question -- and that the second question was adding on by asking how the new name-collided class could coexist with (for example, derive from) the original. I'll be happy to answer the actual questions precisely, but I need to know more: Frst: Is this about now or the eventual future? Do you want the answer for when the full name of Perl6Str is ['parrot';'Perl6Str'], as I think it is today, or ['perl6';'Perl6Str'], as it should be eventually? Second: Does the derived class have to be named ['myhll','Perl6Str'], or can it have a new basename like ['myhll','MyPerl6Str']? AFAIK there is no answer for this at present. (1) POSSIBLE KLUDGE In the very short term we could introduce a simple hack that would allow the user to specify the root namespace for the creation of the new class, defaulting to the HLL root: .HLL evillang .sub foo $P0 = get_hll_namespace# ['evillang'] $P1 = newclass ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... (2) ELEGANT DIRECTION FOR THE FUTURE [to be determined] Seriously: Allison's busy (as am I) with nailing namespaces to the wall, so I wouldn't ask her to decide this. I do have ... not so much an idea, but an approach, which I'll suggest when the time comes: At present, newclass creates a class object and a namespace, both of which have the same name. That must change once we stop depending on typed namespaces. Assuming a single namespace object can represent a single class in future -- which is good for class manipulation and introspection -- I think we'd want to stop having 'newclass' futz with namespaces at all, leaving it up to the user to give it a name ... if any. Yes, Virginia, there are anonymous classes. :-) So it might look like: .HLL evillang .sub foo $P0 = newclass ... set_hll_global ['Perl6Str'], $P0 # Not a Perl 6 string, but an incredible simulation ... -- Chip Salzenberg [EMAIL PROTECTED] -- Chip Salzenberg [EMAIL PROTECTED]
_group in library name (was Re: r13272 - in trunk: compilers/imcc docs/imcc src)
On Wed, Jul 12, 2006 at 05:29:08PM -0700, [EMAIL PROTECTED] wrote: * Apply heuristics that tells .loadlib 'perl6_group' # HLL dynamic PMCs and .loadlib 'dynlexpad'# non-HLL dynamic PMCs apart, by locating the '_group substring inside the library name. Urque, that's really not OK even in the short term. Could you alter it to use an adverb: .loadlib 'perl6_group' :hll please? PS: yes, I am planning to standardize on lower case for pir directives PPS: yes, I am planning to let the upper-case .HLL work for a -long- time :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
Leaving :immediatein PIR doesn't actually introduce any problems that we
didn't already have (and can't escape anyway).
There's a PIR file already in svn somewhere in Parrot where a :immediate
function is used to build a large table programmatically at compile time, so
that at runtime it's already completely available. That's neat.
Now think about the alternatives if your goal is to have the table ready to
go at runtime without any computational overhead at all, e.g. a CRC table.
It could be done with a separate program running outside Parrot to generate
source code, the traditional approach for such things. The form of the
output could be your DSL or not, doesn't matter. The point is, that table
has to be generated at compile time, somehow, and that takes running code
that the user wrote. User code that may have side-effects.
Thus, the key inescapable attribute of any build process that includes the
compile-time preparation of application-specific data, whether it's inside
Parrot or a Perl script called from 'make', is this:
** a user-written program is running at compile time **
and you simply cannot escape that. If you kill :immediate {and don't tell
me deprecate, you want to kill it} the same things happen that you
complain about, they just happen outside the Parrot VM where I think you
think you can ignore them, but they're still there, still part of the whole
compilation process. Any program-generating script has all the
disadvantages you list for :immediate, and it's less convenient to boot.
Ergo, :immediate is not actually creating any problems for you in your
functional-modeling problem. The problems are inherent to user code running
at compile time. If you need to start and stop a new Parrot VM each time,
well, that's no different in principle from a programmer typing make
distclean to remove all the intermediate products of autoconf or op2c.pl or
whatever.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
On Tue, Jul 11, 2006 at 09:59:12PM -0400, Audrey Tang wrote: ?b 2006/7/11 ?U?? 7:33 ???AChip Salzenberg via RT ?g???G Now think about the alternatives if your goal is to have the table ready to go at runtime without any computational overhead at all. And if we can restrict :immediate using some security principal in the future so it can only do things that are not destructive -- and always yield the same result -- in other words, do not depend on the environment, then this use would be totally fine. But that's impossible, as you know well if you just think it through. 'Dependence on the environment' may not be a characteristic of mathematically perfect functional models, but it *is* a characteristic of *all* real programs running in the real world on real hardware. It cannot be avoided, no matter what changes we make and how carefully we try to create 'pure and ideal' computation. For example: What if the IEEE FP of the compilation machine differs slightly from the target machine, so that you get -0 instead of 0 or Inf instead of NaN? What if the Parrot versions of compiler and runtime differ slightly so that the C code behind multi sqrt(Float) isn't the same on the compiler as on the target machine? What if the CPU's been upgraded and the new Pentium suddenly knows how to do long division? What if we alter the hash ordering so the data structure building code produces different results? You think :immediate is a bug. It isn't. It's a messenger of Eris, and Fred Brooks is singing in its choir. I hear him now: 90% of debugging is answering various forms of the question, 'Which program is this?' In short, to say that :immediate is unpredictable is to make a null statement, because in practice, all computation is unpredictable. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39792] [TODO] Deprecate :immediate in favour of .loadlib and .const
On Tue, Jul 11, 2006 at 11:52:10PM -0400, Bob Rogers wrote: Even so, I can't see how it would help to use :immediate to compile Common Lisp. That's fine; some misconceptions to the contrary, that's not what it's intended for.[*] It's an *analogue* of Perl's BEGIN; it's not intended to be a tool for implementing BEGIN when compiling Perl. [*] Just what it _is_ intended for is an open question. I think the user base will answer it, if we let them, in time. -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Mon, Jul 10, 2006 at 03:23:56PM -0500, Patrick R. Michaud wrote: On Sat, Jul 08, 2006 at 01:57:58PM -0700, Chip Salzenberg wrote: Relative is the usual apposite to absolute, but we have a three-way logic here, so appositives don't really work. I think that hll is the best I can think of, and given the existing .HLL directive, its meaning is immediately clear: .HLL 'perl5', perl5_group .namespace ['Foo'] $P0 = get_global 'x' # ['perl5';'Foo';'x'] $P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x'] $P0 = get_hll_global 'x' # ['perl5';'x'] $P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x'] $P0 = get_abs_global 'x' # ['x'] $P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x'] What's the status on the above...has it been blessed/implemented yet? This looks to me like exactly what is needed/desired for the various HLL's I'm working with. Allison has blessed it except for the detail of the _hll_ in the HLL selection. I haven't started implementing it yet, though nothing stands in my way technically. I've suggested that get_namespace follow exactly the same pattern, but so far she hasn't commented on that suggestion at all. BTW I expect find_global to keep working for a good while. The only thing that may change incompatibly in _any_ of this is the meaning of: PMC = get_namespace KEY,STR which currently starts from the HLL root but which I'm proposing should start at the current namespace. *If* that additional proposal goes forward, any place you currently have the above, you would just change it to: PMC = get_hll_namespace KEY,STR PS: None of this is in any PDD yet -- not a complaint, just an observation. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: OSCON hackathon
On Mon, Jul 10, 2006 at 06:09:32PM -0500, Patrick R. Michaud wrote: However, for those who cannot make it on Sunday, I notice that Monday and Tuesday at OSCON are primarily dedicated for tutorial sessions, so people arriving after Sunday and/or not attending or presenting tutorials can perhaps continue hacking activities on those days...? I think it'd be great to maintain a hackathon designated location for those who are between tutorials, or who like me just show up during tutorial days for the hell of it. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39778] Segfault when using a Namespace with an Iterator
On Sun, Jul 09, 2006 at 11:52:23PM -0700, Matt Diephouse wrote: Trying to use an Iterator with a NameSpace makes Parrot segfault Ouch. The current namespace class is typed but in a silly way -- not with name mangling but with actually storing two things with exactly the same name. (One being a sub-namespace, and the other being anything else.) So iterating through it requires custom code. Frankly I'd prefer to make the default namespace actually be a hash with extra behaviors (methods mostly), but that requires something else first, namely, the rearrangement of the Parrot namespace so that Parrot no longer requires a class object and its namespace object to have the same name. I'm going to create a bug for this plan and then connect that bug to this. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Mon, Jul 10, 2006 at 06:57:06PM -0700, Matt Diephouse wrote: Patrick R. Michaud [EMAIL PROTECTED] wrote: I really like both of these suggestions. We also noted on #parrot that get_hll_global would really simplify things for the Tcl folks, which currently go through a macro to achieve the same effect. You mean get_abs_global, actually. The proposed get_hll_global opcode mirrors the existing find_global exactly. :-) Erm, only if it's the explicit-namespace version of find_global. Summarizing the conversion chart: $P0 = find_global 'x' - $P0 = get_global 'x' $P1 = find_global ['ns'],'x' - $P0 = get_hll_global ['ns'],'x' -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Mon, Jul 10, 2006 at 07:22:21PM -0700, Allison Randal wrote: Chip Salzenberg wrote: I think that hll is the best I can think of, and given the existing .HLL directive, its meaning is immediately clear: I like that. Great! Seems to me that we should have get_namespace patterned just alike: Agreed. Great^2! I'm still not entirely happy with abs, but I can live with it, especially since its use should be quite rare. Yeah, if we're going for meaning-based naming in the 'hll' version, it'd be nice to have a meaning-based name for the absolute-root version. Perhaps get_root_global or get_base_global (I like 'base' better). I could live with either get_root_global or get_base_global. I may commit a patch that contains one or the other but only as a development step, not as a stealth vote. (You'll probably want to know that get_base_global has a slight object- orientation connotation from my C++ experience; in C++, a superclass is called a base class. Whether this matters depends entirely on whether slight C++ semantic bleed is likely to interfere with the Parrot user base; and even I must admit that the answer is probably no.) I'll work on updating the namespaces PDD tomorrow. Great^3 that this happens automagically (from my POV) while I'm coding. :-D -- Chip Salzenberg [EMAIL PROTECTED]
Re: Stealing base
On Mon, Jul 10, 2006 at 09:25:53PM -0700, Allison Randal wrote: Maybe get_top_global We can claim it stands for the 'ole (bl***y) path. ;) Now that's the Perl design metric I've come to know and love. :-) Seriously, it works for me. I suggest that you delay the final choice utnil you write the PDD, then to with whatever opcode name looks best in the =item that precedes its description. :-) -- Chip Salzenberg [EMAIL PROTECTED]
Re: The handled op forces resumption?
On Sun, Jul 09, 2006 at 06:27:13PM -0400, Bob Rogers wrote: I have a question about Chandled. r13214 adds item 2 in the following snippet from the current revision: When the Chandled opcode is called: =item 1 Pop and destroy the exception record. =item 2 If there was a continuation in the exception record, invoke the continuation. I hadn't looked at r13214 yet, but I agree that changes is problematic. It misses the implications of the continuation being passed as a parameter and the existence of the Chandled opcode: It is to give the handler complete freedom as to where to transfer control after handling the exception. RATIONALE: What the programmer may consider a warning may become an error in the end. Consider the Perl equivalent of gcc's -Werror. So it's not OK for throwcc force continued execution at any given continuation when handling is done. Also consider that there is little value in a Chandled opcode that transfers control. If it were OK for Parrot to force continued execution in a particular place, then the handler could just return the values that are currently the parameters of Chandled, and Parrot would take it from there. These are the use cases I had in mind for exception handler code: (1) I can handle it [a] execute Chandled [b] invoke some continuation, perhaps the one we got as a parameter, perhaps a different one (2) I can't handle it just return So in short I think Chandled should go back to merely clearing the exception in progress but not transfer control. -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ Language implementors, please know I'm going to do everything I can to
make every commit break nothing. I did pretty well when I made namespace
[''] stop being [] -- I fixed all the HLLs in the selfsame patch, except
two bits of code generation in TGE and PGE, which I fixed when they were
found. (particle++ for the finding) }
On Fri, Jul 07, 2006 at 12:46:35AM -0700, Allison Randal wrote:
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
Always a pleasure.
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
Agreed, with a note of balance that we also want to avoid the pain of
XS. Sometimes you need to poke into the guts of the system, and when you
do, you want it to be pleasant to work with, even though it's not fancy.
Point well taken. Pain is acceptable but not a goal.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
This is non-evil. :)
grin/
I would rename 'get_cur_global' to 'get_global'. The selected namespace
indicates that most of the code belongs in that namespace, so it's
likely that most of the variables do too. (There are variations, but
that's at least the common case.)
Works for me. And that is the current meaning of two-parameter find_global,
so it's not a stretch.
Then, what to call the HLL root access opcodes... perhaps 'get_rel_global'
(for relative root)?
Hrm. Relative is the usual apposite to absolute, but we have a three-way
logic here, so appositives don't really work. I think that hll is the
best I can think of, and given the existing .HLL directive, its meaning
is immediately clear:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_global 'x' # ['perl5';'Foo';'x']
$P0 = get_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_hll_global 'x' # ['perl5';'x']
$P0 = get_hll_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
Seems to me that we should have get_namespace patterned just alike:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_namespace # ['perl5';'Foo']
$P0 = get_namespace ['Bar'] # ['perl5';'Foo';'Bar']
$P0 = get_hll_namespace # ['perl5']
$P0 = get_hll_namespace ['Corge'] # ['perl5';'Corge']
$P0 = get_abs_namespace # [] :-)
$P0 = get_abs_namespace ['parrot']# ['parrot']
I'm still not entirely happy with abs, but I can live with it, especially
since its use should be quite rare.
--
Chip Salzenberg [EMAIL PROTECTED]
Re: pdd21 vs. find_global
On Sat, Jul 01, 2006 at 10:37:59PM -0500, Allison Randal wrote: I'm more inclined to say find_global just shouldn't accept a namespace PMC as an argument. For those who aren't reading the subversion logs: 1. Why aren't you? :-) 2. I've done this -- Chip Salzenberg [EMAIL PROTECTED]
Re: A PDD for dynamic-wind?
On Sat, Jul 08, 2006 at 05:10:57PM -0400, Bob Rogers wrote: And my intended implementation of dynamic-wind actually does require its own stack, separate from the current control stack . .. Is there a PDD forthcoming? If not (or even if so), would you (Allison now, presumably?) like help writing it? As for me, namespaces need to be fully and completely put to bed before I can move on. I'd love to do exceptions next, but I suspect that I can't really do exceptions properly until we have proper dynamic scopes. EHs may not be controlled entirely by the general dynamic scope mechanism, but their definitions and mechanisms for entering and leaving must be identical. Personally I'd love to see your interpretation of dynamic-wind in Parrot. And PDD format is a fine format to present a complete idea so that it can be easily understood and, perhaps, adopted. PS: All of this is about foreground projects. Background and bug fixes always go on. -- Chip Salzenberg [EMAIL PROTECTED]
[perl #39552] Segfault on FreeBSD during make
Is this bug still reproducible this even after removing everything Parrot-related from /usr/local? (Also /usr/bin and /usr/lib if you happen to have installed e.g. Debian's parrot packages.)
I'm pre-hackathoning at OSCON, not post-hackathoning
I'm unable to hang around Portland after Friday afternoon, I'm sorry to report, so Saturday hackathoning will miss me. However, I will be arriving a day _early_ so I'll be in Portland all day Sunday. I understood Patrick to be in a similar situation, so he might be there Sunday too. -- Chip Salzenberg [EMAIL PROTECTED]
.namespace [''] in TGE
I think this patch is advisable, or at least not wrong. Yes/no? === compilers/tge/TGE/Compiler.pir == --- compilers/tge/TGE/Compiler.pir (revision 13181) +++ compilers/tge/TGE/Compiler.pir (local) @@ -380,6 +380,9 @@ .return (code) .end +# NOTE - this code assumes that a type of '' is impossible +#(in older versions of Parrot, it was) + .sub 'grammar_string' :method .param pmc grammar .local string code @@ -387,9 +390,13 @@ .local string inherit type = grammar[type] inherit = grammar[inherit] -code = \n.namespace [ ' +code = \n.namespace +if type == '' goto no_type +code .= [ ' code .= type -code .= ' ]\n\n +code .= ' ] + no_type: +code .= \n\n code .= .sub '__onload' :load\n code .= load_bytecode 'TGE.pbc'\n code .= $I0 = find_type ' -- Chip Salzenberg [EMAIL PROTECTED]
PGE and TGE vs. .namespace
The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) The TGE patch seems to work, but I got test failure from my PGE patch. Patrick? Allison? === compilers/tge/TGE/Compiler.pir == --- compilers/tge/TGE/Compiler.pir (revision 13181) +++ compilers/tge/TGE/Compiler.pir (local) @@ -380,6 +380,9 @@ .return (code) .end +# NOTE - this code assumes that a type of '' is impossible +#(in older versions of Parrot, it was) + .sub 'grammar_string' :method .param pmc grammar .local string code @@ -387,9 +390,13 @@ .local string inherit type = grammar[type] inherit = grammar[inherit] -code = \n.namespace [ ' +code = \n.namespace +if type == '' goto no_type +code .= [ ' code .= type -code .= ' ]\n\n +code .= ' ] + no_type: +code .= \n\n code .= .sub '__onload' :load\n code .= load_bytecode 'TGE.pbc'\n code .= $I0 = find_type ' === compilers/pge/PGE/P6Regex.pir == --- compilers/pge/PGE/P6Regex.pir (revision 13181) +++ compilers/pge/PGE/P6Regex.pir (local) @@ -117,9 +117,14 @@ pir: .local pmc code .local string grammar +.local string nsformat grammar = adverbs['grammar'] +nsformat = .namespace +if grammar == '' goto pir_emit +nsformat = .namespace [ '%0' ] + pir_emit: code = new 'PGE::CodeString' -code.emit(.namespace [ '%0' ], grammar) +code.emit(nsformat, grammar) $P0 = exp.root_pir(adverbs :flat :named) code .= $P0 if target != 'PIR' goto bytecode -- Chip Salzenberg [EMAIL PROTECTED]
Re: [perl #39743] [PATCH] change perl6-internals to parrot-porters in docs
On Thu, Jul 06, 2006 at 02:52:10PM -0500, Chris Dolan wrote: Oops, I missed a couple of instances of perl6-internals in the previous patch (notably, in parrotbug). This updated patch obsoletes the previous one. Thanks, applied. A followup may be needed if p6i ends up *not* forwarding to p2. The perl.org admins are not pleased by the prospect, saying it has caused confusion in the past, and it's easy for a bounce message to tell people a new list address. % diffstat parrot-porters2.patch README |4 ++-- Hey, I *like* diffstat. I wish I saw it used more. -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Thu, Jul 06, 2006 at 12:11:47PM -0700, Allison Randal wrote: It's essentially the linguistic problem of being able to refer to something both by its full name and by the pronoun it. (Otherwise known as topic.) Only, currently it isn't represented by a word. Well, we have three distinct 'it's for namespaces: the Parrot root, the HLL root, and the current. I view the HLL root as the main one for most purposes, and escaping the HLL root I model as escaping a Unix chroot (in rarity if not security), which is why I'm conformable with using interpinfo to get the global root. And of course the current namespace maps onto the Unix working dir for me. -- Chip Salzenberg [EMAIL PROTECTED]
Re: HLL root globals and empty keys (was Re: test of get_namespace opcode)
{ All you HLL implementors and other PIR users out there, please be assured
that I'll be providing as easy a transition as possible when/if these global
opcodes are adjusted. }
On Thu, Jul 06, 2006 at 11:53:59AM -0700, Allison Randal wrote:
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully specified namespace, including the HLL namespace.
Then a set of opcodes using the add_*, del_*, get_* naming scheme handle
the magically assume the HLL root/current namespace behavior. (PDD 21
uses both get_* and find_* for retrieval. It's better to standardize on
one, but it doesn't really matter which one.)
Well, I see a lot to like about this, but (and you knew there was a but
(but that's my job now :-))), in descending order of difficulty:
* The division into two categories (global and symbol) leaves the third
category (current namespace) with no clear home.
* All the things being accessed are globals. Seems like the word global
should be used consistently, and symbol has many meanings in Parrot
that only partly overlap the specific meaning of global.
* We still don't have way to ask for my HLL without spelling it. I can
say my HLL's Foo without spelling my HLL, but when I go up to my HLL's
root I must suddenly know the spelling of my HLL and say it. Seems like
a sign of a design problem.
* The global root is available as Cinterpinfo .INTERPINFO_ROOT_NAMESPACE
at present -- awkward but fast. Since global root accesses are supposed
to be rare, awkwardness doesn't bug me for that case. But adding opcodes
for absolute-root ... hey, absolute, that's a good name.
* Huffmanizing shouldn't be as big a consideration with PIR/pasm as with
most languages. Most PIR/pasm is program-generated.
So here's an illustrative suggestion, which I think is a variant on one of
your also-rans, albeit one that leaves the common HLL case unmarked:
.HLL 'perl5', perl5_group
.namespace ['Foo']
$P0 = get_cur_global 'x' # ['perl5';'Foo';'x']
$P0 = get_cur_global ['Bar'], 'x' # ['perl5';'Foo';'Bar';'x']
$P0 = get_global 'x' # ['perl5';'x']
$P0 = get_global ['Corge'], 'x' # ['perl5';'Corge';'x']
$P0 = get_abs_global 'x' # ['x']
$P0 = get_abs_global ['parrot'], 'x' # ['parrot';'x']
(If there is no Null, substitute a null PMC register.)
--
Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 04:44:35PM -0700, jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: Chip Salzenberg wrote: The below patches are my guess as to how to fix PGE and TGE for the recent change in .namespace. (That is, C.namespace [''] now means what it says, and the HLL root is reachable by C.namespace w/o parameters.) TGE and PGE both need a thorough going-over for the new namespaces implementation. meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Indeed, the patch has nothing to do with extending full nested namespace support to TGE and PGE. It's just a regression fix now that .namespace [''] doesn't do what it used to. Unless you're planning to do that overhaul before 0.4.6, I'd like to at least avoid those regressions. -- Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 05:22:47PM -0700, Allison Randal wrote: jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Oh, I didn't mean don't apply it, just there's more work ahead. I can't speak for Patrick, but go ahead and apply the TGE patch. Chip, did you resolve the failing PGE test(s)? Oddly enough, no. I actually made it worse, to my great surprise. Still hacking tho... -- Chip Salzenberg [EMAIL PROTECTED]
Re: PGE and TGE vs. .namespace
On Thu, Jul 06, 2006 at 10:01:39PM -0700, Chip Salzenberg wrote: On Thu, Jul 06, 2006 at 05:22:47PM -0700, Allison Randal wrote: jerry gay wrote: On 7/6/06, Allison Randal [EMAIL PROTECTED] wrote: meanwhile, back at the ranch, perl6 is failing all t/00-parrot/08-regex.t tests due to the .namespace changes. chip's proposed PGE patch fixes those failures. Oh, I didn't mean don't apply it, just there's more work ahead. I can't speak for Patrick, but go ahead and apply the TGE patch. Chip, did you resolve the failing PGE test(s)? Oddly enough, no. Strangely enough, yes. Apparently I hadn't waved enough 'make clean' chickens over the computer. All better now. -- Chip Salzenberg [EMAIL PROTECTED]
HLL root globals and empty keys (was Re: test of get_namespace opcode)
On Sat, Jul 01, 2006 at 03:04:05PM -0700, Matt Diephouse wrote: Chip Salzenberg [EMAIL PROTECTED] wrote: .namespace # no key means the HLL root. That resolves the other ticket I opened yesterday (good). But I'd prefer to have C .namespace [] so that we could also have the matching C find_global [], 'foo' . Otherwise find_global becomes a two step operation for finding globals in the root HLL namespace. Well, that's a bit problematic. The [] syntax is inherited from the key syntax, and keys currently can't be empty. The use of keys is a hack, but it's a very convenient hack at the source code level, and unlikely to change. --- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED -- On the other hand, we could extend the key PMC to represent emptiness, i.e. zero dimensions. This seems useful for namespaces and could even prove useful for real keys. And this makes keys even more compatible with the Array interface, which I think they might need to implement someday anyway. Allison, what do you think of zero-length keys, i.e. having [] construct a Key PMC describing no dimensions of lookup? If we use those we can get rid of the current null-string hack. If zero-length keys are not OK, then... --- PART 3, IN WHICH AN UGLY BUT WORKING HACK IS DESCRIBED -- I introduced a hack in my recent namespace cleanups. I was planning to ask/warn users about it, but then forgot I'd done it, so it's in the svn repo now. The hack is: When find_global or store_global expects a string or PMC to designate (name) a namespace, Parrot takes a null value to name the HLL root namespace. Thus: .sub main :main $P0 = find_global 'Foo', 'bar' $P0() .end .sub bar .end .namespace ['Foo'] .sub bar $P0 = find_global 'bar' # ['parrot';'Foo';'bar'] null $S0 $P1 = find_global $S0, 'bar' # ['parrot';'bar'] .end I don't recommend anyone coding anything to use this feature, because the more I look at it the less I like it: It's still a two-step process, and with kludge factor to boot. Zero-length keys are better, IMO. -- Chip Salzenberg [EMAIL PROTECTED]
Re: [PATCH] #38627: [TODO] fill Parrot_register_move() with code
On Mon, Jul 03, 2006 at 03:39:19PM -0500, Vishal Soni wrote: On Mon, 2006-07-03 at 13:03 -0700, Chip Salzenberg wrote: The use of a fixed constant like MAX_REGISTER doesn't really work; Parrot has an unbounded (if not infinite :-)) number of registers [...] You'll have to use the INTVAL typedef as the data type to hold register numbers. The function prototype is void Parrot_register_move(Interp *interpreter, int n_regs, unsigned char *dest_regs, unsigned char *src_regs, unsigned char temp_reg, reg_move_func mov, reg_move_func mov_alt, void *info); src_regs and dest_regs are pointers to unsigned char. Unsinged char being 1 byte will store 256 distinct values. Hence I declared the MAX_REGISTER to 256. Well look at that. If I'd looked a bit closer at the diffs I might have noticed that myself. That's definitely an RT-able bug. Let me know what case do we need to code for unbounded number of registers or 256 registers for now. The former, please. I'd consider it the beginning of fixing that bug about using 'unsigned char' for registers. The algorithm will need to move away from using adjacency matrix to probably a graph-vertex data structure approach as the adjacency matrix could eat up memory. I don't know if it would help, but Audrey speaks highly of the Judy library: http://judy.sourceforge.net/ which provides sparse dynamic arrays in what is apparently a very efficient way. If Judy would provide the best solution, we could have Parrot use it. -- Chip Salzenberg [EMAIL PROTECTED]
test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 12:22:56AM -0700, [EMAIL PROTECTED] wrote: Another FAILING namespace test: $P0 = new .ResizableStringArray $P0[0] = '' $P1 = get_namespace $P0 I think I (or the pdd) may have been misunderstood: The get_namespace opcode currently accepts keys (and strings). The compiler.'get_namespace'() method accepts arrays. So unless I've missed something in the purpose of your test, it's testing behavior that Parrot isn't trying to provide. -- Chip Salzenberg [EMAIL PROTECTED]
Welcome to parrot-porters
Since Parrot's mission is far bigger (and, in some ways, far smaller :-)) than Perl 6, and I like the idea that the project advertise itself truthfully, so as not to turn away those who aren't interested in Perl: at my request Robert has set up the alias [EMAIL PROTECTED] - perl6-internals@perl.org as a first step that will eventually lead to the list itself being renamed. The old p6i address will always work too. Share Enjoy! -- Chip Salzenberg [EMAIL PROTECTED]
Re: Welcome to parrot-porters
Here at the tail end of the Hackathon, Patrick suggests that while p6i is no longer descriptive, it does have the advantage of abbreviating to a nify token (i.e. p6i). So what, he asks, should be the abbreviation for parrot-porters? Seems to me that common usage will settle out for itself -- there are things too small even for a detail maven like myself to dictate. So it's obviously a sign of detailitis gone awry for me to mention p^2, or refer to the more pedestrian p-p as a safer alternative. Boy, I'm glad I don't concern myself with such minutiae. PS: Yes I really am coding this morning too. :-P -- Chip Salzenberg [EMAIL PROTECTED]
Onward Upward: New Assignments
YAPC is, among other things, a wonderful opportunity to meet and talk face-to-face about things that concern us. This YAPC, one topic was how to get Parrot development on track to make it the VM we all believe it can be. One outcome of these discussions is a bit of a personnel shuffle, to wit: I'm pleased to announce that Allison Randal is taking over as architect of Parrot, and I'm being promoted to pumpking. Allison, of course, needs no introduction; as architect, she will flesh out the vision of a virtual machine for dynamic languages, that's been her primary interest from the beginning. I, on the other hand, am very happy to be diving back into the code where I've learned I'm the happiest. Writing specs and writing code are similar; but when you're done with code, there's a go button, and lights flash and wheels turn. It's the best toy set in the world. :-) So, to me, this is a promotion. Both Allison and I thank Leo for his service as pumpking. He's done a yeoman's job getting parrot releases regular and stable. We're very pleased that Leo is staying on to continue improving parrot internals. Now that I'm going to carry the release cycle burden, he'll have more opportunity to respond to language implementors' issues, making Parrot better for all. Onward upward! *Squawk*! -- Chip Salzenberg [EMAIL PROTECTED]
Re: test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 10:56:26AM -0700, Matt Diephouse wrote: At the top of the pdd: - Add a get_namespace opcode (that takes an --array-- or a multidimensional hash index) [...] =item $P0 = get_namespace $P1 Get the namespace $P1 (an --array-- of names or [...] Gee, you're right, there it is, and strangely enough, the code already supports this idiom [leo++]. I've just gone through the doc and made it more consistent on that point. The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Re: test of get_namespace opcode vs. arrays
On Sat, Jul 01, 2006 at 01:30:40PM -0700, Matt Diephouse wrote: Chip Salzenberg [EMAIL PROTECTED] wrote: The actual bug you've found seems unrelated to the use of the array of strings (vs. a key), as substituting the key version: $P0 = get_namespace [''] still fails. Debugging in progress. It looks like IMCC treats C .namespace [''] as the root HLL namespace (and not as the namespace '' inside of that). So that's where the bug really lies. I've rooted out that bug, but then discovered there's no way left to designate the root HLL namespace, so I've invented .namespace # no key to mean the HLL root. Now it's a matter of making the tests all work (again). :-) -- Chip Salzenberg [EMAIL PROTECTED]
pdd21 vs. find_global
Darn, find_global has collided with pdd21. Currently find_global is prepared to accept a key or a namespace, and distinguishing namespaces from arrays is starting to get just a little too polymorphic for an opcode. I'm thinking that between get_namespace and the untyped namespace interface, find_global is obsolete. Where you would say $P0 = find_global key_or_array, 'foo' you change to $P99 = get_namespace key_or_array $P0 = $P99['foo'] which also incidentally encourages(!) compilers to cache namespace pointers. -- Chip Salzenberg [EMAIL PROTECTED]
pdd23: closure vs. continuation
Just before I committed pdd23 as it currently is, I asked Audrey whether it was better to make handlers continuations or closures. She said it was not important, and to choose whichever is faster. However, I think I erred in choosing continuations. In the continuation model (as in pdd23 at present), the exception handler runs _outside_ the dynamic scope where the exception occurred, which means that dynamically scoped state required to describe, diagnose, or fix the exception is not available. Oops. Allison, if you give me the OK, I'll recast pdd23 in the alternative way I had in mind, where: * exception handlers are closures, * the closures are called _inside_ the dynamic scope where the throw occurred, * a closure returning without executing Ccaught implies I didn't handle it, try the next handler, therefore obviating the rethrow opcode. PS: caught will perhaps be better renamed handled. -- Chip Salzenberg [EMAIL PROTECTED]
Re: Namespaces Redux
On Wed, Jun 28, 2006 at 11:40:28PM -0700, Matt Diephouse wrote: The get_namespace opcode gets namespaces from the root namespace. Should it get namespaces from the HLL namespace instead? The PDD isn't explicit either way [...] It is, actually: =head2 Namespace Opcodes Note that all namespace opcodes operate from the local HLL root namespace. Navigating outside one's own HLL namespace requires either the Cinterpinfo .INTERPINFO_NAMESPACE_ROOT opcode or the get_namespace() compiler PMC method. All namespace opcodes. Is there any reason that [...; ''] and [...] couldn't refer to the same namespace? The design as it stands avoids any special meaning for *any* string. Any string whatsoever is a valid key; any valid key is a valid namespace name. This is a design goal that would be compromised by the '' special case. Tcl uses C .namespace [''] to refer to the root namespace (correctly, I think) and I can't think of any language that would want to differentiate between the two. All you need to disprove this speculation is one counterexample, and the counterexample doesn't even have to exist yet. Also, is there any reason we can't/shouldn't add find_global variants that lookup globals in HLL's? Right now we have find_global_p_p_s. Adding find_global_p_s_p_s would let me reach into Tcl's private very easily instead of having to crawl the namespaces myself. It's three steps rather than one, but it's not crawling, and it's already in the pdd, mostly: .local pmc tcl tcl = compreg tcl .local pmc ns ns = tcl.'get_namespace'(['Foo';'Bar']) I'm cheating a little here because I'm showing you an example with a key (which the docs don't specifically allow) rather than an array (which they do allow), but the point is to demonstrate compiler.get_namespace(). -- Chip Salzenberg [EMAIL PROTECTED]
Re: lexical lookup and OUTER::
On Fri, Jun 23, 2006 at 08:27:04AM -0700, jerry gay wrote: audreyt++ pointed out on #parrot that there doesn't seem to be a way to specify where to start finding lexicals, in support of perl's OUTER::. eg. (from S04): my $x = $OUTER::x; or my $x = OUTER::$x; So OUTER:: is a -starting- point of one scope up? I thought it was a specific notation that the $x you want is exactly one scope up, and if you wanted two scopes up, you had to ask for OUTER::OUTER::$x. Hm: what -is- the meaning of OUTER::OUTER::$x -- search starting two scopes up, going as far as needed? i propose this should be specified using a three-arg form of find_lex find_lex_p_s_i where the third parameter is an integer specifying which level in the lexical chain to start the lookup. I'm not fond of numeric scope counts, but they are cheap and solve this specific problem. So, OK, and thanks for driving this with a test. -- Chip Salzenberg [EMAIL PROTECTED]
