[lovelyviking]

>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 )

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]

> 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 )

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]

>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) 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 .

[blihp]

What are you using to read/post to HN? That would likely be enough to run Cuis on. I've run Cuis on a Pi 2 and that was fast enough to provide a reasonable interactive development environment with a useful amount of memory. Running without a GUI is generally not likely to lead you in an interesting direction. The thing to understand is that the Squeak VM expects to encapsulate 'high level' hardware including a bitmapped display, keyboard, mouse and a sound device. Anything less than that and you're putting yourself more in the role of VM developer instead of Smalltalk developer. (Honestly, if one were starting from scratch today there are more interesting places to start than the Squeak VM as its lack of SMT support is becoming a crippling limitation. This is a design limitation of the language/environment and can only be overcome fundamentally rethinking a couple of core concepts.)

[lovelyviking]

> The thing to understand is that the Squeak VM expects to encapsulate 'high level' hardware including a bitmapped display, keyboard, mouse and a sound device.

I understand this thing I really do and to develop those capabilities I would have to do it outside of Smalltalk with C and other tools in terminal but I really want to do it with and within Smalltalk learning it more as I go and that requires it starting without sound/graphics in the first stage. This is the only choice available for me with my current limitations. I can temporarily run it to compile vm from source on other hardware but I cannot use it for longer work this way. I don’t care really about the role I am putting myself in as long as I can study it more deeply by already using it and I am simply looking for easier way then implementing it from scratch and without Smalltalk because I only can work from terminal. I would agree that there are many interesting places for starting from scratch too and it would be interesting to see if you would point to them too but in my current situation I am really looking for the intermediate step I’ve described. I simply have no other options for progress at the moment due to my limitations. In other moment I would imagine many other options and probably would not be that focused on one of them.

[igouy]

I won't pretend to understand what you wish to do.

fwiw "part of the runtime can be changed at run time"

pdf 2023 "Removing the Barriers between Applications and Virtual Machines"

https://arxiv.org/pdf/2312.16973v1.pdf

----

https://news.ycombinator.com/item?id=38904180

[fizlebit]

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]

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/ experiments with!