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

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. :wink:

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? -Tim

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.

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. :wink:

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.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs