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
On 10/13/06, Tim B. [email protected] wrote:
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. 
On 10/13/06, Brian M. [email protected] wrote:
On 10/13/06, Tim B. [email protected] wrote:
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? -TimPossibly 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.
On 10/13/06, Brian M. [email protected] wrote:
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?
Hi,
In message “Re: unpack block?”
on Sat, 14 Oct 2006 08:14:14 +0900, Tim B. [email protected]
writes:
|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.
On 10/13/06, Wilson B. [email protected] wrote:
def unpack_each(format)
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?
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.