[squeak-dev] How to get a Trunk image

Hi,

I would like to get the latest development version of Squeak (based on
the trunk?). Where can I find an image or how can I update an old
image?

Bye

--
Damien Cassou
http://damiencassou.seasidehosting.st

"Lambdas are relegated to relative obscurity until Java makes them
popular by not having them." James Iry

> Damien Cassou:
> I would like to get the latest development version of Squeak
> (based on the trunk?). Where can I find an image or how can I
> update an old image?

> Andreas Raab:
> The easiest way to get going is to fetch the image from
> http://squeakvm.org/win32/release/Squeak-3.10.2-trunk.zip and in there
> just hit the "Load code from server" button.

Just a note, I'm using current trunk image and am loading in toolsets
as in Damien's dev and web packages, mostly everything works with a
few tweaks here and there.

At the moment I'm trying to figure out why PrimitiveNode got taken out of
the Compiler package - that's breaking the OB-refactory tools.  Ideas?


Kevin

I got started with Andreas' image which I found here:
http://www.nabble.com/-squeak-dev--Closures-in-Trunk-td24554425.html

It has a convenient "Update" button :)

--
Regards,
Tim

On 7 Sep 2009, at 17:20, Damien Cassou wrote:

Damien is right.
We need an official place for accessing the latest-and-greatest trunk image.
My suggestion that it should be downloadable from squeak.org site.

Ken, Andreas, Janko?

--
Best regards,
Igor Stasenko AKA sig.

Damien Cassou wrote:
> I would like to get the latest development version of Squeak (based on
> the trunk?). Where can I find an image or how can I update an old
> image?

You have three choices:

1) Preloaded (but not fully up-to-date):

    http://squeakvm.org/win32/release/Squeak-3.10.2-trunk.zip

Download it and hit "load code updates". There will be one point where
you have to "merge" due to an MC confusion about class vars order.
Either choice is fine, just continue through it.

2) From 3.10 / 3.10.2:

    http://ftp.squeak.org/3.10/Squeak3.10-7159-basic.zip
    http://ftp.squeak.org/3.10/Squeak3.10.2-7179-basic.zip

Download either one of the above, then:
    - Install *just* MonticelloConfigurations-ar.39.mcz from the trunk
      (this fixes the problems with MCMs)
    - Load or Merge *just* update-ar.3.mcm (the prior two maps
      correspond to 3.10 and 3.10.2 and are there for housekeeping)
    - Execute the following code:
      MethodContext instVarNames at: 2 put: 'closureOrNil'.
    - Choose Help>>"update from server"
This process will take you trough the closure conversion as well.

3) From your own image:

If your image is 3.10-based it should work with the above instructions.
The only situations to keep in mind that can be problematic is if your
image has custom modifications to any of the core packages.

If you have a pre-3.10 image, I'm not sure how well the process will
work but the main issue is then probably in loading the first
update.mcm, so you might try to get yourself in sync with 3.10 first.

Cheers,
   - Andreas

On 9/7/09 12:20 PM, "Damien Cassou" <[hidden email]> wrote:

> Hi,
>
> I would like to get the latest development version of Squeak (based on
> the trunk?). Where can I find an image or how can I update an old
> image?
>
> Bye

I have a complete flow from Squeak3.10-7159-basic in .cs for each .mcz.
Also change the SystemVersion current highestUpdate and the version , as we
have too much different to this image/
For me, I have a Squeak3.11-alpha.7335.image which could put in Ftp and also
produce all .cs , for people like me feeling more confortable with .cs.

Squeak members, do not thing is time to do this ?
Or we plan keep 3.10.2 forever and SystemVersion is still 7179 no matter
system is very different?

Edgar

On Mon, Sep 07, 2009 at 03:49:24PM -0300, Edgar J. De Cleene wrote:
Edgar,

That sounds like a very good thing. How did you produce the .cs for each .mcz?

Dave

On 9/7/09 4:34 PM, "David T. Lewis" <[hidden email]> wrote:

I attach the first .cs , the rest is made automatic.
In this I do not change any and do not put any different to trunk.
The .cs with number > 7173 could be exported from the image and the change
to for have the SystemVersion current highestUpdate rising without changing
others MC loads could be made different, off course.
If Board agree , I put all, the .cs and the Squeak3.11-alpha.7335.image in
my folder for some could polish and put in a best place.

Edgar

Hi Edgar,

    if you have code that generates a .cs from two .mcz's are you
willing to share it?  That would be very useful code indeed.

On Mon, Sep 7, 2009 at 1:16 PM, Edgar J. De
Cleene<[hidden email]> wrote:

2009/9/7 Eliot Miranda <[hidden email]>:
> Hi Edgar,
>
>    if you have code that generates a .cs from two .mcz's are you
> willing to share it?  That would be very useful code indeed.
>
whenever you loading a new MC package in squeak,
it automatically creating a new changeset with the name of loaded package.
So, the only thing you need to do is to file out it into file and
rename it using
a proper numeric version.



--
Best regards,
Igor Stasenko AKA sig.

On 9/7/09 4:34 PM, "David T. Lewis" <[hidden email]> wrote:

>> I have a complete flow from Squeak3.10-7159-basic in .cs for each ..mcz.
>> Also change the SystemVersion current highestUpdate and the version , as we
>> have too much different to this image/
>> For me, I have a Squeak3.11-alpha.7335.image which could put in Ftp and also
>> produce all .cs , for people like me feeling more confortable with .cs.
>
> Edgar,
>
> That sounds like a very good thing. How did you produce the .cs for each .mcz?
>
> Dave


I attach the first .cs , the rest is made automatic.
In this I do not change any and do not put any different to trunk.
The .cs with number > 7173 could be exported from the image and the change to for have the SystemVersion current highestUpdate rising without changing others MC loads could be made different, off course.
If Board agree , I put all, the .cs and the Squeak3.11-alpha.7335.image in my folder for some could polish and put in a best place.

Edgar

Here was the right .cs, forget the previous mail.

On Mon, Sep 7, 2009 at 1:35 PM, Igor Stasenko<[hidden email]> wrote:
Doh!  Thanks!

Hi Edgar -

As a meta comment, I think we're discussing two separate issues here.

One is how to label the image properly. I'd say that given we're using
Monticello, the update number is somewhat useless in this context. I
would argue that a dated version (i.e., SqueakX.Y-090907 for Sept 7th,
2009) is more adequate. And yes, we could shorten that to "update number
90907" if we wanted to ;-)

The second question is whether or not to provide (numbered) change sets.
I have virtually no opinion on that since I find change sets inferior to
Monticello as change sets lack the context and history provided with
Monticello packages. If people find change sets helpful, then I guess
yes we should provide them, but I'd rather have us invest more time into
improving Squeak than providing a service that is rarely of use for people.

Asked concretely: Is there anyone out there who would continuously
consume an update stream (for whatever purpose) instead of consuming the
MC package updates?

Cheers,
   - Andreas

Edgar J. De Cleene wrote:
> I attach the first .cs , the rest is made automatic.
> In this I do not change any and do not put any different to trunk.
> The .cs with number > 7173 could be exported from the image and the change
> to for have the SystemVersion current highestUpdate rising without changing
> others MC loads could be made different, off course.
> If Board agree , I put all, the .cs and the Squeak3.11-alpha.7335.image in
> my folder for some could polish and put in a best place.
>
> Edgar

On 07.09.2009, at 22:57, Andreas Raab wrote:

> One is how to label the image properly. I'd say that given we're  
> using Monticello, the update number is somewhat useless in this  
> context. I would argue that a dated version (i.e., SqueakX.Y-090907  
> for Sept 7th, 2009) is more adequate. And yes, we could shorten that  
> to "update number 90907" if we wanted to ;-)


Makes sense, at least until someone comes up with a nicer idea. How  
about something like this:

Utilities>>updateFromServer
        "Update the image by loading all pending updates from the server."
        | config |
        config := MCMcmUpdater updateFromRepositories: #(
                'http://source.squeak.org/trunk'
        ).
        SystemVersion current date: config date

MCConfiguration>>date
        "answer date of latest dependency"
        ^self dependencies inject: Date new into: [:latest :each |
                latest max: (each versionInfo date
                        ifNil: [((MCWorkingCopy forPackage: each package) ancestry
                                findAncestor: each versionInfo) date])]

MCAncestry>>findAncestor: aVersionInfo
        self allAncestorsDo: [:each | aVersionInfo = each ifTrue: [^each]].
        ^nil

- Bert -

On 07.09.2009, at 23:59, Bert Freudenberg wrote:

Or even what you suggested above which will work with all the places  
that use the update number:

        config date dayMonthYearDo: [:d :m :y |
                SystemVersion current highestUpdate: y * 100 + m * 100 + d].

- Bert -

On 9/7/09 5:22 PM, "Eliot Miranda" <[hidden email]> wrote:

> Hi Edgar,
>
>     if you have code that generates a .cs from two .mcz's are you
> willing to share it?  That would be very useful code indeed.

Elliot , I send the code some days the code ago.
Today I send two mails, the valid is the second one.

Anyway , the code is very simple for have the .cs for each .mcz downloaded
from trunk and is this

!MCPackageLoader methodsFor: 'private' stamp: 'edc 9/1/2009 03:37' prior:
34174438!
useChangeSetNamed: baseName during: aBlock
    "Use the named change set, or create one with the given name."
    | changeHolder oldChanges newChanges csName |

    changeHolder := (ChangeSet respondsTo: #newChanges:)
                        ifTrue: [ChangeSet]
                        ifFalse: [Smalltalk].
    oldChanges := (ChangeSet respondsTo: #current)
                        ifTrue: [ChangeSet current]
                        ifFalse: [Smalltalk changes].
csName := (SystemVersion current highestUpdate + 1) asString,baseName.
    newChanges := (ChangesOrganizer changeSetNamed: csName) ifNil: [
ChangeSet new name: csName ].
    changeHolder newChanges: newChanges.
    [aBlock value] ensure: [changeHolder newChanges: oldChanges].
SystemVersion current registerUpdate: SystemVersion current highestUpdate +
1
! !

Off course , once you have all could export the .cs and revert this method
to the trunk one.


Or made a best one for the same thing.

Edgar

On 9/7/09 5:57 PM, "Andreas Raab" <[hidden email]> wrote:

> One is how to label the image properly. I'd say that given we're using
> Monticello, the update number is somewhat useless in this context. I
> would argue that a dated version (i.e., SqueakX.Y-090907 for Sept 7th,
> 2009) is more adequate. And yes, we could shorten that to "update number
> 90907" if we wanted to ;-)

I don't see why using Monticello exclude update number or version number.

> The second question is whether or not to provide (numbered) change sets.
> I have virtually no opinion on that since I find change sets inferior to
> Monticello as change sets lack the context and history provided with
> Monticello packages. If people find change sets helpful, then I guess
> yes we should provide them, but I'd rather have us invest more time into
> improving Squeak than providing a service that is rarely of use for people.

Maybe some like Monticello and more not , but afraid to say it.
No point in arguing more.

Edgar

On Mon, Sep 07, 2009 at 01:57:28PM -0700, Andreas Raab wrote:
>
> Asked concretely: Is there anyone out there who would continuously
> consume an update stream (for whatever purpose) instead of consuming the
> MC package updates?

Good question. A couple of months ago, I would have said yes for sure. But
the MC update stream is working so well that I would no longer bother with
a change set based update stream. The only thing that I still miss from the
change set stream is the change set preambles, and I suspect that there is
some easy way to produce these automatically from the MC check in comments.

Having said that, there are two useful attributes of change set streams
that may still be of value:

1) They provide a human-readable record of all changes going into the
image, such that future readers can reconstruct the history of contributions
without requiring working tools. This might be important for some future
relicensing exercise for example.

2) A change set stream works well for people with slow computers and
limited network bandwidth, as is still common in many parts of the world.

Dave

Edgar J. De Cleene wrote:
> On 9/7/09 5:57 PM, "Andreas Raab" <[hidden email]> wrote:
>> One is how to label the image properly. I'd say that given we're using
>> Monticello, the update number is somewhat useless in this context. I
>> would argue that a dated version (i.e., SqueakX.Y-090907 for Sept 7th,
>> 2009) is more adequate. And yes, we could shorten that to "update number
>> 90907" if we wanted to ;-)
>
> I don't see why using Monticello exclude update number or version number.

Because the Monticello version is on a per-package basis? I'm not sure I
understand what you're trying to say here. Are you proposing that there
is already a way of having a unique update numbering scheme across
various Monticello package versions? If so, I don't know it. Or are you
suggesting you know how to define such a version? If so, I'm all ears.

The reason why there is currently no unique update number associated
with the trunk is only because nobody thus far has made a proposal as to
how it should be defined. If anyone has a proposal for what to use,
please make suggestions.

>> The second question is whether or not to provide (numbered) change sets.
>> I have virtually no opinion on that since I find change sets inferior to
>> Monticello as change sets lack the context and history provided with
>> Monticello packages. If people find change sets helpful, then I guess
>> yes we should provide them, but I'd rather have us invest more time into
>> improving Squeak than providing a service that is rarely of use for people.
>
> Maybe some like Monticello and more not , but afraid to say it.
> No point in arguing more.

I'm not trying to argue. I'm trying to understand whether there is
actual value in providing an update stream parallel to Monticello
package updates. I just don't see who'd be using these updates if we
would provide them. If there are people who'd be interested in it, then
let's figure out a way of providing it. But if there aren't any, then it
seems like a waste of time to me.

Cheers,
   - Andreas

David,

     for me the crucial advantage a ChangeSet has is in not defining  
the rest of the package.  Currently I'm trying to e port the latest  
version of the closure compiler from Qwaq to Squeak and Pharo.  As you  
can see from the recent commits this cuts across 6 packages, all of  
which contain distro-specific code.  With ChangeSet based tools there  
is the (admittedly slim and still arduous) possibility of producing a  
single linear sequence of changes which could correctly update both  
Squeak and Pharo.  But using packages I can't do better than a painful  
integration process that produces 16 packages.  I like Monticello but  
in this case, complex code updates with ordering constraints that  
overlap packages, ChangeSets (assuming similar levels of tool support)  
would be much better.

Great if Monticello had a sub-package, single system organization  
category, subpackage that only updated the classes and methods in that  
single category.  I guess...

Eliot (phone)

On 7 Sep 2009, at 16:33, "David T. Lewis" <[hidden email]> wrote: