On Feb 5, 2008 8:11 PM, Larry Wall <[EMAIL PROTECTED]> wrote:
> Oh wait, I lied. You can get pugs to do it with:
>
> my $a = 0; my @b; (lazy { VAR($a) }, lazy { VAR(@b[$a]) }) = 1,2; say
> @b.join(':')
>
> Now just put that in a macro...
Ah, macros, is there no problem you can't solve? :)
T
On Tue, Feb 05, 2008 at 05:42:28PM -0500, Mark J. Reed wrote:
: On Feb 5, 2008 5:34 PM, Darren Duncan <[EMAIL PROTECTED]> wrote:
: > >+my $a = 0; my @b;
: > >+($a, @b[$a]) = 1, 2;
: > >+
: > >+assigns 2 to @b[0], not @b[1].
: >
: > Personally, I think this is a particularly welcome change.
On Tue, Feb 05, 2008 at 02:34:35PM -0800, Darren Duncan wrote:
> At 9:15 AM -0800 2/5/08, [EMAIL PROTECTED] wrote:
>> +The left side is evaluated completely for its sequence of containers before
>> +any assignment is done. Therefore this:
>> +
>> +my $a = 0; my @b;
>> +($a, @b[$a]) = 1, 2;
On Feb 5, 2008 5:34 PM, Darren Duncan <[EMAIL PROTECTED]> wrote:
> >+my $a = 0; my @b;
> >+($a, @b[$a]) = 1, 2;
> >+
> >+assigns 2 to @b[0], not @b[1].
>
> Personally, I think this is a particularly welcome change.
It is certainly less surprising, I'd say. But is there a LET*
analogue to
At 9:15 AM -0800 2/5/08, [EMAIL PROTECTED] wrote:
+The left side is evaluated completely for its sequence of containers before
+any assignment is done. Therefore this:
+
+my $a = 0; my @b;
+($a, @b[$a]) = 1, 2;
+
+assigns 2 to @b[0], not @b[1].
Personally, I think this is a particularl
--- Larry Wall <[EMAIL PROTECTED]> wrote:
> Besides $^_ is just uglier than anything else I've seen today...
lol -- I thought of it as a rather cute peeking-wink with a cauliflower
ear, but that's probably much more cutesiness than we want to encourage
in our language design.
===
On Mon Nov 08 19:57:18 2004, coke wrote:
> I was talking with Dan on IRC about what we're going to do as a
> replacement for macros. Talk turned to implementing a registered
> 'compile'r for "pre parsed PIR".
>
> For this to be useful, of course, we'd need to be able to run it from
> the command l
On Tue, Feb 05, 2008 at 11:57:37AM -0800, Jonathan Lang wrote:
: Larry Wall wrote:
: > : Is it forbidden to use placeholder parameters in conjunction with
: > : "my"? Or would it simply not do anything useful? I ask because "Do
: > : what I mean" would seem to imply that 'my Dog $^foo' would spec
Robert has implemented this change on the smokeserver, which is now
displaying smoke report times in UTC as the home page has always claimed
to do. Resolving ticket.
Just a note: snprintf is problematic on older Solaris systems (x86 anyway),
for one. At least through 2.7 (2.8?) it's no included in any lib. So
other apps needed to test and bring in their own version.
a
Andy Bach
Systems Mangler
Internet: [EMAIL PROTECTED]
Voice: (608) 261-5738 Fax: 264-5932
Larry Wall wrote:
> : Is it forbidden to use placeholder parameters in conjunction with
> : "my"? Or would it simply not do anything useful? I ask because "Do
> : what I mean" would seem to imply that 'my Dog $^foo' would specify
> : $^foo's type as 'Dog'. Though if you start doing too much of t
On Tuesday 05 February 2008 11:36:00 Andy Lester wrote:
> Ignoring the length
> parameter leaves those platforms without snprintf() exactly where they
> are today.
... the PIT of VILE DESPAIR!
When the inevitable revolution comes, I'm going to put their maintainers up
against the wall and f
On Feb 5, 2008, at 1:17 PM, [EMAIL PROTECTED] wrote:
(He sent this to me directly by mistake)
snprintf is problematic on older Solaris systems, for one. At least
through 2.7 (2.8?) it's not included in any lib. So other apps
needed to
test and bring in their own version.
This is covered
On Tue, Feb 05, 2008 at 10:42:35AM -0800, Jonathan Lang wrote:
: > +++ doc/trunk/design/syn/S03.podTue Feb 5 09:55:29 2008
: > @@ -2791,7 +2791,7 @@
: > are insufficient for defining the "pecking order" of code. Note that
: > you can bind to either a bare block or a pointy block. Bindi
On Feb 5, 2008 11:08 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Constructions like this give me the willies:
>
>char * const buf = (char *)mem_sys_allocate(16);
>sprintf(buf, "%d", type);
>
i saw this code the other day, and thought, "gee, malloc's just gonna
grab 64 anyway. that's silly.
Constructions like this give me the willies:
char * const buf = (char *)mem_sys_allocate(16);
sprintf(buf, "%d", type);
Yes, I know that 16 characters is more than enough, but I still don't
like it. I'd prefer it if we were using instead
snprintf(buf, 16, "%d", type);
I suspect there
> +++ doc/trunk/design/syn/S03.podTue Feb 5 09:55:29 2008
> @@ -2791,7 +2791,7 @@
> are insufficient for defining the "pecking order" of code. Note that
> you can bind to either a bare block or a pointy block. Binding to a
> bare block conveniently leaves the topic in C<$_>, so the fi
Author: larry
Date: Tue Feb 5 09:55:29 2008
New Revision: 14501
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S03.pod
doc/trunk/design/syn/S06.pod
Log:
Added named placeholders using $:foo twigil; idea from cognominal++:
Placeholder subs can now also autoadd [EMAIL PROTECT
Author: larry
Date: Tue Feb 5 09:15:04 2008
New Revision: 14500
Modified:
doc/trunk/design/syn/S03.pod
Log:
Clarify that lhs of list assignment is list of containers, not thunks
Modified: doc/trunk/design/syn/S03.pod
==
I had removed the PARROT_API from ld() in list.c because we don't need
to offer as a public function to the user a function that computes
logs base 2. fperrad reverted that because it broke "make hello".
It seems to me that this is backwards, just like my PARROT_APIing some
other something
On Wed Aug 16 23:09:16 2006, mdiep wrote:
> I don't know how to write a test for this off the top of my head, but
> Iterator and DynLexPad don't play well together atm. When I tried, I
> got this error:
>
> elements() not implemented in class 'DynLexPad'
>
> Is there an easy way to make
21 matches
Mail list logo
