Pharo for Professional Development
Locked
123
123
Pharo for Professional Development
 
|
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 EinsteinLogic 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Marcus Denker-4
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 <[hidden email]> wrote:
-- 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Michael Rueger-6
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Marcus Denker-4
good idea. Just as a feedback. I tried to use Pharo to implement some algorithms in course I'm giving. This was instructive ... but I think I won't do it next year (except if I implement a pseudo-language a la etoy tile to do algorithmics). The major showstopper was Smalltalk syntax (except for good students). But, more importantly I think (and it bet this was far worst in squeak) is the lack of coherence, ergonomy, etc... I know this is something difficult. I don't espacially care for myself as I know all workarounds but these are really annoying for newcomer who at the end have a feelling of "this doesn't really work". I think ergonomy and coherence is something to discuss... Here are some remarks:
-I've always felt bored with the tool size that I always are resizing manually (I would prefer full screen by default actually) -some shortcuts works with alt and ctrl, some only with alt (disturbing for newcomer that are used to ctrl - I use alt)
-shortcuts are working primarly for qwerty keyboards (especially those that add remove []) -the selection of the code pane is sometime boring too... you have to click twice, or deselect/select -...
I know I should open bugs tickets for that and will do it (just tell me those). But more importantly, I think we should agree on these important usability feature. And especially, I'd like we rethink the browser. Alain did the whisker browser no ? What I want to say here is that it might be more appropriate for newcomers to have one big robust coding tool (classic browser + workspace + Transcript + Test Runner). I cannot do that by myself but it could be one topic to discuss in a meeting.
-- Cédrick ps: again, I think experienced smalltalkers will keep on using old classic tools but this represent too much distraction for newcomers.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
On Dec 18, 2009, at 10:34 , Bart Gauquie wrote: > Just now, I've been looking into > http://code.google.com/p/pharo/issues/detail?id=1570 I've reported > last > week. Thanks for reporting. Please always send a short mail to the list when you create an issue. See also http://www.pharo-project.org/community/issue-tracking Cheers, Adrian _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Marcus Denker-4
I think we should rename 1.1. It's not #alpha, it's #unstable. I think thats a bad idea. Pharo should also set a standard on stability. It's even in the mission statement: 'By providing a stable and small core system, excellent developer tools, and maintained releases'.
Stability means that the 'nightly build' just works: all existing things work as expected, new things in development already partly work. Would it not be arrogantly nice to be so confident in the system, that you can just take the latest release and no errors occur ?
Just a thought, Kind Regards, Bart _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Adrian Lienhard
Thanks for pointing out, did not know that. Kind Regards, Bart On Fri, Dec 18, 2009 at 11:30 AM, Adrian Lienhard <[hidden email]> wrote:
-- 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
On Dec 18, 2009, at 11:36 AM, Bart Gauquie wrote: > > > I think we should rename 1.1. It's not #alpha, it's #unstable. > > Marcus > _______________________________________________ > > > I think thats a bad idea. Pharo should also set a standard on stability. It's even in the mission statement: 'By providing a stable and small core system, excellent developer tools, and maintained releases'. You now, it says: releases. 1.1 is not released. > Stability means that the 'nightly build' just works: all existing things work as expected, new things in development already partly work. > Sorry, this is impossible. How can a nightly build be stable? It's not used, thus not tested. How can it be tested if it is not made avaible? Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
On Dec 18, 2009, at 11:21 AM, Bart Gauquie wrote: > Hi, > > The point I'm trying to make is that even on an alpha release, There is no release yet! > 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 old stuff is *very very bad*. It needs to be fixed. This is when stuff breaks. > > > |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? > I can not work on a system where every change on the unstable branch is garanteed to not break anything. That is because I don't know how this is possible to do. Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by cedreek
Yep, IDE tools in Pharo are at least a few years behind what you can find in other IDEs, at least in terms of usability. This is a known problem :) and there already has been a stream of propositions, enhancements, and talks about this (I myself did a presentation at ESUG 2009 about what I wanted). The issue was also discussed at the last Pharo sprint, and the major problem is simply lack of resources: nobody has the time nor the money to invest at least 2 or 3 months full work, in order to do a major clean up/rewrite of the graphical framework for dev tools (which would be a good first step). Now there is Morphic which is low-level, OB which is complicated, Glamour which needs enhancements... However, the primary annoyance right now is the dichotomy between the OB new framework and the O2 derived for David's work. The problem is that now, whenever the tools changed in OB (especially refactoring support), O2 can not follow and it breaks the tools in the package browser. 1) Remove O2SystemBrowser from the menu. Does anybody uses this browser? It's the same as OBSystemBrowser, so I guess people either use OBSystemBrowser or O2PackageBrowser. 2) How can we backport changes from O2 into OB? About the taskbar: I'm more and more convinced that the taskbar does not work well for me, in particular does not scale. I would prefer something like the Mac Os dock. On the other hand, Algernon is a great tool to navigate quickly to a class (unfortunately, it does not support yet the queries as in a Mercury panel). On 18 déc. 2009, at 11:21, Cédrick Béler wrote:
-- Simon _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
On Dec 18, 2009, at 12:03 09PM, Simon Denier wrote:
Have you tried the new taskbar in Windows 7 (with Aero on)? It's even better than the Dock, imo. This is just another reason why multiple native windows would be nice, though, leaves the problem for someone else :) Cheers, Henry _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
Henrik Johansen wrote:
> This is just another reason why multiple native windows would be nice, > though, leaves the problem for someone else :) Interestingly enough a lot of the (complex) multiple native window applications have (gone back to) all in one window UIs (Eclipse, all of the Adobe products, ...). Michael _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Marcus Denker-4
Hi Marcus, There is no release yet! How often are you planning to do a release? I suppose the next release is the reached milestones for 1.1?
Absolutely.
Allow me to explain why I have such strong beliefs about this. On my firm, we are using some techniques to enable that. On one project they are releasing new functionality every two weeks. How they do that is as following. These 2 weeks releases are incremental changes to a already running production system. They take a limited set of functionality that can be developed in say just over a week. Nightly builds are deployed on test servers. After a day or three development, parts of the developed functionality can already be tested by the proxy. After six or seven days of development, the core dev is done, and they focus on fixing the errors. After a day or two more the whole stuff is developed, tested en ready for production. The main reason why this works pretty well, is that they take small steps. They set a target to develop a limited set of functionality, and commit to it as a team. Furthermore they use extensive testing. They write unit tests for every line of code written and also write integration tests. The product developed is a web application. They use a rich domain and a sql db. They write extensive unit tests for the functionality of the domain; write one integration test if the domain object can be persisted correctly, and write also a limited set of gui tests using selenium, to verify if the gui is working correctly. The amount of unit tests is very high, the amount of integration tests / gui tests much lower. The unit tests serve to test the core behaviour, the other tests more or less if 'everything is wired correctly'. Working like this, they have a high confidence in the code; they get immediate feedback if something broke: so they can fix these errors quickly.
The small steps combined with the extensive testing is what enables us to create these short releases. If they would try to integrate a lot of changes at once, it would take them a lot longer to make that stable. We call every build, in which all tests run, 'a potential shippable product'.
I think that in Pharo most of the tests are unit tests. Please correct if I'm wrong, don't know it well enough yet. Each package is perfectly unit tested. However the dev image which tries to integrate different packages is, I think, lacking integration tests to see if they properly work together. Take the example I gave. Refactoring tools work very well, are nicely unit tested; however combined with the Package browser it did not work. The net result of it is that it does not work.
Now I off course understand that, since Pharo is opensource and community driven, it will be a lot harder to achieve a short release period than doing this on my firm, full time developing on the product.
These are just my views I use in my day 2 day work. 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
On Dec 18, 2009, at 1:05 PM, Bart Gauquie wrote: > Hi Marcus, > > There is no release yet! > > How often are you planning to do a release? I suppose the next release is the reached milestones for 1.1? > Yes, this will be ready in a couple of months. > > > I think that in Pharo most of the tests are unit tests. Please correct if I'm wrong, don't know it well enough yet. Each package is perfectly unit tested. No, no package is perfectly unit-tested. Not even close. For some things there a no tests at all. Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
In reply to this post by Bart Gauquie
On 18 déc. 2009, at 11:36, Bart Gauquie wrote:
We dont have the resources for that right now. It requires much more tests (especially for a dynamic system), build and test server, also rule and quality checks, and even with that you cant declare it as stable. Eclipse nightly builds are tested automatically, but are never declared as stable. See http://download.eclipse.org/eclipse/downloads/build_types.html (yeah, I have a tendency to look up at eclipse whenever it comes to good process) One thing we could do now is better 'monkey testing' of dev versions. Whenever Damien makes a new release, some people could check that the tools work with this release by testing basic, common features. Then they report what works and does not work for the given release. At least people would be aware of the shortcomings. The dev build really misses a process like the core build has with integrators. But we can not mimic this process in dev since it integrates external packages, whose developers are sometimes not concerned with Pharo. I volunteer for that.
-- Simon _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Pharo for Professional Development
|
|
That is true. However, since Pharo chooses external packages and offers them as a dev package, it is the task/responsability of Pharo initiative to make sure they work together.
I'm extremely lazy but a huge fan of automation. Instead of clicking in Pharo manually and checking if the basic stuff is still working; why don't write a testcase which does that for you. Make a little more effort once and then just be lazy and exploit that effort afterwards. Since Pharo is dynamic, everything is an object, it is possible to test anything.
We can create a sort of Pharo-Dev-Integration-Tests package containing a limited set of Integration tests. I will try to create a testcase for the bug I mentioned.
Concerning the parts that are lacking tests. We have a rule to test everything. If you want to adapt something and you find that there is no test, you write a test first for the existing functionality; make sure it runs, add extra test for new functionality, ... . You certainly write a test if a bug occurred in something.
So you don't need to do an effort to try to test everything. If something is working untested, and you don't need to change it: why spent effort in writing tests for it? Only if you change it, you add tests for it.
Kind Regards, Bart _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |