Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

Re: Perl modules (was: Re: Begginer's question: ...)

by haukex (Archbishop)
on Jan 19, 2017 at 14:08 UTC ( [id://1179915]=note: print w/replies, xml ) Need Help??


in reply to Perl modules, was: Re^11: Begginer's question: If loops one after the other. Is that code correct?
in thread Begginer's question: If loops one after the other. Is that code correct?

Hi predrag,

I've partially changed the title of this node but am not sure if that is ok?

Yes, changing the node title is ok, in this node I've also made a change to the title to shorten it a bit. See also How do I compose an effective node title? Note that if threads go too far off-topic, or if there are follow-up questions that are not directly related to the original question, often it's better to start a new thread (a good example being your question of how to specify which Perl version to use, which I've answered below).

I would like to learn CGI scripting later this year and it is very useful for me to know that CGI module is not more recommended.

Yes, there are several more modern web frameworks now: Plack, Catalyst, Dancer, Dancer2, and Mojolicious (all of these implement the new PSGI specification). All of these are good, in my personal opinion I like Mojolicious. Here is a tutorial for getting started with Mojolicious::Lite.

... separate Perl installations. Then, in scripts, I should address the version I want to use?

A typical set-up would be to have the system Perl in a location like /usr/bin/perl, and to have one or more other Perl installations in e.g. ~/perl5/perlbrew (when using perlbrew). However, I normally* wouldn't recommend changing the shebang line ("#!/usr/bin/perl") to a specific installation, because that will likely not work when the scripts are copied to other machines.

Instead, one would ensure that the environment variable PATH is pointing to the desired Perl installation (such as with "perlbrew switch perl-5.24.1", can be checked with the command "which perl"), and then in your scripts the shebang line "#!/usr/bin/env perl" will cause the perl currently in your PATH to be used. Changing the PATH to select a Perl installation also has the advantage that a command like cpan Module::Name will install to the selected Perl installation.

Also, in your Perl scripts you can specify a minimum required Perl version with e.g. use 5.024; for Perl v5.24 (this has the advantage that the new default features of that Perl version are enabled). Is is uncommon and usually not necessary to specify "use exactly this version of Perl".

* However, the aforementioned advice about the shebang line can change in the case of scripts uploaded to a server that you do not have control over. Some webhosts limit their customer's ability to use custom Perl versions, instead providing one or more Perl installations themselves, such as /usr/local/bin/perl5.16 or /opt/perl5.20/bin/perl. In such cases, it might be necessary for you to change the shebang line to point to a specific installation of Perl.

for the server, is it recommended to have just that so demanding module or work with some others?

1nickt and hippo already discussed some of the pros and cons of this. The number of modules you have installed on a machine won't make a difference, only the modules your script uses will make a difference in the start-up time of the script. Traditional CGI scripts would get re-executed on every request to the web server, so start-up times on CGI scripts would make a difference, especially if they get many requests per minute. There are however more modern web servers in which the scripts keep running between requests, in which case the start-up times do not matter. Of course, if this is just a small web page on which you don't expect many requests, start-up times of the scripts may not matter much at all. Otherwise, it would be wise to consider ways to optimize, such as using one of the more modern implementations that keep the scripts running. Another approach might be to not re-generate the charts on every request, instead keeping them cached and only re-generating them when necessary, such as based on an interval or when the data changes.

I would also ask You, if it is ok to sometimes send You a personal message, when I am not sure whether my reply to your post is interesting to others or not?

Personal messages are ok, but note that they are limited in length. In general, anything related to Perl (including web interfaces with Perl) is on-topic here, so it is of interest :-) Posting publicly also means more people can learn from the discussions.

Regards,
-- Hauke D

Replies are listed 'Best First'.
Re^2: Perl modules (was: Re: Begginer's question: ...)
by predrag (Scribe) on Jan 19, 2017 at 19:44 UTC

    Hauke D, lnickt and hippo, thanks a lot to All.

    The reason why I've asked the opinion about Chart::Clicker wasn't about space on the server but closer to the reasons that hippo mentioned. lnickt also mentioned the problem of loading too many modules. Regarding memory, I think there will be enough on the server (at least 1GB and later maybe 2GB).

    The additional reason for my question was because I would like to have something optimal, that is, for example not too large or too complex without reasons. I simply have no sense now of what is optimal and what is not for plotting Perl graphs, but lnickt made a comment that helped me to see that:

    It's difficult to imagine a solution producing high quality graphs from a system graphics library

    Of course, I understood later that having such nice graphs requires some additional "costs".

    Now, I have installed two modules for graphs: GD::Graph and Chart::Clicker. The first one requires ImageMagic and I have it installed, and the second requires Moose, and it is installed as a dependence. I don't know if some other modules can be recommended for graphs, I know for GIFgraph too. From your comments I understand that Moose will be very useful for me in the future, for more advanced use of Perl.

    Examples I've tried for both modules work and I must say I prefer graphs by Chart::Clicker.

    Hauke D thanks for the help about posting on perlmonks etc. I 've already read different FAQs but obviously need some additional time to be more familiar with all that. I see discussions can quickly go out of topic, so one need to think in advance while choosing the right title, or change title often. Thanks for the explanations about Perl installations too, and I believe it will become clearer when I start to use perlbrew. Today, I've looked at different Perl directories a little and found many modules and other files and directories.

    Hauke D Your explanations about CGI scripting are very useful for me but it is probably out of this topic (OT), so I should start a separate topic, but it is maybe too early, because I didn't step in CGI yet. Anyway, I will remember what you wrote

    I dream about one big project for my website for very long time (much older then that idea of converting Latin letters into Cyrillic). During the time, depending ot my knowledge, experience and conditions I went through different phases about how to realize that project.

    Now, with Perl things appear in a completely different light. I am thinking of sending a post on perlmonks about that but maybe I should wait till I begin with the work and first results. On the other side general comments will probably be more useful for me. The right thing is maybe in the middle.

Re^2: Perl modules (was: Re: Begginer's question: ...)
by predrag (Scribe) on Jan 20, 2017 at 09:20 UTC

    Hauke D I was thinking again about your post and hope that it is not a mistake to reply to your comments, even if we maybe go a little out of the topic.

    Traditional CGI scripts would get re-executed on every request to the web server, so start-up times on CGI scripts would make a difference, especially if they get many requests per minute. There are however more modern web servers in which the scripts keep running between requests, in which case the start-up times do not matter. Of course, if this is just a small web page on which you don't expect many requests, start-up times of the scripts may not matter much at all. Otherwise, it would be wise to consider ways to optimize, such as using one of the more modern implementations that keep the scripts running. Another approach might be to not re-generate the charts on every request, instead keeping them cached and only re-generating them when necessary, such as based on an interval or when the data changes.

    During last year, my website had about 400-1000 daily visits and with the new design and much of new content I expect more visits in the future. So, I should have all that in mind while working on my CGI scripts.

    I would like to realize web monitoring on my website, with data about bee hive weight, weather etc. It would be ideal if some or all of these data are presented visually, so this is why I asked a question about modules for plotting in Perl.

    From your comment I see that maybe your last suggestion is most appropriate for me ( not re-generate the charts on every request) because in the simpler version, data would changes probably two times a day. Pages with these data will be very attractive to visitors, so it can significantly increase web traffic.

    Anyway, when I have some results, I will ask perlmonks for comments

    regards

    predrag

      Hi predrag,

      data would changes probably two times a day

      One way to do this would be with a cron job calling a Perl script that generates the charts twice a day and saves them as image files. Then, the web server would only have to serve up static files, without the need of calling a CGI script to get the images.

      Regards,
      -- Hauke D

        One way to do this would be with a cron job calling a Perl script that generates the charts twice a day and saves them as image files. Then, the web server would only have to serve up static files, without the need of calling a CGI script to get the images.

        Hauke D, thank you for that new suggestion, I didn't think that way.

        So, all these images with that chart should be saved under the same file name. And that image file will be inserted in html page. When data change, new image will be saved and automatically will become visible in html page after page refreshing or a new visiting? Did I understood well?

        It is really extremely simple. The only con is that it can't show data in a table. But really excellent solution and I can use it for that project or something else.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1179915]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (None)
    As of 2024-04-25 00:55 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      No recent polls found