;Grafman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, March 26, 2008 3:44 PM
Subject: Re: Extending Parrot NCI callback functionality Options
On Wed, 2008-03-26 at 09:31 -0700, Grafman wrote:
He lives! Just kidding, I know you'v
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
As far as I understand OpenGL, it's got one current context per
thread, and libGL does all sorts of evil things with threads and
thread-local storage to make it all work transparently. An
object-oriented OpenGL interface seems like the right way to go,
though, for all sorts of other reasons.
Arcad
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
> I'm not even sure *that* will work. To invoke a Sub PMC from C, you
> need to pass in an Interp as well as the PMC. Unless you know both
> of those at compile time, I'm not sure how to make the callback
> mechanism work.
>
> ... although I just had an evil idea regarding memcpy and a hash table
chromatic wrote:
On Friday 18 January 2008 20:25:16 Allison Randal wrote:
It's true that the generalized solution for varying callback signatures
doesn't exist yet, but it's easy enough to create your own C callback
layer, with a separate C function for each callback you need. (Note, not
one-pe
On Jan 16, 2008, at 7:39 PM, Geoffrey Broadwell wrote:
I am starting to implement a GLUT and OpenGL binding for Parrot. GLUT
is extremely callback-oriented.
Unfortunately, none of the GLUT callbacks fall within the current
limitations on Parrot NCI callbacks.
As you've discovered, callbacks
On Friday 18 January 2008 20:25:16 Allison Randal wrote:
> It's true that the generalized solution for varying callback signatures
> doesn't exist yet, but it's easy enough to create your own C callback
> layer, with a separate C function for each callback you need. (Note, not
> one-per-signature,
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
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 have some now. If this is
going to be blocked indefinitely, my
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
> I am starting to implement a GLUT and OpenGL binding for Parrot. GLUT
> is extremely callback-oriented. You essentially can't do anything
> beyond open the top-level window until callbacks are functional. You
> can't even draw in that window -- the rendered image never actually
> appears, and
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
13 matches
Mail list logo
