Release candidate Squeak4.4-12320 ready

> Hi All,
>
> Does anyone have a practical solution for this problem?  What would be
> needed to make it so that I can write my package for different versions of
> Squeak and Pharo?
>
> I don't know enough about the pieces involved but here is a question (I've
> been a bit out of the loop).  If Squeak supported MetaCello and
> PackageInstaller would that make it easier for the Squeak Community to write
> code that is compatible with both systems?
>
> If I wanted to port my code to Pharo using Monticello how would I do that
> now?  I use Monticello Configurations and loved them.  Is it as easy as
> making an installer category and publishing a Monticello Configuration file?
> What do people do now (if anything)?
>
> I remember publishing some stuff on SqueakMap but don't remember how it
> worked now, not sure what's wrong with it either since IIRC it supports
> multiple versions.  I think that the process to figure out how to publish
> was a barrier to entry (but don't quote me on that).
>
> I'm not taking sides just asking questions.
>
> All the best,
>
> Ron Teitelbaum
> Head Of Engineering
> 3d Immersive Collaboration Consulting
> [hidden email]
> Follow Me On Twitter: @RonTeitelbaum
> www.3dicc.com
>
>
>
>
>
>
>

>
>
>
> On Thu, Dec 20, 2012 at 6:05 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz
>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.zip
>>
>> This should fix the MC failing tests.
>
>
> This doesn't solve the dirty package problem though
> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167052.html).

> I ran the following doIt in the above image:
>
>
> | trunk dirty |
> trunk := MCRepositoryGroup default repositories detect:
> [:ea | ea description = 'http://source.squeak.org/trunk'].
>
> dirty := Dictionary new.
> MCWorkingCopy allManagers collect:
> [:ea || changes |
> changes := ea changesRelativeToRepository: trunk.
> changes isEmpty ifFalse:
> [dirty at: ea put: changes]].
> ^ dirty
>
> It takes a while, but it gives the following list of dirty packages:
>
> Collections
> FlexibleVocabularies
> Graphics
> Multilingual
> SMLoader
> ToolBuilder-Kernel
>
> Some of these are harmless, but we shouldn't ship the image without fixing
> at least Collections and ToolBuilder-Kernel.

> Hi folks!
>
> As the author of SqueakMap, long time Squeaker (and nowadays both
> Squeaker and Pharooner) and also involved in some other related projects
> (SmalltalkHub and more) my view might be of some interest.
>
> First of all, Angel compares with the rest of the world - but we have
> both historic and technical differences at play. Some things worth noting:
>
> - SqueakMap was indeed started out as a generic package *catalog*. It is
> not a SCM tool. It was format agnostic from the very beginning.
>
> - Monticello and SqueakSource came from Avi. Superb tools but when
> Squeaksource came I quickly warned the community that it would deminish
> SqueakMap because it overlapped and "took over" several "catalog"
> aspects. I was right unfortunately, but at the same time SS was great
> and has served us very well in its own right.
>
> - Noone has really taken SM and moved it forward. I also don't have that
> amount of free time anymore.
>
> - SqueakMap is dead. Face it. :) It is not the future IMHO.
>
> - Monticello and Metacello are the de facto standard these days for SCM
> and package loading. Metacello took the whole
> dependencies/tagging/releases issue and simply rode on MC to solve it. I
> have felt it looks overly complex but it's mostly some line noise - it
> is not that complicated.
>
> - This also means that for a very, very long time package management and
> source code management will be forever "intertwined" in the Smalltalk
> world. Personally I say - fine! Again, let's just embrace it and go.
>
> - The advantage is that Metacello "configurations" is "just code" and
> can offer functionality totally independent of the hosting platform for
> MC. So it doesn't matter if you load a Metacello configuration from a
> website, from SS or SS3 or Smalltalkhub - it all works the same!
>
> - Monticello AND Metacello are meant to work in Squeak too. I haven't
> tried, but I presume Metacello works or is very close to working?
>
> - Pharo is betting hard on Smalltalkhub. It is a really nice system AND
> there is also an image side client tool brewing for it! This means the
> equivalence of the SqueakMap Package Loader will be easy to build in
> Squeak for Smalltalkhub.
>
>
> So my advice would be:
>
> 1. Keep SqueakMap on oxygen for a little while longer while we get ready
> to ditch it. Really.
>
> 2. Bet hard on Monticello (we already do, right?) and Metacello for
> Squeak. Make sure they work. Embrace Metacello even if it does look a
> bit complex to begin with. There are lots of articles, tutorials and
> tons of examples to just copy from. I have written two configurations
> these last two days and "the shit works". Good work Dale! :)
>
> 3. Get involved in Smalltalkhub and help out making it work fine for
> Squeak, note the name - *Smalltalk* hub. It's not Pharohub! Don't set up
> your own unless for some odd reason Pharo makes it uninhabitable for
> Squeak and turns it into "Pharohub".
>
> Note that Smalltalkhub is "just" a new SS, but much more solid
> architecture, really snazzy modern web UI, offering githubish features
> and bloody hell, I mean, it can show diffs right there in the browser!
>
> Smalltalkhub also has a really cool architecture so the coding fun is
> rated A++, Nicolas is busy as a bee making it better, better. I think it
> should be seen as a unifying playground and Metacello as the "glue" that
> makes it possible to have projects tailored for both Squeak and Pharo.
> It has many functions for EXACTLY that.
>
> Either way, I am putting my efforts right there. IMHO the Squeak
> community should do so too. If the Squeak community can ride a bit on
> the momentum in Pharo - there is really no reason not to.
>
> regards, Göran

> SqueakMap is dead, SqueakSource dead, later SmalltalkHub will be dead.
>
> I am coming from pharo by the way, I am new with smalltalk, I was a python
> developer.
> And I love squeak too.
>
> I dont understand why every smalltalk problem should be solved by smalltalk.
>
> Github is a great community , already has gathered tons of ruby and python
> projects, js and many more.
>
> I think its a great candidate for smalltalk, no offense intended but
> definitely better that what SmalltalkHub can offer.
>
> I want to embrace at times all these smalltalk technologies, but is hard to
> abandon Gihub that I have used for my projects and support the smalltalk
> solutions instead.
>
> I dont want to downgrade the hard work of good people, but its hard to
> compete with products that are designed full time by big teams and matured
> through thousands of use cases.
>
> My vote goes to Github.
>
> ________________________________
> From: Göran Krampe <[hidden email]>
> To: The general-purpose Squeak developers list
> <[hidden email]>
> Sent: Thursday, 20 December 2012, 23:14
> Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
>
> Hi folks!
>
> As the author of SqueakMap, long time Squeaker (and nowadays both Squeaker
> and Pharooner) and also involved in some other related projects
> (SmalltalkHub and more) my view might be of some interest.
>
> First of all, Angel compares with the rest of the world - but we have both
> historic and technical differences at play. Some things worth noting:
>
> - SqueakMap was indeed started out as a generic package *catalog*. It is not
> a SCM tool. It was format agnostic from the very beginning.
>
> - Monticello and SqueakSource came from Avi. Superb tools but when
> Squeaksource came I quickly warned the community that it would deminish
> SqueakMap because it overlapped and "took over" several "catalog" aspects. I
> was right unfortunately, but at the same time SS was great and has served us
> very well in its own right.
>
> - Noone has really taken SM and moved it forward. I also don't have that
> amount of free time anymore.
>
> - SqueakMap is dead. Face it. :) It is not the future IMHO.
>
> - Monticello and Metacello are the de facto standard these days for SCM and
> package loading. Metacello took the whole dependencies/tagging/releases
> issue and simply rode on MC to solve it. I have felt it looks overly complex
> but it's mostly some line noise - it is not that complicated.
>
> - This also means that for a very, very long time package management and
> source code management will be forever "intertwined" in the Smalltalk world.
> Personally I say - fine! Again, let's just embrace it and go.
>
> - The advantage is that Metacello "configurations" is "just code" and can
> offer functionality totally independent of the hosting platform for MC. So
> it doesn't matter if you load a Metacello configuration from a website, from
> SS or SS3 or Smalltalkhub - it all works the same!
>
> - Monticello AND Metacello are meant to work in Squeak too. I haven't tried,
> but I presume Metacello works or is very close to working?
>
> - Pharo is betting hard on Smalltalkhub. It is a really nice system AND
> there is also an image side client tool brewing for it! This means the
> equivalence of the SqueakMap Package Loader will be easy to build in Squeak
> for Smalltalkhub.
>
>
> So my advice would be:
>
> 1. Keep SqueakMap on oxygen for a little while longer while we get ready to
> ditch it. Really.
>
> 2. Bet hard on Monticello (we already do, right?) and Metacello for Squeak.
> Make sure they work. Embrace Metacello even if it does look a bit complex to
> begin with. There are lots of articles, tutorials and tons of examples to
> just copy from. I have written two configurations these last two days and
> "the shit works". Good work Dale! :)
>
> 3. Get involved in Smalltalkhub and help out making it work fine for Squeak,
> note the name - *Smalltalk* hub. It's not Pharohub! Don't set up your own
> unless for some odd reason Pharo makes it uninhabitable for Squeak and turns
> it into "Pharohub".
>
> Note that Smalltalkhub is "just" a new SS, but much more solid architecture,
> really snazzy modern web UI, offering githubish features and bloody hell, I
> mean, it can show diffs right there in the browser!
>
> Smalltalkhub also has a really cool architecture so the coding fun is rated
> A++, Nicolas is busy as a bee making it better, better. I think it should be
> seen as a unifying playground and Metacello as the "glue" that makes it
> possible to have projects tailored for both Squeak and Pharo. It has many
> functions for EXACTLY that.
>
> Either way, I am putting my efforts right there. IMHO the Squeak community
> should do so too. If the Squeak community can ride a bit on the momentum in
> Pharo - there is really no reason not to.
>
> regards, Göran
>
>
>
>
>
>

> On 20 December 2012 19:23, Benoit St-Jean <[hidden email]> wrote:
>> FYI, I did post my remarks/concerns on the Squeak and Pharo mailing lists
>> regarding this subject a year ago but it just seems like nobody read or did
>> care.
>>
>> Secondly, as I said, a year ago, we should definitely have *separate* code
>> repositories for Squeak and Pharo.  I just closed Squeak 30 seconds ago,
>> being totally fed up with packages that wouldn't load...  Right now, both
>> environments are polluting the code of the other and it's nonsense...  You
>> know the kind of horror story where version 7 (Squeak) fixes version 6
>> (Pharo) that now became version 8 (Pharo again) but that will be fixed as a
>> combo of version 6 and 8 for Squeak?
>>
>> Can't we have something simple like the Cincom Public Repository ???
>>
>> Could you commit Ruby code to the CRAN (Comprehensive R Arcive Network) ?
>> No!  You know why?  Those are 2 different beasts, just like Squeak and
>> Pharo.  And seeing at which speed Pharo is moving away from "standard" (for
>> lack of a better word) Smalltalk, this "problem will happen more and more
>> and more.
>>
>> How useful is Squeak if all the code available is slowly becoming
>> "Pharo-only friendly" ?
>>
>> In other words, we should setup our *own* SQUEAK ONLY repository, make sure
>> people set a "platform target" (say Squeak 4.4 or 4.3) for migration (and
>> tell the project owners that they should make an effort to port their code
>> to Squeak 4.x) and start from there...
>
> No. That would be suicide.
>
> What we _should_ be doing is _talking_ to people. Keep the lines of
> communication open. The Pharo folk are not monsters. They do not break
> things to spite the Squeak community. And given sufficient reason and
> volunteered effort, they're more than happy to work towards making
> things cross platform.
>

>
>
>
> On Thu, Dec 20, 2012 at 6:05 AM, Frank Shearar <[hidden email]>
> wrote:
>>
>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz
>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.zip
>>
>> This should fix the MC failing tests.
>
>
> This doesn't solve the dirty package problem though
> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167052.html).
>
> I ran the following doIt in the above image:
>
>
> | trunk dirty |
> trunk := MCRepositoryGroup default repositories detect:
> [:ea | ea description = 'http://source.squeak.org/trunk'].
>
> dirty := Dictionary new.
> MCWorkingCopy allManagers collect:
> [:ea || changes |
> changes := ea changesRelativeToRepository: trunk.
> changes isEmpty ifFalse:
> [dirty at: ea put: changes]].
> ^ dirty
>
> It takes a while, but it gives the following list of dirty packages:
>
> Collections
> FlexibleVocabularies
> Graphics
> Multilingual
> SMLoader
> ToolBuilder-Kernel
>
> Some of these are harmless, but we shouldn't ship the image without fixing
> at least Collections and ToolBuilder-Kernel.

>
> On 20-12-2012, at 2:20 PM, Göran Krampe <[hidden email]> wrote:
>>
>> 1. My two daughters and two boats (wanna buy one?). :)
>
>
> Not sure you should be offering daughters for public sale….
>
> And on boats, I have a valuable parable for you. An acquaintance  
> noticed his friends getting infected with the dreaded 'just two more  
> foot' disease; buy a boat, start hankering for one just two foot  
> longer. Repeat. He decided to skip all that and found a retired  
> Royal Navy Corvette for just a few hundred thousand $ - less than a  
> lot of people end up spending on boats. He got an ocean-going  
> military vessel (minus barrel for the gun-turret) ad had much fun.  
> Including supposedly finding a replacement barrel and a Phalanx gun.  
> You might note that US aircraft carriers will soon be on sale since  
> they are now obsolete with the introduction of short-range ballistic  
> anti-shipping missiles that require them to stand offshore by enough  
> that the range of shipboard aircraft is severely compromised. How  
> about basing your latest enterprise on the Enterprise?
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Giraffiti (n): Vandalism spray-painted very, very high
>
>
>
>

> On 20 December 2012 20:03, Colin Putney <[hidden email]> wrote:
>>
>>
>>
>> On Thu, Dec 20, 2012 at 6:05 AM, Frank Shearar <[hidden email]>
>> wrote:
>>>
>>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.tgz
>>> * http://ftp.squeak.org/4.4/Squeak4.4-12320.zip
>>>
>>> This should fix the MC failing tests.

>> This doesn't solve the dirty package problem though
>> (http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-December/167052.html).
>>
>> I ran the following doIt in the above image:
>>
>>
>> | trunk dirty |
>> trunk := MCRepositoryGroup default repositories detect:
>> [:ea | ea description = 'http://source.squeak.org/trunk'].
>>
>> dirty := Dictionary new.
>> MCWorkingCopy allManagers collect:
>> [:ea || changes |
>> changes := ea changesRelativeToRepository: trunk.
>> changes isEmpty ifFalse:
>> [dirty at: ea put: changes]].
>> ^ dirty
>>
>> It takes a while, but it gives the following list of dirty packages:
>>
>> Collections
>> FlexibleVocabularies
>> Graphics
>> Multilingual
>> SMLoader
>> ToolBuilder-Kernel
>>
>> Some of these are harmless, but we shouldn't ship the image without fixing
>> at least Collections and ToolBuilder-Kernel.
>
> I can confirm your list. How do we clean these though? For instance,
> if I manually remove our old friend WeakRegistry class >>
> #migrateOldRegistries I can't save my change because MC rightly thinks
> there's no difference between my (new, modified) code and trunk?
>
> Is it completely crazy to - in this case at least - just remove the
> method in a do-it and then make sure the package isn't dirty by
> verifying with trunk?
>
> WeakRegistry removeSelector: #migrateOldRegistries.
> "Some as yet undecided way of forcing a dirty/clean check"
>
> frank