Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2009-06-02

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
01:41 japhb joined #parrotsketch
10:56 masak joined #parrotsketch
12:06 Whiteknight joined #parrotsketch
13:18 payload joined #parrotsketch
14:30 masak joined #parrotsketch
14:51 payload joined #parrotsketch
15:06 PacoLinux joined #parrotsketch
15:07 PacoLinux left #parrotsketch
16:05 pmichaud joined #parrotsketch
16:21 particle joined #parrotsketch
16:52 NotFound joined #parrotsketch
17:20 Util joined #parrotsketch
18:11 mberends joined #parrotsketch
18:23 darbelo joined #parrotsketch
18:25 jhorwitz joined #parrotsketch
18:27 jonathan joined #parrotsketch
18:28 allison joined #parrotsketch
18:30 Whiteknight hello
18:30 jonathan hi
18:30 darbelo hola
18:31 chromatic joined #parrotsketch
18:31 allison hi
18:31 chromatic $localtime
18:31 cotto hi (no report this week)
18:32 chromatic Let's begin.  allison?
18:32 NotFound hola
18:32 Util hi
18:33 jhorwitz hi
18:33 allison - Almost through editing the final chapter of the PIR book.
18:33 pmichaud hello.
18:33 allison It'll be up in 2 seconds on http://pub.lohutok.net/onyxneon/
18:34 allison - Will be traveling most of the next week.
18:34 allison EOR
18:34 chromatic chromatic?
18:34 chromatic Thanks for asking!  I fixed several memory leaks.  IMCC has a few more nasty ones that hit Rakudo hard.
18:34 chromatic I have a couple of bugs to fix today.
18:35 chromatic I'm writing a grant to develop a new profiling core for Parrot, as HLLs need it badly.
18:35 chromatic That should be available at least at the .sub level for 1.4.
18:35 chromatic jhorwitz?
18:35 jhorwitz no report -- just started working on slides for YAPC.
18:36 chromatic jonathan?
18:36 jonathan Parrot
18:36 jonathan * Re-ordered some code in object cloning that looked like it might be vulnerable to the GC sweeping away stuff we'd rather it didn't.
18:36 jonathan * Tracked down the cause of a segfault I'd got in Rakudo and filed a ticket.
18:36 jonathan Rakudo
18:36 jonathan * Finished up the dispatch refactor at long last
18:36 jonathan * Now method dispatch in Rakudo is just done using the PIR method calling syntax
18:36 jonathan * Was quite a good performance win, and an interop win
18:36 jonathan * In the process, got support for deferal of method calls in place. Quite nice, we only produce the candidate list when we're asked to defer. Needs a lot of testing, didn't really do that yet, just wanted to get the refactor done
18:36 jonathan * Now we aren't cheating on so many things, various minor issues came up that I need to ponder some, for now all workaroundable so that's what I did
18:36 jonathan * Re-worked caching in Perl6MultiSub - now method dispatch is faster and we create caches lazily to decrease startup cost
18:36 jonathan * Other bits...
18:36 jonathan Scheduling:
18:36 jonathan * Going to be away for the second half of June and a just over a week in July taking vacation.
18:36 jonathan * Will be attending YAPC::EU and YAPC::Asia
18:36 jonathan .end
18:37 chromatic moritz?
18:37 * Tene more HLL interop work.  KTHXBAI
18:37 jonathan (I believe moritz is away on vacation.)
18:37 chromatic NotFound?
18:38 NotFound * Added setstdin opcode
18:38 NotFound * Miscellaneous fixes and cleaning
18:38 NotFound EOR
18:38 chromatic particle?
18:38 jonathan q1q
18:38 chromatic PerlJam?
18:40 chromatic pmichaud?
18:40 pmichaud General:
18:40 pmichaud * Rakudo now passing 11,346 spectests (+3 since last week)
18:40 pmichaud * Tracked down the issue behind TT #24 (non-equivalents of hash keys)
18:40 pmichaud * Added a fix, which bacek++ improved
18:40 pmichaud * Updated PCT::HLLCompiler transcode option to allow multiple attempts
18:40 pmichaud * Rakudo and other langs can now optionally transcode to iso-8859-1 for parsing, significantly faster than utf-8.
18:40 pmichaud * With help from NotFound++ and Infinoid++, significantly improved PMCProxy creation in class lookups
18:40 pmichaud * Played with switch Rakudo to hll_map Int and Num, but doing so results in a significant speed penalty so we may avoid hll_map for a while.
18:40 pmichaud Other Rakudo stuff:
18:40 pmichaud * Fixed symbol importation for settings
18:40 pmichaud * Fixed IO.get, moved from PIR to setting
18:40 pmichaud * Worked out BEGIN implementation details (not committed yet)
18:40 pmichaud * Fixed various quoting construct errors, die with useful message on s///
18:40 pmichaud * Corrected cross-metaop handling
18:40 pmichaud * Updated postfix:<++> to be 75% faster
18:40 pmichaud * Refactored .succ/.pred handling overall
18:40 pmichaud EOR
18:41 chromatic Util?
18:41 Util * Two issues from last week are now tickets: * TT #710 - Win32 huge strings do not print on console * TT #717 - Segfault in `parrot_config --dump`
18:41 Util NotFound++ has workarounds for both, reducing the problems to the point that I cannot (yet) recreate them. I plan to test further.
18:41 Util * Talked at length at Atlanta.pm's after-meeting dinner with a IRC-log (#parrot and #perl6) lurker. He is interested in participating, but notes that his route is rocky due to a sore shortage of "overview" and "status" docs. Just FYI.
18:41 Util * TT #688 - Still working on Win32 MSVC PIR code for pbc_to_exe. GCC code from last week fixed Rakudo-on-Feather. Tuit harvest is good; will try Win32 again today.
18:41 Util .eor
18:41 chromatic Whiteknight?
18:41 Whiteknight IO SYSTEM
18:41 Whiteknight * Started the io_rewiring branch to do some major refactoring in the IO system
18:41 Whiteknight * Working to remove costly PCCINVOKE calls from IO API functions
18:41 Whiteknight * Worked with Infinoid++ and NotFound++ to better integrate various types of IO PMCs
18:41 Whiteknight * Would love feedback, but not ready yet for mass testing or benchmarking. Hoping to be ready this week.
18:41 Whiteknight MISC
18:41 Whiteknight * Picked up a grant for an unrelated project, will have less time for Parrot this month. :(
18:42 Whiteknight EOR
18:42 chromatic Did I miss anyone?
18:42 darbelo me
18:42 chromatic Go ahead.
18:42 darbelo .report decnum-dynpmcs :GSoC
18:42 darbelo * Added more VTABLES to DecNum.
18:42 darbelo * Now feature-equivalent to BigNum, sort of.
18:42 darbelo * Starting to convert the decNumber tests to pir.
18:42 darbelo .end
18:42 chromatic Anyone else?
18:43 chromatic Questions?
18:44 pmichaud (checking trac reports to see if I have questions)
18:44 jonathan setstdin op - why? OK, perhaps consistency with setstdout etc but aren't the methods on ParrotInterpreter enough/better for this?
18:44 * darbelo goes afk
18:44 NotFound jonathan: that was answered last week
18:44 chromatic I agree with jonathan.
18:45 jonathan OK, then I'm disagreeing with last week's answer. :-)
18:45 pmichaud do we have any ideas about TT #717 yet?   (parrot_config segfaults when invoked with the --dump option)
18:46 NotFound pmichaud: the idea is simple: the implementation sucks.
18:46 Util pmichaud: yes, it is in the ticket's history update (paired with the patch)
18:46 PacoLinux joined #parrotsketch
18:46 pmichaud Is someone going to review/apply it?  It's not owned at the moment.
18:46 NotFound Using a string structure instead of a pointer to one is The Bad Thing (TM)
18:47 chromatic That sounds like an easy fix.
18:47 Util r39223 (NotFound's patch) stops the bug from appearing during Rakudo's use of `parrot_config --dump` in --gen-parrot.
18:48 NotFound pmichaud: I was waiting to see if the IO reworking goes fast. I can make a fix easily, but note that it can impact output speed.
18:48 pmichaud NotFound: output speed is already terribly slow.
18:48 pmichaud NotFound: I should add that as a ticket if it doesn't exist already, and put it on the report.
18:48 Whiteknight the io_rewiring branch is, hopefully, making IO much faster
18:49 Whiteknight it's a major conceptual change though, so it might not be correct. Pending feedback
18:51 chromatic Other questions?
18:51 chromatic I know that bacek had some conceptual questions about destination PMCs.
18:52 NotFound Talking about setstdin and family... The stdhandle method in ParrotInterpreter is documented experimental.
18:52 NotFound Is time to delete that line?
18:52 pmichaud I think bacek's questions arise from the vtable code still containing remnants from when    add $P2, $P0, $P1  re-used the PMC in $P2 instead of creating a new one.
18:53 pmichaud I could be wrong about that, though.
18:53 allison NotFound: depends on whether it's been well-tested
18:54 NotFound There are tests, but I don't know if is being used in realistic situations.
18:56 allison NotFound: then best to do some "real world" testing before considering it stable
18:56 NotFound Ok
18:57 NotFound I think bacek question is about yesterday discussion about possible deprecation of the *dest parameter in several vtable functions, yes.
18:58 pmichaud I think the determining whether the behavior of something like 'add' should be governed by the intent of the opcode or by the design of the underlying PMC
18:59 pmichaud *determining factor is
18:59 pmichaud if we think that   add $P2, $P0, $P1   should always construct a new PMC with the sum of $P0 and $P1, then the dest parameter is a little superfluous
19:00 pmichaud if we think that there may be some PMCs where we'd like to re-use an existing destination PMC in an 'add' opcode, then the dest parameter remains part of the API but is unused by the standard Parrot MCs
19:00 NotFound And error prone.
19:00 pmichaud *PMCs
19:00 allison The core PMCs don't use the added destination parameter anymore
19:01 chromatic This is because we don't have well-defined reference or value semantics.
19:01 pmichaud Correct.  The question as it stands now is whether that destination parameter should remain in the VTABLE interface or be discarded.
19:01 allison but, that's different than removing the ability to allow any PMC ever to reuse a PMC header for the destination
19:01 particle it's my understanding that pmcs are containers, aka references
19:02 pmichaud particle:  I think PMC registers are references; I'm not so sure about the PMCs themselves.
19:02 allison chromatic: no, it's because we do have well-defined semantics (now) and they involve not morphing PMC destinations
19:02 chromatic I'm not sure about autoboxed primitives.
19:02 particle yeah, it's the autoboxing/proxy pmcs that are under question here
19:03 pmichaud I don't think that's the question either, at least not for bacek's work
19:03 allison autoboxing primitives is irrelevant for destination PMCs
19:04 allison If you say add $I0, $P1, $P2, it's a syntax error, not an autobox
19:04 particle sure, that opcode doesn't exist
19:04 pmichaud anyway, my vote is to keep the existing vtable interface as it is, to preserve the possibility of some PMC types to re-use destination PMCs
19:04 japhb joined #parrotsketch
19:04 allison mine as well
19:05 pmichaud NotFound: I suggest that in the core PMCs we change that last parameter from *dest to *unused  to make it clear that it's not being used.
19:05 NotFound The problem I see is that pasing an unused destination from the ops, and allowing non-core PMC to use it opens a door for obscure and difficult to catch bugs.
19:06 allison NotFound: the ops have to pass the destination parameter, so that PMCs that want to use it can
19:06 pmichaud NotFound: I would prefer to keep the functionality (and recommend against it) than to close it off permanently/altogether.
19:06 allison I wouldn't even recommend against it
19:06 allison A language that has the semantics of morphing the destination can use it
19:06 pmichaud okay, then, recommend against mixing those PMCs with the core PMCs :-)
19:07 allison A language that creates a new destination, doesn't use it
19:07 particle like, say, an int promoting to a bigint
19:07 NotFound In that case, better that language use his own opcode, IMO
19:07 particle colud morph the destination
19:08 allison they can mix too, it's just that the vtables that do morphing have to pay attention to core types
19:08 * allison reareading comment stream to see if missed anything...
19:09 allison I'm okay with calling those "unused" in the core PMCs, but keep them as "dest" in default, so people have an indication of what it's meant for
19:10 pmichaud +1
19:10 NotFound +1
19:10 chromatic I'm less convinced.
19:10 chromatic I don't care for the conceptual weight of keeping around an unused feature we think some language somewhere might use, which the core committers can't get right reliably.
19:11 chromatic If there were a stronger use case -- if someone could show me an example where this feature really makes an implementation easier or more reliable -- I'd feel more comfortable.
19:11 NotFound My +1 is for the renaming of the parameter, not against the deprecation proposal.
19:12 allison it makes something possible that would otherwise be impossible
19:12 allison Parrot isn't about dictating semantics
19:12 allison it's about providing tools to implement a variety of languages
19:12 NotFound I think that this is the possibility of breaking the expectations of a lot of reusable code.
19:13 chromatic Sure, but I'm asking if that feature is 1) useful 2) not obscure 3) possible to implement sanely and correctly 4) worth the baggage of maintenance given 1-3
19:13 allison Unless someone is checking to make sure the pointer of the result is different than the one that was previously stored in the register, they won't even notice
19:13 NotFound If the core PMC doesn't use it, people will assume that it must never will be used, without carefully reading the docs.
19:14 allison think about adding large matrix structures
19:14 allison do you really want to require that they always return a new PMC?
19:14 NotFound Yes
19:14 chromatic I thought that's why we had i_add
19:14 allison expensive
19:14 pmichaud (NotFound:  fwiw, at one time we did have separate opcodes for the two behaviors, but Parrot ended up standardizing on one.)
19:15 allison aye, we standardized because "add" was the strange one
19:15 allison so we took back the unmarked names for the "normal" behavior, and removed the variants
19:17 chromatic Okay, so the justification is "Let's keep a confusing feature we don't use (and couldn't get right when we did use it), because a language might want to use it in the future, and an operation in that language might be slow without it."
19:17 NotFound allison: I think that PMC used for large matrix will be rarely passed to functions no specific for him.
19:17 allison I don't see what's confusing about having access to the return result within the operation
19:18 allison I could imagine Perl using it to check the context of the assignment
19:18 pmichaud Oooh.
19:18 allison you have all three registers in the op anyway
19:18 allison we're just passing all three registers along to the vtable function
19:18 allison instead of cutting off one
19:19 pmichaud we're allowing the (dest) PMC to act as an INOUT instead of just OUT
19:19 allison yes
19:20 NotFound The confusing point is: you cannot write a = b + c without first nulling a if you want to be sure that some unknown pmc does not the expected thing.
19:21 pmichaud NotFound: *if* you're using something other than the core PMCs
19:21 pmichaud NotFound: it's not an issue for the core pmcs
19:21 allison If some unknown PMC does something you didn't expect, it's because you didn't read the documentation for the unknown PMC
19:21 NotFound pmichaud: If I write a reusable function I don't know what type of pmc someone can pass to it.
19:22 pmichaud NotFound: then the unknown PMC needs to know how to handle that case as well.
19:22 pmichaud NotFound: I do understand your point, however.
19:22 NotFound pmichaud: yes, but I don't expect that all writers and users of that type functions will be enough careful.
19:22 allison NotFound: for the most part, it really doesn't matter what PMC header the result has
19:23 pmichaud and you're correct, it can mean that code compiled in one HLL would not be able to effectively use the PMCs from another.
19:23 chromatic ... which subverts one of the points of PMCs and vtables.
19:23 NotFound allison: that is the problem: in the rare cases, people will break is heads trying to catch the bug.
19:24 NotFound s/is/his
19:24 allison we're going down the road of "we shouldn't give people powerful features because we might misuse them"
19:24 allison which really isn't the Parrot philosophy
19:24 pmichaud however, Parrot philosophy is to try to avoid things that would tend to make HLLs incompatible.
19:24 chromatic How about "We shouldn't give people features that are difficult to get right without a very good reason for them."
19:24 allison it's pretty simple for a language that uses this kind of semantics to make sure it only uses them for its own types
19:25 NotFound But the question is if the power from that source is enough to justify the cost.
19:25 allison there's not much cost to passing along a single extra pointer
19:25 chromatic If your language doesn't support dest semantics, you need to null $Px every potential inout PMC.
19:25 chromatic For *every* three-arg op.
19:25 allison chromatic: huh?
19:25 chromatic At least for code you intend to be somewhat generic.
19:26 pmichaud allison:  if my code does
19:26 pmichaud add $P2, $P0, $P1
19:26 pmichaud assuming that $P2 will always get a new PMC
19:26 NotFound allison: The cost is to verify that all functions that potentially have that problem nullify the destionation before using affected opcodes.
19:26 pmichaud but then I end up running my code where $P0 has a vtable that assumes re-use of the dest PMC
19:26 pmichaud then we're likely to end up with a failure/incompatibility.
19:27 pmichaud i.e., if $P0 is a foreign PMC that has the "reuse dest" semantics.
19:27 pmichaud so the only way my local HLL can guard against that is to null $P2 prior to each call to 'add'
19:27 pmichaud to indicate to the foreign VTABLE_add that "I really expect a new PMC here."
19:27 NotFound And we can be sure that lots of people will make that assumption without even knowing they do.
19:27 allison you could go that far, yes
19:28 allison but of course, anyone who's writing vtable functions could also modify all the source parameters too
19:28 allison it's only a convention that they don't
19:28 chromatic It's a strong convention that we don't encourage with the nature of our interfaces.
19:29 NotFound allison: we have RO for that, but you can't make the destination RO
19:29 allison so it's also a convention that if your assignment semantics involve modifying the destination, you only do it for your types
19:29 allison NotFound: sure you can. Marking a PMC as RO applies in any context
19:30 NotFound allison: making a destination RO is effectively making it a non-destination
19:30 allison but again, it'd be kind of overkill to mark all your PMCs as RO just before passing them into an op, just to make absolutely sure no one modifies it
19:30 NotFound allison: no, but you can use it for testing and bug hunting
19:31 allison this is running kind of long for a parrotsketch
19:31 allison I suggest moving it off to #parrot or the mailing list
19:31 NotFound +1
19:33 allison were there other questions?
19:34 chromatic That was the only one I remember and thought to bring up here.
19:34 allison Roadmap review? https://trac.parrot.org/parrot/report/14
19:35 allison The only critical task is HLL export conventions
19:35 allison what's the progress on that one?
19:35 pmichaud Good progress being made all around, there.
19:35 allison excellent
19:35 pmichaud I updated Rakudo's import/export functionality a bit, and both Tene++ and I are steadily moving towards something workable.
19:36 pmichaud anyway, I don't see any major blockers or impediments to having something in place for 1.3
19:36 allison good
19:36 allison any objections to moving packfile pmcs, vtable swap and pirc to 1.5?
19:37 pmichaud no objection here.
19:37 allison (don't want them landing just before 1.4, even if they did happen to be ready)
19:37 chromatic Why not vtable swap?
19:38 chromatic Except for the fact that there's one conceptual question about it.
19:38 chromatic ... and I haven't made progress on it.
19:38 allison it's a fairly fundamental change, so will need some time to shake down
19:38 allison better to merge it right after a supported release than just before
19:39 allison (that is, if it's done by then)
19:39 chromatic It's not as big a change as you think, but it does affect some of the grottiest PMCs, so I can see the point.
19:40 pmichaud gotta run here -- bbiaw
19:40 allison that's pretty much it for this week
19:42 allison any other questions/comments before we go?
19:43 allison alright, that's a wrap, thanks everybody!
19:43 Util left #parrotsketch
19:44 chromatic left #parrotsketch
19:47 particle left #parrotsketch
19:53 jonathan left #parrotsketch
19:53 darbelo left #parrotsketch
20:06 PacoLinux left #parrotsketch
20:12 pmichaud left #parrotsketch
20:51 eternaleye joined #parrotsketch
21:07 NotFound left #parrotsketch
21:10 mberends left #parrotsketch
21:50 Whiteknight joined #parrotsketch

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary