Perl 6 - the future is here, just unevenly distributed

IRC log for #parrotsketch, 2010-01-26

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:15 dduncan joined #parrotsketch
00:28 dduncan left #parrotsketch
01:09 cotto_w0rk joined #parrotsketch
01:52 particle joined #parrotsketch
08:10 particle1 joined #parrotsketch
12:16 bluescreen joined #parrotsketch
16:53 japhb DONE:  Fixed Plumage smoke bug reported by fperrad++
16:54 japhb WIP: *Array reverse (TT 1416 opened re: pain of doing so)
16:55 japhb NEXT: Algorithm::MiniSat, a prereq for doing dependency analysis
16:55 japhb STATUS: Just getting tuits again
16:55 japhb EOR
17:43 cotto_w0rk #did:
17:43 cotto_w0rk * fixed h2inc in one_make, helped get the branch in shape for its merge Monday evening (US Pacific time)
17:43 cotto_w0rk * added some diagnostic smarts to checkdepends.pl; its false positives are now much more transparent
17:43 cotto_w0rk * Coke suggested that pir files be compiled to pbcs and merged similarly to C (foo.c -> foo.o -> foo)
17:43 cotto_w0rk * This will make dependency checking more reliable and give pbc_merge some exercise during the build.
17:43 cotto_w0rk * broke the win32 build, fperrad++ for fixing it
17:43 cotto_w0rk * made pirc not asplode whenever someone reruns headerizer (sadly there was no tt for this)
17:43 cotto_w0rk #will do:
17:43 cotto_w0rk * change the build for pir code to be more C-like for better dependency tracking (i.e. generate intermediate pbc files)
17:43 cotto_w0rk * fix any legitimate failures that checkdepends finds and reduce false positives
17:44 cotto_w0rk * get back into improving profiling
17:44 cotto_w0rk #blockers:
17:44 cotto_w0rk * This space is intentionally left blank.
17:44 cotto_w0rk #closed TTs:
17:44 cotto_w0rk * none directly, but Coke++ got a couple as a result of the one_make merge
17:44 cotto_w0rk #eor:
17:44 cotto_w0rk * eor
17:44 cotto_w0rk q3q
18:14 NotFound joined #parrotsketch
18:17 Util # Done
18:17 Util * Last minute testing of 2.0 release
18:17 Util = Which caused a needles delay, after I reported a test failure that turned out to be a laptop PCRE config issue. Mea culpa.
18:18 Util # Plan to:
18:18 Util * See whether our config process can easily spot the problem I had, and change config to report it.
18:18 Util # Blockers:
18:18 Util * $WORK == MAX_INT
18:18 Util .end
18:18 Util s/needles/needless/
18:18 NotFound What I did:
18:18 NotFound * Getting up to date after several weeks mostly disconnected.
18:18 NotFound * Minor fixes.
18:18 NotFound What I will do:
18:18 NotFound * No fixed plan.
18:19 NotFound EOR
18:22 mikehh What I did since my last report:
18:22 mikehh * building and testing parrot on amd64/i386, with gcc/g++, with and without --optimize
18:22 mikehh * branch testing
18:22 mikehh * some fixes
18:22 mikehh What I intend to do in the next week:
18:22 mikehh * testing and fixing
18:22 mikehh .eor
18:31 chromatic joined #parrotsketch
18:32 chromatic Hello everyone.
18:32 cotto_w0rk hi
18:32 mikehh hello
18:33 Util Hello
18:33 NotFound hola
18:35 chromatic Let's review last week's goals.
18:35 chromatic We merged a couple of branches: one_make and OrderedHash cleanup.
18:35 chromatic We didn't get tt_389_fix; it's more complex than anyone thought.
18:35 chromatic The good news is that the right fix might fix inheriting from primitive types.
18:36 chromatic Any other goals we made?
18:36 dukeleto joined #parrotsketch
18:37 chromatic Okay.  Let's move on to goals for this week.
18:37 Util You got 2.0 released, doesn't that count?
18:37 chromatic Okay, success there too.
18:38 chromatic We have a lot in DEPRECATED.  What can we pick from there?
18:39 chromatic How about moving core to dynpmcs and removing deprecated VTABLE entries?  Anyone want to lead those?
18:41 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
18:42 chromatic mikehh, if you make a branch for each we can encourage everyone else to help you.
18:42 mikehh ok
18:43 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
18:43 chromatic I enjoy it, actually.
18:43 cotto_w0rk Is that a new topic?
18:44 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.
18:44 cotto_w0rk +1 to 2 or 3 hours later
18:44 dukeleto What I did:
18:44 dukeleto * Added "Bail out!" and out of order test detection to Tapir
18:44 dukeleto * Updgraded Plumage to the lastest Tapir
18:44 dukeleto * Talked to people at http://www.buglabs.net/ (an embedded arm platform) about getting hardware so that Parrot can be ported. Sounds promis
18:45 dukeleto ing.
18:45 dukeleto * Starting to organize weekly PL/Parrot meetings, "PL/Parrot sketch" on Tuesdays (same day as #parrotsketch)
18:45 dukeleto * Currently our agreed upon time is 4 hrs after #parrotsketch, i.e. 10:30pm GMT (2:30pm PST)
18:45 dukeleto What I will do:
18:45 dukeleto * Work on PL/Parrot and Tapir
18:45 dukeleto Blocking on:
18:45 dukeleto * Time to do stuff.
18:45 Util +1 to /[1234]/ hours later
18:45 dukeleto irc channel for PL/Parrot sketch is #plparrot on irc.freenode.net, btw
18:45 NotFound Fine for me either the current time or later
18:46 mikehh later is fine
18:46 dukeleto I vote for 1-3 hours later. I already took the 4 hrs later time slot ;)
18:46 Util dukeleto: PL/parrot is Postgres?
18:46 dukeleto Util: yes, Parrot in postgres, http://github.com/leto/plparrot
18:48 chromatic Okay, let's table the time discussion.
18:48 chromatic Let's go on to questions.
18:48 chromatic cotto_w0rk, you had three.
18:49 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:50 chromatic +1
18:50 dukeleto +1
18:51 Util +1
18:51 NotFound Did we already have some security?
18:51 cotto_w0rk Is Coke the go-to guy for that?
18:51 chromatic Coke is it.
18:51 cotto_w0rk NotFound, not yet.
18:52 dukeleto I would like to work on a security subsystem, something like http://en.wikipedia.org/wiki/Seccomp
18:52 NotFound So what may be the security problems?
18:52 cotto_w0rk dukeleto, we have a security pdd that needs implementing
18:52 cotto_w0rk docs/pdds/pdd18_security.pod
18:52 chromatic NotFound, a privilege escalation problem, a resource DOS, anything like that.
18:53 cotto_w0rk A policy about such things wouldn't be a bad idea either.
18:53 cotto_w0rk (unless I wrote it)
18:54 chromatic How about a wiki page with some thoughts?
18:55 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
18:55 dukeleto cotto_w0rk: i would very much like to work on that. count me in
18:56 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
18:56 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,
18:56 dukeleto cotto_w0rk: sure, I will put another hat on
18:56 dukeleto NotFound++
18:57 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"
18:59 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.
19:02 cotto_w0rk ok
19:02 chromatic I'll bring up the idea.
19:03 cotto_w0rk thanks
19:03 cotto_w0rk 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.
19:03 chromatic Post 2.3 seems the earliest practical to me.
19:03 chromatic NotFound was still on the fence last I heard from him about it.
19:04 cotto_w0rk It can be brought up again then.
19:04 cotto_w0rk The wiki page will help in the meantime.
19:04 cotto_w0rk eoq
19:04 chromatic Other questions?
19:04 NotFound I still don't learned git, but if most people wants the switch, I'll do.
19:06 plobsing joined #parrotsketch
19:06 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?
19:06 Util cotto_w0rk: still pro-SVN here, but I should be pro-Git by 2.3. The Git Parable is helping.
19:06 dukeleto i will volunteer to do the git migration when we are ready
19:07 chromatic Instead of "for" or "against", how about "What I would need to feel comfortable switching"?
19:07 cotto_w0rk much better
19:08 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
19:09 chromatic "Version Control with Git" worked for me.
19:09 chromatic I've heard great things about "Pro Git" as well.
19:09 dukeleto everyone can feel free to ask me git questions. Progit.org is a great resource
19:11 cotto_w0rk Where's the architect?
19:12 cotto_w0rk not here
19:12 cotto_w0rk eoq
19:12 chromatic Other questions?
19:12 chromatic Other puns?
19:12 chromatic Random (good natured) abuse?
19:12 cotto_w0rk (though I'm sure she'll review the logs)
19:13 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?
19:14 plobsing dukeleto: it makes additions to the component (eg llvm, libjit etc) much less critical
19:14 plobsing because you're not stuck with it
19:15 chromatic Do you mean program runtime or "The specific framebuilder isn't compiled into Parrot itself"?
19:16 plobsing either or really. I can see it being a separate dynamic library, which lets you change it without recompiling parrot
19:17 plobsing or you could load separate ones via loadlib
19:17 chromatic Pluggable sounds worthwhile, but we could merge this in stages.
19:19 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:20 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
19:20 dukeleto chromatic++
19:21 chromatic Is there anything else?
19:23 chromatic Okay, let's get back to work.
19:26 chromatic left #parrotsketch
19:27 plobsing left #parrotsketch
19:29 NotFound left #parrotsketch
19:54 bluescreen joined #parrotsketch
20:08 PacoLinux left #parrotsketch
20:23 dukeleto left #parrotsketch
21:01 japhb joined #parrotsketch
22:54 Whiteknight joined #parrotsketch

| Channels | #parrotsketch index | Today | | Search | Google Search | Plain-Text | summary