|
| |
News and Views
Trace Data Logging
We get some great ideas from discussions with our customers and long term users.
Recently, John Taylor, a systems integrator based in Austin, asked for logging
of the SECS communication trace data to files. The idea was to be
able to configure the saving of trace data and walk away. The logging
would be continuous, unattended, and self-maintaining. Coincidentally we
had a support issue going on with a new customer who was communicating with
buggy equipment. After some time, the equipment would stop sending event
reports, but the connection would stay up, with the equipment periodically
sending linktest HSMS control messages. The customer was able to document
the behavior for the tool vendor by manually saving data captured in the
communication trace window to files. Since the software is running in a
Fab, this was not as simple and convenient a task as it is today with the new
logging feature. We gave John more than he asked for - the configurable
data display that is seen in the SECS communication trace window can be
optionally written to log files - one file per day, up to a maximum number per
year, and optionally compressing the closed file from the previous day shortly
after midnight. The default configuration of the compression feature will
move the trace data from the previous day into a compressed .zip archive file.
Not only does the repetitive trace data compress to a high degree, having a
single .zip file minimizes disk space overhead, and it makes it easy to copy and
transfer the captured data.
Eclipse is Cool! - Comments by Ed Hume
In the name of keeping things simple and portable, I had been using Sun's Java
from the command line for longer than I care to mention. Not too long ago
I setup Eclipse on a fast Linux
system and loaded up all of Hume Integration's Java source in a project.
In January I went to town refactoring the source for closer adherence to Java
community naming conventions. Eclipse made a complex task simple as it
rifled through the code updating method names and class names. It was
awesome! That got me wondering if anyone had used Eclipse with Tcl/Tk.
It was an interesting topic to research with Google. If you are curious
take a look at the discussion on the Tcl Wiki.
Although I do not want to trivialize the comments, I think its fair to say that
Java has a greater need for the kinds of things that Eclipse does - writing
import statements, knowing package names, auto-generating getters and setters,
auto-completing class names that are repetitively entered, etc. There is
also a consensus that Tcl/Tk could benefit from an IDE that was more powerful
than ActiveState's Komodo. In lieu of an IDE, I have done things such as
cut-and-paste code from a running application using the
inspect
introspection debugger. My personal take on doing GUI development is that
using the layout managers of Java is a struggle - it seems that only the
BoxLayout and the GridLayout managers work as documented, and unlike the Tcl/Tk
grid command, the GridLayout only manages equal-sized rectangles. I have
had far greater success with the Tcl/Tk grid or pack commands for window layout.
Like Java, the Tcl/Tk windows are portable across platforms, and unlike with
Java, I am confident of creating a complex GUI with advanced features that will
show correctly across various platforms in a predictable amount of time. I
will usually include the Iwidgets package for composite widgets such as tabbed
notebooks and hierarchy trees which are not featured by the stock Tcl/Tk.
If you are using Java, and you are not familiar with Tcl/Tk you may want to run
the Tk demo program,
and take a look at the few lines of source code it takes to get things done.
If you think Tcl/Tk looks promising, do a similar investigation of
Iwidgets.
The Recent Changes Datahub SDK Documentation Page
We miss the old days when you only had a formal release with a simple version
number. With the number of packages included in the Datahub SDK toolset,
we are constantly updating one thing or another, whether its with new features,
bug fixes that we have developed, or source changes pulled in from open-source
revisions. We use the
Recent Changes
documentation page as a means to alert you to what has been changed recently.
There is a link to this page from the Documentation
home page, near the bottom of the left-most frame. If we think
something is not important to you, such as the revision of our logo in a program
icon, we may mention it way down on the page. The more important
changes are near the top, just below the remarks on the major release change.
They are more-or-less in descending order by date. The exceptions would be
when we have made a minor change to an item that was recently mentioned.
In that situation, we may choose to add another sentence and a newer date, and
leave the rest of the paragraph in its original place. If you are using an
older version of the Datahub SDK, you may want to look at our online version of
the Recent Changes document to see if its time to download a newer version.
|
