Parrotsketch Every Tuesday @ 18:30 UTC | IRC Log at irclog.perlgeek.de/parrotsketch/today
Set by moderator on 18 February 2009.
00:13 rin1024_ joined 00:51 rin1024_ joined 01:18 rin1024_ joined 02:05 rin1024 joined 03:30 rin1024_ joined 08:15 masak joined 08:26 rin1024 joined 13:59 krunen joined 14:47 pmichaud joined 14:49 Tene joined 16:11 masak` joined 17:16 Whiteknight joined
Whiteknight (posting my report early since I'm going to miss the meeting) 17:17
* Mostly working on the Matrixy compiler. Progress is very rapid indeed (PCT++)
* Started playing with the Socket PMC, but looks like other people are doing it first 17:18
* Random assorted poking at tickets and digging through code, nothing major
EOR
17:31 barney joined 17:50 Infinoid joined 17:54 allison joined 18:07 Util joined 18:19 Tene joined 18:26 chromatic joined 18:28 fperrad joined 18:30 Coke joined
Coke ~~ 18:30
chromatic Good $LOCALTIME
moritz hi there
pmichaud Hello. 18:31
fperrad hello
Infinoid ohai
Coke chromatic: you leading the dance today?
allison hi
chromatic Will do. Allison? 18:32
allison Parrot:
- More fixes to Debian Parrot packaging. Parrot 1.0 has now been uploaded to Debian (thanks to our Debian sponsor Colin Watson).
- Ticket review, resolution, closing.
- Added a --disable-rpath configuration flag, for Linux packaging.
Pynie:
- Attended PyCon, including a virtual machine summit before.
- After talking with Guido, Pynie will be targeting Python 3.x, skipping 2.x entirely.
- Applied patches from contributors.
- Added support for the continued line feature and octal integers.
- Added initial debian packaging files.
- Nearly finished porting Pynie's bootstrapping tests to SubUnit, a python-based testing framework (notionally equivalent to Test::Harness), that can integrate with the CPython test suite.
EOR
masak is here too
Util too
chromatic I'm working on the *ManagedStruct JIT problem for cotto.
Will create a branch to work on reorganizing headers and source files into subsystems today or (likely) tomorrow. 18:33
barney?
barney Parrot:
removed some hardcoded 'library' path components in 'load_bytecode' calls
.eor
chromatic Coke?
Coke - still haven't gotten back to TWIP. I'm afraid the longer I take, the more I dread it. 18:34
18:34 PacoLinux joined
Coke - worked on t/codingstd/c_function_docs.t; mainly ensuring at this point that we're counting the already-written documentation. 18:34
- RT down to 379 tickets.
- there's a parrot 1.0 macport now. I could use help with the devel version, though I'll give it another whack later in the week.
- trying to resurrect partcl, but need the devel port first.
-eor
chromatic cotto?
cotto * almost have all PMCs converted to ATTRs 18:35
- am blocking on some jit-related code (TT #365, TT #519)
EOR
chromatic davidfetter? 18:36
davidfetter ETOOLAZY
chromatic fperrad?
18:36 particle joined
fperrad * some experiments with load_language : not conclusive 18:36
* work on Markdown : basics work
funny problems this morning with r37824 (PGE merge)
because everybody use same identifier name
- Markdown::Node has a attribute 'text' : OK
- grammar uses a token 'Str' : KO, conflict with method .Str (previously .text)
* Lua blocker : RT #59968 ~ TT #472 (segfault when catching an exception from C)
EOR 18:37
chromatic GeJ?
Infinoid? 18:38
Infinoid * Been trying to keep up with bacek++'s continuing socket improvement patches.
* Fixed some socket-related stuff. Made a few improvements to the httpd.pir example.
* The sockets stuff is far too shiny, and it has distracted me from making any progress on website migration stuff.
* Cleaned a few cages.
q1q
1;
chromatic japhb?
masak? 18:39
masak - haven't been to a sketch since March 3rd.
- submitted 40 bugs since then.
- worked a lot on Druid, proto, Web.pm, November (in decresing order of 'a lot').
- doing most thinking and discussing on Web.pm, though.
- even got some Rakudo hacking done! \\o/
- nothing outstanding in Rakudo that needs urgent fixing.
- preparing for NPW2009.
- from a user perspective, Rakudo, despite the record number of new/open tickets, has never been nicer to work with. jonathan++ pmichaud++.
- also, a Perl 6 community is definitely forming. makes me happy.
.eor
chromatic moritz? 18:40
moritz * observed some segfaults creeping back into Rakudo (don't know if they are parrot induced)
* published two Perl 6 articles in a German computer magazine (iX)
* trying to keep the test suite up-to-date, but the spec is moving too quick, and the implementations too slow.
* no parrot work (except occasional POD fixes)
* can agree with masak on the last two points
</report> 18:41
chromatic particle?
particle just small parroty things here and there
dealing with irs
tested sockets code on windows bacek++ infinoid++
google summer of code applications rolling in 18:42
questions, too. been doing my best to answer or direct students in the right direction
application period ends this friday
.end
chromatic PerlJam? 18:43
pmichaud? 18:44
pmichaud * Rakudo now passing 8039 spectests (+717 since last #ps!)
* Added better support for P5 regexes to PGE (and Rakudo)
* Started other refactors related to changes in Synopsis 5 and other PGE improve
ments
* Expect to continue PGE work this week, start HLLCompiler refactors
** Plan to have these available (and new tutorials) in time for NPW
* Jonathan and I are discussing ways to deal with (improve or circumvent) Parrot calling convention issues impacting Rakudo
** We will likely flesh this out in more detail both in IRC discussions and at NPW
EOR
chromatic Tene? 18:45
cotto q1q
chromatic tewk?
Util? 18:46
Util Tuit deficit. No committable work done. Carried over from last week:
* Converting t/op/trans.t to pure PIR
* "Win32 - Porting Parrot to MinGW-TDM"
More tuits expected this week, though.
Showed off the #perl6 evalbot at the Atlanta.pm after-meeting dinner. 18:47
Helped on IRC with macports problem.
EOR
chromatic Did I miss anyone?
Okay. Infinoid, you had one question. 18:48
Infinoid Vasily Chekalkin (bacek) has been involved in parrot for some time, and has submitted quite a few high quality patches.
He seems motivated and has been responsive to the various concerns I've raised.
What do we think about giving him a commit bit?
chromatic +1 here
fperrad +1 18:49
cotto +1
Coke +1
particle he's earned it.
barney ++
particle do we have a mentor?
masak +1
pmichaud who will ment..... right.
Coke infinoid, obviously, since he asked. =-)
particle i'm doubly happy to see a recent committer mentoring a new one. 18:50
pmichaud I'll just note that I think bacek needs close mentoring -- some of his patches in the past put functionality in the wrong place.
that said, recent patches have been much improved.
particle pmichaud: that's more been the case with his rakudo patches than with parrot
and, yes.
Infinoid yeah, me +1 obviously
allison +1 with CLA and mentor
Infinoid (sorry about the delay)
particle have him get his cla off in the mail to the parrot postbox, and upon receipt we'll hand him his commit bit. 18:51
Infinoid if mentoring means reviewing patches like I've been doing and discussing issues, I can do that
pmichaud yes, with the exception that you have to review commits instead of patches :-)
Infinoid I'm a git user. commit is relative :)
particle Infinoid: if he breaks parrot, we flog you :)
moritz we flog both ;-) 18:52
Infinoid Sounds good. thanks, EOQ
allison Infinoid: also being available to answer his questions, training him in sane commit and branching practices, etc
particle wonders if we should add a mentoring section to the committers guide
Infinoid That would help me
allison particle: +1
particle i'll see what i can do. 18:53
allison any more questions before roadmap review? 18:54
chromatic cotto, you had a question.
cotto Do we want to keep the PMC_DATA_IN_EXT macro in include/parrot/pobj.h? Setting it to 1 currently breaks the build when miniparrot tries to compile config_lib.pasm, and it's very likely going to bitrot further as time progresses.
chromatic I don't see its utility anymore. 18:55
cotto What was its previous purpose?
s/previous/original/
chromatic Keep PMC header size small if most PMCs don't need additional data outside of the UnionVal, I suspect.
cotto I'll file a ticket and/or get on it. 18:57
eow
s/w/q/
allison cotto: it used to be that the 'data' member could be either in the core struct or the ext struct
cotto: but now specified as always in the core struct
cotto: so, yes, can be removed
cotto sounds like a plan then 18:58
that'll make some code a little nicer 18:59
eoq
chromatic Any other questions?
allison this one kind of leads into the roadmap review... 19:00
chromatic Go ahead.
allison Based on our experience with estimations in the previous round, I've been looking over the Roadmap for 1.4, and think we need a few revisions in our battle plan. 19:01
Would folks prefer to talk about that here or on the mailing list?
pmichaud here.
unless you have a long proposal already in mind.
allison nope, just topics for discussion at this point 19:02
The list:
particle yes, here then
allison - A big release is a huge drain on developer energy, and also requires packaging/bug fixing, etc work immediately after. So the month after a "supported" release shouldn't include any large development milestones. 19:03
pmichaud I'm not sure I entirely agree with that. (more) 19:04
allison - 1.0 gained us a lot more visibility than I anticipated. Some things we marked as lower-priority until 2.0, have become a higher priority as a result.
pmichaud (shall I wait for the full list before commenting?) 19:05
allison (among these are GC and calling conventions)
pmichaud: (checking my list...)
that'll do it for general motivators
pmichaud: go ahead
particle we're free to modify our roadmap anytime, as long as it's discussed and agreed upon.
allison particle: yup, this is a "discussing and agreeing" session 19:06
pmichaud (big release): my impression from the 1.0 release is that much of the packaging/bug fixing taking place is with respect to the 'make install' step
particle porting, too.
pmichaud in that sense, we really had expected that to occur before 1.0, but it didn't.
so I don't know that the month-after-1.0 is representative in that respect
allison pmichaud: so the energy spent here may not repeat in other supported releases, good point 19:07
pmichaud: I'd still like to revise our 1.1 milestones
pmichaud I agree with revising milestones; I'm just not sure that the conclusion (month after release shouldn't included large milestones) follows from the premise.
allison pmichaud: the developer energy, though, I suspect will repeat on each supported release
pmichaud I guess it depends on how much energy it takes to do a supported release 19:08
in my case, many features that I wanted to work on really needed to wait until after 1.0 to be done
(because of deprecation issues)
Coke I suspect 1.4 will be easier than 1.0 in that regard.
pmichaud I agree. 19:09
allison pmichaud: the month before a supported release should always be focused on fixing and cleaning
Coke (the "amount of energy" regard.)
allison and, it was, in this case
pmichaud at any rate, I think we just put development milestones where the person making the changes feels it makes more sense.
allison pmichaud: ah, yes, I forgot to mention that part: the month after a "supported" release will be focused on removing deprecated items 19:10
(this month certainly has been so far)
pmichaud well, I'm expecting a fair amount of PGE/PCT development in April; but perhaps I'm just the oddball of the group there.
allison so, we should plan for it, since we've already planned our release schedule around it
chromatic I don't think you can predict so succinctly what volunteers will work on. 19:11
allison chromatic: but, we can set saner milestone goals based on the anticipation that our effort will be focused elsewhere
milestones aren't about "predicting" they're about deciding where to put our energy 19:12
so, we plan that the month after every supported release has a focus on removing deprecated items
chromatic Okay, but I still don't think you can predict what volunteers will work on.
pmichaud anyway, I don't know that this is that big an issue. Looking to specifics, are there items currently slated for 1.1 that you think need to move?
particle security can move out 19:13
Coke pir profiling tools is not going to get done if there's no one championing it.
allison chromatic: I'm not trying to predict, I'm trying to decide where to spend my time
particle pcc should move up
pmichaud I suspect pir profiling tools isn't going to happen in 1.1
allison yes, that's one to move out
Coke allison: you're trying to decide where to spend everyone's time. =-)
pmichaud pge ltm and protoregex will have progress; protoregex is likely to happen, ltm is not likely.
allison I'd also like to reschedule the security implementation work
pmichaud (progress on ltm, yes, completion of ltm, no) 19:14
particle coke: *we're* trying to decide. it's not just allison
allison and from 1.2, reschedule the strings/nfg work
pmichaud allison: moving strings/nfg later?
particle yes
allison coke/particle: this is about everyone deciding what they can reasonably accomplish
pmichaud: yes, strings/nfg later
pmichaud: if you need optimizations earlier, we can do that 19:15
pmichaud I think I need features more than optimizations
particle the features you need aren't currently on the roadmap, iirc
pmichaud Rakudo fails a significant number of spectests that it would otherwise pass except for reasonable unicode coverage
Coke optimizations should wait until after the profiler, anyway.
particle ah, sorry, you mean strings features. 19:16
pmichaud yes, strings features.
allison pmichaud: can those be broken down into specific issues?
pmichaud yes. (more) 19:17
allison pmichaud: because what we have on the roadmap now is "big scary refactor that may not actually help anyone"
pmichaud (1) being able to determine if a codepoint is alphabetic/upper/lowercase
(2) being able to convert codepoint names into codepoints
(recognizing that #2 might not be a part of Parrot, but if not, we need to know that so we can implement it in Rakudo.)
19:18 jonathan joined
allison (2) seems like a reasonable feature, and should be possible with ICU 19:18
pmichaud (3) being able to handle upcase/downcase on codepoints above 256
(4) how to handle all of the above when ICU isn't present, or alternately, requiring ICU to be present.
allison (1) also should be possible with ICU (and wasn't part of the nfg refactor anyway)
How many platforms are we shooting with (4)? 19:19
Are the Big Three covered?
pmichaud I don't know if Windows is covered yet for ICU.
particle icu is available on windows 19:20
Coke icu4c-3_6-src.zip10.6 MBZIP file for Windows platforms
pmichaud particle: are we building parrot with icu on windows yet?
particle i build without it, but don't mind a requirement
allison easily installed?
particle we *can* build parrot with icu on windows
yes, easy install
fperrad I do with
particle unzip, add to path.
iirc
fperrad: does the win32 parrot distro include icu? 19:21
fperrad yes
allison Okay, add a ticket for "require ICU" as a possible
particle excellent. let's require it.
pmichaud I'm happy (happier) if we require ICU -- that reduces my need for string changes greatly.
moritz YaY 19:22
pmichaud and it gives a path for being able to fill in missing functionality since we can assume ICU is present.
allison so, the tasks that become a higher priority based on our unexpected visibility are GC, calling conventions, and language implementations 19:23
Coke aren't language implementations outside of the scope of parrot itself?
allison yes, but they factor into my time
pmichaud I'm expecting to develop a new 'mk_language_shell' script based on Rakudo's build environment and the upcoming changes to PCT
chromatic Why is GC such a high priority? 19:24
allison i.e. I plan on spending the majority of my time up to 1.4 on GC, calling conventions, and Pynie
chromatic: because of our speed issues
Coke "without a profiling, how do you know that's where the time is spent?" =-)
pmichaud Rakudo also increasingly runs into places where we'd like/need contexts to be PMC-reachable.
Coke *profiler.
allison Coke: you can't, but I can tell you for sure that our current GC is slow 19:25
the biggest problem is that we're killing PGE/NQP
chromatic How about you listen to the person who *profiled* Parrot? The problem isn't the GC.
allison chromatic: okay, then what is it? 19:26
chromatic Exactly what I've been saying for the past several months. Calling conventions.
allison (keeping in mind that calling conventions is already on my list)
okay, yes I know that
pmichaud I think chromatic's point is that GC should be a distant second to calling conventions.
allison but, changing the calling conventions is going to put more pressure on the GC
we'll at least need to add "active pools" for signature objects 19:27
not a full revamp, just an addition
chromatic There are two potential possible changes which can ameliorate some of the damage in the GC: scanning only specific pools (unlikely), and not always putting an entire new pool on a free list.
When parrot_pass_args is somewhere between 30 and 40% of the entire profile for benchmark applications, the problem isn't the GC. 19:28
allison aye, we've had these conversations
so, I'll revise: I plan on spending the majority of my time up to 1.4 on calling conventions and Pynie 19:29
pmichaud +1
allison and will see if I can convince chromatic to work on a few small changes to GC, once I put more pressure on it
pmichaud allison: I'm curious for the reason for the Pynie focus (not disputing it, just curious) 19:30
allison as one example language
pmichaud because it's .... right
it's an example language that (1) needs attention, (2) is a very good candidate for PCT/Parrot, (3) has visibility, (4) isn't Rakudo.
allison we need a complete implentation out there
and, Python has been very welcoming, far more than I anticipated 19:31
pmichaud okay. Obviously my focus continues to be Rakudo but if I can help out with Pynie then let me know.
Coke s/rakudo/partcl/ but ditto.
allison pmichaud: yes, your focus needs to be Rakudo (and any help on the side welcome)
pmichaud and my biggest help to Pynie will undoubtedly be improving PGE speed.
question: is there a published Python 3.0 grammar somewhere? 19:32
allison pmichaud: yes, PGE speed will be a huge benefit
pmichaud: in the tarball (and py3k repo)
pmichaud okay. Is it just a yacc grammar, or is it a document like the "Python Language Reference" guide was for 2.x ?
allison pmichaud: it's actually a pretty small diff from 2.x
pmichaud okay, that's good.
allison EBNF grammar 19:33
pmichaud perfect.
allison almost translates directly to PGE
pmichaud and you can reuse much of the existing grammar.pg then.
allison pmichaud: yup, and actions
and tests 19:34
jonathan (pynie) I'm happy to answer any questions on stuff too - especially in areas relating to those I've covered in Rakudo.
pmichaud I need to pick up kids from school -- I'll read logs later.
19:35 kj joined
allison jonathan: I've actually started writing a few messages to the Rakudo developers asking how to do X or Y, but always figure it out before I send the message 19:35
pmichaud I'm fine with restructuring milestones; those with my name on them largely remain the same I think.
allison okay
I'm mainly changing the ones with my name on them
pmichaud one thing that would be helpful is for us to designate a way to indicate milestones that are critical to a language as opposed to parrot
allison (or with no name on them)
jonathan I fully agree that the calling enhancements are where we need focus. 19:36
(sorry, backlogging...)
allison pmichaud: how about "critical (rakudo)"
pmichaud that's fine with me. Either a tag, text, or whatever in a trac ticket would work for me.
just let me know what it is :-)
gotta split -- back later.
allison so, back to the roadmap, the things I'd like to reschedule: 19:38
- pdd18-security
- security sandbox
- pir profiling tools
- strings + nfg
- fix dynpmc vtables 19:39
- concurrency/threading (not that no work will happen, just that it's not a milestone priority)
Any problems? 19:40
particle i'd like to see strings, security, and dynpmc in before 1.4, so they're more widely used before 2.0 (in that order)
allison particle: okay, I'll schedule them in the 1.5-1.9 range
jonathan Can somebody give me a reference for the dynpmc vtables issue? I wasn't aware of that issue... 19:41
allison oh, 1.6-1.9 (keeping in mind the "deprecation work" for 1.5
jonathan: no clue
jonathan: I may delete it rather than moving it
chromatic It's important actually.
jonathan allison: OK. We've been using dynpmcs and dynops successfully in Rakudo, so I was curious exactly what it is. 19:42
chromatic It's making dynpmcs initialize their vtables without directly poking vtable function pointers from libparrot into their own vtables.
allison (That's what someone usually says when I try to delete a roadmap item)
chromatic That means we can remove PARROT_EXPORT from all vtable functions.
jonathan chromatic: Is this related to being able...ah, right.
chromatic (and remove several thousand externally visible symbols from libparrot)
allison chromatic: could you write that up as an RFC ticket?
chromatic (and speed up linking and startup relocations) 19:43
allison then we can attach it to the roadmap
chromatic I think there is a ticket for it, but I don't know where it is.
particle write another, and they can be merged later
jonathan chromatic: Agree reducing starup relocations would help for usre.
chromatic It was just a mailing list post. I'll c&p into a ticket.
jonathan *startup, sure
Given it might even give a startup time win that becomes noticable in make spectest for Rakudo, I may find some tuits to make that happen. 19:44
chromatic I have about half of it done so far.
It should be a few days of work; no biggie. 19:45
Right now I'm (still) knee deep in the JIT, so no promises for the next couple of days.
jonathan chromatic: OK, great. :-) 19:46
allison That wraps up my roadmap discussion 19:47
pmichaud said to keep his 1.1 milestone item 19:48
namespaces is in review
parrot on cygwin is landed
and that's the 1.1 milestone list
Any more roadmap review items before we close? 19:49
particle remove the pipp developers release, barney has no plans on it atm 19:50
that's it from me
Coke allison: removing the profiler for 1.1 also?
allison Coke: moving it out, yes 19:51
barney I'm busy in the next two months, hope to make some progress in summer
allison Coke: preferences on moving it to before or after 1.4 or 2.0? (I think before 2.0)
kj waves, without a report :-( 19:52
jonathan Agree, before 2.0 would be good. 19:53
Coke allison: I want it asap. I can't do it. so... doesn't matter. =-)
jonathan Sufficienlty early, it'll help language implementers improve their language implementations pre-2.0 too.
Coke if you make parrot faster, it's less useful.
allison Coke: I want it now 19:54
particle jonathan: right. to be "production-ready" we need these features, and stable languages
allison right now
tewk Profiling support == timing subs and exporting as callgrind format?
Coke so put it before 1.4, and we'll hope someone gets tuits. <shrug>
allison Coke: sensible
particle tewk: pir-level constructs, yes
constructs/operations 19:55
19:58 diakopter joined
allison sounds like we're wrapped. Thanks everyone! 19:58
19:59 diakopter left, fperrad left, Util left 20:01 jonathan left 20:04 chromatic left 20:11 particle left 20:14 Infinoid left 20:20 masak left 20:34 PacoLinux left 23:36 Whiteknight joined 23:49 Coke left

Powered by Cro and the Raku® Programming Language.

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

Thank you!