Re: IMCC Reentrancy

[Audrey Tang]

在 2006/7/18 上午 1:54 時，Audrey Tang 寫到：
If you have a way to make IMCC reentrant that involves upgrading  
to a more recent version of flex and passing one additional  
parameter, go for it! Send us a patch and if it passes all the  
tests, we'll apply it.


As flex 2.5.30+ is not API compatible with the current flex IMCC is  
using, I wonder how it is different from re2c or regel, in  
particular that shoehorning an additional YYLEX parameter to make  
it work with bison will also involve overhauls beyond the original  
bison interface.


I guess my question is: If I send two patches, of equal size, one  
uses re2c and is much cleaner and faster; another uses a kluged-up  
flex with its new, backward-incompatible reentrant API, would you  
reject one and apply the other?  If you are willing to let  
alternative scanners go in, I'd much rather working on that instead  
of trying to work around the bison/flex interface.


Code is easier for me to write than English.  Hence:

09:22 <@audreyt> imcc scanner is now reentrant.
09:22 <@audreyt> I think it wouldn't take more than another hour to  
get it based on re2c

09:22 <@audreyt> but I'm willing to take what is felt more comfortable.

:-)

Audrey

PGP.sig
Description: This is a digitally signed message part

Re: IMCC Reentarancy

[Audrey Tang]

Vishal,

在 2006/7/16 下午 11:57 時，Vishal Soni 寫到：

a. Remove flex and implement re2c
b. Remove static and global variables


Now that the flex part is done, are you still willing to help  
removing the remaining static/global state?


Apart from this we also need to refactor the code to get rid of  
arrays to a

hash table implementation for macros.


This would rock, too.

Thanks,
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: IMCC Reentrancy

[Allison Randal]

Audrey Tang wrote:


Indeed, and I'd like to apologize publicly for the snipping.


Accepted and forgiven.

However, the re2c or regel-based scanner refactoring isn't different 
from a "flex upgrade patch", as it (by definition) can't affect IMCC's 
public API at all.  An additional advantage is that they will let us rid 
of the flaky API situation with flex.  In any case it wouldn't take 6 
months.


In vsoni's original words:


a. Remove flex and implement re2c
b. Remove static and global variables


The full quote in context is:


Since flex is not generating reeentrant code, this option will get rid of
flex altogether and replace it with re2c. This would require significant
reworking on the code. So the plan of action would be as follows:
a. Remove flex and implement re2c
b. Remove static and global variables

Apart from this we also need to refactor the code to get rid of arrays to a
hash table implementation for macros.

All in all this would be over hauling lot of code.



And you answered:

The cost/benefit balance on this solution is not good. A lot of people 
are depending on IMCC now, and a refactor of that magnitude will throw 
several important projects on Parrot into a dead stall.


Yup. Always take the estimate of the developer and multiply it by at 
least 3. If the developer thinks it will require "significant 
reworking", it's likely to be a massive overhaul.


It will involve overhauls, but again, the public interface -- at bison 
level and above -- cannot break.  So the "dead stall" ruling -- 
effectively dismissing re2c and other scanner alternatives instantly -- 
strikes me as extremely surprising.


It's not the definition of the interface I'm concerned about, it's the 
behavior behind the interface. Can you guarantee that you can substitute 
re2c for flex without changing any behavior of IMCC? If you say "Yes", 
I'll still be suspicious the answer will turn out to be "No".


I'm also not convinced that re2c is a significant improvement over flex. 
I'd rather spend that developer time on things that are significant 
improvements.


I am convinced that we need to avoid yanking working systems out from 
under developers whenever possible.


Allison

[perl #39853] [BUG] Tcl - pwd returns path with backslashes on Win32

[via RT]

# New Ticket Created by  Ron Blaschke 
# Please include the string:  [perl #39853]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39853 >


Test languages/tcl/t/cmd_pwd.t fails on Win32.  Tcl's pwd returns the
path with backslashes, most likely because OS.cwd does too, but the test
expects forward slashes, as the result is compared with Perl's Cwd::getcwd.

The "other" Tcl returns forward slashes, too.

C:\Tcl\bin>tclsh
% puts [pwd]
C:/Tcl/bin

I'm not sure if this should be changed in languages/tcl or Parrot's OS.cwd.

Ron

[perl #39858] [PATCH] more elegant hex_to_int in examples/io/httpd.pir

[via RT]

# New Ticket Created by  Kay-Uwe Huell 
# Please include the string:  [perl #39858]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39858 >


Hi parrot,

here is a more elegant function for 'hex_to_int' in examples/io/httpd.pir.

Regards,

kiwi
Index: CREDITS
===
--- CREDITS	(Revision 13335)
+++ CREDITS	(Arbeitskopie)
@@ -282,6 +282,8 @@
 N: Juergen Boemmels
 D: Parrot I/O; macro stuff in assembler.
 
+N: Kay-Uwe 'kiwi' Hüll
+
 N: Kenneth A Graves
 D: yield and other PIR improvements
 
Index: examples/io/httpd.pir
===
--- examples/io/httpd.pir	(Revision 13335)
+++ examples/io/httpd.pir	(Arbeitskopie)
@@ -44,6 +44,11 @@
 
 =cut
 
+.const string CRLF = "\r\n"
+.const string CRLFCRLF = "\r\n\r\n"
+.const string LFLF = "\n\n"
+.const string CRCR = "\r\r"
+
 .sub main :main
 .local pmc sock, work, fp
 .local pmc fp   # read requested files from disk
@@ -83,15 +88,15 @@
 
 if ret <= 0 goto SERVE_REQ
 concat req, buf
-index pos, req, "\r\n\r\n"
+index pos, req, CRLFCRLF
 # print "\npos1:"
 # print pos
 if pos >= 0 goto SERVE_REQ
-index pos, req, "\n\n"
+index pos, req, LFLF
 # print "\npos2:"
 # print pos
 if pos >= 0 goto SERVE_REQ
-index pos, req, "\r\r"
+index pos, req, CRCR
 # print "\npos3:"
 # print pos
 if pos >= 0 goto SERVE_REQ
@@ -137,14 +142,16 @@
 unless fp goto SERVE_404
 
 read file_content, fp, 65535
-rep = "HTTP/1.x 200 OK\n"
-concat rep, "Server: Parrot-httpd/0.1\n"
-concat rep, "Content-Length: "
+rep = "HTTP/1.x 200 OK"
+rep .= CRLF
+rep .= "Server: Parrot-httpd/0.1"
+rep .= CRLF
+rep .= "Content-Length: "
 length len, file_content
 temp = to_string (len)
-concat rep, temp
-concat rep, "\n\n"
-concat rep, file_content
+rep .= temp
+rep .= CRLFCRLF
+rep .= file_content
 send ret, work, rep
 print "served file '"
 print url
@@ -152,12 +159,16 @@
 goto NEXT
 
 SERVE_docroot:
-rep = "HTTP1/1 301 Moved Permamently\nLocation: /docs/html/index.html\nContent-Length: "
+rep = 'HTTP1/1 301 Moved Permamently'
+rep .= CRLF
+rep .= 'Location: /docs/html/index.html'
+rep .= CRLF
+rep .= 'Content-Length: '
 file_content = "Please go to Parrot Documentation." 
 length len, file_content
 temp = to_string (len)
 concat rep, temp
-concat rep, "\n\n"
+concat rep, CRLFCRLF
 concat rep, file_content
 send ret, work, rep
 print "Redirect to 'docs/html/index.hmtl'\n"
@@ -168,7 +179,17 @@
 goto SERVE_file
 
 SERVE_404:
-rep = "HTTP1/1 404 Not Found\nContent-Length: 3\n\n404\n"
+$S0 = '404 Not found'
+$I0 = length $S0
+rep = 'HTTP1/1 404 Not Found'
+rep .= CRLF
+rep .= 'Content-Length: '
+$S1 = $I0
+rep .= $S1
+rep .= CRLF
+rep .= 'Content-Type: text/plain'
+rep .= CRLFCRLF
+rep .= $S0
 print "File not found: '"
 print url
 print "'\n"
@@ -237,95 +258,41 @@
 
 
 .sub hex_to_int
-.param string in
+.param string hex
 
-.local string char
-.local int ret
-.local int pos
-.local int factor
-.local int temp
-.local int len
+hex = upcase hex
 
-ret = 0
-factor = 1
-length len, in
-sub pos, len, 1
+.local int len, num_offset, chr_offset, result
 
-NEXT_CHAR:
-substr char, in, pos, 1
+num_offset = ord '0', 0
+chr_offset = ord 'A', 0
 
-if char=="0" goto CHAR0
-if char=="1" goto CHAR1
-if char=="2" goto CHAR2
-if char=="3" goto CHAR3
-if char=="4" goto CHAR4
-if char=="5" goto CHAR5
-if char=="6" goto CHAR6
-if char=="7" goto CHAR7
-if char=="8" goto CHAR8
-if char=="9" goto CHAR9
-if char=="A" goto CHARA
-if char=="B" goto CHARB
-if char=="C" goto CHARC
-if char=="D" goto CHARD
-if char=="E" goto CHARE
-if char=="F" goto CHARF
+len = length hex
 
-CHAR0:
-temp = 0
-goto CHAREND
-CHAR1:
-temp = 1
-goto CHAREND
-CHAR2:
-temp = 2
-goto CHAREND
-CHAR3:
-temp = 3
-goto CHAREND
-CHAR4:
-temp = 4
-goto CHAREND
-CHAR5:
-temp = 5
-goto CHAREND
-CHAR6:
-temp = 6
-goto CHAREND
-CHAR7:
-temp = 7
-goto CHAREND
-CHAR8:
-temp = 8
-goto CHAREND
-CHAR9:
-temp = 9
-goto CHAREND
-CHARA:
-temp = 10
-goto CHAREND
-CHARB:
-temp = 11
-goto CHAREND
-CHARC:
-temp = 12
-goto CHAREND
-CHARD:
-temp = 13
-goto CHAREND
-CHARE:
-temp = 14
-goto CHAREND
-CHARF:
-temp = 15
-goto CHAREND
+result = 0
+$I0 = 0
+  LOOP:
+unless $I0 < len goto RETURN
+$I1 = ord hex, $I0
+if $I1 < chr_offset goto HAVE_NUMBER
 
-CHAREND:
-mul temp, factor, temp
-add ret, temp, ret
-mul factor, factor, 16

Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o

[Joshua Hoblitt]

On Mon, Jul 17, 2006 at 12:11:55PM -0700, chromatic wrote:
> After discussing the idea with Allison, we both believe that Parrot should be 
> able to produce a single PBC file from a command like:
> 
>   parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

It'd probably make sense to define some clear rules on how symbol
conflicts are handled up front.  As it's always nice to know which :main
to invoke.  :) A possible rule could be "the version of the symbol that
appears in 'left most" file has precedence".  Alternatively, a symbol
collision could just be a fatal error.

-J

--


pgp9npXdqQKrR.pgp
Description: PGP signature

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Allison Randal]

[EMAIL PROTECTED] wrote:


* However, the bison interface does not support both "interp"
  and "yyscanner" as flex inputs; so I created a patch file
  at compiler/imcc/imcparser.c.diff -- it needs to be applied
  manually whenever imcc.y is regenerated into imcparser.c.

  This is really suboptimal, and should be folded into the
  build system.  But then again, $(YACC) and $(LEX) are both
  at this moment hard-coded to "echo" and not governed by the
  normal "make" rules anyway, so I'm not sure how best to address
  this build problem.  Suggestions welcome.


This is not a maintainable build solution. Revert and come back when you 
have one.


(It's always okay to say "I've gotten this far in implementation but hit 
a snag". Just don't commit until you resolve the snag.)


Allison

Checkin #13345

[chromatic]

This patch:

--- trunk/compilers/imcc/main.c (original)
+++ trunk/compilers/imcc/main.c Tue Jul 18 01:33:59 2006
@@ -369,7 +369,7 @@
 exit(EX_USAGE);
 }
 if (*argc == opt.opt_index ) {
-fprintf(stderr, "Missing option value or program name\n");
+fprintf(stderr, "Option %s expects an argument\n", (*argv)[*argc - 
1]);
 usage(stderr);
 exit(EX_USAGE);
 }

... provides quite misleading results:

$ parrot -o file.pir
Option file.pir expects an argument
parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] 

I don't believe there's a working heuristic for guessing which parameter the 
user failed to provide.  That's why I didn't write the original version that 
way.

-- c

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Joshua Hoblitt]

On Tue, Jul 18, 2006 at 01:38:20AM -0700, Allison Randal wrote:
> [EMAIL PROTECTED] wrote:
> >
> >* However, the bison interface does not support both "interp"
> >  and "yyscanner" as flex inputs; so I created a patch file
> >  at compiler/imcc/imcparser.c.diff -- it needs to be applied
> >  manually whenever imcc.y is regenerated into imcparser.c.
> >
> >  This is really suboptimal, and should be folded into the
> >  build system.  But then again, $(YACC) and $(LEX) are both
> >  at this moment hard-coded to "echo" and not governed by the
> >  normal "make" rules anyway, so I'm not sure how best to address
> >  this build problem.  Suggestions welcome.
> 
> This is not a maintainable build solution. Revert and come back when you 
> have one.
> 
> (It's always okay to say "I've gotten this far in implementation but hit 
> a snag". Just don't commit until you resolve the snag.)

FYI, $(YACC) and $(LEX) are set to useful values when  "--maintainer" is
passed to Configure.pl.  If apply a patch as part of the build processes
is really the only option then a conditional could be added to root.in
to only apply the patch when --maintainer is in effect.

-J

--


pgpBcM2Cvyz4Z.pgp
Description: PGP signature

[perl #39857] [PATCH] Made httpd.pir RFC compliant (at least about CRLF)

[via RT]

# New Ticket Created by  Kay-Uwe Huell 
# Please include the string:  [perl #39857]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39857 >


Hi parrot,

this is a patch to make examples/io/httpd.pir RFC compliant (at least
about CRLF).

I put CRLF into a constant...

Regards,

kiwi

Index: CREDITS
===
--- CREDITS	(Revision 1)
+++ CREDITS	(Arbeitskopie)
@@ -282,6 +282,8 @@
 N: Juergen Boemmels
 D: Parrot I/O; macro stuff in assembler.
 
+N: Kay-Uwe 'kiwi' Hüll
+
 N: Kenneth A Graves
 D: yield and other PIR improvements
 
Index: examples/io/httpd.pir
===
--- examples/io/httpd.pir	(Revision 1)
+++ examples/io/httpd.pir	(Arbeitskopie)
@@ -44,6 +44,11 @@
 
 =cut
 
+.const string CRLF = "\r\n"
+.const string CRLFCRLF = "\r\n\r\n"
+.const string LFLF = "\n\n"
+.const string CRCR = "\r\r"
+
 .sub main :main
 .local pmc sock, work, fp
 .local pmc fp   # read requested files from disk
@@ -83,15 +88,15 @@
 
 if ret <= 0 goto SERVE_REQ
 concat req, buf
-index pos, req, "\r\n\r\n"
+index pos, req, CRLFCRLF
 # print "\npos1:"
 # print pos
 if pos >= 0 goto SERVE_REQ
-index pos, req, "\n\n"
+index pos, req, LFLF
 # print "\npos2:"
 # print pos
 if pos >= 0 goto SERVE_REQ
-index pos, req, "\r\r"
+index pos, req, CRCR
 # print "\npos3:"
 # print pos
 if pos >= 0 goto SERVE_REQ
@@ -137,14 +142,16 @@
 unless fp goto SERVE_404
 
 read file_content, fp, 65535
-rep = "HTTP/1.x 200 OK\n"
-concat rep, "Server: Parrot-httpd/0.1\n"
-concat rep, "Content-Length: "
+rep = "HTTP/1.x 200 OK"
+rep .= CRLF
+rep .= "Server: Parrot-httpd/0.1"
+rep .= CRLF
+rep .= "Content-Length: "
 length len, file_content
 temp = to_string (len)
-concat rep, temp
-concat rep, "\n\n"
-concat rep, file_content
+rep .= temp
+rep .= CRLFCRLF
+rep .= file_content
 send ret, work, rep
 print "served file '"
 print url
@@ -152,12 +159,16 @@
 goto NEXT
 
 SERVE_docroot:
-rep = "HTTP1/1 301 Moved Permamently\nLocation: /docs/html/index.html\nContent-Length: "
+rep = 'HTTP1/1 301 Moved Permamently'
+rep .= CRLF
+rep .= 'Location: /docs/html/index.html'
+rep .= CRLF
+rep .= 'Content-Length: '
 file_content = "Please go to Parrot Documentation." 
 length len, file_content
 temp = to_string (len)
 concat rep, temp
-concat rep, "\n\n"
+concat rep, CRLFCRLF
 concat rep, file_content
 send ret, work, rep
 print "Redirect to 'docs/html/index.hmtl'\n"
@@ -168,7 +179,17 @@
 goto SERVE_file
 
 SERVE_404:
-rep = "HTTP1/1 404 Not Found\nContent-Length: 3\n\n404\n"
+$S0 = '404 Not found'
+$I0 = length $S0
+rep = 'HTTP1/1 404 Not Found'
+rep .= CRLF
+rep .= 'Content-Length: '
+$S1 = $I0
+rep .= $S1
+rep .= CRLF
+rep .= 'Content-Type: text/plain'
+rep .= CRLFCRLF
+rep .= $S0
 print "File not found: '"
 print url
 print "'\n"

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Audrey Tang]

在 2006/7/18 上午 4:38 時，Allison Randal 寫到：


[EMAIL PROTECTED] wrote:
This is not a maintainable build solution. Revert and come back  
when you have one.


Reverted.

Audrey



PGP.sig
Description: This is a digitally signed message part

[perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o

[via RT]

# New Ticket Created by  chromatic 
# Please include the string:  [perl #39856]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39856 >


After discussing the idea with Allison, we both believe that Parrot should be 
able to produce a single PBC file from a command like:

parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

-- c

Re: Checkin #13345

[Audrey Tang]

在 2006/7/18 上午 4:49 時，chromatic 寫到：
I don't believe there's a working heuristic for guessing which  
parameter the
user failed to provide.  That's why I didn't write the original  
version that

way.


Does r13347 look better?  If not, please revert both my changes.

As an aside, regardless of the three changes, this still segfaults:

./parrot -D 1

as does this:

./parrot ''

Thanks,
Audrey

PGP.sig
Description: This is a digitally signed message part

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Audrey Tang]

在 2006/7/18 上午 4:38 時，Allison Randal 寫到：
This is not a maintainable build solution. Revert and come back  
when you have one.


Please clarify: What, exactly, is not maintainable?  The presence of  
a .diff file, or the fact that it needs to be applied manually?


If the latter, an extra line of Makefile rule suffices.  If the  
former, a bison post-processor wrapper is needed.


Thanks,
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Audrey Tang]

在 2006/7/18 上午 5:24 時，Audrey Tang 寫到：

在 2006/7/18 上午 4:38 時，Allison Randal 寫到：
This is not a maintainable build solution. Revert and come back  
when you have one.


Please clarify: What, exactly, is not maintainable?  The presence  
of a .diff file, or the fact that it needs to be applied manually?


If the latter, an extra line of Makefile rule suffices.  If the  
former, a bison post-processor wrapper is needed.


Assuming both were considered unmaintainable, fixed them, and  
committed again as r13348.


I'd be willing to revert r13348 again if you find anything wrong with  
it, but a more specific response would be appreciated.


Thanks,
Audrey




PGP.sig
Description: This is a digitally signed message part

Kwalitee metric: Broken Installer

[Steffen Mueller]

Hi domm, hi perl.qa,

we had a discussion about distributions with broken versions of 
Module::Install. Using Module::CPANTS::Kwalitee::* as models I wrote a 
simple plugin that calculates a Kwalitee metric "uses_broken_installer".


- If the distribution doesn't use Module::Install, it's fine for now.
- If it uses a recent Module::Install, that okay, too.
- If it uses a version of Module::Install that's known to be broken, it 
doesn't get the kwalitee point.


The BrokenInstaller.pm file is attached. It's a straightforward adaption 
of what the other metric plugins do.


Feedback is welcome, though I'd rather not talk about the way I 
determine the version number. It works for all known versions of 
Module::Install.


domm: What do you think? Is this a good metric? If so, would you like to 
include the plugin in the distribution or do you want me to upload a 
separate distribution?


Steffen


BrokenInstaller.pm
Description: Perl program

Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o

[Leopold Toetsch]

Am Montag, 17. Juli 2006 21:11 schrieb chromatic:

>
> After discussing the idea with Allison, we both believe that Parrot should
> be able to produce a single PBC file from a command like:
>
>   parrot -o all_files.pbc file1.pir file2.pir ... filen.pir

Well, that exists already and is named pbc_merge. pbc_merge takes .pbc input 
only, but this shouldn't be a problem.

leo

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Audrey Tang]

在 2006/7/18 上午 6:21 時，Audrey Tang 寫到：

在 2006/7/18 上午 5:24 時，Audrey Tang 寫到：

在 2006/7/18 上午 4:38 時，Allison Randal 寫到：
This is not a maintainable build solution. Revert and come back  
when you have one.


Please clarify: What, exactly, is not maintainable?  The presence  
of a .diff file, or the fact that it needs to be applied manually?


If the latter, an extra line of Makefile rule suffices.  If the  
former, a bison post-processor wrapper is needed.


Assuming both were considered unmaintainable, fixed them, and  
committed again as r13348.


I'd be willing to revert r13348 again if you find anything wrong  
with it, but a more specific response would be appreciated.


The obvious wrong thing with it is that it doesn't come with a check  
for flex >= 2.5.33.  Joshua on #parrot said he'll fix that in the  
morning.


Another obvious point was the resilience of the post processor  
against bison outputs.  Fortunately, it appears that with bison >=  
2.2, multiple %lex-param is supported (though they need to be  
declared in separate lines, unlike %parse-param), and multiple %parse- 
param is also made available to all functions including the  
destructor.  Hence if we can bump the version dependency of bison  
too, then this can work without source-level patching at all  
(committed as .


So, is this maintainer-side dependency (bison 2.2+, flex 2.5.33+;  
does not affect the user) a reasonable cost for IMCC reentrancy?


Thanks,
Audrey

PGP.sig
Description: This is a digitally signed message part

Re: Kwalitee metric: Broken Installer

[Thomas Klausner]

Hi!

On Tue, Jul 18, 2006 at 12:27:30PM +0200, Steffen Mueller wrote:
 
> we had a discussion about distributions with broken versions of 
> Module::Install. Using Module::CPANTS::Kwalitee::* as models I wrote a 
> simple plugin that calculates a Kwalitee metric "uses_broken_installer".

Cool!

Maybe we should call it 'uses_broken_bundled_installer' or
'uses_broken_module_install'?

> The BrokenInstaller.pm file is attached. It's a straightforward adaption 
> of what the other metric plugins do.

I only took a short glance (/me is @work ATM), but it looks ok. I'll
take a closer look in the evening.

 
> domm: What do you think? Is this a good metric?

I think it's a good metric, but maybe Module::Install-supports will
disagree :-)

We could also add checks for problems in Makefile.PL/Build.PL...

> If so, would you like to 
> include the plugin in the distribution or do you want me to upload a 
> separate distribution?

I'd rather include it in MCA.

Thanks a lot!


-- 
#!/usr/bin/perl   http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}

Re: Kwalitee metric: Broken Installer

[David Golden]

Thomas Klausner wrote:

I think it's a good metric, but maybe Module::Install-supports will
disagree :-)


Well, as long as it only picks up *certain* versions, that's probably OK.


We could also add checks for problems in Makefile.PL/Build.PL...


At the risk of going out on a limb here, maybe something that detects 
Module::Build::Compat in "passthrough" mode?


Regards,
David

Re: [perl #39857] [PATCH] Made httpd.pir RFC compliant (at least about CRLF)

[Leopold Toetsch]

Am Montag, 17. Juli 2006 22:31 schrieb Kay-Uwe Huell:
> this is a patch to make examples/io/httpd.pir RFC compliant (at least
> about CRLF).

Thanks, applied - r13353.
leo

[perl #39860] [TODO] build - Configure.pl should accept --libdir, etc.

[via RT]

# New Ticket Created by  Joshua Hoblitt 
# Please include the string:  [perl #39860]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39860 >


LIB_DIR gets setup as part of the configure process which is then passed
to the install script as --libdir=$(LIB_DIR).  The solution is to make
Configure.pl more autotools like in that it can accept --libdir,
--datadir, etc.

-J

--
On Tue, Jul 11, 2006 at 09:30:00AM -0500, Steven Pritchard wrote:
> On Sat, Jul 08, 2006 at 07:01:19PM -0500, Steven Pritchard wrote:
> > First, there is a hardcoded "lib" somewhere that I can't seem to find.
> 
> OK, I finally found the (last, I hope) problem.  In
> tools/dev/install_files.pl, there is this line:
> 
> $dest =~ s/^runtime/lib/;
> 
> I may have gone overboard a bit, but here's what I ended up doing:
> 
> %{__perl} -pi -e 's,"/lib","/%{_lib}", if (/^\s*lib_dir\s*=>/)' \
> config/init/defaults.pm
> %{__perl} -pi -e 's,"lib/,"%{_lib}/, if %(/CONST_STRING\(interpreter,/)' \
> src/library.c
> %{__perl} -pi -e 
> "s,'/usr/lib','%{_libdir}',;s,runtime/lib/,runtime/%{_lib}/," \
> tools/dev/install_files.pl \
> tools/dev/mk_manifests.pl
> 
> In the spec file, %{_lib} will expand to "lib64" on x86_64, otherwise
> it's just "lib".  (In other words, this is all wasted effort on i386.)
> 
> It seems to me that having "lib" hard-coded in src/library.c and
> tools/dev/install_files.pl at the very least would be a bug.  Should I
> put a ticket in RT for this?
> 
> > Second, ICU detection fails.  (I haven't had time to look into this
> > yet.)
> 
> I still haven't looked at this...  Note that this is only on x86_64.
> On i386, it works fine.
> 
> Oh, the one other issue I had worth mentioning was that the readline
> test in Configure.pl failed unless I specified --libs=-lcurses.  I'm
> not who is to blame for that though...  (This was on i386 and
> presumably on x86_64 as well.)
> 
> Steve
> -- 
> Steven Pritchard - K&S Pritchard Enterprises, Inc.
> Email: [EMAIL PROTECTED] http://www.kspei.com/
> Phone: (618)398-3000   Mobile: (618)567-7320


pgpmaWTx9akzs.pgp
Description: PGP signature

Re: [svn:parrot] r13343 - trunk/compilers/imcc

[Allison Randal]

Audrey Tang wrote:
This is not a maintainable build solution. Revert and come back when 
you have one.


Please clarify: What, exactly, is not maintainable?  The presence of 
a .diff file, or the fact that it needs to be applied manually?


Both.

Assuming both were considered unmaintainable, fixed them, and 
committed again as r13348.


Excellent! :)

The obvious wrong thing with it is that it doesn't come with a check for 
flex >= 2.5.33.  Joshua on #parrot said he'll fix that in the morning.


Also good. Please add a check for the bison version too.

Another obvious point was the resilience of the post processor against 
bison outputs.  Fortunately, it appears that with bison >= 2.2, multiple 
%lex-param is supported (though they need to be declared in separate 
lines, unlike %parse-param), and multiple %parse-param is also made 
available to all functions including the destructor.  Hence if we can 
bump the version dependency of bison too, then this can work without 
source-level patching at all (committed as .


Agreed, I prefer this to a post-processor on the bison output.

So, is this maintainer-side dependency (bison 2.2+, flex 2.5.33+; does 
not affect the user) a reasonable cost for IMCC reentrancy?


Yes. Periodically upgrading the tools we use is a good idea anyway.

Allison

Re: Kwalitee metric: Broken Installer

[Steffen Mueller]

Hi,

Thomas Klausner schrieb:

On Tue, Jul 18, 2006 at 12:27:30PM +0200, Steffen Mueller wrote:
we had a discussion about distributions with broken versions of 
Module::Install. Using Module::CPANTS::Kwalitee::* as models I wrote a 
simple plugin that calculates a Kwalitee metric "uses_broken_installer".


Cool!

Maybe we should call it 'uses_broken_bundled_installer' or
'uses_broken_module_install'?


I don't think so. If a bug in certain Module::Build versions was to be 
discovered, the resulting broken Makefile.PL's or Build.PL's could also 
be included in this metric. So neither "bundled" nor "module_install" 
applies in that case.


The BrokenInstaller.pm file is attached. It's a straightforward adaption 
of what the other metric plugins do.


I only took a short glance (/me is @work ATM), but it looks ok. I'll
take a closer look in the evening.


Since http://steffen-mueller.net/mi_old.html is generated using very 
similar heuristics, the part in analyse() should be fine. I just took 
::Files.pm and replaced the obvious pieces with my code.



domm: What do you think? Is this a good metric?


I think it's a good metric, but maybe Module::Install-supports will
disagree :-)


I doubt that. It's not aimed at Module::Install or anything. If anybody 
knows about deficiencies in older M::I releases, it's the 
Module::Install maintainers!



We could also add checks for problems in Makefile.PL/Build.PL...


Exactly. That's why I'd like to keep this from being Module::Install 
specific. Separate metric seem overkill.


If so, would you like to 
include the plugin in the distribution or do you want me to upload a 
separate distribution?


I'd rather include it in MCA.


Perfect.

Steffen

Tap Streams

[Ovid]

Hi all,

Just a quick question, mainly aimed at Schwern since he's most familiar with 
TAP::Harness, though others with thoughts should definitely chime in.

To handle streams, I am thinking of this:

  my $parser = TAPx::Parser->new;
  while ( defined ( my $chunk = $tap_stream->next ) ) {
  my @results = $parser->parse_chunk($chunk);
  # do what you will with the result objects
  }
  $parser->finalize;

This seems rather clean because it doesn't matter how the stream is created.  
Pass chunks (usually single lines, but it doesn't have to be) to the parser and 
everything is golden.  Also, this means that I am not dependent on the stream 
interface.

I assume it's desired to be able to view the results as they're coming in 
rather than wait for the end of the stream.

The only potential problem I see with the above scenario is that the chunks 
have to be "complete".  In other words, if I have a "got" in one chunk, having 
the "expected" in the next chunk makes it a bit more difficult to handle 
(though not insurmountable).  However, depending upon how buffering is handled, 
I could see this condition arising.

Thoughts?

Cheers,
Ovid
 
-- If this message is a response to a question on a mailing list, please send 
follow up questions to the list.
 
Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

get_root_namespace opcode vs. interpinfo {cage cleaners?}

[Chip Salzenberg]

Allison, I suppose that given get_root_namespace, that we should get rid of
C?

If that's true, then a good little cleanup task would be removing all usage
of the latter and replacing it with the former.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

flex/bison version for Parrot?

[Chip Salzenberg]

What versions of flex and bison will work now?  I'd like to make
Configure.perl (or perhaps the Makefile at runtime?) choke on --maintainer
if the right versions aren't found.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: flex/bison version for Parrot?

[Audrey Tang]

在 2006/7/18 下午 1:41 時，Chip Salzenberg 寫到：


What versions of flex and bison will work now?  I'd like to make
Configure.perl (or perhaps the Makefile at runtime?) choke on -- 
maintainer

if the right versions aren't found.


Flex 2.5.33, Bison 2.2.

Thanks,
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: [perl #39853] [BUG] Tcl - pwd returns path with backslashes on Win32

[Will Coleda]

Since both tcl and perl seem to like this style (but I'm sure some  
languages need truly native representations), I'd propose that the OS  
PMC give a way to say which is preferred.



On Jul 17, 2006, at 8:58 AM, Ron Blaschke (via RT) wrote:


# New Ticket Created by  Ron Blaschke
# Please include the string:  [perl #39853]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39853 >


Test languages/tcl/t/cmd_pwd.t fails on Win32.  Tcl's pwd returns the
path with backslashes, most likely because OS.cwd does too, but the  
test
expects forward slashes, as the result is compared with Perl's  
Cwd::getcwd.


The "other" Tcl returns forward slashes, too.

C:\Tcl\bin>tclsh
% puts [pwd]
C:/Tcl/bin

I'm not sure if this should be changed in languages/tcl or Parrot's  
OS.cwd.


Ron



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: Checkin #13345

[chromatic]

On Tuesday 18 July 2006 02:21, Audrey Tang wrote:

Hi Audrey,

> Does r13347 look better?  If not, please revert both my changes.

I think it's still misleading.  #13364 is probably as accurate as Parrot can 
report.

> As an aside, regardless of the three changes, this still segfaults:
>
>  ./parrot -D 1
>
> as does this:
>
>  ./parrot ''

I'll work on those.  Thanks for the report.

-- c

Re: Checkin #13345

[jerry gay]

On 7/18/06, chromatic <[EMAIL PROTECTED]> wrote:

On Tuesday 18 July 2006 02:21, Audrey Tang wrote:
> Does r13347 look better?  If not, please revert both my changes.

I think it's still misleading.  #13364 is probably as accurate as Parrot can
report.


and has the distinction of compiling on windows, too :) # audreyt++
~jerry

[perl #39866] segfaulting command line options.

[via RT]

# New Ticket Created by  Will Coleda 
# Please include the string:  [perl #39866]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39866 >



>>  this still segfaults:
>>
>>  ./parrot -D 1
>>
>> as does this:
>>
>>  ./parrot ''

Re: Checkin #13345

[chromatic]

On Tuesday 18 July 2006 12:55, jerry gay wrote:

> On 7/18/06, chromatic <[EMAIL PROTECTED]> wrote:
> > On Tuesday 18 July 2006 02:21, Audrey Tang wrote:
> > > Does r13347 look better?  If not, please revert both my changes.

> > I think it's still misleading.  #13364 is probably as accurate as Parrot
> > can report.

> and has the distinction of compiling on windows, too :) # audreyt++

Sorry, I meant #13367. I forgot to push my change.

-- c

[perl #39867] Configure.perl --maintainer should check flex/bison versions

[via RT]

# New Ticket Created by  Chip Salzenberg 
# Please include the string:  [perl #39867]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39867 >


Currently if the user has bison or flex that's too old, he won't be told,
and will simply find that a maintainer build fails.

Configure.perl should check that flex and bison are adequately modern to
handle the imcc grammar and lexical scan.

Currently required versions:
   flex 2.5.33   (or higher)
   bison 2.2 (or higher)

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: Checkin #13345

[Audrey Tang]

在 2006/7/18 下午 3:55 時，jerry gay 寫到：


On 7/18/06, chromatic <[EMAIL PROTECTED]> wrote:

On Tuesday 18 July 2006 02:21, Audrey Tang wrote:
> Does r13347 look better?  If not, please revert both my changes.

I think it's still misleading.  #13364 is probably as accurate as  
Parrot can

report.


and has the distinction of compiling on windows, too :) # audreyt++


Actually, chromatic meant r13344, not r13364.

Chromatic: Your original commit log noted room for possible  
improvements with the English
message, which I interpreted as a invitation to help, and acted  
accordingly, but probably
was mistaken, and thereby perceived as rude.  I'm sorry about the  
miscommunication.


I'd like to apologize publicly for saying that you can revert both my  
changes if you think
it's stylistically bad English; I should have said "I'd be willing to  
revert to r13344 if

you find inaccuracies with it".

I was already committing a revert to r13344, but it clashed with your  
r13367 a few minutes
ago; for the record, I think your freshly-committed r13367 gives far  
better error message

than either r13344 or r13364.

It's very hard for me to write tests for English parts of a project,  
as they are often
subjective calls.  In this particular case, please forgive me for  
making a change without
submitting as test+patch first to the mailing list, which I should  
have done in the first
place.  You would be correct to chide me for abusing my Parrot commit  
bit; from now on,
I'll learn to avoid committing anything without a clear consensus  
from the parrot porters.


Again, very, very sorry for causing your distress.  It was not meant  
that way, and I'll

learn to adjust my behavior.

Thanks,
Audrey



PGP.sig
Description: This is a digitally signed message part

Re: [perl #39867] Configure.perl --maintainer should check flex/bison versions

[Joshua Hoblitt]

I believe ambs & I fixed this before the bug was filed. ;)

-J

--
On Tue, Jul 18, 2006 at 01:31:16PM -0700, Chip Salzenberg wrote:
> # New Ticket Created by  Chip Salzenberg 
> # Please include the string:  [perl #39867]
> # in the subject line of all future correspondence about this issue. 
> # http://rt.perl.org/rt3/Ticket/Display.html?id=39867 >
> 
> 
> Currently if the user has bison or flex that's too old, he won't be told,
> and will simply find that a maintainer build fails.
> 
> Configure.perl should check that flex and bison are adequately modern to
> handle the imcc grammar and lexical scan.
> 
> Currently required versions:
>flex 2.5.33   (or higher)
>bison 2.2 (or higher)
> 
> -- 
> Chip Salzenberg <[EMAIL PROTECTED]>

another item for the cage list: INTVAL_MAX etc.

[Chip Salzenberg]

(I'd have added this myself, Andy, but you're the keeper of the
cage/todo.pod document structure.)

New thing:

   RT #39855: configuration: define MIN/MAX macros for all integral typedefs

   For example, if INTVAL is long, then config.h should include:

   #include 
   #define INTVAL_MIN LONG_MIN
   #define INTVAL_MAX LONG_MAX
   ...

   etc.

-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: [perl #39867] Configure.perl --maintainer should check flex/bison versions

[Chip Salzenberg]

On Tue, Jul 18, 2006 at 10:48:45AM -1000, Joshua Hoblitt wrote:
> I believe ambs & I fixed this before the bug was filed. ;)

Bugs fixed before they're filed?

Now _that's_ a process failure mode I can live with!  :-)
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: another item for the cage list: INTVAL_MAX etc.

[Will Coleda]

updated the ticket to say [CAGE], which makes it show on the RT list  
for [CAGE] tickets, http://xrl.us/owsd (from cage/todo.pod in the repo.)


Regards.


On Jul 18, 2006, at 4:51 PM, Chip Salzenberg wrote:


(I'd have added this myself, Andy, but you're the keeper of the
cage/todo.pod document structure.)

New thing:

   RT #39855: configuration: define MIN/MAX macros for all integral  
typedefs


   For example, if INTVAL is long, then config.h should include:

   #include 
   #define INTVAL_MIN LONG_MIN
   #define INTVAL_MAX LONG_MAX
   ...

   etc.

--
Chip Salzenberg <[EMAIL PROTECTED]>



--
Will "Coke" Coleda
[EMAIL PROTECTED]

[perl #39868] [CAGE] convert C NN; }> to C NN;>

[via RT]

# New Ticket Created by  Jerry Gay 
# Please include the string:  [perl #39868]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt3/Ticket/Display.html?id=39868 >


some test files were converted to use begin blocks at the bottom of
the test file. this does not work well in some special cases i
consider this style to be a failed experiment.

therefore, all references to C NN; }> must be
converted to C NN;>

~jerry

Re: [perl #39868] [CAGE] convert C

[Will Coleda]

Note: there are some tests where the number of tests cannot be  
determined until runtime (and therefore don't have "BEGIN" blocks  
tied to them.)


These (like t/doc/pod.t) need to be preserved.

On Jul 18, 2006, at 5:47 PM, Jerry Gay (via RT) wrote:


some test files were converted to use begin blocks at the bottom of
the test file. this does not work well in some special cases i
consider this style to be a failed experiment.

therefore, all references to C NN; }> must be
converted to C NN;>

~jerry



--
Will "Coke" Coleda
[EMAIL PROTECTED]

Re: [perl #39853] [BUG] Tcl - pwd returns path with backslashes on Win32

[Ron Blaschke]

Will Coleda wrote:
> Since both tcl and perl seem to like this style (but I'm sure some
> languages need truly native representations), I'd propose that the OS
> PMC give a way to say which is preferred.

I agree.

As another note, many programs are fine with forward slashes, including
Microsoft's Visual C++ compiler and Windows PowerShell.

Python seems to prefer the native representation, but also fine with
forward slashes.

C:\>python
ActivePython 2.4.3 Build 12 (ActiveState Software Inc.) based on
Python 2.4.3 (#69, Apr 11 2006, 15:32:42) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from os import getcwd, chdir
>>> print getcwd()
C:\
>>> chdir("C:/tmp")
>>> print getcwd()
C:\tmp


Ruby seems to like the forward slashes.

C:\tmp>ruby
require 'Shell'
puts Shell.new.cwd
^Z
C:/tmp


Will this slashing madness ever end?

Ron

Re: Kwalitee metric: Broken Installer

[A. Pagaltzis]

* Randy W. Sims <[EMAIL PROTECTED]> [2006-07-19 00:20]:
> For example, who's to say what constitutes a bad version of an
> installer 

How about the installer maintainer himself? As in the case of
M::I…

Regards,
-- 
Aristotle Pagaltzis // 

Re: Kwalitee metric: Broken Installer

[Randy W. Sims]

Steffen Mueller wrote:

Hi domm, hi perl.qa,

we had a discussion about distributions with broken versions of 
Module::Install. Using Module::CPANTS::Kwalitee::* as models I wrote a 
simple plugin that calculates a Kwalitee metric "uses_broken_installer".


- If the distribution doesn't use Module::Install, it's fine for now.
- If it uses a recent Module::Install, that okay, too.
- If it uses a version of Module::Install that's known to be broken, it 
doesn't get the kwalitee point.


The BrokenInstaller.pm file is attached. It's a straightforward adaption 
of what the other metric plugins do.


Feedback is welcome, though I'd rather not talk about the way I 
determine the version number. It works for all known versions of 
Module::Install.


domm: What do you think? Is this a good metric? If so, would you like to 
include the plugin in the distribution or do you want me to upload a 
separate distribution?


I don't think I like it. It makes me nervous for some reason... For 
example, who's to say what constitutes a bad version of an installer 
(actually, this only applies to M::I, since the other installers aren't 
generally bundled, but I don't mind defending M::I here). In this case, 
you've declared every version prior to some arbitrary release to be bad. 
I doubt that is the case. I think there might have been problems with 
one or two releases, but being an old release is not the same as being a 
flawed release.


Randy.

Real Kwalitee, or please stop spending time thinking about CPANTS

[Andy Lester]

At this point, CPANTS rules are getting into the realm of purely self- 
pleasuring.  If more than a dozen people outside of this small  
enclave of people cares whether a module gets a 16 or 17, I'll be  
shocked.


I have a couple of suggestions on ways you can make REAL kwalitee  
changes and provide real benefit to the Perl community.


1) Start applying Perl::Critic to your code, especially modules.  If  
you don't like all the rules, then make a .perlcriticrc file that  
fits your style.


2) If you find that Perl::Critic is missing rules that you would like  
to see applied to your code, then write an extension.  The framework  
is extremely easy to use.  I've written (stolen, really) a half dozen  
rules and put out a distribution called Perl-Critic-Bangs.  See  
http://use.perl.org/~petdance/journal/30296


3) Those things that you put into CPANTS?  The rules about module  
installers and passing POD and what not?  Write in your use.perl  
journal about them.  Write an article for the Perl Review about  
them.  Get them out where people can see them.


4) Adopt a Perl Mongers group.  Go to pm.org, and find a Perl Mongers  
group that could use a kick in the ass and/or expert technical help.   
Then, sign up for their email list.  Answer questions nicely, and  
helpfully.  Don't pick London or Chicago or NY or Portland.  Maybe  
pick Cleveland or Kuala Lumpur.


5) Write tests for Perl 5 core.  Write tests for Parrot.  Write tests  
for Pugs.


6) Become a Parrot Cage Cleaner.  Help me get the Parrot  
underpinnings cleaned up so that it will scale as more and more  
developers join in.  http://use.perl.org/~petdance/journal/30146


And if you still have time or inclination to make CPANTS rules, have  
at it.


Thanks,
xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Kwalitee metric: Broken Installer

[Jonathan Rockway]

I see two resolutions to this problem:

1) Module authors need to re-release their modules whenever 
Module::Install is updated.


This is extremely inconvenient, but not a terrible demand.  If other 
authors are like me, they accumulate small minor changes to their 
modules, and then release when something important comes along.  A new 
M::I is "important" and would force us to keep our "stable" CPAN modules 
up-to-date with our svn repositories or whatever.  That's a good thing 
;) , but probably not the right way of going about it.  (For the record, 
all my M::I modules use the latest version, and I went to no special 
effort to ensure that.  So maybe this isn't as hard as it sounds.) 

(The right way of going about this, BTW, is out of the scope of this 
e-mail... but I do have some ideas...)


2) Get M::I into the core of perl, so that everyone has a known-good 
tested-everywhere version.


This is the best idea.  CPAN works so well because everyone has it and 
it's a good piece of software (lately CPANPLUS has gotten rather buggy 
and I've gone back to regular CPAN!).


The other solutions (like "kwality" or whatever it's called) are stopgap 
measures that don't fix anything.  Anyone that knows about the kwality 
site probably reads this list ;) and knows to update M::I anyway.  The 
other 90% of the modules are one-offs whose authors have "better" things 
to do, probably, than re-release their module whenever a point release 
of some obscure dependency is released :). 

For the time being, maybe someone just needs to download the broken 
modules, fix the inc directory, and upload them back to the CPAN ;)  
That would actually solve the problem. (And introduce many others, but...)


Actually now I see a third resolution: don't use M::I for CPAN modules.  
CPAN (the software) handles dependency installing, it's standard with 
perl, good enough.  I do like M::I, I just can't think of why it's 
really necessary for CPAN modules.  (For non-CPAN perl packages, though, 
it's a GREAT idea.)


Regards,
Jonathan Rockway

I don't think I like it. It makes me nervous for some reason... For 
example, who's to say what constitutes a bad version of an installer 
(actually, this only applies to M::I, since the other installers 
aren't generally bundled, but I don't mind defending M::I here). In 
this case, you've declared every version prior to some arbitrary 
release to be bad. I doubt that is the case. I think there might have 
been problems with one or two releases, but being an old release is 
not the same as being a flawed release.

Re: Kwalitee metric: Broken Installer

[chromatic]

On Tuesday 18 July 2006 15:57, Jonathan Rockway wrote:

> 2) Get M::I into the core of perl, so that everyone has a known-good
> tested-everywhere version.

For various values of "everyone" and "everywhere" perhaps.

> Actually now I see a third resolution: don't use M::I for CPAN modules.
> CPAN (the software) handles dependency installing, it's standard with
> perl, good enough.  I do like M::I, I just can't think of why it's
> really necessary for CPAN modules.  (For non-CPAN perl packages, though,
> it's a GREAT idea.)

That's my preference as well.

-- c

Re: Checkin #13345

[chromatic]

On Tuesday 18 July 2006 13:38, Audrey Tang wrote:

> Chromatic: Your original commit log noted room for possible
> improvements with the English
> message, which I interpreted as a invitation to help, and acted
> accordingly, but probably
> was mistaken, and thereby perceived as rude.  I'm sorry about the
> miscommunication.

To be fair, it was one of my tersest and worst commit messages.  I should have 
noted why I was unhappy with the error message, as well as the problems I had 
in creating a better one.  (It was also 1 am local time.)

I hope r13376 was much more clear.

-- c

Re: Lessons from the test function parameter placement quibbles?

[Michael G Schwern]

On 7/17/06, demerphq <[EMAIL PROTECTED]> wrote:

Just to clarify, my main point is really that test names should be
mandatory. The fact that making them mandatory also solves other
problems is to me mostly a nice bonus. What I really want is that when
I try to build something and it fails test that I can find the failing
test easily (meaning in a minute or two of looking at the source), and
IMO the best way to do that is to make test names mandatory.


The file and line number provided by the failing test isn't enough to find it?

Re: Lessons from the test function parameter placement quibbles?

[Michael G Schwern]

On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:

so by now we've had quibbles about the "irregularity" of `skip`,
`can_ok` and `isa_ok`, and a suggestion that the test name always
go first.


This puts the emphesis on the wrong thing.  The point of the test is
the test, not the description.

Descriptions are optional because they are not necessary for the test.
Sometimes a test doesn't need a description, its obvious from reading
the code what its doing.  Sometimes it would be redundant.  Sometimes
you're just writing fast.  I write tests without descriptions all the
time.

Its not Test::More's job to enforce style.  The more things are
optional the more useful to more people it is.



Had they been named parameters, we wouldn't be having this
discussion.


   is got => 'foo', expected => 'bar', description => 'foo is bar';

   is 'foo', 'bar', 'foo is bar';

When you plan to use a function thousands of times, brevity is nice.
Same reason its "ok" and "is" and not "assert" and "assert_eq_string".

Your average test function has a very narrow interface:  what you got;
what you expected; maybe a name.  Not a whole lot of room for
confusion there.  Named params are nice when you have a wide
interface, or when you plan on expanding the interface later.

And no, I'm not going to add magic hash ref arguments to Test::More.
Part of its interface design is to be unambiguous and unmagical so
that bad input is not interpreted as some esoteric functionality
(contrast with Test.pm).

When Perl 6 rolls around we can do the named and positional argument thing.

Re: Lessons from the test function parameter placement quibbles?

[Hakim Cassimally]

On 19/07/06, Michael G Schwern <[EMAIL PROTECTED]> wrote:

On 7/17/06, demerphq <[EMAIL PROTECTED]> wrote:
> IMO the best way to do that is to make test names mandatory.
The file and line number provided by the failing test isn't enough to find it?


Not always, but even so, mandatory test names is all kinds of bad,
including "not very perlish" and "likely to turn beginners away from
testing", and "likely to have people typing in random characters to
invent a test name" and "creating clashing test names by accident".

I'd like test names to be more widespread, but I really don't want
them mandatory.

osfameron

Re: use Tests; # ?

[Michael G Schwern]

On 7/17/06, demerphq <[EMAIL PROTECTED]> wrote:

> Well, if the test passes, there's no need to know where exactly it's
> located.  If it fails, the diagnostics contain the line number:
>
>   not ok 6
>   #   Failed test in t/xxx.t at line 26.
>
> I've never seen incorrect line numbers.

I have. Lots and lots and lots of times. I could do a survey but IMO
it would be a waste of time.


BUG REPORT PLZ K THNX111111!

If you don't tell people their shit is broke it doesn't get fixed.

Re: use Tests; # ?

[Michael G Schwern]

On 7/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:

I know we've moved on, but I'm in a completely different time zone, so please 
understand...

I, like demerphq, also think that coming up with a name for each and every test 
is a good idea.

It shouldn't be hard to think of a description for each and every test.

Just note down why you wrote that test case in the first place.

Don't know why you wrote a test case ? Then delete it, for it serves no known 
purpose.

Tests are written for a reason, and that reaons should be part of the test.


Me?  I'm just lazy.  If the test is pretty obvious by looking at the
code then I'm not going to bother taking the time to repeat myself
with a test description.

The great part about descriptions being optional is you can do it your
way, and I can do it my way.

Re: Lessons from the test function parameter placement quibbles?

[Jonathan Rockway]

> I'd like test names to be more widespread, but I really don't want
> them mandatory.

If you really don't want to have test names, you can specify undef.  But
making them "required" (as in "before everything else") makes the API
easier to use for people who are doing things right (i.e. naming their
tests).

use Test::More::MandatoryName tests=>3;

sub ok {
   Test::More::ok(undef, @_);
}

ok($foo == $bar);
ok($baz < $quux);

can_ok('$foo loaded its methods from the XML', qw(foo bar baz can isa));

This setup is better than what Test::More does right now, since can_ok
could now accept a test name.

Regards,
Jonathan Rockway



signature.asc
Description: OpenPGP digital signature

Re: Tap Streams

[Randy W. Sims]

Ovid wrote:

Hi all,

Just a quick question, mainly aimed at Schwern since he's most familiar with 
TAP::Harness, though others with thoughts should definitely chime in.

To handle streams, I am thinking of this:

  my $parser = TAPx::Parser->new;
  while ( defined ( my $chunk = $tap_stream->next ) ) {
  my @results = $parser->parse_chunk($chunk);
  # do what you will with the result objects
  }
  $parser->finalize;

This seems rather clean because it doesn't matter how the stream is created.  
Pass chunks (usually single lines, but it doesn't have to be) to the parser and 
everything is golden.  Also, this means that I am not dependent on the stream 
interface.

I assume it's desired to be able to view the results as they're coming in 
rather than wait for the end of the stream.

The only potential problem I see with the above scenario is that the chunks have to be "complete".  
In other words, if I have a "got" in one chunk, having the "expected" in the next chunk 
makes it a bit more difficult to handle (though not insurmountable).  However, depending upon how buffering 
is handled, I could see this condition arising.

Thoughts?


Seems like the stream and parser are integrally linked anyway. Maybe the 
parser should have a stream.


  my $parser = TAPx::Parser->new_from_stream($tap_stream);
  while ( defined ( my $results = $parser->next ) ) {
  # do what you will with the $results object
  }
  $parser->finalize;

In your above example, would you every use $chunk other than as an 
argument to parse_chunk? Or, if it is needed, can't you call 
$results->raw to get them?


The dependency on the stream interface is not necessarily bad; it would 
just mean pushing the decoupling up a level: let the stream abstract 
away the details of reading bits from some source. Your above example 
would allow:


  my $parser = TAPx::Parser->new;
  while ( defined ( my $results =  ) ) {
  my @results = $parser->parse_chunk($chunk);
  }
  $parser->finalize;

But if you make the stream into a complete, closed abstraction over your 
input, it would have be more like:


  my $tap_stream = TAP::Source->new(\*STDOUT);
  my $parser = TAPx::Parser->new($tap_stream);
  while ( defined ( my $results = $parser->next ) ) {
  my @results = $parser->parse_chunk($chunk);
  }
  $parser->finalize;

Or something like that. It seems to me that requiring the source to be 
wrapped an object would afford a little more protection through 
separating concerns of each object: Streams handle streaming errors; 
Parsers handle parsing errors. This also allows the parser to /know/ how 
to retrieve a meaningful chunk of data from a stream, whether it's a 
single line or multiple lines, because a stream has a guaranteed interface.


Is $tap_stream->next() a destructive iterator? Is use-once or 
resettable? Is it unidirectional? Does it matter?


I think I do like the iterator approach. If an event model is needed, it 
is easy enough to put together with a light layer on top.


Randy.

Re: Lessons from the test function parameter placement quibbles?

[chromatic]

On Tuesday 18 July 2006 17:28, Jonathan Rockway wrote:

> If you really don't want to have test names, you can specify undef.  But
> making them "required" (as in "before everything else") makes the API
> easier to use for people who are doing things right (i.e. naming their
> tests).

That's begging the question!

> This setup is better than what Test::More does right now, since can_ok
> could now accept a test name.

What's unclear about:

can_ok( $some_invocant, 'some_method' );

... that is clearer with:

can_ok( $some_invocant, 'some_method', 
name => q|$some_invocant->can( 'some_method' )| );

(My mind idly wonders if it were possible to generate this test description... 
somehow... somewhere)

-- c

Re: Checkin #13345

[Matt Diephouse]

chromatic <[EMAIL PROTECTED]> wrote:

... provides quite misleading results:

$ parrot -o file.pir
Option file.pir expects an argument
parrot -[abcCEfgGhjprStvVwy.] [-d [FLAGS]] [-O [level]] [-o FILE] 

I don't believe there's a working heuristic for guessing which parameter the
user failed to provide.  That's why I didn't write the original version that
way.


I know I'm a little late to the game here, but in the future it would
be useful to mention this sort of info in a comment in the source. :-)
And a comment might be a nice addition even now.

(You mentioned being more clear in the svn log, but a comment would
really be the most useful.)

--
Matt Diephouse
http://matt.diephouse.com

Re: Checkin #13345

[chromatic]

On Tuesday 18 July 2006 19:43, Matt Diephouse wrote:

> I know I'm a little late to the game here, but in the future it would
> be useful to mention this sort of info in a comment in the source. :-)
> And a comment might be a nice addition even now.
>
> (You mentioned being more clear in the svn log, but a comment would
> really be the most useful.)

Something like this?

-- c

=== compilers/imcc/main.c
==
--- compilers/imcc/main.c(revision 19177)
+++ compilers/imcc/main.c(local)
@@ -370,6 +370,15 @@
 }
 /* reached the end of the option list and consumed all of argv */
 if (*argc == opt.opt_index ) {
+
+/* The only flag that must take a parameter is -o, so if there is a
+ * mismatch, either that missed its required argument or there is no
+ * program to execute.  Detecting -o is easy; there's an
+ * interp->output_file.  (If -o appears with no argument, the getopt
+ * check would have complained earlier.)
+ *
+ * There's really no way to tell which parameter is missing.  For now,
+ * this is the best error message I can imagine. -- c */
 if (interp->output_file) {
 fprintf(stderr, "Missing program name or argument for -o\n");
 }

[svn:perl6-synopsis] r10299 - doc/trunk/design/syn

[larry]

Author: larry
Date: Tue Jul 18 20:26:43 2006
New Revision: 10299

Modified:
   doc/trunk/design/syn/S02.pod
   doc/trunk/design/syn/S03.pod

Log:
Tightening up deceptive syntaxes a bit.


Modified: doc/trunk/design/syn/S02.pod
==
--- doc/trunk/design/syn/S02.pod(original)
+++ doc/trunk/design/syn/S02.podTue Jul 18 20:26:43 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 10 Aug 2004
-  Last Modified: 12 July 2006
+  Last Modified: 18 July 2006
   Number: 2
-  Version: 50
+  Version: 51
 
 This document summarizes Apocalypse 2, which covers small-scale
 lexical items and typological issues.  (These Synopses also contain
@@ -1291,7 +1291,7 @@
 a => %foo   %foo:
 
 Note that as usual the C<{...}> form can indicate either a closure or a hash
-depending on the contents.
+depending on the contents.  It does I indicate a subscript.
 
 Note also that the C<<  >> form is not a subscript and is therefore
 equivalent not to C<.{'a','b'}> but rather to C<('a','b')>.  Bare C<<  >>
@@ -1761,8 +1761,9 @@
 .foo(1)# $_.foo(1) -- must be "dot" method with () args
 .foo   # $_.foo()  -- must be "dot" method with no args
 .$foo: # $_.$foo: 1-- indirect "dot" method with : args
-foo bar: 1 # bar.foo(1)-- bar must be predecl as class or sub
-   -- foo method call even if declared sub
+foo bar: 1 # bar.foo(1)-- bar must be predecl as class
+   -- sub bar allowed here only if 0-ary
+   -- otherwise you must say (bar):
 foo bar 1  # foo(bar(1))   -- both subject to postdeclaration
-- never taken as indirect object
 foo $bar: 1# $bar.foo(1)   -- indirect object even if 
declared sub

Modified: doc/trunk/design/syn/S03.pod
==
--- doc/trunk/design/syn/S03.pod(original)
+++ doc/trunk/design/syn/S03.podTue Jul 18 20:26:43 2006
@@ -12,9 +12,9 @@
 
   Maintainer: Larry Wall <[EMAIL PROTECTED]>
   Date: 8 Mar 2004
-  Last Modified: 16 Jul 2006
+  Last Modified: 18 Jul 2006
   Number: 3
-  Version: 49
+  Version: 50
 
 =head1 Changes to existing operators
 
@@ -245,20 +245,54 @@
 indicated via whitespace between the list operator and the first
 argument.  If there is whitespace, it is always a list operator,
 and the next token will be taken as the first term of the list (or
-if there are no terms, as the expression terminator).
+if there are no terms, as the expression terminator).  Any infix operator
+occurring where a term is expected will be misinterpreted as a term:
 
-If there is no whitespace, the operator is never taken as a list
-operator, but always as a functional operator.  Postfixes are
-specifically disallowed right after the operator except for the
-parenthetical forms delimiting the argument list.  The parentheses
-are optional if and only if there are no arguments.  If there are
-parentheses, they may be followed by any postfix operator.  Unlike
-postfix operators, infix operators and expression terminators are
-allowed without intervening whitespace, and will be taken to indicate
-that the operator is a function with no arguments.
+say + 2;   # means say(+2);
+
+If there is no whitespace, subsequent parsing depends on the
+syntactic category of the next item.  Parentheses (with or without
+a dot) turn the list operator into a function call instead, and
+all the function's arguments must be passed inside the parentheses
+(with the sole exception of an adverbial block, which may follow the
+parentheses).
+
+Other than various forms of parentheses, all other postfixes are
+disallowed immediately after a list operator, even if there are no
+arguments.  To add a postfix to an argumentless list operator you
+must write it as a function call with empty parentheses:
+
+foo.[] # ILLEGAL
+foo++  # ILLEGAL
+foo().[]   # legal
+foo()++# legal (if foo() is rw)
+
+After the parentheses any postfix operators are allowed, and apply
+to the result of the function call.  (Also note that the postfix
+restriction applies only to list operators; it doesn't apply to
+methods.  It is legal to say
+
+$foo.bar
+
+to mean
+
+$foo.bar().{'a','b','c'}
+
+because methods never assume there are arguments unless followed by
+parentheses or a colon.)
+
+If the next item after the list operator is either an infix operator
+or a term, a syntax error.  [Conjecture: this may be relaxed in
+non-strict mode.]
 
 Examples:
 
+say foo + 1;   say(foo(+1));
+say foo $x;say(foo($x));
+say foo$x; ILLEGAL, need space or parens
+say foo+1; 

Re: Hyperoperators and the Each role

[Larry Wall]

On Mon, Jul 17, 2006 at 06:06:52PM -0400, Christopher Jeris wrote:
: I have a couple of questions about what S03 says about hyperoperators
: applying recursively to any object which matches the 'Each' role:
: 
: [from S03]
: Seq(3,8,[2,Seq(9,3)],8) >>-<< (1,1,2,1); # Seq(2,7,[0,Seq(7,1)],7)
: 
: 1. What determines the concrete type of the result of a binary
: hyperoperator which is applied to objects of two different sequence types?
:  Does the example mean that binary hyperoperators are not symmetric (in
: type) even when their underlying operator is symmetric?

Good question.  We'll have to come up with a strategy for that.  Obviously
if the two sides are the same container type, we'd like to keep that.
If they differ, then there are several approaches to finding a common
container type, I imagine.  Doubtless it will end up coming down to
some kind of hidden MMD dispatch on container types.

: 2. Will the 'Each' role require objects implementing it to be, not only
: destructurable, but constructible - as the hyperoperator in the example
: constructs a fresh Seq?  Does this mean that hyperoperators won't apply to,
: say, database result sets?

I would say that constructable is too strong--it merely needs to be clonable
as a container and fillable with the results, assuming the container in
question is able to contain the result type in question.  That might entail
an each variant that mutates the type of the cloned container's elements.
But I'll leave that up to the implementors.  :)

Larry

Re: [CAGE] Coverity and Splint: Has anyone started using these with Parrot?

[Nicholas Clark]

On Wed, Jul 12, 2006 at 12:54:30AM -0500, Andy Lester wrote:

> I think the very first thing we ought to do is start working on  
> turning up the warnings levels in gcc as much as we can, and add as  
> many warnings flags as we can.  gcc at least is pretty standard and  
> we can all use it.

config/auto/gcc.pm has logic to enable gcc warnings by gcc version.
At one time we had more warnings on that we do now.

Turning the alignment warnings on gets "interesting" (for a very noisy value
of interesting) on architectures less forgiving than x86, such as sparc.

Nicholas Clark

Re: [svn:perl6-synopsis] r10299 - doc/trunk/design/syn

[Smylers]

[EMAIL PROTECTED] writes:

> New Revision: 10299
> 
> Modified: doc/trunk/design/syn/S03.pod
> ==
> 
> +If the next item after the list operator is either an infix operator
> +or a term, a syntax error.

If the sentence has no verb, a grammatical error.

Smylers

Re: Re: Checkin #13345

[Matt Diephouse]

chromatic <[EMAIL PROTECTED]> wrote:

On Tuesday 18 July 2006 19:43, Matt Diephouse wrote:

> I know I'm a little late to the game here, but in the future it would
> be useful to mention this sort of info in a comment in the source. :-)
> And a comment might be a nice addition even now.
>
> (You mentioned being more clear in the svn log, but a comment would
> really be the most useful.)

Something like this?


This is what I ended up applying (inlined because it's already ci'd).
I wanted to get more into why having -o means that we can't tell what
the user forgot to pass. (And having not written any of the code, I
could tell what wasn't immediately clear :-)

--
matt diephouse
http://matt.diephouse.com


--- compilers/imcc/main.c   (revision 13376)
+++ compilers/imcc/main.c   (working copy)
@@ -368,8 +368,17 @@
usage(stderr);
exit(EX_USAGE);
}
-/* reached the end of the option list and consumed all of argv */
+/* if we reached the end of the option list and consumed all of argv,
+ * we don't have the name of a program to run */
if (*argc == opt.opt_index ) {
+
+/* If the user passed the -o flag -- the only flag that must take a
+ * parameter -- then we can't be sure that the user forgot the name of
+ * the program. it could be that the user forgot to give the argument
+ * for -o and the rest of argv got slurped up as flags. (If -o appeared
+ * with no argument, the getopt check would have complained earlier.)
+ *
+ * Given that, this was the best error message we could come up with */
if (interp->output_file) {
fprintf(stderr, "Missing program name or argument for -o\n");
}

Re: Lessons from the test function parameter placement quibbles?

[A. Pagaltzis]

* Michael G Schwern <[EMAIL PROTECTED]> [2006-07-19 02:10]:
> On 7/17/06, A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> >Had they been named parameters, we wouldn't be having this
> >discussion.
> 
>is got => 'foo', expected => 'bar', description => 'foo is bar';
> 
>is 'foo', 'bar', 'foo is bar';
> 
> When you plan to use a function thousands of times, brevity is
> nice. Same reason its "ok" and "is" and not "assert" and
> "assert_eq_string".

I know. That’s why I said it would have been nice if the
interface had been planned out that way from the start. Then I’d
cast your example like so:

is 'foo', 'bar', msg => 'foo is bar';

The extra `msg =>` is not too painful, I think, and it would
allow things like `skip` which are relatively uncommon to then
work thusly:

skip n => 2, msg => "Don't feel like it today";

There’s no way to mix up the parameters with that interface.

Ambiguities could easily be avoided for things like `can_ok`
which can take lists for one “logical parameter” by always taking
them as an arrayref.

It’s nosier than the current interface, but just slightly, and it
would make the API a lot more regular.

But we don’t get to fix it now; hopefully for Perl 6.

Regards,
-- 
Aristotle Pagaltzis //