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

MC should really write snaphsot/source.st in UTF8

by Nicolas Cellier

http://stackoverflow.com/questions/16645848/squeak-monticello-character-enc… Let's kill this one, it's totally insane

May 22, 2013

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

by Sean P. DeNigris

Camillo Bruni-3 wrote > because it is the final state, the file is deleted. > it emerged out of a longer discussion with sean, mariano and me I think Yes, we discussed thoroughly in the ml [1] (you were a part, but it was a while back). The objection, which I came to agree with, was that you're not "ensuring delete" because it may not be deleted (e.g. if it never existed). [1] http://forum.world.st/FileReference-should-throw-error-when-deleting-unexis… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-dev-could-we-rename-ensureDeleted-into-ensureDe… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 22, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/23 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > > 2013/5/22 Camillo Bruni <camillobruni(a)gmail.com> > > > >> > >> On 2013-05-22, at 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >>> Hi, > >>> > >>> On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >>> > >>>> On 22 May 2013 10:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > >> wrote: > >>>>> I would use > >>>>> > >>>>> TextModelCore > >>>>> TextModelExtensions > >>>>> > >>>>> TextModelCore-Tests > >>>>> > >>>>> No extra dash in the middle. > >>>> > >>>> nooooo :) > >>>> > >>>> But for tests, i +1, the names are not very good. > >>>> For package: > >>>> > >>>> Package-Name-Tick-Tack > >>>> > >>>> tests should be in: > >>>> > >>>> Package-Name-Tick-Tack-Tests > >>>> > >>>> This convention used everywhere in pharo. > >>> > >>> Please do not do that :). > >>> > >>> If you do that, publishing Package-Name-Tick-Tack will publish the code > >> from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely > >> implicit one-to-many mapping. > >>> > >>> So, the pattern I know of is to put the Tests as a discriminator before > >> the variable part of your code. So, something like: > >>> - BaseName-Core > >>> - BaseName-Tests-Core > >>> > >>> But, the rule I apply more recently for code is to use - only for > >> categories, and camel case for the Monticello packages. Like this we > also > >> document what is the unit of publishing, thus when you look into the > code > >> browser we also know what is mapped on a Monticello package. > >> > >> I would love to change that rule. I think Tests have the same value as > the > >> code itself. > >> The only reason to not load the code is the load time for the > >> configuration. Which is > >> basically is unimportant if you have a CI server preparing images for > you. > >> > >> I can only speak for smaller projects, but I really do not sea a reason > to > >> not load tests... > >> > > > > Because tests not needed to run your application. > > technically yes, but you do not need many things to run the code: > - class comments > - method comments > - any documentation in general > And I don't have it at production because I don't have changes file here. > yet you load them. so I wonder if it makes sense to even load tests > separately? > It make sense when you try to reduce production image size. And loading only required packages (without tests) works well. Why change it?

May 22, 2013

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

by Sven Van Caekenberghe

Yes, yes, cool ! Excellent experiment. On 22 May 2013, at 22:09, 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 >

May 22, 2013

Re: [Pharo-dev] TxText new version 0.8

by Camillo Bruni

On 2013-05-22, at 22:11, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2013/5/22 Camillo Bruni <camillobruni(a)gmail.com> > >> >> On 2013-05-22, at 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >>> Hi, >>> >>> On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>>> On 22 May 2013 10:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> >> wrote: >>>>> I would use >>>>> >>>>> TextModelCore >>>>> TextModelExtensions >>>>> >>>>> TextModelCore-Tests >>>>> >>>>> No extra dash in the middle. >>>> >>>> nooooo :) >>>> >>>> But for tests, i +1, the names are not very good. >>>> For package: >>>> >>>> Package-Name-Tick-Tack >>>> >>>> tests should be in: >>>> >>>> Package-Name-Tick-Tack-Tests >>>> >>>> This convention used everywhere in pharo. >>> >>> Please do not do that :). >>> >>> If you do that, publishing Package-Name-Tick-Tack will publish the code >> from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely >> implicit one-to-many mapping. >>> >>> So, the pattern I know of is to put the Tests as a discriminator before >> the variable part of your code. So, something like: >>> - BaseName-Core >>> - BaseName-Tests-Core >>> >>> But, the rule I apply more recently for code is to use - only for >> categories, and camel case for the Monticello packages. Like this we also >> document what is the unit of publishing, thus when you look into the code >> browser we also know what is mapped on a Monticello package. >> >> I would love to change that rule. I think Tests have the same value as the >> code itself. >> The only reason to not load the code is the load time for the >> configuration. Which is >> basically is unimportant if you have a CI server preparing images for you. >> >> I can only speak for smaller projects, but I really do not sea a reason to >> not load tests... >> > > Because tests not needed to run your application. technically yes, but you do not need many things to run the code: - class comments - method comments - any documentation in general yet you load them. so I wonder if it makes sense to even load tests separately?

May 22, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/22 Camillo Bruni <camillobruni(a)gmail.com> > > On 2013-05-22, at 21:04, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > Hi, > > > > On May 22, 2013, at 5:33 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> On 22 May 2013 10:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>> I would use > >>> > >>> TextModelCore > >>> TextModelExtensions > >>> > >>> TextModelCore-Tests > >>> > >>> No extra dash in the middle. > >> > >> nooooo :) > >> > >> But for tests, i +1, the names are not very good. > >> For package: > >> > >> Package-Name-Tick-Tack > >> > >> tests should be in: > >> > >> Package-Name-Tick-Tack-Tests > >> > >> This convention used everywhere in pharo. > > > > Please do not do that :). > > > > If you do that, publishing Package-Name-Tick-Tack will publish the code > from Package-Name-Tick-Tack-Tests, too :). Why? Because we have a lovely > implicit one-to-many mapping. > > > > So, the pattern I know of is to put the Tests as a discriminator before > the variable part of your code. So, something like: > > - BaseName-Core > > - BaseName-Tests-Core > > > > But, the rule I apply more recently for code is to use - only for > categories, and camel case for the Monticello packages. Like this we also > document what is the unit of publishing, thus when you look into the code > browser we also know what is mapped on a Monticello package. > > I would love to change that rule. I think Tests have the same value as the > code itself. > The only reason to not load the code is the load time for the > configuration. Which is > basically is unimportant if you have a CI server preparing images for you. > > I can only speak for smaller projects, but I really do not sea a reason to > not load tests... > Because tests not needed to run your application.

May 22, 2013

whitespace theme (work in progress)

by Tudor Girba

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

May 22, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/22 Igor Stasenko <siguctua(a)gmail.com> > On 22 May 2013 10:38, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > I would use > > > > TextModelCore > > TextModelExtensions > > > > TextModelCore-Tests > > > > No extra dash in the middle. > > nooooo :) > > But for tests, i +1, the names are not very good. > For package: > > Package-Name-Tick-Tack > > tests should be in: > > Package-Name-Tick-Tack-Tests > How it works? Monticello include all subcategories of package. And with this example tests will be part of package Package-Name-Tick-Tack. I test similar example at Pharo 2.0 > > This convention used everywhere in pharo. > > > Stef > > > > On May 21, 2013, at 10:24 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > > > > 2013/5/21 stephane ducasse <stephane.ducasse(a)free.fr> > >> > >> > >> On May 21, 2013, at 9:00 AM, Denis Kudriashov <dionisiydk(a)gmail.com> > >> wrote: > >> > >> 2013/5/20 stephane ducasse <stephane.ducasse(a)free.fr> > >>> > >>> > >>> Hello. > >>> > >>> New TxText version 0.8 is ready: > >>> > >>> - editor stuff extracted to separate packages TxText-Editor and > >>> TxTextTests-Editor > >>> > >>> may be you should call the second package TxTextEditor-Tests > >> > >> > >> I just follow convention of other TxText packages: TxText-Model -> > >> TxTextTests-Model, TxText-Layout -> TxTextTests-Layout and etc. > >> Some times ago I suggest such repackaging and nobody was against it > >> > >> > >> Still I think that the packages names are not good. I do not hitnk that > >> having tests mixed with the package name is a good approach > >> and we should clean all of them for 3.0 > > > > > > So what the correct way (Pharo way) to name test packages? > > For example I have 'MyPackage-SubCat1-SubCat2'. What name for test > package > > should be? > > > >> > >> > >> Stef > >> > >> > >> > >> > > > > > > > > -- > Best regards, > Igor Stasenko. > >

May 22, 2013

Re: [Pharo-dev] clean, please

by Camillo Bruni

On 2013-05-22, at 21:47, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Haha, maybe we should switch to swearing in other languages to honour the international character of the community ? nuff trolling for today :P > But, yes, clean code is paramount ! > > To come back to a previous discussion: clean code and good design are more important than method comments, class comments are indispensable IMO. yes please ;) I have the same priorities ;)

May 22, 2013

Re: [Pharo-dev] clean, please

by phil＠highoctane.be

Shut the f.ck up dammit. Le 22 mai 2013 21:41, "Camillo Bruni" <camillobruni(a)gmail.com> a Ã©crit : > the fucking code of course! > > On 2013-05-22, at 19:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > The kitchen, the living room ? > > > > On 22 May 2013, at 19:49, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > >> On 22 May 2013 19:41, Paul Davidowitz <pdavidow(a)fastmail.fm> wrote: > >>> Let's keep this clean, please! > >>> > >> > >> keep clean what? > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > > > > > > >

May 22, 2013