Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 24 May 2009.
01:41 japhb joined 10:56 masak joined 12:06 Whiteknight joined 13:18 payload joined 14:30 masak joined 14:51 payload joined 15:06 PacoLinux joined 15:07 PacoLinux left 16:05 pmichaud joined 16:21 particle joined 16:52 NotFound joined 17:20 Util joined 18:11 mberends joined 18:23 darbelo joined 18:25 jhorwitz joined 18:27 jonathan joined 18:28 allison joined
Whiteknight hello 18:30
jonathan hi
darbelo hola
18:31 chromatic joined
allison hi 18:31
chromatic $localtime
cotto hi (no report this week)
chromatic Let's begin. allison? 18:32
NotFound hola
Util hi
jhorwitz hi 18:33
allison - Almost through editing the final chapter of the PIR book.
pmichaud hello.
allison It'll be up in 2 seconds on pub.lohutok.net/onyxneon/
- Will be traveling most of the next week. 18:34
EOR
chromatic chromatic?
Thanks for asking! I fixed several memory leaks. IMCC has a few more nasty ones that hit Rakudo hard.
I have a couple of bugs to fix today.
I'm writing a grant to develop a new profiling core for Parrot, as HLLs need it badly. 18:35
That should be available at least at the .sub level for 1.4.
jhorwitz?
jhorwitz no report -- just started working on slides for YAPC.
chromatic jonathan? 18:36
jonathan Parrot
* 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.
* Tracked down the cause of a segfault I'd got in Rakudo and filed a ticket.
Rakudo
* Finished up the dispatch refactor at long last
* Now method dispatch in Rakudo is just done using the PIR method calling syntax
* Was quite a good performance win, and an interop win
* 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
* 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
* Re-worked caching in Perl6MultiSub - now method dispatch is faster and we create caches lazily to decrease startup cost
* Other bits...
Scheduling:
* Going to be away for the second half of June and a just over a week in July taking vacation.
* Will be attending YAPC::EU and YAPC::Asia
.end
chromatic moritz? 18:37
Tene more HLL interop work. KTHXBAI
jonathan (I believe moritz is away on vacation.)
chromatic NotFound?
NotFound * Added setstdin opcode 18:38
* Miscellaneous fixes and cleaning
EOR
chromatic particle?
jonathan q1q
chromatic PerlJam?
pmichaud? 18:40
pmichaud General:
* Rakudo now passing 11,346 spectests (+3 since last week)
* Tracked down the issue behind TT #24 (non-equivalents of hash keys)
* Added a fix, which bacek++ improved
* Updated PCT::HLLCompiler transcode option to allow multiple attempts
* Rakudo and other langs can now optionally transcode to iso-8859-1 for parsing, significantly faster than utf-8.
* With help from NotFound++ and Infinoid++, significantly improved PMCProxy creation in class lookups
* 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.
Other Rakudo stuff:
* Fixed symbol importation for settings
* Fixed IO.get, moved from PIR to setting
* Worked out BEGIN implementation details (not committed yet)
* Fixed various quoting construct errors, die with useful message on s///
* Corrected cross-metaop handling
* Updated postfix:<++> to be 75% faster
* Refactored .succ/.pred handling overall
EOR
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`
NotFound++ has workarounds for both, reducing the problems to the point that I cannot (yet) recreate them. I plan to test further.
* 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.
* 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.
.eor
chromatic Whiteknight?
Whiteknight IO SYSTEM
* Started the io_rewiring branch to do some major refactoring in the IO system
* Working to remove costly PCCINVOKE calls from IO API functions
* Worked with Infinoid++ and NotFound++ to better integrate various types of IO PMCs
* Would love feedback, but not ready yet for mass testing or benchmarking. Hoping to be ready this week.
MISC
* Picked up a grant for an unrelated project, will have less time for Parrot this month. :(
EOR 18:42
chromatic Did I miss anyone?
darbelo me
chromatic Go ahead.
darbelo .report decnum-dynpmcs :GSoC
* Added more VTABLES to DecNum.
* Now feature-equivalent to BigNum, sort of.
* Starting to convert the decNumber tests to pir.
.end
chromatic Anyone else?
Questions? 18:43
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?
darbelo goes afk
NotFound jonathan: that was answered last week
chromatic I agree with jonathan.
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)
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
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)
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.
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.
NotFound: I should add that as a ticket if it doesn't exist already, and put it on the report.
Whiteknight the io_rewiring branch is, hopefully, making IO much faster
it's a major conceptual change though, so it might not be correct. Pending feedback 18:49
chromatic Other questions? 18:51
I know that bacek had some conceptual questions about destination PMCs.
NotFound Talking about setstdin and family... The stdhandle method in ParrotInterpreter is documented experimental. 18:52
Is time to delete that line?
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.
I could be wrong about that, though. 18:53
allison NotFound: depends on whether it's been well-tested
NotFound There are tests, but I don't know if is being used in realistic situations. 18:54
allison NotFound: then best to do some "real world" testing before considering it stable 18:56
NotFound Ok
I think bacek question is about yesterday discussion about possible deprecation of the *dest parameter in several vtable functions, yes. 18:57
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:58
*determining factor is 18:59
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
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.
pmichaud *PMCs
allison The core PMCs don't use the added destination parameter anymore
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.
allison but, that's different than removing the ability to allow any PMC ever to reuse a PMC header for the destination
particle it's my understanding that pmcs are containers, aka references
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
chromatic I'm not sure about autoboxed primitives.
particle yeah, it's the autoboxing/proxy pmcs that are under question here
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
If you say add $I0, $P1, $P2, it's a syntax error, not an autobox 19:04
particle sure, that opcode doesn't exist
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
allison mine as well 19:04
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.
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.
allison I wouldn't even recommend against it
A language that has the semantics of morphing the destination can use it
pmichaud okay, then, recommend against mixing those PMCs with the core PMCs :-)
allison A language that creates a new destination, doesn't use it 19:07
particle like, say, an int promoting to a bigint
NotFound In that case, better that language use his own opcode, IMO
particle colud morph the destination
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...
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:09
pmichaud +1 19:10
NotFound +1
chromatic I'm less convinced.
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.
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.
allison it makes something possible that would otherwise be impossible 19:12
Parrot isn't about dictating semantics
it's about providing tools to implement a variety of languages
NotFound I think that this is the possibility of breaking the expectations of a lot of reusable code.
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
NotFound If the core PMC doesn't use it, people will assume that it must never will be used, without carefully reading the docs.
allison think about adding large matrix structures 19:14
do you really want to require that they always return a new PMC?
NotFound Yes
chromatic I thought that's why we had i_add
allison expensive
pmichaud (NotFound: fwiw, at one time we did have separate opcodes for the two behaviors, but Parrot ended up standardizing on one.)
allison aye, we standardized because "add" was the strange one 19:15
so we took back the unmarked names for the "normal" behavior, and removed the variants
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.
allison I don't see what's confusing about having access to the return result within the operation
I could imagine Perl using it to check the context of the assignment 19:18
pmichaud Oooh.
allison you have all three registers in the op anyway
we're just passing all three registers along to the vtable function
instead of cutting off one
pmichaud we're allowing the (dest) PMC to act as an INOUT instead of just OUT 19:19
allison yes
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:20
pmichaud NotFound: *if* you're using something other than the core PMCs 19:21
NotFound: it's not an issue for the core pmcs
allison If some unknown PMC does something you didn't expect, it's because you didn't read the documentation for the unknown PMC
NotFound pmichaud: If I write a reusable function I don't know what type of pmc someone can pass to it.
pmichaud NotFound: then the unknown PMC needs to know how to handle that case as well. 19:22
NotFound: I do understand your point, however.
NotFound pmichaud: yes, but I don't expect that all writers and users of that type functions will be enough careful.
allison NotFound: for the most part, it really doesn't matter what PMC header the result has
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.
NotFound allison: that is the problem: in the rare cases, people will break is heads trying to catch the bug.
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"
which really isn't the Parrot philosophy
pmichaud however, Parrot philosophy is to try to avoid things that would tend to make HLLs incompatible.
chromatic How about "We shouldn't give people features that are difficult to get right without a very good reason for them."
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
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
chromatic If your language doesn't support dest semantics, you need to null $Px every potential inout PMC.
For *every* three-arg op.
allison chromatic: huh?
chromatic At least for code you intend to be somewhat generic.
pmichaud allison: if my code does 19:26
add $P2, $P0, $P1
assuming that $P2 will always get a new PMC
NotFound allison: The cost is to verify that all functions that potentially have that problem nullify the destionation before using affected opcodes.
pmichaud but then I end up running my code where $P0 has a vtable that assumes re-use of the dest PMC
then we're likely to end up with a failure/incompatibility.
i.e., if $P0 is a foreign PMC that has the "reuse dest" semantics. 19:27
so the only way my local HLL can guard against that is to null $P2 prior to each call to 'add'
to indicate to the foreign VTABLE_add that "I really expect a new PMC here."
NotFound And we can be sure that lots of people will make that assumption without even knowing they do.
allison you could go that far, yes
but of course, anyone who's writing vtable functions could also modify all the source parameters too 19:28
it's only a convention that they don't
chromatic It's a strong convention that we don't encourage with the nature of our interfaces.
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
NotFound: sure you can. Marking a PMC as RO applies in any context
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
NotFound allison: no, but you can use it for testing and bug hunting
allison this is running kind of long for a parrotsketch 19:31
I suggest moving it off to #parrot or the mailing list
NotFound +1
allison were there other questions? 19:33
chromatic That was the only one I remember and thought to bring up here. 19:34
allison Roadmap review? trac.parrot.org/parrot/report/14
The only critical task is HLL export conventions 19:35
what's the progress on that one?
pmichaud Good progress being made all around, there.
allison excellent
pmichaud I updated Rakudo's import/export functionality a bit, and both Tene++ and I are steadily moving towards something workable.
anyway, I don't see any major blockers or impediments to having something in place for 1.3 19:36
allison good
any objections to moving packfile pmcs, vtable swap and pirc to 1.5?
pmichaud no objection here. 19:37
allison (don't want them landing just before 1.4, even if they did happen to be ready)
chromatic Why not vtable swap?
Except for the fact that there's one conceptual question about it. 19:38
... and I haven't made progress on it.
allison it's a fairly fundamental change, so will need some time to shake down
better to merge it right after a supported release than just before
(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.
pmichaud gotta run here -- bbiaw 19:40
allison that's pretty much it for this week
any other questions/comments before we go? 19:42
alright, that's a wrap, thanks everybody! 19:43
19:43 Util left 19:44 chromatic left 19:47 particle left 19:53 jonathan left, darbelo left 20:06 PacoLinux left 20:12 pmichaud left 20:51 eternaleye joined 21:07 NotFound left 21:10 mberends left 21:50 Whiteknight joined

Powered by Cro and the Raku® Programming Language.

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

Thank you!