Parrot 1.9.0 "Blue-fronted Amazon" released! | parrot.org | Roadmap: icanhaz.com/parrotroadmap | Latest modified TT's: icanhaz.com/parrotbugs
Set by moderator on 16 December 2009.
00:16 kid51 joined
Coke will anyone cry if I eliminate all the _DIR variables in the makefile? 00:28
(or at least most)
they seem to just be obfuscating.
kid51 I shed my last tears in 1993.
Coke excellent!
purl EGG-see-lent!
00:28 payload joined
kid51 But maybe you could paste a patch so we have a better idea of what you're plotting? 00:29
Coke it's all in one_make.
kid51 that's a branch?
Coke ayup
trying to do general makefile cleanup. notes in #ps log today.
kid51 I took a too quick glimpse at that.
Coke works on killing compilers.dummy first. 00:30
kid51 Was looking in from $job when all hell broke loose.
While I'm doing a checkout ... any thoughts on TT #1393? 00:31
Coke no, I saw that one. just standard diagnostics, does it still die if you disable GC, can you reduce the code needed to generate the signal, can you capture a backtrace in gdb... 00:34
kid51 I'll see what I can do. Don't have much experience with C debugging.
Another ticket I'm puzzled about is trac.parrot.org/parrot/ticket/473 (see most recent comments) 00:35
Am I correct in believing that any and all impact of changes in the one_make branch should be evident by completion of Configure.pl? 00:37
00:43 Zak joined
Coke no 00:43
kid51 "does it still die if you disable GC?" No, it does not! So it's the --gc-debug that sparks the problems.
Coke I'm changing the Makefile, so you have to actually build parrot.
nopaste "kid51" at 70.85.31.226 pasted "TT #1393: Without --gc-debug, pge_examples.t PASSes under harness" (4 lines) at nopaste.snit.ch/19186 00:44
"kid51" at 71.255.54.187 pasted "gdb parrot on t/compilers/pge/pge_examples_2.pir" (18 lines) at nopaste.snit.ch/19187 01:02
kid51 Coke FWIW one_make branch passes all tests in 'make test' ... except the one that's giving me problems in trunk. 01:07
01:07 theory joined
Coke heh. 01:10
kid51 Never fails: No sooner do I close a ticket for Smolder upload timeouts than I start getting hit with them myself! 01:21
Hmm, this is weird. My 3 smoke tests actually *did* upload to Smolder ... but the feedback I got on the command-line was: 01:23
Could not upload report to Smolder at smolder.plusthree.com
HTTP CODE: 500 (read timeout)
make: *** [smolder_test] Error 255
in all 3 instances!
Coke: My earlier report that there were no (significant) problems with one_make branch was probably wrong. 01:26
Coke hokay
at this point, if it's passing any tests, it's ok. =-)
but if you have specific things that are failing, I'm happy to hear them.
kid51 It built, but something's amiss during 'test' 01:27
Doing 'make clean' and new smolder
Coke probably missing some deps.
kid51 Yes.
nopaste "kid51" at 71.255.54.187 pasted "one_make branch: preliminary report on 'make test' failure" (7 lines) at nopaste.snit.ch/19188 01:30
Coke ah, yah, data_json is still part of compilers.dummy 01:31
one of the last holdouts.
01:37 Andy joined
nopaste "kid51" at 71.255.54.187 pasted "one_make branch: preliminary report on 'make' failure" (9 lines) at nopaste.snit.ch/19189 01:37
Coke hurm. 01:38
Doesn't look like compiler nqp's "boot" target is part of the normal build. 01:41
02:31 JimmyZ joined 03:12 bacek joined
Coke any reason we cannot rely on prove? 03:24
JimmyZ when it's #!parrot ? 03:38
Coke, I don't know whether it's GFWoC issue or not. 03:41
Coke GFWoC? 03:43
anyone know how to make nqp_test work from the top level dir? 03:47
(right now it does a cd into compilers/nqp)
JimmyZ GFW 03:48
Coke aha. Parrot::Test::Harness is smarter than I thought. fixed. 03:51
dalek rrot: r43313 | coke++ | branches/one_make (12 files):
Convert compiler/nqp's recursive make to an include.
 04:15
rrot: r43314 | plobsing++ | branches/pmc_freeze_cleanup/src/pmc (14 files):
remove checking for EXTRA_IS_NULL in PMCs (it will always be so)
 04:31
rrot: r43315 | coke++ | branches/one_make (8 files):
convert data_json's recursive make to an include.
 04:47
purl I don't know how to convert data_json's recursive make to an include..
Coke holy crap. 04:48
purl only in the Vatican, my friend
Coke The shenanigans required to fill in @library_tests@ instead of just leaving that in the Makefile is insane. 04:49
Coke rips it out.
Coke ughs. 04:52
Coke reverts.
dalek rrot: r43316 | coke++ | branches/one_make (2 files):
$(IMCC_DIR) -> compilers/imcc
 05:04
rrot: r43317 | coke++ | branches/one_make/config/gen/makefiles/root.in:
eliminate PF_DIR variable
06:25 msmatsko joined 06:37 bacek joined
nopaste "tene" at 76.27.121.193 pasted "glxinfo" (633 lines) at nopaste.snit.ch/19190 07:19
Tene Ack.
Didn't mean for that to go here. :)
Too used to nopasting into this channel.
hejki :D 07:29
but hey, at least your direc rendering works!
s/rec$/rect/;
Tene Heh. 07:40
I'm trying to play with love2d.org/ but it's segfaulting after X failures on my laptop.
But works fine when forwarded to a different X server, like my desktop, or Xephyr.
hejki ahh.. pygame eqv for lua?
looks nice. too bad i'm not that much into lua. 07:41
ever played with bullet? :)
Tene Not sure. Don't know much about pygame. The love package actually has a separate binary, doesn't install any lua libraries, has some stuff for reading dirs out of a zip file, etc.
No, never heard of it.
hejki ahh ok 07:42
so it's different from pygame :P
bullet is nice
physics :)
bulletphysics.org/ 07:44
07:57 Essobi joined 08:05 eternaleye joined 08:14 mikehh joined 08:21 eiro_ joined, iblechbot joined 08:44 bacek joined 08:49 xenoterracide left 09:17 mikehh joined 09:46 mikehh joined 09:53 fperrad joined 09:54 mikehh joined 10:10 cognominal joined 10:39 mikehh joined 10:56 bacek joined 11:16 payload joined 12:07 mikehh joined
dalek rrot: r43318 | bacek++ | branches/boehm_gc (3 files):
Get rid of GC_DEBUG macro. It's not so usefull and conflicting with
 12:21
rrot: r43319 | bacek++ | branches/boehm_gc/src/gc/gc_boehm.c:
Implement finalization and explicit collect in Boehm GC.
12:25 bacek joined 12:31 masak joined 12:36 ruoso joined 12:51 cognominal joined 13:11 fperrad joined 13:24 plobsing joined 13:52 whiteknight joined 14:06 bluescreen joined 14:37 payload joined 15:03 PacoLinux joined 15:06 pdcawley joined 15:10 bluescreen joined 15:14 patspam joined 15:28 mikehh joined 15:30 bluescreen joined 15:34 fperrad_ joined 15:48 ash_ joined 15:55 Psyche^ joined 16:06 payload joined
dalek rrot: r43320 | mikehh++ | branches/one_make/compilers (2 files):
set svn properties
 16:08
rrot: r43321 | mikehh++ | branches/boehm_gc/MANIFEST:
regenerate MANIFEST
plobsing question about constant PMCs - must they only contain constant strings as well as PMCs? 16:14
mikehh plobsing: no idea really, but it sounds right 16:20
I would think that if the PMC is constant it should not change 16:21
plobsing thats not what "constant" means in parrot.
"constant" means "ignored by GC"
roughly
mikehh then it should be called something else maybe 16:22
plobsing preaching to the choir
mikehh to me constant means immutable
dalek rrot: r43322 | mikehh++ | branches/boehm_gc (2 files):
set svn keywords
 16:25
mikehh All tests PASS (pre/post-config, make corevm/make coretest, smoke (#31381), fulltest) at r43319 - Ubuntu 9.10 amd64 (g++ with --optimize)
dalek rrot: r43323 | mikehh++ | branches/boehm_gc/src/gc/gc_boehm.c:
fix codetest failure - at least one space between C keyword and subsequent open parenthesis
 16:41
rrot: r43324 | mikehh++ | branches/boehm_gc/src/gc/gc_boehm.c:
fix codetest failure - no c++ comments (highlighted with /*** .. */)
16:41 lucian joined 17:06 payload1 joined
cotto mikehh, istr that bacek leaves those c++ comments there on purpose. 17:13
dalek rrot: r43325 | mikehh++ | branches/boehm_gc/src (3 files):
fix codetest failure - Correctly indented preprocessor directives
17:23 theory joined 17:47 fperrad_ joined 17:49 ruoso joined
Coke mikehh++ # fixing distro bugs. 19:27
msg particle you're the only person I know who uses nmake. Can you try out the one_make branch? 19:28
purl Message for particle stored.
Coke seen pmichaud ?
purl pmichaud was last seen on #parrot 8 days, 3 hours, 18 minutes and 33 seconds ago, saying: good morning. [Dec 22 16:07:55 2009]
ash_ Coke: do you use/have os x? 19:29
19:31 joeri joined 19:36 payload joined
Coke ash_: not until I resurrect my imac which just killed the boot disk. 19:38
(but I'm stuck at 10.4) 19:39
19:39 ash_ joined
ash_ bah colloquy just crashed 19:39
Coke: okay, just curious
i noticed in the opengl stuff that parrot searches for OpenGL in the runtime/parrot/library/OpenGL.pir file in OS X it looks for a libGL.so.1, on my computer (10.6.2) it can't open the libGL librarys (which is actually named libGL.dylib, not .so.1) but my i am misunderstanding how NCI works 19:44
19:48 bacek joined
japhb ash_, OpenGL.pir tries a series of possible library names until it finds one it can load. The second one it tries is libGL, and on OS X, that should resolve to libGL.dylib. If it doesn't (anymore, perhaps), then we just need to add 'libGL.dylib' to the list at line 114. 19:57
I have to say, OS X linking is a complete nightmare.
dalek rrot: r43326 | mikehh++ | branches/boehm_gc/src/gc/alloc_memory.c:
fix codetest failure - there should be one space or a newline after a comma and unwrapped macro arguments
ash_ japhb: hm, here's the error i get 20:09
Could not find a suitable GL shared library! which is thrown on that section of code (around 114)
japhb Yeah, that means it couldn't find a match. Try copying line 114 and adding the .dylib on one copy, and 'make reconfig' 20:11
dalek rrot: r43327 | mikehh++ | branches/boehm_gc/src/gc/gc_boehm.c:
fix codetest failure - add missing function documentation (this needs clarificartion - placeholder)
 20:14
ash_ do i need to run make after reconfig? 20:15
japhb ash_, yes, sorry, forgot to mention that
ash_ kk, i figured as much, its running right now
japhb is multitasking heavily right now
Coke mikehh: you can add a function to the skip list for that instead of adding a potentially incorrect description. 20:17
ash_ japhb: still it doesn't work 20:20
purl It's a Y2K error! Panic! Sue!
japhb :-(
I remember something goofy about having to link parrot itself with the frameworks for OpenGL and GLUT ... we had that working at one point; I wonder if that got broken 20:21
ash_ oh, its looking in the wrong folder
japhb ?
ash_ it set the folder as /System/Library/Frameworks/OpenGL.framework/OpenGL but it should be: /System/Library/Frameworks/OpenGL.framework/Libraries/ 20:22
japhb Huh.
That sounds like a version-dependent thing
OK, I guess we'll have to detect that somehow.
Have you got the Perl and C skills to fix the configure stage and make sure it works with both old and new locations? 20:23
(Oh, and/or the Makefile.in, come to think of it)
ash_ sure, but i don't know the old layout
bacek o hai 20:24
japhb I would naively assume the old layout is what it was set to before ... but we need another Mac user to confirm. 20:25
mikehh hi bacek
bacek mikehh, thanks for work on boehm_gc branch
mikehh bacek: mostly getting codetest to pass - still needs work elsewhere 20:26
dalek rrot: r43328 | bacek++ | branches/boehm_gc/src/gc/gc_boehm.c:
Call Parrot_pmc_destroy in finalizer cb.
 20:30
ash_ japhb: alternatively you can try linking against /usr/X11/lib/libGL.dylib which will open with X instead of Quartz 20:32
20:40 szbalint joined
GeJ Good morning everyone 20:43
Coke ~~
Tene Hi, GeJ! 20:44
GeJ Heya Tene, Coke. 20:46
20:51 lucian joined
ash_ so... adjusting all the load paths in runtime/parrot/opengl.pir it loads fine 21:22
but now when it calls one of the glut methods i get: GLUT: Warning in triangle.pir: The following is a new check for GLUT 3.0; update your code.
so it becomes loadable but not callable, hmmm
21:30 bacek joined
mikehh boehm_gc branch: All tests PASS (pre/post config, make corevm/make coretest, test, fulltest) at r43328 - Ubuntu 9.10 amd64 (g++ with --optimize) 21:47
bacek: looks good - do we have any benchmarks to check different GC variants 21:53
22:04 eternaleye joined
japhb ash_, "GLUT: Warning in triangle.pir: The following is a new check for GLUT 3.0; update your code." UR? Can you show the complete error? "The following" seems to indicate it was about to say something else .... 22:14
ash_ GLUT: Warning in shapes.pir: The following is a new check for GLUT 3.0; update your code.
GLUT: Fatal Error in shapes.pir: redisplay needed for window 1, but no display callback.
japhb ?!? 22:15
OK, that's just WEIRD
problem building libglutcb during parrot build?
(Or maybe that's got the same path issues you found earlier?)
ash_ it happens when you call glutMainLoop() 22:16
googling the error saids its because glutDisplayFunc wasn't getting set, but it is
mikehh pmc_freeze_cleanup branch: All tests PASS (pre/post config, make corevm/make coretest, test, fulltest) at r43328 - Ubuntu 9.10 amd64 (g++ with --optimize)
japhb ash_, yeah, I'm thinking something's hinky with libglutcb, which is the magic bit of Parrot code that allows GLUT callbacks to work with Parrot NCI 22:17
ash_ how is libglutcb made? 22:19
ah, i see, its generated, from config/gen/opengl.pm i'll look at that and see if i can find any problems with it 22:21
japhb ash_, excellent, thank you. 22:23
That was always basically a hack around limitations of existing Parrot NCI
It's a minor miracle it works at all. :-)
ash_ japhb: so... glutDisplayFunc takes a C function pointer, someone its being called in parrot with a parrot sub instead, isn't the point of glutcbDisplayFunc to wrapper glutDisplayFunc to take a parrot sub and store it then pass a C function that calls the parrot one? i think, if i am understanding glutcbDisplayFunc right thats what it should do. Is there a reason that its not being used? 22:32
s/someone/somehow/
japhb ash_, when the glutcb* functions are imported into another namespace, they are renamed to get rid of the 'cb', so the user does not need to know about the hack. 22:37
ash_ oh, okay, i understand
japhb See lines 289 through 303 of OpenGL.pir
ah, good.
ash_ can you start parrot with the gdb? 22:40
japhb ash_, In general yes. Also, I could, but I'm not sure how that would help here, as I don't have a mac dev box. :-) 22:43
ash_ well i think the issue is in some of the C code and i can't view that with --trace :P 22:44
japhb Grr, we used to have purl trained to know who the Mac users were around here, but I've forgotten the write factoid key, or purl has. 22:46
ash_ gdb is a linux thing too 22:48
they'd know
japhb ash_, right ... but I'm saying "Everything works in Linux. Last I heard, it works on Mac OS X 10.5 and earlier. It fails on Mac OS X 10.6. So me doing a gdb on my Linux box will not help find the problem on your OS X 10.6 box. :-)" 22:50
ash_ ah, i found someone in the perl6 channel that said its failing on 10.5 too
same issue
purl same issue is in Formatter::Youtube
22:50 eternaleye joined
japhb Ah, that's getting a little warmer. At least we know it *used* to work on 10.5. 22:51
ash_ i can't find anyone (online) with 10.4 though to check that one
japhb nodnod
Infinoid, ping 22:53
bacek mikehh, It actually not quite good... When I switch default GC to Boehm it crashes on building PGE... 22:58
22:58 Whiteknight joined
dalek TT #1400 created by jth++: 1.9.0 Compilation on Mac 23:00
Infinoid japhb: pong 23:22
japhb Infinoid, Was trying to help ash_, but don't know the OS X world. I noticed you were (long ago) in the section of OpenGL.pir that sets paths for OpenGL / GLUT libraries. Can you lend any insight to ash_'s problem? 23:24
Infinoid I don't know the OS X world, either. I'm a linux/x64 geek 23:25
ash_ i am not exactly sure how to figure out where the next problem is to be honest, i think its in glutDisplayFunc but i can't tell for sure 23:26
japhb Ah. You were on the svn blame for the OS X lines
ash_ can i add breakpoints in the gdb to a extension? (specifically the /runtime/parrot/dynext/libglutcb) 23:27
Infinoid japhb: Was that svn blame from r27022?
r27022: Apply (slightly modified) OpenGL patch from Geoff Broadwell in RT #52988. Geoff++
:)
japhb No, a later one. Checking
27059 23:28
japhb laughs
ash_ my gdb foo is weak 23:29
japhb That was a patch as well -- you committed, I formatted the patch, the original appears to have been from tetragaon/kid51/ambs
OK, so I get the "well, duh" award for the afternoon.
Infinoid Yeah. I think I basically just let them kick it around until they were all happy, and then applied it blindly
Sorry... :)
japhb tetragon, kid51, ambs: If any of you are available, we need some Mac OS X skillz to help ash_ 23:30
Infinoid, np, sorry to have bothered you without checking the log entry first. ;-)
japhb almost forgot there was a time I needed to have someone else apply patches for me. ;-) 23:31
Infinoid a very short period of time... :)
ash_ why do you load a dynext? 23:37
nm, i figured it out 23:42
well, i gotta head home, i'll work on this opengl thing a bit more if i have time 23: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!