On Thu, 24 Oct 2002, Damian Conway wrote:
: Adam D. Lopresto wrote:
:
: Really what I've been wishing for was an operator (or whatever) to let me do an
: s// without changing the variable.
:
: I would hope/expect that that's what the subroutine form of Cs would do.
The problem with defining
Steve Fink wrote:
... If not, then just
renaming it to Undef seems best.
I had a closer look at it. Just renaming doesn't: PerlUndef is derived
from PerlInt, which provides major funtionality for it.
If this syllable Perl is really a problem, I will reorganize them
again i a more
On Thu, Oct 24, 2002 at 12:26:41PM -0300, Adriano Nagelschmidt Rodrigues wrote:
Luke Palmer writes:
Lisp is implemented in C, and C's macros are certainly not essential
to its functionality. But think of what macros in general provide:
* Multi-platform compatability
*
On Fri, 25 Oct 2002, Martin D Kealey wrote:
: Going back to Perl5 for a moment, we have
:
: substr($str,$start,$len) = $newstr
:
: why not simply extend pattern-matching in a similar way to substr, making it
: an L-value, so that one gets
:
: $str ~ /[aeiou]+/ = vowels($)
:
: or
:
:
On Thu, 24 Oct 2002, Leopold Toetsch wrote:
Andy Dougherty wrote:
Types:
iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
ptrsize=4, ptr_alignment=4 byteorder=87654321,
The INTVAL2PTR and PTR2INTVAL macros should take care of such a
On Wed, 23 Oct 2002, Erik Lechak wrote:
Anyways, I am on Win XP using VC++. I look in Config.pm and I see this
'#define PARROT_STACK_DIR'. It's not defined to anything, but the code
tries to do math with it. What is this?
This could well be my fault. I recently changed that test. But
Jürgen Bömmels (via RT) wrote:
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18072]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18072
A PackFile created with a diffrent version of
# New Ticket Created by [EMAIL PROTECTED]
# Please include the string: [perl #18078]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18078
Ken,
The already downloaded the new list so just tell Patty to start sending.
On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote:
I've got a patch which switches this detection to happen at run-time
instead of at build-time. This is going to be necessary for miniparrot
(which has no Configure step) anyway.
Have you checked how much this affects the
Dan Sugalski [EMAIL PROTECTED] writes:
The ability to embed arbitrary data in a pbc file under a
named section. This data needs to be readable by the program
when it runs, but is otherwise ignored by the rest of Parrot.
Right, good call. This'll make perl's named embedded filehandles
At 11:57 on 10/24/2002 EDT, Jason Gloudon [EMAIL PROTECTED] wrote:
On Wed, Oct 23, 2002 at 11:23:26PM -0400, Josh Wilmes wrote:
I've got a patch which switches this detection to happen at run-time
instead of at build-time. This is going to be necessary for miniparrot
(which has no
On Thu, Oct 24, 2002 at 04:47:05PM -0400, Josh Wilmes wrote:
I've got a patch which switches this detection to happen at run-time
instead of at build-time. This is going to be necessary for miniparrot
(which has no Configure step) anyway.
Have you checked how much this affects
Obviously spam, sorry folks.
It snuck in under the spam filters.
X-Spam-Status: No, hits=5.3 required=7.0
tests=CARRIAGE_RETURNS,FORGED_HOTMAIL_RCVD,MISSING_HEADERS,NORMAL_HTTP_TO_IP,NO_REAL_NAME,SPAM_PHRASE_00_01,TO_EMPTY
version=2.41
-R (pondering his next move in the unending war against
At 18:16 on 10/24/2002 EDT, Jason Gloudon [EMAIL PROTECTED] wrote:
STACK_DIR is a compile time constant, so the multiplies in the following code
are eliminated by the compiler if it does any optimization. By making
STACK_DIR a variable, the compiler is no longer able to do this and has to
On Oct-23, Dan Sugalski wrote:
At 7:41 PM +0200 10/23/02, Leopold Toetsch wrote:
Possible (feature/architectural) goals for 0.0.9
* PMC cleanup
- Leo did a huge amount of work on this, but there are a few things
left:
- array.pmc still
Dan Sugalski wrote:
At 4:57 PM +0200 10/19/02, Leopold Toetsch wrote:
[ Vtable union ]
Well... the problem is with references. Larry's declared that a
reference must act identically to its referent if used in the right
context. We could force an explicit deref, but I'd rather not.
Andy Dougherty wrote:
Types:
iv=long long, intvalsize=8, intsize=4, opcode_t=long long, opcode_t_size=8,
ptrsize=4, ptr_alignment=4 byteorder=87654321,
The INTVAL2PTR and PTR2INTVAL macros should take care of such a
configuration. Though I'm not to sure, if we can get rid of all
Steve Fink wrote:
Prerequisites for 0.0.9 release
---
* Reclaim the tinderbox!
On one machine I suddenly have additionally:
Failed Test Status Wstat Total Fail Failed List of failed
---
Steve Fink wrote:
- the various unions should probably be coalesced into one
I did check in my datatypes patch.
- all? native and other data types are summarized in datatypes.h
- hash and list use the same enums now
- datatype.c has currently 2 functions to retrieve types per name/enum
Steve Fink wrote:
On Oct-23, Dan Sugalski wrote:
It'd probably be a good idea for us to have a generic undef.pmc for
undefined usage.
Yes, that's what I was saying. Sorry the comment was vague -- all I
meant was that general Parrot PMCs should not be creating
Perl-specific PMCs. I agree
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18072]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18072
A PackFile created with a diffrent version of core.ops leads to
strange not easy
Really what I've been wishing for was an operator (or whatever) to let me do an
s// without changing the variable.
print 'He said '_($statement ~ s/\.$//)_', but we didn't believe him.';
I'm not sure exactly what the semantics would be, but somehow =~ without the =
seems appealing...it's always
Damian Conway wrote:
I certainly wouldn't mind seeing it return to that role, now that
it's not needed elsewhere. And, of course, that would actually be:
$x ~ $y string concatentation
$x ~= $ystring append
~$x stringification
...
$str =~
Larry,
As long as you're trying to figure out how to shoehorn in the last few
available punctuation symbols, and thinking about if there are any
bracketers left, I wondered if there was a chance of a chunking operator
for literate programming? So you can do something like this, if
were the
On Thursday, October 24, 2002, at 11:22 AM, Larry Wall wrote:
But we also have to balance it against the desirability of using ~ for
concatenation. Requiring whitespace around _ is a bit of a
rationalization
after the fact, and ~ escapes that problem in most cases.
So (w/out whitespaces):
On Thu, 24 Oct 2002, Chris Dutton wrote:
: Also, this brings to mind the one thing I actually remember about
: Sather, and as long as we're discussing operators...
:
: Will we have similar to Sather's ::=? That was essentially the
: statically type this variable at run-time based on the type
Larry Wall wrote:
On 20 Oct 2002, Smylers wrote:
: Seems like not too long ago we were short of punctuation symbols,
: and now you've got a spare one lying around.
Pity there's no extra brackets lying around without going to
Unicode...
Well if C~ were made the hyper prefix (squiggly
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
On the other hand, the current rule for recognizing the *end* of a
name in the style of operator:=+ is to go till the next whitespace,
on the assumption that we'll never have (shudder) whitespace operators.
Oooh, I nominate
From: Angel Faus [EMAIL PROTECTED]
Date: Fri, 25 Oct 2002 00:54:09 +0200
All this ones fit more with the concept of mystical analogy hinted
by =~ than with the plain similarity that one would expect from
like
True. Can't say I like, um, like.
Oh, and =~ looks much more intimidating,
Or we could go with Valspeak:
$a is like $b and stuff
At the moment I like like the best, actually...
Hmmm... I could actually see like in a more active role. Along the
lines of:
my str $string;
my $other_string is like $string;
Analogous to saying:
my str $other_string
Except that
At the moment I like like the best, actually...
like is beautiful for old-style regex matching, but I find it
confusing for the new smart abilities:
$varlike Class:Foo # $var is instance of Class:Foo
$item like %hash # %hash{$item} is true
$digit like (0..10) #
Brent Dax wrote:
Can the new nefarious use be concat? Pretty please?
On Wednesday, October 23, 2002, at 07:46 PM, Damian Conway wrote:
I guess the only concern is the potential for nasty surprises between:
$str =~ s/a/b/; substitute a for b in $str
and:
$str ~= s/a/b/; substitute
Luke Palmer writes:
Do you think that Lisp macros make the language more powerful than
others (eg Perl)? I mean, do they really give a competitive
advantage, or are they being overrated (see below)?
If you define powerful as can do more things, then of course not.
No, of course. I guess
On Thu, 24 Oct 2002, Michael Lazzaro wrote:
:$str1 ~ $str2# $str1 =~ m/$str2/
That would be a smart match, not m/$str2/.
:$str ~ /foo/ # $str1 =~ m/foo/
That would work.
:$str2 = ($str ~ /foo/bar/); # perform subst, assign result to $str2
:
:
On Thu, 24 Oct 2002, fearcadi wrote:
: Maybe , my question really is , how perl will behave if I will do
:
: sub operator:=+ (str $x, str $y) { system( $x | $y ) } ;
:
: so this is more question of qrammar ?
The general rule in most lexers has always been that it grabs the
longest token it can
On Thu, 24 Oct 2002, Deborah Ariel Pickett wrote:
: Which looks better?
: if ($a == 1|2|3 || $b eq x|y|z)
: or
: if ($a == 1||2||3 | $b eq x||y||z)
: ?
I think disjunctions of data values should be | and disjunctions of expressions
should be ||, so that the bigger concept has the bigger
On Thu, Oct 24, 2002 at 09:59:00AM -0700, Michael Lazzaro wrote:
Noone ever guesses that =~ means matching
That's because it doesn't. =~ means something more akin to apply
but it's only valid for the three m//, s///, tr/// ops. That'll
change in perl 6 though :-)
If anything, I'd almost
In 'C', we have:
a = b+c;
In Perl, we can have:
$a = $b$c;
(Parseable as $a = $b operator:spacespace operator:tab
operator:spacespace $c;)
Oh frabjous day!
=Austin
--- David Wheeler [EMAIL PROTECTED] wrote:
On Thursday, October 24, 2002, at 10:34 AM, Larry Wall wrote:
On
On Thursday, October 24, 2002, at 02:52 PM, Austin Hastings wrote:
In 'C', we have:
a = b+c;
In Perl, we can have:
$a = $b$c;
(Parseable as $a = $b operator:spacespace operator:tab
operator:spacespace $c;)
Oh frabjous day!
Good Lord, you're sicker than I am!
:-D
David
--
Um, I don't know about your mail program, but mine
converts
operator:tab
to
operator:spacespace operator:spacespace
Anyone for makefiles?
-Original Message-
From: David Wheeler [mailto:david;wheeler.net]
Sent: Thursday, October 24, 2002 5:59 PM
To: [EMAIL
40 matches
Mail list logo
