- Pharo-dev - lists.pharo.org

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

by Marcus Denker

After a holiday break, we resume the weekly issue tracker report # Pharo 11 - Extend FFIExternalStructureReferenceHandle with tfPointerAddress #15951 https://github.com/pharo-project/pharo/pull/15951 # Bugs - Fix bug in integer vs float comparisons #15973 https://github.com/pharo-project/pharo/pull/15973 - adding back millisecondsToRun: but we will deprecate it. #15969 https://github.com/pharo-project/pharo/pull/15969 # Refactoring Engine - Fix: instance and shared variables driver bugs #15983 https://github.com/pharo-project/pharo/pull/15983 - Fix: cannot move method to class side #15981 https://github.com/pharo-project/pharo/pull/15981 - Adding documentation on the rewrite rules #15966 https://github.com/pharo-project/pharo/pull/15966 - Make insert superclass and subclass working again #15957 https://github.com/pharo-project/pharo/pull/15957 - Add rb to any rb entity printString! Green tests #15959 https://github.com/pharo-project/pharo/pull/15959 - Refactor: pass on refactoring preconditions #15954 https://github.com/pharo-project/pharo/pull/15954 # Metacello Cleanup - Clean(Gofer, Metacello): remove junk and old/unused repositories. #15968 https://github.com/pharo-project/pharo/pull/15968 # Rules / Code Critic - Improve ReMultiplePeriodsTerminatingStatementRule #15956 https://github.com/pharo-project/pharo/pull/15956 - Add release test for ReDoNotSendSuperInitializeInClassSideRule #15972 https://github.com/pharo-project/pharo/pull/15972

Jan. 19, 2024

Re: About removing class side initialization

by David Mason

I like James' suggestion. It shouldn't matter if someone defines a class initialize or not, or whether they call super initialize. So either Object class should have an empty one (like Object>>initialize) or Behavior>>initialize should do the right thing. The Smalltalk way would be for it to go in Object class, because even infrastructure code like Behavior should avoid condition checking when the dispatch rules can already solve the problem. ../Dave On Wed, 17 Jan 2024 at 22:52, James Foster via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > Stef, > > Your comments brought to mind a few thoughts. > > First, initialize methods should, in general, be idempotent; that is, > running them repeatedly should not make further changes after the first run > (along the lines of your mention of lazy initialization). For example, if a > variable is nil then it should be set to an empty set; if it is already a > set, donât replace it. > > Second, many packaging systems have scripts for pre-load, post-load, > pre-remove, and post-remove. Instead of having initialize methods on a > class, we could have scripts associated with a package. (Presumably a > package will be a first-class object and have methods to handle these > action.) > > Third, following a model from upgrading databases, one would have a > âversion numberâ stored somewhere (perhaps a class variable) and scripts > that upgrade and downgrade the version. Rerunning the âupgradeâ would be > idempotent since we would already be on the latest version. > > As to the specific situation, yes, there is a problem with > Behavior>>#initialize that arises from Behaviorâs unique position where > instances are classes and we have an unfortunate gratuitous polymorphism > between instance initialization in which we are creating a new instance of > Behavior (and giving it an empty method dictionary) and class > initialization which is typically associated with _loading_ or _installing_ > a class. Perhaps with a time machine the right solution would be separate > names for these concepts (#initialize for instances, and #postLoad for > classes). But really, the only place this is confusing is with Behavior, so > maybe we should treat it as a special case rather than reaching for a > general solution. > > I think that rather than trying to prevent calling super initialize on > classes (when failing to call super initialize on instances is a common > bug) or trying to prevent an initialize from reaching Behavior>>initialize > (by blocking it on the class side of Object), we should simply have > Behavior>>initialize recognize its special position (and unique risk for > confusion) by being idempotent. That is, if we already have a method > dictionary, then there is no reason to do any further initialization; just > protect the existing code with a check of âare we already initialized?â (Do > the simplest thing that could possible work!) > > So, while we could look at bigger solutions like package managers or image > versions, we should just start by making Behavior>>#initialize smart enough > to recognize its unique danger and handle the problem there. I donât like > the situation in which some initialize methods _must_ call super and some > initialize methods _must not_ call super. > > In fact, I could imagine that there are some times when class > initialization _should_ call super. Perhaps I have an abstract superclass > that builds and caches a list of its subclasses (in GemStone this would be > non-trivial). When a new subclass is added and the subclass is initialized, > I want the super initialize method to be called so the superclass can > reinitialize its cache. Perhaps this is a contrived case, but the point is > that it isnât really appropriate to put in a rule that you should not send > super initialize. > > Just some ideas and thoughts to let you know Iâm reading your postsâ¦ > > James Foster > > > > On Jan 17, 2024, at 12:37â¯PM, stephane ducasse < > stephane.ducasse(a)inria.fr> wrote: > > > > Hi community > > > > I would like to get use your ideas. > > > > Here is the case > > > > Context: Class side initialize are not good. > > We fixed a bug with guille today (should do a PR) this bug was > breaking some projects by changing the superclass of classes to Object. > Radical! > > > > It was produced by the removal of DependentFields in Object and > the removal of the class side Object initialize method > > Needed to initialize DependentFields (RIP). > > > > Doing so when a class was doing a super initialize it executes the > Behavior>>#initialize (which reinitialize the class and its superclass) > and was not reachable before because blocked by Object class>>#initialize. > > > > Two Situations. > > > > When we do a class super initialize there are two cases > > > > Case 1. the super reaches Behavior>>#initialize and your class > gets killed. > > Solution 1. Easy we will define a class side initialize method to > protect the execution of Behavior>>#initialize. > > Ideally raising a warning so that people can find their problems. > > > > Case 2. > > You have a little hierarchy Root and Subclass1 Subclass2 > classes > > Root class defines an initialize method. > > > > You should not redefine initialize in Subclass1 and do a > super initialize > > else we get a double initialize. Not easy to grasp so I > guess that many people are making this mistake. > > > > Solution 2. > > Cyril added a rule in a ReleaseTest (yes this is cool and > we should use more rules and not code by hand in the releaseTest) > > that checks for no class side super initialize in Pharo. > > > > Now long time ago I thought that this class initialize is not that good > and that I would like to have > > a way that class state dependencies do not have to be resolved by the > developers by initializing first A then B > > but that the system could do it automatically. In this case we would not > need initialize by class construction. > > > > Do you have an idea how such design could be? > > > > Iâm too dead right now to think but to me it feels a bit similar to lazy > initialization. > > If all the shared variables would be only accessed by lazy accessors > then we do not need to initialize them statically. > > Now this is a bit extreme but this is to illustrate my wish. > > > > So let us know :) > > Stef > > > > > > > > > > >

Jan. 18, 2024

Re: About removing class side initialization

by Pablo Tesone

Yes to all, I always hated the #initialize in class side, I think we should divide them. It will be easy to remove the #initialize in Behavior and rename it to something else that is called during the real initialization of the objects. In the long time I think we should change the initialize name to something like "doWhenTheClassIsInstaller" or maybe less verbose :P I am not sure about lazy initialization, but it also is a nice solution. Cheers, Pablo On 17/01/2024 21:37, stephane ducasse wrote: > Hi community > > I would like to get use your ideas. > > Here is the case > > Context: Class side initialize are not good. > We fixed a bug with guille today (should do a PR) this bug was breaking some projects by changing the superclass of classes to Object. Radical! > > It was produced by the removal of DependentFields in Object and the removal of the class side Object initialize method > Needed to initialize DependentFields (RIP). > > Doing so when a class was doing a super initialize it executes the Behavior>>#initialize (which reinitialize the class and its superclass) and was not reachable before because blocked by Object class>>#initialize. > > Two Situations. > > When we do a class super initialize there are two cases > > Case 1. the super reaches Behavior>>#initialize and your class gets killed. > Solution 1. Easy we will define a class side initialize method to protect the execution of Behavior>>#initialize. > Ideally raising a warning so that people can find their problems. > > Case 2. > You have a little hierarchy Root and Subclass1 Subclass2 classes > Root class defines an initialize method. > > You should not redefine initialize in Subclass1 and do a super initialize > else we get a double initialize. Not easy to grasp so I guess that many people are making this mistake. > > Solution 2. > Cyril added a rule in a ReleaseTest (yes this is cool and we should use more rules and not code by hand in the releaseTest) > that checks for no class side super initialize in Pharo. > > Now long time ago I thought that this class initialize is not that good and that I would like to have > a way that class state dependencies do not have to be resolved by the developers by initializing first A then B > but that the system could do it automatically. In this case we would not need initialize by class construction. > > Do you have an idea how such design could be? > > Iâm too dead right now to think but to me it feels a bit similar to lazy initialization. > If all the shared variables would be only accessed by lazy accessors then we do not need to initialize them statically. > Now this is a bit extreme but this is to illustrate my wish. > > So let us know :) > Stef > > > > > >

Jan. 18, 2024

Re: About removing class side initialization

by James Foster

Stef, Your comments brought to mind a few thoughts. First, initialize methods should, in general, be idempotent; that is, running them repeatedly should not make further changes after the first run (along the lines of your mention of lazy initialization). For example, if a variable is nil then it should be set to an empty set; if it is already a set, donât replace it. Second, many packaging systems have scripts for pre-load, post-load, pre-remove, and post-remove. Instead of having initialize methods on a class, we could have scripts associated with a package. (Presumably a package will be a first-class object and have methods to handle these action.) Third, following a model from upgrading databases, one would have a âversion numberâ stored somewhere (perhaps a class variable) and scripts that upgrade and downgrade the version. Rerunning the âupgradeâ would be idempotent since we would already be on the latest version. As to the specific situation, yes, there is a problem with Behavior>>#initialize that arises from Behaviorâs unique position where instances are classes and we have an unfortunate gratuitous polymorphism between instance initialization in which we are creating a new instance of Behavior (and giving it an empty method dictionary) and class initialization which is typically associated with _loading_ or _installing_ a class. Perhaps with a time machine the right solution would be separate names for these concepts (#initialize for instances, and #postLoad for classes). But really, the only place this is confusing is with Behavior, so maybe we should treat it as a special case rather than reaching for a general solution. I think that rather than trying to prevent calling super initialize on classes (when failing to call super initialize on instances is a common bug) or trying to prevent an initialize from reaching Behavior>>initialize (by blocking it on the class side of Object), we should simply have Behavior>>initialize recognize its special position (and unique risk for confusion) by being idempotent. That is, if we already have a method dictionary, then there is no reason to do any further initialization; just protect the existing code with a check of âare we already initialized?â (Do the simplest thing that could possible work!) So, while we could look at bigger solutions like package managers or image versions, we should just start by making Behavior>>#initialize smart enough to recognize its unique danger and handle the problem there. I donât like the situation in which some initialize methods _must_ call super and some initialize methods _must not_ call super. In fact, I could imagine that there are some times when class initialization _should_ call super. Perhaps I have an abstract superclass that builds and caches a list of its subclasses (in GemStone this would be non-trivial). When a new subclass is added and the subclass is initialized, I want the super initialize method to be called so the superclass can reinitialize its cache. Perhaps this is a contrived case, but the point is that it isnât really appropriate to put in a rule that you should not send super initialize. Just some ideas and thoughts to let you know Iâm reading your postsâ¦ James Foster > On Jan 17, 2024, at 12:37â¯PM, stephane ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi community > > I would like to get use your ideas. > > Here is the case > > Context: Class side initialize are not good. > We fixed a bug with guille today (should do a PR) this bug was breaking some projects by changing the superclass of classes to Object. Radical! > > It was produced by the removal of DependentFields in Object and the removal of the class side Object initialize method > Needed to initialize DependentFields (RIP). > > Doing so when a class was doing a super initialize it executes the Behavior>>#initialize (which reinitialize the class and its superclass) and was not reachable before because blocked by Object class>>#initialize. > > Two Situations. > > When we do a class super initialize there are two cases > > Case 1. the super reaches Behavior>>#initialize and your class gets killed. > Solution 1. Easy we will define a class side initialize method to protect the execution of Behavior>>#initialize. > Ideally raising a warning so that people can find their problems. > > Case 2. > You have a little hierarchy Root and Subclass1 Subclass2 classes > Root class defines an initialize method. > > You should not redefine initialize in Subclass1 and do a super initialize > else we get a double initialize. Not easy to grasp so I guess that many people are making this mistake. > > Solution 2. > Cyril added a rule in a ReleaseTest (yes this is cool and we should use more rules and not code by hand in the releaseTest) > that checks for no class side super initialize in Pharo. > > Now long time ago I thought that this class initialize is not that good and that I would like to have > a way that class state dependencies do not have to be resolved by the developers by initializing first A then B > but that the system could do it automatically. In this case we would not need initialize by class construction. > > Do you have an idea how such design could be? > > Iâm too dead right now to think but to me it feels a bit similar to lazy initialization. > If all the shared variables would be only accessed by lazy accessors then we do not need to initialize them statically. > Now this is a bit extreme but this is to illustrate my wish. > > So let us know :) > Stef > > > > >

Jan. 18, 2024

About removing class side initialization

by stephane ducasse

Hi community I would like to get use your ideas. Here is the case Context: Class side initialize are not good. We fixed a bug with guille today (should do a PR) this bug was breaking some projects by changing the superclass of classes to Object. Radical! It was produced by the removal of DependentFields in Object and the removal of the class side Object initialize method Needed to initialize DependentFields (RIP). Doing so when a class was doing a super initialize it executes the Behavior>>#initialize (which reinitialize the class and its superclass) and was not reachable before because blocked by Object class>>#initialize. Two Situations. When we do a class super initialize there are two cases Case 1. the super reaches Behavior>>#initialize and your class gets killed. Solution 1. Easy we will define a class side initialize method to protect the execution of Behavior>>#initialize. Ideally raising a warning so that people can find their problems. Case 2. You have a little hierarchy Root and Subclass1 Subclass2 classes Root class defines an initialize method. You should not redefine initialize in Subclass1 and do a super initialize else we get a double initialize. Not easy to grasp so I guess that many people are making this mistake. Solution 2. Cyril added a rule in a ReleaseTest (yes this is cool and we should use more rules and not code by hand in the releaseTest) that checks for no class side super initialize in Pharo. Now long time ago I thought that this class initialize is not that good and that I would like to have a way that class state dependencies do not have to be resolved by the developers by initializing first A then B but that the system could do it automatically. In this case we would not need initialize by class construction. Do you have an idea how such design could be? Iâm too dead right now to think but to me it feels a bit similar to lazy initialization. If all the shared variables would be only accessed by lazy accessors then we do not need to initialize them statically. Now this is a bit extreme but this is to illustrate my wish. So let us know :) Stef

Jan. 17, 2024

ESUG 2024 book the dates

by stephane ducasse

Hello The ESUG board decided the dates and location of the next ESUG conference ESUG 2024 will be at Lille from 8th to 11th July 2024. Notice that this year the conference will be on 4 days. The early rate registration will be 15 of April 2024. The IWST workshop will be chaired by G. Rakic and S. Ducasse. To help us organizing the conference we will ask authors to register to the conference when submitting their article. In the really rare case an article would not be accepted, ESUG will fully reimburse you without any cost. We will update the website. Stef -------------------------------------------- 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. 15, 2024

[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

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: [ANN] success story: ApptiveGrid

by Yanni Chiu

Thanks for all the write ups and presentations. Theyâve pointed me at some new technologies, and confirmed that Iâm not the only one thinking along certain lines. Hopefully Iâll finally get something into production in 2024. I think Soil is definitely the way forward. Once youâve stuck a traditional âdatabaseâ into your architecture, you can end up working harder to work around the constraints imposed by the database than was initially saved. Soil eliminates the âwallâ between your code and the database, so you can get objects all the way down. Yanni On Fri, Dec 29, 2023 at 12:25 PM Norbert Hartl <norbert(a)hartl.name> wrote: > Thanks to all of you for the nice comments. > > I wish you, pharo and the community all the best for 2024. In 2024 there > will be a soil release that I promised for this year but I didnât make it. > > Norbert > > > Am 14.12.2023 um 15:19 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > Yes, this is a really nice project, the front end as well. > > > > It reminds me a bit of FileMaker, but for the web. > > > > I am hoping you have commercial success with ApptiveGrid ! > > > >> On 12 Dec 2023, at 13:02, Norbert Hartl <norbert(a)hartl.name> wrote: > >> > >> I wanted to write this for a very long time nowâ¦so finallyâ¦Iâm very > proud to announce a new success story: ApptiveGrid > >> > >> ApptiveGrid is a SaaS tool to digitalize and automatize business > processes. > >> > >> On the one hand ApptiveGrid is visual database that enables you to > model your database via web frontend. At the same time this model is > available via REST API. > >> > >> <BildschirmÂfoto 2023-12-12 um 12.39.29.png> > >> > >> On top of the data model a form creator turns your model into a form > that you can send e.g. via email to inquire data from other peopleâ¦ > >> > >> <BildschirmÂfoto 2023-12-12 um 12.40.48.png> > >> > >> On the other hand ApptiveGrid is a workflow system where you can define > your work flow in the web frontend and connect to events. These events are > either internal (resulting from a change in your data model) or external > where you can use web hooks to kick of work flows. > >> > >> <BildschirmÂfoto 2023-12-12 um 12.44.10.png> > >> > >> With the combination of both parts ApptiveGrid is able to solve many of > modern digital workflows. It enables to make it for low cost and in almost > no time which are two pretty good reasons to use it. If you want to use it > just visit: http://www.apptivegrid.de. ApptiveGrid provides a start plan > at no cost where most of the functionalities are available. If you have > additional needs just write me. For the people in the pharo community Iâm > sure we can provide a bit more on top. > >> > >> About the tech stack: > >> > >> - The business backend of ApptiveGrid is 100% pharo > >> - It uses https://github.com/svenvc/zinc components for the HTTP > frontend > >> - and https://github.com/ApptiveGrid/Soil as the persistence solution. > >> - Each user has its own database (an empty soil database is 24kb on > disk, could be made even approx. 5kb). There are over 3100 databases in the > system right now > >> - one pharo image holds multiple soil databases open and provides > memory caching for the objects > >> - routing of requests is done with haproxy connection persistence > >> - the web frontend is made with Vue.js and a pharo library that we > transpile to JS with PharoJS > >> > >> If you are interested you can also watch my ESUG videos at > https://www.youtube.com/@esugboard. All talks in the last 2 years were > about ApptiveGrid > >> > >> If you have question, donât hesitate to ask, Iâm happy to answer! > >> > >> Norbert > >> >

Dec. 30, 2023

Re: [ANN] success story: ApptiveGrid

by Norbert Hartl

Thanks to all of you for the nice comments. I wish you, pharo and the community all the best for 2024. In 2024 there will be a soil release that I promised for this year but I didnât make it. Norbert > Am 14.12.2023 um 15:19 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > Yes, this is a really nice project, the front end as well. > > It reminds me a bit of FileMaker, but for the web. > > I am hoping you have commercial success with ApptiveGrid ! > >> On 12 Dec 2023, at 13:02, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> I wanted to write this for a very long time nowâ¦so finallyâ¦Iâm very proud to announce a new success story: ApptiveGrid >> >> ApptiveGrid is a SaaS tool to digitalize and automatize business processes. >> >> On the one hand ApptiveGrid is visual database that enables you to model your database via web frontend. At the same time this model is available via REST API. >> >> <BildschirmÂfoto 2023-12-12 um 12.39.29.png> >> >> On top of the data model a form creator turns your model into a form that you can send e.g. via email to inquire data from other peopleâ¦ >> >> <BildschirmÂfoto 2023-12-12 um 12.40.48.png> >> >> On the other hand ApptiveGrid is a workflow system where you can define your work flow in the web frontend and connect to events. These events are either internal (resulting from a change in your data model) or external where you can use web hooks to kick of work flows. >> >> <BildschirmÂfoto 2023-12-12 um 12.44.10.png> >> >> With the combination of both parts ApptiveGrid is able to solve many of modern digital workflows. It enables to make it for low cost and in almost no time which are two pretty good reasons to use it. If you want to use it just visit: http://www.apptivegrid.de. ApptiveGrid provides a start plan at no cost where most of the functionalities are available. If you have additional needs just write me. For the people in the pharo community Iâm sure we can provide a bit more on top. >> >> About the tech stack: >> >> - The business backend of ApptiveGrid is 100% pharo >> - It uses https://github.com/svenvc/zinc components for the HTTP frontend >> - and https://github.com/ApptiveGrid/Soil as the persistence solution. >> - Each user has its own database (an empty soil database is 24kb on disk, could be made even approx. 5kb). There are over 3100 databases in the system right now >> - one pharo image holds multiple soil databases open and provides memory caching for the objects >> - routing of requests is done with haproxy connection persistence >> - the web frontend is made with Vue.js and a pharo library that we transpile to JS with PharoJS >> >> If you are interested you can also watch my ESUG videos at https://www.youtube.com/@esugboard. All talks in the last 2 years were about ApptiveGrid >> >> If you have question, donât hesitate to ask, Iâm happy to answer! >> >> Norbert >>

Dec. 29, 2023