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

Re: [Pharo-project] GUI Polymorph

by Schwab,Wilhelm K

Hilaire, It was interesting to watch MS' position on GUI examples change over time. Visual C++ started out teaching how to create efficient software. Then one day those examples were gone and all they could talk about was "smooth scrolling" which turned out to be a way to make the machine do the inefficient thing four times instead of once. The idea of altering the model, finding out what is invalidated, marking that as closely as can be done within bounds of common sense (or until diminishing returns), and then drawing just the changed parts is non-intuitive and VERY important. You have done a wonderful job so far, but optimization deserves attention. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Hilaire Fernandes Sent: Friday, June 11, 2010 7:04 AM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] GUI Polymorph Hi Fernando, Sure we can be more optimal in execution term, but it is not my objective. I want the example to be concise and optimal under this term, so smaller then may be easier to catch. Bill, Yes, you can draw segment. Yes you can optimze but it is not the purpose of the documentation. I try to optimize the documentation to its target: get started with GUI programming with Polymorph, and let the reader enjoy. Please consider proposing, additional advanced chapter in the CollaborActive book for some idea about optimization GUI. I will be really happy to read, to learn and to comment on that. Laurent, I removed the heading sections and replace it with Bold style. Thanks for your feedback. Hilaire Fernando olivero a Ã©crit : > Hi Laurent, great work! We need more documentation! > > Just a little coding style i would like to point out. > > I see you are using lazy initialization, but in this case i believe > its a miss-use of the pattern. > Because you always will have a toolbar and a menu bar, since the > creation you are sure you need them, why not go and just initialize > them before installing. > > Let me know what you think. > > > So i propose changing the implementation to : > > initialize > super initialize. > self initializeMenuBar. > self initializeToolbar. > .... > > and > > initializeMenuBar > | menu | > menu := self window newMenu. > menu > addToggle: 'Load' > target: self > selector: #load. > menu > addToggle: 'Save' > target: self > selector: #save. > menubar := self window newToolDockingBar. > menubar > add: 'File' > font: self window theme menuBarFont > icon: nil > help: 'File operations' > subMenu: menu. > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 11, 2010

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

by Alexandre Bergel

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? 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. 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 11, 2010

Re: [Pharo-project] Three current versions: 1.0, 1.1, 1.2

by Marcus Denker

On Jun 9, 2010, at 12:15 PM, Henrik Johansen wrote: > > On Jun 9, 2010, at 11:38 39AM, StÃ©phane Ducasse wrote: > >> >> >> adrian there are some fixed simple UTF and other pending fixes that we could integrate (was planning for after lunch) >> Stef >> >>>> Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now. >>>> >>>> Cheers, >>>> Adrian >>>> >>> >>> - ConnectionQueue. (2476) >>> - WeakKeyDictionaries. >>> Easiest would probably be to port the one in Squeak now (with related finalization classes), as Levente did some work on that compared to what was in Squeak 4.0 / Pharo 1.0 which made it faster without breaking it when not registered for finalization. >>> Alternatively wait for VM's to be built with Igor's finalization enhancements, require those for 1.1 WeakRegistries, and rewrite WeakKeyDictionaries to no longer assume they may be used/are always registered for finalization. (1628, 2309) >>> - Encoding for code importing/exporting (setConverterForCode methods 1608 , 1872) >>> >> >> are some fixed? >> >> Stef > No, he asked for important things that _needs_ to be fixed :) > 1st is a regression from 1.0. > 2nd I explained a few approaches to "fixing". > 3rd is not a regression from 1.0, but still a blatant problem for anyone expecting to be able to write their code in anything but ascii, and be able to reliably export/import it somewhere else. Whether it is a blocking issue or not, I suppose depends on whom you ask. I will tag all the ones you mentioned as 1.1.... so we can assess. The idea is that not releasing 1.1 because of a bug that was already in 1.0 makes no sense. E.g. it means that everyone already using 1.0 did not find it a grave problem for *months*, so I am sure people can wait for 1.2 to have it fixed. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 11, 2010

[Pharo-project] [update 1.1] #11392

by Marcus Denker

11392 ----- Issue 2533: GradientFillStyle cant change first and last color from halo menu Issue 2207: Rotating text is broken -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 11, 2010

Re: [Pharo-project] GUI Polymorph

by Hilaire Fernandes

Hi Fernando, Sure we can be more optimal in execution term, but it is not my objective. I want the example to be concise and optimal under this term, so smaller then may be easier to catch. Bill, Yes, you can draw segment. Yes you can optimze but it is not the purpose of the documentation. I try to optimize the documentation to its target: get started with GUI programming with Polymorph, and let the reader enjoy. Please consider proposing, additional advanced chapter in the CollaborActive book for some idea about optimization GUI. I will be really happy to read, to learn and to comment on that. Laurent, I removed the heading sections and replace it with Bold style. Thanks for your feedback. Hilaire Fernando olivero a Ã©crit : > Hi Laurent, great work! We need more documentation! > > Just a little coding style i would like to point out. > > I see you are using lazy initialization, but in this case i believe its > a miss-use of the pattern. > Because you always will have a toolbar and a menu bar, since the > creation you are sure you need them, why not go and just initialize them > before installing. > > Let me know what you think. > > > So i propose changing the implementation to : > > initialize > super initialize. > self initializeMenuBar. > self initializeToolbar. > .... > > and > > initializeMenuBar > | menu | > menu := self window newMenu. > menu > addToggle: 'Load' > target: self > selector: #load. > menu > addToggle: 'Save' > target: self > selector: #save. > menubar := self window newToolDockingBar. > menubar > add: 'File' > font: self window theme menuBarFont > icon: nil > help: 'File operations' > subMenu: menu. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 11, 2010

Re: [Pharo-project] seaside.gemstone.com down - unable to build 1.1-dev

by Mariano Martinez Peck

On Fri, Jun 11, 2010 at 1:53 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > http://seaside.gemstone.com/ss/metacello/ is down, > therefore ConfigurationOfPharo can not be used to > build Pharo 1.1. from an updated core. > > See http://downforeveryoneorjustme.com/seaside.gemstone.com > > Maybe the machine is switched to vmware.com? > > However - we should again think about reliable > infrastructure ... > Once I remeber Dale though about having the code in both repositories: squeaksource and gemstone. And when doing ensureMetacello, checks first in gemstone. If it fails, it tries in squeaksource...at least that was the idea...I don't know if it was implemented or not. Cheers mariano > > 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 11, 2010

Re: [Pharo-project] Open Bugs for 1.1

by Adrian Lienhard

Thanks! I was wondering what the status of http://code.google.com/p/pharo/issues/detail?id=1628 is (Error: There is no free space in this set!). It seems critical, and there was some fix proposed, but from the comments it is unclear whether this was integrated or not. Cheers, Adrian On Jun 11, 2010, at 13:14 , Marcus Denker wrote: > Hi, > > The overall number of tracker entries is now 352. > > Tagged ones for 1.1: > > http://code.google.com/p/pharo/issues/list?can=2&q=milestone=1.1 > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

June 11, 2010

Re: [Pharo-project] Three current versions: 1.0, 1.1, 1.2

by Marcus Denker

On Jun 9, 2010, at 1:34 PM, Niko Schwarz wrote: > On Wed, Jun 9, 2010 at 9:29 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Also, people who know there is something that really needs to be fixed for a 1.1 release should speak up now. > > I think http://code.google.com/p/pharo/issues/detail?id=2469 should be > integrated before 1.1. I remember how much of a pain the simulator > behavior was when messing with SUnit. Toon's patch might be the > foundation for cleaner SUnit code. > I added that. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 11, 2010

[Pharo-project] seaside.gemstone.com down - unable to build 1.1-dev

by Torsten Bergmann

http://seaside.gemstone.com/ss/metacello/ is down, therefore ConfigurationOfPharo can not be used to build Pharo 1.1. from an updated core. See http://downforeveryoneorjustme.com/seaside.gemstone.com Maybe the machine is switched to vmware.com? However - we should again think about reliable infrastructure ... 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

June 11, 2010

Re: [Pharo-project] Object>>changed:with: no longer in PharoCore-1.1-11383

by Mariano Martinez Peck

On Fri, Jun 11, 2010 at 8:39 AM, Yanni Chiu <yanni(a)rogers.com> wrote: > Mariano Martinez Peck wrote: > > >> >> On Thu, Jun 10, 2010 at 5:01 PM, Yanni Chiu wrote: >> >> Object>>changed:with: is gone, but strangely, #update:with: is still >> present. The method is needed for the current Glorp package to run >> properly (just the logging, nothing critical). Can it be added back? >> >> >> Hi. Thanks for testing Glorp..I am a little out of time with it. Open a >> bug ticket for it. >> > > Submitted: Issue 2531 > > > > The other solution is to put that method in Glorp > >> with *Glorp category ahaha >> > > I have a set of patches that get filed-in during my build. I have this fix > there, for now. > > There are more for Glorp ? I want to have it perfectly working in Pharo. So, let me know and we can commit and integrate them. Cheers Mariano > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

June 11, 2010