2008/6/22 jerry gay <[EMAIL PROTECTED]>:
> On Sun, Jun 22, 2008 at 3:38 AM, Bernhard Schmalhofer
> <[EMAIL PROTECTED]> wrote:
>> James Keenan via RT schrieb:
>>>
>>> On Fri Jul 13 09:58:33 2007, bernhard wrote:
>>>
There are several config probes that are only used for language
imple
James Keenan via RT schrieb:
I'm trying to see if we can move this ticket toward resolution. I think
that it has remained unresolved for so long because the original post
originally called for two steps: (a) removal from Configure.pl of
configuration steps which probed for features only used in
On Mon Sep 08 22:54:28 2008, [EMAIL PROTECTED] wrote:
> Patrick R. Michaud wrote:
> >
> > Fixing this shouldn't be all that difficult -- in particular,
> > I think that src/pmc/resizablepmcarray.pmc lines 205-206 should
> > be changed from
> >
> > - if (key >= PMC_int_val(SELF))
> > -
Reini Urban via RT schrieb:
Defining the hash entries for the subs in PIR syntax is awful.
So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax.
For p6 we must ensure that every parrot package has a perl6 also then. Not good.
So pl, pir or the simple nqp.
The libs and script
>> Defining the hash entries for the subs in PIR syntax is awful.
>> So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax.
>> For p6 we must ensure that every parrot package has a perl6 also then. Not
>> good.
>> So pl, pir or the simple nqp.
>
> The libs and scripts could be writ
On Fri Sep 12 02:18:57 2008, bernhard wrote:
> James Keenan via RT schrieb:
> > I'm trying to see if we can move this ticket toward resolution.
> >
> > And that's where discussion left off three months ago. I am
> > recommending the following:
> >
> > (1) Mark this ticket resolved.
> > (2) Condu
Resolved.
chromatic wrote:
Just for clarification, it attached patch is actually what this ticket
about?
Yes, that's correct.
Ok, so I go ahead and try to fix more pmcs. There is single line patch
for float.
--
Bacek
diff --git a/src/pmc/float.pmc b/src/pmc/float.pmc
index d315627..fa03356 100644
--
chromatic wrote:
Yes, that's correct.
There is 2 patches:
1. complex.pmc single replacement of PMC_str_val.
2. string.pmc.
Replaces PMC_str_val;
Replace VTABLE_get_string(INTERP, SELF) with SELF.get_string();
In set_*_keyed change logick to invoke VTABLE_set_string_native
instead of rep
On Fri, Sep 12, 2008 at 05:03:20PM -0700, [EMAIL PROTECTED] wrote:
> [...]
> (2) Test.pm gets Object rather than Any on its multis;
> this may or may not be the Right Thing.
perl6-language may end up disagreeing with me on this, but I would
much prefer things (from a implementation bootstrapping
On Fri, Sep 12, 2008 at 04:55:39PM -0700, [EMAIL PROTECTED] wrote:
> Log:
> [rakudo] If we are calling ACCEPTS in a multi-dispatch to do a
> type-check, then because blocks are not differentiated from
> regexes at the moment we get exceptions when trying to store $/.
> This patch wraps that code
On Fri, Sep 12, 2008 at 04:41:38PM -0700, [EMAIL PROTECTED] wrote:
> [rakudo] Constraints in a signature should actually be represented
> as an all Junction, not an array.
You may have thought of this already, but it'd be worthwhile to
consider how we might handle infix: (added to the Synopses
t
On Fri, Sep 12, 2008 at 03:47:27PM +0200, NotFound wrote:
> >> Defining the hash entries for the subs in PIR syntax is awful.
> >> So I envision Makefile.pl, Makefile.nqp or Makefile.p6 for this syntax.
> >> For p6 we must ensure that every parrot package has a perl6 also then. Not
> >> good.
> >>
# New Ticket Created by Will Coleda
# Please include the string: [perl #58812]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=58812 >
After many weeks away from tcl, I tried to do a make test today
(r31046) and found a segf
On Friday 12 September 2008 19:48:30 Will Coleda wrote:
> After many weeks away from tcl, I tried to do a make test today
> (r31046) and found a segfault.
>
> I can't easily generate PIR to narrow it down, because even the --pir
> option is segfaulting.
>
> doing a build and just running "../../pa
Hi Larry,
# from Larry Wall
# on Thursday 11 September 2008 12:13:
>So when you put something into a list context, some of the values
>will be considered "easy", and some will be considered "hard".
>The basic question is whether we treat those the same or differently
>from a referential point of
On our Smolder site, we're getting test results on FreeBSD (or, at
least, i386-freebsd-64int) approximately every 70 minutes.
Is there any reason to keep this ticket open?
Thank you very much.
kid51
On Fri Sep 12 20:24:06 2008, [EMAIL PROTECTED] wrote:
> On our Smolder site, we're getting test results on FreeBSD (or, at
> least, i386-freebsd-64int) approximately every 70 minutes.
>
> Is there any reason to keep this ticket open?
>
E ... we *were* getting hourly reports on FreeBSD up thr
Qui, 2008-09-11 às 12:13 -0700, Larry Wall escreveu:
> And I guess the fundamental underlying constraint is that a list cannot
> be considered immutable unless its feeds can be considered immutable,
> at least in some kind of idempotent sense. This conflicts with the
> whole point of reactive prog
On Fri, Sep 12, 2008 at 11:33 AM, Daniel Ruoso <[EMAIL PROTECTED]> wrote:
> In SMOP, I'm probably going to presume that everything needs to be lazy,
> then even:
>
> my @o = grep { /\d+/ } =$*IN;
> my @a = (1,2,(3,4,@o));
> my @b = (1,2,(3,4,@a));
Can only one array "have" the iterator? If not,
20 matches
Mail list logo
