Release candidate Squeak4.4-12320 ready

Dimitris,

It's not easy to just use github with Smalltalk ... see my talk about "Practical Git for Smalltalk"[1] from last years STIC conference.

With that said, I have been using git and github for my own projects for most of the last year[2]. I have adapted Metacello[3] so that it can be used to manage projects in git as well as the more traditional mcz repositories. Projects using git and mcz repositories (like SqueakSource, etc.) can be intermixed.

There are still things that need to be done to make git-based development smooth, but for someone familiar with git, they can use the system today....

The new version of Metacello works with squeak, pharo and gemstone, so you can use git for cross platform development.

The new version of Metacello is still in pre-release, but is fully functional ... I am waiting for feedback on the new scripting api before release.

As a side note, the Metacello configurations actually get simpler to create and maintain when one uses git...

Dale

[1] http://gemstonesoup.wordpress.com/2012/09/18/practical-git-for-smalltalk-stic-2012/
[2] https://github.com/dalehenrich
[3] https://github.com/dalehenrich/metacello-work/blob/master/README.md

----- Original Message -----
| From: "dimitris chloupis" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Thursday, December 20, 2012 2:15:03 PM
| Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
|
|
|
|
| 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
|
|
|
|
|
|

Even Eclipse is moving to Git and GitHub

Eclipse Says Goodbye to CVS
http://mmilinkov.wordpress.com/2012/12/21/eclipse-says-goodbye-to-cvs/

...
This is a journey that the entire Eclipse community has been on for at least
two years. I have to admit that when I first heard of the idea that we
should move the  Eclipse community from CVS to git, I was adamantly against
the idea. The notion seemed to big, too scary, and the idea that we could
get the community to move seemed too unlikely. But as time went by the logic
and benefits of moving to git started to clearly make  sense. The trend
towards social coding is huge. Working with the developer community which
has grown up around github is large and vibrant. It is critically important
to all open source organizations to make it as easy as possible to attract
more contributors, and leveraging git is a big part of making that happen.
....

On 21 December 2012 17:51, Angel "Java" Lopez <[hidden email]> wrote:
It's very easy to convert a CVS into a git one, handily.

frank

Hi Dimitris,

With Cuis, we use Github as the main place for storing packages. We use git as it is intended to be used. This means that we let git handle file versioning. Besides, Cuis uses lf as the line terminator. This means that git can diff and merge Cuis packages. For example see

https://github.com/pbella/Cuis-Ports/commit/d2c70f95b6efee4f4d7671f432b4b304b5115c1d .

Cheers,

Juan Vuletich

Quoting dimitris chloupis <[hidden email]>:

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

Cheers,
Juan Vuletich

On 12/21/12, dimitris chloupis <[hidden email]> wrote:
Yes, that is what we are trying to do as well. Making useful packages
(code external to the image) available in Squeak, Cuis and Pharo.

>
> But I have loads of fun with pharo , and definitely my eye is on Squeak too.
> I love smalltalk I wish I had discovered it earlier. But better late than
> never I guess :D

Great! You are welcome.

--Hannes

Cuis is reasonably compatible with Squeak. It has a distinct set of objectives, so some decisions are taken differently. Please see http://www.jvuletich.org/Cuis/Index.html .

Maybe after some time with the various Smalltalk variants you get used to that fragmentation, and believe there are reasons for it. Or maybe you can help find the means to reduce that fragmentation.

Cheers,

Juan Vuletich

Quoting dimitris chloupis <[hidden email]>:

Thank you.  I am definetly going to take a look at Cuis. How compatible is Cuis to Squeak ? 

By the way I am already using Github for my first smalltalk (pharo) project which I call "Ephestos", together with ss3 as a backup plan.

I dont do much with git , just the usual stuff, git push commit pull rm add .

I have to say, the smalltalk field is abit confusing to me as a beginner, there is squeak , then there is pharo , then there is Cuis, etc etc

Its a pity there is so much fragmentation. I am sure for some people this kind of freedome is cool and fun , but I personally try find ways to make things work together.  

But I have loads of fun with pharo , and definitely my eye is on Squeak too. I love smalltalk I wish I had discovered it earlier. But better late than never I guess :D

---

From: Juan Vuletich (mail lists) <[hidden email]>
To: dimitris chloupis <[hidden email]>; The general-purpose Squeak developers list <[hidden email]>
Sent: Friday, 21 December 2012, 21:33
Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..

Hi Dimitris,

With Cuis, we use Github as the main place for storing packages. We use git as it is intended to be used. This means that we let git handle file versioning. Besides, Cuis uses lf as the line terminator. This means that git can diff and merge Cuis packages. For example see

https://github.com/pbella/Cuis-Ports/commit/d2c70f95b6efee4f4d7671f432b4b304b5115c1d .

Cheers,

Juan Vuletich

Quoting dimitris chloupis <[hidden email]>:

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 12/21/2012 11:35 PM, Benoit St-Jean wrote:
> I understand your point Ron but how do you handle multi-environment
> version (Cuis, Pharo, Squeak) of code ?  What if PackageX has a version
> 6 for Squeak, 7 for Cuis and a version 8 for Pharo.  Let's say that
> Package has different bugs on each environment?  Are we all gonna be
> commit-frenzy on top of each other for the same package?

Not sure I understand the described problem but Metacello explicitly can
describe #common, #squeak, #gemstone and #pharo etc - and this is
already in use and works for several projects.

Just by looking in my image I see that ConfigurationOfHelpSystem and
ConfigurationOfShout, OmniBrowser etc etc - they all do this already.

regards, Göran

Hey!

On 12/21/2012 10:58 PM, Ron Teitelbaum wrote:
Github is nice and I applaud if we have the ability to use it.
SmalltalkHub is on the other hand "our own puppy" and fully MC focused,
so the advantages would typically be:

- Only Smalltalk stuff, no line noise of other things.
- MC is still a much smoother ride than mirroring to files and using
external tools like git.
- Since we control SmalltalkHub we can tailor it for "Smalltalker needs"

Disadvantages are obvious of course, but I tend to think SmalltalkHub
has a good spot.

- Metacello indeed works for Squeak. And has done so for quite some time.

- Metacello already works with SmalltalkHub. This is because Metacello
is simply a layer on top of Monticello so SmalltalkHub (or any other MC
repository) needs to know about Metacello. That is a very good thing.

- I think it would be good if Squeak endorsed/considered Metacello a
primary tool. And nothing stops us from adding better support in
SqueakMap to deal with it.

- And finally, no. Pharo does what Pharo wants :). But Pharo is closer
to working with github than Squeak is, given several git and github
related efforts in the Pharo community (Dale himself too). :)

When it comes to the Pharo vs Squeak "debate" it is IMHO quite simple.
Pharo has their own agenda and the core people are doing a lot of good
work there. As a Smalltalker, Squeaker and Pharooner I applaud it and
love it.

BUT... just because the Pharo project is independent doesn't mean there
aren't lots of us straddling both (or more) camps and want to do cross
platform tooling and libraries etc. Dale Henrichs is one such shining
example, and he of course also covers Gemstone.

At the same time sometimes time and effort is colliding. Take for
example my Riak binding and coding on Oak (a... kind of OODB) - I picked
Pharo explicitly for the Riak binding and Oak too - simply because there
was extra effort trying to be cross platform. That is something we
simply need to live with.


> Nobody likes change but if we would all benefit from adopting some
> similar tools should we not consider doing that for the benefit of the
> entire Smalltalk community.

I would think so.

regards, Göran

Göran,

Just a clarification ... my work on github/metacello should work on all three platforms: squeak, pharo and gemstone.

The filetree repository which is used to store Monticello packages in git allows one to share source code amongst 7 different smalltalk dialects[1] and work is ongoing to have it functional on VA as well.

Benoit,

It isn't necessary have a commit storm on a single package ... Metacello associates specific mcz files with a Metacello version which are immutable (by convention), so you won't be affected if someone commits a newer mcz package ...

Also, there are several different approaches for making projects portable across multiple platforms:

  - partition project into multiple packages isolating platform
    dependent code into platform specific packages (i.e, Grease-Core,
    Grease-Pharo-Core, Grease-GemStone-Core)
  - create platform-specific branches of a single package (i.e.,
    Grease-Core.common, Grease-Core.pharo, Grease-Core.gemstone,
    Grease-Core.squeak)
  - using git, create platform-specific branches

Metacello then associates the set of mcz files that work together in a single version (with different set of files for each platform). Common code is typically in a shared package ....

Dale


[1] https://github.com/CampSmalltalk/Cypress/blob/master/README.md

----- Original Message -----
| From: "Göran Krampe" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Cc: [hidden email], "Ron Teitelbaum" <[hidden email]>
| Sent: Friday, December 21, 2012 4:01:00 PM
| Subject: Re: [squeak-dev] Squeaksource, Squeak and Pharo..
|
| Hey!
|
| On 12/21/2012 10:58 PM, Ron Teitelbaum wrote:
| > I’m happy with the fragmentation.  I wasn’t at the start of this
| > conversation but I think I’m starting to appreciate it.  I agree
| > that
| > the goals for each are a bit different and having separated
| > achieving
| > those goals is easier.  We are building some new stuff and it seems
| > that
| > selecting the right fork for the right job “may” not have been
| > possible
| > without the split.  There are a number of new developments coming,
| > (in
| > the VM, Spoon, Seaside, Cuis, EToys, …) and it’s possible that one
| > big
| > monolithic Squeak may have made it more difficult for all.  It
| > seems
| > that we are closer to having split up the components then we had
| > thought.
| >
| > I know we cannot make everyone happy.  It seems that the starting
| > point
| > which seems to me to be COG, is the common link that binds
| > everything
| > else.  Let me know if you think that is wrong.  If that is true
| > then
| > building Squeak, or Pharo, or Cuis from a single point seems like
| > something that might help bring the communities back together.
| >  Will
| > Github or SmalltalkHub help to accomplish this?  If this were a
| > goal
| > would either do more than the other?
|
| Github is nice and I applaud if we have the ability to use it.
| SmalltalkHub is on the other hand "our own puppy" and fully MC
| focused,
| so the advantages would typically be:
|
| - Only Smalltalk stuff, no line noise of other things.
| - MC is still a much smoother ride than mirroring to files and using
| external tools like git.
| - Since we control SmalltalkHub we can tailor it for "Smalltalker
| needs"
|
| Disadvantages are obvious of course, but I tend to think SmalltalkHub
| has a good spot.
|
| > I agree with the goal, we want to be able to load a package and
| > have it
| > work and it would be nice if the dependencies were limited/managed
| > such
| > so that it will load in any fork.  Not all packages will load in
| > every
| > fork so knowing which will work beforehand is preferable.  VW is
| > different since nobody expects that with some work it will run on
| > Oinq,
| > I mean Cog (my name for the vm didn’t stick).
| >
| > It seems to me that it doesn’t really matter.  There seems to be
| > some
| > movement behind Metacello and SmalltalkHub.  Sometimes movement is
| > preferable to good ideas.  If Metacello works for Squeak and will
| > work
| > with SmalltalkHub should we not include it in Squeak to give it a
| > boost?  If Squeak goes with GitHub will Pharo follow?
|
| - Metacello indeed works for Squeak. And has done so for quite some
| time.
|
| - Metacello already works with SmalltalkHub. This is because
| Metacello
| is simply a layer on top of Monticello so SmalltalkHub (or any other
| MC
| repository) needs to know about Metacello. That is a very good thing.
|
| - I think it would be good if Squeak endorsed/considered Metacello a
| primary tool. And nothing stops us from adding better support in
| SqueakMap to deal with it.
|
| - And finally, no. Pharo does what Pharo wants :). But Pharo is
| closer
| to working with github than Squeak is, given several git and github
| related efforts in the Pharo community (Dale himself too). :)
|
| When it comes to the Pharo vs Squeak "debate" it is IMHO quite
| simple.
| Pharo has their own agenda and the core people are doing a lot of
| good
| work there. As a Smalltalker, Squeaker and Pharooner I applaud it and
| love it.
|
| BUT... just because the Pharo project is independent doesn't mean
| there
| aren't lots of us straddling both (or more) camps and want to do
| cross
| platform tooling and libraries etc. Dale Henrichs is one such shining
| example, and he of course also covers Gemstone.
|
| At the same time sometimes time and effort is colliding. Take for
| example my Riak binding and coding on Oak (a... kind of OODB) - I
| picked
| Pharo explicitly for the Riak binding and Oak too - simply because
| there
| was extra effort trying to be cross platform. That is something we
| simply need to live with.
|
|
| > Nobody likes change but if we would all benefit from adopting some
| > similar tools should we not consider doing that for the benefit of
| > the
| > entire Smalltalk community.
|
| I would think so.
|
| regards, Göran
|
|

Hey guys!

On 12/22/2012 03:43 AM, Dale Henrichs wrote:
> Göran,
>
> Just a clarification ... my work on github/metacello should work on all three platforms: squeak, pharo and gemstone.

Yeah, my point was rather that Pharo has several git related efforts
(not only yours, although I haven't looked at them), and thus might be
"closer" to working with github. But I really like that your work is
still meant and built cross dialect.

regards, Göran

thank you Chris for summarizing these community requirements as a
summary of the discussions in 2010 and 2011. As 4.4 is soon to be
released this is now what is put into action.

--Hannes

On 12/20/12, Chris Muller <[hidden email]> wrote:

> Another point: The window opens at 560@286 so its bottom-right corner is at 1360@886 which might by off of some screens. I'd position it further up to the left, maybe at ((1024@768) - (800@600)) / 2 ==> 112@84

Past Squeak releases were saved in standard size 800x600, which is a
good balance between what's needed to operate Squeak, what's available
on screens, and what's a desired-size operating environment that users
not wishing to run full-screen would want.  800x600 is a *balanced*
size.

560x286 is non-standard and probably something that will force users
into a resize gesture before they will do anything.

So, we should please deploy the image at 800x600.

On 22 December 2012 21:02, Chris Muller <[hidden email]> wrote:
So I presume that we are actually talking about the window in which
Squeak lives, right? The extent of the host window?

The window's the same size as the 4.3 release. I've not altered it.
Note as well that the ReleaseBuilder says 'self setDisplayExtent: 800
@ 600'.

frank

On 22.12.2012, at 23:51, Frank Shearar <[hidden email]> wrote:

Chris, when I wrote "position" in the paragraph above I meant precisely that. I did not propose to change the size.

> So I presume that we are actually talking about the window in which
> Squeak lives, right?

Yes.

> The extent of the host window?

No.

> The window's the same size as the 4.3 release. I've not altered it.
> Note as well that the ReleaseBuilder says 'self setDisplayExtent: 800
> @ 600'.
>
> frank

We're talking about _where_ the window opens.

- Bert -

On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
OK. I suspect the reason I've not noticed anything like that is
because I'm running 1024x768 on a Lucid box. The window opens rather
close to the top left, pretty much where I'd expect it to. I just
opened a TrunkImage.image on a Mac and it looks like it opens it right
in the centre of the screen. Is that what you see?

On 23-12-2012, at 11:15 AM, Frank Shearar <[hidden email]> wrote:

> On 22 December 2012 23:36, Bert Freudenberg <[hidden email]> wrote:
>>
>> We're talking about _where_ the window opens.
>
> OK. I suspect the reason I've not noticed anything like that is
> because I'm running 1024x768 on a Lucid box. The window opens rather
> close to the top left, pretty much where I'd expect it to. I just
> opened a TrunkImage.image on a Mac and it looks like it opens it right
> in the centre of the screen. Is that what you see?


Last I recall there was no info in the image header to specify where the main squeak window would open and it was a platform decision at start time. Now, with the Ffenestri stuff in proper use one could revise that by allowing the image code to specify where the first window opens, with appropriate policy objects to discover the screen size and look at OS preferences etc.

Are non-RISC OS vm *still* opening a main window by default? I hope not. It's a stupid thing to do; no window should even created until (and unless!) some displaying to Display (or suitable other object) is done.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Throughout history, every mystery solved has turned out to be...
*not magic*