Nicolas We want to keep the live part of Pharo and incremental loading and it is key for us. Now we should not be naive. Most of the time we do not have the garantee that a change will work when loaded.
We proposed Pablo to work since two years on a really working dynamic code loader and Pablo has really nice results. But it takes time to evaluate if/how we integrate its changes. Pablo has an atomic coder loader and an incremental and modular class builder. He also designed a modular shutdown/startup list manager (in production). We want to be able to have a **real** and robust incremental load. Right now as you know it and as in ANY smalltalk I can break the system super easily. There is no magic. I do not see how we can make sure that any piece of code will be loaded and do not break the system. So our objective is to have a new infrastructure that we can updates (like method hashes for example without having to twists our mind and do five updates). Now about git, we want and we will have our lovely image as a working directory but this requires engineering because the image is another artefact that other languages do not have to worry. We will get there. Stef On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier <[email protected]> wrote: > > > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <[email protected]>: >> >> My four wishes, in no particular order: >> - Better code completion >> - Git in Pharo as easy as using Git for other languages > > The recipe is easy: turn pharo into a file based edit-compile-run language > and expunge those live object burden ;) > Let me explain why it's not just trolling. > Currently we have to download an image made by a bot. > Pharo has gradually lost the power to upgrade the image (it's not new). > > If we recognize that an image acts like a workspace, and want to let the > pull/branch switch/etc work again... > IOW going from one point to any other in source code graph > and experience the full power of git like any other language, > that means, in a live IDE, at least solving those two problems: > - changing the tools that are used to upgrade the image (Compiler, > MethodDictionary, Array, etc...) > - correctly initialize all the states (including stange loops) > If pharo has not managed to solve this with a linear one way history (the > regularly broken update image option), > how do you think this is going to be solved in the more general case? > I call this the universal boostrap problem. > > IMO the logical next step is to separate the IDE > (the Inanimate Desintegrated Environment of any other language). > > Maybe we don't have to bend Pharo too much to git if it does not fit. > The goal: as easy might be not that easy. > > >> - Bloc on Steroid >> - Being able to interrupt any process and endless loop using Cmd-. >> >> Merry Christmas to all of you! >> Alexandre >> >> >> >> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <[email protected]> >> > wrote: >> > >> > Hi everybody, >> > >> > This looks like a good moment of the year to ask all of you what would >> > you want to see in Pharo next year. >> > Features, improvements, radical changes, etc…. whatever you want. >> > >> > Of course, this list will not be a roadmap and it does not means we will >> > implement all of it (as always, time drives our possibilities), but is a >> > good moment for us a a community to check where we are and where we wan to >> > go next :) >> > >> > So, let’s those wishes come! >> > >> > cheers, >> > Esteban >> >> >
