- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by kilon alios

by the way here are the blender guidelines if someone wants to take a taste ---> http://wiki.blender.org/index.php/Dev:Doc/Code_Style <http://wiki.blender.org/index.php/Dev:Doc/Code_Style> On Tue, Aug 5, 2014 at 1:37 PM, kilon alios <kilon.alios(a)gmail.com> wrote: > Blender wiki is badly maintained because developers are only forced to > document when they add a feature and not when they improve it etc So many > of the pages are outdated , pictures are from version years ago and look > very diffirent to modern versions of Blender. Its not a wiki problem its a > maintance problem. But Blender has a huge community of video tutorials > online. Even professional communities like Blendercookie and blenderguru. > So it can afford to not care so much about keeping everything uptodate. > Still people complain about the Blender wiki . > > If Pharo accepts source code that at least has proper class comments then > thats a big step forward. Even a hint of documentation is 1000 times better > than no documentation at all. I think that this will definitely bring more > people to contribute. I think I can also help there too. d > > Blender also takes advantage of auto documentation, python offers doc > strings, think of it as class comments and method comments with formatting. > For example you can embed a unit test inside the class comment and the test > will be runable by the user. The entire Blender API for python coders is > auto documented this way. So I agree this a really good idea for > documentation. > > Also pharo people have done a great job with Pier and Pillar. Its > definitely more powerful than a wiki and having a solution especially > tailored for Pharo is a big plus. We dont need a wiki. As long as > everything is linked back to the main website its fine. Pillar is much > easier to learn than Latex and not very dissimilar to wiki syntax. I am > very happy with pillar personally and Damien's conversion from Latex to > Pillar works very well too. > > Another good thing is that pharo documentation is really well written, > there are things that are missing but most of it is a very good state. Its > great not to have to rewrite documentation just because its not well > understood. So its only a matter of keeping it updated. > > > On Tue, Aug 5, 2014 at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> >> On 05 Aug 2014, at 11:05, kilon alios <kilon.alios(a)gmail.com> wrote: >> >> I don't question people contribution to Pharo. >> >> I do think however that we need to prioritize documentation. For example >> Blender development works in a way that a developers adding a feature to >> Blender main repo (not external code and external libraries) must add >> documentation to Blender wiki for the users. >> >> >> +1 >> we do not like wikis (bah, I like them, but others donâtâ¦ and they have a >> point: a wiki must be maintained, otherwise is a waist of time and effort). >> butâ¦ since Pharo4 we started a practice which is: we do not integrate any >> new stuff that is not correctly commented (in classes), with tests and (if >> possible), examples. >> >> in the long way this is the best because Pharo relies a lot in >> âautodocumentationâ. >> >> now, we can improve this: >> - even if new stuff has to come that way, most of the code inside image >> is poorly documented, tested and examples. We can improve that. We need to. >> I remember the comment per day Luc started a couple of years agoâ¦ is >> complicated to have them running in long way (until documentation is >> finished) because people get tired, but we could have a âtwo weeks >> commentsâ each three months or something like that. Not perfect, but better >> than what we have now. >> - I dream with PetitParser integrated into Pharo, and then a >> markdown/pillar parser into class comments, allowing us to have better >> formating and references, etc. to improve navigation. >> >> and of course, more can be done: >> -tutorials for newbies (your work on the videos is great there, btw!) >> -example projects in different areas (I think the laser game is a good >> one, but we need more âprofessionalâ examples: web apps, desktop apps, etc.) >> -etc. >> >> >> >> Also Blender has coding guidelines that need to be followed in order for >> code to added to main repo, does Pharo has something similar ? If yes where >> is such a document ? >> >> >> Not really (at least that I know). We should. >> >> >> Also Blender mailing list is very active with major bug fixes and >> features enhancement , in Pharo it looks to me that a lot of this >> discussion is located to fogbug . That means however than unless you >> frequent there its very difficult to track changes that affect your >> workflow. >> >> >> we still need to find the best workflow, yes. Iâm not happy with fogbugz >> in general, not because of the tool, which is great (and Iâm very grateful >> that we have it), but because it does not seems to adapt correctly to an >> open source project, or at least to our own project. Anyway, maybe if we >> continue the "moving to githubâ effort, probably we will prefer to use the >> github tracker, eventually (even if not as powerful as fogbugz). >> >> Esteban >> >> >> Not just Blender but many open source projects work similarly. >> >> >> On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >>> 2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>> >>> I can tell you why. Because its rarely is simple for people not familiar >>>> with Pharo like me. >>>> >>>> I once tried to help Damien with PharoLauncher. I added the progress >>>> bars you get when you download a new image it was simple as pie. Then >>>> Damien recommended for me to try to add support to PharoLauncher for CLI . >>>> I understand how Pharo does CLI stuff but was not able to understand >>>> anything about how PharoLauncher downloads and handles images. I literally >>>> spent hours trying to understand the internal architecture and gave up >>>> after 2 hours or so cause I had no clue how things worked. >>>> >>>> Also finding a bug to fix in Pharo is time consuming, you have to go >>>> through one bug after another till you find that you can figure out whats >>>> wrong and how to fix. Its not easy and its very annoying at times. >>>> >>>> Generally what kills me is lack of motivation, I don't like reading >>>> other's people code, I don't even like reading my code. I prefer >>>> documentation , If I am to fix a bug I want at least someone to show me how >>>> it works because figuring it by myself takes a lot of time and I am simply >>>> not willing to invest that time just because people find documentation >>>> something that should write one day when their software reaches version 1 >>>> meaning years later. >>>> >>>> So you want to motivate people to contribute to bug fixes ? Do not >>>> allow any code to enter pharo main distribution without full class >>>> comments. I really mean "full class comment" not 2 , or 3 lines. >>>> >>>> PBE has been left hanging years after the release of 1.4 , why ? you >>>> expect people to contribute to bug fixes even when the most basic of >>>> documentation is abandoned ? >>>> >>>> Sorry if I sound harsh but you wanted a honest answer . For me >>>> undocumented code is far more annoying than a bug or a missing feature. >>>> >>> >>> I find it a bit to harsh :) >>> +1 for more source code documentation, but keep in mind that there are >>> people that may not do proper documentation (even change code >>> or fix bugs and don't document their code) but doing A LOT for pharo >>> behind the scenes. >>> >>> >>> >>>> >>>> >>>> On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: >>>> >>>>> Hi guys >>>>> >>>>> I'm sure that most of you did not realize it, but Pharo does not >>>>> magically improve. It improves because some of us are looking >>>>> at the tracker issues and looking at the code and improving it. >>>>> >>>>> Since Pharo is yours I wonder why you do not take the time to improve. >>>>> In fact, this is the key advantage of true open-source: being able to have >>>>> an impact. An example, I was fed up to have a stupid widget to move >>>>> method between protocol and classes between packages. I fixed it. >>>>> It took my 20 min without knowing anything about Nautilus. >>>>> >>>>> And it improved Pharo Right now, Right there. >>>>> Of course if more people would be improving Pharo we could also focus >>>>> on enabling technology and frameworks. But >>>>> apparently we have to choose either we improve Pharo now or we invent >>>>> cool stuff that takes time. >>>>> I wonder why I do not go for the fame of writing a cool stuff instead >>>>> of just improving systematically the system. >>>>> >>>>> I wrote some roadmaps for people willing also to help. >>>>> >>>>> https://github.com/pharo-project/pharo-workingRoadmaps >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>> >> >> >

Aug. 5, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by kilon alios

Blender wiki is badly maintained because developers are only forced to document when they add a feature and not when they improve it etc So many of the pages are outdated , pictures are from version years ago and look very diffirent to modern versions of Blender. Its not a wiki problem its a maintance problem. But Blender has a huge community of video tutorials online. Even professional communities like Blendercookie and blenderguru. So it can afford to not care so much about keeping everything uptodate. Still people complain about the Blender wiki . If Pharo accepts source code that at least has proper class comments then thats a big step forward. Even a hint of documentation is 1000 times better than no documentation at all. I think that this will definitely bring more people to contribute. I think I can also help there too. d Blender also takes advantage of auto documentation, python offers doc strings, think of it as class comments and method comments with formatting. For example you can embed a unit test inside the class comment and the test will be runable by the user. The entire Blender API for python coders is auto documented this way. So I agree this a really good idea for documentation. Also pharo people have done a great job with Pier and Pillar. Its definitely more powerful than a wiki and having a solution especially tailored for Pharo is a big plus. We dont need a wiki. As long as everything is linked back to the main website its fine. Pillar is much easier to learn than Latex and not very dissimilar to wiki syntax. I am very happy with pillar personally and Damien's conversion from Latex to Pillar works very well too. Another good thing is that pharo documentation is really well written, there are things that are missing but most of it is a very good state. Its great not to have to rewrite documentation just because its not well understood. So its only a matter of keeping it updated. On Tue, Aug 5, 2014 at 12:20 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 05 Aug 2014, at 11:05, kilon alios <kilon.alios(a)gmail.com> wrote: > > I don't question people contribution to Pharo. > > I do think however that we need to prioritize documentation. For example > Blender development works in a way that a developers adding a feature to > Blender main repo (not external code and external libraries) must add > documentation to Blender wiki for the users. > > > +1 > we do not like wikis (bah, I like them, but others donâtâ¦ and they have a > point: a wiki must be maintained, otherwise is a waist of time and effort). > butâ¦ since Pharo4 we started a practice which is: we do not integrate any > new stuff that is not correctly commented (in classes), with tests and (if > possible), examples. > > in the long way this is the best because Pharo relies a lot in > âautodocumentationâ. > > now, we can improve this: > - even if new stuff has to come that way, most of the code inside image is > poorly documented, tested and examples. We can improve that. We need to. I > remember the comment per day Luc started a couple of years agoâ¦ is > complicated to have them running in long way (until documentation is > finished) because people get tired, but we could have a âtwo weeks > commentsâ each three months or something like that. Not perfect, but better > than what we have now. > - I dream with PetitParser integrated into Pharo, and then a > markdown/pillar parser into class comments, allowing us to have better > formating and references, etc. to improve navigation. > > and of course, more can be done: > -tutorials for newbies (your work on the videos is great there, btw!) > -example projects in different areas (I think the laser game is a good > one, but we need more âprofessionalâ examples: web apps, desktop apps, etc.) > -etc. > > > > Also Blender has coding guidelines that need to be followed in order for > code to added to main repo, does Pharo has something similar ? If yes where > is such a document ? > > > Not really (at least that I know). We should. > > > Also Blender mailing list is very active with major bug fixes and features > enhancement , in Pharo it looks to me that a lot of this discussion is > located to fogbug . That means however than unless you frequent there its > very difficult to track changes that affect your workflow. > > > we still need to find the best workflow, yes. Iâm not happy with fogbugz > in general, not because of the tool, which is great (and Iâm very grateful > that we have it), but because it does not seems to adapt correctly to an > open source project, or at least to our own project. Anyway, maybe if we > continue the "moving to githubâ effort, probably we will prefer to use the > github tracker, eventually (even if not as powerful as fogbugz). > > Esteban > > > Not just Blender but many open source projects work similarly. > > > On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> I can tell you why. Because its rarely is simple for people not familiar >>> with Pharo like me. >>> >>> I once tried to help Damien with PharoLauncher. I added the progress >>> bars you get when you download a new image it was simple as pie. Then >>> Damien recommended for me to try to add support to PharoLauncher for CLI . >>> I understand how Pharo does CLI stuff but was not able to understand >>> anything about how PharoLauncher downloads and handles images. I literally >>> spent hours trying to understand the internal architecture and gave up >>> after 2 hours or so cause I had no clue how things worked. >>> >>> Also finding a bug to fix in Pharo is time consuming, you have to go >>> through one bug after another till you find that you can figure out whats >>> wrong and how to fix. Its not easy and its very annoying at times. >>> >>> Generally what kills me is lack of motivation, I don't like reading >>> other's people code, I don't even like reading my code. I prefer >>> documentation , If I am to fix a bug I want at least someone to show me how >>> it works because figuring it by myself takes a lot of time and I am simply >>> not willing to invest that time just because people find documentation >>> something that should write one day when their software reaches version 1 >>> meaning years later. >>> >>> So you want to motivate people to contribute to bug fixes ? Do not allow >>> any code to enter pharo main distribution without full class comments. I >>> really mean "full class comment" not 2 , or 3 lines. >>> >>> PBE has been left hanging years after the release of 1.4 , why ? you >>> expect people to contribute to bug fixes even when the most basic of >>> documentation is abandoned ? >>> >>> Sorry if I sound harsh but you wanted a honest answer . For me >>> undocumented code is far more annoying than a bug or a missing feature. >>> >> >> I find it a bit to harsh :) >> +1 for more source code documentation, but keep in mind that there are >> people that may not do proper documentation (even change code >> or fix bugs and don't document their code) but doing A LOT for pharo >> behind the scenes. >> >> >> >>> >>> >>> On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> Hi guys >>>> >>>> I'm sure that most of you did not realize it, but Pharo does not >>>> magically improve. It improves because some of us are looking >>>> at the tracker issues and looking at the code and improving it. >>>> >>>> Since Pharo is yours I wonder why you do not take the time to improve. >>>> In fact, this is the key advantage of true open-source: being able to have >>>> an impact. An example, I was fed up to have a stupid widget to move >>>> method between protocol and classes between packages. I fixed it. >>>> It took my 20 min without knowing anything about Nautilus. >>>> >>>> And it improved Pharo Right now, Right there. >>>> Of course if more people would be improving Pharo we could also focus >>>> on enabling technology and frameworks. But >>>> apparently we have to choose either we improve Pharo now or we invent >>>> cool stuff that takes time. >>>> I wonder why I do not go for the fame of writing a cool stuff instead >>>> of just improving systematically the system. >>>> >>>> I wrote some roadmaps for people willing also to help. >>>> >>>> https://github.com/pharo-project/pharo-workingRoadmaps >>>> >>>> Stef >>>> >>>> >>>> >>> >> > >

Aug. 5, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by phil＠highoctane.be

I hate that there is no wiki. And the Squeak wiki is still useful to find out how some things do work internally. Phil On Tue, Aug 5, 2014 at 11:20 AM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 05 Aug 2014, at 11:05, kilon alios <kilon.alios(a)gmail.com> wrote: > > I don't question people contribution to Pharo. > > I do think however that we need to prioritize documentation. For example > Blender development works in a way that a developers adding a feature to > Blender main repo (not external code and external libraries) must add > documentation to Blender wiki for the users. > > > +1 > we do not like wikis (bah, I like them, but others donâtâ¦ and they have a > point: a wiki must be maintained, otherwise is a waist of time and effort). > butâ¦ since Pharo4 we started a practice which is: we do not integrate any > new stuff that is not correctly commented (in classes), with tests and (if > possible), examples. > > in the long way this is the best because Pharo relies a lot in > âautodocumentationâ. > > now, we can improve this: > - even if new stuff has to come that way, most of the code inside image is > poorly documented, tested and examples. We can improve that. We need to. I > remember the comment per day Luc started a couple of years agoâ¦ is > complicated to have them running in long way (until documentation is > finished) because people get tired, but we could have a âtwo weeks > commentsâ each three months or something like that. Not perfect, but better > than what we have now. > - I dream with PetitParser integrated into Pharo, and then a > markdown/pillar parser into class comments, allowing us to have better > formating and references, etc. to improve navigation. > > and of course, more can be done: > -tutorials for newbies (your work on the videos is great there, btw!) > -example projects in different areas (I think the laser game is a good > one, but we need more âprofessionalâ examples: web apps, desktop apps, etc.) > -etc. > > > > Also Blender has coding guidelines that need to be followed in order for > code to added to main repo, does Pharo has something similar ? If yes where > is such a document ? > > > Not really (at least that I know). We should. > > > Also Blender mailing list is very active with major bug fixes and features > enhancement , in Pharo it looks to me that a lot of this discussion is > located to fogbug . That means however than unless you frequent there its > very difficult to track changes that affect your workflow. > > > we still need to find the best workflow, yes. Iâm not happy with fogbugz > in general, not because of the tool, which is great (and Iâm very grateful > that we have it), but because it does not seems to adapt correctly to an > open source project, or at least to our own project. Anyway, maybe if we > continue the "moving to githubâ effort, probably we will prefer to use the > github tracker, eventually (even if not as powerful as fogbugz). > > Esteban > > > Not just Blender but many open source projects work similarly. > > > On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > >> 2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> I can tell you why. Because its rarely is simple for people not familiar >>> with Pharo like me. >>> >>> I once tried to help Damien with PharoLauncher. I added the progress >>> bars you get when you download a new image it was simple as pie. Then >>> Damien recommended for me to try to add support to PharoLauncher for CLI . >>> I understand how Pharo does CLI stuff but was not able to understand >>> anything about how PharoLauncher downloads and handles images. I literally >>> spent hours trying to understand the internal architecture and gave up >>> after 2 hours or so cause I had no clue how things worked. >>> >>> Also finding a bug to fix in Pharo is time consuming, you have to go >>> through one bug after another till you find that you can figure out whats >>> wrong and how to fix. Its not easy and its very annoying at times. >>> >>> Generally what kills me is lack of motivation, I don't like reading >>> other's people code, I don't even like reading my code. I prefer >>> documentation , If I am to fix a bug I want at least someone to show me how >>> it works because figuring it by myself takes a lot of time and I am simply >>> not willing to invest that time just because people find documentation >>> something that should write one day when their software reaches version 1 >>> meaning years later. >>> >>> So you want to motivate people to contribute to bug fixes ? Do not allow >>> any code to enter pharo main distribution without full class comments. I >>> really mean "full class comment" not 2 , or 3 lines. >>> >>> PBE has been left hanging years after the release of 1.4 , why ? you >>> expect people to contribute to bug fixes even when the most basic of >>> documentation is abandoned ? >>> >>> Sorry if I sound harsh but you wanted a honest answer . For me >>> undocumented code is far more annoying than a bug or a missing feature. >>> >> >> I find it a bit to harsh :) >> +1 for more source code documentation, but keep in mind that there are >> people that may not do proper documentation (even change code >> or fix bugs and don't document their code) but doing A LOT for pharo >> behind the scenes. >> >> >> >>> >>> >>> On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: >>> >>>> Hi guys >>>> >>>> I'm sure that most of you did not realize it, but Pharo does not >>>> magically improve. It improves because some of us are looking >>>> at the tracker issues and looking at the code and improving it. >>>> >>>> Since Pharo is yours I wonder why you do not take the time to improve. >>>> In fact, this is the key advantage of true open-source: being able to have >>>> an impact. An example, I was fed up to have a stupid widget to move >>>> method between protocol and classes between packages. I fixed it. >>>> It took my 20 min without knowing anything about Nautilus. >>>> >>>> And it improved Pharo Right now, Right there. >>>> Of course if more people would be improving Pharo we could also focus >>>> on enabling technology and frameworks. But >>>> apparently we have to choose either we improve Pharo now or we invent >>>> cool stuff that takes time. >>>> I wonder why I do not go for the fame of writing a cool stuff instead >>>> of just improving systematically the system. >>>> >>>> I wrote some roadmaps for people willing also to help. >>>> >>>> https://github.com/pharo-project/pharo-workingRoadmaps >>>> >>>> Stef >>>> >>>> >>>> >>> >> > >

Aug. 5, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by Esteban Lorenzano

On 05 Aug 2014, at 11:05, kilon alios <kilon.alios(a)gmail.com> wrote: > I don't question people contribution to Pharo. > > I do think however that we need to prioritize documentation. For example Blender development works in a way that a developers adding a feature to Blender main repo (not external code and external libraries) must add documentation to Blender wiki for the users. +1 we do not like wikis (bah, I like them, but others donâtâ¦ and they have a point: a wiki must be maintained, otherwise is a waist of time and effort). butâ¦ since Pharo4 we started a practice which is: we do not integrate any new stuff that is not correctly commented (in classes), with tests and (if possible), examples. in the long way this is the best because Pharo relies a lot in âautodocumentationâ. now, we can improve this: - even if new stuff has to come that way, most of the code inside image is poorly documented, tested and examples. We can improve that. We need to. I remember the comment per day Luc started a couple of years agoâ¦ is complicated to have them running in long way (until documentation is finished) because people get tired, but we could have a âtwo weeks commentsâ each three months or something like that. Not perfect, but better than what we have now. - I dream with PetitParser integrated into Pharo, and then a markdown/pillar parser into class comments, allowing us to have better formating and references, etc. to improve navigation. and of course, more can be done: -tutorials for newbies (your work on the videos is great there, btw!) -example projects in different areas (I think the laser game is a good one, but we need more âprofessionalâ examples: web apps, desktop apps, etc.) -etc. > > Also Blender has coding guidelines that need to be followed in order for code to added to main repo, does Pharo has something similar ? If yes where is such a document ? Not really (at least that I know). We should. > > Also Blender mailing list is very active with major bug fixes and features enhancement , in Pharo it looks to me that a lot of this discussion is located to fogbug . That means however than unless you frequent there its very difficult to track changes that affect your workflow. we still need to find the best workflow, yes. Iâm not happy with fogbugz in general, not because of the tool, which is great (and Iâm very grateful that we have it), but because it does not seems to adapt correctly to an open source project, or at least to our own project. Anyway, maybe if we continue the "moving to githubâ effort, probably we will prefer to use the github tracker, eventually (even if not as powerful as fogbugz). Esteban > > Not just Blender but many open source projects work similarly. > > > On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > I can tell you why. Because its rarely is simple for people not familiar with Pharo like me. > > I once tried to help Damien with PharoLauncher. I added the progress bars you get when you download a new image it was simple as pie. Then Damien recommended for me to try to add support to PharoLauncher for CLI . I understand how Pharo does CLI stuff but was not able to understand anything about how PharoLauncher downloads and handles images. I literally spent hours trying to understand the internal architecture and gave up after 2 hours or so cause I had no clue how things worked. > > Also finding a bug to fix in Pharo is time consuming, you have to go through one bug after another till you find that you can figure out whats wrong and how to fix. Its not easy and its very annoying at times. > > Generally what kills me is lack of motivation, I don't like reading other's people code, I don't even like reading my code. I prefer documentation , If I am to fix a bug I want at least someone to show me how it works because figuring it by myself takes a lot of time and I am simply not willing to invest that time just because people find documentation something that should write one day when their software reaches version 1 meaning years later. > > So you want to motivate people to contribute to bug fixes ? Do not allow any code to enter pharo main distribution without full class comments. I really mean "full class comment" not 2 , or 3 lines. > > PBE has been left hanging years after the release of 1.4 , why ? you expect people to contribute to bug fixes even when the most basic of documentation is abandoned ? > > Sorry if I sound harsh but you wanted a honest answer . For me undocumented code is far more annoying than a bug or a missing feature. > > I find it a bit to harsh :) > +1 for more source code documentation, but keep in mind that there are people that may not do proper documentation (even change code > or fix bugs and don't document their code) but doing A LOT for pharo behind the scenes. > > > > > On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: > Hi guys > > I'm sure that most of you did not realize it, but Pharo does not magically improve. It improves because some of us are looking > at the tracker issues and looking at the code and improving it. > > Since Pharo is yours I wonder why you do not take the time to improve. In fact, this is the key advantage of true open-source: being able to have > an impact. An example, I was fed up to have a stupid widget to move method between protocol and classes between packages. I fixed it. > It took my 20 min without knowing anything about Nautilus. > > And it improved Pharo Right now, Right there. > Of course if more people would be improving Pharo we could also focus on enabling technology and frameworks. But > apparently we have to choose either we improve Pharo now or we invent cool stuff that takes time. > I wonder why I do not go for the fame of writing a cool stuff instead of just improving systematically the system. > > I wrote some roadmaps for people willing also to help. > > https://github.com/pharo-project/pharo-workingRoadmaps > > Stef > > > > >

Aug. 5, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by kilon alios

I don't question people contribution to Pharo. I do think however that we need to prioritize documentation. For example Blender development works in a way that a developers adding a feature to Blender main repo (not external code and external libraries) must add documentation to Blender wiki for the users. Also Blender has coding guidelines that need to be followed in order for code to added to main repo, does Pharo has something similar ? If yes where is such a document ? Also Blender mailing list is very active with major bug fixes and features enhancement , in Pharo it looks to me that a lot of this discussion is located to fogbug . That means however than unless you frequent there its very difficult to track changes that affect your workflow. Not just Blender but many open source projects work similarly. On Tue, Aug 5, 2014 at 1:13 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: > 2014-08-04 22:37 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > > I can tell you why. Because its rarely is simple for people not familiar >> with Pharo like me. >> >> I once tried to help Damien with PharoLauncher. I added the progress bars >> you get when you download a new image it was simple as pie. Then Damien >> recommended for me to try to add support to PharoLauncher for CLI . I >> understand how Pharo does CLI stuff but was not able to understand anything >> about how PharoLauncher downloads and handles images. I literally spent >> hours trying to understand the internal architecture and gave up after 2 >> hours or so cause I had no clue how things worked. >> >> Also finding a bug to fix in Pharo is time consuming, you have to go >> through one bug after another till you find that you can figure out whats >> wrong and how to fix. Its not easy and its very annoying at times. >> >> Generally what kills me is lack of motivation, I don't like reading >> other's people code, I don't even like reading my code. I prefer >> documentation , If I am to fix a bug I want at least someone to show me how >> it works because figuring it by myself takes a lot of time and I am simply >> not willing to invest that time just because people find documentation >> something that should write one day when their software reaches version 1 >> meaning years later. >> >> So you want to motivate people to contribute to bug fixes ? Do not allow >> any code to enter pharo main distribution without full class comments. I >> really mean "full class comment" not 2 , or 3 lines. >> >> PBE has been left hanging years after the release of 1.4 , why ? you >> expect people to contribute to bug fixes even when the most basic of >> documentation is abandoned ? >> >> Sorry if I sound harsh but you wanted a honest answer . For me >> undocumented code is far more annoying than a bug or a missing feature. >> > > I find it a bit to harsh :) > +1 for more source code documentation, but keep in mind that there are > people that may not do proper documentation (even change code > or fix bugs and don't document their code) but doing A LOT for pharo > behind the scenes. > > > >> >> >> On Mon, Aug 4, 2014 at 10:51 PM, stepharo <stepharo(a)free.fr> wrote: >> >>> Hi guys >>> >>> I'm sure that most of you did not realize it, but Pharo does not >>> magically improve. It improves because some of us are looking >>> at the tracker issues and looking at the code and improving it. >>> >>> Since Pharo is yours I wonder why you do not take the time to improve. >>> In fact, this is the key advantage of true open-source: being able to have >>> an impact. An example, I was fed up to have a stupid widget to move >>> method between protocol and classes between packages. I fixed it. >>> It took my 20 min without knowing anything about Nautilus. >>> >>> And it improved Pharo Right now, Right there. >>> Of course if more people would be improving Pharo we could also focus on >>> enabling technology and frameworks. But >>> apparently we have to choose either we improve Pharo now or we invent >>> cool stuff that takes time. >>> I wonder why I do not go for the fame of writing a cool stuff instead of >>> just improving systematically the system. >>> >>> I wrote some roadmaps for people willing also to help. >>> >>> https://github.com/pharo-project/pharo-workingRoadmaps >>> >>> Stef >>> >>> >>> >> >

Aug. 5, 2014

Re: [Pharo-dev] About your contributions: Improve Pharo right now, right there.

by phil＠highoctane.be

It looks like the older site had more information of these aspects. http://old.pharo-project.org/community/issue-tracking (yes, the video is dead indeed). I had a walk on the various pages and indeed there are a lot of problems for someone to find the way to do things. Why is the video gone ? Phil On Tue, Aug 5, 2014 at 12:53 AM, Tim Mackinnon <tim(a)testit.works> wrote: > Benjamin - I feel your pain. I went through the same thing - and I did try > to > help things by updating some of the information on the FogBugz wiki (which > I > think you found - at least the video). > > I know I hit a bunch of 404 errors too - which I corrected, but I can see > that you hit a few more - so I've tried to fix them too. > > The Fogbugz wiki now points to the contributions wiki page (as that's > easier > to edit) - and then I've also pointed that page onto the pharo.org > contributions page. I'm sure there are more corrections that can be made > - > if you ask Marcus, he can give you wiki edit priv's so you can correct > things as well. > > However - there is a bigger question for the community, where should the > main documentation be? We have some on the Fogbugz wiki and some on > Pharo.org - and they conflict with each other? > > I would suggest that more generic/simple info should be on pharo.org (e.g. > stuff that doesn't change too much, and that we can polish and make it look > slick) - and then we link things back to Fogbugz where the details can be > edited and updated by the wider community? (which is what I have tried to > do > having hit the same stumbling block as Benjamin). > > Tim > > > > -- > View this message in context: > http://forum.world.st/About-your-contributions-Improve-Pharo-right-now-righ… > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > >

Aug. 5, 2014

Re: [Pharo-dev] Can forking speed up anything?

by David T. Lewis

On Mon, Aug 04, 2014 at 02:53:07PM +0200, Levente Uzonyi wrote: > On Mon, 4 Aug 2014, Frank Shearar wrote: > > >On 4 August 2014 09:38, Cl??ment Bera <bera.clement(a)gmail.com> wrote: > >> > >> > >> > >>2014-08-04 10:17 GMT+02:00 Yuriy Tymchuk <yuriy.tymchuk(a)me.com>: > >>> > >>>Hi guys, > >>> > >>>I have a script that runs very slow and does a lot of non dependent > >>>operation of a collection. I wander if I can speed it up by making it > >>>run in > >>>another process, because as far as I understand everything runs on a > >>>single > >>>thread, so I guess this won???t save me. > >>> > >>I don't think forking can speed up anything. > > > >But that's only because we're single-threaded, hence single-cored. If > >we had a VM that handle multiple threads (like if we resuscitated > >Andreas' and Igor's Hydra work), then forking _would_ speed things up. > >But that would raise another huge issue, namely the shared state > >nature of the image. > > Hydra works differently. It's basically running multiple images from a > single VM, and provides channels between images for communication (like in > Erlang). There's no shared state at all between images, and one image can > only use one core just like now. > It's also possible to use multiple cores by spawning new VMs. IIRC > OSProcess has some support for this. > OSProcess + CommandShell does this in class RemoteTask. A RemoteTask spawns a VM with forked image, and uses Fuel to serialize the results back to the parent image/VM. But Pharo may be missing the necessary VM and plugin support, so I'm not sure if it works in Pharo now. But I have to say that this is unlikely to useful as a performance enhancement except in very specialized cases where large chunks of work can be run in completely independent parallel tasks. Dave

Aug. 5, 2014

Re: [Pharo-dev] Can forking speed up anything?

by S Krish

http://stackoverflow.com/questions/5919172/gpgpu-vs-multicore The answer is really nice.. over GPU/ multithreaded CPU et als. GPU is not a panacea for enterprise programming, but for specific parallel unbranched-no synchronization driven algorithms * The worst code for GPU is code with less parallelism or code with lots of branches or synchronization. * Easily vectorizable code: CPU is easier to code but low performance. GPU is slightly harder to code but provides big bang for the buck. For all others, CPU is easier and often better performance as well. * GPUs don't support interrupts and exception. On Tue, Aug 5, 2014 at 1:00 AM, stepharo <stepharo(a)free.fr> wrote: > > On 4/8/14 19:46, Alexandre Bergel wrote: > >> Hi Yuriy, >> >> My advice is to use OpenCL. OpenCL is a standard to use the graphical >> card to carry out massive computation. >> The good news is that Ronie has worked on a binding between OpenCL and >> Pharo. I am using it and it works pretty well. >> http://smalltalkhub.com/#!/~ronsaldo/OpenCL >> > > Alex > > first a good algorithm with a controlled complexity is important. > If you have a naive algorithm you can wait that the Universe die > before getting a result. > I remember doing stupid algorithm that we speed up with roel from a > couple of hours to 20 s. > > Second OpenCL binds you to system having openCL support and this is > important to understand it. > > Stef > >> >> Cheers, >> Alexandre >> > > >

Aug. 5, 2014

New CogVMs available

by Eliot Miranda

...at http://www.mirandabanda.org/files/Cog/VM/VM.r3058/. CogVM binaries as per VMMaker.oscog-eem.842/r3058 Spur: Provide unpinObject: for InterpreterProxy. Fix initialization of the heap-resident remembered set added by VMMaker.oscog-eem.827. It must be created /after/ old space is initialized. Fix two become bugs surfaced when adding/removing inst vars to/from Association, Binding et al. First, the class table must be scanned to ensure there are no forwarders to classes (much cheaper than the full hierarchy walk to follow method dictionaries etc that was done). Second, machine code methods that gain a new reference through become must get added to the youngReferrers. Add a new become effect flag, OldBecameNew that captures this and respond to it in CoInterpreter>>postBecomeAction: by adding all methods to youngReferrers so that on the next scavenge all will be made right. Fix GC of machine code, which must follow forwarders when doing markAndTraceLiteral: and again add to youngReferrers if following gains a new ref. Refactoring of markAndTraceLiteral: into markAndTraceLiteral:in:at: et al required. Fix assert in addFreeSubTree:. General: Support the alternate bytecode set header in all VMs to ease testing of multiple bytecode sets. This means methods with the sign bit set have no primitive field and a larger num literals field, but no more. Fix longPrintOop: (actually printOopShortInner:) for global variable printing in face of new Environments. Cogit: Clean up adding to the youngReferrers by providing ensureInYoungReferrers:. Since there always is room on youngReferrers, nuke roomOnYoungReferrersList, canLinkToYoungClasses and caller code, simplifying ceSend:super:to:numArgs: etc. Fix assert in followForwardedLiteralsIn: General: Change the scanning for initial nils scheme in the StackToRegisterMappingCogit to answer the number of push nils in a bytecode, instead of whether the bytecode is a push nil. Refactor genReturnTopFromBlock into genBlockReturn. These changes accomodate Sista. Rationalize the length functions, deleting byteLengthOf:, fetchLong32LengthOf: & fetchWordLengthOf: and providing numBytesOf:, num16BitUnitsOf:, num32BitUnitsOf:, num64BitUnitsOf: and numBytesOf:. Provide fetch/storeShort16:ofObject:[withValue:] and fetch/storeLong64:ofObject:[withValue:]. -- best, Eliot

Aug. 5, 2014

Re: [Pharo-dev] [pharo-project/pharo-core] ea9df7: 40138

by Sean P. DeNigris

stepharo wrote > you could also provide code :) Nicolai beat me to it :) https://pharo.fogbugz.com/default.asp?13770#BugEvent.106854 ----- Cheers, Sean -- View this message in context: http://forum.world.st/pharo-project-pharo-core-ea9df7-40138-tp4770903p47718… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

Aug. 5, 2014