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

[ANN] Pharo Consortium New Bronze Member: ApptiveGrid

by Marcus Denker

The Pharo Consortium is very happy to announce that ApptiveGrid GmbH has joined the Consortium as a Bronze Member. About - ApptiveGrid: https://www.apptivegrid.de - Pharo Consortium: http://consortium.pharo.org ApptiveGrid is a SaaS tool to digitalize and automatize business processes. ApptiveGrid is a visual database that lets you effortlessly create and modify your data models through a web frontend, seamlessly integrates with REST API for external access, and features a dynamic form creator for easy data collection. It's also a powerful workflow system, where you can design and automate your processes, responding to both internal changes and external triggers through web hooks. The backend of ApptiveGrid is 100% Pharo: It uses [zinc](https://github.com/svenvc/zinc) components for the HTTP frontend and [soil](https://github.com/ApptiveGrid/Soil) as the persistence solution. The goal of the Pharo Consortium is to allow companies and institutions to support the ongoing development and future of Pharo. Individuals can support Pharo via the Pharo Association https://association.pharo.org

Jan. 8, 2024

Re: How to halt on Test errors?

by Davide Varvello

Hi Gabriel,Your answer leads back to my original question: how can I implement the "halt on error"? It is not clear to me. Cheers Davide On Monday, January 8, 2024 at 02:31:33 PM GMT+1, Gabriel Cotelli <g.cotelli(a)gmail.com> wrote: You can implement another version of TestResult that halts when an error is added instead of recording it, and reimplement classForTestResult in the test cases to return this new class instead. On Mon, Jan 8, 2024 at 5:54â¯AM Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: No ideas? CheersDavide On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Noury, You are right and reading your answer I understand I wasn't crystal clear. I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command.Is there anything like that in Pharo? TIA Davide On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: Hi Davide, Why not use one of the following: self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch"self shouldnt:Â ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Guys, Sometimes I'd like to stop my test suite when an error occurs. My raw approach is to put a self haltÂ in the TestResult>>addError:Â and look at the debugger, but I'm wondering if there is a more suitable way. Can you help me, please? TIADavide

Jan. 8, 2024

Re: How to halt on Test errors?

by Guillermo Polito

Yes. Also you can try extending the current commands to get your âDebug Testsâ from the class side. And we accept contributions :) > El 8 ene. 2024, a las 14:31, Gabriel Cotelli <g.cotelli(a)gmail.com> escribiÃ³: > > You can implement another version of TestResult that halts when an error is added instead of recording it, and reimplement classForTestResult in the test cases to return this new class instead. > > On Mon, Jan 8, 2024 at 5:54â¯AM Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > No ideas? > > Cheers > Davide > > > On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > > > Hi Noury, > > You are right and reading your answer I understand I wasn't crystal clear. > > I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command. > Is there anything like that in Pharo? > > TIA > > Davide > > On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com <mailto:bouraqadi@gmail.com>> wrote: > > > Hi Davide, > > Why not use one of the following: > > self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > self shouldnt: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > > On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org>> wrote: > Hi Guys, > > Sometimes I'd like to stop my test suite when an error occurs. > > My raw approach is to put a self halt in the TestResult>>addError: and look at the debugger, but I'm wondering if there is a more suitable way. > > Can you help me, please? > > TIA > Davide

Jan. 8, 2024

Re: How to halt on Test errors?

by Gabriel Cotelli

You can implement another version of TestResult that halts when an error is added instead of recording it, and reimplement classForTestResult in the test cases to return this new class instead. On Mon, Jan 8, 2024 at 5:54â¯AM Davide Varvello via Pharo-users < pharo-users(a)lists.pharo.org> wrote: > No ideas? > > Cheers > Davide > > > On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via > Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Hi Noury, > > You are right and reading your answer I understand I wasn't crystal clear. > > I have a test scenario where sometimes a race condition occurs, so I'm not > expecting any error. Which is why I'd prefer something built-in Pharo: a > sort of "haltIfError" or "haltOnError" built-in command. > Is there anything like that in Pharo? > > TIA > > Davide > > On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi < > bouraqadi(a)gmail.com> wrote: > > > Hi Davide, > > Why not use one of the following: > > self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > > self shouldnt: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > > > On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users < > pharo-users(a)lists.pharo.org> wrote: > > Hi Guys, > > Sometimes I'd like to stop my test suite when an error occurs. > > My raw approach is to put a self halt in the TestResult>>addError: and > look at the debugger, but I'm wondering if there is a more suitable way. > > Can you help me, please? > > TIA > Davide > >

Jan. 8, 2024

Re: How to halt on Test errors?

by Davide Varvello

Hi Guillermo,There is no debug mode on test classes (see screenshot), it is at method level and unfortunately the error does not occur when I run the single test method, but when I ran the whole test class. How can I run the debugger at test class level? Cheers Davide On Monday, January 8, 2024 at 10:07:37 AM GMT+1, Guillermo Polito <guillermopolito(a)gmail.com> wrote: Hi Davide, I donât think something specific to your needs exists, but you can easily build your own.There is already for example `haltIfTest` that will halt if youâre in the dynamic extent of a test. If youâre dealing with concurrency issues, I donât understand how the `haltIfError` is actually helping you.Just running the test in debug mode is not enough? => it should open a debugger when it finds an error, right? G El 8 ene. 2024, a las 09:54, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> escribiÃ³: No ideas? CheersDavide On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Noury, You are right and reading your answer I understand I wasn't crystal clear. I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command.Is there anything like that in Pharo? TIA Davide On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: Hi Davide, Why not use one of the following: self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch"self shouldnt:Â ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Guys, Sometimes I'd like to stop my test suite when an error occurs. My raw approach is to put a self haltÂ in the TestResult>>addError:Â and look at the debugger, but I'm wondering if there is a more suitable way. Can you help me, please? TIADavide

Jan. 8, 2024

Re: How to halt on Test errors?

by Guillermo Polito

Hi Davide, I donât think something specific to your needs exists, but you can easily build your own. There is already for example `haltIfTest` that will halt if youâre in the dynamic extent of a test. If youâre dealing with concurrency issues, I donât understand how the `haltIfError` is actually helping you. Just running the test in debug mode is not enough? => it should open a debugger when it finds an error, right? G > El 8 ene. 2024, a las 09:54, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> escribiÃ³: > > No ideas? > > Cheers > Davide > > > On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > > Hi Noury, > > You are right and reading your answer I understand I wasn't crystal clear. > > I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command. > Is there anything like that in Pharo? > > TIA > > Davide > > On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: > > > Hi Davide, > > Why not use one of the following: > > self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > self shouldnt: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" > > On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hi Guys, > > Sometimes I'd like to stop my test suite when an error occurs. > > My raw approach is to put a self halt in the TestResult>>addError: and look at the debugger, but I'm wondering if there is a more suitable way. > > Can you help me, please? > > TIA > Davide

Jan. 8, 2024

Re: How to halt on Test errors?

by Davide Varvello

No ideas? CheersDavide On Thursday, January 4, 2024 at 03:42:17 PM GMT+1, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Noury, You are right and reading your answer I understand I wasn't crystal clear. I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command.Is there anything like that in Pharo? TIA Davide On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: Hi Davide, Why not use one of the following: self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch"self shouldnt:Â ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Guys, Sometimes I'd like to stop my test suite when an error occurs. My raw approach is to put a self haltÂ in the TestResult>>addError:Â and look at the debugger, but I'm wondering if there is a more suitable way. Can you help me, please? TIADavide

Jan. 8, 2024

Call for chapters

by stephane ducasse

Welcome to this collaborative book. We are looking for contributions to new tools in the Pharo ecosystem. Here is a non-exhaustive list of possible tools we have in mind. Development tools such as refactoring, memory usage, and new approaches to debugging Development tools such as UI builders Development tools to develop compilers Tools for modeling such as Cormas, Moose Libraries as basis for advanced tools Each chapter will be reviewed by three reviewers. We expect the chapters to describe the tools, present some clear scenarios, describe key elements of implementations, evidence of use of the tools, Submission process: A chapter must be written in Microdown. Writers may want to clone the current repository and use Pillar (see https://github.com/pillar-markup/pillar and https://github.com/pillar-markup/microdown) The Sample1 folder in the Chapters folder contains a sample chapter. The authors should send an email to stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>, goca(a)dmi.uns.ac.rs <mailto:goca@dmi.uns.ac.rs>, and juanpablo.sandoval(a)uc.cl <mailto:juanpablo.sandoval@uc.cl>. The authors should then do a PR to this repository with their chapter containing all their files. The length of each chapter is not fixed but authors should make sure that the chapter is not either too short or too long. It is worth to see that the format is good for tutorials but is not compact. We will give feedback on this aspect. As usual the material should be new and unpublished. Citations should be expressed using the microdown citation e.g. {!citation|ref=Blac09a!} using {!citation|ref=Blac09a!}, A chapter must be spellchecked with a system such as grammarly, if needed, each chapter should contain a bibfile having the same name than the main folder file, if needed each chapter should contain a folder named 'figures' that contains the figures of the chapter. The Sample1 folder illustrates this structure, it contains: Sample1.bib Sample1.md figures/pharo.png figures/rmod.png This book will be published via the book-on-demand program of http://bod.fr <http://bod.fr/>. It will be published on the Bibliotheque Nationale de France and it will be available on most public platforms such as amazon.com. S. Ducasse, G. Rakic and J-P Sandoval -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Jan. 6, 2024

Re: How to halt on Test errors?

by Davide Varvello

Hi Noury, You are right and reading your answer I understand I wasn't crystal clear. I have a test scenario where sometimes a race condition occurs, so I'm not expecting any error. Which is why I'd prefer something built-in Pharo: a sort of "haltIfError" or "haltOnError" built-in command.Is there anything like that in Pharo? TIA Davide On Thursday, January 4, 2024 at 01:24:59 PM GMT+1, Noury Bouraqadi <bouraqadi(a)gmail.com> wrote: Hi Davide, Why not use one of the following: self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch"self shouldnt:Â ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: Hi Guys, Sometimes I'd like to stop my test suite when an error occurs. My raw approach is to put a self haltÂ in the TestResult>>addError:Â and look at the debugger, but I'm wondering if there is a more suitable way. Can you help me, please? TIADavide

Jan. 4, 2024

Re: How to halt on Test errors?

by Noury Bouraqadi

Hi Davide, Why not use one of the following: self should: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" self shouldnt: ["message that might signal an error"] raise: Error "Replace Error with the exception you want to catch" On Jan 3 2024, at 4:55 pm, Davide Varvello via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hi Guys, > > Sometimes I'd like to stop my test suite when an error occurs. > > My raw approach is to put a self halt in the TestResult>>addError: and look at the debugger, but I'm wondering if there is a more suitable way. > > Can you help me, please? > > TIA > Davide >

Jan. 4, 2024