- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo for Professional Development

by Bart Gauquie

Hi, The point I'm trying to make is that even on an alpha release, everything that worked before should still work perfectly. The new stuff being added are first buggy; seems normal to me. But if the new stuff is breaking old, working stuff, and we only notice it after a month; then it will take us a lot of time, debugging the issues, investigating them; time we should spent instead on adding new stuff. The feeling I have is that most of the code is unit tested, which is fine; but that little code is integration tested. The bug I described above is a misconfiguration between some packages, and since the environment itself are also just packages, there should be some integration test to test the pharoxxx.dev.image to see if everything is integrating correctly with each other. I mean a testcase which just opens a browser and 'clicks' on all items to see if everything is still working. On my day to day work I firmly believe in taking small steps, making sure that these small steps don't break anything. And if there is a test failing then, taking that small step; i immediately get the feedback that my small change has influence on some other part of the system, which I did not see before. Every bug we find is first reproduced by writing a failing test for it. Like this we are sure we fix the right thing, and furthermore we are sure that this bug will never reoccur again. We used to have someone on the team who got furious if only one file was committed during a change which added behaviour. She was right: every change should have a corresponding test. Again about the bug I posted. How would this issue be fixed? How can I fix this? I can in the O2classes / test create a 'mock' description which knows the packages instead of the package message. And then fix it then, that seems to be step one. However I did not actually reproduce the bug, since the bug was: I click in a System browser, and call browse package, which failed. It is that kind of test I want to write for it. Since the tools are part of the environment, they should be integration tested. I will make an attempt to write such a test. |The Smalltalk "tradition" slightly differs here, as the more tolerant |developers use the alpha build, but people doing production work use the |latest stable release (in this case 1.0). |I've done a number of production applications in Squeak and we always |used the stable version for that. Or, in case we really needed something |from the trunk version, we only updated occasionally when we were sure |it had reached a somewhat stable plateau. You're correct on this one, however in this case, Pharo IS the production work. It is Pharo itself we are also developing. And since it is development, I think we should make sure the quality keeps up at a highest level possible, even if modifying it. I don't mean to criticize, I love the opensource initiative that Pharo is, I'm just trying to help Pharo further. Any other thoughts on this? Kind Regards, Bart

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Marcus Denker

On Dec 18, 2009, at 10:34 AM, Bart Gauquie wrote: > Hi Marcus, > > I can understand your reasoning. The point I was trying to make is that even for the 1.1 alpha release everything should be stable that was stable before. I really appreciate the effort everybody does in it; the new stuff being added and all; but breaking things that worked before is not improving. If its not stable, nobody will use it. I think we should rename 1.1. It's not #alpha, it's #unstable. Marcus

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Michael Rueger

Bart Gauquie wrote: > Hi Marcus, > > I can understand your reasoning. The point I was trying to make is that > even for the 1.1 alpha release everything should be stable that was > stable before. I really appreciate the effort everybody does in it; the > new stuff being added and all; but breaking things that worked before is > not improving. If its not stable, nobody will use it. Would you use Eclipse's nightly builds? No? Then don't use 1.1 alpha, same thing. The Smalltalk "tradition" slightly differs here, as the more tolerant developers use the alpha build, but people doing production work use the latest stable release (in this case 1.0). I've done a number of production applications in Squeak and we always used the stable version for that. Or, in case we really needed something from the trunk version, we only updated occasionally when we were sure it had reached a somewhat stable plateau. Michael

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by laurent laffont

On Fri, Dec 18, 2009 at 9:32 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > > For Christmas, I would like :) > > - tab support because my laptop has a small screen > > How are tabs different to the taskbar with all windows maximized? > I want to see Transcript / Workspace / .... at the same time. But I will try to work the way you do. I've also played with layouts trying to have windows behave like Ion ( http://modeemi.fi/~tuomov/ion/intro.html) > > I implemented tabs for OB a few years back, but then came the taskbar > which i found more useful (and faster). > OK Laurent

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Bart Gauquie

Hi Marcus, I can understand your reasoning. The point I was trying to make is that even for the 1.1 alpha release everything should be stable that was stable before. I really appreciate the effort everybody does in it; the new stuff being added and all; but breaking things that worked before is not improving. If its not stable, nobody will use it. I make a bug report for every fault I notice. And I'm perfectly happy to live with it; I'm however not sure everyone does. I want to fix bugs also. Allow me to give another example to indicate what I mean : Just now, I've been looking into http://code.google.com/p/pharo/issues/detail?id=1570 I've reported last week. I was using the dev image for this. I'm not using the Core image, since there I'm missing essential tools I need. The error was that in the system browser browse package did not work anymore. I've looked into the issue , the cause of it is that Lukas updated Refactoring-Core-lr81.mcz, adding: 'the package environment can work on multiple packages now'; thereby deleting the package message, replacing it by the packages message. Of course the OR2EnvironmentNode>>packageCategories which failes is still using the package message, and not the new one. I can off course quickly fix it by adding packages first or something, but that is not the point I want to make. The point is that a development environment should be stable. I'm also not judging or finger pointing or anything. I'm just giving an example to indicate that this is not good, that essential behaviour just from one version to the other can break and we don't even notice it, till someone tries it. And figuring a bug which cause was almost a month ago is more difficult and takes a lot more of our precious time than noticing it directly. So again also my question: is there a way to for instance test that if I open a SystemBrowser, navigate to a class, and execute the browse package command that a package browser window is opened on it; so like this I can test if any regression took place. If I look at the milestones for 1.1 I notice that there is a Continuous integration system planned. This is good, very good, actually essential. We should really try to do Continuous Integration, even in the development 1.1 branch; more forward in small but certain steps. Kind Regards, Bart On Fri, Dec 18, 2009 at 10:19 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Dec 18, 2009, at 9:41 AM, Bart Gauquie wrote: > > > Dear all, > > > > I've been using Squeak before, now I'm using Pharo. Its still 'hobby' > usage. However, on my firm, we have a lot of working groups in which we > investigate new technologies. We mainly use Java / .Net. > > I've initiated a working group around Smalltalk/Seaside. And chose Pharo > as a smalltalk platform/dialect, mainly because its free and adaptable. I'm > a fan of it, but my colleagues of it have some doubts about it. I know that > its not finished yet, and that a lot of improvements are ongoing. The main > 'complaint' about Pharo is that the environment is not stable. In a lot of > the tools you get exceptions, errors, it breaks something, stuff like that. > Thats a shame off course. I expect in an environment that everything just > works. We are using Eclipse in our day to day work; nowadays, Eclipse is > quite fast and is reliable. Pharo is more or less fast enough, but still not > reliable. There are too much 'dead links', messageNotUnderStoods I mean. For > instance on latests browse package is not working on the Class Browser. On > the Pharo 1.0 branch, there are also dead links here and there. > > > 1.1 can not be stable. How on earth can you do anything if even the > bleading edge developement-only release can not move? > > Do *not* use 1.1 if you are not willing to live with a bug *and* are > willing to help fixing it. > > If you see bugs in 1.0, How Can We Fix them if they are not reported? > > > Marcus > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- imagination is more important than knowledge - Albert Einstein Logic will get you from A to B. Imagination will take you everywhere - Albert Einstein Learn from yesterday, live for today, hope for tomorrow. The important thing is not to stop questioning. - Albert Einstein The true sign of intelligence is not knowledge but imagination. - Albert Einstein Gravitation is not responsible for people falling in love. - Albert Einstein

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Adrian Lienhard

Hi Bart, Thanks for the feedback. You make some good points. If you want to help make Pharo better, please report bugs! Stability is important for us. That is why we have a 1.0 that is stabilizing, and a 1.1 alpha branch at the moment. We don't just commit everything into one trunk... After 1.0 is released, there will be maintenance updates for important fixes. Cheers Adrian On Dec 18, 2009, at 09:41 , Bart Gauquie wrote: > Dear all, > > I've been using Squeak before, now I'm using Pharo. Its still > 'hobby' usage. > However, on my firm, we have a lot of working groups in which we > investigate > new technologies. We mainly use Java / .Net. > I've initiated a working group around Smalltalk/Seaside. And chose > Pharo as > a smalltalk platform/dialect, mainly because its free and adaptable. > I'm a > fan of it, but my colleagues of it have some doubts about it. I know > that > its not finished yet, and that a lot of improvements are ongoing. > The main > 'complaint' about Pharo is that the environment is not stable. In a > lot of > the tools you get exceptions, errors, it breaks something, stuff > like that. > Thats a shame off course. I expect in an environment that everything > just > works. We are using Eclipse in our day to day work; nowadays, > Eclipse is > quite fast and is reliable. Pharo is more or less fast enough, but > still not > reliable. There are too much 'dead links', messageNotUnderStoods I > mean. For > instance on latests browse package is not working on the Class > Browser. On > the Pharo 1.0 branch, there are also dead links here and there. > > So therefore my question: I highly support that Pharo wants to > innovate ; > BUT as a developer I first expect that every tool works perfectly, > that I > can trust it. Furthermore, since Smalltalk environment is written in > itself, > I expect that every tool is also thoroughly unit tested to avoid > regression > on the tools. I don't know if it is possible to test the Morphic > windows in > Pharo. Rephrasing: I think we should focus a lot on making the current > system stable, and keeping it stable; and focus on fixing bugs asap > (and not > just quickly fixing the bug, first at least write a test for it). > All these > new stuff like NewCompiler, Settings, in the 1.1 are very valuable > stuff to > add; but we should really keep focusing on stability. I'm saying this > because, what I've noticed is that my colleagues are trying the other > smalltalks like Cincom; the only reason that that they are doing > this , is > because the environment is not stable enough: I suspect that a lot > of other > people are also doing this? > > I've noticed that there are quite some regression bugs (for instance: > http://code.google.com/p/pharo/issues/detail?id=349) it worked in > version x > but now is not working anymore. If you have a lot of these, you lose > a lot > of time. I'd rather make one slow step forward, instead of rushing > forward > and having to back up. > > Furthermore I still had some other tools I found very useful in my > day to > day work that I'm missing in Pharo > - Proper keyboard shortcuts: see other thread, did not have time yet > to put > something on wiki > - History of a file: you can always check the local history of a file > (comparable with the versions of a message in Pharo), but you can in > the > same view also see the version of the file on the repository - > regardless > which versioning system you're using. And quickly open these versions, > select 2 of these versions and compare them with each other. This is > very > valuable tool if you're developing with a lot of people on the same > to see > every version created and quickly be able to compare them. Is there > such > functionality in Pharo ? > - ... > > Any thoughts on this? > > Kind Regards, > > Bart > > -- > imagination is more important than knowledge - Albert Einstein > Logic will get you from A to B. Imagination will take you everywhere - > Albert Einstein > Learn from yesterday, live for today, hope for tomorrow. The > important thing > is not to stop questioning. - Albert Einstein > The true sign of intelligence is not knowledge but imagination. - > Albert > Einstein > Gravitation is not responsible for people falling in love. - Albert > Einstein > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Marcus Denker

On Dec 18, 2009, at 9:41 AM, Bart Gauquie wrote: > Dear all, > > I've been using Squeak before, now I'm using Pharo. Its still 'hobby' usage. However, on my firm, we have a lot of working groups in which we investigate new technologies. We mainly use Java / .Net. > I've initiated a working group around Smalltalk/Seaside. And chose Pharo as a smalltalk platform/dialect, mainly because its free and adaptable. I'm a fan of it, but my colleagues of it have some doubts about it. I know that its not finished yet, and that a lot of improvements are ongoing. The main 'complaint' about Pharo is that the environment is not stable. In a lot of the tools you get exceptions, errors, it breaks something, stuff like that. Thats a shame off course. I expect in an environment that everything just works. We are using Eclipse in our day to day work; nowadays, Eclipse is quite fast and is reliable. Pharo is more or less fast enough, but still not reliable. There are too much 'dead links', messageNotUnderStoods I mean. For instance on latests browse package is not working on the Class Browser. On the Pharo 1.0 branch, there are also dead links here and there. > 1.1 can not be stable. How on earth can you do anything if even the bleading edge developement-only release can not move? Do *not* use 1.1 if you are not willing to live with a bug *and* are willing to help fixing it. If you see bugs in 1.0, How Can We Fix them if they are not reported? Marcus

Dec. 18, 2009

Re: [Pharo-project] Services

by StÃ©phane Ducasse

Alain service were developed by romain robbes. We pushed that in 3.9 with the hope that it would be an important architectural backbone now few applications use it. And in the future we will have to think about what to do. For example FileList is using it. Ideally the menu or menubar could use them. Now it requires a deeper analysis and vision. I believe that this is important but there is a difference between important and used. Stef On Dec 17, 2009, at 10:25 PM, Alain Plantec wrote: > Alain Plantec a Ã©crit : >> gloups! >> I've just discovered that the Preferences class has a child. >> yes, yes, it is the ServicePreferences class with a dictionary full of >> Preference instances. >> So, I was always wondering, what are services ? are they used ? > I've browsed a little bit, now I think I understand, it's a kind of > service providing framework > which allows dynamically built menus > and yes it seems to be used. >> I don't know if I will have enough energy for that but do you think it >> is possible to >> use pragmas as we do for settings ? use the Setting browser for >> services ? (Lukas ?) >> thanks >> Alain >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by StÃ©phane Ducasse

On Dec 17, 2009, at 10:23 PM, Mariano Martinez Peck wrote: > > > On Thu, Dec 17, 2009 at 10:12 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > I don't use it, and I think all the people that don't use it is for > > the same reason, and it is because it is REALLY slow. Even in good > > machines. > > I do not know what you mean by REALLY slow, but I find the latency of > the package browser perfectly acceptable. > > More than one second to open the brower. More than one second to go to another method, etc. Anyway, for me its the same as I can change it when I download an image. We can do a poll if you want, but I think someone (david, lukas or I don't know who) is working in a better browser with a faster package. I'm slowly making progress on the new package support I have some red tests that I should fix. After I will be able to start thinking about the integration within MC convention. And there will be a lot of bugs... so I will need help. > If people prefer the system browser, then fine with me. I just saw a > number of people systematically switching to the package browser. > > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 18, 2009

Re: [Pharo-project] Collecting pharo user company names

by StÃ©phane Ducasse

Hola German > After the event on BA I put an eye on Pharo with more detail than before. > > And let me comment that I found it very comfortable to develop software. > > Even when I continue deploying production solutions in small squeak > images, I started using Pharo to the redesign of my Real Estate > product. We hope to have small pharo images in the future. but one step at a time. > Don't know if this is enough to qualify as "company using Pharo" but > wanted to comment anyway. Sure it does :) Do you have a webpage? Pay attention 1.1 is in flux, faster but in flux and we want to keep it like that for a moment and start to do a code freeze. Having one release every six months. Stef

Dec. 18, 2009