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

Re: [Pharo-dev] Messy Configurations

by Camillo Bruni

On 2013-05-23, at 07:52, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > On May 23, 2013, at 4:22 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: >>> What do you think? >> >> I think we should have a stable and strong Versionner. As soon as making a software release is more than clicking one button, we will end up with messy configurations. > > Yes christophe worked on porting travis to pharo because dale used it for his tests so that we can get the latest version of metacello > in pharo. We do not do it for fun believe me. unless it runs in the current development version of Pharo I fear that it will ever be used. currently it only runs under 1.4 which is deprecated. If the current development aims at 2.0 we will have the same situation.

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by 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 <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] FileSystem inconsistency

by Camillo Bruni

On 2013-05-23, at 07:41, stephane ducasse <stephane.ducasse(a)free.fr> wrote: > We should talk when I'm back but my point is that > deleting an nonexisting file should raise an error, if deleting an non existig folder does. yes FilePluginPrims >> #deleteFile: should raise a warning if the file does not exist. otherwise it is quite inconsistent :/

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

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.

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

Am 23.05.2013 um 09:22 schrieb Camillo Bruni <camillobruni(a)gmail.com>: > My point is the following: Tests ARE functional documentation and thus should be shipped > under any circumstance with the rest of the code. Documentation is completely useless in a deployed runtime environment. And while I didn't package my tests and I use SUnit, Mocketry, Phexample, etc in my tests I have to load all of these in every image I deploy. I think there are more views on this field and I can't see a reason to enforce only one! Norbert

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Norbert Hartl

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

May 23, 2013

Re: [Pharo-dev] [Moose-dev] whitespace theme (work in progress)

by Esteban Lorenzano

supercool! (and really close to the work Nico and Ben were doing... any chance you can merge efforts? :) ) Esteban On May 22, 2013, at 9:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > I just wanted to let you know that I started to work on a Pharo theme that maximizes whitespace. > > It is based on the default Glamour theme, but it is even simpler. It is still a work in progress as several things I would like to achieve are not easily possible with the existing morphs' implementation. > > Still you can see the direction in a couple of screenshots at (plus a couple of explanations): > http://www.tudorgirba.com/blog/whitespace-theme-for-pharo-work-in-progress > > You can play with it in a Moose 4.8 image by: > > MooseImageSetupCommandLineHandler new > installFonts; > installAthens; > installGLMWhitespaceTheme. > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "When people care, great things can happen." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev

May 23, 2013

Re: [Pharo-dev] [Moose-dev] Re: whitespace theme (work in progress)

by Tudor Girba

Thanks. I do not know what they are doing. Is there anywhere I can look? Doru On Thu, May 23, 2013 at 9:30 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > supercool! > > (and really close to the work Nico and Ben were doing... any chance you > can merge efforts? :) ) > > Esteban > > On May 22, 2013, at 9:54 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > I just wanted to let you know that I started to work on a Pharo theme > that maximizes whitespace. > > > > It is based on the default Glamour theme, but it is even simpler. It is > still a work in progress as several things I would like to achieve are not > easily possible with the existing morphs' implementation. > > > > Still you can see the direction in a couple of screenshots at (plus a > couple of explanations): > > > http://www.tudorgirba.com/blog/whitespace-theme-for-pharo-work-in-progress > > > > You can play with it in a Moose 4.8 image by: > > > > MooseImageSetupCommandLineHandler new > > installFonts; > > installAthens; > > installGLMWhitespaceTheme. > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > > > "When people care, great things can happen." > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)iam.unibe.ch > > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev > -- www.tudorgirba.com "Every thing has its own flow"

May 23, 2013

How to find if a method has a version in a package

by Goubier Thierry

Hi, as the question says: how can I determine if a selector of a class is already listed as belonging to an existing version of a MC package ? What I want to do is to determine, when I drag a method from a class to a package, whether this method should go as an extension or an override. At the moment, in the AltBrowser, if you drag a method from a class to the extension tag of a package, it will move the method in the right extension protocol, creating it if needed. Now, what I'd like is, if you do that to a method which has a version in an existing package (not just in the current changes), it can give you the choice to list that method as an override instead of an extension. And for that, I need to query the MCPackage, no? Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

May 23, 2013

Re: [Pharo-dev] TxText new version 0.8

by Tudor Girba

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

May 23, 2013