- Pharo-vm - lists.pharo.org

VM Release 10.0.6 on the pipe

by Guillermo Polito

Hi all, This email is to tell you that there is a new VM release on the CI pipe, with many fixes and improvements. This release will be available for versions of Pharo 11 and above. Improvements in build environment * Update build environment for Pharo 10 vm branch by @guillep in https://github.com/pharo-project/pharo-vm/pull/594 * Make tests run in parallel by @guillep in https://github.com/pharo-project/pharo-vm/pull/596 * Update Jenkins to use Pharo 110 for building by @PalumboN in https://github.com/pharo-project/pharo-vm/pull/661 Cleanups * Cleanups/externalize internalize by @guillep in https://github.com/pharo-project/pharo-vm/pull/583 * Fix/warnings by @guillep in https://github.com/pharo-project/pharo-vm/pull/584 * fixing-categorization in P10 by @tesonep in https://github.com/pharo-project/pharo-vm/pull/625 Fixes * Fix mnuMethodOrNilFor: for method wrappers by @guillep in https://github.com/pharo-project/pharo-vm/pull/578 * fix function signatures by @pavel-krivanek in https://github.com/pharo-project/pharo-vm/pull/582 Debugging improvements * Gdbinit file and helpers v2 by @guillep in https://github.com/pharo-project/pharo-vm/pull/486 * VM Debugger improvement with IR by @QDucasse in https://github.com/pharo-project/pharo-vm/pull/342 VM Improvements * improving-permSpace by @tesonep in https://github.com/pharo-project/pharo-vm/pull/614 * Changing the order of command-line processing and PList in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/609 * Adding parsing of image parameters from PList by @tesonep in https://github.com/pharo-project/pharo-vm/pull/636 * Change terminate handler to exit with 128+signal by @jvalteren in https://github.com/pharo-project/pharo-vm/pull/644 * Improvements in parameters handling in OSX by @tesonep in https://github.com/pharo-project/pharo-vm/pull/639 * Adding check to fix when the image is open with an older VM by @tesonep in https://github.com/pharo-project/pharo-vm/pull/642 * Fix/ephemeron list by @guillep in https://github.com/pharo-project/pharo-vm/pull/668 New Contributors * @jvalteren made their first contribution in https://github.com/pharo-project/pharo-vm/pull/644 **Full Changelog**: https://github.com/pharo-project/pharo-vm/compare/v10.0.5...v10.0.6 <https://github.com/pharo-project/pharo-vm/compare/v10.0.5...v10.0.6> Cheers, Guille et al

Aug. 9, 2023

[Looking for Participants] Experiment on Reflection

by Guillermo Polito

Hello everyone, Iona Thomas is running an experiment on the usage of reflection, studying the usage of reflection by different libraries in Pharo. Our ultimate objective is to understand how to (re)design the reflective layer of Pharo. We are looking for participants for an experiment. The experiment is open to anyone as it is intended to have different levels of experience with Pharo - Duration : ~1h30. - When? During April (see link below). - Where? We will have a set of presential sessions for those that be in Lille, and we are also organising remote sessions. It will help us a lot to organize if you can select possible dates so we can organise the experiment: https://framadate.org/wMiDsJkoHt64ECh8 Please, use your public email as name so we can contact you back. We hope you will help us change the reflective world! Best regards, Iona et al

March 30, 2023

Ephemerons in P11

by Guillermo Polito

Hi all, For those that may not be following the day-to-day development, you may be interested in that Ephemeron support is now enabled in Pharo 11 for one week or so (VM version 10.0.0, Image build 627). Here are some takeaways and actions to take you may be interested in: To get the latest version: - ZeroConf works out of the box - You must update your VMs in the pharo launcher About compatibility: - old images will run on both the old and latest VMs - new images will only run on the latest VM You can read more on: https://github.com/pharo-project/pheps/blob/main/phep-0003.md Cheers, Guille

March 20, 2023

pharo-vm-builder

by Guillermo Polito

> El 15 mar. 2023, a las 02:09, HernÃ¡n Morales <hernan-federico.morales(a)inria.fr> escribiÃ³: > > > > De: "Guille Polito" <guillermo.polito(a)inria.fr> > I wonder: > > - how this can get to the mainstream VM > => the graphviz cmake file is nice :) > > I just add a target to the CMakeLists.txt which you can check here (not PR yet): > > https://github.com/pharo-project/pharo-vm/compare/pharo-10...hernanmd:pharo… > > the idea is to configure normally and then launch the install with the target "graphviz" > > cmake --build build --target graphviz Cool! :D Iâm eager to see the PR! Did you check that cmake already has some graphviz support? I did $ cmake âhelp and I saw there is already a âgraphviz option â¦ --graphviz=[file] = Generate graphviz of dependencies, see CMakeGraphVizOptions.cmake for more. â¦ Is there a difference? > > - how can we make the VM configuration step closer to your report > => when we do `cmake -B dir -S source` cmake does a configure step, where it looks for compile time and runtime dependencies, and it prints that to the stdout. We should be able to enhance it to have what you have in the report. > > Another question is maybe to review the defaults of the current configuration? > > Today I checked a bit the CMakeLists.txt and what would be nice is to split (or organize) the file because it's a bit of a bed sheet? Yes, the reality is that we learnt a lot about CMake ***while*** making the CMake configuration of the VM. It was difficult at the beginning because the nice documentation about CMake is a bit scarce. So there are parts that are a bit rough and could be enhanced a lot. Now we know a lot more, but our time is somewhere else... Iâd suggest starting with concrete and small steps. Do some small PRs, they will pass easily :) If you want we can do a fast call and do a code review and identify concrete things to do in this direction! Some ideas are around - using toolchain files, - removing manual compiler options, let CMake do itâs thing - check how to simplify the cygwin builds (that need path conversionsâ¦) - dependency checks could also be done separately - split the compilation of ffi support - then also how plugins are build could be enhanced by a lot using what I drafted for the plugin compilation > > For example, right now the VM build assumes that if youâre in *nix, you will apt-get your libs yourself. > However: > - that does not always work > - Pharo does not nicely report when a lib is missing/not found, so this makes people think âThe VM does not work!" > > I wonder what would be a better default configuration. > > I wonder myself how do you discover the default configuration? It really depends on what you mean by configuration! One way is to look at the CMakeLists.txt. In the first ~30/40 lines we have all options listed. A quick google search tells that doing: cmake -LAH -S source or cmake -LAH buildDirectory prints all options with their default values and description. So it seems itâs just a matter of doing a proper cmake configuration :) > > > Cheers, > > HernÃ¡n > > > El 20 ene. 2023, a las 19:05, HernÃ¡n Morales <hernan-federico.morales(a)inria.fr <mailto:hernan-federico.morales@inria.fr>> escribiÃ³: > > Hi. > > I did a small package to ease VM compilation. Currently it generates: > > - A timestamped build directory for each usage. > - A GraphViz with the Pharo VM dependency graph. > - A compiler commands file (compile_commands.json) to help clangd find include paths in vscode (for this I'm experimenting a bit to see what automated/static checks could bring to the table). > - A timestamped report file with lot of build information for example: > - if we are in docker > - ulimit > - openssl, curl, wgetm git, etc versions > - complete the tree of the build > > The repo: https://github.com/hernanmd/pharo-vm-builder <https://github.com/hernanmd/pharo-vm-builder> > > To use it: > > git clone https://github.com/hernanmd/pharo-vm-builder <https://github.com/hernanmd/pharo-vm-builder> > cd pharo-vm-builder > git clone https://github.com/pharo-project/pharo-vm.git <https://github.com/pharo-project/pharo-vm.git> > ./pharo-vm-builder.sh > > Let me know any other suggestions, > > Cheers, > > HernÃ¡n > > >

March 15, 2023

Polyphemus VMIL talk

by Pierre Misse-Chanabier

Hello, I'm quite proud to provide my presentation for the VMIL talk I did on Polyphemus https://www.youtube.com/watch?v=-phxX8ia630. Hope this may be of interest to some of you ! Feel free to ping me for questions :) Cheers ! On 16/08/2022 10:36, pmissech wrote: > Hello, > > Although i will not be able to attend ESUG'22, a friend agreed to > present one of our projects to the innovation award. > **Polyphemus** is aÂ VM related, but public aims at any kind of > developers. > Particularly, the video submission talks about how to look at an image > and how to **recover** dead images. > Feel free to contact me if you have any questions ! > Enjoy (and vote for Polyphemus!). > > 5 minutes video, Innovation Technology Award submission: > https://youtu.be/zf3cCtNW830 > Repository: github.com/hogoww/Polyphemus/ > Additionnal information on image recovery: > https://github.com/hogoww/Polyphemus/blob/main/Documentation/ResurrectingDe… > > Cheers !

Dec. 27, 2022

Re: [Pharo-dev] Pharo VM Release - v9.0.21

by Guillermo Polito

Thanks Pablo!!! > El 12 dic. 2022, a las 14:30, tesonep(a)gmail.com escribiÃ³: > > Hello, > I have released a new version of the Pharo VM for Pharo 9, Pharo 10 and Pharo 11. This VM is accessible right now from Zero-Conf, updating it in the Pharo Launcher or using the usual downloads (as described in pharo.org/download <http://pharo.org/download>). > > This version includes a series of bug fixes and upgrades on the third-party libraries. > > Changelog: > > - Implementing High resolution clock for ARM64 (Used during profiling) > - Updating third party libraries for all the graphic layer. > - Fixing a performance regression on the allocation of opcodes and fix-ups. > Cleaning only the ones that are going to be used. > Like this, this version has the same speed than before when allocating in the stack. > - Correctly handling the encoding of the command line arguments of the VM (Windows) > - Allocating the opcodes and fixup structs only once and reusing them (Reducing risk of C Stack Overflow) > > Thanks a lot, and any doubt please let me know. > Cheers, > > Pablo on behalf of the whole Pharo team. > > -- > Pablo Tesone. > tesonep(a)gmail.com <mailto:tesonep@gmail.com>

Dec. 12, 2022

Looking for an engineer position to work on Virtual Machines

by Pierre Misse-Chanabier

Hello, My name is Pierre Misse-Chanabier. I'm finishing my PhD in the RMOD team on testing Virtual Machines in about two months. I am therefore looking for a Job, hopefully in the Pharo community ! Ideally, I'm looking to work in the domains of Virtual Machines or Language Tooling, or Meta-programing, but I'm open to other opportunities. See my CV attached. I have to stay in Lille for at least the next year, therefore, I am looking to work remotely. Here are my most important projects and publications about them: Illicium : a framework to generate C code from Pharo code. Github repository: [ https://github.com/hogoww/Illicium | https://github.com/hogoww/Illicium ] IWST'19 Illicium: A modular transpilation toolchain from Pharo to C [ https://hal.archives-ouvertes.fr/hal-02297860/ | https://hal.archives-ouvertes.fr/hal-02297860/ ] version poster SAC'22 & full ICSR'22: Differential testing of simulation-based VM generators: automatic detection of VM generator semantic gaps between simulation and generated VMs [ https://link.springer.com/chapter/10.1007/978-3-031-08129-3_7 | https://link.springer.com/chapter/10.1007/978-3-031-08129-3_7 ] [ https://dl.acm.org/doi/abs/10.1145/3477314.3507171 | https://dl.acm.org/doi/abs/10.1145/3477314.3507171 ] Polyphemus: Retro engineering of the Pharo Image, and ease of VM tooling Github Repository: [ https://github.com/hogoww/Polyphemus/ | https://github.com/hogoww/Polyphemus/ ] Video Presentation for Esug Innovation award (I was unable to present it myself): [ https://www.youtube.com/watch?v=zf3cCtNW830 | https://www.youtube.com/watch?v=zf3cCtNW830 ] VMIL'22: Ease VM Level Tooling with Language Level Ordinary Object Pointers [ https://hal.inria.fr/hal-03827632 | https://hal.inria.fr/hal-03827632 ] (preprint) I am particularly interested in my latest work: Polyphemus. I have also worked on many part of the Pharo ecosystem. The Pharo VM, The Pharo bootstrap, Calypso, Debugger, selector extraction, Iceberg scripting, SUnit ... Let me know if you have openings or questions ! Pierre

Oct. 25, 2022

Re: Cleaning stale branches

by Guille Polito

Thanks Luc! We have done some cleaning there, I hope thatâs better now. G > El 5 oct 2022, a las 15:50, Luc Fabresse <luc.fabresse(a)imt-nord-europe.fr> escribiÃ³: > > Hello, > > Propositions: > > - PharoX = should be the default branch (dev branch) > - Pharo9 = the current stable branch > - Cog -> I would keep cog because Pharo-0 is misleading ; it looks like that it is the VM for Pharo Image v 0 :-) > - pharo -> yes remove it > - dev-7 -> cog-pharo7 ? > - headless -> feat/headless ? to me, it is a feature branch that started on top of cog > > Luc > > Le mer. 5 oct. 2022 Ã 10:37, Guille Polito <guillermo.polito(a)inria.fr <mailto:guillermo.polito@inria.fr>> a Ã©crit : > We have a couple of stale branches, named a bit chaotically, Iâd like to rename them in a good way, but I donât remember what they are about :) > The numbers below (behind | ahead) are according to the current stable pharo9 branch. > > <GrÃ¡fico_pegado-3.png> > > <GrÃ¡fico_pegado-4.png> > > - headless has already the new tree organisation with cmake > - dev-7 and pharo branches have the old tree organisation, dev-7 has some bugfixes when comparing to `pharo` > - Cog has the original imported version from monticello > > Maybe we can have some naming convention for branches? > > - pharo-[version] to denote major development version branches > - feat/[feature] for feature branches if needed > > Then the four above should be renamed accordingly. Something on the lines of... > > - Cog -> rename as pharo-0? > - pharo -> can be removed > - dev-7 -> pharo-1 > - headless -> pharo-2 > > ? > > G > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org <mailto:pharo-vm@lists.pharo.org> > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org <mailto:pharo-vm-leave@lists.pharo.org> > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Oct. 5, 2022

Re: Making pharoX the default branch

by Guille Polito

Thanks for the input! This is now done! > El 5 oct 2022, a las 15:21, Luc Fabresse <luc.fabresse(a)imt-nord-europe.fr> escribiÃ³: > > > +1 > > --+- (default) dev - Pharo X (nowadays) ---> > | |--- feature || PR ---> # will be merged in default > |--- releases ---> > > BTW: I wanted to do a pass on the wiki pages of the VM repo but I think I need rights for that. do you confirm? > > Cheers, > Luc > > Le mer. 5 oct. 2022 Ã 10:58, tesonep(a)gmail.com <mailto:tesonep@gmail.com> <tesonep(a)gmail.com <mailto:tesonep@gmail.com>> a Ã©crit : > I think is a good idea, go ahead > > On Wed, Oct 5, 2022, 10:20 Guille Polito <guillermo.polito(a)inria.fr <mailto:guillermo.polito@inria.fr>> wrote: > Hi all, > > We were thinking here with Jean Privat that we could make the pharoX branch (the dev branch) the default branch in the repository. > Itâs just a convenience for dev. > Thoughts? > > What should we add in the readme to make sure people do not make mistakes? > - say that stable versions are in releases? > - say the default branch is always dev? > > cheers, > G & J > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org <mailto:pharo-vm@lists.pharo.org> > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org <mailto:pharo-vm-leave@lists.pharo.org> > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org <mailto:pharo-vm@lists.pharo.org> > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org <mailto:pharo-vm-leave@lists.pharo.org> > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org

Oct. 5, 2022

Re: Cleaning stale branches

by Luc Fabresse

Hello, Propositions: - PharoX = should be the default branch (dev branch) - Pharo9 = the current stable branch - Cog -> I would keep cog because Pharo-0 is misleading ; it looks like that it is the VM for Pharo Image v 0 :-) - pharo -> yes remove it - dev-7 -> cog-pharo7 ? - headless -> feat/headless ? to me, it is a feature branch that started on top of cog Luc Le mer. 5 oct. 2022 Ã 10:37, Guille Polito <guillermo.polito(a)inria.fr> a Ã©crit : > We have a couple of stale branches, named a bit chaotically, Iâd like to > rename them in a good way, but I donât remember what they are about :) > The numbers below (behind | ahead) are according to the current stable > pharo9 branch. > > > > - headless has already the new tree organisation with cmake > - dev-7 and pharo branches have the old tree organisation, dev-7 has some > bugfixes when comparing to `pharo` > - Cog has the original imported version from monticello > > Maybe we can have some naming convention for branches? > > - pharo-[version] to denote major development version branches > - feat/[feature] for feature branches if needed > > Then the four above should be renamed accordingly. Something on the lines > of... > > - Cog -> rename as pharo-0? > - pharo -> can be removed > - dev-7 -> pharo-1 > - headless -> pharo-2 > > ? > > G > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org >

Oct. 5, 2022