This Week on p5p 1999/12/26



Notes

Last year I fell behind on reports because I took three business trips in two weeks. I still haven't caught up, so I am going to skip the last couple of reports. I was going to skip this week's report also, but it was so small I decided to do it anyway. The next report should be for 9--15 January. Sorry for the inconvenience.

Meta-Information

The most recent report will always be available at http://www.perl.com/p5pdigest.cgi .

You can subscribe to an email version of this summary by sending an empty message to p5p-digest-subscribe@plover.com.

Please send corrections and additions to mjd-perl-thisweek-YYYYMM@plover.com where YYYYMM is the current year and month.

Module Interface and Version Meta-Information

Last week a discussion started about how to put version information into modules in a standard way, and Sam Tregar suggested that there be a convention that the version information and other module interface information be stored in the POD documents. Discussion on this continued. I should probably have mentioned it in the pervious report.

Sam's message

SVs by Default

When you create a GV (glob value) in Perl, it has its SV slot filled automatically. For example, when you define @foo or sub bar you get space allocated for $foo and $bar automatically. The rationale behind this is presumably that scalar variables are very common and you might as well preallocate them. (I suppose this is why defined *{foo}{SCALAR} always yields true.)

Nick Ing-Simmons complained about this, saying that many SVs are allocated that are never used, and that the original assumption, that SVs are very common, may not be true now that most scalar variables are lexical.

I did not see a resolution of this.

Another return of PREPARE

In an earlier report, I mentioned that Ilya's PREPARE feature had not gone innto 5.005_63. Sarathy added that it would not go into 5.005_64 either unless it was fixed to not use a new opcode.

I mention this because Ilya replied that Perl needs twenty or thirty new opcodes, and that last year he demonstrated that by introducing new opcodes that atomically combine two or more other opcodes that often appear in sequence, some operations might be sped up by a factor of two. This was interesting, although it is not clear that it has anything to do with PREPARE.

Original discussion

Later followup

More Flushing Problems

Someone with no name submitted a bug report that pointed out that if you call truncate Perl truncates the file without flushing the stdio buffer. This is only the most recent in a very long series of similar, related bugs. I wonder why this is so hard to get right? Is it just that nobody has taken it up?

Ilya said that the last time this had come up, he suggested that Perl should always flush the buffer between any buffered and unbiffered operation, and between any read and any write, but ``The result is nil.''

Array::Virtual

Last week's discussion

Andrew Ford reports that this is finished, and is available at http://www.ford-mason.co.uk/resources/. It will appear on CPAN eventually.

#line directives

Andrew Pimlott pointed out that a #line directive in a require'd file inherits its implicit filename not from the file it is in, but from the file that required it. Apparently this is a feature. Andrew submitted a patch changing the behavior. There was no followup discussion. I do not know if the patch was accepted.

DProf

Håkon Alstadheim supplied a patch to Devel::DProf that allows the user to specify the data output file, via an environment variable.

Various

A medium-sized collection of bug reports, bug fixes, non-bug reports, questions, and answers. Apparently the spammers were all on vacation.

Until next time I remain, your humble and obedient servant,


Mark-Jason Dominus
Visit the home of the Perl programming language: Perl.org

Sponsored by

Monthly Archives

Powered by Movable Type 5.13-en