- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Deprecating Protocol browser

by Lukas Renggli

It used to be part of OmniBrowser, but I removed it a long time ago because - it broke due to changes in Pharo, - it had not a single test case, and - nobody bothered to fix it (check the mailing-list). Lukas On 1 August 2011 23:14, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Ok...it seems that doesn't exist on Pharo, but only in PharoCore. Since I > don't use PharoCore, I haven't seen it before. > Maybe it is also in Pharo but I cannot find it. > > Thanks > > On Mon, Aug 1, 2011 at 11:07 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> >> :) >> >> in a browser menu somewhere... >> >> Stef >> >> >> > >> > >> > On Mon, Aug 1, 2011 at 5:44 PM, Randal L. Schwartz >> > <merlyn(a)stonehenge.com> wrote: >> > >>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: >> > >> > StÃ©phane> ProtocolBrowser, a subclass of MessageSet, should be >> > deprecated. >> > StÃ©phane> Now if the functionality is used (I never used it but I may be >> > StÃ©phane> a non typical programmer), we could use FlatListBrowser to >> > StÃ©phane> implement ProtocolBrowser. >> > >> > If you're talking about "browse protocol" from the code browser (or a >> > few other interfaces), >> > >> > where is that "browse protocol" ? Â I cannot even find it (of course, I >> > never use it) >> > >> > thanks >> > >> > I use it all the time on other people's code, >> > because it gives me a quick overview of the full range of what the class >> > provides. >> > >> > Maybe you don't work enough on other people's code? :) >> > >> > -- >> > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 >> > 0095 >> > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> >> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. >> > See http://methodsandmessages.posterous.com/ for Smalltalk discussion >> > >> > >> > >> > >> > -- >> > Mariano >> > http://marianopeck.wordpress.com >> > >> >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Lukas Renggli www.lukas-renggli.ch

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by Mariano Martinez Peck

Ok...it seems that doesn't exist on Pharo, but only in PharoCore. Since I don't use PharoCore, I haven't seen it before. Maybe it is also in Pharo but I cannot find it. Thanks On Mon, Aug 1, 2011 at 11:07 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > :) > > in a browser menu somewhere... > > Stef > > > > > > > > On Mon, Aug 1, 2011 at 5:44 PM, Randal L. Schwartz < > merlyn(a)stonehenge.com> wrote: > > >>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > > > > StÃ©phane> ProtocolBrowser, a subclass of MessageSet, should be > deprecated. > > StÃ©phane> Now if the functionality is used (I never used it but I may be > > StÃ©phane> a non typical programmer), we could use FlatListBrowser to > > StÃ©phane> implement ProtocolBrowser. > > > > If you're talking about "browse protocol" from the code browser (or a > > few other interfaces), > > > > where is that "browse protocol" ? I cannot even find it (of course, I > never use it) > > > > thanks > > > > I use it all the time on other people's code, > > because it gives me a quick overview of the full range of what the class > > provides. > > > > Maybe you don't work enough on other people's code? :) > > > > -- > > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 > 0095 > > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by StÃ©phane Ducasse

:) in a browser menu somewhere... Stef > > > On Mon, Aug 1, 2011 at 5:44 PM, Randal L. Schwartz <merlyn(a)stonehenge.com> wrote: > >>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > > StÃ©phane> ProtocolBrowser, a subclass of MessageSet, should be deprecated. > StÃ©phane> Now if the functionality is used (I never used it but I may be > StÃ©phane> a non typical programmer), we could use FlatListBrowser to > StÃ©phane> implement ProtocolBrowser. > > If you're talking about "browse protocol" from the code browser (or a > few other interfaces), > > where is that "browse protocol" ? I cannot even find it (of course, I never use it) > > thanks > > I use it all the time on other people's code, > because it gives me a quick overview of the full range of what the class > provides. > > Maybe you don't work enough on other people's code? :) > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by merlyn＠stonehenge.com

>>>>> "Mariano" == Mariano Martinez Peck <marianopeck(a)gmail.com> writes: >> If you're talking about "browse protocol" from the code browser (or a >> few other interfaces), Mariano> where is that "browse protocol" ? I cannot even find it (of course, I never Mariano> use it) Code Browser, class pane, select a class, alt-click, see "browse protocol (p)". -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.posterous.com/ for Smalltalk discussion

Aug. 1, 2011

[Pharo-project] [update 1.4] #14069

by StÃ©phane Ducasse

14069 ----- - fixed CommentReference missing backward compatibility methods. - fixed some methodSymbol references http://code.google.com/p/pharo/issues/detail?id=4550 - fixed eval and execution of code in FlatMessageListBrowser Issue 4580: RGMethodDefinition protocol can be nil - fix results of protocolAt: and timeStampAt: of SourceFileArray. - add test to cover SourceFileArray utils methods http://code.google.com/p/pharo/issues/detail?id=4580 Stef

Aug. 1, 2011

Re: [Pharo-project] Deprecating Protocol browser

by Mariano Martinez Peck

On Mon, Aug 1, 2011 at 5:44 PM, Randal L. Schwartz <merlyn(a)stonehenge.com>wrote: > >>>>> "StÃ©phane" == StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> writes: > > StÃ©phane> ProtocolBrowser, a subclass of MessageSet, should be deprecated. > StÃ©phane> Now if the functionality is used (I never used it but I may be > StÃ©phane> a non typical programmer), we could use FlatListBrowser to > StÃ©phane> implement ProtocolBrowser. > > If you're talking about "browse protocol" from the code browser (or a > few other interfaces), where is that "browse protocol" ? I cannot even find it (of course, I never use it) thanks I use it all the time on other people's code, > because it gives me a quick overview of the full range of what the class > provides. > > Maybe you don't work enough on other people's code? :) > > -- > Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 > 0095 > <merlyn(a)stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> > Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. > See http://methodsandmessages.posterous.com/ for Smalltalk discussion > > -- Mariano http://marianopeck.wordpress.com

Aug. 1, 2011

[Pharo-project] trait method tagging is not consistent

by StÃ©phane Ducasse

(SourceFiles sourcedDataAt: (Point>>#dist:) sourcePointer) 'Point methodsFor: ''point functions'' stamp: ''lr 7/4/2009 10:42''' SourceFiles sourcedDataAt: (ComposableMorph>>#newToolSpacer) sourcePointer 'Trait method' so protocol, stamp: .... got confused. http://code.google.com/p/pharo/issues/detail?id=4581 Stef

Aug. 1, 2011

Re: [Pharo-project] [Pharo-users] 1.4 update is broken do not use it

by StÃ©phane Ducasse

+1 And we will do our best to get the best out of us. And people should join if they want more. Stef >>>>> so now updating from https://gforge.inria.fr/frs/download.php/28827/Pharo-1.4-14065.zip >>>> >>>> Is this a core or a full image? If core (which one can use to update further) shouldnt this be reflected in the ZIP's name? >> >>> In 1.4, there is only one image. >>> This simplifies everything.... >> >> >> OK, but then two questions regarding the above image: >> >> - what is the intention? Provide only the core image in the future? >> Will ConfigurationOfPharo still be maintained to be able to >> build a dev image? >> > The intention is that maintaining two images is one too much. > > -> We need to test two images > -> We track bugs in two categories (see my old mails, very confusing "X bugs here, Z bugs open there") > -> We have two completely different ways of how fixes get into the system. > And the one fo the ConfigurationOfPharo is really complex to get even a trivial change in. > > In addtion, it complicates many things: > > -> the story gets complex. Two downloads. Which do I take? Just look at > pharo-project.org. Too complex. > -> The Full image can not be updated. That alone is a killer. > -> We maintain two browsers > -> ..... > > It's not sustainable. > > It should be noted that the ConfigurationOfPharo was broken for far too many days, > and fixing takes too much effort. > > The idea is *not* that this one image has the functionality of the old Core image. > The idea instead is to have *one* image that is the one that everyone uses and that > is the best development environment that we can do. > >> - why is the provided image a Cog only image (was not able to open it >> with the standard VM, so it looks like it was saved with Cog) >> Is this intended? > > I have only one VM on my machine. So this lead to the problem that I updated > the image for download with that VM.... and I forgot that there is problem. This > happend in 1.2 and in 1.3 and in 1.4, and I am tired of it. > > I am too dumb, I will never get it right. > > This is again is a question of complexity: Something that is so complex needs > to be simplified. > > We can not support all old VMs forever. New VMs can load the new image format. > > One of the ideas of 1.4 is that besides one Image, we will have "one" set > of VMs. The ones build by the Jenkins/Hudson. They run the new image format. > > The rule is: for version X of Pharo, use version X of the VM. > > This solves another problem: Moving to the Future. E.g. the new VMs support > better finalization, yet the image needs to be compatible forever to the old code. > The new VMs support Ephemerons. > Do we ever want to use them? An images where they are active will not run on > the old VMs. > > Being able to move forward on the VM side is very, very important. It makes > no sense to be backward *and* forward compatible forever. > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > >

Aug. 1, 2011

Re: [Pharo-project] How to deprecate a Class?

by StÃ©phane Ducasse

The most important aspects is that there is not reference to it. and that if we replace it by something else, it works. After we can write in the comments in big that the class is deprecated. Stef On Aug 1, 2011, at 8:18 PM, Bernardo Ezequiel Contreras wrote: > Hi all, > In the issue tracker, there are many issues to deprecate several classes. so, What do you do in order to deprecate a class? > Could you explain the procedure to deprecate a class? > > Thanks. >

Aug. 1, 2011

Re: [Pharo-project] condenseChanges problem

by StÃ©phane Ducasse

Thanks! Stef On Aug 1, 2011, at 7:03 PM, Pavel Krivanek wrote: > The problem was with double exclamation mark in method > MultiByteFileStreamTest >> #chunkString. Fix attached to the issue. It > only rewrites original source code with the same one. > > -- Pavel > > > On Mon, Aug 1, 2011 at 2:04 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> On Aug 1, 2011, at 2:02 PM, Pavel Krivanek wrote: >> >>> Hi, >>> >>> I created a special on the CI server and it seems that we are not able >>> to condense changes. See >>> https://ci.lille.inria.fr/pharo/job/Pharo%201.4%20condenseChanges/5/console >> >> Yes, this is already broken since sime time... >> >> http://code.google.com/p/pharo/issues/detail?id=3923 >> >> (I think even in 1.2). >> >> Everything not tested will break... >> >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >

Aug. 1, 2011