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

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

by Henrik Sperre Johansen

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

Nov. 25, 2009

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

by Henrik Sperre Johansen

Yes, that's probably it. It was separated out as an individual package so it is less to load into a VMMaker-image, I believe. Cheers, Henry On 25.11.2009 00:56, 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

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

by David T. Lewis

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 >

Nov. 25, 2009

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

by Ramiro Diaz Trepat

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> 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> > > > >> 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 > >> 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] Scriptloader class>>loadFFI

by Schwab,Wilhelm K

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

Nov. 24, 2009

[Pharo-project] Scriptloader class>>loadFFI

by Schwab,Wilhelm K

Does Scriptloader loadFFI work in RC1? It's barking at me about FFIConstants. Bill

Nov. 24, 2009

Re: [Pharo-project] PackageInfo>>classes does not distinguish traits from classes (issue?)

by Simon Denier

On 24 nov. 2009, at 18:17, StÃ©phane Ducasse wrote: > What is strange adrian is that before we did not encounter this > problem in moose. > May be something changes and we did not notice it. Keeping in line with the saying "to clean up your own back yard", I think it's more related to a change in the Moose importer, especially dealing with the package cache. I changed some parts of the package importer in September (but it does not look to change this aspect to me). Now my memory is a bit fuzzy, so I cant track down at which point the last Pharo import worked (this summer?) Sorry, it's a bit off topic for the Pharo ML :) > > Stef > On Nov 23, 2009, at 10:31 PM, Adrian Lienhard wrote: > >> Hi Simon, >> >> There is no such method. But it would be easy to add (just send >> "aPackage classes select: #isTrait"). The reason for returning traits >> with the classes is that clients of PackageInfo typically expect >> "compilation units", i.e., a collection including traits. The naming, >> of course, is not optimal, and should be fixed in the long run. The >> problem is to do so without breaking the clients of PackagInfo. >> >> Cheers, >> Adrian >> >> On Nov 23, 2009, at 16:28 , Simon Denier wrote: >> >>> Hi there >>> >>> When I run PackageInfo>>classes, I get both classes and traits >>> defined >>> in the package. So I can understand the need for a method retrieving >>> all 'compilation units' (or behaviors) from a package, but is >>> there no >>> method to just retrieve the regular classes? Especially since >>> there is >>> a #externalTraits method. >>> >>> -- >>> Simon >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -- Simon

Nov. 24, 2009

Re: [Pharo-project] New version of OCompletion

by Alexandre Bergel

>> - inserting a '(' before an alphanumeric character does not insert a >> ')'. > I not get this one. > 0 -> (0 > a -> (a > a -> ( a) If the caret is on a letter or a number, then you do not get the completion. I think I was inspired by XCode. This is a behavior that looks okay to me. But I remain open to suggestion. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 24, 2009

[Pharo-project] A brilliant idea... Re: Pharo Sprint

by Lawson English

I would have liked to be a fly on the wall during that, even though I suspect it was way beyond my comprehension... Which leads me to one of my most brilliant ideas ever (IMHO)... With the second life setup used by NPR's Science Friday radio show http://www.sciencefriday.com/ and the Metanomics virtual world TV show http://www.metanomics.net/ it IS possible to be a fly on the wall during such an event. My idea: have 2 talented Squeak programmers working on some problem. It might be a simple one or hideously complex or whatever. Have a skype connection between the two + a VNC connection. Now, pipe the skype into Second Life voice. Pipe the VNC into a passive streaming QT connection. Simulcast on Second Life and a web page. Leverage the metanomics mega-local-chat for kibbitzing and questions (highlighted by prefixing QUESTION: to the local chat). Now let the pair programming begin. Occasionally, one of the programmers can glance at the comments flowing past from Second Life and the website and respond (you can writer a filter the comments by the prefix "QUESTION:", so they can go to a separate window, ditto with "SUGGESTION:"). What do you gain? You gain the ability to let other programmers look over your shoulder during pair programming and discuss what is going on quietly among themselves, which could make for a wonderful real-world teaching tool. You ALSO gain the ability to have an unlimited number of programmers glancing over your shoulder and making suggestions without distracting the flow of the programming session. This wouldn't be hard to set up. I know the people who work on the Science Friday and Metanomics projects and I suspect they would be quite interested in working this up. The only issue is $$ for the simulcast video stream. You could start small for tests and work up. With "unlimited" funding you could easily have 500+ passive participants in the session once it gets going. Everyone is thinking "why not do this with croquet/cobalt?" The answer is that you can! BUT, SciFri and Metanomics have already set up the machinery for this on a large scale in Second Life, and there is a pre-existing potential audience of many thousands of computer geeks who lurk in Second Life already at any given moment. It would also be great advertising for Squeak/Cobalt/Croquet if such sessions showed off some spiffy aspect of those technologies. You could have purely beginning level, intermediate level and advanced teaching sessions, as well as real-world problem solving sessions. They may or may not be widely watched, but you never know unless you try. And imagine if such a session were slash-dotted and/or mentioned on Science Friday... Lawson (always in marketing mode) Alexandre Bergel wrote: > Aldo and I seat down during the Pharo Sprint on Saturday. We had fun. > Below what we did. > > > ISSUE #262 (fixed) > Doits are now executed by primtive. This means, a doit method is > *never* installed in a class. > We removed all now unnecessary checks of isDoit > > - Behavior>>allLocalCallsOn: > - ChangeSet>>atSelector: selector class: class put: changeType > - MethodReference>>isValid > - PCCByCompilation>>methodsWithDisabledCall > - PackageInfo>>methods > - SystemNavigation>>browseAllCallsOn: aLiteral localTo: aClass > > Pair programmed with Aldo Mettini > > Slice_262_isDoIt-Alexandre_Bergel.1 in Pharo Inbox > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > ISSUE #1486 (fixed) > > Added BehaviorTest>>testAllLocalCallsOn > > Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks > 2009 > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > ISSUE #1488 (new) > > Dictionary is not a superclass of SmallDictionary, and > SmallDictionary is not a subclass of Dictionary. The only common > superclass of these two classes is Collection. Putting > unreferencedKeys in Collection does not look too good as well. > Therefore, unreferencedKeys looks like to be a good candidate for > being shared by a trait. > > Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks > 2009 > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > ISSUE #261 (fix) > > Even though allCallsOn: implies something about "calls" which seems to > be related to sends, it actually even is used for references to classes. > > We added a SystemNavigation>>allReferencesTo: aLiteral that returns > the list of methods referencing aLiteral. > We simplified allCallsOn: since now it acts on symbols only. It raises > a deprecation warning if a binding is provided to allCallsOn:. We > refactored all callers of allCallsOn: and wrote some tests (for the > one that was easy to write): BehaviorTest>>testAllCallsOn > > Pair programmed with Aldo Mettini during the Pharo Sprint @ Smalltalks > 2009 > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > Cheers, > Alexandre >

Nov. 24, 2009

Re: [Pharo-project] (no subject)

by StÃ©phane Ducasse

On Nov 24, 2009, at 6:55 PM, Lukas Renggli wrote: >> Is there a kind of comparison table of the features available in Eclipse versus the Smalltalks' RBs? > > I was not talking about feature completeness, I was more talking about > the usability of the editor and how the different tools integrate. It > is impressive that you see the renaming happening live in Eclipse > while you type a new class/variable/method name. yes the usability is clearly not the best aspect of smalltalk right now. > I don't know of a single refactoring in Eclipse that is not available > in Smalltalk, of course excluding some of the refactorings that mangle > with types, packages or inner-class and that do not make sense in the > context of Smalltalk. Furthermore the Smalltalk refactoring engine > provides an universal code transformation engine that allows one to > script new transformations (refactorings) within seconds. This is > something that I have not yet seen in any other language with that > sophistication. > > Lukas > > -- > Lukas Renggli > http://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

Nov. 24, 2009