Re: [Pharo-dev] About ways to participate in community and general negativity
Hi guys - this was an interesting thread - and exactly the reason why I brought up “Zapp Empowerment” at ESUG this year. 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 esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 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...). Thierry
Re: [Pharo-dev] About ways to participate in community and general negativity
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 LayoutFrametransform: (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 fmat...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi Thierry, On 10/6/2014 9:37 AM, Thierry Goubier wrote: 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). 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 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. 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. 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 LayoutFrametransform: (without breaking Morphic). 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 The discussion is good, thank you. I don't think I have found the answers yet, but looking for them is fun too Florin
Re: [Pharo-dev] About ways to participate in community and general negativity
2014-10-03 17:03 GMT-03:00 stepharo steph...@free.fr: 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. I know that. What I am saying is: Why there is no voting process for libraries, tools, roadmaps, etc? Not for asking things to you but for getting an idea what's most wanted, where is the community. Some of you are scientists, you know the value of collecting data. I remembered there was a Pharo usage poll in 2012 : https://docs.google.com/forms/d/1sa01_h8_SFoPIrrXaAzpmmCBvnXgEpGzIyslnkcgTpk/viewform?formkey=dFZKeXUwaG80OWhSOGpZVERrX2ZlVGc6MQfromEmail=true I like that route. Even if people with the money don't care, let us believe we have the data, opinions, ideas, etc. You know like a modern democracy :) Definitely I would help building a poll, it doesn't *have* to include a Consortium member but that would be really nice. We could try smart questions. Anyone? 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. Ok for now I disagree a little bit, but I don't want to go there, I don't think that would be a productive discussion. 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. Because there is big money in 3D? 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. But there are entrepreneur networks like FounderDating and https://angel.co/ Of course they are not Google but they are a popular choice for initial investment. Someone using Pharo has passed the seed funding round? Or tried to present a business plan? Cheers, Hernán
Re: [Pharo-dev] About ways to participate in community and general negativity
Tudor Girba wrote: Hi Ben, On Sat, Oct 4, 2014 at 7:27 AM, Ben Coman b...@openinworld.com mailto:b...@openinworld.com wrote: Tudor Girba wrote: Hi, Indeed, you are right about noting that the situation will look different in a couple of months from now. Please, let's discuss these problems again in 2 months. My point was not to delay discussion, but just not let it get you down and be tolerant... * For those sending criticism, of the system being in flux as in progresses. * For those receiving criticism, when its comes from those using the bleeding edge because of their faith in Pharo * For third parties looking on, be confident that it will come together for the release. I am not asking for delaying the discussion about the tools. I am simply saying that the situation will be much different in a couple of months after we have a chance of taking the feedback into account (already quite some changes were made and more are under way, like the menu). As a consequence, we should evaluate the need of having them in parallel with other tools at that time not now. The classic tools are still around. Furthermore, in the Settings, you have a Glamorous Toolkit category which allows you to switch the Inspector and the Playground off. How hard would it be to run some parts of GToolkit in parallel with existing tools, rather than on/off? I'd rather it stare me in the face without boxing me in - to help me adapt in my own time. I tend to forget about things I need to change a setting for. It's not hard at all, but I believe it would defeat the purpose of the exercise at this point. First, I believe the problems being reported are actually minor and we should not overreact. Bare in mind that people mostly reacted to missing features, and not bugs (except for the messed up positioning of the cursor during completion) which is quite encouraging given the magnitude of the change. Second, when working on the latest version you want to exercise the new, not the old. The more options you allow to fallback to the old, the less stress will be applied on the new. And especially given that we are a small community, and that only a fraction of us actually works with the latest version, it would be highly unproductive to not focus on the new. Cheers, Doru Okay. That is a reasonable philosophy. -ben
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi Thierry, On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier thierry.goub...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
Le 04/10/2014 08:14, Tudor Girba a écrit : Hi Thierry, On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier thierry.goub...@gmail.com mailto:thierry.goub...@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). 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? 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. I do have specific tools I can use in such circumstances that you don't have. 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. Thierry Cheers, Doru -- www.tudorgirba.com http://www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About ways to participate in community and general negativity
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 tu...@tudorgirba.com wrote: Hi Thierry, On Sat, Oct 4, 2014 at 12:03 AM, Thierry Goubier thierry.goub...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi, On Sat, Oct 4, 2014 at 8:34 AM, Thierry Goubier thierry.goub...@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.goub...@gmail.com mailto:thierry.goub...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 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. 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). 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). Thierry
Re: [Pharo-dev] About ways to participate in community and general negativity
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
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi Thierry, On Sat, Oct 4, 2014 at 6:49 PM, Thierry Goubier thierry.goub...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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.al...@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 esteba...@gmail.com mailto:esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 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). (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. (3) Event handling does not get touch events. I've hacked this so far but a sustainable solution would be great. (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 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). Cheers, Jeff On Fri, Oct 3, 2014 at 7:44 AM, Esteban Lorenzano esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
2014-10-03 8:44 GMT-03:00 Esteban Lorenzano esteba...@gmail.com: 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. It is a matter of tolerance and patience. 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 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. :) In conclusion: not helping does not help :) Please consider than USING Pharo is a way to contribute to it. Even if you had infinite manpower but no one uses it, it would be worthless. Esteban, still grateful of belonging to this community ditto :) Regards!
Re: [Pharo-dev] About ways to participate in community and general negativity
On Fri, Oct 3, 2014 at 3:23 PM, Esteban A. Maringolo emaring...@gmail.com wrote: 2014-10-03 8:44 GMT-03:00 Esteban Lorenzano esteba...@gmail.com: 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. It is a matter of tolerance and patience. 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 Same boat here. So, I refuse to believe that we cannot be a cool and helpful community. We are. We are indeed. 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. :) We should Hangout more. In conclusion: not helping does not help :) Please consider than USING Pharo is a way to contribute to it. Even if you had infinite manpower but no one uses it, it would be worthless. +1 Esteban, still grateful of belonging to this community ditto :) ditto :) Regards! Peace, Phil
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
2014-10-03 9:27 GMT-03:00 kilon alios kilon.al...@gmail.com: 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. 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. 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. 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. I see years passing but money never comes. You cannot expect big funding if you keep doing things the same as always. 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. Yes, please stop rejecting feedback that you won't like. Cheers, Hernán
Re: [Pharo-dev] About ways to participate in community and general negativity
Generalisations and assumptions lead nowhere , personally I prefer someone that will tell me fuck you I don't like your attitude than someone that tries via diplomacy to make a point just so he does not raise the tentions and hurt egos. If there is such a problem as you claim and you are serious about addressing it then you will have to point the finger and engage in a discussion with those people. Maybe they are not as unreasonable as you think and if they are you can always show them the fire exit. Personally I cannot think of anyone that complains all the time and never is positive or complain the majority of the times. I also like what Thierry is claiming, there are times I wish that Pharo was a lot like Cuis and was aiming more at simplifying and minimising than extending. I am not saying that Pharoers should not try new ideas and improve existing I am talking strictly what goes inside the core. I don't want Pharo to grow to something the size of Java because frankly the community is too small to maintain so much code. But maybe I am wrong time will tell. If you want more people to contribute then it will be necessary to make the core smaller and easier to digest. Create a nice installer that then will install all the external stuff that can be as complex as they want to be. Configurations browser is a step towards the right direction and so is Versioner. On Fri, Oct 3, 2014 at 6:27 PM, Esteban Lorenzano esteba...@gmail.com wrote: 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.goub...@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 esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@gmail.com mailto:esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
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!
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@gmail.com mailto:esteba...@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 :)
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi, On Fri, Oct 3, 2014 at 9:48 PM, stepharo steph...@free.fr wrote: 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. TxText will happen. It's too important to leave it unhappening :). Doru -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About ways to participate in community and general negativity
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 esteba...@gmail.com mailto:esteba...@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
Re: [Pharo-dev] About ways to participate in community and general negativity
Le 03/10/2014 13:44, Esteban Lorenzano a écrit : I’m writing this because I’m sad about what is happening in this list. Hi Esteban, Don't be sad about negativity. I think it is a sign of good health for Pharo. First of all it is a feedback, it should raise a red flag somewhere: some expectation is not met, or an expectation for even better quality. Then it is a manifestation of hight interest and expectation regarding Pharo. After all the worst will be to ignore Pharo. Of course negative feedback are hard to manage emotionally, because those feedbacks can be improperly emotionally expressed. I guess with time people get thick skin to manage it. With Pharo becoming successful, the ratio of pure consumer will raise exponentially, there is nothing you can do with that, but well the net number of contributors will raise also... and still your number should not be that bad because your consumers are developers. (if you compare with DrGeo user, most are pure consumers) Hilaire -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] About ways to participate in community and general negativity
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
Re: [Pharo-dev] About ways to participate in community and general negativity
TxText will happen. It's too important to leave it unhappening :). Oh yes like OSWindow, GTToolkit and many other things. :) Stef
Re: [Pharo-dev] About ways to participate in community and general negativity
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
Re: [Pharo-dev] About ways to participate in community and general negativity
Thanks Hilaire. Yes you know it pretty well being a producer is sometimes tiring :) Stef Le 03/10/2014 13:44, Esteban Lorenzano a écrit : I’m writing this because I’m sad about what is happening in this list. Hi Esteban, Don't be sad about negativity. I think it is a sign of good health for Pharo. First of all it is a feedback, it should raise a red flag somewhere: some expectation is not met, or an expectation for even better quality. Then it is a manifestation of hight interest and expectation regarding Pharo. After all the worst will be to ignore Pharo. Of course negative feedback are hard to manage emotionally, because those feedbacks can be improperly emotionally expressed. I guess with time people get thick skin to manage it. With Pharo becoming successful, the ratio of pure consumer will raise exponentially, there is nothing you can do with that, but well the net number of contributors will raise also... and still your number should not be that bad because your consumers are developers. (if you compare with DrGeo user, most are pure consumers) Hilaire
Re: [Pharo-dev] About ways to participate in community and general negativity
2014-10-03 16:42 GMT-03:00 stepharo steph...@free.fr: 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. Please grant me a small exaggeration (which was the case). and if everybody would spend 1 hour per week reviewing and improving some 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). 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. 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. 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! 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
Re: [Pharo-dev] About ways to participate in community and general negativity
I agree 100% with Thierry. I wrote and complain about it months ago: we need consolidation in the newly developed stuff we have. 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. 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. -- Dr. Geo - http://drgeo.eu iStoa - http://istoa.drgeo.eu
Re: [Pharo-dev] About ways to participate in community and general negativity
Hi, The intention of the message of Esteban is to urge people to be positive. Nothing else. Keep in mind that email is a rather poor environment and simply ask yourself before sending a message if it can have a chance of leading to something better. Positive does not mean no criticism. On the contrary. We need criticism to improve. At the same time, we can always improve the way we deliver criticism. Let's just invest a bit in this positiveness and you will see how people will smile more and more things will get done :) Cheers, Doru On Fri, Oct 3, 2014 at 1:44 PM, Esteban Lorenzano esteba...@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 -- www.tudorgirba.com Every thing has its own flow
Re: [Pharo-dev] About ways to participate in community and general negativity
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
Re: [Pharo-dev] About ways to participate in community and general negativity
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. 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. 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
Re: [Pharo-dev] About ways to participate in community and general negativity
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,
