[PATCH] HP-UX shared libparrot support
This patch adds the necessary hints for HP-UX to build using shared libraries by default.I only have access to gcc on HP-UX, but the necessary compiler flags for the HP commericial compiler are there too.Cheers, Nick Index: config/init/hints/hpux.pm === --- config/init/hints/hpux.pm (revision 10936) +++ config/init/hints/hpux.pm (working copy) @@ -14,7 +14,56 @@ $libs .= ' -lpthread'; } -$conf->data->set(libs => $libs); +# It is possible to have various permutations of compiler and linker on +# HP-UX: +# +# * The bundled (K&R) compiler/linker, which won't ever build parrot +# * The commercial (c89) compiler and HP linker +# * gcc with the HP linker +# * gcc with the GNU linker +# +# Ever though we may have gcc, we need to know which linker is being used +# +# Note: The only configuration currently available to me is gcc with the +# HP linker, so confirmation on other permutations would be appreciated + +my $cc_shared = $conf->data->get('cc_shared'); +my $ld_share_flags = $conf->data->get('ld_share_flags'); + +my ($rpath, $ld_libparrot_soname); + +if ($ld_share_flags eq '-b') +{ + # HP linker + + $rpath = '-Wl,+s -Wl,+b -Wl,'; + + $ld_libparrot_soname = '+h libparrot$(SHARE_EXT).$(SOVERSION) '; +} +else +{ + # GNU linker (based on Linux) + + $rpath = '-Wl,-rpath='; + + $ld_libparrot_soname='-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION) '; +} + + +$conf->data->set + ( +libs => $libs, + +has_dynamic_linking => 1, +parrot_is_shared=> 1, + +libparrot_shared => 'libparrot$(SHARE_EXT).$(SOVERSION)', +libparrot_shared_alias => 'libparrot$(SHARE_EXT)', + +rpath => $rpath, + +ld_libparrot_soname => $ld_libparrot_soname, +); } 1;
[PATCH] Small tweak to libparrot configure for rpath
This patch does a check for the existence of the 'rpath' attribute before using it.There will be platforms which have dynamic loading, but no capability to hard code the path of the library into the executable. We therefore need to cater for the case where parrot_is_shared is set, but rpath is not. [They will probably need to use LD_LIBRARY_PATH or another environment variable as a workaround] Nick Index: config/inter/libparrot.pm === --- config/inter/libparrot.pm (revision 10936) +++ config/inter/libparrot.pm (working copy) @@ -53,7 +53,7 @@ ); $conf->data->set( -rpath_blib => ($parrot_is_shared) +rpath_blib => ($parrot_is_shared) && $conf->data->get('rpath') ? $conf->data->get('rpath') . $conf->data->get('build_dir') . $conf->data->get('slash')
Re: [PATCH] HP-UX shared libparrot support
On Fri, 6 Jan 2006 11:02:17 +, Nick Glencross <[EMAIL PROTECTED]> wrote: > This patch adds the necessary hints for HP-UX to build using shared > libraries by default. > > I only have access to gcc on HP-UX, but the necessary compiler flags for the > HP commericial compiler are there too. FYI: perl5 (and probably a lot more) does not support the combo gcc + GNU ld in 32bit bode, and prefers GNU ld with gcc in 64bit mode. This is due to issues in binutils, and cannot be blamed on either HP ld or gcc -- H.Merijn BrandAmsterdam Perl Mongers (http://amsterdam.pm.org/) using Perl 5.6.2, 5.8.0, 5.8.5, & 5.9.2 on HP-UX 10.20, 11.00 & 11.11, AIX 4.3 & 5.2, SuSE 9.2 & 9.3, and Cygwin. http://www.cmve.net/~merijn Smoking perl: http://www.test-smoke.org,perl QA: http://qa.perl.org reports to: [EMAIL PROTECTED],perl-qa@perl.org
Conversion of string to int (in PIR)
This PIR program: .sub 'main' :main print_as_integer('-4') print_as_integer('X-4') print_as_integer('--4') .end .sub 'print_as_integer' .param string s $I0 = s print $I0 print "\n" .end produces this output: -4 0 -4 I think the last line should be "0", but if anyone thinks that "-4" is correct please say so before I report it as a bug... Thanks. Regards, Roger Browne
Re: Conversion of string to int (in PIR)
On 1/6/06, Roger Browne <[EMAIL PROTECTED]> wrote: > This PIR program: > >.sub 'main' :main > print_as_integer('-4') > print_as_integer('X-4') > print_as_integer('--4') >.end > >.sub 'print_as_integer' > .param string s > $I0 = s > print $I0 > print "\n" >.end > > produces this output: > >-4 >0 >-4 > > I think the last line should be "0", but if anyone thinks that "-4" is > correct please say so before I report it as a bug... > looks like a bug to me. please report it. ~jerry
Paper on Parrot [2]
Hello, Some time ago I announced to be writing a paper on the architecture of Parrot. It's not completely finished, but most things are in. If you are interested, you can read it at http://members.home.nl/joeijoei/parrot/paper.pdf It proved a bit harder than I had expected, and a bit more work. I hope it's worthwhile to read. I'll be finishing it this weekend. If you read it and think to see incorrect information, please inform me. (most information is from mailing lists, docs and Perl6 essentials 2nd ed., so some info could be out-of-date) Kind regards, Klaas-Jan Stol
Re: Conversion of string to int (in PIR)
On Jan 6, 2006, at 13:59, Roger Browne wrote: This PIR program: .sub 'main' :main print_as_integer('-4') print_as_integer('X-4') print_as_integer('--4') .end [ ... ] I think the last line should be "0", but if anyone thinks that "-4" is correct please say so before I report it as a bug... Yup - fixed in r10938. Thanks for testing. Roger Browne leo
Re: Conversion of string to int (in PIR)
On Fri, 2006-01-06 at 17:15 +0100, Leopold Toetsch wrote: > Yup - fixed in r10938. Thanks for testing. OK, then please ignore that patch that I just sent. Thanks for the quick work! Regards, Roger Browne
[PATCH] FreeBSD shared libparrot support
This should make the FreeBSD build support building a shared libparrot. -- - Anders Nor Berle Index: CREDITS === --- CREDITS (revision 10936) +++ CREDITS (working copy) @@ -46,8 +46,9 @@ D: ParTcl builtins E: [EMAIL PROTECTED] -N: Anders Nor Berle a.k.a. Debolaz -D: cleanup in MANIFESTs and Configure.pl +N: Anders Nor Berle +D: Some cleanups and FreeBSD related fixes. +E: [EMAIL PROTECTED] N: Andrew Rodland D: vim syntax files and editor doc Index: config/init/hints/freebsd.pm === --- config/init/hints/freebsd.pm(revision 10936) +++ config/init/hints/freebsd.pm(working copy) @@ -28,8 +28,15 @@ $libs .= ' -pthread'; $conf->data->set( -libs => $libs, -link => 'g++', +libs=> $libs, +link=> 'g++', +rpath => '-Wl,-R', + +has_dynamic_linking => 1, +parrot_is_shared=> 1, +libparrot_shared=> 'libparrot$(SHARE_EXT).$(SOVERSION)', +libparrot_shared_alias => 'libparrot$(SHARE_EXT)', +libparrot_soname=> '-Wl,-soname=libparrot$(SHARE_EXT).$(SOVERSION)', ); }
Re: [PATCH] FreeBSD shared libparrot support
On 1/6/06, Anders Nor Berle <[EMAIL PROTECTED]> wrote: > This should make the FreeBSD build support building a shared libparrot. > thanks, applied as r10939. ~jerry
[PATCH] Fix installation of include files
This patch should make parrot install includes in parrot/include/parrot instead of parrot/include/include/parrot. Also makes it possible to use --includedir to install them somewhere more usefull. :-) -- - Anders Nor Berle Index: tools/dev/install_files.pl === --- tools/dev/install_files.pl (revision 10939) +++ tools/dev/install_files.pl (working copy) @@ -182,6 +182,7 @@ $dest .= $exe; } } elsif ($meta{include}) { +$dest =~ s|^include/||; $dest = File::Spec->catdir($options{includedir}, $dest); } else { $dest = File::Spec->catdir($options{prefix}, $dest);
[perl #38176] [PATCH] Fix string-to-integer conversion with multiple leading spaces
# New Ticket Created by Roger Browne # Please include the string: [perl #38176] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38176 > Until r10938, string-to-integer conversion was possible even when the string contained more than one space before the start of the integer. This patch modifies src/string.t to make this work again. This patch also modifies t/op/string.t to add a test for this case, and for other corner-cases of string-to-integer conversion. $ diffstat s2i.patch src/string.c |4 +++- t/op/string.t | 26 +- 2 files changed, 28 insertions(+), 2 deletions(-) Regards, Roger Browne Index: src/string.c === --- src/string.c (revision 10939) +++ src/string.c (working copy) @@ -1930,8 +1930,10 @@ sign = -1; in_number = 1; } -else if (c == '+' || isspace(c)) +else if (c == '+') in_number = 1; +else if (isspace(c)) +; else break; } Index: t/op/string.t === --- t/op/string.t (revision 10939) +++ t/op/string.t (working copy) @@ -2824,11 +2824,23 @@ Cannot get character before beginning of string OUTPUT -pir_output_is(<<'CODE', <<'OUT', 'string_to_int --4'); +pir_output_is(<<'CODE', <<'OUT', 'more string_to_int'); .sub 'main' :main print_as_integer('-4') print_as_integer('X-4') print_as_integer('--4') + print_as_integer('+') + print_as_integer('++') + print_as_integer('+2') + print_as_integer(' +3') + print_as_integer('++4') + print_as_integer('+ 5') + print_as_integer('-') + print_as_integer('--56') + print_as_integer(' -+67') + print_as_integer('+-78') + print_as_integer(' -089xyz') + print_as_integer('- 89') .end .sub 'print_as_integer' @@ -2841,6 +2853,18 @@ -4 0 0 +0 +0 +2 +3 +0 +0 +0 +0 +0 +0 +-89 +0 OUT ## remember to change the number of tests :-)
Re: Junctions again (was Re: binding arguments)
On 1/5/06, TSa <[EMAIL PROTECTED]> wrote: > Jonathan Lang wrote: > > Therefore, > > > > $x = 3; > > if $x <= 1 & 5 {say 'smaller'} > > if $x > 1 & 5 {say 'larger'} > > > > should produce exactly the same output as > > > > $x = 3; > > if $x <= 1 && $x <= 5 {say 'smaller'} > > This is slightly untrue. because if the junction contains two > identical values or an undef ordered object the < part is > essentially stripped away: > > if $x <= 5 && $x <= 5 {say 'smaller'} > > can be permuted into > > if $x <= 5 && 5 > $x {say 'smaller'} > > and optimized to > > if $x == 5 {say 'smaller'} Do you claim that if $x <= 5 && $x <= 5 {say 'smaller'} is same as if $x == 5 {say 'smaller'} -- Markus Laire
[perl #38174] [PATCH] Fix handling of signs in string_to_int conversion
# New Ticket Created by Roger Browne # Please include the string: [perl #38174] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38174 > Currently, there's an error in the way that parrot's string to integer conversion handles multiple '-' and '+' characters. For example, this PIR code... .sub 'main' :main set $S0, '--4' set $I0, $S0 print $I0 print "\n" .end ...erroneously prints -4. Attached is a patch that modifies src/string.c so that string_to_int looks only for digits after seeing the first occurrence of '-' or '+'. The patch also extends t/op/types.t to test this and similar cases. Regards, Roger Browne Index: src/string.c === --- src/string.c (revision 10937) +++ src/string.c (working copy) @@ -1928,8 +1928,12 @@ /* we've not yet seen any digits */ if (c == '-') { sign = -1; +in_number = 1; } -else if (c == '+' || isspace(c)) +else if (c == '+') { +in_number = 1; +} +else if (isspace(c)) ; else break; Index: t/op/string.t === --- t/op/string.t (revision 10937) +++ t/op/string.t (working copy) @@ -1631,6 +1631,66 @@ print I0 print "\n" + set S0, "+" + set I0, S0 + print I0 + print "\n" + + set S0, "++" + set I0, S0 + print I0 + print "\n" + + set S0, "+2" + set I0, S0 + print I0 + print "\n" + + set S0, " +3" + set I0, S0 + print I0 + print "\n" + + set S0, "++4" + set I0, S0 + print I0 + print "\n" + + set S0, "+ 5" + set I0, S0 + print I0 + print "\n" + + set S0, "-" + set I0, S0 + print I0 + print "\n" + + set S0, "--56" + set I0, S0 + print I0 + print "\n" + + set S0, " -+67" + set I0, S0 + print I0 + print "\n" + + set S0, " +-78" + set I0, S0 + print I0 + print "\n" + + set S0, " -089xyz" + set I0, S0 + print I0 + print "\n" + + set S0, "- 89" + set I0, S0 + print I0 + print "\n" + end CODE 123 @@ -1638,6 +1698,18 @@ -1 0 0 +0 +0 +2 +3 +0 +0 +0 +0 +0 +0 +-89 +0 OUTPUT
Parrot under Cygwin
Probably, I'm doing something wrong... but this is the output compiling parrot on my cygwin... http://nopaste.snit.ch:8001/6180 -- Alberto Simões - Departamento de Informática - Universidade do Minho Campus de Gualtar - 4710-057 Braga - Portugal
Re: Parrot under Cygwin
On 1/6/06, Alberto Simões <[EMAIL PROTECTED]> wrote: > > Probably, I'm doing something wrong... but this is the output compiling > parrot on my cygwin... > > http://nopaste.snit.ch:8001/6180 I've seen more talk on cygwin in the last week or two than in the last year! Yes, building the dynamically loaded classes doesn't yet work, but it's one of my missions to fix it! Have a look at call #37303 which I've updated in the last couple of days which allows libparrot.dll to be build, and then I'm ready to post the final bit which has a preview called parrot_r10901_cygwin_dynclasses_patch.txt from the 5th Jan headed "Revisiting parrot_get_config_string". One question to the floor: I will need to link the dynclasses to libparrot.dll. The current line in tools/build/dynclasses.pl links against extend.o; can anyone explain the reasoning behind this? Thanks, Nick
[perl #38178] [PATCH] Fixes wrong directory listed in instructions for 'svn diff'
# New Ticket Created by Roger Browne # Please include the string: [perl #38178] # in the subject line of all future correspondence about this issue. # https://rt.perl.org/rt3/Ticket/Display.html?id=38178 > This patch, for file docs/submissions.pod, fixes the directory listed against the 'svn diff' command. (The originally-listed directory was not a svn working directory). This patch also adds instructions to apply a 'svn diff' patch, and consistenly names the patches being applied. $ diffstat docs.patch submissions.pod |9 + 1 files changed, 5 insertions(+), 4 deletions(-) Regards, Roger Browne Index: docs/submissions.pod === --- docs/submissions.pod (revision 10939) +++ docs/submissions.pod (working copy) @@ -67,7 +67,7 @@ Patches can also be generated by svn. -cd parrotdev +cd parrot svn diff > docs.patch =item C @@ -122,15 +122,16 @@ You may wish to apply a patch submitted by someone else before the patch is incorporated into SVN. -For single C patches, copy the patch file to F, and run: +For single C patches or C patches, copy the patch file to +F, and run: cd parrot -patch -p0 < single.patch +patch -p0 < some.patch For recursive C patches, copy the patch file to F, and run: cd parrotdev -patch -p0 < recursive.patch +patch -p0 < some.patch =head2 Configuration of to be ignored files
[perl #38146] [TODO] OS.pmc - file copy
> [coke - Tue Jan 03 18:03:31 2006]: > > OS.pmc should provide both a: > > copy(source_file,target) > > And a > > copy(array_of_source_files,targetDir) This needs some more discussion. If we look to Perl, for instance, it doesn't have a built-in copy. You should use either a module, or open both files, copy contents, and close both files. Thus, what I ask if we should have a copy method on OS.pmc. Basically, I think we have three hipothesis: 1) do not implement copy at all. 2) implement it under os.pmc, in C 3) implement it somewhere else in PIR Given that we have (I think) all the needed instructions in PIR, it will be a lot easier to make copy portable using the third choice... but I'm not sure if Parrot will ship with a PIR library... Please, share your ideas. Alberto
Re: [perl #38146] [TODO] OS.pmc - file copy
On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote: [coke - Tue Jan 03 18:03:31 2006]: OS.pmc should provide both a: copy(source_file,target) And a copy(array_of_source_files,targetDir) This needs some more discussion. If we look to Perl, for instance, it doesn't have a built-in copy. You should use either a module, or open both files, copy contents, and close both files. You assume cp semantics. What about preserving metadata? What about multiple forks? What about per-file properties that are invented after you ship your code? And what if the source and destination are on the same file server? Thus, what I ask if we should have a copy method on OS.pmc. Basically, I think we have three hipothesis: 1) do not implement copy at all. You are in a maze of twisty little ad-hoc, informally-specified bug-ridden slow implementations of file copy, all different. 2) implement it under os.pmc, in C 3) implement it somewhere else in PIR Given that we have (I think) all the needed instructions in PIR, it will be a lot easier to make copy portable using the third choice... but I'm not sure if Parrot will ship with a PIR library... Please, share your ideas. I'd like to see every OS get a chance to provide its own file copier. This is important to Mac users, since resource forks may exist and the AppleShare protocol (AFP) allows for intra-server file copy. The same arguments also apply to other file systems. The Genie kernel (part of Lamp, a Unix-like environment on Mac OS) has a copyfile() system call for just this purpose. The knowledge of how to copy a file correctly in a Mac environment (which is non-trivial) is encapsulated in a single place, and usable by any program, either directly through the system call, through cp (for shell scripts), or through a module-loading interpreter. For more typical systems, supply copyfile() in a library as you would a missing kernel call. This usage assumes that copyfile() blocks until completion. Clearly there will be a desire for a concurrent processing mode as well. Josh
[PATCH] Restrict clear_eh to handlers in the current context
If sub A pushes an error handler and then calls B, B can do a 'clear_eh' to get rid of A's handler. This seems to work until B returns, at which point the control stack unwinding done by RetContinuation destroys the rest of the stack looking for the missing handler. The patch detects the problem in clear_eh, and signals a real_exception. Perhaps more controversially, it also makes it an error if clear_eh finds something other than an exception at TOS. The original code did nothing, which doesn't seem right. Error handlers are lexical features of the source code, as are most other things on the control stack [1], so finding a non-exception at TOS indicates a compiler bug (or a logic error in hand-written PIR). Fortunately, this doesn't affect any of the existing test cases -- so I added a new one to test regression. You could also argue that the stack unwinding in RetContinuation.invoke is broken. I tend to agree, but any such fix would be superceded by an implemention of rezipping. This pop_exception fix might also have to change, but probably only in detail. -- Bob [1] The sole exception is the return address used by the bsr/jsr and ret instructions; these aren't bound to any lexical features of the compiled language. Index: src/ops/core.ops === --- src/ops/core.ops(revision 10945) +++ src/ops/core.ops(working copy) @@ -645,12 +645,16 @@ =item B(labelconst INT) -Create an exception handler for the given catch label and push it onto -the control stack. +Create an exception handler that transfers control to the specified +catch label and push it onto the control stack. Such handlers remain +in effect in the current dynamic context, and are popped automatically +on exit. =item B() -Clear out the most recently placed exception. +Remove the exception on the top of the control stack. A "No exception +to pop" error is signalled if the top of the stack is not an +exception, or the exception does not belong to the current context. =item B(in PMC) Index: src/exceptions.c === --- src/exceptions.c(revision 10945) +++ src/exceptions.c(working copy) @@ -327,12 +327,22 @@ { Stack_entry_type type; PMC *handler; +parrot_context_t *current_ctx = CONTEXT(interpreter->ctx); +parrot_context_t *prev_ctx = current_ctx->prev; +Stack_Chunk_t *prev_base = (prev_ctx ? prev_ctx->control_stack : NULL); -handler = stack_peek(interpreter, CONTEXT(interpreter->ctx)->control_stack, &type); +if (prev_base == current_ctx->control_stack) { +real_exception(interpreter, NULL, INVALID_OPERATION, + "No exception to pop."); +} +handler = stack_peek(interpreter, current_ctx->control_stack, &type); if (type != STACK_ENTRY_PMC || -handler->vtable->base_type != enum_class_Exception_Handler) -return; /* no exception on TOS */ -(void)stack_pop(interpreter, &CONTEXT(interpreter->ctx)->control_stack, NULL, +handler->vtable->base_type != enum_class_Exception_Handler) { +/* no exception on TOS */ +real_exception(interpreter, NULL, INVALID_OPERATION, + "No exception to pop."); +} +(void)stack_pop(interpreter, ¤t_ctx->control_stack, NULL, STACK_ENTRY_PMC); } Index: t/pmc/exception.t === --- t/pmc/exception.t (revision 10945) +++ t/pmc/exception.t (working copy) @@ -6,7 +6,7 @@ use warnings; use lib qw( . lib ../lib ../../lib ); use Test::More; -use Parrot::Test tests => 26; +use Parrot::Test tests => 28; =head1 NAME @@ -591,3 +591,42 @@ Error: something happened Outer value OUTPUT + +pir_output_like(<<'CODE', <<'OUTPUT', 'clear_eh out of context (1)'); +.sub main :main + pushmark 1 + clear_eh + print "no exceptions.\n" +.end +CODE +/No exception to pop./ +OUTPUT + +pir_output_is(<<'CODE', <<'OUTPUT', 'clear_eh out of context (2)'); +.sub main :main + .local pmc outer, cont + push_eh handler + test1() + print "skipped.\n" + goto done +handler: + .local pmc exception + .get_results (exception) + print "Error: " + print exception + print "\n" +done: + print "done.\n" +.end +.sub test1 + .local pmc exit + print "[in test1]\n" + ## clear_eh is illegal here, and signals an exception. + clear_eh + print "[cleared]\n" +.end +CODE +[in test1] +Error: No exception to pop. +done. +OUTPUT
Re: [perl #38146] [TODO] OS.pmc - file copy
On Jan 6, 2006, at 10:17 PM, Joshua Juran wrote: On Jan 6, 2006, at 4:11 PM, Alberto Simoes via RT wrote: This needs some more discussion. If we look to Perl, for instance, it doesn't have a built-in copy. You should use either a module, or open both files, copy contents, and close both files. You assume cp semantics. What about preserving metadata? What about multiple forks? What about per-file properties that are invented after you ship your code? And what if the source and destination are on the same file server? So it'd probably be best to put it in os.pmc with checks to know which operating system it's compiled for. That way, each language implementation that includes an operator to copy a file can do so more safely. Isn't part of the point of parrot to make writing a compiler not be system dependent? In fact, if perl had a copy operator instead of doing the open/print combo, the resource fork issue on Macs would be taken care of. Thus, what I ask if we should have a copy method on OS.pmc. Basically, I think we have three hipothesis: 1) do not implement copy at all. You are in a maze of twisty little ad-hoc, informally-specified bug-ridden slow implementations of file copy, all different. 2) implement it under os.pmc, in C 3) implement it somewhere else in PIR Given that we have (I think) all the needed instructions in PIR, it will be a lot easier to make copy portable using the third choice... but I'm not sure if Parrot will ship with a PIR library... Please, share your ideas. I'd like to see every OS get a chance to provide its own file copier. This is important to Mac users, since resource forks may exist and the AppleShare protocol (AFP) allows for intra-server file copy. The same arguments also apply to other file systems. The Genie kernel (part of Lamp, a Unix-like environment on Mac OS) has a copyfile() system call for just this purpose. The knowledge of how to copy a file correctly in a Mac environment (which is non-trivial) is encapsulated in a single place, and usable by any program, either directly through the system call, through cp (for shell scripts), or through a module-loading interpreter. For more typical systems, supply copyfile() in a library as you would a missing kernel call. This usage assumes that copyfile() blocks until completion. Clearly there will be a desire for a concurrent processing mode as well. Josh Another thing is that moving a file across file systems isn't guaranteed to work(I don't know if it is on any platform), and to do so would require copying. Implementing a copy that supported host specific features in os.pmc would help ease that problem. If copy were implemented in pir, and rename were implemented in os.pmc, a problem would arise. The mv command takes care of this, and in my view, for convenience, so should any rename command in os.pmc.
Re: [perl #38178] [PATCH] Fixes wrong directory listed in instructions for 'svn diff'
Committed as 10948. I also renamed 'parrotdev' to 'workingdir' and added some ASCII art to prevent further confusion. Thanks, -J -- On Fri, Jan 06, 2006 at 01:06:19PM -0800, Roger Browne wrote: > # New Ticket Created by Roger Browne > # Please include the string: [perl #38178] > # in the subject line of all future correspondence about this issue. > # https://rt.perl.org/rt3/Ticket/Display.html?id=38178 > > > > This patch, for file docs/submissions.pod, fixes the directory listed > against the 'svn diff' command. (The originally-listed directory was not > a svn working directory). > > This patch also adds instructions to apply a 'svn diff' patch, and > consistenly names the patches being applied. > > $ diffstat docs.patch > submissions.pod |9 + > 1 files changed, 5 insertions(+), 4 deletions(-) > > Regards, > Roger Browne > Index: docs/submissions.pod > === > --- docs/submissions.pod (revision 10939) > +++ docs/submissions.pod (working copy) > @@ -67,7 +67,7 @@ > > Patches can also be generated by svn. > > -cd parrotdev > +cd parrot > svn diff > docs.patch > > =item C > @@ -122,15 +122,16 @@ > You may wish to apply a patch submitted by someone else before the patch is > incorporated into SVN. > > -For single C patches, copy the patch file to F, and run: > +For single C patches or C patches, copy the patch file to > +F, and run: > > cd parrot > -patch -p0 < single.patch > +patch -p0 < some.patch > > For recursive C patches, copy the patch file to F, and run: > > cd parrotdev > -patch -p0 < recursive.patch > +patch -p0 < some.patch > > =head2 Configuration of to be ignored files > pgpN0ScSdYcq4.pgp Description: PGP signature