begin quote from Robert Spier:
> - Renamed include/parrot/register_funcs.h to regfuncs.h
> - Renamed languages/miniperl/miniperlc to mpc
> - Moved t/op/pmc* to t/op/pmc/
> - Moved Parrot/* to lib/Parrot/
> - Moved Test/* to lib/Test/
Thanks to Robert and Jeff for this reorganisation and the post-
On Wed, Jan 30, 2002 at 07:48:25AM +0100, Paul Johnson wrote:
> On Tue, Jan 29, 2002 at 09:57:16PM +, Simon Cozens wrote:
>
> > I've started a new TODO list. Remind me of anything else that needs
> > doing;
>
> Sandboxes.
>
> Has anyone given any thought as to whether Parrot should support
This little patch makes command failures in tests (ie. if Parrot pukes
on compile) report the command and exit code like so:
# 'perl assemble.pl t/op/basic2.pasm --output t/op/basic2.pbc' failed with exit code 1
I don't know if that's informative enough, but its a start anyway.
--- lib/Parrot/
begin quote from Michael G Schwern:
> This little patch makes command failures in tests (ie. if Parrot pukes
> on compile) report the command and exit code like so:
Thank you. This is quite wonderful.
--
I want you to know that I create nice things like this because it
pleases the Author of my
Enclosed patch adds the new SPARC-based JIT files to the manifest,
and also puts it back into alphabetical order.
Simon
--- MANIFEST.oldWed Jan 30 11:42:42 2002
+++ MANIFESTWed Jan 30 11:46:42 2002
@@ -6,35 +6,9 @@
MANIFEST
Makefile.in
NEWS
-lib/Parrot/Assembler.pm
-lib/Parrot
begin quote from Simon Cozens:
> > - Moved t/op/pmc* to t/op/pmc/
Sorry. Bad instructions. t/op/pmc/pmc_(.*) should become t/pmc/$1.
Thanks to Ask for fixing this. I'll fix the MANIFEST.
--
The warly race may riches chase,
An' riches still may fly them, O;
An' tho' at last they catch them f
In embed.h, we declare a function:
struct Parrot_Interp *interp_new();
that's never subsequently used. On the other hand, in embed.c,
we use a function
struct Parrot_Interp * Parrot_new() { ...
that isn't previously declared. Are these supposed to be the same thing?
If so, the patch
This patch clears up warnings in embed.c and test_main.c coming
from function declarations of the form:
void
foobar();
which should properly be
void
foobar(void);
Simon
--- test_main.c.old Tue Jan 29 20:00:01 2002
+++ test_main.c Wed Jan 30 12:05:36 2002
@@ -18,10 +18,10 @@
p
On Wed, Jan 30, 2002 at 01:15:42PM +, Simon Glover wrote:
>
> This patch clears up warnings in embed.c and test_main.c coming
> from function declarations of the form:
Thanks applied (with modifications, in that the functions in test_main are
now declared static).
Nicholas Clark
--
EMCFT
Sun's compiler is (rightly) complaining about the following lines in
io/io_unix.c:
PIO_unix_fdopen() is defined to take a UINTVAL fourth argument:
ParrotIO * PIO_unix_fdopen(theINTERP, ParrotIOLayer * layer,
PIOHANDLE fd, UINTVAL flags);
but it is later called with a
On Wed, 30 Jan 2002, Simon Glover wrote:
>
> Enclosed patch adds the new SPARC-based JIT files to the manifest,
> and also puts it back into alphabetical order.
>
> Simon
>
Applied thanks.
At 10:16 AM 1/30/2002 -0500, Andy Dougherty wrote:
>Sun's compiler is (rightly) complaining about the following lines in
>io/io_unix.c:
>
>PIO_unix_fdopen() is defined to take a UINTVAL fourth argument:
>
> ParrotIO * PIO_unix_fdopen(theINTERP, ParrotIOLayer * layer,
>
Hello p6i,
Who the hell am I?
I've been only a weblog-lurker till now. It's been a couple years since
I last contributed to Perl5. I just read the latest Apocalypse and it
inspired me to get a parrot snapshot and look around.
What's my beef?
I don't like the rx_literal and rx_oneof ops, and I do
On Wed, Jan 30, 2002 at 08:13:55AM -0800, Ashley Winters wrote:
> I think that's exactly what you should be doing! Neither parrot nor the
> rx engine should try to be a full compiler. The rx engine definitely
> should have opcodes in the virtual machine, but those opcodes should
> simply contain s
>Basically, I see a black-box being built in the interests of speed.
>Voodoo array formats, bitmaps, and other such things to avoid actually
>spelling out what the regular expression is doing *in parrot code*.
[snip]
>What I see is that rx_literal is a speed hack to avoid compiling this
>into par
Ashley Winters wrote:
>First, we set the rx engine to case-insensitive. Why is that bad? It's
>setting a runtime property for what should be compile-time
>unicode-character-kung-fu. Assuming your "CPU" knows what the gritty
>details of unicode in the first place just feels wrong, but I digress.
Ashley Winters:
# Who the hell am I?
# I've been only a weblog-lurker till now. It's been a couple
# years since
# I last contributed to Perl5. I just read the latest Apocalypse and it
# inspired me to get a parrot snapshot and look around.
Welcome back to the land of the living. :^)
# What's m
Thus it was written in the epistle of Dave Hartnoll,
> > Oh, one other tweak. The RFC proposes to overload next
> > to mean "fall through to the next case". I don't think
> > this is wise, since we'll often want to use loop controls
> > within a switch statement. Instead, I think we should
> > use
Simon wrote:
:> Have you an idea about what will be the 'final'
:> parser for the Perl 6 compiler ? (LALR(1), like Perl 5 ?)
:
:Yep, LALR1, probably yacc generated.
I recall reading somewhere that Perl6 was going to be parsed by something
very much like Parse::RecDescent, just that faster.
¿has
begin quote from Angel Faus:
> I recall reading somewhere that Perl6 was going to be parsed by something
> very much like Parse::RecDescent, just that faster.
Damian was meant to be writing Parse::FastDescent and then Parse::Perl,
but as we all know, he's a Very Busy Man. If anyone *wants* to try
> Damian was meant to be writing Parse::FastDescent and then
> Parse::Perl,but as we all know, he's a Very Busy Man.
Indeed.
But my 2002 Perl Foundation grant list those two modules (only!) as
deliverables. I'd say they'll be delivered -- probably by Christmas ;-)
Damian
begin quote from Ashley Winters:
> I think that's exactly what you should be doing! Neither parrot nor the
> rx engine should try to be a full compiler. The rx engine definitely
> should have opcodes in the virtual machine, but those opcodes should
> simply contain state-machine/backtracking info,
On Wed, Jan 30, 2002 at 09:32:49AM -0800, Brent Dax wrote:
> # rx_setprops P0, "i", 2
> # branch $start0
> # $advance:
> # rx_advance P0, $fail
> # $start0:
> # rx_literal P0, "a", $advance
> #
> # First, we set the rx
Many of the Perl scripts in the distribution (including assemble.pl !)
can no longer find the Parrot::* modules. Enclosed patch fixes (although
it would be nice if there were an easier way to do this).
Simon
--- languages/scheme/Scheme/Test.pm.old Wed Jan 30 17:42:08 2002
+++ languages/sch
Oops, scratch a couple of those; the pmc2c.pl one's not necessary,
and I see Daniel's already patched pbc2c.pl
Simon
At 5:53 PM + 1/30/02, Simon Glover wrote:
> Many of the Perl scripts in the distribution (including assemble.pl !)
> can no longer find the Parrot::* modules. Enclosed patch fixes (although
> it would be nice if there were an easier way to do this).
Applied, thanks.
--
On Wed, 30 Jan 2002, Ted Ashton wrote:
> Thus it was written in the epistle of Dave Hartnoll,
> > > Oh, one other tweak. The RFC proposes to overload next
> > > to mean "fall through to the next case". I don't think [...]
> >
> > I would like to suggest a different keyword that does not imply s
> > switch(...) {
> >case 1: ...;
> >nobreak; /* intentional fall-through */
> >case 2: ...;
> >break;
> >case 3: ...;
> > }
> >
> > Does anyone agree that `nobreak' reads much better than `skip'?
>
> "skip" was uncomforta
I posted this patch a while back, but it seems to have slipped
through the cracks. It fixes the POD in Parrot::Assember so that perldoc
can read it and just tidies it up generally. It also adds documentation
for the constantize_integer and constantize_number functions.
Simon
--- lib/Parro
At 11:06 AM + 1/30/02, Tim Bunce wrote:
>On Wed, Jan 30, 2002 at 07:48:25AM +0100, Paul Johnson wrote:
>> On Tue, Jan 29, 2002 at 09:57:16PM +, Simon Cozens wrote:
>>
>> > I've started a new TODO list. Remind me of anything else that needs
>> > doing;
>>
>> Sandboxes.
>>
>> Has anyone
At 6:30 PM + 1/30/02, Simon Glover wrote:
> I posted this patch a while back, but it seems to have slipped
> through the cracks. It fixes the POD in Parrot::Assember so that perldoc
> can read it and just tidies it up generally. It also adds documentation
> for the constantize_integer and
Jarkko Hietaniemi writes:
: > What I notice, though, is that the current code does not warn for
: > characters beyond 0x10, which is definitely a bug.
:
: Ahh, it's all coming back now... warning about such characters
: causes pain in the complementing tr///... have to look at this later.
I
Any idea what of this will become 0.0.4?
On Solaris, it looks like JIT will now be enabled if the user has also
installed GNU objdump. However, there is (often) already a disassembler
in /usr/ccs/bin/dis. It's output is similar, but not identical to,
objdump. Is anyone with a Solaris system familiar enough with jit
internals to have a
I'm being anal again. Here's an update to docs/running.pod to better
reflect the current state (both the test_parrot and assemble.pl
improvements, plus documentation of a few more things.) And also a
speling fiks s/POST_MORTERM/POST_MORTEM/.
I could also replace some "perl foo" calls with "./foo"
On Wed, 30 Jan 2002, Steve Fink wrote:
> Any idea what of this will become 0.0.4?
Is there any chance someone (simon) could make a TODO_FIRST [1], which contains
the goals for our next point release. I'm far too lazy to search through
mailing list archives to find it every time I want it.
[1]
On Wed, Jan 30, 2002 at 08:39:17PM +, Alex Gough wrote:
> On Wed, 30 Jan 2002, Steve Fink wrote:
>
> > Any idea what of this will become 0.0.4?
>
> Is there any chance someone (simon) could make a TODO_FIRST [1], which contains
> the goals for our next point release. I'm far too lazy to sea
At 3:27 PM -0500 1/30/02, Andy Dougherty wrote:
>On Solaris, it looks like JIT will now be enabled if the user has also
>installed GNU objdump. However, there is (often) already a disassembler
>in /usr/ccs/bin/dis. It's output is similar, but not identical to,
>objdump. Is anyone with a Solaris
At 12:36 PM -0800 1/30/02, Steve Fink wrote:
>I'm being anal again. Here's an update to docs/running.pod to better
>reflect the current state (both the test_parrot and assemble.pl
>improvements, plus documentation of a few more things.) And also a
>speling fiks s/POST_MORTERM/POST_MORTEM/.
>
>I co
This patch allows parrot to mostly-build with tcc. It allows one to skip
compiling the JIT stuff (by specifying --define jitcapable=0), and it
introduces a test program which gives a friendlier error in this case for
compilers which are as picky as tcc is about function pointer conversion.
If
On Mon, Jan 28, 2002 at 08:13:11PM +, Nicholas Clark wrote:
> Is a MANIFEST.SKIP a good idea, even if Configure.pl doesn't check it by
> default?
Revised patch. Any objections?
[Either express objections or remove my commit privs else it goes in in 24
hours :-)]
You can now do:
nick@thinkin
begin quote from Steve Fink:
> Perhaps a target version for each item?
Oh, bother. This is the second time I've been asked about this, so I
suspect that my goals for the forthcoming releases aren't amazingly
clear.
Here is the Grand Pronouncement!
0.0.4 WILL HAPPEN WHEN we have decent keyed agg
On Wed, Jan 30, 2002 at 09:32:45PM +, Nicholas Clark wrote:
> You can now do:
>
> nick@thinking-cap maniskip$ make manitest
> perl14405-32 -MExtUtils::Manifest=fullcheck -e fullcheck
> Not in MANIFEST: Configure.pl.rej
> Not in MANIFEST: MANIFEST.SKIP.orig
> Not in MANIFEST: MANIFEST.SKIP~
>
At 4:28 PM -0500 1/30/02, Josh Wilmes wrote:
>This patch allows parrot to mostly-build with tcc. It allows one to skip
>compiling the JIT stuff (by specifying --define jitcapable=0), and it
>introduces a test program which gives a friendlier error in this case for
>compilers which are as picky as
A quick recap and elaboration for folks following along at home.
On interpreter startup. P0 will hold an Array with ARGV in it if
there is one, or NULL if not.
P1 will hold a Hash with %ENV in it if there is one, or NULL if not
P2 (this is the new bit) will hold an Array of three elements
cor
We're adding the following:
INTVAL get_character(PMC *, INTVAL)
INTVAL get_character(PMC *, KEY *, INTVAL)
to return the character at position INTVAL in the passed in PMC.
--
Dan
--"it's like this"
I just committed a patch to jit2h.pl, Op.pm, and OpsFile.pm that
infers what ops may modify control flow, used by the jit to decide
whether to fall through to the next op or jump. (Daniel Grunblatt is
ok with it.) Just FYI.
On Wed, Jan 30, 2002 at 10:01:50PM +, Simon Cozens wrote:
> begin quote from Steve Fink:
> > Perhaps a target version for each item?
>
> Oh, bother. This is the second time I've been asked about this, so I
> suspect that my goals for the forthcoming releases aren't amazingly
> clear.
Or perh
On Wed, Jan 30, 2002 at 02:55:54PM -0800, Steve Fink wrote:
> On Wed, Jan 30, 2002 at 09:32:45PM +, Nicholas Clark wrote:
> > You can now do:
> >
> > nick@thinking-cap maniskip$ make manitest
> > perl14405-32 -MExtUtils::Manifest=fullcheck -e fullcheck
> > Not in MANIFEST: Configure.pl.rej
>
On Wed, Jan 30, 2002 at 06:23:43PM -0500, Dan Sugalski wrote:
> We're adding the following:
>
>INTVAL get_character(PMC *, INTVAL)
>INTVAL get_character(PMC *, KEY *, INTVAL)
>
> to return the character at position INTVAL in the passed in PMC.
are characters really INTVAL? I have this g
On Wed, Jan 30, 2002 at 11:20:28PM +, Nicholas Clark wrote:
> On Wed, Jan 30, 2002 at 02:55:54PM -0800, Steve Fink wrote:
>
> Ah. This suggests that this bit of the proposed MANIFEST.SKIP:
>
> ...
>
> becomes
>
> ^classes/.*\.[ch]$
>
> Is it valid to assume that the only .h and .c files i
At 11:40 PM + 1/30/02, Nicholas Clark wrote:
>On Wed, Jan 30, 2002 at 06:23:43PM -0500, Dan Sugalski wrote:
>> We're adding the following:
>>
>> INTVAL get_character(PMC *, INTVAL)
>> INTVAL get_character(PMC *, KEY *, INTVAL)
>>
>> to return the character at position INTVAL in the p
At 06:21 PM 1/30/2002 -0500, Dan Sugalski wrote:
>A quick recap and elaboration for folks following along at home.
>
>On interpreter startup. P0 will hold an Array with ARGV in it if there is
>one, or NULL if not.
>
>P1 will hold a Hash with %ENV in it if there is one, or NULL if not
>
>P2 (this
On Wednesday 30 January 2002 12:32, Brent Dax wrote:
> # Mostly, I'd like to hear how either Unicode character-ranges aren't
> # deterministic at compile-time (I doubt that) or how crippling to
>
> One word: locale.
Not that locales couldn't provide pre-compiled character classes.
--
Bryan C. W
On Wednesday 30 January 2002 11:13, Ashley Winters wrote:
> First, we set the rx engine to case-insensitive. Why is that bad? It's
> setting a runtime property for what should be compile-time
{snip}
> Now, the current CVS rx engine is/would do this at runtime.
We're also currently a compiler sh
On Wed, Jan 30, 2002 at 08:37:30PM -0500, Bryan C. Warnock wrote:
> "But if you know they're going to be twenty times slower, why are you doing
> it?" Because we know / think / hope / pray / have been making sacrifices to
Tangential note: current benchmarking indicates that we're doing a lot
b
At 6:28 PM -0800 1/30/02, Steve Fink wrote:
>I'm sure in Apoc 5 Larry's going to go way beyond that and embed full
>parsers, not just regularish language matchers, but the above is
>easier to grasp.
Odds are, yes. And don't be surprised if the RE engine's required to
return data structures as we
On Wednesday 30 January 2002 21:42, Dan Sugalski wrote:
> I think we may want trees as a fundamental data type at some point...
I wonder about the trees
--
Bryan C. Warnock
[EMAIL PROTECTED]
On Wed, Jan 30, 2002 at 03:27:18PM -0500, Andy Dougherty wrote:
> On Solaris, it looks like JIT will now be enabled if the user has also
> installed GNU objdump. However, there is (often) already a disassembler
> in /usr/ccs/bin/dis. It's output is similar, but not identical to,
> objdump. Is a
Larry Wall:
# For various reasons, some of which relate to the sequence-of-integer
# abstraction, and some of which relate to "infinite" strings
# and arrays,
# I think Perl 6 strings are likely to be represented by a list of
# chunks, where each chunk is a sequence of integers of the same size or
60 matches
Mail list logo
