March 2024 - Pharo-users - lists.pharo.org

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

Books about Pharo

by stephane ducasse

Hi Richard I did not see your original post because I messed up with my account. But thanks for your email :) Now the cool stuff if that we can also read the books from within Pharo. We should improve the Microdown renderer and suddenly we will get shiny cool documentation. S > This is a new thread because it's not limited to any specific topic. > > If you have questions about Pharo, especially "how do I do <this> in > Pharo", you can always ask in this mailing list. You can, if you like > playing Russian Roulette, ask a Large Language Model "AI". > > But there is an amazing resource you should really trye. > > books.pharo.org > > Did you ever wonder where the manual for Pharo was? > That's where. The site lists a bunch of Pharo books and booklets, > all of which have free PDFs except for two of the books. > In particular, you'll always want the most recent edition of > "Pharo by Example" handy. > > These books are really useful. They are written by people know know > their material thoroughly and do a good job of explaining it. If you > want to make any serious use of Pharo, or even to have more happiness > than headaches just playing with it, you owe it to yourself to get the > free PDFs What do we owe the authors? Well, if you're not trying to > make one pension support four people, you owe them the purchase of > some of the books. Me, I'm giving them thanks, praise, and a > heartfelt recommendation. > > Seriously, these books represent a HUGE amount of work and "you are a > fool to yourself and a burden to others" if you don't take advantage > of this great resource.

March 14, 2024

IWST 24 â International Workshop on Smalltalk Technologies Lille, France; July 8th to 11th, 2024

by Steven Costiou

IWST 24 INFORMATION AND CALL FOR PAPERS IWST 24 -- International Workshop on Smalltalk Technologies Lille, France; July 8th to 11th, 2024 GOALS AND SCOPE The goals of the workshop is to create a forum around contributions and experiences in building or using technologies related to Smalltalk. While maturity of presented ideas and results is not crucial, it is expected that their presentation triggers discussion and exchange of ideas. The topics of your paper can be on all aspect of Smalltalk, theoretical as well as practical. Authors are invited to submit research articles or industrial papers. IMPORTANT DATES * Extended abstract submission deadline: MARCH 31ST, 2024 * Extended abstract notification deadline: April 7th, 2024 * Full/short paper submission deadline: May 19th, 2024 * Full/short paper first-round notification deadline: June 30th, 2024 * Workshop: July 9-10, 2024 * Full/short paper resubmission deadline: July 21st, 2024 * Full/short paper final notification deadline: July 31st, 2024 * Camera ready package submission deadline: August 25th, 2024 TOPICS We welcome contributions on all aspects, theoretical as well as practical, of Smalltalk related topics such as: * Code Analysis * Automated Testing * Debugging * Compilers, Virtual Machines and Language implementations * Meta-programming and Meta-modeling * Refactorings * Design patterns * Experience reports * Libraries and frameworks * New dialects or languages implemented in Smalltalk * Interaction and integration with other languages * Tools SUBMISSIONS, REVIEWS, AND SELECTION Authors interetsed to present their work at the IWST 2024 are invited to submit an abstract of the intended talk before the extended abstract submission deadline. The extended abstract should be not longer than 2 pages following the CEUR ART style [1]. Author of the submitted extended abstratcs will be notified and invited to present their work by the extended abstract notification deadline which enables presenters to register at the early registration prices. Authors of the accepted abstracts are also invited to submit a paper to be subject of the review and a potential acceptance for publishing in the IWST 2024 Proceedings. We are looking for papers of two kinds: * Short position papers (5 to 10 pages) describing fresh ideas and early results. * Full research papers (more than 10 pages) with deeper description of experiments and of research results. Paper accepted for publishing will be published within a CEUR-WS Proceedings [2]. Hence, both submissions and final papers must be prepared using the CEUR ART style [1]. All submissions must be sent via EasyChair submission page [3]. Pay attention, for organisation constraints, when submitting your article you are expected to register to the conference and pay the conference fees. REVIEWING As the workshop format encourages bringing fresh ideas and early results to be presented and discussed, and aims for giving a chance to young community members to learn and grow, we will allow submissions with a discussion potential to be conditionally accepted. In this case, authors are expected to follow the recommendation of the reviewers. Consequently, the reviewing process will be organized in two rounds: * in the first round, all submissions will be reviewed by at least 3 reviewers. Based on these reviews authors will receive a notification with reviewers comments, advises, and requirements and papers that are not rejected will be invited to be resubmitted in an improved form together with change log and answrers to the reviewers. * in the second round, PC chairs in collaboration with the reviewers where needed and possible, will evaluate the improved paper version and notifiy authors about final decision on acceptance/rejection. BEST PAPER AWARD To encourage the submission of high-quality ideas, contributions, and papers, the IWST organizing committee is very proud to announce a Award competition in the categories of BEST IDEA, BEST CONTRIBUTION TO THE COMMUNITY and BEST PAPER FOR THIS EDITION OF IWST. The ranking will be decided by the program committee during the review process and by the audience voting during the conference. The awards will be given during the ESUG conference social event. The Awards will take place only with a minimum of six submissions. Notice also that to be eligible, a paper/abstract must be presented at the workshop by one of the author and that the presenting author must be registered at the ESUG conference. PROGRAM CHAIRS * Steven Costiou, Inria Lille, France (chair), * Guille Polito, Inria Lille, France (chair), * Gordana Rakic, University of Novi Sad, Serbia (chair) PROGRAM COMMITTEE to be published ... Links: ------ [1] https://ceur-ws.org/Vol-XXX/CEURART.zip [2] imap://scostiou@zimbra.inria.fr:993/fetch%3EUID%3E/Sent%3E105178?part=1.2.2&filename=text.html [3] https://easychair.org/conferences/?conf=iwst2024

March 14, 2024

Re: [Pharo-dev] Re: "Introducing Atlas" â New blog post on all: objects all: theTime

by Koen De Hondt

Thank you Noury. Writing blog posts about Atlas was my plan to pave the way toward a presentation at ESUGâ24, but when the date of the conference was announced I was sad to conclude that I cannot attend this year. So I will write more blog posts ;-) I like the discussion too. As was already clear when I organized the Pharo Browser Survey <https://all-objects-all-the-time.st/#/blog/posts/3>, a lot of people have an opinion on the tool they use every day, which is good. I welcome all the feedback. Best regards, Koen > On 13 Mar 2024, at 17:43, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > I read the blog post and I liked it. Thank you Koen! > > I've also liked very much the discussion in this thread. > I hope that you guys would expand your ideas and give talks at the ESUG conference next July. > > FYI here is the page with the ESUG call for presentations > https://esug.github.io/2024-Conference/call2024.html > > Noury ;-) > On Mar 11 2024, at 4:27 pm, Aik-Siong Koh <askoh(a)askoh.com> wrote: > Atlas is indeed ambitious, and I am glad you want to push the boundaries. > > Over the decades, GUIs have introduced a bewildering array of widgets and designs that I think we are in a mess again. > I feel we should restart again with a blank window, allow select and rightclick for context menu, and proceed for there to introduce the base minimum for a functional GUI. > I believe "select and rightclick context menu" can solve almost every GUI need simply. > I also think the single column menu can be updated to a two-column menu which is more compact and balanced. > The cursor can be centered between the two columns instead of being at the top left corner. > The cursor has to travel less for any selection. > https://askoh.com/index.html#TwoColumnMenu > > All the best, > Aik-Siong Koh > > On Mon, 11 Mar 2024 09:58:40 +0000, "Tim Mackinnon" <tim(a)testit.works> wrote: > > As browsers are a passion in the Smalltalk world it will be great to read your thoughts - as its certainly a hot potato, and we don't seem to have quite cracked it so far. > > I recall the presentations on Calypso from Pharo days (might have been recorded for review if you haven't seen them). I recall being won over at the time (and I was hesitant) - there was lots of flexibility that had been thought about, and many useful and tricky browsing patterns were covered - but over time I think its proved tricky to work with. In Pharo 11, the browsers don't seem to work as well as they should (lots of funny focus issues and loss of context that I don't recall in previous version - which I think is more down to understanding how it was supposed to work than technical flaws). > > It's definitely worth generating conversation and getting some consensus otherwise it will be a rise and fall scenario all over again. This said, continuing to find a good model that is both flexible and simple is useful. > > Tim > > p.s. On thing I recall from those Calypso presentations was that the model should have let us design browsers where we have different navigation models (e.g. you in theory you could design something where a class has a path to methods which are both instance and class so you don't have to have a mode to swap between them - something I find distracting when designing the interface of a class and trying to figure out how you instantiate/initialize it and you want to jump between the 2 view - I just want to see all all the methods in a list, differentiated in some way vs. hiding them). > > On Sun, 10 Mar 2024, at 5:24 PM, Koen De Hondt wrote: > Dear Pharo users and developers, > > Some people already know that I am working on a browser for Pharo. With this announcement, I make it official ð. > In my latest blog post <https://all-objects-all-the-time.st/#/blog/posts/6>, I introduce Atlas as an ambitious successor of Calypso. It is the first post in a series. > > Happy reading! > > Ciao, > Koen > >

March 13, 2024

Re: [Pharo-dev] Re: "Introducing Atlas" â New blog post on all: objects all: theTime

by Noury Bouraqadi

I read the blog post and I liked it. Thank you Koen! I've also liked very much the discussion in this thread. I hope that you guys would expand your ideas and give talks at the ESUG conference next July. FYI here is the page with the ESUG call for presentations https://esug.github.io/2024-Conference/call2024.html Noury ;-) On Mar 11 2024, at 4:27 pm, Aik-Siong Koh <askoh(a)askoh.com> wrote: > Atlas is indeed ambitious, and I am glad you want to push the boundaries. > > Over the decades, GUIs have introduced a bewildering array of widgets and designs that I think we are in a mess again. > I feel we should restart again with a blank window, allow select and rightclick for context menu, and proceed for there to introduce the base minimum for a functional GUI. > I believe "select and rightclick context menu" can solve almost every GUI need simply. > I also think the single column menu can be updated to a two-column menu which is more compact and balanced. > The cursor can be centered between the two columns instead of being at the top left corner. > The cursor has to travel less for any selection. > https://askoh.com/index.html#TwoColumnMenu > > All the best, > Aik-Siong Koh > > On Mon, 11 Mar 2024 09:58:40 +0000, "Tim Mackinnon" <tim(a)testit.works> wrote: > > As browsers are a passion in the Smalltalk world it will be great to read your thoughts - as its certainly a hot potato, and we don't seem to have quite cracked it so far. > > I recall the presentations on Calypso from Pharo days (might have been recorded for review if you haven't seen them). I recall being won over at the time (and I was hesitant) - there was lots of flexibility that had been thought about, and many useful and tricky browsing patterns were covered - but over time I think its proved tricky to work with. In Pharo 11, the browsers don't seem to work as well as they should (lots of funny focus issues and loss of context that I don't recall in previous version - which I think is more down to understanding how it was supposed to work than technical flaws). > > It's definitely worth generating conversation and getting some consensus otherwise it will be a rise and fall scenario all over again. This said, continuing to find a good model that is both flexible and simple is useful. > > Tim > > p.s. On thing I recall from those Calypso presentations was that the model should have let us design browsers where we have different navigation models (e.g. you in theory you could design something where a class has a path to methods which are both instance and class so you don't have to have a mode to swap between them - something I find distracting when designing the interface of a class and trying to figure out how you instantiate/initialize it and you want to jump between the 2 view - I just want to see all all the methods in a list, differentiated in some way vs. hiding them). > > On Sun, 10 Mar 2024, at 5:24 PM, Koen De Hondt wrote: > > Dear Pharo users and developers, > > > > Some people already know that I am working on a browser for Pharo. With this announcement, I make it official ð. > > In my latest blog post (https://all-objects-all-the-time.st/#/blog/posts/6) I introduce Atlas as an ambitious successor of Calypso. It is the first post in a series. > > > > Happy reading! > > > > Ciao, > > Koen > > > > > >

March 13, 2024

ESUG24 Call for Student Volunteers, 8-11 July, Lille, France

by Steven Costiou

CALL FOR STUDENT VOLUNTEERS, ESUG 2024, 8-11 JULY, LILLE, FRANCE Student volunteers help the conference running smoothly; in return, they have free accommodations, while still having most of the time to enjoy the conference. PAY ATTENTION: the places are limited so do not wait till the last minute to apply. CONFERENCE DETAILS: Send an email to volunteers-esug24(a)inria.fr. * title: [ESUG 2024 Student] * name, gender, university/school, country, email address * short description of you and why you are interested in participating Accommodation is covered from Sunday 7 July until 8 Thursday July 2024 (including nights from Sunday to Monday and from Thursday to Friday). Students will be hosted in student rooms. ESUG additionally covers for the lunches during the week and one dinner. Travel costs are *not* covered by the student volunteers program. Duties include handling registration as people arrive at the conference, filling coffee machines, collecting presentation slides for ESUG right after the presentation is given, being present at an information desk to answer questions, and generally being helpful. Student volunteering makes the conference better, takes a fairly small amount of time and doesn't significantly interfere with enjoying and learning from the conference. Please note, this role requires discipline and constant attention to all attendees.

March 12, 2024