- 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 Mariano Martinez Peck

On Thu, May 13, 2010 at 1:17 PM, David T. Lewis <lewis(a)mail.msen.com> wrote: > On Thu, May 13, 2010 at 10:56:17AM +0300, Igor Stasenko wrote: > > On 13 May 2010 10:33, St??phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > oops > > > Igor do you have more information? > > > how do we do that? > > > > > just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. > > > > As far as i can tell, everything else should work fine after that. > > This is not my contribution , so i don't know all nuances, sorry. > > > > I just made things which allow source pointers > 32Mb to be stored in > > method trailers, while others put this in use in various places :) > > That is probably all that is needed, yes. But be sure to test it. > When I did this for trunk, I tested by loading some big Monticello > package endlessly in a loop until I got the changes file up to > a couple hundred megabytes. You should be able to do this, save > and restart the image, browse all old methods is the sources file > and so forth. Then modify some method and make sure your change > appears at the end of the huge changes file, and that you can > revert your most recent change. And of course you should get no > warning dialog about the changes file size. > > Somebody with a fast computer should volunteer to test this. I > recall that it took a long time on my slow laptop computer with > slow disk drive ;) > > Thanks Dave. In my case, I accidently did something similar: I installed Seaside 3.0 a couple of times: 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 >

May 13, 2010

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

by Lukas Renggli

> 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

May 13, 2010

Re: [Pharo-project] A remote workspace

by StÃ©phane Ducasse

yes http://gemstonesoup.wordpress.com/2009/10/19/metacello-tutorial-updated/ >>>> > > I tried REPLServer, and it works really well! > > It has a dependency on TcpService, so I had to install KomServices and > DynamicBindings. Is there a tutorial somewhere about writing Metacello > configurations?

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 david for the advice. I will check that but right now I have several other pending item on non pharo stuff. Stef On May 13, 2010, at 1:17 PM, David T. Lewis wrote: > On Thu, May 13, 2010 at 10:56:17AM +0300, Igor Stasenko wrote: >> On 13 May 2010 10:33, St??phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> oops >>> Igor do you have more information? >>> how do we do that? >>> >> just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. >> >> As far as i can tell, everything else should work fine after that. >> This is not my contribution , so i don't know all nuances, sorry. >> >> I just made things which allow source pointers > 32Mb to be stored in >> method trailers, while others put this in use in various places :) > > That is probably all that is needed, yes. But be sure to test it. > When I did this for trunk, I tested by loading some big Monticello > package endlessly in a loop until I got the changes file up to > a couple hundred megabytes. You should be able to do this, save > and restart the image, browse all old methods is the sources file > and so forth. Then modify some method and make sure your change > appears at the end of the huge changes file, and that you can > revert your most recent change. And of course you should get no > warning dialog about the changes file size. > > Somebody with a fast computer should volunteer to test this. I > recall that it took a long time on my slow laptop computer with > slow disk drive ;) > > Dave > > > _______________________________________________ > 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 Geoffroy Couprie

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. Best regards, Geoffroy

May 13, 2010

Re: [Pharo-project] A remote workspace

by Geoffroy Couprie

Hello, On Thu, May 13, 2010 at 1:22 AM, 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, ... > Mostly because VNC will not work on buggy connections like the one I had at my school. It sends too much data for slow connections. And you can't send one command (like updating a Monticello package) to a lot of VMs. This idea of a remote workspace is not remote development (although that would be really cool), but remote administration. I have to admit that this is mostly a good excuse for me to poke around the system and learn a lot of things :) Best regards, Geoffroy

May 13, 2010

Re: [Pharo-project] A remote workspace

by Geoffroy Couprie

Hello, On Thu, May 13, 2010 at 9:27 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 13, 2010, at 12:46 AM, Geoffroy Couprie wrote: > >> Hello, >> >> On Thu, May 13, 2010 at 12:38 AM, Michael van der Gulik >> <mikevdg(a)gmail.com> wrote: >>> There's a package called REPLServer for Squeak which does the above. >>> It has command line editing and history. >> >> Aww, you just killed my first real Smalltalk program :( > > Have a look there is certainly space to improve. > If it works in pharo it would be great to produce a ConfigurationOfREPL for pharo1.0 and pharo1.1 I tried REPLServer, and it works really well! It has a dependency on TcpService, so I had to install KomServices and DynamicBindings. Is there a tutorial somewhere about writing Metacello configurations? Best regards, Geoffroy

May 13, 2010

Re: [Pharo-project] A remote workspace

by Geoffroy Couprie

Hello, 2010/5/13 Andrei Stebakov <lispercat(a)gmail.com>: > You are a godsend! I was just asking about this feature on the list... > 1) Should be reasonably fast > 2) Should use secure connection (ideally ssh). > > I'd rather teach Pharo communicate via standard input/output first so you > can use it as a command line tool, then expand this ability to talk via any > variant of TCP/IP. > I am very new to Pharo so I don't know the extent it's married to its GUI > environment, not sure how easy it is to implement... > I saw your messages and I thought, "hey, maybe what I'm working on would interest him" :)

May 13, 2010

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

by David T. Lewis

On Thu, May 13, 2010 at 10:56:17AM +0300, Igor Stasenko wrote: > On 13 May 2010 10:33, St??phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > oops > > Igor do you have more information? > > how do we do that? > > > just replace CompiledMethod>>checkOKToAdd:at:, or take it from trunk. > > As far as i can tell, everything else should work fine after that. > This is not my contribution , so i don't know all nuances, sorry. > > I just made things which allow source pointers > 32Mb to be stored in > method trailers, while others put this in use in various places :) That is probably all that is needed, yes. But be sure to test it. When I did this for trunk, I tested by loading some big Monticello package endlessly in a loop until I got the changes file up to a couple hundred megabytes. You should be able to do this, save and restart the image, browse all old methods is the sources file and so forth. Then modify some method and make sure your change appears at the end of the huge changes file, and that you can revert your most recent change. And of course you should get no warning dialog about the changes file size. Somebody with a fast computer should volunteer to test this. I recall that it took a long time on my slow laptop computer with slow disk drive ;) Dave

May 13, 2010

Re: [Pharo-project] apparently recentMessages does not get the latest changes after

by Igor Stasenko

It never worked for me, each time i used this feature. Not in Squeak not in Pharo :) On 13 May 2010 13:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > yes! > Sorry > > On May 13, 2010, at 11:56 AM, Igor Stasenko wrote: > >> did you meant 'recent submissions'? >> >> On 13 May 2010 12:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >>> strange.... >>> Any idea? >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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