Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
+1 This 5.2 should be a freeze and polish what we have now. I propose No red test if possible Open mantis show I do not could create a new category named 5.2 , who could do this ? Also shows 94 reported crashed , some very old.
On 24 May 2018, at 05:44, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
I propose to leave "60Deprecated" as the package where we would put deprecations. No nned for 52Deprecated, I suppose...
A "feature freeze" would be "5.2beta". Do we want to go there directly, Edgar?
Best, Marcel Am 24.05.2018 12:34:14 schrieb Edgar De Cleene edgardec2005@gmail.com: +1 This 5.2 should be a freeze and polish what we have now. I propose No red test if possible Open mantis show I do not could create a new category named 5.2 , who could do this ? Also shows 94 reported crashed , some very old.
On 24 May 2018, at 05:44, Marcel Taeumel <marcel.taeumel@hpi.de [mailto:marcel.taeumel@hpi.de]> wrote:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Maybe not. A separate Directory in ftp and a new category in Mantis should be better for now.
On 24/05/2018, 08:51, "Marcel Taeumel" marcel.taeumel@hpi.de wrote:
A "feature freeze" would be "5.2beta". Do we want to go there directly, Edgar?
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote:
Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I
guess
this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and
Etoys
clean-up.
Best, Marcel
Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote:
Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including
updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2].
Although recent TravisCI builds have passed, this folder was empty
because of an issue with the updater which Marcel and I just resolved.
Therefore, all new artifacts are now uploaded to the 5.2alpha directory
and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com
wrote:
Hi Bernard
A solution which works well for the meantime is to take early May
download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk
link
http://files.squeak.org/trunk/. This leads to an empty directory. I
guess
this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel <Marcel.Taeumel@hpi.de
:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager
Edgar,
we came to conclusion that it makes sense to postpone the "6.0" a
little
bit to finish some bigger concerns such as the use of ephemerons and
Etoys
clean-up.
Best, Marcel
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Eliot,
the latest pre-release seems okay. I have been using it for several weeks now. I suppose that the "last stable" from 2016 is not any different from our recent pre-release in terms of stability. Nothing changed with regard to some stability metrics in the last years. If it builds and lasts a few weeks, it should be fine. :-) Yet, the frequent seg-faults in the CI during test runs are kind of unsettling. :-/
Best, Marcel Am 27.05.2018 10:07:01 schrieb Eliot Miranda eliot.miranda@gmail.com: Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus <lists@fniephaus.com [mailto:lists@fniephaus.com]> wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber <bernhard@pieber.com [mailto:bernhard@pieber.com]> wrote:
Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog [https://bintray.com/opensmalltalk/vm/cog]).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952] [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest [https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest]
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus <lists@fniephaus.com [mailto:lists@fniephaus.com]>:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [http://files.squeak.org/trunk/] [2] http://files.squeak.org/5.2alpha/ [http://files.squeak.org/5.2alpha/]
On Sat, May 26, 2018 at 1:20 PM H. Hirzel <hannes.hirzel@gmail.com [mailto:hannes.hirzel@gmail.com]> wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/]
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber <bernhard@pieber.com [mailto:bernhard@pieber.com]> wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ [http://squeak.org/downloads/] and click the trunk link http://files.squeak.org/trunk/ [http://files.squeak.org/trunk/]. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ [http://files.squeak.org/6.0alpha/] as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel <Marcel.Taeumel@hpi.de [mailto:Marcel.Taeumel@hpi.de]>:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Marcel,
On May 27, 2018, at 1:45 AM, Marcel Taeumel marcel.taeumel@hpi.de wrote:
Hi Eliot,
the latest pre-release seems okay. I have been using it for several weeks now. I suppose that the "last stable" from 2016 is not any different from our recent pre-release in terms of stability. Nothing changed with regard to some stability metrics in the last years. If it builds and lasts a few weeks, it should be fine. :-) Yet, the frequent seg-faults in the CI during test runs are kind of unsettling. :-/
There have to be major differences in circumstances we do t have reliable tests for as a number of serious vm bugs have been fixed.
What I find depressing is that we don't have a process that promotes stable VMs to a Pam e where they are easily downloaded. People are still using the 2016 VMs. This is broken.
Best, Marcel
Am 27.05.2018 10:07:01 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
> Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de: > > Hi, there. > > We are going to change the current version number of the Trunk to > "5.2alpha" to denote our plans for the upcoming Squeak release. After > several discussions within the board and with our release manager Edgar, > we came to conclusion that it makes sense to postpone the "6.0" a little > bit to finish some bigger concerns such as the use of ephemerons and Etoys > clean-up. > > Best, > Marcel
Hi Eliot,
I feel your pain. My I ask, what was your process for deciding that a VM is a stable one on http://www.mirandabanda.org/files/Cog/VM/ before the switch to GitHub? Could this old process be used on GitHub as well and if not, why not?
Thanks for your terrific work on the VMs!
Best, Bernhard
Am 27.05.2018 um 10:06 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Bernhard,
On May 27, 2018, at 3:42 AM, Bernhard Pieber bernhard@pieber.com wrote:
Hi Eliot,
I feel your pain. My I ask, what was your process for deciding that a VM is a stable one on http://www.mirandabanda.org/files/Cog/VM/ before the switch to GitHub? Could this old process be used on GitHub as well and if not, why not?
We never really got to the point of having a process as just as we were talking about adding stable links we switched over to GitHub. And we had no CI infrastructure back then.
Given that tests for bugs like the compaction snapshot issue are hard to write and bite only with large images I think something semiautomatic, where the CI proposes candidates and then we decide based on longevity and bug reports which ones to promote might work. At least we can automate the packaging and deployment of a candidate once identified.
Thanks for your terrific work on the VMs!
Best, Bernhard
Am 27.05.2018 um 10:06 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote: Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Eliot,
I feel your pain. My I ask, what was your process for deciding that a VM is a stable one on http://www.mirandabanda.org/files/Cog/VM/ before the switch to GitHub? Could this old process be used on GitHub as well and if not, why not?
Thanks for your terrific work on the VMs!
Best, Bernhard
Am 27.05.2018 um 10:06 schrieb Eliot Miranda eliot.miranda@gmail.com:
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
Hi Eliot,
On Sun, 27 May 2018 at 10:06 am, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi,
On May 26, 2018, at 2:02 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote:
Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
This is so depressing. What's the process by which a stable VM release is made? That process is broken. We have to fix it. 2016?!?!
I recently tried to do a release because of this, but got some pushback. Instead, I did a pre-release, so there's at least a checkpoint we can use for Squeak. We can easily promote that pre-release to be a proper release, we can even do a new full release today or in a few days. But I don't want to make that decision on my own, especially because I'm not update to date on everything that's been worked on.
Fabio
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including
updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2].
Although recent TravisCI builds have passed, this folder was empty
because of an issue with the updater which Marcel and I just resolved.
Therefore, all new artifacts are now uploaded to the 5.2alpha directory
and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com
wrote:
Hi Bernard
A solution which works well for the meantime is to take early May
download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk
link
http://files.squeak.org/trunk/. This leads to an empty directory. I
guess
this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel <Marcel.Taeumel@hpi.de
:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager
Edgar,
we came to conclusion that it makes sense to postpone the "6.0" a
little
bit to finish some bigger concerns such as the use of ephemerons and
Etoys
clean-up.
Best, Marcel
Hi Fabio!
Thanks for the information. I will test using the pre-release version.
What is strange then is that far older versions than 201804030952 are still available on Bintray.
It would be good to have this descriptions on Bintray maybe with a link to the GitHub releases page. On the main GitHub page there are links to the stable release and to the bleeding edge versions. Maybe a link to the latest pre-release should be added?
Bernhard
Am 26.05.2018 um 23:02 schrieb Fabio Niephaus lists@fniephaus.com:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
On Sun, 27 May 2018 at 12:57 pm, Bernhard Pieber bernhard@pieber.com wrote:
Hi Fabio!
Thanks for the information. I will test using the pre-release version.
What is strange then is that far older versions than 201804030952 are still available on Bintray.
It would be good to have this descriptions on Bintray maybe with a link to the GitHub releases page. On the main GitHub page there are links to the stable release and to the bleeding edge versions. Maybe a link to the latest pre-release should be added?
Yes, we should extend the docs. Up until recently, I've always seen the Bintray artifacts as something vm-dev people need, but it turns out that there are some users downloading these artifacts as well.
We could promote the pre-release to be a proper release, then the link would automatically point to it. Instead of manually adding a link to pre-releases, I'd much rather like us to fix the release process.
Fabio
Bernhard
Am 26.05.2018 um 23:02 schrieb Fabio Niephaus lists@fniephaus.com:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com
wrote:
Hi,
I saw that the 5.2alpha build contains the VM with the version
201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs.
More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image.
The VMs that ship with the current 5.2alpha builds are from the latest
VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
Fabio
[1]
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
Best, Karl
On Sun, May 27, 2018 at 2:52 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sun, 27 May 2018 at 12:57 pm, Bernhard Pieber bernhard@pieber.com wrote:
Hi Fabio!
Thanks for the information. I will test using the pre-release version.
What is strange then is that far older versions than 201804030952 are still available on Bintray.
It would be good to have this descriptions on Bintray maybe with a link to the GitHub releases page. On the main GitHub page there are links to the stable release and to the bleeding edge versions. Maybe a link to the latest pre-release should be added?
Yes, we should extend the docs. Up until recently, I've always seen the Bintray artifacts as something vm-dev people need, but it turns out that there are some users downloading these artifacts as well.
We could promote the pre-release to be a proper release, then the link would automatically point to it. Instead of manually adding a link to pre-releases, I'd much rather like us to fix the release process.
Fabio
Bernhard
Am 26.05.2018 um 23:02 schrieb Fabio Niephaus lists@fniephaus.com:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com
wrote:
Hi,
I saw that the 5.2alpha build contains the VM with the version
201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/ opensmalltalk/vm/cog).
The VMs on Bintray are removed after a few weeks to save storage costs.
More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image.
The VMs that ship with the current 5.2alpha builds are from the latest
VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
Fabio
vm/releases/tag/201804030952
[2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Is it? The Downloads page[1] has a Virtual Machines section with all the links you need. I think it would help if there were some information given about what VM you need to download for your platform, but if you know that, then those links should be sufficient.
Levente
[1] https://squeak.org/downloads/
On Tue, 29 May 2018, karl ramberg wrote:
Making it easier to find and download new VM builds should be a priority.It's quite hard to find a recent VM following links from squeak.org
Best, Karl
On Sun, May 27, 2018 at 2:52 PM, Fabio Niephaus lists@fniephaus.com wrote:
On Sun, 27 May 2018 at 12:57 pm, Bernhard Pieber <bernhard@pieber.com> wrote: Hi Fabio! Thanks for the information. I will test using the pre-release version. What is strange then is that far older versions than 201804030952 are still available on Bintray. It would be good to have this descriptions on Bintray maybe with a link to the GitHub releases page. On the main GitHub page there are links to the stable release and to the bleeding edge versions. Maybe a link to the latest pre-release should be added?Yes, we should extend the docs. Up until recently, I've always seen the Bintray artifacts as something vm-dev people need, but it turns out that there are some users downloading these artifacts as well.
We could promote the pre-release to be a proper release, then the link would automatically point to it. Instead of manually adding a link to pre-releases, I'd much rather like us to fix the release process.
Fabio
Bernhard > Am 26.05.2018 um 23:02 schrieb Fabio Niephaus <lists@fniephaus.com>: > >> On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber <bernhard@pieber.com> wrote: >> Hi, >> >> >> I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog). >> > The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. > The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016. > > Fabio > > [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 > [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest > >> >> Should testing happen with this VM or with the latest from Bintray? >> >> Cheers, >> Bernhard
Sent from my iPhone
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
Best, Karl
This scared beginners All in one should have the most stable and recent
Edgar
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
Sent from my iPhone
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
Best, Karl
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
Best regards -Tobias
Edgar
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already: - ZIP - DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
On 30 May 2018 at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an
application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already:
- ZIP
- DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
We don't necessarily need the All-in-One, meaning one download that works on all major platforms. It would still be cool if we can pull it off, though. E.g. users in schools used to love Etoys-to-Go installed on a USB stick, which would work the same plugged into a Mac at school or a PC at home.
We do need a VM+image bundle that works "out of the box" though. One download, double-click, have a running image. Could be separate downloads per platform, if that is more convenient.
For macOS that means it should be an App bundle that includes the image, and the whole bundle needs to be read-only. On first run it should copy image and changes to the writeable sandbox folder and work from there. This should satisfy Apple's security requirements going forward.
- Bert -
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com
wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get
some
more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
I think the AIO causes more problems than it’s worth. Does it work in Windows better than it does in Mac OS and Linux? I hope so, because it only works for rank beginners on the latter platforms.
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org
On May 30, 2018, at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already:
- ZIP
- DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
On 5/31/18, John Pfersich smalltalker2@mac.com wrote:
I think the AIO causes more problems than it’s worth. Does it work in Windows better than it does in Mac OS and Linux? I hope so, because it only works for rank beginners on the latter platforms.
This is the question of the target user group.
As Bert mentions Etoys-to-go on a pen drive (use your environment in school, e.g. Mac and at home Windows-PC) _is_ an issue. But as I just write in the previous mail probably it has to be put on the back-burner at the moment ....
The user group of "beginners" is also the one which is the largest group of users!
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org
On May 30, 2018, at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already:
- ZIP
- DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote:
On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
> Making it easier to find and download new VM builds should be a > priority. > It's quite hard to find a recent VM following links from squeak.org > This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
Well, at least on Mac OS, the fact that Squeak doesn’t work right off the bat is probably a turnoff for most users, especially since there don’t seem to be any instructions on what to after you get this (I just tested this):
I mean, it's a 32 bit app (running on Mac OS 10.13.4) and you can't save the image. What good is it? It's worse than non-functional. It seems to me that a lot of people would just give up on it. I'm still running 4.6 because at least it works on Mac OS without having to screw around, trying to figure out what does work. And doing things not related to programming is what the small Squeak community obviously wants beginners to do. If Squeak was a so hard to use back in 2000, I would have abandoned it immediately.
On May 31, 2018, at 12:24 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 5/31/18, John Pfersich smalltalker2@mac.com wrote: I think the AIO causes more problems than it’s worth. Does it work in Windows better than it does in Mac OS and Linux? I hope so, because it only works for rank beginners on the latter platforms.
This is the question of the target user group.
As Bert mentions Etoys-to-go on a pen drive (use your environment in school, e.g. Mac and at home Windows-PC) _is_ an issue. But as I just write in the previous mail probably it has to be put on the back-burner at the moment ....
The user group of "beginners" is also the one which is the largest group of users!
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: http://www.objectnets.net and http://www.objectnets.org
On May 30, 2018, at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already: - ZIP - DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote: On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
John, I agree with you.
Before thinking about a All-In-One which might cover the Mac as well
there needs to be an stand-alone installation package for 5.2 (VM, sources, changes, image)
for the Mac which actually runs ......
H.
On 5/31/18, John Pfersich smalltalker2@mac.com wrote:
Well, at least on Mac OS, the fact that Squeak doesn’t work right off the bat is probably a turnoff for most users, especially since there don’t seem to be any instructions on what to after you get this (I just tested this):
I mean, it's a 32 bit app (running on Mac OS 10.13.4) and you can't save the image. What good is it? It's worse than non-functional. It seems to me that a lot of people would just give up on it. I'm still running 4.6 because at least it works on Mac OS without having to screw around, trying to figure out what does work. And doing things not related to programming is what the small Squeak community obviously wants beginners to do. If Squeak was a so hard to use back in 2000, I would have abandoned it immediately.
On May 31, 2018, at 12:24 AM, "H. Hirzel" hannes.hirzel@gmail.com wrote:
On 5/31/18, John Pfersich smalltalker2@mac.com wrote: I think the AIO causes more problems than it’s worth. Does it work in Windows better than it does in Mac OS and Linux? I hope so, because it only works for rank beginners on the latter platforms.
This is the question of the target user group.
As Bert mentions Etoys-to-go on a pen drive (use your environment in school, e.g. Mac and at home Windows-PC) _is_ an issue. But as I just write in the previous mail probably it has to be put on the back-burner at the moment ....
The user group of "beginners" is also the one which is the largest group of users!
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: http://www.objectnets.net and http://www.objectnets.org
On May 30, 2018, at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already:
- ZIP
- DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote: On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
Hi all,
On Thu, May 31, 2018 at 10:57 AM H. Hirzel hannes.hirzel@gmail.com wrote:
John, I agree with you.
Before thinking about a All-In-One which might cover the Mac as well
there needs to be an stand-alone installation package for 5.2 (VM, sources, changes, image)
for the Mac which actually runs ......
We recently discussed the necessity of a read-only DMG bundle for macOS which solves this issue. And I've actually implemented that already (e.g. [1]). Thing is, we cannot provide a DMG for the All-In-One nor is there an easy way around the sandbox disaster on macOS. However, we should probably extend the read-only warning in Squeak when running on macOS and instruct users to move the .app bundle before opening it.
Fabio
[1] http://files.squeak.org/5.2alpha/Squeak5.2alpha-18028-32bit/Squeak5.2alpha-1...
H.
On 5/31/18, John Pfersich smalltalker2@mac.com wrote:
Well, at least on Mac OS, the fact that Squeak doesn’t work right off the bat is probably a turnoff for most users, especially since there don’t
seem
to be any instructions on what to after you get this (I just tested
this):
I mean, it's a 32 bit app (running on Mac OS 10.13.4) and you can't save
the
image. What good is it? It's worse than non-functional. It seems to me
that
a lot of people would just give up on it. I'm still running 4.6 because
at
least it works on Mac OS without having to screw around, trying to figure out what does work. And doing things not related to programming is what
the
small Squeak community obviously wants beginners to do. If Squeak was a
so
hard to use back in 2000, I would have abandoned it immediately.
On May 31, 2018, at 12:24 AM, "H. Hirzel" hannes.hirzel@gmail.com
wrote:
On 5/31/18, John Pfersich smalltalker2@mac.com wrote: I think the AIO causes more problems than it’s worth. Does it work in Windows better than it does in Mac OS and Linux? I hope so, because it
only
works for rank beginners on the latter platforms.
This is the question of the target user group.
As Bert mentions Etoys-to-go on a pen drive (use your environment in school, e.g. Mac and at home Windows-PC) _is_ an issue. But as I just write in the previous mail probably it has to be put on the back-burner at the moment ....
The user group of "beginners" is also the one which is the largest group of users!
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: http://www.objectnets.net and http://www.objectnets.org
On May 30, 2018, at 07:59, Tobias Pape Das.Linux@gmx.de wrote:
HI
On 30.05.2018, at 15:30, H. Hirzel hannes.hirzel@gmail.com wrote:
Chris Muller Tue, Feb 28, 2017 at 3:14 AM
AIO provides a compact example file of everything needed to deploy an application on each of the top platforms. For no more than its instructional value, it is something worth keeping, IMO.
The AIO _is_ the application. Good to run off a pen drive as well in a platform independent way.
It does not need to be built regularily. Just for the release is fine.
But the AIO is impractical. Eg, for OSX we _must_ force users now to _move_ the .app bundle before starting it the first time, else things just do not work. The only viable Way I see for that is building read-only disk images, so that people must move the app.
However, nobody else can use DMGs, so we have two things already:
- ZIP
- DMG
And now that snaps (https://snapcraft.io/) enter the stage for linux, we have at least to _consider_ that, too.
And when signing comes into play, this is getting too complex for me.
I completely the understand the desirability of a portable app, but given we;re not a near-stateless browser and given our "workforce", I don't see this happen reliably in the forthcoming time.
Best regards -Tobias
On 5/30/18, David T. Lewis lewis@mail.msen.com wrote: On Wed, May 30, 2018 at 07:22:28AM +0200, Tobias Pape wrote:
On 30.05.2018, at 01:40, Edgar De Cleene edgardec2005@gmail.com wrote:
On 29 May 2018, at 15:42, karl ramberg karlramberg@gmail.com wrote:
Making it easier to find and download new VM builds should be a priority. It's quite hard to find a recent VM following links from squeak.org
This scared beginners All in one should have the most stable and recent
Let's face it: the All-in-ones are dead. Apple makes it harder than ever and for linux we should have start building platform packages long ago.
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Dave
fniephaus wrote
We recently discussed the necessity of a read-only DMG bundle for macOS which solves this issue. And I've actually implemented that already (e.g. [1]). Thing is, we cannot provide a DMG for the All-In-One nor is there an easy way around the sandbox disaster on macOS. However, we should probably extend the read-only warning in Squeak when running on macOS and instruct users to move the .app bundle before opening it.
Fabio
Is homebrew (https://brew.sh/) a valid way to appease the people that, on mac, think the all-in-one isn't sufficient for real work?
-- Sent from: http://forum.world.st/Squeak-Dev-f45488.html
This do ot happen if you move the .app to applications folder. Is what you do with ANY app, don¹t¹ you ? And the not optimized is for any not 64 bits
On 31/05/2018, 05:18, "John Pfersich" smalltalker2@mac.com wrote:
Well, at least on Mac OS, the fact that Squeak doesn¹t work right off the bat is probably a turnoff for most users, especially since there don¹t seem to be any instructions on what to after you get this (I just tested this):
No, with Pharo, I copy the files to subdirectories of my home folder and run without the problems I have with Squeak. I have dozens of images. But then again, Smalltalk is a hobby; I haven’t had an offer for Smalltalk work since 2005.
/————————————————————/ Encrypted email at jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org
On May 31, 2018, at 02:26, Edgar J. De Cleene edgardec2005@gmail.com wrote:
This do ot happen if you move the .app to applications folder. Is what you do with ANY app, don’t’ you ? And the not optimized is for any not 64 bits
On 31/05/2018, 05:18, "John Pfersich" smalltalker2@mac.com wrote:
Well, at least on Mac OS, the fact that Squeak doesn’t work right off the bat is probably a turnoff for most users, especially since there don’t seem to be any instructions on what to after you get this (I just tested this):
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
No, with Pharo, I copy the files to subdirectories of my home folder and run without the problems I have with Squeak. I have dozens of images. But then again, Smalltalk is a hobby; I haven???t had an offer for Smalltalk work since 2005.
John,
What you describe is exactly how I work with Squeak. VMs are installed system wide (on my small Linux laptop "system"). Images are in directories in my home directory, with many separate directories for various Squeak things (including some very old images), as well as directories for Cuis and Pharo images. I use a /usr/local/bin/run shell script to find the right VM based on image type, so for example if I want to run an image called "cuis.image" in my Cuis directory, the command is:
$ run cuis
I rarely use the All-In-One, but I can see that it is very important for some people in their daily use, and it is also very important for classrooms and for making Squeak easily downloadable for people who would like to just download and easily try it. So I think that the "download and run" packages are important, even though I personally prefer to work in the way that you describe.
As with you, Smalltalk is a hobby for me.
Dave
/????????????????????????????????????????????????????????????/ Encrypted email at jgpfersich@protonmail.com Web: www.objectnets.net and www.objectnets.org
On May 31, 2018, at 02:26, Edgar J. De Cleene edgardec2005@gmail.com wrote:
This do ot happen if you move the .app to applications folder. Is what you do with ANY app, don???t??? you ? And the not optimized is for any not 64 bits
On 31/05/2018, 05:18, "John Pfersich" smalltalker2@mac.com wrote:
Well, at least on Mac OS, the fact that Squeak doesn???t work right off the bat is probably a turnoff for most users, especially since there don???t seem to be any instructions on what to after you get this (I just tested this):
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
Smalltalk is a hobby; I haven???t had an offer for Smalltalk work since
As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
Smalltalk is a hobby; I haven???t had an offer for Smalltalk work since
As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was going to make you rich, then you are probably a sad and disappointed person. If you thought that Smalltalk might be a tool to help you think clearly and explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have done with Squeak has been a big part of enabling me to make a decent income in the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some custom software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the learning that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak, but I can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
On 01-06-2018, at 7:39 PM, David T. Lewis lewis@mail.msen.com wrote: [snip]
So I am a happy "hobby" Smalltalker. I make zero income from Squeak, but I can honestly tell you that a good deal of my actual professional income is supported by my hobby.
Now I'm almost the exact opposite in some ways. Smalltalk isn't exactly a hobby in my life; you could almost say it *is* my life. Over the last 35+ years I'd say 90+% of my income has come from Smalltalk and probably 75% specifically from Smalltalk on ARM. Which has to be one of the weirdest specialisations ever.
And I'm inclined to say that the current AIO setup is not a very effective one. An all-in-one package is a fine idea - providing the Smalltalk system and suitable VMs for all the major OS/hardware we can run on is very sensible. I think we've got to the stage where trying to make a unified one-click-run system probably causes more confusion than anything. Perhaps if we went for a simpler directory with the image/changes/sources and appropriate separate VM (sub)directories it might be easier to handle. Plus an actually helpful README to explain things.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
On Jun 1, 2018, at 20:32, tim Rowledge tim@rowledge.org wrote:
On 01-06-2018, at 7:39 PM, David T. Lewis lewis@mail.msen.com wrote: [snip]
So I am a happy "hobby" Smalltalker. I make zero income from Squeak, but I can honestly tell you that a good deal of my actual professional income is supported by my hobby.
Now I'm almost the exact opposite in some ways. Smalltalk isn't exactly a hobby in my life; you could almost say it *is* my life. Over the last 35+ years I'd say 90+% of my income has come from Smalltalk and probably 75% specifically from Smalltalk on ARM. Which has to be one of the weirdest specialisations ever.
And I'm inclined to say that the current AIO setup is not a very effective one. An all-in-one package is a fine idea - providing the Smalltalk system and suitable VMs for all the major OS/hardware we can run on is very sensible. I think we've got to the stage where trying to make a unified one-click-run system probably causes more confusion than anything. Perhaps if we went for a simpler directory with the image/changes/sources and appropriate separate VM (sub)directories it might be easier to handle. Plus an actually helpful README to explain things.
Here, here, there there
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Quality assurance: A way to ensure you never deliver shoddy goods accidentally.
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking that I could make a living with it. Might be my lack of talent but other people with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of time and money.
Of course I miss the technical purity of Smalltalk and objects everywhere, but it is not viable, in my pov, to develop massive business applications, neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
Smalltalk is a hobby; I haven???t had an offer for Smalltalk work
since
As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was going to make you rich, then you are probably a sad and disappointed person. If you thought that Smalltalk might be a tool to help you think clearly and explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have done with Squeak has been a big part of enabling me to make a decent income in the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some custom software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the learning that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak, but I can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
Hi Germán,
Just an FYI, and not to knock Squeak or Pharo you might take a look at VA Smalltalk http://www.instantiations.com or GemStoneS https://gemtalksystems.com. May people use them to develop business and web applications with them.
Lou
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking that I could make a living with it. Might be my lack of talent but other people with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of time and money.
Of course I miss the technical purity of Smalltalk and objects everywhere, but it is not viable, in my pov, to develop massive business applications, neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
Smalltalk is a hobby; I haven???t had an offer for Smalltalk work
since
As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was going to make you rich, then you are probably a sad and disappointed person. If you thought that Smalltalk might be a tool to help you think clearly and explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have done with Squeak has been a big part of enabling me to make a decent income in the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some custom software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the learning that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak, but I can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
Hello guys,
Now I am not counting on making massive amounts of money with Squeak, but I would like to know if someone with a good knowledge of Squeak environment, could arrive at applications that can relatively stand the comparison (taking into account that Squeak is open source) with applications developed with VA Smalltalk or Gemstone.
I can imagine Squeak suffering a bit on the UI-part, but would there be much difference in supported functionalities, you think?
All applications are for personnal use, and as good looking an interface can be, I attach more importance to the usability of my applications anyway. Of course if one can get both....
Kind regards,
Edwin Ancaer
Op wo 6 jun. 2018 15:42 schreef Louis LaBrunda Lou@keystone-software.com:
Hi Germán,
Just an FYI, and not to knock Squeak or Pharo you might take a look at VA Smalltalk http://www.instantiations.com or GemStoneS https://gemtalksystems.com. May people use them to develop business and web applications with them.
Lou
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking that I could make a living with it. Might be my lack of talent but other people with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of
time
and money.
Of course I miss the technical purity of Smalltalk and objects everywhere, but it is not viable, in my pov, to develop massive business applications, neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote:
Smalltalk is a hobby; I haven???t had an offer for Smalltalk work
since
> As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was
going
to make you rich, then you are probably a sad and disappointed person.
If
you thought that Smalltalk might be a tool to help you think clearly and explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have
done
with Squeak has been a big part of enabling me to make a decent income
in
the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some
custom
software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the
learning
that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak,
but I
can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
Hi Edwin,
On Wed, Jun 6, 2018 at 8:11 AM, Edwin Ancaer eancaer@gmail.com wrote:
Hello guys,
Now I am not counting on making massive amounts of money with Squeak, but I would like to know if someone with a good knowledge of Squeak environment, could arrive at applications that can relatively stand the comparison (taking into account that Squeak is open source) with applications developed with VA Smalltalk or Gemstone.
Please ask your question again using a separate thread instead of hijacking a very important thread on a specific subject.
Thank you.
I can imagine Squeak suffering a bit on the UI-part, but would there be much difference in supported functionalities, you think?
All applications are for personnal use, and as good looking an interface can be, I attach more importance to the usability of my applications anyway. Of course if one can get both....
Kind regards,
Edwin Ancaer
Op wo 6 jun. 2018 15:42 schreef Louis LaBrunda <Lou@keystone-software.com
:
Hi Germán,
Just an FYI, and not to knock Squeak or Pharo you might take a look at VA Smalltalk http://www.instantiations.com or GemStoneS https://gemtalksystems.com. May people use them to develop business and web applications with them.
Lou
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking that
I
could make a living with it. Might be my lack of talent but other people with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of
time
and money.
Of course I miss the technical purity of Smalltalk and objects
everywhere,
but it is not viable, in my pov, to develop massive business
applications,
neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote: > Smalltalk is a hobby; I haven???t had an offer for Smalltalk work
since
>
>> As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted
20
years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was
going
to make you rich, then you are probably a sad and disappointed person.
If
you thought that Smalltalk might be a tool to help you think clearly
and
explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have
done
with Squeak has been a big part of enabling me to make a decent income
in
the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some
custom
software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the
learning
that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak,
but I
can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
Hi Edwin,
I develop with VA, have made a few personal programs with Squeak and have no experience with Gemstone.
If you use Seaside to develop web apps (I have done some with both VA and Squeak), I think they will look much the same.
I think you can do some nice looking GUIs with Squeak but they will look like Squeak programs. VA uses the underling OS to draw its GUI stuff, so on Windows, they look like most Windows programs and on Linux, they look like Linux programs.
Depending upon what you want your application to do, there may be things in one of these Smalltalks that makes it easier that the others.
As you know Squeak is free. VA and Gemstone are not although they may offer something free for personal use, I'm not sure.
Lou
On Wed, 6 Jun 2018 17:11:12 +0200, Edwin Ancaer eancaer@gmail.com wrote:
Hello guys,
Now I am not counting on making massive amounts of money with Squeak, but I would like to know if someone with a good knowledge of Squeak environment, could arrive at applications that can relatively stand the comparison (taking into account that Squeak is open source) with applications developed with VA Smalltalk or Gemstone.
I can imagine Squeak suffering a bit on the UI-part, but would there be much difference in supported functionalities, you think?
All applications are for personnal use, and as good looking an interface can be, I attach more importance to the usability of my applications anyway. Of course if one can get both....
Kind regards,
Edwin Ancaer
Op wo 6 jun. 2018 15:42 schreef Louis LaBrunda Lou@keystone-software.com:
Hi Germán,
Just an FYI, and not to knock Squeak or Pharo you might take a look at VA Smalltalk http://www.instantiations.com or GemStoneS https://gemtalksystems.com. May people use them to develop business and web applications with them.
Lou
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking that I could make a living with it. Might be my lack of talent but other people with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of
time
and money.
Of course I miss the technical purity of Smalltalk and objects everywhere, but it is not viable, in my pov, to develop massive business applications, neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote: > Smalltalk is a hobby; I haven???t had an offer for Smalltalk work
since
>
>> As with you, Smalltalk is a hobby for me.
I should have realized this before and then I would not have wasted 20 years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was
going
to make you rich, then you are probably a sad and disappointed person.
If
you thought that Smalltalk might be a tool to help you think clearly and explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have
done
with Squeak has been a big part of enabling me to make a decent income
in
the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some
custom
software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at what I do" aspect is attributable to Squeak, or more specifically the
learning
that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak,
but I
can honestly tell you that a good deal of my actual professional income is supported by my hobby.
YMMV,
Dave
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
Hi Louis, Hi All,
can we please move these discussions to another thread? The All-in-One thread is very important in its own right.
On Wed, Jun 6, 2018 at 9:35 AM, Louis LaBrunda Lou@keystone-software.com wrote:
Hi Edwin,
I develop with VA, have made a few personal programs with Squeak and have no experience with Gemstone.
If you use Seaside to develop web apps (I have done some with both VA and Squeak), I think they will look much the same.
I think you can do some nice looking GUIs with Squeak but they will look like Squeak programs. VA uses the underling OS to draw its GUI stuff, so on Windows, they look like most Windows programs and on Linux, they look like Linux programs.
Depending upon what you want your application to do, there may be things in one of these Smalltalks that makes it easier that the others.
As you know Squeak is free. VA and Gemstone are not although they may offer something free for personal use, I'm not sure.
Lou
On Wed, 6 Jun 2018 17:11:12 +0200, Edwin Ancaer eancaer@gmail.com wrote:
Hello guys,
Now I am not counting on making massive amounts of money with Squeak, but
I
would like to know if someone with a good knowledge of Squeak environment, could arrive at applications that can relatively stand the comparison (taking into account that Squeak is open source) with applications developed with VA Smalltalk or Gemstone.
I can imagine Squeak suffering a bit on the UI-part, but would there be much difference in supported functionalities, you think?
All applications are for personnal use, and as good looking an interface can be, I attach more importance to the usability of my applications anyway. Of course if one can get both....
Kind regards,
Edwin Ancaer
Op wo 6 jun. 2018 15:42 schreef Louis LaBrunda <Lou@keystone-software.com :
Hi Germán,
Just an FYI, and not to knock Squeak or Pharo you might take a look at VA Smalltalk http://www.instantiations.com or GemStoneS https://gemtalksystems.com. May people use them to develop business and web applications with them.
Lou
Hi Dave:
I enjoyed a lot smalltalk and its communities but I failed thinking
that I
could make a living with it. Might be my lack of talent but other
people
with an infinite more capability than me failed at same way and my stubbornness for use Smalltalk in my business only made me lost lot of
time
and money.
Of course I miss the technical purity of Smalltalk and objects
everywhere,
but it is not viable, in my pov, to develop massive business
applications,
neither web, nor desktop and much less mobile.
Just my opinion.
Saludos / Regards, Germán Arduino @garduino
2018-06-01 23:39 GMT-03:00 David T. Lewis lewis@mail.msen.com:
On Fri, Jun 01, 2018 at 01:01:31PM -0300, Germ??n Arduino wrote:
2018-06-01 9:33 GMT-03:00 David T. Lewis lewis@mail.msen.com:
> On Fri, Jun 01, 2018 at 12:50:08AM -0700, John Pfersich wrote: > > Smalltalk is a hobby; I haven???t had an offer for Smalltalk
work
since
> 2005. > > > > >> As with you, Smalltalk is a hobby for me. >
I should have realized this before and then I would not have
wasted 20
years with Smalltalk, who barely bought me a cup or two of tea :(
You should think twice about this. If you thought that Smalltalk was
going
to make you rich, then you are probably a sad and disappointed
person.
If
you thought that Smalltalk might be a tool to help you think clearly
and
explore new ideas, then you may be a happy and satisfied person.
I don't know if anyone will ever make any money by being happy and satisfied, but I can say that in my own experience that the learning that I have
done
with Squeak has been a big part of enabling me to make a decent
income
in
the last 10 or 15 years of my professional life.
To put it in more concrete terms: I do systems integration work for a manufacturing company, and this involves (among other things) some
custom
software development (not Squeak, not Smalltalk). I am good at what I do, and I get paid for it. A significant part of the "I am good at
what
I do" aspect is attributable to Squeak, or more specifically the
learning
that I have derived from Squeak.
So I am a happy "hobby" Smalltalker. I make zero income from Squeak,
but I
can honestly tell you that a good deal of my actual professional
income
is supported by my hobby.
YMMV,
Dave
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
-- Louis LaBrunda Keystone Software Corp. SkypeMe callto://PhotonDemon
Hi David,
On May 30, 2018, at 5:54 AM, David T. Lewis lewis@mail.msen.com wrote:
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
Thanks for the request for comments. :)
I think the AIO is neat on its own. I sometimes use the AIO and/or app bundle for one-off experiments which require a quick "download-n-go" experience where I expect to throw away any changes.
But for Mac users, I'm afraid the AIO and especially the .app bundle take too prominent a place on the website compared to the more traditional VM & sources + image & changes combination, which takes a few extra clicks to discover. I say this because there is AFAIK hardly any in-image or in-VM support for the "work style" imposed by the AIO / .app bundle on OS X / macOS.
For example: new users working with the AIO / app bundle may try "save as..." or "save as new version..." from the world menu and be surprised when any changes they thought they'd saved are gone the next time they run the AIO. This is because, AFAIK, the AIO / .app bundle work style has no in-image support (or in-VM support) for loading any image other than the one bundled within an AIO / app bundle. IIRC there have been discussions on the mailing list about adding this support (say, making the .app bundle load the highest successive .1 .2 .3 image inside the bundle, as created by "save as new version...") but I don't know if any changes ever were implemented. Forgive me if they have, and I missed it!
When I really set an OS X system up for Squeak, I create a folder called "Squeak" in the /Applications folder. Inside that folder, I put VMs and .sources files. (The VM, when used in this way, already contains the facilities to pop up a file requester asking which image to load, which the AIO/.app wouldn't do. It usually even remembers the last-used directory.) I'll usually throw my current preferred VM onto the Dock. My image and changes files live elsewhere, either on my Desktop or in my Documents folder. To load an image, I either double-click, right-click and "open with," or drag its icon onto a VM icon on my Dock.
If I had my druthers, the default OS X / macOS download on squeak.org would no longer be the .app bundle, since this is too close to the AIO experience and shares its drawbacks. It would instead be an archive or dmg with some combination of VM, sources, image, and changes files. It could potentially even contain an installer .pkg which sets up the environment similar to what I described above.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Hear hear.
best, { 'tim'. 'tim'. 'tim'. 'tim' } anyOne
Hello
I think a compromise could be to
a) go for a smooth Mac installation experience at the moment; but still maintain on the to do list to later on go for an AIO experience again [1] (Mac/Windows/Linux)
b) Thus remove the inclusion of Mac support from the All-In-One at the moment. The All-In-One would only support Linux and Windows as it is currently.
c) Focus on getting loading legacy image segments to work fully[2]. Then there is less pressure on having different VMs around in order to open *.morph and *.pr files done in earlier versions. [3]
d) Work on updating the compile and installation instructions for doing different VMs for different variants of Linux. Tobias Pape mentions limited resources. In terms of priority it is not so much the availability of an actual Linux VM which counts but to have a good process descriptions which allow other developers to produce Linux VMs. [4][5]
--Hannes
[1] Bert Freudenberg writes in this thread: 'E.g. users in schools used to love Etoys-to-Go installed on a USB stick, which would work the same plugged into a Mac at school or a PC at home.'
[2] As of now it is possible to load a limited set of 6502 interpreter *.pr and *.morph files. http://wiki.squeak.org/squeak/6502 Work is all done in Smalltalk - no longer in C on the VM level. See class LegacyImageSegment and also http://forum.world.st/How-does-ImageSegmentLoader-readObject-work-tp5077513....
This allows people to contribute to finalize this without any other tool support than just the regular Squeak enviroment.
[3] It is probably mainly the loading of MethodProperties as Eliot Miranda writes
http://forum.world.st/How-does-ImageSegmentLoader-readObject-work-tp5077513p...
<citation> 3.10 had an instance of MethodProperties as the penultimate literal in all methods. As of Cog (but this has nothing to do with the VM) methods either have a selector in the penultimate literal, or an instance of AdditionalMethodState (if the method has a pragma or properties), hence saving considerable space. </citation>
[4] Updated compiling and installation instructions for VMs on Linux. This includes people reading the OpenSmalltalk lists (Cuis, Pharo, Squeak) who do not have in-depth knowledge about VMs but can easily follow well-written instructions.
This as well has to include more in-depth explanations about the different types on VMs
- Virtual machine http://wiki.squeak.org/squeak/676 - Updated README file on https://github.com/OpenSmalltalk/opensmalltalk-vm pointing to compile and installation instructions
[5] See the thread on this list from 14th May 2018 '[squeak-dev] Squeak 4.6 on 32-Bits FreeBSD 11.1' Questions about compiling a VM for FreeBSD. Then knowledge gained there should be put in a place where it can be later on found easily. (Help file - list of links to instructions?, Wiki on OpenSmalltalk?)
On 5/31/18, Tim Johnson digit@sonic.net wrote:
Hi David,
On May 30, 2018, at 5:54 AM, David T. Lewis lewis@mail.msen.com wrote:
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
Thanks for the request for comments. :)
I think the AIO is neat on its own. I sometimes use the AIO and/or app bundle for one-off experiments which require a quick "download-n-go" experience where I expect to throw away any changes.
But for Mac users, I'm afraid the AIO and especially the .app bundle take too prominent a place on the website compared to the more traditional VM & sources + image & changes combination, which takes a few extra clicks to discover. I say this because there is AFAIK hardly any in-image or in-VM support for the "work style" imposed by the AIO / .app bundle on OS X / macOS.
For example: new users working with the AIO / app bundle may try "save as..." or "save as new version..." from the world menu and be surprised when any changes they thought they'd saved are gone the next time they run the AIO. This is because, AFAIK, the AIO / .app bundle work style has no in-image support (or in-VM support) for loading any image other than the one bundled within an AIO / app bundle. IIRC there have been discussions on the mailing list about adding this support (say, making the .app bundle load the highest successive .1 .2 .3 image inside the bundle, as created by "save as new version...") but I don't know if any changes ever were implemented. Forgive me if they have, and I missed it!
When I really set an OS X system up for Squeak, I create a folder called "Squeak" in the /Applications folder. Inside that folder, I put VMs and .sources files. (The VM, when used in this way, already contains the facilities to pop up a file requester asking which image to load, which the AIO/.app wouldn't do. It usually even remembers the last-used directory.) I'll usually throw my current preferred VM onto the Dock. My image and changes files live elsewhere, either on my Desktop or in my Documents folder. To load an image, I either double-click, right-click and "open with," or drag its icon onto a VM icon on my Dock.
If I had my druthers, the default OS X / macOS download on squeak.org would no longer be the .app bundle, since this is too close to the AIO experience and shares its drawbacks. It would instead be an archive or dmg with some combination of VM, sources, image, and changes files. It could potentially even contain an installer .pkg which sets up the environment similar to what I described above.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Hear hear.
best, { 'tim'. 'tim'. 'tim'. 'tim' } anyOne
On Thu, May 31, 2018 at 7:32 AM Tim Johnson digit@sonic.net wrote:
Hi David,
On May 30, 2018, at 5:54 AM, David T. Lewis lewis@mail.msen.com wrote:
This topic deserves a new subject line, and it would be great to get some more input regarding who prefers using the All-In-One distribution for regular use, versus other approaches for organizing their image and VM.
Thanks for the request for comments. :)
I think the AIO is neat on its own. I sometimes use the AIO and/or app bundle for one-off experiments which require a quick "download-n-go" experience where I expect to throw away any changes.
But for Mac users, I'm afraid the AIO and especially the .app bundle take too prominent a place on the website compared to the more traditional VM & sources + image & changes combination, which takes a few extra clicks to discover. I say this because there is AFAIK hardly any in-image or in-VM support for the "work style" imposed by the AIO / .app bundle on OS X / macOS.
For example: new users working with the AIO / app bundle may try "save as..." or "save as new version..." from the world menu and be surprised when any changes they thought they'd saved are gone the next time they run the AIO. This is because, AFAIK, the AIO / .app bundle work style has no in-image support (or in-VM support) for loading any image other than the one bundled within an AIO / app bundle. IIRC there have been discussions on the mailing list about adding this support (say, making the .app bundle load the highest successive .1 .2 .3 image inside the bundle, as created by "save as new version...") but I don't know if any changes ever were implemented. Forgive me if they have, and I missed it!
We probably need a list of images that are available in an AIO bundle and a manager that allows users to remove certain images. Another way of fixing this would be to remove the "Save as" option in AIO bundles all together. Or we could replace it with an "Export as" option that saves the image/changes outside the AIO to avoid any confusion, but then users might not know what to do with those files.
Fabio
When I really set an OS X system up for Squeak, I create a folder called "Squeak" in the /Applications folder. Inside that folder, I put VMs and .sources files. (The VM, when used in this way, already contains the facilities to pop up a file requester asking which image to load, which the AIO/.app wouldn't do. It usually even remembers the last-used directory.) I'll usually throw my current preferred VM onto the Dock. My image and changes files live elsewhere, either on my Desktop or in my Documents folder. To load an image, I either double-click, right-click and "open with," or drag its icon onto a VM icon on my Dock.
If I had my druthers, the default OS X / macOS download on squeak.org would no longer be the .app bundle, since this is too close to the AIO experience and shares its drawbacks. It would instead be an archive or dmg with some combination of VM, sources, image, and changes files. It could potentially even contain an installer .pkg which sets up the environment similar to what I described above.
My personal view is that the All-In-One is a valuable enhancement to the basic image and VM downloads. I do not think that it is practical to maintain it as the primary release artifact, but I do think that we should provide it, as best we can, in addition to the primary image and VM release downloads.
Hear hear.
best, { 'tim'. 'tim'. 'tim'. 'tim' } anyOne
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .
Levente
On Sat, 26 May 2018, Fabio Niephaus wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-) Thank you for fixing the upload! I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016.
Fabio
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray? Cheers, Bernhard > Am 26.05.2018 um 16:58 schrieb Fabio Niephaus <lists@fniephaus.com>: > > Dear all, > > TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. > Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. > Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2]. > > Happy testing! > > Fabio > > [1] http://files.squeak.org/trunk/ > [2] http://files.squeak.org/5.2alpha/ > > > On Sat, May 26, 2018 at 1:20 PM H. Hirzel <hannes.hirzel@gmail.com> wrote: > Hi Bernard > > A solution which works well for the meantime is to take early May download from > > http://files.squeak.org/6.0alpha/ > > And update from within the image. > > One of the updates is the rename to 5.2alpha. The result is attached. > > Regards > --Hannes > > > > > On 5/26/18, Bernhard Pieber <bernhard@pieber.com> wrote: > > Hi, > > > > I wanted to get a current trunk image to help testing the new release. > > Normally, I go to http://squeak.org/downloads/ and click the trunk link > > http://files.squeak.org/trunk/. This leads to an empty directory. I guess > > this might be an unintended consquence of the rename. > > > > Are you going to rename the folder and files in > > http://files.squeak.org/6.0alpha/ as well? > > > > Best, > > Bernhard > > > >> Am 24.05.2018 um 10:44 schrieb Marcel Taeumel <Marcel.Taeumel@hpi.de>: > >> > >> Hi, there. > >> > >> We are going to change the current version number of the Trunk to > >> "5.2alpha" to denote our plans for the upcoming Squeak release. After > >> several discussions within the board and with our release manager Edgar, > >> we came to conclusion that it makes sense to postpone the "6.0" a little > >> bit to finish some bigger concerns such as the use of ephemerons and Etoys > >> clean-up. > >> > >> Best, > >> Marcel
On 27.05.2018, at 20:16, Levente Uzonyi leves@caesar.elte.hu wrote:
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
-t
Levente
On Sat, 26 May 2018, Fabio Niephaus wrote:
On Sat, May 26, 2018 at 6:40 PM Bernhard Pieber bernhard@pieber.com wrote: Hi,
So it was just race condition. :-) Thank you for fixing the upload! I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).The VMs on Bintray are removed after a few weeks to save storage costs. More importantly, these VMs are considered bleeding edge and I don't think it's a good idea to test a bleeding edge Squeak image with a bleeding edge VM. If something is broken, it can be really hard to tell if the problem is in the VM or in the image. The VMs that ship with the current 5.2alpha builds are from the latest VM pre-release which you can find at [1]. Unfortunately, the latest stable VM release [2] is from 2016. Fabio [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201804030952 [2] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/latest
Should testing happen with this VM or with the latest from Bintray? Cheers, Bernhard > Am 26.05.2018 um 16:58 schrieb Fabio Niephaus <lists@fniephaus.com>: > > Dear all, > > TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. > Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. > Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2]. > > Happy testing! > > Fabio > > [1] http://files.squeak.org/trunk/ > [2] http://files.squeak.org/5.2alpha/ > > > On Sat, May 26, 2018 at 1:20 PM H. Hirzel <hannes.hirzel@gmail.com> wrote: > Hi Bernard > > A solution which works well for the meantime is to take early May download from > > http://files.squeak.org/6.0alpha/ > > And update from within the image. > > One of the updates is the rename to 5.2alpha. The result is attached. > > Regards > --Hannes > > > > > On 5/26/18, Bernhard Pieber <bernhard@pieber.com> wrote: > > Hi, > > > > I wanted to get a current trunk image to help testing the new release. > > Normally, I go to http://squeak.org/downloads/ and click the trunk link > > http://files.squeak.org/trunk/. This leads to an empty directory. I guess > > this might be an unintended consquence of the rename. > > > > Are you going to rename the folder and files in > > http://files.squeak.org/6.0alpha/ as well? > > > > Best, > > Bernhard > > > >> Am 24.05.2018 um 10:44 schrieb Marcel Taeumel <Marcel.Taeumel@hpi.de>: > >> > >> Hi, there. > >> > >> We are going to change the current version number of the Trunk to > >> "5.2alpha" to denote our plans for the upcoming Squeak release. After > >> several discussions within the board and with our release manager Edgar, > >> we came to conclusion that it makes sense to postpone the "6.0" a little > >> bit to finish some bigger concerns such as the use of ephemerons and Etoys > >> clean-up. > >> > >> Best, > >> Marcel
Wow, I'm so glad we're having this discussion!
For clarification, the current stable VM is 5.0-201608171728. And, it IS stable. It's one of the last VM's before Eliot made the new garbage collector, so while it can encounter very long GC pauses, I have rarely encountered any crashes whatsoever.
I've tried upgrading my VM several times over the last 18 months since then but it would always frequent-enough crashes that it would become too disruptive to project work. With a new VM coming out every day, at first I would wonder, "did that crash get fixed?" and I would try again every other week or so. But, it's time consuming to switch VM's, bear the instability, and then swtich back, so after too many failures I eventually stopped and just stayed with 5.0-201608171728.
Then, with the announcement of the 5.2 release a few weeks ago, I decided to try again, so ventured back out to bintray try the "latest" VM. In this case, it was, 201804162229. (See, we should not refer to "latest" in any context of searching for a stable release, but only specific version #'s please)...
Unfortunately, it didn't last very long before crashing with a WebClient SSL access, so I was once again forced to revert back to 5.0-201608171728.
It would be so nice if we could include a newer VM one that is just as stable for the release! But...
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .>
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
... IMO, it's a non-starter to include a newer VM in 5.2 release if it means this plugin will be broken.
Thanks, Eliot, for Cog and Spur, they are masterpieces of mechanation!
Best Regards, Chris
On 28.05.2018, at 00:50, Chris Muller asqueaker@gmail.com wrote:
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .>
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
... IMO, it's a non-starter to include a newer VM in 5.2 release if it means this plugin will be broken.
No, It means that the plugin (apparently, I have not reproduced) - cannot be built on ubuntu 14.04 - cannot be use on 14.04 with the plugin from travis.
Although being an LTS, 14.04 is four years old (and goes out of maitenance in a year…)
its a special config, debians around that time still used 0.9-whatever. I think its a fix that takes around 2 hours, +/- time for settiung up the OS. I don't have those 2 hours atm.
Most users will be fine…
-t
On Mon, 28 May 2018, Tobias Pape wrote:
On 28.05.2018, at 00:50, Chris Muller asqueaker@gmail.com wrote:
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .>
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
... IMO, it's a non-starter to include a newer VM in 5.2 release if it means this plugin will be broken.
No, It means that the plugin (apparently, I have not reproduced)
- cannot be built on ubuntu 14.04
- cannot be use on 14.04 with the plugin from travis.
The same thing happens on Debian 8.
Levente
Although being an LTS, 14.04 is four years old (and goes out of maitenance in a year…)
its a special config, debians around that time still used 0.9-whatever. I think its a fix that takes around 2 hours, +/- time for settiung up the OS. I don't have those 2 hours atm.
Most users will be fine…
-t
On 30.05.2018, at 19:50, Levente Uzonyi leves@caesar.elte.hu wrote:
On Mon, 28 May 2018, Tobias Pape wrote:
On 28.05.2018, at 00:50, Chris Muller asqueaker@gmail.com wrote:
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .>
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
... IMO, it's a non-starter to include a newer VM in 5.2 release if it means this plugin will be broken.
No, It means that the plugin (apparently, I have not reproduced) - cannot be built on ubuntu 14.04 - cannot be use on 14.04 with the plugin from travis.
The same thing happens on Debian 8.
should work
Levente
Although being an LTS, 14.04 is four years old (and goes out of maitenance in a year…)
its a special config, debians around that time still used 0.9-whatever. I think its a fix that takes around 2 hours, +/- time for settiung up the OS. I don't have those 2 hours atm.
Most users will be fine…
-t
Should be verifiyed by a test and thus confirmed
On 7/24/18, Tobias Pape Das.Linux@gmx.de wrote:
On 30.05.2018, at 19:50, Levente Uzonyi leves@caesar.elte.hu wrote:
On Mon, 28 May 2018, Tobias Pape wrote:
On 28.05.2018, at 00:50, Chris Muller asqueaker@gmail.com wrote:
Unfortunately, the pre-release VM has the bug described in issue #260: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/260 .>
Yea, i haven't had the time to fix that one. It's actually a plugin not the vm per se…
... IMO, it's a non-starter to include a newer VM in 5.2 release if it means this plugin will be broken.
No, It means that the plugin (apparently, I have not reproduced) - cannot be built on ubuntu 14.04 - cannot be use on 14.04 with the plugin from travis.
The same thing happens on Debian 8.
should work
Levente
Although being an LTS, 14.04 is four years old (and goes out of maitenance in a year…)
its a special config, debians around that time still used 0.9-whatever. I think its a fix that takes around 2 hours, +/- time for settiung up the OS. I don't have those 2 hours atm.
Most users will be fine…
-t
To Fabio,Bernhard,Marcel and surely many other Great Job. No odds on Linux this time. Moving a link to my Mac create .image works
On 26 May 2018, at 13:40, Bernhard Pieber bernhard@pieber.com wrote:
Hi,
So it was just race condition. :-)
Thank you for fixing the upload!
I saw that the 5.2alpha build contains the VM with the version 201804030952, which is not the latest version on Bintray (and interestingly is not even in the versions list on https://bintray.com/opensmalltalk/vm/cog).
Should testing happen with this VM or with the latest from Bintray?
Cheers, Bernhard
Am 26.05.2018 um 16:58 schrieb Fabio Niephaus lists@fniephaus.com:
Dear all,
TravisCI just generated the first set of 5.2alpha artifacts including updated VMs which are now available at [1]. This URL actually links to the same folder you can find at [2]. Although recent TravisCI builds have passed, this folder was empty because of an issue with the updater which Marcel and I just resolved. Therefore, all new artifacts are now uploaded to the 5.2alpha directory and should show up at [1]/[2].
Happy testing!
Fabio
[1] http://files.squeak.org/trunk/ [2] http://files.squeak.org/5.2alpha/
On Sat, May 26, 2018 at 1:20 PM H. Hirzel hannes.hirzel@gmail.com wrote: Hi Bernard
A solution which works well for the meantime is to take early May download from
http://files.squeak.org/6.0alpha/
And update from within the image.
One of the updates is the rename to 5.2alpha. The result is attached.
Regards --Hannes
On 5/26/18, Bernhard Pieber bernhard@pieber.com wrote: Hi,
I wanted to get a current trunk image to help testing the new release. Normally, I go to http://squeak.org/downloads/ and click the trunk link http://files.squeak.org/trunk/. This leads to an empty directory. I guess this might be an unintended consquence of the rename.
Are you going to rename the folder and files in http://files.squeak.org/6.0alpha/ as well?
Best, Bernhard
Am 24.05.2018 um 10:44 schrieb Marcel Taeumel Marcel.Taeumel@hpi.de:
Hi, there.
We are going to change the current version number of the Trunk to "5.2alpha" to denote our plans for the upcoming Squeak release. After several discussions within the board and with our release manager Edgar, we came to conclusion that it makes sense to postpone the "6.0" a little bit to finish some bigger concerns such as the use of ephemerons and Etoys clean-up.
Best, Marcel
squeak-dev@lists.squeakfoundation.org
-
Bernhard Pieber -
Bert Freudenberg -
Chris Muller -
David T. Lewis -
Edgar De Cleene -
Edgar J. De Cleene
-
Edwin Ancaer -
Eliot Miranda -
Fabio Niephaus -
Germán Arduino -
H. Hirzel -
John Pfersich -
karl ramberg -
Levente Uzonyi -
Louis LaBrunda -
Marcel Taeumel -
Paul DeBruicker -
Tim Johnson -
tim Rowledge -
Tobias Pape