Front page | perl.perl5.porters |
Postings from March 2000
In <492568AA.001ACB7C.00@pwj-gw-n001.pwj.co.jp>, scozens@pwj.co.jp writes:
:(Bugs)
:
:! fix small memory leaks on compile-time failures
:
:This is echoed in perltodo:
:
:# =head2 Memory leaks from failed eval/regcomp
:# The only known memory leaks in Perl are in failed code or regexp
:# compilation. Fix this. Hugo Van Der Sanden will attempt this but
:# won't have tuits until January 1999.
:
:Hugo, did you have any luck tracking this down? At
:the very least is there a test case for this?
No; I haven't put any significant time into this. I don't know how to
find out what has leaked; if there is an easy way to find that out,
so that test cases can be checked, then the whole problem should become
fairly straightforward.
:(64-bits)
:
:! Long doubles: figure out where the PV->NV->PV conversion gets it
:! wrong at least in AIX and Tru64 (V5.0 and onwards)
:
:I have a sneaking suspicion this is something Spider Boardman's
:looking at. I also have a sneaking suspicion I just made that up
:out of thin air.
:
:# Verify complete 64 bit support so that the value of sysseek,
:# or C<-s>, or stat(), or tell can fit into a perl number without
:# losing precision.
:
:What's the latest on this?
I think a later bit falls in this section as well:
:! fix the basic arithmetics (+ - * / %) to preserve IVness/UVness if
:! both arguments are IVs/UVs
.. which I believe is part of permitting op/numconvert.t to act sanely
with 64 bit ints.
:(Regexps)
Make regexp engine reentrant: this has been waiting a long time. Ilya
says it is easy.
The recently reported SEGV from diagnostics.pm is just another example
of why this is needed.
:} foreach(reverse...)
:
:I wonder how this can be done. You'd have to delay evaluation of the
:range until runtime.
I think generic iterators should do this: I'd like to be able to do,
say:
for (grep isprime($_), 2 .. ) { # or perhaps '2 .. inf'
...
}
:# there was talk of a mark-and-sweep garbage collector at TPC2
:
:Is this idea still alive or dead?
Hmmm, it would be handy to combine this with reference counting to
find memory leaks.
:(Modules)
:
:Wanted:
A fast and robust BigInt; I still vaguely hope to do this someday if
tuits spherify.
:# perfect a Perl version of expect
:
:Work with IO::Tty and put these in core replacing Comm.pl
:Is this really what we want/need?
I'd love to see a decent perl-based expect.
:! describe new age patterns
:
:What's outstanding here?
Comprehensible documentation for most recently added regexp mechanisms.
Some of the mechanisms may not yet have stabilised, however. (Eg //p.)
:} iterators/lazy evaluation/continuations/first/
:} first_defined/short-circuiting grep/??
:
:Aaaargh.
Macros, of course. :)
:} a way to make << and >> to shift bitvectors instead of numbers
:
:This makes sense to someone.
Would be nice: there are a number of things that you can't easily do
with vec() strings - initialising to all ones/all zeroes is another.
I don't see how to achieve it though: core changes would modify
existing semantics for '$x << 1', and a module that overloaded
operators on wrapped bitvecs would seem too slow to be worth doing.
Hugo
Thread Previous
|
Thread Next