Stuart Herbert | Gentoo

I’ve been playing about with using PDO to work with mysql. Something’s not quite right in there, and it’s resulting in a segfault when I run some local unit tests.

I’m not all that hot on PHP’s internals; I only tend to go digging in there when work needs a runkit bug diagnosing and fixing. But I’m pretty sure that what I’m seeing needs some TLC.

PDO objects themselves are created and destroyed when I’d expect them to be, as the objects go out of scope. The problem is that the PDOStatement objects aren’t doing the same. According to gdb, PDOStatement objects are only getting cleaned up when php_request_shutdown() runs; never before.

Surely we should be seeing PDOStatement objects being destroyed before their corresponding PDO object? The segfault is happening because php_mysql_stmt_dtor() is calling mysql_more_results() after the PDO object has been destroyed. We’re passing garbage data into the mysql client library … which chokes and segfaults as a result.

I think there’s two bugs here. The first problem is that PDOStatement objects appear to be persisting even though they’ve gone out of scope. php_pdo_stmt_delref() only gets called during php_request_shutdown(), never before. That doesn’t seem right to me. Why aren’t PDOStatements being destroyed when they go out of scope?

The second problem is that PDO objects are being destroyed before their corresponding PDOStatement objects. I couldn’t find (or, most likely, I didn’t recognise it any code that handles reference counting between PDO and PDOStatement objects. Maybe I’ve got it wrong, but I’d expect PDOStatement objects to add/subtract the corresponding PDO object’s reference counter, to ensure that PDO objects don’t get destroyed until all of their PDOStatement objects have been destroyed.

Anyone else got an opinion on this?

There’s growing interest in a recent DistroWatch.com article, where they’ve started asking reasonable questions about whether or not Gentoo is in trouble. Folks (including Gentoo devs, alas) are hammering DistroWatch for the article, but tbh I think they need to look closer to home.

If you’ve got a bunch of folk, known to be associated with Gentoo, making statements about how they’re quitting over this, that, and the other, then expect to see articles like the DistroWatch article appearing on the ‘net. Couple that with blogs complaining about things and public fights on -dev, and it doesn’t paint a pretty picture.

Then, imagine you’re outside Gentoo, and all you get to hear from the Gentoo project is stuff like the above. We know that it’s only a small part of the Gentoo story, but right now it’s the only part that anyone gets to hear about. It’s inevitable that folks outside Gentoo are going to be feeling that we’re only giving off a doom and gloom vibe.

They’ve got nothing else to tell them otherwise. Gentoo (as a project) needs to start getting its own message out there. Otherwise the vaccuum that’s left will inevitably fill with stuff like this.

Kristi and I have just come back from the lovely town of Skien, Norway, attending the php|vikinger event organised by Zak Geant. It’s the first time I’ve attended an event like this, and I thought that Zak did a good job of running the unconference with the mighty power of Thor.

It was great to meet Sebastian for the first time, and to pick his brains about PHPUnit test suites. I confess I spent most of the weekend hacking away on my tests, rather than actively joining in the sessions; I now have unit tests for most of my Datastore PHP library. Need to track down and fix a PDO segfault, but otherwise it’s getting to the point where it’s actually useful. I hadn’t seen Hartmut’s PECL_Gen package before; I’m looking forward to when it can throw exceptions back into PHP (grin).

If you’ve never been to Norway before, it’s well worth the trip … especially if (like me) you’re used to how dirty and grey the UK can be. Don’t worry if you don’t know enough Norwegian. I think we met just the one person who didn’t speak English, and we’re pretty sure they were tourists too!

I’m participating in the Google Summer of Code this summer … not as a student (crikey, it’s been 12 years now since I graduated from the University of Sheffield - where does the time go?) but as a mentor. It’s my honour to be a mentor to Anant Narayanan, the most in-demand student involved in this year’s Summer of Code (as reported by Gentoo Weekly News).

No pressure, eh?

I thought it would be useful to share some thoughts about being a mentor. I haven’t seen a lot of discussion about mentoring within SoC; hopefully this’ll spark some off.

Mentors have an interesting position of responsibility. On the one hand, we’re responsible for the SoC student(s) who we’re looking after. On the other, we’re also responsible for ensuring that our organisation (Gentoo in my case) get the most out of the student’s work. Or, as they say in US armed forces officer training, nothing is as important as the man, and nothing is as important as the mission.

First and foremost, whether it’s SoC, Gentoo’s Social Workspaces, the workplace, the dojo, or whatever, it’s a student that “does”, not the mentor. Nobody ever learns anything if they feel that they cannot “do”. It’s essential for the student to feel that they have permission to “do”. As children (and for some of us, this carries on through adult life too), we learn by play, by “wouldn’t it be fun if …”.

Secondly, students need appropriate feedback. No-one can learn without feedback. Students who are participating in the SoC in particular have the expectation of great feedback from their mentor. But what is appropriate feedback? It’s closely tied in with what I feel is the third most important aspect of mentoring.

If you look at requests for feedback from students, it nearly always comes in the form of a question. A student will stop what they are doing, and ask “How was that?” Or maybe they’ll stop what they are doing, and ask “Why is it done that way?” Or maybe they’ll stop what they are doing, and ask “What if I did it that way instead?” Overwhelmingly, the two common denominators are that they ask a question, and that the question is stopping them from “doing”.

My third point about mentoring is that students always have a question that they want answered, but that they haven’t asked. Sometimes, it’s on the tip of their tongue, but they need an answer to their first question before they feel safe to ask it. Sometimes, it’s the question at the back of their mind that’s actually prompted the question that they have asked. Being able to identify what the “unspoken question” is, and to answer it for the student, is a great skill for a mentor to develop. In my experience, it’s the secret to making a student feel like they’re the only person in the room, and that they have you complete attention.

But how should you answer a question? Here, I want to introduce another tool for mentors, which I call the Frame of Reference. The Frame of Reference is what links a mentor’s description with a student’s understanding. Think of it as a situation that both mentor and student have the same understanding of. If you have a shared understanding, you’re able to explore it together, because both mentor and student really are talking about the same thing. Without that shared understanding, mentor and student are actually talking at cross-purposes; at best the student only gets a bit of understanding, and the bits that he gets will be by accident. That’s not good mentoring!

In order to answer a question, the mentor has to find a common frame of reference with the student. This is a trial and error process. My own teacher, Robert Earl Taylor, is always telling me that the secret is to keep trying to find a completely different way to explain something. For any given topic, many mentors only have the one way for explaining something. If the student doesn’t “get it”, the mentor will go back over the same thing the same way time and time again until either it sinks in or the student switches off. Which do you think comes first? It’s normally that the student switches off

Providing feedback, and answering questions, leads me nicely to the last point that I feel is important. You have to allow your students to fail if they are to learn. You can’t wrap them up in cotton wool and ensure that everything they do is safe and sanitised. As a mentor, or a leader in business, failure-avoidance is a worthy principle, but it’s too often applied through micro-management.

Part of the fun - part of the permission that students need if they are to “do” - is to make decisions for themselves, and to give new things a go. If you get the balance wrong, and take all that away from them, then what’s left is the student trying to be a parrot, and trying to copy whatever it is he thinks you want.

And when that happens, the student’s results will merely reflect the very worst of your own opinions, instead of the very best of the student’s own capabilities.

Perforce is a great product, and their people were very kind to me back in the 90’s when I needed a VCS for NQS, but since I switched to using Subversion, I simply don’t use Perforce any more. No-one has volunteered to take over maintaining Perforce any more, so this morning I removed it from the tree.

The packages can now be found in my personal overlay, just in case there’s a Gentoo user who’d like access so that they can learn how to maintain them. If you’re interested, come and talk to me in #gentoo-php or #gentoo-overlays on irc.freenode.net.

I’ve disabled write access to the Gentoo PHP Overlay for the moment. We’re moving the site to the new Gentoo Overlays box soon.

I’ll announce the new address once everything is up and running.

Gentoo Overlays is a project designed to bring social workspaces to Gentoo. We’ll provide a place for Gentoo projects and developers to host their overlays, and the support required for Gentoo users to contribute to the overlays.

Can anyone help us by creating us a logo similar to that used by the Gentoo Forums? If you can, drop by #gentoo-overlays on irc.freenode.net, and let us know!