From: Joel VanderWerf Date: 2009-06-10T09:19:00+09:00 Subject: Re: binaryparse: length in bytes of block definition? Markus Fischer wrote: > Now, I wouldn't mind going back to bit-struct for the BSP reading stuff, > as I find the documentation outstanding well! However, through > binaryparse I discovered one thing I'm really enjoying: it supports > direct reading from an IO-type object. So I can pass either a File IO or > an StringIO object directory, which is really comfortable. That's a useful addition. I've added that to bit-struct 0.12 now (along with the vector stuff), you can get it at: http://redshift.sourceforge.net/bit-struct > About your upcoming addition and your example: how would a simple > integer array look like? > > C-struct example: > > typedef struct { > float normal[3]; > float dist; > } dplane_t; > > Ruby (?): > > class MyFloat < BitStruct > float :value, 32 > end > > class Plane < BitStruct > vector :normal, MyFloat, :length => 3 > float :dist, 32 > end and then Plane.new.normal[2].value works, but yes it seems like one layer too many. > Would multiple dimension be supported, too? Like C-style float[2][2] ? > > class Plane < BitStruct > vector :normal, :length => 3 do > vector :length => 3 od > float 32 > end > end > float :dist, 32 > end Yes, that's supported now: class MD < BitStruct vector :row, :length => 3 do vector :col, :length => 10 do float :x, 32 end end end md = MD.new rows = md.row row = rows[2] cols = row.col col = cols[7] col.x = 1.23 cols[7] = col row.col = cols rows[2] = row md.row = rows p md p md.row[2].col[7].x As you can see, the reader method is fine, but the writer has to be broken down into a sequence of writes to each nested chunk... yuck. The reason it doesn't allow simply md.row[2].col[7].x = 1.23 is that all those intermediate objects have to be something, either separate (copied) bit-structs, or proxies that delegate back to the original. If the latter, there is IMO the possibility of confusion as these proxies propagate around and the original object changes unexpectedly. Any other ideas...? -- vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407