Vision for 2.0: Production Users | Don't forget to post closed tickets in your report. | Note: This channel is only for our Tuesday status meetings; you probably want #parrot instead.
Set by moderator on 23 January 2010.
00:15 dduncan joined 00:28 dduncan left 01:09 cotto_w0rk joined 01:52 particle joined 08:10 particle1 joined 12:16 bluescreen joined
japhb DONE: Fixed Plumage smoke bug reported by fperrad++ 16:53
WIP: *Array reverse (TT 1416 opened re: pain of doing so) 16:54
NEXT: Algorithm::MiniSat, a prereq for doing dependency analysis 16:55
STATUS: Just getting tuits again
EOR
cotto_w0rk #did: 17:43
* fixed h2inc in one_make, helped get the branch in shape for its merge Monday evening (US Pacific time)
* added some diagnostic smarts to checkdepends.pl; its false positives are now much more transparent
* Coke suggested that pir files be compiled to pbcs and merged similarly to C (foo.c -> foo.o -> foo)
* This will make dependency checking more reliable and give pbc_merge some exercise during the build.
* broke the win32 build, fperrad++ for fixing it
* made pirc not asplode whenever someone reruns headerizer (sadly there was no tt for this)
#will do:
* change the build for pir code to be more C-like for better dependency tracking (i.e. generate intermediate pbc files)
* fix any legitimate failures that checkdepends finds and reduce false positives
* get back into improving profiling 17:44
#blockers:
* This space is intentionally left blank.
#closed TTs:
* none directly, but Coke++ got a couple as a result of the one_make merge
#eor:
* eor
q3q
18:14 NotFound joined
Util # Done 18:17
* Last minute testing of 2.0 release
= Which caused a needles delay, after I reported a test failure that turned out to be a laptop PCRE config issue. Mea culpa.
# Plan to: 18:18
* See whether our config process can easily spot the problem I had, and change config to report it.
# Blockers:
* $WORK == MAX_INT
.end
s/needles/needless/
NotFound What I did:
* Getting up to date after several weeks mostly disconnected.
* Minor fixes.
What I will do:
* No fixed plan.
EOR 18:19
mikehh What I did since my last report: 18:22
* building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
* branch testing
* some fixes
What I intend to do in the next week:
* testing and fixing
.eor
18:31 chromatic joined
chromatic Hello everyone. 18:32
cotto_w0rk hi
mikehh hello
Util Hello 18:33
NotFound hola
chromatic Let's review last week's goals. 18:35
We merged a couple of branches: one_make and OrderedHash cleanup.
We didn't get tt_389_fix; it's more complex than anyone thought.
The good news is that the right fix might fix inheriting from primitive types.
Any other goals we made? 18:36
18:36 dukeleto joined
chromatic Okay. Let's move on to goals for this week. 18:37
Util You got 2.0 released, doesn't that count?
chromatic Okay, success there too.
We have a lot in DEPRECATED. What can we pick from there? 18:38
How about moving core to dynpmcs and removing deprecated VTABLE entries? Anyone want to lead those? 18:39
cotto_w0rk I'll put TT 886 on my todo list 18:41
mikehh I'll work on it - I don't think I want to lead it though
chromatic mikehh, if you make a branch for each we can encourage everyone else to help you. 18:42
mikehh ok
chromatic We should also review our 2.3 goals, but let's do that next week after we've figured out when #ps should be for the next few months. 18:43
cotto_w0rk It's not a much fun as adding features but it needs to be done
chromatic I enjoy it, actually.
cotto_w0rk Is that a new topic?
chromatic The #ps time? How would everyone here feel about doing this an hour or two later? 18:44
Util "All bitwise ops" and "All bitwise VTABLE functions" are listed separately in DEPRECATED, but probably should be tackled together.
cotto_w0rk +1 to 2 or 3 hours later
dukeleto What I did:
* Added "Bail out!" and out of order test detection to Tapir
* Updgraded Plumage to the lastest Tapir
* Talked to people at www.buglabs.net/ (an embedded arm platform) about getting hardware so that Parrot can be ported. Sounds promis
ing. 18:45
* Starting to organize weekly PL/Parrot meetings, "PL/Parrot sketch" on Tuesdays (same day as #parrotsketch)
* Currently our agreed upon time is 4 hrs after #parrotsketch, i.e. 10:30pm GMT (2:30pm PST)
What I will do:
* Work on PL/Parrot and Tapir
Blocking on:
* Time to do stuff.
Util +1 to /[1234]/ hours later
dukeleto irc channel for PL/Parrot sketch is #plparrot on irc.freenode.net, btw
NotFound Fine for me either the current time or later
mikehh later is fine 18:46
dukeleto I vote for 1-3 hours later. I already took the 4 hrs later time slot ;)
Util dukeleto: PL/parrot is Postgres?
dukeleto Util: yes, Parrot in postgres, github.com/leto/plparrot
chromatic Okay, let's table the time discussion. 18:48
Let's go on to questions.
cotto_w0rk, you had three.
cotto_w0rk * As we're moving toward a release that will support a language (Rakudo *) that we expect will become widely used, should we have a dedicated non-public mailing list where major security vulnerabilities in Parrot can be reported and dealt with? 18:49
chromatic +1 18:50
dukeleto +1
Util +1 18:51
NotFound Did we already have some security?
cotto_w0rk Is Coke the go-to guy for that?
chromatic Coke is it.
cotto_w0rk NotFound, not yet.
dukeleto I would like to work on a security subsystem, something like en.wikipedia.org/wiki/Seccomp 18:52
NotFound So what may be the security problems?
cotto_w0rk dukeleto, we have a security pdd that needs implementing
docs/pdds/pdd18_security.pod
chromatic NotFound, a privilege escalation problem, a resource DOS, anything like that.
cotto_w0rk A policy about such things wouldn't be a bad idea either. 18:53
(unless I wrote it)
chromatic How about a wiki page with some thoughts? 18:54
NotFound A resource DOS is easy: just ask for a lot of memory and parrot dies. 18:55
cotto_w0rk ideally we'll get better about that
dukeleto cotto_w0rk: i would very much like to work on that. count me in
cotto_w0rk Can I count you in charge? I don't have much meaningful experience in that area. 18:56
dukeleto NotFound: some applications that are built on Parrot want fine-grained control over what system calls are allowed/etc
NotFound We need to document and implement a policy about that. Throw an exception instead of dying in big arrays resizing, and things like that,
dukeleto cotto_w0rk: sure, I will put another hat on
NotFound++
cotto_w0rk q2: Now that the date for YAPC::NA has been announced (June 21-23), are we going to plan for another Parrot workshop or dev summit? 18:57
NotFound dukeleto: yes, but that can be break when we have the security model. Now the discussion about that reduces to "Not implemented yet"
dukeleto +1 to another Parrot dev summit 18:59
chromatic Robert Blackwell has brought up the idea around PPW. I haven't heard anything about YAPC.
cotto_w0rk ok 19:02
chromatic I'll bring up the idea.
cotto_w0rk thanks 19:03
q3: Back in October we tabled discussion about moving to Git until at least post-2.0. Now that we're past 2.0, how does a migration (either soon or after 2.3/Rakudo *) sound? I've started a GitTransition wiki page to document the requirements.
chromatic Post 2.3 seems the earliest practical to me.
NotFound was still on the fence last I heard from him about it.
cotto_w0rk It can be brought up again then. 19:04
The wiki page will help in the meantime.
eoq
chromatic Other questions?
NotFound I still don't learned git, but if most people wants the switch, I'll do.
19:06 plobsing joined
chromatic Anything else to discuss? 19:06
cotto_w0rk chromatic, do you think it'd be a good idea for developers to edit that wiki page to indicate whether we're for or against an eventual transition once all the requirements are met?
Util cotto_w0rk: still pro-SVN here, but I should be pro-Git by 2.3. The Git Parable is helping.
dukeleto i will volunteer to do the git migration when we are ready
chromatic Instead of "for" or "against", how about "What I would need to feel comfortable switching"? 19:07
cotto_w0rk much better
NotFound A "Git for dummies" book ;) 19:08
dukeleto i just helped $work convert a *large* svn repo to git, so I have this stuff fresh in my mind
chromatic "Version Control with Git" worked for me. 19:09
I've heard great things about "Pro Git" as well.
dukeleto everyone can feel free to ask me git questions. Progit.org is a great resource
cotto_w0rk Where's the architect? 19:11
not here 19:12
eoq
chromatic Other questions?
Other puns?
Random (good natured) abuse?
cotto_w0rk (though I'm sure she'll review the logs)
plobsing if it were possible to make a runtime plugable frame builder, would this be desirable? 19:13
dukeleto plobsing: yes, +1. does making it pluggable make it a much larger task?
plobsing dukeleto: it makes additions to the component (eg llvm, libjit etc) much less critical 19:14
because you're not stuck with it
chromatic Do you mean program runtime or "The specific framebuilder isn't compiled into Parrot itself"? 19:15
plobsing either or really. I can see it being a separate dynamic library, which lets you change it without recompiling parrot 19:16
or you could load separate ones via loadlib 19:17
chromatic Pluggable sounds worthwhile, but we could merge this in stages.
dukeleto plobsing: i would say, the minimum amount of pluggability at first would be good. get a good working first-draft, then iterate on pluggability after a stable API has been decided 19:19
chromatic Yes, first get a framebuilder working, then merge, then make it pluggable, then merge, then.... 19:20
dukeleto i.e., i agree with chromatic. don't let pluggabilility slow down a first iteration too much
chromatic++
chromatic Is there anything else? 19:21
Okay, let's get back to work. 19:23
19:26 chromatic left 19:27 plobsing left 19:29 NotFound left 19:54 bluescreen joined 20:08 PacoLinux left 20:23 dukeleto left 21:01 japhb joined 22:54 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!