Author: audreyt
Date: Thu May 17 00:29:36 2007
New Revision: 14392
Modified:
doc/trunk/design/syn/S02.pod
doc/trunk/design/syn/S04.pod
doc/trunk/design/syn/S06.pod
Log:
* Fix thrice misspelling of &?BLOCK as $?BLOCK.
Modified: doc/trunk/design/syn/S02.pod
===
All,
Something that tops my current list of Perl 6 features to desire, or
design flaws to deal with, concerns protecting private attributes of
our objects from being mutated outside of our control due to their
being assigned to from arguments to our routines that are mutable.
I want to raise
As a follow-up to this thread, I discussed the matter on #perl6 with
Larry today (before the thread on mutable arguments), and I learned
that one of my main concerns, of inconsistency between different
collection types, is not valid.
http://colabti.de/irclogger/irclogger_log/perl6?date=2007-05
Darren Duncan wrote:
Larry had some ideas for dealing with the problem, but this is a
matter that should be more widely discussed, particularly among
implementers and such.
A general thought is that a parameter could be marked so that any
argument passed through it is effectively snapshot (
On 5/17/07, Andy Dougherty <[EMAIL PROTECTED]> wrote:
On Wed, 16 May 2007, jerry gay wrote:
> good comments... but why keep both function and macro? which would you
> prefer keeping over the other, and why? i can't understand why both
> exist.
In src/debug.c, for handling user input, I don't s
On 5/17/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED]> wrote:
On 5/17/07, via RT Jerry Gay <[EMAIL PROTECTED]> wrote:
> # New Ticket Created by Jerry Gay
> # Please include the string: [perl #42974]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.o
Am Mittwoch, 16. Mai 2007 11:50 schrieb tewk:
> A couple of questions:
>
> 1: Only two pmcs have the const_too flag SArray and ParrotLibrary.
> This seems redundant given that all pmcs except abstract, singleton, and
> const_too pmcs get a read only variant of the vtable. Is there any
> reason, w
this revision breaks parrot on msvc (and i suspect other c89-compliant
compilers--sometimes i wonder if there are any others!)
in particular, in the following chunk (snipped from overall patch for
brevity) the UNUSED(foo) macro is used before variables are declared
in the body of the find_outer()
On Thursday 17 May 2007 09:32:01 jerry gay wrote:
> this revision breaks parrot on msvc (and i suspect other c89-compliant
> compilers--sometimes i wonder if there are any others!)
I doubt even MSVC is C89-compliant, to be honest. It just barfs more often
than GCC on certain things.
> this sit
On 5/17/07, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
On 5/17/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED]> wrote:
> On 5/17/07, via RT Jerry Gay
<[EMAIL PROTECTED]> wrote:
> > # New Ticket Created by Jerry Gay
> > # Please include the string: [perl #42974]
> > # in the subject line of a
On 5/17/07, chromatic <[EMAIL PROTECTED]> wrote:
On Thursday 17 May 2007 09:32:01 jerry gay wrote:
> this revision breaks parrot on msvc (and i suspect other c89-compliant
> compilers--sometimes i wonder if there are any others!)
I doubt even MSVC is C89-compliant, to be honest. It just barfs
On Thu, 17 May 2007 11:13:45 -0700
"jerry gay" <[EMAIL PROTECTED]> wrote:
> char *s = s_key;
> *s = 0;
> however... why is 's' nulled out, directly after it's initialized to
> 's_key'? that looks funny.
The first line declares a pointer, pointing to s_key. The second lin
On Thursday 17 May 2007 11:13:45 jerry gay wrote:
> On 5/17/07, chromatic <[EMAIL PROTECTED]> wrote:
> > Unfortunately, our headers (and even some system headers) don't follow
> > C89:
> then what the heck does c89 compliance mean for parrot, if it's beyond
> our control because we can't change
On 5/17/07, Mark Glines <[EMAIL PROTECTED]> wrote:
On Thu, 17 May 2007 11:13:45 -0700
"jerry gay" <[EMAIL PROTECTED]> wrote:
> char *s = s_key;
> *s = 0;
> however... why is 's' nulled out, directly after it's initialized to
> 's_key'? that looks funny.
The first line d
On 5/17/07, Mehmet Yavuz Selim Soyturk <[EMAIL PROTECTED]> wrote:
On 5/17/07, Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
> Mmmm, is string_compare a wrapper for strcmp() ? Or is it a wrapper that
> reverses the result? (so return true if they're equal). In /that/ case,
> !string_compare() would be
On Wednesday 16 May 2007 21:15:53 Mehmet Yavuz Selim Soyturk wrote:
> The following patch solves that issue.
>
> --- src/pmc/class.pmc (revision 18568)
> +++ src/pmc/class.pmc (working copy)
> @@ -,8 +,9 @@
> PMC*role = VTABLE_get_pmc_keyed_int(interp, role_list,
>
On Thursday 17 May 2007 18:30:08 chromatic wrote:
> Sort of, but it also breaks test #15 in t/pmc/class.t. That's not your
> fault though; the code fails to take into account role composition into
> roles. I keep trying to fix it, but it gets a lot more complex than I
> thought.
>
> I suspect wh
Patrick R. Michaud wrote:
I can't speak for others, but I use this frequently with
"Configure.pl --step=gen::languages". This allows regeneration
of the per-language makefiles (e.g., languages/perl6/Makefile)
without having to go through the entire configure/rebuild
process for all of Parrot
18 matches
Mail list logo
