Automated smoke report for patch Nov 2 20:00:01 2001 UTC
v0.02 on hpux using cc version B.11.11.02
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t
Automated smoke report for patch Nov 2 20:00:01 2001 UTC
v0.02 on aix using xlc version 3.1.4.10
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during: - = unknown
c = Configure, m = make, t =
Firstly, 8am code this morning builds on Win32 without problem, other than
configure.pl not knowing that link is the linker (which appears to be down
to ActiveState not knowing).
Thanks to Hong Zhang ([EMAIL PROTECTED]) for pointing out the
GetSystemTimeAsFileTime API. Also adjusts zero time
Richard J Cox:
# Firstly, 8am code this morning builds on Win32 without
# problem, other than
# configure.pl not knowing that link is the linker (which
# appears to be down
# to ActiveState not knowing).
Does it have to know? If so, set it in the hints file
(hints/mswin32.pl).
--Brent Dax
On Sat, Nov 03, 2001 at 09:46:06AM -0800, Brent Dax wrote:
but how do I use an additional .ops file? I'd like to statically
link it in and use it alongside core.ops, but I can't figure it out.
To let the assembler know about it, add a line like
use Parrot::OpLib::foo;
to
Hey all. This is a (fairly stupid) pbc dumper, including a dissassembler.
I say fairly stupid because it creates code that won't assemble, because it
tries to do a very literal translation back to pasm.
Sample output (of the bytecode part; the rest is pretty non-contriversial):
set_i_ic
Hello everybody
I am interested in helping out with configure. I don't know too much about
parrot, but I have decent perl skills (I can do what I want to do when I
want to do it) and am interested in helping out. What can I do to help?
(time to spew the to-do list ;)
Zach
Hey all.
I'm having a parrot-project weekend, y'all might have noticed. Right now,
I'm thinking of multiple oplibs, specificly how to get the bytecode/packfile
to express it.
Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify
the oplib (as an index to the table of
On Thu, Nov 01, 2001 at 12:18:18PM -0300, Daniel Grunblatt wrote:
while (pc) { DO_OP(pc, interpreter); }
---
just_do_it(interpreter,pc);
This is quite boring, I know, but could we have a definition of
this function? :)
(Also, I much prefer to see diffs in unified format - use the
On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote:
Hey all.
I'm having a parrot-project weekend, y'all might have noticed.
Cool. Any chance you could write some of the functions in
classes/scalarclass.c? :)
More details coming soon, once Robert and I have finished playing with
On Sat, Nov 03, 2001 at 09:00:25PM +, Simon Cozens wrote:
Cool. Any chance you could write some of the functions in
classes/scalarclass.c? :)
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote:
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
nearly good enough to be writing code that I can't test.
Sombody care to clue me in?
On Sat, 3 Nov 2001, Simon Cozens wrote:
On Sat, Nov 03, 2001 at 04:11:23PM -0500, James Mastros wrote:
No. I say this because I have /no idea/ how they fit into the rest of
existance. To whit, I don't know how to access them from pasm. I'm not
nearly good enough to be writing code that
On Sat, Nov 03, 2001 at 09:49:02PM +, Simon Cozens wrote:
Look at vtable.ops. However, this probably doesn't help because we don't
currently have an op that creates PMCs.
Even worse, we never seem to do anything with vtable_opinfo (etc). That's
the big reason that I started my current
Zach Lipton:
# Hello everybody
#
# I am interested in helping out with configure. I don't know
# too much about
# parrot, but I have decent perl skills (I can do what I want
# to do when I
# want to do it) and am interested in helping out. What can I
# do to help?
# (time to spew the to-do list
On Sat, Nov 03, 2001 at 03:53:10PM -0500, James Mastros wrote:
Here's what I'm thinking: The high 16 bits (or so) of the opcode can identify
the oplib (as an index to the table of oplibs, see the next para), the rest
can identify the opcode. This shouldn't be too bad a limit: 64k opcodes
On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote:
Right now, I'm thinking that the opcodes are going to be assigned to oplibs
linearly (eg the last opcode in core.ops is 292, so the first opcode in the
next oplib loaded will be 293).
I thought that Dan's plan was that oplibs
On Sat, 3 Nov 2001, Brent Dax wrote:
Zach Lipton:
# Hello everybody
#
# I am interested in helping out with configure. I don't know
# too much about
# parrot, but I have decent perl skills (I can do what I want
# to do when I
# want to do it) and am interested in helping out. What can I
On Sat, 3 Nov 2001, Simon Cozens wrote:
On Sat, Nov 03, 2001 at 06:00:42PM -0500, James Mastros wrote:
Right now, I'm thinking that the opcodes are going to be assigned to oplibs
linearly (eg the last opcode in core.ops is 292, so the first opcode in the
next oplib loaded will be 293).
Brent --
but how do I use an additional .ops file? I'd like to statically
link it in and use it alongside core.ops, but I can't figure it out.
The assembler can't find the opcodes, even after I run ops2pm. Is there
some magical command-line switch I'm not activating or something?
This
Brent --
How about, instead of just saying 'oplib foo' in the bytecode header, we
say 'first N opcodes of oplib foo'? After all, you generally don't have
any use for opcodes added after you assembled. :^)
I agree, although I take it further by allowing you to cherry-pick the
ops you need
On Sat, Nov 03, 2001 at 07:17:49PM -0500, Gregor N. Purdy wrote:
I've been working on this. I've added an opcode_table section that
contains (oplib, opindex) pairs (they are constant table string indexes to
allow lookup by name). The custom opcode table for the bytecode in the
packfile is
Hey all.
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need to:
1) Define an ordering on things like open(i, s|sc, i|ic,
James --
We're going to have to think about assigning static opcode numbers,
instead of the current order-defined. For one thing, we're looking at
perpetual bytecode compatablity (no?). This isn't really a Big Deal, but we
need to:
1) Define an ordering on things like open(i, s|sc,
Brian --
None of these are issues with the approach I've been working on /
advocating. I'm hoping we can avoid these altogether.
I think this is a cool concept, but it seems like a lot of overhead with
the string lookups.
I'm hoping we can keep the string lookups in order to
The included patch modifies Parrot::Assembler to open the Parrot::OpLib
directory and collect operations from the files in that directory,
instead of being hardwired to use only Parrot::OpLib::core.
Unfortunately relative paths can't be used because the assembler script
runs from different
On Sat, Nov 03, 2001 at 09:40:14PM -0500, Gregor N. Purdy wrote:
Let me try to illustrate what I'm thinking a little more clearly. The
program:
.use core
set I0, 5
set I1, 37
add I2, I0, I1
print I2
print \n
end
would have an opcode_table in the packfile:
5
--- Gregor N. Purdy [EMAIL PROTECTED] wrote:
Brian --
None of these are issues with the approach I've been
working on /
advocating. I'm hoping we can avoid these altogether.
I think this is a cool concept, but it seems like a lot
of overhead with
the string lookups.
I'm
All:
Here's a list of the things I've been doing:
* Added ops2cgc.pl which generates core_cg_ops.c and core_cg_ops.h from
core.ops, and modified Makefile.in to use it. In core_cg_ops.c resides
cg_core which has an array with the addresses of the label of each opcode
and starts the
Zach Lipton:
# Ok, great. Thanks. I'll see what I can do.
#
# Random idea off the top of my head, note that this assumes
# that configure
# will use perl to work, if this is not going to be true, this
# probably won't
# work.
Well, for now we're using Perl for Configure, but that won't be
First of all you miss typed:
-if ($c{do_opt_t} eq 'goto' and $c{cc} !~ /gcc/i ) {
+if ($c{do_op_t} eq 'goto' and $c{cc} !~ /cc/i ) {
On Sat, 3 Nov 2001, Michael Fischer wrote:
Ok, attached dispatch.diff is the smallest changes
I could think of to get a Configure.pl time choice
for
31 matches
Mail list logo
