I'm writing a simple language to embody the concept of copy-on-write, and
so that I can learn how to implement it. The language is called COW and
it's at
http://japhy.perlmonk.org/COW/
Ben Tilly suggested I contact the Perl6 Internals folk and let you know
that this is an important feature th
On Fri, Nov 30, 2001 at 03:45:44PM -0800, Hong Zhang wrote:
> It may be a good idea to have our own version of vsnprintf().
No, I *want* us to have our own version of vsnprintf. Please steal
one from Perl!
--
The debate rages on: Is Perl Bactrian or Dromedary?
> What we really need is our own s(n?)printf:
>
> Parrot_sprintf(target, "%I + %F - %I", foo, bar, baz);
> /* or some such nonsense */
> or even:
> target=Parrot_sprintf("%I + %F - %I); /* like Perl's built-in */
>
> That way, it could even handle Parrot strings nativel
Andy Dougherty:
# This patch will temporarily appease tinderbox.perl.org, but it has
# three medium-term problems:
#
# 1. Configure.pl doesn't figure out HAS_SNPRINTF yet.
That will be hard to deal with. I can't find a symbol in Config.pm
corresponding to the existence of snprintf.
# 2. Syste
I just tried rebuilding parrot with
typedef long double FLOATVAL;
All the tests in t/op/number.t fail miserably. To save space, I'll just
show a few failures. The others are very similar.
1..28
not ok 1 - set_n_nc
# Failed test (Parrot/Test.pm at line 76)
# got:
'-21745
This patch will temporarily appease tinderbox.perl.org, but it has
three medium-term problems:
1. Configure.pl doesn't figure out HAS_SNPRINTF yet.
2. Systems without snprintf() are subject to buffer overflows.
3. The format strings may not be correct. We need Configure.pl
to figure out t
The Win32 tree tinderbox is burning
--snip--
perlint.obj : error LNK2001: unresolved external symbol _snprintf
perlnum.obj : error LNK2001: unresolved external symbol _snprintf
test_prog.exe : fatal error LNK1120: 1 unresolved externals
--snip--
-SlowByte
On Fri, Nov 30, 2001 at 01:30:35AM -0500, Jeff G wrote:
> The code for add/sub/mul/div has to be able to be simplified somehow. It
> passes the requisite tests so I'm calling it good for now, but there's
> probably a very simple optimization that I'm missing at 1:30 A.M.
Thanks very much for this
On Thu, Nov 29, 2001 at 10:51:52PM -0500, Jeff G wrote:
> > Shouldn't we be placing set_p_i and the like in vtable.ops?
> Of course, I meant vtable.tbl.
No you didn't. vtable.tbl is the methods.
> wondering if it wouldn't be better to let a human create the vtable.ops
> file and leave vtable.tbl
