- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Norbert Hartl

> Am 06.11.2018 um 19:54 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > > Calypso is integral part of Pharo as Iceberg. > We started to discuss the problem in the team. Right now this project > spread kills us. > It is not an easy decision. Either you bind everything closely to you and ease your workflow but have to do everything on your own. Or you welcome external projects not done by you and you enter modern dependency hell. Choose wisely or just try to solve the real problem. You neither have the time to develop everything by yourself nor have the patience to spend time on dependencies. Norbert > Stef >> On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: >> >> Tim Mackinnon <tim(a)testit.works> wrote: >>> >> >>> In retrospect, Iâm wondering if successful projects that have proved >>> integration usefulness should be moved into the core repo? >>> (Iceberg/Calypso?) or are we missing something to help easily track the >>> journey of a multi faceted change (although this sounds overkill?). Or >>> are there sprint days to try and knock these things through easily with >>> everyone on board to do it together? >>> >>> We are sort of damned if you do and damned if you donât. But certainly we >>> want to endure that progress can be made without losing the will to contribute. >>> >> >> Indeed. Putting things in one repo cannot scale and cannot be a solution >> for something that is neither core pharo nor an application. I encourage >> everyone who wants to get a good description of this problem to read >> >> "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration >> Management, and Product Data Management" by Peter van den Hamer & Kees >> Lepoeter. >> >> With git and github a solution to decouple fast-moving from slow-moving >> projects seems to be indeed to fork and make PRs. >> That only works if the quality of the PRs is high enough and we manage to >> use the feedback from slower-moving projects well. >> >> Earlier, weâve seen projects like Magma being overwhelmed by the number of >> needed changes, and Pier being broken by Pillar not respecting its >> constraints. >> >> With tools like Travis, it is quickly clear if a PR would result in a green >> build in the original repo. >> >> With projects where Pharo uses only the core, and applications use more >> than that, the applications still have a dependency problem: if the core >> changes in Pharo influence the other parts, someone needs to do the work to >> make those parts work again. With forked repos, that can be a pharo >> maintainer, the project maintainer or the application maintainer. All three >> need to be able to make those changes. And they need to be decoupled from >> having to make them immediately. And being able to have the discussion >> about the exact implementation independently from implementing a stop-gap >> solution now is also valuable. >> >> So if Calypso is supposed to be extendable and only the core part is part >> of Pharo, having it as an external project makes sense. With a fork for >> Pharo to move at its own speed. If Iceberg is Pharo-only, just having >> different branches for different Pharo versions, it sounds to me like it >> might be better of in the Pharo project. Tonel is supposed to be >> cross-platform so should be separate. >> >> Is this helpful? >> >> Stephan >> >> >> >

Nov. 7, 2018

Re: [Pharo-dev] Porting from VW to Pharo

by Davide Grandi

Do you have name collisions among your namespaces, now ? If not ... problem solved, otherwise maybe you could refactor the classes clashing. Or, maybe, I'm missing some points. Â Â Davide Grandi On 06/11/18 07:23, Shaping wrote: > Can someone point me to the best tools for porting from VW 7.10 to > Pharo 7 64-bit (or maybe 6.1)? > > I'm not sure what to do about the namespaces. I realize that VW's > namespace solution is just a good hack and that the true nature of the > problem runs much deeper--but it does a good job of avoiding > class-name collisions, which is mostly what I need it for, and I can > control exactly how imports work. > > Any suggestions are welcome. > > Thanks. > > Shaping -- Ing. Davide Grandi email : davide.grandi(a)mclink.it mobile : +39 339 7468 778

Nov. 6, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Ben Coman

I get the feeling what is needed is mirroring all dependent repos from the canonical location under http://github.com/pharo-project and a Slice-like tool (probably keeping the name "Slice") which... 1. Pulls all dependent repos to the local machine 2. Simultaneously commits to the local repos with the same commit message 3. Updates a bootstrap-configuration file holding commit-hashes of all the dependencies and commits with same commit message 4. Pushes that bootstrap-configuration file and all changed dependent repos to user's github account 5. Issues a pull request for the bootstrap-configuration file 6. Our CI then builds a test-image by commit-hash direct from each user's repo and if it passes, pulls dependent repo commits under pharo-project 7. CI can then issue PRs to the dependency canonical repos cheers -ben On Wed, 7 Nov 2018 at 02:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Calypso is integral part of Pharo as Iceberg. > We started to discuss the problem in the team. Right now this project > spread kills us. > > Stef > On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > > > > Tim Mackinnon <tim(a)testit.works> wrote: > > > > > > > > In retrospect, Iâm wondering if successful projects that have proved > > > integration usefulness should be moved into the core repo? > > > (Iceberg/Calypso?) or are we missing something to help easily track the > > > journey of a multi faceted change (although this sounds overkill?). Or > > > are there sprint days to try and knock these things through easily with > > > everyone on board to do it together? > > > > > > We are sort of damned if you do and damned if you donât. But certainly we > > > want to endure that progress can be made without losing the will to contribute. > > > > > > > Indeed. Putting things in one repo cannot scale and cannot be a solution > > for something that is neither core pharo nor an application. I encourage > > everyone who wants to get a good description of this problem to read > > > > "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration > > Management, and Product Data Management" by Peter van den Hamer & Kees > > Lepoeter. > > > > With git and github a solution to decouple fast-moving from slow-moving > > projects seems to be indeed to fork and make PRs. > > That only works if the quality of the PRs is high enough and we manage to > > use the feedback from slower-moving projects well. > > > > Earlier, weâve seen projects like Magma being overwhelmed by the number of > > needed changes, and Pier being broken by Pillar not respecting its > > constraints. > > > > With tools like Travis, it is quickly clear if a PR would result in a green > > build in the original repo. > > > > With projects where Pharo uses only the core, and applications use more > > than that, the applications still have a dependency problem: if the core > > changes in Pharo influence the other parts, someone needs to do the work to > > make those parts work again. With forked repos, that can be a pharo > > maintainer, the project maintainer or the application maintainer. All three > > need to be able to make those changes. And they need to be decoupled from > > having to make them immediately. And being able to have the discussion > > about the exact implementation independently from implementing a stop-gap > > solution now is also valuable. > > > > So if Calypso is supposed to be extendable and only the core part is part > > of Pharo, having it as an external project makes sense. With a fork for > > Pharo to move at its own speed. If Iceberg is Pharo-only, just having > > different branches for different Pharo versions, it sounds to me like it > > might be better of in the Pharo project. Tonel is supposed to be > > cross-platform so should be separate. > > > > Is this helpful? > > > > Stephan > > > > > > >

Nov. 6, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Chris Muller

> Earlier, weâve seen projects like Magma being overwhelmed by the number of > needed changes, I'm curious what you meant by this. I'm not aware of Magma ever having been overwhelmed. Its design has made it easy to be one of the most-available and consumable pieces of software for every version of Squeak from 2007 to today. Did you mean the Pharo port? It doesn't really do any magic, I'd be surprised if it would be very difficult to port to Pharo, but I don't know. - Chris

Nov. 6, 2018

Re: [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

by Esteban Maringolo

http://files.pharo.org/image/70/ ? Shouldn't this "unstable", "preview" or whatever you want to call it listed somewhere? In the web the link for files server is listed in the "Older versions" link. Regards, Esteban A. Maringolo El mar., 6 nov. 2018 a las 16:00, Stephane Ducasse (<stepharo.self(a)gmail.com>) escribiÃ³: > Where can we download it? because I would like to add it to the blog post. > > Stef > On Mon, Nov 5, 2018 at 4:12 PM Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > > > Greetings! > > > > Iâm announcing today we reach Pharo 7.0.0-rc1! > > > > This is the first step to release a definitive version, and while we > will continue integrating bug fixes, API change Pull Requests will be > delayed until the open of Pharo 8.0.0 development. > > Now, you would wonder what is the ChangeLog of this releaseâ¦ and answer > is we still do not have one (btw, we should find a way to automate this). > > > > Anywayâ¦ we are very close to release now :) > > > > Please download, test, report issues. > > > > Esteban > >

Nov. 6, 2018

Re: [Pharo-dev] [ANN] Pharo v7.0.0-rc1 released!

by Stephane Ducasse

Where can we download it? because I would like to add it to the blog post. Stef On Mon, Nov 5, 2018 at 4:12 PM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Greetings! > > Iâm announcing today we reach Pharo 7.0.0-rc1! > > This is the first step to release a definitive version, and while we will continue integrating bug fixes, API change Pull Requests will be delayed until the open of Pharo 8.0.0 development. > Now, you would wonder what is the ChangeLog of this releaseâ¦ and answer is we still do not have one (btw, we should find a way to automate this). > > Anywayâ¦ we are very close to release now :) > > Please download, test, report issues. > > Esteban

Nov. 6, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Stephane Ducasse

Calypso is integral part of Pharo as Iceberg. We started to discuss the problem in the team. Right now this project spread kills us. Stef On Mon, Nov 5, 2018 at 11:56 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > > Tim Mackinnon <tim(a)testit.works> wrote: > > > > > In retrospect, Iâm wondering if successful projects that have proved > > integration usefulness should be moved into the core repo? > > (Iceberg/Calypso?) or are we missing something to help easily track the > > journey of a multi faceted change (although this sounds overkill?). Or > > are there sprint days to try and knock these things through easily with > > everyone on board to do it together? > > > > We are sort of damned if you do and damned if you donât. But certainly we > > want to endure that progress can be made without losing the will to contribute. > > > > Indeed. Putting things in one repo cannot scale and cannot be a solution > for something that is neither core pharo nor an application. I encourage > everyone who wants to get a good description of this problem to read > > "Managing Design Data: The Five Dimensions of CAD Frameworks, Configuration > Management, and Product Data Management" by Peter van den Hamer & Kees > Lepoeter. > > With git and github a solution to decouple fast-moving from slow-moving > projects seems to be indeed to fork and make PRs. > That only works if the quality of the PRs is high enough and we manage to > use the feedback from slower-moving projects well. > > Earlier, weâve seen projects like Magma being overwhelmed by the number of > needed changes, and Pier being broken by Pillar not respecting its > constraints. > > With tools like Travis, it is quickly clear if a PR would result in a green > build in the original repo. > > With projects where Pharo uses only the core, and applications use more > than that, the applications still have a dependency problem: if the core > changes in Pharo influence the other parts, someone needs to do the work to > make those parts work again. With forked repos, that can be a pharo > maintainer, the project maintainer or the application maintainer. All three > need to be able to make those changes. And they need to be decoupled from > having to make them immediately. And being able to have the discussion > about the exact implementation independently from implementing a stop-gap > solution now is also valuable. > > So if Calypso is supposed to be extendable and only the core part is part > of Pharo, having it as an external project makes sense. With a fork for > Pharo to move at its own speed. If Iceberg is Pharo-only, just having > different branches for different Pharo versions, it sounds to me like it > might be better of in the Pharo project. Tonel is supposed to be > cross-platform so should be separate. > > Is this helpful? > > Stephan > > >

Nov. 6, 2018

Re: [Pharo-dev] Cannot use Zinc in Pharo7 anymore

by Stephane Ducasse

My problem is that this is a trivial change and I could fix everything in 2 min. Now I cannot. On Sun, Nov 4, 2018 at 11:43 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think we all want the same thing: being able to move quickly. It is just not clear how to do that. > > I saw that you tried a complex scenario in https://pharo.manuscript.com/f/cases/22626/Should-not-hardcode-CmdCommandAb… - I would not even known how to do that, I think. > > > On 4 Nov 2018, at 15:35, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > Just to share my pain with you. Try to change something in the API of Commander? > > I think that it will be nearly impossible. > > Because Iceberg/Calypso depend on Commander and they are all managed > > in different repositories. > > So it means > > - fork each > > - probably introduce automatic deprecation > > - do a PR for each of the subprojects (it means identify for each one > > if we should work on dev or master and being able to checkout > > the correct version which is not always possible) > > - then waits.....that may be each of the PR got integrated > > - now you lost total focus > > - if one day you recover what you were doing then and only then you > > may finish your change. > > > > Good luck. > > > > So to me the message is clear: stay away. > > And this is what I'm doing. > > We are damaging our agility on the altar of a pseudo modularity. > > > > So this is why I will focus on my tiny, uninteresting side projects. > > Stef > > On Sun, Nov 4, 2018 at 3:14 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> > >> Hi Sven > >> > >> I agree with you. Ideally we would like to have much better tooling > >> and process. > >> Now the last time we discussed with Guille and Pablo about it: they > >> estimated that this is over one year of work. > >> And right now we do not have this engineering time to invest on this > >> because other fronts need to be addressed. > >> Still this is really slowing us. This is simple: I stopped thinking to > >> improve something that touches external packages. > >> So I will not work on the trivial changes that would improve Calypso/Iceberg. > >> Why? Because this is tedious, boring, not rewarding. > >> So yes we can do easily with iceberg simple fix on not external > >> packages but as soon as > >> - you need to load latest dev version (which can be a different one > >> than the current one) > >> - update your repo > >> - fix > >> - do a PR > >> - .... wait for its integration > >> > >> So at the end we as a community can ask ourselves what is the reward > >> model for such shitty work? > >> And also what are we ready to give so that Pharo maintainers do such boring job. > >> > >> Right now without really doing it consciously I see myself doing > >> either stupid fix or working on side projects > >> and this is not a good long term approach because the core of Pharo > >> needs a lot of work. > >> > >> Stef > >> On Fri, Nov 2, 2018 at 12:24 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>> > >>> > >>> > >>>> On 2 Nov 2018, at 12:01, Norbert Hartl <norbert(a)hartl.name> wrote: > >>>> > >>>> Hi > >>>> > >>>>> Am 02.11.2018 um 11:15 schrieb Stephane Ducasse <stepharo.self(a)gmail.com>: > >>>>> > >>>>> Hi > >>>>> > >>>>> Pay attention the following email is not nice and politically correct > >>>>> but it is important for the speed of improvements in Pharo. > >>>>> > >>>> thanks for the disclaimer. It is important. I copy that because mine might be not political correct, too. > >>>> > >>>>> I think that we are doing our best when dealing with subproject code. > >>>>> Now if we are forced to publish each little changes > >>>>> on each subproject and wait that something gets integrated into each > >>>>> subproject, then I would prefer to stop Pharo and do something else. > >>>>> We cannot ask someone to stop in the middle of a massive super boring > >>>>> and feel like shit cleaning in addition to stop and > >>>>> please publish a PR and wait that it gets integrated and wait that > >>>>> Pharo integrates the new version. > >>>>> Let us be a bit serious and pro here. > >>>>> > >>>> I know this. And Iâm taking it serious because I want to talk about it. If you decide that you rather be offended then talk please do. I find it annoying that a lot of topics are washed away because someone is offended. That is just another way of killing communication although it is a state-of-the-art these days. > >>>> > >>>>> Or we should drop subprojects. Because changing Pharo is getting a > >>>>> painful. Imagine just a change cross cutting several subprojects. > >>>>> For example, I did not fix the use of deprecated classes in Iceberg > >>>>> because I got distracted by the where is the project hosted and I was > >>>>> not connected on a good web connection. I changed calypso and > >>>>> published to calypso but if the feedback loop is too long it means > >>>>> that > >>>>> we will prefer to work on our own projects (because we have also our > >>>>> own projects and there velocity is high and attractive). > >>>>> > >>>>> I think that with github support this is simple to get the changes. > >>>>> Finally I heard that large companies developing large projects using > >>>>> github are managing one single repo: no subprojects, with their own PR > >>>>> and sync. And us little guys with our super clever brains we will > >>>>> succeed adding more constraints on the table. > >>>>> How bold are we. I'm impressed by such level of arrogance. This is why > >>>>> I do not like that Pharo gets managed in various repo > >>>>> because it kills us. > >>>>> > >>>> Actually I was inquiring what everyone is doing to circumvent those problems (!!!). I have the same situation in my company. Iâm the one that is reluctant to go to monorepo because I donât like my code jailed in a project. But the effort we have to take in order to organize a stable and development version with a lot of external projects is killing us. So can we please talk about it? Pleeeeeaaassseee??? > >>> > >>> It is what it is today: there a some (a few) 'external' projects that are part of the pharo image. For those, (most) allow changes in the pharo image, while the maintainer of the external project merges them back upstream. That is indeed the fastest cycle for pharo itself, but more work for the maintainers. > >>> > >>> I believe the promise of Iceberg is that it would (maybe already is) just as easy to do pull requests against against any repo. The future solution then could be that each external project from the main image to their own repos. > >>> > >>> I want to add another aspect to this discussion: respect for the original authors and current maintainers. It is a *HUGE* amount of work to write, document, publish, support and maintain any piece of software over several years, across pharo versions. > >>> > >>>> Norbert > >>>> > >>>>> Stef > >>>>> On Fri, Nov 2, 2018 at 10:12 AM Norbert Hartl <norbert(a)hartl.name> wrote: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Am 02.11.2018 um 00:13 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On 1 Nov 2018, at 19:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>>>>>> > >>>>>>>> Norbert, > >>>>>>>> > >>>>>>>>> On 1 Nov 2018, at 18:12, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >>>>>>>>> > >>>>>>>>> I was planning on getting all changes to Zn/Zdc from pharo 7 back upstream (and to GitHub), but I did not yet get around to it. > >>>>>>>> > >>>>>>>> The current diff between Zn #bleedingEdge and Pharo 7 seems relatively minor, I will try to merge later tonight, at least the part in Zinc-Character-Encoding-Core that is causing you trouble. > >>>>>>> > >>>>>>> Norbert, > >>>>>>> > >>>>>>> I did a bunch of commits (both in the classic Zn MC repos as well as in GitHub) that should help you, it works for me in any case. Zn #bleedingEdge / HEAD is now in sync with Pharo 7 - it actually contains more. > >>>>>>> > >>>>>>> Could you please test ? > >>>>>>> > >>>>>> The first test I did was successful. There were popups for loading different zinc Versions but that is expected. I will test more today. Thanks for now. Can you please add tags in github for the version in smalltalkhub? Otherwise it is hard to switch. > >>>>>> > >>>>>> Norbert > >>> > >>> > > > >

Nov. 6, 2018

[Pharo 7.0-dev] Build #1369: 22636 - Integrate Iceberg 1.4.0

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

There is a new Pharo build available! The status of the build #1369 was: SUCCESS. The Pull Request #1956 was integrated: "22636 - Integrate Iceberg 1.4.0" Pull request url: https://github.com/pharo-project/pharo/pull/1956 Issue Url: https://pharo.fogbugz.com/f/cases/22636 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 6, 2018

Re: [Pharo-dev] Looking for a good shortcut for "contextual spotter"

by Esteban Lorenzano

> On 6 Nov 2018, at 15:44, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Yes, but I cannot fix the whole input event handler just to assign a shortcut ;) > > > Ps: *Yes*, to fix the event handler is in the TODO list. But if I jump to fix what is broken each time I found something I will be trap in an endless loop until I retire or die. > > The "problem" would be to assign a sub-optimal shortcut as a workaround for a bug. > > Not because it cannot be changed later, but because we all know nothing is as permanent as temporary solutions :) > > I like the Shift+Shift proposed, but I don't know if the current handler can process it. Nope :/ > > Esteban A. Maringolo >

Nov. 6, 2018