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

Re: [Pharo-project] Custom user Interrupt handling

by Dale Henrichs

Michael, What's the approved method for unregistering the current user interrupt handler? InputEventFetcher default eventHandlers copy do: [:hndlr | (hndlr isKindOf: UserInterruptHandler) ifTrue: [ hndlr unregister]]. Looks like it would work, but seems a bit fragile. Dale ----- "Michael Rueger" <m.rueger(a)acm.org> wrote: | Dale Henrichs wrote: | | > 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.... | | Just write your own class (e.g. subclass UserInterruptHandler) and | replace the handler (unregister the current one and register your | own). | | That's why I designed it the way it is :-) | | michael

Aug. 1, 2009

Re: [Pharo-project] #remoteHostAddress

by Schwab,Wilhelm K

For 'localhost', sure, 127.0.0.1 is probably the correct response. However, one can also run into situations of needing to find "the" current IP number/name. There are also servers with multiple addresses, and numbers with multiple names. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Saturday, August 01, 2009 9:00 AM To: Pharo-project(a)lists.gforge.inria.fr; johnmci(a)smalltalkconsulting.com Subject: Re: [Pharo-project] #remoteHostAddress Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> wrote: Well that does ^NetNameResolver addressForName: self localHostName where self localHostName on my machine returns 'Otter-2.local' where it really does addressesForName: and then if there is more than one then addresses first socketAddress So for my mac it's fe80::21c:42ff:fe00:9%en5(Otter-2), 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: 42ff:fe00:8%en5), 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: 63ff:fe02:d2db%en5), 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), 0(0)-inet4-stream-tcp where it has 4 ipv 6 address and 3 ipv 4 addresses. and doing NetNameResolver localHostAddress then gives: fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) The problem then is figuring out what you want, versus grabbing the first element in the list of IP address serviced by the machine. Perhaps in this case you thought you should get 192.168.1.139? Now if I ask for ^NetNameResolver addressForName: 'localhost' then I get back ::1(localhost),0(0) On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > Sorry, this mail came out too quick. How to report the error is a > secondary matter. > I believe the issue is about localhost name resolution. I think > this was discussed around the Windows VM platform, but I am on a Mac. > > > NetNameResolver addressForName: 'localhost' > > does not return 127.0.0.1 > > And, > > NetNameResolver localHostAddress > > returns the address on the network leg (192.168.....) instead of > 127.0.0.1 > > Is the convention that localhost is always 127.0.0.1 ? > > > Cheers > > > r. > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat <ramiro(a)diaztrepat.name<mailto:ramiro@diaztrepat.name> > > wrote: > 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. > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- = = = ======================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com<mailto:johnmci@smalltalkconsulting.com>> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ======================================================================== _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2009

Re: [Pharo-project] Custom user Interrupt handling

by Dale Henrichs

Aug. 1, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Marcus Denker

On 01.08.2009, at 07:06, Serge Stinckwich wrote: > On Sat, Aug 1, 2009 at 2:41 AM, StÃ©phane > Ducasse<stephane.ducasse(a)inria.fr> wrote: >> So what is the process now? >> Do we focus on 1.0? >> Can we integrate other issues? >> Do we have a separate stream for 1.1 alpha? > > Maybe the 1.1 alpha should be available after the release of Pharo 1.0 > so the efforts of the team is not disseminate on two versions. Yes, I think this is the way to go... we should force everyone to use the beta version for a while. Marcus -- Marcus Denker - http://marcusdenker.de PLEIAD Lab - Computer Science Department (DCC) - University of Chile

Aug. 1, 2009

[Pharo-project] [ANN] Squeak OpenVG bingings

by Igor Stasenko

Hello guys, this is a small project to enable a fast & standard 2D vector graphics API for squeak - OpenVG. The squeak sources is hosted at: http://www.squeaksource.com/OpenVG currently there are 4 packages: OpenVG-Base - base development package OpenVG-Tests - package to hold different tests OpenVG-Demo - package to hold different demos OpenVG-Plugin - VMMaker package sources. Before installing it, load the OpenVG-Base first. The platform source files is hosted at code.coogle and can be obtained via svn: svn checkout http://openvg-squeak.googlecode.com/svn/trunk/ Platforms: - currently plugin available only for win32 platform, sorry. If there is a brave soul to port the platform source on different platform , i can add him to developers :) To evaluate a plugin, install: OpenVG-Base, OpenVG-Tests , OpenVG-Demo packages next, download the squeak plugin from here: http://openvg-squeak.googlecode.com/files/OpenVGPlugin.dll now pick one of an OpenVG engine implementations: [1]http://www.amanithvg.com/download/ (a closed source , but VERY fast engine.. and for evaluation only :( ) it having a SRE and GLE versions. Use GLE version. [2]download & build own dll from http://sourceforge.net/projects/shivavg/ or download built by me: http://openvg-squeak.googlecode.com/files/OpenVGPlugin.dll There are also other OpenVG implementations available: - GinkoVG (software renderer) - Kompazz (seems like authors target it on unix platforms only) Now, after doing the above you are ready to run some code. First, tell a plugin, which OpenVG engine to use: OpenVGAPI loadLibrary: 'yourlibname.dll' Next, init the context: OpenVGAPI initContext Next, run some test: VGUTests new display Next run a tiger demo: VGTigerDemo runDemo have fun! P.S. at the moment, the OpenVG API coverage is not complete (no VGImage yet). So, you can play with paths/paints only. -- Best regards, Igor Stasenko AKA sig.

Aug. 1, 2009

Re: [Pharo-project] #remoteHostAddress

by Ramiro Diaz Trepat

Yes, wouldn't you expect 127.0.0.1 as the response from: NetNameResolver addressForName: 'localhost' ? On Fri, Jul 31, 2009 at 3:52 AM, John M McIntosh < johnmci(a)smalltalkconsulting.com> wrote: > Well that does > > > ^NetNameResolver addressForName: self localHostName > > where self localHostName on my machine returns 'Otter-2.local' > > where it really does addressesForName: and then if there is more than > one then > > addresses first socketAddress > > So for my mac it's > > fe80::21c:42ff:fe00:9%en5(Otter-2), > 0(0)-inet6-stream-tcp fe80::21c:42ff:fe00:8%en5(fe80::21c: > 42ff:fe00:8%en5), > 0(0)-inet6-stream-tcp fe80::21b:63ff:fe02:d2db%en5(fe80::21b: > 63ff:fe02:d2db%en5), > 0(0)-inet6-stream-tcp 10.37.129.2(10.37.129.2), > 0(0)-inet4-stream-tcp 10.211.55.2(10.211.55.2), > 0(0)-inet4-stream-tcp 192.168.1.139(192.168.1.139), > 0(0)-inet4-stream-tcp > > where it has 4 ipv 6 address and 3 ipv 4 addresses. > > and doing NetNameResolver localHostAddress then gives: > fe80::21c:42ff:fe00:9%en5(Otter-2),0(0) > > The problem then is figuring out what you want, versus grabbing the > first element in the list of IP address serviced by the machine. > Perhaps in this case you thought you should get 192.168.1.139? > > > Now if I ask for > ^NetNameResolver addressForName: 'localhost' > then I get back > ::1(localhost),0(0) > > > > On 30-Jul-09, at 2:07 PM, Ramiro Diaz Trepat wrote: > > > Sorry, this mail came out too quick. How to report the error is a > > secondary matter. > > I believe the issue is about localhost name resolution. I think > > this was discussed around the Windows VM platform, but I am on a Mac. > > > > > > NetNameResolver addressForName: 'localhost' > > > > does not return 127.0.0.1 > > > > And, > > > > NetNameResolver localHostAddress > > > > returns the address on the network leg (192.168.....) instead of > > 127.0.0.1 > > > > Is the convention that localhost is always 127.0.0.1 ? > > > > > > Cheers > > > > > > r. > > > > > > On Thu, Jul 30, 2009 at 9:20 PM, Ramiro Diaz Trepat < > ramiro(a)diaztrepat.name > > > wrote: > > 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. > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > = > = > = > ======================================================================== > John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > = > = > = > ======================================================================== > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Aug. 1, 2009

Re: [Pharo-project] Custom user Interrupt handling

by Michael Rueger

Dale Henrichs wrote: > 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.... Just write your own class (e.g. subclass UserInterruptHandler) and replace the handler (unregister the current one and register your own). That's why I designed it the way it is :-) michael

Aug. 1, 2009

Re: [Pharo-project] keyboard shortcut open a warning

by Marcus Denker

On Friday, July 31, 2009, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > may be we should simply remove that item. > Â Â Â Â menu > Â Â Â Â Â Â Â Â system > Â Â Â Â Â Â Â Â Â Â Â Â keyboard shortcuts yes > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

Aug. 1, 2009

Re: [Pharo-project] Fix for issue 981 Author class in pharo

by StÃ©phane Ducasse

Thanks miguel this is the right way to do it (ask for feedback) I'm sporadic internet connection so I do not even dare to do an update. Next week will be better. Stef On Aug 1, 2009, at 1:05 AM, Miguel CobÃ¡ wrote: > I have tested the SLICE of issue 981 on a new Pharo 10401 beta image > and an updated 10402 > image and it loads without problems. > > Should I mark this as milestone 1.0 or isn't elegible for this first > release? > I know that my opinion is biased, but I think that the 1.0 version of > pharo should have the > initials problem solved in order to base all the subsecuent code not > to depende on initials. > > Comments? > Has anyone confirmed that the functionality is correct? > What about the format of the name and the message prompt? > > Cheers, > Miguel CobÃ¡ > > On Mon, Jul 27, 2009 at 11:40 AM, Miguel CobÃ¡<miguel.coba(a)gmail.com> > wrote: >> 2009/7/25 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com>: >>> http://code.google.com/p/pharo/issues/detail?id=981 >>> >>> Name: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.3 >>> Author: MiguelCoba >>> Time: 25 July 2009, 3:53:41 am >>> UUID: 27a1accc-4f41-4d11-94f5-9bdbb4166bd7 >>> Ancestors: SLICE-ChangeAuthorInitialsAndNameToFullName-MiguelCoba.2 >>> Dependencies: Monticello-MiguelCoba.372, Morphic-MiguelCoba.347, >>> ScriptLoader-MiguelCoba.972, System-Changes-MiguelCoba.11, >>> System-Support-MiguelCoba.62, Tools-MiguelCoba.179 >>> >>> Removes all the code from initials and name on Author class. It is >>> replaced by a new fullName inst var and corresponding methods. The >>> old >>> code it is deprecated and the image contains no more calls to the >>> old >>> code. All the new code should call only the fullName methods in >>> Author >>> >>> >>> This is my first intent to rewrite the Author class to unify the >>> instance variables. >>> Please, check it on a 10392 core image and post your comments/ >>> critics. >>> >>> Also, I didn't modify the following methods of Utilities. Tell me >>> what >>> would you like to do with them, please: >>> >>> Utilities fixStamp: >>> Utilities methodsWithInitials: >>> Utilities doesMethod:forClass:bearInitials >>> >> >> Also, it should fix also >> >> http://code.google.com/p/pharo/issues/detail?id=142 >> http://code.google.com/p/pharo/issues/detail?id=344 >> >> I changed the status of 981 to fixed as directed by the >> HowToContribute wiki page. >> >> Miguel CobÃ¡ >> >>> Cheers, >>> Miguel CobÃ¡ >>> >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Aug. 1, 2009

Re: [Pharo-project] [ANN] Pharo 1.0 Beta

by Serge Stinckwich

On Sat, Aug 1, 2009 at 2:41 AM, StÃ©phane Ducasse<stephane.ducasse(a)inria.fr> wrote: > So what is the process now? > Do we focus on 1.0? > Can we integrate other issues? > Do we have a separate stream for 1.1 alpha? Maybe the 1.1 alpha should be available after the release of Pharo 1.0 so the efforts of the team is not disseminate on two versions. -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Smalltalkers do: [:it | All with: Class, (And love: it)] http://doesnotunderstand.org/

Aug. 1, 2009