Priorities for this week: MappedByteArray increase coverage & write demo, Google Code-In | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings (at 20:30 UTC); you probably want #parrot instead. | irclog: irc.pugscode.org/
Set by moderator on 7 December 2010.
01:26 whiteknight left 05:43 bluescreen left 06:09 eternaleye_ joined, eternaleye left 07:27 wagle left 08:07 wagle joined 08:56 contingencyplan left 10:19 bluescreen joined 12:15 bluescreen_ joined 12:42 lucian joined 13:22 bluescreen_ left 13:38 bluescreen_ joined 15:04 bluescreen left
dukeleto is on vacation and won't be at #ps today 15:33
15:36 atrodo joined 15:40 bluescreen_ left 15:52 bluescreen_ joined
lucian too 15:53
16:09 bluescreen_ left, bluescreen_ joined 16:11 bluescreen joined 16:37 contingencyplan joined 17:00 mikehh joined 17:21 cotto_work2 is now known as cotto_work 17:52 NotFound joined
NotFound Last week I didn't do a report, this one is for two weeks. 17:57
What I did:
-parrot
* merge mappedbytearray branch
* move Parrot_io_parse_open_flags from io/filehandle.c to io/api.c
* add init_int vtable to Exception PMC
* minor fixes
* add some tests
-winxed
* Put stage 0 up to date with changes in encoding
* Fix problems reported from GCI tasks
* Fix post inc and dec operator in void context in stage 1
* Several minor fixes, refactors and nano optimizations
* Experiments with class creation on the fly and JS-alike method search
What I will do:
No fixed plan
EOR
mikehh What I did since my last report: 18:00
* building and testing parrot on amd64/i386, with gcc/g++
* some fixes
* testing Rakudo and Winxed on latest parrot
What I intend to do in the next week:
* testing and fixing
.eor
19:25 whiteknight joined
whiteknight WHAT I DID: 19:30
* More work on embed_api branch. Lots of fixes. Help from kid51++, Coke++, and bluescreen++ We've identified and fixed several problems and test failures. Only remaining failures that I see now are in codestd tests
* Blogging. Talking about Lorito and starting a series about "GC for Newbies" to explain the concepts to an audience unfamiliar with them.
* Started a new project, Parrot# ("ParrotSharp"), which is going to wrap the new embedding API for use in .NET/Mono applications. Work moving very slowly
* Working on GCI, trying to keep up with students
WHAT I WILL DO:
* Trying to get embed_api2 passing all tests
* When it's passing tests, I want to update it to master again. There are going to be some conflicts
* Would like to prepare a merger for shortly after 2.11
* Need to send some mails to the list about the coming release.
BLOCKING ON:
* Nothing
cotto_work *did: 19:32
- met with allison, chromatic and dukeleto to figure out a direction for Lorito
- rough notes at gist.github.com/740858
- approved/reviewed some gci tasks
*will do:
- more gci review/approval
- write out more well-formed thoughts on Lorito
*blockers:
- none
*eor
q2q
19:56 chromatic joined
Coke I tried to compile embed_api2 and complained a bit. EOR. 20:15
20:17 tcurtis joined
chromatic I pushed a new Lorito branch just after dukeleto did. 20:19
Util # 7-day Ticket Report: 20:29
2 closed: fixed
2 closed: invalid
9 new
2 reopened
# Done:
* No pure-Parrot work this week.
# Plan to do:
* Pbc_to_exe work.
# Blockers
* masak++ 5-problem Perl 6 contest <<< tuits
.end
cotto_work hello 20:31
mikehh hi there
Util Hello
NotFound Hola 20:32
chromatic hello
How'd we do with last week's goals? 20:34
tcurtis Hi.
NotFound About MBA: increased coverage a little, no demo AFAIK 20:35
chromatic Any other particular goals? 20:36
I've seen a lot of embedding API work and some Lorito branch work.
Any status on those?
NotFound embdding is in whiteknight report 20:37
chromatic What's the status of the GSOC branches, any progress there?
cotto_work nothing on my end (gsoc_instrument) 20:38
20:38 plobsing joined
chromatic Let's talk about next week then. 20:38
Our release is next Tuesday, correct?
cotto_work yes, with whiteknight as the release manager 20:40
whiteknight and it's going to be a good one
chromatic Anything we should concentrate on before then?
NotFound Releases dates are no more on google calendar?
20:40 kid51 joined
whiteknight I think we should focus on tickets and DEPRECATED.pod 20:40
lots of gold to be mined there, I think 20:41
mikehh how about html_cleanup for inclusion
whiteknight ah yes, that's a good one
NotFound whiteknight: some is already mined
whiteknight NotFound: yes. It's still something good to work on before the release
NotFound Agreed 20:42
kid51 joins late. Report: Merged tt532_headerizer_refactor. Did testing for whiteknight of embed_api2 on Darwin and Linux. EOR
Coke (google calendar) I only put them so far out the last time i entered them.
kid51 signed PaFo documents; mailed them yesterday
chromatic Shall we say "Remove deprecations | close tickets | merge html_cleanup and embed_api"? 20:44
NotFound +1 20:46
mikehh +1
whiteknight embed_api2 might not merge till after the release 20:47
still have lots of docs and tests to write
but otherwise, +1
chromatic Let's keep it as a goal.
whiteknight alrighty then
chromatic Done. 20:48
Are there any questions?
NotFound cotto_work queued 2
chromatic Just saw. cotto_work?
cotto_work While most gci contributions have been numous and of high quality, we've had some low-quality README translations. Does anyone who has experience with non-native English speakers (or who is one) know whether native-language READMEs will make people more likely to contribute to Parrot?
i.e. Do we want to continue to solicit README translations? 20:49
NotFound In the Spanish case, I don't think so.
Most Spanish able to contribute will use translations only for laugh at the errors or erratas. 20:50
mikehh also where should we put translations in the docs/html etc
kid51 mikehh: Why not in the same directory as README? 20:51
NotFound (in some cases, to endlessly discuss the more appropiate translation for any thecnical term)
(just look for librería/biblioteca in Spanish programming forum) 20:52
kid51 NotFound: My impression is that attitudes on this question differ both among different non-English languages and different speakers of a given non-English language.
mikehh could be, but what about any other translations
NotFound kid51: most probably, Spanish people (specialy in Spain) are peculiar in this matter. 20:53
20:53 allison joined
kid51 I think we can steer a middle path. 20:54
chromatic Could we make a blanket policy about the translation of technical terms, such as "always prefer the English term"?
kid51 chromatic: That will get you into trouble in France :-)
chromatic You can put me on record as not caring about the French Academy. 20:55
kid51 dukeleto suggested plunking down READMEs in branches for now
NotFound (not me, I talk like native americans in bad old westerns and I don't care)
whiteknight you mean Italians badly acting like native americans in bad old westerns 20:56
kid51 but, in any event, I think that unless we actually put some non-Anglo READMEs up on github somewhere, we won't get enough feedback to know what the best policy is
chromatic I agree with kid51.
kid51 We can add a request for patches to the translation at the bottom of each non-Anglo README.
NotFound whiteknight: no, even older westerns. Sergio Leone ones are more recent and are great!
whiteknight :) 20:57
cotto_work kid51: good idea. Let's go with that. 20:58
what about accepting future README translations?
kid51 If one of us thinks a *particular* translation is bad, we won't put it up. But if a reviewer says that a given translation is somewhat workable, let's post it.
whiteknight maybe we need a /translations/drafts/ folder to hold drafts of translations of things 20:59
Coke whiteknight: just use the wiki
kid51 whiteknight: Not a bad idea
whiteknight anything that hasn't passed muster from a native speaker is a draft and we use that as a hook to ellicit more contributions
kid51 whiteknight++
chromatic How do we know which native speaker to trust?
Coke (I also don't particularly want the top level to have 50 README.*'s)
kid51 Colleagues at $job is good starting point. 21:00
leverage people we know in worldwide Perl 5 et al communities
Even if, say, Parrot has no expert developers in Brazil, we certainly know Perl 5 people there. 21:01
21:01 lucian left
whiteknight if we end up with a really lousy translation of something, we'll find out when somebody comes to us and says "this translation is really lousy" 21:01
we have to trust the translator until somebody complains
kid51 I could get feedback on a dozen languages just by walking around the office. 21:02
whiteknight and then we ask the complainer to submit a patch
kid51 Not expert, but workable feedback.
mikehh we have various devs who speak languages other than english, they shoulkd look
NotFound mikehh: I don't feel good about asking for translations when I already know I'm going to reject them. 21:03
With 99.9% confidence. 21:04
kid51 NotFound: Then take yourself out of that loop. We can have other people review Spanish.
chromatic Any other discussion on this topic? 21:06
kid51 Not from me.
chromatic cotto_work, other questions? 21:07
21:07 bluescreen_ left
cotto_work Does anyone have burning questions about the Lorito braindump that I should be sure to address? 21:07
plobsing q1q
mikehh q1q 21:08
chromatic I suppose then... plobsing?
kid51 cotto_work: I don't want you to dumb-down your report on the braindump, but to the extent possible, make it accessible
cotto_work kid51: ok.
kid51 (meaning ... I have no clue as to what's going on there) ;-)
21:08 lucian joined
cotto_work for reference, do you think anything I've posted so far has been dumbed-down or is it appropriately dumb already. ;) 21:09
plobsing I've marked complex as deprecated. anyone object to this?
cotto_work q1q
kid51 no, it's just that whiteknight's posts had my brain spinning ... out of my league, I guess
mikehh plobsing: why would you want to do that?
cotto_work ok. If something's hard to grok, just post a comment and I'll clarify. 21:10
whiteknight kid51: Yeah, that post was off-the-cuff and high-level. I'll make it more accessible
cotto_work If anyone else has question, just post in #parrot with my nick. I'll make sure to find it.
eoq
plobsing mikehh: it doesn't get any love and it is full of bugs
kid51 plobsing: What would be the replacement if that were removed?
mikehh plobsing: then it needs to have someone review it 21:11
plobsing replacement: cook it up yourself (rakudo already does)
anyone who cares enough about complex to build it for their own purposes stands a much better chance of doing it right
or at least less wrong than us (that's a pretty low bar) 21:12
mikehh then we should incorporate the rakudo solution
cotto_work I think the point is that it's not useful as it stands and that it doesn't really belong in core.
whiteknight I'm happy to start a new project to hold Complex, and to maintain it
mikehh whiteknight: +1 21:13
whiteknight PLA depends on Complex, so either I can merge it into there or start it as a new project and use it as a dependency
cotto_work That sounds like an acceptable solution to me. Any objections to doing that after a deprecation cycle? 21:14
chromatic We can deprecate it and see who yells.
whiteknight +1
mikehh so how do you handle those bugs
whiteknight what bugs?
Coke ... correct order is to copy it /first/, then deprecate the in-place version.
mikehh in PLA I mean
whiteknight mikehh: I don't know, it will be a learning experience 21:15
cotto_work Coke: I think that's what's being suggested. if not, it should be.
chromatic Any other questions about Complex? 21:17
whiteknight yes, that's what I'll do. After embed_api2 is fixed and merged I will start a copy
cotto_work whiteknight: can you say as much in the ticket (trac.parrot.org/parrot/ticket/1892 )?
whiteknight yessir 21:18
chromatic mikehh, question?
mikehh what are we going to do about aloha - it's MIA as is bacek 21:20
whiteknight we're talking about that in #parrot right now
kid51 dare I say: bring back purl?
sorear +1 21:21
plobsing +1 # <3 purl
mikehh we kicked purl and aloha was supposed to be the replacement
whiteknight it appears to be easy enough to run our own copy of Aloha. We just need to set it up on feather or somewhere else
chromatic My preference is migrating aloha.
whiteknight +1
cotto_work +1
Coke aloha++
cotto_work feather is nice because anyone with access can fiddle as needed 21:22
whiteknight right, I like that
mikehh I think bacek has the code on github
whiteknight so let's try to get that set up this week
cotto_work any volunteers?
whiteknight I don't know if I have a feather account, but I can take a stab at it 21:24
chromatic cotto_work, do you have another question? 21:26
cotto_work I'd like to start a push to get packfiles PMCs working again and to increase the bus number on that code. Any volunteers to help with that?
I blogged about plobsing's changes, so the barrier to entry shouldn't be too high. 21:27
chromatic I can take a look after this week.
cotto_work thanks. Any other volunteers are welcome too. It's an important bit of code on the way to Lorito. 21:28
eoq
whiteknight I definitely want to get involved in that
whiteknight has to leave now. Just volunteer me for everything else that gets asked about :)
chromatic Any other questions?
21:28 whiteknight left
chromatic Let's call it a week then. Release next week! 21:31
cotto_work um.... go team!\\ 21:32
21:32 NotFound left, plobsing left, kid51 left 21:51 tcurtis left 21:55 atrodo left 23:22 whiteknight joined 23:23 lucian left 23:39 allison left 23:52 lucian 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!