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?
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
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
-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
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
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
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
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
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)
-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 ==
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 am I
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
* 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 the
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 condition be
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
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 right way to
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
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]} #
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 are
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
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
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
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
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}#
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
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
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
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
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.
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
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
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 unlikely
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= secondary
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
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
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
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/questions
37 matches
Mail list logo
