<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-28 17:51 GMT+02:00 Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">2016-09-28 11:17 GMT+02:00 Jakob Reschke <span dir="ltr"><<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>></span><wbr>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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></blockquote><div><br></div></span><div>It's a bug.<br></div><div>Currently, the Environment SUnit tests only work because of strange name scope resolution:<br></div><div>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></div><div>See below some changes rotting for too long in squeak inbox.<br><br></div><div>IMO, we should evaluate 'Smalltalk exportSelf' in environment package post actions, then apply the fix below.<br></div><div><br><div> <br></div></div></div></div></div></blockquote><div><br></div><div>Also don't forget that each environment pretends that Smalltalk globals are pointing to itself (see Environment>><wbr>initializeWithName:), creating some kind of sand-boxing.<br></div><div>It's nice.<br><br></div><div>But Smalltalk is now ambiguous ;)<br>And not so nice at the moment, because some names are misleading now.<br>Smalltalk globals are not really
globals (the variable scope meaning). Or they are globals in their sandbox...<br>And each Smalltalk is an instance of SmalltalkImage.<br>Once upon a
time SmalltalkImage current was meant for universal access to state of object memory (image
as a snapshot) but now what are these "images"?<br>It looks like
unfinished job, with very short term goal (maximizing portability).<br></div><div>I don't know what are the next steps for constructing something solid and consistent. We're not yet there.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><div>----------------------------<br></div></div><br><br><a href="http://source.squeak.org/inbox/Kernel-nice.798.diff" target="_blank">http://source.squeak.org/inbox<wbr>/Kernel-nice.798.diff</a><br></div><div> <br><div></div><div>----------------------------<br></div><br>Name: Kernel-nice.798<br>Author: nice<br>Time: 30 July 2013, 10:34:15.34 pm<br>UUID: e02ae597-3f6d-40b9-9468-bf0141<wbr>6db6de<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.ph<wbr>p?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></div><div><div class="gmail-h5"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Alternatively: Are there downsides of `Smalltalk globals exportSelf`<br>
other than that you have to do it yourself in current Squeak images?<br>
<div><div><br>
2016-09-23 17:28 GMT+02:00 Jakob Reschke <<a href="mailto:jakob.reschke@student.hpi.de" target="_blank">jakob.reschke@student.hpi.de</a>><wbr>:<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 rel="noreferrer" 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="mailto:Das.Linux@gmx.de" target="_blank">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="mailto:brasspen@gmail.com" target="_blank">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 rel="noreferrer" 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="mailto:jakob.reschke@student.hpi.de" target="_blank">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 rel="noreferrer" 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>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div>