Author: larry
Date: Tue Dec 19 01:02:59 2006
New Revision: 13494
Modified:
doc/trunk/design/syn/S06.pod
Log:
Rehuffmanized call/goto to callmumble/nextmumble at suggestion of TheDamian++.
Eliminated the capture forms since unary |$args is just fine for that.
Changed interaction of normal sigs
Author: larry
Date: Tue Dec 19 01:20:40 2006
New Revision: 13495
Modified:
doc/trunk/design/syn/S12.pod
Log:
callsame/callwith/nextsame/nextwith mentioned here too.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/t
Author: larry
Date: Tue Dec 19 01:32:45 2006
New Revision: 13496
Modified:
doc/trunk/design/syn/S12.pod
Log:
Duh, it's December.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(orig
Paul Cochrane wrote:
The problem that I'm trying to solve
here is: how do we add the settings information to perl language files
such that it doesn't cause problems with __END__ and __DATA__ blocks,
is testable by perlcritic, emacs *and* vim pick up their settings
values, and it doesn't interfer
My vote is on removing all emacs and vim settings from our source code
files.
and so you can get really bad code appearance.
# New Ticket Created by Jarkko Hietaniemi
# Please include the string: [perl #41110]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41110 >
Original Message
Subject: [PATCH] tru64: compile (src/nci.c) an
On Sat Dec 16 08:13:32 2006, [EMAIL PROTECTED] wrote:
> test.exe or config/auto/jit/test_c.in segfault during configuration on
> Win32. Note that this happent on
> Pentium MMX ( 586 ). The test tests for "fucomip"
> cpu instruction, but the 586 generation CPUs don't
> have it. It's first introduced
Jonathan Worthington wrote:
> Ron Blaschke wrote:
>> Seems like the old Visual C++ Toolkit 2003 is discontinued.
>>
>> http://msdn2.microsoft.com/en-us/visualc/aa336490.aspx
>>
> Aha. If you would have a moment to write these latest changes into
> readme.win32.pod and send in a patch, that'd be
Kevin,
Thanks for the patch! I've managed to apply it (with some changes),
however the following warning flags don't work with my gcc (3.4.5):
#. "-Wfatal-errors "
#. "-Wmissing-field-initializers "
#. "-Wmissing-include-dirs "
#. "-Wvariadic-macr
On Tue, Dec 19, 2006 at 05:20:06PM +0800, Lee Duhem wrote:
> Allison wrote:
> >My vote is on removing all emacs and vim settings from our source code
> >files.
> and so you can get really bad code appearance.
I'm curious, why is that? We're already discouraging (if not
disallowing) hard tabs in t
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The coda is added to all
Paul Cochrane wrote:
Having editor hints in the source can have value as it can reduce the
cage cleaning load by getting the editor to indent people's code
consistently (admittedly this only helps people who use emacs and vim
in this case) so in that sense it is worthwhile having them around.
The
On Wed Jul 12 08:05:52 2006, [EMAIL PROTECTED] wrote:
> turning up the warnings levels in gcc as much as we can
Applied (mostly) in r16195 and r16196. I'll close the ticket as soon
as I know where the extra flags I mentioned earlier should go.
Thanks heaps for the patch!
Paul
On Tuesday 19 December 2006 10:05, Allison Randal wrote:
> The editor hints aren't actually very helpful, but they do add clutter
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
I a
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> to every source file, and a maintenance burden. Both vim and emacs allow
> top-level settings of these preferences, which is a more appropriate
> place for them.
This assumes that all the projects you use the editor for have the
Nicholas Clark wrote:
On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
to every source file, and a maintenance burden. Both vim and emacs allow
top-level settings of these preferences, which is a more appropriate
place for them.
This assumes that all the projects you use the e
Am Montag, 18. Dezember 2006 04:50 schrieb chromatic via RT:
> On Mon May 09 07:36:14 2005, leo wrote:
> > If you are embedding or extending Parrot and linked against libparrot
> > you now have to additionally link with one of:
> >
> >src/null_config.o
> >src/parrot_config.o # prefix :
Am Sonntag, 17. Dezember 2006 09:45 schrieb chromatic via RT:
> garaud and I hope to have fixed this as of r16139, though he still has
> some dynext and dynpmc failures on his FreeBSD 6.2-tobe box.
>
> Can anyone still confirm?
This issue is looking much like a BSD linker options thingy to me. I c
Hi all,
use v6-alpha;
sub no_donut_for_you (Str $junction) {
state $count = 0;
$count++;
return $count;
}
say no_donut_for_you( any( 'a' .. 'd' ) );
no_donut_for_you( any( 'a' .. 'd' ) ).say;
That outputs something like the following on my system (Version: 6.2.13
(r14
On Tue, Dec 19, 2006 at 01:08:14PM -0800, Allison Randal wrote:
> Nicholas Clark wrote:
> >On Tue, Dec 19, 2006 at 10:05:46AM -0800, Allison Randal wrote:
> >
> >>to every source file, and a maintenance burden. Both vim and emacs allow
> >>top-level settings of these preferences, which is a more a
Nicholas Clark wrote:
To seek clarification - having those as global settings for cperl isn't
likely to be an issue? Or having them in editor blocks?
I meant globally.
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl
All it does is turn on cperl mode for emacs, and set tabs to 4 spaces
for vim and emacs. Not likely to significantly interfere with any
repository you work on. (I actually gave up on the tab key in vim years
ago. I type literal spaces, and my brain automatically adjusts my
indenting to the surroun
Are Hash and Array supposed to have different results on unset keys?
$ cat foo.pir
.sub main
load_bytecode 'dumper.pir'
$P1 = new .Hash
$P2 = $P1['bork']
_dumper ($P2)
$P1 = new .ResizablePMCArray
$P1[200] = 'zdrasti'
$P2 = $P1[201]
_dumper ($P2)
$P2 = $P1[100]
_dumper ($P2)
It's really not a big deal, though. For the immediate problem, let's
just make an exception and leave the hints out of Perl files with
__END__ or __DATA__ blocks.
Sounds good. I can update the Perl::Critic policy, and make a note in pdd07.
Mark it as a cage cleaner task for some point down the
24 matches
Mail list logo
