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

[Pharo-project] [update 2.0] #20015

by Marcus Denker

20015 ----- Issue 5691: all sender of #getSourceFor:in: can just use #sourceCode http://code.google.com/p/pharo/issues/detail?id=5691 Issue 5651: Fix for Classbuilder (subclasses of CompiledMethod) http://code.google.com/p/pharo/issues/detail?id=5651 Issue 5690: CompiledMethod #sourceClass and #sourceSelector http://code.google.com/p/pharo/issues/detail?id=5690 -- Marcus Denker -- http://marcusdenker.de

April 27, 2012

[Pharo-project] remotely sharing a pharo screen

by Ben Coman

I want to remotely share a Pharo screen, so can have a phone hookup with someone while are trying some things out. I have just seen VNC metioned is for remote control. Does this allow shared access to the screen? Or are the some other options cheers -ben

April 27, 2012

[Pharo-project] [update 2.0] #20014

by Marcus Denker

20014 ----- Issue 5699: Failing test: EventHandlerTest http://code.google.com/p/pharo/issues/detail?id=5699 -- Marcus Denker -- http://marcusdenker.de

April 27, 2012

Re: [Pharo-project] TestCase>>#assert:equals: optimization

by Mariano Martinez Peck

Fix in inbox http://code.google.com/p/pharo/issues/detail?id=5562 On Thu, Mar 15, 2012 at 8:58 PM, Stefan Marr <smalltalk(a)stefan-marr.de>wrote: > Hi: > > While stepping through bytecodes, I noticed a slightly annoying > inefficiency in the SUnit implementation. > The description string in #assert:equals: is always computed, even if it > is not necessary. > > While that might not be a performance problem, I find it rather > distracting when I have to debug on the bytecode/VM level. > > Since there seem to be only 127 senders or so in the image, you will > probably not notice a big performance gain. > The change to compute the string only when necessary is below. > > Best regards > Stefan > > PS: This is a resend, because the original mail seemed to have been lost, > while the mailing list was down. > > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:41'! > assert: aBooleanOrBlock description: aStringOrBlock > aBooleanOrBlock value ifFalse: [ > | aString | > aString := aStringOrBlock value. > self logFailure: aString. > TestResult failure signal: aString] > ! ! > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > assert: aBooleanOrBlock description: aStringOrBlock resumable: > resumableBoolean > | exception | > aBooleanOrBlock value > ifFalse: > [|aString| > aString := aStringOrBlock value. > self logFailure: aString. > exception := resumableBoolean > ifTrue: [TestResult > resumableFailure] > ifFalse: [TestResult > failure]. > exception signal: aString] > ! ! > > !TestCase methodsFor: 'asserting' stamp: 'StefanMarr 3/13/2012 23:40'! > assert: expected equals: actual > ^ self > assert: (expected = actual) > description: [self comparingStringBetween: actual and: > expected] > ! ! > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- Mariano http://marianopeck.wordpress.com

April 27, 2012

Re: [Pharo-project] Morphic replacement

by pasduti

Fernando Olivero <fernando.olivero@...> writes: > > Dear all, > > I've been working on a hole replacement of Morphic myself, because if > was tired of fixing Morphic (or porting CUIS Morphic into Pharo), and > found much more productive the approach of rewriting it from scratch. > Hi, I'm new to smalltalk and I'm looking for a gui toolset. I was thinking to do the same like you did because it's hard to find information about Morphic, ... Where could I get that code ?

April 27, 2012

[Pharo-project] [update 2.0] #20013

by Marcus Denker

20013 ----- Issue 5700: Failing test: MethodReferenceTest http://code.google.com/p/pharo/issues/detail?id=5700 Issue 5687: remove and clean up CompiledMethod>>#hasNewPropertyFormat http://code.google.com/p/pharo/issues/detail?id=5687 -- Marcus Denker -- http://marcusdenker.de

April 27, 2012

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] CogVM binaries as per VMMaker.oscog-eem.157/r2550.

by Mariano Martinez Peck

On Thu, Apr 19, 2012 at 6:06 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Thu, Apr 19, 2012 at 12:55 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> On Thu, Apr 19, 2012 at 6:08 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> http://www.mirandabanda.org/files/Cog/VM/VM.r2550/ >>> >>> CogVM binaries as per VMMaker.oscog-eem.157/r2550. >>> >>> Stack/CoInterpreter/Cogit: >>> Implement proper bounds checking for byte access to compiled >>> methods. Raise errors for accesses outside initialPC to size. >>> >>> CoInterpreter: >>> Provide a thorough flush primitive for CompiledMethods that discards all >>> machine code and makes sure that any contexts using the method have bytecode >>> pcs. Primitive #215 (same as 116 in the Stack VM). This is much slower than >>> 116 (flushCache) since it has to enumerate over all heap contexts. >>> >>> >> Excellent. Does it mean we should implement something like this: >> >> CompiledMethod >> flushCache >> "Tell the interpreter to remove all references to this method from >> its method lookup cache, if it has one. In addition, it provides a thorough >> flush primitive for CompiledMethods that discards all machine code and >> makes sure that any contexts using the method have bytecode >> pcs. >> This primitive must be called whenever a method is redefined or >> removed." >> <primitive: 215> >> self simpleFlushCache >> >> >> CompiledMethod >> simpleFlushCache >> "Tell the interpreter to remove all references to this method from >> its method lookup cache, if it has one. This primitive must be called >> whenever a method is redefined or removed." >> >> <primitive: 116>\ >> > > No. 215 is extremely expensive, because it scans the entire heap looking > for contexts using the method, and in the common case of redefining a > method it is unnecessary. It is only necessary if you modify a method > still in-use; read the comment of the attached method. > > Further, I would prefer to update the Interpreter to implement primitive > 215 using primitive 116, i.e. in the Interpreter's primitive table have both > > (116 primitiveFlushCacheByMethod) > ... > (215 primitiveFlushCacheByMethod) "primitiveVoidVMStateForMethod in the > CoInterpreter" > > This is what I've done in the StackInterpreter. In fact, we need to put > in time to bring the Interpreter's primitive set into agreement with Cog. > > Ok, I understand. Now, primitive 215 #primitiveVoidVMStateForMethod receives a CompiledMethod so we implement #voidCogVMState there. However, I see there is also primitive 214 #primitiveVoidVMState. Should we ALSO add something like voidCogVMState "Void all internal VM state in the stack and machine code zones <primitive: 214> ^self primitiveFailed But implemented in SmallttalkImage/VirtualMachine ?? thanks! > > So I'm expecting we will have > > voidCogVMState > "Tell the VM to remove all references to any machine code form of the > method. > This primitive must be called whenever a method is in use and modified. > This is > more aggressive (and *much* more costly) than flushCache since it must > search > through all context objects, making sure that none have a (hidden) > machine code pc > in the receiver. Since modifying a method will likely change the > generated machine code, > modifying a method (rather than redefining it) requires this more > aggressive flush." > > <primitive: 215> > ^self primitiveFailed > > flushCache > "Tell the interpreter to remove all references to this method from its > method lookup cache, if it has one. This primitive must be called whenever > a method is defined or removed. > NOTE: Only one of two selective flush methods needs to be used. > Squeak 2.2 and earlier uses 119 (See Symbol flushCache). > Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)." > > <primitive: 116> > > or > > voidCogVMState > "Tell the VM to remove all references to any machine code form of the > method. > This primitive must be called whenever a method is in use and modified. > This is > more aggressive (and *much* more costly) than flushCache since it must > search > through all context objects, making sure that none have a (hidden) > machine code pc > in the receiver. Since modifying a method will likely change the > generated machine code, > modifying a method (rather than redefining it) requires this more > aggressive flush." > > <primitive: 215> > ^self flushCache > > flushCache > "Tell the interpreter to remove all references to this method from its > method lookup cache, if it has one. This primitive must be called whenever > a method is defined or removed. > NOTE: Only one of two selective flush methods needs to be used. > Squeak 2.2 and earlier uses 119 (See Symbol flushCache). > Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)." > > <primitive: 116> > > >> >> >> If you have a better name for #simpleFlushCache please let me know. >> if you agree, I will open an issue for this. >> >> Cheers >> >> >> >>> >>> Provide an xray primitive for CompiledMethod that answers if a method has >>> machine code, and if so if it's machine code is frameless, and/or refers >>> to a young object. No primitive number. Used to test the above. >>> >>> Make printOopShort: print Association keys. Useful for >>> longPrintOop:, and hence printReferencesTo: etc. >>> >>> Mac OS: add fflush to debug printing in sqMacUIEventsUniversal.c so output >>> appears promptly. >>> >>> Fix the annoying bogus error messages from the mprotect calls by getting the >>> length arg to mprotect right. >>> >>> Add version infor for the Cross/plugins tree. Add a -version switch to win32 >>> >>> -- >>> >>> best, >>> >>> Eliot >>> >>> >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> > > > -- > best, > Eliot > > > -- Mariano http://marianopeck.wordpress.com

April 27, 2012

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

by StÃ©phane Ducasse

would be good to package it with a stable version and publish it for 1/4 in the MetaRepoForPharo14 Any taker? Stef On Apr 26, 2012, at 5:40 PM, Norbert Hartl 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

April 27, 2012

Re: [Pharo-project] Pharo and the rest of the ecosystem

by Norbert Hartl

Am 27.04.2012 um 00:12 schrieb StÃ©phane Ducasse: > > On Apr 26, 2012, at 5:46 PM, Casimiro de Almeida Barreto wrote: > >> I guess that one thing for immediate future of an open source "industry >> grade" smalltalk is to define foundation classes to deal with core >> functionality (file and directory management, (inter)networking, >> multimedia, interfacing with OS, user interface (including seamless use >> of full screen display and OpenGL), etc, etc, etc. > > I hope to start to work on RestrictedSmalltalk once we got the bootstrap up and running. > RestrictedSmalltalk should be closer to Smalltalk than RestrictedPython is from Python :) > but I like the idea that we can understand what is really needed for the core and in particular > from the reflective features. > Yes, knowing the foundation where we standing on can be quite life-sustaining. Ok, it's turtles but even the turtles are made of something. I would love to participate with you guys but that's hard if not present in personal, right? A good sparring-partner will be Craig I think. The last weekend he showed a list of classes and methods that he thinks are essential to do anything useful. A good startpoint for arguing. Norbert

April 27, 2012

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

by Milan Mimica

Works fine once you fix it: http://forum.world.st/leaking-semaphores-tt4432983.html On 26 April 2012 17:40, 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 > -- Milan Mimica http://sparklet.sf.net

April 27, 2012