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

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by StÃ©phane Ducasse

>>> >> just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. this is exactly the same in pharo and squeak trunk >>>> CompiledMethod>>checkOKToAdd: size at: filePosition >>>> "Issue several warnings if the end of the changes file is approaching >>>> a fixed size limit, and finally halt with an error if the limit is reached." >>>> >>>> ^ SourceFiles checkOKToAdd: size at: filePosition >>>> >>>> looks like Pharo didn't integrated this method. >>>> >>>> also, make sure you using a proper source file array.. >>>> >>>> SourceFiles class == ExpandedSourceFileArray SourceFiles class -> ExpandedSourceFileArray I integrated the squeak squeak and they are all green. so I'm puzzled >>> >>> >>> >>> >>>> >>>> On 13 May 2010 03:10, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>>> 2010/5/13 Mariano Martinez Peck <marianopeck(a)gmail.com>: >>>>>> Hi. I have the following error: >>>>>> >>>>>> 'You have reached the size limit of the changes file. >>>>>> You must take action now to reduce it. >>>>>> Close this error. Do not attempt to proceed.' >>>>>> >>>>>> I know this is a known error, but I thought that with Igor's new method >>>>>> trailer this was fixed. >>>>>> >>>>> >>>>> Seems like a leftovers of old stuff, with precautions once you >>>>> reaching the size limit. >>>>> >>>>> Close this error. And attempt to proceed. >>>>> >>>>> :) >>>>> >>>>>> Tested in 11355 >>>>>> >>>>>> Thanks >>>>>> >>>>>> Mariano >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-project mailing list >>>>>> Pharo-project(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko AKA sig. >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 13, 2010

Re: [Pharo-project] RB and OB in Pharo 1.1 [WAS] Re: [Seaside] Loading Seaside 3.0 in Pharo 1.1

by Lukas Renggli

> Now, playing a little with RB I found a deprecated method send: > > hasSpecialSelector: aSymbolÂ ifTrueSetByte: > > You are using it in: > > RBClass >> existingMethodsThatReferTo: > > here: > > Â Â Â special := self realClass environment > Â Â Â Â Â Â hasSpecialSelector: aSymbol > Â Â Â Â Â Â ifTrueSetByte: [ :value | byte := value ]. > > the thing is that self realClass environment answer SystemDirectory but we > should use Smalltalk / SmalltalkImage You must be using a very old version of Refactoring-Core, this was fixed quite some time ago. > In addition, is there a way to automatically check all the sends of > deprecated methods? because there may be a lot...I just tried a Class Rename > refactor and I found this one, but I am sure there are more.. SmallLint finds some of them, but the rule should probably be improved. Also running the tests can show you problems (given that the code is all covered). As I said, we fixed all the deprecated calls in Seaside 3.0, OB, RB, eCompletion, Shout and PetitParser you just need to take the very latest Pharo 1.1 and the very latest code of each package. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 13, 2010

Re: [Pharo-project] #reversed and ANSI compatibility

by Lukas Renggli

> Maybe it was easier to define > > reverse > Â Â Â Â ^self reversed > > in a package of seaside with a categoryÂ *Seaside-Pharo ?Â that's maybe what > Dale did ? No, he changed the code to call #reversed. This however broke Seaside for all other platforms that properly implement the ANSI standard. Having a Seaside specific implementation would be feasible, but then we have to call it #greaseReverse or something, otherwise it will dirty the system package when loading. Even if the name is unfortunate, it doesn't make sense to break ANSI compatibility. This is the only thing we can trust on today for writing platform independent code. Lukas -- Lukas Renggli www.lukas-renggli.ch

May 13, 2010

[Pharo-project] RB and OB in Pharo 1.1 [WAS] Re: [Seaside] Loading Seaside 3.0 in Pharo 1.1

by Mariano Martinez Peck

Stef, Marcus and I also managed to get OB and RB work without > deprecated warnings in the latest Pharo 1.1. > > Yes, I know. With the help of Alexandre and you, I am trying to release the first PharoDev 1.1....we are near ;) Now, playing a little with RB I found a deprecated method send: hasSpecialSelector: aSymbol ifTrueSetByte: You are using it in: RBClass >> existingMethodsThatReferTo: here: special := self realClass environment hasSpecialSelector: aSymbol ifTrueSetByte: [ :value | byte := value ]. the thing is that self realClass environment answer SystemDirectory but we should use Smalltalk / SmalltalkImage THe fix is just: special := Smalltalk hasSpecialSelector: aSymbol ifTrueSetByte: [ :value | byte := value ]. ??? In addition, is there a way to automatically check all the sends of deprecated methods? because there may be a lot...I just tried a Class Rename refactor and I found this one, but I am sure there are more.. Cheers Mariano Lukas > > On 12 May 2010 23:09, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > Hi folks. We are near to go (alpha?) to a first release of Pharo 1.1. I > have > > started to try to load Seaside 3.0 on it and the first problem I had > (there > > will be more for sure) is the famous problem with TheWorldMenu ;) > > > > WASqueakServerAdaptorBrowser class >> initialize of the package > > Seaside-Pharo-Tools-OmniBrowser > > > > It should use the new scheme with pragmas. It would be great if this can > be > > fixed. Sorry I cannot help. > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > seaside mailing list > > seaside(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside >

May 13, 2010

Re: [Pharo-project] A remote workspace

by Igor Stasenko

On 13 May 2010 19:06, Lukas Renggli <renggli(a)gmail.com> wrote: > On 13 May 2010 17:51, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: >>> Hello, >>> >>> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 13 May 2010 02:22, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> Why dont you use the VNC facility of Pharo which is >>>>> typically used to administrate Seaside images: >>>>> >>>>> Â http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>> >>>>> Just install the RFB package, configure and use a normal >>>>> VNC client to remotely use and drive the image. >>>>> >>>>> So you have workspaces, debuggers, you name it, ... >>>>> >>>> Remote debugging is a must. Headless, no UI. >>>> Remote debugger can create own UI at debugger side, while debugged >>>> image could be quite small, >>>> contain no UI, Morphic & rest of stuff. >>>> >>>> Think of debugging a kernel images, where you can't afford having a >>>> lot of stuff loaded, not saying about RFB. >>>> >>> >>> I like the idea of a headless image :) >>> >>> I don't know how hard it would be to add a remote debugger. Could it >>> be done by catching the exceptions on the remote side and sending >>> commands like walking the stack from the local side? >>> >>> For remote administration, it would be fairly easy to have a local UI >>> sending commands periodically to remote VMs to ask for status, execute >>> some code, etc. >>> >> >> It should be a relatively easy. >> A debuggee should need is to encapsulate the objects by some ids, >> and then transfer these objects printstrings over a connection, so >> debugger could show them. >> The debugger consists of a number of panes - 2 inspectors and code. >> So, if you implement a remote inspector, you'll have about 40% of job done. > > You could also implement a new view for OB: meaning the model of OB > runs on the server while the view is on the client. AFAIK this is what > GemStone does for its tools in Pharo. I guess that approach could be > adapted to also work between two Pharo images. > Yes, the model/view separation helps greatly in reducing the complexity for implementing a remote views. > Lukas > > > >> >> >>> Best regards, >>> >>> Geoffroy >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

May 13, 2010

Re: [Pharo-project] A remote workspace

by Dale Henrichs

May 13, 2010

Re: [Pharo-project] #reversed and ANSI compatibility

by Mariano Martinez Peck

Maybe it was easier to define reverse ^self reversed in a package of seaside with a category *Seaside-Pharo ? that's maybe what Dale did ? cheers mariano On Thu, May 13, 2010 at 6:12 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > Marcus just did it. > > Now this is a pity since sorted returns a new collection and sort in Squeak > (does a in place sort) > > In squeak too > reverse > "This method will be the in place version sometime" > > self deprecated: 'Use #reversed'. > ^self reversed > > it was nice to have a coherent protocol. > > Stef > > On May 13, 2010, at 4:37 PM, Lukas Renggli wrote: > > > Please integrate this fix: > > > > http://code.google.com/p/pharo/issues/detail?id=2428 > > > > On 13 May 2010 14:12, Lukas Renggli <renggli(a)gmail.com> wrote: > >>> What ansi specifies for reversed? > >> > >> The problem is that #reverse is deprecated in Pharo 1.1. I didn't look > >> at the implementation of #reversed. If that can be fixed then Seaside > >> 3.0 passes all tests in Pharo 1.1 (after I committed a few changes). > >> > >> ANSI on reverse: > >> > >> 5.7.8.26 Message: reverse > >> > >> Synopsis > >> > >> Answer a collection with the elements of the receiver arranged in > >> reverse order. Definition: <sequenceReadableCollection> > >> Answer a collection conforming to the same protocols as the receiver, > >> but with its elements arranged in reverse order. > >> This operation is equivalent to: > >> 1. Create a new collection which conforms to the same protocols as the > receiver; > >> 2. Traverse the elements of the receiver in the order specified by the > >> #reverseDo: message, adding each element of the receiver to the new > >> collection; > >> 3. Answer the new collection. > >> > >> Return Values > >> <RECEIVER> > >> > >> Errors > >> none > >> > >> On 13 May 2010 09:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >>> yes > >>> the idea was to have > >>> sort > >>> sorted > >>> reverse > >>> reversed > >>> > >>> for inplace/copy based situation. > >>> What ansi specifies for reversed? > >>> > >>> Stef > >>> > >>> On May 13, 2010, at 6:47 AM, Lukas Renggli wrote: > >>> > >>>> The recent change of renaming #revese to #reversed introduces problems > >>>> in the Seaside code-base. > >>>> > >>>> While I agree that the renaming makes sense, #reverse is part of the > >>>> ANSI standard and supported by all other Smalltalk implementations. In > >>>> Seaside we are forced to use it. > >>>> > >>>> Could Pharo re-add a not-deprecated delegator of #reverse in > >>>> SequenceableCollection? I have the opinion that Pharo should follow > >>>> ANSI if this is easily possible, because this is the only mean of > >>>> having some minimal kind of compatibility. > >>>> > >>>> 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 > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 13, 2010

Re: [Pharo-project] A remote workspace

by StÃ©phane Ducasse

I would really like to have that functionality. Stef On May 13, 2010, at 6:06 PM, Lukas Renggli wrote: > On 13 May 2010 17:51, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 13 May 2010 14:46, Geoffroy Couprie <geo.couprie(a)gmail.com> wrote: >>> Hello, >>> >>> On Thu, May 13, 2010 at 2:51 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>>> On 13 May 2010 02:22, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>> Why dont you use the VNC facility of Pharo which is >>>>> typically used to administrate Seaside images: >>>>> >>>>> http://book.seaside.st/book/advanced/deployment/maintaining/vnc >>>>> >>>>> Just install the RFB package, configure and use a normal >>>>> VNC client to remotely use and drive the image. >>>>> >>>>> So you have workspaces, debuggers, you name it, ... >>>>> >>>> Remote debugging is a must. Headless, no UI. >>>> Remote debugger can create own UI at debugger side, while debugged >>>> image could be quite small, >>>> contain no UI, Morphic & rest of stuff. >>>> >>>> Think of debugging a kernel images, where you can't afford having a >>>> lot of stuff loaded, not saying about RFB. >>>> >>> >>> I like the idea of a headless image :) >>> >>> I don't know how hard it would be to add a remote debugger. Could it >>> be done by catching the exceptions on the remote side and sending >>> commands like walking the stack from the local side? >>> >>> For remote administration, it would be fairly easy to have a local UI >>> sending commands periodically to remote VMs to ask for status, execute >>> some code, etc. >>> >> >> It should be a relatively easy. >> A debuggee should need is to encapsulate the objects by some ids, >> and then transfer these objects printstrings over a connection, so >> debugger could show them. >> The debugger consists of a number of panes - 2 inspectors and code. >> So, if you implement a remote inspector, you'll have about 40% of job done. > > You could also implement a new view for OB: meaning the model of OB > runs on the server while the view is on the client. AFAIK this is what > GemStone does for its tools in Pharo. I guess that approach could be > adapted to also work between two Pharo images. > > Lukas > > > >> >> >>> Best regards, >>> >>> Geoffroy >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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

May 13, 2010

Re: [Pharo-project] #reversed and ANSI compatibility

by StÃ©phane Ducasse

Marcus just did it. Now this is a pity since sorted returns a new collection and sort in Squeak (does a in place sort) In squeak too reverse "This method will be the in place version sometime" self deprecated: 'Use #reversed'. ^self reversed it was nice to have a coherent protocol. Stef On May 13, 2010, at 4:37 PM, Lukas Renggli wrote: > Please integrate this fix: > > http://code.google.com/p/pharo/issues/detail?id=2428 > > On 13 May 2010 14:12, Lukas Renggli <renggli(a)gmail.com> wrote: >>> What ansi specifies for reversed? >> >> The problem is that #reverse is deprecated in Pharo 1.1. I didn't look >> at the implementation of #reversed. If that can be fixed then Seaside >> 3.0 passes all tests in Pharo 1.1 (after I committed a few changes). >> >> ANSI on reverse: >> >> 5.7.8.26 Message: reverse >> >> Synopsis >> >> Answer a collection with the elements of the receiver arranged in >> reverse order. Definition: <sequenceReadableCollection> >> Answer a collection conforming to the same protocols as the receiver, >> but with its elements arranged in reverse order. >> This operation is equivalent to: >> 1. Create a new collection which conforms to the same protocols as the receiver; >> 2. Traverse the elements of the receiver in the order specified by the >> #reverseDo: message, adding each element of the receiver to the new >> collection; >> 3. Answer the new collection. >> >> Return Values >> <RECEIVER> >> >> Errors >> none >> >> On 13 May 2010 09:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> yes >>> the idea was to have >>> sort >>> sorted >>> reverse >>> reversed >>> >>> for inplace/copy based situation. >>> What ansi specifies for reversed? >>> >>> Stef >>> >>> On May 13, 2010, at 6:47 AM, Lukas Renggli wrote: >>> >>>> The recent change of renaming #revese to #reversed introduces problems >>>> in the Seaside code-base. >>>> >>>> While I agree that the renaming makes sense, #reverse is part of the >>>> ANSI standard and supported by all other Smalltalk implementations. In >>>> Seaside we are forced to use it. >>>> >>>> Could Pharo re-add a not-deprecated delegator of #reverse in >>>> SequenceableCollection? I have the opinion that Pharo should follow >>>> ANSI if this is easily possible, because this is the only mean of >>>> having some minimal kind of compatibility. >>>> >>>> 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 >>> >>> >>> _______________________________________________ >>> 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

May 13, 2010

Re: [Pharo-project] Problem in Pharo 1.1 (Igor?) : You have reached the size limit of the changes file.

by StÃ©phane Ducasse

thanks for the idea > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside'; > load. > > And then evaluate: > > ConfigurationOfSeaside project latestVersion load: #( 'Seaside 3.0' 'Magritte2' 'Pier2' 'Pier2 AddOns' ). > > > There will be some errors and deprecated...just proceed them as this is only to increase the .changes > > Cheers > > Mariano > > Dave > > > _______________________________________________ > 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

May 13, 2010