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

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Dale Henrichs

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

March 21, 2010

Re: [Pharo-project] [paper] Language Boxes. Bending the Host Language with Modular Language Changes

by Alexandre Bergel

Excellent! Alexandre On 20 Mar 2010, at 19:58, Marcus Denker wrote: > 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. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

March 21, 2010

Re: [Pharo-project] Getting the website ready for 1.0

by Mariano Martinez Peck

On Sun, Mar 21, 2010 at 5:01 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Thanks for the suggestions. I deleted the /getting-started page and added > the content in the side column of the home page. I added direct links to the > book and the screencast. > > Mariano, this means we need to update the links in the workspace. Please > also remove the sentence "We really need your help to fix all these issues > and to get all tests green!" because this is the case now :) > > So...what I do ? I take the same image, uncompress it, change workspace, compress, upload it again ? Regarding the links, the only thing I have to do is to remove "Getting started" ? or add something else ? > Cheers, > Adrian > > On Mar 21, 2010, at 14:01 , laurent laffont wrote: > > > Hi, > > > > "Get the Pharo By Example book" : on this page there's a lot more than > Pharo > > By Example. > > > > "Watch the Pharo Screencasts" points to > > http://www.pharo-project.org/documentation/tutorials-books > > > > I think I'd rather delete the Getting Started page and put its content at > > the top of the homepage, above Mission section. > > > > Cheers, > > > > Laurent Laffont > > > > > > On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard <adi(a)netstyle.ch> > wrote: > > > >> Hi all, > >> > >> I've updated the website content, in particular the following pages, > which > >> are linked from the welcome workspace: > >> > >> http://www.pharo-project.org/documentation/getting-started > >> http://www.pharo-project.org/documentation/tutorials-books > >> > >> If you have any suggestions to improve the website (e.g., for the FAQ), > >> please let me know! > >> > >> Cheers, > >> Adrian > >> > >> BTW, I also updated the download links to the new Pharo RC3 image > >> > >> ___________________ > >> http://www.adrian-lienhard.ch/ > >> > >> > >> _______________________________________________ > >> 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 >

March 21, 2010

Re: [Pharo-project] Getting the website ready for 1.0

by Adrian Lienhard

Thanks for the suggestions. I deleted the /getting-started page and added the content in the side column of the home page. I added direct links to the book and the screencast. Mariano, this means we need to update the links in the workspace. Please also remove the sentence "We really need your help to fix all these issues and to get all tests green!" because this is the case now :) Cheers, Adrian On Mar 21, 2010, at 14:01 , laurent laffont wrote: > Hi, > > "Get the Pharo By Example book" : on this page there's a lot more than Pharo > By Example. > > "Watch the Pharo Screencasts" points to > http://www.pharo-project.org/documentation/tutorials-books > > I think I'd rather delete the Getting Started page and put its content at > the top of the homepage, above Mission section. > > Cheers, > > Laurent Laffont > > > On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> Hi all, >> >> I've updated the website content, in particular the following pages, which >> are linked from the welcome workspace: >> >> http://www.pharo-project.org/documentation/getting-started >> http://www.pharo-project.org/documentation/tutorials-books >> >> If you have any suggestions to improve the website (e.g., for the FAQ), >> please let me know! >> >> Cheers, >> Adrian >> >> BTW, I also updated the download links to the new Pharo RC3 image >> >> ___________________ >> http://www.adrian-lienhard.ch/ >> >> >> _______________________________________________ >> 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

March 21, 2010

[Pharo-project] GSoC next steps

by Mariano Martinez Peck

Hi folks. We received several mails asking questions for the next step. So I think it is a good idea to clarify it a bit. Mentors and students, will have to register in Google GSoC website, but first we want them to be registered in our ESUG GSoC website. Why? Several reasons: 1. We are trying to approach this year GSoC on a more organized way, 2. that's why we are building that special Smalltalk GSoc website, 3. to support you, the students and the projects as best as possible. We are developing this registration in our website and it was almost finish. We will call for mentors first. We created a mailing list for all the mentors. If you are mentor, you should be there. If you are not, please contact us. We had already sent an email to mentors mailing list to invite them to register as mentors in our ESUG GSoC website. If we discover bugs during that period, they will be fixed. Once after all mentors have been successfully registered and the registration process is working correctly, then we will invite students to register also. After that, students and mentors will be registered in our website, each of them will have each other's contact information, each will have their own page for the project, etc. Once all of this is done, then mentors and students will register in the Google GSoC webpage. Finally, mentors will vote and choose the projects to be selected. Even more, if there is more than one student for the same project, the mentor will have to choose. Cheers GSoC admin team esug.gsoc.adm2010(a)gmail.com http://gsoc2010.esug.org/

March 21, 2010

Re: [Pharo-project] Getting the website ready for 1.0

by laurent laffont

Hi, "Get the Pharo By Example book" : on this page there's a lot more than Pharo By Example. "Watch the Pharo Screencasts" points to http://www.pharo-project.org/documentation/tutorials-books I think I'd rather delete the Getting Started page and put its content at the top of the homepage, above Mission section. Cheers, Laurent Laffont On Sun, Mar 21, 2010 at 12:48 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi all, > > I've updated the website content, in particular the following pages, which > are linked from the welcome workspace: > > http://www.pharo-project.org/documentation/getting-started > http://www.pharo-project.org/documentation/tutorials-books > > If you have any suggestions to improve the website (e.g., for the FAQ), > please let me know! > > Cheers, > Adrian > > BTW, I also updated the download links to the new Pharo RC3 image > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2010

[Pharo-project] Getting the website ready for 1.0

by Adrian Lienhard

Hi all, I've updated the website content, in particular the following pages, which are linked from the welcome workspace: http://www.pharo-project.org/documentation/getting-started http://www.pharo-project.org/documentation/tutorials-books If you have any suggestions to improve the website (e.g., for the FAQ), please let me know! Cheers, Adrian BTW, I also updated the download links to the new Pharo RC3 image ___________________ http://www.adrian-lienhard.ch/

March 21, 2010

Re: [Pharo-project] about nextPut: returned argument

by StÃ©phane Ducasse

Excellent! I like consistency Stef >>> This is a very minor change, but to me as important as having class >>> comments, 'at last classified' categories etc... >> >> I imagine and for me I spent time looking at your squeak changes just for exactly the same reason. >> >>> My rationale is : >>> 1) #nextPut: #nextPutAll: are just like #add: #addAll: >>> 2) that's how they historically behave >>> 3) it's good to have homogeneity in the system >> >> yes but you did not reply to my question >> GS, VA, VW, GNU? >> Because before jumping to follow you I hold down my horses for once :) > > Even WriteStream >> #nextPut: returns the argument (both primitive and non primitive version), so these changes give image-wide consistency. > > > Levente

March 21, 2010

Re: [Pharo-project] nebraska?

by StÃ©phane Ducasse

>> > > Nope. In fact, I was surprised to learn that Cobalt doesn't even use TeaTime and that the last version of Croquet that used it was around 0.3. Apparently network latency for reliable message sending of an entire 3D world was greater than expected, so it was tweaked almost out of existence, at least in its original form. I am often wrong about these things of course, so corrections are welcome. > > OTOH, even if its NOT suitable for message sending in Croquet/Cobalt, it seems intuitively obvious that it MIGHT still be viable for use in less demanding 2D P2P scenarios. > > At least, I'm hoping it will be, because honestly, SVN sucks and doesn't apply at all for some of the stuff I'm hoping to use squeak for: P2P backend for plugins in virtual world viewers to share collaborative projects, obects, physics and whatever else people can come up with. One could certainly make the case that smalltalk won''t be fast enough for the high end requirements of such use-cases, but as it stands now the infrastructure really isn't in place for testing even the lowest end (person to person collaboration without requiring a web host for clunky flash based-games and drawing apps). Imagine collaborative etoys or scrabble or whatever tunning on a prim in second life, well integrated into the SL 3D environment where the etoy is controlling a 3D environment that is used by about 1 million people per month. > > As it stands, I can use squeak to POST messages to individual objects in Second Life and control all of their programmable behavior via a seaside-rendered GUI in a HUD object. My intent is to bypass http and directly use the Second Life media plugin to render a Morphic widow or squeak desktop onto that HUD without the overhead of SVN or http or html and and thereby create the beginnings of a squeak plugin to SL. > > As an aside, while people debated the utility of making it easier to embed squeak in games and such, the SL scripting team that has been working over the past 4 years to replace the Linden Scripting Langage with the mono CLR and allow C#/etc programming of SL objects, considered using Squeak as the basis for scripting the open source Second Life viewer, and rejected it because they didn't think it a viable way to go for various reasons, all of which have been raised at one point or another in the debate about embedding squeak in general. I can imagine. When a smart guy opened Squeak in the past, his first reaction was to laugh or cry. (I do not say that against squeak - I got so burned by people looking at me in this strange way when I said that smalltalk was cool and they opened squeak in the past). > They're now planing on using mono as the basis of viewer scripting... Obvious I would say. > > Oh well, opportunities lost.. Yes and this is what we are trying to fix. Make a credible opensource smalltalk.

March 21, 2010

Re: [Pharo-project] about nextPut: returned argument

by Levente Uzonyi

On Sat, 20 Mar 2010, StÃ©phane Ducasse wrote: > > On Mar 20, 2010, at 11:00 PM, Nicolas Cellier wrote: > >> This is a very minor change, but to me as important as having class >> comments, 'at last classified' categories etc... > > I imagine and for me I spent time looking at your squeak changes just for exactly the same reason. > >> My rationale is : >> 1) #nextPut: #nextPutAll: are just like #add: #addAll: >> 2) that's how they historically behave >> 3) it's good to have homogeneity in the system > > yes but you did not reply to my question > GS, VA, VW, GNU? > Because before jumping to follow you I hold down my horses for once :) Even WriteStream >> #nextPut: returns the argument (both primitive and non primitive version), so these changes give image-wide consistency. Levente > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 21, 2010