- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo for Professional Development

by Bart Gauquie

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

Dec. 18, 2009

Re: [Pharo-project] Rome port

by Tudor Girba

Hi, I am a bit confused :). This link seems to not work: >>>> https://gforge.inria.fr/frs/download.php/25047/ >>>> RomePlugin.bundle.zip >> What exactly should I do if I wanted to get Rome in 1.0 using a 4.2.2 VM? Cheers, Doru On 17 Dec 2009, at 20:33, StÃ©phane Ducasse wrote: > Thanks john > > I deleted the plugging file. > > Stef > > On Dec 17, 2009, at 6:46 PM, John M McIntosh wrote: > >> Ya, for years now I've shipped the latest Rome plugin, which BTW I >> did compile, >> within the Squeak macintosh carbon VM. >> >> It's version 1.2.1 >> >> Likely the one https://gforge.inria.fr/frs/download.php/25047/RomePlugin.bundle.zip >> should disappear to avoid confusion. Just use a 4.2.2 VM >> >> I'll add building a RomePlugin for Squeak V5.0 to my list of >> things to do for Christmas. >> >> On 2009-12-17, at 9:38 AM, Alexandre Bergel wrote: >> >>> Michael, this is an excellent start! >>> Thanks for this. This is important. >>> >>>> You will need the RomePlugin for your platform. >>>> https://gforge.inria.fr/frs/download.php/25047/ >>>> RomePlugin.bundle.zip >>>> https://gforge.inria.fr/frs/download.php/25046/rome.zip >>> >>> There is a plugin next to the MacOSX VM. I do not know whether >>> this is >>> the same version of the plugin >> >> -- >> = >> = >> = >> = >> = >> = >> ===================================================================== >> John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Don't give to get. Just give."

Dec. 18, 2009

Re: [Pharo-project] Default code browser

by George Herolyants

2009/12/18 Lukas Renggli <renggli(a)gmail.com>: > How are tabs different to the taskbar with all windows maximized? I think it's a common practice to have more than one browser opened with different methods in each. I usually have three or more. One for a test. One or more for the method being tested. And one or more for the system navigation. I also usually have workspaces, debugger and so one. So I think it is helpful to be in the context of one tool (Browser) when jumping from one method to another and leave the taskbar to hold other tools. Though I think WhiskerBrowser still covers the above use case better. Unfortunately it doesn't run on Pharo. Cheers, George

Dec. 18, 2009

[Pharo-project] Pharo IDE usability (was Re: Pharo for Professional Development)

by CÃ©drick BÃ©ler

> > > 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. > yes and this is sad because in term of real possiblities, this is far better to me... > 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). > Yes It was interesting :) I agreed on most of them (especially the "in context search" which is essential to me) > 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... > Yes I know all that ! That why it probably better to discuss first. Maybe the proposition to pay someone (the count me in stuff) could be used for that. Because to me this is not just a problem but the BIG problem (at least so that newcommers don't leave with a bad feeling). Pay someone for 3 months is easier than for 12 :). And you could count me in for that (to give a contribution and also to participate) :) Every Dolphin users seems enligthened by their tools. Couldn't we mimic them ? Laurent just made propositions, you too in your ESUG presentation. We should collect, organize and provide a clear view of what we expect. Then maybe pay someone or simply create a project but with clear goals. Then make this tool rock solid (even in alpha or unstable ;) ) > > 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? > I use OB. I gave up on the package browser to have a snappier reaction. But, with all due respect, these are projects. The abstraction behind OB make some operations difficult. IMO, this could be easier to use classic rigid tool (as we ( I ) want only one big coding tool). But I actually don't care of what's behind as far as it works as defined in the future specs. > > 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). > Mercury seems quite broken to me. I've stopped looking at it and using it. Mercury and Algernon by the way need also some kind of uniformisation. Do we start some actions in the direction of that ? What other thinks ? CÃ©drick

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Michael Rueger

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

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Henrik Johansen

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

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Simon Denier

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(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Simon

Dec. 18, 2009

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

by GermÃ¡n Arduino

Hola StÃ©phane: 2009/12/18 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hola German > >> After the event on BA I put an eye on Pharo with more detail than before. >> >> And let me comment that I found it very comfortable to develop software. >> >> Even when I continue deploying production solutions in small squeak >> images, I started using Pharo to the redesign of my Real Estate >> product. > > > We hope to have small pharo images in the future. but one step at a time. > Cool. Until now I've my own procedure (home developed :)) to shrinking, but I also started using MinimalMorphic from Edgar who continued a work of Pavel. Not closures yet, but small and good to web services, mainly on shared servers. >> Don't know if this is enough to qualify as "company using Pharo" but >> wanted to comment anyway. > > Sure it does :) > Do you have a webpage? > Sure: www.arduinosoftware.com / www.arsol.biz / www.arsol.net (I'm also developing an internal use system to administer the webhostig and so, but well, I go slow, as time permit...) > Pay attention 1.1 is in flux, faster but in flux and we want to keep it > like that for a moment and start to do a code freeze. Having one release every six months. > To the work I commented (the redesign of my real estate app) I'm using the alphaweb image, and I use to apply all the updates on a daily basis, as a way of maintain myself informed of changes and progress. No real problems until now. BTW: The new System Settings Browser look really nice! > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers. GermÃ¡n.

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Marcus Denker

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

Dec. 18, 2009

Re: [Pharo-project] Pharo for Professional Development

by Marcus Denker

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

Dec. 18, 2009