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
Fblib/lib and try again. If this
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:
particle and i'm not interested in testing every
revision,
when so many might be coding standards
Why are people even
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.
# URL:
Paul Cochrane wrote:
Sorry, I guess there was some mental PATH overloading going on. Try
adding the absolute path to Fblib/lib 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
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)
@@ -87,7
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
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.
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
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 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 = 1
On Friday 30 March 2007 09:36, Nicholas Clark wrote:
An alternative is to have Cmake test be an alias, either to Cmake
devtest by default, and a smaller Cmake usertest (or somesuch) when the
source tree is an official release. Having the source tree know when it's
an official release (perhaps
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
# New Ticket Created by Jerry Gay
# Please include the string: [perl #42215]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42215
http://www.parrotcode.org/docs/pmc/
is missing some of the recently created PMCs,
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
Thanks! Applied in r17859.
Note: I had to update include/parrot/debug.h to make sure that src/
debug.c
Thanks! Applied in r17863.
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42169
ala recent IRC
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
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:
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
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
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.
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, Paul
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #42225]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42225
The third test of t/codingstd/c_parens.t (parentheses should not have
space
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
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 value
-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
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 17860;
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
# New Ticket Created by chromatic
# Please include the string: [perl #42229]
# in the subject line of all future correspondence about this issue.
# URL: 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
# New Ticket Created by chromatic
# Please include the string: [perl #42230]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42230
Parrot::Test reports tests that produce the right output but crash instead of
exiting
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
32 matches
Mail list logo
