[|] Less is More

Cincom Maintenance Releases – updates

In the last post/digest article we noted important changes that we are making in our releases and release process, to better meet customer requirements, based on feedback we are getting from customers (see here).  The fall Cincom Smalltalk releases will be true maintenance “service pack” releases, and introduced in between major releases. 

We are also experimenting with the delivery mechanisms of the maintenance releases, with full installations or in-place updates.

The fall maintenance release full releases will be:  ObjectStudio 8.3.1 and VisualWorks 7.8.1.

VisualWorks will have an optional process to update a 7.8 installation.  The future target will be online updateable maintenance service packs.

What is your preference for delivery?  Please let us know your ideas and suggestions!

Regards

               Arden Thomas athoms@cincom.com

               Cincom Smalltalk Product manager

Cincom Smalltalk release cycles:  Fall Release and future releases

The Cincom Smalltalk group is always looking for ways to improve our products.  This includes adding new features, refining and improving existing features, and trimming out unused features of the product. 

But we also examine and improve other related areas, such as our engineering process, and release cycles.  Based on feedback we received from listening to and talking to our customers, we have made some changes to our release cycle.

Customers requested a true maintenance release that represented refinements and fixes to the major release, and did not include significant new features and functionality, which could represent more work for porting and production application certification. 

Additionally, we wanted to modernize and improve delivering fixes and refinements in between major releases, more similar to how most major software products provide updates.

We heard our customers:  This fall you will see service-pack maintenance releases for our Cincom Smalltalk products.  This release is a true maintenance update as requested by Cincom Smalltalk customers.

In future release cycles we plan to have one major release annually along with service-pack online releases at regular intervals.  The service-pack releases will have refinements, fixes and updates to the major releases. 

The Cincom Smalltalk group (including engineering, support, marketing and product management) is always looking for better ways to serve our customer’s needs.  If you have ideas for new features, fixes, refinements or any suggestions for Cincom Smalltalk products, we want to hear them.  Send your feedback and suggestions to athomas@cincom.com.  Thanks,  and good Smalltalking to you!

Regards

Arden Thomas

Cincom Smalltalk Product manager

athomas@cincom.com

Farewell to an American Icon who “got” Smalltalk

Although Steve Jobs had been battling cancer for a long period of time, it was still a shock to read of his passing. 

Steve Jobs “got” Smalltalk – he understood the impact of the work done at Xerox Parc.  His early work resulting in “Lisa” was done in Smalltalk.  He brought the GUI work originally done in Smalltalk to the masses.

More importantly, I think Steve Jobs understood the bigger picture of what the Smalltalk research work was all about – Smalltalk is all about making computers easy to use by anyone.  You can see this theme in Apple products, be it the Mac, iPods or iPhones.  They are simple, easy and practical to use.  As many of you know, making something simple and obvious is usually a lot of very hard work – it only looks simple and obvious when you get the right result.

Steve Jobs had an incredibly unique and amazing life story.  His work reached millions and raised the bar for products he touched.  He will be missed. RIP Steve Jobs.

Performance tuning - “Know what you are sorting”

You probably know our Smalltalk products support CLDR based internationalization, which is incredibly useful for building applications for use with many languages deployed througout many parts of the world.

Unicode, the basis of internationalization frameworks, makes sorting significantly more work, computation wise.

Cincom engineers are working on techniques to improve the performance of full unicode sorting.

Even if you don’t use the internationalization capabilities, you will probably want to know about this for potential performance tuning.  Knowledge is power!

StringCollationPolicy  is a class with the following comment:

“There are several collation algorithms available:

Fastest -- Strings are sorted based on the values of the characters. No intelligent case folding is done, so that for example, A < B < a < b. This is very fast, but not usually what a user would expect to see.

Fast -- The default collation algorithm for previous versions of VisualWorks. Case folding is done, but the algorithm is otherwise relatively primitive.

Unicode, low priority punctuation -- Unicode compatible collation. White space and punctuation characters are ignored unless the strings can not be distinguished based on letters, accents, and upper / lower case.

Unicode, high priority punctuation -- Unicode compatible collation. White space and punctuation characters are treated as first-class characters, with more influence over collation than distinctions like accents and upper / lower case.”

Lets run a simple test, sorting strings from a text file:

file := 'FAQ.txt'.

stream := file asFilename readStream.

[stream atEnd] whileFalse:[lines add: (stream upTo: Character cr) ].

StringCollationPolicy collationAlgorithm: #UnicodeWithPunctuation.

Transcript cr; show: [lines asSortedCollection] timeToRun printString.

StringCollationPolicy collationAlgorithm: #UnicodeNormal.

Transcript cr; show: [lines asSortedCollection] timeToRun printString.

StringCollationPolicy collationAlgorithm: #Fast.

Transcript cr; show: [lines asSortedCollection] timeToRun printString.

StringCollationPolicy collationAlgorithm: #Fastest.

Transcript cr; show: [lines asSortedCollection] timeToRun printString.

Results:

100.806 milliseconds

80.348 milliseconds

4.105 milliseconds

4.15 milliseconds

Good coding to you  - Arden Thomas

Future Predictions

Most of you are probably reading this on or through the internet.  Twenty to thirty years ago, who could have predicted the impact the internet and the many technologies developed at Xerox PARC would have on us today?

Most predictions seem to be advancements of things we have some familiarity or a grasp on already.  Why?  It is much easier that way.  Ask for predictions about the future in transportation and you will get predictions of cars that can drive themselves, have advanced power systems (battery, fuel cells, etc). The point is, they are all basically derivative of what we have today.  To really envision something completely different is a much harder task.   For transportation, a non-evolutionary future would be something like a transporter (from Star-Trek science fiction) or something equally completely different than what we have today.  Maybe virtual realities can advance so much that much of today’s actual physical travel (at least for business perhaps) would be unnecessary?

Predicting the internet, or even the graphical user interface are examples of things so different, it is hard to imagine it, or even see it coming. 

This brings me to a man and a well-known quote:  “The best way to predict the future is to invent it” – Alan Kay.

Alan, as most of you are aware, is the father of Smalltalk and object-oriented programming.  Alan and others at Xerox Parc were responsible for “game changing” new technologies.

Alan will be speaking this month at HPI.

I think that one of the best things about Smalltalk is that it has remained linked to innovation.

Can you imagine any game changing ideas of the future in software?  Invent it!  Smalltalk is a good place to start.

- Arden

The Project Launcher

A couple things always bothered me about our installations on Windows and Mac platforms.  We would have a very attractive icon installed on the desktop, but I would never use it.  I would instead, like I believe most folks do, go to my image directory, and double click on an image in order to start it up. Another problem - if a newbie was exploring or evaluating the product, they would use the icon (it launches visual.im), but they would not likely be aware of the typical use pattern of;  start visual.im, save as myProject.im, use the image.   More likely they would repeatedly use the icon, which would mean they would never likely start with a truly clean image, and it might add confusion about how to best use the product.

Enter the Project Launcher

The goal of the Project Launcher is to make good use of that desktop or launcher icon, and provide utility to both new and experienced users of the product.

What does it do?  Basically it does three things (at least for now, much more can be added); 

1)      it allows you to create a “project” by saving a clean image as your project.im

2)      it gives you a list of your projects (images) and lets you launch the project (image)

3)      It stores things in the right place by creating a directory in the users “write” space  (Where the product installs is supposed to be read only)

For the experienced user, this is a convenient place to quickly and easily launch an image they wish to work on.  For those developers who like the current way they start images, the project launcher is completely optional, and not a forced choice.

For a new user it manages or teaches the process of naming a project (image) and about keeping a clean starting point.  It also provides a central point to launch or start any of their project images.

How do you access the project launcher?  Simply click on the “molecule” like product icon that gets installed with the product.

Next time, I’ll discuss more about the project launcher, including using automated builds with the project launcher.

Good Smalltalking to you!

               Arden Thomas

               Cincom Smalltalk Product manager

               athomas@cincom.com

The “Smalltalk “ of super-cars.

I enjoy occasionally noting things with design principles similar to Smalltalk – a simpler “less is more” approach, that focuses on what’s important, and leave out what is not, combined with careful design.

So, I was watching a rerun of the popular BBC show, “Top Gear” last week.

They included a race between two supercars – A McLaren F1 (a design I have long admired) which was introduced in 1992, and a Bugatti Veyron, a car introduced in 2003, and at 2.6M, the most expensive production car in the world.

Both cars are amazing feats of engineering and design, but both are rather different in their approach.

The Veyron takes a “more-is-more” approach.  Think one turbocharger is good?  Then two must be better – and the Veyron uses four!  Twelve cylinders is quite a number, so the Veyron uses sixteen. The Veyron’s motor puts out roughly 1000 horsepower.  How to keep it all cool?  The Veyron has ten radiators total! The Veyron has a 7 speed DSG transmission (I do like the DSG design), all wheel drive, and weighs in at 4162 lbs.   The car is amazing – a technological tour-de-force, but I’d hate to get the maintenance bill! :-)

Contrast that with the McLaren F1.  The first thing you notice is the innovative seating.  The driver sits in the center of the car! (how cool is that!?), with two flanking and rearward passenger seats.  The F1 was the first production car to use a carbon fiber chassis.  Carbon fiber is light and strong, and the F1, at 2513 lbs., weighs much less than the Veyron does.  The F1 uses a BMW V12 engine, naturally aspirated (627 hp, no turbochargers), and a six speed manual transmission.    Air is carefully handled for ground effects, and high pressure zones created by the spoiler are used to cool the brakes – nice integration.

The design philosophy of the F1 seems to focus on carefully designing and integrating only the important things.  The F1 is also notable for what it doesn’t have – no all-wheel-drive, no ABS braking or traction control, no turbochargers – simply unnecessary with a good design of the fundamentals. It is meant to be a drivers car.   Good design, less-is-more, and innovation:  definitely a Smalltalk approach!  :-)

So how did the 1 mile race go?  As always, top gear is very entertaining.  Off the line, the McLaren walked away from the Bugatti, leaving the Bugatti pilot exclaiming “How is this happening!?”  At about 1/3 of a mile, the much higher horsepower of the Veyron overtook the McLaren.  See it here: McLaren vs Bugatti

Of course, like computer languages,  performance cars bring passion and strong opinions, such as the McLaren boss declaring the Veyron a “piece of junk”, and “described how the V12-powered F1 trounced the 16-cylinder Veyron so many times off the line that the filming crew got frustrated because his car was supposed to be beaten. Eventually the Veyron stopped dropping its clutch on take-off and was able to catch up to the McLaren F1”. 

Read  more: Piece of junk

I suppose you could make an argument for either machine winning.  Still, the McLaren, which was designed over 15 years earlier than the Veyron, is amazing.  Credit the F1 with a simpler, easier to use and maintain design.  I admire the McLaren, and its design principles, the most.

Other notes:  McLaren’s latest car is the MP4-12C, which is the spiritual successor to the F1.  The MP4-12C  adds technology and more innovations to the F1 principles, such as a type of “brake steering” for more driver control. The F1 still measures up well against the MP4-12C, which incorporates more modern technology, however, the 12C will not be a lone child – expect more potent variants in the future!

Polycephaly – finding the sweet spot

Recently I have written posts about the benefits of using Polycephaly.  If you were at Smalltalk Solution 2011, you probably saw my presentation about using it, and descriptions of experiments I ran.

The sweet spot refers to the question: “How many virtual machines should I run (using Polycephaly) to maximize my throughput?”. 

Many times you can run iterations of the test, using a different number of vm’s for each run and benchmark it.

Another general approach is to use a rule of thumb guide of 1.5 vm’s per core.  This seems to work pretty well.

Some observations:

The 1.5 vm’s per core seems to work pretty well, maybe too well!  It may be the ideal for maximizing the throughput on a server.  However, I ran into an issue using this.  Using 1.5 vm’s per core so thoroughly utilized the full power of the cpu cores, that I rendered my machine largely unresponsive for browsing the web, reading email, or running another application – a victim of my own success! :-)

My main machine has a quad core cpu, so I was running 6 additional vm’s.  In the task manager, a process is maxing out the core when it show the maximum 25% utilization (25% overall of cpu).  Running 1.5 vm’s per core means that when a vm takes a “breather” – performs IO or some other non cpu intensive task, that another process is there waiting to utilize the cpu to its full extent.

Solution?

I found the solution to be fairly obvious.  If I wished to make use of my machine for other tasks, I simply ran three virtual machines, to do the work.  This meant that three vm’s were usually maximizing three cores of the cpu;  the main image collected information from these three, but did not overly tax the cpu’s fourth core when it was allocated time.  The fourth core was essentially available to make my machine responsive in browsing the web, reading email, or running another application.  So for a small reduction in maximum throughput, the benefit was a usable versus non-usable computer, a very beneficial tradeoff!

Have you come across any gems or keen insights in using Polycephaly?  Please share!

Regards

               Arden Thomas

athomas@cincom.com

Polycephaly

This month I will be giving a presentation at Smalltalk Solutions about Polycephaly, the Cincom Smalltalk framework for leveraging multi-core processors.  Come see the presentation, if you can, for more information and results of experiments with Polycephaly.

I’d like to see more customers benefitting from the advantages of Polycephaly, so I thought an example would be useful.

Suppose your company processes records for all of its customers, daily.  (This could be doing any kind of processing, as this is a generic example).

First, we need a way to segment our customers, as a basis for processing groups of customers concurrently.  A simple way to divide customers would be by the first letter of their last name.  So we will process all customers whose last name begins with “A” as one group, “B” as another etc, … “Z”.

Let’s start with a method that gives us a collection of “A” to “Z”:

aToZ

               “Letters A to Z”

               "This is a SharedQueue for managing concurrent access"

               | queue |

               queue := SharedQueue new: 26.

               (10 to: 35) do:[:ea | queue nextPut: (String with: (Character digitValue: ea)) ].

               ^queue

Now let’s create a method to control and distribute the processing, and call it processAToZ

 processAToZ

"self processAToZ"

"This is a generalized example of how (one way) to use Polycephaly for using multiple cores to solve a problem.

This is an example of breaking our universe into pieces to process by letters - for example it could process all customers with last names beginning with 'A', all with 'B', etc, separately."

| letterQueue done results vms |

letterQueue := self aToZ.              "A collection (SharedQueue) of letters A .. Z "

done := Semaphore new.             "To make sure we wait until all processing is complete before proceeding"

results := SharedQueue new.      "Use SharedQueues for safe concurrent access"

vms := Polycephaly.VirtualMachines new: 3.   "Create three headless processing images - benchmark different sizes to see what works best for you"

"below we fork as many processes as we have machines (headless processing images). 

Each process grabs a letter, then sends it to the machine for processing

Results are returned and added, and then another letter is grabbed, until there are no more.

Only after there are no more letters to process, it releases the machine (closes the image) and signals its completion"

vms machines do: [:machine |

[ | letter |  

[letter := letterQueue nextAvailable.

 letter isNil] whileFalse: [results nextPut: (machine do: [:ch | ProcessAtoZ  processLetter: ch ]  with:letter)].

        machine release.                 "Shut down the vm"

       done signal] fork].                "Signal that the machine has completed its work"

vms machines  size timesRepeat: [done wait].  "Wait until each machine has reported in as completed"

^ results

That’s it!  OK lets implement a trivial #processLetter: so this does something we can see:

processLetter: letter

                | letters |

               letters := OrderedCollection new: 100.

               1 to: 100 do:[:n | letters add: letter ].

               ^letters

If you want a parcel with this code, send me an email  athomas@cincom.com

To use this code, start an image, load Polycephaly, load this parcel, then save the image!!! (since the headless images started are copies of this main image, they will not work with Polycephaly, nor be able to do #processLetter: unless you first save the image), run my #test method (in my pcl) to make sure poly is working properly, then inspect the results of #processAToZ. 

 Congratulations!  You now have a means of boosting performance on some of your applications!

 I hope you find this interesting and valuable.

 -        Arden

Deployment experiments for simpler deployment.

This month I wanted to share some thoughts on deployment, and get some comments, ideas and feedback.

Deployment in VisualWorks (should apply to ObjectStudio too) typically involves using Runtime Packager, which is a very capable, but non-trivial process.

So what is the minimal we can do if we want simple and trivial deployment?  It would probably be used for for small applications or for testing.

To understand this better, I set out to experiment with deployment of an application, with the goal of making it as simple as possible. Here is what I did, fairly explicitly, in case you want to reproduce it:

Create a runtime image:

1.      Start Base.im (found in /preview/packaging, save as deploy.im)

2.      Load the runtimepackager parcel

3.      Start runtimepackager (tools -> Runtime Packager)

4.      Click ‘next’ until I am at the last stet, ‘Strip and Save image’, save the image (checkpoint)

5.      Click ‘Do this step’

6.      Move runtime.im to my image directory

Create an application parcel:

1.      Start visual.im, save as dev.im

2.      Load StoreForPostgresQL

3.      Connect to Cincom public repository, browse published items

4.      Load ‘SpiderSolitaire 1.7 released’ bundle (Solitaire application by Dave Buck)

5.      Open system browser, find SpiderSolitaire

6.      Right click on SpiderSolitaire, choose ‘publish as parcel’.

7.      Save and quit image

Create a cmd file (Windows) to start the application (Solitaire.cmd) :

@echo off

@Start ..\bin\win\visual.exe runtime.im -pcl SpiderSolitaire.pcl -doit 'SpiderSolitaireUI open'

Launch application, try it, close it, verify engine has shut down  … all good!

OK, now that I have a runtime.im, simple creation / deployment looks like this:

1.      Publish a parcel

2.      Create the cmd file

Thats it!  nSimple and effective.  Also note if you need to load several parcels, you can use the –cnf command line option, and list the parcels in a file.

Questions:

Should we provide a runtime.im version of base to save some steps?

I’d like the application start not to show the command prompt window, but have not found the right parameter.  Share if you know, comments welcome!

The Forgotten Smalltalk Language

Smalltalk, forgotten?  Certainly not by those of us who use, rely, or enjoy, arguably the most powerful computer language ever developed so far.  But maybe it has been forgotten by the mainstream.

A short anecdote and analogy:

Every year in the summer I go camping with my family, by boat and tent.   Both boating and camping are a great opportunity for using appropriate knots and bends, in order to secure the boat to its dock,  tying parts of the tent, tying a tarp shelter to the trees, etcetera.  So every year before camping I try to re-familiarize myself with the most essential knots, concentrating on the handful of knots that are the “best-in-class” or best in terms of utility, strength, or versatility.  Then there tend to be some variations in many of the best also, which makes it interesting.  So I practice my clove hitch & constrictor, bowlines, adjustable grip hitch and figure 8, to round out the basics.

Many years ago I stumbled on a “new” knot, called the Zeppelin (or Rosendahl) bend.  It is called a Zeppelin bend because it was used to tie down 46 ton airships, back in the day.  This knot is largely unknown (that has been changing), and was almost forgotten.  This is one of my favorites!  It is simple, strong, secure, beautiful and symmetrical. It is easy to tie, and, more importantly, untie.  It is the epitome of simplicity, because, in a way, it is simply the combination of two overhand (simplest knot there is) knots, combined to make something ultra-capable.  To many, myself included, this is the best-in-class bend.  And it was almost forgotten! 

I have used it to tie a winch cable that had snapped, back together for temporary use; I have used it to tie nylon tow straps together to help someone pull a car out of a ditch.  It is amazing that after heavy forces have been applied, you can still actually untie it when needed.

So the Zeppelin bend is the Smalltalk of knots.  Simple, powerful, beautiful and useful. The best there is, yet almost forgotten.  Thankfully, after the bend was rediscovered, it is becoming much better known, and today I find it in most current compilations of knots and bends.

So, by analogy, can we make predictions about the re-discovery of Smalltalk?  My prediction is not “if” but “when”. :-)    People continue to innovate, experiment, and build new Smalltalk implementations.  At some point a new innovation could cause Smalltalk to reach the tipping point, and bring awareness and usage of the language back to the forefront.

Have some fun and learn the knot below!     Comments welcome.   - Arden

The Forgotten Zeppelin Knot

How to Make a Zeppelin Bend Knot

Polycephaly

What is Polycephaly?  Polycephaly (the word means “many heads”) is a framework that allows you to leverage multi-core machines and increase your throughput through concurrency. 

Some things you may not know about Polycephaly:

• Polycephaly works with ALL our Cincom Smalltalk products.  Look for an upcoming blog post by the ObjectStudio team who used it to reduce testing time.
• Customers are successfully using Polycephaly!
• Polycephaly is “Smalltalk simple” (by design).  This helps you avoid some typical pitfalls and problems of using concurrency. 

- Arden

Cincom Smalltalk – recent past, present, future

At ESUG 2010 near Barcelona Spain (I recommend this conference, always interesting!), I presented a roadmap update on Cincom Smalltalk products.  You can see the presentations here:

http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Cincom_Smalltalk_Product_Roadmap&entry=3464518421

or

http://vimeo.com/groups/4961/videos/15839054

Questions, comments, suggestion?  Please contact me at athomas@cincom.com