Slashdot Mirror
#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.)
Actually, the previous mention was for our competitor's language, S#. Our's is #Smalltalk.
Don Roberts
roberts@refactory.com
The Simplest Consultant That Could Possibly Work
Whoops- at first I thought this was for the #Smalltalk channel over at irc2.parcplace.net. :)
.NET runtime?
.NET for the Axim and using Mono for both my iBook and Zaurus!
.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.
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
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
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
Thanks to the #Smalltalk team for an awesome contribution!
(rev in #squeak on irc.freenode.net and irc2.parcplace.net)
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
1. That's up to the Mono or dotGNU people. We use the Reflection API A LOT and the current implementation on those platforms isn't quite up to snuff.
.sif files and then compile. (Heck...people have been bugging us for years to make the RB more like emacs...they got their wish :) ). You can debug it using the standard CLRDBG program from M$. This gives you single stepping, inspecting, and even code evaluation (as long as you express the code in C#'esque syntax). You can override DNU and it works. I don't think that you can do all the really ugly tricks that ST'ers abuse.
.NET objects, you can still use ST syntax. For example, to use the .NET MessageBox class, in C# you would write System.Windows.Forms.MessageBox.Show("Hello World"); in #Smalltalk you write System.Windows.Forms.MessageBox Show: 'Hello World'.
2. This differs almost none. We love smalltalk tried to recreate the experience as much as possible. It does not currently come with an IDE (that's the next step). We've been using other Smalltalk's to edit the applications that we then export as
3. It differs from S# (same thing as SmallScript since Dave took the name) in the following ways. 1) As true as possible to st80 2) Open Source 3) Free (as in beer)
The beauty of it all is that you can program in real, honest to goodness Smalltalk, and when you decide you need to call other
Thanks and Enjoy
don
I assume it will work on FreeBSD/rotor?
Do you even lift?
These aren't the 'roids you're looking for.
Thanks for the reply!
.NET mobile runtime for WinCE 3 and 4? I suppose it is up to how much is or isn't supported/provided in the WinCE .NET runtime, but it'd be great to have that combo!
.NET runtime.
.NET- I'd love to have access to pretty much every library for Windows, but do it all using Smalltalk, to never have to soil myself with an inferior language. :P Some .NET implementations just seem to be a syntax wrapper around C#, but #Smalltalk sounds more like my thing. :)
1. What about the
2/3. that is really good to hear! It sounds like SmallScript diverges quite a bit from regular Smalltalk in that it adds a bunch of new syntax and looses some other Smalltalk features to work better with the
Your last paragraph is exactly why I'm interested in real Smalltalk running on
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
To be fair...we implement most of the Smalltalk collections by wrapping a smalltalk object around a .NET object. But we aren't a Smalltalk->C# translator, we generate "native" msil :).
don
I know that Objective-C is derived from SmallTalk (or is otherwise closely related). Could these SmallTalk-on-CLR projects be leveraged to bring Objective-C to the CLR?
.NET, but the more cross-platform APIs and languages (especially open ones), the better.
I haven't done much programming in either Cocoa or
-Ster
Naturally #Smalltalk is a wrapper around the .NET object system- and I didn't say to imply that SmallScript or other languages on .NET merely compile/convert to C#. However, I meant that some .NET implementations merely take the syntax of the language in question and one-to-one it with the regular .NET API. In Smalltalk, with a library many of us are quite used to that would suck. For something like a C.NET, that'd be fine. However, I've seen lisp implementations where you have a very-very barebones regular lisp library, and then have to use .NET like so:
:)
:x :y | (x + 2) raisedTo: y ]. In Smalltalk, we'd name that method like MyClass>>#addTwo:thenRaise:. In #Smalltalk would one call a method defined in C# as addTwoThenRaise(int x, int y) like obj addTwoThenRaise: #(10 22) ?
(call some-dotnet-object "myMethod" 1 "hello" 42.3)
without even wrapping it all around a Scheme or CL library. Poor example perhaps, but I am just singing praise all the same.
How does #Smalltalk deal with method names? That is, let's say you have a method called addTwoThenRaise(int x, int y) that would do, in Smalltalk [
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
The first keyword is the original .Net method name. Additional keywords can be anything you want. For example, WebClient in .net has a method named DownloadFile that takes the url and the filename to download to. In C# you would say webclient.DownloadFile("http://slashdot.org","foo. txt"). The equivalent call in #Smalltalk is webclient DownloadFile: 'http://slashdot.org' to: 'foo.txt'. The to: keyword is arbitrary, I could have called it foo: and the call would still work so long as the first keyword was DownloadFile. Contructors are similar 0-arg constructors are invoke by the "new" message (as you would expect). Multiple arg constructors are called by adding more (arbitrary keywords). For example, to create a .NET point: System.Drawing.Point new: 3 y: 5.
hope this helps.
don
Hrmm, definately an interesting way of doing it- with arbitrary keywords. Huh, whodathunk. :) But yes, it helps quite a bit, just what I was wondering. Thanks again!
Working toward a usable PDA environment in the spirit of Newton OS: Dynapad
But what am I saying? This is the exact same trolling comment that gets posted wherever and whenever something, anything .NET gets posted. Probably even the same troll.
My guess is either .NET in his life and doesn't get what it is.
a) It's someone who hates Microsoft so very much that it wouldn't matter if Bill Gates cured Cancer and AIDS tommorow, he'd still be the antichrist
b) It's someone who has never used anything
c) It's someone who has been advocating "non-MS solution X" for years now and is frustrated at the fact that no one's listened yet
d) It's the same "*BSD is Dying" guy
e) CowboyNeal
If you want my explanation on what .NET is, check my URL below.
Schnapple
Am I mistaken in thinking that #Smalltalk is not totally portable to platforms that are not microsoft variants because of the mention on the site that it produces dll's? I use Squeak now and have not been terribly interested in all the mutated # language variants being created to work with microsoft .NET. The mention of .dll and the statement that (paraphrased) "you can use the microsoft dbgclr debugger to debug" make it sound tied to the microsoft platform to me, while Squeak runs on all kinds of platforms and is full featured now. I realize #Smalltalk is a work in progress and therefore comparing current 'features' and class libraries are not only irrelevant but also illogical at this time since it is still being worked on, but I am wondering, could not classes be made for Squeak to at least let it communicate with remote .NET objects/services? If my question above about #Smalltalk being, in some sense, tied to a compatible microsoft underlayment, what would be the advantages compared to Squeak which runs on tons of things? If I am mistaken about #Smalltalk, then I respectfully withdraw the question. I'm just curious, since I've been using Squeak and XML and SOAP etc. to do, hmm, "similar" network/services things that .NET was designed for.
:) may not have even heard of, algol, snobol, PL/I, and as far as I am concerned, the "language wars" are over and were childish when they were going on. Do you see #Smalltalk and Squeak as alternatives, competitors, two sides of the same coin, satisfying different niches, essentially the same and up to personal choice, or what?
Just FYI, I'm a bit of an "oldster", having used punched cards, and languages many youngsters
Also, I saw on the #Smalltalk website, on one of the pages, Compiler perhaps, an example of 1 to: 1000 do: [ ] and mention of how in smalltalk we would get 1000 smalltalk objects, which it was said, were not really needed and so the objects would be done away with and you would just use 32-bit integers instead. I presume this is done transparently and backward compatible such that, for example, if the index spilled over into large integers, ( > 32 bits) things would still behave the way the would in other smalltalks such as Squeak. That is, an internal optimization, but if I wanted the object, I would get an object, and not something else?
Thanks. It looks like you guys put in a lot of hard work on #Smalltalk and I will watch it with interest.
Miguel,
It turns out that your reflection might be beautiful. The actual problem is in the Mono VM. Go to the #Smalltalk download page where we have the details and a dump from the error.
don
P.S. You do good work. It's stupid that your post got modded down
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?