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

Re: [Pharo-project] A remote workspace

by Lukas Renggli

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

May 13, 2010

Re: [Pharo-project] A remote workspace

by Igor Stasenko

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. > 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.

May 13, 2010

[Pharo-project] [update 1.1] #11359

by Marcus Denker

11359 ----- Issue 2428: #reverse should not be deprecated for the sake of ANSI compatibility Issue 2425: fix two Undeclards in TextEditor Issue 2427: restart all running methods -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

May 13, 2010

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

by Lukas Renggli

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

May 13, 2010

Re: [Pharo-project] A remote workspace

by Mariano Martinez Peck

please please please take a look to the conversation we have with had with Eliot Miranda some time ago. His ideas were REALLY cool and interesting. yes, of course, that's much more than what we are saying here, but it is very interesting: http://forum.world.st/Fwd-squeak-dev-Smalltalk-vs-Eclipse-tp1295122p1295122… Cheers Mariano On Thu, May 13, 2010 at 1:46 PM, 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. > > 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 >

May 13, 2010

Re: [Pharo-project] Which fonts for Pharo 1.1 ?

by Henrik Sperre Johansen

On 12.05.2010 15:51, Richard Durr wrote: > I'd strongly argue to have true type fonts: > * when you try to make something look good, you don't impair the > ability to use fonts Right. But when you also try to make something which: - Works the same when you move an image between multiple platforms - Should be small in size (the DejaVu fonts shipped with 1.0 to satisfy #1 takes ~4MB zipped, 9 unzipped ) - Runs reasonably on slower machines Providing TrueType fonts by default might not still be the best default (although the support for using them is not removed) So as always, it's a trade-off. Cheers, Henry

May 13, 2010

Re: [Pharo-project] New packages to include in PharoDev 1.1

by Mariano Martinez Peck

Great to know that works in Pharo 1.1...I was going to test it. Thanks mariano On Thu, May 13, 2010 at 1:34 AM, Alexandre Bergel <alexandre(a)bergel.eu>wrote: > Thanks Torsten! > > Cheers, > Alexandre > > > On 12 May 2010, at 19:16, Torsten Bergmann wrote: > > > Alexandre wrote: > >>> - ScriptManager > >> > >> I am not sure what this is about. The squeaksource page is not really > well >furnished > > > > I updated the squeaksource wiki page: > > > > "This tool provides a GUI for managing scripts (or workspaces). It lets > you > > group them into folders, tear off as or bring in from workspaces, save > and > > load from file, and a whole bunch of other cool stuff. The script Manager > > is accessible via the system menu. The menu items should be self- > > explanatory. It was originally written by Joseph Pelrine as an add on for > > ENVY" > > > > > > If you want to try it out in 1.1.: > > > > -------------------------------------------------------- > > Gofer new > > squeaksource: 'MetacelloRepository'; > > package: 'ConfigurationOfScriptManager'; > > load. > > > > (Smalltalk at: #ConfigurationOfScriptManager) load > > -------------------------------------------------------- > > > > Then open it using Tools -> ScriptManager. > > > > Bye > > Torsten > > > > > > > > > > -- > > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > > > _______________________________________________ > > 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 > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > _______________________________________________ > 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 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