June 2010 - Pharo-dev - lists.pharo.org

[Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Torsten Bergmann

Hi Adrian, > still I think arguments like this do not help in finding the best >solution, The "egg thing" was not meant as argument, I apologize if this moved the whole discussion off-topic. My arguments were listed here [1] so can we please continue to discuss on these. >The rationale for moving the help menu was basically what I said before >- it was a single lonely item inside a submenu (we didn't know that Pharo >adds more submenus so this point only holds for PharoCore) OK, we now know: - it is a single item in Pharo core - it is a multiple icon in Pharo-dev ("Pharo") since more items are added - an "end user" typically uses Pharo-dev > My current point of view is that since we don't have a helpful help system > (yet) In Pharo Core we currently offer: - the help on help itself (which should be enough for core since we typically ship additional stuff in Pharo/Pharo-dev) There is more in "Pharo": - Welcome Workspace - ProfStef - HelpBrowser - with a loaded book for Pharo including a full browsable API as Stef wanted. - a help book for ScriptManager - the help on help And yes it needs more work but this is independent from the discussion to find a (root) place and make Help accessible >it is not really important that the help menu is at the top level. This is something I dont buy for three reasons (sorry for repeating my thoughts): - Getting "Help" is in almost any application I know of easily accessible at the root level and not hidden in another menu. Look at Firefox, Linux, Opera, ... at least on Win/Linux. - if you write a commercial app using Pharo as RCP then you want to provide Help (menu) but you may have no/wish no "System" menu - If you argue about having it at the top level only under the condition that the content gets better then why wait until the content gets better and confuse people at that point in time? Can't we just put it where we want it and work on better content? - I think we can agree that we dont want to have "System -> Help" in Core and root "Help" menu in Pharo to have them in sync - Ask a newbie to find help (I tried with a non-Smalltalk friend today and he also didnt expect it under "System"). He also said it would be better to just have "Help". Therefore I would vote to better move "Debug" away from the root level. >On another note, I don't agree with you that we should not move menus >around. If I hadn't carefully reorganized the menus of Pharo two years >ago, our menus would still be the same mess as in a previous Squeak >version. Of course stability is good, but it should not hinder us to clean >up and optimize. Moving a menu item to a better place may be annoying at >first but is quickly amortized. Again: I'm not agains menu moving to clean things up (especially the bloated Squeak menus) But currently we discuss about a good place for the help menu and you suggested to keep it under System and (if better content is available) move it. But this has nothing to do with cleanup. At which point in time will you move it? How do you measure the quality of the content? Let us think about the best place today, nail it down and improve content constantly. Nothing more. Bye T. - the help browser does not provide (much) content yet and hence is of no big help at the moment [1] http://lists.gforge.inria.fr/pipermail/pharo-project/2010-June/028287.html -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl

June 14, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Schwab,Wilhelm K

Adrian, I for one appreciate the changes to the menus. The improved icons are very helpful too, especially for finding the file list. I don't think you will regret restoring the help menu. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Monday, June 14, 2010 10:18 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1 Torsten, I understand your comment wasn't against Pharo in general but still I think arguments like this do not help in finding the best solution, which is what we should strive for. The rationale for moving the help menu was basically what I said before - it was a single lonely item inside a submenu (we didn't know that Pharo adds more submenus so this point only holds for PharoCore) - the help browser does not provide (much) content yet and hence is of no big help at the moment My current point of view is that since we don't have a helpful help system (yet) it is not really important that the help menu is at the top level. But since a couple of people strongly argue for putting the help back into the main menu I'm also ok with reverting the change. On another note, I don't agree with you that we should not move menus around. If I hadn't carefully reorganized the menus of Pharo two years ago, our menus would still be the same mess as in a previous Squeak version. Of course stability is good, but it should not hinder us to clean up and optimize. Moving a menu item to a better place may be annoying at first but is quickly amortized. Cheers, Adrian On Jun 14, 2010, at 16:43 , Torsten Bergmann wrote: > Hi Stef, > >> do you think that all the good energy that we put on pharo can be summarized >that way? > > No, why do you think so? Please dont get off-topic. We talk about a > menu here - nobody lamented about Pharo in general. > Please reread what I wrote: > > "Moving menues around is throwing eggs onto you end users" > > I think it was clear from my mail that moving KNOWN menues around from > time to time is IMHO a bad idea. Maybe you disagree, but I'm still > keep this opinion. > > So I dislike the idea of leaving it for now and MOVE the Help menu > LATER (as Adrian suggested) since this is what confuses people, > especially since user help is something really important. > > We can discuss it now, keep it or fix it. So we can avoid that moving > menues from time to time will lead to irritation. > >> We waited a bit until we got more convinced that we should move it > > Second time you write "we". For me it is still not clear who discussed > it (you and Adrian?) and where and which arguments lead to the > decision. Please tell us so we can also understand your point of view. > > Thx > T. > > > -- > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > Bis zu 150 EUR Startguthaben inklusive! > http://portal.gmx.net/de/go/dsl > > _______________________________________________ > 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

June 14, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by laurent laffont

On Mon, Jun 14, 2010 at 4:52 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Hi Laurent, > > I tried to program while having AutoTest running. > More importantly than the interface, I experienced some problem with long > executing tests. Basically, these tests should not be executed while I am > programming. Or at least in a thread of a lesser priority. Am I the only one > to experience this? > I've seen this, I like the idea of the background thread. We also should be able to tag long tests or exclude tests from Autotest. I'm currently experimenting with GUI (on my free time so I can't go very fast :). I think you are the only user :D Cheers. Laurent > > Cheers, > Alexandre > > > On 11 Jun 2010, at 09:02, laurent laffont wrote: > > > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > Hi Laurent, > > > > I like Autotest. It is true that I always execute the test after > modifying it. > > There are three horizontal panes. Why so? Is it just to open a debugger > when necessary? > > > > I want to be able to open a debugger from autotest. I agree the GUI is > crap now. > > > > > > We could imagine one standalone button instead with a green color to say > the test I just edited is green, and yellow or red when it fails. In that > case, clicking on the button open a debugger. > > > > I just feel the window of autotest takes a lot of space in the screen, > without having a real benefit. > > > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to > make GUI now :) > > > > If you look at Autotest package, AutotestView is just the GUI, so we can > implement several GUI and see the best solution. I need to take the time to > do it, repository is read / write so feel free to commit :) > > > > What I want to have is a dashboard docked on one side of the screen which > acts like you're driving a car. It's always visible, you have to be able to > look quickly at it as when you check the speed of your car, adjust your > drive, .... > > > > Also another problem with the current version if that if a test fails, > change it and fails again, you don't see it has run (nothing moves in the > GUI). > > > > Finally, another problem is that you see that a test has failed, but you > don't know why (SUnit TestRunner has the same problem). I want to display > the exception message too. > > > > Thanks a lot for feedback. > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > > > Cheers, > > Alexandre > > > > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > > > Hi, > > > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no > tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > > > Load it: > > > Gofer new > > > squeaksource: 'Autotest'; > > > package: 'Autotest'; > > > load > > > > > > Open it: > > > AutotestView open > > > (there's en entry in WorldMenu > Tools) > > > > > > And change a tested method to see the results. > > > > > > There's a bug I need to find, maybe someone knows: > > > - Change Bag>>occurrencesOf: > > > - Autotest gives: > > > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 > unexpected passes > > > Failures: > > > CollectionRootTest>>#test0FixtureIterateTest > > > > > > Errors: > > > CollectionRootTest>>#testBasicCollect > > > CollectionRootTest>>#testDoWithout > > > > > > but in SUnit CollectionRootTest gives > > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 > unexpected passes ?? > > > > > > > > > Cheers, > > > > > > Laurent Laffont > > > > > > http://pharocasts.blogspot.com/ > > > http://magaloma.blogspot.com/ > > > > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > > The idea is excellent. > > > > > > Cheers, > > > Alexandre > > > > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > > > You may have a lot of noise. > > > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. > The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > > > I would suggest that TestCase which would use this feature use some > pragma/method to identify/declare which classes/packages this test depends > upon. Then the "autotest" framework would register such tests and listen for > changes in the given classes/packages, launching required tests whenever a > change happen. > > > > > > > > > > Additionally, one could declare such a pragma on a single test > method, when this test should be run for a specific class. > > > > > > > > > > Of course, you also to take care of long running tests, which you > probably want to exclude from auto-testing. > > > > > > > > I see autotest in Pharo in a slighly different way: When I press save > in the Monticello browser, I have a popup menu which asks me whether (i) I > want to run all the tests or (ii) only the tests that cover that I changed > from the last version. > > > > > > > > Does this make sense? > > > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly > look at test results if I want (or not) without stop writing. Often you want > to see your tests failing, as you type / save code. I don't have to stop > writing, click a button, wait test results, go again.... testing is done in > background and I just see notifications whether it's OK or not. > > > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > > > > For autotest unit of work is file: it runs the test file which has > the same name as the code file, but you can customize this behavior. For > autotest-rails: > > > > "A simplified version of Autotest heuristics in this mode would be: > > > > When changing a test file, only this file is run (e.g. > test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > > When changing a model file, only associated unit test file is run > (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > > When changing a controller file, associated functional test file is > run (e.g.app/controllers/foo_controller.rb > âtest/functional/foo_controller_test.rb). > > > > When changing a fixture file, associated unit test and functional > test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb > +test/functional/foo_controller_test.rb). > > > > When changing a helper file, associated functional test file is run > (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > > When changing application_helper.rb file all functional test files > are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > > When changing a file under the config directory, all tests are run." > > > > > > > > Laurent > > > > > > > > > > > > > > > > Cheers, > > > > Alexandre > > > > -- > > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > > Alexandre Bergel http://www.bergel.eu > > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > > > _______________________________________________ > > > > Pharo-project mailing list > > > > Pharo-project(a)lists.gforge.inria.fr > > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 14, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Mariano Martinez Peck

On Mon, Jun 14, 2010 at 5:17 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Torsten, I understand your comment wasn't against Pharo in general but > still I think arguments like this do not help in finding the best solution, > which is what we should strive for. > > The rationale for moving the help menu was basically what I said before > - it was a single lonely item inside a submenu (we didn't know that Pharo > adds more submenus so this point only holds for PharoCore) > Again. Who cares PharoCore? we are talking about PharoDev. > - the help browser does not provide (much) content yet and hence is of no > big help at the moment > > And maybe having a more accesisble menu will help to that. There is also the ProfBrower, Re open the welcome workspace, what it is now in system about, and why not put back the list of shortcuts? > My current point of view is that since we don't have a helpful help system > (yet) it is not really important that the help menu is at the top level. But > since a couple of people strongly argue for putting the help back into the > main menu I'm also ok with reverting the change. > On another note, I don't agree with you that we should not move menus > around. If I hadn't carefully reorganized the menus of Pharo two years ago, > our menus would still be the same mess as in a previous Squeak version. Of > course stability is good, but it should not hinder us to clean up and > optimize. Moving a menu item to a better place may be annoying at first but > is quickly amortized. > agree. > > Cheers, > Adrian > > On Jun 14, 2010, at 16:43 , Torsten Bergmann wrote: > > > Hi Stef, > > > >> do you think that all the good energy that we put on pharo can be > summarized >that way? > > > > No, why do you think so? Please dont get off-topic. We talk > > about a menu here - nobody lamented about Pharo in general. > > Please reread what I wrote: > > > > "Moving menues around is throwing eggs onto you end users" > > > > I think it was clear from my mail that moving KNOWN menues > > around from time to time is IMHO a bad idea. Maybe you disagree, > > but I'm still keep this opinion. > > > > So I dislike the idea of leaving it for now and MOVE the Help > > menu LATER (as Adrian suggested) since this is what confuses people, > > especially since user help is something really important. > > > > We can discuss it now, keep it or fix it. So we can avoid that > > moving menues from time to time will lead to irritation. > > > >> We waited a bit until we got more convinced that we should move it > > > > Second time you write "we". For me it is still not clear who > > discussed it (you and Adrian?) and where and which arguments lead > > to the decision. Please tell us so we can also understand your point of > view. > > > > Thx > > T. > > > > > > -- > > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > > Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > > > > _______________________________________________ > > 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 >

June 14, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Elliot Finley

+1 On Mon, Jun 14, 2010 at 9:17 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Torsten, I understand your comment wasn't against Pharo in general but > still I think arguments like this do not help in finding the best solution, > which is what we should strive for. > > The rationale for moving the help menu was basically what I said before > - it was a single lonely item inside a submenu (we didn't know that Pharo > adds more submenus so this point only holds for PharoCore) > - the help browser does not provide (much) content yet and hence is of no > big help at the moment > > My current point of view is that since we don't have a helpful help system > (yet) it is not really important that the help menu is at the top level. But > since a couple of people strongly argue for putting the help back into the > main menu I'm also ok with reverting the change. > > On another note, I don't agree with you that we should not move menus > around. If I hadn't carefully reorganized the menus of Pharo two years ago, > our menus would still be the same mess as in a previous Squeak version. Of > course stability is good, but it should not hinder us to clean up and > optimize. Moving a menu item to a better place may be annoying at first but > is quickly amortized. > > Cheers, > Adrian > > On Jun 14, 2010, at 16:43 , Torsten Bergmann wrote: > > > Hi Stef, > > > >> do you think that all the good energy that we put on pharo can be > summarized >that way? > > > > No, why do you think so? Please dont get off-topic. We talk > > about a menu here - nobody lamented about Pharo in general. > > Please reread what I wrote: > > > > "Moving menues around is throwing eggs onto you end users" > > > > I think it was clear from my mail that moving KNOWN menues > > around from time to time is IMHO a bad idea. Maybe you disagree, > > but I'm still keep this opinion. > > > > So I dislike the idea of leaving it for now and MOVE the Help > > menu LATER (as Adrian suggested) since this is what confuses people, > > especially since user help is something really important. > > > > We can discuss it now, keep it or fix it. So we can avoid that > > moving menues from time to time will lead to irritation. > > > >> We waited a bit until we got more convinced that we should move it > > > > Second time you write "we". For me it is still not clear who > > discussed it (you and Adrian?) and where and which arguments lead > > to the decision. Please tell us so we can also understand your point of > view. > > > > Thx > > T. > > > > > > -- > > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > > Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > > > > _______________________________________________ > > 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 >

June 14, 2010

Re: [Pharo-project] Help menu disappeared [WAS] [ANN] Pharo-1.1-11400-rc1dev10.06.1

by Adrian Lienhard

Torsten, I understand your comment wasn't against Pharo in general but still I think arguments like this do not help in finding the best solution, which is what we should strive for. The rationale for moving the help menu was basically what I said before - it was a single lonely item inside a submenu (we didn't know that Pharo adds more submenus so this point only holds for PharoCore) - the help browser does not provide (much) content yet and hence is of no big help at the moment My current point of view is that since we don't have a helpful help system (yet) it is not really important that the help menu is at the top level. But since a couple of people strongly argue for putting the help back into the main menu I'm also ok with reverting the change. On another note, I don't agree with you that we should not move menus around. If I hadn't carefully reorganized the menus of Pharo two years ago, our menus would still be the same mess as in a previous Squeak version. Of course stability is good, but it should not hinder us to clean up and optimize. Moving a menu item to a better place may be annoying at first but is quickly amortized. Cheers, Adrian On Jun 14, 2010, at 16:43 , Torsten Bergmann wrote: > Hi Stef, > >> do you think that all the good energy that we put on pharo can be summarized >that way? > > No, why do you think so? Please dont get off-topic. We talk > about a menu here - nobody lamented about Pharo in general. > Please reread what I wrote: > > "Moving menues around is throwing eggs onto you end users" > > I think it was clear from my mail that moving KNOWN menues > around from time to time is IMHO a bad idea. Maybe you disagree, > but I'm still keep this opinion. > > So I dislike the idea of leaving it for now and MOVE the Help > menu LATER (as Adrian suggested) since this is what confuses people, > especially since user help is something really important. > > We can discuss it now, keep it or fix it. So we can avoid that > moving menues from time to time will lead to irritation. > >> We waited a bit until we got more convinced that we should move it > > Second time you write "we". For me it is still not clear who > discussed it (you and Adrian?) and where and which arguments lead > to the decision. Please tell us so we can also understand your point of view. > > Thx > T. > > > -- > GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. > Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 14, 2010

Re: [Pharo-project] [SIXX] feedback

by Schwab,Wilhelm K

Thanks!! -----Original Message----- From: Masashi Umezawa [mailto:umejava@mars.dti.ne.jp] Sent: Monday, June 14, 2010 9:44 AM To: Schwab,Wilhelm K Cc: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [SIXX] feedback Hello Bill, Thanks for the feedback. I've fixed old underscore assignments. The latest development version is available at: http://squeaksource.blueplane.jp/SIXX.html Currently, I'm integrating XMLPullParser patches, so the source is not so well organized. But all assignments are now ANSI-style anyway. ;-) Best regards, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Masashi, > > I have been trying to do some testing of Pharo 1.1 through a Seaside 3.0 daily image. One of the first things I load is SIXX. Pharo has been addressing underscore assignment problems, and the default is now to treat them as syntax errors, and one was identified in SixxAutoMorphMemento class>>release. I have also noted them in the #instDict and #instDict: accessors. > > It would be helpful if you could change the underscores to := for future releases. I am not sure how to tell if there are other underscore assignments in the .sar. > > Thanks for SIXX! > > Bill --- [:masashi | ^umezawa]

June 14, 2010

[Pharo-project] ConfigurationOfCitezen

by Schwab,Wilhelm K

Hello all, Maybe I am simply getting confused by reading code from an "old" image, but I am trying to install Citezen. As I read the configuration, it was written in terms of Seaside 2.8, but it looks like 3.0 is being installed. Any ideas? I am open to thinking about Seaside 3, but my packages will fail to load due to the configuration changes. So far, all I have found is that I need to "change to the new system" but not much more than that. Perhaps the answer is to comment out the offending #initialize code, load everything, and then worry about how to get them registered. As slick as it is to be able to use Seaside to configure my Seaside apps, I do not want to trust myself on that front; I want them to be secured from the beginning, and temporarily re-configured for development as needed, and then programmatically switched back to secure-or-nothing. Semi-rhetorical question: should Citezen be loading Seaside? Could/should there be a Citezen-base or something that just reads BibTeX, and then other things that do all of the web-enabled work? All I do with it is parse entries, for which is very valuable. Bill

June 14, 2010

Re: [Pharo-project] Unwind errors: worse in 1.1?

by Schwab,Wilhelm K

Stef, Small frustration: don't integrate it. Rydier's fix breaks MC, which depends on the unfortunate semantics. I have an RC image trying to build now. In a while, I can try the fix I proposed (which changes the message loop and uses #waitForAccept* vs. #waitForConnect* when accepting), which should not break anything because it added methods rather than changing existing ones. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Sunday, June 13, 2010 2:11 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Unwind errors: worse in 1.1? We will apply it. Now I'm not sure that it was working in 1.0. Stef On Jun 13, 2010, at 8:53 PM, Schwab,Wilhelm K wrote: > Stef, > > For good or bad, it appears that I can't. I have held onto the offending image in case I get any insights into what might have happened to it, but so far, I don't see how to get to the broken state. > > I tried applying my build process to the core, and was stopped. I tried with the seaside 3 image and was stopped again, but noted that it had gotten far enough to try the proposed ConnectionQueue fix (2476). I added a comment to the tracker; but, rydier's suggestion of removing the ^true appears to fix it. It's hobbled now, so what do we have to lose? > > Bill > > > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr > [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane > Ducasse [stephane.ducasse(a)inria.fr] > Sent: Sunday, June 13, 2010 3:24 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Unwind errors: worse in 1.1? > > can you describe a scenario that we can reproduce? > > Stef > > On Jun 13, 2010, at 12:11 AM, Schwab,Wilhelm K wrote: > >> I have long intermittently seen errors with walkbacks titled "Unwind error during termination." They might be more common in 1.1, and worse, I am now unable to close the offending notifiers/debuggers. I also tried "close all debuggers" without success. >> >> Bill >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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

June 14, 2010

Re: [Pharo-project] Autotest, proof-of-concept [was: About TDD and Pharo]

by Alexandre Bergel

Hi Laurent, I tried to program while having AutoTest running. More importantly than the interface, I experienced some problem with long executing tests. Basically, these tests should not be executed while I am programming. Or at least in a thread of a lesser priority. Am I the only one to experience this? Cheers, Alexandre On 11 Jun 2010, at 09:02, laurent laffont wrote: > On Fri, Jun 11, 2010 at 2:29 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > Hi Laurent, > > I like Autotest. It is true that I always execute the test after modifying it. > There are three horizontal panes. Why so? Is it just to open a debugger when necessary? > > I want to be able to open a debugger from autotest. I agree the GUI is crap now. > > > We could imagine one standalone button instead with a green color to say the test I just edited is green, and yellow or red when it fails. In that case, clicking on the button open a debugger. > > I just feel the window of autotest takes a lot of space in the screen, without having a real benefit. > > Yes it's true. I'm still thinking on a good GUI. But I'm learning how to make GUI now :) > > If you look at Autotest package, AutotestView is just the GUI, so we can implement several GUI and see the best solution. I need to take the time to do it, repository is read / write so feel free to commit :) > > What I want to have is a dashboard docked on one side of the screen which acts like you're driving a car. It's always visible, you have to be able to look quickly at it as when you check the speed of your car, adjust your drive, .... > > Also another problem with the current version if that if a test fails, change it and fails again, you don't see it has run (nothing moves in the GUI). > > Finally, another problem is that you see that a test has failed, but you don't know why (SUnit TestRunner has the same problem). I want to display the exception message too. > > Thanks a lot for feedback. > > Laurent Laffont > > http://pharocasts.blogspot.com/ > http://magaloma.blogspot.com/ > > > > Cheers, > Alexandre > > > On 3 Jun 2010, at 17:11, laurent laffont wrote: > > > Hi, > > > > I've written a proof-of-concept for Autotest. Draft/crappy code and no tests (exploration mode :) but it loads on PharoCore-1.1-11383-beta image. > > > > Load it: > > Gofer new > > squeaksource: 'Autotest'; > > package: 'Autotest'; > > load > > > > Open it: > > AutotestView open > > (there's en entry in WorldMenu > Tools) > > > > And change a tested method to see the results. > > > > There's a bug I need to find, maybe someone knows: > > - Change Bag>>occurrencesOf: > > - Autotest gives: > > > > 284 run, 281 passes, 0 expected failures, 1 failures, 2 errors, 0 unexpected passes > > Failures: > > CollectionRootTest>>#test0FixtureIterateTest > > > > Errors: > > CollectionRootTest>>#testBasicCollect > > CollectionRootTest>>#testDoWithout > > > > but in SUnit CollectionRootTest gives > > 0 run, 0 passes, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes ?? > > > > > > Cheers, > > > > Laurent Laffont > > > > http://pharocasts.blogspot.com/ > > http://magaloma.blogspot.com/ > > > > > > On Thu, Jun 3, 2010 at 6:09 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > The idea is excellent. > > > > Cheers, > > Alexandre > > > > > > On 3 Jun 2010, at 10:22, laurent laffont wrote: > > > > > > > > > > > On Thu, Jun 3, 2010 at 3:42 PM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > > You may have a lot of noise. > > > > > > > > I guess that Ruby uses files as a unit of development/deployment. The closest Smalltalk/Pharo has is the class and the package. > > > > > > > > I would suggest that TestCase which would use this feature use some pragma/method to identify/declare which classes/packages this test depends upon. Then the "autotest" framework would register such tests and listen for changes in the given classes/packages, launching required tests whenever a change happen. > > > > > > > > Additionally, one could declare such a pragma on a single test method, when this test should be run for a specific class. > > > > > > > > Of course, you also to take care of long running tests, which you probably want to exclude from auto-testing. > > > > > > I see autotest in Pharo in a slighly different way: When I press save in the Monticello browser, I have a popup menu which asks me whether (i) I want to run all the tests or (ii) only the tests that cover that I changed from the last version. > > > > > > Does this make sense? > > > > > > Please no popup :) What I like in ruby autotest is that I can quickly look at test results if I want (or not) without stop writing. Often you want to see your tests failing, as you type / save code. I don't have to stop writing, click a button, wait test results, go again.... testing is done in background and I just see notifications whether it's OK or not. > > > > > > So test log in a Transcript is OK for me. > > > > > > > > > For autotest unit of work is file: it runs the test file which has the same name as the code file, but you can customize this behavior. For autotest-rails: > > > "A simplified version of Autotest heuristics in this mode would be: > > > When changing a test file, only this file is run (e.g. test/unit/foo_test.rb âtest/unit/foo_test.rb). > > > When changing a model file, only associated unit test file is run (e.g.app/models/foo.rb â test/unit/foo_test.rb). > > > When changing a controller file, associated functional test file is run (e.g.app/controllers/foo_controller.rb âtest/functional/foo_controller_test.rb). > > > When changing a fixture file, associated unit test and functional test are run (e.g.app/fixtures/foos.yml â test/unit/foo_test.rb +test/functional/foo_controller_test.rb). > > > When changing a helper file, associated functional test file is run (e.g.app/helpers/foo_helper.rb âtest/functional/foo_controller_test.rb). > > > When changing application_helper.rb file all functional test files are run (e.g.application_helper.rb â test/functional/*_test.rb). > > > When changing a file under the config directory, all tests are run." > > > > > > Laurent > > > > > > > > > > > > Cheers, > > > Alexandre > > > -- > > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > > Alexandre Bergel http://www.bergel.eu > > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > > Pharo-project mailing list > > > Pharo-project(a)lists.gforge.inria.fr > > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 14, 2010