November 2023 - Pharo-dev - lists.pharo.org

Re: Compiling Pharo VM used for P8

by Jan VranÃ½

Hi, I'm still wondering if anyone managed to compile P8 VM on her/his Linux machine? Thanks! Jan On Mon, 2023-09-04 at 11:12 +0100, Jan Vrany wrote: > Hi, > > freshly downloaded zeroconf VM for P8 shows in `pharo -version`: > > Date: Wed Feb 12 11:43:20 2020 CommitHash: 52202d8. > > so I tried this exact commit from https://github.com/pharo-project/pharo-vm.git : > > commit 52202d80a407f05e9eb4bbd1001d21d913c4fc5b (tag: dev-7-20200212-2, origin/cog/dev-7) > Author: Pablo Tesone <tesonep(a)gmail.com> > Date: Wed Feb 12 11:43:20 2020 +0100 > > Adding B3D plugin dependencies > > Just now also tried v8.6.1 as you suggested (from the same repo): > > commit e829a1dabcea88556103ebe61f69e2a8fb1111ea (HEAD, tag: v8.6.1) > Author: Pablo Tesone <tesonep(a)gmail.com> > Date: Tue Oct 13 15:43:09 2020 +0200 > > Changing version to 8.6.1 > > using cmake: > > git clone ... pharo-vm > cd pharo-vm > mkdir build > cd build > cmake .. > make > > but got a bunch of errors too (though very different) - see below. > > Jan > > ... > NewUndeclaredWarning: BalloonEnginePlugin>>primitiveAddRect (GEFWrongFill is Undeclared) > NewUndeclaredWarning: BalloonEnginePlugin>>primitiveAddRect (GEFEngineStopped is Undeclared) > NewUndeclaredWarning: BalloonEnginePlugin>>primitiveAddRect (GEFWorkTooBig is Undeclared) > NewUndeclaredWarning: BalloonEnginePlugin>>primitiveAddRect (GEFBadPoint is Undeclared) > NewUndeclaredWarning: BalloonEnginePlugin>>primitiveAddRect (GEFEntityLoadFailed is Undeclared) > MetacelloNotification: Loaded -> VMMaker-tonel.1 --- tonel:///home/jv/Projects/Pharo/pharo-vm/smalltalksrc --- cache > MetacelloNotification: Loading -> VMMakerCompatibilityForPharo6-tonel.1 --- tonel:///home/jv/Projects/Pharo/pharo-vm/smalltalksrc --- cache > Warning: This package depends on the following classes: > EncoderForV3 > You must resolve these dependencies before you will be able to load these definitions: > EncoderForV3>>#extensionsAt:in:into: > > MCPackageLoader(Object)>>notify: > MCPackageLoader>>warnAboutDependencies > MCPackageLoader>>validate > MCPackageLoader>>loadWithNameLike: > MCVersionLoader>>basicLoadWithNameLike: > [ > > ... > > adBlock goferLoad answers resolvedReference ...etc... > [:bar | > bar value: 1. > aBlock value. > bar value: 2 ] in IceMetacelloPharoPlatform(MetacelloPharoCommonPlatform)>>do:displaying: in Block: [:bar |... > > *** Warning: Warning: This package depends on the following classes: > EncoderForV3 > You must resolve these dependencies before you will be able to load these definitions: > EncoderForV3>>#extensionsAt:in:into: > > NewUndeclaredWarning: OCAbstractScope>>childrenDo:after:suchThat: (children is Undeclared) > NewUndeclaredWarning: OCAbstractScope>>childrenDo:after:suchThat: (children is Undeclared) > NewUndeclaredWarning: OCAbstractScope>>childrenDo:suchThat: (children is Undeclared) > NewUndeclaredWarning: OCAbstractScope>>childrenDo:suchThat: (children is Undeclared) > NewUndeclaredWarning: DisplayText class>>text: (DefaultTextStyle is Undeclared) > > ... > > MetacelloNotification: Loading -> FileAttributesPlugin-tonel.1 --- tonel:///home/jv/Projects/Pharo/pharo-vm/smalltalksrc --- cache > MetacelloNotification: Loaded -> FileAttributesPlugin-tonel.1 --- tonel:///home/jv/Projects/Pharo/pharo-vm/smalltalksrc --- cache > MetacelloNotification: ...finished baseline > [ 13%] Generating VM files for flavour: CoInterpreterWithQueueFFI > Generating #CoInterpreterWithQueueFFI in '/home/jv/Projects/Pharo/pharo-vm/build'... > NewUndeclaredWarning: VMMaker class>>forceNewFileNamed: (MultiByteFileStream is Undeclared) > NewUndeclaredWarning: VMMaker class>>forceNewFileNamed: (MultiByteFileStream is Undeclared) > #MultiByteFileStream is missing, and does not understand #forceNewFileNamed: > UndefinedObject>>doesNotUnderstand: #forceNewFileNamed: > VMMaker class>>forceNewFileNamed: > CCodeGeneratorGlobalStructure(CCodeGenerator)>>storeHeaderOnFile:contents: > > ... > > FullBlockClosure(BlockClosure)>>on:do: > PharoCommandLineHandler(BasicCommandLineHandler)>>activateSubCommand: > PharoCommandLineHandler(BasicCommandLineHandler)>>handleSubcommand > PharoCommandLineHandler(BasicCommandLineHandler)>>handleArgument: > Syntax Error on line 1: 'Variable or expression expected' > ========================================================= > 1: er frameCallerSP: (interpreter frameCallerFP: interpreter framePointer). > _^_ > 2: aContext := interpreter ensureFrameIsMarried: framePointerToMarry SP: stackPointerToMarry. > 3: interpreter externalDivorceFrame: framePointerToMarry andContext: aContext. > 4: expectedDivorcedContext := interpreter frameCallerContext: interpreter stackPage baseFP. > 5: > 6: self assert: expectedDivorcedContext equals: aContext. > make[2]: *** [CMakeFiles/PharoVMCore.dir/build.make:74: generated/vm/src/cogit.c] Error 1 > make[1]: *** [CMakeFiles/Makefile2:291: CMakeFiles/PharoVMCore.dir/all] Error 2 > make: *** [Makefile:156: all] Error 2 > > > > > > > > On Mon, 2023-09-04 at 10:47 +0200, Guillermo Polito wrote: > > Hi Jan, > > > > could you share a link to the repo/commit youâre building? > > > > Have you tried with this tag? > > > > https://github.com/pharo-project/pharo-vm/tree/v8.6.1 > > > > G > > > > > El 1 sep. 2023, a las 14:32, Jan VranÃ½ <Jan.Vrany(a)labware.com> escribiÃ³: > > > > > > Hi, > > > > > > I'm trying (and failing) to (re)compile Pharo VM used for P8, more specifically > > > this one (from `pharo -version): Date: Wed Feb 12 11:43:20 2020 CommitHash: 52202d8. > > > I'm targeting linux on x86_64. > > > > > > Whether I use mvm (seems that it was used by Jenkins by then) or cmake I always end > > > up having following errors (just a few, there're loads of them): > > > > > > /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:377: multiple definition of `debugCallbackInvokes'; vm/vm.a(gcc3x- > > > cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:377: first defined here > > > /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:376: multiple definition of `checkForLeaks'; vm/vm.a(gcc3x- > > > cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:376: first defined here > > > /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:375: multiple definition of `checkedPluginName'; vm/vm.a(gcc3x- > > > cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:375: first defined here > > > /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:374: multiple definition of `checkAllocFiller'; vm/vm.a(gcc3x- > > > cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:374: first defined here > > > /usr/bin/ld: vm/vm.a(cogit.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:371: multiple definition of `breakLookupClassTag'; vm/vm.a(gcc3x- > > > cointerp.o):/redacted/pharo-vm/spur64src/vm/cointerp.h:371: first defined here > > > > > > Does anyone have an idea? Is there a more detailed description of build > > > environment to use? > > > > > > Thanks! Jan > > > > > > > > > > > > > > > >

Nov. 28, 2023

This week (47/2023) on the Pharo Issue Tracker

by Marcus Denker

Lots of PRs merged last weekâ¦. # Pharo 11 - fixes: SpStringTableColumn displayAlignment is not applied (for Pharo11) #1476 https://github.com/pharo-spec/Spec/pull/1476 # Website / github Readme - Update README.md with Discord and GH Activity #15516 https://github.com/pharo-project/pharo/pull/15516 # Features - Halt once on call #15543 https://github.com/pharo-project/pharo/pull/15543 - Add String>>#findClosing:startingAt: generalizing #findCloseParenthesisFor: #15526 https://github.com/pharo-project/pharo/pull/15526 # Fixes - Fix Icerberg extension detection bug #15414 https://github.com/pharo-project/pharo/pull/15414 - Fix #14367: The same image started for the second time hangs on Windows #15434 Fix #14367: The same image started for the second time hangs on Windows #15434 - Fix method definitions saved in class pane #15503 https://github.com/pharo-project/pharo/pull/15503 - Not possible to ask if a file or folder (via reference) is hidden #15501 https://github.com/pharo-project/pharo/pull/15501 - Integrate new release of pharo-ai / graph-algorithms v1.2.6 #15521 https://github.com/pharo-project/pharo/pull/15521 - Disable automated transform for deprecation of Object>>asOrderedCollection #15540 https://github.com/pharo-project/pharo/pull/15540 - DrTest shortcut was not working #15539 https://github.com/pharo-project/pharo/pull/15539 - 15334-Browser-Accepting-a-class-definition-with-no-change-does-not-refresh #15538 https://github.com/pharo-project/pharo/pull/15538 - fixed #13982 Cleanup: FileSystem packages do not follow package naming #15546 https://github.com/pharo-project/pharo/pull/15546 - Fix #14957 by removing the special case for empty string #15544 https://github.com/pharo-project/pharo/pull/15544 - OSSDL2Driver loop: Avoid creating a new Delay every 5ms #15405 https://github.com/pharo-project/pharo/pull/15405 # Icons and Rendering - Refactor ThemeIcons to have methods that answer a FormSet instead of a Form #15421 https://github.com/pharo-project/pharo/pull/15421 - fix another old icon name #15409 https://github.com/pharo-project/pharo/pull/15409 - Fix more icon names, trivial cleanups #15411 https://github.com/pharo-project/pharo/pull/15411 # Spec - 1477-Doing-an-informduring-in-SpApplication-call-twice-the-during-block #1478 https://github.com/pharo-spec/Spec/pull/1478 - Introduce inform during #1473 https://github.com/pharo-spec/Spec/pull/1473 - Fix column alignment #1475 https://github.com/pharo-spec/Spec/pull/1475 # NewTools - NewTools-FileBrowser should not use StInspector but switch to #617 https://github.com/pharo-spec/NewTools/pull/617 - Pharo issue #15545: Restore author and time stamp to method versions #628 https://github.com/pharo-spec/NewTools/pull/628 - StFBDirectoryFilterTest fails #622 https://github.com/pharo-spec/NewTools/pull/622 - also collect class side methods #623 https://github.com/pharo-spec/NewTools/pull/623 - fix project's url #625 https://github.com/pharo-spec/NewTools/pull/625 - Simplify StFBVisibleFilter implementation #620 https://github.com/pharo-spec/NewTools/pull/620 # Iceberg (GIT Support) - Fix CI and remove Ring2 dependency #1765 https://github.com/pharo-vcs/iceberg/pull/1765 - Fix iceberg metacello integration #1771 https://github.com/pharo-vcs/iceberg/pull/1771 - Avoid useless garbage collects #1767 https://github.com/pharo-vcs/iceberg/pull/1767 - Small cleanups #1756 https://github.com/pharo-vcs/iceberg/pull/1756 - Clean packages usage #1759 https://github.com/pharo-vcs/iceberg/pull/1759 - Avoid RPackage extension #1758 https://github.com/pharo-vcs/iceberg/pull/1758 - Fixes #1746 https://github.com/pharo-vcs/iceberg/pull/1746 - iceberg was still using keyword, not selector, for Pragmas #1749 https://github.com/pharo-vcs/iceberg/pull/1749 - Use #isNotEmpty instead of #notEmpty in Iceberg #1752 https://github.com/pharo-vcs/iceberg/pull/1752 - Updating libgit2 to v3.0.9 #1764 https://github.com/pharo-vcs/iceberg/pull/1764 - Migrate to Tonel V3 #1766 https://github.com/pharo-vcs/iceberg/pull/1766 # Package Model - Packages: Clean tests (naming and reorganization) #15412 https://github.com/pharo-project/pharo/pull/15412 - Fix class template when a tag is selected #15415 https://github.com/pharo-project/pharo/pull/15415 - Packages: Rename package tags and conflict error #15435 https://github.com/pharo-project/pharo/pull/15435 - Packages: Manage edge case of empty tag name #15513 https://github.com/pharo-project/pharo/pull/15513 - Rename RPackage into Package #15377 https://github.com/pharo-project/pharo/pull/15377 - Remove last references to RPackage #15359 https://github.com/pharo-project/pharo/pull/15359 - Integrate Packages to kernel #15518 https://github.com/pharo-project/pharo/pull/15518 # System Announcer - Add tests on method announcements and fix a bug in traits announcements #15424 https://github.com/pharo-project/pharo/pull/15424 - Introduce #codeSupportAnnouncer #15418 https://github.com/pharo-project/pharo/pull/15418 - Push the bahevior of SystemAnnouncer into Announcer #15436 https://github.com/pharo-project/pharo/pull/15436 - Announcer: Reduce usage of global SystemAnnouncer #15468 https://github.com/pharo-project/pharo/pull/15468 - Deprecate SnapshotDone announcement #15514 https://github.com/pharo-project/pharo/pull/15514 # Monticello - Monticello: Remove unused announcer #15466 https://github.com/pharo-project/pharo/pull/15466 - Simplify MCWorkingCopy announcement listening #15403 https://github.com/pharo-project/pharo/pull/15403 - Monticello: Simplify class announcement listening #15419 https://github.com/pharo-project/pharo/pull/15419 - Start to deprecate Gofer #15422 https://github.com/pharo-project/pharo/pull/15422 # Ring - Ring: Improve Ring model to use it for Iceberg tests #15500 https://github.com/pharo-project/pharo/pull/15500 - Ring: Some fixes with Traits V2 #15460 https://github.com/pharo-project/pharo/pull/15460 - Ring: Fix RGPackage>>#asMCSnapshot #15488 https://github.com/pharo-project/pharo/pull/15488 # Refactoring Engine - Removing more unsued method in transformation now in PushDownVariable #15535 https://github.com/pharo-project/pharo/pull/15535 - fix 15529 - Remove unused preconditinos and RBCondition methods #15531 https://github.com/pharo-project/pharo/pull/15531 - 15395 - Removes refactoring precondition that checks for classes referenced by their name #15479 https://github.com/pharo-project/pharo/pull/15479 - Refact/remove class model factory #15445 https://github.com/pharo-project/pharo/pull/15445 - Remove unused RBEnvironmentVisitor and RBEnvironmentsPresenter. Fix #â¦ #15441 https://github.com/pharo-project/pharo/pull/15441 - 15523 refactoring rename refactoring is not working anymore #15525 https://github.com/pharo-project/pharo/pull/15525 # Compiler and Compilation - 15288-OCStaticASTCompilerPlugin-has-two-priority-mecanism #15548 https://github.com/pharo-project/pharo/pull/15548 - CompileMethod: Introduce the concept of properties to persist #15293 https://github.com/pharo-project/pharo/pull/15293 - CompiledMethod: Preserve protocol after removal #15364 https://github.com/pharo-project/pharo/pull/15364 - Simplify recompilation #15413 https://github.com/pharo-project/pharo/pull/15413 - Fix bug in recompilation of trait methods #15423 https://github.com/pharo-project/pharo/pull/15423 # Variables - implement #removeClassVarNamed: in terms of #removeClassVariable: #15473 https://github.com/pharo-project/pharo/pull/15473 - 15470-Remove-Pool-fileOut-support #15472 https://github.com/pharo-project/pharo/pull/15472 - reduce user of #classPool #15496 https://github.com/pharo-project/pharo/pull/15496 - Deprecate asClass #15478 https://github.com/pharo-project/pharo/pull/15478 - add a log to UndeclaredVariable class>>#possiblyRegisteredWithName: https://github.com/pharo-project/pharo/pull/15517 - 15261-cleanup-bindingsDo #15537 https://github.com/pharo-project/pharo/pull/15537 - Cleanup: reduce users of #classPool #15541 https://github.com/pharo-project/pharo/pull/15541 # Tests - Improving performance of some Refactoring Transformation tests #15486 https://github.com/pharo-project/pharo/pull/15486 - Faster TaskIt test run #15498 https://github.com/pharo-project/pharo/pull/15498 - Fix flacky testSubClassWithTraitsAfterModificationOfParentSharedPools #15417 https://github.com/pharo-project/pharo/pull/15417 - Provide a OpenToolTest>>#testImplementorsOfAt #15477 https://github.com/pharo-project/pharo/pull/15477 # Full Image Build - Clean Epicea Baseline #15416 https://github.com/pharo-project/pharo/pull/15416 - Small improvements to the primary baselines #15494 https://github.com/pharo-project/pharo/pull/15494 # Bootrap - Bootstrap: Remove dead code #15461 https://github.com/pharo-project/pharo/pull/15461 - Bootstrap: Remove hack for defined methods #15420 https://github.com/pharo-project/pharo/pull/15420 - Bootstrap: Remove pre Spur code #15397 https://github.com/pharo-project/pharo/pull/15397 - Bootstrap:â¯Do not rely on symlink to locate the bootstrap files #15462 https://github.com/pharo-project/pharo/pull/15462 - Bootstrap: Update localisation of SourceFileArray #15533 https://github.com/pharo-project/pharo/pull/15533 - Rename Pharo30Bootstrap into PharoBootstrap #15459 https://github.com/pharo-project/pharo/pull/15459 - Add logs on PharoBootstrapInitialization #15532 https://github.com/pharo-project/pharo/pull/15532 - Fix date printer during the bootstrap #15551 https://github.com/pharo-project/pharo/pull/15551 # Cleanups: Interaction - Deprecate #removeClassVarNamed:interactive: #15463 https://github.com/pharo-project/pharo/pull/15463 - fix #15407 and remove a spurious UIManager crappy pops up #15432 https://github.com/pharo-project/pharo/pull/15432 - 15400-Remove-spurious-UIManager-default-in-domain-object #15410 https://github.com/pharo-project/pharo/pull/15410 # Cleanup - Cleanup ClassParser: remove tokens #15547 https://github.com/pharo-project/pharo/pull/15547 - Extract Halt from kernel #15530 https://github.com/pharo-project/pharo/pull/15530 - transform timeout: into timeLimit: #15528 https://github.com/pharo-project/pharo/pull/15528 - 15446 clipboard class should be packaged outside of morphic core #15511 https://github.com/pharo-project/pharo/pull/15511 - Cleanup: Tag 3 uncategorized rules #15481 https://github.com/pharo-project/pharo/pull/15481 - Cleanup: Fix notNil -> isNotNil in all collections #15492 https://github.com/pharo-project/pharo/pull/15492 - Cleanup: fix lint issue in TComparable>>#min: and TIsEmpty>>#isNotEmpty by banning #15485 https://github.com/pharo-project/pharo/pull/15485 - Cleanup: Fix notNil -> isNotNil in FileSystem, Text-Diff, Color and Râ¦ #15475 https://github.com/pharo-project/pharo/pull/15475 - Cleanup: Fix notNil -> isNotNil in all Refactoring-* packages #15490 https://github.com/pharo-project/pharo/pull/15490 - Cleanup notNil in FFI/UFFI #15510 https://github.com/pharo-project/pharo/pull/15510

Nov. 27, 2023

Re: [rmod] Pharo needs you! Call to save the Pharo UI

by stephane ducasse

Thanks hernan. I do not think that there is a fileList in newTools. I will check your file dialog. S > On 23 Nov 2023, at 20:43, HernÃ¡n Morales <hernan-federico.morales(a)inria.fr> wrote: > > Hi Stef, > > De: "Stephane Ducasse" <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> > Para: "rmod" <rmod(a)inria.fr <mailto:rmod@inria.fr>>, pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org>, pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Enviados: Jueves, 23 de Noviembre 2023 11:28:15 > Asunto: [rmod] Pharo needs you! Call to save the Pharo UI > Hello people > If you want that Pharo just do not endlessly stay with such a crappy UI we all know, > please consider joining the effort. > > We should make sure that as a general principle, a model MUST not refer to a UI. > So that we can change the UI. We are working on it. But we need help. > > We should > (1) Migrate last cool Morphic-based tools such as Finder, Settings to Spec2, FileList to Spec > > (2) Remove dependencies from Domain objects to Morphic (obviously) > - remove to UIManager first from code outside Morphic. > > As a general principle please watch > http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M03_S5.mp4 > http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M09_S4.mp4 > It looks basic but it is so true. > > > Current status > (1) > Hernan started to work on the Setting Browser > I know someone started to work on Finder but I think the effort was stalled. > We need help there. > As a reference so that anyone can check the new Settings current status, this is the repository I'm working on: https://github.com/hernanmd/new-settings-browser > > Regarding the FileList, I'm afraid we duplicate efforts unnecessarily: I worked some time ago on https://github.com/hernanmd/file-dialog and then I saw that https://github.com/pharo-spec/NewTools appeared, it's a pity to have such a bad communication. > > The issue to close is the following: https://github.com/pharo-project/pharo/issues/15455 > > > Cheers, > > HernÃ¡n > > (2) > We started to clean the refactorings and we are making progress but this is slow. > I started to remove references to UIManager because it should go away. > > In Spec we introduced dialog, check the examples in subclasses of SpDialogPresenter > In addition, an application is able to create some default dialog > check ui - dialogs in SpApplication > I introduced a simple notification center that should play a kind of growl. > The inform: calls should be redirected to notify: because inform: was in P11 not blocking and now in P12 there are. > > I created special issues about the references to UIManager > I opened issues with a special tag > https://github.com/pharo-project/pharo/issues?q=is%3Aissue+is%3Aopen+label%… > > The analysis is here > > https://github.com/pharo-project/pharo/issues/14174 > > Here are some scripts. > > # Here we see the dependencies from Spec to UIManager > | allSpec results | > results := Dictionary new. > allSpec := SpPresenter withAllSubclasses. > > UIManager selectors do: > [ :sel | > | size | > size := ((SystemNavigation default allCallsOn: sel ) > select: [ :mth | allSpec includes: mth methodClass ]) size. > size isZero ifFalse: [ > results at: sel put: size]]. > String streamContents: [ :s | > results keys sorted do: [ :k | > s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] > # The following script shows the callers that are not in Spec nor in Morphic > | allSpec results allMorphs | > results := Dictionary new. > allSpec := SpPresenter withAllSubclasses. > allMorphs := Morph withAllSubclasses. > allClasses := Smalltalk allClasses. > allClasses := allClasses reject: [ :c | allSpec includes: c ]. > allClasses := allClasses reject: [ :c | allMorphs includes: c ]. > > UIManager selectors sorted do: > [ :sel | > | size | > size := ((SystemNavigation default allCallsOn: sel ) > select: [ :mth | allClasses includes: mth methodClass ]) size. > size isZero ifFalse: [ > results at: sel put: size]]. > String streamContents: [ :s | > results keys sorted do: [ :k | > s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] > > abort: -> 1 > abort:title: -> 5 > activate -> 15 > alert: -> 4 > alert:title: -> 4 > alert:title:configure: -> 2 > beDefault -> 2 > chooseDirectory -> 1 > chooseDirectory: -> 1 > chooseDirectory:from: -> 2 > chooseDirectoryFrom: -> 1 > chooseFrom: -> 2 > chooseFrom:lines: -> 2 > chooseFrom:lines:message: -> 1 > chooseFrom:lines:message:title: -> 2 > chooseFrom:lines:title: -> 8 > chooseFrom:title: -> 5 > chooseFrom:values: -> 5 > chooseFrom:values:lines: -> 1 > chooseFrom:values:lines:message: -> 1 > chooseFrom:values:lines:message:title: -> 3 > chooseFrom:values:lines:title: -> 4 > chooseFrom:values:message:title: -> 4 > chooseFrom:values:title: -> 8 > chooseFullFileNameMatching: -> 1 > chooseFullFileNameMatching:label: -> 1 > chooseOrRequestFrom:values:lines:title: -> 3 > confirm: -> 47 > confirm:label: -> 5 > confirm:label:trueChoice:falseChoice:cancelChoice:default: -> 1 > confirm:orCancel: -> 1 > confirm:trueChoice:falseChoice: -> 2 > confirm:trueChoice:falseChoice:cancelChoice:default: -> 6 > deactivate -> 5 > debugProcess:context:label:fullView:notification: -> 1 > defer: -> 24 > deny: -> 2565 > deny:title: -> 2 > displayProgress:from:to:during: -> 4 > edit:label: -> 4 > edit:label:accept: -> 3 > fileExistsDefaultAction: -> 1 > handleDebugRequest:fromDebuggerSystem: -> 1 > handleError: -> 2 > handleError:log: -> 2 > handleWarningDebugRequest:fromDebuggerSystem: -> 1 > inform: -> 98 > inform:actionOnClick: -> 1 > informUser:during: -> 13 > informUserDuring: -> 5 > logError: -> 2 > lowSpaceWatcherDefaultAction: -> 1 > merge:informing: -> 2 > multiLineRequest:initialAnswer:answerHeight: -> 5 > newDisplayDepthNoRestore: -> 1 > newMenuIn:for: -> 15 > onPrimitiveError: -> 1 > proceed:title: -> 2 > question:title: -> 2 > questionWithoutCancel: -> 1 > questionWithoutCancel:title: -> 2 > request: -> 13 > request:initialAnswer: -> 19 > request:initialAnswer:entryCompletion: -> 1 > request:initialAnswer:title: -> 13 > request:initialAnswer:title:entryCompletion: -> 6 > requestDebuggerOpeningFor: -> 1 > requestDebuggerOpeningForProcess:named:inContext: -> 1 > requestDebuggerOpeningForWarning: -> 1 > requestDebuggerOpeningNamed:inContext: -> 1 > requestPassword: -> 3 > restoreDisplay -> 3 > restoreDisplayAfter: -> 1 > spawnNewProcess -> 4 > systemNotificationDefaultAction: -> 1 > terminateUIProcess -> 1 > textEntry: -> 2 > textEntry:title: -> 2 > textEntry:title:entryText: -> 2 > unhandledErrorDefaultAction: -> 3 > warningDefaultAction: -> 1 > > > > -------------------------------------------- > 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 -------------------------------------------- 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

Nov. 23, 2023

Re: [rmod] Pharo needs you! Call to save the Pharo UI

by HernÃ¡n Morales

Hi Stef, > De: "Stephane Ducasse" <stephane.ducasse(a)inria.fr> > Para: "rmod" <rmod(a)inria.fr>, pharo-dev(a)lists.pharo.org, > pharo-users(a)lists.pharo.org > Enviados: Jueves, 23 de Noviembre 2023 11:28:15 > Asunto: [rmod] Pharo needs you! Call to save the Pharo UI > Hello people > If you want that Pharo just do not endlessly stay with such a crappy UI we all > know, > please consider joining the effort. > We should make sure that as a general principle, a model MUST not refer to a UI. > So that we can change the UI. We are working on it. But we need help. > We should > (1) Migrate last cool Morphic-based tools such as Finder, Settings to Spec2, > FileList to Spec > (2) Remove dependencies from Domain objects to Morphic (obviously) > - remove to UIManager first from code outside Morphic. > As a general principle please watch > [ http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M03_S5.mp4 | > http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M03_S5.mp4 ] > [ http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M09_S4.mp4 | > http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M09_S4.mp4 ] > It looks basic but it is so true. > Current status > (1) > Hernan started to work on the Setting Browser > I know someone started to work on Finder but I think the effort was stalled. > We need help there. As a reference so that anyone can check the new Settings current status, this is the repository I'm working on: https://github.com/hernanmd/new-settings-browser Regarding the FileList, I'm afraid we duplicate efforts unnecessarily: I worked some time ago on https://github.com/hernanmd/file-dialog and then I saw that https://github.com/pharo-spec/NewTools appeared, it's a pity to have such a bad communication. The issue to close is the following: https://github.com/pharo-project/pharo/issues/15455 Cheers, HernÃ¡n > (2) > We started to clean the refactorings and we are making progress but this is > slow. > I started to remove references to UIManager because it should go away. > In Spec we introduced dialog, check the examples in subclasses of > SpDialogPresenter > In addition, an application is able to create some default dialog > check ui - dialogs in SpApplication > I introduced a simple notification center that should play a kind of growl. > The inform: calls should be redirected to notify: because inform: was in P11 not > blocking and now in P12 there are. > I created special issues about the references to UIManager > I opened issues with a special tag > [ > https://github.com/pharo-project/pharo/issues?q=is%3Aissue+is%3Aopen+label%… > | > https://github.com/pharo-project/pharo/issues?q=is%3Aissue+is%3Aopen+label%… > ] > The analysis is here > [ https://github.com/pharo-project/pharo/issues/14174 | > https://github.com/pharo-project/pharo/issues/14174 ] > Here are some scripts. > # Here we see the dependencies from Spec to UIManager > | allSpec results | > results := Dictionary new. > allSpec := SpPresenter withAllSubclasses. > UIManager selectors do: > [ :sel | > | size | > size := ((SystemNavigation default allCallsOn: sel ) > select: [ :mth | allSpec includes: mth methodClass ]) size. > size isZero ifFalse: [ > results at: sel put: size]]. > String streamContents: [ :s | > results keys sorted do: [ :k | > s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] > # The following script shows the callers that are not in Spec nor in Morphic > | allSpec results allMorphs | > results := Dictionary new. > allSpec := SpPresenter withAllSubclasses. > allMorphs := Morph withAllSubclasses. > allClasses := Smalltalk allClasses. > allClasses := allClasses reject: [ :c | allSpec includes: c ]. > allClasses := allClasses reject: [ :c | allMorphs includes: c ]. > UIManager selectors sorted do: > [ :sel | > | size | > size := ((SystemNavigation default allCallsOn: sel ) > select: [ :mth | allClasses includes: mth methodClass ]) size. > size isZero ifFalse: [ > results at: sel put: size]]. > String streamContents: [ :s | > results keys sorted do: [ :k | > s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] > abort: -> 1 > abort:title: -> 5 > activate -> 15 > alert: -> 4 > alert:title: -> 4 > alert:title:configure: -> 2 > beDefault -> 2 > chooseDirectory -> 1 > chooseDirectory: -> 1 > chooseDirectory:from: -> 2 > chooseDirectoryFrom: -> 1 > chooseFrom: -> 2 > chooseFrom:lines: -> 2 > chooseFrom:lines:message: -> 1 > chooseFrom:lines:message:title: -> 2 > chooseFrom:lines:title: -> 8 > chooseFrom:title: -> 5 > chooseFrom:values: -> 5 > chooseFrom:values:lines: -> 1 > chooseFrom:values:lines:message: -> 1 > chooseFrom:values:lines:message:title: -> 3 > chooseFrom:values:lines:title: -> 4 > chooseFrom:values:message:title: -> 4 > chooseFrom:values:title: -> 8 > chooseFullFileNameMatching: -> 1 > chooseFullFileNameMatching:label: -> 1 > chooseOrRequestFrom:values:lines:title: -> 3 > confirm: -> 47 > confirm:label: -> 5 > confirm:label:trueChoice:falseChoice:cancelChoice:default: -> 1 > confirm:orCancel: -> 1 > confirm:trueChoice:falseChoice: -> 2 > confirm:trueChoice:falseChoice:cancelChoice:default: -> 6 > deactivate -> 5 > debugProcess:context:label:fullView:notification: -> 1 > defer: -> 24 > deny: -> 2565 > deny:title: -> 2 > displayProgress:from:to:during: -> 4 > edit:label: -> 4 > edit:label:accept: -> 3 > fileExistsDefaultAction: -> 1 > handleDebugRequest:fromDebuggerSystem: -> 1 > handleError: -> 2 > handleError:log: -> 2 > handleWarningDebugRequest:fromDebuggerSystem: -> 1 > inform: -> 98 > inform:actionOnClick: -> 1 > informUser:during: -> 13 > informUserDuring: -> 5 > logError: -> 2 > lowSpaceWatcherDefaultAction: -> 1 > merge:informing: -> 2 > multiLineRequest:initialAnswer:answerHeight: -> 5 > newDisplayDepthNoRestore: -> 1 > newMenuIn:for: -> 15 > onPrimitiveError: -> 1 > proceed:title: -> 2 > question:title: -> 2 > questionWithoutCancel: -> 1 > questionWithoutCancel:title: -> 2 > request: -> 13 > request:initialAnswer: -> 19 > request:initialAnswer:entryCompletion: -> 1 > request:initialAnswer:title: -> 13 > request:initialAnswer:title:entryCompletion: -> 6 > requestDebuggerOpeningFor: -> 1 > requestDebuggerOpeningForProcess:named:inContext: -> 1 > requestDebuggerOpeningForWarning: -> 1 > requestDebuggerOpeningNamed:inContext: -> 1 > requestPassword: -> 3 > restoreDisplay -> 3 > restoreDisplayAfter: -> 1 > spawnNewProcess -> 4 > systemNotificationDefaultAction: -> 1 > terminateUIProcess -> 1 > textEntry: -> 2 > textEntry:title: -> 2 > textEntry:title:entryText: -> 2 > unhandledErrorDefaultAction: -> 3 > warningDefaultAction: -> 1 > -------------------------------------------- > 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

Nov. 23, 2023

Pharo needs you! Call to save the Pharo UI

by stephane ducasse

Hello people If you want that Pharo just do not endlessly stay with such a crappy UI we all know, please consider joining the effort. We should make sure that as a general principle, a model MUST not refer to a UI. So that we can change the UI. We are working on it. But we need help. We should (1) Migrate last cool Morphic-based tools such as Finder, Settings to Spec2, FileList to Spec (2) Remove dependencies from Domain objects to Morphic (obviously) - remove to UIManager first from code outside Morphic. As a general principle please watch http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M03_S5.mp4 http://rmod-pharo-mooc.lille.inria.fr/AdvancedDesignMooc/Videos/M09_S4.mp4 It looks basic but it is so true. Current status (1) Hernan started to work on the Setting Browser I know someone started to work on Finder but I think the effort was stalled. We need help there. (2) We started to clean the refactorings and we are making progress but this is slow. I started to remove references to UIManager because it should go away. In Spec we introduced dialog, check the examples in subclasses of SpDialogPresenter In addition, an application is able to create some default dialog check ui - dialogs in SpApplication I introduced a simple notification center that should play a kind of growl. The inform: calls should be redirected to notify: because inform: was in P11 not blocking and now in P12 there are. I created special issues about the references to UIManager I opened issues with a special tag https://github.com/pharo-project/pharo/issues?q=is%3Aissue+is%3Aopen+label%… The analysis is here https://github.com/pharo-project/pharo/issues/14174 <https://github.com/pharo-project/pharo/issues/14174> Here are some scripts. # Here we see the dependencies from Spec to UIManager | allSpec results | results := Dictionary new. allSpec := SpPresenter withAllSubclasses. UIManager selectors do: [ :sel | | size | size := ((SystemNavigation default allCallsOn: sel ) select: [ :mth | allSpec includes: mth methodClass ]) size. size isZero ifFalse: [ results at: sel put: size]]. String streamContents: [ :s | results keys sorted do: [ :k | s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] # The following script shows the callers that are not in Spec nor in Morphic | allSpec results allMorphs | results := Dictionary new. allSpec := SpPresenter withAllSubclasses. allMorphs := Morph withAllSubclasses. allClasses := Smalltalk allClasses. allClasses := allClasses reject: [ :c | allSpec includes: c ]. allClasses := allClasses reject: [ :c | allMorphs includes: c ]. UIManager selectors sorted do: [ :sel | | size | size := ((SystemNavigation default allCallsOn: sel ) select: [ :mth | allClasses includes: mth methodClass ]) size. size isZero ifFalse: [ results at: sel put: size]]. String streamContents: [ :s | results keys sorted do: [ :k | s nextPutAll: k , ' -> ', (results at: k) asString. s cr. ]] abort: -> 1 abort:title: -> 5 activate -> 15 alert: -> 4 alert:title: -> 4 alert:title:configure: -> 2 beDefault -> 2 chooseDirectory -> 1 chooseDirectory: -> 1 chooseDirectory:from: -> 2 chooseDirectoryFrom: -> 1 chooseFrom: -> 2 chooseFrom:lines: -> 2 chooseFrom:lines:message: -> 1 chooseFrom:lines:message:title: -> 2 chooseFrom:lines:title: -> 8 chooseFrom:title: -> 5 chooseFrom:values: -> 5 chooseFrom:values:lines: -> 1 chooseFrom:values:lines:message: -> 1 chooseFrom:values:lines:message:title: -> 3 chooseFrom:values:lines:title: -> 4 chooseFrom:values:message:title: -> 4 chooseFrom:values:title: -> 8 chooseFullFileNameMatching: -> 1 chooseFullFileNameMatching:label: -> 1 chooseOrRequestFrom:values:lines:title: -> 3 confirm: -> 47 confirm:label: -> 5 confirm:label:trueChoice:falseChoice:cancelChoice:default: -> 1 confirm:orCancel: -> 1 confirm:trueChoice:falseChoice: -> 2 confirm:trueChoice:falseChoice:cancelChoice:default: -> 6 deactivate -> 5 debugProcess:context:label:fullView:notification: -> 1 defer: -> 24 deny: -> 2565 deny:title: -> 2 displayProgress:from:to:during: -> 4 edit:label: -> 4 edit:label:accept: -> 3 fileExistsDefaultAction: -> 1 handleDebugRequest:fromDebuggerSystem: -> 1 handleError: -> 2 handleError:log: -> 2 handleWarningDebugRequest:fromDebuggerSystem: -> 1 inform: -> 98 inform:actionOnClick: -> 1 informUser:during: -> 13 informUserDuring: -> 5 logError: -> 2 lowSpaceWatcherDefaultAction: -> 1 merge:informing: -> 2 multiLineRequest:initialAnswer:answerHeight: -> 5 newDisplayDepthNoRestore: -> 1 newMenuIn:for: -> 15 onPrimitiveError: -> 1 proceed:title: -> 2 question:title: -> 2 questionWithoutCancel: -> 1 questionWithoutCancel:title: -> 2 request: -> 13 request:initialAnswer: -> 19 request:initialAnswer:entryCompletion: -> 1 request:initialAnswer:title: -> 13 request:initialAnswer:title:entryCompletion: -> 6 requestDebuggerOpeningFor: -> 1 requestDebuggerOpeningForProcess:named:inContext: -> 1 requestDebuggerOpeningForWarning: -> 1 requestDebuggerOpeningNamed:inContext: -> 1 requestPassword: -> 3 restoreDisplay -> 3 restoreDisplayAfter: -> 1 spawnNewProcess -> 4 systemNotificationDefaultAction: -> 1 terminateUIProcess -> 1 textEntry: -> 2 textEntry:title: -> 2 textEntry:title:entryText: -> 2 unhandledErrorDefaultAction: -> 3 warningDefaultAction: -> 1 -------------------------------------------- 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

Nov. 23, 2023

Open Call: Object-Centric Breakpoints experiment

by Steven Costiou

Dear Community, We would like to invite you to participate to our experimental study on Object-Centric Breakpoints. This study aims to evaluate and to understand how Object-Centric Breakpoints impacts the debugging activity. This experiment takes place in **Pharo 9**. In this experiment, we ask you to solve 2 debugging tasks, one with standard Pharo tools and one other with Object-Centric Breakpoints. Between the two tasks, you will have to follow a tutorialand warmup tasks to learn how to use the tool. **How to Participate:** All instructions are here, please read them carefully: https://github.com/Pharo-XP-Tools/XPImageGeneration/tree/exp-ocd **About the Experiment:** The experiment last between 40 minutes and 2 hours. Participants should have experience with Pharo development and debugging. We recommend having more than 6 months experience in Pharo and debugging in general. You will gain insights into the Object-Centric Breakpoints approach and contribute to advancements in debugging research. Help us to build better debugging tools that help you debug! :) **Some constraints:** - You are not allowed to load external tools and baselines, but you can use anything that is in the base image - Please do the experiment in one shot if possible without interruptions - The experiment sends anonymous data to our inria server, please make sure that you have a valid internet connection - Please try to use the object-centric breakpoints when the experimental framework asks you to **Notes:** Participation is voluntary, and everything is anonymous. You can abandon the experiment at any point (and your data will be discarded). For any question, you can contact us: steven.costiou(a)inria.fr and valentin.bourcier(a)inria.fr Thank you for considering participating in our study. Your contribution will be valuable in advancing the field of debugging and helping us understand what tools we need to build for Pharo. Sincerely, Steven and Valentin, EVREF team, Inria

Nov. 21, 2023

This week (46/2023) on the Pharo Issue Tracker

by Marcus Denker

# Pharo 11 Backports - backport: Guard RubAbstractTextArea>>#recomputeSelection for empty paragraphs #15140 #15375 https://github.com/pharo-project/pharo/pull/15375 - backport "Defer change list update to avoid a race condition" #14853 #15374 https://github.com/pharo-project/pharo/pull/15374 - 15372-backport-Pharo11-safer-morph-access-in-NECMenuMorphmouseDown-14356 #15373 https://github.com/pharo-project/pharo/pull/15373 # Fixes - Fix scaling of #blankIcon and #notFoundIcon on ThemeIcons #15399 https://github.com/pharo-project/pharo/pull/15399 - 15299-UFFI-should-release-pointers-allocated-for-packing-for-arity #15300 https://github.com/pharo-project/pharo/pull/15300 - 15302-FreeTypeFonts-should-not-use-autorelease-of-ExternalAddresses #15303 https://github.com/pharo-project/pharo/pull/15303 - Calypso: Fix display of extended classes in project view #15314 https://github.com/pharo-project/pharo/pull/15314 - Fix imageCleaner concurrency issue when unifying literals #15385 https://github.com/pharo-project/pharo/pull/15385 - Do not log recompilation in the source file #15398 https://github.com/pharo-project/pharo/pull/15398 - Guard removals of morphs in layouts #1467 https://github.com/pharo-spec/Spec/pull/1467 # Features - Extend ThemeIcons to load the icons for all scales in the icon pack #15323 https://github.com/pharo-project/pharo/pull/15323 - Auto completion should propose globals #15392 https://github.com/pharo-project/pharo/pull/15392 - Calypso: Show content of projects #15315 https://github.com/pharo-project/pharo/pull/15315 # Package Model Cleanup - Packages: Fix missing extensions after class recompiling #15326 https://github.com/pharo-project/pharo/pull/15326 - Introduce a method to get the meta model announcer #15310 https://github.com/pharo-project/pharo/pull/15310 - Packages: Remove #definedSelectors cache #15278 https://github.com/pharo-project/pharo/pull/15278 - Packages: Removing more references to #category #15320 https://github.com/pharo-project/pharo/pull/15320 - RPackage: Deprecate #includesDefinedSelector:ofClass: #15214 https://github.com/pharo-project/pharo/pull/15214 - Package: Move extension methods of RPackage #15346 https://github.com/pharo-project/pharo/pull/15346 - Rename RPackageOrganizer into PackageOrganizer #15360 https://github.com/pharo-project/pharo/pull/15360 - Monticello: Remove usage of RPackageSet #15363 https://github.com/pharo-project/pharo/pull/15363 - Update RPackage dependencies #15393 https://github.com/pharo-project/pharo/pull/15393 - DependencyAnalyzer: Remove usage of RPackageSet #15368 https://github.com/pharo-project/pharo/pull/15368 # Monticello - Remove MCPatchBrowser #15376 https://github.com/pharo-project/pharo/pull/15376 - Monticello: Introduce Monticello-Model #15350 https://github.com/pharo-project/pharo/pull/15350 - Monticello: Simplify method loading #15292 https://github.com/pharo-project/pharo/pull/15292 - Monticello: Remove dead code #15351 https://github.com/pharo-project/pharo/pull/15351 - Monticello: Move mocks to mock package #15361 https://github.com/pharo-project/pharo/pull/15361 - Remove WorkingCopy spotter entries #610 https://github.com/pharo-spec/NewTools/pull/610 # MetaCello - Cleanup metacello #15287 https://github.com/pharo-project/pharo/pull/15287 - Metacello: New cleaning pass #15312 https://github.com/pharo-project/pharo/pull/15312 - Add missing methods for SmalltalkCI #15339 https://github.com/pharo-project/pharo/pull/15339 - Fixes #15342: Monticello: GitHub CI fails with DNU #15344 https://github.com/pharo-project/pharo/pull/15344 - Metacello: fix block evaluation #15362 https://github.com/pharo-project/pharo/pull/15362 # Kernel - Allow to create anonymous classes in a specific environment #15309 https://github.com/pharo-project/pharo/pull/15309 - Fix bug in remake of anonymous classes #15343 https://github.com/pharo-project/pharo/pull/15343 - Undeclared: declare:from: cleanup, first step #15290 https://github.com/pharo-project/pharo/pull/15290 - Remove private system announcer #15355 https://github.com/pharo-project/pharo/pull/15355 - do not hardcode global environment in #removeFromSystem: #15357 https://github.com/pharo-project/pharo/pull/15357 - Add binary selector alias for #newFromArray: for Collection #15316 https://github.com/pharo-project/pharo/pull/15316 # Traits - Traits: Fix bug in dictionary rebuild #15353 https://github.com/pharo-project/pharo/pull/15353 - Speedup #explicitRequirement #15322 https://github.com/pharo-project/pharo/pull/15322 - Traits: Speedup #isFromTrait #15318 https://github.com/pharo-project/pharo/pull/15318 - Rename TraitsV2 into Traits #15319 https://github.com/pharo-project/pharo/pull/15319 - Traits: Do a new cleaning pass over the traits tests and fix file out bug #15304 https://github.com/pharo-project/pharo/pull/15304 - Remove TraitsV2-Compatibility #15325 https://github.com/pharo-project/pharo/pull/15325 # Refactoring Engine - Migrate rename class to driver #15394 https://github.com/pharo-project/pharo/pull/15394 - remove deadcode from driver package #15390 https://github.com/pharo-project/pharo/pull/15390 - RB: A simple fix for abstract methods. No brainer. #15331 https://github.com/pharo-project/pharo/pull/15331 - Remove unused SycRemoveMethodCommand #15337 https://github.com/pharo-project/pharo/pull/15337 - Refactorings: Follow package name convention #15340 https://github.com/pharo-project/pharo/pull/15340 # Tests - Fix #testUndeclared in case of failure #15356 https://github.com/pharo-project/pharo/pull/15356 - Release tests: Improve testNoSentButNotImplementedSelectors #15341 https://github.com/pharo-project/pharo/pull/15341 - Use a test resource for SystemDependenciesTest #15308 https://github.com/pharo-project/pharo/pull/15308 # Cleanup - Some cleanup of CodeExport #15380 https://github.com/pharo-project/pharo/pull/15380 - Deprecate gofer command line #15347 https://github.com/pharo-project/pharo/pull/15347 - Clean AST-Core #15358 https://github.com/pharo-project/pharo/pull/15358 - Remove #isUnitTest #15349 https://github.com/pharo-project/pharo/pull/15349 - Manifest builder should not rely on categories #15324 https://github.com/pharo-project/pharo/pull/15324 - Remove workspace #15284 https://github.com/pharo-project/pharo/pull/15284 - Deprecate TRBProgramNodeVisitor #15305 https://github.com/pharo-project/pharo/pull/15305 - Refactor #inspectionIcons on ThemeIcons to use the #icons accessor #609 https://github.com/pharo-spec/NewTools/pull/609 # Cleanup Trivail - fix icons #15371 https://github.com/pharo-project/pharo/pull/15371 - use allButFirst and simplify expression #15382 https://github.com/pharo-project/pharo/pull/15382 - use allButFirst instead of copyFrom:to: #15369 https://github.com/pharo-project/pharo/pull/15369 - use allButFirst instead of copyFrom:to: #15366 https://github.com/pharo-project/pharo/pull/15366 - Remove deprecated calls #15354 https://github.com/pharo-project/pharo/pull/15354 - Cleanup: usage of notNil in Text-Scanning, Rubric, HeuristicCompletion, NECCompletion, Growl, Regex #15296 https://github.com/pharo-project/pharo/pull/15296 - Cleanup: usage of notNil in Calypse, Microdown, System-Changes, STON, System-Settings #15297 https://github.com/pharo-project/pharo/pull/15297 - Cleanup: Usage of "notNil" and "isEmpty not" in Zinc / Zodiac #15253 https://github.com/pharo-project/pharo/pull/15253

Nov. 17, 2023

Re: [Pharo-vm] Stack overflow support?

by stephane ducasse

Thanks. We will digest and discuss internally. S > On 14 Nov 2023, at 07:19, Daniel Slomovits <daniels220(a)gmail.com> wrote: > > Hello Stephane, > > A simple example like thatâreally any case caused by common types of mistake, even if the method involved is more complexâwouldn't get to run for a couple seconds. It would error out after a small fraction of a second, since the interrupt is issued immediately upon exceeding the limit (which by default isâoops, 64k slots, 256kB, at most ~10k stack frames, but realistically less due to args and temps), and it just doesn't take that long to execute most recursive methods 10k levels deep. > > At this point it would raise the limit a little for that process and signal a StackOverflow exception. In production this likely would mean killing the process but that's up to application code. In development you get a walkback like any other exception. Because the stack is kept to a relatively reasonable size, I've never had debugger performance be an issueâit's noticeably more sluggish, but we're talking about taking 200-300ms to respond instead of imperceptible. Similarly for GC pressureâeven if you have dozens of processes all maxed out on stack, this would still be less than the memory used to start a base image. > > Certainly there are scenarios that can cause problemsâan error while printing an object will stop you from opening a debugger, yes. However a StackOverflow in particular isn't any worse than any other exceptionâin all cases you'll get a walkback, hit "Debug", and get another walkback instead of a debugger. If you hit "Terminate" at that point, it might leave the original process in a zombie state and/or a hidden debugger window, but you can kill it from the Process Monitor/close it from the Window menu and be fine. And even this is because Dolphin doesn't safeguard printing in the development tools the way Pharo doesâif Pharo adopted stack overflow handling like Dolphin's, a stack overflow likely wouldn't even stop you from opening a debugger, it would just make it a little slow, then something would show up with "error printing: a StackOverflow" or the like. > > Hope that helps. > > Daniel > > On Sun, Nov 12, 2023 at 4:53â¯AM stephane ducasse <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> Hi daniel >> >> Thanks for the feedback. >> May be you wrote it but I could not really understand. >> >> How dolphin handled >> >>>> ``` >>>> A >> foo >>>> ^ self foo >>>> ``` >> >> That is let to run a couple of seconds? >> Did they kill the process? >> >> In Pharo we do have an interrupt but >> >>>> But it could happen that, >>>> - the stack is so big that the debugger is very sluggish (best-case scenario) >>>> - the VM is just flooded doing GCs so maybe the Ctrl dot event does not even arrive at Pharo or the trigger >>>> - if the recursion is hit when printing an object (which is more common than you could imagine), opening the debugger could trigger a new recursion and never give back the control to the user >> >> >> S >> >>> On 11 Nov 2023, at 05:10, Daniel Slomovits <daniels220(a)gmail.com <mailto:daniels220@gmail.com>> wrote: >>> >>> I think this is a great idea. I've mostly used Dolphin Smalltalk, which is actually a strict stack machine under the hood (it has a context-like introspection API but the stack is explicitly the canonical form), so it's more-or-less forced to implement a limit of some kind. When I started using Pharo I triggered a couple stack overflows by mistake, and was frustrated by the fact that at first what happened was...nothing, everything seemed fine, my code just didn't work. And then half a minute later Pharo gets extremely slow and I notice it's using 2GB of memory and by then it's too late and I have to kill the image. Getting a more-or-less immediate error would be much more user-friendly IMO. >>> >>> A couple things to learn from Dolphin's implementation, I think: >>> When a stack overflow is detected, the resulting interrupt raises that process' stack limit by a significant amount (though by less than the original limitâIOW it doesn't double, but it's not just a couple more frames either) before signaling the exception, precisely so that exception handling can occur without triggering another stack-overflow event. A further refinement could be that if a second stack overflow is detected, we directly invoke more basic recoveryâthis could mean an emergency evaluator, terminating the offending process and opening a post-mortem with a textual stack dump (ugh! but at least it's predictable), etc. >>> I don't think we should worry too much about refining what exactly the limit is. 10x as much stack as 99% of code will ever use, is still a tiny amount compared to consuming all available memory with Contexts. At least, if I'm understanding the graph/data correctly. That's 36kB of stack space, right? Not 36k frames/contexts deep? With each context being six slots plus args/temps, 36kB is 500-750 frames on a 64-bit VM (in stack representationâcontexts add object-header overhead but we don't reify them unless we have to). For reference, Dolphin's limit is 64kB, but that's a 32-bit VM, so the equivalent for 64-bit would be 128kB...but because Pharo can spill contexts to the stack, the limit could easily be 1MB, or a fixed number of frames designed to approximate thatâstill a tiny amount of memory overall, and still will be hit near-instantly by true infinite recursion, but lots of breathing room for most use cases. >>> Actually, this did get me to thinking...the stack depth of a Pharo process is not necessarily easy/cheap to compute in the general case, without caching a lot of information on intermediate contexts. In most cases the context chain acts as a proper stack, but not alwaysâmethods like Process>>on:do:, and some even more esoteric ones I forget off the top of my head, make modifications far away from the top context and may splice context chains together in odd ways. Perhaps a more flexible limit would be betterâone that is triggered by allocating more than a certain number of contexts total, and examines running Processes in detail to find the culprit at that point. >>> >>> On Thu, Nov 9, 2023 at 4:38â¯AM Guillermo Polito <guillermopolito(a)gmail.com <mailto:guillermopolito@gmail.com>> wrote: >>>> Hi all, >>>> >>>> We started (with many interruptions over the last months) working a bit with Stephane on understanding what is the (positive and negative) impact of stack-overflow support in Pharo. >>>> The key idea is that if a process consumes too much stack (potentially because of an infinite recursion) then the process should stop with an exception. >>>> >>>> ## Why we want better stack consumption control >>>> >>>> This idea comes up to solve issues that are pretty common and hit especially newbies. >>>> For example, imagine you accidentally write an accessor such as >>>> >>>> ``` >>>> A >> foo >>>> ^ self foo >>>> ``` >>>> >>>> Students do this all the time, and Iâve also seen it in experienced people who go too fast :). >>>> More importantly, such recursions could happen also with not-so-obvious indirect recursions (a sends b, b sends c, c sends a), and these could hit anybody. >>>> >>>> This is aggravated because the current execution model allows us to have infinite stacks âmeaning: limited by available memory only. >>>> This is indeed a nice feature for many use cases but it has its own drawbacks when one of these kind of recursions are hit: >>>> - code just loops forever taking space in the stack >>>> - when there is no more stack space, context objects are created and moved to the heap >>>> - but those contexts are strongly held, so they are never GCed and take up extra space >>>> - even worse! they are there adding more work to the GC every time and making the GC run more often looking for space that is not there >>>> >>>> ## Why Ctrl-dot does not always work >>>> >>>> Of course, super users know there is this âCtrl dotâ hidden feature that should help you recover from this. >>>> First, let's take out of the equation that this is only known by super users. >>>> Now, in this situation, when Ctrl-dot is hit it will trigger a handler that suspends the problematic process and opens a debugger on it. >>>> But it could happen that, >>>> - the stack is so big that the debugger is very sluggish (best-case scenario) >>>> - the VM is just flooded doing GCs so maybe the Ctrl dot event does not even arrive at Pharo or the trigger >>>> - if the recursion is hit when printing an object (which is more common than you could imagine), opening the debugger could trigger a new recursion and never give back the control to the user >>>> >>>> ## What are we working on >>>> >>>> The main idea here is: Can we have a simple and efficient way to prevent such kinds of situations? >>>> >>>> After many discussions around detecting recursion, we kinda arrived at the simple solution of just detecting a stack overflow. >>>> The solution is easy to understand (because itâs like other languages work) and easy to implement because there is already support for that. >>>> But this leaves open two questions: >>>> - what happens when people want to use the âinfinite stackâ feature? >>>> - when should a process stack overflow? What is a sensitive default value? >>>> >>>> Our draft implementation here https://github.com/pharo-project/pharo-vm/pull/710 does the following to cope with this: >>>> - we can now parametrize the size of the stack (of each stack page to be more accurate) when the VM starts up >>>> - the stack overflow check can be disabled per process >>>> >>>> We also are running experiments to see what could be a sensitive stack size for our normal usages. Here, for example, we ran almost all test cases in Pharo separately (one suite per line below), and we observed how many tests broke (x-axis) with different stack sizes (y-axis). >>>> Here we see that most test suites require at least 20-24k to run properly, some go up to 36k of stack before converging (i.e., the number of broken tests does not change). >>>> >>>> <ImagenPegada-10.tiff> >>>> >>>> Youâll notice in the graph that There are some scenarios that break all the time. This is because exception handling itself is recursive and may produce more stack overflows depending on the size of the stack between the exception and the exception handler. >>>> So some more work is still required, mostly changing Pharo libraries to properly support this. For example: >>>> - should tests run in a fresh process with a fresh stack? >>>> - should the exception mechanism use less recursion? >>>> - resumable exceptions add stack pressure because they do not âunstackâ until the exception is finally handled, meaning that the stack used by exception handling just adds up to the stack of the original code, can we do better here? >>>> >>>> Probably there are more interesting questions here, thatâs the âwhy" behind this email. >>>> Iâm interested in opinions and scenarios you may come up with that should be taken into account. >>>> >>>> Cheers, >>>> Guille >>> _______________________________________________ >>> 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> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr <http://stephane.ducasse.free.fr/> / http://www.pharo.org <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 >> >> >> > _______________________________________________ > Pharo-vm mailing list -- pharo-vm(a)lists.pharo.org > To unsubscribe send an email to pharo-vm-leave(a)lists.pharo.org -------------------------------------------- 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

Nov. 15, 2023

Re: New blog post on all:objects all: theTime

by Noury Bouraqadi

Thank you Koen for update. Keep pushing. Noury On Nov 15 2023, at 8:25 am, Koen De Hondt <koen(a)all-objects-all-the-time.st> wrote: > Dear Pharo users and developers, > > After my presentation at ESUGâ23, which has been added to my blog (https://all-objects-all-the-time.st/#/blog/posts/4) too, I wrote an evaluation of Calypso (https://all-objects-all-the-time.st/#/blog/posts/5) in which I refer to results of the Pharo Browser Survey that I presented at ESUGâ23. > > It is a long post. It will be the basis for more posts on browsers in Pharo. > > My blog does not support commenting. If you have any feedback or comment, please feel free to send me a message. > > Happy reading! > > Ciao, > Koen

Nov. 15, 2023

New blog post on all:objects all: theTime

by Koen De Hondt

Dear Pharo users and developers, After my presentation at ESUGâ23, which has been added to my blog <https://all-objects-all-the-time.st/#/blog/posts/4> too, I wrote an evaluation of Calypso <https://all-objects-all-the-time.st/#/blog/posts/5>, in which I refer to results of the Pharo Browser Survey that I presented at ESUGâ23. It is a long post. It will be the basis for more posts on browsers in Pharo. My blog does not support commenting. If you have any feedback or comment, please feel free to send me a message. Happy reading! Ciao, Koen

Nov. 15, 2023