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.
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. Cheers, Doru On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <[email protected]> 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 "Every thing has its own flow"
