- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Removing a package from Smalltalkhub

by Damien Cassou

On Tue, May 21, 2013 at 5:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > nah, it is a known missing feature (and really needed), there is a fix coming I think next week. the fix is already commited. Now, people can check if it is good: https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

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

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

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

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

2013/5/21 <btc(a)openinworld.com> > I agree with Igor on this one. The "insert key" toggles between Insert > Mode and Overwrite Mode - but the "key" is not the "mode" - it only > triggers the transition between the two modes. The perception that the > "insert key" is more strongly related Overwrite Mode is an illusion since > most text editors are in Insert Mode by default. Interesting. But I am too young to know about it :))

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

Hi 2013/5/21 phil(a)highoctane.be <phil(a)highoctane.be> > Why not TxBaseEditDecorator ? > For me null (or non) prefix better fit general idea about edit decorators. Edit decorators executes specific actions on text to perform basic edit operations. TxNullEditDecorator is doing nothing except basic edit operations. Also before I introduce edit decorator object TxEditor performs edit operations by itself. So TxNullEditDecorator works as null pattern here. > > > On Tue, May 21, 2013 at 9:23 AM, stephane ducasse < > stephane.ducasse(a)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. >>> >>> >> >> >

May 21, 2013

Re: [Pharo-dev] TxText new version 0.8

by Denis Kudriashov

I make changes which you suggest. So new version 0.9 published Renames: TxNoneEditDecorator->TxNullEditDecorator TxInsertModeEditDecorator->TxOverwriteModeEditDecorator And new TxSecretEditDecorator for password like fields. Best regards, Denis 2013/5/21 <btc(a)openinworld.com> > ** > Denis Kudriashov wrote: > > 2013/5/20 Igor Stasenko <siguctua(a)gmail.com> <siguctua(a)gmail.com> > > On 19 May 2013 22:01, Denis Kudriashov <dionisiydk(a)gmail.com> <dionisiydk(a)gmail.com> wrote: > > > TxInsertModeEditDecorator - input with "insert mode" where any new character replace next one. > > > insert mode is actually opposite - inserts when you type. > replace mode is replaces when you type. > > > > I choose this name because on Windows you have "insert key" to activate > such mode in many text editors. > > > > I agree with Igor on this one. The "insert key" toggles between Insert > Mode and Overwrite Mode - but the "key" is not the "mode" - it only > triggers the transition between the two modes. The perception that the > "insert key" is more strongly related Overwrite Mode is an illusion since > most text editors are in Insert Mode by default. Per your description > TxOverwritetModeEditDecorator would be more correct. > > Supporting info... > [1] > http://help.sap.com/saphelp_45b/helpdata/en/73/69ecc655bb11d189680000e829fb… > [2] > http://publib.boulder.ibm.com/infocenter/symphony/v1r1/index.jsp?topic=/com… > > I will be happy if you introduce more clever names. Good names is difficult > task for single brain. Especially if you are not native english speaker. > But many of you already suggest different names. How we can agree on any > one? > > > > Sometimes only by thrashing it around to wear off the rough edges. > > btw, I really enjoy reading about your advances with TxText. From a > distance, it just seems like its going to make interesting things easier to > do in the future. > > cheers -ben > >

May 21, 2013

Re: [Pharo-dev] [sbe] Pharo por Ejemplo vs Pharo en exemplos

by stephane ducasse

tx fixed in git :) Stef On May 21, 2013, at 7:59 PM, Mariano Vicente <m.vicent(a)gmail.com> wrote: > I like "Pharo en ejemplos" > > > Saludos, > Mariano > > > On Tue, May 21, 2013 at 1:06 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Pharo by example is correctly translated to "Pharo a travÃ©s de ejemplos", but that sounds odd for marketing in spanish... I think the best translation would be "Pharo en ejemplos", but I will ask a friend of mine who is translator :) > > On May 21, 2013, at 4:05 PM, GastÃ³n Dall' Oglio <gaston.dalloglio(a)gmail.com> wrote: > >> Hello. >> >> Or "Pharo con ejemplos"? in my poor English, I always interpreted this way in Spanish. >> >> Regards. >> >> >> 2013/5/21 Esteban A. Maringolo <emaringolo(a)gmail.com> >> +uno a "Pharo en ejemplos" ;-) >> >> Regards! >> >> Esteban A. Maringolo >> >> >> 2013/5/21 Rafael Luque <rafael.luque.leiva(a)gmail.com> >> I contributed to this translation with the Syntax and Seaside chapters. IMO "Pharo en Ejemplos" sounds more natural than "Pharo por Ejemplo" that is the literal word-by-word translation. >> >> Rafa >> >> >> 2013/5/21 stephane ducasse <stephane.ducasse(a)free.fr> >> >> On May 21, 2013, at 8:47 AM, Oscar Nierstrasz <oscar(a)iam.unibe.ch> wrote: >> >> > >> > Be careful, there are many different forms of Spanish. The title should be consistent with the main text. We are not qualified to judge. Ask someone who knows the different dialects. >> >> >> Yes I know :) >> >> > >> > Oscar >> > >> > --- >> > Prof. Dr. O. Nierstrasz -- oscar(a)iam.unibe.ch >> > Software Composition Group -- http://scg.unibe.ch/oscar >> > University of Bern -- Tel/Fax +41 31 631.4618/3355 >> > >> > >> > On 2013-05-21, at 8:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> > >> >> Hi guys >> >> >> >> one guy mentions that Pharo en exemplos is a better translation than Pharo por Ejemplo so what is your point of view on that? >> >> >> >> Stef >> >> _______________________________________________ >> >> sbe mailing list >> >> sbe(a)iam.unibe.ch >> >> https://www.iam.unibe.ch/mailman/listinfo/sbe >> > >> > _______________________________________________ >> > sbe mailing list >> > sbe(a)iam.unibe.ch >> > https://www.iam.unibe.ch/mailman/listinfo/sbe >> >> >> >> >> > >

May 21, 2013

Re: [Pharo-dev] [update 3.0] #30153

by stephane ducasse

yes because nicolas should change the diff algorithem to diff against the latest present parent and not just the direct one since we merge. I really want to get the diff working. Stef On May 21, 2013, at 5:48 PM, Frank Shearar <frank.shearar(a)gmail.com> wrote: > On 21 May 2013 16:44, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> 30153 >> ----- >> >> 10712 safer use of RPackage in ClassDescription>>#addAndClassifySelector:withMethod:inProtocol:notifying: >> https://pharo.fogbugz.com/f/cases/10712 >> >> >> Diff information: >> http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-EstebanLorenzano.1459.… > > Those diff links just 404. > > frank >

May 21, 2013

Re: [Pharo-dev] Removing a package from Smalltalkhub

by roberto.minelli＠usi.ch

Awesome, you guys are fast! A nice to have would also be a rename package and rename project without having to create a new project and/or a new package since in this way you will loose the history.. Cheers, R On May 21, 2013, at 5:53 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > you cannot, once you commited, your package belong to the universe :) > > nah, it is a known missing feature (and really needed), there is a fix coming I think next week. > > Esteban > > On May 21, 2013, at 2:53 PM, roberto.minelli(a)usi.ch wrote: > >> Hi, >> >> I was wondering if and how can I delete a package from Smalltalkhub. >> >> Thanks in avance, >> R >> > >

May 21, 2013

Re: [Pharo-dev] Suggestion about Phexample and StateSpecs(Mocketry) integration

by Denis Kudriashov

2013/5/21 Sean P. DeNigris <sean(a)clipperadams.com> > Camillo Bruni-3 wrote > > Yuriy we can discuss that after tomorrow? > > I would as well appreciate some common solution to avoid the selector > > clash. > > Bump ;) > > I don't remember is it was public conclusion but we agree to try StateSpecs for Phexample. After I finish key features of TxText I will adapt StateSpecs to satisfy Camillo requirements. > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Suggestion-about-Phexample-and-StateSpecs-Mocketry-in… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

May 21, 2013