Smalltalk Tidbits, Industry Rants

So yesterday I posted some on the tense 24 episode and the latest Buffy offering. This yielded this message from an Australian associate:

And on a different but vitally important note - please be very very careful not to give away any plot for 24, Buffy and Angel on your blog. They have only just started running the new series of each in Australia this week so we are somewhat behind.

Heh. I'll do my best.

If you use VisualWorks, run - don't walk - to the public store and load the RBCodeHighlighting package. It is configurable via the system settings, and does the coloring/highlighting as you type. Highly recommended. Kudos to John Brant, Anthony Boris, and Holger for collaborating on this!

This is just funny. Linux Today quotes Sun's CEO:

"Industry analysts and others who suggest otherwise are plain wrong", Sun CEO Scott McNealy said at a news conference in San Francisco yesterday at which the company unveiled a flurry of new products and services. "They just don't get it. That's all right, they haven't for 21 years," McNealy said. "Right now, HP and IBM are reading the analyst reports and saying Linux is going to happen and they're abandoning their Unix customers..."

Hmm. I guess McNealy didn't notice this. And speaking of not getting it, there's the entire Java language - a prime example of utterly ignoring the prior art in Smalltalk and Lisp, and shoving out a half baked implementation. Not to mention that in doing so, they handed large checks to IBM and commoditized their entire product line. There's someone that doesn't get it, alright. McNealy needs a mirror.

Gordon Weakliem has an excellent post on software development up today. He links to Jon Udell, who makes the assertion that "the film industry's project-oriented, just-in-time assembly of resources and talent":

This is really interesting because I was talking to a friend who is both a software engineer and an amateur filmmaker, and he was drawing paralells to software and filmmaking; for example, a filmmaker shoots a lot of film, but doesn't really know how things are going to turn out until the editing process. Which is a lot like software, where it's even more difficult to see where you're going until you get to integration. What's funny is that last night, we were talking to a mutual friend who's a project manager for a construction company. He described his job as "protecting his boss' money", in that the builders will come up with a proposal for how to complete part of a project, and he's the guy who tells them to come up with a cheaper solution. My filmmaker friend exclaimed, "you're the producer!", as in a film producer, who's supposed to rein in the director and the people involved in actually making the film. So I had the realization that the construction industry works this way as well: a builder or developer generally doesn't build anything, they hire people to build it for them. So somebody gets the job of contracting and scheduling the work of concrete workers, drywallers, plumbers, electricians, painters, etc.

That's a great analogy, IMHO. Gordon makes a number of other good points as well, relating all of this to the industry's "standardization" trends - J2EE yesterday, .NET today, gosh knows what tomorrow. Go read his whole post - I'm not going to be able improve on what he has to say.

I finally discovered how some people thought they were getting registered, but had not, in fact gotten registered. The Registration process is a two step thing - first you register, and get sent an email. Then you login, and get sent to the download page. The problem was on that login page - some people apparently hit the "I forgot my Password" button by mistake, and the application was not dealing with that properly - it was simply sending an email, without ever checkking to see whether the user in question was activated or not. That's now handled - such inadvertant mistakes will now be far more gracefully handled. I apologize for the confusion...

I had a problem the other day packaging a BottomFeeder build with ResHacker. It had been working fine under Windows ME, but did not seem to work after I upgraded to XP Pro. I got things going by grabbing a newer release of ResHacker. Now I get word from Anthony Lander that the version on the CST CD works fine in XP if you first delete the executable file that will be created when you use it. So either download the newer version - I found it here, or delete any old executables before you use the old version.

My favorite TV night, Tuesday. Both Buffy and 24 are on, and both were very good again. 24 especially - it had me on the edge of my seat the entire time. The story line connecting the elements working against the President (Palmer) and the terrorists (Ali) look to be converging. They've done a great job of relentlessness so far. I'd be looking forward to Angel tomorrow, but my local WB station insists on showing ACC basketball. As if I care about that....

I saw this announcement - the 1.0 version of NetNewsWire is getting released at a price of $29.95. The interface looks nearly identical to the BottomFeeder one. They support blogging tools in the for-sale version, and I haven't gotten around to doing the Blogger API yet - although that is coming. They run on Mac OS/X, and we run on loads of platforms - not to mention that BottomFeeder is free and open source. As well, I bet they have more than two people working in their spare time ;-)

We had over 2000 downloads of Cincom Smalltalk non-commercial last month, and we have almost 500 so far this month. Interest in Smalltalk seems to be increasing!

We have made the Cincom Smalltalk Wiki with an apache rewrite rule - instead of http://www.cincomsmalltalk.com:8080/CincomSmalltalkWiki, you can now use http://www.cincomsmalltalk.com/CincomSmalltalkWiki. This should make it more accessible to users who can only browse via port 80. There may be some lingering issues - any pages with a "/" in the title will not be visible this way. As they get found/reported to me, I'll fix them.

Here's an interesting paper on SWT usage:

When programming in a GUI operating system, you allocate operating system resources for widgets, images, fonts, and other graphical objects. Since there is a platform limit on the amount of resources you can allocate, you must be careful to free any objects that you allocate in your application. If you allocate a resource and do not free it when you are done with it, your application is "leaking" resources. An application that repeatedly leaks resources will eventually consume all of the available resources, forcing the user to reboot the operating system. Fortunately, SWT makes resource allocation and disposal a straightforward process. There are only two rules that you need to remember when allocating and freeing SWT resource-based objects: Rule 1: If you created it, you dispose it. Rule 2: Disposing the parent disposes the children

Ok, that seems like a huge step backwards to me. It gets more interesting:

This is a simple rule. SWT makes it easy for you to remember when operating system resources are allocated; all SWT resource-based objects (like Color, Cursor, Display, Font, GC, Image, Printer, Region, Widget and subclasses) allocate any needed operating system resources in their constructor. There are no exceptions to this rule. There are no methods in SWT (other than constructors) that allocate operating system resources that the programmer must manage. If you didn't call the constructor, then you don't need to free the resources, so don't call dispose on the object. For example, in the following line of code, an operating system font is allocated:

    Font font = new Font (display, "Courier", 10, SWT.NORMAL); 

Since you called the Font constructor to create the resource, you must dispose the font when you are finished with it, as follows:

    font.dispose();

In the following line of code, however, a constructor is not called:

    Font font = control.getFont ();

Therefore, you must not call dispose. The font variable does contain an operating system font resource, but you did not allocate it. If you were to dispose of this font, you would be leaving the control without a font! The results are undefined. So, if you are using any getter that returns an SWT resource-based object that you did not allocate, do not dispose the object.

I suppose developers would internalize (most) of that - but that introduces some nice opportunities for memory leaks and - whatever happens if you call dispose() inappropriately. This is progress? Interestingly enough, this isn't just me as a Smalltalker being smug. I found this here, on a Java developer's blog. Some of his comments:

cbeust on SWT and memory management:

However, I have to agree with Danno about resource handling: the fact that SWT forces you to free manually the resources you allocate is a huge step backward that is going to become a big liability for this toolkit in the near future.

Back to future gang! Looks like the memory leak business will be alive and well in Java land....

I've said more than once that static - or manifest - typing just gets in the way, and causes more problems than it solves. A lot of people are starting to catch this drift with the rise of Agile methods and test-first. The MS folks obviously don't - here's an interesting example:

What I really want for this class is to serialize it both directions - I want the object to be serialized up to the server so the server can play with it, but when AddItemToBag returns I want the modified bag to come back down to the client. I was all geared up to start exploring custom marshaling when I tried one simple thing - I changed AddItemToBag to take a ref IIntBag instead of just a plain IIntBag:

 public void AddItemToBag(ref IIntBag bag)
 {
  Console.WriteLine("bag[[\"1"] = 1;");
  bag[["3"] = bag[["1"] + bag[["2"];
 }

This turned out to be exactly the combination I wanted - the hashtable is serialized in both directions! Reasonably obvious I suppose but I wasn't convinced it was going to work this way. I figured "ref Int" wouldn't send results back down unless I literally allocated a new hashtable and assigned it to bag. This is too cool. Interestingly the C# compiler demonstrates a little quirk (maybe it demonstrates my own quirkiness) when I try to call the function. If I say this:

IntBagImpl i =  new IntBagImpl();
Server.Add(ref i);

the compiler complains: error CS1503: Argument '1': cannot convert from 'ref IntBagImpl' to 'ref IIntBag' Well, duh. Just for fun I tried this: IntBagImpl i = new IntBagImpl(); Server.Add(ref (i as IIntBag)); Sick stuff to be sure, but hey - it might work :) Alas, the compiler slaps me down with this: error CS1510: A ref or out argument must be an lvalue Changing the type of i to IIntBag of course fixed it, but apparently the compiler doesn't like taking a ref on a temporary object :). Interesting. I wonder what the Mono compiler does here...

that's an example of knowing how to solve a problem but having the type system stand athwart your code shouting stop! Now imagine if he was using Smalltalk - all that time spent fighting the type system would have instead been spent doing something of value

This report, which I discovered here is an eye opener. Kind of takes me back to my days (1960's) in elementary school, with the "duck and cover" drills. Definitely a more coffee kind of read....

A few days ago, I posted this, in response to this post. It was actually a general frustration on my part, and not a rock hurled at the poster. It has now received this response, and I do have some issues with that:

The weakness of both Lisp and Smalltalk (and many other cool researchy languages), is that neither have ever been that good at talking to the machine, which makes them pretty much useless for real work. Today, we have lots of "managed" languages that can talk to system pretty well. Java can do that, and the various languages atop the .NET CLR can do that. And from an industrial perspective that's important. I'm oversimplifying a bit here, but that's been the reality / perception at various points in history over the last 20 years. From where I sit, it looks like the best we can hope to do is to get an advanced language which can use the CLR's ability to talk to the machine. And the CLR that it talks to ought to be the ECMA / Mono one, not the Microsoft one. That would get you a decent language, portability across hardware / os at a binary level, and the ability to talk to the hardware in a rich fashion.

huh? Useless for real work? Where in the heck does that come from? Most applications, in simplified form, look like this:

1. Grab Data from Database
2. Present Data for user to view/modify/create
3. Push any modified data back into the database

Boil it down, and that's what most apps are. Not number crunching, not games in need of the fastest hardware/software (although, Lisp and Smalltalk have been and are being used in games). To me, this sounds an awful lot like the general industry problem of premature optimization - developers the world over are obsessed with making things faster - never stopping to ask if it's the real problem. In most cases, it's not. And managed code is a good thing - having access to pointers is a necessary evil for some levels of work, but for the vast majority of applications, they are a useless distraction - in reality, little more than an error generator. I've done just fine without pointers for a decade, and will do just fine for another decade without them. I wasn't the only one to have this thought; Chris Double weighs in as well:

Maybe I'm misunderstanding Ted but I don't agree with this statement. Perhaps it was true in the past but modern Lisps and Smalltalks seem to have no problems talking to the machine. Dolphin Smalltalk applications look and feel exactly like normal Windows applications. And that's because they are. It's also very easy to call API functions. Corman Lisp, a Common Lisp system for Win32, also has very good methods of talking to the machine. You can practically paste in a C header file definition for the API and Corman Lisp will generate the necessary Lisp code. You can create DLL's in lisp that are callable by C programs. You can even code in-line assembler if you really want to get down and dirty.

Now, VisualWorks doesn't (yet) have the capabilities that the Chris mentions above. But it does pretty well, and the VW VM will be available as a DLL for 7.1 - which means that you'll be able to deploy VisualWorks apps as DLL's at that point. This blog is Smalltalk powered, and the BottomFeeder application I spotted these posts with is a client application that integrates pretty nicely with Windows via the registry. I don't get it....

I decided to put together a new dev build - Holger has been making some enhancements to Twoflower - he's enabled text copy from within Twoflower (which means you can copy text from the HTML View now!). This makes it far more useful, and it's a feature that ought to be out for testing. The dev build is uploading now. The panic? Well, I had completed the image build, and turned to using ResHacker to package up a Windows exe. Imagine my panic when it just didn't work after having updated to XP! After some wailing and gnashing of teeth, I used Google to track down a newer release of ResHacker. I finally located one here. After downloading it, i was able to finish the build. If you want to see what Holger's been up to, give it a whirl!

We have posted a new survey for your perusal. Previous survey results may be found here. We appreciate all feedback!

So I upgraded to XP Pro today. It went fairly well. I decided to share a printer on the home network, and to go back to using the Linux printer as the default. Thus began my descent into XP weirdness

1. Ran the wizard for configuring a small/home office
2. That completed, and succeeded in disabling my network. After it was done, my network card had a nice big red X over it on the control panel, and there was some new 'bridge' icon there
3. Deleted the 'bridge' thingie, whatever it was
4. Rebooted
5. Now, for reasons I cannot begin to fathom, I can share my printer and see the other share devices available on the LAN. Huzzah

I suspect that this is not the scenario the MS marketing folks had in mind in their product plans. It's likely I did something "wrong" here, but - the way I got to a successful configuration was mystifying, to say the least...

Scott Ambler will be giving a keynote address at this year's Smalltalk Solutions Show. Here's the official announcement:

The Smalltalk Industry Council has been very busy planning this years Smalltalk Solutions Conference in beautiful Toronto. The conference will be held July 13-16 at the Crowne Plaza Toronto Centre hotel. The Conference will conveniently take place entirely within this hotel and conference attendees will receive a discount rate with the hotel. Please call early and mention Smalltalk Solutions 2003 when making your reservations for the discount rate. Hotel information and pricing can be found here: http://www.smalltalksolutions.com/hotel/hotel.htm STIC is now accepting registrations for the conference. Please go to the Smalltalk Solutions website http://www.smalltalksolutions.com/registration/reginfo.htm for further information. Remember, STIC members receive a $75.00 US Dollar discount for the conference so join STIC today by visiting the council web site at http://www.stic.org

I got an interesting bug report today for BottomFeeder. It turns out that this feed from Dive into Mark wouldn't parse. I took a look - and he has a version tag of PI!!!! Ok, that's odd. Maybe it's related to this post, as kind of a perverse test to see how many aggregators pass. The 2.7 released failed this test, but a quick patch - which should auto-load on startup - fixes that. I find this kind of thing anti-social. It's one thing to have a bad feed because of a tool problem (bug) or bad HTML (human error). But to have an actively bad feed? Seems a bit over the top to me...

And didn't actually go badly, once I gave up on the upgrade idea and went for a clean install. I's still re-installing software - including the Oracle client software (why is it 600 MB if it's just the client?). Even my VPN software works!

See this blog entry - Sam has some nice things to say about S#. Ironically, it's the next post after an item on COM interoperability issues

If you use BottomFeeder on a non-Windows platform, you may have noticed a problem - on loading a new plugin, a couple of exceptions get thrown, and the plugin did not actually load. I tested on Windows, and did not hit this problem - apparently, packaging the application as a single executable masked it. What happened was, the application has the compiler available so that patches and plugins can be loaded dynamically. However, when loading a plugin that adds new classes, the system tries to log the changes - to the (now non-existant) change file!. Since this is Smalltalk, I just released a patch - it simply prevents the logging of changes, and the plugin stuff works fine on Linux now.

So I'm trying to upgrade my PC to XP Pro from ME. Apparently, I had a few registry entries to Outlook - which I had long, long ago deleted. The installer was confused by this mismatch, and barfed. Then the PC reboots, and I accidentally okayed a boot from CD. That was ok, because the XP Pro installer had an error in the startup script. I'm feeling better about my BottomFeeder slip ups now....

A few days ago, I posted on burnout - I had received an interesting email from a development manager casting about for alternatives to C++ after a recent death march. Today, Reflective Surface weighs in with some commentary:

The obvious options to solve the problem in the programmers' side, which is trying to change the corporate culture, is an inglorious effort that will certainly result in more frustration and stress, and has few chances to succeed. With respect to the companies themselves, the corporate inertia that denies every possibility of finding effective solutions is proportional to the size of the company multiplied by its Dilbert coefficient. So, I fear to say that there's no simple solution. Ironically, the market itself is responsible to blinding companies to the losses that result from continuing in that suicidal path. Companies that go under when programmers finally get so fed up with mismanagement that they leave are pretty common. The case Robertson cites in which the company realized its mistakes and started searching for solutions is exceedingly rare. So, I believe programmers must find their own defense mechanisms to avoid getting burned out. After all, I'm just stating the obvious when I say that there's not point in wearing yourself out because others are failing to realize their errors.

I love that Dilbert coefficient reference. Sometimes, I wonder if the primary goal of many IT organizations is simply churn - everyone chants there's no silver bullet, and yet - as soon as a big technology vendor releases something new (Java, .NET) - everyone scurries off to see what it is.

This morning, I posted this, expressing my frustration that people don't seem to consider Smalltalk when they are casting about for alternatives. Gordon Weakliem makes some excellent points:

But I think that it's hard to underestimate Paul Graham's role as evangelist. His various articles touting Lisp make a compelling case for using interactive environments and against the C/C++/Java/C# lineage, and his "Plan for Spam" shows Lisp neatly solving real problems. Smalltalk's strongest advocate (in my opinion) is Kent Beck, who's been more interested in processes; while his XP and Unit Testing work mentions Smalltalk, he hasn't made Smalltalk the cornerstone, concentrating on demonstrating applicability in any environment.

I think Gordon's on to something here. It's ultimately all about marketing, and evangelists are part of that, whether they work for a vendor - or more usefully, if they don't.

These news items can't be good for Sun:

Pixar Animation Studios, which brought the world Monsters Inc. and Toy Story, is switching from Sun Microsystems to Intel, as the melodrama in the server market heats up. The Emeryville, Calif. based film studio is replacing servers from Sun in its render farm--a bank of servers that fuses artists' images into finished film frames--with eight new blade servers from Rackspace. In all, the blade system contains 1,024 Intel 2.8GHz Xeon processors, and it runs the open-source Linux operating system. Pixar installed the Rackspace system over the previous six months and will use it to develop its next film, The Incredibles, which will likely hit theaters in 2004. ... Last July, for instance, Industrial Light and Magic replaced RISC-based computers running Unix on artist workstations from SGI, choosing instead Dell desktops containing Intel chips and Linux software. ILM also installed a rendering farm running AMD's Athlon processors. Other Intel-Linux installations took place at DreamWorks and Sony Pictures' Imageworks.

Ouch. Meanwhile, this story I linked to got slashdotted - not my link, but the main story. Double Ouch. Excuse me while I enjoy some Schadenfreude....

I posted a patch for the new 2.7 release, and it works fine to address 2.7 issues. Unfortunately, it introduces problems in previous Bf releases. If you are running an older release, do one of two things:

1. Upgrade to 2.7
2. Edit the btfSettings.ini file (2.6) and change the patch file setting to look at file patchDefinitions.xml instead of patches.xml. That will allow the older version to start without errors.

This was due to bugs that shipped in 2.6, for which I apologize.

You just want to scream. This post is more evidence that developers are starting to see that Java and C# may not be the end all and be all of existence. If Lisp gets a thought, why not Smalltalk?

If you downloaded 2.7 earlier after my announcement, get it again in about 2 hours - I uploaded from the wrong directory. Sorry, my bad....

Visit the BottomFeeder Home Page and grab the latest release. There are a lot of bug fixes and improvements. OCS Feedlists are much better supported - Dave Murphy improved the OCS feedlist handling, and Rich Demers has provided a Users Guide for BottomFeeder and for Twoflower. The UI has been enhanced greatly with a toolbar - and there is plugin support as well. BottomFeeder now supports a simple API for adding additional applications at runtime - either ones already installed by the user, or ones available from the website - see the Plugins menu item for details.

I spotted this item over at Dewayne Mikkelson's blog. Fascinating stuff on the ability of nature to cope with the oddest things thrown at it:

Contrary to expectations, urban landscapes are some of the most interesting ecologies. The variety of landscapes and microclimates (roads, parks, gardens, rail, canals, industries), the intense flow of exotic materials for commerce and gardening, and continual disturbance, all contribute towards many opportunities for nature. Due to such variety, cities are often more biologically diverse than the surrounding countryside. Nature is astoundingly creative, and keen to exploit subtle convoluted chance.

Here's one of the examples:

... tropical fauna and flora occurs in certain canals where water used to cool machinery is discharged. Thermal pollution of the River Don by the steel industry has enabled wild figs to colonize its banks

Interesting stuff. Go read the whole thing, and check out the source he cites

I posted this yesterday, and today I just stumbled on this, which purports to be an internal to Sun memo on Java:

This document details the difficulties that keep our Solaris Java implementation from being practical for the development of common software applications. It represents a consensus of several senior engineers within Sun Microsystems. We believe that our Java implementation is inappropriate for a large number of categories of software application. We do not believe these flaws are inherent in the Java platform but that they relate to difficulties in our Solaris implementation. We all agree that the Java language offers many advantages over the alternatives. We would generally prefer to deploy our applications in Java but the implementation provided for Solaris is inadequate to the task of producing supportable and reliable products. Our experience in filing bugs against Java has been to see them rapidly closed as "will not fix". 22 percent of accepted non-duplicate bugs against base Java are closed in this way as opposed to 7 percent for C++. Key examples include:

4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [[under jdk1.3.1, new JFrame launch causes jumping]

In personal conversations with Java engineers and managers, it appears that Solaris is not a priority and the resource issues are not viewed as serious. Attempts to discuss this have not been productive and the message we hear routinely from Java engineering is that new features are key and improvements to the foundation are secondary. This is mentioned only to make it clear that other avenues for change have been explored but without success. Here we seek to briefly present the problem and recommend a solution.

Go read the whole thing. If it's real, it's a fairly devastating indictment...

Have been getting very intense. Last week, Buffy had me on the edge of my seat - Joss Whedon had me gussing wrong the whole episode. I would have enjoyed Angel a whole lot more if the complete idiots at my local WB station weren't bouncing the broadcast day and time to broadcast boring college hoops. Meanwhile, 24 was as tense as ever last week.

Now if only Firefly hadn't been cancelled..... I mean really, Enterprise is so lame in comparison....

I've been working on memory settings for the application server (the one that runs this blog and other ST apps here). I've also been in the guts of BottomFeeder and some of the plugins for it. It was also a snow day and a Friday....

So now I'm watching Farscape, and am feeling lazy...

This is priceless:

Tag Soup RDF lets you create statements that the document/author made, that you or anyone else has made. The lies can be categorized and pruned to your or anyone elses whim. I really hope no one or at least very few, will ever have to manually produce RDF/XML. If you're a programmer use a library, if you're not use an application. If you want to write it yourself it's just like code or English - if it doesn't parse it can't be understood. Responses:

1. "Don't worry your little head about it, we'll build you programs to hide this horrific syntax from you." I've heard that before. Actually, I've heard a lot of it. Categorize under "engineers will save us".
2. Your RSS feed does not validate as RSS. Your feed (RSS 0.91, no less) is auto-generated by Blogger Pro, a closed source tool which you can't customize. Categorize under "tools will save us".
3. While we're on the subject of validation, your HTML doesn't validate either. Some of these errors are under your control (unescaped ampersands in links), others not (invalid HTML in the Blogspot-inserted banner ad). Lucky for you, my browser has been specially designed to work around errors like this and parse and display the rest of your page as best it can.
4. I tried to contact you privately, but neither your site nor your RSS feed contain any sort of machine-readable contact information. No doubt in an attempt to cut down on abuse by spammers. Categorize under "metadata will save us".
5. Your site does link to a web-based contact form, which is broken. I give up.

Ouch. I hope I'm never a target of Mark's. Go see his post for all the links.

You have to admit it's a funny item:

AN INSIDER AT Sun Microsystems says there's frantic discussion inside the company about big problems with the Java platform that, he claimed, "prevent general acceptance of Java for production software within Sun". He said: "It strikes me as hypocritical for Sun to blame Microsoft for any failure of the Java platform when Sun's own engineers find developing common software applications in Java impractical".

One of the problems, he claimed, is that while Java has a lot of benefits compared to C and C , its implementation on Solaris makes it difficult to deliver reliable applications.

I'm not sure the website here is the most reliable source, but I did get a chuckle out of this.

If you grab the latest DEV version of BottomFeeder, you'll see a number of bug fixes around feedlists. You'll also see that a new plugin is available from the Plugins menu. Kudos to Anthony Lander for contributing!

Anthony Lander has started working on an IM client for VW. So far he supports MSN IM, and I'm sure more will come. Check out the Pongo package in the public store

In fact, I'd go so far as to say that .NET is going to be ok for Smalltalk on balance. Have a look at this post from Ted Neward:

The point is that Java has a cocept of 100% pure Java, .NET libraries on the otherhand, it's not mentioned the degree of native code. For example JDBC has a concept of type 4 drivers, meaning 100% Java, is there a 100% CLR concept?

It's that last point that I want to highlight--no, there is no concept of "100% pure CLR", because the CLR embraces the "impure" as part of its reach. Can I build a "100% pure C#" application? Absolutely. But does Microsoft offer that as a marketing promotion? No; they think it's silly, because integration with the unmanaged world is a goal of the CLI, just as NOT integrating with the unmanaged world is a goal of Java. To treat the CLI in any other way is like claiming .NET is better than Java because it integrates with unmanaged code better--which it does, because that's a goal of the whole platform, just it's NOT a goal of Java's. Compare apples to apples, or your entire reasoning and conclusions are wrong.

Hat tip to Alan Knight for pointing me to this. I'd rather play the One OS, many languages game any day, compared to the One Language, many OS game. Since there isn't likely to be only one OS anytime soon (Linux, anyone?), it's a far safer field for Smalltalk to live in.

Decide for yourself:

Opera's techies downloaded the page using wget, in three different formats, identifying as Opera 7, MSIE and Netscape 7.01. The files sent to each browser are different, which is not necessarily suspicious, and the one sent to Opera7 has less content and is bigger than the one sent to IE. But that is not necessarily suspicious either.

Where it does get suspicious is when you look at the style sheets MSN sends to the browsers. The culprit, says Opera, is a 30 pixel value set on the margin property in the Opera style sheet. This instructs Opera to move list elements 30 pixels to the left of the parent, which means content moves off the side of its container, which means it looks like Opera is broken.

Opera tried to test whether or not this was deliberate by changing identification to the non-existent browser Oprah. This returns the IE style sheet, which works perfectly well in Opera. In Opera's view MSN is therefore looking specifically for "Opera" in the User-Agent string and sending it a broken style sheet. That, of course, could still be a mistake, as it's perfectly logical to send IE as the default if the browser can't be identified. But as there was no need for MSN to design an Opera-specific style sheet in the first place, one wonders...

Sounds kind of slimy to me. Go grab the whole story

For those of you tracking dev builds, I've posted a new one. There was a bug in saving feedlists related to BOSS, and there was a bug in decoding OCS files, due to a change in their format. I fixed the former, and Dave fixed the latter.

Spotted this in comp.lang.smalltalk:

For those who have been following the articles and presentations I've been giving on ElastoLab, I've finally released the 3.0 version. In this version, the physics code has been completely re-written in Smalltalk. I did this because I had to fix some tough bugs in the physics and implement a new algorithm to handle multiple particle collisions with barriers. It was much easier implementing this in Smalltalk than in C . The performance in Smalltalk seems to be reasonable, so it wasn't worth keeping it in C .

Along with this release, Simberon will be holding a contest to win one of three Microsoft X-Boxes. The best three scenes submitted before the March 31st deadline win an X-Box. See the web site for details.

ElastoLab is a physics playground for kids age 9 and up that lets them play in a world with gravity, springs, elastics, and more. A simple scripting mechanism allows you to create simple games and interesting simulations.

ElastoLab is written in VisualWorks Smalltalk.

For more information, see Simberon's web site at http://www.simberon.com.

I can vouch for the coolness of ElastoLab - and not just for 9 and up - my nephew (who was 5 at the time) - was utterly fascinated by this!

I guess I'll have to bookmark this page and check for changes to OCS more often. I was going to try and track down a feedlist bug when I found that I couldn't actually load feedlists from Syndic8 any longer.

Dave actually fixed the problem, and I can now go back to trying to reproduce the reported bug....

Here's a useful tip on using Apache without setting up any relays:

First, make sure that you build apache with proxy enabled (./configure --enable-proxy, for example). Then, add the following to your httpd.conf file. Modify the host name and URLs appropriately. Be sure to restart apache if you didn't already. Now, configure a TinyHttpServer (not an IPWebListener!) on the appropriate port (8008, in my example) and start it up. You should be able to reach your configure site by hitting apache with /configure/ as a path (note that the trailing slash is required).

When it's time to deploy you can look at further restricting who can access the /configure/ site as well as mapping urls like /shopping to /shopping/ (to avoid the problem of forgetting the trailing slash). mod-rewrite is good for this...

Read the whole thing

I got a bug report from our Doc guy, Richer Demers this morning. It was related to Twoflower - printing was failing. Since Twoflower is embedded in BottomFeeder, I decided to have a look.

Two things needed to be done:

1. Take account of what platform Bf starts on, and set the printing options accordingly at startip
2. Make sure that Twoflower uses the appropriate printer object based on the platform

The code had been (inadvertantly) Windows specific, but no longer. While I was in there, I added printer support to BottomFeeder - you can now print the HTML Window from a toolbar button or menu pick. The output could stand some cleanup, but it works.

See this comment thread over on Sam Ruby's blog. He's getting spam, and installing spam filters to guard against that.

way, way too much work for me....

Spotted in an email:

Having seen a great degree of programmer burn-out on 1.0, we have analysed the reasons for the same, and have concluded that the technology employed (Visual C ) was one of the major factors. We then started looking for alternatives. Cincom Smalltalk is one of the candidates that we are evaluating. My technical team is trying to implement a reference application using all the candidate technologies, for comparisons and metrics.

Come on in, the waters fine over here!

I read Sam Gentile's Web log on a regular basis, and usually enjoy his point of view. So I was really happy to see this post on his blog:

My work lately led me quite naturally to the seminal book, Generative Programming: Methods, Tools, and Applications. I read most of the book yesterday in one sitting (yikes!) and although I found much of it tough going, I want to share one key insight I got. I have always had a lot of trouble understanding the Smalltalk argument as put forth on places like Wiki when I used to be there and indeed the real advantage of late binding languages. I always viewed the safety of static type checking as a given. Well, in Chapter 6 on Generic Programming, in the area of Overloading and Parametric versus Subtype Polymorphism, is the example that lays it bare before my eyes and makes me see it.

Go read the whole thing to see his example. It's always nice to see people understand where the Smalltalk crowd is coming from!

I finally addressed a nasty problem in BottomFeeder. Some feeds - like Joel on Software's feed - use relative urls in the feed.

Now, IMHO, relative urls in a feed are a bug. However, as an aggregator provider, I get to grit my teeth and deal with bugs like this. So I dove into Twoflower code, and found that it had API's for this issue, and we just were not using the right one when setting up the HTML widget.

This would have been easier to deal with if the code we have for dealing with selection changes in the item list wasn't such an un-refactored mess. I haven't fixed that yet, but at least the mess now works. A new dev build is up, and feeds using relative urls should have working links and images now.