[perl #41099] [PATCH] root.in Makefile and CREDITS
Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target root.new | 16 1 file changed, 12 insertions(+), 4 deletions(-) Eric Lubow E: [EMAIL PROTECTED] W: http://eric.lubow.org/ root.patch Description: root.patch
[perl #41102] [PATCH] On Win32 with Visual C++, nmake was not automatically selected if mingw was also found on the system
# New Ticket Created by David Woldrich
# Please include the string: [perl #41102]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41102
Affected files:
config/init/hints/mswin32.pm
config/inter/make.pm
The Parrot configuration scripts were not incorporating the cues given
by the user when --cc=cl to use the microsoft build environment when
mingw was also present on the system.
Additionally, nmake is now forced as the make exe in the
config/init/hints/mswin32.pm file.
Cheers,
Dave Woldrich
Index: config/init/hints/mswin32.pm
===
--- config/init/hints/mswin32.pm(revision 16127)
+++ config/init/hints/mswin32.pm(working copy)
@@ -58,6 +58,7 @@
make_c = q{$(PERL) -e chdir shift @ARGV;}
. q{system '$(MAKE)', '-nologo', @ARGV; exit $$? 8;},
+ make = 'nmake',
# ZI messes with __LINE__
cc_debug = '-Zi',
Index: config/inter/make.pm
===
--- config/inter/make.pm(revision 16127)
+++ config/inter/make.pm(working copy)
@@ -40,6 +40,7 @@
# precedence of sources for the program:
# default - probe - environment - option - ask
+$prog ||= $conf-data-get($util);
$prog ||= $conf-options-get($util);
$prog ||= $ENV{uc($util)};
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target Eric Lubow E: [EMAIL PROTECTED] W: http://eric.lubow.org/ root.patch Description: root.patch
[perl #41104] [PATCH] Building on MinGW is disrupted by the presense of /bin/sh.exe on the PATH, docs explain required environment change
# New Ticket Created by David Woldrich # Please include the string: [perl #41104] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=41104 Affected files: /README.win32.pod Description: On Win32, backslashes are generated as part of many pathnames by most tools and wind up in the makefile. Windows understands paths with both forward and backslashes. But, Cygwin and MSYS /bin/sh.exe's do not. They correctly interpret the backslashes as escape characters. Perl.exe is designed to search for sh.exe on the system PATH, if it finds it, whenever it shells a new program, it does it via Cygwin's or MSYS' /bin/sh.exe. The make process fails early on due to bad paths. The fix is to remove /bin/sh.exe from the PATH environment variable and run the build process from a dosbox. My patch includes a suggested documentation change (you may want to wordsmith it a bit, but hopefully you get the gist.) Note: the README.win32.pod says that there should be other README's that discuss Cygwin build issues, but I did not see any Cygwin readme's in trunk. My patch does not discuss Cygwin, but theoretically the same advice should apply. Cheers, Dave Woldrich Index: README.win32.pod === --- README.win32.pod(revision 16131) +++ README.win32.pod(working copy) @@ -39,7 +39,14 @@ one of the above toolkits to obtain a later version, either v7 or v8. MinGW works with its GNU make (v 3.80) port and its name is -'mingw32-make.exe'. +'mingw32-make.exe'. If you also have the Minimal SYStem (MSYS) installed, +you will need to remove the Msys/bin folder from your PATH environment +variable before calling perl Configure.pl and mingw32-make. Perl detects +and calls /bin/sh.exe, if found, whenever shelling a new process. sh.exe +causes problems for mingw32-make.exe because of its inability to handle +Windows pathnames with backslashes. You must run perl Configure.pl and +mingw32-make from a dosbox; running those commands from an MSYS shell window +will experience the same backslash path problems. =item Command Shell
[perl #41102] [PATCH] On Win32 with Visual C++, nmake was not automatically selected if mingw was also found on the system
On Sat Dec 16 13:38:53 2006, [EMAIL PROTECTED] wrote: Affected files: config/init/hints/mswin32.pm config/inter/make.pm The Parrot configuration scripts were not incorporating the cues given by the user when --cc=cl to use the microsoft build environment when mingw was also present on the system. Additionally, nmake is now forced as the make exe in the config/init/hints/mswin32.pm file. Patch applied in 16129, thank you. Jonathan
[perl #41099] [PATCH] root.in Makefile and CREDITS
On Sat Dec 16 10:29:32 2006, [EMAIL PROTECTED] wrote: Ensured the makefile doesn't allow a make install and added myself to the CREDITS file. Thanks! Applied in r16140 and r16141 Paul
[perl #41099] [PATCH] root.in Makefile and CREDITS
Eric, Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target It seems that you've provided two different patches to do this (the first looks like an svn diff, and the second a plain normal diff), which one do you want applied? Paul
Generated .pm files in MANIFEST
Hi all, The files languages/regex/lib/Regex/Grammar.pm and languages/lua/Lua/parser.pm are autogenerated, so shouldn't they be mentioned in MANIFEST.generated instead of MANIFEST? If so, I'll move the entries across to MANIFEST.generated and this will reduce the size of the coding standards hammer. I can't seem to find any others, but there might be more hiding, so are there any more that people know of? Thanks heaps in advance! Paul
Re: [perl #41064] [BUG]: Not-so-new 'make' failures on Darwin
Will Coleda wrote: Here's my shell script for running config: #!/bin/sh CC=ccache gcc-4.0 CX=ccache g++-4.0 /usr/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX -- ld=$CX --without-icu $@ Following further discussion with Coke on #parrot, I ran this slight variation on the above: #!/bin/sh CC=/usr/bin/gcc-3.3 CX=/usr/bin/g++-3.3 /usr/local/bin/perl Configure.pl --cc=$CC --cxx=$CX --link=$CX --ld=$CX --without-icu --without-gmp $@ It worked! Which puts me back in the Parrot game. You can see the resulting Parrot configuration at http://nopaste.snit.ch:8001/8999 And it appears that yesterday's Bug Day resulted in a lot of cage cleaning, because the number of individual tests that failed when I ran 'make test' dropped from 62 to 1: http://nopaste.snit.ch:8001/9000 Thank you very much! kid51
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote: Hi all, We could close this ticket if a decision were made as to whether or not the emacs/vim formatting information can be put at the *beginning* of a file in the case where __END__ or __DATA__ blocks are used within a perl source file. What are people's opinions? Would it be too ugly to put the coda at the beginning of the file just after the shebang line? Paul Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: http://search.cpan.org/~cdolan/Perl-Critic-More-0.12/lib/Perl/Critic/ Policy/Editor/RequireEmacsFileVariables.pm Chris -- Chris Dolan, Software Developer, http://www.chrisdolan.net/ Public key: http://www.chrisdolan.net/public.key vCard: http://www.chrisdolan.net/ChrisDolan.vcf
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
From: Chris Dolan [EMAIL PROTECTED] Date: Sun, 17 Dec 2006 13:22:53 -0600 On Dec 16, 2006, at 12:41 PM, Paul Cochrane via RT wrote: Hi all, We could close this ticket if a decision were made as to whether or not the emacs/vim formatting information can be put at the *beginning* of a file in the case where __END__ or __DATA__ blocks are used within a perl source file. What are people's opinions? Would it be too ugly to put the coda at the beginning of the file just after the shebang line? Paul Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes . . . That will still be true for Emacs 22, BTW. However, this wouldn't be hard to hack around in a cperl-mode hook function. Since we already insist that people load editor/parrot.el for editing C code, this would amount to zero additional burden on Parrot hackers. And in that case, we could put the Local Variables: section anywhere we like, so we might as well keep it at the end of the code, just before any __END__ or __DATA__ blocks. I think I would like to write this anyway; it would be a useful addition to cperl-mode. But in that case, we would also need a customized Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy. WDOT? -- Bob Rogers http://rgrjr.dyndns.org/
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Paul, Use the one that is the newest. It has the reallyinstall target in the make help and in the actual make process. Eric -Original Message- From: Paul Cochrane via RT [mailto:[EMAIL PROTECTED] Sent: Sunday, December 17, 2006 7:51 AM To: Eric B. Lubow Subject: [perl #41099] [PATCH] root.in Makefile and CREDITS Eric, Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target It seems that you've provided two different patches to do this (the first looks like an svn diff, and the second a plain normal diff), which one do you want applied? Paul
RE: [perl #41099] [PATCH] root.in Makefile and CREDITS
Paul, I just checked the RT queue. I didn't realize they came in at the same time. Use the one that's 1.4k and is CC'd perl6internals. Eric -Original Message- From: Paul Cochrane via RT [mailto:[EMAIL PROTECTED] Sent: Sunday, December 17, 2006 7:51 AM To: Eric B. Lubow Subject: [perl #41099] [PATCH] root.in Makefile and CREDITS Eric, Added make reallyinstall target Added help text for make reallyinstall target Fixed make install target It seems that you've provided two different patches to do this (the first looks like an svn diff, and the second a plain normal diff), which one do you want applied? Paul
[perl #33962] readline returns one too many lines
On Sat Jan 29 06:17:10 2005, leo wrote:
Matt Diephouse [EMAIL PROTECTED] wrote:
I already use that workaround in some of my code, but that sorta
defeats the purpose of testing the filehandle itself. The filehandle
should become false after it returns the last line of the file - not
the last line plus an empty string.
Looked again at that stuff. You are testing for EOF before the readline,
which implies that EOF should be set along with returning data. This
seems to be wrong.
So the correct way seems to be:
unless file goto END
LOOP:
$S0 = readline file
unless file goto END
$I0 += 1
goto LOOP
Leo is right. Compare the equivalent Perl 5 code:
my $file;
open $file, @ARGV[0] or die can't open file;
my $count = 0;
while ($file) {
my $string = readline $file;
print Count is $count: $string;
$count++;
last if $string eq ;
}
print \nTotal count: $count\n;
which prints out:
Count is 0: line 1
Count is 1: line 2
Count is 2: line 3
Count is 3:
Total count: 4
There's no way the filehandle can know that it has reached the last line
of the file before it reads the last line of the file. The extra line
isn't a problem with readline, it's simply a result of the loop control
structure you've chosen. Perl 5's
while (FILEHANDLE) {...}
construct isn't a simple while loop on a file handle, it's syntactic
sugar for a filehandle iterator. Which reminds me that we need to either
make sure that the default Iterator object can be applied to ParrotIO
objects, or provide one that can (or perhaps an Iterator role). So, I'm
leaving this ticket open and attached to the I/O PDD ticket.
Allison
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
From: Bob Rogers [EMAIL PROTECTED] Date: Sun, 17 Dec 2006 15:03:10 -0500 From: Chris Dolan [EMAIL PROTECTED] Date: Sun, 17 Dec 2006 13:22:53 -0600 . . . Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes . . . That will still be true for Emacs 22, BTW. However, this wouldn't be hard to hack around in a cperl-mode hook function . . . Here it is, plus a bonus of auto-mode-alist hackery. Comments? -- Bob Index: editor/parrot.el === --- editor/parrot.el(revision 16136) +++ editor/parrot.el(working copy) @@ -22,3 +22,56 @@ (statement-case-intro . *) (inextern-lang . 0) + +;; All *.pmc and *.ops files are really C (or close enough). +(let ((tail '(\\.pmc$ \\.ops$))) + (while tail +(or (assoc (car tail) auto-mode-alist) + (setq auto-mode-alist + (cons (cons (car tail) 'c-mode) auto-mode-alist))) +(setq tail (cdr tail + +(defun parrot-hack-perl-local-variables () + Redo hack-local-variables if it was fooled by __END__ or __DATA__. +The coda containing 'Local Variables:' should appear just before the first +of these, but Emacs won't see it if there are more than 3000 characters +after the __END__ or __DATA__. This is designed to be installed as a +mode hook; when the hook runs, we know we're in a Perl buffer and can +repeat the search for the coda in the Perl-appropriate place. + +Important: Do not call this from another mode hook function. If it is +not directly on the perl-mode-hook or cperl-mode-hook list, it won't be +able to disable itself, and you'll get an unbounded recursion. + +We try hard not to call hack-local-variables if it's not needed. But if +it is, and 'Local Variables:' contains a 'Mode:' line, then the mode +function will be called again, and mode hooks will be rerun. + (interactive) + (save-excursion +;; The hack-local-variables code makes a point of only looking backwards +;; from point-max in case the buffer is huge. We need to search from the +;; start, to find the first of __END__ or __DATA__, and can assume that the +;; buffer is of reasonable size. +(goto-char (point-min)) +(if (re-search-forward ^__\\(END\\|DATA\\)__$ nil t) + (let* ((end (point)) + ;; this is based on the hack-local-variables logic. + (start (max (- end 3000) (point-min + (search-backward \n\^L start 'move) + (if (let ((case-fold-search t)) + (search-forward Local Variables: end t)) + (let ((cperl-mode-hook + (remove 'parrot-hack-perl-local-variables cperl-mode-hook)) + (perl-mode-hook + (remove 'parrot-hack-perl-local-variables perl-mode-hook))) + ;; Important: We can't rerun hack-local-variables without + ;; rebinding mode hooks, since hack-local-variables may + ;; re-establish the mode, which will run the hooks again. + (save-restriction + (narrow-to-region start end) + (hack-local-variables + +(add-hook 'cperl-mode-hook 'parrot-hack-perl-local-variables) +;; We also need one on perl mode, because the coda contains the Mode: spec, so +;; we'll be in perl-mode to start off. +(add-hook 'perl-mode-hook 'parrot-hack-perl-local-variables)
Re: [perl #41105] [PATCH] Silence a warning on Cygwin
On Saturday 16 December 2006 19:29, Steve Peters via RT wrote: Actually, no, not the previous patch. Try the following instead. Thanks, applied as 16177. -- c
[perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003
With ICU optional these days, is this still necessary?
Re: Side effect between exit .HLL
At 08:46 12/12/2006 +0100, François PERRAD wrote:
With the following code :
.sub main
print reached\n
exit 1
print not reached\n
.end
I obtain :
reached
But after adding a .HLL directive
.HLL 'Lua', 'lua_group'
.sub main
print reached\n
exit 1
print not reached\n
.end
I obtain :
reached
No exception handler and no message
current instr.: 'main' pc 2 (exit.pir:5)
Is it a feature or not ?
François.
The following patch solves the problem, but I haven't a real explanation.
François.
Index: luaboolean.pmc
===
--- luaboolean.pmc (revision 16180)
+++ luaboolean.pmc (working copy)
@@ -35,7 +35,7 @@
does integer
dynpmc
group lua_group
-hll Lua maps Integer {
+hll Lua maps Boolean {
/* Class initialization. Caches constant strings that will be used later.
*/
Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)
Be aware that you cannot use the verbose form of Emacs settings at the beginning of a file, unless the file is shorter than 3000 bytes. See Perl::Critic::Policy::Editor::RequireEmacsFileVariables policy for more details: So this means we need to put the emacs and vim settings at the end of the file. Vim sets a similar restriction in that its settings should be in the first or last 5 lines. The problem that I'm trying to solve here is: how do we add the settings information to perl language files such that it doesn't cause problems with __END__ and __DATA__ blocks, is testable by perlcritic, emacs *and* vim pick up their settings values, and it doesn't interfere with the visual structure of the file. I've hit a bit of a brick wall in trying to satisfy all these conditions; any ideas as to how we can achieve this? Many thanks in advance, Paul
