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

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

by Igor Stasenko

On 20 May 2010 21:50, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > Â 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 ) > Right, you are free to change it to anything you like. But it would be unwise to poke manually with more than 2500 functions (i listed the numbers earlier), so there is an automated process which generating code for them. Here is how generated method looks like: glDrawArraysInstancedARB: mode first: first count: count primcount: primcount "This method was automatically generated from OpenGL specs" "See http://squeaksource.com/OpenGLSpecs for details" <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self glApiCall: #( void glDrawArraysInstancedARB ( GLenum mode , long first , GLsizei count , GLsizei primcount ) ) attributes: #( #alias 'DrawArraysInstanced' #category #'ARB_draw_instanced' #version #'2.0' ) As you may see, in addition to function prototype 'void glTbufferMask3DFX ( GLuint mask )' it contains an additional meta-information, which could be userful to diagnose problem, if call fails. And as an example, how you can change it, here it is: choosePixelFormat <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ NBFFICallout stdcall: #( int ChoosePixelFormat ( HDC dc , GLPixelFormatDescriptor pixelFormat )) module: #gdi32 as you can see, this method doesn't taking any arguments, while function expects 2. Still its a working implementation. A dc and pixelFormat is an instance variables of method's receiver, and NBFFICallout knows how to deal with it. > Cheers, > Henry > > > > _______________________________________________ > 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.

May 20, 2010

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

by Igor Stasenko

Dear all, I will make a better implementation at image side, and cover everything with comments, as Eliot suggested. On 20 May 2010 22:23, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > igor > > I have a question about your new finalization. Can we add it to Pharo? yes, you can. But without VM modifications it won't work. That's why i postponed image-side integration for a better time(s). Old images, how Chris already mentioned, don't need to be aware of changes on VM side and will continue to function as if nothing happen. > Should we replace something else (I mean it is something to replace an existing solution). Well, it works best if you having a lot of weak refs, while only few of them dying time to time. You are free to implement a post-mortem action however you like (but this is also true for current implementation, except that new scheme is much more effective). > How does it interact with existing code? I will replace an existing WeakRegistry, which will work exactly as an old one. Also, if you want, i can add a fallback mechanism, if you will run your image using older VM. Any other uses of new finalization is up to you :) As you may guess, a Magma exploits new finalization enhancement for own needs. For this, I implemented a specialized weak dictionaries, which clean themselves automatically (Magma don't needs to deal with finalization of objects, it just needs to keep buffers free of garbage). This was a real-world use of new features, which shown us its benefits. Thanks to Cris for taking care integrating and testing it. > 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 >> > > > _______________________________________________ > 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.

May 20, 2010

[Pharo-project] Where to host Help packages?

by Mariano Martinez Peck

Hi Torsten. It is not clear for me where Help packages should be hosted. For example, ScriptManager host its own Help package in its own repository. But Metacello is in the HelpSystem repository. So....where should I host them ? or what is the convention? in their own repositories or in HelpSystem ? Cheers Mariano

May 20, 2010

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

by Mariano Martinez Peck

On Thu, May 20, 2010 at 10:25 PM, Torsten Bergmann <astares(a)gmx.de> wrote: > Maybe you should include "Pharo-Project-Help" MCZ package > from squeaksource.com/HelpSystem into the ConfigurationOfPharo. > > While the core image only has the basic help support and only > one topic ("Help on Help) the dev image would then have some basic > infos on Pharo itself as well as the browsable API for Pharo > accessible from the help browser (if this is loaded). > > Thanks Torsten. I wasn't aware of such package. So..for next release I will add a project reference from ConfigurationOfPharo to ConfigurationOfHelpSystem loading the default group (that includes core, help and system). Now, the problem is that I already have Help-Core and tests in PharoCore...so will it override them? which version should I use? the one from the core of the one of the metacello configuration ? > Do we have a ghostwriter who wants to help on this package? > > I don't know. For me it is difficult to have so many places to write: Pharo By Example volume 2, Collaborative book, Help System....how do we concentrate efforts? where should I write each thing ? I think we should make this a bit more clear. Cheers Mariano > Thx > T. > > -- > GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! > Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 > > _______________________________________________ > 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 Sean P. DeNigris

Yanni Chiu wrote: > > It's really up to each project to make it easy/hard to accept > contributions. I don't see what outsiders could do to change that, other > than to ask to become an insider. > Ah, now I see what you're saying. I actually agree. My idea is to encourage and default to w/r, not impose it. I assume that many projects are read-only, not because of a desire of the maintainer, but just because that's the default in SqS. Why not default to r/w, making life easier for the community, and admins can select read-only if they want. Yanni Chiu wrote: > > An idea comes to mind though. Maybe a "maintenance" group could be > created. Members of the maintenance group would have write permissions > to all projects. They would only submit code to make things work on > different platforms, but would not wildly re-factor, change the design, > add features, etc. That way, the admin/dev's would still maintain > "control" of their project, but get help from the maintenance crew. > Sounds interesting. Sean -- View this message in context: http://forum.world.st/Community-Development-a-suggestion-tp2224670p2225365.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 20, 2010

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

by Yanni Chiu

Sean P. DeNigris wrote: > > Yanni Chiu wrote: >> I don't think using global write is the right way to fix the problem. >> > Why not? What is the concrete negative scenario that it creates? It takes away the admin's responsibility to administer. The admin can enable global write, if they chose. If global write is imposed, then the admin may feel less responsible for what is happening to the project. Why have an admin role at all, if everything is world writable? > Yanni Chiu wrote: >> 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. It's really up to each project to make it easy/hard to accept contributions. I don't see what outsiders could do to change that, other than to ask to become an insider. An idea comes to mind though. Maybe a "maintenance" group could be created. Members of the maintenance group would have write permissions to all projects. They would only submit code to make things work on different platforms, but would not wildly re-factor, change the design, add features, etc. That way, the admin/dev's would still maintain "control" of their project, but get help from the maintenance crew. > 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 That seems like a reasonable idea.

May 20, 2010

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

by Torsten Bergmann

Maybe you should include "Pharo-Project-Help" MCZ package from squeaksource.com/HelpSystem into the ConfigurationOfPharo. While the core image only has the basic help support and only one topic ("Help on Help) the dev image would then have some basic infos on Pharo itself as well as the browsable API for Pharo accessible from the help browser (if this is loaded). Do we have a ghostwriter who wants to help on this package? 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

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