[igouy]

Sorry I failed to notice your reply.

> image is not recreated from scratch every time and it is more than just a cache

Yes, some vm & image & sources & changes can be taken as the base implementation for development purposes -- a persistent cache.

The state of whatever IDE tools were in use will be saved -- is that what makes you say "more than just a cache"? If I sleep a windows desktop is that more than just a cache?

> changes first happen in an image

What if I write a plain-text source code file using Notepad, and use Smalltalk file handling and byte code compilation and command-line argument handling (packaged in the image) to write the result of a computation to stdout (and quit the image without saving)?

[em-bee]

If I sleep a windows desktop is that more than just a cache?

yes, so basically what i meant here is that a cache just stores data, but it doesn't store the whole application.

this is significant in that i can shut down an application (say my webbrowser), then i can upgrade it to a new version, restart and and the application will reinitialize itself and load data from the cache, but now i have a new version of the application.

whereas if i put my laptop to sleep, or better yet, hibernate, then the whole state of the laptop is frozen in place, and i can't do anything to it until i run it again. same is true for smalltalk images.

What if I write a plain-text source code file using Notepad, and use Smalltalk file handling and byte code compilation and command-line argument handling (packaged in the image) to write the result of a computation to stdout (and quit the image without saving)?

you could be doing that, but then you would use the image as your IDE and runtime environment, but not building the actual application in your image. so you wouldn't using what i have been taught is the traditional way of doing smalltalk development.

i am not trying to be pedantic here. it does not matter either way. i just find the smalltalk image approach interesting because it forces you to think about software development in a different way.

this mattes to me because i am working with a web development platform (written in pike) that uses a similar approach. albeit more by accident than intentional. the developers of the platform added support for programmable objects that are stored in the platforms database. these objects can change the behavior of the platform itself, like plugins, but because they are stored in the database they can be changed at runtime, like a smalltalk image. and all the same implications for doing that apply here too. the database becomes more than a cache. and in theory the whole platform could be rewritten such that almost all of its code is stored in the database and only a small bootstrapping system needs to remain outside. this is simply made possible because pike can load and update code at runtime and code changes can be applied without restarting, just like smalltalk.

the downside of the image approach is that it makes upgrading the base image harder, because there is no clear distinction between the base image and any user added changes. i kind of have to take extra steps to pick out my changes and apply them to a new image.

it would be interesting if that process could be improved. it probably would require some compartmentalization just like an OS where i have the base OS, my home directory and the system configuration. i can take a disk image, upgrade the OS and the rest still works. it would be nice if upgrading pharo for example would work the same way.

btw: thanks for the email. i have to ask, how did you manage to reply to a comment more than a month old. normally the reply function is disabled on comments that are 14 days old.

[igouy]

> traditional way of doing smalltalk development

Is that in-conflict with a reproducible build process or can we have both.

> makes upgrading the base image harder, because there is no clear distinction between the base image and any user added changes.

We've been keeping "user added changes" in external files? (Plus the changes file.)

Port "user added changes" from the source code archive to each vendor release.

(btw: I ask nicely and don't abuse this small kindness.)

[em-bee]

Is that in-conflict with a reproducible build process or can we have both

in part the question is what makes a build reproducible. what actually needs to be reproduced? the point of a reproducible build is that a version of source code always produces the same binary.

how do you make reproducible builds in smalltalk? reproducible builds depend on what goes into the build process. so they depend on the compiler and build tools. in smalltalk those are all in the image, and the question is then what happens when i load code into an image. am i getting that right? i am not so familiar with the details here, but i would guess that it depends on how smalltalk compiles the code and how the import process deals with timestamps and source paths, etc.

however if i work on my source code within the image and i share the code by making a copy of the image then the image is the source and the binary and there is nothing to reproduce. your copy and my copy of the image are going to be identical until one of us makes changes to the image.

i'd be curious to learn more here. outside the smalltalk world my editing tools do not affect the reproducibility of the builds of my code. in smalltalk. just getting a new version of the code browser would change the build, wouldn't it? how do you track that or keep that separate?

Port "user added changes" from the source code archive to each vendor release

right, but that's the "wrong" way around from the perspective of a desktop. i don't need to port my code to new versions of VS Code or vim or which ever tools i use to develop. only smalltalk forces me to do that. so i don't mean distinction in the file structure but distinction in the code dependency.

(i would never have considered to ask for being allowed to make a late reply, especially in this case. it is unlikely that anyone else is going to see our conversation. we could have just continued over email. but hopefully we can dig out some worthwhile details that not only me but anyone searching can learn from)

[igouy]

> just getting a new version of the code browser would change the build

Outside the smalltalk world could getting a new version of the code browser "library" affect the reproducibility of the builds of your code.

(indeed: vanity)

[em-bee]

it sounds like you are asking a question, but there is no "?" at the end, so i am slightly confused. if it is a question, my answer is no, because the tools i use to read or edit the code are completely distinct from the build tools.

what affects the reproducibility is the compiler, and that's the issue with smalltalk. you can't upgrade the IDE without upgrading the compiler. say if i use pharo, and switch to a new version of pharo then i get a new version of smalltalk, and i can't compile my own code in the image with the old version any more.

based on that i don't understand how you even enable or test reproducibility in smalltalk. i'd like to learn more about that.

(re: vanity. since a while i have wondered how i would go about creating the longest running discussion thread on hackernews. and how long i would be able to keep it going. i think we are off to a good start here. just remember to peek in here once a while to see if there is a response. and if there isn't feel free to poke me by email. (unless we decide that there is nothing to add))

[igouy]

> … you can't upgrade the IDE without upgrading the compiler.

Do you mean because the IDE and compiler are packaged together, so when you get image' it may contain changes to both?

> … i can't compile my own code in the image with the old version any more.

Do you mean because the image' package has compiler' not the old version?

(Probably an abuse of kindness.)

[igouy]

My imagination has failed. I don't understand which issues you are concerned with. I think we're done.