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

[Pharo-project] Display depth on Linux

by Hernan Wilkinson

On linux, when setting Display Depth to something else than 32, it is impossible to recongnize something on the screen. We did some research with Juan Vuletich on this and it sounds like an error on the VMnot the Smalltalk code We try it on Ubuntu 9.04, 64 bits. Is this a known bug? Hernan

Aug. 10, 2009

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

by Keith Hodges

StÃ©phane Ducasse wrote: > I have ginsu on my disc since years. > Ginsu was a good declarative model (now we have MC which plays the > same role). > What we are missing is a package management system. So may be > metacello can play this role. > I think that once we will have cleaner and better modular package we > should be able to rely on > an external build process to integrate and release pharo. > Right now script loader is a big bag of hack and scripts which were > mandatory to deal with dependent > packages and other dirty things. Also a true atomic loader will help. > (I mean true as opposite of Ginsu/MC<1.5 > loader which could not deal with the issue of modifying parts of the > system used to load the system). > So all in all I do not think that there is a need for Ginsu right now. > Cleaning and making MC better (probably MC2) is the way to go. > Something I feel that MC1.0 was designed from a UI point of view and > is a bit arcane to script. > Stef > > MC1.6 is the one with atomic loading Keith

Aug. 9, 2009

[Pharo-project] PluggableTextMorph without smalltalk shortcuts

by Tudor Girba

Hi, Is there a way to get a PluggableTextMorph without the default Smalltalk shortcuts? Until now I have something like: (PluggableTextMorph on: textModel text: #text accept: #accept:notifying: readSelection: #selection menu: #menu:shifted:) onKeyStrokeSend: #keystroke:from: to: textModel I can intercept a key like (Cmd+i), but I do not know how to disable the default behavior. Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

Aug. 9, 2009

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

by Michael Roberts

great, i have created a small page on the wiki http://code.google.com/p/pharo/wiki/PackageManagementSystem it would be good if people could update they are interested in / represent. I am mainly interested in links that go to docs & downloads (code). Looking at the recent IdeasToImplement tidy up, package management concerns are spread around somewhat. Would someone like to group them all together? thanks, Mike

Aug. 9, 2009

Re: [Pharo-project] About v4 strike fonts

by John M McIntosh

Are you sure you didn't have a BitBltPlugin.bundle in the Resource folder of any of those squeak.apps you deleted? I believe it would override the 4.1.1b2U behavior,, although someone could test that for me? On 9-Aug-09, at 1:20 PM, StÃ©phane Ducasse wrote: > Hi john > > I downloaded the vm from your web site and I got 1.0. > So I removed all the 4.4.1beta2U vm and replaced them by the latest > one. > This is really strange. > > Stef > -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================

Aug. 9, 2009

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

by Dale Henrichs

----- "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> wrote: | El dom, 09-08-2009 a las 10:29 -0700, Dale Henrichs escribiÃ³: | | > - Package to package dependencies. One can declare required | packages | > like the | > following: | > 'Example-Core-anon.9' | > 'Example-Tests-anon.3' requires: 'Example-Core' | > 'Example-AddOn-anon.1' requires: 'Example-Tests' | > 'Example-UI-anon.1' requires: { 'OB'. 'Example-AddOn'. } | > From the above statements, the package load order is derived and | used when you | > load the project: | > (ExampleProject version: '0.3') load | > It is also used to determine _which_ packages should be loaded | when an | > expression like the following is executed: | > (ExampleProject version: '0.3') load: 'Example-AddOn' | > This statement causes 'Example-Core-anon.9', | 'Example-Tests-anon.3', | > 'Example-AddOn-anon.1' to be loaded in order. | | This is very good, one thing that the package management system of | Debian has is that you can indicate a minimal version for a required | package: | | for example, following your code snippet: | | 'Example-Core-anon.9' | 'Example-Tests-anon.3' requires: 'Example-Core' minVersion: 9 | 'Example-AddOn-anon.1' requires: 'Example-Tests' minVersion: 1 | maxVersion: 3 | 'Example-UI-anon.1' requires: { 'OB' . 'Example-AddOn'. } | | This way, the package system doesn't have to install a exact version | if a group of | versions of the package required can equally work. This permits to | have a package, say | 5 of a package that have a new feature that I need in my image and not | be overwrote by | a dependency of other package that needs exactly version 3 that | doesn't have the feature | that I need. | | Maybe Metacello has this functionality, but if not, it would be, I | think, easy to add it, | just a comparation that the version available in the system meets the | criteria stated by | the package dependency. Metacello has the notion of version comparison operators (including the approximately greater than operator from Ruby Gems). These operators are used for project to project version comparison as well as comparing package versions. Currently a single operator is supported, but I intend to support range operations in a future version. | | Also, a form to force the install a package even if not all the | dependencies are met is good, | in particular to test some experimental package. This sounds like an interesting feature to consider...I'm inclined to use Notifications for these "boundary crossings" making it possible for the driver code to customize operations without burdening the core with tons of options ... but I'm just riffing:) | | For more information you can refer to the dpkg/deb/aptitude tools in | the debian system. | Of course that tools do a lot more but we don't need, at least for | now, all the features. | | | http://en.wikipedia.org/wiki/Aptitude_(program) | http://en.wikipedia.org/wiki/Deb_(file_format) | http://en.wikipedia.org/wiki/Dpkg | | All of them are GPL but I think that a new implementation, without use | the code, and in another | language, using only the ideas, is permited and can be integrated in | Pharo as MIT code. I agree that some useful ideas can be picked up from some of the other package management systems out there and I'm very open to specific suggestions. Dale

Aug. 9, 2009

Re: [Pharo-project] [ANN] 10413

by StÃ©phane Ducasse

Indeed I realized that this is a good question. For me the point is to have a good fall back when C plugin are not there. On Aug 9, 2009, at 7:04 PM, Damien Cassou wrote: > On Sun, Aug 9, 2009 at 3:32 PM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >> Now it should be easier for people that want to test strike fonts >> (one >> file to load) > > Why would Strike fonts be necessary? We have FreeType and a good > looking font by default in Pharo non-core. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > 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

Keith you mentioned that you did videos about Bob or sake. Do you have them so that I can watch them? Stef On Aug 9, 2009, at 10:01 PM, Keith Hodges wrote: > Keith Hodges wrote: >> 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" > Same goal as for Sake/Packages, and it works for me. > >>> (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 >>> > Not a realistic proposition. Better to be open to all to maintain on > behalf of the community. >>> - For each package there should be a known way to discuss and report >>> problems >>> > That's just arbitrary metadata in the package definition, for more > general topics we use the packages(a)squeakfoundation.org mailing list >>> - A gate keeper includes and removes packages from the set depending >>> on their status >>> > Probably too complicated to be practical. >>> 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 >>> > Sake/Packages supports a stable and a beta release of each package. >>> 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. >>> > Bob does that. >>> The package management system does not need to be very >>> sophisticated, >>> > Sake is as simple as possible for defining actions with dependencies. >>> but it should manage dependencies and have a simple GUI (to search >>> for >>> packages and see what is already loaded). >>> > Sake/Packages uses the class browser as is, no extra GUI is required. > > Packages provided explore > > shows you what is loaded, and this should be merged into > PackageOrganization. > > 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] a process to maintain non core package

by StÃ©phane Ducasse

I have ginsu on my disc since years. Ginsu was a good declarative model (now we have MC which plays the same role). What we are missing is a package management system. So may be metacello can play this role. I think that once we will have cleaner and better modular package we should be able to rely on an external build process to integrate and release pharo. Right now script loader is a big bag of hack and scripts which were mandatory to deal with dependent packages and other dirty things. Also a true atomic loader will help. (I mean true as opposite of Ginsu/MC<1.5 loader which could not deal with the issue of modifying parts of the system used to load the system). So all in all I do not think that there is a need for Ginsu right now. Cleaning and making MC better (probably MC2) is the way to go. Something I feel that MC1.0 was designed from a UI point of view and is a bit arcane to script. Stef On Aug 9, 2009, at 7:41 PM, John M McIntosh wrote: > I believe Joseph Pelrine work on one for the "Squeak World Tour" fork. > http://desk.org:8080/CampSmalltalk/Squeak%20World%20Tour%20Results > > From time to time he thinks of bring it up to date, but there is a > general lack of interest... > However I can ask him for a spec sheet/objectives for the product and > see how they match to other > proposals. > > If people are curious about why he would know a bit about package > management then consider > http://www.amazon.com/Mastering-Envy-Developer-Joseph-Pelrine/dp/0521666503 > > > On 9-Aug-09, at 9:03 AM, Michael Roberts wrote: > >> do we have a list of candidate package management systems? >> >> cheers, >> >> Mike >> > > -- > = > = > = > = > = > ====================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http:// > www.smalltalkconsulting.com > = > = > = > = > = > ====================================================================== > > > > > > _______________________________________________ > 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] Wiki for Pharo future work [WAS] preparing 1.1

by StÃ©phane Ducasse

I will do a pass on the items in the future because some are at different plans. Stef On Aug 9, 2009, at 8:19 PM, Mariano Martinez Peck wrote: > Hi folks. I have integrated and merged all those links for future > things for Pharo in this page: > > http://code.google.com/p/pharo/wiki/IdeasToImplement > > There are a lot of items I really don't know what they are and they > have very little information. Sometimes only a single world. I don't > know who wrote those things, but it would be wonderful people could > take 5 minutes and try to give more information about the items: > explanations, details, links, whatever. Because perhaps the one who > wrote that understands it but the others don't. If you don't have > edit permissons just ask or let me know and I write it. > > Finally, we should update the milestones page. However I don't have > the knowledge neither the authority to do this. Please the board or > someone update this. > > Best, > > Mariano > > > > > ---------- Forwarded message ---------- > From: Adrian Lienhard <adi(a)netstyle.ch> > Date: Thu, Aug 6, 2009 at 8:21 AM > Subject: Re: [Pharo-project] preparing 1.1 > To: Pharo-project(a)lists.gforge.inria.fr > > > There are also the following related wiki pages: > > http://code.google.com/p/pharo/wiki/Milestones > http://code.google.com/p/pharo/wiki/HaveALookAt > http://code.google.com/p/pharo/wiki/PlanToUse > http://code.google.com/p/pharo/wiki/ToDoBetterOnLongTerm > http://code.google.com/p/pharo/wiki/BetterMop > > (We should consolidate these pages.) > > If you have feature requests for 1.1, please post them here. > > Adrian > > On Aug 6, 2009, at 12:30 , StÃ©phane Ducasse wrote: > > > Hi guys > > > > we would like also to get a list of items for 1.1 > > > > http://code.google.com/p/pharo/wiki/IdeasToImplement > > > > > > â¢ MethodReference? and CompiledMethod? > > â¢ Clean category / comments (some package are totally wrong) > > â¢ First class packages > > â¢ Files: Cleaning file/directory (Gnu + rio rewrite) > > â¢ Streams > > â¢ Remove projects and other > > â¢ Clean ImageSegments? > > â¢ MethodReference?/CompiledMethod? > > â¢ NewCompiler? > > â¢ Better browser > > â¢ Cleaning Morphic (better integration of Polymorph) > > â¢ Rome and other Sophie library > > â¢ Preferences using pragmas > > â¢ Checking CUIS enhancement > > â¢ Checking Squeak enhancement > > â¢ Enhancement Strike Fonts > > â¢ underscore in selector > > - test server > > _______________________________________________ > > 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

Aug. 9, 2009