- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TxText new version 0.8

by Tudor Girba

Not even for Moose it makes sense to deploy without tests :) Doru On Thu, May 23, 2013 at 9:18 AM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > >>> > >> technically yes, but you do not need many things to run the code: > >> - class comments > >> - method comments > >> - any documentation in general > >> > > > > And I don't have it at production because I don't have changes file here. > > > > > >> yet you load them. so I wonder if it makes sense to even load tests > >> separately? > >> > > > > It make sense when you try to reduce production image size. And loading > > only required packages (without tests) works well. Why change it? > > I know that this scheme is in use, but why? why do I have to reduce the > size > of a production image? from how many to many megabytes? It might make sense > for moose, but none of the other projects. Do you really care if the image > is > 35 instead of 25MB? To me this argument sounds invalid :/ > > > -- www.tudorgirba.com "Every thing has its own flow"

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

>>> >> technically yes, but you do not need many things to run the code: >> - class comments >> - method comments >> - any documentation in general >> yet you load them. so I wonder if it makes sense to even load tests separately? > > for me there is one big reason to put tests in separate package: modularity. modularity? what does that have to do with tests? Tests are first class participants of software (well some DO NOT WRITE TESTS). So modularity does not count. There are even class tests which map 1 to 1 to existing classes. How does modularity hold up here? My point is the following: Tests ARE functional documentation and thus should be shipped under any circumstance with the rest of the code. > I usually care a little about modularity when writing tests (they can > use anything from anything, > as long as test fulfills its purpose and covers the functionality i need).. > But in regular code i cannot afford that , because then Kernel will > start depending on Morphic etc.. wait what? that's a 2 level contradiction here :/

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

>>> >> technically yes, but you do not need many things to run the code: >> - class comments >> - method comments >> - any documentation in general >> > > And I don't have it at production because I don't have changes file here. > > >> yet you load them. so I wonder if it makes sense to even load tests >> separately? >> > > It make sense when you try to reduce production image size. And loading > only required packages (without tests) works well. Why change it? I know that this scheme is in use, but why? why do I have to reduce the size of a production image? from how many to many megabytes? It might make sense for moose, but none of the other projects. Do you really care if the image is 35 instead of 25MB? To me this argument sounds invalid :/

May 23, 2013

Re: [Pharo-dev] could we rename ensureDeleted into ensureDelete?

by stephane ducasse

> Am 23.05.2013 um 07:43 schrieb stephane ducasse <stephane.ducasse(a)free.fr>: > >> I disagree and this is not coherent with the ensureFile and ensureDirectory >> > What does it mean anyway? File and Directory are things, delete is an action/verb and deleted is a state. To me the only one that makes sense is that you can ensure a state. To me ensureFile sounds odd, too. It should be called ensureFileExists. yes :) > > Norbert >> On May 22, 2013, at 10:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >>> Camillo Bruni-3 wrote >>>> because it is the final state, the file is deleted. >>>> it emerged out of a longer discussion with sean, mariano and me I think >>> >>> Yes, we discussed thoroughly in the ml [1] (you were a part, but it was a >>> while back). The objection, which I came to agree with, was that you're not >>> "ensuring delete" because it may not be deleted (e.g. if it never existed). >>> >>> [1] >>> http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… >>> >>> >>> >>> ----- >>> Cheers, >>> Sean >>> -- >>> View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… >>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>> >> >> >

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 23.05.2013 um 02:35 schrieb Igor Stasenko <siguctua(a)gmail.com>: > ProjectName-Core > ProjectName-Extras > ProjectName-Tests That approach has a limited scope. Because we match by prefix you have to do -Core and not just ProjectName. In a decent amount of projects -Core and -Extras will grow and you will have tests for -Core and -Extras and you don't want to combine them into a single -Tests package. But what do you do? ProjectName-Core-Core ProjectName-Core-Tests ?? Surely not. From this perspective one can look the way seaside does it. It is ProjectName-Core ProjectName-Extras ProjectName-Tests-Core ProjectName-Tests-Extras So there are multiple possibilities how to achieve it. I always start my projects by keeping tests inside the same package as the rest of the code. Well, I have the habit to mostly create a -Core package at the beginning. Later of the module grows I put -Tests in an extra package. And in one big project I did the seaside approach by putting the -Tests after the ProjectName. This way you don't have too much problems until you introduce platform dependent packages. Norbert

May 23, 2013

Re: [Pharo-dev] could we rename ensureDeleted into ensureDelete?

by Norbert Hartl

Am 23.05.2013 um 07:43 schrieb stephane ducasse <stephane.ducasse(a)free.fr>: > I disagree and this is not coherent with the ensureFile and ensureDirectory > What does it mean anyway? File and Directory are things, delete is an action/verb and deleted is a state. To me the only one that makes sense is that you can ensure a state. To me ensureFile sounds odd, too. It should be called ensureFileExists. Norbert > On May 22, 2013, at 10:33 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > >> Camillo Bruni-3 wrote >>> because it is the final state, the file is deleted. >>> it emerged out of a longer discussion with sean, mariano and me I think >> >> Yes, we discussed thoroughly in the ml [1] (you were a part, but it was a >> while back). The objection, which I came to agree with, was that you're not >> "ensuring delete" because it may not be deleted (e.g. if it never existed). >> >> [1] >> http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > >

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Tudor Girba

Yes, I think this is good at this point. When the mapping will disappear, things will become simpler. Doru On Thu, May 23, 2013 at 8:11 AM, Denis Kudriashov <dionisiydk(a)gmail.com>wrote: > 2013/5/22 Tudor Girba <tudor(a)tudorgirba.com> > >> So, the pattern I know of is to put the Tests as a discriminator before >> the variable part of your code. So, something like: >> - BaseName-Core >> - BaseName-Tests-Core >> > > It is exactly my pattern but with dash before Tests word: > -TxText-Model > -TxTextTests-Model > -- www.tudorgirba.com "Every thing has its own flow"

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/22 Tudor Girba <tudor(a)tudorgirba.com> > So, the pattern I know of is to put the Tests as a discriminator before > the variable part of your code. So, something like: > - BaseName-Core > - BaseName-Tests-Core > It is exactly my pattern but with dash before Tests word: -TxText-Model -TxTextTests-Model

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/23 Igor Stasenko <siguctua(a)gmail.com> > i stand corrected.. actually i meant following composition: > > ProjectName-Core > ProjectName-Extras > ProjectName-Tests > And what names should be for packages to split tests of Core and Extras? Because I want to load only ProjectName-Core with tests withour Extras stuff

May 23, 2013

Re: [Pharo-dev] MC Filetree -- missing FiletreeURL ?

by stephane ducasse

> > I would _love_ to be able to use Smalltalk at work. Until it can work > properly with git, and people can use their own text editors (vim, > emacs, sublime), and quite a few other bits and pieces, it's just a > non-starter. it will happen. I'm sure :) > I _like_ Pharo, and I _like_ how it has energy and momentum, and a > much nicer UI than the old Pharo 1.0 UI. I'm honestly quite jealous of > the resources the community wields, not just because of INRIA's and > the Consortium's money, but because there are loads of people actually > around, who are prepared to knuckle down and do the gruntwork needed. > Squeak is now a very small community. I'm rather proud of what we get > done with what little we have. Just so that I understand. What are you trying to achieve? Most of the pharo people are not payed for doing pharo. What we are building (and fighting for) is an ecosystem in which smart guys can also find a job and it is becoming to happen. Mariano is full of work and many others. Sean told me that he got several job offers. Pharo is not the end, it is the start. It is not like we would like it to be but everyday it gets closer to it. Stef

May 23, 2013