[Pharo-project] NativeBoost callbacks - status?
Hi Igor, What is the extent to which callbacks are currently supported in NB? On my machine (macos10.6) they do not seem to work properly. The quick sort test crashes the VM. What are the limitations of the current implementation? Thanks Ciprian
Normally it worked. Stef On Nov 22, 2012, at 12:11 PM, Ciprian Teodorov wrote:
Hi Igor,
What is the extent to which callbacks are currently supported in NB?
On my machine (macos10.6) they do not seem to work properly. The quick sort test crashes the VM.
What are the limitations of the current implementation?
Thanks Ciprian
i will check. I didn't merged with your code, Ciprian yet.. does it crashing for NativeBoost-Core-IgorStasenko.78 or in your code? i will merge your stuff and check. -- Best regards, Igor Stasenko.
Hi Igor, My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke the callbacks since I have also removed the ulongAt: and ulongAt:put: accessors which are used by the callback counter (there are some strange argument conversions going on). Though if I merge your .78.mcz with my .83.mcz all tests pass ... I don't know what you think about having the memory accessors in a trait? the bad thing is that I do not see any way of sharing them with the ones from ByteArray (can we extend a class with traits?)... however such a trait might be handy if we want to implement something like FloatArray using NB (think about FloatArray32, FloatArray64, etc)... I will try to fix this issue during the WE... if I will find the time. Thanks very much! Ciprian On Thu, Nov 22, 2012 at 2:49 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i will check.
I didn't merged with your code, Ciprian yet.. does it crashing for NativeBoost-Core-IgorStasenko.78 or in your code?
i will merge your stuff and check.
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
On 22 November 2012 20:22, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi Igor,
My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke the callbacks since I have also removed the ulongAt: and ulongAt:put: accessors which are used by the callback counter (there are some strange argument conversions going on).
Though if I merge your .78.mcz with my .83.mcz all tests pass ...
I don't know what you think about having the memory accessors in a trait? the bad thing is that I do not see any way of sharing them with the ones from ByteArray (can we extend a class with traits?)...
hmm.. i think we can't because that will make Collections package dirty. So, there's not much choice: we should use only extension methods. What i thinking is getting rid of ulongAt/put protocols, and use uint32 instead to be more precise and to not confuse with C types.
however such a trait might be handy if we want to implement something like FloatArray using NB (think about FloatArray32, FloatArray64, etc)...
I will try to fix this issue during the WE... if I will find the time.
Thanks very much! Ciprian
On Thu, Nov 22, 2012 at 2:49 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i will check.
I didn't merged with your code, Ciprian yet.. does it crashing for NativeBoost-Core-IgorStasenko.78 or in your code?
i will merge your stuff and check.
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On Nov 22, 2012 11:23 PM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 22 November 2012 20:22, Ciprian Teodorov <ciprian.teodorov@gmail.com>
wrote:
Hi Igor,
My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke the callbacks since I have also removed the ulongAt: and ulongAt:put: accessors which are used by the callback counter (there are some strange argument conversions going on).
Though if I merge your .78.mcz with my .83.mcz all tests pass ...
I don't know what you think about having the memory accessors in a trait? the bad thing is that I do not see any way of sharing them with the ones from ByteArray (can we extend a class with traits?)...
hmm.. i think we can't because that will make Collections package dirty. So, there's not much choice: we should use only extension methods. What i thinking is getting rid of ulongAt/put protocols, and use uint32 instead to be more precise and to not confuse with C types. That's what I have tried to do in my last 3 commits, but there seems to be some strange border effect (with callback counter) that I did not see coming. I'll look into it during the WE.
Cheers
however such a trait might be handy if we want to implement something
like
FloatArray using NB (think about FloatArray32, FloatArray64, etc)...
I will try to fix this issue during the WE... if I will find the time.
Thanks very much! Ciprian
On Thu, Nov 22, 2012 at 2:49 PM, Igor Stasenko <siguctua@gmail.com> wrote:
i will check.
I didn't merged with your code, Ciprian yet.. does it crashing for NativeBoost-Core-IgorStasenko.78 or in your code?
i will merge your stuff and check.
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On 23 November 2012 11:07, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
On Nov 22, 2012 11:23 PM, "Igor Stasenko" <siguctua@gmail.com> wrote:
On 22 November 2012 20:22, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi Igor,
My bet ... extracting the nbXAtOffset to the TNBMemoryAccessors broke the callbacks since I have also removed the ulongAt: and ulongAt:put: accessors which are used by the callback counter (there are some strange argument conversions going on).
Though if I merge your .78.mcz with my .83.mcz all tests pass ...
I don't know what you think about having the memory accessors in a trait? the bad thing is that I do not see any way of sharing them with the ones from ByteArray (can we extend a class with traits?)...
hmm.. i think we can't because that will make Collections package dirty. So, there's not much choice: we should use only extension methods. What i thinking is getting rid of ulongAt/put protocols, and use uint32 instead to be more precise and to not confuse with C types.
That's what I have tried to do in my last 3 commits, but there seems to be some strange border effect (with callback counter) that I did not see coming. I'll look into it during the WE.
yes, i merged with your code and now running callback test is crashing VM. i will try to figure what's going on.
Cheers
-- Best regards, Igor Stasenko.
okay, seems like i found why: NBExternalAddress>>ulongAt: zeroBasedOffset put: value "Store unsigned 64-bit integer into memory at (receiver's address + ZERO-based offset) using native byte order. Note, there is no range checking " It should use 32-bit values.. Callback code using ulongAt:put. to store single value at certain address in machine code. Since it stores 64-bit value instead of 32bit, it overrides the instructions which follow, and of course that leads to crash. Trait aliases.. is wrong: #longAt:->#nbInt64AtOffset:. #longAt:put:->#nbInt64AtOffset:put:. #ulongAt:->#nbUInt64AtOffset:. #ulongAt:put:->#nbUInt64AtOffset:put: another reason to get rid of confusion with C types.. -- Best regards, Igor Stasenko.
On Sat, Nov 24, 2012 at 3:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
okay, seems like i found why:
NBExternalAddress>>ulongAt: zeroBasedOffset put: value "Store unsigned 64-bit integer into memory at (receiver's address + ZERO-based offset) using native byte order. Note, there is no range checking "
It should use 32-bit values.. Callback code using ulongAt:put. to store single value at certain address in machine code. Since it stores 64-bit value instead of 32bit, it overrides the instructions which follow, and of course that leads to crash.
Trait aliases.. is wrong:
#longAt:->#nbInt64AtOffset:. #longAt:put:->#nbInt64AtOffset:put:. #ulongAt:->#nbUInt64AtOffset:. #ulongAt:put:->#nbUInt64AtOffset:put:
another reason to get rid of confusion with C types..
Yep indeed... that's the issue ... I have corrected it locally, but I cannot commit it (it seems I'm not in the developers list anymore):
NBExternalHandle variableByteSubclass: #NBExternalAddress uses: TNBMemoryAccessors @ {#byteAt:->#nbInt8AtOffset:. #byteAt:put:->#nbInt8AtOffset:put:. #longAt:->#nbInt32AtOffset:. #longAt:put:->#nbInt32AtOffset:put:. #ulongAt:->#nbUInt32AtOffset:. #ulongAt:put:->#nbUInt32AtOffset:put:} Cheers, Ciprian
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
On 25 November 2012 13:27, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
On Sat, Nov 24, 2012 at 3:39 PM, Igor Stasenko <siguctua@gmail.com> wrote:
okay, seems like i found why:
NBExternalAddress>>ulongAt: zeroBasedOffset put: value "Store unsigned 64-bit integer into memory at (receiver's address + ZERO-based offset) using native byte order. Note, there is no range checking "
It should use 32-bit values.. Callback code using ulongAt:put. to store single value at certain address in machine code. Since it stores 64-bit value instead of 32bit, it overrides the instructions which follow, and of course that leads to crash.
Trait aliases.. is wrong:
#longAt:->#nbInt64AtOffset:. #longAt:put:->#nbInt64AtOffset:put:. #ulongAt:->#nbUInt64AtOffset:. #ulongAt:put:->#nbUInt64AtOffset:put:
another reason to get rid of confusion with C types..
Yep indeed... that's the issue ... I have corrected it locally, but I cannot commit it (it seems I'm not in the developers list anymore):
yeah.. squeaksource sometimes "forgets" some metadata, when it crashes.. i added you back. But if you just want to fix this, and nothing else, don't bother: i already committed the fix as well as a lot more code.. I want to release new version of config with new great stuff. :)
NBExternalHandle variableByteSubclass: #NBExternalAddress uses: TNBMemoryAccessors @ {#byteAt:->#nbInt8AtOffset:. #byteAt:put:->#nbInt8AtOffset:put:. #longAt:->#nbInt32AtOffset:. #longAt:put:->#nbInt32AtOffset:put:. #ulongAt:->#nbUInt32AtOffset:. #ulongAt:put:->#nbUInt32AtOffset:put:}
Cheers, Ciprian
-- Best regards, Igor Stasenko.
-- Dr. Ciprian TEODOROV Ingénieur Développement CAO
tél : 06 08 54 73 48 mail : ciprian.teodorov@gmail.com www.teodorov.ro
-- Best regards, Igor Stasenko.
On 22 November 2012 12:11, Ciprian Teodorov <ciprian.teodorov@gmail.com> wrote:
Hi Igor,
What is the extent to which callbacks are currently supported in NB?
On my machine (macos10.6) they do not seem to work properly. The quick sort test crashes the VM.
hmm. should work fine. Make sure you using updated VM.
What are the limitations of the current implementation?
the limitation is multithreading. callback should be called in same thread as VM. another limitation is that callback should be called only during execution of some primitive, or to be more precise. it is only related to interrupt/event handling of VM: no callbacks allowed during interrupt/event handling. but i will get to that once will have a code to check that (like making own callback to handle events from OS) -- Best regards, Igor Stasenko.
participants (3)
-
Ciprian Teodorov -
Igor Stasenko -
Stéphane Ducasse