I'm relatively new to Squeak and as I have mentioned it in the past, I love it.
However, I guess there must be some tricks of the trade that you learn either through experience or from others with more experience, and that's the reason for this email.
I mainly use Squeak to develop Seaside apps. I develop on Mac OS and deploy to Linux. My development environment contains a bunch of Monticello packages and SqueakMap packages that I use most often.
Although I haven't used Monticello as other have suggested for version control maintenance, I do understand the possibilities of doing it and will start versioning my apps with it. That way, I can also always have a standalone versioned release of my apps that I could load into other images.
However, the question I have is, say a new image comes out (e.g. 3.9, 3.10, 4.0 etc), how can I migrate my entire development environment to the new image? I could file-in my apps that I saved in Monticello, but what about all the other packages I loaded? The stock full image (VM and image) seems to come with a .changes file, so the packages that I load will simply be added to that .changes file. Therefore, the .changes file will not only contain my changes, but also the changes that came with the original image I started with. I would hate to have to load each of the packages I normally use again for every new "environment" I setup.
Any clues as to how I can simplify this process?
Thanks, Daniel
Daniel:
I guess each Squeaker have a different solution, so I share mine.
Each .image in use is what you download from official servers , plus favorite packages plus your own code, you end with a sm directory and a package-cache directory into the directory what have your working .image.
So, until the packages used change for new version .image, you know what the loading order of packages is, what this particular setup works and your app too.
See http://saltypickle.com/Home/10 and study the John Pierce Configure Script, changing what you don't use and adding your own code.
Run this first in your new .image, chances are you are in business, but keep all packages what you use up to day for increasing stability.
Hope this help you.
Edgar
PS And if you travel and don't have Internet connection, I have tricks to fool sm and load code from sm directory in your disk
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
This is interesting. I will study John's script.
Thanks, Daniel
On Aug 24, 2005, at 5:05 AM, Lic. Edgar J. De Cleene wrote:
Daniel:
I guess each Squeaker have a different solution, so I share mine.
Each .image in use is what you download from official servers , plus favorite packages plus your own code, you end with a sm directory and a package-cache directory into the directory what have your working .image.
So, until the packages used change for new version .image, you know what the loading order of packages is, what this particular setup works and your app too.
See http://saltypickle.com/Home/10 and study the John Pierce Configure Script, changing what you don't use and adding your own code.
Run this first in your new .image, chances are you are in business, but keep all packages what you use up to day for increasing stability.
Hope this help you.
Edgar
PS And if you travel and don't have Internet connection, I have tricks to fool sm and load code from sm directory in your disk
1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Edgar,
BTW, I was playing with the scripts on http://saltypickle.com/Home/10 and have a couple of questions that maybe you or someone else can help me.
Below is a snippet of the script:
installer install. % "SQUEAK MAP PACKAGES TO INSTALL" #((MCInstaller 5) (DynamicBindings 2) (KomServices 3) (KomHttpServer 4) (KeyBinder 3)
What do the numbers after the package names mean? Is it a release/ version number?
Also, wouldn't mind hearing what you have to say about mobility issues and internet connection that you mentioned.
Thanks, Daniel
On Aug 24, 2005, at 5:05 AM, Lic. Edgar J. De Cleene wrote:
Daniel:
I guess each Squeaker have a different solution, so I share mine.
Each .image in use is what you download from official servers , plus favorite packages plus your own code, you end with a sm directory and a package-cache directory into the directory what have your working .image.
So, until the packages used change for new version .image, you know what the loading order of packages is, what this particular setup works and your app too.
See http://saltypickle.com/Home/10 and study the John Pierce Configure Script, changing what you don't use and adding your own code.
Run this first in your new .image, chances are you are in business, but keep all packages what you use up to day for increasing stability.
Hope this help you.
Edgar
PS And if you travel and don't have Internet connection, I have tricks to fool sm and load code from sm directory in your disk
1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Daniel Salama puso en su mail :
Edgar,
BTW, I was playing with the scripts on http://saltypickle.com/Home/10 and have a couple of questions that maybe you or someone else can help me.
Below is a snippet of the script:
installer install. % "SQUEAK MAP PACKAGES TO INSTALL" #((MCInstaller 5) (DynamicBindings 2) (KomServices 3) (KomHttpServer 4) (KeyBinder 3)
What do the numbers after the package names mean? Is it a release/ version number?
Also, wouldn't mind hearing what you have to say about mobility issues and internet connection that you mentioned.
Thanks, Daniel
Yes, this was version numbers. I have CableModem now, but in past I suffer of unreliable and expensive dial-up. So I attach my solution File in the .cs and do in a workspace SMLoader newWhitoutNet You could have access to last saved map. If you have the 3.7 CD, http://www.squeak-ev.de/Download/Squeak-CD/ ,you have all packages for 3.7 in that disk, copy the complete sm directory on your hard disk and no need of Internet connection, Use the browse cache option of SM and install the package. You must modify the John script for using packages on your disk. In Squeak exist a way of recording actions , but I not having time to use/test it, sure someone could say how.
Send mail to Markus Denker begging he publish soon the 3.8 CD version -:)
Edgar
Hi Daniel,
On 8/24/05, Daniel Salama dsalama@user.net wrote:
BTW, I was playing with the scripts on http://saltypickle.com/Home/10 and have a couple of questions that maybe you or someone else can help me.
Below is a snippet of the script:
installer install. % "SQUEAK MAP PACKAGES TO INSTALL" #((MCInstaller 5) (DynamicBindings 2) (KomServices 3) (KomHttpServer 4) (KeyBinder 3)
What do the numbers after the package names mean? Is it a release/ version number?
The number after the package name is the auto version number. Both parameters will be passed in as arguments to:
SMSqueakMap default installPackageNamed: aString autoVersion: version.
Regards,
John
Lic. Edgar J. De Cleene wrote:
I guess each Squeaker have a different solution, so I share mine.
Well, hopefully, soon we will all have a common solution. Have you looked into Kabungu? Looks promising to me...
It looks like dependencies are finally coming to Squeak-ville.
Daniel
Daniel Vainsencher puso en su mail :
Lic. Edgar J. De Cleene wrote:
I guess each Squeaker have a different solution, so I share mine.
Well, hopefully, soon we will all have a common solution. Have you looked into Kabungu? Looks promising to me...
It looks like dependencies are finally coming to Squeak-ville.
Daniel
Daniel I try Kabungu and fail, maybe I doing some wrong, no time now for more test.
And the day all have that common solution could means no change. Sure you wish this ?
I think the dependencies thing should reach class granularity not packages granularity.
I continue investigation on how transfer and load arbitrary code between normal Squeak and SqueakLight and how cook the Egg.
Egg should be a minimal core .image drived via Unix terminal, with TCP connectivity, connecting to a repository of individual class and should have some intelligent way of decide the load order.
Sorry I still learning tons of things and this could take a loooong time.
Cheers
Edgar
___________________________________________________________ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar
Hi daniel
I suggest you to have a build process, i.e., any kind of script that given one fresh image produces your environment. This way you can minimize the pain of moving to new images. I can send you what I did in the past for my robot env. Stef
I'm relatively new to Squeak and as I have mentioned it in the past, I love it.
However, I guess there must be some tricks of the trade that you learn either through experience or from others with more experience, and that's the reason for this email.
I mainly use Squeak to develop Seaside apps. I develop on Mac OS and deploy to Linux. My development environment contains a bunch of Monticello packages and SqueakMap packages that I use most often.
Although I haven't used Monticello as other have suggested for version control maintenance, I do understand the possibilities of doing it and will start versioning my apps with it. That way, I can also always have a standalone versioned release of my apps that I could load into other images.
However, the question I have is, say a new image comes out (e.g. 3.9, 3.10, 4.0 etc), how can I migrate my entire development environment to the new image? I could file-in my apps that I saved in Monticello, but what about all the other packages I loaded? The stock full image (VM and image) seems to come with a .changes file, so the packages that I load will simply be added to that .changes file. Therefore, the .changes file will not only contain my changes, but also the changes that came with the original image I started with. I would hate to have to load each of the packages I normally use again for every new "environment" I setup.
Any clues as to how I can simplify this process?
Thanks, Daniel
This is the second suggestion to use a script to automate the process. If you don't mind sharing what you did for the robot env, I would appreciate it.
Thanks, Daniel
On Aug 24, 2005, at 7:33 AM, stéphane ducasse wrote:
Hi daniel
I suggest you to have a build process, i.e., any kind of script that given one fresh image produces your environment. This way you can minimize the pain of moving to new images. I can send you what I did in the past for my robot env. Stef
I'm relatively new to Squeak and as I have mentioned it in the past, I love it.
However, I guess there must be some tricks of the trade that you learn either through experience or from others with more experience, and that's the reason for this email.
I mainly use Squeak to develop Seaside apps. I develop on Mac OS and deploy to Linux. My development environment contains a bunch of Monticello packages and SqueakMap packages that I use most often.
Although I haven't used Monticello as other have suggested for version control maintenance, I do understand the possibilities of doing it and will start versioning my apps with it. That way, I can also always have a standalone versioned release of my apps that I could load into other images.
However, the question I have is, say a new image comes out (e.g. 3.9, 3.10, 4.0 etc), how can I migrate my entire development environment to the new image? I could file-in my apps that I saved in Monticello, but what about all the other packages I loaded? The stock full image (VM and image) seems to come with a .changes file, so the packages that I load will simply be added to that .changes file. Therefore, the .changes file will not only contain my changes, but also the changes that came with the original image I started with. I would hate to have to load each of the packages I normally use again for every new "environment" I setup.
Any clues as to how I can simplify this process?
Thanks, Daniel
I'm contemplating a migration too, but I have objects in the image I need to preserve/migrate as well. Though you don't mention that as a requirement, you may still find an in-place upgrade convenient. Here are a couple of tips:
You can update an image in place by filing in the update stream from the server. Find the squeak tab on the left of your image (or at least, on the left of mine :) and hit "load code updates." I think that, depending on the history of the image, it will sometimes stop at a certain version. You might try "save as new version" off the main menu if that happens, though I'm not really sure what the implications of that operation are. (Usually when it hits a version boundary it just asks you if you want to proceed to to the next version.)
Second, you can control the change set that changes go into, so changes you file in are not mixed in with your own. If you load updates from the server, each goes into its own changeset. If you're filing in the changes yourself, see the "changes" item on the main menu, and "create new change set" off its submenu. A more visually oriented alternative is to create a new project and switch to it, then file in the changes. Each project, by default, has a changeset with the name of the project.
squeak-dev@lists.squeakfoundation.org
-
Daniel Salama -
Daniel Vainsencher -
John Pierce -
Lic. Edgar J. De Cleene -
Ross Boylan -
stéphane ducasse