Stas Bekman <[EMAIL PROTECTED]> writes: > Joe Schaefer wrote:
[...] > > :-) Not for this in mp2. Technically the problem lies with > > Perl_sv_setsv_flags, which does not copy magic (except for vstrings in > > 5.8.1+, which explains the current apreq2 code). Once I better > > understand the purpose of the (currently undocumented?) mg_copy slot in > > struct mgvtbl, I'll see if I can convince p5p to let Perl_sv_setsv_flags > > copy magic whenever that slot is occupied. > > That may just work, if it doesn't incur a significant delay for the > generic case. Heh, I just figured out how to get values to work in apreq2 without the MAGIC_KEYS hack. The basic problem is that perl does a lazy fetch of tied hash values - paraphrasing perlguts, it creates an empty PVLV that has (PERL_MAGIC_tiedelem) get-magic, so it doesn't actually FETCH the value until perl demands the value. So when you write something like my @values = values %$table; perl generates all the magic PVLV's by iterating over the keys, and it isn't until the "=" assignment that perl executes the FETCH on each value. The problem is that our iterator (SvCUR(obj)) has already ran through the key list, so it's value is 0 when those FETCHES are executed. However, after taking a closer look at how perl constructs the PVLV, I realized that this issue can be solved by freezing the iterator's value during the PVLV's construction. I just committed this idea to apreq2's cvs by simply cloning the table's SV and copying its SvCUR setting, and values() seems to work fine. This cloning seems involves a ton of copying overhead, so maybe a better choice of iterator could make this be more efficient (after all, it's only the iterator that we need to clone to get values() working). -- Joe Schaefer --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
