September 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] possible TODOs...

by StÃ©phane Ducasse

> Let me add few my wishes: > > - Inspect and Explore merging into just Inspect. By extending > Explorer with remaining Inspector functionalities like editing > objects? > > - Inspect always on the same place in menus, not once at the top, > then on the middle, on the bottom... > > - same for senders/implementors > > - Integrating Monticello commands directly into code browser, in > right-click menu over packages. This really helps with code > management, I know that from VW. you should use the package browser and ask for improvement because you can start to do what you want with it. > > > - switch off halos by default, > > > - multi select by Ctrl-left click or Shift-left click (all other > windowing systems have multi select, so it is a time to introduce it > here too = a big plus for newcomers) > > > And last wish and I hope it is not too heretic: shouldn't we > "harmonize" menus between different Smalltalk dialects a bit? This > would help us the web guys a lot, we need to switch between dialects > daily. Specially with VisualWorks, which most people use besides > Squeak. And where in the era of Vasily Bykov a lot of sound > usability features were introduced. Why wouldn't introduce them here > too? > > Here is first such good usability feature: > > Do it > Print it > Inspect it > Debug it > > ... in all menus in the middle, without exception! > > > Best regards > Janko > > > Marcus Denker wrote: >> Hi, >> I was already multiple times asked for a list of specific things >> that people could work on. Here are some ideas: >> -> World menu (after applying the simplification from bugtracker >> #166) >> -> Fullscreen of/on should be rendered like soundof/on, that >> is just one entry that changes >> according to state of display. >> -> in debug the start rendering entries should only be >> rendered when flag is set. (see code it calls) >> -> Preferences contains the code of the old preferences- >> browser. Remove all code related to this. >> (see Preferences class>>preferencesControlPanel) >> -> Browser has "printOut" menu entries that just do fileOut. Remove >> those entries. >> -> Browser has entry "browse all" in system category menu. This >> makes no sense. >> -> SqueakMap stores 1.5MB of crap in the image. make changeset that >> removes SqueakMap from the image. >> (check SqueakMap default purge) >> -> registerInFlapsRegistry... called in the class side initalize, >> please remove this and the infrastructure of flaps-registering. >> -> clean up Preferences. There are many preferences that nobody >> ever changes because the >> default makes a lot of sense. These need to be removed. >> -> CurvierMorph should be merged with PolygonMorph >> -> FileList2 should be merged with FileList. >> -> TranslatedMethod is a leftover from the original Jitter of 1998. >> Needs to be removed. >> Please note, it's in the specialObjectArray! >> -> Remove PluggableDictionary, PluggableSet (these are workarounds >> for the broken hashing in Squeak. We >> will fix hashing later for real) >> -> ColorTheme and subclasses should be removed. Refactoring needed >> for all users. (maybe best done >> after polymorph is added) >> -> remove BOBTransformationMorph. Refactor, merge with >> TransformationMorph? (maybe wait till etoys is gone) >> -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe >> wait till etoys is gone) >> -> Remove world-in-world support. start by removing classes >> EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. >> -> TwoWayScrollPane shoud be removed (ScrollPane can do >> everything). Fix all useres of TwoWayScrollPane and delete class. >> -> CurrentProjectRefactoring is deprecated, yet it is referenced. >> Please fix all references (mostly just use Project current) and >> remove CurrentProjectRefactoring. >> -> Use Sophie's code to render a real pulldown menu entries on >> windows and Mac >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > Janko MivÅ¡ek > Svetovalec za informatiko > Eranova d.o.o. > Ljubljana, Slovenija > www.eranova.si > tel: 01 514 22 55 > faks: 01 514 22 56 > gsm: 031 674 565 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2008

Re: [Pharo-project] possible TODOs...

by StÃ©phane Ducasse

Good list ! - What do you think about remove bookMorph because it introduced a lot of dependencies - I will continue to work on etoy removal On Sep 21, 2008, at 2:22 PM, Marcus Denker wrote: > Hi, > > I was already multiple times asked for a list of specific things > that people could work on. Here are some ideas: > > -> World menu (after applying the simplification from bugtracker #166) > -> Fullscreen of/on should be rendered like soundof/on, that is > just one entry that changes > according to state of display. > -> in debug the start rendering entries should only be rendered > when flag is set. (see code it calls) > > -> Preferences contains the code of the old preferences-browser. > Remove all code related to this. > (see Preferences class>>preferencesControlPanel) > > -> Browser has "printOut" menu entries that just do fileOut. Remove > those entries. > > -> Browser has entry "browse all" in system category menu. This > makes no sense. > > -> SqueakMap stores 1.5MB of crap in the image. make changeset that > removes SqueakMap from the image. > (check SqueakMap default purge) > > -> registerInFlapsRegistry... called in the class side initalize, > please remove this and the infrastructure of flaps-registering. > > -> clean up Preferences. There are many preferences that nobody ever > changes because the > default makes a lot of sense. These need to be removed. > > -> CurvierMorph should be merged with PolygonMorph > > -> FileList2 should be merged with FileList. > > -> TranslatedMethod is a leftover from the original Jitter of 1998. > Needs to be removed. > Please note, it's in the specialObjectArray! > > -> Remove PluggableDictionary, PluggableSet (these are workarounds > for the broken hashing in Squeak. We > will fix hashing later for real) > > -> ColorTheme and subclasses should be removed. Refactoring needed > for all users. (maybe best done > after polymorph is added) > > -> remove BOBTransformationMorph. Refactor, merge with > TransformationMorph? (maybe wait till etoys is gone) > > -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe > wait till etoys is gone) > > -> Remove world-in-world support. start by removing classes > EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. > > -> TwoWayScrollPane shoud be removed (ScrollPane can do everything). > Fix all useres of TwoWayScrollPane and delete class. > > -> CurrentProjectRefactoring is deprecated, yet it is referenced. > Please fix all references (mostly just use Project current) and > remove CurrentProjectRefactoring. > > -> Use Sophie's code to render a real pulldown menu entries on > windows and Mac > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2008

Re: [Pharo-project] possible TODOs...

by Janko MivÅ¡ek

Hi, Let me add few my wishes: - Inspect and Explore merging into just Inspect. By extending Explorer with remaining Inspector functionalities like editing objects? - Inspect always on the same place in menus, not once at the top, then on the middle, on the bottom... - same for senders/implementors - Integrating Monticello commands directly into code browser, in right-click menu over packages. This really helps with code management, I know that from VW. - switch off halos by default, - multi select by Ctrl-left click or Shift-left click (all other windowing systems have multi select, so it is a time to introduce it here too = a big plus for newcomers) And last wish and I hope it is not too heretic: shouldn't we "harmonize" menus between different Smalltalk dialects a bit? This would help us the web guys a lot, we need to switch between dialects daily. Specially with VisualWorks, which most people use besides Squeak. And where in the era of Vasily Bykov a lot of sound usability features were introduced. Why wouldn't introduce them here too? Here is first such good usability feature: Do it Print it Inspect it Debug it ... in all menus in the middle, without exception! Best regards Janko Marcus Denker wrote: > Hi, > > I was already multiple times asked for a list of specific things that > people could work on. Here are some ideas: > > -> World menu (after applying the simplification from bugtracker #166) > -> Fullscreen of/on should be rendered like soundof/on, that is > just one entry that changes > according to state of display. > -> in debug the start rendering entries should only be rendered > when flag is set. (see code it calls) > > -> Preferences contains the code of the old preferences-browser. Remove > all code related to this. > (see Preferences class>>preferencesControlPanel) > > -> Browser has "printOut" menu entries that just do fileOut. Remove > those entries. > > -> Browser has entry "browse all" in system category menu. This makes no > sense. > > -> SqueakMap stores 1.5MB of crap in the image. make changeset that > removes SqueakMap from the image. > (check SqueakMap default purge) > > -> registerInFlapsRegistry... called in the class side initalize, please > remove this and the infrastructure of flaps-registering. > > -> clean up Preferences. There are many preferences that nobody ever > changes because the > default makes a lot of sense. These need to be removed. > > -> CurvierMorph should be merged with PolygonMorph > > -> FileList2 should be merged with FileList. > > -> TranslatedMethod is a leftover from the original Jitter of 1998. > Needs to be removed. > Please note, it's in the specialObjectArray! > > -> Remove PluggableDictionary, PluggableSet (these are workarounds for > the broken hashing in Squeak. We > will fix hashing later for real) > > -> ColorTheme and subclasses should be removed. Refactoring needed for > all users. (maybe best done > after polymorph is added) > > -> remove BOBTransformationMorph. Refactor, merge with > TransformationMorph? (maybe wait till etoys is gone) > > -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait > till etoys is gone) > > -> Remove world-in-world support. start by removing classes > EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. > > -> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix > all useres of TwoWayScrollPane and delete class. > > -> CurrentProjectRefactoring is deprecated, yet it is referenced. Please > fix all references (mostly just use Project current) and > remove CurrentProjectRefactoring. > > -> Use Sophie's code to render a real pulldown menu entries on windows > and Mac > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Janko MivÅ¡ek Svetovalec za informatiko Eranova d.o.o. Ljubljana, Slovenija www.eranova.si tel: 01 514 22 55 faks: 01 514 22 56 gsm: 031 674 565

Sept. 21, 2008

[Pharo-project] possible TODOs...

by Marcus Denker

Hi, I was already multiple times asked for a list of specific things that people could work on. Here are some ideas: -> World menu (after applying the simplification from bugtracker #166) -> Fullscreen of/on should be rendered like soundof/on, that is just one entry that changes according to state of display. -> in debug the start rendering entries should only be rendered when flag is set. (see code it calls) -> Preferences contains the code of the old preferences-browser. Remove all code related to this. (see Preferences class>>preferencesControlPanel) -> Browser has "printOut" menu entries that just do fileOut. Remove those entries. -> Browser has entry "browse all" in system category menu. This makes no sense. -> SqueakMap stores 1.5MB of crap in the image. make changeset that removes SqueakMap from the image. (check SqueakMap default purge) -> registerInFlapsRegistry... called in the class side initalize, please remove this and the infrastructure of flaps-registering. -> clean up Preferences. There are many preferences that nobody ever changes because the default makes a lot of sense. These need to be removed. -> CurvierMorph should be merged with PolygonMorph -> FileList2 should be merged with FileList. -> TranslatedMethod is a leftover from the original Jitter of 1998. Needs to be removed. Please note, it's in the specialObjectArray! -> Remove PluggableDictionary, PluggableSet (these are workarounds for the broken hashing in Squeak. We will fix hashing later for real) -> ColorTheme and subclasses should be removed. Refactoring needed for all users. (maybe best done after polymorph is added) -> remove BOBTransformationMorph. Refactor, merge with TransformationMorph? (maybe wait till etoys is gone) -> AlignmentMorphBob1 should be removed. Refactoring needed. (maybe wait till etoys is gone) -> Remove world-in-world support. start by removing classes EmbeddedWorldBorderMorph, NewWorldWindow after fixing all uses. -> TwoWayScrollPane shoud be removed (ScrollPane can do everything). Fix all useres of TwoWayScrollPane and delete class. -> CurrentProjectRefactoring is deprecated, yet it is referenced. Please fix all references (mostly just use Project current) and remove CurrentProjectRefactoring. -> Use Sophie's code to render a real pulldown menu entries on windows and Mac -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 21, 2008

Re: [Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by StÃ©phane Ducasse

> Hi Stef > > I'm interested why you think this blog would scare people from > Smalltalk? As it happens though, it's obviously aimed purely at > Smalltalkers: It's difficult to start such a discussion without > letting it out into the world for people to see, I say. I do not really understand what is the point of the Blog. Of course it would be nice if we could have a better interoperability. But I do not see the point. Then since years we never got more people of different dialects working together. > I'm actually all for open debate. Whether I agree or disagree with > the blog itself, I say don't hide such talk: if our community and > the language and tools are strong enough they will survive in spite > of such debate, or perhaps even because of it. > > Finally: is it always more difficult to build than to clean? I think > it's easier to build crap than to clean: building something good and > *keeping it that way* is the really difficult part. :) > Squeak is a perfect case in point: so many good ideas, but buried in > mounds of cruft that this effort (Pharo) is trying to strip away. > Once something has become crufty, it is really, really hard to clean > up. We know we did that for years and we are doing it. Still I always have present that building is still difficult and I respect what other people build. But this respect does not include that I will not judge the quality of a work. > > > Cheers, > Simon > > ps. > Bob Martin proposed adding a fifth line to the Agile Manifesto: > "Craftsmanship over Crap" (ie, favouring the former over the > latter). I couldn't agree more, it's a way of thinking I try to > apply all the time. A nice one. > > > On 20 Sep 2008, at 21:14, StÃ©phane Ducasse wrote: > >> I think that this is not like that that he will really bring >> smalltalk back. >> Concertation is equals to death. Have a look at Squeak. >> >> Stef >> >> PS: a good friend of mine once told me: "do not shit where you eat" >> and I keep that in mind >> even when cleaning squeak. I know that this more difficult to build >> things than to clean them. >> Still I would not let this blog out there because it will not >> produce anything positive, just scared >> more people from Smalltalk. >> >>> Hi all - as I said in my subject, I've already posted this on >>> Squeak-Dev, but I thought those on here who don't subscribe to >>> that list might be interested, too: >>> >>> http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html >>> >>> Cheers, >>> Simon >>> >>> >>> ******************************************************************************************************************************************* >>> >>> This email is from Pinesoft Limited. Its contents are confidential >>> to the intended recipient(s) at the email address(es) to which it >>> has been addressed. It may not be disclosed to or used by anyone >>> other than the addressee(s), nor may it be copied in anyway. If >>> received in error, please contact the sender, then delete it from >>> your system. Although this email and attachments are believed to >>> be free of virus, or any other defect which might affect any >>> computer or IT system into which they are received and opened, it >>> is the responsibility of the recipient to ensure that they are >>> virus free and no responsibility is accepted by Pinesoft for any >>> loss or damage arising in any way from receipt or use thereof. >>> >>> ******************************************************************************************************************************************* >>> >>> Pinesoft Limited are registered in England, Registered number: >>> 2914825. Registered office: 266-268 High Street, Waltham Cross, >>> Herts, EN8 7EA >>> >>> _______________________________________________ >>> 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 > > > > ****************************************************************************************************************************************** > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > ******************************************************************************************************************************************* > > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 21, 2008

Re: [Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by Simon Kirk

Hi Stef I'm interested why you think this blog would scare people from Smalltalk? As it happens though, it's obviously aimed purely at Smalltalkers: It's difficult to start such a discussion without letting it out into the world for people to see, I say. I'm actually all for open debate. Whether I agree or disagree with the blog itself, I say don't hide such talk: if our community and the language and tools are strong enough they will survive in spite of such debate, or perhaps even because of it. Finally: is it always more difficult to build than to clean? I think it's easier to build crap than to clean: building something good and *keeping it that way* is the really difficult part. Squeak is a perfect case in point: so many good ideas, but buried in mounds of cruft that this effort (Pharo) is trying to strip away. Once something has become crufty, it is really, really hard to clean up. Cheers, Simon ps. Bob Martin proposed adding a fifth line to the Agile Manifesto: "Craftsmanship over Crap" (ie, favouring the former over the latter). I couldn't agree more, it's a way of thinking I try to apply all the time. On 20 Sep 2008, at 21:14, StÃ©phane Ducasse wrote: > I think that this is not like that that he will really bring > smalltalk back. > Concertation is equals to death. Have a look at Squeak. > > Stef > > PS: a good friend of mine once told me: "do not shit where you eat" > and I keep that in mind > even when cleaning squeak. I know that this more difficult to build > things than to clean them. > Still I would not let this blog out there because it will not > produce anything positive, just scared > more people from Smalltalk. > >> Hi all - as I said in my subject, I've already posted this on >> Squeak-Dev, but I thought those on here who don't subscribe to that >> list might be interested, too: >> >> http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html >> >> Cheers, >> Simon >> >> >> ******************************************************************************************************************************************* >> >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> >> ******************************************************************************************************************************************* >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 21, 2008

Re: [Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by Simon Kirk

Hi Stef, No, not in particular: I thought it was an interesting conversation piece, rather than something I thought was a good idea (I actually had no opinion one way or the other). Given Pharo's a fork, I thought you (meaning both the group and you personally) would have an opinion on it, and I was interested to know what it was. Judging by your other post, I was right :) Cheers, Simon On 20 Sep 2008, at 21:16, StÃ©phane Ducasse wrote: > Hi simon > > Why did you post this here. > Because we forked? > Sorry but we had to. > > Stef > >> Hi all - as I said in my subject, I've already posted this on >> Squeak-Dev, but I thought those on here who don't subscribe to that >> list might be interested, too: >> >> http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html >> >> Cheers, >> Simon >> >> >> ******************************************************************************************************************************************* >> >> This email is from Pinesoft Limited. Its contents are confidential >> to the intended recipient(s) at the email address(es) to which it >> has been addressed. It may not be disclosed to or used by anyone >> other than the addressee(s), nor may it be copied in anyway. If >> received in error, please contact the sender, then delete it from >> your system. Although this email and attachments are believed to be >> free of virus, or any other defect which might affect any computer >> or IT system into which they are received and opened, it is the >> responsibility of the recipient to ensure that they are virus free >> and no responsibility is accepted by Pinesoft for any loss or >> damage arising in any way from receipt or use thereof. >> >> ******************************************************************************************************************************************* >> >> Pinesoft Limited are registered in England, Registered number: >> 2914825. Registered office: 266-268 High Street, Waltham Cross, >> Herts, EN8 7EA >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 21, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

Hi Adrian, The problem (and why I did not change the open menu) is that it is stiched to gether from different sources: 1) the ToolSet defines the upper part, interestingly not the transcript. b) everthing in the lowest part is generated automatically from all classes that register themselves in the open menu... Marcus On 19.09.2008, at 22:49, Adrian Lienhard wrote: > nice! > > some comments/ideas: > - I think "recently logged changes" need to be accessible from the > menu > - Help: does not make sense if it opens a submenu with only one item > - Pharo: this label does not tell much, "System" may be a bit better > - Open->Services Browser: honestly I don't know what this is, but it > looks like it would rather belong into Preferences > - Open->Preference Browser: can be removed if we have a top level > entry for preferences > - Open->Language Editor: probably also better goes into Preferences > (or remove it from the menu?) > - Consistent spelling (Class browser vs. Monticello Browser) > - Most important, I would also rethink the order in menus to create > logical groups and move important items up. Here a suggestion for > the open menu: > > Class browser > Method finder > Message names > ----------------------- > Workspace > Transcript > ----------------------- > Test Runner > Process browser > ----------------------- > Monticello Browser > Monticello Configurations > Recent submissions > Simple change sorter > Dual change sorter > File list > > Cheers, > Adrian > > On Sep 19, 2008, at 22:21 , Marcus Denker wrote: > >> >> On 19.09.2008, at 16:05, David Mitchell wrote: >> >>> Works great on Windows XP. >>> >>> Haven't downloaded Pharo in a while. >>> >>> Love the menu cleanup. >> >> Here is a changeset for a very radical menu cleanup of the >> world menu. >> >> <cleanMenu.1.cs> >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 21, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

On 20.09.2008, at 12:03, Norbert Hartl wrote: > On Fri, 2008-09-19 at 23:15 +0200, Adrian Lienhard wrote: >> On Sep 19, 2008, at 23:02 , Marcus Denker wrote: >> >>> >>> On 19.09.2008, at 22:49, Adrian Lienhard wrote: >>> >> [...] >> >>>> Class browser >>>> Method finder >>>> Message names >>> >>> Do we need Message names? >> >> hm... I almost never use it, but I know people that do quite often. >> "Method finder" seems even less important (I've never used it, except >> for demos ;)) >> > I use it on a daily base. I'm now an average skilled squeaker but > still > can't remember all the funny method names. The substring search capa- > bility of method finder ofter saves my day. I think I would stop using > it if browsing a complete protocol would be a little bit more usable > than just having all possible methods. Something like that. > > I think beginners will use Method finder quite often. > One thing is that "method finder" and "message names" both allow one to search for methods. The "method finder" in addition allows for giving examples in the form 3. 4. 7. So there is definitly the problem of duplicated features here. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 21, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Marcus Denker

On 20.09.2008, at 19:44, Michael Rueger wrote: > Marcus Denker wrote: > >> Licensed under the MIT License with parts under the Apache License. > > That would actually be the correct License, as Pharo, as are all > other projects *images* based on Squeak, is not entirely MIT. > Ok, I will add that to the distribution and the new website/google code. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 21, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

Another one :) Cleaning the inspector. Stef

Sept. 20, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

Version 2 On Sep 20, 2008, at 10:07 PM, StÃ©phane Ducasse wrote: > first one of a long series. > I will go over all the extensions of gary removal and slowly removed > them all and check the senders. > Please have a look. > > > "Change Set: removalIsUniClass > Date: 20 September 2008 > Author: Stephane.Ducasse > > Remove isUniClass and fix senders. > Note that for senders that were defined in Etoy I just removed > their body" > > > <EtoyRemoval-001-removalIsUniClass. > 1.cs>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2008

Re: [Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by StÃ©phane Ducasse

Hi simon Why did you post this here. Because we forked? Sorry but we had to. Stef > Hi all - as I said in my subject, I've already posted this on Squeak- > Dev, but I thought those on here who don't subscribe to that list > might be interested, too: > > http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html > > Cheers, > Simon > > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > > ******************************************************************************************************************************************* > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2008

Re: [Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by StÃ©phane Ducasse

I think that this is not like that that he will really bring smalltalk back. Concertation is equals to death. Have a look at Squeak. Stef PS: a good friend of mine once told me: "do not shit where you eat" and I keep that in mind even when cleaning squeak. I know that this more difficult to build things than to clean them. Still I would not let this blog out there because it will not produce anything positive, just scared more people from Smalltalk. > Hi all - as I said in my subject, I've already posted this on Squeak- > Dev, but I thought those on here who don't subscribe to that list > might be interested, too: > > http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html > > Cheers, > Simon > > > ******************************************************************************************************************************************* > > This email is from Pinesoft Limited. Its contents are confidential > to the intended recipient(s) at the email address(es) to which it > has been addressed. It may not be disclosed to or used by anyone > other than the addressee(s), nor may it be copied in anyway. If > received in error, please contact the sender, then delete it from > your system. Although this email and attachments are believed to be > free of virus, or any other defect which might affect any computer > or IT system into which they are received and opened, it is the > responsibility of the recipient to ensure that they are virus free > and no responsibility is accepted by Pinesoft for any loss or damage > arising in any way from receipt or use thereof. > > ******************************************************************************************************************************************* > > Pinesoft Limited are registered in England, Registered number: > 2914825. Registered office: 266-268 High Street, Waltham Cross, > Herts, EN8 7EA > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

first one of a long series. I will go over all the extensions of gary removal and slowly removed them all and check the senders. Please have a look. "Change Set: removalIsUniClass Date: 20 September 2008 Author: Stephane.Ducasse Remove isUniClass and fix senders. Note that for senders that were defined in Etoy I just removed their body"

Sept. 20, 2008

[Pharo-project] Interesting post about Smalltalk and the effect of success (sorry for those who already saw this on Squeak Dev)

by Simon Kirk

Hi all - as I said in my subject, I've already posted this on Squeak- Dev, but I thought those on here who don't subscribe to that list might be interested, too: http://www.robvens.nl/en/blog/The-Smalltalk-Trap.html Cheers, Simon ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Sept. 20, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

I could produce some changeset going over gary removal. Let me know. This is too much fun to finally remove etoy. Stef On Sep 20, 2008, at 9:28 PM, Marcus Denker wrote: > > On 20.09.2008, at 21:20, StÃ©phane Ducasse wrote: > >> Hi gary >> >> to relax from real men work (fixing my house :), I was browsing >> your package. >> I would like to know what is the semantics of self flag: #toRemove >> why did you keep the method in general do we have to look at the >> senders? >> > > another question is if it's really good to use monticello for the > removal... if we load it, > it moves all overrides into the removal-override category. These we > then would have to re-categorize > by hand. > > Maybe for a change like this, a changeset might be better... > > Marcus > >> Stef >> >> >>> Hi Stef. >>> >>> Been busy with work-work so haven't had time to review the EToys >>> removal. There are some methods identified that have not been >>> verified for removal vs. modification, but I've attached the mcz >>> here anyway. >>> >>> There are a few removals in TheWorldMainDockingBar in the etoys >>> removals, no mods there. >>> >>> The DockingBarMorph is, however, used in Polymorph for toolbars. >>> There is a potential conflict in Project>>finalEnterActions that >>> is defined in both Polymorph and EToysRemoval, the EToysRemoval >>> version should work with Polymorph though (based on Polymorph >>> version with an additional removal of "world presenter >>> positionStandardPlayer"). This will cause problems when updating >>> Polymorph though, until I get some time to split off the overrides >>> into a separate package. >>> >>> As for Etoys removal, the package contains changed methods and >>> stubs (flagged for removal). There are some manual steps required >>> to get rid of extra cruft (mostly preferences and scripting forms). >>> >>> Regards, Gary. >>> >>> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr >>> > >>> To: "An open mailing list to discuss any topics related to an open- >>> sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Friday, September 12, 2008 4:59 PM >>> Subject: [Pharo-project] removing the DockingBar and >>> TheWorldMainDockingBar >>> >>> >>>> Hi all >>>> >>>> I was ready to remove the novice mode and I think that we should >>>> remove DockingBar and TheWorldMainDockingBar >>>> Now gary it may introduce conflicts with etoy removal. >>>> What do you think? >>>> When will you send us the etoy removal? >>>> >>>> Stef >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> <Pinesoft-Removals-EToys-gvc. >>> 6.mcz>_______________________________________________ >>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 20, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by Marcus Denker

On 20.09.2008, at 21:20, StÃ©phane Ducasse wrote: > Hi gary > > to relax from real men work (fixing my house :), I was browsing your > package. > I would like to know what is the semantics of self flag: #toRemove > why did you keep the method in general do we have to look at the > senders? > another question is if it's really good to use monticello for the removal... if we load it, it moves all overrides into the removal-override category. These we then would have to re-categorize by hand. Maybe for a change like this, a changeset might be better... Marcus > Stef > > >> Hi Stef. >> >> Been busy with work-work so haven't had time to review the EToys >> removal. There are some methods identified that have not been >> verified for removal vs. modification, but I've attached the mcz >> here anyway. >> >> There are a few removals in TheWorldMainDockingBar in the etoys >> removals, no mods there. >> >> The DockingBarMorph is, however, used in Polymorph for toolbars. >> There is a potential conflict in Project>>finalEnterActions that is >> defined in both Polymorph and EToysRemoval, the EToysRemoval >> version should work with Polymorph though (based on Polymorph >> version with an additional removal of "world presenter >> positionStandardPlayer"). This will cause problems when updating >> Polymorph though, until I get some time to split off the overrides >> into a separate package. >> >> As for Etoys removal, the package contains changed methods and >> stubs (flagged for removal). There are some manual steps required >> to get rid of extra cruft (mostly preferences and scripting forms). >> >> Regards, Gary. >> >> ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr >> > >> To: "An open mailing list to discuss any topics related to an open- >> sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> >> Sent: Friday, September 12, 2008 4:59 PM >> Subject: [Pharo-project] removing the DockingBar and >> TheWorldMainDockingBar >> >> >>> Hi all >>> >>> I was ready to remove the novice mode and I think that we should >>> remove DockingBar and TheWorldMainDockingBar >>> Now gary it may introduce conflicts with etoy removal. >>> What do you think? >>> When will you send us the etoy removal? >>> >>> Stef >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> <Pinesoft-Removals-EToys-gvc. >> 6.mcz>_______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 20, 2008

Re: [Pharo-project] removing the DockingBar and TheWorldMainDockingBar

by StÃ©phane Ducasse

Hi gary to relax from real men work (fixing my house :), I was browsing your package. I would like to know what is the semantics of self flag: #toRemove why did you keep the method in general do we have to look at the senders? Stef > Hi Stef. > > Been busy with work-work so haven't had time to review the EToys > removal. There are some methods identified that have not been > verified for removal vs. modification, but I've attached the mcz > here anyway. > > There are a few removals in TheWorldMainDockingBar in the etoys > removals, no mods there. > > The DockingBarMorph is, however, used in Polymorph for toolbars. > There is a potential conflict in Project>>finalEnterActions that is > defined in both Polymorph and EToysRemoval, the EToysRemoval version > should work with Polymorph though (based on Polymorph version with > an additional removal of "world presenter positionStandardPlayer"). > This will cause problems when updating Polymorph though, until I get > some time to split off the overrides into a separate package. > > As for Etoys removal, the package contains changed methods and stubs > (flagged for removal). There are some manual steps required to get > rid of extra cruft (mostly preferences and scripting forms). > > Regards, Gary. > > ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr > > > To: "An open mailing list to discuss any topics related to an open- > sourceSmalltalk" <Pharo-project(a)lists.gforge.inria.fr> > Sent: Friday, September 12, 2008 4:59 PM > Subject: [Pharo-project] removing the DockingBar and > TheWorldMainDockingBar > > >> Hi all >> >> I was ready to remove the novice mode and I think that we should >> remove DockingBar and TheWorldMainDockingBar >> Now gary it may introduce conflicts with etoy removal. >> What do you think? >> When will you send us the etoy removal? >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > <Pinesoft-Removals-EToys-gvc. > 6.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2008

[Pharo-project] allUnsentMessages fix

by StÃ©phane Ducasse

looking at issue http://code.google.com/p/pharo/issues/detail?id=178&colspec=ID%20Type%20Sta… I saw that allUnsentMessages implementation is wrong it should be. Behavior>> allUnsentMessages "Answer an array of all the messages defined by the receiver that are not sent anywhere in the system." ^ SystemNavigation default allUnSentMessagesIn: self selectors Stef

Sept. 20, 2008

Re: [Pharo-project] More menu cleanup

by Marcus Denker

On 20.09.2008, at 19:39, Adrian Lienhard wrote: > I created an issue and added this and the other changeset posted by > Marcus: > http://code.google.com/p/pharo/issues/detail?id=166 > > Feedback welcome. I added two removals for a different menu: the browser's method menu: leanCodePane.1.cs removes the menu entry of getting a code-pane for a method. It removes all code (e.g. MethodHolder) related to it. cleanTileScript.1.cs removes the tile menu entry and starts to clean up the system. It does not remove SyntaxMorph... only PluggableTileScriptormorph, all related code from Browser and Codeholder. http://code.google.com/p/pharo/issues/detail?id=181 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 20, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Michael Rueger

Marcus Denker wrote: > Licensed under the MIT License with parts under the Apache License. That would actually be the correct License, as Pharo, as are all other projects *images* based on Squeak, is not entirely MIT. Michael

Sept. 20, 2008

Re: [Pharo-project] More menu cleanup

by Adrian Lienhard

I created an issue and added this and the other changeset posted by Marcus: http://code.google.com/p/pharo/issues/detail?id=166 Feedback welcome. Adrian On Sep 20, 2008, at 19:30 , Adrian Lienhard wrote: > Here is a changeset that cleans up and restructures the code context > menu. In the process of removing stuff I also removed around 30 > methods, some of which were huge (ever seen the implementation of > the "explain" functionality?). > > Cheers, > Adrian > > BTW: After loading the changeset save and restart to get all icons > in the menu. > > <cleanContextMenu.1.cs> > ___________________ > 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

Sept. 20, 2008

[Pharo-project] More menu cleanup

by Adrian Lienhard

Here is a changeset that cleans up and restructures the code context menu. In the process of removing stuff I also removed around 30 methods, some of which were huge (ever seen the implementation of the "explain" functionality?). Cheers, Adrian BTW: After loading the changeset save and restart to get all icons in the menu. ___________________ http://www.adrian-lienhard.ch/

Sept. 20, 2008

Re: [Pharo-project] [ANN] first one-click image

by Adrian Lienhard

On Sep 20, 2008, at 12:03 , Norbert Hartl wrote: > On Fri, 2008-09-19 at 23:15 +0200, Adrian Lienhard wrote: >> On Sep 19, 2008, at 23:02 , Marcus Denker wrote: >> >>> >>> On 19.09.2008, at 22:49, Adrian Lienhard wrote: >>> >> [...] >> >>>> Class browser >>>> Method finder >>>> Message names >>> >>> Do we need Message names? >> >> hm... I almost never use it, but I know people that do quite often. >> "Method finder" seems even less important (I've never used it, except >> for demos ;)) >> > I use it on a daily base. I'm now an average skilled squeaker but > still > can't remember all the funny method names. The substring search capa- > bility of method finder I assume you don't mean the "method finder" but the tool referred to as "Message names"? The former is the fancy one you can enter example values like "3. 4. 7" and it will tell you that the method #+ satisfies this example. I agree that the message names tool is useful especially for beginners. Cheers, Adrian

Sept. 20, 2008

Re: [Pharo-project] [ANN] first one-click image

by Norbert Hartl

On Fri, 2008-09-19 at 23:15 +0200, Adrian Lienhard wrote: > On Sep 19, 2008, at 23:02 , Marcus Denker wrote: > > > > > On 19.09.2008, at 22:49, Adrian Lienhard wrote: > > > [...] > > >> Class browser > >> Method finder > >> Message names > > > > Do we need Message names? > > hm... I almost never use it, but I know people that do quite often. > "Method finder" seems even less important (I've never used it, except > for demos ;)) > I use it on a daily base. I'm now an average skilled squeaker but still can't remember all the funny method names. The substring search capa- bility of method finder ofter saves my day. I think I would stop using it if browsing a complete protocol would be a little bit more usable than just having all possible methods. Something like that. I think beginners will use Method finder quite often. My 2 zents. Norbert

Sept. 20, 2008

Re: [Pharo-project] [ANN] first one-click image

by StÃ©phane Ducasse

I use method finder for math stuff. Stef On Sep 19, 2008, at 11:15 PM, Adrian Lienhard wrote: > > On Sep 19, 2008, at 23:02 , Marcus Denker wrote: > >> >> On 19.09.2008, at 22:49, Adrian Lienhard wrote: >> > [...] > >>> Class browser >>> Method finder >>> Message names >> >> Do we need Message names? > > hm... I almost never use it, but I know people that do quite often. > "Method finder" seems even less important (I've never used it, > except for demos ;)) > > What about a "More..." item, that switches to a menu with less often > used tools? Recent submissions (which I added below because it is in > the flaps) could go there too, as well as the dual change sorter. > Maybe also File list (I also never use it). > > This would mean: > > +++++++++++++++++ > Class browser > Workspace > Transcript > ----------------------- > Test Runner > Process browser > ----------------------- > Monticello Browser > Monticello Configurations > Change sorter > ----------------------- > more... > +++++++++++++++++ > > > +++++++++++++++++ > Method finder > Message names > ----------------------- > Recent submissions > Dual change sorter > File list > +++++++++++++++++ > >> >> >>> >>> ----------------------- >>> Workspace >>> Transcript >>> ----------------------- >>> Test Runner >>> Process browser >>> ----------------------- >>> Monticello Browser >>> Monticello Configurations >>> Recent submissions >>> Simple change sorter >>> Dual change sorter >>> File list >>> >>> Cheers, >>> Adrian >>> >>> On Sep 19, 2008, at 22:21 , Marcus Denker wrote: >>> >>>> >>>> On 19.09.2008, at 16:05, David Mitchell wrote: >>>> >>>>> Works great on Windows XP. >>>>> >>>>> Haven't downloaded Pharo in a while. >>>>> >>>>> Love the menu cleanup. >>>> >>>> Here is a changeset for a very radical menu cleanup of the >>>> world menu. >>>> >>>> <cleanMenu.1.cs> >>>> >>>> >>>> -- >>>> Marcus Denker -- denker(a)iam.unibe.ch >>>> http://www.iam.unibe.ch/~denker >>>> >>>> _______________________________________________ >>>> 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 >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 >

Sept. 20, 2008

Re: [Pharo-project] [ANN] first one-click image

by StÃ©phane Ducasse

coooooool Stef PS: ok I shouuld contniue fixing my floor instead of reading emails :) On Sep 19, 2008, at 11:02 PM, laurent laffont wrote: > Hi, > > here's is Pharo test report: > > passed: 3357 > failures: 5 > errors: 2 > > http://www.adhocmusic.net/squeak/reports/Pharo0.1-10072-2008-09-15.tests.ht… > > Thanks to Alexandre Bergel work, squeakci/ContinuousIntegration is > now able to download a Pharo image, unzip it, test it and create the > report with a single command. > > Laurent Laffont. > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Marcus Denker

On 20.09.2008, at 00:46, Marcus Denker wrote: > > On 19.09.2008, at 15:59, David Mitchell wrote: > >> Maybe something like, >> >> "Organization of the file structure for easy portability across >> Linux, >> Macintosh, and Windows inspired by the organization used by the >> Sophie >> project." > > I will add this: Or maybe in the style of etoys (http://squeakland.org/download/license.jsp ) Licensed under the MIT License with parts under the Apache License. Copyright (c) Pharo Project, and Contributors Copyright (c) 1996-2008 Viewpoints Research Institute, and Contributors Copyright (c) 1996 Apple Computer, Inc. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. You may obtain a copy of the Apache License at http://www.apache.org/licenses/LICENSE-2.0 > = > = > = > = > = > = > ====================================================================== > > Organization of the file structure for easy portability across Linux, > Macintosh, and Windows inspired by the organization used by the Sophie > project, originally invented for Plopp (http://www.planet-plopp.com) > by > Impara (http://impara.de) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Marcus Denker

On 19.09.2008, at 15:59, David Mitchell wrote: > Maybe something like, > > "Organization of the file structure for easy portability across Linux, > Macintosh, and Windows inspired by the organization used by the Sophie > project." I will add this: Pharo is Licenced under MIT. Copyright (c) 2008 Pharo Project Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. = = = = ======================================================================== Organization of the file structure for easy portability across Linux, Macintosh, and Windows inspired by the organization used by the Sophie project, originally invented for Plopp (http://www.planet-plopp.com) by Impara (http://impara.de) -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

On 19.09.2008, at 20:19, David Mitchell wrote: > (Forgot to copy the list) > > > Yep, that fixed them all after I did a Load code updates. > > Did have one new error in testPrinting: > > self assert: nonSEarray2 printString = 'an Array(#Array)' > > But I have to say, I have never experienced a Squeak release where > there was only one test error. And that is even a wrong test ;-) I think this is a fallout from converting all ReadOnlyBindings in the SystemDictionary to normal Associations. the nonSEarray2 (non-self-evaluating) is indeed now self-evaluating, it prints as {#Array->Array}, not 'anArray(#Array)'. I have added an entry in the bugtracker. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Adrian Lienhard

On Sep 19, 2008, at 23:02 , Marcus Denker wrote: > > On 19.09.2008, at 22:49, Adrian Lienhard wrote: > [...] >> Class browser >> Method finder >> Message names > > Do we need Message names? hm... I almost never use it, but I know people that do quite often. "Method finder" seems even less important (I've never used it, except for demos ;)) What about a "More..." item, that switches to a menu with less often used tools? Recent submissions (which I added below because it is in the flaps) could go there too, as well as the dual change sorter. Maybe also File list (I also never use it). This would mean: +++++++++++++++++ Class browser Workspace Transcript ----------------------- Test Runner Process browser ----------------------- Monticello Browser Monticello Configurations Change sorter ----------------------- more... +++++++++++++++++ +++++++++++++++++ Method finder Message names ----------------------- Recent submissions Dual change sorter File list +++++++++++++++++ > > >> >> ----------------------- >> Workspace >> Transcript >> ----------------------- >> Test Runner >> Process browser >> ----------------------- >> Monticello Browser >> Monticello Configurations >> Recent submissions >> Simple change sorter >> Dual change sorter >> File list >> >> Cheers, >> Adrian >> >> On Sep 19, 2008, at 22:21 , Marcus Denker wrote: >> >>> >>> On 19.09.2008, at 16:05, David Mitchell wrote: >>> >>>> Works great on Windows XP. >>>> >>>> Haven't downloaded Pharo in a while. >>>> >>>> Love the menu cleanup. >>> >>> Here is a changeset for a very radical menu cleanup of the >>> world menu. >>> >>> <cleanMenu.1.cs> >>> >>> >>> -- >>> Marcus Denker -- denker(a)iam.unibe.ch >>> http://www.iam.unibe.ch/~denker >>> >>> _______________________________________________ >>> 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 > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

On 19.09.2008, at 22:49, Adrian Lienhard wrote: > nice! > > some comments/ideas: > - I think "recently logged changes" need to be accessible from the > menu > - Help: does not make sense if it opens a submenu with only one item > - Pharo: this label does not tell much, "System" may be a bit better > - Open->Services Browser: honestly I don't know what this is, but it > looks like it would rather belong into Preferences > - Open->Preference Browser: can be removed if we have a top level > entry for preferences > - Open->Language Editor: probably also better goes into Preferences > (or remove it from the menu?) > - Consistent spelling (Class browser vs. Monticello Browser) > - Most important, I would also rethink the order in menus to create > logical groups and move important items up. Here a suggestion for > the open menu: > > Class browser > Method finder > Message names Do we need Message names? > > ----------------------- > Workspace > Transcript > ----------------------- > Test Runner > Process browser > ----------------------- > Monticello Browser > Monticello Configurations > Recent submissions > Simple change sorter > Dual change sorter > File list > > Cheers, > Adrian > > On Sep 19, 2008, at 22:21 , Marcus Denker wrote: > >> >> On 19.09.2008, at 16:05, David Mitchell wrote: >> >>> Works great on Windows XP. >>> >>> Haven't downloaded Pharo in a while. >>> >>> Love the menu cleanup. >> >> Here is a changeset for a very radical menu cleanup of the >> world menu. >> >> <cleanMenu.1.cs> >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by laurent laffont

Hi, here's is Pharo test report: passed: 3357 failures: 5 errors: 2 http://www.adhocmusic.net/squeak/reports/Pharo0.1-10072-2008-09-15.tests.ht… Thanks to Alexandre Bergel work, squeakci/ContinuousIntegration is now able to download a Pharo image, unzip it, test it and create the report with a single command. Laurent Laffont.

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Adrian Lienhard

nice! some comments/ideas: - I think "recently logged changes" need to be accessible from the menu - Help: does not make sense if it opens a submenu with only one item - Pharo: this label does not tell much, "System" may be a bit better - Open->Services Browser: honestly I don't know what this is, but it looks like it would rather belong into Preferences - Open->Preference Browser: can be removed if we have a top level entry for preferences - Open->Language Editor: probably also better goes into Preferences (or remove it from the menu?) - Consistent spelling (Class browser vs. Monticello Browser) - Most important, I would also rethink the order in menus to create logical groups and move important items up. Here a suggestion for the open menu: Class browser Method finder Message names ----------------------- Workspace Transcript ----------------------- Test Runner Process browser ----------------------- Monticello Browser Monticello Configurations Recent submissions Simple change sorter Dual change sorter File list Cheers, Adrian On Sep 19, 2008, at 22:21 , Marcus Denker wrote: > > On 19.09.2008, at 16:05, David Mitchell wrote: > >> Works great on Windows XP. >> >> Haven't downloaded Pharo in a while. >> >> Love the menu cleanup. > > Here is a changeset for a very radical menu cleanup of the > world menu. > > <cleanMenu.1.cs> > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

On 19.09.2008, at 16:05, David Mitchell wrote: > Works great on Windows XP. > > Haven't downloaded Pharo in a while. > > Love the menu cleanup. Here is a changeset for a very radical menu cleanup of the world menu. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Fwd: [Pharo-project] [ANN] first one-click image

by David Mitchell

(Forgot to copy the list) Yep, that fixed them all after I did a Load code updates. Did have one new error in testPrinting: self assert: nonSEarray2 printString = 'an Array(#Array)' But I have to say, I have never experienced a Squeak release where there was only one test error. (Of course, before the test runner was integrated, there were no errors, but that doesn't count!) Great work everyone. On Fri, Sep 19, 2008 at 11:06 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > > On 19.09.2008, at 17:31, Norbert Hartl wrote: >>> >>> >> No need to. None of these seem to fail in 10073. The one-click is >> based on 10072. > > Sorry for that... I will do a new release soon. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > >

Sept. 19, 2008

Re: [Pharo-project] Image size

by Michael Rueger

StÃ©phane Ducasse wrote: > ScriptLoader is also such releaseBuilder guy. > I know well releaseBuilder :) so I guess we should unify the two? Michael

Sept. 19, 2008

Re: [Pharo-project] Image size

by StÃ©phane Ducasse

ScriptLoader is also such releaseBuilder guy. I know well releaseBuilder :) Stef > >>>> Is there a reason why the cleanup code resides in ScriptLoader? >>>> >>> >>> No. >>> -- >> But where you will put it? > > Should have read all the mails first ;-) > ReleaseBuilder > > Michael > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Marcus Denker

On 19.09.2008, at 17:31, Norbert Hartl wrote: >> >> > No need to. None of these seem to fail in 10073. The one-click is > based on 10072. Sorry for that... I will do a new release soon. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] Image size

by Michael Rueger

StÃ©phane Ducasse wrote: >>> Is there a reason why the cleanup code resides in ScriptLoader? >>> >> >> No. >> -- > > But where you will put it? Should have read all the mails first ;-) ReleaseBuilder Michael

Sept. 19, 2008

Re: [Pharo-project] Image size

by Michael Rueger

Marcus Denker wrote: > > There is more code for cleaning in the "cleaning" category of ScriptLoader. > #initialCleanup and #finalCleanup. > (we should merge the code above in the cleanup methods) There is also some code in the ReleaseBuilder classes. It would be good IMHO to have one location to put all these utility methods. I started ReleaseBuilder back then as that place, so subclasses e.g. for Squeakland, Sophie or Plopp can implement all the necessary magic needed when auto building a release. Michael

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Norbert Hartl

On Fri, 2008-09-19 at 10:16 -0500, David Mitchell wrote: > I just ran all of the tests in the image. > > 2135 run, 2107 passes, 4 expected failures, 4 failures, 20 errors, 0 > unexpected passes > > None of the failures or errors look platform specific. > > 1 and 2. Date monthIndex is returning self implicitly (and does > nothing of use). > > 3. ReleaseTest fails because there are two undeclared. > #TextEditorYellowButtonMenu and #ChangesOrganizer > > 4. testLocalMethodWithSameCodeInTrait fails here: > deny: (trait >> selector = (each >> selector)) > And I don't really understand traits well enough to cope. > > Haven't looked at the errors. > No need to. None of these seem to fail in 10073. The one-click is based on 10072. Norbert > On Fri, Sep 19, 2008 at 9:05 AM, David Mitchell > <david.mitchell(a)gmail.com> wrote: > > Works great on Windows XP. > > > > Haven't downloaded Pharo in a while. > > > > Love the menu cleanup. > > > > Go! GO!! GO!!! > > > > On Fri, Sep 19, 2008 at 4:17 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > >> Hi, > >> > >> There is now a first one-click image. This uses the packaging invented by > >> Impara for Plopp, > >> which later was used by Sophie and then even Seaside: > >> > >> > >> https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip > >> > >> on the Mac, this is an executable. On windows, this is a directory with an > >> .exe, for linux, > >> there is a pharo.sh. > >> > >> This has only been tested on Mac and Linux right now. > >> > >> Notes: > >> => COPYRIGHT needs to be fixed > >> => needs to be tested on Windows > >> => more testing on Linux > >> => fix icon for windows > >> => Icon is not yet final > >> => we need to add the truetype plugins / recompiled VM > >> > >> The idea behing this is that it should be very simple to get it running for > >> new people. > >> Those with lots of knowledge then can take the package appart and use it > >> like they want. > >> > >> The idea is that the one-click will have more tools later (syntax > >> highlighting, Refactoring, things > >> like that). In addtion there will be a .zip with a "core" image that has the > >> bare minimum for > >> deployment. The "download" link of the pharo website will point to the > >> one-click destribution. > >> > >> Marcus > >> > >> > >> -- > >> Marcus Denker -- denker(a)iam.unibe.ch > >> http://www.iam.unibe.ch/~denker > >> > >> > >> _______________________________________________ > >> 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

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by David Mitchell

I just ran all of the tests in the image. 2135 run, 2107 passes, 4 expected failures, 4 failures, 20 errors, 0 unexpected passes None of the failures or errors look platform specific. 1 and 2. Date monthIndex is returning self implicitly (and does nothing of use). 3. ReleaseTest fails because there are two undeclared. #TextEditorYellowButtonMenu and #ChangesOrganizer 4. testLocalMethodWithSameCodeInTrait fails here: deny: (trait >> selector = (each >> selector)) And I don't really understand traits well enough to cope. Haven't looked at the errors. On Fri, Sep 19, 2008 at 9:05 AM, David Mitchell <david.mitchell(a)gmail.com> wrote: > Works great on Windows XP. > > Haven't downloaded Pharo in a while. > > Love the menu cleanup. > > Go! GO!! GO!!! > > On Fri, Sep 19, 2008 at 4:17 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: >> Hi, >> >> There is now a first one-click image. This uses the packaging invented by >> Impara for Plopp, >> which later was used by Sophie and then even Seaside: >> >> >> https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip >> >> on the Mac, this is an executable. On windows, this is a directory with an >> .exe, for linux, >> there is a pharo.sh. >> >> This has only been tested on Mac and Linux right now. >> >> Notes: >> => COPYRIGHT needs to be fixed >> => needs to be tested on Windows >> => more testing on Linux >> => fix icon for windows >> => Icon is not yet final >> => we need to add the truetype plugins / recompiled VM >> >> The idea behing this is that it should be very simple to get it running for >> new people. >> Those with lots of knowledge then can take the package appart and use it >> like they want. >> >> The idea is that the one-click will have more tools later (syntax >> highlighting, Refactoring, things >> like that). In addtion there will be a .zip with a "core" image that has the >> bare minimum for >> deployment. The "download" link of the pharo website will point to the >> one-click destribution. >> >> Marcus >> >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Norbert Hartl

On Fri, 2008-09-19 at 11:17 +0200, Marcus Denker wrote: > Hi, > > There is now a first one-click image. This uses the packaging invented > by Impara for Plopp, > which later was used by Sophie and then even Seaside: > > https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip > > on the Mac, this is an executable. On windows, this is a directory > with an .exe, for linux, > there is a pharo.sh. > The image starts with the shell script. TestRunner gives me 4 failures and 20 Errors. I get none of them in 10073 so I think they all have been fixed. Will test further, Norbert

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by StÃ©phane Ducasse

:) > Works great on Windows XP. > > Haven't downloaded Pharo in a while. > > Love the menu cleanup. > > Go! GO!! GO!!! and you did not see http://www.squeaksource.com when you create a package :)))) But I'm sure we can do more ;) Stef

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by David Mitchell

Works great on Windows XP. Haven't downloaded Pharo in a while. Love the menu cleanup. Go! GO!! GO!!! On Fri, Sep 19, 2008 at 4:17 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > Hi, > > There is now a first one-click image. This uses the packaging invented by > Impara for Plopp, > which later was used by Sophie and then even Seaside: > > > https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip > > on the Mac, this is an executable. On windows, this is a directory with an > .exe, for linux, > there is a pharo.sh. > > This has only been tested on Mac and Linux right now. > > Notes: > => COPYRIGHT needs to be fixed > => needs to be tested on Windows > => more testing on Linux > => fix icon for windows > => Icon is not yet final > => we need to add the truetype plugins / recompiled VM > > The idea behing this is that it should be very simple to get it running for > new people. > Those with lots of knowledge then can take the package appart and use it > like they want. > > The idea is that the one-click will have more tools later (syntax > highlighting, Refactoring, things > like that). In addtion there will be a .zip with a "core" image that has the > bare minimum for > deployment. The "download" link of the pharo website will point to the > one-click destribution. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] Copyright inside one click is strange

by David Mitchell

Maybe something like, "Organization of the file structure for easy portability across Linux, Macintosh, and Windows inspired by the organization used by the Sophie project." Would be more accurate. On Fri, Sep 19, 2008 at 6:35 AM, Lukas Renggli <renggli(a)gmail.com> wrote: > On 9/19/08, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> I think this is because the one-click image template comes from the >> Sophie project. Seaside developers basically just replaced the image >> in the zip. > > No, we completely rebuilt it. > > Cheers, > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Lukas Renggli

On 9/19/08, Damien Cassou <damien.cassou(a)gmail.com> wrote: > I think this is because the one-click image template comes from the > Sophie project. Seaside developers basically just replaced the image > in the zip. No, we completely rebuilt it. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 19, 2008

Re: [Pharo-project] [ANN] update 10073

by StÃ©phane Ducasse

On Sep 19, 2008, at 11:30 AM, Adrian Lienhard wrote: > > On Sep 18, 2008, at 21:08 , StÃ©phane Ducasse wrote: >>> >>>> I would like to define some tests also to cover that CM are >>>> really duplicated. >>> >>> btw., I'm in the process of making http://code.google.com/p/pharo/issues/detail?id=167 >>> work correctly... >> >> why >> It was broken? > > no, but it was not completely finished (like the effect of these > changes on the sources/changes condensing procedure) Ok > Stef, in http://code.google.com/p/pharo/issues/detail?id=167 you > removed that method properties are copied when we copy a compiled > method (this is in #copyWithTrailerBytes:). certainly my mistake There was not rationale probably misuderstanding the code. > I am not sure what the expected behavior actually is. What was your > rationale? > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by StÃ©phane Ducasse

> StÃ©phane Ducasse wrote: >> what is the principal behind yoru atomic loading? >> - Another namespace >> - one become > Are you kidding? That's a pretty reckless way to do things. What I > do is a mix of the techniques used in ENVY and Team/V. which is? >> When we talk about atomic loading we mean that we should be able to >> change the code >> of a compiler while this one is currently compiling the changes >> that should loaded. >> Similarly, we should be able to modify the method that is currently >> been executed and showing the progress > Ah, now I see. Our definition of atomic loading is not the same. For > me, atomic loading is a transaction-based load and modification of > semantic elements in the image. It either succeeds or it doesn't, in > which case rolls back, and the image is in the state it was before > the load. For us atomic loading is also a transaction approach. But we MUST be able to load code that modifies the compiler or the UI. Especially until we do not have a bootstrappable system. Else we would simply modify the code and and rebuild the image from scratch. Your approach only work for parts that are not defining in the loading process itself. For us atomic loading means that we can change deep aspects of the system because we must. Changing the compiler or UI element is not something that we do because we are idiot researchers. So think twice. Your approach is good once we will have bootstrappable system. > To answer your other statement, I can support multiple simultaneous > compilers, remote and local, although whether that makes sense is > another question. > > I think the main difference in our thinking is that Pharo seems to > me to be a research project, while I'm just building the things I > need and am accustomed to from VA, VW, ENVY, etc., so that I can > develop software. Come on. Developping applications is different than maintaining a core of a smalltalk system. We can manage Seaside application without problems in MC. Now maintaining and changing an image with living objects being executing during the update mechanism is another story especially when you do not to rely on changeset. Where pharo is a research project? Joseph seriously you do not know what research is. Do not bash us. Atomic loading is really needed and not for fun. I could show you things that are research and this is clearly not what we are doing in pharo (have a look at changebox that completely changes the lookup of messages or classboxes. This is research and this will not be put in pharo). Now we have compiler fixes that cannot be loaded in a package system without atomic loading because the compiler needs to run to install the changes. May be duplicating the compiler is a solution, may be loading bytecode is another one, or using become. Duplicating the compiler is just a hack because we cannot duplicate morphic when we must changing a morphic method. Stef

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by Damien Cassou

On Fri, Sep 19, 2008 at 11:17 AM, Marcus Denker <denker(a)iam.unibe.ch> wrote: > => more testing on Linux Works perfectly on Ubuntu 8.04 32bits. -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 19, 2008

Re: [Pharo-project] Copyright inside one click is strange

by Damien Cassou

I think this is because the one-click image template comes from the Sophie project. Seaside developers basically just replaced the image in the zip. On Fri, Sep 19, 2008 at 8:38 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > it says > > Distribution based on Sophie http://www.sophieproject.org/ Seaside > http://www.seaside.st > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Cassou Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu)

Sept. 19, 2008

Re: [Pharo-project] Image size

by StÃ©phane Ducasse

> > SMSqueakMap default purge > > --> 12.2MB > > that is, SqueakMap keep 1.5MB of data in the image. > We should remove it. > > >> Is there a reason why the cleanup code resides in ScriptLoader? >> > > No. > -- But where you will put it? Stef

Sept. 19, 2008

Re: [Pharo-project] [ANN] first one-click image

by StÃ©phane Ducasse

excellent! Stef On Sep 19, 2008, at 11:17 AM, Marcus Denker wrote: > Hi, > > There is now a first one-click image. This uses the packaging > invented by Impara for Plopp, > which later was used by Sophie and then even Seaside: > > https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip > > on the Mac, this is an executable. On windows, this is a directory > with an .exe, for linux, > there is a pharo.sh. > > This has only been tested on Mac and Linux right now. > > Notes: > => COPYRIGHT needs to be fixed > => needs to be tested on Windows > => more testing on Linux > => fix icon for windows > => Icon is not yet final > => we need to add the truetype plugins / recompiled VM > > The idea behing this is that it should be very simple to get it > running for new people. > Those with lots of knowledge then can take the package appart and > use it like they want. > > The idea is that the one-click will have more tools later (syntax > highlighting, Refactoring, things > like that). In addtion there will be a .zip with a "core" image that > has the bare minimum for > deployment. The "download" link of the pharo website will point to > the one-click destribution. > > Marcus > > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] [ANN] update 10073

by Adrian Lienhard

On Sep 18, 2008, at 21:08 , StÃ©phane Ducasse wrote: >> >>> I would like to define some tests also to cover that CM are really >>> duplicated. >> >> btw., I'm in the process of making http://code.google.com/p/pharo/issues/detail?id=167 >> work correctly... > > why > It was broken? no, but it was not completely finished (like the effect of these changes on the sources/changes condensing procedure) Stef, in http://code.google.com/p/pharo/issues/detail?id=167 you removed that method properties are copied when we copy a compiled method (this is in #copyWithTrailerBytes:). I am not sure what the expected behavior actually is. What was your rationale? Adrian

Sept. 19, 2008

Re: [Pharo-project] Image size

by Marcus Denker

On 19.09.2008, at 11:19, Norbert Hartl wrote: > > SMSqueakMap default clearCaches. > > might be a candidate to add. > SMSqueakMap default purge --> 12.2MB that is, SqueakMap keep 1.5MB of data in the image. We should remove it. > Is there a reason why the cleanup code resides in ScriptLoader? > No. -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by Joseph Pelrine

StÃ©phane Ducasse wrote: > what is the principal behind yoru atomic loading? > - Another namespace > - one become Are you kidding? That's a pretty reckless way to do things. What I do is a mix of the techniques used in ENVY and Team/V. > When we talk about atomic loading we mean that we should be able to > change the code > of a compiler while this one is currently compiling the changes that > should loaded. > Similarly, we should be able to modify the method that is currently been > executed and showing the progress Ah, now I see. Our definition of atomic loading is not the same. For me, atomic loading is a transaction-based load and modification of semantic elements in the image. It either succeeds or it doesn't, in which case rolls back, and the image is in the state it was before the load. To answer your other statement, I can support multiple simultaneous compilers, remote and local, although whether that makes sense is another question. I think the main difference in our thinking is that Pharo seems to me to be a research project, while I'm just building the things I need and am accustomed to from VA, VW, ENVY, etc., so that I can develop software. Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine(a)metaprog.com Web: http://www.metaprog.com You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen

Sept. 19, 2008

Re: [Pharo-project] Image size

by Norbert Hartl

On Fri, 2008-09-19 at 11:06 +0200, Marcus Denker wrote: > On 19.09.2008, at 10:42, StÃ©phane Ducasse wrote: > > > did you flush the changesets ? > > That's important. Adrian lienhard sent this around some time > ago some cleanup code. Here is an updated version: > > > ScriptLoader new cleaningCS. > RequiredSelectors initialize. > ProvidedSelectors initialize. > LocalSends initialize. > Utilities cleanseOtherworldlySteppers. > Smalltalk organization removeEmptyCategories. > SystemBrowser removeObsolete. > TheWorldMenu removeObsolete. > AppRegistry removeObsolete. > MCFileBasedRepository flushAllCaches. > MCDefinition clearInstances. > Symbol compactSymbolTable. > Set rehashAllSets. > Smalltalk cleanOutUndeclared. > Smalltalk garbageCollect. > > --> 13.7 MB > 3.9 was 15.6 MB > > > There is more code for cleaning in the "cleaning" category of > ScriptLoader. > #initialCleanup and #finalCleanup. > (we should merge the code above in the cleanup methods) > > The changesets are the majority of the space, another 100K or so comes > from rehashing the sets. This is I think > because the methodDictionaries are degenerating very fast when adding / > replacing methods. > I had a look at it and SMSqueakMap default clearCaches. might be a candidate to add. Is there a reason why the cleanup code resides in ScriptLoader? Norbert

Sept. 19, 2008

[Pharo-project] [ANN] first one-click image

by Marcus Denker

Hi, There is now a first one-click image. This uses the packaging invented by Impara for Plopp, which later was used by Sophie and then even Seaside: https://gforge.inria.fr/frs/download.php/7078/Pharo0.1-10072-oneclick.zip on the Mac, this is an executable. On windows, this is a directory with an .exe, for linux, there is a pharo.sh. This has only been tested on Mac and Linux right now. Notes: => COPYRIGHT needs to be fixed => needs to be tested on Windows => more testing on Linux => fix icon for windows => Icon is not yet final => we need to add the truetype plugins / recompiled VM The idea behing this is that it should be very simple to get it running for new people. Those with lots of knowledge then can take the package appart and use it like they want. The idea is that the one-click will have more tools later (syntax highlighting, Refactoring, things like that). In addtion there will be a .zip with a "core" image that has the bare minimum for deployment. The "download" link of the pharo website will point to the one-click destribution. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] Image size

by Marcus Denker

On 19.09.2008, at 10:42, StÃ©phane Ducasse wrote: > did you flush the changesets ? That's important. Adrian lienhard sent this around some time ago some cleanup code. Here is an updated version: ScriptLoader new cleaningCS. RequiredSelectors initialize. ProvidedSelectors initialize. LocalSends initialize. Utilities cleanseOtherworldlySteppers. Smalltalk organization removeEmptyCategories. SystemBrowser removeObsolete. TheWorldMenu removeObsolete. AppRegistry removeObsolete. MCFileBasedRepository flushAllCaches. MCDefinition clearInstances. Symbol compactSymbolTable. Set rehashAllSets. Smalltalk cleanOutUndeclared. Smalltalk garbageCollect. --> 13.7 MB 3.9 was 15.6 MB There is more code for cleaning in the "cleaning" category of ScriptLoader. #initialCleanup and #finalCleanup. (we should merge the code above in the cleanup methods) The changesets are the majority of the space, another 100K or so comes from rehashing the sets. This is I think because the methodDictionaries are degenerating very fast when adding / replacing methods. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by Lukas Renggli

FYI, there is a working infrastructure for atomic loading here: http://source.wiresong.ca/mc/SystemEditor-mtf.69.mcz Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 19, 2008

Re: [Pharo-project] Image size

by Norbert Hartl

On Fri, 2008-09-19 at 10:42 +0200, StÃ©phane Ducasse wrote: > did you flush the changesets ? > because it keeps a reference also to any changes. > Ah, learned something new :) That freed more than 1 megabyte. So it is 5% smaller than squeak. Any other hints? :) thanks, Norbert > Stef > > On Sep 19, 2008, at 10:36 AM, Norbert Hartl wrote: > > > Hi, > > > > I have problems in understanding the image size of pharo. > > I monitored it since we started and I did not recognize > > a notably change. So I took a pharo 10073 and squeak 3.10.2 > > for comparsion. > > yes frustrating after removing MVC and more. > > > > Amount classes, amount methods and lines of code are all 10% > > less in pharo. But the image is approx. 0,5% - 1% smaller > > than the squeak one. > > > > To clarify this. I closed all windows and did condenseChanges > > and garbageCollect, flushed the monticello cache... > > > > What could be the reason for this? > > > > thanks, > > > > Norbert > > > > > > > > > > _______________________________________________ > > 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

Sept. 19, 2008

Re: [Pharo-project] 10073 error

by StÃ©phane Ducasse

Indeed now I get the complete recompilation working. > May be got an hiccup bvecause it is working for me. > I will retry then > > stef

Sept. 19, 2008

Re: [Pharo-project] Image size

by StÃ©phane Ducasse

did you flush the changesets ? because it keeps a reference also to any changes. Stef On Sep 19, 2008, at 10:36 AM, Norbert Hartl wrote: > Hi, > > I have problems in understanding the image size of pharo. > I monitored it since we started and I did not recognize > a notably change. So I took a pharo 10073 and squeak 3.10.2 > for comparsion. yes frustrating after removing MVC and more. > > Amount classes, amount methods and lines of code are all 10% > less in pharo. But the image is approx. 0,5% - 1% smaller > than the squeak one. > > To clarify this. I closed all windows and did condenseChanges > and garbageCollect, flushed the monticello cache... > > What could be the reason for this? > > thanks, > > Norbert > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by StÃ©phane Ducasse

what is the principal behind yoru atomic loading? - Another namespace - one become When we talk about atomic loading we mean that we should be able to change the code of a compiler while this one is currently compiling the changes that should loaded. Similarly, we should be able to modify the method that is currently been executed and showing the progress bar. Stef On Sep 19, 2008, at 10:06 AM, Joseph Pelrine wrote: > Hi Stef, > > StÃ©phane Ducasse wrote: >>> We have two important fixes: compiler fixes and trait that are in >>> Changesets or cannot be loaded (in the case of the compiler >>> with MC). >>> I suggest for now to add them as changesets >>> Then we should keep the Compiler package to evaluate if MC1.6 >>> can be used. >>> I asked matthew to see if he can load the package. >>> >>> I still believe that having atomic loading in pharo is important. > I had atomic loading working in Squeak ca. 10 years ago, and I'm > currently getting it working in Pharo, because I need it for a > project I'm working on. As I told you, I'm quite happy to give it to > you if you want to use it. > > Cheers > -- > Joseph Pelrine [ | ] > MetaProg GmbH > Email: jpelrine(a)metaprog.com > Web: http://www.metaprog.com > > You don't become enormously successful without encountering some > really interesting problems. > - Mark Victor Hansen > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by StÃ©phane Ducasse

Ok our concern is that we cannot throw away our current architecture squeaksource and so on. Since this is a really important communication medium within the squeak community. But we will see. Stef On Sep 19, 2008, at 10:06 AM, Joseph Pelrine wrote: > Hi Stef, > > StÃ©phane Ducasse wrote: >>> We have two important fixes: compiler fixes and trait that are in >>> Changesets or cannot be loaded (in the case of the compiler >>> with MC). >>> I suggest for now to add them as changesets >>> Then we should keep the Compiler package to evaluate if MC1.6 >>> can be used. >>> I asked matthew to see if he can load the package. >>> >>> I still believe that having atomic loading in pharo is important. > I had atomic loading working in Squeak ca. 10 years ago, and I'm > currently getting it working in Pharo, because I need it for a > project I'm working on. As I told you, I'm quite happy to give it to > you if you want to use it. > > Cheers > -- > Joseph Pelrine [ | ] > MetaProg GmbH > Email: jpelrine(a)metaprog.com > Web: http://www.metaprog.com > > You don't become enormously successful without encountering some > really interesting problems. > - Mark Victor Hansen > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

Re: [Pharo-project] 10073 error

by StÃ©phane Ducasse

May be got an hiccup bvecause it is working for me. I will retry then stef On Sep 19, 2008, at 10:01 AM, Marcus Denker wrote: > > On 19.09.2008, at 09:19, StÃ©phane Ducasse wrote: > >> Hi >> >> I took 10072 and pressed update. >> After 10 or 15 min I got >> >> DoIt ^ server aborted early >> >> So may be the server stopped in the middle. >> > > I think gforge was down this morning... > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 19, 2008

[Pharo-project] Image size

by Norbert Hartl

Hi, I have problems in understanding the image size of pharo. I monitored it since we started and I did not recognize a notably change. So I took a pharo 10073 and squeak 3.10.2 for comparsion. Amount classes, amount methods and lines of code are all 10% less in pharo. But the image is approx. 0,5% - 1% smaller than the squeak one. To clarify this. I closed all windows and did condenseChanges and garbageCollect, flushed the monticello cache... What could be the reason for this? thanks, Norbert

Sept. 19, 2008

Re: [Pharo-project] CS in pharo

by Joseph Pelrine

Hi Stef, StÃ©phane Ducasse wrote: >> We have two important fixes: compiler fixes and trait that are in >> Changesets or cannot be loaded (in the case of the compiler >> with MC). >> I suggest for now to add them as changesets >> Then we should keep the Compiler package to evaluate if MC1.6 can >> be used. >> I asked matthew to see if he can load the package. >> >> I still believe that having atomic loading in pharo is important. I had atomic loading working in Squeak ca. 10 years ago, and I'm currently getting it working in Pharo, because I need it for a project I'm working on. As I told you, I'm quite happy to give it to you if you want to use it. Cheers -- Joseph Pelrine [ | ] MetaProg GmbH Email: jpelrine(a)metaprog.com Web: http://www.metaprog.com You don't become enormously successful without encountering some really interesting problems. - Mark Victor Hansen

Sept. 19, 2008

Re: [Pharo-project] 10073 error

by Marcus Denker

On 19.09.2008, at 09:19, StÃ©phane Ducasse wrote: > Hi > > I took 10072 and pressed update. > After 10 or 15 min I got > > DoIt ^ server aborted early > > So may be the server stopped in the middle. > I think gforge was down this morning... Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 19, 2008

[Pharo-project] CS in pharo

by StÃ©phane Ducasse

> We have two important fixes: compiler fixes and trait that are in > Changesets or cannot be loaded (in the case of the compiler > with MC). > I suggest for now to add them as changesets > Then we should keep the Compiler package to evaluate if MC1.6 can > be used. > I asked matthew to see if he can load the package. > > I still believe that having atomic loading in pharo is important. > > > > Stef > > >> Issue 167: Please check the traits fixes >> http://code.google.com/p/pharo/issues/detail?id=167 >> >> Comment #2 by adrian.lienhard: >> additionally remove caching of marker methods and make condensing >> work >> looks good now >> >> how do we integrate this since it is a changeset? >> >> Attachments: >> TraitsSharingCM-3.cs 14.6 KB > > > > > > >

Sept. 19, 2008

[Pharo-project] 10073 error

by StÃ©phane Ducasse

Hi I took 10072 and pressed update. After 10 or 15 min I got DoIt ^ server aborted early So may be the server stopped in the middle. Stef

Sept. 19, 2008

[Pharo-project] Copyright inside one click is strange

by StÃ©phane Ducasse

it says Distribution based on Sophie http://www.sophieproject.org/ Seaside http://www.seaside.st Stef

Sept. 19, 2008

Re: [Pharo-project] [ANN] update 10073

by StÃ©phane Ducasse

On Sep 18, 2008, at 5:15 PM, Adrian Lienhard wrote: > > On Sep 18, 2008, at 16:36 , StÃ©phane Ducasse wrote: >> >> About traits I was thinking to implement the protocol we designed >> at ESUG. > > what's that? > >> I would like to define some tests also to cover that CM are really >> duplicated. > > btw., I'm in the process of making http://code.google.com/p/pharo/issues/detail?id=167 > work correctly... why It was broken? > that is, I'm looking forward for your test ;) Yes I should really write something.... (fixig again the floor). I hope to get done after the week end. something like... ============================================= A method belong to a trait or a class. how do we query such belonging. T1 c Class A foo uses: T1 + alias T1>>c = c2 (A>>c2) selector -> c2 (A>>c) selector -> c (T>>c) selector -> c (A>>foo) class -> A (A>>c2) class -> A (A>>c) class -> A ***(T1>>c) class -> nil or T1 ? ** (A>>foo) trait -> nil (T1>>c2) trait -> Exception (T1>>c) trait -> T1 (A>>c) trait -> T1 ============================================= T1 c Class A foo uses: T1 + alias T1>>c = c2 Class B uses: T1 (A>>c2) selector -> c2 (A>>c) selector -> c (B>>c) selector -> c (T>>c) selector -> c (A>>foo) class -> A (A>>c2) class -> A (A>>c) class -> A (B>>c) class -> B (A>>foo) trait -> nil (T1>>c2) trait -> Exception (T1>>c) trait -> T1 (B>>c) trait -> T1 (A>>c) trait -> T1 ============================================= T1 c c1 T2 c c2 uses: T1 Class A foo uses: T2 (A>>c2) selector -> c2 (A>>c) selector -> c (T2>>c) selector -> c (T1>>c) selector -> c (A>>foo) class -> A (A>>c2) class -> A (A>>c) class -> A (A>>c1) class -> A (T1>>c1) class -> ???? T1 or nil (T2>>c1) (T2>>c2) class -> ???? T2 or nil (A>>foo) trait -> nil (A>>c2) trait -> T2 (A>>c) trait -> T2 (A>>c1) trait -> T2 ***** since it is flat (T1>>c1) trait -> ???? T1 or nil (T2>>c1) trait (T2>>c2) trait -> ???? T2 or nil origin = definingClassOrTrait (A>>foo) origin -> A (A>>c2) origin -> T2 (A>>c1) origin -> T1 (A>>c) origin -> T2 ***** (T1>>c) origin -> T1 (T1>>c1) origin -> T1 The origin is the method that you changed (and not override) when you want to change a method in the flat view.

Sept. 18, 2008

Re: [Pharo-project] [ANN] update 10073

by Adrian Lienhard

On Sep 18, 2008, at 16:36 , StÃ©phane Ducasse wrote: > > About traits I was thinking to implement the protocol we designed at > ESUG. what's that? > I would like to define some tests also to cover that CM are really > duplicated. btw., I'm in the process of making http://code.google.com/p/pharo/issues/detail?id=167 work correctly... that is, I'm looking forward for your test ;) Adrian

Sept. 18, 2008

Re: [Pharo-project] [ANN] update 10073

by StÃ©phane Ducasse

Thanks. About traits I was thinking to implement the protocol we designed at ESUG. I would like to define some tests also to cover that CM are really duplicated. >>> >> in two words what was that? > > > 006472: TraitBehavior>>#allClassVarNames is undefined > Description > TraitBehavior contains class compatibility messages. However > #allClassVarNames is not implemented. > eCompletion crashes often because of that. Attached patch > implemented this missing method. Tx

Sept. 18, 2008

Re: [Pharo-project] [ANN] update 10073

by Marcus Denker

On 18.09.2008, at 14:02, StÃ©phane Ducasse wrote: > > On Sep 18, 2008, at 12:26 PM, Marcus Denker wrote: > >> update 10073 >> ------------ >> >> - Issue 44: 7094 FixClassCompatibilityForClassVar (M6472) > > in two words what was that? 006472: TraitBehavior>>#allClassVarNames is undefined Description TraitBehavior contains class compatibility messages. However #allClassVarNames is not implemented. eCompletion crashes often because of that. Attached patch implemented this missing method. > > >> >> - Issue 86: 7138 TransformationMorph-isSticky >> - Issue 89: 7141 PrintingArraysWithMetaclasses >> - Issue 42: 7092 TTCFontDNUfix (M5309) >> - Issue 176:failing tests in 70072 >> - delete ParagraphEditor>>#initializeTextEditorMenus (never called, >> has undeclared) >> - revert Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej (broke >> tests) >> - MorphExtension now stores properties in SmallIdentityDictionary. >> - in loadscript: Smalltalk associations do: [:each | each >> beReadWriteBindingAnnouncing: true] >> >> >> Because it recompiles all methods multiple times, the update takes >> a while to load. >> (this is to be able to remove ReadOnlyVariableBinding, which has >> never seen any use) > > Excellent! > > Stef >> >> >> Marcus >> >> -- >> Marcus Denker -- denker(a)iam.unibe.ch >> http://www.iam.unibe.ch/~denker >> >> >> _______________________________________________ >> 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 -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by StÃ©phane Ducasse

I agree but we should look at them also from time to time. :) On Sep 18, 2008, at 10:27 AM, Marcus Denker wrote: > Hi, > > There are reports in the pharo tracker that are not solvable because > the software the bug > is reported about is not part of pharo. > > I wonder if that makes sense... from the bug-fixing of Squeak, I > have found that it's very > important to keep the numner of open issues as small as possible. > (the nearly 1000 open reports > they gatheres when doing 3.10 in Squeak is completely unmanagable, > for example). > > I would suggest to put these reports on a wiki page, instead of the > bugstracker. Or report them > to the developers of the package. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 18, 2008

Re: [Pharo-project] [ANN] update 10073

by StÃ©phane Ducasse

On Sep 18, 2008, at 12:26 PM, Marcus Denker wrote: > update 10073 > ------------ > > - Issue 44: 7094 FixClassCompatibilityForClassVar (M6472) in two words what was that? > > - Issue 86: 7138 TransformationMorph-isSticky > - Issue 89: 7141 PrintingArraysWithMetaclasses > - Issue 42: 7092 TTCFontDNUfix (M5309) > - Issue 176:failing tests in 70072 > - delete ParagraphEditor>>#initializeTextEditorMenus (never called, > has undeclared) > - revert Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej (broke > tests) > - MorphExtension now stores properties in SmallIdentityDictionary. > - in loadscript: Smalltalk associations do: [:each | each > beReadWriteBindingAnnouncing: true] > > > Because it recompiles all methods multiple times, the update takes a > while to load. > (this is to be able to remove ReadOnlyVariableBinding, which has > never seen any use) Excellent! Stef > > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Norbert Hartl

On Thu, 2008-09-18 at 12:34 +0200, Adrian Lienhard wrote: > On Sep 18, 2008, at 11:58 , Norbert Hartl wrote: > > > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: > >> Hi, > >> > >> There are reports in the pharo tracker that are not solvable because > >> the software the bug > >> is reported about is not part of pharo. > >> > >> I wonder if that makes sense... from the bug-fixing of Squeak, I have > >> found that it's very > >> important to keep the numner of open issues as small as possible. > >> (the > >> nearly 1000 open reports > >> they gatheres when doing 3.10 in Squeak is completely unmanagable, > >> for > >> example). > >> > >> I would suggest to put these reports on a wiki page, instead of the > >> bugstracker. Or report them > >> to the developers of the package. > > > > I put all of those tickets into the tracker. As pharo started it did > > it from 3.9 and not from 3.10. We agreed that we should have a look at > > all changes made in 3.10 to include the important ones. So it was the > > right choice to put all into the pharo tracker. > > yes, I think this made a lot of sense for the issues fixed in 3.10. We > dealt with a couple of them already and now we can decide which ones > we want to fix and which ones to ignore. > Norbert, did you create issues for each change that went into 3.10? > Yes! I worked through the update stream to find every single update. After that I tried to assign them to the right set of mantis reports. For every update number in squeak I opened a ticket and included the information about the mantis tickets as well. I started to change every subject line to include the mantis bug number(s). But this far I have only added this to one third of the tickets. But I'll do the rest in the near future. Norbert > > You are right that it is much more clever to have a look at a problem > > _before_ opening a ticket. But this way you lose an automatic way to > > keep track of the things "already dealt with". That's the same reason > > I included the mantis ticket number in the subject of the pharo > > tickets. > > This way you can easily and fast find the ticket number in the pharo > > tracker. Knowing that an issue from mantis has been dealt with in > > pharo > > has its value, too. > > > > We have to build a convention how to do it. > > I think for the Mantis issues other than the ones that went into 3.10 > we should only create issues in our bugtracker if we explicitly want > to integrate a fix. I.e., we should not automatically create issues > for all issues created in Mantis (would be too much work anyway). Like > this we can keep the number of open reports low as Marcus suggests. > > Adrian > > > > > > > > > Norbert > > > > > > > > > > _______________________________________________ > > 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

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Adrian Lienhard

On Sep 18, 2008, at 11:58 , Norbert Hartl wrote: > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: >> Hi, >> >> There are reports in the pharo tracker that are not solvable because >> the software the bug >> is reported about is not part of pharo. >> >> I wonder if that makes sense... from the bug-fixing of Squeak, I have >> found that it's very >> important to keep the numner of open issues as small as possible. >> (the >> nearly 1000 open reports >> they gatheres when doing 3.10 in Squeak is completely unmanagable, >> for >> example). >> >> I would suggest to put these reports on a wiki page, instead of the >> bugstracker. Or report them >> to the developers of the package. > > I put all of those tickets into the tracker. As pharo started it did > it from 3.9 and not from 3.10. We agreed that we should have a look at > all changes made in 3.10 to include the important ones. So it was the > right choice to put all into the pharo tracker. yes, I think this made a lot of sense for the issues fixed in 3.10. We dealt with a couple of them already and now we can decide which ones we want to fix and which ones to ignore. Norbert, did you create issues for each change that went into 3.10? > You are right that it is much more clever to have a look at a problem > _before_ opening a ticket. But this way you lose an automatic way to > keep track of the things "already dealt with". That's the same reason > I included the mantis ticket number in the subject of the pharo > tickets. > This way you can easily and fast find the ticket number in the pharo > tracker. Knowing that an issue from mantis has been dealt with in > pharo > has its value, too. > > We have to build a convention how to do it. I think for the Mantis issues other than the ones that went into 3.10 we should only create issues in our bugtracker if we explicitly want to integrate a fix. I.e., we should not automatically create issues for all issues created in Mantis (would be too much work anyway). Like this we can keep the number of open reports low as Marcus suggests. Adrian > > > Norbert > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Marcus Denker

On 18.09.2008, at 11:58, Norbert Hartl wrote: > On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: >> Hi, >> >> There are reports in the pharo tracker that are not solvable because >> the software the bug >> is reported about is not part of pharo. >> >> I wonder if that makes sense... from the bug-fixing of Squeak, I have >> found that it's very >> important to keep the numner of open issues as small as possible. >> (the >> nearly 1000 open reports >> they gatheres when doing 3.10 in Squeak is completely unmanagable, >> for >> example). >> >> I would suggest to put these reports on a wiki page, instead of the >> bugstracker. Or report them >> to the developers of the package. > > I put all of those tickets into the tracker. No, these are great! The problem are more reports about OB, AST, RB and things like that... > As pharo started it did > it from 3.9 and not from 3.10. We agreed that we should have a look at > all changes made in 3.10 to include the important ones. So it was the > right choice to put all into the pharo tracker. > > You are right that it is much more clever to have a look at a problem > _before_ opening a ticket. But this way you lose an automatic way to > keep track of the things "already dealt with". That's the same reason > I included the mantis ticket number in the subject of the pharo > tickets. > This way you can easily and fast find the ticket number in the pharo > tracker. Knowing that an issue from mantis has been dealt with in > pharo > has its value, too. > > We have to build a convention how to do it. > -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

[Pharo-project] [ANN] update 10073

by Marcus Denker

update 10073 ------------ - Issue 44: 7094 FixClassCompatibilityForClassVar (M6472) - Issue 86: 7138 TransformationMorph-isSticky - Issue 89: 7141 PrintingArraysWithMetaclasses - Issue 42: 7092 TTCFontDNUfix (M5309) - Issue 176:failing tests in 70072 - delete ParagraphEditor>>#initializeTextEditorMenus (never called, has undeclared) - revert Issue 95: 7149 ChangeHooksTest-tearDown-M6702-rej (broke tests) - MorphExtension now stores properties in SmallIdentityDictionary. - in loadscript: Smalltalk associations do: [:each | each beReadWriteBindingAnnouncing: true] Because it recompiles all methods multiple times, the update takes a while to load. (this is to be able to remove ReadOnlyVariableBinding, which has never seen any use) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Norbert Hartl

On Thu, 2008-09-18 at 10:27 +0200, Marcus Denker wrote: > Hi, > > There are reports in the pharo tracker that are not solvable because > the software the bug > is reported about is not part of pharo. > > I wonder if that makes sense... from the bug-fixing of Squeak, I have > found that it's very > important to keep the numner of open issues as small as possible. (the > nearly 1000 open reports > they gatheres when doing 3.10 in Squeak is completely unmanagable, for > example). > > I would suggest to put these reports on a wiki page, instead of the > bugstracker. Or report them > to the developers of the package. I put all of those tickets into the tracker. As pharo started it did it from 3.9 and not from 3.10. We agreed that we should have a look at all changes made in 3.10 to include the important ones. So it was the right choice to put all into the pharo tracker. You are right that it is much more clever to have a look at a problem _before_ opening a ticket. But this way you lose an automatic way to keep track of the things "already dealt with". That's the same reason I included the mantis ticket number in the subject of the pharo tickets. This way you can easily and fast find the ticket number in the pharo tracker. Knowing that an issue from mantis has been dealt with in pharo has its value, too. We have to build a convention how to do it. Norbert

Sept. 18, 2008

Re: [Pharo-project] Bugs on bugs.squeak.org

by Adrian Lienhard

I agree. I spend a lot of time trying to understand Mantis reports because there typically are duplicates and related reports and fixes proposed are later reported being buggy etc. Adrian On Sep 18, 2008, at 10:43 , Marcus Denker wrote: > Hi, > > bugs.squeak.org is a mess. (and people wonder why I always stress > that doing harvesting was a lot of work... we got > the tracker down to 250 entries with 3.9, if I remember correctly). > > Even for 3.11, they will have some real work ahead to get this in > some form of managable shape. > > Now for Pharo, I don't see that we can benefit from the bug-tracker > at all anymore: there is so much stuff, no > way to do here anything in a strategic, "all covering" way, as we > did for example when moving from BFAV to Mantis. > > So if someone has reported a bug against Squeak, the only way I see > this change ending up in pharo is that the > bug is reported again on the pharo tracker. So if you want something > to be fixed: > > http://code.google.com/p/pharo/issues/list > > (down to 79 open issues, we already fixed and closed 96 reports) > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

Re: [Pharo-project] Non-pharo reports in pharo bugtracker...

by Adrian Lienhard

+1 On Sep 18, 2008, at 10:27 , Marcus Denker wrote: > Hi, > > There are reports in the pharo tracker that are not solvable because > the software the bug > is reported about is not part of pharo. > > I wonder if that makes sense... from the bug-fixing of Squeak, I > have found that it's very > important to keep the numner of open issues as small as possible. > (the nearly 1000 open reports > they gatheres when doing 3.10 in Squeak is completely unmanagable, > for example). > > I would suggest to put these reports on a wiki page, instead of the > bugstracker. Or report them > to the developers of the package. > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 18, 2008

[Pharo-project] Bugs on bugs.squeak.org

by Marcus Denker

Hi, bugs.squeak.org is a mess. (and people wonder why I always stress that doing harvesting was a lot of work... we got the tracker down to 250 entries with 3.9, if I remember correctly). Even for 3.11, they will have some real work ahead to get this in some form of managable shape. Now for Pharo, I don't see that we can benefit from the bug-tracker at all anymore: there is so much stuff, no way to do here anything in a strategic, "all covering" way, as we did for example when moving from BFAV to Mantis. So if someone has reported a bug against Squeak, the only way I see this change ending up in pharo is that the bug is reported again on the pharo tracker. So if you want something to be fixed: http://code.google.com/p/pharo/issues/list (down to 79 open issues, we already fixed and closed 96 reports) Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

[Pharo-project] Non-pharo reports in pharo bugtracker...

by Marcus Denker

Hi, There are reports in the pharo tracker that are not solvable because the software the bug is reported about is not part of pharo. I wonder if that makes sense... from the bug-fixing of Squeak, I have found that it's very important to keep the numner of open issues as small as possible. (the nearly 1000 open reports they gatheres when doing 3.10 in Squeak is completely unmanagable, for example). I would suggest to put these reports on a wiki page, instead of the bugstracker. Or report them to the developers of the package. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Sept. 18, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Alexandre Bergel

> p.s. Alexander, please don't edit Installer and break it for everyone > else. Installer is for all squeak images, not just for Pharo. > p.p.s. Please keep sufficient compatibility in Pharo so at least > Installer can get past the initial bootstrap. Ah!! Some methods are deprecated solely in Pharo. Since Installer is calling some deprecated methods in Pharo, some unit tests related to the authoring go red because these test check there is no call do this deprecated method in the image. Probably this test should be moved somethere else. Maybe having an image verifier or something would help to ensure some basic invariant in the image (such as no call to deprecated method). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

>>> >>>> HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' >>>> > > The LPF script only loads MC1.5 you need to load SystemEditor and > enable > the atomic loading preference. > This will do it. OK > > Installer install: 'Monticello16-Beta'. > >>> - do you have a version of MC1.6 that does not really on LPF >>> (whatever)? >>> >> >> No; LPF is the script to load MC1.5. However, I think I'll try >> moving LPF off of pbwiki and into something that builds a .sar >> file, hosted on svn or squeaksource or something. >> > The first half of the script is the bootstrap of Installer in > http://installer.pbwiki.com/f/LPF.st > > The second half of the script is available via > > Installer view: 'LevelPlayingField'. > > Keith > > p.s. Alexander, please don't edit Installer and break it for everyone > else. Installer is for all squeak images, not just for Pharo. Can you tell us what were the changes? > p.p.s. Please keep sufficient compatibility in Pharo so at least > Installer can get past the initial bootstrap. Sure.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by StÃ©phane Ducasse

Hi matthew did you try to load the package I mentioned? > > No; LPF is the script to load MC1.5. However, I think I'll try > moving LPF off of pbwiki and into something that builds a .sar > file, hosted on svn or squeaksource or something. Sounds the way to go. We will never rely on a script on a web site.

Sept. 17, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Keith Hodges

Matthew Fulmer wrote: > On Fri, Sep 12, 2008 at 05:41:17PM +0200, St?phane Ducasse wrote: > >> Hi matthew >> >> we wanted to see if MC1.6 (the one with actomic loader) could load the >> compiler fixes >> Compiler-md.67 available in pharoInbox >> >> We tried >> >>> HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' >>> The LPF script only loads MC1.5 you need to load SystemEditor and enable the atomic loading preference. This will do it. Installer install: 'Monticello16-Beta'. >> and it broke on us. >> >> so two requests: >> - could you give a try and tell us if you can load the package? >> > > No; it is broken for everybody. I've heard this report a couple > of times. It seems we need to change the hosting of LPF > > No we dont, we just have to slow requests down a bit. I put a couple of delays in it should work now >> - do you have a version of MC1.6 that does not really on LPF >> (whatever)? >> > > No; LPF is the script to load MC1.5. However, I think I'll try > moving LPF off of pbwiki and into something that builds a .sar > file, hosted on svn or squeaksource or something. > The first half of the script is the bootstrap of Installer in http://installer.pbwiki.com/f/LPF.st The second half of the script is available via Installer view: 'LevelPlayingField'. Keith p.s. Alexander, please don't edit Installer and break it for everyone else. Installer is for all squeak images, not just for Pharo. p.p.s. Please keep sufficient compatibility in Pharo so at least Installer can get past the initial bootstrap.

Sept. 16, 2008

Re: [Pharo-project] Call for ideas for a Continuous Integration server

by Alexandre Bergel

Sorry about this email, it essentially says that I need to go to sleep... Alexandre On 16 Sep 2008, at 23:07, Alexandre Bergel wrote: > Dear List, > > Here are the notes I took on AmbientTalk. > > In Ambientalk: > > Table: > >def table[5] { z := z + 1 } > >>[1, 2, 3, 4, 5] > > > Table splicing: > >[1,@[2,3],4] > >>[1, 2, 3, 4] > >def [first, @rest] := [1,2,3,4] > >>[1, 2, 3, 4] > >rest > >>[2, 3, 4] > > > Function > >def square (x) { x*x } > >>nil > >square(5) > >>25 > > There is no check about fulfilling required methods. There is a way > to declare a method as required. > Required method are part of a structural type. Reflection is then > used to ensure that a composition makes sense at composition time. > Aliasing changes the name on the surface (it is not a rename), and > does not create a new entry. > The import clause (which is used to use a trait), may accept any > expression, and not only a trait name. > There is no precedence of the locally defined methods. > > Note that traits are composed when object composer are instantiated. > > Ambientalk may use the same trick than in Smalltalk to declare a > method as required (self requiredMethod), but the lack of precedency > is problematic. > The fact that you do not have precedency, implies that a method used > in a trait needs to be specify as required (using the reflective > trick mentioned above) in case of the composer is likely to not > provide an implementation for this method. Else, better is not mark > the used method as required since the composer will have to exclude > it when using the trait. > > Two methods that are acquired using different import path are not > conflicting since they are the same compiled method. > In Ambientalk, this will always cause a conflict since methods are > âduplicatedâ between composers. In Ambientalk, deep equality (i.e., > comparing bytecode instructions) may not lead to what we want since > methods can be nested. > > The Morphic framework. > Inspired from the Self version and has been influenced by John > Maloneyâs work. > Requirement between traits is specified with for exemple require: > [Trait1, Trait2], in that case, all public methods defined in Trait1 > and Trait2 will be set as required method for the trait that made > the require. > This framework is composed of 18 traits > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2008

[Pharo-project] Call for ideas for a Continuous Integration server

by Alexandre Bergel

Dear List, Here are the notes I took on AmbientTalk. In Ambientalk: Table: >def table[5] { z := z + 1 } >>[1, 2, 3, 4, 5] Table splicing: >[1,@[2,3],4] >>[1, 2, 3, 4] >def [first, @rest] := [1,2,3,4] >>[1, 2, 3, 4] >rest >>[2, 3, 4] Function >def square (x) { x*x } >>nil >square(5) >>25 There is no check about fulfilling required methods. There is a way to declare a method as required. Required method are part of a structural type. Reflection is then used to ensure that a composition makes sense at composition time. Aliasing changes the name on the surface (it is not a rename), and does not create a new entry. The import clause (which is used to use a trait), may accept any expression, and not only a trait name. There is no precedence of the locally defined methods. Note that traits are composed when object composer are instantiated. Ambientalk may use the same trick than in Smalltalk to declare a method as required (self requiredMethod), but the lack of precedency is problematic. The fact that you do not have precedency, implies that a method used in a trait needs to be specify as required (using the reflective trick mentioned above) in case of the composer is likely to not provide an implementation for this method. Else, better is not mark the used method as required since the composer will have to exclude it when using the trait. Two methods that are acquired using different import path are not conflicting since they are the same compiled method. In Ambientalk, this will always cause a conflict since methods are âduplicatedâ between composers. In Ambientalk, deep equality (i.e., comparing bytecode instructions) may not lead to what we want since methods can be nested. The Morphic framework. Inspired from the Self version and has been influenced by John Maloneyâs work. Requirement between traits is specified with for exemple require: [Trait1, Trait2], in that case, all public methods defined in Trait1 and Trait2 will be set as required method for the trait that made the require. This framework is composed of 18 traits -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Sept. 16, 2008

Re: [Pharo-project] Re: Monticello 1.5

by Matthew Fulmer

On Fri, Sep 12, 2008 at 05:41:17PM +0200, St?phane Ducasse wrote: > Hi matthew > > we wanted to see if MC1.6 (the one with actomic loader) could load the > compiler fixes > Compiler-md.67 available in pharoInbox > > We tried > > HTTPSocket httpFileIn: 'installer.pbwiki.org/f/LPF.st' > > and it broke on us. > > so two requests: > - could you give a try and tell us if you can load the package? No; it is broken for everybody. I've heard this report a couple of times. It seems we need to change the hosting of LPF > - do you have a version of MC1.6 that does not really on LPF > (whatever)? No; LPF is the script to load MC1.5. However, I think I'll try moving LPF off of pbwiki and into something that builds a .sar file, hosted on svn or squeaksource or something. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Sept. 16, 2008

Re: [Pharo-project] Re: is pharo ready for production?

by StÃ©phane Ducasse

esteban I think that you can really use pharo for development and give us feedback. for deployment you may switch in alpha phase if needed. The path will be long but the journey is really worth :) Stef On Sep 16, 2008, at 8:06 PM, Esteban Lorenzano wrote: > Hi, > Thanks for the answers. > The main reason I want to run the application on Pharo is because > I'm agree with it's objetives, and I been following the project > advance through the list and I'm very happy with the ongoing work. > Unfortunately, I'm to busy to offer some help... but maybe I can > help on "testing" by using Pharo on a commercial project... > So, following Adrian suggestion, as my project will take 4-5 months > of development, I think the best path should be to wait a little and > start using Pharo in a couple of months. > And of course, I want to produce professional applications, so what > better to use a professional version of squeak? :) > > Cheers, > Esteban > > On 2008-09-16 13:49:48 -0300, Adrian Lienhard <adi(a)netstyle.ch> said: > >> Hi Esteban >> As Stef said, you should not run into major problems because the core >> on which a Seaside application usually depends has not changed >> much. The parts of Pharo that have undergone major changes (or >> that have been totally removed) will likely not affect you. >> I think that you should also take into account when you plan to go >> live. If this is in just another week or two, I would not go for >> Pharo. However, if this is a larger project that takes longer, then I >> suggest to use Pharo. I think we will be fast to fix bugs if you >> report them (whereas at the Squeak side the activity seems to be a >> bit >> less than over here ;)). And over time more and more people will >> start >> to use Pharo in professional projects too. >> Please let us know how you decide and in case you run into any >> troubles that need our attention. >> Cheers, >> Adrian >> On Sep 16, 2008, at 18:02 , StÃ©phane Ducasse wrote: >>> Hi Esteban >>> Lukas is developing seaside on pharo. Netstyle will certainly use it >>> once the first release is out. >>> Now the point is do you need the improvements we are doing? >>> May be 3.9 is good enough or pavel image. >>> From a stability point of view the changes are currently low from >>> api changes - we are cleaning a lot >>> but not changing. And this may change a bit in the >>> future but this is ineluctable. If people want something better they >>> have to ack changes. >>> We will also try to keep changes to the minimum but not less. We >>> want a better system >>> and as such it will change. >>> Stef >>> On Sep 16, 2008, at 5:39 PM, Esteban Lorenzano wrote: >>>> Hi, >>>> I'm planning to start a new commercial, seaside based project in a >>>> few weeks, and I wish to start it in Pharo, but I'm afraid is >>>> not very stable yet... >>>> Can somebody tell me if is usable right now and if not, more or >>>> less when it will be? >>>> Thanks, >>>> Esteban >>>> _______________________________________________ >>>> 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 >

Sept. 16, 2008

[Pharo-project] Re: is pharo ready for production?

by Esteban Lorenzano

Hi, Thanks for the answers. The main reason I want to run the application on Pharo is because I'm agree with it's objetives, and I been following the project advance through the list and I'm very happy with the ongoing work. Unfortunately, I'm to busy to offer some help... but maybe I can help on "testing" by using Pharo on a commercial project... So, following Adrian suggestion, as my project will take 4-5 months of development, I think the best path should be to wait a little and start using Pharo in a couple of months. And of course, I want to produce professional applications, so what better to use a professional version of squeak? :) Cheers, Esteban On 2008-09-16 13:49:48 -0300, Adrian Lienhard <adi(a)netstyle.ch> said: > Hi Esteban > > As Stef said, you should not run into major problems because the core > on which a Seaside application usually depends has not changed much. > The parts of Pharo that have undergone major changes (or that have > been totally removed) will likely not affect you. > > I think that you should also take into account when you plan to go > live. If this is in just another week or two, I would not go for > Pharo. However, if this is a larger project that takes longer, then I > suggest to use Pharo. I think we will be fast to fix bugs if you > report them (whereas at the Squeak side the activity seems to be a bit > less than over here ;)). And over time more and more people will start > to use Pharo in professional projects too. > > Please let us know how you decide and in case you run into any > troubles that need our attention. > > Cheers, > Adrian > > On Sep 16, 2008, at 18:02 , StÃ©phane Ducasse wrote: > >> Hi Esteban >> >> Lukas is developing seaside on pharo. Netstyle will certainly use it > >> once the first release is out. >> Now the point is do you need the improvements we are doing? >> May be 3.9 is good enough or pavel image. >> >> From a stability point of view the changes are currently low from > >> api changes - we are cleaning a lot >> but not changing. And this may change a bit in the >> future but this is ineluctable. If people want something better they > >> have to ack changes. >> We will also try to keep changes to the minimum but not less. We want >> a better system >> and as such it will change. >> >> Stef >> >> >> >> On Sep 16, 2008, at 5:39 PM, Esteban Lorenzano wrote: >> >>> Hi, >>> I'm planning to start a new commercial, seaside based project in a > >>> few weeks, and I wish to start it in Pharo, but I'm afraid is not very >>> stable yet... >>> Can somebody tell me if is usable right now and if not, more or less >>> when it will be? >>> >>> Thanks, >>> Esteban >>> >>> >>> >>> _______________________________________________ >>> 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

Sept. 16, 2008

Re: [Pharo-project] is pharo ready for production?

by Adrian Lienhard

Hi Esteban As Stef said, you should not run into major problems because the core on which a Seaside application usually depends has not changed much. The parts of Pharo that have undergone major changes (or that have been totally removed) will likely not affect you. I think that you should also take into account when you plan to go live. If this is in just another week or two, I would not go for Pharo. However, if this is a larger project that takes longer, then I suggest to use Pharo. I think we will be fast to fix bugs if you report them (whereas at the Squeak side the activity seems to be a bit less than over here ;)). And over time more and more people will start to use Pharo in professional projects too. Please let us know how you decide and in case you run into any troubles that need our attention. Cheers, Adrian On Sep 16, 2008, at 18:02 , StÃ©phane Ducasse wrote: > Hi Esteban > > Lukas is developing seaside on pharo. Netstyle will certainly use it > once the first release is out. > Now the point is do you need the improvements we are doing? > May be 3.9 is good enough or pavel image. > > From a stability point of view the changes are currently low from > api changes - we are cleaning a lot > but not changing. And this may change a bit in the > future but this is ineluctable. If people want something better they > have to ack changes. > We will also try to keep changes to the minimum but not less. We > want a better system > and as such it will change. > > Stef > > > > On Sep 16, 2008, at 5:39 PM, Esteban Lorenzano wrote: > >> Hi, >> I'm planning to start a new commercial, seaside based project in a >> few weeks, and I wish to start it in Pharo, but I'm afraid is not >> very stable yet... >> Can somebody tell me if is usable right now and if not, more or >> less when it will be? >> >> Thanks, >> Esteban >> >> >> >> _______________________________________________ >> 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

Sept. 16, 2008

Re: [Pharo-project] is pharo ready for production?

by StÃ©phane Ducasse

Hi Esteban Lukas is developing seaside on pharo. Netstyle will certainly use it once the first release is out. Now the point is do you need the improvements we are doing? May be 3.9 is good enough or pavel image. From a stability point of view the changes are currently low from api changes - we are cleaning a lot but not changing. And this may change a bit in the future but this is ineluctable. If people want something better they have to ack changes. We will also try to keep changes to the minimum but not less. We want a better system and as such it will change. Stef On Sep 16, 2008, at 5:39 PM, Esteban Lorenzano wrote: > Hi, > I'm planning to start a new commercial, seaside based project in a > few weeks, and I wish to start it in Pharo, but I'm afraid is not > very stable yet... > Can somebody tell me if is usable right now and if not, more or less > when it will be? > > Thanks, > Esteban > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2008