August 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] #remoteHostAddress
by Ramiro Diaz Trepat Aug. 2, 2009

Aug. 2, 2009

I am trying to port Magma to Pharo, and I have run across the following issue. Ini Pharo, the method: Socket>>connectTo: hostAddress port: port waitForConnectionFor: timeout (mir 6/17/2007 20:10) "Initiate a connection to the given port at the given host address. Waits until the connection is established or time outs." self connectNonBlockingTo: hostAddress port: port. self waitForConnectionFor: timeout ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' , self *remoteHostAddress* hostNumber , ':' , port asString] #*remoteHostAddress* has no implementors in Pharo. The implementation of this method in Squeak uses *NetNameResolver* Socket>>connectTo: hostAddress port: port waitForConnectionFor: timeout (mu 8/14/2003 15:15) "Initiate a connection to the given port at the given host address. Waits until the connection is established or time outs." self connectNonBlockingTo: hostAddress port: port. self waitForConnectionFor: timeout ifTimedOut: [ConnectionTimedOut signal: 'Cannot connect to ' , (*NetNameResolver* stringFromAddress: hostAddress) , ':' , port asString] Who is maintaining Socket now in Pharo? Has anyone got some advice on how to solve this? Cheers r.

4 8

[Pharo-project] Custom user Interrupt handling
by Dale Henrichs Aug. 1, 2009

Aug. 1, 2009

For the GLASS GemTools client, I would like to intercept Alt-. and instead of opening a debugger, I would like to send an interrupt to the GemStone process. In Squeak and earlier variants of Pharo, it was possible to replace the interruptSemaphore with one of our own while we were waiting and it worked well enough. With the new structure of InputSensor and friends it doesn't appear to be possible to hack into the event handling system for user interrupts. The class UserInterruptHandler is tantalizingly close, however, there is no obvious way to insinuate myself as an interested party....It's pretty much hard-wired to open a debugger on the interrupted process.... There are probably several ways to allow for the user interrupt to be intercepted: - use a dynamic variable - use a process local Both techniques have the advantage of being process specific... On the other hand if it is easier/preferable to use Ctl-ALT-. then that would work for me. Thanks in advance, Dale

3 2

[Pharo-project] [update] #10403
by Marcus Denker Aug. 1, 2009

Aug. 1, 2009

10403 ----- Issue 1023: Menu System>Keyboard shortcuts calls deprecated method Issue 1022: Mac Menus: merge File and System menu into the App menu Issue 1025: Menu System->Preferences->set author initials calls deprecated method -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

1 0

Re: [Pharo-project] Custom user Interrupt handling
by Dale Henrichs Aug. 1, 2009

Aug. 1, 2009

1 0

Re: [Pharo-project] Custom user Interrupt handling
by Dale Henrichs Aug. 1, 2009

Aug. 1, 2009

It looks as though using signalException:, and a UserInterrupt notification whose defaultAction is to open the debugger will do the trick ... An exception handler on the stack for UserInterrupt can intercept the interrupt and do something different than opening a debugger. I've attached two fileIns with an example implementation...a quick review by a knowledgeable soul would be appreciated (not much code involved at all). If there aren't any other alternatives and this approach is deemed to be acceptable, I can go through the standard process and submit a bug/bugfix (bullet-proofing the code a bit as well). Dale ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: | For the GLASS GemTools client, I would like to intercept Alt-. and | instead of opening a debugger, I would like to send an interrupt to | the GemStone process. | | In Squeak and earlier variants of Pharo, it was possible to replace | the interruptSemaphore with one of our own while we were waiting and | it worked well enough. | | With the new structure of InputSensor and friends it doesn't appear to | be possible to hack into the event handling system for user | interrupts. | | The class UserInterruptHandler is tantalizingly close, however, there | is no obvious way to insinuate myself as an interested party....It's | pretty much hard-wired to open a debugger on the interrupted | process.... | | There are probably several ways to allow for the user interrupt to be | intercepted: | | - use a dynamic variable | - use a process local | | Both techniques have the advantage of being process specific... | | On the other hand if it is easier/preferable to use Ctl-ALT-. then | that would work for me. | | Thanks in advance, | | Dale | | _______________________________________________ | Pharo-project mailing list | Pharo-project(a)lists.gforge.inria.fr | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

1 0