are in http://www.mirandabanda.org/files/Cog/VM/VM.r2749/.
CogVM binaries as per VMMaker.oscog-eem.302/r2749
Fix bad performance regression that on certain platforms (linux) results in all send misses causing a discarded PIC creation followed by a slow hash lookup.
Fix bug when assigning to some context inst vars from generated methods. Add accessors to document the context inst var access scheme. Fix a compiler warning comparing an error code in cog:selector:
Update the BitBltPlugin to include the fast Arm ASM option.
Fix type errors in the Cogit that prevent the Cogit working when compiled with clang. Specifically void * pointers are not comparable. Make sure that fetchPointer:ofObject: & isIntegerValue: are declared in cointerp.h.
Update the Newspeak version of the VMProfileLinuxSupportPlugin. Improve robustness of the nscogbuild/unixbuild mvm scripts.
Add the linux policy change dance to sqUnixVMProfile.c (cf sqUnixHeartbeat.c). Fix a bail_out typo.
Change the VMProfileLinuxSupportPlugin to follow symlinks, answering pairs of module name, dereferenced symlink or nil.
Fix 3 (!!) bugs in primitiveDLSymInLibrary.
On Mon, Jul 15, 2013 at 05:35:36PM -0700, Eliot Miranda wrote:
Thanks Eliot!
Dave
CogVM binaries as per VMMaker.oscog-eem.302/r2749
Fix bad performance regression that on certain platforms (linux) results in all send misses causing a discarded PIC creation followed by a slow hash lookup.
Fix bug when assigning to some context inst vars from generated methods. Add accessors to document the context inst var access scheme. Fix a compiler warning comparing an error code in cog:selector:
Update the BitBltPlugin to include the fast Arm ASM option.
Fix type errors in the Cogit that prevent the Cogit working when compiled with clang. Specifically void * pointers are not comparable. Make sure that fetchPointer:ofObject: & isIntegerValue: are declared in cointerp.h.
Update the Newspeak version of the VMProfileLinuxSupportPlugin. Improve robustness of the nscogbuild/unixbuild mvm scripts.
Add the linux policy change dance to sqUnixVMProfile.c (cf sqUnixHeartbeat.c). Fix a bail_out typo.
Change the VMProfileLinuxSupportPlugin to follow symlinks, answering pairs of module name, dereferenced symlink or nil.
Fix 3 (!!) bugs in primitiveDLSymInLibrary.
-- best, Eliot
On 16 July 2013 01:35, Eliot Miranda eliot.miranda@gmail.com wrote:
I've upgraded the build scripts for build.squeak.org accordingly. Thanks!
frank
Frank Shearar-3 wrote
On 16 July 2013 01:35, Eliot Miranda <
eliot.miranda@
> wrote:
I've upgraded the build scripts for build.squeak.org accordingly. Thanks!
frank
Should I make a new all-in-one?
-- View this message in context: http://forum.world.st/CogVM-binaries-as-per-VMMaker-oscog-eem-302-r2749-tp46... Sent from the Squeak - Dev mailing list archive at Nabble.com.
On 17 July 2013 02:15, Paul DeBruicker pdebruic@gmail.com wrote:
Frank Shearar-3 wrote
On 16 July 2013 01:35, Eliot Miranda <
eliot.miranda@
> wrote:
I've upgraded the build scripts for build.squeak.org accordingly. Thanks!
frank
Should I make a new all-in-one?
That sounds like a good idea. If it's an automated process, we can set up a CI build for it.
frank
Hi Frank,
Frank Shearar-3 wrote
On 17 July 2013 02:15, Paul DeBruicker <
pdebruic@
> wrote:
Frank Shearar-3 wrote
On 16 July 2013 01:35, Eliot Miranda <
eliot.miranda@
> wrote:
I've upgraded the build scripts for build.squeak.org accordingly. Thanks!
frank
Should I make a new all-in-one?
That sounds like a good idea. If it's an automated process, we can set up a CI build for it.
frank
Sorry for the delay to get back to you. I think it could be run by the CI system. Its just a bunch of bash scripts now. They are in this github repo:
https://github.com/pdebruic/Squeak-All-In-One
It does download the updated VMs but does not yet download new images.
To make a new all-in-one just
1. clone that repo 2. download and extract the image you want to use 3. edit the create4.4AllInOne script to reflect the new VM version info 4. run the create4.4AllInOne script.
If you want to automate the build I'd be happy to help. It may also be good to make 'bleeding-edge', latest-stable, and latest-release all-in-one builds. To do that we'd just need to get the proper images downloaded prior to making the all-in-one. My reason for opening bug 7752 was to make this easier on me. But there's probably another way to do it.
Let me know how I can help.
Paul
-- View this message in context: http://forum.world.st/CogVM-binaries-as-per-VMMaker-oscog-eem-302-r2749-tp46... Sent from the Squeak - Dev mailing list archive at Nabble.com.
Hi Eliot,
under Win7 64 Bit the upgrading from r2701 of March 11th I got a speedup from 575 to 231 seconds for my "CSV file reading using symbols to reduce memory consumption and speedup #select" job.
The average full gc came down from 811 to 450 ms (averaged over 19 GC's)
So the performance regression may have been in Windows VM's too.
Thanks a lot!
What I don't understand: I do a "purge undo records" then a GC. In both cases I get around 5MB less used Memory but Squeak uses some additional 68 MB (old VM) resp 73 MB (new VM). Total Memory after GC is around 445 MB in both cases. Is this to be expected and wouldn't happen if the image size were closer to the 512 MB Limit of Windows?
Cheers
Herbert
Am 16.07.2013 02:35, schrieb Eliot Miranda:
are in http://www.mirandabanda.org/files/Cog/VM/VM.r2749/.
CogVM binaries as per VMMaker.oscog-eem.302/r2749
Fix bad performance regression that on certain platforms (linux) results in all send misses causing a discarded PIC creation followed by a slow hash lookup.
Fix bug when assigning to some context inst vars from generated methods. Add accessors to document the context inst var access scheme. Fix a compiler warning comparing an error code in cog:selector:
Update the BitBltPlugin to include the fast Arm ASM option.
Fix type errors in the Cogit that prevent the Cogit working when compiled with clang. Specifically void * pointers are not comparable. Make sure that fetchPointer:ofObject: & isIntegerValue: are declared in cointerp.h.
Update the Newspeak version of the VMProfileLinuxSupportPlugin. Improve robustness of the nscogbuild/unixbuild mvm scripts.
Add the linux policy change dance to sqUnixVMProfile.c (cf sqUnixHeartbeat.c). Fix a bail_out typo.
Change the VMProfileLinuxSupportPlugin to follow symlinks, answering pairs of module name, dereferenced symlink or nil.
Fix 3 (!!) bugs in primitiveDLSymInLibrary.
-- best, Eliot
On Thu, Jul 25, 2013 at 12:18 PM, Herbert König herbertkoenig@gmx.netwrote:
Hi Eliot,
under Win7 64 Bit the upgrading from r2701 of March 11th I got a speedup from 575 to 231 seconds for my "CSV file reading using symbols to reduce memory consumption and speedup #select" job.
The average full gc came down from 811 to 450 ms (averaged over 19 GC's)
So the performance regression may have been in Windows VM's too.
Thanks a lot!
What I don't understand: I do a "purge undo records" then a GC. In both cases I get around 5MB less used Memory but Squeak uses some additional 68 MB (old VM) resp 73 MB (new VM). Total Memory after GC is around 445 MB in both cases. Is this to be expected and wouldn't happen if the image size were closer to the 512 MB Limit of Windows?
The Cog VM keeps a lot more memory around in reserve. It has a machine code zone, a larger new space and a reserve for flushing the stack zone to the heap as contexts that the standard VM doesn't use. (all of these extras are part of the standard linear heap segment). So the disparity is to be expected.
Cheers
Herbert
cheers!
Am 16.07.2013 02:35, schrieb Eliot Miranda:
are in http://www.mirandabanda.org/files/Cog/VM/VM.r2749/.
CogVM binaries as per VMMaker.oscog-eem.302/r2749
Fix bad performance regression that on certain platforms (linux) results in all send misses causing a discarded PIC creation followed by a slow hash lookup.
Fix bug when assigning to some context inst vars from generated methods. Add accessors to document the context inst var access scheme. Fix a compiler warning comparing an error code in cog:selector:
Update the BitBltPlugin to include the fast Arm ASM option.
Fix type errors in the Cogit that prevent the Cogit working when compiled with clang. Specifically void * pointers are not comparable. Make sure that fetchPointer:ofObject: & isIntegerValue: are declared in cointerp.h.
Update the Newspeak version of the VMProfileLinuxSupportPlugin. Improve robustness of the nscogbuild/unixbuild mvm scripts.
Add the linux policy change dance to sqUnixVMProfile.c (cf sqUnixHeartbeat.c). Fix a bail_out typo.
Change the VMProfileLinuxSupportPlugin to follow symlinks, answering pairs of module name, dereferenced symlink or nil.
Fix 3 (!!) bugs in primitiveDLSymInLibrary.
-- best, Eliot
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
* Take a base image (currently 4.5-12565), update it, archive the result. * Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Dave
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
frank
Dave
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the
result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
On 28 July 2013 18:58, H. Hirzel hannes.hirzel@gmail.com wrote:
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the
result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
Thank you Frank for the explanation, I consider it to be a useful metaphor.
"rehydrated" image vs. "dehydrated" image
--Hannes
On 7/28/13, Frank Shearar frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
"rehydrated" = ReleaseSqueakTrunk http://build.squeak.org/job/ReleaseSqueakTrunk/
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk.
"dehydrated" = SqueakTrunk http://build.squeak.org/job/SqueakTrunk/
ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
On 28 July 2013 18:58, H. Hirzel hannes.hirzel@gmail.com wrote:
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the
result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
Is there a location to pull from that would keep my image up to date with the ReleaseSqueakTrunk version of Squeak? Or if I update my image, will parts start dissappearing?
Is the only way to continue to use the ReleaseSqueakTrunk to download occasional snapshots and move all the code into it?
Or is the trunk system still working off of the release version, but the SqueakTrunk job strips out the unloadable packages as part of its job? and then the ReleaseSqueakTrunk loads them back in?
I guess I could figure this our myself, but just in case anyone else is wondering, I'll ask.
-Chris
On Tue, Jul 30, 2013 at 7:13 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Thank you Frank for the explanation, I consider it to be a useful metaphor.
"rehydrated" image vs. "dehydrated" image
--Hannes
On 7/28/13, Frank Shearar frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
"rehydrated" = ReleaseSqueakTrunk http://build.squeak.org/job/ReleaseSqueakTrunk/
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk.
"dehydrated" = SqueakTrunk http://build.squeak.org/job/SqueakTrunk/
ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
On 28 July 2013 18:58, H. Hirzel hannes.hirzel@gmail.com wrote:
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org(InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base
Squeak
image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the
result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
On 30 July 2013 18:13, Chris Cunningham cunningham.cb@gmail.com wrote:
Is there a location to pull from that would keep my image up to date with the ReleaseSqueakTrunk version of Squeak? Or if I update my image, will parts start dissappearing?
Updating still works exactly as normal. Nothing will disappear from your image.
SqueakTrunk and ReleaseSqueakTrunk are the names for jobs on the continuous integration server, build.squeak.org. The update stream continues entirely unchanged.
Is the only way to continue to use the ReleaseSqueakTrunk to download occasional snapshots and move all the code into it?
Or is the trunk system still working off of the release version, but the SqueakTrunk job strips out the unloadable packages as part of its job? and then the ReleaseSqueakTrunk loads them back in?
Yes, but the stripping out part is manual. Well, it's scripted [1], and when a new package becomes unloadable I add it to the script, run the script against the "master" artifact for the SqueakTrunk job and publish it. The SqueakTrunk job then runs a bunch of tests against a copy of that image. After that, build.squeak.org fires off the ReleaseSqueakTrunk job. This takes the SqueakTrunk job's output, adds the packages unloaded in [1] through ReleaseBuilder class >> #prepareNewBuild (see #loadWellKnownPackages for the inverse of [1]'s list), and publishes an artifact. Periodically, someone pushes that artifact to ftp.squeak.org for public consumption. (This step still needs work.)
I guess I could figure this our myself, but just in case anyone else is wondering, I'll ask.
Sure! Questions are always welcome!
frank
[1] https://github.com/squeak-smalltalk/squeak-ci/blob/master/shrink-trunk.st
-Chris
On Tue, Jul 30, 2013 at 7:13 AM, H. Hirzel hannes.hirzel@gmail.com wrote:
Thank you Frank for the explanation, I consider it to be a useful metaphor.
"rehydrated" image vs. "dehydrated" image
--Hannes
On 7/28/13, Frank Shearar frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
"rehydrated" = ReleaseSqueakTrunk http://build.squeak.org/job/ReleaseSqueakTrunk/
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk.
"dehydrated" = SqueakTrunk http://build.squeak.org/job/SqueakTrunk/
ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
On 28 July 2013 18:58, H. Hirzel hannes.hirzel@gmail.com wrote:
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote: > I noticed that the VM tarball jobs on build.squeak.org > (InterpreterVM > and > CogVM jobs) have been failing for some time. These jobs use the > latest > trunk > image from the SqueakTrunk job, which is supposed to be a base > Squeak > image > updated from the trunk stream (see > http://build.squeak.org/job/SqueakTrunk/). > However, that image is missing the ST80 package entirely (which > indirectly > causes the VM tarball job failures). > > I tried to update the image (world menu -> help... -> update code > from > server) in hopes that this would load the missing packages, but > this > fails > due to some other problem. > > The project comment for the SqueakTrunk job says: > > * Take a base image (currently 4.5-12565), update it, archive the > result. > * Run the entire suite of in-image tests. > > I think that I had mistakenly assumed that the "SqueakTrunk" job > was > a > release > image updated from the trunk stream, but actually it must be a > stripped > "base" > image with packages reloaded, and maybe the reloading part has > forgotten > to > install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
On 7/28/13 3:22 PM, "Frank Shearar" frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
And when we go bold and use a Core.image? Our cousins Pharoers build a PharoKernel from sources , great work of Pavel and Guillermo (and others maybe).
Edgar
On 24 October 2013 22:02, Edgar J. De Cleene edgardec2005@gmail.com wrote:
On 7/28/13 3:22 PM, "Frank Shearar" frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
And when we go bold and use a Core.image? Our cousins Pharoers build a PharoKernel from sources , great work of Pavel and Guillermo (and others maybe).
When I have time, basically. I reconstructed the base image from scratch recently, and haven't had a chance to re-rip out Nebraska, Universes, and all the other bits I'd previously removed.
I'm very happy to see Pharo do this work. Kudos to Pavel & Guille & friends!
frank
Edgar
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
2013/10/25 Frank Shearar frank.shearar@gmail.com
On 24 October 2013 22:02, Edgar J. De Cleene edgardec2005@gmail.com wrote:
On 7/28/13 3:22 PM, "Frank Shearar" frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
And when we go bold and use a Core.image? Our cousins Pharoers build a PharoKernel from sources , great work of
Pavel
and Guillermo (and others maybe).
When I have time, basically. I reconstructed the base image from scratch recently, and haven't had a chance to re-rip out Nebraska, Universes, and all the other bits I'd previously removed.
I'm very happy to see Pharo do this work. Kudos to Pavel & Guille & friends!
frank
Edgar
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
The problems you are going to face are: 1) you need a good package delimitation, with clear contracts (on which package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
... And for C) I suggest we call the monster Phreak ;)
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list < squeak-dev@lists.squeakfoundation.org> Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
Inline one time
On Oct 25, 2013, at 6:21 AM, Nicolas Cellier nicolas.cellier.aka.nice@gmail.com wrote:
... And for C) I suggest we call the monster Phreak ;)
:D Phreak out! Which is admittedly a bit of a juxtaposition. All the same...
http://www.youtube.com/watch?v=xblSHz3Ugiw&feature=youtube_gdata_player
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo
- the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring
- since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
I know, Pavel.
If you want to see Squeak shrink faster, and finally catch up with your sterling work from ages ago, please take the image in http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip and see if I haven't broken anything. In particular, poke around the Parser, because Nicolas and I saw some problems in the update stream a while ago concerning Parser.
Because one of the most serious non-technical problems that Squeak has is lack of people.
frank
On 29 October 2013 08:42, Pavel Krivanek squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
On 29 October 2013 09:51, Frank Shearar frank.shearar@gmail.com wrote:
I know, Pavel.
If you want to see Squeak shrink faster, and finally catch up with your sterling work from ages ago, please take the image in http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip
And now with the correct URL: http://build.squeak.org/job/SqueakTrunk/lastSuccessfulBuild/artifact/target/...
frank
and see if I haven't broken anything. In particular, poke around the Parser, because Nicolas and I saw some problems in the update stream a while ago concerning Parser.
Because one of the most serious non-technical problems that Squeak has is lack of people.
frank
On 29 October 2013 08:42, Pavel Krivanek squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
Hi Frank,
spending few minutes on it, I was able to produce very very dirty image (4.6MB). I did only few small changes. Use patch002.st, I attach patch001.st only for diff purposes. I only tried to make it work somehow and made the resultant image responsive. I was not able to recompile all the classes so I simply used ifError: statement so many of methods is still not recompiled. That's one reason why the resultant image is so dirty. The script works on my Linux machine, no clue what will it do on Mac or Win. You should look at the patch002.st, compare patched methods with recent versions. Maybe some currently do not need any change. The patch does not provide good or final solutions, it only shows the most creaking places.
I can help but you should understand that for me it's time I steal from Pharo that has much higher priority for me. I do not understand what Squeak is now and what it wants to be and I do not know last changes in it.
-- Pavel
2013/10/29 Frank Shearar frank.shearar@gmail.com:
I know, Pavel.
If you want to see Squeak shrink faster, and finally catch up with your sterling work from ages ago, please take the image in http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip and see if I haven't broken anything. In particular, poke around the Parser, because Nicolas and I saw some problems in the update stream a while ago concerning Parser.
Because one of the most serious non-technical problems that Squeak has is lack of people.
frank
On 29 October 2013 08:42, Pavel Krivanek squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
Squeak wants to be a platform with support for legacy applications, and slow and smooth progress. Pharo explicitely cannot afford that (too expensive). It could also be the platform for rebasing Etoys, but I don't know what's up on this front.
2013/10/29 Pavel Krivanek squeak1@continentalbrno.cz
Hi Frank,
spending few minutes on it, I was able to produce very very dirty image (4.6MB). I did only few small changes. Use patch002.st, I attach patch001.st only for diff purposes. I only tried to make it work somehow and made the resultant image responsive. I was not able to recompile all the classes so I simply used ifError: statement so many of methods is still not recompiled. That's one reason why the resultant image is so dirty. The script works on my Linux machine, no clue what will it do on Mac or Win. You should look at the patch002.st, compare patched methods with recent versions. Maybe some currently do not need any change. The patch does not provide good or final solutions, it only shows the most creaking places.
I can help but you should understand that for me it's time I steal from Pharo that has much higher priority for me. I do not understand what Squeak is now and what it wants to be and I do not know last changes in it.
-- Pavel
2013/10/29 Frank Shearar frank.shearar@gmail.com:
I know, Pavel.
If you want to see Squeak shrink faster, and finally catch up with your sterling work from ages ago, please take the image in http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip and see if I haven't broken anything. In particular, poke around the Parser, because Nicolas and I saw some problems in the update stream a while ago concerning Parser.
Because one of the most serious non-technical problems that Squeak has is lack of people.
frank
On 29 October 2013 08:42, Pavel Krivanek squeak1@continentalbrno.cz
wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the
package that
you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for
working
around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than
building on
top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits
alive.
That means switching from old file system to new one, switching from
old
text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but
keep
your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then
you'll end
up with Squeak, just a different Squeak, and unless you enjoy jumping
many
hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.orgbroken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make
removed
parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak
working
on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
Hi Pavel,
Thanks for that! I'll definitely dig into this.
frank
On 29 October 2013 11:11, Pavel Krivanek squeak1@continentalbrno.cz wrote:
Hi Frank,
spending few minutes on it, I was able to produce very very dirty image (4.6MB). I did only few small changes. Use patch002.st, I attach patch001.st only for diff purposes. I only tried to make it work somehow and made the resultant image responsive. I was not able to recompile all the classes so I simply used ifError: statement so many of methods is still not recompiled. That's one reason why the resultant image is so dirty. The script works on my Linux machine, no clue what will it do on Mac or Win. You should look at the patch002.st, compare patched methods with recent versions. Maybe some currently do not need any change. The patch does not provide good or final solutions, it only shows the most creaking places.
I can help but you should understand that for me it's time I steal from Pharo that has much higher priority for me. I do not understand what Squeak is now and what it wants to be and I do not know last changes in it.
-- Pavel
2013/10/29 Frank Shearar frank.shearar@gmail.com:
I know, Pavel.
If you want to see Squeak shrink faster, and finally catch up with your sterling work from ages ago, please take the image in http://build.squeak.org/job/SqueakTrunk/573/artifact/*zip*/archive.zip and see if I haven't broken anything. In particular, poke around the Parser, because Nicolas and I saw some problems in the update stream a while ago concerning Parser.
Because one of the most serious non-technical problems that Squeak has is lack of people.
frank
On 29 October 2013 08:42, Pavel Krivanek squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
2013/10/25 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
The problems you are going to face are:
- you need a good package delimitation, with clear contracts (on which
package/API do I depend?) both in the Squeak image (to save the package that you want to see reloaded) and in Pharo 2) the package delimitation has to be in good agreement, because the MC tools do not deal with package refactoring 3) since API are not in agreement, you gonna need plenty of glue for working around changes like trimBoth, includesSubstring: etc...
What are your goals exactly?
A) you want to build on top of smaller kernel? Then once you have 1), why should you go into Pharo rather than building on top of your Squeak kernel?
B) you want to profit by clean-ups and refactorings and shiny new architecture made in Pharo? Then yes, porting some interesting Squeak bits to Pharo has some value. But that means you spend a lot of efforts for maintaining those bits alive. That means switching from old file system to new one, switching from old text system to (yet future) new one, switching to Spec, switching to Settings, Announcements etc...
C) You have no specific goals, just want to follow the momentum, but keep your confortable Squeak slippers? If you end up with hacks for loading all the old Squeak mud, then you'll end up with Squeak, just a different Squeak, and unless you enjoy jumping many hurdles, I don't see the point.
2013/10/25 Edgar De Cleene edgardec2005@gmail.com
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Fri, 25 Oct 2013 14:06:43 +0200 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
Yes, Pharo is doing a great work of simplification. On the other hand, it deliberately has zero requirements to make removed parts reloadable, so the task is a bit easier...
Still exploring and understanding his system, but reporting ReferenceStream to Pharo 2.0 and having DependencyBrowser of Squeak working on it, a long time work could be put our view of Morphic on top of his kernel.
Or Cuis Morph hierarchy.
Edgar
On 10/29/13, 5:42 AM, "Pavel Krivanek" squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
I take your mail for say MUCHAS GRACIAS for your work of all this years. Extend to Guillermo and other people working on Hazelnut, Seed and related. Wish know if you have a special list for this, Pharo list this days send too many mails and los my focus.
To Nicolas, maybe I'm Dr. Frankenstein and like to build a Creature of best parts of Squeak , Pharo and Cuis.
What I wish.
Kind of backwards compatibility which Pharo and Cuis lack now. That do not means you must have a bad system. Juan have a beautiful system and if I'm was younger stick to Cuis
Pharo seems the most serious, but again, change too fast to my taste.
This Wednesday we start Smalltalks 2013 here in Rosario
http://www.fast.org.ar/smalltalks2013
So I take the opportunity to talk face to face with bright people.
Edgar
I don't say it's not possible, especially if you stay concentrated on one distribution, It's perfectly do-able, and I wish success to the 3 main branches, Cuis Pharo Squeak.
What I say is that transporting packages from one distribution to another is a tremendous work. Even if we have cleaned inter-package dependencies (most of this hardwork effectively comes from Pavel in Squeak/Pharo branches), we have to suffer from - different choices for some basic API (includeSubstring: as example) - different delimitation of packages (Take Pharo Text-Scanning as example) - total lack of support from Monticello
I sometimes tries to port some low level code (Kernel, Graphics, Morphic, Collection) from one distribution to another, and often resort to using change sets, MC just do not work.
Even if we would improve tools, the first two points depend on a minimum of coordination, and it's not in the mood of Pharo developers. Pharo want to be free of these chains, because it has to win a sprint: - clean up the maximum of dust before the system is frozen by large user base... It's not a critic, I perfectly understand this position, it's a deliberate choice.
Nicolas
2013/10/29 Edgar J. De Cleene edgardec2005@gmail.com
On 10/29/13, 5:42 AM, "Pavel Krivanek" squeak1@continentalbrno.cz wrote:
Hi Nicolas,
for Squeak we were able to shrink the system to a small kernel and reload and initialize the Morphic back long ago. In 2006. Two years before Pharo started to exist. The reason why Pharo can do it now and Squeak not is not technical.
Cheers, -- Pavel
I take your mail for say MUCHAS GRACIAS for your work of all this years. Extend to Guillermo and other people working on Hazelnut, Seed and related. Wish know if you have a special list for this, Pharo list this days send too many mails and los my focus.
To Nicolas, maybe I'm Dr. Frankenstein and like to build a Creature of best parts of Squeak , Pharo and Cuis.
What I wish.
Kind of backwards compatibility which Pharo and Cuis lack now. That do not means you must have a bad system. Juan have a beautiful system and if I'm was younger stick to Cuis
Pharo seems the most serious, but again, change too fast to my taste.
This Wednesday we start Smalltalks 2013 here in Rosario
http://www.fast.org.ar/smalltalks2013
So I take the opportunity to talk face to face with bright people.
Edgar
De: Nicolas Cellier nicolas.cellier.aka.nice@gmail.com Responder a: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Fecha: Tue, 29 Oct 2013 11:38:56 +0100 Para: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Asunto: Re: [squeak-dev] SqueakTrunk image on build.squeak.org broken?
What I say is that transporting packages from one distribution to another is a tremendous work.
Yes. This is my point also. If you wish port old Squeak packages (and some not too old) to Cuis or Pharo, take long time and lot of work.
I sometimes tries to port some low level code (Kernel, Graphics, Morphic, Collection) from one distribution to another, and often resort to using change sets, MC just do not work.
Well, back in the 3.10 times also think some things could not be made with MC. Andreas prove me was wrong and you could do difficult things with MC.
But maybe we should try resurrect DeltaStreams or MC2 and see if works better. I not against ChangeSets, in fact when I have time try to make all change sets from Trunk era and put somewhere for Bob collect in his system
Edgar
And the work you're doing is absolutely stellar in this respect, but your metaphors are grotesque. I have a small amount of experience with marketing, do hit me up please?
:D
On Jul 28, 2013, at 11:22 AM, Frank Shearar frank.shearar@gmail.com wrote:
It's a term I picked up from work: SqueakTrunk is like a dessicated, dried out thing that's quite small, like a dessicated pea. But ReleaseSqueakTrunk is like the rehydrated pea, useful for cooking.
As the package layering work proceeds, and more packages become unloadable, I unload them from SqueakTrunk. ReleaseSqueakTrunk takes that small SqueakTrunk artifact and reloads all those unloadable packages.
The idea is that people just keep on using the ReleaseSqueakTrunk image, and without even realising it, are using a _constructed_ image, built up from some small core.
frank
On 28 July 2013 18:58, H. Hirzel hannes.hirzel@gmail.com wrote:
Question of clarification:
What do you mean by a 'rehydrated image'?
--HH
On 7/28/13, David T. Lewis lewis@mail.msen.com wrote:
On Sun, Jul 28, 2013 at 08:26:18AM +0100, Frank Shearar wrote:
On 28 July 2013 07:24, David T. Lewis lewis@mail.msen.com wrote:
I noticed that the VM tarball jobs on build.squeak.org (InterpreterVM and CogVM jobs) have been failing for some time. These jobs use the latest trunk image from the SqueakTrunk job, which is supposed to be a base Squeak image updated from the trunk stream (see http://build.squeak.org/job/SqueakTrunk/). However, that image is missing the ST80 package entirely (which indirectly causes the VM tarball job failures).
I tried to update the image (world menu -> help... -> update code from server) in hopes that this would load the missing packages, but this fails due to some other problem.
The project comment for the SqueakTrunk job says:
- Take a base image (currently 4.5-12565), update it, archive the
result.
- Run the entire suite of in-image tests.
I think that I had mistakenly assumed that the "SqueakTrunk" job was a release image updated from the trunk stream, but actually it must be a stripped "base" image with packages reloaded, and maybe the reloading part has forgotten to install ST80. Is that right?
Yes. ReleaseSqueakTrunk contains a rehydrated/full fat Squeak image _with_ ST80 and friends loaded.
Sorry! I should have noticed the failing builds and connected that with the recent stripping of ST80.
Not at all, it was not obvious that this was connected to the problem.
I guess that once the package reorganizing settles down, it would be good to have some kind of sanity-check test to ensure that a rehydrated image contains the expected set of packages.
Dave
squeak-dev@lists.squeakfoundation.org
-
Casey Ransberger -
Chris Cunningham -
David T. Lewis -
Edgar De Cleene -
Edgar J. De Cleene
-
Eliot Miranda -
Frank Shearar -
H. Hirzel -
Herbert König -
Nicolas Cellier -
Paul DeBruicker -
Pavel Krivanek