I’ve just uploaded my port of Joseph Pelrine’s Toothpick logging Framework to VASTGoodies.com.
If I say port, I really just mean minor changes. Toothpick as it can be downloaded from Joseph’s corporate MetaProg page does load and run on VAST, but I had some issues with it. The main problem I had was that Toothpick subclasses AbtTimestamp and the subclass is named Timestamp. Unfortunately, GLORP also defines a class named Timestamp, so you cannot have both in an image. While I think neither subclassing AbtTimestamp nor naming the subclass Timestamp (which is the name of the Timestamp class in all other Smalltalk dialects I know) is a good idea, I decided the easiest way to get around this is to rename the Timestamp class in Toothpick to Toothpick Timestamp.
Another mini-problem with Toothpick 1.1 is that it implements some extensions to base classes that Instantiations has added in VAST 8. So if you load the original version of Toothpick 1.1 into a VAST 8.0 image, you will get warnings and the ToothpickPreload application will become a scratch edition. Not really an issue, but if you use some automation code in a project, you shouldn’t accept scratch editions.
Since I didn’t invest much work in this port, I did not solve the last-mentioned issue with configuration expressions for older and newer versions of VAST, so you may miss exactly these extensions in VAST 7.5 or older if you load Toothpick 1.1.b from VASTGoodies.
I want to thank Joseph for the work he’s done with Toothpick and for open-sourcing it. I think it’s a nicely designed, easy to use logging framework with a host of options to extend it if you need to, but very little configuration work to be done for simple things. You can get started with Toothpick in twenty minutes by reading through a few wiki pages.
I love using my Mac. I like my iPhone. The new Air is really an interesting piece of hardware.
Part of the reason I like my Apple products is that they run quite stable and offer a pleasant overall experience with installing/uninstalling applications. I also like the fact that I can use my Linux/Unix shell commands on it.
But there are times when I wonder how long I’ll like to use Apple products.
The newly announced MacApp Store will probably make finding and installing (and, of course buying) applications easier than ever. But there is a back side to the coin. Apple wants the experience to be as good as possible and so tries to keep everything out of the App Store that may disturb this. By explicitly disallowing all programming languages other than C/Objective-C and runtime environments, they try to make sure that you cannot install anything from the App Store that’s not perfect. But what’s perfect is defined by Apple.
As long as it is still possible to install software on a Mac that is not purchased in the App Store, I still have a choice, and if I want a Java/Ruby/Smalltalk/Clojure/Scala-written program on my Mac I still can do so. But what if Apple decides to lock Mac OS 11 completely and only allow Apps from their App store on it?
Will we have to jailbreak our Macs to run Eclipse or Pharo in a few years?
And what if Apple is succesful with this policy? How long will we be able to install software of choice on any other commercially available OS?
Let’s hope I am just dreaming a nightmare and reality is different…
James Robertson continues to publish greatly appreciated material on getting started with Smalltalk. His latest work is a little runthrough of VA Smalltalk’s installation on a Windows PC.
There’s one little comment I’d like to add here by linking to Instantiations’ installation guide (which is available online and can be installed as James shows in his video):
We recommend you install the manager before you install the client.
It’s no terribly important if you just want to work in single user mode, but in a multi-user environment you should have the library manager installed and setup before you install clients.
Thanks to James for all his hard work.
Back in 2006 when I made the move to a Mac, Apple had put a lot of effort into making Java/Swing Applications feel like native on Mac OS. Adopting Java and integrating it well with MacOS was key to attract new users to the Mac.
But Apple today is self-confident enough to declare mainstream technologies a legacy on their machines. It seems Adobe’s Flash (which is not shipped pre-installed on the new MacBook Air and is not available on any iOS device) now has a prominent friend.
Apple today announces that they won’t maintain a JRE for Mac any more:
As of the release of Java for Mac OS X 10.6 Update 3, the version of Java that is ported by Apple, and that ships with Mac OS X, is deprecated.
This means that the Apple-produced runtime will [..] may be removed from future versions of Mac OS X.
This does not mean that Java will go away from the Mac any time soon, but there will (very likely) be no Java Runtime from Apple any more. So now it is up to Oracle (or any other third party) to provide a Java Runtime for the Mac, because it seems Java 7 (if that ever becomes real) apps will not run on Macs any more. But it also means that betting on languages that run on the JVM for development on the Mac is not a good idea (I am especially thinking of Clojure and Scala here).
Some may think that’s no big deal, since Java is a server-technology and the overall market share of Macs is quite small.
But this also makes life harder for providers of software packages that are portable, like IBM (Lotus Notes, Symphony, DB2 tools etc), the Eclipse project, Oracle (admin tools) and many others. What will happen if they cannot install on Macs any more?
Will this hurt the Mac platform or the software vendors? Will the possible inability to run a Scala-App on Macs influence the developers’ decisions, or will it make the Mac an unattractive platform for users due to missing applications?
Is this just Apple moving away from the mainstream or is the mainstream becoming irrelevant for some corners of the IT industry?
Hat tip to macrumors
Lukas just announced the availability of a new draft chapter on jQuery for the Seaside Book. It gives a good overview as well as a catalog of available functions together with a few how-to tips. A good read and reference.
Since the book is an interactive book, everybody is invited to comment or suggest corrections and extensions to the book:
Please have a look and help us to improve it by leaving comments. We
welcome any kind of feedback or text contribution. We are also happy
to give out passwords if somebody wants to collaborate on the text (we
already did so in the past but without success).
By the way, did you know that the book is basically a Seaside/Pier application?
Over at The Apple Blog, Jon Buys brings up a question that I’ve asked myself quite a few times before: why is there no docking station for Apple’s laptops?
It really is a shame, as beautiful as the new 27 inch LED Cinema Display combination with a brand new MacBook or MacBook Pro may be, that you still have to connect at least 3 cables to your laptop before you can go. And still you need a solution for where to put your MacBook, either for use in clamshell mode or as a second screen.
I am a big fan of the wired keyboard and wired Apple Mouse (which was once called the Mighty Mouse) and have a docking station for a backup drive and the digicam, so I love the idea of having all that stuff connected immediately when the MacBook comes home. Having the charger in the display is also a good idea, but you could also have it in a Docking Station which doesn’t require me to plug in any cable at all. I just put my laptop onto or into it and am ready to go.
A Docking Station from Apple could also make machines like the MacBook Air more appealing to people who want more than one USB port and stuff. You could have a small machine like the Air on the road and a battery of connections at home. Not really a new idea, but one that would fit perfectly into the Applesphere.
The new Cinema Display also has a real flaw: it only has one input and only plays with Macs, because it’s Mini Display Port. I’m not sure what kind of adventorous battery of adapters you’d need to connect another PC. So buying an LED Cinema Display means giving up a lot of alternatives.
Come on, Apple, Docking stations are not really a fresh idea, I’ve had one with my work laptop back in the mid-nineties, and they weren’t actually a brand new idea back then.
Many Web projects start off with a few hands full of users and will probably never reach loads that really put a Smalltalk image under real pressure. However, when it comes to selcting a web framework or platform, one of the first questions people ask is “will it scale to a million users per (choose whatever time unit you want, the whole question is useless in most projects anyway)?”.
While Smalltalk and Seaside perform quite well on a typical PC or a relatively small virtual server, running only one image is not enough for projects that really are successfull.
With Seaside, the solution to scalabality is running several images behind a load balancer (either hardware or Apache with some modules for that). All that’s needed is sticky sessions and some configuration on the balancer to make a Seaside application ready fro prime time.
There are several proposed solutions available, including running Seaside images in the cloud, and just yesterday, Philippe Marschall announced a new one on the Seaside mailing list:
Have you ever wished Apache and Seaside would know each other better?
That Apache could tell Seaside where it was and vice versa? That
Seaside could tell Apache the load of the image so intelligent load
balancing decisions can be made? That you can dynamically add and
remove Seaside images from a cluster without restarting Apache or
messing with configuration files? The guys at JBoss though the same
and wrote mod_cluster
The smalltalk part of this is currently only available for Pharo, but porting it over to other dialects shouldn’t be too hard.
So for those who fear that Smalltalk and Seaside might not scale as high as they hope to need, there are several solutions available, all of which have the charme of not adding any additional complexity to their application’s architecture.