May 2010 - Pharo-dev - lists.pharo.org

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

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

by Eliot Miranda

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

Re: [Pharo-project] Community Development (a suggestion)

by StÃ©phane Ducasse

> > Has anybody out there experienced problems with r/w repos that caused them > to change to read-only? That would make a case for caution. I got student publishing other versions and this was not optimal. I think that it would be good to garbage collect squeaksource somehow. Stef >> How about a SqS usage policy: >> - the project admin(s) are responsible for keeping their email contact >> up-to date >> - periodically (monthly?), project admins are ping'ed. If no >> acknowledgement is received after three attempts, then the project admin >> reverts to the community >> - any community member can then ask to become the project admin >> > > I like this as an addition, but it doesn't solve the primary issue of making > it easy for people to contribute. I know that currently, every time I go > through the process of contacting someone to apply changes, I think, "this > is too hard." I'm sure that many fixes out there are lost because of the > private development model. > > How about this: > * As you suggest above: projects revert to community after x time > * there is an inbox-like place for every project (or one for all external > projects), where community contributions can go. This way, the latest code > is always available, and it is separate from the owners code > > Sean > -- > View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2224980.… > 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

Re: [Pharo-project] Remove developing with Pharo

by StÃ©phane Ducasse

Thanks a lot! > I created a chapter called "Remote Development" under the "Tips and Tricks" chapter. > Here is the link: http://book.pharo-project.org/book/TipsAndTricks/RemoteDevelopment/?_s=q1YO… > > > 2010/5/16 Mariano Martinez Peck <marianopeck(a)gmail.com> > Andrei: Once you have finished to make it work and how to tune it to make it faster, it would be great if you can write this in a section/chaper of the collaborative pharo book: http://book.pharo-project.org/ > > If you want I can creat you a user, and the section...then you only need to write ;) > > > cheers > > mariano > > 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> > Ok, I figured it out. > On the remote machine just start pharo with RFBServer started (connection passwords must be set!) > On the local Windows machine open ssh or putty tunneling local port 5900 to the remote port 5900 (putty -L 5900:localhost:5900 username(a)doman.com) > After that start a VNC client (in my case I installed TightVNC) and connect to your local machine. > That will automatically establish a tunneled traffic between those two systems va ssh tunneling. > > > 2010/5/14 Mariano Martinez Peck <marianopeck(a)gmail.com> > > I paste a text I got from an old mail: "The latest version on squeaksource works. You can load it from http://squeaksource.com/RFB (Note that this package has been forked at least three times.) We used to connect to the server with RealVNC with the following settings: ZRLE encoding (disable auto select), Full color. IIRC you should also turn off the "render cursor locally" feature. > On the server you should allow ZRLE and turn off the conserve memory feature. > " > > In addition, ask in seaside mailing list too. You will probably receive more help. > > Cheers > > Mariano > > > > 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com> > Exactly what VNC slient I can use on Windows? > I tried VNC viewer free (http://www.realvnc.com/products/free/4.1/winvncviewer.html) trying to connect to the locally run Pharo and the viewer fails with "uncknown rect encoding" after which Pharo image also freezes. > Is there any step-by-step tutorial how to setup VNC (remote Linux, local Windows)? > > > On Thu, May 13, 2010 at 6:26 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 2010/5/14 Andrei Stebakov <lispercat(a)gmail.com>: > > Interesting! Is it done on the X-server side or client? > > > you should have settings in your VNC client. > also, you could set bpp for image. > both could help to run things faster. > > > On Thu, May 13, 2010 at 5:38 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> > >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com>: > >> > That's right, looks like it sends full-blown images (not the delta, not > >> > the > >> > commands to x-server) and re-drawing takes forever. I wonder if it's a > >> > Pharo > >> > issue or x-server's? My xterm works pretty fast compared to Pharo > >> > though... > >> > > >> lowering the pixel depth to 8bpp helps :) > >> > >> > 2010/5/12 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > >> >> > >> >> I have at times done what you are attempting, and painful is nicest > >> >> adjective I can think to use. Please let us know if VNC is a better > >> >> option. Re RDP, I have wondered whether the poor performance could be > >> >> telling us something about the amount of drawing that might be > >> >> happening for > >> >> no purpose??? It can be terribly slow, especially the response to > >> >> typing. > >> >> Bill > >> >> > >> >> ________________________________ > >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr > >> >> [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > >> >> Mariano > >> >> Martinez Peck > >> >> Sent: Wednesday, May 12, 2010 10:25 AM > >> >> To: Pharo-project(a)lists.gforge.inria.fr > >> >> Subject: Re: [Pharo-project] Remove developing with Pharo > >> >> > >> >> > >> >> > >> >> 2010/5/12 Andrei Stebakov <lispercat(a)gmail.com> > >> >>> > >> >>> Currently I have my web applications running on a Ubuntu box to which > >> >>> I > >> >>> connect from a remote WinXP system via ssh. > >> >> > >> >> I guess the subject should be "remote" instead of "remove" ? ;) > >> >> > >> >> Sorry I ask but why not you cannot just develop in your pc and with scp > >> >> or > >> >> similar you copy the .image and .image file trough ssh to the server ? > >> >> > >> >>> > >> >>> My current set of tools is Lisp/Slime/Emacs. > >> >>> I tried to launch Pharo with X11 forwarding using X-server on WinXP, > >> >>> but > >> >>> it painfully slow (the Pharo main windows redraws in a few minutes). > >> >>> I am really thinking developing some web app using Pharo/Seaside (I am > >> >>> liking the language more and more!) but I need to know to do it > >> >>> remotely via > >> >>> a secure connection. > >> >> > >> >> > >> >> Yes, there is an implementation of the VNC protocolol. You can take a > >> >> Pharo image and load a VNC server. Then, you can connect to any VNC > >> >> client > >> >> and what you see is the image....Then you can do whatever you want. I > >> >> don't > >> >> know the performance, thus. > >> >> > >> >> That package is called RFB (remote something buffer) > >> >> > >> >> http://book.seaside.st/book/advanced/deployment/maintaining/vnc > >> >> > >> >> To install it: > >> >> > >> >> Gofer it > >> >> squeaksource: 'MetacelloRepository'; > >> >> package: 'ConfigurationOfRFB'; > >> >> load. > >> >> ((Smalltalk at: #ConfigurationOfRFB) project perform: #latestVersion) > >> >> load. > >> >> > >> >> > >> >> Cheers > >> >> > >> >> Mariano > >> >> > >> >> > >> >>> > >> >>> Thank you, > >> >>> Andrei > >> >>> > >> >>> _______________________________________________ > >> >>> 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 > >> > > >> > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > >> _______________________________________________ > >> 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 > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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 > > > _______________________________________________ > 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

May 20, 2010