New proposed #parrotsketch protocol: trac.parrot.org/parrot/wiki/Propos...chProtocol | Please prepost reports by 1800 UTC. | Logs: tinyurl.com/parrotsketch
Set by moderator on 30 June 2009.
00:46 japhb joined 07:53 rin1024 joined 07:57 mikehh joined 08:17 Gerd joined 08:27 Gerd left 12:04 Whiteknight joined 14:33 pmichaud joined 14:59 rin1024__ joined 16:00 NotFound joined
pmichaud Report for 2009-07-14: 16:58
What I did:
* Rakudo now passing 11,784 spectests (+199 since last week)
* Worked on diagnosing and providing -G bug updates for rakudo
* Rakudo is no longer experiencing -G bugs
* MANY THANKS to all who helped with this, including bacek++, chromatic++, Infinoid++, NotFound++, Whiteknight++
* Corrected handling of dynext in load library path
* Fixed a bug in the tracing runcore
* Worked on a patch to eliminate use of string comparisons for 'isa' testing 16:59
** Provides an 11% speed improvement for rakudo spectests
** Mostly works -- will send to mailing list for review and comment
* Added <?> and <!> to Perl6Regex syntax
* Removed deprecated methods and regexes from PGE
* Published instructions for building Rakudo releases
* Invited people to become Rakudo release managers
* Cleaned up rakudo code for some -G bug handling
* Lots of long-term planning and brainstorming
What I didn't do that I said I would do
* I didn't work on build refactor for Parrot (to look like install tree)
* I've decided I'm not really the person to be leading this
* I did send my plan to the mailing list
* Hopefully someone else can/will pick up the ball
What I'm doing this week:
* Finishing HLL interop docs and tasks
* A few PCT and NQP improvements
* Various improvements to Rakudo (Vienna.pm Rakudo Day)
* Working on Hague grant
** redesign of operator precedence parser
* Updating presentations for OSCON and YAPC::EU
What I'm blocking on:
* Insufficient waking hours
EOR
17:06 mikehh joined
NotFound What I did: 17:07
* Closed some old RT tickets.
* Cleaned some 'might be clobbered' warnings seeen with --optimize.
* Miscellaneous cage cleaning and fixing.
* Talked a lot on irc ;)
What I'm doing:
* Looking at exception handling and related problems.
EOR
17:08 darbelo joined
Whiteknight # What I Did Last Week 17:09
- Created a new "Infinite Memory" GC core as a template that new GC hackers can follow and learn from
* (Thanks for suggestion from Coke++ and Austin++)
* Used the new core to find problems with GC core encapsulation (TT #828)
- Tracked down the root cause of the abort-before-exit error that is plaguing Rakudo
* (Thanks for help from Allison++, chromatic++, and pmichaud++ on that!)
* Suggested a potential fix and waiting for feedback (TT #833)
- Fixed error where "exit 1" didn't change Parrot's exit value
- Wrote some assorted function-level documentation
- Built LLVM and Clang, and updated PLATFORMS with information.
# What I'm Doing This Week
- Hopefully (finally) getting io_cleanups locked down and merged (Infinoid++ for his help!)
- Taking lessons learned from the context_pmc branch and writing up a task list for continuing that work 17:10
- Testing for the release
- Doing some deprecation stuff that can be merged post-release.
# What I'm Blocking On
- Tuits
darbelo Report for this week is on the blog: www.parrot.org/content/week-decnum-dynpmcs. 17:35
cotto # What I did: 17:58
* more opsc work, basically understanding what ops2c does and where various functionality should go in opsc
* lots of syncing with bacek++
* also started work on runcore-independent post-past ops processing
# What I hope to do and how many tuits I expect to have:
* nothing external
18:02 chromatic joined
chromatic Working on pluggable, encapsulated runcores. 18:03
Will continue to work on them this week.
Won't enable them by default by 1.4, but may add a compile-time flag to enable pluggability.
Will work on weird bugs for the release as necessary, prioritizing those instead of runcores.
18:07 Util joined
Util # Done: 18:09
* Worked heavily on #691 (installed pbc_to_exe can't find config.fpmc.)
- After being Coke and cautioned me against an `is_installed` approach, I got it working via `cc_inc` changes in the fpmc build.
- Allison's new code (r39993, r39995, r40038, r40039), uses the `is_installed` approach as a short-term fix.
- Even though the issue is resolved, my code will move us toward the longer-term install strategy, so I am re-working my code to fit with Allison's.
( My fault for not checking the SVN updates. ++Allison )
- Candidate patch by tomorrow.
* Closed #717 (parrot_config segfaults when invoked with the --dump option);
- Plan to open related ticket to fix or deprecate Parrot_io_write.
* Reviewed Parrot_io_write, Parrot_io_puts, and print_warning for deprecability. Still in progress.
* Reviewed S02 and related tests for clarity. Still in progress.
# Plan for next week:
* Finish #691
* Kill off Parrot_io_write
* P5toP6 tinkertoy progress
# Blockers: 18:10
* Marathon of Harry Potter movies 1..5 running at local cinemaplex.
* Even so, medium Tuit harvest expected.
.end
18:16 allison joined
Tene Last week: last week: wrapped a gui lib in Parrot, got some basic windows displayed, working on OO interface for it 18:19
this week: More gui, blog post, curses
blocking: I have some work pending on OO for pynie, but that requires :vtable('invoke'), which is blocking on pcc refactor
Which I heard was scheduled to come in shortly after 1.4
allison - Ticket queue work, especially install-related tickets, preparing for release. 18:27
- Fixed pbc_to_exe so it works from an installed parrot. Tested on Pynie and Tcl.
- Plan to build Debian and Ubuntu packages this week to make sure we have no issues for 1.4.
EOR
18:27 moritz joined
cotto hi 18:31
Util hi
moritz hello birdmonks
darbelo hola
Whiteknight hello
allison hi
we've lost our handy channel topic with the link to the new procedure 18:32
cotto q1q
allison has everyone preposted their reports?
Whiteknight yes
NotFound hola
moritz allison: no, I can see it; maybe an irc server messup
allison moritz: could be 18:33
Util in irssi, it is cut off at 'prepost repor'
cmd /topic to see all
moritz anyway, the link is trac.parrot.org/parrot/wiki/Propos...chProtocol
allison and the log of reports is irclog.perlgeek.de/parrotsketch/2009-07-14 18:34
let's start with questions, then roadmap review 18:35
cotto
cotto I'm drafting a message to parrot-dev about the release. Is Saturday a good cut-off point for any disruptive changes? 18:36
(at which point we can focus on testing HLLs, platforms, etc)
Whiteknight it's good for me
allison yes, for a packaged release that's a good amount of time
cotto eoq then
allison other questions? 18:37
NotFound I have a few
Whiteknight I have one too
NotFound TT #826 Deprecate Parrot_str_free?
chromatic Reluctantly yes, with the caveat that it is *not* the problem with Rakudo. 18:38
allison NotFound: go ahead and put in a deprecation notice, that still leaves us free to keep it if someone needs it 18:40
NotFound Ok.
allison Next q from NotFound? 18:41
NotFound Second question: What to do with exceptions thrown from :load or :init blocks? Let them propagate out of imcc, or catch them an abort compiling/loading?
allison let them propagate
NotFound s/an/and
Whiteknight this is along the same lines as my question
allison I mean, if nothing catches them, they'll end execution anyway 18:42
Whiteknight (not exactly the same)
NotFound allison: the problem is when someone catches then.
Whiteknight it's the inferior runloops problem 18:43
Check out TT #833 for a good example and analysis of it
NotFound Forgettting the runloop issues for a now, it lets the module semi-loaded and will be rare that the caller knows how to repair it.
Whiteknight problem stems from an exception in a child runloop being handled by code that had been running in a parent runloop
allison we don't want a scenario where it's impossible to cleanly handle any exception thrown by an embedded parrot 18:44
allison looking at ticket
Whiteknight There are a few good ways I think we can resolve this issue once and for all, but we need to pick the best from the available options
NotFound allison: I tested a way to handle the issue: returnning an error code from the fixup routines, checking it in the compiler calls, and throw an exception here where appropiate. 18:45
Whiteknight a dual-stage exception would work in that case, yes 18:46
but that requires the scheduler to know which runloop a handler is associated with, and to "rethrow" the exception if it's not currently in that runloop
allison I like the "continuing in the same runloop" idea, but it doesn't work for general cases of we're calling a chunk of PIR code from within a chunk of C code
Whiteknight you're right, it doesn't 18:47
so are we looking at disallowing cross-runloop exception propagation, or dual-stage exception throwing?
allison what we need is better context cleanup with exception handlers
chromatic Disallowing cross-runloop propagation seems sensible and necessary. 18:48
allison chromatic: except that it leaves us with a crippled exception system
Whiteknight There is a difference between PIR called from C inline, and PIR called from C that can be appended into the current runloop however
allison minimizing the number of runloops is certainly a plus 18:49
Whiteknight We could disallow exception propagation for the strict inline cases only
pmichaud I don't understand "disallowing cross-runloop exception propagation"
NotFound I think we just need to disallow resume.
pmichaud if the PIR that I'm compiling throws an exception, my eval() function (in PIR) needs to be able to catch it.
allison Whiteknight: yes, the cases that could be scheduled instead of immediately executed are essentially tail calls
Whiteknight pmichaud: in the case we saw where there were two runloops on the stack, an exception thrown from the "child" runloop can't be handled by a handler registered with the "parent" runloop 18:50
allison Whiteknight: the C could couldn
pmichaud Whiteknight: I think that's not workable.
allison 't depend on the return value
Whiteknight allison: exactly my thinking, we could use the same tailcall mechanisms
pmichaud: I think it can be in limited situations
chromatic We're getting a long way from priorities and scheduling into implementation here.
allison pmichaud: it's not
Whiteknight okay, can we continue this discussion in #parrot?
allison chromatic: good point, we can keep talking about this on #parrot 18:51
pmichaud fine with me
NotFound Fine
Whiteknight okay. That satisfies my question too
moritz has a question on behalf of bacek 18:52
chromatic Go ahead.
moritz any objections to merging tt761_keys_revamp branch into trunk?
pmichaud before the release?
moritz I mean before the release, and if there's no black smoke
allison moritz: is it needed before the release?
moritz allison: I'm not entirely sure, but I don't think it's too urgent 18:53
allison moritz: let's do it right after, then
18:53 mikehh joined
chromatic It improves a lot of grotty code, on the plus side. 18:53
allison moritz: make sure you have in deprecation notices for any API changes 18:54
moritz allison: I'll pass that on to bacek++
cotto I'd like to see it in 1.4 for that reason, but it's not urgent
pmichaud as long as rakudo builds and passes all spectests, I have no strong objection.
chromatic I'd rather support clean code than the mess we have now.
pmichaud I'll give the branch a try with rakudo and see what I get.
18:55 webnov8 joined
allison we're still getting reports on parrot-dev of failing tests on various platforms 18:55
18:55 webnov8 left
allison avoiding the "rush to fix at the last minute before the release" is definitely good 18:56
moritz afaict they are all the same tests; bacek thinks they rely on hash order where they shouldn't (I haven't checked that)
pmichaud queue 1 item from me
moritz doesn't mind either way, just wanted to bring up the topic
chromatic pmichaud? 18:57
pmichaud I'll be putting this in an email to parrot-dev, but I again want to express my appreciation to everyone who helped excise the -G errors from Parrot for Rakudo 18:58
I had some doubts as to whether it would be done in time for the 1.4 release, but you all came through in fantastic fashion
so, thanks.
(and yes, I'm not seeing any more -G related errors for the past several days now)
endofitem 18:59
allison NotFound: did we finish all your questions?
and IIRC, Whiteknight had one
(then I'll hand off the rest to chromatic) 19:00
Whiteknight my question was answered
chromatic Alright, let's do milestone review. 19:01
#1 install -- I've seen some pbc_to_exe patches. What's the status and what needs to happen there?
NotFound allison: yes
allison pbc_to_exe now works, tested with pynie and tcl
needs testing with other languages
Util My pbc_to_exe upcoming patches are refactorings, and not critical to actual install. 19:02
chromatic What else is necessary to make a language work from an installed Parrot? Dynops? Dynpmcs?
pmichaud after I do the hll stuff on my plate, I'll give pbc_to_exe a try. 19:03
or I can reverse the priority of those two items -- you can choose. 19:04
allison chromatic: I think we resolved those issues for partcl
chromatic Anything else for installation?
pmichaud have we been able to test partcl with any of the platforms identified as problems with the rakudo ins branch? 19:05
allison pmichaud: what were the platforms?
pmichaud I don't remember off the top of my head -- they're in RT and in the message I sent, though.
basically it was issues in passing the appropriate link options on those systems
because parrot's defaults didn't work there
allison pmichaud: will look them up 19:06
pmichaud (I'm finding them now.)
chromatic Oh right, you can't have a space in one of the options on Windows, I think.
pmichaud and you *have* to have a space on some other platform.
allison chromatic: the install process refactor (making the build tree look more like the install directories) will wait until after 1.4 19:07
pmichaud RT #66558, #66560, #66574 19:08
chromatic Are we on track to meet the spirit of the goal anyway?
allison thanks, patrick
pmichaud #66560 is likely a Rakudo problem and not a Parrot one 19:09
allison chromatic: I'd say so. Will try to knock down as many install tickets as possible before Saturday
pmichaud #66574 may be also -- just related to Rakudo's "different" approach to trying to build the dynpmcs 19:10
chromatic #2 -- HLL interoperability.
pmichaud but 66558 is definitely an issue
I think we're well enough along on HLL stuff that we can consider ourselves to be in good shape for this (more) 19:11
I'm expecting to tighten up some of the specs and clean a few things up, but we at least have enough HLL interop taking place now that we can claim to be supporting HLL interop with only a few hiccups 19:12
I'll make sure any existing open tickets are addressed by Friday morning.
chromatic #3 -- I asked jhorwitz about this, and he's making progress. I'm not sure it'll land by the release however. 19:13
That's the external API.
He wanted to have a draft by last weekend.
allison #3 is a spec target, rather than an implementation target?
if so, the critical bit is deciding if we need any deprecation notices in 1.4
chromatic Right. 19:14
pmichaud my feeling was that we originally intended #3 to be an implementation target.
I'm fine if it's a spec target, but people are already asking about external API stuff.
NotFound We have some documentation and examples that works. 19:15
allison pmichaud: aye, and it's already possible to embedd/extend parrot, but people need clear guidance (i.e. documentation) on what is and isn't part of the API
pmichaud I thought part of the milestone was also reviewing PARROT_EXTERN and PARROT_API markers. 19:17
chromatic It was.
NotFound Time to resurrect PARROT_API?
allison yes, we switched to PARROT_EXPORT to make it clear that that flag was just meant to provide what various platforms need
chromatic I mailed jhorwitz about the deprecation notices.
pmichaud right, but we were also intending to have PARROT_API markers 19:18
allison with plans to add PARROT_API once we defined which functions were part of it
yes
NotFound And will be good to have some test that verifies that all PARROT_API marked functions are documented as external api, and viceversa. 19:19
allison the deprecation notice there would be relevant to embedders, basically "in the future, any function not marked with PARROT_API isn't intended for use in embedding or extensions"
chromatic Right. 19:20
pmichaud works for me.
allison sounds good, and thanks chromatic for contacting jhorwitz
pmichaud can I pass a long a list of functions that Rakudo is currently relying on as candidates for PARROT_API ? 19:21
*along
allison yes, very helpful
chromatic Do we need to add any more priorities? 19:23
allison we're good for 1.4
for 2.0, do we want to break down the list by month? 19:24
or, keep it as a 6 month priority list? 19:25
chromatic Avast! Monthly.
allison okay, we can break that down next week 19:26
chromatic Any other questions?
Tene 1 19:27
allison: is pcc refactor still scheduled to land shortly?
allison after 1.4, yes 19:28
Tene Thanks.
I'm done.
chromatic Okay, thank you all. 19:29
19:29 moritz left, Util left 19:31 chromatic left, NotFound left, pmichaud left 19:33 PacoLinux left 19:34 eternaleye joined 19:52 darbelo left 20:52 ascent joined 21:28 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!