Re: Still about subroutines...

2004-09-17 Thread Richard Proctor
On Fri 17 Sep, Larry Wall wrote: > > $?fileWhich file am I in? > $?lineWhich line am I at? > $?package Which package am I in? > @?package Which packages am I in? > $?module Which module am I in? > @?module Which modules am I in? > $?class Which class am I in

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
it's basically a confusing if else if ($one == $two) { return 1 } else { return 0 } - Love is everything. It is the key to [human] life, and its influences are those that move the world. -- Ralph Waldo Trine

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
But that would return '' or 1and presumably the author wanted zero instead of an empty string. Cheers, Brent - The entrepreneur is essentially a visualizer and an actualizer... He can visualize something and w

Re: [Devel::Cover] return conditions

2004-09-17 Thread Tels
-BEGIN PGP SIGNED MESSAGE- Moin, On Friday 17 September 2004 10:56, [EMAIL PROTECTED] wrote: > But that would return '' or 1and presumably the author > wanted zero instead of an empty string. > > Cheers, Brent > On Fri, Sep 17, 2004 at 09:33:39AM +0100, [EMAIL PROTECTED] wrote: > > it's

[Devel::Cover] @INC at Runtime?

2004-09-17 Thread David Wheeler
Hi Paul (and everyone else), The Devel::Cover documentation says: The inc directories are initially populated with the contects of the @INC array at the time Devel::Cover was built. You may reset these directories using -inc, or add to them using +inc. However, now that new

Re: [Devel::Cover] return conditions

2004-09-17 Thread Dave Cross
On Fri, Sep 17, 2004 at 09:33:39AM +0100, [EMAIL PROTECTED] wrote: > > it's basically a confusing if else > > if ($one == $two) { return 1 } else { return 0 } Or return $one == $two; Dave... -- We are far too young and clever

Re: Current state?

2004-09-17 Thread James Mastros
Patrick R. Michaud wrote: On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote: I agree that the default should be the current outer language. I agree that the default ought to be overridable. I agree that the right way to do that is with something like "use PIR;" rather than inventing an inc

Re: Still about subroutines...

2004-09-17 Thread Thomas Seiler
Richard Proctor wrote: Maybe there are some more... $?perl Which version of perl am I in $?parrot Which version of parrot is perl running on $?parrot_runloop Which runloop is running ? etc... >And relating to the outside world > > $?os Which operating system am I operating on $?pid

Re: [Devel::Cover] return conditions

2004-09-17 Thread Brent . Cowgill
Incidentally, the original obfuscated code is pretty damn fast if you expect to return False most of the time. Rate if_else - (F) space_ship - (F) space_ship (T) ternary - (F) if_else - (T) ret_1_or_ret_0 (T) ternary - (T) ret_1_or_ret_0 (F) (control) (F) (control) (T) i

Re: [Devel::Cover] return conditions

2004-09-17 Thread Tels
-BEGIN PGP SIGNED MESSAGE- Moin, On Friday 17 September 2004 12:41, [EMAIL PROTECTED] wrote: > Incidentally, the original obfuscated code is pretty damn fast > if you expect to return False most of the time. I bet by removing the return statement it gets even faster: ala: ($one == $tw

Re: Still about subroutines...

2004-09-17 Thread Jonathan Scott Duff
On Thu, Sep 16, 2004 at 10:35:45PM -0700, Larry Wall wrote: > Except that only one of these variables' meanings is actually > associated with subs. And I kind of like to read the C as "which". > So if we actually make use of our sigils, we get possibilities like this: > > $?fileWhich file

Re: What Requires Core Support (app packaging)

2004-09-17 Thread Jonadab the Unsightly One
Juerd <[EMAIL PROTECTED]> writes: > Most worlds don't use file extensions, except for humans. You exaggerate their lack of importance. File extensions don't matter to most operating system *kernels*, but they are nevertheless important for more than just Windows: * They are of critical import

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Ricardo SIGNES
* David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] > So, what's to be lost by having the inc directories default to the > contents of @INC when you load Devel::Cover rather than at install > time? Presumably the problem is that by runtime, lib and blib directories are already in @INC, so

Re: Current state?

2004-09-17 Thread Patrick R. Michaud
On Fri, Sep 17, 2004 at 11:44:09AM +0200, James Mastros wrote: > > >Or is there some syntactic shortcut that can be made to let us find > >the end of a closure without having to fully parse the closure itself? > Well, we could do that for the time being, in which case, I suggest the > end conditi

S5: range quantifier woes

2004-09-17 Thread Jonathan Scott Duff
The new range quantifier syntax has been bothering me. For reference, here's the bit of S5 that talks about it: > The repetition specifier is now **{...} for maximal matching, with a > corresponding or **{...}? for minimal matching. Space is allowed on > either side of the asterisks. The curlies

Re: Current state?

2004-09-17 Thread Jonathan Scott Duff
On Fri, Sep 17, 2004 at 11:44:09AM +0200, James Mastros wrote: > Patrick R. Michaud wrote: > >On Tue, Sep 14, 2004 at 12:42:59PM -0700, Larry Wall wrote: > >>I agree that the default should be the current outer language. > >>I agree that the default ought to be overridable. > >>I agree that the rig

Re: What Requires Core Support (app packaging)

2004-09-17 Thread Juerd
Jonadab the Unsightly One skribis 2004-09-17 10:46 (-0400): > * They are of critical importance on Apache-based webservers. They are not. See mod_mime_magic. > * They instruct command-line tab completion for some shells. This >IMO is a biggie, and would be even bigger if more shells were >

Re: S5: range quantifier woes

2004-09-17 Thread Juerd
Jonathan Scott Duff skribis 2004-09-17 9:57 (-0500): > [foo]~5 # match exactly 5 times > [foo]~{0...}# verbose [foo]* > [foo]~{1...}# verbose [foo]+ > [foo]~{1..5}# match from 1 to 5 times > [foo]~{[1,3,5]} #

Re: What Requires Core Support (app packaging)

2004-09-17 Thread John Macdonald
On Fri, Sep 17, 2004 at 10:46:36AM -0400, Jonadab the Unsightly One wrote: > Juerd <[EMAIL PROTECTED]> writes: > > > Most worlds don't use file extensions, except for humans. > > You exaggerate their lack of importance. File extensions don't matter > to most operating system *kernels*, but they

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 09:41:37AM -0500, Jonathan Scott Duff wrote: : Maybe I'm just being curmudgeonly, but is this really that useful to : have such shortcuts? I presume that there will be alternate ways to : access the same information (like maybe a special hash : (%*WHICH{'package'} and %*WHIC

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 09:25:08AM +0100, Richard Proctor wrote: : Maybe there are some more... : : $?perlWhich version of perl am I in It would be "Which version of Perl am I compiled with?" But $?perlversion would much clearer. I suppose the same could be said for $?subname. : And re

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 11:59:09AM +0200, Thomas Seiler wrote: : $?parrot Which version of parrot is perl running on $?parrotversion would be which version of parrot we were compiled on. $*parrotversion would be which version of parrot we are running on. : $?parrot_runloop Which runloop i

Re: S5: range quantifier woes

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 09:57:14AM -0500, Jonathan Scott Duff wrote: : Now for the bothersome parts and some questions and some suggestions in : no particular order: : : - for minimal matching the ? is too far away from the operator that it : applies to. It looks like it's doing something to the

Re: S5: range quantifier woes

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 05:15:58PM +0200, Juerd wrote: : Jonathan Scott Duff skribis 2004-09-17 9:57 (-0500): : > [foo]~5 # match exactly 5 times : > [foo]~{0...}# verbose [foo]* : > [foo]~{1...}# verbose [foo]+ : > [foo]~{1..5}#

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread David Wheeler
On Sep 17, 2004, at 7:48 AM, Ricardo SIGNES wrote: Presumably the problem is that by runtime, lib and blib directories are already in @INC, so the things in your ./distro/lib/ won't be covered, defeating the point. Ah, good point. As to whether there is a simple way to resolve this, I haven't thoug

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Graham Barr
On 17 Sep 2004, at 15:48, Ricardo SIGNES wrote: * David Wheeler <[EMAIL PROTECTED]> [2004-09-17T00:51:22] So, what's to be lost by having the inc directories default to the contents of @INC when you load Devel::Cover rather than at install time? Presumably the problem is that by runtime, lib and bl

Re: Still about subroutines...

2004-09-17 Thread Richard Proctor
On Fri 17 Sep, Larry Wall wrote: > : $?osWhich operating system am I operating on > > Again, which OS am I compiled on, or at best, which OS does the compiler > think I'm compiling for, in the case of cross-compilation. > Therefore should: $?os Be which operating system it is being c

Re: [Devel::Cover] @INC at Runtime?

2004-09-17 Thread Geoffrey Young
> You could use the values from Config.pm paul and I were talking about this on irc, wondering if there was some Config.pm value that would give the @INC that perl was compiled with. neither of us could find one, and when I started poking around as to create a patch, I fould that the logic the co

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual personality. Presumably. Whi

Re: Still about subroutines...

2004-09-17 Thread Austin Hastings
Larry Wall wrote: On Fri, Sep 17, 2004 at 07:35:46PM +0100, Richard Proctor wrote: : Therefore should: : : $?os Be which operating system it is being compiled on : $*os Be which operating system it is being executed on : : Some of the other special variables may have a similar dual personality.

Re: Still about subroutines...

2004-09-17 Thread David Wheeler
On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: I originally made them lowercase because they were $=line variables and I didn't want them to conflict with POD names that are typically uppercase, and use of an C<=> secondary sigil for POD is a no-brainer. s/uppercase/lowercase/ ? David

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 03:16:24PM -0400, Austin Hastings wrote: : For that matter, what's wrong with $__ as a sigil, as in $__LINE__, et : al. It combines the "you can use it as a variable" with the "leading : underscores are magic" memes, and doesn't impose any wierd learning curve. I am unlik

Re: Still about subroutines...

2004-09-17 Thread Larry Wall
On Fri, Sep 17, 2004 at 12:19:10PM -0700, David Wheeler wrote: : On Sep 17, 2004, at 12:06 PM, Larry Wall wrote: : : >I originally made them lowercase because they were $=line variables : >and I didn't want them to conflict with POD names that are typically : >uppercase, and use of an C<=> seconda

Re: Still about subroutines...

2004-09-17 Thread David Wheeler
On Sep 17, 2004, at 12:21 PM, Larry Wall wrote: No, not the verbs, the uppercase nouns we see like =begin COMMENT ... =end COMMENT Oh, I wasn't sure, because in the Synopses you've been using propercase for =head1 POD. But maybe it's not the subjects of the header and item type verbs

Specification based testing

2004-09-17 Thread Ovid
I'm at work, so I've not had a chance to think too deeply about this, but here's an interesting node about specification-based testing using Test::LectroTest (http://search.cpan.org/~tmoertel/Test-LectroTest-0.2006/) http://www.perlmonks.org/index.pl?node_id=390737 It looks like food for though

Problems Re-Implementing Parrot Forth

2004-09-17 Thread Matt Diephouse
Having mentally absorbed the forth.pasm code, I thought I'd rewrite it in PIR and try to make it a full parrot compiler and, hopefully, a bit more approachable. I've already begun on this (see attached file). Unfortunately, I've run into a few issues/questions along the way. In the following, the

Re: Problems Re-Implementing Parrot Forth

2004-09-17 Thread Steve Fink
On Sep-17, Matt Diephouse wrote: > Having mentally absorbed the forth.pasm code, I thought I'd rewrite it > in PIR and try to make it a full parrot compiler and, hopefully, a bit > more approachable. I've already begun on this (see attached file). > Unfortunately, I've run into a few issues/questio