% darbelo has joined #parrot
% AndyA has left AndyA!~andy@82.152.157.85
% slightlyoff_ has joined #parrot
% slightlyoff_ has left slightlyoff_!~slightlyo@204.14.154.209
% slightlyoff has left slightlyoff!~slightlyo@204.14.154.209
% markus_ has joined #parrot
% anna30 has joined #parrot
% markus has left markus!~markus@91-113-24-45.adsl.highway.telekom.at
% anna30 has left anna30!~anna30@d033.dhcp212-198-248.noos.fr
% IllvilJa has joined #parrot
% markus_ is now known as markus
% wknight8111 has joined #parrot
<dalek> r27030 | jonathan++ | trunk:
<dalek> : [rakudo] Make .= really work properly when used in declarations, and add an optimization so we don't emit a type check when doing an assignment to a variable we can statically determine is untyped.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27030
% darbelo has left #parrot
% barney has joined #parrot
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% cognominal has left cognominal!~cognomina@82.67.232.89
% ruoso has joined #parrot
<rotty> barney: did you get an answer from fperrad?
<barney> rotty: yes, I think I forwarded it to you
<rotty> i
% cotto_work has left cotto_work!~cotto@tide533.microsoft.com
% cotto_work has joined #parrot
* rotty checks his mbox
<barney> Donnerstag, 21:33
% iblechbot has joined #parrot
% davidfetter has joined #parrot
% lola22 has joined #parrot
% lola22 has left lola22!~lola22@d033.dhcp212-198-248.noos.fr
% kid51 has joined #parrot
% rdice has joined #parrot
% wknight8111 has joined #parrot
% liona29 has joined #parrot
% liona29 has left liona29!~liona29@d033.dhcp212-198-248.noos.fr
<dalek> r27031 | bernhard++ | trunk:
<dalek> : Let P::T::Harness honor the 'files' import-option,
<dalek> : when there is no '--files' commandline option.
<dalek> : Add a harness for compilers/nqp/bootstrap.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27031
<dalek> r27032 | bernhard++ | trunk:
<dalek> : Let SVN ignore generated files in runtime/parrot/library/NCI/
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27032
% davidfetter has left davidfetter!~chatzilla@start.fetter.org
* barney broke Eclectus testing in r27031
% jq has left jq!~jquelin@merlin.mongueurs.net
<dalek> r27033 | bernhard++ | trunk:
<dalek> : [Eclectus]
<dalek> : Remove Eclectus from unified languages testing,
<dalek> : make 'cd eclectus && make test' work again.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27033
<Infinoid> is VTABLE_get_string constable?  (is it free of side effects?)
<barney> I can imagine that there are side effects, like for Random PMC
<Infinoid> nice example, but that still doesn't modify the PMC
% askie has left askie!~askie@81.171.100.208
% jq has joined #parrot
<Infinoid> know of any pmcs which do local caching of stringification, or something like that?
<barney> I've never seen that, but IMHO it should be possible
<Infinoid> you're right.  and that means nothing that calls VTABLE_get_string should be constable
<barney> If you put it that way, it sounds bad
<Infinoid> I've consted isa(), get_class(), and I'm working on name() and type()
<Infinoid> but I'm not really sure this is the right approach, because some of those call get_string()
<dalek> r27034 | bernhard++ | trunk:
<dalek> : [Eclectus]
<dalek> : Use 'case' in order to switch between implementations.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27034
% askie has joined #parrot
% tetragon has left tetragon!~seneca@gw-312-705.somanetworks.com
<barney> Sounds like a design issue.
% tetragon has joined #parrot
% jq has left jq!~jquelin@merlin.mongueurs.net
% jq has joined #parrot
<dalek> r27035 | fperrad++ | trunk:
<dalek> : [opengl]
<dalek> : - fix openGL config on MinGW32
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27035
% tetragon has left tetragon!~seneca@216.126.67.44
% jq has left jq!~jquelin@merlin.mongueurs.net
% jq has joined #parrot
% barney has left barney!~bernhard@p549A2A35.dip0.t-ipconnect.de
% bpphillips-1 has joined #parrot
% bpphillips-1 has left bpphillips-1!417121a2@67.207.141.120
% tetragon has joined #parrot
<dalek> r27036 | jkeenan++ | trunk:
<dalek> : Refactor preparatory code found in lib/Parrot/Configure/Options/Test.pm into
<dalek> : lib/Parrot/Configure/Options/Test/Prepare.pm.  carp instead of dying silently
<dalek> : when config step class lacks corresponding test files (incorporating Geoffrey
<dalek> : Broadwell's patch in http://rt.perl.org/rt3/Ticket/Display.html?id=53034).
<dalek> : Make changes needed in Configure.pl, t/configure/025-options_test.t and
<dalek> : t/configure/026-options_test.t.  Add t/configure/049-options_test.t to test
<dalek> : previously untested branches and regexes.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27036
<dalek> r27037 | jkeenan++ | trunk:
<dalek> : Correct name of newly added test file.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27037
<Infinoid> any lua experts around?
<Infinoid> how does one tell string_from_cstring() whether or not to free() the cstring when garbage collection occurs?
% lichtkind has joined #parrot
<nopaste> "Infinoid" at 75.31.89.233 pasted "Remove a hack from LUA that was causing lots of crashes and failing tests. Won't the GC take care of this?" (15 lines) at http://nopaste.snit.ch/12725
<dalek> r27038 | infinoid++ | trunk:
<dalek> : [Lua] Checking pointers for 8 digits of hex only works on 32 bit platforms. 
<dalek> : Adjust regexes to get 3 such tests passing on linux/amd64.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27038
% cognominal has joined #parrot
% AndyA has joined #parrot
% kid51 is now known as kid51_afk
<cognominal>  jonathan++
% lichtkind has left lichtkind!~chatzilla@d90-134-44-26.cust.tele2.de
% Theory has joined #parrot
% markus_ has joined #parrot
% IllvilJa has left IllvilJa!~jilves@ua-83-227-215-229.cust.bredbandsbolaget.se
% markus has left markus!~markus@91-113-23-20.adsl.highway.telekom.at
% Theory has left Theory!~Theory@c-24-21-175-208.hsd1.or.comcast.net
<Infinoid> (note for the logs: my above nopaste has been posted to RT as #53072.)
<cognominal> bots shoud give a link for RT nodes :(
<tetragon> Is there any preferred way to temporarily set a cflag, with the duration being a single configure test?
<Infinoid> cognominal: wknight8111 has a bot that does exactly that, and I've written a botnix module that we can plug into dalek to do it too
<nopaste> "Infinoid" at 75.31.89.233 pasted "plugin for dalek: modules/local/rtlink.pm" (24 lines) at http://nopaste.snit.ch/12727
<cognominal> does anyone know how one can access vtable method attributes like :const ?
<cognominal> dalek is written in perl 5 or use parrot?
<Infinoid> dalek is written in perl 5.
<cognominal> yea, i see your paste
<Infinoid> cognominal: access :const from where?
<cognominal> in pir,  suppose I get the pmc of the said method...
% particl1 has left particl1!~particle@c-24-19-3-148.hsd1.wa.comcast.net
<Infinoid> hmm.  I don't know if pmc2c stores that stuff for later introspection
<cognominal> well, I don't have a use for it rigt now.  Also I suppose there is a perl way from the perl5 toolchain
<cognominal> I suppose it will be useful from the interpretor to run a restricted parrot for security reason
<Infinoid> the code within pmc2c can use it, yes
<Infinoid> there's really 2 :const attributes I added in http://www.parrotvm.org/svn/parrot/revision?rev=27028 - one for vtable.tbl and one for methods within .pmc files
<cognominal> I have seen your patches so it made me think.
<Infinoid> ok
% particle has joined #parrot
<Infinoid> interesting thought regarding the security
<cognominal> I thought that was one of the reason to get this flags on the first place so the necesity of introspection
<Infinoid> my motivation was just fixing some gcc warnings that turn into errors when you use g++
<cognominal> but I did not find anything, not that I searched hard.
% kid51_afk is now known as kid51
<cognominal> I hate bureaucracy but I noted that rt is also a tool of social engineering, A ticket that is immediately dismissed by the one in charge of the code , get the users to bark. But yes, he is right. I need that. And eventually, if no one side with me, I now I am probably wrong
<cognominal> "but yes he is right"   # that should have been quoted
% markus_ has left markus_!~markus@91-113-28-184.adsl.highway.telekom.at
<Infinoid> Andy Bach's email sig cracks me up.  "The bureaucracy is expanding to meet the needs of an expanding bureaucracy."
<Infinoid> cognominal: hmm.  did we ever get anywhere with that compilers/imcc/imcc.l stuff?  I would have tried to fix it, but I am clueless about flex and REJECT :(
<cognominal> ho, I should get back to that. The REJECT was only to factorie the error message. That was silly because it complicated the test stuff
<cognominal> One put the error message instead of the REJECT and that is done.
<cognominal> And you suppress some of your test correction because they are not need anymore.
<cognominal> Do you need a patch?
<Infinoid> please, thanks
<cognominal> ok
<Infinoid> cognominal++
<cognominal> sorry for the botched job
<cognominal> Infinoid, do you have the RT number?
<Infinoid> oh...
<Infinoid> #52858
<cognominal> thx
<tetragon> kid51: I got the readline configure step to fail gracefully on my darwin box when it could only find editline.  Unfortunately, it's not in the most elegant of states
<dalek> r27039 | jkeenan++ | trunk:
<dalek> : Add tests to cover previously untested methods, branches or circumstances.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27039
<kid51> Can you paste a patch?
<kid51> Or post it to the RT ticket we have open on that?
<tetragon> I was wondering if there is an elegant way to set a temporary flag
<kid51> The flags, IMHO, are rather messy now.  So I suspect 'temporary' flags would not be the way to go -- but this is not my area of expertise.
<tetragon> Right now I grab the old set, save it, tack on my temporary ones and restore after the build
<kid51> Why don't you post that in the ticket.  That grab/save/append/restore mechanism may be helpful in other places.
<dalek> r27040 | chromatic++ | trunk:
<dalek> : [include] Added Parrot_unCOW_string macro to perform copy-on-impending-write in
<dalek> : place and, most importantly, return the STRING pointer.  This allows the use of
<dalek> : the macro in assignments, instead of calling Parrot_unmake_COW() directly.
<dalek> : The name of this macro could be better, and it might go in a better header, but
<dalek> : this will work for now.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27040
<tetragon> I've attached it to #52212
<tetragon> The reason the modified flags are 'libs' is so that I know it comes after the previously set "-undefined dynamic_lookup"
<kid51> I have to go now, but I will look at it later today or tomorrow.
% kid51 has left kid51!~jkeen@pool-70-107-15-140.ny325.east.verizon.net
<dalek> r27041 | chromatic++ | trunk:
<dalek> : [Rakudo] Fixed Perl6Str increment/decrement to respect STRING copy on write.
<dalek> : (Reported by PerlJam; confirmed by Infinoid).
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27041
% paula35 has joined #parrot
% IllvilJa has joined #parrot
% paula35 has left paula35!~paula35@d033.dhcp212-198-248.noos.fr
<nopaste> "cognominal" at 82.67.232.89 pasted "#52858: "$" vars in PASM don't work, but aren't disallowed either" (67 lines) at http://nopaste.snit.ch/12728
<cognominal> Infinoid. my corrected patch
% mj41 has joined #parrot
% jan has left jan!~chatzilla@90-229-128-103-no52.tbcn.telia.com
% jan has joined #parrot
<dalek> r27042 | infinoid++ | trunk:
<dalek> : [Lua] Remove some conditional freeing of non-freeable resources; let the GC
<dalek> : sort it out.  This fixes lots of lua tests, and resolves RT#53072.
<dalek> : chromatic++ for the review.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27042
<Infinoid> cognominal: thanks, trying it now
<cognominal> don't forget to run flex
<Infinoid> do I need to give it any arguments?  "flex compilers/imcc/imcc.l" doesn't seem to do anything.
<Infinoid> oh, -d -o
<Infinoid> (testing now)
% markus has joined #parrot
<Infinoid> removed hard tabs, trying again...
<cognominal> arf, I though I had emacs configured against hard tabs  :(
<cognominal> sorry
<Infinoid> no big deal, this is what codingstd tests are for :)
% Limbic_Region has joined #parrot
<dalek> r27043 | infinoid++ | trunk:
<dalek> : [IMCC] Disallow "$" vars in PASM mode.
<dalek> : This resolves RT #52858.  rgrjr++ reported it, cognominal++ fixed it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27043
<cognominal> Infinoid++ comitted it :)
<Infinoid> eh, committing is easy.  thanks for fixing it!
% peeps has joined #parrot
<cotto_home> is the schedule for the pre-YAPC::NA hackathon known?
% peeps has left peeps!~peeps@cpe-67-9-161-48.austin.res.rr.com
% liona29 has joined #parrot
% liona29 has left liona29!~liona29@d033.dhcp212-198-248.noos.fr
% DarkWolf84 has joined #parrot
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
% ambs has joined #parrot
<ambs> HI, folks
<ambs> who is playing with OpenGL?
% markus has left markus!~markus@91-113-28-184.adsl.highway.telekom.at
% iblechbot has left iblechbot!~iblechbot@ppp-62-216-196-45.dynamic.mnet-online.de
% Limbic_Region has joined #parrot
% particl1 has joined #parrot
% particle has left particle!~particle@c-24-19-3-148.hsd1.mn.comcast.net
<ambs> hmms
<ambs> Infinoid, you the openGL guy? :)
<Infinoid> I checked it in, and tested it on linux/amd64
<Infinoid> but the patch came from Geoffrey Broadwell <geoff@broadwell.org>
<ambs> well, I'm submitting bug reports
<Infinoid> great!  how badly does it break?
<ambs> somebody will look into them :D
<ambs> detection, for now
<ambs> nothing too bad
<Infinoid> ok, thanks
<Infinoid> ah, you're right, I see that error outside of X too
% diakopter has left diakopter!~diakopter@209.9.237.164
% diakopter has joined #parrot
<ambs> Infinoid, it is not critical, but it would be nice to solve :)
% kid51 has joined #parrot
<Infinoid> ambs: yeah.  I'm just staring at http://www.parrotvm.org/svn/parrot/revision?rev=27035
<Infinoid> seems not everyone needs a $DISPLAY variable
<ambs> (loading)
<Infinoid> so if we can figure out a way to detect those who do, we can check and barf early, or do a link-only test, or something
<ambs> let me see what is compiled and run
<ambs> glutInit...
<ambs>  glutInit will initialize the GLUT library and negotiate a session with the window system. During this process,  glutInit may cause the termination of the GLUT program with an error message to the user if GLUT cannot be properly initialized. Examples of this situation include the failure to connect to the window system, the lack of window system support for OpenGL, and invalid command line options.
<ambs> glutInit
<Infinoid> ok.  well, we can check for the existence of glutInit without actually calling it... maybe just check non-NULLness of its pointer
<ambs> yes
<ambs> or chose anoter function to test
<ambs> :)
<nopaste> "Infinoid" at 75.31.89.233 pasted "Patch to detect OpenGL successfully even without X" (16 lines) at http://nopaste.snit.ch/12729
<Infinoid> well, I haven't ever done any opengl programming, but glutInit() sounds sufficiently important to me :)
<ambs> testing
<ambs> yes, that I agree :-P
<ambs> Determining if your platform supports OpenGL...................yes, GLUT 4.
<ambs> now let me make 
<ambs> and make test
<purl> More like "make fail"
<Infinoid> thanks, purl
<ambs> it seems to be all working.
<Infinoid> I don't think anything opengl-related runs as part of the test suite.  there's an examples/opengl/ that I hand-tested with
<ambs> yeah, but that one fails open display, and that failure is normal and expected :D
<ambs> Infinoid, I think you can apply the patch and close the ticket ;)
<Infinoid> thanks, I will as soon as this test completes momentarily
<ambs> ;)
<ambs> I need to get out. See you tomorrow :)
% ambs has left ambs!~ambs@255.92.54.77.rev.vodafone.pt
<dalek> r27044 | infinoid++ | trunk:
<dalek> : [config] The OpenGL configuration test called glutInit(), which requires 
<dalek> : a $DISPLAY environment variable (on X-based platforms, at least.)  Fix 
<dalek> : things to do a link-only test, which works fine without X running.  
<dalek> : This fixes #53084; ambs++ for reporting it.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27044
% camgirl29 has joined #parrot
% paula35 has joined #parrot
% paula35 has left paula35!~paula35@d033.dhcp212-198-248.noos.fr
% camgirl29 has left camgirl29!~camgirl29@d033.dhcp212-198-248.noos.fr
<dalek> r27045 | infinoid++ | pdd13pbc:
<dalek> : Create a dummy packfile.pmc with stub methods as specified in PDD13.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27045
<Infinoid> 10 commits in less than 24 hours.  \o/
% iblechbot has joined #parrot
% iblechbot has left iblechbot!~iblechbot@212.4-dial.augustakom.net
<dalek> r27046 | infinoid++ | pdd13pbc:
<dalek> : Create dummy FackfileSegment (abstract) and PackfileDirectory (container)
<dalek> : classes, with stub methods as defined by PDD13.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27046
% tetragon has left tetragon!~seneca@69-196-138-185.dsl.teksavvy.com
<Infinoid> jonathan: PDD13 doesn't specify the size of the "words" accessed by RawSegment.pmc.  Native INTVAL-sized words?  Or something more specific?
<Infinoid> also, thinking of naming it packfilerawsegment.pmc, rather than just rawsegment.pmc, to be consistent with the rest.
<dalek> r27047 | jkeenan++ | trunk:
<dalek> : Edit some comments so that they pass t/codingstd/perlcritic.t policy
<dalek> : Bangs::ProhibitFlagComments.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27047
% tetragon has joined #parrot
<Infinoid> r27046.logentry =~ s/Fack/Pack/
% wknight8111 has left wknight8111!~nobody@c-71-230-33-251.hsd1.pa.comcast.net
% particl1 has left particl1!~particle@c-24-19-3-148.hsd1.mn.comcast.net
% particle has joined #parrot
<dalek> r27048 | jkeenan++ | trunk:
<dalek> : Add tests.  Here, case where --without-opengl is specified on command line.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27048
<kid51> Infinoid:  ping
% IllvilJa has left IllvilJa!~jilves@ua-83-227-215-229.cust.bredbandsbolaget.se
<Infinoid> kid51: hi!
<kid51> You know about OpenGL?  What would be sufficient to prove someone had installed it?
<kid51> config/auto/opengl.pm has this comment:  Mindlessly morphed from readline ... may need to be fixed 
<kid51> ... referring to getting it from Fink and macports ... and later on Win32.
<Infinoid> currently, being able to compile config/auto/opengl/opengl.in and link it against -lglut -lGLU -lGL
<kid51> In Fink, I see these packages:  glut and glut-shlibs
<kid51> In Macports:  http://trac.macports.org/projects/macports/browser/trunk/dports/graphics/glut/Portfile
<shorten> kid51's url is at http://xrl.us/bjkce
<kid51> But I get the feeling that that's not all that's needed.
<kid51> (I don't have opengl installed anywhere.)
<Infinoid> glut should depend on the rest of opengl
<Infinoid> glut-shlibs sounds like it has libglut.so
<Coke> cotto_home: (schedule for pre-YAPC::NA hackathon) no, not yet. I'll be there, whenever it is.
<kid51> See code coverage for auto::opengl:  http://thenceforward.net/parrot/coverage/configure-build/config-auto-opengl-pm.html
<shorten> kid51's url is at http://xrl.us/bjkci
<dalek> r27049 | infinoid++ | trunk:
<dalek> : opengl detection test file: fix the following warning:
<dalek> : opengl.c: In function 'main':
<dalek> : opengl.c:14: warning: the address of 'glutInit', will always evaluate as 'true'
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27049
<tetragon> Incidentally, I can get the test for opengl to build on a more vanilla OS X by simply changing it from GL/glut.h to GLUT/glut.h
<tetragon> OS X splits OpenGL between two system frameworks, OpenGL and GLUT
<Infinoid> hmm
<tetragon> And it builds and links correctly without any compiler flags
<Infinoid> after that last checkin, it builds cleanly for me with: g++ -O2 -Wall -o opengl opengl.c -lglut -lGLU -lGL
<Infinoid> and prints: "4"
<tetragon> It prints "5" for me
<tetragon> g++ main.c
<tetragon> No flags, opengl.in renamed to main.c
<Infinoid> interesting
<tetragon> It's doing dynamic lookup
<tetragon> The moment I start pointing it at libraries, the build starts failing
* tetragon goes and looks up the framework gcc flags
* Infinoid opens an opengl detection ticket and sees if he can get the original submitter to have a look
<tetragon> g++ main.c -framework GLUT
<tetragon> It then explicitly links against glut
<Infinoid> are there multiple implementations of the same API to choose from?
<tetragon> Don't think so on my box
<tetragon> I also have some GL headers in /usr/X11
<Infinoid> they very likely put those in there for reverse compatibility with the mess libGL has been making of unix for the last 10 years or so.
<tetragon> Both my Tiger and Leopard Macs give 5 as that version
<tetragon> The difference between 4 and 5 (according to the header file) is 5 added glutGetProcAddress
<Infinoid> ok.  I've created #53088 and pinged (pung?) Geoff Broadwell about it
<Infinoid> he was hoping for more testing, looks like he's got it.
<kid51> And I'm supplying the usual tests of the Perl 5 code.
<Infinoid> oh, and also, what's the story with readline?  I've been meaning to look at it because it fails to detect with g++
<dalek> r27050 | jkeenan++ | trunk:
<dalek> : Add test file to test internal methods and subroutines in auto::opengl.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27050
<Infinoid> kid51++
<tetragon> Hrm... Looks like there's a difference in name mangling
<tetragon> Works the moment I put the externs in an 'extern "C"' block
<Infinoid> I had to do exactly that for src/nci_test.c, recently
<Infinoid> C++ hurts my brain.
<nopaste> "tetragon" at 216.126.67.44 pasted "C++ patch to readline.in" (18 lines) at http://nopaste.snit.ch/12731
<tetragon> You can try that, it works on my box
<dalek> r27051 | jkeenan++ | trunk:
<dalek> : Add file to test auto::opengl internal subs where verbose output has been
<dalek> : requested.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27051
<Infinoid> Determining if your platform supports readline.........................yes.
<Infinoid> nice.
<tetragon> That doesn't necessarily mean that stuff that uses it will build, but it gets past the test
* Infinoid finds out
<dalek> r27052 | jkeenan++ | trunk:
<dalek> : Update MANIFEST to reflect recently added test files.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27052
% liona29 has joined #parrot
% liona29 has left liona29!~liona29@d033.dhcp212-198-248.noos.fr
<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.
<kid51> paula35 camgirl29 liona29  all using that address
% guru has joined #parrot
<Infinoid> I noticed that too
<kid51> We now have a record number of Torontonians on channel ;-)
<Infinoid> yesterday: [05:08]  -!- lola22 [~lola22@d033.dhcp212-198-248.noos.fr] has joined #parrot
<Infinoid> very likely a spambot
<kid51> Can we/should we do anything about it?
<kid51> How about we add it to the Ban List?
<kid51> This is the one that I banned:  *!*@d033.dhcp212-198-248.noos.fr
<dalek> r27053 | jkeenan++ | trunk:
<dalek> : Correct number of tests in plan.
<dalek> diff: http://www.parrotvm.org/svn/parrot/revision?rev=27053
% tetragon has left tetragon!~seneca@216.126.67.44
% tetragon has joined #parrot
% mj41 has left mj41!chatzilla@pc-jurosz.ro.vutbr.cz
<Infinoid> tetragon: it didn't link, libparrot.so ends up wanting mangled versions of readline() and add_history()
<Infinoid> thanks for the patch tho, I think its a step in the right direction
<Infinoid> if I do the same thing to the prototypes in parrotio.pmc, it builds.
% kid51 has left kid51!~jkeen@pool-71-247-57-84.nycmny.east.verizon.net
% guru has left guru!~guru@bas3-toronto02-1279612858.dsl.bell.ca
% guru has joined #parrot
% Andy has joined #parrot
% guru has left guru!~guru@bas3-toronto02-1279612858.dsl.bell.ca
% rdice has left rdice!~richarddi@CPE001217e365c7-CM00159a01d44c.cpe.net.cable.rogers.com
% contingencyplan_ has joined #parrot
% contingencyplan has left contingencyplan!~contingen@cpe-76-186-27-146.tx.res.rr.com
% japhb has joined #parrot
<dalek> r27054 | infinoid++ | pdd13pbc:
<dalek> : Create dummy PackfileRawSegment and PackfileConstantTable PMC classes,
<dalek> : with stub methods as defined by PDD13.
<dalek> diff: http://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?
<Infinoid> jonathan: and while we're at it, are constants named/labeled somehow?  or are they referred to by other means?
% Psyche^ has joined #parrot
<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
<japhb> arse them?
<Infinoid> hi japhb (Mark Glines here)
<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?
% Patterner has left Patterner!~Psyche@e177237073.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<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)
<Infinoid> or 2.  figure out a list of paths from CFLAGS yourself, and find the right one with a loop
<Infinoid> the other part of the problem, of course, is figuring out whether it should be GL/glut.h or GLUT/glut.h or what
<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.
<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
<Infinoid> 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.
<japhb> Infinoid: rockin'.  That's cool.
% peepsalot has left peepsalot!~peeps@cpe-67-9-161-48.austin.res.rr.com
<tetragon> japhb: Apple gcc is a bit different to GNU gcc.  The -framework flag is part of the difference
<japhb> tetragon: are you just fixing auto::opengl, or are you working on gen::opengl as well?
<tetragon> I'm working on gen
<tetragon> Its output is where my system is blowing up on right now
% AndyA has left AndyA!~andy@82.152.157.85
<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.)
<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
<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.  :-/
<japhb> Infinoid: right.
<Infinoid> this is one area where parrot can't be as self-sufficient as we would like
<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
<tetragon> 5 adds glutGetProcAddress
* japhb mumbles something incoherent about vendors messing with perfectly good version numbering
% AndyA has joined #parrot
<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?
<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
<japhb> tetragon: still, I was careful to use >=, rather than ==, for this very reason.
<japhb> tetragon: can you put that header somewhere, or nopaste it or somesuch, so I can grab it and look?
<japhb> Infinoid: thx for sending kid51 that message, I wouldn't have known who to ask.
<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 ....
<nopaste> "tetragon" at 69.196.138.185 pasted "glut.h" (636 lines) at http://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
% Limbic_Region has left Limbic_Region!~Limbic_Re@c-68-49-236-220.hsd1.md.comcast.net
* japhb looking at tetragon's paste
<Infinoid> I like the header prefix changes, conditional in #if defined(__APPLE__) || defined(MACOSX)
<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.
<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?
<tetragon> I think NeXT has similar splits
<Infinoid> I promise to care as soon as the first whiny user bugs us about it
<japhb> Infinoid: fair enough
<tetragon> Got it to link
<tetragon> Which set of tests are the OpenGL ones?
<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.
<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
<Infinoid> (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?
<japhb> 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.
<japhb> Infinoid: but yes, pedantry aside, I understand your point.
<tetragon> japhb: Check under here: http://developer.apple.com/referencelibrary/GraphicsImaging/idxOpenGL-date.html#doclist
<shorten> tetragon's url is at http://xrl.us/bjkg9
<Infinoid> anyway, how do you do unit tests for opengl?
<Infinoid> you'd need pattern recognition to see whether it really looks like a triangle
<japhb> Infinoid: <cheap shot>Judging by vendor drivers, I'd say they don't do them</cheap shot>
<japhb> Seriously though, I was thinking about that,
<tetragon> So, my parrot instance is linked against GLUT and OpenGL, but parrot can't find it
<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.
<Infinoid> 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.
% pjcj has left pjcj!~pjcj@84-73-177-217.dclient.hispeed.ch
<Infinoid> tetragon: does it need an LD_LIBRARY_PATH sort of hack?
% DarkWolf84 has left DarkWolf84!~dwolf@89.215.234.147
<tetragon> Infinoid: Doubtful.  GLUT and OpenGL are already standard frameworks and linked against
<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 http://nopaste.snit.ch/12734
<Infinoid> japhb: yeah, I've done it before, and I need to do it again.  (Fuse.pm needs it badly.)
<Infinoid> still a lot of work tho :)
* japhb gacks at the mixture of directory conventions seen in tetragon's latest paste
<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
<Infinoid> my mistake :)
<japhb> So, when I started trying to design for something resembling portability,
<japhb> I wrote this little PIR routine that would take a list of different names that a dynamic library might be known as,
<japhb> try to load each one in sequence until it either ran out of possibilities, or succeeded.
<tetragon> Not expecting anything like OpenGL or GLUT
<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
<tetragon> They're even quad-architecture binaries
<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?
<tetragon> No .dylib
<tetragon> Just OpenGL and just GLUT
<japhb> tetragon: so just push 'OpenGL' and 'GLUT' onto the lists found at OpenGL.pir: 52-76
<japhb> Each place you see "push libnames, 'foo'" add another push underneath
<japhb> (You'll need to make again to get the .pbc generated, so the new code will get loaded by the OpenGL example. of course.)
<japhb> second to last period there should be a comma (I'm not quite that rude)
<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.
<japhb> Tene: link?
<japhb> Hmmm, I wonder if we lost tetragon
<tetragon> I'm still here
<Tene> ah, here we go: http://use.perl.org/~tene/journal/36200
<tetragon> Build was taking a while
<japhb> tetragon: ah, OK, good
<japhb> (good to have you still here, I mean)
<japhb> Tene: thx
<tetragon> Same error, different line numbers
<tetragon> I may have missed a spot
<japhb> nopaste?
<purl> nopaste is at http://nopaste.snit.ch/ (ask TonyC for new channels) or http://rafb.net/paste or http://paste.husk.org/ or http://poundperl.pastebin.com/ or http://paste.scsys.co.uk/ or don't bother me while I'm eating
<tetragon> I'll be back shortly.  Relocating my laptop
% tetragon has left tetragon!~seneca@69-196-138-185.dsl.teksavvy.com
<Infinoid> Tene: awesome!
<purl> awesome is probably http://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
<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.
<Tene> self-deprecating?
<Tene> Huh, I guess I can understand how you could see that.
<japhb> Mmmm, lacey's ... it doesn't get much better than this.
* 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.
<PerlJam> Tene: what do you think of github?
% tetragon has joined #parrot
<tetragon> Hrm, I wonder if it's searching for .dylib?
<Infinoid> its possible
<Infinoid> config/init/hints/darwin.pm:34:        share_ext           => '.dylib',
<tetragon> I can do GL and GLU with dylib
<tetragon> but not GLUT
% peepsalot has joined #parrot
<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?
<tetragon> It's still having problems with GL
<japhb> bah ram ewe
<tetragon> And parrot is linked against OpenGL and GLUT
<japhb> ok, paste your OpenGL.pir, please, let me cogitate for a minute
<Infinoid> is libGLU important?
<Tene> PerlJam: it's' quite nice
<tetragon> Infinoid: It's part of the OpenGL framework
<nopaste> "tetragon" at 216.126.67.44 pasted "OpenGL.pir" (313 lines) at http://nopaste.snit.ch/12735
<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.
<japhb> Some people never use it, which is why it's not part of core GL itself.
<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.
<Infinoid> nice.
<Infinoid> will loadlib fail if the same library has already been loaded?
<Infinoid> 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
<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.
<japhb> tetragon: OK, so on Mac OS X, are the dynamic libs for OpenGL stored inside the framework directory?
<tetragon> All of OpenGL is in the framework
<tetragon> 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"
<japhb> So in theory, the original 'libGL' should have worked
<japhb> fu. bar.
<japhb> OK, let's get silly.  Try pushing 'libGL.dylib' to libnames.
<Infinoid> ok, this dreamy music is getting to me.  japhb++ tetragon++  goodnight all
<tetragon> Same error
<tetragon> japhb: What's in runtime/parrot/dynext on your (non-OSX) system?
<tetragon> Because that's where loadlib looks
% arbingersys has joined #parrot
<japhb> sorry, was AFK for cat with upset stomach
<japhb> looking ...
<japhb> ah, well, haven't run make in a while, so it's empty
<japhb> right, rebuilding
<tetragon> Heh, changing to libglutcb gets me to a different error, further in.  It loads from there.
% Psyche^ has joined #parrot
<tetragon> I'm now getting an error from NCI
<japhb> well, libglutcb is generated by gen::opengl, and it just wraps the GLUT callbacks to work around deficiencies in Parrot's NCI model.
<japhb> How do you find out the dynamic link directory path on OS X?
<japhb> I mean, just at the command line
<japhb> 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
<japhb> tetragon: grr, so why can't parrot find it?
* japhb wonders if it's something broken with the 'loadlib' op implementation in Parrot ....
<tetragon> Because that's not what parrot is looking for
<tetragon> From what I see, loadlib doesn't look for system libraries.
% Patterner has left Patterner!~Psyche@e177229239.adsl.alicedsl.de
% Psyche^ is now known as Patterner
<japhb> tetragon: explain, please, I'm confused
<japhb> It clearly does on linux.  (search system libs)
<japhb> Oh wait!
<japhb> 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?
<tetragon> ?
<japhb> Accessing the running Parrot binary as if it was a dynamic library ...
<japhb> Something I saw a long time ago while perusing the Parrot docs.
<japhb> Lemme see if I can find it
<PerlJam> yeah, you loadlib the empty string I think
% arbingersys has left #parrot
<japhb> tetragon: can you try that?  Adding the empty string to libnames for GL?
<tetragon> Failed
<tetragon> Same old error
<japhb> Hmmm, docs/compiler_faq.pod seems to indicate you have to use a "null" string.
<japhb> (look near 'loadlib' in that doc)
<japhb> And the other thing to try is the full pathname to libGL.dylib on your system.
<japhb> 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
<japhb> tetragon++ # helping to get this mess figured out
<tetragon> Full paths to the linked against objects (which lack extensions) work
<tetragon> I'm seeing a spinning triangle now
<japhb> YAY!
<japhb> Man that sucked
<japhb> 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:
<tetragon> What are they?
<purl> they are intermingled and intertwingled
<tetragon> How accurate
<japhb> Hold on, copying:
<japhb>   /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
<japhb>   /Developer/SDKs/MacOSX10.4u.sdk/System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
<japhb>   /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?
<tetragon> I didn't play with the SDKs (which let you target different versions) or the individual dylibs
<tetragon> 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
<japhb> tetragon: so I'm gathering ...
<nopaste> "tetragon" at 216.126.67.44 pasted "OpenGL.pir that works on OS X" (311 lines) at http://nopaste.snit.ch/12736
<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
<japhb> OK, about to paste a change to that routine, let's see if a little cleanup still works ...
<tetragon> It'll take a while to build... I've just realcleaned it
% Davemon has joined #parrot
<nopaste> "japhb" at 76.191.190.8 pasted "Cleanup of OpenGL.pir library lists -- does this work?" (28 lines) at http://nopaste.snit.ch/12737
<japhb> tetragon: ah
<japhb> I just cleaned the libnames lists a bit, want to know if it works with that simplified.
<japhb> 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 ...?
<tetragon> Can't say or test.  I don't have that platform
<japhb> nodnod
% Dave has left Dave!~dave@pool-141-150-16-73.mad.east.verizon.net
<japhb> 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.
<tetragon> Hrm... I'm getting a few compiler warnings from the generated glut_callbacks.c
* japhb grumbles about how ridiculously slow RT is about sending mail
<japhb> paste again?
<tetragon> It won't be in the most readable form, as I'm using -j2
<japhb> It was warning free on my box, but then linux/i386 is ridiculously forgiving
<japhb> 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.
<japhb> Oh, wait, I've got a guess.
<japhb> hold on a sec
<japhb> I'm a moron.
<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
<japhb> nodnod
<japhb> I meant ... when I wrote the callbacks generator, I was focused on how freeglut sees the world.
<japhb> I didn't realize that (annoyingly) the OS X GLUT would claim different things belonged in API version 4.
<tetragon> I see glutDestroyMenu in my headers
<japhb> different function.  That's just a normal call, not a callback registration.
<japhb> OK, let me compare things here.
<japhb> Did you get a chance to check if my simplified libnames lists worked for you?
<tetragon> The build still hasn't finished
<tetragon> And it just has
<tetragon> Works
<tetragon> Now I'm waiting on svn diff to churn through my changes
<tetragon> Taking too long
<tetragon> 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 ...
<nopaste> "tetragon" at 216.126.67.44 pasted "config/auto/opengl/opengl.in" (25 lines) at http://nopaste.snit.ch/12738
<nopaste> "tetragon" at 216.126.67.44 pasted "config/auto/opengl.pm" (132 lines) at http://nopaste.snit.ch/12739
<nopaste> "tetragon" at 216.126.67.44 pasted "config/gen/opengl.pm" (499 lines) at http://nopaste.snit.ch/12740
<tetragon> And you already have OpenGL.pir
<japhb> bak
<japhb> tetragon: why #ifdef __APPLE_CC__?  Shouldn't that be dependent on a more generic define?  Or is that to differentiate from fink/macports?
<tetragon> gcc produced a list of predefined macros, and __APPLE_CC__ seemed to be the most specific
<japhb> fair enough.
<japhb> 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
<japhb> hmmm
<japhb> Can you create a diff and attach it to the ticket?
<japhb> 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
<japhb> nodnod
<tetragon> It's been added to #53086
<japhb> k, thx
<avar> japhb: make parrot switch to git too:)
<japhb> avar: heh
<tetragon> I don't like using git
<japhb> tetragon: why?  (honest question)
<tetragon> Seen too many situations that went wrong when using it (in addition to it polluting ~/bin with too many files)
<japhb> tetragon: fair enough.
<japhb> I've had my share of problems with SVK, and have been looking at switching from SVK to git-svn
<tetragon> I mostly just use svn, with some bzr
% ilbot2 has left ilbot2!moritz@faui2k3.org
<japhb> (raw SVN is right out, because I often work disconnected)
<tetragon> There was an OLPC games hackathon that I did some sysadmin stuff at, and too many people got stomped on by git while working in the same files
<japhb> Isn't that precisely the kind of thing git was supposed to be good at?
<tetragon> They ended up emailing eachother their patches and having only a single person committing
<avar> Sounds like they didn't know how to perform merges
<tetragon> From what I could tell, the changes were too close and git handles conflict and conflict-like situations differently to more familiar systems
<japhb> ah
% moritz has left moritz!moritz@ssh.faui2k3.org
<tetragon> They got into situations that the person there most familiar with git couldn't figure out and lost changes as a result.
% moritz has joined #parrot
<tetragon> Anyway, 02:00 means I need sleep
<japhb> OK, I'll keep working on this
<japhb> and upload a new patch in a bit
<japhb> have a good night, tetragon
% Andy has left Andy!~Andy@64.81.227.163
% Davemon is now known as Dave