William Woody's YAAF Journal

Fun for off-screen drawing, the XGPixMap object permits you to create one of these, draw to it, then blow it onto the screen.

The good part about the XGPixMap is that if you are creating a drafting tool, you can create two of these when starting to draw. The first would contain just the elements of the drawing which are static. That can then be used every time the mouse moves, dragging a second object, to provide the background. The moved object can then be drawn by copying the first pix map into the second, then drawing the updated object, then blowing the whole thing on the screen.

A word about the XGPixMap object. Because it uses (on Windows) the CreateCompatibleBitmap() call and a memory-based device context, one limitation is that you cannot copy a pixmap into a second pixmap if either currently has an XGDraw object opened in it. Nor can you copy a pixmap into an XGView's XGDraw drawing context if the pixmap has an associated XGDraw object on it. (This is because the underlying HBITMAP can only be selected into one HDC at a time, and it was easier to create this restriction than to figure out a way to juggle the different device context.)

Some sample code demonstrating drawing with this is below.

/*	TDrawingView::CreatePixMap
 *
 *		Initialize pix map
 */

void TDrawingView::CreatePixMap(yaaf::XGPixMap &pixMap)
{
	Rect r;
	yaaf::XGDraw pixMapDraw(&pixMap);
	
	r = GetContentRect();
	pixMapDraw.EraseRect(r);
	pixMapDraw.MoveTo(r.left,r.top);
	pixMapDraw.LineTo(r.right,r.bottom);
	
}

/*	TDrawingView::DoDrawView
 *
 *		Draw the picture at resource #129 in the middle of the view
 */

void TDrawingView::DoDrawView(Rect r)
{
	yaaf::XGPixMap pixMap(this);
	CreatePixMap(pixMap);

	yaaf::XGDraw draw(this);
	draw.EraseRect(r);		// first, erase the area being redrawn
	draw.DrawPixMap(&pixMap);
}

I will upload a diff with all of the changes soon enough; until then you can always sync with the CVS at yaaf.org.

I've been tweaking things here and there, adding a few methods in one place, modifying behavior in another, with YAAF lately.

The rational: I want to get this thing to beta quality--which, in my mind, means making sure the API is complete. The acid test: a series of sample programs which I intend to include with the YAAF Recipe Guide, a book which "drills down" into the various APIs to give the "gestalt" of how to use YAAF.

I don't know when this will be done, but I hope to have a series of patches up soon for those who bought the CD and who may not have the bandwidth to download another 20 megabytes of source.

is it means I have to go through all of my code and fix the problems I thought I had already fixed. Like the couple of minor bugs in the document handling code.

Hopefully I should post a bug list fix soon, just as soon as I work out the problems I've encountered with the XGDocForm/XGDocEditor code.

Don't worry; nothing major. Just some minor glitches...

A little tweaking, and the changes to the XGDraw code has been uploaded. The great part is that I could strip out all of that weird pseudo-Quartz code in Quickdraw that was messing up the XGDraw code.

Now this means that I'm more likely to work on earlier versions and I don't have to do any weird sort of stack management for drawing contexts or the weird sort of context caching scheme I was working on. The flip side is that on MacOS X 10.1.4 and earlier, anti-aliasing will look different than on MacOS X 10.1.5 or later--however, I think this is an acceptable tradeoff.

I've also changed things so anti-aliasing is only used on MacOS X, and not in the classic environment. The rational for this was that on MacOS X, the default fonts for dialogs and applications are slightly larger, and look better. On MacOS 9 and earlier, anti-aliasing the default Geneva 9 font looks strange, and for maximal compatibility I didn't want to pick Geneva 10 as the default font on some versions and Geneva 9 on others.

Of course you're free to tweak the draw code for your own use; just find where I wrote 'GOSFeatures.fClassic' and change it to a test for if GOSFeatures.fOSVersion >= 0x0860. (The anti-alias in Quickdraw was added in MacOS 8.6.) Then, simply change the default font size to a 10 point font in XGFont from a 9 point Geneva, and you should be all set.

The SetQDTextFlags worked perfectly! Tweak a little, then release to the world...

SetQDTextFlags, which is available in MacOSX 10.1.5 and later, which is *supposed* to solve my problems. The nice part: stripping all of that weird hybrid Carbon Quickdraw/Quartz code that was causing me endless problems.

Eventually I need to separate out the XGDraw code into an XGDraw_mac, XGDraw_win and XGDraw_x modules in order to get all the conditional code under some semblance of control...

... and it's killing the text editing code.

The problem that is causing the text editor fields to run really slow on Macintosh Carbon under OSX is the SetFontObjectA routine, which is doggedly slow. I'm working now on somehow caching the results so I only have to run the internal guts of the routine when the font actually changes. We'll see how well that works.

Well, I finally got the YAAF: The Other Libraries uploaded to CafePress. The book is now available for purchase.

This contains the chapters that didn't fit in the development chapter, and documents the new Mail, HTTP and Astronomy libraries, including a rather nice section on orbital coordinate systems which I thought was sorta cool.

Now I just have to integrate some stuff people sent me, and write the "YAAF Cookbook."

Well, it's done. I've upgraded the web site so I could clean up the appearance, and so I could potentially publish a couple of books, not just the one book per shop limit that is normally used.

And the press release is out--letting people know I've released a new version of YAAF.

The last two things on my todo list: update the software with undo stuff, and get the SourceForge web site working so I can store the source code on their CVS server rather than my poor box's CVS server.

Well, I've published the YAAF Development book on CafePress.

It looked like the additional material for the astronomy, http and mail chapters was threatening to make the book too big even for glue binding, so I've split the book. My hope now is to have the book "YAAF: The Other Libraries" published in another month or so when I finish it; that second book will probably run a hundred and fifty pages or so. (The first runs 400 pages total.)

There is a third book in here somewhere in my brain called "Design Patterns with YAAF" which would discuss more the sorts of patterns that I assume for software development. This would include many more examples, and would be more or less a sort of "so you want to do X; here's how" book than a "here's the classes and a rough idea how to use them" sort of book.

Did I mention that the reason why I want to open a premium shop on CafePress is so I can have a couple of books published there? Turns out if I want to publish more than one kind of thing (like one kind of CD, one kind of book, etc) I have to have a premium shop. The good part is that then I can focus attention on the CD and the books, and the shirt and mug can be relegated to a secondary "merchandise" area.

Well, the CD is up on the CafePress site. (They never sent me an e-mail saying they received it; they just activated the product.) I've ordered one for myself to verify the quality of the CD, since I've never done this before.

The book--well, I've been fixing up the YAAF Development book to include changes made since v1.1a7--including some of the newer libraries, including the HTTP and Mail libraries. Hopefully I should have that done Real Soon Now.

Of course the only problem I'm running into is that I'd like to print the book on CafePress as well as have the PDF for download. I personally like having a bound book rather than a huge multi-hundred page PDF, so I figured I should put the option up there. However, I'm running into a problem: it looks like the development book may be more than 500 pages in the "technical book" size offered by CafePress (with fonts sized to what looks pretty close to fonts used in other technical books)--which exceeds number of pages allowed for wire binding. (I like wire binding for technical books because they lay flat without having to crack the spine--as there is no spine.)

*sigh* If I can keep it under 500 pages, then wire binding. If not, then perfect binding, which will result is a cheaper book, but one where you have to "crack the spine" to keep it open--which makes it harder to use.

By the way, my rational for marking up products on the yaaf site is not to make a lot of money, but to compensate for the cost of opening a premium shop on CafePress. It will set me back $60 a year, and I'd rather have the CDs and the books pay for the markup rather than pay for it out of my own pocket. And if I can also pay for the disk space at mac.com (which hosts the free downloadable files) at the same time, that'd be cool too.

Finally I've gotten some time this weekend to finish the work to get an image working that can be compiled using Visual C++ on WIndows. This includes an installer script to copy all of the headers files to one location, instructions on how to configure Visual C++, and a workgroup file which loads in all of the project files and could compile them in one shot.

I'm also mailing in the master for the YAAF CD. Hopefully it will be available in a week or so on-line for ordering!

Well, I've finished the artwork so I can start pressing CDs for people who don't have the bandwidth to download the entire thing. And oddly enough the same artwork works for a LiveJournal icon, a t-shirt, a mousepad, a coffee mug...

My feeling is that if I can sell a couple of CDs a month or a couple of coffee mugs or whatever, hopefully that will compensate for my creating a "premium" Cafe Press account, so I can then have multiple different CDs. I'm also thinking of writing a "design patterns in YAAF" book, and Cafe Press would permit me to print those as well as distribute the book as a PDF for download.

... ah, the ideas ...

It turns out after almost half a decade after writing the core XGDraw routines within YAAF, I find a basic bug in the ellipse and arc drawing routines which caused them not to be drawn correctly on Microsoft Windows.

*sigh* Fixed and checked in.

On a related note, I also found a site, Cafe Press, which does just in time printing of promotional products, including just in time printing of documents and just in time pressing of CDs. That means I can sell a CD with all of YAAF on it, to save people the effort of having to download stuff. The base price of a CD is pretty cheap, so I may just sit down and do that as an alternate distribution channel.

Finally, I fixed a crashing bug in yamtad, the mail server daemon which was preventing me from feeling comfortable announcing a formal release of YAAF or doing any other real work merging in new features or the like.

It turns out to be two problems. The first was my (stupid) use of sprintf(), when I should have been using snprintf(). No matter how big the buffer is, someone sends something which needs a bigger buffer.

The second problem has to do with some spam SMTP servers sending a message but never sending an 'end of mail' message. Apparently it expects the yaaf SMTP server to time out, and use the message that was sent. What I do (instead) is delete the message. Internally I would then return NULL for the XGMail object representing the received mail.

Well, I wasn't checking if I got back a NULL, started invoking methods on the NULL XGMail object, and of course hilarity ensued.

Fixed!

I just found the world's most obscure bug within YAAF.

I've been working on a mail transport agent as a technology demonstration of multi-threading and of the YAAF network stuff and a faceless background application, and because I needed an MTA which worked for low-volume e-mail stuff on the yaaf.org web site.

But the damned thing kept crashing, and I have been extremely hesitant about releasing this code until I understood why it was crashing.

Well, there appears to be two issues. One appears to be buried in the connection timeout code for TCP/IP sockets on Unix--and that one I still haven't a good clue as to exactly what's happening. (The symptom: some spammer out there doesn't send an 'end of message' marker to the MTA, and my code waits for one. So it eventually times out--but somehow, that timeout and closing of the socket corrupts memory somewhere. This is a bad thing.)

The second bug, however, I just found, and I'm uploading a new daemon to the yaaf.org server to fix this issue.

The bug was in XGDirectory.

Yeah, XGDirectory. Turns out my implementation of yamta was making heavy use of XGDirectory. And XGDirectory was not re-entrant.

First rule of re-entrancy: if you operate on a global resource, you're not re-entrant unless you protect the sensitive code in some sort of accessor. And the current working directory is a global resource. On some circumstances when enough stuff was going on, multiple calls were made into the various XGDirectory methods, and occasionally a 'getcwd()' call was being made in one thread when a 'chdir()' was being called in another.

Kaboom.

Once I find the second bug, and integrate some software donated by David Cotter (yes, I still remember!), then I will do a press announcement of the new version of YAAF.

I'm just nervous about releasing something widely when stuff is still crashing repeatedly.

While walking today and thinking about the implementation of yaaf_data, the underlying database engine I've been meaning to use for a rewrite of BugLink to bring it (finally!) into the year 2000, I had a couple of realizations.
( Read more... )

Well, it's only a month late, but I finally redid the YAAF web site, and redid the downloads. Now I just have to integrate a bunch of stuff from David Cotter who was kind enough to send me a lot of really cool stuff, and I need to rebuild the makefiles so this thing compiles under Windows and Unix correctly.

And of course find that damned crashing bug in my yamtad daemon, and finish the core yaaf_data library for distribution...

Never enough time, never enough time.

*sigh*

The software daemon, yamtad, which I wrote with YAAF as a technology demonstration of the new SMTPd and POP3d daemon software I put together within YAAF, had been crashing periodically when receiving SPAM from certain spammers.

So I spent the last two days writing my own malloc/free routines, hooking them into YAAF through the Metrowerks Profiler code so I could get the name of the routines calling into my allocator, and also wrote it so that every allocation/free call would run a check of all memory allocated, looking for buffer overflows and the like.

It's now running on the yaaf.org server.

And the spammer which was causing my code to crash has stopped spamming my server.

Damn it.

I wanted to find that bug!