www.parrot.org | 1.5.0 "TEH PARROTZ!" Released! | Weekly development focus: Bugfixing and stability. Keep those branches merging!
Set by moderator on 26 August 2009.
00:00 mokurai joined
Whiteknight the exceptionhandler.t test pass? 00:00
haha, I used mk_native_pbc, the packfile tests are all still failing, and now 4 new tests are failing too 00:03
darbelo Say, is there any way to find the a PMC's class from the value of vtable->base_type ?
Whiteknight sortof 00:04
if it's a builtin type, you can figure it out. It's one of the enum_class_* values
bacek exceptionhandler.t works
Whiteknight awesome 00:05
bacek World Domination getting close :)
Definitely $dayjob time.
darbelo Eh, at least I'll find out if it's a built in type. I'll go ack that.
bacek bb
dalek kudo: 81d6216 | pmichaud++ | (6 files):
Move prefix:<-> into the setting.
 00:32
darbelo Ok, it's Dec*Context destruction that segfaults, but I can't figure out what I'm doing wrong.
01:18 TiMBuS joined
dalek kudo: d0b88cf | pmichaud++ | Configure.pl:
Check for some more needed Parrot files during Configure.pl .
 01:21
kudo: 586076e | pmichaud++ | (5 files):
Move prefix:<~> into setting.
01:23 mokurai left
nopaste "bacek" at 211.29.157.151 pasted "Interesting failure for Whiteknight++ to look :)" (27 lines) at nopaste.snit.ch/17709 01:26
01:28 mokurai joined 01:40 theory joined 01:55 darbelo left 02:06 davidfetter joined 02:11 rhr joined 02:28 zostay joined 02:34 japhb joined 02:35 janus joined 02:37 mokurai joined
dalek kudo: aab4bf9 | pmichaud++ | src/classes/ (3 files):
infix:<===> should not be defined in terms of infix:<==> or infix:<eq>.
 02:46
03:04 Andy joined
dalek kudo: f351f60 | pmichaud++ | (4 files):
Move infix:<ne>, infix:<!eq>, infix:<!=>, and infix:<!==> into setting.
 03:28
03:32 Coke joined 03:41 dukeleto joined
dalek rtcl: r640 | coke++ | wiki/SpecTestStatus.wiki:
massive update after running 'unfudge' (tools/tcl_test.pl --skip)
 03:48
dukeleto hola 03:50
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40835 - Ubuntu 9.04 amd64 (g++) 03:52
hi there
rakudo (f351f60) builds on parrot r40835, make test / make spectest (up to r28093) PASS - Ubuntu 9.04 amd64 (g++) 03:54
rakudo (f351f60) - t/spec/S05-match/capturing-contexts.rakudo - TODO passed: 14 03:55
03:59 mokurai joined
mikehh partcl r640 builds on parrot r40835 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (g++) 04:05
Coke: running make spectest in partcl 04:06
nopaste "dukeleto" at 72.11.81.253 pasted "blizkost fails to compile on darwin/perl 5.10.0" (97 lines) at nopaste.snit.ch/17710 04:07
dukeleto oops, wrong channel
what does "positional inside named args at position 3" mean? 04:31
Coke ISTR the spec for PCC dictates where in the arg list named args can go. 04:35
foo(1,2,3) has 3 positional args.
dukeleto is there an equivalent of warn() in parrot ?
Coke not really. "printerr" helps. 04:36
I think the warning has to do with the .param listing: I think all the :named have to come at the end.
there's a PDD about that.
pdd03, line#246 04:37
dukeleto coke++ 04:38
04:44 cognominal joined
dukeleto is there something like warn Dumper [ $foo ] for parrot ? 04:47
Coke look at the data dumper lib.
.macro dumper(dingus) load_bytecode 'dumper.pbc' load_bytecode 'PGE/Dumper.pbc' $P9999 = get_root_global ['parrot'], '_dumper' $P9999(.dingus) 04:48
.endm
dalek rtcl: r641 | coke++ | wiki/SpecTestStatus.wiki:
svn up parrot by one, reclaim a few more tests.
 04:49
rtcl: r642 | coke++ | trunk/config/PARROT_VERSION:
This version avoids a few more segfaults.
dukeleto coke++
jonathan: ping
dalek rrot: r40836 | dukeleto++ | trunk/t/op/gc.t:
[TT #950][t] Convert t/op/gc.t to PIR, jrtayloriv++
 04:56
TT #950 closed by dukeleto++: [PATCH]: Convert Perl tests to use test_more.pir for t/op/gc.t
dukeleto why does load_bytecode silently fail when it can't find the file? I find that highly annoyting 04:57
annoying even
Coke old battle between return null and throw exception.
mikehh partcl make spectest - still get 4 -> !! child died with signal 11, without coredump 04:59
Coke mikehh: which version of parrot? 05:01
purl which version of parrot are you using? 05:02
mikehh partcl mathop, between magcat and namespace (fails straight away), subst and while-old
parrot r40835 - Ubuntu 9.04 amd64 (g++)
Coke hurm. at r40826, namespace.test did not segfault for me. 05:03
dukeleto coke: A method named '__dump' already exists in class 'PGE;Match'. It may have been supplied by a role. :(
Coke dukeleto: what kind of objects are you trying to dump? 05:04
(if not PGE, you don't have to use the PGE/Dumper)
mikehh Coke: not namespace - the test between msgcat and namespace - it doesn't say which one it is
dukeleto Coke: ResizableStringArray or things that contain them
Coke mikehh: ah! 05:05
that's 'info'. the output is odd on that one, yes.
dukeleto Coke: i get that error even when not loading 'PGE/Dumper.pbc' . it might be loaded by blizkost already 05:06
Coke mikehh: hurm. none of those failed for me at 40825. running another check at 40826. 05:07
(of parrot)
danke.
mikehh Coke: I logged the results - do you want it? 05:08
Coke not today; thanks for running the tests. 05:09
mikehh 'k
anyway will run some more tests later 05:11
Coke (&*#$ tests pass when run standalone but segfault when run in 'tools/spec_info.pl' :P 05:14
bacek_at_work Coke: I've got "good" news for you. PGE use some uninitilised values inside... 05:18
Coke ... which might be causing my occasional segfaults? 05:21
bacek_at_work Coke: it can be 05:22
Coke seems like parrot could warn us when we use a register that didn't have a value assigned to it. 05:24
(during compilation, even.) 05:25
if you could fix it, I'd appreciate it. =-) 05:26
(your report, not my wishlist)
cotto particle or jonathan, ping 05:29
dukeleto Coke: depends on the register, right? 05:30
Coke: $P0 should return PMCNULL if nothing is there, correct?
bacek_at_work It's INT registers. 05:33
dukeleto there are things, at least from C-land, that you can check to see how many regs of a certain type exist. the debugger uses them 05:35
i found that in the debugger, if you attempt to print a register, and disable the check for looking if that many registers of that type exist, you just get random garbage data back 05:36
05:51 dukeleto joined 06:02 uniejo joined 06:06 dukeleto joined 06:10 rbaumer joined 06:17 desertm4x joined 06:33 HG` joined 06:59 kjeldahl joined 07:00 uniejo joined 07:01 mrsaturn joined 07:04 iblechbot joined, rbaumer joined 07:08 dukeleto joined 07:21 mokurai joined
dukeleto seen jnthn 07:24
purl I haven't seen 'jnthn', dukeleto
dukeleto seen jonathan
purl jonathan was last seen on #parrot 21 hours, 53 minutes and 42 seconds ago, saying: Ah, broken copy op woulda caused problems in Rakudo for sure. It's used very heavily.
dukeleto msg jnthn i have created some issues for blizkost at github.com/jnthn/blizkost/issues 07:28
purl Sorry, I've never seen jnthn before.
dukeleto msg jonathan i have created some issues for blizkost at github.com/jnthn/blizkost/issues
purl Message for jonathan stored.
GeJ Good morning everyone
dukeleto GeJ: good localtime() 07:29
cotto hi dukeleto
dukeleto cotto: werd up 07:30
cotto are you on windows by chance?
dukeleto cotto: thankfully, no ;) 07:31
cotto: i can test stuff on linux/os x/freebsd for you, if that helps 07:32
cotto nope. I need some win32-specific code tested.
I should see about getting my XP VM running again. 07:33
It's hard to find anyone who's got a windows box ready for testing. 07:34
dukeleto cotto: you need to talk to alias in #msopensource 07:40
cotto dukeleto, good idea. Ironically I helped get that started.
dukeleto cotto: have you heard of the farm of windows boxen that CPAN developers have access to now? they have every permutation of win32 that you could want, with VNC access to them all
cotto++
cotto yeah 07:41
dukeleto i have a login but haven't utilized it much yet because I haven't touched windows in a long while
cotto Looks like I'll need a CPAN id. 07:45
It'd be really ironic if I couldn't get a access because I'm not a Perl 5 hacker. 07:48
he BTW, did anyone pick up and commit the patch for NetBSD FP handling I posted here the other day? 07:51
cotto he, can you renopaste it? I'll commit it if it's sane and nobody else already did. 07:53
he sure. 07:56
dukeleto cotto: say that you will be testing Blizkost and you will be in the clear :) 07:57
nopaste "he" at 158.38.152.119 pasted "Patch to fix FP variant selection for the NetBSD math library" (44 lines) at nopaste.snit.ch/17711
dukeleto he: i saw that and liked it, but didn't try it 07:58
he It's a patch applied to 1.5.0; needed it for the self-tests to pass on NetBSD/i386 when I updated the pkgsrc package. 07:59
cotto he, I assume make test passes with that patch applied? 08:01
I'd test it, but a patch to that file can only effect netbsd.
dalek rrot: r40837 | cotto++ | trunk/config/gen/platform/netbsd (2 files):
[platform] netbsd fp variant selection fix from he++
 08:02
08:02 rbaumer joined
he cotto: yes, make test passes with it applied (I uploaded a smoke test; look for the latest netbsd test) 08:11
thanks, btw. 08:12
cotto thanks for the patch, he
mj41 cotto: I can probably setup some VMware Windows box for Parrot developers. Not sure if our university has some Server licenses. Probably yes, for development (no production, no comercial). 08:31
cotto mj41, that'd be great
mj41 irc://irc.perl.org/msopensource can't help ? 08:32
cotto ideally we could get in with Alias' CPAN Testing Lab, but any access would be helpful
I've pinged Alias.
mj41 WinXP Professional is not problem, but it's one user at one time only. 08:36
cotto That'd be fine. 08:37
08:37 payload joined
dalek rrot: r40838 | dukeleto++ | trunk/docs/book/pct/ch03_compiler_tools.pod:
[cage] Fix some typos in docs/book/pct/ch03_compiler_tools.pod
 08:44
rrot: r40839 | fperrad++ | trunk/tools/dev/fetch_languages.pl:
[languages] add blizkost
 08:47
09:23 cotto joined
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40839 - Ubuntu 9.04 amd64 (gcc) 09:33
09:35 cotto joined
mikehh rakudo (7666e92) builds on parrot r40839, make test / make spectest (up to r28096) PASS - Ubuntu 9.04 amd64 (gcc) 09:45
09:47 MoC joined
mikehh partcl r642 builds on parrot r40839 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (gcc) 09:54
dukeleto mikehh++ 09:55
mikehh messages 09:58
dukeleto: how did you get on with the NaN stuff 09:59
dukeleto mikehh: complex NaN is still broken, some rounding NaN is still broken. but I wrote a bunch of tests :) 10:00
the fact that complex numbers don't obey NaN is the broken-ness 10:01
mikehh tests good - dukeleto++
dukeleto so you can get NaN+5i and such
but you have to be tricky
mikehh so you can get a NaN calculating the real part which does not effect the i part (or vice versa) 10:03
affect
dukeleto mikehh: yep 10:04
10:04 donaldh joined
dukeleto mikehh: see t/op/inf_nan.t for all the fun details :) 10:04
mikehh will have a look 10:05
dukeleto when a Numeric PMC register containing NaN is cast down to an Integer register, internal things go south and a machine-dependent number is returned (-2147483648 on my system) 10:07
and the Complex PMC knows nothing of NaN
mikehh do we have any standards to follow on this? 10:09
what does ieee 794 (I think) have to say 10:10
dukeleto actually it is just for a plain numeric register, not a pmc numeric, that it happens. at least that is what the tests are for. numeric pmc's probably have the same issue, but those tests aren't written yet :)
mikehh:ieee754
mikehh: it probably has a lot to say ;) 10:11
mikehh yup that's right
dukeleto also, there are many "flavors" of ieee754, 1985, 1987 and 2008. i am just going to assume that parrot would like to support 2008 unless someone can explain why that would be a bad idea 10:15
mikehh: www.validlab.com/754R/nonabelian.co...54.129.pdf is the draft for 2008, the actual pdf requires a login
mikehh: it has documentation about quiet and singalling NaN, woohoo 10:16
dukeleto realizes he is one of the few people who gets excited about NaN
wow, ieee754 thinks up some crazy shit to do with NaN's, this is scary :| 10:21
10:30 cognominal joined
mikehh dukeleto: was just looking at speleotrove.com/decimal/ which has been updated since he last looked 10:30
looked in the t/op directory - loads of files - need to look after a make realclean :-} 10:40
my editor nearly had a fit - invoked swap - I thought it had died - t/op -> 2,333 items, totalling 3.2 MB 10:45
dukeleto mikehh: lots of generated files :) 10:46
mikehh especially after running fulltest -> testr whivh generates .pbc files as well 10:47
which
dukeleto i think -2147483648=ilogb('NaN'), that is actually one of the failure modes in ieee754
dukeleto needs sleep 10:48
11:03 desertm4x joined
dalek TT #954 created by dukeleto++: Inf/NaN from ieee754-2008 11:04
11:20 donaldh joined
dalek rtcl: r643 | coke++ | trunk/docs/spectest- (2 files):
update spectest data;

  - includes some segfaults from previously passing tests, skipping those in next
commit.		 12:07
rtcl: r644 | coke++ | wiki/SpecTestStatus.wiki:
14!? more segfaulting tests with latest parrot.
Coke ok. there are now /forty one/ partcl spec tests that are segfaulting. 12:08
out of 137.
41/137 12:09
purl 0.299270072992701
Coke so, 30%.
szbalint ouch 12:11
12:16 ruoso joined, cosimo joined, whiteknight joined
whiteknight good morning #parrot 12:19
NotFound whiteknight: what do you said about kicking asses? 12:25
whiteknight I said you're doing it
NotFound Soemones's ass, or bug's ass? 12:26
whiteknight bugs ass
NotFound Ah, nice
whiteknight and generally being awesome
NotFound Thanks 12:27
12:27 szabgab joined 12:29 quek joined
Coke NotFound, whiteknight : with notfounds last fixes, I get most of my spec tests back, but I'm now up to 41 spec test segfaults in partcl. 12:49
After $DAYJOB today, I'll try to track some of them down more specfically, but for now, the list of segfaults is on the partcl wiki at SpecTestStatus if anyone wants to go segfault hunting. 12:50
(I run against an optimized parrot; some of those may revert to assertion errors in a non-opt parrot)
NotFound Coke: partcl uses asignment to Undef, isn't it? 12:51
Coke I believe we do, yes. 12:52
NotFound I'm looking at that now, looks broken to me even if it pass tests
Coke the concept, or the current impl? 12:53
NotFound Impl
Coke ok. I'm surprised that I don't have MORE failures if that's borked, but I'm happy to test (or show you a test that's failing right now)... 12:54
if-old is probably the shortest test on the list. (build parrot, install it, build partcl, then you can: "./tclsh t_tcl/if-old.test" 12:55
NotFound I'm testing now an attempt of ix.
Coke ix?
purl ix is boring i mean professional programming magazine :)
NotFound fix
12:55 Zak joined
whiteknight kid51 ping 13:49
purl msg kid51 I don't think I'm going to make it up to NYC in September. My wife is having a baby shower then so we have to be in town. Sorry! 13:53
purl Message for kid51 stored.
Coke there's a nyc thing in september? hurm.
whiteknight not a "thing". I was supposed to be in town on unrelated business 13:54
well, my wife was supposed to be in town and I was in charge of driving her there (and back again) 13:55
Coke ahhh.
whiteknight which would have left me in NYC with nothing to do for an afternoon
14:00 quek left 14:06 rbaumer joined 14:11 kid51 joined
Coke kid51: hio 14:12
kid51 hello
purl hello, kid51.
14:14 Andy joined
NotFound I think I've found a serious bug: the stacktop for GC marking is not set when calling PackFile_fixup_subs 14:16
Coke I don't know what that means, but woot. =-) 14:18
kid51 msg pmichaud Please see trac.parrot.org/parrot/ticket/936#comment:9 re 'make install' problems.
purl Message for pmichaud stored.
14:21 Psyche^ joined
NotFound Coke: it may mean that with a two line change most segfaults wil disappear 14:21
Coke NotFound: I'd be excited to test that patch.
14:27 cosimo joined
nopaste "NotFound" at 213.97.96.43 pasted "Set stacktop in packfile fixups" (22 lines) at nopaste.snit.ch/17714 14:27
NotFound Well, 3 lines ;)
Coke YOU DIRTY LIAR! 14:28
</humor> 14:29
bah. when pbc2exe was failing, I created a shell script called 'mytcl' that wrapped the call to parrot. I should have called it tclsh; my fingers type that all the time now. 14:31
NotFound: util.test gets past the original segf. 14:32
so this was a GC bug? 14:33
woot: util.test: Total 290 Passed 130 Skipped 128 Failed 32
NotFound Coke: maybe *the* GC bug
Coke damnit, I was going to finally post a ranty blog entry on partcl complaining about the (&#$ segfaults. you stole my thunder! 14:34
(I will do an unfudge run and see if this magically fixes everything. =-)
NotFound Not everything, but maybe a lot of tests can be unskipped 14:35
Coke fixed 2/3 so far. 38 to go. =-) 14:38
NotFound Coke: 2/3 of partcl segfaults?
Coke I have run the test for 3 spec tests that were segfaulting, 2 no longer segf with your patch. 14:39
(will take a while to run the remaining 38 tests that were segfaulting.)
NotFound Not so bad :)
Coke (esp since I'm just running all 72 skipped tests, some of which are looong.) 14:41
14:41 ewilhelm joined
kid51 whiteknight ping 14:41
whiteknight pong 14:42
kid51 Thanks for prodding on tt509_install_files branch. Am testing wayland's last patch. Will post results and ask for comments and testing on systems/situations that don't support symlinks. 14:44
whiteknight gotcha 14:45
kid51 Also, sorry NYC trip is off?
whiteknight yeah, plans got changed that weekend
kid51 whiteknight: Had you given any thought to the Victory brewery tour on Sat Sept 12?
Coke NotFound: OOC, did tcl prod you to find that segfault maker, or did you just find it during code analysis, or...?
whiteknight kid51: you going to that? 14:46
kid51 I was thinking of driving down for that.
It falls into the Excuses to Get Out of Town Department.
whiteknight that's actually right down the road from where I work, the wife of the guy who owns Victory works with me
kid51 It's being organized by ABE.pm, but I believe details have also been posted on Phila.pm list 14:47
whiteknight yeah, I've seen the emails flying bye
kid51 Well, keep it in mind and I'll ping you about it right after Labor Day. 14:48
whiteknight when is labor day?
kid51 Mon Sep 7
whiteknight is not nearly as good with a calendar as he is with a keyboard
okay
NotFound Coke: I looked at the backtrace of the test you said me 14:53
whiteknight: take a look at my last nopaste
dalek rrot: r40840 | jkeenan++ | branches/tt509_install_files/lib/Parrot/Install.pm:
Applying patch submitted by wayland++ in trac.parrot.org/parrot/attachment/...ier.patch. Needs testing in non-symlinkable situations.
 14:56
kid51 So, we can use testing (perl Configure.pl --prefix=/home/user/some_safe_directory && make manifest_tests && make && make install && make install-dev) of the tt509_install_files branch on Win32 and also on, e.g., Linux w/FAT32 filesystems. See TT509. 15:03
15:19 mokurai joined 15:27 theory joined
Coke NotFound: looking good here, though it'll take some time to go through all the tests; anything stopping you from applying that? 15:35
15:45 nopaste joined
dalek TT #936 closed by pmichaud++: "make install" doesn't install PCT 16:05
pmichaud msg kid51 Added note to #936, closed ticket, thanks!
purl Message for kid51 stored.
Coke NotFound: the segfaults are still squishy. (util.test ran to completion by itself; in the spec test, boom. 16:08
as part of the spec test, that reclaims 12 test files out of 41 segfaults, though. 16:09
16:14 kjeldahl joined
NotFound Coke: not so bad, I'll commit it now 16:18
16:20 darbelo joined
dalek rrot: r40841 | NotFound++ | trunk/src/packfile.c:
[gc] mark stacktop in PackFile_fixup_subs
 16:22
darbelo NotFound: while you're looking at segfaults. decnum-dynpmcs is still seeing segfaults during interpreter destruction. 16:23
NotFound darbelo: Are you using auto_attrs in the pmcs? 16:24
darbelo Nope. and attr_size is correctly set to 0, from what I've been able to see it segfaults when calling VTABLE_destroy() 16:25
16:25 MoC joined
darbelo If I remove the active_destroy flag everything is fine. 16:26
16:26 JimmyZ joined
NotFound darbelo: What trunk release is merged into that branch? 16:27
darbelo I'm working against trunk. decnum-dynpmcs is my GSoC project. 16:28
16:28 yath joined
yath heya 16:28
darbelo purl: decnum-dynpmcs?
purl decnum-dynpmcs is code.google.com/p/decnum-dynpmcs/ or a 2009 GSoC porject or a set of 'big' decimal arithmetic types for parrot.
NotFound Ah, ok, I was mixing things in my head.
yath the docs for PCT tell me to use mk_language_shell.pl for building a scaffold, but i can't find that on a halfway recent parrot... 16:29
what should i use instead?
pmichaud you might need "install-dev" for parrot 16:30
afk # lunch
yath euh, i was not going to do make install* or so..
nopaste "darbelo" at 200.49.154.172 pasted "The segfault." (15 lines) at nopaste.snit.ch/17716 16:31
darbelo NotFound: removing either the active_destroy flag OR the singleton declaration for the PMC fixes the segfault. 16:33
Thing Is I can't find anywhere in the pmc-destruction code where singleton-ness is checked for or where it should matter at all. 16:36
Coke <sigh> partcl's 'make test' is now failign after updating parrot.
darbelo Coke: does partcl use any sigleton PMCs with the active_destroy flag set? 16:37
Coke ... and now it's not. wtf. I swear, someone with root on feather is messing with me. 16:38
darbelo: not unless it's a core pmc. 16:39
darbelo Coke:
Coke: Then you can feel lucky. There's at leat one parrot bug that isn't biting you. 16:40
NotFound Someone should write "Singleton considered harmful" 16:41
darbelo I sort of did, back when I started using them :) 16:42
www.parrot.org/content/singletons-h...buse-them. 16:43
NotFound darbelo: you can try to use Parrot_atexit for the destruction.
dalek rtcl: r645 | coke++ | wiki/SpecTestStatus.wiki:
unfudge some tests thanks to NotFound++
 16:44
rtcl: r646 | coke++ | trunk/config/PARROT_VERSION:
NotFound++ # fewer segfaults at this revision.
darbelo I can just leak the memory, singletons are immortal anyway. But I'd like to confirm that it's a bug on parrot and not my code. 16:46
Coke (P*&@#$(*&@#$(*@#&$(*@#$&(@#*$&@#
NotFound I don't know if destruction of singletons has been planed or even thinked about. 16:47
Coke (unfudge test a. run test in harness. test now segfaults.)
This is reaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaally frustrating.
perhaps I will now get to write my snarky blog post after all, despite NotFound. =-)
NotFound Coke: you can write it anyway 16:48
darbelo s/destruction o //
'There can only be one of this' != 'make it immortal' 16:49
Highlander references notwithstanding :) 16:50
yath hm. docs say i should run mk_language_shell.pl in languages/, but there is no languages/. is compilers/ the successor? 16:51
darbelo yath: nope. Languages have left the nest. They live outside of the parrot tree now. 16:52
NotFound You can just mkdir ir for testing
yath darbelo: hm. and where would i get started (as in: in which directory) to do some fiddling with parrot?
err, PCT
ah ok
$ ../../parrot test.pbc 16:53
>
\\o/
thanks :)
darbelo Anywhere you like, actually. I think create_language.pltakes an argument for the directory it should put stuff into.
NotFound Coke: What test is failing now?
Coke sadly, we have, what, 2 different ways to create a language shell?
NotFound: -appendComp.test, -compExpr-old.test 16:54
2/12
purl 0.166666666666667
darbelo Coke: Yup, and neither one did exactly what I wanted last time I tried them :)
Coke so that's already lost 17% of the gains you just made, just by running the full harness instead of just an unfudging run. 16:55
darbelo But what I wanted was fairly odd too. So I guess it's ok.
Coke (possible those are lost due to recent changes in parrto from my last run and your commit.)
(just by running) and I just started that spec test run, many more chances for regressions. 16:56
yath hm, where would i get a pir.vim from? 16:57
16:57 jrtayloriv joined
yath ah, got ir 16:57
it.
darbelo editor/ in the parrot tree
yath yep :)
NotFound Coke: Some easy to try segfault? 17:03
treed . 17:07
Coke notfound: ./tclsh t_tcl/appendComp.test 17:09
(segfaults after 3rd test.)
... unless you run it in gdb, apparently. :P
NotFound Coke: doesn't segfault for me now, in a non optimized build. 17:11
Coke NotFound: try with --gc-debug 17:16
nopaste "coke" at 65.91.151.195 pasted "backtrace for notfound." (23 lines) at nopaste.snit.ch/17718
17:17 ruoso joined
Coke 9 new failures so far... 17:27
jrtayloriv I want to convert the tests in t/pmc/filehandle.t to use test_more.pir instead of Perl, but a lot of the tests are using the "create_tempfile()" sub from Parrot::Test::Util to create a tempfile before running the pir_output_is tests. Is there any way to get around using Perl here? 17:43
Coke NotFound: net loss of one test file after the update. 17:53
jrtayloriv Is there any reason that I can't just use -- tempfile = open 'tempfile', 'w' -- instead? 17:54
NotFound jrtayloriv: because a file with a fixed name is no good por people doing paralel tests 17:56
17:56 AndyA joined
Coke we probably need a File::Temp in parrot. 17:58
17:59 whiteknight_ joined
Coke jrtayloriv: so, skip that one. 18:00
jrtayloriv NotFound, thanks -- Coke, will do ;) 18:03
Coke jrtayloriv: trac.parrot.org/parrot/ticket/955 18:05
dalek TT #955 created by coke++: need ability to create tempfile from PIR 18:08
duk3leto coke++, i likes temp files 18:10
is the current PID available from Parrot?
jrtayloriv: making test_more.pir better is going to be necessary to convert many tests 18:12
NotFound BTW conveting to pir tests that have known problems not fully solved is not a good idea, and even worse doing it without testing in several different platforms. 18:13
Coke how can one converting tests know which ones have known problems? 18:16
NotFound Good question 18:17
purl Yeah, it is. I'm stumped.
Coke anything SKIPPED is dangerous.
NotFound Yeah, and converting to pir just to be forced to skip it is the worse of the ideas. 18:18
18:19 davidfetter joined
NotFound I mean, converting a todo that segfaults, for example. 18:19
Coke I'd be happy if todos/skips were left in foo-old.t
I don't think it's a moral imperitive, but it's not worth expending extra effort on, sure. 18:20
18:36 joeri joined 18:39 szabgab joined
jrtayloriv As far as implementing create_tempfile() in PIR, File::Temp uses File::Spec::tmpdir() to check for the correct tmp directory ... ultimately, if tmpdir() doesn't find a tmp dir it is supposed to use, it just defaults to cwd -- is there any reason why the tempfiles for the tests should not be created in the test directory? 18:49
NotFound jrtayloriv: because they are temporary files
jrtayloriv NotFound, What would be the problem with having the temporary files in the test directory? Why is that a Bad Thing? 18:52
NotFound jrtayloriv: mainly, because people don't want that lots of files of unknown purpose appear in his work directories for unkown reasons. 18:53
jrtayloriv Doh ... that was dumb ... it's just because the files wouldn't get cleaned up if the test died. Sorry for the time waste. 18:55
pmichaud (create_language.pl) -- I need to update that with the latest improvements from Rakudo's configuration 18:56
cotto anyone want to try a windows patch on pluggable_runcore? 18:57
Coke can we kill one or the other of those scripts? 19:00
cotto +1 19:01
purl 1
cotto +kick purl
Coke if we don't have a ticket, someone should make one.
even if it doesn't decide which one to pick. 19:02
-> 19:03
NotFound Coke: "There's more than one way to do it" ;)
particle cotto: i can try the patch 19:08
nopaste "cotto" at 74.61.2.46 pasted "runcores patch for win32" (17 lines) at nopaste.snit.ch/17719 19:09
cotto although it'd be nice to know first why those printf lines yesterday weren't printfing. 19:10
That patch should work, but it'll also be vulnerable to noise from context switches. 19:20
nopaste "cotto" at 74.61.2.46 pasted "alternate runcores patch for win32 using GetProcessTimes" (27 lines) at nopaste.snit.ch/17720 19:21
cotto mj41, ping 19:23
dalek rrot: r40842 | NotFound++ | trunk/src/pmc/undef.pmc:
[pmc] fix set_pmc vtable in Undef PMC
 19:38
particle cotto: neither patch changes anything, and i'm still not seeing the fprintf output 19:45
neither patch changes the 0 in second column, i didn't look closely for anything else
cotto That's not sane. 19:47
particle sadly, no :( 19:48
cotto Does src/platform.c have the right Parrot_hires_get_time function?
particle oh give me a break! 19:49
i need to reconfigure after i change this. duh. 19:50
cotto yeah
that'd help
particle i'm just gonna modify src/platform.c
cotto fine by me
particle it takes too damned long to reconfig/compile
19:52 mokurai joined
particle cotto: i'm seeing a lot of <<<<<1>>>>> now 19:52
so the command is succeeding
19:52 mokurai left
particle but the times are still 0 19:53
cotto That shouldn't be the case for any program that takes more than 100ns. 19:54
particle your second patch doesn't change anything 19:55
the first patch works! 19:57
cotto the one with QueryPerformanceCounter? 19:58
particle ayep
nopaste "particle" at 76.121.106.245 pasted "hanoi.pir profiling output" (1301 lines) at nopaste.snit.ch/17721
cotto That's a lot better than nothing, but I really want to know what's not working about GetProcessTimes.
Thanks! 19:59
particle ship it!
cotto I'll commit that and figure out what's wrong with GetProcessTimes when I have a windows box to play with.
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40842 - Ubuntu 9.04 amd64 (g++) 20:00
20:04 AndyA joined
mikehh rakudo (7666e92) builds on parrot r40842, make test / make spectest (up to r28100) PASS - Ubuntu 9.04 amd64 (g++) 20:07
Coke NotFound: is r40842 going to rock my wold? 20:08
20:08 chromatic joined
Coke ... world? 20:08
wold: The yellow dye obtained from dyer's rocket. 20:09
NotFound Coke: don't know what to says, seems to change from build to build
chromatic msg whiteknight How encapsulated is the current GC? If I wanted to fork the current M&S and use the linked list idea (I figured out the missing part today), how much work is it? I also need to change the Arena structs slightly.
purl Message for whiteknight stored.
20:10 mokurai joined
chromatic NotFound, sudo echo 0 > /proc/sys/kernel/randomize_va_space ? 20:10
NotFound Uh, forgot to play with that, 20:11
20:11 AndyA joined
Coke NotFound: it sure does. :| 20:14
chromatic: my segfaults are killing me. any help greatly appreciated. =-)
NotFound++ # all his work so far today.
bah. using git-svn, is there an easy way to get .parrot_current_rev to update after 'git svn rebase' ? 20:15
(ATM I have to do a full rebuild or handedit the thing.)
NotFound++ #good measure 20:16
PerlJam git svn info | awk '/Revision:/ { print $2 }' > .parrot_current_rev # ?
Coke: that was for you in case it wasn't obvious :) 20:17
Coke PerlJam: ... easier to edit it by hand. =-)
(actually, easier (but slower) to just run my "rebase and re-intsall for tcl" script. =-)
mikehh partcl r647 builds on parrot r40842 - make test - same 6 tests fail but all subtests PASS - Ubuntu 9.04 amd64 (g++) 20:18
Coke PerlJam++
PerlJam Coke: I wonder if there's a way to trigger scripts to be executed after "git svn rebase" Seems like that would be a good thing for svn:ignore properties at the very least. 20:19
Coke PerlJam: that would be spiffy. 20:20
NotFound Mmmmm... looks like r40842 breaks a rakudo spectest
cotto Now I can finally go back to not caring about windows.
Coke with it got a failure in 'make test' that went away when i ran the test by hand.
mikehh NotFound: which - I just PASSed them all 20:21
chromatic Coke, PerlJam, I have a script to reconfigure Parrot and rewrite config_lib.pasm whether I use svk or git.
PerlJam chromatic++
dalek rrot: r40843 | cotto++ | branches/pluggable_runcore/config/gen/platform/win32/hires_timer.c:
[profiling] Switch to QueryPerformanceCounter for high-resolution timing info on win32.
PerlJam I guess an ordinary post-receive hook would probably be able to do it.
nopaste "chromatic" at 72.87.39.97 pasted "Reconfigure Parrot" (1 line) at nopaste.snit.ch/17722 20:23
duk3leto chromatic: welcome back
purl Your dreams were your ticket out.
NotFound mikehh: S12-attributes.clone
Coke *snrk*
nopaste "chromatic" at 72.87.39.97 pasted "Rewrite config_lib.pasm" (19 lines) at nopaste.snit.ch/17723
NotFound Mmmm... maybe the test pass, even if segfaults at exit 20:24
nopaste "coke" at 65.91.151.195 pasted "this is the second segfault bt with recent parrot in Parrot_String_mark" (23 lines) at nopaste.snit.ch/17724 20:25
mikehh NotFound: passes for me and ./perl6 t/spec/S12-attributes/clone.t passes all 12 tests
dalek rtcl: r647 | coke++ | wiki/SpecTestStatus.wiki:
More spectest churn.

from the previous unfudge round.)		 20:26
Coke that backtrace was from head of parrot, partcl, optimized, against tcl.pbc t_tcl/if-old.test
chromatic You can add debugging symbols to an optimized build.
Coke what's the magic Configure.pl option for that? 20:27
--CCFLAGS=-G ?
--ccflags=-G, I mean. 20:28
mikehh hey dalek is really slow I picked that partcl r647 with svn up 20+ minutes ago
PerlJam mikehh: it probably depends on how often the RSS feed is updated. 20:29
mikehh I thought it was every 5 minutes or so - maybe not for partcl
Coke chromatic: huh. says write in the gcc manual "GCC allows you to use -g with -O" nifty. 20:30
"who knew" 20:31
duk3leto Coke: -g increases the size of the binary by adding debug symbols, which is orthogonal to what -O does. That is how I understand it, anyway 20:32
nopaste "coke" at 65.91.151.195 pasted "now, with debug" (64 lines) at nopaste.snit.ch/17725 20:34
20:34 whoppix joined
Coke (gdb) p str_val 20:35
$3 = <value optimized out>
I have to head out soon; anything I can dump from this gdb session that would help someone debug it? 20:36
rant: all these macros make it hard to debug. :| 20:38
laters. 20:39
particle ~~
dalek rrot: r40844 | cotto++ | branches/pluggable_runcore/config/gen/platform (3 files):
[profiling] pick a more descriptive name for a high-resolution timer function
 20:42
mikehh cardinal - builds on parrot r40842 - make test - 3 failures - 593 tests were run, from 98 files, 511 tests passed, 0 of which were unexpected, 82 tests failed, 82 of which were expected 20:43
NotFound Can a String be Special? 20:44
Ah, no, is a String PMC
mikehh cardinal - There were 3 files that completely failed to compile: gen_08-class.pir, gen_alias.pir,gen_freeze.pir
dalek rrot: r40845 | cotto++ | branches/pluggable_runcore/src/runcore/cores.c:
[profiling] remove some unused or unnecessary variables
 20:45
mikehh cardinal - all 3 failed with get_pmc_keyed() not implemented in class 'String' - Ubuntu 9.04 amd64 (g++) 20:46
cotto karma g 20:50
purl g has karma of 595
mikehh ok what else can I test lua doesn't build for me 20:52
dalek rrot: r40846 | NotFound++ | trunk (2 files):
[cage] add some checks to C stack gc related code
 20:53
mikehh ok I'll test that :-} 20:54
NotFound lua doesn't build with g++, last time I checked
darbelo mikehh: I have something for you to test on decnum-dynpmcs 20:57
mikehh doesnt build with gcc either or on i386 for me 20:58
darbello - ok just rebuilding
nopaste "darbelo" at 200.49.154.172 pasted "[PATCH] Leak memory, don't segfault." (13 lines) at nopaste.snit.ch/17726
darbelo mikehh: nopaste.snit.ch/17726 21:00
mikehh got it - will try in about 10 minutes or so 21:03
treed Did get_pmc_keyed get removed from String recently? 21:11
bacek_at_work: I'm probably looking at you. 21:12
chromatic www.tcl.tk/doc/scripting.html 21:21
21:22 Whiteknight joined
mikehh darbello: looks good so far 21:25
darbelo mikehh: tests are segfault-free?
Whiteknight hello #parrot 21:26
mikehh darbello: not all Failed 1/17 test programs. 0/14629 subtests failed. - t/remaindernear.t .. All 121 subtests passed
treed Whiteknight: Do you know if get_pmc_keyed was removed from String? 21:27
darbelo That's ok, remaindernear.t was my control sample :)
mikehh: are you on i386 or on amd64 ? 21:28
21:28 mokurai joined
mikehh darbelo: the rest pass - Ubuntu 9.04 amd64 (gcc) 21:28
Whiteknight treed: was get_pmc_keyed ever implemented in String? 21:29
chromatic: ping
chromatic pong
treed Whiteknight: It used to be. 21:30
mikehh All tests PASS (pre/post-config, smoke, nqp_test, fulltest) at r40846 - Ubuntu 9.04 amd64 (gcc)
treed cardinal's been using it for ages
Whiteknight chromatic: the PObj part of the GC is relatively well encapsulated, yes
treed I'd bisect, but I'm on Windows right now, and therefore away from my dev environment.
Whiteknight there is a problem in the Buffer allocator though, it expects to be able to walk the STRING pool linearly
treed: what would get_pmc_keyed even do on a String?
chromatic Is that to compact buffer pools? 21:31
darbelo Whiteknight: is there anything in particular about singleton dynpmcs that could cause segfaults if they heve their active_destroy flag set?
Whiteknight yeah, it walks the STRING pool linearly to find used buffers and compacts them
21:31 mokurai joined
Whiteknight darbelo: nothing that I am aware of, but I'm hardly an expert on the dynpmc loading mechanism 21:31
darbelo: I take that to mean you are seeing problems when a dynpmc gets collected? 21:32
chromatic: so what is this "missing piece" that you figured out? I'm very interested to hear about that
treed Whiteknight: Return a character at a given index? 21:33
darbelo Whiteknight: It segfaults in Parrot_pmc_destroy() where it should call the destroy vtable.
chromatic Whiteknight, I could never figure out how to find all garbage PObjs without sweeping the pools.
treed There's a get_string_keyed 21:34
Maybe get_pmc_keyed used to auto-cast?
I swear it used to work.
chromatic The secret is to add another linked list, maybe_garbage. Every time you allocate a new PObj (free list or from the pool), stick it on that linked list.
Whiteknight treed: that doesn't make sense, why would get_pmc_keyed be expected to return a character? It's defined to return a PMC
treed Maybe it returns a String PMC with a length of 1? 21:35
chromatic Then when you run a normal GC (not a full sweep), stick everything you mark on the live list.
treed StringIterator uses get_pmc_keyed, IIRC
chromatic Everything remaining in the maybe_garbage list is unused, and you can stick it on the free list with one pointer swap.
Whiteknight chromatic: the maybe_garbage list would need to be doubly-linked if you're going to be randomly accessing it and pulling things out of the middle
treed Last time I got this error message while building: 21:36
Last time I got this error message while building: 12:59 <purl> bacek_at_work [Fri Aug 7 04:18:34 2009] said: I'll fix parrot today-tomorrow so StringIterator.shift_pmc will work again.
chromatic True.
Whiteknight unless you "swept" it from the root, moving items with the live flag to the alive list, and everything ese to the free list
chromatic I want to avoid sweeps. 21:37
Whiteknight I always figured sweeps were the least expensive part
chromatic Not really.
Whiteknight never benchmarked of course, but that's what it logically seems like it should be
chromatic About half of our GC time is sweeping. 21:38
Whiteknight you're not really talking about avoiding sweeps so much as you are talking about being more selective about what objects we sweep 21:39
so don't sweep over objects that are not allocated
21:39 beta joined
chromatic Right. 21:41
Not only does that save CPU cycles, but it has a chance of avoiding expensive cache games.
Whiteknight it's a good heuristic anyway, I bet there are some savings to be had if (1) a large portion of our PObjs at any given time are free and (2) we can make this cache-friendly
chromatic (1) is almost undoubtedly true for most workloads. 21:42
We also avoid a lot of add_to_free_list calls this way.
Whiteknight and we could improve (1) by tuning the GC, using the Lazy allocator, and increasing our initial allocations
chromatic I did the latter. 21:43
Whiteknight is it in trunk already?
(i never had a good opportunity to test it)
Adding two pointers to every PObj (I assume as part of a header) is going to have a noticable impact on our memory footprint 21:45
chromatic It's not in trunk. 21:46
We do need a better approach than storing two pointers. 21:47
Whiteknight we do have the _next_for_GC field that can reasonably be remoed
removed*
chromatic Sweeping is about 50% more expensive than marking, but part of that is managing fixed-sized memory through malloc/free. 21:48
Whiteknight what is being managed with malloc/free during the sweep anymore?
And I know the STRING compacting stuff is expensive, that has to play a big part
chromatic PMC attributes.
Whiteknight that pointer is only available when the PMC is not aliv 21:51
chromatic en.wikipedia.org/wiki/XOR_linked_list 21:53
Alternately, we don't store the linked list structures in the headers themselves (probably a good idea for cache friendliness) and store them in the Pools/Arenas instead. 21:54
Getting rid of _next_for_GC gets PMCs down to 24 bytes apiece (32 bit). 21:55
Moving _synchronize into _metadata gets us to 20 bytes.
NotFound chromatic: a problem is to locate all points that poke into pmc internal, like I'm learning these days. 21:57
chromatic _next_for_GC bothers me, because I've never understood it.
PMC_sync is fairly well encapsulated.
NotFound For example, the copy opcode poke into next_for_gc for no aparet reason
chromatic That's probably because it's a free pointer. 21:58
mikehh rakudo (7666e92) builds on parrot r40846, make test / make spectest (up to r28100) PASS - Ubuntu 9.04 amd64 (gcc) 22:00
chromatic Let's try to moveof PMC_
Let's try to move PMC_sync into PMC_metadata. That'll give us 14.29% more PMCs for free. 22:01
Lazy allocation means they're free, anyway.
Whiteknight _next_for_GC is a premature optimization, trying to create a way to mark PMCs with priority 22:03
removing it from the GC would be trivial
however, that space is also used in src/freeze.c for an unrelated purpose, and I don't know anything about that
chromatic Yeah. That's what always trips me up. 22:04
Whiteknight would love to travel to the jungle of src/freeze.c with a machete and do some real damage there
that whole goddamn system is a liability 22:05
cotto Do it! Kill it with fire.
jrtayloriv Is there no way to open a file with the O_TEMPORARY flag in PIR? 22:10
22:19 Zak joined
Whiteknight jrtayloriv: not that I know of, no 22:24
jrtayloriv Is there a reason why it shouldn't be added, or is it just that nobody has had the time to do it yet? 22:29
it == "ability to do so"
dalek TT #956 created by darbelo++: [gc] Singleton PMCs with the active_destroy flag set cause segfaults when ... 22:31
22:39 Limbic_Region joined 22:41 rg joined
Whiteknight jrtayloriv: no reason why not, I don't think. Probably need to ask allison about it. Probably just waiting for people with tuits 22:44
that's quite the interesting ticket, darbelo 22:47
quite a head-scratcher
chromatic Shouldn't be: pmc->vtable = (VTABLE *)0xdeadbeef; 22:48
First time through, the vtable turns into hamburger.S
darbelo Whiteknight: Tell me about it. I've been looking at all of the surrounding code for two days and can't find anything even remotely suspicious. 22:49
chromatic Second time through, dereferencing hamburger causes segfaults.
Whiteknight what do you mean hamburger? 22:50
chromatic 0xdeadbeef
darbelo chromatic: The (pmc)->vtable pointer is quite valid a the point the segfault happens.
(pmc)->vtable->destroy could be a suspect. But I can't see anyone tampering with that value anywhere. 22:51
chromatic What's (pmc)->vtable->destroy?
darbelo 0x211a31170 22:52
for a bit more context: 22:55
delprop = 0x202f87e60 <Parrot_default_delprop>, destroy = 0x211a31170,
chromatic Are there any Parrot_Segfaulty_* functions in p *pmc->vtable? 22:56
Oh, this is during global destruction.
Hm.
Conjecture: the dynpmc library is already unloaded at this point, so the dlclose for the shared library handle has already happened.
22:57 mokurai joined
chromatic The pointer is still valid, but the OS has already unmapped that area of memory. 22:57
darbelo chromatic: Yes. Singletons live in the constant pool. They are immortal.
chromatic Okay.
The PMC has outlived its C functions loaded from the shared library. 22:58
darbelo chromatic: Non-singletons die quietly :)
chromatic: Oh. That make sense.
chromatic Just another order of destruction problem, this time in the constant PMC pool.
darbelo chromatic: What prevents singletons from moving out of the constant pool? (probaly after a deprecation notice) 23:00
chromatic The only way I can think of to make them singletons right now without them being in the constant pool is to add a check to the GC sweep not to reap them. 23:01
That *may* be the right approach, but when the constant PMC pool goes away for good, we may still have this problem. 23:02
darbelo Why not treat them as regular PMCs? "Nobody needs you, bub. Have a nice death." 23:03
chromatic Because we can't reap them during GC sweep, otherwise they're not singletons.
darbelo I don't see why 'Only one ever created' == 'Can't kill it'. 23:04
chromatic You create one. It lives for a while.
You can never create another one.
What happens when that first one you created is unreachable from the root set? 23:05
Now you have none and you are sad.
dalek kudo: 7666e92 | pmichaud++ | (6 files):
Move infix:<%>, infix:<div>, and infix:<mod> to the setting.

so add dummy versions of those to NYI.pm for now so people know what's going on.
darbelo "You can never create another one." is not true in current parrot.
I've always read singleton as "Only one at any given time." Which is different, to me, from "always the same one" 23:07
And if parrot singletons are defined as "always the same one" (A reasonable thing too). Then I need a new kind of PMC for waht I want to do. 23:08
Whiteknight chromatic: so you think the Library PMC is being collected earlier in the sweep, unloading the library, and taking all the funcitons with it? 23:09
Whiteknight has no good idea about how we're going to implement strict order-of-destruction in a non-hackish way that doesn't eat up a shitload of memory/performance 23:14
chromatic Whiteknight, I'm certain of it.
cotto Andy, whatever happened to that automatic makefile dependency generation you were working on? 23:15
Whiteknight I'm not sure that makes sense to me. Items in the constant pool never get collected, so they should always be laid out in the order they were allocated in, and soruning a sweep backwards through the pool should always do things in the right order
oh shoot, temporary_pmcs are allocated out of the constant pool, aren't they? 23:16
23:20 Zak joined
darbelo cotto: That reminds me, I had a "make -j" build failure a few days back in the pluggable_runcore branch. You might have to check your makefile deps. 23:20
cotto darbelo, thank. I'll see if I can break anything. 23:21
I usually use -j, but it's very possible I missed something. 23:22
23:25 MoC joined
cotto darbelo, if you get the build failure again, please nopaste the relevant bits of the error message. 23:26
nopaste "darbelo" at 200.49.154.172 pasted "Build failure for cotto++." (50 lines) at nopaste.snit.ch/17727 23:35
darbelo cotto: does your make have a -dp option? 23:39
cotto darbelo, can you reproduce it in trunk? It doesn't look like something runcore-specific.
lemme check'
-dp spits out excessively verbose debugging information 23:40
darbelo Hmm on BSD it's "Help finding concurrency issues for parallel make by adding some randomization."
But maybe it's one of those "Randomize everything" things the OpenBSD developers like to do. :) 23:41
nopaste "darbelo" at 200.49.154.172 pasted "Another -j failure, this one on trunk." (77 lines) at nopaste.snit.ch/17729 23:51
darbelo keeps breakin' stuff all over the place. 23:53
cotto It seems to be having trouble with the generated file lib//Parrot/OpLib/core.pm
darbelo I had to "$ make realclean && perl Configure.pl && make -dp -j9" twice before I finally broke it. 23:55
I could be an issue of inter-Makefile dependencies. 23:58
cotto I'm not sure what to do about that. It looks like Ops2c/Utils.pm is getting a partially written version of that file.

Powered by Cro and the Raku® Programming Language.

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

Thank you!