- Pharo-dev - lists.pharo.org

[Pharo-project] [ANN 1.1] prebuild Core#11284
by Marcus Denker March 22, 2010

March 22, 2010

https://gforge.inria.fr/frs/download.php/26693/PharoCore-1.1-11284-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs March 21, 2010

March 21, 2010

George, At the moment there is no overall way to do that for Pharo. For GemStone I have attributes for specific versions, so for GemStone I can write a spec like this: spec for: #common do: [...]. spec for: #gemstone do: [...]. spec for: #'gs2.4.x' do: [...]. spec for: #'gs3.x' do: [...]. So I can specific packages that are only loaded in GemStone 2.4 or GemStone 3.0. For Pharo I would imagine doing something like the following: spec for: #common do: [...]. spec for: #squeakCommon do: [...]. spec for: #pharo do: [...]. spec for: #'pharo1.0' do: [...]. spec for: #'pharo1.1' do: [...]. Then packages that were specific to 1.0 and 1.1 can be specified. I haven't added this to Metacello for Pharo, because I was kind of waiting for the need to appear rather than add a feature that noone needs, so I've been waiting for someone to ask for the feature:) Dale ----- "George Herolyants" <george.herolyants(a)gmail.com> wrote: | Thanks for the explanation, Dale! | | May be it's obvious and I'm asking stupid questions but then I don't | understand how can I specify in my configuration the differences | between the versions of the target platform? | | 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: | > George, | > | > The mcz files containing the Metacello configurations _are_ copied, | but the configuration itself is not modified in the scheme. | > | > The idea of using different repositories is to indicate which of the | many different projects are _expected_ or _known_ to work in Pharo1.1 | or Pharo1.0. | > | > For GemStone, I have createed a GemSource MetacelloRepository and I | have copied the metacello configurations that I know have been ported | to GemStone. I've done this so that folks can know what is supported. | I make sure that all of the tests run green and that all of the | configs in the GemSource MetacelloRepository can be loaded. | > | > It does not stop someone from loading a configuration into GemStone | that isn't in the GemSource MetacelloRepository, but if you do and run | into trouble, my answer will probably be that it hasn't been ported | yet. | > | > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > | > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > | > Dale

2 1

Re: [Pharo-project] [Pharo-users] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by Dale Henrichs March 21, 2010

March 21, 2010

Mariano, I am seriously considering releasing 1.0-beta.25 today ... I have smacked the heck out Metacello over the last three days without issues so I'm thinking I can let this puppy out the door:)...Especially if it will clean up the release process... One other point I have noticed is that the following configurations aren't pointing to the correct repository: ConfigurationOfOmniBrowser ConfigurationOfRefactoringBrowser ConfigurationOfOCompletion ConfigurationOfShout ConfigurationOfProfStef They all reference the package-cache instead of SqueakSource MetacelloRepository. I'm assuming this is because they were in your package-cache when you did the build. I think this is happening because of a recent change in the sorting order for Gofer ... For the build process you may want to either make sure your package-cache is empty or use disablePackageCache in the places where you explicitly load a Configuration or perhaps something else? Dale ----- "Mariano Martinez Peck" <marianopeck(a)gmail.com> wrote: | > | > I see that the installScript uses ConfigurationOfMetacello from | > gemsource metacello repository instead of Metacello repository. | Given | > that this will be the final release of 1.0, shouldn't we copy | > ConfigurationOfMetacello to squeaksource/MetacelloRepository so that | the | > package registered in monticello is this instead of the gemstone | one. | > This repo for ConfigurationOfMetacello overrides the one of | PharoCore | > that points to squeaksource. | > | > Dale, can you put this version in squeaksource. The release is very | > close and anyway it will be shipped in Pharo dev 1.0, so will reach | a | > lot of people, even if not on squeaksource | > | > | Yes. This is because I added the ImageForDevelopers in the group. With | that, | when running headless I have the problem with the progress Bar. | Then, i needed to use the silntly method, which is in Metacello | beta.25 | which is not released yet. That's why I have to put the other one. | | Don't worry that beta.25 will be then correctly uploaded and released. | After | that, the installScript will be even simpler as I won't need to | install | Metacello manually, but with the ensureMetacello ;) | | Cheers | | Mariano | | | | > Cheers | > > | > > Mariano | > > | > > _______________________________________________ | > > Pharo-users mailing list | > > Pharo-users(a)lists.gforge.inria.fr | > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users | > | > -- | > 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

2 3

Re: [Pharo-project] [Pharo-users] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by Dale Henrichs March 21, 2010

March 21, 2010

3 4

[Pharo-project] [BetaTesting] [ANN] Pharo-1.0-10515-rc3dev10.03.1
by Mariano Martinez Peck March 21, 2010

March 21, 2010

Hi folks. We are proud to announce the (hopefully) last RC3 for Pharo 1.0. This image is based in PharoCore-1.0-10515rc3. The image also contain lot of fixes and improvements of external packages: These, are the fixed issues of the external tools: OB: Issues 1891, 1748, 1670, 1667, 1705, 1667 O2: issues 1887, 1312, 1429, 1886, 2073 New Inspector: issues 1783, 1499 Refactoring Browser: issue 2108 The link is: https://gforge.inria.fr/frs/download.php/26680/Pharo-1.0-10515-rc3dev10.03.… Cheers Mariano

4 9

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs March 21, 2010

March 21, 2010

Miguel, Yes it will be interesting to see how this situation evolves over time. OmniBrowser is a good case in point right now ... There is very little commonality in the configurations for Squeak/Pharo/GemStone. The GemTools package is intended to run on both Squeak and Pharo and it depends upon OmniBrowser so I use a common configuration for both, over time I expect that GemTools will be pointing at different repositories for the ConfigurationOfOmniBrowser. Having different branches for ConfigurationOfOmniBrowser makes much more sense than trying to keep a single configuration in synch for essentially different projects... Dale ----- "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> wrote: | El sÃ¡b, 20-03-2010 a las 14:12 -0700, Dale Henrichs escribiÃ³: | > Miguel, | > | > I should emphasize that conditional load/compile in Metacello is a | pragmatic feature. I don't disagree that the combinatorials can | quickly spiral out of control, but for the short term there is no | alternative. I won't argue that conditionals _should_ be included in | the package management layer, either. | > | > As with all other problems there are several ways to "skin the cat". | I _could_ have extended Monticello to have platform-specific code | components. I _could_ have added conditional compilation to the | Smalltalk compiler. In many ways those solutions are uglier than | putting conditional loading into Metacello:) | > | > In the end I added the minimum set of features to Metacello that | solved the problems that I was facing on a daily basis and conditional | load/compile was high on my list. | > | > With that said, I encourage and support any effort aimed at avoided | the use of conditionals:) | | | Dale, I agree with your arguments and I am not criticizing or | commenting | about the features of Metacello, I am a happy user of Metacello as | you | know, and it is very easy to use it. | | I know that the conditionals are a fundamentally pragmatic solution | (an | this is good, as that is the way that most real world problems are | solved, by being pragmatic and solving the problem, not caring if it | is | pure design or not. :) | | But I think that with enough time (or maybe never, miracles happen, | they | say), Pharo and Squeak will be different enough that will be | difficult | that a universes scheme can work for several forks or Smalltalk | versions. I think that they will need each one its own package set. | For | example, | | squeak5.0 universe will have package A, B and D | pharo3.0 universe will have package B, C, H and K | | with package B being a ConfigurationOfB that has been copied to both | repositories and that maybe have parted ways and both of them have | different versions methods, for example: | squeak5.0 has | ConfigurationOfB version1 | ConfigurationOfB version2 | ConfigurationOfB version3 | | and | pharo3.0 has | ConfigurationOfB version1 | ConfigurationOfB version2 | ConfigurationOfB version3 | ConfigurationOfB version4 | ConfigurationOfB version5 | | And maybe even version3 is different in squeak5.0 and pharo3.0 | universes. | | But we are theorizing, so far Metacello is working very good, we'll | attack the problem when is presented. | So, keep the good job you are doing Dale. | | Cheers | > | > Dale | > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | > | > | Miguel, | > | | > | Keep in mind that the conditional load code in Metacello is the | moral | > | equivalent of #ifdef in C. The debian package universe has the | > | advantage of pushing the conditional compilaton of _source code_ | down | > | a level. | > | | > | With Metacello, I purposely use the version attribute for | conditional | > | loading of code (as close to a conditional compile as you can | get). In | > | Metacello we do the load and the compile... | > | | > | Where common code can be written it should be, but as versions | and | > | platforms diverge in their API, something has to give ... If you | can | > | afford to seal off the source code for an older version then | that's | > | fine, but in a project that is under active development and is | > | _expected_ to run on multiple versions of multiple platforms one | must | > | resort to "conditional loading" - conditional loading is what | makes | > | Grease work, BTW. | > | | > | When you look at the universe of #ifdef in C, you see that some of | the | > | ifdefs are adhoc and some of the ifdefs are based upon platform | > | constants ... and that is what the metacello attributes give you | ... | > | Right now, you can create project-specific attributes and there | are a | > | handful of pre-defined attributes ... As I said, I am | purposefully | > | avoiding adding new pre-defined attributes willy nilly, but | anticipate | > | that some will be needed (GemStone3.0 and GemStone2.4 and even | > | GemStone2.3 need to have difference code compiled/loaded for | projects | > | that are in active developement and expect to be run on all three | > | versions of GemStone the low-level apis are different and | different | > | code has to be written for each different version). | > | | > | Having the conditional compile/load component in Metacello isn't | > | necessarily an elegant feature, but given that no other part of | the | > | Smalltalk system currently provides a conditional compile/load, I | > | added it to Metacello. Since I am maintaining common software on | three | > | different versions of gemstone, I consider it a requirement. | > | | > | If and when an elegant conditional compile/load solution becomes | > | available, then this particular feature of Metacello can be | allowed to | > | die in peace. | > | | > | I will agree that the MYSQL maintainers don't worry whether their | > | executables load on Ubuntu or Fedora, but I can almost guarantee | you | > | that they have conditional code that makes sure that there their | code | > | will compile/build on the different OSes. | > | | > | The ifdef world is as ugly as it comes, but it does exists for a | > | pretty good reason. | > | | > | | > | Dale | > | ----- "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> | wrote: | > | | > | | El sÃ¡b, 20-03-2010 a las 21:54 +0300, George Herolyants | escribiÃ³: | > | | > Thanks for the explanation, Dale! | > | | > | > | | > May be it's obvious and I'm asking stupid questions but then | I | > | | don't | > | | > understand how can I specify in my configuration the | differences | > | | > between the versions of the target platform? | > | | > | > | | > 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: | > | | > > George, | > | | > > | > | | > > The mcz files containing the Metacello configurations _are_ | > | | copied, but the configuration itself is not modified in the | scheme. | > | | > > | > | | > > The idea of using different repositories is to indicate | which of | > | | the many different projects are _expected_ or _known_ to work | in | > | | Pharo1.1 or Pharo1.0. | > | | > > | > | | > > For GemStone, I have createed a GemSource | MetacelloRepository | > | and | > | | I have copied the metacello configurations that I know have | been | > | | ported to GemStone. I've done this so that folks can know what | is | > | | supported. I make sure that all of the tests run green and that | all | > | of | > | | the configs in the GemSource MetacelloRepository can be loaded. | > | | > > | > | | > > It does not stop someone from loading a configuration into | > | | GemStone that isn't in the GemSource MetacelloRepository, but if | you | > | | do and run into trouble, my answer will probably be that it | hasn't | > | | been ported yet. | > | | > > | > | | > > The same thing can apply to Squeak, but someone would have | to | > | step | > | | up to testing/approving metacello configurations that run with | the | > | | various versions. | > | | > > | > | | > > Without this extra step of approval/testing, it's difficult | for | > | | someone that doesn't have their finger on the pulse of the | latest | > | and | > | | greatest happenings to know what to expect ... | > | | > > | > | | > > Dale | > | | | > | | The problem is, you are thinking in upstream development, and | the | > | | idea | > | | of universes is that each package has maintainer for each | platform | > | | involved. This maintainer can be the same person that the | upstream | > | | developer, but it can also be someone else that make sure that | a | > | | given | > | | package load correctly in *a give* fork. | > | | | > | | Making an analogy, what you are saying is that the maintainers | of | > | | MySQL | > | | deb package in Debian should be worried about the package not | > | loading | > | | in | > | | Ubuntu or Fedora. That is not the case. The upstream code can | run in | > | | all | > | | of three distros, but the packages specific to each one (.deb | in | > | | debian | > | | and ubuntu and .rpm in fedora) *must* be build and tested for | their | > | | own | > | | maintainers. The upstream developers can rightfully don't give | a | > | dime | > | | about where is package is being used and maybe they only | release | > | | a .tar.gz and know nothing (but also they don't stop efforts) | about | > | | external package for specific distros. | > | | | > | | So, returning to your question, maybe sometime in the future | Squeak | > | | (if | > | | interested) will have to build its own repositories with its | own | > | | universes and put there the configurations that are proved to | work | > | in | > | | Squeak. | > | | | > | | Right now as Pharo and Squeak are very similar the | configurations | > | | (and | > | | the #common you mention) works, but this isn't going to scale | for | > | | different Smalltalks in the long term. | > | | | > | | Cheers | > | | > | > | | > _______________________________________________ | > | | > 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 | | -- | Miguel CobÃ¡ | http://miguel.leugim.com.mx

1 0

[Pharo-project] [paper] Language Boxes. Bending the Host Language with Modular Language Changes
by Marcus Denker March 21, 2010

March 21, 2010

Lukas Renggli, Marcus Denker, and Oscar Nierstrasz: Language Boxes. Bending the Host Language with Modular Language Changes In: Software Language Engineering: Second International Conference, SLE 2009, Denver, Colorado, October 5-6, 2009, LNCS 5969 p. 274â293, Springer, 2009. Abstract ====== As domain-specific modeling begins to attract widespread acceptance, pressure is increasing for the development of new domain-specific languages. Unfortunately these DSLs typically conflict with the grammar of the host language, making it difficult to compose hybrid code except at the level of strings; few mechanisms (if any) exist to control the scope of usage of multiple DSLs; and, most seriously, existing host language tools are typically unaware of the DSL extensions, thus hampering the development process. Language boxes address these issues by offering a simple, modular mechanism to encapsulate (i) compositional changes to the host language, (ii) transformations to address various concerns such as compilation and highlighting, and (iii) scoping rules to control visibility of language extensions. We describe the design and implementation of language boxes, and show with the help of several examples how modular extensions can be introduced to a host language and environment. http://scg.unibe.ch/archive/papers/Reng09cLanguageBoxes.pdf -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] about nextPut: returned argument
by stephane ducasse March 21, 2010

March 21, 2010

hi guys I saw that nicolas fixed all the add: ... in squeak to return the argument and I like the idea I created an issue. Now I saw that nicolas fixed also nextPut: Item was changed: ----- Method: DummyStream>>nextPut: (in category 'accessing') ----- nextPut: aByte + "do nothing" + ^aByte! - "do nothing"! I checked the ANSI standard and this is unspecified. So I was wondering what the others dialects are doing? What do we do? Stef

5 6

[Pharo-project] killing a runaway process
by sergio_101 March 21, 2010

March 21, 2010

in order to figure out another process.. i loaded up a project to pull in twitter statuses. it looks as if it's broken, as it just keeps feeding stuff to the transcript, with no end in sight.. the first time i tried this, i realized that i hadn't saved my image for a half hour, so i lost a little bit of changes... once i realized what was happening, i realized that my image was seized up, with info dumping to the transcript.. it would be really nice if i could 'control-c' the workspace and clear it out.. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

2 1

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)
by Dale Henrichs March 21, 2010

March 21, 2010

Miguel, Keep in mind that the conditional load code in Metacello is the moral equivalent of #ifdef in C. The debian package universe has the advantage of pushing the conditional compilaton of _source code_ down a level. With Metacello, I purposely use the version attribute for conditional loading of code (as close to a conditional compile as you can get). In Metacello we do the load and the compile... Where common code can be written it should be, but as versions and platforms diverge in their API, something has to give ... If you can afford to seal off the source code for an older version then that's fine, but in a project that is under active development and is _expected_ to run on multiple versions of multiple platforms one must resort to "conditional loading" - conditional loading is what makes Grease work, BTW. When you look at the universe of #ifdef in C, you see that some of the ifdefs are adhoc and some of the ifdefs are based upon platform constants ... and that is what the metacello attributes give you ... Right now, you can create project-specific attributes and there are a handful of pre-defined attributes ... As I said, I am purposefully avoiding adding new pre-defined attributes willy nilly, but anticipate that some will be needed (GemStone3.0 and GemStone2.4 and even GemStone2.3 need to have difference code compiled/loaded for projects that are in active developement and expect to be run on all three versions of GemStone the low-level apis are different and different code has to be written for each different version). Having the conditional compile/load component in Metacello isn't necessarily an elegant feature, but given that no other part of the Smalltalk system currently provides a conditional compile/load, I added it to Metacello. Since I am maintaining common software on three different versions of gemstone, I consider it a requirement. If and when an elegant conditional compile/load solution becomes available, then this particular feature of Metacello can be allowed to die in peace. I will agree that the MYSQL maintainers don't worry whether their executables load on Ubuntu or Fedora, but I can almost guarantee you that they have conditional code that makes sure that there their code will compile/build on the different OSes. The ifdef world is as ugly as it comes, but it does exists for a pretty good reason. Dale ----- "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> wrote: | El sÃ¡b, 20-03-2010 a las 21:54 +0300, George Herolyants escribiÃ³: | > Thanks for the explanation, Dale! | > | > May be it's obvious and I'm asking stupid questions but then I | don't | > understand how can I specify in my configuration the differences | > between the versions of the target platform? | > | > 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: | > > George, | > > | > > The mcz files containing the Metacello configurations _are_ | copied, but the configuration itself is not modified in the scheme. | > > | > > The idea of using different repositories is to indicate which of | the many different projects are _expected_ or _known_ to work in | Pharo1.1 or Pharo1.0. | > > | > > For GemStone, I have createed a GemSource MetacelloRepository and | I have copied the metacello configurations that I know have been | ported to GemStone. I've done this so that folks can know what is | supported. I make sure that all of the tests run green and that all of | the configs in the GemSource MetacelloRepository can be loaded. | > > | > > It does not stop someone from loading a configuration into | GemStone that isn't in the GemSource MetacelloRepository, but if you | do and run into trouble, my answer will probably be that it hasn't | been ported yet. | > > | > > The same thing can apply to Squeak, but someone would have to step | up to testing/approving metacello configurations that run with the | various versions. | > > | > > Without this extra step of approval/testing, it's difficult for | someone that doesn't have their finger on the pulse of the latest and | greatest happenings to know what to expect ... | > > | > > Dale | | The problem is, you are thinking in upstream development, and the | idea | of universes is that each package has maintainer for each platform | involved. This maintainer can be the same person that the upstream | developer, but it can also be someone else that make sure that a | given | package load correctly in *a give* fork. | | Making an analogy, what you are saying is that the maintainers of | MySQL | deb package in Debian should be worried about the package not loading | in | Ubuntu or Fedora. That is not the case. The upstream code can run in | all | of three distros, but the packages specific to each one (.deb in | debian | and ubuntu and .rpm in fedora) *must* be build and tested for their | own | maintainers. The upstream developers can rightfully don't give a dime | about where is package is being used and maybe they only release | a .tar.gz and know nothing (but also they don't stop efforts) about | external package for specific distros. | | So, returning to your question, maybe sometime in the future Squeak | (if | interested) will have to build its own repositories with its own | universes and put there the configurations that are proved to work in | Squeak. | | Right now as Pharo and Squeak are very similar the configurations | (and | the #common you mention) works, but this isn't going to scale for | different Smalltalks in the long term. | | Cheers | > | > _______________________________________________ | > 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

2 2