5.8.0 RC1 has been released; please help testing it
In case you've missed this announcement, please help test Perl 5.8.0-RC1. The just released mod_perl-1.27 and mod_perl-1.99_02 were tested with this release and work properly on several platforms we were able to test on. Please make sure that when 5.8.0 is released it works for you (both mod_perl(s) and 3rd party Perl modules). - Forwarded message from Jarkko Hietaniemi <[EMAIL PROTECTED]> - =head1 Perl 5.8.0 Release Candidate 1 The Perl 5 developer team is pleased to announce the Release Candidate 1 of Perl 5.8.0. Please test extensively. Your help in testing the upcoming perl 5.8.0 is much appreciated. This is a source code release, not a binary release. You will need a C development environment. Please note that Perl 5.8.0 is a major new release of Perl containing many new features, enhancements to existing features and bug fixes. This version is "Release Candidate 1"; the purpose of this version is to permit and encourage the Perl community to conduct extensive testing and to report problems so that we, and the owners of affected Perl packages, have an opportunity to correct them. Because the process of testing the vast quantity of Perl software will take time, and because issues uncovered by this testing may result in further changes or corrections to Perl 5.8.0 and the various Perl packages, WE DO NOT RECOMMEND USING RELEASE CANDIDATE 1 IN A PRODUCTION ENVIRONMENT. Please wait for the final version of Perl 5.8.0 for production use. As always, you should conduct an appropriate level of testing before using any new product in your production environment. As specified in the licenses for Perl (see the files named Artistic or Copying), THIS PACKAGE IS PROVIDED WITH ABSOLUTELY NO WARRANTY. New Release Candidates will come out about weekly until we are satisfied with the results, at which point the final 5.8.0 will be released. =head1 Where To Get It The 5.8.0 RC1 is now available at http://mirrors.kernel.org/cpan/src/perl-5.8.0-RC1.tgz http://cpan.valueclick.com/src/perl-5.8.0-RC1.tgz ftp://ftp.leo.org/pub/CPAN/src/perl-5.8.0-RC1.tgz ftp://ftp.funet.fi/pub/CPAN/src/perl-5.8.0-RC1.tgz and as the CPAN mirrors catch up, in the src/ subdirectory of your nearest friendly CPAN mirror. The size of the file is 10913451 bytes and the MD5 checksum for the file is f595a07df28eb9e40d4d27281a9b37a9 perl-5.8.0-RC1.tgz This release should work in all UNIX/Linux and Microsoft environments, and in other environments which have POSIX/UNIX interfaces, such as BeOS, Cygwin, MPE/iX, NetWare, OS/2, QNX, VMS, VOS, and z/OS, and the appropriate C compilation environment. A MacOS Classic port requires a little bit more work but it should become available soon-- follow http://dev.macperl.org/ =head1 Why To Get It For the list of changes in 5.8.0 see the pod/perldelta.pod, available separately online at http://mirrors.kernel.org/cpan/doc/perldelta.pod http://cpan.valuelick.com/doc/perldelta.pod ftp://ftp.leo.org/pub/CPAN/doc/perldelta.pod ftp://ftp.funet.fi/pub/CPAN/doc/perldelta.pod (and again, eventually at all CPAN mirrors-- note, though, that these URLs are not permanent, they will be removed when the final 5.8.0 is released) The .tgz file will unpack into a directory called "perl-5.8.0-RC1". =head1 How To Do It You will configure, build, and test Perl. Below is a short summary, for the full story read the "INSTALL" file. =head2 Configuring If you are in a UNIX-like system, you can setup Perl for compilation by changing into the "perl-5.8.0-RC1" directory and issuing the following command: sh Configure -des This will simply select all the defaults for your system, INCLUDING defaulting to install in the usual location for production software. (So don't run make install if you run Configure this way!) If you are not in a UNIX-like system (say, Win32), please read the "INSTALL" file and any possible platform specific README files for further instructions, and skip the parts below that don't apply to your platform. If you want to go through Configure interactively (for example to change the default installation directories), do just sh Configure =head2 Building To build Perl issue the command make all Note that the build times can vary considerably. Perl 5.8.0 is about twice the size of 5.6.1, and some source code files are quite large, so your compiler might have hard time processing them. On a fast modern system with lots of CPU and memory the build can be a matter of ten minutes, but on slower/older/more heavily loaded systems it can take up to eight hours, while half an hour to an hour being common. =head2 Testing After the build has finished, it's time to test the build. make test Again, testing times vary a lot. Perl 5.8.0 has more than five times the tests of Perl 5.6.1. Fifteen minutes to half an hour is quite normal, but a slow system may easily take an hour o
ANNOUNCE: mod_perl-1.99_02
The URL http://perl.apache.org/dist/mod_perl-1.99_02.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.99_02.tar.gz size: 378436 bytes md5: b08c12adc1a8ae4ce7a111f8d5fe0b43 Changes since 1.99_02: pass the PATH and TZ environment variables at startup by default as 1.xx did fix ModPerl::Util::exit segv with 5.6.0 no longer support 5.7.x perl development versions added compat for Apache::Table->new various fixes to compile/run on darwin server-scope Perl{Set,Pass}Env config now propagated to %ENV at startup use SvOK(sv) instead of sv == &PL_sv_undef to detect undef values in xs [Stephen Clouse <[EMAIL PROTECTED]>] complete Apache::Util 1.x compat added Apache::MPM_IS_THREADED constant added compat function for Apache::Constants::SERVER_VERSION added Apache::Constants::export stub for compat added noop stubs for timeout functions removed from 2.0: $r->{soft,hard,reset,kill}_timeout turned on PerlOptions +GlobalRequest by default for perl-script handler unless it is explicitly turned off with PerlOptions -GlobalRequest added APR::OS::thread_current function added support for 1.x $r->subprocess_env functionality added support for $r->push_handlers(PerlHandler => ...) added support for $r->proxyreq to detect proxy requests $r->content_type($val) now calls ap_set_content_type underneath add the err_header_out() wrapper to Apache::compat + corresponding tests [Stas Bekman] fix $r->dir_config lookup of values set in the server context added Apache::REDIRECT shortcut constant various fixes for method handlers use Apache::ServerUtil in Apache::compat so Apache->server works in compat mode [Dave Rolsky <[EMAIL PROTECTED]>] add Apache::Util::unescape_uri alias to Apache::unescape_url in Apache::compat change Apache::unescape_url to return the escaped url as 1.x does disabled term coloring by default (enable with env var APACHE_TEST_COLOR=1) fix for APR::IpSubnet->new to check return status apr_ipsubnet_create enabled APR::SockAddr module turn on binmode for filehandle used in $r->send_fd get MP_{TRACE,DEBUG} Makefile.PL options working on win32 various fixes to build/run with bleedperl various fixes for win32 to get make test passing moved constuct_{url,server} methods to Apache::URI module implement Apache::URI::parse in Apache::compat give Perl*Handlers precedence over other handlers by using APR_HOOK_FIRST rather than APR_HOOK_LAST workaround bug in 5.6.1 when XSLoader loads DynaLoader, wiping out any dl handles it had been keeping track of. tidy up test to run standalone (without modperl test config) [Stas Bekman] override T_PTROBJ INPUT typemap to croak if object is not a blessed reference, to prevent possible segv from e.g. Apache::Server->process apr_lock.h is gone; disable APR::Lock for the moment enabled the Apache::Process module fix ModPerl::Util::exit to clear $@ before calling Perl_croak cut down on some build noise fix 'PerlOptions +GlobalRequest' when used within subrequests get rid of some "subroutine redefined" warnings in ModPerl::MM that show up with newer bleedperls. a few fixes for Apache::compat [Dave Rolsky <[EMAIL PROTECTED]>] --- Enjoy, -Doug
ANNOUNCE: mod_perl-1.27
The URL http://perl.apache.org/dist/mod_perl-1.27.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DO/DOUGM/mod_perl-1.27.tar.gz size: 372525 bytes md5: bd07f4f1065eb0d0a8d8004219357d8c Changes since 1.26: workaround Cwd bug in 5.8.0-RC1 that breaks apache configuration on solaris fix get_set_PVp() to properly set NULL values when passing in undef thanks to Lyle Brooks for the spot [Stephen Clouse <[EMAIL PROTECTED]>] Apache::Registry/PerlRun/RegistryNG errors are now saved in $r->notes('error-notes') [Jesse Erlbaum <[EMAIL PROTECTED]>] fix Win32 build problems with spaces in shell arguments [Randy Kobes <[EMAIL PROTECTED]>] make sure DynaLoader is loaded before XSLoader to workaround possible segv when using mod_perl as a dso with perl 5.6.1 autoset PERL_USELARGEFILES=0 if needed fix taint issues with bleedperl fix bug in modules/util test [Tatsuhiko Miyagawa <[EMAIL PROTECTED]>] Adjust the mailling list addresses 's|\@apache\.org|\@perl.apache.org|' [Stas Bekman <[EMAIL PROTECTED]>] Apache::PerlRun will now localize $SIG{__{DIE,WARN}__} thanks to Jon Coulter for the spot PERL5LIB support now properly unshifts paths into @INC rather than push [Tatsuhiko Miyagawa <[EMAIL PROTECTED]>] do not clear symbol tables within a package in perl_clear_symtab() used by directive handler extensions [Stephen Clouse <[EMAIL PROTECTED]>] properly deal with $r->status codes (e.g. redirect) in Apache::RegistryNG [Geoff Young <[EMAIL PROTECTED]>] allow $r->auth_name and $r->auth_type to be set on win32 [John Kelly <[EMAIL PROTECTED]>] fix compilation for win32 w/ apache 1.3.22+ [Randy Kobes <[EMAIL PROTECTED]>] fix multiple %LocationMatch in sections bug [Salvador Ortiz Garcia <[EMAIL PROTECTED]>] rip -D_GNU_SOURCE out of Perl 5.7.3+'s ccflags, which modperl doesn't need and apache won't compile with [Stas Bekman <[EMAIL PROTECTED]>] make sure PerlSetEnv variables are visible after first access to each child [Geoff Young <[EMAIL PROTECTED]>] workaround Apache::Constants::AUTOLOAD problem with bleedperl the first flag argument to perl cannot start with space, since perl tries to open the " -spi.bak" as a file. fix that in the win32 case. [Stas Bekman <[EMAIL PROTECTED]>] starting from perl 5.7.3 for tied filehandles, tiedscalar magic is applied to the IO slot of the GP rather than the GV itself. adjust the TIEHANDLE macro to work properly under 5.7.3+. [Charles Jardine <[EMAIL PROTECTED]>, Stas Bekman <[EMAIL PROTECTED]>] added perl_perl_merge_dir_config and array_header2avrv symbols to mod_perl.def for win32 and mod_perl.exp for aix. [Randy Kobes <[EMAIL PROTECTED]>] INSTALL.apaci: added an explanation of how perl has to be built in order to use DSO without problems (copied from the guide) based on email from Doug. [Stas Bekman <[EMAIL PROTECTED]>] warn if Perl is configured with -Duseshrplib and a libperl.so is found in a place where it should not be, example: /lib /usr/lib or /usr/local/lib fix potential segv in Apache::URI->rpath [Vyacheslav Zamyatin <[EMAIL PROTECTED]>] require URI::URL to work with newer libwww-perl allow overriding of container directive handlers using the func parameter [Geoffrey Young <[EMAIL PROTECTED]>] enable directive handler support for TAKE13 [Geoffrey Young <[EMAIL PROTECTED]>] --- Enjoy, -Doug
RE: separating C from V in MVC
> From: Rob Nagler [mailto:[EMAIL PROTECTED]] > Sent: 31 May 2002 23:48 > Models can only express meta info about the data, not the context > in which the data is rendered. Some info, like placement, is > conditional on the grouping which is chosen by the view. A layout > manager abstracts placement using meta data supplied by the model > and context supplied by the view. This is an interesting comment. We have so far tried [successfully] to keep our document object models completely independent of the rendering component, which means the same DOM can be passed to an Excel/PDF/etc component for rendering. The challenge of course is that it is much easy to render complex things in HTML than for example Excel which imposes a global tablular view where a column can only have one width for a page. Excel does however support multiple pages, but HTML doesn't [frames?]. Whilst one can rely on scroll-bars for HTML, PDF rendering requires the component to decide on wrapping or truncating to fit page widths. We relied heavily on the layout analysis that the W3 did for CSS and HTML when desiging our DOM class, and so HTML rendering is easy. As Rob mentions in one of his emails, the HTML rendering component does not actually have to calculate final layout, as this is done by the browser. Final layouts do have to be managed by some of our other rendering components - the PDF rendering component has to understand all flow, wrap, alignment, trunctation etc layout info. Your comment seems to hint that maybe the DOM should take into account the target rendering flavour eg craft a complex DOM for HTML but a simple DOM for Excel. We chose to make our rendering components all accept complex DOMs and then make their own decisions on to best render them taking into account limitations of the target format. I don't know if this was the right decision, but it has met our requirements for fast reporting development times for over a year now, and I am hoping to take it into the HTML world. I somehow feel that the MVC and MVC+template patterns described so far in the discussions go a long way towards, but do not quite reach our desired level of reusable infra. Templating is an interesting variant, but actually solves a different problem. Perhaps we are wanting too much! I can certainly see that the MVC+ template approach is simpler, and this is the strongest point in its favour. Regards Jeff
RE: separating C from V in MVC
At 21:14 01.06.2002, Jeff wrote: > > From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] > > Sent: 01 June 2002 18:10 > > To: Jeff > > > Well, as I see this, it isn't a problem. The layout manager takes > > the place of the view, as it essentially decides how things should > > be rendered. You then have two stages in your view, but the same > > techniques apply (as the 2nd stage of the view isn't really specific > > to any model or controller). > >This is my current thinking. Now that I have heard more details from >the MVC folks on the list, I will have to sit down and spend some >mental effort in assimilating MVC+template into what we currently >do, and see what sort of beast emerges. Well, as you see, MVC is more something of a way of thinking. I guess it's up to everyone to adapt it to their own needs. You decide what you think is best, but your "layout manager" idea clearly brings new light to this discussion. -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: separating C from V in MVC
> From: Barry Hoggard [mailto:[EMAIL PROTECTED]] > Sent: 01 June 2002 19:16 > I don't think the standard HTML::Template has support for formatting > numbers, dates, etc. Perrin indicated that you can extend HTML::Template in some way to accommodate this, but I am not yet sure of the details. > How do you make sure that it's done consistently in your applications? > It seems problematic to me to require the programmers to do work when a > designer wants to change the number of decimals in a page, for example. In our reporting infra we handle this by extending the number of basic data types to include things like cash value quantity interest rate market price and then set up a central store of meta-data that says xxx => cash value yyy => interest rate and then set up the extended data types cash value => '#,##0.00' quantity => '#,##0' we also allow field specific overrides zzz=> '#,###' [blank when zero] All our components use the meta-data to determine how the result should look. In Excel, quantities are rendered with both a numeric value and a picture. Excel itself handles the commify. In PDF, the rendering component has to create a commified string representation with the correct number of dps. By centralising the meta-data and having rendering components that use your meta-data, you can globally change the accuracy or presentation rules in all view formats. At present, all our folks are Perl literate, so the metadata is very easily managed in a series of Perl modules, but there is nothing stopping you from storing it in a DB, text file etc and creating a non-technical user maintenance interface. Regards Jeff
RE: separating C from V in MVC
> From: Per Einar Ellefsen [mailto:[EMAIL PROTECTED]] > Sent: 01 June 2002 18:10 > To: Jeff > Well, as I see this, it isn't a problem. The layout manager takes > the place of the view, as it essentially decides how things should > be rendered. You then have two stages in your view, but the same > techniques apply (as the 2nd stage of the view isn't really specific > to any model or controller). It is interesting to try and fit our approach into the MVC+template pattern, and I guess it comes down to where you draw the line. I think that the layout manager / creation of the document object model is not really part of a View, as a single DOM can be passed to a number of rendering components. I see it more as something the controller creates and passes to all of the Views that you want to implement. For example lets say that I want to present both a web page, and also render an Excel report in response to a single query [the page gets sent back to the requestor, the Excel gets saved into the db as a blob for later download]. I would see this happening like this: Controller: 1) creates collection of Models and model meta-data 2) creates DOM using layout hints in meta-data 3) passes DOM to HTML View and reaps the HTML rendering 4) passes DOM to Excel View and reaps the Excel rendering 5) saves the Excel rendering in the DB as a blob 6) returns the HTML view to the page requester As you can see from this outline, the controller manages the creation of the DOM outside either the HTML or Excel views. I see the Controller as also responsible for deciding what to do with the results of rendering the DOM in Excel or HTML formats - Views don't decide how their results should be distributed. In the above example, the Controller might decide to return the Excel object to the client, and save the HTML view into a cache or blob etc etc. This is my current thinking. Now that I have heard more details from the MVC folks on the list, I will have to sit down and spend some mental effort in assimilating MVC+template into what we currently do, and see what sort of beast emerges. Regards Jeff
Re: separating C from V in MVC
I forgot to ask one thing about Jesse's comments. I don't think the standard HTML::Template has support for formatting numbers, dates, etc. How do you make sure that it's done consistently in your applications? It seems problematic to me to require the programmers to do work when a designer wants to change the number of decimals in a page, for example. -- Barry Hoggard Tristan Media LLC e: [EMAIL PROTECTED] p: 212-627-1596 aim: hoggardb
RE: separating C from V in MVC
At 15:09 01.06.2002, Jeff wrote: > > From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > > Sent: 01 June 2002 00:17 > > To: Rob Nagler > > Cc: [EMAIL PROTECTED] > > > The same template? How does the layout manager help with that? > > Does it modify the template? It would make more sense to me if > > this were a sort of abstraction to factor out common layout > > ideas from multiple templates. > >The layout manager is more complex than a static template. It takes >a collection of data and meta-data and creates a document tree that >is not a specific rendering flavour - the DOM might subsequently >be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without >requiring (every page) x (every format) x (every option) templates. Well, as I see this, it isn't a problem. The layout manager takes the place of the view, as it essentially decides how things should be rendered. You then have two stages in your view, but the same techniques apply (as the 2nd stage of the view isn't really specific to any model or controller). -- Per Einar Ellefsen [EMAIL PROTECTED]
RE: separating C from V in MVC
> From: Perrin Harkins [mailto:[EMAIL PROTECTED]] > Sent: 01 June 2002 00:17 > To: Rob Nagler > Cc: [EMAIL PROTECTED] > The same template? How does the layout manager help with that? > Does it modify the template? It would make more sense to me if > this were a sort of abstraction to factor out common layout > ideas from multiple templates. The layout manager is more complex than a static template. It takes a collection of data and meta-data and creates a document tree that is not a specific rendering flavour - the DOM might subsequently be rendered in NS4.0 HTML, IE5.01+ HTML, Excel, PDF etc. without requiring (every page) x (every format) x (every option) templates. > ... > That doesn't require a layout manager though. Simple templating is > fine for that, i.e. two different templates (views). In most circumstances it is ok to have templates that are specific to one output flavour, possible with some simple alts. But what if I have 40 pages that I want to render in: IE5+HTML, NS4-HTML, Excel, HP-PCL5 and PDF - and I also want SIMPLE views of each page. This would result in 40 x 5 x 2 = 400 templates. For every change in a basic page, I have to keep 9 other templates in other languages in step. If the number of output formats and page variants is not trivial, it might make more sense to have an active component that creates the document tree, and passes it to simple components that know how to render a DOM in the desired output format. All in all, I think the MVC+template approach described is fine for most of the type of dynamic sites currently available on the web. But I work for a small ASP and we have to manage rapidly changing complex dynamic sites and complex user reporting requirements, with minimal work. We don't have any HTML specialists, but rather a few very good technical generalists. I think that for us a meta-data layout driven approach will be more effective. We do however plan to borrow all the good ideas we can find from any other model, including MVC+template. Our planned move to mod_perl is mostly due to the benefits we have seen from out Perl data processing and reporting - hence the desire to join both the web and DP infra at the hip. Regards Jeff
Re: PERL Internals access
Burton, Craig wrote: > If anyone there can give me some pointers to how to access the syntax > tree for an executing Perl program, _from within that program_, I would > be very grateful. I suspect this may not be possible. The O::Backend > system seems to require the Perl program execute with overloaded Ops > (example : Terse) and so the "normal" execution of the code is forfeited. > > I have fiddled with Devel::OpProf to get at what internal opcodes have > executed, but really want to have my perl program somehow obtain the > same large text dump created by a -MO=Terse printing, as part of my > program's execution. I don't want to call Terse over the source .pl > file either... sorry! Is something like B::Generate is what you are looking for? e.g. see: http://www.perl.com/pub/a/2002/05/07/optree.html Simon had an interesting paper in the last OSC's proceeding paper. I don't know if it's available online. It was called: B::Generate + Source Filters = use Python; In any case you probably want to move this discussion to some other perl specific list/forum, unless it has something to do with mod_perl. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
RE: separating C from V in MVC
> From: Jesse Erlbaum [mailto:[EMAIL PROTECTED]] > Sent: 30 May 2002 22:42 > To: 'Ray Zimmerman'; modperl List; Mason List Jesse, thanks for your comments, I found them very interesting. I am comfortable with Perl and Web programming (though previously not the two together) and am about to embark on development of a new product for an ASP, so have considerable interest at this stage of the proceedings. I would like to ask some further questions, please forgive the extensive haircut of your comments: > applying a design pattern such as MVC is not a panacea I agree - I much prefer Perlish DWIM dweomer >Model: The business logic. Not related to the UI at all. >View: The user interface. >Controller: The glue between the View and the Model. > ... the Model is simply a Perl module... make it entirely separate > from the user interface... the methods... being called from a web > application, a cron script, or an email-based interface Makes sense, in old-style speak [yes, I am approaching 'Ancient of Days' status] this seems to indicate the Model accepts method calls and returns data that will be rendered elsewhere. In our planned development, there is a LOT of tabular data - do you use any standards for the data being returned to the Controller? eg do you use a struct [ie hash/array Perl primitive] or do you return an object? eg a table object etc? > The View, in a web application, is really the HTML output. Sounds good, so I could also pass the Models returned data to a different flavoured rendering view eg PDF, Spreadsheet, Text etc. This sounds a lot like our existing Perl reporting infra which does exactly that. W3 did a huge amount of analysis on layout and style as part of the CSS specs. In our setup, the table objects contain lots of style info. It is easy to render complex tables in PDF [as HTML will be] but formats like Excel are very hard, as there are layout constraints [eg a column can have only one width for the entire page - we call this the 'Highlander Effect'] Is this true of your setup? does the Model returned data contain lots of style hints? Or do you leave this completely to the View layer? How does the view layer know for example to render an Error cell as RED in HTML but blue in Excel due to Excel palette limitations? > Optimally, the View avoids *ALL* application logic. - so the Model has to say RED rather than ERROR? but that wouldn't work if rendering something where RED is illegible? Our reporting knows about basic things like Error, Good, User Date / Numeric preferences etc. > At my company we use HTML::Template ... it's damn fast, too will look at this - is there a list somewhere? > The Controller connects the View to the Model... takes user input > ... translates it into method calls on the Model... then takes output > from the Model and passes it to your View. Sounds like Controller only interacts with one Model? I would assume that a Controller might collect data from a number of Models, and then pass the collection of data to a View? What controls the overall layout? e.g. what is the equivalent of the 'Grid Bag' layout manager - is this done in the Controller? and then passed to the View with all the data from a set of Models? Or do you make the Controller minimalist and have a meta-Model that assembles all the sub-Models into a layout. > CGI::Application modules will do some reading on this also then. > separating the View from Controller is a problem. I guess this is a balance between purist and DWIMism, but as we already have this separation for reporting, I would like to extend it into our dynamic web page generation. > If you have to work with an SPS such as Mason but you still want to > separate your View from your Controller, you have to work twice as hard. Interesting! Jesse, I found your posting extremely useful - thank you very much! Regards Jeff
PERL Internals access
If anyone there can give me some pointers to how to access the syntax tree for an executing Perl program, _from within that program_, I would be very grateful. I suspect this may not be possible. The O::Backend system seems to require the Perl program execute with overloaded Ops (example : Terse) and so the "normal" execution of the code is forfeited. I have fiddled with Devel::OpProf to get at what internal opcodes have executed, but really want to have my perl program somehow obtain the same large text dump created by a -MO=Terse printing, as part of my program's execution. I don't want to call Terse over the source .pl file either... sorry! #!/usr/bin/perl my $terse_dump_of_this = foo_magic_B::something; #code code code code Kind regards, Craig. ** This email is intended only for the use of the individual or entity named above and may contain information that is confidential and privileged. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this Email is strictly prohibited. When addressed to our clients, any opinions or advice contained in this Email are subject to the terms and conditions expressed in the governing KPMG client engagement letter. If you have received this Email in error, please notify us immediately by return email or telephone +61 2 93357000 and destroy the original message. Thank You. **M
Re: Video On Demand Project
At 09:20 01.06.2002, Medi Montaseri wrote: >Please let me know if I should post this to some other (more) relevant >group. I think this very little mod_perl related. I don't think it's a good idea using mod_perl for that purpose either. You should try to find a video on demand mailing list of newsgroup. There must be people who know more about these things. -- Per Einar Ellefsen [EMAIL PROTECTED]
Video On Demand Project
Hi, I am considering a Just-For-Fun Video On Demand Project and am wondering if I can jump start it by pinging your guys first. The environment is Server would be a Linux box, running Apache behind a best case 198 K SDSL line. The movie would say a training lectureimagine a garage, a white board, a camcorder and me scribilling whatever I know about Soccer So where do I go from here ? I got an old camcorder, that I can connect to my VCR or TV. If I was to connect this to my computer, would I need some kind of an adapter that speaks compsite TV signals and digitizes the analog signals and then writes the bits to a file. What are these called, Frame Grabber/Video Capture Card? How about the software for these Frame Grabbers. Recall I'm on Linux, and many of these card vendors don't know how to spell Linux... I see many file formats, which format do I use? I read something about MPEG 2 with PS and TS . How about RAM files (RealAudio) and ... I need help sorting these out... Ok...so now I have recorded something and created a file on the disk, got my web pages all setup and I'm ready to serve. So now comes invokation of some streaming server to push the content of the file out to client. I guess that would be a mod_perl or CGI, so I still need some program. What do I use for that. Can I just use HTTP to serve the file. I also read about Vido On Demand (which I think is unicast) and how bandwidth hungry it is but most appealing to clients, vs multi-casting vs broadcasting. But I think I need the Video On Demand typeso would the SDSL line do? I think that is what the streaming will solve ... rightie one does not need to have 20 Mbits/sec connection to get some work done Please let me know if I should post this to some other (more) relevant group. Thanks -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering -