<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>