<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 22 juin 2020 à 15:20, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le lun. 22 juin 2020 à 12:11, Marcel Taeumel <<a href="mailto:marcel.taeumel@hpi.de" target="_blank">marcel.taeumel@hpi.de</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="gmail-m_-7512624236280241116gmail-m_-3924788306417691219__MailbirdStyleContent" style="font-size:10pt;font-family:Arial;color:rgb(0,0,0)">
> <span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">For the generalization to other atomic types, we indeed need to go through the ExternalType and implement allocate: there too.</span><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Not needed. You can access ExternalType >> #byteSize from within ExternalData. It's public.</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Best,</span></div><div><span style="font-family:Arial,Helvetica,sans-serif;font-size:13px">Marcel</span></div></div></blockquote></div><div class="gmail_quote"><br></div><div class="gmail_quote">Hi Marcel,</div><div class="gmail_quote">you constantly bring me to a lower level API ...<br></div><div class="gmail_quote">I know that byteSize is public, but I don't want to bother with that.</div><div class="gmail_quote">I want to handle an array of N things, not an ExternalData withHandle: (ByteArray new: thing byteSize * N) type: thing.</div><div class="gmail_quote">I want (thing allocate: N), that's all I need...<div>I've used similar constructs provided by VW DLLCC, and believe me, it's convenient!</div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><div>Beside, think of it, an ExternalData has to provide both memory AND type right?<div> ExternalData fromHandle: (ByteArray new: type byteSize * anInteger) type: type.</div><div>Who knows better about its own size than the type itself?<br></div></div><div>Why scatter the responsibilities that could be gathered in the type?<div>Where would this snippet go?</div></div><br></div></div></blockquote><div>The funny thing is that I refactored some dusty parts today, so we can flesh out this discussion:</div><div><br></div><div><div>Name: HDF5-Interface-nice.10</div></div><div>Time: 22 June 2020, 6:13:15.137449 pm</div><div><br></div><div>The old version using byteSize was:</div><div><br></div><div>dimensions<br> "Answer an array of integers representing the dimensions of this dataspace.<br> Note that a dimension -1 means unlimited."<br> | ndims effective hdims maxDims bsize method |<br> ndims := self ndims.<br> bsize := Hsize_t byteSize.<br> method := #(unsignedByteAt: unsignedShortAt: unsignedLongAt: unsignedLongLongAt:) at: bsize highBit.<br> hdims := ByteArray new: ndims * bsize.<br> maxDims := ByteArray new: ndims * bsize.<br> effective := API H5Sget_simple_extent_dims: handle with: hdims with: maxDims.<br> effective = ndims ifFalse: [self error: 'unexpected effective dimensionality'].<br> ^(0 to: ndims - 1) collect: [:i | hdims perform: method with: i * bsize + 1]</div><div><br> </div><div><div>I don't remember if ByteArray did work without using ExternalData wrapper around it, this could only be worse!</div></div><div>The new one is using allocate: which create an ExternalData and deal with all the low level ByteArray container, type byteSize etc...</div><div>It also uses the collection-like protocol on the external data (hdims at:)</div><div><br></div><div>dimensions<br> "Answer an array of integers representing the dimensions of this dataspace.<br> Note that a dimension -1 means unlimited."<br> | ndims effective hdims maxDims |<br> ndims := self ndims.<br> hdims := Hsize_t allocate: ndims.<br> maxDims := Hsize_t allocate: ndims.<br> effective := API H5Sget_simple_extent_dims: handle with: hdims with: maxDims.<br> effective = ndims ifFalse: [self error: 'unexpected effective dimensionality'].<br> ^(1 to: ndims) collect: [:i | (hdims at: i) value] <br></div><div><br></div><div>We can all agree that the later is better.</div><div><div>I have the ExternalData playing its role in the best of the manners:<br></div><div>Tansparently! Exactly like ExternalFunction.</div><div> A great economy of verbiage - unlike this thread ;)</div><div>So thank you Marcel for enhancing those API, let me just add my grain of salt!<br></div></div><div><div><br></div><div>The only annoying thing is the value which unwraps the Hsize_t ExternalTypeAlias value.</div><div>If I would replace Hsize_t with a simple ExternalType hsize_t, then <br></div><div>1) I would omit the value</div><div>2) I would like to write <br> hdims := ExternalType hsize_t allocate: ndims.</div><div>Because it's conceptually the same, allocate an array (ExternalData) of given type.</div><div>That's why I implement allocate: in ExternalType if ever you are still not convinced.<br></div></div></div></div>