- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by StÃ©phane Ducasse

thanks mariano for your work! Stef On May 20, 2010, at 10:05 PM, Mariano Martinez Peck wrote: > Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev image with PharoCore 1.1 so the image may be not 100% stable. However, we think it is good to release it so that people can start to test it, load their own packages, adapt them, etc. We would like to receive feedback about it. It (yet) has failing and error tests. > > The main changes with Pharo 1.0 is that of course, it is based on a PharoCore 1.1 with all that it means. We started to write down some of the actions done in PharoCore 1.1. The list so far can be found here: > http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne > Of course, for the stable releae of Pharo 1.1 we will do a clear list in the website as we did for 1.0. > > Regarding the included packages in 1.1 we added ScriptManager (a tool to manage and persist workspaces), ProfStefBrowser, ArchiveViewer, MethodWrappers and ObjectMetaTools (which includes things like ProtocolCatcher, ObjectTracer, ObjectViewer, etc). > > Another difference is the font. In Pharo 1.0 we used TrueType fonts by default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin, netiher to have the fonts). However, of course, you can disable StrikeFonts and put TrueType like in 1.0. > > That's all. We would really appreciate you use it, test it, report issues, provide fixes, etc. It is important also that you start to use your own packages/applications. There have been several changes in 1.1 that may require change in your code. > > Ahh if you want to create the image yourself, check as usually the installScript.st file to see how to do it. Actually, you can just take a PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0): > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfPharo'; > load. > > ((Smalltalk at: #ConfigurationOfPharo) project version: '1.1-beta1.10517') load. > > Here is the link to the image: > > https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2010

[Pharo-project] FFI Documentation

by Torsten Bergmann

>I want to get this info into the help system and/or collaborative book, as >similar questions pop up regularly on the lists. Hi Sean, Here is the compiled book - see the attached MCZ. Just file it in. If you continue with it it would be good to upload it to the FFI repository at http://source.squeakfoundation.org/FFI We can then also add it to the ConfigurationOfFFI. Thx T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

[Pharo-project] [BetaTesting] [ANN] Pharo-1.1-11367-Beta1dev10.05.1

by Mariano Martinez Peck

Hi Pharaoers. I am pleased to announce the first Pharo 1.1 beta based on PharoCore-1.1-11367-Beta. It is the first time we build a Pharo 1.1 dev image with PharoCore 1.1 so the image may be not 100% stable. However, we think it is good to release it so that people can start to test it, load their own packages, adapt them, etc. We would like to receive feedback about it. It (yet) has failing and error tests. The main changes with Pharo 1.0 is that of course, it is based on a PharoCore 1.1 with all that it means. We started to write down some of the actions done in PharoCore 1.1. The list so far can be found here: http://code.google.com/p/pharo/wiki/ActionsInPharoOneDotOne Of course, for the stable releae of Pharo 1.1 we will do a clear list in the website as we did for 1.0. Regarding the included packages in 1.1 we added ScriptManager (a tool to manage and persist workspaces), ProfStefBrowser, ArchiveViewer, MethodWrappers and ObjectMetaTools (which includes things like ProtocolCatcher, ObjectTracer, ObjectViewer, etc). Another difference is the font. In Pharo 1.0 we used TrueType fonts by default. In Pharo 1.1 we use StrikeFonts (no need of TrueType plugin, netiher to have the fonts). However, of course, you can disable StrikeFonts and put TrueType like in 1.0. That's all. We would really appreciate you use it, test it, report issues, provide fixes, etc. It is important also that you start to use your own packages/applications. There have been several changes in 1.1 that may require change in your code. Ahh if you want to create the image yourself, check as usually the installScript.st file to see how to do it. Actually, you can just take a PharoCore-1.1-11367-Beta image and evaluate (the same procedure as 1.0): Gofer new squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfPharo'; load. ((Smalltalk at: #ConfigurationOfPharo) project version: '1.1-beta1.10517') load. Here is the link to the image: https://gforge.inria.fr/frs/download.php/27025/Pharo-1.1-11367-Betadev10.05… Cheers Mariano

May 20, 2010

Re: [Pharo-project] FFI Documentation

by StÃ©phane Ducasse

thanks sean this is cool to see such kind of documentation emerging. Stef On May 20, 2010, at 9:16 PM, Sean P. DeNigris wrote: > > I want to get this info into the help system and/or collaborative book, as > similar questions pop up regularly on the lists. > > I compiled every piece of info I could find. The focus in on FFI, with > stubs for other strategies. Please read this *very* rough outline for > missing info and inaccuracies: > > FFI > > What is FFI and what is it used for? Calling functions in libraries outside > of the image... > > FFI, the Squeak Foreign Function Interface, is used to call functions > located in shared libraries that are not part of the Squeak VM nor its > plugins. It also provides means to read and write memory structures that are > associated with the use of those shared libraries. A typical use is to > directly invoke operating system APIs. As such, applications that use FFI > can only be used on the platform(s) that support the particular API being > used. C conventions are used throughout, though the external function could > have been written by any language capable of generating object code that > follows C conventions. FFI is probably the easiest way to do the things it > does. FFI is pretty fast too. Croquet uses FFI calls to OpenGL for all it's > drawing routines.[1] > > How does FFI work? > Technically what happens is: > * you define what the interface is - the parameters, types etc. > * when you make the call, the FFI logic assembles the data from the Squeak > Objects into the proper structures according to the routine calling > conventions for your architecture, and of course manages the return values. > So no magic but perhaps just a little assembler in the plugin to properly > deal with all the registers and condition flags. > > How do I use it? > > 1. make a method (whose structure is similar to a named primitive method) > > Example: > system: aString "name (by convention is apiXxx: e.g. apiSystem:)" > > <apicall: long 'system' (char*) module: 'libSystem.dylib'> "first line > should be the external function specification" > ^self externalCallFailed. > > Let's take it piece by piece: > > system: aString > Method name - by convention named 'apiXxx' > > <apicall: long 'system' (char*) module: 'libSystem.dylib'> > Function specification > - should be the first line > - enclosed in angle brackets: < > containing: > 1. Calling Convention, either apicall: (Pascal convention) or cdecl: (C > convention) > - Mac - use either one > - Unix - use cdecl > - Windows - use apical > 2. Return Type (see types) > 3. External Function Name (literal string) > 4. Argument Types (a literal array) > 5. Module - "module: " + [filename of the external library (literal > string)] (see below). > > self externalCallFailed. > Failure handler > - normal smalltalk code > - executed if the linking to or calling the external function fails > - API calls don't know how to communicate failure like Squeak primitives > do, so: > - it does not tell you whether the external function succeeded > - the most common code is simply '^self externalCallFailed.' > > Argument Types > - must be names of ExternalTypes, either: > - atomic types (see ExternalType class>>initializeFFIConstants and > ExternalType class>>initializeAtomicTypes): > void > bool > byte (unsigned) > sbyte (signed) > ushort (16-bit unsigned) > short (16-bit signed) > ulong (32-bit unsigned) > long (32-bit signed) > ulonglong (64-bit unsigned) > longlong (64-bit signed) > char (unsigned) > schar (signed) > float (single-precision float) > double (double-precision float) > > Structure Types [4] > - subclass of ExternalStructure > - class>>fields that returns an array of field descriptions (see below) > - Example: > fields > ^#((red 'byte')(green 'byte')(blue 'byte')) > - class>>initialize which includes "self defineFields" (which must be > called before using the class) > - refer to as MyExternalStructure* (to indicate that the argument or return > is a pointer to that structure) > > Field description [4] > - 2-element array (or three but that does something else, I'm not sure > what): > - first element is the field name > - second is the type > > Mac Memory Allocation Issues [4] (not sure about this) > > If you allocate external structures, those with memory outside the Squeak > process space, you may need to increase the amount of memory that is > reserved outside the object heap for such use. The Mac OS (9 and previous) > needs this, other platforms may be able to dynamically get more memory from > the OS. To see how much memory is currently reserved printIt 'Smalltalk > extraVMMemory'. To change it, execute 'Smalltalk extraVMMemory: > someNumberofBytes' Then save your image and quit. When you next start up, > the amount of memory you requested will be reserved. (JMM) Note the OSX > versions of the VM ignore extraVMMemory because the memory model for > OS-X/unix applications is quite different. > > Module Name > - depends on the platform > - Mac > - pre Snow Leopard: flexible, can eliminate leading lib or extension e.g. > 'libc.dylib' becomes 'libc', 'c.dylib', or 'c' > - Snow Leopard > - file name must be exact including extension (unless Info.plist is > altered as in 'Library Location' below) > - With pre-mach-o VMs > - For Classic applications, use 'InterfaceLib' > - For Carbon libs, use 'CarbonLib' > > Module Location - where the external library file lives > - depends on the platform > - Mac > - pre Snow Leopard > - checks VM path and common library paths > - Snow Leopard > - only looks in VM bundle's Resources file, you must either [5]: > - store all external libraries there > - ln -s path/to/library path/to/VM/Resources/library_name > - Change the VM's Info.plist "SqueakPluginsBuiltInOrLocalOnly" key from > "true" to "false." > Caveats > - security > - malicious users could call arbitrary functions in the OS e.g. "format > c:" from "system.dll" [7] > - VMs do not protect against buffer overflow from bad parameters [8]: > "this would require an attacker to execute arbitrary Smalltalk > code on your server. Of course if they can do that they own you > anyway, especially if you allow FFi or use the OSProcess plugin" - John > McIntosh > > * difficulty > - if you make a mistake you'll not drop into the debugger but Squeak will > just crash [2] > - If you crash Squeak when it is running the garbage collector, then you > know your FFI code is leaking bits into object memory [2] > > What do I need to use FFI with Squeak? > > You need the FFI plugin, which is included with most VM's as of Squeak 3.6 > or so. > > You can also build the plugin yourself. See VMMaker. > > References: > [1] http://wiki.squeak.org/squeak/1414 > [2] http://wiki.squeak.org/squeak/2424 > [3] http://wiki.squeak.org/squeak/5716 > [4] http://wiki.squeak.org/squeak/2426 > [5] > http://forum.world.st/squeak-dev-Alien-Squeak-FFI-issues-on-Snow-Leopard-td… > [6] http://wiki.squeak.org/squeak/5846 > [7] http://forum.world.st/FFI-Callbacks-td54056.html#a54073 > [8] http://forum.world.st/Security-td99624.html#a99635: > > Other choices: > In the fall of 2008, Alien the FFI interface (written by Cadence Design > Systems, Inc.) was put into squeaksource: > http://www.squeaksource.com/Alien.html. This API allows the primitive to > call back to Smalltalk Code, and return error code information, and > apparently is much faster due to a less complex call sequence. > * if you need callbacks > * mac-only? > > Plugins - write external code and dynamically link it to the VM > Pros: > * safest - users are limited to using the functionality you provide and > can not call other external functions e.g. system rm / > * fast - faster than FFI > * you can create new functionality that doesn't exist in any library > Cons: > * harder to write > * plugin must be distributed with the Smalltalk code - there can be > complications with platforms > > Primitive method - invokes behavior in the VM or a plugin [3] > > Questions: > * why would you want to build the FFI plugin yourself? > * api prefix or no for method names? > * not sure about pre Snow Leopard library search > * OSProcess - how does this fit into the bigger picture? > * "^self externalCallFailed." or "self externalCallFailed." i.e. return self > or return the result, or doesn't matter? > * why would a field description have three elements? > * Mac Memory Allocation Issues? > -- > View this message in context: http://forum.world.st/FFI-Documentation-tp2225148p2225148.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2010

[Pharo-project] Fwd: [squeak-dev] Finalization enhancement for 4.2

by StÃ©phane Ducasse

igor I have a question about your new finalization. Can we add it to Pharo? Should we replace something else (I mean it is something to replace an existing solution). How does it interact with existing code? You see I will learn a lot again :) Stef > From: "David T. Lewis" <lewis(a)mail.msen.com> > Date: May 20, 2010 5:59:07 PM GMT+02:00 > To: ma.chris.m(a)gmail.com, The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > Cc: vm-dev(a)lists.squeakfoundation.org > Subject: Re: [squeak-dev] Finalization enhancement for 4.2 > Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org> > > CC to vm-dev list, follow up on technical issues should go to vm-dev. > > Chris, Igor, this sounds very encouraging. Yes, I'll help on the > VM side, with guidance from Andreas and others (I am not technically > competent on this issue). I'll probably be off list for a few days, > but will catch up on this next week. > > Andreas, Eliot, others - any advice or guidance? > > Dave > > On Thu, May 20, 2010 at 10:14:00AM -0500, Chris Muller wrote: >> I have packaged up Igor's change-sets for the finalization fix: >> >> http://bugs.squeak.org/view.php?id=7525 >> http://bugs.squeak.org/view.php?id=7473 >> >> into their respective MC packages and uploaded them to the Inbox. >> >> Recall the original discussion: >> >> http://lists.squeakfoundation.org/pipermail/vm-dev/2010-March/003958.html >> >> I have been running with Igor's enhanced VM and image-side >> finalization patches for a few weeks now. The results are striking. >> Squeak applications using large Weak-collections deteriorate to a >> point of unusability without this fix because Squeak spends 95% of its >> time in the finalization process, leaving no time for application >> processing. With this fix installed, CPU utilization is 0% when the >> application is idle, providing excellent responsiveness. >> >> This is a big, big, win for any application that uses Weak >> collections, and a win for Squeak overall because it's own use of >> weak-collections is enhanced. >> >> While it seems to be backward compatible, e.g. I am able to run the >> enhanced VM on older images (including 3.9), and I am able to run with >> these image changes on an older VM, both are required to take >> advantage of the enhanced finalization. >> >> I would like to push this into the trunk, but will need help from the >> VMMaker developers for that piece. David? >> >> For Magma, this wil be the most exciting and important fix since >> #becomeForward:copyHash: introduced back in 2004. >> >> - Chris >

May 20, 2010

[Pharo-project] FFI Documentation

by Sean P. DeNigris

I want to get this info into the help system and/or collaborative book, as similar questions pop up regularly on the lists. I compiled every piece of info I could find. The focus in on FFI, with stubs for other strategies. Please read this *very* rough outline for missing info and inaccuracies: FFI What is FFI and what is it used for? Calling functions in libraries outside of the image... FFI, the Squeak Foreign Function Interface, is used to call functions located in shared libraries that are not part of the Squeak VM nor its plugins. It also provides means to read and write memory structures that are associated with the use of those shared libraries. A typical use is to directly invoke operating system APIs. As such, applications that use FFI can only be used on the platform(s) that support the particular API being used. C conventions are used throughout, though the external function could have been written by any language capable of generating object code that follows C conventions. FFI is probably the easiest way to do the things it does. FFI is pretty fast too. Croquet uses FFI calls to OpenGL for all it's drawing routines.[1] How does FFI work? Technically what happens is: * you define what the interface is - the parameters, types etc. * when you make the call, the FFI logic assembles the data from the Squeak Objects into the proper structures according to the routine calling conventions for your architecture, and of course manages the return values. So no magic but perhaps just a little assembler in the plugin to properly deal with all the registers and condition flags. How do I use it? 1. make a method (whose structure is similar to a named primitive method) Example: system: aString "name (by convention is apiXxx: e.g. apiSystem:)" <apicall: long 'system' (char*) module: 'libSystem.dylib'> "first line should be the external function specification" ^self externalCallFailed. Let's take it piece by piece: system: aString Method name - by convention named 'apiXxx' <apicall: long 'system' (char*) module: 'libSystem.dylib'> Function specification - should be the first line - enclosed in angle brackets: < > containing: 1. Calling Convention, either apicall: (Pascal convention) or cdecl: (C convention) - Mac - use either one - Unix - use cdecl - Windows - use apical 2. Return Type (see types) 3. External Function Name (literal string) 4. Argument Types (a literal array) 5. Module - "module: " + [filename of the external library (literal string)] (see below). self externalCallFailed. Failure handler - normal smalltalk code - executed if the linking to or calling the external function fails - API calls don't know how to communicate failure like Squeak primitives do, so: - it does not tell you whether the external function succeeded - the most common code is simply '^self externalCallFailed.' Argument Types - must be names of ExternalTypes, either: - atomic types (see ExternalType class>>initializeFFIConstants and ExternalType class>>initializeAtomicTypes): void bool byte (unsigned) sbyte (signed) ushort (16-bit unsigned) short (16-bit signed) ulong (32-bit unsigned) long (32-bit signed) ulonglong (64-bit unsigned) longlong (64-bit signed) char (unsigned) schar (signed) float (single-precision float) double (double-precision float) Structure Types [4] - subclass of ExternalStructure - class>>fields that returns an array of field descriptions (see below) - Example: fields ^#((red 'byte')(green 'byte')(blue 'byte')) - class>>initialize which includes "self defineFields" (which must be called before using the class) - refer to as MyExternalStructure* (to indicate that the argument or return is a pointer to that structure) Field description [4] - 2-element array (or three but that does something else, I'm not sure what): - first element is the field name - second is the type Mac Memory Allocation Issues [4] (not sure about this) If you allocate external structures, those with memory outside the Squeak process space, you may need to increase the amount of memory that is reserved outside the object heap for such use. The Mac OS (9 and previous) needs this, other platforms may be able to dynamically get more memory from the OS. To see how much memory is currently reserved printIt 'Smalltalk extraVMMemory'. To change it, execute 'Smalltalk extraVMMemory: someNumberofBytes' Then save your image and quit. When you next start up, the amount of memory you requested will be reserved. (JMM) Note the OSX versions of the VM ignore extraVMMemory because the memory model for OS-X/unix applications is quite different. Module Name - depends on the platform - Mac - pre Snow Leopard: flexible, can eliminate leading lib or extension e.g. 'libc.dylib' becomes 'libc', 'c.dylib', or 'c' - Snow Leopard - file name must be exact including extension (unless Info.plist is altered as in 'Library Location' below) - With pre-mach-o VMs - For Classic applications, use 'InterfaceLib' - For Carbon libs, use 'CarbonLib' Module Location - where the external library file lives - depends on the platform - Mac - pre Snow Leopard - checks VM path and common library paths - Snow Leopard - only looks in VM bundle's Resources file, you must either [5]: - store all external libraries there - ln -s path/to/library path/to/VM/Resources/library_name - Change the VM's Info.plist "SqueakPluginsBuiltInOrLocalOnly" key from "true" to "false." Caveats - security - malicious users could call arbitrary functions in the OS e.g. "format c:" from "system.dll" [7] - VMs do not protect against buffer overflow from bad parameters [8]: "this would require an attacker to execute arbitrary Smalltalk code on your server. Of course if they can do that they own you anyway, especially if you allow FFi or use the OSProcess plugin" - John McIntosh * difficulty - if you make a mistake you'll not drop into the debugger but Squeak will just crash [2] - If you crash Squeak when it is running the garbage collector, then you know your FFI code is leaking bits into object memory [2] What do I need to use FFI with Squeak? You need the FFI plugin, which is included with most VM's as of Squeak 3.6 or so. You can also build the plugin yourself. See VMMaker. References: [1] http://wiki.squeak.org/squeak/1414 [2] http://wiki.squeak.org/squeak/2424 [3] http://wiki.squeak.org/squeak/5716 [4] http://wiki.squeak.org/squeak/2426 [5] http://forum.world.st/squeak-dev-Alien-Squeak-FFI-issues-on-Snow-Leopard-td… [6] http://wiki.squeak.org/squeak/5846 [7] http://forum.world.st/FFI-Callbacks-td54056.html#a54073 [8] http://forum.world.st/Security-td99624.html#a99635: Other choices: In the fall of 2008, Alien the FFI interface (written by Cadence Design Systems, Inc.) was put into squeaksource: http://www.squeaksource.com/Alien.html. This API allows the primitive to call back to Smalltalk Code, and return error code information, and apparently is much faster due to a less complex call sequence. * if you need callbacks * mac-only? Plugins - write external code and dynamically link it to the VM Pros: * safest - users are limited to using the functionality you provide and can not call other external functions e.g. system rm / * fast - faster than FFI * you can create new functionality that doesn't exist in any library Cons: * harder to write * plugin must be distributed with the Smalltalk code - there can be complications with platforms Primitive method - invokes behavior in the VM or a plugin [3] Questions: * why would you want to build the FFI plugin yourself? * api prefix or no for method names? * not sure about pre Snow Leopard library search * OSProcess - how does this fit into the bigger picture? * "^self externalCallFailed." or "self externalCallFailed." i.e. return self or return the result, or doesn't matter? * why would a field description have three elements? * Mac Memory Allocation Issues? -- View this message in context: http://forum.world.st/FFI-Documentation-tp2225148p2225148.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

Re: [Pharo-project] Need your opinion: What is most appealing form for GL function bindings?

by Henrik Sperre Johansen

On 20.05.2010 17:47, Igor Stasenko wrote: > There are multiple GL bindings exists by now > - one that used by Croquet (FFI) > - another one that using Alien > > and i doing one more, which using NativeBoost for callouts. > > And the question, what form of selectors you like most, > pros/cons .. i need to know, because i can pick any of them, > but i hope, that i will not be only one who using this stuff, so i > need your opinion. > > Lets take a usual OpenGL function: > > void glVertex3f(GLfloat x, GLfloat y, GLfloat z) > For me, 3 + 6 seems the nicest, for the reasons you mentioned. (method names starting in lower case though, so gl vertex3f_x: x y: y z: z). Cheers, Henry PS. That particular method was deprecated in 3.0 and removed in 3.1 though, right? ;)

May 20, 2010

Re: [Pharo-project] Need your opinion: What is most appealing form for GL function bindings?

by Henrik Sperre Johansen

On 20.05.2010 19:42, Schwab,Wilhelm K wrote: > Sig, > > Since you are focusing on the name of the selector, can I conclude that you are using the selector name to make the call? I am not sure I like that (strongly suspect I do not). Dolphin and FFI use a pragma(-ish??) syntax with the return type, function name and argument types explicitly listed. I very much would like to see you handle the details of getting things on and off of the stack, but I would like to control the selector name and the types. > > As an example, calling something > > waveletTransformForward:comma:comma: > > is not nearly as helpful to me as > > waveletTransformForward:size:flag: > > The selector can be even more informative than that, but hopefully it starts to make the case for the independent selector. > > Bill No, but he is automatically generating the interface from a spec file, thus some standard for how to convert it to a selector is needed. If he's using the NB FFI convention we discussed some time ago, the only "magic" is that the arg names are used in the apiCall specification. Example copy-pasted from the announcement of that functionality: primGetModuleFileName: hModule with: lpFileName with: nSize <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout apiCall: #( DWORD GetModuleFileName ( HMODULE hModule, LPTSTR lpFilename, DWORD nSize)) module: #Kernel32 options: #( - coerceNilToNull ) Cheers, Henry

May 20, 2010

[Pharo-project] MetaSource demo app working again

by Torsten Bergmann

>I had fixed this and made a new ConfigurationOf, but I don't have write >access to the EWB repo, so they are both here: Hi Sean, The confusion came mostly from the fact that you also "rehosted" the config itself instead of just the code package. It should be no problem when you put the ExternalBrowser code package into another repo until you can copy it to the original repo. But the ConfigurationOfXXX should be continued on squeaksource/MetacelloRepository which is read/write. So the configuration can point to the temporary location until the package moves to the original one - but others can still use the newer versions in ConfigurationOfXXX since they dont care where the loaded packages are hosted... Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 20, 2010

Re: [Pharo-project] Fwd: [Pharo-users] Flushing the VM method cache?

by Eliot Miranda

On Thu, May 20, 2010 at 11:13 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > Hi Joachim, > > the Behavior>>flushCache method, primitive 89, flushes the entire > cache, so its all you need. There are alternative primitives that flush > selectively, i.e. Symbol>>flushCache, primitive 119, and > CompiledMethod>>flushCache, primitive 116, flush only entries for the > receivers. > And the VM does selectively flush the cache on GC anyway, so you shouldn't have to do anything. > > HTH > Eliot > > On Thu, May 20, 2010 at 10:52 AM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> wrote: > >> >> >> Begin forwarded message: >> >> > From: Joachim Geidel <joachim.geidel(a)onlinehome.de> >> > Date: May 20, 2010 6:31:51 PM GMT+02:00 >> > To: <pharo-users(a)lists.gforge.inria.fr> >> > Subject: [Pharo-users] Flushing the VM method cache? >> > Reply-To: A friendly place where any question about pharo is welcome < >> pharo-users(a)lists.gforge.inria.fr> >> > >> > Hello all, >> > >> > The software I am working on generates classes on the fly, and discards >> > those classes when they are no longer needed. The class library is >> > cross-platform, i.e. it exists for Dolphin and VisualWorks, and I am >> > currently porting it to Pharo. >> > >> > In Dolphin, it is necessary to flush the VM's method cache after >> discarding >> > all the dynamically generated classes, because the method cache holds >> > references to the classes which prevent them from being garbage >> collected. >> > For VisualWorks, I have adopted this, although I am not quite sure if >> it's >> > actually needed there. >> > >> > In the Pharo 1.0 image, I haven't found a method for flushing the VM's >> > method cache in one go, there only seems to be Behavior>>flushCache. >> > >> > What I would like to know is: >> > - Does the VM method cache of the Squeak VM hold references to classes >> which >> > prevent an obsolete class from being garbage collected? If this is not >> the >> > case, I don't need to flush anything. >> > - If flushing the cache is advisable, is Behavior>>flushCache the only >> way >> > to do this? I would have to pick up all the obsolete classes and iterate >> > over them in that case. >> > >> > Thanks in advance! >> > Joachim Geidel >> > >> > >> > >> > _______________________________________________ >> > Pharo-users mailing list >> > Pharo-users(a)lists.gforge.inria.fr >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-users >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >

May 20, 2010