- Pharo-dev - lists.pharo.org

Re: Can anyone get recent Pharo9 builds to work on Linux?

by Danil Osipchuk

I can confirm text input is severely broken backspace/del (tried on Linux buster, but it seems to be an image problem) -- control characters themselves get inserted into text pane. Type a string into a pane, ex. '123456789', position cursor somewhere in the middle, press del/backspace/ left&right arrows. If you inspect the string you'll see control characters inside (evident at 'Items' tab) regards, Danil Ð²Ñ, 27 Ð´ÐµÐº. 2020 Ð³. Ð² 02:08, Martin McClure <martin(a)hand2mouse.com>: > If anyone can get recent (within the last week or so) 64-bit Pharo9 > images to work on Linux, please let me know how you did that! I've tried > everything I can think of and no luck. > > For the purposes of this query, "working'' means that you can open a > playground, type into the it, then backspace over what you've typed. > > If you can do that on Linux, this information would be much appreciated: > > * What build are you running? > * What VM are you running and where did you get it? > * How do you launch it? If from the command-line, what arguments? > > Thanks, > -Martin >

Dec. 27, 2020

Re: Can anyone get recent Pharo9 builds to work on Linux?

by Esteban Lorenzano

Hi Martin, I just did : wget -O- get.pharo.org/64/90+vmHeadlessLatest | bash ./pharo-ui Pharo.image And I had no problem at all (except a libgit2 version that will be fixed soon). I am using a Manjaro, but I do not see why it should not work on others. Esteban On Dec 27 2020, at 12:07 am, Martin McClure <martin(a)hand2mouse.com> wrote: > If anyone can get recent (within the last week or so) 64-bit Pharo9 > images to work on Linux, please let me know how you did that! I've tried > everything I can think of and no luck. > > For the purposes of this query, "working'' means that you can open a > playground, type into the it, then backspace over what you've typed. > > If you can do that on Linux, this information would be much appreciated: > * What build are you running? > * What VM are you running and where did you get it? > * How do you launch it? If from the command-line, what arguments? > > Thanks, > -Martin >

Dec. 27, 2020

Can anyone get recent Pharo9 builds to work on Linux?

by Martin McClure

If anyone can get recent (within the last week or so) 64-bit Pharo9 images to work on Linux, please let me know how you did that! I've tried everything I can think of and no luck. For the purposes of this query, "working'' means that you can open a playground, type into the it, then backspace over what you've typed. If you can do that on Linux, this information would be much appreciated: * What build are you running? * What VM are you running and where did you get it? * How do you launch it? If from the command-line, what arguments? Thanks, -Martin

Dec. 27, 2020

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. 23, 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. 20, 2020