- Pharo-dev - lists.pharo.org

[Pharo-project] VNC for pharo 1.3 or 1.4
by Hernan Wilkinson April 27, 2012

April 27, 2012

Hi does anybody ported the implementation of VNC to pharo 1.3 or 1.4? If so, could you share it? :-) Thanks! Hernan. -- *HernÃ¡n Wilkinson Agile Software Development, Teaching & Coaching* *Phone: +54 - 011 - 4311 - 8404** Mobile: +54 - 911 - 4470 - 7207 email: hernan.wilkinson(a)10Pines.com site: http://www.10Pines.com <http://www.10pines.com/>* Address: Paraguay 523, Floor 7 N, Buenos Aires, Argentina

8 11

[Pharo-project] Donating to Pharo
by Sean P. DeNigris April 27, 2012

April 27, 2012

I noticed http://code.google.com/p/pharo/wiki/ListOfMonthlyDonators How do I join? -- View this message in context: http://forum.world.st/Donating-to-Pharo-tp4591066p4591066.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

4 4

[Pharo-project] System browser in Pharo 1.4
by Olivier Auverlot April 27, 2012

April 27, 2012

Hi, This is probably a stupid question. Why in Pharo 1.4, the system browser does not display classes hierarchically in the column instances / class. Each class is displayed at the same level. It's not easy to read. How to get the same behavior as in previous versions of Pharo ? Best regards Olivier

6 6

[Pharo-project] Who is maintaining the Grease configuration
by StÃ©phane Ducasse April 27, 2012

April 27, 2012

Because we should create a symbolic version for 20 This package depends on the following classes: BlockContext You must resolve these dependencies before you will be able to load these definitions: fixCallbackTemps tempVarRefs valueWithPossibleArguments:

2 11

[Pharo-project] Polymorph (and a few other) changes/fixes
by Gary Chambers April 27, 2012

April 27, 2012

Finally found the time to package out. Have tested a bit after fixing some conflicts. A few minor ones left for DropListMorph as it seems the wrapSelector stuff has changed (and appears broken in 2.0 too). Attached cs and description of changes Regards, Gary

5 25

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] CogVM binaries as per VMMaker.oscog-eem.157/r2550.
by Mariano Martinez Peck April 27, 2012

April 27, 2012

On Fri, Apr 27, 2012 at 7:37 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Fri, Apr 27, 2012 at 12:57 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> >> 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 ?? >> > > Yes. Find attached. > >> >> Thanks. I did slice for Pharo. http://code.google.com/p/pharo/issues/detail?id=5728 > >> 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 >> >> >> > > > -- > best, > Eliot > > > -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] http://book.pharo-project.org/ down
by Guillermo Polito April 27, 2012

April 27, 2012

:(

2 2

[Pharo-project] [update 2.0] #20024
by Marcus Denker April 27, 2012

April 27, 2012

20024 ----- Issue 5719: Create trait with Nautilus fails http://code.google.com/p/pharo/issues/detail?id=5719 -> last Nautilus and Spec packages -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] [Pharo-bugtracker] Issue 5714 in pharo: VersionsBrowser for human beings
by Mariano Martinez Peck April 27, 2012

April 27, 2012

This is so cool!!! guys, take a look to it :) On Fri, Apr 27, 2012 at 2:49 PM, <pharo(a)googlecode.com> wrote: > Updates: > Status: Integrated > > Comment #3 on issue 5714 by marcus.d...@gmail.com: VersionsBrowser for > human beings > http://code.google.com/p/**pharo/issues/detail?id=5714<http://code.google.com/p/pharo/issues/detail?id=5714> > > in 2.0 021 > > > > ______________________________**_________________ > Pharo-bugtracker mailing list > Pharo-bugtracker@lists.gforge.**inria.fr<Pharo-bugtracker(a)lists.gforge.inria.fr> > http://lists.gforge.inria.fr/**cgi-bin/mailman/listinfo/**pharo-bugtracker<http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker> > -- Mariano http://marianopeck.wordpress.com

1 0

[Pharo-project] more fixes to svg importer
by Igor Stasenko April 27, 2012

April 27, 2012

now its much better.. still there are some parts missing.. mainly those: support for elliptical arcs.. ASEllipse / #ellipticalArc: r xrot: xrot large: large sweep: sweep to: pt .. should add this type of segment to path builder. they are usually approximated either by quad or cubic bezier.. and there is a .java code for it.. just need to port it. Also some svg playing with layers/transparency groups.. to render them correctly a renderer much allocate multiple bitmap buffers to render intermediate layers separately. this is also used for masking etc and of course filters.. not implemented. and no protocol for changing the blit mode yet. -- Best regards, Igor Stasenko.

1 1