Re: IMCC Reentrancy
在 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
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
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
# New Ticket Created by Ron Blaschke # Please include the string: [perl #39853] # in the subject line of all future correspondence about this issue. # URL: 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\bintclsh % puts [pwd] C:/Tcl/bin I'm not sure if this should be changed in languages/tcl or Parrot's OS.cwd. Ron
[perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o
# New Ticket Created by chromatic # Please include the string: [perl #39856] # in the subject line of all future correspondence about this issue. # URL: 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
[perl #39858] [PATCH] more elegant hex_to_int in examples/io/httpd.pir
# New Ticket Created by Kay-Uwe Huell # Please include the string: [perl #39858] # in the subject line of all future correspondence about this issue. # URL: 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 a href='docs/html/index.html'Parrot Documentation/a. 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 -sub pos, pos, 1 -if pos=0 gotoNEXT_CHAR
Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o
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 -- pgpquf0alL34t.pgp Description: PGP signature
Re: [svn:parrot] r13343 - trunk/compilers/imcc
[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
[perl #39857] [PATCH] Made httpd.pir RFC compliant (at least about CRLF)
# New Ticket Created by Kay-Uwe Huell # Please include the string: [perl #39857] # in the subject line of all future correspondence about this issue. # URL: 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 a href='docs/html/index.html'Parrot Documentation/a. 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
Checkin #13345
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] 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
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 -- pgpx9rKFZBq4l.pgp Description: PGP signature
Re: [svn:parrot] r13343 - trunk/compilers/imcc
在 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
Re: Checkin #13345
在 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
在 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
在 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
Re: [perl #39856] TODO: Produce Single PBC from Multiple PIR Files with -o
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
在 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: [perl #39857] [PATCH] Made httpd.pir RFC compliant (at least about CRLF)
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.
# New Ticket Created by Joshua Hoblitt
# Please include the string: [perl #39860]
# in the subject line of all future correspondence about this issue.
# URL: 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 - KS Pritchard Enterprises, Inc.
Email: [EMAIL PROTECTED] http://www.kspei.com/
Phone: (618)398-3000 Mobile: (618)567-7320
pgpYrFsq4ua1r.pgp
Description: PGP signature
Re: [svn:parrot] r13343 - trunk/compilers/imcc
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
get_root_namespace opcode vs. interpinfo {cage cleaners?}
Allison, I suppose that given get_root_namespace, that we should get rid of Cinterpinfo .INTERP_ROOT_NAMESPACE? 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?
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?
在 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
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. # URL: 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\bintclsh % 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
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.
# New Ticket Created by Will Coleda # Please include the string: [perl #39866] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt3/Ticket/Display.html?id=39866 this still segfaults: ./parrot -D 1 as does this: ./parrot ''
Re: Checkin #13345
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
# New Ticket Created by Chip Salzenberg # Please include the string: [perl #39867] # in the subject line of all future correspondence about this issue. # URL: 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
在 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
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. # URL: 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.
(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 limits.h #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
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.
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 limits.h #define INTVAL_MIN LONG_MIN #define INTVAL_MAX LONG_MAX ... etc. -- Chip Salzenberg [EMAIL PROTECTED] -- Will Coke Coleda [EMAIL PROTECTED]
[perl #39868] [CAGE] convert CBEGIN { plan tests = NN; } to Cuse Parrot::Test tests = NN;
# New Ticket Created by Jerry Gay
# Please include the string: [perl #39868]
# in the subject line of all future correspondence about this issue.
# URL: 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 CBEGIN { plan tests = NN; } must be
converted to Cuse Parrot::Test tests = NN;
~jerry
Re: [perl #39868] [CAGE] convert CBEGIN …
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 CBEGIN { plan tests = NN; } must be
converted to Cuse Parrot::Test tests = NN;
~jerry
--
Will Coke Coleda
[EMAIL PROTECTED]
Re: [perl #39853] [BUG] Tcl - pwd returns path with backslashes on Win32
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:\tmpruby require 'Shell' puts Shell.new.cwd ^Z C:/tmp Will this slashing madness ever end? Ron
Re: Checkin #13345
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: Checkin #13345
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] 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
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);
}
Re: [CAGE] Coverity and Splint: Has anyone started using these with Parrot?
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
