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"
