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

[Pharo-project] Problems with SmaccDev and Pharo

by Oscar E A Callau

Hi all, My name is Oscar. I've been working with Pharo trying to do a gradual type system. Part of that is working with a Parser for a specific type annotation that I have. I'm using: *Pharo1.0rc1 Latest update: #10492 *SmaCC-lr.13 *SmaCCDev -lr.21 But I have some problems when I use SmaCCParserGenerator window, because I cannot select any option (there are some arrow pictures instead of check-buttons) and always get the error: MessageNotUnderstood: RBClass>>metaclass Does someone has either a suggestion or solution? (sorry If this is an easy/stupid problem) Greetings (I apologize for my poor english) Oscar E. A. CallaÃº P.S.: I attach a picture about the problem.

Nov. 25, 2009

[Pharo-project] Issue 1501 Monticello snapshot browser load class menu item only loads the 'side' (instance or class) that is currently displayed

by Stan Shepherd

In 10496 Browse eg MCHttpRepository location: 'http://www.squeaksource.com/ABKTEST' user: '' password: '' In the snapshot, call up and run menu item 'load class ABKWaSimpleTest' Browse the class. It has class or instance side methods, not both. http://code.google.com/p/pharo/issues/detail?id=1501 -- View this message in context: http://n2.nabble.com/Issue-1501-Monticello-snapshot-browser-load-class-menu… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 25, 2009

Re: [Pharo-project] Scriptloader class>>loadFFI

by Mariano Martinez Peck

yes, it is 1478 issue On Wed, Nov 25, 2009 at 4:35 AM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Isn't this issue http://code.google.com/p/pharo/issues/detail?id=1478 ? > > Adrian > > On Nov 25, 2009, at 01:48 , Schwab,Wilhelm K wrote: > > > At least your email system *HAS* a refresh button. Could somebody > > please tell me what stranglehold MS has on the market??? I thought > > group wise was bad when they foisted that on us :( > > > > > > > > > > -----Original Message----- > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto: > pharo-project-bounces(a)lists.gforge.inria.fr > > ] On Behalf Of Henrik Sperre Johansen > > Sent: Tuesday, November 24, 2009 7:21 PM > > To: pharo-project(a)lists.gforge.inria.fr > > Subject: Re: [Pharo-project] Scriptloader class>>loadFFI > > > > Have.. to... hit... refresh button before replying! ;) > > > > On 25.11.2009 01:18, David T. Lewis wrote: > >> Yes, that is probably it. The separate Pools package was set up to > >> permit VMMaker to have just the Pools package as a prerequisite, > >> rather than the entire FFI package. > >> > >> Dave > >> > >> On Tue, Nov 24, 2009 at 06:56:53PM -0500, Schwab,Wilhelm K wrote: > >> > >>> I think I found it: Andreas added a Pools sub-package, so #loadFFI > >>> needs to load it before the kernel. Right?? > >>> > >>> > >>> -----Original Message----- > >>> From: pharo-project-bounces(a)lists.gforge.inria.fr > >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > >>> Schwab,Wilhelm K > >>> Sent: Tuesday, November 24, 2009 6:52 PM > >>> To: Pharo-project(a)lists.gforge.inria.fr > >>> Subject: [Pharo-project] Scriptloader class>>loadFFI > >>> > >>> Does > >>> > >>> Scriptloader loadFFI > >>> > >>> work in RC1? It's barking at me about FFIConstants. > >>> > >>> Bill > >>> > >>> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > > 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 >

Nov. 25, 2009

[Pharo-project] Scriptloader class>>loadFFI

by Torsten Bergmann

Yes, its the same as issue 1478. And yes, we just have to load the (now splitted) pool constants before the kernel by adding the line install: 'FFI-Pool'; before install: 'FFI-Kernel'; in ScriptLoader>>loadFFI. Looks like Andreas split the FFI packages since VM Maker only needs the constants. Bye T. -- Preisknaller: GMX DSL Flatrate fÃ¼r nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02

Nov. 25, 2009

Re: [Pharo-project] Scriptloader class>>loadFFI

by Adrian Lienhard

Isn't this issue http://code.google.com/p/pharo/issues/detail?id=1478 ? Adrian On Nov 25, 2009, at 01:48 , Schwab,Wilhelm K wrote: > At least your email system *HAS* a refresh button. Could somebody > please tell me what stranglehold MS has on the market??? I thought > group wise was bad when they foisted that on us :( > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Henrik Sperre Johansen > Sent: Tuesday, November 24, 2009 7:21 PM > To: pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Scriptloader class>>loadFFI > > Have.. to... hit... refresh button before replying! ;) > > On 25.11.2009 01:18, David T. Lewis wrote: >> Yes, that is probably it. The separate Pools package was set up to >> permit VMMaker to have just the Pools package as a prerequisite, >> rather than the entire FFI package. >> >> Dave >> >> On Tue, Nov 24, 2009 at 06:56:53PM -0500, Schwab,Wilhelm K wrote: >> >>> I think I found it: Andreas added a Pools sub-package, so #loadFFI >>> needs to load it before the kernel. Right?? >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >>> Schwab,Wilhelm K >>> Sent: Tuesday, November 24, 2009 6:52 PM >>> To: Pharo-project(a)lists.gforge.inria.fr >>> Subject: [Pharo-project] Scriptloader class>>loadFFI >>> >>> Does >>> >>> Scriptloader loadFFI >>> >>> work in RC1? It's barking at me about FFIConstants. >>> >>> Bill >>> >>> >> _______________________________________________ >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 25, 2009

Re: [Pharo-project] OSProcess load

by Schwab,Wilhelm K

Dave, I did get .40. However, it seems to be much better behaved if the help is not displayed. AFAICT, removing the line avoids the interruption of what should be an unattended process. My build process now disables the deprecation warnings. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Tuesday, November 24, 2009 8:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess load On Tue, Nov 24, 2009 at 07:41:05PM -0500, Schwab,Wilhelm K wrote: > Dave, > > Did you update the repository for CommandShell? Yes. > It still is not loading cleanly, even in a current RC1 image, so I > don't think it is my build process. Make sure you have this version from SqueakSource: Name: CommandShell-dtl.40 Author: dtl Time: 18 November 2009, 10:27:48 am UUID: 62cd334e-61eb-4427-8441-8e4c6b3788d9 Ancestors: CommandShell-dtl.39 CommandShell 4.4.3 Use text style 'DefaultFixedTextStyle' rather than 'Atlanta' and fall back to default if none found. Motivated by Pharo. > I *think* all that needs to happen is that the line that processes > 'help' needs to be removed and the packages should load cleanly - at > least that's what happens when I save the result to my cache. The problem was a reference to a font that does not exist in Pharo. During loading, you should still expect to have to proceed through the warnings about MVC classes, and you will get lots of deprecation warning about #isMorphic unless you turn off the #showDeprecationWarnings preference. FYI, the command that processes 'help' is opening a command shell window and feeding it the 'help' command. Dave _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Nov. 25, 2009

Re: [Pharo-project] OSProcess load

by David T. Lewis

On Tue, Nov 24, 2009 at 07:41:05PM -0500, Schwab,Wilhelm K wrote: > Dave, > > Did you update the repository for CommandShell? Yes. > It still is not loading cleanly, even in a current RC1 image, so I > don't think it is my build process. Make sure you have this version from SqueakSource: Name: CommandShell-dtl.40 Author: dtl Time: 18 November 2009, 10:27:48 am UUID: 62cd334e-61eb-4427-8441-8e4c6b3788d9 Ancestors: CommandShell-dtl.39 CommandShell 4.4.3 Use text style 'DefaultFixedTextStyle' rather than 'Atlanta' and fall back to default if none found. Motivated by Pharo. > I *think* all that needs to happen is that the line that > processes 'help' needs to be removed and the packages should load > cleanly - at least that's what happens when I save the result to my cache. The problem was a reference to a font that does not exist in Pharo. During loading, you should still expect to have to proceed through the warnings about MVC classes, and you will get lots of deprecation warning about #isMorphic unless you turn off the #showDeprecationWarnings preference. FYI, the command that processes 'help' is opening a command shell window and feeding it the 'help' command. Dave

Nov. 25, 2009

Re: [Pharo-project] windows 64 bit: printing NetNameResolver localHostAddress fails even after evaluating NetNameResolver initializeNetwork

by Schwab,Wilhelm K

Does not surprise me. I have been getting some DNU errors over #remoteAddress or something. I need to dig into it and make sure I didn't cause it. It further happens only on timeouts, so it was a bit more elusive. I'll bet that if you look into it, you will find code that is sometimes protected by #useOldNetwork and other times called without the test. We really need to separate the IPv4 and 6 code with subclasses so that we can see what is related to what - at least that is how I have approched the little bit of work I've been able to do on this. While I am rambling, suppose a name maps to many addresses, and the DNS server is doing round-robin distribution. What should NetNameResolver do in that case? It was always giving me one particular address - the one to a host that did not exist. $10 says somebody was using a Microsoft security tool to improve our network ;) On the lighter side: I think I just successfully built an RC1 image!!!! Bill ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramiro Diaz Trepat Sent: Tuesday, November 24, 2009 7:17 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] windows 64 bit: printing NetNameResolver localHostAddress fails even after evaluating NetNameResolver initializeNetwork A bit more on this, although I have not debugged any code yet. Start a Pharo image with Seaside running on port 8080 1) 'http://127.0.0.1:8080/seaside' asUrl retrieveContents. Works on Linux, but NetNameResolver throws a "primitive has failed exception on a Mac with the latest VM. 2) 'http://localhost:8080/seaside' asUrl retrieveContents. Time's out in both Linux and Mac 3) 'http://www.google.co.uk' asUrl retrieveContents Works in both platforms On Mon, Nov 23, 2009 at 10:19 AM, Adrian Lienhard <adi(a)netstyle.ch<mailto:adi@netstyle.ch>> wrote: What exactly has changed in the networking code in Pharo compared to Squeak 3.9/3.10? Adrian On Nov 23, 2009, at 01:13 , Ramiro Diaz Trepat wrote: > I am having the same issues trying to connet a Magma Client and a > Magma > Server in "localhost" using the latest Pharo on Snow Leopard (Mac). > It is this issue with NetNameResolver, I couldn't find a work around > yet. > Forcing '127.0.0.1' for localhost used to work before, but not > anymore. > Same image and code seemed to run fine under Linux though. > Cheers > > r > > > > > > 2009/11/22 Bart Gauquie <bart.gauquie(a)gmail.com<mailto:bart.gauquie@gmail.com>> > >> This is related to: >> http://lists.gforge.inria.fr/pipermail/pharo-project/2009-November/016021.h… >> >> I was trying out magma on Pharo. I'm using magma r43final on >> Pharo1.0rc1 >> Latest update: #10493 on Windows Vista 64 bit. >> >> In order for the magma client wanting to connect to the server i >> had to >> adapt >> NetNameResolver>>useOldNetwork >> ^true >> >> It worked till i tried the new high availability of magma. If i >> tried with >> a node to connect to a primary server i always got following error >> on the >> secondary node: MagmaSession>>signalExceptionLike with as message: 'a >> primitive has failed'. After some debugging i figured out that the >> it in >> fact was the primary server which sent to the secondary an Error >> object with >> message text: 'a primitive has failed'. >> >> in the primary server log: >> >> MaLocalRequestServer(MaRequestServer)>>processRequest: >> Receiver: a MaLocalRequestServer >> Arguments and temporary variables: >> aMaClientServerRequest: a MaCommitRequest >> answer: Error: a primitive has failed >> Receiver's instance variables: >> console: a MaRequestServerConsole >> processor: a MagmaRepositoryController >> >> >> Inspired by some issues mentioned @ google code, I tried to evaluate >> NetNameResolver localHostAddress >> on the primary server image. That worked, however trying to print >> that >> resulted in 'a primitive has failed'. >> Even after the NetNameResolver initializeNetwork suggestions I found. >> >> error: >> >> NetNameResolver class(Object)>>error: >> Receiver: NetNameResolver >> Arguments and temporary variables: >> aString: 'a primitive has failed' >> Receiver's instance variables: >> superclass: Object >> methodDict: a MethodDictionary() >> format: 2 >> instanceVariables: nil >> organization: ('as yet unclassified') >> >> subclasses: nil >> name: #NetNameResolver >> classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true >> #ResolverBusy->...etc... >> sharedPools: nil >> environment: Smalltalk >> category: #'Network-Kernel' >> traitComposition: nil >> localSelectors: nil >> >> NetNameResolver class(Object)>>primitiveFailed >> Receiver: NetNameResolver >> Arguments and temporary variables: >> >> Receiver's instance variables: >> superclass: Object >> methodDict: a MethodDictionary() >> format: 2 >> instanceVariables: nil >> organization: ('as yet unclassified') >> >> subclasses: nil >> name: #NetNameResolver >> classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true >> #ResolverBusy->...etc... >> sharedPools: nil >> environment: Smalltalk >> category: #'Network-Kernel' >> traitComposition: nil >> localSelectors: nil >> >> NetNameResolver class>>primGetNameInfo:flags: >> Receiver: NetNameResolver >> Arguments and temporary variables: >> <<error during printing> >> Receiver's instance variables: >> superclass: Object >> methodDict: a MethodDictionary() >> format: 2 >> instanceVariables: nil >> organization: ('as yet unclassified') >> >> subclasses: nil >> name: #NetNameResolver >> classPool: a Dictionary(#DefaultHostName->'' #HaveNetwork->true >> #ResolverBusy->...etc... >> sharedPools: nil >> environment: Smalltalk >> category: #'Network-Kernel' >> traitComposition: nil >> localSelectors: nil >> >> SocketAddress>>hostNumber >> Receiver: <<error during printing>> >> Arguments and temporary variables: >> size: nil >> name: nil >> Receiver's instance variables: >> <<error during printing>> >> >> SocketAddress>>printOn: >> Receiver: <<error during printing>> >> Arguments and temporary variables: >> aStream: a LimitedWriteStream '' >> Receiver's instance variables: >> <<error during printing>> >> >> [] in SocketAddress(Object)>>printStringLimitedTo: >> Receiver: <<error during printing>> >> Arguments and temporary variables: >> s: a LimitedWriteStream '' >> Receiver's instance variables: >> <<error during printing>> >> >> >> I then tried to revert the changes to NetNameResolver back to: >> useOldNetwork >> ^UseOldNetwork ~~ false >> >> >> printing NetNameResolver localHostAddress now nicely printed a ipv6 >> address. However if i then try to connect to the primary server >> from the >> secondary server i get: >> MagmaSession>>signalExceptionLike >> >> MagmaEnvironmentError: magma@PC_XX:51003 could not be made a warm >> backup >> because it is not reachable from magma@PC_XX:51001. >> >> Which is again the same ipv6 error. So the problem i'm facing is that >> either of them work >> I can connect with my magma client to the server if i enable ipv4 >> only, but >> then high availability dont work and vice verse. >> >> Anyone any id how i can debug the primitive has failed on: >> NetNameResolver class>>primGetNameInfo: socketAddress flags: flags >> <primitive: 'primitiveResolverGetNameInfo' module: 'SocketPlugin'> >> flags == 0 ifTrue: [^self primGetNameInfo: socketAddress >> flags: SocketAddressInformation numericFlag]. >> self primitiveFailed >> >> further more, why cant the primitiveFailed mention which primitive >> has >> failed? >> >> Thanks, >> >> Kind Regards, >> >> Bart >> >> -- >> imagination is more important than knowledge - Albert Einstein >> Logic will get you from A to B. Imagination will take you >> everywhere - >> Albert Einstein >> Learn from yesterday, live for today, hope for tomorrow. The >> important >> thing is not to stop questioning. - Albert Einstein >> The true sign of intelligence is not knowledge but imagination. - >> Albert >> Einstein >> Gravitation is not responsible for people falling in love. - Albert >> Einstein >> >> _______________________________________________ >> 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 >> > _______________________________________________ > 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 _______________________________________________ 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

Nov. 25, 2009

Re: [Pharo-project] Scriptloader class>>loadFFI

by Schwab,Wilhelm K

At least your email system *HAS* a refresh button. Could somebody please tell me what stranglehold MS has on the market??? I thought group wise was bad when they foisted that on us :( -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Henrik Sperre Johansen Sent: Tuesday, November 24, 2009 7:21 PM To: pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Scriptloader class>>loadFFI Have.. to... hit... refresh button before replying! ;) On 25.11.2009 01:18, David T. Lewis wrote: > Yes, that is probably it. The separate Pools package was set up to > permit VMMaker to have just the Pools package as a prerequisite, > rather than the entire FFI package. > > Dave > > On Tue, Nov 24, 2009 at 06:56:53PM -0500, Schwab,Wilhelm K wrote: > >> I think I found it: Andreas added a Pools sub-package, so #loadFFI needs to load it before the kernel. Right?? >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of >> Schwab,Wilhelm K >> Sent: Tuesday, November 24, 2009 6:52 PM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] Scriptloader class>>loadFFI >> >> Does >> >> Scriptloader loadFFI >> >> work in RC1? It's barking at me about FFIConstants. >> >> Bill >> >> > _______________________________________________ > 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

Nov. 25, 2009

[Pharo-project] OSProcess load

by Schwab,Wilhelm K

Dave, Did you update the repository for CommandShell? It still is not loading cleanly, even in a current RC1 image, so I don't think it is my build process. I *think* all that needs to happen is that the line that processes 'help' needs to be removed and the packages should load cleanly - at least that's what happens when I save the result to my cache. Bill

Nov. 25, 2009