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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=49668
Test file t/op/jit.t
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) =
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
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
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]
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
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
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
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=47313
The description for
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 testing against the exec
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)
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46927
The attached patch
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
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,
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 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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=46389
In
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 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 of
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
-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
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
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.
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
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 magic
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45437
in r21240, ptc added a
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:
print
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.
# URL:
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:
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=45309
This patch implements the sign function for I, N, BigInt and Complex
numbers.
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 would you ever get
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 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
#
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44995
Hi everyone,
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44811
Test 91 fails at this PASM
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
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 =~
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.
# URL: http://rt.perl.org/rt3/Ticket
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=44291
Hi all,
Attached is
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.
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=43145
In config/auto/jit.pm
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:
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
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
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42975
One of the tests in
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
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
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
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 Isom
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.
# URL:
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 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
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
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
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 +
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 failures occur
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.
# URL:
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
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,
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
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 part
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)
*
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
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 about features
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42293
These two scripts perform
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 line of all future correspondence
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
On Mar 29, 2007, at 10:14 PM, Will Coleda wrote:
On Mar 27, 2007, at 4:45 PM, Allison Randal wrote:
particlebut, 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
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 checking things in that fail coding standards?
because
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=42082
Ongoing refactoring of
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
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
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id
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.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id
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 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
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 configure
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
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
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
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:
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,
(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, Mar 21, 2006 at 06:42:42AM -0800
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
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
I finally got around to writing up a patch to parrot that would allow
the features I mentioned a while back. There aren't any heuristics,
just braces. The first file is a patch to imcc.l and imclexer.c(may as
well). The second file is a set of macro's I've already written up(not
documented
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 are
On Mar 5, 2006, at 1:46 PM, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
Should the network opcodes even be loaded as standard? Csocket et al
aren't
actually that useful on Perl 5 without all the constants in the Socket
module,
so in practical terms
1 - 100 of 153 matches
Mail list logo
