Re: Generators -- Icon, Python, YAML and YATL
On Mon, 31 Dec 2001, Clark C . Evans wrote: > Hello. I was wondering if Parrot is going to support > Generators. A generator is a function that returns > multiple times, and I believe, was first made available > in the language ICON. Now, ICON may have taken it a > bit too far (everything is a generator), however, > Python's newest version supports generators. The generator PEP which contains a more complete discussion: http://python.sourceforge.net/peps/pep-0255.html After reading that I'm only left wondering how this concept connects with continuations. Something tells me that if we implement continuations then coroutines and generators will fall out nearly for free. On the other hand, if we don't do continuations then I think this will be quite hard. Simply put, either we figure out how to package up program state into a nice package or we don't. Um, I think. -sam
Re: [PATCH] The Code Police [1/
On Sat, 29 Dec 2001, Boris Tschirschwitz wrote: > I suggest > opcode_t* code_start So what does this declare: opcode_t* code_start, code_end; If you said two pointers to opcode_t then you just got fooled by your notation! If you want to move the '*' then it has to go to the RHS since that's where it is in the grammar. -sam
Re: [Patch] - for memory.c
On Sun, 9 Dec 2001, David Jacobs wrote: > +for (i = 1; size > i; i <<= 1); Infinite loop if size == MAXINT, eh? "So don't do that." Ok. -sam
Re: Thoughts on vtables...
On Sun, 2 Dec 2001, Michael L Maraist wrote:
> On Sunday 02 December 2001 02:47 pm, Brent Dax wrote:
> > Quick comment: I've been thinking about constructing an 'OpaqueHandle'
> > PMC type. All the programmer is supposed to know about it is that it
> > points to Something (usually a C struct, but they don't have to know
> > that). I'm not sure what trying to access it results in--perhaps it'll
> > look like a reference from the outside ("ParrotInterp=HANDLE(0xDECAF)"),
> > or maybe it'll throw a tantrum.
>
> Perl5 just used a string as the generic c-struct handle as far as I know..
Actually, most XS I've seen uses an SvIV and just stores a pointer using
PTR2INT. Then when you need to access pointer you just do an INT2PTR and
get it back out. Since Perl5's IV is garaunteed to be large enough for a
pointer this all works fine.
-sam
RE: [PATCH] Don't count on snprintf
On Sat, 1 Dec 2001, Dan Sugalski wrote: > At 01:20 PM 12/1/2001 -0500, Jeff G wrote: > >I'll probably pull out perl5's snprintf function and > >add it to the vtables. > > Unfortunately I'll say the dreaded "L" word here... > > Licensing. Wow, are we still running this project without a license? That's insane. What do we need to do to remedy this situation? Whatever it is we should do it now. -sam
Re: Yet another switch/goto implementation
On Thu, 8 Nov 2001, Dan Sugalski wrote: > Yes, it is a bug. There's an array in list context--it's supposed to be > flattened before the foreach loop gets evaluated. (And if there are > multiple arrays in the list it works as you'd expect) Sorry, I quoted the wrong section. It really isn't a bug - the next paragraph in perlsyn explains: If any part of LIST is an array, "foreach" will get very confused if you add or remove elements within the loop body, for example with "splice". So don't do that. -sam
RE: Yet another switch/goto implementation
On Thu, 8 Nov 2001, Brent Dax wrote:
> That doesn't support your argument. The point is that in the statement:
>
> foreach(@array) {
> ...
> }
>
> @array should only be evaluated once, at the beginning of the loop. In
> effect (using := here, but otherwise Perl 5 code):
Oops, you're right - I pulled the wrong section from perlsyn. I think
this is the correct paragraph:
If any part of LIST is an array, "foreach" will get very
confused if you add or remove elements within the loop
body, for example with "splice". So don't do that.
;)
-sam
Re: Yet another switch/goto implementation
On Thu, 8 Nov 2001, Dan Sugalski wrote: > Gack. Looks like a mis-placed optimization in perl 5. The list of a foreach > is *supposed* to flatten at loop start and be static. Apparently not. :) > > Care to file the perl 5 bug report, or shall I? It's not a bug. Check out the "Foreach Loops" section in perlsyn, where you'll find: If any element of LIST is an lvalue, you can modify it by modifying VAR inside the loop. Conversely, if any element of LIST is NOT an lvalue, any attempt to modify that element will fail. In other words, the "foreach" loop index variable is an implicit alias for each item in the list that you're looping over. -sam
Re: Vtables fixed, scalar started
On Sun, 28 Oct 2001, Simon Cozens wrote: > You are all encouraged to write implementations of the vtable functions > in scalarclass.c Cool. So, what needs to get done first? By that I mean, what is standing in the way of our creating tests for scalar PMCs? Maybe I'm anal retentive, but I don't know if I'm ready to start writing methods I can't test! -sam
Re: Parameter passing conventions
On Fri, 26 Oct 2001, Dan Sugalski wrote: > Okay, here are the conventions. Great. Anyone want to offer up some examples or should I just wait for Jako support to see this in action? -sam
RE: Ooops, sorry for that blank log message.
On Fri, 26 Oct 2001, Brent Dax wrote: > What if I want my compiler to be lazy? Do you have the right to punish > me for my laziness by making me add constant folding to my optimizer (or > perhaps making me *write* an optimizer just to do constant folding)? Actually, a really lazy compiler will never use constants with anything other than "set"! See the scheme compiler posted here last week for a good example. -sam
Re: String rationale
On Thu, 25 Oct 2001, Dan Sugalski wrote: > The only bits of the interpreter that much care about the > string data are the regex engine parts, and those only operate on > fixed-sized data. Care to elaborate? I thought the mandate from Larry was to have regexes compile down to a stream of string ops. Doesn't that mean it should work regardless of the encoding of the string? > The interpreter can only peek inside a string if that string is of > fixed length, and the interpreter doesn't actually care about the > character set the data is in. Why is this necessary at all? Wouldn't it be prefereable to have all access go through the String vtable regardless of the encoding? > =item encoding > > Pointer to the library that handles the string encoding. Encoding is > basically how the stream of bytes pointed to by C can be > turned into a stream of 32-bit codepoints. Examples include UTF-8, Big > 5, or Shift JIS. Unicode, Ascii, or EBCDIC are B encodings.first .first? Aside from the above, this was a nice refresher. -sam
Re: [PATCH] Re-fixes comparisions in Parrot Scheme compiler
On Tue, 23 Oct 2001, Dan Sugalski wrote: > At 12:05 PM 10/23/2001 -0400, Sam Tregar wrote: > >PS: CVS! CVS! CVS CVS CVS! > > Someone send me the files needed for Scheme and I'll check 'em in. I'll leave that to Jeff since it's his baby. You'll probably also want to give him CVS commit privs for languages/scheme. -sam
[PATCH] Re-fixes comparisions in Parrot Scheme compiler
Here's a patch to re-fix comparisions in the Scheme compiler. The
patch:
- Makes (<),(>),(<=),(>=) and (=) behave correctly on more than two
args.
- Adds tests to affirm this and fixes tests that were incorrect.
Sidenote: I don't think it's going to be possible to do static type
inference with Scheme... At least not once we have (set) and (let)
anyway! As a result, I think we need move everything into PMCs ASAP.
After that we won't need a more complicated _save() and _restore()
system since we'll only be ever be generating Px register references.
Does that make sense to you?
-sam
PS: CVS! CVS! CVS CVS CVS!
diff -ru scheme.orig/Scheme/Generator.pm scheme/Scheme/Generator.pm
--- scheme.orig/Scheme/Generator.pm Sat Oct 20 11:10:01 2001
+++ scheme/Scheme/Generator.pm Tue Oct 23 11:29:46 2001
@@ -250,8 +250,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','ne',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -266,8 +267,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','ge',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -282,8 +284,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','le',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -298,8 +301,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','gt',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -314,8 +318,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','lt',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
Only in scheme/t/arith: #logic44.pasm#
Only in scheme/t/arith: .#logic44.pasm
diff -ru scheme.orig/t/arith/logic.t scheme/t/arith/logic.t
--- scheme.orig/t/arith/logic.t Sat Oct 20 18:53:20 2001
+++ scheme/t/arith/logic.t Tue Oct 23 11:32:23 2001
@@ -1,6 +1,6 @@
#! perl -w
-use Scheme::Test tests => 49;
+use Scheme::Test tests => 51;
###
### Zero?
@@ -194,9 +194,9 @@
(write (> 2 1 0))
CODE
-#output_is(<<'CODE', 0, 'write (> 2 1 1))');
-#(write (> 2 1 1))
-#CODE
+output_is(<<'CODE', 0, 'write (> 2 1 1))');
+(write (> 2 1 1))
+CODE
###
### LEQ (<=)
@@ -218,8 +218,8 @@
(write (<= 2 1 0))
CODE
-output_is(<<'CODE', 0, 'write (<= 2 1 1))');
-(write (<= 2 1 1))
+output_is(<<'CODE', 1, 'write (<= 1 2 2))');
+(write (<= 1 2 2))
CODE
###
@@ -246,7 +246,10 @@
(write (>= 2 1 1))
CODE
-output_is(<<'CODE', 1, 'write (>= 2 1 2))');
+output_is(<<'CODE', 0, 'write (>= 2 1 2))');
(write (>= 2 1 2))
CODE
+output_is(<<'CODE', 0, 'write (>= 2 3 2))');
+(write (>= 2 3 2))
+CODE
Re: Resync your CVS...
Fresh checkout won't compile on Redhat Linux 7.1: string.c: In function `string_compare': string.c:161: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:161: too few arguments to function string.c:164: warning: passing arg 1 of pointer to function from incompatible pointer type string.c:164: too few arguments to function make: *** [string.o] Error 1 -sam
Re: Why is "make test" so slow?
On 20 Oct 2001, Gregor N. Purdy wrote: > I want to libify everything to the point where Perl wrappers around > the libs allow you to pass the .pasm stuff as a string and get back > a packfile that you can pass on to the interpreter, without firing > off separate processes and writing files. Sounds like a good idea. It'll be necessary to have something like this to support string eval() anyway, right? -sam
[PATCH] Fixes logical ops in Parrot Scheme compiler
Here's a patch to fix logical ops in the Parrot Scheme compiler. The
patch:
- Implements (min) and (max) which had stubs and some =pod'd out code
which I couldn't understand.
- Fixes (=), (<), (>), (<=) and (>=) to work with more than 2 operands.
Added tests where they were missing and fixed tests that were
incorrectly passing.
After this patch "make test" has no failures on my box. Question:
- Why does Scheme::Generator::_save(2) return an array of three
elements? I tried to "fix" _save() and that just broke things...
I must be missing something!
-sam
PS: Can we get this into languages/scheme?
diff -ru scheme.orig/Scheme/Generator.pm scheme/Scheme/Generator.pm
--- scheme.orig/Scheme/Generator.pm Thu Oct 18 15:44:43 2001
+++ scheme/Scheme/Generator.pm Sat Oct 20 17:36:19 2001
@@ -244,8 +244,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','ne',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -260,8 +261,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','ge',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -276,8 +278,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','le',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -292,8 +295,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','gt',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -308,8 +312,9 @@
$self->_add_inst('','set',["I$return",0]);
$self->_generate($node->{children}[0],$temp[0]);
for(1..$#{$node->{children}}) {
-$self->_generate($node->{children}[1],$temp[1]);
+$self->_generate($node->{children}[$_],$temp[1]);
$self->_add_inst('','lt',["I$temp[0]","I$temp[1]","DONE_$label"]);
+($temp[0], $temp[1]) = ($temp[1], $temp[0]);
}
$self->_add_inst('','set',["I$return",1]);
$self->_add_inst("DONE_$label");
@@ -385,59 +390,32 @@
sub _op_max {
my ($self,$node,$return) = @_;
- my $label = $self->_gensym();
-
- my @temp = _save(1);
- $self->_generate($node->{children}[0],$return);
-
- _restore(@temp);
+ my ($targ) = _save(1);
-=pod
-
- $self->__build_children($node);
-
- $self->_add_inst('','set',[$return,$registers[0]]);
-
- $self->_add_inst('', 'lt', [$registers[0],$return,$label]);
- $self->_add_inst('', 'set',[$return,$registers[0]]);
- for(1..$#registers) {
-my $tmp_label = "NEXT_".$self->_gensym();
-$self->_add_inst($label,'lt' ,[$registers[$_],$return,$tmp_label]);
-$self->_add_inst('','set',[$return,$registers[$_]]);
-$label = $tmp_label;
+ $self->_generate($node->{children}[0], $return);
+ for (1 .. $#{$node->{children}}) {
+my $label = $self->_gensym();
+$self->_generate($node->{children}[$_], $targ);
+$self->_add_inst('','le',["I$targ","I$return","SKIP_$label"]);
+$self->_add_inst('','set',["I$return","I$targ"]);
+$self->_add_inst("SKIP_$label");
}
- $self->_add_inst($label);
-
-=cut
-
+ _restore($targ);
}
sub _op_min {
+ my ($self,$node,$return) = @_;
+ my ($targ) = _save(1);
-=pod
-
- my $self = shift;
- my $node = shift;
- my $return = "I$node->{register}";
-
- $self->__build_children($node);
- my @registers = map { "I$_->{register}" } @{$node->{children}};
-
- $self->_add_inst('','set',[$return,$registers[0]]);
-
- my $label = "NEXT_".$self->_gensym();
- $self->_add_inst('', 'gt', [$registers[0],$return,$label]);
- $self->_add_inst('', 'set',[$ret
Why is "make test" so slow?
Why is "make test" so durn slow? Our tools run individually seem pretty snappy on my low-end box (P200/64MB) but running "make test" is like watching paint dry. I'm seeing something like 1 test per second! Please feel free to point me to TFM if this question is answered there. -sam
Re: A new language targeted to the parrot assembler...
On Fri, 19 Oct 2001, Jeff wrote: > For a -very- primitive Scheme -> Parrot compiler, see > > http://216.254.0.2/~jgoff/Files/scheme.tar.gz Woo hoo! > Test files (using the provided version of Test::More) are in the t/ > directory, and can be run by typing 'make test' at the command line. The > test suite currently covers all of the currently-working expressions. > Simple variables will hopefully be added over the weekend alongside data > type tracing. I'm getting some test failures. I've attached the full report below. I'm running this on Redhat Linux 7.1 with a fresh parrot CVS checkout. t/harness t/io/basic..ok t/arith/basic...ok t/arith/logic...ok 16/43# Failed test (Scheme/Test.pm at line 76) # got: '1' # expected: '3' t/arith/logic...ok 19/43# Failed test (Scheme/Test.pm at line 76) # got: '1' # expected: '9' t/arith/logic...NOK 20# Failed test (Scheme/Test.pm at line 76) # got: '0' # expected: '1' t/arith/logic...NOK 21# Failed test (Scheme/Test.pm at line 76) # got: '0' # expected: '3' t/arith/logic...NOK 22# Failed test (Scheme/Test.pm at line 76) # got: '0' # expected: '1' t/arith/logic...NOK 23# Failed test (Scheme/Test.pm at line 76) # got: '0' # expected: '1' t/arith/logic...ok 37/43# Failed test (Scheme/Test.pm at line 76) # got: '1' # expected: '0' t/arith/logic...ok 42/43# Looks like you failed 7 tests of 43. t/arith/logic...dubious Test returned status 7 (wstat 1792, 0x700) DIED. FAILED tests 17, 20-24, 38 Failed 7/43 tests, 83.72% okay t/logic/basic...ok Failed Test Status Wstat Total Fail Failed List of Failed t/arith/logic.t 7 1792437 16.28% 17, 20-24, 38 Failed 1/4 test scripts, 75.00% okay. 7/75 subtests failed, 90.67% okay. make: *** [test] Error 29 -sam
Re: Fetching the PC?
On Thu, 11 Oct 2001, Dan Sugalski wrote: > Did we put a patch into parrot that lets you fetch the current PC and store > it in an integer register? I seem to recall someone did, but I can't find it. That's the '@' thing I was talking about making a doc patch for. I then realized that I didn't understand it well enough to explain it! The little I grok is that a '@' in the assembly gets replaced by the value of $op_pc. Jako does stuff like: set I31, [ printit - @ - 3 ] For function calls. As I thought about documenting '@' I realized I had no idea what those braces are for... Seems to me whoever put in this hack should be the one to document it. -sam
Re: [PROPOSED] Crystalizing loader
On Sat, 6 Oct 2001, Gregor N. Purdy wrote: > After the bytecode is loaded, but before it is executed, put it through > a stage of processing that requires about as much information as a > disassembler would (which is why my op_info stuff from one of my previous > patches is required). > > This process converts opcodes into pointers to the op functions, and > arguments to pointers to the constant values or register entries. This > means that we amortize the dereferences over all invocations of the > op at each PC, which when tight loops are involved should make for > noticable savings. It seems that this would interfere with trying to share the bytecode using mmap(). We might gain a small performance increase but lose a significant advantage in memory reduction in large systems. Of course, if it's configurable then people can make that trade-off for themselves. -sam
@ undocumented?
Am I correct that '@' in the assembly syntax is undocumented? The only place I could find it was in source comments in Parrot::Assembler. I had to search for @ to find it. Believe me, the last thing you want to search for in a Perl module is @. I think a patch to docs/parrot_assembly.pod would be appropriate. Sound good? -sam
Re: SV: Parrot multithreading?
On Sun, 30 Sep 2001, Nick Ing-Simmons wrote: > The main problem with perl5 and threads is that threads are an afterthought. Which, of course, also goes for "UNIX and threads" and "C and threads". It's good for us to be thinking about as early as possible but it's no garauntee that there won't be big problems anyway. Extensions in C come to mind... Has anything come down from the mountain about the future of XS in Perl 6? Speaking of which, what's taking Moses so long? -sam
Re: instructions per second benchmark (in parrot ;)
On Thu, 20 Sep 2001, Dan Sugalski wrote:
> FWIW, my 600MHz Alpha clocks in at around 23M ops/sec. Nyah! ;-P
My PIII 700Mhz gets 23M. Well, ok, to get above 21M I had to make a
slight alteration (below). Damn Alphas and their "superior technology".
-sam
RCS file: /home/perlcvs/parrot/interpreter.c,v
retrieving revision 1.18
diff -u -r1.18 interpreter.c
--- interpreter.c 2001/09/19 20:05:06 1.18
+++ interpreter.c 2001/09/20 23:36:24
@@ -50,11 +50,8 @@
time through */
opcode_t *(*func)();
void **temp;
-opcode_t *code_start;
-code_start = code;
-
-while (code >= code_start && code < (code_start + code_size) &&
*code) {
+while (*code) {
DO_OP(code, temp, func, interpreter);
}
Re: Bytecode safety
On Tue, 18 Sep 2001, Damien Neil wrote: > Proposed: Parrot should never crash due to malformed bytecode. When > choosing between execution speed and bytecode safety, safety should > always win. I don't see this as a safety issue. There's nothing unsafe about crashing. It's just not as pretty as putting up a big ol' "YOUR BYTECODE IS SNOOKERED" message. Having that message is not worth even a 1% degradation in runtime speed. > Careful op design and possibly a validation pass before > execution will hopefully keep the speed penalty to a minimum. Sounds great, but make it a separate program that gets run optionally with the default being to not run it. Validating variable-length instructions takes non-trival time and having it outside the normal execution path will allow to indulge in whatever costly-code analysis you desire. -sam
Re: parrot compilation failure in Tru64
On Sat, 15 Sep 2001, Philip Kendall wrote: > My personal view would be that the gains due to portable bytecode would > be outweighed by the amount of cruft we'd have to put into the > interpreter to get them. As Nicholas Clark and someone else who's name > I've forgotten[1] mentioned, there are platforms (eg Cray) which don't > have a native 32-bit integer type. No cruft need go into the interpreter. We can preprocess any given bytecode format into a native format. These preprocessors can be entirely separate from the interpreter. The gains here are pretty important - with a portable bytecode modules can be distributed pre-compiled, bytecode can be generated on one platform and used on another (think embedding) and all manner of network computing silliness becomes possible. Yes, some platforms will need some costly pre-processing in order to use other platforms' bytecode. However, the 95% case of just needing some byte-swapping will work with almost no penalty at all. The remaining 5% that need to resize the data will still work, albeit with a startup penalty. Easy things easy, hard things possible, right? -sam
Re: Parrot 0.0.1 is released.
> Patches should be sent to the perl6-internals mailing list, where I'll take a
> look at them and apply them to the CVS tree.
Ooo, ooo - me first. Since you turned on -Wall in the Makefile I thought
it would be nice if it compiled without warnings. Below is a patch that
does that on my system.
This is the output from "cvs -q diff -u". Is this is the best way to send
a multi-file patch from the CVS checkout?
-sam
Index: basic_opcodes.ops
===
RCS file: /home/perlcvs/parrot/basic_opcodes.ops,v
retrieving revision 1.4
diff -u -r1.4 basic_opcodes.ops
--- basic_opcodes.ops 2001/09/10 15:48:36 1.4
+++ basic_opcodes.ops 2001/09/10 21:28:39
@@ -60,7 +60,7 @@
// PRINT Ix
AUTO_OP print_i {
- printf("I reg %i is %i\n", P1, INT_REG(P1));
+ printf("I reg %li is %li\n", P1, INT_REG(P1));
}
// BRANCH CONSTANT
@@ -152,7 +152,7 @@
// PRINT Nx
AUTO_OP print_n {
- printf("N reg %i is %Lf\n", P1, NUM_REG(P1));
+ printf("N reg %li is %Lf\n", P1, NUM_REG(P1));
}
// INC Nx
@@ -257,7 +257,7 @@
// PRINT Sx
AUTO_OP print_s {
STRING *s = STR_REG(P1);
- printf("S reg %i is %.*s\n", P1, string_length(s), s->bufstart);
+ printf("S reg %li is %.*s\n", P1, (int) string_length(s), (char *) s->bufstart);
}
// LEN Ix, Sx
@@ -272,4 +272,4 @@
// NOOP
AUTO_OP noop {
-}
\ No newline at end of file
+}
Index: bytecode.c
===
RCS file: /home/perlcvs/parrot/bytecode.c,v
retrieving revision 1.3
diff -u -r1.3 bytecode.c
--- bytecode.c 2001/09/10 09:50:39 1.3
+++ bytecode.c 2001/09/10 21:28:39
@@ -93,7 +93,7 @@
}
num--;
if (len < 0 || (len > 0 && num == 0)) {
-printf("Bytecode error: string constant segment corrupted: %i, %i\n",
len, num);
+printf("Bytecode error: string constant segment corrupted: %i, %i\n",
+(int) len, (int) num);
exit(1);
}
}
Index: parrot.h
===
RCS file: /home/perlcvs/parrot/parrot.h,v
retrieving revision 1.2
diff -u -r1.2 parrot.h
--- parrot.h2001/09/07 15:23:40 1.2
+++ parrot.h2001/09/10 21:28:39
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#define NUM_REGISTERS 32
#define PARROT_MAGIC 0x13155a1
Index: register.c
===
RCS file: /home/perlcvs/parrot/register.c,v
retrieving revision 1.2
diff -u -r1.2 register.c
--- register.c 2001/09/10 15:49:27 1.2
+++ register.c 2001/09/10 21:28:39
@@ -10,10 +10,10 @@
struct IRegChunk *chunk_base;
chunk_base = CHUNK_BASE(interpreter->int_reg);
- printf("Chunk base is %x for %x\n", chunk_base, interpreter->int_reg);
+ printf("Chunk base is %x for %x\n", (unsigned int) chunk_base, (unsigned int)
+interpreter->int_reg);
/* Do we have any slots left in the current chunk? */
if (chunk_base->free) {
-printf("Free was %i\n", chunk_base->free);
+printf("Free was %i\n", (int) chunk_base->free);
interpreter->int_reg = &chunk_base->IReg[chunk_base->used++];
chunk_base->free--;
}
Index: test_main.c
===
RCS file: /home/perlcvs/parrot/test_main.c,v
retrieving revision 1.2
diff -u -r1.2 test_main.c
--- test_main.c 2001/09/10 10:05:23 1.2
+++ test_main.c 2001/09/10 21:28:40
@@ -35,19 +35,19 @@
int i;
time_t foo;
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_concat(s, t, 0);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_chopn(s, 4);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
string_chopn(s, 4);
- printf("String %p has length %i: %.*s\n", s, string_length(s),
string_length(s), s->bufstart);
+ printf("String %p has length %i: %.*s\n", s, (int) string_length(s), (int)
+string_length(s), (char *) s->bufstart);
foo = time(0);
for (i = 0; i < 1; i++) {
string_concat(s, t, 0);
string_chopn(s, 4);
}
- printf("1000 concats and chops took %i seconds.\n", time(0)-foo);
+ printf("1000 concats and chops took %li seconds.\n", time(0)-foo);
string_destroy(s);
}
/* Otherwise load in the program they gave and try that */
RE: Should MY:: be a real symbol table?
On Mon, 3 Sep 2001, Brent Dax wrote:
> Now is where the temp() stuff I was talking about earlier comes in.
>
> sub foo {
> my($bar);
> foo();
> }
>
> is basically equivalent to
>
> sub foo {
> temp($MY::bar);
> foo();
> }
Oh, you're pitching softballs to yourself. Try a hard one:
my @numbers;
for (0 .. 10) {
my $num = $_;
push(@numbers, sub { $num });
}
for (0 .. 10) {
local $num = $_;
push(@numbers, sub { $num });
}
print join(', ', map { $_->() } @numbers), "\n";
It's in Perl5, but the analogy to Perl6 should be clear enough. This is a
good example of the different natures of lexical and dynamic variables.
-sam
Re: An overview of the Parrot interpreter
On Mon, 3 Sep 2001, Dan Sugalski wrote: > I'm not entirely sure how much this'll be used, but I really, *really* want > to be able to call any sub that qualifies as an op rather than as a sub. What would a sub have to do (be?) to qualify? > >I don't understand this restriction. Won't it make implementing variadic > >functions more difficult? > > Varadic functions that take actual integers, floats, or strings, yes. > Varadic functions that take parrot variables (i.e. PMCs) no. Right, so why make the former hard? Is there an upside to the restriction? -sam
Re: An overview of the Parrot interpreter
On Mon, 3 Sep 2001, Dan Sugalski wrote: > >avoid using a "call" opcode all over the place, right? > > No, more a "try and leave the bytecode sections read-only" hack. > > Imagine, if you will, building LWP and bytecode compiling it. It uses > private opcodes 1024-1160. Then you later build, say, MIME::Lite, which > uses opcodes 1024-1090. I was referring to the practice of having compilation units create private opcodes. Am I wrong in thinking this is a new technique deserving of an excuse for existence? > Up until now, I didn't know, so consider yourself the first to find out. :) I'm honored... > * Integer, String, and Number registers 0-x are used to pass parameters > when the compiler calls routines. s/compiler/interpreter/, right? > * Subs may have variable number, or unknown number, of PMC parameters. > (Basically Parrot variables) They may *not* take a variable or unknown > number of integer, string, or number parameters. I don't understand this restriction. Won't it make implementing variadic functions more difficult? > Don't consider this list final until I've had a chance to run it past > Larry. He might be thinking of allowing prototypes to change, or spring > into existance relatively late in the game. (In which case we probably get > a call_in_list and call_in_registers form of sub call) Or those other language designers you're wooing, right? The prototype stuff sounds pretty Perl specific. -sam
Re: An overview of the Parrot interpreter
On Mon, 3 Sep 2001, Dan Sugalski wrote: > Basically chunks of perl code can define opcodes on the fly--they might be > perl subs that meet the proper critera, or opcode functions defined by C > code with magic stuck in the parser, or wacky optimizer extensions or > whatever. There won't be a single global table of these, since we can > potentially be loading in precompiled code. (Modules, say) Each > "compilation unit" has its own table of opcode number->function maps. > > If you want to think of it C-ishly, each object module would have its own > opcode table. Ok, I think I understand. This is some kind of code-compression hack to avoid using a "call" opcode all over the place, right? Speaking of soubroutines, what is Parrot's calling conventions? Obviously we're no long in PUSH/POP land... > >Or not! Are Perl strings PMCs or not? Why does Parrot want to handle > >Unicode? Shouldn't that go in a specific language's string PMC vtables? > > Strings are a step below PMCs. I feel like I almost understand this. So when you call the length() vtable method on a PMC representing a Perl scalar, the length op is eventually going to call another length() op, this time on an underlying Parrot string. Right? I'm still not sure I understand why Parrot is doing string ops at all. Do all our target languages have identical semantics for string operations? When you bring Unicode into the mix I start to wonder. -sam
Re: An overview of the Parrot interpreter
On Mon, 3 Sep 2001, Nathan Torkington wrote: > > Ok, so one example of a PMC is a Perl string... > > If you grok vtables, think of a PMC as the thing a vtable hangs off. > > Another way to think of it is that a PMC is an object. To the outside > (the interpreter that is manipulating data values) its contents are > opaque. All you can do is call methods (vtable entries) on it. > > So if you have an object/PMC that implements a string, the "length" > method/vtable-entry will return the length of the string. An > object/PMC that implements an array, the "length" method/vtable-entry > will return the number of things in the array. I think I understand this. What I don't understand is how this relates to the next section about Parrot's special relationship with strings. If Parrot has a "string" type and string handling functions, why use a PMC to implement a string? What does it mean to have a PMC that "implements a string" and also have a "string type" in Parrot? -sam
Re: An overview of the Parrot interpreter
On Sun, 2 Sep 2001, Simon Cozens wrote: > For instance, the Parrot VM will have a register architecture, rather > than a stack architecture. s/rather than/as well as/; # we've got a stack of register frames, right? > There will be global and private opcode tables; that is to say, an area > of the bytecode can define a set of custom operations that it will use. > These areas will roughly map to compilation units of the original > source; each precompiled module will have its own opcode table. Side note: this isn't making sense to me. I'm looking forward to further explanation! > If our PMC is a string and has a vtable which implements Perl-like > string operations, this will return the length of the string. If, on the > other hand, the PMC is an array, we might get back the number of > elements in the array. (If that's what we want it to do.) Ok, so one example of a PMC is a Perl string... > Parrot provides a programmer-friendly view of strings. The Parrot string > handling subsection handles all the work of memory allocation, > expansion, and so on behind the scenes. It also deals with some of the > encoding headaches that can plague Unicode-aware languages. Or not! Are Perl strings PMCs or not? Why does Parrot want to handle Unicode? Shouldn't that go in a specific language's string PMC vtables? -sam
RE: Should MY:: be a real symbol table?
On Sun, 2 Sep 2001, Brent Dax wrote: > Okay, I forgot to account for the fact that we'd have to increment the > refcount for every inner scope a my() variable is referred to in. > That's not terribly hard, is it? I have no idea what you're talking about here. You asked if it was possible to fake lexical variables with local() (spelled temp() in Perl 6, right?). It's not. Diddling the reference count won't make it any more possible! They have different semantics that just aren't compatible. -sam
RE: Should MY:: be a real symbol table?
On Sun, 2 Sep 2001, Brent Dax wrote: > but in that case the inner my($x) could be translated to > temp($MY::x)--the behavior is basically the same. (Actually, if pads > are replaced with stashes, is there any situation where my($x) can't be > translated to temp($MY::x)? Hmmm...) Closures, for one. File-scoped lexicals for another. Lexical variables are very different beasts from package variables. They are not compatible in some significant ways. Now, that said, we'll need to do something better than pads to support %MY. If that means full-blown symbol tables for every scope... Well, I'd be surprised. There's a reason lexical variables are faster than package variables and I imagine we'd like to keep it that way. -sam
Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code
On Thu, 30 Aug 2001, Simon Cozens wrote: > I could spend a lot of time justifying it to you here and now, or I > could spend the same time writing a detailed specification of the > interpreter interface. I think, to be honest, it might be more > productive for me to take the second option. I agree - go to it. What you've written so far prompts as many questions as it does provide answers, but I am reassured that a real spec is coming. -sam
Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code
On Thu, 30 Aug 2001, Simon Cozens wrote: > That's not entirely relevant any more. Parrot has a semi-autonomous > existence as a generic bytecode interpreter. We may be a long way > from having a language spec, but we're pretty damned close to having > a spec for the interpreter. I look forward to reading it! -sam
Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code
On Thu, 30 Aug 2001, Uri Guttman wrote: > we have very strong internal specs already that will support most > anything larry throws at us. stuff such as the op code loop, async > (file) i/o, events, etc, are all known to be needed so we can code them > now that the design is firming up. we have the flexibility to support > most anything with decent efficiency. Where can I read this stong spec? What I've seen so far is good, but it hasn't imparted to me enough to be sure that it'll handle anything Larry could desire. Larry is more inventive than most. What I've seen so far resembles a software CPU, which be analogy should be able to do anything from run Quake III to compile Java. Does that mean it's well-suited to compiling Perl? I don't know - I haven't seen enough of the design. > some areas such as GC need more spec work as we don't know how the > language will affect it (DESTROY, etc.). Careful - Dan smacks people that use GC and DESTROY in the same sentence. -sam
Re: Final, no really, Final draft: Conventions and Guidelines forPerl Source Code
On Wed, 29 Aug 2001, Simon Cozens wrote: > It's almost time to start coding, people, almost. Not to be an ass, but is it? It seems like we're still a long way from having a language spec. -sam
Re: Anyone here with Sourceforge experience?
On Sat, 25 Aug 2001, Nathan Torkington wrote: > I'd like to keep the code on Sourceforge from the get-go. I don't > have much experience with Sourceforge, though, and would like to talk > to someone who has. Which bits work well? Which bits aren't worth > the effort? Any tips or tricks to pass on? I've been on SourceForge for a while now. It's a great place to keep a CVS tree. The file release interface was designed by someone from another planet, but it works. The online forums are irritating - they destroy the formatting of any code posted. I've never used the mailinglists, but I'm on a couple and they seem to work. The bug tracker works well enough but it's no Bugzilla. Questions? -sam
RE: Draft assembly PDD
On Mon, 6 Aug 2001, Dan Sugalski wrote: > No, he's right. Not dirtying cache lines is pretty much always faster than > dirtying them, and not twiddling with memory's faster than twiddling. And > unfortunately we can't really do fully platform-dependent code, since it'll > be the actual bytecode that'll ned to be different. Ok, I'll go back to lurking - I definitely don't have the education to try to argue the point. I've got some half-formed idea about a stack-based opcode set that compiles down to register references at runtime, but I'm definitely a few books short of articulate on this subject. Choose wisely then - if we want this thing to run well on the Palm and on the Athlon we'll have to! > We're actually doing the appropriate amount of optimization here. When > dealing with low-level constructs it's appropriate to consider low-level > effects and algorithms that handle low-level machinery. Lo tho we walk through the valley of the shadow of the JVM... Is anyone else nervous that we seem to be trying to replace GCC here? Is register allocation really something the Perl community has expertise in? -sam
RE: Draft assembly PDD
On Mon, 6 Aug 2001, Hong Zhang wrote: > It is not just for performance, the stack size and cache > locationality are also big issues. Cache sizes and timings vary from machine to machine. Maybe we should make it configurable at compile-time? If we do that then there's no reason to try to guess at the right number now - we can test later and get an answer we can trust. [ insert routine comment about premature optimzation causing the death of the dinasours here ] -sam
Re: Modules, Versioning, and Beyond
On Mon, 30 Jul 2001, Dan Sugalski wrote: > When you actually use a module, the simple name (like IO) will be > internally expanded out to the three value thing. So if you have two > modules that each use a different version of the same module, they won't > interact because each will be dealing with a separate thing. How will this work with XS modules that load external libraries? Won't trying to load two versions of mysql.so cause symbol collision? -sam
Re: [DDJ] Fast and Small Resizable Arrays
On Fri, 8 Jun 2001, Jarkko Hietaniemi wrote: > An interesting article in the July DDJ) in the Algorithm Alley: > "Fast and Small Resizable Arrays", presents a datastructure that > promises just what the subject says. The first thing I thought of after reading the article was "use less memory"... I wonder how hard it would be to use this technique for AVs in Perl5. -sam
Re: Generating Perl 6 source with Perl
On Fri, 16 Feb 2001, Simon Cozens wrote: > On Fri, Feb 16, 2001 at 08:52:03PM +, Nicholas Clark wrote: > > macro languages and symbolic debuggers don't mix well. > > Generated output would be Real Life C. I'm thinking something along the lines > of > perl vtable.pl < vtable.spec > vtable.c > which would work just fine with symbolic debuggers. I think he meant that using a symbolic debugger is hard, not that it wouldn't work. After all, when GDB is tell you that: (*fooz).blazt[10].mark[0]->set(fungle(10)); Is causing a seg fault and all you wrote was: $fooz->set(10); You've got to get pretty smart to figure out what's going south. -sam
Re: GC: what is better, reuse or avoid cloning?
On Sat, 10 Feb 2001, Buddha M Buck wrote: > I think what he's thinking (in C terms) would be more like the following: Right. It already has a technical name - copy-on-write. I should have made it more clear that I recognized the intended mechanism. I was trying to demonstrate that Perl-level mechanisms already existed to do value aliasing. I was also trying to show that what he is suggesting is a lot like aliasing with some simple copy-on-write STORE magic. For some reason I thought that by pointing that out I could relieve him of his bizarre worries about garbage collecting things with references. I probably should have just gone to bed instead. -sam
Re: GC: what is better, reuse or avoid cloning?
On Sat, 10 Feb 2001, Branden wrote: > Suppose I have a string stored in $foo, say, "abcbca", and then I do: > > $bar = $foo; > $foo .= "xyzyzx"; > > I see two ways of doing this: one is allowing a string value to be shared by > two or more variables, and the other one not. Why would you want to share the string value? Why did you assign the value of $foo to $bar if you really wanted to: $bar = \$foo; Or actually closer to what you seem to want: *bar = \$foo; Although a little birdy told me we're dropping globs for Perl6. Don't most programmers do assignment for a reason? Why should we second-guess them? > Given mark-and-sweep or other advanced GC, which of them is better? Sharing > the value or cloning on each assignment? I don't believe implementing copy-on-write for scalars has anything to do with garbage collection. Any garbage collector that will work for Perl will need to work with references. All you're suggesting is a beneath-the-covers reference, right? What's the point? You seem to be engaging in some extreme and bizarre form of premature optimization. -sam
Re: Speaking of signals...
On Wed, 3 Jan 2001, Dan Sugalski wrote: > I think one of the things we might want to do is figure out what people use > signals for and see if we can abstract out some of that functionality > without actually exposing signals. (From an internals standpoint, at least) Well, one thing people use signals for is IPC with non-Perl processes. I think that if you're want to continue to support that then we need an interface to real, broken though they may be, POSIX signals. Maybe the code gets pushed out of the core, but it still needs to be somewhere. -sam
Re: Perl6 compatibility with non-C enviornments
On Thu, 7 Dec 2000, Bradley M. Kuhn wrote: > Now, I would agree that there are more C hackers about. However, many > people are graduating college with computer science degrees having worked > mostly in Java and very little in C. In 6 years or so, we may find that > there are more Java hackers than C hackers about. But, I agree this alone > isn't a reason to pick Java. That's an interesting theory. Want to hear another one? People that only learn Java in college and never go on to learn other languages aren't going to be developing Perl. Why? They didn't learn Perl in college either. On the other hand, the smart ones will realize pretty quickly that a huge proportion of the best software is written in C. It's not too hard to figure out that C might be a good language to learn. Bottom line: is C's lifespan finite? Certainly. Is Java the replacement? I serriously doubt it. > I already knew that "writing the canonical Perl6 implementation in Java was > likely a lost cause. ;) However, I hope we won't confuse this issue with the > one of making it possible to port Perl to non-C environments. Such > environments do exist, and they do matter, IMO. I'm a jerk, so I have to ask: do they exist? What platform are you talking about where there exists a JVM and where no C compiler can target the architecture? How did they write the JVM with no C compiler? However, point taken. The easier we can make porting Perl the better. > I don't know if that is proven. We still lack a port to the JVM, while our > "sister languages" like Python, Scheme, Tcl, Eiffel and the like all have > JVM ports. Little languages are much more portable than big ones. Ok, I don't really know if that covers Eiffel and Python but I'm pretty sure it covers Tcl and Scheme. You can write interpreters for those languages in surprisingly little code. -sam
Re: Meta-design
On Thu, 7 Dec 2000, Simon Cozens wrote: > On Thu, Dec 07, 2000 at 11:22:35AM -0500, John Porter wrote: > > [C++] > > > It's nearly as portable, > > Uhm. Is this actually true? C runs pretty much anywhere. > > Are there any non-fragile implementations of C++ yet? Which also brings up another point - choosing anything but C is likely to have a direct impact on our existing userbase. I have a suggestion - if a system compiled and ran Perl 5 then it should be able to compile and run Perl 6. No upgrades required. This is also a good arguement against Java. Many, many systems do not have a Java runtime installed and there's no excuse for putting people through the trouble of installing one just to compile Perl. Are we done yet? -sam
Re: Perl6 in Java? (was Re: Meta-design)
On Wed, 6 Dec 2000, Bradley M. Kuhn wrote: > And, it will make the barrier for entry for new internals hacker lower. Really? Do you honestly believe there are more Java programmers than C programmers? Particularily in the Perl development community! > I would note that if we write in Java, we aren't targeting a single > compiler, although at the moment, the only efficient compiler for Java might > be GCJ. It speaks volumes that the only efficient compiler is vaporware. How fast is it? Who knows - it's not finished! Does it have major flaws? Probably - but just wait and see how fast it is! Let's move on - C is our only real option. It's portable enough (proven by perl5), it's fast enough (or nothing is) and we already have in-house experts to lead the implementation. Are we serriously considering anything else? PIL? If someone here has a real proposal for a better-than-cpp macro language then let's hear it. It's worth considering in a purely abstract keep-an-open-mind sense. -sam
RE: Meta-design
On Wed, 6 Dec 2000, Dan Sugalski wrote: > Sure, but only objects. (or, to be really paranoid, things referred to) > Nothing else needs refcounting. All the refcounting code can be isolated in > the reference creation and deletion code, and we don't have to pay it > otherwise. Good point. I hadn't considered the predominance of non-objects in Perl programs. I suppose that any system that allowed us to get away without having to refcount every simple SV would be a pretty big win even if blessed SVs still had to be counted. -sam
RE: Meta-design
On Wed, 6 Dec 2000, Dan Sugalski wrote: > Non-refcounting GC schemes are more expensive when they collect, but less > expensive otherwise, and it apparently is a win for the non-refcount > schemes. Which is why GC is intimately tied to DESTROY consideration in terms of Perl. If we intend to honor predictable DESTROY timing, and I think we should, then we will need to reference count. No ifs, elses or alternations. Anyone care to refute? If we're going to be ref-counting anyway then the performance gain of a non-refcounting GC, avoiding counting, is basically moot. If we're ref-counting for DESTROY timing then we may as well use that data in the GC. I'm not some kind of ref-count true-believer - if you think we should put this discussion of to a later date then I'm cool. I'm just spoiling for some Perl 6 work to do and this area seemed ripe for critical development. -sam
RE: Meta-design
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> >my $new_dog;
> >{
> > my $dog = new Dog;
> > $new_dog = \$dog;
> >}
>
> That would hoist the Dog reference into an outer level of scope--in this
> case the one containing $new_dog. Or so my thinking goes at the moment,
> though there may be (almost inevitably are) problems with that.
"hoist"? I thought this was a stack you were talking about. You're going
to do an O(n) operation on a stack every time a reference is passed out of
scope? What happens when two references diverge:
my $newDog1;
{
my $newDog2;
{
my $dog = new Dog;
$newDog2 = $newDog1 = \$dog;
}
$newDog1 = undef;
}
How does a non-refcounting scheme know that $newDog2 is the last ref to
$dog when the first block is done?
As far as claims about mark-and-sweep improving performance, I guess we'd
need a test implementation in order to find out. Considering the
non-deterministic character of many mark-and-sweep systems performance
testing can be a delicate matter.
-sam
RE: Meta-design
On Wed, 6 Dec 2000, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can still be GC'd later to pick up their now-free memory) Most things
> won't get tossed on there, since most variables don't have any destruction
> behaviour.
If you don't reference count how do you protect yourself from DESTROYing
objects that are still referenced:
my $new_dog;
{
my $dog = new Dog;
$new_dog = \$dog;
}
Did $dog just get erroneously collected by your destruct stack? No?
Without reference counting?
Frankly these hybrid GC schemes look more like the *worst* of both worlds
than best - all the predictable performance problems of reference counting
with the unpredictable performance problems of mark and sweep!
-sam
Re: Proposal for groups
On Tue, 5 Dec 2000, Alan Burlison wrote: > How about writing the documents in XML and having a 'perl specification' > DTD? > ... > Death to POD! Can we *please* not re-fight this war? I know you remember the last couple incarnations of XML VS POD. Just replay them in your mind and enjoy the show. Spare us the angst. -sam
Re: Proposal for groups
On Sat, 2 Dec 2000, Nathan Torkington wrote: > * it's difficult for the design to happen through the questions Is that really true? Have we tried? As far as I can tell we've got a lot of well-intentioned people that for whatever reason are spending very little time making Perl 6 happen. Let me explain why I think this is a useful comment instead of just slander from the sidelines. I'm somone who's reasonably knowledgeable about compiler technology and about Perl internals. Still, I'm not so expert that I feel comfortable leading the design of the Perl 6 internals. I'd hoped to be involved as a skilled helper - able to develop and debug proposed systems. The problem is that I can't be of much use until the people that really are qualified to design this stuff start producing designs. So, here's my opinion: we have enough structure. All the people are here that are going to show up. Now it's time to do the work and that means the experts have got to dedicate some serious time to sketching out the skeleton of this beast. Once you've done that then I think you'll find there are more people around to add the needed muscles, skin and brains. If you need to go off in a room alone to that, well, I guess that's your option. I just don't think you've actually given the existing structure much of a trial yet. -sam > > How about we do this to design the architecture and API: > > perl6-internals-design is for a team of no more than 10 people. These > people should have experience either with perl5 or with a similar > system. Mail to this list goes to perl6-internals-design and to > perl6-internals. > > perl6-internals is a public access list, where folks can feel free to > question and kibitz. The design team will probably want to have a few > people on the public list as well. This is where the consciousness of > the rest of us can be raised. We can see what they're doing, ask > questions, and make suggestions. Because the meta discussion happens > off the -design list, designers will be able to tune it out if they > have to focus on the task at hand. > > This lets us satisfy these goals: > * open process, both for visible and participation > * small team doing the design (elephant is a mouse designed by >committee, etc) > > Make sense? > > Nat >
Re: RFC 125 (v2) Components in the Perl Core Should Have Well-Defined APIs and Behavior
On Tue, 10 Oct 2000, Tim Bunce wrote: > > A very complete UML tool in Java is ArgoUML: > > > > http://argouml.tigris.org/ > > Umm, it might be interesting for someone to add a Perl code generator > for it... I've played with the idea of adding Perl code-generation to my design tools (Visio2000 and ObjectDomain). One question that comes up immediately: what code should be generated for class files? There's no single standard way to layout a Perl class beyond the obvious "h2xs" format. In particular there are numerous ways to declare attributes and methods. An awful lot of what makes a code generator usefull for languages like C++ and Java doesn't apply to Perl. We don't have to manage disjoint sets of declarations (header files / interface files) and implementation files (class files). We already have a flexible and simple documentation format - adding a POD interface to a UML tool would be cute but hardly a huge time saver. I enjoy working with visual UML tools but I'm unconvinced that Perl code generation would be of much practical use. Do you have ideas for functionality that I haven't considered? -sam
Re: RFC 227 (v1) Extend the window to turn on taint mode
On 14 Sep 2000, Chaim Frenkel wrote: > (Someone remind me, What is the point of -T if not running setuid?) All you need to get root is an unprivilaged shell on anything but a fully patched machine. A dumb Perl CGI running without -T is all you need to get a shell. Besides, I bet most online stores keep our credit card numbers in databases accessible by 'nobody'. You probably wouldn't even need root in most cases if you were after card numbers. -sam
Re: RFC 155 - Remove geometric functions from core
On Tue, 29 Aug 2000, Nick Ing-Simmons wrote: > David L . Nicol <[EMAIL PROTECTED]> writes: > > > >does sysV shm not support the equivalent security as the file system? > > mmap() has the file system. I wasn't aware that mmap() was part of SysV shared memory. My mistake? It's not on the SysV IPC man pages on my Linux system. The mmap manpage doesn't mention SysV IPC either. -sam
Re: RFC 155 - Remove geometric functions from core
On Tue, 29 Aug 2000, David L. Nicol wrote: > does sysV shm not support the equivalent security as the file system? Well, no, I don't think it does. It supports permissions on individual segments but it doesn't support anything like directory perimssions. It might be enough, and it might not be. A user can run two programs and not expect one to have an automatic exploit on the other just because they're both Perl! Think "nobody". Yes, you'd provide a paranoid mode for experts to use to avoid the problems to which most users would be exposed. Great. > Did I not just describe how a .so or a DLL works currently? Certainly not. You wrote only a few sentences. I'm no expert but I don't think that shared libraries are that simple. I also don't think they're implemented using SysV IPC shared memory, but you might know differently. > In the ever-immenent vaporware implementation, this whole thing may > be represented as a big file into which we can seek() to locate stuff. Zuh? What are you talking about? Is this some kind of Inline.pm-esque system? -sam
Re: RFC 155 - Remove geometric functions from core
On Tue, 29 Aug 2000, David L. Nicol wrote: > Well then. It is impossible to rearchitect it to make it shared > text? Perhaps the first instance of perl sets up some vast shared > memory segments and a way for the newcomers to link in to it and look > at the modules that have been loaded, somewhere on this system, and use > the common copy? That approach invites big security problems. Any system that involves one program trusting another program to load executable code into their memory space is vulnerable to attack. This kind of thing works for forking daemons running identical code since the forked process trusts the parent process. In the general case of a second perl program starting on a machine, why would this second program trust the first program to not load a poison module? I don't believe you can simply "rearchitect it to make it shared text". > This sounds like a problem to be fixed. Relax, Tom, we'll take it from > here. Are you so sure? From where I'm sitting he's got some pretty tough points there. If you've got a solution then I'm quite suprised, which would be great. If not then I suggest you avoid writing the proverbial bad check. -sam
Re: Do threads support SMP?
On 20 Aug 2000, Chaim Frenkel wrote: > SWM> Does Perl6 support Symmetric MultiProcessing (SMP)? Perl5 does - see 'fork'. I'm guessing that Perl6 will have at least that much support. > SWM> This is a *huge* issue. It affects everything else that we do with > SWM> threads. Most operating system's thread implementations treat threads like processes - they get scheduled independently on whatever CPUs are available. Some OSs do a better job than others, but there's nothing Perl can do about that. So, this is a pretty small issue for us. -sam
Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)
On Fri, 18 Aug 2000, Graham Barr wrote: > > No. The documentation states that the compilation is done only when the > > source file is out of date with the companion object file. As I > > understand it, Inline has some kind of limited automatic make ability. > > So it is a security issue then as it needs somewhere to cache these > object files, and anyone must be able to do it. The place it stores its objects is configurable, so it's only a security problem if you make it one! I'd say its more a configuration problem since you need to carefully think about where that place should be and set the appropriate permissions. -sam
Re: ANNOUNCE: Inline 0.23 (Mix Perl and C w/o XS)
On Thu, 17 Aug 2000, Nick Ing-Simmons wrote: > Simon Cozens <[EMAIL PROTECTED]> writes: > >Wow. I'm sold. Can this be how we should be doing XS in Perl 6? > So we now run equivalent of xsubpp and cc every time script is run? No. The documentation states that the compilation is done only when the source file is out of date with the companion object file. As I understand it, Inline has some kind of limited automatic make ability. Reading the documentation, the only thing red-flag I see is that it only comes with a few of the most obvious typemaps and doesn't seem to have an interface to adding new ones. Check it out: http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-08/msg00078.html -sam
Re: RFC 27 (v1) Coroutines for Perl
On 4 Aug 2000, Perl6 RFC Librarian wrote:
> This proposal introduces a new keyword to perl, "co", as a complement
> to "sub". A subroutine is defined thusly:
>
> co foo { ... }
>
> Coroutines can also be closures:
>
> my $x = co { ... }
Does this really require a new keyword? Why not do it as a module:
use Coroutine;
my $foo = new Coroutine(sub => sub { ... });
# to send
print $foo "data\n";
# to read
my $val = <$foo>;
This also allows a much easier path to future expansion. You can add new
options to new() easily - a priority option is something you
mentioned. You could also setup martialling if such is required.
> Coroutines can be implemented in their traditional manner, using context
> switching, or as threads, but would hide the mundane details of threads
> from the programmer. They would be more suited for producer/consumer type
> problems rather than massively parallel compuations, but I doubt there is
> much call for the latter to be implemented in perl.
And, of course, this wouldn't be the only threading primative offered by
Perl!
Other than those points, this RFC has my whole-hearted support. I'd love
to see solid coroutine support in Perl.
-sam
Re: inline mania
On Tue, 1 Aug 2000, John Tobey wrote: > The people here are rightly skeptical about the effectiveness of using > the 5.6 code base as a starting point for v6, but I have a pretty > clear vision of how to do it, and I am committed to giving it a try, > even if no one else will. In fact, I'll give you all a tentative > schedule: Wait, you're going to develop Perl 6 ALONE? Wasn't this going to be "the community's rewrite of Perl"? Shouldn't you be trying to rally support for your vision before issuing schedules? I'm not trying to knock you - I'm not at all against hearing you plans and possibly helping out. This just seems like a pretty strange way to approach a community effort. > 15 August 2000 - detailed draft spec to perl6-internals. > 31 August 2000 - revised spec after discussion. What? You're expecting all the various perl6-* lists to come up with final RFCs be the end of the month? And you're expecting to have Larry's final plans by then? Or are you going to implement Perl 6 without knowing what it is? > Unicode and threading would become integrable only after a lot of > morphing (refactoring). The morphing would probably destroy any > traces of v5 unicode support (since well under 20% of test scripts > will notice), and of course 5005threads will be the first to go. With > any luck, a compatible, well-integrated replacement will eventually > take its place. This sounds hopeful, but mostly unfounded. Without starting with threading and Unicode as primary features you're going to be fighting an uphill battle ala Perl 5. -sam
Re: inline mania
On Tue, 1 Aug 2000, John Tobey wrote: > I'm thinking of a rewrite in the sense that (by my impression) BSD was > a rewrite of Unix. Refactoring, shifting stuff around until it's easy > to get a handle on things, and replace it all a little at a time. So, > yes, these problems can be solved IMHO, after "enough" of Perl 5 has > been rewritten. Is that Perl 6 you're talking about or Perl 5.8? I mean that. Perl 5 will continue its development while we're doing the rewrite. Incremental changes would be best done in the 5.7 series, no? -sam
Re: inline mania
On Tue, 1 Aug 2000, John Tobey wrote: > Umm, well, not necessarily. Not if what I'm doing becomes what we're > doing. Do tell! What have you been doing? > See http://joel.editthispage.com/stories/storyReader$47 on the > evils of total rewrites. This article has been haunting me. My boss loves it. Suffice it to say that I don't get the OK to rewrite nasty old code as often as I used to. Perhaps for the best? Sometimes. Only sometimes. So, point taken, but I don't consider it gospel. Mozilla has more problems than simply being a costly rewrite. I'm not here to try to tell everyone we're doing a rewrite - that's only what I was told coming in the door. From the Perl 6 press release: The next version of Perl is a chance for the language developers to both rewrite the internals and externals of Perl based on their experience from developing Perl 5, and Chip Salzenbergs work with Topaz. Note that we don't have to take that "chance," but I don't think we should turn it down lightly. I suppose a reasonable question is: can we achieve our goals without a rewrite? Can we succeed in integrating threading and Unicode where the Perl5 developers have failed, without rewriting the internals? I'm not qualified to say no, but I'd like to hear compelling arguments before I'd believe a yes! -sam
Re: inline mania
On Tue, 1 Aug 2000, Simon Cozens wrote: > Counter-counterproposition: Look at the way Sapphire does it. I'm really > proud of that. It's automagically switchable from inlines to ordinary > functions to macros. You can choose which wins, and it's neat to debug. Counter-counter-... Sure I'll take a look. Sounds pretty cool. I'd like to restate, however, that I don't think we should start with this kind of fancy-footwork. We need to start with the basics and we need to keep things simple and understandable. I get the sense that the perl dev community has more than its share of efficiency experts. That's a good thing but there's a proper time to optimize and this is not it. We're doing a rewrite, aren't we? -sam
Re: inline mania
On Tue, 1 Aug 2000, John Tobey wrote: > I propose that all internal and external functions be implemented in > header files and declared inline. The external runtime API will be > generated by compiling non-inline wrappers. > > This will make possible an interesting performance optimization with > GNU CC, whereby op_ppaddr is replaced by a local label, and runops is > a block of code that uses goto instead of function pointer calls. It > could be kept clean (by Perl 5 standards) using techniques similar to > embed.pl's. I counter-propose that we avoid early optimization. I propose that our designs begin with readbility and modularity as their highest priorities. Later we can optimize the sense out of it but at least it would be readable to start with. I propose that we treat "clean (by Perl 5 standards)" as not clean enough for Perl 6. -sam
