00:17 contingencyplan joined 09:20 moritz joined 12:52 Whiteknight joined 13:37 rdice joined 13:40 tewk joined 14:35 davidfetter joined 16:52 particle joined 17:14 cognominal joined 17:21 Auzon joined 17:22 DietCoke joined 17:37 Whiteknight joined 17:49 NotFound joined 18:06 jhorwitz joined 18:09 allison joined 18:14 cotto_work joined 18:23 smash joined 18:27 barney joined, pmichaud joined 18:29 chromatic joined, wknight8111 joined
DietCoke Hello, everyone. 18:30
jhorwitz waves
pmichaud Hello!
allison hi
smash greetings
davidfetter ahlan wa sahlan
18:30 jonathan joined
moritz waves hi 18:30
Tene Last #ps was on June 10? 18:31
barney waves ho
DietCoke there was no PS last week due to yapc::na
pmichaud yes, last #ps was June 10.
DietCoke speaking of yapc...
It was nice meeting a lot of you this past week (some of you for the
first time!). We've had a lot of movement behind the scenes for parrot
in that time, which I suspect others will cover in their reports.
let's go allison, particle, jhorwitz, chromatic, pmichaud and then I'll figure it out after that. 18:32
allison - The hackathon was very productive, and it was great to spend time talking with Parrot hackers. 18:33
- I added 2 new opcodes for patrick (on the pdd25 branch) that allow rapid branchs/returns within a subroutine. Currently named 'pbj' and 'pbr', but probably going to change to 'local_branch' and 'local_branch_return' (or something equally lengthy and descriptive).
- The rest of my time has been spent on debugging the pdd25 branch. The number of failing tests keeps dropping, but still a few to go. 18:34
EOR
particle had a few commits over yapc, nothing to brag about
face-to-face meetings at yapc were very productive 18:35
mainly doing parrot foundation setup work, expect that to continue
won't have much time for parrot development work until my job situation settles down (no eta)
.end
jhorwitz YAPC talks went well. Had lots of positive feedback. 18:36
Not surprisingly, the concept of mod_lolcode generated a lot of excitement, so I worked on it and it's now bundled with mod_parrot. Will have live demos for OSCON.
Focus now is on expanding mod_parrot's access to apache data structures to pave the way for other volunteers to work on higher level stuff like mod_perl6.
EOR
chromatic Applied a lot of patches and closed some bugs.
Spending some time in IMCC -- made a couple of optimizations and plugged some memory leaks.
I'm not sure it's worth anyone's time doing more fixes in IMCC; it's just wrongly designed in a lot of ways that'll take a lot of energy to tease apart. 18:37
I'd really like to help with pdd25cx, but it's not clear what to do or where to start, and I hate to see it slip another release.
Still working with wknight8111 on the new GC; it's getting close.
EOR 18:38
pmichaud ** Rakudo spectest_regression: 66 files, 849 passing tests (+7, +144 from 06-10)
== Overall
: Very productive YAPC::NA, glad to see so many of you there
== Parrot stuff
: Fixed get_parrotclass method of P6object to avoid MMD
: Recognize CCLASS_NEWLINE and CCLASS_ANY for unicode strings on systems w/o ICU
: Spent a lot of time tracking down lexical and :outer issues
== PCT stuff
: Updated HLL compiler to automatically transcode source to a fixed-width representation when possible (for faster parsing)
== PGE stuff
: Added .chars method to Match objects
== NQP stuff
18:38 cjfields_ joined
pmichaud : No changes to NQP -- it just works 18:38
== Rakudo stuff
: Lots of test updates
: Updated Range class
: Added implementation for Complex 18:39
: Added an implementation of ternary ?? !!
: Many grammar refactors to more closely align with STD.pm
: Fixed named 0-ary parsing
: Removed some obsolete rules from grammar
: Rakudo now parses utf8 characters in source (transcoding to iso-8859-1 for speed when possible)
: Created docs/spectest-progress.csv to keep track of spectest progress
: tools/test_summary.pl now also summarizes the reasons for skipped tests
Queue two items for discussion.
EOR.
Tene balances a book on DietCoke's head. 18:40
Tene goes now.
* Missed YAPC::NA because I needed to find a new place to live 18:41
* Cardinal parses more competently and about 80% faster
* Cardinal hashes can now do some rubyish magic with default values
* Start of a smalltalk implementation, under the name ChitChat
* Modified the evalbot from #perl6 to support --target={parse,past,pir} and uploading to pastebin for parrot languages
* polyglotbot is running in #parrot and supports (kind of) abc APL bf cardinal chitchat lolcode lua perl6 pheme plumhead punie pynia squaak tcl
* I don't think it's actually rebuilding the parrot tree, and it needs a couple of minor fixups I'm unlikely to get around to. It's running on feather3.
* Started working on implementing gather/take, but I'm apparently blocking on pdd25cx, I think
* KTHXBAI
allison queues questions for tene and chromatic
barney kicks in
Migrated Plumhead from TGE to NQP.
.eor 18:42
tewk goes now.
DietCoke I have a $DAYJOB issue; I tag allison.
tewk NCI GSoC
* Split CPP(pre-processing) out of c99.
* Using gcc to pre-proccess c code right now.
* moved c99 to compilers/ncigen
* Added alot of gnu extension support to c99 parsing.
* Figuring out PCT so I can generate PIR signatures
EOR
allison DietCoke: okay
Whiteknight I'll go then, since it's a free-for-all 18:43
* I updated docs/memory_internals.pod to be less wrong.
* Worked on some other docs, and function-level documentation
* Did a little IMCC work, and got .macro_const working in *.PIR files
* The new GC is "code complete" and compiles, but doesnt work properly yet
EOR
jonathan goes
* On last week's Rakudo day...
** Did some refactoring and STD.pm tracking
** Got the does operator for roles in place
** Support for anonymous enum constructor
** Variety of type variable stuff - we can now write generic subs/methods
* Parrot core
** Maybe got :instanceof sorta working
* Meta
** Need some brain cycles to finish working out how to implement type-parameterized roles; I'm part of the way there, but have been too sick to think about anything hard for the last few days :-|
** Doubt I'll do that on the next Rakudo day (which will hopefully be on Thursday); will maybe look at getting the Method / Sub etc stuff in place, and maybe signature objects too, since they're likely useful for MMD.
EOR
allison have we missed anyone? 18:44
okay, questions, pmichaud had 2
pmichaud from my post to the mailing list: Any thoughts about short-term fixes for :outer() handling? (RT#56274) 18:45
also related to the discussion: I now know why RT#56184 is a problem and we may need some substantial re-thinking somewhere.
(although fixing RT#56274 may obviate the need to worry about #56184 for a while.) 18:46
allison on RT#56274, is this as an alternative to md5 hashed sub names?
pmichaud no. they are totally unrelated.
(we could potentially make use of this as an alternative to md5 hashed subnames, but 56274 is really a separate and more problematic issue) 18:47
for those who didn't read my mailing list post: :outer(...) doesn't give sufficient resolution.
allison but the solution is essentially to have some unique name or id for every sub 18:48
whether we tack on the the namespace, or generate a unique id
pmichaud if I have .sub 'foo' :outer('bar') and there are multiple .sub 'bar' in the compilation unit, then 'foo' always attaches to the first 'bar'.
allison by compilation unit, do you mean file?
pmichaud yes.
(although it could be a string with PIR code.) 18:49
allison and, you have multiple subs because you have, say methods and regular subs with the same sub name?
pmichaud yes. or subs that are :multi
Tene or multiple namespaces.
pmichaud and that's what really makes this different from the md5 issue -- where I needed a way to locate otherwise anonymous subs. 18:50
in this case I _have_ to use the supplied name, or do lots of name mangling.
allison multiple namespaces is fixable by using full sub names, but the method/sub/multi problem is more complex
the first quick fix didn't work out, is there another short-term solution we could use? 18:51
Whiteknight couldn't we do name-decoration for multis, like we do for similarly-named ops?
allison yes, name decoration for type of sub could work (not ideal in the long-term)
pmichaud at the moment it's the sub-in-separate-namespaces that is causing the most difficulty.
allison how about a simple user-defined id token 18:52
pmichaud that's what I proposed in my mailing list message, yes.
Whiteknight .sub MySub :theycallme('Ishmael'), like that?
allison so, you set the token on the sub, and then refer to it :outer.
pmichaud yes. I proposed :lexid or somesuch
allison yup, that works for me, especially since the problem is local to a file 18:53
make it so
jhorwitz mod_parrot assumes that sub names in PIR are the same as in the HLL. as long as that assumption is still valid, then +1.
allison yeah, it wouldn't affect the sub name
chromatic I like :lexid
jhorwitz seconds
Tene and :outer could fall back to sub name if it can't find a given lexid
pmichaud actually, any sub that doesn't provide :lexid uses its name as the lexid 18:54
allison it would only affect the way the sub is treated for looking up :outer
pmichaud the patch I tried would always look for the most recent version of a sub, as opposed to the first.
That "worked", except that it only worked for .pir files and not .pbc
allison yeah, you can't count on compilation order 18:55
pmichaud (I don't know enough about bytecode formatting to know what is needef ro .pbc)
er, *needed for .pbc)
allison :lexid is preferable
particle anonymous subs can have a lexid, yes?
pmichaud yes, please.
chromatic Sure, why not?
particle and, by default, what's the lexid of an anonymous sub?
allison yes, so it solves an earlier problem we had of how to have :outer subs referring to an anoymous sub
pmichaud default lexid of anonymous sub could be PMCNULL (i.e., doesn't have one) 18:56
allison particle: it has none by default
pmichaud just like it doesn't have a name.
particle but for named subs, lexid is the name of the sub
pmichaud for named subs lexid defaults to name of sub
particle asks leading questions to get to the heart of the matter
allison right, and anonymous subs have no name, so thaey have no lexid
particle it's a bit confusing, since anon subs do have a name in the source file 18:57
allison you have to specify a lexid for an anonymous sub if you want to define an outer block for it
particle but that's just syntax
and it's specced
pmichaud if anon sub has a name in the source file, then that's its lexid
there's no real conflict there.
allison particle: they do, but only because parrot requires some name
particle you don't want anon subs to have a lexid by default. period. 18:58
pmichaud why not?
particle even if they have a name in the pir
allison if they have a name in pir, the :lexid can default to it, might as well since it's there
particle .sub 'foo' :anon ; ... ; .sub 'foo' ; ...
pmichaud any sub that expects to be an outer should provide a :lexid 18:59
in the case you just gave, .sub 'foo' should provide a :lexid
failing to provide a :lexid is asking for trouble. :-)
allison but if the name is something like .sub '' :anon (which may not even be valid at the moment, but should be) then it has no :lexid
pmichaud and one could conceivably do .sub 'foo' :anon :lexid('')
particle .sub 'foo' without :anon has a default lexid of 'foo'
.sub 'foo' :anon must specify a lexid or it has none 19:00
allison particle: yes, and so does .sub 'foo' :anon
pmichaud particle: why require .sub 'foo' :anon to specify a lexid?
allison we'll keep it consistent for sanity
pmichaud there's no conflict if it has one.
particle there's no conflict if two subs have the same lexid? 19:01
pmichaud yes, there's a conflict if two subs have the same lexid.
but
any sub that expects to be an :outer should provide a unique lexid.
regardless of being :anon or not.
the "default lexid" is simply to keep existing code working.
particle so, how do we check for unique lexids?
what about evaled subs?
pmichaud we don't have to check for unique lexids -- that's the responsibility of whatever is generating the code.
evaled subs are no different. 19:02
Whiteknight a lexid hash would associate a single function with a single lexid
pmichaud keep in mind that they only need to be unique within compilation unit, at least with the current implementation of lexicals.
(since :outer doesn't cross comp unit boundaries) 19:03
DietCoke returns.
tewk So you can't eval a sub that has a pre-existing :outer
pmichaud tewk: in the current implementation, that's correct. 19:04
even so, I'm not worried about being able to generate unique lexids.
particle if my code generator creates an anon sub with the same name as a named sub, neither of which specify :lexid, there's a collision
pmichaud if your code generator is generating subs w/o :lexid, it's broken.
allison which there already is now, :lexid just gives us a way to resolve the collision when there is one 19:05
particle ok, so the default is just for humans with silly little code, and code generators will always specify :lexid
pmichaud particle: yes.
particle that works for me.
allison yeah
particle just needs to be documented as such
pmichaud code generators don't have to specify :lexid if they know that a block doesn't have any lexically nested subs.
but it's easier to just always generate one. 19:06
DietCoke Do we have a volunteer to implement this schemne?
pmichaud that was my next comment -- Rakudo is blocked on a lot of tests due ot this.
chromatic If someone writes up what needs to happen, I'm happy to poke at this.
pmichaud essentially we're unable to handle lexically nested subs
chromatic I've already gone negative on my SAN stat due to recent IMCC work.
pmichaud I think jonathan also indicated he might work on it. 19:07
DietCoke pmichaud: can you summarize on the ticket the new :lexid() and its interaction with :outer, then c or j can claim it as a todo.
pmichaud will do immediately following this meeting.
DietCoke I'd even be willing to write up a doc patch if someone else writes up the code. =-)
19:07 cognominal joined
pmichaud my next question is much simpler: Any thoughts on ETA to merging the pdd25cx branch into trunk? 19:08
allison the last 6 failing tests are nasty
some of them I may just todo, if I can demonstrate that all the languages are working even with those tests failing 19:09
the biggest thing right now is a few PGE failing tests, and TCL failing to compile
pmichaud I couldn't figure out the PGE failing tests.
chromatic If you wrote up some information on them, I (and I can guess that NotFound too) would be happy to look at them.
DietCoke I suspect those are related.
pmichaud but I didn't look on it much past the hackathon, so I can look again.
DietCoke I'll take a look and see if I can narrow down what is causing tcl to fail to build. 19:10
allison chromatic: okay, though I don't have much more to say than what's immediately obvious from running the failing tests
pmichaud when I last looked at the hackathon, the failures I was getting were pretty opaque. But I need to look again. 19:11
allison chromatic: I'll be in Seattle Wednesday night, if you want to do some interactive debugging
DietCoke Let's track any blockers on this ticket: rt.perl.org/rt3/Ticket/Display.html?id=54930
allison Portland, I mean
That was my queued question for chromatic 19:13
The one for tene was what he needed from the pdd25cx branch
pmichaud allison: resumable exceptions
Tene pmichaud++ 19:14
allison ah, okay, yes, that should work after the merge
pmichaud we want resumable exceptions for gather/take
allison (resumable at a PIR opcode, not resumable at a random C instruction) 19:15
Tene How should I be getting the continuation to invoke from the exception?
allison Tene, it's passed in when you call 'throw'
jonathan (implementing lexid) if it's not done by my Rakudo day on Thursday, I can look at it then
Tene How should I get it in the exception handler? 19:16
pmichaud does pdd25 not say? or is pdd25 out of date?
Tene Not that I could find. I'm checking again. 19:17
pmichaud sorry, pdd23 is exceptions.
Tene: "handled" opcode 19:19
exception handlers receive a continuation as a parameter, which they can then invoke.
19:20 blah joined
Tene ""Active exception handlers (if any) will be invoked with EXCEPTION as the only parameter. 19:20
pmichaud aha, pdd23 is internally inconsistent.
allison yes, the return continuation is stored in the exception
pmichaud so, how do we get the continuation from the exception?
allison sorry, interrupted 19:22
I'll set up a test case as an example
pmichaud that would be awesome.
DietCoke allison: tcl builds in pdd25cx. interactive version seems to work. 'make test' hangs on the first test. 19:24
allison DietCoke: okay, thanks 19:25
pmichaud I'll look at pge issues tonight.
any other outstanding questions or discussion points?
or did we get them all?
I'd also like to welcome moritz++ as a new committer. 19:26
moritz thanks pmichaud ;)
wknight8111 moritz++
DietCoke allison: I have a backtrace for you.
looks like a loop of handler invocations. 19:28
nopaste.snit.ch/13383 :: I just stopped cutting and pasting at #100 19:29
allison okay, I've seen that elsewhere 19:30
generally when a different exception is thrown in the middle of handling another exception
DietCoke I do that a bit as I often want to translate an exception from parrot-speak to tcl-speak. 19:31
I'm not sure when "in the middle" occurs, though: once I call get_results, aren't I done handling?
allison catch an exception and throw it differently?
DietCoke there's no op to say "my handler is over."
s/it/or a new one/
I can probably track down where in PIR this is happening. 19:32
allison it's any time before the handler is popped
oh, I bet you're using scoped handlers
pmichaud doesn't a handler get popped upon catching an exception...?
allison handlers are persistent, like event handlers 19:33
pmichaud is this strictly for the "push_eh $P0" sort of handler, or also "push_eh label" ? 19:34
DietCoke ... er, how does that work?
pmichaud because if I try to pop_eh after a push_eh label, I get an error.
DietCoke I often do push_eh/pop_eh with labels.
seems to go off the rails in *** switching to BYTECODE_src/PCT/HLLCompiler.pir
allison under the old implementation, yes
DietCoke # Back in sub 'parrot;PCT::HLLCompiler;init', env 823068c
it invokes that several hundred times before, I think, running out of memory and failing an assertion. 19:35
pmichaud HLLCompiler? in tcl?
Tene I get 8 errors in 'make test' in pdd25cx
DietCoke I'm as surprised as you are. =-)
allison I can keep the old functionality for backward compatibility
DietCoke if there's a new/better way to do this, I can update code in the branch, that's nt a problem.
particle points to #parrot 19:36
seems like the meeting's over, no?
DietCoke I agree.
Tene Oh, no allison there. 19:37
19:37 cognominal joined
Tene allison: can you tell me which of the failures in here you're not also seeing: nopaste.snit.ch/13384 ? 19:38
allison tene: I'm seeing all of those
Tene Hm. I thought you said 6. 19:39
Nevermind.
19:40 cotto_work left
allison sorry, 6 root causes (I divided up the failing tests by symptoms) 19:41
Tene ahh, clever. 19:42
pmichaud (presuming that the pge failures are due to the other ones. :-) 19:44
allison I have to go, DietCoke, I'll think of an alternative for you. With resumable exceptions we can't just delete handlers once they've been called once, because we may resume in a loop, and throw the same exception on the next iteration after the loop 19:45
DietCoke Ok. if I have to add something to clear the _eh from inside my handler, I can do that. I wonder if that's the cause of some of the other issues you're seeing. 19:46
~~ 19:47
allison yes, it likely is the cause of one, now that I think about it
Tene doesn't rethrow do that, or does rethrow only work on the same exception object?
allison clearing the handler from inside the handler would work
pmichaud I don't have a problem with clearing the handler (pop_eh?) inside the handler -- it was really what I expected to be doing. But that didn't seem to work in current Parrot.
allison tene: rethrow isn't the same as throwing a different exception expecting the same handler 19:48
19:48 cjfields_ left
DietCoke pmichaud: yah, that doesn't work in trunk. 19:48
it was pre-cleared.
allison pmichaud: it doesn't work in current parrot, because current parrot does delete the handler as soon as it retrieves it
(one of many reasons exceptions weren't resumable before)
pmichaud right, no problem.
just need to know what to switch to :-) 19:49
DietCoke Want us to start adding in the pop_eh's in the branch?
(It's not just tcl using that style.)
allison DietCoke: see if it fixes the failing test, and if so, add it
pmichaud pge and pct have quite a few push_eh's that don't have pop_eh's
(at least, don't have them when the exception is caught)
allison if it doesn't fix the failing test, then it's not needed
DietCoke well, I'm going to have to add it in a LOT of places to verify that it worked. =-) 19:50
allison pmichaud: that could very well explain the failing PGE tests
DietCoke let's give it a shot, we can always rollback.
allison DietCoke: just the ones relevant to that first failing test should do the trick 19:51
DietCoke that will still take some time, but ok. =-)
pmichaud I'll have to do mine a bit later -- have other tasks on my stack that need to be addressed first.
(but should get to it tonight/tomorrow morning)
DietCoke I'll plan on putting them in right after any .get_results in the label.
allison okay, I have a shorter way to test this...
DietCoke (auto delete the handler!) 19:52
allison committing a fix that deletes the handler when it's first invoked
hold on
(we can always change it later when we need it for more complex resumable exceptions
try r28685 19:53
and, I really have to go now, I have a meeting in 3 hours, in a town that's 3.5 hours drive from where I am now 19:54
DietCoke gogogo
moritz get a helicopter ;)
allison email me the results of testing :)
19:54 allison left 19:59 jhorwitz left 20:00 chromatic left 20:08 Auzon left 20:17 NotFound left 21:24 jonathan left 23:36 japhb 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!