I’m not talking about you or anyone else in particular. I’m talking about a general attitude I’m sensing. Now, I can be wrong… of course (and I hope) :) Esteban

On 03 Oct 2014, at 14:27, kilon alios <kilon.alios@gmail.com> wrote:

First of all, if you are referring to me I never said "this is a shit".

Second what you see as negativity I see it as honesty and for me is far more important than "Pharo is yours". Assuming honesty does not become rudeness.

Third I dont recall anyone ever demanding a feature of you guys working 24/7 to implement something disregarding your limited resources.

Fourth I have to say that I really don't get the "Pharo is yours" motto. Is there software out there , open source or not that does not listen to its community and does not try hard to makes its users happy ? Pharo is not mine, If I designed Pharo I would make a lot more diffirent choices than the ones that are included in Pharo and many of them would be proven bad and stupid in the long run because I have made many of them already. I want to contibute and keep pushing Pharo forward but realistically Pharo will never become mine and that maybe is more a good than a bad thing for the rest of you.

Fifth, the community overall is friendly, we had our clashes from time to time but lets be realistic, what community does not ? I have had my bad experiences while coding with python and just a daily participation in irc channels and forums can prove this point easily. These things make one mature emotionally and learn how to treat people online in a productive way. Communities benefit more than fall apart from these incidents because they really prove what kind of metal they are made of.

Not helping does not help is something we will agree to disagree, Companies invest billions of dollars on surveys to see how people feel about a product. You may hate the idea of Pharo viewed as a product but maybe then maybe you understimate the importance of this approach. Sooner or later Pharo will need some serious funding to get more full time developers and investors will see Pharo as a product.

In the end if what drives you all is to create a super cool product go out and ask people what they truly feel about Pharo. Very few people use smalltalk implementations , why ? What they don't like is far more important to what they like. Learning to target features that your users need the most is the path to success but even if the user does not really know what he or she want getting to know your user needs or the way he/she thinks is what will help you design tools that make people smile but most importantly make people use on a day to day basis.

If you are not ready to take in the negativity you wont go very far because there is a ton of negativity out there. If you find my negative bad, boy you have seen nothing . There is a lot of frustration out there for things even unrelated to coding, sometimes accepting that help you communicate easily with people . Dont try to suppress negative it will become a volcano that will erupt eventually.

On the other hand do not tolerate trolling either, isolate these kind of people who love to annoy others and throw the away from poisoning the community.

"Anything done with a measure is perfection"

On Fri, Oct 3, 2014 at 2:44 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote: Hi,

I’m writing this because I’m sad about what is happening in this list. I’m seeing a lot of general negativity and non constructive ways to discuss things. I’m also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I’m seeing more frequently an attitude of “customer”, more than the conviction than this, Pharo, is also yours…

Please people, we (the pharo “core” team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not “pharo the language”, so this is a collateral advantage….)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just “this is a s**t” does not help. Even if it is. - Be propositional. Just “this is a s**t”, and not telling what you want/prefer does not help. - Be proactive. Just “this is a s**t”, and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the “pharo-dev” list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

On 3/10/14 18:56, Hernán Morales Durand wrote:

I have the same feeling. "Pharo is yours, but I take the main decisions". Actually it feels a little bit insulting, I am using Pharo since several years in a domain which nobody works with Smalltalk, and never got a survey request (except for some software engineering research). And I bet there are people not in the Pharo/Moose/Seaside team that didn't received any attention and they are doing significant experiences.

You are paranoid. :) We know well people in Moose and Seaside and they know that they can talk to us. Just ask and we listen. I do not think that people understand what is our life. We are not a team working on Pharo. We are a research team fighting to get some time to push Pharo and Inria gives us some money to pay engineers like igor, and esteban.

Why they don't write here? I suspect one of the reasons is Pharo is being too motivated by software enineering research and not enough interest for other giant domains like 3D, finance, expert systems, HPC, etc. People perceive this. We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO. Repeat after me. We are NOT DOING RESEARCH IN SOFTWARE ENGINEERING IN PHARO.

We are just maintaining it and making sure that we can have a decent compiler and infrastructure to build other systems. How could we build finance, HPC, 3d without been experts. Do not dream there are full team of researchers at Inria building real 3d engines. Why would we go there? Seriously.

I see years passing but money never comes. You cannot expect big funding if you keep doing things the same as always.

Exactly and do not dream about investors. Now we work hard to set the consortium. If at the end of the journey, people do not sponsor or participate then we will close it. and we will look back and say that we did our best. We create an autonomous entity that can manage Pharo but if we cannot pay an engineer with it then this is ok too. But people should not complain that open-source Pharo does not work. We do not have mozilla or google behind us and if individuals do not understand that they can get an impact = Pharo is yours then what can we do. Just continue slower with less engineers.

Yes, please stop rejecting feedback that you won't like.

We do not reject it. But I can say that you can stop rejecting our feedback if you do not like it too :) My feedback is: WE FIGHT EVERY SINGLE DAY TO GET RESOURCES IN PHARO. WE SPEND LOT OF ENERGY TO MAKE IT HAPPENING. and we could do something else in our life and get paid the same. So start thinking to help yourself because this is the best way to build the pharo you need and we do not need the same.

Cheers,

Hernán

Fourth I have to say that I really don't get the "Pharo is yours" motto. Is there software out there , open source or not that does not listen to its community and does not try hard to makes its users happy ? Pharo is not mine, If I designed Pharo I would make a lot more diffirent choices than the ones that are included in Pharo and many of them would be proven bad and stupid in the long run because I have made many of them already. I want to contibute and keep pushing Pharo forward but realistically Pharo will never become mine and that maybe is more a good than a bad thing for the rest of you. You know. Let us take Java, C# , Javascript, Python, can you propose simply to change the core of the system and get any chance to see your changes evaluated?

Not helping does not help is something we will agree to disagree, Companies invest billions of dollars on surveys to see how people feel about a product. You may hate the idea of Pharo viewed as a product but maybe then maybe you understimate the importance of this approach. Sooner or later Pharo will need some serious funding to get more full time developers and investors will see Pharo as a product.

sweet dreams. Investors do not invest in languages. I talked to CamelPro people and they face exactly the same problem.

In the end if what drives you all is to create a super cool product go out and ask people what they truly feel about Pharo. Very few people use smalltalk implementations , why ? What they don't like is far more important to what they like. Learning to target features that your users need the most is the path to success but even if the user does not really know what he or she want getting to know your user needs or the way he/she thinks is what will help you design tools that make people smile but most importantly make people use on a day to day basis.

If you are not ready to take in the negativity you wont go very far because there is a ton of negativity out there.

This is not that we cannot take negativity. Now do not expect that our days are 72h per day. So manage your frustration and help yourself this is the message.

If you find my negative bad, boy you have seen nothing . There is a lot of frustration out there for things even unrelated to coding, sometimes accepting that help you communicate easily with people . Dont try to suppress negative it will become a volcano that will erupt eventually.

On the other hand do not tolerate trolling either, isolate these kind of people who love to annoy others and throw the away from poisoning the community.

"Anything done with a measure is perfection"

On Fri, Oct 3, 2014 at 2:44 PM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:

Hi,

I’m writing this because I’m sad about what is happening in this list. I’m seeing a lot of general negativity and non constructive ways to discuss things. I’m also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I’m seeing more frequently an attitude of “customer”, more than the conviction than this, Pharo, is also yours…

Please people, we (the pharo “core” team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not “pharo the language”, so this is a collateral advantage….)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just “this is a s**t” does not help. Even if it is. - Be propositional. Just “this is a s**t”, and not telling what you want/prefer does not help. - Be proactive. Just “this is a s**t”, and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the “pharo-dev” list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

On 3/10/14 14:58, J.F. Rick wrote:

Hi Esteban,

seconding your points, it is important to acknowledge why a solid Pharo core is important and worth striving towards even if it can be painful. First, read Bret Victor's reflection on Doug Englebart: http://worrydream.com/#!/Engelbart <http://worrydream.com/#%21/Engelbart>

He makes the case that the vision that drove Englebart was important to how he realized things, giving the specific example of how his video conferencing system was fundamentally different than today's screen sharing technology. Today's screen sharing is basically a nice hack onto an existing single user system. Simply doing what Englebart did would require a lot of restructuring at the foundation. With Pharo, we have the possibility to really build / refactor from the ground up, building a fundamentally better foundation, ultimately making cool things possible. For my own work, I'm excited about the possibility of building a new multi-touch implementation from the ground up. That said, the current Pharo foundations have a number of problems for me:

(1) Graphics are still based on BitBlt, which is slow and ugly. Moving over to Athens will address this. While I have successfully used Athens graphics, I still get VM crashes (which are probably due to Athens as I did not get the crashes beforehand). When you get them can you report to see what we can do? (2) Sound does not really work. On 64-bit linux, I can't simply play a recorded file as the sound plug-ins really only work for a 32-bit system. yes yesterday olivier was trying on linux and "alsa" seems oldish now

(3) Event handling does not get touch events. I've hacked this so far but a sustainable solution would be great. Did you check the new OSWindow because We should now integrate and replace the old events system to use OSWindow (4) Packages do not facilitate transfer of resources. For my purposes, I need to add images and sound to a package. This is not really possible right now. I was synching with Max about the status of libgit and he continues to make progress so we will get there.

I am willing to help on these problems for the community but sometimes I need support, especially when C code is necessary, rather than Pharo code. For instance, if I could get a VM that gives me raw touch events into Pharo, I could take (3) from there. I'd also be willing to work on (4) but I could use some help. One intimidating part is that there are so many package managers for Pharo. It might be nice if we simplified down to one: the right one.

Anyway, you can count me in for some contribution back to Pharo core but I might need some support from Pharo central and it won't happen for at least another month as I'm just getting set up in the new location (e.g., no access to a multi-touch device).

Let us know and we will see how to help you. I cannot open Pharo for now because I'm not allowed by Pomodoro :) if you see what I mean. No fun allowed. But after I want to see the new events and how to remove the old one. Igor told me that they plugged the new ones into morphic so I should check. (because in the process we never integrated the cleans I did and that we never finished - that is life).

Cheers,

Jeff

On Fri, Oct 3, 2014 at 7:44 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> wrote:

Hi,

I'm writing this because I'm sad about what is happening in this list. I'm seeing a lot of general negativity and non constructive ways to discuss things. I'm also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I'm seeing more frequently an attitude of "customer", more than the conviction than this, Pharo, is also yours...

Please people, we (the pharo "core" team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not "pharo the language", so this is a collateral advantage....)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just "this is a s**t" does not help. Even if it is. - Be propositional. Just "this is a s**t", and not telling what you want/prefer does not help. - Be proactive. Just "this is a s**t", and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the "pharo-dev" list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

-- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

...

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too. It is a matter of tolerance and patience.

Not only it is a matter of people writing doc so that we do not have to do it, adding tests, checking bugs,.... proposing fixes.

You keep doing your great job, but accept that we, outside of the internal, core, revolutionary research being made, might have mundane necessities. That on the daily basis have more importance than a futuristic 128bit manycore vm that kicks JVM's ass :D

But we even not working on that. JUST PLAIN BUGS. and if everybody would spend 1 hour per week reviewing and improving some libraries then we would have more impact.

...

So, I refuse to believe that we cannot be a cool and helpful community. We are.

Email sometimes is counterproductive to the health of the communication. It's like a fence between us. And as the saying, transliterated, goes: "We're like dogs barking at both sides of the fence that when together they smell at each other and waggle their tails." :)

Yes this is true too. Still Pharo is yours not mine.

...

In conclusion: not helping does not help :) Please consider than USING Pharo is a way to contribute to it.

yes but we are small and using is not enough

Even if you had infinite manpower but no one uses it, it would be worthless. Give me 2 Millions Euros and you will see that lot of people will come and use it.

...

Esteban, still grateful of belonging to this community ditto :)

Regards!

libraries then we would have more impact.

I am. More and more as I'm getting used to the libraries and to the contribution process (which still is centralized).

Excellent

However you can't count with everybody contributing to make Pharo a success. It won't happen to Pharo, as it wont happen anywhere else.

Wikipedia isn't a success because everybody contributes, it is a success because there is a dedicated/loyal group of contributors that accounts for 80% of the material published. Pareto principle end to end.

Yes this is clear.

...

Still Pharo is yours not mine. Sorry, but as others said, I neither share that feeling. And I it isn't something negative to me.

I feel part of the community, and as I publish fixes or minor improvements I begin to be part of the contributors. Only being part of the Association or Consortium is the only, reasonable way, of feeling that, and even so I can anticipate myself I won't feel that. Ok but in other systems did you ever thought that you could improve some core functions? This is my point.

...

...

Please consider than USING Pharo is a way to contribute to it. yes but we are small and using is not enough Not enough, but don't disregard your users!

I do not. I'm writing books, tutorials, videos for them.

Take the example mentioned above above Wikipedia. As the user base grows, the motivation for public contributions grows too. And also grows the funding.

It's a virtuous circle.

...

...

Even if you had infinite manpower but no one uses it, it would be worthless. Give me 2 Millions Euros and you will see that lot of people will come and use it. If I had it I'd totally give it, but unfortunately I don't have it.

However I don't think it is only about that. Many ventures fail with even more money.

With more resources, you would make Pharo better/awesome..., but money only don't create the market nor the demand. Even lobbyists need more money than that to gain traction.

Best regards!

Esteban A. Maringolo

well… I think everybody is taking it too personal :) My call was to keep a good environment and try to be more positive on our communication. And to try to provide advice with the criticism (and to provide fixes when possible). I’m completely aware that people has other things to do than Pharo… but being just in the place of criticise without any positive loop is what I think is not good. Just that, I’m not blaming anyone, just making a call for keep the good will. Esteban

On 03 Oct 2014, at 17:07, Thierry Goubier <thierry.goubier@gmail.com> 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...). 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) on top of an already unstable version (4.0), and I'm really not impressed by the software development process.

The end result is, when I see a bug, I'm already at least two versions behind you guys... 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.

Regards,

Thierry

2014-10-03 13:44 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>: Hi,

I’m writing this because I’m sad about what is happening in this list. I’m seeing a lot of general negativity and non constructive ways to discuss things. I’m also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I’m seeing more frequently an attitude of “customer”, more than the conviction than this, Pharo, is also yours…

Please people, we (the pharo “core” team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not “pharo the language”, so this is a collateral advantage….)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just “this is a s**t” does not help. Even if it is. - Be propositional. Just “this is a s**t”, and not telling what you want/prefer does not help. - Be proactive. Just “this is a s**t”, and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the “pharo-dev” list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

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?

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.

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.

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. Writing the chapter and maintaining Smacc is already a nice tribute to the community. Just continue that and we will be happy :) Stef

Regards,

Thierry

2014-10-03 13:44 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

Hi,

I'm writing this because I'm sad about what is happening in this list. I'm seeing a lot of general negativity and non constructive ways to discuss things. I'm also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I'm seeing more frequently an attitude of "customer", more than the conviction than this, Pharo, is also yours...

Please people, we (the pharo "core" team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not "pharo the language", so this is a collateral advantage....)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just "this is a s**t" does not help. Even if it is. - Be propositional. Just "this is a s**t", and not telling what you want/prefer does not help. - Be proactive. Just "this is a s**t", and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the "pharo-dev" list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

TxText will happen. It's too important to leave it unhappening :).

Oh yes like OSWindow, GTToolkit and many other things. :) Stef

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

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"

Tudor Girba wrote:

Hi Ben,

On Sat, Oct 4, 2014 at 7:27 AM, Ben Coman <btc@openinworld.com <mailto:btc@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

Okay. That is a reasonable philosophy. -ben

Hi Thierry, On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

[...] 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.

I believe there is a confusion here. GT and Glamour are not maintained by the RMoD team. GT is an external project and it is maintained in its separate repository. That is why it stresses RMoD less and it is a way of scaling. Also, since more than one year I am working on fixing various Morphic problems, and I can tell you that GT provides a significant productivity boost in that specific area. In any case, you should also note that these tools are under development since several years (the overall project started 5 years ago) and they are being actively used since 2 years in Moose. I believe we never had that much focus on the tools before. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Hi, On Sat, Oct 4, 2014 at 8:34 AM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Le 04/10/2014 08:14, Tudor Girba a écrit :

...

Hi Thierry,

On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

[...] 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.

I believe there is a confusion here. GT and Glamour are not maintained by the RMoD team. GT is an external project and it is maintained in its separate repository. That is why it stresses RMoD less and it is a way of scaling.

I agree that the GT Tools are a bit different. Still, TxText integration will have to work on all users of all forms of text, including GT (and additionally GT).

Yes. That will become a priority once we address the current issues with GTInspector/Playground.

And now you are starting to have the issue of handling slices on GT from Pharo: do people have to register on Moose, resynchronize on GT on Moose, push their slices there, wait for Moose to push a slice to integrate on Pharo, wait for Pharo to integrate that slice?

Something like that. Only there is no wait time to integrate in Moose as GT is a standalone project, and Moose simply integrates the latest development version of all its dependencies. So, there is not that much difference to integrating in Pharo. Once a new stable version of GT is available, it will automatically be available in Pharo.

Also, since more than one year I am working on fixing various Morphic

...

problems, and I can tell you that GT provides a significant productivity boost in that specific area. In any case, you should also note that these tools are under development since several years (the overall project started 5 years ago) and they are being actively used since 2 years in Moose. I believe we never had that much focus on the tools before.

I found that stepping through the opening sequence of GT to debug MorphTreeMorph a pain and had to find another way to understand the issue.

Can you be more specific? What did you try to achieve and did not manage?

I do have specific tools I can use in such circumstances that you don't have.

What kind of tools? I would be interested in learning about them and the analysis use cases they support.

I agree that Morphic has improved due to the fact GT is exposing it in different ways (and you solving bugs in there), and that you are integrating Alain's work (Rubric) in advance. I'm not worried by GT per se (see above for the contribution things), but by the fact core elements (Athens, TxText, NativeBoost, git) are a long way from stabilising.

I think the way is not that long. But, I am an optimist. Let's see :) Cheers, Doru

Thierry

...

Cheers, Doru

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Hi Thierry, On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi,

Le 04/10/2014 11:54, Tudor Girba a écrit :

...

And now you are starting to have the issue of handling slices on GT from Pharo: do people have to register on Moose, resynchronize on GT on Moose, push their slices there, wait for Moose to push a slice to integrate on Pharo, wait for Pharo to integrate that slice?

Something like that. Only there is no wait time to integrate in Moose as GT is a standalone project, and Moose simply integrates the latest development version of all its dependencies. So, there is not that much difference to integrating in Pharo. Once a new stable version of GT is available, it will automatically be available in Pharo.

I don't think this is the way to go. It raises an additional barrier to contributions to GT, such as:

A - I tried GTPlayground on Pharo, I had a DNU, here is the issue I created.

A - I pushed a slice with the corrections

B - In GT development version we decided to go another way. We don't need your slice. Please wait for the next stable version and try again. Thank you for your contribution.

A ---

I'm not sure you'll get another contribution from A after that exchange ;)

I do not understand your scenario. How is it any different from the Pharo integration? If the integrator decides it's not a good fix, it does not get integrated. There will be barely any delay.

I found that stepping through the opening sequence of GT to debug

...

MorphTreeMorph a pain and had to find another way to understand the issue.

Can you be more specific? What did you try to achieve and did not manage?

I was trying to find out why a MorphTreeMorph would DNU upon GTDebugger opening ;)

I gave up and went blindly into the MorphTreeMorph code instead, trying to solve it by luck.

Can you be more specific, please? What did you do to get a DNU?

I do have specific tools I can use in such circumstances that you

...

don't have.

What kind of tools? I would be interested in learning about them and the analysis use cases they support.

I have a trace tool for those situations (and also for parser work).

What trace tool? Is an example available?

My original use case was: - Finding the bug in an error correction decoding algorithm which worked without error, but with non-satisfying results: lower than expected SNR. - Has then been used very successfully to explain the algorithm. - Was then used as the basis for a hardware design methodology by dynamic code traces of multithreaded programs

Other use cases I use it for: - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text editor errors) where halt makes the image unusable. - Debugging code in Parsers when the code of a reduction is not working properly (somewhere deep in the AST).

Is this more than a logger? Doru

Thierry

-- www.tudorgirba.com "Every thing has its own flow"

Hi Thierry, On Sat, Oct 4, 2014 at 11:32 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:

Hi Doru,

Le 04/10/2014 22:48, Tudor Girba a écrit :

...

Hi Thierry,

On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier <thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> wrote:

Hi,

Le 04/10/2014 11:54, Tudor Girba a écrit :

And now you are starting to have the issue of handling slices on GT from Pharo: do people have to register on Moose, resynchronize on GT on Moose, push their slices there, wait for Moose to push a slice to integrate on Pharo, wait for Pharo to integrate that slice?

Something like that. Only there is no wait time to integrate in Moose as GT is a standalone project, and Moose simply integrates the latest development version of all its dependencies. So, there is not that much difference to integrating in Pharo. Once a new stable version of GT is available, it will automatically be available in Pharo.

I don't think this is the way to go. It raises an additional barrier to contributions to GT, such as:

A - I tried GTPlayground on Pharo, I had a DNU, here is the issue I created.

A - I pushed a slice with the corrections

B - In GT development version we decided to go another way. We don't need your slice. Please wait for the next stable version and try again. Thank you for your contribution.

A ---

I'm not sure you'll get another contribution from A after that exchange ;)

I do not understand your scenario. How is it any different from the Pharo integration? If the integrator decides it's not a good fix, it does not get integrated. There will be barely any delay.

I think you need to reread the exchange. Because Glamour main development is kept separate from Pharo, with a Glamour stable being pushed into Pharo, then you increase the chances that you diverges temporarily the stable Glamour from the one in Pharo. And simply make it costly for someone in Pharo to participate.

I don't think it would cost you much to consider that stable Glamour is the one in Pharo, and that the development one is kept in Moose, with merges of the development Glamour to the stable one in Pharo. You would loose a bit of control on stable Glamour, because any maintainer of Pharo could integrate fixes, in exchange for making it easier for non-Moose users to contribute. Your call :)

You should take into account that with Pharo we are moving towards configurations. That is why Glamour and GT will remain as separate projects loaded via configurations. I actually do not mind more people making decisions. In fact, the Moose development doesn't happen through an inbox, but by directly committing. And we work with the latest development version, not the stable one. We started with the stable one in Pharo to smoothen the integration. It will take a bit of time to find a rhythm that works, but I definitely think this is the right direction.

I found that stepping through the opening sequence of GT to

...

debug MorphTreeMorph a pain and had to find another way to understand the issue.

Can you be more specific? What did you try to achieve and did not manage?

I was trying to find out why a MorphTreeMorph would DNU upon GTDebugger opening ;)

I gave up and went blindly into the MorphTreeMorph code instead, trying to solve it by luck.

Can you be more specific, please? What did you do to get a DNU?

That was at that occasion: http://moose-dev.97923.n3. nabble.com/debugger-in-the-last-moose-tp4032413p4032415.html

Oh. I remember :). I thought you encountered a more recent bug.

...

I do have specific tools I can use in such circumstances that you don't have.

What kind of tools? I would be interested in learning about them and the analysis use cases they support.

I have a trace tool for those situations (and also for parser work).

What trace tool? Is an example available?

http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html

My original use case was:

...

- Finding the bug in an error correction decoding algorithm which worked without error, but with non-satisfying results: lower than expected SNR. - Has then been used very successfully to explain the algorithm. - Was then used as the basis for a hardware design methodology by dynamic code traces of multithreaded programs

Other use cases I use it for: - Debugging code in Morphic (rectangles, MorphTreeMorph stuff, text editor errors) where halt makes the image unusable. - Debugging code in Parsers when the code of a reduction is not working properly (somewhere deep in the AST).

Is this more than a logger?

Part of it is a logger, to record events.

A second part of it is a code rewriting tool. You give it a method, it adds the code to trace the execution and recompiles the method.

A third part is a viewer which links each recorded event with the expression which generated it in the method.

(The second part could be changed to use the Opal facilities instead of code rewriting. There is probably work to be done on the logger as well: remote logging via RS232, Jtag probes, etc...).

Sounds interesting. I never looked at it. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Hi Florin, you're in for some interesting questions :) First, I did not have a methodology for finding the issue (or explaining the algorithm) when I started, and I didn't have one afterwards; you need to look into the WhyLine stuff for that (they do a lot better, but I don't have the time to reimplement their tool). But I noticed that understanding an algorithm is easy (relatively) when: - You can easily move repeatedly to any point in an execution stream of that algorithm (i.e. ubiquitous debugging: step forward, backward, jump at any point back and forth, any number of times). - At each point, you are given the precise point in the source code (debugger-like) - At each point, you get significant values: assignments, arguments, return values Representation is easy: an execution is a tree. A sequence in this execution is items at the same level in the tree. Calls are subtrees, as well as iterations. Gui is simple: a tree on the left, code pane on the right. See an example underway: I'm trying to find a bug in LayoutFrame, so I traced LayoutFrame>>transform: (without breaking Morphic). [image: Images intégrées 1] This is for exploration at the moment, and not comparing values. And on a single method, and highlighting is broken in Pharo 4 :( In the value tracking idea, what we thought then in the place I worked in at that time, is that we could study comparing / diffing trace trees to see where the two versions of the algorithm diverges. We didn't follow up and it wasn't published. I have new visualisations on Roassal now, but they are for static analysis of multitask C code. Does that give you ideas? Thierry 2014-10-06 15:08 GMT+02:00 Florin Mateoc <fmateoc@gmail.com>:

Hi Thierry,

On 10/4/2014 5:32 PM, Thierry Goubier wrote:

...

...

I do have specific tools I can use in such circumstances that you don't have.

What kind of tools? I would be interested in learning about them and the analysis use cases they support.

I have a trace tool for those situations (and also for parser work).

What trace tool? Is an example available?

http://lists.gforge.inria.fr/pipermail/pharo-project/2012-July/067679.html

...

...

My original use case was: - Finding the bug in an error correction decoding algorithm which worked without error, but with non-satisfying results: lower than expected SNR. - Has then been used very successfully to explain the algorithm. - Was then used as the basis for a hardware design methodology by dynamic code traces of multithreaded programs

I am very interested in the "explaining the algorithm" aspect of your tool. Could you please talk a little about that?

I think I had a similar use case - improving an algorithm working over a lot of data (so stepping through it with a debugger was unrealistic) - and my approach was to run two versions in parallel (the latest (best) available iteration in the implementation, known to work, versus the bleeding edge), with synchronization points for every iteration within the algorithm execution, so that I would catch (through a halt) any divergence as soon as it started, and from them on using the debugger. This worked quite well, but it did not help with explaining the working of the algorithm and I kept wishing I had a visualization that would help me get to an intuitive (and holistic, not just of the subparts) understanding of how the algorithm worked (in the style of Bret Victor's visualizations), but I did not know how to get to it. So, if you did manage to get to such a visualization (one that does not come from an already (pre-existing for the creator of the visualization) understanding of the algorithm), that would be fantastic

Florin

Hi Florin, I've changed the header for our discussion :) Le 07/10/2014 05:29, Florin Mateoc a écrit :

Hi Thierry,

Thanks for pointing it out. It is indeed interesting, but not what I had in mind. I am not talking about debugging here so much. I am quite good at that, and I find it natural to build tools that help me do it (and of course, Smalltalk debuggers are very good already (restarting a method/block pretty much gives you the benefits of stepping backwards)), but debugging broken behavior is more about mapping an internalized model of the execution with what's really happening, seeing where they diverge. You are just checking that what you think you know is true. Of course, when you find out it's not, you gain insight/experience. But what to do when there is nothing to check? What if, like in the situation you mentioned, the algorithm is already working (so it's producing the correct/expected results)? But you still want to make it better....

First, when dealing with complex algorithms, a restart a method/a block does not match what a full trace allows, first because you may have side-effects (which defeats the restarting thing), second because you don't have to set the next halt point when you go backward and restart, third because the debugger may lock your environment (think about halting one of the Rectangle methods, for example). However, you may loose some of the context in the trace. Second, your last statement is self-defeating: you want to make your algorithm better, which means you have the knowledge of what makes it tick and improve. I describe that process as moving in the design space of the algorithm, and that great tools are the ones which help you find the right direction in that design space.

What I want help with is what I am not as good at. I want to literally "see" what's wrong (not good enough) with the picture, since the brain has those very powerful visual pattern matching capabilities. They remain unused when you are lost in the minutiae of the debugger, where you only see text and numbers, the granularity/level of abstraction is too low. Profilers are a little better - they also succinctly capture the execution tree, and I have also used traces for hard to debug sequences.

The brain has some good abilities, but they are not what I'd call pattern matching (or at least you need to be very carefull with which visual variable you want to exploit: some are not suited at all to that type of visual analysis). I refer to Sémiologie Graphique, J. Bertin, for that. What I have considered in the work I did in the past on that is that visual systems have natural abstraction capabilities if we use / exploit them, and that they avoid the problems associated with building a formal abstraction process which may miss the point or the analysis we may extract from that. For example, a very high level view of a profile or a trace, as a tree with just a one pixel wide line per item (with identation according to depth + length related to some other execution property) may convey a lot about an execution. Another path that Alexandre Bergel makes wonder with is to use interaction to add and remove additional contextual data; you can't do comparative analysis visually with that, but, given a fast system, you may scan for a large amount of additional data without overloading the base display. I have used it to couple a code visualisation with a large C source file, with hovering over nodes jumping instantaneously to the right place in the source, and this is really effective for fast understanding of code structures (and loop / field of view focus effects).

Coming back to the WhyLine example, they already had something to (visually) look at: objects colliding. Other times, the visual representation is obvious/implied (say an algorithm for driving a car on a given course - even if all you are given are coordinates, it is common sense that you would draw the course on the screen and watch the car as it makes progress when the algorithm ticks). In many algorithms you don't have that. How do you find, in such cases, what pictures/graphs/animations to look at? For an algorithm one obvious candidate would be to the dynamic behavior of the main data structures used (although, say you do this for the car example and compare and contrast visualizing the data structures used by the algorithm vs visualizing the car moving, or the objects colliding). And you still have to find the right scale and level of abstraction.

I guess here you have ideas: heat maps on data accesses, evolving over time; a representation of all objects in memory, with their color which evolves according to freshness (animated). Could be very interesting to compare that way two versions of the same algorithm, to see how they differ in time? Trace may be very valuable there, because it may be tuned to record the type of events you are interested in, and then be exploited to build a visualisation on top. With experience, what I value now a lot is code interaction: anything that very easily couple the visualisation with the relevant code (and not only the method, but the point in the code). I'm also dealing with safety properties of the code: safe, correct multithreaded code, either through run time analysis (see VectorFabrics tools :)) or through static analysis (Frama-C). Interesting subject and I am totally out of available work hours to implement stuff on that :) Thierry

Hi Florin, Le 08/10/2014 04:45, Florin Mateoc a écrit :

Hi again,

I don't understand the self-defeating part. Indeed, I do start with some knowledge, and because of that, initially I can come up with some external representation, which reflects that understanding. After staring at it enough (in its dynamic behavior), I can notice ways to improve things. I "milk" the representation until the initial behavior is barely recognizable. At that point it is not helpful anymore. I need a different representation now to stare at, since I have the nagging feeling that I am still leaving something on the table. How do I get to the next one? Moving in the design space sounds exactly right. So, how do you do that?

No idea yet. I have tried to embed that kind of philosophy in the previous to last programming language I helped design and implement, but didn't manage to setup the right PhD subject and candidate to integrate that into the IDE/Compiler. I approached a visualisation 'guru' who was very interested, but we didn't manage to get the subject / project of the ground. It may have been a bit over-ambitious :)

That is a very nice way of expressing it, except I would still say that it is not the visual system themselves that have the natural abstraction capabilities, it is a specialized part of our brain that extracts that automatically/unconsciously for us (what I called pattern matching (since it can only identify/notice things that it can match somehow)). But you expressed much better than I did why this is/would be so valuable. And I will check out the reference, thank you - the title sounds promising :).

Recommended. I also have praise on the E. Tufte books of course.

Well, same here, and right now I am busy with another spare time project anyway (but I couldn't resist asking about your tools :) ), but if I ever manage to get back to polish that algorithm which has been in the back of my mind during this discussion (for the longest common subsequence), and which I worked on just for fun anyway, but which left me, as I said, with the nagging feeling that I could do more (and I don't mean some peephole optimization), I will try out some of these visualization techniques to see if anything comes out of it.

Please explore when you'll have time, and describe what you end up with. I have the feeling that Pharo is moving towards providing building blocks to reuse as foundations for that kind of work: Roassal, parsers, ASTs, traces, code models, etc... so that we may build any needed visualisation, as Moose is using for software in the large. I'm currently on a medium to long term quest to learn in depth / maybe improve the AST automatic generation in SmaCC; it should give me a core foundation (a common API for the ASTs for all langages that SmaCC can parse) to build upon interactive visualisations IDEs for the programming languages I'm getting involved in: yesterday C, now R, tomorrow (I hope) Fortran and Python. But this is more about static analysis than runtime behavior analysis, unless I turn to VectorFabrics underlying tech... Hum, this one is ... interesting. It opens new ideas. Thanks a lot, this is really great! Thierry

exactly and most of us are aware of these tools and the fact that are very useful because a) we are registered in the moose mailing list b) because you have posted a few demonstrations videos about their use here, in the moose mailing list and in tweeter. I am very excited that you push pharo development forward and can't wait to see what more surprises you have in store for us. My thread which I think it was blown out of proportions was just a request for clarifications and some criticism on the tool itself. I never demanded that the tool should changed just for my shake or I wont use it, nor I expect these changes to come fast or in same form as Workspace. As I said in that thread Pharo 4 is a long way to go till its release. I have no regrets about that thread, my criticism still stands and I think I have been fair and polite but also honest. You replied to my questions without making assumptions and jumping to conclusions about my character and my state of mind and I really appreciate that. As I state always and maybe I started to sound boring by now, documentation is the most important feature. Playground is an advanced tool and of course it needs some explaining to utilise properly . Those blog posts are definetly a good starting point. I am still studying them and I will be using Playground non stop from now on because I use always the latest Pharo 4 for my project Ephestos. I usually get the latest release every few days. Actually your reply put it in some thinking about the potential of using GT tools to refactor Python code which is the core goal of my project. Definetly some exciting potential there. Keep up the great work. On Sat, Oct 4, 2014 at 9:14 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

Hi Thierry,

On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier < thierry.goubier@gmail.com> wrote:

...

[...] 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.

I believe there is a confusion here. GT and Glamour are not maintained by the RMoD team. GT is an external project and it is maintained in its separate repository. That is why it stresses RMoD less and it is a way of scaling.

Also, since more than one year I am working on fixing various Morphic problems, and I can tell you that GT provides a significant productivity boost in that specific area. In any case, you should also note that these tools are under development since several years (the overall project started 5 years ago) and they are being actively used since 2 years in Moose. I believe we never had that much focus on the tools before.

Cheers, Doru

-- www.tudorgirba.com

"Every thing has its own flow"

Le 04/10/2014 12:07, stepharo a écrit :

...

NativeBoost is not unstable for me, but why libcgit is on a bleeding edge NativeBoost version then?

I do not get what you want to say. May be restating will help me understand.

Last time I checked, libcgit was tied to an experimental NativeBoost version (or bleeding edge version). The changes needed by libcgit should have been integrated in Pharo instead.

...

Athens is stable for me, but I believe that TxText requires a bleeding edge Athens.

Igor improve Athens each time it is needed and it does not make athens unstable.

But basically TxText is on a fork of mainline Athens. It's the "Windows undocumented" approach: I'm on TxText, I need something from Athens, I just add the stuff to Athens; anyway, I'm not on the main Athens, I can get my own customized version. Now, when merging TxText, you'll have to merge a new Athens as well, and I hope that you won't find by then that this new Athens breaks Roassal. I can understand why you may want to work like that. From the outside, I'm not impressed by the process.

...

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 for you it would be better that we move faster :) Not slowler.

Not really. If you had a few million € to burn, I'd say "perfect". With the amount of resources we have, I'm saying: this is really risky. And hard to contribute to, so I can't help.

You see if there is a bug in a cache on the system somehwere what can we do. Igot told to alex to use another font and it solved the problem. TxText will be pushed soon in Pharo 40.

I tried to work on that cache issue because my demos with Roassal had the issue, but I couldn't find Igor's description in the archives. I know it's there... Igor, if you are listening, can you tell us again? Thierry

On 3/10/14 22:13, Hilaire wrote:

I agree 100% with Thierry. I wrote and complain about it months ago: we need consolidation in the newly developed stuff we have.

This is what we are doing. Look at spec we cleaned it. Now we do not have 3 more years for TxText and Athens. Keeping the old events is a door open for - more ctrl key does not work.....

So it may mean to slow down and polishing. Because from my point of view, I don't understand where is moving Pharo, but true it is moving.

Pharo is moving as - more modularity (we are working on making the bootstrap part of the building of Pharo) based on conifguration of external elements - great infrastructure compiler text OS event + window more example cleaning menu Stef

Hilaire

Le 03/10/2014 17:07, Thierry Goubier a écrit :

...

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) on top of an already unstable version (4.0), and I'm really not impressed by the software development process.

The end result is, when I see a bug, I'm already at least two versions behind you guys... 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.

Thanks alain. Here is my metaphor: I help myself and share my "soup of stones" with people that want to improve our soup of stones. At the end our soup may be great. Another way to present my metaphor is: "focus on what you need and change the system (and send us fixes/enhancements) on what you need. Because if you do not do it, then why a guy not needing it would need to spend time." ah to grow the market.... well Spur, 64 bits, better FFI, decent events, automated build for VM and many many other things are already in the pipeline and (none of them is about research :) you can trust me on that Stef On 3/10/14 21:24, Alain Rastoul wrote:

Le 03/10/2014 13:44, Esteban Lorenzano a écrit :

...

Hi,

I’m writing this because I’m sad about what is happening in this list. I’m seeing a lot of general negativity and non constructive ways to discuss things. I’m also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I’m seeing more frequently an attitude of “customer”, more than the conviction than this, Pharo, is also yours…

Please people, we (the pharo “core” team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not “pharo the language”, so this is a collateral advantage….)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just “this is a s**t” does not help. Even if it is. - Be propositional. Just “this is a s**t”, and not telling what you want/prefer does not help. - Be proactive. Just “this is a s**t”, and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the “pharo-dev” list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community

Hi Esteban,

Sorry for the long response, but I (like others) feel concerned about your post. I don't see any "negativity" in this forum, I don't understand why you are saying that, but I understand your point of view about people not contributing, being one of them. I think you are too pessimistic (please, drink 2, 3 beers with friends, one for me please - ... cheers :) - talk or forget about what is boring you and then get back with strength). Things are moving slowly, but they are moving in the good direction and thanks to the *dictatorship* leading of Pharo here ;-) , and thanks to people leading projects with Pharo. I think you have to consider that lot of people (may be I'm wrong, and it is just me ?) are here because they like and share the pharo vision of software developmnent, but have to work for a company just to make a living. My company is very focused on productivity and immediate gain. Efficiency against efficacity like our boss "explained" to us... it has some good counterparts like paying my living and my harley :) , and bad ones, like me not liking most of the job I have to do daily, and not agreeing with the "vision" of the company I live with that for now, I ride my bike very often :). Their opinions may looks negative but they are not. To me, people of the rmod team are lucky guys, they work on a sexy technology. May be they feel alone but they are not, may be this technology will fail in next 10 years (I don't think so) but, well, that's life, there will be a reason. Experience is good. I'm still trying to make some smalltalk evangelism (is it goodenglish?) around me at work, and slowly getting people into considering smalltalk (and pharo) as a serious technology (for squeak it was just impossible, sorry), but have not so much time to contribute seriously (and as Pharo moves quite quickly, it requires quite some time just to keeps up to date to last versions). I saw some posts about Glorp, databases and orm (some of my current working skills) and consider getting into this just to help, but on the other hand I have some other personal projects I would like to complete with Pharo. I may look selfish, but that's another point here: Pharo has to have more project going on to succeed. "Pharo's "success stories" is IMHO ***very*** important - and marketing is *****very***** important beeing a developper, I feel a bit sad saying that but that's the f***g reality. Interesting coincidence, I had a discussion today with a collegue about bad succeeding and good falling technologies (like javascript and smaltalk in our talks)...

Just to say keep on the good stuff please. And I stop here.

Regards ,

Alain

Great :) Doru On Fri, Oct 3, 2014 at 11:03 PM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 03/10/2014 22:10, stepharo a écrit :

Hi Stef,

I like your metaphor , and yes, I really hope to share my personal soup with Pharo community asap. A soup about databases, json, streaming/map reduce stuff I've been thinking (and still thinking) for a while now. All of that still in an alpha or infancy step now, but I'm working hard on that (big problem for me is time - I'm greedy on that, plus lot of stress at work). btw, I'm confident about Pharo technology, spur and 64 bits, and it is a great move forward :). May be I'll fail -it would not be the first time- but anyway, if I can contribute with Pharo (bugs, doc or whatever is accessible to me), I will. Just because I prefer Pharo over dotNet or Java :)

Regards,

Alain

Thanks alain.

...

Here is my metaphor: I help myself and share my "soup of stones" with people that want to improve our soup of stones. At the end our soup may be great.

Another way to present my metaphor is: "focus on what you need and change the system (and send us fixes/enhancements) on what you need. Because if you do not do it, then why a guy not needing it would need to spend time." ah to grow the market.... well Spur, 64 bits, better FFI, decent events, automated build for VM and many many other things are already in the pipeline and (none of them is about research :) you can trust me on that

Stef

-- www.tudorgirba.com "Every thing has its own flow"

On 3/10/14 23:03, Alain Rastoul wrote:

Le 03/10/2014 22:10, stepharo a écrit :

Hi Stef,

I like your metaphor , and yes, I really hope to share my personal soup with Pharo community asap. A soup about databases, json, streaming/map reduce stuff I've been thinking (and still thinking) for a while now.

I'm interested in that .

All of that still in an alpha or infancy step now, but I'm working hard on that (big problem for me is time - I'm greedy on that, plus lot of stress at work). btw, I'm confident about Pharo technology, spur and 64 bits, and it is a great move forward :).

Yes I'm waiting for that a lot. ephemerons, pinned objects, new format, immutability..... + opal and sista it will really rock.

May be I'll fail -it would not be the first time- but anyway, if I can contribute with Pharo (bugs, doc or whatever is accessible to me), I will. Just because I prefer Pharo over dotNet or Java

Excellent What I learn is small projects, small steps but many many of them

:)

Regards,

Alain

...

Thanks alain.

Here is my metaphor: I help myself and share my "soup of stones" with people that want to improve our soup of stones. At the end our soup may be great.

Another way to present my metaphor is: "focus on what you need and change the system (and send us fixes/enhancements) on what you need. Because if you do not do it, then why a guy not needing it would need to spend time." ah to grow the market.... well Spur, 64 bits, better FFI, decent events, automated build for VM and many many other things are already in the pipeline and (none of them is about research :) you can trust me on that

Stef

Tim Mackinnon wrote:

Hi guys - this was an interesting thread - and exactly the reason why I brought up “Zapp Empowerment” at ESUG this year.

just to let you know, based on your enthusiasm for this book, I bought it (but not yet read it). And one minor thought on the original post that didn't otherwise warrant its own reply earlier... I think its important not to quash negativity. Its a reflection of frustrations that community members sometimes feel (as in any situation), and feeling unable to vent is a risk for people drifting away from the community. "Feeling" free to be negative is part of what helps people feel part of a community - but its about how that is done. I felt a bit that the take-away-message from the original post was "be positive" (which some people had issue with) but I think the intent was "be constructive" is criticism. cheers -ben

I felt the passion from every single one of you - and in fact, everyone had an interesting point to make. I got a bit nervous as I worked up the 40+ replies, but I was pleased that no-one seemed to take great offence as we covered a wide range of related ideas.

If I could make one small comment - sometimes I think the gems in a reply can easily get lost if you don’t pay special attention to how the person(s) reading it might react. I think we all agree that we do like this community and the amazing work it has done (and continues to do) - and so its worth acknowledging someone’s ideas and then building on them. If you disagree with them however - try acknowledging what they have said and then suggest that there is an equally valid point of view/idea that they can also consider.

But I’m also glad we aren’t afraid to cover difficult conversations. I do think we can all practice giving and receiving feedback in a way that can keep the energy high.

Personally I really like that many of the old things are being modernised (GT Inspector blew me away - as it has done for colleagues who don’t even use Smalltalk). Equally, finding a way to get some community input via a survey/vote sounds quite interesting to prioritise a few things (possibly not for everything - as we are asking people to invest their spare time and energy on a labor of love - so we should go where the energy is). Equally, anything we can do to help keep the engineering high is equally appreciated - and I have seen it get better and better over the years.

Tim

On 3 Oct 2014, at 12:44, Esteban Lorenzano <estebanlm@gmail.com> wrote:

...

Hi,

I’m writing this because I’m sad about what is happening in this list. I’m seeing a lot of general negativity and non constructive ways to discuss things. I’m also seeing more and more people using Pharo for their particular interests (which is of course a good thing) but less and less people who contribute back to Pharo. Finally, I’m seeing more frequently an attitude of “customer”, more than the conviction than this, Pharo, is also yours…

Please people, we (the pharo “core” team) cannot do everything. We do not have the manpower or the resources to hire manpower. We would like, but we just do not have the resources (is already a blessing that we can work on this, for now: INRIA is paying, but what it pays is *research*, not “pharo the language”, so this is a collateral advantage….)

So, having an OPEN SOURCE project, with limited resources means that there is a lot of things that depend on the community. It depends on the community not just to fix, but to enlarge the ecosystem in general too.

So, I refuse to believe that we cannot be a cool and helpful community. I refuse to believe that general negativity and bad humor can overcome the joy of participating in this collective effort.

So, here some recommendations for enhance the way we participate:

- Be positive. Just “this is a s**t” does not help. Even if it is. - Be propositional. Just “this is a s**t”, and not telling what you want/prefer does not help. - Be proactive. Just “this is a s**t”, and not report, discuss and (at least time to time) provide a fix/enhancement does not help.

In conclusion: not helping does not help :) After all, this is the “pharo-dev” list. I mean, the list of people wanting to participate from this great, community effort.

cheers, Esteban, still grateful of belonging to this community