www.parrot.org | Parrot 1.6.0 "half-pie" released: The JIT is dead! | Testing priorities: Exception and MultiSub
Set by moderator on 20 September 2009.
00:00 Whiteknight joined
darbelo I have a STRING with {flags = 128335236, _bufstart = 0x3, _buflen = 0, strstart = 0x87cc8bdc "", bufused = 18416, strlen = 581689504, hashval = 3485389480, encoding = 0x2ab7d7e, charset = 0x22abfa54 00:02
}
does that make sense?
_bufstart = 0x3 looks wrong to me.
Whiteknight is wrong 00:12
darbelo Okay, then something's wonky in the parrot strings subsystem. 00:13
... and it's interactions with the io subsystem. 00:14
dalek rrot: r41458 | jkeenan++ | branches/library_files:
Create a branch to explore solutions for trac.parrot.org/parrot/ticket/1061.
 00:16
darbelo Am I correct that a well-formed strin will have (Buffer_bufstart(s) == s->strstart) ? 00:28
s/strin/STRING/
dalek kudo: 729722a | (Solomon Foster)++ | src/setting/Complex.pm:
Add Complex trig functions not currently shadowed by Parrot complex functions.
 00:33
kudo: 3afb78d | (Solomon Foster)++ | src/setting/ (2 files):
Change from-radians to work on self rather than a passed parameter.
purl dalek: that doesn't look right
kudo: 7a33068 | (Solomon Foster)++ | src/setting/Any-num.pm:
Add Any.atan2.
chromatic Hm, making PMC- and STRING- specific marking functions has the potential to improve branch prediction dramatically. 00:39
Whiteknight getting rid of all those if(PMC_IS_NULL()) calls?
no, i guess he didn't get rid of them, just moved them. nevermind
chromatic Getting rid of the PObj_is_PMC_TESTs.
Austin Why is that wonky? 00:40
Whiteknight wonky?
chromatic It's not wonky, but it confuses the processor's branch predictor.
It also causes a huge number of I1 cache misses.
I cut out 3/4 of the I1 cache misses for the oofib.pir benchmark by exploiting the two marking functions instead of one. 00:41
Try this patch with an optimized build. 00:43
nopaste "chromatic" at 72.87.39.97 pasted "Icache Optimizations in Marking" (57 lines) at nopaste.snit.ch/18053 00:44
Whiteknight just avoiding the extra *mark_PObj_alive calls on all strings would be a huge benefit 00:47
00:47 Austin joined
Whiteknight forget cache optimizations 00:47
purl Whiteknight, I didn't have anything matching cache optimizations
Whiteknight that's cause you're retarded, purl
purl Whiteknight: huh?
chromatic The fun part is realizing that you can *always* remark a STRING as alive. Doing the check and avoiding the remark is silly. 00:48
(with respect to cache writes and COW and... yes, but we don't take advantage of those now)
Whiteknight chromatic: so just commit that patch. looks sane to me 00:49
not necessarily, checking whether the flag is set first prevents a writethrough to main memory 00:50
chromatic Sure, but we're very likely triggering a cache miss even reading it. 00:51
I'd also like to hide the PMC_metadata branch in Parrot_gc_mark_PMC_alive_fun behind the PObj_is_special_PMC_TEST flag and move the marking into mark_special. 00:53
One fewer unlikely test and branch.... 00:54
00:54 TiMBuS joined
Whiteknight I would like to merge mark_special into Parrot_gc_mark_PMC_alive_fun. Creates opportunity to simplify things and prevents an extra function call 00:55
00:55 darbelo left
Whiteknight combine that with removing all the next_for_GC stuff and do the marking immediately while we have the PMC in the cache already to examine it 00:55
chromatic mark_special can be static and inline. 00:56
Whiteknight once we get rid of all the priority marking nonsense, there isn't a lot left of that function to keep 00:57
chromatic Agreed. 00:58
Whiteknight and all PMCs are "special" now, so that whole branch can really be flattened out
at least, that I am aware
dalek rrot: r41459 | chromatic++ | trunk/src/debug.c:
[PDB] Moved two assignments to remove stack variables that give warnings about
rrot: r41460 | chromatic++ | trunk (2 files):
[GC] Improved Parrot_gc_mark_PMC_alive() and Parrot_gc_mark_STRING_alive() such

which means avoiding costly branch prediction misses in Parrot_gc_mark_PObj_alive(). As well, in the -DNDEBUG case, these macros can prevent unnecessary calls for live PMCs and *inline* the STRING marking directly, avoiding the need for function calls. This produced 71.749% fewer icache misses in the oofib.pir benchmark.
ttbot Parrot trunk/ r41460 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/104513.txt ( tt.ro.vutbr.cz//buildstatus/pr-Parrot/rp-trunk/ ) 01:02
chromatic Well that's a downer.
Whiteknight what's a downer? 01:03
purl a downer is probably at hyperarchive.lcs.mit.edu/HyperArchi...downer.hqx OR ftp://ftp.amug.org//pub/info-mac/cmp/downer.hqx
chromatic The ttbot report.
Whiteknight I wonder if some compilers are going to handle the "do if() x; while(0); syntax correctly" 01:05
01:13 s1n joined 01:14 Whiteknight joined
Whiteknight okay, that GC fix froze up miniparrot so hard that is crashed my entire computer 01:14
so...that's a downer 01:15
chromatic Yep, here too. 01:16
It's the normal case.
Infinite recursion?
purl Infinite recursion is probably not TorgoX's friend NOT TorgoX's FRIEND!!!
chromatic I think I found it. 01:22
Whiteknight w00t 01:25
finding it is fundamental
chromatic Yep, that's it. 01:26
Testing the right fix now.
Committing. 01:29
dalek rrot: r41461 | chromatic++ | trunk (2 files):
[GC] Fixed PMC marking in debugging builds by unilaterally moving the

Parrot_gc_mark_PMC_alive_fun().		 01:30
Whiteknight my coretest time is up significantly 01:37
I don't remember when was the last time I tried it, probably a few days ago 01:38
chromatic Faster or slower?
Whiteknight but I was at 37s consistently last time, and 44s consistently right now
no idea why
that's like 20% worse 01:39
chromatic It'd be nice to bisect that a bit.
Whiteknight yeah, would be
chromatic Whoa, Rakudo's "Hello, world!" is some 30.28% faster since my most recent profile. 01:40
Oh, I remember why. I was benchmarking GC tunings. 01:41
It's about 4.26% faster than my best one now.
Whiteknight r41451 and r41452 don't look like they should have affected trunk 01:42
chromatic How about r41441?
Whiteknight urg, it's going to take forever to get back there 01:47
01:55 rhr joined
Whiteknight r41440 was same speed: ~44s 02:03
41441 was same
chromatic Okay, good. 02:04
Hm, not so good actually. That should have improved things.
32 or 64 bit?
Whiteknight 64 02:05
chromatic Okay.
Double the size of the initial pools in the patch for r41441.
Whiteknight those pool sizes should not be calculated using the sizeof() anything 02:07
chromatic I want to align them to page sizes.
Whiteknight right, so just make it x*pagesize
not x*pagesize/sizeof(bullshit)
chromatic I can't think of a downside to that. Agreed. 02:08
Whiteknight it's getting past my bedtime though, so I'll have to try it tomorrow 02:12
goodnight
02:24 japhb joined
dalek ose: r153 | Austin++ | wiki/Cian (2 files):
Wiki updates
 02:25
02:35 janus joined
dalek ose: r154 | Austin++ | wiki/CianLanguageBasics.wiki:
Edited wiki page through web user interface.
 02:35
02:53 Andy joined 02:54 rg1 joined 03:00 rhr joined 03:05 tetragon joined
dalek rrot: r41462 | chromatic++ | trunk/examples/benchmarks/oofib.pir:
[examples] Sped up oofib benchmark by 28.957%.
 03:51
rrot: r41463 | chromatic++ | trunk/src/pmc/fixedstringarray.pmc:
[PMC] Optimized FixedStringArray's set_number_keyed_int() and

creation; this improves the array_access.pir benchmark performance by 13.28%.
rrot: r41464 | chromatic++ | trunk/src/pmc/fixedstringarray.pmc:
[PMC] Optimized FixedStringArray to avoid expensive conversions to and from

array_access.pir benchmark by a further 30.235%.		 03:54
mikehh messages 03:56
04:11 Andy joined
dalek ose: r155 | Austin++ | trunk/ (36 files):
Moved utility classes to library root dir
 04:45
rrot: r41465 | mikehh++ | trunk/include/parrot/gc_api.h:
codetest failures - indented preprocessor directives and space between parens
 04:56
05:20 kyle_l5l left, kyle_l5l_ joined
mikehh All tests PASS (pre/post-config, smoke, fulltest) at r41465 - Ubuntu 9.04 amd64 05:54
partcl r744 builds on parrot r41465 - make test PASS (smolder #28048) - ubuntu 9.04 amd64 05:55
rakudo (729722a) builds on parrot r41465 - make test / make spectest (up to 28400) PASS - Ubuntu 9.04 amd64
06:05 uniejo joined
dalek rrot: r41466 | mikehh++ | trunk/config/gen/makefiles/root.in:
additional test for make fulltest (and make cover) and fix comment
 06:16
06:29 iblechbot joined
treed Does anybody here remember Vera Lynn? 06:59
chromatic Does anybody here hate the implementation of the Class PMC? 07:02
treed I'm not a big fan. 07:04
But... mostly because I can't subclass it from PIR.
chromatic It's fairly ugly. 07:05
It's also inefficient. 07:06
treed Inefficient is the Object Model as I've created it in Cardinal, largely because I can't subclass the PMC.
Each class has a parrot class and a metaclass.
And the metaclass also has a parrot class.
And each of those has a parent class.
I haven't even begun on eigenclasses. 07:07
Shit's *nasty*.
szbalint does anyone hate it? I bet it's not hard to find devs to gang up on old and lonely facets of code :)
chromatic At least Ruby is cleaner than Perl... okay, sorry. I can't keep a straight face here.
moritz ;-) 07:08
treed Cleaner than Perl5, sure.
chromatic Wow. Vestigial variables in this code. 07:09
treed had to actually start using P5 at work.
Banged my head against the desk for a whole afternoon.
Fortunately, Tene's awesome.
07:23 donaldh joined 07:25 fperrad joined
chromatic treed, do you ever have problems with "Object must be created by a class." exceptions? 07:30
treed In what? 07:34
purl IN EXCELSIS DEO
treed I don't recall having seen that before. 07:35
chromatic Just curious about the subclass of Class problems. 07:36
Austin I've hit that one a few times. I think it was while I was getting my brain around the whole class vs. object distinction. 07:37
treed I can't recall what the error was.
Tene might know. 07:41
I think I actually started doing Cardinal Classes as has-a under the general assumption that subclassing PMCs has problems.
Tene actually tested it after he found that out, IIRC.
And found that there are, indeed, problems with subclassinc parrot;Class. 07:42
chromatic I'm not surprised. 07:44
08:02 JimmyZ joined
JimmyZ Is parrot.org down? 08:02
chromatic Looks like it. 08:03
dukeleto 'ello 08:30
08:30 payload joined
dukeleto it was getting hammered by search engines this morning, i think someone contact osu support 08:31
yet another reason for git
chromatic Except I can't dcommit.
dukeleto chromatic: you are thinking git-svn
chromatic True. 08:32
dukeleto chromatic: if we were on git, everyone could still currently commit to their local branches, until the master repo came up
we have a GitObjections page, should we have a WhyGitIsAwesome page? 08:33
everyone could also pull in each others branches that were hosted on other git mirrors
the main repo doesn't stop any development with git, because a "main repo" is only by convention 08:34
s/the main repo/the main repo going down/
chromatic: i have euler_bench setup to test every released version of parrot against each other. 1.6.0 has the fasted interpreter load time, by about 3x than 0.9.0 08:36
chromatic That measures only startup? 08:37
dukeleto chromatic: we have an euler problem 000 that measures interpreter startup, i will give you the raw numbers in a sec 08:38
1.3.0-1.6.0 are all about the same time to start up 08:39
chromatic HEAD should be faster.
dukeleto actually, 1.3.0 seems to be just ever so slightly faster than 1.6.0
chromatic: i can add trunk to the run 08:40
chromatic That'd be handy.
dukeleto chromatic: they are all compiled with "--optimized"
chromatic Good. 08:42
dukeleto i am going to have to use r41351 (what i have) since the server is down
i think i got cachegrind working too, but we will have to save that for tomorrow. i am compiling an optimized trunk now 08:44
chromatic The server's back up now. 08:45
dalek rrot: r41467 | chromatic++ | trunk/src/runcore/main.c:
[runcores] Changed the default runcore to the fast runcore for all builds, not
 08:46
rrot: r41468 | chromatic++ | trunk/src/pmc/class.pmc:
[PMC] Tidied Class PMC's add_parent slightly. It performs less useless work
rrot: r41469 | chromatic++ | trunk/src/pmc/class.pmc:
[PMC] Simplified Class PMC's remove_parent() by replacing manual array resizing

parents.
purl it has been said that parents is a week at least, to be sure
rrot: r41470 | chromatic++ | trunk/src/pmc/class.pmc:
[PMC] Hoisted otherwise duplicate code into static calculate_mro() function.
rrot: r41471 | chromatic++ | trunk/src/pmc/class.pmc:
[PMC] Tidied Class PMC; no functional changes.
szbalint purl still triggers to dalek :S 08:47
purl szbalint: what?
nopaste "dukeleto" at 69.64.235.54 pasted "Euler_Bench #000 for all released versions of Parrot+trunk (intrepeter load time)" (13 lines) at nopaste.snit.ch/18054 09:05
dukeleto looks like 1.6.0 is faster than r41351 by a smidgin 09:06
chromatic Hopefully trunk will beat it back. 09:07
dukeleto chromatic: ok, will check latest trunk, then sleep 09:08
chromatic Ditto.
09:10 bacek joined
bacek o hai 09:10
dukeleto waves at bacek with one foot in his bed 09:11
bacek dukeleto: at least it's not grave :)
chromatic No, but it is serious.
purl okay, chromatic.
dukeleto chromatic: compiling an optimized r41471 now 09:13
bacek It was a big startup time drop in 1.1 09:18
Like 3x times. Looks good
chromatic That was removing PARROT_EXPORT from all vtable C functions.
bacek Ah! I remember it! :) 09:19
dalek rrot: r41472 | chromatic++ | trunk/src (3 files):
[GC] Replaced more Parrot_gc_mark_PObj_alive() with proper typed versions,
chromatic That halved startup time.
We did something else to improve startup time, but I don't remember what gave us the extra 17%.
bacek Anyway. Overall picture is good. 09:20
09:20 iblechbot joined
bacek We just need to remove more PARROT_EXPORTs 09:20
chromatic I wonder if there's a linker option to hide symbols linking against other shared libraries. 09:21
Does that make any sense?
bacek I don't think so... 09:22
09:24 masak joined
chromatic 15% of our symbols visible from nm -g come from libc or gmp. 09:25
bacek Bah... git-svn can't rebase branches properly...
nopaste "dukeleto" at 69.64.235.54 pasted "Euler_Bench #000 for all released versior41472 Parrot+trunk (intrepeter load time)" (12 lines) at nopaste.snit.ch/18056
dukeleto it pretty freakin' close 09:26
dukeleto calls it a night
chromatic: let me know what other data would be useful for ya
chromatic 32-bit or 64-bit machine, dukeleto?
bacek dukeleto: what about real performance not startup time? 09:28
dukeleto chromatic: mbp, so 32-bit binaries, i guess
chromatic 32-bit pointers?
dukeleto chromatic: parrot --version doesn't say anything about it
chromatic Interesting data either way. Thanks!
dukeleto chromatic: does the output of perl Configure.pl tell you the bit-ness? 09:29
chromatic: yes, i will hook it up to some type of graph next
chromatic look for 'ptrsize' in config_lib.pasm 09:30
dukeleto chromatic: 4
chromatic Okay. Good to know.
dukeleto bacek: will give more reports on the other euler bench problems tomorrow, but i did a few preliminary ones and 1.6.0 was doing well. i haven't tried trunk yet on those. 09:32
09:37 allison joined 09:52 gaz joined
dalek rrot: r41473 | bacek++ | branches/pcc_arg_unify_2_0/lib/Parrot/Pmc2c/PCCMETHOD.pm:
Fix access of Context fields in PCCMETHOD.pm
 10:10
rrot: r41474 | bacek++ | branches/pcc_arg_unify_2_0/include/parrot/call.h:
Fix ASSERT_SIG_PMC macro merge conflict.
 10:28
rrot: r41475 | bacek++ | branches/pcc_arg_unify_2_0/src (2 files):
Various merge fixes
bacek Ok. make corevm done 10:31
Epicly failing apparently.
10:47 mokurai left 11:07 quek joined 11:09 whoppix joined 11:17 cosimo joined
dalek rrot: r41476 | bacek++ | branches/pcc_arg_unify_2_0 (7 files):
Recover more stuff from pcc_arg_unify branch.
 11:19
11:53 whiteknight joined, payload joined
whiteknight good morning parrot 11:54
dalek rrot: r41477 | bacek++ | branches/pcc_arg_unify_2_0 (7 files):
Revert "Recover more stuff from pcc_arg_unify branch." bacek-- using
 11:56
whiteknight bacek: what is the plan for pcc_arg_unify_2_0 12:02
?
bacek whiteknight: make it work...
whiteknight so you're copying changes from pcc_arg_unify to the new branch which is updated to newer trunk? 12:03
bacek it's freaking big diff between pcc_arg_unify and trunk...
whiteknight yeah it is 12:04
lots of branches have landed in trunk since pcc_arg_unify was created
bacek I'm actually reviewing all merge conflicts that happened. And looks like I resolved them incorrectly
whiteknight ok
I'm looking over your diff now 12:05
allison is supposed to be writing up a design document for the branch now and should have it posted soon
once that gets posted, we can all make it work
12:13 payload joined 12:14 Austin joined
Austin Good morning, #parrot 12:15
whiteknight good morning Austin 12:16
Austin Today, I hate ... PGE
whiteknight is this what we are doing now first thing in the morning? Saying something we hate?
Austin Dude, this is *so* not the first thing in the morning. 12:17
This is an hour or so into a wumpus hunt.
whiteknight okay, well I haven't witnessed all the non-hate items
so which wumpus are you hunting? 12:18
Austin Here's the bug: $S1 = ".sub anon :anon\\n.param pmc match\\n\\t## Remember end of last ws, in case rule is called 2x\\n\\t\\t$P0 = get_global '$!ws'\\n\\t
Do you see it?
Hint: It's about 8 characters in. 12:19
whiteknight no
still no
Austin Ahh. Well, do you see the .namespace directive?
whiteknight no
Austin THAT'S THE BUG 12:20
whiteknight the bug is...in my brain?
Austin PGE generates all in-line code using this anon-sub eval approach, and it all goes into the root namespace, because there's no .namespace generated for the sub
whiteknight oh, ouch. You can't specify like a :namespace() argument anywhere? 12:21
Austin Nerp. You just type {{ say "Hello, world!" }} and PGE does the rest. 12:22
whiteknight so what you want really is {{ .namespace 'Foo'\\nsayHello, World!" }}?
Austin So I spent 40 minutes hunting for the right incarnation of 07get_hll_global [ 'close' ; 'Grammar' ], '$!ws' only to discover that it's not there.
whiteknight well that is definitely TEH SUXX0RS 12:23
Austin It's actually in 7 get_hll_global '$!ws' - the root variable
So now that I know it, it's easy to work around. But man, it's so wrong.
whiteknight that sounds ot me like a definite bug 12:24
ping pmichaud about it, or create a ticket 12:25
purl I can't find pmichaud in the DNS.
Austin Yeah. I've gotta talk to pmichaud and get his take on it, but I think there's no good reason (other than "it's not worth doing") for having it in the root nsp
whiteknight THAT'S CAUSE YOU'RE RETARDED PURL
That doesn't make any sense to me, why would inline PIR in the grammar be evaled? 12:26
why wouldn't it just be added...inline?
12:26 JimmyZ joined
Austin Because treating it as a sub let's you use it for control flow. Whereas inlining it would require dark magic to manage control flow. 12:27
*let's = lets 12:28
And once you've got <{{ ... }}> doing control flow by eval'ing an anon sub, it's pretty easy to reuse the code for {{ ... }} 12:29
I'd ask, "How was the funeral?" except that I'm pretty sure I know. So, other than the last act, Mrs. Lincoln, what did you think of the play? 12:30
(Or, to put it another way, how are you?) 12:32
whiteknight Doing well, thanks for asking 12:34
it was my grandfather, but the death wasn't any sort of surprise. He was given 2 years to live 4.5 years ago
12:34 payload1 joined
Austin So what have you been up to this week? 12:34
whiteknight mostly personal/family stuff. Haven't had any chance to get hackin 12:36
although I have a huge open window this weekend to code, so I'm looking forward to that
Austin :) 12:37
Did you take the week off from work?
I don't know if you remember a little dialogue you and I had the other day, about (mis)using the #include facility for other purposes in my compiler. 12:40
But it's come to that, now.
bacek oookey... 12:41
Austin I went ahead and wrote the code that creates an empty sub. It was like 40 lines, and a nightmare. 12:42
bacek I reviewed diff between pcc_arg_unify_2_0 and pcc_arg_unify. Unfortunately I can't find anything suspicious.
bacek@icering:~/src/parrot$ git diff pcc_arg_unify_local |wc -l
108642
But I definitely missed something...
Austin chortles at baceks diffitude
Well, it's always in the last place you look. So try line 108640, give or take. 12:43
whiteknight Austin: only took a day off from work 12:45
and came back to a TODO list written in blood on my desk
Austin Well, I guess that means it's important.
Or they would not have used blood. 12:46
whiteknight right, we do have plenty of markers here 12:47
12:52 bluescreen joined 13:11 JimmyZ_ joined 13:23 payload joined 13:34 zerhash joined 13:41 bkuhn joined 13:44 bacek joined
bacek bah. 13:45
13:45 iblechbot joined
bacek Original branch failing in same way... 13:45
bacek spent few hours for almost nothing...
whiteknight time spent on it is not wasted 13:50
what exactly are the failures?
nopaste "bacek" at 122.110.46.45 pasted "pcc_arg_unify failures" (137 lines) at nopaste.snit.ch/18060 13:51
whiteknight oh, great
bacek In nutshell - it's really broken.
whiteknight looking only at the diff, I suspect there is an issue in Parrot_mmd_build_type_tuple_from_sig_obj 13:52
it doesn't look like it is calculating tuple_size anymore 13:53
bacek diff between trunk and branch? Or 2 branches?
whiteknight looking at the complete diff of pcc_arg_unify_2_0 from the time it was created
I need to really look at the source code to make sure 13:55
rg1 msg chromatic r41470 broke the build on sparc (you missed a return statement when you made calculate_mro void)
purl Message for chromatic stored.
whiteknight actually nevermind, it looks like tuple_size isn't used anywhere anymore 13:59
moritz kill it! 14:00
masak its refcount is down to 0, so... 14:06
whiteknight really needs to read the calling conventions PDD again. 14:10
...nevermind, PDD03 doesn't answer any of the questions I had 14:11
there actually doesn't appear to be any documentation anywhere about set_args, get_params, set_returns and get_results 14:14
14:15 Andy joined
bacek whiteknight: pdd03. Line 28 14:16
anyway, $bedtime 14:17
bacek wave from tomorrow 14:18
whiteknight thanks
goodnight
I was hoping for a pasm code example here, but I guess this will have to do
jrtayloriv bacek->sleep(8, "dreams of bacon cheeseburgers");
whiteknight if we had a syntax for PMC aggregate literals in PASM code, the set_* and get_* opcodes would be much more efficient 14:20
goddamn the pcc system is a big damn mess 14:22
14:27 elmex joined 14:31 davidfetter joined
dalek a: d65c92e | fperrad++ | src/pmc/lua (5 files):
use Parrot_gc_mark_PMC_alive & Parrot_gc_mark_STRING_alive
 14:32
14:33 Psyche^ joined, theory joined 14:42 JimmyZ_ joined
dalek rrot: r41478 | NotFound++ | trunk/src (2 files):
[cage] c++ required cast and returnning a value in void function
 14:52
15:11 payload joined
pmichaud okay, should nqp be installed as "parrot-nqp" or as "parrot_nqp" ? 15:11
PDD30:76 gives "parrot-python" as an example, but none of the other parrot* tools use hyphens. 15:12
dukeleto pmichaud: change the docs to say parrot_python? 15:15
purl dukeleto: that doesn't look right
pmichaud that would seem to be most consistent 15:16
I'll do that for now.
dukeleto pmichaud: i am sure asking allison about it would be a good idea too, or at least parrot-dev 15:17
pmichaud looking for use of - versus _ in my /usr/bin/ directory is somewhat enlightening. :) 15:18
i.e., it's apt-get and not apt_get
and ssh-keygen and not ssh_keygen
moritz 745 with -, 200 with _ here
NotFound Given our commitment with unicode, meybe we should use a cuneiform character or something. 15:19
pmichaud 312 versus 54 here
moritz wow, I should really clean up my system at some point ;-)
pmichaud yes, I just did a reinstall last week so mine is fairly clean at the moment :) 15:20
jonathan moritz: Ain't the directory called "bin" 'cus you throw all your trash in it? ;-)
moritz jonathan: ;-)
mikehh NotFound - I made identical changes you did in r41478 - I just wasn't happy about the Class.pmc return; - but it passes all tests 15:26
NotFound: I was going to ask you about that but you did it already 15:28
All tests PASS (pre/post-config, test, fulltest) at r41478 - Ubuntu 9.04 amd64 15:32
pmichaud about now is when I really wish parrot was using git. Maybe I should give git-svn a try. 15:33
(working on new grammar engine stuff)
NotFound mikehh: I did the same, looked if it passed the tests. 15:35
pmichaud (git-svn) bah, too much trouble. 15:36
NotFound mikehh: the other branches don't return anything, so I supposed it was just a mistake not deleting that.
whiteknight I tried git-svn at one point, I don't remember why I gave it up 15:52
tewk pmichaud, git-svn is really easy 15:54
pmichaud I'd need to find an existing mirror or build my own
whiteknight somebody had such a mirror. I want to say it was moritz but I could be wrong
pmichaud right.
I'll just stick with svn and carp about it.
whiteknight yay!
moritz has one, yes 15:55
moritz.faui2k3.org/files/parrot-all...svn.tar.gz
tewk git svn clone -r 41478 svn.parrot.org/parrot/trunk 15:56
will just clone the head.
I'd like to follow your new grammar engine stuff with git. 15:57
you could create a local branch from git-svn and push that to git-hub
pmichaud if I create a local branch from git-svn and place it on github, how hard will it be to get changes back into the parrot svn repo? 15:58
or to keep it up-to-date with parrot trunk?
tewk I do it all the time I can send you a couple of scripts. 16:00
pmichaud that would help
in many ways I'd prefer to develop in my own github account
16:00 MoC joined
pmichaud I just need to know 16:00
(1) how to pull changes from parrot trunk 16:01
tewk Basically, I continually rebase my changes on top of git-svn, I have a script that does that.
script comming
pmichaud (2) when we're done developing, how to push the new features back to parrot repo
if #2 ends up just being "build a huge diff and apply that to parrot svn", I'd be okay with that, too.
whiteknight it sort of stinks that we have to bend over backwards like this to develop in a way we like 16:02
pmichaud whiteknight: I liked your article on the topic :)
whiteknight thanks! It took me like 4 days to write i
it
moritz pmichaud: (1) can be done with dukeleto's git mirror on github, and git-cherry-pick
pmichaud moritz: that sounds like a pain
tewk git svn dcommit will push changes back to parrot svn, assuming you're rebased on-top of git-svn 16:03
moritz pmichaud: it depends on how many changes you want to pull
pmichaud moritz: all of them
I want to stay sync'd with parrot trunk
tewk yeah you have to develop ontop of git-svn to make pushing back to svn easy
pmichaud start by git svn clone -r 41478 svn.parrot.org/parrot/trunk
pmichaud can I just say "head" instead of "41478"? 16:05
16:05 ruoso joined
pmichaud looks like I have to install git-svn, too :) 16:05
tewk apt-get install git-svn 16:06
pmichaud did that.
looks like you have to use the explicit rev number
cloning repo now 16:07
okay, clone done 16:08
cotto_w0rk helo 16:09
tewk git checkout -b new_pge --track remotes/git-svn 16:10
pmichaud ...why the branch?
nopaste "tewk" at 155.98.68.48 pasted "rebase local git changes on top of latest SVN HEAD" (18 lines) at nopaste.snit.ch/18061 16:11
tewk pmichaud, you don't have to you can just use master
pmichaud that would be my preference for now 16:12
I'd like to know the minimum steps needed to get things to work. I can embellish from there.
tewk All that script does is stash local working directory changes while it rebases your work on top of the latest head, and then it pops the local working directory changes back off the stash stack and away you go. 16:13
pmichaud where am I fetching from, in that case?
tewk Parrot SVN
purl Parrot SVN is svn.perl.org/parrot/trunk
moritz if you have a clean working copy, 'git svn rebase' is enough
tewk note its a "git svn fetch" 16:14
pmichaud so, with this approach should I also be pushing to github, or no?
tewk pmichaud, no not yet.
pmichaud so everything stays local?
tewk yeah, but you can push master to git-hub to share your changes 16:15
whiteknight so "git svn fetch" to update from the SVN repo, "git push" to push it to github, and "git dcommit" to commit to SVN repo? 16:16
tewk you will need to push -f to git-hub since you are rebasing on top of PARROT SVN
whiteknight, yes
whiteknight that sounds easy enough
pmichaud I don't understand why -f is needed there
tewk the pushes to github will be non-fast-foward pushes so people
moritz pmichaud: because 'git svn rebase' rewrite history 16:17
tewk because you change history every time you rebase your local changes on top of the latest from PARROT SVN
pmichaud okay.
tewk people pulling from github should use "git pull --rebase"
pmichaud let me try a couple of things
16:18 Zak joined
tewk Because you will be pushing non-fast-foward changes to github 16:18
whiteknight I'm seeing some failed smoke reports on darwin and win32
pmichaud if this is going to cause more people to say "git is more complicated than svn", I'd prefer to not do it
I don't want to provide more reasons for the stick-with-svn crowd to mispoint to "git is harder than svn" 16:19
whiteknight I think we're all intelligent to know that the complication stems from the interplay between git and svn, not from either inividually
pmichaud whiteknight: I'm not so sure about that.
moritz pmichaud: then staying with svn for now is easier
whiteknight I'm smart enough to know that government needs to stay out of my medicare, I'm smart enough to know that git-svn is different beast from git 16:20
pmichaud whiteknight: proving my point, eh? ;-)
whiteknight "Something new and different! Kill it!"
tewk pmichaud, you are developing a patch set on top of the latest SVN HEAD. This workflow is a little more complicated than normal git workflow, but it is a lot easier than maintaing patches or continually rebasing SVN branches to stay up to date with trunk.,
pmichaud tewk: ...except I'm not planning to do svn branches. 16:21
at least, I don't have a need to do svn branches yet.
tewk Yes but thats the VERY BAD alternative to git-svn
You shouldn't do svn-branches
pmichaud huh? 16:22
tewk I'm, agreeing with you.
pmichaud if it's easier to build in svn trunk than to use git-svn, then I should go with that.
The downside is that it's harder for me to make intermediate commits available for others to see. 16:23
for the early stages I could probably do things in an svn branch, and then merge back to trunk when there's a bit more substantial stuff. 16:24
dukeleto tewk: git svn fetch pulls all remote branches while git svn rebase only pulls those needed for the current branch
pmichaud and then work in trunk from there. there shouldn't be many conflicts
tewk dukeleto, I was trying to eliminate network io, when rebasing multiple local branches, looks like git svn was smarter than me. 16:28
dukeleto tewk: it is scare like that 16:31
s/scare/scary/
16:32 jan joined
dalek rrot: r41479 | pmichaud++ | branches/pct-rx:
[pct-rx] Create a new branch for initial regex refactor work
 16:32
tewk dukeleto, its the best patch-set workflow solution I've found, I love it, and have used it everyday for over a year. 16:33
rebasing is a source control "comming of age" skill, once you get it, its wonderfull. 16:34
dukeleto tewk: your script looks useful 16:35
tewk: which branch were you telling pmichaud to use git push -f on ? 16:36
tewk his local master branch, when he wants to push it to github. 16:37
dukeleto tewk: he was pushing to the master github branch then, or creating a new one? I don't think -f should be used on rakudo's master branch on github
tewk dukeleto, Right, this is a different project, it should have its own github repository. 16:38
dukeleto unless it is absolutely necessary and everyone is notified that they need git pull --rebase
tewk: gotcha
tewk And it should be publicly known that the "projectX" github repo is a patch-set continually rebased against an upstream master. 16:39
Parrot SVN in this case./ 16:40
dukeleto tewk: i have a git alias similar to your script: sup = !git stash && git svn rebase && git stash pop 16:41
tewk Looks like pmichaud decided to stick with SVN, which in this case should be very much trouble.
16:42 darbelo joined
tewk dukeleto, yours is much more concise. I was learning git and git-svn when I wrote mine. 16:43
dukeleto tewk: yours will be easier to modify to do more complicated things, and i have a bug. 16:45
if there is nothing to stash, my script pops the *previous* element on the stash, so it only works properly if there is actually something to stash 16:46
tewk: your code goes the extra mile to check that, which is good.
tewk dukeleto, I knew there was a reason I spent time figuring out how to detect changes in the working-dir. 16:51
Now that I think about it, I think I started with your code and ended up with my solution. 16:52
Mine started as a bash alias, but same difference
16:57 particle joined
dukeleto tewk: i could fix it by stashing into a named stash, and then popping it. if the named stash isn't there, the pop should be a noop 17:00
i'm a poet and i don't know it
NotFound Stashing into a stash... Du-du-bi-du-bi.... 17:04
17:05 joeri joined
dalek rrot: r41480 | darbelo++ | trunk (3 files):
[pmc2c] Error out if the pmclass declaration differs form the pmc file's basename. This was previously a warning.

Remove item from DEPRECATED.pod		 17:11
TT #1060 closed by NotFound++: Inconsistent test failures in t/op/annotate.t 17:16
17:25 leto joined 17:30 mokurai joined
dalek ose: r156 | Austin++ | trunk/ (20 files):
NOT WORKING: Refactored Node, moved a bunch of stuff into Types, added
 17:32
TT #665 closed by darbelo++: Pmc2c gets confused when name in "pmclass" line mismatches the filename 17:39
17:41 zerhash joined 17:51 chromatic joined 17:57 kyle joined 18:04 kjeldahl joined 18:06 mberends joined 18:08 cotto_work joined
cotto_work it's quiet 18:40
purl yeah... TOO quiet...
whiteknight MAKE SOME NOISE
cotto_work gjnaiohawjndbnkljfaljbl;dfml;awnghq;jgnasl;gkl;aehb;laejkl;sajahgtukwb
whiteknight I've heard people say Perl is like line noise 18:41
SO MAKE SOME PERL
darbelo Are spam tickets noise? 19:01
I can make a lot of those!
19:01 cotto_work joined
dalek TT #1063 created by darbelo++: pmc2c tests need review. 19:06
19:07 quek joined
darbelo cotto_work: What state was the pmc_pct branch in when it was abandoned? 19:11
cotto_work darbelo, I don't fully recall, but I know that it'll be nearly trivial to bring it in sync with trunk. 19:19
btw, I'm wearing my GSoC shirt.
cotto_work is happy
darbelo is sill waiting on the cotton.
s/sill/still/ 19:20
19:21 cconstantine joined
particle forgot how to match non-newline char with qr//msx 19:22
darbelo [^\\n] ? 19:23
particle ah, i suppose that'll have to do. \\N wasn't working, as that's perl 6 :) 19:24
19:25 AndyA joined
Tene particle: [^\\v] ? 19:25
chromatic Check this, whiteknight.
whiteknight check check it 19:26
chromatic If we allocate all arenas on megabyte (or power-of-two, but let's megabyte) boundaries, we can get the arena holding any PObj with a pointer mask of the low bits.
We can move the GC live/gray/free information into the arena structure and out of the PObj flags. 19:27
It costs a pointer mask more to get at the flags, but during GC (especially stop the world GC), we're not churning the L1/L2 caches with random access patterns.
whiteknight that's interesting 19:28
simplifies the stack-marking code because we can check if a pointer is a PMC with a drastically simplified calculation 19:29
chromatic I didn't even think of that.
whiteknight is there any good way to guarantee that the OS will return us an arena that's aligned on a megabyte boundary? 19:30
chromatic I'm not sure. 19:31
Tene whiteknight: did you ever make a ticket with io cleanups tasklist?
whiteknight Tene: shit, no. I'm retarded
I SWEAR I'll do it tonight
Tene whiteknight: I haven't had any time yet, due to family drama, so no problem on my end. :)
So no hurries. 19:32
whiteknight (family drama) same here.
chromatic posix_memalign?
whiteknight is win32 going to have that? 19:33
and I wonder what the performance of that is compared to a bare malloc 19:34
chromatic mmap() may be easier.
Tene we're not going to be allocating arenas that frequently, are we?
darbelo mmap, (and most other memory allocation) is randomized on OpenBSD. So make sure you have fallback mechanism. 19:35
chromatic OpenBSD doesn't let you specify the address as the first argument? 19:36
darbelo It does, sure. But it ignores it.
chromatic Ah, POSIX... so full of promise and so useless in practice. 19:37
darbelo From the man page: If addr is non-zero, it is used as a hint to the system. (As a convenience to the system, the actual address of the region may differ from the address supplied.)
whiteknight Another idea that's great in theory 19:39
if only operating systems could develop, and actually implement, reasonable standards
darbelo For the record. That is standards-compliant mmap() behaviour as far as I know. 19:40
cconstantine Hey guys, I'm thinking of making a new toy language in parrot on my mac. I have macports and appear to have install parrot (the runtime) with 'sudo port install parrot'. Is it possible to get the devel tools also? 19:42
darbelo Hmm. MAP_FIXED could save you from the address randomization. 19:44
chromatic cconstantine, is there a port called parrot-dev?
I'd rather use MAP_FIXED than sbrk. 19:45
cconstantine chromatic: nope, no port-dev
when I do a 'port search parrot' I get a 'parrot @1.0.0 (lang, devel)'
I'm guessing the lang,devel are options/configurations and I'm further guessing I have lang, but I have no idea how to get to devel 19:46
darbelo The OpenBSD sbrk manpage: The brk() and sbrk() functions are historical curiosities left over from earlier days before the advent of virtual memory management.
Tene cconstantine: 1.0.0 is very old. 19:47
cconstantine :/
so, uninstall the macport and do the manual download thing?
darbelo That would probably be better.
cconstantine k
compiling a checkout from svn... hopefully that is recent enough ;) 19:54
Tene :)
cconstantine: what sort of language are you interested in?
darbelo You could have also used the latest release too. We release every month.
But svn is better than the last release already :) 19:55
cotto_work did allison ever post that doc on pcc_rewiring? 20:05
darbelo I think she was unvailable until tomorrow. 20:06
whiteknight cotto_work: yeah, I think it was due to land Saturday morning 20:21
I'm too excited about these refactors to just wait around forever 20:23
cconstantine Tene: a toy lisp 20:24
Tene: I don't expect it to be really useful, but I need a project
darbelo Why does everyone start with lisp?
cconstantine loves lisp. 20:25
Tene cconstantine: you might want to look at my scheme: github.com/tene/steme/
cconstantine Tene: thanks
Tene cconstantine: or rindolf's fork of it, spark: bitbucket.org/shlomif/spark/overview/
cconstantine hehe
I'll probably just fork it
darbelo jrtayloriv was also working on a scheme recently. 20:26
cconstantine ... or borrow some code... I'm not really looking *for* a lisp, I'm looking to *implement* one
20:26 dukeleto joined
dukeleto 'ello 20:26
Tene hi leto
darbelo Well, PCT will probably make it very easy.
Tene cconstantine: Yes, steme is very basic. Just a s-exp parser and a few builtins. 20:27
cconstantine: it's what I use for my PCT presentations. :)
20:27 ash_ joined
cconstantine hehe 20:27
Tene So, IMO, it's a good first project with PCT.
cconstantine I started on llvm... but I don't really want to write a GC, and interop with both perl and python would be really nice 20:28
I got as far as lex/bison gramar stuffs... didn't get much further
Tene ew, they're no fun compared to PGE. :)
cconstantine it was shades of my undergrad compilers class 20:29
I've spent a grand-total of maybe an hour looking at parrot so I have no idea how easy it'll be, but the docs all make it sound like it's easier 20:30
and more stable... llvm was scary
whiteknight it's rediculously easy
cconstantine llvm wasn't scary for the tech... it was scary because of the docs
whiteknight we're actually going to be using LLVM as our JIT backend eventually. So you'll get all the power and none of the hassle
cconstantine awesome 20:31
I like to hear that
whiteknight yeah, the docs are lousy from what I've seen
of course, our docs aren't much better
cconstantine I don't think I really want an LL vm, I really want a HL vm
Tene cconstantine: The commit log of steme is intended to be an easy intro to building a compiler on Parrot, so should be easy to read.
cconstantine gasps!
Tene: thanks :)
ash_ whiteknight: I have been doing some more work with the llvm-c bindings, they are pretty comprehensive but not at all as easy as C++ 20:32
darbelo say, does steme do macros?
Tene darbelo: No, but I've been doing a lot of thinking about how to do them in PGE. 20:33
cconstantine PGE =? Perl Grammar Engine?
Tene Parrot Grammar Engine
cconstantine ah
whiteknight ash_: we can handle things that aren't easy. So long as it's possible we will make it work
darbelo P usually means Parrot on parrot :) 20:34
cconstantine ok
ash_ when I finish translating the llvm-jit example to C (so it can load llvm-bitcode dynaimcally and jit it) i'll send you a link to show you , its not as documented as it should be though
Tene darbelo: any specific reason you're asking?
darbelo: I'm waiting until after pmichaud's upcoming PGE refactor/rewrite to start playing with it.
whiteknight ash_: Hard part is just figuring out how we want to implement the interface. Do we want a "compile" op, or do we want a "JITEngine" PMC, or something different entirely?
ash_ i am basing most of my translation from the ocaml bindings llvm.org/svn/llvm-project/llvm/tags...ngs/ocaml/
beats me, i am just trying to figure out how it all works together and how it all works with C at the moment 20:35
but i think if you translated the PASM opt codes into JIT operations and ran that it would be pretty efficient 20:36
chromatic Maybe we need a tracing runcore that can hand off a stream of ops to a JIT. 20:37
ash_ but also, the llvm may not be the only way to do a JIT system, once I get a something working with it that JIT's then can try comparing it to libjit 20:40
darbelo Tene: cconstantine mentioned writing a lisp, and that got me curious. I don't really know that much PCT.
What tlittle PCT I know makes me think they'd be tough to get right. 20:43
Tene darbelo: not so much, no.
ash_ whiteknight: blog.fallingsnow.net/2008/05/23/sim...with-llvm/ is what i am doing my example based off of, i have the C++ one working, but I am trying to tralsnate the C++ parts into C, i think its one of the better examples of how to use the llvm-jit system 20:44
whiteknight ash_: Yeah, I printed that out yesterday when you mentioned it and have been reading it intently
darbelo As I said, I don't really know that much PCT.
whiteknight darbelo: it's crazy easy. You should write a small compiler to test it out
Tene darbelo: after you parse a macro definition, you compile it into a match and register it in some global or lexical variable, and then in your parser, you have a rule that checks the global or lexical or whatever variable for alternatives to try. 20:45
Approximately.
whiteknight chromatic: we're going to want an API for it that allows JITing methods as a unit, creating thunks for NCI functions, and compiling programs as a whole for AOT 20:46
ash_ if you run it, it shows the various dis assembled version of the bitcode, its kind of cool seeing how it translates down then how the JIT + optimizations translate it further into 1 body execution with all the functions inlined, it cut the code down significantly when you compare the original 3 functions to the final one that resulted in an inline
whiteknight so an op is probably not right for all that (although certainly interesting possibility!), but a PMC might be
darbelo Hmm. Simpler than I expected. PCT++ 20:47
whiteknight ahs_: yeah, it is a cool example
pmichaud pct will soon get even simpler :)
darbelo pmichaud++ too, then.
Tene darbelo: none of those are actually trivial... I'm hoping that once PGE gets protoregexes, I can just compile macros down into a protoregex.
pmichaud in particular, we should be able to get rid of the Perl6Grammar steps 20:48
whiteknight yeah, soon you'll be able to write a compiler with crayons, construction paper, glue, and elbow noodles
don't get no easier then that
Tene I haven't looked at that in depth yet, though.
pmichaud also, "PGE" may disappear as a standalone component (more) 20:49
more precisely, the new protoregex features will show up in PCT::Regex instead of in PGE
(PGE will continue to exist to provide backwards compat for existing projects)
whiteknight I have a lot of updating to do for Matrixy anyway, so I'll gladly bump it up to use the new stuff 20:50
haven't done any development on it in months, so it needs a lot of TLC
jrtayloriv Anyone know who maintains the PIR .el (emacs lisp) file? 20:51
whiteknight ...nobody?
darbelo jrtayloriv: Firs sucker to ask ;) 20:52
whiteknight leaves. later 20:53
jrtayloriv grrrrrr .... having really annoying tab issues, and I have yet to take the time to learn how to write emacs lisp yet ... but I guess I'll have more luck with all of the reading I've been doing on Scheme lately though ;-)
particle jrtayloriv: svn log is your friend 20:58
or svn blame for that matter
jrtayloriv particle, Ah -- thanks :)
21:01 bluescreen joined
jrtayloriv I'd like to initialize the environment of my compiler with several "builtin" procedures. But I'd like them to be stored in lexical variables that hold references to anonymous subroutines. How can I create a big file that just initializes a bunch of variables like this inside the top PAST::Block? 21:09
(Sorry if that doesn't make sense, I'm still trying to piece together exactly what it is that I want to do here ...)
I could do it by just writing it into the actions.pm obviously, but I'm trying not to clutter it up with hundreds of lines of initialization code. 21:11
I'm looking for some way to just define those variables inside of that PAST::Block from an external file ... 21:12
I see builtins.pir, but I don't think that does what I want (correct me, if I'm wrong about this) ... I want certain symbols (variables) to be bound to standard functions during the initialization of the environment. But those symbols can be changed to point to different procedures (or strings, lists, numbers, etc) afterwards. 21:16
21:17 cconstantine_ joined
dalek cnum-dynpmcs: r187 | darbelo++ | trunk/ (6 files):
Add copyright statements and license comments to pmc files.
 21:17
21:21 bacek joined
darbelo jrtayloriv: you want to be able to rebind the names of your built in functions at runtime? 21:22
jrtayloriv darbelo, Yes, to point to either other functions or to data.
darbelo Why not construct a lookup table? 21:23
jrtayloriv So for instance 'define' is a builtin in scheme, but I can say (set! define 5), and then define just points to the constant value 5 from then on.
Well, I've already got lexical variables, which do exactly what I want (I think), so I just wanted to use those. 21:24
For instance, the way that names are resolved (don't know the "technical" term for this ...) with lexical variables in PIR is exactly how the bindings of scheme's identifiers are looked up. 21:28
darbelo So, your builtins are free-floating pieces of code, and you want to give them names at load-time. 21:29
Tene jrtayloriv: I'd just define the builtins as global functions, possibly in some alternate namespace, and then have a standard program prelude that fetches the builtins into local lexical variables.
darbelo (set! set! set!) ? 21:30
Tene IA! IA! IA! 21:31
cthulhu fhtagn!
jrtayloriv darbelo, Yes - the builtins would just be variables holding references to anonymous subs in the scope of the TOP PAST::Block. 21:33
Tene, So you mean declare them in builtins.pir as usual? 21:34
darbelo I would declare them in builtins.pir under a separate 'compiler-private' namespace.
dukeleto Tene: the hp lovecraft film festival is in Portland in 1 week :) 21:35
darbelo And then have the compiler emmit the pir to initialize those variables to the magic compiler-prive functions. 21:36
jrtayloriv darbelo, Where would I include that file to declare them in the proper scope? 21:37
bah ... I'll come back when I've done a bit more reading, so I can ask intelligent questions. Thanks for the help so far.
darbelo Include files? 21:38
Tene dukeleto: I'll be in Seattle from Sunday to Friday. 21:39
dalek a: 6749a5b | fperrad++ | src/pmc/luatable.pmc:
remove struct LuaHash (refactor with ATTR)
darbelo Hm, does lua work with an installed parrot? 21:43
jrtayloriv darbelo, Yeah, I think my problem is that I'm not grokking namespaces and scoping well enough ... or how actions.pm interacts with compiler.pir ... basically -- I'm really not even sure which questions I should be asking at this point. I'll come back when I am ;)
Tene darbelo: if not, it's a bug, and should be fixed. 21:44
darbelo I cant convince it to find my parrot_config. 21:45
But I just looked in Configure.pl and it seems to think it still lives in the parrot tree. 21:46
Ah, it has to be in the $PATH 21:48
Tene: I think some paths assume lua is still in laguages/ 21:53
Tene darbelo: oops.
darbelo INC contains: /home/darbelo/parrot/lua/t/../../../lib 21:54
making a symlink to lib in my home dir somewhat solves it, but I don't consider it a permanent solution. 21:56
:)
Oh, and the makefile half-misbehaves under non-GNU makes. 21:57
NotFound make: *** No rule to make target `t/lua-TestMore/src/Test/More.lua', needed by `Test/More.pir'. Stop.
This is with gnu make 21:58
darbelo I get that too after fixing the other stuff. 22:01
Tene does lua support modules yet? 22:03
nopaste "NotFound" at 213.96.228.50 pasted "Lua fixes for C++ build" (350 lines) at nopaste.snit.ch/18062
Tene It would be great to add inter-hll support to lua, and add it to our list of inter-compatible languages. :)
22:07 cconstantine_ joined
darbelo It needs some portability touchups in the build department. 22:13
This is Yak #42 in the shaving list. 22:14
As does anything generated with mk_language_shell.pl for that matter. 22:16
dalek rrot: r41481 | mikehh++ | trunk/config/gen/makefiles/root.in:
get make cover to run all the tests make fulltest does
 22:20
Tene argh, I need to just take a full week off to work on Parrot stuff full time to trim down my tasklist. 22:24
mikehh Tene: how about a month :-} 22:25
Tene I wish.
22:34 kid51 joined 22:45 davidfetter joined 22:50 davidfetter joined
dalek rrot: r41482 | jkeenan++ | trunk/config/init/defaults.pm:
Removing old inline comment in order to resolve �rt.perl.org/rt3/Ticket/Display.html?id=41500.
 22:51
22:56 Whiteknight joined
dalek rrot: r41483 | jkeenan++ | branches/library_files/lib/Parrot/Harness/DefaultTests.pm:
Eliminate t/doc/*.t -- directory no longer exists -- from @standard_tests, per comment from mikehh++ in trac.parrot.org/parrot/ticket/1061.
 23:02
23:09 tokuhirom____ joined
mikehh kid51: at the moment I have got make fulltest and make cover running the same tests - see r41481 23:09
23:10 bacek joined
kid51 Okay -- but as I've worked on this TT I've realized that there are a variety of issues involved here, above and beyond Coke's original complaint. 23:11
Mainly: that our notion of what our "default tests" has stretched and become confusing over time. 23:12
A couple of years back, I would have expected @Parrot::Harness::DefaultTests::default_tests to be either: 23:13
(a) the set of tests run by default by 't/harness' without any options; 23:14
and/or
(b) the set of tests run by the most common 'make' target: 'make test'
It turns out that that array no longer describes either t/harness or make test very well. 23:15
As you note in ticket, at one point some npq tests were tacked on to 'make test'
mikehh kid51: yes - I think make test runs an initial test t/op/annotate which I might need to incorporate in make fultest/cover 23:16
kid51 ... and t/harness subtracts tests from @Parrot::Harness::DefaultTests::default_tests in its most basic operation
So I think we need some discussion of what 't/harness', 'make test', 'make fulltest', etc. *ought* to mean. 23:18
How quickly -- or, more likely, slowly -- does 'make cover' 23:19
'make cover' run?
mikehh I can run most of the tests using options like TEST_JOBS=5 - which speeds things up a lot on multicore/multithreaded systems - however you can't do that on make cover - it will blow up 23:20
kid51 I've never actually run 'make cover' -- even though I've done coverage on the configure and build tools hundreds of times. 23:21
mikehh so it takes me about an hour to run as opposed to make fulltest which takes about 10 minutes
kid51 That's what I would have expected. 23:22
mikehh you need Devel::Cover installed
kid51 When I do my configure/build tests coverage, it's probably about the same ratio
mikehh I think bacek has some script that runs it - can't find the url at the moment 23:26
23:36 chromatic joined
chromatic www.modernperlbooks.com/mt/2009/09/...ation.html 23:37
darbelo (Replace Conditional with API)++ 23:43
chromatic Having replaced runtime conditionals with APIs a few times now, I feel confident in my ability to turn a phrase. 23:46
dalek rrot: r41484 | jkeenan++ | branches/library_files/lib/Parrot/Harness/DefaultTests.pm:
Modify documentation to reflect fact that exported arrays hold paths to directories containing files, not files themselves.
 23:53
TT #1064 created by brianwisti++: [PATCH] test documenting difference between $I1 and $I01

Powered by Cro and the Raku® Programming Language.

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

Thank you!