All --
> Chances are good that you were at least having trouble do to the string
> constants not being loaded into the interpreter (I pointed this problem
> out a few minutes ago in a related message). Perhaps getting those
> string-constant-loading statements in there as directed earlier would
Brent --
> # My first cut is pretty sloppy, but it does generate this C file, which
> # compiles, but I don't have the time to figure out how to get
> # it all the
> # stuff it needs to link to. If someones gets it running, I'd
>
> Parrot::Config may come in handy, especially @PConfig{qw(cc ccf
All --
> My first cut is pretty sloppy, but it does generate this C file, which
> compiles, but I don't have the time to figure out how to get it all the
> stuff it needs to link to. If someones gets it running, I'd like to see
> how many Mops they get vs. regular.
BTW, I realized as I left the
Gregor N. Purdy:
# Dan --
#
# > Here's something for someone looking to do something
# interesting while the
# > code freeze is on.
# >
# > Write yourself a program that takes a .pasm file and,
# rather than spitting
# > out bytecode, spits out the bodies of the opcode functions with the
# > appro
Dan --
> Here's something for someone looking to do something interesting while the
> code freeze is on.
>
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the
At 04:32 PM 9/21/2001 -0400, Michael Maraist wrote:
>Either way, branching can be reduced by a clustering a sequence of
>regularly used-ops together into macro-ops.
Congrats, you've uncovered another hidden reason for the preprocessed
opcode functions. :)
The intention is that we'll be able to
> On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
> Cool! Parrot JIT!
>
> But that tells us *just* how time-cons
Mattia Barbon:
# > 'C:Perinperl.exe' is not recognized as an internal or
# external command,
# > operable program or batch file.
# Apply this for the C:Perinperl.exe problem
#
# - system "$^X -e \"$redir_string;system qq{$command};\"";
# + system "$^X -e \"$redir_string;system q{$command};\
Simon Cozens:
# +if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
The version check is no longer necessary, since Configure.pl now detects
longsize itself.
--Brent Dax
[EMAIL PROTECTED]
They *will* pay for what they've done.
On Fri, Sep 21, 2001 at 03:52:52PM -0400, Gregor N. Purdy wrote:
> OK. I'm tinkering with this a bit, but I've tripped over what appears to
> be a bug somewhere in the PackFile::* classes.
You too, eh? I think it would be a VERY good idea to have the configure
process spit out a module containin
Dan --
> Write yourself a program that takes a .pasm file and, rather than spitting
> out bytecode, spits out the bodies of the opcode functions with the
> appropriate replacements done on the parameters. The output should be
> suitable for stuffing into the guts of test_main.c in the place of
Brad Hughes:
# Brent Dax wrote:
# >
# > Dan Sugalski:
# > # At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# > # >Stefan Dragnev:
# > # ># - $c{cc_denug} = ' ';
# > # ># + $c{cc_debug} = ' ';
# > # >
# > # >So *that*'s why -g kept appearing...thanks, applied.
# > #
# > # Don't forget t
Brent Dax wrote:
>
> Dan Sugalski:
> # At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
> # >Stefan Dragnev:
> # ># - $c{cc_denug} = ' ';
> # ># + $c{cc_debug} = ' ';
> # >
> # >So *that*'s why -g kept appearing...thanks, applied.
> #
> # Don't forget that debugging isn't always -g. (It'
At 12:45 PM 9/21/2001 -0700, Brent Dax wrote:
>Dan Sugalski:
># At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
># >Stefan Dragnev:
># ># - $c{cc_denug} = ' ';
># ># + $c{cc_debug} = ' ';
># >
># >So *that*'s why -g kept appearing...thanks, applied.
>#
># Don't forget that debugging isn'
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Could you have another go with the configure patch I just sent?
> *Might* help, and even if it doesn't, it puts us on a level
> playing-field.
Sorry, no, difference.
--
Andy Dougherty [EMAIL PROTECTED]
Dept. of Physics
Lafayet
Dan Sugalski:
# At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
# >Stefan Dragnev:
# ># - $c{cc_denug} = ' ';
# ># + $c{cc_debug} = ' ';
# >
# >So *that*'s why -g kept appearing...thanks, applied.
#
# Don't forget that debugging isn't always -g. (It's /DEBUG for
# me on VMS)
That sort o
Simon Cozens writes:
> I've just checked this in because the disassembler has come adrift
> from the assembler. I don't know if this is the right fix, because
> it feels like a hack, but it seems to work well enough for me to
> debug some failing tests.
Maybe one of the tests should be to disasse
I've just checked this in because the disassembler has come adrift
from the assembler. I don't know if this is the right fix, because
it feels like a hack, but it seems to work well enough for me to
debug some failing tests.
Index: disassemble.pl
==
Simon Cozens:
# This is never set, although it is (indirectly) tested for. Here's
# a patch.
#
# (@c{qw(ivsize opsize nvsize)})=split('/', `./test$c{exe}`);
# +$c{longsize} = $c{opsize};
Actually, that middle one *should* be longsize, not opsize. That was
from before I realized what longsize wa
Could you have another go with the configure patch I just sent?
*Might* help, and even if it doesn't, it puts us on a level
playing-field.
Tru64's fine, apart from this crap:
t/op/number.dubious
Test returned status 7 (wstat 1792, 0x700)
DIED. FAILED tests 1, 7, 9, 11, 13, 15, 17
This is never set, although it is (indirectly) tested for. Here's
a patch.
Index: Configure.pl
===
RCS file: /home/perlcvs/parrot/Configure.pl,v
retrieving revision 1.14
diff -u -r1.14 Configure.pl
--- Configure.pl2001/09/21
At 07:41 PM 9/21/2001 +0100, Simon Cozens wrote:
>On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> > Doing this by hand with -O3, you can see a speedup of around a factor
> of 45
> > over an unoptimised runops loop, so it's definitely worth doing in some
> > cases...
>
>Cool! Parro
At 02:43 PM 9/21/2001 -0400, Gregor N. Purdy wrote:
>Dan --
>
> > Go ahead and apply it, and I'll probably tweak from there.
>
>I'd love to do that, but Simon is (understandably) hesitant to
>have non-bugfix commits right now.
I saw that. Simon's the Code Guy, so what he says goes here. It can wa
At 02:48 PM 9/21/2001 -0400, Michael Maraist wrote:
>Question. It seems to me that the current do-loop:
> while(code > x && code < y && *code) { DO_OP }
>
>Is fail-fast and succeed-slow. I know it has a brother:
> "while(*code)", but this could lead to seg-faults, especially if we allow
>dynami
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Very nice, but can I remind you and everyone else that we're trying
> to get it working before we get it pretty?
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 near
On Fri, Sep 21, 2001 at 02:24:43PM -0400, Dan Sugalski wrote:
> Doing this by hand with -O3, you can see a speedup of around a factor of 45
> over an unoptimised runops loop, so it's definitely worth doing in some
> cases...
Cool! Parrot JIT!
But that tells us *just* how time-consuming our ru
Question. It seems to me that the current do-loop:
while(code > x && code < y && *code) { DO_OP }
Is fail-fast and succeed-slow. I know it has a brother:
"while(*code)", but this could lead to seg-faults, especially if we allow
dynamically modified parsers / compilers.
The first method has an
On Fri, 21 Sep 2001, Simon Cozens wrote:
> Very nice, but can I remind you and everyone else that we're trying
> to get it working before we get it pretty?
Apropos, here's what I get on Solaris 8 (my default perl there has
iv='long long', so that's what we get here too):
/opt/perl-trial/bin/per
At 09:07 PM 9/20/2001 -0400, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> DS> There probably won't be any. The current thinking is that since
> DS> the ops themselves will be a lot smaller, we'll have an explicit
> DS> event checking op that the compiler
Dan --
> >I've continued to play with the DO_OP simplification patch I posted
> >before.
>
> Looks good, at least as far as I can tell from the diff.
Thanks!
> Go ahead and apply it, and I'll probably tweak from there.
I'd love to do that, but Simon is (understandably) hesitant to
have non-bu
Simon --
> > I've continued to play with the DO_OP simplification patch I posted
> > before. I've removed the op info stuff from the op func struct per
> > suggestions from Dan.
>
> Very nice,
Thanks!
> but can I remind you and everyone else that we're trying
> to get it working before we get
On Fri, Sep 21, 2001 at 11:05:29AM +0200, Mattia Barbon wrote:
> not ok 15 - gt_nc_ic
> # Failed test (Parrot/Test.pm at line 74)
> # got: undef
> # expected: 'ok 1
> ok 2
> ok 3
> '
>
> So Test::Harenss keeps whining about test 2 answrd ( yes, the PC
> with the brokn keyboard ag
At 12:29 AM 9/21/2001 +0200, Bart Lateur wrote:
>[I'm behind on my mail :-)]
>
>On Wed, 12 Sep 2001 13:19:40 -0400, Dan Sugalski wrote:
>
> >We're trying to align to a power-of-two boundary, and mask is set to
> >chop off the low bits, not the high ones. It should be something like:
> >
> >11
Here's something for someone looking to do something interesting while the
code freeze is on.
Write yourself a program that takes a .pasm file and, rather than spitting
out bytecode, spits out the bodies of the opcode functions with the
appropriate replacements done on the parameters. The outp
On Fri, Sep 21, 2001 at 01:21:28PM -0400, Gregor N. Purdy wrote:
> I've continued to play with the DO_OP simplification patch I posted
> before. I've removed the op info stuff from the op func struct per
> suggestions from Dan.
Very nice, but can I remind you and everyone else that we're trying
t
At 01:21 PM 9/21/2001 -0400, Gregor N. Purdy wrote:
>I've continued to play with the DO_OP simplification patch I posted
>before.
Looks good, at least as far as I can tell from the diff. Go ahead and apply
it, and I'll probably tweak from there.
Dan
At 13:16 on 09/21/2001 EDT, Uri Guttman <[EMAIL PROTECTED]> wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
> >> The names are unique in the first 31 chars. Are we OK, or do I need
> >> to mangle the names? I could
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
>> The names are unique in the first 31 chars. Are we OK, or do I need
>> to mangle the names? I could mangle them by doing one of the following:
DS> Try choosing something smal
At 09:37 AM 9/21/2001 -0400, Gregor N. Purdy wrote:
>The names are unique in the first 31 chars. Are we OK, or do I need
>to mangle the names? I could mangle them by doing one of the following:
Try choosing something smaller. (If for no other reason than I don't want
to have to type that long a
At 06:43 PM 9/20/2001 -0700, Brent Dax wrote:
>Stefan Dragnev:
># - $c{cc_denug} = ' ';
># + $c{cc_debug} = ' ';
>
>So *that*'s why -g kept appearing...thanks, applied.
Don't forget that debugging isn't always -g. (It's /DEBUG for me on VMS)
Da
On Fri 21 Sep 2001 12:04, "H.Merijn Brand" <[EMAIL PROTECTED]> wrote:
> On Fri 21 Sep 2001 11:45, Mattia Barbon <[EMAIL PROTECTED]> wrote:
> > It is gcc 2.95.2, not 2.8.1
> > *SMACK* to anyone kept the perl scripts
> > compatible with perl 5.004_04
> >
> > Regards
> > Mattia
> >
> > P.S.: Suggst
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 ;-)
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware...http://www.nanoware
On Fri, 21 Sep 2001, Jason Gloudon wrote:
>
> Using the current CVS source with perl5.6.1, the assembler runs with the
> following warning:
>
> Use of uninitialized value in numeric eq (==) at assemble.pl line 53.
>
> 53 if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
>
I've been following the stack vs register machine thread. If you haven't
seen this:
http://www-2.cs.cmu.edu/~koopman/stack_computers/
it does a reasonable job at presenting the pros/cons of many stack-based
architectures.
Anyway, thought it might be useful.
-dave
Leon Brocard added the first examples to the brand new Parrot
site. :-) (the first page is just http://dev.perl.org/perl6/code -
sometime in this weekend I'll probably get it moved around so
dev.perl.org just references parrotcode for Parrot information).
http://www.parrotcode.org/examples/
-
Using the current CVS source with perl5.6.1, the assembler runs with the
following warning:
Use of uninitialized value in numeric eq (==) at assemble.pl line 53.
53 if (($] >= 5.006) && ($PConfig{ivsize} == $PConfig{longsize}) ) {
54 %pack_type = ('i'=>'l!','n'=>'d');
55 }
I
All --
Has anyone else out there tinkered with Jako examples? I'd like to
see examples or example ideas/sketches. I'd especially like to see
examples showing something you think jakoc should understand, but
doesn't.
Things I know I need to work on:
* Get the math ops, etc. working as built-in
All --
I want to commit some bug fixes and new features for Jako. Given the
freeze, though, I want to make sure that if I do it, nobody is
depending upon jakoc as anything other than an illustration for now.
It works great here (much better than the current CVS version), and
will probably work gr
Dan --
> Just a reminder--function names shouldn't exceed 31 characters. The C
> standard doesn't guarantee anything past that...
Using this simplistic program I found two names greater than 31 chars.
I don't know if there are names not fitting the little regexp used here,
but of those that do,
> 'C:Perinperl.exe' is not recognized as an internal or external command,
> operable program or batch file.
Apply this for the C:Perinperl.exe problem
Sorry for the inconvenience.
Mattia
Index: Parrot/Test.pm
===
RCS file: /ho
On Fri 21 Sep 2001 11:45, Mattia Barbon <[EMAIL PROTECTED]> wrote:
> It is gcc 2.95.2, not 2.8.1
> *SMACK* to anyone kept the perl scripts
> compatible with perl 5.004_04
>
> Regards
> Mattia
>
> P.S.: Suggstions about how to make report lins shorter
> *VERY* welcome
Start with stripping
It is gcc 2.95.2, not 2.8.1
*SMACK* to anyone kept the perl scripts
compatible with perl 5.004_04
Regards
Mattia
P.S.: Suggstions about how to make report lins shorter
*VERY* welcome
-- Forwarded message --
Automated smoke report for patch Sep 21 07:00:01 2001 UTC
why is :
make test_prog
instead of just
make
=
iVAN
[EMAIL PROTECTED]
=
Simon Cozens:
# On Thu, Sep 20, 2001 at 09:44:41PM -0700, Brent Dax wrote:
# > Okay, this fixes the issues with changing your IV or NV
# size. It also
# > provides an early warning if your C compiler settings
# aren't okay. I've
# > also made the style of the code a little more consistent.
# I'm
On Fri, Sep 21, 2001 at 10:18:31AM +0100, Leon Brocard wrote:
> Leon Brocard sent the following bits through the ether:
>
> > Attached are trivial comment fixes for two files.
>
> Oh go on, I know we're in a feature freeze but this is a doc
> patch. Can someone apply these please?
Doc patches a
Leon Brocard sent the following bits through the ether:
> Attached are trivial comment fixes for two files.
Oh go on, I know we're in a feature freeze but this is a doc
patch. Can someone apply these please?
Leon
--
Leon Brocard.http://www.astray.com/
Nanoware..
On Thu, Sep 20, 2001 at 09:44:41PM -0700, Brent Dax wrote:
> Okay, this fixes the issues with changing your IV or NV size. It also
> provides an early warning if your C compiler settings aren't okay. I've
> also made the style of the code a little more consistent. I'm applying
> this, but I fig
On Fri, Sep 21, 2001 at 02:50:45AM +0200, Mattia Barbon wrote:
> Parrot::Smoke 0.01 has just been released.
> It works on Win2k and Linux, but it should work
> in most Unices.
This is very cool! Thank you very much.
--
Putting heated bricks close to the news.admin.net-abuse.* groups.
--
not ok 15 - gt_nc_ic
# Failed test (Parrot/Test.pm at line 74)
# got: undef
# expected: 'ok 1
ok 2
ok 3
'
So Test::Harenss keeps whining about test 2 answrd ( yes, the PC
with the brokn keyboard again ) after test 9, and such.
Could output be changed to anyting else?
Thanks
Mat
On Thu, 20 Sep 2001, Brent Dax wrote:
>Mattia Barbon:
># Automated smoke report for patch Sep 20 00:00:02 2001
># v0.01 on MSWin32 using cl version
>...
># MSWin32 --defaults --define iv=int --define nv=float
># MSWin32 --debugging --defaults --define iv=int --define n
In message <20010920190703.S28291@blackrider>
Michael G. Schwern <[EMAIL PROTECTED]> wrote:
> I'm getting 2.67 MIPS with -O3.
>
> Hmmm, why would a K6/200 come out so much faster than a G3/266? If
> anything it should be the other way around.
No idea I'm afraid. I've just clocked 42.86
61 matches
Mail list logo
