Recent blog entries for jefft

Apache 2.0 is GA... cool... lots of weird bug reports and a few really good ones (weird being funky user errors or system setup problems, good being a real bug that can be fixed)...

I'm playing with the iMac that "brown" brought today. It is a beautiful machine, and I'll be pleased as punch if I can get Apache to build on the first try (supposedly just a matter of patching the right Apple-provided libtool file). Apache is building in the background, I'm listening to "Lady Madonna", and ripping Kind of Blue. Of course I could do the same stuff on all those other operating systems, but it is nice to see something just work out of the box for a change. After playing with it for a few minutes this afternoon Sonya (my daughter) and I wanted to immediately order a couple more. This one is destined for my wife's desk upstairs and of course Sonya and I both "need" an iMac of our own. But maybe Sonya has changed her mind by now, because some software of hers was misbehaving under Classic. Oh, well. And I don't think I can print to the Epson C60 via lpr unless I pretend it is PostScript and set up GhostScript on the Linux box. Yuck. Lots of things to resolve.

We're about to head for a party but for the last few minutes I've been trying to get gphoto to talk to my new Kodak DC3200. It took a code change to the DC3200 support to get it to talk at all (some confusion about retrieved baudrate==0), and I haven't gotten it to list the available pictures yet.

The DC3200 isn't very sexy (1 megapixel, fixed focus/focal length lens) but I got it for 60US after rebate so I'm not complaining. It has only 2MB on-board, which is enough for only 6 shots at the highest resolution, so I've ordered a 64MB CompactFlash card. That should bring the capacity up to nearly 200 shots. I ordered a CompactFlash PCMCIA adapter as well (around 5.50US) so I'll be able to ditch the slow serial interface.

I just went looking for something on the internet and the first thing that popped up was my advogato diary page where I mentioned that I needed to look into that very issue. Not helpful :)

whew... I've been playing with Apache 2.0 on AIX for several weeks straight now... almost learning enough about AIX shared objects/libraries to figure out why libtool does what it does and what needs to be done differently for Apache... luckily there are some good people at work to help out :)

I got 64-bit Apache 2.0 serving pages on AIX today but had to disable send_file() usage to do so. Something weird going on as I always get back EINVAL from send_file()... dunno yet... some nice chap in Austin is bound to help me out...

so many little details left... hit a compile failure with 64-bit compiler in anal mode... seems we're not including time.h in mod_mime_magic for the ctime() declaration... but guess what... we shouldn't be calling ctime() anyway in that place (I think that is request processing code) cause it ain't thread safe... a sane APR interface would be nice (probably already is one; I gotta check)... so I'm glad it didn't compile :) somebody put a little XXX there already (eons ago) but we forgot about it...

what else... more export file problems just now noticed because I don't use DSOs enough... differs between an AP_DEBUG build and !AP_DEBUG... gross...

must get sleep... must help clean the house... (nah!)

Hey, we finally got another Apache 2.0 beta out! Cool! I was starting to wonder if it would ever happen. And not a moment too soon... Now if people will just start fixing the remaining bugs for us :)

There are still plenty of things to polish. AIX in particular is a platform I haven't used too much for Apache 2.0 development, and I think that's a shame. I've been around a great deal of AIX knowledge lately and have gained a new appreciation for the platform. There are serious tools for debugging programs, and finally with 5L there is an easier-to-use system trace facility (truss). The existing AIX trace facility has a lot more detail and can be applied to many more problems, but it takes some getting used to.

For the nth time I browsed around the web looking for info on the truerand library, which is the backup random number generator for aprlib and is used on systems without /dev/random. Unfortunately, truerand doesn't appear to work with threads or with programs which use SIGALRM. Perhaps APR should refused to use truerand if APR is built with thread support.

Several Unix platforms actively supported by Apache/APR don't have /dev/random: AIX, Solaris, Tru64, HP-UX, and OS/390 are among them. I don't know if real programs use truerand or if these platforms have routines in their native libraries which are reasonable.

There's always plenty to do...

As sometimes happens, I got up this morning and found apache regression test failures from one machine or another. Today it is AIX. The threaded MPM won't compile anymore with xlc. It has to do with the non-AP_DEBUG flavor of cmd_func. I don't see that any code changed. Maybe --enable-maintainer-mode used to get AP_DEBUG defined even with xlc but not anymore because of configuration changes. Maybe this is goodness since we shouldn't require AP_DEBUG to be defined in order for it to compile with xlc. At least the coffee tastes good. [Update: We're using the AP_DEBUG flavor unexpectedly. The AP_DEBUG flavor of the cmd_func declarations is not portable. Last night Roy removed the check for gcc before turning on AP_DEBUG. Interestingly (or not :) ) the AP_DEBUG flavor of cmd_func compiles cleanly on gcc but the non-AP_DEBUG flavor doesn't. The non-AP_DEBUG flavor compiles cleanly with Tru64 cc and AIX xlc but the AP_DEBUG flavor doesn't. (On Tru64 we get a bunch of warnings with the AP_DEBUG flavor but at least it compiles; the same cannot be said of AIX xlc.)]

Instead of spending most of my spare time hacking on Apache lately I've been messing around at a house we just bought. I've been working on cleaning up the yard and fixing some drainage problems around the house. Next comes reworking the electrical line to the workstop. Other projects on the short list include putting GFCI sockets in the bathrooms, adding an exhaust fan in the master bath, replacing some light fixtures, upgrading the phone lines to support 2 lines + 100Mbps LAN, etc. The biggest problem for me with all this is overcoming the paralysis associated with the risk of making things worse. When I screw up badly I can't simply remove a damaged wall and let "cvs update" get me back to where I started.

The guys doing the painting and refinishing the floors still have a couple of weeks to go, after which we can move in and it will be easier to work on these projects.

Time to shut up and get to work... Liam will wake up any minute now and I need to look at the AIX+xlc problem before that happens. Also, I've got some updates to look at from David Reid for the libtool emulator we have for BeOS and OS/390.

(Trying again after hitting the wrong key in netscape and losing it all! I'll try to remember the gist of it.)

I like reading diary entries, but it would be nice to have a view of diary entries just from folks associated with specified projects. It can be fun to read random diary entries, but it is truly useful to read entries from other folks working on Apache. I don't know of an effecient way to get to such entries.

We communicate all the time on mailing lists, but these diary entries give a different angle on the person and what they are doing. We don't exactly clutter up the mailing list with drivel like this.

At the moment I'm working on replacing the BO_BYTECT usage... It is trivial to improve on the current situation (BO_BYTECT usage is broken since we use buff for so little of our data transfer now), but it is non-trivial to match the same semantics of BO_BYTECT in 1.3. With 2.0, output data can be held at any filter... With 1.3, output data is either held in buff or has already been sent, so it was trivial to account for it either way.

(Uninteresting details, huh?)

I've been trying to assist David in his efforts to add IPv6 and UDP support to APR by reviewing patches. I hope I haven't held him up too much. I realize that I've been a pest :)

Okay, time to press the button and go get Sonya ready for school (stealing some hot coffee along the way)...

I'm letting the caffiene sink in and wondering what to work on this a.m. and I log into my BSD box to make sure Apache 2.0 regression tests are still humming and I notice that the configure script started failing at 2:18 a.m. EDT. I wonder if that would have anything to do with some commits last night :) There was a commit right before the previous successful BSD regression build/run and a commit right afterwards. It looks like there is autoconf/m4 debugging to do this a.m. because the configure script bails out. (I would guess initially that it wasn't broken by rbb's commit last night. It seems that APRVARS stopped getting built at the right time at some point in the last few days.) But first to get Sonya to school...

Apache 2.0 thoughts of the moment:

Nagging question of the week: why doesn't 2.0 run smoothly on FreeBSD 3.4 for me?

Old observations from a couple of weeks back: mpmt_pthread and prefork seem to run fine; dexter hangs intermittently in select(), which never pops even though one or both conditions (readability, timeout) have been met; I imagined that there was some sick interaction between Apache and the FreeBSD user-land thread implementation

New observation: various flavors seem to hang intermittently in unknown code; truss refuses to attach to any of the children; more data required

Other issues to work on before too long:

• ab needs to do the connect() in non-blocking mode
• Commit fix to ap_sendfile() for when no header/trailer structure is provided.
• Get ap_sendfile() working with APR_SO_TIMEOUT.
• Test a few MPM flavors on Solaris x86 and OS/390; I haven't played there since returning from the beach.

Other silly stuff:

• Advagato: How do I add myself to list of developers associated with the Apache project?
• Real life: Figure out why Liam doesn't want to go to sleep at night; this is spoiling my favorite coding time :)