April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Paul DeBruicker

Paul DeBruicker wrote > > You could also consider using 'xrpa' which is like screen but for X > applications. See Bernat Romagosa description here: > > > Woops. That should have been Xpra not Xrpa. See: http://xpra.org/ -- View this message in context: http://forum.world.st/VNC-for-pharo-1-3-or-1-4-tp4590152p4591638.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2012

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Paul DeBruicker

You could also consider using 'xrpa' which is like screen but for X applications. See Bernat Romagosa description here: http://www.asmalltalkbytheseaside.com/#remotedevelopmentonpharowithoutvnc Hernan Wilkinson-3 wrote > > Thanks! works just fine! > > Hernan. > > On Thu, Apr 26, 2012 at 12:40 PM, Norbert Hartl <norbert@> wrote: > >> >> Am 26.04.2012 um 17:21 schrieb Hernan Wilkinson: >> >> > Hi >> > does anybody ported the implementation of VNC to pharo 1.3 or 1.4? >> > If so, could you share it? :-) >> > >> I use it daily on pharo 1.3. I load it via metacello. My baseline entry >> looks like this >> >> project: 'RFB' with: [ >> spec >> className: 'ConfigurationOfRFB'; >> file: 'ConfigurationOfRFB'; >> versionString: #'bleedingEdge'; >> repository: ' >> http://www.squeaksource.com/MetacelloRepository' ]; >> >> Norbert >> > > > > -- > *HernÃ¡n Wilkinson > Agile Software Development, Teaching & Coaching* > *Phone: +54 - 011 - 4311 - 8404** > Mobile: +54 - 911 - 4470 - 7207 > email: hernan.wilkinson@ > site: http://www.10Pines.com <http://www.10pines.com/>* > Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina > -- View this message in context: http://forum.world.st/VNC-for-pharo-1-3-or-1-4-tp4590152p4591622.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

April 27, 2012

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Hernan Wilkinson

Thanks! works just fine! Hernan. On Thu, Apr 26, 2012 at 12:40 PM, Norbert Hartl <norbert(a)hartl.name> wrote: > > Am 26.04.2012 um 17:21 schrieb Hernan Wilkinson: > > > Hi > > does anybody ported the implementation of VNC to pharo 1.3 or 1.4? > > If so, could you share it? :-) > > > I use it daily on pharo 1.3. I load it via metacello. My baseline entry > looks like this > > project: 'RFB' with: [ > spec > className: 'ConfigurationOfRFB'; > file: 'ConfigurationOfRFB'; > versionString: #'bleedingEdge'; > repository: ' > http://www.squeaksource.com/MetacelloRepository' ]; > > Norbert > -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - 4311 - 8404** Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

April 27, 2012

Re: [Pharo-project] OSProcess - is process done?

by DeNigris Sean

Begin forwarded message: > From: "David T. Lewis" <lewis(a)mail.msen.com> > Subject: Re: OSProcess - is process done? > Date: April 26, 2012 8:03:50 PM EDT > > Sean, > > Excellent, thanks for the feedback. As for #upToEnd, that's a tricky > question when you are reading from a pipe (or a socket). It is not > generally possible to ask the pipe whether more data is going to be > available on it. About the best you can do is ask it whether an end > of file condition was detected on the last read operation (there are > fancy ways to set up notification that a pipe was closed, but nothing > that I would want to try to implement in the OSPP plugin). > > Based on that, I ended up doing #upToEndOfFile to mean "read all > available data, and keep trying until end of file is detected, then > answer the result" and #upToEnd to mean "read all currently available > data". In the case of a blocking stream (i.e. the end of the pipe > from which you are reading data), you want the underlying reads to > block (because that is the whole point of a blocking read), and > you want the reads to give you available data if the stream is set > to non-blocking. But there is no practical way to ask a blocking > pipe to give you all available data, because you cannot ask it how > much data it has available in advance of doing the read. > > The combination of a pipe set to non-blocking mode, along with an > #upToEnd that reads whatever data is currently available, gives you > the behavior that you probably expect. But that implies that you > will poll for data (loop and keep reading until you get all the data) > or arrange for event notification to let you know when data is > available (this the AioPlugin, which notifies the image whenever > data becomes available for reading on a pipe). > > There is a mechanism in OSProcess/CommandShell for converting a blocking > pipe into an event-driven buffered reader that handles these issues. > It is not well documented, but try this to see how it works: > > p := PipeableOSProcess command: 'ls -l /usr/bin'. > p pipeFromOutput setBufferedReader. > p upToEndOfFile > > This approach is used in CommandShell to provide the expected behavior > when the image is reading from a pipe connected to some external > process. And when pipes are connected end-to-end in a unix style > pipeline, they can be left in the normal blocking mode so that external > programs will block on reads from their stdin, which is the expected > behavior for normal programs in a unix command pipeline. > > Dave >

April 27, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Camillo Bruni

On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: > Can they really download stuff? How much? Until the configurations are truly self-describing and "know" what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. > > Bill > > [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Thursday, April 26, 2012 6:17 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > Ok for me. > Package Maps Loader > > Stef > >> What about naming it "Package Loader" or "Package center" or something like that? >> And putting it in the main menu instead of inside of Tools? >> >> I want people who open pharo for the first time to say "Hey, here I can download stuff!!!" >> >> Guille

April 26, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

Can they really download stuff? How much? Until the configurations are truly self-describing and "know" what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. Bill [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Thursday, April 26, 2012 6:17 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? Ok for me. Package Maps Loader Stef > What about naming it "Package Loader" or "Package center" or something like that? > And putting it in the main menu instead of inside of Tools? > > I want people who open pharo for the first time to say "Hey, here I can download stuff!!!" > > Guille

April 26, 2012

Re: [Pharo-project] Who is maintaining the Grease configuration

by Dale Henrichs

Stef, This should do the trick: | pharoVersion tokens attributes attribute | pharoVersion := '2.4.4.5'. "not sure of version api for pharo" attributes := { #squeakCommon. #pharo }. tokens := pharoVersion subStrings: $.. attribute := ''. 1 to: tokens size do: [:index | | token | (token := tokens at: index) isEmpty ifTrue: [ ^attributes ]. attribute := attribute, token. attributes add: ('pharo', attribute, '.x') asSymbol. attribute := attribute, '.']. ^attributes Dale ----- Original Message ----- | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Thursday, April 26, 2012 2:53:45 PM | Subject: Re: [Pharo-project] Who is maintaining the Grease configuration | | | On Apr 25, 2012, at 11:01 PM, Dale Henrichs wrote: | | > ... let me finish my thought ... | > | > I can share that algorithm with you, if you want:) | | sure send code :) | | > | > Dale | > | > ----- Original Message ----- | > | From: "Dale Henrichs" <dhenrich(a)vmware.com> | > | To: Pharo-project(a)lists.gforge.inria.fr | > | Sent: Wednesday, April 25, 2012 2:01:05 PM | > | Subject: Re: [Pharo-project] Who is maintaining the Grease | > | configuration | > | | > | For Gemstone, I generate (and cache) the attributes based on | > | programmatic access to the image version number... | > | | > | Dale | > | | > | ----- Original Message ----- | > | | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | | To: Pharo-project(a)lists.gforge.inria.fr | > | | Sent: Wednesday, April 25, 2012 12:58:25 PM | > | | Subject: Re: [Pharo-project] Who is maintaining the Grease | > | | configuration | > | | | > | | Ok I will do it. | > | | We should add this to our process. | > | | | > | | Stef | > | | | > | | | > | | > The first thing that I ran into is that the attributes for | > | | > Pharo2.0 | > | | > need to be updated ... right now: | > | | > | > | | > ConfigurationOfGrease project attributes | > | | > | > | | > returns: | > | | > | > | | > an OrderedCollection(#common #squeakCommon #pharo | > | | > #'pharo1.x' | > | | > #'pharo1.4.x') | > | | > | > | | > Looks like SmalltalkImage>>metacelloPlatformAttributes needs | > | | > to | > | | > be | > | | > updated to return: | > | | > | > | | > #(#squeakCommon #pharo #'pharo2.x' #'pharo2.0.x') | > | | > | > | | > Dale | > | | > | > | | > ----- Original Message ----- | > | | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | | > | To: Pharo-project(a)lists.gforge.inria.fr | > | | > | Sent: Wednesday, April 25, 2012 10:26:18 AM | > | | > | Subject: Re: [Pharo-project] Who is maintaining the Grease | > | | > | configuration | > | | > | | > | | > | Thanks | > | | > | I will start to add the pharo2.0.x to some configurations | > | | > | too. | > | | > | | > | | > | Stef | > | | > | | > | | > | > I'm the editor for the Grease configuration, so I'll take | > | | > | > this | > | | > | > on | > | | > | > ... | > | | > | > | > | | > | > Dale | > | | > | > | > | | > | > ----- Original Message ----- | > | | > | > | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> | > | | > | > | To: "Pharo-project(a)lists.gforge.inria.fr Development" | > | | > | > | <Pharo-project(a)lists.gforge.inria.fr> | > | | > | > | Sent: Wednesday, April 25, 2012 7:37:14 AM | > | | > | > | Subject: [Pharo-project] Who is maintaining the Grease | > | | > | > | configuration | > | | > | > | | > | | > | > | Because we should create a symbolic version for 20 | > | | > | > | | > | | > | > | This package depends on the following classes: | > | | > | > | BlockContext | > | | > | > | You must resolve these dependencies before you will be | > | | > | > | able | > | | > | > | to | > | | > | > | load | > | | > | > | these definitions: | > | | > | > | fixCallbackTemps | > | | > | > | tempVarRefs | > | | > | > | valueWithPossibleArguments: | > | | > | > | | > | | > | > | | > | | > | > | | > | | > | > | > | | > | | > | | > | | > | | > | | > | | > | > | | | > | | | > | | | > | | > | | |

April 26, 2012

Re: [Pharo-project] PetitSmalltalk: now with a self-contained grammar for number literals

by Frank Shearar

On 26 April 2012 23:05, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Why holding 35 parsers in memory is a problem? > > I imagine that the trees should be much much larger. It's not really a problem. I just think it's less elegant than keeping the parsers around only during a parse. frank > Stef >

April 26, 2012

Re: [Pharo-project] Polymorph (and a few other) changes/fixes

by StÃ©phane Ducasse

two answers - we should pay attention that sometimes gary hacked polymorph because he knew that he could not touch the core - so there are some parts that should get in the right places. - this is not about visibility more about dependencies stef On Apr 27, 2012, at 12:05 AM, Sean P. DeNigris wrote: > > Gary Chambers-4 wrote >> >> Well, Stef was wanting to get away from all that ;-) Hence Object cleanup >> etc. >> > > I totally understand the cleanup of regular methods, but are extension > methods included? In fact, why not hide extension categories by default in > Nautilus and then you have both polymorphic simplicity and a manageable > number of methods to deal with from the tools... > > -- > View this message in context: http://forum.world.st/Polymorph-and-a-few-other-changes-fixes-tp4583837p459… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2012

Re: [Pharo-project] Downloading a file

by StÃ©phane Ducasse

thanks! I prefer bugs that last and do not show up like mushrooms :) On Apr 27, 2012, at 12:14 AM, Sean P. DeNigris wrote: > > StÃ©phane Ducasse wrote >> >> this is strange that it works in 1.4 and not in 2.0 because so far we >> nearly changed anything :) >> > > It's a vm bug (see > http://forum.world.st/Confused-about-isDirectory-td4589441.html) so 1.3, > 1.4 and 2.0 should be equally effected... > > From issue 5693: > 1.4 > '/private/tmp' asReference isDirectory. false > 2.0 > '/private/tmp' asFileReference isDirectory. false > > are both wrong results... > > -- > View this message in context: http://forum.world.st/Downloading-a-file-tp4586900p4591149.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

April 26, 2012