#Smalltalk - Open Source Smalltalk for .NET

David Buck writes "John Brant and Don Roberts have released an Open Source Smalltalk compiler and library for .NET called #Smalltalk. This is the first widely available Smalltalk for the .NET platform. #Smalltalk is ANSI compliant and programs written in it compile to DLL's or Windows executables. The compiler is still early in its development, but it looks interesting." (You may recall this earlier mention as well.)

Comments

General #Smalltalk Questions; #Smalltalk and Mono

[RevAaron]

Whoops- at first I thought this was for the #Smalltalk channel over at irc2.parcplace.net. :)

Since it looks like Don is reading this thread, I'll go ahead and ask here-

1. What are the chances we'll see this running on Mono or dotGNU? Or on WinCE using the WinCE .NET runtime?

I'm running OS X myself, with a Dell Axim and a Sharp Zaurus for the development and testing of Dynapad (a PDA OE in Squeak Smalltalk), and I'd love to be able to develop in Smalltalk using .NET for the Axim and using Mono for both my iBook and Zaurus!

2. How much different is this from the regular Smalltalk we all know and love? Does it come with a Smalltalk IDE like we see in Squeak, St-80 or VW, or do you develop #Smalltalk code in VisualStudio? Even though it is compiled to a DLL, can you do all the great runtime tricks Smalltalk is known for?

Can I still develop using the traditional image method and then compile when I want to deploy?

3. How does this differ from #S or SmallScript?

I will be trying this as soon as I can tommorow at work, where my only Windows machine is. I have a lot of hope for .NET, and think that version of Smalltalk for .NET could be a very wonderful thing, as long as it doesn't sacrifice some of Smalltalk's better features to run on the .NET runtime.

Thanks to the #Smalltalk team for an awesome contribution!

(rev in #squeak on irc.freenode.net and irc2.parcplace.net)

my question

[Anonymous Coward]

It looks some of the #smalltalk developers are following the thread, so I'm hoping my question will be answered. This question isn't meant to be a troll, so if you don't agree with it, don't mod it down. My question to the #smalltalk developers is this.

I've been dealing with multi-threading in C# for .NET lately and encountered some serious issues. The situation is this. While looking at the threading API in C#, I discovered that ThreadPool is limited to 25 threads. That in itself isn't necessarily a problem, but I want to build a server component that is persistent and doesn't ever sleep. Part of it's core functionality is managing transaction state in memory. The system has to manage those states, so that multi-request transaction don't have to start at step 1 every single time. Well so I thought, we could store those states in Sql Server, except that from our benchmarks, ADO.NET starts to reach a performance limit around 40 concurrent queries. This is due to the fact the each atomic process has to complete within 400ms averaged over several thousand processes. Each process may consist of 2-3 dozen requests.

Obviously there are serious issues with synchronization, thread scheduling, blocking, asynchronis calls, call backs and interaction with messaging systems like MSMQ for this type of application. In your work with #smalltalk, how have you address these thread issues? did you end up writing your own threading scheduler, and strong monitoring using semiphores? Or did you decide to stay within .NET's pre-emptive threading model? Another option is to use system level scheduler (ie unsafe code) to schedule the thread, monitoring and synch? Some other possible approaches is to use SQL server in a database driven manner, but again the limitation with ADO.NET rules that out because of the high number of concurrent processes. What are your impressions of .NET threading, it's pros/cons for high performance applications where stateful application and high availability are in the requirements?