- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Miguel Enrique CobÃ¡ MartÃnez

El jue, 05-08-2010 a las 19:45 +0200, Norbert Hartl escribiÃ³: First some terms that I use: - Software Package: a collection of classes that conform a working, useful software. Often is convey to other users in the form of one o various monticello packages. - Software Release: a stamped snapshot of a Software package - Monticello: a software that creates mcz files, called monticello packages that comprises a set of classes that are part of a Software Package. - Configuration, ConfigurationOfXXX: Metacello configuration that loads a set of Monticello Packages that together form a release of a Software Package. > > > > > I think Javier is right. I, too, have problems to understand how this > should work. A lot of the ConfigurationOfxxx files are about software > projects that run on pharo and aren't _part_ of it. Just take a > project like seaside. That is a project that runs on a lot of > platforms (hence the existence of grease). The ConfigurationOfXXX packages _are_ for packages not part of a core or released image. That is their raison d'Ãªtre. > > > Clarity. As is very likely that different releases of a package will > > have distinct requirements in: > > - dependencies > > > > > that is what metacello is all about Yes, but it complicates a lot when you try to use a single Configuration to load several releases of a Software Package in several releases of Pharo. Just see the size of the configuration of ConfigurationOfSeaside28 that handles pharo, sqeuak and gemstone installs. I'm sure that Dale tried to add also support for Seaside 3.0 in the same Configuration but that were so much effort compared to just create a new ConfigurationOfSeaside30 that handles only the required mcz packages for 3.0 and forgets and don't care about the mcz packages for 2.8. I was about of doing the same for ConfigurationOfMagma. I considered create a new ConfigurationForMagma11r2 that handles only the packages for that release (that are not so distinct to the previous release as in the case of Seaside, but the scenario is the same). No way. That is not the solution. Not at a long term. So the metacello repositories idea (that was already discussed before) was a perfect solution. > > > > - preinstall/postinstall actions > > - registering with system services (menu, mail systems, sockets, > > startup/stop list) > > > > > that is platform specific. For seaside that needs to be solved from > the seaside crew otherwise they won't stay cross-platform very long. > And I think there is no point in many people writing in a > ConfigurationOfSeaside30 file. Those files should be very dependent on > the people writing seaside. Do you think you will add pharo1.1 stuff > to the file? The ConfigurationOfSeasideXX aren't created, maintained, debuged or cared by the Seaside core developers. And that is good. They concentrate in the Seaside code, and the Configuration maintainers (Dale) concentrate in the installation issue in the various platforms. Of course the maintainer coordinate with the upstream developers to solve platform specific problems, and of course nothing stops a core developer of a Software Package to maintain the ConfigurationOfTheirOwnPackage (as OSProcess' creator is doing) > > > - number of monticello packages composing the package you're > > installing > > > > > that's dependencies Yes but they are distinct for each Pharo release: - because maybe the Pharo release already includes some package previously required by the package (e.g Announcements being part of the core) - because the new Pharo release unloaded some package that previously was part of the core system (e.g. if it depends on Crypto and crypto isn't anymore part of the core image). And also they are distinct in each Software Package release: - because the Software Package was simplified to not use some package anymore - because the Software Package includes new functionality that isn't part of the core system > > > - use of system infraestructure (announcements, transcript, menus, > > help > > system) > > > > again platform handling ditto. > > > > > it will be a nightmare to have code to cope with all those > > conditions in > > a single monolithic giant metacello package, even if metacello is > > capable of do it. > > What if after 4 years of development the package has had 15 > > releases, > > that will means that you'll have possibly 15 > > baselines/predoits/postdoits all listing in the method pane of the > > browser. To someone trying to understand the configuration, it will > > be a > > lot of junk to discard before he understand only the bits that > > matter > > for the release he is interested in. > > > > So, it is healthy to have a distinct configuration in each release > > (even > > if in the current release started as a copy of the previous release > > configuration), to crop the things the _maintainer_ thinks are not > > needed anymore or simply that he doesn't want to maintain anymore. > > All > > the software has a lifetime and distinct repositories gives us the > > possibility to determine the time to end support for a given release > > > > > > > Please correct me if I'm wrong. By copying the configuration files you > make a snapshot of the project without the possibility to alter > anything. The configuration file itself is modified by the software > project the file is for. Probably the software project does not want > anyone to write in the config file. I don't understand this previous paragraph. What config files are you refering to, the Metacello configuration? If so they are in Read/Write repositories to all to modify. Also, they are by the license notice in the page, MIT, so there is no way someone can stop other to modify the Configuration for adapting it when a new Pharo release (or gemstone or squeak) is out. > > > To me a central repository is essential. It is a single well-known > source and it carries the idea of cross-platformness :) Isn't that > would you are trying to solve not just another ConfigurationOfXXX > file. For the moment let's call it ConfigurationOfPharo10Universe. > There you can refer to every single version in another > ConfigurationOfXXX file that is said to be runnable in that platform. > And you can decorate it with pre-/postDoits as you want. Yes, I know, the ConfigurationOfMagma does depends on other packages too: OSProcess, WriteBarrier. That is not a problem. The problem is the proliferation of pre/post doits and custom conditionals to handle the distinct combinatios of Pharo (or gemstone or squeak) releases and Software Package Releases > > I think that most of this software management tasks are solvable by a > description of "requires" and "provides". And metacello solves it > well. As an example let's think of an example like > ConfigurationOfPharoWebDeveloperImage (maintained by the image > provider). The developer image develops linearly hence no version > number in the file. The ConfigurationOfPharoWebDeveloperImage has > dependencies to 20 other software projects that are all defined in a > ConfigurationOfPharo11Universe (maintained by the community). Let's > say it has a dependency on 'Seaside 3.0'. > ConfigurationOfPharo11Universe offers 'Seaside 3.0' and has a > dependency of 'Seaside 3.0.3' in ConfigurationOfSeaside30 (maintained > by the seaside maintainers). ConfigurationOfSeaside30 has a dependency > to 'Grease 1.0.3' in ConfigurationOfGrease. So let's asssume finally > that ConfigurationOfGrease would have a dependency to 'Pharo 1.1' when > run under pharo1.1 or to 'Pharo 1.1 compat package' when run under > pharo 1.0 (metacello allows us to do that). And that is precisely the point. As time goes on, the number of this "conditional" will grow exponentially, lowering the quality of the Configuration and difficulting the maintenance of it. If all of this can be solved by simply copying the current configuration to a new repository on squeaksource when a new Pharo release is out, then better for all, mainly for the maintainer that is the one doing the hard work of maintaing the configuration. > All of these descriptions require and provide anything. And the > descriptions are services offered from one group to another taking a > certain responsibility. You can always rely on things like "Seaside > 3.0" if you trust the people and if not than you use "Seaside > 3.0.4rc2a". > > > What I wanted to say is that there are plenty of situations where you > want to cluster software packages together. By copying the files you > just double to stuff without being able to tweak. I don't understand this part too, why woulnd you be able to tweak it? Also, if the ConfigurationOfMagma, for example, is copied to MetaRepoForPharo1.3 (when Pharo 1.3 is out) and it needs ConfigurationOfOSProcess then I copy also ConfigurationOfOSProcess from MetaRepoForPharo1.2 to MetaRepoForPharo1.3 and then all is working correctly again. > Removing the packages from the MetacelloRepository as Stephane > suggested would just make them platform dependent. Having less files > and clear roles who might change them is something achievable IMHO. > Tearing things apart (by copying) lowers sometimes integration effort. > Or to say with view from the XML world: "If you want to > integrate/cooperate than XML schema is for you If you don't want to do > that than use XML namespaces". I don't get it. :) A final point, the idea is that the end users won't see how things are implemented. The tools will have to be modified to understand this MetacelloRepositories thing. Gofer, GoferProjectLoader and Metacello itself will need to add an indirection when accessing repositories so that they access the correct repository for the image they are running on. With this the user will do Gofer new universe; "Here Gofer points to the Pharo10, Pharo11, etc" package: 'ConfigurationOfMagma'; load; Or better yet: Gofer project load: 'Magma'. "using GoferProjectLoader modified to understand MetacelloRepositories" and when doing a: ConfigurationOfXXX project latestVersion the references to required ConfigurationOfXXX dependencies will need to be taken from the same repository where the ConfigurationOfXXX was got. This way the "Universe" analogy of self-contained group of packages known to work in a given release is fulfilled. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Aug. 5, 2010

[Pharo-project] Code autocompletion on not really fast machines

by laurent laffont

Hi, I'm currently using Pharo 1.1 on a Pentium 3Ghz ~ 4 years old machine on Linux. I feel that code editing is slow, auto-completion can hang the GUI for 2-5 seconds, especially when there's undeclared variables (I usually set them using the dialogs when I accept the code). Am I alone ? Laurent Laffont http://pharocasts.blogspot.com/ http://magaloma.blogspot.com/

Aug. 5, 2010

Re: [Pharo-project] HTTP client library in Pharo?

by Andrei Stebakov

Hi Andreas I believe that the key is in (quoting): "The syntax for the header is: cookie = "Cookie:" cookie-version 1*((";" | ",") cookie-value) ... " That means when you want to send multiple cookies (cookie1 has name1 and value1, cookie2 has name2 and value2) you send: "Cookie: name1=value1; name2=value2" In your case you send two different headers: "Cookie: name1=value1" "Cookie: name2=value2" Maybe some servers may accept this, but the one I am working with chokes on it and skips all the "Cooke: " statements following the first one. If you take a look at the "Live HTTP headers" with FireFox, you'll see requests with cookies follow the "all-cookies-in-one-line" rule. Regards, Andrei On Wed, Aug 4, 2010 at 1:15 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > On 8/4/2010 9:57 AM, Mariano Martinez Peck wrote: >> >> Hi Adrei, excellent :) >> >> BTW, for HTTP Client you should cc Andreas Raab Â or squeak mailing >> list.... > > Squeak-dev please > (http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev) > >> On Wed, Aug 4, 2010 at 6:08 PM, Andrei Stebakov <lispercat(a)gmail.com >> <mailto:lispercat@gmail.com>> wrote: >> >> Â Â I also found that cookies were not correctly sent. >> Â Â Every cookie was sent with its own "Cookie: " header which is not >> Â Â correct. > > I'm curious, why do you think that's incorrect? My understanding is that RFC > 2616 explicitly allows that: > > Â Â Â Â "Multiple message-header fields with the same field-name MAY be > present in a message if and only if the entire field-value for that header > field is defined as a comma-separated list [i.e., #(values)]. It MUST be > possible to combine the multiple header fields into one 'field-name: > field-value' pair, without changing the semantics of the message, by > appending each subsequent field-value to the first, each separated by a > comma." > > And the condition appears to be satisfied in RFC 2109 regarding the Cookie > header: > > "The syntax for the header is: > > Â cookie Â Â Â Â Â = Â Â Â "Cookie:" cookie-version > Â Â Â Â Â Â Â Â Â Â Â Â Â 1*((";" | ",") cookie-value) > ... " > > >> Â Â Also cookie collection is too restrictive to the domain. Let's say >> Â Â your request goes to www.domain.com <http://www.domain.com> and in >> Â Â the cookies it'll have >> Â Â domain.com <http://domain.com>. >> Â Â Those cookies won't be collected since the current algorithm requires >> Â Â it to match from the start of the string (probably should only match >> Â Â the end of the string). > > Yeah, that's a silly bug. Thanks for reporting. > > Cheers, > Â - Andreas > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Norbert Hartl

On 05.08.2010, at 17:09, Miguel Enrique CobÃ¡ MartÃnez wrote: > El miÃ©, 04-08-2010 a las 23:32 -0300, Javier PimÃ¡s escribiÃ³: >> Maybe I saying nonsense, if that is the case just ignore me but... why >> have many packages that do almost exactly the same? Aren't you going >> to get a lot of repeated code lying around in different packages? ie. >> I think most packages have almost exactly the same baselines for >> pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX >> and let them stay in the same class and package? Or maybe adding other >> pragma to specify which pharo version each baseline/version describes. >> I'm sure there could be other solutions. That way you'd have all the >> configurations in the same place and also reuse code if needed instead >> of duplicating it. > I think Javier is right. I, too, have problems to understand how this should work. A lot of the ConfigurationOfxxx files are about software projects that run on pharo and aren't _part_ of it. Just take a project like seaside. That is a project that runs on a lot of platforms (hence the existence of grease). > Clarity. As is very likely that different releases of a package will > have distinct requirements in: > - dependencies that is what metacello is all about > - preinstall/postinstall actions > - registering with system services (menu, mail systems, sockets, > startup/stop list) that is platform specific. For seaside that needs to be solved from the seaside crew otherwise they won't stay cross-platform very long. And I think there is no point in many people writing in a ConfigurationOfSeaside30 file. Those files should be very dependent on the people writing seaside. Do you think you will add pharo1.1 stuff to the file? > - number of monticello packages composing the package you're installing that's dependencies > - use of system infraestructure (announcements, transcript, menus, help > system) again platform handling > > it will be a nightmare to have code to cope with all those conditions in > a single monolithic giant metacello package, even if metacello is > capable of do it. > What if after 4 years of development the package has had 15 releases, > that will means that you'll have possibly 15 > baselines/predoits/postdoits all listing in the method pane of the > browser. To someone trying to understand the configuration, it will be a > lot of junk to discard before he understand only the bits that matter > for the release he is interested in. > > So, it is healthy to have a distinct configuration in each release (even > if in the current release started as a copy of the previous release > configuration), to crop the things the _maintainer_ thinks are not > needed anymore or simply that he doesn't want to maintain anymore. All > the software has a lifetime and distinct repositories gives us the > possibility to determine the time to end support for a given release > Please correct me if I'm wrong. By copying the configuration files you make a snapshot of the project without the possibility to alter anything. The configuration file itself is modified by the software project the file is for. Probably the software project does not want anyone to write in the config file. To me a central repository is essential. It is a single well-known source and it carries the idea of cross-platformness :) Isn't that would you are trying to solve not just another ConfigurationOfXXX file. For the moment let's call it ConfigurationOfPharo10Universe. There you can refer to every single version in another ConfigurationOfXXX file that is said to be runnable in that platform. And you can decorate it with pre-/postDoits as you want. I think that most of this software management tasks are solvable by a description of "requires" and "provides". And metacello solves it well. As an example let's think of an example like ConfigurationOfPharoWebDeveloperImage (maintained by the image provider). The developer image develops linearly hence no version number in the file. The ConfigurationOfPharoWebDeveloperImage has dependencies to 20 other software projects that are all defined in a ConfigurationOfPharo11Universe (maintained by the community). Let's say it has a dependency on 'Seaside 3.0'. ConfigurationOfPharo11Universe offers 'Seaside 3.0' and has a dependency of 'Seaside 3.0.3' in ConfigurationOfSeaside30 (maintained by the seaside maintainers). ConfigurationOfSeaside30 has a dependency to 'Grease 1.0.3' in ConfigurationOfGrease. So let's asssume finally that ConfigurationOfGrease would have a dependency to 'Pharo 1.1' when run under pharo1.1 or to 'Pharo 1.1 compat package' when run under pharo 1.0 (metacello allows us to do that). All of these descriptions require and provide anything. And the descriptions are services offered from one group to another taking a certain responsibility. You can always rely on things like "Seaside 3.0" if you trust the people and if not than you use "Seaside 3.0.4rc2a". What I wanted to say is that there are plenty of situations where you want to cluster software packages together. By copying the files you just double to stuff without being able to tweak. Removing the packages from the MetacelloRepository as Stephane suggested would just make them platform dependent. Having less files and clear roles who might change them is something achievable IMHO. Tearing things apart (by copying) lowers sometimes integration effort. Or to say with view from the XML world: "If you want to integrate/cooperate than XML schema is for you If you don't want to do that than use XML namespaces". Norbert >> >> On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com> >> wrote: >> Miguel, >> >> I think that this kind of approach makes lots of sense ... >> I've toyed with the idea of a "white list" of configuration >> versions, but someone would have to be responsible for >> maintaining the "white list" and the users would have to >> responsible for using the "white list" ... >> >> A repository per version is very simple and gives the >> maintainer flexibility in managing releases. >> >> Dale >> >> >> Miguel Enrique CobÃ¡ MartÃnez wrote: >> >> >> El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov >> escribiÃ³: >> Why there should be repository per release? As >> i know >> MetacelloConfiguration already contains >> information about compatible >> Pharo versions. >> >> Because is cleaner and as the releases of Pharo >> diverge a lot more, the >> code to install package becomes full of conditionals >> to handle the >> distinct issues with each pharo release. >> For example, Magma. Magma 1.1r1 worked good in any >> pharo 1.0, 1.1 and >> 1.2. >> But Magma 1.1r2 doesn't work anymore on Pharo1.0 >> because Pharo 1.0 >> doesn't have the classes DirectoryEntryDirectory and >> DirectoryEntryFile >> that are used by the new magma version. >> So I had to modify the configuration with conditionals >> an several >> variations of preDoits and postDoits and test what >> version image is >> ConfigurationOfMagma is being ran. After a couple of >> hours I gave up. >> >> The correct solution is to have a specific >> ConfigurationOfMagma for each >> released pharo version. >> This have benefits also: >> - It permits the unstable repository to heavily update >> the >> ConfigurationOfXXX without disturbing or broke the >> stable ones. >> - It permits the ConfigurationOfXXX code to remain >> clean, without a >> conditionals for every posible combination of release >> image version and >> package to be installed version >> - It permits the maintainer of a ConfigurationOfXXX to >> decide when to >> stop supporting old version of a certain package by >> deleting the old >> versionXX: methods of the ConfigurationOfXXX in the >> newer pharo >> releases. Not always is good to be able to install >> each and every >> version of a package in the newest release of pharo >> (maybe even old >> versions won't work in the new releases, like the menu >> registration >> issue or classes that doesn't belong to the core >> image) >> - It permits to issue maintenance ConfigurationOfXXX >> releases for a >> stable or "old-stable" image releases, without >> altering the >> configurationOfXXX in other repositories >> Cheers >> >> 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez >> <miguel.coba(a)gmail.com>: >> El miÃ©, 04-08-2010 a las 11:46 +0200, >> Torsten Bergmann escribiÃ³: >> Hi Miguel, >> >> hey, nice! If we follow this >> convention then it is easy to >> implement >> a universe browser that >> selects the correct universe >> repo and >> displays all loadable >> versions. Loading stuff should >> just be >> a few clicks away - I >> personally hate all this >> MC/Gofer typing ... >> >> Attached is a quick/simple >> implementation of such a >> browser: >> >> Mann, Sie sind Ã¼ber schnell! >> >> I tested it in PharoCore 1.0 and >> worked after a few changes, but the >> interface is cool. +1 to aim it be the >> default universe browser in 1.2. >> Simple, to the point. >> In Pharo 1.0 I had: >> >> - Open it with Universe open (doesn't >> register on menu because of the >> lacking pragmas) >> - UniverseBrowser pharoUniverse >> returns PharoCore1.0 instead of >> Pharo10 >> to build the universe name. This could >> be changed in two ways: >> - Add a system property that states >> the image repository: >> SystemVersion current universeName >> "Returns Pharo10 for image >> releases 1.0, 1.0.1, 1.0.5, etc) >> - Use the equivalent method in the >> gofer package I uploaded to >> PharoInbox (if it is approved, so >> there is only a unique source for >> converting image version string to >> universe names) >> >> Other than that, I like the browser. >> >> >> >> - file in the attached >> changeset (I tried in Pharo >> 1.2) >> - open via World menu -> >> "Universe Browser" >> - select the configuration >> you want and from the context >> menu choose >> -- "Load configuration" >> -> only the config is loaded >> -- "Load configuration and >> latest version" -> the config >> and lates version is loaded >> >> Have fun! I used Pharo 1.2 - >> should work in Pharo 1.0 and >> 1.1 too >> (havent tested). >> >> Bye >> T. >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> Cheers >> >> -- >> Miguel CobÃ¡ >> http://miguel.leugim.com.mx >> >> >> _______________________________________________ >> 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 >> >> >> >> -- >> Javier PimÃ¡s >> Ciudad de Buenos Aires >> _______________________________________________ >> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 5, 2010

Re: [Pharo-project] Extract method dialog is too small to see what your typing

by Lukas Renggli

Fixed in the following commit: Name: OB-Refactory-lr.224 Author: lr Time: 5 August 2010, 7:18:55 pm UUID: 0cb4251d-5b9d-475f-8bb5-4a5d63494212 Ancestors: OB-Refactory-lr.223 - force the extract method dialog to be wider It is a bit an ugly hack, I have no idea how Morphic is supposed to work. Lukas 2010/8/4 Tim Mackinnon <tamackinnon(a)gmail.com> > I've logged 2747 <http://code.google.com/p/pharo/issues/detail?id=2747> - > the extract method dialog window is just too small to be used - and its > worse when you type a : for a selector (Pharo 1.1) > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Aug. 5, 2010

Re: [Pharo-project] eCompletion tweak for smart characters

by Lukas Renggli

Hi Tim, I've integrated your changes. I chose a slightly simpler implementation and slightly different behavior (I think) that I interpreted from your code as "do not complete smart characters if there is no separator and not the begin or the end of the text to either side of the cursor". TextMate seems to do that too. Lukas On 3 August 2010 12:21, Lukas Renggli <renggli(a)gmail.com> wrote: > Hi Tim, > > Thank you for the contribution. I will definitely look at it as soon > as I get access to a computer Â again (i am a few days away right now). > > Testing this would be definitely cool, especially given all the edge > cases. It is certainly testable, but kind of tricky to setup > everything. > > Lukas > > On Tuesday, August 3, 2010, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: >> Guys - this is my first attempt at a contribution - and I'm not sure how literally to take the advice on "how to contribute to Pharo" for a small change. Should I create an issue, and post it here (happy to do that, but wondered if conversation might be useful first as I'm new to this). >> >> Given that I'm not sure what the relationship between eCompletion and oCompletion is (someone mentioned the latter is built on top of the former?) - so maybe I'm barking up the wrong tree, however I was impressed with how much quicker Lucas' Hudson built pharo image was with eCompletion so I've been trying that for a few days (although I've noticed some mails on oCompletion but haven't gone back to retry it). >> >> Anyway - I have attached a change set that changes how smart characters work - instead of turning them off because half of the time they do the wrong thing for me and I madly press delete, I wanted to preserve the other half of the time when I'm entering new code and they give me a helpful template. >> >> My proposed fix is for the following scenario - if I go to add an extra bracket around an expression (becuase I later realise that I need to designate a keyword expression) I get two brackets - and then I backspace and they both go, so then I do it again and press delete... Instead I think there is a heuristic which says that says if you type a smart character with the cursor next to a non-whitespace item, you probably don't want the matching character. e.g. >> >> 5 max: 4 > 3 ifTrue: [] {cursor here} - and I click next to the 4 (or the 5) to put the bracket and I get 2, and I really only want one. >> >> My patch tries to address this. >> >> I also didn't see any test cases for this stuff (and possibly some could be written - should I try to do that too?). >> >> Tim > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Aug. 5, 2010

[Pharo-project] XML Parser, Monticello and unicode?

by Norbert Hartl

I'm trying to port the newest XML Parser from squeaksource to gemstone. In XML-Parser-AlexandreBergel.73 there is a unicode test introduced with a longer unicode xml snippet. From this release on I cannot load or merge anything. Besides that the xml snippet looks very strange it loads in pharo but not in gemstone. Unpacking the mcz on the console and examine the content showed that the encoding is indeed weird. I don't know what it is but it is neither ascii nor utf-8. Pharo loaded the snippet into a WideString instance. How does monticello handle WideString instances when written to a file? Norbert

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Dale Henrichs

Javier, I agree with Stef, that duplication isn't an issue - the duplicated bits are static. An individual developer has many routes for building/configuring an application that runs on multiple versions/platforms, but the idea of "metacello universes" is aimed at helping _users_ figure out what configurations are "known to work in a particular version." The repository per release idea has very few moving parts, can be done now, and addresses the main problem, so it should be done. On the other hand, we shouldn't stop looking for better ways to "skin the cat":) Dale Javier PimÃ¡s wrote: > Maybe I saying nonsense, if that is the case just ignore me but... why > have many packages that do almost exactly the same? Aren't you going to > get a lot of repeated code lying around in different packages? ie. I > think most packages have almost exactly the same baselines for pharo1.x. > Maybe it's possible to call the methods baselineXXForPharoXX and let > them stay in the same class and package? Or maybe adding other pragma to > specify which pharo version each baseline/version describes. I'm sure > there could be other solutions. That way you'd have all the > configurations in the same place and also reuse code if needed instead > of duplicating it. > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com > <mailto:dhenrich@vmware.com>> wrote: > > Miguel, > > I think that this kind of approach makes lots of sense ... I've > toyed with the idea of a "white list" of configuration versions, but > someone would have to be responsible for maintaining the "white > list" and the users would have to responsible for using the "white > list" ... > > A repository per version is very simple and gives the maintainer > flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > > El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov escribiÃ³:> > Why there should be repository per release? As i know > MetacelloConfiguration already contains information about > compatible > Pharo versions. > > > Because is cleaner and as the releases of Pharo diverge a lot > more, the > code to install package becomes full of conditionals to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any pharo 1.0, > 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and > DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals an several > variations of preDoits and postDoits and test what version image is > ConfigurationOfMagma is being ran. After a couple of hours I > gave up. > > The correct solution is to have a specific ConfigurationOfMagma > for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update the > ConfigurationOfXXX without disturbing or broke the stable ones. > - It permits the ConfigurationOfXXX code to remain clean, without a > conditionals for every posible combination of release image > version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to decide > when to > stop supporting old version of a certain package by deleting the old > versionXX: methods of the ConfigurationOfXXX in the newer pharo > releases. Not always is good to be able to install each and every > version of a package in the newest release of pharo (maybe even old > versions won't work in the new releases, like the menu registration > issue or classes that doesn't belong to the core image) > - It permits to issue maintenance ConfigurationOfXXX releases for a > stable or "old-stable" image releases, without altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez <miguel.coba(a)gmail.com > <mailto:miguel.coba@gmail.com>>: > > El miÃ©, 04-08-2010 a las 11:46 +0200, Torsten Bergmann > escribiÃ³: > > Hi Miguel, > > hey, nice! If we follow this convention then it is > easy to implement > a universe browser that selects the correct universe > repo and > displays all loadable versions. Loading stuff should > just be > a few clicks away - I personally hate all this > MC/Gofer typing ... > > Attached is a quick/simple implementation of such a > browser: > > Mann, Sie sind Ã¼ber schnell! > > I tested it in PharoCore 1.0 and worked after a few > changes, but the > interface is cool. +1 to aim it be the default universe > browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't register on menu > because of the > lacking pragmas) > - UniverseBrowser pharoUniverse returns PharoCore1.0 > instead of Pharo10 > to build the universe name. This could be changed in two > ways: > - Add a system property that states the image repository: > SystemVersion current universeName "Returns Pharo10 > for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the gofer package I > uploaded to > PharoInbox (if it is approved, so there is only a unique > source for > converting image version string to universe names) > > Other than that, I like the browser. > > > > - file in the attached changeset (I tried in Pharo > 1.2) > - open via World menu -> "Universe Browser" > - select the configuration you want and from the > context menu choose > -- "Load configuration" -> only > the config is loaded > -- "Load configuration and latest version" -> the > config and lates version is loaded > > Have fun! I used Pharo 1.2 - should work in Pharo > 1.0 and 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > <mailto:Pharo-project@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 > <mailto:Pharo-project@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 > <mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires >

Aug. 5, 2010

Re: [Pharo-project] [ANN] Pharo Metacello Universes

by Miguel Enrique CobÃ¡ MartÃnez

El miÃ©, 04-08-2010 a las 23:32 -0300, Javier PimÃ¡s escribiÃ³: > Maybe I saying nonsense, if that is the case just ignore me but... why > have many packages that do almost exactly the same? Aren't you going > to get a lot of repeated code lying around in different packages? ie. > I think most packages have almost exactly the same baselines for > pharo1.x. Maybe it's possible to call the methods baselineXXForPharoXX > and let them stay in the same class and package? Or maybe adding other > pragma to specify which pharo version each baseline/version describes. > I'm sure there could be other solutions. That way you'd have all the > configurations in the same place and also reuse code if needed instead > of duplicating it. Clarity. As is very likely that different releases of a package will have distinct requirements in: - dependencies - preinstall/postinstall actions - registering with system services (menu, mail systems, sockets, startup/stop list) - number of monticello packages composing the package you're installing - use of system infraestructure (announcements, transcript, menus, help system) it will be a nightmare to have code to cope with all those conditions in a single monolithic giant metacello package, even if metacello is capable of do it. What if after 4 years of development the package has had 15 releases, that will means that you'll have possibly 15 baselines/predoits/postdoits all listing in the method pane of the browser. To someone trying to understand the configuration, it will be a lot of junk to discard before he understand only the bits that matter for the release he is interested in. So, it is healthy to have a distinct configuration in each release (even if in the current release started as a copy of the previous release configuration), to crop the things the _maintainer_ thinks are not needed anymore or simply that he doesn't want to maintain anymore. All the software has a lifetime and distinct repositories gives us the possibility to determine the time to end support for a given release Cheers > > Regards, > Javier. > > On Wed, Aug 4, 2010 at 3:18 PM, Dale Henrichs <dhenrich(a)vmware.com> > wrote: > Miguel, > > I think that this kind of approach makes lots of sense ... > I've toyed with the idea of a "white list" of configuration > versions, but someone would have to be responsible for > maintaining the "white list" and the users would have to > responsible for using the "white list" ... > > A repository per version is very simple and gives the > maintainer flexibility in managing releases. > > Dale > > > Miguel Enrique CobÃ¡ MartÃnez wrote: > > > El miÃ©, 04-08-2010 a las 19:52 +0400, Andrey Larionov > escribiÃ³: > Why there should be repository per release? As > i know > MetacelloConfiguration already contains > information about compatible > Pharo versions. > > Because is cleaner and as the releases of Pharo > diverge a lot more, the > code to install package becomes full of conditionals > to handle the > distinct issues with each pharo release. > For example, Magma. Magma 1.1r1 worked good in any > pharo 1.0, 1.1 and > 1.2. > But Magma 1.1r2 doesn't work anymore on Pharo1.0 > because Pharo 1.0 > doesn't have the classes DirectoryEntryDirectory and > DirectoryEntryFile > that are used by the new magma version. > So I had to modify the configuration with conditionals > an several > variations of preDoits and postDoits and test what > version image is > ConfigurationOfMagma is being ran. After a couple of > hours I gave up. > > The correct solution is to have a specific > ConfigurationOfMagma for each > released pharo version. > This have benefits also: > - It permits the unstable repository to heavily update > the > ConfigurationOfXXX without disturbing or broke the > stable ones. > - It permits the ConfigurationOfXXX code to remain > clean, without a > conditionals for every posible combination of release > image version and > package to be installed version > - It permits the maintainer of a ConfigurationOfXXX to > decide when to > stop supporting old version of a certain package by > deleting the old > versionXX: methods of the ConfigurationOfXXX in the > newer pharo > releases. Not always is good to be able to install > each and every > version of a package in the newest release of pharo > (maybe even old > versions won't work in the new releases, like the menu > registration > issue or classes that doesn't belong to the core > image) > - It permits to issue maintenance ConfigurationOfXXX > releases for a > stable or "old-stable" image releases, without > altering the > configurationOfXXX in other repositories > Cheers > > 2010/8/4 Miguel Enrique CobÃ¡ MartÃnez > <miguel.coba(a)gmail.com>: > El miÃ©, 04-08-2010 a las 11:46 +0200, > Torsten Bergmann escribiÃ³: > Hi Miguel, > > hey, nice! If we follow this > convention then it is easy to > implement > a universe browser that > selects the correct universe > repo and > displays all loadable > versions. Loading stuff should > just be > a few clicks away - I > personally hate all this > MC/Gofer typing ... > > Attached is a quick/simple > implementation of such a > browser: > > Mann, Sie sind Ã¼ber schnell! > > I tested it in PharoCore 1.0 and > worked after a few changes, but the > interface is cool. +1 to aim it be the > default universe browser in 1.2. > Simple, to the point. > In Pharo 1.0 I had: > > - Open it with Universe open (doesn't > register on menu because of the > lacking pragmas) > - UniverseBrowser pharoUniverse > returns PharoCore1.0 instead of > Pharo10 > to build the universe name. This could > be changed in two ways: > - Add a system property that states > the image repository: > SystemVersion current universeName > "Returns Pharo10 for image > releases 1.0, 1.0.1, 1.0.5, etc) > - Use the equivalent method in the > gofer package I uploaded to > PharoInbox (if it is approved, so > there is only a unique source for > converting image version string to > universe names) > > Other than that, I like the browser. > > > > - file in the attached > changeset (I tried in Pharo > 1.2) > - open via World menu -> > "Universe Browser" > - select the configuration > you want and from the context > menu choose > -- "Load configuration" > -> only the config is loaded > -- "Load configuration and > latest version" -> the config > and lates version is loaded > > Have fun! I used Pharo 1.2 - > should work in Pharo 1.0 and > 1.1 too > (havent tested). > > Bye > T. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 > > > > -- > Javier PimÃ¡s > Ciudad de Buenos Aires > _______________________________________________ > 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

Aug. 5, 2010

[Pharo-project] Analog to Dolphin's CompositePresenter

by Schwab,Wilhelm K

Gary, all, I am far from comfortable with Polymorph design and programming, but I have managed stick some controls on standard windows. Now I need to do something that would benefit from composition of an image and a selection mask into something that allows the mask to be edited while "scrubbing" over the image. Then those get paired, and then the pairs go into sequences. The pairing can be done with tabs, and maybe a "copy from peer" button. I think I can manage that. My question is on how to make what in Dolphin is called a CompositePresenter, which are useful critters. They are not directly tied to a top-level shell, but sending #show to them will create just that, mostly for testing purposes. Is there already something like this in Polymorph? ComposableMorph might be a place to start?? Is there a better way? Bill

Aug. 5, 2010