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

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

by StÃ©phane Ducasse

On Mar 21, 2010, at 5:01 PM, Adrian Lienhard 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. This is better like that. Stef > > 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 > > > _______________________________________________ > 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] MIT strikes back (was Re: [smalltalk-research] Re: [Esug-list] Google Summer Of Code 2010 news!!!)

by Bryce Kampjes

On Thu, 2010-03-11 at 16:31 -0600, Chris Muller wrote: > Well, I certainly care.. Stef wasn't remarking about license rights, > he said didn't understand the smiley face. Frankly, I don't either. > After years of teasing from Bryce and now this? What a crushing > disappointment. I'm still here.... And still making progress though slowly. Bryce

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Marcus Denker

On Mar 21, 2010, at 9:25 PM, Marcus Denker wrote: > > Hmm... I think I will commit this question as a low-priotiy process to my subconciouness... this is a *real* interesting question. Putting code *everywhere* makes no sense. (esp. when generalizing to > not just classes, but all objects). > Thing to think about: Yes, this is what reflection (or for some people AOP) is all about... > And isn't a class-on-disk nevertheless a class? If I ask the system for all classes, why would it omit those that are by chance on Disk? Are those suddenly "not classes" anymore? > That is a *real* propblem. Imagine we generalize the problem to any object graph. What does that mean? Will students disappear from a course because the objects describing them happen to be swapped out on disk? This makes no sense... the place where an object is stored should have *no* influence on the structure of objects that I see. It's should be invisible and hidden. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Marcus Denker

On Mar 21, 2010, at 9:14 PM, Adrian Lienhard wrote: >> >> >> We already removed the *gently variants for iterating over subclasses, for example. or the "ifPresentAndInMemory" things.... > > Yes, I did some experiments with it lately and managed to create 4MB images. Cases which are not protected are indeed a problem. > Nice! >>> I would like to keep that working and extract it with the image segments code into an external package. How to do this cleanly is an interesting question, though... >>> >> >> I think we should ask the question: Do we intent to *use* this mechanism *at all* the next 5 years? > > Probably not. Nevertheless, I think its a nice idea but if it is not properly working the chances are small anybody will use. > Yes. But it is clear that Mariano has to come up with a workable perfect solution within 3 years anyway ;-) hehehe :-) > In any case, the question of how this *could* be factored out in a clean way is interesting if we want to further strip and modularize the image. It seems we are missing appropriate abstractions to modify from external packages behavior like the #isInMemory sends. Overrides are an unsatisfactory solution. So there is a limitation to the kind of code can be made external packages. Hmm... I think I will commit this question as a low-priotiy process to my subconciouness... this is a *real* interesting question. Putting code *everywhere* makes no sense. (esp. when generalizing to not just classes, but all objects). And isn't a class-on-disk nevertheless a class? If I ask the system for all classes, why would it omit those that are by chance on Disk? Are those suddenly "not classes" anymore? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Adrian Lienhard

On Mar 21, 2010, at 20:49 , Marcus Denker wrote: > > On Mar 21, 2010, at 8:40 PM, Adrian Lienhard wrote: > >> On Mar 21, 2010, at 19:50 , Marcus Denker wrote: >> >>> >>> Yes... #isInMemory is clearly not needed anymore. >> >> Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. >> > > > But was this ever working? Was this ever *used* the last 10 years? Are actually all cases covered? So are there enough #isInmemory checks to not end up with loading > everything anyways? > > We already removed the *gently variants for iterating over subclasses, for example. or the "ifPresentAndInMemory" things.... Yes, I did some experiments with it lately and managed to create 4MB images. Cases which are not protected are indeed a problem. >> I would like to keep that working and extract it with the image segments code into an external package. How to do this cleanly is an interesting question, though... >> > > I think we should ask the question: Do we intent to *use* this mechanism *at all* the next 5 years? Probably not. Nevertheless, I think its a nice idea but if it is not properly working the chances are small anybody will use. In any case, the question of how this *could* be factored out in a clean way is interesting if we want to further strip and modularize the image. It seems we are missing appropriate abstractions to modify from external packages behavior like the #isInMemory sends. Overrides are an unsatisfactory solution. So there is a limitation to the kind of code can be made external packages. > > -- > 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

March 21, 2010

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

by Adrian Lienhard

Dale, Indeed, tags such as pharo1.0, pharo1.1, pharo1.2, etc. will likely be needed for some packages when we have universes for different Pharo versions. Cheers, Adrian On Mar 20, 2010, at 20:45 , Dale Henrichs wrote: > 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 > > _______________________________________________ > 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] isInMemory :)

by Marcus Denker

On Mar 21, 2010, at 8:40 PM, Adrian Lienhard wrote: > On Mar 21, 2010, at 19:50 , Marcus Denker wrote: > >> >> Yes... #isInMemory is clearly not needed anymore. > > Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. > But was this ever working? Was this ever *used* the last 10 years? Are actually all cases covered? So are there enough #isInmemory checks to not end up with loading everything anyways? We already removed the *gently variants for iterating over subclasses, for example. or the "ifPresentAndInMemory" things.... > I would like to keep that working and extract it with the image segments code into an external package. How to do this cleanly is an interesting question, though... > I think we should ask the question: Do we intent to *use* this mechanism *at all* the next 5 years? -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 21, 2010

Re: [Pharo-project] isInMemory :)

by Mariano Martinez Peck

> > > > Yes... #isInMemory is clearly not needed anymore. > > Well... it is needed for the swapping out of classes. If we remove > #isInMemory, we should also remove the whole image segment stub mechanism > because it becomes useless without the isInMemory protection. > > I didn't ask before, just because I was not sure the answer. I am most in Adrian thoughts than Stef. I should check with a bit of time. > I would like to keep that working and extract it with the image segments > code into an external package. How to do this cleanly is an interesting > question, though... > > Yes. That's an interesting point. Because you can put ImageSegment in a separate project without too much problems. The problems are with things like this where you have to put code very deep. And this is usually done in a hacky way. I don't know which is the solution here. But I would like if Pharo have a clean way where you can extend or similar such behavior. > Cheers, > Adrian > > > > > I have a changeset that I will upload to the bug tracker. > > > > Marcus > > > > > > -- > > 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 > > > _______________________________________________ > 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] isInMemory :)

by Adrian Lienhard

On Mar 21, 2010, at 19:50 , Marcus Denker wrote: > > On Mar 20, 2010, at 3:46 PM, stephane ducasse wrote: > >> Mariano >> >> I was wondering (since we already removed a lot of the behavior related to inMemory) if we could not remove is in >> >> traitNames >> "Answer a SortedCollection of all traits (not including class-traits) names." >> | names | >> names := OrderedCollection new. >> self do: >> [:cl | (cl isInMemory >> and: [(cl isKindOf: Trait) >> and: [(cl name beginsWith: 'AnObsolete') not]]) >> ifTrue: [names add: cl name]]. >> ^ names >> >> and friend >> > > Yes... #isInMemory is clearly not needed anymore. Well... it is needed for the swapping out of classes. If we remove #isInMemory, we should also remove the whole image segment stub mechanism because it becomes useless without the isInMemory protection. I would like to keep that working and extract it with the image segments code into an external package. How to do this cleanly is an interesting question, though... Cheers, Adrian > > I have a changeset that I will upload to the bug tracker. > > Marcus > > > -- > 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

March 21, 2010

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

by Adrian Lienhard

On Mar 21, 2010, at 17:53 , Miguel Enrique CobÃ¡ Martinez wrote: > El dom, 21-03-2010 a las 12:48 +0100, Adrian Lienhard escribiÃ³: >> 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 > > > In tht pharo-project.org page, in the section Current Status: RC3, the > text says: "a second release candidate", shouldn't be "a third release > candidate"? Thanks for noting, I fixed it. Adrian

March 21, 2010