Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

2006-12-17 Thread Paul Cochrane

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


Re: Side effect between exit & .HLL

2006-12-17 Thread Francois PERRAD

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.
 */







[perl #31652] [TODO] Win32 - Microsoft Visual C++ Toolkit 2003

2006-12-17 Thread chromatic via RT
With ICU optional these days, is this still necessary?


Re: hello, does anybody who knows the svn respo of synopsis docs?

2006-12-17 Thread Fayland Lam
Audrey Tang wrote:
> 
> 在 Dec 18, 2006 5:52 AM 時,Fayland Lam 寫到:
> 
>> we are trying to translate them into Chinese. so I just wonder where 
>> can I get the .pod source?
> 
> http://svn.perl.org/perl6/doc/trunk/design/syn/

Thanks.

> 
> Cheers,
> Audrey
> 
> 



Re: [perl #41105] [PATCH] Silence a warning on Cygwin

2006-12-17 Thread chromatic
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


Re: hello, does anybody who knows the svn respo of synopsis docs?

2006-12-17 Thread Audrey Tang


在 Dec 18, 2006 5:52 AM 時,Fayland Lam 寫到:

we are trying to translate them into Chinese. so I just wonder  
where can I get the .pod source?


http://svn.perl.org/perl6/doc/trunk/design/syn/

Cheers,
Audrey



hello, does anybody who knows the svn respo of synopsis docs?

2006-12-17 Thread Fayland Lam
we are trying to translate them into Chinese. so I just wonder where can 
I get the .pod source?


Thanks.



Re: [perl #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

2006-12-17 Thread Bob Rogers
   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)


[perl #33962] readline returns one too many lines

2006-12-17 Thread Allison Randal via RT
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 () {...} 

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


Unwanted scalar references

2006-12-17 Thread Ovid
Hi all,

Thanks for the answers to my previous questions.  I do appreciate it.

Today's stumper is this:

  sub decode([EMAIL PROTECTED]) returns Array {
  gather {
  for @list -> $elem {
  take $elem.isa(Array) ?? $elem[1] xx $elem[0] !! $elem;
  }
  }
  }
  decode( [3, "a"], "b", [1, "c"] ).perl.say; 

That prints:

  ("a", "a", "a", \"b", "c")

How do I dereference "b"?  Heck, why is it a reference in the first
place?

Actually, I have found one way to dereference is, but it seems wrong
and buggy (using a prefix ++):

  sub decode([EMAIL PROTECTED]) returns Array {
  gather {
  for @list -> $elem {
  take $elem.isa(Array) ?? $elem[1] xx $elem[0] !! ++$elem;
  }
  }
  }
  decode( [3, "a"], "b", [1, "c"] ).perl.say; 

Oddly, using the postfix ++ gives me the error message I expect:

  *** Can't modify constant item: VRef 
  at 99.pugs line 215, column 18-69
 99.pugs line 215, column 18-69

Cheers,
Ovid

--

Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/


RE: [perl #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Eric B. Lubow
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



RE: [perl #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Eric B. Lubow
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 #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

2006-12-17 Thread Bob Rogers
   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 #40361] [PATCH] #40278 [CAGE] perl coding standards coda. (cont.)

2006-12-17 Thread Chris Dolan

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 #41064] [BUG]: Not-so-new 'make' failures on Darwin

2006-12-17 Thread James E Keenan

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


Generated .pm files in MANIFEST

2006-12-17 Thread Paul Cochrane

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


[perl #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Paul Cochrane via RT
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 #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Paul Cochrane via RT
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


RE: [perl #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Eric B. Lubow

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 #41102] [PATCH] On Win32 with Visual C++, nmake was not automatically selected if mingw was also found on the system

2006-12-17 Thread [EMAIL PROTECTED] via RT
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 #41104] [PATCH] Building on MinGW is disrupted by the presense of /bin/sh.exe on the PATH, docs explain required environment change

2006-12-17 Thread via RT
# New Ticket Created by  David Woldrich 
# Please include the string:  [perl #41104]
# in the subject line of all future correspondence about this issue. 
# 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

2006-12-17 Thread via RT
# New Ticket Created by  David Woldrich 
# Please include the string:  [perl #41102]
# in the subject line of all future correspondence about this issue. 
# 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)};
 


[perl #41099] [PATCH] root.in Makefile and CREDITS

2006-12-17 Thread Eric B. Lubow

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


Weekly Perl 6 mailing list summary for 10-16 December, 2006

2006-12-17 Thread Ann Barcomb

 This week on the Perl 6 mailing lists

"With the little sense of smell I have left, this smells like
INTERCAL's 'COME FROM' statement to me..."

-- Larry Wall, who has a cold, in 'supertyping '


 Language

  supertyping 

In this thread, TSa brought up the concept of supertyping again. The
example of `Square <: Rectangle` was included, along with others.
TSa's question involved an example where the object's type was changed
while its identity was preserved. Additionally, TSa asked if
supertyping will exist in Perl 6, and if so, how would 'superdoes' and
'superis' concepts be expressed.

Jonathan Lang attempted to rewrite the question for a larger audience.
He explained that the suggestion was to go from specific to general,
rather than the other way around.

Jonathan then noted that there are four approaches to code reuse,
three which add functionality, and one which restricts it. This led
him to see supertyping in terms of exemptions for the fourth case.
Luke Palmer responded with an equation to express the relationship,
and his answers to the questions of whether it should be illegal to
add a required method to A if B does not implement it, given `role A
superdoes B`, and if a required method for A should automatically
become a required method for B.

There was some discussion on how 'superdoes' would be written, with
'done_by', 'bequeath', and 'by' being proposed. Ruud H.G. van Tol
offered more suggestions than a thesaurus.

Larry Wall first wanted to see use cases which go beyond the number
examples in order to see the value of the proposal to those who aren't
interested in type theory. Luke Palmer, on the other hand, expressed
his interest in continuing to consider the idea until it is solid
enough that he would be comfortable with it. Larry added his thoughts
concerning namespace issues. There was a great deal more discussion
formulating the specifics of the proposal.

  Gather/Take and threads 

Given a gather block which spawns multiple threads, Joe Gottman wanted
to know if it is guaranteed that no object returned is lost, given
that the relative order of items returned is indeterminate.

This week, Larry Wall responded that gather/take is defined over a
dynamic scope, and each thread is a different dynamic scope, so by
default there would be no results from other threads. He also
entertained the converse, that gather/take is a normal way to set up
inter-thread queuing. The short answer seemed to be that this has not
yet been decided.

 Parrot Porters

  RFC: Proposal for dynamic binding 

This thread was started by Bob Roger's proposal for dynamic binding.
To date, it has included an extended discussion between Bob and
Allison Randal, plus a request from Leopold Toetsch.

Allison began this week by explaining her understanding of the terms
dynamic scoping, assignment and binding. Her view of the proposal is
that it offers a textbook definition of dynamic scoping. The
discussion has included dynamic binding, dynamic scoping, and
temporization, however. With the terms defined, she went on to propose
that Bob create a new proposal for implementing dynamic scope which
does not contain any references to temporization. Bob agreed to do
this, but asked for a few clarifications first.

  [perl #40958] [BUG] - can't iterate subclass of ResizablePMCArray
  

chromatic responded to ticket [perl #40958]  with
a second patch, which improves upon his earlier attempt. However, he
noted that it seems to work poorly with Data::Dumper and that his
solution, while non-invasive, was not ideal. He described his
preferred fix.

  [perl #41055] [BUG]: 'Argument is not numeric' warning in Darwin
  configuration 

Last week, in ticket [perl #41055] , James Keenan
registered a bug with running `perl Configure.pl`, which seemed to be
related to having a 3-level version number.

This week, Lee Duhem commented that it would probably be enough to get
the major OS version.

  [perl #41064] Not-so-new 'make' failures on Darwin 

Ticket [perl #41064]  was created by James Keenan
to report another failure to make Parrot on Darwin. He expressed
frustration that he is still seeing the same problem which he
encountered at the Chicago Hackathon and described the measures he has
taken to resolve it.

Will Coleda found a possible file ownership problem, and suggested
trying a new checkout. After determining that this was not the cause,
Will asked several questions in an attempt to pinpoint the cause.
Several further posts were made by both James and Will as they tri