On Mar 30, 2007, at 9:19 PM, chromatic wrote:
On Friday 30 March 2007 13:59, Alek Storm wrote:
I used a simple benchmark to compare the relative speeds of Parrot
with and without the patch, and I was surprised to find that the test
script runs (very roughly) 10% faster *with* the patch. Can s
# New Ticket Created by chromatic
# Please include the string: [perl #42230]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42230 >
Parrot::Test reports tests that produce the right output but crash instead of
exiting clea
# New Ticket Created by chromatic
# Please include the string: [perl #42229]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42229 >
$ parrot t/pmc/exporter_6.pir
ok 1 - import() with no args does nothing
Segmentation fault
Author: chromatic
Date: Fri Mar 30 22:37:45 2007
New Revision: 17873
Modified:
trunk/docs/pdds/pdd07_codingstd.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[EMAIL PROTECTED]: chromatic | 2007-03-30 22:37:22 -0700
Minor typo fixes, courtesy of
On Friday 30 March 2007 13:59, Alek Storm wrote:
> I used a simple benchmark to compare the relative speeds of Parrot
> with and without the patch, and I was surprised to find that the test
> script runs (very roughly) 10% faster *with* the patch. Can someone
> confirm this? Running revision 178
-1 is often used to signify infinity, so the code using it would
probably be a little clearer if it used that. However, since 0 isn't
a logical value anyway, that's probably a good idea, though I haven't
seen much bare type-converting in the Parrot source.
On 3/30/07, Nicholas Clark <[EMAIL PROT
On Fri, Mar 30, 2007 at 10:25:59PM +, Alek Storm wrote:
> How about like this:
>
> $P0 = getinterp
> $P0["recursionlimit"] = 2000
> $P0["recursionlimit"] = -1
>
> Where the last one signifies an infinite recursion limit (unsafe, but
> it should still be available to HLL implementors).
Is the
Hmm. You know what I just found out? The ParrotInterpreter PMC
doesn't implement set_pmc_keyed. Any objections to implementing it?
It could then be expanded to support getting and setting interpreter
flags, which are currently handled through get_ and
set_integer_keyed_int. Providing a keyed s
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #42225]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42225 >
The third test of t/codingstd/c_parens.t (parentheses should not have
space immediately
How about like this:
$P0 = getinterp
$P0["recursionlimit"] = 2000
$P0["recursionlimit"] = -1
Where the last one signifies an infinite recursion limit (unsafe, but
it should still be available to HLL implementors).
On 3/30/07, chromatic <[EMAIL PROTECTED]> wrote:
On Friday 30 March 2007 13:38,
It would be pretty simple to make this a settable/queryable interpreter
property. Would that be valuable?
It's already a gettable interpreter property
(interp->recursion_limit). I'm guessing it would be valuable to be
able to set the value at runtime. Coke mentioned this on #parrot.
Unfortuna
On Friday 30 March 2007 13:38, Paul Cochrane via RT wrote:
> Thanks! Applied in r17863.
It would be pretty simple to make this a settable/queryable interpreter
property. Would that be valuable?
-- c
Hi,
As suggested by particle++, I added a vtable to the parser in
compilers/pirc.
Now, it's very easy to output PIR /or/ PAST :-) from the parser, without
too much extra code in the parser.
However, as I've only just begun, only very simple stuff will be output.
Changing the flag when creatin
> "jerry" == jerry gay <[EMAIL PROTECTED]> writes:
jerry> i've never run emacs, so i don't know the lispy analog.
jerry> i'm sure somebody will chime in with it.
This does what you think it does:
(setq-default show-trailing-whitespace t)
Emacs 22 users can highlight tabs like this:
(
I used a simple benchmark to compare the relative speeds of Parrot
with and without the patch, and I was surprised to find that the test
script runs (very roughly) 10% faster *with* the patch. Can someone
confirm this? Running revision 17860; benchmark script attached; run
as:
$ parrot bench.pir
On 30/03/07, via RT Will Coleda <[EMAIL PROTECTED]> wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #42169]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42169 >
ala recent "IRC discussion..."
Thanks! Applied in r17863.
Eric Hanchrow wrote:
I think it's relevant to note that I'm using the native Win32
subversion client, and hence most of my files are in DOS format:
carriage-return/linefeed at the end of each line. If I convert that
file's line endings to Unix format (plain line-feeds) it works.
You're right,
Thanks! Applied in r17859.
Note: I had to update include/parrot/debug.h to make sure that src/
debug.c
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42215]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42215 >
http://www.parrotcode.org/docs/pmc/
is missing some of the recently created PMCs, including
chromatic wrote:
On Friday 30 March 2007 07:35, Ron Blaschke wrote:
Not 100% on this, but I think one or two of the stm tests hang, too.
t/pmc/stmlog.t, test 2?
No, I think this one's fine. More like t/stm/queue.t test 2 and
t/stm/runtime.t test 4. Actually, t/stm/queue.t sometimes seems
On Wednesday 14 March 2007 23:00, via RT wrote:
> Index: include/parrot/sub.h
> ===
> --- include/parrot/sub.h(Revision 17473)
> +++ include/parrot/sub.h(Arbeitskopie)
> @@ -87,7 +87,6 @@
> SUB_COMP_FLAG_BIT_28 =
On Friday 30 March 2007 07:35, Ron Blaschke wrote:
> Not 100% on this, but I think one or two of the stm tests hang, too.
t/pmc/stmlog.t, test 2?
-- c
On Friday 30 March 2007 09:36, Nicholas Clark wrote:
> An alternative is to have C be an alias, either to C devtest> by default, and a smaller C (or somesuch) when the
> source tree is an official release. Having the source tree know when it's
> an official release (perhaps by including or not inc
On Fri, Mar 30, 2007 at 08:58:19AM -0700, Allison Randal wrote:
> I concur that the user shouldn't get failing tests for things like
> whitespace at the end of lines. More importantly, the user shouldn't be
> wasting time running tests for coding standards and documentation. How
> about a 'make
Will Coleda wrote:
So lets document what we need. Right now 'make smoke' generates an HTML
report which is uploaded to the smoke server.
Talk has happened in the past about making this more DB like instead of
rendered output, but my concern is for the user visible features we're
lacking. Perh
jerry gay wrote:
Should we even require all of these tests to be ran by default? These
tests should never fail for a user compiling a release version of
parrot, so should they need to test them? They're good for developers,
but only developers.
until we stop actively developing major subsyst
On Thu Mar 15 05:30:31 2007, nahoo wrote:
> On Mi. 14. Mär. 2007, 23:00:18, nahoo wrote:
> > Index: include/parrot/sub.h
> > ===
> > --- include/parrot/sub.h(Revision 17473)
> > +++ include/parrot/sub.h(Arbeitskopie)
>
Paul Cochrane wrote:
Sorry, I guess there was some mental PATH overloading going on. Try
adding the absolute path to F to PATH.
export PATH=/path/to/parrot/blib/lib:$PATH
And then "make."
I tried this (although, I appended the blib path to PATH, not sure if
that makes a difference) and
On Thu, Mar 29, 2007 at 07:28:52PM +0200, Paul Cochrane wrote:
> On 28/03/07, via RT Steve Peters <[EMAIL PROTECTED]> wrote:
> ># New Ticket Created by Steve Peters
> ># Please include the string: [perl #42156]
> ># in the subject line of all future correspondence about this issue.
> ># http://rt
On 3/29/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Mar 29, 2007, at 4:20 PM, jerry gay wrote:
> On 3/29/07, Nicholas Clark <[EMAIL PROTECTED]> wrote:
>> > and i'm not interested in testing every
>> revision,
>> > when so many might be coding standards
>>
>> Why are people ev
Ron Blaschke wrote:
Paul Cochrane wrote:
I don't know if it's of much help, but I too am getting the Cygwin
build barfing when miniparrot goes to build
runtime/parrot/include/config.fpmc.
I think that's actually a good sign. Try adding the absolute path to
F and try again. If this is workin
32 matches
Mail list logo
