I had a #asString method in the BYTE_8 class that I put by accident in the
*generated-code... protocol
This method will be removed if the generated methods are regenerated.
Just add a new method:
BYTE_8>>asString
^ self address hex
The address has 8 bytes because this is the max number of bytes reserved
for the address.
The IP_ADAPTER_INFO struct has a field for the actually used number of
bytes.
You can read that field and just read this number of bytes.
2015-05-12 21:32 GMT+02:00 Usman Bhatti <usman.bha...@gmail.com>:
> Hi Nicolas,
>
> Thank you for looking at the code.
> I was away and could not try your code.
>
> On Thu, May 7, 2015 at 9:27 AM, p...@highoctane.be <p...@highoctane.be>
> wrote:
>
>>
>>
>> On Thu, May 7, 2015 at 1:06 AM, Nicolai Hess <nicolaih...@web.de> wrote:
>>
>>>
>>>
>>> 2015-05-06 22:47 GMT+02:00 Henrik Sperre Johansen <
>>> henrik.s.johan...@veloxit.no>:
>>>
>>>> A few easily fixed Type/pointers to Types mixups, and a slipup where
>>>> two different classes are confused for the same aside, the real show
>>>> stopper, if I haven't missed something entirely, is that the struct
>>>> parser/NB in general does not handle const sized arrays*, which is used in
>>>> a few of the required structs.
>>>>
>>>> Extending the parser should be relatively straight forward, along the
>>>> lines of adding
>>>> stream peek: #'[' ifTrue: [stream next.
>>>> type := SizedExternalArrayType type: type size: stream next.
>>>> stream next = #']' ifFalse: [self error: 'Missing closing bracket
>>>> for ', type printString]]
>>>> to NBExtenralStructureFields >> #parseFields:... after the name is read.
>>>>
>>>> Coding SizedExternalArrayType is a bit more work though...
>>>>
>>>> Cheers,
>>>> Henry
>>>>
>>>>
>>>> *The end goal would be to be able to generate accessors/read/write for
>>>> a simple test-struct such as
>>>> #fieldsDesc
>>>> ^#(
>>>> char ip[MyClassVar +2];
>>>> )
>>>>
>>>
>>> Yes, a parser for this would be great.
>>>
>>> I tried it with a little hack
>>>
>>> NBExternalStructure subclass: #Char_260 ...
>>>
>>> Char_260 class>>#fieldDesc
>>> ^ #(char data)
>>>
>>> Char_260 class>>instanceSize
>>> ^ 260
>>>
>>> You need another accessor for accessing the data, otherwise you'll only
>>> get the first char. AND I don't know how
>>> the external memory is handle, probably it is never freed :)
>>>
>>> Now a complete example (attached code) call it with
>>> GetMacWin32 getMacAddress
>>>
>>
>>
>> Code loads fine on my 3.0
>>
>
> same here.
>
>
>>
>> But hiccup on:
>>
>
>> resolveType: aTypeName
>> " a type name could be
>> - a class variable name
>> - a class name
>> - a type name
>> - a type name, followed by arbitrary number pointer chars - $*"
>>
>> | name newName resolver binding ptrArity |
>> newName := aTypeName.
>> ptrArity := 0.
>> "resolve aliases and pointers"
>> [
>> name := newName trimRight. <<<--------------- HERE - as newName is a
>> subclass of NBExternalStructure, so no trimRight
>> newName := self aliasForType: name.
>> newName last = $* ifTrue: [
>> ptrArity := ptrArity + 1.
>> newName := newName allButLast ].
>> name = newName ] whileFalse.
>>
>> I changed to name := newName asString trimRight.
>>
>
> this worked for me.
>
>
>>
>> Call worked then but output gives this:
>>
>> GetMacWin32 getMacAddress 'BYTE_8 (
>> data: $¼ <-- some weird string here
>> )'
>>
>
> It worked for me, I didn't encounter the problem of strange characters.
> I get:
> 000c29ab70960000
> The last 4 trailing zeros are not the part of the mac address and I am not
> sure why these are getting added. I'll have a look at your code.
>
> thanks again.
>
> usman
>
>
>> Also, I wonder why you call the primGet... twice
>>
>> getMacAddressOf: iInterface
>> | ptr ptr2 nul ret |
>> ptr := NativeBoost allocate: 4.
>> nul := NativeBoost allocate: 0.
>> ptr nbUInt32AtOffset: 0 put: 0.
>> ret := self primGetAdaptersInfo: nul length: ptr.
>> ret = 111 "ERROR_BUFFER_OVERFLOW"
>> ifTrue: [
>> | size |
>> size := ptr nbUInt32AtOffset: 0.
>> ptr2 := NativeBoost allocate: size.
>> ret := self primGetAdaptersInfo: ptr2 length: ptr.
>> ret = 0 "NO_ERROR"
>> ifTrue: [
>> | pip numberOfInterfaces|
>> numberOfInterfaces := size / IpAdapterInfo instanceSize.
>> (iInterface between:1 and: numberOfInterfaces) ifFalse:[ ^ nil].
>> pip := (NBExternalArray ofType: IpAdapterInfo) onAddress: ptr2 size:
>> numberOfInterfaces.
>> ^ (pip at:iInterface ) Address asString]].
>> ^ nil
>>
>> Phil
>>
>>
>>
>>
>>
>>>
>>>
>>>>
>>>> On Wed, May 6, 2015 at 5:28 PM, Esteban Lorenzano <esteba...@gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On 06 May 2015, at 17:03, Nicolai Hess <nicolaih...@web.de> wrote:
>>>>>
>>>>>
>>>>>
>>>>> 2015-05-06 16:40 GMT+02:00 Esteban Lorenzano <esteba...@gmail.com>:
>>>>>
>>>>>>
>>>>>> On 06 May 2015, at 12:10, p...@highoctane.be wrote:
>>>>>>
>>>>>> I've loaded your package.
>>>>>>
>>>>>> A prerequisite is to load OS-Window to make it work.
>>>>>>
>>>>>>
>>>>>> why?
>>>>>> in any case, oswindow is already included in pharo4
>>>>>>
>>>>>
>>>>> OS-Windows (by TorstenBergmann)
>>>>>
>>>>> not
>>>>> OSWindow :)
>>>>>
>>>>>
>>>>> ahhh. Name clash :)
>>>>>
>>>>>
>>>>> It is needed for the shared pool WinTypes,
>>>>> but without OS-Window, he can use NBWinTypes instead.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Esteban
>>>>>>
>>>>>>
>>>>>> I've got the DLL call working nicely and the nativeboost with the
>>>>>> structure freezing.
>>>>>>
>>>>>> Now, we should all have a look at:
>>>>>>
>>>>>> https://github.com/ronsaldo/bullet-pharo
>>>>>>
>>>>>> and
>>>>>>
>>>>>> https://github.com/ronsaldo/swig
>>>>>>
>>>>>> 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.bha...@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 <nicolaih...@web.de>
>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2015-05-06 9:53 GMT+02:00 Usman Bhatti <usman.bha...@gmail.com>:
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Tue, May 5, 2015 at 7:34 PM, p...@highoctane.be <
>>>>>>>>> p...@highoctane.be> wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, May 5, 2015 at 6:28 PM, Usman Bhatti <
>>>>>>>>>> usman.bha...@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
>>>>>>>>>>> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa365917%28v=vs.85%29.aspx>
>>>>>>>>>>> that
>>>>>>>>>>> accepts a PIP_ADAPTER_INFO
>>>>>>>>>>> <https://msdn.microsoft.com/en-us/library/windows/desktop/aa366062(v=vs.85).aspx>
>>>>>>>>>>> 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 <b...@openinworld.com>
>>>>>>>>>> wrote:
>>>>>>>>>> As a complete newb to VM building I found this fairly straight
>>>>>>>>>> forward (on a Mac btw).
>>>>>>>>>> https://github.com/pharo-project/pharo-vm
>>>>>>>>>> cheers -ben
>>>>>>>>>>
>>>>>>>>>> On Mon, May 4, 2015 at 5:28 PM, Usman Bhatti <
>>>>>>>>>> usman.bha...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Sun, May 3, 2015 at 4:22 PM, Pierce Ng <pie...@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
>>>>>>>>>> url: 'http://www.smalltalkhub.com/mc/hernan/ProcessWrapper/main
>>>>>>>>>> ';
>>>>>>>>>> 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:
>>>>>>>>>>
>>>>>>>>>> http://pharo.gemtalksystems.com/book/Virtual-Machine/Building/VMMakerTool/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Pierce
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> --
>> ---
>> Philippe Back
>> Visible Performance Improvements
>> Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
>> Mail:p...@highoctane.be | Web: http://philippeback.eu
>> Blog: http://philippeback.be | Twitter: @philippeback
>> Youtube: http://www.youtube.com/user/philippeback/videos
>>
>> High Octane SPRL
>> rue cour Boisacq 101 | 1301 Bierges | Belgium
>>
>> Pharo Consortium Member - http://consortium.pharo.org/
>> Featured on the Software Process and Measurement Cast -
>> http://spamcast.libsyn.com
>> Sparx Systems Enterprise Architect and Ability Engineering EADocX Value
>> Added Reseller
>>
>>
>>
>
