December 2020 - Pharo-dev - lists.pharo.org

Browsing crashed image

by Danil Osipchuk

Hi, Pharoes Is there a simple way to file out a package from an image which is crashing? The most close thing I found is Epicea/code changes tool - it seems that I have to apply all changes I did (and they are numerous, I didn't expect the image will die since I did nothing fancy, so was just saving the image for speed) regards, Danil

Dec. 23, 2020

This week (52/2020) on the Issue Tracker

by Marcus Denker

This week a bit early due to holidays. We nevertheless manged to merge around 30 Pull Requests. The next issue tracker log will be send in 2021. Debugger ======== - Debugger fuel out stack command #8141 https://github.com/pharo-project/pharo/pull/8141 - 8135-When-executing-a-doit-against-a-context-the-class-is-not-correct #8136 https://github.com/pharo-project/pharo/pull/8136 Fluid Class Definition ================= - 8143-Cleaning-Fluid-Builder #8144 https://github.com/pharo-project/pharo/pull/8144 - 8150-Trait-creation-should-use-the-traitBuilder #8151 https://github.com/pharo-project/pharo/pull/8151 Improvements/Feature ================== - Switch to pharo-icon-pack v1.0.1-idea11 #8089 https://github.com/pharo-project/pharo/pull/8089 - Add a lint rule for classes to have no "Uncategorized" classes in the package #8033 https://github.com/pharo-project/pharo/pull/8033 Refactoring =========== - [RB] - Fix issue 4902, remove duplicated method #8147 https://github.com/pharo-project/pharo/pull/8147 - Fix Abstract instance variables issue #8138 https://github.com/pharo-project/pharo/pull/8138 Bug Fixes ========= - Fix class variable entanglement issue #8045 https://github.com/pharo-project/pharo/pull/8045 - 7984 - Change Sorter broken #8154 https://github.com/pharo-project/pharo/pull/8154 - Fixes in the Parser #8148 https://github.com/pharo-project/pharo/pull/8148 - Fix Morphic Shortcut Error handling #8156 https://github.com/pharo-project/pharo/pull/8156 - Fixes #6993 against P9: Incorrect error message on failed parsing of a number with high radix #6995 https://github.com/pharo-project/pharo/pull/6995 - Do not add DoIts to the cache. fixes #7955 #7959 https://github.com/pharo-project/pharo/pull/7959 - Add `visitSelectorNode:` #8163 https://github.com/pharo-project/pharo/pull/8163 Dead Code remove =============== - 8158-ContextquickStep-is-unused-and-strange #8159 https://github.com/pharo-project/pharo/pull/8159 - DelayBasicScheduler had debug code left from review #7990 https://github.com/pharo-project/pharo/pull/7990 - remove unused ivar DelayBasicScheduler #8164 https://github.com/pharo-project/pharo/pull/8164 - [fix] remove itemFilterName for the spotter, as it seems to be unusedâ¦ #6700 https://github.com/pharo-project/pharo/pull/6700 Cleanups ======== - RBMethodNode #pragmas is the only instance variable for AST children that has an accessor checking for nil #7979 https://github.com/pharo-project/pharo/pull/7979 - Fix testCreationByUnnamed #8165 https://github.com/pharo-project/pharo/pull/8165 - Tag uncategorized classes in package Refactoring-Tests-Core #8019 https://github.com/pharo-project/pharo/pull/8019 - Move business logic from new tools to system-support #7659 https://github.com/pharo-project/pharo/pull/7659 - 8127-FFICalloutAPITestmethod2-sends-non-implemented-call #8139 https://github.com/pharo-project/pharo/pull/8139 Pharo8 backporting =============== - backportIfErrorDo #6154 https://github.com/pharo-project/pharo/pull/6154 - Fixes #6993 against P8: Incorrect error message on failed parsing of a number with high radix #6994 https://github.com/pharo-project/pharo/pull/6994

Dec. 23, 2020

Re: Abut writeOn: versus storeOn:

by Sean P. DeNigris

StÃ©phane Ducasse wrote > I saw that a couple of collections implement writeOn: in addition to > storeOn: and I was wondering if someone knows > the reason. My gut feeling is that this is somehow dead code. #Part 1: Do we need writeOn:? I did some digging, but there was nothing conclusive to my eyes, although I "smelled" the same thing you did. I am documenting here in case it helps... One of the implementors is ShortIntegerArray. Its comment says it "is an array for efficiently representing integers in the 16bit range." Although it's in the Balloon package, its only user (other than objects that initialize it) seems to be FT2Outline. The other is ArrayedCollection, which has this comment for #writeOn: "Store the array of bits onto the argument, aStream. (leading byte ~= 16r80) identifies this as raw bits (uncompressed). Always store in Big Endian (Mac) byte order. Do the writing at BitBlt speeds. We only intend this for non-pointer arrays. Do nothing if I contain pointers." The header and mention of BitBlt make that comment seem similar to another implementor, Bitmap>>#writeOn: - "Store the array of bits onto the argument, aStream. A leading byte of 16r80 identifies this as compressed by compressToByteArray (qv)." Form and MatrixTransform2x3 are other implementors that seem related, as graphics artifacts. Then there is RunArray - a seeming outlier - and several Zinc classes. The clearest case seems to be Zinc, which seems to have this as a domain concept, and has senders and implementors. Other than Zinc, there are very few senders of the message. There is FLEncoder, which seems like it could be legitimate, but it sends the message from #encodeBitmap:, which is itself not sent. Same for Form>>#writeBitsOn: (no senders) The final sender is MCDataStream. #Part 2: What is the distinction between writeOn: and storeOn:? StÃ©phane Ducasse wrote > Because readOn: logic is the inverse of storeOn: and I was wondering what > is the equivalent for writeOn: I'm not sure that this part is correct. I think storeOn: is orthogonal, and #readOn: seems like the inverse from a native English perspective (e.g. Magritte uses the terms read/write), but there are no implementors of #readOn: in P8. There was a recent discussion about #storeOn: and whether it is still useful on Discord general channel. The most illuminating comment was: Martin McClure 12/01/2020 @svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80. Page 101 of the Blue Book says of storeString, "Answer a String representation of the receiver from which the receiver can be reconstructed." The representation is always Smalltalk source code, the "reconstruction" is evaluation by the compiler. Here are all the posts in chronological order: svenvc 12/01/2020 For the sake of discussion, what is a useful store string (for some standard class in the image) ? Esteban A. Maringolo 12/01/2020 For me a "store string" is an expression that instantiates the receiver back. ð SeanDeNigris 12/01/2020 For Morphs, off the top of my head, itâs actually really cool because you can re-create more from a prototype Esteban A. Maringolo 12/01/2020 But it's a weak serialization mechanism, or at least it is fragile. [8:44 AM] (recursions, etc.) SeanDeNigris 12/01/2020 I also use it to generate code in Magritte. The store string for the description is the expression that is returned from the descriptions getterï¿¼ Serializing blocks is a tough problem in general. I went through a lot of grief because fuel will let you serialized them but depends on the outer context not having changed to rematerialize, even for clean blocks, with no hook to fix things if it has changed, making data unloadable Esteban A. Maringolo 12/01/2020 It should only serialize clean blocks or give you a way to resolve the closures. @Esteban A. Maringolo For me a "store string" is an expression that instantiates the receiver back. svenvc 12/01/2020 yes, that is it, but by definition it means that it depends on the compiler. there is also no real specification of what the output looks like (like JSON, XML, STON, or any other textual/binary format). it feels quite weird. Esteban A. Maringolo 12/01/2020 I don't ask for specification, but historically storeOn: aStream always was "smalltalk" expressions. [9:11 AM] at least in my experience, and even "actual" use (not that I chose to use it, but a customer does). gcorriga 12/01/2020 #storeSting is useful when debugging, or when doing exploratory coding. [10:24 AM] e.g. I have a complex data structure, I can send #storeString to it to get a text representation I can use e.g in a unit test. Martin McClure 12/01/2020 @svenvc @Esteban A. Maringolo #storeString and #storeOn: are Smalltalk-80. Page 101 of the Blue Book says of storeString, "Answer a String representation of the receiver from which the receiver can be reconstructed." The representation is always Smalltalk source code, the "reconstruction" is evaluation by the compiler. Of course not all objects can easily be represented by source code, so in practice this message is most useful for objects that can be represented as Smalltalk literals. IMO we should preserve the storeOn: semantics for those objects, but other formats are more useful for general objects. svenvc 12/01/2020 Maybe we should add some more documentation then, as well as some illustrative unit tests/examples. ð 2 ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 23, 2020

[Pharo 8.0] Build #1145: backportIfErrorDo

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1145 was: FAILURE. The Pull Request #6154 was integrated: "backportIfErrorDo" Pull request url: https://github.com/pharo-project/pharo/pull/6154 Issue Url: https://github.com/pharo-project/pharo/issues/backportIfErrorDo Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 22, 2020

[Pharo 8.0] Build #1144: Fixes #6993 against P8: Incorrect error message on failed parsing of a number with high radix

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1144 was: FAILURE. The Pull Request #6994 was integrated: "Fixes #6993 against P8: Incorrect error message on failed parsing of a number with high radix" Pull request url: https://github.com/pharo-project/pharo/pull/6994 Issue Url: https://github.com/pharo-project/pharo/issues/6993 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 22, 2020

Progress Report -> Refactoring Project - ( December 14 - 18 )

by EVELYN CUSI LOPEZ

Hi all, Last week I did these tasks: - Pair programming with Pablo, to understand how use commander2 with calypso. By the moment this only works in source code context, some similary methods can be created to use commander2 in class, variable and method context. - Fix duplicated method issue ( https://github.com/pharo-project/pharo/pull/8147 ) - Fix all abstract instance variables issue ( https://github.com/pharo-project/pharo/pull/8138) - Continue fixing Extract method and ocurrences issues, I separated middle interactions with user (in Find and replace refactoring), to remove coupling between view and logic, but now I have some errors when I want use a composite refactoring. Tasks for this week: - Finish to fix Extract method issues, only logic part (removing views) - Migrate extract method to refactoring2. - Migrate command of extract method and occurrences to commander2 - Create extract setUp and tearDown refactoring only for TestCases - Fix undo refactoring issue (I already tried to correct, however I continue having some problems - https://github.com/pharo-project/pharo/compare/Pharo9.0...Lin777:FixUndoRef… ) - Add option to limit classes where we replace senders of method to other method (https://github.com/pharo-project/pharo/issues/8087) Cheers, Evelyn

Dec. 21, 2020

Re: Abut writeOn: versus storeOn:

by StÃ©phane Ducasse

I have the impression that it is a left over of the dataStream and that we can remove it. S > On 19 Dec 2020, at 22:02, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > Hi > > I saw that a couple of collections implement writeOn: in addition to storeOn: and I was wondering if someone knows > the reason. My gut feeling is that this is somehow dead code. > > Because readOn: logic is the inverse of storeOn: and I was wondering what is the equivalent for writeOn: > > > S > -------------------------------------------- > 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 > -------------------------------------------- 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

Dec. 19, 2020

Abut writeOn: versus storeOn:

by StÃ©phane Ducasse

Hi I saw that a couple of collections implement writeOn: in addition to storeOn: and I was wondering if someone knows the reason. My gut feeling is that this is somehow dead code. Because readOn: logic is the inverse of storeOn: and I was wondering what is the equivalent for writeOn: S -------------------------------------------- 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

Dec. 19, 2020

This week (51/2020) on the Issue Tracker

by Marcus Denker

FFI === - Integrating ThreadedFFI in the image. #8102 https://github.com/pharo-project/pharo/pull/8102 - fixing-initialization-of-ffibackend #8131 https://github.com/pharo-project/pharo/pull/8131 New Features ============= - Class>>#usesTrait: and Class>>#usesTraitTransitively: #8002 https://github.com/pharo-project/pharo/pull/8002 - ThemeIcons should have a #reset method #8050 https://github.com/pharo-project/pharo/pull/8050 Refactoring Engine =========== - 8079-RBRefactoringChangeTesttestAddMetaclassPattern-calls-definition #8107 https://github.com/pharo-project/pharo/pull/8107 - Fixing undo refactory #8051 https://github.com/pharo-project/pharo/pull/8051 Fixes ===== - 8129-Debugger-should-log-the-exception-always #8130 https://github.com/pharo-project/pharo/pull/8130 - Fixed #6391. Filed out methods are now saved into files that have colons in their names #7888 https://github.com/pharo-project/pharo/pull/7888 - Correctly decode file names from SDL2, at SDL2 #8116 https://github.com/pharo-project/pharo/pull/8116 - 8117-RBMethodNode>>methodClass-should-gard-for-nil #8118 https://github.com/pharo-project/pharo/pull/8118 - Bootstrapper in 64 and 32 bits #8064 https://github.com/pharo-project/pharo/pull/8064 - Make use of current working directory primitive on windows #8070 https://github.com/pharo-project/pharo/pull/8070 Graphics ======== - Moving the responsibility to the OSWindowDriver #8123 https://github.com/pharo-project/pharo/pull/8123 - 8086-RSLabelTest-Could-not-find-accessor-for-variable-named-anUTF8EncodedString #8104 https://github.com/pharo-project/pharo/pull/8104 - Enh/win32 athens #8069 https://github.com/pharo-project/pharo/pull/8069 Fluid Class Definitions ======================= Work continous: cleanups and fixes - 7923-Broken-traits-definitions #8046 https://github.com/pharo-project/pharo/pull/8046 - 8122-Expanding-a-class-does-not-respect-superclass #8137 https://github.com/pharo-project/pharo/pull/8137 - ClassParser-reduce-NewUndeclaredWarning #8121 https://github.com/pharo-project/pharo/pull/8121 - 8073-glitch-in-package-template #8106 https://github.com/pharo-project/pharo/pull/8106 - 8036-Spotter-uses-definition-for-class-instead-of-definitionString #8043 https://github.com/pharo-project/pharo/pull/8043 - 8098-definition---definitionString #8099 https://github.com/pharo-project/pharo/pull/8099 - 8080-TraitTesttestPrintingClassSide-is-calling-definition #8091 https://github.com/pharo-project/pharo/pull/8091 - 8078-EpHasImpactVisitorvisitBehaviorChange-calls-definition #8090 https://github.com/pharo-project/pharo/pull/8090 - 081-EpCodeChangeIntegrationTesttestRedundantClassDefinition-calls-definition-and-more #8096 https://github.com/pharo-project/pharo/pull/8096 - 8071-Replying-a-class-definition-with-Epicea-and-fluid-class-does-not-recreate-the-class #8072 https://github.com/pharo-project/pharo/pull/8072 Cleanups Dead Code ================== - Cleanup-ClassOrganization-listAtCategoryNumber #8126 https://github.com/pharo-project/pharo/pull/8126 - SlotScope-DeadCode-Clean #8105 https://github.com/pharo-project/pharo/pull/8105 Cleanups ======= - RBProgramNode>>#doSemanticAnalysis should be correctly packaged #8110 https://github.com/pharo-project/pharo/pull/8110 - Cleanup Variable class comment #8112 https://github.com/pharo-project/pharo/pull/8112 - Small typo in ReExceptionStrategy class comment #8093 https://github.com/pharo-project/pharo/pull/8093 - Typo in handle:about:forProppertiesDo: #8095 https://github.com/pharo-project/pharo/pull/8095 - Move ArrayTest to Collections-Sequenceable-Tests #7995 https://github.com/pharo-project/pharo/pull/7995 - 8075-RunArray-is-not-an-abstract-class #8076 https://github.com/pharo-project/pharo/pull/8076 - TestSkip should be TestSkipped #7997 https://github.com/pharo-project/pharo/pull/7997 - Remove unused ivars in DrTest packages #8085 https://github.com/pharo-project/pharo/pull/8085 - Typo in Path class method name delimeter #8048 https://github.com/pharo-project/pharo/pull/8048 - Cleanup Renraku-Help package #8059 https://github.com/pharo-project/pharo/pull/8059 - Mark abstract classes in Renraku #8061 https://github.com/pharo-project/pharo/pull/8061 - RBGenericNodeVisitor-tests #8067 https://github.com/pharo-project/pharo/pull/8067 Pharo 8 ======= - Backport to ease Moose loading #8124 https://github.com/pharo-project/pharo/pull/8124

Dec. 18, 2020

[Pharo 8.0] Build #1143: Backport to ease Moose loading

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1143 was: FAILURE. The Pull Request #8124 was integrated: "Backport to ease Moose loading" Pull request url: https://github.com/pharo-project/pharo/pull/8124 Issue Url: https://github.com/pharo-project/pharo/issues/backport Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 16, 2020