Bert,
In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Bill
Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
Em 03-10-2010 12:50, Schwab,Wilhelm K escreveu:
Bert,
In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Besides the need to port plugins, there's no literature easily available for developing plugins. So, in many instances when people is not able to write plugins or don't have time to do so, FFI comes just in hand.
Msier Cassou wrote some nice books on squeak/pharo... could enhance adding a chapter on how to develop plugins (perhaps with help of VM people).
CdAB
Bill
Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
On 10/3/2010 8:50 AM, Schwab,Wilhelm K wrote:
In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
Which in return assumes you have a functioning FFI to begin with. I've pointed this out before and will do it again: One of the great portability advantages of the Squeak VM is that it can be ported *without* requiring a functioning FFI. All you need is a C compiler. There have been many ports where an FFI was never implemented (Zaurus, PS/2, Android) and likely never will be. The ability to port portions of domain code (sockets, files, graphics) without being stopped by having to implement an FFI *first* is what gets people going quickly.
Cheers, - Andreas
Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Bill
Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
On 4 October 2010 20:41, Andreas Raab andreas.raab@gmx.de wrote:
On 10/3/2010 8:50 AM, Schwab,Wilhelm K wrote:
In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
Which in return assumes you have a functioning FFI to begin with. I've pointed this out before and will do it again: One of the great portability advantages of the Squeak VM is that it can be ported *without* requiring a functioning FFI. All you need is a C compiler. There have been many ports where an FFI was never implemented (Zaurus, PS/2, Android) and likely never will be. The ability to port portions of domain code (sockets, files, graphics) without being stopped by having to implement an FFI *first* is what gets people going quickly.
In contrary, i think a first thing which should be ported is an FFI. Then other developers, who already know how to use FFI could write bindings to platform-specific libraries, and can experiment fail & succeed without depending on always-busy-and-always-behind-the-deadlines VM maintainer. FFI enabling more agile development. And allows a wider audience to take part in development, instead of few people, who knows how to build VM and write plugins for it. Moving code from FFI to VM plugin is much easier then, since you already having things which work, and all you should do is to replace FFI with primitives, while layer(s) on top of that will remain mostly unchanged.
Cheers, - Andreas
Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Bill
Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
On 10/4/2010 11:16 AM, Igor Stasenko wrote:
On 4 October 2010 20:41, Andreas Raabandreas.raab@gmx.de wrote:
On 10/3/2010 8:50 AM, Schwab,Wilhelm K wrote:
In saying that "port the vm and everything just works" you appear to be ignoring that the plugins have to be ported too. Whether one tweaks and debugs(!!) Smalltalk or C, there will be things to port and fix. I for one would much rather work out the details of a stubborn platform dependency in readily changed and debugged Smalltalk than C hidden away in the vm.
Which in return assumes you have a functioning FFI to begin with. I've pointed this out before and will do it again: One of the great portability advantages of the Squeak VM is that it can be ported *without* requiring a functioning FFI. All you need is a C compiler. There have been many ports where an FFI was never implemented (Zaurus, PS/2, Android) and likely never will be. The ability to port portions of domain code (sockets, files, graphics) without being stopped by having to implement an FFI *first* is what gets people going quickly.
In contrary, i think a first thing which should be ported is an FFI.
I'm not talking about what "should be ported" - I am talking about the ports that actually *did* happen. This is practice, not theory. The Android port would not exist if it had required an FFI port to begin with (it still does not have an FFI). The Zaurus port would have never happened (no concept of shared libraries), the PS/2 port neither.
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
Cheers, - Andreas
Then other developers, who already know how to use FFI could write bindings to platform-specific libraries, and can experiment fail& succeed without depending on always-busy-and-always-behind-the-deadlines VM maintainer. FFI enabling more agile development. And allows a wider audience to take part in development, instead of few people, who knows how to build VM and write plugins for it. Moving code from FFI to VM plugin is much easier then, since you already having things which work, and all you should do is to replace FFI with primitives, while layer(s) on top of that will remain mostly unchanged.
Cheers,
- Andreas
Where I get worried is with an apparent general desire to do everything in Smalltalk when a shared library might be/is the answer.
Bill
Bert Freudenberg bert at freudenbergs.de Fri Oct 1 14:31:52 UTC 2010 We are not talking about optional add-ons. For that, yes, FFI is the quick-and-dirty solution, go ahead and have fun wrapping every library on the planet.
What I am objecting to is the zealous quest to move core functionality out of proper plugins to the image, be it using FFI or Alien or any other generic callout mechanism.
Being able to take an image and run it anywhere without having to worry about the platform is a Good Thing. Once John ported the Squeak VM to iOS, Etoys *just worked*. That's the power our VM abstraction gives us.
Also, the whole Squeak sandbox security model depends on the VM being able to prevent code in the image to do damage. There is no way to do that if you let the image use FFI. Do you want my Etoys project to wipe out your hard disk? I didn't think so.
There is another benefit to plugins that encapsulate platform capabilities: Once the interface has been written, you only need to know C, not so much Smalltalk, to port it to another platform. If the primitive interface has been well-designed this is much easier than doing it in Smalltalk. Plus, it is much simpler to get help from platform experts if they can see the C code.
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Colin
On 10/4/2010 1:04 PM, Colin Putney wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raabandreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I'm sure Eliot will write a long reply, so I'll send the short version: Very useful. Not for porting but for developing and debugging.
Cheers, - Andreas
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Colin
On Mon, Oct 04, 2010 at 01:04:42PM -0700, Colin Putney wrote:
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work?
Yes
Do you write and debug using the simulator?
Yes
Is it worth the high barriers to entry for the uninitiated?
Yes
- Dave
Hi Colin,
Colin Putney wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I almost never use the simulator. I've only used it to fix 2 rounds of BitBlt bugs some time ago.
However, I do plugins for numerical stuff, image processing, graphics and audio processing all the time. Being able to experiment, code and debug in Smalltalk, and later have C speed almost for free is absolutely wonderful. For these kinds of problems, Slang is way more productive than C or ASM. And the "barrier for the uninitiated" is much lower than for working on the VM itself.
I say "almost for free" because in these kinds of problems it is quite natural to code in a rather "low level" Smalltalk, that is almost Slang.
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Colin
As I said above, Slang is not only useful for building the VM (I let the VM experts talk about this application of Slang). It is also wonderful for writing plugins.
Cheers, Juan Vuletich
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a
C
compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil].
Seriously, if anyone knows why these two are disabled *please* let me know.
Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack.
HTH Eliot
Colin
If you could make Slang suck less, what would you change?
On Oct 4, 2010, at 8:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil].
Seriously, if anyone knows why these two are disabled *please* let me know.
Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack.
HTH Eliot
Colin
Hi Casey,
On Tue, Oct 5, 2010 at 9:04 AM, Casey Ransberger casey.obrien.r@gmail.comwrote:
If you could make Slang suck less, what would you change?
Four ideas:
1. a ground-up rewrite to clean up the code, and remove all the hacks, using method tags for metadata and eliminating class side things like mustBeGlobal:. The inlining code is particularly difficult to understand and modify. Inlining doesn't unify variables elegantly, introducing way too many copies. Lots of this could be cleaned up. Some type analysis (see below) would help.
2. generate code from an initialized instance (of Interpreter, StackInterpreter, CoInterpreter etc) which I expect will significantly simplify things like declareCVarsIn:, and would provide type analysis with a lot to go on.
3. replace the default object type sqInt with both an immediate type for SmallInteger (& eventually Character & SmallFloat) and a proper oop struct type that accesses header fields via message sends to the oop, not via bit masks applied by the Interpreter (see e.g. CogMethod CogBlockMethod and their simulators CogBlockMethodSurrogate32 et al).
4. start migrating to C compilers that have support for closures so the VM can be rewritten using Smalltalk control structures.
best, Eliot
On Oct 4, 2010, at 8:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney < colin@wiresong.com colin@wiresong.com> wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab < andreas.raab@gmx.de andreas.raab@gmx.de> wrote:
In practice, there is a *huge* advantage for porting if all you need is
a C
compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil].
Seriously, if anyone knows why these two are disabled *please* let me know.
Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack.
HTH Eliot
Colin
Eliot
Do you think that this is something that could be supported by ESUG? Because improving the infrastructure is important.
Stef
Hi Casey,
On Tue, Oct 5, 2010 at 9:04 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
If you could make Slang suck less, what would you change?
Four ideas:
a ground-up rewrite to clean up the code, and remove all the hacks, using method tags for metadata and eliminating class side things like mustBeGlobal:. The inlining code is particularly difficult to understand and modify. Inlining doesn't unify variables elegantly, introducing way too many copies. Lots of this could be cleaned up. Some type analysis (see below) would help.
generate code from an initialized instance (of Interpreter, StackInterpreter, CoInterpreter etc) which I expect will significantly simplify things like declareCVarsIn:, and would provide type analysis with a lot to go on.
replace the default object type sqInt with both an immediate type for SmallInteger (& eventually Character & SmallFloat) and a proper oop struct type that accesses header fields via message sends to the oop, not via bit masks applied by the Interpreter (see e.g. CogMethod CogBlockMethod and their simulators CogBlockMethodSurrogate32 et al).
start migrating to C compilers that have support for closures so the VM can be rewritten using Smalltalk control structures.
best, Eliot
On Oct 4, 2010, at 8:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil].
Seriously, if anyone knows why these two are disabled *please* let me know.
Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack.
HTH Eliot
Colin
Ooh, I'm liking 4! I didn't know there were C compilers with built-in support for closures. I'm going to have to google on that.
On Oct 5, 2010, at 10:43 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Casey,
On Tue, Oct 5, 2010 at 9:04 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
If you could make Slang suck less, what would you change?
Four ideas:
a ground-up rewrite to clean up the code, and remove all the hacks, using method tags for metadata and eliminating class side things like mustBeGlobal:. The inlining code is particularly difficult to understand and modify. Inlining doesn't unify variables elegantly, introducing way too many copies. Lots of this could be cleaned up. Some type analysis (see below) would help.
generate code from an initialized instance (of Interpreter, StackInterpreter, CoInterpreter etc) which I expect will significantly simplify things like declareCVarsIn:, and would provide type analysis with a lot to go on.
replace the default object type sqInt with both an immediate type for SmallInteger (& eventually Character & SmallFloat) and a proper oop struct type that accesses header fields via message sends to the oop, not via bit masks applied by the Interpreter (see e.g. CogMethod CogBlockMethod and their simulators CogBlockMethodSurrogate32 et al).
start migrating to C compilers that have support for closures so the VM can be rewritten using Smalltalk control structures.
best, Eliot
On Oct 4, 2010, at 8:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. ::
loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil].
Seriously, if anyone knows why these two are disabled *please* let me know.
Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack.
HTH Eliot
Colin
Casey,
there's Apple's GCD extensions to the gcc family. http://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/Block...
Best,
Michael
On 5 October 2010 21:45, Casey Ransberger casey.obrien.r@gmail.com wrote:
Ooh, I'm liking 4! I didn't know there were C compilers with built-in support for closures. I'm going to have to google on that.
On Oct 5, 2010, at 10:43 AM, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Casey,
On Tue, Oct 5, 2010 at 9:04 AM, Casey Ransberger casey.obrien.r@gmail.com wrote:
If you could make Slang suck less, what would you change?
Four ideas:
- a ground-up rewrite to clean up the code, and remove all the hacks, using method tags for metadata and eliminating class side things like mustBeGlobal:. The inlining code is particularly difficult to understand and modify. Inlining doesn't unify variables elegantly, introducing way too many copies. Lots of this could be cleaned up. Some type analysis (see below) would help.
- generate code from an initialized instance (of Interpreter, StackInterpreter, CoInterpreter etc) which I expect will significantly simplify things like declareCVarsIn:, and would provide type analysis with a lot to go on.
- replace the default object type sqInt with both an immediate type for SmallInteger (& eventually Character & SmallFloat) and a proper oop struct type that accesses header fields via message sends to the oop, not via bit masks applied by the Interpreter (see e.g. CogMethod CogBlockMethod and their simulators CogBlockMethodSurrogate32 et al).
- start migrating to C compilers that have support for closures so the VM can be rewritten using Smalltalk control structures.
best, Eliot
On Oct 4, 2010, at 8:47 PM, Eliot Miranda eliot.miranda@gmail.com wrote:
On Mon, Oct 4, 2010 at 1:04 PM, Colin Putney colin@wiresong.com wrote:
On Mon, Oct 4, 2010 at 11:56 AM, Andreas Raab andreas.raab@gmx.de wrote:
In practice, there is a *huge* advantage for porting if all you need is a C compiler and a bit of knowledge about the underlying OS support.
This brings up a question that I've been wondering about for a while. How useful is Slang these days?
I can totally see how it would have been faster to get the new VM up and running in Apple Smalltalk in the first place, but I'm wondering if these days it's more trouble than it's worth. Most dynamic languages (eg, Ruby, Python, Perl, Javascript) are implemented in straight, idiomatic C and benefit a lot from the fact that many, many people already have the skills needed to work with the language and toolchain.
In contrast, the Squeak VM is written in a language that almost nobody knows, using tools that almost nobody understands. Outside of the current maintainers it's a very short list, and many of the people on it aren't active in the community anymore. "Implemented in its self" is kind of neat, but as a practical matter, Slang is not Smalltalk, and a developer skilled in both C and Smalltalk still has a lot to learn before he can contribute to the VM.
So here's a question to the folks that are actively hacking on the VM: is Slang still beneficial in your day-to-day work? Do you write and debug using the simulator? Is it worth the high barriers to entry for the uninitiated?
Slang sucks. Developing in Smalltalk is great. I like using Slang to being continually hit over the head by an ungiving guru; plenty of pain but no enlightenment. The problem is you write Smalltalk that works, push it out and when it doesn't work due to some internal Slang issue you're in a lot of pain. Do you try and fix Slang, do you mangle your Smalltalk to function within its limitations (and forget to comment why, e.g. :: loadNewPlugin: pluginString | plugin plugins simulatorClasses | transcript cr; show: 'Looking for module ', pluginString. "but *why*??" (#('FloatArrayPlugin' 'Matrix2x3Plugin') includes: pluginString) ifTrue: [transcript show: ' ... defeated'. ^nil]. Seriously, if anyone knows why these two are disabled *please* let me know. Yes I write and debug using the simulator. Yes it is worth the high barriers. But Slang is still a massive, fragile hack. HTH Eliot
Colin
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
Casey Ransberger -
Casimiro de Almeida Barreto -
Colin Putney -
David T. Lewis -
Eliot Miranda -
Igor Stasenko -
Juan Vuletich -
Michael Haupt -
Schwab,Wilhelm K -
stephane ducasse