Priorities for this week: irclog.perlgeek.de/parrotsketch/201...#i_3126985 | Post closed tickets in your report. | Note: This channel is for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irclog.perlgeek.de/parrotsketch/today
Set by moderator on 28 December 2010.
06:10 contingencyplan left 10:30 mikehh joined 15:17 contingencyplan joined 15:37 atrodo joined 17:29 kid51 joined
kid51 kid51's report 17:29
DONE
* Closed trac.parrot.org/parrot/ticket/1927: Parrot doesn't build with spaces in directory names
* Closed trac.parrot.org/parrot/ticket/1890: Installed Parrot requires build dir
* Closed trac.parrot.org/parrot/ticket/344: Can't create working installed parrot for macports
WORKING ON
* trac.parrot.org/parrot/ticket/1925: Remove config step auto-jit: This just needs comments/review; otherwise ready to merge. 17:30
* trac.parrot.org/parrot/ticket/1922: Remove 'make help' outfit: Comments welcome.
* Preparation for Jan-29/30 PDS
PARROTSKETCH NEEDS TO DISCUSS
* Parrot Developer Summit
** Need to discuss day and time of Parrot Developer Summit scheduled for weekend of Jan 29-30.
** Last time (Dec 05 2010) we used a polling mechanism to determine time.
** We could do that again, but ...
** ... that resulted in a time which was convenient for Western Hemisphere (Sun mid-afternoon or early evening)
** ... but was necessarily less convenient for Europe or Australasia (Sun late night or Mon early morning)
** Should we rotate the inconvenience on a quarterly basis? 17:31
*
* Google Code-In
** Public recognition for participants who worked on Parrot (I'd like to know each student's real name/city/country).
** Invite participants to get commit bits (discuss whether/how parental consent is necessary).
** Evaluate impact on Parrot Project:
*** How many commits resulted?
*** What new functionality was added?
*** How many new tests were written?
*** What did GCI enable us to do that we wouldn't have done otherwise? 17:32
*** What did GCI divert our attention from?
** In addition to a discussion in psketch, a write-up should be posted to parrot-dev
EOR
18:34 cotto left 19:05 NotFound joined 19:19 plobsing joined
NotFound What I did since last report: 19:21
-parrot
* Minor fixes
-winxed
* Some more compile time evaluations of constant expressions
* volatile var
* Minor fixes
What I will do:
No plan
EOR 19:25
19:30 whiteknight joined
whiteknight WHAT I DID: 19:42
* Helping out with the last few GCI tasks. It was a great program but exhausting.
* On a ticket rampage. Closing lots of tickets, or getting other people to close them for me. We're down to ~570. I would like to be much lower.
* Working on the ExceptionsTasklist wikipage to start putting together a rough TODO list. Taking ownership and triaging many open Exceptions-related tickets.
* Created a branch exceptions_backtrace to add information about backtraces to be preserved across rethrows. This is a temporary fix, I'm planning out the real solution in my head and will put pencil to paper about it soon.
* Created the kill_packfile_new_dummy branch to try and kill the PackFile_new_dummy function, and make packfile handling more consistent. Initial attempts look promising, but still failing tests. This will probably wait till after 3.0.
* Having problems testing PLA. I'm going to start a new ecosystem project for test-related modules, borrowing code heavily from the beleaguered kakapo project. That will probably go public soon.
WHAT I WILL DO:
* Keep closing tickets. I would love to get down to ~550 by next week.
* Trying to get PLA building and running all tests against current Parrot. Probably going to require lots of Kakapo changes, or another test solution.
* Would love to have PLA and ParrotSharp releases ready shortly after 3.0.
EOR
plobsing What I Did: * attempt to make parrot work better with non-ascii OS strings * add documentation about debugging random failures. * polish Ī©Ī· to be more suitable for users (docs, installer) 20:11
What I Plan: * more packfile stuff (in branches, likely too big for upcoming release) * more polish for Ī©Ī· (plumage, etc...)
OK, bad paste. retrying in 3..2..1
ccache cc -I./include -I./include/pmc -ggdb -march=native -DHASATTRIBUTE_CONST -DHASATTRIBUTE_DEPRECATED -DHWhat I Did: 20:12
dukeleto lulz
plobsing What I Did:
* attempt to make parrot work better with non-ascii OS strings 20:13
* add documentation about debugging random failures.
* polish Ī©Ī· to be more suitable for users (docs, installer)
What I Plan:
* more packfile stuff (in branches, likely too big for upcoming release)
* more polish for Ī©Ī· (plumage, etc...)
EOR
cotto_work *did: 20:15
- keep up with gci
- finally over; very successful, very draining
- blogged: reparrot.blogspot.com/2011/01/thank...dents.html
- next year, we'll need to manage it a bit differently
- lots of code review 20:16
- coke++ for speeding up str2c again
- more digging into nqp-rx/nom
- chatted with jnthn. Progress has resumed.
- I have a rough idea of what's needed for Lorito planning at this point.
- rfc review
*will do:
- 3.0 release
- more rfc review
*blockers:
- none
*eor
q3q
dukeleto What I did: * Rode the GCI crazytrain and survived. Thanks to everyone who helped! * Merged many branches from GCI students, increased lots of test coverage. * Worked on my TPF grant in the leto/embed_grant branch * Improved our git docs, adding info about keeping a fork in sync 20:17
What I will do: * Hack on my TPF grant * Write a GCI blog post
darn you, copy and paste.
Blocking on: * Time
.EOR
Util # Done: 20:20
* Recovered from flu; no Parrot work done.
# Plan to do:
* Finish .dmg for Rakudo Star (usable by Parrot)
# 7-day ticket report: 20:21
1 closed: duplicate
29 closed: fixed
1 closed: invalid
6 closed: wontfix
18 new
4 reopened
.end
mikehh What I did since my last report: 20:28
* building and testing parrot on amd64/i386, with gcc/g++
* quite a lot of fixes, especially related to GCI
* sorted out some build failures and removed some warnings
* merged html_cleanup branch into master
* this needs some checking, especially the index/header pages as they now pick up
* the page title (in the index page) directly from the generated html files
* previously this was picked up from the Parrot::Docs::Section files which
* had both the file name and thge title, now we have to work from the file name alone
* I have not yet removed these (Parrot::Docs and ::Section files (for checking)
* they wioll be removed later in html_cleanup_2
What I intend to do in the next week:
* testing and fixing
* set up html_cleanup_2 to remove the cruft left over 20:29
.eor
kid51 Good localtime() everybody! 20:30
tadzik o/
whiteknight hello 20:31
Util Hello
cotto_work hi
mikehh hi there 20:32
cotto_work anyone feel like leading this thing?
kid51 thinks we should set up a rotation of ps chairs (as we do for releasemanager), so we don't waste time each week deciding this 20:33
cotto_work volunteers
kid51 Proceed
cotto_work Our goals last week were to keep up with gci and get plumage working. 20:34
Both seem like a success, from what I can tell.
kid51 First achieved -- but I have no knowledge of latter.
whiteknight plumage is working and is submitting reports to smolder
cotto_work The next barrier appears to be getting people to actually use plumage
whiteknight If you haven't done so, I recommend everybody here give it a shot 20:35
NotFound plumage was working, the goal was to test it the more possible. If most people don't know, the goal has failed IMO.
kid51 Could someone post the procedure (a) to parrot-dev; (b) to a wiki page?
NotFound trac.parrot.org/parrot/wiki/ModuleEcosystem 20:36
kid51 Perhaps wiki page should be titled: "Plumage: Parrot's Module Ecosystem" 20:37
plobsing NotFound: TL;DR
NotFound A page specific for instaling and use it, separated for rationale and design plans mey be better. 20:38
cotto_work Documenting plumage in a "getting started" page sounds like a good goal. 20:40
NotFound A TODO ticket for that? 20:41
cotto_work It should have as low a barrier to entry as possible.
dukeleto hola
cotto_work If you want, but you could also just start a GettingStartedWithPlumage wiki page.
NotFound We have too much wiki pages not linked from everywhere, I think. 20:42
cotto_work Wiki organization is lacking. 20:43
We'd need both a cleanup and a system to keep the wiki organized.
kid51 Wikis are inherently disorganized.
cotto_work not critical, but it would be nice
indeed 20:44
dukeleto are we onto questions?
cotto_work sure
kid51 A post to parrot-dev by someone knowledgeable would suffice to get me started with plumage
q1q
cotto_work any other questions to queue before we dive in? 20:45
ok. I had 3, some of which weren't actually questions. 20:46
1 - The 3.0 supported release is 7 days away. Please don't push any new features or deprecation removals to master after today. Bug fixes are fine through Friday, IFF you don't break HLLs. After Friday, please limit changes to serious bugfixes and documentation improvements only.
NotFound The setlocale problem should be fixed before the release, or reverted. 20:47
cotto_work Was that not completely fixed?
whiteknight maybe we can set up a second, temporary integration branch, and keep master clean and bug-free for the release 20:48
NotFound cotto_work: no, even with the last plobsing patch it fails to read non-ascii directories with C locale. That is very ugly for a release IMO.
cotto_work Who can make sure that that bug either gets fixed or reverted by the end of the day today? 20:49
plobsing or NotFound? 20:50
plobsing I'm implementing the solution suggested by NotFound++ in #parrot a few minutes ago
NotFound cotto_work: I cab test and diagnose te problems, but haven't looked at the code chanegs.
plobsing++
cotto_work plobsing: thank you. Can you take point in reverting or fixing by the end of the day today? 20:51
plobsing sure thing.
cotto_work thanks. 20:52
next question-like entity:
We have several things to focus on for the release:
- deprecations: (remember that we now require an upgrade path to be in place before a deprecated feature can be removed) 20:53
- testing: I'll be damned if Rakudo isn't going to build on the 3.0 release.
(I focus on Rakudo because we've broken it frequently, but other HLLs are also important and need to be tested) 20:54
- docs: html_cleanup was merged earlier this week. Please review the generated documentation, especially links.
dukeleto is hacking on infrastructure that will make it easier to test parrot + rakudo and submit automated smoke reports and emails on failure
cotto_work Are there other things we need to keep under consideration?
dukeleto++
Don't forget that now is a really good time to comb through tickets and get deprecation notices in. 20:56
last comment: 20:57
gci was intense. We got a ton out of it, but it was also a big drain on resources. Next year, we should have a couple dedicated volunteers do most of the work so that the others don't get diverted from other tasks. This isn't so much of a question as a comment to keep in mind for the next gci.
eoq
any thoughts before kid51's question? 20:58
plobsing must leave, will read log
cotto_work alright. kid51, go ahead 20:59
mikehh re gci, we definately need a procedure to test etc. before merges
kid51 Parrot Developer Summit: last weekend of this month ... 21:00
Are we going to use an online scheduling tool as we did last time ...
mikehh spent a lot of time cleaning up
cotto_work kid51: +1 to an online scheduling tool
kid51 ... or are we going to deliberately set a time *different* from last month's time in order to better accommodate our members in different time zones?
whiteknight a different time would probably be good. The last PDS was recent, so it's more important to get people involved 21:01
kid51 Given that bulk of our devs are in Western hemisphere, using a tool and going with the plurality will always lead to times more convenient for us than say, bacek, GeJ, mikehh, nwellnhof, etc.
cotto_work mikehh: do you mean more than codingstds cleanups?
integration wasn't too well-organized 21:02
whiteknight kid51: Let's pick a general rotation schedule. Either 8hours or 12 hours from when our last one was
kid51 As I pre-posted, Sunday 6:00 pm US ET last time translated to early Monday AM in Australia; late Sunday night in Europe
mikehh cotto_work: probably, but need to think about that
kid51 My suggestion: Let'
Let me see if we can get a time that works for Bacek/GeJ, then work backwards from there. 21:03
whiteknight kid51: +1
kid51 In three months: prioritize accommodating European devs
In six months: prioritize Western hemi
cotto_work kid51: I like that, as long as we don't exclude a majority of developers.
mikehh I can generally fit with any time as long as I have a few days to sort it out 21:04
dukeleto cotto_work: is the old embed api properly deprecated?
kid51 cotto_work: I can't guarantee that; at some point in the year, each dev will be inconvenienced
dukeleto should have q1q'ed
kid51 Shall I proceed along those lines?
NotFound We don't have any developer in Antartida?
whiteknight dukeleto: I don't think it is. I need to add that notice
kid51: Yes 21:05
dukeleto whiteknight: that is important
cotto_work kid51: I don't mind if it's inconvenient for me personally. I just want to make sure that we have enough attendees to be productive.
kid51 If so, I will try to have the PDS scheduled by next week's parrotsketch
EOmyQ 21:06
21:06 plobsing left
whiteknight q1q 21:06
cotto_work If we can adequately define and address that, I'm fine with whatever the outcome is.
dukeleto: go ahead
dukeleto? 21:07
NotFound cotto_work: I think the question was the deprecation of old embed 21:08
cotto_work NotFound: plausible. whiteknight go ahead. 21:09
whiteknight on the note that dukeleto mentioned above, do we want to deprecate the old embedding API?
I do, but I would like a show of hands before I put in the notice
cotto_work +1 21:10
mikehh well we have the new one so the old one should be deprecated
whiteknight obviosuly we will need to make sure projects like PL/Parrot which rely on it will be updated before anything changes or is removed
kid51 deprecation => 'the notice goes in, but the current version stays until fully replaced' ???
cotto_work kid51: yes
kid51 +1
NotFound I think we need a +1 from plparrot, is the most active embedding project.
whiteknight kid51: I think so 21:11
cotto_work if at all possible
dukeleto cotto_work: sorry. Already taken care of, whiteknight is going to properly deprecate the old embed API
cotto_work dukeleto: ok
whiteknight okay, I'l commit the notice now
dukeleto +1 to deprecate old embed API, but don't remove until the new embed API can do what the old one does
NotFound Agreed
whiteknight done
mikehh +1 21:12
Util +1 21:13
cotto_work any other questions or comments? 21:14
21:15 bacek joined
bacek ~~ 21:15
mikehh yeah bacek
cotto_work hello bacek
bacek q1q 21:16
cotto_work go ahead
bacek Can we review all RFC/deprecation tickets during this week and properly put them into DEPRECATED?
whiteknight +1 21:17
bacek It's best opportunity to get rid of some old crap.
cotto_work definitely
mikehh +1
bacek Another question/idea. 21:18
cotto_work I'll help with that. Any other volunteers?
whiteknight cotto_work: me
me me ME ME ME
bacek cotto_work, I'll try to help.
cotto_work great. Others are welcome.
bacek: next question?
bacek Another RFC: simplify PIR.
During work on PIRATE I hit a lot of problems with current PIR sugar. 21:19
E.g. macros, etc.
whiteknight bacek: Do we simplify PIR as it is (in IMCC), or do we create a new language based on PIR for PIRATE?
21:19 plobsing joined
mikehh yes, but in what way? 21:19
whiteknight maybe PIRATE should be a compiler for PIR2
bacek whiteknight, not in IMCC.
whiteknight bacek: okay. IMCC is the compiler for PIR. PIRATE can implement it's own language 21:20
bacek pirate consist of 2 parts: PIR parser and PBC emitter.
cotto_work bacek: are you talking about seldom-used features that take too much effort in PIRATE or are you talking about major changes?
NotFound In that case, we should document the differences between "official" PIR and imcc extensions.
bacek cotto_work, "minor deprecations"
cotto_work for example?
bacek .macro
heredocs
cotto_work .macro is used 67 times in t/ 21:21
heredocs are used all over the place
bacek .set_returns/etc ("verbose pcc calls")
mikehh a lot of testing seems to depend on that
bacek Ok, I can try to implement heredocs.
NotFound A lot of tests are written in ugly ways just because they are very old. 21:22
mikehh macros always worry me, a lot of security issues there
whiteknight I think very old PIR features, like .set_returns and friends can be destroyed
TCL uses .macro heavily. Coke will plotz if we delete those
...and i'm not cleaning that up
cotto_work whiteknight: you pass the sanity test 21:23
bacek: if a feature would only require updating a handful of tests that'd be fine, but it sounds like those features are pretty widely-used.
bacek then I'll need some help with implementing macros :) 21:24
cotto_work it will be important for PIRATE to implement a highly-complete subset of PIR in order for us to use it as a replacement for imcc.
bacek But my main goal - emitting PBC from POST
cotto_work I'm always looking for an excuse to hack on PIRATE.
NotFound macros are very useful for hand written assembler languages, but pir is mainly intended to be generated.
bacek NotFound, +1 21:25
whiteknight I can take a look at macros. They may be easy enough to if we can defer translation until we get to the code generator
bacek whiteknight, you welcome. github/parrot/pir :)
whiteknight bacek: Yeah, I know where it is :)
whiteknight has to pack up and go home now. Will backlog 21:26
bacek Another PIR change: more strict syntax.
mikehh on that note, any progress on tree-optimization
bacek E.g. remove support for bare function names.
foo() vs "foo"()
cotto_work bacek: that sounds like something that would be fairly reasonable to automatically fix.
or at least half-automatically 21:27
NotFound A feature I'd like: allow registers in .param
bacek cotto_work, yeah. It's supported in PIRATE now. But I don't like it.
mikehh, no word from tcurtis...
cotto_work +1 if it can be fixed. Is there a deprecation ticket?
bacek cotto_work, yes.
NotFound Automatically generating param names is painful, is easier to use register numbers, 21:28
bacek NotFound, I can look at it. No promises at all, but I'll try.
cotto_work NotFound: can you file a ticket? That sounds like something that'll be easier post-PIRATE.
21:28 whiteknight left
bacek Last thing: moving PCT into separate repo. Similar to nqp-rx. 21:29
cotto_work +1 on the condition that it get very frequent testing.
mikehh plumage?
cotto_work If we break that, a lot of people will be sad.
NotFound Also, is the problem of setting annotations berfore params fixed?
bacek cotto_work, of course. Looks like we almost have mj41 back with new shiny taptinder.
cotto_work bacek: that's great news. Will we be able to easily add and get yelled at when we break new projects? 21:30
bacek cotto_work, I hope so. 21:31
cotto_work NotFound: is there a ticket on that? I don't see one.
NotFound cotto_work: I'll look and create one if not. 21:32
cotto_work NotFound: thank you
bacek Sorry, time to go.
cotto_work bacek: thanks for dropping by
any other comments before I list this week's goals?
here's what I have: 21:33
GOAL 1: Write a GettingStartedWithPlumage wiki page
GOAL 2: Fix the setlocale bug (plobsing)
GOAL 3: Review the documentation produced by make html (all)
GOAL 4: test HLLs, especially Rakudo and nqp-rx after the feature freeze (all)
GOAL 5: review all deprecation tickets, file proper notices (cotto, whiteknight, bacek)
kid51 +1 21:34
cotto_work any volunteers for the plumage wiki page?
mikehh I want to do one on the new make html and requirements 21:35
cotto_work mikehh: Do you have a question or a goal? 21:36
mikehh just a goal for me
cotto_work ok
mikehh and commentin' why i wasn't volunteerin for plumage 21:37
cotto_work Volunteers are welcome for the plumage wiki page task. Let's call it a wrap. 21:39
tadzik can I help? 21:40
mikehh tadzik: help always welcome
tadzik I mean, with the wiki page 21:41
that's supposed to be showing off the plumage usage, both from the user's side and the developer's side, right?
21:41 bacek left
NotFound tadzik: user side 21:42
tadzik a'right. When is that for, before 3.0?
NotFound Developer side is: trac.parrot.org/parrot/wiki/ModuleEcosystem
tadzik right 21:43
21:43 dukeleto left
mikehh tadzik: the wiki pages are not specifically related to parrot releases 21:43
tadzik so "the sooner the better"? 21:44
bah, too many questions. I'll make a note when I write something 21:45
NotFound tadzik: you can start with a very minimal one, is better than none, and incrementally improving.
mikehh tadzik: you can put up an outline, fill it in and when ready link to the main page 21:46
tadzik NotFound: yeah, that's my plan
I'll try to put up some sketch tomorrow
21:47 kid51 left 21:53 bacek joined 22:08 plobsing left 22:15 NotFound 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!