January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Miguel Enrique CobÃ¡ Martinez

El dom, 10-01-2010 a las 17:32 +0100, Adrian Lienhard escribiÃ³: > I would also rather disable it. We had numerous reports where this > failed. I think "the right way" to do it is to have a build server > that creates new Pharo images from the PharoCore version (i.e., > "nightly builds"). Until we have this automated, one can always grab > an up to date PharoCore and build a Pharo image using the Metacello > configuration. But this means that the users that downloaded a prior Pharo will be left on the cold and they will not receive bug fixes, including grave bug fixes. They will be informed that must download a new version and move all their code to a new image. This could generate a lot of irritation on the users because maybe they are changing images just because their current image can't apply a one-line fix that could be distributed by the update stream. Big decision I know, but both options have good arguments. Maybe a BIG warning on pressing the System->Update indicating that the update *could* break something in the image and suggesting to save all their work to a monticello package and know the consecuences and then giving them a button to proceed with the update. So if someone doesn't want to update he/she can cancel. If the haven't saved, they cancel and save their work, then proceed with the update. If they have everything saved, just proceed with the update knowing the consequences. What do you think? Cheers > > Adrian > > On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote: > > > On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike(a)mjr104.co.uk> > > wrote: > > > >> without its own update stream, or section in the update file, I think > >> the effect of allowing the Pharo image to update itself based on the > >> core update file would lead to an undefined result? > >> > >> > > Yes. Mostly due to overrides. > > > > > >> If that is the case I would disable it. > >> > >> I assume this would be replaced by some Metacello 'update stream' ? > >> > >> > > That's a good idea. I am not sure how to implement it, but for sure, > > it will > > be in a future ;) Maybe 1.1 > > > > > >> cheers, > >> Mike > >> > >> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: > >>> It is a simple question. Do we allow that or not. Miguel wrote > >>> the pros > >> and > >>> cons: > >>> > >>> Pros > >>> - Can fix bugs after release > >>> - Can aply improvements to the image after release. > >>> > >>> Cons > >>> - Can mess the image of someone by overwriting some overridden > >>> method. > >>> - Can accidentally update more than intended in someone's image > >>> > >>> > >>> We have to take a decision. > >>> > >>> Cheers > >>> > >>> Mariano > >>> > >>> _______________________________________________ > >>> Pharo-project mailing list > >>> Pharo-project(a)lists.gforge.inria.fr > >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >>> > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> Pharo-project(a)lists.gforge.inria.fr > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > >> > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Jan. 10, 2010

[Pharo-project] Pharo Smalltalk â¥

by Guido Stepken

Pharo Smalltalk â¥ ifTrue: [developer honk] That should be valid code :) Have fun! regards, Guido Stepken

Jan. 10, 2010

Re: [Pharo-project] Object Buffer (implementation tryout)

by CÃ©drick BÃ©ler

> > The problem is that without explaining someone what the menu item > "Buffer it" does and how to use it (e.g., to evaluate "self buffer") > it makes this feature hard to understand. > yes I agree > > I think the idea is good, but how could it be made easy to understand > and use? > don't really know. I first named it 'copy it' and 'paste it' but I don't think that's the issue > BTW, the same effect can also be achieved by assigning the object to a > global, e.g., "Buffer := self at: 4" and then in the popup select > "declare global" if Buffer is not a global yet. uhmm yes it seems better. No need for an extra class and instead of self buffer, evaluating the global is enough. Also, am I correct to remove a global like that: Smalltalk removeKey: #Buffer Maybe then a menu entry more explicit would be 'store in global named Buffer' 'assign to Buffer' "store in Buffer" ? ... uhm a bit too long... Maybe having 'buffer it' in the menu (or store it or copy it) and a secondary item named for instance 'paste it' that is accessible when Buffer exists and that paste 'Buffer' wherever needed. What do you think ? Cheers, -- CÃ©drick

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Fernando olivero

Thanks ! Initially i wont be integrating this changes in OB but is good to know this extra info. Fernando On Jan 10, 2010, at 4:55 PM, Danie Roux wrote: > On Sun, Jan 10, 2010 at 5:45 PM, Fernando olivero wrote: >> Would be nice to adopt this refactoring into Pharo, i've started to port it and cleaning up the textmorph in the process. But it's still a work in progress. > > Just a heads up: > > This will require some work in OB down the line. > > OBTextMorphEditor inherits from TextMorphEditor. Squeak trunk has this > refactoring in, and the default editor is now TextEditor there. > > Which OB is not making use of, as of yet. > > -- > Danie Roux *shuffle* Adore Unix - http://danieroux.com > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Tudor Girba

Hi Fernando, > File out the classes and edit and replace the underscores > assignments with :=, and they load just ok. > But Juan also modified other classes and methods referenced/used > while adopting the new editors objects. > > You can adopt it right away for Glamour, but remember that Morphic > in Cuis has a cleanup, and some methods may be not be there. > > I'm tracking them and will prepare a change set, for compatibiliy > with the Morphic in Cuis and Morphic in Pharo. For example Text in > Cuis, has some > methods that in Pharo are missing. I will wait for your notice then. > Juan did a really great work on this refactoring! and we should > integrate it as soon as posible. I very much agree :). Cheers, Doru > Fernando > > On Jan 10, 2010, at 5:50 PM, Tudor Girba wrote: > >> It would be really great to have that in Pharo. I would adopt it in >> Glamour in a heartbeat :) >> >> Is there an easy way to load this code in Pharo? Especially given >> that >> it looks like it can live side-by-side with the current editor. >> >> Cheers, >> Doru >> >> >> On 10 Jan 2010, at 16:45, Fernando olivero wrote: >> >>> Juan re-factored the smalltalk behavior in the editors, creating the >>> following hierarchy >>> >>> Editor >>> TextEditor SimpleEditor >>> SmalltalkEditor >>> >>> >>> See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html >>> . >>> >>> New text editors. >>> TextEditor provides most of the functionality that used to be in >>> TextMorphEditor. This class is no longer a Controller! >>> >>> SmalltalkEditor is has Smalltalk code specific features. >>> >>> SimpleEditor provides basic functionality for single line text >>> editing. It does not handle fonts and styles, aligning and Smalltalk >>> utilities. It handles one single line. >>> >>> Would be nice to adopt this refactoring into Pharo, i've started to >>> port it and cleaning up the textmorph in the process. But it's still >>> a work in progress. >>> >>> Fernando >>> >>> On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: >>> >>>> Hi, >>>> >>>>> Gary and others >>>>> >>>>> I really think that we should do an audit of Morphic. In 1.1 we >>>>> are >>>>> going already faster but I'm sure that there is plenty >>>>> of space for improvements. >>>>> >>>>> I see several actions >>>>> - checking squeak toolbuilder enhancements and using it for the >>>>> tools >>>>> >>>>> - checking CUIS >>>>> - juan did an excellent job remocving a lot of unnecessary code >>>>> - juan optimize scrollbar >>>>> - juan did a new texteditor morph >>>> >>>> Indeed, a text editor that does not hardcode smalltalk specific >>>> behavior would be great :). >>>> >>>>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>>>> - integrating better polymorph into the widgets layer. >>>>> >>>>> What do you think? >>>> >>>> >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Reasonable is what we are accustomed with." >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Be rather willing to give than demanding to get." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "To lead is not to demand things, it is to make them happen."

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Fernando olivero

File out the classes and edit and replace the underscores assignments with :=, and they load just ok. But Juan also modified other classes and methods referenced/used while adopting the new editors objects. You can adopt it right away for Glamour, but remember that Morphic in Cuis has a cleanup, and some methods may be not be there. I'm tracking them and will prepare a change set, for compatibiliy with the Morphic in Cuis and Morphic in Pharo. For example Text in Cuis, has some methods that in Pharo are missing. Juan did a really great work on this refactoring! and we should integrate it as soon as posible. Fernando On Jan 10, 2010, at 5:50 PM, Tudor Girba wrote: > It would be really great to have that in Pharo. I would adopt it in > Glamour in a heartbeat :) > > Is there an easy way to load this code in Pharo? Especially given that > it looks like it can live side-by-side with the current editor. > > Cheers, > Doru > > > On 10 Jan 2010, at 16:45, Fernando olivero wrote: > >> Juan re-factored the smalltalk behavior in the editors, creating the >> following hierarchy >> >> Editor >> TextEditor SimpleEditor >> SmalltalkEditor >> >> >> See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html >> . >> >> New text editors. >> TextEditor provides most of the functionality that used to be in >> TextMorphEditor. This class is no longer a Controller! >> >> SmalltalkEditor is has Smalltalk code specific features. >> >> SimpleEditor provides basic functionality for single line text >> editing. It does not handle fonts and styles, aligning and Smalltalk >> utilities. It handles one single line. >> >> Would be nice to adopt this refactoring into Pharo, i've started to >> port it and cleaning up the textmorph in the process. But it's still >> a work in progress. >> >> Fernando >> >> On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: >> >>> Hi, >>> >>>> Gary and others >>>> >>>> I really think that we should do an audit of Morphic. In 1.1 we are >>>> going already faster but I'm sure that there is plenty >>>> of space for improvements. >>>> >>>> I see several actions >>>> - checking squeak toolbuilder enhancements and using it for the >>>> tools >>>> >>>> - checking CUIS >>>> - juan did an excellent job remocving a lot of unnecessary code >>>> - juan optimize scrollbar >>>> - juan did a new texteditor morph >>> >>> Indeed, a text editor that does not hardcode smalltalk specific >>> behavior would be great :). >>> >>>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>>> - integrating better polymorph into the widgets layer. >>>> >>>> What do you think? >>> >>> >>> Doru >>> >>> -- >>> www.tudorgirba.com >>> >>> "Reasonable is what we are accustomed with." >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Be rather willing to give than demanding to get." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Tudor Girba

Hi, It looks like Metacello-Platform and Ocompletion are dirty. Any reason for why the changes are not in the Monticello repository? Cheers, Doru On 9 Jan 2010, at 18:13, Mariano Martinez Peck wrote: > Hi Folks/Beta-Testers! > > I have prepare a new PharoDev image. This image, has same > differences with the previous ones that you should know: > > 1) This is the first Dev image I ever prepare. I adapt to Mac OS > Damien's bash scripts to build them and I also cleanup all the > Squeak stuff from those bash scripts. So, maybe there are some > problems. Forgive me if this is the case. I would like you to check, > not only the Image in itself but also the zip. The package.txt, > changelog, the fonts, etc. > > 2) This image puts TrueType fonts again. We won't put StrikeFonts or > DejaVu package until there is big bug with them. We know those fonts > are faster, but still a bit buggy. If you fix those issues, cool! > > 3) This image DOES NOT include O2. I know there are a lot of people > who use it (mostly in Moose), but unfortunately, this was a decision > taken. O2 depends and overrides OB making this more unstable > sometimes. The same as the TrueType, we will put O2 again when this > can be perfectly load in a PharoCore image without anything about OB. > Sorry, but we rather affect only O2 users and not all. If you want > packages support, then help in O2 development. > > 4) In previous Dev images only tests from PharoCore were included. > Now, it also includes the tests from the external packages loaded. > > 5) This image was build using Metacello configurations. If you want, > compare the installScript.st from this image to the previous one. > > 6) There is no Web image this time. If you want to install Seaside > 2.8.4 evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside28'; > load. > > (Smalltalk at: #ConfigurationOfSeaside28) load > > And if you want Seaside 3.0 evaluate: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside30'; > load. > > (Smalltalk at: #ConfigurationOfSeaside30) loadLatestVersion > > However, I am not sure if this is perfectly working in Pharo. > > > > Ok .... Here is the link: https://gforge.inria.fr/frs/download.php/25156/pharo1.0-10505-rc1dev10.01.1… > > I will wait a couple of days now and I will also start to use this > image for my development. If there are issues, report them. If we > have big issues, this image is not release. On the other hand, if it > works well, we release it. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every thing has its own flow."

Jan. 10, 2010

Re: [Pharo-project] CUIS new Text Editor Classes

by Tudor Girba

It would be really great to have that in Pharo. I would adopt it in Glamour in a heartbeat :) Is there an easy way to load this code in Pharo? Especially given that it looks like it can live side-by-side with the current editor. Cheers, Doru On 10 Jan 2010, at 16:45, Fernando olivero wrote: > Juan re-factored the smalltalk behavior in the editors, creating the > following hierarchy > > Editor > TextEditor SimpleEditor > SmalltalkEditor > > > See the comment in Editor class in Cuis image http://www.jvuletich.org/Cuis/Index.html > . > > New text editors. > TextEditor provides most of the functionality that used to be in > TextMorphEditor. This class is no longer a Controller! > > SmalltalkEditor is has Smalltalk code specific features. > > SimpleEditor provides basic functionality for single line text > editing. It does not handle fonts and styles, aligning and Smalltalk > utilities. It handles one single line. > > Would be nice to adopt this refactoring into Pharo, i've started to > port it and cleaning up the textmorph in the process. But it's still > a work in progress. > > Fernando > > On Jan 10, 2010, at 3:09 PM, Tudor Girba wrote: > >> Hi, >> >>> Gary and others >>> >>> I really think that we should do an audit of Morphic. In 1.1 we are >>> going already faster but I'm sure that there is plenty >>> of space for improvements. >>> >>> I see several actions >>> - checking squeak toolbuilder enhancements and using it for the >>> tools >>> >>> - checking CUIS >>> - juan did an excellent job remocving a lot of unnecessary code >>> - juan optimize scrollbar >>> - juan did a new texteditor morph >> >> Indeed, a text editor that does not hardcode smalltalk specific >> behavior would be great :). >> >>> - removing/cleaning extra widgets Pluggable/nonpluggable plague. >>> - integrating better polymorph into the widgets layer. >>> >>> What do you think? >> >> >> Doru >> >> -- >> www.tudorgirba.com >> >> "Reasonable is what we are accustomed with." >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

Jan. 10, 2010

Re: [Pharo-project] Allow or disable System Update in PharoDev images ?

by Adrian Lienhard

I would also rather disable it. We had numerous reports where this failed. I think "the right way" to do it is to have a build server that creates new Pharo images from the PharoCore version (i.e., "nightly builds"). Until we have this automated, one can always grab an up to date PharoCore and build a Pharo image using the Metacello configuration. Adrian On Jan 10, 2010, at 16:59 , Mariano Martinez Peck wrote: > On Sun, Jan 10, 2010 at 4:56 PM, Michael Roberts <mike(a)mjr104.co.uk> > wrote: > >> without its own update stream, or section in the update file, I think >> the effect of allowing the Pharo image to update itself based on the >> core update file would lead to an undefined result? >> >> > Yes. Mostly due to overrides. > > >> If that is the case I would disable it. >> >> I assume this would be replaced by some Metacello 'update stream' ? >> >> > That's a good idea. I am not sure how to implement it, but for sure, > it will > be in a future ;) Maybe 1.1 > > >> cheers, >> Mike >> >> 2010/1/10 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>> It is a simple question. Do we allow that or not. Miguel wrote >>> the pros >> and >>> cons: >>> >>> Pros >>> - Can fix bugs after release >>> - Can aply improvements to the image after release. >>> >>> Cons >>> - Can mess the image of someone by overwriting some overridden >>> method. >>> - Can accidentally update more than intended in someone's image >>> >>> >>> We have to take a decision. >>> >>> Cheers >>> >>> Mariano >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Lukas Renggli

> Lukas: I had most of the tests in red until I install the package OB-Fake > Do you know which packages from OB require OB-Fake? OB-Fake is a fake view. It is used by all tests that do not test another view (morphic or web). > After that I have only two tests failing :) > > - testPushAlpaBeta > - testUpdatesSelection > > The same it is here: http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… I fixed the other two bugs, they were caused by a bug in the hudson test runner. Don't know the matter with these buggers. Will have a look later tonight. > > :) > > Thanks > > Mariano > > > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 10, 2010