Smalltalk › Squeak › Squeak - Dev

Squeak 4.4 Question

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

35 messages Options

Yanni Chiu

Re: Squeak 4.4 Question

On 16/01/13 5:17 PM, Frank Shearar wrote:
>
> They might have the same content, but they are semantically different.

I don't understand what you see as the semantic difference.

>
> But I'm tired of arguing.

Me too. I just don't want to have to keep multiple copies of sources
file around, under different names, which I think is what your change is
leading to.

> Please propose a means that I can, with an
> absolute minimum of effort find the sources file corresponding to a
> given Squeak version, both for 4.4 and for arbitrary versions in the
> future.
>
> I repeat: _all I want_ is a _simple_ correspondence between a released
> Squeak and the source file that it needs. One that a shell script can
> calculate. One that doesn't involve scraping links off a web page.

Exactly the process we have now. The sources file needed to build the
latest release is the one and only sources file created after the last
condense sources.

Squeak1.X --> SqueakV1.sources
Squeak2.X --> SqueakV2.sources
Squeak3.X --> SqueakV3.sources
Squeak4.0 --> SqueakV4.sources
Squeak4.1 --> SqueakV41.sources
Squeak4.2 --> SqueakV41.sources
Squeak4.3 --> SqueakV41.sources
Squeak4.4 --> SqueakV41.sources

(A) No implementation of non-destructive condense sources
Squeak4.5 --> SqueakV41.sources
Squeak4.6 --> SqueakV41.sources
Squeak4.7 --> SqueakV41.sources
Squeak4.8 --> SqueakV41.sources

(A.1) No implementation of non-destructive condense sources, and changes
file gets too big
Squeak4.5 --> SqueakV41.sources
Squeak4.6 --> SqueakV46.sources
Squeak4.7 --> SqueakV46.sources
Squeak4.8 --> SqueakV46.sources

A decision to condense sources has to be made (or not), and from that
point forward, the build script must use that sources file.

(B) Someone implements non-destructive condense sources
Squeak4.5 --> SqueakV45.sources
Squeak4.6, Squeak4.5 --> SqueakV46.sources
Squeak4.7, Squeak4.6, Squeak4.5 --> SqueakV47.sources
Squeak4.8, Squeak4.7, Squeak4.6, Squeak4.5 --> SqueakV48.sources

In scenario (B), you'll get the simple correspondence that you're
looking for. But, the build script is still the same - it has to use the
one and only sources file created by condensing sources.

>
> Deploying without sources might also work, but then you lose debuggability.

Renaming the sources file has nothing to do with deploying without
sources, so I don't get what you're getting at.

Yanni Chiu

Re: Squeak 4.4 Question

In reply to this post by Bert Freudenberg

On 16/01/13 6:05 PM, Bert Freudenberg wrote:
>
> And in case this hasn't been mentioned yet, the non-desctructive condense sources is this:
>
> Smalltalk appendChangesTo: 'test123.sources'

So, should 4.4 be re-done, or does this get run from 4.5 onwards.

bpi

Re: Squeak 4.4 Question

In reply to this post by Frank Shearar-3

Hi Frank,

Couldn't you just add another environment variable SQUEAK_SOURCES_VERSION to your buildpack?

Cheers,
Bernhard

Am 16.01.2013 um 23:50 schrieb Frank Shearar:

> On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote:
>>
>>> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote:
>>>> On 16/01/13 4:40 AM, Frank Shearar wrote:
>>>>>
>>>>>
>>>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are
>>>>> identical to the V41 sources, but I've realised that for automating
>>>>> things you REALLY REALLY want to have the sources file name derivable
>>>>> from the Squeak version. At some point I will need to make Squeak 4.4
>>>>> look for a SqueakV44.sources file, and I've added an item to the todo
>>>>> list to have Squeak 4.5 do this automatically as part of the release
>>>>> cycle.
>>>>
>>>>
>>>> Won't that cause further confusion - the same file named differently. I
>>>> don't understand how a file name that never changes, can be a problem for
>>>> automating a build.
>>>
>>> How can I derive "SqueakV41.sources" from "4.4"?
>>
>> If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking?
>
> Maybe I'm getting misunderstood because it's not clear that I'm
> talking about the _names_ of files, not the contents.
>
> If I want to write a buildpack to deploy a Smalltalk application to
> Heroku, I'll have an environment variable called SQUEAK_VERSION and
> another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string
> "4.4-12327". With that I can find out where exactly to find an image
> tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a
> simple string manipulation. But there is no easy, simple, reliable way
> for me to say "oh, and the sources that corresponds to that is of
> course called "SqueakV44.sources.gz" because my release process had a
> bug in it. I really don't care whether the sources file for 4.4 is
> condensed. I care that it _has_ a sources file, and I care that its
> _name_ is trivially derivable/calculable from the version _name_.
>
> This isn't a hypothetical question about a maybe thing. I have the
> buildpack right now. I just can't finish it because I can't write a
> script to find the sources file. (Scraping http://ftp.squeak.org/4.4/
> for URLs is so made of fail that I'm not going to contemplate it.)
>
> frank
>
>> - Bert -
>>
>>> If I can't derive it,
>>> how can a script? It was an error (on my part) to not produce a
>>> SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due
>>> course, but I need to leave the SqueakV41.sources there for the moment
>>> because the current 4.4 looks for such a file. James Robertson
>>> correctly pointed out that one usually has a .sources file, so we
>>> should have such a thing.
>>>
>>>> IMHO, it should be left alone, unless the plan described by Bert is
>>>> implemented. A "temporary" solution, often becomes permanent.
>>>
>>> The "temporary" part is keeping the SqueakV41.sources there until we
>>> can be sure that 4.4 images won't look for that file, but for
>>> SqueakV44.sources instead.
>>>
>>> frank
>>
>>
>>
>>
>>
>

Eliot Miranda-2

Re: Squeak 4.4 Question

In reply to this post by Yanni Chiu

Hi Yanni,

On Wed, Jan 16, 2013 at 1:44 PM, Yanni Chiu <[hidden email]> wrote:

On 16/01/13 1:38 PM, Frank Shearar wrote:

(It's supposed to be possible to deploy images without sources files.
I haven't been able to get this to work for me. That, too, would
satisfy me.)

I keep the .sources files with the VM, and never have to download a
.sources file for new releases. If I didn't want to save the space, I
would have all the previous squeak .sources there too. Right now,
there's just PharoV10.sources and SqueakV41.sources.

Assuming condense sources is done in the future, when would the
SqueakV4x.sources start to appear? Once the first release candidate is
declared? Or, just after the final release candidate?

It's an alias for 12327, sure. I don't want it to be an alias going
forward. I want it to be the actual proper sources file for the 4.4
releases.

It's premature to introduce SqueakV44.sources, on the faint hope that in
the near future, the non-destructive condense sources will appear.

I have the non-destructive condense changes code written in a Qwaq image. This condense preserves history while trimming branches off the trunk history. i.e. only direct ancestors of the current method version get written to the changes; if a method version isn't an ancestor of the current version it gets eliminated. But this code needs porting and refactoring to be the default condense. It was written for the 3.8-derived Qwaq/Teleplace image (for my own use; it never got integrated). I don't have the time right now to port the code. If you or anyone else is willing to volunteer their time I'm happy to provide the code. In fact, find attached.

If anything is missing, problems come up, etc, don't hesitate to contact me.

HTH

In my
experience, I've seen lots of baggage get introduced, in preparation for
when the rewrite, improved, etc. thing appears - and then it doesn't.
But, we get stuck with the "prep" stuff (i.e. multiple copies of SqueakV41.sources, with different names).

And when the next release comes out, and I delete
Squeak4.4-12327.zip, I'll delete the SqueakV41.sources and the alias
problem will disappear!

"delete" a release! That sounds like a completely wrong process.

IIUC, 4.4 is now released. It uses SqueakV41.sources. Now you want to
release another 4.4 that uses SqueakV44.sources - that is exactly the
same as SqueakV41.sources. Doesn't that create further confusion? I
don't see why this can't be addressed in 4.5.

--
best,

Eliot

condenseChanges.st (12K) Download Attachment

timrowledge

Re: Squeak 4.4 Question

In reply to this post by Frank Shearar-3

On 16-01-2013, at 2:17 PM, Frank Shearar <[hidden email]> wrote:
>
> But I'm tired of arguing. Please propose a means that I can, with an
> absolute minimum of effort find the sources file corresponding to a
> given Squeak version, both for 4.4 and for arbitrary versions in the
> future.
>
> I repeat: _all I want_ is a _simple_ correspondence between a released
> Squeak and the source file that it needs. One that a shell script can
> calculate. One that doesn't involve scraping links off a web page.

My suggestion, for what it's worth -
a) forget naming the individual files by version/update level etc (for releases - for ongoing work when updates are being loaded it makes some sense)
b) name the *directories*
c) document that users should keep the image/changes files for release numpty-ump in a directory separate to their files for release diddly-squat.
d) the best places to keep the VM and .sources file varies by platform. For OS X it could well make sense to keep it in VM bundle, though that might end up with a copy in each version of a VM during development. Disc is cheap, so is it really a problem? For RISC OS I've *always* kept the sources file inside the VM application folder (which is essentially what Apple copied the bundle idea from), For Windows and unices I have no idea what is best because I simply don't use them anymore. Would it make sense to put a suitable link in each release's directory, pointing back to a real file? Links are supposed to work, aren't they?
e) for release filesets stored on squeak.org I'd suggest a directory for the release, subdirectories for each platform with the files set out however it suits the platform, another pseudo-platform with the bare sources/image/changelog/readme and quite possibly links from within the platform subtrees back to those 'originals'.
f) in cases where the same file is used in several releases - such as the .sources, obviously - use a link if possible so it really is the same file.

Proffered pseudo-tree on squeak.org
release_wibble/
rawfiles/
release_wibble-2768.image
release_wibble-2768.changes
release_wibble-2768.sources
RISC_OS/
squeak.image (linked to ../rawfiles/release_wibble-2768.image)
etc
!Squeak/
!RunImage
sources (linked to ../../rawfiles/release_wibble-2768.sources)
plugins/
etc
etc
squeak.changes
release_duckfart/
rawfiles/
release_duckfart-6502.image
release_duckfart-6502.changes
release_duckfart-6502.sources (linked to ../../release_wibble/release_wibble-2768.sources)
RISC_OS/
squeak.image (linked to ../rawfiles/release_duckfart-6502.image)
etc
!Squeak/
!RunImage
sources (linked to ../../rawfiles/release_duckfart-6502.sources)
plugins/
etc
etc
squeak.changes

Yes, if you dump the image and changes in the same directory as a previous pair you might have a problem with overwriting them. But since you really ought to be saving the 'virgin' files somewhere safe, starting up the new image and immediately saving it under a meaningful name in a working directory, that shouldn't happen.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
.signature not found! reformat hard drive? [Yn]

David T. Lewis

Re: Squeak 4.4 Question

In reply to this post by bpi

I don't know anything about buildpacks or Heroku, but the image knows the
name of the sources file it wants to use, so if your shell script is able
to run Squeak you can just ask the image what it wants. Example script
attached.

<OT>
That reminds me, we really should have a way to just feed a start script
directly to the image through stdin rather than messing around with
files on disk. Maybe a VM command line parameter " - " that means "read
further input from stdin", similar to the way it is done with unix utilities
such as tar.
</OT>

Dave

On Thu, Jan 17, 2013 at 12:43:44AM +0100, Bernhard Pieber wrote:

> Hi Frank,
>
> Couldn't you just add another environment variable SQUEAK_SOURCES_VERSION to your buildpack?
>
> Cheers,
> Bernhard
>
> Am 16.01.2013 um 23:50 schrieb Frank Shearar:
>
> > On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote:
> >>
> >> On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote:
> >>
> >>> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote:
> >>>> On 16/01/13 4:40 AM, Frank Shearar wrote:
> >>>>>
> >>>>>
> >>>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are
> >>>>> identical to the V41 sources, but I've realised that for automating
> >>>>> things you REALLY REALLY want to have the sources file name derivable
> >>>>> from the Squeak version. At some point I will need to make Squeak 4.4
> >>>>> look for a SqueakV44.sources file, and I've added an item to the todo
> >>>>> list to have Squeak 4.5 do this automatically as part of the release
> >>>>> cycle.
> >>>>
> >>>>
> >>>> Won't that cause further confusion - the same file named differently. I
> >>>> don't understand how a file name that never changes, can be a problem for
> >>>> automating a build.
> >>>
> >>> How can I derive "SqueakV41.sources" from "4.4"?
> >>
> >> If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking?
> >
> > Maybe I'm getting misunderstood because it's not clear that I'm
> > talking about the _names_ of files, not the contents.
> >
> > If I want to write a buildpack to deploy a Smalltalk application to
> > Heroku, I'll have an environment variable called SQUEAK_VERSION and
> > another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string
> > "4.4-12327". With that I can find out where exactly to find an image
> > tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a
> > simple string manipulation. But there is no easy, simple, reliable way
> > for me to say "oh, and the sources that corresponds to that is of
> > course called "SqueakV44.sources.gz" because my release process had a
> > bug in it. I really don't care whether the sources file for 4.4 is
> > condensed. I care that it _has_ a sources file, and I care that its
> > _name_ is trivially derivable/calculable from the version _name_.
> >
> > This isn't a hypothetical question about a maybe thing. I have the
> > buildpack right now. I just can't finish it because I can't write a
> > script to find the sources file. (Scraping http://ftp.squeak.org/4.4/
> > for URLs is so made of fail that I'm not going to contemplate it.)
> >
> > frank
> >
> >> - Bert -
> >>
> >>> If I can't derive it,
> >>> how can a script? It was an error (on my part) to not produce a
> >>> SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due
> >>> course, but I need to leave the SqueakV41.sources there for the moment
> >>> because the current 4.4 looks for such a file. James Robertson
> >>> correctly pointed out that one usually has a .sources file, so we
> >>> should have such a thing.
> >>>
> >>>> IMHO, it should be left alone, unless the plan described by Bert is
> >>>> implemented. A "temporary" solution, often becomes permanent.
> >>>
> >>> The "temporary" part is keeping the SqueakV41.sources there until we
> >>> can be sure that 4.4 images won't look for that file, but for
> >>> SqueakV44.sources instead.
> >>>
> >>> frank
> >>
> >>
> >>
> >>
> >>
> >
>

echoSources (686 bytes) Download Attachment

Bert Freudenberg

Re: Squeak 4.4 Question

In reply to this post by Yanni Chiu

On 16.01.2013, at 15:39, Yanni Chiu <[hidden email]> wrote:

> On 16/01/13 6:05 PM, Bert Freudenberg wrote:
>>
>> And in case this hasn't been mentioned yet, the non-desctructive condense sources is this:
>>
>> Smalltalk appendChangesTo: 'test123.sources'
>
> So, should 4.4 be re-done, or does this get run from 4.5 onwards.

That's up to the release manager (but I thought 4.4 was done).

- Bert -

David T. Lewis

Re: Squeak 4.4 Question

In reply to this post by timrowledge

On Wed, Jan 16, 2013 at 03:59:55PM -0800, tim Rowledge wrote:

>
> On 16-01-2013, at 2:17 PM, Frank Shearar <[hidden email]> wrote:
> >
> > But I'm tired of arguing. Please propose a means that I can, with an
> > absolute minimum of effort find the sources file corresponding to a
> > given Squeak version, both for 4.4 and for arbitrary versions in the
> > future.
> >
> > I repeat: _all I want_ is a _simple_ correspondence between a released
> > Squeak and the source file that it needs. One that a shell script can
> > calculate. One that doesn't involve scraping links off a web page.
>
>
> My suggestion, for what it's worth -
> a) forget naming the individual files by version/update level etc (for releases - for ongoing work when updates are being loaded it makes some sense)
> b) name the *directories*

I think that naming the directories does make good sense.

In the case of an image file, it is handy to be able to look at the file
name to know where it comes from. But the first thing I ever do with any
new release image is open it and resave it as squeak.image. Later on I
will resave it as squeak.1.image and squeak.2.image and so on, so if the
release image was just called squeak.image and if it was distributed
in a directory that identified the release version, that would work fine
for me.

> c) document that users should keep the image/changes files for release numpty-ump in a directory separate to their files for release diddly-squat.

+1

> d) the best places to keep the VM and .sources file varies by platform. For OS X it could well make sense to keep it in VM bundle, though that might end up with a copy in each version of a VM during development. Disc is cheap, so is it really a problem? For RISC OS I've *always* kept the sources file inside the VM application folder (which is essentially what Apple copied the bundle idea from), For Windows and unices I have no idea what is best because I simply don't use them anymore. Would it make sense to put a suitable link in each release's directory, pointing back to a real file? Links are supposed to work, aren't they?

It would make sense, but unfortunately I don't think that links necessarily
work on all file systems. Most notably, memory sticks are often formatted
with lowest common denominator file systems (VFAT) that do not support
links. So it is not a good idea to rely on this.

> e) for release filesets stored on squeak.org I'd suggest a directory for the release, subdirectories for each platform with the files set out however it suits the platform, another pseudo-platform with the bare sources/image/changelog/readme and quite possibly links from within the platform subtrees back to those 'originals'.
> f) in cases where the same file is used in several releases - such as the .sources, obviously - use a link if possible so it really is the same file.
>
> Proffered pseudo-tree on squeak.org
> release_wibble/
> rawfiles/
> release_wibble-2768.image
> release_wibble-2768.changes
> release_wibble-2768.sources
> RISC_OS/
> squeak.image (linked to ../rawfiles/release_wibble-2768.image)
> etc
> !Squeak/
> !RunImage
> sources (linked to ../../rawfiles/release_wibble-2768.sources)
> plugins/
> etc
> etc
> squeak.changes
> release_duckfart/
> rawfiles/
> release_duckfart-6502.image
> release_duckfart-6502.changes
> release_duckfart-6502.sources (linked to ../../release_wibble/release_wibble-2768.sources)
> RISC_OS/
> squeak.image (linked to ../rawfiles/release_duckfart-6502.image)
> etc
> !Squeak/
> !RunImage
> sources (linked to ../../rawfiles/release_duckfart-6502.sources)
> plugins/
> etc
> etc
> squeak.changes
>
> Yes, if you dump the image and changes in the same directory as a previous pair you might have a problem with overwriting them. But since you really ought to be saving the 'virgin' files somewhere safe, starting up the new image and immediately saving it under a meaningful name in a working directory, that shouldn't happen.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> .signature not found! reformat hard drive? [Yn]
>
>

timrowledge

Re: Squeak 4.4 Question

On 16-01-2013, at 4:40 PM, "David T. Lewis" <[hidden email]> wrote:
>> d) the best places to keep the VM and .sources file varies by platform. For OS X it could well make sense to keep it in VM bundle, though that might end up with a copy in each version of a VM during development. Disc is cheap, so is it really a problem? For RISC OS I've *always* kept the sources file inside the VM application folder (which is essentially what Apple copied the bundle idea from), For Windows and unices I have no idea what is best because I simply don't use them anymore. Would it make sense to put a suitable link in each release's directory, pointing back to a real file? Links are supposed to work, aren't they?
>
> It would make sense, but unfortunately I don't think that links necessarily
> work on all file systems. Most notably, memory sticks are often formatted
> with lowest common denominator file systems (VFAT) that do not support
> links. So it is not a good idea to rely on this.

That's an interesting point; I didn't know that FAT couldn't do links. Do links work within a zip or other archive format? If so, at least they're transmittable in some reasonably convenient fashion.

For unices I guess it makes sense to have the vm in some shared place, the sources file probably ditto, and image/changes pairs in user directories. That presumably implies an install script as part of the download, which would makes links as well. How does it cope with having more than one version installed, possibly requiring several different VMs and/or sources files?

Many years ago I used to have the old Archimedes Smalltalk stuff save the image/changes within application directories so that it was hard work to separate them. So, saving your image as 'fred' would create a !fred directory and copy the changes into !fred.changes and save the image as !fred.image. Remembering of course that RISC OS uses '.' as the directory separator.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Resistance is useless! (If << 1 ohm)

Frank Shearar-3

Re: Squeak 4.4 Question

In reply to this post by Bert Freudenberg

On 17 January 2013 00:22, Bert Freudenberg <[hidden email]> wrote:

>
> On 16.01.2013, at 15:39, Yanni Chiu <[hidden email]> wrote:
>
>> On 16/01/13 6:05 PM, Bert Freudenberg wrote:
>>>
>>> And in case this hasn't been mentioned yet, the non-desctructive condense sources is this:
>>>
>>> Smalltalk appendChangesTo: 'test123.sources'
>>
>> So, should 4.4 be re-done, or does this get run from 4.5 onwards.
>
>
> That's up to the release manager (but I thought 4.4 was done).
>
> - Bert -

4.4 is done, but of course if bugs are found then they need fixing,
which means occasional releases. People using Squeak in anger should
be using 4.4, not 4.5, so I expect/hope that we'll get bug reports for
4.4 from people _using_ Squeak, and bug reports for 4.5 from the core
devs.

frank

David T. Lewis

Re: Squeak 4.4 Question

In reply to this post by timrowledge

On Wed, Jan 16, 2013 at 06:45:13PM -0800, tim Rowledge wrote:

>
> On 16-01-2013, at 4:40 PM, "David T. Lewis" <[hidden email]> wrote:
> >> d) the best places to keep the VM and .sources file varies by platform. For OS X it could well make sense to keep it in VM bundle, though that might end up with a copy in each version of a VM during development. Disc is cheap, so is it really a problem? For RISC OS I've *always* kept the sources file inside the VM application folder (which is essentially what Apple copied the bundle idea from), For Windows and unices I have no idea what is best because I simply don't use them anymore. Would it make sense to put a suitable link in each release's directory, pointing back to a real file? Links are supposed to work, aren't they?
> >
> > It would make sense, but unfortunately I don't think that links necessarily
> > work on all file systems. Most notably, memory sticks are often formatted
> > with lowest common denominator file systems (VFAT) that do not support
> > links. So it is not a good idea to rely on this.
>
>
> That's an interesting point; I didn't know that FAT couldn't do links. Do links work within a zip or other archive format? If so, at least they're transmittable in some reasonably convenient fashion.
>

I think some versions of zip can handle symbolic links, but I don't know
if it is portable.

> For unices I guess it makes sense to have the vm in some shared place, the sources file probably ditto, and image/changes pairs in user directories. That presumably implies an install script as part of the download, which would makes links as well. How does it cope with having more than one version installed, possibly requiring several different VMs and/or sources files?
>

Yes, the unix VM is provided either in the form of an install script
(http://squeakvm.org/unix/release/Squeak-4.10.2.2614-linux_x86_64.sh) or
as a tar archive that has the necessary directory structure.

The VM runs from a shell script (e.g. /usr/local/bin/squeak) and that
script locates the subdirectory that contains the VM, plugins, etc.
These subdirectories are named based on version (VMMaker version and
SVN source version), and also based on whether the VM is for 32-bit or
64-bit images (the /usr/local/bin/squeak script figures that out too).

I think this is pretty much in line with the directory based naming
convention that you suggest. Among other things, this scheme makes
it very easy to go back to another version of the VM (just change the
script) or to install both Cog and interpreter VM on the same machine
(I personally keep separate /usr/local/bin/cog and /usr/local/bin/squeak
scripts but that's just my own personal convention).

The only down side is that an untidy person like myself can end up
wasting a lot of disk space.

Dave

> Many years ago I used to have the old Archimedes Smalltalk stuff save the image/changes within application directories so that it was hard work to separate them. So, saving your image as 'fred' would create a !fred directory and copy the changes into !fred.changes and save the image as !fred.image. Remembering of course that RISC OS uses '.' as the directory separator.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Resistance is useless! (If << 1 ohm)
>
>

Frank Shearar-3

Re: Squeak 4.4 Question

In reply to this post by bpi

On 16 January 2013 23:43, Bernhard Pieber <[hidden email]> wrote:
> Hi Frank,
>
> Couldn't you just add another environment variable SQUEAK_SOURCES_VERSION to your buildpack?

Hi Bernhard,

There are any number of ugly hacks I could do, but I'd really rather
do it _right_. Putting the wrong sources file with an image causes
horrible problems, so having a manual setting up of this link means
one more thing that someone can easily get wrong.

frank

> Cheers,
> Bernhard
>
> Am 16.01.2013 um 23:50 schrieb Frank Shearar:
>
>> On 16 January 2013 22:31, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 16.01.2013, at 06:24, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 16 January 2013 14:02, Yanni Chiu <[hidden email]> wrote:
>>>>> On 16/01/13 4:40 AM, Frank Shearar wrote:
>>>>>>
>>>>>>
>>>>>> I have _also_ put files called SqueakV44.sources(.gz|zip). These are
>>>>>> identical to the V41 sources, but I've realised that for automating
>>>>>> things you REALLY REALLY want to have the sources file name derivable
>>>>>> from the Squeak version. At some point I will need to make Squeak 4.4
>>>>>> look for a SqueakV44.sources file, and I've added an item to the todo
>>>>>> list to have Squeak 4.5 do this automatically as part of the release
>>>>>> cycle.
>>>>>
>>>>>
>>>>> Won't that cause further confusion - the same file named differently. I
>>>>> don't understand how a file name that never changes, can be a problem for
>>>>> automating a build.
>>>>
>>>> How can I derive "SqueakV41.sources" from "4.4"?
>>>
>>> If we're doing the non-destructive source condensing resulting in a SqueakV44.sources file, then the same file linked or renamed to SqueakV41.sources can be used by a 4.1/4.2/4.3 image. Is that what you're asking?
>>
>> Maybe I'm getting misunderstood because it's not clear that I'm
>> talking about the _names_ of files, not the contents.
>>
>> If I want to write a buildpack to deploy a Smalltalk application to
>> Heroku, I'll have an environment variable called SQUEAK_VERSION and
>> another called BUILDPACK_SQUEAK_BASE_URL. That will contain the string
>> "4.4-12327". With that I can find out where exactly to find an image
>> tarball - http://ftp.squeak.org/4.4/Squeak4.4-12327.zip - with a
>> simple string manipulation. But there is no easy, simple, reliable way
>> for me to say "oh, and the sources that corresponds to that is of
>> course called "SqueakV44.sources.gz" because my release process had a
>> bug in it. I really don't care whether the sources file for 4.4 is
>> condensed. I care that it _has_ a sources file, and I care that its
>> _name_ is trivially derivable/calculable from the version _name_.
>>
>> This isn't a hypothetical question about a maybe thing. I have the
>> buildpack right now. I just can't finish it because I can't write a
>> script to find the sources file. (Scraping http://ftp.squeak.org/4.4/
>> for URLs is so made of fail that I'm not going to contemplate it.)
>>
>> frank
>>
>>> - Bert -
>>>
>>>> If I can't derive it,
>>>> how can a script? It was an error (on my part) to not produce a
>>>> SqueakV44.sources. I'll be fixing that in the 4.4 update stream in due
>>>> course, but I need to leave the SqueakV41.sources there for the moment
>>>> because the current 4.4 looks for such a file. James Robertson
>>>> correctly pointed out that one usually has a .sources file, so we
>>>> should have such a thing.
>>>>
>>>>> IMHO, it should be left alone, unless the plan described by Bert is
>>>>> implemented. A "temporary" solution, often becomes permanent.
>>>>
>>>> The "temporary" part is keeping the SqueakV41.sources there until we
>>>> can be sure that 4.4 images won't look for that file, but for
>>>> SqueakV44.sources instead.
>>>>
>>>> frank
>>>
>>>
>>>
>>>
>>>
>>
>
>

Bert Freudenberg

Re: Squeak 4.4 Question

In reply to this post by Frank Shearar-3

On 17.01.2013, at 02:03, Frank Shearar <[hidden email]> wrote:

> On 17 January 2013 00:22, Bert Freudenberg <[hidden email]> wrote:
>>
>> On 16.01.2013, at 15:39, Yanni Chiu <[hidden email]> wrote:
>>
>>> On 16/01/13 6:05 PM, Bert Freudenberg wrote:
>>>>
>>>> And in case this hasn't been mentioned yet, the non-desctructive condense sources is this:
>>>>
>>>> Smalltalk appendChangesTo: 'test123.sources'
>>>
>>> So, should 4.4 be re-done, or does this get run from 4.5 onwards.
>>
>>
>> That's up to the release manager (but I thought 4.4 was done).
>>
>> - Bert -
>
> 4.4 is done, but of course if bugs are found then they need fixing,
> which means occasional releases. People using Squeak in anger should
> be using 4.4, not 4.5, so I expect/hope that we'll get bug reports for
> 4.4 from people _using_ Squeak, and bug reports for 4.5 from the core
> devs.
>
> frank

Yes, but the sources thing isn't really a bug needing an immediate fix, is it?

- Bert -

Frank Shearar-3

Re: Squeak 4.4 Question

No, it's not an emergency. It means an ugly hack in my build pack. It is something I want fixed in 4.5 though.

frank

On 17 Jan 2013, at 15:26, Bert Freudenberg <[hidden email]> wrote:

>
> On 17.01.2013, at 02:03, Frank Shearar <[hidden email]> wrote:
>
>> On 17 January 2013 00:22, Bert Freudenberg <[hidden email]> wrote:
>>>
>>> On 16.01.2013, at 15:39, Yanni Chiu <[hidden email]> wrote:
>>>
>>>> On 16/01/13 6:05 PM, Bert Freudenberg wrote:
>>>>>
>>>>> And in case this hasn't been mentioned yet, the non-desctructive condense sources is this:
>>>>>
>>>>> Smalltalk appendChangesTo: 'test123.sources'
>>>>
>>>> So, should 4.4 be re-done, or does this get run from 4.5 onwards.
>>>
>>>
>>> That's up to the release manager (but I thought 4.4 was done).
>>>
>>> - Bert -
>>
>> 4.4 is done, but of course if bugs are found then they need fixing,
>> which means occasional releases. People using Squeak in anger should
>> be using 4.4, not 4.5, so I expect/hope that we'll get bug reports for
>> 4.4 from people _using_ Squeak, and bug reports for 4.5 from the core
>> devs.
>>
>> frank
>
> Yes, but the sources thing isn't really a bug needing an immediate fix, is it?
>
> - Bert -
>
>
>

timrowledge

Re: Squeak 4.4 Question

In reply to this post by David T. Lewis

On 17-01-2013, at 4:05 AM, "David T. Lewis" <[hidden email]> wrote:
>
>
> The only down side is that an untidy person like myself can end up
> wasting a lot of disk space.

And at C$50/Tb that is how much of a practical problem :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Like, no bother man.." said Pooh as he spaced out on hash