8.6 environments: feature request: duplicate environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

8.6 environments: feature request: duplicate environment

jtuchel
Hi,

after using environments for a while, I have a few ideas that I think might be helpful:

1. Duplicate Environment

Most of the times, you have a lot of stuff that needs to be added to the image directory, or changed in the .ini. Be it icons, message files, or just Log4s settings.
Would't it be nice if I could just duplicate such an environment into a new folder and have all that work done already?

2. Individual environment templates (just a folder to copy from)

Instead of duplicating an environment, or as an addition to that, defining a place to copy stuff from as a "fresh customized environment" with all subfolders, ini files, xml and stuff that you need as a minimum for working on a project, would be great. Imagine you can provide a base-loaded image and all that's needed for it for your individual project team and they simply push "create environment" and get a full working development or packaging or testing image for their daily work from some network share...

3. Environments on Linux and other Unices

With Seaside and server side Smalltalk applications that are deployed to Linux, more and more work has to be done on these platforms. Be it XD packaging, pre-prod-testing down to even developing there (what a terrible thought after having used Scintilla on Windows), Environments should be available there as well.

What do others think about these ideas? Any other ideas?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: 8.6 environments: feature request: duplicate environment

John O'Keefe-3
Joachim -
 
Items 1. and 2. are interesting ideas. We will consider them as we plan updates to Environments.
 
Item 3. is already available in 8.6 for UNIX platforms -- the vasetup script has been changed to open Environments. We had discussed the idea of having an environments script, but we thought that UNIX users are used to using vasetup, so we decided to just go with that.
 
John
On Wednesday, October 2, 2013 4:34:02 AM UTC-4, [hidden email] wrote:
Hi,

after using environments for a while, I have a few ideas that I think might be helpful:

1. Duplicate Environment

Most of the times, you have a lot of stuff that needs to be added to the image directory, or changed in the .ini. Be it icons, message files, or just Log4s settings.
Would't it be nice if I could just duplicate such an environment into a new folder and have all that work done already?

2. Individual environment templates (just a folder to copy from)

Instead of duplicating an environment, or as an addition to that, defining a place to copy stuff from as a "fresh customized environment" with all subfolders, ini files, xml and stuff that you need as a minimum for working on a project, would be great. Imagine you can provide a base-loaded image and all that's needed for it for your individual project team and they simply push "create environment" and get a full working development or packaging or testing image for their daily work from some network share...

3. Environments on Linux and other Unices

With Seaside and server side Smalltalk applications that are deployed to Linux, more and more work has to be done on these platforms. Be it XD packaging, pre-prod-testing down to even developing there (what a terrible thought after having used Scintilla on Windows), Environments should be available there as well.

What do others think about these ideas? Any other ideas?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: 8.6 environments: feature request: duplicate environment

jtuchel
Hi John,

thanks for answering and considering the ideas. Maybe we'll get a few comments here to see if others would think of these as helpful as well.
I wasn't aware of vasetup and will take a look into the docs. 

Joachim

Am Donnerstag, 3. Oktober 2013 14:50:22 UTC+2 schrieb John O'Keefe:
Joachim -
 
Items 1. and 2. are interesting ideas. We will consider them as we plan updates to Environments.
 
Item 3. is already available in 8.6 for UNIX platforms -- the vasetup script has been changed to open Environments. We had discussed the idea of having an environments script, but we thought that UNIX users are used to using vasetup, so we decided to just go with that.
 
John
On Wednesday, October 2, 2013 4:34:02 AM UTC-4, [hidden email] wrote:
Hi,

after using environments for a while, I have a few ideas that I think might be helpful:

1. Duplicate Environment

Most of the times, you have a lot of stuff that needs to be added to the image directory, or changed in the .ini. Be it icons, message files, or just Log4s settings.
Would't it be nice if I could just duplicate such an environment into a new folder and have all that work done already?

2. Individual environment templates (just a folder to copy from)

Instead of duplicating an environment, or as an addition to that, defining a place to copy stuff from as a "fresh customized environment" with all subfolders, ini files, xml and stuff that you need as a minimum for working on a project, would be great. Imagine you can provide a base-loaded image and all that's needed for it for your individual project team and they simply push "create environment" and get a full working development or packaging or testing image for their daily work from some network share...

3. Environments on Linux and other Unices

With Seaside and server side Smalltalk applications that are deployed to Linux, more and more work has to be done on these platforms. Be it XD packaging, pre-prod-testing down to even developing there (what a terrible thought after having used Scintilla on Windows), Environments should be available there as well.

What do others think about these ideas? Any other ideas?

Joachim

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: 8.6 environments: feature request: duplicate environment

Marten Feldtmann-2
In reply to this post by jtuchel
Duplicate environments are good ideas !

MF


--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: 8.6 environments: feature request: duplicate environment

bgridley-2
In reply to this post by jtuchel
I think any means to simplify control of one running image with another is great.  Beside the ability to reproduce itself and its environment, 
in my imagination, creating a runtime image would be done via one image manipulating and monitoring another. One image managing testing on  another, or comparing results of two others.  A dashboard capable of monitoring the health of another image - or comparative health of several. An image for each processor on the chip, wit one parent image.  Having a safe image to control the code with a sandbox image to execute it, so you don't lose your setup when testing changes that would freeze the image...

Any tools that simplify control of one image by another would be welcome and open up new horizons.

--
You received this message because you are subscribed to the Google Groups "VA Smalltalk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
To post to this group, send email to [hidden email].
Visit this group at http://groups.google.com/group/va-smalltalk.
For more options, visit https://groups.google.com/groups/opt_out.