Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
Set by moderator on 1 December 2009.
pmichaud so, is the NQP version creating 10x PMCs during execution as the PIR version? 00:00
chromatic No.
The GC is an order of magnitude more efficient with NQP.
pmichaud sounds to me like it's doing redundant work somehow 00:01
chromatic I agree.
pmichaud when we do a gc run, do we not reclaim all of the garbage pmcs?
tewk conservative collectors can mistake bit patterns for actual references, do you spawn a subbordinate run loop that points to a bunch of garbage that isn't being collected in the pir case? 00:03
pmichaud I mean, if the nqp version is reclaiming 10x PMCs on each run, then either there have to be 10X PMCs being generated between runs, or we're "collecting" the same PMCs over and over
this is all fairly straightforward PIR -- the main way we'd be getting subordinate runloops would be via exception handlers 00:04
tewk or lots of PMCS are marked as live when they really aren't in the pir case
IMCC launches subordinate runloops right?
pmichaud but the load_bytecode example demonstrates that it's not likely due to subordinate runloops
in the load_bytecode example, there's no invocation of imcc, and there aren't any exceptions 00:05
yet it takes significantly longer.
tewk It be interesting to see the number of live PMCS at each GC as well as the number reclaimed. 00:08
chromatic Aha. 00:09
Coke I like it when chromatic says that.
chromatic It's the replenish level. 00:10
In the PIR code, the number of objects per arena in the PMC pool eventually grows from 2048 to 3584. 00:11
In the NQP code, it eventually grows from 10976 to 19208.
The PIR code can reclaim just enough headers that it never bumps up the pool size. 00:12
The NQP code apparently keeps enough headers alive between GC runs that it needs to bump up the pool size and allocate more headers. 00:13
Thus, the NQP code has larger pools and needs to run the GC much less.
pmichaud and so each run reclaims more PMCs
?
chromatic Right. 00:14
More garbage accumulates between runs.
pmichaud that leaves me with two questions then 00:15
tewk Less runs of the garbage collector, less time spent marking.
pmichaud (1) what about the load_bytecode case -- what do the arena sizes look like then? 00:16
00:16 lucian joined
pmichaud (2) does "more garbage accumulation" explain the increased execution time? 00:16
tewk: but what we're seeing is really the opposite (isn't it?). If NQP is doing fewer gc runs, why do the fewer GC runs translate into significantly slower execution? 00:17
chromatic In the PIR code with load_bytecode, the number of objects per arena in the PMC pool eventually grows from 10976 to 19208.
japhb pmichaud, O() > O(n)?
chromatic NQP doesn't run slower for me.
pmichaud it does for me, though.
chromatic I also don't care about wallclock time. It's not accurate enough.
pmichaud chromatic: these numbers are incredibly repeatable on my system though 00:18
every time I run the nqp version, it's 20.5 seconds +/- 0.2
every time I run the PIR version, it's 9.8 seconds +/- 0.2
(this for the case of $N == 28) 00:20
darbelo repeatable != accurate, says the guy that's consistently wrong ;)
chromatic I changed the replenish threshold to 50%, and now the PIR and NQP versions are very close in speed. 00:24
pmichaud what was it previously?
00:25 plobsing joined
pmichaud ...and you're not seeing a 2x difference between the two, right? 00:25
cotto_work What code did you change?
chromatic It was 30%.
pmichaud has anyone else been able to duplicate the results I'm seeing on my system?
(i.e., the NQP version takes 2x longer to run than the PIR version ?) 00:26
chromatic cotto_work, src/gc/gc_private.h line 42
japhb pmichaud, repeat the exact commands you want us to try, and I'll run it on this box (32-bit Linux)
00:26 payload joined
pmichaud japhb: nopasting 00:26
japhb pmichaud, thx
pmichaud (takes me 60 seconds to run :-) 00:28
japhb :-)
nopaste "pmichaud" at 66.25.4.52 pasted "nqp benchmark for others to try" (36 lines) at nopaste.snit.ch/18918 00:29
00:32 jsut_ joined
japhb fib-6.nqp takes 10.977s user time, and fib-6-nqp.pir takes 11.077s user; the pir compile alone takes 0.176s user. 00:33
This is with parrot r42822
pmichaud weird. so your results match chromatic's
nopaste "darbelo" at 190.136.175.208 pasted "OpenBSD i386 results" (13 lines) at nopaste.snit.ch/18919
japhb Worth it to update to HEAD and try again?
pmichaud I think I'm on head, yes. 00:34
or pretty close to it
japhb OK, the compile will take a while
pmichaud r42834
darbelo nopaste.snit.ch/18919 is for r42840
chromatic The only other possibilities I can imagine are a difference for 64-bit machines (plausible, with regard to arena sizes) and uncommitted changes in pmichaud's copy (possible, but less likely).
japhb HEAD appears to be r42840 00:35
pmichaud the only uncommitted change in my copy is the parrotinterpreter.pmc change that chromatic++ suggested earlier
otherwise this is really a brand-new checkout
japhb chromatic, you said you were on 64-bit like pmichaud was ... and I'm on 32-bit (original Core Duo)
chromatic I'm on 32 bit. 00:36
japhb Ah, I misread you earlier then.
pmichaud in fact, it's mostly a brand new system, as I reinstalled kubuntu yesterday and started with fresh checkouts of everything
japhb
.oO( Now would be a good time for my 64-bit system to be not dead )
 00:37
pmichaud I could try it on feather.... wall clock time is very unreliable there, but we should be able to see a 2x difference
japhb chromatic, do arena sizes make any attempt to account for change in word size? 00:39
pmichaud I'll also try it on my notebook (also 64-bit, but a different machine nontheless)
*nonetheless
japhb At HEAD, the results are essentially the same (delta both the NQP and PIR cases being a few dozen milliseconds faster, we must have had some tiny optimizations lately) 00:41
00:41 jsut joined
chromatic Not really. 00:41
japhb shrugs
pmichaud milliseconds aren't significant in wall clock time
japhb Could have been simple variance
pmichaud even full seconds aren't always significant
japhb I wasn't using wall time, but rather user time. But yes, I know that varies too. 00:42
pmichaud right.... my user times vary as well.
er, I should say, my user times show 2x differences
chromatic Let's see how these minor tweaks help. 00:43
nopaste "pmichaud" at 66.25.4.52 pasted "results on my 64-bit notebook (also kubuntu 9.10)" (25 lines) at nopaste.snit.ch/18920 00:45
dalek rrot: r42841 | chromatic++ | trunk/src/gc/gc_private.h:
[GC] Increased replenish threshold to 50%, in hopes of making arenas grow to
 00:46
rrot: r42842 | chromatic++ | trunk/src/gc/gc_ms.c:
[GC] Reversed the free_list check condition in gc_ms_more_traceable_objects()
rrot: r42843 | chromatic++ | trunk/src/pmc/sub.pmc:
[PMC] Explicitly set some Sub attributes to PMCNULL to avoid spurious marking.
chromatic pmichaud, can you time it without the fakecutable? 00:47
pmichaud sure
nopaste "pmichaud" at 66.25.4.52 pasted "fakecutable versus .pbc (notebook, 64-bit)" (17 lines) at nopaste.snit.ch/18921 00:48
"pmichaud" at 66.25.4.52 pasted "fakecutable versus nqp-rx.pbc versus .pir (notebook, 64-bit)" (25 lines) at nopaste.snit.ch/18922 00:50
chromatic How about after r42843?
pmichaud haven't tried that yet
japhb starting recompile as well 00:51
pmichaud (recompiling now) 00:52
00:52 abqar joined
chromatic Looks like a 13.763% performance improvement on the NQP version. 00:52
13.984% on the PIR version. 00:53
nopaste "pmichaud" at 66.25.4.52 pasted "r42483 fakecutable versus nqp-rx.pbc versus .pir (notebook, 64-bit)" (32 lines) at nopaste.snit.ch/18923 00:54
pmichaud r42483 definitely helps the nqp version a lot, doesn't help the PIR version as much
there's still a 40% difference between the two, though. 00:55
japhb Yeah, closed the gap considerably
chromatic GC arena sizes in the 64-bit world then. 00:56
japhb Oh this is interesting
pmichaud I can confirm that on 32-bit (feather) I also see that the NQP and PIR versions have similar execution profiles.
japhb Suddenly, my PIR version got faster (and the NQP stayed the same)
pmichaud so it's something about the 64-bit world that causes the slowdown 00:57
japhb Now fib-6.nqp is 10.741 user time, fib-6-nqp.pir is 8.233 user
chromatic Pointer sizes and the objects-per-pool calculation.
japhb So my NQP time dropped by about .2s, and the PIR version dropped from 11.077 to 8.233 00:58
chromatic Whiteknight mentioned that a while back. We need to get that sizeof (PMC *) out of there.
msg whiteknight It's time to fix the number of initial headers created in the GC -- no more relying on pointer sizes. 00:59
purl Message for whiteknight stored.
pmichaud the load_bytecode still causes the execution profile to slow down significantly, though 01:00
I guess because it increases the objects-per-arena
I can turn this into a PIR program that we can use for more profiling tests 01:01
chromatic That'd be handy. 01:02
pmichaud I wonder if I should go back to 32-bit on my desktop, though. 01:05
I suppose I could install 32-bit on an empty partition just to see how it compares to 64 bit 01:06
Coke hurls www.childsplaycharity.org/ in case anyone here is a gamer and doesn't know about it. 01:08
japhb They're doing quite well this year, I see. 01:09
chromatic vanishes for a bit 01:10
nopaste "pmichaud" at 66.25.4.52 pasted "fib-6 benchmarks and timing, 64-bit desktop (for pmichaud)" (37 lines) at nopaste.snit.ch/18924 01:12
pmichaud time to do a 32-bit install 01:13
01:30 kid51 joined
Coke kid51: hey 01:37
01:37 brrant joined
dalek rtcl-nqp: f5f5537 | (Will Coleda)++ | TODO:
add to pile
 01:38
rtcl-nqp: 03b8836 | (Will Coleda)++ | src/PmTcl/commands/info.pm:
Add basic [info commands]
rtcl-nqp: 78524e7 | (Will Coleda)++ | (3 files):
add stubs for [package]
Coke wonders how to implement an op that isn't a :pirop 01:45
cotto ponders the koan of the op which isn't an op 01:47
01:49 JimmyZ joined 01:58 Limbic_Region joined 02:13 mikehh joined
Coke pmichaud: hurm. running the N tests we can run, partcl is taking 7.77s, partcl-nqp is taking 10.2s (using -q on partcl to stop the load of the stdlib to make it a fair fight.) 02:13
japhb That seems not too bad considering you went up a level in implementation language 02:15
Tene Coke: explain what you want to implement? 02:18
Coke Tene: I want to have == call a function in NQP, not be directly mapped to a pirop.
02:19 mikehh joined
Tene PAST::Op.new( :pasttype('call'), :name('function'), ... ); ? 02:19
Coke token infix:sym<==> { <sym> <O('%equality_numeric, :pirop<iseq Inn>')> } 02:20
02:21 Andy joined
Coke japhb: it's also doing a hell of a lot less. it's only going to get slower, I fear. 02:22
Tene Oh, the .O stuff... I don't understand that part yet. 02:24
Coke: I'll keep a watch for that and get back to you after I've converted abc and squaak.
Coke Tene: danke. 02:35
03:16 JimmyZ joined 03:45 allison joined
dukeleto msg japhb what is up with this? gist.github.com/246915 03:51
purl Message for japhb stored.
japhb dukeleto, that's ... odd 03:52
dukeleto japhb: my luck 03:54
japhb I don't know if it matters, but I'm up at Parrot r42843 now 03:55
Actually, let me recompile and make sure nothing broke recently
dukeleto japhb: sounds good
japhb Yep, looks good, and all tests passing
(not that we have nearly enough tests, mind you ....)
dukeleto japhb: how do you feel about getting a faster test harness for plumage, written in PIR instead of NQP? 03:56
japhb Sounds fine with me ... but remember, it either has to ship with Parrot or Plumage. No external project dependencies. :-) 03:57
dukeleto japhb: this faster one also has tests, which currently our harness does not have
japhb nodnod
dukeleto japhb: no external deps other than parrot :)
dalek rrot-plumage: 939edf9 | leto++ | :
[cage] Get rid of useless slurp()'ing of the test file in t/harness
dukeleto japhb: github.com/leto/tapir
tapir?
purl somebody said tapir was being written to be testable from the ground up, unlike nqpTAP
japhb I assume you mean Tapir. Which means you ought to get Tapir snapshotted into Parrot RSN. ;-)
dukeleto japhb: i think it is easier to get tapir into plumage first. plumage has simpler needs 03:58
japhb So ... I can't replicate your Plumage build fail right now.
make realclean and start over?
I'm fine with copying Tapir in
dukeleto japhb: yep. i was using an installed parrot and that is probably the issue
japhb: sweet. it is very close to being ready 03:59
japhb Since you're a Plumage committer, the copyright issue should go away
I always use an installed parrot.
dukeleto japhb: you don't use --parrot_config=... ?
japhb never
On the short list of Plumage features: upgrade parrot, upgrade itself, and then upgrade all the installed projects. 04:00
japhb short on tuits ATM
dukeleto japhb: yes, tapir is artistic 2.0, but snapshots can go into parrot or plumage since I am a parrot committer, correct? 04:01
04:01 allison joined
japhb Right. If the license is the same, and you've done a PaFo CLA (which you must have, to get your Plumage commitbit), there's no issue. 04:01
dukeleto japhb: sounds good, just checking. it is the same setup as nqp-rx 04:02
japhb nodnod
dukeleto japhb: what do you need help with on plumage that i can actually do?
japhb #1 is write tests 04:03
dukeleto purl, tapir is also github.com/leto/tapir
purl okay, dukeleto.
dukeleto japhb: i have a general idea of writing tests for nqp-rx and plumage. which are most useful to you in nqp-rx? 04:04
japhb You should be able to write tests for Glue.pir, Util.nqp, and Plumage/Metadata.nqp at the very least. Possibly the other Plumage/*.nqp as well, but I haven't worked hard on testability of those yet.
Wait, tests *of* nqp-rx?
dukeleto japhb: yes, tests in the nqp-rx repo
japhb: i have a commit bit for that as well ;)
japhb: does Glue.pir get installed anywhere? 04:05
japhb: i basically have a copy of qx() in tapir and it would be nice if some library provided that instead. but then dependencies/etc.... 04:06
japhb Oh, I dunno. I mean, if you want to do forward-looking tests for NQP-rx (meaning, tests of stuff we *want* as opposed to already there), look at wiki.github.com/perl6/nqp-rx/plumage-requests
#1 request there is Full hash literals / constructors
Right now, ironically enough, nothing in Plumage installs anywhere. It is on my list for Parrot 2.0 to make Plumage installable and snapshot it into Parrot just as NQP-rx is. 04:07
I don't think I can make it by 1.9, but I suppose hope springs eternal.
dukeleto also known as icanhaz.com/plumage-requests
japhb dukeleto, well OK then. 04:08
Do you own icanhaz.com?
dukeleto japhb: no.
japhb: just a random url shortener
japhb Oh, I see the credits at the bottom, got it. I just figured one of the #parrot crew had to be an owner, because we keep using that site, when other url shorteners are much ... well ... shorter. 04:09
dukeleto japhb: you can use whatever site you want. I just end up making short url's first and that is what i use :) 04:10
japhb :-)
dukeleto japhb: feel free to optimize the length of our short urls >;) 04:11
japhb heh
When I need really, really short I use j.mp
dukeleto wowzers
owned by twitter, though 04:12
i defer from the big url shorteners because i don't want to be their link juice
japhb nodnod 04:13
dukeleto i call shenanigans on our priority this week
i went to the wiki page, and i have no idea how to help
japhb I wish there was a url that short owned by the good guys
dukeleto ENEEDMOREDIRECTIONS
japhb And in truth, the real priority seems to be "Make GC & PCC performance suck less" 04:14
dukeleto japhb: xrl.us is run by a perl hacker
why the junk is this weeks priority classvtableoverrides then? 04:15
japhb Might have been set prior to pmichaud & chromatic's discoveries today 04:16
(and never updated)
dukeleto interesting, i haven't backlogged 04:19
japhb dukeleto, also check email, the whole thread starts there 04:20
04:25 JimmyZ_ joined
dukeleto japhb: yeah, i took a break from email for a few hours :) 04:26
japhb silly boy 04:27
cotto The priorities discovered earlier today don't really apply to people not interested in gc hacking. 04:28
though I'm sure this would be an excellent time to dive into writing a new gc if anyone were interested
04:29 JimmyZ_ joined
japhb cotto: or PCC hacking, or profiling analysis, ... 04:29
cotto or those 04:31
dalek TT #1090 closed by dukeleto++: Convert t/pmc/exporter.t to PIR 04:33
04:33 JimmyZ__ joined
Tene dukeleto: getting plumage installable would be great. japhb has expressed concern over getting that done before 1.9 04:34
dukeleto Tene: yes, it would be
Tene If you're looking for a priority. >.> 04:35
dalek TT #1114 closed by dukeleto++: [patch] Converted some tests from perl to pir 04:36
dukeleto parrot compiles warn with ./src/pmc/callsignature.pmc: In function ‘Parrot_CallSignature_set_integer_keyed’: 04:42
japhb dukeleto, Tene: One task would be to get consensus on which directory Glue.pbc and Util.pbc ought to be installed into. I suppose we could just put them into Plumage/ in the lib dir, but they are more general than just for Plumage (any remaining vestiges of Plumage-only-functions can be easily pulled out and moved elsewhere) 04:43
But if not within Plumage/, they need better names. 04:44
Tene I still vote for Plumage/
Other tools can still load Plumage::Glue
japhb Fine by me, I don't really care ... but others might 04:45
Tene What objections do you imagine others might have?
dukeleto the code began as glue for Plumage, seems about right
japhb tries to pick his battles ... but the first step is knowing what might be a battle in the first place
dukeleto we could call it HLL::Glue
japhb dukeleto, yes, but it is way more than that now. I've implemented grep, map, reduce, ... 04:46
Then again, any real HLL would have their own version of same
dukeleto japhb: what have you done in PIR and what is in NQP?
Tene japhb: so maybe Bootstrap/Utils?
dukeleto yes, but what about qx() ?
japhb I've tried to make Glue.pir only contain stuff that is a pain to write directly in NQP. Everything else has been moved to Util.nqp at this point. 04:47
(And if NQP-rx ever implements a wrapper around root_new, another big chunk of Glue.pir can go away.) 04:48
Maybe NQP/Glue and NQP/Util ?
Actually, that feels decent as a namespace. 04:49
Says what it's for, and all that.
dukeleto japhb: i like it 04:50
japhb (BTW, the comment about root_new above is because root_new wants a key, but is not a keyed aggregate)
OK, that I can do in a bit.
$day_job still going for a little longer
dukeleto japhb: same error after 'realclean' 04:51
japhb WTF?
OK, what was that nopaste link again? 04:52
dukeleto japhb: gist.github.com/246915
japhb And you've got a recent pull of plumage? 04:53
dukeleto japhb: 939edf9, the latest 04:54
japhb OK, what if you realclean and configure with parrot-nqp instead of nqp ? 04:55
dukeleto japhb: i am recompiling nqp-rx again after nuking my installed parrot. i will try that next
japhb OK 04:56
plobsing does parrot have fork? 05:00
japhb plobsing, I doubt it. spawn and pipe open, but probably not fork, since it's not easily portable 05:02
dukeleto plobsing: docs/pdds/pdd25_concurrency.pod
config/gen/platform/generic/exec.c 05:03
42: child = fork();
looks like we use fork() in exec() but don't expose a fork() opcode
plobsing: what do you need to do?
plobsing well i was hoping to spawn off 2 children and pass a frozen PMC between them. 05:04
the important part is the thawing side not to have the packfiles of the freezing side
also I'd been thinking it would be nifty to fork and run independant tests (within the same file) in different processes 05:05
that way when I crash the interpreter, I still see all the test results
for PIR tests 05:06
dukeleto plobsing: funny you should ask about that :)
tapir?
purl tapir is probably being written to be testable from the ground up, unlike nqpTAP or github.com/leto/tapir
plobsing thats a harness no? 05:07
dukeleto plobsing: yes. so it is maybe not exactly what you are talking about, but i need the same stuff
plobsing my problem is test files that have an interpreter panic halfway through
and I want to work around that
dukeleto plobsing: spawnw() is probably what you want
plobsing: then what you want *is* on the tapir TODO list 05:08
plobsing: it won't be easy, but it will be worthwhile, if you want to work on it 05:10
plobsing which item in the TODO list does that fit under? and more importantly, how can the harness uncrash the tester?
dukeleto plobsing: so if i hear you, you want each test in each test file to be run in a seperate parrot process, such that if a test causes a segfault, only one test dies and not the rest of the file 05:11
plobsing: correct?
plobsing more or less. some tests should run in the same process if they are tightly coupled
dukeleto plobsing: now you might be asking for too much ;) 05:12
plobsing: then those should be put in the same test
plobsing I didn't expect it to be possible
its more of a wishlist item
dukeleto plobsing: it is a wishlist item for tapir. it is much easier and a bigger return on investment to get parallelizing on files working, though 05:13
plobsing depends on who measures those returns ;-)
dukeleto plobsing: but that doesn't solve your issue, it just makes the test suite a shit ton faster
plobsing: yes, i agree. the speed increase doesn't matter in your situation, other than you can run+crash the suite much faster ;)
plobsing dukeleto: my test suite already runs a shit ton faster than yours, because half the files crash 1/3 of the way through 05:14
dukeleto plobsing: nice!
plobsing: are you using coretest? 05:15
plobsing coretest doesn't work
dukeleto plobsing: in which way does it not work?
plobsing some tests in coretest use like() which depends on PGE, which isn't build by corevm
so make realclean; perl Configure.pl; make -j3 coretest = FAIL 05:16
05:16 TonyC joined
dukeleto plobsing: tell me which ones and i will fix that 05:17
plobsing: i think some people that are translating tests do not know that tests in coretest can only use a subset of test_more.pir . that is not really written down anywhere
05:18 nopaste joined
dukeleto we a flag in test files that are in 'coretest' so that devs know they can only use a subset of test_more.pir, and that subset should be written down somewhere 05:19
plobsing not sure if it's warranted, but what about a 'test_core.pir'
dukeleto s/we a/we need a/
plobsing: that could actually work
japhb: same stupid error. i will try parrot-nqp next 05:20
japhb nod
05:24 TonyC joined 05:26 TonyC joined
plobsing nopaste? 05:27
purl nopaste is at nopaste.snit.ch/ (ask TonyC for new channels) or paste.scsys.co.uk/ or App::Nopaste or tools/dev/nopaste.pl or at www.extpaste.com/ or paste.scsys.co.uk (for #catalyst, #dbix-class, #moose and others) or gist.github.com/ or paste or gtfo or tools/dev/nopaste.pl or trac.parrot.org/parrot/browser/tru...nopaste.pl
05:27 nopaste joined
plobsing dukeleto: here's the stderr from 'make coretest' nopaste.snit.ch/18929 05:28
it contains the backtraces that show all the places PGE is used in core tests 05:29
dukeleto i get a passing TODO in t/pmc/complex.t on darwin/x86, i think someone was asking about that 05:45
japhb: it got a lot farther with parrot-nqp gist.github.com/246979 05:47
japhb: and that is my fault 05:48
japhb dukeleto, well, that's good and bad.
Yeah, something is really goofy that config.fpmc is not there
dukeleto japhb: because i am not using an installed parrot, just the compiled binary in the repo directory.
japhb NAUGHTY 05:49
dukeleto is naughty
japhb Just set --prefix during parrot configure, and then you can easily install to a nice safe place.
I use --prefix=/usr/local/parrot
dukeleto japhb: ok, back on track. got the latest nqp-rx and the latest plumage working and passing their test suites 05:51
japhb yay ....
plobsing fpmc? 05:52
japhb "frozen pmc"
dukeleto shudders from a cool wind across the nape of his neck 05:53
plobsing oh. good. I was wondering what to call those. I've been calling them x.freeze, but it didn't seem right.
dukeleto how do I /bin/sh -c foo.t without foo.t having to be executable? 06:03
i need a way to run tests in any language, via the shebang line
plobsing perl handles shebang detection itself 06:07
and automatically dispatches
perl foo.t
dukeleto plobsing: oy vey
plobsing: but you are right, i have seen that trick
plobsing: it doesn't seem to work, for a different reason. it can't find parrot-nqp, even though it is in my path 06:12
japhb I've run out of steam. dukeleto, feel free to ping me tomorrow about moving Glue/Util and seeing if we can get to installable Plumage
dukeleto PATH=/usr/local/bin perl t/01-sanity.t
Can't exec parrot-nqp at t/01-sanity.t line 1.
japhb: sounds good
07:13 JimmyZ joined
JimmyZ hello cotto. 07:14
07:17 uniejo joined 07:21 chromatic joined, theory joined
JimmyZ I want to hack all PMCs, to unify them into using the same way to get PMC class attr. ie. hash.pmc one way in PMC its self is by using PARROT_HASH(SELF) and another by using GET_ATTR_Hash, which way should I take? 07:22
Did I describe clearly? 07:23
chromatic GET_ATTR_Hash 07:25
JimmyZ chromatic: I saw the codes, the difference is that the former doesn't use PObj_is_object_TEST to avoid Attributes of type being subclassed from a high-level PMC 07:28
chromatic Right; the latter is more subclassable. 07:31
JimmyZ chromatic: So I am confused, if we should always check atrrs for subclassable in hash.pmc its self, or just use GET_ATRR when get attr from other pmcs? and the former seems to be more agile 07:34
s/if/do/
dalek TT #1342 created by dukeleto++: [RFC] make a test_core.pir that tests which are part of coretest use, ... 07:35
chromatic Within PMCs, the GET_ATTR syntax is the best approach. 07:42
JimmyZ yes, but GET_ATTR losts a bit performance.;) 07:47
chromatic If that's our worst performance problem, we're in good shape. 07:48
JimmyZ thanks, I will try change them to use GET_ATTR 07:50
s/try/try to/ 07:51
07:56 bacek joined
bacek o hai 07:56
dukeleto bacek: hola 07:58
bacek aloha dukeleto
dukeleto bacek: are you working hard in the merge mine? 07:59
bacek dukeleto, not yet. But I'll start pretty soon
dalek zy-k: 0df29e5 | bernhard++ | (2 files):
Configure.pl and t/harness are no longer needed.
 08:00
dukeleto bacek: music to my ears. what do you think of this? trac.parrot.org/parrot/ticket/1148 08:01
bacek: should I attempt to push that in before the merge? it is useful?
08:01 iblechbot joined
bacek dukeleto, it makes sense. 08:02
dukeleto bacek: seems like those bugs will exists after the merge, might as well apply a patch that fixes them while it still applies, right ?
bacek yes, of course
dukeleto bacek: ok, i will apply now and see if the test suite passes
bacek ok 08:03
dalek lambda: cec1e90 | bernhard++ | t/harness:
t/harness and Makefile are no longer needed.
 08:04
zy-k: 8846a21 | bernhard++ | MAINTAINER:
Updated MAINTAINER.
 08:06
08:08 cotto_w0rk joined
dalek lambda: 952393c | bernhard++ | MAINTAINER:
Updated MAINTAINER.
 08:10
lambda: 6a4daae | bernhard++ | .gitignore:
Makefile is no longer generated.
08:11 fperrad joined
dukeleto bacek: coretest passed. i am running fulltest now 08:13
08:21 fperrad_ joined
JimmyZ chromatic: then when do pmcs need to use PARROT_HASH? 08:29
chromatic That was a convenience macro for the Hash PMC that was a little bit more typesafe than PMC_data(SELF). 08:30
It predates the new PMC attributes.
JimmyZ chromatic: should I repalce it by using GET_ATTR syntax ?
chromatic Yes. 08:31
JimmyZ chromatic: then I think I can remove PARROT_$pmcname syntax entirely . 08:32
bacek dukeleto, any luck with fulltest?
JimmyZ chromatic: another quesiont is: when getting attrs, should all pmcs always to use PObj_is_object_TEST for checking ? 08:33
dukeleto bacek: yep, just finished :) will commit now 08:34
bacek dukeleto, ok
JimmyZ s/quesiont/question/
chromatic Within the PMC, you can use the macro directly. It gets translated appropriately. 08:35
JimmyZ chromatic: I think it's the last question about it for me . ;)
dalek rrot: r42844 | dukeleto++ | trunk (2 files):
[TT #1148] Implement 'clone' method for CallSignature, flh++
 08:36
JimmyZ chromatic: which macro? PARROT_$pmcname or GET_ATTR?
chromatic GET_ATTR 08:37
dukeleto bacek: ok, callsig is all yours :)
bacek dukeleto, branching now :) 08:38
chromatic You don't have to do any checks. The PMC translator will add them for you.
Is this the new Context/CallSig merge branch?
JimmyZ chromatic: so I can remove PARROT_$pmcname syntax within PMCs?
chromatic Yes.
dalek TT #1148 closed by dukeleto++: Implement "clone" method for CallSignature 08:39
rrot: r42845 | bacek++ | branches/cs_csr_merge:
Branch for merging CallSignature and CallSignatureReturns
JimmyZ chromatic: and So I can remove the PARROT_$pmcname macro from the source codes, I think.
chromatic Yes.
JimmyZ chromatic: thanks, I will do it. 08:40
chromatic Excellent.
JimmyZ hopes that'is the correct way.
chromatic I'll review the patch to make sure. 08:42
JimmyZ chromatic++
08:43 payload joined 08:52 cognominal joined
dalek rrot: r42846 | dukeleto++ | trunk/NEWS:
[cage] Make a skeleton for the news for 1.9.0 and start filling in what I know
 08:52
rrot: r42847 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Copy CSR attributes into CS.
rrot: r42848 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Reorder CS.mark and .destroy to be closer to .init.
rrot: r42849 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Destroy CS.returns_values
dukeleto bacek++
dalek rrot: r42850 | bacek++ | branches/cs_csr_merge/src/call/args.c:
Copy CSR VTABLEs into src/call/args.c prepending csr_ prefix.
 09:19
09:39 payload joined
dalek rrot: r42851 | bacek++ | branches/cs_csr_merge/src/call/args.c:
Make headerized happy again in src/call/args.c
 09:43
rrot: r42852 | bacek++ | branches/cs_csr_merge/src/call/args.c:
csr_set_string_keyed_int can accept NULLs.
rrot: r42853 | bacek++ | branches/cs_csr_merge/src/call/args.c:
Switch from CSR to CS in building returns.
09:44 bacek joined
dalek rrot: r42854 | bacek++ | branches/cs_csr_merge (2 files):
Remove CallSignatureReturns
 09:46
rrot: r42855 | bacek++ | branches/cs_csr_merge/MANIFEST:
Update MANIFEST...
 09:53
rrot: r42856 | dukeleto++ | trunk/t/op/inf_nan.t:
[t][cage] Remove PGE-dependence from t/op/inf_nan.t since it is part of 'make coretest'
 10:03
rrot: r42857 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Pacify compiler about default case in CallSignature.clone
rrot: r42858 | bacek++ | branches/cs_csr_merge/src/pmc/callsignature.pmc:
Remove old results storage from CallSignature
rrot: r42859 | dukeleto++ | trunk/t/op/number.t:
[t][cage] Remove PGE-dependence from t/op/number.t since it is part of 'make coretest'
 10:10
JimmyZ Improved Algorithms for String Searching Problems: lib.tkk.fi/Diss/2009/isbn9789512298884/ 10:37
diakopter++ for share 10:38
10:42 mikehh joined 10:51 bacek joined 11:34 riffraff joined 11:40 payload joined
mikehh All tests PASS (pre/post-config, smoke (#30407), fulltest) at r42859 - Ubuntu 9.10 amd64 (g++ with --optimize) 11:57
12:11 JimmyZ joined 12:25 bluescreen joined 12:39 jsut joined 12:42 whiteknight joined, bluescreen joined 12:48 JimmyZ joined
dalek rrot: r42860 | bacek++ | branches/cs_csr_merge (4 files):
Move append_result function from src/extend.c into src/call/args.c
 12:59
rrot: r42861 | bacek++ | branches/cs_csr_merge/t/pmc/callsignaturereturns.t:
Remove test for CallSignatureReturns
rrot: r42862 | bacek++ | branches/cs_csr_merge/t/pmc/callsignature.t:
Remove test for C<returns> attribute in callsignature.t
13:01 bluescreen joined
bacek anyone alive here? 13:04
moritz no, I'm undead 13:05
sjn we are all bots
pmichaud (barely alive)
moritz barely alive, barely kicking :-) 13:06
bacek heh :)
sjn "anyone alive here?" should be the first question of any turing test
bacek cs_csr_merge branch need some love 13:07
Parrot_pcc_merge_signature_for_tailcall is badly broken
whiteknight good morning bacek
13:07 lucian joined
bacek because we share same pointer between different CallSignature 13:08
(and I'm falling asleep...)
pmichaud ...it's snowing here. 13:10
szbalint lucky :S
bacek pmichaud, no way! It's second day of summer!
szbalint I want to have snow too, but alas there is none
pmichaud This is Dallas. Dallas, Texas. We don't normally get snow here in December. 13:11
szbalint this is Wien, Austria 13:15
bacek snow... Is it some problem with "Dihydrogen monoxide"? 13:18
szbalint the silent killer. 13:25
13:26 ruoso joined, iblechbot joined
moritz in the course of human history, more people have died from Dihydrogen monoxide than from car accidents 13:26
Coke msg dukeleto those test_atan changes look wrong. You should probably use the .fp_eq macro instead. 13:27
purl Message for dukeleto stored.
13:28 bluescreen joined
whiteknight purl msg chromatic: We need to figure out how many headers are used for startup, and how much are used for common applications (NQP startup) 13:35
purl Message for chromatic stored.
pmichaud ...noting of course that nqp itself isn't a "common application" :) 13:36
JimmyZ common languages :)
moritz re PIR and __END__ 13:40
iirc there's an include mechanism for PIR files
Coke .include '', yes.
13:41 payload joined
moritz what would happen if you include a PIR which contains an __END__ marker? 13:41
Coke in the current scheme of .include, it would affecting the including file as well.
*affect
moritz which would be rather bad, IMHO
Coke but I imagine you could redefine it.
moritz anyway, I don't want to argue any way, I don't use PIR enough for that. I just want to point out that these things should be thought of 13:42
dalek rrot: r42863 | mikehh++ | trunk/t/pmc/complex.t:
correct a failing test that indicated a TODO pass - t/pmc/complex.t
 13:45
Coke hurm. particle commented but didn't vote. 13:57
particle my vote depends on the answers, but is likely -1. pir is an assembly language, funky text blocks don't belong 13:58
Coke see, my vote depends on the fact that we have to expend energy /thinking/ about those answers. =-) 13:59
particle i like the 'split subroutine body over two files' edge case. that grabs people. 14:01
14:02 JimmyZ_ joined 14:05 lucian joined 14:19 whiteknight joined
whiteknight I like the idea of __END__ because I like thinking we could use the extra space to store additional data and metadata about a file 14:20
pmichaud I'd rather have a start/stop marker for that, rather than just __END__ 14:21
something like: "=data" ... "=cut"
moritz we could also ask ourselves if evolving PIR is the right direction to move 14:22
PerlJam good morning 14:28
someone wants to add __END__ to PIR?
JimmyZ yes, there is a ticket.
PerlJam weird.
whiteknight when you think about *real* assembly languages, they usually give you the ability to specify where things go, like the data section, text section, code section, etc 14:30
pmichaud: yes, I do like the idea of stop/start markers for it 14:31
Having a literal section in PIR code that contains the HLL code that was compiled would be great for producing meaningful annotations, for instance 14:32
pmichaud oh. I figured that would just be .annotate "source", "....source here..."
whiteknight places where we could specify lists of literal strings would be great for i18n among other uses
PerlJam I'd bet that most PIR is machine generated rather than human generated. If that's true, what would the machines use something like __END__ for? Just a place to store static data? And then how would that data be accessed?
whiteknight I still hold out for ways to specify PMC aggregate literals, and a separate section (and therefore possibly a separate parser) would be ideal for that 14:33
14:33 mikehh joined
PerlJam whiteknight: aggregate literals sounds useful, but it also doesn't sound like __END__ :) 14:34
Coke whiteknight: that belongs in the PBC, not the PIR.
whiteknight PerlJam: I'm past __END__ now, looking more at specific file "sections" with start/stop markers
Coke: But how does it get into the PBC? Need a way to specify the literal in PIR to be compiled into PBC 14:35
14:35 lucian joined
Coke which portion of the PBC doesn't have a way to get that information into it? 14:35
whiteknight Coke: I think we're talking about different things
Coke whiteknight: you want to add something to the PIR; I'm saying that the ultimate place for that sort of thing is in the bytecode; what good is it if it's just in the pir? 14:36
and if it's ok just inthe pir, why not just put it in pod?
whiteknight Coke: We need PIR syntax to specify the kinds of things we want to add to PBC
Coke what specifically are you trying to add?
whiteknight PBC has ways to hold that kind of stuff
Coke ok. which section of the pbc do we need pir syntax for? 14:37
particle if it's in pbc, it must be in pasm
whiteknight Coke: you're misunderstanding me
Coke whiteknight: not on purpose.
09:37 <@whiteknight> PBC has ways to hold that kind of stuff
which stuff?
which stuff that is not specifiable via pir?
whiteknight I'm not talking about PBC. no talking about PBC 14:38
particle come up with the pasm solution first, then address pir
whiteknight forget PBC
purl whiteknight: I forgot pbc
whiteknight thanks, purl
purl pas de quoi whiteknight
Coke storing stuff in pir only is not a good idea.
it's just comments at that point.
whiteknight nobody is talking about that either
Coke ok. then I have no idea what you're talking about. =-)
particle pbc is an acronym for the parrot bytecode format
whiteknight I'm thinking about a system similar to __END__ but without the problems created by file inclusions 14:39
Coke Ok. what data would go in end other than comments?
whiteknight the ability to specify data and metadata in the PIR file (in a similar way to how DATA and TEXT sections in x86 assembly work), which would then be stored in the compiled bytecode and accessible from the program 14:40
Coke ok. we can already store data (via .const subs) and metadata (via .annotate). is there /new/ data/metadata you wish to store?
whiteknight no, not necessarily. Just looking for better ways 14:41
just a thought experiment
particle leave the experimentation until you get the basics down :P
Coke ok. I vote against new syntax. if it's a new feature, that's something else.
whiteknight why the blanket disapproval of new PIR syntax? It's hardly a language that's above improvement 14:43
better syntax could provide natural pathways to increase features while at the same time improving parsing and compilation performance 14:44
particle i'd rather concentrate on making our bytecode human-readable, by supporting all pbc concepts in pasm 14:45
whiteknight it's not either/or.
particle no, it's not, except for time.
whiteknight if we say we want to focus on that, maybe 10% of our develpment team will take that task
14:45 bluescreen joined
particle and for me, it's likely neither 14:45
whiteknight always better to put out a unified vision and an array of tasks. 14:46
14:46 payload1 joined
Coke (why against) because timtoady isn't something we need at this level? 14:47
I'm not saying this is the best implementation, mind you, but it's functional. There are other things that are not functional; I'd like to prioritize those (more) 14:50
... so, yes, if there's a better syntax/format/something to replace something we already have, yes, that should be on the table. but do we really want our core committers working on that when we have HLL features that are currently impossible to implement with core parrot? 14:51
14:52 patspam joined
Coke (yes, people will work on whatever they want to anyway, which is fine and expected, but as you say, we should have a unified vision; our array of tasks should reflect our best understanding of our user's needs.) 14:53
14:54 patspam1 joined
whiteknight We don't decide what our core committers are going to work on. This isn't a business or some sort of authoritarianism 14:55
people work on what they want to work on, they vote for features with their tuits
you can say "you must not do X", but you can never say "you must do Y" 14:56
particle that's not how roadmaps work.
Coke ... did you read my sends? yes, I understand.
whiteknight particle: and our roadmaps obviously don't work the way our development team works 14:57
otherwise we might actually meet some of our deadlines eventually
particle you speak with the devil's tongue. OUT DEMONS, OUT!!!
whiteknight if a developer comes to us and says "I want to improve PIR syntax, I will do that or I will do nothing", it's not a matter of saying "we would prefer something else" 14:58
Coke whiteknight: no one is saying that.
whiteknight Coke: implicitly, all open source devs are saying exactly that
people work on what they want to work on, or they don't work at all 14:59
Coke whiteknight: so why even ask if we want this feature?
whiteknight Coke: because it's not a free-for-all either. There are plans and goals
Coke whiteknight: right.
whiteknight if the needs of the developers match the needs of our project, development gets done
Coke so I don't really know, again, what you're arguing about.
I'm not saying that a developer cannot work on that feature if they feel it is crucial. I am explaining why I do not feel that is crucial, and that I would rather prioritize other things higher. 15:01
Obviously every developer is not going to agree on all the priorities.
but where there is overlap, there is our roadmap.
whiteknight I'm saying that it's nonsensical and even wrong to say "X would be nice, but table it because Y is higher priority"
if PIR improvements are nice, greenlight them and people will do the work 15:02
you can't prioritize somebody elses tuits
Coke I feel it is crucial as me as a HLL implementor to prioritize.
Tene In general, it seems that new PIR development has been discouraged until we get a replacement for pirc.
Coke crucial /to/ me.
whiteknight Coke: right. And you can prioritize your tuits accordingly 15:03
and you can even provide incentives (begging, kudos, karma) to try and nudge others in that direction
Coke whiteknight: so, again, I don't understand what we're arguing about. 15:04
whiteknight I'm mostly arguing against what particle said earlier
and saying that if a feature is something we would like eventually, we should greenlight it
and also you can't worry about dividing developer effort, it divides itself and disappears if you don't utilize it 15:05
Coke shuts up since whiteknight isn't arguing with him. 15:06
whoops, argument coming: 15:09
bah. six line argument typed out and deleted. I don't have the energy. 15:13
Coke tries to sum up.
we /can/ divide developer effort, and have done so in the past. We should endeavor to use that power for the good of the users where it does work, and when we say "please don't bother", please hear "please prioritize that at the bottom of the collective queue." 15:14
(division example: "let's move off rt.perl.org") 15:15
Coke likes how his summary was 5 lines. Oy. 15:18
whiteknight it's certainly not a perfect world of "never" and "always" 15:22
15:22 lucian joined
whiteknight There are plenty of projects that I am certainly not ever going to work on regardless of the priority level. I know there are other combinations of projects and people where that holds true as well 15:22
and when the entire list of ongoing projects falls on a person's "I'm not ever going to do that" list, we've lost that person forever 15:23
Coke whiteknight: is that a bad thing?
people leave the project all the time.
if their goals don't mesh with the project, that seems reasonable to me. 15:24
whiteknight maybe, yes. Especially if we've artificially shortened the list of projects to try and avoid dividing effort
I would rather have a person working on a low priority task then to have that person not working with us at all
Coke whiteknight: that depends on the project. if it's merely "low priority" and not "actively harmful", sure. 15:25
I am not suggesting new pir syntax is actively harmful.
whiteknight as people become more integrated into the community, it becomes easier to manipulate them into doing things for the good of the project
where manipulate was probably the wrong word choice
Coke subdue?
hurm.
moritz one roadmap to bind them, and in the darkness to grind them 15:26
whiteknight for instance, I'm pretty well integrated and I'm willing to do certain tasks for the good of the project that I wouldn't do as more of an outsider
moritz++ 15:27
15:29 bubaflub joined 15:41 bluescreen joined 15:54 Psyche^ joined
Coke whiteknight: there were a lot of those roadmap items that were theoretically documented at the PDC (but never on the wiki) 15:55
in re TT#604; Thanks for following up on those.
whiteknight the tasks on the "roadmap" really form a comical subset of tasks we should be looking at 15:56
I really wish we could have a new general meeting to get priorities in order again
Coke (meeting) - in person meetings aren't going to cut it. 15:58
whiteknight right, a good dedicated online meeting would be good for this purpose
Coke +1 from me.
whiteknight like #ps, only different in scope and time commitment
Coke (unless of course, the meeting is in Albany, NY. =-)
whiteknight: we should probably have one of those just after each stable release. 15:59
whiteknight I like that idea
Tene We could have one right now! In this channel!
whiteknight what bothers me is that these releases all have taglines, but we don't do anything in the large sense to acheive them besides following the small set of ragtag items on the roadmap
pmichaud whiteknight: do you mean the "production ready", "stable platform for HLL developers", etc. taglines? 16:01
whiteknight pmichaud: exactly
pmichaud whiteknight: those were our best guesses of progress as of PDS 2008
whiteknight there are a lot of things we should focus on, and should have been focusing on to make 2.0 "production ready"
but the roadmap only shows "testing sprint" and something vague about PGE
pmichaud what really hurts is that we haven't revised our notion of priority since then
whiteknight pmichaud: exactly! We need to revise
pmichaud you're preaching to the choir here :-) 16:02
whiteknight our roadmap is uninformative at best right now, absolutely useless and totally misleading more likely
Coke Infinoid: ping. estimated release of svn-bisect so I can advertise?
whiteknight to think that the only thing we need to acheive production readiness is "testing sprint" is assinine
pmichaud I've long complained that there's a parrot-process problem in that there doesn't seem to be a process or mechanism to update the roadmap
(I've complained about this since march) 16:03
Coke here's my suggestion: just after each stable release to plan out the next six months, plus one in place of next week's parrotsketch.
all in favor? =-)
pmichaud -1
purl -1
Tene I like how agreeable purl is. :)
pmichaud because in this case, "just after each stable release" will mean after January 16:04
and I think we need to be updating our roadmap _now_
Coke pmichaud: ... please reread my send?
whiteknight pmichaud: no meeting we have before january will affect our trajectory for the 2.0 release
pmichaud Coke: okay, mis-applied the "plus one" comment
Coke so, long term, just after the release to set the plan, but we need one right now to figure out what we can do before january. 16:05
moritz whiteknight: but for example the deprecation items in the 2.0 release
pmichaud whiteknight: false. While it might not affect the contents of the 2.0 release, it can certainly affect our activities between now and then.
and as moritz++ says, it might change what we choose to deprecate
whiteknight pmichaud: that may be true. I don' want to be entirely pesimistic
the net end deliverable can't be changed much at this point
pmichaud right now most of what I hear about the "2.0 release" is that it's a convenient excuse to postpone hard decisions until after January. 16:06
whiteknight but if we can improve our process, 2.6 could be dramatically affected
pmichaud when in reality we need to be making those hard decisions *before* the January release. Even if it doesn't affect the code, it may affect what we're telling others about the next stable release.
whiteknight agreed 16:07
pmichaud Also, given the number of issues that (imo) keep us from being truly "production ready", I'd like to resurrect the idea that we create another "supported release" in April.
whiteknight for instance, I do want to start planning the next GC now, not after 2.0
pmichaud because I think that waiting until July for that is unrealistic.
whiteknight pmichaud: that only helps us if we can achieve the necessary improvements by April
a lame-duck april release does nothing to help us 16:08
pmichaud I think July may end up being too late for Parrot.
Tene echo EVERYTHING >> DEPRECATED.pod
whiteknight this is the problem with time-based releases, you can't say that any given release will contain any given feature set
pmichaud: in what sense?
Coke whiteknight: but if you go the other way, you can never say when it's going to be released.
whiteknight Coke: neither is perfect, just pointing out the issues 16:09
Coke so either way, you can never say. =-)
right.
whiteknight I certainly don't advocate for a change
but time-based releases are the reality, and we need to understand the pros and cons of that
pmichaud time-based releases are the reality, but the 6-month cycle is our own doing.
imo, a 6-month cycle assumes far more stability (and progress) than we've achieved in Parrot. 16:10
16:21 ilbot2 joined
moderator Parrot 1.8.0 Zygodactyly released | Priority: trac.parrot.org/parrot/wiki/ClassV...eOverrides | Latest modified TT's: icanhaz.com/parrotbugs | Parrot Languages: icanhaz.com/parrotlang
16:22 Util joined
whiteknight that is, the only things covered by the policy are things we've deemed to be stable 16:22
not cover everything until we've deprecated the trash
PerlJam whiteknight++
whiteknight pmichaud: I think people will use the standard darkPAN defense: "We don't know what our users are relying on, and we can't just pull the rug out from under them" 16:23
szbalint_ real or not, Darkpan is still a _wrong_ argument. Taking into account the needs of people who by definition won't express their views is bending over backwards so much as to fall backwards.
16:23 slavorg joined
PerlJam szbalint_++ 16:23
szbalint_ Besides, people needing a feature can a.) fix code b.) not upgrade.
whiteknight I think it's also going to be used as "and it hurts Parrot adoption if we remove things our users rely on without warning"
szbalint_++
PerlJam Does anyone have a handle on the current parrot user base? 16:24
pmichaud I guarantee that Parrot-lack-of-features-and-performance will hurt its adoption far more than a moving API :)
PerlJam (non-#parrot user base)
whiteknight it's the current Parrot devs and maybe a handful of other people
pmichaud whiteknight: okay, thanks for the answer -- that's essentially what I was looking for.
16:24 tewk joined
whiteknight pmichaud: no problem. I have plenty to say on the issue (I know you do too) 16:25
pmichaud whiteknight: yes, I have plenty to say also, but for the most part it appears to be screaming against the wind. I'm weary of it and so will likely stop.
whiteknight Anything worth having is worth fighting for 16:26
pmichaud fighting indefinitely? with no results?
whiteknight if we fight properly, there will be results
dukeleto pmichaud: i hear what you are saying
PerlJam There's always the fork option.
Coke PerlJam: aka. "the nuclear option". 16:27
dukeleto occasionally uses a spoon as well
whiteknight I don't think a fork will generate critical mass
and I think it's a huge waste to fork the project over an incomplete roadmap and lousy deprecation policy. like pmichaud says, policy can be changed
pmichaud the more common outcome is that people "vote with their feet"
dukeleto Coke: why should i juse .fp_eq instead?
whiteknight pmichaud: true 16:28
Coke dukeleto: because comparing equality on FP's is wrong?
pmichaud which is somewhat why I say that "July may be too late for Parrot"
dukeleto Coke: is() takes a 4th argument, of precision
whiteknight so maybe the first act of business is to draft a new support policy and vet it on the list
dukeleto whiteknight++
PerlJam whiteknight++ sounds like a plan. 16:29
16:29 workbench joined
Coke dukeleto: ah, that's relatively new. +1; (-1 that if it's present, it should be used instead of doing an iseq check first. =-) 16:30
16:30 PacoLinux joined, brrant joined
moritz wouldn't that be a good candidate for a named argument? 16:30
Coke thanks for pointing that out.
16:33 davidfetter joined, jsut joined
Coke email about #ps sent. 16:34
16:35 HG` joined 16:40 hachi joined
kthakore /win 12 16:45
dalek TT #1343 created by coke++: parrot's Test::More's is(Float,Float), with precision 16:48
16:50 lucian joined
dalek TT #662 closed by doughera++: [PATCH] Add more dependencies on parrot.h 16:54
dukeleto Coke: i don't quite understand the -1 part of what you said 17:02
coke++ for tt 1343, i considered writing them, but just wrote 2 extra lines instead 17:03
Coke dukeleto: you pass in a precision to alter the comparison - it's potentially ignored.
$dayjob
pmichaud $lunch 17:04
or perhaps that's &lunch
dukeleto self.'lunch'(food)
pmichaud $Pm <== &lunch 17:06
(hey, it is called the "feed" operator :-)
17:20 theory joined
dalek rrot: r42864 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add a PIR implementation of 'glob' based on 'PGE::Glob'
 17:21
cotto_w0rk good morning 17:24
whiteknight hello cotto_w0rk 17:25
cotto_w0rk ponders the difference between working and w0rking 17:28
whiteknight down that path lies danger 17:35
next thing you know, you're getting fired for w0rking when you should be working
Tene If IRC is too time-constrained, what about holding the discussion in email and/or wiki? 17:36
mj41_ /msg dukeleto Do you have permanent IP? 17:39
\\msg dukeleto Do you have permanent IP?
moritz /msg should work
if you don't have leading spaces 17:40
and a decent IRC client :-)
17:44 payload joined
whiteknight urg, I can't get TAP::Harness::Archive to build on OpenSolaris 17:45
Coke Tene: (mailing list) that's what I said!
whiteknight which means I can't submit smolder reports there
Coke whiteknight: is THA using xs? 17:46
whiteknight Coke: no idea. Build.PL gives me crap about the wrong arguments
Coke ... should you be using Makefile.PL ? 17:47
(are you building it via cpan or manually?)
whiteknight it doesn't have a Makefile.PL
I am trying to do it via cpan, yes
Coke do you have an old version of Moudle::Build?
Module::Build
purl Module::Build is at sourceforge.net/projects/module-build or We preference you, the author, yay! or Making it even easier to create packages that the users can't install! or in soviet russia, module builds you or obsoleted by Module::Install, which is easy -and- produces distribution that install
whiteknight I just installed Module::Build in this session 17:48
Coke vaguely wants :multi(Float,Float)|(*,Float)|(Float,*) 17:51
whiteknight ah, nevermind. Figured it out 17:52
"perl Build.PL Build && perl Build Install"
mj41_ please try it and set your passwd 17:59
to dukeleto :-)
18:02 xenoterracide joined
Coke whiteknight: wasn't cpan doing that for you? 18:10
whiteknight Coke: nope
tried to write it's own makefile
hilarity ensued 18:11
Coke were you doing anything other than 'cpan Module::Build' ? 18:14
er, s/Module::Build/that other thing./
whiteknight I opened cpan, and typed "install TAP::Harness::Archive" 18:15
(after I installed a few prereqs)
Coke I would definitely report that over in #toolchain.
whiteknight will do. Thanks 18:16
Infinoid Coke: pong. weekendish. still want to get "svn-bisect run sh -c 'foo bar'" working 18:17
18:18 nopaste joined
dalek rrot: r42865 | fperrad++ | trunk/runtime/parrot/library/distutils.pir:
[distutils] add a named parameter 'verbose' to some OS utilities
 18:24
whiteknight for all it's hype, the cpan utility is remarkably unuser-friendly. 18:30
and I'm having a huge number of issues involving missing dependencies not getting loaded
18:31 chromatic joined
whiteknight I don't know if that's a problem with cpan or a problem with the metadata from the various modules 18:34
bubaflub whiteknight: could it be both? 18:36
dukeleto whiteknight: also email module-authors, if #toolchain doesn't help 18:39
whiteknight success! 18:41
purl hmmm... success is finding king size papers
whiteknight smolder.plusthree.com/app/public_pr...ails/30475 18:42
18:46 nopaste joined, hachi joined, brrant joined, workbench joined, rhr_ joined, |Ryan52 joined, leto_ joined, bluescreen joined, whiteknight joined, KatrinaTheLamia joined, DrForr joined, jjore joined, cxreg joined, he_ joined, jan joined, estrabd_ joined, frodwith_ joined, Tene joined, treed joined, purl joined, Essobi joined, NotFound joined, preflex joined, sjn joined, Maddingue joined, integral joined, PerlJam joined, eiro_ joined, baest joined, ttbot joined, athomason joined, spinclad joined, silug joined 18:47 joeri joined, payload joined, PacoLinux joined, slavorg joined, cosimo_ joined, sri_ joined, mj41_ joined, mikehh joined, ruoso joined, cognominal joined, fperrad joined, redbrain joined, GeJ joined, slavorgn joined
dukeleto wilkommen! 18:47
dalek p-rx: 4633d19 | pmichaud++ | (3 files):
Allow leading & on subroutine declarations.
 18:52
p-rx: 3173f73 | pmichaud++ | src/NQP/Grammar.pm:
Add bare circumfix to colonpair.
p-rx: 530da42 | pmichaud++ | src/NQP/ (2 files):
Improve longname handling for routine and regexes, allow "infix:<...>" names.
p-rx: eab37ff | pmichaud++ | src/stage0/ (3 files):
Update bootstrap.
p-rx: 588f6a7 | pmichaud++ | src/NQP/Actions.pm:
Merge branch 'master' of git@github.com:perl6/nqp-rx
p-rx: 2d32e30 | pmichaud++ | src/stage0/ (3 files):
Re-update bootstrap with latest pull from github.
Coke Infinoid: ok. I eagerly await the ability to delete my cpan module! 18:53
Infinoid++
whee, parrot-users-nyc gets its first spam. 18:55
dukeleto joy to the world 18:56
cotto_w0rk It's a big day.
I'd better get back to work.
dukeleto why does nyc think they are so cool?
i might have to start parrot-users-the-rest-of-the-universe
18:57 theory joined
cotto_work anyone want to be purl? now's your chance 18:57
dalek rrot: r42866 | pmichaud++ | failed to fetch changeset:
[nqp]: Latest updates to nqp-rx, ability to declare &category:<xyz> subs.
 18:58
18:59 nopaste joined, hachi joined, brrant joined, workbench joined, rhr_ joined, |Ryan52 joined, leto_ joined, bluescreen joined, whiteknight joined, KatrinaTheLamia joined, silug joined, spinclad joined, athomason joined, ttbot joined, baest joined, eiro_ joined, PerlJam joined, integral joined, Maddingue joined, sjn joined, preflex joined, NotFound joined, Essobi joined, purl joined, treed joined, Tene joined, frodwith_ joined, estrabd_ joined, jan joined, he_ joined, cxreg joined, jjore joined, DrForr joined
pmichaud If I became purl, I'd have to kill myself. 19:00
whiteknight yay! no more netsplit 19:08
internet is dragging ass though' 19:09
purl: kill yourself 19:10
purl whiteknight: huh?
whiteknight purl kill yourself is <reply>Okay, I'll try dividing by zero while dereferencing a null pointer. Wish me luck!
purl ...but kill yourself is <reply>Goodbye... cruel... world.......
dalek rtcl-nqp: ae81e91 | pmichaud++ | (3 files):
Refactor %GLOBALS initialization.
 19:11
whiteknight purl no, kill yourself is <reply>Okay, I'll try dividing by zero while dereferencing a null pointer. Wish me luck!
purl okay, whiteknight.
rrot-linear-algebra: 9ebe089 | Whiteknight++ | PLATFORMS:
starting a more verbose file explaining platform compatibility
bubaflub karma purl 19:14
purl purl has karma of 8799
bubaflub huh. i was expecting a negative number.
cotto_work purl cheats 19:15
purl cheats are fun.
cotto_work purl--
purl cotto_work: sorry...
cotto_work karma purl
purl purl has karma of 8799
bubaflub oh, i see
dukeleto bubaflub: purl is a cheater! 19:22
Tene purl++ 19:29
karma purl
purl purl has karma of 8800
Tene foo bar purl--
karma purl
purl purl has karma of 8798
bubaflub bahhaahaha
Coke pmichaud++
pmichaud: that is easier to read, thanks. =-) 19:30
19:31 jhorwitz joined 19:32 dngor joined
Coke PerlJam: if you make a perl is undead t-shirt and sell it on cafepress or something and it doesn't suck, i will buy it. 19:46
TimToady phone 19:59
20:01 confound joined
Coke seen chromatic? 20:01
purl chromatic was last seen on #parrot 11 hours, 19 minutes and 29 seconds ago, saying: I'll review the patch to make sure.
20:10 nopaste joined 20:13 HG` joined
Coke is vaguely surprised no one has migrated pugs to git. 20:14
whiteknight I was under the impression that pugs was mostly dead in the water, except the P6 tests
and are the tests even still in that repo?
pmichaud it's been discussed from time to time 20:15
(moving pugs, or portions of pugs, into a separate repo and/or git)
whiteknight that's still the repo where the spectest suite is? 20:19
pmichaud yes
whiteknight okay
pmichaud I'll be glad to move it to the perl6 github account someday, though :-)
Coke I think pull out the spec and the tests into a separate repo would be boss. 20:20
"pulling"
20:20 Andy joined
PacoLinux whiteknight: can you take a look to pkgsrc.se/math/blas ? seems to be a BLAS package for solaris 20:36
whiteknight PacoLinux: were you reading my mind?
PacoLinux :)
dalek 9plus: c5871ee | bernhard++ | (2 files):
Use setup.pir instead of Configure.pir.
 20:39
PerlJam I think it would be wise to get TimToady's opinion before pulling the spec out of the pugs repo. 20:43
whiteknight PacoLinux: doesn't seem like there are any pre-built packages. I'm going to have to do the build myself
and I've heard this particular build can be a huge PITA
dalek 9plus: 342570b | bernhard++ | setup.pir:
Forgot to add setup.pir.
 20:45
whiteknight doesn't help that I need the C bindings, not the Fortran ones
PacoLinux Required to run: [lang/f2c] <--- fortran is translated to C 20:49
20:49 jsut joined 20:50 naypalm joined
dalek 9plus: 3f83e0a | bernhard++ | Makefile:
Makefile is no longer generated.
 20:50
21:08 theory joined
Coke PerlJam: done and done. (don't touch for now.) 21:14
21:15 payload joined 21:18 dngor joined, kthakore left 21:19 bacek joined 21:26 joeri left 21:32 hercynium joined 21:35 HG` joined 21:42 japhb joined
Coke is forced to upgrade parrot again! 21:49
pmichaud++
21:51 TonyC joined
mikehh All tests PASS (pre/post-config, smoke (#30485), fulltest) at r42866 - Ubuntu 9.10 amd64 (gcc with --optimize) 22:02
messages 22:03
dukeleto mikehh++ 22:16
22:24 HG` joined, mmcleric joined
GeJ Good morning everyone 22:29
22:30 mmcleric joined 22:36 AndyA joined
dukeleto GeJ: glorious localtime() to you as well 22:46
GeJ: what are you working on lately? 22:47
22:58 bacek joined 23:23 particle joined
GeJ dukeleto: sadly nothing parrot-related. Currently $job is taking all brain cycles. And I don't expect any changes before January. 23:26
dukeleto: Although, when I really need a break, I'm trying to submit patches here and there. 23:28
win 2 23:34
damn
dukeleto meh 23:50

Powered by Cro and the Raku® Programming Language.

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

Thank you!