On 28.09.2016, at 17:51, Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com> wrote:

> 
> 
> 2016-09-28 11:17 GMT+02:00 Jakob Reschke <jakob.reschke at student.hpi.de>:
> Let me repeat my question which might have gone unnoticed in my
> previous wall of text:
> 
> Why doesn't the global environment (Smalltalk globals) export anything
> by default? Is there a reason at all, or was it simply forgotten at
> some point (because "nobody uses Environments" anyway)?
> 
> 
> It's a bug.
> Currently, the Environment SUnit tests only work because of strange name scope resolution:
> we use the environment of superclass in that resolution with no good reason.
> Since ProtoObject/Object are in the class hierarchy, we have undue access to Smalltalk globals.
> 
> See below some changes rotting for too long in squeak inbox.
> 
> IMO, we should evaluate 'Smalltalk exportSelf' in environment package post actions, then apply the fix below.

+1
Because why not? Environments seem currently strangely unusable. Fixing them can be great :)

> 
>  
> ----------------------------
> 
> 
> http://source.squeak.org/inbox/Kernel-nice.798.diff
>  
> ----------------------------
> 
> Name: Kernel-nice.798
> Author: nice
> Time: 30 July 2013, 10:34:15.34 pm
> UUID: e02ae597-3f6d-40b9-9468-bf01416db6de
> Ancestors: Kernel-nice.797
> 
> Better fix for http://bugs.squeak.org/view.php?id=1554
> A class variable defined in a superclass should take precedence over a global variable.
> 
> First look in local class variables.
> Then look in local sharedPools (a local sharedPool will shadow a super class variable, that sounds fair).
> Then look in superclass pools.
> When superclass chain is exhausted, look in the Environment that were provided as parameter.
> 
> Note that this is mostly squeak 1.x implementation of #scopeHas:ifTrue: (or st-80), except that anEvironment parameter replaces Smalltalk.
> This way we avoid duplicate lookup of previous workaround.
> And we never ever look in superclass environment, that's not necessarily ours.
> 
> This currently breaks some EnvironmentTest because inheriting superclass environment is a cheap and easy way to  import all Smalltalk (unless you  are not an Object or ProtoObject of course).
> The longest and proper way would be to properly export some symbols from Smalltalk globals, and import them explicitely in the tested environment.
> 
> 
> Alternatively: Are there downsides of `Smalltalk globals exportSelf`
> other than that you have to do it yourself in current Squeak images?
> 
> 2016-09-23 17:28 GMT+02:00 Jakob Reschke <jakob.reschke at student.hpi.de>:
> > In the meantime, I figured out that the Smalltalk globals environment
> > does not export anything. Hence, nothing can be imported from it by
> > default.
> >
> > Further, I found this post [1] by Frank Shearar, which contains a
> > snippet to load a package into an environment (however,
> > EnvironmentRequest has been renamed to CurrentEnvironment since then).
> > He also proposes `Smalltalk globals exportSelf` there, to let the
> > global environment export its contents, which could be one way to
> > solve my first problem.
> >
> > I am unsure how this is intended to be used; what is the reason for
> > not letting the global environment export anything by default? After
> > all, you have to start somewhere... To attempt an alternative, I
> > created a fresh environment for the classes that I want to import
> > later under other names like so:
> >
> >     fsenv := Environment named: #FileSystem.
> >     fspackage := PackageOrganizer default packageNamed: 'FS' ifAbsent: [].
> >     fspackage classes do: [:ea | fsenv bind: ea name to: ea ]
> >     fsenv importSelf.
> >     fsenv exportSelf.
> >     testenv := Environment named: #TestEnv1.
> >     testenv importSelf.
> >     testenv exportSelf.
> >     testenv import: fsenv removingPrefix: 'FS'.
> >     testenv valueOf: #Filesystem "=> FSFilesystem"
> >
> > Now I can use testenv valueOf: #Filesystem to retrieve the
> > FSFilesystem class, so far so good. I have not used my testenv for
> > anything real yet, but it is still missing all the basics such as
> > Object or Array. So I doubt it will be of much use, unless I set up
> > another environment to import from that contains all the Kernel,
> > Collections etc. classes. But this does not feel right, as there
> > already is such an environment: Smalltalk globals...
> >
> > In the post from 2012 for which Chris posted the link, Colin linked an
> > image (and luckily, he has not removed it from his webspace since
> > then) from which I could grab the browser opening snippet. It is
> > simply
> >
> >     Browser fullOnClass: aClassDefinedInAnotherEnvironment
> >
> > ...which in my case gives me a browser for the global environment
> > instead, because the "renamed" classes stem from there, of course.
> >
> > Frank's post also has another snippet to browse an environment:
> >
> >     b := Browser new
> >       selectEnvironment: anEnvironment;
> >       yourself.
> >     Browser openBrowserView: (b openEditString: nil) label: b
> > defaultBrowserTitle
> >
> > But it seems like the browser will only show an environment's own
> > contents, not the imported classes. Hence, I do not see anything in my
> > environments so far. If my assumption is correct, there is no way to
> > see the imported classes under their new names in the browser.
> >
> > When I try to define a new class using my empty browser on my
> > environment, it goes back into Smalltalk globals and puts the class
> > there instead. It also does that in Colin's old image, so I guess
> > defining classes in environments is not supported that way.
> >
> > More elaborate tools are probably required to easily see what is going
> > on, without exploring the Environments implementation in parallel.
> >
> > [1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2013-December/175519.html
> >
> >
> > 2016-09-23 11:59 GMT+02:00 Tobias Pape <Das.Linux at gmx.de>:
> >> Hi Colin,
> >>
> >> do you have an idea here?
> >>
> >> Best regards
> >>         -Tobias
> >
> > 2016-09-16 18:27 GMT+02:00 Chris Cunnington <brasspen at gmail.com>:
> >>>Can I get a system browser for my environment (where saving a method
> >>>compiles it with the environment bindings in place)?
> >>
> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2012-June/164605.html
> >>
> >> Chris
> >
> >>
> >> On 16.09.2016, at 14:50, Jakob Reschke <jakob.reschke at student.hpi.de> wrote:
> >>
> >>> Hello,
> >>>
> >>> I am having a look at Environments, but have not yet figured out, how
> >>> to operate them. I would like to create a new environment with an
> >>> additional binding for an existing class under another name, and load
> >>> a package in that new environment.
> >>>
> >>> The most of a documentation I have found is http://wiki.squeak.org/squeak/6220
> >>> and I have tried the following so far:
> >>>
> >>> testenv := Environment named: #TestEnv1.
> >>> testenv import: Smalltalk globals.
> >>> testenv from: Smalltalk globals import: { #String -> #MyString }.
> >>> testenv importSelf.
> >>> testenv exportSelf.
> >>>
> >>> However, testenv valueOf: #MyString or testenv valueOf: #String both
> >>> return nil instead of the String class. Does it mean that the
> >>> from:import: did not work? It seems to only add a policy to my
> >>> environment, but no declarations or bindings.
> >>>
> >>> For evaluating something in context of the environment, I have found
> >>> the EnvironmentLoader, but it does not seem to recognize the
> >>> additional binding either:
> >>>
> >>> (EnvironmentLoader for: testenv) evaluate: 'MyString'. => nil
> >>> (EnvironmentLoader for: testenv) evaluate: 'String'. => nil
> >>>
> >>> (at least the import of the original globals seems to have worked).
> >>>
> >>> What steps am I missing?
> >>>
> >>> Also it is not very convenient to make up strings of code everytime I
> >>> want to do something in the other environment, is there a better way?
> >>> Can I get a system browser for my environment (where saving a method
> >>> compiles it with the environment bindings in place)?
> >>>
> >>> Best regards,
> >>> Jakob
> >>>
> >>
> 
> 
>