Sunday, March 28, 2010

Wikipedia green thread article

Wikipedia's green thread article states that most Smalltalk dialects implement green threads. Why is the term most used for the assertion? Don't all Smalltalk dialects implement green threads?

34 comments:

gaelli said...

I believe Smalltalk MT (MT as multithread) uses native threads:
http://www.objectconnect.com/stmt_overview.htm

Markus

jarober said...

So far as I know, Smalltalk/MT uses only native Windows threading

Carl said...

I believe that Smalltalk MT implements red threads.

Reinout Heeck said...

Smalltalk MT might be sufficiently oddball, see the heading 'multithreading' here: http://www.objectconnect.com/products.htm

Anonymous said...

No, for instance Smalltalk/MT uses native threads.

Thomas said...

One could refer you to older versions of one of your employer's products. There's also Smalltalk MT...

Gaboto said...

What about Gemstone?
it says that it run native threads:
http://www.cincomsmalltalk.com/userblogs/badger/blogView?showComments=true&entry=3342683829

John Dougan said...

Smalltalk/MT for sure and maybe F-Script.

Peter William Lount said...

No, Smalltalk MT (Multi-Threaded) implement NATIVE THREADS. They t[h]read where other smalltalk vendors and vm makers fear to go.

nicolas cellier said...

Smalltalk MT ?

Andrés said...

Thomas,

> One could refer you to older versions of one of your employer's products.

Which one are you referring to, specifically?

Andres.

Andrés said...

Gaboto,

> What about Gemstone?

That I am aware of, their Smalltalk VMs are single threaded as far as execution of Smalltalk bytecode goes. I do know that e.g.: the Stone has multiple threads in it, but I don't think those execute bytecodes concurrently.

Andres.

Andrés said...

Gaboto,

Also, the thing about GemStone is that it could easily be seen as the fabric that ties several other images together... I'd say it's a bit harsh to interpret single bytecode threadedness as a deficiency.

Andres.

Andrés said...

Peter,

> They t[h]read where other smalltalk vendors and vm makers fear to go.

They also t[h]read exclusively on Windows, whereas other vendors and vm makers are not similarly constrained. Does that mean the vm makers of Smalltalk MT fear, say, Apple? I don't think so.

Nice try, but no cigar :).

Andres.

PS: as usual, any comments about my employer's priorities should be directed to the appropriate manager.

Peter William Lount said...

Peter: They t[h]read where other smalltalk vendors and vm makers fear to go.

Andreas: They also t[h]read exclusively on Windows, whereas other vendors and vm makers are not similarly constrained. Does that mean the vm makers of Smalltalk MT fear, say, Apple? I don't think so.

Well, platform deployment scenarios is really entirely orthogonal to whether or not they do native threads. Should they wish they could deploy to other platforms. So your point is nullified.

Yes, native threads are not easy. Yes, the smalltalk vendors and vm makers have feared to native t[h]read.

In developing ZokuTalk I have no such fears. Native threads are crucial.

There are other smalltalk's that use multi-threading as in native threads to some degree. For example, visual age smalltalk uses a thread for garbage collection and also can do asynchronous i/o calls to the operating system. This does speed up operations and helps to prevent blocking of green threads not doing the i/o.

Smalltalk/X might also have some native threading capability. I've not looked and can't remember; it's been a while since I used it.

The Dolphin guys reportedly have merged with a private smalltalk company that never published their vm and they are reportedly working on native threads.

Native Threads are Coming to Smalltalk whether or not the vendors such as Cincom or Instantiations embrace it or not.

Those that don't may find themselves left in the dust.

12 Core Processors are shipping from AMD today! More are on the way. Tirela already has 48, 64 and 128 cores with plans for 1024 per chip! Intel has demonstrated 80 core experimental chips. Larrabee, delayed but not out of the game, will be a game changer and will have 24+ cores on minimal chips with plenty on the higher end units.

The challenge is solving the safe multi-threading problems - native and green - in an safe and easy way for users. ZokuTalk has such a parallel breakthrough solution in development now.

By the way, hydra style solutions while easy are not a general solution.

Andrés said...

Peter,

From your comments I get the idea that you have some point you want to prove about certain vendors, i.e.:

> Native Threads are Coming to Smalltalk whether or not the vendors such as Cincom or Instantiations embrace it or not. Those that don't may find themselves left in the dust.

That is wonderful, but again, I will not discuss things decided by my managers in this forum. But, if you want, we can talk about technical matters.

> Well, platform deployment scenarios is really entirely orthogonal to whether or not they do native threads.

With the small detail, of course, that said platforms provide different native thread capabilities. The problem here is that it is not enough to, say, have multithreading on Windows (or Macintosh) alone. It should behave the same on all platforms. Without researching these matters, this cannot be done, and the point I was trying to get at is that doing the necessary cross platform homework takes a lot of engineering time.

> In developing ZokuTalk I have no such fears. Native threads are crucial.

Google didn't seem to know about ZokuTalk. White papers, please.

Fears or not, this is not a small problem. It doesn't even stop in the VM. As soon as the image has multithreading, then it can no longer rely on assumptions such as "higher priority processes always preempt lower priority processes"...

> There are other smalltalk's that use multi-threading as in native threads to some degree.

The difficult part is to have several object engine threads running bytecodes at the same time in the same image space. But is that the desirable choice?

> 12 Core Processors are shipping from AMD today! More are on the way. Tirela already has 48, 64 and 128 cores with plans for 1024 per chip! Intel has demonstrated 80 core experimental chips. Larrabee, delayed but not out of the game, will be a game changer and will have 24+ cores on minimal chips with plenty on the higher end units.

Yeah, sure, never mind that the approach is one of diminishing returns. It is not clear at all that 1024 cores will outperform an 8 core CPU by a factor of 128 on memory intensive applications. I don't think we will see memory sizes multiplied by 128 either (that would yield 1GB cache). Smalltalk is (comparatively speaking) memory intensive. Certainly a mark/sweep GC will be painful. What about that?

Andres.

Peter William Lount said...

Andreas,

Not much to prove really other than the utility that real native threads are useful in smalltalk. Smalltalk/MT proved that point over a decade ago.

I'm not asking you what your managers have chosen or not chosen to do. I was referring to their earlier comments. If they go for a general solution all the better for the smalltalk industry.

The details of native threads on different platforms isn't really relevant as those are details that can be hidden from the users of smalltalk. Many languages offer cross platform portability of their native threads, often mapped to the os native threads. The result is still actual multi-core native threads rather than one core bound green threads.

ZokuTalk is in development and information will be released as it's ready for market. Relevant papers will be published in due course.

I agree it's not a small problem, parallel programming. It's more of making a commitment to make it happen and not give in to those that say it can't be done or those that say the only way to do it is to compromise on safety and easy of use.

It's those that think different that push the human race forward.

Many in the Smalltalk community have been unwilling to make the commitment to do the hard work to get it done. Just an observation from conversations on this topic.

Yes some assumptions change, even some important assumptions change with parallel.

The desirable choice depends upon what the application needs are. In the general case, yes it is desirable.

[continued...]

Peter William Lount said...

[... continued]

Diminishing returns. That's depends upon your point of view and what your application use cases and deployment scenarios are on M-core multi-core chips. It all depends.

Memory bandwidth is a limiting factor for all multi-core native threaded applications whether they use a garbage collector or not. Certainly applications that generate larger volumes of transient objects will likely generate a lot of garbage to be collected putting an extra load on the memory systems. That is true of any language now.

It's also the case that the more data that an application in any language processes the more hits to main memory it will have causing up to about two orders of magnitude difference in data access times. That's actually one reason why many c++ programs are not all that much faster than Smalltalk programs. Filling the data cache and persistently spilling from it is expensive. Programs that do a lot of work with what is in the data cache run much faster, generally that is.

I've always thought that one of the most important components on motherboards isn't the cpu so much as the memory data transport systems. Tirela's design is interesting since it implements a network inside the chip rather than using more traditional approaches. Intel does that too with their experimental 80 core design. The more traditional design is one factor that delayed the first Larrabee design as it just couldn't keep up the bandwidth on the bus, well at least that is what one article said about it. However, the main processors are X86-64 bit beasties and ARM-32 bit systems.

If your application fragments easily into isolated chunks and you don't mind the costs/penalties of the hydra or multiple independent virtual machines then by all means go that route but that solution shouldn't be forced upon users as their only choice. General solutions are needed by many serious applications.

Do it however you want. I'm just saying, I prefer more powerful solutions than limited ones when possible. Of course the incremental path is also a viable route for many clients. The major vendors have many clients with real world systems to move forward successfully onto new versions. Change that breaks end user applications won't be appreciated. It's the old Microsoft problem of moving forward while remaining compatible.

ZokuTalk is more nimble. There is more than one way to skin a cat, so to speak. Now where is Anomaly, my neighbors black cat.

Peter William Lount, Thinking Different Implementing Real Code.
http://smalltalk.org
http://zoku.com

Andrés said...

Peter,

> The details of native threads on different platforms isn't really relevant as those are details that can be hidden from the users of smalltalk.

Sure, many things can be hidden from Smalltalk users. Is that a good idea? And how do you do that for e.g.: VisualWorks' >10 supported platforms? It is not clear that these diverse platforms will necessarily help VM implementers by adopting a single threading model, a standard threading API, etc.

> Many in the Smalltalk community have been unwilling to make the commitment to do the hard work to get it done.

Having the will to do something is great. So, exactly what is the something that should be done? Where is the relevant research that supports that point of view? These (and some of the subsequent) wishy-washy statements do not contribute much, you know? I probably won't travel at the speed of light just because I wish to do so.

Moreover, I should point out that VM engineers are a tiny fraction of the Smalltalk community. This gross load misbalancing is not sustainable given the current expectations. Maybe all this detail hiding is a double edge sword.

> [general assertions followed by] However, the main processors are X86-64 bit beasties and ARM-32 bit systems.

Right, so how do we deal with these CPUs today? You provide little to no concrete insight, while claiming you have the solution while mostly everybody else is paralyzed in fear. That's some extraordinary claim. Where's the extraordinary evidence?

Andres.

Peter William Lount said...

"Having the will to do something is great. So, exactly what is the something that should be done? Where is the relevant research that supports that point of view? These (and some of the subsequent) wishy-washy statements do not contribute much, you know? I probably won't travel at the speed of light just because I wish to do so." - Andrés.

Sigh. The statements I made are very precise. To characterize them as wishy-washy isn't fair considering that you won't talk specific proprietary details either.


"Moreover, I should point out that VM engineers are a tiny fraction of the Smalltalk community. This gross load misbalancing is not sustainable given the current expectations. Maybe all this detail hiding is a double edge sword." - Andrés.

That is a valid point. However, just because you don't know how to do a thing doesn't mean that it can't be done. Generally commitment comes first with innovation following. However that said many business people are highly conservative and don't want to take risks when the status quo looks ok or even good.


"[general assertions followed by] However, the main processors are X86-64 bit beasties and ARM-32 bit systems." - Peter

"Right, so how do we deal with these CPUs today? You provide little to no concrete insight, while claiming you have the solution while mostly everybody else is paralyzed in fear. That's some extraordinary claim. Where's the extraordinary evidence?" - Andrés.

There are many approaches to dealing with today's cpu designs. I have provided as much concrete insight as you have considering that both of us can't speak freely on the topic.

You're altering my words. I didn't say that everybody else is paralyzed in fear. There is much progress going on. What I said is that those in the smalltalk community that I have spoken with or whose comments I've read or interacted with generally don't support the general solution (a few have). The non-generalists typically have gone for ideals that won't work as general solutions (e.g. hydravm). Committing to something already knowing how is only one way to go about solving problems. I'd dare say that many of the biggest challenges have been solved without knowing ahead of time how to solve it. Everything in the general zokutalk safe parallel solution can be done today on today's hardware. I've been working on it for a while and it's not easy for sure but it is all so very real. While your applying the Carl Sagan Principle might seem like it's fair it's not because, correct me if I'm wrong, you are not disclosing proprietary solutions either now are you?

"as usual, any comments about my employer's priorities should be directed to the appropriate manager." - Andrés.

I want to push people forward (http://www.youtube.com/watch?v=USn5t5nQWU8) encouraging innovation. There are real viable solutions out there. More than one in fact. Find them or not, they exist.

Peter William Lount

Peter William Lount said...

Just in case you didn't like my comment above let's get real about evidence.

"Not much to prove really other than the utility that real native threads are useful in smalltalk. Smalltalk/MT proved that point over a decade ago." - Peter

Thomas said...

@Andres, I was thinking in terms of ObjectStudio prior to the 8.x series, where the VM actually spawned native Windows threads.

Andrés said...

Thomas, I do not think ObjectStudio 7.x executed more than one Smalltalk process at a time... I do remember it creating processes for the image.

Andrés said...

Peter,

> The statements I made are very precise. To characterize them as wishy-washy isn't fair considering that you won't talk specific proprietary details either.

Hmmm? Which proprietary details are you referring to?

> However, just because you don't know how to do a thing doesn't mean that it can't be done.

Generally I agree with this, with the understanding that several other factors control whether things are done or not. Clearly, a multithreaded (meaning: more than one Smalltalk process running at the same time) Smalltalk is possible.

> However that said many business people are highly conservative and don't want to take risks when the status quo looks ok or even good.

I can't quite comment on this.

> What I said is that those in the smalltalk community that I have spoken with or whose comments I've read or interacted with generally don't support the general solution (a few have).

So, what were their technical objections?

> you are not disclosing proprietary solutions either now are you?

No, but it's common knowledge that things like PICs did not originate in the VisualWorks VM, and there are plenty of papers about them that anybody can read.

> I want to push people forward encouraging innovation.

Yes. I think we need more people thinking about the hard problems of the day.

Andres.

Peter William Lount said...

"Hmmm? Which proprietary details are you referring to?" - Andrés

The ones you are asking me to reveal to you, an employee of a smalltalk vendor.

"Clearly, a multithreaded (meaning: more than one Smalltalk process running at the same time) Smalltalk is possible." - Andrés

Ok, then do that first. End of line. Just do it.

If all Cincom or Instantiations did was that, what Java has had essentially forever, and what Smalltalk/MT has had for over a decade or so then just do that. That is a start. At least Visual Works and Visual Age Smalltalks would have entered the modern multi-core era!

I can comment and opine for I know of what I speak, besides http://www.youtube.com/watch?v=STiuregSvHg. It's time in my humble opinion that the main commercial smalltalk vendors just get it done and stop wimping out about it.

"So, what were their technical objections?" - Andrés

Most people object to native multi-threading because it's hard. Yes it's hard, so what? What they don't realize is that it's not that much different than single green threads messing up your smalltalk program! Have you ever tried to deprogram a major app with 20+ running threads on one native thread? Yikes, yes it's no picnic either but it's doable. Most people let the unknown stop their commitment forward and just never get started or never undertake the hard stuff.

If I can figure out a way of doing safe multi-threaded (native or green) programming with zero budget... then why haven't the main vendors who have a budget been able to get basic native threading done ever since Smalltalk/MT lead the way back in the late 1990's with just regular native threading? It is not for the lack of intelligent people, that they have in spades for sure. It's the lack of a commitment to get it done, a lack of vision by someone(s) - in my humble opinion.

ZokuTalk (tm) will be my first smalltalk execution engine and it will provide safe multi-threaded native and green thread programming (you really need both since there are limits to the number of native threads on most operating systems [~64 on vista] and green threads are lighter weight - as long as any thread can map to a native thread as needed it's all good)... I'm doing it on zero budget quite literally. I'm not only having to learn and implement the new safe parallel paradigm but also all the other icky internal stuff too.

Let's have the smalltalk vendors take the first step and at least match the capabilities of the other languages that provide native threads to programmers. Given that it's possible to get much done using just native threads alone that is a fantastic first step. There is more than one way to skill a cat after all. [No cats nor Anomalies where harmed in the making of this comment].

Just do it: basic native threads in Visual Works, Visual Age, Squeak, Pharo, ...., after all Smalltalk/MT has had it for more than ten years! Can't let the Java's of the world keep their lead now can we?

Peter

Andrés said...

Peter,

> The ones you are asking me to reveal to you, an employee of a smalltalk vendor. [...] do that [meaning a multithreaded Smalltalk] first. End of line. Just do it. If all Cincom or Instantiations did was that, what Java has had essentially forever, and what Smalltalk/MT has had for over a decade or so then just do that. That is a start. At least Visual Works and Visual Age Smalltalks would have entered the modern multi-core era! It's time in my humble opinion that the main commercial smalltalk vendors just get it done and stop wimping out about it. If I can figure out a way of doing safe multi-threaded (native or green) programming with zero budget... then why haven't the main vendors who have a budget been able to get basic native threading done ever since Smalltalk/MT lead the way back in the late 1990's with just regular native threading? It is not for the lack of intelligent people, that they have in spades for sure. It's the lack of a commitment to get it done, a lack of vision by someone(s) - in my humble opinion.

There's little to no technical content in what you wrote, other than claims you cannot substantiate. You choose not give evidence, and then state that I am somehow attempting to take advantage of your proprietary information. It's hard to talk about technical matters like this.

Also, for the nth time, *I WILL NOT DISCUSS MATTERS THAT RELATE DECISIONS THAT BELONG TO MY MANAGERS*. So, I do not care about the allegations of wimping, or lack of vision, or status quo, or whatever else. Please take these assertions somewhere else, this is not the forum for such a discussion.

Andres.

Peter William Lount said...

The smalltalk vendors gotta at least keep up with the Java's of the world! [:)]

http://www.youtube.com/watch?v=STiuregSvHg [;)]

Peter William Lount said...

Whoa dude. No need to freak. Again I am not and have not asked you to reveal anything of confidence. All I ask is the same courtesy in return from you. When you assert that I haven't put in the technical details and then complain about it you're essential asking me to spill out the details of my solution. Yes, I will have to prove it with either working code or papers. that will come in time. However... in the mean time...

Look, all we are asking for is Native Threads! That is real. There is not only tons of papers on that but working systems! It's been done before. It's straightforward by now. Java has it. Smalltalk/MT proved it and is working on improving it as we speak.

Once again I've not asked you to spill any confidence that you're committed to. All I ask is the same courtesy in return.

Andrés said...

Peter,

> Look, all we are asking for is Native Threads! That is real. There is not only tons of papers on that but working systems! It's been done before. It's straightforward by now. Java has it. Smalltalk/MT proved it and is working on improving it as we speak.

I understand the request. However, please note I am not the one that should receive such requests :).

Andres.

Peter William Lount said...

That's fair.

Andrés said...

Peter, in general I don't talk about work in this blog, but I should point out an example of how different things look from this other, "vendor" if you like, point of view.

I spent close to two years mainly focused on 64 bit VisualWorks. There was a lot to fix: compiled methods were broken, floating point arithmetic was broken (tests revealed breakage across all platforms, not just 64 bits), small integers were broken, the IGC was broken in several ways, the class table for 64 bits was also broken, the JIT was broken (and debugging revealed 32 bit breakage as well), PICs were broken, the scavenger was broken, BOSS was broken (so you couldn't use Store), etcetera. My priority for 7.7 was to fix all this mess, and it is done.

Of course that means I couldn't play with multithreaded VMs (in the sense of multiple Smalltalk processes running simultaneously), or other interesting projects that would be just as fun to pursue. So, as you see, it's not as easy as saying "hey I am starting from scratch and I have no customers to support, multithreading is so easy why don't you guys just do it you are wimping out!". It just doesn't work that way.

So now that 64 bit is working reasonably well, customers have indicated they want a Windows 64 bit version. Well, again, it's not a simple matter of "why don't you guys just do it". The CPU is different, fortunately we have the Linux64/x86 code generator but unfortunately the Windows ABI is different. Easier when you have an interpreter, not so easy when you have a JIT. How about auditing all the Windows API calls in the VM and the image? The MSDN docs are not very good to begin with.

Of course all of this work can be done, but it takes a huge amount of time. What sometimes is frustrating to me is that VM work seems to be gauged with a Smalltalk image complexity stick. It is really inappropriate to expect such a rate of development. With the image, you generally do not have the problem of having to understand tons of documents before you can do anything. You just open a browser and start creating your own world with just as much complexity as you want. Contrast that with the fact that the Apple docs used to come in something like a 400mb compressed installer. How large is MSDN? On the Linux side, just the GCC manual (which you can't use in all platforms anyway) is 660+ pages. Where is the time to truly comprehend all this material? This intellectual overload problem is particularly painful when one considers the VM community is, as you mentioned, a tiny sliver of the Smalltalk community.

So. I wouldn't give up on a multithreaded Smalltalk at all. Eventually it will happen. However, given the current state of affairs, it will take time. Something that would really help is to get a new batch of VM engineers, and a renewed interest to tackle the difficult problems that come with any mature technology :).

Andres.

Peter William Lount said...

Andrés,

It sure sounds like you guys spent a lot of time and effort into ensuring an excellent 64 bit version of Cincom Smalltalk. I applaud your work to make it so on the various platforms.

Yes as I indicated in my earlier comment any long term successful vendor (such as Microsoft) has a large legacy base to consider and that will impact the choices that are made for sure.

Squeak also now has this same problem, the code base is too huge and elklectic. At least Pharo is more focused. More distributions means more competition which is likely a good thing. It's like the Linux model with many distrubutions being a good thing.

In many ways it is easier for a new system burning the disk packs.

However, it's been well over a decade that Smalltalk/MT has had native multi-threading. That is the part that irks me. It's not just one vendor that has delayed, it's pretty much all of them.

One of the two main reasons that I began writing a new Smalltalk like system is that the existing ones didn't do multi-threading native (well except for Smalltalk/MT). For other reasons Smalltalk/MT wont' work for the apps I'm working on.

I'm not giving up on an awesome native multi-threaded smalltalk at all, I'm making it happen! Since others won't get it done I choose to shape a system, ZokuTalk, that is what I and my customers need: safe, easy, straight forward and powerful native (and green) multi-threading that works on single or multi-core processors. It will incorporate the safe parallel processing solution that I've come up with (more on that when the software is ready).

My goal isn't a version of smalltalk really, it's the applications that I can build with having ZokuTalk that is motivating me to get the work done. ZokuTalk is a side component.

By the way, in the late 1980's I did work for a company building a Smalltalk Clone. The system was called Audition and was built upon a version of Forth at the heart. The smalltalk was layered on top of this lower level. The target competitor at the time was Digitalk V/286. Unfortunetly that company imploded on the stock market and while it lingered on doing custom contracts it faded away. Also unfortunately the owners turned down my request a few years ago to open source it. I didn't work on the virtual machine for that system as I was working on the GUI and solving hundreds of bugs. It was an awesome project. So while I hadn't written a virtual machine before I started ZokuTalk I have worked professionally within a Smalltalk vendor. Now I do it again.

Good luck with whatever you're doing at Cincom!

Cheers,

Peter

Andrés said...

Peter,

> any long term successful vendor (such as Microsoft) has a large legacy base to consider and that will impact the choices that are made for sure. Squeak also now has this same problem, the code base is too huge and elklectic. At least Pharo is more focused. More distributions means more competition which is likely a good thing. It's like the Linux model with many distrubutions being a good thing. In many ways it is easier for a new system burning the disk packs.

Yes, although sometimes I worry that the net effect may reduce to assuming the problems don't exist for a while, so one feels better, then one solves all the "easy" problems again ((because they had already been solved before, like GUI and all of that), at first there is a lot of progress but after N years it becomes evident the old problems are still there and not much has been done to address them. My concern is that this modus operandi may train most people on how to solve the easy problems.

> However, it's been well over a decade that Smalltalk/MT has had native multi-threading. That is the part that irks me. It's not just one vendor that has delayed, it's pretty much all of them.

Sigh... I have many wishes like this one. Patience, patience and a lot of work. Also, we (the community) should work more to train most people on how to solve or at least think about the hard problems. For example, there's a running half-joking comment stating that if you want to tune GC, you have to call John McIntosh. Why is it that we have this sort of god-like figure that comes down and solves our problems? Why can't we be in control ourselves? Why aren't there 100 John McIntoshes instead of 1?

I also hope that you are successful. Maybe we can chat more at some conference in the future?

Andres.

Peter William Lount said...

"Why aren't there 100 John McIntoshes instead of 1?" - Andrés.

Deep copy in smalltalk isn't really implemented properly. That's the likely reason. All attempts at deep copying John McIntosh have failed. We have tried many times. It wasn't pretty. You remember what happened to that Vulcan that they beamed up in the first Star Trek movie that didn't quite make it though the transporter cycle? Well it was worse than that each time. Sort of like the first seven Ripley clones in Alien IV. We'll just have to perfect deep copy first.

Complex systems need people who can grasp them. It takes time and skill and financial resources. I've been working at figuring out safe parallel for years and the pieces have only recently all fallen into place.

There are lots of parts of Smalltalk that are not standardized. It's a divergence for sure. Yet some components do standardize and become portable across versions.

It really does depend upon what people need in practical projects too.

Last year I needed something done with native threads so I used Smalltalk/MT to get the job done for that contract. This year? Hopefully I'll have ZokuTalk up and running but if not then I'll choose the best of the breed tool for that particular job.

To infinity and beyond! At a conference then!