On Mon, 2008-01-07 at 11:51 -0800, chromatic via RT wrote:
On Monday 07 January 2008 08:18:24 Geoffrey Broadwell wrote:
It seems like this should be available from interpinfo in PIR ... and
since 'parrot -v' displays optimization information, it should probably
display the runcore chosen
Right now, Parrot's support for NCI callbacks (C code calling back into
PIR code) is relatively limited. In particular, there are at least the
following limitations:
1. The return type must be void (C library does not expect a response).
2. The callback must have exactly two arguments (from
On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot.
I started down this path several months ago. The following is the thread on
the topic.
http://tinyurl.com/3crzpu
OK, read it now. I think I got a little farther, but
On Sat, 2008-01-19 at 17:25 +1300, Allison Randal wrote:
Geoffrey Broadwell wrote:
On Wed, 2008-01-16 at 22:38 -0700, Paul Seamons wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot.
[...]
I don't often get concentrated time
to help out with Parrot and Perl 6, but I
On Sat, 2008-01-19 at 16:12 -0600, Patrick R. Michaud wrote:
On Fri, Jan 18, 2008 at 09:41:01PM -0800, Geoffrey Broadwell wrote:
Null PMC access in invoke(); misspelled sub name in function call?
I fear this error message may actually send a beginner down a false
trail. This particular
On Tue, 2008-02-12 at 12:46 -0500, Bob Rogers wrote:
From: Andrew Parker [EMAIL PROTECTED]
Date: Tue, 12 Feb 2008 15:17:03 +0100
Thanks for the pointer, Bob. I read through it and it might be
tangentially related to this. That problem is about scopes being
modeled by subs
On Wed, 2008-02-13 at 14:21 +, [EMAIL PROTECTED] wrote:
On a more rational note, has any thought been given to what good enough
performance for release will be?
Should we perhaps add a performance benchmark to the tests?
Normalising it to account for hardware variations might be a
On Tue, 2008-03-11 at 23:01 +0100, Ron Blaschke wrote:
Andy Lester wrote:
On Mar 11, 2008, at 2:43 PM, Ron Blaschke wrote:
It ties pointers to INTVALs, which I guess it shouldn't.
As I read the mail, it seems like the only problem we have is in casting
the pointer to an int
From the point of view of someone working through the PCT tutorial
(quite rockin', BTW!):
On Wed, 2008-03-26 at 14:25 +0100, Klaas-Jan Stol wrote:
having used NQP a bit, I feel like I'm missing a few things. I'm not
entirely sure what the fate of NQP is; will it always be a bootstrap
stage for
On Wed, 2008-03-26 at 09:31 -0700, Grafman wrote:
He lives! Just kidding, I know you've had actual paid work going
on. :-)
Hi chromatic - as you know, I took over the Perl OpenGL project over a
year ago - you had mentioned that I might consider doing a port to
Parrot; Geoffrey had suggested
On Wed, 2008-03-26 at 16:27 -0700, Bob Free wrote:
Cool - great to hear from you - sorry that it's been a while since I've
posted an update!
Real life can be so darned intrusive ;-)
It'd be great to have you participate - you've done quite a lot for POGL.
Regarding your work/ideas on
Imagine my delight upon reading this in the Perl 6 Design Team minutes:
* also had a contact from someone who wants to port OpenGL to Parrot
* not Geoff Broadwell
* seems like a very serious approach
Ouch! You wound me, sir!
Just for the record, I've attached my OpenGL/GLUT proof of
On Tue, 2008-04-01 at 16:19 -0700, [EMAIL PROTECTED] wrote:
+The Unicode Standard defines a Igrapheme cluster (commonly simplified to
just
+Igraheme) as one or more characters forming a visible whole when displayed,
Typo ---^
-'f
On Wed, 2008-04-02 at 14:16 -0700, [EMAIL PROTECTED] wrote:
=head3 Directives used for Parrot calling conventions.
+{{ A bit of a radical idea, but now would be the time to decide on this:
+ Remove the whole long-style invocation syntax altogether.
+ Only allow the short version.
+
On Sun, 2008-04-13 at 14:35 -0700, chromatic wrote:
As well, the optimizations I recommend for Parrot (if you want to use
optimization flags) are:
-O2, to choose the fastest available runcore
Not so, unless this has been fixed without resolving the RT bug:
On Wed, 2008-04-16 at 00:10 +0200, Leopold Toetsch wrote:
Am Freitag, 11. April 2008 21:02 schrieb Nuno 'smash' Carvalho:
Greetings all,
I just posted a little Parrot benchmark in my use.perl's journal
Just a reminder:
Please don't use unoptimzed builds for benchmarking. There are a
On Wed, 2008-04-16 at 09:47 +0100, Tim Bunce wrote:
I agree with Geoffrey that optimized builds should be the default.
Thank you!
Developers working on parrot (wanting unoptimized/debug quick builds)
would just need to set an env var in their .profile, for example, and
carry on as now. No
I've been working on parsing the function prototypes in the
GL/GLU/GLUT/GLX headers, in preparation for generating bindings for all
of them during the Parrot build.
Currently my prototype parser is able to compute NCI signatures for all
but 14 out of the 1835 total prototypes found in my system's
On Thu, 2008-04-17 at 05:49 -0700, Mark Glines via RT wrote:
It looks like this is a parsing bug, caused by some weird stuff in one
of my header files. The top of my /usr/include/GL/gl_mangle.h looks
like this:
#if 0
#define GL_MANGLE_C1 DO NOT EDIT!!! - TO REGENERATE from gl.h, EXECUTE
On Thu, 2008-04-17 at 15:35 -0400, Andy Dougherty wrote:
If optimized builds are to be the default, however, someone needs to
either hunt down and fix all the wrong attribute_null decorations, or
apply a patch similar in spirit to the one I proposed in
[PATCH] Re: [perl #50684] String
On Thu, 2008-04-17 at 08:33 -0700, Mark Glines via RT wrote:
On Thu, 17 Apr 2008 08:16:23 -0700
Geoffrey Broadwell [EMAIL PROTECTED] wrote:
3. Parse the define *values*, and toss any that don't look right.
I'm thinking #3, since it's probably best to have that safety check
anyway
On Fri, 2008-04-18 at 06:26 -0700, Andy Dougherty via RT wrote:
+my $these_tests = $steps_tests{$temp[0]}{$temp[1]}
+or croak No tests exist for configure step $step;
Thank you. That's definitely an improvement. I know I wasted a lot
of time trying to figure out what the
On Fri, 2008-04-18 at 05:10 -0700, James Keenan via RT wrote:
I'll consider this patch, but, as all the other code in this module has
corresponding unit tests, we'll have to write a test for it. It should
go in whatever t/configure/*.t file holds other tests for
OK, I've done some more research on differences between various GLUT
libraries; please try the attached patch rather than the one from tentra
(mine includes his with a couple changes and several additions).
-'f
=== config/auto/opengl/opengl.in
On Sun, 2008-04-20 at 06:27 -0700, James Keenan via RT wrote:
1. I tried your patch out. It did not apply cleanly at first, so I had
to do a little editing. I am attaching an 'svn diff' that represents
the changes actually made.
Yep, that was because someone else had committed a change
On Sun, 2008-04-20 at 19:01 -0700, James Keenan wrote:
auto::gettext (r26100 | particle | 2008-02-27)
auto::crypto (r26359 | fperrad | 2008-03-14)
auto::glibc (r26946 | particle | 2008-04-12)
auto::opengl (r27022 | infinoid | 2008-04-18)
gen::opengl (r27022 | infinoid | 2008-04-18)
On Sun, 2008-04-20 at 19:28 -0700, James Keenan via RT wrote:
As to the question of whether people know how to write tests: I think
there is empirical evidence that people know how to write tests for the
configuration steps. For example, when François earlier submitted
config/auto/crypto.pm,
On Mon, 2008-04-21 at 17:06 -0700, James Keenan via RT wrote:
I'm mostly in agreement. It just seems to me that the configuration
ought to be settling down as we near 1.0.
Absolutely. However, as of 0.6.1 we are at the stage where outsiders
like myself can finally meaningfully contribute --
On Mon, 2008-04-21 at 17:02 -0700, Mark Glines wrote:
1. It seemed more relevant than some stuff that's already in
parrot. (I have more machines with OpenGL installed than have
postgresql, for example.)
Ditto, but of course, I'm biased. :-)
2. The author (Geoff) was responsive, willing
On Tue, 2008-04-22 at 12:18 -0700, Mark Glines wrote:
Ok. So if the OpenGL and crypto code didn't have to generate custom C
files, they wouldn't have to have all the extra infrastructure, right?
Just a test that gets skip_alled if the library can't be loaded at
runtime, like pgsql has, no
I found several things that either seemed wrong or confusing here.
Forgive me if they are explained elsewhere or I missed something
obvious
On Tue, 2008-04-22 at 10:56 -0700, [EMAIL PROTECTED] wrote:
-Conversion will be done with a function called Cstring_grapheme_copy:
+Conversion will
On Wed, 2008-04-23 at 18:40 -0700, James Keenan wrote:
There are five configuration step classes where the class's runstep()
method has an internal subroutine called _handle_mswin32(). These
classes are:
config/auto//crypto.pm
config/auto//gettext.pm
config/auto//gmp.pm
On Thu, 2008-04-24 at 19:55 -0700, James Keenan via RT wrote:
Please see patch attached. It turned out that config/auto/opengl.pm
didn't quite conform to the pattern, so I left it unchanged.
Other than having a Darwin case, how is it different than the pattern?
Also, the implementation of
On Thu, 2008-04-24 at 21:53 -0700, Mark Glines wrote:
On Thu, 24 Apr 2008 20:48:34 -0700
Geoffrey Broadwell [EMAIL PROTECTED] wrote:
my $platform = $os =~ /mswin32/i $cc =~ /^gcc/i ? 'win32_gcc' :
$os =~ /mswin32/i ? 'win32_other
On Fri, 2008-04-25 at 03:45 -0700, James Keenan via RT wrote:
Other than having a Darwin case, how is it different than the pattern?
The Darwin case is the difference.
Ah.
my $platform = $os =~ /mswin32/i $cc =~ /^gcc/i ? 'win32_gcc' :
$os =~ /mswin32/i
On Fri, 2008-04-25 at 09:39 -0700, jerry gay wrote:
On Fri, Apr 25, 2008 at 8:38 AM, Geoffrey Broadwell [EMAIL PROTECTED] wrote:
(Subtle note -- the || really wants to be //, but as I recall we're not
allowed to assume that // is there yet.)
correct, parrot depends on perl 5.8, so we
On Sat, 2008-04-26 at 09:25 -0700, James Keenan via RT wrote:
Please review revised patch attached. Geoff, does this work for you?
Jerry, okay on Win32?
Generally, yes. One tiny nit:
+=item * Cdefault
+
+Libraries to be added where no OS-specific or OS/C-compiler-specific
libraries
On Mon, 2008-04-28 at 00:30 -0700, chromatic wrote:
I'm somewhat unconvinced, in general. For the OpenGL bindings, where the
build process has to build specific C code which links against specific
libraries, I can mostly see the point. For other bindings where it's
possible to build
On Mon, 2008-04-28 at 08:44 -0700, Geoffrey Broadwell wrote:
I'm not wedded to splitting them up as much as I did. In fact, I'd be
fine with core.in, opengl.in, and misc.in. Better for you?
chromatic confirmed on IRC that this was his preference, saying also
that this arrangement solves
On Wed, 2008-05-07 at 18:22 -0700, James Keenan via RT wrote:
On Sun Apr 20 19:01:44 2008, [EMAIL PROTECTED] wrote:
I would like to propose both short-term and long-term remedies.
Short-term: If you are proposing a new configuration step, or doing
a significant overhaul of any
really trying to. Consider this my
complaint: This is a suboptimal way to treat people who want to donate
their time and energy to this project, and it slows down project
progress to boot.
-'f
On Tue, 2008-05-06 at 22:22 -0700, Geoffrey Broadwell wrote:
# New Ticket Created by Geoffrey
On Wed, 2008-05-14 at 07:50 -0700, Will Coleda via RT wrote:
Nifty!
Minor nits:
- can we use _ instead of - in the filename?
- can we make the error message more graceful if the disassemble
executable hasn't been built?
- it's not always going to be called disassemble - you'll need to
On Wed, 2008-05-14 at 10:40 -0700, Will Coleda via RT wrote:
Excellent. I was about to ask if we could have someone windows test to
make sure this works for them...
Sure ... but I don't know who to ask. I'm hoping you do.
and it would be a lot easier if we
had a test (even a very minimal
On Wed, 2008-05-14 at 11:03 -0700, Geoffrey Broadwell wrote:
On Wed, 2008-05-14 at 10:40 -0700, Will Coleda via RT wrote:
Excellent. I was about to ask if we could have someone windows test to
make sure this works for them...
The previous version of the patch didn't work on Windows, because
I said:
The attached short PIR program shows the problem -- parrot segfaults on
the first shift operation when iterating over a namespace.
It turns out that the namespace was a red herring. The real problem is
that when iterating over a hash, you cannot assign to a PMC register; it
must be a
On Fri, 2008-05-16 at 22:05 -0700, chromatic wrote:
Parrot 0.6.2 is on schedule for the 20 May release. In preparation, please
gather up any NEWS you find important for your subsystem
- Configuration
+ add step auto::opengl
+ add step gen::opengl
+ add step gen::call_list
-
On Sat, 2008-05-17 at 00:17 -0700, Geoffrey Broadwell wrote:
On Fri, 2008-05-16 at 22:05 -0700, chromatic wrote:
and please run make fulltest on every architecture you can find.
Running on Debian-testing/i386 (SVK) and Debian-testing/amd64 (git-svn)
overnight (they're common I know
I am considering adding PIR translations (and possibly other language
translations) of the OpenGL Programming Guide (Red Book) sample code
to examples/opengl/ in the Parrot repository. The original C version of
this code is under the seemingly free license at the bottom of this
message. What do
Thanks to tetragon++, I've now got OpenGL header parsing (mostly)
working on both Debian Linux/i386 and Mac OS X 10.5. Now I need headers
for Windows to continue the porting work.
For each of MSVC, MinGW, and cygwin, I need:
1. Path globs [1] for all OpenGL headers, in the form
On Sun, 2008-05-25 at 18:23 +0200, Ron Blaschke wrote:
Hi Geoffrey,
Hi there!
[snip *lots* of great detail]
Excellent, thank you! I will incorporate this into my next patch set,
and then another go around of compatibility testing with Mac OS X and
Linux. This next patch is going to be a
On Mon, 2008-05-26 at 21:41 -0700, Will Coleda via RT wrote:
On Mon, May 26, 2008 at 10:08 PM, Geoffrey Broadwell
[EMAIL PROTECTED] wrote:
On Mon, 2008-05-26 at 18:25 -0700, Geoffrey Broadwell wrote:
Please give this version a try.
tetragon++ has reported success on Mac OS X. Now we
On Tue, 2008-05-27 at 21:16 +0200, Ron Blaschke wrote:
[Answers to all my questions]
Forgot to mention, I sent in a new patch a few hours ago incorporating
all of the OpenGL Win32/MSVC portability fixes to RT 54868:
http://rt.perl.org/rt3/Ticket/Display.html?id=54868
Can you give that
On Wed, 2008-05-28 at 20:39 +0200, Ron Blaschke wrote:
I've applied the patch against a clean r27888 and got:
Generating runtime/parrot/includedone.
Generating OpenGL bindings...
step gen::opengl died during execution: 'GLOBAL_LOGGER_NAME' is defined
as
On Wed, 2008-05-28 at 21:30 +0200, Ron Blaschke wrote:
Geoffrey Broadwell wrote:
I guess you are right. I have changed it as you suggested. Now
Configure says:
Generating OpenGL bindings...In OpenGL header 'C:/Program
Files/Microsoft SDKs/Windows/v6.1/Include/gl/GLU.h', prototype
On Wed, 2008-05-28 at 22:54 +0200, Ron Blaschke wrote:
Geoffrey Broadwell wrote:
OK, I know what's causing this (no typemap entry for 'wchar_t*', as the
error indicates). Not sure about best NCI type type to match this to --
it really wants to be a native Parrot string with encoding UCS2
On Thu, 2008-05-29 at 09:41 -0700, NotFound wrote:
+# Dirty way of checking if compiling with c++
+ my $nocpp = index($conf-data-get('cc'), '++') 0;
+
-$self-set_result(set for gcc);
+ if ($nocpp) {
+for my $maybe_warning
(@{
The most recent version of the patch got sent to the wrong mail alias;
I've reattached it below.
-'f
diff --git a/MANIFEST b/MANIFEST
index b0e3c9d..43c4f52 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -296,7 +296,6 @@ config/auto/warnings/test_c.in []
On Fri, 2008-05-30 at 15:01 -0700, Geoffrey Broadwell wrote:
The most recent version of the patch got sent to the wrong mail alias;
I've reattached it below.
... And now regenerated, because I've broken out and committed one of
the fixes included in the previous version, at the request
On Tue, 2008-06-03 at 08:33 -0700, Will Coleda wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #55238]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=55238
./parrot -o
On Mon, 2008-06-02 at 20:28 -0700, chromatic via RT wrote:
On Monday 02 June 2008 20:05:22 Bob Rogers wrote:
Agreed, but doesn't this info really belong in README? Then DEVELOPING
really only needs the middle paragraph, which is unchanging, and there
would be one less file to have to
On Thu, 2008-06-05 at 02:54 -0700, Stephane Payrard via RT wrote:
On Wed Jun 04 21:40:56 2008, japhb wrote:
cognominal apparently has an absolutely insane collection of GL headers
on his system. I've made a number of portability fixes in response;
hopefully the attached patch should fix
On Thu, 2008-06-05 at 12:16 +0200, Jonathan Worthington wrote:
chromatic wrote:
On Wednesday 04 June 2008 11:28:58 Geoffrey Broadwell wrote:
The op '$P0 = iter $P1' doesn't work if $P1 is a ResizableStringArray.
I haven't tested, but I suspect the same may be true of the some other
On Thu, 2008-06-05 at 17:36 -0700, Ivan B. Serezhkin via RT wrote:
Hello.
Hi there!
FreeBSD users are humans too, with two arms and two legs =)
Of course! I just haven't been able to find a Parrot/FreeBSD/OpenGL
person previously. Standard request: please send me a tarball of all
of your
On Thu, 2008-06-05 at 08:57 -0700, Geoffrey Broadwell wrote:
On Thu, 2008-06-05 at 02:54 -0700, Stephane Payrard via RT wrote:
Anyway the fix is not yet perfect. The Configure.PL still dies :
Use of uninitialized value in hash element at config/gen/opengl.pm line 490.
step gen::opengl
I've incorporated all of your fixes, plus some fixes for cognominal, in
the latest patch attached to RT #55228. Please give that a try.
-'f
This is on a Gentoo linux amd64 machine, with Parrot trunk r28204, and an
unstable (git) version of mesa built from the x11 overlay.
Is this normal?
Nope, not normal.
Try the attached patch. It's an update of the patch in #55228; I'll
update that RT in a moment.
-'f
diff --git
On Fri, 2008-06-13 at 18:35 +0100, Nuno 'smash' Carvalho wrote:
Parrot next release is on schedule for next Tuesday, June 17th. Unless
any showstopping bugs are reported in the next few days. In
preparation, please update NEWS with the latest hackings, also report
any PLATFORMS updates.
As
On Mon, 2008-06-16 at 23:17 -0500, Packy Anderson wrote:
Of course, I'm still doing perl Configure.pl --without-opengl, but
I don't know if that's a problem with hints file or with the GLUT
implementation...
That would be for me to look at Join #parrot (irc.perl.org) and
ping japhb,
On Mon, 2008-06-16 at 20:01 -0700, Will Coleda via RT wrote:
On Sat Aug 19 14:30:53 2006, chip wrote:
Runtime errors seem to be off by one these days. Anybody play with line
numbering recently?
Note that this bug (or a similar one) affects line numbers of
disassembly (I assume because the
On Tue, 2008-06-17 at 11:27 -0700, Packy Anderson wrote:
Here's the command I'm using to configure and make
$ make realclean; CC=gcc-4.0 CX=g++-4.0 perl Configure.pl --
cc=$CC --cxx=$CX --link=$CX --ld=$CX --optimize; make -j 2
That's a pretty advanced build method. OK, let's sanity check:
On Wed, 2008-06-18 at 09:06 -0700, chromatic wrote:
On Tuesday 17 June 2008 21:06:58 Geoffrey Broadwell wrote:
Index: src/dynext.c
===
--- src/dynext.c(revision 28459)
+++ src/dynext.c(working copy
On Tue, 2008-07-01 at 11:46 -0700, chromatic wrote:
if (nextinterp-code-base.data
|| next = (interp-code-base.data + interp-code-base.size))
Oh, that's just pretty. I've long been in the habit of laying out
whitespace for multiple if tests like this:
if ( next
Please consider putting the change summary in the very first line of the
commit message, rather than just the subsystem ID. For example, prefer
this:
[foobar] Fix compile under VoodooCC
* Frobnicated the whosit
* Defenestrated the whatsit
* Sacrificed a chicken under a full blue
First, thank you for working on this!
Now some comments ...
On Thu, 2008-07-03 at 19:07 +0200, Reini Urban wrote:
parrot-languages is my compressed version of the fedora split,
they have for every single language a seperate package.
Thank you for choosing the single-package route here.
I
On Sat, 2008-07-05 at 20:11 -0700, Andrew Johnson wrote:
Parrot_quicksort() is in src/utils.c; the first do-while loop has nothing to
stop it when j reaches 0, so it keeps going outside of the data array. I
guess that the while condition needs j 0 adding to it to prevent that from
happening.
On Mon, 2008-07-07 at 17:21 +0200, Reini Urban wrote:
Donald Hunter via RT schrieb:
I think you must be linking against the X11 libGLU and libGL, where I am
linking against the w32 native libraries.
So we have to use some detection heuristic to seperate the X11 case
(such as
On Wed, 2008-07-16 at 10:04 -0700, Reini Urban wrote:
Remove
/usr/runtime/parrot/include
/usr/runtime/parrot
/usr
paths from the .include searchpath.
+1 for not adding these to the searchpath by default.
(We shouldn't do something messed up like adding them in one place, and
then
On Thu, 2008-07-17 at 22:50 +0200, Reini Urban wrote:
The problem I had with the w32api libs was -lglut32. with linking
directly to the dll /usr/bin/glut32.dll everything works fine, and I'll
get rid of freeglut as default.
I'm not sure I understand what you meant here.
Now I only have to
I've noticed several patches from you today in which you're adding code
to try to load an existing library under additional library names for
cygwin support. It's beginning to look like this is a common operation.
I needed this for the OpenGL bindings, so I wrote a utility routine in
I noticed a couple commits overnight for Lua to support OpenGL. I'm a
bit confused by them, since they don't seem to actually *do* anything,
just lots of (hopefully automatically generated!) scaffolding.
fperrad: How do these bindings actually work?
Everyone:
We're getting to the stage that
On Mon, 2008-07-21 at 09:34 +0200, François Perrad wrote:
Geoffrey Broadwell a écrit :
fperrad: How do these bindings actually work?
There'll work with runtime/parrot/library/OpenGL.pir.
OK ... so what could be improved about runtime/parrot/library/OpenGL.pir
so that you didn't have to write
On Tue, 2008-07-22 at 09:03 +0200, François Perrad wrote:
Ok, talking about libraries :
Lua compiler Lua Standard Libraries are complete (as far as the
current Parrot supports it).
So, since April 2008, I wrote some extension libraries for Lua
Since mid-June 2008, I tried to write extension
On Tue, 2008-07-22 at 15:37 -0700, chromatic wrote:
The wiki page at:
http://www.perlfoundation.org/parrot/index.cgi?inter_hll_mapping_notes
seems to be missing the rationale for *why* it's necessary to map types
between languages? (Also see If Perl 6 has to care about the internal
On Tue, 2008-07-22 at 22:58 -0400, Bob Rogers wrote:
So I would argue that (1) what seem like differences in numbers in
the various languages are really differences in the way those languages
define their numeric operators, not in the numbers themselves;
I disagree. How do you represent
On Wed, 2008-07-23 at 10:11 -0400, Bob Rogers wrote:
True. But passing a Complex to any language that does not have a
concept of Complex is going to cause problems if the language tries to
treat it as anything but a black box. And a black box doesn't require a
special representation.
But we
On Wed, 2008-07-23 at 17:09 +0200, François Perrad wrote:
From a couple comments you make later, it sounds like you're aiming to
be perfectly API compatible with the original library implementations
for Lua and PHP, so that moving to Parrot is a drop-in replacement as
far as the user's
On Fri, 2008-07-25 at 13:40 +0200, Peter Gibbs wrote:
+HUGEINTVAL num;
Does this really need to be a HUGEINTVAL? Why is INTVAL not sufficient?
-'f
On Fri, 2008-07-25 at 22:18 +0200, Peter Gibbs wrote:
typedef HUGEINTVAL(*sprintf_getint_t) (PARROT_INTERP,INTVAL,
SPRINTF_OBJ *);
So, since obj-getint returns a HUGEINTVAL, I gave it one to store the
result in.
Fair enough, that's good enough for me.
As to why sprintf_obj is
On Sun, 2008-07-27 at 13:13 +0200, Reini Urban wrote:
+stat $I0, conf_file, 0
+if $I0 goto conf
+
+# If installed into /usr/lib/parrot, not /usr/runtime/parrot
+# This logic has to be reversed when installed versions should
run faster
+# than source builds.
Reverse
On Sun, 2008-07-27 at 12:10 -0700, Will Coleda via RT wrote:
On Sun, Jul 27, 2008 at 1:08 PM, via RT Geoffrey Broadwell
[EMAIL PROTECTED] wrote:
# New Ticket Created by Geoffrey Broadwell
# Please include the string: [perl #57344]
# in the subject line of all future correspondence about
I'll reply to the rest of this (if someone doesn't beat me to it)
tomorrow, but just wanted to comment on your closing comment:
On Sun, 2008-07-27 at 22:25 -0700, jerry gay wrote:
that's an install tree
policy, and as far as i'm concerned, it hasn't been addressed yet
(along with many other
On Tue, 2008-08-05 at 13:20 -0400, Will Coleda wrote:
On Tue, Aug 5, 2008 at 1:10 PM, chromatic [EMAIL PROTECTED] wrote:
Gah, no maintenance releases please! See Mommy, why did it take over five
years to release a new stable version of Perl 5 with a bugfix I made in
2002?
Perhaps I used
On Tue, 2008-08-05 at 11:19 -0400, Jesse Vincent wrote:
[branch feature]
This sounds very useful. Is the SVK paradigm changing so that online
use is assumed, and offline is a mode to switch to temporarily? I'm
used to thinking of SVK in one two ways:
1. As a better SVN client for normal
On Tue, 2008-08-05 at 12:54 -0700, chromatic wrote:
On Tuesday 05 August 2008 12:35:50 Geoffrey Broadwell wrote:
bugfixes that should be backported to one or more already released
versions and re-released immediately.
I can see patching the previous release in case of a critical bugfix
On Tue, 2008-08-05 at 16:19 -0400, Michael Peters wrote:
We also need to think about deprecation cycles. If you deprecate a
feature in 1 version and then it disappears in the next then the time
between when my code works and when it doesn't is only 6 months. Some
distros provide support for
On Fri, 2008-08-15 at 07:00 -0700, Will Coleda wrote:
#not ok 1 - Line length ok
# Failed test 'Line length ok'
# at t/codingstd/linelength.t line 80.
# Lines longer than coding standard limit (100 columns) in 1 files:
# /home/smoke/parrot/compilers/pirc/new/pirsymbol.c:256: 104 cols
#
On Fri, 2008-08-15 at 11:57 -0400, Will Coleda wrote:
This causes -all- smolder reports to be marked as failures.
Perhaps 'make codetest' or 'make codingstd_tests' should be an automated
commit hurdle? Meaning, SVN won't allow the commit if those don't pass.
Assuming we actually want
On Mon, 2008-08-18 at 17:44 -0400, Michael Peters wrote:
Allison Randal wrote:
It's true that you can't get a Python array and expect it to respond to
all the same method calls as a Tcl array. But that Python array is just
another variable type, that accepts keyed access and method
On Wed, 2008-08-20 at 22:20 +0200, Ron Blaschke wrote:
I think we need a way to select the calling convention for a function,
similar to, or maybe even part of, the signature. Also, it would be
good to have a way to select a calling convention when loading a
library, as a calling convention
On Thu, 2008-08-28 at 00:03 -0700, Allison Randal wrote:
Briefly discussed on the phone with Patrick, Jerry, and chromatic: The
versions of the math opcodes that modify an existing destination PMC
instead of creating a new destination PMC are not useful to HLLs,
because they make
1 - 100 of 112 matches
Mail list logo
