On Jan 12, 2008, at 9:42 AM, James Keenan (via RT) wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #49668]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=49668 >
Test file t/op/jit.t currentl
What does atan2(0, 0) generate on tru64?
On Jan 5, 2008, at 7:51 PM, Jarkko Hietaniemi wrote:
--- src/pmc/complex.pmc.dist2008-01-06 00:48:21.0 +0200
+++ src/pmc/complex.pmc 2008-01-06 02:53:34.0 +0200
@@ -1180,7 +1180,10 @@
im = 0.0;
RE(d) = log(sqrt(
On Dec 10, 2007, at 10:59 AM, Klaas-Jan Stol wrote:
In order to draw attention to this point, I changed the subject.
Is there anybody who thinks the removal from PIR of $-less registers
("absolute" or PASM registers) should not be done?
kjs
Parrot provides a calling convention, but does no
On Nov 29, 2007, at 10:13 PM, Patrick R. Michaud wrote:
Also, in case it matters, I'm on x86 (32-bit) for this.
Pm
Does it still occur after `ccache -C`? Since ccache uses md5, there's
always the possibility you inadvertently discovered a collision in md5.
Might want to back up ~/.ccac
How can you know what opcodes a dynamically loaded library provides at
compile time? If there's no other method than interp, then you'll have
to use interp to find out what's valid and what's not, without
redesigning how dynops are handled.
On Nov 27, 2007, at 1:15 PM, [EMAIL PROTECTED] wrote
Try running Configure.pl with --execcapable=0 and you'll probably get
further through. Probably need a config hint somewhere.
On Nov 21, 2007, at 8:17 AM, Simon Dassow (via RT) wrote:
# New Ticket Created by Simon Dassow
# Please include the string: [perl #47666]
# in the subject line of al
On Nov 14, 2007, at 1:35 PM, Andy Dougherty wrote:
I'm forwarding a message I got about the f == 0.0 warnings.
--
Andy Dougherty [EMAIL PROTECTED]
-- Forwarded message --
Date: Wed, 14 Nov 2007 10:38:10 -0500
From: Jeffrey Kegler <[EMAIL PROTECTED]>
To: Andy D
On Nov 13, 2007, at 9:06 PM, James Keenan via RT wrote:
On Sun Nov 11 22:29:21 2007, ptc wrote:
My next guess now is that the -std=c89 gcc compiler option doesn't
play nicely with your system headers. I've removed the compiler flag
in r22809, see how you go.
Paul
It did. Now Darwin is
On Nov 10, 2007, at 7:42 AM, James Keenan via RT wrote:
On Fri Nov 09 23:31:56 2007, [EMAIL PROTECTED] wrote:
It in no way refers to architecture actually. It refers to the
calling
convention on an architecture(dependent upon implementation). The x86
method is by pushing arguments onto the
On Nov 9, 2007, at 2:24 AM, Paul Cochrane wrote:
On 09/11/2007, Joshua Isom <[EMAIL PROTECTED]> wrote:
Did you test the exec runcore? I don't think any of that code is used
outside of the exec runcore so you aren't actually testing that code.
I'll have a go at tes
On Nov 9, 2007, at 8:08 PM, James Keenan (via RT) wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #47313]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=47313 >
The description for Parrot con
Did you test the exec runcore? I don't think any of that code is used
outside of the exec runcore so you aren't actually testing that code.
Also, I'm not sure the exec runcore even works. I haven't heard of it
working in quite some time.
On Nov 8, 2007, at 3:21 PM, Paul Cochrane (via RT) wr
On Oct 25, 2007, at 4:35 PM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46927]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46927 >
The attached patch removes
On Oct 23, 2007, at 5:45 PM, Allison Randal wrote:
Klaas-Jan Stol wrote:
Hi, attached a document describing the current macro layer of IMCC.
On the proposed modifications to macros, I have reservations on the
automatic munging of .local variable names. Macros are simple
parameterized subst
On Oct 20, 2007, at 2:33 PM, Paul Cochrane via RT wrote:
The ctags program is now detected at configuration time (this program
sometimes has different names on different systems) and now 'make tags'
should work out of the box for all the variations that I'm aware of
(namely ctags, exuberant-cta
It seems as though the first line seems to have caught my eye.
In most languages, ~ is used for bitwise not, and not bitwise xor which
is given ^. Parrot seems to do things a tad differently. An analysis
of the generated pir shows how parrot treats it now.
.sub main
$I0 = 5
On Oct 13, 2007, at 7:20 AM, Ron Blaschke wrote:
Attached patch should fix computed goto on Solaris with the Sun C
compiler.
All tests successful (7 subtests UNEXPECTEDLY SUCCEEDED), 11 tests and
621 subtests skipped.
Passed TODO Stat Wstat TODOs Pass List of Passed
On Oct 12, 2007, at 7:33 PM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46389]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46389 >
In src/dynpmc/gdbmhash.c t
On Oct 1, 2007, at 12:45 PM, jerry gay wrote:
On 10/1/07, Paul Cochrane via RT
<[EMAIL PROTECTED]> wrote:
src/exceptions.c has a todo comment in it:
* XXX TODO get rid of all the internal_exceptions or call them
* with an interpreter arg
The fact that we can't completely get rid o
It doesn't work completely with FreeBSD's make it seems. Building
'parrot' works just fine, dynpmc stuff fails with this.
g++ -o ./parrot src/main.o blib/lib/libparrot.a -lpthread -lm
-L/usr/local/lib -licuuc -licudata -lpthread -lm -lm -lcrypt -lutil
-pthread -lreadline -Wl,-E -L/usr/l
-Werror -Wdeclaration-after-statement
Should work according to the manpage. But just one little problem.
src/string.c
In file included from src/string.c:26:
src/string_private_cstring.h:21: warning: size of 'parrot_cstrings' is
7560 bytes
*** Error code 1
So we'd have to change some things a
For x86, you can also combine different runcores. If you try -Cj it
might run even faster. What type of program were you running to get
that slowdown? When I got the amd64 jit to the bare bones state, I got
a 10% increase in speed. If Lua's parrot implementation allows you to
turn the sourc
Oh, just pick a small section no one else bothers with. I'm setting up
again for working on complex.pmc(setting up, not working). I'm doing
amd64 jit even if it only works on FreeBSD(not enabled by default for a
reason). If you don't do anything/commit anything for a while, it's
still ok. T
I did get a delay email from gmail. So either gmail's servers are
screwed up and accidently resending the same email repeatedly and not
knowing it succeeded or perl.org's mail servers are screwed up and
making gmail think it needs to be delayed when it's actually sent. But
it's my first time
I'm curious about the test coverage some of the listings. There's 100%
coverage of src/pmc/compiler.pmc but 12.5% coverage of
src/pmc/compiler.c which is created from compiler.pmc. With the
inheritence of pmc's, won't that screw with the coverage reports as
well?
But, as a side note, when I
On Sep 14, 2007, at 6:51 AM, Klaas-Jan wrote:
On Sep 14, 1:47 pm, [EMAIL PROTECTED] (Joshua Isom) wrote:
I may be slow in understanding sometimes, but I really don't know what
you mean.. :-) Could you elaborate a bit more?
Do you mean you want to get unique local variables (as the macro
On Sep 13, 2007, at 9:00 PM, Allison Randal wrote:
Joshua Isom wrote:
And while we're add it, can we add the magic to do the same thing we
to do labels to variables as well?
What thing?
Allison
It's the little magic that turns this:
.macro foo(bar)
.local $baz:
On Sep 13, 2007, at 8:21 PM, Jerry Gay (via RT) wrote:
# New Ticket Created by Jerry Gay
# Please include the string: [perl #45437]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45437 >
in r21240, ptc added a 'cover' tar
On Sep 12, 2007, at 6:21 PM, Will Coleda wrote:
On Sep 12, 2007, at 11:38 AM, Klaas-Jan Stol (via RT) wrote:
# New Ticket Created by Klaas-Jan Stol
# Please include the string: [perl #45405]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticke
On Sep 9, 2007, at 6:40 PM, Doug McNutt wrote:
At 21:16 +0100 9/9/07, Nicholas Clark wrote:
On Sun, Sep 09, 2007 at 10:56:20AM -0700, Jrg Plate wrote:
# http://rt.perl.org/rt3/Ticket/Display.html?id=45309 >
This patch implements the sign function for I, N, BigInt and Complex
numbers.
What sh
On Sep 7, 2007, at 3:02 PM, chromatic wrote:
On Friday 07 September 2007 09:32:51 Patrick R.Michaud wrote:
Chromatic is already aware of this issue, but I thought I'd
file a ticket for it that others can hang information on.
Starting with r21103, Parrot won't build on my 64-bit platform.
It
On Sep 7, 2007, at 7:19 AM, James E Keenan wrote:
If you have gmake installed, then shouldn't
$conf->data->get('gmake_version') return a true value?
>>
>> if ( $conf->data->get('gmake_version') ) {
>> $conf->data->set( make_c => "$prog -C" );
>> }
>> else {
If so, how wou
On Sep 6, 2007, at 7:52 PM, James Keenan via RT wrote:
On Fri Jun 08 06:48:12 2007, ptc wrote:
In the file config/inter/make.pm, there is the following todo item:
# FIXME this is an ugly hack
# replace the value for $(MAKE) with the actual path or we'll
end up
# with
As far as I know the code in question would primarily apply to Linux on
amd64. It may also apply to other systems on amd64, but I know that
particular directory structure is used with Linux. FreeBSD is not
affected(but then again, I never have gotten a 32 bit working build).
On Sep 4, 2007,
On Aug 27, 2007, at 11:13 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44995]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44995 >
Hi everyone,
Another iss
On Aug 20, 2007, at 7:10 PM, chromatic (via RT) wrote:
# New Ticket Created by chromatic
# Please include the string: [perl #44811]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44811 >
Test 91 fails at this PASM with th
On Aug 16, 2007, at 5:25 AM, Paolo Molaro wrote:
On 08/16/07 Ron Blaschke wrote:
The optimization done by the parrot jit is invalid for the x86 C
calling
convention: the area of memory containing the passed arguments
can be used as scratch space by the called function.
If you can make sure it
On Aug 9, 2007, at 9:44 AM, Patrick R. Michaud wrote:
On Thu, Aug 09, 2007 at 07:36:11AM -0700, jerry gay wrote:
On 8/9/07, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
indeed. that's why
array = push item
and
$S0 = 'hello'
$S0 = say
is valid pir.
Actually, $S0 = 'hello' doesn't
On Aug 6, 2007, at 5:41 PM, James Keenan via RT wrote:
On Mon Aug 06 05:57:39 2007, ptc wrote:
This is the block in question in config/init/defaults.pm:
my $archname = $Config{archname};
if ($m) {
if ( $archname =~ /x86_64/ && $m eq '32' ) {
$archname =~ s/x86_64/i
On Aug 4, 2007, at 5:28 AM, Paul Cochrane wrote:
On 03/08/07, via RT Joshua Isom <[EMAIL PROTECTED]>
wrote:
# New Ticket Created by Joshua Isom
# Please include the string: [perl #44391]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/
I'm pretty sure 0.0 always equals -0.0. I think it's part of the c
specification. Now, on OpenBSD, you can't print -0.0, as it will print
0.0 instead which is really annoying. This is with at least 3.8 but I
don't know if it's been changed since then. Anyway, to test for -0.0
instead of 0.0
On Jul 31, 2007, at 11:11 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #44291]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=44291 >
Hi all,
Attached is a pat
On Jul 28, 2007, at 12:54 PM, Will Coleda wrote:
Since I found myself doing this for PGE::Codestring and now for Tcl's
'__stringToList', I thought it might be a good idea to write down the
process in case anyone else finds themselves working on a similar
task.
http://www.perlfoundation.org/
On Jul 11, 2007, at 12:37 PM, Andy Dougherty wrote:
On Wed, 11 Jul 2007, Paul Cochrane wrote:
To be able to configure parrot to build with icc (the intel C
compiler) one currently needs a command line which looks like this:
perl Configure.pl --cc=icc --link=icc --ld=icc
--ccflags=" -no-gcc"
On Jun 21, 2007, at 12:57 PM, Mark J. Reed wrote:
On 6/21/07, Andy Lester <[EMAIL PROTECTED]> wrote:
We now have STRUCT_COPY(dest,src) and STRUCT_COPY_N(dest,src,n) for
all your struct-copying needs.
Wait! Wait! It should be src, THEN dest!
--
Mark J. Reed <[EMAIL PROTECTED]>
Are you a
On Jun 18, 2007, at 4:48 PM, Andy Lester wrote:
Is there a reason we use
memcpy( dest, src, sizeof(FOO) );
instead of
*dest = *src;
The latter should be the exact same code, but be much less likely to
be screwed up.
No, they're extremely different. In the first, the data of FOO is
On Jun 7, 2007, at 3:19 AM, Paul Cochrane (via RT) wrote:
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #43145]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=43145 >
In config/auto/jit.pm there
After a little prodding around, I think the problem is that the dynops
aren't build with the rpath. I don't know how "proper" the following
patch is(i.e. linux doesn't seem to have a problem so either this is
right or the other way is right), but it does the trick.
Index: config/gen/makefiles
You have to add LD_LIBRARY_PATH=.:blib/lib to your environment as in
src/dynoplibs/README(not the best place, but it's where I first found
it) to get it to work at the moment. I don't recall there always
having been an issue but it exists at the moment.
It should be noted probably that darwin
On May 23, 2007, at 8:06 PM, Will Coleda wrote:
On May 23, 2007, at 1:58 AM, Joshua Isom wrote:
I confess to not grasping the point you claim is simple. As you
understand it, what is there about a register based machine, as
opposed to a stack based machine, that specifically improves the
On May 21, 2007, at 5:56 PM, Will Coleda wrote:
I was talking to a colleague (who wishes to remain anonymous), and
s/he had a list of questions about the state of parrot that I think
should end up in the FAQ or elsewhere in the repo. I wanted to post
them here to get some discussion - I don't
On May 16, 2007, at 7:21 PM, James Keenan (via RT) wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #42975]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42975 >
One of the tests in t/tools/o
On May 12, 2007, at 12:25 AM, chromatic wrote:
I agree. It may be a decent test, but it's not a test to run by
default right
now.
While I'm asking for a pony, I'd also like a way to disable the coding
standards tests for an official release tarball.
-- c
This will at least take care of t
On May 9, 2007, at 4:01 PM, Nicholas Clark wrote:
On Wed, May 09, 2007 at 01:06:49PM -0700, chromatic wrote:
On Wednesday 09 May 2007 12:53:57 Nicholas Clark wrote:
On Tue, May 01, 2007 at 04:41:22PM -0700, [EMAIL PROTECTED]
wrote:
+
+#define STRING_IS_NULL(s) ((s) == NULL)
+#define STRING_
The shootouts do not generally run under the default runcore, so these
are not ideal for a standard `make test`. For most of the tests, a
quick alternative for the slow runcore can be found(for some, the input
can be generated by fasta.pir). Both are ran under JIT, so it could be
a JIT proble
At the time I got this email, it was still failing when I applied the
patch, but with r18394 it's currently working again without problems.
A full make test passes with only previously failing errors.
On May 1, 2007, at 2:11 PM, chromatic wrote:
On Sunday 29 April 2007 11:18:20 Joshua
On Apr 29, 2007, at 12:55 PM, Allison Randal via RT wrote:
Joshua Isom (via RT) wrote:
My current svn repository uses a patch that I sent to the list about a
week ago, in which the pge tests would run with gc on if the file
DEVELOPING existed. Since I updated to over 18323,
t/compilers/pge
On Apr 27, 2007, at 2:22 PM, Steve Peters wrote:
On Fri, Apr 27, 2007 at 09:22:22AM -0700, Steve Peters wrote:
# New Ticket Created by Steve Peters
# Please include the string: [perl #42768]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/
On Apr 26, 2007, at 8:28 AM, James E Keenan wrote:
Allison Randal wrote:
Nicholas Clark wrote:
I guess that the most obvious current thing that ties Parrot to the
Perl
community is that Parrot requires a copy of Perl to bootstrap, and
all the
build tools are written in Perl 5.
This is sl
I think that would be more work than truly necessary. We have an
obvious dependency on having a make that can read a generic makefile,
and a c compiler that can compile to the running architecture
successfully(cross compiling would come later). We can limit what goes
into parrot, which pmc's,
Aiming to be as ANSI C compatible as possible will help to make it
build on a PDP-10, although I haven't tried it yet in an emulator. Of
course, some tweaking may be necessary, but that would only increase
portability!
On Apr 25, 2007, at 4:06 AM, Nicholas Clark wrote:
On Tue, Apr 24, 2007
On Apr 21, 2007, at 8:24 PM, chromatic wrote:
Parrot_alloc_context() performs some calculations about the number of
registers used to determine how much memory to allocate:
const size_t size_n = sizeof (FLOATVAL) * n_regs_used[REGNO_NUM];
const size_t size_nip = size_n +
sizeof
On Apr 21, 2007, at 12:41 PM, chromatic wrote:
On Saturday 21 April 2007 04:01, Joshua Isom wrote:
I'm getting failures in t/pmc/class.t, t/pmc/exporter.t,
t/pmc/pccmethod_test.t, t/pmc/role.t, and t/pmc/smop_attribute.t and
all seem to be related to PCCMETHOD's. The failure
On Apr 20, 2007, at 9:18 AM, Andy Dougherty wrote:
On Thu, 19 Apr 2007, Patrick R. Michaud via RT wrote:
On Thu, Apr 19, 2007 at 11:47:55AM -0700, Andy Dougherty wrote:
t/compilers/pge/p5regex/p5rx.Parrot VM: PANIC: Out of
mem!
I believe that both of these tests are currentl
On Apr 19, 2007, at 8:18 PM, Patrick R. Michaud wrote:
On Thu, Apr 19, 2007 at 11:47:55AM -0700, Andy Dougherty wrote:
# New Ticket Created by Andy Dougherty
# Please include the string: [perl #42620]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/r
On Apr 18, 2007, at 3:48 PM, chromatic wrote:
On Wednesday 18 April 2007 13:34, Alek Storm wrote:
Vtable methods defined in C are visible from C.
Of course, otherwise nothing would be able to call them.
Therefore, it makes
sense that vtable methods defined in PIR are visible from PIR, at
On Apr 16, 2007, at 8:46 AM, Andy Dougherty wrote:
On Sun, 15 Apr 2007, Allison Randal via RT wrote:
According to our records, your request regarding
"[TODO] ResizableBooleanArray uses 64 bytes per bit of information"
has been resolved.
If you have any further questions or concerns, please
On Apr 16, 2007, at 8:46 AM, Andy Dougherty wrote:
On Sun, 15 Apr 2007, Allison Randal via RT wrote:
According to our records, your request regarding
"[TODO] ResizableBooleanArray uses 64 bytes per bit of information"
has been resolved.
If you have any further questions or concerns, please
On Apr 14, 2007, at 7:44 AM, Jonathan Worthington wrote:
Hi,
This patch broke the build on some platforms (Win32 with MSVC++
included).
INTVAL
PIO_poll(Interp *interp, PMC *pmc, INTVAL which, INTVAL sec, INTVAL
usec)
{
+if (pmc == PMCNULL) {
+ real_exception(interp, NULL, E_Valu
On Apr 12, 2007, at 1:54 PM, Nicholas Clark wrote:
On Thu, Apr 12, 2007 at 01:50:09PM -0500, Joshua Isom wrote:
On Apr 12, 2007, at 9:29 AM, Nicholas Clark wrote:
My view of this is something along these lines. You can use any
function you want at all, but if it's not documented as
On Apr 12, 2007, at 9:29 AM, Nicholas Clark wrote:
On Thu, Apr 12, 2007 at 09:13:14AM -0500, Steve Peters wrote:
On Thu, Apr 12, 2007 at 01:37:24PM +0200, Ron Blaschke wrote:
I think that we need to tread very carefully with adding additional
gcc-isms to Parrot, lest we break compatibility wi
On Apr 10, 2007, at 2:05 AM, Allison Randal wrote:
Klaas-Jan Stol wrote:
hi,
Some suggestions for PDD15:
1.
reading PDD15, I noticed that some methods/ops are named using an
underscore to separate words, others don't, for instance:
* get_class (but also "getclass" is used in the examples)
* n
On Apr 6, 2007, at 11:48 AM, chromatic wrote:
On Friday 06 April 2007 00:58, Joshua Isom wrote:
What if we had a repository, ala pugs with it's "open" commits, solely
for people to commit tests. It could help improve bug discovery and
test coverage, as well as ambiguity ab
On Apr 5, 2007, at 5:45 PM, Leopold Toetsch wrote:
Am Donnerstag, 5. April 2007 00:39 schrieb Jonathan Worthington:
Don't really need a policy to tell me that breaking stuff for
languages
folks sucks. :-) I try hard to avoid it, but unfortunately stuff slips
through the net occasionally. In t
On Apr 5, 2007, at 10:45 AM, Klaas-Jan Stol wrote:
jerry gay wrote:
i've recently committed (r17998) a draft of PMC documentation
guidelines, for your review. This document is meant to formalize,
clarify, and extend the current de facto style for documentation of
core PMCs. you'll find the docu
On Apr 4, 2007, at 6:39 AM, Paul Cochrane wrote:
On 04/04/07, Joshua Isom <[EMAIL PROTECTED]> wrote:
On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
> # New Ticket Created by Will Coleda
> # Please include the string: [perl #42293]
> # in the subject lin
On Apr 3, 2007, at 11:29 PM, Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #42293]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42293 >
These two scripts perform the s
On Mar 31, 2007, at 3:24 PM, Allison Randal wrote:
Jonathan Worthington wrote:
Does this also imply that all number-based type instantiation is
going away, and thus we need to deprecate the find_type op too?
Eventually, yes (almost certainly), but not in the next month.
Allison
I'm not su
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
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 even checking things in that fail coding standards?
because not a
On Mar 29, 2007, at 10:14 PM, Will Coleda wrote:
On Mar 27, 2007, at 4:45 PM, Allison Randal wrote:
but, we need better smoke tools
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
Perhaps this is too complicated a method. The shootouts should
probably be ran with the testing core. If you want to test the CGP
core, use 'make testC', and so on. Otherwise, how will we know if
ack.pir starts failing with a different runcore? I'd feel it'd be
preferable to ignore the firs
On Mar 25, 2007, at 9:34 PM, James Keenan (via RT) wrote:
# New Ticket Created by James Keenan
# Please include the string: [perl #42082]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42082 >
Ongoing refactoring of Confi
On Mar 23, 2007, at 7:51 AM, Mike Mattie wrote:
On Wed, 21 Mar 2007 18:39:51 -0700
Allison Randal <[EMAIL PROTECTED]> wrote:
chromatic wrote:
Agreed. And we don't work from the installation paths because the
installation paths are broken. Can we break out of this cycle with
some automated tes
Two quick questions, what "hackish" things in pir are you refering to,
and how much more do you think it would take to get bytecode working?
Also, consider that file size alone is not the best indicator of how
well something is programmed, as sometimes a bigger object file is
faster than a sma
to memory management and the garbage collector.
On Mar 1, 2007, at 2:21 PM, Joshua Isom (via RT) wrote:
# New Ticket Created by Joshua Isom
# Please include the string: [perl #41658]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.htm
to memory management and the garbage collector.
On Mar 1, 2007, at 2:21 PM, Joshua Isom (via RT) wrote:
# New Ticket Created by Joshua Isom
# Please include the string: [perl #41658]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.htm
On Mar 4, 2007, at 12:40 PM, Alek Storm wrote:
For the same reason we have set_attr, set_attr_str, get_attr, and
get_attr_str, even though they're only used by ParrotObject - it
allows for
multiple, concurrent object systems. This goal is mentioned in PDD
15, in
"What The Bytecode Sees". Why
On Feb 20, 2007, at 8:44 AM, jerry gay wrote:
On 2/20/07, Aldo Calpini <[EMAIL PROTECTED]> wrote:
no objection here! this is a long-desired feature, and is currently
unavailable. although i don't have a pocketpc to test on, i'll do my
best to help. for years, the dependence on perl 5's configur
On Feb 19, 2007, at 5:57 PM, Nicholas Clark wrote:
There's a benchmark of Ruby implementations at
http://www.antoniocangiano.com/articles/2007/02/19/ruby-
implementations-shootout-ruby-vs-yarv-vs-jruby-vs-gardens-point-ruby-
net-vs-rubinius-vs-cardinal
(or http://xrl.us/uy5m )
There's a c
On Feb 18, 2007, at 7:14 PM, Will Coleda wrote:
On Feb 17, 2007, at 10:14 AM, Patrick R. Michaud via RT wrote:
Yes, but our MANIFEST is just a list of everything in the repository
(modulo a single directory that we started skipping in r12600).
It's best purpose is probably to make sure tha
On Feb 13, 2007, at 1:28 PM, Aldo Calpini wrote:
whoa there!
furthermore, the Configure process uses $^O here and there, and this
should eventually be replaced by an --arch=something parameter to
Configure.pl (which defaults to $^O, of course).
my parrot does indeed run some of the examples
On Feb 7, 2007, at 1:49 PM, chromatic wrote:
On Tuesday 06 February 2007 15:56, James Keenan wrote:
On Feb 6, 2007, at 12:07 PM, Allison Randal wrote:
E ... I'm the one who *needs* the tutorial, not the one to write
it.
That makes you a prime person to capture the questions it needs to
Multimethod constructors? That's one thing that, as far as I know, is
missing from parrot and could be resolved with this. Although the
potential to create an array for sprintf with one opcode does sound
nice, or at least one line of pir.
On Mar 24, 2006, at 11:38 AM, Chip Salzenberg wrote:
at version of OpenBSD were you running (perhaps something old or
direct from CVS)?
-J
--
On Tue, Mar 21, 2006 at 03:13:18PM -0800, Joshua Isom via RT wrote:
On OpenBSD 3.8 x86, I still get the failures with -0.0/0.0. Check the
smokes...
On Mar 21, 2006, at 3:01 PM, Joshua Hoblitt wrote:
On Tue, Ma
On OpenBSD 3.8 x86, I still get the failures with -0.0/0.0. Check the
smokes...
On Mar 21, 2006, at 3:01 PM, Joshua Hoblitt wrote:
On Tue, Mar 21, 2006 at 06:42:42AM -0800, Steve Peters via RT wrote:
[jhoblitt - Sun Jan 01 18:49:23 2006]:
I've commited a possible fix for openbsd, cygwin, &
I think it's gcc 3.3.5 and x86 specific. I'm not positive about the .5
though. I've been building on darwin ppc with 3.3 and it's fine, and
it fails on openbsd too. But it's also successful on gcc 4.1. I've
addressed it with using sprintf, since 1.22461e-16 is close enough to
0.00 f
If the compiler goes through all the constants at compile time to find
identical ones, why not use ".const float number = 0.0"? With pmc's,
only .Sub is supported I think. But for more complex types, the best I
can think of is being able to freeze a pmc and store it into the const
table, such
I've committed it as of r11820. Since it parses by tokens, braces
inside of strings are allowed.
With regard to clashing, pir specials take precedent over macros. The
complications that could arise from accidental recursion, etc, seems
complex. As for your .local example, you can always use
On Mar 6, 2006, at 5:31 PM, Allison Randal wrote:
On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
* opcode vs function / method
open P0, "data.txt", ">"
print P0, "sample data\n"
Using opcodes for all the IO has some disadvantages:
a) namespace pollution: all opcodes
1 - 100 of 163 matches
Mail list logo
