- Pharo-dev - lists.pharo.org

[Pharo-project] [NativeBoost] not happy with too many references to NBFFICallout & its public API
by Igor Stasenko Nov. 28, 2012

Nov. 28, 2012

Hi, i am thinking about redesign of FFI top-level api, because it not very good. First thing is that NBFFICallout referenced in too many places (187 in my image). So, from one side, we should encourage using a convenience syntax, using self nbCall: .. instead of NBFFICallout ... but there's one more thing: - a code generator has many different ways of use, and i actually going to add another one, but i see that it will explode the protocol(s) without make it convenient to use. Imagine that you want to generate a callout to function, which address cannot be obtained directly from external library. This is actually a real issue, which Esteban met when implementing bindings to Chipmunk library: - some functions are not exposed directly by dynamic library, but indirectly: the symbol(s) which library exports is not direct pointer(s) to functions but instead a pointers to variable, where the function pointer is stored. So, in order to get function pointer , one needs first to get a pointer to symbol, and then read the pointer value at that address. So, i thought that i would simply add new protocol to NBFFICallout: call: anonFunctionSignature convention: callConvention functionAddress: aFunctionAddressBlock Then, one could use it like: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ NBFFICallout call: #( int () ) convention: #cdecl functionAddress: [ self getPointerTo: 'functionname' ] but it is too elaborate.. you can imagine that if one would like to implement a more convenient form, he could just do: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self indirectCall: #( int () ) name: 'functionname' or even: myMethod <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self indirectCall: #( int functionname () ) now the problem is that you cannot wrap the NBFFICallout method in order to implement convenience method, because of use of thisContext. I also concerned about exploding NBFFICallout public API.. which imo doesn't makes much sense, because we should encourage the use of convenience methods. So, i looking for improving public API: - First thing is getting rid of direct references to NBFFICallout.. - second thing is avoid tying public API with thisContext (so you can create own convenience methods without much hassle). So, lets imagine what and how we can do it: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ NBFFICallout cdecl: #( int foo() ) module: 'bar' 1. getting rid of global: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout cdecl: #( int foo() ) module: 'bar' 2. separating the call convention from signature: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout cdecl call: #( int foo() ) module: 'bar' 3. as a bonus, since cdecl is most used, we can assume it is default: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout call: #( int foo() ) module: 'bar' 4. avoid hardcoding module: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout call: #( int foo() ) module: self module 5. pass code generation options as a separate message, instead of additional keyword: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self nbCallout options: #( +optFoo - optBar); call: #( int foo() ) module: self module 6. finally users would want to do it in most convenient way: foo <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> ^ self call: #( int foo() ) Which means that #call: is convenience method which they implement by themselves. Here how i think it should look like: call: fnSpec ^ (self nbCalloutIn: thisContext sender) cdecl; options: #(+optFoo - optBar); call: fnSpec module: self module. If you look at current implementation of Object>>nbCall: nbCall: fnSpec " you can override this method if you need to" | sender | sender := thisContext sender. ^ NBFFICallout handleFailureIn: sender nativeCode: [ :gen | gen sender: sender; callType: self nbCallingConvention; generateCall: fnSpec module: self nbLibraryNameOrHandle] it is almost the same, except from cryptic use of blocks, and private internal NBFFICallout methods which doing the job. So, basicly, i want to get rid of NBFFICallout class >> [cdecl/stdcall]: module: [options:] [cdecl/stdcall]: emitCall: [options:] and replace them with #call:module: and #call: emit: and also add new one: #call:address: which can be used for passing a function pointer directly. And any future extensions to public API will be a single method. Not 2,3 or more, like today.. -- Best regards, Igor Stasenko.

4 13

[Pharo-project] monticello not tracking recategorization
by Camillo Bruni Nov. 28, 2012

Nov. 28, 2012

currently monticello does not track method recategorization! anybody has a direct hint where to look at? in the mean time I start a binary search on the images to figure out when we introduced the bug...

2 1

[Pharo-project] a probably stupid question on canvas
by StÃ©phane Ducasse Nov. 28, 2012

Nov. 28, 2012

Hi guys I was wondering why we need a separate class named AlphaBlendingCanvas Igor can you have a look and depending on your answer I will put it on my todo list. Stef ?

2 4

[Pharo-project] who are "cipt" and "tbh"?
by Esteban Lorenzano Nov. 28, 2012

Nov. 28, 2012

Hi, Can I ask people to use real names instead name initials? Otherwise I get lost about who pushes changes :) Esteban

2 1

[Pharo-project] [ANN] NativeBoost v 1.7
by Igor Stasenko Nov. 28, 2012

Nov. 28, 2012

Hi, there i'd like to announce new version of NativeBoost - 1.7. Here's an overview of changes comparing to previous version: - indirect argument in signatures. You can now use special syntax to indicate that argument to external function should be taken from n-th element of variable object (like Array) from method's argument or instance variable. Syntax: myMethod: args <primitive: .... > ^ self nbCall: #( void funFoo( int args@1 , float args@2 )) Usage: self myMethod: { 1 . 1.2 } Thanks to Ciprian Teodorov who proposed and implemented it. - Win32, features and examples: NBWin32Shell - an interface to use windows shell api (executing commands, showing control panel settings) different examples for using HDC, message box etc. Thanks to Torsten Bergmann for contribution! And last bits, from me: A public API changes to avoid use of NBFFICallout global, and instead use message(s) to denote FFI callout. Old syntax: NBFFICallout cdecl: #(...) emitCall: [ â¦ ] New syntax: self nbCallout function: #(â¦) emit: [â¦] Old syntax: NBFFICallout cdecl: #(...) module: .. New syntax: self nbCallout cdecl function: #(â¦) module: â¦ or: self nbCallout function: #(â¦) module: â¦ because cdecl is default Old syntax: NBFFICallout cdecl: #(...) module: .. options: #(â¦) New syntax: self nbCallout cdecl; options: #(â¦); function: #(â¦) module: â¦ Old syntax: NBFFICallout stdcall: #(...) module: .. options: #(â¦) New syntax: self nbCallout stdcall; options: #(â¦); function: #(â¦) module: â¦ ---- New API and syntax: self nbCallout function: <signature> address: [ address block ] generate code for calling a function located at given address with given signature. The address of function is provided by user in address block, which should return a pointer to the function (NBExternalAddress or Unsigned integer value, representing an absolute address of function). This API is useful, when you need to call some function which is not exported by via DLL symbol directly, but indirectly. The old NBFFICallout API is still there, but use of it is strongly discouraged. And it will be removed eventually. So be warned! :) -- Best regards, Igor Stasenko.

4 8

[Pharo-project] mess in package extensions
by Pavel Krivanek Nov. 28, 2012

Nov. 28, 2012

Hi, we have got some problems with package extensions and merging of them during updates. This problems became evident in this issues: - http://code.google.com/p/pharo/issues/detail?id=6956 - http://code.google.com/p/pharo/issues/detail?id=7036 In the first one we several times tired to move the methods to the correct package. At the end we tried to remove them in a fixing slice but how can you see in the latest image, this methods are still there. This methods cause 5 of 6 test failures in the Pharo Kernel (the last one is the Undeclared test with 5 undeclared classes) In the second issue the Form class methods are in the correct method category but as you may see in the Monticello browser, they are not in the Graphics-Files package. The Pharo Kernel shrinking removes packages with respect to method category and doesn't take an opinion of Monticello into account. So this methods are (correctly) removed during shrinking. But because they are not part of the Graphics-Files package by Monticello, they are not correctly loaded with the rest of the Morphic and thus the Jenkins job "Pharo Kernel 2.0 Reload by Monticello" is failing. Cheers, -- Pavel

2 2

[Pharo-project] almost ready for 2.0 beta
by Esteban Lorenzano Nov. 28, 2012

Nov. 28, 2012

Hi, I've been working last days to put pharo 2.0 ready to beta. So far we have just two missing integrations: - NativeBoost - Key Chain we deferred Opal to first cycle of next year release (february), because is not ready for inclusion yet. So. we will be on beta as soon as Igor and Ben give me the proper version for their inclusion :) Esteban

1 0

[Pharo-project] [update 2.0] #20421
by Marcus Denker Nov. 28, 2012

Nov. 28, 2012

20421 ----- Issue 7060: New Spec version http://code.google.com/p/pharo/issues/detail?id=7060 Issue 7054: InputEventHandler unregistering should nil the eventFetcher http://code.google.com/p/pharo/issues/detail?id=7054 Issue 7041: remove theme UIThemeStandardSqueak http://code.google.com/p/pharo/issues/detail?id=7041 Issue 7036: move Form class>>#fromFileNamed and fromBinaryStream to Graphic-Files http://code.google.com/p/pharo/issues/detail?id=7036 Issue 7031: Package HistoryCollection should be merged into Nautilus http://code.google.com/p/pharo/issues/detail?id=7031 Diff information: http://ss3.gemstone.com/ss/Pharo20/Spec-Core-MarcusDenker.66.diff http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-MarcusDenker.739.diff http://ss3.gemstone.com/ss/Pharo20/Nautilus-MarcusDenker.380.diff http://ss3.gemstone.com/ss/Pharo20/Kernel-MarcusDenker.1259.diff http://ss3.gemstone.com/ss/Pharo20/HistoryCollection-MarcusDenker.16.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Files-MarcusDenker.37.diff http://ss3.gemstone.com/ss/Pharo20/Graphics-Display Objects-MarcusDenker.98.diff -- Marcus Denker -- denker(a)acm.org http://www.marcusdenker.de

1 0

Nov. 27, 2012

Hi guys now with this change set the behavior when selected a piece of code is the same with smart char than the default behavior. aaaa + ' -> 'aaaa' 'aaaa' + ' -> aaaaa Stef

1 0

[Pharo-project] just help :)
by Sebastian Nozzi Nov. 27, 2012

Nov. 27, 2012

> 2012/11/25 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > just help :) This is what I would like to get involved in. Hopefully it can benefit the project. In order of personal interest: == 1) Positioning Pharo as THE language to learn programming. With a "fun" touch. Smalltalk is still an excellent language/environment to learn programming and I think: if it can be learnt while having fun, the better! My idea is to write simple game-programming tutorials (board games, puzzles, etc. like this - http://inventwithpython.com/ - but cooler). I already started working on this, that's why I bugged you guys with Morphic questions in the past. What I would like to offer is the knowledge and tools to use Pharo as a post-Scratch (http://scratch.mit.edu/) for creative projects (games, animations, stories, etc.). Conceptually similar to: http://www.greenfoot.org/home - only it would be it would be Smalltalk based ;-D. I also would love to write educational software (disclaimer: I'm not a school teacher or anything similar - although I imagine getting involved in the area). >From the spirit I know that maybe Squeak is more the place to go... And also that Pharo aims to be more enterprise/research oriented. I don't discard my code running in Squeak, but I just happen to find Pharo easier to use / develop in. == 2) Writing small (but attractive/useful) sample apps ... to be useful for people/small companies and get devs hooked (return-on-investment might be low?). Examples: a TestLink clone, a time-tracker, a corporate contact-database, a room reservation system, etc. The idea is to use these apps as "troyan horses", and get devs interested in Smalltalk/Pharo (the apps would be free and open-source, to guarantee usage/adoption). Maybe to extend / customize them for their needs. Increase mind-share (I assure you, it's needed! None of my past/current colleagues knew what Smalltalk was, some confused it with Lisp). But I'm sure this won't happen without... == 3) Writing (documenting) Pharo >From an "enterprise" point of view (how can I do X, because I need this for a real-life project asap?). I think there is a lot of work to be done here also. Documenting classes, working on external documentation. Like how to interact with OS processes/io, databases, deployment strategies, persistence strategies, how to work in a team, etc. For this I would like to collaborate in the "collaborative book". I already have a list of things that could be added/improved, and I think I would also learn a lot in the process. The only thing that worries me is me not being a native English speaker (writer). == Some work involved in these areas overlap. Ideally I would combine all three. So, these are the areas I would like to get involved in. It would be great if it could benefit the project at large :-) Best regards, Sebastian

3 2