Does anyone remember Servant by Andy Hertzfeld? Which kind of blended the Finder with ResEdit, showing the resources just like it shows folders and files. Allowing to manipulate them the same way, for example copying via drag'n'drop etc.
> The sheer oddity + lack of real world example code floating around made it feel impenetrable
not sure if I understand you, but you have the code of the whole system at your fingertips. Which is certainly "real world" because you are running it :)
real world example means end user applications, not developer tools. i want to see how an application looks like that my mother could use, or that i could sell to my customer. websites. desktop applications that hide the IDE...
that's not the question. we are looking for examples that come with source that can be studied.
the success page lists 53 projects. only one of them came with a direct link to the source. one included an un-clickable link. one linked to a non-english website where i could figure out that it was licensed under the LGPL, but i could not find the link to the source.
a surprise was that DrGeo which is known to be Free Software links to a dead website. grafoscopio which i also believe to be FOSS as well has a dead download link on its website.
that is three source examples under active development
for a project as old and as large as pharo is that is surprisingly little.
more accessible source examples are needed to attract developers. especially given the difficulty to get used to the pharo developer tools.
i have actively explored working with pharo. i just could not find any useful apps that i could use and contribute to. and i had no ideas for an app that i'd be interested enough to create from scratch.
for a while i even tried to use it as a desktop and used an app that provides a commandline inside pharo.
the primary problem was that upgrading to a new version of pharo each year was difficult. given the image based development you tend to start with a current version of pharo and then keep to that version until you are done.
i mean the lack of version control inside the image can be considered a problem, as you have to connect to external tools go get it, lest you save a copy of the image as a version (which is what i would call image based version control), which that is not practical at all.
but that is not what i meant. i was talking about the problem that when i develop an application in pharo 11, but then i want to move the development to pharo 12, that amounts to a lot of work, so i don't do it but i'll stick to pharo 11 until my app is done.
it's not the code conflicts, but all the modifications i made to the environment. addons i installed, configurations i changed, windows i opened, code snippets i have in a workspace/playground. pharo is to much like a desktop, and switching to a new version of pharo is like reinstalling my computer and setting up my desktop from scratch.
there is no tool that would just take every change i made to the original pharo image and apply it to the new one.
you know like docker where your base image is immutable and changes to that image are saved in a separate image that is layered on top. so that you can replace the base image while keeping your changes.
> there is no tool that would just take every change i made to the original pharo image and apply it to the new one.
What about Smalltalk?
All your interaction with the IDE is implemented in Smalltalk. For each of the changes you want to preserve, figure out which UI class is used and browse the code to figure out how the UI class makes those changes. Then copy what the UI class does into a workspace script, save the script, and file-in to a clean distro image to check that it works.
Here's an example of a little script being filed-in to load a program, do clean-up and save the image:
i would want to preserve everything. this is not solvable with a simple script. in docker this feature comes built in. everywhere else all i need to do is copy my homedirectory, and every upgraded application works with the data i have. smalltalks design makes this a magnitude more difficult, and in the end not worth the effort until i get an opportunity to work on a paid project.
Yup. This is an interesting time for the project. It's after the '88 meeting where they separated features onto blue (easier), pink (harder) and red (hardest) cards and before '91 when they were actively talking to IBM about what would eventually become Talingent in '92.
They've had enough time to think about things and get some early coding experiments under their collective belts, but not so long that the impact of infighting (and mild panic) is so apparent.
I contributed a small bit to a serial port manager in this time frame. In retrospect, it's clear they wanted something that could work on different hardware (like the 16550 popular in PCs and Z8530s already used by the macs) - but I'm a little sad to see it isn't mentioned here.
http://bitsavers.org/pdf/apple/mac/Servant_A_New_Shell_for_t...