August 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Good Work Guys!

by StÃ©phane Ducasse

Thanks Daniel. Now we do not want to compete with Squeak. We did pharo because we had to. We hope that we will produce something good that people can use. Feel free to contribute. There is always something to do (test, reporting bugs, reporting that fixes are working....). Stef > All, > > I just had to let you all know that I'm so very excited about the > Pharo project. I've been back and forth with Squeak for many years. > Like others, I love the language, but very much disliked the > interface. I knew I just couldn't foist the look-and-feel on my users > and get away with it. Seaside mitigated this somewhat, since they > wouldn't have to see the interface, but it was still sort of painful > to me. I hated being so shallow that the look and feel affected me so > much, but there it was. > > I totally agree with you guys and your direction. My kids will still > use Squeak, but for me, it will be Pharo, different systems for > different goals. For me Pharo looks awesome, and while I've only > looked a little bit at Polymorph, it seems to be exactly what is > needed, a bunch of ready-made widgets to build UI's. I'll have no > problem with my users dealing with this interface. I can't wait for > the UI builder I've seen on Youtube. Finally, a truly cross-platform > development system for smalltalk for the mainstream developer! > > This is probably too long already, but thank you for all of your hard > work! > > DZ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

Re: [Pharo-project] a process to maintain non core package

by StÃ©phane Ducasse

On Aug 9, 2009, at 2:26 PM, Adrian Lienhard wrote: > Hi, > > I really think we need a package management system and a process to > maintain it. > > The goal is that loading and using non-core packages "just > works" (unlike for instance SqueakMap, where loading more often fails > than succeeds because there are a lot of obsolete packages and a > dependency mechanism is missing). Yeap! > - There should be a responsible maintainer for each package > - For each package there should be a known way to discuss and report > problems > - A gate keeper includes and removes packages from the set depending > on their status > > This limits the set of included packages (at least initially) but > would increase the quality and hence the user experience. > > Maybe there could be two sets, a stable and an unstable set. New > packages would first go to the unstable set and then move up to the > stable set after a while. Yes but if we take for example sound. When I integrate a fix from Cuis I do not want to get > An automated build process could load packages into new builds and > report the result of the tests. Yes! > The package management system does not need to be very sophisticated, > but it should manage dependencies and have a simple GUI (to search for > packages and see what is already loaded). Yes. We should start incrementally fixing that. I should look at Metacello and MC1.5 when I get more time. Stef > > Cheers, > Adrian > > On Aug 8, 2009, at 12:31 , StÃ©phane Ducasse wrote: > >> Hi >> >> in the future I would like to have a process like that to maintain >> package like sound (or morphic extras) or any package that are not >> core else we will not be able to maintain them or to apply package >> wide changes. >> >> - we mark the packages that are not in the image but that we want to >> maintain >> - at integration step we >> load all the external packages >> - integrate >> - publish in different repos >> >> Else I bet that we will not be able to maintain the non core >> packages. >> >> Stef >> >> PS: I'm integrating >> >> Issue 1051: Cuis 0053-ensure-close.1.cs >> and some changes touched sound so this is good experiment. >> >> _______________________________________________ >> 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

Aug. 9, 2009

[Pharo-project] [ANN] 10412

by StÃ©phane Ducasse

- Issue 1052: Cuis 0058-browseUndeclared.1.cs SystemNavigation default browseUndeclaredReferences - Issue 1055: Strike font preliminaries StrikeFont preliminaries for CUIS enhanced fonts. - Issue 1054: Cuis code author CUIS code author checking code SystemNavigation default contributorsNotSignatories SystemNavigation default allContributors SystemNavigation default contributionsOf: ... - Issue 1046: CompiledMethod>>asString throws error: Improper store into indexable object CompiledMethod>>asString ^self getSource Thanks dan shepherd Stef

Aug. 9, 2009

Re: [Pharo-project] a process to maintain non core package

by Adrian Lienhard

Hi, I really think we need a package management system and a process to maintain it. The goal is that loading and using non-core packages "just works" (unlike for instance SqueakMap, where loading more often fails than succeeds because there are a lot of obsolete packages and a dependency mechanism is missing). - There should be a responsible maintainer for each package - For each package there should be a known way to discuss and report problems - A gate keeper includes and removes packages from the set depending on their status This limits the set of included packages (at least initially) but would increase the quality and hence the user experience. Maybe there could be two sets, a stable and an unstable set. New packages would first go to the unstable set and then move up to the stable set after a while. An automated build process could load packages into new builds and report the result of the tests. The package management system does not need to be very sophisticated, but it should manage dependencies and have a simple GUI (to search for packages and see what is already loaded). Cheers, Adrian On Aug 8, 2009, at 12:31 , StÃ©phane Ducasse wrote: > Hi > > in the future I would like to have a process like that to maintain > package like sound (or morphic extras) or any package that are not > core else we will not be able to maintain them or to apply package > wide changes. > > - we mark the packages that are not in the image but that we want to > maintain > - at integration step we > load all the external packages > - integrate > - publish in different repos > > Else I bet that we will not be able to maintain the non core packages. > > Stef > > PS: I'm integrating > > Issue 1051: Cuis 0053-ensure-close.1.cs > and some changes touched sound so this is good experiment. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

[Pharo-project] Fwd: loading CUIS strike font

by StÃ©phane Ducasse

> > > Ok I missed it. > > Stef > > On Aug 8, 2009, at 4:06 PM, Juan Vuletich wrote: > >> Hi Stef, >> >> stephane ducasse wrote: >>> does one of you succeed to load the latest version of CUIS ? >>> http://www.jvuletich.org/Squeak/Misc/ >>> >>> I got base64Decoded missing but I could not find it in CUIS 258 >>> >>> Stef >> Load EnhancedStrikeFonts-Preliminaries.2.cs (included in the zip >> file) first. >> >> Cheers, >> Juan Vuletich >> > > > >

Aug. 9, 2009

Re: [Pharo-project] Pharo beta 1.0 and Tutorials/Books directions

by StÃ©phane Ducasse

We hope to have pharo by example for august. Stef On Aug 8, 2009, at 10:51 PM, csrabak(a)bol.com.br wrote: > Dear folks, > > Now Pharo beta 1.0 is out, and since the link > > http://www.pharo-project.org/documentation/tutorials-books suggests > the use of "Squeak By Example" as a first reference, I noticed that > a person following the book and using Pharo will not: > > 1) Be able to run the SqueakMap example from the Quick Tour; > > 2) Be able to create the SBECell (and as consequence build the > Quinto example) because the image does not have anymore > SimpleSwitchMorph (used to be in Morphic-Extras, but in Pharo this > package has only PaintBoxMorph and PaintBoxColorPicker). > > From the list I undertand the main reason classes have been dropped > in Pharo image, on the other hand, I think a note in documentation > page could either: > > a) A note mentioning that for following the book the interested > person should use a specific image prepared for that (which the SBE > www site point to); > > b) Put a list of instructions on how to adapt the directions on the > book in order to be able to use the Pharo image successfully. > > As older messages make me believe Oscar already is doing something > on this lines I don't know still if any further investigation for > 'b' above is necessary, however if this can be useful, I can give a > look on it! > > Regards, > > -- > > Cesar Rabak > GNU/Linux User 52247. > Get counted: http://counter.li.org/ > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

Re: [Pharo-project] Pharo beta 1.0 and Tutorials/Books directions

by Adrian Lienhard

Thanks for the feedback. I added a note to the website. Adrian On Aug 8, 2009, at 22:59 , Miguel Enrique CobÃ¡ Martinez wrote: > El sÃ¡b, 08-08-2009 a las 17:51 -0300, csrabak(a)bol.com.br escribiÃ³: >> Dear folks, >> >> Now Pharo beta 1.0 is out, and since the link >> >> http://www.pharo-project.org/documentation/tutorials-books suggests >> the use of "Squeak By Example" as a first reference, I noticed that a >> person following the book and using Pharo will not: >> >> 1) Be able to run the SqueakMap example from the Quick Tour; >> >> 2) Be able to create the SBECell (and as consequence build the Quinto >> example) because the image does not have anymore SimpleSwitchMorph >> (used to be in Morphic-Extras, but in Pharo this package has only >> PaintBoxMorph and PaintBoxColorPicker). > > There is a new version of the book in the works, aimed to Pharo. By > the > moment, I agree with you that a disclaimer should be added and maybe > the > first drafts of the book should be uploaded to the site, at least to > review and feedback to the authors. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

Re: [Pharo-project] Loading CUIS strike font

by StÃ©phane Ducasse

Apparently I used the V2 preliminaries files. I will integrate the V4 in the next release today. On Aug 8, 2009, at 3:09 PM, StÃ©phane Ducasse wrote: > > > does one of you succeed to load the latest version of CUIS ? > http://www.jvuletich.org/Squeak/Misc/ > > I got base64Decoded missing but I could not find it in CUIS 258 > > Stef > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

Re: [Pharo-project] a process to maintain non core package

by StÃ©phane Ducasse

thanks for the info. Stef On Aug 8, 2009, at 8:20 PM, Keith Hodges wrote: > StÃ©phane Ducasse wrote: >> Hi >> >> in the future I would like to have a process like that to maintain >> package like sound (or morphic extras) or any package that are not >> core else we will not be able to maintain them or to apply package >> wide changes. >> >> - we mark the packages that are not in the image but that we want to >> maintain >> - at integration step we >> load all the external packages >> - integrate >> - publish in different repos >> >> Else I bet that we will not be able to maintain the non core >> packages. >> >> Stef >> > In PackageInfo/MC1.5 packages keep knowledge of where they were loaded > from in order to support this scenario > > Keith > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 9, 2009

Re: [Pharo-project] Missing characters when typing?

by Michael Rueger

Michael Rueger wrote: > as additional info: one more thing: is it happening to people who are *not* using shout or auto completion? Michael

Aug. 9, 2009