- Pharo-dev - lists.pharo.org

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

by Tim Mackinnon

By the way - it's a shame there is no rss feed for you blog as I like to use a feed reader on my phone to keep up with such things. Not sure what you are using, but if you could enable it, that would be coo. Tim On Tue, 19 Mar 2024, at 4:30 PM, Tim Mackinnon 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 20, 2024

Re: "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: "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: "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

"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

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

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-users] Re: 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: "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