Building a Distributed Spreadsheet in Modula-3
We need some underlying data structure for our spreadsheet, so let's begin simply by typing:
TYPE Grid: REF ARRAY OF ARRAY OF INTEGER;
TYPE Grid: REF ARRAY OF ARRAY OF Money.T;This defines a two dimensional grid of integers (in the first line), or, as a second option, of type Money.T. Integers are a built-in type. Money.T is a programmer-defined type; the “.T” suffix is a Modula-3 convention. (In a real spreadsheet, each column would have a distinct user-defined type. Let that detail pass for now.)
A new grid can be allocated on the heap during variable declarations, if you wish, or during program execution.
VAR myGrid : Grid := NEW (Grid, rows, cols); BEGIN myGrid := NEW (Grid, 100, 20); END.
The second assignment of myGrid will wipe out the first, but don't be alarmed—we do not have a memory leak. The Modula-3 garbage collector takes care of reclaiming lost memory. This is also true of object variables (no destructors necessary), including objects that allocate memory on remote machines.
To flesh out our spreadsheet object, we next attach some operator methods to the grid. A good place for this is in a separate “interface” file. Listing 1 contains an initial cut at spreadsheet.i3. Our object is now declared to be a Spreadsheet.T type.
The important property of an interface is that it contains no executable code whatsoever. That's reserved for “.m3” or module files. The interface does not say how something is computed, merely what it does. This is similar to .h files in C, but is more strict. Only the operations explicitly exposed in an interface—or “exported” to use the jargon—are available for outside use.
(The sharp reader may have noticed that the representation of Grid is exposed in spreadsheet.i3—a bad thing. Modula-3 does allow you to hide details of representation inside implementation files. That would take us into a discussion of opaque types, however, a more advanced topic.)
Modula-3 comes with a multi-platform windowing system called Trestle. Built upon Trestle is a user interface toolkit called VBTkit, and a UI builder, FormsVBT. You may call X directly if you wish (alternatively, the Win32 GDI), but in doing so you lose portability.
A description of your program's user interface is called a “Trestle Form”. A form is a textual description of names and values, organized using nested parentheses. Form elements consist of windows, frames, buttons and so on, as well as properties such as color. Listing 2 is a sample form for a popup calculator, as shown in Figure 1.
The important point is that a form is defined in its own file, outside any Modula-3 code. This separation of concerns proves valuable when the user interface designer is a different person from the primary coder. The form does not describe how to construct the interface, merely what it looks like. The FormsVBT library builds it at run time and hooks it into your code.
Suppose our spreadsheet is implemented, along with a suite of test functions. To build a program, we must inform the compiler what source files comprise our executable. This is done in a Modula-3 make file, or m3makefile. An example is shown in Listing 3.
To build your program, at the command-line prompt type:
The compiler will determine dependency relations for you, recompiling only what is necessary.
Converting a regular object (restricted to a single address space) to a network object (visible over the Net) is not as difficult as you might imagine. You must attend to four details.
First, the network object library needs to be linked in. This is performed in the m3makefile (Listing 3).
Second, make the following two changes to the spreadsheet interface:
IMPORT Money; IMPORT NetObj; (* new statement *) TYPE T = NetObj.T OBJECT (* modified line *) grid: Grid; name: TEXT; METHODS ...
Third, and this matters only at execution time, a network object daemon needs to be running in the background. The program is supplied as part of Modula-3. Start the daemon by typing:
netobjd &In a client-server architecture, the spreadsheet object resides with the server, yet it is the client that issues method calls (to update a cell, for example). Clients need to find out about each other. This is the fourth detail.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- RSS Feeds
- Tech Tip: Really Simple HTTP Server with Python
- Readers' Choice Awards
- BASH script to log IPs on public web server
30 min 8 sec ago
4 hours 5 min ago
- Reply to comment | Linux Journal
4 hours 38 min ago
- All the articles you talked
7 hours 1 min ago
- All the articles you talked
7 hours 5 min ago
- All the articles you talked
7 hours 6 min ago
11 hours 31 min ago
- Keeping track of IP address
13 hours 22 min ago
- Roll your own dynamic dns
18 hours 35 min ago
- Please correct the URL for Salt Stack's web site
21 hours 46 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?