unpack block?

[Tim Bray]

unpack doesn't seem to take a block. This seems like an obvious
thing to want if I'm going to work with a big input string and not
burn memory. Am I missing something? -Tim

 

[Brian Mitchell]

unpack doesn't seem to take a block. This seems like an obvious
thing to want if I'm going to work with a big input string and not
burn memory. Am I missing something? -Tim

Possibly a good idea. Lets go ahead and try it out.

class String
def unpack_each(format)
index = 0
loop {
break if index >= self.size - 1
yield ary = self[index..-1].unpack(format)
# We can't pack nils nor can we compact and pack too little data.
break if ary.include? nil
index += ary.pack(format).size
}
end
end

So it's not the greatest code ever but it seems to work [1]:

input = ([42] * 99).pack('c*')
count = 0
last = nil
input.unpack_each('cc') {|a| last = a; count += 1}
p count #=> 50
p last #=> [42, nil] Ok. boundaries should work like normal pack.

Of course, it might also be a good idea to consider reading
conservative chunks from whatever you are unpacking and iterating over
those while unpacking but having both ways available might be nice.

Brian.

[1] The usual disclaimers apply. I have not build a good test suite
for this because I only plan on using it as a proof of concept in this
email. I recommend doing so if any of the code is used. ;-)

 

[Brian Mitchell]

Possibly a good idea. Lets go ahead and try it out.

class String
def unpack_each(format)

On second thought... each_unapck is a much better name.

Brian.

 

[Wilson Bilkovich]

On second thought... each_unapck is a much better name.

Shouldn't it just be 'unpack', and have some 'if block_given?' juice
squeezed on it?

 

[Brian Mitchell]

Shouldn't it just be 'unpack', and have some 'if block_given?' juice
squeezed on it?

Not when I am monkey patching [1] like this. If I felt like writing a
worthwhile implementation... then that might happen. I am an advocate
of intelligent interfaces but I am also an advocate of avoiding too
many invasive changes when they really aren't needed. It is perfectly
sensible to play around with this using a name each_unpack.

And it is a sort of iteration... like each_line and each_byte, we get
repeated results from a sort of scan like transformation process. Each
series of unpacked array.. I think it fits.

Anyway.. I sound like a broken record. Just woke up from the aftermath
of an 8 hour long party at my apartment here in NYC. ;-)

Brian.

[1] I have no problem reopening classes but when I override something
I always take great care to minimize change. If this is so great, we
could merge the idea into ruby's code base and call it standard.

 

[Yukihiro Matsumoto]

Hi,

In message "Re: unpack block?"

|unpack doesn't seem to take a block. This seems like an obvious
|thing to want if I'm going to work with a big input string and not
|burn memory. Am I missing something? -Tim

No, it's a quite interesting idea. I implemented it with a few
minutes hack. I will check it in later and try to see how it works
(in HEAD, of course).

matz.