#parrot Parrot 0.6.1 "Bird of Paradise" Released | parrotcode.org
Set by moderator on 17 April 2008.
Infinoid I had to do exactly that for src/nci_test.c, recently 00:01
C++ hurts my brain. 00:02
nopaste "tetragon" at 216.126.67.44 pasted "C++ patch to readline.in" (18 lines) at nopaste.snit.ch/12731 00:04
tetragon You can try that, it works on my box 00:05
dalek r27051 | jkeenan++ | trunk: 00:06
: Add file to test auto::opengl internal subs where verbose output has been
: requested.
diff: www.parrotvm.org/svn/parrot/revision?rev=27051
Infinoid Determining if your platform supports readline.........................yes. 00:07
nice.
tetragon That doesn't necessarily mean that stuff that uses it will build, but it gets past the test 00:08
Infinoid finds out
dalek r27052 | jkeenan++ | trunk: 00:09
: Update MANIFEST to reflect recently added test files.
diff: www.parrotvm.org/svn/parrot/revision?rev=27052
00:12 liona29 joined
kid51 I think this address is suspect: d033.dhcp212-198-248.noos.fr . I've seen 3 'people' sign on and off from that address in just the past few hours. 00:23
paula35 camgirl29 liona29 all using that address 00:24
00:24 guru joined
Infinoid I noticed that too 00:25
kid51 We now have a record number of Torontonians on channel ;-) 00:27
Infinoid yesterday: [05:08] -!- lola22 [~lola22@d033.dhcp212-198-248.noos.fr] has joined #parrot 00:28
very likely a spambot
kid51 Can we/should we do anything about it? 00:35
How about we add it to the Ban List? 00:36
This is the one that I banned: *!*@d033.dhcp212-198-248.noos.fr 00:39
dalek r27053 | jkeenan++ | trunk: 00:45
: Correct number of tests in plan.
diff: www.parrotvm.org/svn/parrot/revision?rev=27053
01:31 tetragon joined
Infinoid tetragon: it didn't link, libparrot.so ends up wanting mangled versions of readline() and add_history() 02:10
thanks for the patch tho, I think its a step in the right direction
if I do the same thing to the prototypes in parrotio.pmc, it builds. 02:12
02:16 guru joined 02:19 Andy joined 02:55 contingencyplan_ joined 03:00 japhb joined
dalek r27054 | infinoid++ | pdd13pbc: 03:16
: Create dummy PackfileRawSegment and PackfileConstantTable PMC classes,
: with stub methods as defined by PDD13.
diff: www.parrotvm.org/svn/parrot/revision?rev=27054
Infinoid jonathan: soo... in PDD13's ConstantTable definition, what's a "key", and how is that distinct from a PMC?
jonathan: and while we're at it, are constants named/labeled somehow? or are they referred to by other means? 03:17
03:18 Psyche^ joined
japhb Platform portability question -- to be sanely portable, my OpenGL bindings probably need to be able to parse the system GL/GLU/GLUT/GLX headers. But these can be in a number of different places depending on platform and local administration. So after a successful detection during Configure (using a C test file that does #include <GL/glut.h>, for instance), how do I find out the full path to the headers that were detected, so that I can p 03:19
arse them?
Infinoid hi japhb (Mark Glines here) 03:20
japhb Infinoid: Hi there!
purl Hi there! is, like, there a smart way to use inheritance of a db in dbic
japhb Trying to deal with your ticket.
Infinoid purl, forget Hi there!
purl Infinoid: I forgot hi there
japhb :-)
Infinoid I don't know of a way. two ideas come to mind, but they both have problems:
japhb tetragon: are you around? 03:21
Infinoid 1. create a test.c that just does #include <GL/glut.h>, run "gcc $CFLAGS -E" on that and parse the output (make gcc handle the search path stuff for you)
or 2. figure out a list of paths from CFLAGS yourself, and find the right one with a loop
the other part of the problem, of course, is figuring out whether it should be GL/glut.h or GLUT/glut.h or what 03:22
japhb Infinoid: I thought of 2, but it was blown out of the water by the comment in the ticket about '-framework GLUT' flags, which I wouldn't know what to do with (unless they are guaranteed to be in a fixed location on all OS X versions)
Infinoid I think that's a linker option, not a preprocessor option. I could be wrong about that. 03:23
tetragon japhb: Yes
Infinoid it sounds like OSX likes to figure out which libraries to pull in at runtime, so you don't have to specify -lglut -lGLU -lGL on the liner line 03:24
s/liner/linker/
tetragon I'm actually working on getting it to go on OS X
Infinoid tetragon++
japhb Infinoid: I think, but I'm not sure, that every platform *other* than OS X keeps the GLUT headers in <GL/...>, like Dog intended.
Infinoid japhb: amazingly, someone got your configure patch working on MingW32, too. So now that win32 is involved, all bets are off.
japhb tetragon: THANK YOU. I'm pretty much having to cargo cult from other places.
Infinoid: rockin'. That's cool. 03:25
tetragon japhb: Apple gcc is a bit different to GNU gcc. The -framework flag is part of the difference 03:26
japhb tetragon: are you just fixing auto::opengl, or are you working on gen::opengl as well?
tetragon I'm working on gen
Its output is where my system is blowing up on right now 03:27
japhb tetragon: Ah, good. Because I was planning on working on Phase 2 tonight, which is merging in the code I've been working on to parse the function prototypes. (The gen::opengl you have only parses the #defines and creates the GLUT callback library.) 03:28
tetragon (really shouldn't be using make -j2 right now, really causes fun make output, bleh)
Infinoid heh
japhb And to do Phase 2 portably, I need to know where I can grab all those headers.
tetragon And I have to repoint it to the correct header locations (i.e., not /usr/include)
Infinoid japhb: I think it's gonna have to be a couple of nested for-loops...
tetragon And I don't have freeglut 03:29
japhb tetragon: yep. That hardcoded directory I was expecting to change to whatever Parrot's official "where are the headers" technique -- only as discussed above, there doesn't appear to actually be one. :-/
Infinoid: right.
Infinoid this is one area where parrot can't be as self-sufficient as we would like 03:30
japhb tetragon: I *thought* I had it set up correctly to fall back all the way to GLUT 1 if need be, but it's possible I screwed something up, since I clearly don't have a GLUT < GLUT 4 (freeglut/OpenGLUT) to test with.
tetragon My system is GLUT 5
japhb ?!?
Infinoid hmm 03:31
tetragon 5 adds glutGetProcAddress
japhb mumbles something incoherent about vendors messing with perfectly good version numbering
03:32 AndyA joined
Infinoid msg kid51 Does the config system have a mechanism for enumerating the (platform-specific) multitude of include-directories, to see which one contains a header needed for the opengl stuff? 03:32
purl Message for kid51 stored.
tetragon You can always override the version number and have that function ignored
japhb tetragon: freeglut has glutGetProcAddress, and advertises as GLUT 4.
tetragon According to the glut header I'm looking at, that's glut 5 03:33
japhb tetragon: still, I was careful to use >=, rather than ==, for this very reason.
tetragon: can you put that header somewhere, or nopaste it or somesuch, so I can grab it and look?
Infinoid: thx for sending kid51 that message, I wouldn't have known who to ask. 03:34
Infinoid kid51++ # he's been busily adding tests for the extra config components added by your patch
japhb kid51: local testing maniac? I thought chromatic held that banner .... 03:35
nopaste "tetragon" at 69.196.138.185 pasted "glut.h" (636 lines) at nopaste.snit.ch/12733
Infinoid I think he was unhappy that his Devel::Cover score dropped below 100%
japhb LOL
Infinoid hey, whatever motivates ya...
japhb no kidding
japhb looking at tetragon's paste 03:36
Infinoid I like the header prefix changes, conditional in #if defined(__APPLE__) || defined(MACOSX) 03:38
japhb Infinoid: yeah, like I said, I think only OS X messes up those locations. Just to make sure that there really isn't perfect portabilty or anything. Sigh. 03:39
Infinoid I just worry about whether apple is the only one who decided to split ogl/glut headers into separate, nonstandard paths
japhb It's possible OS/2 did that as well. Do we officially care? 03:40
tetragon I think NeXT has similar splits
Infinoid I promise to care as soon as the first whiny user bugs us about it 03:41
japhb Infinoid: fair enough
tetragon Got it to link
Which set of tests are the OpenGL ones? 03:42
Infinoid I don't think the testsuite runs any opengl. there's an examples/opengl/ script tho
japhb Infinoid: that would be correct. I'm having enough trouble carving out time to write the binding itself, and have a working example or two. Full tests are probably going to have to fall on someone else's shoulders. 03:43
tetragon Doesn't work yet
Infinoid japhb: well, full tests are tough anyway, they'll have to be skipped whenever opengl isn't built or isn't available 03:44
(people ssh'ing into a linux box can't run it because they don't have a $DISPLAY variable, for instance)
japhb tetragon: do you know if there is an online place containing docs for the GLUT that comes with OS X?
Infinoid: well, assuming they aren't doing X forwarding. I generally am, since I admin all the boxes I ever ssh to, and therefore have no reason not to trust them. 03:45
Infinoid: but yes, pedantry aside, I understand your point.
tetragon japhb: Check under here: developer.apple.com/referencelibrar...ml#doclist
shorten tetragon's url is at xrl.us/bjkg9
Infinoid anyway, how do you do unit tests for opengl?
you'd need pattern recognition to see whether it really looks like a triangle 03:46
japhb Infinoid: <cheap shot>Judging by vendor drivers, I'd say they don't do them</cheap shot>
Seriously though, I was thinking about that,
tetragon So, my parrot instance is linked against GLUT and OpenGL, but parrot can't find it 03:47
Infinoid I don't know that it matters. as long as the function calls are getting through unchanged, any problems there are the vendor's fault, not yours.
maybe link to a dummy library to make sure the calls are getting through with the right arguments?
japhb and decided that probably you could make some tests that would only fail if the user's GL drivers were completely insane, in which case that might be validly called a justified fail.
Infinoid tetragon: does it need an LD_LIBRARY_PATH sort of hack?
tetragon Infinoid: Doubtful. GLUT and OpenGL are already standard frameworks and linked against 03:48
Infinoid what's the error message?
purl the error message is supposed to be blort
Infinoid purl, forget the error message
purl Infinoid: I forgot error message
japhb Infinoid: that kind of inserted library is actually pretty standard ... it's how OpenGL debuggers and network renderers work
nopaste "tetragon" at 69.196.138.185 pasted "parrot error loading GL" (20 lines) at nopaste.snit.ch/12734 03:49
Infinoid japhb: yeah, I've done it before, and I need to do it again. (Fuse.pm needs it badly.)
still a lot of work tho :)
japhb gacks at the mixture of directory conventions seen in tetragon's latest paste 03:50
tetragon hehe
japhb Infinoid: true.
Infinoid that message 'Could not find a suitable GL shared library' isn't coming from parrot, I don't think
tetragon It's what you get when you mash Mac OS with Unix with NeXT
japhb tetragon: nodnod
Infinoid I think maybe it's coming from some stub library OS X provided, which can't find the real thing at runtime
japhb Infinoid: that's coming from my code
Infinoid oh. I grepped and didn't find it 03:51
my mistake :)
japhb So, when I started trying to design for something resembling portability,
I wrote this little PIR routine that would take a list of different names that a dynamic library might be known as,
try to load each one in sequence until it either ran out of possibilities, or succeeded.
tetragon Not expecting anything like OpenGL or GLUT 03:52
japhb So, we just need to add the name of the dylib that OS X uses to that list
Infinoid all headerfile issues aside, what's your library named?
tetragon Which part? It's OpenGL or GLUT
They're even quad-architecture binaries 03:53
japhb So right now, the code only knows GL => libGL, GLU => libGLU, and GLUT => libglut (plus libglutcb, but we build that ourselves, so know the name a priori)
tetragon And my system has 'OpenGL' and 'GLUT'
Infinoid OpenGL.dylib? 03:54
tetragon No .dylib
Just OpenGL and just GLUT
japhb tetragon: so just push 'OpenGL' and 'GLUT' onto the lists found at OpenGL.pir: 52-76
Each place you see "push libnames, 'foo'" add another push underneath 03:55
(You'll need to make again to get the .pbc generated, so the new code will get loaded by the OpenGL example. of course.) 03:56
second to last period there should be a comma (I'm not quite that rude) 03:57
Tene I just made a post on my use.perl journal about my presentation at Penguicon. It's not showing up on my journal page yet though. 04:04
japhb Tene: link? 04:05
Hmmm, I wonder if we lost tetragon
tetragon I'm still here 04:06
Tene ah, here we go: use.perl.org/~tene/journal/36200
tetragon Build was taking a while
japhb tetragon: ah, OK, good
(good to have you still here, I mean)
Tene: thx
tetragon Same error, different line numbers
I may have missed a spot 04:07
japhb nopaste?
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or rafb.net/paste or paste.husk.org/ or poundperl.pastebin.com/ or paste.scsys.co.uk/ or don't bother me while I'm eating
tetragon I'll be back shortly. Relocating my laptop
Infinoid Tene: awesome!
purl awesome is probably www.youtube.com/watch?v=Gi2CfuqcUGE
Infinoid purl: I doubt it.
purl Infinoid: i'm not following you...
Tene I guess that might be appropriate for planet.parrotcode.org?
japhb Tene: seems so 04:08
Infinoid purl, forget awesome
purl Infinoid: I forgot awesome
japhb Tene: most self-deprecating use.perl journal post I've seen in a while. I'm used to the use.perl journalers being ... "self confident" shall we say. 04:09
Tene self-deprecating?
Huh, I guess I can understand how you could see that.
japhb Mmmm, lacey's ... it doesn't get much better than this. 04:10
japhb is easy to please ... just supply dark chocolate in copious quantities.
Tene Ahh, mostly talking about negatives. I mainly put that post up there in hopes that people from the presentation looking for more information would have a greater chance of finding it. 04:12
PerlJam Tene: what do you think of github?
04:12 tetragon joined
tetragon Hrm, I wonder if it's searching for .dylib? 04:14
Infinoid its possible 04:15
config/init/hints/darwin.pm:34: share_ext => '.dylib',
tetragon I can do GL and GLU with dylib 04:16
but not GLUT
04:19 peepsalot joined
japhb tetragon: Meaning, OpenGL.pir is successfully loading GL and GLU but not GLUT on your system, or there is no .dylib for GLUT on your system? 04:19
tetragon It's still having problems with GL
japhb bah ram ewe
tetragon And parrot is linked against OpenGL and GLUT 04:20
japhb ok, paste your OpenGL.pir, please, let me cogitate for a minute 04:21
Infinoid is libGLU important?
Tene PerlJam: it's' quite nice
tetragon Infinoid: It's part of the OpenGL framework 04:22
nopaste "tetragon" at 216.126.67.44 pasted "OpenGL.pir" (313 lines) at nopaste.snit.ch/12735 04:23
Infinoid if you say so. I don't even know what it *does*. :)
japhb Infinoid: GLU makes it so you don't have to handle all the raw math yourself for a number of different operations that are conceptually simple but annoying to implement over and over.
Some people never use it, which is why it's not part of core GL itself. 04:24
Infinoid hmm, ok
japhb Bob Free, the current maintainer of POGL (Perl5 OpenGL binding) recently found out there was a years-old brown paper bug in the GLU binding, because nobody had used that particular functionality before this year. 04:25
Infinoid nice. 04:26
will loadlib fail if the same library has already been loaded?
if it just says "oh, the library is already loaded" and silently succeeds, looking at the way tetragon's library lists are set up, I think it might never get around to loading GLUT 04:27
japhb tetragon: Well, one thing is that you don't need to add "OpenGL" and "GLUT" in every one of those places. The "OpenGL" belongs only in the first block, the "GLUT" only in the third.
tetragon But it's failing on the first load
japhb In fact, it's wrong to. "GLUT" is not a fallback for core GL, for instance.
tetragon: OK, so on Mac OS X, are the dynamic libs for OpenGL stored inside the framework directory? 04:28
tetragon All of OpenGL is in the framework 04:30
I'm reading some docs on the organisation of OpenGL on OS X right now
japhb Odd, I just ssh'ed to a Mac OS X box, and did a locate, and I see "/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib" 04:31
So in theory, the original 'libGL' should have worked
fu. bar.
OK, let's get silly. Try pushing 'libGL.dylib' to libnames. 04:32
Infinoid ok, this dreamy music is getting to me. japhb++ tetragon++ goodnight all
tetragon Same error 04:33
japhb: What's in runtime/parrot/dynext on your (non-OSX) system? 04:36
Because that's where loadlib looks
04:37 arbingersys joined
japhb sorry, was AFK for cat with upset stomach 04:40
looking ...
ah, well, haven't run make in a while, so it's empty
right, rebuilding
tetragon Heh, changing to libglutcb gets me to a different error, further in. It loads from there.
04:40 Psyche^ joined
tetragon I'm now getting an error from NCI 04:41
japhb well, libglutcb is generated by gen::opengl, and it just wraps the GLUT callbacks to work around deficiencies in Parrot's NCI model.
How do you find out the dynamic link directory path on OS X? 04:43
I mean, just at the command line
I'm wondering if the OpenGL framework directories are even being seen by whatever is the ld.so equivalent.
tetragon It's in with the base frameworks. It gets found even if you don't link against it 04:44
japhb tetragon: grr, so why can't parrot find it? 04:45
japhb wonders if it's something broken with the 'loadlib' op implementation in Parrot ....
tetragon Because that's not what parrot is looking for
From what I see, loadlib doesn't look for system libraries. 04:46
japhb tetragon: explain, please, I'm confused
It clearly does on linux. (search system libs)
Oh wait!
I wonder if you have to do that loading a null lib trick that you do to get libc on linux because the OpenGL was linked in? 04:47
tetragon ?
japhb Accessing the running Parrot binary as if it was a dynamic library ... 04:48
Something I saw a long time ago while perusing the Parrot docs.
Lemme see if I can find it
PerlJam yeah, you loadlib the empty string I think 04:49
04:49 arbingersys left
japhb tetragon: can you try that? Adding the empty string to libnames for GL? 04:49
tetragon Failed 04:51
Same old error
japhb Hmmm, docs/compiler_faq.pod seems to indicate you have to use a "null" string.
(look near 'loadlib' in that doc)
And the other thing to try is the full pathname to libGL.dylib on your system. 04:53
According to the docs, loadlib should fallback from its magic searches to actually believing the pathname you give it, and trying to literally load that file as a dylib.
tetragon Using a null library doesn't work 04:54
japhb tetragon++ # helping to get this mess figured out 04:55
tetragon Full paths to the linked against objects (which lack extensions) work 04:57
I'm seeing a spinning triangle now
japhb YAY!
Man that sucked
OK, now we need to iterate back to sanity.
tetragon At least those paths should be constant across OS X
japhb tetragon: Hmmm. This OS X box shows at least 3 dirs, but I don't know if some of those are just installers or backup copies or some such: 04:58
tetragon What are they?
purl they are intermingled and intertwingled
tetragon How accurate 04:59
japhb Hold on, copying:
/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
/Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
tetragon With this, I only touched /System/Library/Frameworks/OpenGL.framework/OpenGL
japhb no ".../Versions/A/Libraries/..." even? 05:00
tetragon I didn't play with the SDKs (which let you target different versions) or the individual dylibs
GLUT doesn't even have individual dylibs
japhb tetragon: can you paste your latest working version?
tetragon Framework builds can be quite different to conventional Unix libraries 05:01
japhb tetragon: so I'm gathering ...
nopaste "tetragon" at 216.126.67.44 pasted "OpenGL.pir that works on OS X" (311 lines) at nopaste.snit.ch/12736 05:02
tetragon You are in a maze of twisty little libraries, all alike
japhb OK, that's something we can work with at least.
tetragon Now to see about splitting out the rest of my changes and see if it builds from scratch 05:03
japhb OK, about to paste a change to that routine, let's see if a little cleanup still works ... 05:04
tetragon It'll take a while to build... I've just realcleaned it 05:05
05:05 Davemon joined
nopaste "japhb" at 76.191.190.8 pasted "Cleanup of OpenGL.pir library lists -- does this work?" (28 lines) at nopaste.snit.ch/12737 05:05
japhb tetragon: ah
I just cleaned the libnames lists a bit, want to know if it works with that simplified. 05:06
Infinoid said that someone had gotten the mingwin build to configure the OpenGL stuff ... I wonder if they actually got it to run the example ...? 05:07
tetragon Can't say or test. I don't have that platform 05:09
japhb nodnod
The only Win32 box I have around here is Win2K, had a nearly full hard drive, and hasn't even been booted in a couple years, so that's likely a bust. 05:10
tetragon Hrm... I'm getting a few compiler warnings from the generated glut_callbacks.c 05:11
japhb grumbles about how ridiculously slow RT is about sending mail
paste again?
tetragon It won't be in the most readable form, as I'm using -j2 05:12
japhb It was warning free on my box, but then linux/i386 is ridiculously forgiving
oh
japhb always had a deep seated mistrust of parallel makes on pre-production code
tetragon But they're nested extern declarations and implicits of the same functions
japhb erm. Hmmm. odd. 05:13
Oh, wait, I've got a guess.
hold on a sec
I'm a moron. 05:14
tetragon glutMouseWheelFunc and glutMenuDestroyFunc
japhb This is probably the problem: #include <GL/freeglut.h>
tetragon Before I took care of that, it wouldn't build at all 05:15
japhb nodnod
I meant ... when I wrote the callbacks generator, I was focused on how freeglut sees the world.
I didn't realize that (annoyingly) the OS X GLUT would claim different things belonged in API version 4. 05:16
tetragon I see glutDestroyMenu in my headers
japhb different function. That's just a normal call, not a callback registration.
OK, let me compare things here. 05:17
Did you get a chance to check if my simplified libnames lists worked for you? 05:19
tetragon The build still hasn't finished
And it just has
Works 05:20
Now I'm waiting on svn diff to churn through my changes
Taking too long 05:21
I'll just grab the files
japhb ... OK, looks like up through GLUT 3, callback lists are identical. Now working through GLUT 4/5 mess ... 05:22
nopaste "tetragon" at 216.126.67.44 pasted "config/auto/opengl/opengl.in" (25 lines) at nopaste.snit.ch/12738 05:23
"tetragon" at 216.126.67.44 pasted "config/auto/opengl.pm" (132 lines) at nopaste.snit.ch/12739 05:24
"tetragon" at 216.126.67.44 pasted "config/gen/opengl.pm" (499 lines) at nopaste.snit.ch/12740
tetragon And you already have OpenGL.pir 05:25
japhb bak 05:29
tetragon: why #ifdef __APPLE_CC__? Shouldn't that be dependent on a more generic define? Or is that to differentiate from fink/macports? 05:30
tetragon gcc produced a list of predefined macros, and __APPLE_CC__ seemed to be the most specific 05:32
japhb fair enough. 05:33
Do you have commit rights?
tetragon I'm not familiar with the fink/darwinports conventions
japhb (Because I don't)
tetragon And I don't have commit
japhb sigh
hmmm 05:34
Can you create a diff and attach it to the ticket? 05:36
Then I can work with that, and someone with commitbit might commit your work in the mean time.
japhb longs for the PUGS world of "free commitbits for everyone"
tetragon It'll take a while. Laptop hardware and I need to pull out a couple of other patches from the output 05:38
japhb nodnod 05:39
tetragon It's been added to #53086 05:43
japhb k, thx 05:45
avar japhb: make parrot switch to git too:) 05:49
japhb avar: heh 05:50

Powered by Cro and the Raku® Programming Language.

Please report any issues / comments / feature requests as an issue on App::Raku::Log.

Thank you!