March 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] about run tests from nautilus

by stephane ducasse

I see what you mean and you will show that to me. I tend to do not like to have three different testing framework, 5 button classesâ¦ especially when people building tools have to take care about different conventions. Stef >> I do not buy this argument you will have to show me. >> >> when I see >> >> self assert: contents = $A > > already in this case, looking at the debugger you're stuck with a silly message that > doesn't give you the slightest hint of what is wrong. You don't see in the debugger > "Got ... instead of $A". > > You have to write > > self assert: contents equals: $A > > to get a "Got ... instead of $A" message. Well now it is matter of style writing > > contents should = $A > > Look at all the tests in ReleaseTest, and you will see that we have to manually > capture the contents before doing any assertion, otherwise the results on the build > server are not of much use. Even if we have a serialized stack with fuel, there is > no way I can get the result that was used for the comparison. That is unless I > use #assert:equals: everywhere! > >> I do not see the difference with >> contents should be equals: $A > > no, not #equals, you send #=, which is natural, and get a decent error message for free. > >> except that I do not understand what is be and that every object is extended with should and friends. > > no need to use the #be. > >> Then I do not want to chain results of tests. >> >> Stef >> >>>> pfffff can we stop such kind of mess. >>>> I frankly do not see the value of >>> >>> Think about the error messages here. >>> >>>> self should not be = $a >>> >>> Error message will be something like: Got 'adsfasdfasd' instead of $a >>> >>>> vs >>>> self assert: self = $a >>> >>> and here? >>> Assertion failed >>> >>> AKA 0 contextual information. Now it gets even worse when doing things like >>> #should:raise: and friends. You have to fully restart the test case to even >>> when debugging it just because you don't have decent error messages. >>> >>> Now this is what Phexample brings, 10 clicks less per failed assertion. >>> I want that in 3.0. Besides in most cases a tree rewrite will do the proper >>> transformation, so 0 effort for nice error messages. >> >> this is my point I do not see why I get something more complex that what we already have. >> >> No need to reply I see that should construct a nice object whatever. Now to me it does not help >> me. I prefer to get a better Sunit. >> >> >> >> >>>> I looked and most of the tests in Moose do not gain anything to rely on phExample. >>>> And now such change break nautilus. >>> >>> they don't break nautilus if the test in nautilus were implemented as I said before. >>> >>> >> >> > >

March 3, 2013

[Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by Torsten Bergmann

Stef, this is not a problem of SqS. I copied the two new versions manually today back from MetacelloRepository to the SqS/Pastell repo since it looks like they were missing there. This is historic and from the time when usually sqS/MetacelloRepository was used for all configurations. It's not a real problem that the numbers have changed - I dont think many people reference Pastell. I already updated my other configs. If you have a script it should take care in the future if a newer ConfigurationOfXXX is either - in sqS/MetacelloRepository - or the projects own directory Regarding version numbers: I would vote for two digits - Major and minor version. So usually you start with 0.1, then 0.2, 0.3, ... When you make a patch to an old (problematic) version then you branch with a patch number. So for instance 0.2.1 means it is the first patch for Version 0.2. Bye T.

March 3, 2013

Re: [Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by stephane ducasse

Hi nicolas > Semantic versionning? http://semver.org/ thanks for the pointer. I could follow it. But we should have tool support for that. > In that case, the 3 numbers major.minor.patch are used this way: > > - the last is changed for bugfix only > - the second is changed for new functionality only with 100% backward > compatibility > - the first is changed when backward compatibility is broken so if you have a non working system with number 1.0 and after you get all the tests green because you load the correct dependent library then it means that you should get 1.1. Because making a system working for real is not a patch. Stef > > Nicolas > > 2013/3/3 stephane ducasse <stephane.ducasse(a)free.fr>: >> >> On Mar 3, 2013, at 9:08 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: >> >>> Stef wrote: >>>> Pastell is now migrated to SmalltalkHub and has a nice CI job >>> >>> Please note that previously ConfigurationOfPastell >>> had the versions: 1.0, 1.0.2, 1.0.3, 1.0.4 and now >> >> where? >> >>> has the versions: 1.0, 1.1., 1.2, 1.3 >>> >>> That broke other configurations that depend for instance on 1.0.4 >> >> this is strange because when I queried the repository I only got >> >> Name: ConfigurationOfPastell-AlexandreBergel.2 >> Author: AlexandreBergel >> Time: 12 September 2012, 11:43:37.215 am >> UUID: ddd4217f-9fd0-234c-9669-e02e8634e984 >> Ancestors: ConfigurationOfPastell-AlexandreBergel.1 >> >> 1.0 : First shoot! >> no tbn.4 and not 5 >> >> Now when I look at it with the MC browser I see more. >> So I redid everything for nothing. Fucking crappy system. >> >> >> and the version was only >> >> baseline10: spec >> <version: '1.0-baseline'> >> >> spec for: #'common' do: [ >> spec blessing: #'baseline'. >> spec repository: 'http://www.squeaksource.com/Pastell'. >> spec package: 'Pastell'. >> spec group: 'default' with: #('Pastell' ). ]. >> >> so just an illusion. no dependency at all on XMLParser. Then the packages pastell-base was wrong since the tests could not work. >> >> >>> and it adds a lot of confusion! >> >> Nice to tell me that I spent my sunday on doing bullshit. :) >> Squeaksource is the confusion and if nobody moves then nothing will ever change. >> >> Have a look at the repo on smalltalkhub and you will see that apparently the two last files were not given to me >> when I used my ****automatic***** migration scriptâ¦. scary! >> >> Now if squeaksource does not serve all the files. We should really run away! >> >> >>> Why didnt you just continue with 1.0.5 or 2.0? >> >> Why people started to have 1.0.2 after 1.0? >> What is the reason? >> Then may be we should start also to have >> 1.0.0.0.1 to have enough digits. >> >> I hate this numbering and I see no value beside bad marketing like seaside 3.0.2.a >> >> >>> >>> Thanks >>> T. >>> >>> >>> >> >> >

March 3, 2013

Re: [Pharo-project] about run tests from nautilus

by Camillo Bruni

On 2013-03-03, at 21:16, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > I do not buy this argument you will have to show me. > > when I see > > self assert: contents = $A already in this case, looking at the debugger you're stuck with a silly message that doesn't give you the slightest hint of what is wrong. You don't see in the debugger "Got ... instead of $A". You have to write self assert: contents equals: $A to get a "Got ... instead of $A" message. Well now it is matter of style writing contents should = $A Look at all the tests in ReleaseTest, and you will see that we have to manually capture the contents before doing any assertion, otherwise the results on the build server are not of much use. Even if we have a serialized stack with fuel, there is no way I can get the result that was used for the comparison. That is unless I use #assert:equals: everywhere! > I do not see the difference with > contents should be equals: $A no, not #equals, you send #=, which is natural, and get a decent error message for free. > except that I do not understand what is be and that every object is extended with should and friends. no need to use the #be. > Then I do not want to chain results of tests. > > Stef > >>> pfffff can we stop such kind of mess. >>> I frankly do not see the value of >> >> Think about the error messages here. >> >>> self should not be = $a >> >> Error message will be something like: Got 'adsfasdfasd' instead of $a >> >>> vs >>> self assert: self = $a >> >> and here? >> Assertion failed >> >> AKA 0 contextual information. Now it gets even worse when doing things like >> #should:raise: and friends. You have to fully restart the test case to even >> when debugging it just because you don't have decent error messages. >> >> Now this is what Phexample brings, 10 clicks less per failed assertion. >> I want that in 3.0. Besides in most cases a tree rewrite will do the proper >> transformation, so 0 effort for nice error messages. > > this is my point I do not see why I get something more complex that what we already have. > > No need to reply I see that should construct a nice object whatever. Now to me it does not help > me. I prefer to get a better Sunit. > > > > >>> I looked and most of the tests in Moose do not gain anything to rely on phExample. >>> And now such change break nautilus. >> >> they don't break nautilus if the test in nautilus were implemented as I said before. >> >> > >

March 3, 2013

Re: [Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by stephane ducasse

So what do we do? because frankly I'm fed up and when I see 10 then 102 for a baseline when we had dependency to a project that else makes sure that the system does not work at all I'm puzzled. Now I do not have the time to change that. if you have go ahead. A bit of rigor and consistency would help. I do not understand why programmer number things like that at leas we should have 1.1 1.2 2.0 means major changes to me 1.0.2 does not mean nothing. Stef

March 3, 2013

Re: [Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by Nicolas Cellier

Semantic versionning? http://semver.org/ In that case, the 3 numbers major.minor.patch are used this way: - the last is changed for bugfix only - the second is changed for new functionality only with 100% backward compatibility - the first is changed when backward compatibility is broken Nicolas 2013/3/3 stephane ducasse <stephane.ducasse(a)free.fr>: > > On Mar 3, 2013, at 9:08 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > >> Stef wrote: >>> Pastell is now migrated to SmalltalkHub and has a nice CI job >> >> Please note that previously ConfigurationOfPastell >> had the versions: 1.0, 1.0.2, 1.0.3, 1.0.4 and now > > where? > >> has the versions: 1.0, 1.1., 1.2, 1.3 >> >> That broke other configurations that depend for instance on 1.0.4 > > this is strange because when I queried the repository I only got > > Name: ConfigurationOfPastell-AlexandreBergel.2 > Author: AlexandreBergel > Time: 12 September 2012, 11:43:37.215 am > UUID: ddd4217f-9fd0-234c-9669-e02e8634e984 > Ancestors: ConfigurationOfPastell-AlexandreBergel.1 > > 1.0 : First shoot! > no tbn.4 and not 5 > > Now when I look at it with the MC browser I see more. > So I redid everything for nothing. Fucking crappy system. > > > and the version was only > > baseline10: spec > <version: '1.0-baseline'> > > spec for: #'common' do: [ > spec blessing: #'baseline'. > spec repository: 'http://www.squeaksource.com/Pastell'. > spec package: 'Pastell'. > spec group: 'default' with: #('Pastell' ). ]. > > so just an illusion. no dependency at all on XMLParser. Then the packages pastell-base was wrong since the tests could not work. > > >> and it adds a lot of confusion! > > Nice to tell me that I spent my sunday on doing bullshit. :) > Squeaksource is the confusion and if nobody moves then nothing will ever change. > > Have a look at the repo on smalltalkhub and you will see that apparently the two last files were not given to me > when I used my ****automatic***** migration scriptâ¦. scary! > > Now if squeaksource does not serve all the files. We should really run away! > > >> Why didnt you just continue with 1.0.5 or 2.0? > > Why people started to have 1.0.2 after 1.0? > What is the reason? > Then may be we should start also to have > 1.0.0.0.1 to have enough digits. > > I hate this numbering and I see no value beside bad marketing like seaside 3.0.2.a > > >> >> Thanks >> T. >> >> >> > >

March 3, 2013

Re: [Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by stephane ducasse

On Mar 3, 2013, at 9:08 PM, "Torsten Bergmann" <astares(a)gmx.de> wrote: > Stef wrote: >> Pastell is now migrated to SmalltalkHub and has a nice CI job > > Please note that previously ConfigurationOfPastell > had the versions: 1.0, 1.0.2, 1.0.3, 1.0.4 and now where? > has the versions: 1.0, 1.1., 1.2, 1.3 > > That broke other configurations that depend for instance on 1.0.4 this is strange because when I queried the repository I only got Name: ConfigurationOfPastell-AlexandreBergel.2 Author: AlexandreBergel Time: 12 September 2012, 11:43:37.215 am UUID: ddd4217f-9fd0-234c-9669-e02e8634e984 Ancestors: ConfigurationOfPastell-AlexandreBergel.1 1.0 : First shoot! no tbn.4 and not 5 Now when I look at it with the MC browser I see more. So I redid everything for nothing. Fucking crappy system. and the version was only baseline10: spec <version: '1.0-baseline'> spec for: #'common' do: [ spec blessing: #'baseline'. spec repository: 'http://www.squeaksource.com/Pastell'. spec package: 'Pastell'. spec group: 'default' with: #('Pastell' ). ]. so just an illusion. no dependency at all on XMLParser. Then the packages pastell-base was wrong since the tests could not work. > and it adds a lot of confusion! Nice to tell me that I spent my sunday on doing bullshit. :) Squeaksource is the confusion and if nobody moves then nothing will ever change. Have a look at the repo on smalltalkhub and you will see that apparently the two last files were not given to me when I used my ****automatic***** migration scriptâ¦. scary! Now if squeaksource does not serve all the files. We should really run away! > Why didnt you just continue with 1.0.5 or 2.0? Why people started to have 1.0.2 after 1.0? What is the reason? Then may be we should start also to have 1.0.0.0.1 to have enough digits. I hate this numbering and I see no value beside bad marketing like seaside 3.0.2.a > > Thanks > T. > > >

March 3, 2013

Re: [Pharo-project] about run tests from nautilus

by stephane ducasse

I do not buy this argument you will have to show me. when I see self assert: contents = $A I do not see the difference with contents should be equals: $A except that I do not understand what is be and that every object is extended with should and friends. Then I do not want to chain results of tests. Stef >> pfffff can we stop such kind of mess. >> I frankly do not see the value of > > Think about the error messages here. > >> self should not be = $a > > Error message will be something like: Got 'adsfasdfasd' instead of $a > >> vs >> self assert: self = $a > > and here? > Assertion failed > > AKA 0 contextual information. Now it gets even worse when doing things like > #should:raise: and friends. You have to fully restart the test case to even > when debugging it just because you don't have decent error messages. > > Now this is what Phexample brings, 10 clicks less per failed assertion. > I want that in 3.0. Besides in most cases a tree rewrite will do the proper > transformation, so 0 effort for nice error messages. this is my point I do not see why I get something more complex that what we already have. No need to reply I see that should construct a nice object whatever. Now to me it does not help me. I prefer to get a better Sunit. >> I looked and most of the tests in Moose do not gain anything to rely on phExample. >> And now such change break nautilus. > > they don't break nautilus if the test in nautilus were implemented as I said before. > >

March 3, 2013

[Pharo-project] Pastell is now migrated to SmalltalkHub and has a nice CI job

by Torsten Bergmann

Stef wrote: > Pastell is now migrated to SmalltalkHub and has a nice CI job Please note that previously ConfigurationOfPastell had the versions: 1.0, 1.0.2, 1.0.3, 1.0.4 and now has the versions: 1.0, 1.1., 1.2, 1.3 That broke other configurations that depend for instance on 1.0.4 and it adds a lot of confusion! Why didnt you just continue with 1.0.5 or 2.0? Thanks T.

March 3, 2013

Re: [Pharo-project] Fwd: Amber git repo moved to the amber organisation

by phil＠highoctane.be

Forget previous mail, clicking on the class gives me just that... 2013/3/3 Nicolas Petton <petton.nicolas(a)gmail.com>: > > > Begin forwarded message: > >> From: Nicolas Petton <petton.nicolas(a)gmail.com> >> Subject: Amber git repo moved to the amber organisation >> Date: March 3, 2013 6:42:52 PM GMT+01:00 >> To: Amber ML <amber-lang(a)googlegroups.com> >> >> Hi guys, >> >> amber has moved to https://github.com/amber-smalltalk/amber >> Update your git repo ;) >> >> Cheers, >> Nico > > -- > Nicolas Petton > http://www.nicolas-petton.fr > >

March 3, 2013