First public release of grammar engine
I've just committed the first draft of a Perl 6 grammar engine to the parrot repository (in compilers/p6ge). What you'll find there is still at a somewhat early stage of development, I'm releasing it now so that people can begin commenting and suggesting improvements to the framework. The next big items to be developed are a test harness and hopefully lots of tests, as well as to begin sniffing through the code for bugs. I know there are plenty of optimizations that can and should be added to the system, but I'm going to focus on filling out the feature set a fair bit more before I worry about much more in the way of optimization. I'll have more details in a subsequent email (I only have a few minutes at the moment to generate this one). A copy of the README file that describes P6GE in more detail is below. I'll be directing most of the comments and discussion about P6GE onto the perl6-compiler mailing list, so that it doesn't interfere too much with perl6-internals (and vice-versa). Pm compilers/p6ge/README =head1 Perl 6 Grammar Engine (P6GE) This is an initial implementation of a Perl 6 Grammar Engine designed to run in Parrot. It's definitely a work in progress, and much of the current implementation is designed simply to bootstrap us along (i.e., some parts such as the parser and generator are expected to be discarded). The current work is also largely incomplete -- although it has support for groups (capturing and non-capturing), quantifiers, alterations, etc., many of the standard assertions and character classes are not implemented yet but will be coming soon. In addition there's some experimental work here in being able to parse and convert Perl *5* regular expressions into PIR subroutines, but the focus should be on building the perl6 capabilities first and we'll fold in perl 5 syntax a bit later. =head1 Installation P6GE assumes that it is part of the parrot distribution in the Fcompilers/p6ge directory. Simply type Cmake in this directory to build the Fp6ge.so shared library it needs. You can either leave this file in the current directory (and set LD_LIBRARY_PATH or equivalent appropriately), or move it to Fruntime/parrot/dynext. (XXX: Need to update Parrot configure so this happens automatically?) The distribution comes with a small Fdemo.pir program that gives an example of using P6GE. To run the demo, simply do Cparrot demo.pir. In the demo, you can use a leading slash to enter a rule to be compiled (note: no trailing slash), you can enter a string to be matched against the previously entered rule, you can enter a ? to see the PIR subroutine for the rule, and you can enter a + to re-invoke the rule on the previous string. If you get errors about cannot open shared object file, that usually means that Parrot was unable to locate the p6ge.so object file. =head1 Using P6GE Because I couldn't find a lot of detailed information about writing a Parrot compiler in C, I went ahead and wrote this using Parrot's native call interface. Essentially the library provides a Cp6ge_p6rule_pir() function that builds a PIR code string from a given rule string, this PIR code string can then be sent to the PIR compiler to get a final subroutine. (Having the PIR code string easily available and printable is also very handy for debugging as we build the rest of the grammar engine.) Here's a short example for compiling a regular expression and then matching it against another string: load_bytecode p6ge.pir .local pmc p6ge_compile p6ge_compile = global _p6ge_compile # get the compiler .local string pattern .local pmc rulesub set pattern, ^(From|Subject):# pattern to compile rulesub = p6ge_compile(pattern)# compile it to rulesub .local pmc match $S0 = From: [EMAIL PROTECTED] # target string match = rulesub($S0) # execute rule on target string match_loop: unless match goto match_fail # if match fails stop print match succeeded\n match._print() # display captures ($0, $1, etc.) match._next()# find the next match goto match_loop match_fail: print match failed\n One can also get the intermediate PIR code that P6GE generates for the rule subroutine -- just use (rule, $S0) = p6ge_compile(target) and you can print/inspect the contents of $S0 to see the generated code. =head1 Known Limitations At the moment, P6GE is not very aware of Unicode strings -- it's pretty much limited to 8-bit Latin-1 characters in patterns. This is because the P6GE parser is still in C, and because support for character class operations in Parrot is still being worked out. Eventually these things will be resolved and we'll fix P6GE up for Unicode then. Most of the backslash sequences (\d, \D, \N, etc.) are unimplemented, although backslashes do properly escape metacharacters in
[PATCH] for languages/perl6/perl6 --tree
Hello,
by executing the command perl6 --tree there is to seen the following
error message:
[EMAIL PROTECTED] perl6]$ perl ./perl6 --tree -e 'print alf';
Can't call method tree on an undefined value at ./perl6 line 418.
[EMAIL PROTECTED] perl6]$
The problem is that the function $parser-prog only returns a value
if the function P6C::IMCC::init() is called first.
So I fixed the program languages/perl6/perl6 that the modul
P6C::IMCC is loaded and also the function P6C::IMCC::init is
called generally. There is no need not to call it when the
option --tree is used. At the end of this mail I add my changes.
Gerd
[EMAIL PROTECTED] perl6]$ diff -u perl6 perl6.parse_tree
--- perl6 2004-11-17 13:14:32.902467776 +0100
+++ perl6.parse_tree2004-11-17 13:20:42.238320192 +0100
@@ -473,10 +473,9 @@
$Data::Dumper::Indent = 1;
END
die $@ if $@;
-} else {
- eval 'use P6C::IMCC qw(:external)';
- die $@ if $@;
}
+eval 'use P6C::IMCC qw(:external)';
+die $@ if $@;
if (!$OPT{'force-grammar'} eval(require $OPT{grammar})) {
$parser = eval new $OPT{grammar} or die $OPT{grammar}: $@;
} else {
@@ -519,7 +518,7 @@
close(IN);
}
verbose(2, Parsing);
-P6C::IMCC::init() unless $OPT{tree};
+P6C::IMCC::init();
my $result = run_pass('parse', sub {$parser-$::rule($in,0,$f)}, $fw);
output_tree($result, $f, $fw);
}
[EMAIL PROTECTED] perl6]$
Re: Exceptions, sub cleanup, and scope exit
Dan Sugalski [EMAIL PROTECTED] wrote: The 'invoke the current return continuation' op apparently got lost in the blowup. That needs to go in. Its in and named Creturncc since yesterday return with current continuation. I'd like pushing exception handlers to remain simple -- the current system is almost OK. What I'd like it to change to is: push_eh label Shouldn't that be: push_eh handler, label This is more restrictive than passing in a generic invokable object as the exception handler, but given that all the exception handling schemes in all our languages of interest do lexically scoped exceptions I think we're better off with the restriction. Good. ...Allowing random invokables as exception handlers feels like it's likely to have some subtle security or consistency problems associated with it, though I can't give a good example at the moment. Yep, it smells like that. Throwing exceptions should be: throw language, subsystem, severity, code, object Allowing just one additional object doesn't properly support Python, which has two optional expressions for the Craise statement and Python attaches a traceback object to the exception. OTOH (again from Python's view) raising just a CStopIteration or a CKeyErrror ought to be fast as its used heavily. And Python has an hierarchy of exception *objects*, with inheritance. So I think that for maximum flexibility we should just have exception objects, with some mandatory attributes (the exception class might already provide enough information) and additional information the HLL might stuff in. How will Perl6 do it? And I'm definitely unsure what types language and subsystem should be. Clanguage - I presume - is defining the HLL that emitted the code, where the exception occured. I think this information has to be in the interpreter context as we should eventually be able to execute mixed languages code. So Clanguage should probably end up in the traceback object, passed along with the exception. BTW - how do we set Clanguage? pushmark 12 . . random code here . popmark 12 where everything put on the control stack after the pushmark identifier is popped off by the corresponding popmark identifier. Marks can nest, and it's the code's responsibility to not reuse labels. popmark will *not* cross routine boundaries, so the control stack will never be cleared out past the point where it was when the sub/method/whatever was entered. This is intended for cleanup of a bunch of pushed handlers inside one routine? Now, with this, there's one other thing we need to talk about, and that's scope exit actions. We promised this a number of years back (and now I feel very old) and need to deliver on them. A scope exit action is put in place on the control stack with: pushaction Psub and when the action is popped off the stack because of a popmark, walking the stack back looking for exception handlers, a popaction op, or returning from a subroutine the sub is invoked with a *single* integer parameter that indicates whether the action is being called as part of a normal or exception-based stack unwind. (a status of 0 means the action was caused by normal code, a 1 because the action was popped off as parrot walked backwards looking for an exception handler) If folks want to argue that the action should get the exception information if called as part of an exception unwind I'm OK with that. Go for it, I'm unsure of that one. Python has try ... finally. It preserves (possibly) existing exceptions around the finally block. But if in the finally clause another exception occurs (or a return of break is executed), the saved exception is lost. This could mean that the exception object is needed, e.g. to nullify it in that case. So, parrot will automatically clear out the control stack and invoke any actions on it if: *) the current return continuation is invoked with the return op *) a tail call is made with either the tailcall or tailmethodcall ops How does the latter look like for recursive tail calls? So. Simple, right? Make sense to everyone? Yep. A lot. A final question: classifying the exception in the handler is still up to the HLL, I presume? And one remark WRT internally thrown exceptions: in case of a MemoryError exception (Python speak), we are not allowed to use any more resources, so we probably need to preconstruct a few needed items for such a case. leo
Re: Exceptions, sub cleanup, and scope exit
Tim Bunce [EMAIL PROTECTED] wrote: I guess the HLL compiler needs to ensure that for every push the control flow will always pass through a matching pop. Not necessarily. The handler is pushed onto the control stack. During a context change (e.g. from a subroutine return), the previous context with the according control stack top is copied into the interpreter. So effectively the handler is discarded. OTOH if several handlers are involved the emitted code ought to take care of it, yes. Couldn't (doesn't) parrot have a stronger concept of a 'scope' (as in perl5's scope.c) so that scope-exit cleanup can be automated and reliable? AFAIK a scope is either a lexical closure or optimized (maybe) to a region of code surrounded by Cnew_pad / Cpop_pad opcodes. Doing the rught thing on scope exit is up to the emitted code. Tim [ignore me if I'm talking nonsense] leo
Re: Exceptions, sub cleanup, and scope exit
Dan Sugalski wrote: It's also important for people writing these things to take into account the possibility that their exit actions may potentially be triggered multiple times, courtesy of the joys of continuations. Hmm, the first thing to take into the account is that return continuations can be promoted to the fully blown continuations. This should affect the handlers in the same way - so exception handlers could have become arbitrary invokable objects at the point when the exception is thrown. Miro
Re: Exceptions, sub cleanup, and scope exit
Miroslav Silovic [EMAIL PROTECTED] wrote: Hmm, the first thing to take into the account is that return continuations can be promoted to the fully blown continuations. Yes. But an exception handler is not a RetContinuation object. It's an Exception_Handler object (also derived from Continuatio), behaving more like a RetContinuation then a full one. Creating a full continuation involves the Cclone vtable of that object, which can do just the right thing. With some few missing patches there isn't any visible P1 or such object around. So the described behavior will work. Miro leo
Re: Exceptions, sub cleanup, and scope exit
At 10:03 AM +0100 11/19/04, Miroslav Silovic wrote: Dan Sugalski wrote: It's also important for people writing these things to take into account the possibility that their exit actions may potentially be triggered multiple times, courtesy of the joys of continuations. Hmm, the first thing to take into the account is that return continuations can be promoted to the fully blown continuations. This should affect the handlers in the same way - so exception handlers could have become arbitrary invokable objects at the point when the exception is thrown. I'd rather not, if we can avoid it. Assumptions on control flow and such are likely to be very different, and I can't think of a good reason to treat an error handler as a normal sub. (If you have one then we can think on it some) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: First public release of grammar engine
Patrick R. Michaud wrote: P6GE assumes that it is part of the parrot distribution in the Fcompilers/p6ge directory. Simply type Cmake in this directory to build the Fp6ge.so shared library it needs. oolong:~/research/parrot/compilers/p6ge coke$ make cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c p6ge_parse.c:23:20: malloc.h: No such file or directory p6ge_parse.c: In function `p6ge_parse_new': p6ge_parse.c:105: warning: assignment makes pointer from integer without a cast p6ge_parse.c: In function `p6ge_parse_literal': p6ge_parse.c:156: warning: assignment makes pointer from integer without a cast p6ge_parse.c: In function `p6ge_parse_quant': p6ge_parse.c:227: warning: assignment makes pointer from integer without a cast make: *** [p6ge_parse.o] Error 1 oolong:~/research/parrot/compilers/p6ge coke$ uname -a Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc Regards.
Re: Exceptions, sub cleanup, and scope exit
At 10:58 PM + 11/18/04, Tim Bunce wrote:
On Thu, Nov 18, 2004 at 11:37:54AM -0800, chromatic wrote:
On Thu, 2004-11-18 at 13:36 -0500, Dan Sugalski wrote:
I'd like pushing exception handlers to remain simple -- the current
system is almost OK. What I'd like it to change to is:
push_eh label
with popping the top exception handler being:
pop_eh
I'm up for better names, too.
The push_ is okay but eh is meh. push_handler seems better, though
handler is terribly generic. If the documentation and comments use it
consistently only for exceptions, though, it could work.
Throwcatch, so
push_catcher ?
I guess the HLL compiler needs to ensure that for every push the
control flow will always pass through a matching pop.
Otherwise that'll be another hard to debug situation.
Hopefully not. This is partially handled by the push/popmark stuff,
partially handled by stack unwinding on 'returns', and partially
handled by the sub-private nature of stacks.
Within a sub (or method, whatever) generated code can use the
pushmark/popmark ops to manage control stack elements. I expect
this'll be done mostly for entering and leaving scope -- code like:
foo: {
bar: {
}
}
outsidefoo:
would push a mark for foo when that block is entered, then push one
for bar when *that* block is entered. When bar's left the exit code
does a popmark bar, while exiting the foo block would exit a popmark
foo. If code in bar did a goto outsidefoo, the compiler would see
that it was exiting both the bar and foo blocks and just do a popmark
foo (since that'd pop all bar's entries too)
Each sub in parrot basically has its own private set of stacks, and
doesn't directly connect to its invoker's stacks. (Those are only
available from the return continuation tucked away in the interpreter
structure, so parrot can get to it easily enough) If code invokes a
continuation then the current stacks all go away (more or less --
unless there's a continuation holding on to them, but even then
they're out of view) and the stacks in the invoked continuation get
put into play, so any exception handlers that were in effect no
longer are. Or, rather, the ones that were in scope when the
continuation was taken are put back in scope as part of switching
over to the control stack that's held in the continuation.
Finally, when a 'return' op is invoked (basically one that puts the
return continuation back in play either through a real return or a
tail call) the op itself walks back the current control chain (which,
remember, is just for the current sub so it should be short) and
virtually pops all the elements off it, which means any element that
does something when popped will get a chance to do its thing.
Now it's distinctly possible there are more things that should go on
the control stack besides exception handlers, marks, and run my code
when I'm popped entries, so we can add those in as we need.
Tim [ignore me if I'm talking nonsense]
Nope, not nonsense. Things are just a bit fuzzy, so some
explanation's in order. :)
--
Dan
--it's like this---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: First public release of grammar engine
On Fri, Nov 19, 2004 at 07:52:57AM -0500, William Coleda wrote: oolong:~/research/parrot/compilers/p6ge coke$ make cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c p6ge_parse.c:23:20: malloc.h: No such file or directory Oops. Should've been stdlib.h instead. Fixed, thanks. make: *** [p6ge_parse.o] Error 1 oolong:~/research/parrot/compilers/p6ge coke$ uname -a Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc One of the areas where we can definitely use assistance is in porting and testing p6ge in operating environments different from the ones I have available to me--currently I'm doing most of my work in Red Hat 9 and its successors. Yes, I know RH is a fairly forgiving development environment; OTOH, in the not too-distant-future we'll be working primarily in PIR and Perl 6, so a lot (but not nearly all) of the architecture-dependency issues will be handled for us by other components. Pm
Re: Threads, events, Win32, etc.
[ long win32 proposal ] I've to read through that some more times. OK; let me know if you have any questions on how the Win32 stuff works. I tried to explain things that are unlike POSIX, but of course it makes sense to me. Do you alread have ideas for a common API, or where to split the existing threads.c into platform and common code? I didn't see anything in thread.c that was platform specific -- or at least nothing that looked like it wouldn't work on Win32. Obviously thr_win32.h will be much different than thr_pthreads.h. As for a common API, I suppose we would have to figure out how the modules would interact. In the case of IO (any function names I made up have capital letters to distinguish them from anything that may be in the current codebase): * There is some generic IO code that sets up IO and event objects, and it sits below the buffering layer. All this stuff is going to be thread-safe so the low-level IO code shouldn't have to worry about it. This generic IO code sets up the IO and Event objects indicating what file, which operation (read/write/lock/unlock), what to do when the operation completes, how many bytes, file position, and any memory buffer needed. Then it would pass this information to the OS-specific code. So this generic code (say, StartIO()) would create an IO object that contains the file object, a pointer to the r/w buffer if the operation requires it, and a file position and byte count if the operation uses it. It would also contain an event object indicating what to do in case of failure or completion. StartIO pins the memory buffer, locks the IO object, and calls Win32AsyncRead or whatever. The XXXAsyncYYY funtcion starts the IO and returns to StartIO which unlocks the IO object and returns it to the caller. That can then be passed into functions to find out if it's complete, cancel it, etc. If XXX is Win32, the module would just start Read/WriteFile; if it's Solaris, maybe it'll call aioread/write; if it's POSIX without aio (e.g. Linux), it'll start up a new thread to do a blocking read/write. When the IO completes, the XXX code figures out the return code and how many bytes read/written. This information is passed to the generic CompleteIO(), which locks the IO object, updates the status (return code, byte count), unpins the buffer, dispatches the event as described by the Event object, and unlocks the IO object. * In the case of timers, there would be XXXCreateTimer and XXXCancelTimer, while the XXX code would need to call FireTimer(). * I suppose there should be an XXXQueueEvent function as well, but I'm not certain of its uses. Actual EventDispatch() would be a generic function that puts an event into a thread's queue and notifies the thread. I am not sure how to handle general events like RunGC. * GUI message handlers need to dispatch events synchronously. So the generic check_events function would call XXXGetGUIMessages which would need to dispatch the messages to whatever registered for them in that thread. Since this would amount to method dispatch instead of event dispatch, it would probably need something special for this. GNS
Re: First public release of grammar engine
At 7:00 AM -0700 11/19/04, Patrick R. Michaud wrote: On Fri, Nov 19, 2004 at 07:52:57AM -0500, William Coleda wrote: oolong:~/research/parrot/compilers/p6ge coke$ make cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c p6ge_parse.c:23:20: malloc.h: No such file or directory Oops. Should've been stdlib.h instead. Fixed, thanks. make: *** [p6ge_parse.o] Error 1 oolong:~/research/parrot/compilers/p6ge coke$ uname -a Darwin oolong 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc One of the areas where we can definitely use assistance is in porting and testing p6ge in operating environments different from the ones I have available to me--currently I'm doing most of my work in Red Hat 9 and its successors. Given that this is going to be part of core parrot no matter what language pack is shipped with it (so everyone will get a parrot distribution with a pasm, pir, z-code, and regex compiler) I'm up for adding this to the basic makefile once things are shaken down a little. If they're already shaking, we can do it now. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: COND macros (was: Threads, events, Win32, etc.)
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Gabe Schaffer [EMAIL PROTECTED] wrote: The problem is a different one: the COND_INIT macro just passes a condition location, the mutex is created in a second step, which isn't needed for windows. OTOH a mutex aka critical section is needed separatly. So we should probably define these macros to be: COND_INIT(c, m) COND_DESTROY(c, m) see src/tsq.c for usage. Does win32 require more info to create conditions/mutexes or would these macros suffice? Win32 doesn't require anything else, but I don't think I like this idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what happens when some code goes to LOCK(m)? It would work under POSIX but break under Win32. I think there should be an opaque struct that contains c,m for POSIX and c for Win32. GNS
Re: Exceptions, sub cleanup, and scope exit
Dan Sugalski wrote: Hmm, the first thing to take into the account is that return continuations can be promoted to the fully blown continuations. This should affect the handlers in the same way - so exception handlers could have become arbitrary invokable objects at the point when the exception is thrown. I'd rather not, if we can avoid it. Assumptions on control flow and such are likely to be very different, and I can't think of a good reason to treat an error handler as a normal sub. (If you have one then we can think on it some) While that's not what I commented on, sure. Common LISP and TOM both invoke error handler -before- unwinding the stack (then the handler explicitely unwinds if it can't recover). I still don't think it's something Parrot should care about, as their (hypothetical) compilers can install their own error handling, and other languages don't expect their own throw to ever return - so I wouldn't call this a good reason. :) Miro
Re: COND macros (was: Threads, events, Win32, etc.)
At 8:42 AM -0500 11/19/04, Gabe Schaffer wrote: On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Gabe Schaffer [EMAIL PROTECTED] wrote: The problem is a different one: the COND_INIT macro just passes a condition location, the mutex is created in a second step, which isn't needed for windows. OTOH a mutex aka critical section is needed separatly. So we should probably define these macros to be: COND_INIT(c, m) COND_DESTROY(c, m) see src/tsq.c for usage. Does win32 require more info to create conditions/mutexes or would these macros suffice? Win32 doesn't require anything else, but I don't think I like this idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what happens when some code goes to LOCK(m)? It would work under POSIX but break under Win32. I think there should be an opaque struct that contains c,m for POSIX and c for Win32. This'll mean that every mutex will have a corresponding condition variable, something that I'm not sure we need. On the other hand, I can't picture us having so many of these that it makes any difference at all, so I don't have a problem with it. It isn't a good general-purpose thread solution (there are plenty of good reasons to unbundle these) but we don't really *need* a general-purpose solution. :) Parrot's locks will all have wait/signal/broadcast capabilities. We should go rename the macros and rejig the code. This may have to wait a little -- we're cleaning up the last of subs, I've still got the string stuff outstanding, and I promised Sam Ruby I'd deal with classes and metaclasses next. So much time, so little to do. No, wait, that's not right... -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: First public release of grammar engine
On Fri, Nov 19, 2004 at 09:05:31AM -0500, Dan Sugalski wrote: At 7:00 AM -0700 11/19/04, Patrick R. Michaud wrote: One of the areas where we can definitely use assistance is in porting and testing p6ge in operating environments different from the ones I have available to me--currently I'm doing most of my work in Red Hat 9 and its successors. Given that this is going to be part of core parrot no matter what language pack is shipped with it (so everyone will get a parrot distribution with a pasm, pir, z-code, and regex compiler) I'm up for adding this to the basic makefile once things are shaken down a little. If they're already shaking, we can do it now. :) I think they're already shaking, so we can do it whenever you think appropriate. I'm still learning the ins-and-outs of Parrot's configuration/build system, so if someone else knowledgeable about such things wants to tackle it, or at least get it started, that'd make me very happy. :-) Pm
Re: First public release of grammar engine
At 7:26 AM -0700 11/19/04, Patrick R. Michaud wrote: On Fri, Nov 19, 2004 at 09:05:31AM -0500, Dan Sugalski wrote: At 7:00 AM -0700 11/19/04, Patrick R. Michaud wrote: One of the areas where we can definitely use assistance is in porting and testing p6ge in operating environments different from the ones I have available to me--currently I'm doing most of my work in Red Hat 9 and its successors. Given that this is going to be part of core parrot no matter what language pack is shipped with it (so everyone will get a parrot distribution with a pasm, pir, z-code, and regex compiler) I'm up for adding this to the basic makefile once things are shaken down a little. If they're already shaking, we can do it now. :) I think they're already shaking, so we can do it whenever you think appropriate. I'm still learning the ins-and-outs of Parrot's configuration/build system, so if someone else knowledgeable about such things wants to tackle it, or at least get it started, that'd make me very happy. :-) Cool. This, I think, is a job for p6i, so I shall push it over there. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Getting the grammar engine in (or a small task for the interested)
Folks, Since the grammar engine that Patrick's working on is going to be part of the base parrot kit (given the number of languages that have perl 5 compatible regex implementations, we might as well make it so the *real* perl 5, and perl 6, regex engine's there to be used in their parrot incarnations) I'd like to get it building as part of the core parrot build system. So, if someone'd like to take a shot at thumping the template makefile bits to add in compilers/p6ge to the basic build, that'd be great. Grovelling over the code in there to scrub out portability issues would also be good. This should be relatively simple, so have at it. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: COND macros
Gabe Schaffer wrote:
On Wed, 17 Nov 2004 16:30:04 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote:
Gabe Schaffer [EMAIL PROTECTED] wrote:
The problem is a different one: the COND_INIT macro just passes a
condition location, the mutex is created in a second step, which isn't
needed for windows. OTOH a mutex aka critical section is needed
separatly.
So we should probably define these macros to be:
COND_INIT(c, m)
COND_DESTROY(c, m)
see src/tsq.c for usage.
Does win32 require more info to create conditions/mutexes or would these
macros suffice?
Win32 doesn't require anything else, but I don't think I like this
idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what
happens when some code goes to LOCK(m)? It would work under POSIX but
break under Win32.
The mutex in COND_INIT is specific to that condition, it can't get
reused in unrelated places. But it is used to synchronize {push,pop,
wait_for}_entry. How is e.g. tsq.c:push_entry() synchronized then on Win32?
... I think there should be an opaque struct that
contains c,m for POSIX and c for Win32.
Works for me too, modulo above sync issues.
GNS
leo
Re: First public release of grammar engine
William Coleda wrote: Patrick R. Michaud wrote: P6GE assumes that it is part of the parrot distribution in the Fcompilers/p6ge directory. Simply type Cmake in this directory to build the Fp6ge.so shared library it needs. cc -shared -fpic p6ge_parse.o p6ge_gen.o p6ge_parsep5.o -o p6ge.so cc: unrecognized option `-shared' ld: Undefined symbols: _main make: *** [p6ge.so] Error 1 $ uname -a Darwin Althalus.local 7.6.0 Darwin Kernel Version 7.6.0: Sun Oct 10 12:05:27 PDT 2004; root:xnu/xnu-517.9.4.obj~1/RELEASE_PPC Power Macintosh powerpc $ cc -v Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs Thread model: posix gcc version 3.3 20030304 (Apple Computer, Inc. build 1666) That's Mac OS X 10.3.6 'Panther' by the way. I have no idea why GCC's not accepting -shared, that came as quite a shock. I'm hoping there's someone around who knows more about Apple's GCC on Darwin than I do, because my experience is largely limited to using it through XCode for Objective-C stuff. Well done on getting a grammar engine going though. Things are looking up :-)
Re: First public release of grammar engine
William Coleda [EMAIL PROTECTED] wrote: Patrick R. Michaud wrote: P6GE assumes that it is part of the parrot distribution in the Fcompilers/p6ge directory. Simply type Cmake in this directory to build the Fp6ge.so shared library it needs. oolong:~/research/parrot/compilers/p6ge coke$ make cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c p6ge_parse.c:23:20: malloc.h: No such file or directory Well, p6ge should eventually use Parrot's config info and the Makefile ought to be a generated one. leo
Re: First public release of grammar engine
On Fri, Nov 19, 2004 at 02:54:20PM +0100, Leopold Toetsch wrote: Well, p6ge should eventually use Parrot's config info and the Makefile ought to be a generated one. s/eventually use/be using/# :-) Dan's moved the item to p6i, so hopefully someone there will either make the changes for me or point me in the direction of doing it. I like to stay abreast of portability issues as we go, rather than find out about them later. Pm
Re: First public release of grammar engine
On Fri, Nov 19, 2004 at 07:03:45AM -0800, Will Coleda wrote: This would be a good idea. pmc's fix for the malloc.h issue gets the error below. All the CC flags (and file extensions, and path separator) should be pulled from config. Also, missing a clean target. (Sorry if it sounds like I'm complaining, I just want to try this out! =-) Don't worry, it doesn't sound like complaining at all -- just accurate and rapid reporting of problems coupled with a well-placed (and appreciated) eagerness to try things out. I truly appreciate the rapid and useful feedback. Pm
[perl #32507] [TODO] ResizableIntegerArray missing vtables (e.g., pop)
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #32507] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32507 In P6GE, there's an array (gr_cap) that is used to store group captures as an array of ints. Leo suggests that a ResizableIntegerArray be used instead of a PerlArray, but before this can be done the ResizableIntegerArray needs to have vtable entries for push and pop. Pm - Forwarded message from Leopold Toetsch [EMAIL PROTECTED] - - the array gr_cap seems to take integers only. If yes it should be eventually a ResizableIntegerArray. But this needs 2 TODO items (which I'd just drop off to the list): implement missing vtables like pop and use the allocation style from ResizablePMCArray, i.e. the size in PMC_int_val2(ar). The resize logic could just be reused (called directly)
[perl #32508] [TODO] P6GE - Convert PerlArray in gr_cap to ResizableIntegerArray
# New Ticket Created by Patrick R. Michaud # Please include the string: [perl #32508] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32508 P6GE currently uses a PerlArray for holding an array of captures; Leo suggests this should be a ResizableIntegerArray instead (I agree). However, this depends on the availability of push/pop vtable operations (RT #32507). This ticket is entered to remind us to make the switch in p6ge when 32507 has been completed. Pm - Forwarded message from Leopold Toetsch [EMAIL PROTECTED] - - the array gr_cap seems to take integers only. If yes it should be eventually a ResizableIntegerArray. But this needs 2 TODO items (which I'd just drop off to the list): implement missing vtables like pop and use the allocation style from ResizablePMCArray, i.e. the size in PMC_int_val2(ar). The resize logic could just be reused (called directly) - End forwarded message -
Re: First public release of grammar engine
This would be a good idea. pmc's fix for the malloc.h issue gets the error below. All the CC flags (and file extensions, and path separator) should be pulled from config. Also, missing a clean target. (Sorry if it sounds like I'm complaining, I just want to try this out! =-) cc -I ../../include -c -o p6ge_parse.o p6ge_parse.c cc -I ../../include -c -o p6ge_gen.o p6ge_gen.c In file included from ../../include/parrot/parrot.h:29, from p6ge_gen.c:22: ../../include/parrot/config.h:67: warning: use of `long double' type; its size may change in a future release ../../include/parrot/config.h:67: warning: (Long double usage is reported only once for each file. ../../include/parrot/config.h:67: warning: To disable this warning, use -Wno-long-double.) cc -I ../../include -c -o p6ge_parsep5.o p6ge_parsep5.c cc -shared -fpic p6ge_parse.o p6ge_gen.o p6ge_parsep5.o -o p6ge.so cc: unrecognized option `-shared' ld: Undefined symbols: _main make: *** [p6ge.so] Error 1 On Fri, Nov 19, 2004 at 09:05:31AM -0500, Dan Sugalski wrote: If they're already shaking, we can do it now. :)
Re: Getting the grammar engine in (or a small task for the interested)
On Fri, 19 Nov 2004, Dan Sugalski wrote: So, if someone'd like to take a shot at thumping the template makefile bits to add in compilers/p6ge to the basic build, that'd be great. Grovelling over the code in there to scrub out portability issues would also be good. I'll take a look at this. This should be relatively simple, so have at it. :) Hee, hee. I know better than to believe that! -- Andy Dougherty [EMAIL PROTECTED]
Re: Getting the grammar engine in (or a small task for the interested)
At 10:58 AM -0500 11/19/04, Andy Dougherty wrote: On Fri, 19 Nov 2004, Dan Sugalski wrote: So, if someone'd like to take a shot at thumping the template makefile bits to add in compilers/p6ge to the basic build, that'd be great. Grovelling over the code in there to scrub out portability issues would also be good. I'll take a look at this. Cool. This should be relatively simple, so have at it. :) Hee, hee. I know better than to believe that! Hey, I said it *should* be easy. I didn't say that it actually *would* be easy... :-P -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: Getting the grammar engine in (or a small task for the interested)
On Fri, 19 Nov 2004, Andy Dougherty wrote:
On Fri, 19 Nov 2004, Dan Sugalski wrote:
So, if someone'd like to take a shot at thumping the template
makefile bits to add in compilers/p6ge to the basic build, that'd be
great. Grovelling over the code in there to scrub out portability
issues would also be good.
I'll take a look at this.
Ok, here's a first pass. Most of it is pretty straightforward, but one
thing is worth noting:
The code uses both signed and unsigned chars, with and without the 'const'
qualifier. I gather this is a deliberate part of a carefully considered
overall design. Unfortunately, it's hard to get it to interact smoothly
with system headers and functions. I put in various casts to pacify Sun's
cc compiler. I fully expect that Linux/gcc folks might notice even more
squawking after applying my patch than before because that compiler will
complain about a completely different set of conversions.
Without understanding the underlying design, I don't know offhand what to
recommend, but this patch works for me and highlights spots where some
further thought might be needed.
diff -r -u -H -P parrot-orig/MANIFEST parrot-andy/MANIFEST
--- parrot-orig/MANIFESTFri Nov 19 10:58:42 2004
+++ parrot-andy/MANIFESTFri Nov 19 13:04:40 2004
@@ -123,7 +123,6 @@
classes/unmanagedstruct.pmc []
classes/version.pmc []
classes/vtablecache.pmc []
-compilers/p6ge/Makefile []
compilers/p6ge/README []
compilers/p6ge/demo.pir []
compilers/p6ge/p6ge.h []
@@ -211,6 +210,7 @@
config/gen/makefiles/miniperl.in []
config/gen/makefiles/ook.in []
config/gen/makefiles/perl6.in []
+config/gen/makefiles/p6ge.in []
config/gen/makefiles/root.in []
config/gen/makefiles/scheme.in[]
config/gen/makefiles/tcl.in []
diff -r -u -H -P parrot-orig/compilers/p6ge/p6ge_gen.c
parrot-andy/compilers/p6ge/p6ge_gen.c
--- parrot-orig/compilers/p6ge/p6ge_gen.c Fri Nov 19 08:53:40 2004
+++ parrot-andy/compilers/p6ge/p6ge_gen.c Fri Nov 19 14:43:43 2004
@@ -81,7 +81,7 @@
/* strcon(...) converts string values into PIR string constants */
static char*
-strcon(const char* s, int len)
+strcon(const unsigned char* s, int len)
{
static char esc[P6GE_MAX_LITERAL_LEN * 2 + 3];
char* t = esc;
diff -r -u -H -P parrot-orig/compilers/p6ge/p6ge_parse.c
parrot-andy/compilers/p6ge/p6ge_parse.c
--- parrot-orig/compilers/p6ge/p6ge_parse.c Fri Nov 19 08:53:40 2004
+++ parrot-andy/compilers/p6ge/p6ge_parse.c Fri Nov 19 14:41:41 2004
@@ -22,6 +22,7 @@
#include ctype.h
#include stdio.h
#include stdlib.h
+#include string.h
int p6ge_ctype[256];
int p6ge_cmeta[256];
@@ -62,7 +63,7 @@
p6ge_parse_error(P6GE_Text* t, const char* msg)
{
printf(%s at offset %d (found '%c')\n, msg, t-pos - t-text, *(t-pos));
- t-pos = ;
+ t-pos = NULL;
}
@@ -231,7 +232,7 @@
p6ge_parse_error(t, Missing { after ** quantifier);
p6ge_skip(t, 1);
if (isdigit(*(t-pos))) {
-q-min = q-max = atoi(t-pos);
+q-min = q-max = atoi((char *) t-pos);
while (isdigit(*(t-pos))) t-pos++;
p6ge_skip(t, 0);
} else p6ge_parse_error(t, Missing min value in **{} quantifier);
@@ -239,7 +240,7 @@
p6ge_skip(t, 2);
if (t-pos[0] == '.') { q-max = P6GE_INF; p6ge_skip(t, 1); }
else if (isdigit(*(t-pos))) {
-q-max = atoi(t-pos);
+q-max = atoi((char *) t-pos);
while (isdigit(*(t-pos))) t-pos++;
p6ge_skip(t, 0);
}
@@ -296,8 +297,8 @@
{
P6GE_Text t;
P6GE_Exp* e = 0;
-t.text = s;
-t.pos = s;
+t.text = (unsigned const char *) s;
+t.pos = (unsigned const char *) s;
t.capture = 0;
t.ncapture = 0;
return p6ge_parse_expr(t);
@@ -361,6 +362,8 @@
Initial version by Patrick R. Michaud, 2004.11.16
=cut
+
+*/
/*
* Local variables:
diff -r -u -H -P parrot-orig/compilers/p6ge/p6ge_parsep5.c
parrot-andy/compilers/p6ge/p6ge_parsep5.c
--- parrot-orig/compilers/p6ge/p6ge_parsep5.c Fri Nov 19 08:53:40 2004
+++ parrot-andy/compilers/p6ge/p6ge_parsep5.c Fri Nov 19 14:47:37 2004
@@ -22,6 +22,7 @@
#include ctype.h
#include stdio.h
#include stdlib.h
+#include string.h
static P6GE_Exp* p5re_parse_expr(P6GE_Text* t);
@@ -29,7 +30,7 @@
p5re_parse_error(P6GE_Text* t, const char* msg)
{
printf(%s at offset %d (found '%c')\n, msg, t-pos - t-text, *(t-pos));
- t-pos = ;
+ t-pos = NULL;
}
@@ -143,14 +144,14 @@
else if (c == '*') { q-min = 0; q-max = P6GE_INF; }
else if (c == '{') {
if (isdigit(*(t-pos))) {
-q-min = q-max =
Re: [perl #32280] [PATCH] Detects presence of perldoc at configuration time
Sorry for the delay, but here is a revised patch to detect perldoc.
- If Perldoc is detected, no warning messages will be printed and things
will work as before
- If Perldoc is not detected
- Configure.pl will print a message saying that the docs will not
be built
- docs/ will not be built
- When 'make docs' or 'make html' is run, a message will be echoed
to the screen explaining that perldoc is required.
James
Leopold Toetsch wrote:
Nicholas Clark [EMAIL PROTECTED] wrote:
I don't like the build blowing up on me when there is no perldoc, and on
some machines that I use I'm not in a position to change this.
So, as opinions aren't really matching, let's try this approach:
The configure step from that patch doesn't bail out, but prints a big
fat warning about the lack of accessing perl and parrot docs, disables
the parrot doc make target and continues.
Nicholas Clark
leo
--- config_o2/auto/perldoc.pl 1969-12-31 19:00:00.0 -0500
+++ config/auto/perldoc.pl 2004-11-18 22:02:39.0 -0500
@@ -0,0 +1,36 @@
+#! perl -w
+# Copyright: 2001-2004 The Perl Foundation. All Rights Reserved.
+
+=head1 NAME
+
+config/auto/perldoc - Perldoc
+
+=head1 DESCRIPTION
+
+Determines if Perldoc exists on the system.
+
+=cut
+
+package Configure::Step;
+
+use strict;
+use vars qw($description @args);
+use Parrot::Configure::Step ':auto';
+
+$description=Determining if your system has perldoc installed...;
+
[EMAIL PROTECTED](verbose);
+
+sub runstep {
+
+my $a = `perldoc perldoc`;
+unless ($a =~ m/perldoc/) {
+ Configure::Data-set(perldoc = 0);
+ Configure::Data-set(notperldoc = 1);
+} else {
+Configure::Data-set(perldoc = 1);
+ Configure::Data-set(notperldoc = 0);
+}
+}
+
+1;
? .MANIFEST.swp
? .Makefile.swp
? .config_perldoc.patch.swp
? config/auto/.headers.pl.swp
? config/auto/.perldoc.pl.swp
? config/auto/perldoc.pl
? config/gen/.makefiles.pl.swp
? config/gen/makefiles/.root.in.swp
? docs/.Makefile.swp
? icu/source/test/testdata/out
? lib/Parrot/Configure/.Step.pm.swp
? tools/dev/.install_files.pl.swp
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.772
diff -u -r1.772 MANIFEST
--- MANIFEST 18 Nov 2004 07:01:10 - 1.772
+++ MANIFEST 19 Nov 2004 21:34:56 -
@@ -158,6 +158,7 @@
config/auto/memalign/test_c.in[]
config/auto/memalign/test_c2.in []
config/auto/pack.pl []
+config/auto/perldoc.pl[]
config/auto/signal.pl []
config/auto/signal/test_1.in []
config/auto/signal/test_2.in []
Index: config/gen/makefiles.pl
===
RCS file: /cvs/public/parrot/config/gen/makefiles.pl,v
retrieving revision 1.36
diff -u -r1.36 makefiles.pl
--- config/gen/makefiles.pl 13 Sep 2004 05:25:51 - 1.36
+++ config/gen/makefiles.pl 19 Nov 2004 21:34:56 -
@@ -88,34 +88,39 @@
genfile('config/gen/makefiles/parrot_compiler.in', 'languages/parrot_compiler/Makefile',
commentType = '#', replace_slashes = 1);
-
- # set up docs/Makefile, partly based on the .ops in the root dir
-
- opendir OPS, ops or die opendir ops: $!;
- my @ops = sort grep { !/^\./ /\.ops$/ } readdir OPS;
- closedir OPS;
-
- my $pod = join , map { my $t = $_; $t =~ s/\.ops$/.pod/; ops/$t } @ops;
-
- Configure::Data-set(pod = $pod);
-
- genfile('config/gen/makefiles/docs.in', 'docs/Makefile',
- commentType = '#');
-
- Configure::Data-set(pod = undef);
-
- open MAKEFILE, docs/Makefile or die open docs/Makefile: $!;
-
- foreach my $ops (@ops) {
- my $pod = $ops;
- $pod =~ s/\.ops$/.pod/;
- print MAKEFILE EOM;
+ my $perldoc = Configure::Data-get('perldoc');
+ if ($perldoc) {
+# set up docs/Makefile, partly based on the .ops in the root dir
+
+opendir OPS, ops or die opendir ops: $!;
+my @ops = sort grep { !/^\./ /\.ops$/ } readdir OPS;
+closedir OPS;
+
+my $pod = join , map { my $t = $_; $t =~ s/\.ops$/.pod/; ops/$t } @ops;
+
+Configure::Data-set(pod = $pod);
+
+genfile('config/gen/makefiles/docs.in', 'docs/Makefile',
+commentType = '#');
+
+Configure::Data-set(pod = undef);
+
+open MAKEFILE, docs/Makefile or die open docs/Makefile: $!;
+
+foreach my $ops (@ops) {
+my $pod = $ops;
+$pod =~ s/\.ops$/.pod/;
+print MAKEFILE EOM;
ops/$pod: ../ops/$ops
perldoc -u ../ops/$ops ops/$pod
-EOM
- }
- close MAKEFILE
+EOM
+}
+
+close MAKEFILE
+} else {
+print \nNo Perldoc, not generating a docs makefile.\n;
+}
}
1;
Index: config/gen/makefiles/root.in
===
RCS file: /cvs/public/parrot/config/gen/makefiles/root.in,v
retrieving revision 1.261
diff
return value of s///
Synopsis 5 has a section on the return value from matches: http://www.wall.org/~larry/syn/S05.html#return_values_from_matches However, it has nothing on the return values of substitutions. In perl 6 will these always return a match object? Or will it be as perl 5 and return the number of substitutions (or the empty string if none) Nicholas Clark
Fwd: Re: [PATCH] Re: Getting the grammar engine in (or a small task for the interested)
Just a quick note to perl6-compilers that I've just committed a patch (timely submitted by Andy Dougherty) that should enable p6ge to compile under OSX and a few other environments a bit more cleanly. More details to come soon. Pm - Forwarded message from Patrick R. Michaud [EMAIL PROTECTED] - Date: Fri, 19 Nov 2004 16:37:33 -0700 From: Patrick R. Michaud [EMAIL PROTECTED] To: Andy Dougherty [EMAIL PROTECTED] Cc: Perl6 Internals [EMAIL PROTECTED] Subject: Re: [PATCH] Re: Getting the grammar engine in (or a small task for the interested) On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote: Ok, here's a first pass. Most of it is pretty straightforward, but one thing is worth noting: The code uses both signed and unsigned chars, with and without the 'const' qualifier. I gather this is a deliberate part of a carefully considered overall design. You're being very kind, but no, it's an indication of my working too late one night. It really should all be unsigned characters, and its fixed now, as well as the bunches of warnings that gcc was giving when compiling everything. Without understanding the underlying design, I don't know offhand what to recommend, but this patch works for me and highlights spots where some further thought might be needed. Thanks a *bunch* for this -- I've gone ahead and applied the patches (along with other cleanups) and committed them into CVS. A test suite harness for p6ge should be coming within the next day or so-- stay tuned. Pm - End forwarded message -
[perl #32514] Cannot Build Parrot on Linux PPC (nonvolatile registers)
# New Ticket Created by chromatic # Please include the string: [perl #32514] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org:80/rt3/Ticket/Display.html?id=32514 --- osname= linux osvers= 2.4.24-benh0 arch= powerpc-linux cc= gcc 3.2.3 20030422 (Gentoo Linux 1.4 3.2.3-r3, propolice) --- Flags: category=core severity=critical ack=no --- Apparently the AIX and Darwin JIT fixes have broken the Linux PPC build, which doesn't pick up the appropriate hints file. I tried a couple of ways to force it to do so to no avail. Someone who knows what he's doing will have to do it. c++ -o parrot -L/usr/local/lib -Wl,-E -g imcc/main.o blib/lib/libparrot.a blib/lib/libicuuc.a blib/lib/libicudata.a -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp blib/lib/libparrot.a(jit_cpu.o)(.text+0x2722): In function `Parrot_end_jit': src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2726):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x274e):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2752):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2772):src/jit_cpu.c:74: undefined reference to `Parrot_ppc_jit_restore_nonvolatile_registers' blib/lib/libparrot.a(jit_cpu.o)(.text+0x2776):src/jit_cpu.c:74: more undefined references to `Parrot_ppc_jit_restore_nonvolatile_registers' follow collect2: ld returned 1 exit status make: *** [parrot] Error 1 --- Summary of my parrot 0.1.1 configuration: configdate='Fri Nov 19 13:50:03 2004' Platform: osname=linux, archname=powerpc-linux jitcapable=1, jitarchname=ppc-linux, jitosname=LINUX, jitcpuarch=ppc execcapable=1 perl=/usr/bin/perl Compiler: cc='gcc', ccflags='-DDEBUGGING -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', Linker and Libraries: ld='gcc', ldflags=' -L/usr/local/lib', cc_ldflags='', libs='-lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp' Dynamic Linking: share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC', load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC' Types: iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4, ptrsize=4, ptr_alignment=1 byteorder=4321, nv=double, numvalsize=8, doublesize=8 --- Environment: HOMELANGLANGUAGELC_ALLLD_LIBRARY_PATHLOGDIR PATHSHELL
Re: First public release of grammar engine
On Thu, Nov 18, 2004 at 04:01:54PM -0700, Patrick R. Michaud wrote: I've just committed the first draft of a Perl 6 grammar engine to the parrot repository (in compilers/p6ge). What you'll find there is still at a somewhat early stage of development, I'm releasing it now so that people can begin commenting and suggesting improvements to the framework. Working code. This will shut the nay-sayers up. (Why do I doubt this?) =head1 Known Limitations Lastly, error handling needs to be improved, but this will likely be decided as we discover how P6GE integrates with the rest of Parrot. $ ../../parrot demo.pir input /pattern, string to match, + to continue match, ? to print pir, / Unrecognized character at offset 1 (found '') Segmentation fault Is this a known limitation? [Done after Andy's patch went in] Blows up the same way on x86 Linux and x86 FreeBSD. OS X gives Bus error instead. Nicholas Clark
Re: return value of s///
On Fri, Nov 19, 2004 at 10:20:23PM +, Nicholas Clark wrote: : In perl 6 will these always return a match object? Or will it be as perl 5 : and return the number of substitutions (or the empty string if none) Yes, and yes. The match object returns the number of substitutions in a numeric context. If there is no match, it returns 0 in a numeric context or undef in a string context. Larry
Re: First public release of grammar engine
On Sat, Nov 20, 2004 at 12:18:17AM +, Nicholas Clark wrote: $ ../../parrot demo.pir input /pattern, string to match, + to continue match, ? to print pir, / Unrecognized character at offset 1 (found '') Segmentation fault Is this a known limitation? [Done after Andy's patch went in] Blows up the same way on x86 Linux and x86 FreeBSD. OS X gives Bus error instead. Known limitation, and yet not entirely incorrect since null patterns are illegal. But p6ge should obviously do something more intelligent than segfaulting. So, as a more general question, what should happen when p6ge is fed a pattern with an error in it? I'm guessing we'll eventually have it throw some sort of exception, but Parrot exception handling is still in flux so what to do in the meantime? If we think of p6ge as a normal compiler, then perhaps it should work the same way that imcc does -- namely, generate error messages to standard output and return the same sort of object that imcc does when it's given code with an error in it. Pm
Re: silent effects of opcodes
On Thu, 18 Nov 2004 08:13:02 +0100, Leopold Toetsch [EMAIL PROTECTED] wrote: Bill Coffman [EMAIL PROTECTED] wrote: ps: I'm making progress on grokking the cfg and register renaming stuff. Will let you know. This needs an SSA graph of the data flow? Static Single-Assignment (I had to look it up). My approach is to consider something you once said, which was to the effect of ensuring the accuracy of the analysis. I've got some code to do a fairly simple depth first search per symbol. It is slower (I presume), but easier to understand. Later, I plan to (or someone else could) implement the data flow stuff with bit vectors and SSA to determine reachability, etc. In this way, I can compare the simple analysis with the complex analysis, and convince myself, and anyone else that the code is correct. All this will be done even before verifying the program runs correctly (passing make test). Advanced_Compiler_Design__Implementation by Muchnick is my main resource. Register renaming is easy enough when you have DU (def-use (def means value is written, use means value read) and UD chains, and especifically webs (which connect defs to uses). Webs are components of def-use chains (using graph theory language). They are effectively different variables, and can be provided with separate symbol names, which is actually very similar to what is done during a spill. My depth first search algorithm finds these too. Like I said, I wanted to start with something simple that is correct, and move forward with the more optimized forms later. Another thing I'd like to do, is throw in is a randomizer, to change the way the allocator assigns registers. Considering all the cruft that was uncovered when the algorithm was changed, it might be a good idea to have a debug feature that selects registers differently each time it runs (each allocation should be valid, of course). This could help flesh out any other faulty assumptions in the parrot compiler. BTW, looking at analyse_life_block() it seems that this allocates unconditionally a Life_range structure. As these are O2 in (n_symbols * n_basic_blocks) we could safe huge amounts of memory, by defining that a missing life block propagates the previous one. Dunno if its possible, though. That's definitely not very efficient. Plus it's mallocing each Life_Range, which is usually at least another 8 bytes per chunk, and then a lot of potential thrashing when freed. It seems I've seen a lot of less than optimum code like this, and I suspect there's a lot more like it. Solving these things will bring me that much closer to the ultimate goal of defeating Dan's evil code. ;) leo Bill
Re: silent effects of opcodes
At 5:36 PM -0800 11/19/04, Bill Coffman wrote: Another thing I'd like to do, is throw in is a randomizer, to change the way the allocator assigns registers. Considering all the cruft that was uncovered when the algorithm was changed, it might be a good idea to have a debug feature that selects registers differently each time it runs (each allocation should be valid, of course). This could help flesh out any other faulty assumptions in the parrot compiler. That'd actually help quite a bit. I've run into a number of cases where things worked only through sheer happenstance -- subs that were used before they were actually fetched, but only because they'd been fetched before and the temp registers mapped the same. Being able to throw a random seed into the pir compiler'd be nice there to flush those out. That's definitely not very efficient. Plus it's mallocing each Life_Range, which is usually at least another 8 bytes per chunk, and then a lot of potential thrashing when freed. It seems I've seen a lot of less than optimum code like this, and I suspect there's a lot more like it. Yow. That'd also trigger pathologically degenerate code in some versions of glibc's memory deallocation system. Solving these things will bring me that much closer to the ultimate goal of defeating Dan's evil code. ;) Better save that code -- I'm working on some machine generated Anti-Evil(tm) for it. If I'm lucky I won't be able to recreate it without some CVS fiddling. :) -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[ANNOUNCE] Test::Simple 0.50
http://www.pobox.com/~schwern/src/Test-Simple-0.50.tar.gz or a CPAN near you. Not much in this release, just fixing the little Windows testing bug. Also dumped Aegis. Stiched the Aegis era revisions back into the older CVS history, converted the whole thing to Subversion and I'm now using SVK. Offline commits, yay! This also means the Test-Simple repository is off my laptop and on a public server. Anonyous access coming soon. 0.50 Sat Nov 20 00:28:44 EST 2004 * Fixed bug in fail-more test on Windows (not a real bug). [rt.cpan.org 8022] - Change from CVS to SVK. Hopefully this is the last version control system change. - Again removing File::Spec dependency (came back in 0.48_02) - Change from Aegis back to CVS 0.49 Thu Oct 14 21:58:50 EDT 2004 - t/harness_active.t would fail for frivolous reasons with older MakeMakers (test bug) [thanks Bill Moseley for noticing] -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ 7a. Good, Fast, Cheap: Pick any two (you can't have all three). -- RFC 1925
