subject:"\[Pharo\-dev\] TxText new version 0.8"


Am 23.05.2013 um 10:19 schrieb Sven Van Caekenberghe :

> 
> On 23 May 2013, at 10:12, Norbert Hartl  wrote:
> 
>> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :
>> 
>>> 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  wrote:
>>> 
 On 2013-05-23, at 09:35, Norbert Hartl  wrote:
 
> Am 23.05.2013 um 09:18 schrieb Camillo Bruni :
> 
> 
 technically yes, but you do not need many things to run the code:
 - class comments
 - method comments
 - any documentation in general
 
>>> 
>>> And I don't have it at production because I don't have changes file 
>>> here.
>>> 
>>> 
 yet you load them. so I wonder if it makes sense to even load tests
 separately?
 
>>> 
>>> It make sense when you try to reduce production image size. And loading
>>> only required packages (without tests) works well. Why change it?
>> 
>> I know that this scheme is in use, but why? why do I have to reduce the 
>> size
>> of a production image? from how many to many megabytes? It might make 
>> sense
>> for moose, but none of the other projects. Do you really care if the 
>> image is
>> 35 instead of 25MB? To me this argument sounds invalid :/
>> 
> 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

Re: [Pharo-dev] TxText new version 0.8

2013-05-23 Thread Denis Kudriashov

2013/5/23 Denis Kudriashov 

> I deploy without tests. But I dont unload it. I just have configuration to
> load only code without tests.


And I have prepared clean (ready to deploy) image to load this configuration

Re: [Pharo-dev] TxText new version 0.8


Am 23.05.2013 um 10:16 schrieb Camillo Bruni :

> 
> On 2013-05-23, at 10:12, Norbert Hartl  wrote:
> 
>> 
>> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :
>> 
>>> 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

Re: [Pharo-dev] TxText new version 0.8

2013-05-23 Thread Denis Kudriashov

2013/5/23 Camillo Bruni 

>
> On 2013-05-23, at 10:12, Norbert Hartl  wrote:
>
> >
> > Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :
> >
> >> 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

Re: [Pharo-dev] TxText new version 0.8

2013-05-23 Thread Sven Van Caekenberghe


On 23 May 2013, at 10:12, Norbert Hartl  wrote:

> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :
> 
>> 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  wrote:
>> 
>>> On 2013-05-23, at 09:35, Norbert Hartl  wrote:
>>> 
 Am 23.05.2013 um 09:18 schrieb Camillo Bruni :
 
 
>>> technically yes, but you do not need many things to run the code:
>>> - class comments
>>> - method comments
>>> - any documentation in general
>>> 
>> 
>> And I don't have it at production because I don't have changes file here.
>> 
>> 
>>> yet you load them. so I wonder if it makes sense to even load tests
>>> separately?
>>> 
>> 
>> It make sense when you try to reduce production image size. And loading
>> only required packages (without tests) works well. Why change it?
> 
> I know that this scheme is in use, but why? why do I have to reduce the 
> size
> of a production image? from how many to many megabytes? It might make 
> sense
> for moose, but none of the other projects. Do you really care if the 
> image is
> 35 instead of 25MB? To me this argument sounds invalid :/
> 
 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
>> 
>> 
>> 
>> 
>> 
> 
>

Re: [Pharo-dev] TxText new version 0.8


On 2013-05-23, at 10:12, Norbert Hartl  wrote:

> 
> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :
> 
>> 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).

Re: [Pharo-dev] TxText new version 0.8


Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe :

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

Re: [Pharo-dev] TxText new version 0.8


Am 23.05.2013 um 09:43 schrieb Camillo Bruni :

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

Re: [Pharo-dev] TxText new version 0.8

2013-05-23 Thread Sven Van Caekenberghe

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  wrote:

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

Re: [Pharo-dev] TxText new version 0.8


On 2013-05-23, at 09:35, Norbert Hartl  wrote:

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

Re: [Pharo-dev] TxText new version 0.8


Am 23.05.2013 um 09:22 schrieb Camillo Bruni :

> 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

Re: [Pharo-dev] TxText new version 0.8


Am 23.05.2013 um 09:18 schrieb Camillo Bruni :

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

Re: [Pharo-dev] TxText new version 0.8

2013-05-23 Thread Tudor Girba

Not even for Moose it makes sense to deploy without tests :)

Doru


On Thu, May 23, 2013 at 9:18 AM, Camillo Bruni 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"

Re: [Pharo-dev] TxText new version 0.8

>>> 
>> 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 :/

Re: [Pharo-dev] TxText new version 0.8

>>> 
>> 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 :/

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Norbert Hartl


Am 23.05.2013 um 02:35 schrieb Igor Stasenko :

> 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

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Tudor Girba

Yes, I think this is good at this point.

When the mapping will disappear, things will become simpler.

Doru


On Thu, May 23, 2013 at 8:11 AM, Denis Kudriashov wrote:

> 2013/5/22 Tudor Girba 
>
>> 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"

Re: [Pharo-dev] TxText new version 0.8

2013/5/22 Tudor Girba 

> 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

Re: [Pharo-dev] TxText new version 0.8

2013/5/23 Igor Stasenko 

> 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

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread stephane ducasse

>> 
>> 
> i stand corrected.. actually i meant following composition:
> 
> ProjectName-Core
> ProjectName-Extras
> ProjectName-Tests

Yes something simple!!

> 
> no 3-4 levels of tick-tacks (but i love to use subcategories inside a
> package, i.e.

Re: [Pharo-dev] TxText new version 0.8

On 23 May 2013 02:38, Igor Stasenko  wrote:
> On 22 May 2013 22:16, Camillo Bruni  wrote:
>>
>> On 2013-05-22, at 22:11, Denis Kudriashov  wrote:
>>
>>> 2013/5/22 Camillo Bruni 
>>>

 On 2013-05-22, at 21:04, Tudor Girba  wrote:

> Hi,
>
> On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
>
>> On 22 May 2013 10:38, Stéphane Ducasse 
 wrote:
>>> I would use
>>>
>>> TextModelCore
>>> TextModelExtensions
>>>
>>> TextModelCore-Tests
>>>
>>> No extra dash in the middle.
>>
>> no :)
>>
>> 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.

Re: [Pharo-dev] TxText new version 0.8

On 22 May 2013 22:16, Camillo Bruni  wrote:
>
> On 2013-05-22, at 22:11, Denis Kudriashov  wrote:
>
>> 2013/5/22 Camillo Bruni 
>>
>>>
>>> On 2013-05-22, at 21:04, Tudor Girba  wrote:
>>>
 Hi,

 On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:

> On 22 May 2013 10:38, Stéphane Ducasse 
>>> wrote:
>> I would use
>>
>> TextModelCore
>> TextModelExtensions
>>
>> TextModelCore-Tests
>>
>> No extra dash in the middle.
>
> no :)
>
> 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.

Re: [Pharo-dev] TxText new version 0.8

On 22 May 2013 21:04, Tudor Girba  wrote:
> Hi,
>
> On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
>
>> On 22 May 2013 10:38, Stéphane Ducasse  wrote:
>>> I would use
>>>
>>> TextModelCore
>>> TextModelExtensions
>>>
>>> TextModelCore-Tests
>>>
>>> No extra dash in the middle.
>>
>> no :)
>>
>> 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  wrote:
>>>
>>> 2013/5/21 stephane ducasse 


 On May 21, 2013, at 9:00 AM, Denis Kudriashov 
 wrote:

 2013/5/20 stephane ducasse 
>
>
> 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.

Re: [Pharo-dev] TxText new version 0.8

2013/5/23 Camillo Bruni 

>
> On 2013-05-22, at 22:11, Denis Kudriashov  wrote:
>
> > 2013/5/22 Camillo Bruni 
> >
> >>
> >> On 2013-05-22, at 21:04, Tudor Girba  wrote:
> >>
> >>> Hi,
> >>>
> >>> On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
> >>>
>  On 22 May 2013 10:38, Stéphane Ducasse 
> >> wrote:
> > I would use
> >
> > TextModelCore
> > TextModelExtensions
> >
> > TextModelCore-Tests
> >
> > No extra dash in the middle.
> 
>  no :)
> 
>  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?

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Camillo Bruni


On 2013-05-22, at 22:11, Denis Kudriashov  wrote:

> 2013/5/22 Camillo Bruni 
> 
>> 
>> On 2013-05-22, at 21:04, Tudor Girba  wrote:
>> 
>>> Hi,
>>> 
>>> On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
>>> 
 On 22 May 2013 10:38, Stéphane Ducasse 
>> wrote:
> I would use
> 
> TextModelCore
> TextModelExtensions
> 
> TextModelCore-Tests
> 
> No extra dash in the middle.
 
 no :)
 
 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?

Re: [Pharo-dev] TxText new version 0.8

2013/5/22 Camillo Bruni 

>
> On 2013-05-22, at 21:04, Tudor Girba  wrote:
>
> > Hi,
> >
> > On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
> >
> >> On 22 May 2013 10:38, Stéphane Ducasse 
> wrote:
> >>> I would use
> >>>
> >>> TextModelCore
> >>> TextModelExtensions
> >>>
> >>> TextModelCore-Tests
> >>>
> >>> No extra dash in the middle.
> >>
> >> no :)
> >>
> >> 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.

Re: [Pharo-dev] TxText new version 0.8

2013/5/22 Igor Stasenko 

> On 22 May 2013 10:38, Stéphane Ducasse  wrote:
> > I would use
> >
> > TextModelCore
> > TextModelExtensions
> >
> > TextModelCore-Tests
> >
> > No extra dash in the middle.
>
> no :)
>
> 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 
> wrote:
> >
> > 2013/5/21 stephane ducasse 
> >>
> >>
> >> On May 21, 2013, at 9:00 AM, Denis Kudriashov 
> >> wrote:
> >>
> >> 2013/5/20 stephane ducasse 
> >>>
> >>>
> >>> 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.
>
>

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Camillo Bruni


On 2013-05-22, at 21:04, Tudor Girba  wrote:

> Hi,
> 
> On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:
> 
>> On 22 May 2013 10:38, Stéphane Ducasse  wrote:
>>> I would use
>>> 
>>> TextModelCore
>>> TextModelExtensions
>>> 
>>> TextModelCore-Tests
>>> 
>>> No extra dash in the middle.
>> 
>> no :)
>> 
>> 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...

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Tudor Girba

Hi,

On May 22, 2013, at 5:33 PM, Igor Stasenko  wrote:

> On 22 May 2013 10:38, Stéphane Ducasse  wrote:
>> I would use
>> 
>> TextModelCore
>> TextModelExtensions
>> 
>> TextModelCore-Tests
>> 
>> No extra dash in the middle.
> 
> no :)
> 
> 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  wrote:
>> 
>> 2013/5/21 stephane ducasse 
>>> 
>>> 
>>> On May 21, 2013, at 9:00 AM, Denis Kudriashov 
>>> wrote:
>>> 
>>> 2013/5/20 stephane ducasse 
 
 
 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."

Re: [Pharo-dev] TxText new version 0.8

On 22 May 2013 10:38, Stéphane Ducasse  wrote:
> I would use
>
> TextModelCore
> TextModelExtensions
>
> TextModelCore-Tests
>
> No extra dash in the middle.

no :)

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  wrote:
>
> 2013/5/21 stephane ducasse 
>>
>>
>> On May 21, 2013, at 9:00 AM, Denis Kudriashov 
>> wrote:
>>
>> 2013/5/20 stephane ducasse 
>>>
>>>
>>> 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.

Re: [Pharo-dev] TxText new version 0.8

2013-05-22 Thread Stéphane Ducasse

I would use

TextModelCore
TextModelExtensions

TextModelCore-Tests

No extra dash in the middle. 
Stef

On May 21, 2013, at 10:24 PM, Denis Kudriashov  wrote:

> 2013/5/21 stephane ducasse 
> 
> On May 21, 2013, at 9:00 AM, Denis Kudriashov  wrote:
> 
>> 2013/5/20 stephane ducasse 
>> 
>>> 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
> 
> 
> 
> 
>

Re: [Pharo-dev] TxText new version 0.8

2013-05-21 Thread Benjamin

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  wrote:

> 2013/5/21 stephane ducasse 
> 
> On May 21, 2013, at 9:00 AM, Denis Kudriashov  wrote:
> 
>> 2013/5/20 stephane ducasse 
>> 
>>> 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
> 
> 
> 
> 
>

Re: [Pharo-dev] TxText new version 0.8

2013/5/21 stephane ducasse 

>
> On May 21, 2013, at 9:00 AM, Denis Kudriashov 
> wrote:
>
> 2013/5/20 stephane ducasse 
>
>>
>> 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
>
>
>
>
>

Re: [Pharo-dev] TxText new version 0.8

2013/5/21 

> 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 :))

Re: [Pharo-dev] TxText new version 0.8

Hi

2013/5/21 p...@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.duca...@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.
>>>
>>>
>>
>>
>

Re: [Pharo-dev] TxText new version 0.8

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 

> **
> Denis Kudriashov wrote:
>
> 2013/5/20 Igor Stasenko  
>
>On 19 May 2013 22:01, Denis Kudriashov  
>  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/69ecc655bb11d18968e829fbbd/content.htm
> [2]
> http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com.ibm.help.symphony12.doc/text/common/02/2004.html
>
>  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
>
>

Re: [Pharo-dev] TxText new version 0.8

2013-05-21 Thread btc

Denis Kudriashov wrote:

2013/5/20 Igor Stasenko

On 19 May 2013 22:01, Denis Kudriashov 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/69ecc655bb11d18968e829fbbd/content.htm
[2]
http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com.ibm.help.symphony12.doc/text/common/02/2004.html

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

Re: [Pharo-dev] TxText new version 0.8

2013/5/20 Igor Stasenko 

> also, going ahead.. how easy/hard would be to implement a password input
> field,
> when model contains what user types, but display all *** chars?
>

I forgot to implement it :))
It is easy. I will add it at next version.

Re: [Pharo-dev] TxText new version 0.8

2013-05-21 Thread p...@highoctane.be

Why not TxBaseEditDecorator ?


On Tue, May 21, 2013 at 9:23 AM, stephane ducasse
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.
>>
>>
>
>

Re: [Pharo-dev] TxText new version 0.8

2013-05-21 Thread stephane ducasse

> 
> 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.
> 
>

Re: [Pharo-dev] TxText new version 0.8

2013-05-21 Thread stephane ducasse

On May 21, 2013, at 9:00 AM, Denis Kudriashov  wrote:

> 2013/5/20 stephane ducasse 
> 
>> 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

Re: [Pharo-dev] TxText new version 0.8