Squeak-dev March 2017

squeak-dev@lists.squeakfoundation.org

50 participants
281 discussions

Re: [squeak-dev] Environment changes in the Inbox
by Jakob Reschke 03 Mar '17

03 Mar '17

2017-03-03 3:15 GMT+01:00 Chris Muller <asqueaker(a)gmail.com>: > That's a LOT of stuff! Environments provides a "trade-off" for the > developer to engage in one sort of work instead of another sort of > work. A sort of work unfamiliar to Smalltalkers.. > > [...] > >> It is not possible to load a version of FileSystem where >> FSPath is called Path into the same environment as ST80 without >> overwriting ST80's Path. > > Unless you renamed it. I think of Berts question in the context of > system configuration. Applications have code which configures the > image for themself. Codifying the rename there (pre-load) means you > can still always use the latest-and-greatest versions without having > to do any more work than setting up Environments. That might be true if you are developing an application as in "the thing that you want to start up an image for". But what I am currently working on is not meant to be an application in that sense, but another set of tools and a library. I expect them to be loaded to support development of other applications, not to be loaded all for themselves (as much as FileSystems is a library, from Squeak's perspective). And for a library, I do not like the idea of telling users that they must first rename some class in their system before they can safely install the library. Performing the rename silently in a pre-load script is even more offensive IHMO, see below. >>> Our environments support renaming, doesn't that help? >>> >> >> Yes, it does. What I meant is that because of this name conflict, I >> require another environment at all. Unless I consider it desirable to >> rename one of the Path classes and possibly change all the references >> from Path to FSPath in the loaded package. Or rename Path to St80Path >> and hope that nobody will ever add another method uses it under the >> name "Path". > > If someone added a new method, your app still wouldn't be calling it > unless you change it to do so.. I do not really understand. Maybe there was a misunderstanding. If my library automatically renames Path to St80Path (or forces the user to do it manually) and at a later time the user loads another package that has "Path" in some method that expects it to be the Path from ST80, the code is screwed. Sounds like a problem that Craig tries to solve with Naiad. > Name collisions are such a very-rare problem, and we're make the > system more complicated in *so* many places, it really does feel like > the tail wagging the dog. I touched the system in many places, indeed, but I do not agree to have made it horribly more complex. The core of the matter is replacing the singleton "Smalltalk" or "Smalltalk globals" by references to something that is more specific to the respective context, and making sure that the context tells which more specific environment that has to be. What does have become somewhat more complex is to think about how to correctly load code, when you develop the loading facilities. But how loading and compiling works is hardly trivial anyway. In comparison to other systems, it probably is, but not absolutely. > Environments is for developers (nerds). Although my preference is to > reduce and simplify the system (by removing it altogether), I will > respect developers who want to push forward as long as it is not > exclusionary to power users and Smalltalk newbies, meaning it must > preserve the illusion of Smalltalk-80's original, simple, single > Smalltalk environment. Programming tools are for developers. Nobody criticizes their unconditional presence, though. Environments are a tool to be used under the right circumstances, offering a way out of some tricky conflicts that arise in the real world and that developers (or nerds) need to solve. Multiple environments simply are not the same as a single environment. To simulate the view of a monolithic environment at any time, it might help if browser & co. also showed the imported classes, not only the declared classes of an environment. But then it is imperative to indicate the environment more prominently, as Bert requested, because otherwise users might be more frequently grabbing the wrong browser window and wondering "why are my classes not here?" If we wanted to always show all classes from all environments, each visual class reference would have to carry an environment tag, like "Path [FileSystems]" and "Path [MVC]" (could be omitted for the original Smalltalk environment). It might be distracting, though. For example when every other class in the test runner would carry a tag and you could not easily deselect or filter by tag/environment. For tools that have a category list, the tag could be added to the category instead, segregating classes in dependent list views by environment. Though, it might cause confusion about what categories are (or rather are not). You would still need the tag on the class name when no category is indicated, such as in message traces. . What is more important and where environments are really lacking at the moment IMHO is that there is no easy or canonical way of transferring them to another image. As long as my library uses environments to deal with Path and friends, it cannot be installed by simply loading a Monticello package or configuration. Users are still burdened with setting up and organizing environments, like they would traditionally be burdened with renaming ST80's Path and remembering it when they encounter bugs in yet another package. So I agree that environments are not a finished solution and realize they are not the complete answer to the needs for a module system. But they will never become better if you cannot even work with them.

1 0

Re: [squeak-dev] Environment changes in the Inbox
by Jakob Reschke 03 Mar '17

03 Mar '17

2017-03-03 0:06 GMT+01:00 Bert Freudenberg <bert(a)freudenbergs.de>: > > The general metaphor seems to be that an environment just replaces the > global Smalltalk dictionary with its own, but the code in general doesn't > even have to be aware of the existence of other environments. This is in > contrast to how other systems handle modules and namespaces. Would you think > this is a fair characterization? The metaphor sounds adequate to me, but I think the validity of the contrast depends on your view of what environments really are in the context of modules or namespaces. An object file compiled from C also does not know where its externals will come from until it is linked with other objects or libraries. Java classes also do not know where the other packages will come from until a class loader starts collecting things from a classpath. Environment variables (ha!) like PATH, CLASSPATH, PYTHONPATH, and include paths might be a good analogy for our environments: they provide a context to resolve names (executable names, fully qualified class names, module names, included file names, and in Squeak "global" variables) by the system (runtime, compiler/linker), and they typically do not appear in the source code. They are part of a module system, but they are neither the module system all by themselves nor namespaces as a language feature. In fact, they are not language features at all. Our environments are different from those path variables in that they support renaming and fine granular imports. In Python, Java, C++ this is done by the language's "import" features. Hence, Python modules, Java packages, and C++ namespaces (and C function prototypes, if you want to look at them as imports) all do appear in the source code. For this aspect, your contrast definitely holds. It might be interesting that the centrality of PYTHONPATH also poses a challenge to coexisting applications, leading to solutions like virtualenv. In Squeak we can either use multiple images or use multiple environments to resolve conflicts. 2017-03-03 4:23 GMT+01:00 Bert Freudenberg <bert(a)freudenbergs.de>: > On Thu, Mar 2, 2017 at 6:34 PM, Jakob Reschke <jakob.reschke(a)student.hpi.de> > wrote: > > Is it fair to say that we can pretty much ignore environments in daily use? > That we only create one if we need it? Or do you think they would be useful > for regular development? You should not always need them and you can usually ignore them, unless you run into Path classes frequently... ;-) If the Smalltalk library ecosystem were larger (Java sized), the need for more explicit namespaces or environments might be more pressing.

1 0

Re: [squeak-dev] Environment changes in the Inbox
by Jakob Reschke 03 Mar '17

03 Mar '17

2017-03-03 0:06 GMT+01:00 Bert Freudenberg <bert(a)freudenbergs.de>: > Let me see if I understand ... > > On Thu, Mar 2, 2017 at 3:45 AM, Jakob Reschke <jakob.reschke(a)student.hpi.de> > wrote: >> >> >> 1. prepare the environment in a workspace, because there are no tools for >> it: >> >> env := Environment named: #NewProjectWithPharoBindings. > > > This creates a new empty environment. > >> >> env import: Smalltalk globals. > > > This makes all current classes available inside the new environment. > >> >> env from: Smalltalk globals import: { #FSFilesystem -> #FileSystem. >> #FSPath -> #Path. "..." } > > > This makes the FS classes (which you loaded previously) available under the > non-prefixed name, too. Correct. > >> >> env importSelf; > > > Makes future declarations in this environment visible to itself. > Yes, and also the already existing ones (if any), but for some reason the implementation of importSelf explicitly does not overwrite existing (imported) bindings with own declarations. I wonder why... But it does not matter all that much because of what I described in the older thread titled "Environments: imported bindings overwriting each other". >> >> exportSelf. > > > Makes future changes in this environment visible to other environments that > imported it. > Correct. >> >> 2. open a Workspace that "lives" in the new environment: >> >> env beCurrentDuring: [Workspace open] >> >> ...and change its title to remember its purpose. > > > Yoshiki and I tried that but evaluating code still appears to use the > Smalltalk environment. We had to change the evaluateSelectionAndDo: method > in the Morphic package to use the model's environment. Is that a change you > missed? Bingo! Stupid me. There are some other relevant changes in TextEditor as well. Add Morphic-jr.1325 to the list. > > In general it appears to be working well, although the tool support is > minimal for now. It would be useful if environment-aware tools indicated the > current environment (if it is not the default). Maybe. I did it for the TestRunner, but playing with only two different environments and without duplicate class names (except for Path) I could always tell the environment from the visible classes. Question is: How to indicate? Changing the title might make some titles long. IIRC, Marcel once told me that Bastian Steinert indicated environments with differently colored window borders in his thesis work. But Marcel found that confusing, and I also think that would be difficult to comprehend.

4 3

The Inbox: Morphic-jr.1325.mcz
by commits＠source.squeak.org 03 Mar '17

03 Mar '17

A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-jr.1325.mcz ==================== Summary ==================== Name: Morphic-jr.1325 Author: jr Time: 3 March 2017, 3:28:29.825687 am UUID: ec6312f8-a496-fe46-8c4e-e1ca155b499d Ancestors: Morphic-tpr.1324 regard the model's environment in TextEditor =============== Diff against Morphic-tpr.1324 =============== Item was changed: ----- Method: TextEditor>>browseClassFromIt (in category 'menu messages') ----- browseClassFromIt "Launch a hierarchy browser for the class indicated by the current selection. If multiple classes matching the selection exist, let the user choose among them." | aClass | self lineSelectAndEmptyCheck: [ ^ self ]. aClass := UIManager default classFromPattern: self selection string withBlanksTrimmed + withCaption: 'choose a class to browse...' + in: model environment. - withCaption: 'choose a class to browse...'. aClass ifNil: [ ^ morph flash ]. + self systemNavigation - SystemNavigation default spawnHierarchyForClass: aClass selector: nil! Item was changed: ----- Method: TextEditor>>browseIt (in category 'menu messages') ----- browseIt "Launch a browser for the current selection, if appropriate" | aSymbol anEntry brow | Preferences alternativeBrowseIt ifTrue: [^ self browseClassFromIt]. self lineSelectAndEmptyCheck: [^ self]. (aSymbol := self selectedSymbol) isNil ifTrue: [^ morph flash]. aSymbol first isUppercase ifTrue: + [anEntry := (model environment + valueOf: aSymbol - [anEntry := (Smalltalk - at: aSymbol ifAbsent: [ self systemNavigation browseAllImplementorsOf: aSymbol. ^ nil]). anEntry ifNil: [^ morph flash]. (anEntry isKindOf: Class) ifFalse: [anEntry := anEntry class]. brow := SystemBrowser default new. brow setClass: anEntry selector: nil. brow class openBrowserView: (brow openEditString: nil) label: 'System Browser'] ifFalse: [self systemNavigation browseAllImplementorsOf: aSymbol]! Item was changed: ----- Method: TextEditor>>compileSelectionFor:in: (in category 'do-its') ----- compileSelectionFor: anObject in: evalContext | methodNode | methodNode := [Compiler new compileNoPattern: self selectionAsStream in: anObject class context: evalContext + environment: model environment notifying: self ifFail: [^nil]] on: OutOfScopeNotification do: [:ex | ex resume: true]. ^ methodNode generateWithTempNames! Item was changed: ----- Method: TextEditor>>evaluateSelectionAndDo: (in category 'do-its') ----- evaluateSelectionAndDo: aBlock "Treat the current selection as an expression; evaluate it and invoke aBlock with the result." | result rcvr ctxt | self lineSelectAndEmptyCheck: [^ nil]. (model respondsTo: #evaluateExpression:) ifTrue: [ ^ aBlock value: (model perform: #evaluateExpression: with: self selection)]. (model respondsTo: #doItReceiver) ifTrue: [ rcvr := model doItReceiver. ctxt := model doItContext] ifFalse: [rcvr := ctxt := nil]. result := [ rcvr class evaluatorClass new evaluate: self selectionAsStream in: ctxt to: rcvr + environment: (model environment ifNil: [Smalltalk globals]) notifying: self ifFail: [morph flash. ^ nil] logged: true. ] on: OutOfScopeNotification do: [ :ex | ex resume: true]. (model respondsTo: #expressionEvaluated:result:) ifTrue: [ model perform: #expressionEvaluated:result: with: self selection with: result]. ^aBlock value: result! Item was changed: ----- Method: TextEditor>>referencesToIt (in category 'menu messages') ----- referencesToIt "Open a MessageSet with the references to the selected global or variable name." | selection environment binding | self selection isEmpty ifTrue: [ self selectWord ]. environment := (model respondsTo: #selectedClassOrMetaClass) + ifTrue: [ model selectedClassOrMetaClass ifNil: [ model environment ] ] + ifFalse: [ model environment ]. - ifTrue: [ model selectedClassOrMetaClass ifNil: [ Smalltalk globals ] ] - ifFalse: [ Smalltalk globals ]. selection := self selectedSymbol ifNil: [ self selection asString ]. (environment isBehavior and: [ (environment instVarIndexFor: selection ifAbsent: [ 0 ]) ~= 0 ]) ifTrue: [ ^ self systemNavigation browseAllAccessesTo: selection from: environment ]. selection isSymbol ifFalse: [ ^ morph flash ]. binding := (environment bindingOf: selection) ifNil: [ ^ morph flash ]. self systemNavigation browseAllCallsOn: binding! Item was added: + ----- Method: TextEditor>>systemNavigation (in category 'as yet unclassified') ----- + systemNavigation + ^ SystemNavigation for: model environment!

1 0

The Inbox: EToys-dtl.281.mcz
by commits＠source.squeak.org 03 Mar '17

03 Mar '17

David T. Lewis uploaded a new version of EToys to project The Inbox: http://source.squeak.org/inbox/EToys-dtl.281.mcz ==================== Summary ==================== Name: EToys-dtl.281 Author: dtl Time: 2 March 2017, 9:05:08.262967 pm UUID: 5441a7e4-f77e-45cb-bb21-a24bc7a2b87b Ancestors: EToys-ul.280 Capture Bert's explanation of Worldlet in a class comment =============== Diff against EToys-ul.280 =============== Item was changed: PasteUpMorph subclass: #Worldlet instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Etoys-Squeakland-Morphic-Mentoring'! + !Worldlet commentStamp: 'dtl 3/2/2017 21:02' prior: 0! + An area with a private Presenter, viz, for which the scope of its stop-step-go buttons is limited to the area's interior. + + A Worldlet serves as a world within a world, which can have its own flaps, but does not have its own worldState. It is used for recording and replaying demos in an EventTheater.! - !Worldlet commentStamp: 'sw 9/19/2006 14:53' prior: 0! - An area with a private Presenter, viz, for which the scope of its stop-step-go buttons is limited to the area's interior.!

1 0

The Inbox: Monticello-jr.664.mcz
by commits＠source.squeak.org 02 Mar '17

02 Mar '17

A new version of Monticello was added to project The Inbox: http://source.squeak.org/inbox/Monticello-jr.664.mcz ==================== Summary ==================== Name: Monticello-jr.664 Author: jr Time: 2 March 2017, 11:24:19.419687 pm UUID: 5f7f61e8-c5f7-7749-8d7f-c39b5b4584fb Ancestors: Monticello-jr.663 make 'recompile package' work for working copies in another environment =============== Diff against Monticello-jr.663 =============== Item was changed: ----- Method: MCWorkingCopyBrowser>>recompilePackage (in category 'actions') ----- recompilePackage + (workingCopy withEnvironmentActiveDo: [workingCopy package packageInfo methods]) - workingCopy package packageInfo methods do: [:ea | ea actualClass recompile: ea methodSymbol] displayingProgress: 'Recompiling...'!

1 0

The Inbox: SUnit-jr.106.mcz
by commits＠source.squeak.org 02 Mar '17

02 Mar '17

A new version of SUnit was added to project The Inbox: http://source.squeak.org/inbox/SUnit-jr.106.mcz ==================== Summary ==================== Name: SUnit-jr.106 Author: jr Time: 2 March 2017, 11:07:55.282687 pm UUID: 675e77ab-782e-2c47-a754-a9d1ca6f9c03 Ancestors: SUnit-mt.105 make ClassTestCase>targetClass work in other environments =============== Diff against SUnit-mt.105 =============== Item was changed: ----- Method: ClassTestCase>>targetClass (in category 'private') ----- targetClass |className| className := self class name asText copyFrom: 0 to: self class name size - 4. + ^ self class environment valueOf: (className asString asSymbol). - ^ Smalltalk at: (className asString asSymbol). !

1 0

The Inbox: SUnitGUI-jr.65.mcz
by commits＠source.squeak.org 02 Mar '17

02 Mar '17

A new version of SUnitGUI was added to project The Inbox: http://source.squeak.org/inbox/SUnitGUI-jr.65.mcz ==================== Summary ==================== Name: SUnitGUI-jr.65 Author: jr Time: 2 March 2017, 11:16:47.351687 pm UUID: 2fc0a490-bd92-cc43-96c7-ede4b233243d Ancestors: SUnitGUI-mt.64 make TestRunner work in another environment use with the following code snippet: someEnvironment beCurrentDuring: [TestRunner open] =============== Diff against SUnitGUI-mt.64 =============== Item was changed: Model subclass: #TestRunner + instanceVariableNames: 'categories categoriesSelected classes classIndex classesSelected failedList failedSelected errorList errorSelected lastUpdate result previousRun categoryPattern classPattern environment' - instanceVariableNames: 'categories categoriesSelected classes classIndex classesSelected failedList failedSelected errorList errorSelected lastUpdate result previousRun categoryPattern classPattern' classVariableNames: '' poolDictionaries: '' category: 'SUnitGUI'! !TestRunner commentStamp: '<historical>' prior: 0! <lint: #ignore rule: #classNotReferenced rational: 'this view is only accessed from menus'> ! Item was added: + ----- Method: TestRunner>>environment (in category 'accessing') ----- + environment + ^ environment ifNil: [Smalltalk globals]! Item was added: + ----- Method: TestRunner>>environment: (in category 'accessing') ----- + environment: anEnvironment + environment := anEnvironment. + self update; reset! Item was changed: ----- Method: TestRunner>>findCategories (in category 'utilities') ----- findCategories | visible | visible := Set new. self baseClass withAllSubclassesDo: [ :each | each category ifNotNil: [ :category | visible add: category ] ]. ^ Array streamContents: [ :stream | + self environment organization categories do: [ :each | - Smalltalk organization categories do: [ :each | (visible includes: each) ifTrue: [ stream nextPut: each ] ] ].! Item was changed: ----- Method: TestRunner>>findClassesForCategories: (in category 'utilities') ----- findClassesForCategories: aCollection + | environment items | - | items | aCollection isEmpty ifTrue: [ ^ self baseClass withAllSubclasses asSet ]. + environment := self environment. items := aCollection gather: [ :category | + ((environment organization listAtCategoryNamed: category) + collect: [ :each | environment valueOf: each ]) - ((Smalltalk organization listAtCategoryNamed: category) - collect: [ :each | Smalltalk at: each ]) select: [ :each | each includesBehavior: self baseClass ] ]. ^ items asSet.! Item was changed: ----- Method: TestRunner>>initialize (in category 'initialization') ----- initialize super initialize. failedList := errorList := Array new. SystemChangeNotifier uniqueInstance notify: self ofSystemChangesOfItem: #class change: #Added using: #update; notify: self ofSystemChangesOfItem: #category change: #Added using: #update; notify: self ofSystemChangesOfItem: #class change: #Removed using: #update; notify: self ofSystemChangesOfItem: #category change: #Removed using: #update; notify: self ofSystemChangesOfItem: #class change: #Renamed using: #update; notify: self ofSystemChangesOfItem: #category change: #Renamed using: #update; notify: self ofSystemChangesOfItem: #class change: #Recategorized using: #update; notify: self ofSystemChangesOfItem: #category change: #Recategorized using: #update. + environment := Environment current. self update; reset! Item was changed: ----- Method: TestRunner>>label (in category 'accessing-ui') ----- label + ^ 'Test Runner in environment ', environment name! - ^ 'Test Runner' !

1 0

PositionableStream requests
by Chris Cunningham 02 Mar '17

02 Mar '17

I've just committed a (very) minor documentation change to the inbox for PositionalStream>>upToAll: that I'd request be put into trunk. http://source.squeak.org/inbox/Collections-cbc.740.mcz The request is: PositionalStream>>backUpTo: backs up to a collection. This name/pattern doesn't match other methods in this class - I would have expected it to back up to a specific object, not a collection. So, I'd request that we could change this to #backUpToAll: to make the behavior more apparent. Apparently #backUpTo: is only used outside of the image - no callers in the latest trunk image (other than the tests, of course). If this is acceptable, I'd be happy to make the changes. Thanks, cbc

1 0

The Inbox: Collections-cbc.740.mcz
by commits＠source.squeak.org 02 Mar '17

02 Mar '17

A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-cbc.740.mcz ==================== Summary ==================== Name: Collections-cbc.740 Author: cbc Time: 2 March 2017, 1:06:57.171201 pm UUID: df2ea404-5798-bd4b-abb9-2d4c05e290c0 Ancestors: Collections-ul.739 Documentation change - explain where the stream pointer is left after calling #upToAll: =============== Diff against Collections-ul.739 =============== Item was changed: ----- Method: PositionableStream>>upToAll: (in category 'accessing') ----- upToAll: aCollection + "Answer a subcollection from the current access position to the occurrence (if any, but not inclusive) of aCollection. + If aCollection is not in the stream, answer the entire rest of the stream. + The stream is left pointing to the location just after the found aCollection, or at end if not found." - "Answer a subcollection from the current access position to the occurrence (if any, but not inclusive) of aCollection. If aCollection is not in the stream, answer the entire rest of the stream." | startPos endMatch result | startPos := self position. (self match: aCollection) ifTrue: [endMatch := self position. self position: startPos. result := self next: endMatch - startPos - aCollection size. self position: endMatch. ^ result] ifFalse: [self position: startPos. ^ self upToEnd]!

1 0

Jump to page: