Hi Ben,
On Sat, Oct 4, 2014 at 7:27 AM, Ben Coman <b...@openinworld.com> wrote: > Tudor Girba wrote: > >> Hi, >> >> Indeed, you are right about noting that the situation will look different >> in a couple of months from now. Please, let's discuss these problems again >> in 2 months. >> > > > My point was not to delay discussion, but just not let it get you down and > be tolerant... > * For those sending criticism, of the system being in flux as in > progresses. > * For those receiving criticism, when its comes from those using the > bleeding edge because of their faith in Pharo > * For third parties looking on, be confident that it will come together > for the release. I am not asking for delaying the discussion about the tools. I am simply saying that the situation will be much different in a couple of months after we have a chance of taking the feedback into account (already quite some changes were made and more are under way, like the menu). As a consequence, we should evaluate the need of having them in parallel with other tools at that time not now. > > The classic tools are still around. Furthermore, in the Settings, you >> have a Glamorous Toolkit category which allows you to switch the Inspector >> and the Playground off. >> > > > How hard would it be to run some parts of GToolkit in parallel with > existing tools, rather than on/off? I'd rather it stare me in the face > without boxing me in - to help me adapt in my own time. I tend to forget > about things I need to change a setting for. > It's not hard at all, but I believe it would defeat the purpose of the exercise at this point. First, I believe the problems being reported are actually minor and we should not overreact. Bare in mind that people mostly reacted to missing features, and not bugs (except for the messed up positioning of the cursor during completion) which is quite encouraging given the magnitude of the change. Second, when working on the latest version you want to exercise the new, not the old. The more options you allow to fallback to the old, the less stress will be applied on the new. And especially given that we are a small community, and that only a fraction of us actually works with the latest version, it would be highly unproductive to not focus on the new. Cheers, Doru > -ben > > > Cheers, >> Doru >> >> >> >> On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <b...@openinworld.com <mailto: >> b...@openinworld.com>> wrote: >> >> Thierry Goubier wrote: >> >> Le 03/10/2014 21:48, stepharo a écrit : >> >> >> On 3/10/14 17:07, Thierry Goubier wrote: >> >> Hi Esteban, >> >> I'm not sure my answer will please you or stef, and >> maybe I shouldn't >> voice it, staying being a "customer" instead of >> contributing "the way >> you want it". Hard words, but yours are hard too. >> >> I'd say simply that Pharo is successfull, fairly >> successfull for >> someone like me. It allows me to engage in complex work, >> in what I do >> best and what affords me to be paid and have the freedom >> to use Pharo. >> Some of those things suppose that I maintain and extend >> fairly complex >> packages on top of Pharo, and deal with permanent, >> multiple >> overlapping interruptions (meeting, administrative work, >> travels, >> etc...). >> >> >> Same here :) >> >> Pharo is great, it allows me to build a significant >> activity on top of it. >> >> Some of the consequences of that success? I'm looking at >> things that >> works now, not in Pharo 5, 6, or 7. I'm a bit frightened >> by grandiose >> rewritting attempts which will be usable in a version or >> 2, at best, >> and leave an unsatisfying "now" situation. I'll >> carefully evaluate >> what new stuff is integrated. New stuff I look to see if >> they are >> usable (libcgit integration, TxText) and what I see is >> stuff that >> builds on unstable core libs extensions (NativeBoost, >> Athens) >> >> Why Athens would be unstable? >> or nativeBoost? >> >> >> NativeBoost is not unstable for me, but why libcgit is on a >> bleeding edge NativeBoost version then? Athens is stable for me, >> but I believe that TxText requires a bleeding edge Athens. >> >> on top of an already unstable version (4.0), and I'm >> really not >> impressed by the software development process. >> >> >> what should it be? >> You know Igor will not be paid in a month from now, JB >> should find a job >> and esteban has two years to prove that the consortium flies. >> So if we do not clean the event and windowing systems, rick >> and thales >> will be in trouble. So we are fighting against time. >> >> >> Thales is not an easy customer :) I know; apart from parser >> know-how, there is nothing that I can sell outside (projects, >> etc..) about Pharo. And if I'm not successfull, then its no more >> Pharo for me. >> >> The end result is, when I see a bug, I'm already at >> least two versions >> behind you guys... >> >> >> Why. I do not get why Pharo 3 would be unstable and that far >> from Pharo 20. >> >> >> I'm on Pharo 3. Some of the stuff I'm interested is on Pharo 4 + >> bleeding edge version of core Pharo subsystem... two versions >> off from 3 for me. >> >> >> Remember, this Pharo 4 is alpha status. I think we had similar >> discussions about this time last year with Pharo 3, and it shaped up >> really well for release. >> >> >> >> Libcgit is like that: its Pharo 4 + Bleeding edge native boost >> not yet in Pharo 4 + libcgit (and from ESUG, I get that it will >> require an entire refactoring of Monticello and a complete new >> on disk format). It's really shaping up like a long, long term >> target. >> >> so there's nothing worth reporting. There is some >> progress on the way >> things are being done (thanks Marcus for doing the >> deprecation API >> backporting on 3.0) and not much on others (and I speak of >> methodology, not of new features being added on). >> >> If you have the feeling that I don't contribute the way >> I should or >> the way you would like, step back and ask yourself if >> this is not my >> "unspoken" way of me saying that I don't find a way to >> contribute, or >> that contributing effectively is too costly. >> >> And look! This is not a matter of resources, but maybe a >> matter of >> slowing down a bit, so that the poor community members >> with limited >> resources like me that are not full time on Pharo 4.0 >> development may >> catch up :) And please, no more rejection of feedback, >> even negative. >> It just gives me the feeling you are overstreched, and >> that Pharo has >> a problem setting its goals. >> >> >> Thierry, >> I do not have the impression that we go fast. >> You see we started Athens more than two years ago. It is a >> success for >> external tools like moose and Roassal but >> without TxText Athens will just be a nice package not change >> the face of >> Pharo and we will get there. >> >> >> I believe you're right about those; but I'd say that the way >> it's being done is a bit worrying. Why? >> >> Because for me, TxText is already more advanced than the current >> text editor: the ability to change the cursor, probably a better >> layout, etc... Should already been integrated, then, if its >> already better. But you still have the font bug that Alexandre >> complained about... how many months ago? So, as long as its not >> resolved, TxText can't be integrated (and additionally, I'm sure >> that there is aliasing issues on my machines: fonts in Roassal >> don't look as nice as in Morphic). >> >> And now, to make integration easier, we pile more stuff on top >> of the existing, bound to be removed, infrastructure: Glamour, >> Rubric, etc... And both Glamour and Spec don't make it easy to >> solve Morphic bugs. >> >> I value your ambition a lot :) But I also feel that it stresses >> the Rmod team, and it leaks over the community. >> >> >> What are the plans to integrate TxText? By which I mean, what will >> be the staging for refactoring existing tools on top of it? It seems >> the path of Opal where (I think) it was in one Release before it was >> fully enabled worked well. >> >> Now I know that GTools have been used in Moose for a long time, but >> its integration to Pharo REPLACING Workspace has been a cultural >> shock to those that haven't used it before (myself included, though >> I'm lookign forward to adapting). I think there'll be similar >> culture shock when Pharo 4 is released, from those that don't follow >> the bleeding edge. I'd strongly suggest that GTools operate for ONE >> release alongside existing tools, as an additional item in the first >> level World menu next to 'Workspace'. >> >> Indeed, even if Playground is quite stable through long use in >> Moose, it is new to Pharo, and marking its menu entry as >> 'Experimental' for now might provide some benefits. >> >> * This may provide a to stress test new evolving frameworks like >> TxText & Rubric - without affecting existing tools. >> >> * Now Playground has a wider community exposure, feedback from new >> users is likely to be less pressure and less negative if they still >> have access to old tools. >> >> * Feedback may result in changes. >> >> * Reduced culture shock. Builds confidence in a stable system not >> going "too fast" but just "fast enough" (very subjective I know). >> >> -ben >> >> >> Writing the chapter and maintaining Smacc is already a nice >> tribute to >> the community. Just continue that and we will be happy :) >> >> >> Thanks. John gave me plenty of fixes and I'm preparing a new >> version of SmaCC, and adding GUI tools (thinking of Guillaume >> needs and my needs as well). >> >> I certainly hope I'll be able to contribute on other things, >> still :) >> >> Thierry >> >> >> >> >> >> >> >> >> -- >> www.tudorgirba.com <http://www.tudorgirba.com> >> >> "Every thing has its own flow" >> > > > > -- www.tudorgirba.com "Every thing has its own flow"
