[Pharo-dev] Object-centric breakpoint experiment during ESUG'24
Dear community, First, I would like to thanks again all the participants to our experiment with object-centric breakpoints in Pharo. Many people participated, and we plan to present our results in an informal manner at ESUG. However, from the scientifical point of view it would strenghten our analysis if we had more participants. The more participants we have, the more we can trust our results and take enlightened decisions about how to further develop the object-centric debugger. Therefore, the experiment remains open until July 10th (included). If you're interested you can still do it, the instructions are here https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd Many people also declined to participate because of a lack of time, which we totally understand. This is why we also propose to you, if time is an issue, to participate to the experiment during the first days of esug. We can find a calm room in which we can supervise the experiment and collect your data (reminder: once in our server the data is anonymized). Please let us know if you would be potentially interested to participate in such setting during ESUG. Thanks in advance, Steven and Valentin, EVREF team.
[Pharo-dev] Re: Open Call: Object-Centric Breakpoints experiment
Dear community, we are still looking for participants for our experiment in the EVREF team! Please help us! We need 15 more participants, if you are interested and if you believe you can work your way around a debugger, the experiment is fully available online here (using Pharo 9): https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd We would like to show our results at ESUG, but for that we really need these 15 additional participations so that we can trust the results better. Thanks in advance, and many thanks to the people who already participated! Steven. Le 2024-02-02 14:14, Steven Costiou a écrit : > Dear Community, > > as part of a research project in the EVREF team, we are looking for people to > participate to an empirical experiment on object-centric breakpoints - a > debugging tool present in Pharo 9. > > Many people from the community already participated, and we thank them very > much > > We are still looking for participants, we need 40 people to do the > experiment! > > Please help us, in return it helps us understand better our tools and their > impact and therefore build better tools for the Pharo community! > > For those who want to know a bit more, see my original email below. > For those who just want to jump at the experiment, you can go there > https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd > > Thanks in advance > Steven. > > --- > > We would like to invite you to participate to our experimental study on > Object-Centric Breakpoints. > This study aims to evaluate and to understand how Object-Centric Breakpoints > impacts the debugging activity. > > This experiment takes place in **Pharo 9**. > In this experiment, we ask you to solve 2 debugging tasks, one with standard > Pharo tools and one other with Object-Centric Breakpoints. > Between the two tasks, you will have to follow a tutorialand warmup tasks to > learn how to use the tool. > > **How to Participate:** > All instructions are here, please read them carefully: > https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd > > **About the Experiment:** > > The experiment last between 40 minutes and 2 hours. > Participants should have experience with Pharo development and debugging. > We recommend having more than 6 months experience in Pharo and debugging in > general. > You will gain insights into the Object-Centric Breakpoints approach and > contribute to advancements in debugging research. > > Help us to build better debugging tools that help you debug! > > **Some constraints:** > > - You are not allowed to load external tools and baselines, but you can use > anything that is in the base image > - Please do the experiment in one shot if possible without interruptions > - The experiment sends anonymous data to our inria server, please make sure > that you have a valid internet connection > - Please try to use the object-centric breakpoints when the experimental > framework asks you to > > **Notes:** > Participation is voluntary, and everything is anonymous. > You can abandon the experiment at any point (and your data will be > discarded). > For any question, you can contact us: steven.cost...@inria.fr and > valentin.bourc...@inria.fr > > Thank you for considering participating in our study. > Your contribution will be valuable in advancing the field of debugging and > helping us understand what tools we need to build for Pharo. > > Sincerely, > Steven and Valentin, > EVREF team, Inria
[Pharo-dev] IWST 24 — International Workshop on Smalltalk Technologies Lille, France; July 8th to 11th, 2024
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
[Pharo-dev] Open PhD position on debugging at Inria Lille
Hello, we have a PhD position opening at Lille, France. See all details here: https://recrutement.inria.fr/public/classic/fr/offres/2024-07154 Steven. _Summary of the research proposal:_ ### Application development inevitably introduces bugs. Often, it's not clear why a code change introduced a bug. To find this cause-and-effect relationship and debug more efficiently, developers can sometimes rely on the existence of a previous version of the code without the bug. Yet, traditional debugging tools are not designed for this kind of work, making it a tedious operation. In this thesis, we propose an approach that enables us to understand and to debug an application in a LIVE SYSTEM, such as Pharo or Python, by comparing two executions with different results: one execution succeeds and the other fails. Based on this hypothesis, we propose in this thesis to answer the following challenges: - How to detect divergence, i.e. different behavior between two executions of a program? - How can we reduce the cost in time, memory and energy consumption of detecting divergence(s) on long executions? - What are the criteria for deciding whether a divergence is normal or unauthorized? - What about detecting multiple divergences in the same program? - What abstractions are needed to compare two executions of a program and detect divergences? To meet these challenges, in addition to a precise state-of-the-art on debugging techniques, the PhD student will study concrete cases of program execution and propose a tool to be integrated into Pharo.
[Pharo-dev] Open Call: Object-Centric Breakpoints experiment
Dear Community, as part of a research project in the EVREF team, we are looking for people to participate to an empirical experiment on object-centric breakpoints - a debugging tool present in Pharo 9. Many people from the community already participated, and we thank them very much We are still looking for participants, we need 40 people to do the experiment! Please help us, in return it helps us understand better our tools and their impact and therefore build better tools for the Pharo community! For those who want to know a bit more, see my original email below. For those who just want to jump at the experiment, you can go there https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd Thanks in advance Steven. --- We would like to invite you to participate to our experimental study on Object-Centric Breakpoints. This study aims to evaluate and to understand how Object-Centric Breakpoints impacts the debugging activity. This experiment takes place in **Pharo 9**. In this experiment, we ask you to solve 2 debugging tasks, one with standard Pharo tools and one other with Object-Centric Breakpoints. Between the two tasks, you will have to follow a tutorialand warmup tasks to learn how to use the tool. **How to Participate:** All instructions are here, please read them carefully: https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd **About the Experiment:** The experiment last between 40 minutes and 2 hours. Participants should have experience with Pharo development and debugging. We recommend having more than 6 months experience in Pharo and debugging in general. You will gain insights into the Object-Centric Breakpoints approach and contribute to advancements in debugging research. Help us to build better debugging tools that help you debug! **Some constraints:** - You are not allowed to load external tools and baselines, but you can use anything that is in the base image - Please do the experiment in one shot if possible without interruptions - The experiment sends anonymous data to our inria server, please make sure that you have a valid internet connection - Please try to use the object-centric breakpoints when the experimental framework asks you to **Notes:** Participation is voluntary, and everything is anonymous. You can abandon the experiment at any point (and your data will be discarded). For any question, you can contact us: steven.cost...@inria.fr and valentin.bourc...@inria.fr Thank you for considering participating in our study. Your contribution will be valuable in advancing the field of debugging and helping us understand what tools we need to build for Pharo. Sincerely, Steven and Valentin, EVREF team, Inria
[Pharo-dev] Open Call: Object-Centric Breakpoints experiment
Dear Community, We would like to invite you to participate to our experimental study on Object-Centric Breakpoints. This study aims to evaluate and to understand how Object-Centric Breakpoints impacts the debugging activity. This experiment takes place in **Pharo 9**. In this experiment, we ask you to solve 2 debugging tasks, one with standard Pharo tools and one other with Object-Centric Breakpoints. Between the two tasks, you will have to follow a tutorialand warmup tasks to learn how to use the tool. **How to Participate:** All instructions are here, please read them carefully: https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd **About the Experiment:** The experiment last between 40 minutes and 2 hours. Participants should have experience with Pharo development and debugging. We recommend having more than 6 months experience in Pharo and debugging in general. You will gain insights into the Object-Centric Breakpoints approach and contribute to advancements in debugging research. Help us to build better debugging tools that help you debug! :) **Some constraints:** - You are not allowed to load external tools and baselines, but you can use anything that is in the base image - Please do the experiment in one shot if possible without interruptions - The experiment sends anonymous data to our inria server, please make sure that you have a valid internet connection - Please try to use the object-centric breakpoints when the experimental framework asks you to **Notes:** Participation is voluntary, and everything is anonymous. You can abandon the experiment at any point (and your data will be discarded). For any question, you can contact us: steven.cost...@inria.fr and valentin.bourc...@inria.fr Thank you for considering participating in our study. Your contribution will be valuable in advancing the field of debugging and helping us understand what tools we need to build for Pharo. Sincerely, Steven and Valentin, EVREF team, Inria
[Pharo-dev] One PhD and two internships offers on object-centric debugging at Inria Lille
Hello, Inria Lille is recruiting one phd student and two interns to work on object-centric debugging within the OCRE project (ANR). DESCRIPTION OF THE PROJECT Debugging is difficult and costly. Object-centric debugging is a young technique arguing that focusing the scope of debugging on specific objects considerably eases the tracking and the understanding of hard bugs in Object-Oriented Programs (OOP). But it lacks fundamental bricks to be applicable in practice. Therefore, it has never been empirically evaluated. The objectives of the OCRE project are to study the fundamental and practical limits that hinder the implementation, the evaluation, and the adoption of object-centric debugging. We propose to build the first generation of object-centric debuggers, in order to identify and evaluate its real benefits to OOP debugging. We argue that these debuggers have the potential to drastically lower the cost (time and effort) of tracking and understanding hard bugs in OOP. PHD TOPIC The goal of this PhD is to understand and to achieve the full potential of object-centric debugging by: - identifying the precise scenarios for object-centric debugging, - studying means to obtain objects to debug, - studying the implementation requirements for object-centric debuggers and to implement prototypes, - evaluate empirically object-centric debugging using these prototypes. The full detailed offer is available here: https://jobs.inria.fr/public/classic/fr/offres/2021-04101 INTERNSHIPS These two internships aim at helping the design and the implementation of an object-centric debugger, by unveiling knowledge without which object-centric debuggers cannot be built and evaluated, or cannot be used in practice. Internship 1 - Identifying and acquiring objects to debug The objective of this internship is to study the practical problems of acquiring objects to debug. The intern will characterize the scenarios in which developers need to identify objects to debug and explore these scenarios by implementing prototypes. Internship 2 - Evaluating object-centric debugging scenarios The objective of this internship is to identify and to evaluate the debugging scenarios that are the most likely to benefit from object-centric debugging. The intern will interrogate real developers about object-centric debugging scenarios, then implement prototypes and evaluate them empirically with developers to validate these scenarios. ADMINISTRATIVE DETAILS Location: Lille, France Phd: - starting date: preferably october 2022, but it can start before. - duration: 3 years (fully funded) - the candidate must hold a Master or an equivalent degree Internships: - starting date: anytime - duration: 4-6 months - the candidate must be studying for a Master degree or equivalent (1st or 2nd year, equivalent to M1 or M2 in France)
[Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming
Le 2021-07-21 16:26, Esteban Maringolo a écrit : > I agree with the fact that words shape our way of thinking, but how > does master in this context relates to slavery? > I would agree that a master/slave disk setup would directly relate to > that, but as I see there are no "slave" branches nor repositories. So > I really don't understand it. Sure, it was randomly chosen. Perhaps it designates a martial art master, which totally makes sense for the main branch that controls a software project. Totally makes sense. Of course everybody knows Microsoft does not really care (maybe some of their employees, I don't know) and that is just marketing (again, maybe not for people who feel concerned, but I will not speak for them). In the meantime, if nazis were not trying to shut up the big-picture-idea, those "discussions" would not happen. > As for Pharo being political, I have my doubts, It is political by essence, as an **open-source** project, it is more political because it promotes a vision, it is even more because it requires funding that is found by many ways that involve choices and politics. Then, the fact that you and your friends (you are a few here) want that we don't speak about that kind of topics (it was the same for the code of conduct) **is** political. So, you, by *arguing* with me right now, are making it political. What more do you need? > but calling people > names does not foster dialogue, Exactly! I don't want to dialogue with nazis and hear their shit, I want them to go away. And don't play the naive card: using precise keywords "woke", "woke incursion", "virtue-signalling", etc. are the mark of the nazis calling for more nazis to help them shut social and political actions down. It is factual. I am not the one insulting. > and certainly doesn't help building a > stronger community. > > Best regards, > > Esteban A. Maringolo > > On Wed, Jul 21, 2021 at 7:18 AM Steven Costiou > wrote: > >> Bullshit bullshit bullshit. >> >> It is not about feeling oppressed and stuff, it is about systemic racism >> that impregnated our vocabulary and that we are trying to get rid off. >> We should say in the FAQ that we support the idea of the transition but that >> for now, technically, using "master" is easier with Pharo until anyone from >> the community takes her time to solve the project. >> >> Woke + Virtue-Signalling => nazi words used by nazis to tell other nazis >> that they should nazify the discussion and kill every effort about any kind >> of social movement discussion. >> + typical nazi arguments everywhere in your messages... We're not stupid. >> >> Vocabulary and things will change. Pharo is political (in every way), so it >> has a political dimension and it will be discussed. >> You can do nothing about it. >> Just quit. >> >> Le 2021-07-21 11:51, miloslav.r...@cuzk.cz a écrit : >> >> Ugh. Slight history lesson / disambiguation. >> >> The phrasing „woke" actually came from „the left", first it was being „woke" >> about feminism, then this, then that. >> >> Then, those who felt oppressed by the sexist arguments of extreme, „woke" >> fraction of feminism, or racist arguments of those posing as anti-racists >> (and I could go on), started to use it as a pejorative, for those pushing >> insane propaganda, and for the propaganda itself. >> >> Then, those who called themselves / their positions „woke" in the past, >> started screeching that it is „extreme right vocabulary". >> >> As multiple people pointed out, master repository doesn't have anything to >> do with slavery; as I pointed out there is need to feel butthurt about some >> words even if your ancestors were affected by the concepts they were also >> used for. So you points are completely invalid, virtue-signalling garbage. >> >> But it usually takes „having the lived experience" of the woke garbage >> turning aginst you, to get one of the indoctrinated to leave their religion. >> And trying to do so doesn't belong on this forum, I just said what I felt >> needed to be said. >> >> And with this, I'm back to lurking, I just wanted to clearly demonstrate why >> such debates have no merit (clearly the opposite) on prog. lang. >> forums/mailing list. >> >> Everyone, keep on making Pharo great. >> >> From: Steven Costiou >> Sent: Tuesday, July 20, 2021 9:47 PM >> To: Rauš Miloslav >> Cc: pharo-dev@lists.pharo.org >> Subject: [Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming >> &g
[Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming
Bullshit bullshit bullshit. It is not about feeling oppressed and stuff, it is about systemic racism that impregnated our vocabulary and that we are trying to get rid off. We should say in the FAQ that we support the idea of the transition but that for now, technically, using "master" is easier with Pharo until anyone from the community takes her time to solve the project. Woke + Virtue-Signalling => nazi words used by nazis to tell other nazis that they should nazify the discussion and kill every effort about any kind of social movement discussion. + typical nazi arguments everywhere in your messages... We're not stupid. Vocabulary and things will change. Pharo is political (in every way), so it has a political dimension and it will be discussed. You can do nothing about it. Just quit. Le 2021-07-21 11:51, miloslav.r...@cuzk.cz a écrit : > Ugh. Slight history lesson / disambiguation. > > The phrasing „woke" actually came from „the left", first it was being „woke" > about feminism, then this, then that. > > Then, those who felt oppressed by the sexist arguments of extreme, „woke" > fraction of feminism, or racist arguments of those posing as anti-racists > (and I could go on), started to use it as a pejorative, for those pushing > insane propaganda, and for the propaganda itself. > > Then, those who called themselves / their positions „woke" in the past, > started screeching that it is „extreme right vocabulary". > > As multiple people pointed out, master repository doesn't have anything to do > with slavery; as I pointed out there is need to feel butthurt about some > words even if your ancestors were affected by the concepts they were also > used for. So you points are completely invalid, virtue-signalling garbage. > > But it usually takes „having the lived experience" of the woke garbage > turning aginst you, to get one of the indoctrinated to leave their religion. > And trying to do so doesn't belong on this forum, I just said what I felt > needed to be said. > > And with this, I'm back to lurking, I just wanted to clearly demonstrate why > such debates have no merit (clearly the opposite) on prog. lang. > forums/mailing list. > > Everyone, keep on making Pharo great. > > FROM: Steven Costiou > SENT: Tuesday, July 20, 2021 9:47 PM > TO: Rauš Miloslav > CC: pharo-dev@lists.pharo.org > SUBJECT: [Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming > > So far, no windmill complained about "woke incursions". > "Woke" is extremely clear vocabulary, only used by - let us get straight to > the point and not waste our time - modern nazis. > > So, perhaps you misused the word and should document yourself extensively on > the subject. > But your reply seems to point otherwise. > And *you* are the one feeling hurt because we want to recognize that > vocabulary has an impact on how we perceive and conceive things. > What was that again about cowardise and virtue? :) > > It is something to cope as we can with an annoying technical situation, it is > another thing to ask to not consider political views because they are "woke" > (which only purpose is to deny their legitimity without arguing). > Does the Pharo community support "anti-woke" argumentation? > This needs to be clear so that I can decide to leave the community or not. > > Or perhaps, that is a misunderstanding. > > Steven. > > Le 2021-07-20 20:12, miloslav.r...@cuzk.cz a écrit : > > Hi, > > it's „highly probably" somewhere in the territorry of poor understanding, but > I wouldn't blame language (don't pretend to be obtuse when you want to be > sneakily subversive). > > I explicitly stated that fighting against __actual__ slavery is better done > by other means / elsewhere. Fighting against percieved shadows („extreme > right vocabulary"; or nomenclature that never hurt no-one) is just divisive, > and counter-productive on a programming language mailing-list. > > You can't erase history, and that some words that had negative connotations > in the past are used for new, entirely unrelated purposes today is no wonder. > > As, of course, you can't be bothered to know, I'm member of one of those > nations called „Slavic" (.cz in my mail address). You know, you pretender, > nations who were enslaved so frequently that the word „slave" came from our > enslavement. Do I have a tendency to blame „heirs" of those who enslaved us > in the past ? Do I cringe every time the word slave is uttered ? Do you know > that some brainwashed individuals in our nation, in sync with todays > brainwashing, tried to push the narrative that
[Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming
So far, no windmill complained about "woke incursions". "Woke" is extremely clear vocabulary, only used by - let us get straight to the point and not waste our time - modern nazis. So, perhaps you misused the word and should document yourself extensively on the subject. But your reply seems to point otherwise. And *you* are the one feeling hurt because we want to recognize that vocabulary has an impact on how we perceive and conceive things. What was that again about cowardise and virtue? :) It is something to cope as we can with an annoying technical situation, it is another thing to ask to not consider political views because they are "woke" (which only purpose is to deny their legitimity without arguing). Does the Pharo community support "anti-woke" argumentation? This needs to be clear so that I can decide to leave the community or not. Or perhaps, that is a misunderstanding. Steven. Le 2021-07-20 20:12, miloslav.r...@cuzk.cz a écrit : > Hi, > > it's „highly probably" somewhere in the territorry of poor understanding, but > I wouldn't blame language (don't pretend to be obtuse when you want to be > sneakily subversive). > > I explicitly stated that fighting against __actual__ slavery is better done > by other means / elsewhere. Fighting against percieved shadows („extreme > right vocabulary"; or nomenclature that never hurt no-one) is just divisive, > and counter-productive on a programming language mailing-list. > > You can't erase history, and that some words that had negative connotations > in the past are used for new, entirely unrelated purposes today is no wonder. > > As, of course, you can't be bothered to know, I'm member of one of those > nations called „Slavic" (.cz in my mail address). You know, you pretender, > nations who were enslaved so frequently that the word „slave" came from our > enslavement. Do I have a tendency to blame „heirs" of those who enslaved us > in the past ? Do I cringe every time the word slave is uttered ? Do you know > that some brainwashed individuals in our nation, in sync with todays > brainwashing, tried to push the narrative that we (our nation), were > colonizers as well ? > > NO. > > No-one is gonna make me feel like a victim (or an abuser) because of what > happened in the past, before my father was born, etc. > > Go fight you windmills, Don Q., I just hope the rest of the community won't > let themselves be pulled into it. > > M.R. > > FROM: Steven Costiou > SENT: Tuesday, July 20, 2021 4:08 PM > TO: Pharo Development List > CC: Rauš Miloslav > SUBJECT: Re: [Pharo-dev] Re: Metacello / Iceberg / GitHub master to main > renaming > > Le 2021-07-19 16:54, miloslav.r...@cuzk.cz a écrit : > > Maybe it's worth putting something in an faq - that we support the intent of > the master to main naming convention > > That's pretty counter-productive. It would be just empty virtue-signalling > response to an empty virtue-signalling gesture (that of MS/Github pushing > master->main transition). > > The change would bring absolutely nothing to no-one (except a lot of needless > work/friction; and an inroad for future woke incursions). Whomever is having > problem with slavery can fight modern-day slavery in ie. Africa / China / etc > or sex trafficking in their own country. I'm a bit sorry if I misinterpret what you say because of my poor understanding of english. But I would answer that whomever having a problem with fighting slavery in general should leave the community. Anyone also using and supporting extreme right vocabulary (e.g. "woke") should leave the community. If that's trolling, all the same. If I misinterpreted (non-native english speaker), I am sorry, and probably you will agree with me and there is no need for dicussion. Steven. > I'd prefer either nothing in the FAQ, or finite statement to the tune of "no > wokeness, we are about merit and not about empty gestures". > > Of course I expect cowardice & virtue-signalling to win in the end, but at > least I tried. > M.R. > > -Original Message- > From: Tim Mackinnon > Sent: Monday, July 19, 2021 1:14 PM > To: Pharo Development List > Subject: [Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming > > Maybe it's worth putting something in an faq - that we support the intent of > the master to main naming convention, but that as we are a small community > trying to improve many aspects of 50 years of development, this one had to > unfortunately take a back seat for the moment while we simplify other things > to make this an easier change? > > Tim > > On 19 Jul 2021, at 12:26, stephane ducasse
[Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming
Le 2021-07-19 16:54, miloslav.r...@cuzk.cz a écrit : >> Maybe it's worth putting something in an faq - that we support the intent of >> the master to main naming convention > That's pretty counter-productive. It would be just empty virtue-signalling > response to an empty virtue-signalling gesture (that of MS/Github pushing > master->main transition). > > The change would bring absolutely nothing to no-one (except a lot of needless > work/friction; and an inroad for future woke incursions). Whomever is having > problem with slavery can fight modern-day slavery in ie. Africa / China / etc > or sex trafficking in their own country. I'm a bit sorry if I misinterpret what you say because of my poor understanding of english. But I would answer that whomever having a problem with fighting slavery in general should leave the community. Anyone also using and supporting extreme right vocabulary (e.g. "woke") should leave the community. If that's trolling, all the same. If I misinterpreted (non-native english speaker), I am sorry, and probably you will agree with me and there is no need for dicussion. Steven. > I'd prefer either nothing in the FAQ, or finite statement to the tune of "no > wokeness, we are about merit and not about empty gestures". > > Of course I expect cowardice & virtue-signalling to win in the end, but at > least I tried. > M.R. > > -Original Message- > From: Tim Mackinnon > Sent: Monday, July 19, 2021 1:14 PM > To: Pharo Development List > Subject: [Pharo-dev] Re: Metacello / Iceberg / GitHub master to main renaming > > Maybe it's worth putting something in an faq - that we support the intent of > the master to main naming convention, but that as we are a small community > trying to improve many aspects of 50 years of development, this one had to > unfortunately take a back seat for the moment while we simplify other things > to make this an easier change? > > Tim > > On 19 Jul 2021, at 12:26, stephane ducasse wrote: > > Sven > > From that perspective this master to main change will cost us a lot of > problem. > I decided to continue to configure all my repositories to use master > and I will do it for any repository that is related to pharo and that people > may use. Just to remove such kind of friction. > I would encourage people to do the same like that we do not have to think. > > S > > On 12 Jul 2021, at 14:32, Sven Van Caekenberghe wrote: > > Hi, > > For new GitHub projects the default branch is now main instead of master. > > There is however code in Metacello / Iceberg / ... that tries a number of > options if no branch is specified, but it is not yet aware of this change. > > Specifically: > > This does not work > > ./pharo reddit.image metacello install github://svenvc/Reddit > BaselineOfReddit > > instead you have to say > > ./pharo reddit.image metacello install github://svenvc/Reddit:main/ > BaselineOfReddit > > It took me half an hour to figure this out ;-) > > Sven
Re: [Pharo-dev] Why UnhandledError is not the only way to open debugger?
Le 2019-12-19 19:54, Denis Kudriashov a écrit : > Or in other words why Halt and Warning open debugger directly instead of > using UnhandledError signalling? > > In Squeak it's all going though UnhandledError. Hi Denis, Thomas Dupriez made a nice documentation from existing materials about how exceptions are handled: -https://raw.githubusercontent.com/pharo-open-documentation/pharo-wiki/master/General/Exceptions_Image_WhatHappensWhenAnExceptionIsSignalled.png - https://github.com/pharo-open-documentation/pharo-wiki/blob/master/General/Exceptions.md I am also interested in deeply understanding these mechanics because I have strange behavior with the new spec debugger when it comes to stepping over code that produces an exception and how to "catch it" to display useful information in the gui. I am going into vacations tomorrow with no or few internet, so I will only follow from far away but not participate until january. Steven.
Re: [Pharo-dev] [Mm10s] 2019-11-25
Le 2019-11-28 14:15, ducasse a écrit : > Thanks steven > If you need beta tester please let me know. Yes please, the halt/bp window in the debugger needs feedback. Start a P8 image, then reload spec https://github.com/pharo-spec/Spec then load NewTools https://github.com/pharo-spec/NewTools It should be active by default. Steven. > S. > >> On 28 Nov 2019, at 11:29, Steven Costiou wrote: >> >> ### Last week: >> >> - halt/breakpoint manager in the spec debugger: see all halt/breakpoints and >> (de)activate them in one click. When deactivated, a halt/breakpoint just >> prints a log message in the Transcript. >> >> - Pharo IOT book writing >> >> ### This week (starting 2019-11-25): >> >> - Pharo IOT book writing >> >> - add a "watch variable" window in the debugger to track variables during >> debugging >> >> ### Pipeline >> >> - Pharo IOT book >> >> - Enhancing the spec debugger: better breakpoint support, adding missing >> features (menus, options), fixing bugs >> >> - Integrating object-centric debugging in the spec2 tools >> >> - Writing a chapter/documentation about the Pharo debugger
Re: [Pharo-dev] [Mm10s] 2019-11-25
### Last week: - halt/breakpoint manager in the spec debugger: see all halt/breakpoints and (de)activate them in one click. When deactivated, a halt/breakpoint just prints a log message in the Transcript. - Pharo IOT book writing ### This week (starting 2019-11-25): - Pharo IOT book writing - add a "watch variable" window in the debugger to track variables during debugging ### Pipeline - Pharo IOT book - Enhancing the spec debugger: better breakpoint support, adding missing features (menus, options), fixing bugs - Integrating object-centric debugging in the spec2 tools - Writing a chapter/documentation about the Pharo debugger
Re: [Pharo-dev] About the infinite debugger
Hi, i had no answer to my comments on fogbuz (one of the first) so i assumed it was not a good idea. In the usecases i used to reproduce the bug, replacing "ex pass" by "ex debug" in runCaseForDebug:solved the problem. See the analysis on fogbuz. Did not have any side effect, but i do not know enough about the system and maybe it does. I think i already asked about that somewhere (here or on discord) but no answers. But maybe it is wrong to do that? I'd be happy to have feedback on that. Steven. Le 2018-08-05 22:27, Tim Mackinnon a écrit : > Guys - this really needs attention - I've spend hours now trying to debug > some code and most of it is in closing infinite debuggers. It makes a mockery > of our tagline - "awesome debugging". And the extra irony is that I'm > debugging some file path stuff for exercism, to make it easier for hopefully > more people to learn Pharo. > > How can we get this fixed? > > Tim > > On 2 Aug 2018, at 21:44, Norbert Hartl wrote: > > bump > > Am 04.07.2018 um 02:28 schrieb Martin McClure : > > On 07/03/2018 05:02 PM, Martin McClure wrote: On 06/29/2018 07:48 AM, > Guillermo Polito wrote: > I know that the exception handling/debugging has been modified several > times in the latest years (some refactorings, hiding contexts...), we > unfortunately don't have tests for it, so I'd like some more pair of > eyes on it. Ben, Martin could you take a look? > Hi Guille, > I'm just back from vacation last week, and about to go on vacation for > another week, but I'll see what I can see. > About the primitive pragmas for context-marking, I think some of those > were changed for the exception handling fix that Andres and I did a few > years back, so *could* be involved in this. I'd hate to see regression > in the exception handling in an attempt to fix this bug. After a look at at the pull request, I'm quite sure that removing the prim 199 marker is the wrong thing to do. Thanks, Pablo, for restoring it! The start of execution of exception handlers must be marked in order for #findNextHandlerContext to work correctly. If these contexts are not marked, exceptions signaled from inside an exception handler can find the wrong handler. See the code and comment in #findNextHandlerContext. I'm afraid that I cannot immediately help with the debugger problem, since I don't know the debugger nearly as well as I do the exception handling code, and I'm going on vacation for a week in 20 minutes. :-) Perhaps when I get back I can take a look at it if it is still a problem by then. Regards, -Martin
[Pharo-dev] About infinite debuggers in tests (https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger)
Hi, Is that normal that in the following method we do "EX PASS" (at the end)? runCaseForDebug: aTestCase [ aTestCase announce: TestCaseStarted withResult: self. aTestCase runCaseManaged. aTestCase announce: TestCaseEnded withResult: self. "To not affect performance of big test suites following logic is not inside addPass: method" errors remove: aTestCase ifAbsent: [ ]. failures remove: aTestCase ifAbsent: [ ]. self addPass: aTestCase ] on: self class failure , self class skip , self class warning , self class error do: [ :ex | ex sunitAnnounce: aTestCase toResult: self. EX PASS ] I think it is the source of the infinite crazy debugger bug (maybe i'm wrong) https://pharo.fogbugz.com/f/cases/22085/Infinite-debugger Doing "ex debug" solves the problem but i do not know the impact (pharo 5 - 6 - 7, but not previous versions). For what i understand, it happens because : - when you got an error in a test, it goes through the ex pass - but when you got a doesNotUnderstand, it first goes into: doesNotUnderstand: aMessage | exception resumeValue | (exception := MessageNotUnderstood new) message: aMessage; receiver: self. RESUMEVALUE := EXCEPTION SIGNAL. ^exception reachedDefaultHandler ifTrue: [AMESSAGE SENTTO: SELF] ifFalse: [resumeValue] In normal cases (class of the receiver is not a test case), when you step in the debugger the EXCEPTION SIGNAL blocks the execution right away. In subclasses of TESTCASE, it does EX PASS each time you signal the exception and so it continues in the doesNotUnderstand. Then it enters the AMESSAGE SENTTO: SELF in the doesNotUnderstand, which is still not understood and goes again into the "ex pass", then you can wait a long time... I'm not really sure though why it does not open another debugger and why it gets stuck. Maybe that is the real bug: it should open another debugger and not loop and pop one million debugging windows after a user interruption. Another side effect is that the watchdog of the TestExecutionEnvironment also gets stuck and stops counting for the timeout, because a debugging session was open and never closed (because its looping). See TestExecutionEnvironment>>watchDogLoopFor:. Replacing EX PASS by EX DEBUG seems to work and reproduce the standard behavior of the debugger for classes that are not subclasses of TestCase. But i do not know if the "pass" was explicitly intended and if there will be side effects... Steven.
[Pharo-dev] Exception in Iceberg when removing selectors from anonymous classes
Hi, i downloaded yesterday the latest Pharo 7 and in a playground if you do: class := Object newAnonymousSubclass. (OK) class package. "a RPackage(_UnpackagedPackage)" (OK) class compile: 'test ^nil'. (OK) (class >> #test) package. "nil" (Surprising but no problem with any pharo version since yesterday) class removeSelector: #test. (Exception, see below) An exception is raised in IceSystemEventListener class because the method package is nil: handlePackagesChange: packages IceRepository registry do: [ :repository | | changed | changed := packages anySatisfy: [ :each | repository notifyPackageModified: each name ]. "(EACH IS NIL HERE)" changed ifTrue: [ Iceberg announcer announce: (IceRepositoryModified for: repository) ]] So to fix it, the package needs to be correctly set for each method compiled in an anonymous class, but should anonymous subclasses really raise events when adding/modifying/removing methods? Steven.
Re: [Pharo-dev] Does Talents project published somewhere?
Hi, Talents can be found here http://scg.unibe.ch/research/bifrost/talents , there is a one click distribution but its pharo 1.3 and it is not possible to just load the Talents into more recent versions of Pharo. The Bifröst framework has to come with it from now, i'm also interested in having Talents in Pharo 5/6 and it was on my agenda to port it from the 1.3 to the 5.0. It may not be technically hard but i think it is a matter of knowing what to do... Steven. Le 2016-09-13 16:25, Denis Kudriashov a écrit : > Hi. > > I am interesting in object specific traits. And I saw paper about Talents. > But I can't find this project anywhere. Is it published? > > Best regards, > Denis
