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

Re: [Pharo-project] About TDD and Pharo

by laurent laffont

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 >

June 3, 2010

[Pharo-project] [ANN 1.1] pre-build beta 11383

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27077/PharoCore-1.1-11383-Beta.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Alexandre Bergel

> 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? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Simon Denier

On 3 juin 2010, at 14:24, Sean P. DeNigris wrote: > > > StÃ©phane Ducasse wrote: >> >> what is important for me is that we distinguish what is related to the UI >> flow from the loading of a specific >> tests libraries. >> RIght now I would like to concentrate on UI flow and tools interaction. >> > > Oh, okay - got it. In that case: > +1 for autotest-like functionality, where appropriate tests are run when > code is saved (I haven't thought through how it could work, but it sounds > great; maybe run tests that are senders of the saved method?) 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. -- Simon

June 3, 2010

Re: [Pharo-project] Can I use Projects in Pharo?

by Sean P. DeNigris

Thanks for all the great feedback! It's great to discuss because it makes me think about what's really important and why... Mariano Martinez Peck wrote: > > I think we should not reinvent the wheel in Pharo. I mean, Morphic is > nice, > although I would like to have native windows so that I can use my Mac > expose > features. But no, I have only one window. > I secretly pray for a world where the OS/application paradigm disappears like T-rex in a meteor shower ;-) and I do a lot of cross-platform work (Windows and Mac mostly), so relying on OS features doesn't work for me. Mariano Martinez Peck wrote: > > Then, I have something similar but > implemented in Pharo using Mac + narrows. > Do you mean the window cycling within Pharo? That's not all that similar! It still has totally (logically) unrelated windows fighting for screen space. There's no way to bring up the *set* of windows related to task A, and then back to B. Mariano Martinez Peck wrote: > > I also have tons of image, and each image (or more than one) for a > project. > Why don't you use your own OS virtual workspaces and spread you different > images over the different workspaces? that's easier than Squeak Projects. > And maybe faster and better supported. > This seems to come down to vision and work habits. My vision is to use one image for everything, where all my data is available to all other data, and I can explore interesting relationships between (seemingly) unrelated bits. Using many images, to me, is a giant step back toward existing mainstream options. Plus, anything we do in Pharo is infinitely user customizable and fixable - not so with OS features. For example, I have exactly three options for the space-switching shortcut on the Mac - wow, thanks for all the options! Mariano Martinez Peck wrote: > > - In Pharo we have a good package management system now (Metacello). If > you > use it correctly, you can define all your project dependencies (even > working > in a core or dev image). So you should be able to load your project in any > image without any problem. > Yes, definitely! Metacello is great for sharing and deploying, but again, using one system for everything is one of the key reasons I came to the Squeak/Pharo world - if I wanted everything separate, there is Mac software for each task that probably (due to maturity and market) does each better. Mariano Martinez Peck wrote: > > - We release images quite frequently, much more than other > dialects/languages. So...usually you don't have to wait too much to get a > new image with the fixed issue. > [gasp] complain and wait until my issue is fixed!!! I can't imagine it ;-) When I find an issue, if I can, I fix it myself and move on with my work. Mariano Martinez Peck wrote: > > - How many times you find an issue that affects all your projects? I > don't > think this is very common. Usually, when I find a bug or a problem, is not > "too" core in the sense that only affects me in a particular place, but > not > in all my other work. > Often enough with the tools. Two quick examples: * while using SSpec, I've found and fixed various bugs, e.g. in the test runner, which effected all the projects I'm working on simultaneously. I didn't want to stop what I was doing, upload the project, write a Metacello configuration for it, and install it in X other images, and I didn't have to because I only had one image. * while working with the monticello browser, every time I wanted to add a "directory" repository (which I do frequently), I had to start searching from the default directory, even though all my repos are in the same parent folder. So I added a setting for it and kept working. Summary: For me, the separate image approach is a hack to simulate a missing feature, with tradeoffs that don't work for the way I do. Cheers, Sean -- View this message in context: http://forum.world.st/Can-I-use-Projects-in-Pharo-tp2239170p2241621.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 2 June 2010 16:59, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Some news (sources at www.squeaksource.com/Athens) >> >> About having a first 'minimal' version, working with RomePluginCanvas and RomeReferenceCanvas, Â it seems to be ok. >> I retrieve the tests from Sophie and all are green. >> In romeDemo, I made a category Â with some working examples (using RomePluginCanvas and RomeRefrenceCanvas). >> >> However, There is still some primitive faillures for which I'm not able to do a lot of things: see for example RomeDemo class >> demoRotateWindow. > > >> >> Now about fonts, I thing the best is to rebuild all: a part of the code is using some Tweak specific classes, or other classes no longer present in Pharo. >> Morover I wonder why it is usefull to have a Rome-comon API for fonts (RomeFont), when pharo as already its own AbstractFont API ? > > I guess that the idea was really to have an API > >> fonts are just set to a canvas to draw strings. You can see an example using fonts in RomeDemo class >> demoRotateSophieLogo. >> >> From tweak, I only kept classes about CTransformCanvas, but I don't know what it is Â :) There is just a working example in RomeDemo. So maybe it could be removed (I think all the 'Athens-Tweak' category could be removed). >> >> So maybe at this point we could start to fix the API (?) > > Excellent! > So may be we could put ROME in pharo-dev as a demo? > But without bindings with Morphic, its not really userful. > Stef > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

June 3, 2010

Re: [Pharo-project] Multiple Worlds (was Re: Can I use Projects in Pharo?)

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > there is a key point in all this thread. > we are not against ideas. > Ha ha, I never thought otherwise :) StÃ©phane Ducasse wrote: > > We loved etoys and I did more presentations about it than probably 95% of > the squeakers population > now we do not like its implementation because it hurts us. > Same for projects. Simple. > Yes, I got that. That's why I forked this thread - to refocus on the multiple world feature, and away from the existing project implementation. I'll add the mockup to my todo list (with key bindings at the top), but the immediate future will be working on a commercial project in Pharo - yay! Sean -- View this message in context: http://forum.world.st/Multiple-Worlds-was-Re-Can-I-use-Projects-in-Pharo-tp… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > what is important for me is that we distinguish what is related to the UI > flow from the loading of a specific > tests libraries. > RIght now I would like to concentrate on UI flow and tools interaction. > Oh, okay - got it. In that case: +1 for autotest-like functionality, where appropriate tests are run when code is saved (I haven't thought through how it could work, but it sounds great; maybe run tests that are senders of the saved method?) Sean -- View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2241578.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2010

Re: [Pharo-project] About TDD and Pharo

by Sean P. DeNigris

StÃ©phane Ducasse wrote: > > but is it not just using SSpec? > SSpec is not bad, but needs some work. StÃ©phane Ducasse wrote: > > Did SSpec still loads? > It loads, but most of the tests fail - even though the project itself mostly works. StÃ©phane Ducasse wrote: > > Does it load in pharo well? > It definitely works in 1.0. I don't remember if I loaded it in 1.1, I'll try when I get a minute. StÃ©phane Ducasse wrote: > > Where is it? > SqS. I will upload my fixes soon. Sean -- View this message in context: http://forum.world.st/About-TDD-and-Pharo-tp2240686p2241568.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2010

Re: [Pharo-project] Can I use Projects in Pharo?

by Geert Claes

Mariano Martinez Peck wrote: > > I think we should not reinvent the wheel in Pharo. I mean, Morphic is > nice, although I would like to have native windows so that I can use my > Mac expose features. But no, I have only one window. Then, I have > something similar but implemented in Pharo using Mac + narrows. > > Then, you can have more than one workspace in the OS, why we need to > implement the same in Pharo ? > > I also have tons of image, and each image (or more than one) for a > project. Why don't you use your own OS virtual workspaces and spread you > different images over the different workspaces? that's easier than Squeak > Projects. And maybe faster and better supported. > Agree .... mind you I don't use spaces :) Mariano Martinez Peck wrote: > > The ONLY problem is what people said about updating issues in all images. > But, : > > - In Pharo we have a good package management system now (Metacello). If > you use it correctly, you can define all your project dependencies (even > working in a core or dev image). So you should be able to load your > project in any image without any problem. > Yep, I already mentioned that in my first reply here -- View this message in context: http://forum.world.st/Can-I-use-Projects-in-Pharo-tp2239170p2241332.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 3, 2010