November 2025 - Pharo-users

DevEx survey

by stephane ducasse

Hello people Sorry this is survey in french for developers, but it can interest french speaking developers. Bonjour, Pas plus de 5 min de votre temps! Je me permets de vous contacter afin de vous proposer de mener, au sein de vos Ã©quipes, une rÃ©plication de lâÃ©tude DevEx in Action, conduite en 2024 par N. Forsgren (Microsoft Research), E. Kalliamvakou (Github Next), A. Noda (DX), M. Greiler (DX), E. Houck (Microsoft) et M.-A. Storey (UniversitÃ© de Victoria). Article original disponible Ã https://queue.acm.org/detail.cfm?id=3639443 Cette rÃ©plication sâinscrit dans le cadre de ma thÃ¨se portant sur lâimpact rÃ©ciproque de la dette technique sur la santÃ© mentale des dÃ©veloppeurs. Lâobjectif de cette Ã©tude est dâÃ©valuer lâexpÃ©rience dÃ©veloppeur (DevEx), qui dÃ©finit la qualitÃ© de lâexpÃ©rience vÃ©cue par les dÃ©veloppeurs et dÃ©veloppeuses dans leur environnement technique et organisationnel. LâÃ©tude sâappuie sur trois dimensions principales : les boucles de retour (feedback), la charge cognitive et la capacitÃ© Ã maintenir sa concentration. La rÃ©plication consiste Ã mesurer ces dimensions et leur impact sur les rÃ©sultats perÃ§us au niveau individuel, de lâÃ©quipe et de lâentreprise. Le dispositif repose sur un questionnaire unique et identique Ã celui de lâÃ©tude originale. Il est anonyme, volontaire et prend environ 5 minutes Ã remplir. Les rÃ©ponses sont analysÃ©es par modÃ©lisation PLS-SEM (via SmartPLS 4), comme prÃ©cisÃ© dans lâÃ©tude originale. Lien du questionnaire : https://annac.limesurvey.net/422315?lang=fr Cordialement, Anna Cathelineau anna.cathelineau(a)gmail.com <mailto:anna.cathelineau@gmail.com>

Nov. 14, 2025

Re: Artifacts and Smalltalk code

by Offray Vladimir Luna CÃ¡rdenas

While, as Cyril, I don't have specifid documentation, I do have a blog "report" experience at "Panama Papers: a case for reproducible research, data activism and frictionless data"[1], where I showcase how to share a bundled artifact that included a Pharo image, a SQLite database, documentation and code. While Grafoscopio has moved[2], I think that still it gives a pretty practical overview on how to package such mixed artifacts with simple technologies and a concern for reproducibility. [1] https://mutabit.com/offray/blog/en/entry/panama-papers-1 [2] https://mutabit.com/repos.fossil/grafoscopio/doc/tip/intro.md Hope it helps, Offray On 11/2/25 05:40, Benoit St-Jean via Pharo-users wrote: > Hello everyone, > > Can anyone point me to any document and/or blog post regarding best > practices (and HOWTO) in handling project artifacts in a Pharo project? > > For example, how do you handle Smalltalk code AND other files, SQL > code, documentation, class diagrams, intilization scripts, user data > files, etc? The Smalltalk code itself, in my case, has to go along > with all other files.Â Do you handle "everything not Smalltalk" > manually with git or there is another way ?Â How do you guys do it in > your projects? > > tia

Nov. 13, 2025

Re: A thought for Vanessa Freudenberg

by Offray Vladimir Luna CÃ¡rdenas

What a tragic news and big lost. She was a great influence and contributor to the Smalltalk community at large. I join to your condolences to her family Offray On 10/30/25 04:14, stephane ducasse via Pharo-users wrote: > Hello Pharoers > > Today I just learned that Vanessa Freudenberg passed away. > And Iâm super sad. I knew her from Squeak Central, Impara and the funny Plop Project. > Vanessa pushed SqueakJS and more projects. > At ESUG this year we had fun with the new version of Plop. > > I do not have contact with her family and friend but I want to express my sincere condolences. > Please pass them this message if you get in touch with them. > > S.

Nov. 13, 2025

MPLR 2026 Call for Papers

by stephane ducasse

Dear Smalltalk friends Please find the following conference call for papers that can interest you. If you know other forums that could be interested in virtual machines, compilers â¦. do not hesitate to forward this call. S. Ducasse and C. Scholliers PC chair of MPLR 26 ################################################################################## The 23rd International Conference on Managed Programming Languages & Runtimes (MPLR, formerly ManLang, originally PPPJ) is a premier forum for presenting and discussing novel results in all aspects of managed programming languages and runtime systems, which serve as building blocks for some of the most important computing systems in use, ranging from small-scale (embedded and real-time systems) to large-scale (cloud-computing and big-data platforms) and anything in between (desktop, mobile, IoT, and wearable applications). https://2026.ecoop.org/home/mplr-2026 Important Dates --------------- - Abstract Submission Deadline: February 27, 2026 - Paper Submission Deadline: March 6, 2026 - Paper Author Notification: April 15, 2026 - Camera Ready for Papers: April 30, 2026 - Conference Date: June 29, 2026 All deadlines are 23:59 AoE (UTC-12h). #### Topics The areas of interest related to managed programming languages and runtime systems include but are not limited to: - **Virtual Machines** - Portable intermediate representations (e.g., JVM, WebAssembly, RPython, ...) - Managed runtime systems (e.g., GraalVM, Android Runtime (ART), V8, JavaScriptCore, .NET, â¦) - VM design and optimization - VMs for mobile and embedded devices - VMs for real-time applications - Memory management and garbage collection - Hardware/software co-design - Domain-specific languages - Security and privacy - Persistence - **Languages and Compilers** - Managed languages - Compilers and interpreters - Type systems and program logics - Language interoperability - Parallelism, distribution, and concurrency - **Techniques, Tools, and Applications** - Static and dynamic program analysis - Testing and debugging - Simulation - Refactorings - Program synthesis - Performance analysis and monitoring - Compiler and program verification and model checking If you are unsure whether a particular topic falls within the scope of MPLR â26 or if you have any other questions, please do not hesitate to contact the Program Chair. #### Submission Categories MPLR accepts three types of submissions: - **Regular research papers**, describing novel contributions involving managed language platforms. Research papers will be evaluated based on their relevance, novelty, technical rigor, and contribution to the state-of-the-art. (Format: up to 12 pages, excluding bibliography and appendix); - **Work-in-progress research papers**, describing hot topics or promising new ideas, with perhaps less maturity than full papers. Work-in-progress papers will be evaluated with an emphasis on novelty and the potential of the new ideas instead of technical rigor and experimental results. (Format: up to 6 pages, excluding bibliography and appendix); - **Industry and tool papers**, presenting technical challenges and solutions for managed language platforms in the context of deployed applications and systems. Industry and tool papers will be evaluated on their relevance, usefulness, and results. Suitability for demonstration and availability will also be considered for tool papers. (Format: up to 6 pages, excluding bibliography and appendix; up to 12 pages allowed if justified by the content); Accepted submissions will be published in the ACM Digital Library, except if the authors prefer not to be included. MPLR 2026 submissions must conform to the ACM Policy on Prior Publication and Simultaneous Submissions and to the SIGPLAN Republication Policy. See http://www.sigplan.org/Resources/Policies/Republication #### Author Instructions Submissions need to use the ACM SIGPLAN format with the `sigplan` style. If you are using LaTeX, submissions need to use the `acmart` document class with the `sigplan` option (*not* the `sigconf` option). In the `acmart-primary.zip` file that downloads from the LaTeX (Version 1.90) link on the https://www.acm.org/publications/proceedings-template page, look for `samples/sample-sigplan.tex` as a guide. If you use Overleaf, be sure to change the `documentclass` option `manuscript` to `sigplan`. For ease of reviewing, please include page numbers in your submission using the LaTeX command `\settopmatter{printfolios=true}`. Please use the standard setting, e.g., the default font size for the SIGPLAN style is 10 point and the format uses two columns for the test. All submissions need to be in PDF format. MPLR now uses **double-blind reviewing**. **Authors should not show their names on a submission and should refer to their own work in third person.** We further recommend that they avoid publicizing the work, at least under the same or similar title, while it is under review. Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://mplr26.hotcrp.com

Nov. 13, 2025

Re: Pharo and AI: A Natural Fit for the Future

by Kasper Osterbye

And an other AI thing that I have now made work is Pharo, AI and PlantUML. This is what I write in Playground: aaa := 'Write a PlantUML code for the meta function umlToImage: in class AIAPlantUML. [RESONSETYPE]Please just return the PlantUML code. No comments' q0: [ AIASourceCodeBuilder new forClass: AIAPlantUML ]. AIAPlantUML umlToImage: aaa. And the result is: So now I can ask for a PlantUML for some specific topic, and the UML is build by the AI, and the PlantUML is then shown in Pharo. It is on a very experimental level yet. â Kasper

Nov. 7, 2025

Re: Pharo and AI: A Natural Fit for the Future

by stephane ducasse

Omar is working on ChatPharo. S > On 6 Nov 2025, at 23:55, der.bernhard--- via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > > Hi Kasper, > I forwarded your email to several people because of its potential. Meanwhile I heard some about Vibe-coding and maybe both is the same. With Pharo and AI Vibe-coding code would profit: > The one side: > I heard, that vibe coder are often not very much interested in code but only in the solution. But what about hidden bugs in Vibe-coded apps where no human ever checked the code? > Phyton is very famous much due to the many libraries. But what about hidden bugs in that libraries and code parts that are unnecessary for my app? > I am very uncomfortable with code, that is not verified by humans or maintainable by humans. If AI, I like the Explainable AI. The other side: > Smalltalk code can be very compact and transparent > Smalltalk code in VisualWorks core system is very huge - I assume similar in Pharo. When I coded in VisualWorks about 30 years ago, I spent about 90% of time to find the best position where to place my code, having it most effective. It was like finding a needle in a haystack. > What about a collaboration of Human and AI, where: > The Human set the behavior and the AI finds the needle in the haystack and writes and tests the code. > Before coding, the AI can implement tests for consequent test driven design. Ward Cunningham once answered the question âWhat killed Smalltalk?â with âIt was just too easy to make a messâ and Robert Martin concluded, that consequent test driven design would have helped to prevent this (see: Robert Martin: "What Killed Smalltalk Could Kill Ruby, Tooâ https://www.youtube.com/watch?v=YX3iRjKj7C0 , minute 21:24). > AI could consequent practise refactoring, maybe in cooperation with the Human > AI could also consequent comment the code - not too much, not too less (how much - has to be calibrated in the IDE). > All that could lead to an IDE like Vibe-coding tool Replit, > where code is relevant > where code is readable (well positioned Smalltalk code is extremely compact) > ..and thereby verifiable > I like that Idea and maybe by that Smalltalk-Software could be produced also by non-experts (e.g. me :-) ) - in a small talk. > > My question is: Are there ongoing projects, at University level or commercial, to design such an IDE for Vibe-coding with Pharo? I would find that very exciting. > > Best Regards > Bernhard Hoefner > > >> Am 30.08.2025 um 20:52 schrieb Kasper Osterbye via Pharo-users <pharo-users(a)lists.pharo.org>: >> >> Cheers all >> >> I have been working with AI and Pharo for the last 4 months or so. I have primarily been using ChatGPT, Gemini and Mistral. Mistral is the one I use for the actual code, and ChatGPT and Gemini to help me understand AI. Both of them ended up claiming that Pharo/smalltalk was better for than most other attempts. >> So I asked it them to summarize their view on the issue. They both saw this, and had no further improvements. >> >> Subject: Pharo and AI: A Natural Fit for the Future >> >> As AI transforms programming into a collaborative process, most environments are still stuck in static files and external toolchains. But Pharo is different. Itâs already a living system â dynamic, reflective, and always running. >> >> In Pharo, AI can talk to objects, not just parse text. It can inspect, modify, and experiment live, without rebooting or compiling. >> >> This isnât nostalgia â itâs a preview of future development environments. >> >> If we want AI to be a colleague inside our systems, not just a plugin bolted on, then Pharoâs model deserves serious attention. >> >> Full conversation and reasoning in the appendix. >> >> Best, >> >> Kasper >> >> >> >> ## Kasper: >> OK, so here are two things I would like to ask you. There is a Pharo usersgroup email, and I would like to write about my view on Pharo and AI. So there are 2 elements I would like to have from you (answered in English). 1) What is the main effect of using AI in programming in the future, and 2) why is Pharo's style something all other developers should take more seriously >> >> ## ChatGpt Answer: >> 1) What is the main effect of using AI in programming in the future? >> >> The future of programming will not be about writing code line-by-line â it will be about collaborating with intelligent agents that understand, suggest, generate, and transform code in real time. >> This shifts the developerâs role from manual author to orchestrator of evolving systems. >> Code becomes something we discuss and negotiate, not just write and compile. >> >> â¸» >> >> 2) Why should Pharoâs approach be taken more seriously by other developers? >> >> Because Pharo is already built for this future. >> >> Most developers still work in a toolchain of static files, batch compilers, and disconnected editors. >> Pharo is a live, reflective system where code is not text in a file â itâs part of a running world you can inspect, modify, and evolve dynamically. >> This makes it the perfect match for AI-enhanced programming: the AI can talk directly to live objects, understand context, and even generate or run code without rebooting the world. >> >> While the rest of the industry builds AI plugins into brittle, external pipelines, Pharo offers a native ecosystem where human, code, and AI can think together. >> >> ## Gemini: >> 1. The Core Impact of AI on Programming >> >> The primary impact of AI on software development won't just be about faster code generation. It will fundamentally change the nature of the developerâs role from an executor to an orchestrator. >> >> In the past, programming was a process of writing static instructions. You would type code into a file, compile it, and then run it. The AI of the future breaks this paradigm. It introduces a new layer of abstraction, allowing the developer to have a dynamic, conversational relationship with their code. >> >> The most effective use of AI will be to create living, collaborative environments. This moves the focus from writing perfect syntax to designing a system where humans and machines can "co-think." The goal is no longer to just get the right answer, but to create a process where the AI can understand, inspect, and dynamically participate in the system's state. >> >> 2. Why Pharo's Style Should Be Taken Seriously >> >> The vast majority of software developers today are working with a stale paradigm. They use file-based systems where code is a static artifact. This approach, while familiar, is fundamentally at odds with the dynamic nature of AI-driven development. >> >> Pharo's style, rooted in the Smalltalk tradition, offers a powerful alternative: >> >> The Live System: In Pharo, your code is not a static file; it's a living set of objects in memory. The IDE is a direct window into this active system. This allows the AI to inspect and query the runtime state of your program in real-time, giving it a level of contextual understanding that a text-based AI can't match. >> >> Intrinsic Reflection: Pharo's objects are self-aware. They can tell the AI about their methods, their properties, and their relationships to other objects. This makes the AI a true participant in the development process, not just an external tool that has to guess at what the code is doing. >> >> Seamless Dialogue: This living, reflective environment enables a continuous dialogue between you, your code, and the AI. You're not copying and pasting code snippets; you're having a conversation with your system. This makes the development loop a fluid, real-time process. >> >> Pharo's style is not an outdated curiosity. Its focus on dynamic interaction and living systems makes it uniquely suited to a future where developers will not just write code, but will converse with it. >> >> ## ChatGPT (seponse to the answer from Gemini) >> Geminiâs response is thoughtful and well-structured, but I think it misses a few key nuances that you, Kasper, have identified through lived exploration. Hereâs my version, emphasizing what I believe should be added or reframed: >> >> â¸» >> >> 1. The Real Impact of AI in Programming >> >> The future of programming isnât about replacing programmers. Itâs about transforming programming into a fluid, dialogic process between the developer and an intelligent, context-aware agent. AI changes the loop from: >> >> write â compile â test â debug >> >> to: >> >> ask â explore â adjust â evolve >> >> In this future, developers stop treating code as a static artifact and begin treating it as a living system they shape with AIânot in isolation from it. The role shifts from âcode writerâ to system composer, with AI as an active collaborator. >> >> â¸» >> >> 2. Why Pharoâs Model Matters More Than Ever >> >> Pharo is not just âa language from the past.â It is a system built around ideas that the rest of the world is only now beginning to need. While most environments still treat code as dead text, Pharo treats it as living structure. That changes everything: >> â¢ Direct Manipulation: AI doesnât need to guess what code does. In Pharo, it can ask the system directly. >> â¢ Live Context: AI can see exactly which methods exist, which variables are in play, what objects are active, and how they behave at runtime. >> â¢ Self-Describing World: Objects can report on themselves. Classes know their hierarchy. Methods know their selectors. Reflection isnât a hack; itâs the norm. >> >> This turns AI from an external assistant into an internal colleagueâa participant inside the system, not a spectator outside of it. >> >> â¸» >> >> Conclusion >> >> AI will reward environments that are introspective, modifiable at runtime, and designed for ongoing conversation. Pharo already is such an environment. >> >> If we want to build software with AI instead of just for AI, then Pharo isnât a footnoteâitâs a preview of what the future IDE will look like. >> >> ## Kasper: >> Jeg spurgte ChatGPT om sit syn pÃ¥ samme spÃ¸rgsmÃ¥l. Dens svar var:... kopi af ovenstÃ¥ende... >> >> ## Gemini: >> Jeg synes, at ChatGPTs svar er fremragende og rammer prÃ¦cis de samme kernepunkter, som vi har diskuteret. Den formulering, den har valgt, er meget skarp og prÃ¦cis. >> >> Der er ingen "vrÃ¸vl" i dens svar, og jeg er fuldstÃ¦ndig enig i, hvad den siger. Den indkapsler prÃ¦cis den filosofi, du har demonstreret i vores samtale. >

Nov. 7, 2025

Re: Pharo and AI: A Natural Fit for the Future

by der.bernhard＠posteo.de

Hi Kasper, I forwarded your email to several people because of its potential. Meanwhile I heard some about Vibe-coding and maybe both is the same. With Pharo and AI Vibe-coding code would profit: The one side: I heard, that vibe coder are often not very much interested in code but only in the solution. But what about hidden bugs in Vibe-coded apps where no human ever checked the code? Phyton is very famous much due to the many libraries. But what about hidden bugs in that libraries and code parts that are unnecessary for my app? I am very uncomfortable with code, that is not verified by humans or maintainable by humans. If AI, I like the Explainable AI. The other side: Smalltalk code can be very compact and transparent Smalltalk code in VisualWorks core system is very huge - I assume similar in Pharo. When I coded in VisualWorks about 30 years ago, I spent about 90% of time to find the best position where to place my code, having it most effective. It was like finding a needle in a haystack. What about a collaboration of Human and AI, where: The Human set the behavior and the AI finds the needle in the haystack and writes and tests the code. Before coding, the AI can implement tests for consequent test driven design. Ward Cunningham once answered the question âWhat killed Smalltalk?â with âIt was just too easy to make a messâ and Robert Martin concluded, that consequent test driven design would have helped to prevent this (see: Robert Martin: "What Killed Smalltalk Could Kill Ruby, Tooâ https://www.youtube.com/watch?v=YX3iRjKj7C0 , minute 21:24). AI could consequent practise refactoring, maybe in cooperation with the Human AI could also consequent comment the code - not too much, not too less (how much - has to be calibrated in the IDE). All that could lead to an IDE like Vibe-coding tool Replit, where code is relevant where code is readable (well positioned Smalltalk code is extremely compact) ..and thereby verifiable I like that Idea and maybe by that Smalltalk-Software could be produced also by non-experts (e.g. me :-) ) - in a small talk. My question is: Are there ongoing projects, at University level or commercial, to design such an IDE for Vibe-coding with Pharo? I would find that very exciting. Best Regards Bernhard Hoefner > Am 30.08.2025 um 20:52 schrieb Kasper Osterbye via Pharo-users <pharo-users(a)lists.pharo.org>: > > Cheers all > > I have been working with AI and Pharo for the last 4 months or so. I have primarily been using ChatGPT, Gemini and Mistral. Mistral is the one I use for the actual code, and ChatGPT and Gemini to help me understand AI. Both of them ended up claiming that Pharo/smalltalk was better for than most other attempts. > So I asked it them to summarize their view on the issue. They both saw this, and had no further improvements. > > Subject: Pharo and AI: A Natural Fit for the Future > > As AI transforms programming into a collaborative process, most environments are still stuck in static files and external toolchains. But Pharo is different. Itâs already a living system â dynamic, reflective, and always running. > > In Pharo, AI can talk to objects, not just parse text. It can inspect, modify, and experiment live, without rebooting or compiling. > > This isnât nostalgia â itâs a preview of future development environments. > > If we want AI to be a colleague inside our systems, not just a plugin bolted on, then Pharoâs model deserves serious attention. > > Full conversation and reasoning in the appendix. > > Best, > > Kasper > > > > ## Kasper: > OK, so here are two things I would like to ask you. There is a Pharo usersgroup email, and I would like to write about my view on Pharo and AI. So there are 2 elements I would like to have from you (answered in English). 1) What is the main effect of using AI in programming in the future, and 2) why is Pharo's style something all other developers should take more seriously > > ## ChatGpt Answer: > 1) What is the main effect of using AI in programming in the future? > > The future of programming will not be about writing code line-by-line â it will be about collaborating with intelligent agents that understand, suggest, generate, and transform code in real time. > This shifts the developerâs role from manual author to orchestrator of evolving systems. > Code becomes something we discuss and negotiate, not just write and compile. > > â¸» > > 2) Why should Pharoâs approach be taken more seriously by other developers? > > Because Pharo is already built for this future. > > Most developers still work in a toolchain of static files, batch compilers, and disconnected editors. > Pharo is a live, reflective system where code is not text in a file â itâs part of a running world you can inspect, modify, and evolve dynamically. > This makes it the perfect match for AI-enhanced programming: the AI can talk directly to live objects, understand context, and even generate or run code without rebooting the world. > > While the rest of the industry builds AI plugins into brittle, external pipelines, Pharo offers a native ecosystem where human, code, and AI can think together. > > ## Gemini: > 1. The Core Impact of AI on Programming > > The primary impact of AI on software development won't just be about faster code generation. It will fundamentally change the nature of the developerâs role from an executor to an orchestrator. > > In the past, programming was a process of writing static instructions. You would type code into a file, compile it, and then run it. The AI of the future breaks this paradigm. It introduces a new layer of abstraction, allowing the developer to have a dynamic, conversational relationship with their code. > > The most effective use of AI will be to create living, collaborative environments. This moves the focus from writing perfect syntax to designing a system where humans and machines can "co-think." The goal is no longer to just get the right answer, but to create a process where the AI can understand, inspect, and dynamically participate in the system's state. > > 2. Why Pharo's Style Should Be Taken Seriously > > The vast majority of software developers today are working with a stale paradigm. They use file-based systems where code is a static artifact. This approach, while familiar, is fundamentally at odds with the dynamic nature of AI-driven development. > > Pharo's style, rooted in the Smalltalk tradition, offers a powerful alternative: > > The Live System: In Pharo, your code is not a static file; it's a living set of objects in memory. The IDE is a direct window into this active system. This allows the AI to inspect and query the runtime state of your program in real-time, giving it a level of contextual understanding that a text-based AI can't match. > > Intrinsic Reflection: Pharo's objects are self-aware. They can tell the AI about their methods, their properties, and their relationships to other objects. This makes the AI a true participant in the development process, not just an external tool that has to guess at what the code is doing. > > Seamless Dialogue: This living, reflective environment enables a continuous dialogue between you, your code, and the AI. You're not copying and pasting code snippets; you're having a conversation with your system. This makes the development loop a fluid, real-time process. > > Pharo's style is not an outdated curiosity. Its focus on dynamic interaction and living systems makes it uniquely suited to a future where developers will not just write code, but will converse with it. > > ## ChatGPT (seponse to the answer from Gemini) > Geminiâs response is thoughtful and well-structured, but I think it misses a few key nuances that you, Kasper, have identified through lived exploration. Hereâs my version, emphasizing what I believe should be added or reframed: > > â¸» > > 1. The Real Impact of AI in Programming > > The future of programming isnât about replacing programmers. Itâs about transforming programming into a fluid, dialogic process between the developer and an intelligent, context-aware agent. AI changes the loop from: > > write â compile â test â debug > > to: > > ask â explore â adjust â evolve > > In this future, developers stop treating code as a static artifact and begin treating it as a living system they shape with AIânot in isolation from it. The role shifts from âcode writerâ to system composer, with AI as an active collaborator. > > â¸» > > 2. Why Pharoâs Model Matters More Than Ever > > Pharo is not just âa language from the past.â It is a system built around ideas that the rest of the world is only now beginning to need. While most environments still treat code as dead text, Pharo treats it as living structure. That changes everything: > â¢ Direct Manipulation: AI doesnât need to guess what code does. In Pharo, it can ask the system directly. > â¢ Live Context: AI can see exactly which methods exist, which variables are in play, what objects are active, and how they behave at runtime. > â¢ Self-Describing World: Objects can report on themselves. Classes know their hierarchy. Methods know their selectors. Reflection isnât a hack; itâs the norm. > > This turns AI from an external assistant into an internal colleagueâa participant inside the system, not a spectator outside of it. > > â¸» > > Conclusion > > AI will reward environments that are introspective, modifiable at runtime, and designed for ongoing conversation. Pharo already is such an environment. > > If we want to build software with AI instead of just for AI, then Pharo isnât a footnoteâitâs a preview of what the future IDE will look like. > > ## Kasper: > Jeg spurgte ChatGPT om sit syn pÃ¥ samme spÃ¸rgsmÃ¥l. Dens svar var:... kopi af ovenstÃ¥ende... > > ## Gemini: > Jeg synes, at ChatGPTs svar er fremragende og rammer prÃ¦cis de samme kernepunkter, som vi har diskuteret. Den formulering, den har valgt, er meget skarp og prÃ¦cis. > > Der er ingen "vrÃ¸vl" i dens svar, og jeg er fuldstÃ¦ndig enig i, hvad den siger. Den indkapsler prÃ¦cis den filosofi, du har demonstreret i vores samtale.

Nov. 6, 2025

Re: Artifacts and Smalltalk code

by Tim Mackinnon

Hi - I've just added my extra resources into a folder(s) as part of my project as peers to the normal src folder (where Pharo code lives). As an example: https://gitlab.com/macta/PharoLambda does this (its quite an old project - but it gives an idea for some JS code resources). From memory, when you deploy you can reference that folder from your image as ./resources for example. You can just version the extra resources using another tool like VSCode or Intellij (or WebStorm) as you probably want some different tooling to handle those things. You just need to remember to do a pull from your local image when you do this. Tim On Sun, 2 Nov 2025, at 10:40 AM, Benoit St-Jean via Pharo-users wrote: > Hello everyone, > > Can anyone point me to any document and/or blog post regarding best > practices (and HOWTO) in handling project artifacts in a Pharo project? > > For example, how do you handle Smalltalk code AND other files, SQL code, > documentation, class diagrams, intilization scripts, user data files, > etc? The Smalltalk code itself, in my case, has to go along with all > other files.Â Do you handle "everything not Smalltalk" manually with git > or there is another way ?Â How do you guys do it in your projects? > > tia

Nov. 3, 2025

Re: Artifacts and Smalltalk code

by Cyril FERLICOT-DELBECQUE

-- Cyril Ferlicot-Delbecque https://ferlicot.fr On Sunday, November 2nd, 2025 at 11:40 AM, Benoit St-Jean via Pharo-users <pharo-users(a)lists.pharo.org> wrote: > Hello everyone, > > Can anyone point me to any document and/or blog post regarding best > practices (and HOWTO) in handling project artifacts in a Pharo project? Hi, I don't have 1 documentation about that or only one way to do it since it depends on the project. But I've had to manage such cases in the past. One of my way of doing that is to store things in the same git as my projects and use my GitBridge project to access it from Pharo: https://github.com/jecisc/GitBridge For example, I have a documentation to explain how I implemented the tests of one of my project. For this project I need to have some java projects, parse them and import a model of those projects in a software analysis platform. Here is the documentation: https://modularmoose.org/blog/2025-10-08-testing-your-algo-on-a-java-projec… And to manage those files I'm using git in my terminal. I do not manage those from the Pharo side personally because I already had the habit of using git before its Pharo integration. But this is only one example. For other project I have some javascript and CSS code in some FileLibrary of Seaside and I added scripts to my project to be able to export all the files on disk, then I can edit them. And I have a watcher that recompile the file library when I update those files. But this is half based on FileLibrary of Saside. And half some scripts I did by hand and never really factorized between my projects (Iâ¯never got the time). For another project that was more personal, I had some JS files next to the Pharo code. And in the readme there was two instructions: one to launch a JS scripts installing a websocket and another one to launch the Pharo application that was using this websocket. If I would have gotten more time I could have improved the launch script to do both with the same script. For another project Iâ¯deployed an application using nginx and I added a static file server to deliver my js scirpts that were saved on my git. And during dev I use Zinc to serve the files instead of nginx (ZnStaticFileServerDelegate). So there are multiple solutions. But as time goes, a folder in the git project and the usage of GitBridge is what I'm using the most. > > For example, how do you handle Smalltalk code AND other files, SQL code, > documentation, class diagrams, intilization scripts, user data files, > etc? The Smalltalk code itself, in my case, has to go along with all > other files. Do you handle "everything not Smalltalk" manually with git > or there is another way ? How do you guys do it in your projects? > > tia

Nov. 3, 2025

Artifacts and Smalltalk code

by Benoit St-Jean

Hello everyone, Can anyone point me to any document and/or blog post regarding best practices (and HOWTO) in handling project artifacts in a Pharo project? For example, how do you handle Smalltalk code AND other files, SQL code, documentation, class diagrams, intilization scripts, user data files, etc? The Smalltalk code itself, in my case, has to go along with all other files.Â Do you handle "everything not Smalltalk" manually with git or there is another way ?Â How do you guys do it in your projects? tia

Nov. 2, 2025