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

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by Levente Uzonyi

On Tue, 26 Oct 2010, StÃ©phane Ducasse wrote: > > On Oct 26, 2010, at 11:18 PM, Levente Uzonyi wrote: > >> On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: >> >>> HI Ramain (or someone with time). >>> >>> OCompletion does not work anymore in Pharo 1.2 because of the Preferences >>> removal. It would be nice if you could update it to use the new settings >>> framework. >> >> I fixed some of the preference issues (i didn't upload it yet), but it's a PITA to make it work in Pharo 1.2, because too many things were changed and are therefore broken. > > I can imagine. > We should really get a way to support automatic change application but this is a real job to build that. > >> Btw what's with the "keep deprecated stuff for the next 2 minor versions" policy? > > this is what we do: we will remove 1.1 deprecated methods in 1.3 alpha. May be we did not apply it totally and are messy with that > because we did not deprecated all the preferences methods. > >> Preferences are gone in 1.2, but Settings were only introduced in 1.1 and Preferences doesn't seem to be deprecated at all in 1.1. So, according to the policy, Preferences should be available till at least 1.3. > > the preferences class is just there in 1.2 to help people loading their code. but the behavior is gone. No, it's not there. At least not in the core image (12216). Levente > > Settings were introduced in 1.1 (but not used) so that people can migrate their code in 1.1 to save it in 1.2. > Alain reminds that recently. >> >> >> Levente >> >>> >>> There is information here: >>> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ >>> >>> Thanks >>> >>> mariano >>> >> >> _______________________________________________ >> 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 >

Oct. 26, 2010

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by StÃ©phane Ducasse

On Oct 26, 2010, at 11:18 PM, Levente Uzonyi wrote: > On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: > >> HI Ramain (or someone with time). >> >> OCompletion does not work anymore in Pharo 1.2 because of the Preferences >> removal. It would be nice if you could update it to use the new settings >> framework. > > I fixed some of the preference issues (i didn't upload it yet), but it's a PITA to make it work in Pharo 1.2, because too many things were changed and are therefore broken. I can imagine. We should really get a way to support automatic change application but this is a real job to build that. > Btw what's with the "keep deprecated stuff for the next 2 minor versions" policy? this is what we do: we will remove 1.1 deprecated methods in 1.3 alpha. May be we did not apply it totally and are messy with that because we did not deprecated all the preferences methods. > Preferences are gone in 1.2, but Settings were only introduced in 1.1 and Preferences doesn't seem to be deprecated at all in 1.1. So, according to the policy, Preferences should be available till at least 1.3. the preferences class is just there in 1.2 to help people loading their code. but the behavior is gone. Settings were introduced in 1.1 (but not used) so that people can migrate their code in 1.1 to save it in 1.2. Alain reminds that recently. > > > Levente > >> >> There is information here: >> http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ >> >> Thanks >> >> mariano >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2010

Re: [Pharo-project] OCompletion doesn't work in Pharo 1.2 because of Preferences delete

by Levente Uzonyi

On Tue, 26 Oct 2010, Mariano Martinez Peck wrote: > HI Ramain (or someone with time). > > OCompletion does not work anymore in Pharo 1.2 because of the Preferences > removal. It would be nice if you could update it to use the new settings > framework. I fixed some of the preference issues (i didn't upload it yet), but it's a PITA to make it work in Pharo 1.2, because too many things were changed and are therefore broken. Btw what's with the "keep deprecated stuff for the next 2 minor versions" policy? Preferences are gone in 1.2, but Settings were only introduced in 1.1 and Preferences doesn't seem to be deprecated at all in 1.1. So, according to the policy, Preferences should be available till at least 1.3. Levente > > There is information here: > http://book.pharo-project.org/book/CustomizingPharo/DeclaringSetting/ > > Thanks > > mariano >

Oct. 26, 2010

Re: [Pharo-project] Fwd: Cog VM doesn't start to listen on socket

by Lukas Renggli

No, I fixed it in Kom. Lukas On 26 October 2010 22:12, Tudor Girba <tudor.girba(a)gmail.com> wrote: > So, you always have to pass a script that restarts the server? This sounds like a workaround, right? > > Cheers, > Doru > > > On 26 Oct 2010, at 21:48, Lukas Renggli wrote: > >> Ok, I think I solved the issue. Restarting the server on startup seems >> to solve the problem on all my machines. >> >> Thanks again for the hints! >> >> Lukas >> >> On 26 October 2010 20:41, Lukas Renggli <renggli(a)gmail.com> wrote: >>> Thank you Eliot for the answer. I will have to investigate and see if >>> this is a Seaside specific issue or related to Kom. >>> >>> Lukas >>> >>> 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Eliot Miranda <eliot.miranda(a)gmail.com> >>>> Date: Tue, Oct 26, 2010 at 10:23 AM >>>> Subject: Re: Cog VM doesn't start to listen on socket >>>> To: Lukas Renggli <renggli(a)gmail.com> >>>> >>>> >>>> Hi Lukas, >>>> Â Â obviously we use sockets intensively in Teleplace and we see no problems >>>> that are to do with Cog. Â But Cog does throw up timing issues in your code >>>> because it has very different performance to the base VM (Smalltalk code is >>>> faster, most primitives have the same speed, allocation is slightly faster, >>>> etc). Â So my gut feeling is that what you're seeing is a timing related >>>> issue (race condition?) that is revealed when on Cog and hidden when on the >>>> normal VM. >>>> HTH (yeah, right... ed.) >>>> Eliot >>>> >>>> On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>>> >>>>> Hi Eliot, >>>>> >>>>> I noticed that on the Cog VM the Kom Seaside server does not >>>>> automatically start to listen, even if there is a process waiting at >>>>> the semaphore of the socket. Singaling that semaphore from the process >>>>> browser fixes the problem and the Cog image is fully working until the >>>>> next time it is opened. >>>>> >>>>> The exact same image opened with an old VM does not show the problem >>>>> and immediately starts to listen by itself. >>>>> >>>>> Did anybody else notice the same problem? Anybody found a solution? >>>>> >>>>> Lukas >>>>> >>>>> -- >>>>> Lukas Renggli >>>>> 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 >>>> >>> >>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >> >> >> >> -- >> Lukas Renggli >> 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 > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch

Oct. 26, 2010

Re: [Pharo-project] Fwd: Cog VM doesn't start to listen on socket

by Tudor Girba

So, you always have to pass a script that restarts the server? This sounds like a workaround, right? Cheers, Doru On 26 Oct 2010, at 21:48, Lukas Renggli wrote: > Ok, I think I solved the issue. Restarting the server on startup seems > to solve the problem on all my machines. > > Thanks again for the hints! > > Lukas > > On 26 October 2010 20:41, Lukas Renggli <renggli(a)gmail.com> wrote: >> Thank you Eliot for the answer. I will have to investigate and see if >> this is a Seaside specific issue or related to Kom. >> >> Lukas >> >> 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: >>> >>> >>> ---------- Forwarded message ---------- >>> From: Eliot Miranda <eliot.miranda(a)gmail.com> >>> Date: Tue, Oct 26, 2010 at 10:23 AM >>> Subject: Re: Cog VM doesn't start to listen on socket >>> To: Lukas Renggli <renggli(a)gmail.com> >>> >>> >>> Hi Lukas, >>> obviously we use sockets intensively in Teleplace and we see no problems >>> that are to do with Cog. But Cog does throw up timing issues in your code >>> because it has very different performance to the base VM (Smalltalk code is >>> faster, most primitives have the same speed, allocation is slightly faster, >>> etc). So my gut feeling is that what you're seeing is a timing related >>> issue (race condition?) that is revealed when on Cog and hidden when on the >>> normal VM. >>> HTH (yeah, right... ed.) >>> Eliot >>> >>> On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>>> >>>> Hi Eliot, >>>> >>>> I noticed that on the Cog VM the Kom Seaside server does not >>>> automatically start to listen, even if there is a process waiting at >>>> the semaphore of the socket. Singaling that semaphore from the process >>>> browser fixes the problem and the Cog image is fully working until the >>>> next time it is opened. >>>> >>>> The exact same image opened with an old VM does not show the problem >>>> and immediately starts to listen by itself. >>>> >>>> Did anybody else notice the same problem? Anybody found a solution? >>>> >>>> Lukas >>>> >>>> -- >>>> Lukas Renggli >>>> 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 >>> >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> > > > > -- > Lukas Renggli > 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 -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

Oct. 26, 2010

Re: [Pharo-project] Fwd: Cog VM doesn't start to listen on socket

by Lukas Renggli

Ok, I think I solved the issue. Restarting the server on startup seems to solve the problem on all my machines. Thanks again for the hints! Lukas On 26 October 2010 20:41, Lukas Renggli <renggli(a)gmail.com> wrote: > Thank you Eliot for the answer. I will have to investigate and see if > this is a Seaside specific issue or related to Kom. > > Lukas > > 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> ---------- Forwarded message ---------- >> From: Eliot Miranda <eliot.miranda(a)gmail.com> >> Date: Tue, Oct 26, 2010 at 10:23 AM >> Subject: Re: Cog VM doesn't start to listen on socket >> To: Lukas Renggli <renggli(a)gmail.com> >> >> >> Hi Lukas, >> Â Â Â obviously we use sockets intensively in Teleplace and we see no problems >> that are to do with Cog. Â But Cog does throw up timing issues in your code >> because it has very different performance to the base VM (Smalltalk code is >> faster, most primitives have the same speed, allocation is slightly faster, >> etc). Â So my gut feeling is that what you're seeing is a timing related >> issue (race condition?) that is revealed when on Cog and hidden when on the >> normal VM. >> HTH (yeah, right... ed.) >> Eliot >> >> On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >>> >>> Hi Eliot, >>> >>> I noticed that on the Cog VM the Kom Seaside server does not >>> automatically start to listen, even if there is a process waiting at >>> the semaphore of the socket. Singaling that semaphore from the process >>> browser fixes the problem and the Cog image is fully working until the >>> next time it is opened. >>> >>> The exact same image opened with an old VM does not show the problem >>> and immediately starts to listen by itself. >>> >>> Did anybody else notice the same problem? Anybody found a solution? >>> >>> Lukas >>> >>> -- >>> Lukas Renggli >>> 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 >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > -- Lukas Renggli www.lukas-renggli.ch

Oct. 26, 2010

Re: [Pharo-project] Fwd: Cog VM doesn't start to listen on socket

by Lukas Renggli

Thank you Eliot for the answer. I will have to investigate and see if this is a Seaside specific issue or related to Kom. Lukas 2010/10/26 Eliot Miranda <eliot.miranda(a)gmail.com>: > > > ---------- Forwarded message ---------- > From: Eliot Miranda <eliot.miranda(a)gmail.com> > Date: Tue, Oct 26, 2010 at 10:23 AM > Subject: Re: Cog VM doesn't start to listen on socket > To: Lukas Renggli <renggli(a)gmail.com> > > > Hi Lukas, > Â Â Â obviously we use sockets intensively in Teleplace and we see no problems > that are to do with Cog. Â But Cog does throw up timing issues in your code > because it has very different performance to the base VM (Smalltalk code is > faster, most primitives have the same speed, allocation is slightly faster, > etc). Â So my gut feeling is that what you're seeing is a timing related > issue (race condition?) that is revealed when on Cog and hidden when on the > normal VM. > HTH (yeah, right... ed.) > Eliot > > On Tue, Oct 26, 2010 at 5:04 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> >> Hi Eliot, >> >> I noticed that on the Cog VM the Kom Seaside server does not >> automatically start to listen, even if there is a process waiting at >> the semaphore of the socket. Singaling that semaphore from the process >> browser fixes the problem and the Cog image is fully working until the >> next time it is opened. >> >> The exact same image opened with an old VM does not show the problem >> and immediately starts to listen by itself. >> >> Did anybody else notice the same problem? Anybody found a solution? >> >> Lukas >> >> -- >> Lukas Renggli >> 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 > -- Lukas Renggli www.lukas-renggli.ch

Oct. 26, 2010

Re: [Pharo-project] Smells looking at collections

by Eliot Miranda

Hi Florin, 2010/10/26 Florin Mateoc <fmateoc(a)gmail.com> > Eliot wrote: > > Hi Levente, > > in my experience playing with the Dan and Alan Borning's multiple > inheritance implementation getting things to work was one thing, reasonably > straighforward, but getting tool support right (file-out format so that > things filed back in correctly, etc) was another, an dth ebulk of the work. > Looking at your proposal below I see no problem getting it to work but see > lots of problems integrating it, e.g. with Monticello, etc. Traits is > already integrated with Monticello, supported with tests, etc. As such it > is a much less risky or effortful proposition than a new scheme. So with > that in mind are there important functional benefits of your scheme's direct > state access as compared with traits that use accessors to access state that > each user of a trait must implement? i.e. what are the key benefits you see > in direct inst var access? > > best > Eliot > > > Hi Eliot, > > I think there is a strong argument for stateful traits, especially since we > are talking about collection smells. > One of the main selling points for traits (for me, at least) is that they > would allow us to clean up the mess > created by inheritance for reuse (Dictionary is a Set) in existing > libraries. > And obviously to create cleaner libraries going forward. > Well, inheritance for reuse is used not just for behavior, but for state as > well. > Stateful traits would allow for a cleaner separation between inheritance > and subtyping. > Stateful traits would even allow you to push the separation further and, as > part of your design, you could have state-only traits > complementing behavior-only traits. > Let us not forget that clean concepts are also easier to learn. I think it > is much more important to get the concepts right > than any existing integration with Monticello. Why does it matter that we > have tests and integration if people are not > using traits? > The argument is not over the utility of stateful traits. The argument is over how to access that state. The existing Traits implementation allows indirect access to state, where the Trait uses accessors that must be implemented by a class using the trait. This has the disadvantages listed by Levente, possibility of accessor selectors clashing with existing protocol, lack of privacy and poorer performance. One possible solution is to do a new traits implementation that supports state, but as discussed integration is hard and that could be a lot of work. There are other solutions to explore that could localise the changes. For example imagine adding some special illegal syntax that a variant of the compiler (a compiler mode or a subclass or...) can deal with and using that to reference trait state. Then changes are localised to - the compiler (to compile the syntax down onto the relevant inst vars) - class definition/trait composition (to ensure the state inst vars exist in the class) - shout (to highlight the new syntax) - the decompiler (so decompiled trait code displays the new syntax for trait state access) Another possibility might be a selector privacy hack. The selectors used to access state in a trait are known not to clash in the trait (they ca be so chosen by the trait author not to conflict with anything in the trait) but they cannot be guaranteed not to clash with a user of the trait. So post-compile the selectors for the trait's state could be changed to private values (keys that existed only in the method dictionary of the trait user). This doesn't have the performance of direct inst var access, but it solves the clash and privacy issues. And I expect there are other solutions too. In summary don't argue for or against stateful traits, instead think about how to add state to traits whilst having the most minimal impact on the rest of the infrastructure. best Eliot > Cheers, > Florin > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 26, 2010

Re: [Pharo-project] Proposal: adding 261 named colors

by StÃ©phane Ducasse

http://map.squeak.org/package/4fcb1d4d-ff16-46e2-bfa8-a7410f0cd5a3 Stef

Oct. 26, 2010

Re: [Pharo-project] About Adding/modifying in SUnit or not?

by StÃ©phane Ducasse

Yes this is important. test written in Sunit should run on it and new features can be incompatible. On Oct 25, 2010, at 4:07 PM, Lukas Renggli wrote: > I am all in for improving SUnit, but there must be some compatibility > mode that makes it easy not only to run, but also to write tests on > the official SUnit. This is crucial for projects like Seaside, > Magritte, Pier, PetitParser, ... that are supposed to work on various > other Smalltalk platforms. > > Lukas > > On 25 October 2010 15:51, Niko Schwarz <niko.schwarz(a)googlemail.com> wrote: >> Yea, well, it depends on whether we want to be compatible with camp >> smalltalk's SUnit, as maintained by Niall Ross: >> http://sunit.sourceforge.net/devel.htm. Pharo already is using >> extensions, such as the possibility to mark tests as expected failures >> at all (that is impossible in standard SUnit). >> >> My humble opinion is that we must control our testing environment, and >> we already have an excellent cleanup of SUnit, namely akuhn/SUnit, >> http://www.squeaksource.com/akuhn.html. And we have progress in the >> form of Phexample, which builds ontop of SUnit. >> http://smalltalkthoughts.blogspot.com/2009/11/phexample-because-examples-ex… >> . I'd be more than happy if Pharo took a new SUnit as its standard >> testing framework, and I'd even be thrilled if enough people found >> Phexample useful enough, so that it could become standard over time. >> >> Niko >> >> 2010/10/25 Luc Fabresse <luc.fabresse(a)gmail.com>: >>> Hi all, >>> I am working on pushing environments in SystemNavigation. >>> SystemNavigationTest previously used ClassFactoryForTestCase from SUnit for >>> generating classes. >>> Now I need an environment-aware ClassFactoryForTestCase. >>> Should I directly modify ClassFactoryForTestCase since a class generator >>> should now be environment aware? >>> Should I subclass ClassFactoryForTestCase and put it in SUnit? >>> Should I never changed SUnit and put it elsewhere? ;-) >>> #Luc >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> http://scg.unibe.ch/staff/Schwarz >> twitter.com/nes1983 >> Tel: +41 076 235 8683 >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 26, 2010