We use Understand for C++ (link is to the index of all "Understand for..." family members) when reviewing and designing formal unit tests for our clients' code. It's extremely useful for manual static analysis: understanding structure and inter-relatedness, so to speak.
However, to understand dynamic behavior you should look at various tracing options, even the lowly printf(), or try stepping through in a debugger. The larger, more complex and the more object-oriented the code, the more important understanding the dynamics are.
Anyway, Understand for C++ is much more interactive than any of the free comment extraction or cross reference tools and the database has a Perl API, though we've not had a chance to use it. It's worth the price if your doing this as part of your job.
All Das Keyboard II needs is a cheat switch: press it and a red led under every key would backlight the glyph(s) for that key so you can find the euro symbol.
We use "lightweight" MDA to codegen code for limited scope portions of an overall design, like communications protocols, state machines (for UIs and embedded systems), data models, and data flow engines. We use models to generate SQL, C (dialects for 8-bit SOC through Win32,.NET and Linux), C++, C#, Perl, HTML, and XML.
We often use diagrams to design our models, but the models themselves are (to date) are written in textual forms (XML, text outlines, or custom mini-languages) rather than graphical editors. The textual forms are useful because we can use any text editor (like your favorite IDE or programmer's editor or sometimes even notepad.exe or a wiki) to maintain them anywhere. Also, it takes a lot of time to build a graphical editor and tools like Eclipse, Visio, etc. still take too long to whip up a GUI in unless you're already a guru in that tool. Implementing and tweaking ad-hoc extension in to a text-based modelling tool is also relatively easy. I'd much prefer to be able to use graphical model editors, but haven't had the time to roll our own and haven't found a tool that makes rolling our own that easy.
Tool-based MDA offers better return than raw coding does under a few conditions: (1) where the model's structure represents the solution more intuitively or concisely than source code (state machines and dataflow, for instance), (2) where the model can be used to generate repetetive code and reduce the chances of human error (all of the examples listed above), (3) where many artifacts can be created from one model, and thus kept in sync automatically, for instance in data modelling (SQL schema, SQL queries and C++/Perl/etc. wrapper codegen from 1 model, multiple endpoints of a comms channel), (4) where a team can build an MDA tool *once* and then apply it to many problems.
In some sense, you can think of item 1 in that list as being true when the model you've chosen is also one of the best ways to document the implementation.
Where codegen MDA starts to fall over is (1) when the implementation requires a number of different "one-off" solutions that can't easily and naturally be incorporated in the model (for instance, where the model is based on an early, simplistic view of how the application should behave; late-arriving requirements can clobber a model's utility), (2) where developing or installing, configuring and customizing the modelling tool is more work than writing the code (when the developer can whip up the code faster than you can install, configure and customize the modelling tools for your application), and (3) where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.
(3) doesn't prevent MDA, but it does place extra emphasis on having the model generate maintainable code so you can cut away from the modelling tool at some point.
MDA is quite useful, but like every other TLA and FLA (SOAP?, XML?, COM?, SQL?, REST?) or four letter word (Java? Perl?), you should only use it where it helps meet your needs.
Check out Cepstral, which specializes in generating very good voices with open source tools. There is a better demo form here that lets you choose a voice and a number of special effects, including accents such as French Canadian or German.
As a side note, one of its founders is Kevin Lenzo, of YAPC and Perl Foundation fame.
We had an incident where two of us modified the same OOo spreadsheet and tried to check it in to the repository (p4).
This being XML, I unzipped the two versions of the spreadsheet, ran xmllint --format on the contents file of each, did a diff, manually copied the relevant changes from one to the other and tweaked a few of the attributes that they use for run length encoding runs of cells, then re-zipped them. Not quite automatic, but pretty close!
I can't imagine how I'd have done that with Excel.
By the same token, I dare not use OOo on real Excel spreadsheets or word docs. Some of my clients and peer vendors use formatting that either renders like Mondrian spreadsheets in OOo or, when edited with OOo, causes OOo to emit.xls or.doc files that give MSOffice fits.
But we use OOo whenever possible, and it's been getting better compatibility wise with every release.
When choosing a language, choose one that does what you need. Don't choose a language because it's easy or pretty if it doesn't do what you need. Moreover, if you really are limited to a single language, you are forgoing the huge swaths of comp. sci. goodness whatever language you're limiting yourself to doesn't support.
Any competent group generally needs to be able to handle a mix of languages, from C/C++/Java, Perl/Python/Ruby/etc, and the myriad of narrow languages (SQL, templating, shell & batch, HTML, lua, etc., etc.).
Perhaps you should use C, C++ or FORTRAN for the numerical portions and native Java for the general purpose portions.
cygwin is a really nice emulation layer, but it is an emulation layer and is not 24x7 ready. The timekeeping and IPC mechnisms aren't fully reliable for production-ready use, IMHO. It is amazing for what it does.
We've been running several production PostgreSQL-on-cygwin servers and have been experiencing random corruption and poor timekeeping. There's a bug (hopefully fixed now) in cygwin timekeeping that causes a rollover after 49 days of uptime. PostgreSQL on cygwin also experiences odd table and index corruption problems that I've never seen with it on Linux/FreeBSD.
We're cutting to Oracle for business reasons, or we'd switch to the newly free Win32 PostgreSQL ASAP.
Have you considered MS' Services for Unix? We've not used it, but I'd be interested in hearing about how well it works.
Hi. First a bit about me and my firm (not a plug--we're too busy to take on random work and we're probably not in your region), then the free advice. I own an 8 person (and growing:) software engineering consultancy that does project planning and software development for new products in the embedded and distributed application spaces.
We specialize in a few different types of work for small firms and billion dollar companies. Man/machine interfaces. Medium scale (5 to 500 end points) distributed soft real time data gathering and collaborative apps. Hard real time embedded consumer and diagnostic devices. To give you some idea, over the last 10 years we've worked with x86, PIC, 8051, etc. using VxWorks, Win*, SCO, FreeBSD, Linux, PalmOS. Oracle, PostgreSQL, SQL Server dbs, C, C++, Java, Perl, etc. A wide variety.
The advice: don't try to farm the project out. Find a firm that has experience using the tools you need to have used doing the kind of work you need to have done. Make sure that their management team and engineering staff are the same ones that worked on prior, sucessful projects like yours will be, and check with their past clients to make sure they did an acceptable job.
Get a project plan from them with a detailed task breakdown (be reasonable about how detailed: don't expect them to make up tasks for things you can't yet spec clearly). Have them identify risks up front and get those tasks moved to the front of the schedule. Make sure you see clear descriptions of architecture--vague descriptions and diagrams are a good sign that they don't get it yet. Make sure you or somebody you trust technically reviews their work.
Once hired, visit them frequently throughout the process. Assuming you don't have an airtight spec, you'll want to work on site as much as you can or have them work on your site--rent space in an incubator or industrial park or even a house, but get you and them and everyone you can to work in the same physical space for a good part of each week if not full time.
You can try to get them to take equity, but sucessful firms generally avoid doing that unless you or your advisors have a really good track record, a solid bplan, etc., etc. If they're eager to take equity, then they may be starving. If they're good, that's ok, but it's often a sign of desparados.
Good luck--you've chosen a hard path, but it's a lot of fun and hopefully you'll do well at it.
Don't forget that it costs a significant amount of money to seek, hire, train, and provide benefits (medical!) for people. Usually a $60 or $80/hr rate is a loaded rate that covers the full cost of an employee. In some cases this also pays for offsite space, utilities, equipement.
It can also reflect the quality of talent--a well run consultancy may also try to identify and retain people with higher levels talent so you'll get higher bang for your buck as opposed to a warm bodies in chairs type permatemp agency.
Yeah, it's trival: use POD. And pod2man. Or any other format you want (po2html, pod2text, etc) on almost any system with Perl on it. And integrate it in to your program as online help. And usage. And and and...
There's still a dusty corner of systems design and programming that takes place on DOS: some embedded programming tools (compilers, flash burners, in circuit emulator debuggers) for some chips still work "best" on DOS.
Only now, we can use DOSEMU to run them under Linux and get the benefit of real development environment when supporting legacy apps. We can open a bash shell and use Perl, gnu make, emacs/vim, etc to drive development, then have a DOSemu / FreeDOS window to drive download and debug.
It can be quite difficult automating the Windows versions of these tools to that same level. Most of our projects use Windowes tool (running in VMware on Linux), but we did one two years ago hosted on DOSEMU and using Bytecraft's (now) excellent compiler for the PIC chips.
Best of both worlds, and many, many thanks to all the hackers that made it work so well.
It's pretty readable and the basic text output and font metrics all work. It's very easy to produce output with from Perl, so you can very rapidly prototype your reports and see what the resulting PDF contains.
You can also tweak it a bit and disable the PDF stream compression feature so you can really see what'ts going on.
There are several parts of the package that aren't complete, but I haven't needed them so far.
I for one am really glad to see MS grabbing as much OSS code as they can for implementing the more standards compliant portions of their products, if only to see them ship more stable, secure code.
I've a lot more faith in the code they grab from the *BSD trees than in their own internally generated code and, having to run WinXX a lot (my VMWare Workstation currently has 8 open machines in it and 6 of them are WinXX: WinNT (1), Win2K(4) and WinXP(1), two are RH8), I'd rather have the peace of mind.
The problem is that the development tools have indeed become too expensive. Long gone are the days where one could buy a simple 'Turbo' this or 'Visual' that compiler for $99.95.
Instead, you have to download *free* tools. And suffer the ignominy of reading man pages and using Google! That just sucks. I want to spend my $50 on TurboPascal or the old shareware C compilers you could
get back then!
- Barrie
(who still has a TurboPascal in the original shrinkwrap with the little
handwritten pricetag on it from the mom&pop computer shop that sold them in his neighborhood back in the 80s)
Apache and mod_perl are incredibly powerful but complex systems;
it's very difficultfor any one person, to keep all of the details and
possible approaches to all of the things you can do with them
in my^Wtheir head.
This book's approach helps me find tried and true approaches
to the things I need to make mod_perl do. It's far better
organized and written than the freely available documentation and
covers a range of modules (many written for the book) that do things
I used to do the hard way. It's clear, concise, and the material
is well chosen. You'll get a lot further along on your next
mod_perl project a lot faster with this book close to hand than by repeatedly scouring CPAN and the web for the modules, mail messages, and documentation
People--especially FUDchunkers--are missing the most important points:
Almost all of the most useful Perl5 code of today will be runnable by Perl6 tomorrow: the compiler will fall back to perl5 and the VM is language neutral (even moreso that.NET it would seem).
In addition to running most perl5 modules as-is, Perl6 matching rules will have a perl5 backwards compatability mode built in so you can continue using the Perl5 regular expressions you know and love from Perl, Java, and everywhere else that's adopted them as needed in Perl6 code.
Yes, Perl6 is a rewrite and introduces a lot of deep CS concepts and ew syntax, but some care is being taken to assure that most Perl5 code will be runnable as is, while people learn about the power of some of the advanced tools Perl6 will provide.
Please Don't Panic (or incite others to): the apocolypses and exegises are technical documents, they are not meant to be smooth, easy reading or to reassure today's perlers that their hard won skills will be useful. They're meant to describe what's new and different and usually why. Don't be scared by the new and different, just as with existing Perl, you should be able to adopt the powerful new concepts and syntax as you need to without having to swallow it whole or unlearn everything you already know.
Perl6 will be stunningly more powerful, expressive, and provide (optionally) the safety features required for average coders to implement large systems while letting experts use extremely powerful tools like closures, continuations, intricate pattern matching that have mostly been accessible in academic languages to this point. And it will still allow convenient scripts to be generated if that's what you need to do.
Remember folks, other languages can make shitty code smell nice, but it's still shitty code and you wouldn't want to eat^Wmaintain it.
If you like your prefork server, just build Apache 2.0 with the "prefork" MPM. Some plaftorms are not supported by it, there's a MPM specific to Win32 for instance.
Threads programming is made hard when you are communicating between the threads or when a thread goes haywire and overwrites another threads' memory regions. The former is not a large issue for most C or (especially) mod_perl Apache modules, since they don't try to share state. These should port rather easily to a multithreaded environment.
The real issue is for C modules that get a little funky with the 1.3 (or older) API: there's a *lot* new under the hood in Apache 2.0 and such modules may require a complete rewrite. Many will only require minor rewrites, though complete rewrites to leverage Apache 2.0's input and output filters will be quite beneficial. Imagine writing a filter module that can alter content retrieved by the new mod_proxy, and optionally cached locally before or after the filter alters it:).
Debugging is often more difficult with threads, but there are command line options to make it easier to debug, and there's always compiling it with the prefork MPM.
Yes, many modules and C libraries are not thread safe; this will be a source of painful problems for advanced modules for years to come. But most modules should port relatively painlessly, and many people don't go farther than those modules that ship with Apache; those, of course, are already being ported and debugged.
The prefork MPM is likely to be more safe in the face of memory bugs and deadlock issues due to the isolation imposed by the OS between processes, but is likely to be slower than the threaded MPMs on many platforms.
FWIW, mod_perl 2.0 is shaping up very nicely and perl5 seems to be resolving most of the major obstacles to full, safe multithreading in a manner that will prevent unexpected variable sharing problems (all variables are thread-local unless specified otherwise). mod_perl 2.0 boots and runs multithreaded now, and as soon as the core Perl interpreter becomes more threadsafe, it should be ready for trial use.
At least one mod_perl production site has been tested on mod_perl 2.0 (though not in production:). mod_perl 2.0 has a compatability layer that will help existing modules run with little or no modification.
Life's looking good for Apache 2.0 and mod_perl 2.0.
I used Andrew workstations back in the mid 80's,
as did many here, I'm sure, and was about to
write a comment here to that effect: its
implementation of tiled windows did suck, and
now that more and more apps are multi-windowed,
it would suck even more. Don't know if Ion's
more usable (which is likely), but I think the
tiled-only paradigm is too limited for general
purpose use.
If tiled windows were so great, then a great
majority of people would
have reflexively hit the tiling layout desktop cleanup functions available on various versions of MS Windows and in various X Window managers.
But they don't.
Slashdot Mirror
We use Understand for C++ (link is to the index of all "Understand for..." family members) when reviewing and designing formal unit tests for our clients' code. It's extremely useful for manual static analysis: understanding structure and inter-relatedness, so to speak.
However, to understand dynamic behavior you should look at various tracing options, even the lowly printf(), or try stepping through in a debugger. The larger, more complex and the more object-oriented the code, the more important understanding the dynamics are.
Anyway, Understand for C++ is much more interactive than any of the free comment extraction or cross reference tools and the database has a Perl API, though we've not had a chance to use it. It's worth the price if your doing this as part of your job.
- BarrieAll Das Keyboard II needs is a cheat switch: press it and a red led under every key would backlight the glyph(s) for that key so you can find the euro symbol.
- Barrie
We use "lightweight" MDA to codegen code for limited scope portions of an overall design, like communications protocols, state machines (for UIs and embedded systems), data models, and data flow engines. We use models to generate SQL, C (dialects for 8-bit SOC through Win32, .NET and Linux), C++, C#, Perl, HTML, and XML.
We often use diagrams to design our models, but the models themselves are (to date) are written in textual forms (XML, text outlines, or custom mini-languages) rather than graphical editors. The textual forms are useful because we can use any text editor (like your favorite IDE or programmer's editor or sometimes even notepad.exe or a wiki) to maintain them anywhere. Also, it takes a lot of time to build a graphical editor and tools like Eclipse, Visio, etc. still take too long to whip up a GUI in unless you're already a guru in that tool. Implementing and tweaking ad-hoc extension in to a text-based modelling tool is also relatively easy. I'd much prefer to be able to use graphical model editors, but haven't had the time to roll our own and haven't found a tool that makes rolling our own that easy.
Tool-based MDA offers better return than raw coding does under a few conditions: (1) where the model's structure represents the solution more intuitively or concisely than source code (state machines and dataflow, for instance), (2) where the model can be used to generate repetetive code and reduce the chances of human error (all of the examples listed above), (3) where many artifacts can be created from one model, and thus kept in sync automatically, for instance in data modelling (SQL schema, SQL queries and C++/Perl/etc. wrapper codegen from 1 model, multiple endpoints of a comms channel), (4) where a team can build an MDA tool *once* and then apply it to many problems.
In some sense, you can think of item 1 in that list as being true when the model you've chosen is also one of the best ways to document the implementation.
Where codegen MDA starts to fall over is (1) when the implementation requires a number of different "one-off" solutions that can't easily and naturally be incorporated in the model (for instance, where the model is based on an early, simplistic view of how the application should behave; late-arriving requirements can clobber a model's utility), (2) where developing or installing, configuring and customizing the modelling tool is more work than writing the code (when the developer can whip up the code faster than you can install, configure and customize the modelling tools for your application), and (3) where you need to spend extra effort installing and describing the modelling tools for downstream maintenance organizations.
(3) doesn't prevent MDA, but it does place extra emphasis on having the model generate maintainable code so you can cut away from the modelling tool at some point.
MDA is quite useful, but like every other TLA and FLA (SOAP?, XML?, COM?, SQL?, REST?) or four letter word (Java? Perl?), you should only use it where it helps meet your needs.
- Barrie
As a side note, one of its founders is Kevin Lenzo, of YAPC and Perl Foundation fame.
- Barrie
We had an incident where two of us modified the same OOo spreadsheet and tried to check it in to the repository (p4).
This being XML, I unzipped the two versions of the spreadsheet, ran xmllint --format on the contents file of each, did a diff, manually copied the relevant changes from one to the other and tweaked a few of the attributes that they use for run length encoding runs of cells, then re-zipped them. Not quite automatic, but pretty close!
I can't imagine how I'd have done that with Excel.
By the same token, I dare not use OOo on real Excel spreadsheets or word docs. Some of my clients and peer vendors use formatting that either renders like Mondrian spreadsheets in OOo or, when edited with OOo, causes OOo to emit .xls or .doc files that give MSOffice fits.
But we use OOo whenever possible, and it's been getting better compatibility wise with every release.
- Barrie
When choosing a language, choose one that does what you need. Don't choose a language because it's easy or pretty if it doesn't do what you need. Moreover, if you really are limited to a single language, you are forgoing the huge swaths of comp. sci. goodness whatever language you're limiting yourself to doesn't support.
Any competent group generally needs to be able to handle a mix of languages, from C/C++/Java, Perl/Python/Ruby/etc, and the myriad of narrow languages (SQL, templating, shell & batch, HTML, lua, etc., etc.).
Perhaps you should use C, C++ or FORTRAN for the numerical portions and native Java for the general purpose portions.
- Barrie
cygwin is a really nice emulation layer, but it is an emulation layer and is not 24x7 ready. The timekeeping and IPC mechnisms aren't fully reliable for production-ready use, IMHO. It is amazing for what it does.
We've been running several production PostgreSQL-on-cygwin servers and have been experiencing random corruption and poor timekeeping. There's a bug (hopefully fixed now) in cygwin timekeeping that causes a rollover after 49 days of uptime. PostgreSQL on cygwin also experiences odd table and index corruption problems that I've never seen with it on Linux/FreeBSD.
We're cutting to Oracle for business reasons, or we'd switch to the newly free Win32 PostgreSQL ASAP.
Have you considered MS' Services for Unix? We've not used it, but I'd be interested in hearing about how well it works.
- Barrie
Hi. First a bit about me and my firm (not a plug--we're too busy to take on random work and we're probably not in your region), then the free advice. I own an 8 person (and growing :) software engineering consultancy that does project planning and software development for new products in the embedded and distributed application spaces.
We specialize in a few different types of work for small firms and billion dollar companies. Man/machine interfaces. Medium scale (5 to 500 end points) distributed soft real time data gathering and collaborative apps. Hard real time embedded consumer and diagnostic devices. To give you some idea, over the last 10 years we've worked with x86, PIC, 8051, etc. using VxWorks, Win*, SCO, FreeBSD, Linux, PalmOS. Oracle, PostgreSQL, SQL Server dbs, C, C++, Java, Perl, etc. A wide variety.
The advice: don't try to farm the project out. Find a firm that has experience using the tools you need to have used doing the kind of work you need to have done. Make sure that their management team and engineering staff are the same ones that worked on prior, sucessful projects like yours will be, and check with their past clients to make sure they did an acceptable job.
Get a project plan from them with a detailed task breakdown (be reasonable about how detailed: don't expect them to make up tasks for things you can't yet spec clearly). Have them identify risks up front and get those tasks moved to the front of the schedule. Make sure you see clear descriptions of architecture--vague descriptions and diagrams are a good sign that they don't get it yet. Make sure you or somebody you trust technically reviews their work.
Once hired, visit them frequently throughout the process. Assuming you don't have an airtight spec, you'll want to work on site as much as you can or have them work on your site--rent space in an incubator or industrial park or even a house, but get you and them and everyone you can to work in the same physical space for a good part of each week if not full time.
You can try to get them to take equity, but sucessful firms generally avoid doing that unless you or your advisors have a really good track record, a solid bplan, etc., etc. If they're eager to take equity, then they may be starving. If they're good, that's ok, but it's often a sign of desparados.
Good luck--you've chosen a hard path, but it's a lot of fun and hopefully you'll do well at it.
- Barrie
Learn 5 now. 6 will run 5 and 6 will be done when it's done, 5 is useful today.
- Barrie
Don't forget that it costs a significant amount of money to seek, hire, train, and provide benefits (medical!) for people. Usually a $60 or $80/hr rate is a loaded rate that covers the full cost of an employee. In some cases this also pays for offsite space, utilities, equipement.
It can also reflect the quality of talent--a well run consultancy may also try to identify and retain people with higher levels talent so you'll get higher bang for your buck as opposed to a warm bodies in chairs type permatemp agency.
- Barrie
Use the right tool, don't let the wrong tool use you.
- Barrie
There's still a dusty corner of systems design and programming that takes place on DOS: some embedded programming tools (compilers, flash burners, in circuit emulator debuggers) for some chips still work "best" on DOS.
Only now, we can use DOSEMU to run them under Linux and get the benefit of real development environment when supporting legacy apps. We can open a bash shell and use Perl, gnu make, emacs/vim, etc to drive development, then have a DOSemu / FreeDOS window to drive download and debug.
It can be quite difficult automating the Windows versions of these tools to that same level. Most of our projects use Windowes tool (running in VMware on Linux), but we did one two years ago hosted on DOSEMU and using Bytecraft's (now) excellent compiler for the PIC chips.
Best of both worlds, and many, many thanks to all the hackers that made it work so well.
- Barrie
That seems far too cheap. Can you buy wiretaps in bulk?
'scuse me maam, where are your wiretaps?
Aisle three, right next to the pinhole cameras and poison darts.
http://search.cpan.org/~areibens/PDF-API2-0.3r77/M ANIFEST
It's pretty readable and the basic text output and font metrics all work. It's very easy to produce output with from Perl, so you can very rapidly prototype your reports and see what the resulting PDF contains.
You can also tweak it a bit and disable the PDF stream compression feature so you can really see what'ts going on.
There are several parts of the package that aren't complete, but I haven't needed them so far.
- Barrie
I for one am really glad to see MS grabbing as much OSS code as they can for implementing the more standards compliant portions of their products, if only to see them ship more stable, secure code.
I've a lot more faith in the code they grab from the *BSD trees than in their own internally generated code and, having to run WinXX a lot (my VMWare Workstation currently has 8 open machines in it and 6 of them are WinXX: WinNT (1), Win2K(4) and WinXP(1), two are RH8), I'd rather have the peace of mind.
- Barrie
- Barrie
Instead, you have to download *free* tools. And suffer the ignominy of reading man pages and using Google! That just sucks. I want to spend my $50 on TurboPascal or the old shareware C compilers you could get back then!
- Barrie
(who still has a TurboPascal in the original shrinkwrap with the little handwritten pricetag on it from the mom&pop computer shop that sold them in his neighborhood back in the 80s)
This book's approach helps me find tried and true approaches to the things I need to make mod_perl do. It's far better organized and written than the freely available documentation and covers a range of modules (many written for the book) that do things I used to do the hard way. It's clear, concise, and the material is well chosen. You'll get a lot further along on your next mod_perl project a lot faster with this book close to hand than by repeatedly scouring CPAN and the web for the modules, mail messages, and documentation
Yours in mod_perl,
Barrie
People--especially FUDchunkers--are missing the most important points:
.NET it would seem).
Almost all of the most useful Perl5 code of today will be runnable by Perl6 tomorrow: the compiler will fall back to perl5 and the VM is language neutral (even moreso that
In addition to running most perl5 modules as-is, Perl6 matching rules will have a perl5 backwards compatability mode built in so you can continue using the Perl5 regular expressions you know and love from Perl, Java, and everywhere else that's adopted them as needed in Perl6 code.
Yes, Perl6 is a rewrite and introduces a lot of deep CS concepts and ew syntax, but some care is being taken to assure that most Perl5 code will be runnable as is, while people learn about the power of some of the advanced tools Perl6 will provide.
Please Don't Panic (or incite others to): the apocolypses and exegises are technical documents, they are not meant to be smooth, easy reading or to reassure today's perlers that their hard won skills will be useful. They're meant to describe what's new and different and usually why. Don't be scared by the new and different, just as with existing Perl, you should be able to adopt the powerful new concepts and syntax as you need to without having to swallow it whole or unlearn everything you already know.
Perl6 will be stunningly more powerful, expressive, and provide (optionally) the safety features required for average coders to implement large systems while letting experts use extremely powerful tools like closures, continuations, intricate pattern matching that have mostly been accessible in academic languages to this point. And it will still allow convenient scripts to be generated if that's what you need to do.
Remember folks, other languages can make shitty code smell nice, but it's still shitty code and you wouldn't want to eat^Wmaintain it.
- Barrie
We just need to seed kudzu in all the oasis we can find in the world's deserts. In 2,000 years the planet would be a rainforest.
Now, how long until the music publishing conglomerates "get it"?
- Barrie
If you like your prefork server, just build Apache 2.0 with the "prefork" MPM. Some plaftorms are not supported by it, there's a MPM specific to Win32 for instance.
:).
:). mod_perl 2.0 has a compatability layer that will help existing modules run with little or no modification.
Threads programming is made hard when you are communicating between the threads or when a thread goes haywire and overwrites another threads' memory regions. The former is not a large issue for most C or (especially) mod_perl Apache modules, since they don't try to share state. These should port rather easily to a multithreaded environment.
The real issue is for C modules that get a little funky with the 1.3 (or older) API: there's a *lot* new under the hood in Apache 2.0 and such modules may require a complete rewrite. Many will only require minor rewrites, though complete rewrites to leverage Apache 2.0's input and output filters will be quite beneficial. Imagine writing a filter module that can alter content retrieved by the new mod_proxy, and optionally cached locally before or after the filter alters it
Debugging is often more difficult with threads, but there are command line options to make it easier to debug, and there's always compiling it with the prefork MPM.
Yes, many modules and C libraries are not thread safe; this will be a source of painful problems for advanced modules for years to come. But most modules should port relatively painlessly, and many people don't go farther than those modules that ship with Apache; those, of course, are already being ported and debugged.
The prefork MPM is likely to be more safe in the face of memory bugs and deadlock issues due to the isolation imposed by the OS between processes, but is likely to be slower than the threaded MPMs on many platforms.
FWIW, mod_perl 2.0 is shaping up very nicely and perl5 seems to be resolving most of the major obstacles to full, safe multithreading in a manner that will prevent unexpected variable sharing problems (all variables are thread-local unless specified otherwise). mod_perl 2.0 boots and runs multithreaded now, and as soon as the core Perl interpreter becomes more threadsafe, it should be ready for trial use.
At least one mod_perl production site has been tested on mod_perl 2.0 (though not in production
Life's looking good for Apache 2.0 and mod_perl 2.0.
I used Andrew workstations back in the mid 80's,
as did many here, I'm sure, and was about to
write a comment here to that effect: its
implementation of tiled windows did suck, and
now that more and more apps are multi-windowed,
it would suck even more. Don't know if Ion's
more usable (which is likely), but I think the
tiled-only paradigm is too limited for general
purpose use.
If tiled windows were so great, then a great
majority of people would
have reflexively hit the tiling layout desktop cleanup functions available on various versions of MS Windows and in various X Window managers.
But they don't.
My guess is that anyone that would be watching the cameras are too busy trying to look down someones shirt or sleeping on the job.
Seems like the cameras' images should be available (perhaps after a delay) on the 'net. Let netizens watch the watchmen.