Hi,
How important is the changes file, really? I don't mean in terms of recovering from crashes, because I use my changes file all the time.
I mean, if a changes file is not present, does everything still work? I ask, because SmalltalkImage >> #logChange: specifically protects against a missing changes file (in the sense that it does nothing if (Sources at: 2) == nil). However, if you start up an image with no changes file, there's a big fat modal dialog warning about the missing file, but clicking through results in what looks - at first glance at least - like a normally functioning image.
If a changes file is _desirable_ but not _necessary_, could we remove the dialog (or do something different for -headless images, like dumping a warning to stderr)? Or simply start a new changes file if one's missing?
The concrete problem I'm trying to work around is with the CI test script. Running the test means modifying the changes file and Jenkins really does not like that. If the changes file were not necessary I could simply not keep it under version control.
Sometimes, I don't _care_ about recovering from a crash.
frank
There is a preference to control the warning:
warnIfNoChangesFile
Cheers, Bob
On 8/1/12 8:00 AM, Frank Shearar wrote:
Hi,
How important is the changes file, really? I don't mean in terms of recovering from crashes, because I use my changes file all the time.
I mean, if a changes file is not present, does everything still work? I ask, because SmalltalkImage >> #logChange: specifically protects against a missing changes file (in the sense that it does nothing if (Sources at: 2) == nil). However, if you start up an image with no changes file, there's a big fat modal dialog warning about the missing file, but clicking through results in what looks - at first glance at least - like a normally functioning image.
If a changes file is _desirable_ but not _necessary_, could we remove the dialog (or do something different for -headless images, like dumping a warning to stderr)? Or simply start a new changes file if one's missing?
The concrete problem I'm trying to work around is with the CI test script. Running the test means modifying the changes file and Jenkins really does not like that. If the changes file were not necessary I could simply not keep it under version control.
Sometimes, I don't _care_ about recovering from a crash.
frank
On Wed, Aug 01, 2012 at 01:00:32PM +0100, Frank Shearar wrote:
Hi,
How important is the changes file, really? I don't mean in terms of recovering from crashes, because I use my changes file all the time.
I mean, if a changes file is not present, does everything still work? I ask, because SmalltalkImage >> #logChange: specifically protects against a missing changes file (in the sense that it does nothing if (Sources at: 2) == nil). However, if you start up an image with no changes file, there's a big fat modal dialog warning about the missing file, but clicking through results in what looks - at first glance at least - like a normally functioning image.
If a changes file is _desirable_ but not _necessary_, could we remove the dialog (or do something different for -headless images, like dumping a warning to stderr)? Or simply start a new changes file if one's missing?
The concrete problem I'm trying to work around is with the CI test script. Running the test means modifying the changes file and Jenkins really does not like that. If the changes file were not necessary I could simply not keep it under version control.
Sometimes, I don't _care_ about recovering from a crash.
You can symlink the changes file to /dev/null and all of the changes will go into the bit bucket:
$ rm myImage.changes $ ln -s /dev/null myImage.changes $ squeak myImage
Dave
On 1 August 2012 13:35, David T. Lewis lewis@mail.msen.com wrote:
On Wed, Aug 01, 2012 at 01:00:32PM +0100, Frank Shearar wrote:
Hi,
How important is the changes file, really? I don't mean in terms of recovering from crashes, because I use my changes file all the time.
I mean, if a changes file is not present, does everything still work? I ask, because SmalltalkImage >> #logChange: specifically protects against a missing changes file (in the sense that it does nothing if (Sources at: 2) == nil). However, if you start up an image with no changes file, there's a big fat modal dialog warning about the missing file, but clicking through results in what looks - at first glance at least - like a normally functioning image.
If a changes file is _desirable_ but not _necessary_, could we remove the dialog (or do something different for -headless images, like dumping a warning to stderr)? Or simply start a new changes file if one's missing?
The concrete problem I'm trying to work around is with the CI test script. Running the test means modifying the changes file and Jenkins really does not like that. If the changes file were not necessary I could simply not keep it under version control.
Sometimes, I don't _care_ about recovering from a crash.
You can symlink the changes file to /dev/null and all of the changes will go into the bit bucket:
$ rm myImage.changes $ ln -s /dev/null myImage.changes $ squeak myImage
Ah, yes of course. That's the natural thing to do! Pity I didn't think of it, but oh well!
Thanks!
frank
Dave
Frank Shearar-3 wrote
If the changes file were not necessary I could simply not keep it under version control.
Pharo uses wget to download things like the image/changes/sources [1] [2].
HTH, Sean
[1] https://ci.lille.inria.fr/pharo/job/Scripts-download/ws/pharo-shell-scripts/... [2] https://ci.lille.inria.fr/pharo/job/Scripts-download/ws/download.sh/*view*/
-- View this message in context: http://forum.world.st/Changes-file-how-important-tp4642416p4642455.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 1 August 2012 14:14, Sean P. DeNigris sean@clipperadams.com wrote:
Frank Shearar-3 wrote
If the changes file were not necessary I could simply not keep it under version control.
Pharo uses wget to download things like the image/changes/sources [1] [2].
Sure. But doing that right now means you use git to get a shell to download an artifact, which seems... a bit busy. Right now we can check out the CI environment in its entirety. I guess the current squeak-ci also helps with bandwidth usage, if that's an issue: you'll only download a new image once in a while. I don't know if that's a significant argument either way :)
frank
HTH, Sean
[1] https://ci.lille.inria.fr/pharo/job/Scripts-download/ws/pharo-shell-scripts/... [2] https://ci.lille.inria.fr/pharo/job/Scripts-download/ws/download.sh/*view*/
-- View this message in context: http://forum.world.st/Changes-file-how-important-tp4642416p4642455.html Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 01.08.2012, at 06:24, Frank Shearar wrote:
On 1 August 2012 14:14, Sean P. DeNigris sean@clipperadams.com wrote:
Frank Shearar-3 wrote
If the changes file were not necessary I could simply not keep it under version control.
Pharo uses wget to download things like the image/changes/sources [1] [2].
Sure. But doing that right now means you use git to get a shell to download an artifact, which seems... a bit busy. Right now we can check out the CI environment in its entirety. I guess the current squeak-ci also helps with bandwidth usage, if that's an issue: you'll only download a new image once in a while. I don't know if that's a significant argument either way :)
frank
IMHO the tests should be as close to real-world usage as possible. You don't need a changes file for running, but for developing you do. I think putting a hard git reset into the build script is the right way to deal with this. Alternatively it could copy the image+changes to a temp location and run from there.
- Bert -
On 1 August 2012 17:29, Bert Freudenberg bert@freudenbergs.de wrote:
On 01.08.2012, at 06:24, Frank Shearar wrote:
On 1 August 2012 14:14, Sean P. DeNigris sean@clipperadams.com wrote:
Frank Shearar-3 wrote
If the changes file were not necessary I could simply not keep it under version control.
Pharo uses wget to download things like the image/changes/sources [1] [2].
Sure. But doing that right now means you use git to get a shell to download an artifact, which seems... a bit busy. Right now we can check out the CI environment in its entirety. I guess the current squeak-ci also helps with bandwidth usage, if that's an issue: you'll only download a new image once in a while. I don't know if that's a significant argument either way :)
frank
IMHO the tests should be as close to real-world usage as possible. You don't need a changes file for running, but for developing you do. I think putting a hard git reset into the build script is the right way to deal with this. Alternatively it could copy the image+changes to a temp location and run from there.
The latter is the only feasible option of the two: Jenkins has very particular ideas about things, and doing a hard reset in the build script be too late.
I'm just waiting for Chris Cunnington to chown a few files and I'll take another run at the problem.
Oh, and it occurs to me belatedly that I _do_ need the changes file... for tests that check that, for instance, changes are actually stored there. Not that we have any of those, but when we do...
frank
- Bert -
On Wed, 1 Aug 2012, Frank Shearar wrote:
Hi,
How important is the changes file, really? I don't mean in terms of recovering from crashes, because I use my changes file all the time.
I mean, if a changes file is not present, does everything still work? I ask, because SmalltalkImage >> #logChange: specifically protects against a missing changes file (in the sense that it does nothing if (Sources at: 2) == nil). However, if you start up an image with no changes file, there's a big fat modal dialog warning about the missing file, but clicking through results in what looks - at first glance at least - like a normally functioning image.
If a changes file is _desirable_ but not _necessary_, could we remove the dialog (or do something different for -headless images, like dumping a warning to stderr)? Or simply start a new changes file if one's missing?
The concrete problem I'm trying to work around is with the CI test script. Running the test means modifying the changes file and Jenkins really does not like that. If the changes file were not necessary I could simply not keep it under version control.
In some cases the changes file is not necessary, but the absence of the real changes file will make the system behave differently, especially while running the compiler tests.
Levente
Sometimes, I don't _care_ about recovering from a crash.
frank
squeak-dev@lists.squeakfoundation.org
-
Bert Freudenberg -
Bob Arning -
David T. Lewis -
Frank Shearar -
Levente Uzonyi -
Sean P. DeNigris