Vision for 2.0: Production Users | Priority for 1.6: Merge Branches | Priority for this week: Fix partcl segfaults & PANICs, increase test coverage on Namespace and Array PMCs, prune a struct | trac.parrot.org/parrot/wiki/Propos...chProtocol | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 18 September 2009.
00:02 Whiteknight joined 05:52 kurahaupo joined 07:14 cotto_w0rk joined 11:34 Whiteknight joined 14:18 Util joined 15:58 NotFound joined 16:52 fperrad joined 17:03 smash joined 17:10 darbelo joined
cotto_work # What I did: 17:17
* profiled pprof2cg (tuit were short this week)
# What I hope to do and how many tuits I expect to have:
* same as last week, hopefully with more tuits
# What could block my progress:
* rl
.eor
fperrad # What I did last weeks : 17:24
* Lua : rewrite my Test Suite in pure Lua
as an independent project, see testmore.luaforge.net/
(include a Lua port of Test::More)
* load_language : converts WMLScript, Markdown & Lua
# What I must to do
* prepare a talk about Parrot for act.osdc.fr/osdc2009fr/
.eor
darbelo #did: 17:39
* Removed PIC.
* Moved the JIT call frame builder into it's own file.
* Gave the frame builder it's own configure probe.
* Obliterated the rest of the JIT.
* Removed the JIT-dependent exec core.
#will try to:
* Go back to the strstart removing.
* More pmc_freeze.c cleanups
#Might block on:
* Tuit shortage.
.eor
NotFound What I did: 17:43
* Applied some patches.
* Miscellaneous fixes.
* Diagnosed problem in MySql module.
What I will do:
* Fix problems that intereferes with MySql module, improve it.
Q2Q
.eor
mikehh What I did in the last week: 17:50
* building and full testing parrot on amd64 and i386
* fixing codetest/manifest_tests failures
* testing language builds on latest parrot, mainly rakudo and partcl
* worked on make cover - added more coverage and
* got cover-clean to remove all files generated by make cover
* except cover_db directory which is removed by make realclean
What I intend to do next week:
* continue testing
* get fulltest to run all tests
.eor
dukelet0 'ello 17:59
What I did: 18:02
* Working on blog post about the Parrot Shell
* Benchmarking Euler problems on Parrot across released version
* Working on the Blizkost test suite
* Applying patches
Plan:
* More of the same
Blocking on:
* Too damn nice outside in PDX.
.eor
s/version/versions/
18:05 darbelo left 18:09 darbelo joined 18:20 chromatic joined
chromatic I worked on optimizations and bug fixes. 18:21
I helped remove the JIT.
This coming week, I hope to remove more deprecated features and work on other optimizations.
I also hope to document some of the slang primitives to help us figure out Lorito primitives. 18:22
18:25 allison joined
Util # Done 18:27
* TT#994 - Set up local git-svn clone for auto-prop experiment; experiment still in progress.
* TT#389 - Poked at pbc.c, trying to keep subs with :method out of the namespace. It poked back, hard. Traced to namespace.pmc add_to_class().
* Attended Atlanta LinuxFest. 500+ attendees.
= Python had a *booth*, with full-color banner, staff answering questions, code and websites being demoed...
@ Grrrr. Atlanta.pm would have staffed a Perl booth, if we had only known.
= OTOH, a Webhosting booth gave away copies of 2009-09 LinuxProMagazine (issue 106), containing the "Birdsong" Parrot article. (Can't find it online, though)
# Plan for next week:
* Make SVN properties do-the-right-thing for `git-svn` users (TT#994). Should finish in the week, either in success or failure.
* Brain-dump last weeks research into TT#389. Continue poking; medium chance of success.
# Blockers:
* None; more tuits available this week.
.end
mikehh I make it time 18:30
chromatic Hello.
darbelo Hola.
mikehh Hi there
chromatic Let's review last week's goals.
How did we do removing the old JIT?
mikehh most of it gone 18:31
fperrad hello
cotto_work hio
NotFound hola
darbelo The part that still there is the onw we want to keep.
I'd call it 'succesful' 18:32
chromatic How much refactoring is left of what remains?
mikehh me too
Util hi 18:33
chromatic How about improving the test coverage of Exception?
18:35 kj joined
mikehh make cover reports 85.9% on exception.c 18:35
NotFound I've done a bit just a few moments ago
18:36 allison joined
mikehh 95.4% on exceptionhandler.c 18:36
chromatic Can you make a list of what we need to get to 100% on the wiki? 18:37
mikehh I'll give it a go
chromatic How about MultiSub? Did anyone work on that? 18:38
18:38 jrtayloriv joined
Util multisub.{c,pmc} had no change in coverage numbers from r40951 to r41406. 18:39
chromatic Let's keep it on the list for next week then. 18:40
How did we do on branch merges?
mikehh good
cotto_work thanks to bacek and his git-svn magic
mikehh especially kill branches
darbelo gc-refactor merged, kill_pic branched and merged, kill_jit branched_and merged
NotFound kill++
darbelo all dead now. 18:41
chromatic Do we have upcoming branches to merge?
jrtayloriv (sorry I'm late -- howdy)
allison (looks like my connection dropped off before my report made it into the channel, can fill in later) 18:42
darbelo no branch other than pcc has commits in the last month. Merges look unlikely. 18:43
chromatic Anything else to review from last week, tech-wise?
Util RT#53302 says that the `nsentry` branch might be removed after a `diff` of it is added to TT#389. 18:44
cotto_work q1q
chromatic Okay.
NotFound q2q
chromatic Let's put MultiSub on the testing queue for this week. 18:45
Let's review milestones. Can someone who's not at a conference go through this list? trac.parrot.org/parrot/report/14
I have done a bit of work on pruning C data structures; will mail the list later.
allison_ is vtable swap going to be worked on this month? 18:46
i.e. should we reschedule or drop the task? 18:47
(it may end up being irrelevant, if lorito goes as planned)
chromatic It's become less of a priority, thanks to other changes. 18:48
allison_ bump after 2.0? or drop from roadmap tasks? 18:49
chromatic Let's defer it until 2.1.
allison_ 2.2 it is
mikehh TT #566, #567, #568 are all hll_interop stuff (pmichaud)
NotFound Looks like almost no one knows what needs to be done.
dukelet0 looks at milestones
allison_ actually, 2.6, since we haven't broken out the post-2.0 milestones yet 18:50
dukelet0 i will add enough docs to the parrot_debugger to close before 1.7
allison_ the hll_interop task needs a revisit
as in "what's been done, what needs to be done, what's blocking?" 18:51
Util TT#600 (bytecode testing framework) needs more detail before I would tackle it.
allison_ Util: would you feel comfortable putting together a first draft of what you think might need to be done, so the group can expand/discuss?
Util Doh!
mikehh the testr option compiles to bytecode and then tests it 18:52
allison_ The basic task is just "make it possible to test a bytecode file"
Util I will make a first draft.
allison_ Util: thanks! 18:53
Util ...if you tell me what you are testing for - loadability? canonical structure?
mikehh rakudo also compiles to .pbc as well
allison_ Util: more general than that
Util OK
allison_ Util: we should be able to run any test we currently run in PIR from a bytecode file instead
(that's the only way to be sure the bytecode is working) 18:54
Util Aha! got it!
NotFound We are not. The problem of not storing the encoding of constant strings is still unresolved. 18:55
allison_ on seed libraries, how's the Aviary, Plumage stuff coming?
should we reschedule/rename this task to fit that work?
fperrad TT #1052 is needed
allison_ fperrad: for the testing task? 18:56
darbelo japhb was working on bootstraping some aviary stuff.
18:57 pmichaud joined
fperrad allison_, yes, TT #1052 is : Add --target=pbc to HLLCompiler 18:58
mikehh assigned to pmichaud
allison_ fperrad: aye, took a look, it's not an absolute requirement for bytecode testing (since it could always be done in a separate step), but nice to have 18:59
NotFound allison_: Can we host some modules at svn.parrot.org ? We were talking yesterday about MySql module leaving hist nest i examples.
pmichaud right, I can't imagine that TT #1052 would be a requirement
clearly we can produce .pbc without having --target=pbc 19:00
allison_ NotFound: we could... though it might be better to follow the approach we've taken with languages
fperrad sorry, I think as HLL implementor
allison_ NotFound: where each group of modules keeps it's own repository 19:01
NotFound: (in the source control tool of their choice)
NotFound allison_: When/if it gets mature enough and more people work on it, sure.
allison_ NotFound: we can create another svn repo easily enough on svn.parrot.org. Will it be used by enough modules to be worth it? 19:03
(input from others on channel?)
NotFound allison_: main points are: be easy for me to work on it, and have a url that plumage can use. 19:04
19:04 Coke joined
Coke goes whoops. 19:04
pmichaud I would just do modules in github, sourceforge, etc.
allison_ NotFound: plumage can use any URL, it's a distributed module index
dukelet0 github++
pmichaud pick the one you're most productive with
NotFound Being easy for me excludes git. 19:05
darbelo NotFound: google code has svn and is pretty easy to set up.
pmichaud yes, googlecode is also good. that's what partcl is using
and pynie
NotFound Ok, I'll give it a try.
allison_ questions, NotFound you had 2 queued, was that one? 19:06
NotFound allison_: TT #1057, subsystem prefix for list.c functions.
allison_ looking 19:07
NotFound Also MySql related, BTW
chromatic I prefer Parrot_list as a prefix; it's only one character longer and it's much clearer. 19:08
allison_ NotFound: lists aren't a specific enough subsystem
chromatic ... but I'm not sure we *need* those functions in general.
allison_ so, Parrot_pmc
NotFound The api page says 2 or 3 letters 19:09
chromatic: they are used.
allison_ (or, more accurately, lists aren't a subsystem)
chromatic I know we use them now, but I think they're only used in a few places and largely vestigial. 19:10
NotFound allison_: Parrot_pmc_list_... ?
allison_ NotFound: that would work, or Parrot_pmc_array
NotFound chromatic: maybe, but I need to rename it, is blocking MySql work.
allison_ NotFound: go ahead, it falls under the general deprecation item 19:11
darbelo Rename them now and open ticket for their obliteration?
mikehh kill++ 19:12
allison_ darbelo: yes, or at least a ticket to check and see if they can die
pmichaud if rakudo uses them (unlikely), I'm okay with them renaming. 19:13
NotFound I think is only use by the Array pmc and imcc
allison_ NotFound: there's a good chance they should be refactored into Array's code, then 19:14
mikehh BTW Coke++ for closing RT tickets and getting others to
allison_ NotFound: for now, rename, enter a ticket to explore what to do next 19:15
pmichaud Yes, Coke++
NotFound Ok
pmichaud +1
NotFound Next question: the exception thrown by the exit opcode is resumable?
Tene NotFound: anything thrown by throw_from_op is resumable, but throw_from_c or whatever isn't. 19:16
so, probably yes
NotFound Actually is, but I doubt any code that uses it expects to be resumed.
Coke I can see wanting an on-exit handler.
(which might be a non-sequitor.)
Tene Coke: that would invoke some other code, but wouldn't resume.
NotFound The real question is: can we get rid of the continuation created in it? 19:17
Tene NotFound: why?
allison_ NotFound: the spec lists it as "handleable", but doesn't mark "resumable"
NotFound Tene: to avoid debugging strange failures caused by a resume.
pmichaud (on-exit handler) In general, we want to have an "on-exit" possibility for all subs, not just main
dukelet0 pmichaud: like "after" in Moose ? 19:18
pmichaud dukelet0: perhaps. In Perl 6 it's "leave"
Tene NotFound: If someone is trying to resume an exit exception, I don't see any reason to disallow it. It's just an exception like any other.
pmichaud dukelet0: I think that "after" in Moose is more of a wrapper than an on-exit handler
NotFound Tene: if we allow it to be resumed, every time you use exit you must add code to handle the possible resume. 19:20
pmichaud NotFound: that's not much different than any other "throw" situation.
NotFound pmichaud: then kill the opcode and use throw 19:21
Tene Do we also need to always check that a sub that we're invoking still exists, just because there's the possibility that someone has deleted it?
pmichaud ....deleted it? 19:22
how does one "delete" a referenced sub?
Tene I'm pretty sure that I remember doing that... remove it from the namespace.
pmichaud if anything has a pointer to the sub, it should still exist.
allison_ NotFound: are you asking whether we should add functionality to exit? or remove existing functionality? 19:23
dukelet0 pmichaud: namespace elements can be deleted
pmichaud that would include any contexts, outer lexical references, etc.
Tene It was just an example of doing something stupid an dbroken.
pmichaud dukelet0: deleting a namespace element doesn't delete the sub.
at least, it shouldn't delete the sub
NotFound allison_: I see it at removing existing unfunctionality.
s/at/as
dukelet0 pmichaud: we should have a test for that
Tene and resuming an exit exception would fall into that category.
pmichaud: there are plenty of places in PCT and rakudo where functions are fetched from namespaces. That's all I was thinking of. 19:24
NotFound Tene: no, faliling to find a sunb throws an exception, resuming an exit can give a segmentation fault.
pmichaud assuming that an exit exception has a resume entry (a Continuation), that continuation would reference the sub, and the sub would therefor be marked as live and not be gc'ed
Tene Please ignore my chosen example. It wasn't a good idea. :)
pmichaud i.e., the Sub PMC would exist simply because there's a Continuation/Exception that continues to reference it 19:25
NotFound Is valid code to have an exit at the end of a bytecode segment, and in fact we have examples and tests like that.
pmichaud but going a bit further (more) 19:26
it wouldn't bother me if "exit" throws an unresumable exception. If someone needs a resumable exception, we have "throw" for that.
NotFound pmichaud: that's my point, if for some you want a resumable exit you can throw an exit exception 19:27
But the current, and what most people will expect for the exit opcode, is to not needing to care for resume.
pmichaud but that's true for many 'throw' usages as well 19:28
i.e., many people assume a thrown exception won't resume.
(not a counter-argument, just pointing out that throw and exit aren't any different in this respect)
allison_ I'm okay with non-resumable exit 19:29
I'm about to have to leave for lunch
pmichaud otoh, it seems to me that exit could use the same logic as throw
cotto_work allison_, could you look over GitObjections on the wiki in the near future and make sure all your objections are present? 19:30
NotFound pmichaud: Given that few languages have resumable exceptions, yes, most people don't expect. But that's only a documentation and examples problem.
Tene pmichaud: it currently does
allison_ did cotto have a question before we go?
cotto_work that was it
allison_ cotto: yes, I'll look over it
pmichaud Tene: then why is there an issue with exit and not with throw?
cotto_work thank
eoq
s/k/ks/ 19:31
NotFound It currently does, the point is to change the current behaviour and docuemnt it.
allison_ pmichaud: I mainly see it as a question of "why have exit if it does the same thing as throw?"
but, I don't have a strong opinion here
pmichaud allison_: that's reasonable to me also
allison_ NotFound: it would be subject to a deprecation cycle
pmichaud what are we changing about the current behavior, then, if it's already the same as throw?
NotFound The point of using exit is shortness. The need to be ready for resume is against that.
pmichaud you're trying to make it *not* the same as throw? what's the purpose of that? 19:32
allison_ so, you can deprecate it and see if anyone complains between now and then
Tene NotFound: remove lines 890,893,894 from src/ops/core.ops
allison_ have to run, thanks everybody!
Coke allison_: ~~
Tene pmichaud: his point is that 'exit' has different expectations from 'throw', and that resuming from an exception thrown by 'exit' is unlikely to be correct in any situation. 19:33
I don't know how much I agree with it.
NotFound Tene: and hard to debug if it happens.
Tene NotFound: identical debugging situation to any other resumed exception.
as well, IMO, if you're resuming from an exit exception, you had better know what you're doing. There are well-documented ways to prevent your handler from catching exit exceptions. 19:34
I don't see how 'exit' is a special case here. 19:35
pmichaud I have to go as well. It feels odd to treat 'exit' as a special case, although I see the point.
Tene IMO, it's the same as 'print' vs 'say'
pmichaud bbl
NotFound Tene: Is a different opcode, that's spècial enough for me.
Coke btw, there is a ticket somewhere where allison has proposed removing say. =-) 19:36
Tene 'say' used to be a different opcode, iirc.
Coke say used to be PIR magic. then it was an opcode.
(and before that, it was just print, no newlines)
Tene and before that, you didn't even have 'print', you just had to call a method on STDOUT? 19:37
;)
japhb appears for long enough to say:
Don't kill say.
My life as a PIR debugger would just be more painful with only print.
Coke (oh, I'm not planning on it.)
Tene There are quite a few opcodes that could be replaced by method calls, iirc.
japhb Two lines of code every time I wanted to print the value of a register.
Tene NotFound: It looks like allison has OK'd it, as long as it goes through a deprecation cycle, and nobody else will complain too loudly if you want to do it. 19:39
NotFound But you are complaining ;)
Tene NotFound: Please make a ticket and attach the patch I proposed, and list the date after which it can be applied.
NotFound Tene: ok
Tene and list it in the deprecated whatever place.
NotFound EOQ
mikehh anyone got anything else to say or is that a wrap-up 19:41
Tene Sounds like we're done.
dukelet0 The dishes are done, man. 19:43
19:44 Util left 19:45 darbelo left 19:46 NotFound left, fperrad left 20:04 chromatic joined 20:11 chromatic left 20:45 jrtayloriv left 20:49 cotto_work joined 22:09 allison_ joined
allison_ Pasting report dropped by poor network access earlier: 22:09
- Gave a talk at the JVM Languages Summit.
- Tested Parrot on Mac OS 10.6, filed some tickets (warnings and possible future development).
- Ran some simple benchmarks on the pcc branch, show the speed is about equal to current trunk.
- Talked with chromatic about project roles and responsibilities, a "Dev Coach" role.

Powered by Cro and the Raku® Programming Language.

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

Thank you!