<div dir="ltr"><div dir="ltr">Hi Jakob,</div><div dir="ltr"><br></div><div dir="ltr">The Inbox is a place where things are placed for collaboration and review.  It's perfectly normal that < 100% of submissions there will end up in trunk, and so there will always be "stale" versions being made through the normal course of business.  There's a button on the web site (access controlled)  for treating the stale versions.  As a community, we maintain full control over the Inbox.<br></div><div><br></div><div>We also have full control over the ancestry.  Merging items from the Inbox nearly invariably involves making a new version.  Since the ancestry is a permanent output affecting every current and future image, its important to prioritize its shape and size over the temporary, personal conveniences of inputting it.</div><div><br></div><div>I hope I answered your question and, if I have stale versions you'd like me to clean up, please accept my apology and let me know which one(s) so I can get it cleaned up.  There is no Collections-cmm.869, but I'm sure I have some old ones out there that could be treated...</div><div><br></div><div> - Chris</div><div dir="ltr"><br></div><div>On Sat, Jan 4, 2020 at 4:39 PM Jakob Reschke <<a href="mailto:forums.jakob@resfarm.de" target="_blank">forums.jakob@resfarm.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi Chris, hi all,</div><div><br></div><div>Chris, in your effort to omit intermediary or flawed versions from the ancestry, you produce stale versions in the inbox, in this case Collections-cmm.869 if I remember correctly.</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>How can we make sure that no Trunk committer (you are a Trunk committer Chris and can handle this yourself, but in general someone else might do it) will merge these versions that you wanted to omit?</div><div><br></div><div>If that happens, the ancestry will be "complete" again, which you wanted to avoid, and moreover it will look confusing (branches and merges instead of plain linear, actual history). I am still opposed to such omissions, but let's focus on the "if it happens, what then" part instead.</div><div><div><br></div></div><div>The omitted versions should be removed from the inbox, either by treating them or by withdrawing them (which is not directly possible at the moment, right?). How can we implement a reasonably reliable process with communication rules to handle such cases? Or is there already one that works? I don't think we can expect every treating Trunk committer to read through all the mails and ancillary threads to identify, or derive implicitly as in this case, which versions are stale.</div><div><br></div><div>Kind regards,<br>Jakob</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Sa., 4. Jan. 2020 um 23:09 Uhr schrieb <<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Chris Muller uploaded a new version of Collections to project The Inbox:<br>
<a href="http://source.squeak.org/inbox/Collections-cmm.870.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/inbox/Collections-cmm.870.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: Collections-cmm.870<br>
Author: cmm<br>
Time: 4 January 2020, 4:08:57.317384 pm<br>
UUID: c4bf7594-c44e-4d02-9956-2b727d2eb75b<br>
Ancestors: Collections-fn.869, Collections-ul.867<br>
<br>
Tweak ul.867 so that:<br>
<br>
        Dictionary new: 3<br>
<br>
is not significantly slower than:<br>
<br>
        Dictionary new<br>
<br>
=============== Diff against Collections-fn.869 ===============<br>
<br>
Item was changed:<br>
  ----- Method: HashedCollection class>>goodPrimeAtLeast: (in category 'sizing') -----<br>
  goodPrimeAtLeast: lowerLimit<br>
+       "Answer the smallest good prime >= lowerlimit.<br>
+       If lowerLimit is larger than the largest known good prime, just make it odd.<br>
+       Use linear search, and exponential search to speed up cases when lowerLimit is small (<2500 and <100000, respectively)."<br>
-       "Answer the next good prime >= lowerlimit.<br>
-       If lowerLimit is larger than the largest known good prime,<br>
-       just make it odd."<br>
<br>
+       | high mid low prime primes |<br>
-       | low mid high prime primes |<br>
        primes := self goodPrimes.<br>
+       (primes at: primes size) < lowerLimit ifTrue: [<br>
-       high := primes size.<br>
-       lowerLimit > (primes at: high) ifTrue: [<br>
                ^lowerLimit bitOr: 1 ].<br>
+       lowerLimit < 2500 ifTrue: [<br>
+               "Use linear search when the limit is small. The boundary is based on measurements."<br>
+               high := 1.<br>
+               [ <br>
+                       (prime := primes at: high) >= lowerLimit ifTrue: [ ^prime ].<br>
+                       high := high + 1 ] repeat ].<br>
+       lowerLimit < 100000 <br>
+               ifTrue: [<br>
+                       "Use exponential search when the limit is not too large. The boundary is based on measurements."<br>
+                       high := 1.<br>
+                       [ (primes at: high) < lowerLimit ] whileTrue: [<br>
+                               high := high * 2 ].<br>
+                       low := high // 2 + 1. "high // 2 was smaller than lowerLimit" ]<br>
+               ifFalse: [<br>
+                       "Regular binary search."<br>
+                       low := 1.<br>
+                       high := primes size ].<br>
-       low := 1.<br>
        [ high - low <= 1 ] whileFalse: [<br>
                mid := high + low // 2.<br>
                prime := primes at: mid.<br>
                lowerLimit < prime<br>
                        ifTrue: [ high := mid ]<br>
                        ifFalse: [<br>
                                lowerLimit > prime<br>
                                        ifTrue: [ low := mid ]<br>
                                        ifFalse: [ ^prime ] ] ].<br>
        (primes at: low) >= lowerLimit ifTrue: [ ^primes at: low ].<br>
        ^primes at: high!<br>
<br>
Item was changed:<br>
  ----- Method: HashedCollection>>compact (in category 'private') -----<br>
  compact<br>
        "Reduce the size of array so that the load factor will be ~75%."<br>
<br>
        | newCapacity |<br>
+       newCapacity := self class sizeFor: tally.<br>
-       newCapacity := self class goodPrimeAtLeast: tally * 4 // 3.<br>
        self growTo: newCapacity!<br>
<br>
<br>
</blockquote></div></div>
<br>
</blockquote></div></div>