- Pharo-dev - lists.pharo.org

[Pharo 9.0] Build #340: pushOuterVectors-use-tempVectorVarNames

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

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

June 5, 2020

[Pharo 8.0] Build #1140: 6418-Backport-5643-into-Pharo8

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

There is a new Pharo build available! The status of the build #1140 was: SUCCESS. The Pull Request #6429 was integrated: "6418-Backport-5643-into-Pharo8" Pull request url: https://github.com/pharo-project/pharo/pull/6429 Issue Url: https://github.com/pharo-project/pharo/issues/6418 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 5, 2020

[Pharo 9.0] Build #339: Created a simple and a complex test for the changes file flushing issue

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

There is a new Pharo build available! The status of the build #339 was: FAILURE. The Pull Request #6492 was integrated: "Created a simple and a complex test for the changes file flushing issue" Pull request url: https://github.com/pharo-project/pharo/pull/6492 Issue Url: https://github.com/pharo-project/pharo/issues/6491 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 5, 2020

[Pharo 9.0] Build #338: 6049-It-should-not-be-possible-to-use-super-as-something-else-than-the-receiver-of-a-message

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

There is a new Pharo build available! The status of the build #338 was: SUCCESS. The Pull Request #6482 was integrated: "6049-It-should-not-be-possible-to-use-super-as-something-else-than-the-receiver-of-a-message" Pull request url: https://github.com/pharo-project/pharo/pull/6482 Issue Url: https://github.com/pharo-project/pharo/issues/6049 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

June 5, 2020

Re: [Pharo-dev] Discoverability

by Denis Kudriashov

Hi Sean. Ð¿Ñ, 5 Ð¸ÑÐ½. 2020 Ð³. Ð² 16:15, Sean P. DeNigris <sean(a)clipperadams.com>: > I had a "simple" goal: to change Calypso's class pane to a tree. After an > hour or two, I didn't feel any closer! > I implemented it in very early stages. But I did have time to implement it in a better way. The old code is still there. But I did not expose it to the browser widgets API. Try to replace following line in ClyFullBrowser>>switchToFlatClasses classView showQueries: classQueries as: ClyExtensionLastSortedClasses hierarchical with: fullQuery := ClyQuery unionFrom: classQueries as: ClyExtensionLastSortedClasses hierarchical. classView initiateUIChangeBy: [ dataSource := ClyExpandedDataSource on: fullQuery. classView dataSource: dataSource. classView ensureSelectedItemIfNeeded]. The trick is to use ClyExpandedDataSource instead of ClyCollapsedDataSource. The former is responsible to provide expansion to predefined internal tree structure (which you see in default browser). I wanted to merge them but I had no time for that. I thought to myself, > packages are already in a tree, let me dig there! I got a bit worried when > I > saw what seemed to be a mini-DSL for tree making instead of simple message > sends: > ClyFullBrowser >> #newPackageView > ... > treeStructure: { > ClyProjectChildItem -> > #prepareProjectItemsQueryFrom:in:. > RPackage -> #prepareClassGroupQueryFrom:in: }; > But I pressed on and tried to duplicate that logic: > ClyFullBrowser >> #newClassView > ... > ^ self newNavigationView > treeStructure: { > Class -> #prepareProjectItemsQueryFrom:in: } > You were in the right direction. But there is a little detail here. By default your code would work for domain objects in the list (not a class view). But the problem with classes and methods lists is to support the Ring model where classes are not instances of Class and methods are not instances of CompiledMethod. My solution was to have a data type for query items. By default it is an actual class of objects. But for classes and methods I introduced ClyClass and ClyMethod to address the Ring case. So try following in your experiment ClyClass -> #prepareProjectItemsQueryFrom:in: And you should have a debugger. I wonder, did you try a halt in #treeStructure users . I think it would help to discover this logic. Denis ... > > And... nothing. When #prepareClassItemsQueryFrom:in: didn't exist, I got no > debugger. When I created it, placing a halt in it never got triggered. > > Besides my immediate experiment of making the class pane a tree, my more > fundamental questions are: > 1. What is the best heuristic to explore the system? This would be great to > put somewhere publicly. Especially, but as we can see from this post not > exclusively, for new users. > 2. Do we value discoverability? > 3. If so, are we designing our system with this value in mind? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

June 5, 2020

Discoverability

by Sean P. DeNigris

I had a "simple" goal: to change Calypso's class pane to a tree. After an hour or two, I didn't feel any closer! I'm wondering if it's my process or something else. A few questions: 1. Is there a heuristic for finding relevant documentation? We have lots of docs, but there seem to be a lot of separate locations for it. I think I searched on the Nabble ML mirror for "Calypso" posts on either Pharo list. After digging around, I found a discussion where Steph was working on a [] booklet, which I read and was helpful for understanding the model but didn't directly address my issue (not that it should, this is pretty low-level hacking!). Then I tackled the class comments, which are VERY thorough, but it's hard (at least for me) to piece together the overall design from the individual parts. 2. How do we make sophisticated designs discoverable? I remember one of my Aha! moments when I discovered Smalltalk was using Morphic halos on a menu item and easily finding the code it used underneath. Things like that do not generally seem possible anymore in my experience. I thought to myself, packages are already in a tree, let me dig there! I got a bit worried when I saw what seemed to be a mini-DSL for tree making instead of simple message sends: ClyFullBrowser >> #newPackageView ... treeStructure: { ClyProjectChildItem -> #prepareProjectItemsQueryFrom:in:. RPackage -> #prepareClassGroupQueryFrom:in: }; But I pressed on and tried to duplicate that logic: ClyFullBrowser >> #newClassView ... ^ self newNavigationView treeStructure: { Class -> #prepareProjectItemsQueryFrom:in: } ... And... nothing. When #prepareClassItemsQueryFrom:in: didn't exist, I got no debugger. When I created it, placing a halt in it never got triggered. Besides my immediate experiment of making the class pane a tree, my more fundamental questions are: 1. What is the best heuristic to explore the system? This would be great to put somewhere publicly. Especially, but as we can see from this post not exclusively, for new users. 2. Do we value discoverability? 3. If so, are we designing our system with this value in mind? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

June 5, 2020

[Pharo 9.0] Build #337: emitStore-do-not-use-Object-new

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

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

June 5, 2020

Re: [Pharo-dev] PROPOSAL: UN-St (United Nations of Smalltalk)

by Sean DeNigris

Thank you for your feedback on all three MLs. Here are three important clarifications: 1. My idea is actually very small and humble. Maybe âDialect Ambassadorsâ would better capture the intent. Although my title was grandiose, I meant it in the âJ.C.R. Licklider Intergalactic Networkâ sense because people tend to deliver the minimum ha ha. My actual proposal/idea is not to "reinvent XYZ", or "merge Squeak, Pharo, and Cuis into one layered system" - although Iâd be overjoyed if any of that happened :) My proposal is simply to have a group of 1+ representatives from each community who believe in the importance of sticking together enough to remain calm and objective to resolve misunderstandings before they explode. Of course, there may be unintended positive consequences, like âhey, did you see the improvements we made to ABC? You may want to steal that!â 2. âWe tried that when we XYZ and ABC ruined it by ____â. Yes, Iâve been a despondent bystander during many of these. Thatâs exactly what Iâm trying to repair! Maybe the next one will succeed if we have some facilitators who are objective and impartial who can go to ABC and say, âso-and-so is worried you might be thinking about doing _____. What about XYZ isnât working for you?â Etc, Etc. Who knows, maybe we could even get one of these stalled initiatives back on trackâ¦ 3. "Why not include dialect ABC, and XYZ, too?â Thereâs really no reason to exclude anyone. The reason I specifically included Squeak, Pharo, and Cuis is that, as more immediate family members, we seem to experience more "sibling rivalryâ. I just happened to personally know of a need in these cases (especially the first two). In fact, after some of the responses, I realized that I probably should have included Gemstone, which is clearly an important part of our shared ecosystem; again, I only left them out because Iâm not aware of any problems there! Since there is interested, and not to distract too much from the Dev MLs, maybe we could just pick a place for interested parties to âmeetâ. Iâm familiar with Discord (which Pharo uses), which is free but not threaded (and so can get confusing for long-running topics). Any other suggestions? - Sean

June 5, 2020

Re: [Pharo-dev] question about Zinc ZnUrl or ZnResourceMetaUtils

by Sven Van Caekenberghe

https://github.com/svenvc/zinc/commit/7a42881f14144e0d9dcc2b3aa98a075f189ea… > On 4 Jun 2020, at 23:06, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Theoretically, the order is not important (should not matter), but for practical purposes (like being able to parse a URL and print it to the same representation) it would be a good idea. > > I'll see if I can add it. > >> On 28 May 2020, at 11:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Hi sven >> >> Are the dictionaries for the query part conserving the order? >> Because this would be really nice. >> >> 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 >> >

June 5, 2020

[Pharo 9.0] Build #336: Fix https://github.com/pharo-vcs/iceberg/issues/1331

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

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

June 5, 2020