Squeak-dev September 2016

squeak-dev@lists.squeakfoundation.org

46 participants
175 discussions

Installing Filetree
by Bert Freudenberg 02 May '17

02 May '17

Hi all, Dale has been working on a Squeak version of FileTree, which is a Monticello repository backed not by zip files, but a tree of individual class files that can be versioned using git, svn, etc: https://github.com/dalehenrich/filetree/blob/master/doc/SqueakInstall.md Since I don't like cluttering my image with unrelated things, here's how to load it using just Installer - provided you have an up-to-date trunk image with the fixes I posted today: ======================== "Bootstrap from squeak43 branch in squeaksource3" Installer ss3 project: 'FileTree'; install: 'MonticelloFileTree-Core.squeak43'. "Load from local filetree repository (cloned squeak4.3 branch from github into image folder)" Installer monticello mc: (MCFileTreeRepository directory: (FileDirectory uri: 'filetree/repository/')); install: 'MonticelloFileTree-Core' ======================== If you have an older image without the new fixes, giving an explicit version number for the ss3 bootstrap should make it work (e.g. 'MonticelloFileTree-Core.squeak43-dkh.70'). - Bert -

9 39

Re: The Trunk: Morphic-topa.784.mcz
by Marcel Taeumel 10 Apr '17

10 Apr '17

Nice! :) <http://forum.world.st/file/n4813138/font-importer.png> Two questions: 1. Who does the rendering? Looks kind of irregular... See attachment. 2. Can we move it to the "Tools" package? Best, Marcel -- View this message in context: http://forum.world.st/The-Trunk-Morphic-topa-784-mcz-tp4813130p4813138.html Sent from the Squeak - Dev mailing list archive at Nabble.com.

4 14

Seaside3.2 on Squeak5.1 is working well.
by Tobias Pape 08 Nov '16

08 Nov '16

Hi all I just want to report that Seaside3.2 works well on Squeak5.1 with 1422 passing tests. [1] Thanks for everyone developing Seaside and/or Squeak for taking care! Yay! Best regards -Tobias [1]: There's only one Test error because "'Seaside-Pharo-Continuation' depends on unknown package 'Grease-Pharo-Core'" which is obviously not loaded on Squeak, but gladly that does not hamper functionality.

3 2

Environment declarations vs bindings
by Nicolas Cellier 05 Oct '16

05 Oct '16

Since we are at reviewing Environment, here is a small detail that bothers me. I already asked some months ago, but silence was the only response, so ping. Implementation of Environment is sometimes not obvious: - Environment>>associationAt: uses declarations inst.var.. - Environment>>associationOrUndeclaredAt: uses bindings inst.var. How can it be so different, the selector does not speak, does it? OK, there is a flag: #review in one of them, but that does not make code clearer, it's just a smell of over-complexity or ill-naming. Whatever the reason (self explaining code?) Colin does not comment class/methods, that's a fact. Chris made the effort of commenting Environment but then came this declarations/bindings split, and the comment did rapidly rot. We have here an un-healthy statu quo crying for change. So if we want to at least comment the class with the meaning/role/responsibility of inst vars, here is my understanding: environment bind: #Foo to: 0. just add to the declarations. (You see how names are not obvious: bind does not bind the new binding to bindings). If the Environment importSelf, then the ClassBinding/Global also goes to bindings... (thru an observer pattern and the magic of naming policies) The bindings is what is used by the compiler, so what if an environment does not importSelf? It means that the variable it declares are not bound, so it is not reachable (kind of invisible class/Global). IOW, the bindings will contain all the imports, including self-imports. importSelf is generally what we want to do, unless weird cases of powerless environment for obfuscation or trustless sandboxing reason. Now, associationAt: does not speak for itself. It's too hard to decide if we're speaking of own declarations or bindings... Analyzing the usage is difficult. bindingAt: would be less ambiguous, so IMO we cannot fix without semantic shift. The semantic will be carried by the senders (the Tools), and the tools by usage we want to make of Environment. So we first have to define that: what feature do we want to support? With which tool? That probably require yet another thread...

5 6

Re: [squeak-dev] Environment declarations vs bindings
by Jakob Reschke 04 Oct '16

04 Oct '16

Many questions should be answered with tooling here, but in the particular case I mentioned, IMHO it is not about tooling. Until now, code that does `Smalltalk at: something` wants to look up something dynamically or it can't be sure that this class is actually loaded. As there was only one place to do such lookups, no differentiation about visibility or the source of a binding was necessary. Instances of `Smalltalk at: something` should either be replaced by an environment aware equivalent that makes clear if a name should be looked up *only* in the receiving environment (in its declarations), or if a name should be resolved, looking also in imported environments (in the bindings). As it is inconvenient to find all these pieces of code and change them all, `Smalltalk (globals)` could be the "active" environment (currently via dynamic scoping with `on: CurrentEnvironment do: ...`), not the original global environment. But then Environment>>at: must behave sensibly. I would expect that I can always do `Smalltalk at: #Object` to retrieve `Object` in any environment (under the assumption that every environment would import the "Kernel" or original environment). This is currently not the case, because Environment>>at: looks only into an environment's (own) declarations, not the imported bindings. 2016-09-29 17:30 GMT+02:00 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > > > 2016-09-29 15:15 GMT+02:00 Jakob Reschke <jakob.reschke(a)student.hpi.de>: >> >> Hi, >> >> Environment>>associationAt: is part of the Smalltalk globals >> Dictionary compatibility interface, right? As a quick and dirty fix, I >> changed instances of Smalltalk at: xyz in Monticello code to >> CurrentEnvironment signal at: xyz, but #at: also only reads in the >> declarations, so myEnvironment at: #MCWriter or myEnvironment at: >> #Object returns nil by default. It would make more sense to perform a >> full lookup via #valueOf:ifAbsent: in #at: and its cousins, wouldn't >> it? >> >> Best, >> Jakob >> > > I imagine that the question is about tools. > For now Smalltalk importSelf, so bindings and declarations do agree. > If an Environment does not importSelf, then some variables will be > invisibles (unbounds). Do we still want to see them in some tool, or not? > What's going on if we play with Alias? Do we want to see the Alias in some > browser? If not, then we'd better stick with declarations. > There is no easy solution. A single facade for two dictionaries cannot fit > all, so we need several different messages. > But it's much about what we want to do with those environments. > > >> >> 2016-09-29 7:33 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: >> > On 9/28/16, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: >> >> Since we are at reviewing Environment, here is a small detail that >> >> bothers >> >> me. I already asked some months ago, but silence was the only response, >> >> so >> >> ping. >> >> >> >> Implementation of Environment is sometimes not obvious: >> >> - Environment>>associationAt: uses declarations inst.var.. >> >> - Environment>>associationOrUndeclaredAt: uses bindings inst.var. >> >> How can it be so different, the selector does not speak, does it? >> >> >> >> OK, there is a flag: #review in one of them, but that does not make >> >> code >> >> clearer, it's just a smell of over-complexity or ill-naming. >> >> >> >> Whatever the reason (self explaining code?) Colin does not comment >> >> class/methods, that's a fact. >> > >> > Alternatively a description of the general ideas and the mechanism would >> > help. >> > >> > After all Environments is just a clever combination of a few >> > dictionaries to look up class names? Isn't it? ;-) >> > >> > However the fact that people did not move on much finalising the >> > implementation of environments since 2012 shows that it is hard to >> > reverse-engineer the intentions from the (incomplete) code. >> > >> > >> > >> > >> > >> >> Chris made the effort of commenting Environment but then came this >> >> declarations/bindings split, and the comment did rapidly rot. >> >> We have here an un-healthy statu quo crying for change. >> >> >> >> So if we want to at least comment the class with the >> >> meaning/role/responsibility of inst vars, here is my understanding: >> >> >> >> environment bind: #Foo to: 0. just add to the declarations. >> >> (You see how names are not obvious: bind does not bind the new binding >> >> to >> >> bindings). >> > >> > Environments >> > >> > bind: aSymbol to: anObject >> > | binding newBinding | >> > newBinding := aSymbol => anObject. >> > >> > binding := declarations associationAt: aSymbol ifAbsent: [nil]. >> > binding ifNotNil: >> > [binding class == newBinding class >> > ifTrue: [binding value: anObject] >> > ifFalse: [binding becomeForward: newBinding]. >> > ^anObject]. >> > >> > binding := undeclared associationAt: aSymbol ifAbsent: [nil]. >> > binding >> > ifNil: [binding := newBinding] >> > ifNotNil: >> > [undeclared removeKey: aSymbol. >> > binding class == newBinding class >> > ifTrue: [binding value: anObject] >> > ifFalse: [binding becomeForward: >> > newBinding]]. >> > >> > declarations add: binding. >> > self binding: binding addedTo: self. >> > ^anObject >> > >> > >> > Could you elaborate a bit please? >> > >> > >> > >> > >> >> If the Environment importSelf, then the ClassBinding/Global also goes >> >> to >> >> bindings... (thru an observer pattern and the magic of naming policies) >> >> >> >> The bindings is what is used by the compiler, so what if an environment >> >> does not importSelf? It means that the variable it declares are not >> >> bound, >> >> so it is not reachable (kind of invisible class/Global). >> >> >> >> IOW, the bindings will contain all the imports, including self-imports. >> >> importSelf is generally what we want to do, unless weird cases of >> >> powerless >> >> environment for obfuscation or trustless sandboxing reason. >> >> >> >> Now, associationAt: does not speak for itself. It's too hard to decide >> >> if >> >> we're speaking of own declarations or bindings... Analyzing the usage >> >> is >> >> difficult. bindingAt: would be less ambiguous, so IMO we cannot fix >> >> without >> >> semantic shift. >> > >> > This would need as well elaboration as well a separate thread. >> > >> > >> >> The semantic will be carried by the senders (the Tools), and the tools >> >> by >> >> usage we want to make of Environment. So we first have to define that: >> >> what >> >> feature do we want to support? With which tool? That probably require >> >> yet >> >> another thread... >> > >> > Yes >> > >> > --Hannes >> > >> >

12 21

Re: [squeak-dev] How to create a 'Hello world' example for environments
by Jakob Reschke 01 Oct '16

01 Oct '16

Hello, Looks good to me as an outline. I have the following comments, questions or doubts: 1. Currently, for me it does not feel like "entering" or "leaving" an Environment, as that works with dynamic scoping in a block. So step 8 could turn out to be void. 2. Since all of this should go into a workspace, not into the browser, what is the shortest applicable snippet of code that, given a source code string and a class, creates a new method in that class? 3. I am not sure what will happen if you attempt to create a subclass that has the same name as another imported class. Generally, evaluating Superclass subclass: #Subclass ... a second time will replace the former Subclass by the new Subclass. 'myEnvironment' would have imported Hello from Smalltalk globals, so an "old" Hello is already visible. We have to check that evaluating the subclass expression will not try to update that existing Hello class, but create a new one instead. Here, the "shallow" lookup mechanism would be needed. Once I have figured out 2. I will try out and check 3. ;-) Kind regards, Jakob 2016-09-30 13:29 GMT+02:00 H. Hirzel <hannes.hirzel(a)gmail.com>: > Starting a new thread, culled from the thread 'What are environments for'. > > There are many more good questions and thoughts in the thread 'What > are environments for' but this thread is just about what the subject > says: > > How to create a 'Hello world' example for environments > > --Hannes > > On 9/29/16, David T. Lewis <lewis(a)mail.msen.com> wrote: >> On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote: >>> On 9/29/16, Jakob Reschke <jakob.reschke(a)student.hpi.de> wrote: >>> > Hi Nicolas, >>> > >>> > First, thank you for answering me in the other thread. >>> > >>> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier >>> > <nicolas.cellier.aka.nice(a)gmail.com>: >>> >> Without clear goals or vision, fixing could essentially mean "let >>> >> Environment be transparent", that is let it remain a promise, a >>> >> potential, >>> >> whithout too many side effects... Not exactly YAGNI, just a bit of >>> >> over-engineered nice piece of code that might serve later. OK this >>> >> sounds >>> >> like a mandatory first step. > > >>> > I don't quite get what you mean by transparent, other than fixing it >>> > and enhancing the documentation to shed some light on what it is, why >>> > it is there and how to use it. > .. > ... > >>> Another maybe simple use case could be to have a project specific >>> environment set up when you enter a project >>> (http://wiki.squeak.org/squeak/1020). >>> >>> We now have very nicely cleaned up Project code in Squeak 5.1 >>> >>> 1) Subclass MorphicProject --- MyMorphicProject >>> 2) Subclass PasteUpMorph --- MyPasteUpMorph >>> 3) Override #initialize in MyMorphicProject and use MyPasteUpMorph >>> 4) ... some more adaptations ..... to enter a new Environment -- how? >>> >> >> I like this idea a lot. >> >> I would love to see a simple "hello world!" level example of Environments. >> If someone could make an EnvironmentsDemoProject that opens a new project >> with >> something that changes Duck>>speak ==> 'quack' to Duck>>speak ==> 'moo', >> I think it might really help me to understand how to use Environments. >> >> Dave > > So let's focus on a 'hello world' example for environments and do it > _slowly_ step by step so that people can catch up with the issues. > > > > Outline of steps of a 'Hello world' environments example > ============================================= > > Steps > > > 1. subclass Object with a #Hello class. > > 2. compile a class method #say the method should write 'Hello' to the Transcript > > 3. run > Hello say > > The result should be 'Hello' on the Transcript > > > 4. create a new Environment called "myEnvironment". > > 5. import the Smalltalk environmnet into myEnvironment > > 6. subclass Object with a #Hello class in myEnvironment > > 7. compile a method #say the method should write 'Buenas dias' to the Transcript > > run > Hello say > > Result should be > > 30-Sept-2016 > > Starting a new thread, culled from the thread 'What are environments for'. > > There are many more good questions and thoughts in the thread 'What > are environments for' but this thread is just about what the subject > says: > > How to create a 'Hello world' example for environments > > --Hannes > > On 9/29/16, David T. Lewis <lewis(a)mail.msen.com> wrote: >> On Thu, Sep 29, 2016 at 07:51:23AM +0200, H. Hirzel wrote: >>> On 9/29/16, Jakob Reschke <jakob.reschke(a)student.hpi.de> wrote: >>> > Hi Nicolas, >>> > >>> > First, thank you for answering me in the other thread. >>> > >>> > 2016-09-28 23:02 GMT+02:00 Nicolas Cellier >>> > <nicolas.cellier.aka.nice(a)gmail.com>: >>> >> Without clear goals or vision, fixing could essentially mean "let >>> >> Environment be transparent", that is let it remain a promise, a >>> >> potential, >>> >> whithout too many side effects... Not exactly YAGNI, just a bit of >>> >> over-engineered nice piece of code that might serve later. OK this >>> >> sounds >>> >> like a mandatory first step. > > >>> > I don't quite get what you mean by transparent, other than fixing it >>> > and enhancing the documentation to shed some light on what it is, why >>> > it is there and how to use it. > .. > ... > >>> Another maybe simple use case could be to have a project specific >>> environment set up when you enter a project >>> (http://wiki.squeak.org/squeak/1020). >>> >>> We now have very nicely cleaned up Project code in Squeak 5.1 >>> >>> 1) Subclass MorphicProject --- MyMorphicProject >>> 2) Subclass PasteUpMorph --- MyPasteUpMorph >>> 3) Override #initialize in MyMorphicProject and use MyPasteUpMorph >>> 4) ... some more adaptations ..... to enter a new Environment -- how? >>> >> >> I like this idea a lot. >> >> I would love to see a simple "hello world!" level example of Environments. >> If someone could make an EnvironmentsDemoProject that opens a new project >> with >> something that changes Duck>>speak ==> 'quack' to Duck>>speak ==> 'moo', >> I think it might really help me to understand how to use Environments. >> >> Dave > > So let's focus on a 'hello world' example for environments and do it > _slowly_ step by step so that people can catch up with the issues. > > > > Outline of steps of a 'Hello world' environments example > ============================================= > > Steps > > > 1. subclass Object with a #Hello class. > > 2. compile a class method #say the method should write 'Hello' to the Transcript > > 3. run > Hello say > > The result should be 'Hello' on the Transcript > > > 4. create a new Environment called "myEnvironment". > > 5. import the Smalltalk environmnet into myEnvironment > > 6. subclass Object with a #Hello class in myEnvironment > > 7. compile a method #say the method should write 'Buenas dias' to the Transcript > > run > Hello say > > The result should be 'Buenas dias' on the Transcript > > > 8. Leave environment called 'myEnvironment' > > > 9. run > Hello say > > The result should be this time 'Hello' on the Transcript > > > > Any comments on these steps? >

5 4

New, faster RISC OS Squeak
by Chris Cunnington 01 Oct '16

01 Oct '16

I get a File 'System:Modules.StreamMan' not found error. I take it from here [1] [2] that StreamMan is short for StreamManager. And that it should be in the sharedsoundbuffer.!System folder. I shift+double clicked and followed !Shared.350.Modules to see StreamMan in this directory. The file appears present but still there is an error. Chris [1] http://permalink.gmane.org/gmane.comp.lang.smalltalk.squeak.vm.devel/9468 [2] http://www.raspberrypi.org/phpBB3/viewtopic.php?t=29504&p=278048

5 15

Re: [squeak-dev] Environment declarations vs bindings
by Jakob Reschke 01 Oct '16

01 Oct '16

I suppose nobody of us wants throw everything over and force Environments onto it. All of this is about opportunities that were available if Environments could actually be used and operated intuitively, right? I, too, think that you should not have to care about Environments if you do not want to. Though, it might be neccessary or advantageous in some uncommon cases, some of which we have collected already. Some code, however, like the loading facilities of Monticello, currently seem to not play very well together with Environments (because of the access to the Smalltalk dictionary, how that is implemented in Environment, and the dynamic binding issue). But if you cannot load/install something into an Environment and if there are no (additional) tools to put code into an Environment and then run it, then how are you supposed to make use of the feature? Now that I formulated it that way, I think somebody claimed to already use Environments for something at some point in another, older discussion. I would like to know how they did it, given Environments' current state. If you only refer to the dynamic Environment issue with your comment about added complexity, an alternate solution would possibly be to add explicit environment parameters to all facilities that would need them and that do not have them yet (thinking of Monticello again). But that seems even more invasive to me and it bloats interfaces if you also want to keep the existing environment-agnostic interface, which we certainly want to do. Kind regards, Jakob 2016-09-30 23:36 GMT+02:00 Chris Muller <asqueaker(a)gmail.com>: >>> I don't like the idea of CurrentEnvironment at all. IMO global state >>> stinks. >>> It would mean that a lotta behavior would change by simply switching one >>> shared variable... >>> I see it more like a not so clever workaround to make tools still work in >>> presence of environments with minimal changes. >> >> >> Global state does indeed stink, which is why Environments is so nice, >> because "global" isn't global anymore. > > This deserves some qualification. Its true that writable globals > stink, you never know what state its going to be in, and updating it > introduces contention, etc. However, Class names don't suddenly point > to a different class object within the context of a running > application, and no one ever replaces Smalltalk with a new instance. > These globals are just "there" -- read-only bindings which don't > suffer the stinky issues associated with writable globals. > > I'm glad Nicolas started the other thread asking "what's it for?" To > me, that's the most important question -- is there something actually > truly useful gained in exchange for complicating the language and > tools? Is it only about everyone being able to have elegant, > prefix-less class names all loaded into one image? Most of the > use-cases mentioned in this and the other threads were just "cool ways > to handle a one-off problem." > > For the real world, we have been wanting smaller, more modular images. > The conditions of having less code and responsibility in those smaller > images bodes them less likely to benefit from Environments. Multiple > small images passing messages over the network lets those Smalltalk > applications run on multiple processor cores, compared to one > monolithic image with all the code loaded and disambiguated via a > hierarchy of Environment imports/exports and running on just one > process core. > > In 15 years, I think I've had just one name collision between classes > of different packages (neither of which used prefixes). I think I > simply renamed one of them. Dynamic system. With Environments, I > would still have had to write some code to do various > imports/exports/renames, etc.. and so it doesn't actually save me any > development effort. I guess it boils down to letting me keep pretty, > but ambiguous, names in the code. But, I actually prefer prefixes... > > Not trying to be a party pooper, but complexity is commonplace, > simplicity is rare. If we still have a simple system, we should value > that aspect and try to keep it that way. At least _optionally_... > > Best, > Chris >

1 0

Daily Commit Log
by commits＠source.squeak.org 30 Sep '16

30 Sep '16

Changes to Trunk (http://source.squeak.org/trunk.html) in the last 24 hours: http://lists.squeakfoundation.org/pipermail/packages/2016-September/068986.… Name: EToys-tfel.265 Ancestors: EToys-tfel.264 - remove the old KedamaVectorizer class - remove all autogenerated methods - make it so that any user defined script call to a turtle forces the surrounding conditionals be sequentially executed. this can be optimized further, but considering we'll rewrite this entire thing anyway, it might not be worth it right now. ============================================= http://lists.squeakfoundation.org/pipermail/packages/2016-September/068987.… Name: MorphicExtras-tfel.200 Ancestors: MorphicExtras-tfel.199 remove cached thumbnails from book morph pages before saving them ============================================= http://lists.squeakfoundation.org/pipermail/packages/2016-September/068988.… Name: EToys-tfel.266 Ancestors: EToys-tfel.265 for now, always compile scripts in the global environment. =============================================

1 0

Re: [squeak-dev] The Trunk: Kernel-nice.1042.mcz
by Tim Felgentreff 30 Sep '16

30 Sep '16

This breaks compiling EToys scripts when those refer to global classes. I probably don't understand something here, but for context, EToys players are not in the global environment, they create their own otherwise empty environment. On Thu, 29 Sep 2016 at 10:19 <commits(a)source.squeak.org> wrote: > Nicolas Cellier uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-nice.1042.mcz > > ==================== Summary ==================== > > Name: Kernel-nice.1042 > Author: nice > Time: 29 September 2016, 10:15:16.009388 am > UUID: 8923b113-72cf-414e-802c-cef7c50f8ad1 > Ancestors: Kernel-tfel.1041, Kernel-nice.798 > > Merge Kernel-nice.798 (variable scope fix, don't resolve name in > superclass environment) > > Reminder: this requires some Smalltalk exportSelf. > > =============== Diff against Kernel-tfel.1041 =============== > > Item was changed: > ----- Method: Class>>bindingOf:environment: (in category 'compiling') > ----- > bindingOf: varName environment: anEnvironment > "Answer the binding of some variable resolved in the scope of the > receiver" > | aSymbol binding | > aSymbol := varName asSymbol. > > + "First look in local classVar dictionary." > + binding := self classPool bindingOf: aSymbol. > + binding ifNotNil:[^binding]. > - "First look in classVar dictionary." > - (self classThatDefinesClassVariable: aSymbol) ifNotNil: > - [:x | ^x classPool bindingOf: aSymbol]. > > + "Next look in local shared pools." > - "Next look in shared pools." > self sharedPools do:[:pool | > binding := pool bindingOf: aSymbol. > binding ifNotNil:[^binding]. > ]. > > + "Next look into superclass pools" > + superclass ifNotNil: [^ superclass bindingOf: aSymbol environment: > anEnvironment]. > + > + "No more superclass... Last look in declared environment." > + ^anEnvironment bindingOf: aSymbol > - "Next look in declared environment." > - binding := anEnvironment bindingOf: aSymbol. > - binding ifNotNil:[^binding]. > > - "Finally look higher up the superclass chain and fail at the end." > - superclass == nil > - ifTrue: [^ nil] > - ifFalse: [^ superclass bindingOf: aSymbol]. > - > ! > > >

2 2

Jump to page: