« July 2003 | Main | September 2003 »
August 28, 2003
BLOB support for PHP
For those who haven't been paying attention today to the PHP mailing lists, I broke the build, or at least those that follow and use the ODBC extension by default (*cough* Windows *cough*). Why did I break the build?
The patch provided by Clara Liu was supposed to add/simplify BLOB support within PHP's current architecture. The catch (there's always a catch) is that there is no default data type for a BLOB in ODBC. As such, Clara decided to emulate BLOB behavior via a SQL_LONGVARBINARY type, which should work just fine. The build problem showed it's ugly face when the patch she sent expects a #define for a type of SQL_BLOB that just does not exist on the 3 major driver managers I support (iODBC, unixODBC, and Windows).
There are two options to fixing this that I see, but I do need people to test them.
The first patch simply adds in a "#define SQL_BLOB SQL_LONGVARCHAR" to the system and hopes all is right.
The second patch removes the use of the word SQL_BLOB as a case type, and hopes that REGISTER_LONG_CONSTANT will properly convert a SQL_BLOB over to a SQL_LONGVARBINARY.
Any testing of these patches would be appreciated since I cannot test them currently. As always comments and feedback are looked upon fondly. Email, comments, and trackbacks all work very well.
So why did I commit this basically untested patch? To get it tested first off. I had a handful of people claiming it worked great for them, but they were all limited to the same DB types and this patch needed further testing. Many of those wanting to test were Windows users without compilers, and as such the only way to enable their testing was to give them a snapshot. Seeing as I have now Windows machine around me, this was my best option. I don't have much hope that these current patches will even be tested, but I could be proven wrong.
On another note, if none of this works I'll abandon the attempts to make this work.
Posted by Dan at 03:16 PM | Comments (2)
August 27, 2003
kansas bound simon
Congratulations must be given to Simon who has apparently made it stateside for a job. Too bad it's in Kansas, a bit far. If you end up towards the east coast let me know.
Posted by Dan at 07:04 AM | Comments (1)
August 26, 2003
customer service
I've complained in the past about the quality of the reception on my TiBook, and even pointed out a great little extension hack to increasing the quality. I finally decided to pick up an external antenna, in the hopes of making my life a little easier. After looking around, I discovered Small Dog Electronics was selling the antenna whip. Being a fan of small businesses and having had heard good things about Small Dog, I decided to buy from them. It was back ordered, and I really didn't think twice about it.
On August 19 I received an email informing me that the Debit Card I purchased with was not being authorized to send to either address I gave them (billing/shipping) and asked that I verify my addresses with the issuer of the card. Immediately I called up the bank that issued the card, confirmed that my proper address was there (the Billing address given to Small Dog) on file, and that the shipping address would not be a problem. I send back a response detailing my conversation with the bank and do not hear anything further. I also called at the time to leave a voice message, because sometimes talking to someone on the phone will help clarify things quickly.
A few days go past, and I call again to checkup on the status, only to find that no one (again) answers the phone. I leave a second message to a general mailbox rather than the specific mailbox of the person I"ve been in contact with. On Aug 25th I received another email stating that they still cannot resolve the credit card issue, and that I should check with my issuer again. I call my bank again, and once again verify (with a different person) that the information is correct. This representative went so far as to claim that this must have been a problem on their end and that they should check their equipment. I called the home base of Small Dog once again and received no answer from anyone. I left yet another voice mail but for some reason my hopes are not high.
The question becomes has anyone else had such horrible experiences with Small Dog, or is this just an extremely rare case of cluelessness? Right now I'm about to just say cancel the order, and go with a group I've never heard of.
Posted by Dan at 01:05 PM | Comments (0)
August 25, 2003
junkyard wars
I discovered today that I am a mere 2 steps away from Junkward Wars fame! I am connected to Red Captain Doctor Crash via a previous coworker. Seeing how this is one of the more interesting and exciting shows on TV (at least for me), I'm rather excited about this find. I was told a story where Crash tried to use a acetylene torch to cook lobster. A true hero in my book.
Posted by Dan at 01:19 PM | Comments (0)
August 21, 2003
Virii
I'm not sure what's worse in the whole process:
Knowing that there are sysadmins and people out there ignorant enough to not protect their Windows boxes from the onslaught of viruses and hack attempts,
or
The fact that all these STUPID mail attachment scrubbers insist on informing me that the email "I" sent has a virus attached to it. You would think the mail scrubbers would realize by now (because this certainly isn't the first time a Windows virus has done this) that these emails are not from me or a mailing list, and just not send this moronic "informative" message. I've had to delete 98723927492732 of these today alone. I think that traffic alone causes more of an internet slow down then the movement of the virus.
Posted by Dan at 04:16 PM | Comments (0)
The Pudding Theory
Last night, mans cognitive understanding the world around him became just a little bit better. A team of specialists was assembled for the sole purposed of testing the theories of one A. Moody, in an effort to enrich the lives of countless other human beings. This theory is better known as the Pudding Theory.
The hypothesis of the Pudding Theory is elegantly simple. The premise states that upon eating at a chinese buffet, the first time someone receives a plate from the dessert island your check will be presented. The question left of course is, what happens if you eat out of order, starting with your dessert, eventually moving to a full meal. Does the check arrive too early, therefor laying on the table so as to influence the gluttony ("I'm going to get my $10 out of this!!"), or will it be kept quiet disrupting the normal signal used by many wait-staff to deliver a check thus forcing us to ask for it?
A insertion team of two was put into place at the Golden Fortune Chinese Buffet with the intent on discovering what just might happen. The team realized this was a hot zone of activity upon entering by the early signs: a large rush of people sitting there devouring countless plates of meat, the Iraqi 50 most wanted playing cards for sale, and the mob-scene that was the ice cream dispenser. The team was sat at the far end of the room, with a clear view of the entire dining establishment. Upon placing drink orders, the team went into action, gathering two plates and filling them with various items on the dessert isle. This task was more dangerous than initial reconnaissance had suggested. The mass of dining patrons were now entering their need for a sugar fix, leaving much of the dessert isle in ruins, and the trays empty. The fall back plan of ice cream was put into jeopardy when it was discovered the ice cream machine was no longer in service at that time, hence the mob. To sedate the mob, a series of pastries was brought out, which when covered with vanilla pudding worked wonders.
Returning to their seats the team discovered their drinks filled and awaiting consumption. Within a minute of sitting down another wait staff brought over the check, set it down, and left it for us. Working quickly, the team devoured the contents of their plates, put the plates on another table, and proceeded to fill a new plate with a more traditional style dinner item. A few minutes later the original waitress returned to check up on liquid refreshment levels, but had a confused look as to how the check was delivered to the dining patrons while they were still eating.
Some brief yelling could be heard, but the insertion team was unable to make out any of it.
In conclusion, the Pudding Theory does hold when used in a dining establishment. It also can provide a few more minutes of entertainment when needed, but execution must be done with care. The wait staff does not like to be toyed with, so use extreme caution in not getting caught.
Posted by Dan at 06:13 AM | Comments (1)
August 20, 2003
PHP Blob support
Clara Liu, of Zealworks, had sent me a patch many moons ago that incorporated blob and clob support to the PHP ODBC functions. After having looked over it awhile I had decided that I really didn't understand the how the patch would work. I was hesitant to add such a change to the PHP source. Looking at my saved emails from the conversation she never really explained how or why this patch would work either, so I put it off until I could later look at it. What was so confusing about the patch? She copied the SQL_LONGVARBINARY portions of code and just renamed them to SQL_BLOB. It seems now that there are a significant number of users asking/requesting for BLOB support within the PHP system, and as such I would like to present to those users her patch for testing. Just be nice to my slow internet connection please.
The patch is done from a recent snapshot of CVS for PHP 5, but should be easily backported to PHP 4.3 systems. You can find the patch file at http://www.deadmime.org/~dank/blob_patch. If this works, thank Clara Liu for her efforts some how :)
If this works or does not work for you, please let me know via blog comments, trackbacks, or even email. Thanks for your time.
Posted by Dan at 06:51 PM | Comments (1)
ODBC fetch speed
While talking with Edin the other day, he complained about how painfully slow the PHP ODBC fetch system is for him. He provided me with some numbers and a sample query to back his complaints. While I don't remember the exact timings he had, it looks something like this:
Connecting - 0.5 seconds
Executing - 0.1 seconds
Fetching - 2.7+ seconds
Fetching is obviously what he was complaining about, as the query was simply returning 70 rows of single data elements. I suggested that he do one minor hack to his PHP source and recompile. After doing this hack, his fetching time went from that astronomically high number down to a lightning quick 0.1 seconds.
This hack is wonderful, and I actually tried to implement it back in the PHP 4.2.0 days, only to discover it broke a significant portion of Microsoft based clients.
You can implement this hack yourself too by changing your cursor type from SQL_CURSOR_DYNAMIC to SQL_CURSOR_FORWARD_ONLY within the php_odbc.c file (only the two instances of SQLSetStmt please). Mind you, I do not support such changes and cannot ask for anything more than feedback if it worked for you (via a TB or a Comment would be nice). You should see a dramatic change as well in your fetch speeds.
Supposedly with IBMs DB2 v8 (and greater) you can do this same alteration via a few words of SQL at the end of your query. For example adding in "FOR READ ONLY" will convert the cursor to a FORWARD_ONLY cursor and speed up your queries as well. The reason this works within the DB2 system is it seems they've dropped support for dynamic cursors awhile back. If anyone else has found that their DBs also support this change for cursor alterations, let me know.
Posted by Dan at 06:36 PM | Comments (0)
August 19, 2003
Certificates
On a random side note, I was able to get my first class medical student license yesterday. Only catch with this is a need to wear corrective lens while being the PIC. Granted the license will be a second class license by the time I get to use it any, but it still is nice to know I can go all the way.
Posted by Dan at 01:19 PM | Comments (1)
Software Porting and Graphical Toolkits
I spent a lot of time this summer working to port one of the plentiful graphical toolkits from the open source arena into the new frontier of EROS operating system (the web page is extremely outdated). There are, of course, a few catches working with EROS that are not readily visible upon initial inspection. First, the system works via capabilities, a concept embraced to enforce secure coding and and application behavior. Second, there is no POSIX compatability layer, which makes emulating many assumed features and functions near impossible at times (i.e. poll). Third, there is no working shell (yet), so compilations have to be accomplished via a cross environment, and allowing only testing a single application at a time. Fourth, at the start of this endeavor, there was no graphical display system.
When we started on this route, it was decided that we were going to work following a system like Apple's Quartz system, where an application and the window manager can share the information between them in an easy manner. The reasoning was this fell inline closely (and could be adapted to) the idea of capabilities, and would allow us to continue the security model we've been working with. Slowly a proof of concept windowing system was developed, and we were eventually able to create sample draw program (single color with no erasing). The next step was to create a toolkit, and herein lies a headache that has yet to be fully grasped.
From the start, we realized that there were not that many options provided to us as far as using publically available toolkits. We were not looking to completely write our own widget set (which is what we really needed), and began looking at the open source projects that (claim to) do so. GTK, Qt, wxWindows, and FLTK were what we decided were to become our options.
Let me start by discussing some of the lesser known widgets and toolkits and why we didn't take this route.
FLTK provides an extraordinarily nice widget set that allows for some functions that do not exist elsewhere. It also follows the look and feel of SGI's Irix system, a windowing system that I found absolutely enjoyable. Unfortunately the individual looking at this code had decided that the lack of portability in this code was going to make this an extremely long process. Upon looking at it briefly, I had come to the same conclusion. The best part about it though, it was small, fast, and able to be built easily as a static library, a necessity for us as EROS has no shared libraries yet.
wxWindows is probably one of the greatest cross platform toolkits out there. The code is extremely easy to follow, nicely modularized, self-contained, and not filled with a lot of the ANSI C++ standards mess (i.e. templates). The work necessary for porting this system could almost be done in a day with no significant feature tradeoffs. The downfall to wxWindows was the lack of a widget set open to the public. While the MGL port can provide a widget set, you will be required (from what I could tell) to purchase this portion of the code from a third party entity which is not what we wanted. The big selling points of wxWindows: it's easy to port, and uses the native widget set. I will certainly remember this for future products. Also since it uses pre-ANSI standard C++, it has a much wider range of portable C++ code.
We started down the road to port Qt but it became painfully clear that this wasn't going to work for one major reason: our C++ compiler. The C++ compiler on EROS is no where near fully functional in any sense of the word, and was simply lacking features necessary to make things happen. A good indicator to the age of gcc that we are using, it's stopped at version 2.8. Thankfully there is an effort underway by another individual to update this to 3.something, and I hope this will be done in the near future for the next step in the process. The Qt world was very nice, with a large amount of code easy to follow and alter. Other developers in the Qt land were quick to respond, and responded with an insane amount of detail towards answering a question at random. Some of the documentation I think could be cleared up a bit if they wanted to (i.e. QtDirectPainter vs QtPainter), but for the most part it is a very good setup.
This left us with GTK+ which is built entirely in C, for better or worse. GTK+ is built off a series of dependencies that include glib, atk, pango, libiconv, gettext, and the kitchen sink. If you were to avoid using the natural language support (like we are), glib is the starting point for the whole demon spawn process. If this is any indication as to how the rest of the system will work, god save the queen.
Glib starts with a dependency upon some of the most annoying pieces for natural language support. I call them annoying because if such features haven't been implemented yet, it means I need to either port them or try to implement them as a whole. Thinks like iconv and gettext do not exist yet in EROS, and more than likely won't in my lifetime on the project. Oddly enough, you can disable iconv in the configure process, but not gettext. Why is this odd? Well there are portions of the code not #if'd out that depend upon iconv, but the entire system is #if'd out for missing the use of gettext.
Digger a little deeper, one will discover yet another headache. It seems that all of glib has one giant assumption: that you are a UNIX/POSIX-compliant system. This has been an endless source of trouble for our porting process, forcing us to touch many files that really shouldn't need be. Doing things like adding in a define of G_OS_UNIX to code and ensure it only works with UNIX systems. Yes glib does work on Windows, and looking at that code it is certainly a modern coding marvel that it was able to be retrofitted on top of the other boilerplate.
All of this work took many months of just examine the code, moving things around, hacking, hoping and praying that everything was going to work out. There is no way for us to test any code during these edits, we would essentially need to get the entire system ported in theory before we could test. The final step was to make everything compile. The true test of any developer is, of course, to understand and use any of the GNU utilities for compilation. GCC isn't so bad, but tools like autoconf or libtool are. Autoconf, despite all claims otherwise, does not really allow for a cross build very easily. In our cases, the version of GCC does not include a crt1.o (not required by the standard supposedly) and as such we cannot run configure using any of the cross environment tools. The solution to this was to, of course, configure for linux and begin to hack the resulting Makefiles, config.h and glibconfig.h.
Why, oh why, does this world need libtool? At this time I see libtool as a glorified shell script wrapper to add another layer of complexity to the world of Makefiles and build processes. No one seems to be able to answer questions on how it works, or why it does some function. More importantly it seems to infect every portion of most open source projects, and this is bad. After many days of editing, reading, and cursing it seems that libtool was finally ready to play nice.
As of late last night, I started for the first time building glib for EROS without natural language support, without many of the neat frills you expect, with the use of libtool, and with the use of our own cross build environment.
[EDIT: grammar correction ]
Posted by Dan at 07:44 AM | Comments (0)
August 15, 2003
Umm...
Not typical of what you find on this blog, but this article is too bizarre to pass up.
Safe for Work.
[EDIT] Corrected the link, thanks to Erik
Posted by Dan at 06:35 AM | Comments (2)
August 14, 2003
Above and Beyond Duty
I have some amazing friends, who, when pressed, accomplish amazing things with little to no forethought. Just last night I was reminded of this, but not by one of my friends directly. This time rather by the girlfriend of one of my friends who helped put an end to the Philadelphia Groper. Some of the "facts" in the article are a bit wrong (i.e. it's not exclusive). I'm always impressed by what my friends can accomplish.
Posted by Dan at 06:26 AM | Comments (0)
August 11, 2003
Throwing Rocks
The sport of bowling is becoming harder and harder to take part in. This past weekend, it became painfully evident as a group of us set forth on an adventure to include some bowling. The trip out to the alley took more time than expected due to extremely heavy rains, but once there a small wait existed before being granted a lane. We took comfort in the billiards room, enjoying some relaxing games of 8 ball, while taking in the sights of potential purse snatchers.
Things in the bowling alley have changed though since I've been a kid, or maybe it's just the difference between big city bowling and back woods sticks bowling. I remember a fairly plain alley, no bright lights or black lights, and no fancy electronic scoring sheets. Yet the alley found this weekend consisted of 8 giant projection screen TVs located directly above the lanes, constantly spewing forth a series of video snipp-its that became a blur of nonsense. It worked wonderfully for a distraction though to hitting pins of any kind. The use of black lights and rotating colored lights also joined in, but those can generally be tuned out much easier as they are not aimed at the center of your attention. These video screens though were another story. The electronic scoring systems provided little video animation clips of bowling balls and pins in various situations, along with tips and difficulty ratings for how your pins left standing.
I should have known from the start that this was going to be just a bizarre experience. When getting my shoes I had asked for a 13, only to discover they didn't have a pair of 13's only a single shoe. As such I was subjected to a size 14 shoe, which while roomy, wasn't the best shoe to be using when asking for foot control. FInding a ball was difficult as there seemed to be a lack of them on the shelves. We later discovered that the group at the lane next to us was hordeing all the balls like they were going out of style. I've not seen so many little kids dancing on the alley's, or walking down the gutter lanes.
The crowning moment of true bizarreness occurred as Dave was stepping up to let lose some of the fury that is better known as The Dave Bowling Experience, all screens went black and the lights over the alley went dark. The pins were still visible, but not much else on the lane could be seen. Slowly the screens became illuminated with the sights of Michael Jackson in what was called "10 Minute Dance Mix". The sad part about this is that some DJ was able to condense all of the Michael Jackson experience into a 10 minute music video (I guess there's no need to buy his greatest hits album now). This new change in the atmosphere caused a distinct change in game play as you could no longer tell where you are in relation to the line or pin alignment. My own game (I was on a 4 strike roll) was severely hindered by this change (1 or 2 pins at most per roll).
This might have not been so bad if it weren't for the shoddy lanes themselves. There was no slide on the approach, a must for anyone who likes to ease the approach to the line. Another interesting twist added to the game, the 2 or 3 pins on the left side (#4, #7, #8) were better left untouched by a throw. Typically if missed in the first throw, the automatic pin tools would still lose any (or all) of these pins at random. It often gave someone a spare when they hadn't yet earned it. Figuring out the electronic scoring system became much too difficult to correct this, so we just sort of let it slide. Given the amount of money thrown around to make you forget this was a bowling alley, you would hope, or at least expect, that the lane would operate correctly. Oh well..
As a warning to all future outings looking to bowl, if you notice giant TV screens above the pins, just leave. It's for your sake, and the sanity of your game.
Posted by Dan at 01:44 PM | Comments (0)
August 06, 2003
Data Representation
It happens at least once or twice every year. A piece of junk mail arrives at my parents house, destined for my father, who inevitably believes it is more important for me to know of it's existence than throw it away. The mail in question though is often an announcement for a presentation on data representation, and how it effects our understanding, a rather interesting discussion to say the least. Working with computers, this becomes an essential area of concern for myself. How can I increase my productivity levels? How do I process what's on the screen? How can I fully understand what data is being fed to me?
It's not something I directly correlate back to my computer use regularly. I have become rather ingrained in my ways, working while subconsciously shifting through the data I've deemed useless. It was only recently that I realized just how bad current operating systems represent applications and other data. Being a CLI type of person, I spend a lot of time typing, and using the least efficient means of visualizing data. This has been a personal trade off for me in many ways, I find less time spent utilizing the mouse directly translates back to more time to stay focused on the task at hand. But take a look at the GUI format for representing applications.
Under Microsoft Windows, it was the Windows-95 release that changed everything. Among it's many changes, the biggest visual impact was the introduction of the Start menu. No longer did a user have to search through billions of small files looking for the .exe, they could easily jump on the Start menu and go. Unfortunately this idea didn't extend any further in the operating system. Try copying an application from one drive to another, or using the command line tool to discover the ugly joy of the application parts. Even today in Windows XP you'll find the same thinking in use, only now there is a protective "are you sure you want to see the ugly parts of your computer?" warning before you can play. Open this up, and you discover that there are hundreds of tiny little files that comprise this application and just make life typically annoying. That oh so nifty Start menu is just a link to the executable in another area, and doesn't necessarily represent everything on your computer.
The current offerings of desktops for UNIX haven't gotten much better. For the most part they're still emulating other services, rather than trying to innovate a new system. I would argue that application layout for UNIX systems is typically even worse than those found on Windows operating systems, but thats for another day.
Apple's current Mac OS X has a really interesting change, one that I don't believe I've fully appreciated until I needed to explain to my father how to copy an application from one drive to another. Under the Aqua GUI, an application appears to be a single icon that contains most (if not all) the necessary files to run the executable. It is easy enough to copy this application from one location to another (just drag it around), or even to share the application across the network. This is all fine and dandy, but what about those of us who are CLI users? Under the command line, you'll discover that each application is actually a directory, postfixed with a .app, that contains a series of directories that define the behavior of the application (resources, versions, etc).
While you can argue that just moving up a directory level would accomplish the same thing in the other windowing systems, you would be missing the elegance that is found here. As far the Apple GUI is concerned, this directory IS the application. The mixture of the two functionalities provides an ease of use that so far has been unparalleled. On the flip side, often times the computer illiterate are not aware that copying an application will require more than one file. This mistake is typically made only once, but is there any reason for it to even exist? Now to see if I can enable such visual representation in the EROS system, but no promises.
Posted by Dan at 08:19 AM | Comments (1) | TrackBack
August 05, 2003
Airplanes
Got a chance to fly in a 1972 Beech Bonanza 36A. I figure if I could ever afford an airplane, it would come down to two choices:
The Beech Bonanza 35 (or heck maybe even a newer Beech) or some type of seaplane (land/sea style) that I haven't figured out what yet.
Very sweet airplane, though the 36A does not have the V tail of the 35.
[EDIT: added in seaplane link]
Posted by Dan at 12:54 PM | Comments (0)