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
th
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
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
runtime/parr
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 HLL
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 y
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 exte
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 in
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
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
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.
Re
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
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?"
>
> Per
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
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
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 actua
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 meth
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 conventio
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 assumpt
On Thu, 2008-09-18 at 07:34 -0500, Patrick R. Michaud wrote:
> > "Aggregating coroutine" and "aggregating yield" aren't nearly as zippy
> > as 'gather' and 'take', but they're more meaningful to a broader
> > audience, which may help the feature spread.
I don't buy this. The Perl 6 terms are
On Thu, 2008-09-18 at 10:28 -0700, jerry gay wrote:
> On Thu, Sep 18, 2008 at 10:21 AM, Patrick R. Michaud <[EMAIL PROTECTED]>
> wrote:
> > On Thu, Sep 18, 2008 at 09:06:44AM -0700, jerry gay wrote:
> >> what some refer to as "traits", perl 6 calls "roles".
The Perl 6 name is a better, more natur
On Wed, 2008-09-24 at 18:09 -0500, Patrick R. Michaud wrote:
> On Thu, Sep 25, 2008 at 12:10:35AM +0200, Reini Urban wrote:
> > 2008/9/24 Patrick R. Michaud <[EMAIL PROTECTED]>:
> > > So, in order to get the behavior you're describing from the interactive
> > > prompt, we'll probably need more than
Tom Christiansen:
> > Don't we have to solve all this to get the Perl 6 debugger
> > working anyway?
>
> Although I'm unsure why that might be, I also recognize the possibility
> that there may well exist hypothetical documents, unread by me, which
> mandate some scenario or behavior wherein the
On Fri, 2008-10-03 at 08:55 -0700, Will Coleda wrote:
> Index: Makefile.PL
> ===
> -BEGIN { require 5.008 }
> +BEGIN { require 5.8.6 }
> Index: Configure.pl
> ===
> -use
On Fri, 2008-12-05 at 09:10 -0600, Andy Lester wrote:
> On Dec 5, 2008, at 4:13 AM, Simon Cozens wrote:
>
> > I just ran this code, which worked with the expected results:
>
>
> Beautiful. Posted to Perlbuzz.
>
> http://perlbuzz.com/2008/12/database-access-in-perl-6-is-coming-along-nicely.html
On Fri, 2008-12-05 at 13:13 -0600, Andy Lester wrote:
> On Dec 5, 2008, at 1:11 PM, Geoffrey Broadwell wrote:
> > I can't, because as Perlbuzz oh-so-helpfully tells me when I try to
> > submit my comment: "Registration is required." With no indication how
> >
On Tue, 2008-12-23 at 17:31 -0800, Will Coleda via RT wrote:
> chromatic mentioned on #parrot that if we remove PIC, we're going to break
> all the
> predereferenced runcores. After some discussion, this probably means ripping
> out:
>
> 16:42 <@chromatic> Everything other than the default core
On Sun, 2009-01-11 at 12:39 -0500, Andrew Whitworth wrote:
> This is something that obviously needs to be avoided. PASM doesn't
> require that P42 be the 42nd register in an array. It only requires
> that values put into P42 aren't overwritten and the register isn't
> repurposed later. The simplest
On Mon, 2009-01-12 at 07:01 -0800, Ovid wrote:
> - Original Message
>
>
> > > > I could optionally make the following work:
> > > >
> > > > $string.trim(:leading<0>);
> > > > $string.trim(:trailing<0>);
>
> Alternatively, those could be ltrim() and rtrim(). If you need to
> dynamica
> > Could you change to simply bounce with a
> > message:
> >
> > --
> > Please submit reports to Parrot using the web interface:
> >
> > https://trac.parrot.org/parrot/newticket
> >
> > Thanks,
> > The Parrot Team
> > --
> >
> > Thanks!
> > Allison
Out of curiosity, why don't we allow
On Mon, 2009-11-23 at 14:00 +, Parrot Bug Summary wrote:
> Parrot Bug Summary
>
> http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Now that we've emptied RT, can we shut this off?
-'f
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 probabl
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 both
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 farthe
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 t
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 do
On Tue, 2008-02-12 at 21:36 -0500, Bob Rogers wrote:
> From: chromatic <[EMAIL PROTECTED]>
>Date: Tue, 12 Feb 2008 17:03:31 -0800
>
>On Tuesday 12 February 2008 16:55:06 Geoffrey Broadwell wrote:
>
>> Feh. Please someone tell me there is a ligh
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 b
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
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 po
>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
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 suggest
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
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 concept
On Tue, 2008-04-01 at 16:19 -0700, [EMAIL PROTECTED] wrote:
> +The Unicode Standard defines a I (commonly simplified to
> just
> +I) 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:
http://rt.perl.org/rt3//
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. Th
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. N
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, EXEC
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&#
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
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
> Parrot::Configure::Options:
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 be
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)
> gen:
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.
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, willin
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_all"ed if the library can't be loaded at
> runtime, like pgsql has, n
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 C:
> +Conversion will be done with a funct
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
> config
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 C<
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 =~ /
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.)
> >
>
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 * C
> +
> +Libraries to be added where no OS-specific or OS/C-compiler-specific
> libraries
> +are
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 Pa
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 arr
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 o
least I'm 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 Tick
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 n
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 minima
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&#x
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
- Miscellaneo
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 (the
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
'/path/to/dir1
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 do
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.
> >
> > tetr
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 late
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
>
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/Inclu
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
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
> (@{ $self->{pote
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 []
config/gen/call_li
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, a
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.
> # http://rt.perl.org/rt3/Ticket/Display.html?id=55238 >
>
>
> ./parrot -o runtime/p
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
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
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
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
1 - 100 of 113 matches
Mail list logo
