2015-05-06 13:38 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:


On Wed, May 6, 2015 at 12:29 PM, Nicolai Hess <nicolaihess@web.de> wrote:


2015-05-06 12:10 GMT+02:00 phil@highoctane.be <phil@highoctane.be>:
I've loaded your package.

A prerequisite is to load OS-Window to make it work.

I've got the DLL call working nicely and the nativeboost with the structure freezing.

This is because you have a recursive datastructure description, but acutually the IP_ADAPTER_INFO structure is not recursive:

PIP_ADAPTER_INFO class >>fieldsDex
^ #(
��PIP_ADAPTER_INFO�� nextVariable;
�� DWORD������������������������������������ ComboIndex;
�� CHAR�������������������������������������� AdapterName;
�� CHAR�������������������������������������� Description;
....)

The "nextVariable" should be a pointer to the structure.

from MSDN:

 struct _IP_ADAPTER_INFO {
  struct _IP_ADAPTER_INFO ��*Next;   "<- pointer"
  DWORD ������������������������������������ComboIndex;
  char ��������������������������������������AdapterName[MAX_ADAPTER_NAME_LENGTH + 4];
  char ��������������������������������������Description[MAX_ADAPTER_DESCRIPTION_LENGTH + 4];
  UINT ��������������������������������������AddressLength;

....


��
So, what's to put in there then?

IpAdapterInfo class>>#fieldsDesc
^#(
�� IpAdapterInfo*�� Next;
�� DWORD���� ComboIndex;
....

This would work

��
I can use FFI / NB for basic cases but never ventured into those structure.
I'd like to :-)

Phil
I





��
because it looks like the way to go to wrap libraries...

Ronie, I know you modified swig for generating Pharo code;

Is cloning your swig repo the way to go ?


Phil





On Wed, May 6, 2015 at 10:39 AM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
Hi Nicolai,

Here is my package that defines the nativeboost call and associated C structs.
The external C struct is self referencing and hence sometimes I get infinite recursion when trying to change field descriptions. That is the reason why the automatically generated accessors are absent (although I had them in an earlier version).

Attached also the DLL referenced in the code.



On Wed, May 6, 2015 at 9:58 AM, Nicolai Hess <nicolaihess@web.de> wrote:


2015-05-06 9:53 GMT+02:00 Usman Bhatti <usman.bhatti@gmail.com>:


On Tue, May 5, 2015 at 7:34 PM, phil@highoctane.be <phil@highoctane.be> wrote:

On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:
I succeeded to do it by encapsulating the C routine as a DLL and doing an FFI call from my image (as suggested by Guille).

At least there was a way!

Exactly :)
��

Looks like this is the most controlled|debuggable way:
�� - get it working with C code out of Pharo
�� - make a bridge that can be used easily with FFI in a dll
�� - use that from Pharo with proven FFI

Would NativeBoost work with your dll? Should.

I have read a few resources about Nativeboost but I am still naive to know the difference between FFI and nativeboost. The FFI call I made to invoke the DLL function looked similar to the nativeboost calls.
��


I also tried to perform the nativeboost call by creating my structures in Pharo. The function in Windows that can be used to retrieve mac address in Windows:��GetAdaptersInfo��that accepts a PIP_ADAPTER_INFO����structure. I subclassed NBExternalStructure to define this struct and the other used by it in the image but my NB call returned with 87 code (Invalid parameter) and it was impossible to debug. However, I would like to make this thing work to understand what went wrong.

Has this something to do with 32|64 bit library complications?

Not exactly. For me, it was more related to the fact that I had to map a complex C struct in Pharo. Here is an excerpt of the definition from MSDN:

typedef struct _IP_ADAPTER_INFO {
�� struct _IP_ADAPTER_INFO ��*Next;
��...
��PIP_ADDR_STRING �� �� �� �� CurrentIpAddress;
�� �� �� �� �� IP_ADDR_STRING �� �� �� �� ��GatewayList;
...
}

So, I had to define three external structures (all names in capitals) and I did the effort but in the end I got an error code that I could not debug in the image. Hence, I gave up and opted to go in the native environment. But I would like someone knowledgable to have a look at my nativeboost code ��because the nativeboost approach is more simple (everything's in the image).

I can have a look.

btw. for what do you need the mac address?

��



usman
��

Phil

With ProcessWrapper, I could not load the classes essential for making the plugin work.

HTH,

Usman




On Mon, May 4, 2015 at 2:54 PM, Ben Coman <btc@openinworld.com> wrote:
As a complete newb to VM building I found this fairly straight forward (on a Mac btw).
cheers -ben

On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti <usman.bhatti@gmail.com> wrote:


On Sun, May 3, 2015 at 4:22 PM, Pierce Ng <pierce@samadhiweb.com> wrote:
On Sat, May 02, 2015 at 03:55:47PM +0200, Usman Bhatti wrote:
> 1/ OSProcess: I tried�� (PipeableOSProcess command: 'ipconfig /all') output.

I have used http://www.smalltalkhub.com/#!/~hernan/ProcessWrapper successfully
back when I was on Windows using some now-ancient version of Pharo.

I had initially discarded the idea of using this project because it required a plugin and the information of the plugin was outdated on squeaksource. However, having evaluated superficially the complexity of doing it with nativeboost (because too many external c struct involved in the call), I would like to see if I am better off using this wrapper.

I loaded it with:

Gofer it
�� package: 'ProcessWrapper-Core';
�� package: 'ProcessWrapper-Plugin';
�� package: 'ProcessWrapper-Tests'; �� �� �� ��
�� load.

But the plugins wont load because it requires the class��SmartSyntaxInterpreterPlugin and apparently this file is a part of the VMMaker. Is there any recent config for VMMaker in Pharo because this one looks outdated:



��

Pierce








��








��