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