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

[em-bee]

yes to both.

(not as long as we keep to the topic and respond before the time to reply expires)

[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]

> if in smalltalk the image is my source

As-before it doesn't need to be.

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