[Pharo-project] 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 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 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
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
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
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
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
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: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
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
Bart Gauquie wrote:
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
You mean for a two week release cycle you only plan for one week of development? Are your managers *sane*? ;-) I think most of us can't imagine working in an environment like that, being used to one week release cycles with two weeks of work scheduled ;-) Of course with kind of development cycle I can perfectly understand why you expect the 1.1 branch to always be working. Realistically though the OpenSource cycle is more one developer working, community testing. Which is not to say that we try to get better :-) Michael
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
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.
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
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. This is just another reason why multiple native windows would be nice, though, leaves the problem for someone else :) Cheers, Henry
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
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? And native basic dialogs may be helpful too, to not reinvent the wheel (aka FileBrowser :). I vote for the WhiskerBrowser with all the cool OB stuff integrated! ;) Cheers, George
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
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.
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?
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
2009/12/18 Levente Uzonyi <leves@elte.hu>:
Sure, start the vm with: -vm display=none. Then use RFB to connect to the image, we use several such images.
Yes. You're right. I completely forgot about the possibility to use RFB. Yeah, in this case all the native dialogs won't fit at all. And multiple windows in the meaning I described previously add complexity in this case. But. IIUC Newspeak's GUI framework has the possibility to handle such issues. In case native GUI is inaccessible, it can render itself in Morphic and thus provide the possibility to use RFB. And native dialogs may be handled this way. So, nothing impossible :).
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
On Fri, Dec 18, 2009 at 1:39 PM, George Herolyants <george.herolyants@gmail.com> 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?
And native basic dialogs may be helpful too, to not reinvent the wheel (aka FileBrowser :).
I vote for the WhiskerBrowser with all the cool OB stuff integrated! ;)
Cheers, George
Hi, you may be interested in SeasideXUL project (http://code.google.com/p/seasidexul/). The rendering of UI with native look&feel is a responsibility of the standard Mozilla XULRunner and there may be several clients connected to one image. However the OmniBrowser binding and code editor is not in the production ready state now. Cheers, -- Pavel
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
Dolphin is better than that<g>, and yes, it is a shame that it is tied to Windows. In fairness, I would have made the same initial decision as they did, but I would have started investigating wx or some other toolkit as early as XP's release, and would have gotten serious about it shortly thereafter. The feature you are describing is what they call an idea space, and it is probably my least favorite features of Dolphin. That said, the single main window of Pharo is both a blessing and a curse. It is nice if I have reason to run two images at once; it is less than optimal most other times. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Taylor Sent: Sunday, January 10, 2010 6:19 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo for Professional Development 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Steve, I'm confused: how is a D4 guy an idea space fan??? Speaking of old images, I have 5.1 in gainful use. Moving to 6 was problematic, so aside from buying it (for the reason you mention), I never made the switch. I _think_ the problems I had have since been identified and understood, but there's that MS tentacle to consider. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Taylor Sent: Sunday, January 10, 2010 8:40 PM To: Pharo-project@lists.gforge.inria.fr 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
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
In short, the same story as me, but I have a better excuse :) It would be unwise for me to move to 6 only to promptly dump Windows. There are sabres rattling in the distance, and I'm not sure what will happen first. There are scenarios under which I might move to D6, but most of that could be avoided by a hybrid Pharo/Dolphin system, which is more in keeping with my plans to kick MS to the curb. Part of me wishes I could just take the mac plunge, but Linux is a better fit for embedded devices that are of interest. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stephen Taylor Sent: Sunday, January 10, 2010 9:44 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo for Professional Development 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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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/
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<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
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
But gwenael did a complete GTK binding for Squeak/pharo and he moved everything to GNU. Too bad. So we/you could gain from that. Stef On Jan 11, 2010, at 8:18 AM, Stéphane Ducasse wrote:
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<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
_______________________________________________ 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
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'. 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
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
On 18 déc. 2009, at 11:36, 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'. 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 ?
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.
Just a thought,
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
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
On Dec 18, 2009, at 1:23 PM, Bart Gauquie wrote:
Concerning the parts that are lacking tests. We have a rule to test everything.
We have the rule to do something, even if what we do it is not perfect. 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
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 Dec 18, 2009, at 2:39 PM, Bart Gauquie wrote:
Do you have negative experiences with writing tests?
No.
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.
Yes. I *love* tests... but if you say "I only integrate the System-Setting change if you provide tests for everything it touches", you will for sure never integrate anything. Marcus
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
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
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
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (15)
-
Adrian Lienhard -
Bart Gauquie -
Benoit St-Jean -
csrabak＠bol.com.br -
Cédrick Béler -
George Herolyants -
Henrik Johansen -
Levente Uzonyi -
Marcus Denker -
Michael Rueger -
Pavel Krivanek -
Schwab,Wilhelm K -
Simon Denier -
Stephen Taylor -
Stéphane Ducasse