MarmotBlog

Tim pointed out to me today that the last merge from the 1.2 branch to the trunk did not include John’s cool Marmot theme. John added and committed the theme on the branch, not the trunk, so I assumed it would be merged.

Whether this is a failing CVS or that I’m using and old version (thanks Apple) remains to be seen. In any event it appears that while files added to the branch can be merged, there is no method by which directories added to the branch are merged.

After some trial and error (I love sandboxes), I found that I could checkout the trunk and then checkout the specific directory in question from the branch into the trunk sandbox.

The next step was to update just that directory the current trunk HEAD (update -A), which removes the branch sticky tag. It also removed all the files from the directory, but left the directory in place.

From there, I was able to perform a normal merge from the branch to the trunk for just that directory which correctly merged the files. I committed that and all is well.

I updated (make sure to update -d) my trunk sandbox and it got the new theme.

There has to be a better way.

Marmot 1.2.1 has now been tagged and all bug fixes and enhancements to the release have been merged back to the trunk. The development cycle for 1.3 can start now. Any additional bug fixes, etc. to the 1.2 branch will be merged back as necessary.

Make sure to checkout or update to the trunk in your sandbox before undertaking any new development.

This happened with UBB and has come up again as I start working on a email class. It is obviously just short of suicidal to try and recreate every wheel, so we start with existing classes. But how do we include those in Marmot?

I don’t think that cluttering the libraries/mu directory with other include files is a good idea. I’ve now created a libraries/vendor directory at the same location and added it to my include path. My thought is we can include versions of any include files that we might use in Marmot here, but any installation site can decide to use this directory or they can install different versions of the required files in other locations.

I’m not going to commit any of the vendor or Marmot email files yet. I want to wait and see how this works. I’m also waiting for us to merge all the 1.2 branch bug fixes to the trunk, since these are new features that belong on the trunk in 1.3.

First off, all of the Marmot pages except CVS Monitor should have John’s new Marmot favicon. Safari seems to lose the icon when you switch tabs, so it’s not as cool as it could be. And it looks like IE doesn’t like it either. Oh, well.

Also, CVS Monitor has been updated to the final release of 0.6.3 (was 0.6.3b3). They say 0.7 will have :ext support and possibly Subversion and arch support as well.

My new update to the documentation should finally work right in Safari, Mozilla, and IE. Those changes will get moved over sometime later today if they work.

CVSMonitor hadn’t been updating since John added templates/mu/marmot/ because that directory wasn’t owned by the cvsphp group in the repository. I have added a cron job at :59 to make sure group permissions are right so the :00 CVSMonitor updates should go without a hitch.

Finally, I have three RSS feeds for Bugzilla. I hope to someday replace them with one fancy script and maybe even better integration with Bugzilla’s query tools and saved queries. Until then, we have feeds for:
30 recently updated bugs
30 recently closed bugs
all open bugs

I think that’s all for now. All these little changes made for a big post.

The Marmot 1.2 branch has been created in the CVS repository. John and I finished some last minute tweaks today in Tim’s absence, but we believe we would have had his support for the changes eventually.

Time to update to the branch on our development machines and see what bugs make themselves known.

cvs update -r marmot_1-2_branch

Just as a reminder, the cvs that comes with Xcode Tools is an old version (1.10, 1998) that doesn’t support useful features like update -C. DarwinPorts has 1.11.13, and Fink has 1.11.5-1.

I’m still intrigued by arch, maybe I’ll give it a try sometime…

Bug 105 started with two similar problems John and Tim had with <goofytext> making its way into their applications, in and out of a database, and back out to the presentation layer, either causing an XML parsing error or a very mangled output stream.

The root of the problem was Marmot’s questionably-intelligent encoding practices. In 1.0.x, Marmot’s add_element would try to encode < and > signs in content, unless it resembled a tag. This was to allow the developer to insert Marmot tags directly in a content string. The two big uses of this were <break /> and <link> tags inserted into paragraphs or other block-level elements. (Also any of the style tags like <bold>.) The problem with this is that it wasn’t any more intelligent than this, so bits of the string’s contents that were not valid tags but somewhat resembled tags, like <user@host.org> or <www.host.com> were not being encoded, causing these non-tags to end up in the XML stream at build time.

This problem was further compounded by 1.1’s new mu_insert_element() function, which would return a stringified representation of a tag. We decided on this as a way to allow developers to insert elements into another element’s content without typing the tags themselves. Today we realized that this only pushed the problem around and didn’t solve anything. The content of one element still contained a stringified representation of another element, which made our encoding decisions even more difficult.

At the same time mu_insert_element() was created, MU_Presentation::make_element() was added to return an unattached element object, exactly like mu_insert_element() returned a string. add_element() was already modified to accept either a string or one of these objects, so it was only logical that we further extend add_element() to accept a string, an object, or an array made of strings and objects. This finally solved our embedded-element issue that plagued us since the beginning. Now, developers do not write tags for Marmot elements by hand, nor do they even have access to string representations of those elements.

The remaining issue is handling cases where this is already being done the wrong way. We are moving forward to document the UBB features to allow developers and users the ability to represent test styles, links, and other basic formatting within strings, for user editing or storage in a database.

Changes for Bug 105 include:
Expanding add_element()’s functionality
Deprecating text2xml(), mu_insert_element(), and the use of tags in a content string