Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
Early on in the life of Perl 5 Larry adopted the convention that subroutines that Perl calls automatically for you should have all-caps names[*]. I'm not uncomfortable with the apparent try/CATCH inconsistency. I suspect that having CATCH etc. be lowercase would create a greater inconsistency in the 'big picture'. (Plus you'd get into problems with NEXT vs next etc.) Tim. [*] Historical note: This actually came about partly because the DBI ties a hash ref into the same class that the hash is blessed into. Perl's tie FETCH method used to be called fetch, but that clashed with the DBI's own fetch method. On Tue, Jan 22, 2002 at 05:40:47PM +, Andy Wardley wrote: > I was reading Apocalypse 4 and was perturbed by the strange and inconsistent > looking use of UPPER and lower case in various keywords. > > Now before anyone rushes to assist me in understanding the logic, I should > say that we've already thrashed this out on the London.pm mailing list and > several people (Hi Piers :-) have re-iterated the reasoning being the use > of upper vs lower case. > > In a nutshell, UPPER CASE is reserved for special Perl blocks that should > stand out to the user due to the fact that they represent exception flow > control. > > It's a good, logical and consistent argument for sure, but sorry, I don't > buy it. We end up with peculiarities like 'try/CATCH'. Even if 'try' > is a keyword and 'CATCH' is a special block, I can't see any valid reason > for having them different case. Same with 'last/NEXT' - they're so similar > in concept that the implementation details should not matter. > > By this argument, I could claim that the correct capitalisation of "knife > and FORK" is based on the rule "cutting things are in lower case, spiking > things are in UPPER CASE". It's consistent and logical, but common sense > should tell you that it's plain wrong. > > INIT, DESTROY, AUTOLOAD, etc., all make sense to me. They really are > special blocks that normally only occur once in a file. But CATCH and > NEXT are part of normal syntax. I don't think they're any more "unusual" > in their flow control than try, while, loop or foreach. > > I think this needs a rethink. What do other people think? > > A >
Re: Some Apocalypse 4 exception handling questions.
On Tue, 22 Jan 2002 10:03:08 -0800 (PST), Larry Wall wrote:
> At the moment, I see this:
>
> -2. PRE in order, inherited, no side effects
> -1. FIRST in order
> 0. inline code normal flow
> 1. CATCH, CONTROLsingular
> 2. NEXT, LAST, KEEP, UNDOin reverse order
> 3. POST in reverse order, inherited, no side effects
This is all very sensible, and I completely agree with it. However, don't we
need some restrictions on what can go in PRE and POST blocks to ensure that
they are still valid in inherited methods?
class A;
sub foo($bar,$baz){
PRE{ $bar<10 }
my $qux=$baz;
POST{ $qux==$baz }
}
class B is base(A); # I forget the syntax for inheritance
sub foo($x,$y){
# Insert any old random code here
}
Presumably, PRE/POST blocks will only be able to access their sub's
arguments, since the derived class' sub may not declare the same variables
as the base class (see $qux above). Or, maybe you just can't inherit from
methods with such conditions, but I think that's putting the restriction in
the wrong place. Or, you only inherit conditions which are inheritable, but
that defeats the whole scheme.
Also, these references have to be compiled into accesses to the argument
list, rather than to the lexicals, otherwise they won't be any use at all to
the derived class. Of course, this might be how references to sub arguments
are compiled anyway, in which case there's no problem.
--
Peter Haworth [EMAIL PROTECTED]
"Master, does Emacs have the Buddha nature?" the novice asked.
The Chief Priest had been in the temple for many years and could be
relied upon to know these things. He thought for several minutes before
replying, "I don't see why not. It's got bloody well everything else."
RE: Some Apocalypse 4 exception handling questions.
Peter Haworth [mailto:[EMAIL PROTECTED]] wrote: > This is all very sensible, and I completely agree with it. > However, don't we > need some restrictions on what can go in PRE and POST blocks > to ensure that they are still valid in inherited methods? There's another issue: sometimes we don't want to inherit PRE conditions. DBC allows a derived method to strengthen (add) post-conditions; but to weaken (remove) preconditions. I haven't (yet) seen how this weakening would be accomplished. Perhaps the mechanism that controls inheritance of preconditions may have a more general applicability? Dave.
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote: > Early on in the life of Perl 5 Larry adopted the convention that > subroutines that Perl calls automatically for you should have > all-caps names[*]. Not early enough to catch import() though. Oh well ... Perl 6 will fix that. (For various definitions of "fix" ;-) > I'm not uncomfortable with the apparent try/CATCH inconsistency. Same here. People are just used to try/catch from other languages that are philisophically bent different. That just makes try/CATCH inconsistent with those languages, not with Perl. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
[PATCH] Ok this has bugged me long enough
test_main needed an overhaul on options handling, and if/then/else was
breeding like rabbits. This one is 41 lines shorter and easier to read.
Please test before I commit.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.36
diff -u -r1.36 test_main.c
--- test_main.c 22 Jan 2002 00:53:35 - 1.36
+++ test_main.c 23 Jan 2002 19:49:56 -
@@ -27,6 +27,7 @@
int from_stdin;
int from_file;
char *filename;
+char **argp;
struct Parrot_Interp *interpreter;
init_world();
@@ -40,10 +41,10 @@
** -p profiling
** -P predereferencing
** -t tracing
+** -f filename or stdin
**
-** We really should use getopt, but are we allowed?
*/
-
+argp = argv+1;
flags= 0;
bounds_checking = 0;
profiling= 0;
@@ -55,102 +56,60 @@
from_file= 0;
filename = NULL;
-while (argc > 1 && argv[1][0] == '-') {
-if (argv[1][1] == 'b' && argv[1][2] == '\0') {
-bounds_checking = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'j' && argv[1][2] == '\0') {
-jit = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'p' && argv[1][2] == '\0') {
-profiling = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'P' && argv[1][2] == '\0') {
-predereferencing = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 't' && argv[1][2] == '\0') {
-tracing = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'd' && argv[1][2] == '\0') {
-debugging = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'f') {
-if (strcmp("-", argv[2]) == 0) {
-from_stdin = 1;
-}
-else {
-filename = malloc(strlen(argv[2])+1);
-filename = strcpy(filename, argv[2]);
-}
-for (i = 3; i < argc; i++) {
-argv[i-2] = argv[i];
-}
-argc -= 2;
+while (*argp && (*argp)[0] == '-') {
+if((*argp)[2] != '\0')
+internal_exception(PARROT_USAGE_ERROR,
+"%s: Invalid switch: %s\n", argv[0], (*argp));
+
+switch((*argp)[1]) {
+case 'd': debugging = 1;
+argp++; break;
+case 'b': bounds_checking = 1;
+argp++; break;
+case 'j': jit = 1;
+argp++; break;
+case 'p': profiling = 1;
+argp++; break;
+case 'P': predereferencing = 1;
+argp++; break;
+case 't': tracing = 1;
+argp++; break;
+case 'f': argp++;
+printf("-f flag\n");
+if(strcmp("-", (*argp)) == 0) {
+from_stdin = 1;
+} else {
+filename = malloc(strlen((*argp))+1);
+filename = strcpy(filename, (*argp));
+}
+argp++; break;
+default:
+internal_exception(PARROT_USAGE_ERROR,
+"%s: Invalid switch: %s\n",
+argv[0], (*argp));
}
-else {
-internal_exception(PARROT_USAGE_ERROR, "%s: Invalid switch:
%s\n", argv[0], argv[1]);
-}
}
+flags |= (debugging == 1 ? PARROT_DEBUG_FLAG : 0);
+flags |= (profiling == 1 ? PARROT_PROFILE_FLAG : 0);
+flags |= (bounds_checking == 1 ? PARROT_BOUNDS_FLAG : 0);
+flags |= (jit == 1 ? PARROT_JIT_FLAG : 0);
+flags |= (predereferencing == 1 ? PARROT_PREDEREF_FLAG : 0);
+flags |= (tracing == 1 ? PARROT_TRACE_FLAG : 0);
-if (debugging) {
+if(debugging)
fprintf(stderr, "Parrot VM: Debugging enabled.\n");
-flags |= PARROT_DEBUG_FLAG;
-}
-if (bounds_checking) {
-flags |= PARROT_BOUNDS_FLAG;
-}
-
-if (jit) {
#if !JIT_CAPABLE
- internal_exception( JIT_UNAVAILABLE, "%s: Cannot use the '-j'
JIT-enabling flag on this architecture: " JIT_ARCHNAME "\n", argv[
Re: [PATCH] Ok this has bugged me long enough
Eek, don't apply that, I see a bug, I'll post a new one in a sec. -Melvin At 02:52 PM 1/23/2002 -0500, Melvin Smith wrote: >test_main needed an overhaul on options handling, and if/then/else was >breeding like rabbits. This one is 41 lines shorter and easier to read. > >Please test before I commit. > >-Melvin > > >Index: test_main.c >===
[PATCH] Replacement patch for test_main
Modified version of last patch. Fixed in case -f flag wasn't provided a
file or "-" arg.
-Melvin
Index: test_main.c
===
RCS file: /cvs/public/parrot/test_main.c,v
retrieving revision 1.36
diff -u -r1.36 test_main.c
--- test_main.c 22 Jan 2002 00:53:35 - 1.36
+++ test_main.c 23 Jan 2002 20:02:12 -
@@ -27,6 +27,7 @@
int from_stdin;
int from_file;
char *filename;
+char **argp;
struct Parrot_Interp *interpreter;
init_world();
@@ -40,10 +41,10 @@
** -p profiling
** -P predereferencing
** -t tracing
+** -f filename or stdin
**
-** We really should use getopt, but are we allowed?
*/
-
+argp = argv+1;
flags= 0;
bounds_checking = 0;
profiling= 0;
@@ -55,102 +56,63 @@
from_file= 0;
filename = NULL;
-while (argc > 1 && argv[1][0] == '-') {
-if (argv[1][1] == 'b' && argv[1][2] == '\0') {
-bounds_checking = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'j' && argv[1][2] == '\0') {
-jit = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'p' && argv[1][2] == '\0') {
-profiling = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'P' && argv[1][2] == '\0') {
-predereferencing = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 't' && argv[1][2] == '\0') {
-tracing = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'd' && argv[1][2] == '\0') {
-debugging = 1;
-for(i = 2; i < argc; i++) {
-argv[i-1] = argv[i];
-}
-argc--;
-}
-else if (argv[1][1] == 'f') {
-if (strcmp("-", argv[2]) == 0) {
-from_stdin = 1;
-}
-else {
-filename = malloc(strlen(argv[2])+1);
-filename = strcpy(filename, argv[2]);
-}
-for (i = 3; i < argc; i++) {
-argv[i-2] = argv[i];
-}
-argc -= 2;
+while (*argp && (*argp)[0] == '-') {
+if((*argp)[2] != '\0')
+internal_exception(PARROT_USAGE_ERROR,
+"%s: Invalid switch: %s\n", argv[0], (*argp));
+
+switch((*argp)[1]) {
+case 'd': debugging = 1;
+argp++; break;
+case 'b': bounds_checking = 1;
+argp++; break;
+case 'j': jit = 1;
+argp++; break;
+case 'p': profiling = 1;
+argp++; break;
+case 'P': predereferencing = 1;
+argp++; break;
+case 't': tracing = 1;
+argp++; break;
+case 'f': if(*(++argp) == NULL)
+internal_exception(PARROT_USAGE_ERROR,
+"%s: -f requires an argument\n",
+argv[0]);
+
+if(strcmp("-", (*argp)) == 0) {
+from_stdin = 1;
+} else {
+filename = malloc(strlen((*argp))+1);
+filename = strcpy(filename, (*argp));
+}
+argp++; break;
+default:
+internal_exception(PARROT_USAGE_ERROR,
+"%s: Invalid switch: %s\n",
+argv[0], (*argp));
}
-else {
-internal_exception(PARROT_USAGE_ERROR, "%s: Invalid switch:
%s\n", argv[0], argv[1]);
-}
}
+flags |= (debugging == 1 ? PARROT_DEBUG_FLAG : 0);
+flags |= (profiling == 1 ? PARROT_PROFILE_FLAG : 0);
+flags |= (bounds_checking == 1 ? PARROT_BOUNDS_FLAG : 0);
+flags |= (jit == 1 ? PARROT_JIT_FLAG : 0);
+flags |= (predereferencing == 1 ? PARROT_PREDEREF_FLAG : 0);
+flags |= (tracing == 1 ? PARROT_TRACE_FLAG : 0);
-if (debugging) {
+if(debugging)
fprintf(stderr, "Parrot VM: Debugging enabled.\n");
-flags |= PARROT_DEBUG_FLAG;
-}
-if (bounds_checking) {
-flags |= PARROT_BOUNDS_FLAG;
-}
-
-if (jit) {
#if !JIT_CAPABLE
- internal_exception( JIT_UNAVAILABLE, "
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote: : :On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote: :> Early on in the life of Perl 5 Larry adopted the convention that :> subroutines that Perl calls automatically for you should have :> all-caps names[*]. : :Not early enough to catch import() though. Oh well ... Perl 6 will :fix that. (For various definitions of "fix" ;-) import() is not called automatically by Perl. It's called automatically by the module Exporter.pm. Subtle but important difference there. Casey West -- Shooting yourself in the foot with Mach The bullets work pretty well, but they don't make guns for it any more.
Re: Apocalypse 4 : The Strange Case of the STRANGE CASE
On Wed, Jan 23, 2002 at 03:21:37PM -0500, Casey West wrote: : :On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote: :: ::On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote: ::> Early on in the life of Perl 5 Larry adopted the convention that ::> subroutines that Perl calls automatically for you should have ::> all-caps names[*]. :: ::Not early enough to catch import() though. Oh well ... Perl 6 will ::fix that. (For various definitions of "fix" ;-) : :import() is not called automatically by Perl. It's called :automatically by the module Exporter.pm. Subtle but important :difference there. My bad, that's wrong. I think what my brain wanted to say is that it is lowercase because Exporter.pm came before use() or something like that. Where was my morning coffee hiding today? Casey West -- Shooting yourself in the foot with Cray You shoot yourself in the foot with an Uzi.
RE: Apocalypse 4 : The Strange Case of the STRANGE CASE
Casey West:
# On Wed, Jan 23, 2002 at 01:45:44PM -0600, Jonathan Scott Duff wrote:
# :
# :On Wed, Jan 23, 2002 at 11:50:54AM +, Tim Bunce wrote:
# :> Early on in the life of Perl 5 Larry adopted the convention that
# :> subroutines that Perl calls automatically for you should have
# :> all-caps names[*].
# :
# :Not early enough to catch import() though. Oh well ... Perl 6 will
# :fix that. (For various definitions of "fix" ;-)
#
# import() is not called automatically by Perl. It's called
# automatically by the module Exporter.pm. Subtle but important
# difference there.
Nope. 'use Foo;' is translated to 'BEGIN {require Foo; import Foo;}' by
Perl; Exporter just provides a default implementation of import().
--Brent Dax
[EMAIL PROTECTED]
Parrot Configure pumpking and regex hacker
. hawt sysadmin chx0rs
This is sad. I know of *a* hawt sysamin chx0r.
I know more than a few.
obra: There are two? Are you sure it's not the same one?
resend: schemepair.patch
Ok, here is the updated schemepair-patch.
The diff is agains a fresh update of anoncvs and should hopefully apply
clean.
A Pair is implemented as an array with exact 2 elements. This elements
may be PMC values, especially other Pairs. The car-element is index 0,
the cdr-element is index 1.
Lists are nested pairs with PerlUndef as end-of-list-marker. Maybe I
should introduce a new PMC-type for this.
To implement nested pairs its nessary to introduce 2 new vtable functions
and the acompaning core.ops to get and set the PMC value of the indexed
element. I choosed set_p_p_i and set_p_i_p. The later one is inconsistent
with indexed set operations set_p_i_i, set_p_n_i and set_p_s_i.
Maybe this time there is a little bit more discussion
Juergen
? t.s
? boeboe
? pair.diff
? sp.diff
? t.diff
? classes/schemepair.pmc
? languages/scheme/foo.scheme
? languages/scheme/t/lists
Index: MANIFEST
===
RCS file: /cvs/public/parrot/MANIFEST,v
retrieving revision 1.100
diff -u -r1.100 MANIFEST
--- MANIFEST22 Jan 2002 16:01:33 - 1.100
+++ MANIFEST23 Jan 2002 20:21:00 -
@@ -51,6 +51,7 @@
classes/perlstring.pmc
classes/perlundef.pmc
classes/pmc2c.pl
+classes/schemepair.pmc
config_h.in
core.ops
disassemble.pl
@@ -180,6 +181,7 @@
languages/scheme/t/arith/nested.t
languages/scheme/t/harness
languages/scheme/t/io/basic.t
+languages/scheme/t/lists/basic.t
languages/scheme/t/logic/basic.t
make.pl
make_vtable_ops.pl
Index: Makefile.in
===
RCS file: /cvs/public/parrot/Makefile.in,v
retrieving revision 1.120
diff -u -r1.120 Makefile.in
--- Makefile.in 21 Jan 2002 03:25:25 - 1.120
+++ Makefile.in 23 Jan 2002 20:21:01 -
@@ -67,7 +67,8 @@
CLASS_O_FILES = classes/default$(O) classes/perlint$(O) classes/perlstring$(O) \
classes/perlnum$(O) classes/perlarray$(O) classes/perlundef$(O) \
-classes/perlhash$(O) classes/parrotpointer$(O) classes/intqueue$(O)
+classes/perlhash$(O) classes/parrotpointer$(O) classes/intqueue$(O) \
+classes/schemepair$(O)
ENCODING_O_FILES = encodings/singlebyte$(O) encodings/utf8$(O) encodings/utf16$(O) \
encodings/utf32$(O)
Index: core.ops
===
RCS file: /cvs/public/parrot/core.ops,v
retrieving revision 1.80
diff -u -r1.80 core.ops
--- core.ops19 Jan 2002 07:12:53 - 1.80
+++ core.ops23 Jan 2002 20:21:02 -
@@ -516,6 +516,14 @@
Set $1 to index $3 of hash $2
+=item B(out PMC, in INT, in PMC)
+
+Set $1[$2] to $3
+
+=item B(out PMC, in PMC, in INT)
+
+Set $1 to $2[$3]
+
=cut
@@ -574,6 +582,11 @@
goto NEXT();
}
+inline op set(out PMC, in PMC) {
+ $1 = $2;
+ goto NEXT();
+}
+
inline op set(out PMC, in INT, in INT) {
$1->vtable->set_integer_index(interpreter, $1, $2, $3);
goto NEXT();
@@ -604,6 +617,17 @@
goto NEXT();
}
+/* FIXME: Order of arguments diffrent from above */
+inline op set(out PMC, in INT, in PMC) {
+ $1->vtable->set_pmc_index (interpreter, $1, $3, $2);
+ goto NEXT();
+}
+
+inline op set(out PMC, in PMC, in INT) {
+ $1 = $2->vtable->get_pmc_index (interpreter, $2, $3);
+ goto NEXT();
+}
+
inline op set(out PMC, in INT, in STR) {
$1->vtable->set_integer_index_s(interpreter, $1, $2, $3);
goto NEXT();
@@ -2475,6 +2499,28 @@
}
newpmc = pmc_new(interpreter, $2);
$1 = newpmc;
+ goto NEXT();
+}
+
+=item B(out INT, in PMC)
+
+get the type of the PMC C and store it in C
+
+=cut
+
+op get_type (out INT, in PMC) {
+ $1 = $2->vtable->type(interpreter, $2);
+ goto NEXT();
+}
+
+=item B(out STR, in PMC)
+
+get the typename of the PMC C and store it in C
+
+=cut
+
+op get_type (out STR, in PMC) {
+ $1 = $2->vtable->name(interpreter, $2);
goto NEXT();
}
Index: global_setup.c
===
RCS file: /cvs/public/parrot/global_setup.c,v
retrieving revision 1.19
diff -u -r1.19 global_setup.c
--- global_setup.c 22 Jan 2002 01:04:50 - 1.19
+++ global_setup.c 23 Jan 2002 20:21:02 -
@@ -27,6 +27,7 @@
Parrot_PerlHash_class_init();
Parrot_ParrotPointer_class_init();
Parrot_IntQueue_class_init();
+Parrot_SchemePair_class_init();
}
/*
Index: vtable.tbl
===
RCS file: /cvs/public/parrot/vtable.tbl,v
retrieving revision 1.12
diff -u -r1.12 vtable.tbl
--- vtable.tbl 14 Jan 2002 20:18:23 - 1.12
+++ vtable.tbl 23 Jan 2002 20:21:02 -
@@ -58,3 +58,7 @@
unique void logical_notPMC* value
strvoid match PMC* value REGEX* re
strvoid repeat PMC* value PMC* dest
+
+unique void set_pmc_index PMC* value INTVAL index
+unique PMC* get_pmc_index INTVAL index
+
Index: classes/Makefile.in
===
RCS file: /cvs/public/
Re: on parrot strings
[EMAIL PROTECTED] (Russ Allbery) wrote on 22.01.02 in <[EMAIL PROTECTED]>: > Kai Henningsen <[EMAIL PROTECTED]> writes: > > > A case that (in a slightly different context) recently came up on > > alt.usage.german (I don't remember if this particular point was made, > > but it belongs): > > > "berliner" - attribute, belonging to, coming from, etc. Berlin. > > "Berliner" - noun, a citizen of that city, or a jelly donut. > > > Two different words that only differ in capitalization. > > In German, do you ever write in all caps? If so, how does it change > things like this? Yes (though it's usually a bad idea), and you need context to disambiguate, obviously. (That's where the rule about optionally capitalizing the sharp s as SZ instead of SS fits - how else to distinguish "IN MASSEN" (great amounts) from "IN MASZEN" (in moderation)?) People do get confused sometimes. (Similarly when the capitalization at the start of a sentence changes one of those words.) If I had to design the language from scratch, that's one feature I'd try to avoid. > You're right, I should have thought of German, where capitalization is > used to indicate part of speech. MfG Kai
Re: Some Apocalypse 4 exception handling questions.
> The problem I see with inheriting subblocks such as > FIRST/LAST/etc, is that they are tied in with the logic > ... of their enclosing block... Surely this is an argument *for* it being pretty odd *not* to inherit them. Let's say you add a LAST block to a method. In the LAST block you write clean up code that frees some resources. If you inherit from that method, and do not inherit the LAST block, then you've got a leak. This is obviously a mild example. --me
RE: Some Apocalypse 4 exception handling questions.
From: Me [mailto:[EMAIL PROTECTED]] > > > The problem I see with inheriting subblocks such as > > FIRST/LAST/etc, is that they are tied in with the logic > > ... of their enclosing block... > > Surely this is an argument *for* it being pretty odd > *not* to inherit them. > > Let's say you add a LAST block to a method. In the > LAST block you write clean up code that frees some > resources. If you inherit from that method, and do not > inherit the LAST block, then you've got a leak. This is > obviously a mild example. Methods can be inherited. Their implementations may include LAST blocks, which will be invoked along with the inherited method if the method is not redefined in a subclass. However, if the method is redefined in a subclass, neither the superclass' method's implementation or its associated LAST block would be invoked. In contrast, pre- and post-conditions _are_ inherited and separate from the method implementation itself. If an inherited method is redefined in a subclass, it must still satisfy pre- and post-conditions.
RE: Some Apocalypse 4 exception handling questions.
From: David Whipp [mailto:[EMAIL PROTECTED]] > Peter Haworth [mailto:[EMAIL PROTECTED]] wrote: > > This is all very sensible, and I completely agree with it. > > However, don't we > > need some restrictions on what can go in PRE and POST blocks > > to ensure that they are still valid in inherited methods? > > There's another issue: sometimes we don't want to inherit PRE > conditions. DBC allows a derived method to strengthen (add) > post-conditions; but to weaken (remove) preconditions. I > haven't (yet) seen how this weakening would be accomplished. In regard to Design-by-Contract, Larry did say more on that later. -Didn't he? In Class::Contract, pre-conditions are allowed to weaken by allowing either the satisfaction of the subclassed method's pre-conditions or by satisfying the pre-conditions of all classes from which it is derived.
need help making auction
see attached file.
=
frank crowley
__
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
#!/usr/bin/perl
use vars qw(%config %category %form);
use strict;
#-###
#
# In accordance with the GPL, this copyright notice MUST remain intact:
#
# EveryAuction Release Version 1.51 (5/13/00)
# Copyright (C) 2000 EverySoft
# Registered with the United States Copyright Office, TX5-186-526
# http://www.everysoft.com/
#
#-###
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of the GNU General Public License
# as published by the Free Software Foundation; either version 2
# of the License, or (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
#
#-###
#
# Modification Log (please add new entries to bottom):
#
# * 02/2000
# Matt Hahnfeld ([EMAIL PROTECTED]) - Original Concept and Design
# Version available from http://www.everysoft.com/
#
# * MM/
# Name (email) - Modification
# Availability
#
#-###
#-#
# Configuration Section
# Edit these variables!
local %config;
# The Base Directory. We need an
# absolute path for the base directory.
# Include the trailing slash. THIS SHOULD
# NOT BE WEB-ACCESSIBLE!
$config{'basepath'} = '/home/hahnfld/auctiondata/';
# Closed Auction Directory
# This is where closed auction items are stored.
# Leave this blank if you don't want to store
# closed auctions. It can potentially take
# up quite a bit of disk space.
$config{'closedir'} = 'closed';
# User Registration Directory
# This is where user registrations are stored.
# Leave this blank if you don't want to
# require registration. It can potentially
# take up quite a bit of disk space.
$config{'regdir'} = 'reg';
# List each directory and its associated
# category name. These directories should
# be subdirectories of the base directory.
%category = (
computer => 'Computer Hardware and Software',
elec => 'Consumer Electronics',
other => 'Other Junk',
);
# This is the password for deleting auction
# items.
$config{'adminpass'} = 'auction';
# You need to assign either a mail program or
# a mail host so confirmation e-mails can
# be sent out.
# Leave one commented and one uncommented.
#
# YOU NEED EITHER A MAIL PROGRAM
# $config{'mailprog'} = '/usr/lib/sendmail -t';
#
# OR YOU NEED A MAIL HOST (SMTP)
$config{'mailhost'} = 'localhost';
# This line should be your e-mail address
$config{'admin_address'} = '[EMAIL PROTECTED]';
# This line should point to the URL of
# your server. It will be used for sending
# "you have been outbid" e-mail. The script
# name and auction will be appended to the
# end automatically, so DO NOT use a trailing
# slash. If you do not want to send outbid
# e-mail, leave this blank.
$config{'scripturl'} = 'www.your.host.com';
# This will let you define colors for the
# tables that are generated and the
# other page colors. The default colors
# create a nice "professional" look. Must
# be in hex format.
$config{'colortablehead'} = '#BB';
$config{'colortablebody'} = '#EE';
# Site Name (will appear at the top of each page)
$config{'sitename'} = 'Your Site Name Here';
# You can configure your own header which will
# be appended to the top of each page.
$config{'header'} =<<"EOF";
$config{'sitename'} - Powered By EveryAuction
$config{'sitename'}
Online Auction
keyword username
EOF
# You can configure your own footer which will
# be appended to the bottom of each page.
# Although not required, a link back to
# everysoft.com will help to support future
# development.
$config{'footer'} =<<"EOF";
Powered By http://www.everysoft.com/auction/>EveryAuction 1.51
EOF
# Sniper Protection... How many minutes
# past last bid to hold auction. If auctions
# should close at exactly closing time, set
# to zero.
$config{'aftermin'} = 5;
# File locking enabled? Should be 1 (yes)
# for most systems, but set to 0 (no) if you
# are getting flock errors or the script
# cra
Re: Some Apocalypse 4 exception handling questions.
Me writes: : > The problem I see with inheriting subblocks such as : > FIRST/LAST/etc, is that they are tied in with the logic : > ... of their enclosing block... : : Surely this is an argument *for* it being pretty odd : *not* to inherit them. : : Let's say you add a LAST block to a method. In the : LAST block you write clean up code that frees some : resources. If you inherit from that method, and do not : inherit the LAST block, then you've got a leak. This is : obviously a mild example. I think our terminology is getting sloppy here. What do you mean by "inherit from that method"? If the derived method overrides the base method, it will manage its own resources, and doesn't need the base method's LAST. If the derived method calls the base method, the LAST of the base method will naturally come along for the ride. If there is no derived method, the base method also calls its own LAST as a matter of course. I don't see any problem here. Larry
Re: need help making auction
At 01:39 PM 1/23/2002 -0800, frank crowley wrote: >see attached file. > > >= >frank crowley What is it that you wanted us to see? -Melvin
Re: need help making auction
On Wed, Jan 23, 2002 at 01:39:09PM -0800, frank crowley wrote: : :see attached file. Hi frank, This mailing list is not designed to help folks get their Perl 5 programs working. EverySoft, the company that built the program you attatched has their own online forum for helping you. Home Page:http://www.everysoft.com/frames.html Online Forum: http://209.15.166.219/cgi-bin/forum.pl Please go to their forum and ask them to help you, I'm sure they would be more than happy to. No further response is necessary. Casey West -- Technology makes it possible for people to gain control over everything, except over technology. -- John Tudor
Re: Some Apocalypse 4 exception handling questions.
Me wrote: > > > The problem I see with inheriting subblocks such as > > FIRST/LAST/etc, is that they are tied in with the logic > > ... of their enclosing block... > > Surely this is an argument *for* it being pretty odd > *not* to inherit them. > > Let's say you add a LAST block to a method. In the > LAST block you write clean up code that frees some > resources. If you inherit from that method, and do not > inherit the LAST block, then you've got a leak. This is > obviously a mild example. Methinks (that's me, not you) that if me thinks (that's you, not me) that my argument is an argument *for* it being pretty odd *not* to inherit them, that there is an assumption by me or me (that's one or the other of us) that is clearly wrong about the way inheritance of methods (should) work. In my mind, the idea of inheriting a method is that the subclass and the superclass have a common subroutine that is invoked whether the message is sent to the subclass or to the superclass. In Perl6 terms, that subroutine may include PRE/POST blocks, FIRST/LAST/NEXT/CATCH/UNDO/KEEP blocks, embedded closures and other statements, whatever the implementation needs to be to get the job done correctly. The whole she-bang subroutine implementation comes along for the inheritance ride. The idea that has been mentioned of having PRE and POST blocks be inherited is a slightly different concept... in that case, the method itself is NOT being inherited, and NONE of the code of the method in the superclass is used by the subclass... Except the PRE and POST conditions, as implemented by the PRE and POST blocks. They would get inherited to allow the design by contract invariants required by the superclass to be enforced in spite of subclassing. This separate type of inheritance is another reason that perhaps the PRE and POST blocks should not be included within the block of the subroutine that implements a method, but perchance should be defined outside of them... perhaps as properties of the method definition? I would be extremely doubtful of Larry's lucidity if I thought that he was suggesting that none of the FIRST/LAST/NEXT/CATCH/UNDO/KEEP blocks were included with an inherited method, but I don't think that. Such blocks are an inherent part of the implementation of the method, not an inherit part of subclassing. What do you think, me? > --me -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: need help making auction
At 01:43 PM 1/23/2002 -0800, you wrote: >i need help on making it into an auction that will >work. Ok I thought so. You might try [EMAIL PROTECTED] for some beginner tips but I doubt you want to submit a whole script, maybe rephrase your stuff into specific problems you are having. Good luck, -Melvin
Re: Some Apocalypse 4 exception handling questions.
>Methinks (that's me, not you) that if me thinks (that's you, not me)
>that my argument is an argument *for* it being pretty odd *not* to
>inherit them, that there is an assumption by me or me (that's one or the
>other of us) that is clearly wrong about the way inheritance of methods
>(should) work.
Eek.
>In my mind, the idea of inheriting a method is that the subclass and the
>superclass have a common subroutine that is invoked whether the message
>is sent to the subclass or to the superclass. In Perl6 terms, that
I'm not comfortable with this sort of concept. Typically "inheritance" is
going to either take the base implementation or _replace_ the implementation.
The replacement can decide to {call|ignore} the base method.
If you have hidden side effects that makes things scary, (and potentially
costly in the long run) I think.
If you wouldn't want the base implementation to be ignore there is usually
some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
sure.
-Melvin
Re: Some Apocalypse 4 exception handling questions.
David Whipp writes: : Peter Haworth [mailto:[EMAIL PROTECTED]] wrote: : > This is all very sensible, and I completely agree with it. : > However, don't we : > need some restrictions on what can go in PRE and POST blocks : > to ensure that they are still valid in inherited methods? : : : There's another issue: sometimes we don't want to inherit PRE : conditions. DBC allows a derived method to strengthen (add) : post-conditions; but to weaken (remove) preconditions. I : haven't (yet) seen how this weakening would be accomplished. Damian told me you just handle that by ORing together the preconditions, but ANDing the postconditions. : Perhaps the mechanism that controls inheritance of : preconditions may have a more general applicability? Underneath it's all just block properties that happen to be closures. We can do whatever we want with them--as long as we agree on the definitions of "we" and "want". Or at least agree to disagree such that we keep out of each other's way. Larry
Re: Some Apocalypse 4 exception handling questions.
Melvin Smith wrote:
>
> >Methinks (that's me, not you) that if me thinks (that's you, not me)
> >that my argument is an argument *for* it being pretty odd *not* to
> >inherit them, that there is an assumption by me or me (that's one or the
> >other of us) that is clearly wrong about the way inheritance of methods
> >(should) work.
>
> Eek.
>
> >In my mind, the idea of inheriting a method is that the subclass and the
> >superclass have a common subroutine that is invoked whether the message
> >is sent to the subclass or to the superclass. In Perl6 terms, that
>
> I'm not comfortable with this sort of concept. Typically "inheritance" is
> going to either take the base implementation or _replace_ the implementation.
> The replacement can decide to {call|ignore} the base method.
I think you just said the same thing I did. To be more explicit, using
the terminology you seem to want to use, I'll point out that I was only
talking about the case of an inherited method, not a _replacement_
method. In other words, when you inherit a method, you are taking the
base implementation for that method. But if you replace a method, you
are not inheriting that method, but rather replacing it; yes, the
replacement method may choose to call the base implementation's method
as part of the replacement implementation. When you replace a method,
you have 2 subroutines, the base implementation, and the replacement
implementation, but when you inherit a method, you have only 1
subroutine, which may be called 2 different ways.
> If you have hidden side effects that makes things scary, (and potentially
> costly in the long run) I think.
I wasn't positing hidden side effects. I was trying to not inherit
fragments of the base implementation, as me seemed to be trying to do.
> If you wouldn't want the base implementation to be ignore there is usually
> some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
> sure.
I'm not sure either. In fact, I'm not sure what you mean by this
sentence at all. If it matters, please rephrase it, so we can talk more
about it.
> -Melvin
--
Glenn
=
Due to the current economic situation, the light at the
end of the tunnel will be turned off until further notice.
Re: Some Apocalypse 4 exception handling questions.
At 02:25 PM 1/23/2002 -0800, Glenn Linderman wrote:
>Melvin Smith wrote:
> > I'm not comfortable with this sort of concept. Typically "inheritance" is
> > going to either take the base implementation or _replace_ the
> implementation.
> > The replacement can decide to {call|ignore} the base method.
>
>I think you just said the same thing I did. To be more explicit, using
>the terminology you seem to want to use, I'll point out that I was only
>talking about the case of an inherited method, not a _replacement_
>method. In other words, when you inherit a method, you are taking the
>base implementation for that method. But if you replace a method, you
>are not inheriting that method, but rather replacing it; yes, the
>replacement method may choose to call the base implementation's method
>as part of the replacement implementation. When you replace a method,
>you have 2 subroutines, the base implementation, and the replacement
>implementation, but when you inherit a method, you have only 1
>subroutine, which may be called 2 different ways.
After re-reading your piece by itself I see we did say the same thing.
The confusion set in when I read 'Me's' post inline with yours.
> > If you wouldn't want the base implementation to be ignore there is usually
> > some mechanism in C++ and Java for this, how it applies to Perl6 I'm not
> > sure.
>
>I'm not sure either. In fact, I'm not sure what you mean by this
>sentence at all. If it matters, please rephrase it, so we can talk more
>about it.
Referring to final, private, etc. modifiers that you can use in C++/Java
whenever you don't want someone reimplementing or overriding something.
Will there be such a thing in Perl6?
I think this is meant more for "Me" (not me) than you.
-Melvin
Re: Some Apocalypse 4 exception handling questions.
Melvin Smith wrote: > > > > If you wouldn't want the base implementation to be ignore there is usually > > > some mechanism in C++ and Java for this, how it applies to Perl6 I'm not > > > sure. > > > >I'm not sure either. In fact, I'm not sure what you mean by this > >sentence at all. If it matters, please rephrase it, so we can talk more > >about it. > > Referring to final, private, etc. modifiers that you can use in C++/Java > whenever you don't want someone reimplementing or overriding something. > Will there be such a thing in Perl6? > > I think this is meant more for "Me" (not me) than you. final and private are completely different concepts as I understand them. At least, I think I understand private to be stuff used by the implementation of methods, that is not available for the general public to see. This is considered a good thing in compiled code where users code to the interface, and cannot see the implementation. In Perl, the implementation is generally visible, and privacy would be somewhat fictitious, albeit perhaps a useful one at times. Final seems to be a way of sealing off a class or method from future inheritance. Generally, the arguments I've seen on OO lists seem to indicate that regardless of how omniscient the original designer is, someone will get an idea for a useful subclass for the class or method, but run into the problem of not being able to extend it because of the superclass implementor's choice to make it final. Hence, final seems to be a concept that is rather un-Perl-ish. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Re: Some Apocalypse 4 exception handling questions.
On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote: > I think you just said the same thing I did. To be more explicit, using > the terminology you seem to want to use, I'll point out that I was only > talking about the case of an inherited method, not a _replacement_ > method. In other words, when you inherit a method, you are taking the > base implementation for that method. But if you replace a method, you > are not inheriting that method, but rather replacing it; yes, the > replacement method may choose to call the base implementation's method > as part of the replacement implementation. When you replace a method, > you have 2 subroutines, the base implementation, and the replacement > implementation, but when you inherit a method, you have only 1 > subroutine, which may be called 2 different ways. But the base class may be just an interface class. And thus by inheriting the pre conditions you are enforcing the API. So I can see a use for it, but I can also see where you don't want it too. Graham.
Re: Some Apocalypse 4 exception handling questions.
> I think our terminology is getting sloppy here. Ok, I (think I) understand. It's simple: If you declare a derived method, then preconditions and postconditions may or may not be inherited, and independently, the code may or may not be inherited. By default, the conditions are inherited and the code is not. One can optionally not inherit the conditions (at least preconditions, from another post I just read). And one can optionally inherit the code (by calling it). Right? Btw, are you going to have an equivalent of super? --me
Re: Some Apocalypse 4 exception handling questions.
> [final, private] I detest what these modifiers have done to me in the past. They seem very unperlish to me.
Re: Some Apocalypse 4 exception handling questions.
At 02:45 PM 1/23/2002 -0800, Glenn Linderman wrote: >Melvin Smith wrote: > > Referring to final, private, etc. modifiers that you can use in C++/Java > > whenever you don't want someone reimplementing or overriding something. > >final and private are completely different concepts as I understand >them. I wouldn't say "completely different". They are both used for "enforcement" of similar means, but you are correct, they are different. >to see. This is considered a good thing in compiled code where users >code to the interface, and cannot see the implementation. In Perl, the >implementation is generally visible, and privacy would be somewhat >fictitious, albeit perhaps a useful one at times. Likewise in C++/Java/etc., its just a policy, not an absolute law. I wasn't debating the usefulness of them anyway, just noting the availability; and I thought it was relevant to the original comment by Mr. Me. >Final seems to be a way of sealing off a class or method from future >inheritance. Generally, the arguments I've seen on OO lists seem to >indicate that regardless of how omniscient the original designer is, >someone will get an idea for a useful subclass for the class or method, >but run into the problem of not being able to extend it because of the >superclass implementor's choice to make it final. Hence, final seems to >be a concept that is rather un-Perl-ish. Thats one contrived example that I've heard before, but that is more about decisions on where to use it, not whether it is good to have in your toolbox. Anway, sorry to start this tangent, it probably has little interest for the rest of the guys here. :) -Melvin
Re: Some Apocalypse 4 exception handling questions.
On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote: > Final seems to be a way of sealing off a class or method from future > inheritance. Generally, the arguments I've seen on OO lists seem to > indicate that regardless of how omniscient the original designer is, > someone will get an idea for a useful subclass for the class or method, > but run into the problem of not being able to extend it because of the > superclass implementor's choice to make it final. Hence, final seems to > be a concept that is rather un-Perl-ish. Hmm. It would be un-Perl-ish to not provide a mechanism for the fascist to implement final if they wanted it. Which leads me to wonder if a way unfolds from the syntax already revealed or if we have to wait for the OOP-Apocalypse to see how to put our PRE conditions on the "isa" mechanism. -Scott -- Jonathan Scott Duff [EMAIL PROTECTED]
Re: Some Apocalypse 4 exception handling questions.
At 05:01 PM 1/23/2002 -0600, Jonathan Scott Duff wrote: >On Wed, Jan 23, 2002 at 02:45:21PM -0800, Glenn Linderman wrote: > > Final seems to be a way of sealing off a class or method from future > > inheritance. Generally, the arguments I've seen on OO lists seem to > > indicate that regardless of how omniscient the original designer is, > > someone will get an idea for a useful subclass for the class or method, > > but run into the problem of not being able to extend it because of the > > superclass implementor's choice to make it final. Hence, final seems to > > be a concept that is rather un-Perl-ish. > >Hmm. It would be un-Perl-ish to not provide a mechanism for the >fascist to implement final if they wanted it. Which leads me to >wonder if a way unfolds from the syntax already revealed or if we have >to wait for the OOP-Apocalypse to see how to put our PRE conditions on >the "isa" mechanism. I agree totally. Ive never bought into arguments about why "available, non-default" behavior is so oppressive. Else "use strict" would have to go. :) Glenn's point is correct about these mechanisms - when you don't have access to source code, it can be frustrating, but I think its the availability of source + the design decision of the author, not the keyword that is the problem. -Melvin
Re: Some Apocalypse 4 exception handling questions.
Graham Barr wrote: > > On Wed, Jan 23, 2002 at 02:25:35PM -0800, Glenn Linderman wrote: > > I think you just said the same thing I did. To be more explicit, using > > the terminology you seem to want to use, I'll point out that I was only > > talking about the case of an inherited method, not a _replacement_ > > method. In other words, when you inherit a method, you are taking the > > base implementation for that method. But if you replace a method, you > > are not inheriting that method, but rather replacing it; yes, the > > replacement method may choose to call the base implementation's method > > as part of the replacement implementation. When you replace a method, > > you have 2 subroutines, the base implementation, and the replacement > > implementation, but when you inherit a method, you have only 1 > > subroutine, which may be called 2 different ways. > > But the base class may be just an interface class. And thus by inheriting > the pre conditions you are enforcing the API. So I can see a use for > it, but I can also see where you don't want it too. So if the base class is just an interface class, then you cannot usefully inherit the methods, without winding up with just another interface class. Of course, that sometimes is useful too. So maybe your point was that when you replace a method from a base class that you only have 1 subroutine for that method, the replacement one, because there wasn't really one there in the interface class to inherit? It was not my intention in the paragraph I quoted to say anything about pre and post conditions, but neither was it my intention to imply that they shouldn't be inherited, if they exist. I'd still like to hear Larry comment on the benefits vs dangers of having the PRE and POST conditions defined within the implementation block of a method, as opposed to defined outside. The more I think about it, the more convinced I am that the natural place to define the pre and post conditions is outside the implementation block, to prevent them from referencing lexically scoped variables of the implementation... or have a compiler rule preventing it. Otherwise they could be impossible to evaluate in the context of an inherited (replacement) method. -- Glenn = Due to the current economic situation, the light at the end of the tunnel will be turned off until further notice.
Apoc4: Block scoping
Does the alias operator, C<< -> >>, work for C blocks too?
if $a * $b / $c + $d -> $abcd { ... }
Where $abcd would be lexically scoped to the if block and else block,
if defined. I expect it could be used with any block statement,
since Apoc 4 demonstrates it with for, grep, loop, and given.
Thanks,
cd
RE: [dha@panix.com: Re: ^=~]
>Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
>
>You *could* instead consider reversing the arguments to all the list
>manipulation operators:
>
> @result = map @data { mapping() }
> @result = grep @data { selector() };
> @result = sort @data { comparison() };
> @result = reduce @data { combinator() };
>
I would love this. From an OO point of view, it looks much more natural imho
to think on map and friends as list methods that take block arguments than
as block methods that take arrays as arguments.
In other words:
@result = @data.map(&mapping)
looks better than:
@result = &mapping.map(@data)
>Then you would have the possibility of:
>
> @result = map @data -> $x { mapping($_, $x) }
> ...
>
I am afraid I don't understand this one. ¿Which value is $_ suposed to get?
> The Perl5-ish:
>
> @sorted_by_size =
> map { $_->[0] }
> sort { $a->[1] <=> $b->[1] }
> map { [$_, -s] }
> @files;
>
>would become:
>
> @sorted_by_size =
> map sort map @files
> { [$_, -s] }
> { $^a[1] <=> $^b[1] }
> { $_[0] };
>
>Though I suppose the method call approach solves that nicely too:
>
> @sorted_by_size =
> @files.map( { $_[0] })
> .sort({ $^a[1] <=> $^b[1] })
> .map( { [$_, -s] });
>
>with the operations reading left-to-right, down the page.
>
Mmm.. If we did reverse the order of the arguments I was expecting it to
become:
@sorted_by_size =
@files.map({ [$_, -s] })
.sort({ $^a[1] <=> $^b[1] })
.map({ $_[0] })
Or if that was not decided, then I would expect:
@sorted_by_size = { $_[0] }.map (
{ $^a[1] <=> $^b[1] }.order (
{ $^a[1] <=> $^b[1] }.map (@files)
)
);
By the way, assuming the order of list manipulation operators was actually
reversed, ¿would the following be correct perl6?
@sorted_by_size =
@files.map -> $file { [$file, -s $file] }
.sort -> @a, @b { @a[1] <=> @b[1] }
.map -> @pair { @pair[0] }
--
Angel Faus
[EMAIL PROTECTED]
Re: Apoc4: Block scoping
Chris Dale writes:
: Does the alias operator, C<< -> >>, work for C blocks too?
:
: if $a * $b / $c + $d -> $abcd { ... }
:
: Where $abcd would be lexically scoped to the if block and else block,
: if defined. I expect it could be used with any block statement,
: since Apoc 4 demonstrates it with for, grep, loop, and given.
I haven't decided whether it makes sense for C or C to try
to pass anything to their blocks. We'd either have to hardwire it
syntactically to look for -> and do something different, which is icky,
or we'd have to make it assume -> $_ when there wasn't an arrow, which
is ickier. People aren't going to expect $_ to get overridden like
that.
Larry
Re: on parrot strings
On Wed, Jan 23, 2002 at 06:06:00PM +0200, Kai Henningsen wrote: > People do get confused sometimes. I'm confused as to why this is still on p6i. Followups to alt.usage.german? Thanks. -- DESPAIR: It's Always Darkest Just Before it Gets Pitch Black http://www.despair.com
Re: Some Apocalypse 4 exception handling questions.
> "Larry" == Larry Wall <[EMAIL PROTECTED]> writes: Larry> I think our terminology is getting sloppy here. What do you mean by Larry> "inherit from that method"? If the derived method overrides the base Larry> method, it will manage its own resources, and doesn't need the base Larry> method's LAST. If the derived method calls the base method, the LAST Larry> of the base method will naturally come along for the ride. If there is Larry> no derived method, the base method also calls its own LAST as a matter Larry> of course. I don't see any problem here. That's why I'm still puzzled about what it means to inherit PRE/POST as well. A block of code doesn't have a superclass. What exactly are you "inheriting from"? If you call "super" from a method, surely the super will have its own PRE/POST, and then there's no need to inherit it. If you don't call "super", how do you know the PRE/POST of a similar subroutine in a superclass that you're completely overriding should even apply? So, does it make any sense at all to talk about "inheriting" PRE/POST as a separate act, other than the natural block start/end from calling "super" at the right time? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/> Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Tinderbox/bonsai
I just wanted to give everyone a quick summary of the status of tinderbox and bonsai. Tinderbox is up and running at tinderbox.perl.org. If people would like, I can configure a little bot for #parrot so that it will let everyone know if the tinderbox state changes (but won't annoy people in other ways by telling them other things). I added a key to tinderbox.perl.org by popular demand so that people can tell what the different colors mean. There are also no clients for windows or other rare OS's now. It would be great if we could get one going. I'll do the best that I can to help get it setup. Also, when you check in code, it is a good idea to look at tinderbox and see if tests are failed. Currently tinderbox is orange because of the TODO test in t/op/rx.t. Perhaps we should be able to let tinderbox know not to go orange for TODO tests. As for bonsai, tinderbox.perl.org/bonsai is up and running and will allow you to query for a variety of things. Take some time to explore. I made a small list of useful queries at the bottom of this message. The bonsai database does not automatically update itself yet (still having some problems and I think I need to rewrite some code in bonsai). I just manually updated the database so it should be pretty current, but the names of checkeriners won't appear in the "guilty" col on tinderbox until this is fixed (which may be a good thing). Let me know if there is anything else that these tools can do that would be useful or if you have any questions and I'll do my best to help. Zach Useful bonsai queries (sorry to pick on you Dan): List all checkins in the last two hours (note that without automatic updating this will be out of date): http://tinderbox.perl.org/bonsai/cvsquery.cgi?treeid=default&module=all&bran ch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby =Date&date=hours&hours=2&mindate=&maxdate=&cvsroot=%2Fhome%2Ftinder%2Fperlcv s All checkins in the last day: http://tinderbox.perl.org/bonsai/cvsquery.cgi?treeid=default&module=all&bran ch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby =Date&hours=2&date=day&mindate=&maxdate=&cvsroot=%2Fhome%2Ftinder%2Fperlcvs All checkins in the last week: http://tinderbox.perl.org/bonsai/cvsquery.cgi?treeid=default&module=all&bran ch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby =Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fhome%2Ftinder%2Fperlcvs All checkins by Dan in the last week (replace dan in the url to change the person to query for): http://tinderbox.perl.org/bonsai/cvsquery.cgi?treeid=default&module=all&bran ch=HEAD&branchtype=match&dir=&file=&filetype=match&who=dan&whotype=match&sor tby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fhome%2Ftinder%2Fperl cvs Generate a shell script to return your working cvs tree back to a tree where Dan's checkins from last week are not in your tree (useful if a checkin is causing a problem and you want to back it out of your tree so you can continue to work): http://tinderbox.perl.org/bonsai/cvsquery.cgi?treeid=default&module=all&bran ch=HEAD&branchtype=match&dir=&file=&filetype=match&who=dan&whotype=match&sor tby=Date&hours=2&date=week&mindate=&maxdate=&cvsroot=%2Fhome%2Ftinder%2Fperl cvs&generateBackoutCVSCommands=1 All changes to parrot/interpreter.c since the beginning of time: http://tinderbox.perl.org/bonsai/cvslog.cgi?file=parrot/interpreter.c&root=/ home/tinder/perlcvs A "blame" list for parrot/interpreter.c that shows each line of the file and who wrote it (useful for tracking down who introduced a problem, javascript popups show you the commit log messages): http://tinderbox.perl.org/bonsai/cvsblame.cgi?file=parrot/interpreter.c Generate cvs diffs for parrot/interpreter.c to see what changed between two versions of the file: http://tinderbox.perl.org/bonsai/cvsview2.cgi?command=DIRECTORY&subdir=parro t&files=interpreter.c
Re: Tinderbox/bonsai
>different colors mean. There are also no clients for windows or other rare >OS's now. It would be great if we could get one going. I'll do the best that >I can to help get it setup. I remember trying a month or so ago and it appeared that the Tinderbox module used sendmail wrapper for sending the data which would not work on Windows. At the time I didn't have time to investigate it, or convert it to Net::SMTP or such. Is this still the case? Did I have the wrong version? I'd be happy to run a Win2000 client. -Melvin
Re: [perl6]Re: Tinderbox/bonsai
It is still using sendmail though I am working on a Net::SMTP version for the next release. If you can give me a few days I'll have it up on CPAN. Thanks for volunteering to contribute. Zach On 1/23/02 7:15 PM, "Melvin Smith" <[EMAIL PROTECTED]> wrote: > >> different colors mean. There are also no clients for windows or other rare >> OS's now. It would be great if we could get one going. I'll do the best that >> I can to help get it setup. > > I remember trying a month or so ago and it appeared that the Tinderbox > module used sendmail wrapper for sending the data which would not > work on Windows. At the time I didn't have time to investigate it, or > convert it to Net::SMTP or such. > > Is this still the case? Did I have the wrong version? > > I'd be happy to run a Win2000 client. > > -Melvin >
