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@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@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

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

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?

...

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.

Absolutely.

...

|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

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

On Dec 18, 2009, at 1:10 PM, Marcus Denker wrote:

...

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.

This is even phrased too positively: For *almost everthing*, there are no tests. In addition, the code base is *a mess of epic proportion*. Normal rules do not apply. Marcus

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

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:

I think we should rename 1.1. It's not #alpha, it's #unstable.

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.

My 2 cents,

-- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

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

On Fri, 18 Dec 2009, George Herolyants wrote:

2009/12/18 Michael Rueger <m.rueger@acm.org>:

...

Henrik Johansen wrote:

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, ...).

Yeah! That's true. And their look&feel may differ from the underlying os. And everyone uses them without complaining. So what's wrong with pharo? Maybe one of the weak points is that it simulates windowing system inside another one, when other applications (Eclipse, Netbeans...) have strongly defined layout (though customizable)? I think it's a real issue. Pharo Development Environment is *Integrated* but the UI still lacks this integration in some places, IMHO.

But I think multiple windows in the meaning of what for example firefox has will be helpful as well. I mean two or more usual pharo windows "connected" to the same image. Is that possible?

HostWindowPlugin is available: http://wiki.squeak.org/squeak/3862

And native basic dialogs may be helpful too, to not reinvent the wheel (aka FileBrowser :).

At first sight this idea seems to be cool, but it's not. FileBrowser is not a "reinvented wheel", it's really useful in a closed environments like smalltalk. FileBrowser has the same features on all platforms while native dialogs don't. Some platforms don't even have a graphical UI, would you open a terminal in the image on those? Levente

I vote for the WhiskerBrowser with all the cool OB stuff integrated! ;)

Cheers, George

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Fri, 18 Dec 2009, George Herolyants wrote:

2009/12/18 Levente Uzonyi <leves@elte.hu>:

...

On Fri, 18 Dec 2009, George Herolyants wrote:

...

And native basic dialogs may be helpful too, to not reinvent the wheel (aka FileBrowser :).

At first sight this idea seems to be cool, but it's not. FileBrowser is not a "reinvented wheel", it's really useful in a closed environments like smalltalk. FileBrowser has the same features on all platforms while native dialogs don't.

I may be wrong, but I think the basic features are the same. And the purpose of dialogs to ask user and return its answer to the system. And this feature is shared by all the dialogs. If we're talking about selecting files, such kind of dialogs at least in windows and linux have almost the same feature set and are more usual for people.

In that sense, yes the dialogs have similar features, but FileBrowser is more than a dialog.

...

Some platforms don't even have a graphical UI, would you open a terminal in the image on those?

I may not understand something, but is it possible to use Pharo's GUI on such platforms?

Sure, start the vm with: -vm display=none. Then use RFB to connect to the image, we use several such images. Levente

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

You guys didn't ask what I think about this either :) Native windows are not the panacea that many believe them to be. My most intense GUI in Dolphin uses a fair amount of emulation to obtain adequate performance. However, the problem (AFAIK) arises only when creating large numbers of widgets, e.g. the cells of a spreadsheet. I think our goal should be to offer a good emulated widget framework AND to use native windows for the various tool shells. A useful transition would be to use native shells with the current Polymorph widgets inside of each shell. The concept of "the" desktop (world menu) will disappear, and the current approach to startup/shutdown will be revealed to be as broken as it is. Toolshells will need menus and/or toolbars (hopefully with tasteful and compact, fixed-size buttons). Once those things are sorted, we could begin to convert the various tools to native widgets, if we even care to do so. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Levente Uzonyi Sent: Friday, December 18, 2009 7:52 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo for Professional Development On Fri, 18 Dec 2009, George Herolyants wrote:

2009/12/18 Michael Rueger <m.rueger@acm.org>:

...

Henrik Johansen wrote:

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, ...).

Yeah! That's true. And their look&feel may differ from the underlying os. And everyone uses them without complaining. So what's wrong with pharo? Maybe one of the weak points is that it simulates windowing system inside another one, when other applications (Eclipse, Netbeans...) have strongly defined layout (though customizable)? I think it's a real issue. Pharo Development Environment is *Integrated* but the UI still lacks this integration in some places, IMHO.

But I think multiple windows in the meaning of what for example firefox has will be helpful as well. I mean two or more usual pharo windows "connected" to the same image. Is that possible?

HostWindowPlugin is available: http://wiki.squeak.org/squeak/3862

And native basic dialogs may be helpful too, to not reinvent the wheel (aka FileBrowser :).

At first sight this idea seems to be cool, but it's not. FileBrowser is not a "reinvented wheel", it's really useful in a closed environments like smalltalk. FileBrowser has the same features on all platforms while native dialogs don't. Some platforms don't even have a graphical UI, would you open a terminal in the image on those? Levente

I vote for the WhiskerBrowser with all the cool OB stuff integrated! ;)

Cheers, George

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael Rueger wrote:

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, ...).

That was one of the last major developments on Dolphin Smalltalk before development was scaled back - a very nice tabbed window container for all of your workspaces, browsers, etc. I think the only thing it didn't hold was the Transcript, unfortunately. Dolphin's a fine piece of work - such a pity it's Windows only.

Michael

Steve

Schwab,Wilhelm K wrote:

Dolphin is better than that<g>

I've put my money where my mouth is with Dolphin - I think I've bought every product they've ever released, just to give them a hand - despite the fact that I've still got a Dolphin version4 image on the go!

The feature you are describing is what they call an idea space, and it is probably my least favorite features of Dolphin.

And one of my favourites! If only everyone agreed with me all the time...

Bill

Steve

Schwab,Wilhelm K wrote:

Steve,

I'm confused: how is a D4 guy an idea space fan???

The key word is laziness - not the good sort of laziness that programmers are supposed to have, along with hubris, etc, but the bad sort you're supposed to shake yourself out of. I've bought the various new Dolphin products, admired their niftyness, then gone back to my working image, thinking "must move this over when I've got a minute..." It's a terrible confession, but there you have it :)

Bill

Steve

Well, the IdeaSpace rocks! :) See, you're not alone! ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Blog: lamneth.wordpress.com A standpoint is an intellectual horizon of radius zero. (Albert Einstein) ________________________________ From: Stephen Taylor <stephen.taylor@bom.gov.au> To: Pharo-project@lists.gforge.inria.fr Sent: Sun, January 10, 2010 8:40:15 PM Subject: Re: [Pharo-project] Pharo for Professional Development Schwab,Wilhelm K wrote:

Dolphin is better than that<g>

I've put my money where my mouth is with Dolphin - I think I've bought every product they've ever released, just to give them a hand - despite the fact that I've still got a Dolphin version4 image on the go!

The feature you are describing is what they call an idea space, and it is probably my least favorite features of Dolphin.

And one of my favourites! If only everyone agreed with me all the time...

Bill

Steve _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project __________________________________________________________________ Make your browsing faster, safer, and easier with the new Internet Explorer® 8. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/

Given we're at the start of the year, I can still have wishes as well, then let's add Gayvert's wxWidgets as well http://www.wxsqueak.org/ []s -- Cesar Rabak Em 11/01/2010 05:18, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: Now for pharo people could ressurect the GTK port done by gwenael. Or pay for that. Stef On Jan 11, 2010, at 2:40 AM, Stephen Taylor wrote:

Schwab,Wilhelm K wrote:

...

Dolphin is better than that

I've put my money where my mouth is with Dolphin - I think I've bought every product they've ever released, just to give them a hand - despite the fact that I've still got a Dolphin version4 image on the go!

...

The feature you are describing is what they call an idea space, and it is probably my least favorite features of Dolphin.

And one of my favourites! If only everyone agreed with me all the time...

...

Bill

Steve

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 18 déc. 2009, at 12:29, Henrik Johansen wrote:

On Dec 18, 2009, at 12:03 09PM, Simon Denier wrote:

...

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).

Simon

Have you tried the new taskbar in Windows 7 (with Aero on)? It's even better than the Dock, imo.

Depends which Dock you are talking about :) I especially like the new with Dock/Exposé in Snow Leopard. OK, I have watched a small vid about the W7 taskbar, and it's also near what I have in mind for a new taskbar in Pharo! Actually, the different between snow leopard/dock and W7/taskbar is becoming rather short.

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

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

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.

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

Marcus, We have the rule to do something, even if what we do it is not perfect.

I never suggested this. Only trying to improve the way we are working, so that we can work more efficiently.

The idea to request a test for everything does not work. And in addition, even tests do no guarantee that a change will have no impact.

Marcus

Do you have negative experiences with writing tests? I've been using it all my professional career; and I firmly believe it is the only way to develop software, a good test set really helps to move forward at a sustainable pace. Close attention should off course be payed to the quality of the tests also. You are right on the point that extensive testing does not give you a mathematical certainty that everything works, but having a good test set catches most of the bugs, certainly if you're adapting/refactoring an existing system: which is the goal of Pharo: evolve/refactor Squeak. Kind Regards, Bart

On 18 déc. 2009, at 13:23, Bart Gauquie wrote:

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.

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.

One problem is that some features can only be tested through UI. Because the feature below can not be piloted outside of the UI and I dont know any framework performing automatic UI tests in Pharo. Maybe there is. Anyway, the first thing to do is to automate the launch of tests in a newly built dev image. Some people started to do that but I dont know more.

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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Simon

Thanks for pointing out, did not know that. Kind Regards, Bart On Fri, Dec 18, 2009 at 11:30 AM, Adrian Lienhard <adi@netstyle.ch> wrote:

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 Pharo-project@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