I don't know if this would be quicker to implement than a Project type, but at the moment I would appreciate a simple Workspace that evaluates everything in a specific Environment. Projects would be far more useful to actually write code in another Environment, of course.
2016-09-29 14:37 GMT+02:00 David T. Lewis lewis@mail.msen.com:
On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote:
On 9/29/16, Jakob Reschke jakob.reschke@student.hpi.de wrote:
Hi Nicolas,
First, thank you for answering me in the other thread.
2016-09-28 23:02 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Without clear goals or vision, fixing could essentially mean "let Environment be transparent", that is let it remain a promise, a potential, whithout too many side effects... Not exactly YAGNI, just a bit of over-engineered nice piece of code that might serve later. OK this sounds like a mandatory first step.
I don't quite get what you mean by transparent, other than fixing it and enhancing the documentation to shed some light on what it is, why it is there and how to use it.
But then, what feature are we after? I have read bootstrapping, sandboxing, letting concurrent packages and/or versions co-exist, stop prefixing class names with pseudo namespace... So environment are about reducing global variable scope.
For me, the essential decisions are in these questions:
- how will environments and source-code-management interfere?
- how are we going to specify reproducible artifacts (images)?
Are we going to use environment "statically" like in VW, just like namespaces are in many languages? That somehow means that the SCM will have to be environment aware.
Or are we going to transfer this responsibility at a higher level, like Metacello for example? In this later case, we have greater flexibility, but assembling an image means telling which package is installed into which environment, then which import are necessary for each environment.
It depends on whether you look at Environments as a developer's tool (like, e. g., Java packages) or an operator's/administrator's tool (like, e. g., Docker containers, maybe). In this discrimination developers can also be operators while they gather the dependencies for their projects, for example.
Treating them as an operator's tool, I could imagine to create a new environment for every "Squeak app" you want to deploy in a production image. Installing that app via Metacello or the Squeak Map could (optionally?) create such an environment, isolating its dependencies (and their particular versions) from other apps in that image. Alternatively, you could install that app or library package into an existing environment that you must specify then. But I do not consider myself an operator, so I might be off conventional paths here...
Another thing I have in mind is running a new test case against many older versions of a package (and its dependencies?) to find out which version introduced a regression, without changing the "main" environment each time when another version is checked out. Imagine you would want to do this with the Kernel or Collections package. I would want "throwaway" environments for this.
My current naive use case is to hide from a Pharo package that I want to get going in Squeak the fact that in Pharo some classes have been renamed. I just want to make the older Squeak classes available under their changed names, without really renaming the classes themselves and without doing a big search&replace in the client package. This is probably bound to fail, because the interface has probably changed as well, but a generalization of this would be compatibility-, adapter- or emulation environments.
Another maybe simple use case could be to have a project specific environment set up when you enter a project (http://wiki.squeak.org/squeak/1020).
We now have very nicely cleaned up Project code in Squeak 5.1
- Subclass MorphicProject --- MyMorphicProject
- Subclass PasteUpMorph --- MyPasteUpMorph
- Override #initialize in MyMorphicProject and use MyPasteUpMorph
- ... some more adaptations ..... to enter a new Environment -- how?
I like this idea a lot.
I would love to see a simple "hello world!" level example of Environments. If someone could make an EnvironmentsDemoProject that opens a new project with something that changes Duck>>speak ==> 'quack' to Duck>>speak ==> 'moo', I think it might really help me to understand how to use Environments.
Dave
I agree that a simple workspace example first is better.
It could be an updated version of the example taken from
http://wiki.squeak.org/squeak/6220
seaside := (Environment named: #Seaside) import: Smalltalk globals; importSelf; exportSelf; yourself.
magma := (Environment named: #Magma) import: Smalltalk globals; importSelf; exportSelf; yourself.
app := (Environment named: #AwesomeApp) import: Smalltalk globals; import: seaside; from: seaside import: {#Session -> #SeasideSession}; import: magma; from: magma import: {#Session -> #MagmaSession}; importSelf; exportSelf; yourself.
I assume with the changes from Nicolas of today this will look different.
Just two environments would be sufficient.
--Hannes
On 9/29/16, Jakob Reschke jakob.reschke@student.hpi.de wrote:
I don't know if this would be quicker to implement than a Project type, but at the moment I would appreciate a simple Workspace that evaluates everything in a specific Environment. Projects would be far more useful to actually write code in another Environment, of course.
2016-09-29 14:37 GMT+02:00 David T. Lewis lewis@mail.msen.com:
On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote:
On 9/29/16, Jakob Reschke jakob.reschke@student.hpi.de wrote:
Hi Nicolas,
First, thank you for answering me in the other thread.
2016-09-28 23:02 GMT+02:00 Nicolas Cellier nicolas.cellier.aka.nice@gmail.com:
Without clear goals or vision, fixing could essentially mean "let Environment be transparent", that is let it remain a promise, a potential, whithout too many side effects... Not exactly YAGNI, just a bit of over-engineered nice piece of code that might serve later. OK this sounds like a mandatory first step.
I don't quite get what you mean by transparent, other than fixing it and enhancing the documentation to shed some light on what it is, why it is there and how to use it.
But then, what feature are we after? I have read bootstrapping, sandboxing, letting concurrent packages and/or versions co-exist, stop prefixing class names with pseudo namespace... So environment are about reducing global variable scope.
For me, the essential decisions are in these questions:
- how will environments and source-code-management interfere?
- how are we going to specify reproducible artifacts (images)?
Are we going to use environment "statically" like in VW, just like namespaces are in many languages? That somehow means that the SCM will have to be environment aware.
Or are we going to transfer this responsibility at a higher level, like Metacello for example? In this later case, we have greater flexibility, but assembling an image means telling which package is installed into which environment, then which import are necessary for each environment.
It depends on whether you look at Environments as a developer's tool (like, e. g., Java packages) or an operator's/administrator's tool (like, e. g., Docker containers, maybe). In this discrimination developers can also be operators while they gather the dependencies for their projects, for example.
Treating them as an operator's tool, I could imagine to create a new environment for every "Squeak app" you want to deploy in a production image. Installing that app via Metacello or the Squeak Map could (optionally?) create such an environment, isolating its dependencies (and their particular versions) from other apps in that image. Alternatively, you could install that app or library package into an existing environment that you must specify then. But I do not consider myself an operator, so I might be off conventional paths here...
Another thing I have in mind is running a new test case against many older versions of a package (and its dependencies?) to find out which version introduced a regression, without changing the "main" environment each time when another version is checked out. Imagine you would want to do this with the Kernel or Collections package. I would want "throwaway" environments for this.
My current naive use case is to hide from a Pharo package that I want to get going in Squeak the fact that in Pharo some classes have been renamed. I just want to make the older Squeak classes available under their changed names, without really renaming the classes themselves and without doing a big search&replace in the client package. This is probably bound to fail, because the interface has probably changed as well, but a generalization of this would be compatibility-, adapter- or emulation environments.
Another maybe simple use case could be to have a project specific environment set up when you enter a project (http://wiki.squeak.org/squeak/1020).
We now have very nicely cleaned up Project code in Squeak 5.1
- Subclass MorphicProject --- MyMorphicProject
- Subclass PasteUpMorph --- MyPasteUpMorph
- Override #initialize in MyMorphicProject and use MyPasteUpMorph
- ... some more adaptations ..... to enter a new Environment -- how?
I like this idea a lot.
I would love to see a simple "hello world!" level example of Environments. If someone could make an EnvironmentsDemoProject that opens a new project with something that changes Duck>>speak ==> 'quack' to Duck>>speak ==> 'moo', I think it might really help me to understand how to use Environments.
Dave
squeak-dev@lists.squeakfoundation.org
-
H. Hirzel -
Jakob Reschke