d2r links to Don Park's post about finding conversations. As it happens, BottomFeeder already does that. There's an option in settings (Do Item Cross-referencing) - if you turn that on, then items you subscribe to that are referenced elsewhere in your subscribed content will get flagged. I did that about a year ago, I think - it was a user request.
Ziggy makes some comments about version control, and exhibits some odd ideas about Smalltalk in the process. His prime objection makes some sense - "everyone" else uses file based systems (like CVS) for version control, and Smalltalk's failure to "get with the program" holds it back. There's some truth to that - but there are also some very good reasons why most Smalltalk systems don't fall back to CVS style systems.
It's not that it can't be done, or hasn't been done - VSE used PVCS as a backend (even though it hid it pretty well). ObjectStudio users tend to use SourceSafe or other Windows version control systems. The real disconnect comes with systems like VisualWorks, Squeak, or VisualAge Smalltalk - all classic image-based Smalltalk systems. Avi explains the issues well here:
The thing is, when you move away from code and into arbitrary data files, most of the useful features of *any* version control system go away. How well does the darcs theory of patches work on images? Can CVS insert its conflict markers into a Word file? And how many times do you need to cherry pick changes from a patch someone committed to an obscure branch of that project timeline? The most you usually need or are able to do is to associate a specific revision of a binary file with a specific version of the code, and it would be trivial to extend Monticello [VCS Avi has worked on] to do that if the need came up
Here's the commentary that I wondered about in Ziggy's post:
Smalltalk, on the other hand, doesn't integrate well with the version control systems we have all grown to love (or at least tolerate). Avi Bryant points out that these problems don't really surface for Smalltalk developers, because the Smalltalk VM can keep track of every change, and tag each change with more metadata than SCM tools can possibly capture.
Sorry, but I don't buy it. I call this "Smalltalk Disease" -- the arrogant tendency for Smalltalkers to dismiss a problem because they can mutate a Smalltalk image to nearly eliminate it. (And, if they haven't done it themselves, or the necessary features aren't present in your VM, then at least someone has done elsewhere, presumably in some production environment.)
OK. So you can upgrade your VM to handle versioning and merging of Smalltalk methods. Fine.
What happens when you want to version something else, like, data files, documents, or images? I guess CVS/Subversion/darcs/etc. aren't so useless after all....
Hmm - it's not a VM level thing - the code and parse trees are all available at the Smalltalk level - which is a large part of what makes them easy to deal with. The common Smalltalk VCS systems - ENVY, Store, Monticello - all deal with code artifacts at that level, and use some kind of back end (typically a database, although Monticello supports multiple back ends) to store source code. One could posit a CVS style back end, and I've seen it done - our partner Heeg has plugged in such systems for customers on a consulting basis. As to external artifacts? As Avi says, it's not that big a deal to extend that way, and - in fact - VW 7.3 (which will be released very soon) can handle external artifacts. It's become a big deal because of things like the Web Toolkit, where there are ssp files (and image files, etc) that make up part of the "whole system".
There are issues with the various Smalltalk VCS systems - ENVY doesn't handle merges well, Store has had problems with the nature of its db schema - and, as Avi mentioned in his post, Monticello is not perfect either. The point is, the various file based systems aren't perfect either, and they simply don't mesh well with image-based development.
Update: Colin Putney comments here, and Patrick Logan has some thoughts here. Ziggy makes follow up points over here
All I need now is Pooh flying Piglet as a kite. The wind is really blowing this morning - I just chased my trash cans down the street.
The Cincom Smalltalk Worldwide User's Conference is rapidly approaching - don't miss this chance to hear about our future plans directly from engineering! We also have outside experts coming in to talk - like Joseph Pelrine on SCRUM. We'll get started in Frankfurt, Germany next Tuesday - see you there!
While explaining why he blogs, Dave Winer explains something interesting about product development:
When I started blogging it was mostly to get a bunch of stuff off my plate, ideas I couldn't do anything with, things I wanted even if I couldn't create them. I hoped other people would read this stuff and someone would create what I wanted, and therefore increase happiness. Over the years I learned that this very rarely happens. People really want to come up with the ideas, even more than they want to be successful.
This sort of thing is very noticeable in open source projects - the developers will work on what interests them, regardless of what kinds of polish might be required to "finish" the product. This befalls commercial products as well; it's quite common to run across areas of a product that fall victim to the "80% rule" - 80% (the interesting aspects) of some feature get built, while the remaining 20% of "spit and polish" never happen - because it's considered uninteresting by the developers.
I've come to the conclusion that only a real user base motivates people to "finish" products. And even with a real user base, the less income that is tied to the work, the less likely it is to ever get done...
It's not for everyone, but I've been weeding out some of the partial content feeds - the ones that I would like to read, but tend to blitz by due to the teaser content. I've now got 4 scripts that create local full content feeds in order to replace the partial content feeds provided by the authors. I suppose this isn't the sort of thing that makes them happy; after all, it means that I'll be completely avoiding their html page (and thus, their sponsors). On the other hand, it's making my reading experience much more pleasant. If you're interested, see this wiki page for details and a short example script.
Darren Oakey makes a common mistake when discussing typing:
He's got a reasonably good technique - every function has a test that passes nulls to it - so very quickly you understand how your app deals with nulls. However, I'm not sure I'm buying in. This is like the smalltalk type arguments on weak typing compared to strong typing. Sure, we can rely on tests to ensure the robustness of the code - but there's a lot in me that says that's not the answer - I'd rather rely on the compiler if I can!
One problem - Smalltalk is not weakly typed. It's just not manifestly typed. C is manifestly typed and weakly typed.
Now here's some honest marketing for you - Scoble explains why he's not moving to MSN Spaces. Microsoft pushed out an announcement on their new blogging service (competing with Google) last night. Here's my biggest question on this sort of thing - MS and Google are supporting free blog hosting "for the masses" now. What's the revenue model here? Advertising I suppose... but on low volume blogs (which most are) - is that enough? Here's another thought - what's the upside for MS and Google in giving away space and bandwidth? What am I more likely to buy from them as a result? Just curious.
Here's an online video showcasing Self. Interesting, and illustrates the benefits of dynamic systems nicely
I've uploaded a new development build of BottomFeeder - all the changes are also available via the normal upgrade route (assuming you look at the dev stream). What's the change? Michael Lucas-Smith let me know about a change that would make the html display faster - they haven't turned it on ay SwS because it's not yet compatible with the editing of XML that they are concentrating on. For my purposes in BottomFeeder, that's irrelevant though. Have a look - you should see much better responsiveness
I guess Dave doesn't realize how many huge sites run on things like PHP, Perl and Smalltalk:
I've been getting lots of mail about the programming project described below. My challenge will be to try to organize the energy to actually create the needed software. People ask if C# or Java would be okay, and the answer is, of course. I basically meant "compiled code" as opposed to interpreted code. Static instead of dynamic. We have to cut to the metal. I also need to write up a spec that explains what the software does. Anyway, let's give it a couple of days to gestate. In the meantime you might start writing code. ";->"
I see that Sony - a company I usually think of as "getting" marketing - has come down firmly on the side of stupidity. While Ken Jennings was racking up victories on Jeopardy, lots of people were getting interested. It seems that Jason Kottke was just generating too much postive interest for the legal beagles at Sony. Apparently, he posted some spoilers for the last show, and Sony went all medieval on him. Interestingly enough, the Washington Post did the same thing, and Sony didn't so much as mumble. I guess only the small targets without big lawyers matter. I'm far less enthusiastic about the PlayStation 2 than I was a few hours ago. Good job, Sony legal. That sound you're hearing is a prospect sauntering off.
The Cincom Smalltalk Worldwide User's Conference starts next Tuesday, December 7. We'll be hosting Smalltalkers from various countries in Europe, the US, Canada, and South Africa. Come here user stories like this one from Peter Fichtner. We'll see you there!
Looks like IBM wants out of the PC business:
IBM, whose first PC in 1981 moved personal computing out of the hobby shop and into the corporate and consumer mainstream, has put the business up for sale, people close to the negotiations said Thursday.
While IBM long ago ceded the lead in the personal computer market to Dell and Hewlett-Packard so it could focus instead on the more lucrative corporate server and computer services business, a sale would nonetheless bring the end of an era in an industry that it helped invent. The sale, likely to be in the $1 billion to $2 billion range, is expected to include the entire range of desktop, laptop and notebook computers made by IBM.
Things get bought and sold between businesses all the time (think Lexmark) - but I have to wonder about one thing - what does this mean for the Thinkpad line? I've used a lot of laptops over the years, and the Thinkpad has been one of the nicest I've seen.
Yeah, this sounds like a plan:
The way the Internet was built might be part of the problem, he said. Its open architecture allows Web surfing, but that openness makes the system vulnerable, Mr. Tenet said. Access to networks like the World Wide Web might need to be limited to those who can show they take security seriously, he said. Mr. Tenet called for industry to lead the way by "establishing and enforcing" security standards. Products need to be delivered to government and private-sector customers "with a new level of security and risk management already built in."
Hmm - will someone let Mr. Tenet know that the net isn't solely a US thing? Could someone else explain why a decentralized system is inherently more secure than the centrally monitored system he sounds like he'd prefer? Sheesh.
The script tool has made it easier for me to follow a bunch of comics that I like - I can easily scrape any of the feeds on the comics.com site into a local RSS file that I can subscribe to. Here's the script I use:
contentBlock := [:builder :chunk | | lnk | lnk := 'http://www.comics.com', chunk. builder link: lnk. builder title: 'Monty: ', Date today printString. builder description: '<img src="', lnk, '">'. builder pubDate: Timestamp now]. out := 'monty.xml' asFilename writeStream. writer := RSS20_SAXWriter new output: out. writer prolog. writer startRSS. writer startChannel. writer title: 'For Better, For Worse'. writer link: 'http://www.comics.com/comics/monty/index.html'. writer description: 'Monty'. writer pubDate: Timestamp now. writer startItem. writer title: 'Monty: ', Date today printString. content := 'http://www.comics.com/comics/monty/index.html' asURI valueStream contents. str := content readStream. str throughAll: '<IMG SRC="/comics/monty'. str upToAll: '<IMG SRC="/comics/monty'. str throughAll: 'IMG SRC="'. rest := str upToAll: '"'. contentBlock value: writer value: rest. writer endItem. writer endChannel. writer endRSS. out close.
That script works for any of the comics on that site; all you have to do is change the titles and urls. I'm now subscribing to a bunch of the things there.
A common need in any application is Windows that cooperate - child windows that close when their parent closes, etc. It turns out that it's pretty easy to set that up in VisualWorks - I've needed it in BottomFeeder, and I'm sure that most Cincom Smalltalk developers need this capability at some point. So how do you do it? Let's start with the 'main application window' - add this to the #postBuildWithMethod:
postBuildWith: bldr super postBuildWith: bldr. bldr window application: self; beMaster.
That sets the 'main application' window up as a master - child windows will receive most of the same window events and follow them. Now you need to set up the child window. Let's say that it opens up from some method in the main application:
openSomeTool | tool | tool := SomeTool new. toolBuilder := tool allButOpenInterface: #windowSpec. toolBuilder window application: self; beSlave. tool finallyOpen.
What's going on here is that you are registering a specific window as the 'master', and another as the 'slave' - which means that a set of events received by the master window will be passed along. If you want events passed equally, then use #bePartner to all involved windows.
It turns out that you can customize the set of events you care about - a quick look at #beMaster and #beSlave in class ApplicationModel shows this:
beMaster "Send windowState events to other ApplicationWindows that have the same application as us. Effectively the dual of beSlave." self sendWindowEvents: #(#close #collapse #expand ); receiveWindowEvents: #(#expand )
beSlave "Receive windowState events from some other ApplicationWindow that has the same application as us. Effectively the dual of beMaster." self receiveWindowEvents: #(#close #collapse #expand ); sendWindowEvents: #(#expand )
You could easily add your own custom versions of #beMaster and #beSlave - and either expand or contract the list of window events. You can also use #sendWindowEvents: and #receiveWindowEvents: to tailor the event stream. It's all pretty easy to manage.
Why do some languages catch on while others don't? It's all about facial hair. I guess Alan Kay needed a beard, or a bigger mustache...
Rich is blogging again, and has an update on Smalltalk Doc. It is in preview for VW 7.3 (which will be out any build now :) ). It's not so much that ST Doc is "not a priority" as Rich says; it's more that it's one of many priorities we have. So many priorities, so little time...
Binkley says that you can do hot (runtime) patching in Java now - from this article we get the following:
But ah-hah! We do, we can use a different implementation of FunctionTable which stores the method body as a String in Derby and uses BeanShell (or Janino!) to invoke it. So a method invocation is completely configurable at runtime! Not deploy time, runtime. If you find a bug, you can fix it without a redeploy.
Uh, yeah. Go read the whole post to see just how simple it really is. meanwhile, all I have to do in Smalltalk is load in a new version of my code, and I'm done.
Mark Derricutt extolls the virtues of full closures - and his post gets picked up by Sys-Con, an online Java 'zine.
Strongly Typed misconstrues the terms again:
WOW! There's quite a discussion going on regarding Stongly-Typed languages and Dynamic Languages.
A common point that I see in the discussion is compile time / run time checking. A strongly typed language will do type checking at compile time and reduce run time errors. Because of that dynamic languages will require the programmers to be more responsible.
Strong typing has nothing to do with whether the check is at compile time or runtime. Smalltalk, for instance, is strongly typed - you can't get a type error. If you send a message to an object that doesn't understand it, you'll get a well understood exception. C++ - which I guess is "strongly typed" in Richard's world - forces type declarations up front, but you can, via the wonders of casting, send wholly inappropriate messages to objects and get nice, malformed core dumps. Yep, that's safe. Hmm. Java lets you walk into that same minefield with casting, although the results are far less dangerous (the runtime system deals with them far more gracefully). His example is laughable:
I believe strongly typed languages yield better encapsulated code because requirements are explicitly presented up front. To illustrate this, lets make believe. Let's pretend we have a method called foo:
Public Function Foo()
End Function
All we know about it is that it returns a numeric type. But we only know that because we ran a few tests and made a reasonable assumption. Assuming that it returns a Integer type we go on to code. At some point we end up using the value from Foo in another call:
FooBarProcessing(VarFromFoo)
We run it and everything works great. Days go by and everybody's happy. But unexpectedly, after our code was released, it breaks.
What happened?
After an hour of debugging we find Foo returned a value of 100,000. FooBarProcessing only works with a 2 byte integer. Something we didn't know at compile time. We only found this out because we obtained the original source code and traced it through. So much for encapsulation.
That break isn't due to dynamic typing, but due to a lousy type system - one that every C based language shares, btw - in this case, his "fix" is to declare the variable an int (likely a 32 bit value, but that's an implementation detail left floating around to bite the developer). Now, let's examine that in Smalltalk - where the number would not be constrained to a range (unless there was a domain reason for doing so, in which case we would enforce that via code). In Smalltalk, there is no such thing as overflow for integers. So yeah, this is a typing problem - it's a problem with the typing system that Richard thinks is saving the day.
Peter Williams Lount addresses what Birdman's Land calls OO's Achilles Heel:
"When everyone defines their own objects, then all [Object Oriented programming] does is bog you down trying to convert between two mismatched items."
I don't think this problem is specific to OO at all; it's a general domain level problem that has cropped up in many places (how many people have tried to define a generic "Person" object or data structure, for instance?). Peter's got a long dissertation on that subject; have a look
One of the things that helps a lot in a product manager's job is knowing what people are saying about your product(s). One way of doing this is face to face communication, and it's usually the best way. Unfortunately, I'm not really able to visit with all of our customers on a regular basis - there are too many of them, and they are too widely scattered (all over the world). We have local people, and they talk to customers (and in turn, to me) - and I visit with various customer groups at shows, conferences, etc. Still, it's not enough - I really need to get more. Enter the BottomFeeder
One of the more useful things I built int Bf is support for the RSS/Atom feeds that various search engines support - you can get results in a feed from:
And many others. I don't use pubsub, because their whole email subscription system was an extra step; call me lazy. It also helps to check Technorati on a regular basis. What I've done is set up search feeds for these engines looking for references to these terms: Cincom, Smalltalk, VisualWorks, ObjectStudio, James Robertson, BottomFeeder. I run across comments made about my company and/or its products pretty darn quick this way; it fills in the gap created by the impossibility of meeting regularly with all customers - not to mention the fact that it finds commentary by potential customers as well.
If you're involved in product promotion or customer relations in any way, you need to be tracking this kind of information. Get yourself an aggregator and start searching!
Blogging Roller explains everything you'll ever need to know about child behavior:
I've got a theory about why kids can make parents so angry. They don't realize it, but kids emulate their parent's verbal and physical mannerisms all the time. As you watch your child you can see bits and pieces of your own personality. They pick up on the little phrases that you repeat. They repeat them too. When your kid starts to fuss or throw a tantrum or otherwise behave like a jackass, he does it in a way that reminds you of yourself, your mannerisms, and your personality. You see your own inner jackass reflected in the actions of your child. Your kid learned how to be a jackass directly from you, it shows, and boy oh boy does that piss you off.
I've gotten a number of questions about how to build a BottomFeeder development image. I've finally got a set of basic instructions up on the site - follow the download links and grab the first download available under the DEV links (scroll down). Here's what you'll need to do first:
When you uncompress the file, you should preserve the directory structure. You may need to adapt the script file based on what you do there. Enjoy!
I'll be offline for awhile later today - I'm heading to Frankfurt, Germany on an overnight flight. I'll be speaking at and attending the Worldwide User's Conference - I hope to see a lot of Smalltalkers there!
One of the things we have been looking at is re-hosting ObjectStudio onto .NET. This is research at present - we have not committed to such a project! As it happens, I'm writing this while I'm on my way to the User's Conference in Frankfurt - and I ran across Larry O'Brien's latest article in SDTimes. He's talking about "little languages" (what most people call Domain Specific Languages, I think) - and in the midst of that, says the following:
A fundamental premise of .NET is that a platform that is explicitly designed to support multiple languages and programming approaches is superior to a platform, notably Java, whose design is dominated by the needs of a single language. I am convinced that Microsoft is sincere in trying to give the .NET managed platform as much flexibility as possible, albeit for the purely mercenary purpose of being in a position to explout advances as they enter the mainstream
Hmm. That explains why VB didn't change at all once it morphed into VB.Net, right? ,NET supports any language, so long as it ultimately behaves a lot like C#. Going back to our ObjectStudio plans - we've taken a good initial look at the platform, and our engineers have found a number of issues - any Smalltalk built on top of .NET is going to have to make a lot of compromises, because there are a lot of things you can't do:
Some of those might seem like things you wouldn't 'normall' need - say, changing the class of an object. On the other hand, have a look here, at one of my posts on BOSS Schema migration. BOSS is the VisualWorks object serialization framework; schema migration involves changing the class of an object as you get it back from disk. Would you have to implement a framework that way? Clearly not, or else Java wouldn't support serialization. On the other hand, it's how it was done in VW, because it was pretty easy. Some of the other problems get right into the guts of typical Smalltalk operations, like interactively modifying a system (any time an end user applies an update to BottomFeeder, for instance, that happens).
Ultimately, .NET only looks like it supports multiple languages and paradigms from the narrow perspective of the C language family - many things we take for granted in Smalltalk are simply inconceivable to those guys. if you can't imagine it, you don't even know that it's missing. Now, I'm sure that one could build a middle layer over the top of the .NET runtime to deal with these issues - but it would be hard, and the resulting system would be slows. Supposedly, many of these issues will be addressed now that the iron Python guy is working for Microsoft. We'll see...
I'm on the flight to Frankfurt as I write this. Supposedly, my presentation for the conference is all done - it's on the CD that the marketing folks are going to hand out at the show. Like most presenters, I'm simply incapable of leaving well enough alone - I had to twiddle with my slides.
As it happens, the presentation is going to be my standard "where we are, where are we going" spiel. I haven't been happy with that presentation for quite some time now - it's repetitive, too wordy, and too long. You could say that it needed refactoring. So, with nothing better to do before they turn the lights off on the flight, I've gone ahead and refactored my slides. As soon as I have a network connection again, I'll upload the new presentation to our Wiki
I may well be off email until Friday - the hotel I'm at has no broadband, and dialup looks dicey - seems that you have to request a room with an analog line, and I haven't done that yet. I'm in the Frankfurt Cincom office today, and they block email access unless it's going to their servers... which I don't use (for reasons that are way to stupid to go into here). So bottom line - if you don't get an email response from me this week, don't be too surprised.
In a post explaining Python for Java developers, there's a hilarious paraphrasing of a comment on RegEx:
XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."
Heh. Oh, read the entire post as well. Everything he said about Python relative to Java goes for Smalltalk as well.
I've got dialup in my room here - very, very slow dialup. Also very, very unreliable dialup :). I'll be taking notes at the conference and posting things up nightly, but I don't think I'll be able to keep up with all my normal reading - the connection is just too dodgy.
Len Lutomski and Andreas Hiltner are up with the new Opentalk for ObjectStudio stuff - they'll have a live demo of VW <--> ObjectStudio interoperability. Cross platform as well, with the VW side running on a Mac.
So, There's a demo of a chat application (shipping on the CD) - and they'll go over the cross dialect portability issues. First, what's Opentalk? Opentalk is the framework used in VW for the creation of communication protocols. ObjectStudio 7.0 contains a release quality version of Opentalk ST-ST (Smalltalk to Smalltalk). ObjectStudio was extended quite a bit to achieve this - the upshot is that Opentalk in ObjectStudio is identical (at the user level) to Opentalk in VW - so user code will move between the two easily.
ObjectStudio now supports multi-image applications, including VW images on non-Windows systems. This extends support for OST features to VW users, and of VW features to OST users.
Now they are showing the demo - chat windows on Windows in ObjectStudio, and their analog over on the Mac in VW.
Len's now going through some basics. Three topics:
This stuff is all discussed in the doc. A request broker implements the API of interest to applications. A protocol implementation consists of
Creating a broker (you can specify the address for systems with more than one network interface). A broker is actually a fairly complex object - the simple API below flares out to define all the parts described above (adaptor, transport, marshaler, dispatcher). That means that you can customize these parameters, or derive your own protocols and slot them into this api easily.
"create it" broker := RequestBroker newStstTcpAtPort: 1900. "start the broker" broker start. "stop the broker" broker stop.
Now, why would you want to customize the dispatch? In VW, a new process is just a lightweight VW process. In OST, it's a Windows thread. That could tie a Windows system down quickly - you'll want to configure pool dispatch. There's some basic protocol for testing connections - echo and ping. Echo sends an object across and then gets it back. So you test marshal and unmarshal on both ends.
Now, to actually accomplish something you need to reference some object on the remote side. A reference is a local proxy object that re-implements doesNotUnderstand: to forward messages. When you send a message to a reference, you are sending it across the wire. There are two ways:
"create" broker objectAdaptor export: someObject oid: #greeting. "reference remotely" remote := clientbroker remoteObjectToHost: 'localhost' port: 1907 oid: #greeting "server registry" broker registerService: Random new id: #random "client" remoteObject := (clientBroker activeBrokerAtHost: 'localhost' port: 1907) serviceById: #random.
What about pass mode control? Pass mode is how it's transmitted - for instance, by reference or by value. Copying a large object across the wire can be expensive. Passing by reference is cheap, but messaging that object may be expensive. You need to balance the two. By default in Opentalk, most things (not immediates, literals, few others) are passed by reference. You can override that at the class or instance level - there's an API to coerce the pass mode. You can customize down to the instance variable level if desired. Opentalk supports several pass modes and pass mode controls - check the documentation.
What about cross dialect issues? You need to be aware of them - they are all documented. Base classes are mapped already - so VW and OST collections pass between each other seamlessly. There are some disparities in Magnitudes:
The error messages coming from OST and VW will differ as well (i.e., the error strings from things like MNU, for instance. That wraps things up, and unfortunately, time was a little rushed. I think a number of people are going to want to see this in the demo room later. Another upshot - having done this, porting Opentalk to ObjectStudio means that it should be fairly easy to port over to other Smalltalk implementations.
Now we have the first technical talk of the talk of the conference, after my overview of product directions. Alan's talking about Web Toolkit - the VW Web Application server capabilities. This all started (for VW) back in 1995 with VisualWave. in 2001 we introduced the Web Toolkit with VW 5i.4 - an ASP/JSP compliant toolkit. It started out sharing most of the infeastructure with Wave, and has been increasingly sharing infrastructure with Opentalk - instead of 2 server frameworks, we are converging towards one.
Why WTK? "Standard", but better. It's simple, reliable, secure. It's also easily debuggable - i.e., - slap a halt inside an ssp page and bang - into the debugger. Contrast that with the equivalent in WebSphere (etc) jsp - lots and lots of extra boilerplate. What Alan is really on about is the latest and greatest in WTK, along with some tips
With 7.3, we have better international character support. One of the issues is that the web started out very English-centric, and international support has been very much a catch up game. One of the main things we did in 7.3 was to separate the locale and charset - which had been tied together in previous releases. What are the main charset issues?
The probem with URL encoding? What encoding is it? The standard seems to be converging towards utf-8. Typically, browsers use the encoding of the page containing a linked url. This tends to get ugly. Here's what we do:
What about scalability? Pure Smalltalk scales quite nicely (proxying from web server directly to the WTK server or exposing the WTK server directly). Gateways allow connectivity and interoperability. We've got a Perl gateway in this release, primarily for use with Apache. We also updated ISAPI. NSAPI and FastCGI have been deprecated. Configuration of these can be a pain - you need to check the doc for your web server carefully.
What about memory tuning? You need to look at both ObjectMemory and MemoryPolicy. In 7.2.1 and 7.3 we have modified these - LargeSpace has been made much bigger - this is to deal with socket buffer issues. The upper bound has been moved down to 160MB, so you need to check that. We have implemented some buffer reuse, but it's not yet optimized. You really, really need to test this out for yourself!
Load Handling? There are now parameters for:
There is an Opentalk based load balancer that ships with the product. There is also a more general (and more generic) Opentalk balancer that well be adapted to replace the WTK specific balancer. We do not support session migration.
Subsystems/Headless support. We added a defined startup/shutdown procedure to this release. Before, there were a few big methods in ObjectMemory that did everything. We've refactored it all. They are kind of like Unix run-levels. There are subsystems for the Windowing System, for User Applications (main() ), for Opentalk. This replaces being a dependent on ObjectMemory. That's still supported. You can specify pr-reqs and command line options. This makes headless operation more definable. You can easily drive it this way:
WindowingSystem canActivate: false. WindowingSystem canActivate: true; activate.
There are a number of useful command line flags:
You can disable these for end user applications!
Heeg has created a nice goodie called VisualWAF - it's a layer above WTK for application development. There's also Seaside, which is now shipping as a goodie in 7.3. Then there's WithStye, an XML editing/display toolset for VisuaLWorks.
Question: from Georg: What do you use to create a simple, easy to edit website? I recommended WithStyle, and Andrew McNeil has demos available.
Question: What about multi-language websites? You can have specific tags that specify their encoding. Answer: That's fine, the server is ok with that. It's only an issue with form data, query data (etc) that comes back - need application specific logic there.
Comment - several people would be interested in the WithStyle demos - we'll have that going in the "Meet the Experts" room.
Alan, Len, Andreas, and Mark are demonstrating a usage of Opentalk to publish data from ObjectStudio to the web. It's a simple demo - an SSP page and servlet on the VisualWorks side, with Opentalk used to communicate back to ObjectStudio for the data.
"get the name from the form data and then use it to get data from ObjectStudio" name := self request anyFormValueAt: 'name'. data := self class defaultServiceReference select: name.
Note - you can't just expect to pull a stock ObjectStudio client/server application and push it behind a VW web application - you have all the single user/multi-user issues that would need to be addressed. The summary from Alan - it was more work to create the simple HTML pages than it was to code up the data transmission piece.>
Question: Has anyone used this in the real world yet?
Answer: Yes and no. There are some OST customers using the preview version that shipped with 6.91. As well, Opentalk itself has been used in production by many people using VisualWorks.
Question: What about the documentation? Is it well documented?
Answer: Yes, the documentation shows all this.
Andreas Toenne of Heeg is going over the DotNet connect for VW. .NET is Microsoft's managed platform (their answer to J2EE). Huge, growing library of windows libraries and services. It's (in theory) the future development/deployment platform for Windows based applications. It is easier to work with than C++ - a big step up. Not as productive or simple as Smalltalk, but a step up for the C++ world. The .NET connect is our way of interfacing VW applications with a C# (or other CLR based) application. Most of this talk is demo again. The demo is a simple one - captures mouse clicks, and sends them to VisualWorks to chart.
First step - install the DotNet connect into the environment (load the parcel using the parcel manager). Second step - create (edit, compile) the C# application. There are already some pre-generated links for things like WindowsForms.
Next - start the wizard. The wizard allows you to adjust settings - what to import - the assembly or assemblies in question, for instance. The wizard imports all the methods/constructors (notifying you of problems along the way) - allows you to filter out any you don't need to hook to as well. What's generated is some C++ code that needs to be compiled (an nmake file is created as well).
Important here - you need not buy anything from MS here - you can download the free tools from MS (all command line). You can also, of course, work with VS itself.
Next - Load in the generated Smalltalk code (the wizard created that as well). Right now, this is a set of (load order important) .st files. By the next release, this step should be a lot simpler. What comes in is a namespace, some stub classes that are needed, and an external interface class that hooks to the DLL (generated in the step above).
Finally, we need to link up the events that are coming from the dotNet dll with your Smalltalk code - here you need to write some code. I'm sitting at the back of the room here, so I can't actually make out the code itself - there are demos shipping with VW 7.3 (including the NC). At this point, you often need to go back to the generated C interface and change the relevant API to be threaded.
There are a few choices for talking to a .NET application:
The way in for us is through the unmanaged bridge that MS put in for all the existing C/C++ code out there. On the VW side, a proxy layer was built to manage that communication.
Limitations
The documentation covers all the limitations (I didn't get all of them down here). The performance is very good - method calls and returns are very fast.
Future steps:
You can see a high level view of this in our DotNet Whitepaper.
The first day of the show is over. It was a good day - lots of good conversations with users of VisualWorks and ObjectStudio, lots of good presentations. My notes are up - scroll down. I'll get Niall's copious notes at some point in the future and post those as well. I got the pictures from Andrew McNeil, our guy in Sydney, Australia. Here's how I looked this morning, talking about the product roadmap:
I think Scoble hasn't thought this one through:
Om Malik says that the personal blog is dead. Oh, yeah! Well, personally, I know a whole lot of people who are publishing blogs for just their friends and family. You wanna read some blogs that have very few readers? Just click randomly on the page at Weblogs.com. You'll find lots of blogs you haven't heard of yet. The question is, are any of them interesting?
Or, visit MSN Spaces and look at the "just updated" part of the page.
But, sadly, OM is right. It's getting harder and harder to keep up with the rapidly-spreading blogosphere. In the end, it's going to be automatic tools that really help you find the good stuff.
You mean like TV killed radio? Or do you mean the way Radio had earlier killed off magazines? And as useful as Amazon's "readers who bought this also bought blah" is, I still tend to focus in on new books by authors I already like. In the same way, I seriously doubt that I'll cede control to a search bot for all my news - I'll continue to personally look for people who I find interesting. Search will get better, but it will augment, not replace what we do now.
There were a lot of comments on this post, as well as posts on other blogs. Peter William Lount has some more commentary up today
In response to this post, Patrick Logan has some thoughts on an appropriate place to start for a "Universal VM":
I would consider Erlang/OTP, Gambit Scheme, Cincom (VW) Smalltalk as better starting places (among several others), for inspiration if not implementation in support of this vision. Note that Gambit Scheme has hosted Erlang in a prototype that appears to be roughly equivalent in scalability. Note that the Cincom Smalltalk VM appears to be scalable for web systems and capable of running Python a good bit faster than CPython. So I am nominating them as candidates for hosting multiple languages on multiple platforms in support of the dynamic vision above. And with a fair bit less overhead than is apparent in the dotnet runtime as per its own definition.
Believe me, this is something we've thought of - and it's something we are seriously considering...
InfoWorld points to a LinuxWorld story on a fascinating possiblity in the PC space - could IBM be interested in buying Apple?
When the news got out last week that IBM is considering selling its PC unit, rumors started swirling that Big Blue may be maneuvering to buy Apple. LinuxWorld has the story here. The LinuxWorld article says that swallowing Apple would be one way for IBM to avenge rival Microsoft for that "bad blood over early versions of Windows."...
The big question - would Apple still be Apple after such a thing? I have my doubts...
Vassili Bykov and Joseph Pelrine on XP - it's an unscripted talk. Joseph - "Without VisualWorks, and Envy, and Gemstone, XP never would have happened. Something else might have happened, but it would have been as crappy as many other things in Java".
Joseph: What would you do differently, if your customer could only pay you for one day of software development? Especially if, by doing something different, he would be able to afford yet another day of software development? What would become important, and what would become less important?
The consultants view: The customer is healed when all of his money has been removed. To increase the quality of your code, bring these practices into your team:
You should also have some (minimal) coding standards. A team should be able to agree on some set of them that makes code consistent across the development team. Continuous integration - always being able to have a functioning version of your project - is crucial. If it's a PITA to do a build, you'll do it less often...
This talk is more like an interactive bull session between Joseph, Vassili, and the audience. There's a lot of good humored back and forth with the audience. Jospeh and Vassili are now launching into a TDD session with VisualWorks - starting with a test for a simple application. One thing right off - his first test is a simple one that passes - and Joseph points out that this is a bad idea in general - it gives you no new information When you write new code, the test should fail (because it should precede the new code). So they walk through a simple exercise of creating a Person class, with the test driving the required code. It's all basic stuff, but it demonstrates how a pair programming, TDD session ought to run (at least, how one in front of a live audience should run :) ).
A small aside at this point about the benefits of Smalltalk - it's a real boon to have the refactoring/test tools built right into the development tools - you don't have to step out of one toolset and into another in order to get things done. To get from where you are now to TDD - take what you normally do in a workspace and slap them into a test class instead - it automates the process.
Finally, Joseph is previewing what's coming in the next rev of SUnit - TestErrors and TestFailures will be full classes, and he's added report logging (using the same format that ANT uses). "If you don't know enough to write the test, do you know enough to write the code?"
This is mostly demos from Vassili - there aren't really many slides (and he's used a VisualWorks framework for slides anyway...). So where are we in terms of tools in VisualWorks? What we have now are "legacy" tools from the ParcPlace/ObjectShare days, plus new tools that have been submitted from the community. At present, tools integration is kind of like having a single fire hose to put out multiple house fires - there's a lot of integration that needs to be done. What we'e done over the last few years is to concentrate on the user interaction level - making the tools more user friendly and modern (especially the look/feel). We're going to see a few Pollock demos, but - here's a caveat - Pollock is currently at Feature Set I - meaning, it's partially complete, but not yet "baked". In other words, some of the underlying infrastructure may well change.
First up - Trippy, the inspector introduced in VW 5i.3:
Pragmas in VW.
size <primitive: 62> ^0
The code in the method does not execute - this calls into the VM. It's not really a pragma. What Vassili is talking about is things like menu pragmas:
browseAllProbedMethods <menuItem: #(#_BrowseProbes #pdp '&Browse Probes') icon: nil nameKey: nil menu: #(#menuBar #probes) position: 30.1>
That's Smalltalk code that gets executed, not a call out to the VM (or in the case of DLLCC, to a DLL). The syntax is somewhat limited - you can't just write any old Smalltalk code. If you look at the byte code though, you'll see some attributes - you get a method with a label:
if you define new pragmas, you need a (class side) definition method. Initially, pragmas came in to allow ad-hoc extension of menus (without the issue of multiple applications waxing the same method):
example <example: 1 difficulty: #medium> "code here"
pragmaDeclaration <pragmas: #instance> ^#(example:difficulty)
So - how do we find pragmas if we want to browse for them? Well, clearly you can iterate over a set of methods and look for annotations. However, when a class gets a pragma added you'll get a change message - #instancemethodChanged (for instance side pragmas). There's a class called Pragma that has some protocol making it easier to find them in the system. Immediately, Joseph Pelrine noted that this could be used to make it easier to locate test cases in SUnit.
Moving on - the bottom of the launcher is actually a tool dock, to which you can add your own tools. There's a monitor for Store and for change sets there already:
So to add something to the tool dock, add a method to the launcher:
applicationOpener <component: 100 class: #[BrowserOpener] #spec #windowSpec> ^self newTool: BrowserOpener
So what about adding auto-completion? It turns out that there's a tool module for that - in the #postBuildWith: method you add a completionDriver - have a look at the way it's used in method lookup, etc. in the the current system. There's a reusable dialog as well - IncrementalSearchDialog
dialog
requestWithSuggestions: #('one' 'two' 'three' 'four')
filterBlock: : [:entry :suggestion | entry, '*' match: suggestion].
As a side thing, Vassili is showing us ad-hoc delegation with pragmas - very cool. You can easily define a set of allowable message names to relay onto a defined object.
Finally, we're looking at the Settings framework. That's a cool piece of work - I've mucked with it a fair amount in BottomFeeder. Learning the settings framework will walk you through pragmas as well. One nice thing I discovered is that it's easy enough to change the settings storage mechanism. VW uses an XML file, and allows you to save individual settings pages. I was able to override that in a subclass to save to an ini (key=value pair) style file. It's a very nice piece of work. The nice thing is this - if you mess up when defining a setting, the settings tool itself handles it (showing a "debug" button in development
Now on to the Pollock section of the presentation. I won't have screen shots for any of this stuff, since all the relevant examples aren't available to me at the moment. Looking at tooltips - In VW, the tip pops up as soon as the mouse goes over the relevant screen object. On the Mac (for instance), you need to linger the mouse over the same place for a moment before a tooltip appears. The way this works is a finite state machine, cycling between armed (ready to, but not yet), cool (not active), warm (firing), reaper (get rid of the tip). Most systems (like the mac) don't do "Warm" - VW does. That's why you get a tip for each toolbar button as you move the mouse across the toolbar - the FSM cycles between "warm" and "reaper".
We are having a look at the Pollock version of the completion driver now - same thing as the current implementation, except that the code is cleaner.
Hat tip to Steve Kelly for providing me updated versions of three games - Xonix, Asteroids, and Golden Monkey. He packaged them up as BottomFeeder plugins, and they are now available as updates on the dev upgrade path. Very cool
This is being given by Helge Nowak, our German tech sales rep - which means I can take notes instead of being up in the front of the room :). ObjectStudio is an important piece of Cincom Smalltalk - while VW gets most of the (verbal) attention, OST is used quite a bit in Europe - particularly in German speaking Europe. What we are looking for here is direct feedback from our customers as to where we should be heading with the product - there are a couple of possible routes forward on the VM level.
First off, why are we at something of a crossroads at the VM level? OST has a byte code interpreter, not a JIT. That means that relative to other Smalltalk implementations, it's execution can be slow for certain CPU intensive operations. We have a fast, cross platform (including Windows) execution already - the VW VM. However, OST is a Windows specific product which ties fairly tightly to things like the Windows GUI and COM components. So, that puts the MS CLR (the engine used by the various .NET languages) out there as something we need to investigate.
What have we learned about from our OST customers?
We are addressing a lot of that already - by bringing Opentalk to OST, we have connectivity and interop with VW, and the stack of services it supports. We have improved execution speed over the last two releases, and made a number of improvements to the COM framework. So that leaves us with a discussion that we need to have both internally and externally: do we take a serious look at the CLR, or do we extend and enhance the existing VW execution engine to support the things OST needs (Native Windows widgets and full COM support, for instance). This would be of interest to both OST and VW customers - it would extend OST services to VW users - and there are plenty of them that VW users would be happy with (Native Widgets, full COM Support). Of course, OSt users would benefit as well - much faster execution and (better) access to the stack of VW services.
One of the primary issues in front of us is customer impact. Either change will result in some level of migration effort for end users of OST - we would like to minimize that impact as much as is possible. With that in mind, let's look at both options:
ObjectStudio for .NET?
This would mean an OST VM layer glommed on top of the CLR. It's an interesting question as to how big that layer would be - it all depends on how many services can simply be handed off to the CLR. Why would we want to go this way?
What problems would we have?
The possible solution to that is Whidbey, which is a long term plan on their part to get to better support for dynamic language features. Sadly, it looks like a lot of where they are going is not going to give us much of what we need. For instance, the CLR lacks support for these kinds of things - i.e., we would have to glom these into our own layer:
Whidbey would be the first reasonable CLR to start with (and it's a ways out). The MS roadmap is not completely clear to us on this. What it amounts to is this - we would have to create our own dynamic layer on top of the CLR, and that would be a non-trivial task. In the process, we would lose some of what makes Smalltalk... Smalltalk. Additionally, some of the migration (on the part of customers) would be onerous - existing GUIs would need to be redone. If we could get there, the end result would likely be good for customers (with the above caveats). The problem is, it might be a good ways out - due to the current lack of support in the CLR. And before someone else brings up Iron Python again, note carefully what Patrick said about it.
What about OST/VW co-habitation?
This would mean OST uses the VW VM (with changes made by us in both directions as required). It would not mean sacrificing existing OST services - these (GUI, COM, etc) would move to the VW VM. The end result would be that VW code and OST code would be (mostly) portable between the two systems - potentially opening up the entire VW stack to OST users. Again, we would build an OST compatibility layer on top of the VW VM. The difference here is, all the engineering effort (and code) would be accessible to us, so changes could be made on either end.
In either case - VW VM or CLR - we really can't deliver an interim release. Either the migration will be done or not; once the decision is made, we'll be going in that direction until a final release is ready to be used. The biggest benefit: We can make this work exactly like the current ObjectStudio product. The caveat there is that going all the way there may limit our ability to make use of extant VW tools in VW. On the other hand, there may well be migration effort (the level would vary) if we made use of the existing VW tools.
How does this match cuctomer needs?
To get to ObjectStudio .NET - it's a radical approach. It's also highly dependent on Microsoft's direction and delivery schedule. It's also the case that we would need access to outside knowledge (i.e., raising the expense of doing this). Translation to you - it would take longer. What about using VW - all the knowledge is in house, and the delivery would be under our control.
This is the point where we need help from the ObjectStudio community. We want - and need - your feedback.
|
| Subscribe to WebVelocity |
| Visit this group |