Ben Langhinrichs

September, 2004
SMTWTFS
   01 02 03 04
05 06 07 08 09 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

Search the weblog





























Genii Weblog


Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.


Thu 30 Sep 2004, 11:00 PM
Well, it is just my opinion, but John Kerry looked very strong in tonight's US Presidential debate, and was as clear and precise as I have heard him.  George Bush looked a bit shaky and defensive, and tried to push his practiced debate points too much even when they had little to do with the topic, but he didn't say anything too destructive.  Kerry was quite good at actually answering the questions, while Bush simply dodged some, but both had some trouble sticking with their own constrictive debate contract, each trying hard to respond directly to the other.

On the negative side, Kerry should have left the pen alone, and Bush has got to learn to not roll his eyes and look rude when the other guy is speaking.  No wonder he pushed so hard to try to limit pictures of him when Kerry was speaking, even if the networks didn't go along.

On the positive side, neither man stooped too low, and both stayed within the time limits very respectfully.  Good points were made on both sides, and the questions asked were reasonably hard hitting for both men.  The moderator is to be commended.

Update at 12:28am: I guess others agreed.  With 512107 responders, the MSNBC poll shows 70% think Kerry won, 30% think Bush (they don't offer a tie choice).  With 131357 responders, the CNN poll shows 79% think Kerry won, 18% think Bush won, and 3% think it was a tie.  ABC News shows it was a bit closer, but I don't have the stats, something like 45% Kerry, 35% Bush, rest tie.  None of these are statistically sound polls, of course, but the early concensus seems to be that Kerry did well.  Let's see how the spinmeisters spin this over the next few days.

Update 2 at 1:04am: By the way, can you believe that George Bush, in the wake of the horrible Abu Ghraib torture scandal, would slip up and say (about his daughters): "I'm trying to put a leash on them."?  Even though it was in quite a different context and obviously not meant that way, it may be one of those statements that gets repeated and repeated.  I've already seen a couple of bloggers pick up on it, including Andrew Sullivan, who puts it succinctly and well:
No president who has presided over Abu Ghraib should ever say he wants to put anyone on a leash. That's all.
 

Copyright © 2004 Genii Software Ltd.

Wed 29 Sep 2004, 10:56 PM
I just can't stand bugs.  I hate them.  Unfortunately, I am in the wrong business, because all software has bugs.  Nonetheless, I at least have the satisfaction of knowing that Midas probably has a few fewer than a couple of days ago.

If you remember, I asked When is a bug not worth fixing?, and related the story of a rare bug with an easy workaround.  The problem is, when I dug deeper, I realized that the bug was not so rare, although it was seldom so obvious, and that the "easy workaround" may have been easy, but it was certainly not a workaround.

So, many hours later (about 2:30am, as I recall), I had finally rewritten the code to both severely limit the number of paragraph definitions, but also to properly restore them, which it hadn't been doing in some cases.  The customer checked and it worked for them, and it has passed all our internal test, so I guess that that bug and related ones are no longer part of Midas.

Unfortunately, there are always more bugs.  Even more unfortunately, there are never any more hours in the day.  I guess I'll just have to keep on keeping on.  Yawn!!!

Copyright © 2004 Genii Software Ltd.

Wed 29 Sep 2004, 09:45 AM
John Roling (aka Greyhawk68) invited me to speak at the GRANITE User Group meeting in Chicago next Monday, October 4, and I gladly accepted.  It is a mix of admin and developers, so I will talk briefly about CoexLinks and then more extensively about the Midas Rich Text LSX, with lots of live demos.  A new twist for me is that I can show how the Midas Rich Text C++ API and @Midas Formulas fit into the Midas picture, and show a couple of quick demos of those.  

I intend to keep it fairly informal with lots of room for questions and discussion, and I hope it is both fun and informative.  While I've spoken at a number of conferences big and small, I've never spoken at a User Group meeting before, but I would like to do that more.  (Any of you in user groups out there who would like to have me talk, take note!)

If any customers or potential customers would like to meet with me while I'm in Chicago, get in touch soon, as I am only planning a day trip right now.

Copyright © 2004 Genii Software Ltd.

Tue 28 Sep 2004, 01:11 PM

It seems so simple to software users.  There should be no bugs, no limitations, and no difficult workarounds.  I have been a software user for years, and it certainly feels like that to me.

But how does a software vendor decide whether a bug is worth fixing?  That is something I struggle with frequently.  The problem is usually a case where the bug is not encountered by many users, and has a fairly clean workaround, and the fix is likely to cause more trouble than the original bug.

Scenario
An agent was copying tables and then deleting rows from the tables.  The agent was not crashing, but was reporting an odd error:

MIDAS: Unable to save additional deleted PAB definitions.

and the rows were losing justification after the delete.  Now, this sounds like a concrete, repeatable bug, the kind I like to fix right away.  So the customer sent a sample, which included the code:

Set rtchunk = rtitem.DefineChunk("Table *;Row 1-" +Str( FIRST_ROW-1 ))
Call rtchunk.remove

My first reaction is, "Cool!", because I love it when somebody actually uses the more complex variations of chunk definitions.  Unfortunately, this is the problem.  The FIRST_ROW can be 8, and there are as many as 12 columns, so there can be 84 cells deleted in each table, with n unknown number of tables.  Internally, we store paragraph definitions for the separate cells to determine whether they will be re-used later, and the limit is 100, which is almost always plenty.  Just not this time.

Workaround
The workaround is simple for this user, which is to cycle through the tables:

Set rtchunk = rtitem.DefineChunk("Table 1")
Do
   Set rtrow = rtchunk.DefineSubchunk("Row 1-" +Str( FIRST_ROW-1 ))
   Call rtrow.remove
Loop Until Not rtchunk.GetNextTarget

and if that wasn't enough, you could break it down to another loop for each row.  This works, but obviously I wish customers didn't have to worry about this stuff.

Possible solutions
I could just change the limit to 255 instead of 100.  This still would only allow the user 3 tables, but going any higher would add a lot of overhead to deletions.  I could go with a linked list approach, but it is a lot of change for this purpose, since I use parallel arrays.  I could rewrite the logic so that duplicate pab references were not stored multiple times, which is the correct solution, but I worry about the implications I haven't thought of.  So for now, I'll swallow and accept another limitation and document this somehow, and hope that one day soon I'll get tired and fix it properly.  In the meantime, like all the Notes "oddities", this remains a Midas "oddity".  I don't imagine the IBM engineers like leaving them around either, but the risk of change may outweigh the risk of leaving bad enough alone.


Update: A fix has been made (that certainly didn't take long, did it?)  See Fewer bugs, less sleep for details.

Copyright © 2004 Genii Software Ltd.

Tue 28 Sep 2004, 10:18 AM
There are plenty of places reporting on our press releases for @Midas Formulas and Midas Rich Text C++ API, but one that surprised me was Wikiverse showing this press release under the Java Programming Language.

Copyright © 2004 Genii Software Ltd.

Tue 28 Sep 2004, 09:23 AM
Ruy Teixeira poses some questions about the latest Gallup poll regarding Bush vs. Kerry.

Copyright © 2004 Genii Software Ltd.