Send me a receipt and you can have your money back.

Yes, that's about it.

Dave and Nicholas are not full time employees, but contractors. Nick's primary work, at least, is his work for TPF. He does not have a manager (in the usual sense) or office mates or status as a full time employee. I don't think TPF is really set up to have full time employees like that, at present. One way to think about this is, "If TPF was going to hire a full time programmer, who would do the hiring and managing?" Instead, they have exceptional status as holders of only somewhat focused long-term grants. I'll write more about that. The question of disincentive goes something like this: "If 'They' are willing to pay for Bob's project to get done, why should I do my project for free? I'll see if I can get it funded, and if not, maybe I'll just go swimming."

I am still using and enjoying TO, and still feeling sort of frustrated by it. I respect the effort it must have taken, so I would like to write up a more complete analysis in a future (soon!) blog post and let you know when I've done this. Thanks for asking!

I think it addresses a problem, but not the one that generating subs from concatenated strings is a pain.

I'm using Tabs Outliner, without having tried Sidewise. It seems to do the things I want, but not very well. Its UI is sort of a mess, and really needs to make more sense. But it does okay.

I think the main nastiness is that it moves most programmers from something they're more used to (writing pieces that are composed by calling) into something they are not used to: composition by concatenation. It doesn't help, either, that the things being concatenated are strings rather than abstract syntax trees. The kinds of bugs that will arise, and the kinds of tricks and mistakes to avoid, are weird and foreign to most programmers. It can get into the realm of "if you wrote the code as cleverly as you can, you are by definition not smart enough to debug it." It's not always wrong, it's just, let's say, discomfiting.

How does this look as a start? https://gist.github.com/4664573

You'll see gfind tested clumsily in my git repo's script and results. While it may yet be more optimizable than is seen there, those results show that it's fine, but slower than most of the faster pure Perl options. I did not attempt to tune it very hard.

link added in updated: https://github.com/rjbs/perl-file-finder-speed

No. My assumption was that the faster libraries would be more optimized than that, and I would never write the opendir/readdir tree processing in my own code, so it didn't seem a useful comparison.

I didn't test find. Why not! The y-axis labels are picked by the chart library. If I regenerate the chart later, I'll set them manually. Mostly, the important thing to know is that they're linear.

The current colors are unfortunate. It is File::Find::Rule which is unaffected by count, for reasons spelled out in the post: it always gets all results, even if you will only fetch ten of them.

Right now there is no special facility for one-offs. You could simply make a consumer (a service) that issued a $10 charge that it would consume immediately upon being paid, and then set up no replacement. This wouldn't be too gross. It would be easier to do one-off charges if it weren't for the fact that all line items are owned by a consumer. At any rate, the "charge a fraction of my cost over a period of time" is only *one* profile of funds use. For example, we have consumers which consume all their money up front but then last until a preset date or event. Others use up money only when the service associated with them is used. I could imagine making one consumer (with no replacement) per customer order, which would consume its money all at once once the shipment system marked the order fulfilled. The scaling problems of Moonpig are not yet well-addressed, but it fits our scale. The most serious problem is that its sole storage implementation is quite naive, and should be replaced with something more like KiokuDB.

Charging against accrued revenue (daily) was one of the major motivators and design constraints for Moonpig. It's quite easy to create a type of service that uses all its money at once, but mostly we charge $20 up front and then drain your balance at about 5¢ per day. Given that a day of service is 5¢, we don't sweat the problems you note, but I think it balances out anyway. We send heartbeat events roughly daily, so if you're activated after the daily heartbeat, your final deactivation will be a day later than had you been activated before it. But it gets easier, I guess: 1. Say your service is supposed to charge 1¢ daily, but for some reason it doesn't get a heartbeat for a week. When it gets it, it will say, "Gosh, I haven't charged in seven days!" Then it will charge 1¢ seven times to catch up. 2. The "1¢ per day" isn't a fixed thing. It's actually "{D} monetary units per {S} seconds of total lifetime divided into {C} long chunks." So our usual $20/year service has D = $20, S = 1yr, C = 1d 3. ...so we could keep D and S the same, but change C to 1h. Then each heartbeat it would charge for all the hours it had missed, and you'd be able to have expiration times accurate to the hour, and you wouldn't terminate early, only slightly late, depending on how often you sent heartbeat events.

My understanding of multipoint was that the stereo profile would connect to one device and the monaural to another device, and that was roughly it. Perhaps I should revisit the documentation.

Yeah, for the sake of anybody else reading this, the problems I have are all with the generics of using a headset with two devices. The headset itself is really, really nice. I'm hoping that iOS 6 at least helps me switch band and forth faster.

Yup, New Street!

The omakase was good, but nothing to feel too burned about missing. The company greatly outshone the food. There was some very nice yellowtail, and I thought the spicy broth for the crispy duck ramen was surprising, but mostly it was merely good. The place we went for sushi in 2006 or so was the best. Next year's restaurant agenda includes: VQ, Le Pigeon, Beast, Teardrop.

That's now how things work. The perl5-porters list is not comprised of people who are funded to work on whatever goes into core. In fact, as far as I know, there are no PPI experts on perl5-porters, because there are basically no PPI experts other than Adam, who is largely unavailable for Perl work these days. Putting something into core does not mean it will get any more or less maintenance than anything else. It just means that perl will become harder to release when tests break. 5.16.1 is coming, pretty soon. 5.14.3 will come a while after that. There was insufficient interest in backporting any of the very minor tweaks that had been brought up for it. A few patches from Debian, at least, will be in 5.14.3.

Very exciting, thanks!

Cool! The one in the airport was basically adequate airport food. It's good to hear that the original is better. :)

The state of bug reporting for perl5 is definitely not ideal, and we're working on ways to improve it. I'll look into your specific problem. In the meantime, forward your bug report to me or to perl5-porters@perl.org Thanks!

bigfloat.pl will not come with perl 5 anymore, but it isn't going to go away or stop working. It's on the CPAN, and you can install it on your 5.16 install if you still need it easily with "cpan Perl4::CoreLibs" http://search.cpan.org/~zefram/Perl4-CoreLibs-0.003/lib/Perl4/CoreLibs.pm I don't understand your pack/unpack problem. Can you supply a simple example of a program that doesn't do what you expect?

The campaign is more influenced by the introduction than the body, kinda. That is, the chaotic/insane period is (kinda, mostly) in the past.