Parrot 1.3.0 "Andean Swift" released | parrot.org
Set by moderator on 23 June 2009.
particle that's the most general solution, i think. allow the user to set precisely how each exception will be handled 00:00
.'set_errors_as_exception'( $I1, $P2 ) # set these error types to exceptions, handled by this pmc 00:01
perhaps, if no pmc is passed, the default is to leave them unhandled, making them fatal unless otherwise handled 00:02
darbelo Wait, the user is passing me the exception to throw or the handler that will catch it? 00:03
particle the exception type, and optionally the handler 00:04
...or exception types
s1n Whiteknight: i need to speak with you later, but i have to leave now, i'll be back in about 2 hours
darbelo Oh, I think I get it now. I'll go read the docs. 00:06
Whiteknight s1n: okay, awesome 00:07
Infinoid chromatic: Use helgrind much? 00:10
chromatic Only once, and never figured out what it was telling me. 00:14
particle cycling & 00:17
cotto bacek, ping 01:10
01:11 Zak joined
dalek tracwiki: v5 | Austin_Hastings++ | PGEBestPractices 01:13
tracwiki: Added some more tid-bits
tracwiki: trac.parrot.org/parrot/wiki/PGEBes...ction=diff
tracwiki: v25 | cotto++ | ParrotQuotes 01:16
tracwiki: Whiteknight++ does things wrong, also fix formatting to indicate an afk quote
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
Whiteknight ?
cotto ! 01:18
davidfetter ¡ 01:19
Infinoid ¿ 01:20
01:28 japhb joined
Whiteknight yay! 01:28
cotto ?
dalek tracwiki: v6 | Austin_Hastings++ | PGEBestPractices 01:29
tracwiki: Fixed typos, added leader.
tracwiki: trac.parrot.org/parrot/wiki/PGEBes...ction=diff 01:30
cotto Austin_Hastings++ #inadvertent pun
or advertent 01:31
bacek cotto: pong 01:35
cotto bacek, According to your proposal, we'll be implementing core PMCs in nqp or PIR.
Have you identified any barriers that could keep us from doing this or have you tried to implement something important (say Integer or RPA) in PIR?
bacek cotto: (NQP or PIR) it doesn't matter. My proposal to drop step with generating C from "new language for PMC" 01:36
however we'll probably have to generate C for "ops" 01:37
(Not necessary of cause) 01:38
If we'll split "ops" into "ops" and "l1ops" where "ops" are in pseudo-C and "l1ops" in "L1" 01:39
cotto So you're saying PMCs will go PIR/nqp/HLL -> PIR -> L1/C, but ops will need to be C until we get L1 working?
bacek cotto: something like this.
purl something like this is tempting: www.zones.com/cgi-bin/zones/site/pr...p;zone=zbs
cotto or rather, once we get ops working in L1, we'll have all the tools to write PMCs in nqp/pir and won't need to bother with a separate pmc compiler 01:40
forget something like this
purl cotto: I forgot something like this
bacek I didn't quite understand difference between those two approaches. 01:41
cotto just restating
bacek Ah. Than yes :)
cotto I still think we'll need to do some more work to be able to make PMCs work from L1, but I think your approach makes sense. 01:42
I don't want to clobber the pmc_pct branch, but it looks like it's worthwhile to start working on ops instead. 01:43
bacek yes, we'll need more work for implementing some L1 ops before we can rewrite PMC into NQP/PIR.
at least for raw memory access.
cotto Plus, if we define PMCs at runtime it'll make life easier for HLLs that want to have their own PMCs. 01:44
chromatic There's no reason to clobber that branch.
We should do it to get rid of the Perl 5 parser anyway.
cotto I wonder if there'd be any problems using the GC for all memory allocated from L1. 01:45
bacek We can put it "on hold"
chromatic I wouldn't think so.
Why not bring it to feature parity with pmc2c?
bacek imaging shiny world with all memory allocated from GC
cotto bacek, including memory used by the gc? ;) 01:46
chromatic I built a bootstrapping GC once.
Not as hard as you think.
bacek chromatic: too much effort...
cotto: of cause!
cotto bacek, I think the expression you're looking for is "of course"
bacek reading ParrotQuote about 4th language :) 01:47
chromatic: "too much effort" was about pmcc/pmc2c parity. 01:48
chromatic I don't see why, but I haven't been working on it.
cotto I agree with that. pmc2c isn't great, but it's not so bad that making pmcc work until we can do PMCs in L1 is worthwhile. 01:49
bacek chromatic: there is too many corner cases in pmc2c...
chromatic That's why it'd be nice to fix them.
cotto at which point any specific PMC compiler would be obsolete
chromatic Remember though that pmc2c means that anyone who wants to build dynpmcs needs Perl 5 and all of those libraries installed too. 01:51
cotto only until L1 PMCs work 01:52
chromatic That'll be a while.
cotto yes, but that's the current state anyway 01:53
chromatic How far is pmc_pct from doing the right thing?
With some tweaks to existing PMC syntax anyhow?
cotto I'd conservatively estimate that it's half way there. 01:54
More than half the coding's been done, but debugging's always tricky.
chromatic Would another two weeks get it close to merging?
cotto whose two weeks? 01:55
also, how close?
chromatic Stable enough to merge, without using it by default.
cotto hmmm. 01:56
it's not out of the realm of probability 01:57
I'm just not seeing the benefit of putting further effort into it. What are your thoughts? 01:58
chromatic It's not too far from landing, per a decent estimate.
It's a migration path away from pmc2c even in the short term.
It's modifiable to do what we need to do for L1 PMCs in the future. 01:59
I don't see much risk in continuing to work on it.
cotto My impression was that in the future the pir compiler would be sufficient for building PMCs, obsoleting both pmc2c and pmcc. 02:00
and that since they'll both eventually be obsolete, we might as well just use what we have now 02:01
chromatic I don't assume the PIR compiler will get that sufficient without some work which includes this.
cotto You may be right, however an updated ops compiler will definitely be needed, whereas pmcc may be needed. 02:03
chromatic We *can* write PMCs in straight PIR, but I'm not sure that's the *best* way to write them. 02:04
cotto When I say "PIR", I mean anything that gets compiled to PIR. 02:05
chromatic Fair enough.
02:06 amuck_ joined
cotto btw, with all this talk about making PMCs more dynamic, how feasible do you think it'd be to avoid doing PMC initialization (as in class_init) until the first time pmc_new gets called? 02:08
for a specific PMC type
chromatic I've thought about that. You have to init its parents too, but it's not infeasable. 02:09
That might speed up startup quite a bit.
cotto just what I was thinking
chromatic Especially delaying initialization of PMCs with lots of multis.
cotto one problem is code that depends on enum_class_Foo
chromatic We probably have to define those constants and do some init anyway, but not the full init. 02:10
cotto I guess there's not a very efficient way to do that without the constants 02:11
chromatic Probably not. 02:12
cotto I wonder how that'd fit in with L1 PMCs. 02:15
02:16 snarkyboojum joined
chromatic That's an open question. 02:16
Hopefully we can rearrange our initialization at that point. 02:17
cotto It might be orthogonal. Either way, it'd help.
chromatic Our highest priority right now is installation, and then probably the profiler. 02:18
cotto I can buy that. There's a ton of stuff that could use work, but we do have priorities. 02:19
Starting on an ops compiler would help me learn ops for profiler work. Maybe that'd be a good thing to start on. 02:23
chromatic Seems reasonable. I can work on the interface for pluggable runcores.
cotto sounds like enough of a plan 02:24
s1n i'm getting warnings about trap, is it intended to be experimental and thus not in ops.num? 02:27
dalek rrot: r39831 | petdance++ | trunk/compilers/imcc/pbc.c:
Rewrote IMCC_int_from_reg to not be all cut & paste
 02:30
02:32 Andy joined 02:42 janus joined
dalek rrot: r39832 | petdance++ | trunk/compilers/imcc/cfg.c:
use NULL for pointers, not 0
 02:43
rrot: r39833 | petdance++ | trunk/include/parrot/compiler.h:
annotations on the differences between pure and const functions
 02:59
03:04 magnachef joined
whoppix purl, tell Whiteknight about btw, my offer to make flowcharts and illustrations for the docs is still standing, if someone finds some time to throw a list of things that need illustration the most. 03:06
purl OK, whoppix.
03:09 amuck joined
nopaste "tene" at 24.10.252.130 pasted "broken implementation of 'is cached' for pmichaud++ or jnthn++" (52 lines) at nopaste.snit.ch/17060 03:13
03:21 skids joined
s1n is the codetest target for testing coding standards (only)? 03:24
cotto that's codingstd_test 03:28
I think codetest is a little more inclusive
03:34 tetragon joined
s1n cotto: i'm looking for cage cleaning things, is codetest the right place? 03:36
Andy or running splint! 03:37
cotto s1n, what Andy said. We'll occasionally get codingstd failures, but I think you'll have a lot more to do if you play with splint.
s/get/introduce/ 03:38
Andy the bummer is that splint has SO MANY WARNINGS
and I'm trying to figure out what's what.
s1n i didn't think splint was maintained anymore 03:39
does it work? 03:40
purl i think does it work is it used? =-)
Andy yes 03:42
"Maintained" is relative
build it from source.
dalek rrot: r39834 | petdance++ | trunk/compilers/imcc/parser_util.c:
Splint annotations on string literals
rrot: r39835 | petdance++ | trunk (9 files):
no longer tries to headerize on imcc.y directly. Add lots of splint macros to imcc.y
ttbot petdance: Parrot trunk/ r39835 i386-linux-thread-multi make error tt.ro.vutbr.cz/file/cmdout/43484.txt 03:44
Andy huh
cotto ttbot++ 03:45
s1n Andy: do you have docs on how to use splint against parrot to do some cage cleaning?
Andy no
jdv79 cotto: get anywhere with your l1 experiments? 03:46
s1n Andy: so where would i start, what would i need to do?
cotto not terribly far, and I think I've been taking the wrong approach.
jdv79 the one you outlined in the wiki? 03:47
cotto I think I should be trying as much as possible to use existing nqp syntax to implement PMCs rather than looking for an extension every time there's something tricky.
yes
wait, you mean L1Recap?
Andy I wish I knew the diff between ttbot and me 03:48
jdv79 RewritingPMCsInNQP
cotto ok. That's what I was thinking of. 03:49
jdv79 i think i get the general idea. its the "how do we get there from here" that i guess everyone is wondering about. 03:50
cotto yes, at the nqp level
jdv79 is there something wrong with doing it with PIR? 03:51
cotto no, it's just that nqp is higher-level and easier to work with
and can be compiled directly to PIR with existing tools 03:52
jdv79 nqp is tied to p6 though and pir isnt... 03:53
cotto explain "tied"
it's based on perl6, but it doesn't need Rakudo or anything
Once "Close" arrives (if it hasn't already), we could just as easily use it. 03:54
but that might be confusing because it looks like C but is very different under the hood. 03:55
jdv79 sounds like PIR is a good fit to me. basicaly just get rid of the C code.
cotto Straight PIR makes more sense for ops than for PMCs since the ops will generally be smaller and more self-contained. 03:56
Andy AHA 03:57
For some reason, Makefile can't find my yacc
jdv79 ok. 03:58
cotto time for some shaving 03:59
Andy well, good, I've goofed up the build. 04:00
are we using actual yacc, or bison? 04:01
04:04 snarkyboojum joined
chromatic Bison. 04:05
jdv79 asswipe 04:10
wrong window - sorry 04:11
Andy chromatic: I was fooled into thinking that I was actually rebuilding files. 04:12
chromatic But you should see the other guy! 04:13
04:13 particle1 joined
Andy hey, chromatic, I gotta say, thumbs up on the regular posting to the modern perl blog 04:13
dalek rrot: r39836 | petdance++ | trunk (9 files):
reverting -r39835
cotto laziness? 04:14
purl i heard laziness was a virtue, after all :)
cotto laziness is also bill.wards.net/blosxom/humor/story/feynman.html
purl okay, cotto.
chromatic Thanks, Andy. 04:16
Andy Time & repetition.
chromatic Fire and motion.
Andy what's that 04:20
purl somebody said that was about the level that you were asking for
04:20 tetragon joined
chromatic That's how you take control of a battlefield. 04:21
Pin down your opponent and don't get pinned down. 04:22
"Entropy". That's my answer to your next question. 04:23
Andy Time & repetition is how habits and/or evolution and/or public perception happens. 04:24
04:26 eternaleye joined
dalek rrot: r39837 | petdance++ | trunk/compilers/imcc (8 files):
adding more splint notations, this time with bison properly running
 04:30
04:35 snarkyboojum joined
dalek rrot: r39838 | petdance++ | trunk/compilers/imcc (2 files):
consting. Removed unused interp from add_pcc_named_return()
 04:43
ose: r22 | austin_h...@yahoo.com++ | trunk/ (7 files):
Improved self, builtins, got more of Node.c= working
 04:54
05:00 amuck joined 05:03 amuck_ joined
dalek rrot: r39839 | cotto++ | branches/pmc_pct/compilers/pmcc/src (3 files):
[pmcc] Simplify function body parsing to slurp everything into a PAST::Block.

NOTE: This may be the last commit to this branch, as a separate pmc compiler may not be necessary. See irclog.perlgeek.de/parrot/2009-06-30#i_1275754		 05:14
cotto can someone think of a name for the new ops compiler that looks less like "oops" than "opsc"?
chromatic lops? 05:15
cotto scalpel - useful for operations 05:20
05:22 iblechbot joined 05:36 leto_ joined
bacek cotto: clops 05:38
cotto compiler for L1 ops?
not bad 05:39
bacek Level One Language
Ops Mega G... 05:40
Ops Meta G...
I can't find proper word for G... :-/ 05:41
cotto the thesaurus is your friend
cotto puts off naming the thing and digs into ops2c 05:42
05:45 tetragon joined
cotto I was hoping this would be easier than it looks like it's going to be. 05:46
bacek What doesn't kill you... 05:47
cotto leaves me badly injured and possibly scarred for life? 05:48
bacek and without hope to bright shiny future. 05:49
05:58 uniejo joined
cotto I've had lots of paper cuts that didn't kill me, but I don't feel any stronger. 06:08
06:13 jdv79 joined 06:16 tetragon joined
cotto The callgrind spec is hard to read too. I'm getting the sinking feeling that I might have to do some actual work. 06:31
06:31 brbrooks joined 06:39 tetragon joined 06:52 leto_ joined
cotto chromatic, ping 06:56
chromatic pong 06:58
07:11 Zak joined
dalek tracwiki: v2 | cotto++ | ProposedParrotsketchProtocol 07:22
tracwiki: Revert preposting recommendation to the original 30m. We can change it later if needed.
tracwiki: trac.parrot.org/parrot/wiki/Propos...ction=diff
08:00 burmas joined 08:03 tetragon joined 08:10 jdv79 joined 08:34 snarkyboojum joined 08:37 viklund joined 08:49 cognominal joined
nopaste "mikehh" at 217.42.128.29 pasted "codetest failures from make fulltest at r39839" (45 lines) at nopaste.snit.ch/17063 09:26
mikehh i got a patch - testing now
nopaste "mikehh" at 217.42.128.29 pasted "PATCH for codetest failures at r38939" (22 lines) at nopaste.snit.ch/17064 09:35
mikehh this Patch PASSes make test codetest and fulltest
got to go - bbl 09:36
09:44 bacek_ joined 10:31 kid51 joined 10:34 burmas joined 10:35 cognominal joined
dalek rrot: r39840 | bacek++ | branches/tt761_keys_revamp/src/dynpmc/rational.pmc:
[pmc] Fix handling of C<dest> in Rational dynpmc to be in-line with all
 10:58
rrot: r39841 | jkeenan++ | trunk/compilers/imcc/pbc.c:
Applying patch submitted by mikehh to remedy two coding standards failures.
 11:02
kudo: 78b5ac5 | jnthn++ | (2 files):
Implement [X] for RT#67064.
 11:11
kudo: 997a1bd | jnthn++ | src/parser/ (2 files):
Get our parsing of type declarators a little more in line with STD.pm and hanlde the case where there is no C<where> clause. Resolves RT#66854.
11:24 masak joined
bacek_ bah... 12:06
msg Whiteknight Does GC check CPU registers? 12:07
purl Message for whiteknight stored.
12:08 skids joined 12:09 snarkyboojum joined
bacek_ kid51: (TT#798) it's libsdl-dev or libsdl1.2-dev 12:17
12:18 JC1 joined 12:21 rhr joined
dalek kudo: fa963c8 | jnthn++ | src/parser/ (2 files):
Support writing of literals inside a signature.
 12:22
kudo: 72ececf | jnthn++ | t/spectest.data:
Add S06-multi/value-based.t to spectest.data.
kudo: 1317e53 | jnthn++ | src/parser/actions.pm:
If BUILD is declared as a method rather than a submethod, emit a warning. Should handle RT#66120.
 12:27
12:51 ruoso joined 13:01 Whiteknight joined
dalek TT #800 created by pmichaud++: Parrot assumes command line arguments are ASCII 13:36
kudo: f484da5 | jnthn++ | src/builtins/globals.pir:
Implement first cut of $*CWD. Patch courtesy of Lyle <webmaster@cosmicperl.com> along with a tweak from me.
 13:40
kudo: 7773f90 | jnthn++ | src/builtins/io.pir:
Implement chdir. Roughly based off a patch from Lyle++ <webmaster@cosmicperl.com>, but with corrections to error handling and the way me update $*CWD to work with relative directory changes.
kudo: 466baf6 | jnthn++ | t/spectest.data:
Run chdir and $*CWD spectests.
13:40 MoC joined
pmichaud missing a pop_eh in there. 13:44
Also, I would've somewhat expected chdir() in setting instead of PIR
jonathan eh - we tailcall straight away afterwards, but yeah 13:45
Yeah, could do it that way too...though we need to instantiate the OS PMC. 13:46
pmichaud I don't mind inline PIR in that case.
jonathan And it's not a whole load of coe.
But mostly, the patch I started in was in PIR.
13:50 maettu joined 14:05 Andy joined
jonathan Man is the Parrot GC heisenbug a pain... 14:12
moritz Whiteknight++ # wknight8111.blogspot.com/2009/06/l1...w-faq.html 14:14
Whiteknight GC heisenbug?
moritz there's just one minor point: the usage of "algorithmic complexity" is highly misleading in that context
it usually means the O(n^2) thing
jonathan Whiteknight: Aye, there's some GC bug in Parrot that is randomly tripping up Rakudo.
Whiteknight bacek: ping
moritz but it just buys us constant factors, although we hope they'll be large
jonathan (Randomly as in, it sometimes causes segfaults, and sometimes wrong answers, and when there's a small change the fail moves.) 14:15
14:16 Hunger joined
pmichaud Whiteknight: the gc bug started showing up again after the memory leak fixes 14:18
which means that somewhere a "leak" was "fixed" that shouldn't have been.
Whiteknight urg. and I assume from the name "heisenbug" that there's no way to reliably reproduce it? 14:19
szbalint there is, you just have to run parrot long enough =) 14:20
jonathan Whiteknight: There may be a way, but no known way of yet.
Whiteknight Is there a ticket open for this? 14:24
Whiteknight wants to get up to speed on the details without having to ask a million stupid questions 14:25
pmichaud there's not a ticket, because it's not reliably reproducible. 14:28
as in, it only exists for certain source code programs and certain revisions of rakudo/parrot
Whiteknight ok 14:29
do we know then that it's even GC-related? most of the fixed memory leaks in recent days haven't involved the GC at all 14:30
moritz all non-determinism is attributed to the GC, by defintion :-) 14:31
pmichaud Whiteknight: sometimes "GC" gets used generically for "problem disappears when parrot's -G flag is used"
and it's not "recent days" -- it's more like "within the past six weeks"
14:33 maettu left
dalek kudo: 2827e45 | jnthn++ | src/pmc/perl6multisub.pmc:
Get Perl6MultiSub to stringify sensibly.
 14:34
kudo: 1e742a7 | jnthn++ | src/builtins/io.pir:
Missing pop_eh spotted by pmichaud++.
kudo: 91bb463 | jnthn++ | src/classes/Multi.pir:
Implement prefix:<~> for MultiSub. This makes sure we stringify Parrot multisubs correctly (it may well we that we can drop this patch if Parrot changes how they stringify).
kudo: 2ae07bd | jnthn++ | src/setting/IO.pm:
Before handling stuff off to Parrot IO, we should use prefix:~ to stringify it. Causes no spectest issues.
Whiteknight okay, awesome 14:37
14:38 davidfetter joined
dalek rrot: r39842 | petdance++ | trunk/compilers/imcc/main.c:
use NULL when you mean NULL
 14:45
rrot: r39843 | petdance++ | trunk/compilers/imcc/symreg.c:
refactored int_overflows
14:49 Theory joined 14:59 bacek_ joined 15:03 mikehh joined
Whiteknight purl msg bacek yes, the GC does check the CPU registers. Check the file src/gc/system.c. It's messy and not well documented, but this is where the magic happens. Let me know if you have any questions about it. 15:04
purl Message for bacek stored.
15:12 kgilmer left
Coke catches up. 15:26
15:30 clinton joined 15:40 chromatic joined
Coke chromatic: hey, big guy. 15:40
purl big guy is alot easier to upend on skates
15:41 rdice joined
chromatic What's up? 15:41
purl Your face, chromatic. That's what.
chromatic Also my hair, purl.
purl chromatic: excuse me?
dalek kudo: bcdaaff | pmichaud++ | docs/release_guide.pod:
Update release_guide.pod with more names.
15:44 Theory joined
dalek kudo: 7032827 | pmichaud++ | docs/release_guide.pod:
Release #18 is no longer "planned" -- it "happened". masak++
 15:47
szbalint haha 15:48
Tene ... looks like cloneflags.pasm isn't getting installed. 15:56
Is this right?
16:04 darbelo joined
dalek kudo: a4978b9 | pmichaud++ | src/ (2 files):
Add infix:<minmax> operator -- resolves RT #66640.
 16:06
kudo: c4e546e | jnthn++ | src/parser/ (2 files):
Change the way we detect state variable initialization to be more general. Resolves both RT#67040 and RT#67058.
purl dalek: that doesn't look right
kudo: 95a2c4f | pmichaud++ | src/builtins/any-str.pir:
Improve error message for "substring not found" (RT #66624).
kudo: 86271a6 | jnthn++ | :
Merge branch 'master' of git@github.com:rakudo/rakudo
cotto Heh. I just realized that the 2+ hour YAPC Parrot BOF meeting was described as "short". 16:07
chromatic It was long for a retrospective, but we'd never done a retrospective before (and we don't do them regularly), so it was about as long as I expected.
Coke I misread that as 24 hour. 16:08
16:09 flh joined
moritz I've never seen a really short BOF :-) 16:09
cotto I'm not complaining at all. It was a productive meeting, just not short. 16:18
dalek tracwiki: v26 | coke++ | ParrotQuotes 16:21
tracwiki: I find that dozens work best in the moment.
tracwiki: trac.parrot.org/parrot/wiki/Parrot...ction=diff
16:31 smash joined
smash hello everyone 16:31
everone hello smash
cotto hi smash 16:36
16:40 Psyche^ joined
dalek rrot: r39844 | pmichaud++ | trunk/src/string/charset/unicode.c:
[strings]: Fix bug in upcase handling on unicode strings.
 16:45
jonathan pre-pastes his report. 16:50
parrotsketch? 16:53
purl i think parrotsketch is a status meeting for parrot core committers held every Tuesday at 18:30 UTC in #parrotsketch
jonathan clock?
purl jonathan: LAX: Tue 9:53am PDT / CHI: Tue 11:53am CDT / NYC: Tue 12:53pm EDT / LON: Tue 5:53pm BST / BER: Tue 6:53pm CEST / IND: Tue 10:23pm IST / TOK: Wed 1:53am JST / SYD: Wed 2:53am EST /
jonathan Wait, none of them is UTC!
davidfetter LON is BST, which is usually pretty close to UTC ;)
jonathan UTC doesn't do daylight savings, though? 16:54
cotto time?
purl i guess time is 16:49:35 2009 and (did you mean "clock"?) or flowing like a river or the fire in which we burn
jonathan OK, so is #ps in 35 minutes of 95 minutes?
That is, do I eat now or later? ;-)
cotto 95
jonathan Food now! :-D
cotto nom 16:55
davidfetter SELECT now() AT TIME ZONE 'UTC';
timezone
purl timezone is, like, at www.timeanddate.com/worldclock/
davidfetter ----------------------------
2009-06-30 16:56:11.301204
antiphase Has no-one heard of NTP? 16:56
cotto or date -utc
s/-/--/
moritz antiphase: even if you have, it might be unwise to mix your database's time with your system time ;-) 16:57
17:09 abesapien joined
whoppix evening #parrot. 17:11
moritz hei whoppix 17:12
whoppix moritz :) hows rakudo coming along? 17:13
Whiteknight evening whoppix
moritz whoppix: nicely
whoppix Whiteknight, hey. You got my message?
moritz, cool
17:23 allison joined
Whiteknight whoppix: no, no messages 17:24
Coke: I've made a lot of progress on that context_pmc branch, but I still only give it about a 50% chance of success as is 17:25
we may need to go back in as a second step and clean things up first
whoppix Whiteknight, oh. Well, I was just saying, that my offer to illustrate the docs still stand, if someone finds some time to lump together a list of topics that need illustrating the most.
Whiteknight, then I'll read up on the topics myself and make illustrations, which someone more familliar with parrot can proof-read. 17:26
Whiteknight whoppix: oh excellent! I'll make sure we get a list to you!
whoppix Whiteknight, ok, cool.
Coke Whiteknight: yes, well, I was hoping we'd clean it up first. =-) 17:27
Whiteknight damn the torpedos, full speed ahead! 17:28
Coke If you want to restart the branch, that's fine.
Whiteknight plus, I'm getting a much better understanding of where all Contexts are used
Coke hokay.
might be good if you slapped a page together with what you think is coming up next. 17:29
smash Coke: sorry, did i miss a relaease ? i have fallen off the face of the earth a couple of times this year
Coke smash: you mean a release you were scheduled to do? I think so, but we had it covered. 17:32
for penance, you can close a few tickets. =-)
smash Coke: i'm terrible sorry about that..
fair enough, gimme some links :-P
Whiteknight moritz: you got clang+llvm to build Parrot? Do tell! Could you write up a recipe on the wiki? 17:34
moritz Whiteknight: there was no black magic involved, and I wrote about it on the list ;-) 17:36
Whiteknight: but if you suggest a nice title I can certainly add a few lines
Coke smash: my preference is anything on this report marked tcl: 17:37
trac.parrot.org/parrot/report/16 17:38
dalek cnum-dynpmcs: r94 | darbelo++ | trunk/src/pmc/decnumcontext.pmc:
Changed all of DecNumContext's numeric getters/setters to return/accpet INTVAL
 17:39
NotFound "reports by 1800 UTC": "by" means before of after?
moritz before
NotFound Ok
Whiteknight moritz: BuildWithClang seems like a good title 17:41
or BuildWithClangAndLLVM
17:44 brbrooks joined
cotto Clang implies LLVM 17:46
moritz aye 17:48
cotto Whiteknight, if all PMC-related memory allocations went through the GC, what other changes would we need to make? 17:52
Whiteknight cotto: what do you mean?
chromatic malloc/free use GC pools.
We could use sized pools (more overhead in managing them, possibly less fragmentation) or just extend the heap and deal with any fragmentation later. 17:53
17:55 jhorwitz joined
Whiteknight chromatic: we do have sized pools now that are miserably underutilized 17:55
moritz Util: if you need some help on your PPI-based 5->6 translator, feel free to ping me 17:57
(but not this week, I fear)
Util moritz: thanks!
cotto ppi? 17:58
purl i think ppi is a perl syntax parser that is good enough to actually use, and is quite capable of handling most non-DamianWare :) or useful for automating perl golfing. or at www.perl.com/pub/a/2005/06/09/ppi.html or "100 percent round-trip safe, and it's been stress tested against the 38,000 (non-Acme) modules in CPAN, handling all but 28 of the most broken and bizarre" or impossible or Penis Pushes Inside
dalek tracwiki: v1 | moritz++ | BuildingWithClang
tracwiki: trac.parrot.org/parrot/wiki/Buildi...ction=diff
moritz ok, I've added that wiki page. Should I link to it somewhere? 18:00
18:01 cogno joined
dalek tracwiki: v3 | Util++ | ProposedParrotsketchProtocol 18:04
tracwiki: trac.parrot.org/parrot/wiki/Propos...ction=diff
18:04 amuck_ joined
Util purl, PPI is also search.cpan.org/dist/PPI/ 18:05
purl that is too long, Util
pmichaud Whiteknight: rather than wait for #ps, I'll ask my current question here: Why was TT #389 assigned to me? 18:08
Coke ppi? 18:09
purl well, ppi is a perl syntax parser or www.perl.com/pub/a/2005/06/09/ppi.html or search.cpan.org/dist/PPI/
Util Coke: much better! 18:10
Whiteknight pmichaud: I dont remember, let me look it up
you know what? I have no idea. It might have been a goof 18:11
allison: when does the book show up on amazon? :) 18:15
pmichaud #ps in 15
Whiteknight or, for that matter, when does it appear someplace that I can buy a copy?
allison Whiteknight: the printers have to finish processing it
18:16 burmas joined
Whiteknight okay, and how long does that take? My last experience with a publisher was a print-on-demand thing and I had a book in my hands in 4 days 18:16
darbelo++ 18:18
Coke allison: someone should ping monty python and ask for an endorsement. =-)
allison Whiteknight: that was my experience last time I submitted a print-on-demand title too
Coke: lovely idea :)
Whiteknight "Wait a minute, this isn't funny at all!" - Monty Python 18:19
moritz darbelo++ # using adverbs in his #ps report ;-)
dalek: a short line on how much you are on schedule would be nice
erm, meant darbelo
Coke allison: which book: draft/ or pir/ ? 18:20
18:21 Whiteknight joined
allison Coke: pir/ 18:21
Coke allison: ""The C<die> opcode throws a 18:22
fatal (that is, uncatchable) exception""
ORLY?
purl YA RLY.
Coke what's the difference between draft/ and pir/ ? is pir just a finalized version? 18:23
18:24 amuck_ joined, cogno joined
allison Coke: draft/ is all the chapters of the original book, pir/ is just the PIR chapter from the original book, broken out into separate chapters 18:24
Coke: I'm thinking the next book should be a cleaned up version of the Squaak tutorial 18:25
Coke ok. is that original chapter deleted from draft/ ?
cotto #ps in 5
dalek kudo: aa1a18d | pmichaud++ | docs/spectest-progress.csv:
spectest-progress.csv update: 409 files, 11510 passing, 85 failing

   S02-builtin_data_types/hash_ref.rakudo 23,24,25,26,28,29,30 - The object is-a 'Hasi'
   S02-builtin_data_types/num.rakudo 32,34,36,38 - The object is-a 'Nun'
   S02-builtin_data_types/range.rakudo 11,15 - got the right array
   S02-literals/quoting-unicode.t 68,69,70 - q-style string with ...
   S02-names_and_variables/fmt.rakudo 5 - fmt() works with @ array
   S02-whitespace_and_comments/comments.rakudo 7,8,9 - embedded comment ...
   S03-operators/cross-metaop.rakudo 4 - smooth cross operator works
   S03-operators/increment.rakudo 3 - magical ++ should not be numified
   S03-operators/increment.rakudo 4 - it isa Str
   S03-operators/range.rakudo 5,6,8,10,12,29,33,48
   S04-statement-modifiers/until.rakudo 4 - post until
   S04-statement-modifiers/while.rakudo 4,5 - post while
   S04-statements/do.rakudo 7,8 - prefixing 'if' statement with 'do' ...
   S05-match/capturing-contexts.rakudo 1,2 - Match object ...
   S05-substitution/match.t aborted 5 test(s)
   S05-transliteration/trans.rakudo 8,9,10,14 -
   S12-attributes/recursive.rakudo 2 - Sanity check, $a is of type A
   S12-class/basic.rakudo 5 - .isa("Foo")
   S12-enums/basic.rakudo 27 - short name of the enum without parenthesis is an enum
   S32-container/zip.rakudo 11,12 - can mix arrays and ranges for infix:<Z>
   S32-io/IO-Socket-INET.t 2 - echo server and client
   S32-num/int.rakudo 40,42,44,46,48,50,52,54,56,58,60,62 - The object is-a 'Inu'
   S32-num/rand.rakudo aborted 5 test(s)
   S32-scalar/undef.rakudo 37 - The object is-a 'Hasi'
   S32-str/lc.rakudo 8 - lowercasing char-range
   S32-str/words.rakudo aborted 8 test(s)
   integration/99problems-21-to-30.rakudo aborted 5 test(s)
Coke AIGH.
cotto epic commit message
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo daily test failures, 2009-06-30" (68 lines) at nopaste.snit.ch/17066 18:27
moritz notice "The object is-a 'Inu'" and "The object is-a 'Hasi'"
pmichaud moritz: yes, that's the "strange calls to .succ" that I mentioned.
'Inu' = 'Int'++
dalek rrot: r39845 | allison++ | trunk/docs/book/pir (9 files):
[book] Final cross-reference and page-break fixes.
pmichaud 'Hasi' = 'Hash'++
etc.
rrot: r39846 | coke++ | trunk/docs/book/pir/ch09_exceptions.pod:
fix typo
allison Coke: not sure, checking... 18:28
pmichaud #ps in 0 18:30
18:31 cogno joined 18:33 jan joined
jonathan Hasigotagcbug? 18:36
chromatic Hope not.
jonathan Unfortunatley, Parrot has. 18:37
:-(
pmichaud the errors in the nopaste seem to occur primarily with the fakecutable. Running with perl6.pbc doesn't produce the same errors (still checking this)
moritz pmichaud: which parrot version did you use? with the 1.3.0 release it looks much cleaner here 18:38
NotFound Can someone delete RT #67078? 18:39
cotto NotFound, will do
pmichaud moritz: the 1.3.0 release.
18:50 athomason joined 18:53 einstein joined, amuck_ joined
Coke at $DAYJOB 18:57
dalek ose: r23 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
Created wiki page through web user interface.
 19:00
ose: r24 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
Edited wiki page through web user interface.
ose: r25 | austin_h...@yahoo.com++ | wiki/WishList.wiki:
Deleting wiki page WishList.
19:04 jevin joined
Util pmichaud: I would be very interested in a repeatable test case that fail with fakecutable but succeeds with perl6.pbc. 19:05
chromatic The only real difference between the two is that the fakecutable always enables the --leak-check flag.
Coke pmichaud++ 19:06
Util chromatic: that *should* be the only difference; if another diff is lurking, I will hunt it.
cotto pmichaue?
Coke 1072 / 60 19:09
purl 17.8666666666667
pmichaud util: Let me see if I can get the instructions together for a repeatable perl6 failure. 19:11
jonathan chromatic: I've seen bugs appear and disappear with very small, unrelated changes. I think just a slightly different memory allocation profile - which the fakeexecutable is *occasionally* enough to give - can do it. 19:13
chromatic: The *vast* majority perform exactly the same under the fakeexecutable and without it though and it's -G that hides the problem. 19:14
chromatic True, the memory layout will be slightly different.
jonathan So I'm about certain it's not the fakeexecutable that holds the problem. It just sometimes might make enough of a different in memory layout to make the bug trigger differently. 19:15
*difference
19:17 Tene joined 19:18 jdv79 joined, Theory joined
dalek tracwiki: v76 | whiteknight++ | WikiStart 19:21
tracwiki: creating a section here on the main page to list our current development priorities
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
tracwiki: v77 | whiteknight++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
tracwiki: v78 | whiteknight++ | WikiStart
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
flh How would someone describe what the Capture PMC is? Is it just a clever combination of a list and a hash? Why is it called "Capture"? 19:23
pmichaud jonathan: the nopaste I just gave actually demonstrates differences between 'perl6' fakecutable and running the .pbc
Whiteknight flh: that's actually a very good question. I have no idea what that PMC is for
flh: I don't think it gets used much, at least not any more 19:24
pmichaud Capture is the base class for all of PGE and PCT.
so I think it gets used a lot. :-)
Whiteknight will just shut up now
allison pmichaud: Are you using the C Capture now?
pmichaud flh: Capture is basically a list and a hash, yes. It represents things that can have both positional and named values.
moritz flh: it's called "Capture" in Perl 6 because it captures the contents of an argument list 19:25
allison pmichaud: didn't you used to use a PIR Capture Class?
pmichaud allison: yes, but switched to the Capture PMC once it was available and reliable.
(because the Capture PMC is substantially faster)
Coke rant: now when a language is marked cross-HLL we'll have no idea WHICH languages it's HLL for. =-)
meaning we'll have to put it elsewhere. which means we'll have two places to check. 19:26
pmichaud Coke: I think the purpose of "cross-HLL" is to denote issues specifically affecting language interoperability
Coke: it's not intended to simply say "this issue affects multiple languages"
Coke in which case, that's a component, not a language.
pmichaud component++ 19:27
allison yes, I'm adding the component "hll-interop"
(did someone suggest it as a language?)
Coke I thought so, based on #ps. could have read it wrong. 19:28
it's still an issue that we can't say that some bug affects both tcl and rakudo.
easiest way around that is to fix all those bugs. =-)
Whiteknight: a surprising number of those 300 tickets are still open. 19:29
(for good reason)
allison Coke: hmm... we could probably create a custom select type
Whiteknight I think #ps today was very nice and very productive
maybe needs some practice, but good overall 19:30
pmichaud Coke: I suspect that TT #760 is no longer a blocker for Tcl. It's been marked as "rejected", at any rate.
(TT #760 is still appearing in the /16 report)
NotFound TT #661: there is still something on int blocking perl6, or any other?
Coke pmichaud: if the ticket is rejected, it shouldn't even be on that report.
pmichaud NotFound: I was just looking at that. I think #661 can be marked as resolved, at least from rakudo's perspective. 19:31
Coke: Agreed -- so perhaps the report needs fixing.
Coke will do.
allison pmichaud: you have a few minutes to talk about install questions?
NotFound pmichaud: I think you or some other rakudo guy said it was no tested yet on windows, maybe 2 weeks ago. Is this solved? 19:32
19:32 iblechbot joined
pmichaud NotFound: I think it is solved. But if it isn't, then we can wait until someone speaks up about it again. 19:32
(and they can file a new ticket if that's the case) 19:33
Coke pmichaud: fixed; added status column in report, skipping records == rejected.
NotFound I'll add a comment on the ticket saying it will be closed in a few days if no one objects, then.
pmichaud NotFound: +1
purl 1
pmichaud (though I'd be okay with closing it now.) 19:34
Coke NotFound: that is such a common action, i wonder if we should add a status called "closing".
chromatic Or "closed"?
Coke (anything in a closing state that's more than N days old is fair game to close.)
chromatic: but it's not closed.
nopaste "pmichaud" at 72.181.176.220 pasted "rakudo head running on Parrot trunk, spectest results" (31 lines) at nopaste.snit.ch/17068
Coke I suppose we could just say "closing ticket. Reopen if necessary" 19:35
chromatic Yep. Reopening is cheap.
NotFound Coke: I'd like that, if the close will be automated.
Coke and then leave off the last sentence to be succint.
er, terse. =-)
allison Coke: that has the advantage of requiring less work in the default case
chromatic It's like writing a technical book where each paragraph ends with a sentence telling you what the next paragraph will be about when you get around to reading it, which you'd already be doing if not for the presence of the sentence telling you what you will be reading in a moment.
Slightly different from the Star Trek V problem. 19:36
Sorry, Star Trek: Generations.
NotFound The I'll close it, following our guru's words about laziness.
dalek TT #661 closed by NotFound++: [TODO] Capture output of subprocesses 19:41
Coke wonders if he'll have to post that message with slight updates in another six months. 19:44
japhb Tene: re: the two "General Issues" at the top of trac.parrot.org/parrot/wiki/HllInteroperability ... Are they 1) already ticketed but you don't know the TT#s, or 2) definitely not ticketed, or 3) may or may not be ticketed?
pmichaud japhb: The second general issue is probably TT #150 19:45
japhb pmichaud: thanks, looking 19:46
Appears trac is quite slow right now ...
dalek rrot: r39847 | allison++ | trunk (2 files):
[book] Deleting draft chapter now split into a full PIR book.
 19:47
19:49 MoC joined, Sark joined
Tene japhb: I have no idea 19:49
japhb: I have a lot of trouble trying to remember to deal with tickets properly. 19:50
japhb Reading your TT #150, as suggested by pmichaud, I think he's right, that's a match for issue #2
japhb goes to edit wiki page
Crap, have to learn yet another markup language
nopaste "pmichaud" at 72.181.176.220 pasted "difference between perl6 fakecutable and perl6.pbc (for Util)" (20 lines) at nopaste.snit.ch/17070 19:51
pmichaud Util: See nopaste #17070 (above)
Tene japhb: Yes, tt150 is right
19:51 abesapien joined
smash any wiki page with the install issues mentioned earlier ? 19:51
japhb How do I mark up a TT# on the wiki so that it will be linked? Just do it like any other HREF? Or does it recognize special syntax?
Tene japhb: the other is 777
19:52 PacoLinux joined
japhb Tene: thanks 19:52
dalek TT #801 created by flh++: Rewrite capture.t in PIR
Util pmichaud: thanks; will investigate today.
Tene japhb: I'll try to work on enumerating and ticketing everything else I can think of tonight.
pmichaud japhb: I think just "#150" is sufficient to generate a link to a ticket.
japhb Tene: did you create one for the "can't instantiate classes other than the one named in the use statement" problem? ('use OpenGL::Math:from<parrot>;' doesn't allow 'new OpenGL::Math::Vec4') 19:53
Tene: thanks
Tene japhb: Your description there isn't exactly right...
but I have a few clues
japhb Tene: fair enough
allison pmichaud: one general philosophical question about install tools 19:54
Tene I'm checking to confirm that #744 hasn't been fixed yet...
allison right now, our biggest problem is trying to make install tools that ship with parrot and work when they live the build directory and also the install directories
smash wavez. 19:55
Tene hi smash
pmichaud allison: (short-circuiting where I think you're leading) I think we should no longer have a notion of "run from the build directory", except to the extent that we create something that looks like an install in the build directory
but I'm guessing you're actually about to ask something else :-) 19:56
allison pmichaud: this is much simpler if language building tools aren't installed with parrot at all, they're just given as "examples" and each language keeps their own customized versions
dalek tracwiki: v8 | japhb++ | HllInteroperability
tracwiki: Add Trac Ticket numbers for two existing General Issues
tracwiki: trac.parrot.org/parrot/wiki/HllInt...ction=diff
pmichaud allison: Philosophically I completely agree with that, but there are a few additions 19:57
allison pmichaud: aye, that's also true, to the extent that we can get a build directory to mimic an install
pmichaud In particular, Parrot should provide tools for compiling dynpmcs and dynops. We shouldn't expect languages to maintain separate copies of those.
chromatic I'd like to keep the ability to run HLL code from a Parrot I haven't installed with 'make install' or 'make install-dev', but I don't care if it gets rearranged by 'make' in the Parrot build directory.
Coke (make hll languages write their own tools); I have concerns with that.
pmichaud in fact, the tools for compiling dynpmcs and dynops need to follow the deprecation cycle -- they're in effect part of the Parrot API 19:58
allison pmichaud: that is, installing should be no more than copying from one directory to another
Coke: aye, the problem is when you have to fix a bug in the "example" that was the starting point for all the languages
pmichaud I completely agree that "make install" ought to act more like a copy. Currently it does a re-build, which means that what we tested with "make test" isn't at all what gets installed.
allison Coke: it doesn't automatically spread out to all the languages
chromatic: yes, being able to run in the build directory somehow is required for testing 19:59
pmichaud I think we all agree that Parrot's "make" should create something that looks like an uninstalled install 20:00
Coke pmichaud: given that we're linking against two different configs, I'm not sure you can avoid that.
allison pmichaud: but at the same time, you don't want Parrot to do the processing on your makefiles?
Coke it already doesn't rebuild individual c files, anyway.
pmichaud Coke: I'm saying there should be only one real "config"
Coke pmichaud: ... how?
allison pmichaud: (that is, I was thinking you were in favor of decoupling the languages from the Parrot scripts)
pmichaud Coke: but if there can't be only one real config, we should at least make the two configs look as similar as possible 20:01
Coke pmichaud: that's another issue for which there is already a ticket.
Whiteknight I added a priorities section to the main page of the wiki
we can list important priorities there
Coke (see doughera's thoughts on that process)
pmichaud Coke: i.e., paths to libraries and precompiled things should be the same (modulo the root of the directory)
allison pmichaud: "make install" shouldn't be building anything. If it is, it's a dependency bug in our makefile 20:02
dalek kudo: c51b9aa | jnthn++ | src/builtins/guts.pir:
Fix inheritance from Object - it no longer tries to also add Any as a parent also (which explodes when building the C3).
pmichaud Coke: I'm not at all claiming that what I'm suggesting is different from adougherty's stuff. :-) Everything I've seen adougherty write I agree with.
allison: iiuc, "make install" recompiles the parrot binary 20:03
I could be wrong -- haven't checked recently.
allison it didn't 4 months ago when I worked on the install process, but could have been introduced since then
Coke pmichaud: there is a ./parrot and a ./parrot_install, or something to that effect.
pmichaud Coke: yes, that's that I remember.
We test "./parrot", but then installed "./parrot_install" 20:04
Coke right.
pmichaud s/installed/install/
allison mmm... yes, that is true, and should change
Tene japhb: are we just listing all HLL-related tickets on the HLLinteroperability page?
Coke the only (theoretical) change is the config.
pmichaud no, other things change as well.
Coke Tene: better to just link to the report.
pmichaud In particular, the paths where the libraries get found.
Tene Coke: which report?
purl somebody said which report was the hopkins report? I'm losing track of which is which.
Coke those paths are in the config.
Tene: #16
pmichaud some of them are compiled into the binaries.
Coke as part of the config, yes? 20:05
japhb Tene: I was thinking "any tickets directly affecting HLL interop that don't affect single-HLL (or pure PIR) code"
allison pmichaud: yes, but it's the same ones between the two
pmichaud as hard-coded paths.
allison pmichaud: that is, Parrot has a set of search paths that include both install and build directories
Coke japhb, tene: in that case, you can just have a report that returns things assigned to that component.
allison and both ./parrot and ./parrot_install get the same search paths
pmichaud allison: that matches what I've seen, yes. But we should get rid of the "build directory" paths from parrot altogether.
Coke OBTW: 'make test' failing on feather because, I think, of the pre-installed 1.2.0 parrot. 20:06
japhb Coke: until a few minutes ago, we didn't have that component. We're still looking for the tickets. :-)
allison (there was a change proposed to have different search paths for the two, but it was rejected)
pmichaud i.e, we just include the install versions of the paths.
Coke I'm just saying, don't link to them, just tag 'em.
japhb Coke: can a report be embedded into a wiki page?
Coke japhb: embed? no clue. link to? sure.
going to yapc::eu?
purl it has been said that going to yapc::eu is (: going to YAPC::EU 2009)
Coke going to yapc::eu 2009?
purl going to yapc::eu 2009 is ash or BinGOs
Coke going to yapc::eu 2009 is also maybe coke
purl okay, Coke.
allison pmichaud: yes, that's perfectly possible, since the search paths respect the 'prefix' config option
jonathan going to yapc::eu 2009 is also jnthn
purl okay, jonathan.
Coke I just found out I'll be in the UK the week before. 20:07
japhb Coke: I'd prefer if they weren't a link apart. I'll see what embedding is available.
pmichaud at any rate, from a hll implementors perspective, it would be far simpler if the relative paths for components (e.g., nqp and perl6grammar) were identical for built and installed versions of Parrot.
japhb Coke, Tene: In the mean time, I'll change the Component for the tickets we know about.
Tene: What were your findings on #744?
Tene japhb: still segfaults
purl No whammies!
allison pmichaud: so, all that's actually stored is 'library/' or 'dynext/', and the 'prefix' provides the rest of the path
Coke pmichaud: that's solved by making the build look like the install.
pmichaud Coke: that's what I'm advocating, yes. 20:08
Coke so let's make that the priority.
Tene allison: could parrot_config locate the prefix it's currently running from at runtime?
Coke then maybe the config stuff will fall out of that.
pmichaud (afaik, I haven't been advocating anything else.)
Coke pmichaud: probably not. =-)
Whiteknight is heading home
Coke Whiteknight: no!
you stay right there.
Whiteknight !!!
Coke JK.
allison there's a tricky bit to making the build look like the install, though, and that is the clash between the parrot runtime directories and the C directories (we have two 'include' directories) 20:09
Whiteknight haha, later
pmichaud allison: (decoupling) Some things like makefile generation should be decoupled from parrot -- i.e., I expect languages to create their own tools for that (from examples that Parrot provides)
Coke allison: just have our "local install" go into blib
20:09 MoC joined
pmichaud that's because hlls and other users may have some heavy customization they need to do with makefiles 20:09
allison pmichaud: but dynpmcs and dynops are makefiles
Tene I discovered today that cloneflags.pasm isn't installed. Is this an issue? 20:10
pmichaud I think that dynpmc and dynop generation ought to be tools that Parrot provides
and *not* be pure makefiles
because the generation of dynops and dynpmcs is heavily dependent on configuration information that's not easily managed in makefiles
jonathan That's what the (now deprecated) tool for them did, IIUC?
allison pmichaud: they're just a series of generated and compiled files, with dependencies on what should be built first 20:11
20:11 brbrooks joined
jonathan (e.g. the one that Rakudo still uses...unless that's changed...) 20:11
pmichaud allison: what generates the files?
allison pmichaud: it seems a bit silly to reinvent makefiles
pmichaud we don't really need to reinvent makefiles here, though. 20:12
allison pmichaud: it's pretty much exactly like PGE
pmichaud I don't understand "exactly like PGE"
allison pmichaud: you call a script to process some syntax
pmichaud: it generates a more general form, which is then compiled
pmichaud I'm saying that script ought to be one level higher than it is now
allison the script should generated the C code and compile it? 20:13
s/d//
pmichaud yes. or the script should generate the makefile
but having the hll implementor manually maintain the makefile is asking for lots of difficulties
allison I'm in favor of generating the makefiles, perfectly possible
but, then we have some makefiles generated by Parrot and some not
pmichaud well, that's why I think the tool should just do the compilation oughtright. 20:14
*outright
it's not too much of a stretch to think of pmc2c as becoming pmc2lib
or something that directly compiles *.pmc files into the library form.
allison that is what the old tools did, but they kept getting the dependencies wrong, because they were a perl script trying to act as a Makefile
pmichaud I'd say to fix the old tools then (more) 20:15
in particular, I don't see an advantage to breaking up the .c .o .lib dependencies
allison that's the way makefiles work
pmichaud but they don't have to
(more)
allison each file generated is a target, so it can check if it's changed
pmichaud it's perfectly possible to write a target that goes completely from .pmc to .o 20:16
without having to write the intermediate target for .c
allison yes, but that's a bad makefile, it has to recompile from source every time
pmichaud isn't that the case anyway?
allison if the .o file hasn't changed since the last compilation, it doesn't have to recompile it to build the .lib 20:17
pmichaud right, but the dependency for the .o can be the .pmc file, not the .c
20:17 Zak joined
allison sure, it can 20:18
pmichaud speaking from an hll perspective at the moment, though, I think I'd rather have a change to a .pmc cause recompilation of all files than to have to worry about managing many individual dependencies myself
especially if/when I have .pmc files that depend on other PMCs, and those have to be linked properly.
allison so, you'd write your makefiles that way
pmichaud the issue is that writing those makefiles is very prone to error at the moment. 20:19
allison that's the advantage of leaving languages free to write their own
it's a choice between freedom and the ease of a blackbox 20:20
pmichaud right now compiling ".pmc" files feels like it ought to be a blackbox
I don't see where making it non-blackbox provides any real advantages to hll implementors.
allison I suspect we'll never write tools that satisfy every language implementor, but I still think it's worth providing tools to make it easy 20:21
pmichaud right.
allison easy for the default case
japhb allison: Does it need to be a choice that Parrot makes? If Parrot provides the blackbox tool, then the HLL can use it ... or not, if they want to Makefile-to-the-metal
pmichaud so I'd like a tool that makes pmc and ops generation simple
japhb nod
allison then I'd go for a makefile generator tool
pmichaud much like what we have now in the build tree that Rakudo is using
allison you never have to look at the makefile if you don't want to, it'll just be generated for you 20:22
pmichaud in current Rakudo trunk, it's nice because we just list the *.pmc files in our Makefile and the libraries get compiled automatically
allison but, it's there if you want to modify it
pmichaud we don't have to deal with any separate makefiles at all
allison pmichaud: aye, that's the old tools, but they will never work from an installed parrot
pmichaud i.e., Parrot (build) provides tools to go directly from .pmc to *.so 20:23
can we make tools that would work from an installed parrot?
allison now
no
pmichaud why no?
allison they're a perl script that's template generated using hard-coded build paths
okay, there's one way you could save it
pmichaud can we make a perl script that doesn't have hard-coded build paths?
allison do the template generation of the perl script in Rakudo, instead of in Parrot 20:24
pmichaud: not in Parrot, no
pmichaud allison: why not?
allison clarify: someone could write a script like that, yes, but they wouldn't be using any of the existing code 20:25
pmichaud presumably they would re-use pmc2c.pl and ops2c.pl (the libraries), though, yes?
allison and, adding more magical, blackbox, unmaintainable perl scripts is really undesirable at this point 20:26
pmichaud let me try this approach
(writing nopaste)
allison pmichaud: well, no, I mean the original was just calling those scripts 20:27
pmichaud: see tools/build/dynpmc.pl
pmichaud: it really was literally a Makefile written in Perl
pmichaud: entirely unnecessary, and buggy as heck
nopaste "pmichaud" at 72.181.176.220 pasted "ideal makefile entries for dynops and dynpmcs" (5 lines) at nopaste.snit.ch/17071 20:28
pmichaud ideally that's what I think what a hll implementer should use to compile dynops and dynpmcs 20:29
allison how is pmc2lib supposed to figure out what the individual pmcs are? 20:30
pmichaud so that if I have a new .pmc file, I just update PMC_SOURCES and then "make"
because the individual pmcs would be given by PMC_SOURCES
nopaste "NotFound" at 213.96.228.50 pasted "Patch for TT #794: fix and test" (68 lines) at nopaste.snit.ch/17072 20:31
NotFound Is that tne intention of the ticket?
chromatic Looks right to me, NotFound.
allison pmichaud: what about additional C dependencies? 20:32
pmichaud allison: I haven't run across those yet (more)
I admit that they may occur. But thus far in Rakudo we haven't run across them nor do we expect to anytime soon.
jonathan allison: buggy as heck? It's been building Rakudo's dynpmcs for months...
allison pmichaud: I'm trying to be convinced, I just can't see that pouring the effort into writing pmc2lib is worth it to avoid a simple makefile
pmichaud allison: I'd agree if the makefile were simple. 20:33
The makefile is not simple.
The makefile is quite complex.
allison jonathan: look back over tickets that tried to change it in any way, it's ossified
pmichaud: aye, but the makefile is also formulaic, it can be generated 20:34
Tene pmichaud: can you show what the makefile needs to look like without pmc2lib?
pmichaud Tene: code.google.com/p/partcl/source/bro...les/pmc.in 20:35
Tene Coke++
chromatic That could be simpler with rules for .pmc .c and .dump files... except that the rules for .c files there might conflict with the rules for .c files elsewhere. 20:36
allison pmichaud: that is, I could give you a similar script to call in the config file "$tools_dir/pmc_makefile" passing it the same list of *.pmc files and the desired directory name
NotFound Can I commit that right now, or it risk to break something in some HLL?
pmichaud there's also the issue that some .pmc files depend on others 20:37
which the makefile for tcl doesn't seem to illustrate
allison though, what do we do when some languages are using the Perl .pmc generator while others are using the PCT-based one?
if it's all central, it's harder to make the migration optional 20:38
(or gradual)
pmichaud Rakudo's ins branch attempts to simplify what tcl did a bit: github.com/rakudo/rakudo/blob/ins/b...akefile.in 20:39
(line 365)
(actually, lines 365-372)
allison pmichaud: that looks good 20:42
pmichaud except I don't like the *.c (might not be portable)
and it fails on certain platforms, as described by adougherty++
because the LD_OUT macro doesn't expand properly on certain systems 20:43
and LIBPARROT doesn't properly handle the #IF(parrot_is_shared) option that tcl is using.
allison on LD_OUT: aye, that's usually why we end up using the simplest possible Makefile syntax 20:44
pmichaud I'd prefer to be able to create Makefiles that didn't require the special #IF(...) preprocessing. 20:45
allison conditionals are useful in makefiles 20:46
and, it doesn't really provide good syntax for them internally
pmichaud right; the code that Parrot's makefile generator uses for handling conditionals feels bletcherous to me, though. 20:47
Tene *obviously* we need a Parrot-hosted 'make' replacement.
japhb Tene, Coke: How does this look? trac.parrot.org/parrot/wiki/HllInteroperability
pmichaud Tene: I disagree with that.
Tene pmichaud: Yes, so do I. I was trolling. :)
japhb The "General Issues" is an inline query, and the "Known Workarounds" is hand-edited
allison pmichaud: no arguments here, but does that mean we throw it out or fix it? 20:48
Tene japhb: nice. :)
chromatic You don't think this whole system is bletcherous? (more)
allison pmichaud: another rhetorical question
pmichaud: we need conditional makefiles for Parrot, and they aren't going away
chromatic We use a Perl 5 system to write and run C code to probe system capabilities, then write a Makefile which calls Perl 5 code to run a C compiler and linker to build Parrot and Parrot extensions.
pmichaud allison: yes, but you're also saying that every hll needs conditional makefiles. 20:49
dalek tracwiki: v9 | japhb++ | HllInteroperability
tracwiki: trac.parrot.org/parrot/wiki/HllInt...ction=diff
allison pmichaud: so, we will have to fix the processing. That doesn't mean every hll has to use it.
pmichaud hll's have to do something to be able to handle those conditions, though, yes?
i.e., they might not use conditional make files, but they have to implement their own equivalent mechanism for handling it?
allison hmmm... well, I'll go so far as saying building C code using Parrot will always require knowing whether parrot is shared or static, yes 20:50
pmichaud it's more than that -- the ops generation requires knowledge of all of the available runcores 20:51
allison that too
pmichaud which means that when Parrot gets a new runcore, I have to update my Makefile
allison or, rerun the script that generated the makefile
which should probably be run as part of Configure.pl 20:52
pmichaud and then re-apply any local patches I had made
Tene allison: pynie isn't even using a makefile... would pynie just have to reimplement everything?
allison Tene: yup, pynie uses python build infrastructure
20:52 Theory joined
Tene So Parrot just wouldn't offer anything here to pynie, with your scheme? 20:52
allison Tene: it'll likely eventually use autoconf
pmichaud I'll be curious to see pynie make use of dynpmcs and/or dynops :-) 20:53
allison Tene: aye, so you can see why I'm less inclined to favor the "centralized language build infrastructure"
pmichaud: it's just a simple series of calls to scripts and c compilers 20:54
Tene Hmm, okay.
allison any build system can do it
pmichaud I'm not at all claiming that parrot should centralize the entire build. I'm simply saying we should give a slightly higher level of abstraction for dynpmcs and dynops
allison it just strikes me as a difficult solution to a simple problem 20:55
dalek kudo: fbc5428 | jnthn++ | src/ (6 files):
Factor out type check error generation to one place and use it consistently. There are improvements we need to do to the reporting, but at least now we need to fix it in one place and the errors will now all consistently contain the type we got and the type we expected.
pmichaud allison: fair enough (more)
allison I wouldn't object if someone wants to write it, but there are other places I'd rather see the effort go
pmichaud I think we're in agreement there (more)
it sounds like you're not unalterably opposed to it, but you're not wanting to dedicate resources to it when there are other priorities
I can't disagree with that 20:57
I don't disagree with that
mikehh allison: make html - Failed to process docs/book/draft/ch03_pir.pod.
chromatic The sooner we can stop writing ops and PMCs in C, the sooner this problem goes away.
allison mikehh: thanks, will fix
pmichaud so while I'd like to see something cleaner, I'm not personally wanting to dedicate a lot of time to it either, which means we should leave things as they are now (even if somewhat more painful for makefile management in hlls) and focus on other priorities. 20:58
allison pmichaud: I guess at this point what I'd say is to think about modularity as you switch Rakudo off the old tools
pmichaud: whatever you develop may get "cannonized"
er, canonized :)
pmichaud allison: that's exactly how I was thinking.
which is why I didn't like the possibility of canonizing the ugly makefiles.
I also didn't want to complicate the gen_makefile.pl script that Rakudo uses with conditional handling, but it looks as though I will have to do that. 20:59
either that or we get Rakudo to use Parrot's gen_makefile.pl script.... but that's just putting a different parrot dependency in place. 21:00
(i.e., building Rakudo would still depend on a parrot tool)
allison yeah, it's a tossup there
pmichaud so I think the answer to your earlier question is that we have to "fix conditional handling of makefiles" 21:01
allison it's a pretty light tool, but it does use some Perl libraries from Parrot's build system
pmichaud I was hoping to avoid that, but the only other option is to make it possible to create dynops and dynpmcs w/o conditionals (which doesn't seem likely at this point) 21:02
allison is that something we could get a volunteer working on? or do you have a pretty clear idea how to fix that chunk of code?
pmichaud ideally I'd want a gen_makefile.pl to not have any dependencies on the Perl libraries in Parrot's build system 21:03
or, if we expect hll implementors to be using Parrot's copy of gen_makefile.pl, then we should put it on a deprecation cycle and document its API
we also need to document and explain the pmc2c and ops2c scripts. 21:04
(and they need to be on the deprecation cycle as well)
allison mmm... in that case, I'd just update your gen_makefile.pl
and we can review it as a candidate replacement for the existing gen_makefile.pl 21:05
though, the existing one is just a few lines long
pmichaud okay, so planning (more) 21:06
allison and has the advantage of not duplicating code (even if the code it's not duplicating is kind of ugly, at least it's ugly once instead of ugly twice)
pmichaud I'm probably not going to want to switch rakudo to using Parrot's gen_makefile.pl, for the modularity issue you mentioned above (and other reasons)
so, I'll look into updating Rakudo's makefile generation (and its tool)
but I'd really like to see that Parrot's build/install layout get cleaned up first 21:07
so that we're not having to do a bunch of conditionals along the lines of "if this is an install, do XYZ, otherwise do ABC"
allison I don't have a list of where all those differences are 21:08
but could probably find them pretty quickly trying to build Rakudo off an installed Parrot 21:09
pmichaud I think if we just take the approach of having Parrot's "make" put everything into an install-template
then we'll remove the differences in the first place
at least, we'll remove the bulk of them.
currently the "ins" branch in Rakudo is able to build Rakudo from an installed parrot, but the fakecutable still depends on the build tree being present 21:10
21:10 amuck_ joined
pmichaud (like Tcl, though, the "ins" branch can only build from an installed parrot -- it's not possible to build Rakudo from a build-copy of parrot) 21:10
21:11 Whiteknight joined
allison yes, the fakecutables still don't work without the build directory 21:12
pmichaud: we're basically looking at something like the DESTDIR option being turned on all the time 21:13
21:13 zak_ joined
allison or, 'make disttest' 21:14
spinclad 'make build; make DESTDIR=<build> test' v. 'make build; make install; make DESTDIR=<install> test' 21:17
and at some stage one can check, with strace or such, that all component accesses look to the right DESTDIR. 21:19
21:19 abesapien joined
pmichaud anyway, as a general item I should probably note that my tuits for parrot core development are likely to be somewhat limited for the next few months. My Hague grant has been starved for resources while I've been dealing with install/build/packaging/other issues in Rakudo, and I need to get moving on the Hague grant (because without it I have no income at the moment). 21:20
Util pmichaud: [nopaste 17070] Besides changing `git@` to `git://` in the `git clone`, I followed your instructions exactly, on both Darwin and Linux. 21:21
All three tests report `ok` in `./perl6` and `parrot/parrot perl6.pbc` runs of t/01-sanity/07-isa.t, on both systems.
Further info: on Darwin, `make spectest` only fails t/spec/S12-enums/basic (Failed test: 27) and t/spec/S32-num/rand (Parse errors: Bad plan. You planned 110 tests but ran 106.)
Linux `make spectest` has not completed.
Cannot proceed with investigation :(
pmichaud Util: what Linux? 21:22
purl Linux is linux is linux by another name. or 80% of the world's top 500 super computers right now and the number one embedded system broadcast.oreilly.com/2008/10/how-l...evice.html
pmichaud (tuits) I do still expect to be able to complete the hll-interop items, as they directly affect Rakudo, but troubleshooting install/core issues may be more difficult for me to come by. 21:23
Util pmichaud: Mandrakelinux release 10.1 (Community) for i586
Linux version 2.6.8.1-10mdksecure (nplanel@n3.mandrakesoft.com) (gcc version 3.4.1 (Mandrakelinux (Alpha 3.4.1-3mdk)) #1 SMP Wed Sep 8 16:46:40 CEST 2004
pmichaud util: okay, I'm on kubuntu 9.04 (i386) 21:24
I'll try on 64-bit just to see if I get anything different.
I'm not sure what masak++ is running, but he noticed similar errors today.
jonathan allison: Are you currently expecting to have some Parrot-y meetup in the day or two after YAPC::EU? 21:25
allison: Basically it's easy for me to be there on the Thursday, and a little less convenient but possible for me to be there on the Friday.
But I need to find/book a flight, so would be good to have an idea. 21:26
pmichaud Util: can you verify the revision of Parrot that you got? parrot/parrot_config revision 21:28
Util pmichaud: 39846 on both Darwin and Linux 21:29
pmichaud okay.
I'm stumped, then.
let me see if I can duplicate on another platform somewhere.
Util: on my 64-bit box (using the git://... address) it compiles and runs fine. Let me try again on my 32-bit box. 21:33
nopaste "mikehh" at 86.150.205.31 pasted "codetest failure from make fulltest at r39847" (29 lines) at nopaste.snit.ch/17073 21:34
"mikehh" at 86.150.205.31 pasted "PATCH for codetest failure at r38947" (17 lines) at nopaste.snit.ch/17074 21:35
mikehh codetest passes with the patch
chromatic +1 on the patch 21:36
Infinoid mikehh: Thanks, applied as r39849 21:38
dalek rrot: r39848 | Infinoid++ | trunk/t/op/integer.t:
Apply integer.t_to_pir.patch from flh++ in TT #796.
rrot: r39849 | Infinoid++ | trunk/docs/book/pir/ch06_subroutines.pod:
Apply patch from mikehh++:
allison jonathan: yes, thursday sounds good 21:39
21:39 amuck__ joined
allison jonathan: my schedule is pretty flexible, but it's likely that I'll want to get on the road Friday too 21:40
dalek TT #796 closed by Infinoid++: Rewrite globals.t and integer.t in PIR
jonathan allison: OK, that's helpful to know. 21:41
Whiteknight Infinoid: what do we need to do to get io_cleanups knocked out? I feel like you have a better idea about what needs to be done then I do
jonathan allison: I'll be around all conference too; I'm sure there'll be some degree of hallway track. :-)
I'll probably arrange to head off on Friday too.
allison pmichaud: yes, that's reasonable. Fortunately I'll have a pile more time for Parrot core starting in late July
jonathan: I may be doing all hallway track at YAPC::EU 21:42
jonathan allison: Sure. I'll probably just take things as they come...
allison jonathan: hmmm... are they doing hacking rooms again this year? that was very useful
Whiteknight (more time for Parrot core)++
Infinoid Whiteknight: Lemme swap that back into my poor little brain
jonathan allison: They may be, but I dodn't remember reading anything of that. 21:43
Infinoid Whiteknight: (I know the feeling, I haven't found any chunks of time for parrot greater than 5 minutes for the last week or more
Whiteknight: )
allison jonathan: I guess it entirely depends on the space. Braga had great space for sitting out and hacking, Vienna less so, Copenhagen very little. It's an adventure. :) 21:44
jonathan :-)
jonathan is looking forward to it. 21:45
pmichaud Util: now I find I'm unable to duplicate the error I was getting earlier. I have no clue why. Earlier I started from a completely fresh checkout as well. 21:49
Whiteknight would love to make it to YAPC::EU sometime 21:50
pmichaud oh, wait, I might've tested the wrong one. 21:54
Infinoid Whiteknight: Ok. To get this working, Pipe needs an additional ATTR to store a child process pid. This should be initialized to -1 or some arbitrarily chosen win32-friendly value. If the destroy() method detects a sane pid, it should call an OS-specific child process cleanup function 21:55
dalek tracwiki: v79 | whiteknight++ | WikiStart
tracwiki: Add a link here to a page about installation. This may be the wrong page, somebody please correct me if so
tracwiki: trac.parrot.org/parrot/wiki/WikiSt...ction=diff
Infinoid We don't have a Parrot_waitfor() but we might consider adding one for this
rather, PipeHandle needs these things, not Pipe 21:56
Whiteknight okay, that all sounds reasonable
I wouldn't know how to write Parrot_waitfor(), would you know how to do that?
Infinoid yeah. The relevant code is already there in src/io/unix.c and src/io/win32.c 21:57
Whiteknight oh, okay
Infinoid It's just terribly FileHandle-specific at the moment
Whiteknight what about other systems then, is there an equivalent for portable.c?
Infinoid I don't know. I think fork() and pipe() are also missing in that case 21:58
Whiteknight ok
21:58 bacek_ joined
Infinoid oops. s/waitfor/waitpid/ 21:59
Whiteknight Infinoid: what should the type of this new ATTR be, PIOHANDLE?
because Win32 doesn't really have much notion of pids
Infinoid Sure it does, you can see them in the Task Manager if you enable that column
Judging from Parrot_io_close_win32(), it looks like a HANDLE, so if that's what PIOHANDLE wraps, it should work fine 22:00
INTVAL procid = VTABLE_get_integer_keyed_int(interp, filehandle, 0);
HANDLE process = (HANDLE) procid; 22:01
WaitForSingleObject(process, INFINITE);
that's beautiful. HANDLE is a pointer, isn't it?
CloseHandle(process);
Whiteknight well, let me rephrase that. Win32 has pids, but uses HANDLE to keep track of child processes 22:02
pmichaud Util: Just confirming that I'm unable to duplicate the errors I saw before. I'll keep an eye out for the problem and let you know if they arise again.
mikehh smolder don't seem to be talking to me again
sorry it just responded 22:03
Infinoid Whiteknight: thanks, win32 confuses me :)
NotFound CreateProcess returns a handle for the process and other for his main thread. The thread handle is closed during open, for simplicity.
mikehh pre/post config, smolder, fulltest All PASS at r39849 - Ubuntu 9.04 amd64 22:16
Whiteknight Infinoid: how do we wait in Unix?
what's the equivalent to WaitForSingleObject?
Infinoid waitpid()
purl waitpid() is probably the way to go if you need to just hang around waiting.
Infinoid Parrot_io_close_unix() has the equivalent to the above code 22:17
Whiteknight do we have any test systems where the portable.c stuff is actually used?
Infinoid I don't know of any. I've been wondering that for a while now 22:18
If I understand correctly, portable.c is just stdio, but unfortunately, stdio is limited to simple file access, and doesn't try to handle child processes or sockets or pipes or threads, so we still need something OS-specific to handle those things 22:20
NotFound There is the popen call, but if a system has it probably also has fork and pipe.
Whiteknight okay, I have a commit coming through now that adds a child PIOHANDLE to PipeHandle 22:21
now we just need to find places to set this value (Parrot_io_open?)
Infinoid hmm, interesting. the popen() manpage claims to be POSIXful
PipeHandle.new() and overridden by Parrot_io_open_pipe_* I guess 22:22
dalek rrot: r39850 | whiteknight++ | branches/io_cleanups/src (2 files):
[io_cleanups] add a child PIOHANDLE to PipeHandle PMC, to keep track of a child process that is attached to the pipe.
 22:23
Whiteknight you want to prototype something for it, or are you going to leave me to fumble around in the dark with it? :) 22:24
Infinoid heh, I've still got the editor window open with fixups for Parrot_io_open_pipe_unix 22:25
Whiteknight does it make sense to ever create just a PipeHandle, or do we always create an entire Pipe? 22:27
NotFound Are you planning to go to Lisbon? If you break my pipe implementation, I don't recommend you go to a place near me }:)
Infinoid creating a PipeHandle does not make sense, as it won't be connected to anything.
hmm.
Whiteknight Okay, I'm trying to modify the logic in Parrot_io_open that creates a new FileHandle by default if a PMC is not provided 22:28
I want to create a Pipe instead then if the PIO_F_PIPE flag is specified
Infinoid I suppose you could optimize this case a little bit by only creating *one* of the PipeHandles yourself, if the other one will just be freed
But in the open() case, the other side of the pipe is just gonna call exec() anyway, so I doubt it's worth the trouble of freeing it properly
Whiteknight really needs to read this whole Pipe/PipeHandle implementation a little closer to figure out what is happening 22:29
Infinoid Pipe/PipeHandle are pretty basic, I think the real beef is in the pipe() manpage
22:30 Limbic_Region joined
Infinoid You're welcome to harass me if something doesn't make sense, though. That would mean I haven't written enough documentation :) 22:30
Whiteknight okay, so what happens when I type "$P0 = open 'perl -v' "rp"'? 22:31
what type should $P0 contain, a Pipe or PipeHandle?
Infinoid $P0 will contain a PipeHandle 22:32
Whiteknight okay, so Parrot_io_open should open and return a PipeHandle?
Infinoid open() will internally create a Pipe, fork a child, extract the fd from one of the PipeHandles and use Parrot_dup() semi-blindly, hoping it ends up as stdin or stdout (I think that can be done a little more nicely) and exec the child process 22:33
the parent process returns the other PipeHandle
uh, all that extract/Parrot_dup stuff happens in the child process prior to calling exec(). My sentence making sk1llZ are full of fail today. 22:34
22:35 rg joined
Infinoid It's basically the same thing the existing code already does, we're just doing it with PMCs now 22:36
NotFound You can use dup2 instead of dup to make more clear the intention. 22:37
Whiteknight okay, I added basic support to Parrot_io_open for pipes, take a look at this next commit to makes ure it's sane 22:40
dalek rrot: r39851 | whiteknight++ | branches/io_cleanups/src/io/api.c:
[io_cleanups] add basic preliminary logic to support for Pipes to Parrot_io_open. Probably doesn't work as-is
Infinoid Oh. Uh... 22:43
I've just been hacking Parrot_io_close_unix() to return a PipeHandle directly, I haven't looked at Parrot_io_open() yet
Looks like the flags handling stuff is going to need some help too tho, thanks for pointing that out
uh 22:44
Infinoid =~ s/Parrot_io_close_unix/Parrot_io_open_pipe_unix/
Whiteknight the logic in Parrot_io_open is a little lousy as-is, should probably refactor that function a little bit 22:45
Infinoid great. I've been avoiding it until later because it looked complicated :) 22:46
NotFound Whiteknight: I had the idea of doing that, but left it when you started to talk about refactoring handles.
Whiteknight hey, don't let me stop you, feel free to jump in!
NotFound I'll think about that tomorrow, now I go to bed :O 22:47
Whiteknight NO BED! HACK NOW! 22:48
bacek_ Good morning
purl Here I am, brain the size of a planet, and all they say is 'Good Morning'
NotFound www.youtube.com/watch?v=56lF8E1psDU
Infinoid hai bacek_
bacek_ o hai, Infinoid
Infinoid <MCHammer> Stop. Sammich time! 22:49
22:59 Zak joined
Whiteknight hey, we just had sammiches too! 23:04
Infinoid Sammiches++ 23:06
Whiteknight actually, we've done sammiches two nights in a row now. BLT last night, chicken salad tonight
Infinoid gets an ENOMOARSAMMICH and returns to hacking parrot 23:08
chromatic Honeymoon's over?
Whiteknight no, we've both just been craving sandwiches 23:09
plus we've gotten some really ripe tomatoes, so we put them on everything
23:09 skids joined
Infinoid even chicken salad? 23:12
Whiteknight hellz yes. I make the best chicken salad too, and we put all sorts of stuff into it
tonight we did celery, craisins, and tomato 23:13
Infinoid cool.
jonathan Mmmm...celery. 23:14
23:14 amuck joined
jonathan hadn't been hungry until he just glanced at #parrot 23:14
Infinoid ok. I just need to do the child process part and then I'll have a patch that probably crashes gloriously
23:15 snarkyboojum joined
Infinoid Do you happen to know if the IO PDD mentions anything about open() and pipes mucking with stderr? 23:16
This code tries to direct both stdout and stderr to the pipe, which I'm not sure is common behavior.
(I don't see anything, so I'm thinking about ripping it out) 23:17
23:25 patspam joined, NotFound joined
Infinoid My eternal glory is somewhat delayed by the fact that I can't figure out the right path prefix for including a pmc_*.h header 23:28
Infinoid loves it when he forgets simple stuff like this. :) 23:29
Whiteknight I have no idea
chromatic: ping
Infinoid apparently when in src/io/, one must include "../pmc/pmc_foo.h" 23:30
chromatic pong 23:31
Whiteknight chromatic: about how many PMCs get allocated by Parrot on startup? have you seen any numbers like that in your profiling?
chromatic I can check quickly.
Whiteknight because it occurs to me that our initial mallocs should provide at least that many initially, so we don't run the GC on startup
chromatic 1147 to run "Hello, world" from PBC. 23:32
That's initialized PMCs. 23:33
305 constant (a different pool).
290 non-initialized PMCs (does not call VTABLE_init).
I don't expect a speedup making the initial arenas larger, though. 23:34
I'll give you a hint: free list.
Whiteknight if the initial arena is smaller, we have to do a full GC run first, then allocate a new arena, so I would expect some speedup
of course, it would be easy enough for me to test that... 23:36
chromatic A better speedup is not dumping everything from a new pool onto the free list first.
That means changing the code that grabs a new GCable to check the free list first, then if it's empty do a pointer bump in the fresh arena, and if it reaches the end, do a GC run. 23:38
nopaste "infinoid" at 173.75.243.238 pasted "[PATCH] [HALF-BAKED] This is the kind of thing I had in mind for child pipe creation" (127 lines) at nopaste.snit.ch/17076 23:40
Whiteknight chromatic: you're right, that's probably a good speedup too 23:49
that small algorithmic change might make for a great second core in the GC 23:50
Tene Whiteknight: your next big task is AIO, right?
chromatic Let's make that a second core so we can test it. 23:51
Whiteknight Tene: that's the plan, yes
chromatic: good idea
purl Whiteknight: Good Idea: Playing catch with your grandfather. Bad Idea: Playing catch >with< your grandfather.
Whiteknight I think we have a new hacker who's interested in helping out with GC too
haha! upping the initial allocation to 2048 PMCs sped up coretest on my system by 2 seconds 23:52
EAT THAT HATERS!
Infinoid haters? 23:53
purl i think haters is nom nom nom
chromatic Two seconds in coretest is noise.
Whiteknight yeah, I know
chromatic Mine varies anywhere between 40 seconds and 55.
davidfetter don't hate the parrot. hate the game 23:57
player* 23:58
Whiteknight WHO HATES PARROT?!?!

Powered by Cro and the Raku® Programming Language.

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

Thank you!