<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>That sounds like a decent compromise. I would strongly request that a ByteArray>>signedByteAt:(put:) exist in the base image. The lack was why it was added - and it is useful for add-on packages such as my Kafka one. </div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Thanks,</div><div id="AppleMailSignature">CNBC<br><br>Sent from my iPhone</div><div><br>On Feb 16, 2016, at 1:41 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><div>Hi Levente,</div><div><br></div><div> I just wanted to note a potential problem with Collections-ul.667</div><div><br></div><div>Name: Collections-ul.667</div><div>Author: ul</div><div>Time: 10 October 2015, 3:40:46.732 pm</div><div>UUID: 7cd785ff-1839-4075-ac56-4b71054529d8</div><div>Ancestors: Collections-topa.666</div><div><br></div><div>Added the missing methods of ByteArray's platform independent access category: #signedByteAt: #signedByteAt:put: #long64At:put:bigEndian: and #long64At:bigEndian:. The 64-bit methods are not optimized.</div><div><br></div><div><br></div><div>In this version you provided ByteArray>>#signedByteAt:[put:] which conflicts with FFI-Kernel's methods of the same name. There's a difference in semantics. If you look at ExternalStructure's class comment it points out that</div><div><br></div><div>"This class provides an abstract base for all structures that can be used by external functions. ExternalStructures have two possible handle types:</div><div><span class="" style="white-space:pre"> </span>- ExternalAddress</div><div><span class="" style="white-space:pre"> </span>If the handle is an external address then the object described does not reside in the Smalltalk object memory.</div><div><span class="" style="white-space:pre"> </span>- ByteArray</div><div><span class="" style="white-space:pre"> </span>If the handle is a byte array then the object described resides in Smalltalk memory.</div><div>Useful methods should be implemented by subclasses of ExternalStructure using the common ByteArray/ExternalAddress platform dependent access protocol which will transparently access the correct memory location."</div><div><br></div><div>i.e. the primitives used automatically differentiate between an ExternalAddress holding a pointer to external memory, in which case the datum is accessed via that location, or a ByteArray, in which case the datum is accessed in the ByteArray. Your versions only do the latter and would hence misinterpret data in ExternalAdderss instances. Here's the FFI code:</div><div><br></div><div>ByteArray>>signedByteAt: byteOffset</div><div><span class="" style="white-space:pre"> </span>"Return a 8bit signed integer starting at the given byte offset"</div><div><span class="" style="white-space:pre"> </span>^self integerAt: byteOffset size: 1 signed: true</div><div><br></div><div>ByteArray>>integerAt: byteOffset size: nBytes signed: aBoolean</div><div><span class="" style="white-space:pre"> </span>"Primitive. Return an integer of nBytes size from the receiver.</div><div><span class="" style="white-space:pre"> </span>Note: This primitive will access memory in the outer space if</div><div><span class="" style="white-space:pre"> </span>invoked from ExternalAddress."</div><div><span class="" style="white-space:pre"> </span><primitive: 'primitiveFFIIntegerAt' module:'SqueakFFIPrims'></div><div><span class="" style="white-space:pre"> </span>^self primitiveFailed</div><div><br></div><div>And here's yours:</div><div>ByteArray>>signedByteAt: index</div><div><span class="" style="white-space:pre"> </span>"Return an 8-bit signed integer quantity from the given byte index."</div><div><span class="" style="white-space:pre"> </span></div><div><span class="" style="white-space:pre"> </span>| byte |</div><div><span class="" style="white-space:pre"> </span>(byte := self at: index) <= 16r7F ifTrue: [ ^byte ].</div><div><span class="" style="white-space:pre"> </span>^byte - 16r100</div><div><br></div><div>Now of course this isn't an issue in builds that load the FFI after Collections, but it does affect images in which FFI-Kernel was loaded and then the image was updated to instal Collections-ul.667.</div><div><br></div><div>I'm not sure what the right fix is, but I thought I'd better mention it. One obvious one is to implement the FFI methods in ExternalAddress>>#signedByteAt:[put:], and if folks agree I can do this. Let me know. Pharoers, if I do this, you'll need to make sure that the Pharo base includes ByteArray>>#signedByteAt:[put:].</div><div><br></div><div class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div>
</div></blockquote><blockquote type="cite"><div><span></span><br></div></blockquote></body></html>