You are currently browsing the category archive for the ‘Smalltalk’ category.

Joel Turnbull will be giving a talk entitled Gemstone and Maglev at the Agile Round Table in Cincinnati on March 2nd, 2010:

What is Gemstone? How do I get started with Gemstone? Why would I get started with Gemstone?

All of these questions will be answered!

We’ll do object persistence in Gemstone. We’ll persist objects from a web application. We’ll talk about Maglev and GLASS…

If you’re in the Cincinnati area and are interested in hearing about a production GLASS (GemStone/S, Linux, Apache, Smalltalk, Seaside) installation, then the Agile Round Table is the place to be!

Photo by http://www.flickr.com/photos/davidclow/ / CC BY-NC-ND 2.0

So you’ve read Kent Beck’s Smalltalk: Welcome to the Balkans:

The Smalltalk vendors seem to me to be in the same boat. Everyone has taken their “ANSI standard” Smalltalk in different incompatible directions

I don’t think the real issue is standardization.

It’s true that each dialect of Smalltalk has quirks, but version differences are not unique to Smalltalk. It can be challenging to move Ruby programs between different versions of Ruby and it can be challenging to move C code between different operating systems and compilers.

Seaside is proof that a significant body of code can be written to be portable across at least 7 different Smalltalk dialects. It takes a hefty glob of Grease (a Smalltalk portability layer), but it can be done.

Aida and Swazoo are additional examples of significant applications that have been ported to multiple dialects of Smalltalk. They are built on top of Sport (another Smalltalk portability layer).

Writing portable Smalltalk is a solvable problem.

Kent’s proposed solution is a good idea in and of itself:

Have the tiniest possible core defined in terms of test cases. Build a shared library on top of that, implemented in terms of the core. Include numbers, collections, meta-objects, code structure, and code loading. None of this parcel/bundle/package/pundle/category nonsense. Compete on VMs, graphics libraries, and enterprise-y tools.

But expecting a set of vendors to agree on the the “tiniest possible core”, when they can’t agree on a set of common methods is unrealistic.

Here’s what sent Kent off on his diatribe:

All the tests pass in Squeak finally. I’ve been making the changes in place…I load my code back into Monticello … I go to load into VW. Kaboom. The meta information is snarled. The monkey patches are gone. Merging does nothing sensible.

and it’s sent me off on my own diatribe:)

I’ve been working in Smalltalk for 25 years and this problem is just as bad now as it was 25 years ago! It is virtually impossible to do cross-dialect development in Smalltalk. It was unfortunate for Kent that Monticello was partially ported, because it gave him the illusion that cross-dialect development was possible:

And that’s where I sit, blogging because I’m too mad to think…if you can’t even move code between versions. Who would rationally invest in Smalltalk code if they weren’t already locked in?

Right on, Kent! Existing customers may not demand cross-dialect development, but prospective Smalltalkers are being turned away and turning your back on cross-dialect development is turning your back on the Smalltalk community.

You know the story of the Smalltalk balloon:

The cover of that issue depicted the “land of Smalltalk” as a remote island, and that triggered a connection for me out of which was born the fanstasy of liberating Smalltalk from the ivory tower by balloon ascent.

Smalltalk isn’t just balkanized, Smalltalk is an archipelago where every dialect is stranded on its own island! It would be a luxury to have a hot air balloon to transport code modifications back and forth between dialects!

It is technically feasible to port Monticello to every dialect of Smalltalk.

It is an idea whose time has come and gone about 50 times! You can claim that a file-based Smalltalk wouldn’t have this problem, but Monticello is file-based development for Smalltalk.

Monticello makes cross-dialect development possible.

The Monticello code base has not had the attention to portability that Seaside and Aida have, but seriously, Monticello isn’t under active development. A one off port is perfectly adequate. I did a one off port of Monticello to GemStone in December of 2006. It’s not incredibly difficult and it has not required a lot of maintenance.

Monticello has withstood the test of time in the Squeak community and it does a pretty good job:

I load my code back into Monticello (I love SqueakSource, BTW–easy to use, free, what GitHub would have been if they’d stopped developing after a month….)

Envy and Store are not viable candidates. Monticello is a light-weight solution compared to Store and Envy.

If you can afford to port Seaside, then you can afford to port Monticello.

So why don’t we just do it?

It isn’t realistic to expect all Smalltalk dialects to live on the same island, but to continue to perpetuate the current isolationism between dialects is just pathetic:

I’m calling bullshit on the state of Smalltalk. Vendors, you’re acting crazy.

Thank you, Kent for the kick in the butt!

And Happy Valentines Day!

Lukas Renggli announced the availability of a PDF version of Dynamic Web Development with Seaside:

At the end of the payment process (PayPal) you will be redirected to the download area where you are able to get the latest builds of the PDF version of the book. If you bookmark the page you will be able to download fixes and extra chapters as we integrate them into the online version. By buying the PDF version you support our hard work on the book.

Photo by http://www.flickr.com/photos/dpc47/ / CC BY-NC-SA 2.0

James Foster describes a very clever technique for getting a report on the contents of your GemStone data base. Originally written for GemStone/S 6.x, he has recently updated the code to support the 64-bit product.

You can load the code from the ScanBackup GemSource project.

Photo by MorBCN (Creative Commons).

[1]

That’s a huge platter of fruit de mer sitting in front of me (at the end of the table) and no it wasn’t all mine – there were 5 of us sharing that mound of seafood. The photo nearly says it all about ESUG 2009: a group of Smalltalkers eating seafood and talking shop.

Overall an excellent conference. Good presentations, good food, and good conversations. Congratulations to ESUG and the conference organizers for a job well done.

Follow these links for slides, pictures and videos. Here are some of my highlights

Glamour

Where did all the code go?

If you’ve ever tried to write a browser in Smalltalk you are aware of the amount of code that you must write. OmniBrowser cuts down on the amount of code involved, but you must still wrap your mind around the OB meta model, which is not always easy.

Enter Glamour. The following code produces an Object Explorer (multi-paned object explorer):

| browser |
browser := GLMFinder new.
browser list
	title: 'Collection';
	when: [:each | each isCollection].
browser list
	title: 'Object';
	display:  [ :anObject | 
        anObject class allInstVarNames collect: [:iv | 
            iv -> (anObject instVarNamed: iv) ] ];
	format: [:assoc |
        assoc key asString, ' : ', assoc value printString];
	send: #value.
browser text
	display: [:entity | 'self' ];
	title: 'Evaluator';
	update: #selection 
    on: $o 
    entitled: 'Open (o)' 
    with: [ :text :entity |
	    Compiler 
         evaluate: text selectedText 
         for: entity 
         logged: false ].
^ browser

Philipp Bunge and Tudor Girba have been able to distill window building down to the bare minimum. Very neat work. Oh, did I mention that besides a Morphic mapping, there is a Seaside3.0 mapping too?

Metacello

While I feel comfortable with the core engine of Metacello, I arrived in Brest, keen to get feedback on the spec creation API. Fortunately, I was able to spend the better part of 4 days working closely with Tudor Girba to refine the functionality and spec creation API. Following Doru’s suggestions, I have made some fairly significant changes to improve the overall usability of Metacello. Doru and I will continue working together on refining the things for the beta release of Metacello.

In addition to Doru’s feedback, I was able to talk to a number of different people about Metacello and the problems it is trying to address. All in all very positive feedback.

Seaside 3.0

Julian, Lukas and Philippe announced Seaside 3.0 at the conference and the Seaside Sprint brought Seaside3.0 tantalizingly close to beta.

GemStone will be releasing version 2.4 very soon now. Shortly after the 2.4 release is officially announced, we will make the Seasde3.0 beta available on GLASS.

The online book Dynamic Web Development with Seaside (sponsored by ESUG) was also announced at the conference.

CouchDB for GemStone/S

In the days leading up to ESUG Randall Schwarz visited our offices and piqued my interest in NOSQL databases:

Have you run into limitations with traditional relational databases? Don’t mind trading a query language for scalability?

Sounds like an ad for GemStone/S doesn’t it?

I chatted up the idea that it would a be a no-brainer for GemStone to provide a NOSQL database mapping for GLASS with a number of folks at the conference.

Philippe Marschall thought it was more than a good idea. In a matter of days (or was it hours) he had implemented a CouchDB mapping for GLASS using Seaside3.0. The code is up on GemSource in the CouchDB project.

Summary

There were lots of other conversations and many more interesting projects to discuss like Pharo and a port of Moose to GemStone. Needless to say, I came away from the conference with a todo list as long as your arm (to add to my already long todo list:).

The next few months should be a very interesting time as the seeds sown at this year’s ESUG come to fruition!

—–
[1]Photo by Damien Pollet (Creative Commons).

[1]

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

With the latest dev release of Pharo (pharo0.1-10243dev09.02.3), the new GemTools Client has stopped working correctly. From what I can see, a number of updates were made to OmniBrowser which causes the buttons to disappear from the OGLauncher….I stopped looking for additional problems at that point:). I’m not going to complain, though, the Pharo image is pretty cool already and it is still pre-Beta.

As of pharo0.1-10213dev09.01.3 (and probably pharo0.1-10236dev09.02.2.zip) the GemTools Client was working correctly. Until further notice don’t use the latest versions of Pharo.

I have been pretty busy fixing bugs recently and anticipate a refresh of the GemTools Client and the GLASS package in a week or so.

—–
[1] Photo by milomingo via Flickr (Creative Commons).

[1]

Sebastion Dietz wrote:

We are using Smalltalk (a rather old implemetation) for a logistics and foreign trade application with a bit over 500,000 lines of code (comments and empty lines excluded ;-) ).

Having worked with Smalltalk for 10 years now, I would not recommend it for larger business applications.

Janko Mivsek wrote:

Smalltalk allows me to be agile, productive, my systems are maintainable regardless of all changes of business climate in recent years.

Samuel A. Falvo II wrote:

Unfortunately, Smalltalk is an effectively dead langauge to the majority of software shops out there (a real pity, too), relegated to the same dustbin which holds both Lisp and Forth.

Smalltalk is a language that makes true OO programming so cheap that you’re more often than not benefitting from a pure-OO (possibly with patterns) approach to coding for pretty much everything.

In short, it’ll take you, the programmer, substantially longer to implement a properly OO solution to any problem in Java than it would in Smalltalk.

Mark Driver wrote:

So I’m not suggesting that we are going to see a massive renaissance in Smalltalk use in the near future. Today I still have a hard time recommending most mainstream IT organizations invest heavily in new strategic initiatives with Smalltalk.

If you are BIG fan of dynamics languages (closures, meta programming, and all that cool stuff) then consider giving Smalltalk a look. You might like what you see. Its like Ruby but with bigger muscles. You think Rails is cool? Check out seaside.

Chad Fowler said:

In my opinion, Seaside is the coolest thing going in web development

Edward Povazan wrote:

Recently I’ve had the good fortune to be exposed to Blain Buxton, a long time Smalltalker.

Stange talk of ‘messages’ and ‘images’ and crazy talk of changing objects on the fly without restarting anything. In fact, not even having the concept of an application to restart.

After some digging and reading, and after a nice demonstration using Squeak, I am starting to understand things and want to be in this lively Smalltalk world.

Ramon Leon wrote:

I use Ruby, I like Ruby, but Smalltalk is more productive when I’m working in unknown territory.

Smalltalk doesn’t have to be pragmatic, because it’s better than its imitators and the things that make it different are also the things that give it an advantage.

So, if you still haven’t tried Smalltalk, and I mean really tried it, by writing an application in it, give it a go. You’ll never regret it, because everything you learn, and you’ll learn a lot, you’ll be able to bring back with you to whatever language you call home.

Interesting, the corporate world may not be in love with Smalltalk, but for many developers Smalltalk becomes the language of choice (once they get to know it).

The fact is that there are a number of companies with significant and ongoing investments in Smalltalk. There may not be a ton of companies out there leveraging Smalltalk, but they are out there and not all of them are interested in letting the competition in on their secret.

But this post isn’t aimed at IT shops and corporations.

Smalltalk was designed to allow people (not just programmers) to express their creativity in the computing medium.

You don’t program in Smalltalk. You work in Smalltalk. You immerse yourself in Smalltalk.

Everything is an object and everything can be modified from within the development environment, including the tools and the web server. If you need to change the behavior of the web server (i.e., fix a bug), you can – the source code is in the image, easily accessible and the changes can be made without breaking stride.

The image provides built-in persistence for your application objects – no need to configure and manage separate programs to persist your data.

With the built-in inspector you can poke around your object graph. With the built-in debugger you can fix your code and explore the relevant objects. No context switch needed when you hit a problem whether it be a problem in the data base, a problem in your web server, or a problem with your application – the debugger pops up and you just continue with your development. It is a joy to accomplish things in Smalltalk.

For individuals and small groups of programmers (like MicroISVs) for whom productivity is important it can make a lot of sense to choose Smalltalk as the development/deployment platform. For a web application, the entire deployment stack can be built into a single executable program (the image): DB, configuration console and web server, all running within a single program – all written in the same language and all developed with the same tools. Here are several examples of Smalltalk-based deployment stacks in action (each download includes a Mac application, a Linux shell script and a Windows .exe file):

Don’t you think it’s time that you gave Smalltalk a whirl?

——
[1] Photo by thebacon via Flickr (Creative Commons).

[1]

Norm Green made the following announcement on the GemStone/S customer forum – the invitation for attending the CAB meeting is extended to users of the free Web Edition:

Hello GemStone Customers,

Back in the 1990s, GemStone hosted an annual meeting of customers here
in Beaverton to talk about “all things GemStone”. This was a chance
to meet other customers, give feedback to us on things you like and
don’t like about the product, and talk directly with the Engineering
team. Since Smalltalk Solutions is not happening this year, we are
thinking of holding Customer Advisory Board meetings in May or June.
These would last for 2 or 3 days (something like Tuesday through
Thursday) and would occur here at GemStone headquarters or at a nearby
venue. We have several ideas regarding the format including tutorials
on GLASS and Seaside. We could do something like host a CampSmalltalk
around the same time as the CAB. The only cost to attend would be
travel and living expenses.

In order to move forward, we’d like to get an idea how many people
would be wiling to attend. If you think you could come, please send
me an email. While we’re not asking for a commitment to attend, we’d
like to know that there’s a pretty decent chance you’d be able to
come. Both 32 bit and 64 bit customers are invited and customers are
free to send more than 1 representative.

Looking forward to hearing from you!!

Best regards,

Norman R. Green
GM – Engineering
GemStone Systems Inc.

If you are interested in attending send send mail here or to Norm directly.

———-
[1] Photo by Thomas Hawk via Flickr (Creative Commons).

[1]

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

As a few brave souls discovered, the process for updating to the new crop of tools is a little more complicated than it needs to be. A couple of them even got their fingers pinched during the update:).I was looking for feedback, so I appreciate the effort. Hopefully their sacrifices will be worthwhile.

updatelauncher

There weren’t that many changes made to the OmniBrowser code in GLASS post GLASS.230-dkh.177, however, the changes that were made created havoc for any windows opened prior to the update. I had originally hoped that a couple of errors between friends would be okay, but enough people ran into odd problems during the updates to GLASS.230-dkh.182 and GLASS.230-dkh.183, that it became clear that the update process needed to be improved.

I tried a number of things including an attempt to work around the problems with the new GemTools Client code. I was successful in getting the new GemTools Client to run against the older versions of GLASS (which is a step in the right direction), but I wasn’t able to get around the crashes and walkbacks. With a nudge from Igor Stasenko, I finally settled on using an update script.

In the end I made two significant changes to the update process:

  1. Update the GemTools client before updating the server. In the past we’ve updated the server-side code first and then updated the client-side code. However, since we’re recommending that users move to a completely different client image, I think it is easier to get the client update out of the way before doing the server update, especialy now that the latest GemTools Client code will run against older versions of GLASS. Any problems in getting the GemTools Client built and connected to the server can be worked out before making changes on the server side.
  2. Update the Server using a script instead of the Monticello Browser. With this particular update, using a script is necessary since the windowing mechanism for the current session becomes broken during the update. In the long run, it is useful to have a script-based update mechanism that can be used to update production repositories that aren’t easily accessed through the GemTools Client.

Preview GLASS.230-dkh.187

Since GLASS.230-dkh.183 I’ve made a handful of improvements that are worth trying out:

  • merge Pier-Model-lr.245, load Pier-Blog-lr.103.
  • OSTestRunner bugfixes.
  • debugIt implemented. debugIt opens a Debugger on the selected code, setting a breakpoint on the first statement.
  • exploreIt implemented. exploreIt opens a Chasing Inspector on the result of evaluating the selected code.
  • Remove MonticelloConfigurations as a required package.

If you’ve been following the mailing list, you will have noted that we’ve received a flurry of bug reports in the last week or so. I appreciate the bug reports, but because I intend to address a good number of them before the next beta update, the next update will be deferred for at least 2 more weeks.

1. Update GemTools Client: GemStone-dkh.355

If you choose to use Pharo as the basis of your GemTools Client, be sure to download the latest dev image as a starting point. As of today, pharo0.1-10211dev09.01.2.zip is the latest dev image. If you choose to use Squeak as your GemTools Client, start with a basic 3.10 image like Squeak3.10-7159-basic.zip.

sessiondef1Use the Universe Browser, select the GemTools-Client version 0.355 package (in Network category) and install it. Note that during the install using 3.10, you will be warned about an extension to OTToolset – is is safe to proceed.

Open a Workspace and evaluate the expression ‘OGLauncher open‘ and then edit the Glass session, inserting the login information that is relevant to your system – stoneHost, gemHost, stoneName and netLDI.

Login using the GemToolsLauncher and get ready to update the GLASS repository to GLASS.230-dkh.187. Note that during the login using Pharo, you will get a warning about using a deprecated #authorInitials: api – it is safe to proceed.

Even though the Class Browser and Monticello Browser are functional, I wouldn’t try to do too much work using the new GemTools Client and an old version of GLASS. For best results you should immediately update your GLASS repository.

I’ve used the new GemTools Client to upgrade GLASS.230-dkh.164 (corresponding to 2.3 release and the 1.0beta11 appliance) and GLASS.230-dkh.177 (corresonding to the 2.3.1 release) with good results.

Since I’m still actively working on the new tools, I don’t plan to publish a ‘one-click’ GemTools Client, until the rate of change has settled down.

2. Update GemStone Repository: GLASS.230-dkh.187

The following update script:

  1. Adds a method to SystemChangeAnnouncement.
  2. Turns off autoMigrate.
  3. Loads GLASS.230-dkh.187 from the GemSource repository.
  4. Sets autoMigrate back on.
  5. Performs a commit.

The code should be pasted into the workspace pane of a Gemstone-dkh.355 GemTools Launcher or run from a topaz session.

| httpRepository version rg |
SystemChangeAnnouncement 
    compileMethod: 'item: ignored' 
    category: 'accessing'.
MCPlatformSupport autoMigrate: false.
httpRepository := MCHttpRepository
    location: 'http://seaside.gemstone.com/ss/GLASS'
    user: ''
    password: ''.
"pick up the GLASS repository if it's already
 in default repository group"
MCRepositoryGroup default repositoriesDo: [:rep |
    rep = httpRepository ifTrue: [ httpRepository := rep ]].
version := httpRepository
    loadVersionFromFileNamed: 'GLASS.230-dkh.187.mcz'.
version load.
rg := version workingCopy repositoryGroup.
rg addRepository: httpRepository.
MCPlatformSupport autoMigrate: true.
System commitTransaction.

If you’ve used the GemTools Launcher to run the update script you should logout and then log back in before continuing with your work. If you use topaz to update the repository, you need to remember to use a GemStone-dkh.355 GemTools Client to connect to your repository.

The GemTools Client is still in preview, so unless you are brave and/or curious, I’d recommend that you stick with a more stable version of GLASS.

———-

[1] Photo by EricGjerde via Flickr (Creative Commons).

[Update 3/16/2009: see the post GLASS Beta Update: Cooking with GLASS (Preview) for the latest preview information].

Over the Christmas holidays my grandson Oscar and I got serious about tools.

Oscar learned how to use a drill and I built an OmniBrowser-based version of TestRunner to go along with the new GemTools Launcher.

GemTools Launcher updates

Gerhard Obermann has been busy working on the tools, too. He’s made a number of improvements to the Launcher:

  • Empty and Show Object log menu items added to the Doit button.
  • Added a Transaction button as a home for Commit and Abort.
  • Tweaked appearance in a number of places.

To pick up Gerhard’s changes use the Package Universe browser to load GemTools-Client version 0.335. If you haven’t already loaded the tools preview, follow these instructions.

OSTestRunner

OSTestRunner is a clone of the Squeak TestRunner with the functionality molded to fit within OmniBrowser. OSTestRunner can be run in Squeak, Pharo or GLASS. Click on the image below for a full-sized view of the Pharo version.

newtestrunner

To use with Squeak or Pharo, check out the instructions in the announcement message.

To load into GLASS:

  1. Follow the instructions for bringing up the tools preview (make sure you load GemTools-Client version 0.335 on the Squeak side).
  2. Log into GemStone (using the new launcher) and load GLASS.230-dkh.183 from the GLASS project on GemSource, using the GLASS Monticello browser.
  3. Logout and log back in to make sure that the client is updated with the new server classes and enjoy.

I’m still tweaking OSTestRunner for GLASS roundtrip performance and I want to have better user feedback while the tests are running, but other than that I’m happy with the new OSTestRunner – hey all of the menus and buttons work on the new version!

Monday, I’ll dive back into MC2 and will beat on the new tools (tweaking here and there), so you can look forward to a general release of the GemTools towards the end of the month.

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 446 other followers

Categories

RSS GLASS updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Metacello Updates

  • An error has occurred; the feed is probably down. Try again later.

RSS Twitterings

  • An error has occurred; the feed is probably down. Try again later.
July 2019
M T W T F S S
« May    
1234567
891011121314
15161718192021
22232425262728
293031