Squeak-dev March 2019

squeak-dev@lists.squeakfoundation.org

26 participants
85 discussions

The Trunk: Graphics-mt.406.mcz
by commits＠source.squeak.org 06 Jan '20

06 Jan '20

Marcel Taeumel uploaded a new version of Graphics to project The Trunk: http://source.squeak.org/trunk/Graphics-mt.406.mcz ==================== Summary ==================== Name: Graphics-mt.406 Author: mt Time: 17 January 2019, 11:18:39.003727 am UUID: 027d00a7-113d-4b9f-aaec-79e3373339c1 Ancestors: Graphics-mt.405 Adds an informative string representation for LayoutFrame to support layout design and debugging. =============== Diff against Graphics-mt.405 =============== Item was added: + ----- Method: LayoutFrame>>printOn: (in category 'printing') ----- + printOn: aStream + + super printOn: aStream. + + aStream nextPutAll: '( '. + + { {'l'. self leftFraction. self leftOffset}. {'t'. self topFraction. self topOffset}. {'r'. self rightFraction. self rightOffset}. {'b'. self bottomFraction. self bottomOffset} } do: [:spec | + aStream nextPutAll: spec first; space. + + spec second printOn: aStream maxDecimalPlaces: 2. + + aStream nextPutAll: ((spec third ifNil: [0]) >= 0 ifTrue: ['+'] ifFalse: ['-']). + (spec third ifNil: [0]) abs printOn: aStream maxDecimalPlaces: 0] + separatedBy: [aStream space]. + + aStream nextPutAll: ' )'.!

3 2

Drag and drop to reorder items in a single list
by Jakob Reschke 26 Nov '19

26 Nov '19

Hello everyone, tl;dr: the current PluggableTextMorph/Plus does not support the reordering of items in a single list via drag and drop. Attached you find a change set that fixes this, but it might also break in other places. Thus, I kindly ask for a review. Today I found myself implementing a ToolBuilder-built list in which the items should be reorderable via drag and drop. Unfortunately, the current implementation of PluggableTextMorph/Plus does not allow this: you first have to drag the item out of the list before you can drop it in again. Seems like the list morph needs the mouse focus to be able to accept the drop. However, the current implementation explicitly releases the focus from the list upon grabbing the item. Then I changed the PluggableTextMorphPlus to not drop the focus, but keep it, when starting to drag an item. Now the focus would not even be released anymore when the item was indeed dragged out of a list if that list itself does not accept any drops (such as the method list in the system browser: it does not accept drops, but the methods can be dragged from it to the message categories list). So I have changed further methods to make the list morphs always handle dragging events, even if they are not interested in drops. But I do not know what else that might have broken. So, please have a look at the attached change sets. The one without "all" in the file name contains only the actual changes. The one with "all" also contains other relevant (unchanged) methods that I touched during my investigation. Eventually, I would like to put this or a revised edition of it in the inbox because list reordering via drag and drop should not be impossible. The third file contains a simple Model subclass with a list whose items should be reorderable via drag and drop, so you do not have to write it yourself. Grab a sample instance and open it with the ToolBuilder: ToolBuilder open: DragDropInSingleList new. In case I simply got it wrong and there is no need to change Morphic lists to achieve what I want, please tell me how to do it right. ;-) Best regards, Jakob

3 3

When did it become a good idea for selected text to be enclosed by () instead of replaced by 9 ?
by tim Rowledge 06 Nov '19

06 Nov '19

In trying to see if anything had changed re WaveEditor etc I updated an image to update 16963. When I went to save this image a Squeak5.1-16963… I selected the last thre digits of the prior name (Squeak5.1-16549…) intending to type 963. Imagine my surprise - nay, alarm! - when I got ‘Squeak5.1-16(963) instead. Oh my, I said to myself, what has Pooh done now. As best I can work out this is a result of the change in TextEditor>enclose: that added ‘9’ some time ago (and which did not affect me since I normally turn off the annoying enclose stuff in preferences) combined with a more recent change to TextEditor>dispatchOnKeyboardEvent: wherein a use of TextEditor>enclose: was added near the end. I see two obviously related Preferences for enclosing text. I see this as a dangerous thing, because multiple preferences interacting on the same issue can cause chaos, not to say confusion. And every time a preference is added it is yet another sheaf of potential problems to test. So, yes, I can turn it off easily enough. But how could it ever be unsurprising to a user to get a(bc)d instead of the expected a9d ? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful random insult:- Fell out of the family tree.

6 6

Plans for 5.3 Morphic / Readability (Re: Squeak Oversight Board Election 2019)
by H. Hirzel 17 Sep '19

17 Sep '19

Hello Marcel a question, see below. Regards Hannes On 1/11/19, Marcel Taeumel <marcel.taeumel(a)hpi.de> wrote: > Hi, there. > > I would like to continue serving on the Squeak Oversight Board in 2019, too. > My main interests encompass user interaction (Morphic), > code modularity > (readability/extensibility), What are your suggestions / plans for 5.3 for enhancing the Morphic user interaction expericence? How do you think better readability of code could be achived? > backwards compatibility (Etoys), and > programming/productivity tools. > > During the past years, it has been a healthy mix of promising ideas, > enlightening discussions, and challenging viewpoints. I do value such > programming experiences as a great addition to my daily life. Squeak's > community is great! Thank you. :-) > > Let us continue shaping Squeak for many opportunities to come! It is an > intriguing programming system with its liveness promoting exploratory > working habits. What a time to be a "programmer". ;-) > > Best, > Marcel > Am 10.01.2019 20:38:30 schrieb Ron Teitelbaum <ron(a)usmedrec.com>: > Hi All, > > Thank you Craig for jumping right in! I would encourage everyone else to > follow Craig's lead. I know some people like to wait but the more > candidates the better. > > The lack of candidates shouldn't be an incentive for people to run and a > large number of candidates shouldn't be a reason for you to decide against > volunteering to run! We have had some excellent people run and not be > elected that would have been terrific members of the board! You show your > commitment to Squeak just by running! For those of you that say you don't > have the time or are not sure what you would have to do, we have had some > excellent answers in the past. There is no requirement or specific demands > and the board decides when and how it will meet. Most, if not all, meetings > are electronic so the demands on your time are very low! Plus the members > are all terrific people you will enjoy working with! > > Jump on in and add your name to the candidate list! > > Thanks! > > Ron Teitelbaum > > On Thu, Jan 10, 2019 at 2:49 AM Craig Latta <craig(a)blackpagedigital.com > [mailto:craig@blackpagedigital.com]> wrote: > > > Hi all-- > > I'd like to serve on the Squeak Oversight Board in 2019. With you > and my fellow board members, I intend to continue... > > - ...representing Squeak at conferences, including ESUG and the > International Conference on Live Coding[1]. > > - ...maintaining the agenda and notes at the board meetings. I > anticipate having the time to make posts to the board blog this > term. > > - ...developing symbiosis between the Squeak, JavaScript, and Web > platform communities through my work with Caffeine[2] and > SqueakJS[3]. > > I would be honored to have your vote. > > > cheers! > > Craig > > -- > > [1] http://iclc.livecodenetwork.org/2019/ingles.html > [http://iclc.livecodenetwork.org/2019/ingles.html] > [2] https://caffeine.js.org [https://caffeine.js.org] > [3] https://squeak.js.org [https://squeak.js.org] > > -- > Craig Latta > Black Page Digital > Amsterdam :: San Francisco > craig(a)blackpagedigital.com [mailto:craig@blackpagedigital.com] > +31 6 2757 7177 (SMS ok) > + 1 415 287 3547 (no SMS) > > >

2 3

Re: [squeak-dev] The Trunk: Collections-pre.822.mcz
by Chris Muller 21 Aug '19

21 Aug '19

My main objection is about growing the "mutator" nomenclature further instead of trimming it back. I'm working on a GraphQL framework. GraphQL has a first-class notion of "mutations". https://graphql.org/learn/queries/ Currently, we have almost zero mention of the word "mutator" in the image. I would appreciate if, instead of germinating the overloading the word, we uproot it and keep the nomenclature for this Smalltalk tooling confined to "getter" and "setter" that we have now. So, instead of #asMutator and #isMutator, how about #asSimpleSetter and #isSimpleSetter? We can end up removing a method instead of adding one. We already have many existing methods which are dealing with this conversion, all of which use the traditional Smalltalk / developer linguisitic of "setter". Browsing through all the "setter" nomenclature we have in a message names browser, including Utilities class>>#getterSelectorFor: Utilities class>>#setterSelectorFor: Utilities class>>#simpleSetterFor: which instruct Etoys users to use existing methods on String, #asSetterSelector or #asSimpleSetter. Of special note is SyntaxMorph>>#isStandardSetterKeyword: which, by its use of a utility-method implementation, acknowledges that this behavior is _application-specific_. I, myself, would just write: someSelector asSimpleSetter = someSelector "same as isMutator / isSimpleSetter" instead of #isSimpleSetter, but can appreciate both styles. They both better avoid the awkwardness of "mutator" as a general, reliable behavior when: #at: isMutator "true" while #at:put: isMutator "false" Best, Chris On Thu, Mar 21, 2019 at 1:16 AM <patrick.rein(a)hpi.uni-potsdam.de> wrote: > > Which one are you refering to? I only see Symbol>>#asMutator in Collections in the method category converting. It is also used in a few other places beyond generating instance variable accessors. > > Bests, > Patrick > > >#asMutator: is for "generate instVar accessors" code-generation, and > >that's why it's in the Tools package. > > > >IMHO, if #isMutator belongs anywhere, it isn't in Collections. > > > >Regards, > > Chris > > > > > > > >On Wed, Mar 20, 2019 at 3:08 PM Chris Muller <asqueaker(a)gmail.com> wrote: > >> > >> Assuming a single-keyword is a mutator? Object>>#at: is not a > >> mutator. #indexOf: is not. #first: is not. Obviously many more.. > >> > >> If API balance is the goal of this, perhaps #asMutator should be > >> removed instead. This feels application-specific... > >> > >> On Wed, Mar 20, 2019 at 2:05 PM <commits(a)source.squeak.org> wrote: > >> > > >> > Patrick Rein uploaded a new version of Collections to project The Trunk: > >> > http://source.squeak.org/trunk/Collections-pre.822.mcz > >> > > >> > ==================== Summary ==================== > >> > > >> > Name: Collections-pre.822 > >> > Author: pre > >> > Time: 20 March 2019, 8:05:20.383677 pm > >> > UUID: 483c4461-cee4-4a4f-82d3-fbc03e7201cc > >> > Ancestors: Collections-dtl.821 > >> > > >> > Adds #isMutator to Symbol which is analogous to asMutator. > >> > > >> > =============== Diff against Collections-dtl.821 =============== > >> > > >> > Item was added: > >> > + ----- Method: Symbol>>isMutator (in category 'testing') ----- > >> > + isMutator > >> > + > >> > + ^ self isKeyword and: [self numArgs = 1]! > >> > > >> > > > >

6 12

Help: fonts in PluggableTextSpec
by K K Subbu 20 May '19

20 May '19

Hi, PluggableTextSpec>>font returns a default font if font is not specified. This results in default font overriding any fonts in the plugged textmorphs :-( as in the case of Help->FontSizeSummary. The exact font to be used to render text should be determined lazily by textMorph and not in pluggable text spec. My proposed fix has a wide ranging effect, so I am posting it here for a critique before finalizing a patch to Inbox. Thanks and Regards .. Subbu

2 3

The Inbox: TraitsTests-pre.19.mcz
by commits＠source.squeak.org 04 May '19

04 May '19

Patrick Rein uploaded a new version of TraitsTests to project The Inbox: http://source.squeak.org/inbox/TraitsTests-pre.19.mcz ==================== Summary ==================== Name: TraitsTests-pre.19 Author: pre Time: 28 March 2019, 3:30:48.769796 pm UUID: 2ed07595-23e5-5f41-92ef-17c27ad0a017 Ancestors: TraitsTests-ul.18 Adds a test case for removing traits from a class by simply executing a class creation method without a trait composition. This does currently not yet work. =============== Diff against TraitsTests-ul.18 =============== Item was added: + ----- Method: TraitTest>>expectedFailures (in category 'failures') ----- + expectedFailures + + ^ #(testRemoveTraitBySimpleClassDefinition)! Item was added: + ----- Method: TraitTest>>testRemoveTraitBySimpleClassDefinition (in category 'testing') ----- + testRemoveTraitBySimpleClassDefinition + + | classAv1 classAv2 | + classAv1 := self createClassNamed: #TraitTestMethodClassA superclass: Object uses: T1. + classAv2 := self createClassNamed: #TraitTestMethodClassA superclass: Object. + + self assert: classAv1 == classAv2. + self assert: classAv2 traits isEmpty.! Item was added: + ----- Method: TraitsTestCase>>createClassNamed:superclass: (in category 'utility') ----- + createClassNamed: aSymbol superclass: aClass + | class | + class := aClass + subclass: aSymbol + instanceVariableNames: '' + classVariableNames: '' + poolDictionaries: '' + category: self categoryName. + self createdClassesAndTraits add: class. + ^class!

10 18

SqueakMap updating fails to update files
by tim Rowledge 28 Apr '19

28 Apr '19

I've been trying to update the NuScratch packages a bit and having 'fun'. The first problem was simply trying to install the current version; the gpio package has two dependencies and one of them complained that it could not be found. That would be JSON->tonyg.37. Which was a moment's confusion because that is not listed on SM at all, where the versions are 39 a&b. Then I looked at the mcz file in a zip window and noticed that the json tonyg.37 package was included within the mcz, which added some more confusion because it's *right there* so how can it not be found? After much puzzling I was able to change the dependency to the newer JSON->tony39b and get it uploaded to squeaksource. Anyone wanting a nice monticello project could do worse than improving the tools around those dependencies; we don't see relevant info anywhere except (so far as I could find) in the info window displayed just after saving a package. Nor does it seem we can removed just one dependency out of several. I then needed to update the SM entry in order to load the updated gpio package. Unfortunately this failed to upload properly - eventually I got a timeout error, which locked up the image for a couple of minutes before finally returning control to me. It looks like the http://map.squeak.org/accountbyid/4340a66e-2296-48b7-9aa8-5305d303752f/file… file didn't get there - attemtping to fetch it results in a 'not here mate' error. Rather confusingly the SM tool does actually show the new version in the list, which isn't reflected in the reality of the web server - opening another image to check in a separate SM catalog shows the lack of the new version. I guess it would be nice to only update the SM tool if the upload is successful. Two attempts have failed to achieve anything and I don't want to overload the server image if it is having problems. What next? tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Try not to let implementation details sneak into design documents.

4 17

Re: [squeak-dev] The Trunk: Collections-pre.822.mcz
by Chris Muller 24 Apr '19

24 Apr '19

> Sorry to open this up again. I have progressed well in shuffling things around. However: While moving the corresponding test cases I noticed that there is also #isBinary, #isDoIt, #isInfix, #isUnary, #isKeyword, and #isPvtSelector implemented on Symbol. Given that these all exist, I would rather keep #asSimpleSetter, #isSimpleSetter, #asSetterSelector in the Collections package. > > Any other oppinions on that? Virtually every classic description of the Smalltalk language in books and classes I can remember talks about "three kinds of message names, unary, binary, and keyword..." For example, here it is on the Complete Smalltalk Syntax on a Postcard: https://medium.com/@richardeng/syntax-on-a-post-card-cb6d85fabf88 So, I think those three belong in Collections. "Setter" relates to making a setter method. That's tooling. So the only reason I would have anything "setter" in Collections is if there are enough senders from different depending packages that Collections is the only common ancestor between them. Best, Chris

2 1

The Inbox: Environments-cmm.75.mcz
by commits＠source.squeak.org 22 Apr '19

22 Apr '19

Chris Muller uploaded a new version of Environments to project The Inbox: http://source.squeak.org/inbox/Environments-cmm.75.mcz ==================== Summary ==================== Name: Environments-cmm.75 Author: cmm Time: 17 February 2019, 8:54:02.934673 pm UUID: 13aceb53-d0e1-4823-a86c-a2abacb6c2d9 Ancestors: Environments-pre.73 Keep and access Classes and Traits by their #name's logical value instead of the physical identity of the String object. =============== Diff against Environments-pre.73 =============== Item was removed: - (PackageInfo named: 'Environments') preamble: '"Fix ''Instances'' entry for Smalltalk Environment." - | dict | - dict := (Environment classPool at: ''Instances''). - dict keys - do: [ : eachName | (eachName isSymbol not ) ifTrue: [ dict at: eachName asSymbol put: (dict removeKey: eachName) ] ]. - - "Let Environment names be, consistently, Symbols." - Environment allInstances do: - [ : each | - each info - instVarNamed: ''name'' - put: (each name asSymbol) ]'! Item was changed: ----- Method: Environment>>allClassesAndTraitsDo: (in category 'classes and traits') ----- allClassesAndTraitsDo: aBlock declarations keysAndValuesDo: [:key :value | + ((value isBehavior) and: [key = value name]) ifTrue: - ((value isBehavior) and: [key == value name]) ifTrue: [aBlock value: value]]! Item was changed: ----- Method: Environment>>classOrTraitNamed: (in category 'classes and traits') ----- classOrTraitNamed: aString "aString is either a class or trait name or a class or trait name followed by ' class' or 'classTrait' respectively. Answer the class or metaclass it names." | meta baseName | (aString endsWith: ' class') ifTrue: [meta := true. baseName := aString copyFrom: 1 to: aString size - 6] ifFalse: [ (aString endsWith: ' classTrait') ifTrue: [ meta := true. baseName := aString copyFrom: 1 to: aString size - 11] ifFalse: [ meta := false. baseName := aString]]. + ^declarations at: baseName ifPresent: - ^declarations at: baseName asSymbol ifPresent: [ :global | global isBehavior ifTrue: [ meta ifFalse: [ global ] ifTrue: [ global classSide ]]]! Item was changed: ----- Method: Environment>>hasClassNamed: (in category 'classes and traits') ----- + hasClassNamed: aString + ^ declarations + at: aString + ifPresent: [ : global | global isKindOf: Class ] + ifAbsent: [ false ]! - hasClassNamed: aString - Symbol hasInterned: aString ifTrue: - [:symbol | - ^ (declarations at: symbol ifAbsent: [nil]) - isKindOf: Class]. - ^ false.! Item was changed: ----- Method: Environment>>initialize (in category 'initialize-release') ----- initialize + declarations := Dictionary new. + bindings := Dictionary new. - declarations := IdentityDictionary new. - bindings := IdentityDictionary new. undeclared := WeakIdentityDictionary new. policies := Array new. observers := IdentitySet new.! Item was changed: ----- Method: Environment>>removeClassNamed: (in category 'classes and traits') ----- removeClassNamed: aString declarations + at: aString - at: aString asSymbol ifPresent: [:class | class removeFromSystem] ifAbsent: [Transcript cr; show: 'Removal of class named ', aString, ' ignored because ', aString, ' does not exist.']! Item was added: + (PackageInfo named: 'Environments') postscript: '"Fix ''Instances'' entry for Smalltalk Environment." + | dict | + dict := (Environment classPool at: ''Instances''). + Environment classPool at: ''Instances'' put: (dict := dict as: Dictionary). + + "Fix ''delcarations'' and ''bindings'' of existing Environments." + Environment allInstances do: + [ : each | + #(''declarations'' ''bindings'') do: [ : eachIdDictVar | (each instVarNamed: eachIdDictVar put: ((each instVarNamed: eachIdDictVar) as: Dictionary)) ] ]'!

3 2

← Newer
1
2
3
4
5
6
7
8
9
Older →