Parrot 0.6.2 "Reverse Sublimation" Released | parrotcode.org/ | 18/672 new/open tix | logged in irclog.perlgeek.de/parrot/today
Set by moderator on 24 May 2008.
00:01 cognominal joined 00:04 Zaba_ joined 00:10 AndyA joined 00:52 bacek joined 00:55 teknomunk joined
nopaste "bacek" at 202.7.166.169 pasted "Diff for t/spectest_regression.data with 10 more passing tests (for pmichaud to commit :)" (39 lines) at nopaste.snit.ch/13128 01:11
bacek #perl6? 01:16
purl?
kid51 purl quit about an hour and a half ago with no explanation! 01:28
bacek drinking with Bender? 01:30
01:33 tetragon joined
particle bacek: i have map.rakudo failing 59-60, but i'm applying the rest 01:52
dalek r27974 | particle++ | trunk: 01:53
: [rakudo] add 9 more passing test files to spectest_regression (bacek++)
diff: www.parrotvm.org/svn/parrot/revision?rev=27974
bacek particle, hmm. 01:59
ok 59 # TODO unspecced - mutating $_ in map works (1) 02:00
ok 60 # TODO unspecced - mutating $_ in map works (2)
particle, it should works... 02:05
02:08 braceta joined 02:19 jimk joined 02:29 purl joined 02:32 Ademan joined 02:44 Theory joined 02:48 kid51 joined
japhb OK, things look quiet around here, and I've gotten signoff on the big OpenGL patch from Win32, Mac OS X, and Linux. 02:54
I'm preparing to do the big commit now, unless someone has an objection.
dalek r27975 | japhb++ | trunk: 03:03
: [OpenGL] First cut of parsing OpenGL headers
: Dynamically generate config/gen/call_list/opengl.in
: and runtime/parrot/library/OpenGL_funcs.pir using
: system OpenGL headers. Remove hardcoded equivalents.
diff: www.parrotvm.org/svn/parrot/revision?rev=27975
r27976 | japhb++ | trunk:
: [OpenGL] Win32/MSVC support; platform support docs
: * Add platform support/portability docs to config/auto/opengl.pm
: * Add comments explaining OpenGL portability knobs to various files
: * Support OpenGL on Win32/MSVC, thanks to (Ron Blaschke)++
diff: www.parrotvm.org/svn/parrot/revision?rev=27976
r27977 | japhb++ | trunk:
: [OpenGL] 'make clean' versus 'make realclean' fixes
: * Change call_list.txt deletion from 'clean' to 'realclean'
: * Add 'realclean' deletions for new OpenGL generated files
diff: www.parrotvm.org/svn/parrot/revision?rev=27977
r27978 | japhb++ | trunk:
: [OpenGL] Bring config/gen/opengl.pm docs up to date
: * Add items for newly generated files to gen files list
: * Point to config/auto/opengl.pm for platform support docs
diff: www.parrotvm.org/svn/parrot/revision?rev=27978
r27979 | japhb++ | trunk:
: [OpenGL] Fix braino in Win32/MSVC support
: * Forgot to add '/gl/*.h' to Win32 include globs
diff: www.parrotvm.org/svn/parrot/revision?rev=27979
r27980 | japhb++ | trunk:
: [OpenGL] Fixing patch to not confuse normal SVN
: * Unmangle SVN Id line
diff: www.parrotvm.org/svn/parrot/revision?rev=27980
r27981 | japhb++ | trunk:
: [OpenGL] Further Win32/MSVC portability fixes
: * Standardize on uppercase for Win32 env var names
: * Search both <path>/*.h and <path>/gl/*.h on Win32
: * Force / for path separator
: * Ignore empty include paths
: * Switch to File::Glob::bsd_glob() for space safe globbing
diff: www.parrotvm.org/svn/parrot/revision?rev=27981
r27982 | japhb++ | trunk:
: [OpenGL] More Win32/MSVC porting
: * Narrow scope of system headers read for Win32
: * For now, workaround wchar_t by mapping it as void
diff: www.parrotvm.org/svn/parrot/revision?rev=27982
kid51 must sleep 03:07
purl $kid51->sleep(8 * 3600);
03:10 bacek joined
dalek r27983 | japhb++ | trunk: 03:18
: [OpenGL] Setting svn:ignore for generated files
diff: www.parrotvm.org/svn/parrot/revision?rev=27983
r27984 | japhb++ | trunk: 03:19
: [OpenGL] Updating MANIFEST.SKIP
diff: www.parrotvm.org/svn/parrot/revision?rev=27984 03:20
03:40 bacek joined
tetragon Triangle spins on OS X 10.5 (ppc) 03:40
japhb wheee 03:46
I am *so* happy to have that merged 03:47
git++ # Utterly painless local branches
I'm already getting to love that feature
The merge is way saner than SVK, too. 03:48
03:49 Theory joined
cotto_home looks like something broke 03:53
nopaste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl somebody said nopaste was 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 or App::Nopaste or tools/dev/nopaste.pl
nopaste "cotto_home" at 75.92.237.130 pasted "OpenGL brokenness on Linux/x86" (12 lines) at nopaste.snit.ch/13129 03:54
japhb checking ...
WTF? Who puts command lines in a header file? 03:55
OK, give me a couple minutes to kill this.
cotto_home: can you email me a tarball of your /usr/include/GL/ ? 03:56
cotto_home it looks like the triangle still spins, though 03:57
japhb yeah, those were warnings, not errors 03:58
cotto_home sure. where to?
japhb but I'd like to be warning-free
japhb?
purl it has been said that japhb is Geoffrey Broadwell, mailto:geoff@broadwell.org
04:01 silug joined
japhb wants to go back in time and shake K&R vigorously: "STOP BEING SO SLIPPERY ABOUT SIZED TYPES!" 04:03
cotto_home sorry for the delay. My mail server's being uncharacteristically slow. 04:04
japhb np
I'm trying to find a sane definition of 'size_t', and all I'm getting is insanity or begging the question. 04:05
I'm about to just call it a 'long' and go on with my day.
FINALLY found it -- it's 'unsigned long' 04:12
cotto_home: mail still not getting through? 04:16
Tene japhb: what is merge like in svk?
japhb Tene: well, for one thing, it sometimes thinks the entire file has changed when someone else commits your patch (without changes), and you try to sync up again. git notices that all the changes are to the exact same content, and drops the local patch. 04:18
Secondarily, I don't know if it doesn't exist in SVK, or I never found it, but git wins many points by doing the right thing WRT 'git rebase' 04:19
I'm just finding in general that (aside from sheer number of the git options), working with git has been pretty painless, mostly "oh hey, that's cool!" moments. 04:20
Tene nods.
japhb SVK was more of "this sucks less than SVN, and disconnected operation is nice" but not truly painless. (Though clearly clkao had tried to add defaulting to make things more self-obvious, IMHO the git guys have done a better job of this in most instances.) 04:22
spinclad they've had a long time, and good hackers, to tune it on the kernel tree 04:24
dalek r27985 | chromatic++ | trunk: 04:26
: [src] Added documentation for all undocumented functions.
: Fixed some minor typos.
: Tidied the code slightly.
diff: www.parrotvm.org/svn/parrot/revision?rev=27985
Tene I'll be traveling again this week, so looks like I'll have time for cardinal again. 04:27
I'm also starting work on a smalltalk grammar.
04:28 tetragon joined
Tene Wasn't parsing, though, so I'll try it again while awake, and if that doesn't work, I'll try it with caffeine. 04:28
japhb Tene++
spinclad: nodnod
spinclad: and large numbers of highly motivated good hackers makes a big difference, no matter how good a single hacker is. 04:29
Tene: I find the best caffeine is dark chocolate.
caffeine + endorphins + random good-for-you chemicals + tastes good = mmmmmm.... 04:30
ank = coronary thrombosis? 04:32
spinclad Tene: name of squawk? 04:33
japhb ank: don't think so. 70+% cacao dark chocolate is even IIRC diabetic-safe
I've heard doctors recommend 1-2 oz per day of 70+% dark chocolate. Sorta like that "glass of red wine" thing. I just prefer chocolate over wine. 04:34
tetragon Unfortunately the chocolate I like is a bit on the expensive side 04:35
japhb tetragon: what's your chosen brand?
tetragon (Tends to run $8.25/100g)
cotto_home I wonder if nutella counts
tetragon japhb: Soma. It's a local chocolatier 04:36
japhb tetragon: right now I like Valrhona (sp?) and El Rey -- the latter costs half the former, and I tend to like it more. There's also a fantastic one I found from a single plantation in South America (Columbia?) but I've forgotten the brand and can't find it anymore. :-( 04:37
tetragon japhb: www.somachocolate.com
ank nice 04:38
i tried some 85% lindt one a few months ago
i've never had anything like that before 04:39
tetragon japhb: Another local brand I like is ChocoSol
japhb tetragon: Ah, Toronto. Hmmm, I wonder if I can get that through a local retailer ... Whole Foods might carry it, I guess.
tetragon www.chocosoltraders.com/
japhb Soma's home page image is a pretty awesome collage 04:40
tetragon The ChocoSol varieties tend less towards the traditional fine chocolate and more towards rustic
japhb NICE: www.chocosoltraders.com/ingredients.html
If there is any particular place in the world I want to visit, I think Oaxaca is in the top 3. Hard to beat the art and chocolate. 04:41
tetragon Their Oxaca Crunch is good 04:42
And they're where I first tried raw cacao 04:44
japhb How did you like it? 04:45
tetragon Like what? I stayed in Toronto. Oaxaca Cruch is one of the chocolate varieties 04:46
japhb tetragon: raw cacao 04:47
dalek r27986 | japhb++ | trunk:
: [OpenGL] Mesa headers compatibility
: * Fix a couple warnings in Mesa headers for cotto_home++
: * Still one such warning unfixed
diff: www.parrotvm.org/svn/parrot/revision?rev=27986
tetragon It tasted a bit like chocolate-flavoured dirt 04:48
japhb cotto_home: r27986 should fix 2/3 of your Configure warnings. As soon as I get your header tarball, I'll work on a clean fix for the last one (the inline shell code)
tetragon: heh
tetragon japhb: They've worked on their raw chocolates so that they don't taste like dirt (the earlier batches did) 04:49
japhb nodnod
tetragon Although for really good hot chocolate, I'd have to go with Soma 04:50
It's like drinking molten chocolate
(which it mostly is) 04:51
japhb tetragon: there was a place around 2 hours south of here that had amazing hot chocolate -- like 5 different varieties, my favorite of which had that "molten chocolate" think, plus lots of distinct spicings. 04:52
Wonder if it's still there
s/think/thing
tetragon As for chocolate that I can buy from the grocery store: www.cocoacamino.com/en/index.php
cotto_home japhb, you should have it soon, if not now 04:55
s/it/them/
japhb cotto_home: not quite yet, but my mail server pulls from upstream, rather than accepting pushes, so there's a 60-second delay built in
tetragon really wants chocolate now 04:56
pmichaud christmas chocolate?
japhb tetragon: /me cheated, and ate some of my chocolate before starting this thread. ;-)
cotto_home looks better. japhb++ 04:57
and after looking at that mess, japhb++ again 04:59
japhb Which mess?
The header?
purl The header is 'Referer:'
japhb purl, forget the header
purl japhb: I forgot header
tetragon cotto_home: It couldn't have been worse than the OS X headers, could it? 05:00
cotto_home I wouldn't know 05:01
dalek r27987 | chromatic++ | trunk:
: [tools] Made c2str stop lying about how long constant strings are in C source
: code. Now they're correct in the generated src/string_private_cstring.h.
japhb cotto_home: trust me, the OS X headers were nuts.
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=27987
japhb cotto_home: though, after just spelunking through some of the gcc-internal headers, I'm finding a whole new definition of "nuts" 05:02
tetragon japhb: I just noticed the OS X headers refered to a header I didn't send you, AvailabilityMacros.h. I just found it in /usr/include 05:05
japhb That's the thing that filled in the "AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER", I assume ...?
tetragon Yes 05:06
And what would be filled in depended upon OS X version
Full of #if statements enclosing things like #define AVAILABLE_MAC_OS_X_VERSION_10_4_AND_LATER_BUT_DEPRECATED_IN_MAC_OS_X
_VERSION_10_5 DEPRECATED_ATTRIBUTE
japhb I just filtered that stuff out as noise. 05:07
tetragon notices that some of those macro names are over 80 characters
So, no handling of deprecation or of limiting based upon what the target environment is? 05:08
japhb At this point, it really doesn't help us to be anal about matching Apple's deprecations. Worst that happens is that one of our users manages to use a deprecated CGL API or something, and I don't think it's really our job to police that.
Mind you, in code we ship, we should avoid using deprecated APIs (if we can), but we shouldn't prevent our *users* from making that decision on their own. 05:09
So if it's declared in a header, I wrap it.
cotto_home: oddly, your mail still has not arrived. 05:10
Is Mac OS X 10.4 always 32-bit? Or is there a 64-bit 10.4? 05:14
tetragon IIRC, the core of OS X 10.4 is always 32-bit 05:15
Userland may vary
japhb tetragon: OK, thanks.
tetragon doesn't have a 64-bit box handy
dalek r27988 | chromatic++ | trunk:
: [src] Made string_init() construct constant string table entries directly,
: bypassing const_string() (for which I have big plans) and using the now-correct
: string lengths from src/string_private_cstring.h.
diff: www.parrotvm.org/svn/parrot/revision?rev=27988
r27989 | japhb++ | trunk: 05:24
: [OpenGL] Comment on Mac OS X 10.4 typedef weirdness
: * Add comment to config/gen/opengl.pm explaining both that:
japhb cotto_home: tarball received, thanks
dalek : + Mac OS X 10.4 disagrees with everyone else about some typedefs, and
: + This doesn't actually matter (and was fixed in 10.5), so is ignored
diff: www.parrotvm.org/svn/parrot/revision?rev=27989
japhb cotto_home: what's your OS? 05:26
tetragon japhb: developer.apple.com/macosx/64bit.html 05:27
japhb tetragon++ # Always quick with the Apple docs 05:32
Interestingly, the one place that that page explicitly said 64-bit code *doesn't* work is for GUI code. But they don't bother to specify if OpenGL is part of that. I guess I have to assume so. And it looks like 10.4 only has any 64-bit on PPC. 05:33
PPC G5, to be precise 05:34
tetragon I think the original version of that doc was written before the Intel Macs came out
japhb Anyone have a PPC G5 or 64-bit Intel Mac running Mac OS X 10.4? kid51 has 10.4/PPC, but didn't specify which processor. 05:35
tetragon I think his is a laptop, which would make it 32-bit
And none of my home machines are 64-bit 05:36
dalek r27990 | chromatic++ | trunk:
: [JIT] Cleaned up warnings in x86 JIT (NotFound, RT #55134).
diff: www.parrotvm.org/svn/parrot/revision?rev=27990
japhb tetragon: damn, I think that's a hole in our testing
'our' == parrot in general 05:37
tetragon I just ran the file command on OpenGL on my 10.4 box 05:41
It only reported 32-bit libraries, unlike on my 10.5 box
japhb tetragon: nodnod. That matches other evidence. 05:42
tetragon And "make -j4" falls over on my dual-core Intel
japhb Something GL-related? 05:43
tetragon Nope, src/builtin.c
japhb (There is one known GL dependency issue, but I'm not sure about the best place to fix it) 05:44
tetragon The one where the glut callbacks depend upon libparrot?
Or is this the error handling one
japhb tetragon: I thought Ron's fixes cleared up those ... or maybe they just made things "better" but not "right" 05:45
cotto_home japhb, Debian Linux on x86
japhb I was talking about the fact that runtime/parrot/library/OpenGL.pbc depends on both OpenGL.pir and OpenGL_funcs.pir 05:46
tetragon I'll need to try another build without -undefined dynamic_lookup at some point
japhb ... But there's also the problem that a LOT of those library .pbc's depend on includes in runtime/parrot/include/, and as far as I can tell none of those dependencies are declared. 05:47
tetragon But from what I see in the Makefile, the libparrot thing does appear to have been dealt with
japhb cotto_home: Using pure Mesa? Or vendor GL layered on top of system Mesa?
.oO( 'make realclean; perl Configure.pl; make; make test' can be annoyingly slow at times ... )
 05:52
dalek r27991 | japhb++ | trunk: 05:56
: [OpenGL] Ignore Mesa API-mangling headers
: * Ignore Mesa's {gl,glu,glx}_mangle.h, used for loading both
: a vendor GL and Mesa at the same time. For now we don't
: support this, and the headers confuse the header parser.
diff: www.parrotvm.org/svn/parrot/revision?rev=27991
japhb cotto_home: r27991 should leave your Configure warnings-free
cotto_home you mean pure software? no
japhb cotto_home: I meant, as opposed to having Mesa headers and, say, nvidia drivers 05:57
cotto_home r27991 works. thanks
japhb cotto_home: Mind if I feed your platform info to the bot?
cotto_home I'm using Intel's 3d drivers 05:58
nope
japhb cotto_home: done 05:59
cotto_home: Intel, eh? Cool ... can you send me output from 'glxinfo' and 'lshw' (or equivalent)? I'd like to know what I'm up against in supporting more advanced OpenGL stuff on Intel GPUs. 06:02
dalek r27992 | chromatic++ | trunk:
: [src] Cleaned up find_exception_handler() function (NotFound, RT #55114).
diff: www.parrotvm.org/svn/parrot/revision?rev=27992
cotto_home just a sec 06:03
japhb thanks muchly.
cotto_home nopaste? 06:04
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl nopaste is probably 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 or App::Nopaste or tools/dev/nopaste.pl
japhb tetragon: For that matter, what GPUs do you have?
nopaste "cotto_home" at 75.92.237.130 pasted "glxinfo output" (85 lines) at nopaste.snit.ch/13130
japhb cotto_home: interesting, server glx is 1.2 06:07
nopaste "cotto_home" at 75.92.237.130 pasted "lshw output" (525 lines) at nopaste.snit.ch/13131
japhb Oh, now *that* is interesting:
OpenGL renderer string: Mesa DRI Intel(R) 945GM 20061017 x86/MMX/SSE2
OpenGL version string: 1.3 Mesa 7.0.3
OK, I thought I would have only the Voodoo (and similar era) cards stuck at 1.3, but it looks like even the 945GM is stuck there ... at least, with Mesa 7.0. 06:09
Anyone know if nopaste.snit.ch pastes are permanent, or temporary? 06:11
cotto_home they're temporary 06:12
japhb cotto_home: for how long?
cotto_home idk
japhb k
cotto_home I can send you the files if it'd make life easier 06:13
japhb cotto_home: yeah, please, if it's not too much trouble. The pastes give me stuff to think about, but I'll want to keep permanent copies. 06:14
japhb goes back to reviewing glxinfo output ...
Oh good, stencil-enabled visuals. My next example program would have been hamstrung without that. 06:15
cotto_home done 06:16
japhb thx again
cotto_home++ tetragon++ # Very helpful 06:17
cotto_home thanks for working to improve Parrot 06:18
japhb My pleasure. Truly,.
s/,// 06:19
06:19 AndyA joined 06:20 barney joined 06:49 cognominal joined
nopaste "bacek" at 202.7.166.164 pasted "Summon pmichaud to fix Array.push with no args" (11 lines) at nopaste.snit.ch/13132 06:53
pmichaud ....pong 06:57
(applied, testing)
bacek got "summoning skill" +2 06:58
:)
07:01 mire joined
bacek pmichaud, I can fudge last test in S29-array/push.t. Then we can add it to regression 07:02
pmichaud S29-num/complex.t just failed
oh, it looks like a -G issue 07:03
bacek pmichaud, what is '-G'? 07:04
pmichaud -G turns off Parrot's garbage collection 07:05
dalek r27993 | pmichaud++ | trunk:
: [rakudo]:
: * Fix Array.push() to work with empty argument lists. (bacek++)
: * While we're here, might as well fix Array.delete, Array.exists,
: Array.unshift too.
diff: www.parrotvm.org/svn/parrot/revision?rev=27993
pmichaud somewhere in Parrot there's a bug that causes segmentation faults. Adding the -G option seems to make this go away.
(So we suspect it's a bug in the garbage collector)
bacek pmichaud, gc in parrot is really bad... 07:06
pmichaud we know. Fortunately there are a couple of people working on that :-)
bacek any progress?
pmichaud I haven't been following it that closely :-) 07:07
bacek pmichaud, is very strange... Array.unshift works with '_' in signature... 07:08
s/is/it is/
pmichaud Array unshift with no arguments works? 07:09
bacek yes...
oops. 07:10
07:10 iblechbot joined
bacek no.. bots on #perl6 updated too fast 07:11
It doesn't
... works with _ :)
pmichaud anyway, it's fixed now? 07:12
bacek pmichaud, yes 07:13
S29-array/unshift.t can be added to regression
dalek r27994 | chromatic++ | trunk: 07:14
: [config] Removed GCC warnings when compiling with g++ (NotFound, RT #55050).
: All config tests still pass.
diff: www.parrotvm.org/svn/parrot/revision?rev=27994
nopaste "bacek" at 202.7.166.166 pasted "proposal to fudge on test in array/push.t" (10 lines) at nopaste.snit.ch/13133 07:15
bacek pmichaud, nopaste.snit.ch/13133 is bad or good idea?
pmichaud (fudge test) +1
bacek ok
so S29-array/push.t can be added to regression now :) 07:16
pmichaud testing. 07:17
purl i think testing is Don't use #perl for testing! or experiri vovere est or make tests pass for existing features, fail for unimplemented features and skip for wishlist features
bacek purl, you back! How is your drink party with Bender? 07:18
purl bugger all, i dunno, bacek
dalek r27995 | pmichaud++ | trunk: 07:23
: [rakudo]:
: * Add two more spectest files to spectest_regression (bacek++)
diff: www.parrotvm.org/svn/parrot/revision?rev=27995
bacek Files=54, Tests=994
pmichaud time for sleep.
woo hoo! 6 more to go to reach 1000! 07:24
bacek++
dalek r27996 | chromatic++ | trunk: 07:25
: [src] Removed unused intlist_dump() and LIST_DEBUG (NotFound, RT #55012).
diff: www.parrotvm.org/svn/parrot/revision?rev=27996
pmichaud afk -- sleep.
bacek pmichaud, I'll try to find some more passing tests.
pmichaud, and good night!
dalek r27997 | chromatic++ | trunk: 07:35
: [spec] Added runtime/ files to RPM packages (Gerd Pokorra, RT #54836).
diff: www.parrotvm.org/svn/parrot/revision?rev=27997
r27998 | chromatic++ | trunk: 07:41
: [PIR] Fixed language building for recent PGE changes (Moritz Lenz, RT #54182).
diff: www.parrotvm.org/svn/parrot/revision?rev=27998
bacek moritz++ 07:44
karma moritz
purl moritz has karma of 39
bacek karma bacek
purl bacek has karma of 27
dalek r27999 | chromatic++ | trunk: 08:11
: [config] Added exec core building to Makefile only for platforms where it works
: (i386). See RT #47289 -- this shouldn't break PPC, for example.
diff: www.parrotvm.org/svn/parrot/revision?rev=27999 08:12
r28000 | chromatic++ | trunk: 08:14
: [docs] Updated PIR PDD 19 to reflect changes in empty namespace declaration
: (Andrew Whitworth, RT #54942).
diff: www.parrotvm.org/svn/parrot/revision?rev=28000
08:30 tetragon joined
dalek r28001 | chromatic++ | trunk: 08:31
: [dynops] Made the hcf dynop call abort() instead of trying to write a testable,
: portable segfault (see RT #52222, Seneca Cunningham).
diff: www.parrotvm.org/svn/parrot/revision?rev=28001
r28002 | chromatic++ | trunk: 09:08
: [config] Updated Cygwin docs to mention MSWin32 Perl problems.
: Improved Configure error when forgetting to update path.
: (Ronald Schmidt, RT #54780).
diff: www.parrotvm.org/svn/parrot/revision?rev=28002
09:12 Zaba joined 09:22 masak joined
nopaste "masak" at 130.238.45.242 pasted "Something wrong with $_ today" (12 lines) at nopaste.snit.ch/13134 09:36
masak kinda strange error 09:37
why does $_ expect a parameter?
bacek masak, it's not from '$_' 09:52
masak it occurs in connection with it
bacek Yes, it's 'connected to $_'. But it just bug in producing PIR. 09:55
NotFound Someone knows why instead of including readline.h the functions readline and add_history are hand-declared?
masak bacek: is it fixable?
bacek masak, dunno right now 09:56
masak, actually this code doesn't looks right for me. 09:57
masak which code?
bacek masak, your sample... But I can be wrong. 09:58
masak I hope so
what do you consider wrong about it? 09:59
10:16 AndyA joined
dalek r28003 | chromatic++ | trunk: 10:23
: [config] Fixed some typos and tidied the root makefile template slightly.
diff: www.parrotvm.org/svn/parrot/revision?rev=28003
10:24 ank joined
dalek r28004 | chromatic++ | trunk: 10:26
: [lib] Allowed CONST_STRING in dynpmcs, so that core PMCs can use more
: CONST_STRING in autogenerated code.
diff: www.parrotvm.org/svn/parrot/revision?rev=28004
16:39 ilbot2 joined
moderator Parrot 0.6.2 "Reverse Sublimation" Released | parrotcode.org/ | 18/672 new/open tix | logged in irclog.perlgeek.de/parrot/today
16:41 moritz joined 16:45 avar joined 16:53 gmansi joined
NotFound Given that PIO_printf and PIO_eprintf don't use PIOs in his interface and that are general purpose, will not be better to rename them as Parrot_printf and move his declarations to embed.h ? 17:03
17:14 bacek joined 17:19 Theory joined
moritz uhm, I get a segfault in rakudo while running t/spec/S29-array/push.rakudo 17:19
17:23 nemesys joined
NotFound moritz: can't reproduce here. 17:29
17:30 Ivatar joined
NotFound Works both with parrot perl6.pbc and with ./perl6 17:31
moritz valgrind reports some noise 17:32
NotFound Will try with a c++ build. 17:35
moritz ==21724== ERROR SUMMARY: 182558 errors from 73 contexts (suppressed: 61 from 1)
NotFound Same result winth c++ build. 17:40
Linux i386
Uh, I was not updated, retesting. 17:41
17:44 masak joined
NotFound Same result, no segfault. 17:46
moritz I tried to reduce the test file, which of course made the bug go away
NotFound Will try with gcdebug core, but may take ages to finish ;) 17:47
Adding a --runcore option to perl6 executable will be nice. 17:48
moritz NotFound: I have a reduced test cases that fails with runcode=gcdebug 17:51
NotFound: nopaste.snit.ch/13136 produces an assertions failure for me 17:52
called as ../../parrot --runcore=gcdebug perl6.pbc push.rakudo
NotFound Trying... 17:54
purl succeeding.
masak purl: you sure talk a lot 17:55
purl masak: what?
moritz purl: forget trying 17:56
purl moritz: I forgot trying
masak 'the little bot who forgot to try'
17:56 braceta joined
NotFound Maybe is a Jedi knight. 17:57
masak Maybe?
how do I run the rakudo test suite?
`prove t/` doesn't seem to cut it :) 17:58
Zaba_ make test
purl More like "make fail"
masak Zaba_: thx
moritz make test spectest_regression
masak purl: forget make test
purl masak: I forgot make test
moritz the segfault happens in the latter 17:59
masak moritz: ok
NotFound Many people forget that.
masak :)
17:59 cognominal joined
moritz tries to reduce the test even more 18:00
masak whoa!? did it just stop by the pugs repo and got me a few more tests? 18:01
moritz masak: it fetches all test from t/spec/* and runs some of them
NotFound moritz: it's still running.
Well, stepping, better say.
moritz NotFound: takes a few minutes ;)
masak it's nice to see so many tests actually passing 18:02
moritz some of them are actually fudged ;) 18:03
masak though my adventures with rakudo often quickly run up against things that ought to be a failing test
moritz: meaning that they are hidden?
moritz: all tests successful here
moritz masak: yes, they aren't executed, mostly because they are parse failures 18:04
masak ah
NotFound It's a good cpu test executing something non-minimal with the gcdebug core.
moritz I reduced the test to:
use v6;
my @push = ();
say +@push;
NotFound Failed! 18:05
src/string.c:514: failed assertion '!PObj_on_free_list_TEST(a)'
moritz same here
bug report sent
NotFound moritz: mine is a g++ build. 18:06
masak hm, when I run it in parrot perl6.pbc, I get "Scope not found for PAST::Var '@push'"
is that the same error? 18:07
moritz masak: the interactive thing doesn't really work
Tene pmichaud: ping
NotFound Will try now the re-reduced version.
masak ok :)
moritz masak: you have to put the statements on one single line in the interactive blah
masak yuck 18:08
though when I do that, everything's fine
and directly from cmd line too 18:09
did you say the bug is compiler-specific?
NotFound Not very fast, anyway.
moritz masak: it seems to be a garbage collector bug
masak in parrot?
purl hmmm... in parrot is false.
moritz yes
NotFound masak: looks like not, given that fails same way building with C and with C++ 18:10
masak maybe I need to remake
moritz masak: the reduced test only fails for me when I run parrot with --runcore=gcdebug
masak oh 18:11
moritz masak: ..after 3 minutes execution time ;)
NotFound masak: it does not fail for unless I use the gcdbeug core.
masak pray tell, what is this gcdebug core?
seems it is neither fast nor safe to use :)
NotFound masak: the gcdebug core makes a full gc after each opcode.
masak haha 18:12
NotFound So it's no exactly very fast.
But helps reproduce bugs.
There's a chromatic's article in perl.com about it. 18:13
masak you should use some Monte Carlo method to randomly add and remove GCs between each opcode, keeping the ones that go wrong
but favoring minimal sets 18:14
moritz or just an option to run GC after each $n opcodes
NotFound A Las Vegas method will be more enlighten X-)
masak :)
moritz bug report is [perl #55164] 18:15
NotFound Same stacktrace with the reduced case. 18:16
moritz aye
you can also remove the 'use v6;'
which seems to be a no-op anyway
masak does it produce opcodes? otherwise, it doesn't matter 18:17
yup, it spat out the failed assertion here too
moritz wonders if there is a way to execute the compilation with normal runcore, and only the execution wih the gcdebug runcore 18:19
masak moritz: oh. I'm starting to realize what took time now...
NotFound moritz: probably to add a --runcore option to the executable will be simpler.
japhb moritz: output to .pir, and then run that manually? 18:21
moritz japhb: the generated pir doesn't run
Class 'Perl6Array' not found
japhb moritz: eww 18:22
moritz so it seems to need some libraries, and I don't know how to include them
japhb Actually, I think that may be a valid RT -- when PCT is told to output to .pir, either that .pir should be directly runnable, or there should at least be an option to output the .pir with runtime setup included so that it *will* directly run. 18:23
moritz japhb: there's already a ticket for that 18:26
japhb: don't know its status, though
jhorwitz moritz: try adding this to your generated PIR: load_bytecode '/path/to/parrot/languages/perl6/perl6.pbc' 18:30
moritz jhorwitz: error:imcc:syntax error, unexpected PARROT_OP, expecting $end ('load_bytecode') 18:33
jhorwitz paste the PIR?
moritz load_bytecode '/home/moritz/src/parrot/languages/perl6/perl6.pbc'
as the first line in the file 18:34
jhorwitz ah
18:34 paco joined
moritz does it need to be inside a namespace, sub or whatever? 18:34
jhorwitz throw it in a sub w/ :init :load 18:35
moritz jhorwitz: thanks, that works 18:36
... and doesn't produce ane error with gcdebug anymore 18:37
jhorwitz excellent 18:38
masak but strange
moritz it's not excellent, because it means debugging is much harder
NotFound moritz: agree.
jhorwitz oh i see
kinda like when buggy code works in gdb. :-P 18:39
NotFound As some tickets say, it must be the old gc problem manifesting again.
masak is there a way to compile but not run using gcdebug?
moritz masak: try ../../parrot --runcore=debug perl6.pbc -c $file 18:40
masak let's hope that variant breaks in the same way
jhorwitz afk &
masak i.e. that the error is in the compilation phase, and not an interaction between compilation and runtime
moritz $ ../../parrot --runcore=gcdebug perl6.pbc -c push.rakudo 18:44
syntax OK
pmichaud kid51++ jkeenan++ # changing code_tests to codetest 18:53
18:53 masak` joined
masak` it compiles ok :/ 18:53
moritz: so the GC problem requires both compilation and running to manifest 18:54
18:54 bacek joined 18:55 paco joined
moritz masak`: seems like, yes 18:56
masak` (whoever finally solves it)++ 18:57
pmichaud (gc problem) switching runcores in the middle probably doesn't help find a gc bug, because gc bugs are very dependent on the order of execution
i.e., even changing a single instruction is often enough to make the evidence of the bug disappear 18:58
NotFound That's why gcdebug is so useful.
pmichaud correct. 18:59
slow, but useful.
actually, "slow" doesn't describe it well. Excruciatingly slow. Feels like working on geologic timescales :-)
moritz pmichaud: do you think an option to executed GC only each $N opcodes would be helpful? 19:00
19:00 Zaba joined
pmichaud moritz: I don't know enough about parrot internals to know for sure. 19:00
NotFound Yes, but the solution is to have a more robust gc, in order to not have to use it frequently.
moritz NotFound: ah right. Go ahead and implement it... (/me ducks very deep) 19:01
NotFound moritz: I think an option to not use it until n opcodes executed will be useful.
masak` plus a script that does binary search on the exact point of error 19:02
NotFound That way one can try several n values in each case.
masak`: binary search if fast enough to do it by hand. 19:03
masak` NotFound: not sure I parsed that. 19:04
NotFound masak`: I think there is no need for the script in the majority of usages.
tetragon Ick, t/pmc/exception.t started failing recently on my box (no segfault/sigbus)
moritz if you want good binary search, used gi + git-svn 19:05
masak` NotFound: you may be right
time to go home and plug in the laptop
pmichaud (standalone PIR) I worked on getting pir-output modules to run standalone last night, but got too tired to finish. 19:07
however, I don't think they'll be useful for gc debugging, since it's another case of the sequence of operations changing to hide the bug
Tene pmichaud: I have a question about interactive execution. 19:09
NotFound pmichaud: I think most gc bugs are hidden because after a few opcodes the offending vars are reused, in that case will be useful. But I don't have any evidence, just a thought.
Tene pmichaud: actions.pm currently uses @?BLOCK to keep track of symbol tables and such, and a few other similar tricks. That environment isn't available after compilation ends. Is there a plan to fix this such that interactive mode can actually work? 19:11
pmichaud Tene: That's not really the problem.
by the time a program is running, @?BLOCK may be long gone
(e.g., imagine the case where we compile to .pir and then run the .pir
)
in interactive mode, we need to be able to execute code that modifies the current lexical environment 19:12
but Parrot isn't really set up for that, since lexical scopes are tied to .sub, and the smallest unit of execution we have is a .sub
Tene pmichaud: So the actions.pm stage needs to be able to look things up in the current lexical environment, then? 19:13
pmichaud partially. But consider this:
if I do: my @past = ();
when compiled, it acts as if I had done
{ my @past = () }
Tene Right.
pmichaud (because the statement has to be in a sub) 19:14
which means that the @past variable was local to that one interactive line
so we have to have a way for interactive mode to be able to propagate the lexicals it defined into its outer environment
Tene Yes, I understand that problem.
pmichaud to me that's the fundamental blocker at the moment.
Tene I'm more referring to the fact that "say $a" doesn't do a lookup in the lexical environment, it looks at $?BLOCK, which won't exist anymore. 19:16
pmichaud uh, that's not correct.
say $a does do a lookup in the lexical environment
find_lex $P17, "$a" 19:17
$P18 = "say"($P17)
oh, if you mean the process of compiling say $a doesn't have $a defined.... you're correct. But that's a very fixable problem.
Tene In the compilation stage. actions.pm:1572
pmichaud I'm not worried about that. 19:18
Tene Okay.
pmichaud we'll just pass the current lexical environment to the compiler, and the compiler can check for lexical variables when one isn't defined in $?BLOCK
Tene Clever.
pmichaud so that's not the hard issue in my eyes :-) 19:19
Tene Okay, thanks.
I didn't think it was the most significant issue, just wondering if you had a solution planned yet.
pmichaud I do now. :-P
but I knew I could solve that problem so hadn't thought about it. The "propagate lexicals to another scope" is trickier. 19:20
it may be that we'll have a special flag that we pass to the compiler that tells it to generate code to move the lexicals to the outer scope when finished.
Although I don't know if Parrot yet allows us to modify another sub's lexical table. 19:21
at any rate, it hasn't been high on my list of things to solve just yet. Interactive mode is still a "nice to have" feature -- not a "gotta have". :-) 19:26
NotFound I've made a proof of concept implementation and it catches the bug.
paste?
clunker3 pasta.test-smoke.org/ or paste.husk.org/ or nopaste.snit.ch:8001/ or rafb.net/paste or poundperl.pastebin.com/ or paste.scsys.co.uk/
purl it has been said that paste is (see: nopaste) or like glue but a little safer to sniff. or nopaste.snit.ch:8001/ or scsys.co.uk:8001/ anywhere shadowpaste is or mmm, sticky paste or You there! Eating the paste. or <see> 2 girls, 1 paste
nopaste "NotFound" at 213.96.228.50 pasted "gcdebug N test" (35 lines) at nopaste.snit.ch/13138 19:28
NotFound PARROT_GCDEBUG_SKIP=85000 ../../parrot --runcore=gcdebug perl6.pbc testprog.p6 19:29
19:29 mire joined
moritz NotFound: testing now... 19:32
NotFound With the 85000 value, just a few seconds before fail. 19:35
85080 is almost exact. 19:38
moritz NotFound: your example (with 85000) didn't reproduce the error for me
NotFound: I'll try with different values
NotFound moritz: try a lower value.
moritz the run time seems strongly non-linear in PARROT_GCDEBUG_SKIP 19:40
NotFound Will build with C and retest. 19:41
Fails with 85082 19:44
moritz: the algorithm is simple, if it does not fail or finishes in a short time, break and try other value ;) 19:46
85084 is the exact point in my build. 19:53
moritz that seems build dependent
NotFound Strange. 19:54
purl But true.
moritz so it's a a nice way to identify GC bugs
but not good for really tracing them
anyway, nice patch
NotFound++
NotFound For tracing, aborting at that point may help. 19:55
Or run under debugger and setting a breakpoint when counter exhausts. 19:57
moritz that's actually a nice idea
20:00 bacek joined
NotFound Patch sended to the mailing list. 20:11
20:12 scrottie joined
scrottie Hi pmichaud >=) 20:13
pmichaud, thought I'd try to catch you active, re: the Larry Wall doll, but my clunky old irc-II client doesn't save messages and I'm heading out in a bit, so I'll catch you on email. cheers! I'm scott@slowass.net, by the way. 20:19
20:20 scrottie left
moritz btw the newly fudged S04-statements/try.t could be added to /spectest_regression.data 20:55
pmichaud moritz++
moritz S29-list/map.t also passes, but I wouldn't add that before clarifying if the last two tests are actually correct 20:59
if they aren't, they should test for the exact opposite
21:00 Theory joined 21:01 jan joined
moritz it's a bit frustrating that p6l seems to discuss various stuff that nobody implements atm, but simple stuff doesn't get answered 21:01
(ok, I sent this one to p6c, maybe I am to blame here)
21:02 donaldh joined
pmichaud what isn't being answered? I'll try to push it 21:03
I might have just overlooked it. Likely, given how code-focused I've been for the past week.
moritz the question if $_ is rw in a map block 21:04
pmichaud I think yes. Just a sec --
S02: You may add a trait argument of <rw> to allow called routines to modify your value. $_, $!, and $/ are context<rw> by default. 21:06
so, assuming that @array is rw, I'd presume that $_ in a map block would be rw as well (assuming the map block doesn't have a signature)
moritz so the 'rw' doesn't have to be in map's signature? 21:07
pmichaud you mean on the block argument? That would seem to make the block itself rw 21:08
moritz ah right
pmichaud map doesn't assign to the block (I don't think) -- it simply invokes the block with arguments
moritz pmichaud: thanks for the clarification, I'll correct the test 21:11
moritz changed 'svn up' to 'svn up || true' in his local makefile to have 'make spectest' working offline 21:18
pmichaud smart.
21:18 donaldh joined
pmichaud isn't there a character that can be put in front of a makefile line that says "ignore the result code?" 21:18
I think it's @ or + or something?
moritz dunno, my Makefile-fu is rather bad 21:19
pmichaud: sial.org/pbot/31176 21:22
21:23 Zaba_ joined
NotFound pmichaud: @ 21:23
Ops, no, this is to not echo the command. 21:24
pmichaud hyphen
spectest_regression:
-svn up 21:25
or, more precisely
-cd test && svn up
NotFound Yes, that is.
pmichaud ($_ in map block) Also, S04 says this about the 'for' statement: 21:28
If you rely on $_ as the implicit parameter to a block, then $_ is considered read/write by default. That is, the construct:
for @foo {...}
is actually short for:
for @foo <-> $_ {...}
so you can modify the current list element in that case.
so, I'd take it that bare blocks tend to treat $_ as rw
particle pmichaud: the makefile prefix char for nmake is ! iirc 21:30
moritz so it's incompatible? d'oh 21:31
particle @ is so it won't print 21:32
@echo 'foo' # prints 'foo', not "echo 'foo'\\nfoo" 21:33
oh, i see, -
no, i don't recognize that for nmake 21:34
pmichaud –[[number ]]command
Turns off error checking for the command. Spaces and tabs can appear
before the command. By default, NMAKE halts when any command returns
an error in the form of a nonzero exit code. This modifier tells NMAKE to
21:34 arbingersys joined
pmichaud ignore errors from the specified command. 21:34
particle that's microsoft nmake, and not at&t or bell or whatever? 21:35
pmichaud I'm pretty sure it is.
particle well, go ahead and try it
'course, win32 build is broken atm
pmichaud the PDF I took the above from was describing the Microsoft Program Maintenance Utility (NMAKE) 21:36
version 1.20.
particle ooh, that's damned old 21:37
but probably still accurate
pmichaud so it's likely available :-)
dalek r28018 | pmichaud++ | trunk:
: [rakudo]:
: * Add S04-statements/try.t to spectest_regression (moritz++)
particle Microsoft (R) Program Maintenance Utility Version 8.00.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
dalek diff: www.parrotvm.org/svn/parrot/revision?rev=28018
pmichaud rakudo spectest_regression: 55 test files, 1012 tests
is "1012 tests" the number of passing tests, or the number of tests including todo and skip ? 21:38
particle pmichaud: did you see that allison++ has added branchcc and return_branchcc for you to pdd25cx ?
pmichaud I did, yes!
that should be... interesting.
particle i figured it would make you happy :)
pmichaud well, the devil is in the details -- I have to actually try using it first. :-) 21:39
but as I reviewed my various exception handling code, the thought of having to create a separate sub to handle each exception was looking really nasty.
moritz pmichaud: I think fudged tests emit something like "ok $count - skip $reason", so they'll be counted as passing 21:40
particle i figured we'd write a library file with an exception handler generator or something
pmichaud that still seemed pretty icky. 21:41
particle well, anyway, there may not be a need
pmichaud that's what I'm hoping.
particle i've gotta go epoxy some bolts in cement &
japhb kinky 21:42
pmichaud moritz: you're correct, skipped tests count as passing tests. Wish we could fix that somehow.
moritz pmichaud: maybe just emit 'not ok # TODO' stuff? 21:43
pmichaud that might be nicer.
moritz it sounds like fudge could easily do that, but the only time I actually looked at its source I got scared off by too many local()s 21:44
maybe I just need to ignore that ;)
and hope that larry's code is so good that all my changes DWIM 21:45
nopaste "pmichaud" at 76.183.97.54 pasted "What's the purpose of eval here?" (13 lines) at nopaste.snit.ch/13140
pmichaud (from S04-statements/try.t) 21:46
moritz pmichaud: probably that the test won't exit if the implementation is faulty 21:47
pmichaud ....but we use #?rakudo skip for that now
or #?pugs skip or #?<impl> skip
and the whole point of a "try" block is to catch exceptions, including exits. :-)
moritz I have to admit that I fudged that file rather brainlessly 21:48
pmichaud well, I agree that the test needs fudging for Rakudo
I'm just thinking that there may be a lot of 'eval's that were done from before we had the ability to #?impl skip
and I'd like to get rid of those. :-)
moritz I didn't even check if CATCH blocks should work inside or outside the try { ... }, because I hoped that the one who moved it to t/spec/ checked it ;) 21:49
pmichaud inside.
that way the CATCH block has access to the try block's lexicals.
moritz seems logical ;)
how well does eval() work in rakudo? 21:50
pmichaud okay, as long as you aren't trying to access outer-scoped lexicals.
my $a; eval "$a = 4"; # won't work.
moritz t/spec/S29-num/pi.t looks like much fun 21:51
#?rakudo 6 skip 'eval not implemented'
is_approx((eval("Num::pi "), $PI), "Num::pi");
pmichaud unless Num::pi is being declared locally in the test, I don't think we need eval there. 21:52
moritz aye
pmichaud i.e.: is_approx(Num::pi, $PI, "Num::pi") should be sufficient.
moritz that's one of the cases you mentioned
> say Num::pi 21:53
[oops; continuation 0xb64b97a0 of type 22 is trying to jump from runloop 274 to runloop 50]
Null PMC access in clone()
pmichaud oh, that's interesting.
aha, old artifact. 21:55
fixing.
moritz should type names propate from eval to the outside? 21:56
pmichaud example?
moritz mx $x = eval 'class A { }; A.new()"; say $x.WHAT 21:57
21:57 Zaba joined
pmichaud no, eval has its own lexical scope 21:57
eval 'my $a = 3;'; does not give the outer scope a lexical $a
at least, I don't think it does.
(checking)
moritz so, what should the example print? "A\\n"?
and is the output useful? 21:58
pmichaud oh, the output would still be 'A', yes
but the classname 'A' would not be in scope.
moritz that's kinda... ugly 21:59
pmichaud S04: Blocks are delimited by curlies, or by the beginning and end of the current compilation unit (either the current file or the current eval string). 22:00
22:02 arbingersys left
pmichaud (Null PMC access) -- not sure where that NULL is coming from. :-| 22:05
oh, yes I am. :-)
moritz speaking of "sure" - I should surely go te bed right now ;-) 22:06
good localtime() everybody, see you tomorrow 22:07
pmichaud a demain
bacek moritz, see you... It's 8AM of tomorrow here :)
dalek r28019 | pmichaud++ | trunk: 22:09
: [rakudo]:
: * Clean up slurpy arguments to 'print'
: * Fix lookups of non-existent package items
: * moritz++
diff: www.parrotvm.org/svn/parrot/revision?rev=28019
22:18 Whiteknight joined
pmichaud particle: ping 22:20
22:23 teknomunk joined
Whiteknight chromatic++ has been on a rampage this weekend! My inbox is filled with tales of his travels 22:50
with s/travels/commits/
jonathan hi all 22:59
Back from France.
Three words. I hate flying.
On the upside, I did some Rakudo hacking at Orly airport. And fixed a GC bug in Parrot. 23:01
ci's coming in a bit
NotFound A tax-free patch? 23:02
jonathan It's all EU.
If I want tax-free stuff, I have to nip over to the Ukraine
NotFound I hate eastern europeans, they don't voted the "Chiqui Chiqui" in Eurovision X-) 23:04
jonathan By that logic, as a Brit, I hate almost all of Europe. ;-) 23:05
NotFound Yes, but the easterns the worse.
23:06 toft left
jonathan points out that he moved to east europe from west europe. :-) 23:07
NotFound Anyway, the "Chiqui Chiqui" is destined to conquer the world, like the Macarena X-) 23:10
I'm wondering why ldd parrot shows libstdc++.so in non-c++ build. 23:12
And the same with ldd blib/lib/libparrot.so 23:13
tetragon I see the same on OS X (with otool) 23:14
Some of the build steps are done (on OS X) with g++ for some reason I haven't looked at
The OS X build uses "c++" instead of "ld" as the linker 23:15
NotFound Looks strange, given all "Why C" stuff in parrot faqs.
jonathan NotFound: I believe it's for ICU linking to work. 23:16
Since ICU is written in C++.
tetragon It looks like the Linux config defaults to using g++ when $conf->data->get('link') isn't set
NotFound jonathan: Stranger again.
tetragon jonathan: I've worked with ICU. It has a Java, C++, and a pure C API 23:17
23:17 Limbic_Region joined
Whiteknight an optimized build fails "make perl6". Is this a known issue or should I create a ticket? 23:17
jonathan Whiteknight: provided there's no obvious link with the other currently open ticket on something not working on an optimized build yes. (I forget what the other currently being discussed issue is...) 23:18
NotFound By the way, I think some document must say that parrot is not written in C, but in the common subset of C and C++. 23:19
Whiteknight chromatic opened one about the optimized build failing a few of the threading tests
jonathan Ah, OK.
That doesn't feel like an obvious link to me.
So please do submit a ticket.
Whiteknight done and done 23:24
i need to submit some follow-up info (i didn't copy the error messages the first time, and need to rebuild)
NotFound Specifying --link=gcc , same result. 23:29
Eevee so. what needs doing that will get my.. ankles wet
dalek r28020 | coke++ | trunk: 23:39
: RT #53602 (remove or convert tools/docs/search-ops.py)
: implementation by kid51++
diff: www.parrotvm.org/svn/parrot/revision?rev=28020
23:53 kid51 joined
kid51 logs on and for the first time in days is not deluged with > 20 Viagra/Cialis spams 23:56
More emails from Parroteers than spam -- perhaps there's hope for humanity yet! 23:57

Powered by Cro and the Raku® Programming Language.

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

Thank you!