Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Cool Uses for Perl

( #1044=superdoc: print w/ replies, xml ) Need Help??

This section is the place to post your general code offerings.

CUFP's
Commodore disk image processor thingy
5 direct replies — Read more / Contribute
by rje
on Sep 01, 2014 at 19:57
    Dear Perlmonks,

    I wrote a Perl library, and I think it's pretty cool, but I'm also asking your opinions about it - is it worth putting on CPAN, for instance.

    It is a pure-Perl library for handing Commodore disk images. For those needing a refresher, these are digital images of diskettes and hard disks used by Commodore computers in the late 1970s thru the 1980s.

    It's hosted inside my network, behind my modem's firewall, by my Raspberry Pi running a cheapo web server I wrote (also in Perl) specifically for the purpose of serving and manipulating Commodore disk images.

    My library handles D64, D71, D81, D67, D80, D82, and X64 image types. Each format is a little package (about 8k) with data specific to that image. I made them packages, although I could have just used parametric data. These packages are essentially parametric data anyhow, and provide context to a generic engine that knows how Commodore disk images work.

    The library is 140k (includes good POD documentation, which is rare for me) split among about 20 files.

    First, is it worth posting to CPAN. It's awfully specialized. Maybe it would be better just to post it as a tarball on a website (or github?).

    Second, it's been nearly 10 years since I've uploaded to CPAN, and I am intimidated by the process. Yes, I've read the rules, but I'm concerned about uploading 20 related files in one batch. Anyone have any advice beyond what PAUSE has to say?

    Thanks for listening.

Duct taping spam-bot protection to a web forum
1 direct reply — Read more / Contribute
by aitap
on Aug 31, 2014 at 10:24

    There is a free web hosting which offers a third-level domain name and an installation of their proprietary CMS. It is somewhat widely known in the ex-USSR countries. They have "Web 2.0" AJAX interface, a lot of modules for nearly everything, from a simple forum to a web shop, and a primitive read-only API. I happen to be moderating one of such forums. Despite not being popular in terms of human population it has recently gained a lot of popularity among spam-sending robots.

    At first they all were making the same mistake of posting messages with titles equal to their nicknames, and so the first version of bothunter.pl was born. It employed link parsing routines of WWW::Mechanize and reproduced a sniffed AJAX request by some black magic of parsing JavaScript source for variables. Needless to say, soon it broke, both because JavaScript source slightly changed and because bots became slightly smarter, so the moderators went back to deleting bots manually.

    Yesterday I thought: with PhantomJS, I could mimic the browser and click all these AJAX buttons required to ban a user. As for the spam, maybe it's possible to count unique words in a message and warn if some of them is repeated a lot, and a list of stop-words could help, too... Before I started thinking of ways to automatically build a list of stop words from spam messages I realised that I was reiventing the wheel and searched for spam detection engines.

    My first try was Mail::SpamAssassin, because it's written in Perl and I heard a lot of stories about plugging it into other programs. It turned out to be not so easy to make it work with plain text (non-mail) messages, so I searched for alternatives. It is Mail::SpamAssassin, after all. Bogofilter is not written in Perl, but still was easy to plug in my program, thanks to its -T option, and it happily works with plain text without complaining.

    Interfacing with the site was not so easy. Banning a spam robot (click-click-tab-tab-"spam robot"-tab-space-tab-space) exploded into a mess of ->clicking xpath-found elements; at one time the site refused to register my click no matter how I tried, so I had to call the corresponding JS function manually; in the other place of program I find myself logged out, and the only way to get back in is to load the page I'm going to delete, load the login page, log in, then load the to-be-deleted page again. Kludges. Ew.

    So, here it is: the second version of bot hunter Perl program. I hope it won't break as fast as the first one. Or, at least, will be easier to fix.

LED blinking Morse code from Raspberry Pi
4 direct replies — Read more / Contribute
by rje
on Aug 30, 2014 at 11:23
    With the handy Device::BCM2835 package, I tossed together this little package so I could send "morse code" out on an LED I connected to GPIO Pins #5 and #7.

    (FYI: the Raspberry Pi can run a number of Linux systems, all with Perl. I wrote a tiny HTTP server on it which lets me create and serve Commodore disk images, also allowing me to extract and inject files, in Perl of course. It runs behind my firewall...)

'bld' project - signature(SHA1) based replacement for 'make'
4 direct replies — Read more / Contribute
by rahogaboom
on Aug 22, 2014 at 15:14
    NAME bld VERSION bld version 1.0.6 USAGE usage: bld [-hc] -h - this message.(exit) -c - The -c option will create, at the end of a bld run, a bld.ch +g file with all files and their old/new signatures that have been added/deleted/changed. Successive runs will +append to this file with a time stamp. ARGUMENTS None OPTIONS bld [-hc] -h - help message(exit) -c - The -c option will create, at the end of a bld run, a bld.chg fi +le with all files and their old/new signatures that have been added/deleted/changed. Successive runs will appe +nd to this file with a time stamp. ENVIRONMENT VARIABLES None RC CONFIGURATION FILES For defining perl variables in the Bld file EVAL section. Should be +valid perl code. Syntax errors will be reported. $ENV{HOME}/.bldrc - user bld run cmd file .bldrc - local bld run cmd file DESCRIPTION bld(1.0.6) is a simple flexible non-hierarchical program that builds +a single C/C++/Objective C /Objective C++/Assembler target(executable or library(static or share +d)) and, unlike 'make', uses SHA1 signatures(no dates) for building software and GNU cpp for autom +atic header file dependency checking. The operation of bld depends entirely on the construction +of the Bld(bld specification) and Bld.gv(bld global values) files. See the bld.README file. There + are no cmd line arguments. A bld.rm program is provided to clean up the main bld directory. bld is based upon taking the SHA1 signature of anything that, when ch +anged, would require a re-build of the executable/library. It is not, like 'make', based in + any way on dates. This means that source or header files may be moved about, and if the file +s do not change then nothing needs to, or will, be re-built. bld is not hierarchical; all + of the information to re-build the executable is contained in the Bld(and Bld.gv) file. Bl +d can descend recursively to pick up and build source, however, the specification for this is s +till in the Bld file at the top of the source tree. Complex multi-target projects are built with the use of a Bld.<projec +t> (Bld files and target bld output files) directory, bld.<project>(project source) directory, + bld.<project>(target construction) script, bld.<project>.rm(target and bld.<info|warn|fata +l>.<target> file removal) script, Bld.<project>.gv(project global values) file, bld.<project>.i +nstall(target and file install) script and bld.<project>.README(project specific documentati +on) file. Current example projects: git - the git project http://git-scm.com/ svn - the subversion project http://subversion.apache.org/ systemd - the systemd project http://www.freedesktop.org/wiki/Sof +tware/systemd/ example - misc examples intended to show how to create Bld and Bl +d.gv files To understand the bld'ing of a single target the following should be +understood: ~/bld directory files: bld - the bld perl script bld.rm - script to clean the bld directory bld.README - for first point of contact quick start Bld - the bld file which controls bld and the construction + of a target Bld.gv - the file of global values imported into the Bld file (unusually used only for multi-target builds) Bld.sig - the signature(SHA1) file created from the Bld file bld.info - information about the bld bld.warn - warnings from the bld bld.fatal - the fatal msg that ended the bld The Bld file(and Bld.gv) controls the entire target bld. The Bld fil +e is divided into three sections - Comments, EVAL and DIRS: ################################################## Comments - Add comments before the EVAL line EVAL # add perl variables to be used in the DIRS section 'dir' or {cmds} p +arts. six are mandatory. $PROJECT = "git"; $CC = "clang"; $INCDIR = "test/include"; # optional variables e.g. $CCOPT = "-O"; # mandatory defined variables # the target to build e.g. executable, libx.a, libx.so $bld="exec-c"; # cmd used in perl system() call to build $bld target - requires +'$bld'(target) and '$O'(object files) internally $bldcmd = "$CC $INCDIR -lm -o \$bld \$O"; # space separated list of directories to search for libraries $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" or "nos +ystem") $opt_s = "system"; # inform about any files that will require re-building, but do no +t rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("nolibcheck", "libcheck", " +warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; DIRS # '{cmds}' cmd blocks e.g. {ls;pwd;date;} # or # '[R] dir:regex:{cmds}' specifications e.g. bld.$PROJECT/git-2.3.0/: +^zlib\.c$:{gcc $INCDIR -o zlib.o $s} # see examples below in 'Bld FILE FORMAT AND EXAMPLES'. both 'dir' a +nd '{cmds}' fields below may have EVAL # defined variables interpolated into them. {cmds} [R] dir:regex:{cmds} {cmds} [R] dir:regex:{cmds} [R] dir:regex:{cmds} ... ... ################################################## The Bld file has three sections, a starting comments section to docum +ent the Bld, an EVAL section to define variables(and Bld.gv defined variables read in at t +he beginning of the EVAL section) for interpolation into DIRS section 'dir' and '{cmds}' +fields and a DIRS section that defines either {cmd} blocks or '[R] dir:regex:{cmds}' sp +ecifications. The entire EVAL section is eval{}'ed in bld. Any errors will terminate t +he run. There are six mandatory variables(see above). The {cmd} blocks just execute a g +roup of shell cmds. The '[R] dir:regex:{cmds}' specifications are used to build source, l +ocated in directories below the bld directory. These specifications are composed of three f +ields: [R] dir - a directory with possibly variables to be interpolated +and [R] if a recursive search for source is to be made. regex - a perl regular expression to match sources to be built +by the {cmds} field. if [R] is specified then this same regex will be applied t +o every directory recursively searched. the same {cmds} are applied to e +very source found. {cmds} - a group of cmds to construct all the source files selec +ted by the regex field. {cmds} will be executed successively for each source ma +tched. the cmds should have at least one '$s' variable specified. each of the + matched source files will be substituted for '$s'. Rebuilds will happen if: 1. a source file is new or has changed 2. the corresponding object file is missing or has changed 3. the command that is used to compile the source has changed 4. a dependent header file has been added/deleted or changed 5. the command to link the executable or build the library archiv +e has changed 6. the executable or library has changed or is missing The execution of bld will produce four files: Bld.sig The Bld.sig file, holds the source/object/header/executable/l +ibrary file names and corresponding signatures and build cmd signatures used to det +ermine if a source should be re-built. System header files and libraries may optionall +y be included. bld.info Contains detailed information about the the stages of the bui +ld. 1. date/time, OS version, compiler version, cpp version etc. 2. comments section of Bld file 3. EVAL section expansion of $bld, $bldcmd and $lib_dirs mand +atory variables($O is object files) 4. Bld file DIRS section specification lines with irrelevant +white space compressed out 5. R recursively expanded and numbered DIRS section specifica +tion lines 6. a. DIRS section specification lines b. variable interpolated(except for $s) specification +line cmd field c. matching compilation unit source file(s) d. source file header dependencies 7. EVAL section expansion of defined variables used in DIRS s +ection cmd fields 8. List of all build - System headers(full path) User headers(relative path) System libraries(full path) User libraries(relative path) Source files(relative path) Build target(bld directory) bld.warn Warnings about the build e.g. multiple copies of the same head +er files in different directories, multiple '$s' variables specified in DIRS line c +ommand field, same source file specified in more than one directory, EVAL de +fined variables not used in DIRS cmds. Each warning will include the package, + filename and source line etc. bld.fatal Fatals terminate the build e.g. Same source file \'$basename\' + specified in same directory, extra unused variable(s) in DIRS section etc. Thes +e files should be empty if everything built correctly. The six mandatory EVAL defined variables are: 1. $bld # the target to build e.g. executable, libx.a, libx.so $bld="exec-c"; 2. $bldcmd # cmd used in perl system() call to build $bld target - requi +res '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC $INCDIR -lm -o \$bld \$O"; 3. $lib_dirs # space separated list of directories to search for libraries $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; 4. $opt_s # use system header files in dependency checking("system" or +"nosystem") $opt_s = "system"; 5. $opt_r # inform about any files that will require re-building, but d +o not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; 6. $opt_lib # do dependency checking on libraries("nolibcheck", "libcheck +", "warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; To understand the building of complex multi-target projects the follo +wing directories and files should be understood: ~/bld directories: Bld.<project>/<version> - has all files controlling <project> <ve +rsion>s blds and bld target output files bld.<project>/<version> - source code for <project> <version>s aux - template scripts directory for <project +> blds ~/bld/aux files: aux/bld.<project> - template copied to Bld.<project>/<versi +on> directories to bld multi-target projects aux/bld.<project>.rm - template copied to Bld.<project>/<versi +on> directories to clean multi-target projects ~/bld/Bld.<project>/<version> files: bld.<project> - for initiating single target, mul +ti-target or all target blds of a <project> bld.<project>.rm - for initiating single target, mul +ti-target or all target clean of a <project> bld.<project>.targets - list of all <project> targets bld.<project>.README - <project> README bld.<project>.install - <project> install script bld.<project>.script.<script> - scripts called by the Bld.<projec +t>.<target> files Bld.<project>.<target> - the Bld file for each <project> < +target> Bld.gv.<project> - global values imported into all B +ld.<project>.<target> files Bld.sig.<project>.<target> - the signature(SHA1) file for each + <project> <target> bld.info.<project>.<target> - the bld.info file for each <proje +ct> <target> bld.warn.<project>.<target> - the bld.warn file for each <proje +ct> <target> bld.fatal.<project>.<target> - the bld.fatal file for each <proj +ect> <target> The previous description material focused on the construction of a si +ngle target. This requires only the use of the bld program and Bld file. To bld complex multi-target + projects requires use of some standard directory structure conventions, several programs for bld'in +g targets and cleaning project directories and directory/file naming conventions. For example, usin +g git-2.3.0 and a <project> name of 'git': Bld.git/git-2.3.0 All of the target Bld files and bld run output files are here +. During development the initiation of target re-blds or full project re-blds are initiated from +here. bld.git/git-2.3.0 The git-2.3.0.tar.gz file is unzipped here and ./configure is + run against the git project source code. aux Template scripts for use in the Bld.git/git-2.3.0 directory. + The bld.<project> script is copied to Bld.git/git-2.3.0 as bld.git. The bld.<project>.rm is cop +ied to Bld.git/git-2.3.0 as bld.git.rm. No changes are required to the scripts code. aux/bld.git The bld.<project> file would be copied to Bld.git/git-2.3.0 a +s bld.git. There is no need to change the file; the file name is picked up internally. This is the + main project bld script. It is executed either with a sequence of target names or with '--al +l' for building all targets. Do 'perldoc bld.git' for the man page. aux/bld.git.rm The bld.<project>.rm file would be copied to Bld.git/git-2.3. +0 as bld.git.rm. There is no need to change the file; the file name is picked up internally. This script + is used to remove build files related to specific targets or clean files related to all targets. It i +s executed either with a sequence of target names or with '--all' for cleaning all targets. For example, + if test-wildmatch is used as a target then the following files will be removed: bld.fatal.git.test-wildmatch bld.info.git.test-wildmatch bld.warn.git.test-wildmatch Bld.sig.git.test-wildmatch test-wildmatch The target Bld file, Bld.git.test-wildmatch, will not be remo +ved. Do 'perldoc bld.git.rm' for the man page. bld.git.targets All the project targets go here, one to a line. The targets +will be built in order from top to bottom. Make sure than libraries that are required by subsequent targ +ets are built first. The file may have any number of blank or comment lines. bld.git.README The bld.git.README file provide getting started and contact i +nformation. bld.git.install For installing the project. This most likely will be a scrip +t to create an installable package. At present none are populated. bld.git.script.<script> These are scripts to call from the Bld files that do various +functions required for target construction. There may be any number of these. The git pro +ject did not require any. Bld.git.<target> The Bld file for a specific target. Bld.gv.git The project global values file. This file is imported at the + beginning of every project target Bld file. It has no structure. It contains defined variable +s that are common to all project Bld files e.g. $CC. Bld.sig.git.<target> bld.info.git.<target> bld.warn.git.<target> bld.fatal.git.<target> See above for a description of these files. See BUILDING MULTI-TARGET PROJECTS below for the detail steps in +building complex multi-target projects. FEATURES AND ADVANTAGES 1. Everything is done with SHA1 signatures. No dates are used anywh +ere. Signatures are a property of the file and not meta data from the system used for the build. Any t +ime issues, whether related to local clocks, networked host clocks or files touched by command activit +ies are eliminated. Modern signature algorithms are strongly randomized even for small file changes - +for the 160 bit SHA1 hash collisions are unlikely in the extreme. The Digest::SHA module is fast. The ex +pense of signature calculation times is small relative to the expense of programmer time. An investig +ation of some other make alternatives e.g. scons, cook - will disclose that they too are using signatur +es - maybe for exactly for the same reasons. 2. bld is REALLY simple to use. There are no arguments and no envir +onment variables. The entire bld is controlled from the Bld(and Bld.gv file) file. Only a minimal kn +owledge of perl is needed - variable definitions and simple regular expressions. 3. Automatic dependency checking - GNU cpp is used to find the heade +r file dependencies. Optionally, header file checking may be done for user header files only or for simul +taneously both system header and user header files. All header file dependency information associated +with each source is saved to the bld.info file. 4. There are no built in dependency rules. The Bld file DIRS sectio +n specifications give what is to be built from what and the Bld file EVAL section gives how to assemb +le all the components for the target. 5. bld is not hierarchical. A single Bld file controls the construc +tion of a single target(a target is an executable or library(static or shared)). Complex multi-target p +rojects use one Bld.gv(global values) file and many Bld files - one to a target. The source directory +structure goes under bld.<project>/<version> and each target Bld file(Bld.<project>.<target>) encapsulates all + the build information for all the source directories under bld.<project>/<version>. All the built +targets and build information files go into the Bld.<project>/<version> directory. See "'make' and it's + difficulties:" below for reasons why recursive make causes problems. 6. Each source file will have three signatures associated with it - +one for the source file, one for the corresponding object file and one for the cmds use to re-build th +e source. A change in any of these will result in a re-build. A change in the target signature will resu +lt in a re-build. Optionally, the signatures of dynamic libraries may be tracked. If a library sig +nature changes the bld may warn or stop the re-build. If dynamic libraries are added or deleted from the + bld this can ignore/warn/fatal. 7. If any files in the bld have the same signature this is warned ab +out e.g. two header or source files of the same or different names. 8. Complex multi-target projects are built with a standard directory + setup and a standard set of scripts - Directories: Bld.<project>/<version> - has all files controlling <pr +oject> <version>s blds and bld target output files bld.<project>/<version> - source code for <project> <ve +rsion>s Files: bld.<project> - for initiating single target, + multi-target or all target blds of a <project> bld.<project>.rm - for initiating single target, + multi-target or all target clean of a <project> bld.<project>.targets - list of all <project> targets bld.<project>.README - <project> README bld.<project>.install - <project> install script bld.<project>.script.<script> - scripts called by the Bld.<pr +oject>.<target> files Bld.<project>.<target> - the Bld file for each <projec +t> <target> Bld.gv.<project> - global values imported into a +ll Bld.<project>.<target> files 9. Security - since the signatures of everything(source, objects, li +braries, executable) are checked it is more difficult to insinuate an exploit into a source, object, lib +rary or executable during the build process. 10. The capture of the full build process in the bld.info, bld.warn a +nd bld.fatal files allows easy access to and saving of this information. For multi-target projects with t +he target names appended to these files it allows quick investigation of the build process of many interr +elated targets at the same time. 11. Perl - since bld is all perl and since all warnings and fatals ha +ve the source line number associated with them, it is very easy to locate in the source code the exact loca +tion of an error and examine the context about which the error occurred and routine that the error was pro +duced in. 12. Time - programmer time; learning about, maintaining/debugging Mak +efiles and Makefile hierarchies, dependency checking integration and formulation of Makefile strategies, auto +matic Makefile generation with Autotools - these all dominate the programmer time and expense of 'make'. bl +d only requires basic perl variables(in the Bld file EVAL section) and '[R] dir:regex:{cmds}' line specif +ications(in the Bld file DIRS section). 13. The -c option will create, at the end of a bld run, a bld.chg fil +e with all files and their old/new signatures that have been added/deleted/changed. Successive runs will appen +d to this file with a time stamp. 14. 'make' and it's difficulties: http://www.scons.org/wiki/FromMakeToScons a detailed critique of make and some alternatives(Adrian +Neagu) http://freecode.com/articles/what-is-wrong-with-make What is Wrong with Make?(Adrian Neagu) http://www.scons.org/architecture/ a description of the scons architecture and in particular + the reasons for the use of signatures instead of dates ftp://ftp.gnu.org/old-gnu/Manuals/autoconf/html_mono/autoconf +.html#SEC3 a brief critique of make and how GNU automake from the GN +U Build System contributes http://aegis.sourceforge.net/auug97.pdf an article "Recursive Make Considered Harmful" by Peter M +iller from the Australian UNIX Users Group http://www.conifersystems.com/whitepapers/gnu-make/ an in depth critique of make http://www.conifersystems.com/whitepapers/gnu-make/ What's Wrong With GNU make? http://www.leosimons.com/2006/bettermake/what-is-a-better-mak +e.html What is a better make? http://www.leosimons.com/2006/a-better-make.html Building a better (make|ant|maven|...) DEPENDENCIES I use Fedora for development on an x86_64 architecture. Yum is th +e package installation tool. Required for execution: experimental.pm(3pm) - for smartmatch and switch features cpp(1) - gnu cpp cmd is required for dependency determination ldd(1) - used for library dependency determination Do: cpan install cpanm cpanm experimental.pm Required for test: gcc(1)/g++(1) (http://gcc.gnu.org/) clang(1) (http://llvm.org/) yacc(1)/flex(1) Some variation might be required on(for git, svn, systemd test): yum install gcc.x86_64 yum install gcc-c++.x86_64 yum install gcc-objc.x86_64 yum install gcc-objc++.x86_64 yum install libobjc.x86_64 yum install gnustep-base.x86_64 yum install gnustep-base-devel.x86_64 yum install clang yum install byacc yum install flex yum install zlib-devel.x86_64 yum install libxdiff.x86_64 yum install apr.x86_64 yum install apr-util.x86_64 yum install apr-util-devel.x86_64 yum install sqlite-devel.x86_64 yum install intltool yum install libcap-devel yum install gtk-doc yum install lzma.x86_64 yum install libmount-devel.x86_64 If ./configure generates the following msg about missing requireme +nts: "configure: error: Package requirements (foo) were not met: No package 'foo' found Consider adjusting the PKG_CONFIG_PATH environment variable if + you installed software in a non-standard prefix." Do: yum install "pkgconfig(foo)" Also check: http://who-t.blogspot.com/2014/05/configure-fails-with +-no-package-foo.html If the downloaded project code does not have a configure script th +en check for a configure.ac file and run 'autoconf' with no arguments or options. This will g +enerate a configure script. PROJECT STATE 1. The git, svn and systemd projects need work. I ran ./configure be +fore each bld. I used no options. How options affect the generated code and thus the Bl +d files is important. Anyone willing to investigate configure options and how these opti +ons affect the Bld files is welcome. 2. The bld.<project>.install scripts all need to be done. These scri +pts need to build the the packages that 'yum install <package>' would install or possibl +y packages tailored to other systems. I'd prefer to partner with someone knowledgeable a +bout the installation of git, svn and systemd. 3. All the Bld.gv.<project> files should be vetted by a <project> kno +wledgeable builder. 4. The git, svn and systemd projects will all be creating new version +s eventually. Anyone that would like to add bld.<project>/<version> and Bld.<project>/< +version> directories with the new versions is welcome. 5. I need someone with substantial experience building the linux kern +el to advise me or partner with me on the construction of 4.0 or later. 6. If you successfully bld a new project and wish to contribute the b +ld, please do so. I'm interested in how others construct/organize/document/debug project +s and their Bld files. QUICK START 1. Bld'ing the systemd project - http://www.freedesktop.org/wiki/Soft +ware/systemd/ a. cd Bld.systemd/systemd-208 # puts you into the systemd(systemd- +208) project directory b. ./bld.systemd --all # bld's all of the systemd targets a +nd bld target output files - the bld.info.systemd.<target>, the bld.warn.systemd.<target>, the bld.fatal.systemd.<target> +, files c. ./bld.systemd.rm --all # cleans up everything 2. Bld'ing the svn project - https://subversion.apache.org/ a. cd Bld.svn/subversion-1.8.11 # puts you into the svn(subversion +-1.8.11) project directory b. ./bld.svn --all # bld's all of the svn targets and + bld target output files - the bld.info.svn.<target>, the bld.warn.svn.<target>, the bld.fatal.svn.<target>, files c. ./bld.svn.rm --all # cleans up everything 3. Bld'ing the git project - http://www.git-scm.com/ a. cd Bld.git/git-2.3.0 # puts you into the git(git-2.3.0) project + directory b. ./bld.git --all # bld's all of the git targets and bld tar +get output files - the bld.info.git.<target>, the bld.warn.git.<target>, the bld.fatal.git.<target>, files c. ./bld.git.rm --all # cleans up everything 4. Bld'ing any single target a. cd bld # the main bld directory - cd here when you unpack + the bld.tar.xz file b. Install the source code in a sub-directory of the bld directory c. Create a Bld file - the Bld file entirely controls the target b +ld - see example below d. ./bld -h # the bld usage msg e. ./bld # do the bld f. ./bld.rm # clean up g. vi Bld.sig # examine the bld signature file h. vi bld.info # detailed info about the stages of the bld i. vi bld.warn # warning msgs from the bld j. vi bld.fatal # fatal msgs that terminated the bld - should be e +mpty if bld is successful Bld FILE FORMAT AND EXAMPLES A more detailed description of the Bld(and Bld.gv) files initially pr +esented in the DESCRIPTION section above is presented here. 1. A comments section 2. An EVAL(starts a line) section - this is perl code that is eval'ed + in bld. Six variables are required. These are: e.g. EVAL # mandatory defined variables # the target to build e.g. executable, libx.a, libx.so $bld="exec-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -lm -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require re-building, bu +t do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("nolibcheck", "libch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; Any other simple perl variables can be defined in the EVAL sec +tion and used in the DIRS section. Environment variables may be set. 3. A DIRS(starts a line) section - this section will have either {cmd +s} cmd blocks or '[R] dir:regex:{cmds}' specifications. The {cmds} blocks are just a group of shell cmds, always executed. + A dir specification is a source directory relative to the bld directory. The regex specification is a perl regular e +xpression that will pick up one or more of the source files in dir. The {cmds} specification describes how to bu +ild the selected source files. Any number of cmds, ';' separated, may be specified within the {} brackets. Example Bld Files: Simplest(Bld.example/example/Bld.example.helloworld-c): The 'Hello World!' program with only the minimal required defi +nitions. Comments EVAL $CC = "gcc"; # mandatory defined variables # the target to build e.g. executable, libx.a, libx.so $bld="helloworld-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "/usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require re-building, bu +t do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("nolibcheck", "libch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "warnlibcheck"; DIRS bld.example/example : ^helloworld\.c$ : { $CC -c $s; } Complex(Bld.example/example/Bld.example.exec-c): A well commented example of all of the features of a Bld file. + The code routines are all just stubs designed to illustrate a Bld file. Comments EVAL # this section will define perl variables to be interpolated i +nto DIRS section cmd fields # the compiler $CC = "clang"; # mandatory defined variables # the target to build e.g. executable, libx.a, libx.so $bld="exec-c"; # cmd used in perl system() call to build $bld target - re +quires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC -lm -o \$bld \$O"; # space separated list of directories to search for librar +ies $lib_dirs = "example/lib /usr/lib /lib /usr/local/lib"; # use system header files in dependency checking("system" +or "nosystem") $opt_s = "system"; # inform about any files that will require re-building, bu +t do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("nolibcheck", "libch +eck", "warnlibcheck" or "fatallibcheck") $opt_lib = "fatallibcheck"; # some examples of variables that will be interpolated into DI +RS section cmd fields $INCLUDE = "-I bld.example/example/include"; $LSOPTIONS = "-l"; # "a" or "b" to conditionally compile main.c $COND = "a"; DIRS # this section will have either {cmds} cmd blocks or '[R] dir: +regex:{cmds}' specifications # example of use of conditional compilation bld.example/example/C : ^main\.c$ : { # can have comments here too if [ "$COND" == 'a' ]; then $CC -S $INCLUDE $s; fi if [ "$COND" == 'b' ]; then $CC -O4 -S $INCLUDE $s; fi } # example of execution of a bare block of cmds - '{' and '}' m +ay be on separate lines { ls $LSOPTIONS; } # the cmd field may be put on another line(s) and indented bld.example/example/C : ^g\.x\.C$ : { $CC -c $INCLUDE $s; } # all three fields - dir, regex and cmd - may be put on separa +te lines(even with extra blank lines). # directories may have embedded blanks('a b'). bld.example/example/C/a b : ^m\.c$ : {$CC -c $INCLUDE $s;} # example of regex field that captures multiple source files(h +.c and i.c) and example of a # cmd field with multiple cmds - white space is irrelevant(a c +hange should not cause a re-build) # example of cmd fields with multiple cmds(ls and $CC) bld.example/example/C : ^(h|i)\.c$ : { ls -l $s; $CC +-c $INCLUDE $s; } # example of assembler source # Note: the $CC compile produces .o output by changing the c t +o an o. # the as output needs to be specified by the -o option. bld.example/example/C : ^main\.s$ : {as -c -o main.o $s;} # are applied to all subdirectories of the specified dir field +(right after the 'R') R bld.example/example/C/y : ^.*\.c$ : {$CC -c $INCLUDE $s;} bld.example/example/C/x : ^t\.c$ : {$CC -c $INCLUDE $s;} bld.example/example/C/z : ^(w|w1)\.c$ : {$CC -c $INCLUDE +$s;} # cmd blocks may execute multiple cmds(ls and pwd) { ls -lfda; pwd; ls; } FILES $HOME directory files: .bldrc - user bld run cmd file ~/bld directory files: .bldrc - local bld run cmd file bld - the bld perl script bld.rm - script to clean the bld directory bld.README - for first point of contact quick start Bld - the bld file which controls bld and the construction of +a target Bld.gv - the file of global values imported into the Bld file(unu +sually used only for multi-target builds) Bld.sig - the signature(SHA1) file created from the Bld file bld.info - information about the bld bld.warn - warnings from the bld bld.fatal - the fatal msg that ended the bld bld.chg - all files and their old/new signatures that have been ad +ded/deleted/changed ~/bld directories: Bld.<project>/<version> - has all files controlling <project> <versio +n>s blds and bld target output files bld.<project>/<version> - source code for <project> <version>s aux - template scripts directory for <project> bl +ds ~/bld/aux files: aux/bld.<project> - template copied to Bld.<project>/<version> +directories to bld multi-target projects aux/bld.<project>.rm - template copied to Bld.<project>/<version> +directories to clean multi-target projects ~/bld/Bld.<project>/<version> files: bld.<project> - for initiating single target, multi-t +arget or all target blds of a <project> bld.<project>.rm - for initiating single target, multi-t +arget or all target clean of a <project> bld.<project>.targets - list of all <project> targets bld.<project>.README - <project> README bld.<project>.install - <project> install script bld.<project>.script.<script> - scripts called by the Bld.<project>.< +target> files Bld.<project>.<target> - the Bld file for each <project> <targ +et> Bld.gv.<project> - global values imported into all Bld.< +project>.<target> files Bld.sig.<project>.<target> - the signature(SHA1) file for each <pr +oject> <target> bld.info.<project>.<target> - the bld.info file for each <project> +<target> bld.warn.<project>.<target> - the bld.warn file for each <project> +<target> bld.fatal.<project>.<target> - the bld.fatal file for each <project> + <target> BUILDING SINGLE TARGETS (a target is an executable or library(static or shared)) 1. Construct the Bld file - see below for a Bld file example and s +ee the Bld.example directory for multiple examples. A Bld.gv file is not needed f +or a single target. Since there are no args to bld and no environment variables are + used, nothing else needs to be done. 2. Execute './bld'. This will rebuild the target and create/updat +e the Bld.sig signature file. The bld.info, bld.warn and bld.fatal files will be creat +ed. 3. Use './bld.rm' to clean the bld directory. BUILDING MULTI-TARGET PROJECTS (a target is an executable or library(static or shared)) 1. Pick a name for the project e.g. git, svn, systemd. 2. In the main bld directory(the location of the bld script) creat +e a bld.<project> directory. Create another directory, bld.<project>/<version>, +that describes the version of the code it will hold e.g. systemd-208. Any number +of these version directories may be created to maintain different versions of th +e code. Unpack the source code in the version directory e.g. bld.systemd/systemd-2 +08/<systemd-208 src code>. 3. Create a Bld.<project> directory. Create another directory, Bl +d.<project>/<version>, that describes the version of the code it will maintain e.g. sy +stemd-208. There should be one version directory for each version of the code be +ing maintained. These directories will hold: a. all of the Bld.<project>.<target> and Bld.gv.<project> f +iles that control the construction of each project target b. all of the target bld output files: bld.info.<project>.<target>(information describing t +he bld) bld.warn.<project>.<target>(bld warning msgs) bld.fatal.<project>.<target>(bld fatal msgs) c. the bld scripts and script control files d. all of the targets 4. Create a Bld.<project>.<target> file for each project target. +These control the bld for each and only that target. If there are variables that may + be defined globally over the entire project then set them in the Bld.gv.<project>(o +ne per project) file. The Bld.gv.<project> file will be included in each Bld.<project +>.<target> file before it is evaluated. All Bld.<project>.<target> files require six +variables to be defined. These are: e.g. # mandatory defined variables # space separated list of directories to search for librari +es $lib_dirs = ""; # use system header files in dependency checking("system" o +r "nosystem") $opt_s = "nosystem"; # inform about any files that will require rebuilding, but +do not rebuild("rebuild" or "norebuild") $opt_r = "rebuild"; # do dependency checking on libraries("libcheck", "nolibche +ck", "warnlibcheck" or "fatallibcheck") $opt_lib = "nolibcheck"; # the target to built e.g. executable, libx.a, libx.so $bld="accelerometer"; # cmd used in perl system() call to build $bld target - req +uires '$bld'(target) and '$O'(object files) internally $bldcmd = "$CC $LIBSLINKOPTS -o \$bld \$O -LBld.systemd/sys +temd-208 -ludev -lsystemd-shared -ludev-core -lm -lrt -ldl"; The definition of these variables may be spread between the Bld +.<project>.<target> and the imported Bld.gv.<project> files. See the Bld FILE FORMAT section below for detailed instructions + on Bld file construction. 5. Create a bld.<project>.targets file with all of the project tar +get names, one to a line. e.g. # each line is a valid target argument to bld.<project> e.g +. './bld.<project> target' # and will build one(that named) library or executable. th +e order of target bld's # is important. if 'bld.<project> --all' is used to bld al +l targets then dependencies # must be built first, that is, libraries that executables +depend on must be built at # the start. # libsystemd-shared.a # libsystemd-login.so # systemd-cgls ... The order is important; if an executable depends on a library t +hen build the library first. 6. Copy the 'bld.<project>' and 'bld.<project>.rm' files from the +aux directory to the source code directory and rename them for that particular project. These s +cripts use the <project> part of the script name for building output files. 7. Run the ./bld.<project> script with the --all option or one or +more target names from the bld.<project>.targets file. This will bld all targets or the selected targets. The: bld.info.<project>.<target>(information describing the bld) bld.warn.<project>.<target>(bld warning msgs) bld.fatal.<project>.<target>(bld fatal msgs) files will be created. Examine these for the results of each t +arget bld. All of the bld.fatal.<project>.<target> files should be empty if everything bld's OK. 9. Run './bld.<project> --all' again to rebuild. If everything bu +ilt successfully the first time then this run will indicate that everything is up to date. 8. Use './bld.<project>.rm [--all] [target, target, ...]' to clean + up. 9. Use './bld.<project>.install' as root to install the project. 10. Examine the ./bld.<project>.README for project specific inform +ation. NOTES 1. bld assumes that a source will build a derived file e.g. .o files + in the same directory and have the same root name as the source. a subsequent Bld file {} +block can rename and move the .o files. 2. bld assumes that all targets in multi-target bld's will be unique +ly named - all targets go into the same project directory before distribution for installat +ion. installation can then rename and distribute targets in any way desired. 3. Some projects(rarely) violate either or both of these target nami +ng or object file naming/location requirements, but reconstructing these projects w +ith bld should be relatively easy e.g. systemd. 4. bld executes cmd fields({}) in the bld directory and then moves a +ll created files to the source directory. 5. A bld run may be ^C interrupted. When a normal uninterrupted run + is completed the Bld.sig file is rewritten using only those files that were includ +ed in the build. Thus, if files were added or deleted this would reflect in the ne +w Bld.sig file. If a run is interrupted, all files read in from the original Bld.sig f +ile and any new files already built are written out to the Bld.sig file. This ensures +that new files already built and old files not yet examined will not be re-built. This +may result in some entries in the Bld.sig file that no longer exist, but this will b +e corrected at the end of the next normally completed run. 6. The Bld.sig signature file is automatically created and updated. + It contains one line for each source, one line for each header file, optionally one li +ne for each library and one line for the executable. The header file lines and the execu +table line have two fields: the file name and its signature. The source lines have f +our fields: the file name, the signatures of the source file, the command use to build + the source, and the object file. The user can modify this file to force the re-build + of files by altering the signature or even by deleting a line, however, any modificati +on to a source or header file, or build command string will do the same thing. Removing t +he Bld.sig file will re-build the entire target. 7. A non C or C++ source will be re-built if its build command has b +een changed or the source file itself has been changed. The re-built output will be + put back in the directory where the source came from. The assumption is that it w +ill be a file that will then act a source for subsequent build steps e.g. a lex or yacc t +hat will produce a C file as output which will then later need to be compiled. Bld fi +le cmd({}) blocks can modify this. 8. When blocks of cmds({}) are executed by the perl `{ cmds } 2>&1`; + operator, error reporting is per ``; call. If you are executing multiple cmds an +d want more granular error reporting then break up the cmd block into multiple cmd blo +cks e.g {ls;pwd;} -> {ls;} {pwd;} or dir:regex:{ls;pwd;$CC -c $s;} -> {dir/ls;} {dir/p +wd;} dir:regex: {$CC -c $s;}. 9. All cmds must end with a ';'. If you miss this then you'll see m +sgs like - "sh: -c: line 1: syntax error: unexpected end of file". This includes the + compiles and the $bldcmd string. 10. If you interrupt a bld(^C) you might get an object file left in t +he bld directory. The next time bld is run this will not be recognized as a new fil +e and mv'ed to the source file directory. Just remove these before a new bld run. 11. { cmds } are executed within `{ cmds } 2>&1`; and the return stdo +ut/stderr matched against strings stored in the @stderr_err_strs array. Any actual + error return not matched by one of these strings will be missed. New strings can +be added to @stderr_err_strs in the BGC.pm module. CALL TREE Calls to imported functions from public CPAN modules are omitted. Ca +lls to some bld coded routines are omitted: opt_help() system_error_msg() warning() fatal() sourcesort() bld Bld_section_extract() init_blddotinfo() dirs_pro() cvt_dirs_to_array() expand_R_specification() accum_blddotinfo_output() var_sub() var_sub() var_sub() variable_match() var_sub() var_sub() var_sub() read_Blddotsig() var_sub() var_sub() src_pro() file_sig_calc() buildopt(); tgtextorfile(); hdr_depend() file_sig_calc() rebuild_src_bool() tgt_signature() rebuild_target_bool() file_sig_calc() file_sig_calc() rebuild_exec() file_sig_calc() file_sig_calc() multiple_sigs() sig_file_update() DIAGNOSTICS Diagnostics are either warnings(calling warning($msg)) or fatals(call +ing fatal($msg)). Warnings and fatals are exclusive; specific conditions cause warnings + and specific other conditions cause fatals. There is no overlap. Warnings are co +nditions that may be of interest e.g. same header file in multiple locations or multipl +e -c specifications in a source compilation cmd, but which should not impact the full bui +ld of the project. Fatals are conditions that either will necessarily force the terminat +ion of the build e.g. a source file compile failure, or that indicate the construction + of the Bld file has some instructions that are contradictory or missing necessary ele +ments e.g. same source file matched twice in Bld file DIRS section specifications. W +arnings are written to the bld.warn file only. Fatals are written identically to standar +d out and the bld.fatal file. Warnings all start with 'WARNING:' and fatals all st +art with 'FATAL:'. There are no other types of diagnostic msgs. INCOMPATIBILITIES None Known BUGS AND LIMITATIONS None Known SEE ALSO Do: perldoc 'bld.<project>' perldoc 'bld.<project>.rm' 'make' and it's difficulties - in FEATURES AND ADVANTAGES above GITHUB RELEASES https://github.com/rahogaboom/bld bld-1.0.6.tar.gz - changes related to: a. fixes for two gcc warnings in the example c +ode(rdx and daa) b. use 'print STDERR' for all prints - more im +mediate output c. doc updates bld-1.0.5.tar.gz - changes related to: a. change {cmds} block execution from 'system +"cmds";' to '`{ cmds } 2>&1`;' b. add -c option to create bld.chg file with a +ny file changes during a bld run c. add $ENV{HOME}/.bldrc and .bldrc files d. doc updates bld-1.0.4.tar.gz - entirely perldoc updates. example projects - +bld-1.0.4-git.tar.xz, bld-1.0.4-svn.tar.xz and bld-1.0.4-systemd.tar.xz. Why are there no releases beyond the latest three? For now, I on +ly intend to maintain and answer questions about the most recent releases. This may change in future. AUTHOR Richard A Hogaboom richard.hogaboom@gmail.com LICENSE and COPYRIGHT and (DISCLAIMER OF) WARRANTY Copyright (c) 1998-2014, Richard A Hogaboom - richard.hogaboom@gmail.c +om All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are + met: * Redistributions of source code must retain the above copyright notic +e, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright no +tice, this list of conditions and the following disclaimer in the document +ation and/or other materials provided with the distribution. * Neither the name of the {organization} nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "A +S IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, +THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PUR +POSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE +LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUEN +TIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOOD +S OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOW +EVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIA +BILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF +THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. : +-)
DBIx::Class recursive subquery construct
No replies — Read more | Post response
by maruhige
on Aug 15, 2014 at 14:38

    Hello Monks,

    My first encounter with DBIx::Class's subquery construct went so well (and my need of n subqueries so great) that I tried a programmatic way of creating nested subqueries, shared here.

    Context is simply a tag search function, where all the tags are in one table, with an intermediate 2 integer column table to the post table. Tags are retrieved from the tag table in ascending order of weight to ensure the smallest possible start set, getting progressively smaller.

    sub recursive_subquery{ my($schema,$join_column,$key,$values) = @_; my ($value1) = shift(@$values); my $sub_query =$schema->search({ $key => $value1, }); for(@$values){ my $tmp_query = $schema->search({ $join_column => { -in => $sub_query->get_column($join_column)->as_query }, $key => $_, }); $sub_query = $tmp_query; } return $sub_query; }

    And a short example of using it manually in Catalyst:

    $c->stash->{rows} = $c->model('DB::Post')->search({ 'posts.post_id' => { -in => recursive_subquery( $c->model('DB::TagCloud1'), ,'post_id', 'tag_def_id',[ 16042, 190712, ])->get_column('post_id')->as_query }, });

    As an aside, the performance of this highlighted the unhappy fact that mysql tends to evaluate sub queries from the outside-in, so you may want to reverse the weighting in that setup.

Draw a Square With Perl!
4 direct replies — Read more / Contribute
by Dipseydoodle
on Aug 14, 2014 at 10:41

    Good morning monks. Today I figured I'd post this little script I wrote. It's not that cool and you can propbably point out errors in my writing/syntax style, so feel free to yell at me :)

    #!/usr/bin/perl # Put on your nerd glasses and draw a square! use strict; use warnings; my $balancex = 10; # width my $repeatx = $balancex; #don't change repeatx!!! use balancex instead +. my $repeaty = 10; # height do{ while($repeatx > 0){ print ". "; # change the period to print another character, but ke +ep the extra space. $repeatx -= 1; } print "\n"; $repeatx += $balancex; $repeaty -= 1; } until ($repeaty == 0); #corrected by Athanasius & AppleFritter

    No doubt this could be done in much fewer lines, or even as a one-liner :P But as it says it draws a square with periods, and is just fun to look at.

Check popular review sites for new reviews.
1 direct reply — Read more / Contribute
by wrinkles
on Jul 28, 2014 at 19:25

    This script checks select pages on some popular review sites for the latest review, and writes the date of the most recent review from each site to a file. Each time it is run, it checks against the previous results and sends an email notification with the date and link to page(s) with fresh reviews.

    "mailx" was used to send email. I suspect that this may not be available in Windows, I tested only on Mac OS X and Ubuntu.

    The following script has the pages hard-coded, as it was written for my school. Those pages (and your email addresses) could easily be replaced to suit your requirements.

    I found "The 10-minute XPath Tutorial" ("Automating System Administration with Perl, 2nd ed.) very helpful in understanding XPath. Thanks also to the help of fellow perl monks!

    By the way, "EB" and "MA" are shorthand for two separate campuses within our school.

    Update 2014-07-28 - I ran perlcritic and fixed some potential problems

    #!/usr/bin/env perl use strict; use warnings; use utf8; use Text::CSV; use Carp; use LWP::Simple qw(get); use Text::Unidecode qw(unidecode); use HTML::TreeBuilder::XPath; # Email Settings my %email = ( to => 'me@example.com,you@example.com', subject => 'New ECDS reviews found' ); # Reviews subroutine and URLs to check my $review_sites = [ { site => 'Yelp', sub => \&yelp_checker, review_pages => { 'EB' => 'http://www.yelp.com/biz/encinitas-country-day-school-encinitas?sort_b +y=date_desc', 'MA' => 'http://www.yelp.com/biz/encinitas-country-day-school-encinitas-2?sort +_by=date_desc' } }, { site => 'GreatSchools', sub => \&gs_checker, review_pages => { 'MA' => 'http://www.greatschools.org/california/encinitas/9670-Encinitas-Count +ry-Day-School/?tab=reviews' } }, { site => 'PrivateSchoolReview', sub => \&psr_checker, review_pages => { 'MA' => 'http://www.privateschoolreview.com/school_ov/school_id/ +2039' } }, { site => 'Kudzu', sub => \&kudzu_checker, review_pages => { 'MA' => 'http://www.kudzu.com/m/Encinitas-Country-Day-School-135 +71675' } }, { site => 'MerchantCircle', sub => \&mc_checker, review_pages => { 'MA' => 'http://www.merchantcircle.com/business/Encinitas.Country.Day.School.7 +60-942-1111?sort=created&dir=desc' } } ]; # Default date if no record my $default_date = '00-00-0000'; # Month name to number conversion my %month = ( January => '01', February => '02', March => '03', April => '04', May => '05', June => '06', July => '07', August => '08', September => '09', October => '10', November => '11', December => '12' ); # Where is the reviews file? my $reviews_filepath = "reviews.txt"; # Where is the alert message file? my $msg_filepath = "msg.txt"; # Slurp hash from reviews file my $old_reviews = hash_from_csv($reviews_filepath); my %new_reviews; # Iterate through each site for my $review_site (@$review_sites) { my $pages = $review_site->{review_pages}; # iterate through each campus html and collect xpath nodes while ( my ( $campus, $url ) = each %$pages ) { my $html = get $url or croak("Can't reach $url $!\n"); $html =~ s/([^[:ascii:]]+)/unidecode($1)/ge; my $tree = HTML::TreeBuilder::XPath->new; $tree->parse($html) or croak("Parse failed: $!\n"); my ($date) = $review_site->{'sub'}->($tree); # create hash keys from campus and review site names my $campus_site = $campus . '_' . $$review_site{'site'}; push( @{ $new_reviews{$campus_site} }, $date ); push( @{ $new_reviews{$campus_site} }, $url ); } } # Write message if new reviews my $msg = ''; while ( my ( $item, $data ) = each %new_reviews ) { unless ( $$old_reviews{$item}[0] eq $$data[0] ) { $msg .= "New review on $$data[0]: \n $$data[1]\n"; } } # Save message. open my $fh, ">:encoding(utf8)", "$msg_filepath" or croak("cannot open $msg_filepath: $!"); print {$fh} $msg or croak("Can't print message:\n$msg\n$!"); close $fh; # Write new review data to file. hash_to_csv( \%new_reviews, $reviews_filepath ); # Email message if exists send_email($msg) if length($msg); ######## SUBROUTINES ####### # import old data from file sub hash_from_csv { my $filepath = shift; open my $fh, "<:encoding(utf8)", "$filepath" or croak("cannot open $filepath: $!"); my $csv = Text::CSV->new( { binary => 1 } ); my %hash; map { $hash{ shift @{$_} } = $_ } @{ $csv->getline_all($fh) }; close $fh; return \%hash; } # write new data to file sub hash_to_csv { my ( $hash, $filepath ) = @_; open my $fh, ">:encoding(utf8)", "$filepath" or croak("cannot open $filepath: $!"); my $csv = Text::CSV->new( { binary => 1, eol => "\n" } ); for ( keys %$hash ) { my $colref = [ $_, $$hash{$_}->[0] ]; $csv->print( $fh, $colref ); } close $fh; return; } # send email notifications sub send_email { my ($body) = @_; open my $pipe, '|-', '/usr/bin/mailx', '-s', $email{subject}, $ema +il{to} or croak("can't open pipe to mailx: $!\n"); print $pipe $body; close $pipe; croak("mailx exited with a non-zero status: $?\n") if $?; return; } # extract date of most recent review from GreatSchools tree sub gs_checker { my $tree = shift; my $xpath = '//div[contains(@class,"media mbs")]/div[(@class="author small make-99 +9999 fl pbn mbn")]'; my $dates = $tree->findnodes($xpath); # dates returned as 'month dd, yyyy' my $date; $date = $$dates[0]->as_trimmed_text() if ( $$dates[0] ); if ( $date =~ /(\w{3,9})\s+(\d{1,2}),\s+(\d{4})/ ) { $date = $3 . '-' . $month{$1} . '-' . $2; } return ( $date || $default_date ); } # extract date of most recent review from Yelp tree sub yelp_checker { my $tree = shift; my $xpath = '//meta[@itemprop="datePublished"][1]'; my $dates = $tree->findnodes($xpath); # dates returned as 'yyyy-mm-dd' if ( $$dates[0] ) { return $$dates[0]->attr('content'); } else { return ( $$dates[0] || $default_date ); } } # extract date of most recent review from PrivateSchoolReview tree sub psr_checker { my $tree = shift; my $xpath = '//meta[@itemprop="datePublished"][1]'; my $dates = $tree->findnodes($xpath); # dates returned as 'yyyy-mm-dd' if ( $$dates[0] ) { return $$dates[0]->attr('content'); } else { return ( $$dates[0] || $default_date ); } } # extract date of most recent review from Kudzu tree sub kudzu_checker { my $tree = shift; my $xpath = '//div[@class="review_post_date"]/p/span[@class="rp-da +te"]'; my $dates = $tree->findnodes($xpath); # date returned as 'mm/dd/yyyy' my $date; $date = $$dates[0]->as_trimmed_text() if ( $$dates[0] ); if ( $date =~ /(\d{1,2})\/(\d{1,2})\/(\d{4})/ ) { $date = $3 . '-' . $1 . '-' . $2; } return ( $date || $default_date ); } # extract date of most recent review from MerchantCircle tree sub mc_checker { my $tree = shift; my $xpath = '//span[@itemprop="datePublished"][1]'; my $dates = $tree->findnodes($xpath); # dates returned as 'Month dd, yyyy at hh:mm PM' my $date; $date = $$dates[0]->as_trimmed_text() if ( $$dates[0] ); if ( $date =~ /\s*(\w{3,9})\s*(\d{1,2})\s*\,\s*(\d{4})\s+at\s+\d{1,2}\:\d{2} +\s+[AP]M/ ) { $date = $3 . '-' . $month{$1} . '-' . $2; } return ( $date || $default_date ); }
Install missing modules with Module::Extract::Install's cpanm-missing/cpanm-missing-deep
1 direct reply — Read more / Contribute
by frozenwithjoy
on Jul 24, 2014 at 12:07

    The other day I got a new laptop and tried to run a couple scripts on it. I quickly grew tired of the tedious cycle of 'Module::X not found' errors/installing Module::X. I decided to make a tool to improve the situation.

    The result, Module::Extract::Install, can be used to analyze perl scripts and modules to identify and install their dependencies in an automated, pain-free manner. You can use this module's methods to write your own script (e.g., to pipe missing modules to your favorite installer) or take advantage of the included command-line tools cpanm-missing (checks a list of Perl files) and cpanm-missing-deep (checks all the Perl files within a directory).

    Feel free to give me last minute comments/suggestions before I put it on CPAN (currently it is only available through GitHub). Thanks!

SysV shared memory (Look-Alike) -- pure perl
3 direct replies — Read more / Contribute
by flexvault
on Jul 20, 2014 at 16:42

    Dear Monks,

    I have stayed away from using shared memory because of the statement: "This function is available only on machines supporting System V IPC." in the documentation for use. I decided I had a good use and did a Super Search and found zentara's excellent work which I used as a starting point for this discussion. I re-read the documentation and looked at the books 'Programming Perl' and the 'Perl Cookbook', and wondered if I could do something similar with a RAM disk and not have a dependency on System V IPC support. So taking the code provided by zentara, and using it as a benchmark for my requirements, I started testing on a 8GB RAM disk on a Debian 64bit Linux box using a 32-bit 5.14.2 Perl. I found that I could get approximately 216K System V IPC writes per second(wps). WOW!

    Since I only needed 20-25K writes per second, I started working on my "shared memory look-alike". What I found was that I could do better than 349K wps. Actually the 1st run produced 800K wps, but I realized I didn't follow the format of zentara's script, so I modified the script to call a subroutine, flock the file, test return codes, etc. Currently, 349K wps is the worse case on a RAM disk, 291K wps on a 7,200 rpm hard disk, and 221K wps on a 5,400 rpm disk. (Note: I didn't have a SSD on the test system.) The code follows, and if I did something to make my numbers look better, I'd like to know.

    Update: Do not use this code as it mixes buffered and unbuffered I/O. See later for a sample that I believe works correctly!

    ####### shmem-init.pl ############################ #!/usr/bin/perl use warnings; use strict; use Time::HiRes qw( gettimeofday usleep ); use Fcntl qw( :DEFAULT :flock ); ## Part of core perl use IPC::SysV qw(IPC_STAT IPC_PRIVATE IPC_CREAT IPC_EXCL S_IRUSR S_IWU +SR IPC_RMID); # see "perldoc perlfunc /shmget" and "perldoc perlipc /SysV" # big difference from c is attach and detach is automatic in Perl # it attaches to read or write, then detaches my $go = 1; $SIG{INT} = sub{ $go = 0; &close_m(); #close up the shared mem exit; }; my $segment_hbytes = 0x640; # hex bytes, a multiple of 4k my ($segment_id, $segment_size) = &init_m($segment_hbytes); print "shmid-> $segment_id\tsize-> $segment_size\n"; # Counter Elap +sed time Writes/second # ------------- +---------------------------- my $stime = gettimeofday; my $i = 0; # Result: 2000000 9.27 +134203910828 215718/second while($go) { &write_m($i); $i++; if ( $i >= 2_000_000 ) { $stime = gettimeofday - $stime; my $rpm = int( 2_000_000 / + $stime ); print "$i\t$stime\t$rpm/second\n\n"; last; } #select(undef,undef,undef,.001); last if ! $go; } our $indexdb; # Counter Ela +psed time Writes/second # ------------ +----------------------------- my $file = "/dev/shm/FlexBase/__env.index"; # Result: 2000000 5.7 +3024797439575 349025/second # my $file = "/__env.index"; # Result: 2000000 6.8 +8051080703735 290676/second # my $file = "/flexvault/__env.index"; # Result: 2000000 9.0 +2671384811401 221564/second open( $indexdb,"+<", $file ) or die "Not open: $!"; $stime = gettimeofday; $i = 0; while( 1 ) { &write_mem($i); $i++; if ( $i >= 2_000_000 ) { $stime = gettimeofday - $stime; my $rpm = int( 2_000_000 / + $stime ); print "$i\t$stime\t$rpm/second\n"; last; } } close $indexdb; exit; sub write_mem() { our $indexdb; # Write a string to the shared file. my $message = shift; if ( flock( $indexdb, LOCK_EX ) ) { my $ret = sysseek( $indexdb, 0, 0); # move to beginning of fil +e if ( ! defined $ret ) { die "O04. sysseek failed: $!"; } $ret = syswrite ( $indexdb, $i, length($i) ); if ( $ret != length($i) ) { die "O05. syswrite failed! $!"; } } ## ## Make test ( 1==1 ) to verify syswrite worked correctly. ## Make test ( 1==2 ) to test speed of syswrite to filesystem. ## if ( ( 1==2 )&&( flock( $indexdb, LOCK_SH ) ) ) { my $ret = sysseek( $indexdb, 0, 0); # move to beginning of fil +e if ( ! defined $ret ) { die "O06. sysseek failed: $!"; } $ret = sysread ( $indexdb, my $ni, length($i) ); if ( $ni != $i ) { die "O07. |$ni|$i| $!"; } } return 0; } ################################################################# sub init_m(){ my $segment_hbytes = shift; # Allocate a shared memory segment. my $segment_id = shmget (IPC_PRIVATE, $segment_hbytes, IPC_CREAT | IPC_EXCL | S_IRUSR | S_IWUSR); # Verify the segment's size. my $shmbuffer = ''; shmctl ($segment_id, IPC_STAT, $shmbuffer); my @mdata = unpack("i*",$shmbuffer); #not sure if that is right unp +ack? works :-) return($segment_id, $mdata[9] ); } sub write_m() { # Write a string to the shared memory segment. my $message = shift; shmwrite($segment_id, $message, 0, $segment_size) || die "$!"; #the 0, $segment_size can be broke up into substrings like 0,60 # or 61,195, etc return 0; } sub close_m(){ # Deallocate the shared memory segment. shmctl ($segment_id, IPC_RMID, 0); return 0; } 1; __END__

    Regards...Ed

    "Well done is better than well said." - Benjamin Franklin

Yahoo Content Analyzer
No replies — Read more | Post response
by Your Mother
on Jul 20, 2014 at 16:34

    Inspired by How to transmit text to Yahoo Content Analysis. Not sure how complete or correct it is, just threw it together for fun. Seems to work and Iíll make amendments as necessary or sanely suggested.

    Requires: strictures, LWP::UserAgent, Getopt::Long, Pod::Usage, Path::Tiny.

    #!/usr/bin/env perl use 5.010; use strictures; no warnings "uninitialized"; use LWP::UserAgent; use Getopt::Long; use Pod::Usage; use open qw( :encoding(UTF-8) :std ); use Path::Tiny; # use XML::LibXML; # For expansion... or XML::Rabbit my $service = "http://query.yahooapis.com/v1/public/yql"; my %opt = ( text => undef, url => undef, max => 100 ); # These are, luckily, false by default for Yahoo, so we only care abou +t true. my %boolean = map {; $_ => 1 } qw/ related_entities show_metadata enable_categorizer /; # What we compose to query, e.g. not "verbose" or "file." my %sql = ( %opt, %boolean ); my $ok = GetOptions( \%opt, "text=s", "file=s", "url=s", "max=i", "verbose", "help", keys %boolean ); pod2usage( -verbose => 0, -exitval => 1, -message => "Options were not recognized." ) unless $ok; pod2usage( -verbose => 2 ) if $opt{help}; pod2usage( -verbose => 0, -exitval => 1, -message => "One of these, at most, allowed: text, url, fil +e." ) if 1 < grep defined, @opt{qw/ text url file /}; # Only one, text|file, is allowed by Getopt::Long. $opt{text} ||= path($opt{file})->slurp if $opt{file}; unless ( $opt{url} || $opt{text} ) # Accept from STDIN. { say "Type away. ^D to execute (on *nix anyway)."; chomp( my @input = <> ); $opt{text} = join " ", @input; die "Give some input!\n" unless $opt{text} =~ /\w/; } my @where; for my $key ( keys %opt ) { next unless defined $opt{$key} and exists $sql{$key}; $opt{$key} = "true" if $boolean{$key}; $opt{$key} =~ s/([\\"'\0])/\\$1/g; push @where, sprintf "%s = '%s'", $key, $opt{$key}; } my $q = sprintf "SELECT * FROM contentanalysis.analyze WHERE %s", join " AND ", @where; say "SQL >> $q\n" if $opt{verbose}; my $ua = LWP::UserAgent->new; my $response = $ua->post( $service, [ q => $q ] ); say $response->request->as_string if $opt{verbose}; say $opt{verbose} ? $response->as_string : $response->decoded_content(); exit ! $response->is_success; __END__ =pod =encoding utf8 =head1 Name yahoo-content-analyzer - command-line to query it. =head1 Synopsis yahoo-content-analyzer -text "Perl is a programming language." -text "{command line string}" -file (slurp and submit as text) -url -max [100 is default] -related_entities -show_metadata -enable_categorizer -verbose -help =head1 Description L<https://developer.yahoo.com/search/content/V2/contentAnalysis.html> =head1 Code Repository L<http://perlmonks.org/?node_id=1094394> =head1 See Also L<https://metacpan.org/search?q=YQL>. =head1 Author and License Your Mother, L<http://perlmonks.org/?node_id=248054>. You may redistribute and modify this code under the same terms as Perl itself. =head1 Disclaimer of Warranty No warranty. No means no. =cut

    Updates/Changelog

    • Removed URI, only first draft used it.
commandline ftpssl client with Perl
1 direct reply — Read more / Contribute
by zentara
on Jul 05, 2014 at 12:37
    Recently, all my c-based ftpssl programs stopped working with ssl, namely gftp and lftp. I found that Net::FTPSSL still works great, but it isn't interactive, it allows just automated scripting. So, how to make an interactive session? I first thought of using a gui, but there was no real advantage to the gui, over the commandline, ( not without a huge amount of work ;-) ), so a simple commandline program fit the bill. Here it is. There is a second program below it, which runs it from a pty, in anticipation of channeling it into a Tk or GTk gui; but the gui's seems to have difficulty capturing the tty. If anyone can show how to get the ftpssl tty pty output into a textbox, I would be grateful.

    If you want to experiment on your own machine, Proftd works good when configured with --enable-tls, you can google for instructions.

    I used a little eval trick to pass the commands into the pty.

    Some common commands : list pwd cwd noop nlst mkdir('foo') rmdir('foo') put('somelocalfile', 'remotefile')

    The method set that comes with Net::FTPSSL is simple and easy.

    ftps-z: runs standalone or thru a pty as shown below

    #!/usr/bin/perl use strict; use warnings; use Net::FTPSSL; my $server = "127.0.0.1"; my $username = "someuser"; my $passwd = "somepass"; my @ret; my $ftps = Net::FTPSSL->new($server, Encryption => EXP_CRYPT, Debug => 1, # Croak => 1, ) or die "Can't open $server\n$Net::FTPSSL::ERRSTR"; $ftps->login($username, $passwd) or error("Credential error, $ftps->last_message"); # get default listing and pwd @ret = $ftps->list() or error("Command error, $ftps->last_message"); print "####################\n"; print join "\n", @ret,"\n"; print "####################\n"; # get default pwd @ret = $ftps->pwd or error("Command error, $ftps->last_message"); print "####################\n"; print join "\n", @ret,"\n"; print "####################\n"; if( -t STDIN ) { print "tty\n"; } while(1){ print "Hit Control-C to exit ... otherwise:\n"; print "Enter command: \n"; my $com = <STDIN>; chomp $com; if ($com =~ m/quit/){ print "exiting\n";} # needed this eval to get ftps methods to work with pty my @ret = eval "\$ftps->$com"; if($@) { print "@_\n"; } print "####################\n"; print join "\n", @ret,"\n"; print "####################\n"; if ($com =~ m/quit/){ print "exit command received, ftpssl exiting\n"; + print "Control-C to exit pty, or Shift-PageUp to + view log\n"; last; } } print "at end\n"; exit;
    IO-Pty-driver for above ftps-z
    #!/usr/bin/perl -w # Description: Fool a process into # thinking that STDOUT is a terminal, when in fact # basic PTY code from etcshadow use warnings; use strict; use IO::Pty; $SIG{CHLD} = 'IGNORE'; # for when we quit the ftpssl session my $pty = IO::Pty->new; my $slave = $pty->slave; open TTY,"/dev/tty" or die "not connected to a terminal\n"; $pty->clone_winsize_from(\*TTY); close TTY; my $pid = fork(); die "bad fork: $!\n" unless defined $pid; if (!$pid) { open STDOUT,">&=".$pty->fileno() or die $!; exec "./ftps-z"; }else{ $pty->close(); while (defined (my $line = <$slave>)) { print $line; } } while(1){ my $command = <>; print $slave "$command\n"; }

    I'm not really a human, but I play one on earth.
    Old Perl Programmer Haiku ................... flash japh
Vim: Auto highlight of variables
No replies — Read more | Post response
by Loops
on Jun 27, 2014 at 18:49

    So Ovid made this blog post that gave an example of editing Perl in Vim -- when you move your cursor over a Perl variable it is highlighted in the rest of the document automatically. Quite handy.

    Paul Johnson then made some improvements and put the code in a Git repo so that it's very easy to install with Pathogen in Vim

    After cloning that repo into your Pathogen bundle directory, it pretty much just works as advertised. For some reason it does not work with Tim Popes "vim-sensible" plugin however.

    The highlighting is delayed until you haven't moved your cursor for the number of milliseconds set in the Vim "updatetime" variable. By default this is set to 4000 which is pretty slow. Doing "set ut=50" in your vimrc makes it much snappier.

    Enjoy.

    P.S. Anyone have an updated syntax file for 5.20.0 sub-signatures and other new features?

WWW::Mechanize inventory update for musicstack.com
No replies — Read more | Post response
by maruhige
on Jun 24, 2014 at 11:21

    Spent a bit longer on this than needs be with hindsight, so I figure i'd share the product of that time

    Music stack doesn't have much in the way of an API, instead it requires manual navigation to upload change files. The change file also has an enormous amount of saved customisations on the upload form which would be numbingly tedious to fill out manually in the $mech itself

    So! here's a short and effective means of putting inventory files up on Music Stack, using WWW::Mechanize to navigate from the login screen to the upload screen.

    use WWW::Mechanize; my $username = 'x@example.com'; my $password = 'mypw'; my $upfile = '/path/to/additions.csv'; my $mech = WWW::Mechanize->new() or die $!; $mech->cookie_jar(HTTP::Cookies->new()); $mech->get(q#http://www.musicstack.com/login.cgi#) or die $!; #need to use sequential identifiers when forms are either nameless + or share the same name $mech->form_number(3); $mech->field ('user' => $username); $mech->field ('pw' => $password); $mech->click_button(name => "login"); #now on the user account page $mech->follow_link( text => 'Upload' );#case sensitive #now on the inventory management page $mech->form_name('form'); # 2 forms on page - other is 'search' # 3 options here - add is incremental $mech->set_fields('delete' => 'add'); $mech->field('upfile' => $upfile ); $mech->click_button(value => 'Upload File'); #the file is uploaded and the status screen displayed here print $mech-> content();
Tk Tartaglia's triangle fun - Pascal's triangle fun
2 direct replies — Read more / Contribute
by Discipulus
on Jun 17, 2014 at 12:56
           Dedicated to my father who studied the other Tartaglia
    After more then one month of sparetime works and 35 subversion i'm very happy to present you:

    16 fun experiments with the Tartaglia's triangle

    This is a Perl Tk program that shows many of the properties of such incredible triangle: you can modify the aspect of the triangle itself and of the output window and of the help pages too.

    In Italy the name of the arithmetic triangle is dedicated Tartaglia so I want to present with this name.

    I'm not a mathematician and the math used in the code is something late Middle Age, but works.

    If someone wish to improve this program i will be very happy: inernal math used, better explication in output windows, or even typos spot(i'm not english native, as you can guess) or suggestion are welcome. In fact i wish this program to be used in educational context.

    Have fun!

    L*


    Update 1/07/2014: commented lines 188-190 and 555 (printing debug info for windows dimensions and positioning).

    L*

    There are no rules, there are no thumbs..
    Reinvent the wheel, then learn The Wheel; may be one day you reinvent one of THE WHEELS.
Storing Experience for Posterity
4 direct replies — Read more / Contribute
by GotToBTru
on Jun 12, 2014 at 10:34

    I put the following together to scrape experience, level and writeups off my profile page and store it in a text file on my computer, to record my progress through the Monastery. A scheduled task runs this once a day.

    use strict; use warnings; use LWP::Simple; use URI::URL; my $date=`ECHO %DATE:~10,4%%DATE:~4,2%%DATE:~7,2%`; # YYYYMMDD my $url = url('http://perlmonks.org/?node_id=844862'); my $content = get($url); $content =~ s/\cJ//g; $content =~ s/\cM//g; my ($experience, $level, $posts) = ($content =~ /Experience:\D+(\d+).+ Level:.+([A-Z][a-z]+\s+\(\d+\)).+ Writeups:.+>(\d+)</x); open my $ofh, '>>','perl_xp.dat'; printf $ofh "%d,%d,%d,%s\n",$date,$experience,$posts,$level; close($ofh);

    There is probably a way to do this in Javascript that could be included in the Free Nodelet, but that's beyond my skill level.

    Update

    Improved version here.

    1 Peter 4:10

Add your CUFP
Title:
CUFP:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others meditating upon the Monastery: (9)
    As of 2015-05-05 13:20 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      In my home, the TV remote control is ...









      Results (119 votes), past polls