+1

On Wednesday, September 28, 2016, Tobias Pape <Das.Linux at gmx.de> wrote:

>
> On 28.09.2016, at 17:51, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com <javascript:;>> wrote:
>
> >
> >
> > 2016-09-28 11:17 GMT+02:00 Jakob Reschke <jakob.reschke at student.hpi.de
> <javascript:;>>:
> > 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
> <javascript:;>>:
> > > 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
> <javascript:;>>:
> > >> 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
> <javascript:;>>:
> > >>>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
> <javascript:;>> 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
> > >>>
> > >>
> >
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20160929/ad891ba3/attachment-0001.htm