Re: 6PAN (was: Half measures all round)
Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See also debian's apt-get. Which brings me to my pet peeve- I think it's time to start doing binary packaging in CPAN, for those who don't want to bother with compilation. That has interesting implications for how we deal with paths, but still, I think it's worthwhile. Of course you would want to support source as well, but having binary available for those who want it just seems like a darn good idea. Of course there would be issues of who's providing the binaries, how they are built, how external dependencies on third-party libraries are managed, etc, but still, I think it's worth looking into. It might not be a problem that's worth solving, in the end, but I think it's one worth giving serious thought to. --Josh At 23:38 on 06/04/2002 EDT, "Miko O'Sullivan" <[EMAIL PROTECTED]> wrote: > [This seems like a good time to post something that's been on my mind for > some time.] > > SUMMARY > > The world needs a really easy CPAN client. Here's one design for such a > thing. > > DETAILS > > A few brief philosphical points: > > 1) People like languages that have tons of built-in > doohickeys. See PHP and Java. > > 2) Instead of a huge standard library, a really easy to use CPAN > client allows programmers to have the world of modules almost > as easily as built-in, and with the advantage of up-to-date-ness > and quantity. > > 3) The current CPAN.pm isn't really easy to use. Now matter how > simple it may seem to the Perl Guru community, inexperienced > users find it intimidating to download CPAN modules. > Remember: beginners end up ruling the world. See Microsoft. > > Solution: a simple program that is called from the command line. Here's a > brief tour: > > Download and install a module from CPAN. Loading a module also automatically > loads its dependencies. > >cpan load Date::EzDate > > The command above would ask the user if they want to install using the > current directory as the root of library tree, and is also mentions that if > they want to specify another dir they can use this command: > >cpan --lib ~/lib load Date::EzDate > > Update a module. > >cpan update Date::EzDate > > Don't download dependencies: > >cpan --dep 0 load Date::EzDate > > Update all currently installed modules: > >cpan update * > > Update a namespace: > >cpan update Date::* > > Get help on using cpan: > >cpan help > > No configuration files (.e.g .cpan) are necessary. However, you can use a > configuration file if you want tp indicate a .cpan-like file > >cpan --conf ~/.cpan load Date::EzDate > > Get from a particular FTP server > >cpan --server cpan.idocs.com load Date::EzDate > > By default, progress messages are kept to a minimum. No more of those > hundreds of lines of bewildering make messages. > >cpan --lib ~/perllib load Date::EzDate >finding server >downloading module >determining dependencies >downloading dependencies >installing >done > > Optional verbose mode >cpan --verbose load Date::EzDate >(hundreds of lines of lovely make messages) > > Request particular operating system compilation (e.g. Win32) > (usually not needed explicitly because cpan.pl will know which compilation > to ask for) > >cpan --compile win32 load Date::EzDate > > Indicate latest development vs. latest stable > >cpan --latest beta load Date::EzDate > > Remove a module >cpan remove Date::EzDate > > > - > Other Misc CPAN Ideas > > - Authors don't need to indicate dependencies. CPAN figures it out from the > use's and require's. CPAN will not accept modules that depend on other > modules that aren't on CPAN. (Yes, there might be a chicken and egg problem > there, I'm sure we can find a solution.) This leads me to... > > - Run-time dependencies: Dependencies can be indicated explicitly with > something like this: > > use Dependency Date::Language::French; > > - CPAN conformity: All modules served from CPAN must meet certain > specifications. They must include a version, POD, license statement, and > probably other meta-info. The meta-info would be standardized so that the > system could tell that the module conforms. > > - Automated load balancing: cpan.perl.org doesn't have to pay for the > bandwidth of the whole world. cpan.pl should recognize a command from > CPAN.org to redirect to another server. > > - 6pan.org: The domain name 6pan.org is available as of this writing. Larry, > are you planning on saying "6PAN" enough to merit somebody registering > 6pan.org? > >
Re: Minimum perl version ?
On Wed, Jun 05, 2002 at 01:44:07PM -0400, Andy Dougherty wrote: > because lib/Parrot/Makefile.PL contains > > WriteMakefile( > 'NAME' => 'Parrot::PakFile2', > 'VERSION_FROM' => 'PakFile2.pm', # finds $VERSION > > and PakFile2.pm says (among other things) > > require 5.005_62; > use warnings; > > our @ISA = qw(Exporter DynaLoader); > > none of which will work with 5.005. > > Is it perhaps time to require 5.6.x? It's probably a better idea not to use 5.6.x's h2xs to generate extensions. 5.8 has a flag to generate extensions that don't use any 5.6isms in their boilerplate code, and (oddly enough) 5.005_03's h2xs doesn't generate any 5.6isms in the boilerplate code either :-) Also, 5.6's h2xs generates buggy code for constant(), which is enough of a reason to avoid for the general case of extension building. I'm unconvinced that 5.6 offers any features over 5.005 that we really need (5.005 introduces qr//) and it seems to me that we keep the barriers to building parrot as low as practical, to encourage the most participation. A greater number of OSes have perl >5.005 installed by default than >5.6 Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
[netlabs #674] [PATCH] saveall and restoreall
Index: core.ops
===
RCS file: /home/perlcvs/parrot/core.ops,v
retrieving revision 1.147
diff -u -r1.147 core.ops
--- core.ops5 Jun 2002 01:56:08 - 1.147
+++ core.ops5 Jun 2002 20:27:41 -
@@ -2731,6 +2731,38 @@
=cut
+
+
+=item B()
+
+Save all the registers.
+
+=item B()
+
+Restore all the registers.
+
+=cut
+
+inline op saveall() {
+ Parrot_push_i(interpreter);
+ Parrot_push_n(interpreter);
+ Parrot_push_s(interpreter);
+ Parrot_push_p(interpreter);
+ goto NEXT();
+}
+
+inline op restoreall() {
+ Parrot_pop_i(interpreter);
+ Parrot_pop_n(interpreter);
+ Parrot_pop_s(interpreter);
+ Parrot_pop_p(interpreter);
+ goto NEXT();
+}
+
+=back
+
+=cut
+
###
=head2 Register stack operations
Re: Stack
On Wed, Jun 05, 2002 at 12:07:26PM -0700, Sean O'Rourke wrote: > Another thing to toss into the discussion, preferably sooner rather than > later: continuations. From what I can tell, implementing continuations > relies on having an arbitrary graph of "stack" frames, and garbage > collecting them when they can no longer be reached. Putting continuations > on top of a C-like stack looks either expensive, difficult, or both -- > sure, you can always copy the entire stack whenever someone does a > call/cc, but for cases where the continuation is not invoked, or in which > it is used like an exception, this seems wasteful. With a C-like stack, we can implement something similar to what is described in the paper "Representing Control in the Presence of First-Class Continuations" (http://citeseer.nj.nec.com/hieb90representing.html). This seems reasonably efficient. -- Jerome
Re: Stack
At 4:48 PM +0200 6/5/02, Jerome Vouillon wrote: >My feeling is that the current implementations of stacks are not >adequate: >- the control stacks store too many registers at once; The control stack doesn't store any registers at all. I presume you're talking about the four register frame stacks. >- the generic stack is typed, so it is slow; Yep, hence the integer stack. Access to the generic stack can and should be faster. I'm thinking of some call-framing stuff to speed it up. >- none of these stacks provide any support for register > spilling/reload: there is no opcode to get or set the > n-th element of a stack. Which is just a deficiency in the opcode set, or would be if we didn't have one of these opcodes. Though arguably the rotate_up op is a bit less than spiffy, in which case all we need to do is add an op. (So I will) >So, I propose to replace them by a single stack. Here is a design >proposal. What do you think about it? Nope. :) Seriously, a linear stack, even a chunked one like we have, makes continuations a major pain. Continuations are going to be more prevalent as soon as exceptions come online in the next few days. Also, the problem with a single untyped stack is garbage collection. Right now, *all* entries on the stack are typed, either implicitly (the PMC and String frame stacks) or explicitly (the user stack). Forcing the GC to intuit whether a pointer on the stack is for a PMC or string (or is, in fact, even a pointer) is a rather time-intensive thing and, given how rarely the stack's likely to be used anyway, I don't see it as a big issue. Could be wrong, of course. Wouldn't be the first time. I'll need more convincing for that, though. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
[PATCH] Re: Minimum perl version ?
This is supposed to have one of those bug ID thingies, isn't it, so that it
doesn't get lost?
All tests successful, 9 subtests skipped.
Files=19, Tests=359, 190 wallclock secs (162.14 cusr + 22.67 csys = 184.81 CPU)
nwc10@colon [parrot5005]$ grep ^PERL Makefile
PERL = /usr/bin/perl
nwc10@colon [parrot5005]$ /usr/bin/perl -v
This is perl, version 5.005_03 built for i386-freebsd
Copyright 1987-1999, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5.0 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
Nicholas Clark
--
Even better than the real thing:http://nms-cgi.sourceforge.net/
--- ./include/parrot/debug.h.orig Mon Jun 3 09:06:19 2002
+++ ./include/parrot/debug.hWed Jun 5 21:31:56 2002
@@ -196,12 +196,6 @@ PDB_print_stack_pmc(struct Parrot_Interp
void
PDB_help(const char *);
-#define na(c) { \
-while(*c && !isspace(*c)) \
-c++; \
-while(*c && isspace(*c)) \
-c++; }
-
#define valid_chunk(chunk,c,d,s,i) { \
if (*c) { \
d = atol(c); \
--- ./lib/Parrot/PakFile2.pm.orig Mon Apr 29 05:22:02 2002
+++ ./lib/Parrot/PakFile2.pmWed Jun 5 21:23:50 2002
@@ -1,71 +1,23 @@
package Parrot::PakFile2;
-require 5.005_62;
+require 5.005;
use strict;
-use warnings;
use Carp;
+use vars qw (@ISA $VERSION);
-require Exporter;
require DynaLoader;
-use AutoLoader;
-our @ISA = qw(Exporter DynaLoader);
+@ISA = qw(Exporter DynaLoader);
# Items to export into callers namespace by default. Note: do not export
# names by default without a very good reason. Use EXPORT_OK instead.
# Do not simply export all your public functions/methods/constants.
-# This allows declaration use Parrot::PakFile2 ':all';
-# If you do not need this, moving things directly into @EXPORT or @EXPORT_OK
-# will save memory.
-our %EXPORT_TAGS = ( 'all' => [ qw(
-
-) ] );
-
-our @EXPORT_OK = ( @{ $EXPORT_TAGS{'all'} } );
-
-our @EXPORT = qw(
-
-);
-our $VERSION = '0.01';
-
-sub AUTOLOAD {
-# This AUTOLOAD is used to 'autoload' constants from the constant()
-# XS function. If a constant is not found then control is passed
-# to the AUTOLOAD in AutoLoader.
-
-my $constname;
-our $AUTOLOAD;
-($constname = $AUTOLOAD) =~ s/.*:://;
-croak "& not defined" if $constname eq 'constant';
-my $val = constant($constname, @_ ? $_[0] : 0);
-if ($! != 0) {
- if ($! =~ /Invalid/ || $!{EINVAL}) {
- $AutoLoader::AUTOLOAD = $AUTOLOAD;
- goto &AutoLoader::AUTOLOAD;
- }
- else {
- croak "Your vendor has not defined Parrot::PakFile2 macro $constname";
- }
-}
-{
- no strict 'refs';
- # Fixed between 5.005_53 and 5.005_61
- if ($] >= 5.00561) {
- *$AUTOLOAD = sub () { $val };
- }
- else {
- *$AUTOLOAD = sub { $val };
- }
-}
-goto &$AUTOLOAD;
-}
+$VERSION = '0.01';
bootstrap Parrot::PakFile2 $VERSION;
# Preloaded methods go here.
-
-# Autoload methods go after =cut, and are processed by the autosplit program.
1;
__END__
--- ./debug.c.orig Tue Jun 4 19:51:39 2002
+++ ./debug.c Wed Jun 5 21:32:34 2002
@@ -19,6 +19,14 @@
#include
#include
+/* This clashes with 5.005_03's headers. */
+#define na(c) { \
+while(*c && !isspace(*c)) \
+c++; \
+while(*c && isspace(*c)) \
+c++; }
+
+
/* PDB_get_command
* get a command from stdin to execute
*/
--- /dev/null Mon Jul 16 22:57:44 2001
+++ lib/Parrot/ppport.h Wed Jun 5 21:35:23 2002
@@ -0,0 +1,540 @@
+
+/* ppport.h -- Perl/Pollution/Portability Version 2.0002
+ *
+ * Automatically Created by Devel::PPPort on Wed Jun 5 21:35:23 2002
+ *
+ * Do NOT edit this file directly! -- Edit PPPort.pm instead.
+ *
+ * Version 2.x, Copyright (C) 2001, Paul Marquess.
+ * Version 1.x, Copyright (C) 1999, Kenneth Albanowski.
+ * This code may be used and distributed under the same license as any
+ * version of Perl.
+ *
+ * This version of ppport.h is designed to support operation with Perl
+ * installations back to 5.004, and has been tested up to 5.8.0.
+ *
+ * If this version of ppport.h is failing during the compilation of this
+ * module, please check if a newer version of Devel::PPPort is available
+ * on CPAN before sending a bug report.
+ *
+ * If you are using the latest version of Devel::PPPort and it is failing
+ * during compilation of this module, please send a report to [EMAIL PROTECTED]
+ *
+ * Include all following information:
+ *
+ * 1. The complete output from running "perl -V"
+ *
+ * 2. This file.
+ *
+ * 3. The name & version of the module you were trying to build.
+ *
+ * 4. A full log of the build that failed.
+ *
+ * 5. Any
Re: Stack
On Wed, Jun 05, 2002 at 12:07:26PM -0700, Sean O'Rourke wrote: > language feature, and that they will rarely be used. I'm sympathetic to > that point of view, having never felt the lack of continuations in my > brief programming life, but if that's the way we want to go, we should at > least be explicit about it. The Ruby style uses lots of continuations. If we want to be a common VM for the major scripting languages, we should take them into account. Just something to keep in mind. Joe
Stack
My feeling is that the current implementations of stacks are not adequate: - the control stacks store too many registers at once; - the generic stack is typed, so it is slow; - none of these stacks provide any support for register spilling/reload: there is no opcode to get or set the n-th element of a stack. So, I propose to replace them by a single stack. Here is a design proposal. What do you think about it? -- Jerome Description === A stack frame has the following structure: ---+---+-+--+---+---+--- |(1)| (2)| (3) |(4)|(5)| ---+---+-+--+---+---+--- ^ | stack pointer (1) frame description (1 stack entry) (2) function arguments (3) local data (4) return address (1 entry) (5) saved stack pointer (1 entry) (point to the beginning of (2)) The stack pointer points to the beginning of the function arguments of the topmost frame. The frame description is a pointer to a structure containing: - the number of arguments of each type, - the type of the local data - the size of the frame - the amount of stack needed by the function (including the space needed for them arguments of the functions that may be called from this function) - possibly some other information, if needed We have the following operations (I use some pseudo C code to explain them): - Function call: call P0 contains the function closure, and I0 a pointer to a description of the arguments. size = ((frame_desc *) st[-1])->size; /* get the current frame size */ st[size - 3] = pc + 2; /* save the return address */ st[size - 2] = st; /* save the stack pointer */ st += size;/* move to the next stack frame */ pc = ((closure *)P0)->pc; /* jump to the function address */ - Function tail call: tailcall P0 contains the function closure, and I0 a pointer to a description of the arguments. pc = ((closure *)P0)->pc; /* jump to the function address */ - Function initialization: frame points to a frame description. /* Check the arguments number and types (compare the information in I0 and ) */ /* Check whether there is enough room on the stack for the local data and the arguments of the functions this function may call; if not, then allocate a new stack chunk */ /* Fill the frame with GC-safe values */ st[-1] = /* store the frame description */ - Function return : ret pc = st[-3]; /* jump to the return address */ st = st[-2]; /* restore the stack pointer */ - Stack read access : load , = st[] - Stack write access : store , st[] = GC == The GC can walk the stack using the saved stack pointer: st = st[-2]; /* Move to the previous stack frame */ It can use the frame description (st[-1]) to know which stack entry need to be followed. When performing a function call, we may need to put some arguments on the stack, beyond the end of the frame. Also, for tail calls, we are going to overwrite some function arguments and maybe some local data. We should be careful that the GC is not triggered at this point. For instance, we can first write the function arguments to the local data, and only afterwards move them to their final location. A better design would be to have a table which indicates for each return address which entries of the corresponding frame need to be followed by the GC. Then, we don't need to store frame descriptions on the stack, nor to initially fill the frame with GC-safe values. Debugging = We could have a debugging version of the opcodes, that make some sanity checks: - we don't write out of the frame; - we don't write a value of some type and then reload it with another type; ... The opcode version could be selected during bytecode fixup. Floats == On a lot of architectures, they are twice as large as integers and pointers. So, we have two options: - make the stack entries large enough for floats (this wastes memory) - use to stack entries to store floats (we then need to be careful with memory alignement)
Ix regs for keyed access, PMCs and other peeves
Warning, if this message is too long, please skim to the bottom and read
the part marked IDEA, lest it get lost in the rant.
Why make keyed access of arrays any more complicated than it
needs to be?
The Ix regs are for optimization, so it seems natural
for Ix or ICx simply return the i-th element, rather than
the "keyed" element. Internally the KEY is converted _back_
to INTVAL if it is native, or calls the get_integer method
of the PMC.
Maybe the problem is we are using the same interface for arrays
as hashes?
If in Perl I say:
push @list, "0th";
push @list, "1st";
print $list[0] . "\n";
print $list[1] . "\n";
I get:
0th
1st
Not being quite the seasoned Perl hacker that some of you are,
can someone point out to me why _arrays_ need accessors
converted to a KEY, then right back to an int. If Perl wants that, fine,
but why force it on the Parrot implementation.
Most languages require array indexes to be integer types, and I thought
Perl did the same.
I figure a lot of code will be of the type
foreach $s (@list) {
print $s;
}
set I0, 0
NEXT:
set S0, P0[I0]
jundef S0, LAST
print S0
inc I0
LAST:
Could this be how chop @list is implemented? Possibly.
I'm not sure, but I know for/foreach is a typical construct in most Perl
programs.
Finally, even though I've heard Dan's reasons, the 75% treatment
of the I, S and N regs still bugs me (can't store globals, cant use
in keyed access). Some languages don't need PMCs at
all for the basic types. They deal with strictly typed items,
and aren't interested in polymorphism of builtin types, rather
they need _support_ for implementing their own polymorphism.
I always hoped that we could rip out most of the PMCs and have
a working VM (keeping certain ones for handling opaque system
objects like IO handles, subroutine handles, symbol tables, etc.)
Right now I don't see this happening. I see lists and hashes
implemented, but called Perl*, not Parrot*. Are we expecting
people to provide a full set of PMCs when they wish to implement
their language on Parrot? What happens to the common runtime then?
Oops, you can't run your Ruby code, you haven't installed libVMRuby.so..
Er, I can't use PerlArray because my language Foo needs arrays
to do X, Y and Z. So I either implement it at the Parrot level, or
write a PMC.
I also don't like the idea of the classes/ directory being full of
every language's PMCs, eek.
That is not my idea of what a VM is.
We are providing a non-orthogonal implementation for other
languages, in my opinion. Granted, if the language wishes
to be compatible with Perl and others running on the same VM,
then they need to follow a few fules, since Perl is 1st priority.
IDEA:
On PMCs themselves: PerlInt is nothing but a wrapper
for a native int. It knows how to call vtable methods of other
objects when it is involved in an operation with that object, and
most importantly it knows how to morph itself, but it is STILL just
a wrapper. Why is this? Wouldn't it make more sense if everything
were 'PerlScalar'. It seems PerlInt, PerlString and PerlNum could
be all combined into a 'PerlScalar'. Then we could go back to
letting things that are ints, be ints. Whee!
:)
-Melvin
[netlabs #669] [PATCH] fix jako's use of inc and dec
Index: jakoc
===
RCS file: /cvs/public/parrot/languages/jako/jakoc,v
retrieving revision 1.16
diff -u -u -p -r1.16 jakoc
--- jakoc 28 Jan 2002 20:21:38 - 1.16
+++ jakoc 4 Jun 2002 20:26:45 -
@@ -1895,7 +1895,7 @@ sub do_add
$temp .= ".0" if (num_q($a) or num_q($b)) and not $temp =~ m/\./;
emit_code('set', [$dest, $temp]);
} elsif (reg_q($b)) {
- if ($dest eq $b) {
+ if ($dest eq $b && int_q($a)) {
emit_code('inc', [$dest, $a]);
} else {
my $temp = int_q($a) ? 'I0' : 'N0';
@@ -1907,7 +1907,7 @@ sub do_add
}
} elsif (reg_q($a)) {
if (int_or_num_q($b)) {
- if ($dest eq $a) {
+ if ($dest eq $a && int_q($b)) {
emit_code('inc', [$dest, $b]);
} else {
my $temp = int_q($b) ? 'I0' : 'N0';
@@ -1934,9 +1934,13 @@ sub do_inc
my ($dest, $amount) = @_;
if (defined $amount) {
-push_source "$dest += $amount;";
-($dest, $amount) = map_args($dest, $amount);
-emit_code('inc', [$dest, $amount]);
+if (int_q($amount)) {
+ push_source "$dest += $amount;";
+ ($dest, $amount) = map_args($dest, $amount);
+ emit_code('inc', [$dest, $amount]);
+} else {
+ do_add($dest, $dest, $amount);
+}
} else {
push_source "$dest++;";
($dest, $amount) = map_args($dest);
@@ -1963,7 +1967,7 @@ sub do_sub
$temp .= ".0" if (num_q($a) or num_q($b)) and not $temp =~ m/\./;
emit_code('set', [$dest, $temp]);
} elsif (reg_q($b)) {
- if ($dest eq $b) {
+ if ($dest eq $b && int_q($a)) {
emit_code('dec', [$dest, $a]);
} else {
my $temp = int_q($a) ? 'I0' : 'N0';
@@ -1975,7 +1979,7 @@ sub do_sub
}
} elsif (reg_q($a)) {
if (int_or_num_q($b)) {
- if ($dest eq $a) {
+ if ($dest eq $a && int_q($b)) {
emit_code('dec', [$dest, $b]);
} else {
my $temp = int_q($b) ? 'I0' : 'N0';
@@ -2002,9 +2006,13 @@ sub do_dec
my ($dest, $amount) = @_;
if (defined $amount) {
-push_source "$dest -= $amount;";
-($dest, $amount) = map_args($dest, $amount);
-emit_code('dec', [$dest, $amount]);
+if (int_q($amount)) {
+ push_source "$dest -= $amount;";
+ ($dest, $amount) = map_args($dest, $amount);
+ emit_code('dec', [$dest, $amount]);
+} else {
+ do_sub($dest, $dest, $amount);
+}
} else {
push_source "$dest--;";
($dest, $amount) = map_args($dest);
--
Don't get suckered in by the comments -- they can be terribly
misleading. Debug only code.
--Dave Storer
Minimum perl version ?
According to README,
You'll also need Perl 5.005 or above, compiled to support
the types you wish to support in Parrot. (Parrot will
make, but you'll be unable to assemble anything.) You can find
what types are support by typing 'perl -V', and examining the
values for ivtype and nvtype. Parrot should work with INTVALs
and NUMVALs up to those types.
However, trying to build with the Sun-supplied 5.005_03, I get the error
cd lib/Parrot && /usr/bin/perl Makefile.PL && make && cd ..
Could not eval '
package ExtUtils::MakeMaker::_version;
no strict;
local $VERSION;
$VERSION=undef; do {
our $VERSION = '0.01';
}; $VERSION
' in PakFile2.pm: Can't modify subroutine entry in scalar assignment at
(eval 6) line 7, at EOF
*** Error code 2
make: Fatal error: Command failed for target `lib/Parrot/.dummy'
because lib/Parrot/Makefile.PL contains
WriteMakefile(
'NAME' => 'Parrot::PakFile2',
'VERSION_FROM' => 'PakFile2.pm', # finds $VERSION
and PakFile2.pm says (among other things)
require 5.005_62;
use warnings;
our @ISA = qw(Exporter DynaLoader);
none of which will work with 5.005.
Is it perhaps time to require 5.6.x?
(Note too that perl -V:ivtype and perl -V:nvtype also won't work in 5.005 -- those too
were introduced in the
5.6.x series.)
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayette College, Easton PA 18042
Re: Stack
At 04:48 PM 6/5/2002 +0200, Jerome Vouillon wrote: >My feeling is that the current implementations of stacks are not >adequate: >- the control stacks store too many registers at once; They are register windows, so I think they work fine for that purpose. It doesn't mean the control stack must be used everywhere. >- the generic stack is typed, so it is slow; I agree here, sort of. Since I didn't write it, I can't comment, except I'd like to hear the pros and cons of a typed vs. non-typed stack. We are already assuming that the compiler will generate valid internal state, so why check stack entries? Possibly there can be a compile time option for developers to use a typed stack, which would not exist at runtime in the general distribution? >- none of these stacks provide any support for register > spilling/reload: there is no opcode to get or set the > n-th element of a stack. This part I definitely agree with. While its not true that there is NO support, it makes writing a register spiller more compilicated when you have to worry about the order in which you spill, and interference. There >So, I propose to replace them by a single stack. Here is a design >proposal. What do you think about it? Looks like C calling convention, give or take a bit. >Floats >== >On a lot of architectures, they are twice as large as integers and >pointers. So, we have two options: >- make the stack entries large enough for floats (this wastes memory) >- use to stack entries to store floats (we then need to be careful > with memory alignement) The JVM does the latter. I think the first option is not attractive because it bloats the stack since Floats are in the minority. I think there are some valid concerns here. -Melvin
[PATCH] vtable PDD patch
This clarifies some semantics of the get_string and substr vtables. Index: docs/pdds/pdd02_vtables.pod === RCS file: /home/perlcvs/parrot/docs/pdds/pdd02_vtables.pod,v retrieving revision 1.10 diff -r1.10 pdd02_vtables.pod 175c175,176 < encoding of the PMC's choice. --- > encoding of the PMC's choice. This string may be modified without modifying > the PMC. 324,325c325,327 < Return a substring of the passed in PMC. Returns a substring, either < as a PMC or a STRING. --- > Return a substring of the passed in PMC. Returns a substring, either as a PMC > or a STRING. When returning a STRING, the string may be modified without > modifying the PMC.
Re: Stack
Another thing to toss into the discussion, preferably sooner rather than later: continuations. From what I can tell, implementing continuations relies on having an arbitrary graph of "stack" frames, and garbage collecting them when they can no longer be reached. Putting continuations on top of a C-like stack looks either expensive, difficult, or both -- sure, you can always copy the entire stack whenever someone does a call/cc, but for cases where the continuation is not invoked, or in which it is used like an exception, this seems wasteful. You could argue that they can be slow because they're not a very important language feature, and that they will rarely be used. I'm sympathetic to that point of view, having never felt the lack of continuations in my brief programming life, but if that's the way we want to go, we should at least be explicit about it. /s
Auto-capturing
I just read through A5 (wow, that's long), and I agree with most of it. Some of it's really cool. Here's what makes me uneasy: The fact that a grammar rule auto-captures into a variable of its name. Is this efficient? If I'm writing a syntax-directed translator, I usually don't need to capture the rules. The rules are run for their side-effects. I definitely see the win, but I see a lose in it too. Seems like an awful lot of memory's going to be wasted if I'm matching a big file with one C<$grammar.match>. Is there a way to tell it I to capture something from a grammar rule? Should auto-capture really be default? Is someone going to tell me "well, it's really not inefficient because ... optimizes " That would relieve me greatly. I am waiting eagerly for Exegesis 5 :) This is fun stuff. Luke
Re: 6PAN (was: Half measures all round)
> For the record, you will hear no disagreement from me. I recognize that > this is a HARD problem. Nonetheless, I think it's an important one, and > solving it (even imperfectly, by only supporting well-defined platforms) > would be a major coup. I'd like to take that even further: just supporting Win32 binaries would be a major coup. Very few windows users can compile, but a much more significant percent of Un*x users can. A few more ways to address issues of multi-platform (my favorite is at the end): - Divide and conquer: design the 6PAN so that individuals and small groups can set up their own binary specific distribution sites. One person might decide to set up a Win32 distribution site, another a Mac distribution site. They can all register on the central 6PAN server. Users can then choose which distributions they prefer in general. - Unit testing: with binaries it becomes more imperative that downloaded modules are rigourously tested. Unit tests should be distributed with modules, and download clients should have a way of saving errors and (if the user givesd permission) sending them back to the developer. - My favorite: don't do binaries. With bytecode Pure Perl makes all the more sense. I'm not saying binaries should be prohibited, but the culture should steer away from them.
A5: thread safety of matching
As always, most of it is great. so only the niggles get discussed. On page 7, the following example is given: $oldpos = pos $string; $string =~ m/... <( .pos == $oldpos )> .../; This implies that match position is associated with the string. This worries me. If 2 threads are matching on the same string (intuitively safe, because matching is a read-only operation) then both threads may both attempt to set ..pos. This would be unfortunate. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
Re: A5: thread safety of matching
At 4:52 PM -0700 6/5/02, David Whipp wrote: >As always, most of it is great. so only the niggles get discussed. > >On page 7, the following example is given: > > $oldpos = pos $string; > $string =~ m/... <( .pos == $oldpos )> .../; > >This implies that match position is associated with the string. This worries >me. If 2 threads are matching on the same string (intuitively safe, because >matching is a read-only operation) then both threads may both attempt to set >..pos. This would be unfortunate. pos is an iterator, and we ought to treat it like iterators on hashes and arrays, i.e. a separate entity from what's being iterated on. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 01:11:58PM -0700, David Wheeler wrote: > On 6/4/02 12:59 PM, "Steve Simmons" <[EMAIL PROTECTED]> claimed: > > > Actually, for 6PAN I think they should have to pass. And maybe we > > need a bug submission setup, and status checks, and . . . OK, OK, I'll > > stop now. They're nice ideas, but who bells the cat? The again, if > > Tim O'Reilly wants to fund me I'd be happy to do it. :-) > > On what platform(s)? Who's going to pay for the test bed for every possible > combination of perl version, OS, various libraries, etc., etc.? I think that > *requiring* that all tests pass is unrealistic. Perhaps so, but I'd prefer to see this as a goal and fall short rather than set our sights lower and achieve an empty success. As for funding - well, one source has been mentioned above. Another might be the H/W vendors. Suppose we modify the proposal to have a list of systems on which the module has been known to pass (or fail) self-test? Get H/W and O/S donations from Sun, HP, etc, volunteer labor to assemble a test framework, and then let people upload. On the web page for a given 6PAN module put a pass/fail indicator for all the stuff that vendors have donated. Vendor X wants to be on the list? Let 'em donate hardware, S/W, and (maybe eventually) something towards overhead. Hmmm, we may have a good idea here...
Implement 6PAN now with CPANPLUS shell frontends.
[For those of you coming in late, here's the relevent thread from perl6-language http:[EMAIL PROTECTED]/msg10024.html ] Some of you may or may not be aware that I hate waiting, especially when it's about good ideas for Perl 6. Some of you may also be aware of the CPANPLUS project to reimplement the CPAN shell: http://cpanplus.sourceforge.net/ What you may not know is that CPANPLUS includes the ability to have *multiple shell frontends*. http://cpanplus.sourceforge.net/backend.html Currently there's plans for two. One mimicing the classic CPAN shell and a new one the CPANPLUS folks are developing in their own image (the default). Now, none of the suggestions I've seen so far in the 6PAN shell interface thread are particularly radical and don't need to wait for Perl 6 or 6PAN. So rather than just talking about it, DO IT! Implement your 6PAN shell ideas as CPANPLUS frontends. Write an apt-get or dselect style interface to CPAN. Write a CPAN shell that doesn't need initial, manual configuration. Write a pointy-clicky GUI frontend. Experiment! Code speaks louder than mailing list threads. :) -- This sig file temporarily out of order.
Re: 6PAN (was: Half measures all round)
On Tue, Jun 04, 2002 at 04:15:02PM -0400, John Siracusa wrote in response to me: > > Frankly, I'd argue that nothing in 6PAN ought to be in alpha/beta state. > . . . > Nah, I think it's useful to be able to upload "unstable" versions to 6PAN to > get the widest possible audience of testers. It's a lot easier than hosting > it on a web site or whatever--for both the developer and the users. . . . True, true. You've convinced me. > > . . . . With (potentially) many modules having > > the same name and multiple authors/versions, the current complexity of > > the perl /lib tree could increase to the third power. That gonna be > > very disk-intensive for every frigging perl script that runs. > > See my earlier framework/bundle suggestion. I don't think it's that bad, > disck-access-wise. Sticking just to the disk-intensive issue for a moment -- Due to our judicious writing of modules, libraries, etc, we tend to have a lot have relatively simple (less than 1000 lines) scripts that do quite useful things for managing our network (sorry, can't talk about 'em -- proprietary software and all that sort of rot). Each tool does a direct use or require of about a half-dozen things, but our master modules and libs grab quite a few more. All in all I guestimate we're loading anywhere from 30 to 100 modules per `simple' tool run. With standard @INC plus our two or three more, that's 8-10 directory trees that must be searched. The current perl module naming schema means (essentially) one probe per directory per package until the module is found. Once it's found, all is done. With the new one, we seem to have agreed that `most recent' will be used, not `first found'. That means that every tree must be probed, and probed with globs or sub-searches to match the various author, version, $RELEASE, etc stuff. Only once we know what's available can we make an intelligent `most recent' decision. At a minimum, with 10 items in @INC we have a tenfold increase in number of dir reads. Then add in the checking for author, version, etc ... and we've got to either embed the author/version/release data into the file names (the horror, the horror) or open the individual modules and read the author/version/release data from each one (the horrorer, the horrorer). This very strongly argues towards indexes. My seat of the pants number say our current tools (which use DBI to access databases) spend about as 10% of their CPU and wall clock time in compilation. This is measured by deliberately running the tools with an error (bad switch) vs running it correctly and comparing the times. Go to a module/version/release seach pattern and a ten-fold minimum increase in serach time . . . and you double the tool run times. That's intolerable in our environment. I recently spent a solid month peeling 9 seconds of per-tool overhead down to 1 second, getting a documented(!) savings of 16.25 hours *per week* in our operations group. The prospect of losing that time again with perl6 is, er, not acceptable. Again, this argues towards indexes. > > The current perl module tree is pretty difficult for the average day to > > day scripter to comprehend. I'd go even further and say that it's so > > complex as to be unmanagable. > > Encapsulating by module would make the structure pretty easy to understand, > IMO. Yes, that would help with the understanding. It would not help with the search time overhead. > Disk space and RAM are cheap and getting cheaper. Think about what you mean > by "gigantic." Anyone who exhausts memory by running 150 different versions > of the Tk module at once deserves what they get ;) > > > On the other hand, there's no reason that shared libs couldn't be stored in a > > standard location and symlinked to. > > Yes there is: sanity! I think that's a foolish optimization. It makes > things much too fragile. Stuff like that already drives me nuts in regular > Unix OS/app installations. I picked Tk as my example because it *cannot* work with multiple versions of the shared libraries (the .so files, not the perl modules) simultaneously. Every window, every widget, every Ghu-knows-what down to a fairly low level must reside in the same context. If they don't, subwindows don't get managed properly, widgets from version X can't be attached to units from version Y, etc, etc. The same is almost certianly true of DBI modules, Gnome modules, and many others. The 6PAN installation tree and perl6 module builds must be able to deal with this issue. If they don't, then Larry's promise of the ability of simultaneous load is only going to apply to pure perl modules. But I don't think that's what Larry means, and I don't think it's a restriction we *have* to live with. Steve -- STEP 4: PRACTICE THE RULE OF THREE: If an e-mail thread has gone back and forth three times, it is time to pick up the phone. from the 12-Step Program for email addicts, http://www.time.com/time/columnist/taylor/article/0,9565,2
Re: 6PAN (was: Half measures all round)
On 6/5/02 2:59 PM, Steve Simmons wrote: > Sticking just to the disk-intensive issue for a moment -- > [...] > With the new one, we seem to have agreed that `most recent' will be > used, not `first found'. That means that every tree must be probed, > and probed with globs or sub-searches to match the various author, > version, $RELEASE, etc stuff. > [...] > I recently spent a solid month peeling 9 seconds of per-tool overhead down to > 1 second, getting a documented(!) savings of 16.25 hours *per week* in our > operations group. The prospect of losing that time again with perl6 is, er, > not acceptable. Again, this argues towards indexes. More generally, I'd just call it caching. This can be done in many ways: cached "flattened" bundle files, traditional indexes, or even simply another module that does some (or all) of this for you, when needed, by augmenting the "use" implementation with its own cached information: use Module::Cache; use Foo; # subsequent "use"s are faster now! :) use Bar; ... There may be some bootstrapping issues, but so far everything in Perl 6 seems up for "user replacement/augmentation." Why not "use" as well? :) >>> The current perl module tree is pretty difficult for the average day to >>> day scripter to comprehend. I'd go even further and say that it's so >>> complex as to be unmanagable. >> >> Encapsulating by module would make the structure pretty easy to understand, >> IMO. > > Yes, that would help with the understanding. It would not help with > the search time overhead. But that's fixable. It's much harder to make an inherently confusing (but "fast") on-disk organization "more understandable", IMO :) -John
regex and xml/html/*ml
hmm. Just read (skimmed) apocalypse 5, had one concern - it looks like we are on a serious collision course with parsing the various *mls. before: m#..etc# after m#\\\# Also, the space being backslashed sort of bugs me. Surely there is going to be a 'non-x' modifier? And perhaps a modifier to change the character for logical tags from <> to something else (like <<>>, perhaps?) Ed
Re: 6PAN (was: Half measures all round)
At 2:59 PM -0400 6/5/02, Steve Simmons wrote: >My seat of the pants number say our current tools (which use DBI to >access databases) spend about as 10% of their CPU and wall clock time >in compilation. This is measured by deliberately running the tools >with an error (bad switch) vs running it correctly and comparing >the times. Go to a module/version/release seach pattern and a >ten-fold minimum increase in serach time . . . and you double the tool >run times. That's intolerable in our environment. I recently spent >a solid month peeling 9 seconds of per-tool overhead down to 1 second, >getting a documented(!) savings of 16.25 hours *per week* in our >operations group. The prospect of losing that time again with perl6 >is, er, not acceptable. Again, this argues towards indexes. Nah. It argues for precompilation and a faster engine, both of which you'll get. :) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: 6PAN (was: Half measures all round)
At 12:55 AM -0400 6/5/02, Josh Wilmes wrote: >Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See >also debian's apt-get. > >Which brings me to my pet peeve- I think it's time to start doing binary >packaging in CPAN, for those who don't want to bother with compilation. > >That has interesting implications for how we deal with paths, but still, I >think it's worthwhile. The biggest issues with binaries are relocatability (which is a problem on some OSes), build options, compiler compatibility, and size. Size is the biggest obvious problem--there are a lot of modules with C code, and object code is generally larger than the C it came from, often by an order of magnitude or two. Multiply that by the potential number of OS/compiler/perl build options and you get a number that's rather large. The rest are just complicated icing on the cake. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even Perl class: stemsystems.com/class teddy bears get drunk
RE: regex and xml/html/*ml
[EMAIL PROTECTED]:
# Just read (skimmed) apocalypse 5, had one concern - it looks
# like we are on a serious collision course with parsing the
# various *mls.
#
# before:
#
# m#..etc#
#
# after
#
# m#\\\#
That's intentional. What will that regex do with this?
That's interpreted the same way, but typed a bit differently. It won't
match your regex.
The moral of the story is that you should not try to parse the *MLs with
regexen--use modules instead.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: regex and xml/html/*ml
--
On Wed, 5 Jun 2002 13:21:39
Brent Dax wrote:
>[EMAIL PROTECTED]:
># Just read (skimmed) apocalypse 5, had one concern - it looks
># like we are on a serious collision course with parsing the
># various *mls.
>#
># before:
>#
># m#..etc#
>#
># after
>#
># m#\\\#
>
>That's intentional. What will that regex do with this?
>
>
>
>That's interpreted the same way, but typed a bit differently. It won't
>match your regex.
>
>The moral of the story is that you should not try to parse the *MLs with
>regexen--use modules instead.
>
>--Brent Dax <[EMAIL PROTECTED]>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Early in the series, Patrick Stewart came up to us and asked how warp
>drive worked. We explained some of the hypothetical principles . . .
>"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
>--Star Trek: The Next Generation Technical Manual
>
>
Is your boss reading your email? Probably
Keep your messages private by using Lycos Mail.
Sign up today at http://mail.lycos.com
Re: regex and xml/html/*ml
On Wed, 5 Jun 2002 [EMAIL PROTECTED] wrote: > Just read (skimmed) apocalypse 5, had one concern - it looks like we are on a > serious collision course with parsing the various *mls. > > before: > > m#..etc# > > after > > m#\\\# > > Also, the space being backslashed sort of bugs me. Surely there is going to be > a 'non-x' modifier? And perhaps a modifier to change the character for logical > tags from <> to something else (like <<>>, perhaps?) Hey, if that makes people more reluctant to use regexes to parse HTML or XML and leads them to use real parsers then this could be construed as a feature ;--) Michel Rodriguez Perl & XML http://www.xmltwig.com
Re: 6PAN (was: Half measures all round)
On Wed, Jun 05, 2002 at 12:55:36AM -0400, Josh Wilmes wrote: > > Good stuff. Sounds halfway between CPAN.pm and activestate's ppm. See > also debian's apt-get. > > Which brings me to my pet peeve- I think it's time to start doing binary > packaging in CPAN, for those who don't want to bother with compilation. > > That has interesting implications for how we deal with paths, but still, I > think it's worthwhile. > > Of course you would want to support source as well, but having binary > available for those who want it just seems like a darn good idea. OK. Say I want binaries for my 3 boxes: On Bagpuss /usr/local/bin/perl -v says: This is perl, v5.8.0 built for armv4l-linux (with 1 registered patch, see perl -V for more detail) but you had better actually build that with -v3 flags on your ARM compiler because my machine's hardware can't cope with the v4 instructions on the CPU On Thinking-Cap /usr/local/bin/perl -v says: This is perl, version 5.004_05 built for i386-freebsd Copyright 1987-1998, Larry Wall 5.004 is officially still supported, and some modules do build on 5.004 [Third box, Marvellous-Mechanical-Mouse-Organ is an SGI Indy and doesn't doesn't want to power up for some reason, probably because it's been off for about 12 months] I presume you're going to suggest that they are too obscure for binary CPAN to support them. So limit things to the most recent perl. But having experimented with trying to ship 5.8.0-RC1 between FreeBSD versions, there are sufficient changes between libc on 4.4 STABLE and 4.5 STABLE such that you can't run a binary compiled on 4.5 on a 4.4 box due to missing symbols. So you're starting to enter version compatibility nightmare. And if you have module needing a C++ compiler, are you going to ship your x86 linux binaries using RedHat's 2.96, or a real gcc? And are you doing dependencies, or are you interfacing with the OS package manager? And if you're not interfacing, but you are adding modules to the OS perl, then what do you do if one of your dependency modules is already there? Do you just go "oh good", have binary CPAN say nothing, and then hope that the OS packaging system doesn't remove the dependency module from under you? I believe that binary CPAN would have problems that scale as the number of OS subversions that binary CPAN would try to support. This may sound rather negative, but it basically means that I'm feeling sufficiently pessimistic that I don't think there are reasonable solutions to the problems. However, that's only my opinion, and others' will differ. On the other hand, I think the idea of multiple platforms automatic CPAN testing is a very good idea. Nicholas Clark -- Even better than the real thing:http://nms-cgi.sourceforge.net/
A5: hypotheticals outside regexen
Page 13 tells use about C decls. But it also says that the topic must
be a regex. Whilst it explains that this isn't really a problem, I'm not
sure that it justifies it. So perhaps someone can clarify why this
(hypothetical) code in not a reasonable generalization:
our $foo = 0;
sub do_something
{
let $foo = $foo + 1;
# stuff ...
commit();
}
sub commit
{
fail if rand < 0.3;
}
for 1..10
{
do_something()
CATCH { default {} }
}
print "$foo\n"; # expect a value of around 7
Dave.
Re: A5: hypotheticals outside regexen
You have I how often that would have been useful. It's a great
exception safety mechanism... like C++'s "resource aquisition is
initialization" thingy, but without having to write a class for every
variable.
On Wed, 5 Jun 2002, David Whipp wrote:
> Page 13 tells use about C decls. But it also says that the topic must
> be a regex. Whilst it explains that this isn't really a problem, I'm not
> sure that it justifies it. So perhaps someone can clarify why this
> (hypothetical) code in not a reasonable generalization:
>
>
> our $foo = 0;
>
> sub do_something
> {
> let $foo = $foo + 1;
> # stuff ...
> commit();
> }
>
> sub commit
> {
> fail if rand < 0.3;
> }
>
> for 1..10
> {
> do_something()
> CATCH { default {} }
> }
>
> print "$foo\n"; # expect a value of around 7
>
>
>
> Dave.
>
[Patch] fix check_source errors
A few coding style errors have crept in lately. The attached patch should
fix the majority of them. I didn't touch the MANIFEST errors mentioned,
though.
--Josh
$ make check_source | grep ERROR | grep -v '^languages/'
byteorder.c:35 (ERROR) Improper indenting for "# if INTVAL_SIZE == 4" (should be "# if
byteorder.c:37 (ERROR) Improper indenting for "# else"
byteorder.c:46 (ERROR) Improper indenting for "# endif"
byteorder.c:55 (ERROR) Improper indenting for "# if INTVAL_SIZE == 4" (should be "# if
byteorder.c:57 (ERROR) Improper indenting for "# else"
byteorder.c:67 (ERROR) Improper indenting for "# endif"
byteorder.c:80 (ERROR) Improper indenting for "# if OPCODE_T_SIZE == 4" (should be "#
if
byteorder.c:83 (ERROR) Improper indenting for "# else"
byteorder.c:93 (ERROR) Improper indenting for "# endif"
byteorder.c:103 (ERROR) Improper indenting for "# if OPCODE_T_SIZE == 4" (should be "#
if
byteorder.c:106 (ERROR) Improper indenting for "# else"
byteorder.c:115 (ERROR) Improper indenting for "# endif"
byteorder.c:274 (ERROR) apparent non-4 space indenting (0 spaces)
hash.c:381 (ERROR) Cuddled else ("} else {") found.
packfile.c:184 (ERROR) Improper indenting for "#if TRACE_PACKFILE" (should be "# if
packfile.c:189 (ERROR) Improper indenting for "#endif"
pxs.c:11 (ERROR) apparent non-4 space indenting (2 spaces)
pxs.c:18 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:24 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:30 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:36 (ERROR) apparent non-4 space indenting (0 spaces)
pxs.c:87 (ERROR) apparent non-4 space indenting (3 spaces)
pxs.c:102 (ERROR) apparent non-4 space indenting (3 spaces)
pxs.c:0 (ERROR) Ending boilerplate is missing.
types/bignum.h:65 (ERROR) apparent non-4 space indenting (2 spaces)
jit/alpha/jit_emit.h:173 (ERROR) Cuddled else ("} else {") found.
include/parrot/has_header.h:0 (ERROR) Ending boilerplate is missing.
include/parrot/debug.h:0 (ERROR) Ending boilerplate is missing.
include/parrot/pxs.h:0 (ERROR) Ending boilerplate is missing.
config/gen/platform/darwin.c:74 (ERROR) apparent non-4 space indenting (0 spaces)
config/gen/platform/darwin.c:106 (ERROR) apparent non-4 space indenting (0 spaces)
MANIFEST:138 (ERROR) examples/benchmarks/gc_alloc_reuse.pasm: 8.3 name collision with
MANIFEST:141 (ERROR) examples/benchmarks/gc_header_reuse.pasm: 8.3 name collision with
MANIFEST:143 (ERROR) examples/benchmarks/gc_waves_sizeable_data.pasm: 8.3 name
collision with
MANIFEST:144 (ERROR) examples/benchmarks/gc_waves_sizeable_headers.pasm: 8.3 name
collision with
- patch -
Index: byteorder.c
===
RCS file: /cvs/public/parrot/byteorder.c,v
retrieving revision 1.10
diff -u -r1.10 byteorder.c
--- byteorder.c 20 May 2002 01:28:32 - 1.10
+++ byteorder.c 6 Jun 2002 04:00:18 -
@@ -32,9 +32,9 @@
return w;
#else
INTVAL r;
-# if INTVAL_SIZE == 4
+# if INTVAL_SIZE == 4
return (w << 24) | ((w & 0xff00) << 8) | ((w & 0xff) >> 8) | (w>>24);
-# else
+# else
r = w << 56;
r |= (w & 0xff00) << 40;
r |= (w & 0xff) << 24;
@@ -43,7 +43,7 @@
r |= (w & 0xff00) >> 24;
r |= (w & 0xff00) >> 56;
return r;
-# endif
+# endif
#endif
}
@@ -52,9 +52,9 @@
#if PARROT_BIGENDIAN
return w;
#else
-# if INTVAL_SIZE == 4
+# if INTVAL_SIZE == 4
return (w << 24) | ((w & 0xff00) << 8) | ((w & 0xff) >> 8) | (w>>24);
-# else
+# else
INTVAL r;
r = w << 56;
r |= (w & 0xff00) << 40;
@@ -64,7 +64,7 @@
r |= (w & 0xff00) >> 24;
r |= (w & 0xff00) >> 56;
return r;
-# endif
+# endif
#endif
}
@@ -77,10 +77,10 @@
#if PARROT_BIGENDIAN
return w;
#else
-# if OPCODE_T_SIZE == 4
+# if OPCODE_T_SIZE == 4
return (w << 24) | ((w & 0xff00) << 8) | ((w & 0x00ff) >> 8) |
((w & 0xff00) >>24);
-# else
+# else
opcode_t r;
r = w << 56;
r |= (w & 0xff00) << 40;
@@ -90,7 +90,7 @@
r |= (w & 0xff00) >> 24;
r |= (w & 0xff00) >> 56;
return r;
-# endif
+# endif
#endif
}
@@ -100,10 +100,10 @@
return w;
#else
opcode_t r;
-# if OPCODE_T_SIZE == 4
+# if OPCODE_T_SIZE == 4
return (w << 24) | ((w & 0xff00) << 8) | ((w & 0x00ff) >> 8) |
((w & 0xff00) >>24);
-# else
+# else
r = w << 56;
r |= (w & 0xff00) << 40;
r |= (w & 0xff) << 24;
@@ -112,7 +112,7 @@
r |= (w & 0xff00) >> 24;
r |= (w & 0xff00) >> 56;
return r;
-# endif
+# endif
#endif
}
@@ -271,7 +271,7 @@
INTVAL
endianize_fetch_int(char * s, char * o) {
-
+
}
void endianize_put_int(const char * s, char * o) {
Index: hash.c
===
RCS file: /cvs/public/parrot/hash.c,v
retrieving revision 1.5
diff -u
A5: a few simple questions
First, a slight clarification: if I say: m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] / does this give me a hash of arrays? (i.e. is the rhs of a hash processed as a scalar context) When I look at this, I see a common pattern: the join/split concept. It feels like there should be a standard assertion: m:w/ %foo := [ (\w+) = ] / .. Another useful assertion might the the long form of repeat count: m:w/ @list := (\w+) ] / to match an even number of words. And a question about (I think something similar came up a few weeks ago): why isn't it , i.e. a list of the numbers of matches allowed. This seems to be the only place in perl6 where a list of numbers, as a range, isn't constructed using the .. operator. Dave. -- Dave Whipp, Senior Verification Engineer, Fast-Chip inc., 950 Kifer Rd, Sunnyvale, CA. 94086 tel: 408 523 8071; http://www.fast-chip.com Opinions my own; statements of fact may be in error.
A5: making a production out of REs
I'd like to be able to use REs to generate lists of strings. For
example, it might be nice to create a loop such as:
for $i (sort(p:p5|[0-9A-F]{2}|)) { # "p" operator for "production"?
and have $i walk from '00' through 'FF'. Or whatever.
I created a specialized macro-preprocessor several years ago, in order
to mechanize the production of families of related class definitions
for C++ (Feh!). It was amazingly powerful, even in the primitive form
I implemented. I wonder whether the A5 REs could be coerced to serve
in a more powerful and integrated manner in Perl6.
-r
--
email: [EMAIL PROTECTED]; phone: +1 650-873-7841
http://www.cfcl.com/rdm- my home page, resume, etc.
http://www.cfcl.com/Meta - The FreeBSD Browser, Meta Project, etc.
http://www.ptf.com/dossier - Prime Time Freeware's DOSSIER series
http://www.ptf.com/tdc - Prime Time Freeware's Darwin Collection
Re: Auto-capturing
Luke Palmer wrote: > I just read through A5 (wow, that's long), and I agree with most of it. > Some of it's really cool. Here's what makes me uneasy: The fact that a > grammar rule auto-captures into a variable of its name. > > Is this efficient? If I'm writing a syntax-directed translator, I usually > don't need to capture the rules. The rules are run for their side-effects. > I definitely see the win, but I see a lose in it too. Seems like an awful > lot of memory's going to be wasted if I'm matching a big file with one > C<$grammar.match>. > > Is there a way to tell it I to capture something from a grammar rule? > Should auto-capture really be default? Is someone going to tell me "well, > it's really not inefficient because ... optimizes " That would > relieve me greatly. There will be plenty of scope for optimization where perl can detect that the values returned named subregexes are never referred to. The easiest way to turn such optimizations on is to match in a boolean, string, or numeric context. > I am waiting eagerly for Exegesis 5 :) Me too. ;-) Damian
Re: A5: hypotheticals outside regexen
> Page 13 tells use about C decls. But it also says that the topic must > be a regex. Whilst it explains that this isn't really a problem, I'm not > sure that it justifies it. So perhaps someone can clarify why this > (hypothetical) code in not a reasonable generalization: Because Perl code doesn't backtrack (except within regexes). Exceptions and backtracking are quite different. If you want hypothetical *code*, put it in a regex. Damian
Re: A5: hypotheticals outside regexen
You have I how often that would have been useful. It's a great
> exception safety mechanism... like C++'s "resource aquisition is
> initialization" thingy, but without having to write a class for every
> variable.
Have you already forgotten KEEP and UNDO (that we introduced in A4/E4):
our $foo = 0;
sub do_something
{
KEEP { $foo = $foo + 1 }
commit();
}
sub commit
{
fail if rand < 0.3;
}
for 1..10
{
try { do_something() }
}
print "$foo\n"; # expect a value of around 7
;-)
Damian
Re: A5: a few simple questions
David Whipp wrote:
>
> First, a slight clarification: if I say:
>
> m:w/ %foo := [ (\w+) = (\w+) [ , (\w+) ]* ] /
>
> does this give me a hash of arrays? (i.e. is the rhs of a hash processed as
> a scalar context)
That's an error. The grouping bound to a hypothetical hash has to have
either exactly one or exactly two captures in it. To get what you want
you'd need something like:
rule wordlist { (\w+) [ , (\w+) ]* }
m:w/ %foo := [ (\w+) = () ] /
or just:
m:w/ %foo := [ (\w+) = ({ /(\w+) [ , (\w+) ]*/ }) ] /
> When I look at this, I see a common pattern: the join/split concept. It
> feels like there should be a standard assertion:
These are good ideas for assertions. If they don't become standard, it will
certainly be possible to write a module that makes them available.
> And a question about (I think something similar came up a few weeks
> ago): why isn't it , i.e. a list of the numbers of matches allowed.
> This seems to be the only place in perl6 where a list of numbers, as a
> range, isn't constructed using the .. operator.
Because a isn't a list of numbers. It's the lower and upper bounds on a
repetition count.
Damian
Re: A5: making a production out of REs
Rich Morin wrote:
> I'd like to be able to use REs to generate lists of strings. For
> example, it might be nice to create a loop such as:
>
>for $i (sort(p:p5|[0-9A-F]{2}|)) { # "p" operator for "production"?
>
> and have $i walk from '00' through 'FF'. Or whatever.
You mean:
$ch = any(0..9,'A'..'F');
for sort egs $ch _ $ch => $i {
...
}
where C is the (hypothetical) eigenstate operator on
(hypothetical) superpositions?
Even if Larry decides against superpositions, there will definitely be some
kind of non-quantum iterator syntax that supports these kinds of permuted
sequences.
Damian
cvs.perl.org moved
Robert Spier and I moved cvs.perl.org to a new server tonight. Everything should work as usual, except maybe a bit faster. If anything is odd, not working as it used to, working better, not working at all, please send us mail at cvs at perl.org. The new server is faster, spiffier and better connected (the old one was behind a double T1 in an office; the new one is in a datacenter with 100Mbit ethernet to internap). It's donated by the kind people at Ticketmaster/CitySearch. - ask ps. we couldn't make parrot work for our perl programs yet, but we are using perl5.8 in production. :-D pps. we also decided to run some python on the server, so you can also access the cvs at http://cvs.perl.org/viewcvs/parrot/ Let us know what you think and if that should be permanent (viewcvs; not python. We will keep using that when it makes sense) :) -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
