Is there a reason why we have "find_type", but "loadlib"; "eq_str" but "isnull" ?
On Sat, Nov 20, 2004 at 10:46:03AM -0500, Andy Dougherty wrote:
> On Fri, 19 Nov 2004, Patrick R. Michaud wrote:
>
> > On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
> > >
> > > Ok, here's a first pass. Most of it is pretty straightforward
>
> One spot I may have goofed: I chan
> Parrot's locks will all have wait/signal/broadcast capabilities. We
> should go rename the macros and rejig the code. This may have to wait
Really? I'm not sure I understand what broadcast does on a lock. Are
you talking about something like P5's condpair? If so, why not just
cop that code? Of c
On Fri, 19 Nov 2004 15:35:44 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Gabe Schaffer wrote:
> > Win32 doesn't require anything else, but I don't think I like this
> > idea. If you do COND_INIT(c, m) and Win32 ignores the 'm', what
> > happens when some code goes to LOCK(m)? It would work
Ken Fox ("perl6 Kakapo") has mailed me a link [1] and some hints about
PIC - Polymorphic Inline Cache.
This is quite an interesting idea about dynamic recompiling and caching
of method lookups. And it smells like more MOPS and generally just a
faster Parrot VM. So I've hacked together an initia
All:
oo1-prop.pasm and oo2-prop.pasm are both broken. The
only way I knew this was that there times in the
benchmark graphs had dropped off the map. It was
previously proposed to make the benchmarks part of the
test suite being sure not to include anything that
took a substantial amount of time (
On Fri, 19 Nov 2004, Patrick R. Michaud wrote:
> On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
> >
> > Ok, here's a first pass. Most of it is pretty straightforward
One spot I may have goofed: I changed some initializations from "" to
NULL, which is, of course, rather a differ
On Sat, Nov 20, 2004 at 09:23:36AM +0100, Lars Balker Rasmussen wrote:
> Andy Dougherty <[EMAIL PROTECTED]> writes:
> > /* strcon(...) converts string values into PIR string constants */
> > static char*
> > strcon(const char* s, int len)
>
> Haven't looked at the code yet, but I'll just observe
On Sat, Nov 20, 2004 at 12:18:17AM +, Nicholas Clark wrote:
> $ ../../parrot demo.pir
> input /pattern, string to match, + to continue match, ? to print pir,
> /
> Unrecognized character at offset 1 (found '')
> Segmentation fault
>
> Is this a known limitation? [Done after Andy's patch went
On Fri, Nov 19, 2004 at 04:30:06PM -0500, Andy Dougherty wrote:
>
> Ok, here's a first pass. Most of it is pretty straightforward, but one
> thing is worth noting:
>
> The code uses both signed and unsigned chars, with and without the 'const'
> qualifier. I gather this is a deliberate part of a
James deBoer <[EMAIL PROTECTED]> wrote:
> Sorry for the delay, but here is a revised patch to detect perldoc.
No problem, and thanks, applied.
This looks a bit bulky ...
> + Configure::Data->set(perldoc => 0);
> + Configure::Data->set(notperldoc => 1);
... but given that I didn't even
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Exceptions are not, by default, resumable.
Are there non-default resumable exceptions?
leo
Andy Dougherty <[EMAIL PROTECTED]> writes:
> --- parrot-orig/compilers/p6ge/p6ge_gen.c Fri Nov 19 08:53:40 2004
> +++ parrot-andy/compilers/p6ge/p6ge_gen.c Fri Nov 19 14:43:43 2004
> /* strcon(...) converts string values into PIR string constants */
> static char*
> -strcon(const char* s,
13 matches
Mail list logo
