Squeak-dev January 2020

squeak-dev@lists.squeakfoundation.org

43 participants
227 discussions

The Inbox: Collections-cmm.870.mcz
by commits＠source.squeak.org 05 Jan '20

05 Jan '20

Chris Muller uploaded a new version of Collections to project The Inbox: http://source.squeak.org/inbox/Collections-cmm.870.mcz ==================== Summary ==================== Name: Collections-cmm.870 Author: cmm Time: 3 January 2020, 7:59:19.257837 pm UUID: b3e2efab-cf35-426d-9910-adab44aa4ed4 Ancestors: Collections-fn.869, Collections-ul.867 Building on Collections-ul.867, let "Dictionary new: anySize" _never_ be significantly slower than "Dictionary new". =============== Diff against Collections-fn.869 =============== Item was changed: ----- Method: HashedCollection class>>goodPrimeAtLeast: (in category 'sizing') ----- goodPrimeAtLeast: lowerLimit + "Answer the smallest good prime >= lowerlimit. + If lowerLimit is larger than the largest known good prime, just make it odd. + Use linear search, and exponential search to speed up cases when lowerLimit is small (<2500 and <100000, respectively)." - "Answer the next good prime >= lowerlimit. - If lowerLimit is larger than the largest known good prime, - just make it odd." + | high mid low prime primes | - | low mid high prime primes | primes := self goodPrimes. + (primes at: primes size) < lowerLimit ifTrue: [ - high := primes size. - lowerLimit > (primes at: high) ifTrue: [ ^lowerLimit bitOr: 1 ]. + lowerLimit < 2500 ifTrue: [ + "Use linear search when the limit is small. The boundary is based on measurements." + high := 1. + [ + (prime := primes at: high) >= lowerLimit ifTrue: [ ^prime ]. + high := high + 1 ] repeat ]. + lowerLimit < 100000 + ifTrue: [ + "Use exponential search when the limit is not too large. The boundary is based on measurements." + high := 1. + [ (primes at: high) < lowerLimit ] whileTrue: [ + high := high * 2 ]. + low := high // 2 + 1. "high // 2 was smaller than lowerLimit" ] + ifFalse: [ + "Regular binary search." + low := 1. + high := primes size ]. - low := 1. [ high - low <= 1 ] whileFalse: [ mid := high + low // 2. prime := primes at: mid. lowerLimit < prime ifTrue: [ high := mid ] ifFalse: [ lowerLimit > prime ifTrue: [ low := mid ] ifFalse: [ ^prime ] ] ]. (primes at: low) >= lowerLimit ifTrue: [ ^primes at: low ]. ^primes at: high! Item was changed: ----- Method: HashedCollection class>>sizeFor: (in category 'sizing') ----- sizeFor: nElements "Large enough prime (or odd if too large) size to hold nElements with some slop (see fullCheck)" + nElements < 6 ifTrue: [ ^5 ]. - nElements < 4 ifTrue: [ ^5 ]. ^self goodPrimeAtLeast: nElements + 1 * 4 // 3! Item was changed: ----- Method: HashedCollection>>compact (in category 'private') ----- compact "Reduce the size of array so that the load factor will be ~75%." | newCapacity | + newCapacity := self class sizeFor: tally. - newCapacity := self class goodPrimeAtLeast: tally * 4 // 3. self growTo: newCapacity!

4 5

The Trunk: Monticello-cmm.708.mcz
by commits＠source.squeak.org 04 Jan '20

04 Jan '20

Chris Muller uploaded a new version of Monticello to project The Trunk: http://source.squeak.org/trunk/Monticello-cmm.708.mcz ==================== Summary ==================== Name: Monticello-cmm.708 Author: cmm Time: 4 January 2020, 3:47:13.56897 pm UUID: e4b9ac6a-3174-4839-a141-d58c52def9bb Ancestors: Monticello-ct.706 Fix Refresh button of MCRepositoryInspector not noticing removed versions. =============== Diff against Monticello-ct.706 =============== Item was added: + ----- Method: MCFileBasedRepository>>refresh (in category 'accessing') ----- + refresh + super refresh. + self flushCache! Item was added: + ----- Method: MCFileRepositoryInspector>>refresh (in category 'morphic ui') ----- + refresh + allVersionNames := nil. + super refresh!

1 0

The Inbox: Collections-fn.869.mcz
by commits＠source.squeak.org 03 Jan '20

03 Jan '20

A new version of Collections was added to project The Inbox: http://source.squeak.org/inbox/Collections-fn.869.mcz ==================== Summary ==================== Name: Collections-fn.869 Author: fn Time: 3 January 2020, 10:27:08.945712 am UUID: c29ef38b-f152-468e-bac9-74515c099ac4 Ancestors: Collections-nice.868 Add quick-check for identity to String>>sameAs: (similar to Character>>sameAs:). Example: [MenuIcons smallInspectItIconContents sameAs: MenuIcons smallInspectItIconContents] bench Before: 1,740,000 per second. 574 nanoseconds per run. 0 % GC time. After: 94,800,000 per second. 10.5 nanoseconds per run. 0 % GC time. =============== Diff against Collections-nice.868 =============== Item was changed: ----- Method: String>>sameAs: (in category 'comparing') ----- sameAs: aString "Answer whether the receiver sorts equal to aString. The collation sequence is ascii with case differences ignored." + self == aString ifTrue: [ ^true ]. ^(self compare: aString caseSensitive: false) = 2!

1 0

The Inbox: Tools-jr.929.mcz
by commits＠source.squeak.org 03 Jan '20

03 Jan '20

A new version of Tools was added to project The Inbox: http://source.squeak.org/inbox/Tools-jr.929.mcz ==================== Summary ==================== Name: Tools-jr.929 Author: jr Time: 30 December 2019, 3:20:08.513977 pm UUID: 0a4d62fd-022e-1844-b6bc-db1502ab2466 Ancestors: Tools-cmm.928 Show browsed environment in Browser title if it is not the default environment. =============== Diff against Tools-cmm.928 =============== Item was changed: ----- Method: Browser>>defaultBrowserTitle (in category 'initialize-release') ----- defaultBrowserTitle + | title | + title := 'System Browser'. + ^ environment = self class environment + ifTrue: [title] + ifFalse: [title, ' on environment ', environment asString]! - ^ 'System Browser'!

5 7

Unmerged trunk versions
by Jakob Reschke 01 Jan '20

01 Jan '20

Hi, I just noticed that Tools-ct.915 is in Trunk, but not part of the ancestry of the latest version: [image: image.png] Might want to double-check such things before the release. Kind regards, Jakob

4 5

Bouncing progress bars and hiding of notifiers
by tim Rowledge 01 Jan '20

01 Jan '20

Something annoying and hopefully simple to fix in a way that makes it worth getting into 5.3 is the way progress bars can bounce around the screen. It's visually distracting and somehow a bit tacky. It's not the particular location of the morph (more on that later) but the bounce of the dratt ed thing. I *think* that the simplest way to solve this is to prevent a new #requestedPosition: from being noted when the progress bar is already in operation. The obvious way to do this might be to only set the requestedPosition if it is currently nil. However, having a persistent class var UniqueInstance complicates life a fraction since we can't rely on the requested position being nil when we 'first' open a progress bar. We could probably set it back to nil in SystemProgressMorph>>#freeSlot: when the 'self delete' is run. For a simplest-possible fix, it looks like checking the activeSlots value is effective; by not changing the requested position if activeSlots > 0 it seems to work. My example here is 'Progress' displayProgressAt: Display center from: 0 to: 10 during: [:bar | 0 to: 10 do: [:i | bar value: i. 'Progress2' displayProgressAt: 200@300 from: 0 to: 100 during: [:baz | 0 to: 100 do: [:j | baz value: j. (Delay forMilliseconds: 2) wait]]]]. ... where previously the progress bar would leap tall buildings in a single bound. You get the picture. Proposed fix in inbox Morphic-tpr.1616 A related issue we have discussed on the list before is the unfortunate case where sometihng goes wrong during a large upload and a Notifier/Informer/Confirmer gets hidden behind a progress bar with many active bars. I've seen this during loading large packages like Seaside, for example. The system is stuck waiting for you to do something with the notifier but it is sat behind a large progress bar and nobody has a clue what is happening. A very simple workaround for this is to slightly offset the default position used when no explicit position is provided for the progress bar. Currently that is #center, as in centre of the screen. I noticed we already have a related solution in Rectangle - #aboveCenter as used in ModalSystemWindowView. So by adding a #belowCenter that aims a bit below the center (duh) we get a progress bar defaulting to just a bit lower on the screen. Obviously this doesn't solve for any cases where the bar is deliberately opened at the screen center. I'd like to suggest setting the default position for the assorted notifier/confirmer/informer windows using the #aboveCenter but right now as I look at the code for opening assorted UserDialogBoxMorphs I find my brain melting. Some methods accept an argument for the position but ignore it, some test the position for nil and use a preferred position, some use the current Hand position in combination with the center point of a specified submorph... crikey. I suspect there are better ways to solve the problem. Perhaps making sure the progress bar doesn't end up in front might be simpler? Perhaps catching the inform/confirm request and incorporating it into any active progress bar morph; that seems more complex than we'd want now. Proposed improvement in inbox ToolBuilder-Kernel-tpr.135 tim -- tim Rowledge; tim(a)rowledge.org; http://www.rowledge.org/tim BASIC is to computer programming as QWERTY is to typing.

3 2

[BUG] Cannot compile cascade sent to block
by Thiede, Christoph 01 Jan '20

01 Jan '20

Hi all! :-) Steps to reproduce: Do it: [true] whileTrue; whileFalse Expected behavior: The script is compiled and executed (and an infinite loop occurs). Actual behavior: [cid:60074202-9794-48ae-a5fd-57507c88211b] Further investigations: In #analyseTempsWithin:rootNode:assignmentPools:, the inner BlockNode [true] is not computed a blockExtent, because it is optimized. This leads to a nil key in the ByteCodeEncoder's blockExtentsToLocals. A fast solution would be to skip nil blockExtents in #noteBlockExtent:hasLocals:, but that's a dirty workaround. Similar bug: Try to do: Object newSubclass compile: 'iWontCompile: foo foo. [true] whileTrue; whileFalse' Fails with: [cid:8ddf552d-c1a1-4498-9284-472389ef8208] Again, the problem is that blockExtent isNil. Workaround: Send #yourself to the block before sending the cascade. This prevents the receiver from being optimized. Please note that this problem does not only occur in case of special blocks. For example, [Sensor anyButtonPressed] whileTrue; whileFalse fails as well. How to fix this appropriately? I'm not sure whether I understand the whole idea of blockExtent so far. According to the documentation comment, it should be okay to be nil; however, the #blockExtent comment does not mention this fact. Please see the attached changeset for an approach to fix the issue. All tests from KernelTests-Methods and most tests from Test-Compiler pass it, except of the testAllNodePCs* which time out in my fresh image. It would be great to hear if this is the right way to solve the bug, or just extending a workaround :-) Best, Christoph

5 17

Jump to page: