Re: [Pharo-users] spec 2 documentation

[ASAM]

I looked for the same one and even donated. But as far as I know there is no
book yet.

https://www.okpal.com/building-user-interfaces-with-spec/?utm_campaign=01DKKYM06QR7GF0K4S5YA3VVZ0&utm_medium=campaign_edit-okpuid_01DKKYKZ99J5VPEAKHNXH8375A-20190903&utm_source=share_directlink#/

-Joerg




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] FFI and absolute path to dll

[ASAM]

Hello, 
I'm using Pharo 8 64bit on Windows 10 64bit. 
I am trying to access a 32bit dll via a relative path.

I'm desperate. I've been reading the document
(http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) all the
time up and down but I can't find an example of absolute path and Windows.

If e.g. my.dll file would be stored here.

C:\Program Files (x86)\GALEP5\my.dll

then what should the method win32ModuleName return?

Another question came to me while reading the document.
It is actually important to know whether the DLL was generated as cdecl or
stdcall?
The dll i try to call use stdcall.

I would be very happy if someone helps me.
I can no longer see the message "External module not found" :-)

Thanks a lot!



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] FFI and absolute path to dll

[ASAM]

Thanks for the tips. It really helped me a lot. 
The dll is now loaded (I chose the 64-bit version of the dll).

I am currently working on value mashalling and I want to create an ENUM
class subclass from FFIEnumeration. 

Inside http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1  i
read chapter 4.4  Enumerations.
I tried the example.
For me, however, only new class variables are created after
"ExampleEnumeration initialize".

Is that okay? or a bug?

In Doc..."You will see that the enumeration class gets redefined as follows
creating and initializing a class variable for each of its elements."  but i
can't  see the  initializing.

Do I have a mistake in thinking?
Thanks for your help and time.











--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] FFI and absolute path to dll

[ASAM]

Oh. Thank you for your answers. Now that you say it, I remember it. I dealt
with Pharo 2 years ago. And now I  come back to load and execute a DLL with
Pharo.

Does anyone have a more detailed example of FFIOpaqueObjectis object than in
the book (http://books.pharo.org/booklet-uffi/pdf/2020-02-12-uFFI-V1.0.1) ? 
I don't really understand it yet.

I want to call a DLL whose API has 33 functions, 41 structures and 15 enums. 
I would like to do it right and I have to understand everything first so
that I can then decide how to implement it.

Thank you for your help





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] FFI and absolute path to dll

[ASAM]

Of course there is a documentation for the API. 
It is even an ISO standard. And if I can do that, I would also like to make
it available on GitHub. That's why it should be good.

It is the ISO 22900-2 D-PDU-API.
I can also attach the header file. However, the PDF is provided with a
watermark. So please google.

The API is provided by different manufacturers.

The process is roughly the following, for Windows systems read a resitre key
that says where the root.xml is. On Linux the pdu_api_root.xml is under
/etc.

In the root.xml you can find where the individual suppliers have installed
their dll. With the absolute path you can now load the dll. 

Under Linux it would be a so-file which I have never seen live. I would say
95% use it only under windos.

Thanks for help.

ISO22900_2.h   




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] UFFI counterpart to "C iterate over a arry through a pointer"

[ASAM]

Hello, I'm looking for help with the following problem.
I try to get closer from the C point of view to the problem.

//These are the structures
typedef struct {
  unsigned int  NumEntries;  /* number of entries written to the
pModuleData array */
  MODULE_DATA *pModuleData;  /* pointer to array containing module infos
and module handles */
} MODULE;

typedef struct {
   unsigned int ModuleTypeId;/* ModuleTypeId */
   unsigned int hMod;/* handle Module assigned */
   char   *pVendorModuleName;/* Vendor specific information string. */
} MODULE_DATA;

//this is a function that I call via FFI
unsigned int errorCheck GetModuleIds(MODULE  **pModuleIdList)
{
//memory will be allocated here and the structure will be filled.
}

Now my questions :-)


I solve the pointer pointer problem with ExternalAddress and MODULE
fromHandle:

| result pointerAutoRelease mod|
pointerAutoRelease := ExternalAddress new pointerAutoRelease.
result := call ffiGetModuleIds: pointerAutoRelease.
"inside Methode -> ffiGetModuleIds ^self ffiCall:#(uint32
GetModuleIds( void** pModuleIdList ) )"
"result is unimportant for understanding the problem"
mod := MODULE fromHandle: pointerAutoRelease.

Is this a good way? Or is there a better solution?


And now comes my main problem... 
How do I get my array( or Collection) from NumEntries and *pModuleData with
ffi?

So I would do it roughly in C.
main(){

MODULE_DATA *pModuleData; 
MODULE *moduleIdList=NULL;  
unsigned int retval = GetModuleIds(&moduleIdList);

printf("Number of modules: %d\n\n",moduleIdList->NumEntries);
 
for (unsigned int i=0;iNumEntries;i++)
{
// Set a pointer to the current ModuleData
pModuleData = &moduleIdList->pModuleData[i];  //is like iterate
through a pointer

//etc. .
...
}

}

Thanks you for your help.



--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] Output the method name as a string at runtime

[ASAM]

Hello, 
I would like to output the method name as a string in case of an error.

what I've already done is this: (with thisContext selector asString)

pduDestruct
| result |
result := call ffiPDUDestruct.
result = T_PDU_ERROR PDU_STATUS_NOERROR 
ifFalse: [ Error signal:'Method: ' , thisContext selector asString , '  with
result: ', result item asString ]


but now I use it more often. And wanted to rebuild it like that.

initialize
errorBlock := [ :tPduError | Error signal:'Method: ' , thisContext 
selector
asString , '  with result: ', tPduError item asString ].


pduDestruct
| result |
result := call ffiPDUDestruct.
result = T_PDU_ERROR PDU_STATUS_NOERROR ifFalse: [ errorBlock value: 
result
]


but that doesn't work because "this Context selector toString" now returns
'initialize'.

Can someone give me a hint how to solve this? 
Is "thisContext selector asString" the only way to get the name of the
method at runtime?

Thanks in advance.















--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] Output the method name as a string at runtime

[ASAM]

Thanks Ben,
 
in the meantime I come to a solution that looks like your second suggestion.

However, I use the already existing methodsignal: withTag: .

 pduDestruct
| result |
result := call ffiPDUDestruct.
result = T_PDU_ERROR PDU_STATUS_NOERROR
ifFalse: [ DPDiagPduApError signal: thisContext selector asString 
withTag:
result item asString]


Although. I like your solution almost a bit better.
What I like about your solution is, that throwing the exception (signal) is
somehow easier to see while looking.

Thanks
ASAM 




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] UFFI asynchronous callbacks

[ASAM]

I use Pharo 8(64bit) UFFI to call a dll(64bit). 
Over the dll I have access to 1 or more hardware devices.
The dll has a function where I can register a call-back function. 
The callback is invoked whenever a hardware is connected or disconnected
from PC.

At the moment, Pharo always crashes when the callback is executed by the
dll.

Before I waste my time trying to find the bug. 
I wanted to ask first…  Is Pharo supporting asynchronous callbacks?

I also found this old thread but the last entry is from 2017. 
http://forum.world.st/UFFI-with-asynchronous-callbacks-td4993968.html#a5014328
Now I wanted to check the current status.

Thanks for your help.




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

Hello Ben, 

I quickly made a dummy DLL to limit the problem to the essentials.

I think my problem comes more from how I use the semaphore.

I wanted to do that: 

only "semaphore signal",
But that somehow doesn't work.
Now i'm doing that "[ Processor yield. semaphore signal ] fork" (it work's)
but i don't know if that's a good idea.


ffiCallback
^ FFICallback signature: #( void #( uint32 foo ) ) block: [ :foo | 
  Transcript
  show: 'API Funktion value: ' , foo asString, ' 
activePriority:',
  Processor activePriority asString; cr.

"that's working"
  [ Processor yield. semaphore signal ] fork. 
  
  "that usually works 80%."
  "[ semaphore signal ] fork"
  
  "that crashes pharo almost always."
  "semaphore signal"  
]

I also have a little problem, too. Why can I use my own C-Type UNUM32 at
...self ffiCall: #( T_ERROR StartMyThreadFunction(UNUM32 millisecondsToFire)
). 
But with FFICallback signature: # (void # (uint32 foo)) I get an error
"Unable to resolve external type: UNUM32. Why is that?

Thanks for your help.

testDllForAsyncCallback.dll
  
testDllForAsyncCallback.cpp
  
testDllForAsyncCallback.h
  
testDllForAsyncCallback.h
  
UFFICallback.st   
CTypes.st   
 




--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

Hi Pablo, 
today I have a little bit of time to try out the "threaded FFI". 
But immediately with the load I get the following error message 
"PrimitiveFailed: primitive #primitiveInitializeQueueWith: in
TFCallbackQueue failed".

see pic:  <http://forum.world.st/file/t372350/ThreadedFFI.png> 

When I load it again it looks good. But then I get the error message with
every Pharo start.

To rule out possible errors, I tested with a fresh Pharo8 64bit image, of
course.

Could you tell me what i'm doing wrong?

Thanks 
ASAM










--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] UFFI asynchronous callbacks

[ASAM]

no code is needed as I mentioned ...

 But immediately with the load 

Metacello new
baseline: 'ThreadedFFI';
repository: 'github://pharo-project/threadedFFI-Plugin';
onConflictUseLoaded;
load.

To rule out possible errors, I tested with a fresh Pharo8 64bit image, of
course.





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html