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

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by StÃ©phane Ducasse

>> > > The infinitive in English is two words with possibly other words separating them, the word "to" and then the verb lacking any "s" or "es" or other tense, number or person modifiers: "to program" or "to code." Thanks. I know the difference :) I meant in method selectors include: vs includes: > I choose preservesCDataSections because it is more obvious that it returns a boolean and that the corresponding preservesCDataSections: accepts a boolean. > If you call the testing message preserveCDataSections, No I would write is isPreservingCDataSections doesPreserveCDataSections for me preservesCDataSection: should better be written as preserveCDataSections: Because I do not have to think if I should put an S or not. > it sounds more like you are commanding the receiver to do so rather than asking if it already does.. > > Also, my mail client ate the example code, so here it is again: > doc := > (XMLDOMParser on: '<root><![CDATA[&foo;&bar;]]></root>') > preservesCDataSections: true; Yes but it looks like an order too and I do not understand the difference between using preserveSCD.... and parseDocument (with no S after parseDocument) > parseDocument. > doc root firstNode > produces: > <![CDATA[&foo;&bar;]]> I follow Beck and Smalltalk with Style (see my web page) convention. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Fwd: Re: Squeaksource XML Parser - Enhanced support for CDATA Sections

by jaayer

---- On Tue, 10 Aug 2010 01:45:42 -0700 StÃ©phane Ducasse wrote ---- >Just an api point > >why preservesC... >and not >Â Â Â Â preserverC > >I'm always confuse with the infinitive and third person singular situation. > >Stef The infinitive in English is two words with possibly other words separating them, the word "to" and then the verb lacking any "s" or "es" or other tense, number or person modifiers: "to program" or "to code." I choose preservesCDataSections because it is more obvious that it returns a boolean and that the corresponding preservesCDataSections: accepts a boolean. If you call the testing message preserveCDataSections, it sounds more like you are commanding the receiver to do so rather than asking if it already does.. Also, my mail client ate the example code, so here it is again: doc := (XMLDOMParser on: '<root><![CDATA[&foo;&bar;]]></root>') preservesCDataSections: true; parseDocument. doc root firstNode produces: <![CDATA[&foo;&bar;]]>

Aug. 10, 2010

Re: [Pharo-project] Change set fileout

by Alexandre Bergel

> The bad idea was for me to integrate it and not fix it after I realized the problem. > Thanks. > I was planning to do the same. but now I'm exhausted. ;( Stef, this kind of glitches are normal. No worry. Cheers, Alexandre > > > On Aug 10, 2010, at 8:38 PM, Eliot Miranda wrote: > >> >> >> On Tue, Aug 10, 2010 at 11:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Yes I integrated a "fix" of eliot so that you can fileout category containing / but this is not a so great idea. :) >> >> It's not such a bad idea. Try filing-out a category that contains / (e.g. fileIn/out :) ) without it. But you need to fix other places as well. Andreas fixed this yesterday in trunk by not passing the full path to checkName:fixErrors:. This isn't necessary. One only needs the local name since "FileStream newFileNamed: fileName" will construct a file in the current directory. >> >> >> http://code.google.com/p/pharo/issues/detail?id=2661 >> >> >> writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag useHtml: useHtml >> >> | extension converter f fileName | >> aStream contents isAsciiString ifTrue: [ >> stOrCsFlag ifTrue: [ >> extension := (FileDirectory dot, FileStream st). >> ] ifFalse: [ >> extension := (FileDirectory dot, FileStream cs). >> ]. >> converter := MacRomanTextConverter new. >> ] ifFalse: [ >> stOrCsFlag ifTrue: [ >> extension := (FileDirectory dot, FileStream st "multiSt"). >> ] ifFalse: [ >> extension := (FileDirectory dot, FileStream cs "multiCs"). >> ]. >> converter := UTF8TextConverter new. >> ]. >> fileName := useHtml ifTrue: [baseName, '.html'] ifFalse: [baseName, extension]. >> + fileName := FileDirectory default checkName: fileName fixErrors: true. >> f := FileStream newFileNamed: fileName. >> f ifNil: [^ self error: 'Cannot open file']. >> (converter isMemberOf: UTF8TextConverter) >> ifTrue: [f binary. >> UTF8TextConverter writeBOMOn: f]. >> f text. >> f converter: converter. >> f nextPutAll: aStream contents. >> f close. >> ! >> >> >> checkName: aFileName fixErrors: fixing >> + "Check if the file name contains any invalid characters" >> + | fName | >> + fName := super checkName: aFileName fixErrors: fixing. >> + (fName includes: self class pathNameDelimiter) ifFalse: >> + [^fName]. >> + ^fixing >> + ifTrue: [fName copyReplaceAll: (String with: self class pathNameDelimiter) with: '#'] >> + ifFalse: [self error:'Invalid file name'] >> >> >> >> >> Stef >> >> On Aug 10, 2010, at 4:23 PM, Gary Chambers wrote: >> >>> Has anyone else noticed that, very recently, when filing out change sets from the change sorter the filename is rather odd >>> (at least on Windows)? >>> >>> >>> Instead of the expected "OngoingFixes.2.cs" I'm getting >>> "C##Users#Gazza#Desktop#Pharo#Contents#Resources#OngoingFixes.2.cs" >>> >>> saved where expected (in Contents\Resources). >>> >>> Regards, Gary >>> _______________________________________________ >>> 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 -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2010

Re: [Pharo-project] Change set fileout

by StÃ©phane Ducasse

The bad idea was for me to integrate it and not fix it after I realized the problem. Thanks. I was planning to do the same. but now I'm exhausted. ;( Stef On Aug 10, 2010, at 8:38 PM, Eliot Miranda wrote: > > > On Tue, Aug 10, 2010 at 11:32 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Yes I integrated a "fix" of eliot so that you can fileout category containing / but this is not a so great idea. :) > > It's not such a bad idea. Try filing-out a category that contains / (e.g. fileIn/out :) ) without it. But you need to fix other places as well. Andreas fixed this yesterday in trunk by not passing the full path to checkName:fixErrors:. This isn't necessary. One only needs the local name since "FileStream newFileNamed: fileName" will construct a file in the current directory. > > > http://code.google.com/p/pharo/issues/detail?id=2661 > > > writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag useHtml: useHtml > > | extension converter f fileName | > aStream contents isAsciiString ifTrue: [ > stOrCsFlag ifTrue: [ > extension := (FileDirectory dot, FileStream st). > ] ifFalse: [ > extension := (FileDirectory dot, FileStream cs). > ]. > converter := MacRomanTextConverter new. > ] ifFalse: [ > stOrCsFlag ifTrue: [ > extension := (FileDirectory dot, FileStream st "multiSt"). > ] ifFalse: [ > extension := (FileDirectory dot, FileStream cs "multiCs"). > ]. > converter := UTF8TextConverter new. > ]. > fileName := useHtml ifTrue: [baseName, '.html'] ifFalse: [baseName, extension]. > + fileName := FileDirectory default checkName: fileName fixErrors: true. > f := FileStream newFileNamed: fileName. > f ifNil: [^ self error: 'Cannot open file']. > (converter isMemberOf: UTF8TextConverter) > ifTrue: [f binary. > UTF8TextConverter writeBOMOn: f]. > f text. > f converter: converter. > f nextPutAll: aStream contents. > f close. > ! > > > checkName: aFileName fixErrors: fixing > + "Check if the file name contains any invalid characters" > + | fName | > + fName := super checkName: aFileName fixErrors: fixing. > + (fName includes: self class pathNameDelimiter) ifFalse: > + [^fName]. > + ^fixing > + ifTrue: [fName copyReplaceAll: (String with: self class pathNameDelimiter) with: '#'] > + ifFalse: [self error:'Invalid file name'] > > > > > Stef > > On Aug 10, 2010, at 4:23 PM, Gary Chambers wrote: > > > Has anyone else noticed that, very recently, when filing out change sets from the change sorter the filename is rather odd > > (at least on Windows)? > > > > > > Instead of the expected "OngoingFixes.2.cs" I'm getting > > "C##Users#Gazza#Desktop#Pharo#Contents#Resources#OngoingFixes.2.cs" > > > > saved where expected (in Contents\Resources). > > > > Regards, Gary > > _______________________________________________ > > 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

Aug. 10, 2010

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

by Alexandre Bergel

> I think I will add an on/off switch for Autotest, sometimes I don't want it to run on debugging sessions for long tests This is good. I usually open and close Autotest. But having a switch will definitely help. When it is switched off, then you can monitor the test that should be run. That will be useful. Cheers, Alexandre > > Laurent > > > Cheers, > Alexandre > > > > > > > On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > Ideally, we should not tag long tests. The system should be smart enough to characterize a test as long. If it takes more than 200ms, then it is long. Autotest should then offer me to include long test or not in the automatic test execution. > > > > Using tags means that I have to go over each method test and tag them. This is a costly effort that is likely to not work in practice. > > > > We have > > -=-=-=-=-=-=-=-=-=-=-=-= > > TestCase class>>newTestDictionary > > ^ Dictionary new at: #timeStamp put: TimeStamp now; > > at: #passed put: Set new; > > at: #failures put: Set new; > > at: #errors put: Set new; > > yourself > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > Maybe it should be extended with > > -=-=-=-=-=-=-=-=-=-=-=-= > > at: #long put: Set new > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > I guess the tweak in SUnit to identify long tests should not be that hard to implement. > > > > Cheers, > > Alexandre > > > > > > On 26 Jul 2010, at 07:44, laurent laffont wrote: > > > > > > > > On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel <alexandre(a)bergel.eu> wrote: > > > I have been using Autotest for a while already. I greatly reduce the window switching. This is cool. > > > However, I have to disable Autotest when the tests take time to execute. > > > > > > > > > An idea is to be able to tag tests with pragmas to put them in categories. So we can have a LongRunning category which is not run by default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) > > > > > > Then SUnit could be enhanced to show these categories. Useful to quickly select all tests related to a project for example; or run only performance tests. > > > > > > > > > How would you name the tag ? Where the implementation should go ? (TestCase ?) > > > > > > > > > Laurent. > > > > > > > > > Alexandre > > > > > > > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > > > > > Hi Alexandre, > > > > > > > > I've reorganized Autotest to write tests. The tests now run in a thread with lower priority. Thanks for feedback. > > > > > > > > Cheers, > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > 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? > > > > > > > > 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 > > > > > > _______________________________________________ > > > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Aug. 10, 2010

Re: [Pharo-project] Change set fileout

by Eliot Miranda

On Tue, Aug 10, 2010 at 11:32 AM, StÃ©phane Ducasse < stephane.ducasse(a)inria.fr> wrote: > Yes I integrated a "fix" of eliot so that you can fileout category > containing / but this is not a so great idea. :) > It's not such a bad idea. Try filing-out a category that contains / (e.g. fileIn/out :) ) without it. But you need to fix other places as well. Andreas fixed this yesterday in trunk by not passing the full path to checkName:fixErrors:. This isn't necessary. One only needs the local name since "FileStream newFileNamed: fileName" will construct a file in the current directory. > http://code.google.com/p/pharo/issues/detail?id=2661 > > > writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag useHtml: > useHtml > > | extension converter f fileName | > aStream contents isAsciiString ifTrue: [ > stOrCsFlag ifTrue: [ > extension := (FileDirectory dot, FileStream st). > ] ifFalse: [ > extension := (FileDirectory dot, FileStream cs). > ]. > converter := MacRomanTextConverter new. > ] ifFalse: [ > stOrCsFlag ifTrue: [ > extension := (FileDirectory dot, FileStream st > "multiSt"). > ] ifFalse: [ > extension := (FileDirectory dot, FileStream cs > "multiCs"). > ]. > converter := UTF8TextConverter new. > ]. > fileName := useHtml ifTrue: [baseName, '.html'] ifFalse: [baseName, > extension]. > + fileName := FileDirectory default checkName: fileName fixErrors: > true. > f := FileStream newFileNamed: fileName. > f ifNil: [^ self error: 'Cannot open file']. > (converter isMemberOf: UTF8TextConverter) > ifTrue: [f binary. > UTF8TextConverter writeBOMOn: f]. > f text. > f converter: converter. > f nextPutAll: aStream contents. > f close. > ! > > > checkName: aFileName fixErrors: fixing > + "Check if the file name contains any invalid characters" > + | fName | > + fName := super checkName: aFileName fixErrors: fixing. > + (fName includes: self class pathNameDelimiter) ifFalse: > + [^fName]. > + ^fixing > + ifTrue: [fName copyReplaceAll: (String with: self class > pathNameDelimiter) with: '#'] > + ifFalse: [self error:'Invalid file name'] > > > > > Stef > > On Aug 10, 2010, at 4:23 PM, Gary Chambers wrote: > > > Has anyone else noticed that, very recently, when filing out change sets > from the change sorter the filename is rather odd > > (at least on Windows)? > > > > > > Instead of the expected "OngoingFixes.2.cs" I'm getting > > "C##Users#Gazza#Desktop#Pharo#Contents#Resources#OngoingFixes.2.cs" > > > > saved where expected (in Contents\Resources). > > > > Regards, Gary > > _______________________________________________ > > 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 >

Aug. 10, 2010

Re: [Pharo-project] Change set fileout

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/list?thanks=2779 > > Instead of the expected "OngoingFixes.2.cs" I'm getting > "C##Users#Gazza#Desktop#Pharo#Contents#Resources#OngoingFixes.2.cs"

Aug. 10, 2010

Re: [Pharo-project] Why StringHolder

by StÃ©phane Ducasse

great! Stef On Aug 10, 2010, at 8:19 PM, Guillermo Polito wrote: > Ok, I checked CUIS and it is using SmalltalkEditor and TextEditor as expected, and there is no notice of ParagraphEditor :). > In squeak 4.1, there are yet some usages of ParagraphEditor, but in some View objects I don't see in Pharo nor in CUIS. > I opened an issue for replacing ParagraphEditor: > > http://code.google.com/p/pharo/issues/detail?id=2778 > > Cheers! > > On Tue, Aug 10, 2010 at 10:12 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > > > What's CUIS? :( > > another squeak fork > > > - then we should probably rewrite some parts and do not inherit from StringHolder > > I never understood why MessageSet is a subclass of Browser :) > > But I would focus on the > > > > > > on the ...? > > paragraphEditor kicking out > > > > > > > > StringHolder class comment says: "I am a kind of Model that includes a piece of text. In some cases, the text can be edited, and in some the text is a method." > > > > > > And I smell that its main responsibility is to hold a Text or a String in its contents variable, and all its subclasses are there because of that... And if so, I don't like that inheritance approach :). > > > > This is exact. > > > > > I want to destroy (literally) that hierarchy :). And maybe it helps us in coming refactors and cleanings, so we can do them with less fear :P. > > > > So could you > > review benjamin code? > > > > This evening I'll check it and compare it with the existant RecentMessageSet and that stuff. > > > > then check the texteditor/paragraphEditor > > > > I'll write it down in my TODO list :). But the idea is to replace ParagraphEditor with them, is it? > > yes > > > > > > > > > Well, this mail is just for ask for advice and argue about the correctness of this change (or not). > > > > > > Thanks for reading up to here! > > > Guille > > > _______________________________________________ > > > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

Re: [Pharo-project] Polymorph enhancements

by StÃ©phane Ducasse

On Aug 10, 2010, at 5:27 PM, Tudor Girba wrote: > Aha, that is it then (I am using the default Watery theme). > > I will give 1.2 a try. We should anyway switch Moose to it soon :). so soon? 1.2 is bleeeeeeeeeeding edge :) You know it. Stef > > Cheers, > Doru > > > On 10 Aug 2010, at 17:24, Gary Chambers wrote: > >> Only for 1.2 due to changes in the window controls (is ok in 1.1 for themes other than Watery/Watery2)... >> >> Regards, Gary >> >> ----- Original Message ----- From: "Gary Chambers" <gazzaguru2(a)btinternet.com> >> To: <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, August 10, 2010 4:11 PM >> Subject: Re: [Pharo-project] Polymorph enhancements >> >> >>> Only tested on the bleeding edge 1.2... >>> >>> Shouldn't crash though (if not on W2K theme)... >>> Do you have a debug log available? >>> >>> Regards, Gary >>> >>> ----- Original Message ----- From: "Tudor Girba" <tudor.girba(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Tuesday, August 10, 2010 4:07 PM >>> Subject: Re: [Pharo-project] Polymorph enhancements >>> >>> >>>> Ah, ok. I will wait :) >>>> >>>> Doru >>>> >>>> >>>> On 10 Aug 2010, at 16:39, Gary Chambers wrote: >>>> >>>>> Wait a mo, need to upload a fix for W2K theme... project hosting is currently read-only... >>>>> >>>>> Regards, Gary >>>>> ----- Original Message ----- >>>>> From: Gary Chambers >>>>> To: Pharo Development >>>>> Sent: Tuesday, August 10, 2010 3:31 PM >>>>> Subject: [Pharo-project] Polymorph enhancements >>>>> >>>>> See: http://code.google.com/p/pharo/issues/detail?id=2777 >>>>> >>>>> Mostly since Doru expressed an interest in closable tabs... ;-) >>>>> >>>>> Regards, Gary >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project________… >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "If you interrupt the barber while he is cutting your hair, >>>> you will end up with a messy haircut." >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -- > www.tudorgirba.com > > "Reasonable is what we are accustomed with." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 10, 2010

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

by laurent laffont

On Tue, Aug 10, 2010 at 2:21 PM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Sorry to answer so late. I was having few days off. I am now up and running > :-) > > > Now that I've managed to use Pharo at work (youhou !!) I'm in a case > where I have very long tests (selenium acceptance tests) *and* I want them > to run. Ideally I also want to queue and schedule them (if a test is saved > twice in a queue, run only once and put it in higher position on the queue). > > How can a test be saved twice in a queue? If you accept twice the same > method? > Actually when Autotest is running it discards all method modified event. I would like to queue these events. > > Solutions: > > - have to running modes for Autotest (normal and batch) > > - tagging > > - ? > > tagging will not work I feel. We could have different modes for autotest: > > -exhaustive: run all the tests, including long ones > -transparent: run no more than 2 short tests > -test only: run the test only when I modify them > I think I will add an on/off switch for Autotest, sometimes I don't want it to run on debugging sessions for long tests Laurent Cheers, > Alexandre > > > > > > > On Mon, Jul 26, 2010 at 8:01 AM, Alexandre Bergel <alexandre(a)bergel.eu> > wrote: > > Ideally, we should not tag long tests. The system should be smart enough > to characterize a test as long. If it takes more than 200ms, then it is > long. Autotest should then offer me to include long test or not in the > automatic test execution. > > > > Using tags means that I have to go over each method test and tag them. > This is a costly effort that is likely to not work in practice. > > > > We have > > -=-=-=-=-=-=-=-=-=-=-=-= > > TestCase class>>newTestDictionary > > ^ Dictionary new at: #timeStamp put: TimeStamp now; > > at: #passed put: Set new; > > at: #failures put: Set new; > > at: #errors put: Set new; > > yourself > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > Maybe it should be extended with > > -=-=-=-=-=-=-=-=-=-=-=-= > > at: #long put: Set new > > -=-=-=-=-=-=-=-=-=-=-=-= > > > > I guess the tweak in SUnit to identify long tests should not be that hard > to implement. > > > > Cheers, > > Alexandre > > > > > > On 26 Jul 2010, at 07:44, laurent laffont wrote: > > > > > > > > On Sat, Jul 24, 2010 at 10:16 AM, Alexandre Bergel < > alexandre(a)bergel.eu> wrote: > > > I have been using Autotest for a while already. I greatly reduce the > window switching. This is cool. > > > However, I have to disable Autotest when the tests take time to > execute. > > > > > > > > > An idea is to be able to tag tests with pragmas to put them in > categories. So we can have a LongRunning category which is not run by > default. Like NUnit (http://www.nunit.org/index.php?p=category&r=2.2) > > > > > > Then SUnit could be enhanced to show these categories. Useful to > quickly select all tests related to a project for example; or run only > performance tests. > > > > > > > > > How would you name the tag ? Where the implementation should go ? > (TestCase ?) > > > > > > > > > Laurent. > > > > > > > > > Alexandre > > > > > > > > > On 15 Jun 2010, at 21:41, laurent laffont wrote: > > > > > > > Hi Alexandre, > > > > > > > > I've reorganized Autotest to write tests. The tests now run in a > thread with lower priority. Thanks for feedback. > > > > > > > > Cheers, > > > > > > > > Laurent Laffont > > > > > > > > http://pharocasts.blogspot.com/ > > > > http://magaloma.blogspot.com/ > > > > > > > > > > > > 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? > > > > > > > > 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 > > > > > > _______________________________________________ > > > 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 >

Aug. 10, 2010