As if the world hadn’t changed enough for the families of three souls lost to senseless violence at the hands of a madman in Cupertino yesterday, we’ve also lost a visionary who was willing to continue risking his successes to change our world for the better.

My condolences to the families of Mark Muñoz, 59; John Vallejos, 51; Manuel Guadalupe Piñon, 48; and Steven P. Jobs, 56 and to their friends and co-workers.

I’m not fond of contests and so-called giveaways where contestants have to like some Facebook page or tweet links to some company promotion. They insult consumers’ intelligence and make the product look more like circus sideshows than valuable products in their own right.

Admittedly, Apokalypse has participated in a few promotions, but they tend to be for worthwhile causes. Particularly when those causes aren’t getting the attention they deserve and benefit society. Like helping Colleen Wainwright raise money for WriteGirl, an organization which has been incredibly effective meeting its crucial goal of “bringing the skills and energy of professional women writers to teenage girls who do not otherwise have access to creative writing or mentoring programs.”

So, to help her improve the future of girls through the skills-building organization, WriteGirl, Apokalypse is giving half of the money from every sale of Mori to her fund-raising project. As if that isn’t enough, to encourage more people to participate I’m offering Mori at a discount. A 50% discount. Do you get that? Not only will you save money, but half of the money you spend on yourself at this site will make society better. That’s my 50 and 50 for 50 for 50 offer.

How is WriteGirl crucial to society? Check out their goals (emphasis mine):

• To introduce girls to a wide variety of writing genres;
• To teach a robust set of writing and critical analysis skills;
• To encourage girls to explore and develop their creative talents, both written and oral;
• To nurture girls and promote healthy behaviors and life choices through positive mentoring relationships with women writers;
• To assist girls in preparing for college;
• To inspire girls to pursue careers in writing, such as journalism, public relations,screenwriting, songwriting, corporate communications, publishing, website content producing, editing or creative writing;
• To equip girls with communication tools to confidently navigate the challenges they face; and
• To produce a full slate of program activities throughout the year so that we may serve as many girls as possible (including seven full-day writing workshops annually, a gala public reading and publication of a book each season, college visits and other special outings, and ongoing creative writing mentoring).

How are they effective? 100% of the seniors in their program have gone on to college. One hundred percent. For ten years! “How many seniors is that?” a cynic might sneer. “Ten? Twelve?” I don’t honestly know, and it doesn’t matter to me. Ten or twenty, it makes a difference.

You might think, that’s such an insignificant effort in this big world. But productivity buffs know productivity success isn’t about tackling the tasks which are larger than life. It’s making all tasks into small ones that only require a little effort that over time, day after day, gets things done.

And they’re in LA, which is one of the largest communications hubs in the world. WriteGirl’s efforts cascades into movies, print, radio, music, marketing, and anything else where people put more than two syllables together.

There’s usually a lot of hand-wringing over the under-representation of females in the tech community, and how to help encourage women to enter the field. What a bunch of hooey. Women were at the forefront of modern computing, advancing the field back when the technology was too hard for most male programmers of today. Let people, of whatever gender or other demographic, have the skills and tools of a professional knowledge worker and let them pick the field and specialties of their choice.

WriteGirl does that, and more. If you’ve been waiting for the chance to buy Mori, now’s the time to do it. Half of your investment in your own productivity will be given to Colleen’s 50 for 50 Project. If you need another reason, you’ll save 50% off the new price. If you already have a license for Mori, do yourself a favor and donate to the project.

In case you missed it, I released Mori 1.6.12 for users who were on Lion to deal with changes that were not compatible with previous versions of MOX. It’s a pretty substantial update, as most of the code was originally slated for 1.7. But I don’t believe many would dispute that these changes were overdue.

However, as 1.6.12 has been out for nearly two weeks, at least four significant bugs have been found which merit an updated Mori 1.6.13 ASAP.

• A crasher that sometimes occurs when windows are closed.
• A crasher in background process for Spotlight indexing.
• Documents of the previous session not being opened on Leopard (10.5.8) when Mori restarts.
• Search not functioning on Leopard (10.5.8).

Now, what is the prize for putting up with that kind of excitement? How about these new features:

• Compatible with Lion (but doesn’t yet provide for Lion-specific features).
• LinkBack-client support added. Saved docs now reload with LinkBacks intact. Select multiple LinkBacked items and begin edit sessions for them by clicking one menu item.
• Titles can now be fully displayed, taking up multiple rows in the Source and Entries lists.
• Users can now set different font styles for source and entry lists. Currently this setting affects all docs being displayed.
• Notes can be zoomed in and out either via a pop-up menu on the footer, the new “View > Zoom” menu (and corresponding shortcut keys), and the pinch-to-zoom gesture on supporting devices.
• The background color of notes can be changed in the font panel.
• Searches can be performed with simple partial terms or an advanced term syntax.
• Entries can be sent to Mori from the Terminal app or any shell/BSD invocation.
• Added gestural support: pinch-to-zoom for Apple devices.
• Added gestural support: swipe to navigate entry hierarchy (from any of the three main views).
• Users with a 3Dconnexion SpaceNavigator can use it to zoom the content view larger and smaller.
• Mori supports document type plugins for importing files dropped into a notebook.
• Entry icons can be customized in the Inspector.
• Added Dutch localization work by Thijs Zandwijk.
• Mori now accepts links to entries in other Mori documents dropped into notes.
• Items dragged into notes keep info related to their originating files, so you can double-click them and have them opened in their default editor or viewer application (similar to LinkBack). Changes aren’t yet reloaded into notebooks in this release. However, they will be in an upcoming one.
• Holding down the control key now creates link(s) instead of copying items dropped into a notebook.
• Updates to the Spotlight and internal search indices now occur in the background, using Daniel Vollmer’s SIWorkManager classes, so they no longer slow down your workflow.
• Status message window no longer pops up into foreground, interrupting you. It is now an activity window that you can show or hide.

Feature Improvements

• All URLs dropped at once into an entry are now accepted.
• New entries are created for every URL dropped at once into the source or entries lists.
• Added files to types of data accepted from services.
• Added code to load the default system icon for those types of documents whose icons are lacking in Mori.
• Entries can be copied and pasted in more ways, both in outlines and notes.
• Updated the General preference pane.
• Handles closing LinkBacks better.
• Added check to Smart Folders to allow matches on any or no tags.
• Better reporting of errors occurring in the Cocoa framework.
• Smart/tag folders auto-update their results when entries are changed.
• Trash folder no longer first selected entry when a notebook is opened.
• Dropping files into a notebook creates separate entries for each with the entries being either the files’ contents or a link (made by holding the control key when the files are dropped).
• Extracting an entry from a section of text will now provide a default title for it taken from the start of the text (works like dropping text into the outline).
• The sheet for titling the extracted text now displays the extracted text in a hide-able view.
• Purge data related to deleted entries when the Trash is emptied just in case “Check notebook” is run.
• Added a “Missing Plugin” message if the appropriate one isn’t found for an entry’s content.
• Warning on beta status only displayed once on newer releases for license holders.
• Crash Reporter Enhancements – Works on Snow Leopard; sends multiple reports; User-settable anonymization reporting; changed all localizations.
• Added column name for table/outline cells’ tooltip display.
• Pre-release now stores Spotlight metadata in a folder separate from the release version.
• Added critical alerts for incorrect number of internal directories in a notebook.
• Branded services menu items so Snow Leopard users can tell which ones are provided by Mori (Oneill).
• Initial credits for developers, testers, localization, etc.
• Added recording/reloading multiple selected entries.
• Added auto-display of the horizontal scrollbar in the content view when the content scales wider than the view.
• Software Update window can now be dismissed with the escape key.
• Changed the behavior of the new up/down multitouch swipe gesture. It now makes the entry which is up a level (the parent or its successor) the current entry when the sibling boundary has been reached.
• Added the missing “Actual Size”, “Fit Width” and “Fit Note”.

Now about the price change. When I started putting together some comparative feature charts as part of an analysis of the competition and where Mori stood, it was pretty plain in which areas Mori was deficient and where it excelled. It isn’t a notepad app, although you can create notebooks which are just filled with notes. Mori isn’t an outliner, although you can create outlines with it. Several, in fact, inside a notebook. The same is true for address book, todo lists, contact loggers and other apps of the Personal Information Manager persuasion.

Now, I admit Mori lacks calendar- and date-specific tools powerful enough to compete with calendaring apps like iCal and Google Calendar at this time. And it lacks the fake notebook paper look and syncing among devices (coming in Mori v1.8), but there’s a reason for that. When Jesse developed it, his focus wasn’t on making a computerized copy of a physical notebook nor replicating the stereotypical functionality of PIMs.

Mori’s minimalist interface belies the presence of a set of tools that let you create notebooks according to your own workflow needs and habits. You’re not tied to just one kind of notebook, be it a notepad, todo list, address book or what-have-you. Smart folders and tag folders aren’t a pre-selected set, locking you into what the developers decided you’re going to have. Nor is the Source List, allowing you to arrange its contents as folders only, entries only, or folders and entries, in any order and with as many columns as you like. You can even hide the Source List. The Entries List too. Give them a staggered arrangement like Mail or widescreen like Address Book. Or even hide them. Selectively.

A Mori notebook window in its default configuration.

A Mori window configured to display its three panes in its widescreen configuration.

A Mori window configured to only display its source list.

A Mori window configured to only display the entries list.

Searching for information is more powerful in Mori too. Jesse made the sophisticated language present in the search engine available right in the search field. A lot of users don’t need that level of sophistication all the time, so I added some settings which have less flexibility. But even in those settings the ability to use that powerful language is still present.

Checkboxes don’t have a set meaning. They can represent anything you want, with a different meaning for each notebook. The same goes for Mori’s tags, flags, labels, and ratings. Combined with its smart folders, there’s almost no limit to the kind of system you can create with Mori.

But the clearest example of the power in Mori is the “Edit Notebook Columns…” feature, which makes the Core Data technology underlying Mori accessible to users. Edit columns to create specially-crafted notebooks best suited for a particular type of use. For example, I’ve created feature roadmap notebooks for my products with category, priority and target columns to indicate the part of the product (eg, user interface, import/export, file format) affected by the described feature (or bug), relative importance over other entries in the same category, and the version in which it’s expected to be present; three columns which aren’t normally required in all notebooks. Or the two fields, Director and Genre, added to the fictional Mori Movie notebook shown above.

All of these factors, and more, add up to the best reason to get Mori: the ability to create notebooks that conform to your own expectations. Where you make the final decision on what works, and what doesn’t. A very valuable proposition indeed.

Steve drove the personal computer industry. The IBM PC wouldn’t have been designed as it was, nor been the success that it was, had it not been for Steve’s insistence on raising the bar on the Apple II’s case, documentation and packaging beyond the aesthetic sensibilities of the technophile typically purchasing microcomputers at that time.

Windows would not have existed were it not for Bill Gates’ realization that Steve correctly viewed the GUI as the catalyst to broadening the PC’s appeal to regular people who had no interest in becoming computer literate. And of course, the Macintosh is still around and Microsoft is still copying its aesthetics and features.

Mobile computing is just the latest incarnation of PC devices, and Apple is solidly dominating them with the iPhone and iPad. What his vision is for cloud computing is still a mystery, but he’s made it plain it’s important enough to invest a considerable sum.

No floppy drives either!

Steve’s made even companies outside the computer industry sit up and take notice. Remember when brightly colored plastic goods were all the rage after the introduction of the original iMac? And of course, the recording and motion picture industries have had to contend with Steve’s ambitions, as well as benefited from Apple’s software for creative professionals.

Now, I’m no Apple fanboy. I think the essence of The Macintosh Way at Apple was effectively killed when Steve returned as iCEO with his NeXT lieutenants. And no one can deny that Steve didn’t originate the ideas nor implement them. But it’s doubtful anyone else could’ve pulled off what he did. It’s pretty evident no one else would because, even with the examples he’s set, no other big computer company has. He understood how the technologies he was around could be utilized by people, not just engineers; he had the organization to achieve it; and he was willing to spend the resources, time and reputation to bring his vision to reality.

I had played with a Macintosh at a dealer’s once or twice but saw little value in it. It did doodles, but not real tasks. The machine that blew my mind was the Commodore Amiga. It too, had a mouse-driven GUI, but its hardware blew the doors off any other on the market. I even got a job as a Macintosh programmer on the basis of the software I developed for the Amiga. I cockily boasted of the machine’s superiority, of the inferior Mac’s usefulness only for trivial “home’ applications, and my new bosses said they might consider porting their software based on what I showed them. But it wasn’t long after, as I programmed the Mac during the day, and my Amiga at night, that I began to see the genius embodied in the Mac. It was just so much more professional in the look and feel of its UI and, sad as it was for me to acknowledge, its hardware (the case and peripherals). More elegant, refined. Even more artistic. The technological superiority of the Amiga paled to the human element reflected in the Mac. I understood that. And it wasn’t the fact there were windows, menus and an interface in which everything was actually a picture. Those were already available for most platforms of the mid-80s. It was how the total experience was shaped, how the necessary elements complemented each other and supported that experience. Without the strength of Steve Jobs’ vision and conviction, we wouldn’t have had that.

There’s no doubt that his resignation yesterday signifies an unhappy prognosis in his battle with cancer. Men with his abilities and drive don’t stop creating voluntarily. Even into their 70s and 80s, they continue to imagine wonderful gadgets and objects and do the work they enjoy. My neighbor Tom, in his 70s, crafts beautiful wooden boxes with compartments and sliding wooden locks using manual and powered wood-working tools that intimidate me. He told me he too, has terminal cancer. But he just keeps working, and smiles the most welcoming smile because he’s still doing what he loves. They all do. Until their bodies just aren’t strong enough to keep up with their hearts. It’s tragic to lose men in their 70s when there’s so much we have to learn from them.

It’s more than doubly so when they’re as young as Steve Jobs.

Well I got email up and running on openSUSE, not yet caught up with all the mailing lists, notices and junk I’m subscribed to, but I have with the customers which is most important to me.

Once I got the Linux machine working, I began setting up the tools necessary to write software for the Mac, and to incorporate into that effort the files necessary to make Mori and the other Apokalypse products run on Windows, Linux and various mobile devices.

Apple’s insistence that we must purchase new hardware every 18 months is plainly greedy, consumer unfriendly and very environmentally-unfriendly. I refuse to unnecessarily chain myself to the system as Apple chooses to package it.

I had previously decided to move onto Cocotron, a cross-platform (compatible with a target which uses a different system than the host) framework which looks and acts like Cocoa to programs using it but in a way that permits them to work on Windows and Linux, once Mori 1.7 was released. But the failure of my iMac, Apple’s policies and the availability of other growth markets have converged to motivate me to integrate it into the same effort.

But Cocotron is developed on Macs and uses toolchains (the set of development tools which builds the programs) for a format suitable for the Windows and Linux platforms. What I wanted was the toolchain for Linux that targeted MOX.

But I discovered very little practical effort was made in this direction. So to make this effort a reality, I availed myself of an open-source compiler effort, llvm, and began modifying it to be part of a fully-functional cross-platform toolchain.

But since working with Cocotron would at least initially involve running on MOX, I once again took up the effort to install Leopard on my pc as many had reportedly been able to do, and which I attempted over 2 years ago. The day after Thanksgiving Day (here in the US) I got Leopard working on my PC, an Athlon64 (Venice) machine. Details of the process and required kexts coming in a follow-up entry. (Thus I didn’t need to relocate to Miami. At least not yet.)

I wasn’t able to migrate the stuff from my previous Mac work drive due to space limitations, so I decided to postpone the MOX situation until after I could clear up more drive space and install Snow Leopard. I resumed work on the cross-platform toolchain and once I got it to produce what might be compiled files suitable for the Mac (at least according to the Linux utility “file” which identifies them as Mach-O object binaries) I decided they needed to be tested in the Mac (Darwin) environment for validation and to complete any unfinished details for a working cross-platform clang-based toolchain. (I’ll write an entry and submit patches back to the clang project if successful.)

By this time I had already purchased a copy of Snow Leopard after the Tuesday, November 30th meeting of the North Florida Ruby Brigade (a great bunch of guys with a penchant for more than just Ruby-related tech. I really hope we can help achieve a critical mass for a high-tech community in the Big Bend area), so I set about researching to what extent it was possible and what was required for my four year-old pc.

Not much, as it turns out. I’ll post an entry with details on it later, but a lot of the online info is very obsolete. The work of those in the OSX86 community and the guys of Voodoo Labs has been outstanding in making installs quite simple these days. Install Chameleon, install MOX, replace the standard kernel if needed, and install kexts for your machine if needed.

So Snow Leopard booted on my pc yesterday, and finished migrating my data (more or less) today. It took less time to install SL on a freshly-formatted drive than it took to migrate my data (no way to skip the directory on my hard drive holding my music files? Really?).

There are some things I’ve yet to work out, but I can at least continue developing for Macs. I’m currently unable to test on PowerPCs and Tiger, which I will correct with replacement hardware eventually; but at least Xcode still builds apps for them.

Xcode is running well (apparently). I’ve compiled Mori and some other projects, and finding some of the SL-related problems users have complained about. I’m trying to fix those up for another Oneill release today. But whether I can correct all those bugs beforehand or not, there will be a new snapshot to see if this set up actually works.

One thing I can report after using a current Linux system during this time, which was evident even within a day, is it will in no way become the preferred desktop platform for users who regard computers as a tool for other work rather than a gadget to be played with for its own sake.

My sincerest apologies to anyone attempting to contact me recently. Close to two weeks ago, my iMac G5 began to shut itself off. What happens is that as it boots, sometime after loading its kernel extensions, it will power itself off. This has happened a couple times before, but not as long as this time. The last time, it had just turned Spring. Now that it happened when the cold weather set in here in North Florida, I suspect its climate-related. I plan on relocating to South Florida at the end of the month in hope that it will correct this problem, but it’s no guarantee that it will.

In the meantime, I’m using an old PC running Linux to access the Internet. And I’m really annoyed to find that a lot of sites have some terrible incompatibilities with five year-old browser technology. I cannot access my email, nor my Twitter nor Facebook accounts. So there’s now a customer service phone line, (626) 667-4285, for you to reach me in addition to leaving comments on this blog or the user forums. For now, these are the only means I have to respond to anyone’s attempts to contact me.

I’m attempting both to fully upgrade this machine to current versions of Linux and get a working installation of MOX so I can continue work on Mori for a release before the end of the year. I apologize for the inconvenience in delays once again, and will provide additional information as the situation improves.

Update: I forgot to mention that I got help from the great folks at NSCoder Nights in San Francisco when mucking about the installer and Xcode files. Particularly helpful were Bruce Spath and Dan Grover. Thanks again, guys!

Here’s how you can install the iPhone SDK for 2.2.1 on a Mac running at least MOX 10.5.5:

1. Ensure you have at least 6 gigs of disk space available. If you have tried to install the iPhone SDK on the target volume before, it may state an upgrade will be performed instead of an install. Sadly, the only solution I currently have for this situation is to uninstall Xcode using /Library/Developer/3.1/uninstall-devtools.
2. Download the SDK disk image.
3. Mount the image by double-clicking it.
4. Copy the mounted volume to a hard drive.
5. Navigate to iPhone SDK.mpkg/Contents/iPhoneSDK.dist in the copied folder and replace line 340 which should be
start_selected = "isIntel() && hasRightOS() && agreedToSLA()"

with
start_selected = "true"

6. Run the installer, selecting either the default location /Developer or another directory name if you’re looking to preserve your current Xcode installation.
7. After a successful installation, navigate from the installation directory (default of /Developer) to /Platforms/iPhoneSimulator.platform/Developer/Library/Xcode/Specifications/iPhone Simulator Architectures.xcspec, and make the following two changes.

First, replace

{ Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = ( i386 );
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},


with

{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: i386)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
i386,
);
ArchitectureSetting = "ARCHS_OLD_STANDARD_32_BIT";
},
{
Type = Architecture;
Identifier = Standard;
Name = "Standard (iPhone Simulator: ppc)";
Description = "32-bit iPhone Simulator architectures";
ListInEnum = YES;
SortNumber = 1;
RealArchitectures = (
ppc,
);
ArchitectureSetting = "ARCHS_STANDARD_32_BIT";
},


then, replace

{ Type = Architecture;
Identifier = i386;
Name = "Intel";
Description = "32-bit Intel";
PerArchBuildSettingName = "Intel";
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},


with

{
Type = Architecture;
Identifier = i386;
Name = Intel;
Description = "32-bit Intel";
"PerArchBuildSettingName" = Intel;
ByteOrder = little;
ListInEnum = NO;
SortNumber = 105;
},
{
Type = Architecture;
Identifier = ppc;
Name = "Minimal (32-bit PowerPC only)";
Description = "32-bit PowerPC ";
"PerArchBuildSettingName" = PowerPC;
ByteOrder = big;
ListInEnum = No;
SortNumber = 201;
},
{
Type = Architecture;
Identifier = ppc7400;
Name = "PowerPC G4";
Description = "32-bit PowerPC for G4 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 202;
},
{
Type = Architecture;
Identifier = ppc970;
Name = "PowerPC G5 32-bit";
Description = "32-bit PowerPC for G5 processor";
ByteOrder = big;
ListInEnum = NO;
SortNumber = 203;
},


Now go ahead and start Xcode and when you select the “File > New Project…” menu item, you should see a darling iPhone category for projects. Also, run the iPhone simulator in /(Xcode install path)/Platforms/iPhoneSimulator.platform/Developer/Applications/iPhone\\ Simulator.app, it’s really mind-blowing to run it on your desktop, especially one Apple tells you isn’t able to run their iPhone SDK.

By the way, if you don’t feel like going through these steps yourself I’ve put together iPhoneSDKonqueror, an app which will handle these steps for you in a mostly automated manner. You should buy it. It’s only USD$5 and if you appreciate the ability to use your PowerPC Mac to write apps for the iPhone, it’s the right gesture to make to me.

I drove with the top down, to clear my head.
The night was cool and quiet. And though it looked and sounded
much like South Florida when I drive like this, on nights like this;
To clear my head, there was no oppressing tension as there usually is in South Florida.

Like there is when I have to work several times harder to clear my head.
For the hot light to turn off, to clear my head.
And the cool light to turn on, and space is tranquil.
Because in South Florida the hot light stays on when you try to clear your head,
and the extra work keeps you from being able to fully clear your head.
And you can’t work there as well as you can here, once you’ve cleared your head.

So now, on to get a new Oneill build out.

I know I didn’t make it easy to figure out what I’m talking about. I just couldn’t make it obvious enough that you could Google for the answer, and still have decent mood. But don’t forgot, friends, Big Daddy does love you.

Back on August 27 of this year I stated the release of Mori 1.7 was imminent due to the acquisition of an encryption utility which would provide the core of the reworked 1.7 feature list. That has now been four months. So once again I failed to deliver on the expectations I’ve set before you, and for that I apologize. I’ve just uploaded a new alpha test release (code-named Oneill) for your inspection, but before I list the specific features it contains I’ll explain why it’s taken so long, and why it’s only an alpha.

After I announced the changed development plan, one forum member wrote,

Most of the announced features [ie, "LinkBack, customized labels, font settings for source & entry views, better keyboard navigation, outlining improvements, self-downloading updates, and now encryption"] have either been tried to some degree in the failed versions, or are of marginal usefulness.

In my response I outlined the terrible decision I made to replace Mori’s view system with a more advanced, revamped one and how it was important to get new features (including encryption) into users’ hands now. I also disagreed with his characterization of the new feature set as trivial and tried before. However, I also offered to let you, Mori’s users, decide whether to include encryption in Mori and whether I should delay Mori 1.7 to get the new view system working or continue with the new course I had set to produce a new version quickly.

Although only 11 votes were cast on whether to delay, it was overwhelmingly pro-delay (even with my 1-star vote). So I decided to compromise and add some of the new view system and the originally promised features to Mori now, and continue making piecemeal changes afterwards.

Of course I should’ve mentioned my decision to you before, and for not explaining it to you I’m sorry. Once I made the decision, however, I just withdrew and set about getting the job done. (Although I hadn’t entirely withdrawn. As some have noted on the forum, I am far more communicative on Twitter as it limits content to 140 characters, which is very lightweight as a conversing medium. Unfortunately, I’m only aware of one Mori user who’s on Twitter and has made his presence known. Hi, Dale!)

So now that I’ve put out a new Oneill release, what does it actually contain? To quote from the release notes:

• Multi-line rows is in operation. There is a speed issue (not having it), and a horrible display bug when adding characters to a multi-line row, but the text displays correctly once edits are done.
• Users can now set different font styles for source and entry lists. Currently this setting affects all docs being displayed.
• Notes can be zoomed in and out either via a pop-up menu on the footer, or through the new “View > Zoom” menu (and corresponding shortcut keys).
• Users with MacBook Airs, and late 2008 model MacBooks and MacBook Pros can use gestures to zoom in and out as well.
• Users with a 3Dconnexion SpaceNavigator can use it zoom in and out as well.
• Various internal changes.

That’s right, you can adjust the font sizes for the source & entry lists, and zoom into your notes to make it easier for you to work with your info.

Multi-line entries for those extra-long topics or more complex outlines, as a start for the type of formatting you’ll be able to have in your Mori notebooks.

Support for gesturing and alternate input devices, starting with the multitouch trackpads on all the current Mac laptops and the 3Dconnexion Space Navigator.

So that’s where Mori’s development is now. I have more changes coming shortly, but I have a long drive ahead of me: Silicon Valley and Macworld 2009.

As I mentioned in my last post, I’ve made a pre-release of Cocoalogue available for the PMC bundle. Only one person took advantage of the offer, which was so surprising to me I had sent him a license for Clockwork because I didn’t realize what he actually purchased! So not only is he Cocoalogue user #1 for all time, he’s also the happy owner of a Clockwork license! (See what you all missed out on?)

A Simple Cocoalogue Overview

Cocoalogue is an interpreted computer programming system, oftentimes called a scripting system or dynamic language these days. While the system shares a great deal in common with the Smalltalk-80 system on which it was based, Cocoalogue’s current executable model is more like the one used for Perl, Python, Ruby, AppleTalk, any of the shell programs which have scripting support, etc. It also includes a Cocoa bridge to allow use of the Objective-C/Cocoa frameworks on Mac OS X, and extensions to the Smalltalk syntax to allow static typing, namespaces, and more.

There are four main components to Cocoalogue as it now exists: the language compiler, the virtual machine, and the run-time system. They are designed to function fairly independently, so modification of any component doesn’t adversely affect the others. They can also be replaced independently, so a language compiler for Ruby could be substituted, for example; or the run-time system can be replaced with one written for Apple’s Open Scripting Architecture. Also, they are generally written in C using POSIX libraries for portability, although some functionality was implemented in Objective-C/Cocoa for expediency’s sake.

What is this Smalltalk of Which You Speak?

Since I’m pimping Smalltalk so often, I should explain a little bit about it so you understand some basic Cocoalogue concepts. Smalltalk is a programming environment developed at Xerox’ Palo Alto Research Center (PARC), incorporating programming language, tools and user interface, that was originally designed for educational purposes in the hope that the researchers developing it would discover how to make computers easier to use. Windowing Graphical User Interfaces (GUI) such as used by all implementations of the Mac OS and Windows, and Integrated Development Environments (IDE) used by Xcode and Visual Studio are based on inventions arising out of the Smalltalk initiative.

Wikipedia has a more detailed explanation of the history and implementation of Smalltalk than I have space for here. But I’ll briefly cover its syntax to explain what Cocoalogue has. Resources, or objects, used by programs are represented as variables in the Smalltalk language, and are sent messages that represent the actions the programmer wishes the objects to perform.

rectanglesContainingX: xCoordinate andY: yCoordinate
| rectangles aPoint|
rectangles := OrderedCollection
     with: (Rectangle left: 0 right: 10 top: 100 bottom: 200)
     with: (Rectangle left: 10 right: 10 top: 110 bottom: 210).
aPoint := Point x: xCoordinate y: yCoordinate.
^ rectangles select: [:aRect | aRect containsPoint: aPoint].

The example is for demonstrating Smalltalk syntax, not coding quality; so don’t use it as a template for your own work. It defines a method named #rectanglesContainingX:andY: that returns an OrderedCollection, or list, of rectangles which contain a specific point given as an x-y coordinate, and represented in the example by xCoordinate and yCoordinate, respectively. The method defines two temporary variables, rectangles and aPoint, which are used to hold values computed for use while the method executes. The method creates an OrderedCollection object with two rectangles for elements (technically, it sends the message #left:right:top:bottom: to the Rectangle class two different times which has the responsibility to create the two rectangles, and those rectangles are then sent to the OrderedCollection class as part of the #with:with: message) and assigns the result to the rectangles temporary variable. It then creates a point for the given x-y coordinate (again technically, it sends #x:y: to the Point class along with the x-y coordinate). The last statement sends #select: to the OrderedCollection object represented by the rectangles variable, which has the responsibility of going through each rectangle element in the collection and finding every one which meets some criteria, passing the criteria test in an executable sequence of code as an object called a block. The collection’s #select: method returns a new collection which contains all the elements matching the test “contains aPoint“. The #rectanglesContainingX:andY: method then returns that result to whatever object called it.

Cocoalogue Isn’t Smalltalk

As much as I love Smalltalk, and have made having a professional-grade programming environment based on Smalltalk my goal, strict adherence to Smalltalk isn’t my objective for Cocoalogue. My objective is to create a development and work environment based on the interactive model I enjoyed using systems such as Squeak, BASIC, and Instant-C; which incorporate modern code development and management tools such as SCM; and use of legible programming languages such as Smalltalk. I’ll spell out the major deviations from Smalltalk systems as I outline the components below.

The Cocoalogue Run-Time System

The run-time system is itself composed of four parts: the memory management system, which uses an indirect pointer similar to relocatable blocks on the classic/Carbon Mac API combined with reference counting; the data types system, which permits the definition of types and their operators; the class library, which provides the pre-defined types and classes used to write programs; and the Cocoa bridge (it’s odd that there are Wikipedia entries for PyObjC, CamelBones, RubyCocoa, but none for Cocoa bridge) which allows interaction with objects created or used by Mac OS X’s Cocoa frameworks. Soon, the Cocoa bridge will also allow the declaration and invocation of normal C functions, but the syntax to do this hasn’t been finalized yet.

Cocoalogue’s Run-time Differences with Smalltalk

The largest distinguishable differences the current implementation of Cocoalogue has with Smalltalk are

• lack of a persistent image;

  Although it would be relatively trivial to provide an image-based environment typical to Smalltalk implementations, I’ve forgone support in Cocoalogue’s current implementation to speed up development of other features. In addition, as the supported classes and functionality undergoes enhancement it’ll be best not to keep an image around which will undergo repeated changes to its fundamental objects.

• fine-grained control over the execution environment;

  To support the ability to define types of arbitrary width (such as Smalltalk’s LargeInteger and Fraction) a type must be able to specify how, and whether, exceptional conditions should be handled by the run-time system. For the LargeInteger class, calculations which result in either over- or under-flow conditions should cause the class to widen the resulting object to fully contain the result whereas for types having an Int32 specification should discard the excess result bits, yet still permit the method or object which invoked the operation to know or respond to the exception itself.

• Cocoa classes instead of Smalltalk’s;

  Smalltalk-compatible classes aren’t developed yet, so programming still requires familiarity with the Cocoa frameworks. Literals are instantiated from the corresponding Cocoa classes (NSNumber, NSString, etc.).

• DataType vs Object as fundamental type primitive;

  To support primitive types for languages such as C, all types are derived from DataType in Cocoalogue’s language by specifying their widths in Bits, a concrete subclass of DataType. Operators are declared and invoked via the standard Smalltalk syntax so the functionality is inherited by Objects.

  DataStructure is an abstract type derived from DataType and which defines aggregate structures whose members’ alignment and packing can be specified by the programmer, or the environment by default.

  DataShared is an abstract type derived from DataStructure which defines structures whose members share the same offset from one end of the structure so their members “overlap” in storage.

  Object is a concrete type derived from DataStructure which acts as the base type for all data types of the standard OOP model, and can contain either objects or DataTypes.

• Classes don’t need a Metaclasses support object;

  Rather than maintain Smalltalk’s legacy of Class/Metaclass structure for inheritance, class methods, class variables, etc., I’ve shifted the classical class-based model into the DataType/DataStructure/Object/Class framework. This will allow the addition of other execution architectures into the run-time system.

Cocoalogue’s Virtual Machine

The virtual machine is a hybrid of abstract syntax tree and bytecode techniques to keep semantic info sufficiently close to executable code for debugging purposes and to give me enough leeway to optimize along any of several directions. They’re stored in sequences as literals along with standard data type literals, and are nestable and suitable for parameter passing to allow the declaration of the expected Smalltalk blocks (closures) as well as other sophisticated techniques for specifying code order and execution.

Cocoalogue’s Compiler

The compiler handles an extended version of the Smalltalk grammar that allows the specification of explicit types, bit widths, and byte-ordering for data. I sought to maintain strict conformity with Smalltalk syntax as much as possible, except perhaps for a place or two where I thought the syntax was inelegant. The additions to the syntax I made are generally in keeping with the beauty I found in the syntax, although admittedly with my own biases.

Cocoalogue’s Compiler Syntax Differences with Smalltalk’s
One of the basic questions for an explicit-typing extension to Smalltalk is, what does it look like? For Cocoalogue, one of the ways types can be specified is like this:

variableDeclaration = variableName ‘::’ className { inflection }.

wherever a variable is declared for use as a parameter, temporary, instance var, etc. inflection can be a type modifier such as ‘signed’ or ‘unsigned’, an array specifier [delimited by '(' and ')'], or a pointer specifier (‘^’).

Smalltalk methods always pass a result back as an object, even when a result isn’t specified through the return (‘^’) expression when the result is the object currently executing the method in question. Thus Smalltalk methods have no syntax to specify the result. So Cocoalogue also has an extension to allow the type of the result to be specified. The default type for the result is Object. Otherwise, the result’s type is specified by appending “::^ className { inflection }” to the method’s message pattern. The Smalltalk example code given above might now look like the following in Cocoalogue:

rectanglesContainingX: xCoordinate::CGFloat andY: yCoordinate::CGFloat ::^ NSArray^
|  rectangles :: NSArray^.
   aPoint :: NSPoint.
   each :: NSRect.
   enumerator :: NSEnumerator^.
   selectedRectangles :: NSMutableArray^. |
rectangles := #( (NSRect x: 0 y: 100 w: (10 - 0) h: (200 - 100))
                        (NSRect x: 10 y: 110 w: (10 - 10) h: (210 - 110) ).
aPoint := NSPoint x: xCoordinate y: yCoordinate.
enumerator := rectangles objectEnumerator.
selectedRectangles := NSMutableArray alloc init.
[(each := enumerator nextObject) != nil]
     whileTrue:
          [[eachRectangle containsPoint: aPoint]
               ifTrue:
                   [selectedRectangles := addObject: eachRectangle]]].
^selectedRectangles

In accordance with the Cocoa frameworks, view coordinates are expressed from a normal Cartesian (bottom-left) orientation. As you can tell, the bulk of the code is to make up for the lack of support in Objective-C for closures which results in it being unsupported in Cocoa. When Smalltalk-like collection classes are added to Cocoalogue, the bulk of this example will be significantly reduced.

That’s a little overview of Cocoalogue as I promised in my last post. Once Mori 1.7 is released I’ll be able to continue completing basic Cocoalogue functionality. The main purpose of releasing it in scripting model form is to get it released and into use quickly. “Enhancements” (read greater Smalltalk class support) and surely bugfixes will follow.