TxText new version 0.8
Hello. New TxText version 0.8 is ready: - editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor - edit decorators implemented: - TxNoneEditDecorator- basic editing - TxMaskedEditDecorator- input masked values like phone numbers - TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. - TxSmartCharsEditDecorator- input smart characters like ()[]{} - TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'. According methods were added to TxTextMorph: - #editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) - #inputContents - returns "native" value (undecorated). - #displayedContents - returns raw text model asString See new examples on TxTextMorph class side. Best regards, Denis
On 19 May 2013 22:01, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor - edit decorators implemented:
TxNoneEditDecorator- basic editing then maybe it should be named as basiceditdecorator?
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e. Masked-SimgleLine so i could have a single-line editor for entering only a phone number? also, going ahead.. how easy/hard would be to implement a password input field, when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards, Denis
-- Best regards, Igor Stasenko.
Hi. Sorry for late response. I have not internet yesterday. 2013/5/20 Igor Stasenko <siguctua@gmail.com>
On 19 May 2013 22:01, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor - edit decorators implemented:
TxNoneEditDecorator- basic editing then maybe it should be named as basiceditdecorator?
I named it "none" edit decorator because It actually not performs any decoration around basic editing operations. TxNoneEditDecorator just performs it. Concrete edit decorator can execute specific action on text to perform requested edit operation. There are three edit operations: #insertCharacters:at:, #removeNextCharacterAt:, #removePreviousCharacterAt:. They take aTextSelection as "at" argument. For example TxInsertModeEditDecorator extends text selection before characters insertion: TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString size] aTextSelection replaceWith: aString
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
I choose this name because on Windows you have "insert key" to activate such mode in many text editors.
TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine so i could have a single-line editor for entering only a phone number?
Now with mask decorator you have single line text field. Multilined mask is not supported (I dont try it actually). When you insert miltiline text to masked field only first line will be used. I make such restriction to simplify implementation. Actually I never see multilined masked field. Decorators can not be wrapped in general way. Maybe some of it. But there is no cases in current decorators. Main reason: most of decorators change cursor position with very specific way. And wrapping decorators will lead to unpredictable and useless results. Your example Masked-SingleLine (if mask can be multilined) is not about wrapping decorators. It is about input "filtering" . It is my next task. I want put at text morph specification of correct input. So you can forbid "cr" characters, can allow only numbers and etc. And at same time decorators can restrict input by its implementation requirements which happens with masked decorator. But edit decorators and "filters" are different concepts (I not choose name for "filters" yet). TxSingleLineEditDecorator implements general way to edit single line text with simple decoration format. Maybe it should be renamed. TxSingleLineEditDecorator transforms full text by decoration format after any edit operation. And it saves logical cursor position after transformation. Look at methods of TxSmartNumbersDecorationFormat as example. I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one? Best regards, Denis
also, going ahead.. how easy/hard would be to implement a password input field, when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards, Denis
-- Best regards, Igor Stasenko.
I named it "none" edit decorator because It actually not performs any decoration around basic editing operations. TxNoneEditDecorator just performs it.
Yes this is what TxNullEditDecorator would convey. I do not see why TxNoneEditDecorator would mean that and not the TxNullEditDecorator.
Concrete edit decorator can execute specific action on text to perform requested edit operation. There are three edit operations: #insertCharacters:at:, #removeNextCharacterAt:, #removePreviousCharacterAt:. They take aTextSelection as "at" argument. For example TxInsertModeEditDecorator extends text selection before characters insertion:
TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString size] aTextSelection replaceWith: aString
Yes my point is still valid. the NullDecorator does not decorate.
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
I choose this name because on Windows you have "insert key" to activate such mode in many text editors.
I think that igor suggestion is better. because replace is replace :) and insert is insert.
TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine so i could have a single-line editor for entering only a phone number?
Now with mask decorator you have single line text field. Multilined mask is not supported (I dont try it actually). When you insert miltiline text to masked field only first line will be used. I make such restriction to simplify implementation. Actually I never see multilined masked field.
Decorators can not be wrapped in general way. Maybe some of it. But there is no cases in current decorators. Main reason: most of decorators change cursor position with very specific way. And wrapping decorators will lead to unpredictable and useless results.
Your example Masked-SingleLine (if mask can be multilined) is not about wrapping decorators. It is about input "filtering" . It is my next task. I want put at text morph specification of correct input. So you can forbid "cr" characters, can allow only numbers and etc. And at same time decorators can restrict input by its implementation requirements which happens with masked decorator. But edit decorators and "filters" are different concepts (I not choose name for "filters" yet).
TxSingleLineEditDecorator implements general way to edit single line text with simple decoration format. Maybe it should be renamed. TxSingleLineEditDecorator transforms full text by decoration format after any edit operation. And it saves logical cursor position after transformation. Look at methods of TxSmartNumbersDecorationFormat as example.
I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one?
Best regards, Denis
also, going ahead.. how easy/hard would be to implement a password input field, when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards, Denis
-- Best regards, Igor Stasenko.
Why not TxBaseEditDecorator ? On Tue, May 21, 2013 at 9:23 AM, stephane ducasse <stephane.ducasse@free.fr>wrote:
I named it "none" edit decorator because It actually not performs any decoration around basic editing operations. TxNoneEditDecorator just performs it.
Yes this is what TxNullEditDecorator would convey. I do not see why TxNoneEditDecorator would mean that and not the TxNullEditDecorator.
Concrete edit decorator can execute specific action on text to perform requested edit operation. There are three edit operations: #insertCharacters:at:, #removeNextCharacterAt:, #removePreviousCharacterAt:. They take aTextSelection as "at" argument. For example TxInsertModeEditDecorator extends text selection before characters insertion:
TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString size] aTextSelection replaceWith: aString
Yes my point is still valid. the NullDecorator does not decorate.
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
I choose this name because on Windows you have "insert key" to activate such mode in many text editors.
I think that igor suggestion is better. because replace is replace :) and insert is insert.
TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine so i could have a single-line editor for entering only a phone number?
Now with mask decorator you have single line text field. Multilined mask is not supported (I dont try it actually). When you insert miltiline text to masked field only first line will be used. I make such restriction to simplify implementation. Actually I never see multilined masked field.
Decorators can not be wrapped in general way. Maybe some of it. But there is no cases in current decorators. Main reason: most of decorators change cursor position with very specific way. And wrapping decorators will lead to unpredictable and useless results.
Your example Masked-SingleLine (if mask can be multilined) is not about wrapping decorators. It is about input "filtering" . It is my next task. I want put at text morph specification of correct input. So you can forbid "cr" characters, can allow only numbers and etc. And at same time decorators can restrict input by its implementation requirements which happens with masked decorator. But edit decorators and "filters" are different concepts (I not choose name for "filters" yet).
TxSingleLineEditDecorator implements general way to edit single line text with simple decoration format. Maybe it should be renamed. TxSingleLineEditDecorator transforms full text by decoration format after any edit operation. And it saves logical cursor position after transformation. Look at methods of TxSmartNumbersDecorationFormat as example.
I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one?
Best regards, Denis
also, going ahead.. how easy/hard would be to implement a password input field, when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards, Denis
-- Best regards, Igor Stasenko.
Hi 2013/5/21 phil@highoctane.be <phil@highoctane.be>
Why not TxBaseEditDecorator ?
For me null (or non) prefix better fit general idea about edit decorators. Edit decorators executes specific actions on text to perform basic edit operations. TxNullEditDecorator is doing nothing except basic edit operations. Also before I introduce edit decorator object TxEditor performs edit operations by itself. So TxNullEditDecorator works as null pattern here.
On Tue, May 21, 2013 at 9:23 AM, stephane ducasse < stephane.ducasse@free.fr> wrote:
I named it "none" edit decorator because It actually not performs any decoration around basic editing operations. TxNoneEditDecorator just performs it.
Yes this is what TxNullEditDecorator would convey. I do not see why TxNoneEditDecorator would mean that and not the TxNullEditDecorator.
Concrete edit decorator can execute specific action on text to perform requested edit operation. There are three edit operations: #insertCharacters:at:, #removeNextCharacterAt:, #removePreviousCharacterAt:. They take aTextSelection as "at" argument. For example TxInsertModeEditDecorator extends text selection before characters insertion:
TxInsertModeEditDecorato>>insertCharacters: aString at: aTextSelection aTextSelection isEmpty ifTrue: [aTextSelection end moveRight: aString size] aTextSelection replaceWith: aString
Yes my point is still valid. the NullDecorator does not decorate.
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
I choose this name because on Windows you have "insert key" to activate such mode in many text editors.
I think that igor suggestion is better. because replace is replace :) and insert is insert.
TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'.
btw, can you wrap decorators on top of each other i.e.
Masked-SimgleLine so i could have a single-line editor for entering only a phone number?
Now with mask decorator you have single line text field. Multilined mask is not supported (I dont try it actually). When you insert miltiline text to masked field only first line will be used. I make such restriction to simplify implementation. Actually I never see multilined masked field.
Decorators can not be wrapped in general way. Maybe some of it. But there is no cases in current decorators. Main reason: most of decorators change cursor position with very specific way. And wrapping decorators will lead to unpredictable and useless results.
Your example Masked-SingleLine (if mask can be multilined) is not about wrapping decorators. It is about input "filtering" . It is my next task. I want put at text morph specification of correct input. So you can forbid "cr" characters, can allow only numbers and etc. And at same time decorators can restrict input by its implementation requirements which happens with masked decorator. But edit decorators and "filters" are different concepts (I not choose name for "filters" yet).
TxSingleLineEditDecorator implements general way to edit single line text with simple decoration format. Maybe it should be renamed. TxSingleLineEditDecorator transforms full text by decoration format after any edit operation. And it saves logical cursor position after transformation. Look at methods of TxSmartNumbersDecorationFormat as example.
I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one?
Best regards, Denis
also, going ahead.. how easy/hard would be to implement a password input field, when model contains what user types, but display all *** chars?
According methods were added to TxTextMorph:
#editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString
See new examples on TxTextMorph class side.
Best regards, Denis
-- Best regards, Igor Stasenko.
I make changes which you suggest. So new version 0.9 published Renames: TxNoneEditDecorator->TxNullEditDecorator TxInsertModeEditDecorator->TxOverwriteModeEditDecorator And new TxSecretEditDecorator for password like fields. Best regards, Denis 2013/5/21 <btc@openinworld.com>
** Denis Kudriashov wrote:
2013/5/20 Igor Stasenko <siguctua@gmail.com> <siguctua@gmail.com>
On 19 May 2013 22:01, Denis Kudriashov <dionisiydk@gmail.com> <dionisiydk@gmail.com> wrote:
TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one.
insert mode is actually opposite - inserts when you type. replace mode is replaces when you type.
I choose this name because on Windows you have "insert key" to activate such mode in many text editors.
I agree with Igor on this one. The "insert key" toggles between Insert Mode and Overwrite Mode - but the "key" is not the "mode" - it only triggers the transition between the two modes. The perception that the "insert key" is more strongly related Overwrite Mode is an illusion since most text editors are in Insert Mode by default. Per your description TxOverwritetModeEditDecorator would be more correct.
Supporting info... [1] http://help.sap.com/saphelp_45b/helpdata/en/73/69ecc655bb11d189680000e829fbb... [2] http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com....
I will be happy if you introduce more clever names. Good names is difficult task for single brain. Especially if you are not native english speaker. But many of you already suggest different names. How we can agree on any one?
Sometimes only by thrashing it around to wear off the rough edges.
btw, I really enjoy reading about your advances with TxText. From a distance, it just seems like its going to make interesting things easier to do in the future.
cheers -ben
2013/5/21 <btc@openinworld.com>
I agree with Igor on this one. The "insert key" toggles between Insert Mode and Overwrite Mode - but the "key" is not the "mode" - it only triggers the transition between the two modes. The perception that the "insert key" is more strongly related Overwrite Mode is an illusion since most text editors are in Insert Mode by default.
Interesting. But I am too young to know about it :))
On May 19, 2013, at 10:01 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor may be you should call the second package TxTextEditor-Tests
- edit decorators implemented: TxNoneEditDecorator- basic editing TxNullEditDecorator ?
TxMaskedEditDecorator- input masked values like phone numbers TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. TxSmartCharsEditDecorator- input smart characters like ()[]{} TxSingleLineEditDecorator - general way to decorate editing with simple decoration format. TxSmartNumbersDecorationFormat is example. It transform text with number format like: '10 000 000' or '10'000'000'. According methods were added to TxTextMorph: #editDecorator: - set specific edit decorator (TxNoneEditDecorator by default) #inputContents - returns "native" value (undecorated). #displayedContents - returns raw text model asString See new examples on TxTextMorph class side.
Best regards, Denis
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0 Stef
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
Use Nautilus to generate them, so you will not have to think about it :) (and you can blame someone else in case of bad naming ^^) Ben On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
I would use TextModelCore TextModelExtensions TextModelCore-Tests No extra dash in the middle. Stef On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :) But for tests, i +1, the names are not very good. For package: Package-Name-Tick-Tack tests should be in: Package-Name-Tick-Tack-Tests This convention used everywhere in pharo.
Stef
On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
-- Best regards, Igor Stasenko.
Hi, On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :). If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping. 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 But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package. Cheers, Doru
Stef
On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com "Value is always contextual."
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you. I can only speak for smaller projects, but I really do not sea a reason to not load tests...
2013/5/22 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you.
I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Because tests not needed to run your application.
On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/22 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you.
I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Because tests not needed to run your application.
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?
2013/5/23 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/22 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we
also
document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you.
I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Because tests not needed to run your application.
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?
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 :/
Not even for Moose it makes sense to deploy without tests :) Doru On Thu, May 23, 2013 at 9:18 AM, Camillo Bruni <camillobruni@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"
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason. Norbert
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored) which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?. So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
Hmm, there are different views possible on this. We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open. I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable. I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO. On 23 May 2013, at 09:43, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored)
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit. Norbert
On 23 May 2013, at 09:43, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored)
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 2013-05-23, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
so that means nobody *actually* loads code without tests? :D (evil laugh).
2013/5/23 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-23, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really
small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
so that means nobody *actually* loads code without tests? :D (evil laugh).
I deploy without tests. But I dont unload it. I just have configuration to load only code without tests. And I think guys who try mobile development with Pharo not deploy application with tests to apple store
Am 23.05.2013 um 10:16 schrieb Camillo Bruni <camillobruni@gmail.com>:
On 2013-05-23, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
so that means nobody *actually* loads code without tests? :D (evil laugh).
What do you mean? Norbert
On 23 May 2013 10:16, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
so that means nobody *actually* loads code without tests? :D (evil laugh).
But i do not argue about what is the be best deployment scenario. I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him. Technocracy is not better than any other totalitarian forms of government. Because it ignores the needs of individual (for the good of ephemeral "majority", of course). -- Best regards, Igor Stasenko.
so that means nobody *actually* loads code without tests? :D (evil laugh).
But i do not argue about what is the be best deployment scenario.
I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him.
it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things. It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever. It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities. How does an ideal project look for you?
On 25 May 2013 11:44, Camillo Bruni <camillobruni@gmail.com> wrote:
so that means nobody *actually* loads code without tests? :D (evil laugh).
But i do not argue about what is the be best deployment scenario.
I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him.
it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs
you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things.
It heavily depends what kind of project is it. For small/tiny projects following all steps/recommendations may be not necessary and actually cumbersome. Consider pilot projects as well. For frameworks, mid to big projects or any project with intent to be used by others, of course, building up an ecosystem (docs, tests, examples etc) is necessary.
It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever.
It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities.
How does an ideal project look for you?
Ideal project has tests, docs, examples books, flyers with ad, sales managers and profit :) But things are never ideal, and you always looking for a sweet spot between: - time - resources - features and in situations when you lack of time & resources (usual for open-source projects), you have to pick what features to implement first, and which have to wait. You simply cannot afford to do everything in time, and hence you need to prioritize things. Writing documentation before 1st line of code, or otherwise? But this is orthogonal to my point. I see little point in keeping tests in deployed image. It is good to have tests, and run them regularly while developing, using SCM, continuous integration, writing docs, examples etc etc.. Consider deploying database application. To run all the tests for it may take days, often will require setting up special testing environment (outside of image) and many other things.. That means , even if you will keep those tests in image, you will be never able to run them in deployed environment, simply because this will mean: stopping all services, changing configs, firewalls.. etc.. So, do you really think that in such scenario (which actually typical for most server-based applications), having tests in deployed image makes any difference? -- Best regards, Igor Stasenko.
Am 25.05.2013 um 13:22 schrieb Igor Stasenko <siguctua@gmail.com>:
On 25 May 2013 11:44, Camillo Bruni <camillobruni@gmail.com> wrote:
so that means nobody *actually* loads code without tests? :D (evil laugh).
But i do not argue about what is the be best deployment scenario.
I am arguing about leaving developers to choose: - if (s)he wants to deploy with tests or not, it should be up to him.
it's also up to him to - write configurations - write tests - write documentation and examples - commit code to a repository - create jenkins jobs
you see, there are many things that one can avoid to do in a project, yet it is a common standard to do ALL of these tasks for a project. Yet you have your liberty to ignore these things.
It heavily depends what kind of project is it. For small/tiny projects following all steps/recommendations may be not necessary and actually cumbersome. Consider pilot projects as well. For frameworks, mid to big projects or any project with intent to be used by others, of course, building up an ecosystem (docs, tests, examples etc) is necessary.
It is about the good path and how you push people towards it. If you do not provide the tools for it we will be stuck in stone age forever.
It has never been the liberty of ignoring things that brought a project forward, but the tools that open new possibilities.
How does an ideal project look for you?
Ideal project has tests, docs, examples books, flyers with ad, sales managers and profit :) But things are never ideal, and you always looking for a sweet spot between: - time - resources - features
and in situations when you lack of time & resources (usual for open-source projects), you have to pick what features to implement first, and which have to wait. You simply cannot afford to do everything in time, and hence you need to prioritize things. Writing documentation before 1st line of code, or otherwise?
But this is orthogonal to my point. I see little point in keeping tests in deployed image. It is good to have tests, and run them regularly while developing, using SCM, continuous integration, writing docs, examples etc etc..
Consider deploying database application. To run all the tests for it may take days, often will require setting up special testing environment (outside of image) and many other things.. That means , even if you will keep those tests in image, you will be never able to run them in deployed environment, simply because this will mean: stopping all services, changing configs, firewalls.. etc.. So, do you really think that in such scenario (which actually typical for most server-based applications), having tests in deployed image makes any difference?
Yes, yes and yes. I agree with everything you said. Norbert
On 23 May 2013, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
That is a cool trick ! So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-)
Norbert
On 23 May 2013, at 09:43, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored)
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Am 23.05.2013 um 10:19 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
On 23 May 2013, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
That is a cool trick !
Yep and it works good. Although being a little bit stupid one of my favorite tests is still testNoDebuggers self assert: (SystemWindow allSubInstances select: [:each| each model isKindOf: Debugger ]) size = 0 So whenever a debugger window opens, monit sends an email telling me :)
So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-)
Yes, that is a good idea. You just need to overwrite some things in Zinc and package your stuff in an extra package so I can unload it :P Norbert
Norbert
On 23 May 2013, at 09:43, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored)
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 23 May 2013, at 10:19, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 23 May 2013, at 10:12, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven@stfx.eu>:
Hmm, there are different views possible on this.
Absolutely!
We should never give up the possibility of building/constructing really small images. There has been massive work done on modularisation, unloading and stripping. Let's keep that option/route open.
That's my only point. Having tests packaged separately just opens the possibility to make things smaller.
I personally doubt how much difference tests actually make compared to other stuff, but that does not mean that they should no longer be unloadable.
agreed.
I stopped trying to minimise production images, because it is not worth the trouble: it is a lot of work, memory is relatively cheap and I need the tools to remain present, just in case I want to debug. Even running tests is a kind of debugging and/or quality control: a way to confirm that the production image is (still) working OK. This is all useful and a small price to pay, IMHO.
That is the funny part in this discussion. I stopped minimizing them as well. On most images I use RFB and like to have the full fledge installation being present. I stopped even to use cleanUpForProduction because it removes SUnit. I hook up SUnit to rest handlers and trigger them from the outside to do runtime sanity checks, e.g. used by monit.
That is a cool trick !
So cool that I want to make that into a general purpose Zn handler (totally optional and on localhost only of course) ;-)
And so I did: --- Name: Zinc-HTTP-SvenVanCaekenberghe.363 Author: SvenVanCaekenberghe Time: 28 May 2013, 10:38:03 am UUID: a1fa8795-eb44-4812-81e7-3da28fa9bda9 Ancestors: Zinc-HTTP-SvenVanCaekenberghe.362 Implemented ZnTestRunnerDelegate (original idea by Norbert Hartl - Thx) Minor optimalization to ZnUtils class>>#nextPutAll:on: --- $ curl http://localhost:1701/sunit/ZnUtilsTests 15 run, 15 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes $ curl http://localhost:1701/sunit/ZnUtilsTests/testBase64 1 run, 1 passes, 0 skipped, 0 expected failures, 0 failures, 0 errors, 0 unexpected passes The above are 200 responses, a failure will be a 500 response. With specifically written tests this could be quite useful for monit checks. Sven PS: The service is off by default, and when on only exposed to localhost, don't change this without thinking about the consequences !
Norbert
On 23 May 2013, at 09:43, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible: - tests - comments (luckily in the changes file...) - source code (luckily in the changes file...) - monticello metadata (which was around 5MB or so, did anybody care?) - font files that linger around (also around 2MB, and also mostly ignored)
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
-- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
Am 23.05.2013 um 09:43 schrieb Camillo Bruni <camillobruni@gmail.com>:
On 2013-05-23, at 09:35, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni@gmail.com>:
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 :/
I can tell from a server deployment perspective. A production image should only contain the source it really needs. Additional not-used code cannot have a benefit but it could cause side effects (breaking things, slowing things down, opening security holes, etcâ¦). So you reduce it to the bare essentials. Having less code also makes an image faster which is not a noticable effect but it is there. Finally if you want to have 48 images (that can be feasible on a 16 core machine) on your machine then it would sum up to 480 MB which is less memory for additional images or OS I/O cache which in turn makes your machine slower. Not carrying about memory at all is a typical view point that the java community developed. But your professional acting should be reasonable. That means for every action should have a reason. At best a good reason. Growing the image by supporting new possibilties and tools is a good reason. Just wasting memory because it is easier to load a huge bunch is IMHO not a good reason.
So I conclude that for a production ready image you want to strip out as much as possible:
If we assume that we have a use case where it is a requirement, yes! I didn't want to tell it is needed for every deployment.
- tests
yes, because tests are not used and tests are code that depends on other modules.
- comments (luckily in the changes fileâ¦)
I didn't know comments can be in-image. But if so I would say: If this can be done in a feasible way and saving memory is king then yes I would do it.
- source code (luckily in the changes fileâ¦)
same as for comments
- monticello metadata (which was around 5MB or so, did anybody care?)
This one thing that is done by "cleanUpForProduction". Btw. cleanUpForProduction is exactly what I mean, a workflow to clean unnecessary stuff.
- font files that linger around (also around 2MB, and also mostly ignored)
Yes, I think cleanUpForProduction does this as well. Being able to disable freetype, unload the freetype stuff and have a small bitmap font that can be used as a replacement is good.
which sort of makes sense, however for that you will need a custom tool, which is orthogonal to being able to load tests in a separate package. And the test only contribute to the static code base, whereas in a live production environment I would expect to have more live objects (I am guessing here)?.
The tool is cleanUpForProduction. I don't know how you define orthogonality and so I don't get the second sentence. What is a static code base in smalltalk? .sources/.changes? Aren't there classes, class initializations, etc. whenever you load additional code? Maybe you can elaborate on that point.
So for a production environment, if you want to get these small MB savings on the image you need a decent script. I would really like to have real numbers on how much the tests contribute to the total size.
If you want to save size it doesn't matter how much it is as long as there is an easy way to save it. But this is not only about size. Code that gets loaded might do things in class initialization that opens a security hole or it might that just the presence of the code makes it more vulnerable. I don't like to discuss security issues here. My statement is that in production every single piece that is not used doesn't bring any benefit but it can waste memory, cpu cycles and open security holes. So what reasons can be there to load that stuff if you easily can avoid it? Norbert
On 22 May 2013 22:16, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/22 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you.
I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Because tests not needed to run your application.
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. 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.. -- Best regards, Igor Stasenko.
On 23 May 2013 02:38, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 22:16, Camillo Bruni <camillobruni@gmail.com> wrote:
On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/22 Camillo Bruni <camillobruni@gmail.com>
On 2013-05-22, at 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
I would love to change that rule. I think Tests have the same value as the code itself. The only reason to not load the code is the load time for the configuration. Which is basically is unimportant if you have a CI server preparing images for you.
I can only speak for smaller projects, but I really do not sea a reason to not load tests...
Because tests not needed to run your application.
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. 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..
.. as for production, i am even more radical: i would leave only bytecode in image. (and some people would even go further and obfuscate class/method names, replacing them with meaningless names). The problem is that we don't have such tools. Probably because we don't need them, because most of our work is open source. But for proprietary, closed-source project i bet this is one of the issues why pointy-hair managers ;) prefer to use other language than smalltalk.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
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 :/
Am 23.05.2013 um 09:22 schrieb Camillo Bruni <camillobruni@gmail.com>:
My point is the following: Tests ARE functional documentation and thus should be shipped under any circumstance with the rest of the code.
Documentation is completely useless in a deployed runtime environment. And while I didn't package my tests and I use SUnit, Mocketry, Phexample, etc in my tests I have to load all of these in every image I deploy. I think there are more views on this field and I can't see a reason to enforce only one! Norbert
On 22 May 2013 21:04, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
This convention used everywhere in pharo.
Please do not do that :).
If you do that, publishing Package-Name-Tick-Tack will publish the code from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely implicit one-to-many mapping.
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
i stand corrected.. actually i meant following composition: ProjectName-Core ProjectName-Extras ProjectName-Tests no 3-4 levels of tick-tacks (but i love to use subcategories inside a package, i.e. ProjectName-Core-Foo , ProjectName-Core-Bar... etc
But, the rule I apply more recently for code is to use - only for categories, and camel case for the Monticello packages. Like this we also document what is the unit of publishing, thus when you look into the code browser we also know what is mapped on a Monticello package.
Cheers, Doru
Stef
On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
-- Best regards, Igor Stasenko.
-- www.tudorgirba.com
"Value is always contextual."
-- Best regards, Igor Stasenko.
2013/5/23 Igor Stasenko <siguctua@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
Am 23.05.2013 um 02:35 schrieb Igor Stasenko <siguctua@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
I understand your point. Now I would like a tool to help and that the tool or rule encode decision. We are all overloaded with information that we should keep in mind. Tools are done for that to help us getting free to think on the important point. Stef On May 23, 2013, at 8:35 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 23.05.2013 um 02:35 schrieb Igor Stasenko <siguctua@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
2013/5/22 Tudor Girba <tudor@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
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@gmail.com>wrote:
2013/5/22 Tudor Girba <tudor@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"
2013/5/22 Igor Stasenko <siguctua@gmail.com>
On 22 May 2013 10:38, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
I would use
TextModelCore TextModelExtensions
TextModelCore-Tests
No extra dash in the middle.
nooooo :)
But for tests, i +1, the names are not very good. For package:
Package-Name-Tick-Tack
tests should be in:
Package-Name-Tick-Tack-Tests
How it works? Monticello include all subcategories of package. And with this example tests will be part of package Package-Name-Tick-Tack. I test similar example at Pharo 2.0
This convention used everywhere in pharo.
Stef
On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/21 stephane ducasse <stephane.ducasse@free.fr>
On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
2013/5/20 stephane ducasse <stephane.ducasse@free.fr>
Hello.
New TxText version 0.8 is ready:
- editor stuff extracted to separate packages TxText-Editor and TxTextTests-Editor
may be you should call the second package TxTextEditor-Tests
I just follow convention of other TxText packages: TxText-Model -> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. Some times ago I suggest such repackaging and nobody was against it
Still I think that the packages names are not good. I do not hitnk that having tests mixed with the package name is a good approach and we should clean all of them for 3.0
So what the correct way (Pharo way) to name test packages? For example I have 'MyPackage-SubCat1-SubCat2'. What name for test package should be?
Stef
-- Best regards, Igor Stasenko.
participants (11)
-
Benjamin -
btc＠openinworld.com -
Camillo Bruni -
Denis Kudriashov -
Igor Stasenko -
Norbert Hartl -
phil＠highoctane.be -
stephane ducasse -
Stéphane Ducasse -
Sven Van Caekenberghe -
Tudor Girba