Squeak-dev April 2018

squeak-dev@lists.squeakfoundation.org

47 participants
159 discussions

The Inbox: Morphic-kfr.1422.mcz
by commits＠source.squeak.org 29 Apr '18

29 Apr '18

A new version of Morphic was added to project The Inbox: http://source.squeak.org/inbox/Morphic-kfr.1422.mcz ==================== Summary ==================== Name: Morphic-kfr.1422 Author: kfr Time: 29 April 2018, 9:50:40.210436 am UUID: a103be7a-8442-c044-b18d-2718839b486a Ancestors: Morphic-kfr.1421 Reverting some changes to BorderStyles so #inset and #raised works again. Uses lazy initializion for baseColor =============== Diff against Morphic-kfr.1421 =============== Item was changed: ----- Method: ComplexBorder>>trackColorFrom: (in category 'color tracking') ----- trackColorFrom: aMorph + baseColor ifNil:[self color: aMorph raisedColor].! - baseColor isTransparent ifTrue:[self color: aMorph raisedColor].! Item was changed: ----- Method: InsetBorder>>trackColorFrom: (in category 'color tracking') ----- trackColorFrom: aMorph + baseColor ifNil:[self color: aMorph insetColor].! - baseColor isTransparent ifTrue:[self color: aMorph insetColor].! Item was changed: ----- Method: RaisedBorder>>trackColorFrom: (in category 'color tracking') ----- trackColorFrom: aMorph + baseColor ifNil:[self color: aMorph raisedColor].! - baseColor isTransparent ifTrue:[self color: aMorph raisedColor].! Item was changed: ----- Method: SimpleBorder>>initialize (in category 'initialize-release') ----- initialize + width := 0. - - width := 0. + ! - color := Color transparent!

1 0

The Trunk: Tools-cmm.808.mcz
by commits＠source.squeak.org 28 Apr '18

28 Apr '18

Chris Muller uploaded a new version of Tools to project The Trunk: http://source.squeak.org/trunk/Tools-cmm.808.mcz ==================== Summary ==================== Name: Tools-cmm.808 Author: cmm Time: 28 April 2018, 3:27:07.649576 pm UUID: 941a22f6-3add-4476-951b-65c2ad89ba4b Ancestors: Tools-cmm.807 Fix UndefinedObject DNU #isUniClass when opening a MessageSet containing invalid MethodReferences. =============== Diff against Tools-cmm.807 =============== Item was changed: ----- Method: MessageSet>>initializeMessageList: (in category 'private') ----- initializeMessageList: anArray "Initialize my messageList from the given list of MethodReference or string objects. NB: special handling for uniclasses. + Do /not/ replace the elements of anArray if they are already MethodReferences, so as to allow users to construct richer systems, such as differencers between existing and edited versions of code." - Do /not/ replace the elements of anArray if they are already MethodReferences, so as to allow users to construct richer - systems, such as differencers between existing and edited versions of code." - messageList := OrderedCollection new. anArray do: [:each | each isMethodReference ifTrue: [messageList addLast: each] ifFalse: [MessageSet parse: each toClassAndSelector: [ :class :sel | class ifNotNil: [ messageList addLast: ( MethodReference new class: class selector: sel)] ]]]. - "Unify labels if wanted." self class useUnifiedMessageLabels ifTrue: [ messageList do: [:each | | cls | cls := each actualClass. + each stringVersion: + (cls + ifNil: [each asString] + ifNotNil: + [cls isUniClass + ifTrue: [cls typicalInstanceName, ' ', each selector] + ifFalse: [cls name , ' ' , each selector , ' {' , + ((cls organization categoryOfElement: each selector) ifNil: ['']) , '}' , + ' {', cls category, '}']])]]. - each stringVersion: (cls isUniClass - ifTrue: [cls typicalInstanceName, ' ', each selector] - ifFalse: [cls name , ' ' , each selector , ' {' , - ((cls organization categoryOfElement: each selector) ifNil: ['']) , '}' , - ' {', cls category, '}'])]]. - messageListIndex := messageList isEmpty ifTrue: [0] ifFalse: [1]. contents := ''!

1 0

Move classes between packages in Trunk
by karl ramberg 28 Apr '18

28 Apr '18

Hi, I have not found any documentation for moving classes between packages in Trunk. I know I have done it before but I can't remember the procedure. Do you have to move the class first in one update and then delete it from the other package in an other update ? Best, Karl

2 1

The Trunk: Morphic-kfr.1421.mcz
by commits＠source.squeak.org 28 Apr '18

28 Apr '18

Karl Ramberg uploaded a new version of Morphic to project The Trunk: http://source.squeak.org/trunk/Morphic-kfr.1421.mcz ==================== Summary ==================== Name: Morphic-kfr.1421 Author: kfr Time: 28 April 2018, 11:15:32.487436 am UUID: be62513b-d2ac-9146-a2bf-67f86cee7f04 Ancestors: Morphic-cmm.1420 Change to send to a implemented selector =============== Diff against Morphic-cmm.1420 =============== Item was changed: ----- Method: PianoRollNoteMorph>>mouseMove: (in category 'event handling') ----- mouseMove: evt | delta offsetEvt | editMode isNil ifTrue: ["First movement determines edit mode" ((delta := evt cursorPoint - hitLoc) dist: 0 @ 0) <= 2 ifTrue: [^self "No significant movement yet."]. delta x abs > delta y abs ifTrue: [delta x > 0 ifTrue: ["Horizontal drag" editMode := #selectNotes] ifFalse: [self playSound: nil. + offsetEvt := evt copy cursorPoint: evt cursorPoint + (20 @ 0). - offsetEvt := evt copy setCursorPoint: evt cursorPoint + (20 @ 0). self invokeNoteMenu: offsetEvt]] ifFalse: [editMode := #editPitch "Vertical drag"]]. editMode == #editPitch ifTrue: [self editPitch: evt]. editMode == #selectNotes ifTrue: [self selectNotes: evt]!

1 0

Re: [squeak-dev] [Vm-dev] How to yellow click with two buttons without changing mouse settings?
by Marcel Taeumel 27 Apr '18

27 Apr '18

Hi Tim, it is already in place to convert CTRL+UP/DOWN into MouseWheelEvents. See HandMorph >> #initForEvents HandMorph >> #filterEvent:for: HandMorph >> #generateMouseWheelEvent:direction: Would be nice if the VM would actually deliver mouse-wheel events. See: EventSensor >> #processMouseWheelEvent: EventSensorConstants class >> #initialize Would be VERY EASY to provide a similar conversion for CTRL+RED clicks if needed for single-button mice. Best, Marcel Am 24.04.2018 18:47:28 schrieb tim Rowledge <tim(a)rowledge.org>: Last time I checked (which was a while ago, so maybe nicer now) there were varying checks/flags in the various platform vms, and further checks/preferences in the image. And then there are/were preferences like 'personalizedWorldMenu', the entire 'keyboard' preferences group, 'generalizedYellowButtonMenu' and very probably others that affect, change, filter and generally spindle, fold and mutilate events. Purely in-image changes have the virtue of being fixable in-image and of course you can set behaviour of an application you are writing (Scratch for instance). Purely vm handled preferences have the (potential) virtue of being globally settable for a users via whatever platform mechanism is used, most of which have always impressed me as a result of seriously deranged minds working hard to make life awkward. When we mix the two and add 20+ years of development history without an actual plan then we get some decidedly odd results. tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim Useful Latin Phrases:- Visne saltare? Viam Latam Fungosam scio = Do you want to dance? I know the Funky Broadway.

2 5

Re: [squeak-dev] A new Squeak release
by David T. Lewis 27 Apr '18

27 Apr '18

That is great, thank you Edgar! Yes of course we will help and be advisors. Also, our next board meeting will be Wednesday, March 2 at 2:00pm in your time zone. If you are available, you are invited to join us to discuss the upcoming release. It is a Google Hangouts meeting, so one of us will send you a link before the meeting. I am CC'ing the board, but let's keep follow up discussion on the main squeak-dev list. Dave On Fri, Apr 27, 2018 at 08:34:59AM -0300, Edgar De Cleene wrote: > This is a mail I was waiting. > Sure !! > And I wish have you and others (Marcel send me mails ) as advidcesrs > > Edgar > @morplenauta > > > On 26 Apr 2018, at 21:43, David T. Lewis <lewis(a)mail.msen.com> wrote: > > > > Hi Edgar, > > > > The Squeak oversight board has been discussing the upcoming release in our > > last few meetings, and we would be very happy if you would agree to be the > > Release Manager for the next Squeak release. > > > > Overall we are thinking that a new Squeak 5.2 release would make sense if it > > can be done in the next two or three months, so this should be our target. > > > > There are also many advances happening in the VM that may lead to a Squeak 6 > > release some time later, but right now we have a lot of great improvements > > in Squeak that deserve to be officially released soon. > > > > Are you still interested and willing to be the release manager for Squeak 5.2? > > > > Thanks in advance, > > > > Dave, on behalf of the Squeak Oversight Board >

1 0

The Trunk: Kernel-nice.1167.mcz
by commits＠source.squeak.org 27 Apr '18

27 Apr '18

Nicolas Cellier uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-nice.1167.mcz ==================== Summary ==================== Name: Kernel-nice.1167 Author: nice Time: 25 April 2018, 11:09:01.928037 am UUID: fd3a4e4a-925e-1842-9c73-f7f5736dd21c Ancestors: Kernel-eem.1166 I shall not invoke super floorLog: with a different radix. Ouch, probably a remnant from my ancestor method floorLog10 that I generalized. =============== Diff against Kernel-eem.1166 =============== Item was changed: ----- Method: Fraction>>floorLog: (in category 'mathematical functions') ----- floorLog: radix "Unlike super, this version is exact when radix is integer" | d n | + radix isInteger ifFalse: [^super floorLog: radix]. - radix isInteger ifFalse: [^super floorLog: 10]. n := numerator floorLog: radix. d := denominator floorLog: radix. ^(numerator * (radix raisedTo: d)) < (denominator * (radix raisedTo: n)) ifTrue: [n - d - 1] ifFalse: [n - d]! Item was changed: ----- Method: Integer>>floorLog: (in category 'mathematical functions') ----- floorLog: radix "Unlike super, this version is exact when radix is integer" + radix isInteger ifFalse: [^super floorLog: radix]. - radix isInteger ifFalse: [^super floorLog: 10]. self <= 0 ifTrue: [^DomainError signal: 'floorLog: is only defined for x > 0.0']. ^(self numberOfDigitsInBase: radix) - 1!

2 1

A new Squeak release
by Eliot Miranda 27 Apr '18

27 Apr '18

Hi All, we're moving close to a new Squeak release. There are some issues to discuss before we decide exactly what and when to release. I have two issues that I would like people's opinions on. 1. the VM can be compiled with support for read-only objects, and indeed Pharo is already doing this. Were we to enable read-only object support we could introduce read-only bindings. I have this code ready to go, but the current Squeak VM does not include read-only object support. We could go ahead and release without read-only object support or enable read-only object support in the VM, push the new VMs out and enable read-only literals. It would then take a few days for everyone to test their code and fix issues with read-only literals. For example, code such as a := { 'one ' . 'two ' . 'three ' }. a do: [:e | e at: e size put: (Character value: 0)]. must be rewritten, e.g. as a := #('one ' 'two ' 'three ' ) collect: [:ea| ea copyReplaceAll: Character space asString with: Character null asString]. and the classic '' writeStream as '' copy writeStream i.e. literals are read-only but copies of literals are not. 2. the current VM, Monticello and the ClassBuilder has full support for ephemerons, which provide instance based finalization. For example, if a file that is the key of some ephemeron in a registration dictionary, then, with a suitable finalization process, the VM will arrange that the ephemeron gets sent finalize when the file is only referenced from ephemeris, and then the ephemeron can finalize the file itself, flushing any buffered characters and closing the file's descriptor. What we have now is a copy of the file in a weak registry, which means we finalize the copy not the actual file. This limits our ability to write clean file implementations. The same applies to several other uses of weak registries. Again Pharo is using the facility (and hence we can use their finalization process and some of their code). So the question is should we hold up the release for these features or should we go ahead and somehow arrange that we do address these (and other?) issues promptly in a subsequent release? Let me make a proposal. We go ahead and make a release with what we have, calling it Squeak 5.5, and then follow a plan to provide read-only object support, read-only literals, and as mush of the finalizationsystem rewritten to use ephemeron (where appropriate) as we can manage by, say, September 1. This will be Squeak 6. And the trunk process would update to requiring a rad-only-object enabled VM immediately after the 5.5 release. _,,,^..^,,,_ best, Eliot

15 31

asApproximateFraction[AtOrder:]
by Eliot Miranda 26 Apr '18

26 Apr '18

Hi All, asApproximateFraction isn't that useful. It is based on asApproximateFractionAtOrder:, which gives you the best fraction it can find up to order. e.g. testContinuedFractions self assert: (Float pi asApproximateFractionAtOrder: 1) = (22/7). self assert: (Float pi asApproximateFractionAtOrder: 3) = (355/113) Here's 32-bit Float 1/3: ((FloatArray new: 1) at: 1 put: 1/3; at: 1) 0.3333333432674408 ((FloatArray new: 1) at: 1 put: 1/3; at: 1) asApproximateFraction (11184811/33554432) That's not what I expected :-). The problem is that asApproximateFractionAtOrder: is great if you know the number you're dealing with, but if you don't then it'll give you too much information. [This value comes up in the vm parameters system report page, where 1/3 is the ratio of growth to heap size above which a full GC is performed, i.e. by default every time a scavenge causes the heap grows by 1/3 from the last time a full GC was performed, the system will do a full GC. It would be great to report this as 1/3, not 0.33333298563957214, which is what's emerging from the C code in the VM]. Let's get a feeling for orders; they're effectively negative powers of 10: (1 to: 20) collect: [:order| | f | { order. (f := Float pi asApproximateFractionAtOrder: order). f asFloat. (f asFloat - Float pi) abs}] {{1 . (22/7) . 3.142857142857143 . 0.0012644892673496777}. {2 . (333/106) . 3.141509433962264 . 8.32196275291075e-5}. {3 . (355/113) . 3.1415929203539825 . 2.667641894049666e-7}. {4 . (103993/33102) . 3.1415926530119025 . 5.778906242426274e-10}. {5 . (104348/33215) . 3.141592653921421 . 3.3162805834763276e-10}. {6 . (208341/66317) . 3.1415926534674368 . 1.2235634727630895e-10}. {7 . (312689/99532) . 3.1415926536189365 . 2.914335439641036e-11}. {8 . (833719/265381) . 3.141592653581078 . 8.715250743307479e-12}. {9 . (1146408/364913) . 3.141592653591404 . 1.6107115641261771e-12}. {10 . (4272943/1360120) . 3.141592653589389 . 4.04121180963557e-13}. {11 . (5419351/1725033) . 3.1415926535898153 . 2.220446049250313e-14}. {12 . (80143857/25510582) . 3.1415926535897927 . 4.440892098500626e-16}. {13 . (245850922/78256779) . 3.141592653589793 . 0.0}. {14 . (817696623/260280919) . 3.141592653589793 . 0.0}. {15 . (19052873251/6064717916) . 3.141592653589793 . 0.0}. {16 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. {17 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. {18 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. {19 . (19870569874/6324998835) . 3.141592653589793 . 0.0}. {20 . (19870569874/6324998835) . 3.141592653589793 . 0.0}} More useful would be something like: asApproximateFractionToEpsilon: epsilon "Answer a Fraction approximating the receiver. This conversion uses the continued fraction method to approximate a floating point number." 1 to: 12 do: [:order| | fraction | fraction := self asApproximateFractionAtOrder: order. (fraction - self) abs <= epsilon ifTrue: [^fraction]]. ^ self asApproximateFractionAtOrder: 0 and then instead of asApproximateFraction "Answer a Fraction approximating the receiver. This conversion uses the continued fraction method to approximate a floating point number." ^ self asApproximateFractionAtOrder: 0 one could have asApproximateFraction "Answer a Fraction approximating the receiver. This conversion uses the continued fraction method to approximate a floating point number." ^self asApproximateFractionToEpsilon: 1e-6 And hence { 0.0. 0.333. 0.5. 1.0. Float pi . ((FloatArray new: 1) at: 1 put: 1/3; at: 1) } collect: [:n| n asApproximateFractionToEpsilon: 1e-6] {0 . (333/1000) . (1/2) . 1 . (355/113) . (1/3)} Votes for or against changing asApproximateFraction to use asApproximateFractionToEpsilon:? (asApproximateFraction has no senders into base image) Suggestions for a selector that would use self asApproximateFractionToEpsilon: 1e-6 (less clumsy than e.g. asUsefulApproximateFraction). _,,,^..^,,,_ best, Eliot

4 8

The Trunk: Collections-bf.787.mcz
by commits＠source.squeak.org 26 Apr '18

26 Apr '18

Bert Freudenberg uploaded a new version of Collections to project The Trunk: http://source.squeak.org/trunk/Collections-bf.787.mcz ==================== Summary ==================== Name: Collections-bf.787 Author: bf Time: 26 April 2018, 1:25:29.283438 pm UUID: ed53996c-b8a6-40b7-a186-37ec55737b62 Ancestors: Collections-pre.786 Allow to write Strings to binary WriteStream. =============== Diff against Collections-pre.786 =============== Item was changed: ----- Method: WriteStream>>nextPutAll: (in category 'accessing') ----- nextPutAll: aCollection | newEnd | (collection class == aCollection class + or: [ collection class isBits - or: [ collection isString and: [ aCollection isString and: [ collection class format = aCollection class format ] ] ]) "Let Strings with the same field size as collection take the quick route too." ifFalse: [ ^ super nextPutAll: aCollection ]. newEnd := position + aCollection size. newEnd > writeLimit ifTrue: [self growTo: newEnd + 10]. collection replaceFrom: position+1 to: newEnd with: aCollection startingAt: 1. position := newEnd. ^aCollection!

1 0

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

Jump to page: