January 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] NativeBoost design and deployment

by Ciprian Teodorov

Just my 2 cents on this: I don't think pragma is a good idea. It breaks the nice everything is a message ... plus the reason given by Igor. I think pragma is just a way to work around some other *limitations* we have. We should better work on those. If not for the problem at hand maybe we can use the compiled method directly, instead of keeping names around Cheers, Ciprian On Jan 9, 2013 10:25 AM, "Igor Stasenko" <siguctua(a)gmail.com> wrote: > On 9 January 2013 09:10, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 8 January 2013 19:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> > >> > >> > >> On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >>> > >>> On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: > >>> > When one deploys an image one usually requires ONLY > >>> > the image - not the source or changes file. An "image locker" > >>> > code would look like this: > >>> > > >>> > SmalltalkImage checkSourcesFileAvailability: false. > >>> > SmalltalkImage checkChangesFileAvailability: false > >>> > > >>> > do disable acording warnings when source/changefile is removed. > >>> > > >>> > If one uses NativeBoost in such a deployment scenario, for > >>> > instance the > >>> > > >>> > NBWin32Shell shellBrowse: 'http://www.google.de' > >>> > > >>> > functionality the internal code (due to missing source) now > >>> > looks like this > >>> > > >>> > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 > >>> > <primitive: 'primitiveNativeCall' module: > 'NativeBoostPlugin'> > >>> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > >>> > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, > #LPCTSTR > >>> > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' > >>> > > >>> > Hence the t1 ... t5 parameters. > >>> > > >>> > NativeBoost is in this situation not able to match the > >>> > FFI parameters and throws an error "Could not find accessor for > variable > >>> > ..." > >>> > > >>> > Try yourself without a changes and source file. This makes > >>> > NativeBoost not very deployment friendly and unusable in > >>> > such a "minimal deployment" scenario ... > >>> > > >>> > Any comments? > >>> > > >>> > >>> yes it needs sources (indirectly) to bind method's argument names > >>> during code generation. > >>> To avoid that, i can imagine that one must modify a compiler to detect > >>> if compiled method > >>> primitive requires arg names, and store them in method properties. > >>> Like that later code generator can use them without need to access the > >>> source code. > >> > >> > >> Indeed. If a pragma were used then the whole thing could look a lot > nicer, > >> not be dependent on source, and include support for an error code. e.g. > >> > >> shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > >> lpDirectory show: nShowCmd > >> > >> <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > #lpOperation #, > >> #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, > #INT > >> #nShowCmd ) ) > >> module: 'Shell32.dll' > >> errorCode: ec> > >> > >> ^self nbCallFailedWith: ec > >> > >> It's pretty trivial to add such pragma compilers to the compiler. > There is > >> an example for the FFI. It also frees one to use a nicer syntax, e.g. > >> > >> shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > >> lpDirectory show: nShowCmd > >> <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, > LPCTSTR > >> lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' > >> module: 'Shell32.dll' > >> errorCode: ec> > >> > >> ^self nbCallFailedWith: ec > >> > > > > i do not see how encoding function signature in pragma could help with > > binding argument names. > > Yes, you need to get some control at compile time to be able to encode > > method arg names somewhere in method properties for later use.. but > > not at cost of moving everything into pragma. > > > > And 'nice' syntax is actually already there .. nothing prevents you > > from using strings for function signature, e.g. > > > > self nbCall: 'int foo()' > > equivalent to > > self nbCall: #(int foo() ) > > > > (i don't know why Torsten gave code in such form, that could leave an > > impression that syntax is horrible ;) > > ah, yes.. it is because he shows decompiled method source. > The original source code looks much better: > > shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: lpDirectory show: nShowCmd > <primitive: #primitiveNativeCall module: > #NativeBoostPlugin> > > ^ self nbCall: #( > HINSTANCE ShellExecuteA( > 0, > LPCTSTR lpOperation, > LPCTSTR lpFile, > LPCTSTR lpParameters, > LPCTSTR lpDirectory, > INT nShowCmd)) module: 'Shell32.dll' > > > > > > And besides, how you suppose to "pragmatize" following: > > > > storeDouble: aDouble at: address > > " This method stores a double floating point value at given > memory address. > > an address can be an instance of NBExternalAddress, or > > simple ByteArray with at least 8 bytes long, which will hold a > 64bit > > floating-point value" > > > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' > error: errorCode> > > > > ^ self nbCallout > > options: #( > > - optCoerceNilToNull > > + optAllowByteArraysPtr > > + optAllowExternalAddressPtr > > ); > > function: #( void (void * address, double aDouble) ) > > emit: [:gen | | asm | > > asm := gen asm. > > > > "Here , we expecting that an address value is on > top of the stack" > > asm > > pop: EDX; "load an address value into > EDX register by popping it > > from a stack" > > > > "now copy the floating point value > (which is 8-bytes long) to the > > given address" > > mov: ESP ptr to: EAX; > > mov: EAX to: EDX ptr; " store first > 32bit part of 64bit double value" > > > > mov: ESP ptr + 4 to: EAX; > > mov: EAX to: EDX ptr + 4. " store > second 32bit part of 64bit double value" > > > > ] > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > -- > Best regards, > Igor Stasenko. > >

Jan. 9, 2013

Re: [Pharo-project] FileSystem inconsistency

by StÃ©phane Ducasse

On Jan 9, 2013, at 6:05 AM, Jimmie Houchin wrote: > Thanks for all the suggestions for easier way to create references. > > Part of the problem is that I did not sufficiently read the documentation in the class comment. I also did not know of the PBE2 chapter referenced by Stef. > > Part of the problem is also that the browser in 2.0 is presenting things differently and I am not sure I understand fully what it is communicating. We will improve it soon. > > When I look at the class methods in FileSystem most of them are gray and a only few black. It is not self evident what the gray coloration means. Also when one clicks on instance creation, the only method is #store:. So unless you see the class comment, then you won't see the documentation on using FileSystem disk workingDirectory which returns a FileSystemDirectoryEntry instance, while FileSystem disk returns a FileSystem instance. > > I should have investigated documentation a little harder. > > Jimmie > > On 1/8/2013 11:01 AM, Esteban Lorenzano wrote: >> anyway, even if there are easier ways to create references, I think Jimmie is right, there are inconsistencies in the protocol. >> maybe for 3.0? >> >> On Jan 8, 2013, at 5:58 PM, Camillo Bruni <camillobruni(a)gmail.com> wrote: >>> On 2013-01-08, at 17:55, Max Leske <maxleske(a)gmail.com> wrote: >>>> On 08.01.2013, at 17:07, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>>>> Hello, >>>>> >>>>> I was writing a small utility using FileSystem. I had never used FileSystem before. So I am browsing the code trying to learn where to start and how to use it. >>>>> >>>>> It took me a little while to learn to do something like: >>>>> fs := FileSystem store: (DiskStore activeClass createDefault). >>>> Why not >>>> >>>> fs := FileSystem disk. >>>> >>>> ?? >>>> >>>> or: >>>> >>>> reference := FileSystem disk referenceTo: '/foo/bar.txt'. >>> or: >>> >>> '/foo/bar/plonk.txt' asFileReference >>> '/foo/bar' asFileReference >>> >>> which creates a FileReference on the disk, the default >

Jan. 9, 2013

Re: [Pharo-project] Smalllint for Traits

by StÃ©phane Ducasse

Thanks We will have a look and integrate your smallLint rules. Stef On Jan 9, 2013, at 2:04 AM, aizcorbe wrote: > Hi all, as part of a thesis I have been working on, I extended Smalllint to > let it check Traits and Traits specific errors. > > The enviroment objects and the refactoring scope browsers now handles and > list classes and traits (before they just handled classes). The new > refactoring scope selection is available at "refactoring scope>selection > all behaviors" menu option. > > The smalllint framework have been extended and is available at > "refactor>code critics extended". > These are some of the changes: > smalllint rules can now check traits and traits methods. > a new rule presentation schema is available, which lets to spot the place > where the error is actually located and also add extra information to the > rule result (but is more difficult to define the rules in this way). > > For extra information about the changes and how can they be used you can > refer to: > > http://dc.uba.ar/inv/tesis/licenciatura/2012/aizcorbe.pdf (refer to chapter > 4 if you want to bypass all the conceptual background ) > > there was also added some rules to check Traits specific errors. > > The Smalllint for Traits extension is available for pharo 1.3 and is located > in: > > http://www.squeaksource.com/TesisTraitLint > > the packages are organized as follows: > > OBLintTraitExtension.1.3 (the smalltalk environment extension to add Traits > handling capabilities). > TraitLint.1.3 (the Smalllint extension itself and the Traits > rules implementation). > TraitLintTest.1.3 (the unit tests for the Smalllint extension and > the rules implementation, it is not mandatory). > > I hope you find this useful. > cheers > > > > -- > View this message in context: http://forum.world.st/Smalllint-for-Traits-tp4662559.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

Jan. 9, 2013

[Pharo-project] jenkins slave disk space

by Camillo Bruni

our pharo-linux64 bit slave is down due to disk space limitations. this is mainly caused by the ~6GB android SDK ;) which takes around the same space as the whole workspace under /builds Solutions: ========== a) condense the android sdk b) create a slave with a bigger disk

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 9 January 2013 09:10, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 January 2013 19:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> >> On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> >>> On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: >>> > When one deploys an image one usually requires ONLY >>> > the image - not the source or changes file. An "image locker" >>> > code would look like this: >>> > >>> > SmalltalkImage checkSourcesFileAvailability: false. >>> > SmalltalkImage checkChangesFileAvailability: false >>> > >>> > do disable acording warnings when source/changefile is removed. >>> > >>> > If one uses NativeBoost in such a deployment scenario, for >>> > instance the >>> > >>> > NBWin32Shell shellBrowse: 'http://www.google.de' >>> > >>> > functionality the internal code (due to missing source) now >>> > looks like this >>> > >>> > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 >>> > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >>> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR >>> > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR >>> > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' >>> > >>> > Hence the t1 ... t5 parameters. >>> > >>> > NativeBoost is in this situation not able to match the >>> > FFI parameters and throws an error "Could not find accessor for variable >>> > ..." >>> > >>> > Try yourself without a changes and source file. This makes >>> > NativeBoost not very deployment friendly and unusable in >>> > such a "minimal deployment" scenario ... >>> > >>> > Any comments? >>> > >>> >>> yes it needs sources (indirectly) to bind method's argument names >>> during code generation. >>> To avoid that, i can imagine that one must modify a compiler to detect >>> if compiled method >>> primitive requires arg names, and store them in method properties. >>> Like that later code generator can use them without need to access the >>> source code. >> >> >> Indeed. If a pragma were used then the whole thing could look a lot nicer, >> not be dependent on source, and include support for an error code. e.g. >> >> shellExecute: lpOperation file: lpFile parameters: lpParameters directory: >> lpDirectory show: nShowCmd >> >> <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, >> #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT >> #nShowCmd ) ) >> module: 'Shell32.dll' >> errorCode: ec> >> >> ^self nbCallFailedWith: ec >> >> It's pretty trivial to add such pragma compilers to the compiler. There is >> an example for the FFI. It also frees one to use a nicer syntax, e.g. >> >> shellExecute: lpOperation file: lpFile parameters: lpParameters directory: >> lpDirectory show: nShowCmd >> <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR >> lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' >> module: 'Shell32.dll' >> errorCode: ec> >> >> ^self nbCallFailedWith: ec >> > > i do not see how encoding function signature in pragma could help with > binding argument names. > Yes, you need to get some control at compile time to be able to encode > method arg names somewhere in method properties for later use.. but > not at cost of moving everything into pragma. > > And 'nice' syntax is actually already there .. nothing prevents you > from using strings for function signature, e.g. > > self nbCall: 'int foo()' > equivalent to > self nbCall: #(int foo() ) > > (i don't know why Torsten gave code in such form, that could leave an > impression that syntax is horrible ;) ah, yes.. it is because he shows decompiled method source. The original source code looks much better: shellExecute: lpOperation file: lpFile parameters: lpParameters directory: lpDirectory show: nShowCmd <primitive: #primitiveNativeCall module: #NativeBoostPlugin> ^ self nbCall: #( HINSTANCE ShellExecuteA( 0, LPCTSTR lpOperation, LPCTSTR lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)) module: 'Shell32.dll' > > And besides, how you suppose to "pragmatize" following: > > storeDouble: aDouble at: address > " This method stores a double floating point value at given memory address. > an address can be an instance of NBExternalAddress, or > simple ByteArray with at least 8 bytes long, which will hold a 64bit > floating-point value" > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: errorCode> > > ^ self nbCallout > options: #( > - optCoerceNilToNull > + optAllowByteArraysPtr > + optAllowExternalAddressPtr > ); > function: #( void (void * address, double aDouble) ) > emit: [:gen | | asm | > asm := gen asm. > > "Here , we expecting that an address value is on top of the stack" > asm > pop: EDX; "load an address value into EDX register by popping it > from a stack" > > "now copy the floating point value (which is 8-bytes long) to the > given address" > mov: ESP ptr to: EAX; > mov: EAX to: EDX ptr; " store first 32bit part of 64bit double value" > > mov: ESP ptr + 4 to: EAX; > mov: EAX to: EDX ptr + 4. " store second 32bit part of 64bit double value" > > ] > > > > > -- > Best regards, > Igor Stasenko. -- Best regards, Igor Stasenko.

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 9 January 2013 09:39, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > > > The issue is not limited to only pragma as the route, it can the > CompiledMethod extension or any. Eventually stripping source/ disconnecting > the sources / changes file is an expectation.... > > Otherwise can there be an easy way of truncated changes / sources file of > the NativeBoost part alone read only that can allow the functionality as is. > > Bar this part of the code I am sure all the rest can be a pragma, so may > need to figure that out..how this may fit in compile / parse . > Potentially you could move things to pragmas, but at cost of increased complexity and losing flexibility. Putting things into pragmas will heavily dictate how you should organize your code, and will lead to canonization of interface, which will be very hard to change later (if you need that). Original FFI implementation is a good example of that, where the syntax of <cdecl: ..> are not compatible with common pragma syntax. And the problem is , that once choice was done (no matter how good or bad it is), now it is really hard to change it. But then imagine, how you could turn this to pragmas: ^ self nbCall: self signature module: self module options: self options or this: ^ self nbCallout function: #( int foo()) address: [ self getMyFunctionAddress ] The only thing you need right now is to capture arg names, so indeed, we need a pragma to indicate an intent, something like: <captureArgNames> ^ self nbCall: self signature module: self module options: self options But as i said before, i don't want to hack compiler right now, i postpone changes for Opal. Then you will be able to write something like that: shellExecute: lpOperation file: y parameters: z directory: w show: v <nativeCall> ^ self nbCall: .... module: 'Shell32.dll' the rest will be handled under the hood (including things like working without source code). -- Best regards, Igor Stasenko.

Jan. 9, 2013

[Pharo-project] [Update] Zinc-SSO OAuth 1.0 & OpenID Alpha Code & Live Demos

by Sven Van Caekenberghe

Hi, Here is another update regarding the Zinc-SSO project. http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072658.h… Jan has been porting his earlier CloudforkSSO work to Zinc-SSO so that we now have support for both OAuth1 and OpenID. Both are considerably more complex than OAuth2 that was implemented earlier. The codebase was cleaned up a bit and more test/demo code was added. Some basic documentation and loading instructions can be found at https://github.com/svenvc/docs/blob/master/zinc/zinc-sso-paper.md Basically you should be able to get all the bits (preferably in Pharo 2.0) by doing (ConfigurationOfZincHTTPComponents project version: '2.2') load: 'SSO' This is not a subject where loading some code gives you a working demo since there is some setup to be done. Therefor we orginanized two live demos: http://sso.stfx.eu http://sso.doit.st There is now support for Google, Microsoft, Facebook, Twitter & Yahoo. The second demo is slight more extensive: it even allows you to do Twitter posts ! Although the code is not yet production quality, we could use some feedback from early adopters to help use shake out remaining problems. Jan & Sven PS: We would like to thank Andy Burnett of Knowinnovation Inc and ESUG for sponsoring this open source work. -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by S Krish

The issue is not limited to only pragma as the route, it can the CompiledMethod extension or any. Eventually stripping source/ disconnecting the sources / changes file is an expectation.... Otherwise can there be an easy way of truncated changes / sources file of the NativeBoost part alone read only that can allow the functionality as is. Bar this part of the code I am sure all the rest can be a pragma, so may need to figure that out..how this may fit in compile / parse . ******************* [ :gen | | asm | asm := gen asm. "Here , we expecting that an address value is on top of the stack" asm pop: EDX; "load an address value into EDX register by popping it from a stack" "now copy the floating point value (which is 8-bytes long) to the given address" mov: ESP ptr to: EAX; mov: EAX to: EDX ptr; " store first 32bit part of 64bit double value" mov: ESP ptr + 4 to: EAX; mov: EAX to: EDX ptr + 4. " store second 32bit part of 64bit double value" ...] ******************* On Wed, Jan 9, 2013 at 1:40 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 8 January 2013 19:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: > >> > When one deploys an image one usually requires ONLY > >> > the image - not the source or changes file. An "image locker" > >> > code would look like this: > >> > > >> > SmalltalkImage checkSourcesFileAvailability: false. > >> > SmalltalkImage checkChangesFileAvailability: false > >> > > >> > do disable acording warnings when source/changefile is removed. > >> > > >> > If one uses NativeBoost in such a deployment scenario, for > >> > instance the > >> > > >> > NBWin32Shell shellBrowse: 'http://www.google.de' > >> > > >> > functionality the internal code (due to missing source) now > >> > looks like this > >> > > >> > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 > >> > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> > >> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > >> > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR > >> > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' > >> > > >> > Hence the t1 ... t5 parameters. > >> > > >> > NativeBoost is in this situation not able to match the > >> > FFI parameters and throws an error "Could not find accessor for > variable > >> > ..." > >> > > >> > Try yourself without a changes and source file. This makes > >> > NativeBoost not very deployment friendly and unusable in > >> > such a "minimal deployment" scenario ... > >> > > >> > Any comments? > >> > > >> > >> yes it needs sources (indirectly) to bind method's argument names > >> during code generation. > >> To avoid that, i can imagine that one must modify a compiler to detect > >> if compiled method > >> primitive requires arg names, and store them in method properties. > >> Like that later code generator can use them without need to access the > >> source code. > > > > > > Indeed. If a pragma were used then the whole thing could look a lot > nicer, > > not be dependent on source, and include support for an error code. e.g. > > > > shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > > lpDirectory show: nShowCmd > > > > <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR > #lpOperation #, > > #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, > #INT > > #nShowCmd ) ) > > module: 'Shell32.dll' > > errorCode: ec> > > > > ^self nbCallFailedWith: ec > > > > It's pretty trivial to add such pragma compilers to the compiler. There > is > > an example for the FFI. It also frees one to use a nicer syntax, e.g. > > > > shellExecute: lpOperation file: lpFile parameters: lpParameters > directory: > > lpDirectory show: nShowCmd > > <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR > > lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' > > module: 'Shell32.dll' > > errorCode: ec> > > > > ^self nbCallFailedWith: ec > > > > i do not see how encoding function signature in pragma could help with > binding argument names. > Yes, you need to get some control at compile time to be able to encode > method arg names somewhere in method properties for later use.. but > not at cost of moving everything into pragma. > > And 'nice' syntax is actually already there .. nothing prevents you > from using strings for function signature, e.g. > > self nbCall: 'int foo()' > equivalent to > self nbCall: #(int foo() ) > > (i don't know why Torsten gave code in such form, that could leave an > impression that syntax is horrible ;) > > And besides, how you suppose to "pragmatize" following: > > storeDouble: aDouble at: address > " This method stores a double floating point value at given memory > address. > an address can be an instance of NBExternalAddress, or > simple ByteArray with at least 8 bytes long, which will hold a > 64bit > floating-point value" > > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' > error: errorCode> > > ^ self nbCallout > options: #( > - optCoerceNilToNull > + optAllowByteArraysPtr > + optAllowExternalAddressPtr > ); > function: #( void (void * address, double aDouble) ) > emit: [:gen | | asm | > asm := gen asm. > > "Here , we expecting that an address value is on > top of the stack" > asm > pop: EDX; "load an address value into EDX > register by popping it > from a stack" > > "now copy the floating point value (which > is 8-bytes long) to the > given address" > mov: ESP ptr to: EAX; > mov: EAX to: EDX ptr; " store first 32bit > part of 64bit double value" > > mov: ESP ptr + 4 to: EAX; > mov: EAX to: EDX ptr + 4. " store second > 32bit part of 64bit double value" > > ] > > > > > -- > Best regards, > Igor Stasenko. > >

Jan. 9, 2013

Re: [Pharo-project] Smalllint for Traits

by Fernando Olivero

Cool work! It would be nice to have in the latest Pharo 2.0, so it can be integrated. Think about integrating it into SmallLint, if not, your nice work maybe will get lost. Saludos, Fernando On Wed, Jan 9, 2013 at 2:04 AM, aizcorbe <juansebastian.aizcorbe(a)gmail.com>wrote: > Hi all, as part of a thesis I have been working on, I extended Smalllint to > let it check Traits and Traits specific errors. > > The enviroment objects and the refactoring scope browsers now handles and > list classes and traits (before they just handled classes). The new > refactoring scope selection is available at "refactoring scope>selection > all behaviors" menu option. > > The smalllint framework have been extended and is available at > "refactor>code critics extended". > These are some of the changes: > smalllint rules can now check traits and traits methods. > a new rule presentation schema is available, which lets to spot the place > where the error is actually located and also add extra information to the > rule result (but is more difficult to define the rules in this way). > > For extra information about the changes and how can they be used you can > refer to: > > http://dc.uba.ar/inv/tesis/licenciatura/2012/aizcorbe.pdf (refer to > chapter > 4 if you want to bypass all the conceptual background ) > > there was also added some rules to check Traits specific errors. > > The Smalllint for Traits extension is available for pharo 1.3 and is > located > in: > > http://www.squeaksource.com/TesisTraitLint > > the packages are organized as follows: > > OBLintTraitExtension.1.3 (the smalltalk environment extension to add Traits > handling capabilities). > TraitLint.1.3 (the Smalllint extension itself and the > Traits > rules implementation). > TraitLintTest.1.3 (the unit tests for the Smalllint extension and > the rules implementation, it is not mandatory). > > I hope you find this useful. > cheers > > > > -- > View this message in context: > http://forum.world.st/Smalllint-for-Traits-tp4662559.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 9, 2013

Re: [Pharo-project] NativeBoost design and deployment

by Igor Stasenko

On 8 January 2013 19:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > On Fri, Jan 4, 2013 at 12:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 4 January 2013 08:54, Torsten Bergmann <astares(a)gmx.de> wrote: >> > When one deploys an image one usually requires ONLY >> > the image - not the source or changes file. An "image locker" >> > code would look like this: >> > >> > SmalltalkImage checkSourcesFileAvailability: false. >> > SmalltalkImage checkChangesFileAvailability: false >> > >> > do disable acording warnings when source/changefile is removed. >> > >> > If one uses NativeBoost in such a deployment scenario, for >> > instance the >> > >> > NBWin32Shell shellBrowse: 'http://www.google.de' >> > >> > functionality the internal code (due to missing source) now >> > looks like this >> > >> > shellExecute: t1 file: t2 parameters: t3 directory: t4 show: t5 >> > <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin'> >> > ^ self nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR >> > #lpOperation #, #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR >> > #lpDirectory #, #INT #nShowCmd ) ) module: 'Shell32.dll' >> > >> > Hence the t1 ... t5 parameters. >> > >> > NativeBoost is in this situation not able to match the >> > FFI parameters and throws an error "Could not find accessor for variable >> > ..." >> > >> > Try yourself without a changes and source file. This makes >> > NativeBoost not very deployment friendly and unusable in >> > such a "minimal deployment" scenario ... >> > >> > Any comments? >> > >> >> yes it needs sources (indirectly) to bind method's argument names >> during code generation. >> To avoid that, i can imagine that one must modify a compiler to detect >> if compiled method >> primitive requires arg names, and store them in method properties. >> Like that later code generator can use them without need to access the >> source code. > > > Indeed. If a pragma were used then the whole thing could look a lot nicer, > not be dependent on source, and include support for an error code. e.g. > > shellExecute: lpOperation file: lpFile parameters: lpParameters directory: > lpDirectory show: nShowCmd > > <nbCall: #(#HINSTANCE #ShellExecuteA #(0 #, #LPCTSTR #lpOperation #, > #LPCTSTR #lpFile #, #LPCTSTR #lpParameters #, #LPCTSTR #lpDirectory #, #INT > #nShowCmd ) ) > module: 'Shell32.dll' > errorCode: ec> > > ^self nbCallFailedWith: ec > > It's pretty trivial to add such pragma compilers to the compiler. There is > an example for the FFI. It also frees one to use a nicer syntax, e.g. > > shellExecute: lpOperation file: lpFile parameters: lpParameters directory: > lpDirectory show: nShowCmd > <nbCall: 'HINSTANCE ShellExecuteA(0, LPCTSTR lpOperation, LPCTSTR > lpFile, LPCTSTR lpParameters, LPCTSTR lpDirectory, INT nShowCmd)' > module: 'Shell32.dll' > errorCode: ec> > > ^self nbCallFailedWith: ec > i do not see how encoding function signature in pragma could help with binding argument names. Yes, you need to get some control at compile time to be able to encode method arg names somewhere in method properties for later use.. but not at cost of moving everything into pragma. And 'nice' syntax is actually already there .. nothing prevents you from using strings for function signature, e.g. self nbCall: 'int foo()' equivalent to self nbCall: #(int foo() ) (i don't know why Torsten gave code in such form, that could leave an impression that syntax is horrible ;) And besides, how you suppose to "pragmatize" following: storeDouble: aDouble at: address " This method stores a double floating point value at given memory address. an address can be an instance of NBExternalAddress, or simple ByteArray with at least 8 bytes long, which will hold a 64bit floating-point value" <primitive: 'primitiveNativeCall' module: 'NativeBoostPlugin' error: errorCode> ^ self nbCallout options: #( - optCoerceNilToNull + optAllowByteArraysPtr + optAllowExternalAddressPtr ); function: #( void (void * address, double aDouble) ) emit: [:gen | | asm | asm := gen asm. "Here , we expecting that an address value is on top of the stack" asm pop: EDX; "load an address value into EDX register by popping it from a stack" "now copy the floating point value (which is 8-bytes long) to the given address" mov: ESP ptr to: EAX; mov: EAX to: EDX ptr; " store first 32bit part of 64bit double value" mov: ESP ptr + 4 to: EAX; mov: EAX to: EDX ptr + 4. " store second 32bit part of 64bit double value" ] -- Best regards, Igor Stasenko.

Jan. 9, 2013