On Oct 19, 2004, at 1:56 AM, Leopold Toetsch wrote:
Jeff Clites <[EMAIL PROTECTED]> wrote:
On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
Nethertheless we have to create managed objects (a Packfile PMC) so
that we can recycle unused eval-segments.
True, and some eval-segments are "done" as s
[EMAIL PROTECTED] wrote:
Could we have the chunks only hold one frame and avoid much of the
compaction work? If we return to the inderict access mechanism, we
can switch register frames by changing one pointer. But if we keep
the one frame per chunk, we do not need to compact frames, standard
DOD
Sigh. I'll get this right sometime!
Brian
Index: config/auto/jit.pl
===
RCS file: /cvs/public/parrot/config/auto/jit.pl,v
retrieving revision 1.33
diff -u -r1.33 jit.pl
--- config/auto/jit.pl 8 Mar 2004 08:49:05 - 1.33
++
Just to let people know how things are going on win32 (at least from
my perspective).
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t\library\streams.t2 512212 9.52% 14 18
t\pmc\nci
> t\pmc\perlnumNOK 36# got: '0
> # 0
> # '
> # expected: '0
> # -0.00
> # '
Visual C++ compiles "-0.0" to 0.0, which leads to the error. Attached
patch will fix this.
src/string.c
win32-perlnum-negzero.patch
Description: Binary data
Austin Hastings wrote:
Michele Dondi wrote:
On Sun, 17 Oct 2004, Matt Fowles wrote:
Google groups has nothing for Perl6.language between October 2 and 14.
Is this really the case? (I had not signed up until shortly before
Yes: no traffic at all for quite a while...
Does this mean that we're done
Okay, since my calendar's off and it's apparently time to rehash this
*again* (I had this down for next month, but I guess it's a chaotic
cycle). Normally I'd just let it spin out, but we *do* have an issue
with sub call speeds, and I don't see how fiddling with this will do
any harm otherwise.
Michele Dondi wrote:
On Sun, 17 Oct 2004, Matt Fowles wrote:
Google groups has nothing for Perl6.language between October 2 and 14.
Is this really the case? (I had not signed up until shortly before
Yes: no traffic at all for quite a while...
Does this mean that we're done? :)
--- Matt Fowles <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb accidentally introduced a dependency
> on
> Config::IniFiles. Since it is implemented in pure
> perl he offered to
> add it to the repository. Warnock applies.
>
> http://xrl.us/div3
In the note offering to fix it, I also listed nume
On Sun, 17 Oct 2004, Matt Fowles wrote:
Google groups has nothing for Perl6.language between October 2 and 14.
Is this really the case? (I had not signed up until shortly before
Yes: no traffic at all for quite a while...
Michele
--
Except people don't actually read the documentation, and when the
Hello All,
This is my first post to the parrot list, but I hope that many will
follow. Thanks to all of you for working so dilligently on building
this wonderful new toy for all us geeks to play with!
I am currently working on a fix to the large subroutine register
allocation bug, aka, "massive
Leo~
Thanks for the detailed explanation.
On Tue, 19 Oct 2004 10:50:22 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Until around Parrot 0.0.3 there were chunked stacks *with* an
> indirection for the register frame pointers. During development of the
> JIT system these indirections got dr
michel wrote:
Whether or not an old definition is retained if
a word is redefined is a different question, in
the case of Parakeet, it will increment by two
because all high level words are looked up by
name at run-time via indirect threading.
This is an incorrect __Forth__ behaviour. gForth's is
Matt Fowles <[EMAIL PROTECTED]> wrote:
> All~
> This feels similar in spirit to the old framestacks that we used to
> have. I throught that we moved away from those to single frame things
> so that we did not have to perform special logic around continuations.
> I would feel more comfortable if
Michel Pelletier <[EMAIL PROTECTED]> wrote:
> The Python interpreter could use this method too
> to really spank CPython, which has implicit
> stack traffic that cannot be easily optimized
> out.
That's not need. The translater can easily create register code, even
from Python bytecode, which is s
Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Oct 17, 2004, at 3:18 AM, Leopold Toetsch wrote:
>> Nethertheless we have to create managed objects (a Packfile PMC) so
>> that we can recycle unused eval-segments.
> True, and some eval-segments are "done" as soon as they run (eval "3 +
> 4"), whereas
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> The naming of the interpreter structure has changed. The struct is
> now called "parrot_interp_t";
Thanls,
leo
Sam Ruby <[EMAIL PROTECTED]> wrote:
> ... Suggestions welcome, in
> particular, a PIR equivalent to the Perl would be most helpful.
It could be something like below. Some remarks:
* we don't have a notion to create a Closure PMC, so these closures are
handcrafted. (NB: a subroutine with a .yi
Brian Wheeler <[EMAIL PROTECTED]> wrote:
> Here's the diff against the current CVS.
Please append the patch.
,--[ messed up ]---
| > +
| > cc_gen('config/auto/mema
|
| > On Thu, 2004-10-14 at 06:37, Leopold Toetsch wrote:
`
On Mon, Oct 18, 2004 at 09:26:09PM -0400, Dan Sugalski wrote:
> A
> >I have started a test script for the Integer PMC. In that process I found
> >strangeness in get_string(). set_integer_native() can be inherited from the
> >Scalar PMC.
> >
> >For the Undef PMC I fixed an error in set_number_native
On Oct 19, 2004, at 12:42 AM, Leopold Toetsch wrote:
Will Coleda <[EMAIL PROTECTED]> wrote:
t/pmc/signal...Hangup
I saw that once too: looks like the test script got the signal.
That's what my patch from last week was supposed to fix--I'm surprised
it's still happening. We should c
At 14:47 Uhr +0200 16.10.2004, Leopold Toetsch wrote:
Anyway, JIT memOk. There is a test in config/auto/jit/test_exec_openbsd.in,
Ok, I've looked at the test_exec_linux source, and tried it out
separately; it's clear what happens to me now: I've enabled the
following GrSecurity option, which make
Will Coleda <[EMAIL PROTECTED]> wrote:
> My machine did happen to be under a bit of a load at the time the test
> ran, but that doesn't seem like much of an excuse. =)
The test awaits the signal do be delivered in a second or so. Under load
it just may fail.
> t/pmc/signal...Hang
Christian Jaeger wrote:
Ok, I've looked at the test_exec_linux source, and tried it out
separately; it's clear what happens to me now: I've enabled the
following GrSecurity option, which makes the mprotect system call fail
with a permission error - the test even outputs this as the line
"failur
24 matches
Mail list logo
