On Mon, 24 Sep 2001, Simon Cozens wrote:
>When tests fail for Really Bad reasons, they tend to do something like this:
>
>Got: '
>'
>Expected: '
>ok 1
>...
>'
>
>It'd be really nice if we could intercept that and give more detail on why
>the test failed. Did the assembler compile to a PBC ok? Did
On Tue 25 Sep 2001 06:00, "Kenneth YK Young" <[EMAIL PROTECTED]> wrote:
> I listened in for a while but no one mentioned
> Windows CE as a target. I believe that's becoz no
> perl5 on Windows CE?
But there *is* perl5 for WinCE. I've just passed the majority of the base
bleadperl test suite on Wi
Buggs:
# Collect all the P(ok)emons on the Core Platforms
# and try to find the secret ways to the None Core Platforms.
# Then proceed to level 0.0.2.
#
# --
# CORE PLATFORMS
# --
# ===
# Linux (x86):
# make ok / test ok
# ===
> > -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */
> > - /* function table */
> > -STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */
> > +opcode_t *(**opcode_funcs)(); /* Opcode function table */
> > +STRING_F
On Monday 24 September 2001 22:59, Buggs wrote:
> On Monday 24 September 2001 22:48, Simon Cozens wrote:
> > On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
> > > Tru64
> > > make ok / test fails
> >
> > Can I have some more data on this? Works perfectly here.
>
> The machine from Compaq Te
On Tue, 25 Sep 2001, Kenneth YK Young wrote:
>
> I listened in for a while but no one mentioned
> Windows CE as a target. I believe that's becoz no
> perl5 on Windows CE?
Nope. More because we've no development tools or platform for
WinCE. (Unless the iPaq counts, but I presume it doesn't) I'd
I listened in for a while but no one mentioned
Windows CE as a target. I believe that's becoz no
perl5 on Windows CE?
Can someone advise what needs to be done to port
perl6 to CE (with or without porting perl5 first)?
If I have the prerequisites, I'm willing to help - for fun.
(Though I don'
On Monday 24 September 2001 11:54 am, Dan Sugalski wrote:
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging event" bit permanently set.
> Dunno whether
On Tuesday 25 September 2001 00:00, Simon Cozens wrote:
> When tests fail for Really Bad reasons, they tend to do something like
> this:
>
> Got: '
> '
> Expected: '
> ok 1
> ...
> '
>
> It'd be really nice if we could intercept that and give more detail on why
> the test failed. Did the assembler
Yet more fun with testing... patch at bottom, rambling first
noop didn't have a test, ironic yes, but imagine the shame if it didn't work.
Also time and bitwise ops tests. For the bitwise ops I've tried to be
platform nice, these tests merely exercise the ops, rather than anything
else.
BUG: c
When tests fail for Really Bad reasons, they tend to do something like this:
Got: '
'
Expected: '
ok 1
...
'
It'd be really nice if we could intercept that and give more detail on why
the test failed. Did the assembler compile to a PBC ok? Did the interpreter
segfault? (This is what usually happ
All --
I've created a varargs-ish example by making a new op, print_s_v.
This is pretty rough, and I haven't updated the assembler, but it
seems to work.
I'm attaching a patch, and a test program (pt.pasm).
Enjoy!
-- Gregor
___
On Monday 24 September 2001 22:48, Simon Cozens wrote:
> On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
> > Tru64
> > make ok / test fails
>
> Can I have some more data on this? Works perfectly here.
The machine from Compaq Testdrive.
Compaq Tru64 Unix 5.1(JAVA) ES40 4@667MHz (ev6)
On Mon, Sep 24, 2001 at 10:44:33PM +0200, Buggs wrote:
> Tru64
> make ok / test fails
Can I have some more data on this? Works perfectly here.
--
To downgrade the human mind is bad theology.
- C. K. Chesterton
Collect all the P(ok)emons on the Core Platforms
and try to find the secret ways to the None Core Platforms.
Then proceed to level 0.0.2.
--
CORE PLATFORMS
--
===
Linux (x86):
make ok / test ok
===
CygWin
Con
> > GNU does offer the gettext tools library for just such a purpose. I don't
> > know how it will translate to the various platforms however, and it likely
> > is a major overkill for what we are trying to do.
> > http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
> > It migh
> >
> >I have a minor issue with a proliferation of createArray. In perl5 we
> >used the Stack for just about everything minus physically setting @x =
> >(1,2,3). The creation of a dynamic array is a memory hog.
>
> Less of a hog in many ways than using a stack. Worth the times when it's not.
I
On Mon, 24 Sep 2001, Uri Guttman wrote:
> >> then what about a win/win? we could make the event checking style a
> >> compile time option.
>
> DS> Odds are you'll get per-op event checking if you enable debugging,
> DS> since the debugging oploop will really be a generic "check event
>
On Mon, Sep 24, 2001 at 03:16:47PM -0400, Steven W McDougall wrote:
> t/op/number.t 255 6528023 144 626.09% 1-23
> 6/74 subtests failed
Looks like Test::Harness has no brains either.
--
For true believers, LORD would be K\textsc{nuth} in TeX, and
L\textsc{amport} in LaTeX. Atheists prefe
> Just out of interest, what are the tests looking like on IRIX?
mmm...not so good.
- SWM
world:~/src/Perl/parrot>uname -a
IRIX64 world 6.2 03131016 IP19
world:~/src/Perl/parrot>make test
perl t/harness
t/op/basic..ok 1/2skip() is UNIMPLEMENTED! at
/home/abhaile/swmcd/perl/lib/s
ite_perl/
At 08:42 PM 9/24/2001 +0200, Paolo Molaro wrote:
>On 09/24/01 Michael Maraist wrote:
> > > GNU does offer the gettext tools library for just such a purpose. I don't
> > > know how it will translate to the various platforms however, and it
> likely
> > > is a major overkill for what we are trying
At 02:25 PM 9/24/2001 -0400, Gregor N. Purdy wrote:
>Fortunately, there is a perfectly rational definition of the mod(x,y)
>function over the full domains of x and y, and even for x and y that
>are not integral. This can be found in the book Concrete Mathematics,
>Second Edition by Graham, Knuth a
At 01:03 PM 9/24/2001 -0400, Michael Maraist wrote:
> > > is it possible the ops to handle variable number of arguments, what I
> have
> > > in mind :
> > >
> > > print I1,",",N2,"\n"
> >
> > This should be done by create array opcode plus print array opcode.
> >
> > [1, 2, 3, 4, 5]
>
>I have a
On 09/24/01 Michael Maraist wrote:
> > GNU does offer the gettext tools library for just such a purpose. I don't
> > know how it will translate to the various platforms however, and it likely
> > is a major overkill for what we are trying to do.
> > http://www.gnu.org/manual/gettext/html_mono/gett
On Mon, 24 Sep 2001, Uri Guttman wrote:
> > "AB" == Alan Burlison <[EMAIL PROTECTED]> writes:
>
> AB> If you are interested, I'll try to get a copy of the paper to you.
> AB> It has some interesting ideas. By having 'arenas' for each object
> AB> type, you can remove a large part of th
All --
As I understand it, computer languages differ in their implementation
of the mod() function. I've heard some architectures differ, too, so
that the same language (such as C or Perl) might behave differently on
different machines (I'd be interested to know if this is really true).
Fortunat
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> then what about a win/win? we could make the event checking style a
>> compile time option.
DS> Odds are you'll get per-op event checking if you enable debugging,
DS> since the debugging oploop will really be a generic "check even
> >Just curious, do we need a dedicated zero register and sink register?
>
> I've been pondering that one and waffling back and forth. At the moment I
> don't think so, since there's no benefit to going with a zero register
over
> a zero constant, but that could change tomorrow.
For example,
--- Hong Zhang <[EMAIL PROTECTED]> wrote:
> Just curious, do we need a dedicated zero register and
> sink register?
> The zero register always reads zero, and can not be
> written. The sink
> register can not be read, and write to it can be ignored.
Those, probably not = we have a real nop, and i
At 09:39 AM 9/24/2001 -0700, Hong Zhang wrote:
> > Attached patch makes sure you don't try and use register numbers over
> > 31. That is, this patch allows registers I0-I31 and anything else gets
> > a: Error (foo.pasm:0): Register 32 out of range (should be
> > 0-31) in 'set_i_ic'
> >
> > Oh, the
At 12:38 PM 9/24/2001 -0400, Michael Maraist wrote:
> > GNU does offer the gettext tools library for just such a purpose. I don't
> > know how it will translate to the various platforms however, and it likely
> > is a major overkill for what we are trying to do.
> > http://www.gnu.org/manual/gette
At 12:27 PM 9/24/2001 -0400, Michael Maraist wrote:
> > >then what about a win/win? we could make the event checking style a
> > >compile time option.
> >
> > Odds are you'll get per-op event checking if you enable debugging, since
> > the debugging oploop will really be a generic "check event eve
On Sat, Sep 22, 2001 at 11:56:26PM +0100, Alex Gough wrote:
> I wrote some tests today...
Thanks, applied.
--
A year spent in artificial intelligence is enough to make one believe in God.
> Just curious, do we need a dedicated zero register and sink register?
> The zero register always reads zero, and can not be written. The sink
> register can not be read, and write to it can be ignored.
I brain-stormed this idea a while ago, and here's what I came up with.
We're not RISC, so we
We could use the bsd gettext though, couldn't we?
--Josh
At 12:49 on 09/24/2001 PDT, "Wizard" <[EMAIL PROTECTED]> wrote:
> Michael Maraist wrote:
> > But wouldn't that make parrot GPL'd?
> Yes, Yes it would.
> (cup o' coffee and a sux donut, please.)
> Never mind. I'll take a look at the docs
> > is it possible the ops to handle variable number of arguments, what I have
> > in mind :
> >
> > print I1,",",N2,"\n"
>
> This should be done by create array opcode plus print array opcode.
>
> [1, 2, 3, 4, 5]
I have a minor issue with a proliferation of createArray. In perl5 we
used the St
Michael Maraist wrote:
> But wouldn't that make parrot GPL'd?
Yes, Yes it would.
(cup o' coffee and a sux donut, please.)
Never mind. I'll take a look at the docs and look around some more and see
what other clever ideas we can't use.
Grant M.
> Attached patch makes sure you don't try and use register numbers over
> 31. That is, this patch allows registers I0-I31 and anything else gets
> a: Error (foo.pasm:0): Register 32 out of range (should be
> 0-31) in 'set_i_ic'
>
> Oh, there's also a comment at end of line patch that has snuck i
> GNU does offer the gettext tools library for just such a purpose. I don't
> know how it will translate to the various platforms however, and it likely
> is a major overkill for what we are trying to do.
> http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
> It might make sen
> is it possible the ops to handle variable number of arguments, what I have
> in mind :
>
> print I1,",",N2,"\n"
This should be done by create array opcode plus print array opcode.
[1, 2, 3, 4, 5]
The create array opcode takes "n" top of stack (or "n" of registers)
and create an array out of
GNU does offer the gettext tools library for just such a purpose. I don't
know how it will translate to the various platforms however, and it likely
is a major overkill for what we are trying to do.
http://www.gnu.org/manual/gettext/html_mono/gettext.html#SEC2 - Purpose
It might make sense to impl
> >then what about a win/win? we could make the event checking style a
> >compile time option.
>
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging even
> Odds are you'll get per-op event checking if you enable debugging, since
> the debugging oploop will really be a generic "check event every op" loop
> that happens to have the "pending debugging event" bit permanently set.
> Dunno whether we want to force this at compile time or consider some w
At 10:46 AM 9/24/2001 -0400, Michael Maraist wrote:
>Why aren't we just using the perl5 memory manager?
Because it's not what I ultimately want, or what Parrot ultimately needs.
That and it would've been more work than it was worth when Parrot was first
set up. (We don't *do* much, so I didn't
At 09:56 AM 9/24/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> >> do we always emit one in
> >> loops?
>
> DS> At least one per statement, probably more for things like regexes.
>
> >> what about complex conditional code? i don't think there is
At 12:36 AM 9/25/2001 +1000, Andrew J Bromage wrote:
>G'day all.
>
>On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote:
>
> > Does it have to be in the instruction stream to be useful?
>
>No, of course not. I said "instruction" because that's how I saw it
>implemented last, but that
At 09:02 AM 9/24/2001 -0500, David M. Lloyd wrote:
>I'm just curious, is there a plan for how closures will work in Parrot?
When we create a PMC for a subroutine, it'll grab onto the scratchpad
that's in effect, and that scratchpad has a link to its parent, and so on.
When the last pointer to a
Dan Sugalski writes:
> Speaking from on high here, bytecode is strictly identifiable as to its
> characteristics. It will be as portable as a platform implementer wants it
> to be. The only 'required' types of bytecode that need to be read are
> 32-bit integer (both big and little endian) with
At 09:42 AM 9/24/2001 -0700, Wizard wrote:
>Some questions about implementation:
>which scenarios?:
>1.> external text-file strings (name=value?) chosen at run-time
>2.> Parrot build-time embedded strings (language chosen at configure)
>
>Do we want to break the messages into sets, such that <256
At 01:16 PM 9/24/2001 +0100, Dave Mitchell wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > Subject: What should and shouldn't get documented?
> >
> > I see there's a lot of embedded documentation going into the core, and
> > that's a good thing. That brings up a question, though--what exactly
At 12:24 PM 9/24/2001 +0200, Bart Lateur wrote:
>On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
>
> >Nope. At the very least, a bytecode file needs to start with:
> >
> >8-byte word:endianness (magic value 0x123456789abcdef0)
> >byte: word size
> >byte[7]:empty
> >wo
At 12:17 AM 9/24/2001 -0400, Michael Maraist wrote:
>Dan wrote:
> > For bytecode, it's not a big problem, certainly not one I'm worried about.
> > Machines that want 64-bit ints have, likely speaking, more than enough
> > memory to handle the larger bytecode.
> >
>That's not the problem. The pro
Leon --
> Can someone apply this please?
I just applied this patch a few minutes ago...
Regards,
-- Gregor
_
/ perl -e 'srand(-2091643526); print chr rand 90 for (0..4)' \
Gregor N. Purdy
At 10:36 AM 9/24/2001 -0400, Michael Maraist wrote:
>On Mon, 24 Sep 2001, Buggs wrote:
>
> > On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> > > At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> > > >http://astray.com/mandlebrot.pasm
> > > >
> > > >Leon, you're a sick, sick man.
> > >
>
All --
> > Also looks like there are some bugs in the num register handling that need
> > fixing. :(
>
>
> Just forgotten or is there more to it?
I just fixed the dec_n_n opcode, and fixed the assembler's handling of
constants like '0.1', which were being routed through oct().
Regards,
-- G
On Mon, 24 Sep 2001, Simon Cozens wrote:
> On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote:
> > I'm afraid I'll have very little time this week to track this down myself.
>
> It's OK; I've found myself a SPARC machine and I'm looking into it.
Thank you.
Some perspective for othe
> I'm just curious, is there a plan for how closures will work in Parrot? I
> think that closures are one of the coolest Perl 5 features around (despite
> their memory leak issues :-), and I'd hate to see them go away.
I doubt that there's any limitation. In Java, all they had to do was
supply
> DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>
> >> >Horribly wasteful of memory, definitely, and the final allocation system
> >> >will do things better, but this is OK to start.
> >>
> >> So to stop it waste memory, subtract 1 first and add it again later.
>
> DS> Nah, it'll
G'day all.
On Mon, Sep 24, 2001 at 10:27:24AM -0400, Michael Maraist wrote:
> Does it have to be in the instruction stream to be useful?
No, of course not. I said "instruction" because that's how I saw it
implemented last, but that was in a compiler backend, not in a virtual
machine specificat
On Mon, 24 Sep 2001, Buggs wrote:
> On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> > At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> > >http://astray.com/mandlebrot.pasm
> > >
> > >Leon, you're a sick, sick man.
> >
> > Okay, I think that means we need to weld in bitmap handling opco
> I have a suggestion for allowing parrot implementations to execute
> code more efficiently. Add an "instruction" or other annotation which
> denotes what registers are "live" at some point in the code. The
Does it have to be in the instruction stream to be useful? Why not just
be part of the
Leon Brocard sent the following bits through the ether:
> Attached is a patch to actually make dec_n_nc do what it should.
> (Also included is a minor doc patch which I've previously sent but
> which hasn't yet been applied ;-)
Can someone apply this please?
Leon
--
Leon Brocard...
On Mon, Sep 24, 2001 at 09:16:34AM -0500, Gibbs Tanton - tgibbs wrote:
> assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've
> done a cvs update -dP and it doesn't get added...what happend to this file?
You need to rerun Configure.
--
[Bastille Linux] Of course, if we cons
On Mon, Sep 24, 2001 at 03:14:19PM +0100, Leon Brocard wrote:
> While we're at it: Simon, what do we need to have ready before
> we release the next version?
OK, here's the release roadmap for the near future:
0.0.2 will be released when all tests pass on the core platforms.
0.0.3 will be releas
assemble.pl dies saying that it can't find Parrot/Types.pm in @INC. I've
done a cvs update -dP and it doesn't get added...what happend to this file?
Tanton
Gibbs Tanton - tgibbs sent the following bits through the ether:
> For the 0.0.2 release
While we're at it: Simon, what do we need to have ready before
we release the next version?
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...h
On Mon, Sep 24, 2001 at 09:03:39AM -0500, Gibbs Tanton - tgibbs wrote:
> For the 0.0.2 release, do we want floating point constants in the constant
> table, or do we want to change the code to work with inline constants...I
> think we can do a simple memcpy to make the inline constants work (inste
For the 0.0.2 release, do we want floating point constants in the constant
table, or do we want to change the code to work with inline constants...I
think we can do a simple memcpy to make the inline constants work (instead
of casting and assigning.)
Tanton
I'm just curious, is there a plan for how closures will work in Parrot? I
think that closures are one of the coolest Perl 5 features around (despite
their memory leak issues :-), and I'd hate to see them go away.
- D
<[EMAIL PROTECTED]>
> >>We're talking bytecode. That will indeed be a case of "huge arrays of
> >>tightly packed integers".
> >
> >For bytecode, it's not a big problem, certainly not one I'm worried about.
> >Machines that want 64-bit ints have, likely speaking, more than enough
> >memory to handle the larger byteco
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>> do we always emit one in
>> loops?
DS> At least one per statement, probably more for things like regexes.
>> what about complex conditional code? i don't think there is an
>> easy way to guarantee events are checked with insert
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>> >Horribly wasteful of memory, definitely, and the final allocation system
>> >will do things better, but this is OK to start.
>>
>> So to stop it waste memory, subtract 1 firs
Some questions about implementation:
which scenarios?:
1.> external text-file strings (name=value?) chosen at run-time
2.> Parrot build-time embedded strings (language chosen at configure)
Do we want to break the messages into sets, such that <256 is 'fatal', 256
to 511 is 'warning', 512 to 767 i
On Mon, Sep 24, 2001 at 09:16:10AM -0400, Andy Dougherty wrote:
> I'm afraid I'll have very little time this week to track this down myself.
It's OK; I've found myself a SPARC machine and I'm looking into it.
--
Calm down, it's *only* ones and zeroes.
On Fri, 21 Sep 2001, Andy Dougherty wrote:
> Apropos, here's what I get on Debian Sparc/Linux (my default perl there
> has iv='long long', so that's what we get here too). Note that nearly
> everything fails.
Ok, I've done cvs update and things are ever so slightly better. On
Friday, I got
>
I wrote:
> Should we go the full hog and make the /*=for api ... */ bit in the
> src field subsume any info we currently append to embed.pl etc in Perl 5?
s/field/file/
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Subject: What should and shouldn't get documented?
>
> I see there's a lot of embedded documentation going into the core, and
> that's a good thing. That brings up a question, though--what exactly should
> we document, and where should it be seen?
>
>
On Monday 24 September 2001 03:27, Dan Sugalski wrote:
> At 01:47 AM 9/24/2001 +0100, Simon Cozens wrote:
> >http://astray.com/mandlebrot.pasm
> >
> >Leon, you're a sick, sick man.
>
> Okay, I think that means we need to weld in bitmap handling opcodes into
> the interpreter. :)
>
> Also looks lik
On Fri, 14 Sep 2001 16:42:21 -0400, Dan Sugalski wrote:
>Nope. At the very least, a bytecode file needs to start with:
>
>8-byte word:endianness (magic value 0x123456789abcdef0)
>byte: word size
>byte[7]:empty
>word: major version
>word: minor version
>
>
On Sun, Sep 23, 2001 at 10:05:20PM -0400, Steven W McDougall wrote:
> This patch makes them go away.
And it doesn't appear to break anything else in the process. Thanks,
applied!
Just out of interest, what are the tests looking like on IRIX?
> -opcode_t *(*(*opcode_funcs)[2048])(); /* Opcod
On Sun, Sep 23, 2001 at 06:59:48PM -0700, Dave Storrs wrote:
> I.e., what is fair game to be worked on
* Documentation
* Tests
* Portability fixes
> and what is a "hold off for now?"
* Everything else
--
I see ADA as a larger threat than communism at this point in time -- Ted Holden
Andrew J Bromage sent the following bits through the ether:
> What do you all think? Leon mentioned control flow graphs a few days
> ago, but I think that live value information is more generally useful
> to optimising interpreters and JIT compilers.
I guess it depends what level you want to b
G'day all.
I have a suggestion for allowing parrot implementations to execute
code more efficiently. Add an "instruction" or other annotation which
denotes what registers are "live" at some point in the code. The
intended usage is that compilers which wish to generate this
information generate
83 matches
Mail list logo
