Cuis-Smalltalk | Hacker News Reader

Cuis-Smalltalk

cuis.st

104 pointshaolez27 comments

I've tried to play with Smalltalk on my vacation and I've had some troubles with Squeak and Pharo.

Surprisingly, everything worked out of the box with Cuis and its vector graphics rendering makes the experience much more pleasant. I'm impressed!

For the record, on my Linux box, Squeak would have troubles with my keyboard input (I can't type a caret!) and Pharo had DPI scaling issues where everything becomes blurry, as well as some crashes here and there.

did you have to compile it for your box or you used a ready image? My experience with squeak was similar:(see below) https://news.ycombinator.com/item?id=38820927

I've used a ready image. And Cuis seems derived from Squeak, so supposedly the build process is the same and it might not be trivial. I haven't tried to build any of them yet.

The developers have written a terrific open source book that walks the reader through creating a Spacewar! game in Cuis Smalltalk (just updated yesterday):

https://github.com/Cuis-Smalltalk/TheCuisBook

Features: https://cuis.st/features

Giving it a whirl in your web browser: https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis...

Is there a 32 bit version? how hard to adapt/compile one without previous experience ? I tried to do it with squeak and I realised that I should go in depth of cmake and c for configuration of generated vm and it’s kind of ruins the purpose because this is exactly what I’ve been trying to avoid (by all means) in the first place. I went through all of the trouble of generating vm just to face reality in which instead of smalltalk I had to deal with depths of c in all of it’s beautiful cmake complications because vm has failed to compile and even when it did it didn’t work on the target hardware because of some problem with sound. I didn’t need sound at all but I found it too time consuming to turn sound module if I recall it correctly. I was looking for absolutely minimalistic system like bare minimum to study it and I found it hard to achieve. I am curious how cuis different or the same in that regard? Where to get help in compiling one for a new hardware? Any insights/advices about this?

The web version uses squeakjs and a 32bit image. There's also:

https://github.com/nmingotti/The-Cuis-CookBook/wiki/Run-Cuis...

And:

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/ma...

Which points to 64 and 32 bit VMs:

https://github.com/OpenSmalltalk/opensmalltalk-vm/releases

The cuis smalltalk images are in the repo, eg:

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/ma...

This (and squeak, Pharo) seem to run fantastic in squeakjs on an Android phone. But the resolution/zoom level is unusable - and three button mouse is tricky on touch.

Any efforts to make a) usable dev images to run on iphone/android via squeakjs, and b) tooling to develop single purpose apps that could run on phones, tablets and desktop via squeakjs/the browser?

What's the story for creating and distributing standalone executables?

There isn't one. Smalltalk implementations, including Cuis/Squeak/Pharo, are image-based. So applications in their world get packaged more like a word processor/spreadsheet document than a traditional executable from other languages/environments. You distribute the .image file (and usually a .changes file as well... but that is more or less optional via changes you can make to the .image) which is loaded and run by the VM, which is the actual executable.

The license allows you to distribute your applications either as standalone .image files or bundled along with copies (modified or not) of the VM, but they are still discrete files.

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

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

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

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

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

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

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.

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!

Thats not that different from Java, C# and loads of other compiled languages. Sure images there are called "dll" og "Class" files, but in practice you have to ship a runtime to run them (C# can compile to standalone native code, but I don't think that is normally done).

When you don't publish single-file binary (JIT self-contained or otherwise or AOT), each assembly is compiled to a separate .dll file. .NET assemblies closest abstraction in other languages is probably modules and compilation units (sans limitations of those) - they can contain many types and their members.

> There isn't one.

https://github.com/pharo-open-documentation/pharo-wiki/blob/...

https://despotadesdibujau.github.io/southsmalltalks/how-to-d...

https://book.huihoo.com/smalltalk/pharo/enterprise-pharo/boo...

Also, not generally available unfortunately:

https://richardeng.medium.com/mobile-smalltalk-c6f0cc712909

Both cinecom and vast should allow deployment/distribution:

https://www.cincomsmalltalk.com/

https://www.instantiations.com/vast-platform/

It really is unfortunate that there isn't a straight-forward way to compile to a stand-alone executable which would "just work" --- as perfect as it would be for a project I have in mind (Erudite affords Literate Programming, and I need vector graphics, and the DrGeo tool looks to have a lot of code I could crib from), but I just can't see telling folks to download an entire development environment to use it.

Objective-C takes a lot from Self and compiles to the Mac, iOS and Linux. Because it is built on top of C it should be even more portable than that.

Since there are a few Smalltalk experts around, let me ask: what's the deal with Monticello? Is it legacy cruft and we should just migrate to Git, or is there something more to it?

Monticello lets you export/import code between your image and text files which can then be managed by a vcs like git. Created by Avi Bryant.

"Cuis-Smalltalk uses GitHub to host, version, diff its core development and to manage a set of external packages (i.e. code that is maintained independently and outside Cuis-Smalltalk but closely related to it).

Package files are simple text files, encoded for latin alphabet (ISO 8859-15) and handled without problems by GitHub. Cuis-Smalltalk uses the LF (ascii code 10) newline convention, as preferred in GitHub. This allows Git/GitHub to diff versions, and merge branches."

9.5 Daily Workflow

https://cuis-smalltalk.github.io/TheCuisBook/Daily-Workflow....

If there was a talk that explained and visualized the runtime state/how Smalltalk processes things (like this one for Javascript: "What the heck is the event loop anyway?" https://youtube.com/watch?v=8aGhZQkoFbQ), that would greatly help in understanding and coming to terms with it

Reply on news.ycombinator.com