- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] TxText new version 0.8

by stephane ducasse

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

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 23.05.2013 um 10:19 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > On 23 May 2013, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > >> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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(a)gmail.com> wrote: >>> >>>> On 2013-05-23, at 09:35, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>>> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni(a)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 >>> >>> >>> >>> >>> >> >> > >

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/23 Denis Kudriashov <dionisiydk(a)gmail.com> > 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

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 23.05.2013 um 10:16 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > > On 2013-05-23, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/23 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-05-23, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Sven Van Caekenberghe

On 23 May 2013, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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(a)gmail.com> wrote: >> >>> On 2013-05-23, at 09:35, Norbert Hartl <norbert(a)hartl.name> wrote: >>> >>>> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni(a)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 >> >> >> >> >> > >

May 23, 2013

Re: [Pharo-dev] Messy Configurations

by roberto.minelli＠usi.ch

+1000 Camillo!! I'd really appreciate a "better" MC configuration mechanism! R On May 22, 2013, at 5:53 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: > I recently spent some time to revise how to write Metacello Configurations. > > Observation: > ============ > - many configurations are quite a mess > - many configurations duplicate code internally > - many configurations have archived development versions > > > For Pharo 3.0 I made a new Configuration template which improves and documents > these observed points in quite some detail. Simply load a new 3.0 image and > create a new configuration from the monticello working copy browser. > > Solution: > ========= > - specify external projects in separate, reusable methods > - only have ONE development version you regularly update > - do not use version numbers for the development version > - only make a version number when you release something stable AKA not #development > - name the baseline after the first version that introduces it > > > > What do you think?

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

On 2013-05-23, at 10:12, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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).

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 23.05.2013 um 09:53 schrieb Sven Van Caekenberghe <sven(a)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(a)gmail.com> wrote: > >> On 2013-05-23, at 09:35, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Am 23.05.2013 um 09:18 schrieb Camillo Bruni <camillobruni(a)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 > > > > >

May 23, 2013

What is a ExclusiveWeakMessageSend?

by StÃ©phane Ducasse

Hi Gary We are working with alain on removing all the triggering event facilities from Object and porting it to announcement. Now I was wondering what is the ExclusiveWeakMessageSend. Stef

May 23, 2013