- Pharo-dev - lists.pharo.org

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

by Chris Muller

I don't know what causees those either, but if you just want to dismiss the debugger window, try Proceed. On Sat, Jun 12, 2010 at 5:11 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> 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 >

June 14, 2010

[Pharo-project] SmaCC

by Ross Boylan

I'm using the Pharo 1.0 image and have loaded the configuration for SmaCC. It doesn't seem to come with any instruction or examples about how to use it, and I seem to have only the SmaCC-Runtime package group. I think I need SmaCCDev, but can't figure out how to load it. I opened up the monticello browser, but when I try to add a repository it asks me for an email address. I would appreciate help on any or all of figuring out how to use SmaCC, loading SmaCCDev (or any other packages) and info about package management in Pharo. Thanks. Ross Boylan

June 14, 2010

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

by laurent laffont

On Mon, Jun 14, 2010 at 9:32 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > > 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 :). > > Maybe putting a timeout will be cool. Something like 500 ms per test > method. > > Are you working on this? I will be glad to try it out and write tests for > this. > Repository is public write, don't hesitate to commit ! I will be happy to share experience with you on this. I've just commited a new version with more experimentations: - A new GUI. Open it with: AutotestDashboard open. To close: AutotestDashboard close. It's less intrusive and widget oriented (see AutotestAbstractWidget), so we can add more stuff without a big bloat class for GUI. - Only tests of the same package are run. Maybe a not so good idea, as I've seen tests and code are often not in the same package. What do you think ? Cheers, Laurent > > Cheers, > Alexandre > > > > > 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 > > > > _______________________________________________ > > 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 Adrian Lienhard

OK, Torsten has some good points (like, why not doing it right now rather than later?)! I took the proposal of Torsten from an earlier mail and tweaked it a bit. This shows the complete world menu including sub menus: System Browser Workspace Test Runner Monticello Browser -------------------- Tools ... (<-as today) Windows Collapse all windows Expand all windows Close top window Close all debuggers Send top window to back Move window onscreen Delete unchanged windows System About... Settings -------------- VM statistics Start profiling all processes Start profiling UI -------------- Start drawing again Start stepping again -------------- Restore display Enable halt inspect once Help Help Browser ProfStef Tutorial Welcome Workspace ---------------- Save Save as... Save and quit Quit Note, I inlined the debug menu into System. The reason is that I don't like multiply nested menus and the system menu does not get overly long. Also I deleted "Space left". Maybe other items like "Start stepping again" are also not really useful anymore? Furthermore I moved "Close all debuggers" into the Windows menu. I kept About... in system as I think it has not much to do with Help but more with System. I also changed the labels of some of the items (like Help Browser and ProfStef Tutorial). Does that look reasonable? Cheers, Adrian On Jun 14, 2010, at 20:45 , StÃ©phane Ducasse wrote: > torsten > > propose a menu redistribution as laurent did so that we arrive to something better. > I agree that debug could be in another place than in root. > > stef > _______________________________________________ > 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] [ANN] Bytes, a convenience to print the size of things

by Chris Muller

Just FYI, there's also a single-method version of this behavior which has been available in the "Ma base additions" package for some years now.. maAsBytesDescription | suffixes | suffixes := { 'k'"ilobytes". 'M'"egabytes". 'G'"igabytes". 'T'"erabytes". 'P'"etabytes". 'E'"xabytes". 'Z'"ettabytes". 'Y'"ottabytes"}. suffixes size to: 1 by: -1 do: [ : index | | units | units := 1000 raisedTo: index. self > units ifTrue: [ ^ ((self / units) asFloat roundTo: 0.01) asString, (suffixes at: index) ] ]. ^ self asString On Sat, Jun 12, 2010 at 10:03 AM, <sebastian(a)flowingconcept.com> wrote: > Hi there, > > I've published a package to help printing measures of bytes in a human readable fashion. > > Here is is: > http://www.squeaksource.com/Bytes > > Examples: > > Â Â Â Â 2 gigabytes asMegabyteString "will give you '2048 MB' if you print it" > > for those who have stored half of the galaxy its range goes from kilo to yatto > > enjoy > > sebastian > PS: it uses Aconcagua as foundation so be sure to install it first > > _______________________________________________ > 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

> 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 :). Maybe putting a timeout will be cool. Something like 500 ms per test method. Are you working on this? I will be glad to try it out and write tests for this. Cheers, Alexandre > > 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 > > _______________________________________________ > 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

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

by StÃ©phane Ducasse

torsten propose a menu redistribution as laurent did so that we arrive to something better. I agree that debug could be in another place than in root. stef

June 14, 2010

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

by StÃ©phane Ducasse

> > Again. Who cares PharoCore? we are talking about PharoDev. I do because if I click 20 times per hour on the wrong item in the menu then it means that it is not well placed. > > - 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? because the list was plain wrong! > 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 > > _______________________________________________ > 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 StÃ©phane Ducasse

+ 2^10000000000000 Stef On Jun 14, 2010, at 5:17 PM, Adrian Lienhard 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] ConfigurationOfCitezen

by StÃ©phane Ducasse

> 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 think that conifguration OfCitezen load lastest dev (as mention in the class comment) load seaside30 > > 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. indeed we could have a citezen base and a citezen for web Damien can reply to you when he reappear from his teaching duties :) not sure that this is not 8 h per day this week Setf

June 14, 2010