4 ms·

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 re

by em-bee 6mo ago

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 6mo ago
> 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 6mo ago
  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 6mo ago
    > … 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 6mo ago
      yes to both. (not as long as we keep to the topic and respond before the time to reply expires)
      - igouy 6mo ago
        > … 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.

by em-bee 6mo ago

igouy 6mo ago

> 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 6mo ago
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 6mo ago
  > … 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 6mo ago
    yes to both. (not as long as we keep to the topic and respond before the time to reply expires)
    - igouy 6mo ago
      > … 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.