I hope to use apache2 + Mod_perl2 that to make the forum run stable and quickly in Windows 2000.

Highlights In 5.8.0

- Better Unicode Support:
Unicode support has been much enhanced since 5.6, at all levels:
- now supports Unicode 3.2.0 (5.6.1 supports 3.0.1)
- at the language (and internals) level Unicode support is
now more ubiquitous and robust
- regular expressions now work with Unicode
- support for non-Latin encodings (such as the various
Chinese/Japanese/Korean encodings) through the Encode module

- New Threads Implementation:
A new multithreading implementation called interpreter threads,
or "ithreads" for short, is available, their use instead of the
old "5.005 threads" is strongly encouraged. The major difference
is that in ithreads any data sharing must be done explicitly.

- New IO Implementation:
the new PerlIO implementation is both a portable stdio implementation
(at the source code level) and a flexible new framework for richer
I/O behaviours

- Better Numeric Accuracy:
previous Perls relied on vendors' string-to-number and back
routines which in some cases proved to be too much trust
leading to nonportable and wrong behaviours

- 64-bit support:
64-bit support is now considered to be mature -- if your platform
supports 64-bit integers or address space, you can compile Perl to
use those

- Safe Signals:
in previous versions of Perl signals could corrupt Perl's internal state

- Many New Modules:
Digest::MD5, File::Temp, Filter::Simple, libnet, List::Util,
Memoize, MIME::Base64, Scalar::Util, Storable, Switch,
Test::More, Test::Simple, Text::Balanced, Tie::File, ...

- Extensive Regression Testing:
Perl has now almost six times as many tests as in 5.6,
and the code is test built daily on several platforms

Incompatibilities

- BINARY INCOMPATIBLE:
mainly because of the PerlIO introduction, Perl 5.8 is not
binary compatible with any earlier Perl release, XS MODULES
WILL HAVE TO BE RECOMPILED!

- AIX Dynaloading:
Perl uses now AIX dynaloading, instead of the older emulated
version, to be more compatible with other applications on AIX

- 64-bit Platforms No Longer Use Perl Malloc:
the Perl malloc seems to have various problems on platforms
with 64-bit addressing, therefore the default in these cases
is to use the native malloc

- Hashing Order Changed Once Again:
the function used in the implementation of hashes was changed
to a better one once again, but your code shouldn't be expecting
any particular key ordering

- Attributes For my Now Handled At Run-Time:
the attributes for my() are now run-time, as opposed to compile time

- REF(...) instead of SCALAR(...):
to be consistent with ref()'s results, references to references
now stringify as "REF(...)"

- Unicode Model Changed (no more "use utf8", almost)
In Perl 5.6 "Unicodeness" was lexically scoped to the operations;
in Perl 5.8 "Unicodeness" is bound to the data. The only remaining
use of "use utf8" is when the Perl script itself is written in the
UTF-8 encoding of Unicode.

- VMS: Socket Extension Dynamic, IEEE fp Default on Alpha
- the Socket extension is now dynamic rather than static, which may
cause problems in really old VMS installations
- the IEEE floating point is now the default format in OpenVMS Alpha,
see README.vms for reasons and other details

Nomenclature Change

- What the "Camel III" book called an "IO discipline"
is now called an "IO layer"

Deprecations

- dump():
the functionality of the dump command is now considered obsolete

- 5.005 threads are now to be considered deprecated;
the new "interpreter threads" implementation should be used instead

- Pseudohashes:
the user-visible implementation of pseudohashes is going to be removed
and replaced with something cleaner (also, the internal implementation
will have to go since it was found to slow down the overall hash access)

- Use of tainted data in exec LIST and system LIST:
now gives a warning, but will become fatal error in a future release

- tr///C, tr///U:
the interface was found to be a mistake, pack("C0", ...) and
pack("U0", ...) can be used instead

Known Problems

- AmigaOS cannot build Perl 5.8.0

- The Compiler Suite: bytecompiling and compiling still do not work

- Lvalue subroutines: still experimental

- Interaction of local() and tie(): the exact semantics are still in flux

- Tied/Magical Array/Hash Elements Do Not Autovivify

- Self-tying arrays and hashes: currently explicitly disallowed

The forum runs fine on Perl 5.8, I am using it on my server.

I don't immediately see the connection with apache 2 and mod_perl 2, though...

Ivan
-----
Iyengar Yoga Resources / GT Plugins

They don't look new to me?

If you search the forum, I'm pretty sure there is a posting here from either Jason or Alex that states that mod_perl2 is not yet supported. It will be supported when mod_perl2 becomes stable, however.

- wil

Yeah and it was posted to backdream on June 20th ;)

What is "backdream"?

- wil

Errr the name of the user you replied to

Hi,

mod_perl2 is not yet stable, however once it is released, we do plan to support it. You should have no problems running Gossamer Forum with perl 5.8.0 though.

Cheers,

Alex
--
Gossamer Threads Inc.

New as in they are now included with perl itself I believe.

Cheers,

Alex
--
Gossamer Threads Inc.

I'm glad to see libnet in there now!

mod_perl 2 still has a long way to go to stable - the mod_perl prefork code, which is similar to the way that mod_perl 1 works, is listed as beta, but the threaded mode is still listed as alpha. I highly doubt we'll see anything this year, and probably not until the middle of next year. Of course, I'm not connected with the project at all, I'm only judging this based on the speed progress has been made with it thus far.

I've got mod_perl 1 built using Perl 5.8.0 on my system, and it works perfectly well. As for mod_perl 2, as soon as it is released (currently, it won't even compile on my system, much less run) we'll update our products as necessary to support it.

---

Jason Rhinelander
Gossamer Threads
jason@gossamer-threads.com

What kind of changes would be needed to support it?

I doubt it'll need much, but it'll probably be necessary to look for Apache2:: modules instead of Apache:: modules.

---

Jason Rhinelander
Gossamer Threads
jason@gossamer-threads.com

I read somewhere that you'll need to use ModPerl::Registry instead of Apache::Registry