Lua on Parrot @ FPW'07
I gave a talk at the French Perl Workshop last week. The subject was : Languages Implementation with Parrot - A study case: Lua on Parrot. Now, it's available on http://www.parrotcode.org/talks/LuaOnParrot.pdf François.
Re: [DOCS] NCI
On Nov 26, 7:42 am, [EMAIL PROTECTED] (Will Coleda) wrote: # New Ticket Created by Will Coleda # Please include the string: [perl #47826] # in the subject line of all future correspondence about this issue. # URL:http://rt.perl.org/rt3/Ticket/Display.html?id=47826 The NCI information in docs/books is out of date. per codyl on #parrot, the code doesn't compile. The best link so far seems to be at the perlreview in a pay-for article; Need to update the docs for NCI in the repository to be usable. -- Will Coke Coleda [EMAIL PROTECTED] The example in PDD16 - NCI is up-to-date. kjs
[svn:parrot-pdd] r23078 - in trunk: docs/pdds include/parrot src/pmc
Author: allison Date: Mon Nov 26 00:53:05 2007 New Revision: 23078 Modified: trunk/docs/pdds/pdd25_concurrency.pod Changes in other areas also in this revision: Modified: trunk/include/parrot/scheduler.h trunk/src/pmc/task.pmc Log: [concurrency] Priority is an integer value, not a string value. Modified: trunk/docs/pdds/pdd25_concurrency.pod == --- trunk/docs/pdds/pdd25_concurrency.pod (original) +++ trunk/docs/pdds/pdd25_concurrency.pod Mon Nov 26 00:53:05 2007 @@ -311,7 +311,9 @@ Types of tasks include 'event', 'exception', 'io', and 'code'. Possible status values for tasks include 'created', 'invoked', 'inprocess', and 'completed'. The final state of a task is 'destroyed', but is never marked (the task PMC is -removed from the task list and at some later point destroyed by GC). +removed from the task list and at some later point destroyed by GC). The +priority of a task is an integer value between 0 and 100, with 0 as the lowest +priority. The birthtime stamp is the point at which the task was inserted into the task list, and is used for calculating the age of tasks.
Re: [svn:parrot] r22924 - trunk/src/pmc
Patrick R. Michaud wrote: How about 'copy'? Of the above suggestions, 'morph' seems most accurate, and 'new' seems all wrong to me. Of course, if we do it as a variant of 'clone' or 'morph' we might run into trouble when the source operand is itself a class (do we want to copy the class or do we simply want to morph to that type?). I like 'copy', and the idea that it always consistently creates a copy of the object it's passed. We'll probably get some confusion about the distinction between 'copy' and 'clone'. Saying clone creates a new PMC is clear enough. I'll put in a todo ticket. Allison
Re: PAST and OO
So this doesn't get Warnocked: this is a Patrick question. Best to put it in the RT queue. Allison Jonathan Worthington wrote: Hi, In my reading through the PDDs, I came across the new PAST one, which I'm happy to see. I noticed that there is not any class and role definition related PAST nodes. I don't know if that's by design or just because nobody has written a spec and implementation yet. I think that since many languages have such OO constructs, it would be a Good Thing to get PAST to do some of the work. So, I spent a few moments putting together a proposal for something that could work. I don't know if it's along the right lines or not - I've not really contributed to PAST so far so I'm just doing what feels right. I hope it may be useful or a starting point, anyway. I've supplied it as a diff against the PDD. If such PAST nodes are wanted, and once we've got a spec for them ironed out, I'd be interested to have a crack at the implementation too. Hope this is useful, Jonathan
[perl #46681] [TODO] [C] Use strerror_r instead of strerror
Ok, here's try two. Platform specific stuff has been moved into
config/gen/platform, and non-win32 platforms use strerror_r directly.
On Fri Nov 23 01:29:35 2007, kjs wrote:
On Nov 22, 2007 9:03 PM, Joe Sadusk via RT
[EMAIL PROTECTED] wrote:
Reposting this because this is my first patch, and it didn't occur to me
that if I don't CC perl6-internals, no one would notice it.
It turns out that strerror_r is POSIX only, and windows has the slightly
different strerror_s (exactly the same except the arguments are in a
different order). I defined a macro that abstracts this, but I don't
know if there's a standard header file cross platform macros like this
are put in, so I put it inline in the pmc. If anyone has a suggestion of
where this belongs, I'll gladly move it.
I'm no expert on this, but in config/gen/platform, there are
subdirectories that contain files that do platform dependent stuff.
(I only know this because I once added
config/gen/platform/win32/string.h, which defines a macro for strdup
for MSVC users.)
I suspect that your macro should go in a similar file, but this should
be confirmed by someone with more knowledge on this.
kjs
diff --git a/config/gen/platform/generic/string.h b/config/gen/platform/generic/string.h
new file mode 100644
index 000..8de1ca1
--- /dev/null
+++ b/config/gen/platform/generic/string.h
@@ -0,0 +1,22 @@
+/*
+ * $Id$
+ * Copyright (C) 2004-2007, The Perl Foundation.
+ */
+
+#ifndef PARROT_PLATFORM_GENERIC_STRING_H_GUARD
+#define PARROT_PLATFORM_GENERIC_STRING_H_GUARD
+
+#if defined __GLIBC__
+# define _XOPEN_SOURCE 600
+#endif
+
+#include string.h
+
+#endif /* PARROT_PLATFORM_GENERIC_STRING_H_GUARD */
+
+/*
+ * Local variables:
+ * c-file-style: parrot
+ * End:
+ * vim: expandtab shiftwidth=4:
+ */
diff --git a/config/gen/platform/win32/string.h b/config/gen/platform/win32/string.h
index 607745a..bd47db3 100644
--- a/config/gen/platform/win32/string.h
+++ b/config/gen/platform/win32/string.h
@@ -14,6 +14,8 @@
# endif
#endif
+#define strerror_r(errnum, buf, buflen) strerror_s(buf, buflen, errnum)
+
#endif /* PARROT_PLATFORM_WIN32_STRING_H_GUARD */
/*
diff --git a/src/pmc/file.pmc b/src/pmc/file.pmc
index 3c8d801..56be62d 100644
--- a/src/pmc/file.pmc
+++ b/src/pmc/file.pmc
@@ -27,6 +27,13 @@ CFile is a singleton class which provides access to File functions.
/* RT#46679 Check if we need to deallocate strerror strings */
/* RT#46681 apparently, strerror_r is thread-safe and should be used instead.*/
+/* strerror_r should truncate the message if its too long for the supplied buffer
+ * its probably best to just specify a sane default buffer size than to worry
+ * about retrying calls
+ */
+#define ERRBUF_SIZE 128
+
+
static PMC *File_PMC;
pmclass File singleton {
@@ -98,7 +105,8 @@ Returns a true value (1) if the supplied path is a directory.
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
+char errmsg[ERRBUF_SIZE];
+strerror_r(errno, errmsg, ERRBUF_SIZE);
real_exception(interp, NULL, E_SystemError, errmsg);
}
@@ -129,7 +137,8 @@ Returns a true value (1) if the supplied path is a plain file.
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
+char errmsg[ERRBUF_SIZE];
+strerror_r(errno, errmsg, ERRBUF_SIZE);
real_exception(interp, NULL, E_SystemError, errmsg);
}
@@ -162,7 +171,8 @@ Returns a true value (1) if the supplied path is a link.
string_cstring_free(cpath);
if (error) {
-char *errmsg = strerror(errno);
+char errmsg[ERRBUF_SIZE];
+strerror_r(errno, errmsg, ERRBUF_SIZE);
real_exception(interp, NULL, E_SystemError, errmsg);
}
@@ -197,6 +207,8 @@ free to change or give me hints on how to change it. -- ambs
FILE *source = fopen(cfrom, rb);
+char errmsg[ERRBUF_SIZE];
+
if (source) {
FILE *target = fopen(cto, w+b);
@@ -218,13 +230,13 @@ free to change or give me hints on how to change it. -- ambs
fclose(target);
}
else {
-char *errmsg = strerror(errno);
+strerror_r(errno, errmsg, ERRBUF_SIZE);
real_exception(interp, NULL, E_SystemError, errmsg);
}
fclose(source);
}
else {
-char *errmsg = strerror(errno);
+strerror_r(errno, errmsg, ERRBUF_SIZE);
real_exception(interp, NULL, E_SystemError, errmsg);
}
string_cstring_free(cfrom);
@@ -251,7 +263,8 @@ Rename a file Cfrom to the path Cto.
string_cstring_free(cto);
if (error) {
-char *errmsg = strerror(errno);
+char errmsg[ERRBUF_SIZE];
+strerror_r(errno, errmsg, ERRBUF_SIZE);
Re: Current roadmap for Perl 6 on Parrot
Hi, here/hear, hear/here, on the 'ghost town' point... it's an immense surprise given the size of CPAN that there is such a 'ghost town' feel about some (if not all) of Perl6... Regards, K On Nov 25, 2007 2:58 PM, brian d foy [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Patrick R. Michaud [EMAIL PROTECTED] wrote: How others can start hacking and contributing - If you're interested in hacking on the compiler, my suggestion is to become somewhat familiar with the compiler tools already available in Parrot. I'm not interested in hacking on the compiler, but I am interested in writing tests. I've added some to the Pugs project, but that seems to be a ghost town now. Is there a new plan for tests besides adding them to the Pugs code? I'm not really into writing tests that won't ever pass in Pugs. :) -- Outside the mind, there is no Lotus Sutra.. outside the Lotus Sutra, there is no mind... (Hakuin) I correctly predicted that you'd eventually read this... (Kevin von Spiel) The word 'ergodic' has several meanings, probabilists tend to use it rather carelessly. We conform to this custom here. (Geoffrey Grimmett David Stirzaker) I choose to live my life in the company of Gandhi King. My concerns are global. I reject, absolutely, revenge, aggression, retaliation. The foundation of such a method, is love. I love you Sheriff Truman.. (Albert Rosenfield) ((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x ((lambda (x) (list x (list 'quote x))) '(lambda (x) (list x (list 'quote x If I've worked out anything over the course of this life... well, it's this: the smarter we become, the more stupid we become... we can't help it... it's how the whole thing works... (Richard Weatherman)
[perl #47828] [TODO] Implement the 'copy' opcode
# New Ticket Created by Allison Randal # Please include the string: [perl #47828] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47828 The 'copy' opcode is similar to 'clone' but it reuses the PMC header of the destination register. It takes two PMC arguments. The opcode will be implemented by calling the 'morph' and 'assign' vtable functions. Allison
Re: [svn:parrot] r22924 - trunk/src/pmc
On Nov 26, 2007 10:01 AM, Allison Randal [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: How about 'copy'? Of the above suggestions, 'morph' seems most accurate, and 'new' seems all wrong to me. Of course, if we do it as a variant of 'clone' or 'morph' we might run into trouble when the source operand is itself a class (do we want to copy the class or do we simply want to morph to that type?). I like 'copy', and the idea that it always consistently creates a copy of the object it's passed. We'll probably get some confusion about the distinction between 'copy' and 'clone'. Saying clone creates a new PMC is clear enough. I'll put in a todo ticket. What do you get if you 'copy' an object? kjs
[perl #47846] [RFC] Remove .emit/.eom pair from PIR language.
# New Ticket Created by Klaas-Jan Stol # Please include the string: [perl #47846] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47846 From the beginning IMCC has had the .emit/.eom pair of directives. The idea is that they can be used to emit pure pasm instructions, without the need for any .sub. An example is this: .sub main print hi! .end .emit print there set I0, 42 print I0 .eom However, this feature is never used. If you ack for .emit or .eom, the only files that contain these words are the PIR compilers (compilers/imcc, compilers/pirc) and the test files for these compilers. Moreover, it seems it's a rather useless as well. If you compile the above example to PASM (using parrot -o - test.pir), the result will be: main: print hi! set_returns returncc # == leaving here print there set I0, 42 print I0 So, in other words, these instructions are never executed. The only case in which it would be useful would if this instruction block would get a label, but in that case it would be better to use a pir .sub. Summarizing, IMHO this feature can be removed. Comments welcome, kjs
Re: [svn:parrot] r22924 - trunk/src/pmc
Klaas-Jan Stol wrote: On Nov 26, 2007 10:01 AM, Allison Randal [EMAIL PROTECTED] wrote: I like 'copy', and the idea that it always consistently creates a copy of the object it's passed. We'll probably get some confusion about the distinction between 'copy' and 'clone'. Saying clone creates a new PMC is clear enough. I'll put in a todo ticket. What do you get if you 'copy' an object? copy $P1, $P2 This creates a PMC that reuses the PMC header of $P1, morphing it to be the same type of object as $P2 (an instance of the same class), and copying the data from $P2 to $P1. Allison
Re: [perl #47846] [RFC] Remove .emit/.eom pair from PIR language.
Klaas-Jan Stol (via RT) wrote: Summarizing, IMHO this feature can be removed. Thumbs up. Allison
Re: [perl #47794] [BUG] objects - :method doesn't work with :outer()
Patrick R.Michaud (via RT) wrote:
This isn't a super-huge priority at the moment... for the
time being we can simply have PCT not attach any :outer
flags to methods. But eventually we'll probably want to
have this working.
Can you give me an HLL use case, so we get the implementation right? A
.sub marked with :outer is one that's lexically scoped inside another
.sub. So, a method marked with :outer is a method that's defined within
another method/sub. Something like:
method foo ($a, $b, $c) {
...
method bar ($x, $y, $z) {
...
}
...
}
Is that what you're looking for?
Allison
Re: [perl #47794] [BUG] objects - :method doesn't work with :outer()
On Mon, Nov 26, 2007 at 04:01:37PM +0200, Allison Randal wrote:
Patrick R.Michaud (via RT) wrote:
This isn't a super-huge priority at the moment... for the
time being we can simply have PCT not attach any :outer
flags to methods. But eventually we'll probably want to
have this working.
Can you give me an HLL use case, so we get the implementation right? A
.sub marked with :outer is one that's lexically scoped inside another
.sub. So, a method marked with :outer is a method that's defined within
another method/sub. Something like:
method foo ($a, $b, $c) {
...
method bar ($x, $y, $z) {
...
}
...
}
Is that what you're looking for?
In Perl 6:
class ABC {
my $x = 0;
method foo() {
$x = $x + 1;
}
method bar() {
say $x;
}
}
$x is lexically scoped, which means that methods foo and bar
need to be marked with the class block as their :outer scopes.
Similar considerations may apply for inner classes, where we
end up with methods (of an inner class) inside of other blocks.
Pm
Re: PAST and OO
On Mon, Nov 26, 2007 at 11:29:23AM +0200, Allison Randal wrote: So this doesn't get Warnocked: this is a Patrick question. Best to put it in the RT queue. I'll go ahead and answer it here, now that I have an answer. :-) In my reading through the PDDs, I came across the new PAST one, which I'm happy to see. I noticed that there is not any class and role definition related PAST nodes. I don't know if that's by design or just because nobody has written a spec and implementation yet. I think that since many languages have such OO constructs, it would be a Good Thing to get PAST to do some of the work. Actually, after adding class/method support to NQP yesterday I think I've concluded that PAST doesn't really need new node types to support this, it just needed a couple of additional attributes on existing types [1]. My goal for PAST-pm was to take care of the things that were common to a bunch of languages (e.g., short-circuiting ops), and then let each language take care of the things that are somewhat special to the language. Given that so many languages have differing interpretations of various OO constructs and OO metamodels, for now I think it's perhaps better if PAST gives only a little support and lets language-specific OO stuff be in the things that are special group. Also, since interacting with Parrot's OO model is now primarily done via methods on class objects and protoobjects, PAST's callmethod op seems to be able to handle most of the work. Of course, if we later discover that additional PAST node types would be useful for a wide variety of languages, we can add them. Thus far in looking at NQP, perl6, and pynie, I think I'm slightly more comfortable with the existing types and a somewhat simpler PAST implementation. So, for now, I've added a method blocktype for PAST::Block nodes to the spec, and I'm thinking that instance attributes will end up being handled with an attribute scope in the PAST::Var nodes. Thanks! Pm 1. At the moment I'm a bit biased towards having fewer PAST node classes with attributes to distinguish subtypes. When building an ast I'm finding it's much easier to change an attribute on an existing node than it would be to try to copy or rebless a node into a different subclass. Likewise, the POST generation also seems to be slightly easier with fewer node types and some judicious use of attributes and MMD as method selectors.
Parrot Bug Summary
Parrot Bug Summary http://rt.perl.org/rt3/NoAuth/parrot/Overview.html Generated at Mon Nov 26 14:00:09 2007 GMT --- * Numbers * New Issues * Overview of Open Issues * Ticket Status By Version * Requestors with most open tickets --- Numbers Ticket Counts: 34 new + 731 open = 765 Created this week: 15 Closed this week: 19 --- New Issues New issues that have not been responded to yet 1 - 2 weeks old 2 - 3 weeks old 3 - 4 weeks old 47153 [PATCH][Review] Proposed change from PMC_IS_NULL to PMC_is_null 47141 [PDD19] Line directive 47109 [CAGE] wrap macro args in parens inside macro bodies 47011 [TODO] VTABLE method 'new_from_string' is deprecated 4 - 5 weeks old 46971 [DEPRECATED] newfrom sub/method in PGE 46933 [PATCH] [RFE] Change behavior of Data::Dumper wrt Undef 46925 [TODO] [C] Call pmc slicing functions from PackFiles thaw() 46923 [TODO] [C] Check flags of parrot_range object in elements() method Slice PMC 46761 Dynpmcs and ParrotLibrary Global Destruction 46757 [BUG] Segfault in Parrot_TclString_nci_get_list 5 - 6 weeks old 46597 wrong NOTNULL in Parrot_init_arg_indexes_and_sig_pmc 46593 [PATCH] better documentation on parameter passing 46479 Remove rt.saved.search from tools/util/release.json? 46457 [BUG][IMCC] long sub invocation with named parameters 6 - 7 weeks old 46437 refactor interpreter cloning so it doesn't redundantly reinsert subs 46295 [CAGE] [pdd15oo] Review the docs w.r.t. the new OO implementation 7 - 8 weeks old 8 - 9 weeks old 45857 [IMCC][RFC] #line vs .line 9 - 10 weeks old 45659 Tcl - [string is double .1] returns wrong value 45565 Random failures in t/perl/Parrot_Docs.t 45503 one test in 't/op/string.t' is failling for jit runcore 10 - 11 weeks old 11 - 12 weeks old 12 - 13 weeks old 13 - 14 weeks old 44979 [BUG] TGE reports an error, but won't say which line it's on. 44851 Update step 2.f in release_manager_guide.pod 14 - 15 weeks old 44765 [PATCH] Don't reuse interpreter argument on stack 15 - 16 weeks old 44471 [PATCH] :vtable is ignored when :anon 16 - 17 weeks old 17 - 18 weeks old 44139 opcodes, warnings, and exceptions 18 - 19 weeks old 19 - 20 weeks old 20 - 21 weeks old --- Overview of Open Issues PlatformSeverity Tag Lang aix0abandoned 0 5005threads 0 Amber0 All3fatal 3 bounce0 BASIC0 bsdos 0High 0 Bug 68 bc 0 cygwin 4low 1 compiler 0 befunge 0 cygwin_nt 0medium0 configure 0 bf 0 darwin 5none 0 core 0 cola 0 dec_osf0Normal1 dailybuild0 forth0 dgux 0unknown 0 docs 2 jako 0 dos0Wishlist 3 duplicate 0 Lisp 1 dynixptx 0 install 1 m4 0 freebsd8 library 0 ook 0 generic0 notabug 0 perl61 gnu0 notok 0 plot 0 HPUX 2 ok0 punie0 irix 0 Patch47 pynie2 irix64 0 regex 0 python 0 Linux 3 sendToCPAN0 ruby 0 lynxos 0 Todo453 scheme 0 mac0 unknown 0 tcl 72 machten0 utilities 0 urm 0 macos 0 wontfix 0 Zcode0 MacOS X2 mswin320 netbsd 1 next 0 openbsd2 os20 os390 0 other 0 powerux0 qnx0 riscos 0 sco0 Solaris4 sunos 1 svr4 0 svr5 0 sysv 0 unicos 0 unicosmk 0 unix 0 unknown0 uts0 vms0 VOS0 Win32 10 --- Ticket Status By Version New or OpenResolved --- Requestors with most open tickets Paul Cochrane 330 Will Coleda52 James Keenan 46 Jerry Gay 38 chromatic 28 jerry gay 23 Matt Diephouse 20 Bernhard Schmalhofer 16 Klaas-Jan Stol 15 Leopold Toetsch
Re: [perl #47828] [TODO] Implement the 'copy' opcode
On Mon, Nov 26, 2007 at 01:03:32AM -0800, Allison Randal wrote: The 'copy' opcode is similar to 'clone' but it reuses the PMC header of the destination register. It takes two PMC arguments. The opcode will be implemented by calling the 'morph' and 'assign' vtable functions. Just a note that there are a lot of the built-in types -- especially the aggregate and subroutine types -- that don't currently have implementations of 'assign'. This is why I've been favoring solutions that somehow use clone instead of morph+assign . Pm assign implemented. Allison
Re: [svn:parrot] r22924 - trunk/src/pmc
On Mon, Nov 26, 2007 at 11:01:56AM +0200, Allison Randal wrote: Patrick R. Michaud wrote: How about 'copy'? I like 'copy', and the idea that it always consistently creates a copy of the object it's passed. We'll probably get some confusion about the distinction between 'copy' and 'clone'. Saying clone creates a new PMC is clear enough. I'll put in a todo ticket. Excellent, thanks. Pm
Re: [perl #47828] [TODO] Implement the 'copy' opcode
On Mon, Nov 26, 2007 at 09:03:38AM -0600, Patrick R. Michaud wrote: On Mon, Nov 26, 2007 at 01:03:32AM -0800, Allison Randal wrote: The 'copy' opcode is similar to 'clone' but it reuses the PMC header of the destination register. It takes two PMC arguments. The opcode will be implemented by calling the 'morph' and 'assign' vtable functions. Just a note that there are a lot of the built-in types -- especially the aggregate and subroutine types -- that don't currently have implementations of 'assign'. This is why I've been favoring solutions that somehow use clone instead of morph+assign . On the other hand, since the primary reason for having a 'copy' opcode is to be able to implement variations of 'assign', using 'morph' and 'assign' vtable functions might be more accurate. So, I'm not as much in favor of using clone as before, and will leave it up to wiser heads and implementors to decide. :-) Pm
[perl #47852] [TODO] remove codestring-pmc branch
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #47852] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47852 15:50 pmichaud coke: can we get rid of the codestring-pmc branch? 15:51 Coke as long as someone verifies there isn't any work in progress there. =-) 15:51 Coke If you open a ticket, I'll try to remember to do it later tonight. Pm
[perl #45023] SUGGESTION inlining subs
On Tue Sep 11 11:11:39 2007, bernhard wrote: Patrick R. Michaud schrieb: On Tue, Aug 28, 2007 at 09:37:39AM -0700, Debbie Harry wrote: # New Ticket Created by Debbie Harry # Please include the string: [perl #45023] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45023 Maybe it would be useful to support inlining of subs (at PIR level?) This would support good programming style. Well, I'm a bit confused as to what's being asked here, so I'll go ahead and ask for some clarification. Are you asking for the ability to define subs in PIR such that any PIR-based calls to those subs are then inlined? Or are you looking at this from more of a high-level language (HLL) perspective, such that someone writing in a HLL can designate certain blocks as being suitable for inlining? I remember this as a conversation I had with a German guy at YAPC::EU. The idea was optimisation of PIR code. Avoid the overhead of argument passing by inlining subs in the PBC. My suggestion was to start a discussion by submitting an RT ticket for that idea. Ah. Handling things at the bytecode level is a bit beyond where I currently work, so I can't say how difficult or likely this is to happen anytime soon. I'd like to either stall this ticket, resolve it, or pass it off to someone else. Pm
[perl #39913] [BUG] TGE - Can't use } in the transform definitions.
On Sun Jul 23 06:35:21 2006, coke wrote:
The TGE grammar doesn't deal with embedded }'s:
Invalid:
transform a (b) {
# do nothing}
}
transform a (b) {
# do {nothing}
}
If we still need this, I vote that tge transforms require the
closing brace to be at the beginning of a line (possibly preceded by
whitespace).
If we don't need this, I vote that we close the ticket.
FWIW, none of PGE, PCT, and NQP are using TGE.
Pm
[perl #44851] Update step 2.f in release_manager_guide.pod
It looks as though the 0.4.15, 0.4.16, and 0.5.0 releases were all made without updating PBC_COMPAT, with no ill effects. So, I've now removed item f (update PBC_COMPAT) from the release_manager_guide.pod and I'm marking this ticket as resolved. Pm
Re: [perl #46681] [TODO] [C] Use strerror_r instead of strerror
On Sunday 25 November 2007 21:48:01 Joe Sadusk via RT wrote: Ok, here's try two. Platform specific stuff has been moved into config/gen/platform, and non-win32 platforms use strerror_r directly. Change its to it's in the comment before #define ERRBUF_SIZE and this patch looks reasonable to me, if it passes on Windows and Unixy platforms. -- c
[perl #47854] [BUG] r22956 breaks perl6
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #47854] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47854 The perl6 compiler no longer runs or passes tests after r22956 (r22955 appears to work fine). The log for r22956 reads: r22956 | chromatic | 2007-11-22 03:59:23 -0600 (Thu, 22 Nov 2007) | 2 lines [PMC] Fixed a minor memory leak with String PMC (only affected that weird constant string workaround exposed by HLL interactions). Pm
Re: [perl #47854] [BUG] r22956 breaks perl6
On Monday 26 November 2007 10:52:41 Patrick R.Michaud wrote: The perl6 compiler no longer runs or passes tests after r22956 (r22955 appears to work fine). The log for r22956 reads: r22956 | chromatic | 2007-11-22 03:59:23 -0600 (Thu, 22 Nov 2007) | 2 lines [PMC] Fixed a minor memory leak with String PMC (only affected that weird constant string workaround exposed by HLL interactions). You're right. That patch looks obviously wrong now, so please feel free to revert it. -- c
Re: [perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
James E Keenan schrieb: On Nov 25, 2007, at 12:52 PM, Paul Cochrane via RT wrote: This error has been happening in dotnet for a long time. I can't give you a better timeframe than that, but it's been in that state (giving these warnings) since before I managed to get it's Configure.pl to go again, (which was a few months ago now). Paul: I really have to wonder about that. In my work, I am *constantly* running: svn update;perl Configure.pl ... and I only started to get this error today. As I was offline for a couple of days, the error has to have crept in since Thursday. The difference is that the root Configure.pl is now also generating 'language/dotnet/Makefile' by executing 'cd languages/dotnet; perl Configure.pl' in gen::languages. Previously 'languages/dotnet/Makefile' was only generated when 'cd languages/dotnet; perl Configure.pl' was called manually. Generating 'language/dotnet/Makefile' by the root Configure.pl became necessary, because I made 'make realclean' more thorough in cleaning up. As far as I see it, the output that are seen are harmless warnings from 'languages/dotnet/Configure.pl'. If nobody beats me to it, I take a look at it after experimenting with 'languages/plumhead/Configure.pl'. Regards, Bernhard
[perl #47858] make vim-install not working
# New Ticket Created by Johannes Barop # Please include the string: [perl #47858] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47858 Hi, I think there is a type-error in the Makefile or a file is named wrong. make found a missing target pir.vim.in Renaming the pir_vim.in to pir.vim.in seems to fix it. [EMAIL PROTECTED]:~/parrot/editor$ make vim-install make: *** Keine Regel vorhanden, um das Target »pir.vim.in«, benötigt von »pir.vim«, zu erstellen. Schluss. [EMAIL PROTECTED]:~/parrot/editor$ cp pir_vim.in pir.vim.in [EMAIL PROTECTED]:~/parrot/editor$ make vim-install /usr/bin/perl -MExtUtils::Command -e cp pir.vim.in pir.vim /usr/bin/perl ops2vim.pl ../src/ops/*.ops pir.vim /usr/bin/perl -MExtUtils::Command -e mkpath /home/seminar/.vim /usr/bin/perl -MExtUtils::Command -e cp skeleton.pir /home/seminar/.vim /usr/bin/perl -MExtUtils::Command -e mkpath /home/seminar/.vim/syntax /usr/bin/perl -MExtUtils::Command -e cp pir.vim /home/seminar/.vim/syntax /usr/bin/perl -MExtUtils::Command -e cp pasm.vim /home/seminar/.vim/syntax /usr/bin/perl -MExtUtils::Command -e cp pmc.vim /home/seminar/.vim/syntax /usr/bin/perl -MExtUtils::Command -e mkpath /home/seminar/.vim/plugin /usr/bin/perl -MExtUtils::Command -e cp filetype_parrot.vim /home/seminar/.vim/plugin/parrot.vim /usr/bin/perl -MExtUtils::Command -e mkpath /home/seminar/.vim/indent /usr/bin/perl -MExtUtils::Command -e cp indent_pir.vim /home/seminar/.vim/indent/pir.vim [EMAIL PROTECTED]:~/parrot/editor$
Re: [perl #47858] make vim-install not working
On Monday 26 November 2007 11:48:29 Johannes Barop wrote: I think there is a type-error in the Makefile or a file is named wrong. make found a missing target pir.vim.in Renaming the pir_vim.in to pir.vim.in seems to fix it. Thanks for the report! We renamed files a while back to get rid of multiple dots in filenames, but we missed updating this Makefile's target. Fixed in r23097. -- c
Re: [perl #47854] [BUG] r22956 breaks perl6
On Monday 26 November 2007 10:52:41 Patrick R.Michaud wrote: The perl6 compiler no longer runs or passes tests after r22956 (r22955 appears to work fine). The log for r22956 reads: r22956 | chromatic | 2007-11-22 03:59:23 -0600 (Thu, 22 Nov 2007) | 2 lines [PMC] Fixed a minor memory leak with String PMC (only affected that weird constant string workaround exposed by HLL interactions). Reverted in r23100. -- c
[svn:parrot-pdd] r23101 - in trunk: compilers/pct/src/PAST docs/pdds
Author: pmichaud Date: Mon Nov 26 14:05:02 2007 New Revision: 23101 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PAST/Compiler.pir trunk/compilers/pct/src/PAST/Node.pir Log: [pct]: * Add support for n_neg and n_mod opcodes. * Add lvalue support to PAST. * Change 'islvalue' and 'isslurpy' flags to be 'lvalue' and 'slurpy'. Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Mon Nov 26 14:05:02 2007 @@ -166,7 +166,7 @@ for the Cnamed attribute. Optional parameters are identified via the Cviviself attribute (see below) indicating how the parameter is to be initialized if not supplied by the caller. Slurpy parameters -are indicated via the node's Cisslurpy attribute. +are indicated via the node's Cslurpy attribute. =item keyed @@ -210,19 +210,19 @@ scope. Otherwise, the node refers to a pre-existing variable (possibly from an outer scope). -=item islvalue([flag]) +=item lvalue([flag]) -Accessor method for the Cislvalue attribute, which indicates +Accessor method for the Clvalue attribute, which indicates whether this variable is being used in an lvalue context. -=item isslurpy([flag]) +=item slurpy([flag]) -Accessor method for the Cisslurpy attribute of parameter variables. -A true value of Cisslurpy indicates that the parameter variable +Accessor method for the Cslurpy attribute of parameter variables. +A true value of Cslurpy indicates that the parameter variable given by this node is to be created as a slurpy parameter (consuming all remaining arguments passed in). Named slurpy parameters are indicated by having a non-empty Cnamed attribute and a true value of -Cisslurpy. +Cslurpy. =back @@ -377,7 +377,7 @@ The table of PIR opcodes that PAST knows about is given in Fcompilers/pct/src/POST/Node.pir . -=item islvalue([flag]) +=item lvalue([flag]) Get/set whether this node is an lvalue, or treats its first child as an lvalue (e.g., for assignment).
[perl #47792] [BUG]: languages/dotnet/Configure.pl causes configuration error
On Sun Nov 25 20:00:10 2007, coke wrote: fixed in r23065. Note: While these reverts cleared up the problem going forward, even after doing 'svn update' I was unable to successfully do 'make realclean'. I had to blow away my sandbox and checkout a new sandbox of trunk in order to be able to 'make realclean' after my first Configure.pl. So anyone else who is having trouble with 'make realclean' will probably have to do likewise. Thank you very much. kid51
TGE Status?
There are a few tickets in RT for TGE; 44979, 43757, 40002, 39913... However, I noted after talking to Patrick earlier today that TGE isn't currently in use in the new toolchain. Anyone have plans for TGE going forward? Will it eventually be phased out in favor of the other pct tools? -- Will Delete more stuff from the repository Coleda [EMAIL PROTECTED]
[svn:parrot-pdd] r23124 - in trunk: compilers/pct/src/PAST docs/pdds
Author: pmichaud Date: Mon Nov 26 22:27:07 2007 New Revision: 23124 Modified: trunk/docs/pdds/pdd26_ast.pod Changes in other areas also in this revision: Modified: trunk/compilers/pct/src/PAST/Compiler.pir trunk/compilers/pct/src/PAST/Node.pir Log: [pct]: * Add 'returns' attribute to PAST::Val nodes. Modified: trunk/docs/pdds/pdd26_ast.pod == --- trunk/docs/pdds/pdd26_ast.pod (original) +++ trunk/docs/pdds/pdd26_ast.pod Mon Nov 26 22:27:07 2007 @@ -118,6 +118,12 @@ Accessor method to get/set the constant value for this node. +=item returns([typename]) + +Get/set the type of value to be generated by this node. +If not specified, the type is taken from the type of +the value attribute given above. + =back =head2 PAST::Var
'abc' now written in nqp
Well, after a long and very fruitful day of hacking, the 'abc' compiler in Parrot is now written mostly in PGE and NQP, with all tests passing. 'abc' is an implementation of a basic calculator (like the unix bc(1) command) for Parrot. While abc does support a lot of bc features, the primary purpose of abc is to serve as a simple example and tutorial of using the various Parrot toolkits to build compilers for Parrot. Previously abc was written using a mixture of tools using a variety of languages. After today's efforts abc is now written with only * a Perl 6 grammar (src/grammar.pg), * some NQP code to build an ast from the parse tree (src/grammar-actions.pg) * the Parrot Compiler Toolkit library (PCT) * and some PIR for setup and builtin functions (abc.pir, src/builtins.pir) In other words, the bulk of the code for the abc compiler is written in Perl 6. With this we've been able to basically prove the workability of NQP and the Parrot Compiler Toolkit, and the next step is to start redesigning the perl6 compiler to use the same approach. I also need to add a lot of documentation to the abc source files, to make it clearer as to what is happening at each step. But I think that will have to wait for me to get some sleep first. Pm
