I get a warning during the Configure process:
...
Alright, now I'm gonna check some stuff by compiling and running
a small C program. This could take a bit...
test.c:13:1: warning: no newline at end of file
...
Attached is a trivial patch which adds a newline.
Leon
--
Leon
This looks really nice...
Regards
Mattia
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 07:00:00 2001 UTC
v0.01 on linux using cc version 2.95.2 2313 (Debian GNU/Linux)
O = OK
F = Failure(s), extended report at the bottom
? = still running
t/op/number.t is basically testing that
the rounding behaviour is the same across all
platforms. This is ***wrong***.
Regards
Mattia
--- Forwarded message follows ---
To: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
Subject:Parrot Smoke
I'd be sending 3 smoke reports ( Win2k/MSVC, x86/Linux,
Alphs/Tru64/GCC ) per snapshot, and maybe I will
start on cygwin and Win2k/MinGW, too.
Before I spam everyone with this,
is someone interested in it, and if so,
should I continue sending it to perl6-internals,
or is is preferable a different
I've just been fiddling around with the assembler and disassembler,
so that they use Gregor's PackFile modules. While this now means
that assembly and disassembly will Just Work seamlessly when we
change types and pack formats, it does look like I've broken something
on Tru64, or at least,
--- Forwarded message follows ---
Automated smoke report for patch Sep 22 13:00:00 2001 UTC
v0.01 on dec_osf using gcc version 2.95.2
O = OK
F = Failure(s), extended report at the bottom
? = still running or test results not (yet) available
Build failures during:
On Sat, Sep 22, 2001 at 03:56:09PM +0100, Simon Cozens wrote:
I'm looking into it now.
Fixed. Parrot is now as broken as it was on Tru64 before I
started messing with it, but now it will also Do The Right
Thing when you change the internal types.
--
Asynchronous inputs are at the root of our
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parrot_Interp *interpreter) {
IV return_offset = 5;
if
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
or is there a saner way to do it?
There is, and I've done it. (removed an assumption in process_opfunc.pl)
Jarkko, please resync; I think you'll find only one test now fails.
Unfortunately, I do not have the slightest idea why that
On Sat, Sep 22, 2001 at 04:33:31PM +0200, Mattia Barbon wrote:
Before I spam everyone with this,
is someone interested in it
I'm *very* interested in it.
and if so,
should I continue sending it to perl6-internals,
or is is preferable a different ML?
For now, let's have them here. We can
On Fri, Sep 21, 2001 at 02:51:02PM -0400, Andy Dougherty wrote:
I fear some sort of alignment or sizeof() issue is at work, and I'd hate
to see whatever problems exist so far get widely propagated into other
pieces of the source.
I've just cleaned up all the alignment and sizeof() issues from
On Sat, Sep 22, 2001 at 05:45:12PM +0100, Simon Cozens wrote:
Parrot's tests now run successfully on Tru64 and Linux.
That is, Linux x86. Linux Alpha just compiled successfully too.
--
sub UNIVERSAL::AUTOLOAD{ $UNIVERSAL::AUTOLOAD =~ s/::/ /; print
$UNIVERSAL::AUTOLOAD }; hacker perl another
I've got a mac suitable for setting up as a test platform for parrot now,
courtesy of Grant. Does anyone have any connections with Apple? I'd like to
see about getting an OS X server license for it so we can do automated
smoke testing and suchlike things, but my budget, alas, doesn't have the
At 07:40 PM 9/22/2001 +0300, Jarkko Hietaniemi wrote:
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
All --
The missing code is going to look something like this:
Next time I'm in front of my development machine, I'll give this a try.
If this approach works, I'll work harder to produce a version of the
solution that we can be proud of.
OK. I got it working. I'm attaching the compile.pl and
what about adding run !
#!/usr/bin/perl -w
my ($pasm) = $ARGV[0] =~ /(.*?)\./;
system(./assemble.pl $ARGV[0] $pasm.pbc ; ./test_prog $pasm.pbc);
cheers
=
iVAN
[EMAIL PROTECTED]
=
hi,
is it possible the ops to handle variable number of arguments, what I have
in mind :
print I1,,,N2,\n
cheers
=
iVAN
[EMAIL PROTECTED]
=
At 07:09 PM 9/22/2001 +0300, raptor wrote:
hi,
is it possible the ops to handle variable number of arguments
No.
Which isn't to say that if you do:
new P0, list
push P0, A
push P0, multipart
push P0, string
push P0, \n
print P0
you won't get A multipart string out,
On Sat, 22 Sep 2001, raptor wrote:
hi,
is it possible the ops to handle variable number of arguments, what I have
in mind :
print I1,,,N2,\n
This could probably be done as a macro when the assembler has macro
support in the future.
For now, the Jako Compiler converts:
var int i;
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 in 'cos
it's
On Sat, Sep 22, 2001 at 09:05:53PM +0100, Leon Brocard 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'
Applied,
On Saturday 22 September 2001 04:05 pm, Leon Brocard 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'
Except it
GRRR... always use reply yo all...
--- Forwarded message follows ---
From: Mattia Barbon [EMAIL PROTECTED]
To: Simon Cozens [EMAIL PROTECTED]
Subject:Re: Tru64 Numeric bug exposed!
Copies to: [EMAIL PROTECTED], [EMAIL
On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
[parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
ccflags=-O3 -Iinclude --define iv=long --define nv=double
[parrot]$ make
[parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Whoa - did you re-assemble
I've found the bug on Linux Sparc; This is either a bug in Parrot, or a bug in
Perl, and I can't tell which.
On this machine, NVs are doubles; their pack_type is 'd', which is as it should
be. So, a number (2.0) is inserted into the bytecode stream with pack('d', 2.0)
However, when I try
cvsuser 01/09/22 10:20:59
Modified:.Makefile.in
Added: Test More.pm Simple.pm Utils.pm
Log:
I'm sick of having to install Test::More everywhere. Temporary measure
until we remove this silly dependency.
I promise I'll do it after 0.02 is out.
Mattia
On Sun, Sep 23, 2001 at 12:27:53AM +0200, Mattia Barbon wrote:
[parrpt]$ perl Configure.pl --defaults --define cc=gcc --define
ccflags=-O3 -Iinclude --define iv=long --define nv=double
[parrot]$ make
[parrot]$ for i in t/op/number*.pbc ; do ./test_prog $i; done
Whoa - did you
On this machine, NVs are doubles; their pack_type is 'd', which is
as it should be. So, a number (2.0) is inserted into the bytecode
stream with pack('d', 2.0)
./perl -Ilib -MDevel::Peek -le 'Dump(pack(d,2))'
SV = PV(0x1d9ed4) at 0x1e4568
REFCNT = 1
FLAGS = (PADTMP,POK,pPOK)
PV =
[Sorry if this is a duplicate. I sent the original from work.
Is there a spam filter removing messages from non-subscribers?]
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we
did something non-traditional that
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are: put floats into the
constant section, or ensure instructions are assigned on an appropriate
boundary. I can see pros and
On Saturday 22 September 2001 07:21 pm, Simon Cozens wrote:
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are: put floats into
the constant section, or ensure instructions
On Sun, 23 Sep 2001, Simon Cozens wrote:
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko Hietaniemi wrote:
unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are: put floats into the
constant section, or ensure instructions are assigned
--- Simon Cozens [EMAIL PROTECTED] wrote:
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
Hietaniemi wrote:
unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are:
put floats into the
constant section, or ensure instructions are assigned
On Sat, Sep 22, 2001 at 04:41:28PM -0700, Benjamin Stuhl wrote:
at load time. Yes, it's slow and hackish, but strings are
the only *portable* format for floating-point numbers
I thought (although I might have conveniently forgotten the other
side of the argument:) that we weren't that
On Sat, 22 Sep 2001, Benjamin Stuhl wrote:
--- Simon Cozens [EMAIL PROTECTED] wrote:
On Sun, Sep 23, 2001 at 02:17:40AM +0300, Jarkko
Hietaniemi wrote:
unaligned access
Bother. It is as I feared.
Dan, we need to do something about this. The choices are:
put floats into the
On Saturday 22 September 2001 07:33 pm, Simon Cozens wrote:
On Sat, Sep 22, 2001 at 04:41:28PM -0700, Benjamin Stuhl wrote:
at load time. Yes, it's slow and hackish, but strings are
the only *portable* format for floating-point numbers
I thought (although I might have conveniently
On Sat, Sep 22, 2001 at 07:12:05PM -0400, Michael G Schwern wrote:
Compaq has a program called Testdrive where they offer free accounts
on a VERY wide range of machines OS's. Tru64, Caldera, Debian,
Redhat, Kondara, OpenVMS, Mandrake, SuSE, Turbo, NetBSD, FreeBSD,
Beowulf, iPAQ on Alpha,
[EMAIL PROTECTED] (Leon Brocard) writes:
[...]
Attached is a trivial patch which adds a newline.
I've put that in CVS. I also renamed the 'test' executable we make to
test_siz (just because using test on a unix system is bad karma).
- ask
--
ask bjoern hansen, http://ask.netcetera.dk/
[EMAIL PROTECTED] (Dan Sugalski) writes:
I've got a mac suitable for setting up as a test platform for parrot
now, courtesy of Grant. Does anyone have any connections with Apple?
I'd like to see about getting an OS X server license for it so we
can do automated smoke testing and suchlike
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're
Some tests for stack operations, pushing and popping, except
for pmcs. Suggest: t/op/stacks.t
Alex Gough
--
Hatred is the coward's revenge for being intimidated.
#
#! perl -w
# Tests for stack operations, currently push_*, push_*_c and pop_*
# where * != p.
# Assembler code is
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we
did something non-traditional that made implementing higher-level
lexically scoped languages easier?
What if the VM (and assembler) had lexical scoping built-in
Here's what I use ...
#!/usr/bin/perl -w
# parrot - compile and run parrot assembly language
$srcfile = shift or die usage: $0 PASMFILE\n;
($pbcfile = $srcfile) =~ s{\.pasm$}{.pbc}i;
system(perl assemble.pl $srcfile $pbcfile ./test_prog $pbcfile);
--
On 22 Sep 2001, Ask Bjoern Hansen wrote:
[EMAIL PROTECTED] (Dan Sugalski) writes:
I've got a mac suitable for setting up as a test platform for parrot
now, courtesy of Grant. Does anyone have any connections with Apple?
I'd like to see about getting an OS X server license for it so we
On Sat, 22 Sep 2001, Ken Fox wrote:
I've been thinking about the possibility of building a higher-level
VM. The current VM is very close to a traditional CPU. What if we did
something non-traditional that made implementing higher-level
lexically scoped languages easier?
snip
I'm proposing:
On Thu, Sep 20, 2001 at 11:11:42AM -0400, Dan Sugalski wrote:
Actually the ops=C conversion was conceived to do exactly what's being
done now--to abstract out the body of the opcodes so that they could be
turned into a switch, or turned into generated machine code, or TIL'd. If
you're
David M. Lloyd wrote:
Take it from me (the one with several abortive attempts at getting an
extra compare stuck in Perl 5's dispatch loop): You don't want to stick
another compare in there. It *kills* performance.
Kills? I thought the event flag test dropped performance by a few
percent. We
48 matches
Mail list logo
