- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Native Boost Basics: passing char* buffer

by Igor Stasenko

On 1 January 2013 09:39, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > testPharoBuffer > "self new testPharoBuffer " > | buf addr addr2 | > buf := String new: 100000. > addr := buf asNBExternalString. > addr2 := ( NativeBoost allocate: 256 ). > self testPharoBuffer: addr . " or use addr2, both of it does not > work" > Transcript cr; show: buf. > > > have tried "addr readString" / on addr2 .. too > > Need to understand how to pass a memory location to the dll function stack > and get back what is written to the memory in Pharo in a more general sense. > > Hmm.. Did you changed the signature? self nbCall: #( int readAndWritePipe( void * buf ) ) module: 'TestPharo.dll' So, if this a String (a variable-byte object) , a function will receive a pointer to its first byte, and if its address (NBExternalAddress) then a pointer passed to function will be equal to that address. > > On Tue, Jan 1, 2013 at 12:13 PM, S Krish <krishnamachari.sudhakar(a)gmail.com> > wrote: >> >> I am trying to work with memory addresses back n forth.. >> >> Simple case of char* buffer that needs to be filled in by dll . Buffer >> does not change in Pharo after the call. Am I missing something here.. >> >> The memory address that is printed out does not match what I see in Pharo >> / infact the address does not change at all... for repeated call invoked >> from debugger. >> >> C Code: >> >> DLLEXPORT int readAndWritePipe(char* outBuf ) >> { >> system("Echo readAndWritePipe" ); >> debugPrintf ( "readAndWritePipe: %d \n" , &outBuf , 1046 ); >> memcpy ( outBuf , "Testing123\0" , 11) ; >> return 0; >> } >> >> void debugPrintf ( char* logString, int intArg , char* strArg, int size ) >> { // can redirect as needed to logger end point.. >> FILE * logFile = fopen( "c:\\temp\\writePipes.log" , "a" ); >> char* buf = (char*) calloc( sizeof(char) , size ); >> sprintf( buf, logString , intArg , strArg ); >> fputs(buf , logFile ); >> fclose(logFile); >> } >> >> Pharo: >> >> testPharoBuffer: buf >> >> <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: >> errorCode > >> ^ self nbCall: #( int readAndWritePipe( String buf ) ) module: >> 'TestPharo.dll' >> >> >> testPharoBuffer >> "self new testPharoBuffer " >> | buf addr addr2 | >> buf := String new: 100000. >> addr := buf asNBExternalString. >> addr2 := ( NativeBoost allocate: 256 ). >> self testPharoBuffer: addr . " or use addr2, both of it does not >> work" >> Transcript cr; show: buf. >> > > -- Best regards, Igor Stasenko.

Jan. 1, 2013

Re: [Pharo-project] Native Boost Basics: passing char* buffer

by S Krish

Thanks, char* and void* works like a charm...

Jan. 1, 2013

Re: [Pharo-project] Native Boost Basics: passing char* buffer

by S Krish

testPharoBuffer "self new testPharoBuffer " | buf addr addr2 | buf := String new: 100000. addr := buf asNBExternalString. addr2 := ( NativeBoost allocate: 256 ). self testPharoBuffer: addr . " or use addr2, both of it does not work" Transcript cr; show: buf. have tried "addr readString" / on addr2 .. too Need to understand how to pass a memory location to the dll function stack and get back what is written to the memory in Pharo in a more general sense. On Tue, Jan 1, 2013 at 12:13 PM, S Krish <krishnamachari.sudhakar(a)gmail.com>wrote: > I am trying to work with memory addresses back n forth.. > > Simple case of char* buffer that needs to be filled in by dll . Buffer > does not change in Pharo after the call. Am I missing something here.. > > The memory address that is printed out does not match what I see in Pharo > / infact the address does not change at all... for repeated call invoked > from debugger. > > C Code: > > DLLEXPORT int readAndWritePipe(char* outBuf ) > { > system("Echo readAndWritePipe" ); > debugPrintf ( "readAndWritePipe: %d \n" , &outBuf , 1046 ); > memcpy ( outBuf , "Testing123\0" , 11) ; > return 0; > } > > void debugPrintf ( char* logString, int intArg , char* strArg, int size ) > { // can redirect as needed to logger end point.. > FILE * logFile = fopen( "c:\\temp\\writePipes.log" , "a" ); > char* buf = (char*) calloc( sizeof(char) , size ); > sprintf( buf, logString , intArg , strArg ); > fputs(buf , logFile ); > fclose(logFile); > } > > Pharo: > > testPharoBuffer: buf > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode > > ^ self nbCall: #( int readAndWritePipe( String buf ) ) module: > 'TestPharo.dll' > > > testPharoBuffer > "self new testPharoBuffer " > | buf addr addr2 | > buf := String new: 100000. > addr := buf asNBExternalString. > addr2 := ( NativeBoost allocate: 256 ). > self testPharoBuffer: addr . " or use addr2, both of it does not > work" > Transcript cr; show: buf. > >

Jan. 1, 2013

Re: [Pharo-project] Native Boost Basics: passing char* buffer

by Igor Stasenko

On 1 January 2013 07:43, S Krish <krishnamachari.sudhakar(a)gmail.com> wrote: > I am trying to work with memory addresses back n forth.. > > Simple case of char* buffer that needs to be filled in by dll . Buffer does > not change in Pharo after the call. Am I missing something here.. > > The memory address that is printed out does not match what I see in Pharo / > infact the address does not change at all... for repeated call invoked from > debugger. > > C Code: > > DLLEXPORT int readAndWritePipe(char* outBuf ) > { > system("Echo readAndWritePipe" ); > debugPrintf ( "readAndWritePipe: %d \n" , &outBuf , 1046 ); > memcpy ( outBuf , "Testing123\0" , 11) ; > return 0; > } > are you sure you want to print an address of argument (&outBuf) instead of argument value (outBuf - which is a pointer value passed to function) ? Because &outBuf, will always be a location on stack where the value stored. And sure thing, when you call that function from simple short test app, it will be always same, since nothing interferes with stack. > void debugPrintf ( char* logString, int intArg , char* strArg, int size ) > { // can redirect as needed to logger end point.. > FILE * logFile = fopen( "c:\\temp\\writePipes.log" , "a" ); > char* buf = (char*) calloc( sizeof(char) , size ); > sprintf( buf, logString , intArg , strArg ); > fputs(buf , logFile ); > fclose(logFile); > } > > Pharo: > > testPharoBuffer: buf > > <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: > errorCode > > ^ self nbCall: #( int readAndWritePipe( String buf ) ) module: > 'TestPharo.dll' > > > testPharoBuffer > "self new testPharoBuffer " > | buf addr addr2 | > buf := String new: 100000. > addr := buf asNBExternalString. > addr2 := ( NativeBoost allocate: 256 ). > self testPharoBuffer: addr . " or use addr2, both of it does not > work" > Transcript cr; show: buf. > String type in signature makes a copy of string on stack + adds null-terminating character, and then pushing the pointer on stack as argument to function. So, it is more like 'pass by value-copy' argument. If you want to do 'pass by reference', just use 'void *' (or char* ) in function signature, but then make sure you null-terminate stuff there by yourself, if needed. String type converter is more for convenience to avoid dealing with null-terminating chars every time. But sure thing, if you need to pass a pointer to buffer, where function will store something ,you should not use it. -- Best regards, Igor Stasenko.

Jan. 1, 2013

[Pharo-project] Native Boost Basics: passing char* buffer

by S Krish

I am trying to work with memory addresses back n forth.. Simple case of char* buffer that needs to be filled in by dll . Buffer does not change in Pharo after the call. Am I missing something here.. The memory address that is printed out does not match what I see in Pharo / infact the address does not change at all... for repeated call invoked from debugger. C Code: DLLEXPORT int readAndWritePipe(char* outBuf ) { system("Echo readAndWritePipe" ); debugPrintf ( "readAndWritePipe: %d \n" , &outBuf , 1046 ); memcpy ( outBuf , "Testing123\0" , 11) ; return 0; } void debugPrintf ( char* logString, int intArg , char* strArg, int size ) { // can redirect as needed to logger end point.. FILE * logFile = fopen( "c:\\temp\\writePipes.log" , "a" ); char* buf = (char*) calloc( sizeof(char) , size ); sprintf( buf, logString , intArg , strArg ); fputs(buf , logFile ); fclose(logFile); } Pharo: testPharoBuffer: buf <primitive: #primitiveNativeCall module: #NativeBoostPlugin error: errorCode > ^ self nbCall: #( int readAndWritePipe( String buf ) ) module: 'TestPharo.dll' testPharoBuffer "self new testPharoBuffer " | buf addr addr2 | buf := String new: 100000. addr := buf asNBExternalString. addr2 := ( NativeBoost allocate: 256 ). self testPharoBuffer: addr . " or use addr2, both of it does not work" Transcript cr; show: buf.

Jan. 1, 2013

Re: [Pharo-project] Happy new year, to all of you!!!

by S Krish

All, Happy Smalltalking all the way through the new year and the decade ahead. All the best in every way, prosperity is most important that can enable more smalltalk, a virtuous cycle of give and take in the year ahead. On Tue, Jan 1, 2013 at 5:38 AM, Alexandre Bergel <alexandre.bergel(a)me.com>wrote: > I wish you a Happy Phaoring for 2013! > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > >

Jan. 1, 2013

[Pharo-project] Happy new year, to all of you!!!

by Alexandre Bergel

I wish you a Happy Phaoring for 2013! Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Jan. 1, 2013

Re: [Pharo-project] About RBMethodModifierFinalRule

by Max Leske

We use it in Pharo 1.1.1 and 1.4. But we can put it back in as a custom rule if we need to. Max On 30.12.2012, at 21:03, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi guys > > rationale > ^ 'Checks that a methods marked with <modifier: #final> is never overridden.' > > my impression is that we can safely remove this rule. We never used this pragma for this convention. > Isn't it :) > > Stef

Dec. 31, 2012

Re: [Pharo-project] About RBLiteralArrayContainsCommaRule

by StÃ©phane Ducasse

Ok :) for now I kept it. And I'm creating an unused category to group the rules that we do not follow. I hope soon that we will develop some good rules to drive our development. Stef On Dec 30, 2012, at 9:05 PM, Peter Hugosson-Miller wrote: > Possibly it's useful as a warning to one who comes from a C-syntax language, and might accidentally define a literal array containing some. For example, #(1, 2, 3) - not an error, but not (as the perpetrator might believe) an array containing three integers ;) > -- > Cheers, > Peter. > > On 30 dec 2012, at 20:48, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi >> >> I'm going over all the SmallLint rule and extending their rationale and fixing sometimes their default check. >> Now I'm reading >> >> RBLiteralArrayContainsCommaRule >> >> rationale >> ^ 'Checks for literal arrays that contain the #, symbol.' >> >> and I have no idea why this would be a problem. >> >> Anybody has an idea? >> >> Stef >> >> >

Dec. 30, 2012

[Pharo-project] [update 2.0] #20463

by StÃ©phane Ducasse

20463 ----- - Issue 7190: MC core model depends on UI !! http://code.google.com/p/pharo/issues/detail?id=7190 - Issue 7195: SmallLint Rules better description and cleaning http://code.google.com/p/pharo/issues/detail?id=7195 - Issue 7198: MCVersionLoader http://code.google.com/p/pharo/issues/detail?id=7198 Diff information: http://ss3.gemstone.com/ss/Pharo20/System-Tools-StephaneDucasse.93.diff http://ss3.gemstone.com/ss/Pharo20/Refactoring-Critics-StephaneDucasse.28.d… http://ss3.gemstone.com/ss/Pharo20/Monticello-StephaneDucasse.740.diff http://ss3.gemstone.com/ss/Pharo20/Metacello-MC-StephaneDucasse.666.diff http://ss3.gemstone.com/ss/Pharo20/Manifest-Core-StephaneDucasse.99.diff http://ss3.gemstone.com/ss/Pharo20/Gofer-Core-StephaneDucasse.190.diff

Dec. 30, 2012