3 ms·

>There isn't one. Smalltalk implementations, including Cuis/Squeak/Pharo, are image-based… well that is true, except one case when vm doesn’t run on the desire

>There isn't one. Smalltalk implementations, including Cuis/Squeak/Pharo, are image-based… well that is true, except one case when vm doesn’t run on the desired hardware/software combination. So in my case I had quite a story of trying to port vm. (unsuccessfully so far, see details : https://news.ycombinator.com/item?id=38820927 https://news.ycombinator.com/item?id=38820927 ) Any advice about how to move forward with it? How hard it is to extract the bare minimum of the language from the image? All I need is basic set with repl , nothing more. As I understand it should be possible but requires deep knowledge of the image which one does not possess in the beginning. I really wish to play with language and study it and with current limitations it is only possible on a hardware where the vm doesn’t run out of the box.

blihp 3y ago
> well that is true, except one case when vm doesn’t run on the desired hardware/software combination. So in my case I had quite a story of trying to port vm unsuccessfully so far . ( see details : https://news.ycombinator.com/item?id=38820927 https://news.ycombinator.com/item?id=38820927 ) The available pre-built VM's should support most 32-bit and 64-bit x86 and ARM Linux systems. For 32-bit you might have to go back to a slightly older release (I'm not sure if 32-bit has been deprecated yet or not) but you'll still get 99.9% of the experience. I think Windows is fully supported but not sure about OS X since the move to ARM as I've heard some grumbling about issues on that platform. If you're on a non-x86/ARM system, you would have to build from source but won't be able to use the 'fast' VM (i.e. cog/spur) and would have to fall back to the interpreter VM. I managed to get it running on a couple/few ARM-based systems back before there was official support for ARM as a platform and it wasn't too difficult. IIRC, it took a couple/few #define's to shut the compiler up and things mostly worked on Linux. (the remaining issues were long ago fixed due to bug reports and the JIT side of things once ARM became a supported platform) > Any advice about how to move forward with it? How hard it is to extract the bare minimum of the language from the image? All I need is basic set with repl , nothing more. As I understand it should be possible but requires deep knowledge of the image which one does not possess in the beginning. I really wish to play with language and study it and with current limitations it is only possible on a hardware where the vm doesn’t run out of the box. You're not likely to get very far with just a repl on a Squeak-derived (i.e. Cuis/Squeak/Pharo) Smalltalk. GNU Smalltalk is going to work better with that approach but you'll lose most of why people love Smalltalk, IMO. I'd be surprised if based on what I said above you can't get a pre-built image running on a computer you have access to. If that's the case, let me know what you're trying to run it on and I'll see if I can give you a pointer to something that would work.
- lovelyviking 3y ago
  >you would have to build from source but won't be able to use the 'fast' VM (i.e. cog/spur) and would have to fall back to the interpreter VM. Thank you for your answer. This is exactly the path I went through. I decided to go with interpreter and I have built one. During this process I tried to exclude sound support and I think I did but resulting vm was still complaining about some sound library that was missing. As I remember I didn’t figure out how to turn-off-more what is already turned off and postponed solution for better times. >You're not likely to get very far with just a repl on a Squeak-derived (i.e. Cuis/Squeak/Pharo) Smalltalk. GNU Smalltalk is going to work better with that approach but you'll lose most of why people love Smalltalk, IMO. I agree and all my tries were done done with squeak and I didn’t even consider other options so far. Thank you for advice about GNU Smalltalk, may be it worth trying even though I really wanted to use squeak and partly because I really didn’t want to “loose the most of why people love Smalltalk”. My idea was to learn porting it to everywhere I wish it to be like in emulated retro machines and study it in it’s minimal form. Perhaps the proper way of doing it was/is to go through the blue book but I was looking for some shortcut way where I study the very basic sub-system of objects with repl first or even without it depending on the hardware/emulated platform which can be without sound/video/keyboard/mouse capabilities. >I'd be surprised if based on what I said above you can't get a pre-built image running on a computer you have access to. If that's the case, let me know what you're trying to run it on and I'll see if I can give you a pointer to something that would work. This is the case. My idea of ‘getting very far’ with it is to learn to separate the core minimum set of objects that can run on the machine without sound/video capabilities, only with working terminal access and then build/expand/grow the system (copy from main image additional parts if required) and learn on the way while already ‘living’ within the environment of smalltalk in it’s bare minimal basic form. The final destination may very and could be this weird first retro computer that I’ve built when I was a schoolboy(https://news.ycombinator.com/item?id=38762668 https://news.ycombinator.com/item?id=38762668) and not only it, I wish it to become the language of choice for many tasks But as intermediate step it could be let’s say raspberry pi zero w - headless while (importantly!) completely without sound and video drivers. If that would be possible and easier then completely writing it from scratch it would be great. With my current hardware limitations this is the only realistic setup in which I can study it properly .
fizlebit 3y ago
I like the idea of smalltalk, but it suffers from a modularity problem. As I understand it classes just use other classes in the image and it is very difficult to track dependencies. It is a topic revisited often in the Pharo community. Strongtalk and its successor newspeak tried to address that and I think also introduced or experimented with optional static typing. Our modern experience with operating systems has the notion of processes that are relatively isolated from the system, sys calls and wot not. Smalltalk doesn’t have this separation which is a boon and a curse. I’d love to see a smalltalk within a microkernel system like l4 where it retains its all source code is available, debugable, editable, but there is proper process isolation and some sort of security model. Modern systems are so complicated that it would take a vast army, and then maybe half the os stuff has to be written in c++/rust anyway cause gc is too slow for gpu, disks, and networks.
- 7373737373 3y ago
  I figure the lack of security mechanisms in Smalltalk languages is due to them mostly being developed in mutually trusting, non-hostile academic environments It would also be cool if images were really small, like https://netjam.org/spoon/smallest/ https://netjam.org/spoon/smallest/ experiments with!

blihp 3y ago

> well that is true, except one case when vm doesn’t run on the desired hardware/software combination. So in my case I had quite a story of trying to port vm unsuccessfully so far . ( see details : https://news.ycombinator.com/item?id=38820927 https://news.ycombinator.com/item?id=38820927 ) The available pre-built VM's should support most 32-bit and 64-bit x86 and ARM Linux systems. For 32-bit you might have to go back to a slightly older release (I'm not sure if 32-bit has been deprecated yet or not) but you'll still get 99.9% of the experience. I think Windows is fully supported but not sure about OS X since the move to ARM as I've heard some grumbling about issues on that platform. If you're on a non-x86/ARM system, you would have to build from source but won't be able to use the 'fast' VM (i.e. cog/spur) and would have to fall back to the interpreter VM. I managed to get it running on a couple/few ARM-based systems back before there was official support for ARM as a platform and it wasn't too difficult. IIRC, it took a couple/few #define's to shut the compiler up and things mostly worked on Linux. (the remaining issues were long ago fixed due to bug reports and the JIT side of things once ARM became a supported platform) > Any advice about how to move forward with it? How hard it is to extract the bare minimum of the language from the image? All I need is basic set with repl , nothing more. As I understand it should be possible but requires deep knowledge of the image which one does not possess in the beginning. I really wish to play with language and study it and with current limitations it is only possible on a hardware where the vm doesn’t run out of the box. You're not likely to get very far with just a repl on a Squeak-derived (i.e. Cuis/Squeak/Pharo) Smalltalk. GNU Smalltalk is going to work better with that approach but you'll lose most of why people love Smalltalk, IMO. I'd be surprised if based on what I said above you can't get a pre-built image running on a computer you have access to. If that's the case, let me know what you're trying to run it on and I'll see if I can give you a pointer to something that would work.

lovelyviking 3y ago
>you would have to build from source but won't be able to use the 'fast' VM (i.e. cog/spur) and would have to fall back to the interpreter VM. Thank you for your answer. This is exactly the path I went through. I decided to go with interpreter and I have built one. During this process I tried to exclude sound support and I think I did but resulting vm was still complaining about some sound library that was missing. As I remember I didn’t figure out how to turn-off-more what is already turned off and postponed solution for better times. >You're not likely to get very far with just a repl on a Squeak-derived (i.e. Cuis/Squeak/Pharo) Smalltalk. GNU Smalltalk is going to work better with that approach but you'll lose most of why people love Smalltalk, IMO. I agree and all my tries were done done with squeak and I didn’t even consider other options so far. Thank you for advice about GNU Smalltalk, may be it worth trying even though I really wanted to use squeak and partly because I really didn’t want to “loose the most of why people love Smalltalk”. My idea was to learn porting it to everywhere I wish it to be like in emulated retro machines and study it in it’s minimal form. Perhaps the proper way of doing it was/is to go through the blue book but I was looking for some shortcut way where I study the very basic sub-system of objects with repl first or even without it depending on the hardware/emulated platform which can be without sound/video/keyboard/mouse capabilities. >I'd be surprised if based on what I said above you can't get a pre-built image running on a computer you have access to. If that's the case, let me know what you're trying to run it on and I'll see if I can give you a pointer to something that would work. This is the case. My idea of ‘getting very far’ with it is to learn to separate the core minimum set of objects that can run on the machine without sound/video capabilities, only with working terminal access and then build/expand/grow the system (copy from main image additional parts if required) and learn on the way while already ‘living’ within the environment of smalltalk in it’s bare minimal basic form. The final destination may very and could be this weird first retro computer that I’ve built when I was a schoolboy(https://news.ycombinator.com/item?id=38762668 https://news.ycombinator.com/item?id=38762668) and not only it, I wish it to become the language of choice for many tasks But as intermediate step it could be let’s say raspberry pi zero w - headless while (importantly!) completely without sound and video drivers. If that would be possible and easier then completely writing it from scratch it would be great. With my current hardware limitations this is the only realistic setup in which I can study it properly .

fizlebit 3y ago

I like the idea of smalltalk, but it suffers from a modularity problem. As I understand it classes just use other classes in the image and it is very difficult to track dependencies. It is a topic revisited often in the Pharo community. Strongtalk and its successor newspeak tried to address that and I think also introduced or experimented with optional static typing. Our modern experience with operating systems has the notion of processes that are relatively isolated from the system, sys calls and wot not. Smalltalk doesn’t have this separation which is a boon and a curse. I’d love to see a smalltalk within a microkernel system like l4 where it retains its all source code is available, debugable, editable, but there is proper process isolation and some sort of security model. Modern systems are so complicated that it would take a vast army, and then maybe half the os stuff has to be written in c++/rust anyway cause gc is too slow for gpu, disks, and networks.

7373737373 3y ago
I figure the lack of security mechanisms in Smalltalk languages is due to them mostly being developed in mutually trusting, non-hostile academic environments It would also be cool if images were really small, like https://netjam.org/spoon/smallest/ https://netjam.org/spoon/smallest/ experiments with!