Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit. But how to change such legacy beast, the pharo image ? Potential is huge but resistance is also tough for so few people⦠Just imagining changing method protocols seems so complex at the end ! Instead, Iâd start with minimal images, bootstrapped ones. A system I would love to understand every bits. Iâm pretty sure this is what lots of us have in mind and the progress in bootstrap has been teasing us ;-) <dreamMode> For instance, Iâd want minimal images that would be able to deal with collections of informations (text/data processing) with (web)socket connectivity or whatever cheapest way to communicate. It would be some kind of information store, a minimal image that can store information objects and that I can interact with a client in a full pharo image (or in a web browser). Wouldnât it be possible to start from scratch, literally from nothing (nil) and define little by little what necessary and along the way define minimal protocols, minimal Object class and then iteratively a clean collection hierarchy until ⦠(for me) ⦠the information store. That would probably need some filesystem support but itâs not an obligation. Iâd far prefer web socket stream support and interaction with object only within the image. Another image could be responsible of exporting information objects to files⦠It also need some basic mime types support and probably parsing (xml/html, json, geojson, ical, â¦). I donât know well. But it has to be iteratively done anyway. I imagine there are not one but several images (and therefore source code) that would lead to functionally equivalent images. There should be some ways to abstract functionalities we expect of a system (if people have pointers on that) ? We could even imagine like a Contest to come up with the nicest pharo images (contest driven by tests ^^). Depending on the functionality coverage, thatâd be just crazy to see similarities between code/images⦠</dreamMode> Is it feasible, does some of the remarks makes sense to some of you ? At least, Caro, as we talked a bit, your writings on such a quest will be terrific, and Iâm sure well followed ;-) Have a nice Easter Monday, Cédrick
Hi Cedreek, (Part of this I mentioned on Discord as well, but not all readers will be on Discord) I'm working with a tiny Smalltalk image (currently around 150Kb) which contains basic classes (very similar to PharoCandle, but with the regular Smalltalk names without PC-prefix, see https://github.com/carolahp/PharoCandleSrc). It additionally supports WebSockets when used in combination with SqueakJS, but I'm working on a regular WebSocket-version for OpenSmalltalk-VM as well. The image has an ObjectEncoder/Decoder pair allowing the image to 'receive' encoded classes and methods from a regular Smalltalk image (bytcode only, since no compiler is present in the tine image). The tiny image can install these classes and use them. The current 'protocol' is to send messages to this tiny image and have the image send events back to the regular image. The tiny image (client) is responsible for making a connection with the regular image (server). But this protocol can be adjusted with newly installed classes of course ;-). My idea (dream?) is to create small cloud images for personal use, so you can run many on limited computing units. These images will not have file- or FFI-support and need to retrieve data through WebSocket/HTTP/... or other web communication technology. It is part of a project I'm working on to learn programming in Smalltalk to kids. They can spin up an image in the cloud (or on their Raspberry Pi at home) and load their code from a remote repository. The development environment will run in the cloud and be usable with a web browser. In the web browser runs a tiny image which can execu...o wait, I explained that part already ;-). So in the web browser this same tiny image is running (on SqueakJS). This time, it loads code to be able to manipulate the DOM. This tiny image is sort of the Javascript replacement. So everything is Smalltalk! :-) Still a long way to go though. I hope to be able to demonstrate a little of this in a not so distant future. I will share my code as well. Everything will be open source. Feel free to reach out if anyone wants to participate. ;-) Regards, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Erik,
(Part of this I mentioned on Discord as well, but not all readers will be on Discord)
Yes Iâve just seen it and I remembered seeing your posts
I'm working with a tiny Smalltalk image (currently around 150Kb) which contains basic classes (very similar to PharoCandle, but with the regular Smalltalk names without PC-prefix, see https://github.com/carolahp/PharoCandleSrc). It additionally supports WebSockets when used in combination with SqueakJS, but I'm working on a regular WebSocket-version for OpenSmalltalk-VM as well.
The image has an ObjectEncoder/Decoder pair allowing the image to 'receive' encoded classes and methods from a regular Smalltalk image (bytcode only, since no compiler is present in the tine image). The tiny image can install these classes and use them. The current 'protocol' is to send messages to this tiny image and have the image send events back to the regular image. The tiny image (client) is responsible for making a connection with the regular image (server). But this protocol can be adjusted with newly installed classes of course ;-).
Cool this is the stuff I need to play with. How can I try ?
My idea (dream?) is to create small cloud images for personal use, so you can run many on limited computing units.
Frankly this is my same goal, except I see them as « Information system node » of a distributed information system architecture ie. Computing units of information objects (often related to scripts btw). So this is really really great what you achieved :)
These images will not have file- or FFI-support
Ok. Indeed this would complicate for nothing. No FFI support but would some simple interaction wanted (I/o stream, small unix system call ?).
and need to retrieve data through WebSocket/HTTP/... or other web communication technology. It is part of a project I'm working on to learn programming in Smalltalk to kids.
Cool
They can spin up an image in the cloud (or on their Raspberry Pi at home) and load their code from a remote repository.
For me it would be spin a new information system and eventually link it with shared others (can be a remote repo).
The development environment will run in the cloud and be usable with a web browser. In the web browser runs a tiny image which can execu...o wait, I explained that part already ;-). So in the web browser this same tiny image is running (on SqueakJS). This time, it loads code to be able to manipulate the DOM. This tiny image is sort of the Javascript replacement. So everything is Smalltalk! :-)
Still a long way to go though. I hope to be able to demonstrate a little of this in a not so distant future. I will share my code as well. Everything will be open source.
Iâm really interested and love to help in some ways. So as far as you have info/tuto or other thinks, please tell me. Just be running it would be the first step. Any pointers/repositories ? Cheers, Cédrik
Feel free to reach out if anyone wants to participate. ;-)
Regards, Erik
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
This sounds a lot like Craig Latta's "Spoon". Probably worth talking to him about it. On Tue, 14 Apr 2020 at 07:48, Erik Stel <erik.stel@gmail.com> wrote:
Hi Cedreek,
(Part of this I mentioned on Discord as well, but not all readers will be on Discord)
I'm working with a tiny Smalltalk image (currently around 150Kb) which contains basic classes (very similar to PharoCandle, but with the regular Smalltalk names without PC-prefix, see https://github.com/carolahp/PharoCandleSrc). It additionally supports WebSockets when used in combination with SqueakJS, but I'm working on a regular WebSocket-version for OpenSmalltalk-VM as well.
The image has an ObjectEncoder/Decoder pair allowing the image to 'receive' encoded classes and methods from a regular Smalltalk image (bytcode only, since no compiler is present in the tine image). The tiny image can install these classes and use them. The current 'protocol' is to send messages to this tiny image and have the image send events back to the regular image. The tiny image (client) is responsible for making a connection with the regular image (server). But this protocol can be adjusted with newly installed classes of course ;-).
My idea (dream?) is to create small cloud images for personal use, so you can run many on limited computing units. These images will not have file- or FFI-support and need to retrieve data through WebSocket/HTTP/... or other web communication technology. It is part of a project I'm working on to learn programming in Smalltalk to kids. They can spin up an image in the cloud (or on their Raspberry Pi at home) and load their code from a remote repository. The development environment will run in the cloud and be usable with a web browser. In the web browser runs a tiny image which can execu...o wait, I explained that part already ;-). So in the web browser this same tiny image is running (on SqueakJS). This time, it loads code to be able to manipulate the DOM. This tiny image is sort of the Javascript replacement. So everything is Smalltalk! :-)
Still a long way to go though. I hope to be able to demonstrate a little of this in a not so distant future. I will share my code as well. Everything will be open source.
Feel free to reach out if anyone wants to participate. ;-)
Regards, Erik
-- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Richard, Richard O'Keefe wrote
This sounds a lot like Craig Latta's "Spoon". Probably worth talking to him about it.
In the past I had some interest in Spoon, but it seems inactive now in favour of Caffeine and Naiad (the module system for Spoon). Spoon is not open source btw. Spoon & Naiad is/was about live coding with versions of classes and methods which is different from my needs. At that time Spoon had its own VM I think. Recently I had some contact with Craig regarding SqueakJS for my work and last Fall I presented some of my ideas at a meetup where he was too. He did not reach out there and admittedly I did not ask. My ideas are definitely not new and where possible I try to make use of existing ideas, designs or products. Something about trying to stand on the shoulder of giants comes up as a title ;-). Thx for the pointer though. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
Hi Cédrick, Remember the Pharo vision back in 2005. Pharo Zen Our values and convictions are condensed in this simple list. Easy to understand, easy to learn from, easy to change. Objects all the way down. Examples to learn from. Fully dynamic and malleable. Beauty in the code, beauty in the comments. Simplicity is the ultimate elegance. Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary. Messages are our vocabulary. Polymorphism is our esperanto. Abstraction and composition are our friends. Tests are important but can be changed. Explicit is better than implicit. Magic only at the right place. One step at a time. There is no unimportant fix. Learning from mistakes. Perfection can kill movement. Quality is a emerging property. Simple processes to support progress. Communication is key. A system with robust abstractions that a single person can understand. Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
But how to change such legacy beast, the pharo image  ? Potential is huge but resistance is also tough for so few people⦠Just imagining changing method protocols seems so complex at the end !
Instead, Iâd start with minimal images, bootstrapped ones. A system I would love to understand every bits. Iâm pretty sure this is what lots of us have in mind and the progress in bootstrap has been teasing us ;-)
-- Dr. Geo http://drgeo.eu
Which is always available in any Pharo image as Help > Pharo Zen
On 16 Apr 2020, at 12:04, Hilaire <hilaire@drgeo.eu> wrote:
Hi Cédrick,
Remember the Pharo vision back in 2005.
Pharo Zen Our values and convictions are condensed in this simple list. Easy to understand, easy to learn from, easy to change. Objects all the way down. Examples to learn from. Fully dynamic and malleable. Beauty in the code, beauty in the comments. Simplicity is the ultimate elegance. Better a set of small polymorphic classes than a large ugly one. Classes structure our vocabulary. Messages are our vocabulary. Polymorphism is our esperanto. Abstraction and composition are our friends. Tests are important but can be changed. Explicit is better than implicit. Magic only at the right place. One step at a time. There is no unimportant fix. Learning from mistakes. Perfection can kill movement. Quality is a emerging property. Simple processes to support progress. Communication is key. A system with robust abstractions that a single person can understand.
Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
But how to change such legacy beast, the pharo image ? Potential is huge but resistance is also tough for so few people⦠Just imagining changing method protocols seems so complex at the end !
Instead, Iâd start with minimal images, bootstrapped ones. A system I would love to understand every bits. Iâm pretty sure this is what lots of us have in mind and the progress in bootstrap has been teasing us ;-)
-- Dr. Geo http://drgeo.eu
As a matter of fact it is interesting to compare the number of classes in the last releases of the descendants of Smalltalk 80: * Cuis5 (480 classes), * Squeak 5.2 (2713 classes) * Pharo8 (*9084 *classes) I don't think the last Pharo vision statement: /A system with robust abstractions that a single person can understand./ is in anyway realistic. Now, will Pharo9 reach the sky with *10'000* classes? Very likely if you observe the graph below: Hilaire Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
-- Dr. Geo http://drgeo.eu
I forgot the graph: Now, will Pharo9 reach the sky with *10'000* classes? Very likely if you observe the graph below: -- Dr. Geo http://drgeo.eu
A vision is not a state-of-the-art description. If we would target a minimal system we still can have a bloated one. And the number of classes in the system is not a metric of understandability. Otherwise providing more tools for people to look onto code and understand would be a contradiction to this. Norbert
Am 16.04.2020 um 12:46 schrieb Hilaire <hilaire@drgeo.eu>:
As a matter of fact it is interesting to compare the number of classes in the last releases of the descendants of Smalltalk 80:
* Cuis5 (480 classes), * Squeak 5.2 (2713 classes) * Pharo8 (*9084 *classes)
I don't think the last Pharo vision statement:
/A system with robust abstractions that a single person can understand./
is in anyway realistic.
Now, will Pharo9 reach the sky with *10'000* classes? Very likely if you observe the graph below:
Hilaire
Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
-- Dr. Geo http://drgeo.eu
I think weâre in a kind of in-between path: - the bootstrap work but still at its early days - the main development still copes with Morphic. Spec2 is a high objective and is sponsored⦠So lots of code duplication, as the tools and frameworks. But also progress and again so few real manpower⦠It seems to be more reasonable to imagine iterative bootstrap of new images. But this is just a feeling and right now people are so busy that I think we have to be patient for that.I donât know but that might be kind of an obliged path so as to reduce drastically later. I hope so too. Also, Hilaire, I can see you struggle with DrGEO to keep up to date. Iâve no such project, so I can just imagine your frustration, especially since DrGEO UI had to rely on Morphic from long time (To me, this must be the hardest projects to maintain here). For now, I can bear some hundreds MB as anyway all open softwares on my OS (just crazy by the way). Just out of curiosity, I opened an Activity Monitor (see pic 1). Wow, I was amazed that pharo occupies 2,51Go (the processor is ok, around 3% in idle). But WOW, I work in this image for about two weeks never turning off my computer, always suspend with Pharo and everything opened (yes Iâm this kind of guy ^^) and this is actually extraordinary stable. Iâve as many workspaces as I did visualization experiments on COVID⦠So thousands of record every days, and visualizations etc⦠Compared to other softwares on the list, pharo does not have to blush. I save the image, it is 170MB on disk. 20MB more than my last version (with is normal since I keep more data in it). I reopen. All is still available (at least the data in playgrounds), and the occupied memory is 228MB (pic 2). Ok, I could have done a garbage collector⦠But still Iâm impressed on the stability, really ! So Iâd like to sincerely congratulates the dev for that. Please continue your hard work ! I also wish that the infrastructure will soon allow to build real and better images, within a contained complexity. Just some questions maybe : - what would be a realistic estimation of having « minimal images from bootstrap» usable in production ? 2y ? - What about the UI plans here, Full removal of Morphic ? SPEC2 then specific backends (Bloc / Native) ? Is it possible/planned to have a programmable UI, like a REST Interface that would be compatible with Spec2 ? Cheers, Cédrick After reopening (like one of my safari tab !).
Le 16 avr. 2020 à 12:46, Hilaire <hilaire@drgeo.eu> a écrit :
As a matter of fact it is interesting to compare the number of classes in the last releases of the descendants of Smalltalk 80:
* Cuis5 (480 classes), * Squeak 5.2 (2713 classes) * Pharo8 (*9084 *classes)
I don't think the last Pharo vision statement:
/A system with robust abstractions that a single person can understand./
is in anyway realistic.
Now, will Pharo9 reach the sky with *10'000* classes? Very likely if you observe the graph below:
Hilaire
Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
-- Dr. Geo http://drgeo.eu
I'm not sure what "descendants of Smalltalk-80" means. Surely it should include VisualWorks (2994 classes) and GNU Smalltalk (248 classes in the kernel) and Dolphin Smalltalk (2164). My Smalltalk is recognisably a descendant of Smalltalk-80, and the test build has 985 classes I'm not sure what the number of classes means either. The number of classes in a classic Smalltalk-80 image is well-defined, but with repository access like Iceberg, it is feasible to have a lot of stuff outside the core. The figure for GNU Smalltalk is deceptive because the UI kit, XML support, I18N support, Sockets, and a lot of other stuff are outside its kernel. VW comes with a bunch of "parcels": XML, XPath, XSL, oodles of tools including UI painter, data base interface, &c out of the image (so not counted above) but available with a few mouse clicks. Pharo and Squeak can install a grreat deal of stuff from their repositories. Dolphin comes with another 900-odd easily installable contributed classes. Given the number of different things we want to interface to these days, including but in no way limited to TCP, UDP, SCTP, FTP(S), HTTP(S), (X)HTML,XML,assorted XML addons, YAML, TOML, JSON, BERP, ASN.1, SQL, assorted No-SQL systems, too many audio formats, too many image formats, too many video formats, too many compression schemes, too many versions of Markdown (and close relatives), a character set standard that grows rapidly and requires a book of 1030 pages to describe it -- that's exclusive of code charts -- and all the other delirious warty melons one needs to interface to these days, and I don't believe we *can* have a minimal class library. I mean, it takes me 28 classes just to deal with core XML, and I insist that every class be worth its pay. The best we can hope for is something in the Spoon mould, where you have in the low hundreds of classes, some of which (arithmetic, collections, streams, perhaps geometric objects) can be understood in full by programmers, some of which (compiler, network, file system) have *interfaces* that programmers can understand but whose implementation they seldom bother about, then an middle layer of packages providing things like audio, images, video, compression, encryption, Markdown, whatever, that are normally held locally and possibly auto-loaded, then an outer layer of repositories. Smalltalk is simple enough, it's just that things we need to talk to are insanely complex. (Hands up everyone who has actually read the whole of the Unicode standard. Oh well done. Now put your hand down if you have *understood* the whole of it. Nobody with a hand up? Well I never.) understand On Thu, 16 Apr 2020 at 22:46, Hilaire <hilaire@drgeo.eu> wrote:
As a matter of fact it is interesting to compare the number of classes in the last releases of the descendants of Smalltalk 80:
* Cuis5 (480 classes), * Squeak 5.2 (2713 classes) * Pharo8 (*9084 *classes)
I don't think the last Pharo vision statement:
/A system with robust abstractions that a single person can understand./
is in anyway realistic.
Now, will Pharo9 reach the sky with *10'000* classes? Very likely if you observe the graph below:
Hilaire
Le 13/04/2020 à 14:30, Cédrick Béler a écrit :
Just a reflexion that Iâd like to share here. When Hilaire talks about complexity. I have to agree too, even if I like the progress under the hood, and explored spaces like GToolkit.
-- Dr. Geo http://drgeo.eu
Le 16/04/2020 à 14:23, Richard O'Keefe a écrit :
I'm not sure what "descendants of Smalltalk-80" means.
Obviously, I mean the Apple' Smalltalk-80 Squeak takes its origin from. I should have write that.
Smalltalk is simple enough, it's just that things we need to talk to are insanely complex. (Hands up everyone who has actually read
But Pharo is over this point. Its complexity is not because of additional packages but from its internal way of doing things, I can't tell you exactly why, I am just observing this situation when trying to understand how things work from the inside. See for example my idiotic struggle a couple of days ago. For example, Morph was not cleanup as done in Cuis but since ten years there were attempts to develop additional frameworks (athens, bloc, brick, other?) with unclear results. -- Dr. Geo http://drgeo.eu
We are not fighting successfully against the accidental complexity. On the other hand, the count of classes is not really meaningful value. Pharo has about 1700 test classes, there are rules, manifests and baselines. The Opal and AST-Core has much more classes than the old compiler for good reasons and so on... Cheers, -- Pavel Ät 16. 4. 2020 v 15:23 odesÃlatel Hilaire <hilaire@drgeo.eu> napsal:
Le 16/04/2020 à 14:23, Richard O'Keefe a écrit :
I'm not sure what "descendants of Smalltalk-80" means.
Obviously, I mean the Apple' Smalltalk-80 Squeak takes its origin from. I should have write that.
Smalltalk is simple enough, it's just that things we need to talk to are insanely complex. (Hands up everyone who has actually read
But Pharo is over this point. Its complexity is not because of additional packages but from its internal way of doing things, I can't tell you exactly why, I am just observing this situation when trying to understand how things work from the inside. See for example my idiotic struggle a couple of days ago.
For example, Morph was not cleanup as done in Cuis but since ten years there were attempts to develop additional frameworks (athens, bloc, brick, other?) with unclear results.
-- Dr. Geo http://drgeo.eu
participants (7)
-
Cédrick Béler -
Erik Stel -
Hilaire -
Norbert Hartl -
Pavel Krivanek -
Richard O'Keefe -
Sven Van Caekenberghe