Peter Sinnott <[EMAIL PROTECTED]> wrote:
> Possibly unrelated.
Yes :)
> eval_4.pasm seems to be falling over on redhat as 3 when running
> with jit.
Yep. I've seen that too. I'm investigating.
Thanks,
leo
Perl 6 Summary for 2004-11-22 through 2004-11-29
All~
Rather than try to do something witty about the strange music I am
listening to, or the stuffed animals who are assisting me. I will start
this summary off with an entirely self-serving request. A while
ago I saw the quote "
At 8:46 PM -0500 11/29/04, Dan Sugalski wrote:
It requires being somewhat careful with what ops we put *in*.
And since I wasn't clear (This stuff always obviously makes little
sense only after I send things...), I meant in the switch/cgoto/jit
core loop, not what ops are actually ops.
--
Dan
At 8:32 PM -0500 11/29/04, Michael Walter wrote:
There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.
Oh, absolutely. In this case the issues are personal taste (Leo
doesn't like the big list) and issues with specif
At 9:20 AM +0100 11/24/04, Leopold Toetsch wrote:
Too many opcodes
Bluntly, no. Not too many opcodes.
This has been an ongoing issue. I'm well aware that you want to to
trim down the opcode count for ages and replace a lot of them with
functions with a lightweight calling convention. Well, we alr
There is also such thing as premature "pessimization". I'm not in the
position to judge whether it is appropriate in this case, though.
Back-to-reading-mode-ly yours,
Michael
On Mon, 29 Nov 2004 20:25:48 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 8:29 AM +0100 11/28/04, Leopold Toetsch
At 3:02 PM +0100 11/25/04, Leopold Toetsch wrote:
Transcendental (and some other) ops that have a FLOATVAL out
argument and INTVAL source argument(s) are deprecated.
No, dammit, they are *not* deprecated.
Like the other numeric ops, this isn't your call. Leave them in.
--
At 8:29 AM +0100 11/28/04, Leopold Toetsch wrote:
Thomas Seiler <[EMAIL PROTECTED]> wrote:
Dan Sugalski wrote:
At 10:34 AM +0100 11/27/04, Leopold Toetsch wrote:
See also subject "Too many opcodes".
>> [...]
>>
Could you undo this please? Now is not the time to be trimming ops out.
When is
At 12:23 PM -0500 11/29/04, brian wheeler wrote:
Fair enough. However, shouldn't the rest of the opcodes with an IO
object as their parameter be methods as well? Its not a lot of ops, but
it would trim down the core a bit.
They should -- it'll make it easier to abstract things out later when
peo
Right, so with at least a basic rework of the string stuff in, it's
time to turn our attention to objects and all the stuff that goes
with them.
I'd originally thought that the bits we'd put in place would be
sufficient to do everyone's object system (well, all the languages
that we explicitly
Fair enough. However, shouldn't the rest of the opcodes with an IO
object as their parameter be methods as well? Its not a lot of ops, but
it would trim down the core a bit.
Brian
On Thu, 2004-11-25 at 08:00 +0100, Leopold Toetsch wrote:
> Brian Wheeler <[EMAIL PROTECTED]> wrote:
> > I noticed
A fresh checkout of parrot failed trying to create ops.h. The
problem is that the directory include/parrot/oplib/ is not listed in
MANIFEST and hence doesn't exist. I'm guessing this is a left-over from
the ops cleanup.
This patch ensures that the directory exists before trying to write to it.
(
Hello All,
I haven't been able to devote much time lately, but this week I hope
to modify the register allocator to deal with these arcs, as well as
enhancements to the spill code. I expect that in some cases it will
have a definite impact on speed, and others it won't. Most of the test
cases (ma
All~
I get segfaults (mentioned previously) on signal_1.pasm and signal_2.pasm
Despite these, make test reports success.
For the interested:
[EMAIL PROTECTED]:~/parrot$ uname -a
Linux fowles 2.6.8-1-686 #1 Thu Nov 11 13:18:29 EST 2004 i686 GNU/Linux
Fairly stock debian system (usually pretty fo
At 11:06 AM -0500 11/29/04, Matt Fowles wrote:
All~
On Mon, 29 Nov 2004 14:51:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It seems to me that there is no good solution to this problem without
> annotating the register set or killing the register
On Mon, Nov 29, 2004 at 03:32:19PM +0100, Leopold Toetsch wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
>
> > make testj hangs on string_102.pasm. Here's the gdb backtrace.
>
> I can't reproduce that. Another Redhat or NPTL problem?
>
> leo
Possibly unrelated.
eval_4.pasm seems to be fallin
First pass of this is done and available at:
http://www.parrotcode.org/examples/
> [odin - Wed Nov 24 12:15:07 2004]:
>
> The parrotcode.org website has an 'Examples' section, which
> (currently) contains only PASM. PIR examples would need to be added.
>
>
All~
On Mon, 29 Nov 2004 14:51:43 +0100, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Luke Palmer <[EMAIL PROTECTED]> wrote:
> > It seems to me that there is no good solution to this problem without
> > annotating the register set or killing the register allocator.
>
> I think I've proposed a re
Luke Palmer <[EMAIL PROTECTED]> wrote:
> It seems to me that there is no good solution to this problem without
> annotating the register set or killing the register allocator.
I think I've proposed a reasonable solution: putting lexicals in
registers.
> Luke
leo
Luke Palmer <[EMAIL PROTECTED]> wrote:
> make testj hangs on string_102.pasm. Here's the gdb backtrace.
I can't reproduce that. Another Redhat or NPTL problem?
leo
Parrot Assembler via RT writes:
> make testj hangs on string_102.pasm. Here's the gdb backtrace.
It looks like a really subtle, nasty problem. If I add a noop anywhere
in the top section of code (before MAIN) it works. It works even if I
change the filename from string_102.pasm to test.pasm!
# New Ticket Created by Luke Palmer
# Please include the string: [perl #32676]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32676 >
make testj hangs on string_102.pasm. Here's the gdb backtrace.
% gdb parrot
GNU gdb
It seems to me that there is no good solution to this problem without
annotating the register set or killing the register allocator. So
perhaps we should keep the non-pmc registers at value semantics; that
is, continuations simply restore their value when the continuation was
taken.
Yes, I know
On Mon, 29 Nov 2004 01:44:42 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
> On Nov 28, 2004, at 4:58 AM, Herbert Snorrason wrote:
> You cheated:
>
> Revised^5 Report on the Algorithmic Language Scheme: 50 pages.
Actually, I didn't look for that. Interesting info. Admittedly, I also
missed ISO 718
On Nov 28, 2004, at 2:48 AM, Piers Cawley wrote:
I just thought of a heuristic that might help with register
preservation:
A variable/register should be preserved over a function call if either
of the
following is true:
1. The variable is referred to again (lexically) after the function has
re
On Nov 28, 2004, at 4:58 AM, Herbert Snorrason wrote:
On Sat, 27 Nov 2004 21:49:49 -0500, Michael G Schwern
<[EMAIL PROTECTED]> wrote:
On Sat, Nov 27, 2004 at 09:58:44PM +, Herbert Snorrason wrote:
It should. EcmaScript is also a relatively small language, which
would
work strongly in its adv
Herbert Snorrason wrote:
On Sat, 27 Nov 2004 22:48:42 +0100, liorean <[EMAIL PROTECTED]> wrote:
CLR, JVM and C/C++ implementations exists. As parrot is supposed to be
better for dynamic languages, I guess EcmaScript 3.0 would fit right
in with parrot.
I'd love to contribute. Could one write an i
27 matches
Mail list logo
