- Pharo-users - lists.pharo.org

Re: [Pharo-dev] "The Classification Model" â New blog post on all: objects all: theTime

by Koen De Hondt

Hi Tim, This is a good place to discuss. I did not add comment functionality to my blog because I do not want people to spam the site with stuff that is not related to the content, and I do not want to moderate the comments. Sending me messages is fine too, but here everyone can read along. You have understood correctly, but I consider it a virtual classification rather than a computed classification because the classification does not depend on user input. Atlas has an âAllMethodsClassificationâ that holds items for all methods of a class. It is used for instance methods and class methods, depending on the âsourceâ of the classification, either a class or a metaclass. Suppose you implement a new classification, letâs say âAllInstanceMethodsAndClassMethodsClassificationâ, that holds items for all instance methods and class methods of a class, then you are all set. All items and classifications have a display name, which is shown in the UI. However, the display name depends on the context. If it is clear from the context that #example is a class method, then displaying âexampleâ is fine. However, when the context is more general, like any manual classification that can hold anything, displaying âMy class>>#exampleâ would be more appropriate. So just implementing a new kind of classification would not be enough for your use case. Therefore I would also implement a dedicated view on that classification so that the list in the view can indicate whether a method is an instance or a class method, together with the protocol it belongs to. An alternative to what you propose, and a better solution in my opinion, is to have two views side by side, so that instance and class methods are not mixed. That simplifies the implementation, certainly because Atlas has both views, and composing your own browser is possible. That is certainly a topic for a future post. Thank you for your questions. I welcome all feedback, as it will shape Atlas. Ciao, Koen > On 19 Mar 2024, at 17:30, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Koen - is there any particular place you would like us to feedback on the posts? Is here useful, or some other location? > > I like the concepts you are introducing (I need to take to read your PHD - so good to have the link in there) - but the devil is in the detail of course. > > If I have understood correctly - the idea of computed classifications give rise to the flexibility we all crave? So in my previous comment - when designing a new class and trying to work out its protocol, in particular how to instantiate it vs. update it - its very inconvenient to have to flip between class and instance method definitions - a much flatter view of a Class has both instance AND class methods that I can see together is more efficient to work with in that initial design phase vs later when stabilised the more traditional - a Class name has Class and Instance definition, a Class definition has class methods, an Instance definition has instance methods (apologies if terminology isn't quite right - typing this in a hurry on a break). > > But does the classification model handle the above? To flatten instance and class methods into a single sorted list (discriminated in some manner - like one being bold or having some prefix) and also allowing you to add to add new items to that list and provide that discrimination sounds like it might not fit that classification model? Or maybe it does? I guess we do currently allow methods to have categories and we can view multiple categories in a list. I guess I'm curious how it hangs together to model non-trivial examples? And maybe this is the next blog post? > > Thanks for surfacing the ideas. > > Tim > > On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote: >> Dear Pharo users and developers, >> >> Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. >> If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. >> >> Happy reading! >> >> Ciao, >> Koen

March 19, 2024

Re: [Pharo-dev] "The Classification Model" â New blog post on all: objects all: theTime

by Tim Mackinnon

Hi Koen - is there any particular place you would like us to feedback on the posts? Is here useful, or some other location? I like the concepts you are introducing (I need to take to read your PHD - so good to have the link in there) - but the devil is in the detail of course. If I have understood correctly - the idea of computed classifications give rise to the flexibility we all crave? So in my previous comment - when designing a new class and trying to work out its protocol, in particular how to instantiate it vs. update it - its very inconvenient to have to flip between class and instance method definitions - a much flatter view of a Class has both instance AND class methods that I can see together is more efficient to work with in that initial design phase vs later when stabilised the more traditional - a Class name has Class and Instance definition, a Class definition has class methods, an Instance definition has instance methods (apologies if terminology isn't quite right - typing this in a hurry on a break). But does the classification model handle the above? To flatten instance and class methods into a single sorted list (discriminated in some manner - like one being bold or having some prefix) and also allowing you to add to add new items to that list and provide that discrimination sounds like it might not fit that classification model? Or maybe it does? I guess we do currently allow methods to have categories and we can view multiple categories in a list. I guess I'm curious how it hangs together to model non-trivial examples? And maybe this is the next blog post? Thanks for surfacing the ideas. Tim On Mon, 18 Mar 2024, at 5:51 PM, Koen De Hondt wrote: > Dear Pharo users and developers, > > Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. > If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. > > Happy reading! > > Ciao, > Koen

March 19, 2024

Re: [Pharo-dev] "The Classification Model" â New blog post on all: objects all: theTime

by Noury Bouraqadi

It sounds promising. I want it now ;-) Noury On Mar 18 2024, at 6:51 pm, Koen De Hondt <koen(a)all-objects-all-the-time.st> wrote: > Dear Pharo users and developers, > > Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. > If you liked it, I invite you to read the next post (https://all-objects-all-the-time.st/#/blog/posts/7) It describes the Classification Model, which is the foundation of Atlas. > > Happy reading! > > Ciao, > Koen >

March 19, 2024

UKSTUG Meeting - Maximiliano Tabacman: Electronic Roleplaying Assistant - 27 March 2024

by Giovanni Corriga

In this presentation, Maximiliano Tabacman will be presenting the main features, abstractions and design decisions behind ERA, the Electronic Roleplaying Assistant ( https://preview.drivethrurpg.com/en/product/137825/ERA-for-Rolemaster ). ERA is currently being used to create characters and manage the adventures of many gaming groups across the world, supporting Navigator RPG, Against the Darkmaster, Rolemaster Classic, Rolemaster Fantasy and Rolemaster Unified. We will review how Pharo allows creating a deployed version that runs locally in Linux, Mac and Windows, while Digital Ocean and Auth0 allow running an online server with different user roles. https://pharo.org/success/RolPlayingAssistant.html We will also mention how ERA makes use of the different frameworks developed and maintained by the Buenos Aires Smalltalk group, hosted at Github. Maximiliano Tabacman ( https://www.linkedin.com/in/maximiliano-tabacman-9aa4b817b/ ) is a long time Smalltalker with a Phd from the University of Buenos Aires. He is a Software architect at Mercap, executive secretary at FAST and creator of ERA. This will be an online meeting from home. If you'd like to join us, please sign up in advance on the meeting's Meetup page ( https://www.meetup.com/ukstug/events/299364517/ ) to receive the meeting details. Donât forget to bring your laptop and drinks!

March 19, 2024

"The Classification Model" â New blog post on all: objects all: theTime

by Koen De Hondt

Dear Pharo users and developers, Last week I told you about a new blog post that outlined the objectives of the Atlas browser. It was the first post of a series. If you liked it, I invite you to read the next post <https://all-objects-all-the-time.st/#/blog/posts/7>. It describes the Classification Model, which is the foundation of Atlas. Happy reading! Ciao, Koen

March 18, 2024

Re: String concatenation performance

by Noury Bouraqadi

Thank you Richard for the detailed response. Noury On Mar 18 2024, at 8:06 am, Richard O'Keefe <raoknz(a)gmail.com> wrote: > Let me start by giving some figures from my Smalltalk, on an Intel > core I5-6200U @ 2.3 Ghz CPU laptop with 8GB of memory running Ubuntu > 22.04 and gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0. Smalltalk is > compiled to C then finished with the system C compiler. Static > whole-program compilation is allowed by the ANSI standard and the > system was originally written to serve as a baseline for Bryce's JIT. > nsec technique > 249 replaceFrom:to:with:startingAt:*5 > 128 withAll:*5 > 486 ,,,, > 492 (,,),(,) > 521 streamContents: > 367 StringWriteStream > 860 StringBuffer>>addAllLast: > 385 StringBuffer>>nextPutAll: > > replaceFrom:to:with:startingAt:*5 makes a string the right size then > fills it in using #replaceAll:from:to:startingAt:. > withAll:*5 is String withAll: a withAll: b withAll: c withAll: d > withAll: e (supported up to 6 withAlls.) > This is interesting because the result can be a [ReadOnly](ByteArray > -- UTF8 -- or ShortArray -- UTF16 or String -- UTF32) and each of the > up to 6 operands can independently be these things. It wasn't > intended as a fast alternative to #, . > .... is a,b,c,d,e > (,,),(,) is (a,b,c),(d,e). > streamContents: is what you had > StringWriteStream is basically the same as streamContents: but using a > WriteStream specialised to Strings with some extra primitive support. > There are also StringReadStream and StringReadWriteStream. > StringBuffer is my version of Java's StringBuilder; it's a cross > between a String, an OrderedCollection, and a WriteStream. It can > change size like an OrderedCollection; it has most of the "writing" > methods (but not the "position" ones) of a WriteStream, and at all > times you can use it as a String without having to copy the contents. > You would expect #addAllLast: and #nextPutAll: to have the same > result, and they do, but they were written a different times and > #nextPutAll: was optimised for the case where the operand is a string > while #addAllLast: wasn't. > > What does all that mean in practice? > It means that a benchmark like this is VERY SENSITIVE to the details > of how the library is written. > Even just bracketing the commas differently gives you a different time. > > It means that techniques which are more efficient for LARGE volumes of > data may have startup costs > that make them less efficient for SMALL volumes of data, and that this > is a very small benchmark. > The cost of a,b,c,d,e is proportional to |a|*5 + |b|*4 + |c|*3 + |d|*2 > + |e|, while the other techniques > are proportional to |a| + |b| + |c| + |d| + |e|, BUT have overheads of > their own. > > Well, that was astc. What about Pharo? > 1,950,528 per second' ,,,, > 6,509,256 per second' withAll:*5 > > Here it is. I've added withAll:*2 to withAll:*6 to ArrayedCollection class. > withAll: c1 withAll: c2 withAll: c3 withAll: c4 withAll: c5 > |e1 e2 e3 e4 e5| > e1 := c1 size. > e2 := c2 size + e1. > e3 := c3 size + e2. > e4 := c4 size + e3. > e5 := c5 size + e4. > ^(self new: e5) > replaceFrom: 1 to: e1 with: c1 startingAt: 1; > replaceFrom: e1+1 to: e2 with: c2 startingAt: 1; > replaceFrom: e2+1 to: e3 with: c3 startingAt: 1; > replaceFrom: e3+1 to: e4 with: c4 startingAt: 1; > replaceFrom: e4+1 to: e5 with: c5 startingAt: 1; > yourself > > What's the lesson here? Just because A is faster than B doesn't mean > there isn't a fairly obvious C, D, ..., that will beat A. > > Now what is the real argument in favour of StringBuilder in Java and > streamContents: in Smalltalk? > > s := ''. > 1 to: n do: [:i | s := s , 'X']. > > makes a string of n Xs but takes O(n**2) time and turns over O(n**2) memory. > s := String streamContents: [:o | 1 to: n do: [:i | o nextPut: $X] > makes a string of n Xs while taking O(n) time and turning over O(n) memory. > n does not have to be very big before this gets to be a HUGE difference. > > For what it's worth, the Java compiler turns a+b+c+d+e into code that creates > a StringBuilder, stuffs a ... e into it, and then pulls a string out. > There is no point > in benchmarking a fixed number of concatenations against a StringBuilder in > Java because they're the same thing. Smalltalk compilers don't do that. > > In Java and in Smalltalk you should seldom concatenation strings, but should > send the fragments directly to their final destination. I've never > quite made up > my mind whether being toString()-centric was Java's biggest blunder or just the > second biggest, but it was a pretty darned big one for sure. Smalltalk go this > right: #printOn: is the basic notion and #printString the derived and > best avoided > one. > > On Sat, 16 Mar 2024 at 08:12, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > > > I thought streamContents: was faster than using a comma binary message... > > > > I was wrong. Pharo is not Java :-) > > > > Noury > > > > "Run in P11" > > > > a := 'aaaaa'. > > > > b := 'bbbbb'. > > > > c := 'ccccc'. > > > > d := 'ddddd'. > > > > e := 'eeeeee'. > > > > [ a , b , c , d , e ] bench. > > > > "'3958888.090 per second'" > > > > "'3808242.503 per second'" > > > > > > [ > > > > String streamContents: [ :str | > > > > str > > > > << a; > > > > << b; > > > > << c; > > > > << d; > > > > << e ] ] bench > > > > "'3083603.838 per second'" > > > > "'2927641.144 per second'" a := 'aaaaa'. > > > > b := 'bbbbb'. > > > > c := 'ccccc'. > > > > d := 'ddddd'. > > > > e := 'eeeeee'. > > > > [ a , b , c , d , e ] bench. > > > > "'3958888.090 per second'" > > > > "'3808242.503 per second'" > > > > [ > > > > String streamContents: [ :str | > > > > str > > > > << a; > > > > << b; > > > > << c; > > > > << d; > > > > << e ] ] bench > > > > "'3083603.838 per second'" > > > > "'2927641.144 per second'" > > > > a := 'aaaaa'. > > b := 'bbbbb'. > > c := 'ccccc'. > > d := 'ddddd'. > > e := 'eeeeee'. > > [ a , b , c , d , e ] bench. > > "'3958888.090 per second'" > > "'3808242.503 per second'" > > [ > > String streamContents: [ :str | > > str > > << a; > > << b; > > << c; > > << d; > > << e ] ] bench > > "'3083603.838 per second'" > > "'2927641.144 per second'" >

March 18, 2024

Re: String concatenation performance

by Richard O'Keefe

Let me start by giving some figures from my Smalltalk, on an Intel core I5-6200U @ 2.3 Ghz CPU laptop with 8GB of memory running Ubuntu 22.04 and gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0. Smalltalk is compiled to C then finished with the system C compiler. Static whole-program compilation is allowed by the ANSI standard and the system was originally written to serve as a baseline for Bryce's JIT. nsec technique 249 replaceFrom:to:with:startingAt:*5 128 withAll:*5 486 ,,,, 492 (,,),(,) 521 streamContents: 367 StringWriteStream 860 StringBuffer>>addAllLast: 385 StringBuffer>>nextPutAll: replaceFrom:to:with:startingAt:*5 makes a string the right size then fills it in using #replaceAll:from:to:startingAt:. withAll:*5 is String withAll: a withAll: b withAll: c withAll: d withAll: e (supported up to 6 withAlls.) This is interesting because the result can be a [ReadOnly](ByteArray -- UTF8 -- or ShortArray -- UTF16 or String -- UTF32) and each of the up to 6 operands can independently be these things. It wasn't intended as a fast alternative to #, . .... is a,b,c,d,e (,,),(,) is (a,b,c),(d,e). streamContents: is what you had StringWriteStream is basically the same as streamContents: but using a WriteStream specialised to Strings with some extra primitive support. There are also StringReadStream and StringReadWriteStream. StringBuffer is my version of Java's StringBuilder; it's a cross between a String, an OrderedCollection, and a WriteStream. It can change size like an OrderedCollection; it has most of the "writing" methods (but not the "position" ones) of a WriteStream, and at all times you can use it as a String without having to copy the contents. You would expect #addAllLast: and #nextPutAll: to have the same result, and they do, but they were written a different times and #nextPutAll: was optimised for the case where the operand is a string while #addAllLast: wasn't. What does all that mean in practice? It means that a benchmark like this is VERY SENSITIVE to the details of how the library is written. Even just bracketing the commas differently gives you a different time. It means that techniques which are more efficient for LARGE volumes of data may have startup costs that make them less efficient for SMALL volumes of data, and that this is a very small benchmark. The cost of a,b,c,d,e is proportional to |a|*5 + |b|*4 + |c|*3 + |d|*2 + |e|, while the other techniques are proportional to |a| + |b| + |c| + |d| + |e|, BUT have overheads of their own. Well, that was astc. What about Pharo? 1,950,528 per second' ,,,, 6,509,256 per second' withAll:*5 Here it is. I've added withAll:*2 to withAll:*6 to ArrayedCollection class. withAll: c1 withAll: c2 withAll: c3 withAll: c4 withAll: c5 |e1 e2 e3 e4 e5| e1 := c1 size. e2 := c2 size + e1. e3 := c3 size + e2. e4 := c4 size + e3. e5 := c5 size + e4. ^(self new: e5) replaceFrom: 1 to: e1 with: c1 startingAt: 1; replaceFrom: e1+1 to: e2 with: c2 startingAt: 1; replaceFrom: e2+1 to: e3 with: c3 startingAt: 1; replaceFrom: e3+1 to: e4 with: c4 startingAt: 1; replaceFrom: e4+1 to: e5 with: c5 startingAt: 1; yourself What's the lesson here? Just because A is faster than B doesn't mean there isn't a fairly obvious C, D, ..., that will beat A. Now what is the real argument in favour of StringBuilder in Java and streamContents: in Smalltalk? s := ''. 1 to: n do: [:i | s := s , 'X']. makes a string of n Xs but takes O(n**2) time and turns over O(n**2) memory. s := String streamContents: [:o | 1 to: n do: [:i | o nextPut: $X] makes a string of n Xs while taking O(n) time and turning over O(n) memory. n does not have to be very big before this gets to be a HUGE difference. For what it's worth, the Java compiler turns a+b+c+d+e into code that creates a StringBuilder, stuffs a ... e into it, and then pulls a string out. There is no point in benchmarking a fixed number of concatenations against a StringBuilder in Java because they're the same thing. Smalltalk compilers don't do that. In Java and in Smalltalk you should seldom concatenation strings, but should send the fragments directly to their final destination. I've never quite made up my mind whether being toString()-centric was Java's biggest blunder or just the second biggest, but it was a pretty darned big one for sure. Smalltalk go this right: #printOn: is the basic notion and #printString the derived and best avoided one. On Sat, 16 Mar 2024 at 08:12, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > I thought streamContents: was faster than using a comma binary message... > > I was wrong. Pharo is not Java :-) > > Noury > > "Run in P11" > > a := 'aaaaa'. > > b := 'bbbbb'. > > c := 'ccccc'. > > d := 'ddddd'. > > e := 'eeeeee'. > > [ a , b , c , d , e ] bench. > > "'3958888.090 per second'" > > "'3808242.503 per second'" > > > [ > > String streamContents: [ :str | > > str > > << a; > > << b; > > << c; > > << d; > > << e ] ] bench > > "'3083603.838 per second'" > > "'2927641.144 per second'" a := 'aaaaa'. > > b := 'bbbbb'. > > c := 'ccccc'. > > d := 'ddddd'. > > e := 'eeeeee'. > > [ a , b , c , d , e ] bench. > > "'3958888.090 per second'" > > "'3808242.503 per second'" > > [ > > String streamContents: [ :str | > > str > > << a; > > << b; > > << c; > > << d; > > << e ] ] bench > > "'3083603.838 per second'" > > "'2927641.144 per second'" > > a := 'aaaaa'. > b := 'bbbbb'. > c := 'ccccc'. > d := 'ddddd'. > e := 'eeeeee'. > [ a , b , c , d , e ] bench. > "'3958888.090 per second'" > "'3808242.503 per second'" > [ > String streamContents: [ :str | > str > << a; > << b; > << c; > << d; > << e ] ] bench > "'3083603.838 per second'" > "'2927641.144 per second'"

March 18, 2024

Re: String concatenation performance

by Yanni Chiu

The test is using string literals, which may be optimized in various ways. Is that representative of your use case? On Fri, Mar 15, 2024 at 3:12 PM Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > I thought streamContents: was faster than using a comma binary message... > > I was wrong. Pharo is not Java :-) > > Noury > > "Run in P11" > > a := 'aaaaa'. > > b := 'bbbbb'. > > c := 'ccccc'. > > d := 'ddddd'. > > e := 'eeeeee'. > > [ a , b , c , d , e ] bench. > > "'3958888.090 per second'" > > "'3808242.503 per second'" > > > [ > > String streamContents: [ :str | > > str > > << a; > > << b; > > << c; > > << d; > > << e ] ] bench > > "'3083603.838 per second'" > > "'2927641.144 per second'" a := 'aaaaa'. > > b := 'bbbbb'. > > c := 'ccccc'. > > d := 'ddddd'. > > e := 'eeeeee'. > > [ a , b , c , d , e ] bench. > > "'3958888.090 per second'" > > "'3808242.503 per second'" > > [ > > String streamContents: [ :str | > > str > > << a; > > << b; > > << c; > > << d; > > << e ] ] bench > > "'3083603.838 per second'" > > "'2927641.144 per second'" > > a := 'aaaaa'. > b := 'bbbbb'. > c := 'ccccc'. > d := 'ddddd'. > e := 'eeeeee'. > [ a , b , c , d , e ] bench. > "'3958888.090 per second'" > "'3808242.503 per second'" > [ > String streamContents: [ :str | > str > << a; > << b; > << c; > << d; > << e ] ] bench > "'3083603.838 per second'" > "'2927641.144 per second'" >

March 15, 2024

String concatenation performance

by Noury Bouraqadi

> I thought streamContents: was faster than using a comma binary message... I was wrong. Pharo is not Java :-) Noury "Run in P11" a := 'aaaaa'. > b := 'bbbbb'. > c := 'ccccc'. > d := 'ddddd'. > e := 'eeeeee'. > [ a , b , c , d , e ] bench. > "'3958888.090 per second'" > "'3808242.503 per second'" > [ > String streamContents: [ :str | > str > << a; > << b; > << c; > << d; > << e ] ] bench > "'3083603.838 per second'" > "'2927641.144 per second'" a := 'aaaaa'. > b := 'bbbbb'. > c := 'ccccc'. > d := 'ddddd'. > e := 'eeeeee'. > [ a , b , c , d , e ] bench. > "'3958888.090 per second'" > "'3808242.503 per second'" > [ > String streamContents: [ :str | > str > << a; > << b; > << c; > << d; > << e ] ] bench > "'3083603.838 per second'" > "'2927641.144 per second'" a := 'aaaaa'. b := 'bbbbb'. c := 'ccccc'. d := 'ddddd'. e := 'eeeeee'. [ a , b , c , d , e ] bench. "'3958888.090 per second'" "'3808242.503 per second'" [ String streamContents: [ :str | str << a; << b; << c; << d; << e ] ] bench "'3083603.838 per second'" "'2927641.144 per second'"

March 15, 2024

This week (11/2024) on the Pharo Issue Tracker

by Marcus Denker

With the freeze, we will see now less PRs being integrated, most of them fixes and tests. If you see bugs in Pharo 12, make sure to check that it is reported on the issue tracker! # Fixes - fix calypso close button #16295 https://github.com/pharo-project/pharo/pull/16295 - Fixing issue #16291 - RBRemoveDirectAccessToVariableTransformationTest is failing #16293 https://github.com/pharo-project/pharo/pull/16293 - Fixes issue: RB - Undo refactoring sometimes not only undo the last changes of refactoring #8103 #16285 https://github.com/pharo-project/pharo/pull/16285 - Update Roassal to v1.06 #16287 https://github.com/pharo-project/pharo/pull/16287 - Remove use of âset -eâ from script âgetPharoVM.shâ #16282 https://github.com/pharo-project/pharo/pull/16282 - Prevents asking for user input twice during the Pushing up method refactoring #16281 https://github.com/pharo-project/pharo/pull/16281 - 16233-ChangeRecordtimeStamp-calls-deprecated-method #16254 https://github.com/pharo-project/pharo/pull/16254 - Fix title display in File Presenter windows #716 https://github.com/pharo-spec/NewTools/pull/716 # Improvements - Add pre-filling the name text presenter in file dialogs #717 https://github.com/pharo-spec/NewTools/pull/717 - Adding tests for debug points + integrating debug points to Calypso Browser #16268 https://github.com/pharo-project/pharo/pull/16268 - Make #taskbarButtonMenu: on SystemWindow and MorphicNativeWindow use the FormSet for each of the icons #16296 https://github.com/pharo-project/pharo/pull/16296 - Refactor MenuItemMorph, PluggableMenuItemSpec and PragmaMenuAndShortcutRegistrationItem to support use of a FormSet and apply that to CmdCommand #16201 https://github.com/pharo-project/pharo/pull/16201

March 15, 2024