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.
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. -ben
Cheers, Doru
On Sat, Oct 4, 2014 at 2:30 AM, Ben Coman <btc@openinworld.com <mailto:btc@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"