| 1 | .\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.32 |
| 2 | .\" |
| 3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
| 5 | .de Sh \" Subsection heading |
| 6 | .br |
| 7 | .if t .Sp |
| 8 | .ne 5 |
| 9 | .PP |
| 10 | \fB\\$1\fR |
| 11 | .PP |
| 12 | .. |
| 13 | .de Sp \" Vertical space (when we can't use .PP) |
| 14 | .if t .sp .5v |
| 15 | .if n .sp |
| 16 | .. |
| 17 | .de Vb \" Begin verbatim text |
| 18 | .ft CW |
| 19 | .nf |
| 20 | .ne \\$1 |
| 21 | .. |
| 22 | .de Ve \" End verbatim text |
| 23 | .ft R |
| 24 | .fi |
| 25 | .. |
| 26 | .\" Set up some character translations and predefined strings. \*(-- will |
| 27 | .\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left |
| 28 | .\" double quote, and \*(R" will give a right double quote. | will give a |
| 29 | .\" real vertical bar. \*(C+ will give a nicer C++. Capital omega is used to |
| 30 | .\" do unbreakable dashes and therefore won't be available. \*(C` and \*(C' |
| 31 | .\" expand to `' in nroff, nothing in troff, for use with C<>. |
| 32 | .tr \(*W-|\(bv\*(Tr |
| 33 | .ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p' |
| 34 | .ie n \{\ |
| 35 | . ds -- \(*W- |
| 36 | . ds PI pi |
| 37 | . if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch |
| 38 | . if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\" diablo 12 pitch |
| 39 | . ds L" "" |
| 40 | . ds R" "" |
| 41 | . ds C` "" |
| 42 | . ds C' "" |
| 43 | 'br\} |
| 44 | .el\{\ |
| 45 | . ds -- \|\(em\| |
| 46 | . ds PI \(*p |
| 47 | . ds L" `` |
| 48 | . ds R" '' |
| 49 | 'br\} |
| 50 | .\" |
| 51 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 52 | .\" titles (.TH), headers (.SH), subsections (.Sh), items (.Ip), and index |
| 53 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 54 | .\" output yourself in some meaningful fashion. |
| 55 | .if \nF \{\ |
| 56 | . de IX |
| 57 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 58 | .. |
| 59 | . nr % 0 |
| 60 | . rr F |
| 61 | .\} |
| 62 | .\" |
| 63 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 64 | .\" way too many mistakes in technical documents. |
| 65 | .hy 0 |
| 66 | .if n .na |
| 67 | .\" |
| 68 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 69 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 70 | . \" fudge factors for nroff and troff |
| 71 | .if n \{\ |
| 72 | . ds #H 0 |
| 73 | . ds #V .8m |
| 74 | . ds #F .3m |
| 75 | . ds #[ \f1 |
| 76 | . ds #] \fP |
| 77 | .\} |
| 78 | .if t \{\ |
| 79 | . ds #H ((1u-(\\\\n(.fu%2u))*.13m) |
| 80 | . ds #V .6m |
| 81 | . ds #F 0 |
| 82 | . ds #[ \& |
| 83 | . ds #] \& |
| 84 | .\} |
| 85 | . \" simple accents for nroff and troff |
| 86 | .if n \{\ |
| 87 | . ds ' \& |
| 88 | . ds ` \& |
| 89 | . ds ^ \& |
| 90 | . ds , \& |
| 91 | . ds ~ ~ |
| 92 | . ds / |
| 93 | .\} |
| 94 | .if t \{\ |
| 95 | . ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u" |
| 96 | . ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u' |
| 97 | . ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u' |
| 98 | . ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u' |
| 99 | . ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u' |
| 100 | . ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u' |
| 101 | .\} |
| 102 | . \" troff and (daisy-wheel) nroff accents |
| 103 | .ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V' |
| 104 | .ds 8 \h'\*(#H'\(*b\h'-\*(#H' |
| 105 | .ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#] |
| 106 | .ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H' |
| 107 | .ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u' |
| 108 | .ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#] |
| 109 | .ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#] |
| 110 | .ds ae a\h'-(\w'a'u*4/10)'e |
| 111 | .ds Ae A\h'-(\w'A'u*4/10)'E |
| 112 | . \" corrections for vroff |
| 113 | .if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u' |
| 114 | .if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u' |
| 115 | . \" for low resolution devices (crt and lpr) |
| 116 | .if \n(.H>23 .if \n(.V>19 \ |
| 117 | \{\ |
| 118 | . ds : e |
| 119 | . ds 8 ss |
| 120 | . ds o a |
| 121 | . ds d- d\h'-1'\(ga |
| 122 | . ds D- D\h'-1'\(hy |
| 123 | . ds th \o'bp' |
| 124 | . ds Th \o'LP' |
| 125 | . ds ae ae |
| 126 | . ds Ae AE |
| 127 | .\} |
| 128 | .rm #[ #] #H #V #F C |
| 129 | .\" ======================================================================== |
| 130 | .\" |
| 131 | .IX Title "PERLHACK 1" |
| 132 | .TH PERLHACK 1 "2006-01-07" "perl v5.8.8" "Perl Programmers Reference Guide" |
| 133 | .SH "NAME" |
| 134 | perlhack \- How to hack at the Perl internals |
| 135 | .SH "DESCRIPTION" |
| 136 | .IX Header "DESCRIPTION" |
| 137 | This document attempts to explain how Perl development takes place, |
| 138 | and ends with some suggestions for people wanting to become bona fide |
| 139 | porters. |
| 140 | .PP |
| 141 | The perl5\-porters mailing list is where the Perl standard distribution |
| 142 | is maintained and developed. The list can get anywhere from 10 to 150 |
| 143 | messages a day, depending on the heatedness of the debate. Most days |
| 144 | there are two or three patches, extensions, features, or bugs being |
| 145 | discussed at a time. |
| 146 | .PP |
| 147 | A searchable archive of the list is at either: |
| 148 | .PP |
| 149 | .Vb 1 |
| 150 | \& http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ |
| 151 | .Ve |
| 152 | .PP |
| 153 | or |
| 154 | .PP |
| 155 | .Vb 1 |
| 156 | \& http://archive.develooper.com/perl5-porters@perl.org/ |
| 157 | .Ve |
| 158 | .PP |
| 159 | List subscribers (the porters themselves) come in several flavours. |
| 160 | Some are quiet curious lurkers, who rarely pitch in and instead watch |
| 161 | the ongoing development to ensure they're forewarned of new changes or |
| 162 | features in Perl. Some are representatives of vendors, who are there |
| 163 | to make sure that Perl continues to compile and work on their |
| 164 | platforms. Some patch any reported bug that they know how to fix, |
| 165 | some are actively patching their pet area (threads, Win32, the regexp |
| 166 | engine), while others seem to do nothing but complain. In other |
| 167 | words, it's your usual mix of technical people. |
| 168 | .PP |
| 169 | Over this group of porters presides Larry Wall. He has the final word |
| 170 | in what does and does not change in the Perl language. Various |
| 171 | releases of Perl are shepherded by a \*(L"pumpking\*(R", a porter |
| 172 | responsible for gathering patches, deciding on a patch\-by\-patch, |
| 173 | feature-by-feature basis what will and will not go into the release. |
| 174 | For instance, Gurusamy Sarathy was the pumpking for the 5.6 release of |
| 175 | Perl, and Jarkko Hietaniemi was the pumpking for the 5.8 release, and |
| 176 | Rafael Garcia-Suarez holds the pumpking crown for the 5.10 release. |
| 177 | .PP |
| 178 | In addition, various people are pumpkings for different things. For |
| 179 | instance, Andy Dougherty and Jarkko Hietaniemi did a grand job as the |
| 180 | \&\fIConfigure\fR pumpkin up till the 5.8 release. For the 5.10 release |
| 181 | H.Merijn Brand took over. |
| 182 | .PP |
| 183 | Larry sees Perl development along the lines of the \s-1US\s0 government: |
| 184 | there's the Legislature (the porters), the Executive branch (the |
| 185 | pumpkings), and the Supreme Court (Larry). The legislature can |
| 186 | discuss and submit patches to the executive branch all they like, but |
| 187 | the executive branch is free to veto them. Rarely, the Supreme Court |
| 188 | will side with the executive branch over the legislature, or the |
| 189 | legislature over the executive branch. Mostly, however, the |
| 190 | legislature and the executive branch are supposed to get along and |
| 191 | work out their differences without impeachment or court cases. |
| 192 | .PP |
| 193 | You might sometimes see reference to Rule 1 and Rule 2. Larry's power |
| 194 | as Supreme Court is expressed in The Rules: |
| 195 | .IP "1" 4 |
| 196 | .IX Item "1" |
| 197 | Larry is always by definition right about how Perl should behave. |
| 198 | This means he has final veto power on the core functionality. |
| 199 | .IP "2" 4 |
| 200 | .IX Item "2" |
| 201 | Larry is allowed to change his mind about any matter at a later date, |
| 202 | regardless of whether he previously invoked Rule 1. |
| 203 | .PP |
| 204 | Got that? Larry is always right, even when he was wrong. It's rare |
| 205 | to see either Rule exercised, but they are often alluded to. |
| 206 | .PP |
| 207 | New features and extensions to the language are contentious, because |
| 208 | the criteria used by the pumpkings, Larry, and other porters to decide |
| 209 | which features should be implemented and incorporated are not codified |
| 210 | in a few small design goals as with some other languages. Instead, |
| 211 | the heuristics are flexible and often difficult to fathom. Here is |
| 212 | one person's list, roughly in decreasing order of importance, of |
| 213 | heuristics that new features have to be weighed against: |
| 214 | .IP "Does concept match the general goals of Perl?" 4 |
| 215 | .IX Item "Does concept match the general goals of Perl?" |
| 216 | These haven't been written anywhere in stone, but one approximation |
| 217 | is: |
| 218 | .Sp |
| 219 | .Vb 5 |
| 220 | \& 1. Keep it fast, simple, and useful. |
| 221 | \& 2. Keep features/concepts as orthogonal as possible. |
| 222 | \& 3. No arbitrary limits (platforms, data sizes, cultures). |
| 223 | \& 4. Keep it open and exciting to use/patch/advocate Perl everywhere. |
| 224 | \& 5. Either assimilate new technologies, or build bridges to them. |
| 225 | .Ve |
| 226 | .IP "Where is the implementation?" 4 |
| 227 | .IX Item "Where is the implementation?" |
| 228 | All the talk in the world is useless without an implementation. In |
| 229 | almost every case, the person or people who argue for a new feature |
| 230 | will be expected to be the ones who implement it. Porters capable |
| 231 | of coding new features have their own agendas, and are not available |
| 232 | to implement your (possibly good) idea. |
| 233 | .IP "Backwards compatibility" 4 |
| 234 | .IX Item "Backwards compatibility" |
| 235 | It's a cardinal sin to break existing Perl programs. New warnings are |
| 236 | contentious\*(--some say that a program that emits warnings is not |
| 237 | broken, while others say it is. Adding keywords has the potential to |
| 238 | break programs, changing the meaning of existing token sequences or |
| 239 | functions might break programs. |
| 240 | .IP "Could it be a module instead?" 4 |
| 241 | .IX Item "Could it be a module instead?" |
| 242 | Perl 5 has extension mechanisms, modules and \s-1XS\s0, specifically to avoid |
| 243 | the need to keep changing the Perl interpreter. You can write modules |
| 244 | that export functions, you can give those functions prototypes so they |
| 245 | can be called like built-in functions, you can even write \s-1XS\s0 code to |
| 246 | mess with the runtime data structures of the Perl interpreter if you |
| 247 | want to implement really complicated things. If it can be done in a |
| 248 | module instead of in the core, it's highly unlikely to be added. |
| 249 | .IP "Is the feature generic enough?" 4 |
| 250 | .IX Item "Is the feature generic enough?" |
| 251 | Is this something that only the submitter wants added to the language, |
| 252 | or would it be broadly useful? Sometimes, instead of adding a feature |
| 253 | with a tight focus, the porters might decide to wait until someone |
| 254 | implements the more generalized feature. For instance, instead of |
| 255 | implementing a \*(L"delayed evaluation\*(R" feature, the porters are waiting |
| 256 | for a macro system that would permit delayed evaluation and much more. |
| 257 | .IP "Does it potentially introduce new bugs?" 4 |
| 258 | .IX Item "Does it potentially introduce new bugs?" |
| 259 | Radical rewrites of large chunks of the Perl interpreter have the |
| 260 | potential to introduce new bugs. The smaller and more localized the |
| 261 | change, the better. |
| 262 | .IP "Does it preclude other desirable features?" 4 |
| 263 | .IX Item "Does it preclude other desirable features?" |
| 264 | A patch is likely to be rejected if it closes off future avenues of |
| 265 | development. For instance, a patch that placed a true and final |
| 266 | interpretation on prototypes is likely to be rejected because there |
| 267 | are still options for the future of prototypes that haven't been |
| 268 | addressed. |
| 269 | .IP "Is the implementation robust?" 4 |
| 270 | .IX Item "Is the implementation robust?" |
| 271 | Good patches (tight code, complete, correct) stand more chance of |
| 272 | going in. Sloppy or incorrect patches might be placed on the back |
| 273 | burner until the pumpking has time to fix, or might be discarded |
| 274 | altogether without further notice. |
| 275 | .IP "Is the implementation generic enough to be portable?" 4 |
| 276 | .IX Item "Is the implementation generic enough to be portable?" |
| 277 | The worst patches make use of a system-specific features. It's highly |
| 278 | unlikely that nonportable additions to the Perl language will be |
| 279 | accepted. |
| 280 | .IP "Is the implementation tested?" 4 |
| 281 | .IX Item "Is the implementation tested?" |
| 282 | Patches which change behaviour (fixing bugs or introducing new features) |
| 283 | must include regression tests to verify that everything works as expected. |
| 284 | Without tests provided by the original author, how can anyone else changing |
| 285 | perl in the future be sure that they haven't unwittingly broken the behaviour |
| 286 | the patch implements? And without tests, how can the patch's author be |
| 287 | confident that his/her hard work put into the patch won't be accidentally |
| 288 | thrown away by someone in the future? |
| 289 | .IP "Is there enough documentation?" 4 |
| 290 | .IX Item "Is there enough documentation?" |
| 291 | Patches without documentation are probably ill-thought out or |
| 292 | incomplete. Nothing can be added without documentation, so submitting |
| 293 | a patch for the appropriate manpages as well as the source code is |
| 294 | always a good idea. |
| 295 | .IP "Is there another way to do it?" 4 |
| 296 | .IX Item "Is there another way to do it?" |
| 297 | Larry said "Although the Perl Slogan is \fIThere's More Than One Way |
| 298 | to Do It\fR, I hesitate to make 10 ways to do something". This is a |
| 299 | tricky heuristic to navigate, though\*(--one man's essential addition is |
| 300 | another man's pointless cruft. |
| 301 | .IP "Does it create too much work?" 4 |
| 302 | .IX Item "Does it create too much work?" |
| 303 | Work for the pumpking, work for Perl programmers, work for module |
| 304 | authors, ... Perl is supposed to be easy. |
| 305 | .IP "Patches speak louder than words" 4 |
| 306 | .IX Item "Patches speak louder than words" |
| 307 | Working code is always preferred to pie-in-the-sky ideas. A patch to |
| 308 | add a feature stands a much higher chance of making it to the language |
| 309 | than does a random feature request, no matter how fervently argued the |
| 310 | request might be. This ties into \*(L"Will it be useful?\*(R", as the fact |
| 311 | that someone took the time to make the patch demonstrates a strong |
| 312 | desire for the feature. |
| 313 | .PP |
| 314 | If you're on the list, you might hear the word \*(L"core\*(R" bandied |
| 315 | around. It refers to the standard distribution. \*(L"Hacking on the |
| 316 | core\*(R" means you're changing the C source code to the Perl |
| 317 | interpreter. \*(L"A core module\*(R" is one that ships with Perl. |
| 318 | .Sh "Keeping in sync" |
| 319 | .IX Subsection "Keeping in sync" |
| 320 | The source code to the Perl interpreter, in its different versions, is |
| 321 | kept in a repository managed by a revision control system ( which is |
| 322 | currently the Perforce program, see http://perforce.com/ ). The |
| 323 | pumpkings and a few others have access to the repository to check in |
| 324 | changes. Periodically the pumpking for the development version of Perl |
| 325 | will release a new version, so the rest of the porters can see what's |
| 326 | changed. The current state of the main trunk of repository, and patches |
| 327 | that describe the individual changes that have happened since the last |
| 328 | public release are available at this location: |
| 329 | .PP |
| 330 | .Vb 2 |
| 331 | \& http://public.activestate.com/pub/apc/ |
| 332 | \& ftp://public.activestate.com/pub/apc/ |
| 333 | .Ve |
| 334 | .PP |
| 335 | If you're looking for a particular change, or a change that affected |
| 336 | a particular set of files, you may find the \fBPerl Repository Browser\fR |
| 337 | useful: |
| 338 | .PP |
| 339 | .Vb 1 |
| 340 | \& http://public.activestate.com/cgi-bin/perlbrowse |
| 341 | .Ve |
| 342 | .PP |
| 343 | You may also want to subscribe to the perl5\-changes mailing list to |
| 344 | receive a copy of each patch that gets submitted to the maintenance |
| 345 | and development \*(L"branches\*(R" of the perl repository. See |
| 346 | http://lists.perl.org/ for subscription information. |
| 347 | .PP |
| 348 | If you are a member of the perl5\-porters mailing list, it is a good |
| 349 | thing to keep in touch with the most recent changes. If not only to |
| 350 | verify if what you would have posted as a bug report isn't already |
| 351 | solved in the most recent available perl development branch, also |
| 352 | known as perl\-current, bleading edge perl, bleedperl or bleadperl. |
| 353 | .PP |
| 354 | Needless to say, the source code in perl-current is usually in a perpetual |
| 355 | state of evolution. You should expect it to be very buggy. Do \fBnot\fR use |
| 356 | it for any purpose other than testing and development. |
| 357 | .PP |
| 358 | Keeping in sync with the most recent branch can be done in several ways, |
| 359 | but the most convenient and reliable way is using \fBrsync\fR, available at |
| 360 | ftp://rsync.samba.org/pub/rsync/ . (You can also get the most recent |
| 361 | branch by \s-1FTP\s0.) |
| 362 | .PP |
| 363 | If you choose to keep in sync using rsync, there are two approaches |
| 364 | to doing so: |
| 365 | .IP "rsync'ing the source tree" 4 |
| 366 | .IX Item "rsync'ing the source tree" |
| 367 | Presuming you are in the directory where your perl source resides |
| 368 | and you have rsync installed and available, you can \*(L"upgrade\*(R" to |
| 369 | the bleadperl using: |
| 370 | .Sp |
| 371 | .Vb 1 |
| 372 | \& # rsync -avz rsync://public.activestate.com/perl-current/ . |
| 373 | .Ve |
| 374 | .Sp |
| 375 | This takes care of updating every single item in the source tree to |
| 376 | the latest applied patch level, creating files that are new (to your |
| 377 | distribution) and setting date/time stamps of existing files to |
| 378 | reflect the bleadperl status. |
| 379 | .Sp |
| 380 | Note that this will not delete any files that were in '.' before |
| 381 | the rsync. Once you are sure that the rsync is running correctly, |
| 382 | run it with the \-\-delete and the \-\-dry\-run options like this: |
| 383 | .Sp |
| 384 | .Vb 1 |
| 385 | \& # rsync -avz --delete --dry-run rsync://public.activestate.com/perl-current/ . |
| 386 | .Ve |
| 387 | .Sp |
| 388 | This will \fIsimulate\fR an rsync run that also deletes files not |
| 389 | present in the bleadperl master copy. Observe the results from |
| 390 | this run closely. If you are sure that the actual run would delete |
| 391 | no files precious to you, you could remove the '\-\-dry\-run' option. |
| 392 | .Sp |
| 393 | You can than check what patch was the latest that was applied by |
| 394 | looking in the file \fB.patch\fR, which will show the number of the |
| 395 | latest patch. |
| 396 | .Sp |
| 397 | If you have more than one machine to keep in sync, and not all of |
| 398 | them have access to the \s-1WAN\s0 (so you are not able to rsync all the |
| 399 | source trees to the real source), there are some ways to get around |
| 400 | this problem. |
| 401 | .RS 4 |
| 402 | .IP "Using rsync over the \s-1LAN\s0" 4 |
| 403 | .IX Item "Using rsync over the LAN" |
| 404 | Set up a local rsync server which makes the rsynced source tree |
| 405 | available to the \s-1LAN\s0 and sync the other machines against this |
| 406 | directory. |
| 407 | .Sp |
| 408 | From http://rsync.samba.org/README.html : |
| 409 | .Sp |
| 410 | .Vb 5 |
| 411 | \& "Rsync uses rsh or ssh for communication. It does not need to be |
| 412 | \& setuid and requires no special privileges for installation. It |
| 413 | \& does not require an inetd entry or a daemon. You must, however, |
| 414 | \& have a working rsh or ssh system. Using ssh is recommended for |
| 415 | \& its security features." |
| 416 | .Ve |
| 417 | .IP "Using pushing over the \s-1NFS\s0" 4 |
| 418 | .IX Item "Using pushing over the NFS" |
| 419 | Having the other systems mounted over the \s-1NFS\s0, you can take an |
| 420 | active pushing approach by checking the just updated tree against |
| 421 | the other not-yet synced trees. An example would be |
| 422 | .Sp |
| 423 | .Vb 1 |
| 424 | \& #!/usr/bin/perl -w |
| 425 | .Ve |
| 426 | .Sp |
| 427 | .Vb 2 |
| 428 | \& use strict; |
| 429 | \& use File::Copy; |
| 430 | .Ve |
| 431 | .Sp |
| 432 | .Vb 4 |
| 433 | \& my %MF = map { |
| 434 | \& m/(\eS+)/; |
| 435 | \& $1 => [ (stat $1)[2, 7, 9] ]; # mode, size, mtime |
| 436 | \& } `cat MANIFEST`; |
| 437 | .Ve |
| 438 | .Sp |
| 439 | .Vb 1 |
| 440 | \& my %remote = map { $_ => "/$_/pro/3gl/CPAN/perl-5.7.1" } qw(host1 host2); |
| 441 | .Ve |
| 442 | .Sp |
| 443 | .Vb 18 |
| 444 | \& foreach my $host (keys %remote) { |
| 445 | \& unless (-d $remote{$host}) { |
| 446 | \& print STDERR "Cannot Xsync for host $host\en"; |
| 447 | \& next; |
| 448 | \& } |
| 449 | \& foreach my $file (keys %MF) { |
| 450 | \& my $rfile = "$remote{$host}/$file"; |
| 451 | \& my ($mode, $size, $mtime) = (stat $rfile)[2, 7, 9]; |
| 452 | \& defined $size or ($mode, $size, $mtime) = (0, 0, 0); |
| 453 | \& $size == $MF{$file}[1] && $mtime == $MF{$file}[2] and next; |
| 454 | \& printf "%4s %-34s %8d %9d %8d %9d\en", |
| 455 | \& $host, $file, $MF{$file}[1], $MF{$file}[2], $size, $mtime; |
| 456 | \& unlink $rfile; |
| 457 | \& copy ($file, $rfile); |
| 458 | \& utime time, $MF{$file}[2], $rfile; |
| 459 | \& chmod $MF{$file}[0], $rfile; |
| 460 | \& } |
| 461 | \& } |
| 462 | .Ve |
| 463 | .Sp |
| 464 | though this is not perfect. It could be improved with checking |
| 465 | file checksums before updating. Not all \s-1NFS\s0 systems support |
| 466 | reliable utime support (when used over the \s-1NFS\s0). |
| 467 | .RE |
| 468 | .RS 4 |
| 469 | .RE |
| 470 | .IP "rsync'ing the patches" 4 |
| 471 | .IX Item "rsync'ing the patches" |
| 472 | The source tree is maintained by the pumpking who applies patches to |
| 473 | the files in the tree. These patches are either created by the |
| 474 | pumpking himself using \f(CW\*(C`diff \-c\*(C'\fR after updating the file manually or |
| 475 | by applying patches sent in by posters on the perl5\-porters list. |
| 476 | These patches are also saved and rsync'able, so you can apply them |
| 477 | yourself to the source files. |
| 478 | .Sp |
| 479 | Presuming you are in a directory where your patches reside, you can |
| 480 | get them in sync with |
| 481 | .Sp |
| 482 | .Vb 1 |
| 483 | \& # rsync -avz rsync://public.activestate.com/perl-current-diffs/ . |
| 484 | .Ve |
| 485 | .Sp |
| 486 | This makes sure the latest available patch is downloaded to your |
| 487 | patch directory. |
| 488 | .Sp |
| 489 | It's then up to you to apply these patches, using something like |
| 490 | .Sp |
| 491 | .Vb 5 |
| 492 | \& # last=`ls -t *.gz | sed q` |
| 493 | \& # rsync -avz rsync://public.activestate.com/perl-current-diffs/ . |
| 494 | \& # find . -name '*.gz' -newer $last -exec gzcat {} \e; >blead.patch |
| 495 | \& # cd ../perl-current |
| 496 | \& # patch -p1 -N <../perl-current-diffs/blead.patch |
| 497 | .Ve |
| 498 | .Sp |
| 499 | or, since this is only a hint towards how it works, use CPAN-patchaperl |
| 500 |