Re: Project Start: Section 1
> Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm > Date: Sun, 10 Nov 2002 11:44:43 -0800 > From: Michael Lazzaro <[EMAIL PROTECTED]> > > Determine a schema describing the fields/elements of the documentation, > in order for the docs to be databased & later sliced in a variety of > ways (beginner manual, advanced specs, test cases, etc.) Input and/or > output requirements are, at minimum: > > -- as XML > -- as HTML > -- as manpage (*roff) > -- as PDF > -- as LaTex > -- as POD > -- as executable test cases > > Note that POD consists of formatting directives, not schema information, > and so cannot represent the information in a form sufficient for full > slicing. At this point it would therefore appear that XML is the most > obvious authoring option. I very much dislike XML for writing. It'd be nice to use some kind of "extended POD" or something. Something that's mostly content, little structure. Formats with a lot of structure tend to be unproductive, and although the structure is useful, much of it is redundant and can be bypassed by a processor that's just a little smarter. Of course, a sensible XML format could still be useful. Very sensible. Luke
Re: Unifying invocant and topic naming syntax
ralph wrote:
If the syntax for passing "it" to a sub
remains as verbose as it currently is,
you are probably right that "it" won't
be used to achieve brevity!
You're confusing brevity of declaration with brevity of use.
Declarations should always be relatively verbose.
Why do you think your estimate of Perl 6
usage of "it" is so much lower than is
true for the standard Perl 5 functions?
Because I don't believe many people write subroutines that
default to $_ or that rely on some particular value of $_.
In Perl 5, relying on $_ is fraught with peril, since its
global nature means you have to be wary of what happens to
it in any nested calls as well.
We ought not make that peril any easier to fall into in
Perl 6. Making $_ lexical goes a long way towards that.
Making (limited) circumvention of that lexicality depend on
a verbose and explicit syntax will help too.
Btw, can I just confirm that one can't do:
sub f ($a = ) { ... }
or
sub f (;$_ = ) { ... }
where is the upscope it and $_
is the sub's topic.
I seriously doubt it but, as always, that's up to Larry.
If it were allowed, the syntaxes might be something like:
sub f ($a = $CALLER::_) { ... }
sub f (;$_ = $CALLER::_) { ... }
Naturally, I see this as another symptom
of the way upscope "it" is being treated
as a second class citizen,
No. It's just not being treated as a parameter.
Because it isn't one.
and that this is leading things in the wrong direction.
Actually, I'm very happy with the direction it's being led.
Besides, what's wrong with:
$foo = sub { print $_ } is given($_);
Compared with
$foo = sub { print $^_ };
The answer is brevity, or lack thereof.
But, even if $^_ *were* synonymous with $_, it
still wouldn't do what you want. The placeholder
in:
$foo = sub { print $^_ };
makes the closure equivalent to:
$foo = sub ($_) { print $_ };
which expects the topic to be passed as the argument of the
subroutine, *not* "inherited" out-of-band from the caller's
scope.
If you're proposing that there be some special exemption for
$^_ so that it (a) doesn't placehold a parameter and (b)
aliases the caller's topic instead, then I'm vehemently opposed,
since it makes $^_ a kind of *anti*-placeholder.
Introducing that kind of inconsistency would be playing straight
into Simon's hands! ;-)
Why bother with currying?
You mean placeholders. Currying is something else entirely.
Why bother with the "it" concept? None of these are necessary.
They simplify code generation, but their more
general feature is enabling brevity.
Of usage, yes, but not necessarily of declaration.
Damian
Re: Primitive Vs Object types
Mark J. Reed wrote:
Attributes are class-specific for a variable (okay, class instance
specific, if you do Evil Things with multiple copies of a single base
class in different legs of the inheritance tree and override the
default behaviour of the engine) and not queryable at runtime without
really nasty parrot assembly code.
You won't be able to query attributes at run-time? Even within
the class? I rather like the ability to loop through
the attributes of an object with something like this Perl5 code:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $this->{$attr}\n";
}
You will. But they won't be entries of a hash. They'll be
separate variables and associated accessor methods.
So maybe something like this:
foreach my $attr (qw(foo bar baz))
{
print "$attr: $self.$attr()\n";
}
Damian
Re: Primitive Vs Object types
Luke Palmer wrote:
Could you just look through the lexical scope of the object?
for $this.MY.kv -> $k, $v {
print "$k: $v\n"
}
Or would you look through the class's lexical scope and apply it to
the object?
for keys $this.class.MY {
print "$_: $this.MY{$_}\n"
}
I think one of those two is possible. (Providing the .class method
exists and DWIMs)
I'm not sure either of those works, exactly. The scope of attributes isn't
precisely lexical in nature. Perhaps instead of a C method, an object
would have a (private!) C method, allowing something like:
for $this.HAS -> $attr {
print "$attr.key(): $attr.value()\n"
}
Or maybe not. ;-)
Damian
Re: Superpositions and laziness
Nicholas Clark wrote: We're looking for a word that tersely expresses > has_no_side_effects_and_can_safely_have_its_results_cached_based_on_parameter_types_ > and_values_and_calling_context ? And to people in the perl5 know, Memoize is the module that implements this, hence why people who know of how and what Memoize can do favour that name. Except that it's not necessarily obvious to everyone else? cacheable is rather long and sufficiently made up that my copy of ispell doesn't recognise it. But at least all English speakers can agree how to spell words that don't end in i[zs]e (or end ou?r or [cs]e :-) Except, of course, that many (near-)English speakers would be tempted to spell your suggestion "cachable". Hence I suspect that "cached" might be better. Then we will only have to contend with those few remaining Romantic poets who will want to write it "cachéd". ;-) Damian
Re: Superpositions and laziness
Paul Johnson wrote: Part of the reason I would prefer something like "pure" over something like "cached" is because it describes the function rather than telling the compiler how to deal with it. That feels better to me. It's working at a higher level. Maybe the end result is the same, or maybe there are other optimisations which can be made with "pure" functions. It's a way of nailing down the contract on the function rather than specifying implementation details. I can certainly see your point, but to me this is disquieteningly reminiscent of the horror that is C in C++ methods. Because, if you're serious about C meaning "pure" in the mathematical sense, then C subs can't access globals or C, can't have C parameters, and call non-C subroutines. One of the reasons I like C is because it does specify exactly the way the subroutine is to behave (i.e. be called the first time, and not called every subsequent time the same arguments are supplied). So I can do nasty^H^H^H^H^Hhandy things like giving the sub side-effects, in the sure knowledge that they won't be invoked more than once. With C I can never be sure what optimizations the compiler is or isn't going to make, or even whether those optimzations will be the same from platform to platform [*]. So I can never be sure what the precise behaviour of my sub will be. :-( Damian [*] I can easily imagine architectures under which re-calling a particular pure function is actually faster than retrieving a previously cached result.
Re: Quick roadmap
If memory serves me right, Dan Sugalski wrote: > > Should be reasonably straightforward. Hopefully quick, too, as I'm > pressed for time here. > -- Hmm... Object frameworks ? ... (or is that shelved for the present ?) Gopal -- The difference between insanity and genius is measured by success
Re: FMTWYENTK about := ( :-)
Arcadi wrote:
this is not a description or definition of something. It is just set
of questions and confusions that I have when I encounter words like
"variable" , "name" , "alias", "assign" in perl . In the form of
explanation. But actually these are questions .
These are answers. In the form of answers. ;-)
perl have 3 *mostly* independent concepts
i) variable-names ( live in namespaces )
2) actually variables or *containers* live in perl memori at
compile-time-phase .
Or run-time (e.g. lexicals, anonymous variables)
3) values live everywere and are the MOSTIMPORTANTTHING.
That is a philosophical position. I could also argue that
values are the LEASTIMPORTANTTHING: that they are merely
trivial "special cases" of the abstractions embodied by
the variables. I could also argue that even variables are
UNIMPORTANTTHINGS; that only the relationships between
variables, as represented by the algorithm, matter.
All just philosophical positions. ;-)
Variable is the following 3-level thing
1) name | '$a'
||
|V
2) container| (.)
||
|V
3) value| some number e.g., 5
Yes. This is a deep understanding. Excellent.
names are strings that can be chosen according to some
restrictions.
Though, in Perl, those restrictions aren't terribly restrictive. Here, for example,
is a variable whose name is (phonetically):
NEWLINE-NEWLINE-ALLO-ALLO-SPACE-the-SPACE-sky-SPACE-is-TAB-falling-BANG-BANG-BANG
and yet it is perfectly legal in Perl:
*{'
«» the sky is falling!!!'} = \[0]->[0];
while (${'
«» the sky is falling!!!'}<10) {
print ${'
«» the sky is falling!!!'}, "\n";
${'
«» the sky is falling!!!'}++;
}
Names *live* in *namespace* . that is, perl keep some
tables ( aka as namespaces ) that list known variable-names. and each
name refer to a container. the type of namespace: global, package,
lexical and so on defines the *scope* of variable-name, life-circle of
variable-name and so on ( but everything for variable-name ).
Another deep insight. Well done.
special modifiers "my" "our" help to place the variable-name in the desired
"variable-namespace".
container is mystical intermediate between value and variable
name.
Mystical? I'd have said that the container is the *least* mystical
part of the symbiosis. It's the only tangible piece of the puzzle.
Its a wheels and sticks inside the clock . we don't see it but it
is necessary to "de-mystify" - how the clock *knows* what time is it.
In perl variable may have properties . Actually containers have.
And values may have them too.
value is actual data - the 0's and 1's that actually run here and
there when program runs.
Not quite. The value is the *interpretation* of the 1's and 0's.
For example, the same bitsequence (say 01010101) may be part of
a (very short) string, or an integer, or a floating point number, or a
reference. And no two of those interpretations will necessarily
represent the same "value.
value is always a scalar - some number,
although it may be a reference ( which is also number ) to some more
elaborate structure ( as in perl is almost always the case even for
references themselves as far as I know, but ???) .
ha, and also, variable ( actually the container ) may be anonymous (
All containers are inherently anonymous. In a sense, a variable is
merely the association of a container and a name.
as most of variables in usual perl program ), in that case it is not
referenced to by some "variable-name" *directly* ; but it is
definitely referenced by something -- otherwize it is dead.
perl variable and values may have properties .
*compile time* properties are attached to *containers*
they are introduced by "is" operator ( actually at run time
containers may already be unneeded , they did all the "semantic"
work and the may go ,
but I am not sure )
Sometimes they can be optimized away; sometimes not.
*run time properties are attached to values ; they are introduced
with "but"; they begin to function at run-time, but perl at compiler
time may well be aware of them ( ??? ) .
Yes, it may be. If the value is a compile-time value such as:
return 0 but true;
then the compiler might well optimize that somehow.
examples :
my $x is constant = 1 ;
our $y = 0 but true ;
* "my" "our" tells where ( and how long and to whom visible ) the
*variable-name* '$x', '$y' lives.
and this create the following structure :
1) name | '$x' ( lives in MY:: namespace )
||
|V
2) container| (.)->props->{ "constant"=>1 , ... }
||
|V
3) value|1->props->{ ... }
1) name | '$x' ( lives in Main:: namespace )
||
|
Re: Project Start: Section 1
> > I very much dislike XML for writing. It'd be nice to use some kind > of "extended POD" or something. Something that's mostly content, > little structure. Formats with a lot of structure tend to be > unproductive, and although the structure is useful, much of it is > redundant and can be bypassed by a processor that's just a little > smarter. > > Of course, a sensible XML format could still be useful. Very > sensible. > > Luke I agree with you. XML is very unpleasant to write. I would rather focus on writing the content, and POD is just ok for this. We can later reformat the content in any other format or maybe extend POD to handle structure. I think we are going to be more productive if we avoid the discussion about file formats for now. -angel
[perl #18319] [PATCH] Re: How to portably link on Win32 (all flavors), OS/2 and VMS?
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #18319]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18319 >
I've gotten no negative feedback (no positive either, but that's normal)
so I propose that the following patch go in.
On Tue, 29 Oct 2002, Andy Dougherty wrote:
> On Tue, 29 Oct 2002, Andy Dougherty wrote:
>
> > Here's my proposal for stage one: This patch is intended to define
> > explicitly what the different compiler and linker commands and flags
> > are, what they are supposed to mean, and how they are to be used.
I've gotten a little feedback. Here's my proposed patch. I added yet
more documentation and cleaned up config/gen/makefiles/root.in to use the
variables consistently. Also, with the new link_out variable, the stack
direction test should work again with MS Visual C. It might even work
with VMS, though lots of other things still won't. I had to make some
guesses for all those systems.
I did not fix up Makefiles in different sub-directories or any other build
commands that are part of the test suite. Nor did I generalize the
stackdir.pl stuff to a generic Configure function. One thing at a time.
diff -r -u parrot-orig/config/auto/stackdir.pl parrot-andy/config/auto/stackdir.pl
--- parrot-orig/config/auto/stackdir.pl Mon Oct 21 09:44:36 2002
+++ parrot-andy/config/auto/stackdir.pl Thu Oct 31 11:57:03 2002
@@ -18,19 +18,33 @@
genfile('config/auto/stackdir/test1_c.in', 'test1.c');
genfile('config/auto/stackdir/test2_c.in', 'test2.c');
-my($cc, $ccflags, $ldout, $o, $link, $linkflags,
- $cc_exe_out, $exe, $libs) =
- Configure::Data->get( qw(cc ccflags ld_out o link linkflags
- cc_exe_out exe libs) );
+my($cc, $ccflags, $cc_c, $cc_inc, $o, $link, $linkflags,
+ $link_out, $exe, $libs) =
+ Configure::Data->get( qw(cc ccflags cc_c cc_inc o link linkflags
+ link_out exe libs) );
-system("$cc $ccflags -I./include -c test0.c >test0.cco $redir_err") and
-die "C compiler failed (see test0.cco)";
-system("$cc $ccflags -I./include -c test1.c >test1.cco $redir_err") and
-die "C compiler failed (see test1.cco)";
-system("$cc $ccflags -I./include -c test2.c >test2.cco $redir_err") and
-die "C compiler failed (see test2.cco)";
-system("$link $linkflags ${cc_exe_out}test$exe test0$o test1$o test2$o $libs
>test.ldo $redir_err") and
- die "Linker failed (see test.ldo)";
+# XXX VMS syntax is only a guess!
+# (The main issue is what to do about redirecting errors.)
+if ($^O =~ /VMS/) {
+ system("$cc $ccflags $cc_inc $cc_c test0.c") and
+ die "C compiler failed for test0.c.";
+ system("$cc $ccflags $cc_inc $cc_c test1.c") and
+ die "C compiler failed for test1.c.";
+ system("$cc $ccflags $cc_inc $cc_c test2.c") and
+ die "C compiler failed for test2.c.";
+ system("$link $linkflags ${link_out}test$exe test0$o,test1$o,test2$o $libs")
+and
+ die "Linker failed for stack direction test.";
+}
+else {
+ system("$cc $ccflags $cc_inc $cc_c test0.c >test0.cco $redir_err") and
+ die "C compiler failed (see test0.cco)";
+ system("$cc $ccflags $cc_inc $cc_c test1.c >test1.cco $redir_err") and
+ die "C compiler failed (see test1.cco)";
+ system("$cc $ccflags $cc_inc $cc_c test2.c >test2.cco $redir_err") and
+ die "C compiler failed (see test2.cco)";
+ system("$link $linkflags ${link_out}test$exe test0$o test1$o test2$o $libs
+>test.ldo $redir_err") and
+ die "Linker failed (see test.ldo)";
+}
my %results=eval cc_run();
cc_clean();
diff -r -u parrot-orig/config/gen/makefiles/root.in
parrot-andy/config/gen/makefiles/root.in
--- parrot-orig/config/gen/makefiles/root.inMon Oct 28 12:25:36 2002
+++ parrot-andy/config/gen/makefiles/root.inThu Oct 31 10:00:21 2002
@@ -7,8 +7,9 @@
RANLIB = ${ranlib}
LINK = ${link}
LD = ${ld}
+# link_out and ld_out might have trailing spaces, so they are handled
+# by the input file, config/gen/makefiles/root.in.
LD_SHARED = ${ld_shared}
-LD_OUT = ${ld_out}
LD_SHARED_FLAGS=${ld_shared_flags}
INC=include/parrot
@@ -168,7 +169,7 @@
mops : examples/assembly/mops${exe} examples/mops/mops${exe}
$(TEST_PROG) : test_main$(O) $(GEN_HEADERS) $(O_DIRS) $(O_FILES)
lib/Parrot/OpLib/core.pm
- $(LINK) ${ld_out}$(TEST_PROG) $(LINKFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
+ $(LINK) ${link_out}$(TEST_PROG) $(LINKFLAGS) $(O_FILES) test_main$(O) $(C_LIBS)
lib_deps_object : $(O_DIRS) $(O_FILES)
$(PERL) tools/dev/lib_deps.pl object $(O_FILES)
@@ -201,17 +202,17 @@
$(RANLIB) $@
blib/lib/libparrot$(SO) : blib/lib $(O_DIRS) $(O_FILES)
- $(LD) $(LD_SHARED) $(LD_SHARED_FLAGS) $(LDFLAGS)
$(LD_OUT)blib/lib/libparrot$(SO) $(O_FILES) $(C_LIBS)
+
[perl #18320] PerlArray, GC or string bug
# New Ticket Created by Jerome Quelin # Please include the string: [perl #18320] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18320 > And yet another bug discovered thanks to my Befunge interpreter (would you please stop breaking my Befunge toy! :-) ). I can't see wether it's a PerlArray, GC or string bug. I managed to shorten it to: $ cat foo.pasm new P1, .PerlArray set S0, "" set S1, "123456789\nabcdefghijkl\nABCDEFGHIJKL" substr S2, S1, 0, 9 concat S2, S0 set P1[0], S2 set P1[1], "foobar" set S14, P1[0] print ">>>" print S14 print "<<<\n" end $ perl assemble.pl foo.pasm > foo.pbc $ ./parrot foo.pbc >>>123456789 l <<< This is of course not the correct result. The l near the end of the line is machine-dependant, that is, it's garbage and can be whatever is in the memory. Leon Brocard tried it and told me removing the foobar line still gets the bug for him, but I need the foobar line on my machine to see the bug. The first shortened piece of code had a repeat statement, but it does not seem to be necessary for the bug. Anyway, here's the first shortened buggy code: new P1, .PerlArray repeat S0, " ", 12 set S1, "123456789\nabcdefghijkl\nABCDEFGHIJKL" substr S2, S1, 0, 9 concat S2, S0 substr S2, S2, 0, 80 set P1[0], S2 set P1[1], "foobar" set S14, P1[0] print ">>>" print S14 print "<<<\n" end I can't shorten it anymore, and no, I don't have a patch. I don't even know where the bug lies. I just know there's a bug :-) Jerome -- [EMAIL PROTECTED]
Re: Parrot Builds broken for Win32?
On Sun, 10 Nov 2002, Clinton A. Pierce wrote: > Grabbing the last few snapshots from dev.perl.org, I can't find one that'll > build under Win32. During Configure.PL I get these errors: > > Determining stack growth direction...'.\test.exe' is not recognized as an > internal or extern > al command, operable program or batch file. Try my patch logged as [perl #18319]. -- Andy Dougherty [EMAIL PROTECTED]
Re: [perl #18320] PerlArray, GC or string bug
Jerome Quelin (via RT) wrote: # New Ticket Created by Jerome Quelin # Please include the string: [perl #18320] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=18320 > And yet another bug discovered thanks to my Befunge interpreter (would you please stop breaking my Befunge toy! :-) ). I can't see wether it's a PerlArray, GC or string bug. Actually 2 bugs: PerlArray aka list and string_append. Thanks for reporting - fixed. leo
Re: Parrot Builds broken for Win32?
Andy Dougherty wrote: On Sun, 10 Nov 2002, Clinton A. Pierce wrote: Grabbing the last few snapshots from dev.perl.org, I can't find one that'll build under Win32. During Configure.PL I get these errors: Determining stack growth direction...'.\test.exe' is not recognized as an internal or extern al command, operable program or batch file. Try my patch logged as [perl #18319]. We need something like this patch, but PARROT_STACK_DIR is unused so I removed the stackdir.pl from RunSteps.pm. leo
branch dump
Hi, This may be an ignorant statement since I just joined this list, but I noticed that the parrot "branch" assembly instruction doesn't work and sometimes causes a core dump on Linux 2.4. -- example 1: setI0, 16 branch 3 print "a" print "b" print "c" print "d" print "\n" end result 1: prints nothing, just ends example 2: setI0, 16 branch 7 print "a" print "b" print "c" print "d" print "\n" end result 2: causes parrot to core dump (segmentation fault) - Since this is my first posting, I hope I haven't spoken ignorantly. I'm interested in getting involved with this project and I'd kind of like to know how things work. Got any advice for me? Michael W. Collins
Re: Quick roadmap
At 1:19 PM +0530 11/11/02, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: Should be reasonably straightforward. Hopefully quick, too, as I'm pressed for time here. -- Hmm... Object frameworks ? ... (or is that shelved for the present ?) Not shelved, no. (And arguably the infrastructure in place is sufficient to do objects, but that's a bit of a stretch) But with the things I've named, we have a complete functional core. (Well, OK, a complete imperative core. Close enough) With an object framework, we have an incomplete object core and incomplete functional core. I'm feeling the need for some completion here. :) Don't worry, objects will get done, and soon. I just wanted a short list there. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: branch dump
At 10:02 AM -0500 11/11/02, Michael Collins wrote: Hi, This may be an ignorant statement since I just joined this list, but I noticed that the parrot "branch" assembly instruction doesn't work and sometimes causes a core dump on Linux 2.4. Oh, it works, you just need to understand it properly. :) This is one of the reasons to use labels in a hand-rolled assembly program. So, let's look at your code, shall we? -- example 1: setI0, 16 branch 3 print "a" print "b" print "c" print "d" print "\n" end Simple, straightforward, easy. With one mistake, that of counting. Branch offsets are relative to the PC (IC?) at the start of the op. Words used to encode parameters to ops also count. So, lets show this with offsets: setI0, 16 branch 3 0 1 print "a" 2 3 print "b" 4 5 print "c" 6 7 print "d" print "\n" end So the branch 3 sets the PC to be the constant "a". Now, we don't inline string constants, so that's really an offset in the current segment's string table. In this case, its the first constant in the constant table, so it has an offset of 0. Which just happens to be the end opcode number. :) All you need to do is change the offset a bit to point to an opcode and you'll be fine. Two tools you may find handy are disassemble.pl (which disassembles a bytecode file) and the -t switch to parrot, which traces execution. Both are really useful for diagnosing Odd Problems. (And if this is actual assembly code you're writing, use labels for branch destinations, though real offsets are fine if you're planning on emitting the bytecode directly) -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Project Start: Section 1
Joseph F. Ryan wrote: > Well, my point was that language tests will be different than the > compiler/parser tests for awhile. For instance, take a simple string > substitution test: > > # simple substitution > my $var = "perl5"; > $var =~ s/\d/6/; > > While this is completely valid perl6, and something that might want to > be included in the regex test suite, it won't pass neither the P6C parser > tests, nor the P6C compiler tests, nor the P6C regex tests, because > substitution isn't implemented yet. Therefore, I don't think that it should > be included in the P6C tests. So where to put it? If it really needs to go > in /parrot/languages/perl6/t, perhaps tests like these could go in somewhere > like /parrot/languages/perl6/t/future ? True, but keep in mind that all you're doing is submitting a patch. It's up to the pumpking to decide whether he applies it immediately or only after the feature is implemented. Go ahead and put the test where it will make the most sense once everything is finished. When you submit the patch, clearly mark that it tests a feature that isn't implemented yet. If you only have time and energy to write one test, choose an implemented feature over an unimplemented one. You'll get the most satisfaction and the Parrot project will benefit the most from tests for implemented features. Allison
Re: Project Start: Section 1
On Monday, November 11, 2002, at 05:08 AM, Angel Faus wrote: I very much dislike XML for writing. It'd be nice to use some kind I agree with you. XML is very unpleasant to write. I certainly agree with that, but I was thinking of something very basic -- just enough to get it into a database, for example. You'd just copy a standard template and fill in the fields. Like perhaps: 1.1.2.1 Numeric Context Numeric Context is a context full of cheesy goodness. For example, the following code will put $obj in int context: my int $i = $obj; blah blah blah ... Context Numeric Values ... I agree it's more of a pain, but it's also conveying a *heck* of a lot more information, for not really that much more to type. There'd only be 10-15 allowed tags. (Note the empty closing tag on $obj. My tools handle this cheat, which makes it a heck of a lot more readable to put in lots of inline tags.) My point being it's a lot easier to convert from XML-->POD than POD-->XML, and if it's in a descriptive form like this we have a lot of web tools that will do slicing and autoformatting, so we can try out different approaches more easily online. Otherwise someone has to go in by hand to do every one of them later. (I'm also hoping POD itself will change to be more descriptive, perhaps partly based on what we learn here, but that'll be in the distant future.) MikeL
Re: Project Start: Section 1
On Sunday, November 10, 2002, at 06:00 PM, Allison Randal wrote: Revision on reading Mike's message: If the constant stream of revisions happens on cognitivity, how about submitting approved docs to the "perl6" repository? I would tend to agree, using the CVS repository to do nickle-and-dime revisions seems a waste. I'd rather do it somewhere else and submit "big" docs changes after they had been approved. MikeL
Example outline for Section 1
On Sunday, November 10, 2002, at 11:44 AM, Michael Lazzaro wrote:
TASK 1a:
Produce a _complete_ outline of all necessary documentation for Section
1, including the topics introduced and the order in which those topics
are represented.
As an example, here is a very crude partial outline that I created a
while back:
[] Values
[] literal numbers
[] literal strings
[] Variables
[] names
[] declaring
[] scope
[] my
[] our
[] temp
[] full package name
[] type
[] properties
[] rw, const, ?
[] assignment to
[] assertions on [fetch,store]
[] Scalars
[] implementing type
[] method calls of
[] properties of
[] overloading implementing type
[] Booleans
[] (references transparent to)
[] declaring
[] assignment to
[] accessing
[] Numbers
[] (...unfinished, similar to "Strings", below...)
[] auto BigInts, BigRats
[] Strings
[] declaring
[] assignment to
[] putting nonprintable characters in
[] ascii
[] Unicode
[] accessing
[] returns in bool context
[] returns in num context
[] @arr[-1]
[] length (chars,bytes,elements)
[] type of
[] q operators
[] q
[] qq
[] qw
[] qx
[] implementing type
[] method calls of
[] properties of
[] overloading implementing type
[] concatenate
[] ~ operator
[] interpolation
[] scalar: "$(expr)"
[] list : "@(expr)"
[] sub : "&(expr)" or "&foo(expr)" ?
[] parens now required
[] " ... \q{foo} ... "
[] ' ... \qq{$foo} ... '
[] ...etc...
[] " ... \L{ stuff } ... "
[] " ... \U{ stuff } ... "
[] " ... \Q{ stuff } ... "
[] make sure to backslash curlies inside meaningful curlies
[] printf formats
[] ' ... %d ... ' (single quotes or interpolates)
[] problems with interpolating too much
[] "$foo[bar]" vs. "$foo\Q[bar]" (using \Q)
[] Heredocs
[] begin
[] terminator
[] automatic whitespace removal
[] type (q,qq,...)
[] Arrays
[] implementation
[] flattening *@args
[] non-flattening $@args
[] lazy &@args
[] hashlist *%args
[] declaring
[] assignment to
[] ()
[] []
[] qw
[] can be spelled < >
[] ( $a .. $b )
[] ( $a .. $b : $step )
[] accessing
[] values
[] @arr[-1]
[] slices
[] *@arr to flatten
[] returns ref to itself in scalar context
[] lazyness
[] ( 1 .. Inf )
[] ($first,@rest) = ( 1 .. Inf )# should work
[] type of contents, or untyped
[] implementing type
[] method calls of
[] properties of
[] overloading implementing type
[] assertions on [get,put,clear,...]
[] [1,2,3] means scalar(list(1,2,3))
[] Hashes
[] declaring
[] assignment to
[] accessing
[] values
[] as pairs (a => b)
[] keys of %( a=>b, c, d=>e ) are (a,c,d) (binding of '=>')
[] returns in bool context
[] returns .keys in numeric context
[] .reset (iterators)
[] slices
[] lazyness of keys, vals
[] type of val, or untyped
[] type of keys, or default, or untyped
[] implementing type
[] method calls of
[] properties of
[] overloading implementing type
[] assertions on [get,put,clear,...]
[] References
[] transparency in bool context
[] Context
== bit, int, num, str, ref ->
(Integer,Number,String,Ref,Scalar,Array,Hash,Regex,Code)
[] scalar
[] bit $foo
[] int $foo
[] num $foo
[] str $foo
[] object ($foo, %foo, MyClass @foo, &foo, etc.)
[] list
[] flattening *@args
[] non-flattening $@args
[] lazy &@args
[] hashlist *%args
[] casting
[] scalar(expr)
[] list(expr)
[] hash(expr)
[] hash {}
[] objlist(expr1, expr2, ...) (scalar context to list of exprs)
[] sub {}
[] can casting also be spelled $foo.int, etc.?
[] determining context
[] Properties
[] declaring
[] attaching to (compiletime)
[] is
[] multiples: is foo bar zap
[] attaching to (runtime)
[] but
[] accessing
[] $foo.propname
[] assigning to
[] temp $self.propname = 0; # assigns to propname
[] temp $self is propname = 0; # wrong, assigns to $self
[] properties are method calls
[] but foo($a,$b,$c)
[] multiples: but foo bar zap
[] on vars
[] on vals/expressions
[] { return $foo but false }
[] on sub declarations
[] is rw
[] is constant
[] is same (memoized)
[] is private, is public
[] is lazy
[] is weak
Re: Example outline for Section 1
Michael Lazzaro writes: > On Sunday, November 10, 2002, at 11:44 AM, Michael Lazzaro wrote: > > TASK 1a: > > > > Produce a _complete_ outline of all necessary documentation for Section > > 1, including the topics introduced and the order in which those topics > > are represented. > > As an example, here is a very crude partial outline that I created a > while back: > I think , this still need some general introduction that just ties together in one picture all these value--variable--container-symbol-table-assignment--alias--propperty staff . something like your introduction with less details. because it seems that after you describe only what can *fit* in the picture . something like , you describe *every* particular flower in the garden , I first want to see the whole of it at ones as much as it is possible. because ultimately the peacfull whole of perl features is what is so beatiful and exciting about perl. Apocalypseses adn Exercises ( DConway> Apotheosis 3 and Excoriation 3? DConway> Apoplexy 3 and Exorcism 3? DConway> Apogee 3 and Escapevelocity 3? ) are first and formost exciting and stimulating. So we can try follow them as much as it is apprpriate. just my own wishes from this project. I a bit egoistic :-) . sorry for that . > [] Values > [] literal numbers > [] literal strings > arcadi.
Re: Superpositions and laziness
On Monday, November 11, 2002, at 02:19 AM, Damian Conway wrote: One of the reasons I like C is because it does specify exactly the way the subroutine is to behave (i.e. be called the first time, and not called every subsequent time the same arguments are supplied). So I can do nasty^H^H^H^H^Hhandy things like giving the sub side-effects, in the sure knowledge that they won't be invoked more than once. With C I can never be sure what optimizations the compiler is or isn't going to make, or even whether those optimzations will be the same from platform to platform [*]. So I can never be sure what the precise behaviour of my sub will be. :-( Amen. The more abstract or metaphorical the name, the more difficult it is to be really sure of what it does. Of the choices, "cached" seems by far the most self-explanatory. If we used "pure", we'd have to teach people what "pure" means, which would be much harder than teaching them what "cached" means. MikeL
The eternal "use XXX instead of POD" debate (was: Project Start: Section 1)
From: Angel Faus [mailto:afaus@;corp.vlex.com] > > I very much dislike XML for writing. It'd be nice to use some kind > > of "extended POD" or something. Something that's mostly content, > > little structure. Formats with a lot of structure tend to be > > unproductive, and although the structure is useful, much of it is > > redundant and can be bypassed by a processor that's just a little > > smarter. > > I agree with you. XML is very unpleasant to write. > > I would rather focus on writing the content, and POD is just ok for > this. > > We can later reformat the content in any other format or maybe extend > POD to handle structure. I think we are going to be more productive > if we avoid the discussion about file formats for now. Yes one more vote for: use POD and extend as necessary. Someone should probably dig through the perl6-lang archives and write up the great "Perl should use XXX instead of POD" debate. Nip the whole flaming debate in the bud. The most recent one that I can recall started around: http://www.mail-archive.com/perl6-language@;perl.org/msg05084.html Okay... let's make that someone be me... The general Pro's and Con's of POD seem to be: PRO === simple concise limited extensible forgiving easy to convert to XXX easy to write easy to read easy to ignore separates block/inline markup no special editor required the camel was written in it the powers that be won't stand for any substitute CON === confusing Perl-centric limited no tables no figures no lists whitespace sensitivity separates block/inline markup extensiblity loses most other "PRO" args The only consist support for something different than POD... was for something that is in fact very similar to, and in fact based upon POD: SDF. http://www.ifi.uio.no/in228/scripting/doc/sdf/index.html And the major arguments for something like SDF as POD "the next generation", are that it allows for tables, figures, lists, variables, styles. That it's extensibility is a little cleaner and easier on the eyes. And that it is less sensitive to whitespace. So my humble advice would be to forget XXX, concentrate on the shortcomings of POD, and perhaps merge whatever new extensible functionality you want, like say support for cascading requirements, into either POD or SDF... and go from there. -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
Re: Project Start: Section 1
On Sunday, November 10, 2002, at 07:36 PM, Joseph F. Ryan wrote: # simple substitution my $var = "perl5"; $var =~ s/\d/6/; While this is completely valid perl6, and something that might want to be included in the regex test suite, it won't pass neither the P6C parser tests, nor the P6C compiler tests, nor the P6C regex tests, because substitution isn't implemented yet. With all do respect, this is what TODO tests are for. Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: The eternal "use XXX instead of POD" debate (was: Project Start: Section 1)
On Mon, Nov 11, 2002 at 01:40:59PM -0600, Garrett Goebel wrote: > The general Pro's and Con's of POD seem to be: > > PRO > === > simple, concise, limited, extensible, forgiving > easy to convert to XXX, easy to write, easy to read, easy to ignore > separates block/inline markup, no special editor required > the camel was written in it, the powers that be won't stand for any substitute > > CON > === > confusing, Perl-centric, limited, no tables, no figures, no lists > whitespace sensitivity, separates block/inline markup > extensiblity loses most other "PRO" args Two arguments that I don't see listed (and may not have been raised in the most recent perl6-language version of the debate) are: [PRO] It is difficult to get open source hackers to write documentation. Therefore, it is essential to reduce the potential barriers as much as possible. Format conversion can happen after the fact; the best format in the world is useless if it inhibits people from writing docs. Pod addresses this as a core problem, and imposes only the smallest of learning curves and slightest of inconveniences upon authors. [CON] Anything more complex than pod either inhibits people writing docs, or inhibits docs being converted to other formats (HTML, [La]TeX, XML, DocBook, etc.), or both. This point is more than just theory; we've seen it happen many times over the past decade. Another argument in favor of Pod is that it seems that everyone who wants to switch to format XXX hasn't made a significant contribution to the Perl documentation (or the Pod toolchain), yet finds it horribly broken. Nevertheless, the number of people who use Pod and the amount of documentation in Pod continues to increase every year. Z.
Re: Project Start: Section 1
On Mon, Nov 11, 2002 at 10:34:00AM -0800, Michael Lazzaro wrote: > ... I was thinking of something very basic -- just enough to get > it into a database, for example. You'd just copy a standard > template and fill in the fields. Like perhaps: > > > 1.1.2.1 > Numeric Context > > Numeric Context is a context full of cheesy goodness. For > example, the following code will put $obj in int > context: > > my int $i = $obj; > > blah blah blah ... > > > Context > Numeric Values > > > ... > > > > I agree it's more of a pain, but it's also conveying a *heck* of a lot > more information, for not really that much more to type. I think POD is sufficiently extensible that we can add that functionality without going 100% XML, e.g.: =head1 NAME 1.1.2.1 - Numeric Context =begin parrotdoc ContextNumeric Values ... =end parrotdoc Numeric Context is a X full of cheesy goodness. For example, the following code will put C<$obj> in C context: my int $i = $obj; blah blah blah ... =cut So POD and XML are isomorphic with regards to information conveyable. I think tools to convert POD <=> XML will be very easy to come by, so perhaps we should come up with standard doc markup to facilitate building those tools. J
Re: Example outline for Section 1
In my opinion, this outline puts too much weight on the first section. I would prefer it to be made of just the basic concepts and have forward references to the apropiate sections. For example: I wouldn't put the list of methods supported by each of the types in Section 1. Instead of this, I would point to the reference of Built-in classes. This would be a set of documents structured by class, where the user would find: - The inheritance tree of the Class - The run-time and compile-time properties that affect the behaviour of objects of this class. - The public methods and attributes of the class. - What is its value in boolean/numeric/Foo... context. For example: the reference of the Object class would explain the rw, const, etc.. properties; and the methods that any object implements. The same for the String, Number, Code, etc.. class. I imagine it could structured in something like this: Class String --- Represents Perl String values. It is automatically constructed when you write literal strings, or string quotes (q, qq). INHERITS FROM: Object (or Scalar?) PROPERTIES: (?) CONTEXT TRANSFORMATIONS: - bool: When used in boolean context, returns true if the string has non-zero length and false otherwise. - num: Returns the number represtened by the string. If there is no possible interpretation as a number, returns 0. The interpretation of number representations is the same that when writing literal numbers. METHODS: - chars(): return the number of chars that the string is made of - bytes(): return the length of the string in bytes. This will be usually different from chars, whenever the string is in a multi-byte econding. --- (as you can see, my imagination is not very original indeed) I also would remove any formal explanation of operators, to avoid duplication with an Operators chapter. And I think that the right place to explain sprintf formats is the sprintf function reference. This approach would leave Section 1 with the role of introducing the basic concepts and an explanation of how to use them (with some informal examples, and pointers to right sections). A final question: I am afraid I don't know what "implementing type" and "overloading implementing type" are about. Could you explain them? Thanks. -angel
Re: The eternal "use XXX instead of POD" debate (was: Project Start: Section 1)
On Monday, November 11, 2002, at 11:58 AM, Adam Turoff wrote: Two arguments that I don't see listed (and may not have been raised in the most recent perl6-language version of the debate) are: So long as someone can come up with a formal POD template that represents all the fields we need, I'm game. Just something easy to slurp into a database, please. MikeL
Re: Example outline for Section 1
On Monday, November 11, 2002, at 12:13 PM, Angel Faus wrote:
In my opinion, this outline puts too much weight on the first section.
I would prefer it to be made of just the basic concepts and have
forward references to the apropiate sections.
Agreed. I was just listing all the *possible* cruft that had to go in
somewhere... if you look at /val.html, you'll see it doesn't even have
half of it.
A final question: I am afraid I don't know what "implementing type"
and "overloading implementing type" are about. Could you explain
them? Thanks.
Assume you have:
my str $a;
my str @b;
my str %c;
this can also (tentatively) be represented as:
my $a;
my @b is Array of str;
my %c is Hash of str;
or, extrapolating:
my $a is Scalar of str;
my @b is Array of str;
my %c is Hash of str;
In other words, each variable has at least two types: the type the
variable "stores" (str) and the type the variable "is" (Scalar, Array,
Hash). It's the latter type that is the "implementing" type.
This is only important because it's presumably possible to declare
Scalars, Arrays, and Hashes that are based on other classes:
class OrderedHash is Hash { ... }
my %c is OrderedHash of str;
which gets you functionality very similar to a 'tie', but more
consistent and easier to use.
There's a ton of tricky questions in this that we need to figure out,
(as soon as we get through the first
how-the-heck-will-we-document-things decisions.)
MikeL
HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
From: David Wheeler [mailto:david@;wheeler.net] > On Sunday, November 10, 2002, at 07:36 PM, Joseph F. Ryan wrote: > > # simple substitution > > my $var = "perl5"; > > $var =~ s/\d/6/; > > > > While this is completely valid perl6, and something that > > might want to be included in the regex test suite, it > > won't pass neither the P6C parser tests, nor the P6C > > compiler tests, nor the P6C regex tests, because > > substitution isn't implemented yet. > > With all do respect, this is what TODO tests are for. Can anyone write up a detailed document describing how one would go about writing Perl6 test cases and submitting them to Parrot? The parrot documentation on testing, is understandably focused on testing parrot... not the languages running on parrot. I can't find any writeup or overview on the Perl5 regression test framework. Which is odd, because I'd expect something like that to exist in the core documentation. -Perhaps I'm just missing it... Otherwise useful links include: A basic guide to writing tests for Parrot http://www.parrotcode.org/docs/tests.pod.html chromatic's: An Introduction to Testing http://www.perl.com/pub/a/2001/12/04/testing.html And there's the Perl QA sites: http://qa.perl.org/ http://magnonel.guild.net/~schwern/cgi-bin/perl-qa-wiki.cgi And Michael G. Schwern's: http://magnonel.guild.net/~schwern/talks/Writing_A_Test_Library/full_slides/ but -- Garrett Goebel IS Development Specialist ScriptPro Direct: 913.403.5261 5828 Reeds Road Main: 913.384.1008 Mission, KS 66202 Fax: 913.384.2180 www.scriptpro.com [EMAIL PROTECTED]
RE: Autovivification
Erik Steven Harrison:
# >I think that, if Perl can determine the type with virtually no
# >ambiguity, it should autovivify.
#
# Actually, this behavior has already (mostly) been decided over in P6
# language. It was decided (and I agree) that the Perl 5 behavior of
Can you give me a link or a thread name or something?
# autovivifying references to the basic data types is the incorrect
# behavior, leading to a lot of bugs when dealing wityh complex data
# structures. So no autovifiying an untyped $undefined_var[$foo]
Why? It's pretty obvious that you want an array, and the normal array
Perl 6 provides is a good default.
If this is the case, why should we allow C or C<[qw(anon
array)]> without a type? After all, they might *really* want a
different type of array!
My understanding was that Perl 6 is not abandoning the DWIM principle.
When did this change?
(Sorry if this sounds like I'm attacking you. I'm not--I'm just
attacking your opinion. :^) )
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: HOWTO: Writing Perl6 Tests
On Monday, November 11, 2002, at 12:31 PM, Garrett Goebel wrote: Can anyone write up a detailed document describing how one would go about writing Perl6 test cases and submitting them to Parrot? The parrot documentation on testing, is understandably focused on testing parrot... not the languages running on parrot. Allison, if you could arrange an official liaison on p6i that could direct (in a definitive, buck-stops-here way) authors' efforts w/ regard to how perl6-specific tests should be written, we would be grateful. We seem to have a decent number of people here willing to do it, if they get some tutoring to start out. Otherwise useful links include: A basic guide to writing tests for Parrot http://www.parrotcode.org/docs/tests.pod.html chromatic's: An Introduction to Testing http://www.perl.com/pub/a/2001/12/04/testing.html And there's the Perl QA sites: http://qa.perl.org/ http://magnonel.guild.net/~schwern/cgi-bin/perl-qa-wiki.cgi And Michael G. Schwern's: http://magnonel.guild.net/~schwern/talks/Writing_A_Test_Library/ full_slides/ MikeL
Previous writings
If it's not obvious, I hereby donate the perl6-related text currently at: http://cog.cognitivity.com/perl6/val.html http://cog.cognitivity.com/perl6/var.html to the perl6-documentation effort. Authors are free to copy/paste/modify/rewrite the text, as desired, when writing docs for this project. MikeL
Re: branch dump
If memory serves me right, Dan Sugalski wrote: > All you need to do is change the offset a bit to point to an opcode > and you'll be fine. Hmm... you mean to say that a jump to a non-instruction is valid ? .. We've had the verifiability question hashed out ... but jump target validation is one of the simplest cases. This could a serious issue if Parrot starts using precompiled .pbc files (instead of the .pm model). Also it must be relatively simple to check for right ? ... A special option (for the sake of speed freaks ?) parrot -fverify hello.pbc ? Excuse my ignorance if such a thing already exists ... Gopal -- The difference between insanity and genius is measured by success
Re: branch dump
At 9:25 PM +0530 11/11/02, Gopal V wrote: If memory serves me right, Dan Sugalski wrote: All you need to do is change the offset a bit to point to an opcode and you'll be fine. Hmm... you mean to say that a jump to a non-instruction is valid ? .. Sure. Or at least not forbidden. We've had the verifiability question hashed out ... but jump target validation is one of the simplest cases. This could a serious issue if Parrot starts using precompiled .pbc files (instead of the .pm model). No, it's not a problem. There are two potential cases to deal with. 1) We trust the code 2) We don't trust the code The first is the common case for us. We're either coming straight from source, or from code that we are reasonably sure is fine. In that case, why bother verifying? Sure, there may be compiler errors, but having every single invocation of bytecode check for compiler errors is a bit excessive. The second is the less common case, but given the number of things we can't verify (it's valid to give branch and jump register args) the time spent isn't going to get you anywhere, since you need to check at runtime anyway. With a full scan of the bytecode, of course, and you'd need to figure where each and every instruction starts, which can be costly. (We can't use any table in the bytecode, as what makes that table any more valid than the code itself? :) We're already pretty much forced to do full runtime checking, so if code branches somewhere it shouldn't when it's running in a restricted container, we'll just catch the bad access and kill the interpreter. Not much else for it, if we need to guard against the malicious, and unfortunately we do. Also it must be relatively simple to check for right ? ... A special option (for the sake of speed freaks ?) parrot -fverify hello.pbc ? No, the option'd be more that you enable verification rather than disable it. Speed is the default. Excuse my ignorance if such a thing already exists ... Only plans, which aren't as solid as they ought be. I'll fix that. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Unifying invocant and topic naming syntax
> You're confusing brevity of declaration
> with brevity of use.
One needs sufficient brevity of both call
and declaration syntax if the mechanism's
brevity is to be of use in short scripts.
> Making (limited) circumvention of [$_'s
> lexicality] depend on a verbose and
> explicit syntax will help too.
Sometimes verbosity doesn't matter, but
I don't see how it can ever help. I'd buy
"clarity".
More to the point, the declaration syntax
will not help with avoiding accidents at
the time of call. So what is driving you
guys to deliberately avoid a brief def
syntax?
> > $foo = sub { print $^_ }; # shorthand for
> > $foo = sub { print $_ } is given($_);
> If you're proposing that there be some special
> exemption for $^_ so that it (a) doesn't
> placehold a parameter and (b) aliases the
> caller's topic instead
Well it clearly does placehold something.
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self and $line? I am
talking about being able to placehold
these things, whatever you choose to call
them.
> > Why bother with currying?
>
> You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
--
ralph
Some basic string tests.
I wrote up some basic string tests, just to get a feel. You can find them at: http://jryan.perlmonk.org/images/stringtest.tar.gz Things of note: -I wasn't sure how the tests should be written, so I wrote them in a generic 'code in .t, expected output in .o' form. This should be pretty easy to convert to whatever is decided. -Things that are currently unimplemented in P6C are in the TODO folder, per David Wheeler's suggestion. -I added the original P6C string test that I wrote to the tarball for comparison; its 'p6corig.t'. This uses a system that P6C uses; it is built off of Parrot's Parrot::Test, which is built off of Test::More.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Garrett Goebel wrote: > Can anyone write up a detailed document describing how one would go about > writing Perl6 test cases and submitting them to Parrot? The parrot > documentation on testing, is understandably focused on testing parrot... > not the languages running on parrot. > > I can't find any writeup or overview on the Perl5 regression test > framework. Which is odd, because I'd expect something like that to exist > in the core documentation. -Perhaps I'm just missing it... I'm not going to attempt the "detailed" document you ask for; but I would like to offer some thoughts. Test suites for Perl5 modules can be somewhat opaque. It is not obvious what is being tested. Anyone familiar with "Agile" programming methods will know the importance of good tests is; and that test-code should be as well written as actual production code. We should attempt to set a good example. It is often hard to write good tests. Especially if they are written as a derivative of a spec (or, Argh, of the code itself). Writing tests should be one of the most important activities of any module writer, so we should want it to be one of the easiest things that one can do in Perl6. Making things easy, is hard! So we should be prepared to endure some pain to get it write. We should expect to implement some tests in one way, then throw them out (or convert them) when we find a better way. We MUST avoid setting our testing approach in stone from Day-1. We probably want to orient towards something like the xUnit test-suites; but we want to do it in a way that incorporates a module's documentation (the module in question may be CORE:: -- so lets not think of the Perl6 documentation project as a special case). I've just said we should expect to thouw away tests, when we find better ways of doing things; so here's one to throw away: =chapter 0 Getting Started Every programming book starts with a simple program that prints the message "hello, world" to the screen. The Perl6 documentation is no exception. This is how to write this simple program in Perl6: =test-src hello_world print "hello, world\n"; =explaination When you run this program, you should see the message on the screen =test-stdout hello, world =test-end OK, so its a trivial test; but we must be able to write them. We'll find various problems with alternative output devices, etc.; but this shouldn't put us off. The emphesis in on using a test to explore a behaviour, from the perspective of a user. It is not a white-box test. The test should be readable as part of the documentation: not something separate, that only gurus can fathom. We need a standard script that runs tests that are embedded in documentation. Dave.
Re: The eternal "use XXX instead of POD" debate (was: Project Start: Section 1)
Monday 11 November 2002 20:40, Garrett Goebel wrote: > The only consist support for something different than POD... was > for something that is in fact very similar to, and in fact based > upon POD: SDF. > > http://www.ifi.uio.no/in228/scripting/doc/sdf/index.html > > > And the major arguments for something like SDF as POD "the next > generation", are that it allows for tables, figures, lists, > variables, styles. That it's extensibility is a little cleaner and > easier on the eyes. And that it is less sensitive to whitespace. > After reading the SDF documentaion it looks a very interesting alternative to POD: even more usable than POD, an way more powerfull. Unfortunately, I was unable to run SDF on my computer (I keep getting a nasty out-of-memory error), and the project looks a bit unmantained right now, (I had to download it from CPAN, because the link pages are broken). Does anyone have any experience with SDF? -angel
Re: perl6-all doesn't seem to get these
[EMAIL PROTECTED] (Markus Laire) writes: [...] > I have subscribed to both perl6-all and perl6-documentation, and > these messages don't seem to get into perl6-all at all. It would have been better if you had told [EMAIL PROTECTED] I just browsed through the archive for this list and noticed your post. perl6-all should be getting the messages now. -- ask bjoern hansen, http://www.askbjoernhansen.com/ !try; do();
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
In order for TODO tests to work Test::Harness must be upgraded (only 5.8.0 ships with a T::H able to parse TODO tests). An upgraded version of Test::Harness can simply be distributed with Parrot the same way Test::More is. On Mon, Nov 11, 2002 at 02:31:50PM -0600, Garrett Goebel wrote: > I can't find any writeup or overview on the Perl5 regression test framework. > Which is odd, because I'd expect something like that to exist in the core > documentation. -Perhaps I'm just missing it... pod/perlhack.pod contains some issues specific to the Perl 5 core. Most of them have to do with legacy and bootstrapping problems (ie. when you're testing yourself with yourself). The most important for Parrot is "you must burn a small sacrifice to cross-platform compatibility when writing core tests", but I don't think you can even write incompatible code in Parrot yet the way you can in Perl 5. Otherwise, they're just normal tests and are handled by things like Test::Tutorial, Test::More and Test.pm. Details on the test output protocol can be found in Test::Harness. > Otherwise useful links include: > > A basic guide to writing tests for Parrot > http://www.parrotcode.org/docs/tests.pod.html > > chromatic's: An Introduction to Testing > http://www.perl.com/pub/a/2001/12/04/testing.html > > And there's the Perl QA sites: > http://qa.perl.org/ > http://magnonel.guild.net/~schwern/cgi-bin/perl-qa-wiki.cgi > > And Michael G. Schwern's: > http://magnonel.guild.net/~schwern/talks/Writing_A_Test_Library/full_slides/ -- Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/ Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One Don't ask me lady, I live in beer.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Monday, November 11, 2002, at 03:33 PM, Michael G Schwern wrote: Otherwise, they're just normal tests and are handled by things like Test::Tutorial, Test::More and Test.pm. Details on the test output protocol can be found in Test::Harness. I think it'd be useful for folks to get a pointer to some existing Perl 6 tests that they can model off of. Do any exist yet? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Example outline for Section 1
On Monday, November 11, 2002, at 12:31 PM, Michael Lazzaro wrote: On Monday, November 11, 2002, at 12:13 PM, Angel Faus wrote: In my opinion, this outline puts too much weight on the first section. I would prefer it to be made of just the basic concepts and have forward references to the apropiate sections. Agreed. I was just listing all the *possible* cruft that had to go in somewhere... if you look at /val.html, you'll see it doesn't even have half of it. Oh, sorry -- and this is assuming there will be a "Section 0" which gives the basic whole-language introduction. Which we can't do yet, because we don't know most of the details. So by "Section 1", I mean "the first section after the introductory stuff." MikeL
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
On Mon, Nov 11, 2002 at 11:47:01PM +0100, Angel Faus wrote:
> Does anyone have any experience with SDF?
I played with it for some in-house documentation a couple years ago.
I'm afraid I wasn't very impressed with it; I found it very difficult
to customize the output to what I wanted, and the syntax is a bit
of a mess.
One of POD's good features is that there is very little syntax to
learn. ("=foo" begins a paragraph; paragraphs end with a blank
line; X is an interior sequence.) This has resulted in some
ugliness--in particular, lists are terrible, since a simple
three-element list:
- one
- two
- three
must be written as:
=over
=item *
one
=item *
two
=item *
three
=back
16 lines of POD!
POD parsers also go to a fair amount of trouble to infer syntax. For
example, a function name like this() will be rendered differently by
many POD processors. This is a good thing, in that you don't have to
litter your documentation with a lot of C<> directives. This is a bad
thing, in that there aren't any formal rules on what patterns parsers
will match, so you're never quite certain what your document will end
up looking like.
I'd love to see a cleaner POD, with tables, better support for lists,
and the ability to turn syntax inferencing on a per-document basis.
Unfortunately, I don't think SDF is it.
I'd be happy to join in a discussion of how to make a better POD.
I don't think this is an appropriate topic for the perl6 documentation
list, however--consider Knuth, _The Art of Programming_, and TeX
as an example of what can happen if you decide to create the perfect
authoring system before starting to write. :>
- Damien
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, 11 Nov 2002, David Wheeler wrote: > I think it'd be useful for folks to get a pointer to some existing Perl > 6 tests that they can model off of. Do any exist yet? languages/perl6/t/*/*.t is what we've got, though they're intended to exercise the prototype compiler, not the "real language" (which looks like it's changing quite a bit from what's implemented). The "sub main" should now be optional, btw. /s
Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
On Mon, Nov 11, 2002 at 03:50:34PM -0800, Damien Neil wrote: > POD parsers also go to a fair amount of trouble to infer syntax. For > example, a function name like this() will be rendered differently by > many POD processors. This is a good thing, in that you don't have to > litter your documentation with a lot of C<> directives. This is a bad > thing, in that there aren't any formal rules on what patterns parsers > will match, so you're never quite certain what your document will end > up looking like. This is a common complaint about Pod. The main problem is with the multiple Pod processors that use different inference rules. > I'd love to see a cleaner POD, with tables, better support for lists, > and the ability to turn syntax inferencing on a per-document basis. > Unfortunately, I don't think SDF is it. I *think* we're almost there. Sean Burke has been working on revamping Pod from the ground up for a few months now. He started with a clear spec on what should be inferred where and when (perlpodspec) and a series of modules and tools that obey those rules (Pod::SAX and his recent rewrite of pod2man and such). I haven't been keeping up with his efforts, but was among the many who mentioned the need to have "extensions" to Pod a few months ago. I believe that Sean and others are chomping on that nut at the moment. > I'd be happy to join in a discussion of how to make a better POD. Check out [EMAIL PROTECTED] Z.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote > languages/perl6/t/*/*.t is
what we've got, though they're intended to
> exercise the prototype compiler, not the "real language" (which looks like
> it's changing quite a bit from what's implemented).
OK, lets take a specific test. builtins/array.t contains a test for the
reverse (array) function. Ignoring the fact that it is obviously incomplete,
I'd like to focus on the format of the test.
The test currently looks like (with a bit of cleanup):
#!perl
use strict;
use P6C::TestCompiler tests => 1;
##
output_is(<<'CODE', <<'OUT', "reverse");
sub main() {
@array = ("perl6", "is", "fun");
print @array, "\n";
print reverse @array;
print "\n", @array, "\n";
}
CODE
perl6isfun
funisperl6
perl6isfun
OUT
##
This is fine as a test, but not as documentation. Furthermore, it is
depending on the "print" statement for its comparison (not necessarily bad;
but I find that "golden-output" style tests tend to become difficult to
maintain -- specific assertions tend to work better).
So what would documentation for this feature look like?
=context array ops
=function reverse
The reverse functions takes an existing array, and returns a new array that
contains the same elements in the reverse order. Like all functions on
arrays, it can also be called as a method on the array, using "dot"
notation. The following example demonstrates its use:
=test simple_array_reverse
my @original = qw( foo bar baz );
my @result = reverse @original;
assert_equal( @result, qw( baz bar foo ) );
assert_equal( @original, qw( foo bar baz ) );
my @reversed_again = @result.reverse;
assert_equal( @reversed_again, qw( foo bar baz ) );
=test-end
=cut
I'm not claiming that the test is any better. But its context is that of
documentation, not code. An obvious question is how to extend it to be a
more thorough test, whilst not spoiling the documentation. We'd want to
intersperse text with the test-code; and probably mark a few bits as
"hidden", from a normal documentation view (levels of hiding might be
defined for overview vs. reference vs. guru levels of understanding).
Dave.
Re: Unifying invocant and topic naming syntax
ralph wrote:
> So what is driving you
guys to deliberately avoid a brief def
syntax?
Can't speak for Larry. But what's driving me is the desire
to balance conciseness with comprehensibility, and to keep the
overall cognitive load manageable.
If you're proposing that there be some special
exemption for $^_ so that it (a) doesn't
placehold a parameter and (b) aliases the
caller's topic instead
Well it clearly does placehold something.
Sure. It's placeholds a parameter named $^_, which
may or may not be equivalent to a parameter named $_
(Larry will need to rule on that bit).
In
method f ($self : $a) { ... }
sub f ($a) is given ($line) { ... }
what do you call $self
The "invocant".
and $line?
A lexical variable that happens to be bound to the caller's topic.
I am talking about being able to placehold
these things, whatever you choose to call
them.
You can't placehold the invocant, since placeholders create subroutines,
not methods.
We probably *could* find a notation to placehold the C variable,
but I just can't see the need, when all you have to do now is write
C after the closure.
Why bother with currying?
You mean placeholders.
I meant currying. (I was listing mechanisms
that I believed existed to enable coding
brevity.)
Currying is more about efficiency and algorithmic integrity than
brevity. In fact, I would argue that it explciitly *not* about brevity.
Compare:
$incr = &add.assuming(x=>1);
with:
$incr = { add(1,$^y) };
The currying syntax was (deliberately) chosen to be verbose because
powerful or unusual things should be clearly marked.
Ultimately we're discussing philosophy, which is a waste of time since
we are unlikely to convince each other. I think we should just agree
to disagree here, and let Larry decide.
Damian
Re: branch dump
If memory serves me right, Dan Sugalski wrote: > Sure. Or at least not forbidden. k ... > that case, why bother verifying? Hmm wouldn't the JIT benifit from a pre knowledge of basic blocks and types or some information ? ... (I seem to think so ...). > at runtime anyway. With a full scan of the bytecode, of course, and > you'd need to figure where each and every instruction starts, which > can be costly. Can't that be added onto the JIT'ing process ? ... viz during conversion ,check for jump targets ?.. I still have this assumption that JITs need to maintain some sort of basic block identification for peephole optimisations ?.. Or is that totally irrelvant for register VMs ? ... (this is the first register VM I have encountered...) > >option (for the sake of speed freaks ?) parrot -fverify hello.pbc ? > > No, the option'd be more that you enable verification rather than > disable it. Speed is the default. Yup I meant just that not "-noverify' , but "-verify" :-)... So, Parrot is more secure than perl is ? (that being your benchmark). Gopal -- The difference between insanity and genius is measured by success
Re: branch dump
> Hmm wouldn't the JIT benifit from a pre knowledge of basic > blocks and types or some information ? ... (I seem to think so > ...). I would think so, because if, for example, the JIT wants to do a full register allocation to map parrot registers to machine registers, it would certainly need information about basic blocks. (I am talking of a complete register allocation, that would re-do the original register allocation of imc with the actual number of registers available in the machine) On the other hand, the JIT could certainly regenerate this information from the imc code, which is probably going to be stored somewhere anyway. -angel
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, 11 Nov 2002, Dave Whipp wrote:
> This is fine as a test, but not as documentation. Furthermore, it is
> depending on the "print" statement for its comparison (not necessarily bad;
> but I find that "golden-output" style tests tend to become difficult to
> maintain -- specific assertions tend to work better).
One thing the "golden-output" has going for it is that it gets into and
out of perl6 as quickly as possible. In other words, it relies on
perl6/parrot to do just about the minimum required of it, then passes
verification off to outside tools (e.g. perl5). I realize they can be
fragile, but at least for the moment, we can't rely on a complete
perl6 Test::Foo infrastructure, and I think that in general, we
_shouldn't_ require such a thing for the very basic tests. Because if we
do, and something basic is broken, all the tests will break because of it,
making the bug-hunter's job much more difficult.
> documentation, not code. An obvious question is how to extend it to be a
> more thorough test, whilst not spoiling the documentation. We'd want to
> intersperse text with the test-code; and probably mark a few bits as
> "hidden", from a normal documentation view (levels of hiding might be
> defined for overview vs. reference vs. guru levels of understanding).
Hm. I'm not sure how well it goes with the Perl philosophy ("the perl
language is what the perl interpreter accepts"), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I don't think real tests, which exercise specific corner cases,
mix very well with user-level documentation of any sort.
/s
RE: Project Start: Section 1
Michael Lazzaro:
# OK, let's start on the first section (calling them
# "Sections", not "Chapters"). As our first experiment, we
# will assume a treelike style (section 1 --> 1.1, 1.2, 1.2.1,
# etc.); look at http://www.mysql.com/documentation/ for an
# example of a good, detailed documentation tree.
I'm finding (as I write a perlvar/perldata-like document) that things
are so interconnected that it's hard to come up with a fairly flat
structure. Therefore, I'm suggesting this structure. (The first one is
very fleshed-out because I've thought a lot about how to structure it.)
Variables and Subroutines
Basic Data Types
Scalars
Arrays
Hashes
Subroutines
Variable Names
Sigils
The Rest
Subscripting and Calling
Retrieving Array Elements
Individual Elements
Slices
Retrieving Hash Elements
Individual Elements
Slices
Calling Subroutines
Multi-Dimensional Arrays and Hashes
MD Arrays
MD Hashes
References: Simulating Mixed MD
Contexts
List Contexts
Array Context
N-ary Context
Hash Context
Scalar Contexts
String Context
Numeric Context
Boolean Context
(whatever else) Context
Void Context
Creating A Context
Implicit Ways
scalar() and list()
context()
Detecting The Context
Declaring Variables
Global
Lexical
Declaring Subroutines
Unprototyped
Prototyped
Typed Variables
Reference Types
Context Types
Compact Types
References
Taking References
Dereferencing References
Testing References
Why Use References?
Autovivification
Soft References
Properties
Names, Variables and Values
Names
Variables
Values
Variable and Value Properties
Variable Properties
Value Properties
Tainting
Reference: Reference Types
Reference: Context Types
Reference: Compact Types
Reference: Variable Properties
Subroutines
Scalars, Arrays and Hashes
Reference: Value Properties
Operators and Built-In Functions
Expressions and Statements
Operators
Unary
Binary
Hyper-Operators
Built-In Functions
Pattern Matching
Modules and Classes
Modules
Classes
Grammars
Standard Library
Pragmas
IO
...
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
> Hm. I'm not sure how well it goes with the Perl philosophy ("the perl
> language is what the perl interpreter accepts"), but we could embed the
> _real_ test cases in whatever formal spec happens. This would be the
> excruciatingly boring document only read by people trying to implement
> perl6. I don't think real tests, which exercise specific corner cases,
> mix very well with user-level documentation of any sort.
Yes, we should identify 2 types of tests: those that explore user-centric
corner cases; and those that explore implementation-centric corner cases.
User-centric tests are "real", but they aren't "unit-tests".
One of the goals of perl6 is to create a reasonably regular languages --
without too many exceptions to exceptions of a context-specific rule. ;). If
this goal is attained, then there won't be too many user-visible corner
cases ... so the document won't be too tedious.
The perl6.documentation project should focus on these user-centric tests. It
is possible (likely) that people creating these tests will find things to
spill over onto the implementation-tests; but that probably shouldn't be a
goal of the documentation.
Dave.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
"Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message > One thing the "golden-output" has going for it is that it gets into and > out of perl6 as quickly as possible. In other words, it relies on > perl6/parrot to do just about the minimum required of it, then passes > verification off to outside tools (e.g. perl5). I realize they can be > fragile, but at least for the moment, we can't rely on a complete > perl6 Test::Foo infrastructure, and I think that in general, we > _shouldn't_ require such a thing for the very basic tests. Because if we > do, and something basic is broken, all the tests will break because of it, > making the bug-hunter's job much more difficult. I see where you are coming from ... but is the IO infrastructure really the most primitive thing to rely on? It may be at the moment; but I expect that it will become more complex. C may be a built-in right now; but it should probably move to a module later. If we can't rely on C to kill a test (and C; then things are pretty badly broken (assuming that C exists). If we are going to pick a very small subset on which almost all tests will depend ... isn't it better to pick the test-infrastructure itself to be that dependency; rather that some arbitrary module (like IO). Dave.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Sean O'Rourke wrote:
documentation, not code. An obvious question is how to extend it to be a
more thorough test, whilst not spoiling the documentation. We'd want to
intersperse text with the test-code; and probably mark a few bits as
"hidden", from a normal documentation view (levels of hiding might be
defined for overview vs. reference vs. guru levels of understanding).
Hm. I'm not sure how well it goes with the Perl philosophy ("the perl
language is what the perl interpreter accepts"), but we could embed the
_real_ test cases in whatever formal spec happens. This would be the
excruciatingly boring document only read by people trying to implement
perl6. I don't think real tests, which exercise specific corner cases,
mix very well with user-level documentation of any sort.
I agree with that. take the example of reverse (array) in this thread.
Really, the testing should have a number of other tests to be complete,
including thorough testing of boundary conditions.
e.g. - tests of reverse on
0. undef
1. Empty list
2. (0..Inf) - Error ?
3. Mixed data types
4. Complex data types
5. Big (long) lists
6. Big (individual items) lists
7. Array References
8. Things that should raise a compile-time error
9. Things that should raise a run-time error
This gets pretty boring in main documentation.
Writing a complete test suite really also needs reasonable knowledge
of how the internals are written in order to understand the kinds of
tests that are likely to provoke errors. (More thoughts on this if requested).
A related issue is that test ordering should relate to implementation.
E.g. if reverse is implemented as "copy to a new array and then do in
place reverse", then "copy to a new array" should be tested first.
R.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Dave Whipp wrote: "Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message > One thing the "golden-output" has going for it is that it gets into and out of perl6 as quickly as possible. In other words, it relies on perl6/parrot to do just about the minimum required of it, then passes verification off to outside tools (e.g. perl5). I realize they can be fragile, but at least for the moment, we can't rely on a complete perl6 Test::Foo infrastructure, and I think that in general, we _shouldn't_ require such a thing for the very basic tests. Because if we do, and something basic is broken, all the tests will break because of it, making the bug-hunter's job much more difficult. I see where you are coming from ... but is the IO infrastructure really the most primitive thing to rely on? It may be at the moment; but I expect that it will become more complex. C may be a built-in right now; but it should probably move to a module later. A module? For something as basic as print? I hope not, that would certainly be a pain. If we can't rely on C to kill a test (and C; then things are pretty badly broken (assuming that C exists). I think the point that Sean was trying to make was that for some kind test infrastructre to be available to Perl 6 to test Perl 6 with, it would have to be implemented in Perl6 first. The problems with this are: 1.) Perl 6 at the moment is *extremely* slow. This has much to do with the huge grammar PRD has to handle, but why make the testing any slower than it already is? 2.) If there is a problem with some part of the compiler that the testing mechanism was built with, it will break the testing mechanism. This will needlessly break all of the tests, and could be very painful to debug. If we are going to pick a very small subset on which almost all tests will depend ... isn't it better to pick the test-infrastructure itself to be that dependency; rather that some arbitrary module (like IO). Dave. Well, the P6C print implementation is as basic as it gets; all it does is take a list of arguments, loop through them, and call parrot's print op on them. Although the full implementation will be more complex (as it will have to handle printing to filehandles other than stdout), the testing implementation won't have to deal with that. However, assert is bound to be more complex, since it will have to handle and compare many different types of data structures.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
On Mon, Nov 11, 2002 at 05:43:01PM -0800, Dave Whipp wrote: > "Sean O'Rourke" <[EMAIL PROTECTED]> wrote in message >> One thing the "golden-output" has going for it is that it gets into >> and out of perl6 as quickly as possible. In other words, it relies on >> perl6/parrot to do just about the minimum required of it, then passes >> verification off to outside tools (e.g. perl5). I realize they can be >> fragile, but at least for the moment, we can't rely on a complete >> perl6 Test::Foo infrastructure, and I think that in general, we >> _shouldn't_ require such a thing for the very basic tests. Because if >> we do, and something basic is broken, all the tests will break >> because of it, making the bug-hunter's job much more difficult. > > I see where you are coming from ... but is the IO infrastructure > really the most primitive thing to rely on? It may be at the moment; > but I expect that it will become more complex. C may be a > built-in right now; but it should probably move to a module later. I/O is fairly fundamental, particularly for a language as heavily into being glue as perl. I can't see it not being core. > If we can't rely on C to kill a test (and C then things are pretty badly broken (assuming that C exists). Perl's tests are built on Test::More, it uses ok() and is() not assert(). If we're going to be doing test cases for perl 6 then we should do them using perl's standard testing format (i.e. Test::More, Test::Harness, etc.) > If we are going to pick a very small subset on which almost all tests > will depend ... isn't it better to pick the test-infrastructure itself > to be that dependency; rather that some arbitrary module (like IO). If your program can't do basic I/O it's probably pretty broken. Even if we we're to only rely on the test modules, they also need to be able to communicate with the outside world. andrew -- Aries: (March 21 - April 19) You'll soon find yourself in the midst of a power struggle, as two corrupt and ruthless families fight for control of a small town. Whatever you do, don't trust the drunken undertaker.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
"Joseph F. Ryan" <[EMAIL PROTECTED]> wrote in message news:3DD0674C.1080708@;osu.edu... > A module? For something as basic as print? > I hope not, that would certainly be a pain. My understanding is that C will be a method on C (or whatever), which has a default invocant of $stdout. This module might be included automatically, so users don't need to know about it. Anyway, calling C "basic" is a very biased point of view. Its the viewpoint of someone who knows how things are implemented. > >If we can't rely on C to kill a test (and C; > >then things are pretty badly broken (assuming that C exists). > > > > I think the point that Sean was trying to make was that for some kind test > infrastructre to be available to Perl 6 to test Perl 6 with, it would have > to be implemented in Perl6 first. The problems with this are: > > 1.) Perl 6 at the moment is *extremely* slow. This has much to do with > the huge grammar PRD has to handle, but why make the testing any slower > than it already is? > > 2.) If there is a problem with some part of the compiler that the testing > mechanism was built with, it will break the testing mechanism. This > will needlessly break all of the tests, and could be very painful to debug. I think it would be a mistake to assume that we can't use a testing infrastructure for tests. Sure, there need to be some implementation-centric unit tests that depend on almost nothing: but those tests should be run as a guard around a main regression (i.e. a regression script should say "do clean checkout; run sanity checks; if OK, then run regression"). If C fails, then things are broken. It is also a mistake to base the decision on the fact that perl is currently too slow. This will be fixed: performance of dispatch will be crucial all perl scripts, not just tests. > >If we are going to pick a very small subset on which almost all tests > >will depend ... isn't it better to pick the test-infrastructure itself to be > >that dependency; rather that some arbitrary module (like IO). > > Well, the P6C print implementation is as basic as it gets; all it > does is take a list of arguments, loop through them, and > call parrot's print op on them. Although the full implementation will > be more complex (as it will have to handle printing to filehandles other > than stdout), the testing implementation won't have to deal with that. > However, assert is bound to be more complex, since it will have to handle > and compare many different types of data structures. This feels like a false augment (even if the conclusions are true). Contrast: C takes a single arg, and evaluates it in boolean context. It if the result is false, then execution terminates. OTOH, C takes a list of args; iterates through them, and calls a polymorphic (in parrot) method on each. If I make a primitive assert op in parrot, then the perl implementation is rather basic. assert_equal is a bit more complex. But the complexity can be structured. We don't need, initially, to implement heterogeneous comparisons, for example. At a more detailed level: a test that compares integers doesn't need strcmp to work. You seem to be concerned about a boot-strapping problem. I want to make the assumption that there is a level of functionality below which it is pointless to run user-level tests. Dave.
Re: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
"Andrew Wilson" <[EMAIL PROTECTED]> wrote > Perl's tests are built on Test::More, it uses ok() and is() not > assert(). If we're going to be doing test cases for perl 6 then we > should do them using perl's standard testing format (i.e. Test::More, > Test::Harness, etc.) I would argue that we should write our tests using perl6's standard format -- and we need to define that format. There may be a good argument for using the perl5 standards; but we should explore the alternatives. "assert" is a generally accepted term: I'm not sure why perl should be different. > If your program can't do basic I/O it's probably pretty broken. Even if > we we're to only rely on the test modules, they also need to be able to > communicate with the outside world. My day-job is ASIC verification: in a previous job I tested microprocessor cores. We generally found mechanisms to communicate pass/fail without requiring any IO capability. A common method is to use the programm counter -- if we execute the instruction at address 0x123456, then exit as a PASS; if we reach 0x654321, then fail. (we used the assembler to get the addresses of specific pass/fail labels). We don't need to go to these extremes for perl testing, because we have an exit(int) capability. exit(0) means pass: anything else (including timeout) is a fail. The fact that we don't need C is not a good argument for not using it. Perl tests should assume that Parrot works! 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: HOWTO: Writing Perl6 Tests (was: Project Start: Section 1)
Dave Whipp wrote: "Andrew Wilson" <[EMAIL PROTECTED]> wrote The fact that we don't need C is not a good argument for not using it. Perl tests should assume that Parrot works! Right, so whats wrong with using one of parrot's most basic ops? Thats all perl6 print is; a small wrapper around a basic parrot feature. -- Joseph F. Ryan
[perl #18336] [PATCH] Segfault in PIO_destroy
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #18336]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18336 >
System: Solaris 2.8 (SunOS 5.8), UltraSPARC.
Source: CVS snapshot parrot_2002-11-12_00.tar.gz
Perl: 5.6.1 built with Sun cc.
Did perl Configure.pl and make as in the README. Ran "./parrot", got
expected options help, and a core dump. Tried "./parrot -j", typed some
data and ^D and also got a core dump. Ran dbx on the core, stack trace
showed that it was in mem_sys_free called from PIO_destroy (io/io.c:156
called from Parrot_really_destroy and Parrot_exit). I noticed that
alloc_pio_array wasn't clearing the allocated array of pointers, and
PIO_destroy is freeing all PIO_NR_OPEN (256) of them every time, and figured
that in tests memory happened to be zeroed so this was never caught. HTH,
I'd like to get more involved with Parrot.
Dave
Isa. 40:31
-- attachment 1 --
url: http://rt.perl.org/rt2/attach/41470/33354/96560c/parrot-patch-2002
diff -u io/old_io.c io/io.c
--- io/old_io.c 2002-11-11 22:33:35.311264000 -0600
+++ io/io.c 2002-11-11 22:33:57.654252000 -0600
@@ -64,7 +64,7 @@
{
ParrotIOTable newhandles;
size_t size = numhandles * sizeof(ParrotIO *);
-newhandles = (ParrotIOTable)mem_sys_allocate(size);
+newhandles = (ParrotIOTable)mem_sys_allocate_zeroed(size);
return newhandles;
}
Parrot BASIC 2
I sat around trying to think of a witty, pithy way to make this announcement more surreal or frightening than it really is and failed. So I guess I'll let it stand on it's own. I've just completed a complete re-write of BASIC for Parrot. This time I've used QuickBASIC as a model which means there's all kinds of new features, and it's a much friendlier language to work with. It's not complete, but a few tutorials that I found for QuickBASIC can be completed with this compiler. If you're interested, you can get the bundle at http://geeksalad.org/basic/basic2.zip and eventually I suppose I'll hack it into the languages\basic CVS tree in the Parrot distribution. The compiler itself is rather hideous Perl, but the output and the runtime libraries are all pure PASM. Of interest specifically to p6i: This version *almost* works flawlessly under 0.0.8 from about two weeks ago. There's still some memory issues and large programs (like newtrek.bas) that run long enough will segfault. So right now the RT_initialize.pasm file has "collectoff" and "sweepoff" statements and that seems to avoid the symptom. Enjoy. :) From the README file: -- Parrot BASIC 2.0 What is it? It's an implementation of BASIC in Parrot. Unlike version 1, this is modeled after Microsoft's QuickBASIC version 4.5. A quick list of features: * It's compiled directly to Parrot Assembly (PASM) and not interpreted. * Richer syntax than Parrot BASIC 1.0, which was modeled after GW-BASIC * Much, much faster than Parrot BASIC 1.0 * Support for user-defined types * Support for variable scopes+ (+ QB has bizarre ideas of scope. Caveat Programmer.) I couldn't find a proper book on QuickBASIC, and believe it or not Google wasn't terribly helpful in finding a good manual. I did have a QB.exe and a few help files for information. What's missing? The things that are missing fall into three classes. "Someday I'll do these, there's hooks for it but I need a break now." * Keywords: defint const static ubound * SHARED in DIM statements * Exception handling * The keyword USING * The "* length" modifier for strings * Forward-declarations (DECLARE) are missing. For now, your DIM's and functions must by defined before they're used. * DEF FN. It's a special case of FUNCTION. "These are *hard* and I may not do them, ever" * Keywords: common chain bload bsave cseg "These are nearly impossible given where Parrot is now. maybe when the I/O gets rounded out and some libraries get added. Like graphics, sound, and filesystem access." * Keywords: screen pset preset line circle draw view window pmap color palette paint get put pcopy beep sound locate view width resume pos poke peek rset * Most directory manipulations * Record (binary) I/O And I probably have a whacked idea of I/O in QuickBASIC anyway. What's incomplete? Mostly the File I/O stuff. Surprisingly, basic file I/O is working properly. See test #47. What's a hack? Dirty little secrets of PB2; some good, some bad: * single/double are simply Parrot Nx registers * int/long are simply Parrot Ix registers * Everything is case insensitive. * Arrays are really hashes. Yes, "foo(a$)" is now legal BASIC. I'll sneak a "keys()" function into BASIC eventually... * Other bad syntax is forgiven or Something Interesting happens * The _STARTASM directive lets you put PASM in your BASIC code. (see testsuite.pl for an example) * I couldn't wrap my brain around BASIC's scoping to write the expression evaluator properly. It's a kind of dynamic scoping that hurts my head. So the expression evaluator is a postfix machine. * The DIM statement doesn't really need to indicate any kind of size at all. DIM a$(1) will set aside a$ as any n-dimension array of any size. * The random number generator is *intentionally* seeded with a constant to make testing easier. Use "randomize timer" to mix things up. How do I get going? Quickstart? 1. Edit "testrun.pl" and change the pathname at the beginning of the script to wherever parrot is. 2. Type "compile.pl wumpus2.bas" This produces "TARG_test.pasm" and "TARG_localfuncs.pasm" 3. Type "testrun.pl" and enjoy. eliza2 and wumpus2 are simply ports from the Parrot BASIC 1.0 version. All that had to be done were to add DIM statements and a RANDOMIZE. See the notes below for more examples. Where's the advanced syntax stuff? Once you've fixed "testrun.pl" as noted above, the script "testsuite.pl" will run BASIC through its self-tests. If you look through the script there's examples of almost every kind of syntax that I've got working. What are all of these files? RT_* Runtime Libraries. Things like the expression evaluator and builtin functions (add, sub, mul, sin, cos, etc..) COMP_* The compiler itself. Please, oh please don't look at this Perl code. It's terrib
Re: Unifying invocant and topic naming syntax
> > method f ($self : $a) { ... }
> > sub f ($a) is given ($line) { ... }
> >
> > what do you call $self
>
> The "invocant".
>
> > and $line?
>
> A lexical variable that happens to be
> bound to the caller's topic.
The "invokit" perhaps?
> placeholders create subroutines, not methods.
Oh.
Are placeholders only usable with anonymous
subs, or named subs too?
Switching briefly to currying, can one curry
a method?
--
ralph
RE: Autovivification
--
On Mon, 11 Nov 2002 13:02:12
Brent Dax wrote:
>Erik Steven Harrison:
># >I think that, if Perl can determine the type with virtually no
># >ambiguity, it should autovivify.
>#
># Actually, this behavior has already (mostly) been decided over in P6
># language. It was decided (and I agree) that the Perl 5 behavior of
>
>Can you give me a link or a thread name or something?
No, because I am crazy and hallucinated it. I turned a
thread on autovification of read only values and then
filled in my own, biased opinion. Consider my right to
post removed.
>
># autovivifying references to the basic data types is the incorrect
># behavior, leading to a lot of bugs when dealing wityh complex data
># structures. So no autovifiying an untyped $undefined_var[$foo]
>
>Why? It's pretty obvious that you want an array, and the normal array
>Perl 6 provides is a good default.
>
>If this is the case, why should we allow C or C<[qw(anon
>array)]> without a type? After all, they might *really* want a
>different type of array!
I always liked that Perl would autovivify references
if I assumed that the data was there. And then I
actually started to write some complex (for me at the
time) tree walking code, only to mangle the structure.
A few slips in a for loop, and boom, the whole thing
fritzed.
But then, I'm a self taught hobbyist. So I may not be
the population we need to play to.
>
>My understanding was that Perl 6 is not abandoning the DWIM principle.
>When did this change?
>
>(Sorry if this sounds like I'm attacking you. I'm not--I'm just
>attacking your opinion. :^) )
Oh good. My opinion has been getting uppity lately. This should put it in line. :-)
-Erik
>--Brent Dax <[EMAIL PROTECTED]>
>@roles=map {"Parrot $_"} qw(embedding regexen Configure)
>
>Wire telegraph is a kind of a very, very long cat. You pull his tail in
>New York and his head is meowing in Los Angeles. And radio operates
>exactly the same way. The only difference is that there is no cat.
>--Albert Einstein (explaining radio)
>
>
Get 25MB of email storage with Lycos Mail Plus!
Sign up today -- http://www.mail.lycos.com/brandPage.shtml?pageId=plus
Re: HOWTO: Writing Perl6 Tests
Michael Lazzaro wrote: > Allison, if you could arrange an official liaison on p6i that could > direct (in a definitive, buck-stops-here way) authors' efforts w/ > regard to how perl6-specific tests should be written, we would be > grateful. We seem to have a decent number of people here willing to do > it, if they get some tutoring to start out. I propose chromatic for this task. I'll get back to you with details. Allison
Re: Project Start: Section 1
Luke Palmer wrote: I very much dislike XML for writing. It'd be nice to use some kind of "extended POD" or something. Something that's mostly content, little structure. Formats with a lot of structure tend to be unproductive, and although the structure is useful, much of it is redundant and can be bypassed by a processor that's just a little smarter. +1 (x10) I like the idea of using an extended POD. -Carlos
RE: Project Start: Section 1
Michael Lazzaro:
# On Monday, November 11, 2002, at 05:08 AM, Angel Faus wrote:
# >> I very much dislike XML for writing. It'd be nice to use some kind
# > I agree with you. XML is very unpleasant to write.
#
# I certainly agree with that, but I was thinking of something
# very basic
# -- just enough to get it into a database, for example. You'd
# just copy
# a standard template and fill in the fields. Like perhaps:
#
#
# 1.1.2.1
# Numeric Context
#
# Numeric Context is a context full of cheesy
# goodness. For
# example, the following code will put $obj in int
# context:
#
# my int $i = $obj;
#
# blah blah blah ...
#
#
# Context
# Numeric Values
#
#
# ...
#
#
What's wrong with this?
=section 1.1.2.1 Numeric Context
Numeric Context is a context full of cheesy goodness. For example, the
following code will put C<$obj> in C context:
my int $i = $obj;
blah blah blah...
=seealso Context
=seealso Numeric Values
=tests
That's 14 lines to XML's 23 (XML is nearly twice as many lines!), and
the POD is much less cluttered.
You're probably looking at that and wondering, "what about the
glossary?" Well, cross-referencing glossary entries is just this in
Perl 6:
$text =~ s:each / (%glossary_entries) /$1/;
Where %glossary_entries's values are a unique entry ID of some sort.
And if that's not easy enough for you, you can always add a G
construct, or even use L.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Wire telegraph is a kind of a very, very long cat. You pull his tail in
New York and his head is meowing in Los Angeles. And radio operates
exactly the same way. The only difference is that there is no cat.
--Albert Einstein (explaining radio)
Re: branch dump
Angel Faus wrote: Hmm wouldn't the JIT benifit from a pre knowledge of basic blocks and types or some information ? ... (I seem to think so ...). I would think so, because if, for example, the JIT wants to do a full register allocation to map parrot registers to machine registers, it would certainly need information about basic blocks. JIT doese register allocation already, but not per basic block (which JIT has too). Allocation is more fine grained per JITed sections, which are either basic blocks, or consist of JITed code only. On the other hand, the JIT could certainly regenerate this information from the imc code, which is probably going to be stored somewhere anyway. But right, IMCC could help here by e.g. assigning registers with top down priority I0, I1, In ... could be the top N used registers for this block, which JIT just remapps to processor registers. Calling externl (non JITed code) would still need to load/restore these. -angel leo
Re: Quick roadmap
Dan Sugalski wrote: ... These are the things going in, and in the order they're going in: Could you comment on current unresolved issues: - string_set, reusing string headers - the inconsistencies in the PASM examples, especially the last one in this thread: "[CVS ci] string_set is back for a faster live - not only" and a general roadmap considering: - subject "Parrot 0.0.9" - Buffer/PMC unification - var/value vtable split thanks, leo
