Mike Lambert wrote:
> Fixing BUFFER_external_FLAG is probably a good thing, and I'm up for
> applying them after 008 goes out the door. However, BUFFER_external_FLAG
> and BUFFER_selfpoolptr_FLAG almost seem to have complementary purposes
> I imagine we could either:
> a) make them act identicall
Mike Lambert wrote:
> Unfortunately, I fail to see why this actually fixes any bug.
> string_grow should unmake_COW itself.
The problem is that unmake_COW will always resize the allocation down
to bufused (plus the padding added by mem_allocate). This means that
the buflen test could pass, and
> 4) set P[k], i
>
> Here probably P should be a IN argument, because P itself is neither
> created nor changed, just the array/hash contents is changed.
> Currently only the JITters and imcc are using this flags, so, it should
> be discussed, what OUT really means.
I disagree. If P contains no k
Mr. Nobody wrote:
> Date: Fri, 30 Aug 2002 18:13:27 -0700 (PDT)
> From: Mr. Nobody <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: [PATCH] in makefile, move libparrot.a from "test" to "all"
>
> libparrot.a is not really related to testing, it should belong in "all". This
> patch does so, a
> > $ perl6 -k examples/life-ar.p6 5
> > Running generations
>
> This problem is due to the fact that the argument strings are
> created with the external flag set, which is not properly
> supported by the string and GC modules. Steve posted
> some patches recently that might well fix the problem
> > However, the intermediate filename 'y.tab.c' isn't necessarily portable,
>
> > if I remember my Windows and VMS lore correctly. However, those platforms
> > probably have bison, which understands the simpler -o imcparser.c output
> > option.
>
>
> So the first question actually is, is there a
> > I have a weird bug where concatenation is sometimes failing, and I
> > have no idea why. See the attached pasm. I fully expect both works and
> > weird to output "foo", "bar", "quux" with various levels of spacing,
> > but weird doesn't output quux.
>
> Patch below should fix the problem. This
> This patch is the real fix for strings with the BUFFER_external_FLAG.
> It requires the previous dod.c and resources.c patches to be applied.
>
> Strings marked with the BUFFER_external_FLAG point to the external
> memory rather than making a copy for themselves. Side effects of this
> are (1) l
> Small cleanups, but also a piece of my attempted fixes to the
> BUFFER_external_FLAG. (The CVS version currently doesn't work anyway,
> so don't worry about only getting parts of my fixes in; nothing
> depends on it.)
I'm curious about your dod/external "fix". If I understood the purpose of
BUF
> In tracking down a gc bug, I realized that the current throwaway
> implementation of the print op could be replaced with a faster
> throwaway implementation that avoids doing a string_to_cstring.
>
> Note that both the original and new implementations are still buggy
> with respect to supporting
> This patch trims off the period at the end of executable filenames for
> C-based tests on unix. (It compiled "t/src/basic_1.c" ->
> "t/src/basic_1."; this patch makes that "t/src/basic_1")
This patch should also update languages/perl6/P6C/TestCompiler.pm, since
it hijacks lib/Parrot/Test.pm to
> "KF" == Ken Fox <[EMAIL PROTECTED]> writes:
KF> Simon Cozens wrote:
>> [EMAIL PROTECTED] (Damian Conway) writes:
>>
%hash4 = ("Something", "mixing", pairs => and, "scalars");
>>>
>>> That's perfectly okay (except you forgot the quotes around the
>>> and you have an odd
Damian Conway wrote:
> No. It will be equivalent to:
>
> <[\x0a\x0d...]>
I don't think \n can be a character class because it
is a two character sequence on some systems. Apoc 5
said \n will be the same everywhere, so won't it be
something like
rule \n { \x0d \x0a | \x0d | \x0a }
Hmm.
Simon Cozens wrote:
> [EMAIL PROTECTED] (Damian Conway) writes:
>
>>> %hash4 = ("Something", "mixing", pairs => and, "scalars");
>>
>>That's perfectly okay (except you forgot the quotes around the
>>and you have an odd number of elements initializing the hash).
>
> Urgh, no. Either a pair is a
On Sat, 2002-08-31 at 07:07, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > Is C<\n> going to be a rule (e.g. C<< >>)
>
> There might be an named rule like that. But C<\n> will certainly
> still be available.
>
> > or is it implicitly translated to:
> >
> > <[\x0a\x0d...]>+
>
> No. It
On Sat, 2002-08-31 at 18:45, Steven W McDougall wrote:
Good write-up.
> I tested this theory by hacking mem_allocate() to enforce a minimum
> round-up to an 8-type boundary.
>
> /* Round up to requested alignment */
> if (align_1<7) align_1 = 7; /* <<< HACK */
> size = (size
> > $roundor7 = rx /<+[17]>/
> > That is: the union of the two character classes.
>
> Thank you; that wasn't in A5, E5 or S5. Will there be <-> as
> well?
>From A5:
The outer <...> also naturally serves as a container
for any extra syntax we decide to come up with for
charac
I checked out Parrot from CVS on 2002Aug30 to an IRIX64 system.
shell01:/usr/tmp/swmcd/parrot>uname -a
IRIX64 shell01 6.5 07201611 IP27
make compiled OK.
make test failed all the t/pmc/perlhash.t tests.
Running
parrot t/pmc/perlhash_1.pbc
produced a bus error.
I chased the err
On Saturday, August 31, 2002, at 06:52 AM, Damian Conway wrote:
> my Date $date = Date.new('June 25, 2002');
>
>> my Date $date is now { .init 'June 25, 2002' };
>
> As is that.
Yes, but this:
my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
2002' };
Is shorter
[EMAIL PROTECTED] (Damian Conway) writes:
> Neither. You need:
> $roundor7 = rx /<+[17]>/
> That is: the union of the two character classes.
Thank you; that wasn't in A5, E5 or S5. Will there be <-> as
well?
--
I wish my keyboard had a SMITE key
-- J-P Stacey
[EMAIL PROTECTED] (Damian Conway) writes:
> > %hash4 = ("Something", "mixing", pairs => and, "scalars");
>
> That's perfectly okay (except you forgot the quotes around the
> and you have an odd number of elements initializing the hash).
Urgh, no. Either a pair is an atomic entity or it isn't.
Larry wrote:
> :my $date = Date.new('June 25, 2002');
>
> Assignment is wrong for conferring compile-time properties, I think.
Agreed. For a start, it's too late. The declaration is compile-time;
the assignment, run-time.
> We almost need some kind of topicalization:
>
> my Date $d
Aaron Sherman wrote:
> Is C<\n> going to be a rule (e.g. C<< >>)
There might be an named rule like that. But C<\n> will certainly
still be available.
> or is it implicitly translated to:
>
> <[\x0a\x0d...]>+
No. It will be equivalent to:
<[\x0a\x0d...]>
(no repetition)
> Al
Piers Cawley wrote:
> If I replace C<< ($key, $val) >> with
>
> @ary = m/<$pattern>/
>
> and the match succeeds, how many elements are there in @ary?
Zero. No explicit captures in that pattern.
> Suppose you want to use a hypothetical variable to bind a name to
> a capture
Trey Harris wrote:
>> sub repeat is multi ($desc is valued(1), &body) {
>> body(1);
>> }
>>
>> sub repeat is multi ($desc is valued(0), &body) {
>> }
>>
>> sub repeat is multi ($desc is valued(['A'..'F']), &body) {
>> die "Can't repeat hexadecimally";
Nicholas Clark asked:
>%hash3 = @kv_array
>
> Is perl6 going to spot that @kv_array has an even number of entries, all
> are scalars (no pairs), and so do this
>
>for @kv_array -> key, value {
>%hash3{$key} = $value;
>}
Yes. Just like in Perl 5.
> Or is it going to treat
HellyerP wrote:
> This week I was fortunate enough to hear Damian speak twice, once on
> everything and once on Perl6. Damian, it was tremendous of you to come
> and speak to us in London - thank-you very much.
It was my pleasure.
> If he's coming to a city near you, book
> your seats now.
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #16895]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=16895 >
1)
The following code snippet, appended to anyop.c
strcpy(name, "shl_p_p_ic")
From: "Nicholas Clark" <[EMAIL PROTECTED]>
> In Damian's excellent perl6 talk, I think he said that by default a hash
> in list context will return a list of pairs. Hence this
>
>@array = %hash
>
> for %hash with n keys would give an array of n elements, all pairs.
Will there actually be a
Piers Cawley wrote:
> Unless I'm very much mistaken, the order of execution will
> look like:
>
> $2:=$1; $1:=$2;
You're not binding $2:=$1. You're binding $2 to the first
capture. By default $1 is also bound to the first capture.
Assuming that numbered variables aren't special, the orde
On 31 Aug 2002 at 10:26, Piers Cawley wrote:
> > my $pattern = rx:w / $1:=(\S+) = $2:=(\S+) |
> > $2:=(\S+) = $1:=(\S+) /;
>
> Count the capturing groups. Looks like there's 4 of 'em to me. $1, $2,
> $3 and $4 are automatic variables which, according to the Apocalyp
On 31 Aug 2002 at 0:17, Piers Cawley wrote:
> my $pattern = rx:w / $1:=(\S+) = $2:=(\S+) |
> $2:=(\S+) = $1:=(\S+) /;
>
> @ary = m/<$pattern>/
>
> how many elements are there in @ary? I can
> make a case for 4 quite happily. Certainly that's what A5 seems to
32 matches
Mail list logo
