August 2024 - Pharo-dev - lists.pharo.org

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

by Marcus Denker

# This week (31/2024) on the Pharo Issue Tracker We will send the reports for the last weeks this week, this one is for week 31 (the week startig 26 July) # Features - Adding "OnStack replacement" feature to Reflectivity #16919 https://github.com/pharo-project/pharo/pull/16919 - Inspection tab for inspecting selectors of a Context #812 https://github.com/pharo-spec/NewTools/pull/812 - Adding command to add breakpoints in the debugger #807 https://github.com/pharo-spec/NewTools/pull/807 - Remember debugger size and position #795 https://github.com/pharo-spec/NewTools/pull/795 # Fixes - Use withAdapterDo: to set the scrolling height, courtesy of @jecisc #1579 https://github.com/pharo-spec/Spec/pull/1579 - Fix scrollTo: on SpScrollableLayout not working #1370 https://github.com/pharo-spec/Spec/pull/1370 - Fix for SettingsBrowser shows rule class and not rule text #16962 https://github.com/pharo-project/pharo/pull/16962 - 16923-ReferenceFinder-should-not-look-at-ephemeron-references #16955 https://github.com/pharo-project/pharo/pull/16955 - Avoid analyzing classes in Manifest methods while checking ReClassesHaveNoReferencesCondition #16954 https://github.com/pharo-project/pharo/pull/16954 - Provide error information directly when class definition loading fails #16898 https://github.com/pharo-project/pharo/pull/16898 - Fix keyboard focus of rename method refactoring window #16835 https://github.com/pharo-project/pharo/pull/16835 - Speed up refactoring tests by constricting refactoring models #16807 https://github.com/pharo-project/pharo/pull/16807 - Fix calypso browsing of Ring models #16802 https://github.com/pharo-project/pharo/pull/16802 - Fix Duplicate class command UX issues #16967 https://github.com/pharo-project/pharo/pull/16967 - Fix clean blocks serialization #16235 https://github.com/pharo-project/pharo/pull/16235 # Comments / Documentation - A small fix in a FileReference method comment, as suggested by @Ducasse #16966 https://github.com/pharo-project/pharo/pull/16966 - Update GitHub issue templates #16959 https://github.com/pharo-project/pharo/pull/16959 # Cleanup - Cleaning up FFI usage of SDL2 #16798 https://github.com/pharo-project/pharo/pull/16798 - Remove dead code in Monticello #16961 https://github.com/pharo-project/pharo/pull/16961 - Remove MCTool #16952 https://github.com/pharo-project/pharo/pull/16952 - Remove unused author #1833 https://github.com/pharo-vcs/iceberg/pull/1833

Aug. 26, 2024

Metacello Dependency Version Best Practice

by sean＠clipperadams.com

I recently experienced some CI problems for several of my projects because of an (IMO unnecessarily tight) version specification of XML-XPATHâs dependency on XMLParser: \`github://pharo-contributions/XML-XMLParser:v3.6.x/src\`. At minimum, it seems the dependency should be on the major version (e.g. v3), not the minor (unless Iâm missing a needed feature that was added in 3.6). More importantly though, it raises questions about what the best practice is here. In summary, it seems to me that in general itâs better to only pin versions in reaction to CI failures because pinning has significant downsides and uncertainties. Defensive pinning smells like premature optimization IMO. In more detail, partially pinning (to major or minor version)Â *by default* doesn't seem right to me for several reasons unless we're talking about a tagged release that should be reproducible because: * We have limited community resources to manage these pinnings, which create cascading conflict problems with all other dependent projects. * Pinnings seem somewhat arbitrary because oftenÂ communityÂ maintainers are not familiar enough with both projects or have enough time to do a thorough investigation. How does the maintainer know whether a particular dependency version really âworksâ with the project? Unless they are intimately familiar with both projects (and even then I wouldnât have confidence in a manual review), the best way I can think of is to rely on passing CI, and in that caseâ¦ * It seems easier to just react to CI failures; defensive pinning smells like premature optimization IMO * Partial pinning (minor or major version) will not lead to reproducible builds because the patch is floating * What does reproducibility even mean from an untagged baseline? Looking through a bunch of repos, it doesnât seem that there is consensus either way. Some specify baselines and some specific versions. p.s. for tracking the major, I like ba-stâs naming convention of v{integer} instead of adding â.xââs of unclear value

Aug. 4, 2024

Re: EU Citizen Initiative for consumers to have access to apps they purchased

by James Foster

How would this impact software that is licensed on a subscription basis? What if some functionality in the application requires a server component. Is the vendor required to provide that server component forever? Or is the vendor prohibited from building applications that have a server component? I have a deep suspicion of government regulation of business arrangements like this. James > On Aug 3, 2024, at 5:47â¯AM, David Mason <dmason(a)torontomu.ca> wrote: > > There is currently a citizen initiative to get a law in place that makers of software must not make the software become unusable after they end support. > > While this is directly about games, it has implications for things like cars, tractors, medical devices, and anything that has a significant software component. > > I encourage my EU friends and colleagues to consider signing and explaining to their friends why it's important for them to sign even if they don't play games. > > Here's a video that explains it: https://www.youtube.com/watch?v=mkMe9MxxZiI > > Here's tha petition: https://www.stopkillinggames.com/ > > Sorry this is a bit off-topic, but I think it's important to the entire software industry. > > ../Dave

Aug. 3, 2024

EU Citizen Initiative for consumers to have access to apps they purchased

by David Mason

There is currently a citizen initiative to get a law in place that makers of software must not make the software become unusable after they end support. While this is directly about games, it has implications for things like cars, tractors, medical devices, and anything that has a significant software component. I encourage my EU friends and colleagues to consider signing and explaining to their friends why it's important for them to sign even if they don't play games. Here's a video that explains it: https://www.youtube.com/watch?v=mkMe9MxxZiI Here's tha petition: https://www.stopkillinggames.com/ Sorry this is a bit off-topic, but I think it's important to the entire software industry. ../Dave

Aug. 3, 2024