[igouy]

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

When packaged together IDE & compiler can't be upgraded separately (without doing the work to in-effect make separate packages).

> … can't compile my own code in the image with the old version

So we could try to compile own-code' in image' with compiler', and we could try to compile own-code' in image" with compiler", but we want to try to compile own-code' in image" with compiler' ?

Not without doing the work to in-effect make separate packages. (Say we could port compiler' to image" but would that mean trying to compile compiler' with compiler".)

And now we're back to what does "traditional way of doing smalltalk development" mean because supposedly "Team/V could forward and backwards migrate versions of Smalltalk “modules” within a running virtual image."

> the point of a reproducible build is that a version of source code always produces the same binary.

Scope: does "a version of source code" just mean own-code or does it mean sources+changes.

[em-bee]

i have just been reading https://news.ycombinator.com/item?id=48081245 about reproducible builds in debian, and that reminded me of this discussion. truth is i still struggle to understand how reproducible builds with smalltalk images even work.

in debian, a build is reproducible if the checksum of the resulting package of my build matches that of your build. how do you do that in a smalltalk image? you take the checksum of what? which objects or rather entities do you compare, and how do you compare them, to verify that a build is reproducible? it can't be the whole image, because that is guaranteed to be different somewhere, and thus the image checksums won't match. so how does that really work?

[em-bee]

there is another thought that i just realized. what are reproducible builds with runtime compiled languages like python, ruby, perl, even javascript? the point of a reproducible build is to verify that the binary i use, or that the package i use is based on the same source that i have. python et al don't have binaries. so my reproducible build check is a diff of the source tree. if in smalltalk the image is my source then i care about knowing that the image has not been modified. that's impossible because the image changes just by using it, unless i never save the changes. what's left is exporting the source and running a diff on that maybe.

[igouy]

> … the point of a reproducible build is to verify that the binary i use, or that the package i use is based on the same source that i have.

I have been talking about how to reproduce a particular build, not how to verify.

From the same initial state, perform the same sequence of actions, implies arrive at the same final state. Reproducible.

"Retaining your old change logs gives you a record of all the changes you have made to the system. This will prove invaluable when you receive a new release of Smalltalk/V. … In short, back up the image and change log together, and you shouldn't have any problems."

page 285 Smalltalk/V 286 Tutorial and Programming Handbook 1988

[em-bee]

ok, it seems we are talking about different things. "reproducible builds" generally refers to verification. so i misunderstood what you meant.

so we actually have to go back to this question:

> traditional way of doing smalltalk development

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

to summarize, i was talking about traditional meaning to make changes in an image and then exporting them if needed. and then i was wondering if local changes and the base image can be kept separate, and by that i meant "within the image" so that, when you look at an image, or when you use it, browse the code, you can easily see what are changes and what is the base image. kind of like in an operating system where i can clearly distinguish system files from user files. so effectively that would suggest some kind of ownership markers, or, alternatively, it needs versioning of objects within the image.

i am not suggesting that smalltalk needs to be changed, but i am trying to work out the limitations that affect the workflow. essentially, because this distinction is missing, there is no way to reproduce a build (in your sense of the meaning) without exporting the code and re-importing it in a new image. actually, object versioning within the image would be a really useful addition to smalltalk. it would allow you to easily go back to old versions. of course it would also cause the image to grow, so there would have to be some efficient way to store that. for one, old versions don't need to be kept in memory so they could be in a secondary storage. or put differently, smalltalk could keep track of the changes in the changes file as it does, but in such a way that i can browse and load in old changes from within the image. i don't know if that is possible now.

the image based server system that i talked about earlier btw does have an ownership system and object based versioning. that reveals some interesting potential.

btw this lack of distinction between base image and changes in the image, especially the lack of ownership information i believe is one reason why linux distributions didn't pick up smalltalk as soon as it became available under a free license, because the license could not actually be verified across all objects. especially older objects that had the source purged to save space.

[igouy]

> … so that, when you look at an image, or when you use it, browse the code, you can easily see what are changes and what is the base image…

You seem to be asking about something that is in documentation from 1984.

http://stephane.ducasse.free.fr/FreeBooks/TheInteractiveProg...

> i am not suggesting that smalltalk needs to be changed…

Smalltalk has been changed, several times.

"With ENVY/Manager the image becomes a discardable by-product of development, secondary to the repository that stores and coordinates all work."

https://www.google.com/books/edition/Mastering_ENVY_Develope...

"The way ChangeSets are created and managed in Cuis is different from Squeak."

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

[em-bee]

thanks. it's going to take a while to find time to read those. likely longer than the two weeks available to reply here. let me just say that my experience with smalltalk is limited to playing with squeak and doing some coding with pharo. (i made some video workshops life coding through some tasks, if you are curious).

i am also not suggesting that smalltalk can't be changed, just that i didn't want to assume that my suggestion is the right way, and has to be done, or else. more like: how about this? is that feasible?

cuis is interesting, there are other branches that i find interesting too, such as strongtalk. it's a pity that they receive even less attention than smalltalk itself.

i wish i had more opportunity to work with smalltalk, but nobody is hiring ;-)

[igouy]

> if in smalltalk the image is my source

As-before it doesn't need to be.

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