- Pharo-dev - lists.pharo.org

Slow writing to Transcript (stderr) in Windows 10 PharoConsole.exe -headless

by Christopher Fuhrman

Hello, I encountered a performance bug in Pharo 6 under Windows 10 with Moose, starting from the Moose 6.1 (beta) image in Pharo Launcher. I migrated my code from Pharo 5 and it uses a PharoCommandLineHandler to load an MSE file, which sometimes has many (15K) warnings/errors. It was taking over a minute to run something that in Moose takes only a few seconds. To debug and make a minimal example, I removed the Moose file part of my CommandLineHandler and simulated the writing of errors (i/o) with a loop. I believe the I/O to the stderr is why the performance is bad. In Windows 10 Task Manager, I can see that the process is not using much CPU. As I recall, my code didn't have this performance problem in Pharo 5. The command in windows to execute my minimal sample is something like: C:\Users\me>Documents\Pharo\vms\61-x86\PharoConsole.exe -headless "C:\Users\me\Documents\Pharo\images\Moose Suite 6.1 (beta)\CommandHandler VM slow bug.image" mooseminer --msefile blah The last part (--msefile blah) is needed because I didn't want to remove the argument validation. Here's a copy of the image: https://www.dropbox.com/s/7cgt37lef2xh2ut/CommandHandler%20VM%20slow%20bug.… A workaround is to run without -headless (or to not have so many errors). I hope this is useful to someone. For RMOD people I'm happy to demo this on my machine. Cheers, -- Christopher Fuhrman, P.Eng, PhD *Professor in the DÃ©partement of Software and IT EngineeringÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Sven Van Caekenberghe

> On 7 Nov 2018, at 10:27, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Alex, > > > On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: >> >> Hello, >> >> When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... > > This looks like your image changes the definition of > Number>>raisedToInteger: somewhere along the line. In the standard > image it doesn't call #run:with:in:. I don't think that definition got overwritten, check the implementers of #run:with:in: is seems to have to do with meta links or proxies or something like that ... > HTH, > Alistair >

Nov. 7, 2018

Re: [Pharo-dev] Infinite error recursion while saving Pharo70 alpha

by Alistair Grant

Hi Alex, On Wed, 7 Nov 2018 at 10:16, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > Hello, > > When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... This looks like your image changes the definition of Number>>raisedToInteger: somewhere along the line. In the standard image it doesn't call #run:with:in:. HTH, Alistair

Nov. 7, 2018

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

by Esteban Lorenzano

It is not so easy. A huge project as Pharo would profit to be split in order to manage its parts correctly. For example, we recently released iceberg 1.3.0. And there were some problems around and we evaluate the possibility of revert that release until we fix the problems. At the end, problems were not so important and the fix was made with a 1.3.1 release and almost immediately an 1.4.0. Now, imagine If iceberg would be integrated in pharo. 1. The nature of âicebergâ would be lost in other parts. We cannot talk anymore of releasing 1.3.1 or whatever, we just release Pharo. No clear way to know what changed in Iceberg without digging in the full list of changes. 2. If we need to revert. How do we do it? There is no release so what do we revert? A commit? How many commits? How do we revert if development tree continued growing and iceberg commit are now mixed with others? Of course, we could maintain a branch. But then I'd argÃ¼e is more or less the same as having a separated project. Situation is not ideal (even if it is a lot better as before). But Iâm envisioning this solution: add multiple source directories capability. Then we can have: src/kernel src/system src/spec src/iceberg src/calypso etc. This will not just help to improve modularisation but weâll gives a âfreeâ feature : using git subtree to manage those directories. For those who do not know: subtree allow us to merge different project trees into one. But the important part is how it will behave in Pharo (or other projects adopting it): For Pharo it will be JUST ONE REPOSITORY. So one single commit will spread to all repositories. Now, the âprice to payâ later is that time to time we need to push subtree from Pharo to their external projects (but this can be automated easily), and of course, doing âan iceberg releaseâ means to do a pull subtree from external repository to Pharo (also very easy). Esteban Ps: remember: programming is an iterative improving process. âProcess" is part of programming so iterations applies to it too. > On 7 Nov 2018, at 07:02, Tim Mackinnon <tim(a)testit.works> wrote: > > Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). > > When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. > > I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). > > For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. > > I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. > > Tim > > Sent from my iPhone > >> On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: >> >> 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. 7, 2018

[ANN] Iceberg v1.4.0

by Cyril Ferlicot

Hello! This week we are releasing the version v1.4.0 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0) This version is available in the latest Pharo 7. This release fixes a bug introduced in v1.3. It also add new features in the repository view, add some cleaning and also re-introduce a feature that was lost. Thanks to all contributors. Enjoy! Full changelog: Bugfixes #1068 'There is no associated repository configured.' warning on right clicking missing repository Features #1077 Repository view: Allow to collapse branches/remotes/tags trees #847 Move tags under remotes in Repository view #1070 set upstream if missing Cleanups #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest" #1015 Replace usages of Glamour in the Github Plugin #1063 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons -- Cyril Ferlicot https://ferlicot.fr

Nov. 7, 2018

Infinite error recursion while saving Pharo70 alpha

by Aliaksei Syrel

Hello, When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... [image: Screen Shot 2018-11-07 at 09.55.07.png] VM: Mac OS - x64 - 1013.5 - CoInterpreter VMMaker.oscog-eem.2461 uuid: > b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 31 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: > 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 31 2018 > VM: 201810311808 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Date: Wed Oct 31 11:08:29 2018 CommitHash: c7a9b1f Plugins: 201810311808 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Image: Pharo7.0.0alpha [Build information: > Pharo-7.0.0+alpha.build.1361.sha.011b7c939adeb52338baad16a694cab2e7a54d74 > (64 Bit)] Cheers, Alex

Nov. 7, 2018

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

by Tudor Girba

Excellent! Doru > On Nov 5, 2018, at 4:11 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 -- www.feenk.com "Speaking louder won't make the point worthier."

Nov. 7, 2018

Re: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules

by Shaping

Hi Eliot. Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder whether there is any issue here. STON would use the print strings for (PSC) Float / (VW) Double, and so deseerialization on Pharo would automatically produce the right class. Going in the other direction might need some help. APF needs support in PSC before one can port, but are representable as suitably-sized word arrays. There is no support for __float128 anywhere in the VM (e.g. not even in the FFI) on PSC as yet. I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. Iâm using APFs in VW in the 300-bit range, and want to reduce the needed precision to 64 bits, to save space and time on large (5 million+) scalar time-series, both on the heap and during BOSSing (25 m save-time now). The problem is not so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). Other calculations need the more extreme precision. I think I can make 128-bit floats work, and would really like to see a small, fast, boxed 128-bit float implementation in Pharo or VW. The APFs are big and slow. Where in the queue of planned improvements to Pharo does such a task lie? I suspect itâs not a very popular item. Broadening the issue somewhat, Iâm trying to find as many good reasons as possible to justify the work needed to port all my VW stuff to Pharo. Iâve seen the references to Cogâs speed and coming speed-up. Are there recent (say, in the last year) benchmarks comparing VW and Pharo? Any details here would be very much appreciated. Having no namespaces in Pharo is, I think, the biggest impediment. I prefer not to prefix class names, but there may be fewer name-collisions than I suppose--maybe none. Still, I need to know how VW and Pharo classes map in order to place overrides and extensions correctly. Besides the mentioned float-class mappings is there a reference on this? Object allSubclasses in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than it used to be. I suppose I donât need to check all unloaded packages because all classes in each of those will have the same unique prefix. Is that correct? Or, I could just load every package I can find, before I check names. But that little experiment has never gone well in the past. Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more fitting idea than what VW currently offers? Shaping On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: STON is able to serialise Pharoâs Floats, what do you mean by double ? Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with a range between =10^307 and 10^307. Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). APFs are binary representations that can be arbitrarily large, using Integers (LargePositiveIntegers for example) to model the bits of the mantissa. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. â¦.. Number subclass: #Float instanceVariableNames: '' classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree Sqrt2 ThreePi Twopi' poolDictionaries: '' category: 'Kernel-Numbers' My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307. Some valid examples are: 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 â¦. I see that Pharoâs Float is VWâs Double. So then I just need to be able to serialize APF. â¦. FIFloatType subclass: #FFIFloat128 instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'UnifiedFFI-Types' I'm a 128bits (cuadruple precision) float. It is usually not used, but some compiler modes support it (__float128 in gcc) THIS IS NOT YET SUPPORTED â¦. The class above is also from the Pharo 7 image. This is the largest of the c-type FFIFloats. Any Float classes of this size and larger for the Smalltalk heap on 64-bit Pharo? Cheers, Shaping Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > a Ã©crit : (Having domain problems recently. Please excuse this posting if you have seen it twice. I've not seen it appear yet on the list.) Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Shaping -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of David T. Lewis Sent: Wednesday, October 31, 2018 14:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification This is very clear and well written. Dave Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc cessfulBuild/artifact/book-result/STON/STON.html Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,,,^..^,,,_ best, Eliot

Nov. 7, 2018

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

by Tim Mackinnon

Itâs a tricky trade off as Norbert alludes too - in my recent example I needed some underlying base pieces in place (for the compilerâs ast) and those needed reviewing to then be committed - then there were two parts to Calypso that relied on those changes) that also needed reviewing and I wasnât sure if Denis waited for the core approval or loaded up my PR - but anyway it took him a bit of time to process that and he came back with some better suggestions that I also needed to implement (which I had to find time to do as well). When I noticed that the core Pharo pieces were merged, I then had to chase Denis to see if he was now happy and could merge my changes. I guess it would be helpful if there was a way to easily load up multiple project prâs in one go (like the suggested slice concept) so maintainers can easily review. Probably more importantly is an easy way to track the status of multiple submissions so you can follow up with relevant people and push things along and also ensure things get committed in the right order (eg doc the dependency chain a bit better). For me, after a few days I forgot about my Calypso changes and realised a few weeks later (by accident) and so could chase Denis. I think itâs this latter case that Steph alludes to - you lose interest after a few days without some useful prompts and easy status tracking. If we can make that easier I think it would help. Tim Sent from my iPhone > On 7 Nov 2018, at 05:48, Ben Coman <btc(a)openinworld.com> wrote: > > 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. 7, 2018

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