The LINCKS GPD
In Linux Journal Issue 11, we described a typical installation of LINCKS, described the functionality of its components, and briefly introduced the main application interface, xlincks. Since LINCKS is distributed with an online tutorial, and a 70-page xlincks manual, we will assume that you know the basics about operating xlincks. In this second and last part, we describe how to create your own views, or general presentation descriptors (GPD), as we call them. For a reference manual description of GPDs, see chapter 7 of the xlincks User's Manual, and for a technical overview description see Journal of Systems and Software.
As a running example, we will show you how to use xlincks to create an address book, and the GPDs used to enter and display data. We start out by designing our data structures, then describe the LINCKS object model, and finally show how the address book is represented in the object model. We briefly describe the automatic search for GPDs used in xlincks and show our first GPD, followed by a description of the GPD's parts. We conclude by extending the newly-created GPDs to demonstrate a few additional features.
In our address book, the two obvious objects are the person object containing personal information, such as: name, birth date, e-mail address, and private phone number, and the address object. An address object can be shared by different persons and contains the common street address and common phone number.
In LINCKS, each object consists of the following parts:
IMAGE storing any type of information which can be PostScript, object code, a GIF, or a name (string). The size must be less than 232-1 bytes and the content is single-valued. (Currently, xlincks can only handle IMAGEs containing zero-terminated strings.)
ATTRIBUTE describing or typing the object. The value of an attribute is a zero-terminated string shorter than 216-1 bytes. An attribute is named by two strings, a group tag and a field tag, where several attributes can share the same group tag, but the combination of group and field must be unique.
LINKS containing links to other objects. A link field is plural, that is, for each object it can contain several links to other objects, as opposed to the attributes, which are single-valued.
In Figure 1, the window with three entries is the person object where the image contains the person's name, the second line specifies the birth date, and the fourth line is a link to an address object. The second, bigger window is the node view applied to the same object. (To apply another view, click on the item, then on the “Expand...” menu item, and then choose the node view. See the previous article in Issue 11, or read the xlincks manual, for more information.) The first entry in the node view is the image, followed by all the attributes and finally the link section beginning with the SYSTEM:Parent entry.
Notice that the system creates the two attributes SYSTEM:Created and SYSTEM:Owner--this pair is a good example of two attributes sharing the same group tag. In general we use all capital letters for the group part and lower case letters, possibly initial capital letters, for the field part.
GPDs are named by a string, which may contain white space. xlincks looks for a specific GPD first in your own GPDmaps and then in the list of system GPDmaps. This allows you to override the system GPDs with your own specialized GPDs. Now, if you expand the Empty User 4's GPDmap line, you will get a window with your first GPDmap as in Figure 2.
Replace the <<table>> with the name of the new GPD, person and then move out of the line with ctrl-n. A new placeholder <<gpd>> will appear which we fill in with a one line description of the new GPD, view of person object, as in Figure 3. Now, expand (meta-l meta-e) the description line to get the empty GPD template seen in the bottom of Figure 3.
First, you add a link from the GPDmap by first clicking on the line Empty User 4's GPDmap followed by a click on the line <<gpdmap>> in the empty GPD, then on the Add Link button—resulting in <<gdpmap>> being replaced with a link to Empty User 4's GPDmap.
Second, we need to define the logical structure by describing the logical parts in the person object. Earlier, we defined the person object to contain a name and birth date. Now, move to <<direct>> line in the STRUCTURE section and replace it with the name of our GPD, person. The name of the GPD used in GPDmap must occur at least once in the STRUCTURE part. After moving out of the line, we replace the newly created empty: value with the parts in our person object: name and “birth date”--since the part name includes a space we must use quotation marks (otherwise it would be three parts!).
Third, now that we've defined the structure of the person object, we need to define where to store the information. The ACCESS section of the GPD defines where we store or retrieve the parts of the logical structure. We would like to store the person's name in the IMAGE part and his/her birth date in an ATTRIBUTE called ADDRESSBOOK:Date.
To specify the name component, we move to the <<direct>> in the ACCESS section and replace it with the name (the name of structure part). Then we move out of the line and replace the empty: value with IMAGE. The resulting GPD can be seen in Figure 4. A warning: any omitted ACCESS specification defaults to IMAGE!
To define where we find the “birth date” in the ACCESS part we move the cursor to the name line in the ACCESS section and do an insert closest plural (meta-l meta-i), with the result as shown in Figure 5. Replacing the direct line with birth date (without quotation marks!) and the empty: value line with ATTR ADDRESSBOOK Date gives us Figure 6. Notice that we use the keyword ATTR followed by the group tag (ADDRESSBOOK) and the field tag to define the storage place for birth date in an attribute.
Last, if we would like to try our new GPD, we need to create a place to store the object, say in our LINCKS home directory:
1) Click on the line “Linux on the Road”
2) Do an insert closest plural (meta-l meta-i)
3) Expand the item (using meta-l meta-e or ctrl-left-click)
4) Fill in the GPD as person
5) Expand the same line (person) which should result in a two-line window saying item and empty: birth date as seen in Figure 7.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- SourceClear Open
- Doing for User Space What We Did for Kernel Space
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide