Re: [perl #60986] Win32 package refuses to install if not run by an administrator

James Keenan via RT wrote: > Okay to close the ticket? Yes. gw

Re: [perl #60986] Win32 package refuses to install if not run by an administrator

2009/2/1 James Keenan via RT : > My reading of the issues raised in this RT is that it's a > straightforward Win32 installation issue -- nothing specific to Parrot. > > Okay to close the ticket? +1 François > Thank you very much. > kid51 > ___ > http://l

Re: [perl #60986] Win32 package refuses to install if not run by an administrator

Andrew Whitworth via RT wrote: > On Tue Dec 02 05:50:02 2008, [EMAIL PROTECTED] wrote: >> Hi, >> >> I think it is wrong that the Win32 installation package for Parrot >> refuses to install if not run by an administrator. >> >> I simply do not want to pol

Re: [perl #61052] [BUG]: r33482 Can't run 'make realclean' in languages/perl6 directory

- Original Message > From: Moritz Lenz <[EMAIL PROTECTED]> > (Just out of curiosity, do you need 'make realclean' in > languages/perl6/? Most of the time a simple 'make' works for me, or a > 'make clean'. I never needed realclean in Rakudo, only in parrot so far). No, I don't need to do

Re: [perl #61052] [BUG]: r33482 Can't run 'make realclean' in languages/perl6 directory

ug has been around for a while, but I've been too lazy to report it :) Actually I call it a feature ;-) > My build tools automatically run a 'make realclean' if I type 'rebuild' in a > directory with a Makefile. > If you do that in languages/perl6, you can no longer

Re: [perl #61052] [BUG]: r33482 Can't run 'make realclean' in languages/perl6 directory

et/Display.html?id=61052 > > > > This bug has been around for a while, but I've been too lazy to report it :) > > My build tools automatically run a 'make realclean' if I type 'rebuild' in a > directory with a Makefile. If you do that in languages/per

[perl #61052] [BUG]: r33482 Can't run 'make realclean' in languages/perl6 directory

t :) My build tools automatically run a 'make realclean' if I type 'rebuild' in a directory with a Makefile. If you do that in languages/perl6, you can no longer run "make" in that directory. Doing an "svn up" doesn't help. Going back to the top leve

[perl #60986] Win32 package refuses to install if not run by an administrator

not run by an administrator. I simply do not want to pollute my system and am therefore using a non-administrator user for everything. I know that the installation will then not be able to install filetype bindings, system wide entries in the registry or install itself in Program Files and that I w

[perl #60676] Win32 parrot-0.8.1 installation won't run perl6

ade over an extracted parrot-0.8.1gz so that the entire build directory structure and content is present (but no build has been done.) Parrot.exe is run from ...runtime\parrot\library to avoid another bug: that P6object.pbc can't be found. The error lo

[perl #57538] [BUG] MMX check in config/auto/cpu/i386 segfaults when run as a 64-bit binary on OS X 10.5

he command line by building config/auto/cpu/i386/memcpy_mmx.c with the flags "-arch x86_64 -DPARROT_CONFIG_TEST" and running the output; the SSE check also segfaults when I manually run it. No crash happens if I change the $byteorder check in config::auto::arch to respond with x86_64

[perl #57538] [BUG] MMX check in config/auto/cpu/i386 segfaults when run as a 64-bit binary on OS X 10.5

On Sat Aug 02 20:08:36 2008, tetragon wrote: > The Configure test for MMX on Intel chips Was this a test in t/configure/? t/steps/? or during Configure.pl itself?

[perl #57538] [BUG] MMX check in config/auto/cpu/i386 segfaults when run as a 64-bit binary on OS X 10.5

# New Ticket Created by "Seneca Cunningham" # Please include the string: [perl #57538] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=57538 > The Configure test for MMX on Intel chips segfaults when built as a 64-bit binary

Re: [perl #31133] [TODO] Run different run cores inside Test.pm

I can make this work for 'make fulltest' in t/harness if 'make fulltest' can legitimately require TAP::Harness. (The secret is to add a --fulltest flag to the harness, which passes a sub reference to TAP::Harness to return an array reference of Parrot paths with runcore flags to execute for eac

Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt

On 29/03/2008, James Keenan via RT <[EMAIL PROTECTED]> wrote: > On Fri Mar 28 21:03:12 2008, [EMAIL PROTECTED] wrote: > > Parrot::Test uses the full path of the test script to determine which > > optimization flags to pass parrot. The method used causes the bogus > > optimization value '/' to b

Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt

use File::Basename; use Memoize (); use Parrot::Config; @@ -575,6 +576,7 @@ die "Unknown test function: $func"; } $code_f = File::Spec->rel2abs($code_f); +my $code_basef = basename($code_f); # native tests are just run, others need to write code first if ( $cod

Re: [perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt

? "-O$1" : "-O1"; +my $opt = $code_basef =~ m!opt(.)! ? "-O$1" : "-O1"; my $args = $ENV{TEST_PROG_ARGS} || ''; $args .= " $opt --output=$out_f"; $args =~ s/--run-exec//;

[perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt

? "-O$1" : "-O1"; +my $opt = $code_f =~ m!opt/(.)! ? "-O$1" : "-O1"; my $args = $ENV{TEST_PROG_ARGS} || ''; $args .= " $opt --output=$out_f"; $args =~ s/--run-exec//;

[perl #52224] Parrot::Test calls parrot with a bogus optimization values when run in /opt

# New Ticket Created by "Seneca Cunningham" # Please include the string: [perl #52224] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=52224 > Parrot::Test uses the full path of the test script to determine which optimizatio

[perl #31133] [TODO] Run different run cores inside Test.pm

On So. 24. Feb. 2008, 17:39:36, [EMAIL PROTECTED] wrote: > 'make fulltest' exits at the end of any core with failing tests; > that's how I > expect make to behave. (If it doesn't, there's something wrong.) Actually it no longer does that, as I have changed 'make fulltest' in preparation for the

Re: [perl #31133] [TODO] Run different run cores inside Test.pm

On Sunday 24 February 2008 17:19:58 Will Coleda wrote: > When cutting a release, we do a 'make fulltest', which runs parrot > with various cores to verify that no supported core fails any tests; > the problem with fulltest is that it uses four different harnesses; > This means sifting through a lo

Re: [perl #31133] [TODO] Run different run cores inside Test.pm

On Sun, Feb 24, 2008 at 7:35 PM, James Keenan via RT <[EMAIL PROTECTED]> wrote: > On Sun Aug 15 13:02:08 2004, coke wrote: > > > > Nothing has been done on this ticket in 3-1/2 years. chromatic's > question of two years back remains unanswered. I can't fin

[perl #31133] [TODO] Run different run cores inside Test.pm

On Sun Aug 15 13:02:08 2004, coke wrote: > Nothing has been done on this ticket in 3-1/2 years. chromatic's question of two years back remains unanswered. I can't find the phrase 'Run different run cores' inside TODO, Parrot::Test or any other file in the current distrib

[perl #50314] [BUG] t/harness: Test::Run fails to test cleanly

Patch applied to trunk in r25320.

[perl #50314] [BUG] t/harness: Test::Run fails to test cleanly

On Sun Jan 27 17:36:02 2008, [EMAIL PROTECTED] wrote: > As part of my exploration of t/harness (http://rt.perl.org/rt3/Ticket/ > Display.html?id=50302), I had occasion to try the Test::Run variant. > However, when I tried to install Test::Run today (no small feat, as > it sits

[perl #50314] [BUG] t/harness: Test::Run fails to test cleanly

?id=50302), I had occasion to try the Test::Run variant. However, when I tried to install Test::Run today (no small feat, as it sits on a pile of non-core dependencies), it failed one of its tests (see attached output from Linux; I got the same failure on Darwin). cpan[2]> install SHLOMI

Re: expected test failures in t/pmc, t/run, and t/stm

Allison Randal wrote: Thanks all for the reports. I see two common trouble spots in hellgrind and the test output. One is a possible race condition if two threads add tasks to the concurrency scheduler at exactly the same moment. The other is the fact that PCC uses globals in the interpreter to

Re: expected test failures in t/pmc, t/run, and t/stm

Here's where we stand after r24412 on Linux. t/dynoplibs/myops..1..10 ok 1 - fortytwo ok 2 - what_do_you_get_if_you_multiply_six_by_nine ok 3 - hcf ok 4 - a short cheating quine ok 5 - one alarm ok 6 - three alarm ok 7 - repeating alarm ok 8 - bxand - A AND B, but not BOTH ok 9 - conv_u2_i ok

Re: expected test failures in t/pmc, t/run, and t/stm

Thanks all for the reports. I see two common trouble spots in hellgrind and the test output. One is a possible race condition if two threads add tasks to the concurrency scheduler at exactly the same moment. The other is the fact that PCC uses globals in the interpreter to store invocation info

[perl #49258] Parrot::Test with --run-exec assumes "." is in $PATH

::Test tests => 1; # Odd communication with Parrot::Test. my $args = $ENV{TEST_PROG_ARGS} || ''; $args .= ' ' if $args; $args .= '--run-exec'; local $ENV{TEST_PROG_ARGS} = $args; pir_output_is( <<'CODE', <<'OUTPUT', ".const of n

Re: expected test failures in t/pmc, t/run, and t/stm

On Monday 31 December 2007 07:16:44 Allison Randal wrote: > Just an FYI that intermittent test failures are to be expected after > r24346 in the following files: > > t/pmc/nci.t 1 256651 50 > t/pmc/task.t1 256 3 1 3 &g

expected test failures in t/pmc, t/run, and t/stm

Just an FYI that intermittent test failures are to be expected after r24346 in the following files: t/pmc/nci.t 1 256651 50 t/pmc/task.t1 256 31 3 t/run/options.t 1 256261 23 t/stm/basic_mt.t3 768 4

[perl #41860] [CAGE] Run Parrot under Coverity Prevent

Parrot is now running under Coverity Prevent. The address for access to its output is: http://scan2.coverity.com:9035/. If you wish to get an account to be able to then access the scan page, you will need to send an email to [EMAIL PROTECTED] I'm going to put this info up on the Parrot wiki

[perl #42690] [TODO] optionally run configure/build tests during config process

No complaints in last 2-1/2 weeks. Resolving ticket.

Re: [perl #43041] [PATCH] don't run t/distro/file_metadata.t from release tarballs

On Wednesday 23 May 2007 13:29:26 Mark Glines wrote: > I think the test should only run if a file named "DEVELOPING" exists, > just like the codingstd tests do. Agreed. Thanks, applied as r18635. -- c

[perl #43041] [PATCH] don't run t/distro/file_metadata.t from release tarballs

st hang. Gentoo builds things as a special user, and it overrides $HOME with a newly created tmpdir, so svk is guaranteed to hang in this case. I think the test should only run if a file named "DEVELOPING" exists, just like the codingstd tes

[perl #42690] [TODO] optionally run configure/build tests during config process

Applied with slight correction in r.. Correction was to place 2 tests in t/configure/25-options_test.t into SKIP blocks when $ENV {PERL5OPT}=-MDevel::Cover. This was necessary because Devel::Cover was gagging on running tests within tests. Tested in both trunk and reconfigure branch; resu

[perl #42690] [TODO] optionally run configure/build tests during config process

On Sat May 12 07:17:36 2007, jkeen at verizon.net wrote: > Applied with slight correction in r.. > That would be: r18516. kid51

[perl #42690] [PATCH] optionally run configure/build tests during config process

Please review patch. Index: Configure.pl === --- Configure.pl(revision 18438) +++ Configure.pl(working copy) @@ -60,8 +60,35 @@ This turns on the user prompts. +=item C<--test> + +Run certain tests along

[perl #42690] [TODO] optionally run configure/build tests during config process

I have taken this ticket because I have begun working on it in the 'reconfigure' branch.

[perl #42690] [TODO] optionally run configure/build tests during config process

art to jim keenan. however, these tests are not run during the normal build cycle, which limits their effectiveness. i'd like to make running these tests easier by allowing Configure.pl to accept command-line options which allow a user to run the tests. therefore, i propose a --test option, th

[perl #41860] [CAGE] Run Parrot under Coverity Prevent

On Thu Mar 15 19:24:31 2007, ptc wrote: > Coverity already runs Prevent on the Perl 5 source. Let's get > Parrot running under it, too. L Just to keep this ticket up to date with what's happening, here is a reply to my email asking to add Parrot to Coverity which recen

[perl #41877] [PATCH] Allow to use Test::Run as a Harness

# New Ticket Created by Shlomi Fish # Please include the string: [perl #41877] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41877 > This patch gives an option to use Test::Run[1] as a harness for running the tests us

[perl #41877] [PATCH] Allow to use Test::Run as a Harness

Thanks, Applied!

[perl #41860] [CAGE] Run Parrot under Coverity Prevent

# New Ticket Created by Paul Cochrane # Please include the string: [perl #41860] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41860 > Coverity already runs Prevent on the Perl 5 source. Let's get Parrot running under it,

[perl #41241] [BUG] Tcl doesn't compile/run on win32.

# New Ticket Created by Will Coleda # Please include the string: [perl #41241] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=41241 > Need details.

Re: Are CATCH blocks still in effect when run?

On Sun, Jul 02, 2006 at 09:26:20PM -0400, Bob Rogers wrote: :However, I notice that S04 doesn't explicitly specify the dynamic : environment for anything evaluated in a CATCH block. Does now. Thanks! Larry

Are CATCH blocks still in effect when run?

sight. If so, then that would make my life easier. A key aspect of both HANDLER-CASE and HANDLER-BIND is that none of the handlers they establish are in scope when those handlers are invoked. That way, if a badly-written handler should be prone to (re)igniting printers, you don't get looping.

Re: [perl #38841] [TODO] Split exec run core into two distinct run cores

c_run'. Very much appreciated. As already noted in that include file, runcore feature bits should be arranged, so that individual parts of a run core can be tested too. E.g. exec := jit_bit | exec_bit. And while there, e.g. runcore should have an associated name for better error report

[perl #38841] [TODO] Split exec run core into two distinct run cores

# New Ticket Created by Bernhard Schmalhofer # Please include the string: [perl #38841] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38841 > The exec runcore is about saving compiled JIT code in an object file and gener

Re: [perl #38480] [PATCH] Slight improvements to documenting run cores

On Feb 10, 2006, at 16:35, Andy Dougherty (via RT) wrote: The following patch would have made it slightly easier for me to figure it out (mostly by assuring that the same abbreviations are used consistently so that grep helps you finds the relevant documents more quickly.) Thanks, applied -

[perl #38480] [PATCH] Slight improvements to documenting run cores

3:15:02 2005 +++ parrot-andy/docs/running.podFri Feb 10 10:04:46 2006 @@ -133,6 +133,8 @@ =head2 Run Core Options +TODO: The default run core should be indicated. + =over 4 =item -b, --bounds-checks, --slow-core @@ -141,7 +143,7 @@ =item -C, --CGP-core -Select the CGP (CGot

Re: Can Parrot and Perl6 run on z/OS UNIX?

n, Win32, Tru64, OpenVMS (Alpha), Solaris (Sparc), FreeBSD (x86)." a)Can Parrot and Perl6 run on z/OS UNIX as well? If so what is the support currently available? At the moment I don't see anything specific with regrad to z/OS in the config system, so I guess we currently may not be able to

Can Parrot and Perl6 run on z/OS UNIX?

eBSD (x86)." a)Can Parrot and Perl6 run on z/OS UNIX as well? If so what is the support currently available? b)Are the features currently available will also be present for z/OS UNIX? c)Are there any architecture dependency issues? Thanks in advance regards Ravi Sastry

[perl #38114] [TODO] Tcl - Run tcltest.tcl

# New Ticket Created by Will Coleda # Please include the string: [perl #38114] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38114 > The next *big* milestone is to be able to run tcl's test suite natively. Th

[perl #22706] IMCC (& Parrot) crash with -t when invoke is run

Can't reproduce, seems to pass C call. Should be closed. .sub _main # void win32_setup(void) loadlib P1, "kernel32.dll" dlfunc P0, P1, "GetStdHandle", "pi" set I0, 1 set I5, -11 invoke # Will crash here. store_global "kernel32", P1 store_global "Win32handle", P5 e

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

On Mon, Dec 13, 2004 at 01:46:49PM -0500, Matthew Zimmerman wrote: > I'm going to have to stop sending patches if it's going to take 5 hours > for my messages to get to the list. You guys are so damned fast, I can't > compete! :) I think that your messages hit the moderator, as your address wasn

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

Dan Sugalski (via RT) wrote: # New Ticket Created by Dan Sugalski # Please include the string: [perl #33028] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 > A plain ./parrot foo.pbc when foo.pbc doesn't exist t

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

Dan Sugalski (via RT) wrote: # New Ticket Created by Dan Sugalski # Please include the string: [perl #33028] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 > A plain ./parrot foo.pbc when foo.pbc doesn't exist t

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

chromatic wrote: On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote: A plain ./parrot foo.pbc when foo.pbc doesn't exist triggers a core dump on OS X. The problem is in embed.c not checking the results of Parrot_locate_runtime_file(). Here's a naive patch. [snip chromatic's fine patch, very

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

Matthew Zimmerman <[EMAIL PROTECTED]> wrote: > strlen() is puking on the NULL return from Parrot_locate_runtime_file() > in Parrot_readbc. Attached patch fixes this behavior. Thanks, applied. leo

Re: [perl #33028] Parrot cores when asked to run a nonexistent bytecode file

On Mon, 2004-12-13 at 07:44 -0800, Dan Sugalski wrote: > A plain > > ./parrot foo.pbc > > when foo.pbc doesn't exist triggers a core dump on OS X. The problem is in embed.c not checking the results of Parrot_locate_runtime_file(). Here's a naive patch. Is there a good place to put tests f

[perl #33028] Parrot cores when asked to run a nonexistent bytecode file

# New Ticket Created by Dan Sugalski # Please include the string: [perl #33028] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=33028 > A plain ./parrot foo.pbc when foo.pbc doesn't exist triggers a core dump on OS

Re: Prederefed run cores

FWIW the CGP sub_i_i_i opcode on the PowerBook 0x001048d4 :lwz r0,8(r30) 0x001048d8 :lwz r2,12(r30) 0x001048dc :lwzxr0,r27,r0 0x001048e0 :lwzxr2,r27,r2 0x001048e4 :lwz r9,4(r30) 0x001048e8 :subfr0,r2,r0 0x001048ec :stwxr0,r27,r9 0x001048f0 :

Re: Prederefed run cores

Dan Sugalski <[EMAIL PROTECTED]> wrote: > Or 3) Toss the prederef stuff entirely. And here is, why I want to keep the CGP core: sub_i_i_i 0x81bbef0 : mov0x4(%esi),%ecx 0x81bbef3 : mov0x8(%esi),%edx 0x81bbef6 : mov0xc(%esi),%eax 0x81bbef9 : add$0x10,%esi 0x8

Re: Prederefed run cores

Dan Sugalski <[EMAIL PROTECTED]> wrote: > While I want to keep the switch core, I'm still not seeing the need > for prederef with it. I'm presuming this crept in at some point and > just needs un-creeping? Using prederef for switch has one advantage: it's a bit faster. Before the indirect registe

Re: Prederefed run cores

of CGP.pm and CSwitch.pm but can be cleanued up too. I still like to keep CGP and CSwitch run cores. The latter as the safe run core with argument checking and as a fallback, if CGOTO isn't available on that platform. The former as an extension for JIT to run non-JITted opcodes. Similar t

Re: Prederefed run cores

x for prederefed run cores. It's unoptimized currently. make fulltest is passing again here. Or 3) Toss the prederef stuff entirely. Well, the prederefed function core (parrot -P) is for sure not necessary. Patches welcome to remove the plain prederefed function core F. F is still ne

Re: Prederefed run cores

Duraid Madina wrote: Dan Sugalski wrote: Or 3) Toss the prederef stuff entirely. Which might not be quite as bad as it sounds: on at least one "strange platform" (IA64 HP-UX) the native C compiler gets the switch core running faster than the prederef core! (!) Err, the switched core *is* a prede

Re: Prederefed run cores

is prederefed too. CGP is by far the fasted run-core for JIT-less architectures, if CGoto is available. The switched core can of course run w/o prederef too. But one thing is nice with prederef: it's by far the simplest way to create a safe run core that verifies opcode arguments. This cou

Re: Prederefed run cores

Dan Sugalski wrote: Or 3) Toss the prederef stuff entirely. Which might not be quite as bad as it sounds: on at least one "strange platform" (IA64 HP-UX) the native C compiler gets the switch core running faster than the prederef core! (!) Duraid

Re: Prederefed run cores

At 11:13 AM +0200 10/28/04, Leopold Toetsch wrote: With the indirect register addressing all prederefed run cores (Prederefed, CGP, Switch) are currently not functional, as these run cores have absolute addresses in the prederefed code. I see two ways to fix it: 1) use frame pointer relative

Prederefed run cores

With the indirect register addressing all prederefed run cores (Prederefed, CGP, Switch) are currently not functional, as these run cores have absolute addresses in the prederefed code. I see two ways to fix it: 1) use frame pointer relative addressing: + prederefed code is usable by

[perl #31133] [TODO] Run different run cores inside Test.pm

# New Ticket Created by Will Coleda # Please include the string: [perl #31133] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=31133 >

Re: New Dumper, can only run from top level

Hi, On Saturday 20 March 2004 20:09, Will Coleda wrote: > I am having trouble running a .pbc that includes a call to _dumper > unless I run it from the top level parrot directory. > > bash-2.05a$ cat ./foo.imc > .sub main >_dumper($P1) >end > .end > > .inclu

New Dumper, can only run from top level

I am having trouble running a .pbc that includes a call to _dumper unless I run it from the top level parrot directory. bash-2.05a$ cat ./foo.imc .sub main _dumper($P1) end .end .include "library/dumper.imc" bash-2.05a$ ./parrot -o foo.pbc foo.imc bash-2.05a$ ./parrot foo.pbc &quo

Re: [perl #27505] [PATCH] allow to run classes/pmc2c2.pl from any directory

Ilya Martynov <[EMAIL PROTECTED]> wrote: > Patch below my signature is required to allow to run classes/pmc2c2.pl > from any directory. Otherwise it will complain it cannod find .dump > files unless it is being run from parrot directory. Thanks, applied. leo

[perl #27505] [PATCH] allow to run classes/pmc2c2.pl from any directory

# New Ticket Created by Ilya Martynov # Please include the string: [perl #27505] # in the subject line of all future correspondence about this issue. # http://rt.perl.org:80/rt3/Ticket/Display.html?id=27505 > Patch below my signature is required to allow to run classes/pmc2c2.pl from

Re: How to run typeless languages fast on parrot?

On 11/07/03 Leopold Toetsch wrote: > Very interesting. While we don't compete with typed languages, its nice Oh, but mono _will_ also compete with dynamically typed languages! :-) > to see, that parrot execution speed is in the region of mono - for such > small tight loops. Well, that was mono

Re: How to run typeless languages fast on parrot?

Paolo Molaro wrote: I couldn't resist writing an equivalent program that runs on the Mono VM:-) Very interesting. While we don't compete with typed languages, its nice to see, that parrot execution speed is in the region of mono - for such small tight loops. My *guess* is that mono executes t

Re: How to run typeless languages fast on parrot?

rts out as an integers and becomes a float mid-way. There are three different loops that simulate how smart a compiler frontend could be: one puts just $i in a 'PMC' (PerlSV in the C# code), the second puts the loop upper bound, too, to match with the above imcc code and the last puts the 5

Re: How to run typeless languages fast on parrot?

Sterling Hughes <[EMAIL PROTECTED]> wrote: > php mandel2.php 1.93s user 0.01s system 76% cpu 2.552 total That's measuring IO speed mainly :) But anyway good. BTW: $ time ./yal examples/mandelbrot.yal | parrot - >/dev/null real0m0.420s user0m0.420s $ time ./yal examples/mandelbrot.yal |

Re: How to run typeless languages fast on parrot?

> At 04:10 PM 11/5/2003 -0700, Luke Palmer wrote: > >Actually that was pretty good for an early version. You could help IMCC > >out by not creating those PerlUndefs until you're going to assign to > >them. > > Also, anytime you use a temporary to assing a constant literal, you > should be able to

Re: How to run typeless languages fast on parrot?

On Wed, 5 Nov 2003, Thies C. Arntzen wrote: > hi, Hi ho, and glad to have you on-board. :) > we've started a project (will have a web-page soon) that aims to port the > php-language (www.php.net) to run on top of parrot. we've written some > init

Re: How to run typeless languages fast on parrot?

rator could be overloaded and calculate the phase of the moon instead of adding 5.5 ... union { Yeah, that's a PMC. ... could you explain how you are planning to make untyped languages run really fast on parrot and what direction i have to take to use that technique? AFAIK you

Re: How to run typeless languages fast on parrot?

At 06:26 PM 11/5/2003 -0500, Melvin Smith wrote: >Also, anytime you use a temporary to assing a constant literal, you s/assing/assign =0) -Melvin

Re: How to run typeless languages fast on parrot?

At 04:10 PM 11/5/2003 -0700, Luke Palmer wrote: Actually that was pretty good for an early version. You could help IMCC out by not creating those PerlUndefs until you're going to assign to them. Also, anytime you use a temporary to assing a constant literal, you should be able to use a I/S/N reg.

Re: How to run typeless languages fast on parrot?

Thies C. Arntzen writes: > hi, > > we've started a project (will have a web-page soon) that aims to > port the php-language (www.php.net) to run on top of parrot. Cool! > we've written some initial code and i'm kinda stuck while >

Re: How to run typeless languages fast on parrot?

At 08:54 PM 11/5/2003 +0100, Thies C. Arntzen wrote: we've started a project (will have a web-page soon) that aims to port the php-language (www.php.net) to run on top of parrot. we've written some First of all, welcome! :) I'll read your mail in depth and send a

How to run typeless languages fast on parrot?

hi, we've started a project (will have a web-page soon) that aims to port the php-language (www.php.net) to run on top of parrot. we've written some initial code and i'm kinda stuck while writing the codegen (i target imc) my problem

{CVS ci] separated interpreter flags and run core flags

interpreter->flags was a mixture of various flags like GC_DEBUG and run core settings. Additionally the CGoto bit was set by default, CGoto + prederef bit did select the CGP core. This is now cleaned up: - flags are flags - run_core settings are separate - only any one core can be active T

Re: [CVS ci] PackFile-12: run code in loaded sorcefile

Piers Cawley <[EMAIL PROTECTED]> wrote: >> >> C > Does this handle function serialization as well? Do you mean loading a source or PBC file and spit out bytecode per subroutine or for one specific subroutine? If so: No - not yet. The Eval PMC can return a whole packfile via get_string(). Eval.get

Re: [CVS ci] PackFile-12: run code in loaded sorcefile

Leopold Toetsch <[EMAIL PROTECTED]> writes: > With this patch, the major pieces are finished > ... > load_bytecode "temp.imc" > $P0 = global "_sub2" >.pcc_begin prototyped >.pcc_call $P0 > > does what it look's like: call the Sub "_sub2" in the loaded sorce file. > > C looks fo

[CVS ci] PackFile-12: run code in loaded sorcefile

With this patch, the major pieces are finished ... load_bytecode "temp.imc" $P0 = global "_sub2" .pcc_begin prototyped .pcc_call $P0 does what it look's like: call the Sub "_sub2" in the loaded sorce file. C looks for a registered compiler of type "FILE". This compiler then compiles

Re: [perl #23063] [PATCH] run make test with valgrind

Hello, > > for searching memory leaks it to run the testsuite with valgrind. The > attached patch allows to run > make test VALGRIND='valgrind -q' > and find the memory bugs. Thanks, applied. Simon

[perl #23063] [PATCH] run make test with valgrind

# New Ticket Created by Jürgen Bömmels # Please include the string: [perl #23063] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=23063 > Hello, for searching memory leaks it to run the testsuite with valgrind.

Re: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run

er in getting a stack trace to the problem. > This may just be a quirk in MSVS.NET. I can't get the vcdg (debug) version of the > program to run beyond: > func(INTERP, SELF); // <-- here Strange. Parrot_jit_build_call_func() even does emit a stack frame. Can you single step through it in assembly mode? leo

Re: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run

rk in MSVS.NET. I can't get the vcdg (debug) version of the program to run beyond: pmclass NCI { void* invoke (void * next) { Parrot_csub_t func = (Parrot_csub_t)D2FPTR(PMC_data(SELF)); func(INTERP, SELF); // <-- here return next; } } My guess is that my

Re: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run

Clinton Pierce wrote: Clarification: running an invoke() at *any* time will cause all subsequent tracing to segfault. I can't reproduce that on Linux (even with Dan's patch not applied yet). leo

Re: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run

At 7:58 PM -0400 6/29/03, Clinton Pierce wrote: Clarification: running an invoke() at *any* time will cause all subsequent tracing to segfault. Thus (pseudoPASM): loadlib dlfunc invoke trace 1 end Will cause the segfault. I checked in a fix for

Re: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run

t;Clinton A. Pierce" (via RT) <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Date: Sun, Jun-15-2003 11:06 AM > Subject: [perl #22706] IMCC (& Parrot) crash with -t when invoke is run > > # New Ticket Created by "Clinton A. Pierce" > # Please include the string

  1   2   >